سلاسل إعادة التوجيه: كيف تحدث، ما تكلفتها، وكيفية مسطحتها

سلسلة إعادة التوجيه هي العيب الفني النادر الذي يختبئ خلف إشارة خضراء. اكتب URL، احصل على الصفحة، الحالة 200 — كل اختبار عادي ينجح، لأن كل عميل عادي HTTP يتبع السلسلة بأكملها بصمت ويبلغ فقط أين وصل. القفزات بينهما موجودة، تُحسب في كل استرجاع، ولا شيء في المتصفح يخبرك بعددها.

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

سلسلة 4-قفزة تتشكل من 4 قرارات صحيحة منفصلة

تتراكم السلاسل طبقة واحدة في كل مرة، وتكسب كل طبقة مكانها عندما تصل:

1. يصل TLS. يضيف شخص ما قاعدة حافة ترسل http:// إلى https://. الوجهة المقصودة الآن تستخدم HTTPS.
2. يُختار مضيف كنسي. تُعَدّ الفرقة على www، لذلك يُعيد القمة التوجيه إليه. يجب أن يؤدي اسم المضيف الشقيق إلى نفس الوجهة المقصودة.
3. يتم تطبيع الشرطات الخلفية. يضيف إطار عمل أو افتراضي CDN قاعدة لإلحاق أو إزالة الشرطة النهائية. يجب أن تستخدم الروابط المنشورة وبيانات خريطة الموقع النمط المقصود باستمرار.
4. يُرسل التدويل. تبدأ مسارات الجذر في التوجيه إلى بادئة اللغة، /blog/ إلى /en/blog/. تحتاج الصفحات المترجمة إلى عناوين URL مستقرة مميزة، على الرغم من أن إعادة التوجيه من الجذر هي خيار تصميم الموقع.

هذه هي 4 قواعد صحيحة، والآن يصل http://example.com/blog إلى وجهته عبر 4 إعادة توجيه. نقل نظام إدارة المحتوى الذي يعيد كتابة /blog/* إلى /articles/* يضيف 5 دون لمس أي من الأربعة 4، لأنّها مُطبقة في التطبيق بينما يعيش الآخرون في الحافة، خادم الويب، والموجه. تُطلق القواعد بالترتيب الذي يمر به الطلب عبر المكدس، وليس بالترتيب الذي سيحلّق فيه الـ URL بأسرع. لا يملك أحد التركيب.

هذا هو أيضًا سبب أن نتيجة http‑to‑https في بياناتنا الخاصة يجب قراءتها بعناية. بين 23 مايو و31 أغسطس 2026، تم إشارة إلى التوحيد من HTTP إلى HTTPS في 44٪ من 171 تقييمًا ولكن فقط 8٪ من 48 موقعًا مميزًا. مستوى الموقع 8% هو رقم الانتشار؛ رقم التقييم يصف ملاحظاتنا، وليس الويب. يتم تقييم الفحص في كل مرة يُشغَّل فيها التدقيق، لذا فإن عددًا قليلًا من المواقع التي تم تدقيقها مرارًا وتكرارًا بينما استمر العيب يساهم في العديد من التقييمات الفاشلة لكل منها، ويؤدي ذلك إلى رفع معدل التقييم بعيدًا عن حصة المواقع المتأثرة. اقتباس 44% كـ "44% من المواقع" سيُبالغ في انتشار أكثر من عامل 5.

Google يتابع حتى 10 قفزات ويُنصح بالبقاء تحت 5

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

ينقسم التكلفة إلى 3 أجزاء، وتتحمل أوزانًا غير متساوية:

كفاءة الزحف. كل قفزة هي طلب يستهلكه الزاحف الخاص بـ Google دون استلام محتوى — التوثيق واضح أن المحتوى المُعاد بواسطة إعادة توجيه URL يُتجاهل ويُعالج فقط محتوى الهدف النهائي. على موقع يحتوي على بضع مئات من الروابط، هذا هو الضوضاء. على موقع حيث توجد السلسلة في نمط URL، كل رابط داخلي يستخدم، يتضاعف عبر كامل الزحف ويتنافس مع حد قدرة الزحف الذي يواجهه المضيف نفسه بالفعل.

الزمن اللازم، في كل جلب غير مخزن مؤقتاً. القفزة هي رحلة كاملة: DNS قد تكون دافئة بالفعل، لكن إعادة استخدام الاتصال تنتهي في اللحظة التي تتغير فيها القفزة المضيف، وهو ما يفعله خطوة example.com إلى www.example.com حسب التعريف. يشعر المستخدمون بهذا مرة واحدة ثم يتوقفون عن الشعور به، لأن المتصفحات تخزن إعادة التوجيه الدائمة مؤقتاً. الآلات التي تجلب باردة، بدون ذاكرة مؤقتة دافئة، تشعر به في كل مرة.

توحيد الإشارة، وهو المكان الذي يعيش فيه الأسطورة. الادعاء القديم هو أن كل قفزة تنزف نسبة من قيمة الرابط. Google نفيت ذلك علناً في يوليو 2016، عندما صرح غاري إيليس صراحةً أن إعادة التوجيه 30x لا تفقد PageRank، موضحاً ما قاله John مولر بالفعل حول تحولات http إلى https في وقت سابق من ذلك العام. النسخة الدائمة للقلق أضيق ولا تزال حقيقية: 301 هو أقوى إشارة توحيد يمكن الحصول عليها، وقيمة إعادة التوجيه هي أنها تُحدد وجهة واحدة بوضوح. السلسلة لا تزال تُحدد وجهة واحدة، لذا حجة القيمة هي الأضعف من أسباب 3 لتسطيح. كفاءة الزحف والوقت اللازم يحملان القضية.

الجالسات والوكالات الذكية تتعامل مع السلاسل أقل تسامحاً من المتصفحات

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

curl لا يتبع أي شيء على الإطلاق بدون -L؛ السلسلة تُرجع 301 عاريًا وجسمًا فارغًا. كل عميل مكتبة HTTP يختار سقف القفزة الخاص به وفرضته الافتراضية ما إذا كان سيتبع على الإطلاق، وتُحدد هذه الافتراضات من قبل من كتب كود الجلب، وليس من قبل الموقع. عملاء متوافقين مع المواصفات يزيلون بيانات الاعتماد عندما يمر إعادة التوجيه عبر أصول، وهو بالضبط ما تفعله قفزة apex إلى www. تتغير دلالات الطريقة أيضًا: 301 و302 لهما تاريخ طويل من إعادة كتابة POST إلى GET، بينما 307 و308 تحافظان على الطريقة الأصلية — اختلاف يهم في اللحظة التي يقدّم فيها الوكيل بدلاً من القراءة.

أضف قيد الميزانية. ملخص أو وكيل يعمل صفحة تحت حد زمني يقضي جزءًا منها على قفزات لا تُرجع محتوى، والجلب الذي يتجاوز سقف القفزة الداخلي يبدو متطابقًا مع موقع متوقف. السلسلة لا تُبلغ نفسها كسلسلة؛ تُبلغ كنتيجة فارغة. هذا هو نفس شكل الفشل كما في تعارضات التوجيه في بيانات قابلية الفهرسة لدينا — يعمل الموقع للناس ويقلّب بهدوء للعمل للآلات.

تسطيح في خطوات 4: الجرد، الانكماش، إعادة الربط، احتفاظ الخريطة

1. جرد عدد القفزات الحقيقية. قِس، لا تفكر في التكوين. بالنسبة لـ URL واحد:

curl -sIL -o /dev/null -w '%{num_redirects} hops -> %{url_effective}\n' http://example.com/blog
curl -sILD - -o /dev/null http://example.com/blog | grep -iE '^(HTTP/|location)'

السطر الأول يعطي العدد، السطر الثاني المسار. نفّذها على نماذج http:// و https://، القمة و www، مع أو بدون شرطة أخيرة، وعلى نموذج ممثل URL من كل قالب — السلسلة عادةً ما تعيش في نمط، وليس صفحة. يقوم audit بنفس المسار على الصفحة الرئيسية، الهدف الكانوني، والمضيف البديل في تمريرة واحدة، ويبلغ المسار الممسوح كدليل.

2. احصر كل سلسلة إلى 301 واحد. خذ مدخل URL والوجهة النهائية من الجرد واكتب قاعدة واحدة تربط الأول مباشرةً بالآخر، في الطبقة الخارجية التي يمكنها رؤية الكليتين — عادةً الحافة أو CDN. ثم أوقف القواعد الوسيطة التي كانت تشكل السلسلة، بدلاً من تركها في مكانها خلف الجديدة. استخدم 301 للانتقال الدائم، و308 عندما يجب أن يبقى الأسلوب. يجب أن يكون الهدف 200 يعلن نفسه كـ canonical؛ إعادة توجيه ينزل على صفحة يوجّه canonical إلى مكان آخر تعيد تشغيل الغموض في مفردات مختلفة، وهو التفاعل الذي تعمل من خلاله canonical tags guide.

3. وجه الروابط الداخلية إلى URLs النهائية. لا تزال قاعدة مسطحة تكلف قفزة على كل رابط داخلي يذكر الـ URL القديم. يجب أن تشير الخرائط، التنقل، التعليقات التوضيحية hreflang، العلامات canonical، والروابط داخل المحتوى جميعها مباشرةً إلى الوجهة، بحيث توجد إعادة التوجيه فقط للروابط الخارجية الواردة والعلامات القديمة. هذه الخطوة هي ما يحول إصلاح التكوين إلى مكسب كفاءة الزحف.

4. احتفظ بخريطة السلسلة. سجل كل قاعدة منتهية، مدخلة URL، ووجهتها النهائية في ملف واحد يعيش مع تكوين البنية التحتية. تُعاد تشكيل السلاسل لأن الشخص التالي الذي يضيف بادئة locale أو يهاجر مخطط المسار لا يملك وسيلة لرؤية 4 القواعد الموجودة بالفعل في مسار الطلب. الخريطة هي ما يجعل التركيب مرئيًا لأي شخص يرسل طبقة 5، وهي المدخل للجرد التالي. العلاج الكامل خطوة بخطوة موجود في دليلنا إعادة التوجيه و URL دليل التطبيع.

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