איך למצוא redirect chains ו-loops לפני שהן פוגעות ב-SEO

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

במיגרציות אתר, החלפת דומיין, מעבר ל-HTTPS או ניקוי CMS ישן, שתי הבעיות האלה מופיעות מהר. כל צוות רואה חלק אחר מהמערכת: SEO רואה URL ישנים, developers רואים שרת או CDN, marketing רואה קמפיינים, ו-platform רואה DNS. השרשרת נוצרת בדיוק בין השכבות האלה.

למה chain קטן הופך לבעיה

שרשרת כזו נראית תמימה:

http://old-brand.example/page
  -> https://old-brand.example/page
  -> https://www.old-brand.example/page
  -> https://new-brand.example/page
  -> https://new-brand.example/he/page

כל hop בפני עצמו "נכון". יחד הם יוצרים מסלול ארוך, איטי וקשה לניהול. עבור משתמשים זה מוסיף latency. עבור crawler זה מבזבז crawl budget ומקשה להבין מה היעד הסופי. עבור צוות תפעול זה מסתיר את המקום האמיתי שבו ה-rule יושב.

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

איפה loops נוצרים

Loops נוצרים כששתי שכבות מנסות "לתקן" את אותו URL בכיוונים שונים.

דוגמאות נפוצות:

• CDN מוסיף trailing slash, וה-CMS מסיר אותו.
• rule אחד מעביר www ל-non-www, ו-rule אחר עושה ההפך.
• Cloudflare rule מעביר ל-HTTPS, וה-origin מחזיר ל-HTTP פנימי.
• locale routing מעביר /he/page אל /page, ואפליקציה מוסיפה שוב /he.
• regex רחב מדי תופס גם את יעד ההפניה.

הסוג האחרון מסוכן במיוחד. כלל כמו ^/(.*)$ -> /new/$1 יכול לתפוס גם /new/page אם אין guard, וכך ליצור loop או path שמתנפח בכל hop.

סימנים שצריך לבדוק

בדיקה ידנית של כמה URLs אינה מספיקה. חפשו סימנים כאלה:

• מעבר דרך יותר מ-hop אחד לפני 200.
• status code משתנה בין mobile ל-desktop בלי סיבה.
• 301 שמוביל ל-302 ואז שוב ל-301.
• URL עם UTM שמאבד query באמצע השרשרת.
• יעד סופי שמחזיר 404 או 5xx.
• הבדל בין תוצאה מ-browser לתוצאה מ-curl.
• redirect שמופיע רק אחרי CDN cache clear.

בפרויקט ישראלי טיפוסי, כדאי להוסיף גם קישורי WhatsApp, LinkedIn ו-QR לרשימת הבדיקות. הם מגיעים דרך in-app browsers ולעיתים מפעילים user agent אחר.

תהליך בדיקה

1. התחילו מה-URL הישן ביותר

בדקו את ה-source שהמשתמשים וה-crawlers באמת פוגשים, לא רק את הכתובת החדשה. אם דומיין ישן עדיין מקבל links, הוא חלק מהבדיקה.

2. רשמו כל hop

לכל hop תעדו:

• source.
• status code.
• Location.
• האם query נשמר.
• האם host או path השתנו.
• האם היעד מחזיר 200.

3. הפרידו בין בעיית status לבעיית ארכיטקטורה

לפעמים כולם מתווכחים האם להשתמש ב-301 או 302, אבל הבעיה האמיתית היא שיש ארבעה hops. תקנו קודם את המסלול.

4. איחדו כללים כשאפשר

במקום:

http://old-brand.example/a -> https://old-brand.example/a
https://old-brand.example/a -> https://new-brand.example/a
https://new-brand.example/a -> https://new-brand.example/resources/a

עדיף, כשזה אפשרי:

http://old-brand.example/a -> https://new-brand.example/resources/a

5. בדקו חריגים

שרשראות רבות מסתתרות בחריגים:

• דפי מוצר שהוסרו.
• blog slugs ששונו ידנית.
• path עם אותיות גדולות.
• query parameters.
• locale prefixes.
• trailing slash.

איך למנוע chains במיגרציה

לפני launch:

1. בנו redirect map מלא.
2. הגדירו יעד סופי, לא יעד ביניים.
3. בחרו canonical host לפני כתיבת rules.
4. החליטו איך מטפלים ב-trailing slash וב-lowercase.
5. בדקו את ה-map על staging.
6. פרסמו בקבוצות אם המפה גדולה.

ביום launch:

• בדקו דוגמאות מכל template.
• בדקו URL עם UTM.
• בדקו דפי top traffic.
• בדקו mobile ו-desktop.
• עקבו אחרי 404 ו-loop errors.

אחרי launch:

• נקו internal links שעדיין קוראים לכתובות ישנות.
• עדכנו sitemap.
• בדקו Search Console.
• השאירו redirect monitor לפחות כמה שבועות.

דוגמה: locale prefix כפול

באתרים מרובי שפות, קל ליצור prefix כפול בכתובות פנימיות. זה קורה כאשר תוכן כבר מחזיק prefix, והרכיב שמייצר href מוסיף prefix שוב.

הכלל הבריא:

• תוכן פנימי משתמש בנתיב לוגי כמו /blog/post.
• helper אחד אחראי להוסיף locale prefix.
• בדיקות HTML מחפשות duplicate prefixes.

זה חשוב במיוחד בשפות RTL, כי קל להתמקד בטקסט ולפספס בעיית routing.

איך UrlEdge עוזר

בודק ההפניות נותן תמונה של המסלול בפועל: status code, hops ויעד סופי. במיגרציות גדולות, ניהול bulk redirects עוזר לבדוק redirect map במקום להתעסק בכל URL בנפרד. אחרי launch, ניטור קישורים שבורים עוזר לראות יעדים שבורים שלא הופיעו בבדיקות ידניות.

המטרה אינה למצוא "כלי בדיקה". המטרה היא שבעל הכללים יראה את אותו מסלול שהמשתמש או crawler רואים.

FAQ

האם redirect chain אחד פוגע ב-SEO?

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

כמה hops הם יותר מדי?

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

איך יודעים אם יש loop?

כלי בדיקה יציג חזרה ל-URL קודם או חריגה ממספר hops. Browser בדרך כלל יציג שגיאה על too many redirects.

האם צריך לבדוק גם redirects מתוך האפליקציה?

כן. CDN, worker, framework middleware, CMS ו-origin יכולים כולם להוסיף redirect. בדיקה טובה עוברת דרך כל המסלול.