העברת אתר ללא אובדן: הגדרה נכונה של הפניות 301

הפניית 301 לא עובדת: היכן נשבר המעבר ולאן נעלמת התנועה

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

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

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

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

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

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

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

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

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

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

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

שיטות הפניה: מתי איזה מצב מתאים

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

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

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

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

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

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

1. ביקורת כתובות. אוספים מפה מלאה של נקודות כניסה: יומני שרת אינטרנט מכמה חודשים, מפת אתר, דוחות אינדוקס, קישורים חיצוניים. נכנסות אליה כתובות עם פרמטרים, סלאש בסוף וברישיות שונה — דווקא הן נשארות לרוב בלי זוג.
2. מתכננים מערך הפניות. כל כתובת ישנה מקבלת בדיוק יעד אחד, בלי שרשראות וחוליות ביניים: כמה מעברים ברצף טורפים משקל וזמן תגובה. לעמודים בלי מקבילה שמים קוד ישר של «נמחק» במקום שליחה לעמוד הבית.
3. אוספים סביבת בדיקה. עותק של המבנה והכללים בעמדת בדיקה נפרדת: מריצים את מפת הכתובות בסקריפט ומשווים קודי תגובה, כותרות ונקודות יעד סופיות.
4. מגדירים הפניות. ברמת שרת האינטרנט או מאזן העומסים, ולא בסימון העמוד — כך הכלל פועל לפני מסירת התוכן ואינו תלוי במנוע.
5. בדיקת כיסוי. משווים את הרשימה מהביקורת לתגובות בפועל: סופרים את שיעור הכתובות שמחזירות קוד תקין ומוודאים שלא נוצרו שרשראות חדשות.
6. החלפה וניטור. לאחר ההפעלה עוקבים אחר קודי התגובה בכתובות לשעבר ואחר דינמיקת הכניסות דרכן; פערים סוגרים נקודתית.
7. תוכנית חזרה לאחור. קונפיגורציית הכללים מנוהלת גרסאות לצד הפרויקט: אם המבנה לא התקבל היטב, החזרה למערך הקודם אורכת דקות, בלי עריכה ידנית של סביבת הייצור.

מפת הפניות, יומנים ונוהלי עדכון

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

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

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

מיגרציה של חנות אינטרנטית: תנועה ומיקומים לפני ואחרי

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

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

כיצד הגדרנו את המעברים

על בסיסה פרשׂנו הפניות 301 — בדיוק מעבר אחד, בלי שרשראות «ישן — ביניים — חדש»: כל צעד מיותר מאבד משקל קישור ומגדיל את זמן התגובה. כתובות שירות של מסננים ומיון סגרנו מפני אינדוקס, ולעמודי עימוד כתבנו כללים נפרדים כדי שמנועי החיפוש לא יאספו רשימות ריקות.

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

מה יצא

בשבוע הראשון לאחר המעבר ירד שיעור המעברים מחיפוש ב-12% — תגובה צפויה לשינוי כתובות. עד השבוע השלישי הנראות התאוששה ל-95% מהקודמת, וכעבור חודשיים — ל-104%: המבנה החדש של הקטעים הוסיף כיסוי בזכות שאילתות מדויקות יותר. שגיאות 404 נותרו על 0,4% מכלל הפניות במקום 6% בימים הראשונים — הן הוסרו בכללים נקודתיים לפי הלוגים.

במה שונה הפניית 301 מהפניה זמנית?

301 — העברה קבועה: מנוע החיפוש מחליף את הכתובת הישנה בחדשה באינדקס ומעביר אליה את האותות המצטברים. הפניה זמנית (302 ו-307) אומרת ההפך — הכתובת תחזור, לכן כתובת ה-URL המקורית נשארת העיקרית, והחדשה מדורגת כעמוד נפרד. מכאן גם ההבדל: בהפניית 301 משקל העמוד עובר, בזמנית — נשאר במקום.

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

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

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

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

ספקות טכניים: שאלות על הפניות ואיחוד

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

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

האתר כבר עבר, אבל חלק מהכתובות מחזירות שגיאה — מה לעשות?

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

איך לוודא שהכתובות החדשות נכנסו לאינדקס?

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

אנחנו שוב משנים מבנה — יהיה צורך לכתוב מחדש את הכללים?

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

נדון במיגרציה שלכם: מה לשלוח להערכה ולתוכנית

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

• ייצוא הכתובות הנוכחיות: מפת אתר, לוג שרת לחודש-חודשיים, טבלת כתובות עם תדירות פניות.
• מבנה האתר החדש: רשימת קטעים וכתובות, כדי להתאים ישנות לחדשות אחד לאחד ולא להשאיר עמודים «תלויים».
• כללים פעילים: הפניות ברמת שרת האינטרנט והפרוקסי ההפוך, robots.txt, כתובות קנוניות, הגדרות עימוד ופרמטרים בקישורים.
• מקרים מיוחדים: גרסאות שפה, קטעים סגורים, מסמכים וקבצים, כתובות עם סלאש בסוף ובאותיות גדולות.
• גישות: סביבת בדיקה, פאנל אחסון, מאגר קוד עם קונפיגורציה — נבדוק קודי תגובה ושרשראות הפניות לפני המעבר, ולא אחריו.
• תאריכים: חלון המעבר הרצוי ותקופות שבהן אסור לגעת באתר הייצור.

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