ماذا يحدث فعليًا عند التحويل
عندما يطلب المتصفح رابطًا ويجيب الخادم بحالة 3xx وترويسة Location، يُصدر المتصفح بصمت طلبًا ثانيًا إلى ذلك العنوان الجديد. لا يرى الزائر سوى الوجهة؛ أما الكلفة — رحلة ذهاب وإياب إضافية — والدلالة فتركبان على رمز الحالة.
يقول 301 إن المورد انتقل نهائيًا: على العملاء الذهاب إلى الرابط الجديد الآن وتذكّر تخطي القديم في المرة القادمة. ويقول 302 إنه في مكان آخر مؤقتًا: اذهب إليه الآن، لكن اسأل الأصلي مجددًا في المستقبل. كل ما يهم في التحويلات — SEO والتخزين المؤقت وقابلية التراجع — ينبع من أي الوعدين قطعت.
ماذا تفعل محركات البحث بكل منهما
مع 301 تتعامل محركات البحث مع الانتقال كحقيقة تحريرية: إشارات الرابط القديم المتراكمة — الروابط والتاريخ والترتيب — تُنقل إلى الجديد، وخلال الأسابيع التالية يحل الرابط الجديد محل القديم في النتائج. لهذا تُنفَّذ ترحيلات المواقع والانتقال إلى HTTPS وإعادة تسمية الروابط بتحويلات 301: السمعة تتبع المحتوى.
ومع 302 تفعل المحركات الشيء الحرفي: تُبقي الرابط القديم في الفهرس، لأنك أخبرتها أن المحتوى عائد. تحويل 302 المتروك في مكانه لانتقال دائم هو أحد أخطاء SEO الصامتة الكلاسيكية — كل شيء يعمل للزوار، لكن الرابط الجديد لا يبني أي تاريخ بينما يذبل القديم ببطء. إن اكتشفت واحدًا، فمجرد تغييره إلى 301 يبدأ النقل؛ والمحركات تتعامل مع التصحيح بسلاسة.
والخطأ المعاكس موجود أيضًا: تحويل 301 مستخدم لشيء مؤقت فعلًا (صفحة حملة أو اختبار A/B) يخبر المحركات بإزالة الأصل من الفهرس — وهو بالضبط ما لم ترده.
الجزء الذي يتعلمه الناس بالطريقة الصعبة: تحويلات 301 تلتصق
يُسمح للمتصفحات بتخزين تحويل 301 دون انتهاء صلاحية — وعدة متصفحات تفعل ذلك بالضبط. في أول مرة يرى فيها متصفح الزائر التحويل قد يتذكره إلى أجل غير مسمّى، ولا يسأل الرابط القديم مجددًا أبدًا. أصلح الخادم غدًا وسيظل ذلك الزائر يهبط على الصفحة الخاطئة، لأن التحويل يعيش الآن في متصفحه، خارج متناولك. لا يوجد زر تفريغ لمتصفحات الآخرين.
نتيجتان عمليتان. أولًا، اختبر الانتقال بـ 302، ولا ترقّه إلى 301 إلا عندما تكون متأكدًا — الرمز المؤقت هو القابل للتراجع. ثانيًا، ضع Cache-Control صريحة على التحويلات، لأن عمرًا محدودًا يحوّل "عالق للأبد" إلى "عالق يومًا على الأكثر". نحن نتبع هذه القاعدة على هذا الموقع: تحويلاتنا القانونية تحمل Cache-Control: public, max-age=86400، فحتى التحويل الذي نغيّره لاحقًا يصحّح نفسه خلال يوم لدى كل زائر وكل كاش بينهما.
تحويل بعمر محدود قابل للتخزين المؤقت
$ curl -sI https://cdn.com.tr/en/features/almacenamiento-objetos-s3 | grep -iE 'http|location|cache-control'
HTTP/2 301
location: https://cdn.com.tr/en/features/object-storage
cache-control: max-age=86400, public
سلاسل التحويل: الضريبة التي تدفعها عند كل نقرة
التحويلات تتراكم. قاعدة http→https تضيف قفزة، وقاعدة www أخرى، والرابط المُعاد تسميته ثالثة — وصار كل زائر يدفع ثلاث رحلات ذهاب وإياب قبل أن يتحرك أي محتوى، بينما تُضعف محركات البحث قليلًا من الإشارة عند كل خطوة وسيطة وتتوقف عن تتبع السلاسل الطويلة جدًا كليًا.
الحل ليس تجنب التحويلات؛ بل جعل كل رابط قديم يشير مباشرة إلى الوجهة النهائية. عندما تعيد تسمية صفحة كان يشير إليها تحويل أصلًا، حدّث القاعدة القديمة أيضًا، ليذهب جيلا الروابط كلاهما مباشرة إلى العنوان الجديد في قفزة واحدة. التدقيق الدوري أمر واحد لكل رابط، والشكل الذي تريد رؤيته هو 301 واحد يتبعه 200.
اتبع السلسلة كاملة وعُدّ القفزات
# -L follows redirects; print each hop's code and target
curl -sIL -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com/old-page
# see every hop explicitly (one line per response)
curl -sIL http://example.com/old-page | grep -iE '^HTTP|^location'
# healthy: HTTP/1.1 301 -> HTTP/2 200. unhealthy: 301 -> 301 -> 302 -> 200
التحويلات على CDN: أين يجب أن تعيش، وتخزينها مؤقتًا
التحويل الذي يقدّمه تطبيقك يعمل، لكنه يكلّف رحلة كاملة إلى الأصل لإنتاج ترويسة واحدة لا تتغير. نقل التحويلات المعروفة إلى الحافة — أو ترك الحافة تخزّن ما يصدره تطبيقك — يجيب عنها قرب الزائر بدلًا من ذلك.
النصفان متاحان هنا. تستطيع قواعد التوصيل التحويل عند الحافة مباشرة (تحويل موقع الهاتف إعداد بحقل واحد في اللوحة)، ومنذ تحسين حديث صارت الحافة تخزّن أيضًا تحويلات 301 و302 من أصلك بأعمار محدودة، فتتوقف عمليات الزحف المتكررة لرابط منقول عن الوصول إلى تطبيقك كليًا. الإرشاد العملي: أعطِ تحويلاتك Cache-Control صريحة كأي استجابة أخرى، قصيرة لتحويلات 302، وحتى يوم لتحويلات 301 — طويلة بما يكفي لامتصاص الحركة، وقصيرة بما يكفي للنجاة من أخطائك أنت.
الاختيار في خمس ثوانٍ
أعدت تسمية صفحة، أو نقلت نطاقات، أو انتقلت إلى HTTPS، أو وحّدت التكرارات: 301، مع تحديث السلاسل القديمة لتشير مباشرة إلى الرابط النهائي. صفحة حملة، أو تحويلة صيانة، أو اختبار A/B، أو تقسيم جغرافي، أو أي شيء تنوي التراجع عنه: 302. لست متأكدًا بعد: 302 أولًا — فهو القابل للتراجع — ثم رقّه إلى 301 حين يستقر الانتقال.
والقاعدة الجامعة التي تلتقط الباقي: التحويل وعد بمستقبل رابط. اختر الرمز المطابق للوعد الذي تستطيع فعلًا الوفاء به.
أسئلة شائعة
هل تفقد تحويلات 301 إشارة الترتيب؟
أعلنت Google منذ سنوات أن تحويلات 301 تمرّر الإشارة كاملة — ومخاوف "فقدان PageRank" التاريخية عفا عليها الزمن. ما يسرّب الإشارة فعلًا هو السلاسل الطويلة وتعاقب 301/302 المختلط، ولهذا فإن توجيه الروابط القديمة مباشرة إلى الوجهة النهائية أهم من مسألة القفزة الواحدة.
متى تحترم محركات البحث تحويل 301 الخاص بي؟
يعمل التحويل للزوار فورًا. أما تحديث الفهرس — حلول الرابط الجديد محل القديم في النتائج — فيستغرق أيامًا إلى أسابيع بحسب وتيرة الزحف. أبقِ التحويل في مكانه دائمًا؛ فالمحركات تعيد التحقق منه دوريًا، وإزالته مبكرًا تُيتّم كل رابط لا يزال يشير إلى العنوان القديم.
تحويل 301 خاطئ مخزّن في متصفحات الزوار. ماذا الآن؟
أصلح قاعدة الخادم، وقدّم استجابة الرابط القديم الجديدة مع Cache-Control تنتهي سريعًا. المتصفحات التي تعود ستصحّح نفسها عند أول طلب غير مخزّن؛ والتي خزّنته دون انتهاء تصحّح عند أول إخلاء لكاشها. وهذا بالضبط سبب وجوب حمل التحويلات لـ Cache-Control محدودة من اليوم الأول.
هل يعيش التحويل في تطبيقي أم عند الحافة؟
التحويلات البنيوية الدائمة (www وhttps والأقسام المُعاد تسميتها) مكانها الحافة حيث لا تكلّف شيئًا عند كل زيارة. تحويلات مستوى التطبيق مناسبة للمنطق الذي يحتاج حالة التطبيق — ومع تخزين الحافة لاستجابات 301/302، تتوقف حتى هذه عن قصف أصلك عند الزيارات المتكررة.