خطأ إعادة التوجيه (حالة GSC)

الخلاصة — تعني حالة “Redirect error” في Google Search Console أن Google حاولت اتباع إعادة توجيه لصفحتك ولم تستطع؛ أي أن إعادة التوجيه معطلة بطريقة ما، ولذلك لم تُفهرس الصفحة. وهذه مشكلة يجب إصلاحها. لا تخلط بينها وبين “Page with redirect”، وهي إعادة توجيه عادية تعمل بصورة سليمة.

ما معنى “Redirect error”؟

تعني هذه التسمية أن Google صادفت إعادة توجيه لم تستطع اتباعها بنجاح إلى وجهة. Evidence for this claim Google reports Redirect error when it could not process a redirect to a destination. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report ويسرد تقرير Google السلاسل الطويلة والحلقات وطول عنوان URL المفرط وعناوين إعادة التوجيه السيئة أو الفارغة بوصفها أمثلة. Evidence for this claim Google lists overly long chains, loops, excessive redirect URL length, and bad or empty redirect URLs for this report status. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report

عندما تفتح تقرير Page Indexing في Google Search Console (تجده تحت “Indexing” في القائمة اليسرى)، تجمع Google عناوين URL التي لم تفهرسها حسب السبب. وRedirect error أحد هذه الأسباب.

يعني ذلك أن Google وجدت في عنوان URL إعادة توجيه — قاعدة ترسل الزوار من عنوان إلى آخر — وحاولت اتباعها، لكنها لم تصل إلى النهاية. ربما أشارت إعادة التوجيه إلى أخرى ثم ثالثة بلا نهاية، أو أعادت صفحتان التوجيه إحداهما إلى الأخرى في حلقة، أو كان العنوان المرسل إليه معطلاً أو فارغاً. أياً كان السبب، تخلت Google عن المحاولة، فلا يمكن فهرسة الصفحة.

الخطأ الوحيد الذي يقع فيه الناس

هناك حالة مختلفة تسمى “Page with redirect”، ويخلط الناس بينهما باستمرار. وهذا هو الفرق ببساطة:

• Redirect error = إعادة توجيه معطلة لم تستطع Google اتباعها. يجب إصلاحها.
• Page with redirect = إعادة توجيه عادية تعمل. اتبعتها Google بنجاح؛ لكن عنوان URL ليس النسخة «الرئيسية»، فلا يُفهرس (وقد تُفهرس الصفحة التي يشير إليها). ليست خطأً، ولا تحتاج عادةً إلى إجراء.

لذلك لا تقلق إذا رأيت “Page with redirect”؛ فهذا غالباً ما تريده بالضبط. أما “Redirect error” فتعني أن شيئاً معطلاً فعلاً.

ما الذي تفعله؟

تقوم فكرة الإصلاح غالباً على جعل إعادة التوجيه تصل مباشرة إلى الصفحة النهائية في قفزة واحدة بدلاً من الارتداد عبر سلسلة أو حلقة.

1. افتح أداة URL Inspection في Search Console (أو زر عنوان URL في المتصفح) لترى ما يحدث.
2. حدد موضع تعطل إعادة التوجيه: الحلقة أو العنوان المعطل أو السلسلة الطويلة.
3. استبدلها بإعادة توجيه واحدة (301) تشير مباشرة إلى الصفحة النهائية العاملة.
4. حدّث روابطك الداخلية لتشير إلى الصفحة النهائية أيضاً.
5. في Search Console، انقر Validate Fix لطلب إعادة الفحص.

هل تريد النسخة التقنية — أسباب Google الأربعة الدقيقة، وكيفية تتبع سلسلة من سطر الأوامر، وحقيقة عدد إعادات التوجيه التي ستتبعها Google؟ انتقل إلى المتقدم.

الخلاصة — ‏“Redirect error” حالة في Page Indexing بـ Google Search Console: حاول Googlebot اتباع إعادة توجيه ولم يستطع حلها، فلم تُفهرس الصفحة. تسمي Google أربعة أسباب: سلسلة طويلة جداً، أو حلقة، أو عنوان إعادة توجيه تجاوز أقصى طول لعنوان URL، أو عنوان سيئ/فارغ في السلسلة. إنها إعادة توجيه معطلة يجب إصلاحها، وتختلف عن “Page with redirect” التي تعني إعادة توجيه عاملة وغير أساسية ولا تحتاج عادةً إلى إجراء. شخّص بتتبع السلسلة (curl -IL وURL Inspection وLighthouse وزاحف)، واختصرها إلى 301 مباشر واحد للعنوان النهائي، وأصلح الروابط الداخلية، ثم نفذ Validate Fix. أما حدود القفزات: تنشر وثائق Google الحالية سقف 10 قفزات، وتوصي بما لا يزيد على 3 وأقل من 5. تصف تصريحات Mueller المؤرخة في 2014 و2020 نحو خمس قفزات لكل زحف؛ كما وصف تصريح 2014 متابعة البقية لاحقاً. وملاحظات Patrick المشابهة مستقلة. استهدف قفزة واحدة دائماً.

أين تظهر هذه الحالة؟

تظهر “Redirect error” في Search Console ضمن Page Indexing ← “Why pages aren’t indexed”. يقسم الجدول العناوين غير المفهرسة حسب الأسباب، وهذه واحدة منها. الخلاصة: إنها مشكلة زحف/اتباع لا حكماً على الجودة. لا تقول Google إن الصفحة منخفضة الجودة أو معاقبة؛ بل إنها لم تستطع حرفياً اتباع إعادة التوجيه إلى وجهة، فلم تجد شيئاً تفهرسه.

أسباب Google الأربعة — بدقة

هذه أسباب التقرير الموثقة في Search Console، وليست تصنيفاً شاملاً لكل عيوب تنفيذ إعادة التوجيه. Evidence for this claim Google reports Redirect error when it could not process a redirect to a destination. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report وتوصي Google بصورة منفصلة بمسارات قصيرة ومباشرة. Evidence for this claim Google lists overly long chains, loops, excessive redirect URL length, and bad or empty redirect URLs for this report status. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report

وثائق Page Indexing محددة: تعني الحالة أن Google واجهت أحد الآتي: سلسلة طويلة جداً، أو حلقة، أو عنوان إعادة توجيه تجاوز في النهاية أقصى طول لعنوان URL، أو عنواناً سيئاً أو فارغاً في السلسلة. هذه القائمة كاملة: أربعة أنماط فشل، ويرتبط كل إصلاح بأحدها. (تجد الصياغة الدقيقة في الاقتباسات.)

‏“Redirect error” مقابل “Page with redirect” — الفرق الأهم

هذا أكثر مواضع الالتباس شيوعاً، لذا يستحق الوضوح. فهما حالتان مختلفتان في Page Indexing:

• Redirect error — لم تستطع Google اتباع إعادة التوجيه (لأحد الأسباب الأربعة). لا يمكن فهرسة الصفحة. إنها معطلة؛ أصلحها.
• Page with redirect — استطاعت Google اتباعها؛ فقد عملت. عنوان URL غير أساسي ويعيد التوجيه إلى مكان آخر، فلا يُفهرس هو، لكن الوجهة قد تُفهرس. تصفها Google بأنها عنوان غير أساسي يعيد التوجيه إلى صفحة أخرى، ولذلك لن يُفهرس، بينما قد تفهرس الوجهة أو لا بحسب تقييم Google لها. ليست خطأً ولا تحتاج عادةً إلى إجراء.

إذا ظهرت عناوين URL القديمة التي أعدت توجيهها عمداً بـ301 في “Page with redirect”، فهذا عمل النظام كما صُمم؛ لا تحاول «إصلاحه». ركز على “Redirect error” المعطلة فعلاً. (يوجد جدول مقارنة في أوراق الغش.)

الأسباب الأربعة وكيفية إصلاح كل منها

1. سلسلة إعادة توجيه طويلة جداً. ‏A → B → C → D → … بدلاً من A مباشرة إلى العنوان النهائي. تضيف كل قفزة زمناً وفرصة عطل، وقد لا تصل Google إلى الوجهة في السلسلة الطويلة. الإصلاح: اختصر السلسلة. وجّه العنوان الأصلي مباشرة إلى الوجهة النهائية في 301 واحد، وأزل القواعد الوسيطة أو حدّثها.

2. حلقة إعادة توجيه. عنوانان أو أكثر يعيدان التوجيه بعضهما إلى بعض: A → B → A، أو دورة أطول. تظهر في المتصفح كخطأ ERR_TOO_MANY_REDIRECTS / “too many redirects”. تنشأ الحلقات غالباً من قواعد متعارضة: HTTP↔HTTPS أو www↔non-www أو الشرطة الختامية↔دون شرطة. الإصلاح: حدد الدورة، واختر شكلاً أساسياً واحداً لكل بُعد (مثل HTTPS وnon-www والشرطة الختامية)، واجعل كل قاعدة تشير في اتجاه واحد فقط.

3. تجاوز عنوان إعادة التوجيه أقصى طول لعنوان URL. قد تؤدي قاعدة تعيد إلحاق أجزاء بالعنوان — كإعادة كتابة خاطئة أو معلمات تتبع منفلتة أو إعادة تغذية المخرجات — إلى نمو الوجهة فوق الحد، وغالباً يتداخل ذلك مع حلقة. الإصلاح: أوقف القاعدة التي تلحق المعلمات، واحذف معلمات التتبع غير الضرورية، ووجّه إلى عنوان نهائي نظيف وثابت.

4. عنوان سيئ أو فارغ في السلسلة. صياغة Google عامة، ولا تسمي العناوين النسبية مثالاً. فقيمة Location النسبية صالحة في HTTP (يحلها المستلم نسبة إلى العنوان الحالي)، وليست النسبية المشكلة بذاتها. ما يعطل القفزة: Location فارغ، أو قيمة لا تحل إلى عنوان حقيقي، أو قاعدة تنتج نصاً تالفاً. الإصلاح: تتبع القفزة وتحقق من قيمة Location المعطلة، ثم أصلح القاعدة لتنتج وجهة صالحة قابلة للحل. العنوان المطلق افتراضي أكثر أماناً، لكن العيب هو «لا تُحل» لا «ليست مطلقة».

كم إعادة توجيه تتبع Google فعلياً؟

هنا تتكرر أرقام سيئة، لذا يلزم الحذر؛ وقد تغير هذا القسم منذ آخر تحقق. تنشر وثائق بنية الزحف لدى Google الآن افتراضياً: “By default, Google’s crawlers follow up to 10 redirect hops. However, specific products’ crawlers may have different limits.” (الترجمة العربية) «تتبع زواحف Google افتراضياً ما يصل إلى 10 قفزات إعادة توجيه، لكن قد تكون لزواحف منتجات محددة حدود مختلفة.» وتضيف أن Googlebot يتبع عادةً 10 قفزات عند زحف محتوى الويب العام، بينما لا تتبع Google Inspection Tools إعادات التوجيه إطلاقاً؛ فالعدد يعتمد حتى على أداة Google التي تجلب.

تضيف وثائق نقل المواقع الحالية لدى Google الهدف العملي: تجنب السلاسل؛ وإن تعذر ذلك فأبقها عند ما لا يزيد على 3 وأقل من 5. وهذا ليس سقفاً تقنياً آخر. العشر هو ما تقول وثائق الزاحف إن Googlebot يتبعه؛ و3 إلى 5 هي توصية التنفيذ الحالية.

للرقم المألوف «خمس قفزات» مسار أدلة مستقل ومؤرخ. في جلسة مشرفي مواقع عام 2014 عند 46:03، وصف John Mueller اتباع Googlebot ما يصل إلى خمس إعادات في زحف واحد ومتابعة البقية في الزحف التالي. وفي 2020 قال بصورة منفصلة إن Google تتبع نحو 5 قفزات لكل محاولة زحف، ونصح بأقل من 5 للعناوين كثيرة الزحف. كان تصريح المتابعة عام 2014 حقيقياً، لكن التصريحين إرشادان تاريخيان تمثيليان، لا ضماناً حالياً لمتابعة كل سلسلة أو توقيتها.

حدي العملي، من سنوات إصلاح هذه المشكلات، هو أيضاً نحو 5 قفزات، وقد رأيت Google تستأنف سلاسل أطول بصورة مستقلة. هذه ملاحظات ممارس، وليست أساس تصريح Mueller عام 2014 ولا حداً للمنصة.

لا يغير ذلك النصيحة العملية: أعد التوجيه مباشرة إلى عنوان URL النهائي في قفزة واحدة. تتجنب القفزة الواحدة سؤال عدد القفزات كله، وهي أسرع للمستخدمين أيضاً.

كيفية تشخيص خطأ إعادة التوجيه

تريد أن ترى إعادة التوجيه التي تتعثر فيها Google:

• URL Inspection ‏(GSC). تتبع المعاينة الحية إعادة التوجيه وتختبر العنوان النهائي، لكنها لا تعرض المسار ولا تسمي الوجهة، فلا تغني عن تتبع كل قفزة لمعرفة موضع العطل. وهناك أداة مختلفة تسميها بنية الزحف “Google Inspection Tools” لا تتبع إعادات التوجيه إطلاقاً؛ فلا تفترض تماثل كل أدوات «المعاينة». استخدمها لتأكيد حكم Google العام لا لرؤية السلسلة.
• curl -IL (أو أداة فحص إعادة التوجيه) لتتبع كل قفزة ورمز حالة من سطر الأوامر؛ وهي أسرع طريقة لاكتشاف سلسلة أو حلقة. الأوامر في Scripts.
• Lighthouse. تقترح وثائق Google أداة تصحيح ويب مثل Lighthouse لمزيد من التفاصيل.
• زاحف — Ahrefs Site Audit أو Screaming Frog أو Sitebulb — لاكتشاف السلاسل والحلقات على نطاق الموقع، بما فيها ما لم تعرف عنه.
• المتصفح. تظهر الحلقة فوراً كخطأ ERR_TOO_MANY_REDIRECTS.

كيفية الإصلاح خطوة بخطوة

1. أعد إنتاج إعادة التوجيه (curl أو فاحص إعادة التوجيه أو المتصفح)، وحدد القفزة المعطلة: الحلقة أو الهدف المفرط الطول أو العنوان السيئ أو السلسلة.
2. استبدل السلسلة أو الحلقة بقفزة مباشرة واحدة إلى العنوان النهائي، واختر الإصلاح وفق ما يُفترض أن يفعله ذلك العنوان فعلاً، لا بصورة آلية. نقل دائم ← 301 واحد (أو 308). نقل مؤقت فعلاً ← 302/303/307، لأن Google تعامل إعادات التوجيه الدائمة والمؤقتة بصورة مختلفة في الإشارات الأساسية. إذا كان العنوان القديم لا ينبغي أن يعيد التوجيه أصلاً، فأعده إلى 200 حقيقي؛ وإذا اختفى المحتوى نهائياً بلا بديل، فقد يكون 404/410 هو الجواب الصحيح بدلاً من فرض إعادة توجيه. أياً كان الحل، فلا وسطاء.
3. حدّث الروابط الداخلية لتشير إلى العنوان النهائي؛ لا تستمر في الربط بالعنوان القديم الذي يعيد التوجيه.
4. أعد الاختبار بـcurl أو URL Inspection لتأكيد إعادة توجيه واحدة نظيفة (أو 200 مباشر).
5. نفذ Validate Fix في Search Console. لاحظ أنه يضع إعادة الفحص في الطابور ولا يعيد فهرسة الصفحة فوراً. ويظل الحل معتمداً على إعادة زحف Google للعنوان وفق جدولها، فلا تتوقع تغير الحالة مباشرة.

أين تتجمع هذه الأخطاء؟ عمليات نقل المواقع

وفق خبرتي، تولد معظم أخطاء إعادة التوجيه أثناء عمليات النقل: HTTP إلى HTTPS، وتوحيد www، وتغيير النطاق أو CMS أو الشرطة الختامية. تتراكم السلاسل والحلقات مع طبقات القواعد. الوقاية: احتفظ بخريطة توجيه واجعل كل عنوان قديم يشير مباشرة إلى عنوانه النهائي الجديد، لا إلى وسيط يعيد التوجيه. old → interim → new سلسلة منذ اليوم الأول.

ملاحظة عن 301 مقابل 302

لا يتعلق الخطأ بنوع إعادة التوجيه، بل بتعذر اتباعها. ومع ذلك، لا تفقد إعادات 3xx نظام PageRank، وقد تعامل Google ‏302 كـ301 مع الوقت (اختبرت ذلك بنفسي: تصرف 302 طويل العمر بين موقعين قائمين كنقل دائم). مع ذلك استخدم 301 للنقل الدائم لإرسال أوضح إشارة أساسية. استخدم النوع الصحيح وقفزة واحدة.

الحالات والمفاهيم المرتبطة

الحالة الشقيقة “Page with redirect” هي النظير الطبيعي غير الخاطئ. وسلسلة إعادة التوجيه أشهر سبب أساسي هنا، وتقرير Page Indexing هو موضع هذه الحالات في GSC. وللصورة الأوسع عن قرار Google بالفهرسة، راجع مركز الفهرسة.

ملخص الذكاء الاصطناعي

خلاصة مكثفة للنسخة المتقدمة:

• “Redirect error” = لم تستطع Google اتباع إعادة توجيه، ولذلك لا تُفهرس الصفحة. إنها حالة في Page Indexing داخل Search Console تحت “Why pages aren’t indexed”؛ وهي فشل في الاتباع/الزحف، لا عقوبة ولا حكماً على الجودة.
• أربعة أسباب تحددها Google: سلسلة إعادة توجيه طويلة جداً، أو حلقة، أو عنوان إعادة توجيه تجاوز أقصى طول لعنوان URL، أو عنوان سيئ/فارغ في السلسلة. ويرتبط كل إصلاح بأحدها.
• ليست “Page with redirect” نفسها. ‏Redirect error = إعادة معطلة يجب إصلاحها. أما Page with redirect = إعادة عاملة غير أساسية، وهي عادية ولا تحتاج عادةً إلى إجراء. وهذا أكبر موضع التباس في الموضوع.
• أصلح كل سبب: السلسلة الطويلة ← اختصرها إلى قفزة مباشرة واحدة تناسب السلوك المقصود للعنوان؛ الحلقة ← حل تعارض قواعد HTTP/HTTPS وwww والشرطة الختامية؛ العنوان المفرط الطول ← أوقف إلحاق المعلمات؛ العنوان السيئ/الفارغ ← تتبع القيمة المعطلة الفعلية وأنتج هدفاً صالحاً قابلاً للحل (فالنسبية ليست المشكلة تلقائياً).
• عدد القفزات: تنشر وثائق زحف Google الآن افتراضياً حتى 10 قفزات إعادة توجيه لـGooglebot (ولا تتبع Google Inspection Tools أي قفزة)، بينما توصي وثيقة نقل المواقع بما لا يزيد على 3 وأقل من 5. تصف تصريحات Mueller المؤرخة عامي 2014 و2020 نحو 5 قفزات لكل زحف؛ ووصف تصريح 2014 أيضاً متابعة البقية لاحقاً. أما ملاحظة Patrick الميدانية المشابهة وحده العملي عند نحو 5 فمستقلان. استهدف قفزة واحدة.
• شخّص باستخدام URL Inspection وcurl -IL وLighthouse وزاحف (Ahrefs Site Audit أو Screaming Frog أو Sitebulb) عند العمل على نطاق واسع.
• سير الإصلاح: أعد الإنتاج ← حدد القفزة المعطلة ← أنشئ قفزة مباشرة واحدة إلى العنوان النهائي، بنوع إعادة التوجيه (أو عدمها) المطابق للغرض ← حدّث الروابط الداخلية ← أعد الاختبار ← نفذ Validate Fix، الذي يضع إعادة الفحص في طابور جدول زحف Google ولا يعمل فوراً.
• تتجمع الأخطاء أثناء عمليات النقل (HTTPS وwww والنطاق وإعادة بناء المنصة). امنعها بربط كل عنوان قديم مباشرة بعنوانه الجديد النهائي، لا عبر إعادة توجيه وسيطة.

الوثائق الرسمية

وثائق أصلية من محركات البحث.

Google

• تقرير فهرسة الصفحات — مصدر تعريف “Redirect error” وأسبابها الأربعة، وحالة “Page with redirect” المنفصلة، واقتراح استخدام أداة تصحيح مثل Lighthouse.
• إعادات التوجيه وبحث Google — وثيقة Google عن الأنواع، وتفضيل إعادات الخادم، وكيفية معاملة الدائم والمؤقت في الإشارات الأساسية.
• تأثير رموز حالة HTTP في زواحف Google — وثيقة بنية الزحف التي تنص على السقف الافتراضي الحالي، حتى 10 لـGooglebot، وأن Google Inspection Tools لا تتبع إعادات التوجيه إطلاقاً.
• الزحف والفهرسة — مركز إعادات التوجيه وتحديد النسخة الأساسية وضوابط الزحف.
• أداة URL Inspection — فحص عنوان واحد؛ تتبع المعاينة الحية إعادة التوجيه لاختبار العنوان النهائي، لكنها لا تكشف المسار الذي سلكته.

Bing / Microsoft

• إرشادات مشرفي مواقع Bing — إرشادات Bing العامة، ومنها استخدام 301s للنقل الدائم وتجنب سلاسل إعادة التوجيه.
• إدارة إعادات التوجيه — 301s و302s والعناوين الأساسية (2011) — تدوينة Bing الأقدم التي ما زال يُستشهد بها عن أفضل الممارسات: وجّه العناوين القديمة مباشرة إلى الوجهة النهائية.

اقتباسات من المصدر

تصريحات موثقة من Google، مع روابط عميقة إلى المقاطع.

Google — الأسباب الأربعة

• “Google experienced one of the following redirect errors: A redirect chain that was too long; A redirect loop; A redirect URL that eventually exceeded the max URL length; A bad or empty URL in the redirect chain.” (الترجمة العربية) «واجهت Google أحد أخطاء إعادة التوجيه الآتية: سلسلة طويلة جداً؛ حلقة؛ عنوان تجاوز أقصى طول؛ أو عنوان سيئ أو فارغ في السلسلة.» — Google، تقرير Page indexing. الانتقال

Google — ‏“Page with redirect” للمقارنة

• “This is a non-canonical URL that redirects to another page. As such, this URL will not be indexed. The target URL of the redirect might or might not be indexed, depending on what Google thinks about that target URL. A canonical URL with a redirect can be indexed.” (الترجمة العربية) «هذا عنوان غير أساسي يعيد التوجيه إلى صفحة أخرى، ولذلك لن يُفهرس. وقد تُفهرس الوجهة أو لا، بحسب تقييم Google لها. ويمكن فهرسة عنوان أساسي يتضمن إعادة توجيه.» — Google، تقرير Page indexing. الانتقال

John Mueller — عدد القفزات

• في جلسة 2014، وصف اتباع Googlebot حتى خمس إعادات ومتابعة البقية لاحقاً. المشاهدة 46:03
• “Search engines just follow the redirect chain (for Google: up to 5 hops in the chain per crawl attempt).” (الترجمة العربية) «تتبع محركات البحث السلسلة فحسب (لدى Google: حتى 5 قفزات لكل محاولة زحف).» المصدر
• “The only thing I’d watch out for is that you have less than 5 hops for URLs that are frequently crawled.” (الترجمة العربية) «سأنتبه فقط إلى وجود أقل من 5 قفزات للعناوين كثيرة الزحف.» المصدر

Google — السقف الحالي

• “By default, Google’s crawlers follow up to 10 redirect hops. However, specific products’ crawlers may have different limits.” (الترجمة العربية) «تتبع زواحف Google افتراضياً حتى 10 قفزات، وقد تختلف حدود زواحف منتجات محددة.» — Google، وثائق بنية الزحف.
• “Googlebot generally follows 10 redirect hops when crawling for general web content, but Google Inspection Tools doesn’t follow redirects.” (الترجمة العربية) «يتبع Googlebot عادةً 10 قفزات في زحف الويب العام، لكن Google Inspection Tools لا تتبعها.» — المصدر نفسه. المصدر

Google — التوصية العملية

• “ideally no more than 3 and fewer than 5.” (الترجمة العربية) «يُفضّل ألا تزيد على 3 وأن تقل عن 5.» المصدر

قائمة تحقق لإصلاح redirect-error

طبقها على كل عنوان يحمل “Redirect error”:

• تأكد أنها “Redirect error” فعلاً وليست “Page with redirect”؛ فالثانية سليمة عادةً ولا تحتاج إلى إجراء.
• أعد إنتاج إعادة التوجيه بـcurl -IL (أو فاحص إعادة توجيه)، واقرأ كل قفزة ورمز حالة.
• حدد أي أسباب Google الأربعة ينطبق: سلسلة طويلة، أو حلقة، أو عنوان تجاوز أقصى طول، أو عنوان سيئ/فارغ.
• في الحلقة، حدد القواعد المتعارضة (HTTP↔HTTPS أو www↔non-www أو الشرطة الختامية)، واجعل كل إعادة تشير في اتجاه واحد فقط.
• في السلسلة، اختصرها إلى 301 واحد يشير إلى العنوان النهائي، واحذف القفزات الوسيطة.
• في العنوان المفرط الطول، أوقف إلحاق المعلمات ووجّه إلى هدف نظيف وثابت.
• في العنوان السيئ/الفارغ، تتبع قيمة Location المعطلة نفسها أولاً — فارغة أو غير قابلة للحل أو تالفة، لا نسبية فحسب — ثم أصلح القاعدة لتنتج هدفاً صالحاً قابلاً للحل؛ والعنوان المطلق افتراضي أكثر أماناً.
• تأكد أن الوجهة النهائية تعيد 200، لا إعادة أخرى ولا 4XX/5XX.
• حدّث الروابط الداخلية لتشير إلى العنوان النهائي، لا عنوان إعادة التوجيه.
• أعد الاختبار بـcurl أو URL Inspection؛ وتوقع إعادة نظيفة واحدة أو 200 مباشراً.
• انقر Validate Fix في Search Console؛ فهو يضع إعادة الفحص في الطابور ولا يعمل فوراً.

أوراق غش redirect-error

الفرق بين الحالتين

الأسباب ← التشخيص ← الإصلاح

عدد القفزات

تتبع السلسلة

أسرع وسيلة لرؤية الموضع الذي تتعثر فيه Google بدقة هي أن تتبع سلسلة إعادة التوجيه بنفسك وتقرأ كل قفزة ورمز حالة.

macOS / Linux

# -I = headers only, -L = follow redirects: prints each hop's status + Location
curl -sIL https://www.example.com/old-page/ | grep -i -E '^(HTTP/|location:)'
# Example of a healthy single hop:
#   HTTP/2 301
#   location: https://www.example.com/new-page/
#   HTTP/2 200
#
# A chain shows multiple 3xx lines before the 200.
# A loop never reaches 200 — you'll see the same URLs repeat (curl stops at its
# --max-redirs limit, default 50).

إذا أردت قائمة العناوين والرموز لكل قفزة في سطر:

curl -sIL -o /dev/null -w '%{http_code} %{url_effective}\n' https://www.example.com/old-page/
# Add --max-redirs 10 to cap how far curl will follow (useful for catching loops):
curl -sIL --max-redirs 10 -o /dev/null -w '%{http_code} %{url_effective}\n' https://www.example.com/old-page/

Windows (PowerShell)

# Follows redirects and reports the final status; -MaximumRedirection caps the chain
Invoke-WebRequest -Uri "https://www.example.com/old-page/" -MaximumRedirection 10 |
  Select-Object StatusCode, @{n='FinalUrl';e={$_.BaseResponse.ResponseUri}}

# To see each hop, disable auto-follow and inspect the Location header one step at a time:
Invoke-WebRequest -Uri "https://www.example.com/old-page/" -MaximumRedirection 0 -ErrorAction SilentlyContinue |
  Select-Object StatusCode, @{n='Location';e={$_.Headers.Location}}

قراءة المخرجات

• 3xx واحد ثم 200 = قفزة واحدة نظيفة. جيد.
• عدة أسطر 3xx قبل 200 = سلسلة؛ اختصرها إلى 301 واحد.
• تكرار العناوين نفسها أو عدم بلوغ 200 = حلقة؛ حدد القواعد المتعارضة.
• ‏3xx يشير إلى 4XX/5XX أو إلى Location فارغ/تالف = عنوان سيئ/فارغ في السلسلة؛ أصلح القاعدة.

بعد 301 → 200 مباشر، أعد الاختبار ثم نفذ Validate Fix.

تنبيه: يرسل -I طلب HEAD لا GET. تعيد معظم الخوادم وشبكات CDN التوجيه بالطريقة نفسها بصرف النظر عن الأسلوب، لكن بعض إعدادات الخادم أو قواعد CDN أو البرمجيات الوسيطة تتفرع بحسب أسلوب الطلب. لذلك، إذا بدت إحدى القفزات مختلفة عما تتوقع، فأعد التشغيل بلا -I (أي curl -sL عادي) لتأكيد أن سلوك GET مطابق قبل أن تستنتج أن الإصلاح خاطئ.

لدي “Redirect error” — ماذا أصلح؟

تبدو أسباب Google الأربعة متشابهة من بعيد، إذ تنتهي كلها بعدم حل إعادة التوجيه، لكن إصلاح كل منها مختلف. تتبع السلسلة أولاً (باستخدام curl أو Redirect Checker)، ثم استخدم ما تراه لاختيار الفرع أدناه.

أياً كان الفرع الذي تصل إليه، فالحالة النهائية واحدة: 301 مباشر واحد إلى عنوان يعيد 200. أعد الاختبار باستخدام Redirect Checker أو curl -IL قبل النقر على Validate Fix.

أخطاء تتحول إلى “Redirect error”

• توجيه old → interim → new بدلاً من old → new. هذه أكثر طريقة شيوعاً لولادة “Redirect error”. كلما نقلت الموقع (HTTPS أو www أو النطاق أو CMS) ووجهت العنوان القديم إلى عنوان وسيط يعيد التوجيه أصلاً بدلاً من النهائي، فقد بنيت سلسلة منذ اليوم الأول. افعل بدلاً من ذلك: وجّه العنوان الأصلي دائماً مباشرة إلى الوجهة النهائية.
• تكديس قواعد تحديد النسخة الأساسية من دون فحص ترتيبها. تعمل قواعد HTTP→HTTPS وwww→non-www والشرطة الختامية بصورة مستقلة؛ وإذا اختلفت قاعدتان في الاتجاه نشأت حلقة لا سلسلة. افعل بدلاً من ذلك: اختر شكلاً أساسياً واحداً لكل بُعد، وتأكد أن كل قاعدة تشير في الاتجاه نفسه، لا القاعدة التي عدلتها وحدها.
• «إصلاح» إعادة توجيه بإضافة إعادة أخرى فوقها. يؤدي ترقيع قفزة معطلة بوضع قاعدة جديدة أمامها عادةً إلى إطالة السلسلة بدلاً من تقصيرها. افعل بدلاً من ذلك: استبدل السلسلة كلها بـ301 مباشر واحد، ولا تضف قفزة أخرى إليها.
• الخلط بين “Redirect error” و”Page with redirect” ومحاولة «إصلاح» إعادة عاملة. تعني “Page with redirect” أن Google اتبعت بنجاح عنواناً غير أساسي إلى هدفه؛ فهي ليست معطلة. افعل بدلاً من ذلك: أنفق الوقت على العناوين الموسومة فعلاً بـ”Redirect error”، واترك “Page with redirect” وشأنها.
• إعادة التوجيه إلى عنوان يعيد هو نفسه 404s أو 5xxs أو يحمل noindex. حتى القفزة النظيفة الواحدة عديمة الفائدة إذا لم تُعد الوجهة 200 ولم تكن قابلة للفهرسة؛ فإما ألا تستطيع Google إكمال الحل أو ألا تفهرس ما تجده. افعل بدلاً من ذلك: تأكد أن الهدف النهائي يعيد 200 حقيقياً وقابل للفهرسة قبل توصيل إعادة التوجيه به.
• السماح بإلحاق معلمات التتبع/الاستعلام في كل قفزة. تنمّي قاعدة إعادة كتابة تعيد تغذية مخرجاتها، وهو شائع مع معلمات التتبع أو الجلسات، العنوان الهدف فوق أقصى طول في إعادة طويلة العمر. افعل بدلاً من ذلك: احذف المعلمات غير الضرورية ووجّه إلى عنوان نظيف وثابت.
• النقر على Validate Fix وافتراض أنه فوري. يضع Validate Fix إعادة الفحص في الطابور ولا يعيد فهرسة الصفحة مباشرة. افعل بدلاً من ذلك: أعد اختبار إعادة التوجيه بنفسك أولاً (curl أو Redirect Checker) لتعرف أنها أُصلحت فعلاً قبل انتظار إعادة زحف Google.

أثبت أن الإصلاح يعمل

نفذ هذه الاختبارات بعد اختصار السلسلة أو كسر الحلقة أو إصلاح العنوان السيئ/الفارغ، وقبل الاعتماد على Search Console لتأكيد الإصلاح.

الاختبار 1: ‏301 واحد إلى 200

• الاختبار: الصق العنوان القديم في Redirect Checker، أو نفذ curl -sIL -o /dev/null -w '%{http_code} %{url_effective}\n' <url>.
• المتوقع: قفزة 301 واحدة بالضبط (أو 308) تنتهي بعنوان يعيد 200.
• تفسير الفشل: يعني وجود أكثر من سطر 3xx قبل 200 أن السلسلة لم تُختصر فعلاً؛ وعودة العنوان نفسه تعني أن الحلقة لم تُصلح.
• نافذة المراقبة: فورية؛ لا تحتاج رموز الحالة إلى وقت كي «تستقر».
• سبب التراجع: ظهور أي قفزة إضافية، أو كون الحالة النهائية 4XX/5XX بدلاً من 200.

الاختبار 2: لا حلقة ولا نمو

• الاختبار: شغّل Redirect Chain Mapper على العنوان المتأثر، أو نفذ curl -sIL --max-redirs 10 -o /dev/null -w '%{http_code} %{url_effective}\n' <url> (يعيد الحد المنخفض لـ--max-redirs خطأً إذا استمرت الحلقة).
• المتوقع: يعرض المخطط قفزة مستقيمة واحدة بلا عناوين متكررة، ولا يكون طول العنوان الهدف قد ازداد بسبب معلمات ملحقة.
• تفسير الفشل: تكرار العناوين يعني بقاء قاعدة تحديد النسخة الأساسية المتعارضة؛ وطول الهدف فوق المتوقع يعني أن قاعدة ما ما زالت تلحق المعلمات.
• نافذة المراقبة: فورية.
• سبب التراجع: عودة الحلقة، أو نمو طول العنوان مجدداً عند إعادة الفحص بعد أيام.

الاختبار 3: تحقق جماعي بعد النقل

• الاختبار: مرر قائمة العناوين القديمة كاملة عبر SEO Migration Planner & Validator أو Redirect Checker جماعياً.
• المتوقع: يصل كل عنوان قديم في الخريطة بقفزة واحدة إلى عنوانه الجديد المقصود عند 200.
• تفسير الفشل: أي عنوان ما زال يعرض قفزات متعددة أو حلقة أو وجهة غير 200 يعني أن صفه في خريطة إعادة التوجيه لم يُطبق فعلاً أو يشير إلى وجهة خاطئة.
• نافذة المراقبة: فورية لفحص القفزات.
• سبب التراجع: فشل أكثر من بضعة عناوين في الفحص الجماعي؛ فهذه علامة على عيب منهجي في خريطة إعادة التوجيه نفسها، لا في قاعدة واحدة فحسب.

الاختبار 4: Search Console

• الاختبار: انقر Validate Fix للعناوين المتأثرة في تقرير Page Indexing، ثم راقب الحالة.
• المتوقع: يخرج العنوان من “Redirect error”، ويفضل أن ينتقل إلى “Page with redirect” إذا كان عنواناً قديماً غير أساسي، أو أن يظهر العنوان النهائي مفهرساً.
• تفسير الفشل: استمرار “Redirect error” بعد اكتمال التحقق يعني أن إعادة التوجيه الحية ما زالت لا تُحل كما اختبرتها، أو أن Google لم تُعد الزحف بعد.
• نافذة المراقبة: يضع Validate Fix إعادة الفحص في الطابور، لا إعادة فهرسة فورية؛ وتعتمد المدة كلياً على جدول إعادة الزحف الخاص بـGoogle لذلك العنوان، وهو غير منشور، فلا تتوقع موعداً ثابتاً.
• سبب التراجع: عودة التحقق بنتيجة فشل، أو ظهور الحالة مجدداً في زحف لاحق بعد أن اختفت أولاً.

أدوات التتبع والإصلاح

• Redirect Checker — الصق عنواناً واحداً لترى كل قفزة ورمز حالة والوجهة النهائية؛ وهو أسرع وسيلة لتأكيد أن العنوان المعلّم أصبح 301 نظيفاً واحداً ينتهي بـ200.
• Redirect Chain Mapper — يصور المسار قفزة بقفزة، فتظهر السلسلة أو الحلقة فوراً بدلاً من قراءة الترويسات الخام سطراً سطراً.
• Bulk HTTP Status Code Checker — يفحص عدة عناوين معاً، وهي طريقة اكتشاف أخطاء إعادة التوجيه عبر موقع أو خريطة كاملة بدلاً من عنوان واحد في كل مرة.
• SEO Migration Planner & Validator — مصمم تحديداً لعمليات نقل المواقع، حيث تنشأ معظم أخطاء إعادة التوجيه. اربط العناوين القديمة مباشرة بعناوينها الجديدة النهائية، لا عبر وسيط، وتحقق من الخريطة قبل الإطلاق وبعده.
• Google Search Console — URL Inspection. تتبع المعاينة الحية إعادة التوجيه وتختبر العنوان النهائي، لكنها لا تعرض المسار قفزة بقفزة ولا تسمي العنوان النهائي؛ فاقرنها بـcurl -IL أو فاحص إعادة توجيه عندما تحتاج إلى رؤية موضع تعطل السلسلة.
• curl -IL من سطر الأوامر لمن يريد تتبع القفزات يدوياً؛ توجد الأوامر في تبويب Scripts.
• Ahrefs Site Audit / Screaming Frog / Sitebulb. تكشف كل سلسلة وحلقة عبر الموقع دفعة واحدة، ومنها ما لم يُفتح له طلب دعم قط.

موجّهات للتحليل

زوّدها بتتبعات فعلية؛ فلا يمكن التحقق من المسار من عنوان وحده.

تشخيص تتبع معطل

حلل تتبع إعادة التوجيه هذا قفزة بقفزة. حدد أول حلقة أو Location غير صالح/فارغ أو سلسلة مفرطة أو وجهة غير ناجحة. أوصِ بإعادة توجيه مباشرة واحدة من عنوان البداية إلى عنوان 200 النهائي المقصود. التتبع: [ألصق الحالات وقيم Location].

مراجعة خريطة قبل النشر

راجع خريطة إعادة التوجيه المقترحة هذه من القديم إلى الجديد. علّم الإعادات الذاتية والحلقات والقفزات المتعددة والوجهات المتعارضة والأهداف التالفة وعمليات التوجيه إلى صفحات غير ذات صلة. أعد الخرائط المصححة وقائمة تحقق. الخريطة: [ألصق الصفوف].

تجميع نتائج الزحف

جمّع أخطاء إعادة التوجيه هذه حسب نمط المصدر المشترك والقاعدة أو القالب المرجح. اذكر لكل مجموعة الدليل وأصغر تغيير في الإعداد وعدد العناوين المتأثرة واختباراً لما بعد النشر. لا تخترع هدفاً عندما لا تكون الوجهة المقصودة موجودة في البيانات. الصفوف: [ألصق تصدير الزحف].

اختبر نفسك: Redirect error

خمسة أسئلة عن المعنى والإصلاح. اختر إجابة ثم تحقق.

سجل التغييرات