اللغات

الحظر بسبب طلب غير مصرح به (401)

ما معنى حالة فهرسة الصفحات في Google Search Console «الحظر بسبب طلب غير مصرح به (401)»، وكيف تختلف عن 403 وفق RFC 9110، وما أسبابها الشائعة، وكيف تشخّصها كروبوت، وما الإصلاح الصحيح وفق نوع الصفحة — عامة أو خاصة أو محجوبة خطأً من WAF أو مدفوعة.

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

«الحظر بسبب طلب غير مصرح به (401)» حالة في تقرير فهرسة الصفحات في Google Search Console تعني أن Googlebot تلقى HTTP 401 (المصادقة مطلوبة) عند محاولته زحف عنوان URL. لا تقدم Google بيانات اعتماد، لذلك لا ترى المحتوى — ولا تُفهرس الصفحة ويسقط عنوان URL المفهرس سابقًا الذي يعيد 401 في النهاية. وفق RFC 9110 يفتقد 401 بيانات اعتماد صالحة (لم تُرسل أو رُفضت)، بينما يعني 403 أن الخادم فهم الطلب ورفضه لأسباب لا تتعلق دائمًا ببيانات الاعتماد. تتعامل Google مع كل 4xx باستثناء 429 بالطريقة نفسها للفهرسة، لكن السبب والإصلاح يختلفان بحسب الصفحة: أزل المصادقة عن صفحة عامة محجوبة خطأً؛ اسمح لـGooglebot المتحقق منه عبر IP/reverse-DNS (لا user-agent قابل للانتحال) إذا كان أمن الروبوتات يحجبه؛ أبقِ المصادقة على المحتوى الخاص/التجريبي؛ واستخدم البيانات المنظمة للمحتوى المدفوع بدل 401 شامل للمحتوى الاشتراكي. **"Loads fine in my browser"** _(الترجمة العربية)_ «تُحمّل عندي» فخ لأنك مصادق وGooglebot ليس كذلك. URL Inspection Live Test وcurl -I؛ وغياب WWW-Authenticate يعني استجابة مشوهة لا دليلًا على أن WAF هو السبب. يؤكد Live Test وValidate Fix الوصول لا الفهرسة، ولا يوجد جدول زمني منشور لإعادة المحاولة.

الخلاصة — تعني حالة «الحظر بسبب طلب غير مصرح به (401)» أن Googlebot تلقى HTTP 401 (Unauthorized) — بوابة مصادقة لا يستطيع اجتيازها. لا تقدم Google بيانات اعتماد، لذلك لا يرى المحتوى أبدًا: لن تُفهرس الصفحة، وسيسقط عنوان URL المفهرس سابقًا الذي يعيد 401 مع مرور الوقت. 401 مقابل 403 بدقة وفق RFC 9110: يفتقد 401 بيانات الاعتماد الصالحة (لم تُرسل أصلًا أو رُفضت البيانات المُرسلة)؛ أما 403 فيعني أن الخادم فهم الطلب ورفضه، لأسباب لا تتعلق دائمًا ببيانات الاعتماد. تتعامل Google مع كل 4xx باستثناء 429 بالطريقة نفسها للفهرسة، فتتقارب النتيجة — لكن السبب والإصلاح يختلفان، ويتوقف الإصلاح على نوع الصفحة: أزل متطلب المصادقة عن الصفحة العامة المحجوبة بالخطأ؛ اسمح لـGooglebot المتحقق منه بالمرور عبر IP أو reverse-DNS (لا عبر user-agent القابل للانتحال) إذا حجبته أداة أمان الروبوتات خطأً؛ أبقِ المصادقة على المحتوى الخاص أو التجريبي فعلًا؛ واستخدم البيانات المنظمة للمحتوى المدفوع من Google بدل 401 شامل على المحتوى الاشتراكي القابل للفهرسة. «تُحمّل عندي في المتصفح» فخ — فأنت مصادق، وGooglebot ليس كذلك. لا تستخدم 401/403 لخفض معدل الزحف. شخّص كروبوت (URL Inspection Live Test وcurl -I) — فغياب ترويسة WWW-Authenticate يعني أن الاستجابة مشوهة، لا أن WAF هو السبب. يؤكد Live Test وValidate Fix الوصول، لا الفهرسة، ولا يوجد جدول زمني منشور لإعادة المحاولة.

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

تبلغ تسمية فهرسة الصفحات عن الاستجابة التي رصدتها Google؛ ولا تحدد أي قاعدة مصادقة أو CDN أو تطبيق أنشأها. Evidence for this claim The Page Indexing report identifies URLs where Google encountered an authorization request. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: Google: Page indexing report أما سلوك الفهرسة الأساسي فيأتي من معالجة Google الموثقة لاستجابات 4xx. Evidence for this claim Google treats 4xx responses other than 429 as if the content does not exist for indexing. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: Google: HTTP status codes

يأتي الرمز مباشرة من استجابة الخادم. طلب Googlebot عنوان URL فتلقى HTTP 401، أي حالة «Unauthorized» — فالصفحة خلف بوابة مصادقة (HTTP Basic Auth أو جدار تسجيل دخول أو قاعدة تحكم في الوصول). وتعريف Google نفسه في تقرير فهرسة الصفحات هو أن طلبًا للمصادقة حجب الصفحة عن Googlebot؛ وإذا أردت فهرستها فعليك إما إزالة متطلب المصادقة أو السماح لـGooglebot بالمرور بعد التحقق من هويته.

في مقالتي رموز حالة HTTP وتأثيرها في SEO أصف 401 بأنه يعني أن العميل لم يعرّف نفسه أو يتحقق منه عند الحاجة — وهو نموذج ذهني مفيد، لكنه ليس تعريف البروتوكول الكامل. والقاعدة الدقيقة في RFC 9110 هي أن 401 يعني افتقاد الطلب بيانات اعتماد مصادقة صالحة للمورد، وقد يأتي أيضًا بعد أن يرفض الخادم بيانات الاعتماد؛ لذلك لا يعني 401 دائمًا أن Googlebot (أو المتصفح) لم يرسل شيئًا، بل إن ما قُدم لم يكن صالحًا. وفي كلتا الحالتين تكون النتيجة العملية لـGooglebot واحدة: لا يملك بيانات اعتماد يقدمها، فلا يتجاوز البوابة.

ماذا تفعل Google بحالة 401؟

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

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

لن أعطيك شيئًا لا أستطيع إثباته: جدولًا زمنيًا محددًا لإعادة المحاولة. تعيد Google الزحف مع مرور الوقت، لكن الوثائق لا تنشر جدولًا مضمونًا من نوع «يعيد Googlebot محاولة 401 كل N يومًا»، لذلك لن أتظاهر بوجوده. تعامل مع إعادة الزحف على أنها «سيعود إليها في وقت ما» لا كساعة توقيت.

401 مقابل 403 مقابل أخطاء 4xx الأخرى — الجزء المهم

هذا هو الفرق الذي تطمسه معظم الشروحات، وهنا تكمن القيمة الحقيقية. من ناحية الفهرسة، تتعامل Google مع 401 و403 بالطريقة نفسها (قاعدة 4xx باستثناء 429). لكن السبب والإصلاح مختلفان لأن الرمزين يعنيان شيئين مختلفين:

  • 401 Unauthorized وفق تعريف RFC 9110 — يفتقد الطلب بيانات اعتماد مصادقة صالحة للمورد المستهدف. ويشمل ذلك حالتين: لم تُرسل بيانات اعتماد إطلاقًا، أو أُرسلت ثم رفضها الخادم. ويجب أن تحمل استجابة 401 المطابقة للمواصفة ترويسة WWW-Authenticate تسمي تحديًا واحدًا على الأقل. أما صيغتي المختصرة — «لم يعرّف العميل نفسه أو يتحقق منه عند الحاجة» — فهي اختصار مفيد للحالة الشائعة، فاعتبرها نموذجًا ذهنيًا لا قاعدة شاملة.
  • 403 Forbidden وفق RFC نفسها — فهم الخادم الطلب لكنه يرفض تنفيذه. وقد تكون بيانات الاعتماد سببًا، لكن المواصفة تصرح بأن الطلب «قد يكون محظورًا لأسباب لا علاقة لها ببيانات الاعتماد». لذلك لا يعني 403 دائمًا أن «العميل معروف/مصادق عليه لكنه يفتقد الصلاحيات» — فهذا نمط شائع عمليًا، لا ضمان. وفي تقرير فهرسة الصفحات لدى Google تحديدًا، يعني 403 المرسل إلى Googlebot (الذي لا يرسل بيانات اعتماد أصلًا) غالبًا أن الخادم يعيد الخطأ على نحو غير صحيح — بسبب جدار حماية أو WAF أو قاعدة روبوتات غير مهيأة. (ولهذا توجد حالة شقيقة Blocked due to access forbidden (403)؛ ومسار تشخيصها يتداخل كثيرًا.)

يظل الاختصار الذهني العملي مفيدًا للفرز: 401 ≈ «بوابة مصادقة نسيت رفعها» (موقع تجريبي أو مصادقة HTTP متروكة)، بينما 403 ≈ «قاعدة أمان تحظر Googlebot خطأً». النتيجة الفهرسية واحدة والسبب الجذري مختلف — فلا تتعامل مع أي من الاختصارين كأنه الحد الفعلي للبروتوكول. يوجد جدول القرار في علامة أوراق الغش.

لماذا ترى هذه الحالة؟ — الأسباب الشائعة

في صفحة تريد فعلًا فهرستها، يكون 401 في الغالب واحدًا من الأسباب الآتية:

  • موقع تجريبي أو تطويري خلف Basic Auth. حميت بيئة تجريبية بكلمة مرور (وهو التصرف الصحيح)، لكن Google اكتشفت عنوان URL بطريقة ما — رابطًا داخليًا أو خريطة موقع أو مرجعًا متسربًا — وتبلغ الآن عن 401. إذا كان عنوان الموقع التجريبي لا ينبغي أن يكون عامًا فعلًا، فهذا متوقع (انظر قسم 401 المقصود).
  • مصادقة HTTP عرضية في قسم عام. قاعدة .htpasswd أو إضافة «قريبًا» أو حاجز وضع الصيانة بقي مفعّلًا فوق مجلد يفترض أن يكون منشورًا.
  • WAF أو CDN أو قائمة سماح IP تحظر Googlebot. هذه الحالة خادعة. قد يعيد Cloudflare أو Akamai أو Sucuri أو قائمة سماح جغرافية/IP رمز 401 (أو 403) إلى عناوين IP الخاصة بـGooglebot بينما يخدم البشر طبيعيًا. تبدو الصفحة «عاملة للجميع» لأن كل من يختبرها يأتي من عنوان مسموح.
  • جدار تسجيل دخول على محتوى اشتراكي أو مدفوع تريد فهرسته فعلًا. يبقي 401 الشامل Googlebot خارجًا تمامًا — والإصلاح ليس إضعاف الحاجز، بل استخدام البيانات المنظمة المدعومة من Google للمحتوى المدفوع (انظر الفرع الرابع أدناه).

كيف تشخّص الحالة؟ — اختبر كروبوت لا كمتصفح

أكبر فخ هنا هو «تعمل عندي». بالطبع تعمل — فأنت مصادق، أو أن عنوان IP الخاص بك ضمن قائمة السماح، أو أن متصفحك يحمل cookie جلسة. ولا يملك Googlebot شيئًا من ذلك. لذلك شخّص كروبوت:

  • URL Inspection → Live Test (في GSC). هذا أقرب ما يمكنك الوصول إليه لرؤية الاستجابة الفعلية التي يتلقاها Googlebot. شغّله على عنوان URL المتأثر؛ فإذا تعذر جلبه بسبب المصادقة، فقد أكدت أن 401 حقيقي وقابل لإعادة الإنتاج.

  • curl -I من سياق غير مصادق. اطلب عنوان URL بلا cookies أو بيانات اعتماد واقرأ سطر الحالة:

    curl -I https://www.example.com/page/
# Look for:  HTTP/1.1 401 Unauthorized
# and a WWW-Authenticate: header confirming an auth gate

    إذا حصلت curl (الذي لا يرسل جلسة أو مصادقة) على 401 بينما يحصل متصفحك على 200، فهذه الفجوة هي المشكلة — متصفحك مصادق وGooglebot ليس كذلك. تفرض RFC 9110 على 401 المطابق للمواصفة حمل ترويسة WWW-Authenticate — ووجودها يؤكد تحدي مصادقة حقيقي. أما غيابها فلا يعطيك الجواب: بل يخبرك أن الاستجابة مشوهة أو ناقصة، لا أي طبقة أنشأتها. لا تقفز مباشرة إلى «لا بد أن WAF هو السبب» بسبب غياب الترويسة وحده.

  • تحقق من كون الحجب مرتبطًا بعنوان IP. إذا أعاد curl من جهازك 200 لكن فشل Live Test في GSC، فهذه إشارة حقيقية إلى أن شيئًا يعتمد على عنوان المصدر أو مسار الطلب — لكن أكد ذلك بمقارنة سجلات edge/CDN وسجلات الأصل وطبقة التطبيق وأي مزود هوية قبل تسمية WAF سببًا. وقد يوجه طلب HEAD (الذي يرسله curl -I) أو يخزنه بطريقة مختلفة عن GET، لذلك تحقق أيضًا بطلب GET مجهول.

كيف تصلح الحالة؟ — أربعة فروع وفق نوع الصفحة الفعلي

لا يوجد إصلاح واحد — بل أربعة، واختيار الخطأ قد يكشف محتوى أردت حمايته أو يترك صفحة قابلة للفهرسة خلف حاجز دائم. صنّف عنوان URL ضمن أحدها قبل لمس أي إعداد:

1. محتوى خاص أو تجريبي فعلًا ← أبقِ المصادقة ولا تلمسها. إذا كان لا ينبغي أن يكون عنوان URL عامًا حقًا، فإن 401 يعمل كما صُمم — فالمصادقة من جهة الخادم طريقة مشروعة توصي بها Google لإبعاد المحتوى عن الجميع، بما في ذلك Googlebot. وقد أوضح John Mueller هذه النقطة للمواقع التجريبية: الطريقة الصحيحة لإخفاء موقع هي المصادقة من جهة الخادم، عبر IP أو cookie أو مصادقة الخادم المعتادة، بحيث يُحجب المستخدمون العاديون — ومنهم Googlebot — عن رؤية المحتوى. لا تسمح لـGooglebot بتجاوز حاجز يحمي محتوى خاصًا فعلًا لمجرد إزالة صف التقرير؛ فهذا يهزم الغرض من الحاجز. الإصلاح هنا هو نظافة الاكتشاف لا فتح الوصول: تأكد من أن عنوان URL غير مرتبط أو موجود في خريطة موقع أو مُرسل إلى خاصية Search Console هذه، واترك المصادقة قائمة.

2. صفحة عامة حُجبت بالخطأ ← أزل متطلب المصادقة. إذا كان ينبغي فهرسة الصفحة وكان الحاجز متروكًا — Basic Auth أو جدار تسجيل دخول أو إضافة وضع الصيانة — فأوقفه لهذا المسار. هذه هي الحالة المباشرة: بمجرد أن يحصل الطلب المجهول على 200، تُفتح الصفحة أمام Googlebot.

3. صفحة عامة حجبها أمن الروبوتات خطأً ← اسمح لـGooglebot المتحقق منه، لا لسلسلة user-agent حرفيًا. عندما يرفض WAF أو CDN أو قائمة سماح IP Googlebot في صفحة تريد إبقاءها عامة، اسمح بـGooglebot المتحقق منه عبر IP أو reverse-DNS. يمكن انتحال user-agent بسهولة؛ إذ يستطيع أي شخص الادعاء بأنه Googlebot. والمسار الذي توصي به Google هو التحقق من الزاحف عبر نطاقات IP المنشورة أو فحص DNS عكسي ثم أمامي، ثم تمرير تلك الطلبات المحددة عبر الحاجز — أنت لا تزيل قاعدة الأمان، بل تنشئ استثناءً متحققًا لها. لإصلاح الإيجابية الكاذبة نفسها:

  • حدد القاعدة التي تعيد 401/403 إلى Googlebot (أحداث Firewall في Cloudflare أو سجلات Akamai/Sucuri أو سجلات edge/origin/application الخاصة بك).
  • اسمح بنطاقات IP المتحققة الخاصة بـGoogle (أو فئة الروبوت) بدل تعطيل الحماية بالكامل.
  • أعد الاختبار باستخدام URL Inspection Live Test حتى تتمكن Google من جلب الصفحة.

4. محتوى اشتراكي أو مدفوع تريد فهرسته ← لا تستخدم 401 شاملًا أصلًا. إذا كانت الصفحة مقيدة بالتسجيل أو الاشتراك لكنك تريد اكتشافها في البحث، فإن 401 الصارم أداة خاطئة مهما كان السبب — فلا يستطيع Googlebot جلبها. توثق Google تنفيذًا مدعومًا للمحتوى المدفوع بدلًا من ذلك: قدّم الصفحة مع البيانات المنظمة المناسبة للمحتوى المدفوع (isAccessibleForFree وhasPart والخصائص ذات الصلة) كي تتمكن Google من فهرسة الجزء المجاني المعاين دون فتح الصفحة كلها. هذا تغيير في الترميز واستجابة الخادم، لا تغيير في حاجز المصادقة.

تحقق من الإصلاح واضبط التوقعات

بعد أن تفتح الصفحة فعلًا (وتؤكد عبر curl/Live Test أن الطلب المجهول يعيد 200)، كن دقيقًا بشأن ما يؤكده كل إجراء:

  • يؤكد Live Test الوصول، لا الفهرسة. توضح وثائق URL Inspection لدى Google أن الاختبار المباشر يؤكد فقط ما إذا كانت Google-InspectionTool تستطيع حاليًا الوصول إلى الصفحة وتحليلها — ولا يوجد اختبار يضمن أن الصفحة ستنتهي في الفهرس أو ستظهر في نتائج البحث. يعني نجاح Live Test أن الحاجز مفتوح؛ ولا يعدك بما سيحدث بعد ذلك.
  • Validate Fix اختياري وليس مطلوبًا. تحدّث Google عدد المشكلات كلما أعادت زحف صفحة، سواء نقرت Validate Fix أم لا. استخدمه للتتبع الداخلي عند وجود إصلاح حقيقي — ولا تتحقق من عنوان URL يفترض أن يبقى خاصًا، ولا تتعامل مع التحقق نفسه كأنه يسرّع إعادة الفهرسة.
  • لا تتوقع فهرسة فورية. تستغرق إعادة الزحف وإعادة الفهرسة وقتًا، وكما ذكرنا لا يوجد جدول زمني منشور لإعادة المحاولة سأقتبسه لك. راقب حالة الفهرسة الفعلية وأداء البحث منفصلين عن حالة التقرير؛ فلا Live Test ولا Validate Fix يضمن اختيار canonical أو الظهور في البحث.
  • أسطورة ينبغي إسقاطها: إن 401 في GSC ليس عقوبة ولا إجراءً يدويًا. إنه حالة وصول للزحف. ولا يضر ترتيب صفحاتك الأخرى ولا «يضع» موقعك في قائمة سوداء — بل يبقي الصفحة المحجوبة خارج الفهرس فحسب.

أين تقع هذه الحالة ضمن التقرير؟

هذه إحدى حالات HTTP في تقرير فهرسة الصفحات — ومن شقيقاتها Blocked due to access forbidden (403) وحالات 4xx و404 الأخرى، وحالة خطأ خادم 5xx. لمعرفة التقرير نفسه وطريقة قراءة جدول «لماذا لا تُفهرس الصفحات»، راجع مركز تقرير فهرسة الصفحات. أما الآليات الأساسية — كيف يجلب Googlebot المحتوى وما الذي تعنيه رموز الحالة له — فتغطيها موضوعات الزحف والفهرسة.

Add an expert note

Pin an expert quote

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