301 רידיירקט ב-1С-Битрикс: היכן הולך לאיבוד טראפיק בעת העברת אתר
העברת אתר לדומיין חדש, שינוי ЧПУ או העברת קטלוג לענף אחר במבנה — כל אלה הם תמיד נתק בין הכתובות הישנות לחדשות. רובוט החיפוש מגיע לקישור מתוצאות החיפוש, מקבל 404, ואחרי כמה סריקות מוציא את העמוד מהאינדקס.
אם 301 רידיירקט אינו מוגדר, יחד עם העמוד הולכות לאיבוד גם העמדות שנצברו, משקל הקישורים והאותות ההתנהגותיים, והשחזור אורך חודשים. נבחן היכן בדיוק הולך לאיבוד הטראפיק וכיצד זה נסגר.
התרחיש הראשון — החלפת דומיין ללא כלל חובק. ב-1С-Битрикс הכתובות חיות בשלושה מקומות: כללי עיבוד הכתובות בהגדרות המודול, קבצי .htaccess ברמת שרת האינטרנט והמבנה הפיזי של הספריות. אם הכלל נוסף רק בשכבה אחת, חלק מהכתובות הישנות מחזירות 404, וחלק — 200 עם כפילות תוכן. הכפילויות מדללות את המשקל בין העותקים, ובחיפוש מתקבעת לא הגרסה שקידמתם.
התרחיש השני — איחוד מראות. כאשר האתר נגיש גם עם www וגם בלי, ובשני הפרוטוקולים, מנוע החיפוש רואה ארבעה עותקים של אותו תוכן. הכתובת הקנונית צריכה להיות אחת, וכל השאר — להחזיר 301 אליה.
בלי זה robots.txt ומפת האתר מצביעים על גרסאות שונות, הסריקה מתבצעת בחוסר אחידות, והעמודים מתחרים בעצמם.
התרחיש השלישי — שינוי מבנה הקטלוג או המדור. הכתובות הישנות של מוצרים ומאמרים נשארות בסימניות של אחרים ובקישורים חיצוניים, והחדשות מופיעות רק בניווט הפנימי. כאן חשובה מפת ההתאמות: לכל כתובת ישנה — היעד שלה, ולא ערימה של הכול לדף הבית. רידיירקט המוני "הכול לדף הבית" מנוע החיפוש קורא כ-404 רך ומאפס את משקל העמוד.
בנפרד יש להתייחס להעברה תוך שמירת פרמטרים. כתובות עם תגי UTM, מסננים ועימוד אסור לרידיירקט באופן עיוור — אחרת יודבקו עמודי תוצאות המסנן והזנב הארוך יאבד. הכלל צריך לפעול על הנתיב ללא פרמטרים, ואת מחרוזת ה-query להעביר בנפרד.
כל אחד מהתרחישים הללו מאובחן לפי לוגים של שרת האינטרנט ודוחות שגיאות סריקה: רואים אילו כתובות ישנות עדיין מקבלות בקשות ומה הן מחזירות בתגובה. מכאן — שאלה של מפת רידיירקטים מדויקת וסדר הפעלתה.
מה נותנת הגדרה נכונה של הפניות
הפניה נכונה היא לא "הפניה לשם הפניה", אלא דרך לשמר את המשקל המצטבר של העמוד בעת שינוי הכתובת שלו. כאשר הכלל מחזיר קוד קבוע במקום זמני, מנוע החיפוש מעביר אותות מהכתובת הישנה לחדשה: מיקומים, קישורים חיצוניים, היסטוריית חשיפות.
אם הקוד זמני, המשקל נשאר בכתובת הישנה, והחדשה לא מצליחה להיכנס לטופ במשך חודשים — התנועה יורדת, למרות שהתוכן לא השתנה.
המשימה השנייה היא איחוד כתובות ומאבק בכפילויות. אותו מוצר זמין בכתובת עם www ובלעדיה, עם סלאש ובלעדיו, עם פרמטרים של סינון ומיון — עבור מנוע החיפוש אלו עמודים שונים שמתחרים ביניהם ומטשטשים את הרלוונטיות.
הכללים מביאים את כל הווריאציות לכתובת קנונית אחת, ולאינדקס נכנס עמוד אחד במקום חמישה. זה משפיע ישירות על המיקומים: המשקל לא מתחלק בין העתקים, אלא עובד עבור כתובת אחת.
האפקט השלישי הוא צפיות בעת שינוי מבנה. מעבר למדור חדש, שינוי כתובות ידידותיות, איחוד קטלוגים — כל אלו שוברים קישורים ישנים, אם לא מכינים מפת הפניות מראש. כאשר הכללים מתוארים ונבדקים לפני העלייה לאוויר, המבקרים והרובוטים מגיעים לעמוד עדכני, ולא לשגיאה.
קישורים חיצוניים וסימניות ממשיכים לעבוד, גורמי התנהגות לא יורדים, והאינדוקס נבנה מחדש בצורה חלקה, בלי שמדורים נופלים מהתוצאות.
בפועל זה נראה כך: לפני השינויים מתעדים את המיקומים והתנועה הנוכחיים בכתובות המרכזיות, אחרי — בודקים שאף כתובת לא מחזירה שגיאה ולא מובילה לשרשרת של כמה מעברים. שרשראות ולולאות — אלו סוג נפרד של בעיות: הדפדפן והרובוט מסתובבים במעגל, העמוד לא נפתח, והסיבה לא נראית בממשק. לכן הכללים נאספים במקום אחד, נבדקים על רשימה מלאה של כתובות, ורק אחר כך מפורסמים.
דרכים להגדרת הפניות: השוואת גישות
ניתן ליישם הפניות ב-1С-Битрикс בשלוש רמות — והבחירה ברמה קובעת מי וכמה מהר יוכל לערוך את הכללים בהמשך. הגדרת השרת מספקת השהיה מינימלית בהחזרת התשובה, אך כל עריכה דורשת גישה לקונפיגורציה והפעלה מחדש.
המודול של Битрикс שומר את מפת ההפניות במסד הנתונים, ולכן הכללים מתווספים דרך ממשק הניהול ללא פריסה. אפשרות משולבת — כאשר כללים סטטיים נמצאים בשרת, וכללים המשתנים לעתים קרובות במודול.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| הגדרת שרת | הפניות טכניות המוניות: החלפת דומיין, איחוד מראות, הסרת כפילויות עם סלאש | עריכות רק דרך קונפיג, אין היסטוריית שינויים, כאשר נפח הכללים גדול זמן עיבוד הבקשה גדל |
| מודול Битрикс | כללים המשתנים באופן קבוע, קישור למדורים ולמוצרים, עבודת מנהל תוכן | הכלל מופעל לאחר אתחול הליבה — מעט איטי יותר מאשר בשרת, חלק מהבקשות לסטטיקה מעובדות קודם |
| מפת הפניות בקובץ | העברת מערך גדול של כתובות ישנות בעת מיגרציה, העלאה חד-פעמית | יש לתעד את הקובץ בגרסאות ידנית, בעת התנגשות עם כללי השרת סדר ההפעלה אינו ברור |
| כללים בתבנית | מקרים נקודתיים התלויים בלוגיקת העמוד | מתערבב עם הקידוד, קשה להעביר לתמיכה, קל לאבד בעת עדכון התבנית |
בפועל לרוב משלבים: השרת מטפל בהפניות תשתיתיות, המודול — בתוכן, ומפת ההפניות משמשת ככלי חד-פעמי למיגרציה. חשוב לבנות סדר הפעלה: תחילה כללי השרת, לאחר מכן המודול, אחרת אותה כתובת עשויה לצאת בשתי שרשראות ולקבל לולאה. לפני הפריסה בודקים את המפה לאיתור התנגשויות ולולאות — לאחר השחרור איתור הבאגים יקר יותר.
אם באתר כבר הצטברו כללים ממקורות שונים, אנו תחילה אוספים אותם למפה אחודה, מסירים כפילויות ורק לאחר מכן מפזרים לפי רמות.
סדר העבודה: מביקורת כתובות ועד לבדיקה
אנחנו בונים את העבודה כך שאף כתובת ישנה לא תאבד ולא תהפוך לשרשרת של כמה הפניות. תחילה אנחנו אוספים תמונה מלאה: ייצוא כתובות מהלוגים, ממפת האתר, ממנועי החיפוש ומקישורים פנימיים, והצל�בה עם המבנה של האתר החדש.
בשלב הזה חשוב לתפוס כתובות עם פרמטרים, רישיות ולוכסן בסוף — דווקא הן לרוב יוצרות כפילויות ושגיאות "רכות".
לאחר מכן מתכננים את הכללים: מתאימים כתובת ישנה לכתובת חדשה אחד לאחד, מסירים חוליות ביניים, ומתארים בנפרד הפניות תבניתיות עבור מדורים ועימוד. לאחר אישור מפת ההפניות עוברים ליישום ולבדיקה.
- ביקורת כתובות — מייצאים את כל הכתובות הישנות מהלוגים, ממפת האתר וממקורות חיצוניים, ומסמנים עמודים עם תנועה וקישורים נכנסים.
- הצל�בה עם המבנה — מתאימים כל כתובת ישנה לחדשה, מתעדים כתובות ללא מקבילה ישירה ומחליטים לאן להוביל אותן.
- תכנון כללים — מתארים את מפת ההפניות: זוגות נקודתיים, תבניות למדורים, טיפול בפרמטרים וברישיות.
- יישום — מגדירים כללים ברמת השרת ובמנוע עצמו, כך שההפניה תפעל לפני הגשת העמוד.
- בדיקת הפניות — מריצים את כל הרשימה, בודקים קוד תגובה, היעדר שרשראות ומחזורים, ושימור פרמטרים.
- בקרה לאחר ההשקה — מצליבים אינדוקס ולוגים, מסירים שגיאות שנותרו, ובמידת הצורך מתקנים את הכללים.
- מסירה — מוסרים את מפת ההפניות ואת ההוראות להוספת כללים חדשים לצוות שלכם.
כל שלב מסתיים בתוצאה ניתנת לבדיקה, ולכן בסוף אתם מקבלים לא אוסף של כללים מפוזרים, אלא מפה מנוהלת שאפשר להרחיב בלי סיכון לשבור כתובות קיימות.
מה הלקוח מקבל בסיום העבודה
העבודה אינה מסתיימת בעובדה ש"ההפניות הוגדרו", אלא בסט של תוצרים שלפיהם המערכת ממשיכה לפעול בלעדינו. כל סעיף להלן הוא מה שנשאר בידי הצוות שלכם: ניתן להעבירו לספק חדש, לבדוק אותו בסקירה או להרים אותו בעת ניתוח ירידה בתעבורה.
- מפת הפניות — טבלה "כתובת ישנה → כתובת חדשה → סוג כלל → מקור" עבור כל הדפים שהוסרו מפרסום, המדורים והכתובות הישנות לאחר שינוי המבנה. נאספת מיומני הביקורים ומפת האתר, ולא "מהזיכרון": כך נכנסות אליה כתובות שאיש אינו זוכר, אך עדיין מגיעים אליהן מהחיפוש ומקישורים חיצוניים.
- תצורת כללים — הכללים עצמם, מסודרים לפי רמות: כתובות קבועות בתצורת השרת, תבניות גורפות במודול ההפניות, חריגים בודדים — בנפרד. ההפרדה נדרשת כדי שעריכת דף אחד לא תפגע בשאר ולא תהפוך לעריכת כל הקובץ.
- נוהל לטיפול בכתובות — סדר הפעולות בעת הסרת דף מפרסום, שינוי כתובת מדור, איחוד כפילויות והעברת קטלוג. עמו, מנהל תוכן חדש אינו יוצר קישורים שבורים, משום שהמסלול "הסיר דף → הוסיף כלל → בדק" מתואר לפני שהדבר נדרש.
- תיעוד לתמיכה — היכן נמצאים הכללים, כיצד להוסיף חדש, כיצד להחזיר שגוי לאחור, ואילו בדיקות להריץ לאחר העלאה. בבלוק נפרד — שגיאות אופייניות: שרשראות של כמה מעברים, כללים לכתובת שאינה קיימת, התנגשות בין תבנית לחריג.
- דוח בדיקה — רשימת הכתובות שעבורן בוצעה בדיקת קודי התגובה, ורשימת השרשראות שנמצאו וטופלו. זהו הוכחה שהכללים עובדים, ולא רק רשומים.
- הרשאות ונקודות בקרה — היכן לראות יומני מעברים, אילו דוחות מציגים את שיעור השגיאות, ולמי לפנות בעת אי-התאמה. כדי שהאבחון לא יתחיל בחיפוש אחר מי שנגע לאחרונה בתצורה.
את כל האמור לעיל אנו מוסרים בקונטור שלכם: הכללים, הנוהל והתיעוד נשארים במאגר הפרויקט ובבסיס הידע, ולא בהתכתבות. תארו את המשימה — נחזור עם הערכה ותוכנית, באיזה סדר לאסוף את התוצרים הללו עבור מבנה האתר שלכם.
מקרה בוחן: שחזור מיקומים לאחר שינוי מבנה
הפרויקט — חנות מקוונת על 1С-Битрикс עם קטלוג של כמה אלפי פריטי סחורה. בעת העברה למבנה חדש של מדורים ושינוי שמות קטגוריות השתנו כתובות הכרטיסים והרשימות, אך מפת ההפניות נשארה מהמיגרציה הקודמת: חלק מהכללים הובילו לעמודים שבורים, וחלק — למדורים כלליים במקום למוצרים ספציפיים.
כשבועיים לאחר השחרור מנועי החיפוש כבר הראו ירידה בשאילתות מסחריות, והתנועה מאורגנית ירדה באופן מורגש יותר מהצפוי.
מה עשינו
תחילה הפיקו חיתוך מלא של הכתובות הנוכחיות והשוו אותן לכתובות ההיסטוריות מיומני השרת ומייצוא מערכות האנליטיקה. עבור כל זוג "כתובת ישנה → כתובת חדשה" נקבעה התאמת יעד: כרטיס מוביל לכרטיס, מדור — למדור, ולא לעמוד הבית.
הכללים רוכזו במקום אחד, נבדקו לסתירות וללולאות, ובנפרד טופלו שרשראות של שתי הפניות ויותר — הן כווצו לצעד אחד כדי לא לאבד ממשקל הקישור.
לאחר מכן הוגדרה החזרת הפניה קבועה ברמת השרת, ולא דרך סקריפטים — כך התשובה מגיעה מהר יותר ואינה תלויה בעומס האפליקציה. עבור כתובות שלא נמצאה להן התאמה ישירה, נכתבו כללים תוך שמירה על מבנה ה-URL: קטגוריה ופרמטרי סינון מועברים לכתובת החדשה באופן אוטומטי.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| שיעור הכתובות עם הפניה תקינה | 41% | 96% |
| עמודים באינדקס עם שגיאה | ~1 800 | < 60 |
| שחזור מיקומים לפי שאילתות מובילות | — | 3-5 שבועות |
| תנועה אורגנית | ירידה | חזרה לרמה הקודמת וצמיחה |
שלושה שבועות לאחר התיקונים עיקר השאילתות המסחריות חזרו למיקומים הקודמים, וחלקן — גבוה מהמקוריים: הכתובות הישנות כבר לא התחרו עם החדשות, ומשקל הקישורים הפסיק להתפזר. בנפרד נקבע כלל לעתיד: כל שינוי מבנה עובר דרך מפת הפניות לפני השחרור, ולא אחריו.
במה שונה הפניית 301 מ-302 ומתי זה חשוב
הפניית 301 היא הפנייה קבועה: השרת מודיע למנוע החיפוש שהדף עבר באופן סופי, וכל המשקל שנצבר לכתובת צריך לעבור לכתובת החדשה. הפניית 302 היא זמנית: הכתובת הישנה נשארת הראשית, והחדשה נחשבת לזמנית בלבד. ההבדל הוא בקוד תגובה אחד, אבל בדיוק ממנו תלוי איזה דף ייכנס לאינדקס והאם יישמר לו התעבורה הקודמת.
המכניקה פשוטה: בהפניית 301 מנוע החיפוש מקבע את הכתובת החדשה כקנונית לאחר מספר סריקות, ואת הישנה מסיר בהדרגה מתוצאות החיפוש. בהפניית 302 הכתובת הישנה שומרת על מעמדה כראשית, והחדשה עשויה כלל לא להיכנס לאינדקס — המערכת ממשיכה לפנות לכתובת הישנה, בציפייה שה"זמניות" תסתיים.
אם הפניית 302 נשארת חודשים ארוכים, זה נראה כשגיאת תצורה: המיקומים נחלשים, מכיוון ששני הדפים מתחרים זה בזה, והמשקל אינו מתאחד.
בפועל, בחירת הקוד נקבעת לפי התרחיש. מעבר לדומיין חדש, שינוי מבנה הקטלוג, איחוד כפילויות עם www ובלעדיו, מעבר מ-http ל-https, איחוד כרטיסי מוצר — כל אלה שינויים קבועים, וכאן נדרש רק 301.
הפניית 302 זמנית מתאימה כאשר הכתובת תחזור: עבודות תחזוקה, בדיקת A/B של דף נחיתה, מבצע עונתי, הגבלת גישה לחלק מהקהל. ברגע שהסיבה נעלמה, ההפנייה מוסרת.
בנפרד יש להתייחס לשרשרת הפניות. כאשר הפניית 301 מובילה לכתובת שמחזירה בעצמה 301, מנוע החיפוש מבזבז סריקות לחינם ועשוי לא להגיע לדף הסופי. התצורה הנכונה היא מעבר אחד ישירות לכתובת הסופית, ללא חוליות ביניים. הדבר נכון גם למעגלים: אם A מפנה ל-B, ו-B מפנה בחזרה ל-A, שני הדפים נופלים מהאינדקס.
ב-1С-Битрикс הקודים מוגדרים בכללי עיבוד הכתובות, בהגדרות ההפניות ודרך מודול SEO — חשוב שהקוד יתאים לכוונה האמיתית, ולא יוצב "ליתר ביטחון". טעות בבחירה כאן עולה לא בקוסמטיקה, אלא במיקומים אבודים, שמוחזרים רק לאחר חודשים.
ספקות טכניים נפוצים בעת ההגדרה
לפני אישור מפת ההפניות, לקוחות בדרך כלל שואלים את אותן שאלות — על שרשראות, התנגשויות עם מודולים והתנהגות בעת החלפת דומיין. להלן תשובות שמסירות את רוב הספקות עוד לפני תחילת העבודה.
מה יקרה אם באתר כבר הצטברו שרשראות הפניות?
שרשרת של שתיים-שלוש הפניות היא סיבובים מיותרים עבור רובוט החיפוש ואובדן חלק ממשקל הקישורים בכל שלב. אנו אוספים את כל הכללים מהגדרות השרת, המודול וקובץ .htaccess, מאחדים אותם לטבלה אחת ומכווצים אותם להפניות ישירות "כתובת ישנה → סופית". בתוצאה — תשובה אחת במקום שלוש, התנהגות צפויה ומפה ברורה שנראית בשלמותה.
האם הכללים יכולים להתנגש עם מודולים ורכיבים?
כן, וזו הסיבה הנפוצה ביותר ל"ההפניה מוגדרת, אבל לא עובדת". כללים ברמת השרת פועלים לפני שהמודול מספיק לעבד את הכתובת, לכן חלק מההפניות פשוט לא מגיעות לאפליקציה. אנו בודקים את סדר העיבוד ומפרידים את הכללים כך שכללי השרת והכללים הפנימיים לא יחפפו זה לזה. לאחר מכן ההפניות פועלות באופן יציב בכל סוגי הכתובות.
מה קורה עם הפניות בעת החלפת דומיין?
הדומיין הישן ממשיך לקבל תעבורה, ואי אפשר פשוט לכבות אותו — אחרת ההפניות ינותקו. אנו מגדירים את הכללים כך שכל כתובת של הדומיין הישן תוביל לכתובת המתאימה לה בדומיין החדש, כולל מדורים מקוננים ופרמטרים. בנפרד אנו בודקים שההפניות לא נכנסות ללולאה ולא מאבדות כתובות עם סיומות לא סטנדרטיות.
כיצד לוודא שההגדרה לא שברה כתובות קיימות?
לפני הפרסום אנו מריצים את רשימת הכתובות המרכזיות ובודקים את קוד התגובה בכל אחת: היכן שאמורה להיות הפניה ישירה — היא קיימת, היכן שהדף חי — הוא מוגש כמו קודם. אם כלל נוגע במדור פעיל, זה נראה לפני הפרסום, ולא לפי ירידה בתעבורה אחרי שבוע. את התיקונים מבצעים אחד-אחד, כך שתמיד ניתן להחזיר את המצב הקודם.
בואו נדון במשימה שלכם בנושא הפניות מחדש
הפניות מחדש כמעט אף פעם לא קיימות בוואקום: הן צצות בעת שינוי מבנה הקטלוג, העברת מדורים, איחוד כפילויות לאחר מיתוג מחדש או מעבר לתבנית חדשה.
לכן את השיחה אנחנו מתחילים לא ממחירון, אלא ממפת הכתובות הנוכחית שלכם: אילו כתובות URL משתנות, כמה הן, האם כבר יש היסטוריית הפניות מצטברת ומה מצב האינדוקס כעת.
כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות, אנחנו צריכים מינימום של נתוני פתיחה. תארו את המשימה בצורה חופשית — בהמשך נבהיר את הפרטים בעצמנו.
- המצב הנוכחי: מה משתנה — מבנה הקטלוג, הדומיין, התבנית, מדור או עמודים בודדים.
- רשימת כתובות: האם יש ייצוא של כתובות URL ישנות וחדשות, ובאיזה פורמט — טבלה, לוג שרת, מפת אתר.
- הסיבה: מעבר, איחוד כפילויות, שינוי כתובות ידידותיות, מחיקת מדור או שחזור לאחר תקלה.
- מגבלות: דדליין, חלון זמן השבתה, דרישות לשימור מיקומים ותנועה.
- מה כבר נעשה: האם ניסיתם להגדיר כללים בעצמכם, אילו שגיאות אתם רואים.
- גישות וסביבה: מהדורת המוצר, האחסון, האם יש סביבת בדיקה לבדיקת שרשראות.
- קריטריון מוכנות: מה נחשב בעיניכם לתוצאה — היעדר הפניות שבורות, שימור מיקומים, לוג נקי.
לפי נתוני פתיחה אלה נבנה תוכנית עבודה: ביקורת של הכתובות הנוכחיות, תכנון מפת ההפניות, הגדרת כללים ברמת השרת ובלוח הבקרה, בדיקת שרשראות וקודי תגובה, בקרת אינדוקס לאחר ההטמעה. את ההערכה ניתן לפי היקף — מתיקון נקודתי ועד הגירת מבנה מלאה.
אם המצב דחוף והאתר כבר מאבד תנועה — כתבו זאת כך, ונטפל בסדרי העדיפויות ראשונים. תארו את המשימה, ואנחנו נחזור עם הערכה ותוכנית עבודה.