قاموس السيو

ما المقصود بـسلسلة التحويلات (Redirect Chain)؟

سلسلة التحويلات هي تتابع تحويلين أو أكثر بين الرابط المطلوب والصفحة النهائية التي تُرجع المحتوى فعلا.

افحصه مجانًا: فحص التحويلات 301

سلسلة التحويلات (Redirect Chain): سلسلة التحويلات هي تتابع تحويلين أو أكثر بين الرابط المطلوب والصفحة النهائية التي تُرجع المحتوى فعلا.

تتكوّن سلسلة التحويلات (Redirect Chain) حين لا يشير الرابط إلى وجهته النهائية مباشرة، بل يمرّ أولا بعنوان واحد أو أكثر من العناوين الوسيطة. يُحوَّل الطلب من الصفحة A إلى B، ثم من B إلى C، ولا ترد بالرمز 200 OK إلا الصفحة C. وكل خطوة من هذه الخطوات «قفزة» (hop): طلب HTTP واستجابة مستقلان يجب أن يُتمّهما المتصفح أو الزاحف قبل أن يرى أي محتوى.

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

لماذا تكلّفك السلاسل؟

  • التأخير. كل قفزة رحلة ذهاب وإياب إضافية، ومصافحة TLS جديدة كلما تغيّر المضيف. وعلى اتصال جوال بطيء قد تؤخر ثلاث قفزات وصول أول بايت من الصفحة الحقيقية تأخيرا ملحوظا.
  • الزحف. توضّح جوجل أن Googlebot يتبع حتى 10 قفزات تحويل؛ وبعد ذلك يُبلغ Search Console عن خطأ تحويل ولا يُجلب المحتوى (Google Search Central: أخطاء HTTP والشبكة). وقبل بلوغ هذا الحد تكون كل قفزة زائدة طلبا مهدرا، وهذه تكلفة حقيقية في المواقع الكبيرة التي تعاني قيدا صارما على ميزانية الزحف (Crawl Budget).
  • إشارات متضاربة. التحويل الدائم إشارة قوية على الرابط الأساسي (canonical). أما السلسلة التي تخلط بين 301 و302 وتحويل meta refresh فتُضبّب على جوجل أي رابط تريد فهرسته.
  • الزواحف الأخرى. ليست كل الزواحف بمثابرة Googlebot. فقد تتوقف زواحف البحث بالذكاء الاصطناعي وجالبات معاينة الروابط بعد قفزات أقل، ولذلك يبقى المسار القصير هو الخيار الآمن إن أردت أن يُقرأ نصّك ويُقتبس منه.

مثال: سلسلة من ثلاث قفزات

$ curl -sIL http://example.com/shoes/ | grep -iE "^(HTTP|location)"
HTTP/1.1 301 Moved Permanently
Location: https://example.com/shoes/
HTTP/2 301
location: https://www.example.com/shoes/
HTTP/2 301
location: https://www.example.com/running-shoes/
HTTP/2 200

تعمل هنا ثلاث قواعد منفصلة بالتتابع: فرض HTTPS، ثم إضافة www، ثم نقل القسم القديم إلى الجديد. والحل أن تعالج البروتوكول والمضيف في قاعدة واحدة، وأن توجّه المسار القديم مباشرة إلى رابطه النهائي. في ملف .htaccess على Apache:

RewriteEngine On
# المسار القديم مباشرة إلى وجهته النهائية (قفزة واحدة)
RewriteRule ^shoes/$ https://www.example.com/running-shoes/ [R=301,L]
# البروتوكول والمضيف معا (قفزة واحدة)
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

الترتيب مهم: ضع قواعد المسارات المحددة أولا حتى لا تنتظر القاعدة العامة للمضيف لتعمل.

أخطاء شائعة

  • إصلاح التحويل مع ترك الروابط الداخلية ووسوم canonical وخريطة الموقع XML على الرابط القديم، فتبدأ كل نقرة داخلية سلسلة جديدة.
  • إضافة تحويل جديد فوق القديم بعد كل ترحيل بدل تحديث وجهة القاعدة القديمة.
  • وضع تحويل مؤقت من نوع تحويل 302 في وسط سلسلة من قفزات تحويل 301.
  • إنشاء حلقات (A ← B ← A) لا تنتهي أبدا وتعرض للمستخدم صفحة خطأ.

كيف تكتشف السلاسل وتصلحها

الصق الرابط في أداة فحص التحويلات 301 لتتبّع كل قفزة مع رمز حالتها وترويسة Location وزمنها. تُظهر الأداة الحلقات والسلاسل الطويلة، وتبيّن هل تتجمّع نسخ http/https وwww/بدون www في خطوة واحدة. اختبر النسخ الأربع للصفحة الرئيسية، ثم الروابط القديمة من عمليات الترحيل السابقة. الهدف: قفزة واحدة على الأكثر من أي رابط قديم، وصفر قفزات من روابطك الداخلية.

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

كم تحويلا متتاليا يُعدّ كثيرا؟

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

هل تفقد سلاسل التحويل قيمة PageRank؟

صرّحت جوجل بأن تحويلات 3xx لا تفقد PageRank. التكلفة الحقيقية للسلاسل هي بطء الصفحات وهدر طلبات الزحف، وارتفاع احتمال أن يتوقف بعض الزواحف قبل الوصول إلى الرابط النهائي.

هل التحويل من http إلى https سلسلة؟

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