מיגרציית Shopify ל-headless בלי לאבד URL של מוצרים

במעבר מ-Shopify ל-headless, העיצוב החדש הוא לא החלק המסוכן. הסיכון הוא שכבת ה-URL. כתובות כמו /products/{handle}, /collections/{handle} ו-/pages/{handle} כבר נמצאות בגוגל, באימיילים, בקמפיינים, ב-QR, אצל affiliates וב-bookmarks של לקוחות. אם ה-storefront החדש משנה את המבנה בלי redirect map, התנועה הישנה מגיעה ל-404 או לדף כללי מדי.

הסיכון האמיתי במיגרציה

Shopify נותן מבנה URL צפוי:

/products/blue-shirt
/collections/summer
/pages/shipping

ב-headless storefront, במיוחד עם Next.js, Hydrogen או stack פנימי, הצוותים נוטים לבחור מבנים אחרים:

/shop/blue-shirt
/c/summer
/shipping

המבנה החדש יכול להיות טוב יותר למוצר. אבל ביום ההשקה, הכתובות הישנות עדיין מקבלות תנועה. בישראל זה בולט במיוחד בחנויות שמוכרות דרך שילוב של SEO, Meta ads, Google Shopping, WhatsApp, ניוזלטרים ושיתופי פעולה עם יוצרים. לא כל הלינקים נמצאים רק באתר.

ללא redirect map נוצרות שלוש בעיות:

1. 404 על מוצרים וקטגוריות: Googlebot ומשתמשים מגיעים לכתובות שכבר לא קיימות.
2. אובדן הקשר מסחרי: מוצר שנגמר צריך להגיע לחלופה או collection מתאים, לא תמיד לדף הבית.
3. שבירת attribution: קישורי campaign עם UTM או coupon מגיעים ליעד בלי הפרמטרים שהצוות צריך למדידה.

לפני שמגדירים כלל אחד: אספו את ה-URL

אל תבנו redirect map מתוך תחושת בטן. התחילו מרשימות קיימות:

• export מ-Shopify Admin של products ו-collections.
• sitemap.xml של החנות הישנה.
• דפי landing מתוך Google Search Console.
• landing pages עם הכנסות או sessions מתוך analytics.
• URLs פעילים מקמפיינים ב-Google, Meta, LinkedIn או affiliates.
• קישורים מ-email, SMS ו-WhatsApp templates.
• דפי support, FAQ ו-policy שקיבלו backlinks.

טבלת העבודה צריכה לכלול לפחות:

old_url,new_url,type,priority,owner,preserve_query,notes
https://old-brand.example/products/blue-shirt,https://new-brand.example/shop/blue-shirt,301,high,ecommerce,true,best seller
https://old-brand.example/collections/summer,https://new-brand.example/c/summer,301,high,seo,true,collection page

שימו לב לדומיינים: בדוגמאות ציבוריות השתמשו ב-old-brand.example ו-new-brand.example, לא בדומיין מקומי אמיתי שאפשר לרשום.

איך לבנות redirect map

לא כל כתובת צריכה כלל ידני. לרוב משלבים pattern rules עם חריגים.

שינוי prefix פשוט

Old: /products/blue-shirt
New: /shop/blue-shirt

כלל:

{
  "source": "^/products/(.*)$",
  "destination": "/shop/$1",
  "type": 301
}

שינוי collection

Old: /collections/summer
New: /c/summer

כלל:

{
  "source": "^/collections/(.*)$",
  "destination": "/c/$1",
  "type": 301
}

מוצר שהוסר

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

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

שמירת UTM ו-query

קישור כזה:

https://old-brand.example/products/blue-shirt?utm_source=newsletter&utm_campaign=spring

צריך להגיע ל:

https://new-brand.example/shop/blue-shirt?utm_source=newsletter&utm_campaign=spring

אם ה-redirect מוחק query parameters, crawl טכני יכול להיראות נקי בזמן שהדוחות של marketing נשברים.

איפה כדאי להריץ את ההפניות

אפשר להגדיר redirects באפליקציית headless עצמה, אבל זה קושר את שכבת המיגרציה ל-deploy של frontend. במפה גדולה יותר, עדיף לעיתים לנהל את ההפניות בשכבה ייעודית ברמת ה-Edge:

• redirect map מחוץ לקוד ה-storefront.
• import של CSV או rules.
• בדיקה לפני DNS cutover.
• שינוי חריג בלי להוציא גרסת frontend.
• rollback מהיר אם יעד מסוים מתנהג לא נכון.

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

בדיקות launch

לפני cutover, בדקו את ה-redirect map בסביבה שמדמה production:

1. דוגמאות מכל template: מוצר, collection, page, blog, policy.
2. high-value URLs: דפים עם clicks, revenue, backlinks או קמפיינים פעילים.
3. query preservation: UTM, coupon, affiliate IDs.
4. chain check: אין HTTP -> HTTPS -> old host -> new host -> final path כאשר אפשר להגיע ישירות.
5. destination quality: מוצר שהוסר לא נזרק לדף הבית בלי סיבה.
6. mobile paths: קישורים מ-WhatsApp ו-in-app browsers.
7. rollback: האם אפשר לכבות קבוצת כללים בלי להוריד את האתר.

אחרי ההשקה, עקבו אחרי:

• 404 לפי path.
• redirect chains.
• clicks שמגיעים מדומיינים ישנים.
• דפי מוצר עם drop חריג בתנועה.
• קמפיינים שבהם UTM נעלם.
• logs של endpoints ישנים אם יש integration.

טעויות שכדאי למנוע

redirect map שנבנה רק מ-Shopify export

Shopify יודע על מוצרים ו-collections, אבל לא תמיד על URL שקיבלו backlinks, פרמטרים, קיצורים או קישורי campaign.

הפניית כל מוצר חסר לדף הבית

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

שכחת UTM

בחנויות DTC, UTM ו-affiliate params יכולים להיות ההבדל בין launch שנראה מוצלח לבין דוחות בלתי שמישים.

ערבוב redirects זמניים וקבועים

מוצר שעבר למבנה חדש מקבל 301. קמפיין זמני או landing page עונתי יכול לקבל 302. אל תבחרו status code אחד לכל הטבלה.

איך UrlEdge עוזר בפרויקט כזה

ב-UrlEdge אפשר לנהל את המיגרציה כ-map ולא כערימת תיקונים:

• ייבוא bulk של CSV.
• regex rules למבנים צפויים.
• שמירת path ו-query כאשר צריך.
• בדיקת redirects לפני פרסום.
• ניטור broken links אחרי cutover.
• rollback לכללים בעייתיים.

התחילו ב-Bulk URL management, והשלימו עם Broken link monitor אחרי העלייה.

FAQ

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

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

מה עושים עם מוצר שאזל לצמיתות?

בחרו יעד מועיל: מוצר מחליף, collection או דף תמיכה. homepage הוא fallback חלש אם אין הקשר.

האם לשמור UTM בכל מקרה?

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

מתי מפרסמים את ה-redirect map?

לפני שה-storefront החדש מקבל production traffic. המפה צריכה להיות מוכנה, מיובאת ונבדקת בסביבת staging.