שדרוג אתר קיים בלי לאבד כתובות ותוכן: צ׳קליסט מעבר מקצועי

אתר חדש יכול להיראות מצוין ועדיין לפספס את מה שהאתר הקודם כבר עשה טוב. לקוח שמגיע מקישור ישן עלול לנחות בעמוד שגיאה. מאמר מועיל יכול להיעלם בזמן העברת התוכן. טופס שנראה תקין על המסך לא בהכרח מעביר את הפנייה למקום הנכון.

לכן שדרוג אתר אינו רק פרויקט עיצוב. הוא גם תהליך של שימור מידע, בדיקת מסלולים והעברת אחריות. המדריך הזה נועד לבעלי עסקים שכבר יש להם אתר ורוצים לשפר אותו, בלי להתחיל את ההיכרות עם הלקוחות מחדש. הוא מציע תהליך עבודה לצמצום טעויות, לא הבטחה לשמירת מיקומים או להגדלת תנועה.

מתחילים מהחלטה: מה באמת מחליפים?

לפני סקיצות ועיצובים, כתבו מה לא עובד היום. האם קשה להסביר את השירותים? האם תוכן חשוב קבור בתפריט? האם עדכון עמוד דורש פנייה למפתח? אולי האתר ברור ושימושי, ורק חלק מהמסכים דורשים רענון.

יש הבדל בין שינוי עיצוב, מעבר למערכת ניהול חדשה, שינוי כתובות והחלפת דומיין. לא חייבים לבצע את כולם יחד. אם אין סיבה עסקית או טכנית לשנות כתובת של עמוד שימושי, כדאי לשקול לשמור אותה. כך קל יותר לדעת מה השתנה ומה צריך לבדוק.

מסמך הפתיחה יכול להיות קצר: מה משפרים, מה משאירים, מה לא נוגעים בו ומי מאשר כל החלטה. בפרויקט של בניית אתר תדמית, המסמך הזה עוזר להפוך רצון כללי ב״אתר מודרני״ לתוצאה שאפשר לבדוק.

מכינים מלאי לפני שמוחקים או מעבירים

התחילו ברשימת העמודים הקיימים. אפשר להצליב את מערכת הניהול, מפת האתר ונתוני Search Console, אם יש גישה לנכס הנכון. אל תסתפקו בעמודים שרואים בתפריט: מאמרים, קבצים להורדה, עמודים שאליהם מפנים קמפיינים ותמונות עשויים להיות חלק מהפעילות.

לצד כל כתובת רשמו מה יש בעמוד, למי הוא עוזר ומה רוצים לעשות איתו. שלוש החלטות שימושיות הן לשמור, לשפר או לבחון מחדש. ״לבחון מחדש״ אינו אישור למחוק. גם עמוד שלא מושך הרבה כניסות עשוי להסביר שירות חשוב או לשמש לקוח שכבר נמצא בתהליך מכירה.

כדאי להוסיף לרשימה גם בעל אחריות. מי בודק שהמחיר שמופיע עדיין נכון? מי מאשר שימוש בהמלצה של לקוח? מי יודע אם מסמך ישן עדיין בתוקף? אלו שאלות תוכן ועסק, לא רק שאלות פיתוח.

כשכתובת משתנה, מגדירים יעד מדויק

לכל כתובת שמשתנה צריך להחליט לאן היא עוברת. במקום להפנות את כל האתר הישן לדף הבית, התאימו בין העמוד הישן לבין היעד שנותן מענה דומה. מפת מעבר פשוטה כוללת כתובת ישנה, כתובת חדשה, סיבת השינוי ותוצאת בדיקה.

לדוגמה, עמוד על שירות מסוים צריך להוביל לעמוד המעודכן של אותו שירות, אם קיים כזה. אם ביטלתם שירות ואין תוכן חלופי רלוונטי, אל תסתירו את ההחלטה מאחורי יעד לא קשור. בקשו ממי שמבצע את המעבר להגדיר את ההתנהגות המתאימה ולתעד אותה.

בהעברה קבועה Google ממליצה על הפניה קבועה בצד השרת, בדרך כלל 301 או 308. מומלץ שהקישור הישן יוביל ישירות ליעד הסופי ולא יעבור דרך רצף כתובות ביניים. הסבר Google על הפניות.

הפניה אינה מחליפה עדכון של קישורים בתוך האתר. בדקו את ההדר, הפוטר, הכפתורים, קישורי השירותים והקישורים מתוך המאמרים. הקורא לא אמור להרגיש שהוא עובר דרך הגרסה הקודמת בכל לחיצה.

בודקים את התוכן, לא רק את מספר העמודים

ספירה זהה של עמודים לפני ואחרי אינה מוכיחה שההעברה הצליחה. פתחו עמוד חשוב בשתי הגרסאות והשוו: האם נשמר ההסבר שעוזר ללקוח להחליט? האם שאלות נפוצות נעלמו? האם נשארה כותרת בלי הטקסט שמתחתיה? האם קישור להורדת מסמך עדיין עובד?

את הבדיקה כדאי לחלק לשתי רשימות. הראשונה כוללת מידע שצריך להישמר, כגון תיאור שירות, פרטי יצירת קשר ותוכן מקצועי שימושי. השנייה כוללת שיפורים מתוכננים, כגון ניסוח ברור יותר או סידור מחודש של סעיפים. ההפרדה מונעת מצב שבו אובדן מקרי מוצג כשינוי עיצובי.

לא כל משפט ישן חייב להישאר. מידע לא נכון צריך לתקן, ותוכן כפול דורש החלטה. אבל שינוי כזה צריך להיות מכוון, ולא תוצאה של שדה שלא עבר למערכת החדשה.

לפני העלייה: בדיקה טכנית שאפשר להסביר גם לבעל העסק

בקשו דוח בדיקות שמציין כתובת, תוצאה ומועד בדיקה, ולא רק הודעה ש״הכול תקין״. אלו כמה בדיקות שימושיות:

• עמודים שאמורים להיות ציבוריים נפתחים ומציגים את התוכן הנכון, גם כשנכנסים ישירות לכתובת.
• כתובות ישנות שנכללות במפת המעבר מגיעות ליעדים שנקבעו.
• לכל עמוד חשוב יש כותרת ותיאור מתאימים, וכותרת ראשית ברורה.
• הכתובת הקנונית, כלומר הגרסה המועדפת של העמוד שמוצהרת בקוד, מתאימה לכתובת הציבורית.
• מפת האתר והקישורים הפנימיים מפנים לכתובות המעודכנות.
• תמונות, מסמכים ותפריטי ניווט נפתחים במחשב ובטלפון.

בסביבת פיתוח עשויים להשתמש ב־noindex כדי למנוע הופעה בחיפוש. ודאו שההגדרה אינה נשארת בטעות בעמודים הציבוריים שמיועדים לאינדוקס. חסימה ב־robots.txt אינה תחליף ל־noindex: Google צריכה להיות מסוגלת לסרוק את העמוד כדי לראות את הוראת noindex. התיעוד הרשמי של Google.

הנחיות המעבר של Google כוללות הכנת מפת כתובות, עדכון קישורים וכתובות קנוניות, ובדיקת האתר החדש. גם במעבר מסודר ייתכנו תנודות זמניות בחיפוש. מדריך Google למעבר אתר עם שינוי כתובות.

מסלול פנייה בודקים מתחילתו ועד סופו

בחרו מסלול אמיתי: כניסה למאמר, מעבר לשירות ופתיחת טופס יצירת קשר. בדקו אותו בטלפון, בלי להסתמך על התצוגה במחשב של המעצב. האם ברור על מה לוחצים? האם אפשר לקרוא את הטקסט? האם שדה חובה מוסבר? האם מקבלים הודעת הצלחה ברורה?

בדיקת שליחה בפועל צריכה להיעשות בצורה מתואמת ומורשית, עם סימון ברור שזו בדיקה. לאחריה צריך לוודא שהפנייה אכן נקלטה במערכת או אצל הגורם המתאים. לחיצה על כפתור, הודעת הצלחה בדפדפן ורשומה במערכת הם שלבים שונים.

גם מדידה היא בדיקה נפרדת. אירוע שמופיע בכלי אנליטיקה אינו לבדו הוכחה שפנייה נקלטה, ופנייה שהגיעה אינה הוכחה שנמדדה נכון. להרחבה אפשר לקרוא את המדריך למדידת המרות באתר.

ביום המעבר מגדירים גם מי מטפל בתקלה

לפני העלייה קבעו מי מבצע, מי בודק ומי זמין אם מתגלה בעיה. שמרו גרסה קודמת שאפשר לחזור אליה בהתאם לאופן שבו האתר מנוהל, ותעדו מה כולל גיבוי התוכן. אין טעם לגלות בזמן תקלה שהגיבוי כולל קבצי עיצוב אך לא את התוכן המעודכן.

רשמו אילו תקלות עוצרות השקה. לדוגמה, טופס מרכזי שלא עובד או שירות חשוב שנעלם הם בעיות שונות מריווח לא מושלם בכותרת. ההחלטה מראש עוזרת להימנע מוויכוח תחת לחץ.

מיד אחרי העלייה חזרו על בדיקות מסלולי הכניסה והפנייה באתר הציבורי. תצוגה מקדימה שעברה בדיקה אינה מספיקה כדי לאשר את האתר החי.

אחרי העלייה מפרידים בין תקינות, אינדוקס ותוצאה עסקית

עמוד שמחזיר תגובה תקינה ומציג תוכן עדיין לא בהכרח מופיע בגוגל. ב־Search Console אפשר לבדוק מידע על הגרסה שנמצאת באינדקס ולבצע בדיקה של הכתובת החיה. אלו בדיקות שונות; בדיקה חיה תקינה אינה הבטחה לאינדוקס או למיקום מסוים. הסבר על בדיקת כתובת ב־Search Console.

עקבו גם אחר פניות ותקלות בפועל, לא רק אחר מספר כניסות. אם יש ירידה, בדקו את התקופה, מקור התנועה, שינויי הקמפיינים ואופן המדידה לפני שמייחסים אותה לעיצוב החדש. בלי נתוני בסיס אמינים אפשר לבצע בדיקת תקינות, אבל אי אפשר לטעון שהשדרוג שיפר או פגע בביצועים העסקיים.

שינוי עיצוב או כתובות בתוך אותו אתר אינו סיבה אוטומטית להשתמש בכלי ״שינוי כתובת״ של Google. הכלי מיועד למעברים מסוימים בין דומיינים או תתי־דומיינים, ולא למעבר אחסון ללא שינוי כתובת או לכל שינוי נתיב פנימי. מתי משתמשים בכלי שינוי כתובת.

תבנית עבודה למלאי: מה רושמים בכל שורה?

כדי שרשימת העמודים תהיה כלי עבודה ולא רק ייצוא של כתובות, הגדירו מראש מה כל שורה צריכה לספר. אפשר להתחיל בגיליון משותף שבו מופיעים השדות הבאים: הכתובת הנוכחית, שם העמוד, סוג התוכן, השירות שהוא תומך בו, מי אחראי עליו, ההחלטה לגביו, היעד המתוכנן והבדיקה הנדרשת. לצד אלה הוסיפו עמודת הערות ומקום לקישור לראיה, למשל צילום של רכיב שצריך להישמר.

אין צורך למלא נתוני תנועה שאין לכם. אם לא חוברה מדידה או שאין גישה לדוח המתאים, כתבו ״לא נבדק״. ההבדל בין אפס כניסות לבין נתון חסר חשוב: הראשון הוא תוצאת מדידה בתנאים מסוימים, והשני הוא מגבלה. לא נכון לקבל החלטת הסרה כאילו שני המצבים זהים.

הפרידו גם בין מידע קיים לבין החלטה מתוכננת. העובדה שעמוד מציג היום שירות מסוים אינה אומרת שהעסק ימשיך להציע אותו. סמנו החלטות שדורשות בעל מקצוע או בעל תפקיד, במקום לתת למפתח לנחש. לדוגמה: מנהל השיווק מאשר ניסוח, בעל העסק מאשר שינוי בהיצע, ואחראי התשתית בודק את המימוש.

בסוף שלב המיפוי בחרו קבוצה קטנה של עמודים מייצגים לבדיקה מפורטת: עמוד שירות, מאמר, עמוד עם טופס ועמוד עם קובץ להורדה. זו דרך לגלות בעיות בתהליך ההעברה לפני שחוזרים על אותו תהליך בעשרות עמודים. היא אינה תחליף לבדיקת יתר העמודים לפני העלייה.

דוגמאות למפת מעבר: ארבע החלטות שונות

הדוגמאות הבאות דמיוניות ונועדו להמחיש את שיטת העבודה. הן אינן כתובות של לקוח או הוראות לשינוי באתר מסוים.

עמוד שנשאר: לעסק יש עמוד בנתיב services/consulting שמסביר שירות פעיל. העיצוב משתנה, אבל התוכן והכוונה נשארים. ההחלטה יכולה להיות לשמור את הכתובת ולבדוק שהתוכן המעודכן, הכפתורים והקישורים פועלים בה. אין צורך להמציא כתובת חדשה רק כדי לסמן שהפרויקט התקדם.

עמוד שעובר: מדריך שהיה בנתיב articles/guide מועבר לנתיב blog/guide כחלק ממבנה מאושר. ברשומה מציינים את המקור ואת היעד הסופי, מי אישר את המעבר ואיך נבדק שהקורא מגיע למדריך הנכון. בדיקת ההפניה אינה מסתיימת בכך שהדפדפן הציג עמוד כלשהו.

תכנים שעשויים להתאחד: שני עמודים ישנים מסבירים כמעט את אותו שירות, אבל אחד מהם מכיל תשובות ייחודיות. לפני שמציעים איחוד, מעתיקים למסמך עבודה את ההבדלים המהותיים ובודקים אם יש הצדקה עסקית לעמוד אחד. ההחלטה דורשת אישור, תכנון יעד ושימור המידע השימושי. דמיון בכותרות לבדו אינו בסיס למחיקה.

שירות שכבר אינו מוצע: קודם מאמתים את ההחלטה עם בעל העסק. ייתכן שיש צורך בהסבר ללקוחות קיימים, במסמך תמיכה או בהפניה לשירות חלופי שבאמת מתאים. אם אין חלופה, צריך לבחור טיפול טכני ותוכני מפורש. אל תציגו שירות שאינו קיים רק כדי להשאיר עמוד, ואל תובילו את הקורא לשירות לא קשור בלי הסבר.

הפניות, פרמטרים וקנוניקל: מה צריך לבדוק בנפרד?

אלה שלושה נושאים שנוטים להתערבב, אף שכל אחד מהם עונה על שאלה אחרת. הפניה קובעת לאן המבקר עובר. פרמטרים בכתובת עשויים לשנות מידע או להעביר פרטי מקור. קנוניקל הוא אות שמציין איזו גרסה מועדפת כאשר יש כתובות עם תוכן זהה או דומה.

בבדיקת הפניות בקשו לראות גם את הדרך ולא רק את היעד. בדוגמה דמיונית, כתובת ישנה עשויה לעבור לעמוד ביניים, משם לגרסת HTTPS ורק אז לכתובת הסופית. ברשומת הבדיקה כדאי לשמור את רצף הכתובות ואת קודי התגובה כדי שמי שמתחזק את האתר יוכל להבין מה לתקן. אם קיימת לולאה שחוזרת לאותה כתובת, אין כאן מעבר שהושלם.

באתר שמשתמש בפרמטרים, הגדירו מה המשמעות שלהם לפני שמסירים אותם. פרמטר אחד עשוי לסמן מקור קמפיין, ואחר עשוי לבחור מוצר, שפה או אפשרות בטופס. כלל גורף שמוחק כל מה שמופיע אחרי סימן השאלה עלול לשנות את התוצאה שהמשתמש ציפה לקבל. בדקו תרחישים מייצגים בלי להעתיק לכתובות בדיקה פרטים אישיים או מידע רגיש.

לגבי קנוניקל, Google מסבירה שזהו אות לבחירת גרסה מועדפת ולא פקודה מחייבת. כדאי שהקישורים הפנימיים, מפת האתר וההצהרה בעמוד יהיו עקביים, ושלא יפנו בטעות לכתובת סביבת הפיתוח. הנחיות Google לכתובות קנוניות.

גם תמונות וקבצים הם חלק מהמעבר

לעיתים מעבירים את הטקסט בשלמותו אבל משאירים תמונות או מסמכים בשרת הישן. כל עוד השרת פעיל, העמוד החדש נראה תקין. הבעיה מתגלה רק אחרי שסוגרים את השירות הישן, כשקישורים שהיו תלויים בו מפסיקים לעבוד. לכן בדקו לא רק איך העמוד נראה, אלא גם מהיכן נטענים הנכסים שלו.

צרו רשימה נפרדת לנכסים חשובים: תמונת שירות, קובץ הצעת מידע, קטלוג או מדריך שהלקוח אמור להוריד. לכל נכס רשמו לאיזה עמוד הוא שייך, מי בעל הזכויות, האם הוא עדכני ומהי כתובת היעד שלו. אם הרישיון לתמונה אינו ברור, עצם העובדה שהיא הופיעה באתר הישן אינה הוכחה שמותר להשתמש בה מחדש בכל הקשר.

בבדיקה החזותית הסתכלו על חיתוך התמונה בטלפון, על חדות במסך גדול ועל הקריאות של מידע שמופיע בתוכה. אל תעבירו טקסט חשוב לתמונה בלבד אם הוא צריך להיות קריא, נגיש וניתן לעדכון. הטקסט החלופי צריך לתאר את תפקיד התמונה בהקשר, לא לשמש מקום לרשימת מילות מפתח.

בקבצים להורדה בדקו את הקובץ עצמו, לא רק תגובת שרת מוצלחת. פתחו אותו וודאו שזו הגרסה שהתכוונתם למסור. מסמך שנפתח אבל מציג פרטי קשר ישנים הוא עדיין תקלה עסקית שצריך לטפל בה לפני שמפנים אליו לקוחות.

רשימת יציאה מסביבת הפיתוח

סביבת בדיקה מאפשרת לעבוד בלי לשנות מיד את האתר הציבורי, אבל היא גם עלולה לשמר הגדרות שלא מתאימות להשקה. לקראת המעבר עברו על רשימה ייעודית: כתובות של תמונות וקישורים, פרטי קשר לדוגמה, סימוני תוכן זמני, טפסים שמחוברים ליעד בדיקה ותגיות שנועדו רק לצוות העבודה.

אחד ממקרי הבדיקה החשובים הוא פתיחה של האתר כמשתמש שאינו מחובר. מסך שנראה תקין למנהל האתר עשוי להתנהג אחרת למבקר רגיל. בדקו גם חלון צר, ניווט באמצעות מקלדת, פתיחת התפריט וסגירתו, וקריאה של הודעות שגיאה בטופס. אלו בדיקות שימושיות גם כשאין לכם מעבדה מלאה לבדיקות נגישות, אך הן אינן תחליף לבדיקת נגישות מקצועית כאשר היא נדרשת.

אל תשנו אבטחה או הרשאות כפתרון מהיר כדי לאפשר למישהו לבדוק את האתר. אם נדרשת גישה, הגדירו למי, לאיזו סביבה ולכמה זמן, ופעלו במסלול המאושר. בדומה לכך, אל תשאירו מידע של לקוחות בסביבת ניסוי רק משום שהוא כבר היה זמין באתר הקודם.

בתום הבדיקה בקשו רשימה של פערים פתוחים עם חומרה ואחראי. ״נבדק״ ו״עבר״ אינם אותו סטטוס. אפשר לבדוק רכיב ולגלות שהוא נכשל; אפשר גם לא להצליח לבדוק אותו בגלל חיבור חסר. תיעוד ברור מונע אישור השקה על בסיס רושם כללי.

מסירת האתר: מה צריך להישאר אצל בעל העסק?

לאחר המעבר, בעל העסק צריך לדעת איך להמשיך לעבוד בלי להיות תלוי בזיכרון של מי שבנה את האתר. הכינו מסמך מסירה קצר עם מפת העמודים המעודכנת, רשימת השינויים העיקריים, מיקום ניהול התוכן, תהליך העלאת תמונות והדרך לדווח על תקלה. אין צורך לכלול במסמך הזה סיסמאות או מפתחות גישה.

הגדירו מי רשאי לערוך תוכן, מי בודק לפני פרסום ואיך חוזרים לעריכה קודמת כאשר המערכת תומכת בכך. אם מישהו שאינו טכני עומד לעדכן את האתר, בקשו ממנו לבצע משימה מייצגת בסביבה מתאימה: שינוי פסקה, החלפת תמונה או הוספת קישור. כך מגלים אם המסירה באמת שימושית ולא רק אם התקיימה הדרכה.

רשמו גם מה לא כלול. למשל, האם שינוי מבנה עמוד דורש עבודה נוספת, האם חיבור חיצוני מנוהל אצל ספק אחר, והיכן רואים הודעות על תקלה. הבהירות הזו אינה התחייבות חדשה לשירות; היא דרך לתעד את האחריות שכבר סוכמה ולמנוע הנחות סותרות.

בסיום ההעברה כדאי להחזיק רשימת משימות תחזוקה קטנה עם תדירות שמתאימה לאתר. לא כל עסק צריך ניטור מורכב, אבל חשוב לדעת מי בודק שהטפסים, הקישורים והעדכונים ממשיכים לפעול גם אחרי שסיימו את פרויקט העיצוב.

תכנון חזרה לאחור בלי לאבד פניות חדשות

החזרה לגרסה קודמת נשמעת פשוטה, אבל צריך להגדיר מה בדיוק חוזר. קוד, תוכן, בסיס נתונים וקבצים אינם בהכרח נשמרים באותו גיבוי. אם מאז העלייה נקלטו פניות או בוצעו עריכות, שחזור גורף עלול להחזיר גם את הנתונים למצב מוקדם יותר. לכן תוכנית החזרה צריכה להתייחס למידע החדש, ולא רק למראה האתר.

לפני ההשקה שאלו את הגורם הטכני איך מבודדים את התקלה ואילו חלקים אפשר להחזיר בנפרד. בקשו הסבר בשפה פשוטה: מה נשמר, מה עשוי להשתנות, מה צריך לייצא לפני פעולה ומי מאשר אותה. אל תבצעו שחזור על בסיס הכפתור הזמין ביותר במערכת.

לא כל בעיה מצדיקה נסיגה מלאה. שגיאת תוכן נקודתית יכולה לדרוש תיקון מקומי, בעוד שכשל רחב במסלול הפנייה עשוי להצדיק עצירת ההשקה. ההחלטה תלויה בהיקף ובסיכון, ולכן חשוב שמישהו יהיה אחראי לה ולא רק זמין טכנית לבצע אותה.

לאחר תיקון או שחזור, חזרו על אותו תרחיש שנכשל ושמרו את התוצאה. היעלמות הודעת שגיאה אינה מספיקה אם המשתמש עדיין אינו מגיע ליעד. סגירת תקלה צריכה להישען על התנהגות שנבדקה, יחד עם תיעוד של מגבלות שנותרו.

איך בונים תמונת מצב שאפשר להשוות אליה?

עוד לפני השדרוג, תעדו מה אתם יודעים על האתר ומה לא. שמרו את התקופה שאליה מתייחסים הנתונים, את מקורם ואת הגדרת הפעולה שנמדדת. אם מספר הפניות מגיע ממערכת ניהול ואילו הכניסות מגיעות מכלי אנליטיקה, הציגו אותם כשני מקורות שונים ואל תניחו שכל פנייה משויכת לכניסה שנמדדה.

לאחר העלייה השוו תקופות בעלות הקשר דומה ככל האפשר. שבוע עם חופשה, שינוי בתקציב הפרסום או מבצע אינו בהכרח דומה לשבוע רגיל. באתר עם מעט פניות, שינוי של פנייה אחת או שתיים יכול להיראות גדול באחוזים, בלי להספיק למסקנה יציבה. לכן כדאי להציג גם את המספרים עצמם ולא רק שיעור שינוי.

הכינו יומן קצר של אירועים משמעותיים: מועד השקה, תיקון טופס, החלפת מספר טלפון, שינוי בקמפיין או עדכון בהגדרות המדידה. היומן עוזר לזהות הסברים אפשריים לשינוי, אך הוא לא מוכיח סיבתיות. אם העלייה במספר הפניות התרחשה אחרי העיצוב החדש, זה עדיין לא אומר שהעיצוב לבדו גרם לה.

כאשר אין נתונים אמינים, התחילו מתיעוד איכותני שאפשר לאמת: האם כל השירותים זמינים, האם המסרים ברורים, האם מסלולי הפנייה עובדים והאם לקוחות מצליחים למצוא את המידע שחיפשו. אלו תוצאות בעלות ערך גם בלי לייחס להן מספרי צמיחה שלא נמדדו.

מה כדאי להכין לפגישת השדרוג?

הביאו רשימה של העמודים החשובים, שלוש דוגמאות לדברים שלא עובדים היום ומסלול אחד שלקוח צריך להשלים באתר החדש. אם יש נתונים, צרפו מידע רלוונטי מ־Search Console וממערכת הפניות, בלי לחשוף פרטים אישיים שלא נדרשים לתכנון.

כך אפשר לתכנן אתר חדש סביב מה שהעסק צריך, תוך שמירה על מה שכבר שימושי. רוצים לבחון שדרוג כזה? התחילו בעמוד בניית האתרים של Leadify, ואם מוקד השינוי הוא המבנה והנראות בחיפוש, אפשר להכיר גם את שירות הקידום האורגני.