תגי מטא ב-Битрикс נשברים בעת ייבוא מוצרים המוני
ייבוא המוני של קטלוג ל-Битрикс שובר תגי מטא לא בגלל שגיאה בקוד, אלא בגלל סדר הפעולות בתוך החלפת הנתונים. נתונים מ-1С או מקובץ ייצוא מגיעים בכמה מעברים: תחילה הצעות מסחריות ומחירים, אחר כך מאפיינים ושיוך למדורים.
תבנית תגי המטא נבנית משדות שעדיין אין ברגע כתיבת הכרטיס — והעמוד נכנס לאינדקס עם כותרת ריקה או כותרת מהסוג «מוצר» בלי קטגוריה ומותג.
המקור השני לתקלה — התבנית עצמה. אם נשארו בה רק שם הפריט ושם המדור, מאות כרטיסים באותו קטלוג מקבלים title ו-description זהים.
כפילויות של title ו-description גרועות יותר מתגי מטא ריקים: מנוע החיפוש בוחר מתוך קבוצת עמודים דומים כתובת אחת, והשאר נופלים מהתוצאות — יחד איתם נחלשים כרטיסים שבאותו ייצוא הספיקו לעדכן מחירים ומלאי.
התקלה השלישית מורגשת לא מיד. עדכון מחירים ומלאי משנה את הרכב הקטלוג: מוצר עובר לארכיון, עובר למדור אחר, מופיע באוסף חדש. תגי המטא נשארים מהגרסה הקודמת — פריט שהוסר ממשיך לאסוף תנועה לעמוד בלי הצעה, והחדש מגיע לאינדקס עם סימון ריק.
תגי מטא ריקים וכפילויות לא נרפאים בתיקון חד-פעמי: כל טעינה נוספת מחזירה אותם, כל עוד התבנית לא מחוברת לשדות שבאמת מתמלאים בעת החלפת הנתונים. נפרט כיצד זה נסגר — מחוקי ההצבה ובדיקת כפילויות ועד בקרת התוצאה אחרי כל ייצוא.
מה משתנה לאחר הטמעת תבניות שדות SEO
לאחר הפעלת תבניות שדות SEO, הסימון של כרטיסים מפסיק להיות תלוי במי ומתי מילא את השדות ידנית. חוקי ההצבה מרכיבים כותרת ותיאור ממאפייני המוצר — קטגוריה, מותג, שם, מאפיין מרכזי — ובפלטפורמת 1С-Битрикс מיושמים ברמת האינפובלוק, ולא ברמת כרטיס בודד. הערכים נשארים ניתנים לדריסה: עבור פריטים מובילים העורך מגדיר טקסט ידנית, והחוק לא דורס אותו.
חלק הכרטיסים עם סימון תקין בקטלוג של כמה אלפי פריטים עולה משליש ל-95% ומעלה — זה נראה בדוח לפני ואחרי ההטמעה, ולא מוערך בעין. במקביל יורד חלק הכפילויות: התיאור כבר לא חופף מילה במילה במאות פריטים, כי החוק מציב חלקים שונים — קטגוריה, מותג, מאפיין, טווח.
הכנת מדור בקטלוג מואצת בזכות ירושה: קטגוריה חדשה מקבלת את החוק ממדור האב, ובמקום מילוי ידני של כל כרטיס המהנדס מגדיר תבנית אחת. תיקון במקום אחד משנה את הסימון של כל המדור — הפעלת קטגוריה, שנמשכה קודם ימים, מצטמצמת לבדיקת הצבות על מדגם ולחריגים ממוקדים.
נשאר תקנון: טיפול במאפיינים ריקים כדי שמפרידים מיותרים לא ייכנסו לכותרת, עדיפות לערכים ידניים על פני התבנית, והרצת בדיקה לפני פריסה על כל הקטלוג. לאחר מכן הסימון צפוי, והוספת מלאי לא יוצרת מחדש תור משימות למילוי ידני.
צורות אחסון של חוקים: אינפובלוק, מודול או שירות חיצוני
ניתן להחזיק את חוקי יצירת הסימון בשלושה מקומות: באינפובלוק הסטנדרטי של 1С-Битрикс, במודול נפרד על שדות מותאמים אישית, או בשירות חיצוני. הבחירה נקבעת לפי מספר השדות בתבנית, לפי מי שעורך את החוקים — מנהל תוכן או מפתח — ולפי מה שקורה בייצוא המוני של הקטלוג.
הדרישה לכל אפשרות היא אחת: החוקים צריכים לשרוד אינדוקס מחדש, עדכון פלטפורמה וייבוא מוצרים, אחרת הסימון «ייסע» במאות עמודים בבת אחת. להלן חלופות שבאמת בוחרים ביניהן בקטלוג חי.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| אינפובלוק סטנדרטי | קטלוג אחד, תבנית מהסוג «{שם} — לקנייה ב{עיר}», תיקונים בידי מנהל תוכן | חוקים מורכבים — תנאים לפי מלאי, קטגוריות, שפות — לא באים לידי ביטוי, וההיגיון מתפזר בהגדרות המדורים |
| שדות מותאמים אישית ומודול נפרד | שדות ייעודיים לתגי מטא, תבניות שונות לפי קטגוריות, חישובים לפי מאפיינים מקושרים | יש לתחזק את המודול בעת עדכוני פלטפורמה, והעברה בין אתרים מורכבת יותר |
| שירות חיצוני | כמה אתרים וקטלוגים, חוקים אחידים, ייצוא הסימון למערכות משיקות | השהיית סנכרון, החלפת נתונים והרשאות גישה; כאשר השירות לא זמין, הסימון לא מתעדכן |
בפועל מתחילים באינפובלוק הסטנדרטי, וכשהחוקים מתרבים מעל לעשרה, מעבירים את ההיגיון למודול ומשאירים באינפובלוק רק דריסות ידניות לכרטיסים בודדים.
סדר העבודות: מביקורת הסימון ועד מסירת התקנון
העבודות מתקדמות מתיעוד המצב הקיים אל תקנון שפועל לפיו העורכים ממשיכים לעבוד בעצמם. הסדר מסיר את הסיכון המרכזי: התבניות לא מיושמות מיד באתר החי, ולכן אף עמוד לא מאבד סימון בזמן שהחוקים מכווננים.
- ביקורת סימון. מייצאים כותרות ותיאורים לפי כל סוגי העמודים — קטלוג, כרטיסי מוצר, מאמרים, מדורים. מתעדים היכן הערכים משוכפלים, היכן ריקים, והיכן הוזנו ידנית.
- מפת פערים. משווים את מדגם הביקורת למופת לכל תבנית: מה נוצר אוטומטית, מה נערך ביד, והיכן החוקים מתנגשים בין מדורים. מכאן רואים אילו תבניות מאחדים ואילו דורשות היגיון נפרד.
- סכימת חוקים. מתארים את ההצבה לפי סוגי עמודים: אילו שדות משתתפים, כיצד מטופלים ערכים ריקים, ומה נכנס לעימוד ולמסננים. את הסכימה מתאמים איתכם לפני ההגדרה — תיקונים בשלב זה זולים יותר מאשר אחרי ההעברה.
- הגדרה בסביבת בדיקה. פורסים עותק של האתר עם בסיס נתונים עובד, מחברים תבניות ומריצים יצירה על כל מדגם הכתובות. בודקים מקרים לא שגרתיים: שמות ארוכים, מוצרים בלי תיאור, מדורים שירותיים.
- בדיקה. עוברים על מדגם ביקורת של עמודים ומשווים את הערכים הסופיים לצפויים. בנפרד מוודאים שכתובות ותיקות לא איבדו סימון ושהופיעו כפילויות.
- העברה לאתר החי. פורסים את החוקים על העותק העובד ועוקבים אחרי התנהגות העמודים לאחר העדכון. חזרה למצב הקודם במקרה של סטיות אורכת דקות.
- תקנון מילוי. מוסרים מסמך: מה העורך ממלא, מה נוצר מעצמו, וכיצד לבדוק עמוד לפני פרסום. מעבירים הדרכה ומלווים את התיקונים הראשונים.
מארז תוצרים: תבניות, חוקי הצבה, תקנונים
מוסרים את הפרויקט כך שתגי המטא ב-Битрикс יעבדו בלעדינו. כל מה שקשור להצבה נמצא במאגר הקוד לצד הקוד: לא בהתכתבות ולא בראש של מישהו אחר, אלא במסמכים שמהנדס חדש או עורך מערכת יבין מהם בעצמו.
- מפת תבניות — טבלה «סוג עמוד → תבנית → מקור נתונים»: כרטיס מוצר, מדור קטלוג, מאמר, עמוד שירותים, עימוד.
- מדיניות עדיפויות שדות — מה מנצח בעת התנגשות: ערך מהכרטיס, תבנית אוטומטית או תיקון ידני של העורך. בלי זה קל לאבד ערכים מחושבים.
- הוראות לעורך — דוגמאות «לפני/אחרי», מגבלות אורך, ניתוח טעויות אופייניות. אדם בלי רקע טכני מתקן שדות ולא שובר את התבנית.
- סכימת שיוך למדורים — היכן בדיוק החוקים מופעלים: אינפובלוקים, מדורים, גרסאות שפה, חריגים בודדים. ממוקד, ולא «מופעל בכל מקום».
- יומן שינויים — מי, מתי ולמה שינה את התבנית, ומה היה המצב הקודם. חוק אחד מוחזר לאחור בלי לפגוע בשאר.
- מערכת בדיקות בקרה — רשימת עמודים לקבלה וצ'קליסט לפני עדכון המוני של הקטלוג.
- תקנון העברת ידע — פירוט מוקלט עם הצוות והסדר שלפיו ההוראות מתעדכנות כשמבנה האתר משתנה.
מכאן והלאה התמיכה היא לא «להקפיץ מפתח», אלא תיקון של מסמך אחד. תארו את המשימה — נחזור עם אומדן ותוכנית.
מקרה בוחן: קטלוג עם 40 אלף פריטים בלי כפילויות בסימון
קטלוג עם 40 אלף פריטים — אלה עשרות אלפי כרטיסים, ולכל אחד מאפיינים, מדורים והצעות מסחריות משלו. את הסימון בו ניהלו ידנית: מנהלי תוכן העבירו את שם המוצר ל-title ול-description, חלק מהשדות נשארו ריקים, וחלק שוכפלו בין כרטיסים במדורים סמוכים. בהיקף כזה הסימון התפזר כבר חודש אחרי טעינת קטלוג נוספת.
לפני: מילוי ידני ושליש כפילויות
description מלא היה לכ-62% מהכרטיסים, והשאר עברו לחיפוש עם תיאור ריק או חתוך. כפילויות של title ו-description, שנבדלו בסדר המילים או בהטיה, הופיעו כמעט בכל כרטיס שלישי — מנועי החיפוש איחדו עמודים כאלה והשאירו אחד בתוצאות. מדור חדש הושק בתוך שבועיים-שלושה: עד שלא עברו ידנית על כל הכרטיסים, אי אפשר היה לפתוח את המדור.
אחרי: תבניות על מאפיינים ונקודת תיקון אחת
העברנו את הסימון לתבניות שמרכיבות תגי מטא ממאפייני הכרטיס — קטגוריה, סדרה, סוג מוצר, מלאי. החוק קובע את סדר החלקים, האורך והמפרידים, ולכן כרטיסים זהים כבר לא מפיקים כותרות זהות.
חלק הכפילויות ירד משליש למקרים בודדים, הכרטיסים המלאים עלו מ-62% ל-99%, ומדור חדש מושק כעת ביום עבודה אחד — מספיק לציין תבנית, והיא מיושמת על כל פריטי המדור.
גם התמיכה בסימון הפסיקה להיות שגרה: הוספת מאפיין או מדור לא דורשת תיקונים בכרטיסים, וטעינות המוניות ממערכת הנהלת החשבונות עוברות דרך אותה תבנית. מגבלות האורך והמבנה של השדות בדקנו מול הדרישות של 1С-Битрикс, כדי שהסימון ייכנס כראוי לקוד העמוד ולמפת האתר.
מה לעשות אם חלק מהסימון כבר מולא ידנית
החוק פשוט: ערך ידני קודם לערך מהתבנית — אבל רק בשדה שתוקן. המילוי האוטומטי ב-Битрикс פועל ברמת מאפיין העמוד, ולכן אנחנו לא מכבים את החוק כולו, אלא מסמנים שדה מסוים כדרוס ידנית: השאר ממשיכים להתעדכן מהתבנית.
נוח יותר לאחסן את העדיפות לא כדגל, אלא כמקור הערך: לכל שדה יש ערך נוכחי, יוצר וזמן שינוי אחרון. אז הרצה חוזרת של התבניות מדלגת על תאים דרוסים, ולא מוחקת אותם.
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| ערך שדה ידני | עמודים ייחודיים שבהם התבנית נותנת טקסט חלש | נדרשת בקרה בעת החלפת תבנית המדור |
| חוק לפי תבנית | קטלוג וכרטיסים טיפוסיים | לא מתחשב במשמעות של עמוד מסוים |
| חריג ממוקד | כתובות ומדורי משנה בודדים | יש לתחזק את הרשימה מעודכנת |
| הקפאת תמונת מצב | החלפת היגיון היצירה | השדות מפסיקים לקבל שיפורים מהתבנית |
חריגים מוגדרים לפי מסכת כתובת או לפי ענף בעץ, ולא לפי רשימת עמודים — אחרת הרשימה מתיישנת מהר יותר משמצליחים לתחזק אותה. עבור כל אחד מתעדים סיבה: כעבור חצי שנה אף אחד לא צריך לנחש למה שדה הפסיק להתעדכן.
היסטוריית התיקונים סוגרת את הסיכון המרכזי של הרצה המונית: רואים מי ומתי שינה את הערך, ומה היה לפני ואחרי. חזרה לגרסה קודמת אורכת דקות במקום שחזור מגיבוי.
תגי מטא ב-Битрикс: ספקות טכניים לפני ההתחלה
ספקות לגבי תגי מטא כמעט תמיד נוגעים לדבר אחד: האם האוטומציה לא תשבור את הקטלוג והאם לא נקבל כפילויות במקום צמיחה בתנועה. להלן ארבע שאלות שנשאלות בהתחלה: לגבי עומס, עמודי מסננים, גרסאות שפה והתנהגות בעת עדכון פלטפורמה.
מה לעשות עם כפילויות של עמודי מסננים?
יצירה אוטומטית של תגי מטא למקטעי קטלוג יוצרת אלפי כתובות כמעט זהות. אנחנו מחזירים כתובת קנונית לעמוד הראשי של המדור, סוגרים צירופי פרמטרים שירותיים ב-robots.txt ולא מכניסים אותם למפת האתר. לאינדקס נכנסים רק מקטעים עם תוכן ייחודי.
האם הביצועים של הקטלוג לא ייפגעו?
תגי מטא נאספים בשמירת הפריט ונשמרים בבסיס הנתונים, ובעמוד נשארת הצבה של ערכים מוכנים. חישוב מחדש המוני מתבצע במשימות רקע במנות, ולכן הצגת הקטלוג לא נפגעת, וסריקת רובוטים לא יוצרת שיאים. איחוד עמודים מתבצע פעם אחת בזמן הסימון, ולא בכל הצגה.
איך זה עובד עם ריבוי שפות ותת-דומיינים אזוריים?
עבור גרסאות שפה הקישור נבנה דרך hreflang עם ציון השפה הראשית, ועבור תת-דומיינים — תבניות כותרת נפרדות עם עיר וכתובת קנונית משל עצמן. כך הגרסאות לא מתחרות זו בזו בתוצאות ולא מטשטשות את המשקל של האתר הראשי.
מה יקרה בעת עדכון הפלטפורמה?
התבניות והחוקים נשמרים במודול נפרד ובקובצי תבנית עיצוב, ולא בליבה, — עדכון הפלטפורמה לא מוחק את ההגדרות. לפני הפרסום מריצים בדיקה על עותק ושומרים אפשרות לחזור לתצורה קודמת.
נדון במשימה ונחזור עם אומדן ותוכנית
אומדן מדויק לתגי מטא נשען לא על ניחושים, אלא על הרכב הקטלוג והחוקים הנוכחיים להפקת כותרות. כדי לחשב את היקף העבודה, די לנו בגישה לממשק הניהול או לעותק של התצורה, ברשימת האינפובלוקים ובכמה דוגמאות עמודים — כרטיס מוצר, מדור, עמוד שירות. אם חלק מהתיאורים כבר הוזנו ידנית, שלחו ייצוא: ננתח מה מעבירים לתבניות ומה משאירים כחריג.
- סוגי עמודים: אילו מדורים וכרטיסים משתתפים באוטומציה וכמה יש בסך הכול;
- היכן כיום נוצרים הכותרת והתיאור — ברכיב, במאפייני SEO או בהגדרות האינפובלוק;
- מבנה הנתונים: הצעות מסחריות, סניפים, גרסאות שפה, חיבור ל-1С;
- מאפייני SEO מלאים: חלק הפריטים עם ערכים ידניים שאסור לדרוס;
- גישות: סביבת בדיקה או עותק של בסיס הנתונים, כדי לבדוק את הפלט בלי סיכון לאתר העובד;
- מגבלות: תבנית כתובת העמוד, דרישות לאורך ולמבנה הכותרות.
בהמשך נציג תוכנית הטמעה בשלבים: ביקורת הפלט הנוכחי, תכנון תבניות וחוקי הצבה, הרכבה בסביבת בדיקה, השוואת תוצאות, העברה לאתר העובד. מסירת התוצאה היא לא רק קוד עובד, אלא גם תיאור התבניות עם דוגמאות, חוקים לחריגים והוראות לעורכים. תמיכה לאחר ההשקה כוללת בקרה על מדורים חדשים ותיקון תבניות כשמבנה הקטלוג משתנה.
תארו את המשימה ושלחו את מה שיש בהישג יד — נחזור עם אומדן עבודות ותוכנית הטמעה.