فحص عنوان URL في GSC
أدخل عنوان URL في Search Console، وانقر على “عرض الصفحة التي تم زحفها”، ثم قارن كود المصدر HTML للتأكد من عدم اختفاء المحتوى الأساسي بعد الرندر (التقديم).
مقارنة تباين النص
قارن بين عدد الأحرف النصية في “عرض مصدر الصفحة” و“فحص العنصر”. إذا تجاوز معدل تباين النص 20%، فهناك خطر كبير جداً يتعلق بالفهرسة.
اختبار النتائج الغنية (Rich Results Test)
استخدم أداة اختبار النتائج الغنية من Google لعرض لقطة الشاشة، وتأكد من تحميل المحتوى الهام في الجزء العلوي من الصفحة بالكامل خلال نافذة رندر مدتها 5 ثوانٍ.
أدوات Google الرسمية
تعد أداة فحص عنوان URL في Google Search Console (GSC) هي البوابة للحصول على حالة الزحف الفعلية لـ Googlebot.
من خلال “اختبار عنوان URL المنشور”، يمكن استدعاء خدمة WRS (خدمة تقديم الويب) لإنشاء بنية DOM كاملة في غضون 60-90 ثانية.
توفر GSC نسخة HTML بعد الرندر، ولقطة شاشة، وقائمة بالموارد التي تم تحميلها.
يعتمد Googlebot حالياً على أحدث نواة متصفح Chrome المستقرة، ولكنه يضع حداً أقصى يبلغ حوالي 5 ثوانٍ لتنفيذ البرمجيات النصية (Scripts) لكل صفحة.
بالاشتراك مع “اختبار النتائج الغنية”، يمكن مقارنة فرق البايتات بين الاستجابة الأصلية ونتائج الرندر النهائية، وتحديد مشكلات فشل تحميل البرمجيات بسبب أخطاء 403 أو 404 الناتجة عن الحظر في ملف Robots.txt.
Google Search Console
في شريط التنقل الجانبي لـ Google Search Console، بعد إدخال عنوان URL محدد، سيقوم النظام بسحب لقطة بيانات من آخر عملية زحف مخزنة في قاعدة بيانات فهارس Google.
إذا كانت حالة الصفحة تظهر “عنوان URL متاح على Google”، يمكنك معرفة ما إذا كانت هناك أخطاء في تحليل HTML أو مشكلات في تحسين الأجهزة الجوالة أثناء الزحف.
لاستكشاف مشكلات فقدان المحتوى الناتج عن رندر JavaScript بشكل أعمق، يجب النقر على زر “اختبار عنوان URL المنشور”.
ستؤدي هذه العملية إلى تشغيل WRS (خدمة تقديم الويب) التي تطلق متصفحاً بدون واجهة (Headless Browser) يعتمد على أحدث إصدار مستقر من Chromium للوصول الفعلي إلى الصفحة المستهدفة.
عندما تقوم خدمة WRS بالرندر، فإنها تضبط عرض منفذ العرض على 1280 بكسل، وتعتمد استراتيجية الزحف الموجهة للأجهزة الجوالة أولاً.
في لوحة “عرض الصفحة التي تم تقديمها”، تعرض علامة تبويب HTML بنية DOM الكاملة بعد انتهاء تنفيذ البرمجيات النصية.
يجب على الفنيين مقارنة عدد أسطر كود HTML أو حجم الأحرف المعروض هنا مع “عرض مصدر الصفحة” (استجابة الخادم الأصلية) التي تظهر عبر النقر الأيمن في المتصفح.
إذا كان حجم HTML الأصلي 2 كيلوبايت فقط، بينما نما HTML بعد الرندر إلى 50 كيلوبايت، فهذا يعني أن الصفحة تعتمد بشكل كبير على رندر جانب العميل (Client-Side Rendering).
إذا كان كود HTML بعد الرندر يفتقر إلى النص الأساسي أو علامات قوائم المنتجات، فسيتم اعتبار الرندر فاشلاً.
يخصص Googlebot موارد حوسبة محدودة لتنفيذ البرمجيات لكل صفحة. وعلى الرغم من أن المسؤولين لم يقدموا وقتاً نهائياً مطلقاً، إلا أن العديد من التجارب أظهرت أنه إذا تجاوز وقت تحميل المحتوى 5 ثوانٍ، فإن احتمالية فقدان تلك البيانات خلال مرحلة الفهرسة تزداد بشكل كبير.
“لا ينتظر Googlebot إلى ما لا نهاية حتى تنتهي JavaScript من جميع المهام غير المتزامنة؛ فميزانية الرندر الخاصة به محدودة بسرعة تحميل الصفحة، وتأخر استجابة الخادم (TTFB)، وتعقيد تحليل البرمجيات. إذا تجاوز وقت استجابة واجهة API نحو 2000 مللي ثانية، فغالباً ما يظل المحتوى في حالة “Loading” في اللحظة التي يتم فيها إنشاء لقطة الرندر.”
تحت علامة التبويب “مزيد من المعلومات” في قائمة “موارد الصفحة”، سيتم إدراج جميع ملفات JS و CSS التي فشل تحميلها.
تشير رموز الحالة 403 أو 404 بوضوح إلى أخطاء في تكوين أذونات الخادم أو مسارات موارد غير صالحة، ولكن الأكثر أهمية هو حالة “محظور بسبب ملف Robots.txt”.
نظراً لأن العديد من تطبيقات الصفحة الواحدة (SPA) تضع منطق التوجيه ورندر البيانات في ملفات برمجية محددة، فإذا كان ملف /robots.txt يحتوي على قواعد مثل Disallow: /assets/، فلن يتمكن Googlebot من الحصول على البرمجيات الأساسية، وبالتالي لن تتمكن خدمة WRS من بناء شجرة DOM كاملة.
والنتيجة هي أنه حتى لو رأى المستخدم الصفحة كاملة في المتصفح، فإنها قد تظهر لمحرك البحث كصفحة فارغة أو تحتوي فقط على الإطار الأساسي.
عند استكشاف أخطاء البرمجيات، يجب التركيز على منطقة “رسائل وحدة تحكم JavaScript”.
هنا يتم تسجيل الاستثناءات التي تظهرها خدمة WRS أثناء تنفيذ الكود.
إذا استخدم فريق التطوير ميزات ES6+ الجديدة بدون معالجة Polyfill (مثل BigInt أو ResizeObserver)، وكان إصدار Chromium المستخدم في الزحف لا يدعم بعض واجهات API غير القياسية، فستظهر أخطاء Uncaught ReferenceError أو SyntaxError في وحدة التحكم.
تؤدي هذه الأخطاء إلى انقطاع عملية تحليل البرمجيات بالكامل، مما يعطل كل منطق حقن المحتوى اللاحق.
من خلال مراقبة أرقام الأسطر وأسماء الملفات المذكورة في سجل الأخطاء، يمكن تحديد ملف المكتبة أو كتلة المنطق التي تعيق عملية الزحف بدقة.
تعد “لقطة الشاشة” بعد الرندر وسيلة أخرى للقياس الكمي.
على سبيل المثال، تقوم بعض البرمجيات بحساب ارتفاع العناصر أو شفافيتها ديناميكياً. إذا أظهرت لقطة الشاشة مساحات بيضاء واسعة، فحتى لو كانت النصوص موجودة في علامات HTML، قد تعتبر خوارزمية Google الصفحة غير صديقة للمستخدم، مما يقلل من أولوية الفهرسة.
عند التعامل مع المواقع عالية الديناميكية، يجب التأكد من أن جميع المحتويات الموجودة فوق الطية (Above the Fold) تكتمل عملية الرندر الخاصة بها خلال ثانيتين.
اختبار النتائج الغنية
أداة اختبار النتائج الغنية هي بيئة فحص عامة توفرها Google. وخلافاً لـ Search Console التي تتطلب إثبات ملكية الموقع، تسمح هذه الأداة لأي شخص بتحليل أي عنوان URL عام أو قصاصة كود ملصقة.
بعد إدخال عنوان URL وبدء الاختبار، سيقوم النظام بتشغيل متصفح بدون واجهة يعتمد على أحدث إصدار مستقر من Chromium، لمحاكاة سلوك وصول Googlebot Smartphone أو Googlebot Desktop.
بالنسبة لتطبيقات الصفحة الواحدة (SPA) التي تعتمد بشكل كبير على أطر عمل مثل React أو Angular أو Vue.js، فإن وظيفة “عرض الصفحة المختبرة” هي المعيار لتحديد ما إذا كان المحتوى قد دخل بنجاح في شجرة DOM.
نظراً لأن Googlebot لديه حد أقصى لتخصيص الموارد عند معالجة البرمجيات، فإذا كانت الصفحة تتطلب عمليات حسابية كثيفة أو أكثر من 20 طلباً لواجهة API غير متزامنة في مرحلة التهيئة، فقد تنهي خدمة WRS التقاط HTML قبل اكتمال تنفيذ البرمجيات.
عند إجراء الفحص الفعلي، سيقوم النظام بإنشاء لقطة لـ HTML بعد الرندر.
من خلال هذه اللقطة، يمكن للفنيين مقارنة فرق البايتات بين ما يرجعه الخادم الأصلي والرندر النهائي بدقة.
على سبيل المثال، صفحة تعتمد بالكامل على رندر جانب العميل (CSR) غالباً ما يحتوي كود HTML الأصلي الخاص بها على أقل من 5 كيلوبايت من كود القالب الأساسي، وإذا وصل كود HTML بعد الرندر عبر هذه الأداة إلى أكثر من 100 كيلوبايت، فهذا يعني أن Googlebot نجح في تنفيذ البرمجيات وجلب المحتوى الديناميكي.
وعلى العكس، إذا ظل كود HTML بعد الرندر في حدود 5 كيلوبايت ولم يتضمن علامات النص الأساسي، فهذا يشير إلى انقطاع تنفيذ البرمجيات على مستوى خدمة WRS.
يضع محرك رندر Google قيوداً صارمة على مهلة تحميل الموارد الفردية، وعادةً لا ينبغي أن يتجاوز وقت تحميل ملف JS واحد 2000 مللي ثانية.
إذا كانت المكتبات الخارجية أو واجهات API التي تشير إليها الصفحة تستجيب ببطء شديد، فستحدد علامة تبويب “موارد الصفحة” في نتائج الاختبار حالة فشل التحميل المقابلة.
- وضع اختبار قصاصة الكود: يدعم لصق منطق كود HTML غير المنشور، وهو أمر حيوي لفحص ما إذا كان منطق رندر JS يتوافق مع معايير الزحف خلال مرحلة بيئة الاختبار (Staging). بهذه الطريقة، يمكن التأكد من إمكانية تحليل علامات Schema المولدة ديناميكياً قبل دمج الكود في الفرع الرئيسي.
- تبديل محاكاة وكيل المستخدم (User-Agent): على الرغم من أن الزحف عبر الأجهزة الجوالة هو الافتراضي، إلا أنه عند التعامل مع مواقع ذات منطق استجابة معقد، يمكن أن يكشف التبديل إلى محاكاة الأجهزة المكتبية عن تأثير أولوية تحميل CSS على ترتيب تنفيذ JS.
- مقارنة لقطة الرندر: لقطة الشاشة التي يوفرها النظام ليست مجرد مرجع مرئي، بل هي أساس للحكم على ما إذا كانت الصفحة تعاني من “انزياح المحتوى” أو “اهتزاز التخطيط”، لأن التغيرات العنيفة في التخطيط قد تؤدي إلى سوء تقدير Googlebot لسهولة استخدام الصفحة.
“اختبار النتائج الغنية لا يقتصر فقط على التحقق من البيانات المنظمة، بل هو مختبر لفحص ظهور المحتوى الديناميكي. إذا كان النص يتم تحميله عبر JS، فإن البحث عن وجود هذا النص في ‘عرض الصفحة المختبرة’ هو أسرع طريقة للتحقق من نجاح الفهرسة.”
عندما تحتوي الصفحة على JSON-LD أو Microdata محقونة عبر البرمجيات، ستقوم الأداة باستخراج هذه المعلومات المنظمة من DOM بعد الرندر.
إذا كانت هناك أخطاء برمجية في الكود، أو إذا توقف البرنامج بسبب خطأ JS قبل حقن علامات Schema، فستظهر الأداة تنبيهاً “لم يتم اكتشاف نتائج غنية”.
يعد هذا الفحص مهماً بشكل خاص لمواقع التجارة الإلكترونية أو مواقع التقييمات، لأن Google تحتاج إلى تحديد سمات معينة مثل السعر وحالة المخزون والتقييم أثناء الفهرسة.
إذا كانت هذه السمات مفقودة في HTML لـ “الصفحة المختبرة”، فلن تظهر النجوم أو معاينة الأسعار في صفحة نتائج البحث (SERP)، حتى لو كانت تظهر بشكل طبيعي للمستخدم.
يجب إيلاء اهتمام خاص لسجلات أخطاء وحدة التحكم، لأن بيئة WRS تفرض قيوداً على استهلاك الذاكرة أكثر صرامة من متصفحات المستخدمين العاديين.
إذا استهلك البرنامج موارد CPU عالية جداً، فقد يتخلى Googlebot عن رندر تلك الصفحة، مما يؤدي إلى الاحتفاظ بقالب فارغ فقط في الفهرس.
- إجمالي عدد الموارد المحملة: يُنصح بالتحكم في موارد JS المطلوبة للصفحة الواحدة لتكون أقل من 50 مورداً. الطلبات المتوازية الكثيرة تؤدي إلى تأخير جدولة WRS، مما يزيد من خطر فشل الرندر.
- مراقبة أخطاء تنفيذ البرمجيات: تلتقط الأداة أخطاء مثل
ReferenceErrorأوTypeErrorالتي تسبب كسر سلسلة الرندر. إذا رأيت أخطاء عدم توافق مع معايير ES ناتجة عن نقص Polyfill، يجب تعديل هدف التجميع (Compile Target) لأدوات البناء فوراً. - صلاحية استجابة واجهة API: افحص جميع نقاط نهاية API التي تجلب المحتوى ديناميكياً عبر قائمة الموارد. إذا ظهر رمز الحالة “محظور” أو “مهلة”، فهذا يعني أن جدار الحماية حظر Googlebot أو أن أداء API لا يلبي حد الزحف.
كل “تحذير” أو “خطأ” في التقرير الناتج عن هذه الأداة يعكس سلوك Googlebot في بيئة الفهرسة الحقيقية.
إذا نبهت الأداة إلى “تعذر تحميل بعض البرمجيات”، حتى لو كانت تعمل في متصفح Chrome العادي، يجب أخذ ذلك على محمل الجد، فقد يكون ذلك بسبب فرض قيود على معدل الطلبات (Rate Limiting) على عناوين IP الخاصة بـ Googlebot عند محاولتها الوصول لهذه الموارد.
Chrome DevTools
في بيئة التطوير المحلية، تعد لوحة “Network conditions” في Chrome DevTools هي نقطة البداية لمحاكاة سلوك زحف Googlebot.
من خلال الضغط على F12 أو النقر الأيمن واختيار “فحص” لفتح شريط الأدوات، ادخل إلى More tools -> Network conditions من قائمة النقاط الثلاث في الزاوية العلوية اليمنى.
في هذه اللوحة، قم بإلغاء تحديد “Use browser default”، واختر Googlebot يدوياً من القائمة المنسدلة.
ستقوم هذه العملية بتعديل سلسلة User-Agent التي يرسلها المتصفح، لتصبح مثلاً: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html).
تكمن أهمية هذه الخطوة في التحقق مما إذا كان الخادم يحتوي على منطق خاص موجه لمحركات البحث.
إذا تم تكوين الخادم لإرجاع كود HTML مختلف بناءً على وكيل المستخدم، فستظهر البيئة المحلية على الفور نتائج استجابة تختلف تماماً عن وصول المستخدم العادي.
يجب على الفنيين مقارنة معلومات رأس الاستجابة في هذا الوقت، والتحقق مما إذا كان Content-Type أو تعليمات التحكم في التخزين المؤقت (Cache-Control) قد تغيرت.
إذا أرجع الخادم لـ Googlebot خطأ 403 (رفض الوصول) أو 301 (إعادة توجيه غير متوقعة)، فهذا يعني أن مسار الفهرسة محظور بالفعل على مستوى الخادم.
لمحاكاة “الموجة الأولى من الفهرسة” لـ Googlebot، يجب اختبار أداء الصفحة عند تعطيل JavaScript.
ادخل إلى صفحة إعدادات DevTools (Settings)، وابحث عن قسم التصحيح (Debugger) في التفضيلات، وحدد “Disable JavaScript”.
بعد تحديث الصفحة، سيعرض المتصفح فقط بنية HTML الأصلية التي يرسلها الخادم.
بالنسبة للمواقع التي تعتمد بنية تطبيق الصفحة الواحدة (SPA)، غالباً ما تؤدي هذه العملية إلى ظهور صفحة بيضاء تماماً أو عرض رسوم تحميل متحركة فقط.
إذا اختفت المعلومات النصية الأساسية أو قوائم التنقل أو قوائم المنتجات بعد تعطيل البرمجيات، فهذا يعني أن محرك البحث يجب أن يدخل في “الموجة الثانية من الفهرسة” المعقدة (مرحلة رندر WRS) للحصول على المحتوى.
في هذه الحالة، يجب تسجيل عدد بايتات HTML الأصلي، مثل 15 كيلوبايت من كود الإطار الأساسي، ومقارنته مع DOM بعد الرندر الكامل لتحديد حجم المحتوى المحقون عبر JS.
“في بيئة المحاكاة المحلية، يعد تعطيل JavaScript هو أقوى اختبار ضغط. إذا كان كود HTML الأصلي يفتقر إلى علامة H1 أو الفقرات الرئيسية التي تحتوي على المعلومات الدلالية الهامة، فإن خطر فهرسة هذه الصفحة كصفحة فارغة يكون مرتفعاً جداً عند تقلبات الشبكة أو ضيق حصص رندر Google.”
بيئة عمل Googlebot ليست جهاز كمبيوتر مكتبي عالي الأداء. باستخدام لوحة “Performance” في DevTools، يمكن محاكاة قدرة الحوسبة لـ Googlebot بشكل أكثر واقعية.
في إعدادات الأداء، اضبط تقييد وحدة المعالجة المركزية (CPU Throttling) على تبطئة بمقدار 4 أو 6 أضعاف (4x or 6x slowdown).
إذا كانت مهمة الرندر التي تستغرق 800 مللي ثانية على جهاز MacBook عالي الأداء تزداد لتصل إلى 5500 مللي ثانية عند تبطئة السرعة 6 أضعاف، فقد لامست بالفعل حد الـ 5 ثوانٍ الشائع لدى Googlebot.
من خلال عرض المهام الطويلة (Long Tasks) في مخطط Flame Chart، يمكن تحديد أي مكتبات JS ضخمة تعطل الخيط الرئيسي (Main Thread)، مما يؤدي إلى تأخير الرندر.
إذا تجاوزت المقاييس الكمية مثل إجمالي وقت الحظر (TBT) في هذه البيئة 2000 مللي ثانية، فعادة ما يشير ذلك إلى أن Googlebot قد يتوقف عن الانتظار قبل اكتمال توليد المحتوى، ويلتقط لقطة DOM غير مكتملة.
التحقق اليدوي عبر المتصفح
يتم التأكد من حالة الرندر يدوياً عن طريق مقارنة فروق البيانات بين Initial HTML و Rendered DOM.
يستخدم Googlebot أحدث محرك رندر من Chrome، ولكن إذا تجاوز تنفيذ JS حد الـ 5 ثوانٍ أو تجاوزت طلبات موارد الصفحة الواحدة 50 مورداً، فقد لا تتم فهرسة المحتوى.
يجب أن يركز الاختبار اليدوي على سلسلة تحميل الموارد، والتأكد من وجود سمة href في علامة <a> داخل كود مصدر HTML، بدلاً من توليدها ديناميكياً عبر حدث onclick، لضمان اتصال مسارات الزحف.
كود المصدر مقابل DOM الفعلي
الكود الذي يتم عرضه عبر view-source في المتصفح يعكس تدفق النص الأصلي المرسل من الخادم، بينما تعرض لوحة Elements في أدوات المطورين نموذج كائن الذاكرة (DOM) بعد تحليله بواسطة محرك الرندر وتنفيذ البرمجيات وتصحيح الأخطاء.
بالنسبة للمواقع التي تعتمد بنية SPA، غالباً ما يحتوي كود المصدر الأصلي فقط على حاوية فارغة تحمل id="app" أو id="root" مع عدة مراجع لبرمجيات يتجاوز حجمها الإجمالي 500 كيلوبايت.
بمقارنة عدد الأحرف النصية الصرفة في كود المصدر مع عددها في DOM بعد الرندر، عندما تتجاوز هذه النسبة 1:20 (أي أن HTML الأصلي يحتوي على 100 كلمة فقط بينما يصل بعد الرندر إلى 2000 كلمة)، فإن الموجة الأولى من زحف محرك البحث لن تتمكن تقريباً من الحصول على أي معلومات دلالية فعالة.
يؤدي هذا التباين إلى بقاء الصفحة في حالة فراغ محتوى خلال المرحلة الأولى من الفهرسة، بانتظار المعالجة الثانية في طابور الرندر.
| بعد المقارنة | خصائص بيانات كود المصدر الأصلي (Initial HTML) | خصائص بيانات DOM بعد الرندر (Rendered DOM) | تأثير الفروق التقنية على الفهرسة |
|---|---|---|---|
| إجمالي عقد DOM | عادة أقل من 50 عقدة، البنية مسطحة للغاية. | قد يتجاوز 1500 عقدة، مع زيادة عمق المستويات. | الزيادة الكبيرة في العقد تعني أن توليد المحتوى يعتمد كلياً على JS. |
| حالة علامات Meta | تحتوي على عناوين عامة أو أوصاف نائبة ثابتة. | تحتوي على علامات SEO محددة محقونة ديناميكياً. | قد تسجل أدوات الزحف بيانات وصفية خاطئة قبل تشغيل البرمجيات. |
| علامة Canonical | مفقودة أو تشير إلى عنوان URL ثابت للصفحة الرئيسية. | يتم تحديثها ديناميكياً لتشير للمسار المطلق الصحيح. | عدم اتساق العلامات يسبب تضارباً في تحليل خصائص الصفحة. |
| بيانات JSON-LD | فارغة في قصاصة الكود أو تحتوي على إطار Schema أساسي فقط. | مليئة ببيانات أسعار المنتجات الكاملة، التقييمات، أو المخزون. | تحدد ما إذا كانت صفحة النتائج (SERP) ستعرض مقتطفات غنية. |
| الروابط الداخلية | قد يكون شريط التنقل فارغاً، والروابط لم يتم إنشاؤها بعد. | يحتوي على علامات <a> كاملة ومسارات تصنيفات ديناميكية. |
يؤثر على كفاءة اكتشاف برامج الزحف لعناوين URL العميقة الأخرى. |
عند إجراء مقارنة عميقة، يمكن الحصول على إجمالي عدد الأحرف بعد الرندر الحالي عن طريق إدخال document.body.innerText.length في وحدة التحكم، ومقارنته بحجم ملف كود المصدر بالبايت.
إذا كان حجم كود المصدر 30 كيلوبايت، ولكن innerText بعد الرندر يصل إلى 15,000 حرف، فإن معظم وزن النص يتركز في طبقة الرندر.
في هذه الحالة، إذا كانت هناك وظيفة تكرارية (Recursive Function) تستغرق أكثر من 200ms أو واجهة API خارجية تستغرق أكثر من 2.0s، فقد يتوقف محرك رندر Googlebot عن التسجيل قبل اكتمال حقن المحتوى بسبب استراتيجيات تخصيص الموارد.
| المؤشرات الكمية | حد الخطر | النتائج الفعلية للزحف والفهرسة |
|---|---|---|
| فجوة نسبة النص (Text Ratio Gap) | > 80% من النص مولد بواسطة JS | من السهل جداً تصنيف الصفحة كـ “محتوى ضعيف” في بيئة بدون برمجيات. |
| معدل نجاح استخراج الروابط | أقل من 5 علامات <a> صالحة في المصدر |
ستضيع ميزانية الزحف (Crawl Budget) في انتظار لا ينتهي. |
| استهلاك ذاكرة تنفيذ البرمجيات | أكثر من 50 ميجابايت من استهلاك ذاكرة المكدس (Stack) | قد ينهي خادم الرندر المهمة قسراً بسبب قيود الذاكرة. |
| اكتمال HTML فوق الطية | أقل من 10% من المحتوى المرئي متاح في المصدر | سيرى المستخدم صفحة بيضاء لفترة طويلة، مما يضر بإشارات الترتيب. |
افحص قائمة التنقل في لوحة Elements؛ إذا ظهر الرابط كـ <a href="javascript:void(0)" onclick="navigateTo('/page')">، فعلى الرغم من أنه يبدو كرابط، إلا أنه بالنسبة لبرامج زحف محركات البحث يعد طريقاً مسدوداً لا يمكن تتبعه.
يجب أن تكون سمة href القياسية موجودة بالفعل في HTML الأصلي المرسل من الخادم، أو يتم إنتاجها بعد تشغيل البرمجيات بتنسيق <a href="/target-path"> القياسي.
المواقع التي تمتلك بنية روابط HTML أصلية كاملة عادة ما يتم فهرسة صفحاتها الجديدة بسرعة أكبر بنسبة 40% إلى 70% من المواقع التي تعتمد كلياً على حقن الروابط عبر JS.
إذا كانت هناك علامة meta بقيمة noindex في كود المصدر، وحاول منطق البرمجيات إزالتها واستبدالها بـ index بعد الرندر، فإن هذا الإجراء غالباً ما يكون غير فعال.
تلتزم محركات البحث عادةً بالتعليمات التي تجدها في HTML الأولي، مما يؤدي إلى فشل الصفحة في دخول عملية الفهرسة العادية.
التحقق عبر محاكاة البيئة
في متصفح Chrome، افتح أدوات المطورين (DevTools)، واضغط Ctrl+Shift+P لفتح قائمة الأوامر، واكتب Disable JavaScript ثم اضغط Enter؛ هذه هي نقطة البداية لمحاكاة حالة الزحف الأولى لمحرك البحث.
أعد تحميل الصفحة بعد تعطيل البرمجيات؛ إذا ظهرت الشاشة فارغة أو بهيكل أساسي فقط، فهذا يعني أن Initial HTML من الخادم لا يحتوي على أي محتوى نصي جوهري.
بالنسبة لملف HTML بحجم 100 كيلوبايت، إذا كان 90% من محتواه النصي يعتمد على حزمة JavaScript بحجم 2 ميجابايت يتم تحميلها لاحقاً، فعند حدوث تأخير في الشبكة أو خطأ في التنفيذ، من المرجح جداً أن يسجل محرك البحث حاوية فارغة فقط.
| معايير المحاكاة | معايير الضبط والقيم | النتائج والمؤشرات الملاحظة |
|---|---|---|
| تقييد الشبكة (Network Throttling) | Fast 3G (محاكاة 1.5 Mbps، تأخير 40ms) | إذا تجاوز وقت رندر المحتوى الرئيسي 5000ms (5 ثوانٍ)، قد يتوقف طابور رندر Google. |
| تقييد CPU | 4x slowdown (محاكاة أداء معالج الجوال) | إذا تجاوز وقت تحليل البرمجيات 1.5 ثانية، سيؤدي انشغال الخيط الرئيسي لتأخر الرندر. |
| محاكاة User-Agent | Googlebot Smartphone | التحقق مما إذا كان الخادم يرجع خطأ 403 أو كوداً مخصصاً للجوال. |
| حجم منفذ العرض (Viewport) | 411 x 731 بكسل (عرض الجوال القياسي) | التأكد من تحميل المحتوى تلقائياً دون الحاجة للنقر أو السحب. |
قم بتغيير سلسلة User-Agent للمتصفح إلى Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html).
في لوحة Network، حدد Disable cache وراقب سلسلة تحميل الموارد بهوية Googlebot.
في عمليات الزحف القياسية، لا يقوم Googlebot عادةً بتحميل جميع ملفات الوسائط، بل يعطي الأولوية لتحليل النصوص والبيانات المنظمة.
إذا كانت الصفحة تكتشف وكيل المستخدم عبر البرمجيات وتنفذ منطقاً مختلفاً، مثل إغلاق بعض الواجهات غير المتزامنة للزحف، فسيؤدي ذلك إلى اختلاف بنية DOM في لوحة Elements عما يراه المستخدم العادي.
في لوحة Network، اضبط سرعة الشبكة يدوياً على Fast 3G وقيد أداء CPU إلى 4x slowdown.
موارد الحوسبة التي تخصصها خوادم رندر Googlebot لكل صفحة محدودة عند التعامل مع مليارات الصفحات. استخدم لوحة Performance لتسجيل عملية التحميل والتركيز على نشاط الخيط Main.
إذا كانت المهام الطويلة الناتجة عن Evaluate Script تتجاوز 50 مللي ثانية وتشكل أكثر من 70% من دورة التحميل، ففي بيئة الزحف الحقيقية، قد ينهي محرك الرندر لقطة البيانات قبل اكتمال تعبئة المحتوى.
إذا اتسعت الفجوة بين First Contentful Paint (FCP) و Largest Contentful Paint (LCP) لأكثر من 3 ثوانٍ بسبب تنفيذ JS، فإن احتمالية زحف محرك البحث لصفحة ناقصة تزداد بنسبة 40% تقريباً.
استخدم علامة تبويب Sensors أسفل أدوات المطورين لمحاكاة مواقع جغرافية مختلفة (مثل سان فرانسيسكو أو لندن).
تتوزع نقاط زحف Googlebot بشكل أساسي داخل الولايات المتحدة. إذا كان منطق JS في الموقع يتضمن إعادة توجيه تلقائية بناءً على IP أو توليد محتوى بناءً على التوقيت المحلي، فقد يؤدي ذلك إلى زحف نسخة من الصفحة لا تتوافق مع نسخة المنطقة المستهدفة.
افحص رسائل الخطأ في لوحة Console، وخاصة ReferenceError أو TypeError.
على الرغم من أن إصدار محرك رندر Google (Evergreen Googlebot) يتم تحديثه باستمرار، إلا أن دعمه لبعض واجهات Web API الحديثة جداً قد يختلف.
إذا لم يتم التعامل مع توافق Polyfill في الكود بشكل جيد، فسيتوقف البرنامج في منتصف التنفيذ، مما يؤدي لتوقف بناء شجرة DOM.
- حد عدد الطلبات: إحصاء إجمالي طلبات الشبكة قبل اكتمال الرندر. إذا تجاوزت الصفحة 50 مورداً من JS أو CSS، فقد لا يتم تحميل بعض البرمجيات في الوقت المناسب بسبب قيود المتصفح وحصص موارد الزحف.
- حالة Shadow DOM: تحقق في لوحة Elements من وجود علامة
#shadow-root (closed). يستطيع Googlebot تحليل Shadow DOM في وضع Open، ولكن محتوى وضع Closed غير مرئي لبرامج الزحف. تأكد من أن جميع Web Components في وضع Open. - التحقق من تنسيق الروابط: في DOM بعد الرندر، ابحث عن علامة
<aباستخدامCtrl+F. تأكد من أن جميع روابط الانتقال تحتوي على سماتhrefكاملة. إذا كان الانتقال يتم عبرwindow.location.hrefدون ترك روابط قياسية في HTML، فلن تكتشف محركات البحث هذه الصفحات الفرعية. - التحميل الكسول للصور (Lazy Load): تأكد من أن علامات
<img>قد استبدلت المحتوى فيdata-srcإلى سمةsrcدون الحاجة للتمرير. يستطيع Googlebot محاكاة بعض التمرير، لكن فعاليته غير مستقرة مع البرمجيات التي تعتمد على مستمعي أحداثscrollالمعقدة. استخدام سمةloading="lazy"القياسية هو الخيار الأكثر أماناً.
قارن حجم البايتات وعدد عقد النص بين Initial HTML و Rendered DOM.
إذا تجاوز فرق تغطية النص بينهما 80%، وكان معظم المحتوى النصي يتم حقنه بعد حدث DOMContentLoaded، فهذا يعني أن SEO الموقع يعتمد بشدة على كفاءة الرندر.
يُنصح بتسجيل Total Blocking Time (TBT) أثناء الاختبار؛ إذا تجاوزت هذه القيمة 300ms، فمن المتوقع أن يعيق تنفيذ البرمجيات تحليل محرك البحث لـ DOM.
استخدم لوحة Coverage في Chrome لمعرفة معدل استخدام ملفات JS. إذا كان 80% من كود ملف JS بحجم 500 كيلوبايت لا يُنفذ عند تحميل الصفحة الأولى، فإن هذا الكود الزائد يستهلك قدرات خادم الرندر هباءً، مما يؤثر على سرعة الفهرسة.
أدوات الزحف الاحترافية
يمكن لأدوات الزحف الاحترافية محاكاة بيئة Chrome (مثل Screaming Frog v20+).
تشير البيانات إلى أن تكلفة زحف البرمجيات أعلى بـ 20 مرة من HTML الثابت.
عندما يتجاوز الفرق في عدد كلمات HTML بين “قبل الرندر” و“بعد الرندر” 10%، أو يتجاوز الفرق في اكتشاف الروابط الداخلية 5%، تنخفض عادةً معدلات نجاح الفهرسة.
يجب أن يركز الفحص على معدل اكتمال الرندر خلال 5 ثوانٍ، وما إذا كانت البرمجيات قد فشلت في التحميل بسبب رمز الحالة 403.
Screaming Frog SEO Spider
عند استخدام Screaming Frog للزحف واسع النطاق، فإن تحويل وضع الرندر من “Text Only” إلى “JavaScript” يغير سلوك الزحف من مجرد طلبات HTTP بسيطة إلى محاكاة كاملة للمتصفح.
سيقوم البرنامج بتشغيل نسخة Headless Chrome لتحليل كل ملف برمجيات على الصفحة.
من الناحية التقنية، يحتاج المستخدم إلى اختيار خيار JavaScript في قائمة Configuration > Spider > Rendering.
التغير في البيانات يكون ملحوظاً جداً؛ فالطلب على ذاكرة الوصول العشوائي (RAM) عند زحف JavaScript يزداد عادة بمقدار 5 إلى 10 أضعاف.
على سبيل المثال، عند زحف 100 ألف صفحة تحتوي على أطر عمل معقدة مثل React أو Angular، يُنصح بتخصيص 16GB إلى 32GB من الذاكرة على الأقل للبرنامج، وإلا قد تنهار عملية رندر Chrome بسبب نقص الموارد.
يحاكي برنامج الزحف إصدار محرك رندر Chrome لضمان توافق بنية DOM التي يتم زحفها مع “Evergreen Chrome” الذي يستخدمه Googlebot حالياً.
| فئة المؤشر | HTML الأصلي (Source) | HTML بعد الرندر (Rendered) | توصية حد التباين |
|---|---|---|---|
| عدد الكلمات (Word Count) | يحتوي فقط على الإطار الأساسي والبيانات الوصفية | يحتوي على النصوص المحملة غير المتزامنة | تباين > 15% يتطلب مراجعة بشرية |
| عدد الروابط الداخلية | 0 أو عدد قليل جداً من الروابط النائبة | روابط التنقل والمنتجات المولدة ديناميكياً | تباين > 0 يشير لوجود خطر في الزحف |
| علامة Canonical | قد تكون مفقودة أو تشير لقيمة افتراضية | النسخة النهائية المعدلة عبر JS | يجب الاعتماد على النسخة بعد الرندر |
| حجم الصفحة (Size) | عادة < 50 KB | قد ينمو إلى 500 KB – 2 MB | الحجم الزائد قد يؤدي لاقتطاعه من قبل Google |
عندما يحاكي البرنامج تنفيذ البرمجيات، يتم ضبط مهلة AJAX Timeout الافتراضية عادةً على 5 ثوانٍ، وهو ما يشبه استراتيجية Googlebot.
إذا كانت استجابة واجهة بيانات الصفحة بطيئة وتأخر ملء DOM لأكثر من 5 ثوانٍ، فستكون نتيجة زحف Screaming Frog صفحة “هيكل فارغ”.
يمكن قياس هذه الظاهرة كمياً بمقارنة عمود Word Count:
إذا كان عدد الكلمات بعد الرندر أقل من عددها في كود المصدر، أو إذا تطابقا تماماً بينما تحتوي الصفحة فعلياً على نصوص كثيرة، فهذا يشير عادةً إلى أن برمجيات الرندر لم تكتمل في الوقت المحدد.
في اختبارات مواقع التجارة الإلكترونية، إذا كانت قائمة المنتجات تُحمل عبر التمرير الديناميكي، يمكن للزاحف محاكاة إجراء التمرير لأسفل لتشغيل البرمجيات وجلب معلومات المنتجات المخفية.
بالنسبة للتدقيق التقني للمواقع الكبيرة، يمكن استخدام “JavaScript Rendering Table” في وظيفة “Bulk Export” لتصدير تقرير تباين الرندر للموقع بالكامل.
يسرد هذا التقرير التغيرات في علامات Title و Meta Description و H1 لكل عنوان URL قبل وبعد الرندر.
في الحالات العملية، إذا وجد أن علامة H1 بعد الرندر أصبحت “Loading…” أو “Undefined”، فهذا يثبت أن محرك البحث يزحف إلى كود الحالة الوسيطة وليس المحتوى النهائي.
تسجل علامة تبويب “Resource” في البرنامج رمز حالة HTTP لكل ملف برمجيات (.js) وملف أنماط (.css).
إذا أرجعت بعض البرمجيات الوظيفية خطأ 403 Forbidden، فغالباً ما يكون ذلك بسبب تعرف جدار حماية الخادم (WAF) على سلوك Headless Chrome كجوم ضار وحظره، مما يؤدي لفشل عرض تخطيط الصفحة ومحتواها بشكل صحيح.
| حالة موارد الرندر | سبب الحدوث | التأثير على الزحف |
|---|---|---|
| Blocked by robots.txt | تم ضبط مسار البرنامج على Disallow | لا يستطيع Googlebot قراءة البرنامج، فشل الرندر |
| Status Code: 429 | تكرار الطلبات العالي أدى لتقييد السرعة | تحميل غير كامل لموارد الصفحة، فقدان المحتوى |
| Status Code: 404 | مسار ملف البرنامج غير صالح | تعطل المكونات الديناميكية المعتمدة على الملف |
| Timeout (Exceeded 5s) | استجابة الواجهة بطيئة أو منطق معقد | HTML المزحوف فارغ أو يحتوي رسائل خطأ |
تسمح وظيفة “Rendered Page” للمستخدم بمقارنة لقطة كود المصدر واللقطة المرئية بعد الرندر جنباً إلى جنب.
بهذه الطريقة، يمكن اكتشاف المحتويات التي تخفيها JavaScript بصرياً، مثل النصوص الموجودة داخل علامات التبويب (Tabs) التي لا تظهر إلا بعد النقر.
إذا كانت نسبة المحتوى النصي في HTML الأصلي أقل من 20%، بينما يعتمد 80% على الرندر، فإن استقرار هذه الصفحة في فهرس Google سيواجه تحديات.
يستطيع Screaming Frog أيضاً التقاط أخطاء وحدة التحكم (Console Errors)؛ وإذا تسببت الصفحة في أخطاء برمجية قاتلة أثناء التحميل، فسيبرزها البرنامج في التقرير.
عند التعامل مع مئات الآلاف من عناوين URL، يُنصح بتفعيل خياري “Store Images” و “Store Rendered HTML”، مما يسمح باسترجاع لقطة الرندر لأي صفحة في أي وقت بعد انتهاء الزحف.
من خلال تحليل “Link Discovery Difference”، يمكن إحصاء نسبة الروابط الداخلية التي تتطلب تشغيل البرمجيات لاكتشافها.
إذا تجاوزت هذه النسبة 30%، فسيصبح عمق الزحف (Crawl Depth) للموقع غير قابل للتحكم بسبب تأخير تنفيذ البرمجيات.
Lumar (DeepCrawl)
تستخدم Lumar قدرات حوسبة سحابية موزعة لتوفير مسح تلقائي للمواقع الكبيرة التي تمتلك ملايين العناوين.
عند التعامل مع المهام التي تتطلب تنفيذ JavaScript، يتم تشغيلها عبر آلاف النسخ من المتصفحات المحاكاة في الخلفية.
تقتصر الأدوات المحلية العادية بمساحة الذاكرة الفعلية؛ فعلى سبيل المثال، جهاز بذاكرة 32GB يمكنه دعم ما بين 20 إلى 50 خيطاً متوازياً فقط في وضع الرندر.
أما Lumar، التي تعمل على خوادم سحابية، فيمكنها التوسع تلقائياً لأكثر من 500 خيط بناءً على حجم المهمة، لضمان اكتمال الرندر الكامل لمليون صفحة خلال 24 ساعة.
إذا استغرق تشغيل برمجيات الصفحة أكثر من 5000 مللي ثانية (5 ثوانٍ)، سيصنف النظام عنوان URL هذا كـ “صفحة عالية التكلفة”، لأن Googlebot لن ينتظر طويلاً في الواقع، مما يؤدي لظهور محتوى فارغ في الفهرس.
في مشاريع React أو Vue القياسية، قد يحتوي HTML الأصلي على 2KB إلى 5KB فقط من كود الإطار، بينما قد تتضخم شجرة DOM بعد الرندر لتصل إلى 300KB إلى 800KB.
يدل هذا النمو الذي يتجاوز 100 ضعف على اعتماد الصفحة الشديد على البرمجيات.
تشمل المؤشرات التي توفرها Lumar إجمالي عدد عقد DOM؛ فإذا تجاوز عدد العقد 1500 (وهو الحد الذي تنصح به Google)، ستنخفض كفاءة الرندر بشكل حاد.
من خلال تسجيل Time to Interactive (وقت التفاعل) و Total Blocking Time (إجمالي وقت الحظر) في السحابة، يمكن للأداة تحديد ملفات JS التي تعيق عرض المحتوى (مثل ملفات vendor.js التي يتجاوز حجمها 500 كيلوبايت).
بالنسبة لمواقع التجارة الإلكترونية الضخمة أو المواقع الدولية، يمكن التحقق مما إذا كانت بعض البرمجيات المسؤولة عن الرندر قد فشلت في التحميل في مناطق معينة بسبب أخطاء في تكوين شبكة توصيل المحتوى (CDN) عبر إرسال طلبات من خوادم في مواقع جغرافية مختلفة.
يسرد تقرير البيانات نسبة موارد البرمجيات ذات رموز الحالة 4xx و 5xx.
إذا كانت 20% من طلبات البرمجيات في الصفحة ترجع خطأ 403 (بسبب حظر robots.txt أو جدار الحماية)، فستكون نتيجة الرندر لتلك الصفحة ناقصة.
ينشئ نظام تقارير Lumar “خريطة تباين الرندر”، توضح بالتفصيل التغير في عدد الروابط الداخلية للصفحة عند تفعيل وتعطيل JavaScript.
إذا انخفض عدد الروابط من 200 إلى 0 عند تعطيل البرمجيات، فهذا يعني أن بنية التنقل تعتمد كلياً على التنفيذ الديناميكي، مما يؤثر سلباً على سرعة اكتشاف Googlebot للصفحات الجديدة.
تدعم المنصة أيضاً دمج بيانات الرندر المزحوفة مع واجهة API الخاصة بـ Google Search Console.
إذا أظهرت البيانات زيادة في عدد الكلمات بنسبة 300% بعد الرندر ولكن دون زيادة مقابلة في حركة البحث، فقد يعني ذلك أن المحتوى المحقون ديناميكياً لم يتم التعرف عليه بشكل فعال من قبل Google.
تخرج Lumar مؤشر Rendered Page Word Count وتقارنه بـ Source HTML Word Count.
الصفحات التي تعاني من فجوة نسبة (Ratio Gap) أكبر تميل لأن تكون أقل استقراراً في معدل الزحف. ومن خلال مراقبة أكثر من 500 ألف عينة، وجد أنه عندما تتجاوز فجوة الرندر 80%، يزداد تأخير الفهرسة عادةً بمقدار 3 إلى 7 أيام.
