هل يرى Googlebot فعلاً ما يعرضه موقعك المبني على React أو Next.js؟

المشكلة

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

الأعراض

• أداة فحص الروابط في Search Console تُظهر لقطة شاشة معروضة تفتقد محتوى ظاهراً في متصفح عادي، أو تنجح خطوة "جلب الصفحة" بينما تُظهر "لقطة الشاشة" موارد محجوبة أثناء العرض.

• المحتوى المفهرس للصفحة (عبر بحث `site:` أو الكود المعروض في أداة الفحص) متأخر بشكل واضح عن آخر تحديث منشور، حتى بعد مرور أسابيع.

• محتوى يُجلب عبر استدعاء من جهة العميل بعد تحميل الصفحة (مثل `useEffect` مع طلب API) لا يظهر إطلاقاً في نسخة HTML المفهرسة لدى جوجل.

• روابط داخلية مبنية فقط عبر معالِج `onClick` أو عناصر `<a>` تُضاف بواسطة الكود دون خاصية `href` حقيقية، فلا يكتشفها محرك زحف لا ينفّذ كل معالِجات الأحداث.

• بيانات وصفية أساسية (العنوان، الرابط الأساسي، الوصف) تُضبط من جهة العميل بعد اكتمال الترطيب (hydration) بدلاً من وجودها في استجابة الخادم الأولى، فيختلف ما يظهر عبر `curl` أو عرض المصدر عما يعرضه المتصفح لاحقاً.

كيف نشخّص المشكلة

نبدأ بأهم اختبار: جلب الرابط بنفس طريقة محرك الزحف (طلب HTTP مباشر بلا متصفح ولا تنفيذ جافاسكريبت) ومقارنته بشجرة DOM الكاملة المعروضة عبر متصفح بلا واجهة. أي عنصر موجود في DOM المعروض وغائب عن الاستجابة الخام يُعد مرشحاً لفجوة فهرسة مرتبطة بالعرض. نراجع أيضاً لقطة الشاشة المعروضة و"عرض الصفحة كما زحفها جوجل" في Search Console، ونفحص تبويب الشبكة بحثاً عن طلبات تحجب العرض الأول أو تفشل، إضافة لبيانات مؤشرات الويب الأساسية الميدانية (راجع صفحة مؤشرات الويب الأساسية لدينا) لأن بطء الترطيب ومشاكل الفهرسة غالباً ما تشترك في نفس السبب الجذري.

الحل

الحل غالباً هو نقل المحتوى إلى استجابة الخادم الأولى بدلاً من تركه معتمداً على تنفيذ جافاسكريبت من جهة العميل — عبر العرض من جانب الخادم، أو التوليد الساكن، أو مكونات الخادم المتدفقة لكل ما يهم الفهرسة (العناوين، النص، وسوم الروابط الأساسية والبيانات الوصفية، الروابط الداخلية بخاصية href حقيقية). المحتوى التفاعلي البحت فعلاً (لوحة تحكم خلف تسجيل دخول مثلاً) لا يحتاج هذا؛ المحتوى المقصود به الظهور في نتائج البحث يحتاجه. نتأكد أيضاً أن الموارد الحرجة (الخطوط، الصور الظاهرة أولاً، السكربتات المحجوبة للعرض) غير محظورة بالخطأ في robots.txt، لأن مورداً محجوباً أثناء مرحلة عرض جوجل قد يجعل الصفحة تُفهرَس ناقصة حتى لو كان كود HTML نفسه سليماً.

تفاصيل التنفيذ

هذا الموقع نفسه مبني على App Router في Next.js: كل صفحة أساسية ضمن `src/app/[lang]/[...slug]/page.tsx` هي مكوّن خادم (Server Component) تحسم دالة `generateMetadata()` فيه العنوان والوصف والرابط الأساسي ووسوم hreflang من جهة الخادم قبل تنفيذ أي كود من جهة العميل — وهو نفس النمط الموصوف في هذه الصفحة وليس توصية نظرية فقط. جسم الصفحة يُسلَّم بعدها لمكونات العميل (ملفات `"use client"` ضمن `src/components/PageContent/`) للتفاعل فقط (الحركات، القوائم القابلة للطي)، وليس للمحتوى النصي نفسه الذي يصل ضمن HTML الأولي عبر ملفات الترجمة المستهلكة من جهة الخادم. للمواقع المبنية على Next.js تحديداً نفحص: قرار العرض الساكن أو الديناميكي لكل مسار (تغطية `generateStaticParams`)، وهل مكونات العميل مجرد غلاف للترطيب حول محتوى مُعرَض من الخادم أم جزيرة عرض من جهة العميل تُخفي المحتوى حتى يكتمل تحميل الكود، وهل استيرادات `next/dynamic` المستخدمة لتقسيم الحزم (نمط `dynamic-loaders` المعتمد في هذا الموقع) ما زالت تُعرَض من جهة الخادم (`ssr: true`) بدلاً من كونها للعميل فقط.

أخطاء شائعة

• اعتبار "يظهر بشكل جيد في أدوات مطوري Chrome" دليلاً على قابلية الفهرسة — هذا يثبت فقط أن المتصفح قادر على تنفيذ الكود، وليس أن مرحلة عرض جوجل ستلتقطه بنفس الجدول الزمني أو الميزانية.

• جلب المحتوى الأساسي للصفحة من جهة العميل (`useEffect` مع استدعاء API) بدلاً من جهة الخادم، مما يخلق احتمالاً حقيقياً أن يُفهرس محرك البحث حالة التحميل بدلاً من المحتوى نفسه.

• استخدام `next/dynamic(..., { ssr: false })` لمحتوى يهم الفهرسة، وهو ما يُخرج الحزمة كاملة من العرض من جانب الخادم وليس فقط جانبها التفاعلي.

• حظر حزم JS/CSS في robots.txt (ممارسة قديمة من عصر ما قبل محركات الزحف القادرة على العرض) وهو ما يمنع فعلياً جوجل من عرض الصفحة بشكل صحيح اليوم.

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

التحقق

نتحقق عبر أداة فحص الروابط في Search Console (لقطة الشاشة المعروضة وكود "عرض الصفحة كما زحفها") على عينة من روابط حقيقية، ومقارنة بين الاستجابة الخام و DOM المعروض عبر القوالب الرئيسية للموقع، وفحص robots.txt بحثاً عن حظر غير مقصود لملفات JS/CSS، وبيانات مؤشرات الويب الأساسية الميدانية للتأكد أن الإصلاح لم يكتفِ بنقل المحتوى إلى DOM بل حافظ أيضاً على سرعة كافية لمؤشر INP.

الخدمة والحلول ذات الصلة

تحسين محركات البحث للجافاسكريبت هو الطبقة التي تقوم عليها البيانات الهيكلية ووسوم hreflang والروابط الأساسية — فلا قيمة لأي من هذه الإشارات إن لم يصل المحتوى والبيانات الوصفية التي تحملها إلى محرك الزحف كاملة أصلاً.