302 مقابل 307: إعادة التوجيه المؤقتة وحفظ الطريقة

الخلاصة — إعادة التوجيه 302 و307 كلتاهما «مؤقتة» — ترسلان الزوار إلى مكان آخر الآن مع إبقاء العنوان الأصلي هو العنوان المحتسب. وتعالج Google الرمزين بالطريقة نفسها، فلا فرق SEO ذا معنى. الفرق الحقيقي تقني: يجب على 307 أن تبقي طلبك من النوع نفسه (فيظل إرسال النموذج إرسال نموذج بدل أن يتحول إلى جلب صفحة عادية)، بينما كانت 302 تسمح تاريخيًا بتبديل ذلك. استخدم 302 العادية لإعادة التوجيه المعتادة، و307 عندما تعيد توجيه شيء يرسل بيانات، مثل نموذج أو API — ولا تفترض أن «تعيين 307 افتراضيًا في كل مكان» مجاني تلقائيًا.

ماذا تعني 302 و307 فعلًا

كل من 302 و307 إعادة توجيه: تطلب عنوان URL وتهبط في عنوان آخر. والرقم هو رمز حالة HTTP الذي يعيده الخادم، ويحمل رسالة للمتصفحات ومحركات البحث.

• 302 — «Found» (مؤقتة). إعادة التوجيه المؤقتة الأصلية. تقول «اذهب إلى هنا الآن، لكن العنوان القديم ما زال الحقيقي — سأعود».
• 307 — «Temporary Redirect». الرسالة نفسها — مؤقتة، والعنوان القديم ما زال محتسبًا — لكن مع وعد إضافي: على المتصفح تكرار طلبك الدقيق، بما في ذلك كونه GET (مجرد جلب صفحة) أو POST (إرسال بيانات مثل نموذج).

إذن هما شقيقتان. ومن المفيد قولها هكذا: 307 هي 302 مع ضمان إضافي بأن المتصفح لن يستبدل إرسال نموذجك بهدوء بطلب جلب صفحة عادية.

هل يهم ذلك لتحسين محركات البحث؟

ليس بالطريقة التي يقلق منها معظم أصحاب المواقع. تسرد وثائق Google أن 307 “equivalent to 302” (ترجمة) «مكافئة لـ302» في كيفية معالجة زواحفها لإعادة التوجيه واتباعها. وكلتاهما إشارة «مؤقتة»، لذلك لا تعتبر Google الوجهة افتراضيًا صفحة canonical لمجرد أنك وجهت إليها. ولا توضح وثائق Google هل تمرر 302 و307 كميات متطابقة أو مختلفة من قيمة الروابط — لكن الواضح أن أيًا من الرمزين لا يمنح الوجهة إشارات المصدر بالطريقة التي تفعلها إعادة التوجيه الدائمة. وإذا قال لك أحد إن 307 «تمرر قيمة أقل» من 302، فاطلب مصدره؛ فلم تنشر Google مصدرًا يقول ذلك.

إذن متى أستخدم كل واحدة؟

• استخدم 302 عادية لإعادة التوجيه المؤقتة اليومية — صفحة تخفيض موسمية، أو اختبار A/B، أو صفحة صيانة، أو إرسال شخص إلى الصفحة الرئيسية لبلد معين.
• استخدم 307 عندما يرسل الشيء الذي تعيد توجيهه بيانات — إرسال نموذج، أو استدعاء API، أو POST لتسجيل الدخول أو الدفع. هنا يهم وعد 307 (الحفاظ على الطريقة والبيانات كما هما)، لأن 302 عادية قد تسمح لمتصفح قديم بتحويل POST إلى GET وإسقاط البيانات.

أمر واحد يربك الناس

قد تفتح أدوات المطور في متصفحك وترى 307 لم تضبطها قط. غالبًا ليست إعادة توجيه حقيقية من الخادم، بل ترقية متصفحك لرابط http:// إلى https:// من تلقاء نفسه (ميزة أمنية تسمى HSTS) وعرضها لك على أنها 307. الخادم لم يرسلها. للمزيد انتقل إلى تبويب Advanced.

هل تريد الصورة الكاملة — تاريخ المواصفة، وما تقوله Google وMueller بالضبط، و«307 الشبح» في HSTS، وإعدادات الأطر التي تفاجئ المطورين؟ انتقل إلى تبويب Advanced.

الخلاصة — 302 و307 كلتاهما إعادة توجيه مؤقتة، وتعالجهما Google بالطريقة نفسها — إذ تقول وثائقها إن 307 «مكافئة لـ302»، وقال Mueller «بالنسبة إلى SEO لا يهم الأمر حقًا» بين الزوجين المؤقت والدائم؛ ولا رمز منهما إشارة إلى أن الوجهة ينبغي أن تصبح canonical، ولم تنشر Google فرقًا معلنًا في PageRank أو قيمة الروابط بينهما. الفرق الحقيقي هو الحفاظ على الطريقة: يجب أن يحافظ اتباع 307 التلقائي على طريقة الطلب نفسها (فيبقى POST هو POST)، بينما تسمح 302 للعميل بتحويل POST إلى GET — أما بايتات الجسم الدقيقة وبيانات الاعتماد والسلوك عبر أصل مختلف فتظل رهينة بالعميل، فتحقق ولا تفترض. الجأ إلى 307 عندما يسبب فقدان الطريقة كسرًا — في APIs والنماذج وتدفقات POST وwebhook والدفع والمصادقة — لكن انتبه إلى إعادة الإرسال غير القابلة للتكرار (فقد يعيد طلب دفع أو طلب شراء توجيهه). 302 عادية مناسبة لإعادة توجيه GET المعتادة، ومنها توصية Google الصريحة باختبارات A/B. وانتبه إلى «307 الشبح» في HSTS (اسم في واجهة Chrome لا ضمان بروتوكولي)، وإلى تفاصيل الأطر (توثق Next.js 303 لـServer Actions و307 في مواضع أخرى — راجع إصدارك بدل التعميم على منصات أخرى)، وإلى أن Bing لا تملك إرشادًا مميزًا لـ302 مقابل 307. وترتيبي المفضل لإعادة التوجيه المؤقتة هو 307 / 302 / 303 قبل meta/HTTP refresh — لكن جعل 307 افتراضية ليس بلا تكلفة، فتحقق من رؤوس التخزين المؤقت ودعم العملاء القدامى وضوابط القابلية للتكرار أولًا. “equivalent to 302” (ترجمة) «مكافئة لـ302.» “for SEO, it doesn’t really matter” (ترجمة) «لا يهم الفرق حقًا من منظور SEO».

كلتاهما مؤقتة — هذه هي نقطة البداية

قبل أي شيء: تقع 302 و307 في الفئة نفسها. تجمع Google 302 (Found) و303 (See Other) و307 (Temporary Redirect) تحت «إعادة توجيه مؤقتة»، وسلوكها جميعًا واحد — “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (ترجمة) «يتبع Googlebot إعادة التوجيه، لكن مسار الفهرسة لا يستخدمها إشارة إلى أن هدف إعادة التوجيه ينبغي أن يكون canonical». وبعبارة بسيطة، تبقي إعادة التوجيه المؤقتة عنوان المصدر هو canonical افتراضيًا؛ ولا تمنح الوجهة إشارات المصدر كما تفعل إعادة التوجيه الدائمة (301/308).

هذه بالضبط مقارنة طبقة الدائم ولكن منزلة واحدة: 301/308 هما الزوج الدائم، و302/307 الزوج المؤقت، ومنطق «الأعلى رقمًا يحافظ على الطريقة» متطابق في الزوجين.

الفرق الحقيقي الوحيد: الحفاظ على الطريقة والجسم

إليك الفرق الذي يهم فعلًا في جملة واحدة: عندما يتبع العميل 307 تلقائيًا، تشترط مواصفة HTTP الحالية (RFC 9110) إبقاء طريقة الطلب نفسها؛ أما 302 فتترك للعميل حرية تحويل POST إلى GET. هذا ضمان على مستوى المواصفة للطريقة — وليس ضمانًا شاملًا لكل بايت من الجسم أو لبيانات الاعتماد أو للتعامل عبر أصل مختلف، فذلك يعتمد على العميل المحدد الذي ينفذ إعادة التوجيه. تحقق من هذه الأمور بطلب حقيقي بدل افتراض أن 307 تعيد كل شيء مطابقًا في كل حالة.

سبب وجود هذا الالتباس قصة في تاريخ المواصفة تستحق الرواية، لأن معظم الشروحات تذكر الحقيقة بلا سببها. ففي عصر HTTP/1.0 كان نص مواصفة 302 يقول تقنيًا إن العملاء لا ينبغي أن يغيروا طريقة الطلب عند اتباع إعادة التوجيه — لكن المتصفحات الأولى (Netscape ثم الجميع) تجاهلت ذلك وحولت الطرق غير GET بصمت، ولا سيما POST، إلى GET مع 302. وأصبح هذا السلوك غير المتسق لكنه الشامل معيارًا فعليًا. ثم صاغ HTTP/1.1 (RFC 2616، الذي أُدرج لاحقًا في RFC 7231 وRFC 9110 الحالية) الانقسام إلى رمزين صريحين لإنهاء الالتباس:

• 303 (See Other) — يجلب هدف إعادة التوجيه بـGET أو HEAD (وليس «GET دائمًا» ببساطة؛ فـRFC 9110 تسمح بأي من الطريقتين الآمنتين)، وهو السلوك المقصود لنمط «POST ثم أعد التوجيه إلى صفحة نتيجة يمكن إعادة تحميلها بأمان».
• 307 (Temporary Redirect) — تُحفظ الطريقة بصرامة عند الاتباع التلقائي، وفق المواصفة؛ ولا تجبر RFC 9110 كل عميل على اتباع إعادة التوجيه أصلًا.

تضع MDN الخلاصة العملية بوضوح: “The difference between 307 and 302 is that 307 guarantees that the client will not change the request method and body when the redirected request is made. With 302, older clients incorrectly changed the method to GET.” (ترجمة) «الفرق بين 307 و302 أن 307 تضمن ألا يغير العميل طريقة الطلب والجسم عند إرسال الطلب المعاد توجيهه. أما مع 302 فقد غيّر العملاء القدامى الطريقة خطأً إلى GET». لم تضف 307 قدرة جديدة بقدر ما أزالت غموضًا — فهي النسخة المضمونة بالمواصفة لما كان يفترض أن تفعله 302 المنفذة جيدًا. والمتصفحات الحديثة أكثر اتساقًا بكثير من فوضى عصر Netscape، لكن 307 تزيل الالتباس بالمواصفة لا بالعرف.

جنبًا إلى جنب:

ملاحظتان دقيقتان ينبغي إبقاؤهما واضحتين: سماح RFC بالتحويل مع 302 يذكر POST، لا كل طريقة — فلا تعممه إلى «302 تكسر دائمًا PUT/DELETE» من دون فحص عميلك. ولا رمز منهما قابل للتخزين افتراضيًا لمجرد حالته: لا تدرج RFC 9111 302 أو 307 ضمن رموز الحالة القابلة للتخزين الحدسي من الحالة وحدها؛ فالتخزين يعتمد على رؤوس Cache-Control/Expires الصريحة، لا على رمز إعادة التوجيه الذي اخترته.

“302 always breaks PUT/DELETE” (ترجمة) «302 تكسر دائمًا PUT/DELETE».

تتسق تعريفات Ahrefs لدي مع جزء الحفاظ على الطريقة: “A 307 redirect is the same as a 302 redirect, except it retains the HTTP method (POST, GET) of the original request when performing the redirect.” (ترجمة) «إعادة توجيه 307 هي إعادة توجيه 302 نفسها، إلا أنها تحتفظ بطريقة HTTP (POST أو GET) للطلب الأصلي عند تنفيذ إعادة التوجيه».

هل تعامل Google 302 و307 بشكل مختلف في SEO؟

لا — وGoogle صريحة على نحو غير معتاد في ذلك. هذا موضوع محسوم قليل الجدل، شأنه شأن 301 مقابل 308.

في وثائق رموز حالة HTTP لدى Google، يقول صف 302 إن زواحف Google تتبع إعادة التوجيه وتستخدمها إشارة ضعيفة إلى ضرورة معالجة الهدف، ويقول صف 307 حرفيًا: “Equivalent to 302.” (ترجمة) «مكافئة لـ302». وتذكر Google أن الرمزين مختلفان دلاليًا، وتوصي باختيار رمز الحالة المناسب حتى تستفيد منه العملاء الآخرون، مثل قارئات الكتب الإلكترونية ومحركات البحث الأخرى.

هذه إجابة معالجة الزحف. تتعامل Google معهما بالطريقة نفسها في كيفية جلب Googlebot لإعادة التوجيه واتباعها، ولا تطلب إلا اختيار الرمز الصحيح دلاليًا كي تعمل العملاء غير التابعة لـGoogle جيدًا. Evidence for this claim Google treats 307 as equivalent to 302 for Search while noting that the two status codes are semantically different. Scope: Google Search redirect handling; HTTP clients still need the appropriate status code. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search

هناك تفصيل يستحق الدقة، لأنه فجوة حقيقية في كثير من الشروحات الأخرى: تكافؤ معالجة الزحف ادعاء منفصل عن نتيجة الفهرسة. تجمع وثيقة إعادة التوجيه وGoogle Search لدى Google رموز 302 و303 و307 تحت «إعادة توجيه مؤقتة»، وتقول إن “the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (ترجمة) «مسار الفهرسة لا يستخدم إعادة التوجيه إشارة إلى أن هدفها ينبغي أن يكون canonical». هذا ضمان مفيد وحقيقي — لكنه لا يعد بأن يبقى عنوان المصدر متصدرًا، أو بأن الوجهة لن تُفهرس أبدًا عبر إشارات أخرى. تعامل مع «302 و307 تعالجان بالطريقة نفسها» و«لا واحدة منهما إشارة canonical إلى الهدف» على أنهما عبارتان منفصلتان وكلتاهما صحيحة، لا ادعاء بأن الرمزين يمرران PageRank أو قيمة روابط متطابقة، فهذا ليس ما تقوله وثائق Google في أي من الاتجاهين.

“While Google treats these status codes the same way, keep in mind that they’re semantically different. Use the status code that’s appropriate for the redirect so other clients (for example, e-readers, other search engines) may benefit from it.” (ترجمة) «توضح Google أن الرمزين متكافئان في المعالجة، لكنهما مختلفان دلاليًا؛ لذا ينبغي اختيار الرمز الملائم ليستفيد منه العملاء الآخرون.»

لاحظ إطار الكلام: السبب كله لاختيار 307 بدل 302 سؤال وظائف («هل تعمل مع APIs؟»)، لا سؤال ترتيب. ولا يوجد مصدر أولي موثوق يدعي أفضلية SEO لأي منهما.

هل تعامل Bing 302 و307 بشكل مختلف؟

بصراحة: لم تقل Bing ذلك. إرشاداتها العامة لإعادة التوجيه (منشور 2011 «إدارة عمليات إعادة التوجيه – 301 و302 وcanonical» ومنشور 2020 «ترحيل موقع الويب مع Bing») تناقش فقط انقسام 301 الدائم مقابل 302 المؤقت، ولا تذكر 307 أو 308 بالاسم. وبخلاف موضوع 301 مقابل 308 — حيث أصدر Fabrice Canel تصريحًا مباشرًا — لم أعثر على تصريح لممثل Bing يخص 302 مقابل 307.

لذلك سأقولها بوضوح بدل افتراض التكافؤ: لا يوجد تصريح من Bing يميز تحديدًا بين 302 و307. لكن هناك سلوك موثق يستحق معرفته في نقاش إعادة التوجيه المؤقتة عمومًا — فإذا رأى Bingbot 302 نفسها مرات متتالية كافية، يبدأ معاملتها مثل 301 ويدمج الإشارات إلى الأمام — إلا أن Bing لم تؤكد علنًا أن هذا السلوك يمتد إلى 307 المتكررة. تعامل مع ذلك كفجوة توثيق حقيقية، لا حقيقة عن 307.

متى تكون 307 هي الاختيار الصحيح تقنيًا

أي إعادة توجيه يؤدي فيها فقدان الطريقة الأصلية أو الجسم إلى كسر شيء ما:

• APIs ونقاط webhook — طلب POST/PUT/DELETE يجب أن يصل إلى العنوان الجديد بالطريقة والحمولة السليمتين.
• إرسال النماذج (تدفقات POST) — كما قال Mueller: “if you have a— I’d almost say like a broken setup, that you have a form on one domain and the results are forwarded to a different one, then you would use the 307, 308.” (ترجمة) «إذا كان لديك — وأكاد أقول إعدادًا مكسورًا — نموذج في نطاق والنتائج تُمرر إلى نطاق آخر، فاستخدم 307 أو 308».
• تسليمات الدفع والشراء وتسجيل الدخول/المصادقة عبر POST — أي مكان يؤدي فيه إسقاط الجسم بصمت إلى فشل المعاملة.

ملاحظة أمان جديرة بالتنبيه: ضمان 307 للحفاظ على الطريقة يعمل في الاتجاهين. فإذا لم يكن الطلب الأصلي قابلًا للتكرار — عملية دفع أو إرسال طلب شراء أو أي أثر جانبي — فإن اتباع 307 تلقائيًا يعيد الطلب نفسه إلى العنوان الجديد. وهذا غالبًا ما تريده، لكنه يعني أيضًا أن إعادة المحاولة من العميل أو سلسلة إعادة التوجيه قد تعيد إرسال استدعاء غير قابل للتكرار أكثر من مرة. ضع ضوابط القابلية للتكرار (مفتاح idempotency أو فحص الإرسال المكرر) على نقطة الاستقبال، ولا تفترض أن إعادة التوجيه وحدها تجعل الإعادة آمنة.

سبب كبير لمواجهة المطورين 307 من دون اختيارها: بعض الأطر ومنصات edge تضبط رمزًا يحافظ على الطريقة افتراضيًا للطلبات غير GET. وأوضح مثال موثق هو Next.js — إذ تعيد دالة redirect() رمز 303 عند استدعائها من Server Action و307 في السياقات المدعومة الأخرى، وفق مرجع API الحالي؛ لذلك راجع وثائق إصدار Next.js لديك بدل افتراض أن رمزًا واحدًا ينطبق على كل إطار. تختلف الأطر وCDN وموازنات الحمل الأخرى حسب المنتج والإصدار — تحقق من رمز الحالة الفعلي الذي تعيده منصتك بدل افتراض تشابهه مع منصة أخرى. ورؤية 307 أو 303 غير متوقعة غالبًا ما تكون المنصة تطبق سلوكًا واعيًا بالطريقة لا سوء إعداد — لكن أكد ذلك في إعدادك وإصدارك تحديدًا.

متى تكون 302 هي الافتراضية العملية

إعادة التوجيه المؤقتة المعتادة لطلبات GET العادية — فلا توجد طريقة ينبغي حفظها، ومن ثم لا يمنحك ضمان 307 شيئًا:

• إعادة التوجيه الجغرافي/اللغوي (مع التحفظ المعتاد من حجب المحتوى كليًا بحسب المنطقة).
• اختبارات A/B والتقسيم — تقول إرشادات اختبار المواقع لدى Google صراحةً استخدم 302 لا 301 لنسخ الاختبار المعاد توجيهها، تحديدًا لأن إعادة التوجيه مؤقتة.
• إعادة توجيه وضع الصيانة/«سنعود قريبًا» — لكن فقط عندما توجد وجهة حقيقية ترسل إليها الزوار؛ فإذا كان الموقع كله غير متاح، تشير إرشادات Google نفسها إلى 503 (الخدمة غير متاحة) بدل أي إعادة توجيه. وإذا كان ما تعيد توجيهه طلبًا غير GET — كاستدعاء دفع أو API يصل إلى صفحة الصيانة — فستعيد 307 تشغيل الطلب في العنوان الجديد، وهذا ليس آمنًا تلقائيًا إن كان للاستدعاء أثر جانبي، فلا تستخدم 307 عادةً قبل الفحص.
• إعادة توجيه الهاتف↔سطح المكتب (m-dot) — مثال Mueller نفسه على المكان الذي تكون فيه 302 هي الرمز الصحيح تحديدًا: “a 302 redirect would be the right one because next time someone goes there, you don’t really know if they want to go to the mobile version or the desktop version.” (ترجمة) «إعادة توجيه 302 ستكون الصحيحة، لأنك في المرة التالية لا تعرف حقًا هل يريد الزائر نسخة الهاتف أم سطح المكتب». فالوجهة الصحيحة تعتمد على الزائر، وليست حركة دائمة.

«307 الشبح» في HSTS — 307 لم يرسلها خادمك

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

إذا أرسل موقع رأس HSTS (Strict-Transport-Security) عبر HTTPS، يتذكره المتصفح، وفي أي محاولة لاحقة للوصول إلى نسخة http:// يرقّي الطلب إلى https:// بنفسه — فتُعاد كتابة URI قبل أن يلامس الطلب الشبكة. تعرض إصدارات Chrome الحالية هذه الترقية الداخلية في DevTools على أنها 307، لكن لا شيء على الخادم أصدرها، كما أن الاسم الدقيق أو عدد البايتات أو عرض الرأس سلوك واجهة خاص بإصدار Chrome، لا متطلبًا في مواصفة HTTP أو HSTS — فلا تتعامل مع «307» كاسم مضمون في كل متصفح أو كل إصدار مستقبلي. وقد شرح John Mueller ذلك في موقعه الشخصي: “After seeing the HTTPS URL with the HSTS header (for example, with any redirect from the HTTP version), Chrome will act like it’s seeing a 307 redirect the next time you try to access the HTTP page.” (ترجمة) «بعد رؤية عنوان HTTPS مع رأس HSTS (مثل أي إعادة توجيه من نسخة HTTP)، سيتصرف Chrome كأنه يرى إعادة توجيه 307 في المرة التالية التي تحاول فيها الوصول إلى صفحة HTTP». والتوضيح الأهم: “Your server’s not returning a 307, Chrome is just showing it to you as such to explain that it’s doing the redirect for you.” (ترجمة) «خادمك لا يعيد 307؛ إنما يعرضها Chrome لك بهذه الصورة ليشرح أنه ينفذ إعادة التوجيه نيابةً عنك».

أشرت إلى الأمر نفسه في كتاباتي عن رموز الحالة — فهناك حتى معنى مستقل هو «307 HSTS Policy» («يفرض على العميل استخدام HTTPS») منفصل عن «307 Temporary Redirect». أما دقة SEO فهي: “When web servers require clients to only use HTTPS connections (HSTS policy), Google won’t see the 307 because it’s cached in the browser.” (ترجمة) «عندما تفرض خوادم الويب على العملاء اتصالات HTTPS فقط (سياسة HSTS)، لن ترى Google 307 لأنها مخزنة في المتصفح». فإذا رصدت 307 في تبويب Network ولم تضبطها، وقبل البحث عن قاعدة إعادة توجيه خاطئة، تحقق مما إذا كانت HSTS هي التي تجري ترقية HTTP إلى HTTPS.

الخرافات الشائعة

• «307 لا تمرر قيمة SEO نفسها التي تمررها 302». لا سند لذلك — تقول وثائق Google نفسها إن 307 «مكافئة لـ302» في كيفية معالجة إعادة التوجيه، ولا يعامل أي من الرمزين كإشارة تجعل الوجهة canonical. لكن Google لم تنشر معادلة دقيقة لـPageRank أو قيمة الروابط لأي رمز، فلا تجزم بانتقال متساوٍ أو غير متساوٍ محدد؛ العبارة الدقيقة هي أن Google تعالجهما بالطريقة نفسها، لا أنها حددت مقدار القيمة الممررة.
• «302 هي الاختيار الأكثر أمانًا أو الموصى به لأن طريقة تعامل محركات البحث معها أوضح». مبالغة. فمعاملة Google لـ307 موثقة بالقدر نفسه («مكافئة لـ302»)، وليست حالة يفهم فيها محرك البحث أحد الرمزين أكثر. وإذا كان من شيء، فـ307 تقدم ضمانًا وظيفيًا (حفظ الطريقة والجسم) لا تقدمه 302. (تقول بعض الأدلة الخارجية العكس؛ انظر ملاحظة تبويب الموارد.)
• «رؤية 307 في تبويب Network تعني أن خادمي أساء إعداد إعادة التوجيه». غالبًا خطأ — إذا كانت HSTS مفعلة وكنت قد حملت نسخة HTTPS من قبل، فهذه 307 ترقية HTTP إلى HTTPS ينفذها Chrome نفسه، لا استجابة خادم.
• «302 تحول POST دائمًا إلى GET، فلا تستخدم 302 للنموذج». مبالغة مع المتصفحات الحديثة. كان تحويل POST إلى GET مشكلة حقيقية وموثقة لدى العملاء القدامى — ولهذا وجدت 307 كخيار مضمون، لا دليلًا على أن كل 302 اليوم تسقط بيانات POST. 302 غامضة، وليست معطلة عالميًا.
• «بدّل كل عمليات التوجيه المؤقتة إلى 307 لتحصل على دفعة في الترتيب». خطأ وتغيير لا لزوم له — لا مكسب في الترتيب. السبب الصحيح الوحيد لتفضيل 307 هو حاجة حقيقية إلى حفظ الطريقة والجسم (أو تحصين المستقبل عمومًا).
• «303 و307 متشابهتان أساسًا». لا — 303 تفرض تغيير الطريقة إلى GET (مبنية على نمط POST ثم إعادة التوجيه إلى صفحة نتيجة)، وهي النقيض الوظيفي لضمان 307 في الحفظ. يسهل الخلط بينهما لأنهما مدرجتان معًا.

توصيتي

لإعادة التوجيه المؤقتة، ترتيبي المفضل للتنفيذ هو 307 / 302 / 303، قبل meta refresh (0) وHTTP refresh (0). لاحظ أنني أضع 307 فوق 302 — لا لأنها تساعد SEO (لا تفعل)، بل لأن استخدام الرمز الحافظ للطريقة دائمًا يقلل حاجتك إلى تذكر التبديل لاحقًا: إعادة توجيه GET عادية تعمل جيدًا كـ307، وفي اليوم الذي تعيد فيه توجيه نموذج أو API تكون محميًا سلفًا. هذه حجة اكتمال، وليست بلا تكلفة — فسياسة 307 الافتراضية تحتاج إلى الانضباط نفسه في Cache-Control كأي إعادة توجيه، وإلى العمل مع العملاء القدامى الذين تدعمهم فعلًا، وإلى ضوابط القابلية للتكرار لأي وجهة ليست جلب GET عاديًا. وقد أشار Mueller إلى الاكتمال نفسه: “if you always use them, then you’re always safe.” (ترجمة) «إذا استخدمتها دائمًا فأنت آمن دائمًا». ومع ذلك، 302 العادية مناسبة تمامًا، وفي حالة m-dot المحددة تكون 302 أصح تقنيًا.

أين يقع هذا في المجموعة

302 و307 رمزان من رموز إعادة التوجيه المؤقتة 3xx، ولكل منهما مقال متعمق في هذه المجموعة، إلى جانب الزوج الدائم (301 و308)، والشقيقة 303 التي تستخدم GET دائمًا، ومقارنات الأشقاء — 301 مقابل 308 في طبقة الدائم (منطق حفظ الطريقة نفسه لكن درجة أعلى) و301 مقابل 302 بين الدائم والمؤقت — فضلًا عن مخاطر التشغيل وسلاسل إعادة التوجيه وحلقاتها. ولعائلة استجابات الخادم كاملة، راجع مركز رموز حالة HTTP؛ فنوع إعادة التوجيه أيضًا إحدى إشارات canonicalization التي يغطيها canonicalization.

ملخص الذكاء الاصطناعي

خلاصة مركزة من النسخة المتقدمة:

• كلتاهما إعادة توجيه مؤقتة. تبقي 302 و307 عنوان المصدر canonical افتراضيًا — ولا تمنحان الوجهة إشارات المصدر كما تفعل 301/308 الدائمة.
• تعالجهما Google بالطريقة نفسها. تقول وثائقها إن 307 «مكافئة لـ302»، ويقول Mueller: «بالنسبة إلى SEO، لا يهم الأمر حقًا». لكن هذا ادعاء عن معالجة الزحف، لا معادلة معلنة لـPageRank أو قيمة الروابط؛ فلم تنشر Google واحدة لأي من الرمزين، فلا تجزم بانتقال متساوٍ أو غير متساوٍ محدد، ولا تفترض أن «المعالجة نفسها» تضمن بقاء المصدر متصدرًا أو استحالة فهرسة الوجهة عبر إشارات أخرى.
• الفرق الحقيقي هو الحفاظ على الطريقة. يجب أن يحافظ اتباع 307 التلقائي على الطريقة (فيبقى POST هو POST)، بينما تسمح 302 للعميل بتحويل POST إلى GET. وأضيفت 307 في HTTP/1.1 (RFC 2616 ثم 7231 ثم 9110) لإغلاق هذا الالتباس — لكن بايتات الجسم وبيانات الاعتماد والسلوك عبر أصل مختلف تعتمد على العميل، وسماح RFC بالتحويل يذكر POST تحديدًا، لا كل طريقة غير GET.
• استخدم 307 للـAPIs والنماذج وتدفقات POST وwebhook والدفع والمصادقة — لكن انتبه إلى إعادة الإرسال غير القابلة للتكرار (فقد يعيد طلب دفع أو شراء إرسال نفسه عند إعادة التوجيه؛ أضف ضوابط القابلية للتكرار). واستخدم 302 لإعادة توجيه GET العادية — الجغرافية/اللغوية، وتوصية Google الصريحة باختبارات A/B، ومثال Mueller للهاتف↔سطح المكتب. أما إعادة توجيه الصيانة فتتوقف على وجود مورد حقيقي ترسل إليه الزوار؛ وغالبًا يكون 503 أنسب في الانقطاع الكامل.
• إعدادات الأطر مرتبطة بالإصدار والسياق وليست عامة. توثق Next.js 303 لـServer Actions و307 في سياقات أخرى — راجع إصدارك بدل افتراض أن الأطر أو CDN الأخرى تتصرف بالطريقة نفسها.
• «307 الشبح» في HSTS: غالبًا ما تكون 307 في تبويب Network بمتصفحك ترقية Chrome لـHTTP إلى HTTPS بنفسه (HSTS)، لا استجابة خادم — كما أن اسم «307» الدقيق خيار واجهة خاص بإصدار Chrome، لا متطلب في مواصفة HTTP/HSTS. ويقول Mueller: “Your server’s not returning a 307, Chrome is just showing it to you as such.” (ترجمة) «خادمك لا يعيد 307؛ يعرضها Chrome لك بهذه الصورة فحسب».
• Bing: لا يوجد إرشاد مميز لـ302 مقابل 307 — فلا تفترض التكافؤ، ولا تفترض أن سلوك «302 المتكررة تُعامل كـ301» ينطبق على 307.
• لا رمز منهما قابل للتخزين افتراضيًا من حالته وحدها (RFC 9111) — فالتخزين يحتاج إلى رؤوس Cache-Control/Expires صريحة.
• ترتيبي المفضل لدى Patrick لإعادة التوجيه المؤقتة هو 307 / 302 / 303 قبل meta/HTTP refresh — لكن جعل 307 افتراضية في كل مكان ليس بلا تكلفة؛ تحقق أولًا من رؤوس التخزين المؤقت ودعم العملاء القدامى وضوابط القابلية للتكرار.

“for SEO, it doesn’t really matter.” (ترجمة) «لا يهم الأمر حقًا بالنسبة إلى SEO».

الوثائق الرسمية

وثائق ومواصفات من المصادر الأولية.

Google

• رموز حالة HTTP وأخطاء الشبكة وDNS وGoogle Search — صف 302 ذي «الإشارة الضعيفة»، وصف 307 «مكافئة لـ302»، وتحفظ «مختلفان دلاليًا — استخدم الرمز المناسب».
• إعادة التوجيه وGoogle Search — تجمع 302 و303 و307 كـ«إعادة توجيه مؤقتة» وتشرح أثر كل منها في canonicalization.
• برنامج «ما وراء السجل»، الحلقة 51 — «حديث عن عمليات إعادة التوجيه» (John Mueller وMartin Splitt) — النقاش المسجل عن سبب وجود 307/308 ومتى تهم.
• John Mueller — دليل محرك بحث لـ301 و302 و307 وغيرها — سلوك فهرسة 302 (يميل عنوان المصدر «R» إلى الفهرسة؛ وإعادة التوجيه لا تُخزن).
• John Mueller — 307s — شرح «307 الشبح» في HSTS.

Bing / Microsoft

• إدارة عمليات إعادة التوجيه – 301 و302 وcanonical (أكتوبر 2011) — إطار Bing لـ301 الدائمة و302 المؤقتة (من دون ذكر 307).
• ترحيل الموقع مع Bing (ديسمبر 2020) — إرشادات عامة لنقل الموقع (ولا تصريح خاصًا بـ307 هنا أيضًا).

المواصفات

• MDN — 307 Temporary Redirect — تعريف الحفاظ على الطريقة والجسم، والملاحظة التاريخية عن العملاء القدامى الذين يغيرون الطريقة إلى GET.
• RFC 9110 — HTTP Semantics — §15.4.8 «307 Temporary Redirect» و§15.4.3 «302 Found»، والنص الحالي للمواصفتين.

اقتباسات من المصدر

تصريحات مسجلة من Google، إضافة إلى المواصفة. وحيث تدعم الصفحة المصدر ذلك، يكون كل رابط عميق يقفز إلى المقطع المقتبس.

وثائق Google — 307 مكافئة لـ302

• “Equivalent to 302.” (ترجمة) «مكافئة لـ302» (صف 307) — Google Search Central. الانتقال إلى الاقتباس
• “While Google treats these status codes the same way, keep in mind that they’re semantically different. Use the status code that’s appropriate for the redirect so other clients (for example, e-readers, other search engines) may benefit from it.” (ترجمة) «مع أن Google تتعامل مع رموز الحالة هذه بالطريقة نفسها، تذكر أنها مختلفة دلاليًا. استخدم الرمز المناسب كي تستفيد منه العملاء الآخرون (مثل قارئات الكتب الإلكترونية ومحركات البحث الأخرى)». الانتقال إلى الاقتباس
• “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (ترجمة) «يتبع Googlebot إعادة التوجيه، لكن مسار الفهرسة لا يستخدمها إشارة إلى أن هدفها ينبغي أن يكون canonical» (إعادة التوجيه المؤقتة، التي تشمل 302/303/307). الانتقال إلى الاقتباس

John Mueller، Google (برنامج «ما وراء السجل»، الحلقة 51 — «حديث عن عمليات إعادة التوجيه»؛ ملف PDF لتفريغ رسمي، ولا توجد صفحة HTML تحمل نص مرساة مطابقًا، لذلك لا يمكن وضع رابط deep link من نوع #:~:text= لهذه الاقتباسات)

• “I had to look this up recently. And usually, with a 301 and 302, what is forwarded are GET requests.” … “And with 307, 308, it also forwards POST requests.” (ترجمة) «اضطررت إلى البحث في هذا مؤخرًا. وعادةً ما يُمرر مع 301 و302 هو طلبات GET… ومع 307 و308 تُمرر طلبات POST أيضًا».
• “If you have some kind of an API that uses POST requests, or if you have a— I’d almost say like a broken setup, that you have a form on one domain and the results are forwarded to a different one, then you would use the 307, 308.” (ترجمة) «إذا كان لديك API يستخدم POST، أو إعداد — وأكاد أقول مكسورًا — فيه نموذج في نطاق والنتائج تُمرر إلى نطاق مختلف، فاستخدم 307 أو 308».
• “I guess from a completeness point of view, if you always use them, then you’re always safe. But that’s the difference there. I think for SEO, it doesn’t really matter. It’s more like, I don’t know… Does it work for APIs or not? And usually, APIs are not something that you need to have indexed directly in Search.” (ترجمة) «من زاوية الاكتمال، أظن أنك إذا استخدمتها دائمًا فأنت آمن دائمًا. لكن هذا هو الفرق. وبالنسبة إلى SEO لا يهم الأمر حقًا؛ السؤال هو هل تعمل مع APIs أم لا، وعادةً لا تحتاج APIs إلى فهرسة مباشرة في البحث».
• “And for that kind of redirect [mobile/desktop], from a technical point of view, a 302 redirect would be the right one because next time someone goes there, you don’t really know if they want to go to the mobile version or the desktop version.” (ترجمة) «ولهذا النوع من إعادة التوجيه [الهاتف/سطح المكتب] تكون 302 صحيحة تقنيًا، لأنك في المرة التالية لا تعرف هل يريد الزائر نسخة الهاتف أم سطح المكتب». ملف تفريغ PDF

John Mueller، Google (johnmu.com — «307 الشبح» في HSTS)

• “After seeing the HTTPS URL with the HSTS header (for example, with any redirect from the HTTP version), Chrome will act like it’s seeing a 307 redirect the next time you try to access the HTTP page.” (ترجمة) «بعد رؤية عنوان HTTPS مع رأس HSTS، سيتصرف Chrome كأنه يرى 307 في المرة التالية التي تحاول فيها الوصول إلى صفحة HTTP».
• “Your server’s not returning a 307, Chrome is just showing it to you as such to explain that it’s doing the redirect for you.” (ترجمة) «خادمك لا يعيد 307؛ إنما يعرضها Chrome لك بهذه الصورة ليشرح أنه ينفذ إعادة التوجيه نيابةً عنك». قراءة المنشور

MDN — الفرق في الحفاظ على الطريقة والجسم

• “The difference between 307 and 302 is that 307 guarantees that the client will not change the request method and body when the redirected request is made. With 302, older clients incorrectly changed the method to GET.” (ترجمة) «الفرق بين 307 و302 أن 307 تضمن ألا يغير العميل طريقة الطلب والجسم عند إرسال الطلب المعاد توجيهه. ومع 302 غيّر العملاء القدامى الطريقة خطأً إلى GET». الانتقال إلى الاقتباس

أي إعادة توجيه مؤقتة: 302 أم 307؟

بما أن كلتيهما مؤقتة ومتكافئة في SEO، فالسؤال كله يعود إلى نقطة واحدة — هل يحمل الطلب طريقة أو جسمًا يجب الحفاظ عليه؟

ملاحظة عن مسار «لست متأكدًا»: تعالج Google 307 بالطريقة نفسها التي تعالج بها 302، وتعمل جيدًا لإعادة توجيه GET العادية أيضًا، لذا فاعتمادها افتراضيًا ليس خطأ — لكنه ليس مجانيًا تلقائيًا. أكد رؤوس التخزين المؤقت، وتحقق من أن العملاء الأقدم الذين ما زلت تدعمهم يتعاملون مع 307 بشكل متوقع، وإذا كان للطلب المعاد توجيهه أثر جانبي (استدعاء غير GET إلى API)، فلا تسمح لاتباع 307 التلقائي بإعادة تشغيله من دون ضوابط القابلية للتكرار.

أخطاء إعادة التوجيه المؤقتة التي ينبغي تجنبها

اختر 302 لأن 307 يُفترض أنها تمرر قيمة أقل

توثق Google أن 307 مكافئة لـ302 في البحث. اختر بينهما بناءً على سلوك الطلب، لا الترتيب.

افترض أن 302 أكثر أمانًا دائمًا لأنها أقدم

جعل العملاء القدامى معالجة طريقة 302 غامضة. إذا كان يجب أن يبقى جسم POST أو PUT أو DELETE أو webhook أو API، فاستخدم 307 لضمان الحفظ الصريح.

اعتبر كل 307 في DevTools قاعدة من الخادم

قد يعرض Chrome ترقية HSTS داخلية على أنها 307 رغم أن الخادم لم يعدها قط. أعد إنتاج الطلب بأداة فحص من جهة الخادم أو باستخدام curl قبل تعديل إعدادات إعادة التوجيه.

ادّعِ أن كل 302 تحول POST إلى GET

السلوك التاريخي مسموح به وملتبس، وليس مضمونًا في كل عميل حديث. استخدم 307 عندما تحتاج إلى اليقين؛ ولا تصف كل تطبيقات 302 بأنها معطلة.

استبدل كل 302 بـ307 لتحصل على مكسب SEO

لا توجد أفضلية في الترتيب. غيّر الرمز فقط حيث يؤدي حفظ الطريقة والجسم إلى تحسين الصحة أو حيث يكون الإعداد الافتراضي الأكثر أمانًا لإطارك مناسبًا.

اخلط بين 303 و307

هما متضادان وظيفيًا في التعامل مع الطريقة: تغيّر 303 المتابعة عمدًا إلى GET، بينما تحفظ 307 الطريقة والجسم الأصليين.

شخّص 307 غير متوقعة أو تدفق 302 مكسورًا

تعرض DevTools «Internal Redirect / 307» بلا تفسير

العَرَض: يظهر تنقل http:// على أنه 307 في Chrome، لكن لا توجد قاعدة إعادة توجيه.

السبب المرجح: رقّت HSTS الطلب داخل المتصفح قبل أن يصل إلى الخادم.

الإصلاح: افحص initiator والرؤوس، ثم أرسل طلبًا لا يتبع إعادة التوجيه تلقائيًا مباشرةً إلى عنوان HTTP باستخدام أداة من جهة الخادم — لا متصفحك، إذ قد تطبق نافذة Incognito جديدة أيضًا حالة HSTS المحملة مسبقًا. ولا تتعامل مع curl كخط أساس محايد تلقائيًا — فقد يكون له مخزن HSTS خاص به، فلاحظ طريقة استدعائه. وإذا اختلفت استجابة الخادم الخام عما أظهرته DevTools، فلا «تصلح» 307 الشبح؛ راجع إعادة توجيه HTTP→HTTPS الفعلية من الخادم بصورة منفصلة، وأعد تشغيل أي طلب غير GET كاختبار مضبوط مستقل — فطلب HEAD الذي يتبع تلقائيًا لا يثبت سلوك POST أو الجسم.

يفقد POST جسمه بعد إعادة توجيه مؤقتة

العَرَض: يصل نموذج أو webhook أو تسجيل دخول أو استدعاء API إلى الهدف كـGET أو بلا حمولة.

السبب المرجح: استخدم المصدر 302، فسمح للعميل بتغيير الطريقة، أو أعاد وسيط ما كتابة الاستجابة.

الإصلاح: استخدم 307 للانتقال المؤقت، ثم أعد تشغيل طلب اختبار آمن وأكد في سجلات الهدف أن الطريقة ونوع المحتوى والجسم وصلت سليمة.

تصدر المنصة 307 رغم اختيار إعادة توجيه عامة

العَرَض: يعيد إطار أو منصة edge الرمز 307 بدل 302 المتوقع.

السبب المرجح: اختارت المنصة الرمز المؤقت الحافظ للطريقة، غالبًا لطلب غير GET.

الإصلاح: تحقق من أن الانتقال مؤقت فعلًا وأن الحفاظ على الطلب صحيح. إن كان كذلك، أبقِه — فـGoogle تعامل الرمزين بالطريقة نفسها. لا تغيّره إلا عندما تتطلب دلالات التطبيق أو توافق العميل استجابة مختلفة.

302 مقابل 307 في لمحة

قاعدة عملية: إعادة توجيه صفحة GET مؤقتة → كلاهما يعمل؛ وطلب مؤقت غير GET يجب أن يصل سليمًا → 307.

أدوات تحديد إعادة التوجيه التي تلقيتها فعلًا

أداة Patrick المجانية

• Bulk HTTP Status Code Checker — نفّذ طلبات من جهة الخادم لما يصل إلى 500 عنوانًا وراجع الرموز والسلاسل الفعلية. وهي مفيدة خصوصًا للفصل بين استجابات الخادم وعرض Chrome الداخلي لـ307 الخاص بـHSTS فقط.

افحص سلوك الطلب

• Redirect Checker — تتبع مصدرًا واحدًا عبر كل قفزة وأكد هل يبدأ الخادم بـ302 أم 307.
• لوحة Network في أدوات مطور المتصفح — افحص initiator وما إذا كان Chrome يسمي الإدخال إعادة توجيه داخلية؛ ولا تعتبر ذلك وحده دليلًا على استجابة الخادم.
• curl مع سجلات التطبيق — أرسل POST آمنًا إلى بيئة التجربة وأكد أن الهدف تلقى الطريقة والجسم نفسيهما؛ وإذا ضبطت لـcurl مخزن HSTS خاصًا به (--hsts)، فضع ذلك في حسابك عند تفسير النتيجة. أدوات الحالة وحدها لا تثبت وصول الحمولة.

اختبر نفسك: 302 مقابل 307

خمسة أسئلة عن إعادة التوجيه المؤقتة وما الذي يفرق بينهما فعلًا. اختر إجابة لكل سؤال ثم تحقق من إجاباتك.

موارد تستحق وقتك

كتاباتي ذات الصلة

• 11 نوعًا من إعادة التوجيه وتأثيرها في SEO (Ahrefs، مع Joshua Hardwick) — مراجعي الكامل لكل نوع من إعادة التوجيه. وفيه أشرح ترتيبي المفضل لتنفيذ إعادة التوجيه المؤقتة — 307 / 302 / 303 > meta refresh 0 / HTTP refresh 0 — وأذكر خلاصة SEO بوضوح: “For SEO, it’s the same, but if you have data being sent through forms that redirect, then you don’t want to be swapping between GET and POST.” (ترجمة) «من جهة SEO النتيجة واحدة، لكن إعادة توجيه بيانات النماذج لا ينبغي أن تبدّل GET وPOST».
• رموز حالة HTTP وتأثيرها في SEO (Ahrefs) — مرجعي لكل رمز حالة، بما فيه المعنيان المختلفان لـ307 (Temporary Redirect وسياسة HSTS 307)، وملاحظة أن HSTS تجعل «Google لا ترى 307 لأنها مخزنة في المتصفح».
• الدليل المبتدئ إلى SEO التقني — موضع إعادة التوجيه في الصورة الأوسع.

“Google won’t see the 307 because it’s cached in the browser.” (ترجمة) «لن ترى Google الرمز 307 لأنه مخزّن في المتصفح».

حديثي

• Patrick Stox on SlideShare وSpeaker Deck — محاضراتي عن SEO التقني، ويتناول عدد منها إعادة التوجيه وcanonicalization. (ينطبق إخلاء مسؤوليتي المعتاد: “This is my understanding of systems… not going to be 100% complete or accurate.” (ترجمة) «هذا فهمي للأنظمة… وليس كاملًا أو دقيقًا بنسبة 100%».)

رسمي

• Google — رموز حالة HTTP وأخطاء الشبكة وDNS — سطر «مكافئة لـ302» وتحفظ «مختلفان دلاليًا، استخدم الرمز الصحيح».
• Google — إعادة التوجيه وGoogle Search — تجمع 302/303/307 تحت إعادة التوجيه المؤقتة.
• برنامج «ما وراء السجل» — «حديث عن عمليات إعادة التوجيه» (Google Search Relations، الحلقة 51) — نقاش Mueller وSplitt الذي أخذت منه الاقتباسات أعلاه.

من أنحاء المجال

• John Mueller — 307s — أوضح شرح لـ«307 الشبح» في HSTS: 307 التي يعرضها المتصفح ولم يرسلها الخادم.
• MDN — 307 Temporary Redirect — تعريف واضح لحفظ الطريقة والجسم، وملاحظة تاريخية عن العملاء القدامى.
• An SEO’s guide to redirects (Search Engine Land، Helen Pollitt) — نظرة عامة جيدة إلى عائلة إعادة التوجيه.
• URL Redirects For SEO: A Technical Guide — مراجعة تقنية أخرى مفيدة.
• خرافة ينبغي تصحيحها: توصي صفحة Conductor عن 302 vs 307 باستخدام 302 بدل 307 لأن «من الواضح كيف تتعامل محركات البحث مع إعادة توجيه 302». هذا يناقض وثائق Google نفسها التي تسمي 307 صراحةً «مكافئة لـ302» — فمعاملة 307 موثقة بالقدر نفسه. لا تتعامل مع «302 خيار SEO الأكثر أمانًا» على أنه مرجع؛ العامل الحقيقي الوحيد هو حاجتك إلى حفظ الطريقة والجسم.
• r/TechSEO — مجتمع تصحيح مشكلات إعادة التوجيه وcanonicalization.

“it’s clear how search engines treat the 302 redirect.” (ترجمة) «من الواضح كيف تتعامل محركات البحث مع إعادة توجيه 302». “Equivalent to 302” (ترجمة) «يعادل 302». “302 is the safer SEO choice” (ترجمة) «302 هي خيار SEO الأكثر أمانًا».

سجل التغييرات