إعادة التوجيه المؤقتة 307

الخلاصة — إعادة التوجيه 307 مؤقتة، مثل 302 تمامًا؛ فهي ترسل الزوار ومحركات البحث إلى عنوان URL جديد مؤقتًا من دون أن تقول لـGoogle انقل ترتيب العنوان القديم إلى الجديد. والشيء الوحيد الذي يميزها عن 302 هو أنها تعد بعدم تغيير نوع الطلب. فإذا أرسل شخص نموذجًا (POST)، بقي POST. أما روابط الصفحات العادية فلا يظهر فيها الفرق؛ فالأمر يهم النماذج والتطبيقات فقط. و«307» التي تراها أحيانًا في متصفحك عند ترقية https ليست إعادة توجيه حقيقية أصلًا.

ما هي إعادة التوجيه 307؟

عندما ينتقل عنوان URL إلى مكان آخر مؤقتًا — لا نهائيًا — يستطيع الخادم الرد بـ307 Temporary Redirect وتوجيه المتصفح إلى الموقع الجديد. هذه هي الفكرة الأساسية نفسها في 302: إنها مؤقتة، لذلك لا تتعامل معها Google إشارةً إلى نقل ترتيب العنوان الأصلي إلى الجديد كما تفعل مع إعادة التوجيه الدائمة. إنها إشارة ضعيفة لا توحّد canonicalization، وليست ضمانًا بأن العنوان الأصلي سيحافظ على ترتيبه أو يظل مفهرسًا إلى الأبد. تستخدم إعادة التوجيه المؤقتة لصفحة متوقفة للصيانة، أو حملة موسمية، أو أي شيء تخطط للعودة عنه لاحقًا.

ما الذي يميز 307 عن 302؟

في الحقيقة لا يوجد إلا فرق واحد، ومعظم الناس لا يصادفونه. للطلب على الويب طريقة — غالبًا GET (مجرد جلب صفحة)، وأحيانًا POST (إرسال بيانات مثل إرسال نموذج). تضمن 307 أن يحافظ المتصفح على الطريقة نفسها عند اتباع إعادة التوجيه. كانت المتصفحات القديمة تحول POST أحيانًا إلى GET مع 302، مما قد يكسر إرسال النموذج. وتزيل 307 هذا الخطر بنص المواصفة. Evidence for this claim RFC 9110 defines 307 Temporary Redirect as a temporary move and requires clients not to change the request method when following it automatically. Scope: HTTP semantics for real server 307 responses, not browser-internal HSTS displays. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.8 — 307 Temporary Redirect

في الغالبية العظمى من عمليات إعادة التوجيه — عندما ينقر شخص رابطًا إلى صفحة — لا يغير هذا شيئًا على الإطلاق، لأن الطلبات تكون GET في الحالتين.

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

لا. تقول وثائق Google نفسها إن 307 «مكافئة لـ302». وكلتاهما مؤقتتان، لذلك لا تنقل أي منهما ترتيب الصفحة القديمة إلى الجديدة بالطريقة التي تفعلها إعادة التوجيه الدائمة (301). لا توجد عقوبة سرية ولا دفعة سرية — تتعامل Google مع 307 تمامًا كما تتعامل مع 302.

«307» التي ليست إعادة توجيه

هذا هو الجزء الذي يربك الناس. إذا كان موقعك يفرض https (ميزة أمنية تسمى HSTS)، فقد يعرض المتصفح أحيانًا «307» في أدوات المطور عند زيارة نسخة http من الصفحة. خادمك لم يرسلها قط — فالمتصفح اخترعها ليشرح أنه قفز مباشرةً إلى النسخة الآمنة بنفسه. بل يعرض أيضًا استجابة بحجم 0 بايت، وهذه هي العلامة الكاشفة.

لذلك إذا أبلغت أداة تدقيق أو متصفحك عن 307 مفاجئة، فلا تفزع من أن خادمك سيئ الإعداد. عادةً ما تمسح نافذة تصفح خاصة جديدة ذاكرة HSTS التي تعلمها المتصفح وتعرض رمز الحالة الحقيقي — لكن ليس دائمًا: فبعض النطاقات موجودة في قائمة HSTS المحمّلة مسبقًا المدمجة في المتصفحات، ولا تمسحها النافذة الخاصة. وطريقة رؤية ما يعيده خادمك فعلًا الأكثر موثوقية هي أداة فحص إعادة التوجيه أو طلب curl.

هل تريد لغة المواصفة، وما قاله John Mueller، وآلية HSTS كاملة، وكيف تعيد 307 فعلًا؟ انتقل إلى تبويب Advanced.

الخلاصة — إعادة التوجيه 307 مؤقتة، وتنص RFC 9110 على أنها «MUST NOT change the request method» (ترجمة) «يجب ألا تغيّر طريقة الطلب» — وهو الضمان الصارم الوحيد الذي لا تقدمه 302. أما في SEO فهي غير مؤثرة: تسرد وثائق Google 307 بوصفها «مكافئة لـ302» (إشارة مؤقتة ضعيفة)، وقال Mueller إن اختيار 307 مقابل 302 «لا يهم حقًا» للبحث — فالمسألة هي هل يجب أن تعمل إعادة التوجيه مع حركة POST/API. و307 التي تربك الناس فعلًا هي أثر HSTS: «إعادة توجيه» لا تظهر إلا في المتصفح، بحجم 0 بايت، ولم يرسلها الخادم، بل نتجت عندما رقّى المتصفح http إلى https بنفسه. ولها حالتان لا علاقة وظيفية بينهما، والفصل بينهما هو المهمة كلها.

حالتان مختلفتان تمامًا لـ307

هذه هي الفكرة المنظمة لكل ما يلي، وهي مأخوذة مباشرةً من دليلي لرموز الحالة، حيث توجد لـ307 إدراجان منفصلان: “307 Temporary Redirect – Has the same functionality as a 302 redirect, except you can’t switch between POST and GET” (ترجمة) «إعادة التوجيه المؤقتة 307 — تؤدي وظيفة 302 نفسها، لكن لا يمكن تبديل POST وGET» و*“307 HSTS Policy – Forces the client to use HTTPS when making requests instead of HTTP”* (ترجمة) «سياسة HSTS 307 — تفرض على العميل استخدام HTTPS عند الطلب بدل HTTP». يشتركان في الرقم ولا يكاد يجمعهما شيء آخر:

1. 307 بوصفها إعادة توجيه مؤقتة حقيقية صادرة من الخادم — اختيرت عمدًا (أو جعلها إطار العمل افتراضية) للحفاظ على طريقة HTTP والجسم في طلب غير GET.
2. 307 بوصفها أثرًا متصفحيًا لـHSTS — ليست استجابة خادم أصلًا. يرقّي المتصفح http إلى https داخليًا ويسمي هذه الترقية 307.

الخلط بين هاتين الحالتين هو المصدر الأكثر شيوعًا للارتباك حول 307. وسأعالجهما واحدةً تلو الأخرى.

الحالة الأولى: 307 الحقيقية — ما الذي تشترطه المواصفة؟

مواصفة RFC 9110 (مواصفة دلالات HTTP الحالية) واضحة بلا لبس في §15.4.8:

«The 307 (Temporary Redirect) status code indicates that the target resource resides temporarily under a different URI and the user agent MUST NOT change the request method if it performs an automatic redirection to that URI.» (ترجمة) «يشير رمز الحالة 307 (إعادة التوجيه المؤقتة) إلى أن المورد الهدف موجود مؤقتًا تحت URI مختلف، ولا يجوز لعميل المستخدم تغيير طريقة الطلب إذا نفذ إعادة توجيه تلقائية إلى ذلك URI.»

عبارة «MUST NOT» متطلب صارم وليست اقتراحًا. قارنها بقسم 302 (§15.4.3)، الذي يوثق صراحةً الفوضى التاريخية التي أُنشئت 307 لإصلاحها: يوضح هذا القسم أن العميل قد يغيّر الطريقة من POST إلى GET لأسباب تاريخية؛ أما 307 فتُستخدم عندما يكون هذا التغيير غير مرغوب فيه. بعبارة أخرى، وُجدت 307 تحديدًا لإزالة غموض POST→GET الذي كانت تسببه العملاء الأقدم مع 302.

تذكر 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 and 302 responses are identical when the request method is GET.» (ترجمة) «الفرق بين 307 و302 أن 307 تضمن ألا يغير العميل طريقة الطلب والجسم عند إرسال الطلب المعاد توجيهه. ومع 302 غيّر العملاء الأقدم الطريقة خطأً إلى GET. وتكون استجابات 307 و302 متطابقة عندما تكون طريقة الطلب GET.»

تلك الجملة الأخيرة هي الأهم لـSEO. فكل إعادة توجيه تقريبًا يهتم بها صاحب موقع — من صفحة قديمة إلى صفحة جديدة — هي طلب GET، ومع طلبات GET تكون 307 و302 متطابقتين حرفيًا. ولا يظهر ضمان حفظ الطريقة إلا عندما لا تكون الطريقة GET: إعادة إرسال نموذج، أو نقطة API، أو هدف webhook، أو تسليم POST للدفع أو المصادقة. ما تضمنه المواصفة هو الطريقة والجسم — لكنها لا تحدد وحدها كيف يعالج كل عميل الرؤوس وبيانات الاعتماد والطلبات عبر أصل مختلف عند إعادة التشغيل، لذلك تحقق من عميلك الفعلي ولا تفترض تطابق البايتات. وإذا كنت تقارن الرمزين مباشرةً لنقل صفحة عادي، فهذه المقارنة مغطاة بتفصيل في مقال 302 مقابل 307 المخصص؛ ويفترض هذا المقال أنك تعرف أساس إعادة التوجيه المؤقتة من الغوص العميق في 302، ويركز على ما يخص 307 وحدها.

302 مقابل 303 مقابل 307 في جدول واحد

تندرج الرموز الثلاثة في فئة «المؤقتة» في RFC، لكنها لا تتصرف بالطريقة نفسها على المحورين المهمين فعلًا — حفظ الطريقة والتخزين المؤقت:

لا يمكن تخزين أي من الرموز الثلاثة استدلاليًا افتراضيًا — فـ307 (مثل 302 و303) تحتاج إلى إشارة حداثة صريحة (Cache-Control وExpires وما شابه) قبل أن يخزنها cache من دون طلبها مجددًا.

الحالة الأولى، متابعة: كيف تتعامل Google مع 307 الحقيقية في SEO

النسخة المختصرة: تمامًا مثل 302. تسرد وثائق Google الخاصة بـرموز حالة HTTP صف 307 بوصفها «مكافئة لـ302»، ويشرح صف 302 الذي ترث منه ما يعنيه ذلك:

«By default, Google’s crawlers follow the redirect, and Google systems use the redirect as a weak signal that the redirect target should be processed.» (ترجمة) «افتراضيًا، تتبع برامج زحف Google إعادة التوجيه، وتستخدم أنظمة Google إعادة التوجيه إشارةً ضعيفة إلى أن هدفها ينبغي معالجته.»

كلمة «ضعيفة» هي الأساس — فإعادة التوجيه المؤقتة لا توحّد canonicalization على الهدف بالطريقة التي تفعلها الدائمة. وتجمع وثيقة إعادة التوجيه وبحث Google لدى Google رموز 302 و303 و307 تحت «المؤقتة» وتصف السلوك مباشرةً: «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». وفي الصفحة نفسها، الإطار المقصود واحد: «If you just want to send users to a different page temporarily, use a temporary redirect.» (ترجمة) «إذا كنت تريد فقط إرسال المستخدمين إلى صفحة مختلفة مؤقتًا، فاستخدم إعادة توجيه مؤقتة.»

مباشرةً بعد صفّي 307 و308، تضيف Google التحفظ الجدير بأن يُكتب على الجدار:

وتؤكد Google أن الرمزين متساويان في المعالجة، مع اختلافهما دلاليًا؛ لذلك ينبغي اختيار الرمز المناسب ليستفيد منه العملاء الآخرون.

إذًا تضع Google 307 و302 في فئة واحدة للترتيب، لكنها ما زالت تطلب اختيار الرمز الصحيح دلاليًا. هذه هي إجابة SEO كلها. Evidence for this claim Google treats 307 as equivalent to 302 for Search while noting that the HTTP semantics differ. Scope: Google Search redirect handling; clients still need the semantically appropriate status code. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search وعبّر John Mueller عن ذلك بصرامة أكبر في Search Off the Record الحلقة 51 («Let’s talk redirects»)، موضحًا أن «with 307, 308, it also forwards POST requests» (ترجمة) «مع 307 و308 تُمرر طلبات POST أيضًا» — بخلاف 301/302 التي تمرر طلبات GET — ثم وصل إلى النقطة الحاسمة:

وخلص Mueller إلى أن الاختيار لا يغيّر SEO؛ فالتمييز العملي يتعلق بعمل APIs، وهي عادةً لا تحتاج إلى فهرسة مباشرة في البحث.

لا توجد فائدة ترتيب من تحويل إعادة التوجيهات المؤقتة إلى 307. والسبب الصحيح الوحيد لاختيارها هو حفظ الطريقة/الجسم — أو تفضيل عام لتحصين المستقبل، وسأعود إلى ذلك في النهاية.

الحالة الأولى، متابعة: افتراضات أطر العمل وCDN

تتزايد أسئلة «لماذا هذه 307؟» التي لا تكون اختيارات متعمدة أصلًا — بل افتراضات أطر العمل. فالدالة redirect() في Next.js تجعل 307 افتراضية، وتشرح الوثائق السبب تحت عنوان حرفي «Why does redirect use 307 and 308?»: «The redirect() method uses a 307 by default, instead of a 302 temporary redirect, meaning your requests will always be preserved as POST requests.» (ترجمة) «تستخدم الدالة redirect() الرمز 307 افتراضيًا بدل إعادة التوجيه المؤقتة 302، ما يعني أن طلباتك ستُحفظ دائمًا بوصفها طلبات POST». (يستخدم Next.js الرمز 303 تحديدًا داخل Server Actions، ويوفر permanentRedirect() منفصلًا لحالة 308.) فإذا رأيت 307 لم تكتبها يدويًا، فتحقق هل يجعل إطارك أو منصة edge الرمز افتراضيًا لإعادة التوجيهات غير GET — فهذا هو الجواب عادةً، وغالبًا ما يكون صحيحًا.

الحالة الثانية: «307 الشبح» في HSTS التي لم يرسلها خادمك

هذه هي المنطقة التي لا تغطيها الشروحات بما يكفي، وفيها تظهر قيمة مقال مخصص لـ307. عندما يرسل الموقع رأس Strict-Transport-Security (HSTS)، فإنه يقول للمتصفح: من الآن فصاعدًا لا تحملني إلا عبر https. وفي الطلب التالي إلى نسخة http، يرقّي المتصفح الطلب إلى https بنفسه من دون التواصل مع الخادم — ثم يعرض هذه الترقية الداخلية كـ«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. 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.» (ترجمة) «بعد رؤية عنوان HTTPS مع رأس HSTS (مثل أي إعادة توجيه من نسخة HTTP)، سيتصرف Chrome كأنه يرى إعادة توجيه 307 في المرة التالية التي تحاول فيها الوصول إلى صفحة HTTP. خادمك لا يعيد 307؛ إنما يعرضها Chrome لك بهذه الصورة ليشرح أنه ينفذ إعادة التوجيه نيابةً عنك.»

الجسم بحجم 0 بايت هو العلامة — إذ يضيف Mueller أن «the 307 isn’t actually a redirect at all, it’s just a placeholder» (ترجمة) «307 ليست إعادة توجيه فعلية أصلًا، بل مجرد عنصر نائب». ويعرض دليلي لإعادة التوجيه النتيجة العملية للتدقيق: «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. The initial hit (without cache) will have a server response code that’s likely a 301 or a 302. But your browser will show you a 307 for subsequent requests which makes it more difficult to troubleshoot. You will need to use a fresh Incognito session to see the returned status code.» (ترجمة) «عندما تفرض خوادم الويب على العملاء اتصالات HTTPS فقط (سياسة HSTS)، لن ترى Google 307 لأنها مخزنة في المتصفح. ستكون استجابة الخادم في الزيارة الأولى (من دون cache) غالبًا 301 أو 302. لكن متصفحك سيعرض 307 في الطلبات اللاحقة، ما يصعّب التصحيح. وستحتاج إلى جلسة تصفح خاصة جديدة لرؤية رمز الحالة المعاد.»

ما الذي يراه Googlebot فعلًا مع HSTS (وكيف تطورت القصة)

يجدر جمع تصريحين من Google بينهما خمس سنوات. ففي ديسمبر 2015، قالت Zineb Ait Bahajji (وكانت في Google آنذاك)، وفق Search Engine Roundtable: وفي التصريح المنقول عن عام 2015، وُصفت حالة HSTS بأنها تجعل Googlebot يرى إعادة توجيه 301، بينما يظهر 307 كإعادة توجيه داخلية في أدوات المستخدم. وبحلول أكتوبر 2020، كان إطار Mueller في فيديو Ask Google Webmasters (عبر Search Engine Journal) مختلفًا قليلًا: «In short, [Googlebot] doesn’t interact with them. 307 redirects are generally not real redirects.» (ترجمة) «باختصار، لا يتفاعل Googlebot معها. وإعادات التوجيه 307 ليست عمومًا إعادة توجيه حقيقية.» وفي كلتا الحالتين، لا يرى الزاحف «307» نفسها التي يراها الإنسان في أدوات المطور — فقد تغيرت أدوات البنية التحتية للزحف (وأُحيل Fetch as Google إلى التقاعد لصالح URL Inspection)، لكن النقطة الأساسية صمدت عقدًا على الأقل: لا توجد 307 حقيقية صادرة من الخادم في حالة HSTS. اعتبر تصريح 2020 الإرشاد الحالي، وتصريح 2015 تاريخًا مفيدًا.

الخلاصة التشغيلية المهمة: HSTS وسيلة راحة للمتصفح، وليست آلية لاكتشاف الزحف. ما زال على مالكي المواقع إنشاء إعادة توجيه حقيقية من جهة الخادم (301 فعلية) من http إلى https إذا أرادوا أن يعمل المسار مع الزواحف.

كيف تتعامل Bing مع 307؟

بصراحة؟ توجد فجوة في التوثيق. لم أعثر على تصريح عام من Bing يعالج 307 بالاسم أو 307 الناتجة عن HSTS تحديدًا. وتغطي إرشادات Bing لإعادة التوجيه (منشور 2011 إدارة عمليات إعادة التوجيه – 301 و302 وcanonical ومنشور 2020 ترحيل موقع الويب مع Bing) انقسام 301/302 الدائم مقابل المؤقت فقط — ولا تذكر 307 أو 308 أو HSTS. لذا لا تفترض التكافؤ مع Google، وتعامل مع الأمر بوضوح: لم تقل Bing شيئًا عامًا خاصًا بـ307. والظاهرة حقيقية وذات صلة بالزحف بصرف النظر عن المحرك — إذ يوفر Screaming Frog في SEO Spider خيار «Respect HSTS Policy» تحديدًا لأن HSTS تؤثر في الزحف — لكن هذه وثائق أداة، وليست تصريحًا من Bing.

متى تختار 307 عمدًا؟

اختر 307 (بدل 302) كلما كان فقدان الطريقة أو الجسم الأصلي سيكسر شيئًا ما:

• نقاط API وأهداف webhook التي تستقبل POST/PUT/PATCH.
• تدفقات إرسال النماذج (POST) التي تعيد التوجيه بعد المعالجة.
• تسليمات POST للدفع أو تسجيل الدخول بين المضيفين.
• أي موضع يحمل فيه الطلب جسمًا لا يمكنك تحمل إسقاطه.

في نقل صفحة عادي من عنوان إلى آخر، لا يمكن لـGoogle التمييز بين 302 و307، لذا فكلاهما مناسب على محور SEO. وإذا كنت تتعامل مع النسخة الدائمة من منطق حفظ الطريقة نفسه، فهذه علاقة 301 مقابل 308 — فـ308 بالنسبة إلى 301 مثل 307 بالنسبة إلى 302.

تفضيلي المعلن، من دليل إعادة التوجيه، أكثر حسمًا من عبارة «لا يهم»: «my preferred order would be: 307 / 302 / 303 > Meta refresh 0 / HTTP refresh 0.» (ترجمة) «ترتيبي المفضل هو: 307 / 302 / 303 > Meta refresh 0 / HTTP refresh 0». أضع 307 أولًا بين الخيارات المؤقتة — فاستخدامها باستمرار يعني أنك آمن دائمًا من جهة حفظ الطريقة، وهو قريب من حجة «الاكتمال» التي قدمها Mueller أيضًا. وأيًا كان اختيارك، انتبه إلى ألا تصبح 307 الحقيقية (أو أثر HSTS) قفزةً ضمن سلسلة إعادة توجيه أطول — فكل قفزة إضافية تعني زمن انتقال وكفاءة مهدرة.

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

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

• لـ307 حالتان لا علاقة بينهما. (1) إعادة توجيه مؤقتة حقيقية صادرة من الخادم وتحافظ على طريقة HTTP والجسم؛ (2) أثر متصفحي لـHSTS — «307» بحجم 0 بايت لم يرسلها الخادم، بل نتجت عندما رقّى المتصفح http→https بنفسه. الفصل بينهما هو المهمة كلها.
• الحالة الأولى — ضمان المواصفة: تقول RFC 9110 إن 307 “MUST NOT change the request method.” (ترجمة) «يجب ألا تغيّر طريقة الطلب.» وتضيف MDN: “307 and 302 responses are identical when the request method is GET.” (ترجمة) «تتطابق استجابتا 307 و302 عندما تكون طريقة الطلب GET.» لذا لا يظهر الفرق إلا مع حركة POST/PUT/PATCH (النماذج وAPIs). ويشمل الضمان الطريقة والجسم؛ أما التعامل مع الرؤوس وبيانات الاعتماد والطلبات عبر أصل مختلف عند الإعادة فيعتمد على العميل.
• 302 مقابل 303 مقابل 307: قد تحول 302 (تاريخيًا) POST إلى GET، وتسترجع 303 الهدف عمدًا بـGET/HEAD، ويجب ألا تغير 307 الطريقة — ولا يمكن تخزين أي من الرموز الثلاثة استدلاليًا افتراضيًا.
• إجابة SEO: تسرد وثائق Google 307 بوصفها «مكافئة لـ302» — إشارة مؤقتة ضعيفة لا توحّد الإشارات على الهدف. ويقول Mueller: «بالنسبة إلى SEO لا يهم الأمر حقًا»؛ والسؤال الحقيقي هو «هل تعمل مع APIs؟».
• افتراضات أطر العمل: تجعل redirect() في Next.js الرمز 307 افتراضيًا (303 داخل Server Actions، وpermanentRedirect() لحالة 308) للحفاظ على POST — وهذا مصدر شائع لـ307 «العرضية» وغالبًا ما يكون صحيحًا.
• الحالة الثانية — HSTS: يعرض المتصفح 307 بحجم 0 بايت؛ أما رمز الخادم الحقيقي فعادةً 301/302. لا يرى Googlebot هذه 307 (Mueller 2020: «لا يتفاعل معها»؛ Zineb 2015: «يرى 301»). وما زلت تحتاج إلى 301 حقيقية من الخادم لـhttp→https. دقّق بأداة فحص إعادة التوجيه أو curl عادي — وغالبًا تنجح نافذة خاصة جديدة أيضًا، لكن ليس مع النطاقات الموجودة في قائمة HSTS المسبقة المدمجة في المتصفح.
• Bing: لا يوجد تصريح عام خاص بـ307 — وهذه فجوة توثيق، لا تكافؤًا مثبتًا.
• التفضيل: لا يوجد سبب ترتيبي للتحول إلى 307؛ لكن ترتيب Patrick الخاص يضع 307 أولًا بين الخيارات المؤقتة لتحصين المستقبل.

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

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

Google

• رموز حالة HTTP وأخطاء الشبكة وDNS وGoogle Search — صف «307 (temporary redirect) — Equivalent to 302»، وعبارة صف 302 عن «الإشارة الضعيفة»، والتحفظ القائل إن الرموز مختلفة دلاليًا.
• إعادة التوجيه وGoogle Search — تجمع 302/303/307 تحت «المؤقتة»، وتقول إن «مسار الفهرسة لا يستخدم إعادة التوجيه إشارةً إلى أن هدفها ينبغي أن يكون canonical».

Bing / Microsoft

• إدارة عمليات إعادة التوجيه – 301 و302 وcanonical — إرشادات Bing لإعادة التوجيه (301/302 فقط، بلا ذكر لـ307 أو HSTS).
• ترحيل الموقع مع Bing — إرشادات الترحيل، وتتناول 301/302 فقط مرة أخرى.

مواصفة HTTP

• RFC 9110 §15.4.8 — 307 Temporary Redirect — يجب ألا يغير طريقة الطلب.
• RFC 9110 §15.4.3 — 302 Found — ملاحظة POST→GET التاريخية التي تحيل إلى 307.

مرجع تقني

• MDN — 307 Temporary Redirect — حفظ الطريقة والجسم، وكون الاستجابتين «متطابقتين عندما تكون طريقة الطلب GET».

إطار عمل

• Next.js — مرجع الدالة redirect() — سؤال «Why does redirect use 307 and 308?»؛ الافتراضي 307 (و303 داخل Server Actions).

أداة زحف

• Screaming Frog — دليل SEO لزحف HSTS وإعادات التوجيه 307 — إعداد «Respect HSTS Policy» وآلية HSTS.

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

تصريحات مسجلة؛ وكل رابط يقفز إلى المقطع المقتبس أو يوثقه.

وثائق Google — معالجة SEO

• “307 (temporary redirect) Equivalent to 302.” (ترجمة) «307 (إعادة توجيه مؤقتة) — مكافئة لـ302». — Google Search Central، رموز حالة HTTP وأخطاء الشبكة وDNS وبحث Google. الانتقال إلى الاقتباس
• “By default, Google’s crawlers follow the redirect, and Google systems use the redirect as a weak signal that the redirect target should be processed.” (ترجمة) «افتراضيًا، تتبع برامج زحف Google إعادة التوجيه، وتستخدم أنظمة Google إعادة التوجيه إشارةً ضعيفة إلى أن هدفها ينبغي معالجته». (صف 302 الذي ترث منه 307 هذا الوصف) الانتقال إلى الاقتباس
• “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». — Google Search Central، إعادة التوجيه وبحث Google. الانتقال إلى الاقتباس

مواصفة HTTP / MDN — الضمان التقني

• “The 307 (Temporary Redirect) status code indicates that the target resource resides temporarily under a different URI and the user agent MUST NOT change the request method if it performs an automatic redirection to that URI.” (ترجمة) «يشير رمز الحالة 307 (إعادة التوجيه المؤقتة) إلى أن المورد الهدف موجود مؤقتًا تحت URI مختلف، ولا يجوز لعميل المستخدم تغيير طريقة الطلب إذا نفذ إعادة توجيه تلقائية إلى ذلك URI». — RFC 9110، §15.4.8. قراءة القسم
• “For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 307 (Temporary Redirect) status code can be used instead.” (ترجمة) «لأسباب تاريخية، يجوز لعميل المستخدم تغيير طريقة الطلب من POST إلى GET في الطلب اللاحق. وإذا كان هذا السلوك غير مرغوب، يمكن استخدام رمز الحالة 307 بدلًا منه». — RFC 9110، §15.4.3 (قسم 302). قراءة القسم
• “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… 307 and 302 responses are identical when the request method is GET.” (ترجمة) «الفرق بين 307 و302 أن 307 تضمن ألا يغير العميل طريقة الطلب والجسم عند إعادة التوجيه… وتكون استجابتا 307 و302 متطابقتين عندما تكون طريقة الطلب GET». — MDN، 307 Temporary Redirect. الانتقال إلى الاقتباس

John Mueller، Google — SEO وحفظ الطريقة

• “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 شيئًا تحتاج إلى فهرسته مباشرةً في البحث.» — Search Off the Record، الحلقة 51، «Let’s talk redirects» (17 نوفمبر 2022). ملف تفريغ الحلقة
• “And with 307, 308, it also forwards POST requests” (ترجمة) «ومع 307 و308 تُمرر طلبات POST أيضًا» (مقابل 301/302 التي تمرر طلبات GET). — الحلقة نفسها.

John Mueller، Google — «307 الشبح» في HSTS

• “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… the 307 isn’t actually a redirect at all, it’s just a placeholder.” (ترجمة) «خادمك لا يعيد 307؛ إنما يعرضها Chrome لك بهذه الصورة ليشرح أنه ينفذ إعادة التوجيه نيابةً عنك… و307 ليست إعادة توجيه فعلية أصلًا، بل مجرد عنصر نائب». — John Mueller، HTTPS & HSTS: 301, 302, or 307? (johnmu.com، وكانت أصلًا في Google+، يونيو 2016). الانتقال إلى الاقتباس
• “In short, [Googlebot] doesn’t interact with them. 307 redirects are generally not real redirects.” (ترجمة) «توضح الخلاصة أن Googlebot لا يتفاعل مع هذه الحالة، وأن 307 ليست عادةً إعادة توجيه فعلية.» — John Mueller، Ask Google Webmasters (أكتوبر 2020)، عبر Search Engine Journal. الانتقال إلى الاقتباس

Zineb Ait Bahajji، Google — HSTS، 2015 (منقول)

• “With HSTS implemented, Googlebot sees a 301 redirect (try it with Fetch as Google). The 307 is just an ‘internal redirect’.” (ترجمة) «مع تطبيق HSTS، يرى Googlebot إعادة توجيه 301 (جرّبها باستخدام Fetch as Google). و307 مجرد «إعادة توجيه داخلية».» — Zineb Ait Bahajji (Google)، عبر Twitter، كما نقلها Search Engine Roundtable (ديسمبر 2015). الانتقال إلى الاقتباس

أي 307 أراها فعلًا؟

كل سؤال تقريبًا عن 307 ينتهي إلى واحد من شيئين مختلفين تمامًا. اتبع المسار خطوةً خطوة.

خرافات وأخطاء ينبغي تجنبها

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

«وجود 307 في تبويب Network يعني أن خادمي أساء إعداد إعادة التوجيه». غالبًا خطأ. إذا كان HSTS مفعّلًا ورأى المتصفح رأس Strict-Transport-Security من قبل، فإنه يعرض ترقية http→https على أنها 307 كتفسير داخلي منه — والخادم لم يعدها قط (والجسم بحجم 0 بايت هو العلامة). عادةً ما تعرض جلسة تصفح خاصة جديدة الرمز الحقيقي، لكن ليس للنطاقات الموجودة في قائمة HSTS المسبقة في المتصفح — فاختبر هذه الحالة بأداة فحص إعادة التوجيه أو curl (من دون إعداد HSTS) قبل البحث عن سوء إعداد غير موجود.

«يرى Googlebot 307 نفسها التي يعرضها متصفحي في موقع يستخدم HSTS». ليس تمامًا. قالت ممثلو Google إن Googlebot إما يرى 301 (Zineb، 2015) أو لا يتفاعل مع آلية 307/HSTS أصلًا (Mueller، 2020). وفي كلتا الحالتين ليست «307» التي يراها الإنسان. وما زلت تحتاج إلى 301 حقيقية من الخادم لـhttp→https إذا كان اكتشاف الزواحف لهذا المسار مهمًا.

«303 و307 متشابهتان أساسًا». هما متضادتان على المحور الوحيد المهم. فـ303 تغير دائمًا الطريقة إلى GET (نمط Post/Redirect/Get)، بينما تضمن 307 ألا تتغير الطريقة. ويسهل الخلط بينهما فقط لأن كلتيهما في فئة «المؤقتة» إلى جانب 302.

«بدّل كل عمليات التوجيه المؤقتة إلى 307 لتحصل على دفعة في الترتيب». لا توجد دفعة. السبب الصحيح الوحيد لتفضيل 307 على 302 هو حفظ الطريقة/الجسم فعليًا (أو تحصين المستقبل عمومًا). تحويل كل 302 إلى 307 لا يمنحك شيئًا، وقد يدخل أخطاء.

«302 تحول POST دائمًا إلى GET، لذا فهي معطلة جوهريًا للنماذج». هذا مبالغة. كان تحويل POST→GET مشكلة حقيقية مع العملاء الأقدم غير المتسقين — ولهذا وجدت 307 بوصفها الخيار المضمون — لكن المتصفحات الحديثة أكثر اتساقًا بكثير. تزيل 307 الغموض بالمواصفة بدل الاعتماد على سلوك العميل الحالي؛ ولا يعني ذلك أن 302 «معطلة».

شاهد رمز الحالة الحقيقي (لا أثر HSTS)

يخفي المتصفح 301/302 حقيقية خلف 307 شبحية بعد تخزين HSTS. ولا يطبق curl HSTS افتراضيًا، لذلك يتحدث الطلب العادي مباشرةً إلى الخادم ويعرض الحقيقة — فقط لا تشغله مع ملف cache مضبوط لـ--hsts، وإلا أعدت إدخال إعادة الكتابة من جهة العميل التي تحاول استبعادها.

تتبّع سلسلة إعادة التوجيه كاملةً، مع الرؤوس فقط

# -s silent, -I headers-only, -L follow redirects, cap the hops
curl -sIL --max-redirs 10 http://example.com/old-page 2>&1 \
  | grep -Ei '^(HTTP/|location:)'
# Each "HTTP/…" line is one hop's real status code; each "location:" is where it points.
# An HSTS "307" never appears here — it's browser-only.

تحقق من رمز حالة عنوان واحد من دون اتباعه

curl -s -o /dev/null -w "%{http_code}\n" http://example.com/old-page

وحدة تحكم Chrome DevTools — اكتشف 307 الشبح

ألصق النص في تبويب Console. تكشف إعادة توجيه حقيقية من الخادم علامة redirected وعنوان URL محلولًا؛ أما ترقية HSTS فتحدث قبل أن يغادر الطلب المتصفح أصلًا.

// Fetch and report what the network actually did.
fetch("http://example.com/old-page", { redirect: "manual" })
  .then(r => console.log("type:", r.type, "status:", r.status, "url:", r.url))
  .catch(e => console.log("blocked before request (often HSTS upgrade):", e.message));

يمكنك أيضًا قراءة سجل HSTS الخاص بـChrome مباشرةً على chrome://net-internals/#hsts — استعلم عن نطاق لترى هل يفرض static_upgrade_mode/dynamic_upgrade_mode استخدام https (وهو ما ينتج 307 التي تراها في تبويب Network).

Bookmarklet — لمحة سريعة عن رؤوس التبويب الحالي

اسحب إشارة مرجعية يكون هذا عنوانها، ثم انقرها في أي صفحة لتسجيل حالة عنوان URL الحالي وحالة إعادة التوجيه في Console:

javascript:(function(){fetch(location.href,{redirect:"manual"}).then(function(r){console.log("[status]",r.status,"[type]",r.type,"[redirected]",r.redirected,"[url]",r.url);}).catch(function(e){console.log("[error]",e.message);});})();

ملاحظة: لا يستطيع fetch() في المتصفح قراءة أجسام إعادة التوجيه المعتمة عبر أصل مختلف، لذلك يظل curl -sIL أعلاه هو المرجع في تتبع القفزات المتعددة.

إعادة 307 حقيقية

الفكرة من إعادة 307 (بدل ترك إطار العمل يضبطها افتراضيًا) هي ضمان بقاء الطريقة والجسم. إليك بعض الطرق الشائعة لإجرائها صراحةً.

Apache (.htaccess)

# mod_rewrite with an explicit 307 (R=307). Preserves POST body.
RewriteEngine On
RewriteRule ^old-endpoint$ https://example.com/new-endpoint [R=307,L]

nginx

# 307 keeps the method; 302 would risk POST→GET on older clients.
location = /old-endpoint {
    return 307 https://example.com/new-endpoint;
}

Node / Express

app.post("/old-endpoint", (req, res) => {
  // res.redirect defaults to 302; pass 307 to preserve the POST + body.
  res.redirect(307, "https://example.com/new-endpoint");
});

Next.js (App Router) — 307 هي الافتراضية، لذلك لا تكتب الشيفرة غالبًا

import { redirect } from "next/navigation";
// redirect() returns a 307 by default (303 inside a Server Action),
// preserving the request as a POST. Use permanentRedirect() for a 308.
export default function Page() {
  redirect("/new-endpoint");
}

كيف تبدو استجابة 307 الخام

HTTP/1.1 307 Temporary Redirect
Location: https://example.com/new-endpoint
Content-Length: 0

كيف تبدو «307 الشبح» في HSTS (داخل المتصفح فقط)

السطر نفسه في أدوات المطور، لكن لاحظ العلامات الكاشفة — مصدره المتصفح لا الخادم، ويحمل جسمًا بحجم 0 بايت:

HTTP/1.1 307 Internal Redirect
Location: https://example.com/old-page
Non-Authoritative-Reason: HSTS

إذا رأيت Non-Authoritative-Reason: HSTS (في Chrome)، أو «307» بحجم 0 بايت تختفي عند الاختبار بعميل لا يطبق HSTS، فهذه هي الأثر — وليست إعادة توجيه أرسلها خادمك. اسم الرأس الدقيق ووسم DevTools تفاصيل تنفيذ خاصة بـChrome وليسا ضمانًا في مواصفة HTTP أو HSTS، لذا تعامل معهما كأمثلة توضيحية لا كأساس لأتمتة تعمل عبر المتصفحات أو الإصدارات.

الطريقة والمدة وإطار العمل المصدر

أقيّم 307 على ثلاثة محاور قبل تغييرها:

1. الطريقة: هل يجب أن يتلقى الهدف الطريقة الأصلية وجسم الطلب؟ إذا نعم، فـ307 هي إعادة التوجيه المؤقتة التي تحفظ كليهما. أما صفحة عادية تنتقل إلى صفحة أخرى بـGET فلا تحتاج عادةً إلى هذه الخاصية.
2. المدة: هل الانتقال مؤقت فعلًا؟ أبقِ 307 ما دام متوقعًا عودة العنوان الأصلي. الانتقال الدائم يحتاج قرار إعادة توجيه دائمًا، لا رمزًا مؤقتًا إلى أجل غير مسمى.
3. المصدر: هل أرسل الخادم 307، أم اختارها إطار العمل، أم صنع المتصفح ترقية HSTS داخلية؟ إن ظهور «Internal Redirect» في DevTools ليس قاعدة مصدر ينبغي إعادة كتابتها.

أدوات الفصل بين 307s الحقيقية والشبحية

• Redirect Checker: راقب الحالة التي يمكن للخادم إظهارها والوجهة وكل قفزة من دون الاعتماد على حالة HSTS في متصفح واحد.
• Redirect Chain Mapper: استخدم عرض كل قفزة عندما تكون 307 جزءًا من مسار إعادة توجيه أطول.
• HTTP Header Checker: افحص Location وStrict-Transport-Security وقارن القرائن بين edge والمصدر.
• curl: شغّل curl -I http://example.com/path خارج عرض HSTS الداخلي للمتصفح. اختبر حفظ POST فقط على نقطة نهاية آمنة تملكها.
• أدوات مطور المتصفح: تحقق هل يقول الإدخال «Internal Redirect» وهل يحمل نقلًا بحجم صفر بايت؛ فهذا يشير إلى ترقية HSTS أنشأها المتصفح.

تحقق من 307 بعد النشر

اختبار الحالة والوجهة

الاختبار: افحص المصدر بأداة Redirect Checker أو curl -I. النتيجة المتوقعة: 307 واحدة مع Location المقصودة. تفسير الفشل: غيّرت طبقة أخرى القاعدة أو الهدف. نافذة المراقبة: فورًا. مُشغّل التراجع: حلقة، أو وجهة مكسورة، أو ظهور اسم مضيف غير مقصود.

اختبار حفظ الطريقة

الاختبار: أرسل POST غير مؤذٍ إلى مسار اختبار مضبوط وافحص ما يتلقاه الهدف. النتيجة المتوقعة: يتلقى الهدف POST مع الجسم الأصلي. تفسير الفشل: حوّل وسيط الطريقة أو قدّم رمزًا آخر. نافذة المراقبة: فورًا. مُشغّل التراجع: فقدان نموذج أو webhook أو طلب دفع لطريقته أو جسمه.

اختبار فصل HSTS

الاختبار: قارن DevTools (أو جلسة تصفح خاصة جديدة) بطلب curl -I لا يملك cache لـHSTS. النتيجة المتوقعة: يمكن تمييز «Internal Redirect» في المتصفح عن استجابة الخادم الحقيقية، وما زال HTTP يحمل إعادة توجيه من جهة الخادم. تفسير الفشل: تحجب HSTS قاعدة مصدر مفقودة — تذكر أن النافذة الخاصة وحدها لا تكفي للنطاقات الموجودة في قائمة HSTS المسبقة للمتصفح، لأن هذه الحالة تستمر مستقلّةً عن سجل التصفح. نافذة المراقبة: فورًا. مُشغّل التراجع: أزال تغيير المصدر إعادة توجيه HTTP إلى HTTPS العاملة.

اختبر نفسك: 307 Temporary Redirect

خمسة أسئلة سريعة عن ماهية 307، وكيف تتعامل Google معها، وأثر HSTS. اختر إجابة لكل سؤال ثم تحقق منها.

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

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

• 11 نوعًا من إعادة التوجيه وتأثيرها في SEO — مصدر تعريف 307، وتحفظ HSTS، وترتيب التنفيذ المفضل لدي (307 / 302 / 303 أولًا).
• رموز حالة HTTP وتأثيرها في SEO — مقالي الذي يضم إدراجي 307 المختلفين: حالة إعادة التوجيه المؤقتة وحالة سياسة HSTS.
• الدليل المبتدئ إلى SEO التقني — موضع إعادة التوجيه في الصورة الأوسع.

محاضراتي

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

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

• John Mueller — HTTPS & HSTS: 301, 302, or 307? — أوضح شرح أولي لـ«307 الشبح» في HSTS («خادمك لا يعيد 307»).
• برنامج «ما وراء السجل»، الحلقة 51 — «حديث عن عمليات إعادة التوجيه» (ملف تفريغ) — Mueller وSplitt وسبب وجود 307/308 ولماذا «لا يهم الأمر حقًا بالنسبة إلى SEO».
• Google عن إعادة توجيه 307 وHSTS (Search Engine Journal) — تلخيص فيديو Mueller عن أن «إعادات التوجيه 307 ليست عمومًا حقيقية».
• هل يعامل Googlebot عمليات إعادة توجيه 307 كـ301؟ (Search Engine Roundtable) — تصريح Zineb Ait Bahajji عام 2015 حول ما يراه Googlebot مع HSTS.
• MDN — إعادة التوجيه المؤقتة 307 — المرجع التقني الأوثق لضمان الطريقة والجسم.
• دليل SEO لزحف HSTS وإعادات التوجيه 307 (Screaming Frog) — أفضل معالجة لإعدادات الزحف مع 307 الناتجة عن HSTS.
• Next.js — مرجع redirect() — لماذا يجعل إطار عمل كبير إعادة التوجيهات غير GET افتراضيًا 307.

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