الهندسة البرمجية
إعادة التوجيه: 301 مقابل 302، وسلاسل التحويل، ونقل المواقع دون فقدان الترتيب
متى تستخدم كل رمز حالة، ولماذا تكلف سلاسل التوجيه سرعة الموقع، والخطأ الشائع في نقل المواقع الذي يدمر الزيارات المجانية.
تبدو عمليات إعادة التوجيه بسيطة للغاية حتى يحين موعد نقل الموقع أو ترقيته، وعندها تصبح العامل الأكبر والحاسم فيما إذا كنت ستحتفظ بحركة الزيارات المجانية لموقعك أم ستبدأ من نقطة الصفر.
القواعد الفنية واضحة وموجزة. أما الأخطاء فمكلفة للغاية، ومعظمها يمكن تجنبه بسهولة.
رموز الحالة (Status Codes)
301 — تم النقل نهائياً (Moved Permanently). تنقل محركات البحث إشارات الترتيب إلى الوجهة الجديدة، وتستبدل في النهاية الرابط القديم في فهرستها. تخزنه المتصفحات في الذاكرة المؤقتة بشدة وبشكل دائم في كثير من الأحيان، ولهذا السبب فإن نشر توجيه 301 خاطئ هو أمر مؤلم حقاً للتراجع عنه — إذ يستمر الزوار العائدون في اتباع الرابط من ذاكرة المتصفح المؤقتة حتى بعد إصلاح المشكلة على الخادم بوقت طويل.
308 — توجيه دائم (Permanent Redirect). مطابق لرمز 301 تماماً باستثناء أنه يحافظ على طريقة طلب HTTP الأصلية. فطلب POST يظل POST بدلاً من التحول تلقائياً إلى GET. استخدمه مع نقاط نهاية واجهات البرمجية (API endpoints)؛ أما بالنسبة لصفحات الويب العادية، فإن رمز 301 ممتاز وتدعمه وتفهمه كافة الأدوات بصورة أفضل.
302 — وُجد / مؤقت (Found - Temporary). تظل إشارات وقوة الترتيب مع الرابط الأصلي ولا تُفهرس الوجهة الجديدة بدلاً منه. هذا هو الخيار الصحيح لاختبارات A/B، وصفحات الصيانة المؤقتة، وتوجيه اللغات وفق ترويسة Accept-Language — أي حالة تعتمد فيها الوجهة فعلياً على تفضيلات الطلب وليس كبديل دائم للصفحة.
307 — توجيه مؤقت (Temporary Redirect). وهو النسخة التي تحافظ على طريقة الطلب (HTTP method) لرمز 302.
الخطأ المكلف هو استخدام 302 لعملية نقل دائمة. ستكتشف Google الأمر في النهاية وتتعامل معه كرمز 301، لكن كلمة "في النهاية" قد تعني أشهراً طويلة يظل فيها الرابط القديم متمسكاً بالترتيب بينما تظل صفحتك الجديدة غير مفهرسة.
سلاسل التوجيه (Redirect Chains)
السلسلة هي عملية توجيه تقود إلى توجيه آخر. وتتراكم هذه التوجيهات بهدوء ودون انتباه:
http://example.com/old-page
→ 301 → https://example.com/old-page
→ 301 → https://www.example.com/old-page
→ 301 → https://www.example.com/new-page/
→ 200أربعة طلبات كاملة قبل أن يرى المتصفح بايت واحد من المحتوى. وكان كل من هذه التوجيهات في الغالب قاعدة منطقية أضافها مطور مختلف في وقت مختلف: فرض بروتوكول HTTPS، وتوحيد النطاق مع www، ونقل المسار.
ما هي التكلفة الحقيقية لذلك؟
ليست خسارة في قوة الروابط (Link Equity). فقد أكدت Google منذ عام 2016 أن توجيهات 301 تنقل كامل قيمة PageRank، وبالتالي فإن قاعدة "فقدان 15% لكل قفزة" القديمة لم تعد صحيحة، رغم استمرار تداولها بكثرة.
التكلفة الحقيقية هي السرعة. على اتصالات الجوال، تمثل كل قفزة رحلة اتصال كاملة ذهاباً وإياباً عبر الشبكة — ورغم حل اسم النطاق DNS مسبقاً، إلا أن مصافحة TCP وTLS قد لا تكون كذلك، وقد تضيف كل قفزة إعادة توجيه ما بين 200 إلى 400 مللي ثانية قبل بدء عرض الصفحة. وهذا يؤثر مباشرة على مؤشر Largest Contentful Paint، وهو عامل ترتيب مؤكد، والأهم من ذلك، محرك مباشر لارتفاع معدل الارتداد.
تتتبع Google حتى حوالي عشر قفزات قبل أن تتوقف. ولكن قبل الوصول إلى ذلك بكثير، سيكون زوار موقعك قد غادروه بالفعل.
الحل هو تسطيح المسار (Flattening): وجّه الرابط الأصلي مباشرة إلى الوجهة النهائية بدلاً من تركه يمر عبر القواعد التالية بالتسلسل. عملياً، يعني هذا أن تُكتب قواعد التوجيه للرابط الأصلي مباشرة، وألا تُبنى متسلسلة فوق بعضها.
حيلة ترويسة HSTS
إذا قمت بإعادة توجيه http:// إلى https://، فإن كل زائر لأول مرة يدفع ضريبة وقت تلك القفزة.
إضافة ترويسة HSTS تلغي هذا التأخير تماماً لكل زائر سبق له زيارة الموقع:
Strict-Transport-Security: max-age=31536000; includeSubDomainsيذهب المتصفح الآن مباشرة إلى HTTPS في كل زيارة لاحقة دون الحاجة لطلب التحقق. وهذا يلغي رحلة اتصال شبكية كاملة من كل عملية تحميل للصفحة للزوار العائدين — ترويسة واحدة فقط تحقق مكسباً ملموساً في السرعة.
حلقات التوجيه المفرغة (Redirect Loops)
تتسبب حلقة التوجيه في جعل الرابط غير قابل للوصول على الإطلاق. والأسباب المعتادة هي:
- تعارض قاعدة الشرطة المائلة في نهاية الرابط (trailing slash) مع قاعدة العنوان الأساسي (canonical)
- توجيه HTTPS على مستوى خادم التطبيق يتعارض مع توجيه آخر على مستوى شبكة توزيع المحتوى (CDN)
- توجيه لغات يعيد توجيه صفحة اللغة إلى الصفحة التي أرسلتك إليها للتو
تظل الحلقات المفرغة غير مرئية حتى يطلب مستخدم الرابط المحدد الذي يثيرها، والذي غالباً ما يكون رابطاً يظهر فقط في نتائج البحث أو في روابط خارجية قديمة. افحص الروابط المحددة ولا تكتفِ باختبار الصفحة الرئيسية فقط.
يمكنك فحص أي رابط وتتبعه قفزة بخطوة مع أداة فحص إعادة التوجيه المجانية لدينا — فهي تتبع كل قفزة بشكل مستقل بدلاً من تلخيصها، لترى السلسلة كاملة والتكلفة الزمنية لكل محطة.
خطأ نقل المواقع الذي يدمر الترتيب
يحتاج كل رابط قديم كان يستقبل زيارات أو يحتوي على روابط واردة إلى توجيه 301 مباشر إلى أقرب صفحة مكافئة له.
وليس إلى الصفحة الرئيسية.
تتعامل Google مع التوجيه الجماعي للروابط غير المرتبطة إلى الصفحة الرئيسية باعتباره خطأ 404 ناعم (soft 404) ولا تنقل أي قيمة تذكر للصفحات المنقولة. هذه هي الطريقة الأكثر شيوعاً التي يدمر بها نقل المواقع حركة البحث المجاني، ويحدث هذا غالباً لأن بناء خريطة روابط دقيقة عمل شاق، بينما توجيه كل شيء إلى / يتطلب سطراً واحداً فقط.
لكن الطريقة الشاقة هي الطريقة الوحيدة الناجحة:
- افحص الموقع القديم بالكامل بواسطة الزحف قبل تغيير أي شيء. استخدم Screaming Frog أو Sitebulb أو خريطة موقعك الحالية.
- استخرج الروابط المهمة — أي صفحة حققت زيارات بحث مجانية في Analytics، أو تملك روابط واردة في Search Console أو Ahrefs.
- اربط كل رابط بأقرب صفحة مكافئة له في الموقع الجديد. وتجنب التوجيه لصفحة التصنيف العامة إذا كانت هناك صفحة محددة مكافئة للمحتوى.
- الروابط التي لا يوجد بديل لها يجب أن ترجع رمز 410 Gone، وليس توجيه 301 إلى محتوى لا يمت لها بصلة. يخبر رمز 410 محركات البحث بحذف الصفحة بنظافة؛ أما توجيه 301 غير الدقيق فيخبرها بوجود صفحة تتحدث عن موضوع لا تغطيه في الواقع.
- انشر قواعد التوجيه مع إطلاق الموقع الجديد، وليس في وقت لاحق.
- راقب أدوات مشرفي المواقع Google Search Console لمدة أربعة إلى ستة أسابيع. ستكشف لك أخطاء الزحف وتقارير تغطية الفهرس ما قد تكون غفلت عنه.
الخطوة الرابعة قد تبدو غير بديهية وتستحق التأكيد: إخبار محرك البحث بأن الصفحة قد حُذفت تماماً أفضل بكثير من توجيهه إلى صفحة غير ذات صلة.
الشرطة المائلة الأخيرة (Trailing Slashes)
يعد الرابط /page ورابط /page/ عنوانين مختلفين تقنياً. اختر نمطاً موحداً منهما، واجعل النمط الآخر يُعاد توجيهه إليه، وتأكد من أن جميع الروابط الداخلية داخل موقعك تستخدم الصيغة المعتمدة القياسية.
تكلفة الخطأ هنا ليست مشكلة محتوى مكرر عادة — إذ تتولى وسوم canonical معالجة ذلك — بل هي قفزة إعادة توجيه إضافية عند كل تنقل داخلي، لأن روابطك تشير للصيغة غير المعتمدة ويدفع الزائر ثمن قفزة توجيه مع كل نقرة.
إعادة التوجيه مقابل الوسم الأساسي (Redirect vs Canonical)
استخدم إعادة التوجيه (Redirect) عندما تكون الصفحة قد نُقلت فعلياً ويجب أن ينتهي المستخدمون في مكان آخر.
استخدم الوسم الأساسي (Canonical) عندما يجب أن يظل كلا الرابطين متاحين للوصول ولكنك ترغب في فهرسة نسخة واحدة فقط — مثل منتج يمكن الوصول إليه عبر تصنيفين، أو نسخة مخصصة للطباعة، أو رابط يحتوي على وسوم تتبع.
إعادة التوجيه في الحالات التي تتطلب وسماً أساسياً يعطل وظائف الموقع المشروعة. ووضع الوسم الأساسي عندما ينبغي عمل إعادة توجيه يترك صفحات مكررة متاحة للزيارة ويفسح المجال لمحركات البحث للاختلاف معك في التقييم.
أين يجب تنفيذ قواعد التوجيه؟
على مستوى الخادم (Server level) — عبر ملف .htaccess في Apache وLiteSpeed، أو كتلة الخادم (server block) في Nginx. هذا هو الخيار الأسرع، لأنه يُنفذ قبل بدء تشغيل تطبيق الويب.
على مستوى التطبيق (Application level) — عبر قواعد توجيه المسارات أو إضافات إدارة المحتوى. وهو أبطأ لأن التطبيق يقلع أولاً، لكنه أسهل في الإدارة عندما تعتمد قواعد التوجيه على بيانات من قاعدة البيانات.
إياك والتنفيذ من جانب العميل (Client-side). إن إعادة التوجيه عبر JavaScript أو وسم meta-refresh بطيئة، وتتعامل معها عناكب الزحف بتباين، ولا تنقل إشارات الترتيب بصورة موثوقة. إنها الأداة الخاطئة لأي نقل دائم.
قائمة تحقق سريعة
- استخدم رمز 301 للنقل الدائم، وليس 302
- احرص ألا تتجاوز أي سلسلة توجيه قفزة واحدة
- قم بضبط ترويسة HSTS ليتجاوز الزوار العائدون قفزة HTTPS
- اربط كل رابط قديم له زيارات أو روابط ببديل مكافئ محدد
- دع الصفحات المحذوفة نهائياً ترجع رمز 410، وتجنب توجيهها للصفحة الرئيسية
- وجّه الروابط الداخلية للرابط النهائي مباشرة، وليس لرابط تحويل
- اختبر الروابط المحددة بدقة، ولا تكتفِ باختبار الصفحة الرئيسية فقط
والنقطة الأخيرة هي المكان الذي تختبئ فيه معظم المشاكل والمفاجآت غير السارة.
