צ׳קליסט להגירת אתר: לשמור על הדירוגים, המייל והמדידה

להגדיר מה בדיוק משתנה

„הגירה” היא שם לכמה מהלכים שונים, ומנועי חיפוש מתייחסים לכל אחד מהם אחרת. לפני כל תכנון, רשמו אילו מאלה רלוונטיים:

• החלפת דומיין, למשל מ-example.co.il ל-example.com.
• החלפת פלטפורמה, למשל מ-WordPress ל-Next.js או מפלטפורמת חנות אחת לאחרת.
• שינוי מבנה כתובות: נתיבים חדשים, רמות קטגוריה חדשות, הסרת תיקיות שפה.
• החלפת אחסון או שרת, כשהדומיין והכתובות נשארים כמו שהם.
• שינוי פרוטוקול או מארח: מ-HTTP ל-HTTPS, או מ-www לכתובת בלי www.
• איחוד כמה אתרים לאתר אחד, או פיצול אתר אחד לכמה.

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

למפות כל כתובת שחשובה

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

• סריקה של האתר הנוכחי. ‏Screaming Frog,‏ Sitebulb או סורק דומה מחזירים כל עמוד מקושר עם קוד הסטטוס, ה-canonical והכותרת שלו.
• ייצוא מ-Search Console. דוח הדפים מראה אילו עמודים Google הכניס לאינדקס, ודוח הביצועים נותן קליקים והופעות לכל עמוד, עד 16 חודשים אחורה. הממשק מייצא עד 1,000 שורות בלבד, ולכן באתרים גדולים משכו את הנתונים דרך ה-API של Search Console, המחבר של Looker Studio או הייצוא המרוכז ל-BigQuery.
• ייצוא דפי נחיתה מהאנליטיקס. שנה של דפי נחיתה ב-GA4 תופסת עמודי קמפיין ועמודים ישנים שכבר לא מקושרים מהתפריט.
• רשימת עמודים עם קישורים נכנסים. דוח הקישורים ב-Search Console, או כלי לניתוח קישורים, מראה לאילו כתובות אתרים אחרים מפנים.
• קבצים ומדיה. גם קובצי PDF, תמונות והורדות שמקבלים תנועה או קישורים צריכים הפניות.

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

לבנות את מפת ה-301

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

• הפנו לעמוד המקביל. הפניה של הרבה עמודים לדף הבית נחשבת בדרך כלל ל-soft 404, והדירוגים הישנים הולכים לאיבוד.
• קפיצה אחת בלבד. עדכנו הפניות קיימות כך שכתובות ישנות יפנו ישר לכתובת הסופית, בלי שרשרת דרך כתובת ביניים.
• בחרו צורה אחת ללוכסן בסוף הכתובת, לאותיות גדולות וקטנות ולמארח www, והפנו אליה כל וריאציה אחרת.
• עמודים בלי מקבילה ובלי ערך צריכים להחזיר 404 או 410, לא להפנות למשהו לא קשור.
• הגדירו הפניות בשרת או ב-edge‏ (Nginx,‏ .htaccess, חוקי Cloudflare, הגדרות הפריימוורק), אף פעם לא ב-JavaScript או ב-meta refresh.

להשאיר את סביבת הבדיקות מחוץ לאינדקס

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

• הגנו על סביבת הבדיקות בסיסמה (HTTP basic authentication) או ברשימת כתובות IP מורשות. זו החסימה האמינה היחידה.
• הוסיפו כותרת X-Robots-Tag: noindex כשכבה שנייה. ‏Disallow ב-robots.txt לבדו לא מונע אינדוקס של כתובות שמקושרות ממקום אחר.
• הכניסו את הסרת כל החסימות לצ׳קליסט ההשקה. אתר חי שעדיין שולח noindex או „Disallow: /” הוא אחת הטעויות הנפוצות ביותר ביום ההשקה.

X-Robots-Tag: noindex

User-agent: *
Disallow: /

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

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

• תוכן. כותרות, תיאורי מטא, H1 וטקסט גוף בעמודים המובילים. תוכן שנמחק לוקח איתו את הדירוגים שהוא הביא.
• תגיות canonical. מצביעות על הכתובות החדשות באתר החי, לא על סביבת הבדיקות ולא על הדומיין הישן.
• ‏hreflang. כל גרסת שפה מפנה לעצמה ולכל הגרסאות האחרות, בכתובות מלאות על הדומיין החדש. באתרים בעברית, ערבית ואנגלית זה נשבר בקלות.
• נתונים מובנים. ‏Organization,‏ Product,‏ BreadcrumbList וכל השאר עוברים לאתר החדש; בדקו אותם ב-Rich Results Test.
• קישורים פנימיים. תפריטים, פוטר וקישורים בתוך הטקסט משתמשים בכתובות הסופיות, כך שהאתר לא תלוי בהפניות של עצמו.
• מפת אתר XML. כוללת רק כתובות סופיות שניתנות לאינדוקס ומחזירות 200.

להכין DNS ו-SSL לפני המעבר

• להשיג גישה מוקדם. דעו מי שולט ברשם הדומיין ובספק ה-DNS, וודאו שיש פרטי כניסה עובדים הרבה לפני שבוע ההשקה.
• לייצא את ה-zone. שמרו עותק מלא של כל רשומות ה-DNS הנוכחיות לפני שנוגעים במשהו.
• מחליפים ספק DNS. אם ה-zone עצמו עובר לספק DNS חדש, שחזרו שם את ה-zone המלא, השוו רשומה מול רשומה, והחליפו את שרתי השמות (nameservers) אצל הרשם כמה ימים לפני המעבר. לרשומות ה-NS ב-zone ההורה יש לרוב TTL של 48 שעות שאי אפשר להוריד. אחר כך בצעו את שינוי האתר כשינוי רשומה רגיל.
• להוריד TTL. הורידו את ה-TTL של הרשומות שישתנו לכ-300 שניות, לפחות פרק זמן אחד של ה-TTL הישן לפני המעבר (בדרך כלל 24 עד 48 שעות), כדי שהשינוי יתפשט מהר ושאפשר יהיה גם לחזור ממנו מהר.
• להנפיק תעודות קודם. בשרת החדש או ב-CDN צריכות להיות תעודות תקפות לכל שם מארח, עם www ובלי, לפני שהתנועה מגיעה. השתמשו באימות DNS או בתעודה של ה-CDN, כדי ש-HTTPS יעבוד מהבקשה הראשונה.
• לבדוק HSTS. אם האתר הישן שלח כותרת HSTS, דפדפנים יסרבו ל-HTTP רגיל במארחים שהיא חלה עליהם. כל אחד מהם צריך HTTPS עובד בשרת החדש.

לא לגעת במייל

העברת אתר לא אמורה להשפיע על המייל, אבל שינויי DNS שוברים אותו לעיתים קרובות, בדרך כלל כשה-zone עובר לספק DNS חדש ומשחזרים בו רק את רשומות האתר.

• העתיקו את רשומות ה-MX בדיוק, כולל העדיפויות.
• העתיקו את רשומות SPF,‏ DKIM ו-DMARC‏ (TXT ו-CNAME). בלי SPF או DKIM, מיילים נופלים לספאם או נדחים.
• השאירו רשומות TXT של אימות עבור Google Workspace,‏ Microsoft 365,‏ Meta ושירותים אחרים.
• אם השרת החדש שולח מיילים (התראות מטפסים, אישורי הזמנה), שלחו אותם דרך שירות SMTP מאומת, הגדירו חתימת DKIM לשירות הזה והוסיפו אותו לרשומת ה-SPF. ‏SPF מרשה לכל היותר 10 בדיקות DNS, אז בדקו את הרשומה אחרי כל include חדש.
• אחרי המעבר, שלחו הודעות בדיקה ל-Gmail ול-Outlook ובדקו בכותרות שההודעה עברה SPF,‏ DKIM ו-DMARC.

לאמת טפסים, מדידה והמרות

אתר יכול להיראות מושלם ולא לדווח כלום. בדקו את מה שהעסק מודד, בסביבת הבדיקות ושוב ביום ההשקה.

• כל טופס נשלח, ההתראה מגיעה, והליד מגיע ל-CRM או לאן שהוא אמור להגיע.
• תג GA4 או קונטיינר GTM נמצאים בכל תבנית, עם אותו מזהה מדידה, והאירועים המרכזיים נורים. בדקו ב-Realtime או ב-DebugView.
• המרות Google Ads והפיקסל של Meta נורים בעמודים הנכונים, ובאנר ההסכמה עדיין שולט בהם.
• בחנויות: הזמנת בדיקה מלאה דרך הקופה, עם כתובות ה-callback של סליקת האשראי מעודכנות לדומיין החדש.
• אינטגרציות עם כתובות קבועות בקוד ממשיכות לעבוד: webhooks, ‏callbacks של API וכתובות הפניה של OAuth.

יום ההשקה

• להקפיא או לסנכרן תוכן. עצרו עריכות באתר הישן, או תכננו סנכרון אחרון. בחנויות, הזמנות ולקוחות מסנכרנים אחרונים.
• גיבוי טרי. קבצים ומסד נתונים של האתר הישן, במקום שאפשר לשחזר ממנו מהר.
• להחליף DNS. אחר כך ודאו שהשרת החדש עונה מכמה רשתות שונות.
• להסיר את חסימות סביבת הבדיקות. כותרות noindex, חוקים ב-robots.txt וההגנה בסיסמה.
• לבדוק את מפת ההפניות. הריצו את כל רשימת הכתובות הישנות דרך סורק: כל אחת מחזירה 301 יחיד לעמוד שמחזיר 200.
• להגיש את מפת האתר. הגישו אותה ב-Search Console. בהחלפת דומיין, אמתו את שני הנכסים והשתמשו בכלי שינוי הכתובת (Change of Address).
• להשאיר את השרת הישן פעיל. השאירו אותו פעיל עד שה-DNS יתעדכן בכל מקום ושום תנועה כבר לא תגיע אליו.

השבועות שאחרי ההשקה

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

• ב-Search Console, עקבו בדוח הדפים אחרי „לא נמצא (404)” ו„דף עם הפניה”, ואחרי מספר הכתובות החדשות שנכנסו לאינדקס.
• בדקו ביומני השרת או ב-Cloudflare אילו 404 מקבלים מבקרים אמיתיים ובוטים, והוסיפו הפניות לכל מה שיש לו תנועה או קישורים.
• השוו תנועה אורגנית לכל דף נחיתה מול רשימת המיפוי, לא רק את הסך הכולל של האתר.
• עקבו אחרי Core Web Vitals וזמני התגובה של השרת בסביבה החדשה.
• השאירו את ההפניות לתמיד. Google ממליצה על שנה לפחות, וקישורים מאתרים אחרים מפנים לכתובות הישנות הרבה יותר זמן.

איפה אנחנו נכנסים

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

• SEOSEO טכני, נתונים מובנים ונראוּת
• פיתוח אתריםאתרי תדמית, פורטלים ומנועי הזמנות
• אתרים מנוהליםעדכונים, גיבויים, תיקונים ותמיכה