301 أم 302 إعادة التوجيه؟ الإجابة الصحيحة في 30 ثانية

قراءة في 8 دقائق · آخر تحديث 2 مايو 2026

اسمع، لا تقرأ

اسمع، لا تقرأ

"إجابة في 90 ثانية"

0:00

0:00

1x

الخلاصة السريعة

تنقل صفحة إلى الأبد؟ استخدم 301. بشكل مؤقت فقط؟ استخدم 302. هذه القاعدة الواحدة تغطي تسعة من كل عشرة قرارات إعادة توجيه ستتخذها في حياتك. (أما الحالة الأخرى، لنقاط نهاية API حيث لا يمكن لنوع الطلب أن يتغير أثناء النقل، فتستخدم 307 أو 308. معظم الناس لا يقتربون منها أبدًا.)

تريد معرفة ما هو فعلاً قيد التشغيل على موقعك؟ هناك فحص من سطر واحد يكشف الكود الذي يرسله خادمك. إذا قال 302 وكان النقل من المفترض أن يكون دائمًا، فإن ترتيبك ينزلق الآن في الوقت الفعلي. سنرشدك خلال الفحص أدناه، دون الحاجة إلى أي معرفة بسطر الأوامر.

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

الساعة الحادية عشرة ليلاً. أنت في الأسبوع الثالث من عملية الترحيل، وانخفضت الزيارات العضوية بنسبة 40%. فريق التطوير يقسم أن إعادات التوجيه سليمة. Search Console يبدو طبيعيًا. لكن الخط على مخطط التحليلات يستمر في الهبوط، وأنت تواصل تحديثه وكأن الأرقام قد تخبرك بقصة مختلفة.

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

الإصلاح عادةً سطر واحد من الكود. الجزء الصعب هو اكتشاف المشكلة من الأساس.

هذا الدليل يأخذك عبر القصة كاملة. القاعدة البسيطة لاختيار إعادة التوجيه الصحيحة (إنها فعلاً مجرد سؤالين). كود جاهز للصق مهما كانت منصة موقعك (WordPress، Shopify، Next.js، Apache، Nginx، وكل ما سواها). الشيء الدقيق الذي يجب فحصه داخل Google Search Console بعد ذلك لإثبات نجاح الإصلاح. وإذا كان خطأ شخص آخر قد وقع بين يديك، فهناك دليل استرداد من أربع خطوات ينتظرك في النهاية.

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

الإجابة في 30 ثانية

تنقل صفحة إلى الأبد؟ استخدم 301. مجرد غياب لفترة قصيرة؟ استخدم 302. الحالة الأخرى الوحيدة التي تستحق المعرفة هي نقاط نهاية واجهة برمجة التطبيقات (API)، والتي تحتاج إلى 307 (مؤقت) أو 308 (دائم). ما لم تكن مطوراً يعمل مع واجهات برمجة التطبيقات، فعلى الأرجح لن تصادفها أبداً.

تلك القاعدة الواحدة تغطي 90% من القرارات. لماذا يهم الاختيار إلى هذا الحد؟ لأن كود إعادة التوجيه يؤدي وظيفتين في نفس الوقت. إنه يخبر محركات البحث ما إذا كان النقل دائماً أم مؤقتاً. ويخبر المتصفحات بهدوء ما إذا كان نوع الطلب (الـ GET، الـ POST، وما شابه) بحاجة إلى البقاء كما هو تماماً أثناء المرور. معظمنا يحتاج فقط إلى التفكير في الوظيفة الأولى.

في الأساس، تعمل كل عمليات إعادة التوجيه بنفس الطريقة. يطلب الزائر الرابط القديم. يرسل خادمك رسالة قصيرة تقول: هذه الصفحة انتقلت، وهذا عنوانها الجديد. الرقم في تلك الرسالة (301، 302، 307، 308) هو ما يخبر محركات البحث كيف تتعامل مع النقل.

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

هذا الجدول هو الإجابة القصيرة. بقية هذا الدليل يشرح ما يحدث فعلاً لترتيبك، وميزانية الزحف، والروابط المفهرسة عند اختيار أحدها على الآخر. سترى كوداً جاهزاً للصقّ لكل منصة رئيسية، والأدلة المسحوبة من بيانات زحف حقيقية ووثائق Google نفسها.

التعريفات: 301، 302، 307، 308، وترويسة Location

إليك التعريفات التي ستصادفها في بقية هذا الدليل. يستحق الأمر حفظها. ستعود إليها.

301 Moved Permanently: رمز حالة استجابة يُخبر المتصفح بأن المورد قد نُقل بشكل دائم إلى الرابط المحدد في ترويسة Location. تُمرِّر محركات البحث إشارات الترتيب إلى الرابط الجديد؛ والمتصفحات تخزّن هذا التحويل بقوة في الذاكرة المؤقتة.

302 Found: رمز حالة استجابة يُخبر المتصفح بأن المورد موجود مؤقتًا تحت رابط مختلف محدد في ترويسة Location. تُبقي محركات البحث الرابط الأصلي في الفهرس؛ والمتصفحات لا تخزّنه مؤقتًا بشكل افتراضي.

307 Temporary Redirect: مثل 302 لكن مع حفاظ صارم على طريقة الطلب. يجب على العميل إعادة الطلب بنفس الطريقة (POST يبقى POST). استخدمه عندما لا يمكن لعقد API تغيير الأفعال.

308 Permanent Redirect: مثل 301 لكن مع حفاظ صارم على طريقة الطلب. دائم وآمن للطريقة.

ترويسة Location: ترويسة استجابة HTTP التي تحمل رابط الوجهة لأي تحويل من فئة 3xx.

راجع أيضًا دليل الرابط الكانوني للآلية المرتبطة لكن المختلفة <link rel=canonical>. للمزيد من تفاصيل التنفيذ، تحتوي وثائق MDN حول تحويلات HTTP على ملاحظات جيدة حول السلوك الخاص بالمتصفح.

متى تستخدم 301 مقابل 302: قاعدة القرار

الأمر يتلخّص في سؤال واحد: هل النقل دائم أم مجرّد نقل مؤقت؟ الحالات أدناه تُخبرك في أيّ جانب أنت.

استخدم 301 عندما…

تنتقل إلى نطاق جديد بشكل نهائي. عندما يتحوّل oldbrand.com إلى newbrand.com ولا يوجد احتمال للعودة، استخدم 301. فهو يُخبر محركات البحث: انقل كلّ ما تعرفه عن النطاق القديم إلى الجديد، واحذف القديم من الفهرس.

تنتقل من HTTP إلى HTTPS. كلّ صفحة في موقعك تنتقل من النسخة غير الآمنة (تلك التي لا تحمل قفلًا في المتصفح) إلى النسخة الآمنة. هذا نقل دائم. الـ 301 يضمن أنّ المتصفحات ومحركات البحث تتعامل مع HTTPS باعتبارها النسخة الرسمية من الآن فصاعدًا.

تُعيد هيكلة روابط الـ URL. عندما يتحوّل /blog/post-1 إلى /posts/post-1 كجزء من إعادة ترتيب شاملة للموقع، فأنت لا تريد للمسار القديم أن يعود أبدًا. الـ 301 يُسلّم كلّ قوّة الترتيب إلى البنية الجديدة.

تدمج أو تُقلّص الصفحات. عندما تُوحّد صفحتين قصيرتين في صفحة واحدة أقوى، أعِد توجيه الرابط القديم بشكل دائم. الصفحة المدمجة تلتقط قوّة الترتيب للصفحتين معًا.

تُرسل صفحة محذوفة إلى فئتها الأم. بدلًا من إظهار “الصفحة غير موجودة” لمنتج تمّ إيقافه، أعِد التوجيه إلى صفحة الفئة الأم. الزوّار يصلون إلى مكان مفيد، وقوّة الترتيب تتدفّق إلى صفحة ذات صلة بدل أن تختفي.

تختار بين الوجود مع الشرطة المائلة أو بدونها. اختر إمّا /page أو /page/ وأعِد توجيه الآخر بشكل دائم. الاتساق يمنع Google من معاملتهما كصفحتين منفصلتين.

تختار بين www وغير www. اختر www.domain.com أو domain.com كنسختك الأساسية. أعِد توجيه الأخرى بـ 301 حتى تُكدّس محركات البحث كلّ إشاراتها على واحدة فقط.

ترحيل متجر إلكتروني (من Shopify إلى WooCommerce، أو من واجهة مخصّصة إلى Shopify Plus) هو واحد من أكبر مهام إعادة التوجيه 301 التي ستُنفّذها علامة تجارية. دليل الترحيل الكامل، بما في ذلك خريطة إعادة التوجيه التي تبنيها قبل إطلاق أيّ تغيير في الـ URL، موجود داخل منهجية Revenue Funnel SEO.

استخدم 302 عندما…

تُجري اختبار A/B. إذا كان نصف زيارتك يذهب إلى صفحة بديلة، فلا ينبغي لأيّ من النسختين أن تتولّى دور الرابط الأساسي خلال التجربة. الـ 302 يُخبر محركات البحث: الرابط الأصلي لا يزال هو المسؤول بينما نجمع البيانات.

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

لم تُعِدّ وسوم الدول بعد. هل تُرسل الزوّار من الهند إلى /in/ والزوّار من الولايات المتحدة إلى /us/؟ إذا لم تُضِف hreflang بعد، استخدم 302. (الـ hreflang هو الوسم الذي يُخبر Google بأيّ نسخة تُعرض في أيّ بلد.) يمنع Google من اختيار النسخة الإقليمية الخاطئة كرابط أساسي.

تُشغّل صفحة عروض ستختفي. صفحة Black Friday التي تختفي بعد الأول من ديسمبر يجب ألّا تمتصّ قوّة ترتيب صفحتك الرئيسية. الـ 302 يُبقي الرابط الأصلي هو الأساسي، وصفحة العرض تُوجد فقط من أجل الحملة.

تستخدم صفحة مؤقتة خلال عملية إعادة بناء. عندما تُعيد تصميم قسم من موقعك، فإنّ إعادة التوجيه المؤقتة إلى صفحة مؤقتة تُبقي مكانة الرابط الأصلي سليمة. بمجرّد إطلاق النسخة الجديدة، تُزيل إعادة التوجيه ويعود الرابط الأصلي ليتولّى الأمر من جديد.

حالات استثنائية لا تحسمها القواعد تمامًا

إعادة التوجيه بعد إتمام الشراء في سلّة التسوّق يجب من الناحية التقنية أن تستخدم 303 (تُخبر المتصفح: انسَ بيانات النموذج، فقط احضر هذه الصفحة). معظم المنصّات تُرسل 302 بدلًا منها، والمتصفحات تتعامل معها بالطريقة نفسها. عمليات نقل الـ API التي يُرسل العملاء فيها بيانات POST يجب في الواقع أن تستخدم 308 لتثبيت نوع الطلب. معظم الفرق تلجأ إلى 301 بدلًا منها. لقد نجح الأمر لعقد من الزمن ولم ينكسر شيء بعد. إعادة توجيه تسجيل الدخول عادةً ما تستخدم 302. الزائر ينتقل إلى صفحة تسجيل الدخول، ثمّ يعود بعد تسجيل الدخول.

ما الذي يحدث لتحسين محركات البحث لديك بعد الاختيار (واقع 2026)

اختيار الكود الصحيح ليس مجرد خانة تقنية تُعلَّم. بل يقرر بهدوء ثلاثة أشياء في وقت واحد. هل ستنقل Google قوة الترتيب إلى عنوان URL الجديد. وهل سيحل عنوان URL الجديد محل القديم في نتائج البحث. وهل ستهتم محركات البحث بالذكاء الاصطناعي مثل ChatGPT بالاستشهاد بك أصلًا. كلٌ منها يُغذّي التالي، وإصلاح الضرر لاحقًا يستغرق جهدًا أكبر من فعل ذلك بشكل صحيح من المرة الأولى.

نقل قوة الروابط (Link Equity)

قوة الروابط هي المِفصل الموضوعي بين فهم إعادة التوجيه وSEO خارج الصفحة. منهج السلطة المكتسبة (The Earned Authority Method) هو الإطار الذي يبنيها من الأساس. وهذا بالضبط سبب كون الحفاظ عليها عبر الاستخدام الصحيح لـ 301 يهم أكثر مما يُدركه معظم المُشغّلين.

الانقسام يهم أكثر شيء أثناء عمليات الترحيل. الموقع الذي ينتقل من HTTP إلى HTTPS بكود 302 لا يفقد القوة. بل يُفتّتها عبر متغيرات البروتوكول إلى الأبد.

ما يفعله فهرس Google مع كل منهما

Googlebot هو زاحف Google. يتعامل مع 301 و302 بشكل مختلف جدًا عند تخزين الصفحات في فهرسه. (الفهرس هو قاعدة البيانات الضخمة لكل صفحة تعرفها Google.)

الكود 301 يُخبر Google: استبدل العنوان القديم بالجديد. وعلى مدار الزيارات القليلة التالية تفعل Google ذلك بالضبط. عادةً خلال أسبوعين إلى 6 أسابيع لموقع نموذجي، وأسرع للمواقع الكبيرة التي تتفقدها Google أكثر. ويصبح العنوان الجديد هو الذي تعرضه Google في نتائج البحث. ويختفي القديم بهدوء.

الكود 302 يُخبر Google: أبقِ على العنوان القديم. وتستمر Google في عرض العنوان القديم كالعنوان الرئيسي في نتائج البحث. قد تُزار الصفحة الجديدة، لكنها لا تأخذ المكان أبدًا. تقرأ Google إعادة التوجيه كمسار تحويلي قصير المدى، لا كتغيير عنوان دائم.

Google Search Console (أداة Google المجانية لأصحاب المواقع) فيها ميزة اسمها URL Inspection تُسهّل عليك رؤية ذلك بنفسك. عنوان URL بكود 301 يُظهر في النهاية “URL is not on Google” مع السبب “Page with redirect”، ويظهر العنوان الجديد مُفهرسًا. أما عنوان URL بكود 302 فيتمسك بالأصلي كعنوان رئيسي مع علامة “Page with redirect”. والعنوان الجديد يبقى جالسًا هناك، ولا يُلتقط أبدًا.

بالنسبة لعمليات الترحيل، هذا يعني أن الكود 302 يُنشئ انقسامًا دائمًا بين عنوانَي URL ما لم تعد وتُصلح الكود.

البحث بالذكاء الاصطناعي وإعادة التوجيه: بيانات ChatGPT لعام 2025

وجدت دراسة من SE Ranking في ديسمبر 2025 شيئًا لافتًا. محركات البحث بالذكاء الاصطناعي (ChatGPT، Perplexity، نظرة عامة من الذكاء الاصطناعي من Google) تستشهد بعناوين URL المُعاد توجيهها أقل بكثير من Google العادي.

الأرقام تحكي القصة. 0.79% فقط من استشهادات ChatGPT تشير إلى عناوين URL تمر عبر إعادة توجيه، مقارنة بـ 5.75% في نتائج Google العادية. وهذا يعني أن ChatGPT يستشهد بعناوين URL المُعاد توجيهها بمعدل أقل 3 إلى 7 مرات من Google.

وهنا الجزء المُفاجئ. عندما يتبع ChatGPT إعادة توجيه، فإنه يُفضّل الدائمة بقوة. وجدت الدراسة نفسها أن ChatGPT يتبع 301 بمعدل 1.6 مرة أكثر من 302. وتُظهر Perplexity وميزات AI في Bing النمط نفسه. أنظمة البحث بالذكاء الاصطناعي تعامل إعادة التوجيه الدائمة كأكثر موثوقية من المؤقتة.

وما يعنيه ذلك لعملية الترحيل: كود 302 مُخبّأ في أي مكان في إعادة التوجيه يُقلّص بهدوء فرصك في أن يستشهد بك البحث بالذكاء الاصطناعي. تخسر على جبهتين في وقت واحد. البحث العادي من Google يُعامل عناوين URL الخاصة بك كمُجزّأة، و الموجة الجديدة من محركات البحث بالذكاء الاصطناعي تتوقف عن ذكرك في إجاباتها.

إذا كان كودك الخاطئ يجعل ChatGPT يتوقف عن الاستشهاد بمحتواك، فإن البحث المدفوع عليه أن يسدّ الفجوة. منهج الكمّاشة (The Pincer Method) هو بالضبط السبب في أننا نُدير الإعلانات المدفوعة والبحث العضوي من دليل لعب واحد. عندما يُسقِط البحث بالذكاء الاصطناعي قناة، فالأخرى عليها أن تلتقط الطلب.

كود جاهز للنسخ واللصق لسبع منصات

ابحث في Google عن “301 vs 302 redirect”، وستذكر أفضل النتائج سبع منصات دون أن تعرض لك الكود الفعلي الذي يجب استخدامه. إليك الكود. كل مقتطف أدناه جاهز للنسخ واللصق، تم التحقق منه وفق توثيق المنصات الحالي، واختباره لأكثر الأخطاء شيوعاً.

Apache (.htaccess)

في Apache، يوضع هذا الكود في ملف .htaccess داخل جذر المستندات.

# Single URL 301
Redirect 301 /old-url /new-url

# Pattern-based 301 (regex)
RedirectMatch 301 ^/old/(.*)$ /new/$1

# Domain change with HTTPS
RewriteEngine On
RewriteCond %{HTTP_HOST} ^oldbrand\.com$ [NC]
RewriteRule ^(.*)$ https://newbrand.com/$1 [R=301,L]

خطأ شائع: نسيان RewriteEngine On قبل استخدام RewriteRule. يفشل التوجيه بصمت بدونه، وستقضي عشرين دقيقة تتساءل لماذا لا يعمل شيء. نتناول المقارنة بالتفصيل في htaccess vs Nginx لقواعد إعادة التوجيه.

Nginx

في Nginx، يوضع هذا الكود في ملف إعداد كتلة الخادم (عادةً /etc/nginx/sites-available/yourdomain).

# Single URL 301
location = /old-url {
    return 301 /new-url;
}

# Domain change
server {
    listen 443 ssl;
    server_name oldbrand.com;
    return 301 https://newbrand.com$request_uri;
}

خطأ شائع: استخدام rewrite في حين أن return سيكون أسرع. تعمل return 301 قبل تقييم التعبير النمطي وتوفر على الخادم بعض الجهد. الشرح الكامل موجود في htaccess vs Nginx لقواعد إعادة التوجيه.

Cloudflare Workers + Page Rules

Page Rules (واجهة مستخدم، بدون كود): لوحة Cloudflare ← Rules ← Page Rules ← “Forwarding URL” ← اختر 301 أو 302 من القائمة المنسدلة. الخطط المجانية محدودة بثلاث قواعد Page Rules نشطة، وهذا يمتلئ بسرعة في المواقع التي لها احتياجات متعددة لإعادة التوجيه.

Workers (كود، أكثر مرونة):

export default {
  fetch(request) {
    const url = new URL(request.url);
    if (url.pathname === '/old-url') {
      return Response.redirect('https://example.com/new-url', 301);
    }
    return fetch(request);
  }
}

خطأ شائع: تكلف Workers 5 دولارات شهرياً لعشرة ملايين طلب، لكنها توفر لك قوة مطابقة أنماط لا يمكن لـ Page Rules مجاراتها. سنغطي حالات الاستخدام المتقدمة في أنماط إعادة التوجيه عبر Cloudflare Workers.

WordPress: RankMath PRO + إضافة Redirection + .htaccess يدوي

RankMath PRO: لوحة إدارة WordPress ← Rank Math ← Redirections ← Add New. اختر 301 أو 302 من القائمة المنسدلة، وأدخل عنوان المصدر والوجهة. التغييرات تصبح فعّالة فوراً، دون إعادة تشغيل الخادم.

إضافة Redirection (مجانية، من John Godley): Tools ← Redirection. الأفضل للترحيلات كبيرة الحجم. تدعم استيراد وتصدير CSV، وأنماط التعابير النمطية، وتتبع أخطاء 404. تسجّل الإضافة زيارات إعادة التوجيه، مما يساعدك على اكتشاف السلاسل أو الحلقات قبل أن تتراكم.

.htaccess يدوي: يعمل، لكنه لا يصمد أمام تحديثات الإضافات أو القوالب التي تعدّل .htaccess. استخدمه فقط للقواعد الدائمة على مستوى النظام التي يجب أن تبقى بغض النظر عن حالة WordPress.

إذا كنت تعمل على WordPress وتتعامل مع كل تغيير في إعادة التوجيه كجزء من محرك المحتوى الأكبر، فإن خطوة إعادة التوجيه هي مجرد حركة واحدة داخل المنهجية الأشمل. منهجية Content Compounder هي ما يشغّل ذلك المحرك. حلقة التغذية الراجعة ذات الركائز الست التي تستهلك إتقان إعادة التوجيه باعتباره بنية الركيزة الثانية. للمقارنات الخاصة بالإضافات، يتعمق دليل إضافات إعادة التوجيه في WordPress في معايير الاختيار.

WooCommerce + Shopify

WooCommerce: يستخدم أدوات إعادة التوجيه في WordPress أعلاه. ترحيل عناوين المنتجات بالجملة يحتاج إلى منطق لإزالة التكرار. متجر بـ 500 SKU قد يولّد 500 قاعدة إعادة توجيه تبطئ تحليل .htaccess. نغطي سير عمل إزالة التكرار في قسم الأخطاء الشائعة أدناه.

Shopify: Online Store ← Navigation ← URL Redirects. يدعم Shopify فقط 301 عبر لوحة الإدارة القياسية. لا يمكنك تكوين 302 دون Shopify Function مخصصة أو تطبيق طرف ثالث مثل Easy Redirects.

خطأ شائع: تصمد عمليات إعادة التوجيه في Shopify أمام تغييرات القالب، لكنها تنكسر في اللحظة التي تحذف فيها المنتج أو الصفحة المصدر. صدّر قائمة إعادة التوجيه الخاصة بك دائماً قبل أي تغيير هيكلي. Settings ← Files لن ينقذك هنا.

Next.js (next.config.js)

في Next.js، يوضع هذا الكود في ملف next.config.js في جذر المشروع.

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/old-url',
        destination: '/new-url',
        permanent: true, // permanent: true = 308; permanent: false = 307
      },
    ];
  },
};

خطأ شائع: يستخدم Next.js افتراضياً 307/308 (متغيرات الطريقة الصارمة)، وليس 301/302. إذا كنت تحتاج تحديداً إلى 301/302 لأن بعض أدوات SEO القديمة لا تتعرف على 308 بعد، استخدم statusCode: 301 بدلاً من permanent: true.

وسيط Express

في Express، يوضع هذا الكود في ملف الخادم الرئيسي (عادةً app.js أو server.js).

// Express
app.get('/old-url', (req, res) => {
  res.redirect(301, '/new-url');
});

// Pattern-based redirect
app.use('/old-section/*', (req, res) => {
  const newPath = req.originalUrl.replace('/old-section', '/new-section');
  res.redirect(301, newPath);
});

خطأ شائع: تعود res.redirect() افتراضياً إلى 302 إذا لم تمرر رمز حالة. كن صريحاً دائماً. عمليات 302 الضمنية هي السبب الأكثر شيوعاً لتذاكر الدعم التي تقول “أعددت إعادات التوجيه لكن ترتيبي انخفض”.

Vercel (vercel.json أو next.config.js)

في Vercel، توجد إعادات التوجيه في vercel.json في جذر المشروع، أو داخل next.config.js إذا كنت تستخدم Next.js (تم تناوله أعلاه).

{
  "redirects": [
    {
      "source": "/old-url",
      "destination": "/new-url",
      "permanent": true
    },
    {
      "source": "/old/:path*",
      "destination": "/new/:path*",
      "permanent": true
    }
  ]
}

خطأ شائع: مثل Next.js. permanent: true تعني 308، وpermanent: false تعني 307. إذا كنت تحتاج تحديداً إلى رموز الحالة 301/302، استخدم "statusCode": 301 بدلاً من "permanent".

Netlify (ملف _redirects)

في Netlify، توضع إعادات التوجيه في ملف _redirects داخل دليل النشر (أو public/).

# Single URL 301
/old-url    /new-url    301

# Wildcard
/old/*    /new/:splat    301

# Domain change (full URL on the right)
https://oldbrand.com/*    https://newbrand.com/:splat    301!

خطأ شائع: علامة ! النهائية (راية الإجبار) تجعل إعادة التوجيه تتجاوز الملفات الموجودة في الوجهة. بدونها، يقوم Netlify بإعادة التوجيه فقط عندما لا يتطابق المصدر مع ملف فعلي. مفيدة، لكن من السهل نسيانها.

AWS CloudFront (Functions أو Lambda@Edge)

في CloudFront، يمكن تشغيل إعادات التوجيه عبر CloudFront Function (أرخص وأبسط) أو Lambda@Edge (أقوى وأغلى). لمعظم أعمال إعادة التوجيه، Functions هو الخيار الصحيح.

function handler(event) {
  var request = event.request;
  if (request.uri === '/old-url') {
    return {
      statusCode: 301,
      statusDescription: 'Moved Permanently',
      headers: {
        location: { value: 'https://example.com/new-url' }
      }
    };
  }
  return request;
}

اربط الوظيفة بسلوك توزيع CloudFront بنوع الحدث viewer-request. وظائف CloudFront محدودة بـ 10 مللي ثانية من وقت التنفيذ وليس لها وصول للشبكة، لكنها مجانية لأول عشرة ملايين استدعاء شهرياً.

Caddy

في Caddy، توضع إعادات التوجيه في Caddyfile وهي بسيطة للغاية.

# Single URL 301
oldbrand.com {
    redir /old-url /new-url permanent
}

# Domain change with HTTPS preserved
oldbrand.com {
    redir https://newbrand.com{uri} 301
}

خطأ شائع: permanent في Caddy تعني 301. استخدم temporary للرمز 302. يتعامل Caddy تلقائياً مع HTTPS عبر Let’s Encrypt، لذا فإن إعادات توجيه النطاقات تتم عادةً بسطر واحد.

IIS (Windows Server، web.config)

في IIS، توجد إعادات التوجيه في ملف web.config الخاص بموقعك ضمن قسم <system.webServer>. يتطلب وحدة URL Rewrite (تنزيل مجاني من Microsoft).

<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Old URL 301" stopProcessing="true">
          <match url="^old-url$" />
          <action type="Redirect" url="/new-url" redirectType="Permanent" />
        </rule>
        <rule name="Domain change" stopProcessing="true">
          <match url=".*" />
          <conditions>
            <add input="{HTTP_HOST}" pattern="^oldbrand\.com$" />
          </conditions>
          <action type="Redirect" url="https://newbrand.com/{R:0}" redirectType="Permanent" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

خطأ شائع: redirectType="Permanent" تعني 301 في IIS. استخدم Found للرمز 302، وSeeOther للرمز 303، وTemporary للرمز 307. التسمية غير بديهية. يفترض كثير من المطورين أن Temporary تعني 302 ويشحنون الكود الخاطئ.

في منتصف ترحيل وتحتاج إلى عينين إضافيتين؟ أرسل لنا خريطة موقعك وملف .htaccess. سنجري تدقيقاً مجانياً لمدة 30 دقيقة في مكالمة. شاشتك، صوتنا، مخرجات curl حقيقية. بدون عرض تقديمي. بدون مقترح. رسوم دائمة تبدأ من ₹40,000 / $499 شهرياً عندما تريدنا أن نتولى العمل.

احجز مكالمة استراتيجية 30 دقيقة ← · واتساب +91 96366 50036

كيف تتحقق: لا تُصدِّق. أثبِت.

هناك ثلاث طرق للتحقق مما يفعله التحويل فعليًا. الأولى لا تحتاج أي أدوات خاصة. الثانية تستخدم ميزة مجانية مدمجة في Chrome. الثالثة تستخدم لوحة التحكم المجانية من Google. اختر ما يناسبك. جميعها تخبرك بالحقيقة.

curl -I، فحص السطر الواحد (للمطورين)

إذا لم تكن مطورًا، تخطَّ هذا إلى طريقة Browser DevTools أو Google Search Console أدناه. تعرض لك نفس المعلومات دون سطر الأوامر.

على أي جهاز كمبيوتر به طرفية (النافذة النصية بالأبيض والأسود التي يستخدمها المطورون)، شغِّل:

curl -I https://example.com/old-url

نموذج للمخرجات:

HTTP/2 301
date: Tue, 1 May 2026 09:00:00 GMT
location: https://example.com/new-url
cache-control: max-age=31536000

HTTP/2 301 يتوهج باللون الذهبي، رأس location يشير إلى الرابط الجديد، وقيمة cache-control max-age مُبرزة. لوحة ألوان العلامة التجارية كحلية وذهبية." loading="lazy" width="1600" height="900">

السطر الأول يخبرك بالحالة. 301 هنا. رأس location: يخبرك بوجهة التحويل: رابطك الجديد، تمامًا كما حددته. أما cache-control: max-age=31536000 (سنة واحدة بالثواني) فيخبرك أن التحويل يتم تخزينه مؤقتًا بقوة، وهو ما يتوافق مع التحويل الدائم. ستحترم المتصفحات وشبكات CDN هذا التوجيه وتتجاوز البحث في الزيارات المتكررة.

ملاحظة مهمة: بعض الخوادم تُرجع HTTP/1.1 بدلاً من HTTP/2. يظهر سطر الحالة بصيغة HTTP/1.1 301 Moved Permanently بدلاً من الصيغة الأقصر HTTP/2 301. السلوك متطابق. رقم الإصدار يعكس فقط ما يدعمه خادمك، لا صحة التحويل من عدمها.

علامة تبويب Network في أدوات مطوري المتصفح

افتح Chrome DevTools ← علامة تبويب Network ← فعِّل “Preserve log” ← حمِّل الرابط القديم مباشرة في شريط العنوان.

يعرض الطلب الأول الحالة 301 أو 302 في عمود Status. انقر على ذلك الصف لفحص رأس Location ورؤوس الاستجابة الكاملة في اللوحة اليمنى.

هذه الطريقة رائعة لرصد سلاسل التحويل بصريًا. كل قفزة تظهر كصف منفصل. إذا رأيت ثلاثة صفوف قبل الحالة النهائية 200، فلديك سلسلة تحتاج إلى تقليصها.

فحص URL في GSC، الفحص بعد النشر

Google Search Console ← URL Inspection ← ألصق الرابط القديم.

في حالة التحويل 301 الناجح، سترى “URL is not on Google” مع السبب “Page with redirect”. هذا يؤكد أن Google قد زحف إلى التحويل، وسجله، وبدأ في نقل السلطة إلى الوجهة.

بعد أسبوعين إلى ستة أسابيع، ألصق الرابط الجديد. ما تريد رؤيته: “URL is on Google” مع “Page is indexed” و”User-declared canonical”. هذا يؤكد اكتمال عملية التوحيد. الرابط الجديد يحمل الآن السلطة التي بناها الرابط القديم.

للاطلاع على المرجع الكامل لميزة URL Inspection، راجع توثيق Google لفحص الروابط.

هذه هي لقطة الشاشة التي ترسلها إلى عميلك لتثبت أن الترحيل نجح. ليس تصديرًا من Semrush. ليس تقريرًا من أداة مدفوعة. لوحة Google نفسها تقول إن الرابط موجود على Google. لا تُصدِّق لوحة التحكم. اقرأ الاستجابة.

إذا استخدمت بالفعل الكود الخاطئ: دليل الاستعادة

الاستعادة تتم في أربع خطوات صغيرة. ابحث عن الروابط المعطوبة. أصلح الكود. اطلب من Google العودة. انتظر. معظم الوقت الذي تقضيه هو مجرد انتظار. الإصلاح الفعلي سريع. تستغرق المهمة كاملةً عادةً من 2 إلى 6 أسابيع، والاستعجال في أي خطوة يجعل الانتظار أطول فقط.

كيف يبدو هذا عمليًا. في الربع الأخير ساعدنا علامة تجارية للعناية بالبشرة كانت قد نقلت للتو متجرها من Shopify إلى WooCommerce. استخدم مطوروها رموز 302 على كل رابط لأن إضافة الترحيل تعيّن “مؤقت” افتراضيًا دون تنبيه أحد. بحلول الأسبوع الرابع، انخفضت الزيارات العضوية بنسبة 38%. فحصنا 60 صفحة منتج، وأكّدنا أن كل إعادة توجيه كانت من النوع الخاطئ، وحوّلناها جميعًا إلى 301. ثم أعدنا إرسال خريطة الموقع وطلبنا من Google إعادة الزحف إلى أهم 12 صفحة من حيث الإيرادات. بعد ثمانية عشر يومًا، كانت الروابط الجديدة تظهر كالنسخة الأساسية، وعادت الزيارات إلى ما يقارب 4% من مستوى ما قبل الترحيل.

الأعراض

انخفضت التصنيفات بعد 2 إلى 6 أسابيع من الترحيل، والتوقيت متطابق بشكل لا يمكن أن يكون مصادفة. تُشير Google Search Console إلى “صفحة مع إعادة توجيه” لروابط يُفترض أنها باتت النسخة الرئيسية الجديدة. لا يزال Google يعامل الرابط القديم كالرابط الأساسي. يجعل البحث بالذكاء الاصطناعي الأمر أسوأ: يستمر ChatGPT وClaude وGemini في توجيه الناس إلى الروابط القديمة لأن بيانات تدريبها التقطت إشارة إعادة التوجيه المؤقتة. تظهر روابطك الجديدة بحضور ضعيف أو معدوم في Google رغم أنه قبِل خريطة موقعك دون أي اعتراض. تتذبذب الزيارات المباشرة إلى الروابط القديمة بشكل غير متوقع مع تذكّر المتصفحات والإشارات المرجعية للعنوان القديم، مرسلةً الزوار إلى حلقات إعادة توجيه أو صفحات قديمة.

التشخيص

اختر 20 إلى 50 من روابطك القديمة وافحص ما يُرسله الخادم فعليًا. (إن كنت مطورًا، استخدم curl -I. وإلا، افتح الرابط في Chrome مع أدوات المطور على علامة تبويب Network.) دوّن رمز الحالة الحقيقي، لا ما يقول نظام إدارة المحتوى إنه يُرسله. ثم مرِّر تلك الروابط نفسها عبر أداة فحص الروابط في Google Search Console. التباينات هي مواضع التسريب. ادرس إعدادات منصتك أو تهيئة الخادم لاكتشاف السبب الجذري. ثلاثة أسباب شائعة: إضافة إعادة توجيه مضبوطة على “مؤقت” افتراضيًا، أو استدعاء Express بدون رمز حالة صريح، أو إعادة توجيه Next.js مع permanent: false. سجّل أي سلاسل على حدة. سلسلة مثل A→B→C→D تُضيف مشكلة ثانية فوق مشكلة الكود الخاطئ.

الإصلاح

حوِّل كل إعداد ذي صلة إلى 301 (أو 308 إذا احتجت إلى تثبيت نوع الطلب لواجهة API) وانشر التغيير. تحقق من كل إصلاح بالطريقة نفسها التي اكتشفت بها المشكلة في الأساس، مؤكدًا ظهور 301. أعد إرسال خريطة موقعك إلى Google Search Console ليعرف Google أن شيئًا قد تغيّر. استخدم أداة فحص الروابط في GSC واضغط “طلب الفهرسة” على أهم روابط الوجهة. أعطِ الأولوية للصفحات التي تُدرّ إيرادات أو روابط خلفية. بالنسبة لعمليات إعادة التوجيه ذات الزيارات العالية جدًا، يمكنك تسريع Google بالربط مؤقتًا إلى الرابط الجديد من صفحتك الرئيسية. هذا الرابط الداخلي يدفع Google للعودة والفحص أسرع.

إعادة الفهرسة

الانتظار المعتاد هو 2 إلى 6 أسابيع حتى يحلّ الرابط الجديد محلّ القديم كالرابط الأساسي. أسرع على المواقع الأكبر التي يزورها Google كثيرًا. تتفاوت استعادة البحث بالذكاء الاصطناعي. يبدأ ChatGPT وGemini في الاستشهاد بالرابط الصحيح فور تحديث دورات تدريبهما. أما Perplexity ودردشة Bing فعادةً ما يلحقان خلال 1 إلى 2 أسبوعين بمجرد استقرار الرابط الجديد. للاطلاع على معايير محددة حول كم يستغرق Google لمعالجة إعادة توجيه 301، سننشر بيانات مفصّلة عن توقيت الزحف في منشور مستقبلي.

ورثت فوضى إعادة توجيه ولست متأكدًا من أين يحدث النزيف؟ الصق خريطة موقعك في تدقيق مجاني مدته 5 دقائق وسنُرسل لك قائمة بكل 301 و302 وسلسلة في رسم إعادة التوجيه لديك، إضافةً إلى تلك التي تُفقدك الفهرسة الآن. يتصل بنا معظم العملاء في الأسبوع الثالث من انخفاض زيارات غير مفسَّر. وفّر أسبوعين.

أرسل خريطة موقعك عبر واتساب ←

7 أخطاء تُكلّفك التصنيفات بهدوء

هذه الأخطاء السبعة نراها في كل تدقيق تقريبًا. كل خطأ يأتي مع طريقة سريعة لاكتشافه وطريقة سريعة لإصلاحه.

كيف يبدو هذا عمليًا. العام الماضي دقّقنا شركة برمجيات تستعد لجمع جولتها الاستثمارية الكبيرة الأولى. على مدى ست سنوات من تغييرات المنتج، تراكمت في تهيئة خادمها 4,200 قاعدة إعادة توجيه. وشكّلت 41 منها سلاسل بأربع قفزات أو أكثر. وكانت 6 منها حلقات حية تُدير الخادم في دوائر. اختصرنا كل سلسلة إلى إعادة توجيه بقفزة واحدة، وأنهينا الحلقات، وقلّصنا الإجمالي إلى 1,180. بدأت الصفحات تُحمَّل أسرع بـ 340 مللي ثانية. وبعد أسبوعين، عاد Google يزحف إلى مزيد من صفحات موقعها.

1. سلاسل إعادة التوجيه (A تذهب إلى B، وB إلى C، وC إلى D). يمكنك اكتشافها بتتبّع السلسلة كاملةً خطوة بخطوة. كل قفزة تفقد قدرًا صغيرًا من قوة الترتيب وتُضيف تأخيرًا. الإصلاح بإرسال A مباشرةً إلى D. يغطي دليل تصحيح سلاسل إعادة التوجيه العملية كاملةً خطوة بخطوة.

2. حلقات إعادة التوجيه. يُرجع الخادم أخطاء أو ينتهي متصفحك بسبب تكرار إعادة التوجيه في حلقة. الإصلاح بإزالة القاعدة التي تشير إلى رابط أسبق في السلسلة.

3. خلط 301 و302 في ترحيل واحد. بعض الصفحات حصلت على الكود الدائم، وأخرى على المؤقت، فيرى Google صورة غير متسقة. الإصلاح بفحص كل رابط في خريطة موقعك وتحويل كل قاعدة إلى 301.

4. نسيان أن /page و/page/ رابطان مختلفان. بوجود الشرطة المائلة في النهاية أو بدونها، يعاملهما Google كصفحتين منفصلتين. كلاهما يجب أن يُعيد التوجيه إلى الرابط نفسه، وإلا قسّمت قوة ترتيبك بين نسختين.

5. نسيان متغيرات http:// وwww.. لكل رابط أربع نسخ: مع https وبدونه، ومع www وبدونه. ثلاث منها يجب أن تُعيد التوجيه بـ 301 إلى نسخة رئيسية واحدة. ترك أي منها يُشتّت سلطتك عبر عناوين متعددة.

انفجار روابط المتغيرات هو نمط فشل مرتبط بـ WC تحديدًا. خمس سمات بثماني قيم لكل منها يمكن أن تُنتج 40,000 رابط قابل للفهرسة من منتج واحد. يغطي تحسين محركات البحث التقني الخاص بـ WooCommerce نمط إزالة تكرار روابط المتغيرات الذي يقع في الطابق الثالث من برج WC.

6. صفحات فارغة بعد إعادة التوجيه. رابط الوجهة يعمل، لكن الصفحة قصيرة أو فارغة تقريبًا. يعامل Google ذلك كـ “soft 404” (صفحة تُحمَّل تقنيًا لكنها تتصرف كصفحة مفقودة) ويُسقطها بهدوء. الإصلاح بالتأكد أن الوجهة تحتوي محتوى حقيقيًا ومفيدًا. يغطي دليل استعادة soft 404 مقدار المحتوى الكافي بالضبط.

7. إعادة توجيه الناس تلقائيًا بناءً على بلدهم. إرسال الزوار إلى صفحة مختلفة حسب موقع تصفّحهم، دون خيار للتراجع، يُخالف قواعد Google. الإصلاح حسب الطبقة الأولى من Multi-Region Authority Stack، التي تشرح الطريقة الصحيحة لتوجيه الناس حسب المنطقة.

إعادة التوجيه التلقائي بناءً على Geo-IP بدون خيار يدوي للتجاوز هو نمط يُنذر فريق البريد العشوائي في Google بخطر التخفّي. للتوجيه متعدد المناطق المنجز بشكل صحيح (hreflang، وبنية ccTLD، وقواعد Geo-IP في الطبقة الأولى التي لا تستخدم 302 بصمت)، راجع Multi-Region Authority Stack.

الأسئلة الشائعة

ما الفرق بين إعادة التوجيه 301 و 302؟

الـ 301 تُشير إلى نقل دائم. يستبدل Google الرابط القديم بالجديد كرابط قانوني (canonical). أما الـ 302 فتُشير إلى نقل مؤقت. يُبقي Google الرابط الأصلي كرابط قانوني. كلاهما ينقل قيمة الروابط وفق توثيق Google، لكن سلوك الفهرسة مختلف تمامًا. استخدم 301 عندما يكون النقل دائمًا. واستخدم 302 عندما تنوي التراجع.

هل تضرّ إعادة التوجيه 302 بالسيو؟

نعم. عند استخدامها بشكل خاطئ. استخدام 302 لنقل دائم يعني أن Google يُبقي الرابط المصدر كقانوني إلى أجل غير مسمى، فلا تبني الوجهة إشاراتها الترتيبية الخاصة. القيمة تنتقل في الحالتين (أكّد Mueller ذلك عام 2016) لكنها تنقسم بين الرابطين بدلًا من التجميع في الجديد. والنتيجة: لا يبني أيٌّ من الرابطين السلطة التي تحتاجها للترتيب على الاستعلامات الصعبة. الحل: التحويل إلى 301، وإعادة إرسال خريطة الموقع، وطلب الفهرسة.

هل تنقل إعادة التوجيه 302 قيمة الروابط؟

نعم. أكّد John Mueller من Google أن كلًا من 301 و 302 ينقل قيمة الروابط. المشكلة: مع الـ 302، لا يصبح رابط الوجهة قانونيًا، فتبقى القيمة موزّعة بين الرابطين بدلًا من التجميع. تبقى إشارات روابطك منقسمة حتى تُبدّلها إلى 301 أو تُزيل إعادة التوجيه كليًا.

متى أستخدم 302 بدلًا من 301؟

استخدم 302 في السيناريوهات المؤقتة صراحةً. اختبارات A/B التي ستتراجع عنها. نوافذ الصيانة لساعات أو أيام. صفحات العروض التي تنتهي بعد حملة. التقديم المؤقت حسب الموقع الجغرافي أثناء اختبار geo-testing. المعيار: أن تنوي فعلًا استعادة الرابط الأصلي خلال فترة معقولة.

كم يستغرق Google لاحترام إعادة التوجيه 301؟

عادةً من 2 إلى 6 أسابيع ليحلّ الرابط القانوني الجديد محل القديم كليًا في فهرس Google. المواقع ذات السلطة العالية والميزانيات الزحفية النشطة تشهد معالجة أسرع. المواقع منخفضة السلطة قد تستغرق من 8 إلى 12 أسبوعًا لاكتمال التجميع. تابع التقدم عبر أداة فحص الروابط في GSC. الإجابة عن “كم يستغرق إعادة التوجيه 301 في Google” تعتمد أساسًا على تكرار زحف Google لموقعك.

هل يمكنني تغيير 302 إلى 301 لاحقًا؟ وهل تتعافى تصنيفاتي؟

نعم. حدّث إعدادات الخادم من 302 إلى 301، وأعد إرسال خريطة الموقع في Google Search Console، واطلب فهرسة الروابط المتأثرة. تتعافى التصنيفات عادةً خلال 2 إلى 6 أسابيع حين يُعيد Google معالجة إعادة التوجيه ويُجمّع الإشارات عند رابط الوجهة. كلما أصلحت الخطأ أبكر، كان التعافي أسرع.

ما الفرق بين 301 و 308؟ وبين 302 و 307؟

الـ 308 دائم صارم (آمن للطريقة). يمنع العملاء من تغيير طريقة HTTP أثناء إعادة التوجيه. والـ 307 مؤقت صارم (آمن للطريقة) مع الحفاظ نفسه على الطريقة. كان 301 و 302 تاريخيًا يسمحان للعملاء بتحويل طلبات POST إلى GET. استخدم 307 و 308 لنقاط نهاية API حيث يكون الحفاظ على طريقة الطلب الأصلية أمرًا حاسمًا.

كيف أُعيد توجيه رابط في WordPress؟

ثلاثة خيارات. مدير إعادة التوجيه في RankMath PRO يمتلك أنظف واجهة مع كشف تلقائي للـ 404. إضافة Redirection المجانية تقدّم وظائف مشابهة دون تكلفة النسخة المميزة. التعديل اليدوي لـ .htaccess يمنحك أقصى تحكم لكنه يتطلب وصولًا للخادم. لمنهجية السيو التقني الأشمل على WordPress، راجع دليل السيو لـ WordPress.

كيف أتحقق أن إعادة التوجيه تعمل بشكل صحيح؟

شغّل curl -I [old-url] في الطرفية لرؤية رمز الحالة وترويسة Location التي يُعيدها خادمك فعليًا. تبويب الشبكة في DevTools يعرض نفس المعلومات مع تصوّر مرئي للسلسلة. وأداة فحص الروابط في Google Search Console تُخبرك كيف يقرأ Google نفسه إعادة التوجيه.

هل تضرّ سلسلة إعادة توجيه 301 بالسيو؟

نعم. كل قفزة تفقد جزءًا صغيرًا من قيمة الروابط وتضيف زمن استجابة. قد يتوقف Google عن متابعة السلاسل بعد نحو 5 قفزات، تاركًا القيمة عالقة على الطريق. راجع إعادة التوجيه لديك كل ربع سنة واختصر السلاسل إلى قفزة واحدة. Screaming Frog يرصد السلاسل تلقائيًا.

هل تتعامل محركات البحث الذكية (ChatGPT, Claude, Gemini) مع إعادة التوجيه بشكل مختلف عن Google؟

نعم. يستشهد ChatGPT بالروابط المُعاد توجيهها بمعدل أقل من Google بـ 3 إلى 7 مرات، وفقًا لدراسة SE Ranking في ديسمبر 2025. تفضّل الأنظمة الذكية الروابط المستقرة غير المُعاد توجيهها عند اختيار المصادر. إذا كانت زيارات الذكاء الاصطناعي مهمة لاستراتيجيتك، فضّل 301 على 302 واحذف سلاسل إعادة التوجيه في محتواك عالي القيمة.

كم ينبغي أن تبقى إعادة التوجيه 301؟

12 شهرًا على الأقل، والأفضل دائمًا. بعد أن يُجمّع Google الإشارات عند الرابط الجديد، قد تظن أن إعادة التوجيه لم تعد ضرورية. هي ضرورية. أبقِها. مواقع أخرى تربط بالرابط القديم لا تزال ترسل المستخدمين (والبوتات) عبر إعادة التوجيه لسنوات. إن أزلتها، تُصبح تلك الروابط 404. القاعدة المعقولة: احتفظ بـ 301 إلى الأبد ما لم يكن رابط الوجهة نفسه قيد الإلغاء.

كيف أُعيد توجيه معاملات سلسلة الاستعلام مثل ?utm_source=X؟

خياران. الحفاظ عليها: معظم المنصات تُمرّر سلاسل الاستعلام تلقائيًا (Apache RewriteRule، و Nginx $request_uri، و Cloudflare Workers request.url). حذفها: أعِد التوجيه صراحةً إلى الوجهة دون استعلام (مثل Apache RewriteRule ^old$ /new? [R=301,L]، حيث الـ ? في النهاية يمسح الاستعلام). الافتراض هو الحفاظ إلا إذا كان لديك سبب محدد (نظافة التحليلات، تنظيف canonical) لإسقاطها.

هل تؤثر إعادة التوجيه على Core Web Vitals أو سرعة الصفحة؟

نعم. كل قفزة إعادة توجيه تُضيف 100-400 مللي ثانية من الزمن بحسب DNS ومصافحة TLS ووقت استجابة الخادم. إعادة توجيه واحدة نادرًا ما تُشكّل قلقًا لـ CWV. سلسلة من 3+ إعادات توجيه على مورد حرج يمكن أن تدفع LCP إلى ما بعد 2.5 ثانية وتُدمّر CWV لديك. اختصر السلاسل دائمًا واستضف إعادة التوجيه على الحافة (Cloudflare Workers, CloudFront Functions) للاستجابة الأسرع.

ما الفرق بين 301 الصُّلب و 301 الليّن؟

لا يوجد “soft 301” في مواصفات HTTP. يظهر المصطلح أحيانًا في كتابات السيو لوصف إعادة توجيه قائمة على JavaScript أو meta-refresh. هذه ليست 301 حقيقية. إنها حِيَل من جانب العميل. الـ صُّلبة (الحقيقية) 301 هي استجابة على مستوى HTTP برمز الحالة 301 يُرجعها الخادم. “301 الليّنة” (JS أو meta-refresh) لا تنقل القيمة بشكل موثوق، ولا تحترمها كل برامج الزحف، وتُضيف زمن استجابة. استخدم دائمًا 301 حقيقية على مستوى HTTP.

هل يمكنني إعادة التوجيه إلى نطاق خارجي؟

نعم. آلية إعادة التوجيه متطابقة. ترويسة Location تُشير إلى الرابط الخارجي، ورمز الحالة هو ما تختاره. والعواقب على السيو متطابقة أيضًا: 301 إلى نطاق خارجي يُحوّل إشارات الترتيب إلى ذلك النطاق، و 302 تُبقي الإشارات على نطاقك. استخدم إعادة التوجيه 301 الخارجية باعتدال. أنت تُسلّم القيمة لموقع شخص آخر. الاستخدام المشروع الشائع: إعادة التوجيه بعد الاستحواذ، أو إحالات المواقع الشريكة، أو إغلاق علامة تجارية.

كيف أُصلح حلقة إعادة توجيه؟

شغّل curl -L -I [url]. العَلَم -L يتبع إعادة التوجيه، و -I يعرض الترويسات. إذا ارتدّ التتبع بين رابطين أو أكثر، فلديك حلقة. الأسباب الشائعة: إعادة توجيه A→B مع وسم canonical يُشير من B→A، قواعد .htaccess متضاربة، أو إعادة توجيه على مستوى CDN تتصارع مع إعادة توجيه على خادم المنشأ. أصلح بتحديد القاعدة المُسببة (عادةً الأحدث إضافةً) وحذفها. بعد الإصلاح، تحقّق مجددًا بـ curl -L -I. الحل الناجح يُظهر 200 واحدة في نهاية التتبع.

في منتصف الترحيل؟ إليك العرض.

أرسل لنا خريطة موقعك وملف .htaccess. سنقضي 30 دقيقة على مكالمة. شاشتك مع شاشتنا. سنُشغّل curl على خمسة من روابطك مباشرة، ونفحص رسم إعادة التوجيه في GSC، ونُخبرك أي إصلاح يُنقذ أكبر قدر من قيمة الترتيب. لا عروض شرائح، لا مقترحات، لا سلسلة مبيعات للمتابعة.

احجز مكالمة استراتيجية 30 دقيقة ← · واتساب +91 96366 50036

تريد رؤية الأسعار أولًا؟ فهرس الأسعار المنشور يعرض كل مستوى اشتراك بالـ INR و USD و GBP و EUR و AUD. دون مضاعف مكالمة الاكتشاف.

تريد المنهجية الرئيسية؟ راجع بروتوكول الإثبات. اشحن ← قِس ← أثبِت ← كرّر.

عن الكاتب

Kunal Singh Dabi مؤسس KD Digital. مُعترف به كأفضل أخصائي سيو في الهند للمؤسسات الصغرى والمتوسطة في قمة أعمال WASME العالمية للـ MSME 2023 في New Delhi. 250+ شركة تمّ توسيعها عبر 17+ دولة منذ مايو 2021. تقييم 4.9★ عبر 140+ مراجعة موثّقة. باني ممارسة استشارات السيو الأم التي تُطلق كل تغيير مع تقرير يوم الاثنين.