מעבר מ-CS-Cart ל-1С-Битрикс: היכן אובדים נתונים ו-SEO
העברת חנות מ-CS-Cart ל-1С-Битрикс שוברת לא את המנוע, אלא את הקשרים בין הישויות: כתובות, מאפייני מוצרים ומלאי. עץ המדורים, תבניות הקישורים ומבנה הקטלוג בנויים אחרת בכל פלטפורמה, ולכן ייצוא ישיר של מסד הנתונים משאיר חלק מהחנות לא פעיל.
הפער הראשון — כתובות. ב-CS-Cart כתובת ידידותית נבנית מעץ הקטגוריות וממק"ט, וב-1С-Битрикс — מקודים סימבוליים של מדורים.
בלי מפת הפניות 301, קישורים ישנים מחזירים 404, והמשקל הצבור של הקישורים הולך לאיבוד: קישורים שבורים אחרי ההעברה נקלטים בפאנל למנהלי אתרים ביממה הראשונה של סריקה.
השני — מאפייני מוצרים. המאפיינים שב-CS-Cart ישבו כמערכת אחת, ב-1С-Битрикс מתפצלים בין מאפייני הקטלוג להצעות המסחר: מידות, צבעים, תצורות. בלי מטריצת התאמה, המסננים מאבדים חלק מהפריטים, וכרטיסי המוצר חוזרים לתוצאות החיפוש בלי כותרות ותיאורים.
השלישי — חוסר סנכרון מלאי. כל עוד החלפת הנתונים עם מערכת החשבונאות לא מוגדרת, האתר מציג זמינות לפי תמונת מצב מיושנת, ולקוח מבצע הזמנה על מוצר שאינו במלאי. במקביל נפגעת הנוכחות בתוצאות החיפוש: כפילויות של עימוד ומסננים בלי כתובות קנוניות, ומפת אתר עם קישורים ישנים.
הפערים מתגלים לא ביום ההשקה, אלא בשבוע השני-שלישי, כשמנוע החיפוש סורק את האתר החדש. לכן ההגירה בנויה סביב מפת כתובות, מטריצת התאמה של מאפיינים ותקנון החלפת מלאי — נסביר איך לסגור את זה לפני החלפת הדומיין.
האפקט של המעבר: מהירות הקטלוג, הזמנות ותפקידים
מהירות הקטלוג, ניהול הזמנות אחיד ושחזור צפוי — אלה לא הבטחות ש"יהיה טוב יותר", אלא פרמטרים שאנחנו מתעדים בתחילת העבודה ובודקים אחרי ההעברה. להלן ארבעה אפקטים שהלקוח רואה בשבועות הראשונים לעבודה על הפלטפורמה החדשה.
הקטלוג עומד בזמני תגובה על מדגמים גדולים
מדורים, מאפיינים והצעות מסחר מועברים כך שהמסננים והמיון יעבדו לפי אינדקסים, ולא בסריקה מלאה. במדגם של עשרות אלפי פריטים, רשימת הקטגוריה מוחזרת בשברירי שנייה במקום שניות — זה ההבדל בין עיון לנטישה. מטמון הקטלוג מוגדר כך שייצוא מחירים ומלאי לא מאפס אותו כולו.
ההזמנות מתכנסות למעגל אחד
הרשמה, תשלום וסטטוסים מפסיקים לחיות בנפרד ממערכת המלאי: ההזמנה נוצרת באתר ומיד נראית במערכת החשבונאות עם אותם פריטים ומחירים. חלק ההזמנות שעוברות בלי תיקון ידני של מנהל עולה, ומספר אי-ההתאמות במלאי ופניות חוזרות בגלל עגלה נטושה קטן.
השחזור עומד בתקנון
גיבוי מחולק לרמות — קבצים, מסד נתונים, תצורה — עם בדיקת שלמות הגיבוי, ולא רק עצם יצירתו. זמן השחזור אחרי תקלה מתקצר משעות לעשרות דקות, והחזרה למצב הקודם מבוצעת לפי תרחיש מתורגל, ולא באופן מאולתר.
נעלם סוג התקלות שנמשך שנים
בפלטפורמה הישנה, תקלות נגרמו מהתאמות של הרחבות ועדכונים ששברו תאימות. אחרי המעבר, הלוגיקה יושבת על ליבת הפלטפורמה עם נקודות הרחבה צפויות, ולכן עדכונים מותקנים בלי לעצור את החנות. בדיוק סוג התקלות שנעלם היה לרוב סעיף עלויות נסתר בתחזוקה.
אפשרויות מעבר: חד-פעמי, מדורג, מקביל
מצב המעבר נבחר לפי שני פרמטרים: עד כמה הקטלוג קשור למערכת החשבונאות וכמה שעות השבתה של הוויטרינה מותרות. הצעד הראשון משותף לכל האפשרויות — סביבת בדיקה עם עותק של מסד הנתונים, המדיה ומבנה הכתובות הנוכחי, שבה מתרגלים העברת קטלוג, מאפיינים והצעות מסחר.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| העברה חד-פעמית | קטלוג קטן, מחוץ לעונה, יש חלון השבתה | הוויטרינה לא זמינה ברגע ההחלפה; שגיאות מתקנים כבר באתר הפעיל |
| מעבר מדורג | הקטלוג קשור ל-1С, נדרש שליטה בכל גל | זמן ארוך יותר; חלק מהתקופה שתי מערכות עובדות עם סנכרון |
| מקביל, בלי עצירת מכירות | תנועה גבוהה או עונה, אסור לאבד הזמנות | מורכב יותר: מעגל כפול לקליטת הזמנות, סנכרון מלאי עד להחלפה |
מעבר בלי עצירת מכירות מבוסס על מעגל כפול: ההזמנות ממשיכות להתקבל בוויטרינה הישנה, ומועברות ל-1С-Битрикс במנות, המלאי מותאם עד ההחלפה עצמה. בסביבת הבדיקה בודקים מראש את כללי ההפניות ומפת הכתובות — אחרת התנועה האורגנית המצטברת הולכת ל-404 ביום הראשון.
אפשרות מדורגת נבחרת כשהקטלוג גדול ותלוי במערכת החשבונאות: מדורים, קבוצות והצעות מסחר מועברים בגלים, אחרי כל גל משווים מחירים, מלאי ושיוך תמונות. המשמעות של מצב כזה — לוח זמנים ארוך יותר וצורך לתחזק את שתי המערכות במקביל.
העברה חד-פעמית נשארת פתרון עובד לקטלוגים קומפקטיים: היא דורשת פחות משאבים ומסתיימת בהחלפה אחת. נבחן איזה מצב יתאים לתנועה ולעונתיות שלכם.
שלבי ההגירה: מביקורת הקטלוג ועד ההשקה
מעבר מ-CS-Cart ל-1С-Битрикс נשבר לא בהעברת המוצרים, אלא במלאי, בכתובות העמודים ובקשרים עם מערכת החשבונאות. לכן העבודה מתנהלת ברצף קבוע: קודם מתארים את המצב הנוכחי, אחר כך מעבירים למעגל סגור, ורק לאחר מכן מחליפים את האתר החי.
- ביקורת קטלוג — מייצאים מדורים, מוצרים, הצעות מסחר, מאפיינים, מחירים ומחסנים, סופרים כפילויות ופריטים בלי קטגוריה.
- מפת העברת נתונים — מתאימים ישויות: מדורים לאינפובלוקים, וריאנטים של מוצר להצעות מסחר, מחסנים למחסנים; מגדירים כללים למחירים וליחידות מידה.
- הגדרת היעד — בונים אינפובלוקים, סוגי מחירים ותבניות פלט לפני הזרמת הנתונים, כדי שהנתונים ייכנסו ישר למבנה היעד, בלי תיקונים אחר כך.
- העברה ובדיקה בסביבת בדיקה — משווים מספר פריטים, סכומים וקשרים לפי מדגמי בקרה. בנפרד בודקים מלאי לפי מחסנים והתנהגות במצב של פריט אפס: דווקא כאן המספרים לרוב לא תואמים למערכת החשבונאות.
- כתובות ומטא-נתונים — בונים מפת הפניות מכתובות ישנות לחדשות, שומרים כותרות ותיאורים, מעדכנים את מפת האתר כדי שהתנועה לא תיפגע.
- החלפה — משנים את הכתובות בחלון מוסכם, עוצרים עריכות בקטלוג במנוע הישן ושומרים על החלפת הנתונים תחת מעקב ביממה הראשונה.
- מסירת הפרויקט — הרשאות, סכימת החלפת נתונים, תקנון לעדכון מחירים ומלאי, הוראות לעורכים ונקודת חזרה לגרסה הקודמת.
מפת נתונים, כללי גישה ותקנוני העברה
אחרי מסירת ההעברה, ללקוח נשאר לא רק אתר פעיל, אלא גם סט מסמכים שלפיהם הצוות שלו מפתח את המשאב בלי קבלן חוץ. אנחנו אוספים את הסט הזה במהלך ההגירה מ-CS-Cart ל-1С-Битрикс, ולא משחזרים אותו מהזיכרון בסוף: אחרת חלק מההחלטות נשארות בהתכתבות והולכות יחד עם המבצע.
- סכימת נתונים — התאמת ישויות: מוצרים והצעות מסחר, מאפייני הקטלוג, מחסנים ומלאי, הנחות וכללי עגלה, סטטוסי הזמנות, שיוך למדריכים של מערכת החשבונאות.
- כללי גישה — תפקידים בפאנל הניהול, הרשאות למדורי הקטלוג, הפרדה בין עריכות טקסטים ומחירים, סדר הענקה ושלילת גישות למבצעים חיצוניים.
- תקנון העברה — סדר הייצוא, חלון עצירת קליטת הזמנות, רצף השלבים ונקודות חזרה למצב הקודם אם ההשוואה לא הסתדרה.
- הוראות למנהל — פעולות טיפוסיות עם הערות היכן הפעולה בלתי הפיכה: פרסום מוצר, טיפול בהחזרה, החלפת נתונים עם מערכת החשבונאות, סנכרון ידני של מלאי.
- פרוטוקול השוואה — מספרי בקרה לפי קטלוג, קטגוריות, הזמנות, משתמשים וכתובות עמודים לפני ואחרי המעבר, עם פער בכל סעיף.
- מפת כתובות וכללי איחוי — התאמה בין כתובות ישנות לחדשות, טיפול בכפילויות, פרמטרים של מסננים שלא צריכים להיכנס לאינדקס.
- תקנון גיבויים ועדכונים — תדירות הגיבוי, מקום האחסון, סדר השחזור ובדיקת תאימות עדכוני הפלטפורמה להתאמות.
מקרה בוחן: מעבר חנות עם 40,000 פריטי מוצר
הפרויקט — חנות אלקטרוניקה עם 40,000 פריטי מוצר, חלקם עם הצעות מסחר לפי צבע ונפח. הקטלוג החזיר עמוד קטגוריה תוך 3-4 שניות, והמלאי הגיע ממערכת החשבונאות פעם ביום: מנהלים אישרו הזמנות על דברים שכבר אין במלאי.
נקודת ההתחלה
מדגם לפי שלושה מסננים חושב מחדש בכל בקשה — 40,000 פריטים ו-120,000 הצעות. עד 6-7% מההזמנות נפלו עם שגיאה בשלב האישור, ואיתן אבדו עגלות. בשיא המבצעים, הקטלוג קרס תחת העומס: חלק מהעמודים החזירו שגיאת שרת. את המדדים לפני ואחרי לקחנו מיומני האפליקציה ומערכת החשבונאות, ולא לפי הערכה.
העברת הקטלוג וההחלפה
מוצרים, מאפיינים והצעות יוצאו דרך שכבת ביניים ונבנו מחדש כאינפובלוקים של 1С-Битрикс עם אינדקסים נפרדים לפי מאפיינים ניתנים לסינון. כתובות העמודים הותאמו אחת לאחת ונסגרו במפת הפניות, ולכן התנועה האורגנית לא נפגעה. העברת הקטלוג ארכה שלושה שבועות עם שתי הרצות בדיקה על ייצוא מלא.
החלפת הנתונים עם מערכת החשבונאות נעשתה סדירה — המלאי מתעדכן כל 15 דקות. תגובת הקטלוג עם מסננים — שברירי שנייה במקום 3-4, ושיעור ההזמנות בלי שגיאות הרשמה — 99.5%. את ההחלפה ביצענו בחלון לילי, כארבע שעות, עם אפשרות חזרה לאתר הישן במהלך שבוע.
מה עושים עם התאמות שלא קיימות בפלטפורמה החדשה?
תשובה קצרה: הקוד לא מועבר שורה-שורה. קודם כל מיפוי — רשימה של כל ההתאמות וההרחבות הלא-סטנדרטיות בפלטפורמה הישנה. לגבי כל פריט אנחנו מתעדים לא "איך זה כתוב", אלא איזו משימה הוא פותר בתהליך ואילו נתונים הוא משתמש בהם.
הקבוצה הראשונה — התאמות שהתקיימו רק בגלל מגבלות המערכת הישנה. לוגיקת הנחות, כללי משלוח, ויטרינת קטלוג, פרומו — בפלטפורמה החדשה זה נסגר במנגנונים מובנים, ואין צורך להעביר קוד בכלל. סעיף כזה יוצא מהמרשם עם הערה "נסגר בהגדרה".
הקבוצה השנייה — לוגיקה ייחודית באמת: החלפת נתונים עם מערכת החשבונאות, חישוב לא-סטנדרטי, אזור אישי לתהליך מסוים. אותה מעבירים לא בעריכת הליבה, אלא דרך נקודות הרחבה — מודול משלנו, מטפל אירועים, רכיב נפרד. תאימות הפתרונות נשמרת בדיוק בזכות זה: עדכון הפלטפורמה לא מוחק את ההתאמה.
הקבוצה השלישית — מה שלא מועבר בכוונה: טלאים מצטברים, כפילויות, פתרונות מאולתרים לגרסה הישנה. הרחבות צד שלישי בלי מקבילה נסגרות או במימוש שלנו, או בשירות מתאים עם החלפת נתונים. כל פתרון כזה מתאמים בנפרד — זו כבר שינוי תהליך, ולא העברה.
התוצאה — מרשם התאמות עם החלטה לכל פריט וסט תרחישים לבדיקה. לפלטפורמה החדשה עוברת רק לוגיקה שמייצרת ערך; החוב הטכני של המערכת הישנה נשאר במקום.
חששות טכניים לפני ההעברה: שאלות נפוצות
החששות שנשמעים בתחילת ההעברה הם כמעט תמיד טכניים: האם הנתונים ישרדו את המעבר והאם הפריטים לא יאבדו דירוג בחיפוש. אנחנו עוברים על אלה שצצים לרוב — לפני תחילת העבודה, כי מהתשובות תלויים ההיקף וסדר השלבים.
הלוגיקה פשוטה: מעבירים לא "איך שיצא", אלא לפי מפת התאמות שנאספה מראש. קודם מתעדים את מבנה הקטלוג, המאפיינים, הכתובות וההזמנות באתר הנוכחי, אחר כך משחזרים אותו בפלטפורמה החדשה — אחרי ההחלפה אין צורך ליצור דברים ידנית.
האם מאפייני מוצרים והצעות מסחר יועברו במלואם?
מעבירים מדריכי מאפיינים, את הסוגים שלהם, ערכים מרובים ושיוך למדורים, וגם הצעות מסחר עם מלאי. מודלי הנתונים בפלטפורמות שונים, ולכן ישויות שנויות במחלוקת מאחדים לפי טבלת התאמות ומציגים אותה לפני ההעברה — אתם רואים מראש לאן ייכנס כל שדה.
האם כתובות העמודים יישמרו? האם הפריטים לא יאבדו דירוג?
אוספים מפת "כתובת ישנה → חדשה" ומגדירים הפניות קבועות, תבניות הכתובות חוזרות על המבנה הקודם. אחרי ההעברה מריצים את הרשימה בסריקה ומשווים למקור — פערים מתגלים לפני שרובוט החיפוש רואה אותם.
מה עם היסטוריית ההזמנות ומאגר הלקוחות?
הזמנות, סטטוסים, הרכב פריטים ושיוך לקונים מועברים; מספרים ישנים נשמרים כדי שהתמיכה תמצא אותם לפי מזהה רגיל. נתונים אישיים מועברים במעגל סגור, והגישה אליהם נשארת למעגל מצומצם של עובדים.
נדבר על המשימה: מה לשלוח להערכה מדויקת
הערכה מדויקת של ההעברה מתקבלת לא מסקירת הוויטרינה, אלא מהנתונים: ככל שתמונת המצב של החנות הנוכחית מלאה יותר, כך יש פחות הנחות בתוכנית העבודה ופחות הפתעות באמצע הפרויקט. להלן רשימת מה שדי לשלוח כדי לדון במשימה באופן ענייני. אם משהו חסר — לא קריטי, חלק נאסוף בעצמנו לפי הרשאות.
- גישה לפאנל הניהול ולמסד הנתונים (או גיבוי עדכני) — לפיו רואים את ההיקף בפועל של הקטלוג, מבנה המאפיינים ועומק היסטוריית ההזמנות;
- ייצוא מוצרים עם מדורים, מאפיינים, מחירים ומלאי — הוא נדרש כדי לתכנן מראש התאמה של קטגוריות ולא לאבד הצעות מסחר;
- הזמנות לתקופה רלוונטית עם סטטוסים, אמצעי תשלום ומשלוח — זה מועבר בלוגיקה נפרדת, ולא "איך שיצא";
- רשימת מודולים והתאמות במערכת הנוכחית — הסיבה הנפוצה ביותר להערכת חסר של היקף ההגירה;
- רשימת כתובות שמביאות כיום תנועה אורגנית וטבלת קישורים נוכחיים — על פיהן בונים כללי הפניה כדי שהפריטים לא יאבדו דירוג;
- תיאור אינטגרציות: מחסן, הנהלת חשבונות, שירותי משלוח, דיוור, אזור אישי;
- הנתונים שלכם: לוחות זמנים, מוכנות לעבוד בשלבים ולעבוד על עותק במקביל לאתר הפעיל.
תארו את המשימה בכל צורה נוחה — קישור לאתר והודעה קצרה עם הנתונים כבר נותנים לנו בסיס להערכה. נחזור עם הערכת ההעברה, תוכנית עבודה לפי שלבים ורשימת סיכונים שכדאי לסגור לפני ההשקה.