محظور بسبب مشكلة 4xx أخرى

TL;DR — «محظور بسبب مشكلة 4xx أخرى» في Google Search Console هي فئة Google المتبقية لأخطاء العميل التي لم تُفصل مسبقًا إلى 401 أو 403 أو 404. طلب Googlebot صفحتك وتلقى خطأ 4xx آخر (مثل 400 أو 410 أو 451)، ولذلك لا يمكن فهرسة الصفحة. لا تنشر Google قائمة دقيقة بالرموز التي تصل إلى هنا — ومهمتك الأولى هي معرفة أي رمز ظهر فعليًا، لأن الإصلاح يعتمد عليه بالكامل.

ماذا تعني هذه الحالة

تغطي فئة Search Console هذه استجابة 4xx لا تمثلها أنواع المشكلات الأكثر تحديدًا في التقرير. Evidence for this claim The Page Indexing report uses this category for a 4xx issue not covered by its other issue types. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report وتتعامل Google مع استجابات 4xx غير 429 بوصفها محتوى غير متاح للفهرسة. Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist; 429 is handled as a server-overload signal. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes

عندما تفتح تقرير فهرسة الصفحات في Search Console وترى «محظور بسبب مشكلة 4xx أخرى»، فهذا يعني أن Googlebot حاول جلب العنوان وأن خادمك أجاب بخطأ عميل 4xx — لكنه ليس من الفئات المحددة التي تسردها Google منفصلة. تفصل Google حالات 401 (تسجيل الدخول مطلوب) و403 (ممنوع) و404 (غير موجود) في صفوف مستقلة. وصياغة Google نفسها لهذا الصف هي «a 4xx error not covered by any other issue type» (الترجمة العربية) «خطأ 4xx لا تغطيه أي فئة مشكلات أخرى» — ولا تنشر خريطة شاملة لكل رمز آخر في هذه الفئة. عمليًا، تظهر هنا عادةً الرموز 400 و405 و408 و410 Gone و411 و413 و414 و421 و422 و451، لكن تعامل معها على أنها مرشحات محتملة للفحص لا ضمانًا لما ستجده.

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

التسمية فئة جامعة — اعثر على الرمز الحقيقي

هذا هو الجزء الذي يربك الناس. «4xx أخرى» فئة، لا تشخيص. إن كانت 410 Gone (حذفت صفحة عمدًا) و400 Bad Request (عنوان URL مكسور) تصلان إلى الصف نفسه، فالاستجابة الصحيحة متعاكسة في كل حالة. لذلك قبل أن «تصلح» أي شيء، اعثر على رمز الحالة الفعلي:

• في Search Console، استخدم فحص عنوان URL وانقر على اختبار عنوان URL المباشر لترى ما تتلقاه Google حاليًا.
• افتح الصفحة في DevTools ← علامة تبويب Network في متصفحك وانظر إلى رمز الحالة، أو اجلبها من سطر الأوامر باستخدام curl -I.
• افحص سجلات الخادم لترى أي رمز تلقاه Googlebot فعلًا.

هل هي مشكلة فعلًا؟

أحيانًا تعمل «4xx أخرى» كما ينبغي. فـ410 Gone لصفحة أزلتها نهائيًا سلوك صحيح — ولا تصبح مشكلة إلا إذا كانت الصفحة في خريطة موقع أو ما زالت مرتبطة بها عندما لا ينبغي ذلك. أما إذا كانت صفحة تريد فهرستها تعيد 4xx غريبًا، فذلك خطأ حقيقي ينبغي إصلاحه من مصدره.

كلمة سريعة عن 429

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

هل تريد دليل الإصلاح رمزًا رمزًا، وتفصيل 429، والفرق بين 410 و404، وشجرة قرار التشخيص؟ انتقل إلى العدسة المتقدمة.

TL;DR — «محظور بسبب مشكلة 4xx أخرى» هو صف Google المتبقي في تقرير فهرسة الصفحات: خطأ 4xx تلقاه Googlebot ولم يُفصل في نوع مشكلته الخاص (401/403/404). لا تنشر Google خريطة شاملة لكل رمز آخر في هذا الصف — فـ400 و405 و408 و410 و411 و413 و414 و421 و422 و451 فروع تشخيص ينبغي فحصها بعد معرفة الرمز الحقيقي، لا قائمة عضوية مضمونة. قاعدة Google: تُعامل كل أخطاء 4xx باستثناء 429 بالطريقة نفسها — يعامل المحتوى كما لو أنه غير موجود، فلا تُفهرس الصفحة، مع عدم تأثير في معدل الزحف. لا تخبرك التسمية إلا بالقليل، لذا الخطوة الأولى هي تحديد الرمز الحقيقي (الاختبار الحي لفحص العنوان ← إحصاءات الزحف ← إعادة إنتاج طريقة الطلب الأصلية ← سجلات الخادم/CDN/WAF/التطبيق المترابطة)، لأن إصلاح 410 (إزالة مقصودة) عكس إصلاح 400 أو 429. والخرافة التي تستحق الإزالة: 429 ليس 4xx عاديًا — تتعامل Google معه كـخطأ خادم (حمل زائد) وتبطئ الزحف، لكن ذلك لا يثبت أي تسمية في فهرسة الصفحات يتلقاها عنوان 429؛ اعتبر موضعه في التقرير غير مؤكد. لا تستخدم 4xx لإبطاء Googlebot — استخدم 429 أو 503. حدّد الرمز ← أصلح السبب الجذري (أو أكد أنه مقصود) ← أكد 200 في الاختبار الحي ← استخدم «التحقق من الإصلاح» (الذي يجعل العنوان مؤهلًا لإعادة الفهرسة، لا يضمنها).

ماذا تقول Google فعليًا

تسمية التقرير فئة، لذلك افحص العنوان لتحديد رمز الحالة والسبب الفعليين. Evidence for this claim The Page Indexing report uses this category for a 4xx issue not covered by its other issue types. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report أما سلوك HTTP فموثق بصورة مستقلة عن تصنيف التقرير. Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist; 429 is handled as a server-overload signal. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes

تصف وثائق تقرير فهرسة الصفحات لدى Google هذه الحالة بوضوح: واجه الخادم خطأ 4xx لا تغطيه أي من أنواع المشكلات الأخرى التي يفصلها التقرير، ونصيحتها هي تشخيص الصفحة باستخدام أداة فحص عنوان URL. لذلك فهي بحكم التعريف فئة البقايا — كل 4xx لم يُفصل في صفه الخاص (401 غير مصرح، 403 ممنوع، 404 غير موجود). لا تنشر Google جدولًا شاملًا يربط كل رمز 4xx متبقٍ بهذا الصف، ولذلك تعامل مع أي قائمة لـ«الرموز التي تصل هنا» — ومنها القائمة أدناه — على أنها مرشحات شائعة الملاحظة، لا عضوية رسمية أو كاملة.

يأتي السلوك الكامن وراءها من وثائق Google المنفصلة لرموز حالة HTTP، وهناك قاعدة مركزية تحكم معظم هذه الصفحة: تُعامل كل أخطاء 4xx، باستثناء 429، بالطريقة نفسها — تخبر زواحف Google نظام المعالجة التالي بأن المحتوى غير موجود. في الفهرسة تكون النتيجة مطابقة لـ404: تعامل الصفحة كأنها غير موجودة ولا تُفهرس (أو تُزال إذا كانت مفهرسة). والأهم أن رموز 4xx (باستثناء 429 أيضًا) لا تؤثر في معدل الزحف — فهي لا تبطئ Googlebot، بل تخرج الصفحة من الاعتبار (مع أن تكرار الزحف إلى عنوان يعيد الخطأ باستمرار ينخفض طبيعيًا بمرور الوقت لأن Google لا تزال تجد شيئًا هناك).

أي رموز 4xx تصل إلى هنا عادةً

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

• 400 Bad Request — هدف طلب أو صياغة أو تأطير Host/توجيه مشوه (غالبًا عنوان URL مكسور أو مرمّز بصورة سيئة). الاستنتاج الخاطئ: «شفرة الصفحة مكسورة» — قارن الطلب الدقيق الذي تلقاه الخادم بما قصدت توليده.
• 405 Method Not Allowed — طريقة HTTP المستخدمة غير مسموحة لهذا العنوان؛ وينبغي أن تحمل الاستجابة ترويسة Allow تسمي ما هو مسموح. الاستنتاج الخاطئ: أن فشل curl -I (HEAD) يثبت فشل GET لدى Googlebot بالطريقة نفسها — اختبر الطريقتين منفصلتين.
• 408 Request Timeout — لم يكتمل الاتصال أو الطلب في الوقت المحدد. الاستنتاج الخاطئ: «توقف خادم عام» — اربط التوقيت في طبقة الاتصال/الوكيل/الأصل.
• 410 Gone — المورد محذوف نهائيًا. غالبًا مقصود؛ راجع القسم أدناه.
• 411 Length Required — يصر الخادم على وجود ترويسة Content-Length في طلب يحمل جسمًا. هذا غير معتاد لجلب صفحة عادية — أكد أن الطلب حمل محتوى فعلًا والطبقة التي رفضته قبل تغيير قاعدة.
• 413 Payload Too Large — يتجاوز محتوى الطلب حد الحجم. أكد جسم/ترويسات الطلب الوارد، لا حجم الصفحة نفسها.
• 414 URI Too Long — يتجاوز معرّف URI للطلب حد الطول. غالبًا مشكلة معاملات مولدة أو سلسلة إعادة توجيه، لا مشكلة محتوى صفحة.
• 415 / 422 (Unsupported Media Type / Unprocessable Entity) — رُفض نوع محتوى الطلب أو تعليماته. مثل 411/413، تصف هذه الرموز حالة في الطلب، وهي غير معتادة لـGET صفحة عادية — لا تخفف التحقق عمومًا بلا دليل على الطلب المرفوض الفعلي.
• 421 Misdirected Request — وُجه الاتصال خطأً؛ وتوثق Google أيضًا إعادة 421 كطريقة مقصودة لإخراج مسار من زحف HTTP/2. لا تفترض أن الصفحة مكسورة على كل بروتوكول — أكد ما إذا كانت Google أعادت المحاولة عبر HTTP/1.1 وما كانت الاستجابة النهائية.
• 451 — غير متاح لأسباب قانونية — حجب قانوني أو متعلق بالسياسة. أحله إلى مالك مراجعة الشؤون القانونية/السياسة بدل معاملته كخطأ إعداد جغرافي/WAF روتيني.
• 429 Too Many Requests — تحديد معدل. هذا استثناء — انظر أدناه.

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

429 استثناء — افصل الدلالة عن تسمية التقرير

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

• يجعل 429 Googlebot يبطئ بدل إسقاط الصفحة فورًا.
• لأنه يعامل كخطأ خادم، فمن المعقول أن يظهر 429 الحقيقي كمشكلة خادم/زحف لا «محظور بسبب مشكلة 4xx أخرى» — لكن وثائق Google تصف سلوك المعالجة لا تصنيف التقرير، لذا اعتبر موضعه غير مؤكد ولا تفترض أنه مستبعد من هذه الفئة.
• الخطوة الخاطئة هي تعطيل تحديد المعدل المشروع لإصلاح حالة 4xx أخرى. إذا كان خادمك تحت حمل حقيقي، فأبقِ تحديد المعدل وأرسل ترويسة Retry-After كإجراء جيد — يجعل RFC 6585 الترويسة اختيارية في استجابة 429، ومع أن إرسالها نظافة HTTP معقولة لأي عميل منضبط، فإن وثائق Google التي روجعت لا تقول إن Googlebot يجدول زحفه التالي من قيمتها. أرسلها على أي حال كأفضل ممارسة؛ ولا تعاملها كتوجيه مضمون. وكما كتبت في دليلي على Ahrefs لرموز حالة HTTP، “429s are a little special because they are generally treated as server errors and will cause Google to slow down crawling. But eventually, Google will drop these pages from the index as well.” (الترجمة العربية) «429 مميز قليلًا لأنه يُعامل عمومًا كخطأ خادم وسيجعل Google تبطئ الزحف. لكن Google ستسقط هذه الصفحات من الفهرس في النهاية أيضًا.» لذلك 429 ليس مجانيًا — إنه يشتري وقتًا، ولا يبقي الصفحة مفهرسة إلى الأبد.

410 مقابل 404 — غالبًا ليست مشكلة

تعد 410 Gone أكثر الرموز المقصودة شيوعًا في هذه الفئة: أزلت صفحة وتريد اختفاءها. ينشغل الناس بالفرق بين 410 و404، لكن الفرق العملي صغير. تسرد وثائق Google للزحف 410 ضمن رموز 4xx التي تتلقى معاملة «المحتوى غير موجود» نفسها التي يتلقاها 404. وكما كتبت في دليلي على Ahrefs لرموز حالة HTTP، “404s and 410s have a similar treatment. Both drop pages from the index, but 410s are slightly faster.” (الترجمة العربية) «تُعامل حالتا 404 و410 بصورة متقاربة؛ وتخرج كلتاهما الصفحات من الفهرس، مع أفضلية طفيفة لـ410 في السرعة.» قال John Mueller إن الفارق لا يتجاوز بضعة أيام صغيرة في أقصى تقدير، وإن Google تعامل 404 و410 بالطريقة نفسها على المدى المتوسط والطويل — فكلاهما يُسقط من الفهرس. لا يؤكد إدراج Google لـ410 ضمن معالجة 4xx المشتركة وحده الصف الذي يُبلغ عنه عنوان 410 في فهرسة الصفحات، ولذلك إذا رأيت واحدًا هنا فذلك متسق مع التوقعات لا يقين موثق. في كل الأحوال: إذا كانت 410 في هذه الفئة مقصودة فهي تعمل كما صُممت — تحرك فقط إذا كان ينبغي أن تكون الصفحة حية فعلًا، وأكد حالتها في Search Console بدل افتراضها من الرمز وحده.

لماذا يحدث ذلك

تأتي معظم حالات «4xx أخرى» الواقعية من أحد الأسباب التالية:

• قواعد WAF / حماية الروبوتات / CDN تعيد 4xx غريبًا (غالبًا 4xx ليس 403 نظيفًا) عندما يطلق نمط طلب Googlebot قاعدة.
• إضافات الأمان (مثل إضافات أمان WordPress) تحجب العملاء غير المتصفحين أو تتحداهم.
• حجب IP/جغرافي يصيب Googlebot، الذي يزحف أساسًا من عناوين IP أمريكية.
• تحديد معدل عدواني يعيد 4xx بعد N من الطلبات (وينبغي أن يكون هذا 429 — انظر أدناه).
• عناوين URL مشوهة (400)، أو حدود حجم الطلب (413)، أو فشل التحقق (422) ناتج عن طريقة توليد العنوان أو ربطه.
• إزالات مقصودة (410) لا ينبغي أن تبقى في خريطة موقع.

مصدر كبير للمشكلة من صنع الذات: استخدام 4xx لخنق Googlebot. طلبت Google من مالكي المواقع وشبكات CDN التوقف عن استخدام 404 ورموز 4xx الأخرى لمحاولة خفض معدل زحف Googlebot — فهذا لا يبطئ الزحف، بل يزيل المحتوى من البحث. إذا احتجت إلى أن يتراجع Googlebot، فأعد 500 أو 503 أو 429، لا 4xx.

كيف تشخّص الرمز الحقيقي

اعمل على هذا كأنه شجرة قرار من الأعلى إلى الأسفل. لا تضمن أداة واحدة كشف الفشل الدقيق — فصِل بينها:

1. فحص عنوان URL ← اختبار العنوان المباشر. يؤكد هذا التوافر الحالي — هل تتلقى Google خطأ 4xx الآن أم أن صف التقرير قديم — لكن الاختبار الحي الفاشل لا يكشف دائمًا ترويسات الاستجابة الخام أو سطر الحالة، لذا اعتبره فحص توافر أولًا لا تشخيصًا كاملًا.
2. تقرير إحصاءات الزحف. يجلب أمثلة ممثلة لطلبات Google الفعلية (رمز الاستجابة، ووقت الاستجابة، ونوع الملف) — وهو مفيد لتأكيد ما رآه الزحف المجدول، لأن اختبار العنوان الحي يستخدم Google-InspectionTool لا الزاحف العادي.
3. أعد إنتاجه بنفسك مع مطابقة الطلب الأصلي. افتح العنوان في علامة Network في DevTools، أو استخدم curl؛ وإذا شككت في قاعدة روبوتات فاجلبه بصفة Googlebot (ويفضل من خارج شبكتك) لتشغيل القاعدة نفسها. طابق الطريقة أيضًا — يرسل curl -I طلب HEAD وقد يعطي نتيجة مختلفة عن GET الذي أرسلته Google فعليًا (ففشل 405 في HEAD وحده لا يثبت فشل GET). (الأوامر في عدسة Scripts.)
4. اقرأ سجلات الخادم/CDN/WAF/وكيل المصادقة/التطبيق مترابطة. غالبًا لا تجد الرمز الدقيق والطبقة المانعة والقاعدة أو الشرط المنتج له إلا هنا — خصوصًا عندما لا يستطيع الاختبار الحي عرض الترويسات الخام.
5. تحقق من هوية الطالب منفصلة عن الاستجابة. لا تثبت سلسلة user-agent وحدها أن Googlebot أجرى الطلب؛ أكد عبر DNS عكسي ثم أمامي أو نطاقات IP المنشورة لدى Google قبل تقرير أن الحجب يصيب زاحفًا شرعيًا.
6. اربط الرمز بسببه. 400/405/408/414 ← مشكلة في تأطير الطلب/التوقيت/URI. 411/413/415/422 ← لا تشخّصها كمشكلة محتوى طلب إلا مع دليل على الطريقة والجسم الفعليين لطلب Google — فهذه غير معتادة لجلب صفحة عادية. 410 ← إزالة مقصودة (أكد أنه ينبغي أن يختفي). 421 ← تحقق من كونه منع HTTP/2 الموثق لدى Google وما أعاده بديل HTTP/1.1. خطأ 4xx من طبقة أمان ← حجب يسمح به العميل والمسار المتحقق منه فقط، لا قائمة سماح شاملة. 429 محتمل ← تحديد معدل (عالجه كحمل خادم لا 4xx).

كيف تصلحه حسب الرمز

• 400 / 405 / 408 / 414 (تأطير الطلب، والطريقة، والتوقيت، وطول URI). أصلح مصدر الطلب المشوه، أو عنوان URL المكسور/الطويل، أو الطريقة الممنوعة، أو الاتصال البطيء/غير المكتمل في الطبقة التي تولده فعلًا — وقارن الطلب الدقيق الذي رآه الخادم بما قصد تطبيقك إرساله.
• 411 / 413 / 415 / 422 (أخطاء محتوى الطلب). تصف هذه حالات مرتبطة بجسم الطلب أو طوله أو نوع محتواه — وهي غير معتادة لجلب GET لصفحة عادية. قبل تخفيف حد أو قاعدة تحقق، أكد من السجلات الطريقة والمحتوى اللذين أطلقاها والطبقة التي رفضتهما؛ لا تخفف حدود الأمان عمومًا بلا ذلك الدليل.
• 410 — هل هو مقصود؟ إذا كان ينبغي أن تختفي الصفحة، فـ410 صحيحة — أزلها من خرائط المواقع والروابط الداخلية كي تتوقف عن الظهور بوصفها «مشكلة». وإن كان ينبغي أن تكون حية، فـ410 خطأ ينبغي التراجع عنه.
• 421 — تحقق من كونه منع HTTP/2 مقصودًا. توثق Google إعادة 421 كطريقة لإخراج مسار من زحف HTTP/2. أكد ما إذا كان الطلب عاد إلى HTTP/1.1 وما كانت الاستجابة النهائية قبل اعتبار 421 صفحة مكسورة.
• 429 — تحديد معدل سليم. لا تقتل تحديد المعدل المشروع. أبقه وأضف ترويسة Retry-After كأفضل ممارسة (اختيارية وفق مواصفة HTTP، ولا تؤكد وثائق Google أن Googlebot يجدول زحفه التالي منها)، وتذكر أن Google تقرأ 429 «تمهل» لا «أزل الفهرسة». إن كان 4xx لا يظهر إلا لأن القاعدة تحاول إبطاء Googlebot، فحوّلها إلى 429 أو503.
• 451 — أكد السياق القانوني/السياساتي أولًا. لا تعاملها كخطأ إعداد جغرافي/WAF عادي؛ أحلها إلى مالك القرارات القانونية أو المتعلقة بالمحتوى قبل تغيير الاستجابة.
• حجب WAF/CDN/إضافة أمان. حدد الطبقة والقاعدة المانعتين بدقة أولًا. اسمح لـGooglebot المتحقق — عبر هوية DNS العكسي أو نطاقات IP المنشورة لدى Google، لا عبر الثقة بسلسلة user-agent القابلة للانتحال — وقيّد الاستثناء بالمسار والعميل المقصودين، لا سماحًا شاملًا لكل طلب من Google أو لكل قواعد الأمان. أصلح القاعدة كي يعيد العنوان 200.

لا تستخدم 4xx لإبطاء Googlebot

يجدر ذكر ذلك منفردًا لأنه سبب رئيسي لحالات «4xx أخرى» التي يصنعها الموقع بنفسه: إعادة رموز 4xx لخنق Googlebot لا تعمل وتزيل المحتوى من البحث. وكما ألخص القاعدة في دليلي على Ahrefs لرموز حالة HTTP، “4xxs will cause pages to drop from the index.” (الترجمة العربية) «ستؤدي 4xx إلى إسقاط الصفحات من الفهرس.» إذا كان هدفك الحقيقي إبطاء الزحف، فاستخدم 429 أو 503 — فهما الرمزان اللذان تقرؤهما Google بمعنى «عد لاحقًا»، وتأثيرهما مؤقت.

بعد إصلاحها

بعد حل السبب الأساسي (أو تأكيد أن 410 مقصودة وتنظيف خريطة الموقع/الروابط):

1. فحص عنوان URL ← اختبار العنوان المباشر للتأكد من أن الاستجابة الحية أصبحت 200.
2. اطلب الفهرسة للعناوين ذات الأولوية و/أو انقر التحقق من الإصلاح في صف «محظور بسبب مشكلة 4xx أخرى» في تقرير فهرسة الصفحات.
3. تجعل استجابة 200 العنوان مؤهلًا لكي تعيد Google الزحف إليه ومعالجته وربما فهرسته بعد الزحف التالي — لكنها لا تضمن الفهرسة أو جدولًا زمنيًا ثابتًا؛ فلا تطلب الفهرسة بالجملة قبل إصلاح السبب الجذري، وإلا عدت إلى الفئة نفسها.

هل تضر SEO؟

فقط إذا كانت الصفحات التي تريد فهرستها فعلًا تعيد 4xx — فستسقط من الفهرس وتفقد ترتيبها حتى الإصلاح. أما إذا كان 4xx مقصودًا (410 لصفحة محذوفة، أو حجب مقصود لمسار إدارة لا ينبغي أن يكون في خريطة موقعك)، فهو يعمل كما صُمم ولا يضر شيئًا.

الأخطاء الشقيقة التي ينبغي معرفتها: «محظور بسبب الوصول الممنوع (403)» و**«محظور بسبب طلب غير مصرح به (401)»** هما صفا الجدار الناري/تسجيل الدخول المخصصان، و**«غير موجود (404)»** فئة مستقلة. هذه الحالة هي كل ما تبقى من عائلة 4xx. أما التقرير نفسه وكيف يجمع أسباب عدم الفهرسة، فانظر إلى نظرة عامة على تقرير فهرسة الصفحات.

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

خلاصة مكثفة للنسخة المتقدمة:

• ما هي. «محظور بسبب مشكلة 4xx أخرى» في تقرير فهرسة الصفحات في GSC = تلقى Googlebot خطأ 4xx لم يُفصل إلى 401/403/404. لا تنشر Google قائمة شاملة للرموز التي تصل هنا — فـ400 و405 و408 و410 و411 و413 و414 و421 و422 و451 مرشحات شائعة للفحص، لا قائمة عضوية مضمونة. لا تُفهرس الصفحة (وتُزال إذا كانت مفهرسة).
• القاعدة الأساسية. تُعامل كل 4xx باستثناء 429 بالطريقة نفسها — تعامل Google المحتوى كأنه غير موجود، مثل 404، مع عدم تأثير في معدل الزحف.
• التسمية فئة جامعة. لا تخبرك بالسبب — اعثر على رمز الحالة الحقيقي أولًا (الاختبار الحي لفحص العنوان ← إحصاءات الزحف ← إعادة إنتاج طريقة الطلب الأصلية ← سجلات الخادم/CDN/WAF المترابطة؛ curl -I هو HEAD لا GET، فاختبرهما).
• 429 استثناء (وخرافة شائعة). تتعامل Google مع 429 كـخطأ خادم (حمل زائد) وتبطيء الزحف بدل إسقاط الصفحة، لكن ذلك لا يؤكد تحت أي صف في التقرير يظهر عنوان 429 — اعتبر الموضع غير مؤكد. أبقِ تحديد المعدل المشروع وأرسل Retry-After كأفضل ممارسة (اختياري وفق المواصفة؛ ولا تقول وثائق Google إن Googlebot يجدول منه). لا تعطل الحماية لإصلاح حالة 4xx أخرى.
• 410 مقابل 404. 410 (Gone) هو الرمز المقصود الشائع هنا؛ تجمعه Google مع 404 في معاملة «المحتوى غير موجود»، والفرق العملي في التوقيت صغير. إذا كانت 410 مقصودة فهي تعمل كما صُممت — أكد النية قبل لمسها.
• 421 قد يكون مقصودًا أيضًا. توثق Google 421 كوسيلة لإخراج مسار من زحف HTTP/2 — افحص بديل HTTP/1.1 والاستجابة النهائية قبل افتراض أن الصفحة مكسورة.
• لماذا يحدث. حجب WAF/CDN/إضافة أمان، أو حجب IP/جغرافي، أو قواعد تحديد معدل، أو عناوين مشوهة/طويلة (400/414)، أو حالات محتوى الطلب (411/413/415/422 — تحتاج دليل جسم الطلب الفعلي)، أو إزالات مقصودة (410).
• لا تخنق بـ4xx. استخدام 404/4xx أخرى لإبطاء Googlebot يزيل المحتوى من البحث — استخدم 429 أو 503 بدلًا منه.
• الإصلاح والتحقق. حدد الرمز (لا تتوقف عند اختبار حي فاشل — اسحب إحصاءات الزحف والسجلات المترابطة) ← أصلح السبب الجذري (أو أكد أنه مقصود ونظف خرائط المواقع/الروابط) ← أكد 200 في الاختبار الحي ← تحقق من الإصلاح. تجعل 200 العنوان مؤهلًا لإعادة الفهرسة؛ لكنها لا تضمنها أو جدولًا معينًا.

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

وثائق أساسية من محركات البحث.

Google

• تقرير فهرسة الصفحات — التقرير نفسه، بما في ذلك مدخل “Blocked due to other 4xx issue” (الترجمة العربية) «محظور بسبب مشكلة 4xx أخرى» (خطأ 4xx لا تغطيه أي فئة مشكلات أخرى) والأشقاء 401/403/404.
• كيف تؤثر رموز حالة HTTP وأخطاء الشبكة وDNS في بحث Google — قاعدة معاملة كل 4xx باستثناء 429 بالطريقة نفسها، وفهم 429 كإشارة إلى حمل الخادم، وأن 4xx (باستثناء 429) لا أثر لها في معدل الزحف.
• لا تستخدم 404 لإرضاء الجميع (مدونة Search Central، 2023) — طلب Google من مالكي المواقع وشبكات CDN عدم استخدام 404 و4xx الأخرى لخنق Googlebot، وما ينبغي استخدامه بدلًا منه (500/503/429).
• التحقق من Googlebot وزواحف Google الأخرى — DNS عكسي ثم أمامي ونطاقات IP المنشورة، للسماح لـGooglebot الحقيقي قبل تغيير قاعدة WAF/الجدار الناري.

Bing / Microsoft

• مساعدة Bing Webmaster Tools — التحكم في الزحف — لا تستخدم Bing تسمية «4xx أخرى» المطابقة لتسمية Google، لكن المبدأ واحد: تعني 4xx أن Bingbot لم يستطع جلب محتوى صالح، ولذلك لا يُفهرس العنوان. استخدم التحكم في الزحف لإدارة سرعة Bingbot بدل حجبه برموز الخطأ.

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

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

Google — كيف تُعامل 4xx (باستثناء 429)

• “All 4xx errors, except 429, are treated the same: Google crawlers inform the next processing system that the content doesn’t exist.” (الترجمة العربية) «تُعامل جميع أخطاء 4xx، باستثناء 429، بالطريقة نفسها: تُبلغ زواحف Google نظام المعالجة التالي بأن المحتوى غير موجود.» — وثائق Google Search Central. انتقل إلى الاقتباس

Google — 429 يعامل كخطأ خادم

• “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” (الترجمة العربية) «تتعامل زواحف Google مع رمز الحالة 429 بوصفه إشارة إلى أن الخادم محمل فوق طاقته، ويُعد خطأ خادم.» — وثائق Google Search Central. انتقل إلى الاقتباس

Google — لا تستخدم 4xx للحد من معدل الزحف

• “The 4xx status codes, except 429, have no effect on crawl rate.” (الترجمة العربية) «لا تؤثر رموز الحالة 4xx، باستثناء 429، في معدل الزحف.» — وثائق Google Search Central. انتقل إلى الاقتباس

John Mueller، Google — 410 مقابل 404 (إعادة صياغة)

• وصف John Mueller من Google الفارق بين 410 و404 بأنه صغير — في حدود بضعة أيام على الأكثر — وقال إن Google تعامل 404 و410 بالطريقة نفسها على المدى المتوسط والطويل: فكلاهما يُسقط من الفهرس. أوردت ذلك تغطية Search Engine Journal لملاحظاته: نصائح Google حول رموز الحالة 404 و410 (SEJ). (أعيدت صياغته هنا لا اقتباسه حرفيًا، ريثما يُجرى فحص مستقل للصياغة الدقيقة في هذه الجولة — أكد النص مقابل المصدر قبل اقتباسه مباشرةً.)

Patrick Stox (أنا) — من دليلي على Ahrefs لرموز الحالة

• “4xxs will cause pages to drop from the index.” (الترجمة العربية) «ستؤدي 4xx إلى إسقاط الصفحات من الفهرس.» — Patrick Stox، «رموز حالة HTTP وتأثيرها في SEO»، Ahrefs. انتقل إلى الاقتباس
• “404s and 410s have a similar treatment. Both drop pages from the index, but 410s are slightly faster.” (الترجمة العربية) «تتلقى 404 و410 معاملة متشابهة. كلاهما يسقط الصفحات من الفهرس، لكن 410 أسرع قليلًا.» انتقل إلى الاقتباس
• “429s are a little special because they are generally treated as server errors and will cause Google to slow down crawling. But eventually, Google will drop these pages from the index as well.” (الترجمة العربية) «429 مميز قليلًا لأنه يُعامل عمومًا كخطأ خادم وسيجعل Google تبطئ الزحف. لكن Google ستسقط هذه الصفحات من الفهرس في النهاية أيضًا.» انتقل إلى الاقتباس

ملاحظة عن Retry-After: يسمح RFC 6585 (ولا يفرض) بأن تتضمن استجابة 429 ترويسة Retry-After. إرسالها ممارسة معقولة لأي عميل منضبط، لكن وثائق Google التي روجعت لهذه الصفحة لا تقول إن Googlebot يستخدم قيمة الترويسة كجدول حرفي للزحف التالي — فقدمها كبيانات استجابة اختيارية، لا تعليمات مؤكدة لـGooglebot.

قائمة تشخيص → إصلاح → تحقق لحالة 4xx الأخرى

طبّق هذه القائمة على أي عنوان يظهر «محظور بسبب مشكلة 4xx أخرى»:

• اعثر على الرمز الحقيقي أولًا — فحص عنوان URL ← اختبار العنوان المباشر، وإحصاءات الزحف لتفاصيل الطلبات التمثيلية، وعلامة Network في DevTools / curl (HEAD وGET معًا) / سجلات الخادم-CDN-WAF المترابطة. تسمية الفئة ليست تشخيصًا، ولا تنشر Google خريطة كاملة للرموز والصفوف.
• أكد أنه حي لا قديم — يعرض الاختبار الحي 4xx حاليًا لا تقريرًا قديمًا؛ ولاحظ أن الاختبار الفاشل قد لا يعرض الترويسات الخام، فاستشهد بالسجلات عندما لا يعرضها.
• صنّفه. خطأ تأطير/توقيت/URI (400/405/408/414)؟ حالة محتوى طلب تحتاج دليل الجسم (411/413/415/422)؟ إزالة مقصودة (410)؟ خروج HTTP/2 محتمل (421)؟ قانون/سياسة (451)؟ حجب طبقة أمان؟ 429 محتمل (تحديد معدل)؟
• إذا كان 410 (Gone): هل يفترض أن تكون الصفحة زائلة؟ إن كان نعم فهي صحيحة — أزلها من خرائط المواقع والروابط الداخلية. وإن كان لا فأعد الصفحة.
• إذا كان 421: أكد أنه خروج HTTP/2 مقصود وافحص بديل HTTP/1.1 والاستجابة النهائية قبل اعتباره مكسورًا.
• إذا كان خطأ طلب/تأطير: أصلح العنوان المشوه أو الطويل، أو الطريقة المسموحة، أو مشكلة المهلة/الاتصال من المصدر؛ وتوقف عن ربط العنوان السيئ أو إدراجه.
• إذا كان خطأ محتوى الطلب (411/413/415/422): أكد الطريقة والجسم الفعليين من السجلات قبل تخفيف أي حد أو قاعدة تحقق.
• إذا كان حجب أمان/WAF/CDN: تحقق من Googlebot الحقيقي (DNS عكسي أو نطاقات IP منشورة)، ثم اسمح على نحو ضيق بالهوية/IP والمسار — لا بسلسلة user-agent ولا سماحًا شاملًا.
• إذا كان الهدف خنق الزحف: لا تستخدم 4xx — أعد 429 أو 503 وأضف ترويسة Retry-After كأفضل ممارسة. أبقِ تحديد المعدل المشروع ولا تفترض أن زحف Googlebot التالي يُجدول من هذه الترويسة.
• أكد 200 — يعيد الاختبار الحي الآن 200 للصفحات التي تريد فهرستها.
• تحقق — انقر التحقق من الإصلاح في صف «4xx الأخرى» و/أو طلب الفهرسة للعناوين ذات الأولوية. يجعل ذلك العنوان مؤهلًا لإعادة الفهرسة، لا يضمنها — فلا تطلب بالجملة قبل إصلاح السبب.

النماذج الذهنية

1. التسمية فئة، لا تشخيص. «4xx أخرى» صف Google المتبقي لأي 4xx لم يُفصل في نوع مشكلته — ولا تنشر Google القائمة الدقيقة لما يصل إليه، مع أن 400 و405 و408 و410 و411 و413 و414 و421 و422 و451 مرشحات شائعة. الخطوة الأولى ليست «أصلحه» — بل «أي رمز هو فعلًا؟» فكل ما بعد ذلك يعتمد على الجواب.

2. من ناحية الفهرسة، 4xx الأخرى = 404. تتعامل Google مع كل 4xx باستثناء 429 بالطريقة نفسها: يعامل المحتوى كما لو أنه غير موجود. لذلك مهما كان الرمز المحدد، تكون نتيجة الفهرسة مثل 404 — لا فهرسة، وإزالة إن كان مفهرسًا. وهذا يعني أيضًا عدم تأثير في معدل الزحف.

3. 429 خطأ خادم لا خطأ عميل — وموضعه في التقرير سؤال مستقل غير مؤكد. تقرأ Google 429 بوصفه «الخادم محمل فوق طاقته» وتبطئ بدل إسقاط الصفحة — وهذا موثق. أما ظهور عنوان 429 تحت صف التقرير المحدد هذا فغير موثق في أي من الاتجاهين، فلا تعتبر موضعه محسومًا. لا تعطل تحديد المعدل لإخفائه — أرسل Retry-After كأفضل ممارسة، من دون افتراض أن Googlebot يتبعه وفق جدول.

4. مقصود مقابل خطأ. يمكن أن تعمل 410 لصفحة محذوفة أو 421 لإخراج مسار من HTTP/2 كما صُمما، بينما 400 لصفحة تريد فهرستها خطأ. اسأل «هل ينبغي أن يكون هذا العنوان حيًا أصلًا، وعلى أي بروتوكول؟» قبل اختيار إصلاح — وإذا لم يكن حيًا، فالإصلاح هو التوقف عن إدراجه (في خرائط المواقع والروابط)، لا جعله 200.

5. 4xx أداة خنق خاطئة. إذا كان هدفك إبطاء Googlebot، فلن يحقق 4xx ذلك — بل يزيل الفهرسة. رموز «عد لاحقًا» هي 429 و5xx/503. اختر الرمز المطابق لنيتك: «هذا زائل» (4xx) مقابل «أنا محمل فوق طاقتي، حاول لاحقًا» (429/503).

ورقة غش 4xx الأخرى

الرموز التي تظهر هنا عادةً — والإصلاح لكل منها (لا تنشر Google قائمة عضوية شاملة لهذه الفئة؛ تعامل مع الجدول كفروع تشخيص تفحصها بعد معرفة الرمز الحقيقي، لا ضمانًا.)

الحالات الشقيقة في فهرسة الصفحات

اختر الرمز المناسب لنيتك

اعثر على رمز الحالة الحقيقي

لن تخبرك تسمية GSC بأي 4xx تتعامل معه — افحصه مباشرةً. يرسل -I طلب HEAD لا GET الذي تستخدمه Google فعليًا لجلب الصفحة، ولذلك لا يثبت ناتج HEAD وحده (مثل 405) ما يعيده GET — اختبر الطريقتين.

macOS / Linux — أوامر الفحص

# HEAD only — read the status line (e.g. "HTTP/1.1 410 Gone")
curl -s -I https://www.example.com/page/

# GET — reproduces the method Google actually uses to fetch page content
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.com/page/

# If you suspect a bot-specific block, fetch as Googlebot's user-agent (GET)
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  -o /dev/null -w "%{http_code}\n" https://www.example.com/page/

Windows (PowerShell) — أوامر الفحص

# GET request, matching what Google actually uses to fetch page content
$ua = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Invoke-WebRequest -Uri "https://www.example.com/page/" -Method Get `
  -UserAgent $ua -SkipHttpErrorCheck | Select-Object StatusCode, StatusDescription

إذا اختلف الرمز بين HEAD وGET، أو بين طلب عادي وطلب بصفة Googlebot، فقد عثرت على قاعدة خاصة بالطريقة أو بالروبوت. وقد يعتمد WAF متقدم أيضًا على IP أو البروتوكول أو فئة العميل لا user-agent وحده، ولذلك أجرِ إعادة إنتاج كاملة من خارج شبكتك ولا تفترض أن تطابق user-agent يثبت انطباق القاعدة نفسها على حركة Googlebot الحقيقية.

تحقق من أن الروبوت هو Googlebot فعلًا (قبل السماح له)

إذا جاء 4xx من طبقة أمان وكنت على وشك السماح للزاحف بالمرور، فتأكد أولًا من أنه Googlebot فعلًا — فسلسلة user-agent سهلة الانتحال، وتبديل user-agent وحده في طلب الاختبار لا يعيد إنتاج IP المصدر أو فئة العميل أو البروتوكول أو مسار قاعدة الحافة الحقيقي لدى Google.

macOS / Linux — التحقق من DNS

# 1) Reverse DNS the IP from your logs — must end in googlebot.com / google.com
host 66.249.66.1
# → ... domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Windows — التحقق من DNS

nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

إذا لم ينتهِ البحث العكسي باسم نطاق Google، أو لم يطابق البحث الأمامي عنوان IP الأصلي، فليس الطالب Googlebot — فلا تسمح له. ويمكنك أيضًا مطابقة IP مع النطاقات المنشورة لدى Google (googlebot.json). اسمح بهوية/نطاق IP متحقق منه، لا بسلسلة user-agent وحدها.

أرسل Retry-After مع 429 (لا تقتل تحديد المعدل)

إذا كان عنوان URL يخضع فعلًا لتحديد المعدل، فأعد 429 مع Retry-After كأفضل ممارسة HTTP — بدل تعطيل الحماية أو إعادة 4xx «حقيقي». ترويسة Retry-After اختيارية وفق RFC 6585، ولا تؤكد وثائق Google أن Googlebot يجدول زحفه التالي من قيمتها، فاعتبرها نظافة معقولة لا إصلاحًا مثبتًا. الأمثلة التالية نقطة بداية توضيحية — راجعها مقابل إعداد خادمك/CDN وسياسة الأمان قبل النشر.

Apache (.htaccess / config) — مثال

# Example: return 429 with a 1-hour Retry-After for rate-limited responses
Header always set Retry-After "3600" "expr=%{REQUEST_STATUS} == 429"

Nginx — مثال

# limit_req_status makes throttled requests return 429 instead of 503
limit_req_status 429;
# add a Retry-After hint on 429 responses
error_page 429 = @rate_limited;
location @rate_limited {
    add_header Retry-After 3600 always;
    return 429;
}

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

رسمية

• تقرير فهرسة الصفحات (Google) — مدخل «4xx أخرى» وأشقاؤه 401/403/404.
• كيف تؤثر رموز حالة HTTP في بحث Google — قاعدة كل 4xx باستثناء 429، ودلالة 429 كخطأ خادم، وعبارة “no effect on crawl rate” (الترجمة العربية) «لا أثر في معدل الزحف».
• لا تستخدم 404 لإرضاء الجميع (Google، 2023) — لا تستخدم 404/4xx أخرى لخنق Googlebot.
• التحقق من Googlebot (Google) — DNS عكسي ونطاقات IP المنشورة.

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

• رموز حالة HTTP وتأثيرها في SEO — دليلي الكامل إلى معنى كل رمز حالة في SEO، بما في ذلك خطوط 4xx و410 مقابل 404 و429 المقتبسة هنا.
• دليل المبتدئين إلى SEO التقني — موضع أخطاء الزحف/الفهرسة مثل هذه في الصورة الأكبر.

من الآخرين

• r/TechSEO — مجتمع تصحيح الزحف/الفهرسة، بما في ذلك سلاسل «weird 4xx in GSC» (الترجمة العربية) «4xx غريبة في GSC».
• تحذر Google من استخدام 403 أو 404 للحد من معدل الزحف (Search Engine Land) — تغطية إرشاد Gary Illyes: «Don’t 404 my yum» (الترجمة العربية) «لا تستخدم 404 لإرضاء الجميع»؛ استخدم 500/503/429 بدلًا منه.
• Google: رموز الحالة 404 مقابل 410 — الفروق ضئيلة (Search Engine Roundtable) — Mueller عن ضآلة فرق 410 مقابل 404 عمليًا.
• تقدم Google نصائح حول رموز الحالة 404 و410 (Search Engine Journal) — المصدر المنقول لملاحظات Mueller عن سرعة 410 مقابل 404؛ أكد الصياغة الدقيقة في الصفحة الحية قبل اقتباسها مباشرةً.
• كيفية إصلاح «محظور بسبب مشكلة 4xx أخرى» (Onely) — شرح خطوة بخطوة يغطي الرموز الشائعة؛ مفيد لتدقيق خريطة الموقع والروابط الداخلية. تعامل مع ادعاءات عضوية الرموز على أنها قراءة هذا المصدر لا تصنيف Google مؤكدًا.
• محظور بسبب مشكلة 4xx أخرى (SEOTesting) — يغطي تحليل سجلات الخادم والمراقبة الوقائية، ويسمي أيضًا 422 و405 و413 و414. وينطبق التحفظ نفسه على ادعاءات العضوية.

العثور على الرمز الحقيقي خلف «4xx أخرى»

«4xx أخرى» فئة جامعة، ولذلك فإن الخطوة الأولى المفيدة الوحيدة هي تحديد الرمز الذي يعمل فعليًا — وهذا ما تعنيه فقرة المقال «اعمل على هذا كأنه شجرة قرار من الأعلى إلى الأسفل». أكد الرمز الحي أولًا، ثم تفرع حسب العائلة التي ينتمي إليها قبل لمس أي إعداد.

تتبع فئة «4xx الأخرى»، لا مجرد وجودها

الرقم الوحيد الجدير بالمراقبة هو عدد عناوين URL الموجودة في صف «محظور بسبب مشكلة 4xx أخرى» في تقرير فهرسة الصفحات بمرور الوقت — فاللقطة الواحدة لا تخبرك إن نجح الإصلاح أو بدأت رموز مشكلة جديدة بالظهور، خصوصًا لأن هذه الفئة تجمع أسبابًا مقصودة وعرضية.

عدد فئة 4xx الأخرى بمرور الوقت

• المقياس — عدد العناوين تحت «محظور بسبب مشكلة 4xx أخرى» في تقرير فهرسة الصفحات في GSC، متتبعًا أسبوعًا بعد أسبوع، ويفضل تقسيمه حسب رمز الحالة الحقيقي بعد تحديده لكل عنوان.
• ما الذي يخبرك به — ما إذا كانت إصلاحات الطلب/التحقق (400/405/411/413/422) وقوائم السماح في WAF/CDN تدخل حيز التنفيذ. بالنسبة إلى العناوين التي رمزها الحقيقي 410 مقصود، ينبغي أن يبقى عددها ثابتًا بعد تنظيف خرائط المواقع والروابط الداخلية — فالارتفاع فيها يعني عادةً أن صفحات «محذوفة» جديدة ما زالت تُربط أو تُدرج في خرائط المواقع بالخطأ، لا ظهور خطأ جديد.
• كيفية استخراجه — تقرير فهرسة الصفحات في GSC، بعد تصفيته إلى صف «4xx الأخرى»؛ وافحص عناوين فردية عبر فحص عنوان URL ← الاختبار الحي للتأكد من أن التقرير لا يعرض لقطة قديمة.
• المعيار/النطاق الواقعي — لا يوجد هدف عام — فهو يعتمد تمامًا على عدد العناوين التي تعيد لها عمدًا 410 (أو رمزًا مشابهًا). المعيار الصادق: صفر من 4xx الأخرى بين العناوين التي تريد فهرستها، وعدد ثابت (غير نامٍ) للعناوين التي أزلتها عمدًا. أنشئ خط أساس لعددك قبل الحكم على اتجاه المنحنى.
• الدورية — أسبوعيًا بعد الإصلاح مباشرةً حتى يستقر العدد؛ ثم شهريًا كفحص انحدار، خصوصًا إذا كنت تعتمد على WAF/CDN يمكن أن تتغير قواعده مستقلًا عن نشراتك.

دليل تشغيل: حدّد، أصلح، تحقق

تتبع عملية «4xx الأخرى» الحلقة القصيرة نفسها لكل عنوان في هذه الفئة، أيًا كان الرمز المحدد خلفها — حدد الرمز الحقيقي أولًا، لأن مسار الإصلاح يتفرع جذريًا من هناك.

1. أكد الرمز الحي. شغّل فحص عنوان URL ← اختبار العنوان المباشر للتأكد من أن Google تتلقى 4xx حاليًا ومعرفة ما تلقته — فقد يكون صف التقرير قديمًا، ولا يعرض الاختبار الحي الفاشل الترويسات الخام دائمًا. قاطع ذلك مع تقرير إحصاءات الزحف لأمثلة تمثيلية لما تلقاه الزاحف المجدول فعليًا.

2. أعد إنتاجه مع مطابقة الطلب الأصلي. افتح العنوان في علامة Network في DevTools أو استخدم curl — اختبر طريقة GET، لا curl -I فقط (فهو يرسل HEAD وقد يعطي نتيجة مختلفة). وإذا شككت في قاعدة خاصة بالروبوت، فاجلبه بصفة Googlebot، ويفضل من خارج شبكتك، لتشغيل القاعدة التي قد يواجهها زحف حقيقي — لكن لاحظ أن تبديل user-agent وحده لا يعيد إنتاج IP Google أو بروتوكولها أو فئة عميلها.

3. اقرأ السجلات. افحص سجلات الخادم وCDN وWAF ووكيل المصادقة بحثًا عن الرمز الدقيق والقاعدة أو الشرط الذي أنتجه — فهذا أسرع عادةً من التخمين من المتصفح، وغالبًا الطريقة الوحيدة لرؤية بيانات الاستجابة الخام التي لا يعرضها الاختبار الحي.

4. اربط الرمز بسببه. 400/405/408/414 ← مشكلة تأطير طلب أو طريقة أو مهلة أو طول URI. 411/413/415/422 ← لا تشخصها كأخطاء محتوى طلب إلا بدليل على الطريقة/الجسم الفعليين. 410 ← إزالة مقصودة (أكد أنه ينبغي أن يختفي). 421 ← تحقق من منع HTTP/2 الموثق لدى Google وما أعاده بديل HTTP/1.1. 451 ← مراجعة قانونية/سياساتية. 4xx من طبقة أمان ← حجب يسمح به على نحو ضيق. 429 محتمل ← تحديد معدل يعالج كحمل خادم — وموضعه في التقرير غير مؤكد في أي اتجاه.

5. أصلح حسب السبب. أخطاء تأطير الطلب ← صحح المصدر (عنوان سيئ/طويل، طريقة خاطئة، مهلة) وتوقف عن ربط/إدراج العنوان السيئ. أخطاء محتوى الطلب ← أكد الطلب الفعلي من السجلات قبل تخفيف أي حد. إزالة 410 أو خروج 421 من HTTP/2 ← اتركها ونظف خرائط المواقع والروابط الداخلية (410) أو أكد بديل البروتوكول (421). 451 ← أحلها إلى مراجعة قانونية/سياساتية. حجب طبقة أمان ← تحقق من Googlebot الحقيقي (DNS عكسي أو نطاقات IP منشورة) واسمح بالهوية والمسار على نحو ضيق، لا بسلسلة user-agent ولا قاعدة شاملة. 429/تحديد معدل ← أبقِ التحديد وأضف Retry-After كأفضل ممارسة (اختياري وفق RFC 6585، وليس جدولًا مؤكدًا لـGooglebot)؛ وإذا كانت قاعدة ما تعيد 4xx إلى Googlebot لمجرد خنقه فبدلها بـ429 أو 503.

6. تحقق وتوقف. أكد أن الاختبار الحي يعيد 200 للصفحات التي تريد فهرستها، ثم انقر التحقق من الإصلاح في صف «4xx الأخرى» و/أو اطلب الفهرسة للعناوين ذات الأولوية. تجعل استجابة 200 العنوان مؤهلًا لإعادة الزحف وربما الفهرسة — لكنها لا تضمن ذلك أو جدولًا زمنيًا ثابتًا — فلا تطلب بالجملة قبل إصلاح السبب، وإلا عدت إلى الفئة نفسها.

مطالبات ذكاء اصطناعي جاهزة للاستخدام

مطالبات للنسخ واللصق لتصنيف رمز «4xx الأخرى» الذي تراه وتحديد الإصلاح المناسب من مخرجات التشخيص الخام. أكد النتيجة دائمًا مقابل إعداد الخادم/WAF الفعلي قبل تغيير أي شيء.

صنّف الرمز والسبب من مخرجات curl

I'm diagnosing a "Blocked due to other 4xx issue" status in Google Search
Console. Below is the raw output of GET and HEAD requests to the URL (note
that curl -I alone only tests HEAD, which can differ from what Google's GET
request receives). Tell me the exact status code, and classify the likely
cause as one of: (1) a request-framing/timeout/URI-length issue (400, 405,
408, 414), (2) a request-content condition needing body evidence (411, 413,
415, 422), (3) an intentional 410 Gone, (4) a possible HTTP/2 opt-out (421),
(5) a legal/policy block (451), (6) a WAF/CDN/security-plugin block, or (7) a
mislabeled 429 rate limit. Explain which detail in the output pointed you to
that answer, and flag anything you can't determine from this output alone.

CURL OUTPUT (GET and HEAD):
[paste]

صنّف سطرًا من سجل WAF/الخادم

I'm investigating an "other 4xx" status Googlebot is hitting on a page I want
indexed. Below is a log line (or a few) from my server/CDN/WAF showing the
blocked request. Tell me whether this looks like a bot-identity rule
(user-agent or IP based), a rate-limit/challenge rule that should really be
returning 429, or a request/validation error, and what I'd need to change or
allowlist to fix it without disabling the underlying protection.

LOG LINE(S):
[paste]

تحقق منطقيًا من الإصلاح قبل نشره

I'm about to change how a URL responds because it's currently returning
[status code] and showing as "Blocked due to other 4xx issue" in Search
Console. Here's what I'm about to change: [describe]. Point out anything I
might be missing — for example, whether this could accidentally expose or
re-index a page that's supposed to stay gone (a 410 I'm about to undo), or
whether I should allowlist verified Googlebot instead of loosening a security
rule for everyone.

اختبر نفسك: «محظور بسبب مشكلة 4xx أخرى»

خمسة أسئلة عن معنى فئة «4xx الأخرى»، واستثناء 429، وكيفية تشخيصها وإصلاحها. اختر إجابة لكل سؤال ثم تحقق منها.

أدوات لتشخيص حالات «4xx الأخرى» وإصلاحها

• فاحص حالة HTTP — الصق العنوان المتأثر (أو مجموعة) لتأكيد رمز الحالة الحقيقي خلف تسمية GSC، ورؤية سلسلة الاستجابة كاملة، والتقاط إعادة التوجيه التي تحدث قبل 4xx.
• متحقق Googlebot — افحص ما إذا كان IP يدعي أنه Googlebot حقيقيًا (نطاقات IP المنشورة مع تأكيد DNS العكسي) قبل السماح له عبر WAF أو CDN أو إضافة أمان.
• Google Search Console — فحص عنوان URL ← اختبار العنوان المباشر — أقرب وسيلة لرؤية الاستجابة الدقيقة التي يتلقاها Googlebot الآن بدل صف تقرير قديم محتمل.
• curl -I — أسرع طريقة لقراءة سطر الحالة الخام لعنوان، وإعادة الجلب بصفة Googlebot إذا شككت في قاعدة خاصة بالروبوت.
• لوحة سجلات الخادم/CDN/WAF (Cloudflare أو Akamai أو Sucuri أو سجل إضافة الأمان نفسها، وغير ذلك) — اعثر على الرمز الدقيق والقاعدة أو الشرط الذي أنتجه.

المشكلات الشائعة حسب الرمز

كل رمز يصل إلى «4xx الأخرى» هو حالة مستقلة فعلًا من عرض وسبب وإصلاح — فالفئة لا تملك سببًا جذريًا واحدًا، لذلك تعامل مع هذه البطاقات كمرجع منفصل لا كسلسلة واحدة.

400 Bad Request

العَرَض: يعيد العنوان المتأثر 400 للطلب.

السبب (الأسباب) المحتمل: هدف طلب مشوه أو مرمّز بصورة سيئة، أو مشكلة صياغة، أو تأطير Host/توجيه يرفضه تطبيقك أو طرف الحافة مباشرةً (معاملات استعلام سيئة، أو رموز غير صالحة، أو توجيه غير متوقع).

الإصلاح + الفحص: قارن الطلب الدقيق الذي تلقاه الخادم بما قصدت توليده؛ صحح العنوان وتوقف عن توليد النسخة المكسورة أو ربطها. أعد الفحص بطلب GET (لا curl -I فقط، فهو HEAD) حتى يعيد 200.

405 Method Not Allowed

العَرَض: يعيد العنوان 405 لبعض الطلبات رغم أن الصفحة نفسها تبدو سليمة في المتصفح.

السبب (الأسباب) المحتمل: الطريقة المستخدمة في HTTP غير مسموحة لهذا المسار — غالبًا قاعدة خادم أو CDN لا تسمح إلا بـGET على ذلك المسار، بينما يرسل شيء ما HEAD أو طريقة أخرى يرفضها. افحص ترويسة الاستجابة Allow لمعرفة المسموح، ولا تفترض أن فشل HEAD وحده (مثل curl -I) يثبت فشل GET بالطريقة نفسها.

الإصلاح + الفحص: اسمح بالطريقة الصحيحة للمسار. أعد الاختبار بطريقتي HEAD وGET.

408 Request Timeout

العَرَض: يعيد العنوان 408 أحيانًا، أو يظل الاتصال معلقًا قبل إعادة رمز.

السبب (الأسباب) المحتمل: لم يكتمل الاتصال أو الطلب ضمن مهلة الخادم أو الوكيل أو CDN — إنها مشكلة توقيت/اتصال، لا دليل على توقف الخادم عمومًا.

الإصلاح + الفحص: اربط توقيت الاتصال والطلب عبر سلسلة الوكيل/CDN/الأصل والبروتوكول المستخدم. أعد الاختبار بعد ضبط المهلة المناسبة أو إصلاح مسار الأصل البطيء.

410 Gone

العَرَض: يعيد العنوان 410، وتتضمن قيمة «4xx الأخرى» صفحات تظن أنك حذفتها عمدًا.

السبب (الأسباب) المحتمل: إزالة مقصودة — وهذا يعمل كما صُمم للصفحات التي ينبغي أن تختفي. إذا كان ينبغي أن تكون الصفحة حية، فـ410 خطأ.

الإصلاح + الفحص: إذا كانت الإزالة مقصودة، فأزل العنوان من خرائط المواقع والروابط الداخلية كي يتوقف عن الظهور بوصفه «مشكلة». وإن لم تكن مقصودة فأعد الصفحة.

411 Length Required

العَرَض: يعيد العنوان 411 لطلبات معينة.

السبب (الأسباب) المحتمل: يصر الخادم على وجود ترويسة Content-Length في طلب يحمل جسمًا — وهو أمر غير معتاد لجلب صفحة عادية. أكد من السجلات أن الطلب حمل محتوى فعلًا قبل افتراض أن هذه مشكلة زحف عادية.

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

413 Payload Too Large

العَرَض: يعيد العنوان 413، عادةً للطلبات ذات الجسم أو الترويسات/ملفات الارتباط الكبيرة.

السبب (الأسباب) المحتمل: يتجاوز محتوى الطلب حدًا للحجم وضعه الخادم أو CDN أو WAF — وهذا يتعلق بالطلب الوارد، لا بحجم استجابة الصفحة نفسها.

الإصلاح + الفحص: أكد الطلب الوارد من السجلات قبل رفع أي حد؛ أصلح ما يولد الطلب الضخم، أو ارفع الحد فقط إذا كان ضيقًا فعلًا أمام طلب مشروع. أعد الاختبار للتأكد من أن الطلب بالحجم الطبيعي يعيد 200.

414 URI Too Long

العَرَض: يعيد العنوان 414، عادةً لعنوان مولد أو ذي معاملات طويل.

السبب (الأسباب) المحتمل: يتجاوز URI الطلب نفسه حد الطول — غالبًا بسبب توليد معاملات أو سلسلة إعادة توجيه سارت خطأ، لا بسبب محتوى الصفحة.

الإصلاح + الفحص: أصلح توليد العنوان/إعادة التوجيه من المصدر بدل رفع الحد بلا تفكير، ونظف أي إدخالات في خريطة الموقع/الروابط الداخلية تشير إلى النمط الطويل.

415 / 422 (Unsupported Media Type / Unprocessable Entity)

العَرَض: يعيد العنوان 415 أو 422 رغم أن الطلب يبدو سليمًا في المتصفح.

السبب (الأسباب) المحتمل: فهم الخادم الطلب لكنه رفض نوع محتواه أو فشل قاعدة تحقق في محتواه/تعليماته — وهذا غير معتاد لجلب GET لصفحة عادية. أكد محتوى الطلب الفعلي قبل افتراض أن المشكلة عامة في محتوى الصفحة.

الإصلاح + الفحص: أكد الطلب من السجلات، ثم أصلح قاعدة التحقق أو معالجة نوع المحتوى، أو أصلح ما يولد الطلب المرفوض. أعد الاختبار حتى تصبح الاستجابة 200.

421 Misdirected Request

العَرَض: يعيد العنوان 421، أحيانًا عبر HTTP/2 فقط.

السبب (الأسباب) المحتمل: وُجّه الاتصال إلى مكان خطأ — لكن Google توثق أيضًا إعادة 421 كطريقة مقصودة لإخراج مسار من زحف HTTP/2، ولذلك لا تكون الصفحة مكسورة تلقائيًا.

الإصلاح + الفحص: أكد ما إذا كان الطلب عاد إلى HTTP/1.1 وما كانت الاستجابة النهائية. إذا كان هذا خروجًا مقصودًا من HTTP/2 فلا يحتاج إصلاحًا؛ وإن لم يوجد بديل وكانت الصفحة غير قابلة للوصول عبر أي بروتوكول، فأصلح توجيه الاتصال/SNI/معالجة Host.

451 — غير متاح لأسباب قانونية

العَرَض: يعيد العنوان 451.

السبب (الأسباب) المحتمل: حجب قانوني أو متعلق بالسياسة، قد يكون مقصودًا تمامًا (مثل تقييد المحتوى في ولايات قضائية معينة) — لا تتعامل معه كخطأ إعداد جغرافي/WAF عادي.

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

429 مخطئًا على أنه «4xx أخرى»

العَرَض: توقعت العثور على 4xx عادي هنا، لكن الرمز الحقيقي اتضح أنه 429.

السبب (الأسباب) المحتمل: بدأ تحديد المعدل في طلبات Googlebot. تتعامل Google مع 429 كإشارة إلى حمل زائد على الخادم، لا خطأ عميل مثل بقية هذه الفئة، ولذلك من المعقول أن يظهر 429 الحقيقي كمشكلة زحف/خادم لا أن يبقى موسومًا «4xx أخرى» — لكن وثائق Google تغطي سلوك المعالجة لا تصنيف التقرير، فاعتبر موضعه الدقيق غير مؤكد.

الإصلاح + الفحص: لا تعطل تحديد المعدل المشروع — أضف ترويسة Retry-After كأفضل ممارسة (اختيارية وفق RFC 6585، ولا تؤكد Google أن Googlebot يجدول زحفه التالي منها). إذا كانت قاعدة ما تعيد 4xx إلى Googlebot لمجرد خنقه، فبدلها بـ429 أو 503.

أثبت أن الإصلاح نجح فعلًا

بعد إصلاح خطأ الطلب/التحقق، أو تنظيف 410 مقصودة، أو السماح لـGooglebot المتحقق منه، أو التأكد من معالجة تحديد المعدل كما ينبغي، هذه هي الفحوص التي تفرق بين «تغير الإعداد» و«أصبحت Google قادرة فعلًا على الوصول إلى الصفحة». نفذها بالترتيب.

الاختبار 1 — يعيد الطلب الجديد الحالة المتوقعة

• الاختبار المطلوب — نفذ curl بطلب GET على العنوان المتأثر (مطابقًا للطريقة التي تستخدمها Google فعلًا — فـcurl -I وحده يختبر HEAD)، أو افحصه باستخدام فاحص حالة HTTP.
• النتيجة المتوقعة — للصفحة التي تريد فهرستها، يقرأ سطر الحالة HTTP/1.1 200 OK. أما الصفحة التي أزيلت عمدًا، فبقاء الحالة 410 مقبول — والفحص المهم هناك هو الاختبار 3.
• تفسير الفشل — استمرار 4xx الأصلي يعني أن الإصلاح لم يُطبق فعليًا على ذلك المسار، أو أنك تختبر عنوانًا/بيئة خاطئة. أما اختلاف 4xx عن السابق (مثل تحول 400 إلى 403) فيعني أنك بدلت حجبًا بآخر — افحص قاعدة WAF/CDN.
• نافذة المراقبة — فورية — يجيب الخادم بمجرد أن يصبح التغيير حيًا.
• مُشغّل التراجع — إذا أدى تخفيف قاعدة تحقق أو حجم إلى سلوك لم تقصده، فأعد القاعدة الأصلية وأصلح السبب الجذري بطريقة أخرى (مثل تصحيح الطلب بدل رفع الحد).

الاختبار 2 — تؤكد Google أنها تستطيع الآن الوصول إلى الصفحة

• الاختبار المطلوب — شغّل فحص عنوان URL ← اختبار العنوان المباشر في Google Search Console على العنوان المتأثر.
• النتيجة المتوقعة — للصفحة التي تريد فهرستها، ينجح الاختبار الحي ويعرض 200 من دون 4xx.
• تفسير الفشل — إذا ظل الاختبار الحي يعرض 4xx بعد نجاح اختبار curl المجهول، فاشتبِه في قاعدة مخصصة لنطاقات IP الخاصة بـGooglebot (مشكلة قائمة سماح WAF/CDN)، لا مشكلة طلب عامة.
• نافذة المراقبة — من فورية إلى بضع دقائق بعد الإصلاح.
• مُشغّل التراجع — لا ينطبق — هذا اختبار للقراءة فقط؛ فإذا ظل فاشلًا فارجع إلى فرع فشل الاختبار 1 بدل التراجع عن شيء.

الاختبار 3 — تزول الحالة (أو تبقى ثابتة عمدًا) في تقرير فهرسة الصفحات

• الاختبار المطلوب — استخدم التحقق من الإصلاح في صف «محظور بسبب مشكلة 4xx أخرى» في تقرير فهرسة الصفحات، وراقب عدد الفئة خلال الأسابيع التالية (انظر عدسة كيفية القياس).
• النتيجة المتوقعة — تصبح العناوين التي أصلحتها مؤهلة للخروج من الفئة بعد أن تعيد Google الزحف إلى 200 المصلح — وهذا ليس ضمانًا لإعادة الفهرسة أو لجدول زمني محدد، بل أهلية فقط. وتبقى العناوين ذات 410 المقصودة في الفئة، لكن خرائط المواقع والروابط الداخلية لا تعود تشير إليها.
• تفسير الفشل — لا توجد دورية إعادة محاولة منشورة، فلا تعتبر بطء التحقق فشلًا جديدًا؛ وإذا لم ينخفض العدد بعد أسبوعين لعناوين أصلحتها فعلًا، فأعد الاختبار 1 للتأكد من بقاء الإصلاح (فقد تعيد عملية نشر أو ذاكرة CDN القاعدة القديمة بصمت).
• نافذة المراقبة — من أيام إلى بضعة أسابيع، مع تتبع عدد الفئة.
• مُشغّل التراجع — أعد النظر في الإصلاح الأساسي فقط إذا بدأ الاختبار 1 بالفشل مجددًا — لا تطارد توقيت تقرير فهرسة الصفحات.

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