صفحة مفهرسة بلا محتوى

الخلاصة — تعني حالة “Page indexed without content” في Google Search Console أن صفحتك موجودة في فهرس Google، لكن Google لم يتمكن فعليًا من قراءة أي محتوى صالح للاستخدام منها. وهذا يختلف عن الحظر عبر robots.txt، وغالبًا لا يكون مشكلة تُحل بـ”كتابة مزيد من الكلمات”. ومن الأسباب الواقعية المتكررة أن يحظر خادمك أو شبكة CDN Googlebot بصمت، فيتلقى Google استجابة فارغة مع أن الصفحة تبدو سليمة لك — لكن تعامل معه كسبب محتمل ينبغي فحصه، لا باعتباره السبب الوحيد.

ما معنى هذه الحالة؟

افتح تقرير فهرسة الصفحات في Google Search Console (ستجده ضمن “الفهرسة” في القائمة اليسرى)، وقد ترى حالة باسم “Page indexed without content.” (ترجمة) «صفحة مفهرسة بلا محتوى». وقد تظهر أحيانًا بصيغة مختصرة هي “Indexed without content.” (ترجمة) «مفهرسة بلا محتوى».

هذه هي النقطة الأساسية: الصفحة مفهرسة. عثر عليها Google وأضافها إلى الفهرس. لكن المشكلة أن Google لم يتمكن من قراءة محتوى الصفحة. Evidence for this claim Google defines Page indexed without content as indexed even though Google could not read the content, citing cloaking or unsupported formats as examples. Scope: Google Search Console Page Indexing status; other diagnoses require inspection. Confidence: high · Verified: 2026-07-14 Google: Page indexing report تذكر وثائق Google نفسها إخفاء الهوية أو تنسيقًا غير قابل للفهرسة كسببين محتملين — وتوضح صراحة أن هذه الحالة ليست هي نفسها حظر الصفحة على مستوى robots.txt (فله سبب منفصل في التقرير).

وهذا ما يميزها عن حالتين يخلط الناس بينهما وبين هذه الحالة:

• “Discovered — currently not indexed” — يعرف Google أن عنوان URL موجود لكنه لم يفهرسه بعد.
• “Crawled — currently not indexed” — زحف Google إلى الصفحة لكنه اختار عدم فهرستها.

كلتا الصفحتين غير موجودتين في الفهرس. أما صفحات “Page indexed without content” فهي موجودة فيه — لكن دون محتوى مقروء في سجل الفهرس.

لماذا لا تكون المشكلة عادةً كما يظن الناس؟

الافتراض الطبيعي هو: “لا يستطيع Google قراءة JavaScript لدي”. وقد يكون هذا صحيحًا أحيانًا. لكن John Mueller من Google قال إن السبب الأكثر شيوعًا هو حظر الخادم أو شبكة CDN لـGooglebot — إذ تقدم الاستضافة أو جدار الحماية أو نظام حماية البوتات إلى Googlebot استجابة فارغة بينما يرى الزوار العاديون (وأنت) الصفحة كاملة.

لهذا قد يصعب اكتشاف المشكلة: تفتح الصفحة في متصفحك فتبدو مثالية، وتفترض أن التقرير مخطئ. لكن Google رأى شيئًا مختلفًا.

كيف تتحقق مما رآه Google؟

استخدم أداة فحص عنوان URL في Search Console (ألصق عنوان URL في شريط البحث أعلى الصفحة). ثم:

1. انقر على View Crawled Page لترى ما حصل عليه زحف الفهرسة لدى Google فعليًا — فهذا هو السجل المرتبط بالحالة التي تشخّصها.
2. شغّل Test Live URL أيضًا، لكن افهم حدوده هنا: يدرج Google هذه الحالة ضمن الحالات التي لا يستطيع الاختبار المباشر إعادة فحصها مباشرة، وكون النتيجة “صالحة” لا يعني سوى أن أداة فحص Google تستطيع الوصول إلى الصفحة الآن — وليس دليلًا على زوال حالة الفهرسة.

إذا بدا زحف الفهرسة فارغًا بينما الصفحة كاملة في متصفحك، فهذه إشارة إلى أن شيئًا ما قدّم لـGooglebot محتوى مختلفًا (أو لم يقدم محتوى) — وعلى الأرجح يكون حظرًا من الخادم أو CDN أو حماية البوتات، أو إظهار محتوى مختلف، لا مشكلة في الكتابة.

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

الخلاصة — تعني “Page indexed without content” أن عنوان URL موجود في فهرس Google لكن Googlebot لم يتمكن من قراءة أي محتوى صالح للاستخدام — بخلاف «تم الزحف إليها — غير مفهرسة حاليًا» أو «تم اكتشافها — غير مفهرسة حاليًا»، حيث لا تكون الصفحات مفهرسة أصلًا، وبخلاف حظر الصفحة عبر robots.txt، الذي له سبب مستقل. الافتراض المعتاد هو فشل JavaScript؛ لكن في حالة من يناير 2026 أخبر Mueller مستخدمًا أن السبب عادةً حظر منخفض المستوى من الخادم أو CDN، يستند كثيرًا إلى عنوان IP ويستهدف Googlebot، ولا يمكن إعادة إنتاجه باستخدام curl أو زاحف تابع لجهة خارجية. وتشمل الأسباب المحتملة الأخرى: إظهار محتوى مختلف، أو تصييرًا فارغًا، أو محتوى مشروطًا بالنقر، أو تنسيقًا غير مدعوم — افحصها كفروع يقودها الدليل، لا كترتيب ثابت. شخّص المشكلة عبر View Crawled Page لبيانات الفهرسة في أداة فحص عنوان URL، مع تذكر أن Google يدرج هذه الحالة صراحةً ضمن ما لا يستطيع الاختبار المباشر إعادة فحصه، وأن النتيجة “الصالحة” لا تثبت زوال الحالة.

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

وثائق تقرير فهرسة الصفحات لدى Google موجزة بشأن هذه الحالة: الصفحة موجودة في الفهرس، لكن Google لم يتمكن لسبب ما من قراءة المحتوى. وتذكر الوثائق أن الصفحة قد تقدم محتوى مختلفًا إلى Google، أو تكون بتنسيق لا يستطيع Google فهرسته — والإجراء الموصى به هو فحص عنوان URL ومراجعة تفاصيل التغطية. Evidence for this claim Google defines Page indexed without content as indexed even though Google could not read the content, citing cloaking or unsupported formats as examples. Scope: Google Search Console Page Indexing status; other diagnoses require inspection. Confidence: high · Verified: 2026-07-14 Google: Page indexing report (راجع تبويبي الوثائق الرسمية والاقتباسات للنص الحرفي والروابط العميقة.)

هناك نقطتان تستحقان الدقة، لأن الأدلة التي تتناول هذا المصطلح تطمس الفرق بينهما عادةً:

• تقول صياغة Google إنه “تعذر قراءة المحتوى” — ولا تصف كائنًا فارغًا داخليًا يخزنه Google. اعتبر “سجلًا فارغًا” اختصارًا للأثر الذي يراه القارئ، لا آلية موثقة.
• هذه الحالة ليست صراحةً حظرًا على مستوى الصفحة عبر robots.txt — فلذلك سبب منفصل في التقرير. وتظهر صلة robots.txt هنا بصورة غير مباشرة: قد يؤدي حظر مورد حرج (ملف JS أو CSS تحتاج إليه الصفحة للتصيير) إلى تصيير فارغ، وهذا سبب في فرع التصيير، لا سبب robots.txt نفسه.

إذا حافظت على هذا الفرق فلن تخلط بينها وبين حالات “غير مفهرسة أصلًا” أو مع حظر robots.txt.

لا تفترض أن السبب هو JavaScript

هذا أهم تصحيح في المقال كله، لذا سأبدأ به.

تتعامل الاستجابة التلقائية — ومعظم الأدلة المتصدرة لهذا المصطلح — مع “indexed without content” على أنها مشكلة تصيير أو JavaScript. لكن John Mueller اعترض على ذلك في حالة محددة. وردًا على مستخدم في r/TechSEO على Reddit هبطت صفحته الرئيسية تقريبًا من المركز 1 إلى 15 بعد ظهور الحالة، قال إن هذا يعني عادةً أن الخادم أو CDN يمنع Google من تلقي أي محتوى، وأن الأمر لا يتعلق بـJavaScript. وأضاف أنه غالبًا حظر منخفض المستوى نسبيًا، يستند أحيانًا إلى عنوان IP الخاص بـGooglebot — ما يجعل اختباره من خارج أدوات Search Console مستحيلًا عمليًا. وقيل إن الإعداد المتأثر كان Webflow على Cloudflare، وهو مثال واقعي مفيد على قدرة الإعدادات الافتراضية في CDN أو حماية البوتات على حرمان Googlebot من المحتوى بصمت. (أنا أعيد صياغة ملاحظة منقولة من Reddit ولا أقتبسها — تعامل مع هذا الإطار باعتباره خلاصة حالة موثقة واحدة، لا إحصاءً مقاسًا لتكرار كل سبب.)

هذا هو التصحيح الذي ينبغي استيعابه: كلمة “عادةً” لدى Mueller تصف ما رآه في تلك المحادثة الواحدة، لا ترتيبًا عالميًا للأسباب. ولا ترتب وثائق Google الأسباب أيضًا — بل تذكر إظهار محتوى مختلف والتنسيق غير المدعوم كاحتمالين. لذلك، بدل قائمة ثابتة من 1 إلى 5، مرّ على الفروع التالية وفق الأدلة ودع ما تلقاه Googlebot فعليًا يوجهك إلى الفرع الصحيح:

• استجابة الخادم / CDN / WAF — شيء في طبقة الشبكة يحرم Googlebot من المحتوى (غالبًا حسب عنوان IP وغالبًا غير مرئي من الخارج). وهذا سبب وثّقه Mueller.
• تقديم خاص بالعميل (إظهار محتوى مختلف) — يتلقى Googlebot محتوى مختلفًا أو فارغًا مقارنة بالمستخدمين. قد يكون ذلك إخفاءً متعمدًا (انتهاكًا لسياسة الرسائل غير المرغوب فيها يتطلب نية التلاعب بالترتيب) أو فرق إعدادات غير مقصود — فلا تسمِّ النسخة العرضية “cloaking” كما لو كانت انتهاكًا للسياسة؛ بل سمِّها خللًا في التقديم.
• مشكلة تنسيق / محلل — الاستجابة ليست بتنسيق يفهرسه Google، أو أن ترويسة Content-Type لا تطابق المحتوى الفعلي.
• فشل التصيير / الموارد — تصيير JavaScript يفشل أو تنتهي مهلته أو يعتمد على مورد محظور، فيترك HTML المصيّر فارغًا.
• محتوى مشروط بالتفاعل — لا يظهر المحتوى إلا بعد نقرة أو تمرير لا ينفذه Google.
• مخرج فارغ حقًا — الصفحة تُصيّر فعلًا بلا شيء.

JavaScript فرع واحد ينبغي فحصه — وليس الافتراض المسبق، ولا يحتل تلقائيًا مرتبة أعلى أو أدنى من غيره دون دليل من فحصك.

لماذا قد تكلفك هذه الحالة ترتيبك؟

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

تفاصيل حظر الخادم أو CDN

سبب ضعف تغطية هذا الاحتمال هو صعوبة رؤيته. فقد تقرر قاعدة لحماية البوتات أو WAF، أو قائمة سماح لعناوين IP، أو تحديد معدل صارم، أو إعداد أمان افتراضي تحدّث تلقائيًا، أن Googlebot حركة مسيئة؛ فتُرجع جسمًا فارغًا أو صفحة تحدٍ أو حالة غير 200 — لكن لعناوين IP الخاصة بـGooglebot فقط. أما أنت وفريقك وزاحف الجهة الخارجية فتصلون من عناوين IP عادية وترون الصفحة الحقيقية.

هذا هو الفخ: لا يمكنك إعادة إنتاج حظر Googlebot المستند إلى IP باستخدام curl أو زاحف مكتبي. فهذه الأدوات لا تأتي من نطاقات IP الخاصة بـGooglebot. والمكان الوحيد الذي يمكنك فيه رؤية ما تلقاه Googlebot بثقة هو أدوات اختبار Search Console التي تجلب الصفحة بصفتها Google.

إذا اشتبهت في ذلك، فتحقق أولًا مما إذا كانت الطلبات من Googlebot حقًا (DNS عكسي ثم أمامي، أو نطاقات IP المنشورة من Google)، ثم راجع إدارة البوتات في CDN وقواعد الجدار الناري/WAF وقوائم السماح لعناوين IP وحدود المعدل بحثًا عن أي شيء يحظر تلك النطاقات. يحتوي تبويب النصوص البرمجية على أوامر التحقق.

قبل تغيير أي شيء، اربط الأدلة بدل التخمين: استخرج استجابة View Crawled Page المفهرسة وسجلات أحداث CDN/WAF وسجلات خادم الأصل للفترة الزمنية نفسها، وابحث عن معرف الطلب وفئة العميل والقاعدة أو حد المعدل الذي رفض الطلب. ثم غيّر فقط أضيق مسار أو فئة عميل أو قاعدة تأكدت من مسؤوليتها — وبعد مراجعة أمنية قبل النشر. لا تدعم المصادر التي راجعناها السماح الشامل بكل نطاقات IP المنشورة من Google كخيار افتراضي آمن؛ فهذا يوسع سطح الهجوم لعطل سببه عادةً قاعدة واحدة سيئة الإعداد. بعد التغيير، راقب في سجلاتك طلبات Googlebot المؤكدة وهي تعيد استجابة كاملة، ثم أعد فحص تقرير الفهرسة بعد زحف لاحق — لا ينشر Google جدولًا ثابتًا لإعادة الزحف، لذا المطلوب “keep checking,” (ترجمة) «استمر في الفحص»، لا “check back on day X,” (ترجمة) «عد في اليوم X».

سبب التصيير / JavaScript (عندما يكون JS هو السبب فعلًا)

عندما يكون السبب هو التصيير فعلًا، تكون الآلية واضحة: يزحف Google إلى HTML الخام، ثم يصيّر Chromium بلا واجهة الصفحة ويشغّل JavaScript. ولا يستطيع Google فهرسة إلا ما ينتهي في HTML المصيّر. فإذا كان محتواك يُصيّر لدى العميل وفشل التصيير أو وقع خطأ أو انتهت المهلة أو اعتمد على طلب لا ينفذه Google، فقد يعود HTML المصيّر فارغًا — فتحصل على indexed without content.

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

إصلاح سبب JS هو مسار التصيير المعتاد — التصيير من جانب الخادم أو التصيير المسبق، وضمان وجود المحتوى في HTML المصيّر، وإتاحة التنقل عبر روابط <a href> حقيقية بدل معالجات النقر فقط. (التفصيل الكامل في JavaScript SEO.)

التشخيص: أداة فحص عنوان URL هي الأساس

هناك تشخيص واحد مهم هنا، وهو فحص عنوان URL — لكنه يعتمد على مصدرين مختلفين للبيانات، والخلط بينهما يقود إلى استنتاجات خاطئة. يفصل Google بين بيانات الفهرسة (ما رآه آخر زحف للفهرسة) والاختبار المباشر (جلب Google-InspectionTool لعنوان URL الآن)، وهما لا يجيبان عن السؤال نفسه:

إذًا، سير العمل الفعلي هو:

1. افتح View Crawled Page (بيانات الفهرسة). اقرأ HTML المصيّر واستجابة HTTP وموارد الصفحة المرتبطة بالحالة — فهذا ما تلقاه زحف الفهرسة لدى Googlebot فعلًا. قد يختلف توفر كل جزء حسب الحالة؛ وإذا غابت بعض الحقول، فهذا بحد ذاته دليل تشخيصي (فالاستجابة المحظورة أو غير 200 تعرض غالبًا أقل من التصيير الطبيعي).
2. قارنها بمتصفحك. إذا كان التصيير المفهرس فارغًا أو منزوعًا بينما الصفحة المباشرة كاملة في متصفحك، فأنت أمام حظر أو تقديم خاص بالعميل، لا نقص محتوى.
3. شغّل Test Live URL على أي حال، لكن اقرأ نتيجته على نحو صحيح. لن يؤكد مباشرةً زوال هذه الحالة، لكنه مفيد: إذا فشل الاختبار المباشر نفسه أو أشار إلى مشكلة وصول فهذه أدلة حقيقية؛ وإذا عاد “صالحًا”، فافهمها بمعنى “يمكن الوصول إليه الآن” لا “أُصلح”. Evidence for this claim URL Inspection can show Google's indexed/crawled information and supports a live test for the current accessible version. Scope: Google Search Console URL Inspection; live test results can differ from the indexed version. Confidence: high · Verified: 2026-07-14 Google: URL Inspection tool
4. اقرأ الاستجابة والموارد. تشير حالة غير 200 أو صفحة تحدٍ/اعتراض أو موارد حرجة محظورة (JS/CSS تحتاج إليها الصفحة) إلى السبب.

لأن الحظر المستند إلى IP لن يظهر من الخارج، لا تثق في curl خارجي أو زاحف لإثبات سلامة الصفحة — فأدوات Search Console هي الوحيدة التي تجلب بصفتها Google، وحتى هي تحتاج إلى بيانات الفهرسة لا الاختبار المباشر وحده لتفسير هذه الحالة.

التمييز بين الأسباب

مرجع سريع للحالات والأسباب التي يخلط الناس بينها وبين هذه الحالة:

خرافات ينبغي التخلي عنها

• “أضف 600 كلمة وستُصلح تلقائيًا.” عدد الكلمات مشكلة محتوى رقيق أو جودة. وإذا لم يتلق Google أي محتوى، فلن يغير إضافة كلمات إلى صفحة لا يستطيع قراءتها شيئًا.
• “إنها مشكلة JavaScript.” أحيانًا — لكن وفق Mueller تكون عادةً حظر خادم/CDN، لا JavaScript. فلا تبدأ من هناك.
• “يمكنني إعادة إنتاجها باستخدام curl.” ليس إذا كان الحظر على Googlebot قائمًا على IP.
• “إنها مثل «تم الزحف إليها — غير مفهرسة حاليًا» و«تم اكتشافها — غير مفهرسة حاليًا».” لا — فهاتان الصفحتان غير مفهرستين أصلًا، بينما هذه مفهرسة.
• “اضغط Request Indexing فقط.” إعادة الفهرسة من دون إصلاح الحظر أو التصيير الأساسي لا تفعل سوى تأكيد صفحة فارغة مجددًا.

بعد إصلاح المشكلة

بعد أن يعرض View Crawled Page محتوى حقيقيًا من جديد، استخدم مسار Validate Fix في التقرير و/أو Request Indexing لطلب إعادة الزحف، ثم أعد الفحص للتأكد من أن التصيير يحتوي الآن على محتواك. فالتحقق دون إصلاح سيرتد.

موضع هذه الحالة في الصورة الكبرى

هذه حالة واحدة في تقرير فهرسة الصفحات، داخل مرحلة الفهرسة الأوسع لدى Google (الزحف ← التصيير ← الفهرسة ← العرض). وتفشل الحالات المجاورة في التقرير — زوج “غير مفهرسة حاليًا”، وحالات التكرار/الصفحة الأساسية، وحالات الحظر/الأخطاء — عند نقاط مختلفة من المسار. لمعرفة آليات التصيير وراء سبب JS، راجع التصيير و JavaScript SEO؛ ولمعرفة التقرير كله، راجع مركز تقرير فهرسة الصفحات.

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

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

• المعنى: عنوان URL موجود في فهرس Google، لكن Googlebot لم يتمكن من قراءة محتوى صالح للاستخدام. وهي حالة في تقرير فهرسة الصفحات في Search Console — يذكر Google إظهار محتوى مختلف أو تنسيقًا غير قابل للفهرسة كسببين محتملين، ويستبعد صراحةً حظر الصفحة عبر robots.txt.
• ليست مثل «تم الزحف إليها — غير مفهرسة حاليًا» أو «تم اكتشافها — غير مفهرسة حاليًا» — فهاتان الصفحتان غير مفهرستين أصلًا. كما أنها ليست حظر الصفحة عبر robots.txt ولا 401/403 (ولكل منها سبب مستقل).
• غالبًا ليست JavaScript. في حالة من يناير 2026 (إعادة صياغة لملاحظة منقولة من Reddit)، أخبر Mueller مستخدمًا أن هذا يعني عادةً حظرًا منخفض المستوى من الخادم/CDN — كثيرًا ما يكون مستندًا إلى IP ويستهدف Googlebot — ولا يمكنك إعادة إنتاجه باستخدام curl أو زاحف خارجي. هذه حالة موثقة واحدة، لا ترتيب انتشار مقاسًا.
• فروع الأسباب التي تفحصها (وفق الدليل، لا ترتيب ثابت): استجابة الخادم/CDN/WAF، والتقديم الخاص بالعميل (cloaking أو خلل إعدادات عرضي)، ومشكلة تنسيق/محلل، وفشل التصيير/الموارد، ومحتوى مشروط بالنقر/التمرير، ومخرج فارغ حقًا.
• قد تكلفك ترتيبك: أبلغ مستخدم عن هبوط من نحو المركز 1 إلى 15 — رواية واحدة لا إحصائية محققة.
• ابدأ التشخيص ببيانات View Crawled Page المفهرسة في فحص عنوان URL — فهذا هو السجل المرتبط بالحالة. لا يستطيع الاختبار المباشر إعادة فحص هذه الحالة مباشرةً، والنتيجة “الصالحة” تعني فقط أن الصفحة متاحة الآن، لا أن الحالة زالت. إذا كان العرض المفهرس فارغًا ومتصفحك كاملًا ⇒ حظر أو تقديم خاص بالعميل، لا عدد الكلمات.
• تحقق من Googlebot (DNS عكسي/أمامي أو نطاقات IP المنشورة)، واربط سجلات CDN/ WAF/الأصل بالقاعدة الرافضة نفسها، ولا تغير إلا تلك القاعدة الضيقة بعد مراجعة أمنية — فالسماح الشامل بعناوين IP ليس خيارًا افتراضيًا مدعومًا.
• إضافة كلمات لا تصلح صفحة لا يستطيع Google قراءتها. بعد إصلاح حقيقي استخدم Validate Fix / Request Indexing ثم واصل إعادة الفحص — لا ينشر Google جدولًا ثابتًا لإعادة الزحف.

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

وثائق المصادر الأولية لهذه الحالة والأدوات المستخدمة في تشخيصها.

Google

• تقرير فهرسة الصفحات — مساعدة Search Console — التقرير الذي تظهر فيه الحالة، مع تعريف “Page indexed without content” حرفيًا وأمثلة إظهار محتوى مختلف/التنسيق غير المدعوم.
• أداة فحص عنوان URL — مساعدة Search Console — View Crawled Page وTest Live URL؛ وكيف ترى HTML المصيّر ولقطة الشاشة واستجابة HTTP وموارد الصفحة التي تلقاها Googlebot.
• فهم أساسيات JavaScript SEO — لماذا لا يستطيع Google فهرسة إلا محتوى HTML المصيّر، وكيف تفحص التصيير.
• نظرة عامة على برامج زحف Google وأدوات الجلب — وكلاء مستخدم Googlebot ونطاقات IP المنشورة لتشخيص الحظر المستند إلى IP.
• التحقق من Googlebot وبرامج زحف Google الأخرى — فحص DNS العكسي ثم الأمامي.

Bing / Microsoft

• Bing Webmaster Tools — URL Inspection — يستخدم Bing تسميات حالات مختلفة ولا يملك مقابلًا مطابقًا لـ”indexed without content”، لكن أداة فحص عنوان URL لديه تقدم عرض جلب/تصيير مشابهًا لـBingbot.

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

صياغة موثقة من وثائق Google. يقفز كل رابط عميق إلى المقطع المقتبس في صفحة المصدر.

Google — تعريف تقرير فهرسة الصفحات

• “This page appears in the Google index, but for some reason Google could not read the content.” (ترجمة) «تظهر هذه الصفحة في فهرس Google، ولكن Google لم يتمكن لسبب ما من قراءة المحتوى.» — تقرير فهرسة الصفحات، مساعدة Search Console. الانتقال إلى الاقتباس

Google — JavaScript وHTML المصيّر

• “To make sure that Google can still see your content after it’s rendered, use the Rich Results Test or the URL Inspection Tool and look at the rendered HTML.” (ترجمة) «للتأكد من أن Google لا يزال قادرًا على رؤية محتواك بعد تصييره، استخدم اختبار النتائج المنسّقة أو أداة فحص عنوان URL وانظر إلى HTML المصيّر.» — فهم أساسيات JavaScript SEO، Google Search Central. الانتقال إلى الاقتباس

شجرة قرار للتشخيص

اتبعها من الأعلى إلى الأسفل. الهدف كله هو التوقف عن افتراض “إنها JavaScript” وترك ما تلقاه Googlebot فعليًا يحدد الاتجاه.

الخطوة 1 — تأكد أنها هذه الحالة فعلًا. هل الصفحة في مجموعة Indexed في تقرير فهرسة الصفحات (لا «تم الزحف إليها — غير مفهرسة حاليًا» ولا «تم اكتشافها — غير مفهرسة حاليًا»)؟ إذا كانت في مجموعة غير المفهرسة فأنت تحل مشكلة أخرى.

الخطوة 2 — انظر إلى ما تلقاه Googlebot. فحص عنوان URL ← View Crawled Page (بيانات الفهرسة) ← اقرأ HTML المصيّر واستجابة HTTP المرتبطين بالحالة. (لقطة الشاشة خاصة بالاختبار المباشر وليست جزءًا من العرض المفهرس.)

• يحتوي التصيير على محتواك ← قد يكون سجل الحالة قديمًا؛ شغّل Test Live URL للتحقق من الوصول الحالي (مع العلم أنه لا يعيد فحص هذه الحالة مباشرةً)، وإذا بدا سليمًا أيضًا فتحقق/اطلب الفهرسة وتابع.
• التصيير فارغ أو منزوع أو خاطئ ← واصل.

الخطوة 3 — قارن بمتصفحك. افتح عنوان URL المباشر بنفسك.

• فارغ لـGoogle وكامل لك ← هذا حظر أو تقديم مختلف، لا مشكلة محتوى. انتقل إلى الخطوة 4.
• فارغ لكليهما ← هذه مشكلة تصيير أو محتوى. انتقل إلى الخطوة 5.

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

الخطوة 5 — فرع التصيير / المحتوى. هل المحتوى مصيّر لدى العميل أو مشروط بنقرة/تمرير أو في تنسيق غير مدعوم؟ أصلح التصيير (SSR/تصيير مسبق، وضع المحتوى في HTML المصيّر، وروابط <a href> حقيقية — فـGoogle لا ينقر). وإذا كانت الصفحة فارغة فعلًا، فهذه هي الإجابة.

الخطوة 6 — التحقق. بعد أن يعرض View Crawled Page محتوى حقيقيًا فقط: استخدم Validate Fix و/أو Request Indexing، ثم أعد الفحص للتأكيد.

قائمة فحص لتشخيص “Page indexed without content”

نفذها بالترتيب — فهي ترجّح عمدًا أسباب الحظر/التصيير، لا عدد الكلمات:

• تأكدت من وجود عنوان URL في مجموعة Indexed (لا “«تم الزحف إليها/اكتشافها — غير مفهرسة حاليًا»”).
• شغّلت فحص عنوان URL ← View Crawled Page (بيانات الفهرسة) وقرأت HTML المصيّر واستجابة HTTP المرتبطين بالحالة.
• عرفت أن لقطة الشاشة خاصة بالاختبار المباشر وليست جزءًا من العرض المفهرس.
• فحصت استجابة HTTP بحثًا عن حالة غير 200 أو صفحة تحدٍ أو اعتراض.
• فحصت موارد الصفحة بحثًا عن JS/CSS محظور تحتاج إليه الصفحة.
• فتحت عنوان URL المباشر في متصفحي وقارنته بتصيير Google المفهرس.
• لم أعتبر نتيجة Test Live URL “الصالحة” دليلًا على زوال الحالة — فهي تعني فقط أن أداة Google تستطيع الوصول إلى الصفحة حاليًا.
• إذا كانت فارغة لـGoogle وكاملة لي: تعاملت معها كـحظر أو تقديم خاص بالعميل، لا “cloaking” تلقائيًا (فالمصطلح يفترض نية تلاعب) ولا مشكلة محتوى.
• استبعدت حظر الصفحة عبر robots.txt و401/403 كسبب حقيقي (فهذه حالات مستقلة).
• تحققت من Googlebot (DNS عكسي ثم أمامي، أو نطاقات IP المنشورة).
• ربطت سجلات CDN/WAF وسجلات الأصل ومعرفات الطلبات للعثور على القاعدة الرافضة الدقيقة، ثم غيرت تلك القاعدة الضيقة فقط بعد مراجعة أمنية — لا قائمة سماح واسعة لعناوين Googlebot.
• لم أفترض أن curl / زاحفًا خارجيًا يثبت سلامتها (فحظر IP لا يظهر خارجيًا).
• إذا كان السبب تصييرًا: تأكدت من وجود المحتوى في HTML المصيّر، وأنه غير مشروط بنقرة/تمرير، ويمكن الوصول إليه عبر روابط <a href> حقيقية.
• لم أحاول “إضافة 600 كلمة” كحل.
• بعد إصلاح حقيقي: شغّلت Validate Fix / Request Indexing وأعدت الفحص.

تحقق من أنه Googlebot فعلًا

إذا اشتبهت في حظر الخادم/CDN، فتأكد أولًا من أن الطلبات في سجلاتك تخص Googlebot فعلًا (فكثير من الحركة تنتحل وكيل المستخدم). استخدم فحص DNS عكسيًا ثم أماميًا — ولا تنشر Google طريقة مختصرة.

macOS / Linux

# 1) Reverse DNS the IP from your logs — it should end in googlebot.com or google.com
host 66.249.66.1
# → 1.66.249.66.in-addr.arpa 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

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

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

قارن HTML الخام بالمصيّر بنفسك

لن يعيد هذا إنتاج حظر Googlebot المستند إلى IP (فأنت لا تستخدم عناوين IP الخاصة بـGoogle — ولهذا تظل أداة فحص عنوان URL هي الاختبار الحقيقي). لكنه أسرع طريقة لاكتشاف فجوة التصيير لدى العميل: إذا كان HTML الخام شبه فارغ ولا تمتلئ الصفحة إلا بعد تشغيل JS، فمحتواك يعتمد على تصيير قد يفشل.

macOS / Linux — اجلب HTML الخام وعاين مقدار المحتوى الحقيقي فيه:

# Raw HTML as a plain GET (what a crawler sees before rendering)
curl -sL https://example.com/page/ -o raw.html

# Rough "is there content?" check — count visible-ish characters
# (a near-empty body here on a content page is a red flag for CSR)
wc -c raw.html

# Optional: render with a headless browser to compare, if you have Chrome installed
# (Chrome path varies; this dumps the post-JS DOM)
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
  --headless --disable-gpu --dump-dom https://example.com/page/ > rendered.html
wc -c rendered.html

Windows (PowerShell)

# Raw HTML as a plain GET
Invoke-WebRequest -Uri "https://example.com/page/" -OutFile raw.html
(Get-Item raw.html).Length

# Render with headless Chrome to compare (adjust the Chrome path as needed)
& "C:\Program Files\Google\Chrome\Application\chrome.exe" `
  --headless --disable-gpu --dump-dom "https://example.com/page/" > rendered.html
(Get-Item rendered.html).Length

تعني الفجوة الكبيرة بين raw.html وrendered.html أن محتواك يعتمد على JavaScript. ويُعد ملف raw.html الصغير شبه الفارغ في صفحة يفترض أن تكون ممتلئة هو بالضبط النوع الذي قد يُصيّر بلا شيء عند فشل JS. وفي الحالتين، أكد النتيجة عبر View Crawled Page في أداة فحص عنوان URL — فهذا هو الجلب الوحيد الذي يرى ما تلقاه Googlebot فعليًا.

أخطاء تهدر وقتك مع هذه الحالة

هذه هي الأخطاء المحددة التي أرى الناس يرتكبونها عند ظهور “page indexed without content” — وكل منها يوجهك إلى سبب خاطئ أو يدمر الأدلة اللازمة للعثور على السبب الصحيح.

إعادة كتابة نص الصفحة قبل فحص View Crawled Page. إضافة الكلمات حل للمحتوى الرقيق. وإذا لم يتلق Google أي محتوى — استجابة فارغة أو محظورة — فلن تصل الكلمات الإضافية إلى سجل الفهرس الفارغ أصلًا. افحص View Crawled Page أولًا؛ ولا تكتب مزيدًا إلا إذا أظهر التصيير صفحة رقيقة فعلًا (لا فارغة).

افتراض أن السبب JavaScript والقفز مباشرةً إلى إصلاح التصيير. إنه التخمين الافتراضي، لكن وفق John Mueller يكون السبب عادةً حظر خادم/CDN. وقضاء دورة تطوير على SSR/التصيير المسبق بينما المشكلة الحقيقية قاعدة WAF يعني أن الحالة لن تزول — وأنك أهدرت وقت التطوير في الطبقة الخاطئة.

إثبات “سلامة” الصفحة باستخدام curl أو زاحف خارجي. لن يظهر حظر Googlebot المستند إلى IP من عنوانك أو عنوان زاحفك أو أداة لا تجلب بصفتها Google. ولا تخبرك استجابة curl النظيفة بشيء عما تلقاه Googlebot. وحده Test Live URL في أداة فحص عنوان URL يجلب بصفتها Google.

تكرار Request Indexing دون إصلاح شيء. إعادة إرسال صفحة محظورة أو فارغة لا تفعل سوى تأكيد التصيير الفارغ نفسه. ولا يصبح Request Indexing (أو Validate Fix) ذا معنى إلا بعد أن يعرض View Crawled Page محتوى حقيقيًا.

اعتبار تغيير CDN/WAF آمنًا لأن تصفحك الشخصي لم يتأثر. قد تستهدف الإعدادات الافتراضية لإدارة البوتات وقوائم السماح لعناوين IP وحدود المعدل الصارمة نطاقات IP الخاصة بـGooglebot تحديدًا، بينما تترك الزوار العاديين دون تأثير — لذا لا يثبت “الموقع يعمل لدي” شيئًا عما يراه Googlebot. تحقق من طلبات Googlebot في السجلات (أو بأدوات فحص عنوان URL) قبل أي تغيير أمني وبعده.

الخلط بينها وبين “«تم الزحف إليها — غير مفهرسة حاليًا» و«تم اكتشافها — غير مفهرسة حاليًا»” أو حظر robots.txt أو 401/403. لكل منها سبب مستقل في التقرير. يعني الزوج الأول أن الصفحة ليست في الفهرس أصلًا؛ كما يملك حظر الصفحة عبر robots.txt واستجابة 401/403 الحقيقية حالتين مستقلتين. أما “Page indexed without content” فتعني أن الصفحة مفهرسة لكنها غير مقروءة. وتطبيق حل لصفحة غير مفهرسة (روابط داخلية أفضل، أولوية خريطة الموقع) أو حل robots على هذه الحالة يفوّت السبب الحقيقي تمامًا.

تسمية كل فرق بين محتوى البوت والمستخدم “cloaking”. يتطلب Cloaking وفق سياسة Google للرسائل غير المرغوب فيها نية التلاعب بالترتيب عبر تضليل المستخدمين. أما الاستجابة الفارغة العرضية لـGooglebot بسبب قاعدة CDN سيئة الإعداد فهي خلل تقديم، لا دليلًا على انتهاك السياسة — وقد تقودك تسميتها خطأً إلى حل غير مناسب (استجابة لإجراء يدوي) بدل الحل الفعلي (تغيير الإعداد).

”Page indexed without content” — مرجع سريع

ما هي؟

لا تخلط بينها وبين الحالات المجاورة

فروع الأسباب — افحص الدليل، لا ترتيبًا ثابتًا

أي أداة تجيب عن أي سؤال؟

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

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

شخّص السبب الأرجح مما أظهرته أداة فحص عنوان URL

I'm diagnosing a "Page indexed without content" status in Google Search Console.
Here's what I have:
- Rendered HTML from View Crawled Page: [paste it, or "blank"]
- HTTP response status/headers from View Crawled Page: [paste them]
- What the live page looks like in my own browser: [describe or paste raw HTML]
- Whether Test Live URL shows the same result: [yes/no + what it showed]

Based only on this evidence, rank the most likely cause among: (1) a server/CDN/WAF
block targeting Googlebot, (2) cloaking, (3) a JavaScript rendering failure,
(4) content gated behind a click or scroll, (5) a genuinely blank page or
unsupported format. Explain which specific detail above points to your top pick,
and tell me what additional evidence would confirm or rule it out. Don't assume
JavaScript is the cause by default.

راجع وصف إعدادات CDN/WAF بحثًا عن قاعدة تحظر Googlebot

Here is a description of my CDN/WAF setup: [paste your bot-management settings,
rate-limit rules, IP allowlist/denylist entries, and any custom firewall rules].
Google's crawler IP ranges are published at
https://developers.google.com/static/search/apis/ipranges/googlebot.json.
Identify any rule that could return an empty response, a challenge page, or a
non-200 status to Googlebot's IP ranges specifically, even if normal visitor
traffic is unaffected. List each suspect rule and what to check or relax first.

اكتب تصعيدًا إلى مزود الاستضافة/CDN

Draft a short, specific support ticket to my hosting/CDN provider. Context: Google
Search Console shows "Page indexed without content" for [URL]. Google's own
View Crawled Page tool shows an empty/blocked response, while the page loads fully
in a normal browser — which points at a server or CDN-level block on Googlebot's
IP ranges, not a content or JavaScript issue. Ask them to check bot-management,
WAF, and rate-limiting logs for requests from Google's published crawler IP ranges
around [date/time], and to confirm whether any rule is blocking or challenging
those requests.

أثبت أن Googlebot يحصل على المحتوى الآن فعلًا

لا تُعد عبارة “غيرت قاعدة WAF” أو “أصلحت التصيير” دليلًا — فالنتيجة الوحيدة المعتبرة هي ما يتلقاه Googlebot في الجلب التالي. تختبر هذه الفحوص ذلك، لا مجرد قيامك بتغيير.

الاختبار 1 — أكد الإصلاح فيما يفحصه Google فعلًا

• الاختبار — افحص عنوان URL المتأثر. شغّل Test Live URL أولًا — لا يستطيع إعادة فحص حالة الفهرسة هذه مباشرةً، لكنه يؤكد ما إذا كان Google-InspectionTool يستطيع الوصول إلى الصفحة حاليًا ويعرض لقطة شاشة حديثة. ثم اقرأ HTML المصيّر واستجابة HTTP. وقارن بتصييرك عبر أداة Render Gap إذا كان السبب هو التصيير لدى العميل.
• النتيجة المتوقعة — يحتوي HTML المصيّر ولقطة الشاشة في الاختبار المباشر على محتواك الفعلي ويطابقان ما يراه الزائر العادي، وتكون استجابة HTTP نظيفة 200.
• تفسير الفشل — استمرار الفراغ أو النزع أو حالة غير 200 يعني أن الحظر أو فرق التقديم أو فشل التصيير لم يُصلح فعلًا — فلا تنتقل إلى Validate Fix بعد. يثبت ذلك الوصول الحالي لا تحديث حالة الفهرسة؛ ولا يظهر الأخير إلا بعد أن يعيد Google الزحف إلى عنوان URL وفهرسته.
• نافذة المراقبة — نتيجة الاختبار المباشر فورية؛ أما زوال حالة الفهرسة فلا يظهر إلا بعد الزحف المجدول التالي لدى Google، وموعده غير منشور ولا يمكن التنبؤ به.
• مؤشر التراجع — إذا ظلت الصفحة فارغة أو غير 200 بعد التغيير الذي اعتقدت أنه أصلحها، فعد إلى فروع الأسباب بدل تكرار Request Indexing.

الاختبار 2 — طلبات Googlebot المؤكدة تحصل الآن على استجابة 200 كاملة

• الاختبار — استخرج سجلات الخادم/CDN الحديثة واعزل طلبات عناوين IP المؤكدة لـGooglebot (DNS عكسي ثم أمامي، أو النطاقات المنشورة)، باستخدام Log File Analyzer لفصل طلبات Googlebot الحقيقية عن وكلاء المستخدم المنتحلين. قارن رموز الحالة وأحجام الاستجابة قبل الإصلاح وبعده.
• النتيجة المتوقعة — تعيد طلبات Googlebot المؤكدة 200 مع جسم كامل الحجم، لا صفحة تحدٍ ولا جسمًا فارغًا ولا حالة غير 200.
• تفسير الفشل — استمرار حظر عناوين Googlebot المؤكدة أو حصولها على استجابات فارغة يعني أن قاعدة WAF/CDN التي غيرتها ليست السبب، أو لم تُخفف بما يكفي.
• نافذة المراقبة — راقب حجم السجلات عبر الزيارات العديدة التالية لـGooglebot بدل توقع نتيجة فورية — لا ينشر Google جدول إعادة زحف ثابتًا لعنوان URL.
• مؤشر التراجع — إذا ظلت حركة Googlebot المؤكدة محظورة في السجلات بعد الإصلاح، فعد إلى مراجعة قواعد إدارة البوتات ولا تفترض أن التغيير الأول كافٍ.

الاختبار 3 — تتوقف حالة فهرسة الصفحات عن التكرار

• الاختبار — شغّل Validate Fix في تقرير فهرسة الصفحات، وأعد دوريًا فحص المحتوى المفهرس لعنوان URL باستخدام Google Index Checker.
• النتيجة المتوقعة — تزول الحالة (ينجح التحقق)، وتظل الفحوص اللاحقة تعرض محتوى حقيقيًا مفهرسًا — لا عودة إلى الفراغ.
• تفسير الفشل — فشل التحقق أو عودة الحالة لاحقًا يعني عادةً أن مشكلة الحظر/ التصيير متقطعة (مثل حظر بعض الطلبات فقط) وليست محلولة بالكامل.
• نافذة المراقبة — لا ينشر Google جدولًا ثابتًا لإعادة الزحف أو التحقق — فلا تحكم عليها في يوم نقر Validate Fix؛ واصل الفحص دوريًا حتى يتحدث التقرير.
• مؤشر التراجع — إذا عادت الحالة إلى “indexed without content” بعد اكتمال دورة التحقق، فاعتبر المشكلة غير محلولة وابدأ مجددًا من الاختبار 1.

اختبر نفسك: Page indexed without content

خمسة أسئلة سريعة عن حالة “Page indexed without content” في GSC. اختر إجابة لكل سؤال، ثم تحقق.

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