الملخّص في خمس ثوانٍ

  • 301 (Moved Permanently): استخدمه للنقل الدائم. ينقل إشارة SEO إلى URL الجديد. الافتراضي لـHTTP→HTTPS، www→non-www، وهجرات النطاقات.
  • 302 (Found / Moved Temporarily): استخدمه لإعادات التوجيه المؤقّتة فعلاً. لا ينقل إشارة SEO بنفس الطريقة. الافتراضي لاختبارات A/B، إعادات التوجيه الجغرافية، تدفّقات تسجيل الدخول.
  • 307 (Temporary Redirect، صارم): مثل 302 لكن يُحافظ على طريقة HTTP. مكافئ حديث.
  • 308 (Permanent Redirect، صارم): مثل 301 لكن يُحافظ على طريقة HTTP. مكافئ حديث.

لمعظم حالات المحتوى الثابت، 301 ما تريده. لإرسال النماذج وAPIs، 308 صحيح تقنياً. التمييز يُهمّ أكثر لـAPIs من SEO؛ محرّكات البحث تعامل 308 كـ301.

لماذا HTTP→HTTPS الحالة الأكثر شيوعاً

أعددت SSL على نطاقك. الآن لديك نسختان من كلّ URL: http://example.com/page وhttps://example.com/page. دون إعادة توجيه، محرّكات البحث قد تُفهرس كليهما، صفحاتك تحصل على إشارة منقسمة، والمستخدمون على روابط HTTP المباشرة يرون تحذير "غير آمن".

الإصلاح إعادة توجيه 301 من كلّ URL HTTP إلى HTTPS المكافئ. اضبطها على خادم الويب، CDN، أو طبقة التطبيق — أيّ منها يعمل.

التنويعات الأربعة التي يجب التعامل معها

لمعظم النطاقات هناك أربعة تنويعات URL تحتاج التقاء على شكل واحد قانوني:

  1. http://example.com/page
  2. http://www.example.com/page
  3. https://example.com/page
  4. https://www.example.com/page

اختر canonical واحداً (الأكثر شيوعاً https://example.com أو https://www.example.com — كلاهما اختيارات صالحة). أعد توجيه الثلاثة الأخرى إليه عبر 301.

مهمّ: إعادة التوجيه يجب أن تذهب مباشرة إلى canonical، لا عبر قفزات وسيطة. تجنّب سلسلة "HTTP non-www → HTTP www → HTTPS www → HTTPS non-www" — كلّ قفزة تفقد إشارة وتُضيف كموناً.

تشريح سلسلة إعادة توجيه صحيحة

لـcanonical من https://example.com:

  • http://example.com/page → 301 → https://example.com/page
  • http://www.example.com/page → 301 → https://example.com/page
  • https://www.example.com/page → 301 → https://example.com/page

قفزة واحدة، دائماً. تحقّق بـcurl -I -L أو أداة فحص إعادة توجيه — إن رأيت 301s متتاليتَين أو أكثر، أصلح السلسلة.

أخطاء 301 التي تقتل SEO

1. استخدام 302 افتراضياً

كثير من أُطر الويب تجعل 302 افتراضياً لإعادات التوجيه. في Express.js، Django، Rails، عليك طلب 301 صراحة. كثير من المطوّرين لا يفعلون. النتيجة: سنوات من إعادات التوجيه "المؤقّتة" التي تُعاملها Google بنقل إشارة مُقلَّص.

اضبط الحالة صراحة دائماً. في Express: res.redirect(301, '/new'). في Django: HttpResponsePermanentRedirect(). في Rails: redirect_to '/new', status: :moved_permanently.

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

"http://yoursite.com/old → https://www.yoursite.com/old → https://yoursite.com/old → https://yoursite.com/new" سلسلة من أربع قفزات. كلّ قفزة:

  • تُضيف كمون 50–200ms.
  • تُقلّل نقل الإشارة الذي يُجريه Google.
  • تزيد فرصة كسر قفزة وفشل السلسلة كلّها.

اطوِها إلى قفزة واحدة. دائماً.

3. إعادة توجيه كلّ شيء إلى الصفحة الرئيسية

"أعدنا هيكلة الموقع، لذا أعدنا توجيه كلّ URLs القديمة إلى الصفحة الرئيسية". هذا أسوأ نمط شائع. تفقد كلّ إشارة على مستوى الصفحة. Google يعاملها كأنّ المحتوى القديم اختفى.

عيّن كلّ URL مُزال إلى أقرب مكافئ على البنية الجديدة. إن لم يوجد مكافئ فعلاً، أعِد 410 Gone (Google يُلغي فهرستها أنظف من 404 أو 301-إلى-الصفحة-الرئيسية مُضلِّل).

4. عدم إعادة توجيه تنويعات الشرطة المائلة

example.com/page وexample.com/page/ هما URLs مختلفان. إن سمح CMS بكليهما، محرّكات البحث قد تُفهرس كليهما وتُقسّم الإشارة. اختر واحداً (مع أو بدون شرطة مائلة) وأعد توجيه الآخر بـ301.

5. إزالة إعادات التوجيه القديمة بسرعة

أجريت الهجرة قبل سنتَين. لماذا تُبقي إعادات التوجيه؟ لأنّ مواقع خارجية ما زالت تربط بـURLs قديمة، وتلك الروابط ما زالت تُنقَر. تكلفة قاعدة إعادة التوجيه صفر. إزالتها تفقدك زيارات البقايا إلى الأبد.

6. الحلقات

إن كانت قاعدة "فرض HTTPS" تطابق HTTP وHTTPS بشكل خاطئ، تحصل على حلقة إعادة توجيه لانهائية. المتصفّحات تكتشف هذا وتُظهر ERR_TOO_MANY_REDIRECTS. أسباب شائعة: رؤوس load balancer مُهيَّأة خطأً (X-Forwarded-Proto مفقود)، HSTS مع CDN يسيء التصرّف.

اختبر إعادات توجيهك بـcurl -L -I --max-redirects 5 كجزء من أيّ تغيير. إن أُطلق max-redirects، لديك حلقة.

حالات استخدام 302 / 307

إعادات التوجيه المؤقّتة الحقيقية موجودة:

  • صفحات الصيانة. أثناء توقّف الموقع، أعد التوجيه إلى صفحة حالة. حين تنتهي الصيانة، تراجع. 302 هنا صحيحة.
  • اختبار A/B. إعادة توجيه نصف المستخدمين إلى variant B أثناء اختبار. يجب أن تكون 302؛ إعادة التوجيه ليست دائمة فعلاً.
  • التوجيه الجغرافي. إرسال المستخدمين في أوروبا إلى /eu/ أثناء إطلاق منطقة. 302، لأنّ canonical URL الذي كتبه المستخدم ما زال ذا معنى.
  • تدفّقات تسجيل الدخول / المصادقة. إعادة المستخدم إلى الصفحة التي حاول الوصول إليها بعد المصادقة. 302/307 تقليدية.

الاختبار: إن كانت إعادة التوجيه مقصودة للأبد، استخدم 301. إن كانت التفافة لحظية، استخدم 302.

HSTS: الطبقة فوق إعادات التوجيه

حتّى مع 301 مثالية من HTTP إلى HTTPS، طلب المستخدم الأوّل ما زال يذهب عبر HTTP ويمكن اعتراضه. HSTS (HTTP Strict Transport Security) يُصلح هذا:

  • تُعيد رأس Strict-Transport-Security: max-age=31536000; includeSubDomains.
  • متصفّح المستخدم يتذكّر هذا لسنة.
  • الطلبات المستقبلية، حتّى المكتوبة كـHTTP، تذهب مباشرة إلى HTTPS — دون محاولة HTTP أبداً.

مع HSTS preload (حيث المتصفّحات تشحن قائمة مُدمجة بنطاقات HSTS-فقط)، هذا يُلغي إعادة التوجيه HTTP→HTTPS للزوّار المتكرّرين تماماً.

تحذير: HSTS صعب التراجع داخل max-age الخاصّ به. اختبر بدقّة. ابدأ بـmax-age قصير (300 ثانية) وارفع فقط حين تثق.

عملية التحقّق

لأي تغيير إعادة توجيه:

  1. اختبر بـcurl: curl -I -L -A "Googlebot" http://example.com/somepage. أكّد رموز الحالة، URLs الوسيطة، والوجهة النهائية.
  2. اختبر كما يرى محرّك البحث. استخدم URL Inspection في Google Search Console على URL القديم — يُظهر ما يراه Google.
  3. اختبر السلاسل. إن رأيت أكثر من 301/302 في مخرجات curl، أصلح.
  4. اختبر الحالات الحدّية. URLs بشرطات مائلة، بسلاسل استعلام، بشظايا. كلّ يجب أن يُعاد توجيهه نظيفاً.

القواعد في جملة واحدة

استخدم 301 للنقل الدائم، 302 للتفافات المؤقّتة، إعادات توجيه قفزة واحدة دائماً، احتفظ بها للأبد، تحقّق بـcurl بعد كلّ تغيير. شبه كلّ قصّة "فقدنا تصنيفات بعد الهجرة" تعود لانتهاك إحدى تلك القواعد.