הגדרת כתובות URL ב-1C-Bitrix: היכן נשברת האינדוקסציה
כתובת דינמית כמו /catalog/index.php?SECTION_ID=42&PAGEN_1=2 נכנסת לאינדקס בדיוק כמו כתובת קריאה לאדם. כפילויות כתובות מדללות את המשקל בין העותקים, והמדור מפסיק להתאחד לעץ — החיפוש רואה אוסף עמודים מפוזרים במקום מבנה של קטלוג.
מכאן נדלקת השרשרת. החלפת תבנית או כללים מייצרת כתובות חדשות, הישנות נשארות פעילות או מחזירות 404 — מעברים שבורים טורפים את הקישורים שנצברו. רישיות, סלאש בסוף, www ופרמטרי מיון מוסיפים עוד שכבות של עותקים, אם ההפניה והכתובת הקנונית אינן מוגדרות.
הגדרת URL ב-1C-Bitrix אינה תיבת סימון אחת שמפעילה כתובות קריאות בהגדרות המודול. נדרשים כללי שכתוב, טיפול נפרד בעימוד ובמסנן הפאסטים, מראה אחיד של הכתובת עבור מדורים ועמודי מוצר, והפניות רוחביות בעת העברת מדורים ומוצרים ביניהם.
כתובות קריאות ואינדוקסציה קשורות ישירות: כל עוד מבנה הכתובות של האתר אינו מוביל לגרסה אחת לכל עמוד, כל עריכה בקטלוג מולידה כפילויות חדשות. המחיר — נשירה מהתוצאות של ענפים שלמים: מוצרים ומאמרים נשארים נגישים, אבל מפסיקים לקבל מעברים מהחיפוש.
אנחנו מפרקים כיצד זה נסגר: מכללי השכתוב ומפת ההפניות ועד השוואת סריקות לפני ואחרי הריליס — כדי שהעברת מבנה לא תעלה בדירוגים.
האפקט מכתובות קריאות תקינות: מה משתנה בעבודה
כתובות מנוהלות נותנות אפקט מדיד בשלושה מקומות: אינדוקסציה, התנהגות המבקר וגמישות המבנה. התוצאה הראשונה — איחוד כפילויות: אותו מדור, שנפתח דרך מסנן, מיון או עם סלאש בסוף, נראה בעיני מנוע החיפוש כמו כמה עמודים, ומשקל הקישורים מתדלל בין העותקים. כללי הטיפול בכתובות ב-1C-Bitrix מכנסים את כל הווריאציות למראה קנוני אחד.
השנייה — כתובות מובנות לאדם. כתובת כמו /katalog/nasosy/tsentrobezhnye/ נקראת גם בתוצאות החיפוש וגם בשורת הדפדפן, ולכן המבקר מגיע למדור הנכון לעתים קרובות יותר כבר במעבר הראשון.
במספרים זה נראה כך: עולה חלקם של המעברים פנימה אל תוך הקטלוג ויורד מספר החזרות אל שורת החיפוש מתוך עמוד פנימי.
השלישית — תוצאות יציבות בעת שינוי מבנה המדורים. העברת קטגוריה, פיצול מדור גדול או איחוד של שניים קרובים מפסיקים להיות פעולה עם קריסת דירוגים: הכתובות הישנות נסגרות בהפניות לפי כלל שתואר מראש, קישורים חיצוניים מובילים לאותם חומרים, ומנוע החיפוש רואה עדכון מתוכנן ולא זרם של שגיאות.
בסך הכול המבנה עובר ממצב של "מפחיד לגעת בו" למצב מנוהל: מדורים נבנים מחדש לפי צורכי העסק, והתנועה שנצברה נשמרת. אנחנו מפרקים אילו כללים נדרשים לקטלוג שלכם וכיצד לאמת את התוצאה לפני העלייה לאוויר.
דרכי הפעלה של כתובות קריאות: השוואת מצבי עבודה
מצב הכתובות הקריאות נקבע פעם אחת, אבל מכאן והלאה הוא קובע את כל מבנה הכתובות: כיצד נוצרות הכתובות של כרטיסים חדשים, אילו כללי טיפול בכתובות חלים על מדורים, ומה קורה בעת העברת הקטלוג או החלפת תבנית התצוגה.
בפועל הבחירה מצטמצמת לשלוש סכמות — כתובות קריאות אוטומטיות, כתובות ידניות והיבריד, שבו האוטומטיקה סוגרת את המסה והעריכה הידנית את הנקודות החשובות לחיפוש.
מצב אוטומטי עובד כל עוד הקטלוג אחיד וממלאים אותו עורכים: הקוד נבנה מהכותרת לפי תבנית, וקונפליקטים נפתרים בסיומת מספרית.
כתובות ידניות נותנות שליטה במקומות שבהם נדרש קישור לטיני קצר או מראה אחיד למדורים ישנים ולחדשים — אבל דורשות משמעת: קוד סימבולי שהוחמץ יוצר כתובת כפולה, ולא שגיאה בממשק.
| מצב | מתי מתאים | מגבלות המצב |
|---|---|---|
| אוטומטי לפי תבנית | קטלוג גדול ואחיד, מילוי בידי עורכים, מדורים חדשים מופיעים לעתים קרובות | קירילית בכתובת בתעתיק לא מוצלח, סיומות כשקודים חופפים, ולא ניתן להגדיר כך מבנה שונה לענפים נפרדים |
| כתובות ידניות | סט מוגבל של עמודים בעדיפות, קישורים לטיניים קצרים, העברת מבנה מאתר אחר | לא מתרחב לאלפי כרטיסים, שגיאת כתיב נראית רק דרך שגיאת 404, נדרש פיקוח בכל ייבוא |
| סכמה היברידית | קטלוג גדול עם כמה מדורי חזית, עמודים לפרסום ואוספים רוחביים | נדרש נוהל: מי ומתי עורך את הקוד ידנית, ובנוסף מפת הפניות לכל שינוי שם |
החלפת מצב בפרויקט פעיל היא כבר לא עניין של הגדרה, אלא של תאימות: יש לסגור קישורים ישנים בהפניה קבועה, אחרת מעברים חיצוניים והתוצאות שנצברו נעלמים. לכן קובעים את הסכמה לפני מילוי הקטלוג, ובודקים את כללי הטיפול בכתובות על עותק בדיקה — עם ייבוא, עימוד ומסננים.
סדר היישום: מאודיט הכתובות ועד למסירה
כתובות ב-1C-Bitrix חיות בכמה שכבות: תבניות כתובות קריאות במאפייני בלוקי המידע, כללי טיפול ב-urlrewrite.php, הפניות ברמת השרת וכתובות קנוניות בתבנית. אין לשנות אותן אחת-אחת — חלק מהעמודים מתחילים להחזיר 404, חלק נכנסים לכפילויות, ומנוע החיפוש גורר לאינדקס את שתי הגרסאות. לכן הגדרת הכתובות מתבצעת בשלבים, עם בדיקת התוצאה בכל שלב.
- אודיט כתובות. אוספים את כל מה שהשרת באמת מחזיר: לוגים של בקשות, מפת אתר, ייצוא ממערכות אנליטיקה, כללים פעילים. בנפרד מסמנים כתובות עם תנועה וקישורים חיצוניים — אותן אסור לאבד.
- מפת הפניות. לכל כתובת ישנה קובעים יעד וקוד תגובה: 301 למעבר קבוע, 302 למעבר זמני. מסירים שרשראות של שניים-שלושה מעברים, ומביאים למראה אחיד את הסלאש, הרישיות ופרמטרי השאילתה.
- סכמת כתובות קריאות. מגדירים תבניות למדורים וללוקי מידע, כללי תעתיק, ומחליטים מה נכנס לכתובת — קוד סימבולי, מק"ט או תאריך. בודקים שהכתובות החדשות אינן מתנגשות עם הקיימות.
- קו בדיקה. פורסים עותק עם אותו סט כללים ואותה מפת הפניות, עוברים על כל רשימת הכתובות, ומשווים קודי תגובה וכתובות קנוניות. רק אחרי זה מעבירים לשרת החי.
- תיאום המעברים. מציגים ללקוח את המפה: מה משתנה, מה נשמר, והיכן עומדת הפניה. עורכים את התיקונים לפני הפרסום, לא אחריו.
- הגדרה בשרת החי. מפעילים את הכללים, מנקים מטמון, מרעננים את מפת האתר, ושומרים על מעקב אחר קודי התגובה בשעות הראשונות.
- מסירה. מוסרים את מפת ההפניות, תבניות הכתובות הקריאות, נוהל הוספת מדורים חדשים וסדר בדיקת כתובת לפני פרסום.
מה מוסרים לידיים: קבצים, סכמות, נהלים
הגדרת URL ב-1C-Bitrix לא מסתיימת ברגע שבו הכתובות התחילו להיפתח. בלי סיכומים מוגדרים, המדור החדש הראשון בקטלוג שובר את ההיגיון של התבניות, הכפילויות מתפזרות בתוצאות, והכתובות הישנות נעלמות.
לכן מוסרים ערכה שלמה, שלפיה אפשר לחזור על העבודה ולהעביר אותה למבצע אחר בלי לפענח את הראש של מישהו אחר.
- סכמת כתובות — מפת רמות עם תבניות כתובות קריאות: אילו חלקים נוצרים מהקוד הסימבולי, אילו נקבעים ידנית, והיכן הקינון מוגבל במכוון.
- קונפיגורציה עובדת — כללי טיפול בכתובות עם עדיפויות, הגדרות בלוקי מידע ומדורים שמשפיעות על יצירת הקודים.
- מפת מעברים — טבלה של "כתובת ישנה → חדשה" עם כללי איחוד כפילויות, נרמול סלאש ורישיות, ובנפרד — כתובות לאחר שינוי מבנה הקטלוג.
- כללי הקונפיגורציה — מה אפשר לשנות במקום ומה רק דרך תיאום: תעתיק, מפרידים, אורך הקוד, טיפול בכתובות תפוסות.
- נוהל עבודה — רצף עריכת הכתובת: מי יוזם, באיזה שלב מתעדכן הכלל, ואילו בדיקות מתבצעות לפני העלאה.
- הוראות למנהל התוכן — כיצד לפתוח מדור או כרטיס כך שהקוד ייווצר נכון, ומה לעשות בעת העברת חומר.
- סט בדיקות ויומן שינויים — רשימת כתובות בקרה להרצה אחרי הריליס ונקודות שחזור, אם כלל פעל אחרת.
הערכה מיועדת למי שלא השתתף בהגדרה: ממנה רואים מדוע הכתובת נראית דווקא כך ומה יקרה בהוספה הבאה של מדור.
קייס: איחוד כפילויות כתובות ושחזור התוצאות
נקודת ההתחלה
בקטלוג על 1C-Bitrix אותו כרטיס נפתח בשבע כתובות: עם קוד מספרי ועם קוד סימבולי, עם קידומת www ובלעדיה, עם סלאש בסוף ובלעדיו, עם פרמטרי מיון ומספר עמוד. הרובוט סרק את כל הווריאציות, התוצאות קיבלו כמה עותקים של אותו טקסט ובחרו פעם אחת ופעם אחרת. מספר הכתובות שאונדקסו גדל, והמעברים מהחיפוש פחתו — התנועה דלפה אל הכפילויות.
מה עשינו ולאן הגענו
הפעלנו את מצב הכתובות הקריאות והגדרנו תבנית אחידה לקטלוג, למדורים ולעמודי מוצר; קודים סימבוליים נבנים בתעתיק של הכותרת עם חיתוך ובדיקת התנגשות. את הווריאציות הישנות סגרנו בהפניה קבועה לכתובת הקנונית — חלק מהכללים ברמת השרת, חלק ב-handlers, כדי לא לאבד כתובות עם פרמטרי מסנן.
עמודי המיון והעימוד קיבלו כתובת קנונית והוסרו מהסריקה, ומפת האתר נבנתה מחדש: רק הכתובות העיקריות נכנסו אליה.
אחרי הסריקה מחדש מספר הכתובות שאונדקסו ירד מ-41,000 ל-5,700, ובמקביל מספר העמודים עם תוכן ייחודי באינדקס דווקא גדל ולא קטן.
המעברים מהחיפוש אל הקטלוג עלו בכשליש בערך, סריקת הרובוט מסתיימת בתוך יממה במקום שבוע, ומדורים חדשים נכנסים לתוצאות בתוך ימים ספורים — המכניקה של הכתובות הקריאות כבר מוגדרת עבורם.
ספקות טכניים לפני תחילת העבודה
אתר פעיל אינו דף חלק: יש היסטוריית אינדוקסציה, קישורים חיצוניים ומדורים שהמשתמשים התרגלו אליהם. לפני החלפת סכמת הכתובות ב-1C-Bitrix אנחנו מאמתים מה נצבר, ורק אחר כך נוגעים בכללים.
האתר פעיל — האם יהיה צורך לעצור אותו בזמן בניית הכתובות מחדש?
לא. הכללים החדשים נבנים על עותק ונבדקים בקו בדיקה: משווים את יצירת הכתובות עבור מדורים, עמודי מוצר, ניווט בין עמודים ומסננים. ההעברה מתבצעת מדור-מדור, מפת "כתובת ישנה → חדשה" מוכנה מראש, וההפניות מופעלות יחד עם הכלל — המבקר בכל רגע מגיע לעמוד פעיל.
איך זה עובד עבור גרסאות שפה של האתר?
לכל גרסה — קידומת קטלוג משל עצמה או דומיין נפרד; כלל יצירת הכתובות משותף, והקידומת מוספת אוטומטית. בנפרד אנחנו עוקבים אחר התעתיק: לקירילית ולטינית סטים שונים של כללים, אחרת כתובות של גרסאות שונות יתחילו להתנגש זו בזו.
מה עם קישורים ישנים ודירוגים שנצברו?
כתובות ישנות נסגרות בהפניות קבועות, ומפת האתר נוצרת מחדש לפי המבנה החדש. קישורים חיצוניים וסימניות של משתמשים ממשיכים לעבוד.
אם יהיה צורך לשנות את המבנה שוב — הכול יחזור על עצמו במעגל?
תבניות הכתובות מוצאות למקום אחד — הגדרות בלוקי המידע והמודול, ולא לקוד של קומפוננטות. אז שינויים חוזרים במבנה מצטמצמים לעריכת כלל ולהוספה למפת ההפניות, בלי לשכתב קישורים לפי תבניות.
נדון במשימה שלכם סביב כתובות והפניות
כדי לחזור עם הערכה ותוכנית עבודה, ולא עם שאלות הבהרה, נדרשים נתוני פתיחה על מבנה הכתובות הנוכחי. אספו את מה שיש בהישג יד — את השאר המהנדסים שלנו יסיקו מהפרויקט עצמו ומהגדרות השרת.
- מפת הכתובות הפעילות: ייצוא מקובץ מפת האתר או רשימת מדורים שכבר אונדקסו על ידי החיפוש.
- כללי ההפניה הקיימים: תוכן .htaccess, קובץ שכתוב הכתובות וההגדרות ברמת השרת.
- תבניות כתובות קריאות לפי מדורים וללוקי מידע: היכן SEF מופעל, היכן קישורים נבנים ידנית, והיכן הכתובת נוצרת מהקוד הסימבולי.
- כתובות בלתי ניתנות לשינוי: אלה שכבר הופצו בפרסום, בחומרים מודפסים, באפליקציות ובאיזורי שותפים.
- מקורות המעברים החיצוניים: מאין מגיעים הקישורים, כדי שההפניה לא תקריע חיבורים פעילים.
- דוח 404 ופניות לתמיכה: יראה את המחיר האמיתי של שגיאות בכתובות, ולא את המשוער.
- מגבלות על העלאה: נוהל ריליסים, קיום קו בדיקה וחלון זמן שבו מותר לשנות כללים.
לפי הנתונים האלה אנחנו מכינים תוכנית עבודה: אילו כתובות מתקנים, היכן מציבים הפניה קבועה, כיצד בודקים כיסוי של מפת הקישורים הישנה ובאיזה סדר מעלים את השינויים כדי שהחיפוש לא יאבד עמודים. אם משהו חסר — לא נורא: את החסר נבהיר בשיחה ונקבע בהערכה.
במה שונה כתובת קריאה מכתובת URL דינמית
כתובת דינמית היא שאילתה אל בלוק המידע עם מזהים בפרמטרים: ?SECTION_ID=, ?ELEMENT_ID=. התוכן מוחזר אותו תוכן, אבל את הקישור אי אפשר גם להכתיב וגם לקצר בלי לאבד את המשמעות. כתובת קריאה היא מצב שבו הכתובת נבנית מהקודים הסימבוליים של מדורים ורכיבים, למשל /catalog/plitka/keramogranit/.
ב-1C-Bitrix שתי הווריאציות מוחלפות בהגדרות מודול בלוקי המידע — בשדות "URL страницы раздела" ו-"URL страницы детального просмотра".
ההבדל מתגלה בעת מעבר ושכפול. במצב דינמי שינוי שם של מדור או החלפת מדור אב לא שובר דבר: המזהים נשארים זהים, והכתובת נבנית מחדש בכל הצגה. בכתובת קריאה הכתובת משתנה יחד עם הקוד, וקישורים שפורסמו לפני כן מחזירים 404 עד שנוצרים עבורם כללי הפניה.
בנוסף, אותו רכיב נעשה נגיש גם בכתובת הקריאה וגם בכתובת הדינמית — שני עמודים עם תוכן זהה. כאן בדיוק נדרשת כתובת קנונית: <link rel="canonical"> מצביע על ה-URL הראשי, והשאר לא מאונדקסים כעמודים עצמאיים.
| וריאנט | מתי מתאים | מגבלות |
|---|---|---|
| דינמי | מסננים, ייצואים, עמודים עם שפע פרמטרים | הכתובת אינה קריאה ומאבדת פרמטרים בעת העתקה |
| כתובות קריאות לפי קודים סימבוליים | קטלוג, מאמרים, כרטיסים — כל מה שמאונדקס | נדרשים קודים ייחודיים וכללי הפניה בעת החלפת כתובת |
| כתובות קריאות + פרמטרים | מיון ומסננים בתוך מדור עם כתובת קריאה | הצירופים מולידים כפילויות — בלי canonical לא ניתן להסתדר |
בחירת מצב הכתובות מוכתבת על ידי ייעוד המדור: במקום שבו הקישור נמסר ללקוח או לשותף נדרשת כתובת קריאה, ולטעינות שירותיות מספיקים פרמטרים — עם סגירת העודפים מפני אינדוקסציה.