מעבר בין מערכות איקומרס: מה קורה למוצרים, מלאי, לקוחות, SEO והזמנות?

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

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

מה באמת עובר כשמחליפים מערכת איקומרס?

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

רכיב	מה צריך לבדוק	סיכון נפוץ
מוצרים	מק”טים, וריאציות, מאפיינים, מחירים, תמונות ותיאורים	שדות שלא קיימים באותו מבנה במערכת החדשה
מלאי	מהי מערכת המקור למלאי ומתי מתבצע העדכון האחרון	עלייה לאוויר עם יתרות ישנות
לקוחות	פרטי חשבון, כתובות, העדפות ושדות מיוחדים	חשבונות כפולים או צורך ביצירת סיסמה חדשה
הזמנות	היסטוריה, הזמנות פתוחות, סטטוסים והחזרות	מידע שחסר לשירות לקוחות או לתפעול
SEO	כתובות, Meta Tags, תוכן, Canonical והפניות	עמודים קיימים שמתחילים להחזיר 404
אינטגרציות	ERP, קופה, סליקה, חשבוניות, משלוחים ו-CRM	החנות עולה אבל תהליך העבודה מאחוריה לא עובד
שיווק ומדידה	GA4, פיקסלים, GTM, פידים ואירועי המרה	מכירות מתבצעות אבל המדידה או הקמפיינים נפגעים

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

מוצרים: ייבוא קטלוג הוא רק תחילת הבדיקה

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

אל תסתפקו בשם מוצר ומחיר. עברו גם על:

• מק”ט ומזהים: האם המזהים הקיימים נשמרים והאם מערכות אחרות מסתמכות עליהם?
• וריאציות: צבע, מידה, נפח או כל וריאציה אחרת צריכה להתחבר למוצר הנכון.
• מאפיינים: מותג, חומר, סוג, סדרה ושדות שמשמשים לסינון או לחיפוש.
• תמונות: לא רק התמונה הראשית, אלא גם גלריות וסדר התמונות.
• מחירים: מחיר רגיל, מבצע, מחירונים מיוחדים או מחירים לפי לקוח.
• תוכן: תיאור קצר, תיאור מלא, הוראות, מפרט ומידע נוסף.
• SEO: כתובת קיימת, Title, Description ונתונים נוספים שחשוב לשמר.

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

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

בחנות פעילה, מלאי משתנה כל הזמן. לכן מעבר של “17 יחידות” מקובץ אחד למערכת אחרת יכול להיות נכון ברגע הייצוא ושגוי כמה שעות מאוחר יותר.

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

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

לקוחות: האם החשבונות והסיסמאות יעברו?

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

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

לכן לפני מעבר שאלו במפורש:

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

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

הזמנות: האם צריך להעביר את כל ההיסטוריה?

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

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

כדאי לחלק את ההזמנות לשלוש קבוצות:

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

העיקרון הוא פשוט: אל תעבירו מידע רק מפני שאפשר. העבירו מידע שיש לו תפקיד ברור לאחר המעבר.

ומה קורה להזמנות שנכנסות בזמן המעבר?

זו אחת הנקודות שקל לפספס. נניח שהייצוא האחרון מהחנות הישנה בוצע בשעה 10:00, אבל החנות ממשיכה למכור עד 18:00. מה קורה לכל ההזמנות, הלקוחות ושינויי המלאי שנוצרו באותן שמונה שעות?

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

בתהליך כזה יכולים להיות כמה שלבים:

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

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

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

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

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

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

בין היתר, צריך לבדוק:

• מיפוי כתובות: לאיזה עמוד חדש מגיע כל URL חשוב מהאתר הישן?
• 301 או 308: האם ההפניות הקבועות אכן מחזירות את הסטטוס הנכון ומגיעות ישירות ליעד?
• Canonical: האם העמודים החדשים מצביעים על הכתובות החדשות שלהם?
• קישורים פנימיים: האם האתר החדש עדיין מקשר לכתובות ישנות?
• Sitemap: האם מפת האתר החדשה מכילה את הכתובות שרוצים ש-Google תסרוק?
• Noindex ו-Robots: האם הגבלות שהיו בסביבת הבדיקות הוסרו לפני ההשקה?
• Meta Tags ותוכן: האם כותרות ותיאורים חשובים נשמרו?
• Search Console: האם עוקבים אחרי אינדוקס, 404 ותנועה לאחר העלייה לאוויר?

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

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

לא רק SEO: מה קורה ל-GA4, פיקסלים ופידים?

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

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

• GA4 ואירועי איקומרס
• Google Tag Manager
• Google Ads והמרות
• Meta Pixel ואירועי רכישה
• Google Merchant Center ופיד מוצרים
• קטלוג מוצרים ב-Meta
• מערכות דיוור ואוטומציות
• כלי Analytics, Heatmaps או מערכות צד שלישי

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

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

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

עברו אחרי הזמנה אחת ושאלו מה אמור לקרות:

1. הלקוח מבצע הזמנה.
2. התשלום מאושר.
3. ההזמנה נוצרת בחנות.
4. המלאי מתעדכן.
5. המידע עובר ל-ERP או לקופה, אם הם מנהלים את התהליך.
6. המסמך המתאים מופק.
7. פרטי ההזמנה מגיעים למערכת השילוח.
8. הלקוח והצוות מקבלים את העדכונים הנדרשים.

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

העיצוב בדרך כלל לא “עובר” כמו קטלוג

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

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

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

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

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

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

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

כלומר, שינוי קטגוריות הוא החלטת UX ו-SEO, לא רק משימת ייבוא.

12 שאלות שצריך לשאול את הספק החדש לפני שחותמים

1. אילו נתוני מוצרים ניתן להעביר מהמערכת הקיימת?
2. איך מטפלים בווריאציות, מאפיינים ושדות מיוחדים?
3. אילו נתוני לקוחות עוברים ומה קורה לחשבונות ולסיסמאות?
4. האם ניתן להעביר הזמנות היסטוריות ואילו חלקים שלהן נשמרים?
5. איך מטפלים בהזמנות פתוחות ביום המעבר?
6. מהי מערכת המקור למלאי ואיך מתבצע העדכון האחרון לפני ההשקה?
7. מי מכין את מפת הכתובות והפניות ה-301?
8. מי בודק Meta Tags, Canonical, Sitemap והגדרות אינדוקס