سلاسل إعادة التوجيه

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

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

سلسلة إعادة التوجيه هي عدة استجابات إعادة توجيه متتالية قبل الوصول إلى المورد النهائي. 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: Redirects and Search

عندما تزور عنوان URL قديمًا نُقل، يرسل الخادم إعادة توجيه — وهي استجابة HTTP تقول إن الصفحة المطلوبة موجودة الآن في مكان آخر. في الحالة السليمة تكون خطوة واحدة: تطلب الصفحة A فتصل إلى الصفحة B.

أما سلسلة إعادة التوجيه فتحوّل تلك الخطوة إلى عدة خطوات. تطلب A، فتوجّهك إلى B، ثم توجّهك B إلى C، وهي الصفحة الفعلية. كل محطة وسيطة قفزة. وبدل A → C مباشرةً تحصل على A → B → C — أو سلسلة أطول.

لماذا تحدث؟

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

هل تضر؟

قليلًا، وغالبًا بأقل مما يخشاه الناس. التكلفتان الحقيقيتان هما:

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

ما لا تفعله السلسلة هو استنزاف جزء من قوة الترتيب عند كل قفزة؛ هذه خرافة قديمة. إعادة التوجيه الدائمة لا تخصم قيمة ترتيب بحد ذاتها.

الحل

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

لا تقلق من قفزة إضافية عابرة في صفحة لا يزورها أحد. لكن نظّف السلاسل الطويلة في صفحاتك المهمة كثيرة الزيارة.

هل تريد أرقام القفزات التي تنشرها Google، وأسباب تكوّن السلاسل، وطرق اكتشافها من سطر الأوامر أو بأداة زحف؟ انتقل إلى تبويب متقدم.

الخلاصة — سلسلة إعادة التوجيه هي A → B → C بدل A → C مباشرةً، وكل قفزة إعادة توجيه واحدة، وتنتهي السلسلة عند أول استجابة ليست إعادة توجيه — وليست بالضرورة 200. وهي نتيجة شبه حتمية لتراكم عمليات النقل وتعارض الإضافات وعدم ترتيب القواعد، لا لعدم الكفاءة. أرقام القفزات الثلاثة تصف أمورًا مختلفة: 10 هو الحد التقني الذي يتبعه Googlebot في الوثائق الحالية، و**≤3 وأقل من 5** توصية Google العملية. ووصف Mueller نحو 5 قفزات لكل زحف في 2014 ونحو 5 لكل محاولة زحف في 2020؛ كما ذكر في 2014 إمكان متابعة الباقي في زحف لاحق. هذه تصريحات تمثيلية مؤرخة وليست ضمانًا حاليًا لجدولة الزحف. وملاحظتي أن Google تستأنف السلاسل الأطول دليل ممارس مستقل. التكلفة الموثقة هي زمن الاستجابة ومعالجة الزحف، لا فقدان PageRank مع كل قفزة؛ فإعادة توجيه دائمة واحدة لا تفقد PageRank. والحل ثابت: وجّه كل قاعدة إلى الوجهة النهائية الحية، ثم أصلح الروابط الداخلية والروابط الأساسية وخرائط الموقع التي لا تزال تُدخل الطلب إلى السلسلة.

ما الذي يُعد سلسلة، وما الذي لا يُعد كذلك؟

كل قفزة 3xx تبادل HTTP مستقل. 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 لا توجد نسبة عامة موثقة لفقدان الترتيب ولا حد زحف ثابت، لذا تبقى القفزة المباشرة الواحدة الهدف القابل للدفاع عنه. 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: Redirects and Search

سلسلة إعادة التوجيه هي استجابتان متتاليتان أو أكثر قبل أول استجابة غير معيدة للتوجيه — A → B → C بدل A → C. كل إعادة توجيه قفزة. وتنتهي السلسلة عند أي استجابة لا تعيد التوجيه: غالبًا 200 سليمة، لكنها قد تكون 404 أو 500 أو طلب مصادقة أو نتيجة نهائية أخرى. والسلسلة التي تنتهي بخطأ تظل سلسلة معطلة، ولا تصبح حلقة تلقائيًا.

حلقة إعادة التوجيه مشكلة مختلفة وأكثر تحديدًا: إنها دورية. تعود إحدى القفزات إلى عنوان زاره المسار من قبل، فلا يصل الطلب إلى استجابة نهائية ويعرض المتصفح ERR_TOO_MANY_REDIRECTS. الفارق المهم هو دوري مقابل غير دوري، لا طويل مقابل قصير ولا «ينتهي بخطأ» مقابل «ينتهي بـ200». حلقة من قفزتين تظل حلقة، وسلسلة من عشر قفزات تنتهي بـ404 تظل سلسلة.

في مقالتي 11 Types Of Redirects & Their SEO Impact لخّصتها هكذا: “Redirect chains are when multiple redirects take place between a requested resource and its final destination.” (ترجمة) «تحدث سلاسل إعادة التوجيه عندما تقع عدة عمليات إعادة توجيه بين المورد المطلوب ووجهته النهائية.»

لماذا تحدث السلاسل عمليًا؟

نادرًا ما تنتج السلسلة من قرار مهمل واحد؛ بل تتراكم:

• عمليات نقل متراكبة. يُعاد توجيه عنوان أثناء نقل النطاق، ثم في انتقال HTTPS، ثم عند تغيير المنصة؛ فتضيف كل عملية طبقة بدل استبدال السابقة. المسار http://old → https://old → https://new ثلاث قواعد حين تكفي واحدة.
• معالجة www/non-www وHTTP/HTTPS بقواعد منفصلة. المسار http://www → https://www → https://non-www سلسلة كلاسيكية من ثلاث قفزات يجب دمجها.
• تعارضات CMS والإضافات. قد تعمل إضافتا إعادة توجيه، أو قاعدة إضافة وقاعدة خادم، على العنوان نفسه.
• وضع قواعد البدل قبل القواعد المحددة. إذا سبقت قاعدة عامة (النطاق القديم → الصفحة الرئيسية الجديدة) القاعدة المحددة فلن تعمل المحددة أصلًا. ولهذا يطلب Bing وضع القواعد المحددة قبل قاعدة البدل.

مثال عملي لنقل موقع: ثلاث قواعد منطقية وسلسلة غير ضرورية

تراكمت في موقع ملابس ثلاثة تغييرات، لكل منها مبرره منفردًا:

301  http://old-shop.example/products/trail-shoe
301  https://old-shop.example/products/trail-shoe
301  https://shop.example/products/trail-shoe
200  https://shop.example/shoes/trail-runner

ترقّي القاعدة الأولى HTTP، وتنقل الثانية النطاق، وتعكس الثالثة إعادة تسمية في الكتالوج. ليست المشكلة في عملية بعينها، بل في أن نقطة الدخول القديمة تعيد تشغيل القرارات التاريخية الثلاثة كلها.

استبدل ذلك المسار بإعادة توجيه دائمة مباشرة واحدة:

301  http://old-shop.example/products/trail-shoe
200  https://shop.example/shoes/trail-runner

ثم حدّث الروابط الداخلية والروابط الأساسية وإدخالات خريطة الموقع التي لا تزال تعلن عنوانًا وسيطًا. هذا تتبع توضيحي على نطاق .example، لا تقرير عن شركة بعينها.

ومن الأنماط المضادة المهمة: لا تضع قاعدة عامة «كل شيء → الصفحة الرئيسية» فوق إعادات التوجيه المحددة القائمة. تحذر Google من أن توجيه عناوين قديمة كثيرة إلى وجهة واحدة غير ذات صلة “might be treated as a soft 404 error.” (ترجمة) «قد يُعامل كخطأ 404 ميسّر.» وجّه العناوين القديمة إلى نظائرها الحقيقية بنسبة 1:1.

كم قفزة يتبع Google فعلًا؟

هنا تخلط المقالات المتنافسة ثلاثة أرقام مختلفة. وهي متكاملة لا متناقضة:

1. الحد التقني — 10 قفزات. تقول وثيقة Google لنقل المواقع مباشرةً: “While Googlebot can follow up to 10 hops in a ‘chain’ of multiple redirects (for example, Page 1 > Page 2 > Page 3), we advise redirecting to the final destination directly.” (ترجمة) «مع أن Googlebot يستطيع متابعة ما يصل إلى 10 قفزات في سلسلة من عدة عمليات إعادة توجيه، ننصح بالتوجيه مباشرةً إلى الوجهة النهائية.» وعشر قفزات هي أقصى ما سيتبعه Googlebot إجمالًا قبل التوقف.

2. التوصية العملية — ≤3 وأقل من 5. تقول الجملة نفسها في الوثيقة نفسها: “If this is not possible, keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5.” (ترجمة) «إن تعذر ذلك، فأبق عدد إعادات التوجيه منخفضًا، ويفضل ألا يزيد على 3 وأن يكون أقل من 5.» هذه نصيحة Google نفسها لا تخمين طرف ثالث.

3. التصريحات التمثيلية المؤرخة — نحو 5 قفزات لكل زحف. في جلسة مشرفي المواقع لعام 2014 عند 46:03، وصف John Mueller اتباع Googlebot ما يصل إلى خمس إعادات توجيه في زحف واحد، ثم متابعة الباقي في الزحف التالي. وفي تعليق منفصل على Reddit عام 2020 نقلته Search Engine Journal قال إن Google يتبع “up to 5 hops in the chain per crawl attempt.” (ترجمة) «ما يصل إلى 5 قفزات في السلسلة لكل محاولة زحف.» تصريح 2014 دليل تمثيلي حقيقي على المتابعة اللاحقة، لكنه تاريخي؛ فلا تحوله إلى ضمان بأن Googlebot الحالي سيستأنف دائمًا أو وفق جدول متوقع.

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

الخلاصة: 10 هو الحد الحالي الموثق لدى Google؛ و3 إلى 5 (والأقل أفضل) هدفها العملي الحالي؛ ونحو 5 لكل زحف توجيه تمثيلي مؤرخ من Mueller. لا تفشل السلسلة الأطول من 5 بالضرورة، بل تؤخر عادةً وصول Google وتجميع الإشارات على الوجهة. وبعد حد 10 قد يظهر خطأ إعادة توجيه في تقرير فهرسة الصفحات في Search Console، لكن لا توجد مطابقة مضمونة واحدًا لواحد؛ فهذا يعتمد على ما رصده الزاحف في المحاولة، وقد تُحل السلسلة ببطء بدل ظهور خطأ محدد.

لماذا تهم السلاسل — وخرافة أنها لا تهم

التكلفة الموثقة للسلسلة هي زمن الاستجابة ومعالجة الزحف، لا فقدان الإشارة مع كل قفزة. وبصياغة Google، فإن تسلسل إعادات التوجيه “adds latency for users, and not all user agents and browsers support long redirect chains.” (ترجمة) «يضيف زمن استجابة للمستخدمين، ولا تدعم جميع وكلاء المستخدم والمتصفحات سلاسل إعادة التوجيه الطويلة.»

افصل ذلك عن خرافة «فقدان PageRank مع كل إعادة توجيه». توضح Google أن “301 and other permanent redirects don’t cause a loss in PageRank.” (ترجمة) «لا تسبب 301 وإعادات التوجيه الدائمة الأخرى فقدان PageRank.» يتعلق هذا بقفزة واحدة؛ ولا يعني أن سلسلة بلا حد مجانية، لأن تكلفتها مختلفة: زمن الزحف ووقت تجميع الإشارات، لا تسرب القيمة مع كل قفزة. يمكن أن يصح الأمران معًا: إعادة واحدة لا تفقد PageRank، وسلسلة طويلة تهدر معالجة الزحف وتؤخر الفهرسة.

متى تصلح سلسلة، ومتى لا يستحق الأمر؟

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

حدي العملي: لا أقلق عادةً من السلاسل التي تقل عن نحو 5 قفزات، لكنني رأيت بعد 5 مشكلات في زحفها واحتسابها بصورة سليمة؛ لذلك أبدأ عندها التوصية بالعمل. وراعِ قيمة المسار: سلسلة من 5 قفزات في عنوان عالي القيمة كثير الزحف تستحق الإصلاح، أما قفزة زائدة عابرة في صفحة قليلة الزيارات فعادةً لا تستحق وقتك.

كيفية العثور على سلاسل إعادة التوجيه

يتم الاكتشاف على مستويين: سطر الأوامر للفحص الموضعي، والزواحف للموقع كله:

• يطبع curl -IL <url> على macOS/Linux (أو Invoke-WebRequest على Windows) حالة كل قفزة حتى 200 النهائية؛ وهو أسرع تتبع لعنوان واحد. راجع تبويب Scripts.
• في أدوات المطور → Network حمّل العنوان وراقب طلبات 301/302 قبل 200.
• في Screaming Frog استخدم Response Codes ثم Reports → Redirects → Redirect Chains لتصدير السلاسل وأعداد قفزاتها.
• في Ahrefs Site Audit يعلّم تقرير Redirects مشكلة “Redirect chain too long”. ويمكن في Site Explorer ترشيح الروابط حسب “No. of redirects”، كما يعرض تبويب HTTP headers في Ahrefs SEO Toolbar التسلسل للرابط الذي تنقره.

تقرير السلاسل جزء واحد فقط من مراجعة القواعد القائمة. يفحص تدقيق منظومة إعادة التوجيه أيضًا الوجهات النهائية الميتة، والتحويلات العامة إلى الصفحة الرئيسية، وقواعد البدل الواسعة التي تبتلع العناوين الحية، وإمكان إيقاف قاعدة مهجورة عبر اختبار 404 مسجل وقابل للعكس.

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

قاعدة واحدة في كل مكان: وجّه كل إعادة توجيه مباشرةً إلى الوجهة النهائية الحية، ولا توجّهها إلى إعادة توجيه أخرى. إصلاح السلسلة يعني تغيير هدف كل قاعدة من العنوان الوسيط إلى العنوان النهائي الحقيقي. تصبح A → B → C هي A → C وB → C.

ثم أكمل الجزء الذي يتجاهله معظم الناس:

• حدّث الروابط الداخلية لتشير إلى العنوان النهائي لا إلى عنوان يعيد التوجيه، وإلا واصل موقعك تغذية السلسلة.
• حدّث الوسوم الأساسية وخرائط XML التي ما زالت تسرد عناوين قديمة أو وسيطة.
• رتّب القواعد: القواعد المحددة قبل البدل والقواعد العامة، وادمج توحيد www/HTTPS في قاعدة واحدة حيث يمكن.
• تحقق من أكواد الحالة لا الوجهات فقط إذا لم يكن الطلب صفحة عادية. قد تسمح 301 و302 للعميل بتحويل POST إلى GET في القفزة التالية، بينما تحفظ 307 و308 الطريقة الأصلية. وقد تكسر سلسلة تبدو سليمة في المتصفح إرسال نموذج أو نداء API أو عنوانًا موقّعًا أو webhook إذا اختلط نوع الحالة الخطأ.

عندها تنهار السلسلة إلى قفزة واحدة، وهذا كل ما احتجته.

قراءة مرتبطة في هذه المجموعة: الفرق بين إعادة التوجيه الدائمة والمؤقتة (301 مقابل 302)، وما يحدث عندما لا تنتهي السلسلة أبدًا (حلقات إعادة التوجيه).

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

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

• التعريف: السلسلة A → B → C بدل A → C؛ وكل إعادة توجيه قفزة. تنتهي عند أول استجابة غير معيدة للتوجيه، سواء نجحت أو أخفقت، وليست بالضرورة 200. أما الحلقة فدورية وتعود إلى عنوان زاره المسار نفسه.
• أسبابها: عمليات نقل متراكبة، وقواعد منفصلة لـwww/non-www وHTTP/HTTPS، وتعارضات CMS والإضافات، وقواعد بدل تسبق القواعد المحددة.
• الأرقام الثلاثة: 10 الحد التقني الحالي في وثائق Google؛ و**≤3 وأقل من 5** توصيتها العملية؛ ونحو 5 لكل زحف/محاولة تصريحات Mueller مؤرخة من 2014 و2020. ذكر 2014 متابعة الباقي لاحقًا، لكن ذلك ليس ضمان جدولة حاليًا، وملاحظة Patrick المماثلة دليل ممارس مستقل.
• بعد الحد: ما فوق نحو 5 يؤخر التجميع عادةً بدل الفشل الفوري. وبعد 10 قد يظهر خطأ في Search Console، دون مطابقة مضمونة لأنه يعتمد على رصد الزاحف.
• التكلفة الحقيقية زمن الاستجابة ومعالجة الزحف، لا فقد PageRank لكل قفزة.
• موقف Patrick: لا تفرط في تحسين قفزة عابرة؛ حده نحو 5 مع مراعاة تكرار الزحف.
• الحل: وجّه كل قاعدة إلى الوجهة النهائية، وحدّث الروابط الداخلية والروابط الأساسية وخرائط الموقع، وضع القواعد المحددة قبل قواعد البدل.

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

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

Google

• نقل المواقع مع تغيير عناوين URL — يتضمن إرشاد تجنب السلاسل، وحد 10 قفزات، وتوصية ≤3/أقل من 5، والتحذير من توجيه عناوين قديمة كثيرة إلى وجهة واحدة غير ذات صلة.
• تأثير أكواد HTTP وأخطاء الشبكة وDNS في بحث Google — معالجة Google لإعادات 3xx.
• إعادات التوجيه وبحث Google — الأنواع التي يتعرف إليها Google وكيف يعاملها.
• تحسين ميزانية الزحف — سياق كفاءة الزحف وأثر الخطوات المهدرة في المواقع الكبيرة.

Bing / Microsoft

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

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

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

Google — حدود القفزات والتوصية

• “Avoid chaining redirects. While Googlebot can follow up to 10 hops in a ‘chain’ of multiple redirects (for example, Page 1 > Page 2 > Page 3), we advise redirecting to the final destination directly. If this is not possible, keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5.” (ترجمة) «تجنب تسلسل إعادات التوجيه. يستطيع Googlebot متابعة ما يصل إلى 10 قفزات في سلسلة متعددة، لكننا ننصح بالتوجيه مباشرةً إلى الوجهة النهائية. وإن تعذر ذلك، فأبق العدد منخفضًا، ويفضل ألا يزيد على 3 وأن يكون أقل من 5.» — Google Search Central، نقل المواقع مع تغيير عناوين URL. انتقل إلى الاقتباس

• “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error.” (ترجمة) «لا توجّه عناوين URL قديمة كثيرة إلى وجهة واحدة غير ذات صلة، مثل الصفحة الرئيسية للموقع الجديد؛ فقد يربك ذلك المستخدمين ويُعامل كخطأ 404 ميسّر.» — Google Search Central، نقل المواقع مع تغيير عناوين URL. انتقل إلى الاقتباس

• “301 and other permanent redirects don’t cause a loss in PageRank.” (ترجمة) «لا تسبب 301 وإعادات التوجيه الدائمة الأخرى فقدان PageRank.» — Google Search Central، نقل المواقع مع تغيير عناوين URL. انتقل إلى الاقتباس

John Mueller، Google (2020، عبر نقل Search Engine Journal لتعليقه في Reddit)

• “The only thing I’d watch out for is that you have less than 5 hops for URLs that are frequently crawled. With multiple hops, the main effect is that it’s a bit slower for users. Search engines just follow the redirect chain (for Google: up to 5 hops in the chain per crawl attempt).” (ترجمة) «الشيء الذي أراقبه هو أن تقل القفزات عن 5 للعناوين كثيرة الزحف. مع عدة قفزات يكون الأثر الأساسي بعض البطء للمستخدمين. تتبع محركات البحث السلسلة فحسب؛ وبالنسبة إلى Google حتى 5 قفزات لكل محاولة زحف.» — John Mueller، كما نقلت Search Engine Journal. اقرأ التغطية

John Mueller، Google (جلسة مشرفي المواقع 2014؛ فيديو أصلي)

• وصف Mueller اتباع Googlebot ما يصل إلى خمس إعادات توجيه في زحف واحد، ثم متابعة الباقي في الزحف التالي إن وُجد. شاهد من 46:03

Bing — ضمان جودة النقل

• “Crawling the new website thereafter will reveal any unexpected errors, such as unnecessary redirect chains or error pages.” (ترجمة) «سيكشف زحف الموقع الجديد بعد ذلك أي أخطاء غير متوقعة، مثل سلاسل إعادة التوجيه غير الضرورية أو صفحات الخطأ.» — مدونة Bing لمشرفي المواقع، نقل موقع باستخدام Bing. انتقل إلى الاقتباس

قائمة تدقيق سلاسل إعادة التوجيه

خطوات للعثور على السلاسل وترتيبها وتسطيحها دون هندسة زائدة:

اعثر عليها

• ازحف الموقع كله باستخدام Screaming Frog أو Ahrefs Site Audit واستخرج تقرير السلاسل (Screaming Frog: Reports → Redirects → Redirect Chains؛ وAhrefs: Redirects → “Redirect chain too long”).
• افحص العناوين المهمة بـcurl -IL <url> وتأكد أن كلًا منها ينتهي باستجابة 200 واحدة.
• افحص مسببات النقل الواضحة: الجذر/الرئيسية، وhttp:// مقابل https://، وwww مقابل non-www.
• راجع تقرير فهرسة الصفحات في Search Console لأخطاء إعادة التوجيه؛ قد تظهر السلسلة التي تتجاوز الحد، لكن ليست كل سلسلة طويلة تولد الخطأ نفسه.

رتّب الأولويات (لا تصلح كل شيء)

• رتّب حسب القفزات، وابدأ بما يبلغ 5 قفزات فأكثر.
• وازن بالزيارات وتكرار الزحف: أصلح المسارات المهمة قبل القفزات العابرة.
• تأكد أن العنصر سلسلة تنتهي بـ200 لا حلقة لا تنتهي وتعرض ERR_TOO_MANY_REDIRECTS؛ فالحلقات إصلاح مستقل وأكثر إلحاحًا.

أصلحها

• وجّه كل قاعدة إلى الوجهة الحية النهائية لا إلى عنوان وسيط.
• حدّث الروابط الداخلية التي تشير إلى عناوين تعيد التوجيه.
• حدّث الوسوم الأساسية وخرائط XML ذات العناوين القديمة/الوسيطة.
• ضع القواعد المحددة قبل قواعد البدل والعامة.
• ادمج توحيد www/non-www وHTTP/HTTPS في قاعدة واحدة حيث يمكن.
• أعد الزحف وتأكد أن كل عنوان مُصلح يُحل في قفزة واحدة.

تتبع سلسلة من سطر الأوامر

أسرع طريقة لرؤية قفزات عنوان واحد هي curl. يجلب -I الرؤوس فقط، ويطلب -L متابعة إعادات التوجيه كي ترى السلسلة كلها لا القفزة الأولى.

يرسل -I طلب HEAD لا GET. تجيب معظم القواعد الطلبين بالطريقة نفسها، لكن طبقة التطبيق أو CDN أو WAF أو المصادقة قد تفرق بينهما. يكفي ذلك للفحص السريع؛ أما المسارات الحساسة للطريقة، كنموذج أو API أو عنوان موقّع، فاحذف -I وشغّل تتبع GET.

macOS / Linux

# -I headers only, -L follow redirects, -s quiet, and print each status line + Location
curl -sILo /dev/null -w '%{http_code} %{url_effective}\n' https://example.com/old-page

# Or see the full header of every hop in the chain, down to the final response:
curl -sIL https://example.com/old-page | grep -Ei '^(HTTP/|location:)'

# GET-based trace (safer than -I's HEAD request for method-sensitive paths;
# -o /dev/null discards the response body, -w prints the final status/URL)
curl -sL -o /dev/null -w '%{http_code} %{url_effective}\n' https://example.com/old-page

تطبع النتيجة النظيفة ذات القفزة الواحدة حالة إعادة توجيه مثل 301 ثم 200. وتطبع السلسلة عدة حالات قبل 200؛ عدّها لتحصل على عدد القفزات.

HTTP/2 301
location: https://example.com/intermediate
HTTP/2 301
location: https://www.example.com/final
HTTP/2 200          # <- 2 hops before landing here = a 2-hop chain

Windows (PowerShell)

يتبع Invoke-WebRequest إعادات التوجيه تلقائيًا؛ لذا تتبعها بفحص السجل:

# Follow redirects and print the status of each hop plus the final URL
$r = Invoke-WebRequest -Uri "https://example.com/old-page" -MaximumRedirection 10
$r.BaseResponse.RequestMessage.RequestUri   # the final resolved URL

# To see each intermediate hop, disable auto-follow and step through manually:
$u = "https://example.com/old-page"
do {
  $resp = Invoke-WebRequest -Uri $u -MaximumRedirection 0 -SkipHttpErrorCheck
  "{0}  {1}" -f $resp.StatusCode, $u
  $u = $resp.Headers.Location
} while ($u)

الكشف على مستوى الموقع (الزواحف)

فحوص سطر الأوامر لعنوان واحد. وللموقع كله استخدم زاحفًا:

• Screaming Frog SEO Spider — ازحف ثم استخدم Reports → Redirects → Redirect Chains لتصدير كل سلسلة وعدد قفزاتها ومسارها الكامل. ويوفر Response Codes العرض التفاعلي.
• Ahrefs Site Audit — يعرض تقرير Redirects مشكلة “Redirect chain too long” تلقائيًا، ويمكن في Site Explorer ترشيح الروابط حسب “No. of redirects”.

تعطيك الأداتان قائمة الموقع؛ استخدم curl -IL للتحقق من أن كل إصلاح صار قفزة واحدة.

أعراض سلاسل إعادة التوجيه الشائعة

HTTP → HTTPS → www (أو العكس) في كل طلب

السبب المرجح: توحيد البروتوكول واسم المضيف في قاعدتين، فتضيف كل منهما قفزة.

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

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

السبب المرجح: راكمت عمليات النقل المتتالية قواعد جديدة فوق الخرائط القديمة: /old → /less-old → /new.

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

تعود السلسلة بعد تغيير CMS أو إضافة

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

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

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

السبب المرجح: يعمل نمط واسع قبل المطابقة المحددة، فيرسل العنوان إلى وجهة وسيطة.

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

موجه لترتيب دفعة من تتبعات إعادة التوجيه

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

Audit these redirect traces. For each source URL:
- count redirect hops before the final non-redirect response;
- flag loops, broken final responses, temporary redirects inside an intended
  permanent move, and chains longer than 5 hops;
- identify the direct source-to-final mapping that would flatten the chain;
- prioritize by user/search traffic, internal-link count, and severity;
- distinguish a technical ceiling from best practice: do not claim that every chain
  under 10 hops is healthy or that one low-value extra hop is automatically urgent;
- never invent a destination when the supplied trace has no valid final equivalent.

Return a table with source URL, hop count, final status, issue, recommended direct
mapping, priority, and evidence. Then list internal links, canonicals, and sitemap
entries that still point into a chain if those columns are present.

DATA:
[PASTE REDIRECT TRACE CSV HERE]

راجع الخرائط المقترحة مقابل تكافؤ المحتوى قبل تغيير قواعد الإنتاج.

التوفيق بين أرقام قفزات إعادة التوجيه

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

أدوات العثور على السلاسل وتسطيحها

• Redirect Chain Mapper — تتبع كل قفزة لعنوان أو دفعة، وشاهد التغييرات وصدّر قواعد التنظيف.
• Redirect Checker — فحص سريع للحالة والوجهة وتسلسل القفزات.
• Bulk HTTP Status Code Checker — الصق قائمة أكبر ورشّح المسارات متعددة القفزات والمؤقتة.
• زاحف موقع كامل — اعثر على الروابط الداخلية والأساسية وhreflang وخرائط الموقع التي تدخل السلسلة؛ فتسطيح قاعدة الخادم نصف التنظيف فقط.

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

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

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