Redirect error ב-Google Search Console: סיבות ופתרונות

מה המשמעות של "Redirect error" ב-Search Console

"Redirect error" הוא אחת הסיבות בטבלה "Why pages aren't indexed" בדוח Page indexing של Google Search Console. הוא מופיע כש-Googlebot עוקב אחרי הפניה מהכתובת שלכם אבל אף פעם לא נוחת ביעד שהוא יכול לסרוק, כך שלא הכתובת המקורית ולא היעד מאונדקסים דרך המסלול הזה.

קל לבלבל אותו עם "Page with redirect", אז נבהיר: הסטטוס ההוא תקין. הוא אומר שההפניה עבדה: הכתובת לא מאונדקסת כי היא מצביעה למקום אחר, ו-Google מעריך את היעד בפני עצמו. "Redirect error" אומר שההפניה עצמה נכשלה.

תמצאו אותו תחת Indexing › Pages. לחצו על השורה "Redirect error" כדי לראות את הכתובות המושפעות, והשתמשו ב-Export כדי להוריד את הרשימה המלאה.

הסיבות הנפוצות ל-"Redirect error"

התיעוד של דוח Page indexing של Google מפרט ארבעה מצבים שעומדים מאחורי הסטטוס הזה. שניים נוספים מופיעים לעתים קרובות בפועל.

1. שרשרת הפניות ארוכה מדי

כל כתובת שמפנה לכתובת אחרת מוסיפה קפיצה. הסורקים של Google עוקבים אחרי עד 10 קפיצות הפניה, לפי תיעוד הסריקה של Google. מעבר לזה Googlebot מוותר ו-Search Console מדווח על שגיאת הפניה. שרשראות בדרך כלל גדלות עם הזמן: כלל מ-HTTP ל-HTTPS, אחריו כלל ל-www, אחריו כלל לקו נטוי בסוף הכתובת, ומעל הכול העברת אתר.

2. לולאת הפניות

כתובת A מפנה לכתובת B, וכתובת B מפנה חזרה ל-A (או לכל כתובת שמובילה חזרה ל-A). השרשרת אף פעם לא מגיעה לסופה, ולכן אף דף לא מושג. לולאות נוצרות לעתים קרובות משני כללים שסותרים זה את זה, למשל אחד שמכריח קו נטוי בסוף הכתובת ואחר שמסיר אותו.

3. כתובת הפניה שחורגת מהאורך המרבי

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

4. כתובת שגויה או ריקה בשרשרת

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

5. יעד ש-Google לא יכול לסרוק

אם הכתובת הסופית חסומה ב-robots.txt, Googlebot לא יכול לאחזר אותה. בדקו שהיעד של כל הפניה ניתן לסריקה, ולא רק שהוא קיים.

6. כללי הפניה מתנגשים במקומות שונים

הפניות שמוגדרות ב-CMS, בתוסף, בשרת האינטרנט וב-CDN יכולות להצטבר זו על גבי זו או להתנגש. כלל שנוסף בשכבה אחת עלול להחזיר את הכתובת לכלל בשכבה אחרת, וכך נולדות רוב השרשראות והלולאות.

איך מאבחנים "Redirect error"

התחילו בכתובות המדויקות ש-Search Console מסמן, ואז התחקו אחרי מה שקורה כשמבקשים כל אחת מהן.

השתמשו ב-URL Inspection

הדביקו כתובת מושפעת בשורת הבדיקה בראש Search Console. הקטע Page indexing מראה מתי Google סרק אותה לאחרונה והאם אחזור הדף הצליח. לחצו על Test live URL כדי לבדוק את ההתנהגות הנוכחית, כי הדוח עלול לפגר אחרי התיקונים שלכם.

התחקו אחרי מסלול ההפניה המלא

בקשו את הכתובת ועקבו אחרי כל קפיצה. מהטרמינל:

curl -sIL https://example.com/old-page | grep -iE "^(HTTP|location)"

הפלט מציג כל קוד סטטוס וכל כותרת Location לפי הסדר. חפשו יותר מקפיצה אחת, כתובת שמופיעה פעמיים (לולאה), Location פגום, או תגובה אחרונה שאינה 200.

אם אתם מעדיפים לא להשתמש בטרמינל, ביקורת ה-SEO החינמית בדף Crawler של SEOcrawl AI סופרת את קפיצות ההפניה של כל כתובת, והכלי fetch_url של שרת ה-MCP של SEOcrawl AI מחזיר את הכתובת הסופית, את קוד הסטטוס ואת שרשרת ההפניות המלאה ישירות ב-Claude, ב-ChatGPT או ב-Cursor.

בדקו את קוד התגובה הסופי

ודאו שהכתובת האחרונה במסלול מחזירה 200, ולא עוד 3xx, 4xx או 5xx. כשהשרשרת מסתיימת בשגיאה, הבעיה נמצאת ביעד: עיינו במדריכים שלנו על Not found (404) ועל Blocked due to other 4xx issue.

איך מתקנים כל סיבה

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

• ›שרשרת ארוכה מדי: הפנו את הכתובת הראשונה ישירות לכתובת הסופית שמחזירה 200 והסירו את הקפיצות שביניהן. אם כמה כתובות ישנות מזינות את אותה שרשרת, עדכנו כל אחת מהן.
• ›לולאת הפניות: מצאו את שני הכללים שמצביעים זה על זה ומחקו או תקנו אחד מהם, כך שהמסלול יסתיים בדף אמיתי.
• ›כתובת ארוכה מדי: תקנו את הכלל שממשיך להוסיף לכתובת, ואז ודאו שהיעד נטען.
• ›יעד שגוי או ריק: תקנו את שגיאת ההקלדה או את ערך ה-Location הריק, והשתמשו בכתובות מוחלטות.
• ›יעד שחסום ב-robots.txt: אפשרו סריקה של היעד, או הפנו לכתובת שאינה חסומה.
• ›כללים מתנגשים: רכזו את ההפניות במקום אחד, כדי שה-CMS, השרת וה-CDN לא ידרסו זה את זה.

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

שיטות עבודה מומלצות להפניות

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

• ›השתמשו בקוד הסטטוס הנכון. הפניית 301 (או 308) היא אות חזק לכך שצריך לאנדקס את היעד: השתמשו בה למעברים קבועים. הפניית 302 (או 307) היא אות חלש שמשאיר את הכתובת המקורית בתוצאות: השתמשו בה רק כשהמעבר זמני.
• ›העדיפו הפניות בצד השרת. Google עוקב גם אחרי הפניות meta refresh מיידיות ואחרי הפניות JavaScript, אבל ממליץ להשתמש ב-JavaScript רק כשהפניות בצד השרת או meta refresh אינן אפשריות.
• ›שמרו על שרשראות קצרות. קפיצה אחת היא האידיאל. כל קפיצה נוספת מאטה את המשתמשים, מבזבזת תקציב סריקה ומוסיפה נקודת כשל.
• ›תמיד הפנו לכתובת שמחזירה 200, ואף פעם לא להפניה נוספת.
• ›עדכנו קישורים פנימיים ומפות אתר לכתובות הסופיות, כדי ש-Google והמבקרים שלכם ידלגו על ההפניה לגמרי.
• ›בדקו שוב אחרי כל העברת אתר או שינוי בכללי ה-CMS, השרת או ה-CDN, כי זה בדיוק הזמן שבו מופיעות שרשראות ולולאות חדשות.

איך מאמתים את התיקון

ברגע שההפניה נפתרת בקפיצה אחת לדף שמחזיר 200:

1. ›הריצו URL Inspection על כתובת מושפעת ולחצו על Test live URL כדי לוודא ש-Google מגיע עכשיו ליעד.
2. ›לחצו על Request indexing עבור הכתובות החשובות ביותר שלכם.
3. ›בדוח Page indexing, פתחו את הבעיה "Redirect error" ולחצו על Validate fix כדי ש-Google יסרוק מחדש כל כתובת מושפעת.
4. ›עקבו אחרי סטטוס האימות. זה יכול לקחת כמה ימים או כשבועיים; הכתובות יוצאות מהבעיה ככל שהן נסרקות מחדש.

הקדימו את שגיאות ההפניה

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

תצוגת Indexation של SEOcrawl AI מקבצת את הכתובות שלכם לפי מצב הכיסוי ב-Search Console, כך שתוכלו לראות אילו כתובות נמצאות במצב שגיאה ולעקוב אחרי השינוי במספרן לאורך זמן. אפשר לתייג את הכתובות המושפעות לפי כללים, ידנית או דרך שרת ה-MCP, ולעבוד עליהן עד שכל אחת נפתרת. אם אתם עובדים עם עוזר AI, ביקורת Google Search Console בודקת את כיסוי האינדקס שלכם מפרומפט אחד ופותחת משימה לכל תיקון.

שאלות נפוצות

מה גורם ל-"Redirect error" ב-Google Search Console?

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

איך מתקנים "Redirect error"?

הפנו את הכתובת המקורית ליעד הסופי שלה בקפיצה אחת. הסירו הפניות ביניים, שברו כל לולאה, ווודאו שהכתובת האחרונה מחזירה סטטוס 200. עדכנו את הקישורים הפנימיים כך שיצביעו על היעד, ואז הריצו URL Inspection ולחצו על Validate fix בדוח Page indexing.

מה זו שרשרת הפניות ומה זו לולאת הפניות?

שרשרת הפניות היא רצף של הפניות, שבו כתובת A מובילה ל-B, B מובילה ל-C וכן הלאה עד שמגיעים לדף הסופי. לולאת הפניות היא שרשרת שלא נגמרת לעולם, כי הכתובות מצביעות זו על זו. שתיהן יכולות למנוע מ-Google להגיע לדף ולאנדקס אותו.

301 או 302: במה כדאי להשתמש?

השתמשו ב-301 (או 308) למעבר קבוע: Google רואה בו אות חזק לאנדקס את היעד. השתמשו ב-302 (או 307) רק למעבר זמני, כשאתם רוצים שהכתובת המקורית תישאר בתוצאות החיפוש.

האם "Page with redirect" זהה ל-"Redirect error"?

לא. "Page with redirect" אומר שההפניה עבדה: הכתובת לא מאונדקסת כי היא מצביעה על דף אחר. "Redirect error" אומר ש-Google ניסה לעקוב אחרי ההפניה ולא הגיע אף פעם לדף תקין.

כמה זמן לוקח ל-"Redirect error" להיעלם?

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