מיגרציית אתר איקומרס בלי לאבד SEO: תכנית מעבר מ־WooCommerce ל־Shopify

למה מיגרציה פוגעת ב־SEO גם כשהאתר החדש נראה טוב?

מבחינת צוות העיצוב, מיגרציה מוצלחת היא אתר חדש שעובד. מבחינת מנוע החיפוש, זו מערכת של כתובות, קישורים, תוכן, איתותים ונתונים שצריכה להמשיך לייצג את אותן ישויות ואת אותן כוונות. אם המוצר שהיה ב־/product/red-shoe/ עובר ל־/products/red-shoe, צריך ללמד את Google שהכתובת החדשה היא ההמשך של הישנה. אם קטגוריה נעלמת, צריך להחליט אם היא אוחדה, הוחלפה, הופסקה או פשוט נשכחה.

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

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

שלושה סוגי מעבר שנראים דומים, אבל דורשים QA שונה

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

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

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

ארבעת פנקסי המעבר שצריכים להתקיים לפני שינוי DNS

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

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

איך בונים URL mapping שאפשר לסמוך עליו?

מתחילים מרשימת URLים רחבה, לא רק מ־sitemap. משלבים sitemap XML, נתוני Search Console, Analytics, קישורים פנימיים, קישורים חיצוניים, דוחות Merchant Center, קטלוג פעיל וייצוא מהפלטפורמה הישנה. URL שלא קיבל קליק בחודש האחרון עדיין יכול להיות קטגוריה חשובה, עמוד מוצר עונתי או כתובת שמקבלת קישורים חיצוניים.

לכל כתובת מגדירים אחת מארבע החלטות:

1. מקבילה ישירה: אותו מוצר, קטגוריה או מדריך בכתובת חדשה. מפנים ב־301 או 308 ישירות ליעד.
2. איחוד: כמה כתובות ישנות אוחדו לעמוד חדש שמכסה את אותה כוונה. מפנים ליעד הקרוב ביותר, לא לדף הבית.
3. הוצאה: אין מוצר, חלופה או כוונה שמצדיקים המשך. מחזירים 404 או 410 ומסירים קישורים פנימיים מיותרים.
4. חקירה: הנתונים אינם מספיקים כדי להחליט. לא מפנים לפני שמבינים את התפקיד העסקי והחיפוש של הכתובת.

הפניה גורפת של מאות URLים לדף הבית אינה פתרון. Google מזהירה שהפניות לא רלוונטיות עלולות להיתפס כ־soft 404, והן גם יוצרות חוויה גרועה למי שחיפש מוצר מסוים. בנוסף, יש להימנע משרשראות: הכתובת הישנה צריכה להגיע ישירות ליעד הסופי.

ב־Shopify אפשר לייבא ולייצא הפניות באמצעות CSV. כדאי להכין את הקובץ לפני העברת הדומיין, משום שלאחר המעבר קשה יותר לזהות אילו כתובות ישנות עדיין מקבלות תנועה.

מתי מפנים, מתי משאירים 404 ומתי לא עושים כלום?

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

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

סביבת staging שאינה ניתנת לסריקה מאפשרת לבדוק את האתר בלי ליצור אינדוקס מוקדם. לפני ההשקה עוברים על רשימת URLים מדגמית וגם על סריקה מלאה של סביבת הבדיקה.

• כל URL חשוב מחזיר 200 ביעד החדש, וה־URL הישן מחזיר הפניה ישירה.
• אין noindex, חסימת robots או canonical שמצביע בטעות לסביבת staging.
• כותרת, H1, תיאור, תוכן, breadcrumbs וקישורים פנימיים תואמים ליעד.
• עמוד מוצר מציג את הווריאנט, המחיר, המלאי וה־Product structured data הנכונים.
• קישורים פנימיים אינם מפנים לכתובות הישנות, ומפת האתר מכילה רק כתובות קנוניות חדשות.
• אירועי view_item, add_to_cart, begin_checkout ו־purchase נשלחים פעם אחת ובמבנה הנכון.
• תהליך התשלום, משלוח, החזרות, קופונים, מיילים ושחזור סיסמה נבדקו במובייל ובדסקטופ.

אם המעבר כולל גם החלפת דומיין, מוסיפים אימות נכסים נפרד ב־Search Console ו־Change of Address כאשר הוא רלוונטי. אם הדומיין נשאר זהה והוחלפה רק תשתית, אין להשתמש ב־Change of Address; עדיין צריך לעקוב אחרי crawl, index ו־performance.

תכנית חזרה אינה כפתור קסם

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

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

יום ההשקה: סדר פעולות שמצמצם סיכון

1. מקפיאים שינויים גדולים בקטלוג ובתבנית, מגבים את המקור ומגדירים חלון חזרה.
2. מעלים את האתר החדש ומוודאים שהדומיין מצביע לגרסה שנבדקה.
3. מפעילים את הפניות, בודקים כמה URLים ישנים מכל סוג ומוודאים שאין לולאות או שרשראות.
4. מעדכנים canonical, קישורים פנימיים, sitemap, hreflang ופידים.
5. בודקים את דף הבית, קטגוריה רווחית, מוצר עם וריאנטים, מוצר אזל, סל וקופה.
6. פותחים את Search Console ואת דוחות הפלטפורמה ומתחילים תיעוד יומי של שגיאות וחריגות.

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

איך מבדילים בין תנודה טבעית לבין תקלה במיגרציה?

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

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

דוגמה היפותטית: 1,200 מוצרים שעוברים ל־Shopify

נניח חנות עם 1,200 מוצרים, 48 קטגוריות ו־7,000 URLים שמופיעים בסריקה, ב־sitemap או בדוחות חיצוניים. במעבר נמצאו 860 מוצרים עם כתובת מקבילה, 190 מוצרים שאוחדו לקטגוריות או מוצרים אחרים, 90 מוצרים שהופסקו ו־60 כתובות שעדיין דורשות החלטה.

המספר החשוב אינו “כמה הפניות יצרנו”, אלא האם 860 הכתובות המקבילות מפנות ישירות למוצר הנכון, האם 190 האיחודים באמת עונים על אותה כוונה, והאם 60 הכתובות הלא מוכרעות נבדקו מול קישורים חיצוניים, חשיפות, מלאי והיסטוריית מכירות. אם מפנים את כל 250 הכתובות הלא־ישירות לדף הבית, מתקבלת מערכת שנראית מסודרת בגיליון אך אינה אמינה למשתמש.

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

מתי לא נכון להתחיל מיגרציה?

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

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

סדר עבודה מעשי למעבר בטוח

הסדר שאני ממליץ עליו הוא: (1) להגדיר מה נשאר זהה ומה משתנה, (2) לייצא ולנקות את ארבעת הפנקסים, (3) לבנות סביבת בדיקה, (4) ליישם URL mapping והפניות, (5) לבדוק קטלוג, נתוני מוצר וקופה, (6) לסרוק את האתר החדש, (7) להפעיל מדידה ופידים, (8) לבצע cutover מתועד, (9) לעקוב 24 שעות, 7 ימים ו־30 ימים, ו־(10) לטפל קודם בתקלות מערכתיות ורק אחר כך לשפר תוכן.

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

שאלות נפוצות

האם חייבים לשמור את אותן כתובות?

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

האם 301 מעביר את כל הכוח של הכתובת הישנה?

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

כמה זמן להשאיר הפניות?

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

האם מיגרציה מ־WooCommerce ל־Shopify פוגעת ב־SEO?

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

מה עושים אם התנועה ירדה אחרי המעבר?

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