حلقات إعادة التوجيه

الخلاصة — تحدث حلقة إعادة التوجيه عندما تدور إعادات التوجيه في دائرة: ترسل الصفحة A إلى B، ثم تعيد B الزائر إلى A. لا يُحمّل شيء، فيتوقف المتصفح ويعرض «إعادات توجيه كثيرة جدًا». وهذا يعني أن موقعك متعطل للزوار الحقيقيين، لذا أصلحه قبل أي شيء آخر.

ما حلقة إعادة التوجيه؟

حلقة إعادة التوجيه دورة تعود فيها أهداف إعادة التوجيه في النهاية إلى عنوان URL سابق بدل الوصول إلى مورد نهائي. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 9110: Redirection تدرج Google الحلقات ضمن أخطاء إعادة التوجيه التي تمنع المعالجة الناجحة. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: Page indexing report عودة العنوان نفسه علامة قوية، لكنها ليست دليلًا تلقائيًا؛ فقد تجعل حالة تسجيل الدخول أو اختيار اللغة/الموافقة أو ملف تعريف ارتباط العنوان نفسه يُحل بصورة مختلفة في المرة التالية. عند الشك أعد اختبار العنوان نفسه بالطريقة نفسها، وبحالة الدخول وملفات الارتباط واللغة نفسها، قبل تأكيد الحلقة.

إعادة التوجيه قاعدة تنقل الزائر من عنوان إلى آخر. وهذا طبيعي عند نقل صفحة وتوجيه عنوانها القديم إلى الجديد.

أما حلقة إعادة التوجيه فتنشأ عندما تشير القواعد بعضها إلى بعض ولا تصل إلى صفحة فعلية. وأبسط صورة صفحتان تعيد كل منهما التوجيه إلى الأخرى:

• تزور A فتوجهك إلى B.
• تعيدك B إلى A.
• تعيدك A إلى B مجددًا… بلا نهاية.

لا تُحمّل الصفحة. يتبع المتصفح عدة إعادات توجيه، ويدرك أنها تدور، ثم يتوقف بخطأ. يعرض Chrome الخطأ ERR_TOO_MANY_REDIRECTS، وتعرض Firefox وSafari وEdge صيغها الخاصة من رسالة «الصفحة لا تعيد التوجيه بصورة صحيحة/إعادات توجيه كثيرة جدًا».

لماذا هذا عاجل؟

هذه هي النقطة التي يستخف بها الناس: تعني الحلقة أن صفحتك يتعذر على الزوار الحقيقيين الوصول إليها تمامًا. ليست صفحة بطيئة ولا مشكلة SEO طفيفة، بل انقطاع لكل من يصل إلى العنوان الدائر. وإذا شملت الموقع كله، كما يحدث كثيرًا مع إعداد SSL، فسيظل الموقع كله متعطلًا حتى تصلحها.

تتأثر محركات البحث أيضًا؛ فلا تستطيع Google الوصول إلى صفحة لا تُحمّل ولا فهرستها، لكن انقطاع الخدمة عن الزوار هو الطارئ.

فحوص سريعة تبدأ بها

بعض الحلقات سريع الإصلاح وبعضها ليس كذلك. ابدأ هنا:

1. جرّب نافذة خاصة/متخفية. إذا وقعت الحلقة في متصفحك العادي فقط وعمل العنوان في الوضع المتخفي، فالسبب ذاكرة تخزين مؤقت أو ملف تعريف ارتباط قديم على جهازك؛ امسحهما للموقع. وإن وقعت في الوضع المتخفي أيضًا فهي من جانب الخادم، ولن يفيد المسح.
2. هل غيّرت شيئًا للتو؟ شهادة SSL جديدة، أو خدمة أمان/CDN مثل Cloudflare، أو إضافة WordPress، أو تعديل .htaccess؟ يكاد ذلك التغيير يكون السبب، وغالبًا يكون التراجع عنه أسرع إصلاح.
3. هل المشكلة في HTTPS وحده؟ إذا عمل http:// ودار https://، أو العكس، فالسبب على الأرجح إعدادا HTTPS متعارضان؛ راجع تبويب Advanced للحل. وهذا من أفضل الأسباب توثيقًا، خصوصًا مع وجود CDN أمام الموقع.

يعتمد الإصلاح الحقيقي على سبب الحلقة؛ فلا توجد إجابة واحدة من نوع «راجع إعادات التوجيه». انتقل إلى Advanced للأسباب وتشخيص سطر الأوامر والإصلاحات الخاصة بالمنصات، أو افتح Decision Trees لتحديد السبب خطوة بخطوة.

الخلاصة — حلقة إعادة التوجيه دورة (A → B → A أو أطول) لا تعيد 200 قط، ولذلك لا تُحل. وهي تختلف جذريًا عن السلسلة الطويلة: السلسلة بطيئة، والحلقة معطلة؛ لذا لا يصلحها رفع حد القفزات. تظهر كـERR_TOO_MANY_REDIRECTS في المتصفح وكأحد أربعة أسباب موثقة لحالة «Redirect error» في Search Console. وتضر ثلاثة أطراف: المستخدمين المحجوبين، وبرامج الزحف العالقة، وخادمك الذي يهدر الموارد وقد يتعرض لحمل شديد بحسب الزيارات وتراجع العملاء وحدود السعة والمعدل. ومن أسبابها الموثقة جيدًا تعارض وضع HTTPS/SSL بين CDN/الوكيل والخادم الأصلي؛ وتشمل الأسباب الأخرى تعارض www/non-www، وقاعدة إضافة تواجه قاعدة خادم، وأخطاء الشرطة المائلة. ولا يوجد سبب واحد هو الأكثر شيوعًا في كل المواقع. والإصلاح خاص بالسبب دائمًا.

الحلقة دورة، لا سلسلة طويلة

الخاصية الفارقة هي المسار الدوري، لا عدد معين من القفزات. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 9110: Redirection يصف وسم Search Console مسار إعادة التوجيه الفاشل، لا طبقة الإعداد التي أنشأته. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: Page indexing report اعتبر تكرار العنوان مؤشر تتبع قويًا لا دليلًا تلقائيًا؛ فقد تختلف حالة الطلب، مثل المصادقة أو الموافقة أو اللغة أو ملفات الارتباط أو الرؤوس، بين الزيارات. أكد الحلقة بإعادة إنتاج الانتقال الدوري تحت حالة طلب مكافئة قبل أن تسميها حلقة وتعدل القاعدة.

هذا الفرق يفسر كل ما بعده. أعرّفها في دليلي عن إعادات التوجيه في Ahrefs بأنها حلقات لا نهائية تحدث عندما يعيد عنوان URL التوجيه إلى نفسه، أو عندما يعيد عنوان ضمن سلسلة التوجيه إلى عنوان سابق فيها.

سلسلة إعادة التوجيه (A → B → C → D → النهائية) مسار أطول مما ينبغي، لكنه يصل في النهاية إلى صفحة تعيد 200. هي بطيئة وتستحق الاختصار، لكنها تُحل.

أما الحلقة فدائرة A → B → A لا تصل إلى 200 مهما طال تتبعها. لذلك لا يصلحها «ارفع حد إعادة التوجيه». فهي لا تفشل لنفاد صبر المتصفح، بل لعدم وجود وجهة يمكن بلوغها. يجب كسر الدورة لا متابعة قفزات أكثر.

كيف تظهر الحلقة؟

في المتصفح. يعرض Chrome ERR_TOO_MANY_REDIRECTS، وتقول Firefox «الصفحة لا تعيد التوجيه بصورة صحيحة»، وتعرض Safari وEdge صيغًا من «إعادات توجيه كثيرة جدًا». السبب واحد والصياغة مختلفة.

في Google Search Console. الحلقة أحد أربعة أسباب موثقة لحالة «Redirect error» في تقرير فهرسة الصفحات؛ والثلاثة الأخرى سلسلة طويلة جدًا، أو عنوان إعادة توجيه تجاوز الحد الأقصى لطول URL، أو عنوان سيئ/فارغ في السلسلة. يعكس التقرير ما رأته Google في آخر زحف، لا حكمًا حيًا دائم التحديث؛ لذا أعد الفحص عبر URL Inspection بعد الإصلاح ولا تفترض تحديث التقرير فورًا. ولحالة الخطأ مقال مستقل يغطي الأسباب الأربعة، بينما يختص هذا المقال بالحلقة.

لبرامج الزحف وفي السجلات. يواصل الزاحف الذي يصادف حلقة طلب عناوين تعيد التوجيه. تكتشفها البرامج حسنة السلوك وتتوقف، وقد لا تتوقف البرامج الأخرى، ومن هنا تأتي مشكلة حمل الخادم.

لماذا تهم الحلقات؟ تتضرر ثلاثة أطراف

أصف الحلقات كمشكلة ثلاثية لأنها لا تؤثر في الترتيب وحده، بل في المستخدمين والروبوتات والبنية التحتية:

• المستخدمون: تمنعهم من المورد المقصود وتعرض خطأ «إعادات توجيه كثيرة جدًا»؛ فالصفحة غير قابلة للوصول، وهذه مشكلة انقطاع أولًا.
• الروبوتات ومحركات البحث: تحاصر برامج الزحف وتهدر ميزانية الزحف. لا يستطيع الزاحف الوصول إلى شيء قابل للفهرسة، وتبلغ وثائق Google عنه كـ«Redirect error». ليست عقوبة؛ فالصفحة لا يمكن بلوغها عمليًا، ولا ينطبق تجميع الإشارات لأن Google لا تصل إلى وجهة.
• خادمك: تهدر الحلقات موارده. تتراجع بعض الروبوتات ولا تتراجع أخرى، ويضيف العميل الذي يعيد الطلب بلا توقف حملًا مستمرًا مهدورًا. ويتوقف تحوله إلى انقطاع شديد أو حدث شبيه بـDDoS ذاتي على حجم الزيارات وقابلية التخزين المؤقت وسعة الخادم وحدود المعدل؛ وليس خاصية ملازمة لكل حلقة، لكنه خطر حقيقي في المواقع كثيرة الزيارات أو الزحف بلا حماية للمعدل.

الأسباب الشائعة

لا يوجد سبب عالمي واحد؛ فكل حلقة عملية ترجع إلى تعارض قواعد توحيد العناوين عبر طبقات لا تتشارك الحالة. يرى نظامان مختلفان أن لكل منهما العنوان الصحيح ويختلفان، فيرسلان الطلب ذهابًا وإيابًا. افحص الأنماط التالية بحسب بنيتك، لا وفق ترتيب تكرار ثابت.

تعارض HTTP/HTTPS بين CDN والخادم الأصلي

عند وضع وكيل/CDN مثل Cloudflare أمام الموقع، للاتصال مرحلتان: المتصفح → CDN، ثم CDN → الخادم الأصلي. إذا اختلفتا بشأن HTTP وHTTPS نشأت حلقة عند هذه الحدود. تسمي وثيقة Cloudflare نفسها هذه العائلة: وضع SSL/TLS Encryption سيئ الإعداد، أو إعدادات متعارضة في Edge Certificates، أو قاعدة إعادة توجيه خاطئة؛ وهي شائعة داخل منتج Cloudflare، لا بالضرورة السبب الأشيع عالميًا. ومن فروعها:

• وضع Flexible مع فرض HTTPS في الأصل. يتصل Cloudflare بالأصل عبر HTTP في وضع Flexible رغم استخدام الزائر HTTPS. إذا فرض الأصل HTTP → HTTPS عبر .htaccess أو nginx أو إضافة، أعاد الطلب إلى HTTPS ثم أرسله Cloudflare عبر HTTP من جديد. الإصلاح: استخدم Full أو Full (strict) ليكون اتصال CDN→الأصل عبر HTTPS أيضًا؛ ويتطلب Full (strict) شهادة صالحة في الأصل.
• وضع Full/Full (strict) مع تحويل الأصل HTTPS → HTTP. إذا بقيت قاعدة قديمة تعيد HTTPS إلى HTTP، يطلب CDN عبر HTTPS ويعيده الأصل إلى HTTP. الإصلاح: احذف قاعدة HTTPS→HTTP وليخدم الأصل HTTPS مباشرةً.
• Always Use HTTPS عند الحافة مع تحويل HTTPS في الأصل. قد ينشئ فرض HTTPS في موضعين، أو تعارض HSTS مع قاعدة، الحلقة نفسها. الإصلاح: اختر موضعًا واحدًا.
• قاعدة إعادة توجيه خاطئة من Page Rule أو Bulk Redirect أو Transform Rule تعيد العنوان إلى صيغة غادرها. الإصلاح: راجع قواعد الحافة المخالفة لتوحيد الأصل.

قواعد www وnon-www تعيد إلى بعضها

تريد مضيفًا أساسيًا واحدًا: www.example.com أو example.com. تنشأ الحلقة حين ترسل قاعدة example.com إلى www.example.com وتعيد قاعدة أخرى، ربما في إضافة أو CDN أو إعداد Site Address في WordPress، الاتجاه العكسي. الإصلاح: اختر مضيفًا واحدًا واجعل قاعدة واحدة في موضع واحد تفرضه.

تعارض قاعدة إضافة/CDN مع قاعدة خادم/أصل

موضوع الأسباب السابق أن الحلقة تعيش بين الطبقات. قد تخالف إضافة WordPress لفرض SSL أو حقلا WordPress Address وSite Address في Settings → General قاعدة .htaccess أو قاعدة CDN. تبدو كل طبقة صحيحة منفردة لكنها لا تتشارك الحالة. لذلك لا تثبت سلامة .htaccess غياب الحلقة. الإصلاح: اعثر على القاعدتين اللتين تؤديان المهمة نفسها في موضعين واحذف واحدة.

أخطاء منطق الشرطة المائلة النهائية

قد تتعارض قاعدة تضيف الشرطة (/page → /page/) مع أخرى تحذفها (/page/ → /page) فتنتج حلقة. الإصلاح: اختر صيغة واحدة واجعل القاعدة تحول الصيغة الخاطئة إلى الصحيحة فقط، من دون أن تعيد الصحيحة إلى الخاطئة.

قواعد قديمة متراكمة من عملية نقل سابقة

عمليات النقل مصدر واقعي شائع للحلقات؛ إذ تضيف عمليات HTTP → HTTPS وتوحيد www وتغيير النطاق والمنصة قواعد جديدة فوق قديمة لم تُنظف، وقد تنتهي قاعدتان بالإشارة إحداهما إلى الأخرى. إذا ظهرت الحلقة «فجأة»، فافحص بقايا قواعد النقل.

كيفية تشخيص الحلقة

ينبغي أن ترى الحلقة لا أن تخمنها.

تتبعها من سطر الأوامر بطلب GET فعلي، لا بتتبع HEAD وحده. أرسل نوع الطلب الذي يرسله زائر أو زاحف حقيقي، وسجّل كل كود حالة ورأس Location من دون السماح لـcurl بالمتابعة التلقائية أولًا، لترى كل قفزة لا النتيجة الأخيرة وحدها:

# GET is curl's default method (no -I); -L follows redirects; --max-redirs caps how far
curl -sL --max-redirs 10 -D - -o /dev/null https://www.example.com/ | grep -i -E '^(HTTP/|location:)'
# A loop shows the same two (or few) URLs alternating and never a 200 —
# curl stops with "Maximum (10) redirects followed".

لرؤية عنوان URL الفعلي في كل محطة:

curl -sL --max-redirs 10 -o /dev/null -w '%{http_code} %{url_effective}\n' https://www.example.com/

ثم قارنه بتتبع HEAD فقط (curl -sIL --max-redirs 10 ...) كفحص ثانوي لا دليل أساسي؛ فـHEAD وGET طريقتان مختلفتان وقد يعالجهما التطبيق بصورة مختلفة، فيفوّت تتبع HEAD سلوكًا يظهر مع الطلب الحقيقي. ولا تعِد إرسال طرق غير آمنة مثل POST نموذج لمجرد تتبع الحلقة.

إذا تكرر زوج المضيف/المخطط ولم تر 200 فهذه الحلقة، ويكشف تناوب العنوانين قاعدة التوحيد المتعارضة: المخطط يعني HTTP/HTTPS، والمضيف يعني www/non-www، والشرطة تعني خلل الشرطة. ثم انسب كل قفزة إلى طبقتها: المتصفح/HSTS، أو الحافة/TLS، أو الوكيل العكسي، أو الأصل، أو التطبيق/CMS، أو الجلسة/المصادقة؛ فالحلقة تقع عندما لا تتشارك طبقتان الحالة وتصر كل منهما على رأيها.

مداخل أخرى:

• أدوات المطور في المتصفح → Network. راقب تراكم الطلبات ورأس Location.
• اختبر مع CDN ومن دونه. إذا أمكن الوصول إلى الأصل مباشرةً ولم يدر، فالتعارض بين CDN والأصل، وهذا يوجهك إلى وضع SSL.
• Google Search Console. يبين URL Inspection وتقرير Page Indexing العناوين التي تتعثر فيها Google. تنص الوثائق على أن Inspection Tools لا تتبع إعادات التوجيه؛ فاقرأ النتيجة كتقرير عن العنوان المختبر لا عما بعد الحلقة.
• زاحف للموقع كله مثل Ahrefs Site Audit أو Screaming Frog يكتشف الحلقات المجهولة. في Ahrefs: ازحف الموقع → Redirects → Issues → خطأ «Redirect loop» → View affected URLs لرؤية المسار الكامل.

كيفية إصلاح الحلقة

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

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

في الحالتين استبدل الروابط الداخلية التي تشير إلى عنوان يعيد التوجيه بروابط مباشرة إلى العنوان النهائي، ولا تواصل تغذية المنظومة بعناوين معيدة للتوجيه.

إصلاحات خاصة بالمنصات:

• Cloudflare بحسب وضع SSL: انتقل من Flexible إلى Full أو Full (strict) ليتطابق اتصال CDN→الأصل مع المتصفح→CDN، ولا تفرض HTTPS عند الحافة والأصل معًا. يتطلب Full (strict) شهادة صالحة في الأصل.
• WordPress: راجع Settings → General؛ يجب أن يطابق WordPress Address (URL) وSite Address (URL) المخطط/المضيف الأساسيين. ثم ابحث عن إضافة لفرض SSL أو FORCE_SSL_ADMIN أو مقتطف إعادة توجيه في wp-config.php أو القالب يكرر عمل الخادم/CDN واحذف التكرار. وقد تصلح إعادة توليد .htaccess من Settings → Permalinks تلفه.
• Apache (.htaccess): اجعل لشروط RewriteRule الخاصة بـHTTPS وwww استثناءً للصيغة الصحيحة أصلًا، كي تحول الخاطئة مرة واحدة.
• nginx: المبدأ نفسه؛ يجب ألا تعمل return 301 على طلب في الصيغة الأساسية.

ملاحظة عن حدود القفزات: خرافة يجب تجنبها

لأن الحلقة تبدو «إعادات توجيه كثيرة جدًا»، يلجأ البعض إلى رفع max-redirs أو حد الإضافة. لا يصلح ذلك حلقة حقيقية. فالحلقة ليست مسألة عدد قفزات مثل السلسلة؛ بل تفشل لأن الدورة لا تنتهي. والإصلاح الوحيد هو كسرها.

ملاحظة عن Bing

تسمي Google «حلقة إعادة التوجيه» رسميًا أحد أربعة أسباب لـ«Redirect error» في وثائق فهرسة الصفحات. أما إرشاد Bing العام فيوصي بـ301 للنقل الدائم وتجنب السلاسل غير الضرورية. لم يكشف هذا البحث صفحة Bing باسم «redirect loop»، لكن ذلك فجوة في نطاق الفحص لا إثبات لغياب الإرشاد؛ لذا تعامل مع إطار الأسباب الأربعة كخاص بـGoogle.

مفاهيم مرتبطة

سلسلة إعادة التوجيه مشكلة شقيقة؛ فالسلسلة الطويلة سبب آخر من أسباب «Redirect error»، وهي تُحل بخلاف الحلقة. و301 إعادة التوجيه الدائمة التي تختصر الحلقة إليها عادةً، و302 نظيرتها المؤقتة. وتظهر الحلقة لأغراض SEO غالبًا في حالة redirect error في Search Console.

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

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

• الحلقة دورة لا سلسلة طويلة: A → B → A أو أطول، ولا تعيد 200. السلسلة بطيئة لكنها تُحل، والحلقة لا تُحل؛ لذا لا يفيد رفع حد القفزات، بل يجب كسر الدورة.
• تظهر بطريقتين: ERR_TOO_MANY_REDIRECTS في المتصفح وما يكافئه، وكأحد أربعة أسباب موثقة لـ«Redirect error» في Google Search Console؛ والأخرى سلسلة طويلة جدًا، وطول URL متجاوز، وعنوان سيئ/فارغ.
• ضرر ثلاثي وفق إطار Patrick: المستخدمون محجوبون، والزواحف عالقة، والخادم يهدر الموارد. ويتوقف بلوغ حمل شديد أو DDoS ذاتي على الزيارات وتراجع العملاء والسعة وحدود المعدل، لا على وجود الحلقة وحده.
• سبب موثق جيدًا: تعارض وضع HTTPS/SSL بين CDN والأصل، مثل Cloudflare Flexible مع أصل يفرض HTTPS. ومن الأسباب تعارض www/non-www، والإضافة مع الخادم، وأخطاء الشرطة. لا سبب عالمي واحد، كما أن النقل مصدر شائع.
• شخّص بتتبع GET: سجّل الحالة وLocation لكل قفزة بلا متابعة تلقائية، وقارن HEAD فحصًا ثانويًا. راقب تناوب العناوين، واستخدم Network، والاختبار مع CDN ومن دونه، وURL Inspection الذي لا يتبع التحويلات، وزاحفًا للتوسع.
• أصلح بحسب السبب ثم قاعدة Patrick: إن كان آخر عنوان قبل إغلاق الحلقة هو الوجهة، فاحذف إعادة توجيهه واجعله يعيد استجابة صحيحة؛ وإلا وجّه إعادة التوجيه الدائرة إلى الوجهة الحقيقية. وفي الحالتين أصلح الروابط الداخلية.
• Cloudflare: انتقل من Flexible إلى Full/Full (strict) ولا تفرض HTTPS في الحافة والأصل معًا. WordPress: وحّد Site/WordPress Address واحذف قاعدة أو إضافة فرض SSL المكررة.
• إرشاد Bing أعم من إطار Google ذي الأسباب الأربعة؛ وعدم العثور على صفحة Bing مخصصة للحلقات لا يثبت عدم وجودها.

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

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

Google

• تقرير فهرسة الصفحات — يسمي الحلقة أحد أربعة أسباب لـ«Redirect error» ويقترح أداة تصحيح مثل Lighthouse.
• إعادات التوجيه وبحث Google — وثيقة Google الأساسية، وتوصي بإعادة توجيه دائمة من جانب الخادم حيث يمكن. ولا تستخدم كلمة «loop»؛ فالتسمية في وثيقة الفهرسة أعلاه.
• نقل المواقع مع تغيير عناوين URL — إرشاد السلاسل وحد 10 قفزات وتوصية ≤3 وأقل من 5، المحقق في 2026-07-18. يتعلق بالسلاسل لا الحلقات.
• بنية الزحف/أكواد HTTP — تذكر أن زواحف Google تتبع افتراضيًا حتى 10 قفزات، وقد تختلف المنتجات، وأن Inspection Tools لا تتبع إعادات التوجيه؛ لذا تبلغ عن العنوان المحدد.

Cloudflare (مصدر أساسي واضح لسبب موثق جيدًا)

• ERR_TOO_MANY_REDIRECTS / إعادات توجيه كثيرة جدًا — وثيقة Cloudflare لأسباب داخل منتجها: وضع SSL/TLS الخاطئ، وإعداد Always Use HTTPS، وقواعد التحويل الخاطئة، مع رسم وإصلاح لكل منها.

Bing / Microsoft

• إرشادات Bing لمشرفي المواقع — إرشاد عام باستخدام 301 للنقل الدائم وتجنب السلاسل. لم تظهر صفحة باسم «redirect loop» في البحث؛ وهي فجوة بحث لا إثبات غياب.

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

تصريحات موثقة. يقود كل رابط إلى المقطع المقتبس متى توفر.

Patrick Stox — تعريف حلقة إعادة التوجيه (Ahrefs)

• “Redirect loops are infinite loops of redirects that occur when a URL redirects to itself or when a URL in a redirect chain redirects back to a URL earlier in the chain.” (الترجمة العربية) «حلقات إعادة التوجيه دورات لا نهائية تحدث عندما يعيد عنوان URL التوجيه إلى نفسه، أو عندما يعيد عنوان في سلسلة التوجيه إلى عنوان سابق فيها.» — Patrick Stox، 11 نوعًا من إعادات التوجيه وتأثيرها في SEO، مدونة Ahrefs. انتقل إلى الاقتباس

Patrick Stox — الضرر الثلاثي (Ahrefs)

• “They’re problematic for three reasons: For users – They cut off access to an intended resource and trigger a “too many redirects” error in the browser. For bots and search engines – They “trap” crawlers and waste the crawl budget. For servers - they waste your resources. Some bots will handle this well, others will not. They could potentially take down your server with a constant DDoS attack.” (الترجمة العربية) «إنها مشكلة لثلاثة أسباب: تمنع المستخدمين من المورد المقصود وتعرض خطأ إعادات توجيه كثيرة، وتحاصر برامج الزحف وتهدر ميزانية الزحف، وتهدر موارد الخوادم؛ فقد تتعامل بعض الروبوتات معها جيدًا ولا تفعل أخرى، وربما تُسقط الخادم بحمل يشبه هجوم DDoS مستمر.» — Patrick Stox، 11 نوعًا من إعادات التوجيه وتأثيرها في SEO، مدونة Ahrefs. انتقل إلى الاقتباس

Patrick Stox — كيفية إصلاح الحلقة (Ahrefs)

• “The best way to fix a redirect loop depends on whether the last URL in the chain (before the loop) is the intended final destination. If it is, remove the redirect from the final URL. Then make sure the resource is accessible and returns a 200 status code. If it isn’t, change the looping redirect to the intended final destination.” (الترجمة العربية) «يعتمد أفضل إصلاح للحلقة على كون آخر عنوان قبلها هو الوجهة النهائية المقصودة. إن كان كذلك فاحذف إعادة التوجيه من العنوان النهائي وتأكد أن المورد متاح ويعيد 200. وإن لم يكن فغيّر إعادة التوجيه الدائرة إلى الوجهة المقصودة.» — Patrick Stox، 11 نوعًا من إعادات التوجيه وتأثيرها في SEO، مدونة Ahrefs. انتقل إلى الاقتباس

Google — الحلقة سبب لـ«Redirect error»

• “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، وثيقة مساعدة تقرير فهرسة الصفحات. انتقل إلى الاقتباس

ما سبب حلقة إعادة التوجيه لدي؟

الحلقة دائمًا قاعدة تصارع أخرى؛ والمهمة تحديد أي قاعدتين. تنقل بين الخطوات. (ابدأ بفتح العنوان في نافذة متخفية وتتبع طلب GET إن أمكن عبر curl -sL --max-redirs 10 -D - -o /dev/null لترى العناوين التي تتناوب.)

أي إصلاح أطبق بعد العثور على الحلقة؟

دليل تنفيذ: «الصفحة تدور — ERR_TOO_MANY_REDIRECTS — ماذا أفعل؟»

ترتيب هادئ لمعالجة حلقة حية. نفّذه بالتسلسل وتوقف عند العثور على السبب وإصلاحه. تذكر أنها انقطاع للموقع عند الزوار؛ فأعد الوصول أولًا وحسّن SEO ثانيًا.

0. حدد النطاق (دقيقتان). هل هي في عنوان واحد أم قسم أم الموقع كله؟ حلقة الموقع كله بعد تغيير SSL أو CDN حالة طارئة؛ انتقل إلى الخطوة 3. وحلقة العنوان الواحد غالبًا قاعدة مضيف أو شرطة؛ راجع الخطوتين 2 و4.

1. استبعد متصفحك. افتح العنوان في نافذة متخفية. إن عمل، فالسبب ذاكرة تخزين مؤقت أو ملف تعريف ارتباط محلي قديم؛ امسحهما. وإن دار أيضًا فالمشكلة من جانب الخادم؛ تابع.

2. تتبع كل قفزة بطلب GET، لا HEAD وحده.

curl -sL --max-redirs 10 -o /dev/null -w '%{http_code} %{url_effective}\n' https://www.example.com/

اقرأ العناوين المتناوبة. ما يتبدل يكشف السبب: المخطط (http ⇄ https) يعني SSL/HTTPS (الخطوة 3)، والمضيف (www ⇄ non-www) أو الشرطة يعني الخطوة 4. إذا لم تر 200 وتكرر الزوج، فقد أكدت حلقة لا سلسلة. وقد يفوّت curl -sIL القائم على HEAD سلوك GET؛ فاستخدمه فحصًا ثانويًا فقط.

3. إذا تبدل المخطط، افحص طبقة SSL أولًا (سبب موثق جيدًا مع CDN). هل الموقع خلف Cloudflare أو CDN؟ إن كان، فالأرجح تعارض وضع SSL. إذا كان Cloudflare على Flexible فانقله إلى Full أو Full (strict)؛ إذ يرسل Flexible HTTP إلى أصل يفرض HTTPS. وتأكد أنك لا تفرض HTTPS في موضعين: Always Use HTTPS في الحافة وقاعدة أصل/.htaccess/إضافة؛ احذف واحدة. من دون CDN، أبق واحدة من قاعدتي الأصل.

4. إذا تبدل المضيف أو الشرطة، فاعثر على القاعدتين اللتين تؤديان المهمة نفسها. تكون الحلقة بين طبقات لا تتشارك الحالة: إضافة مقابل .htaccess أو قاعدة CDN مقابل Site Address في CMS. في WordPress راجع Settings → General وأي إضافة لفرض SSL. احذف إحدى القاعدتين كي تحول قاعدة واحدة الصيغة الخاطئة إلى الصحيحة مرة واحدة.

5. طبق الإصلاح البنيوي. حدد آخر عنوان قبل إغلاق الحلقة. إن كان الوجهة المقصودة فاحذف تحويله واجعله يعيد 200. وإن لم يكن فوجّه إعادة التوجيه الدائرة إلى الوجهة الحقيقية. ثم حدّث الروابط الداخلية كيلا تشير إلى عنوان معيد للتوجيه.

6. أعد الاختبار وتأكد من النظافة. شغّل تتبع curl مجددًا. تريد 301 → 200 واحدة أو 200 مباشرةً بلا تناوب. اختبر http:// وhttps://، وwww وnon-www، كيلا تصلح اتجاهًا وتترك الآخر.

7. امسح الذاكرة وأعد التحقق للبحث. امسح ذاكرة CDN/الصفحة كيلا تُخدم استجابات قديمة. وإذا ظهرت الحلقة كـ«Redirect error» في Search Console، فاستخدم URL Inspection وValidate Fix، مع العلم أن إعادة الزحف تستغرق أيامًا أو أسابيع؛ أما إصلاح الزوار فيتحقق عند نجاح الخطوة 6.

8. امنع التالية. احتفظ بمصدر حقيقة واحد لقواعد المخطط/المضيف/الشرطة الأساسية، وبعد أي تغيير SSL أو CDN أو إضافة أو نقل أعد تتبع curl للعناوين المهمة.

إطار الدورة والمالك والثابت

أصلح الحلقات بتوثيق ثلاثة أمور قبل تعديل القواعد:

1. الدورة: اكتب التسلسل المتكرر كاملًا، بما فيه البروتوكول والمضيف والمسار والاستعلام والشرطة. لا تُثبت الحلقة إلا بتكرار عنوان.
2. المالك: حدد الطبقة التي أنشأت كل قفزة: المتصفح/HSTS أو CDN أو موازن الحمل أو خادم الويب أو التطبيق أو الإضافة. الرؤوس وحدود الإعداد أهم من تخمين الخطأ.
3. الثابت: اختر حالة أساسية واحدة تتفق عليها كل الطبقات، عادةً بروتوكول ومضيف وصيغة مسار واحدة. يجوز لكل صيغة غير أساسية أن تتجه إليها، وعلى العنوان الأساسي إعادة استجابة غير معيدة للتوجيه.

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

أدوات كشف دورات إعادة التوجيه

• Redirect Chain Mapper: تتبع كل قفزة وحدد أين يتغير البروتوكول أو المضيف أو الشرطة أو النطاق أو المسار ويتكرر.
• Redirect Checker: افحص بسرعة صيغ HTTP وHTTPS وwww وnon-www بعد الإصلاح.
• Bulk HTTP Status Code Checker: تحقق من عينة أوسع وصدّر الحلقات والسلاسل المتبقية.
• HTTP Header Checker: افحص بصمات CDN/الحافة والرؤوس التي تنسب القفزة إلى طبقتها.
• curl: يعطي curl -sSL --max-redirs 12 -D - -o /dev/null URL تتبع GET خامًا خارج حالة ملفات المتصفح؛ واستخدم -I القائم على HEAD فحصًا ثانويًا فقط. واختبر جلسة جديدة إذا شاركت المصادقة أو ملفات اللغة.
• إعدادات CDN والخادم والتطبيق: قارن كل مالكي التحويل بالثابت المختار للبروتوكول/المضيف/المسار قبل تغيير أي قاعدة.

موارد تستحق وقتك

كتاباتي المرتبطة

• 11 نوعًا من إعادات التوجيه وتأثيرها في SEO — دليلي الكامل وفيه قسم تجنب الحلقات وإطار الضرر الثلاثي واكتشافها وإصلاحها بفرعين.
• 301 مقابل 302 لأغراض SEO — نوع التحويل الذي تختصر إليه الحلقة للنقل الدائم أو المؤقت.
• نقل الموقع يتطلب أكثر من قائمة تدقيق — النقل مصدر شائع وكيف تخطط القواعد كيلا تتصارع.

من أنحاء المجال

• إعادات توجيه كثيرة جدًا (ERR_TOO_MANY_REDIRECTS) — وثيقة Cloudflare الرسمية وأوضح مصدر أساسي لتعارض وضع SSL: Flexible مقابل Full/Full (strict) وAlways Use HTTPS وأسباب شهادات الحافة.
• تقرير فهرسة الصفحات (مساعدة Google Search Console) — يسمي الحلقة أحد أربعة أسباب لـ«Redirect error».
• بحث Google يتجاهل حلقات إعادة التوجيه (Search Engine Roundtable، 2019) — تقرير ثانوي عن تغريدة Mueller مؤرخة؛ لم يُتحقق مستقلًا من الأصل والصياغة، فتعامل معه كسياق لا اقتباس مؤكد.
• إعادات توجيه كثيرة جدًا: إصلاح الحلقات وحماية SEO (Search Engine Land) — دليل واسع للأسباب والإصلاحات في WordPress والبروتوكول.

إحصاءات وحقائق قابلة للاقتباس

• تضر الحلقة ثلاثة أطراف لا طرفًا واحدًا. بحسب دليلي في Ahrefs، تمنع المستخدمين وتحاصر الزواحف وتهدر موارد الخادم، وقد تضيف الروبوتات التي لا تتراجع حملًا بمستوى DDoS بحسب الزيارات وحدود المعدل. المصدر
• الحلقة أحد أربعة أسباب موثقة لـ«Redirect error» في Google Search Console، إلى جانب سلسلة طويلة جدًا وعنوان متجاوز للطول وعنوان سيئ/فارغ. المصدر
• تعارض وضع SSL سبب موثق جيدًا. تشرح Cloudflare كيف ينشئ Flexible الذي يتصل بالأصل عبر HTTP مع أصل يفرض HTTPS حلقة لا نهائية عند حدود CDN/الأصل؛ وهو أحد الأنماط الشائعة داخل منتجها لا ادعاء بأنه السبب الأكثر شيوعًا عالميًا. المصدر

اختبر نفسك: حلقات إعادة التوجيه

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

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