اللغات

إعادة التوجيه 302

ما هي إعادة التوجيه 302 المؤقتة، ولماذا تسميها Google إشارة «ضعيفة» لمعالجة الهدف (لا طريقًا مسدودًا بلا قيمة كما تقول خرافات SEO)، ومتى توصي بها، وما الخطأ الوحيد الذي قد يكلفك الترتيب.

نُشر أول مرة: 2 يوليو 2026 · آخر تحديث: 22 أغسطس 2026 · Advanced
اللغات
AIمن تأليفAI v2
دليل واحد في هذه الصفحة

إعادة التوجيه 302 (رمز HTTP 302، «Found») مؤقتة: ترسل المستخدمين إلى عنوان جديد مع الإشارة إلى بقاء العنوان الأصلي في نتائج البحث. والدقة التي تخطئ فيها الأدلة: تسمي بنية زحف Google 302 إشارة ضعيفة إلى ضرورة معالجة الهدف، مقابل إشارة 301 القوية — وهذا منفصل عن مسار فهرسة البحث الذي لا يعدّ إعادة التوجيه المؤقتة إشارة تجعل الهدف canonical (فالضعيف ليس صفرًا، والمعالجة ليست canonical). وقد قالت Google إن 302 ما زالت تمرر إشارات الروابط، وإنها قد تُعامل كـ301 إذا طال أمدها، لكن لا يوجد جدول زمني منشور. وهي الاختيار الصحيح للحالات المؤقتة فعلًا — وتوصي Google بها لاختبارات A/B، إلى جانب التوجيه الجغرافي/بحسب الجهاز وصفحات الصيانة. والخطأ الحقيقي هو استخدام 302 لانتقال دائم، فيبقى العنوان القديم متصدرًا بدل الجديد مدة غير متوقعة.

الخلاصة — إعادة التوجيه 302 («Found») مؤقتة. وصياغة Google الدقيقة تمر بمرحلتين لا مرحلة واحدة: تسمي بنية الزحف 302 إشارة ضعيفة إلى ضرورة معالجة هدف إعادة التوجيه، مقابل إشارة قوية من 301؛ وبشكل منفصل تقول مسارات الفهرسة في البحث إنها لا تتعامل مع إعادة التوجيه المؤقتة كإشارة تجعل الهدف canonical (مع أن الهدف قد يُفهرس بإشارات أخرى). وغالبًا ما تُخلط آليتان: تمرير إشارات الروابط/PageRank (قال Mueller وIllyes إن ذلك ليس صفرًا مع 302، لكن هذا تصريح علني منهما لا قاعدة عالمية منشورة رسميًا) وتفضيل الفهرسة/الـcanonical (وهو الفرق الفعلي؛ فـ302 تقول لـGoogle أن يبقي عنوان المصدر مفهرسًا). وإذا بقيت 302 مدة طويلة فقد تنقلب — وهذا نمط لاحظه الممارسون لا آلية موثقة، ولا يوجد له جدول زمني منشور. وتوصي Google بـ302 بدل 301 لاختبار A/B. والخطأ الحقيقي الوحيد هو استخدام 302 لانتقال دائم؛ ولا تبنِ وجهة إعادة التوجيه من مدخلات مستخدم غير متحقق منها.

من «Moved Temporarily» إلى «Found» — لمحة تاريخية

وُلدت 302 غامضة. ففي HTTP/1.0 كان اسمها «Moved Temporarily»، وكانت المواصفة تقول إن على العملاء إعادة استخدام طريقة الطلب الأصلية عند اتباعها. لكن المتصفحات لم تلتزم عمليًا؛ فكثير منها كان يحوّل POST بصمت إلى GET عند اتباع إعادة التوجيه، خلافًا للمواصفة. وأقر HTTP/1.1 بالواقع فأعاد تسمية 302 إلى «Found» وأضاف بديلين لا لبس فيهما: 303 (See Other) الذي يبدّل دائمًا إلى GET، و307 (Temporary Redirect) الذي لا يغير الطريقة أبدًا. وما زالت المواصفة الحالية، RFC 9110 (2022)، تذكر أن العملاء قد يغيّرون POST إلى GET مع 302 — وهذا بالضبط سبب وجود 307 عندما يجب ألا تتغير الطريقة. وفي إعادة توجيه الصفحات العادية القائمة على GET (حالة استخدام SEO)، تتصرف 302 و307 بالطريقة نفسها أمام محركات البحث؛ ولا يهم فرق الحفاظ على الطريقة إلا مع إرسال النماذج واستدعاءات API. Evidence for this claim RFC 9110 defines 302 Found as a temporary move to another URI and notes that user agents may change POST to GET when following it. Scope: HTTP semantics for 302 responses. Confidence: high · Verified: IETF: RFC 9110 §15.4.3 — 302 Found

ولأغراض البحث، تجمع Google 302 (found) و303 (see other) و307 (temporary redirect) تحت «مؤقتة»، في مقابل 301 و308 تحت «دائمة».

القرار المختصر عند الاختيار بينها:

  • 302 — قد يغير العميل التالي POST إلى GET (RFC 9110). وهي مناسبة لإعادة توجيه صفحة عادية قائمة على GET، فتجنبها إن كنت لا تحتمل تغير الطريقة.
  • 307 — لا يغير الطريقة ولا يعيد إرسال طلب مختلف. استخدمه حين يجب إعادة إرسال نموذج أو استدعاء API مطابقًا لما أُرسل.
  • 303 — يشير عمدًا إلى مورد مختلف وغير مكافئ، يُجلب عادةً بـGET/HEAD — وهو نمط «أعد التوجيه بعد POST إلى صفحة تأكيد»، وليس بديلًا مماثلًا للطلب الأصلي.
  • التخزين المؤقت — لا تصبح 302 قابلة للتخزين حدسيًا لمجرد رمز حالتها (RFC 9111)؛ ولا تُخزَّن وتُعاد إلا إذا عيّنت توجيهات صريحة للنضارة أو التخزين. لا تفترض أن CDN أو المتصفح سيخزّن 302 عارية افتراضيًا.

إشارة ضعيفة مقابل إشارة قوية — كلمات Google الدقيقة

تجاوز الخرافة واقرأ لغة Google نفسها. ففي وثائق بنية الزحف تقول Google إن 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 إعادة التوجيه إشارة ضعيفة إلى ضرورة معالجة هدف إعادة التوجيه». Evidence for this claim Google's crawling-infrastructure documentation says crawlers follow a 302/303 and Google systems use it as a weak signal that the target should be processed; it also warns that product behavior can differ. Scope: product-specific crawl and processing handoff Confidence: high · Verified: How HTTP Status Codes Affect Google's Crawlers

صف 301 في الجدول نفسه مطابق، باستثناء كلمة واحدة — قوية:

“Google follows the redirect, and Google systems use the redirect as a strong signal that the redirect target should be processed.” (ترجمة) «تتبع Google إعادة التوجيه، وتستخدم أنظمة Google إعادة التوجيه إشارة قوية إلى ضرورة معالجة هدف إعادة التوجيه». Evidence for this claim Google's crawling-infrastructure documentation says crawlers follow a 302/303 and Google systems use it as a weak signal that the target should be processed; it also warns that product behavior can differ. Scope: product-specific crawl and processing handoff Confidence: high · Verified: How HTTP Status Codes Affect Google's Crawlers

«ضعيفة» لا تعني «صفرًا» — لكن من المهم أيضًا تحديد ما هو الضعيف. هنا نظامان مختلفان من Google يتحدثان عن مرحلتين مختلفتين، لا عن سلم واحد:

  • بنية الزحف (التي يصفها اقتباس «الإشارة الضعيفة») تتعلق بما إذا كان سيجري التعامل مع هدف إعادة التوجيه — أي هل يكلف زاحف Google نفسه بجلب الوجهة وفحصها.
  • مسار الفهرسة في البحث مرحلة لاحقة مستقلة، وله قاعدته المباشرة: “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical. The target page might still be indexed if other canonicalization signals are present.” (ترجمة) «يتبع Googlebot إعادة التوجيه، لكن مسار الفهرسة لا يستخدمها إشارة إلى أن هدف إعادة التوجيه ينبغي أن يكون canonical. وقد تُفهرس الصفحة الهدف إذا وُجدت إشارات canonical أخرى». Evidence for this claim Google follows a 302 temporary redirect but does not use it as a signal that the destination should become canonical; Google recommends 302 rather than 301 for temporary site tests. Scope: Google Search handling of temporary redirects and A/B tests. Confidence: high · Verified: Google: Redirects and Google Search Google: Website testing

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

آليتان لا آلية واحدة

هنا تخلط معظم مواد المنافسين بين أسئلة منفصلة، لذا أبقهما منفصلتين:

  1. تمرير إشارات الروابط / PageRank ليس صفرًا مع 302. قال Gary Illyes في 2016 إن Google لم تعد تطبق تخفيف PageRank عبر إعادة توجيه 301 أو 302 أو غيرها من 30x (متخلية عن خرافة «نحو 15% خسارة في كل قفزة»)، وأكد Mueller النقطة نفسها بخصوص 302: “do work the same as normal redirects… It’s not that they don’t pass any PageRank or anything like that.” (ترجمة) «إنها تعمل مثل عمليات إعادة التوجيه العادية… ليس صحيحًا أنها لا تمرر أي PageRank أو ما شابه». اعتبر هذا تصريح Google العلني في المسألة، لا ضمانًا عالميًا منشورًا رسميًا؛ فوثائقها الأولية الحالية لا تحدد قاعدة دقيقة لانتقال إشارات الروابط في كل نوع من إعادة التوجيه وكل حالة.
  2. تفضيل canonical / الفهرسة هو الآلية التي تختلف فعلًا. 301 إشارة قوية لفهرسة الوجهة، أما 302 فإشارتها ضعيفة، ولذلك يبقى الإعداد الافتراضي لدى Google هو فهرسة المصدر.

«هل تمرر 302 PageRank؟» و«هل تغير 302 العنوان الذي يتصدر؟» سؤالان مختلفان. جواب الأول نعم؛ وجواب الثاني «ليس افتراضيًا». الخلط بينهما هو أصل خرافة «302 = لا قيمة».

وبالمثل، عندما تعيد توجيه عنوان URL، تتعقب Google الطرفين. “Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical; which one, depends on signals such as whether the redirect was temporary or permanent. The other URL becomes an alternate name of the canonical URL.” (ترجمة) «تتعقب Google مصدر إعادة التوجيه (العنوان القديم) وهدفها (العنوان الجديد). سيكون أحد العنوانين هو canonical، ويتوقف تحديده على إشارات مثل كون إعادة التوجيه مؤقتة أو دائمة. ويصبح العنوان الآخر اسمًا بديلًا للـcanonical». وفي 302 يبقى المصدر canonical — في الوقت الحالي.

Evidence for this claim A 302 expresses temporary intent, but it does not guarantee that the source URL will always remain Google's selected canonical or that the target cannot index through other signals. Scope: redirect crawling, indexing, and canonicalization Confidence: high · Verified: Redirects and Google Search

ماذا يحدث إذا بقيت 302 مدة أطول من اللازم — «الانقلاب»

هذا هو الجزء الذي يفاجئ الناس: قد تتوقف إعادة التوجيه المؤقتة التي لم تُزل قط عن معاملتها كمؤقتة. يقول Mueller: “if you have 302 redirects for the long run, we treat them exactly the same as 301 redirects anyway.” (ترجمة) «إذا كانت لديك عمليات إعادة توجيه 302 على المدى الطويل، فسنتعامل معها في النهاية تمامًا مثل عمليات 301».

لماذا يحدث ذلك؟ هذا تفسير عملي أقدمه أنا من دليلي عن canonicalization لدى Ahrefs — نموذج ذهني لممارس مبني على سلوك ملاحظ، لا آلية نشرتها Google رسميًا — فتخيله كميزان يميل. ترسل إعادة التوجيه الدائمة الإشارات إلى الأمام نحو العنوان الجديد؛ وترسل المؤقتة الإشارات إلى الخلف نحو العنوان الأصلي. لكن:

“If a temporary redirect is left in place long enough or the URL it’s redirected to already exists, it may be treated as a permanent redirect and send signals forward instead. It requires enough signals to flip the scale we saw earlier for canonicalization signals. As links build up, internal links are changed, sitemap URLs are updated, etc., more signals point to the new URL than the old URL, and the flip occurs.” (ترجمة) «إذا تُركت إعادة توجيه مؤقتة مدة كافية، أو كان العنوان الذي تُوجّه إليه موجودًا أصلًا، فقد تُعامل كإعادة توجيه دائمة وترسل الإشارات إلى الأمام بدلًا من ذلك. ويلزم عدد كافٍ من الإشارات لقلب الميزان الذي رأيناه مع إشارات canonicalization. ومع تراكم الروابط وتغيير الروابط الداخلية وتحديث عناوين sitemap، تشير إشارات أكثر إلى العنوان الجديد من القديم، فيحدث الانقلاب».

المشكلة أن لا أحد يعرف المدة اللازمة. وكما كتبت في دليلي عن إعادة التوجيه، “Nobody knows how long a 302 redirect has to exist before Google starts treating it as a 301 redirect. Usually, it’s a few weeks to a few months, but it can be days, weeks, or months.” (ترجمة) «لا أحد يعرف كم يجب أن تبقى إعادة توجيه 302 قبل أن تبدأ Google بمعاملتها كإعادة 301. عادةً بضعة أسابيع إلى بضعة أشهر، لكنها قد تكون أيامًا أو أسابيع أو أشهر». وقد تتصرف Google أسرع إذا ظنت أنك أخطأت: “Only if Google thinks you used a 302 redirect by mistake for a permanent move does this not happen. In that case, it treats the redirect as a 301… In some circumstances, Google even appears to treat 302s as 301s from the get-go.” (ترجمة) «لا يحدث ذلك فقط إذا اعتقدت Google أنك استخدمت 302 خطأً في انتقال دائم؛ عندها تعامل إعادة التوجيه كـ301… وفي بعض الظروف يبدو أن Google تعامل 302 كـ301 منذ البداية». لا تذكر عدد أيام محددًا — فلا يوجد رقم منشور، وأي رقم تراه (ومن ذلك «يومان» المتداول في أساطير Bing) لم تؤكده Google.

كيف تتعامل Bing مع 302 — تراقب السلوك لا الرأس فقط

تصل Bing إلى النتيجة نفسها عبر طريق مختلف قليلًا، وقد قالت ذلك صراحة. ففي شرحها الراسخ لإعادة التوجيه تصف Bing مراقبة النمط الملحوظ عبر عمليات زحف متكررة بدل الوثوق برمز الحالة وحده: عمليات إعادة التوجيه التي تغير وجهتها باستمرار تُعامل أقرب إلى 302 حتى إن وُسمت 301، والتي تشير دائمًا إلى المكان نفسه تُعامل أقرب إلى 301 حتى إن وُسمت 302 — إذ يبدأ نظام Bing «بالتفكير فيها كأنها 301 أكثر مع استمرارنا في زحفها مرارًا وتكرارًا». وهذا هو التقارب نفسه الذي تصفه Google، وقد توصل إليه المحركان مستقلين: عندما يستمر السلوك المتسق مدة كافية، تثق المحركات بما تفعله إعادة التوجيه أكثر مما تدعيه في رأسها.

كانت إرشادات Bing الأقدم أكثر تشددًا من Google الحالية في قولها «استخدم 302 بحذر»، وتحذر من أن إساءة استخدامها قد تترك القيمة عالقة في العناوين الأصلية. والخلاصة العملية مطابقة لخلاصة Google: طابق نوع إعادة التوجيه مع نيتك الفعلية.

متى تكون 302 هي الاختيار الصحيح

لا تكتفي Google بتحمل إعادة التوجيه المؤقتة — بل توصي بها في حالة استخدام واحدة. ذلك في إرشادات اختبار A/B:

“If you’re running a test that redirects users from the original URL to a variation URL, use a 302 (temporary) redirect, not a 301 (permanent) redirect. This tells search engines that this redirect is temporary—it will only be in place as long as you’re running the experiment—and that they should keep the original URL in their index rather than replacing it with the target of the redirect (the test page). JavaScript-based redirects are also fine.” (ترجمة) «إذا كنت تجري اختبارًا يعيد توجيه المستخدمين من العنوان الأصلي إلى عنوان نسخة مختلفة، فاستخدم إعادة توجيه 302 (مؤقتة)، لا 301 (دائمة). فهذا يخبر محركات البحث أن إعادة التوجيه مؤقتة — وستظل قائمة ما دام الاختبار جاريًا — وأن عليها إبقاء العنوان الأصلي في الفهرس بدل استبداله بهدف إعادة التوجيه (صفحة الاختبار). وإعادة التوجيه المعتمدة على JavaScript مقبولة أيضًا».

حالات الاستخدام المشروعة (وجميعها مؤقتة فعلًا):

  • اختبار A/B — توصية Google الصريحة أعلاه. لكن لا تطله أكثر من اللازم: تحذر Google من أنه «إذا اكتشفنا موقعًا يشغّل تجربة مدة طويلة بلا داعٍ، فقد نفسر ذلك محاولة لخداع محركات البحث». شغّله بقدر ما يلزم للوصول إلى دلالة إحصائية، ثم أزله.
  • التوجيه الجغرافي وتوجيه الجهاز واللغة — عندما تعتمد الوجهة «المناسبة» على الزائر، ولا ينبغي لعنوان واحد أن يحل محل المصدر نهائيًا. ولا يكفي هنا اختيار رمز الحالة: تحقق مما يتلقاه Googlebot نفسه (فعادةً لا يحمل إشارات الموقع أو الجهاز الحقيقية للزائر، فتحقق مما تقدمه القاعدة له)، وهل يعتمد التوجيه على ملفات تعريف الارتباط أو الرؤوس التي لا يرسلها الزاحف، وهل تفصل مفاتيح التخزين المؤقت ورأس Vary النسخ على نحو صحيح (حتى لا يقدّم cache صفحة بلد إلى بلد آخر)، وهل يستطيع قارئ الشاشة أو زائر بلا JavaScript الوصول إلى المحتوى، وهل يستطيع الزائر تجاوز التوجيه التلقائي كي لا يعلق في حلقة. واربطه بـhreflang صحيح للنسخ المترجمة — ينبغي أن يتفقا لا أن يتعارضا.
  • صفحات الصيانة أو عدم توافر الخدمة مؤقتًا — مثال Google نفسه: «إذا كانت خدمة يقدمها موقعك غير متاحة مؤقتًا، يمكنك إعداد إعادة توجيه مؤقتة لإرسال المستخدمين إلى صفحة تشرح ما يحدث، من دون الإضرار بالعنوان الأصلي في نتائج البحث». ميّز بين حالتين. إذا كان العنوان نفسه لا يمكن تقديمه الآن (الخادم الخلفي متوقف أو أنت في أثناء نشر)، فقد يكون رد 503 Service Unavailable مع رأس Retry-After على العنوان نفسه أدق؛ فهو يقول «لا يمكن تلبية الطلب مؤقتًا، حاول لاحقًا» دون تحويل إلى مكان آخر. استخدم 302 عندما توجّه عمدًا إلى صفحة شرح مختلفة ومفيدة فعلًا (صفحة حالة أو صفحة «سنعود» بتفاصيل إضافية)، لا لمجرد وسم العنوان الأصلي بأنه غير متاح.
  • عروض محددة المدة — أرسل الزوار إلى صفحة الحملة طوال مدتها، ثم عد إلى الوضع السابق.
  • موازنة الحمل / التحويل الاحتياطي — وجّه الحركة إلى مكان آخر عندما يصبح الأصل أو مركز البيانات غير متاح مؤقتًا.

راجع تبويب Examples للأمثلة المشروحة جنبًا إلى جنب، وتبويب Checklists لفحص ما قبل الإطلاق.

الخطأ الحقيقي الوحيد

استخدام 302 عندما تقصد انتقالًا دائمًا. فأنت تقول لـGoogle أن تبقي العنوان القديم مفهرسًا، وقد لا تحل الصفحة الجديدة التي تريدها أن تتصدر محله فترة غير محددة وغير متوقعة — تكلفة حقيقية في الظهور، لا احتمالًا نظريًا. إذا اختفت الصفحة نهائيًا فاستخدم 301 (أو 308). ومن الأخطاء الشقيقة خلط 301 و302 بلا اتساق داخل سلسلة إعادة التوجيه، وكذلك — وهو فشل أي إعادة توجيه — توجيه عنوانين إلى بعضهما وإنشاء حلقة.

تنفيذ إعادة توجيه 302

الرأس هو المهم — سطر الحالة 302 Found مع Location. وهذا مثال PHP من Google:

header('HTTP/1.1 302 Found');
header('Location: https://www.example.com/newurl');
exit();

Apache (ملف .htaccess) — راية R=302 هي التي تجعلها مؤقتة (أما R=301 أو R المجردة فستجعلها دائمة افتراضيًا):

Redirect 302 /old-path https://www.example.com/newurl
# or with mod_rewrite:
RewriteRule ^old-path/?$ https://www.example.com/newurl [R=302,L]

nginx — تعطي redirect إعادة توجيه 302 (أما permanent فتعطي 301):

location = /old-path {
    return 302 https://www.example.com/newurl;
}

أيًا كانت المنصة (إضافات إعادة التوجيه في WordPress، أو قاعدة CDN/edge، أو معالج على مستوى التطبيق)، فالقاعدة واحدة: يُفضل أن تكون إعادة التوجيه من الخادم، ويجب اختيار الرمز المؤقت عمدًا — فمعظم الأدوات تضبط 301 افتراضيًا، لذلك تكون 302 عادةً إعدادًا صريحًا.

ملاحظة أمنية تنطبق على أي إعادة توجيه: إذا بُنيت الوجهة في رأس Location من مدخل يتحكم فيه المستخدم (مثل معامل استعلام ?next= أو ?returnUrl=)، فقد صنعت مقومات إعادة توجيه مفتوحة — إذ يستطيع المهاجم إنشاء رابط على نطاقك يقفز بالزائر فعليًا إلى مكان خبيث. لا ترسل الزوار إلى أي عنوان يظهر في معامل الطلب؛ اسمح فقط بالوجهات التي ستعيد التوجيه إليها فعلًا (مجموعة ثابتة من المسارات أو الأصول الآمنة المعروفة)، واختبر كيفية تعامل منطقك مع المدخلات المشفرة والمدخلات النسبية إلى المخطط (//evil.example و%2F%2Fevil.example والحيل المشابهة) قبل الوثوق به في الإنتاج. راجع صياغة المقتطف الخاصة بكل منصة مقابل إصدارها الحالي قبل النشر — فالأمثلة أعلاه توضيحية وليست بديلًا عن الاختبار على خادمك أو CDN.

للاطلاع على النظير الخاص بالانتقال الدائم والمقارنة الكاملة، راجع المقالات الشقيقة عن إعادة التوجيه 301، و301 مقابل 302، و302 مقابل 307 في هذه المجموعة.

Try it live

This is a real endpoint on this site — not a simulation. Hit it from the button, open it in a new tab, or curl -i it from your terminal, and the server answers with the actual status code this article is about.

Open in new tab ↗

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.