لنبدأ بالخلاصة الأهم: تكاد زواحف الذكاء الاصطناعي الشائعة حالياً لا تنفّذ JavaScript إطلاقاً. إذا كان ظهور محتوى صفحتك مرهوناً بتشغيل JS في المتصفح، فستبدو الصفحة فارغة أمام GPTBot وClaudeBot وPerplexityBot. المسألة هنا ليست تحسين ترتيب؛ بل ما إذا كان المحتوى موجوداً في نظر هذه الزواحف أصلاً.
يستند كثيرون إلى تجربة Googlebot لاستنتاج طريقة عمل زواحف الذكاء الاصطناعي، ومن هنا يبدأ الالتباس. طوّر Googlebot على مر السنين قدرة ناضجة نسبياً على عرض JavaScript، ولذلك يستطيع غالباً التقاط محتوى الصفحات المعروضة بالكامل في الواجهة الأمامية، وإن كان ذلك أبطأ وأكثر استهلاكاً للموارد. زواحف الذكاء الاصطناعي تعمل بطريقة مختلفة: يجلب معظمها ملف HTML الأصلي الذي يعيده الخادم، ويقرأه ثم يغادر، من دون فتح متصفح أو انتظار JS أو تنفيذ جولة عرض لاحقة.
زواحف الذكاء الاصطناعي وGooglebot ليسا الشيء نفسه
يزحف Googlebot على مرحلتين. في المرحلة الأولى يقرأ HTML الأصلي ويلتقط ما هو متاح مباشرة. ثم تُضاف الصفحة إلى قائمة انتظار العرض في المرحلة الثانية، حيث يُستخدم متصفح بلا واجهة مثل Chrome لتشغيل JavaScript وإدراج المحتوى المُنشأ ديناميكياً. تستهلك هذه الآلية موارد حوسبة كبيرة، لكن Google مستعدة لتحمّلها لأن البحث هو نشاطها الأساسي.
زواحف شركات الذكاء الاصطناعي لا تملك هذه المرحلة الثانية. فكل من GPTBot التابع لـOpenAI، وClaudeBot التابع لـAnthropic، وزاحف Perplexity، وOAI-SearchBot المسؤول عن البحث الفوري في ChatGPT، ينهي عمله حالياً عند HTML. والسبب عملي: تشغيل متصفح بلا واجهة على امتداد الويب مكلف للغاية، كما أن المطلوب هو «نص يمكن إدخاله مباشرة إلى النموذج»، لا إعادة إنتاج المشهد البصري لصفحتك. لذلك يصبح ما أنفقته من JavaScript على تفاعلات الواجهة الأمامية والحركات والتحميل الكسول مجرد ضوضاء أو فراغ بالنسبة إلى هذه الزواحف. الاستثناء الوحيد هو Google AI Overviews، لأنها مبنية على فهرس Google القائم وتستفيد بالتالي من قدرات العرض لدى Googlebot. لكن إذا كنت تستهدف الظهور في ChatGPT وPerplexity وClaude، فلا يمكنك المراهنة على تشغيل JavaScript.
كيف تختلف قابلية القراءة للذكاء الاصطناعي بين أساليب العرض الثلاثة؟
قد يصل المحتوى نفسه إلى زاحف الذكاء الاصطناعي بصور مختلفة جذرياً تبعاً لاستراتيجية العرض. والفارق كله يتلخص في سؤال واحد: هل «كُتب المحتوى داخل HTML على الخادم»، أم «لا يظهر إلا بعد انتهاء تشغيل JS في المتصفح»؟
- SSG (التوليد الساكن): يُنشأ ملف HTML كامل لكل صفحة أثناء عملية البناء ويُحفظ كملف ثابت. يعيد الخادم المنتج الجاهز مباشرة، فيستطيع زاحف الذكاء الاصطناعي التقاط النص كاملاً. وهو الخيار الأسهل قراءةً والأسرع تحميلاً.
- SSR (العرض من جانب الخادم): يجمع الخادم ملف HTML كاملاً في الوقت الفعلي ثم يعيده مع كل طلب. تحصل زواحف الذكاء الاصطناعي هنا أيضاً على النص الكامل، لكن الخادم يدفع كلفة المعالجة في كل مرة؛ لذا ينبغي مراقبة الحمل عند ارتفاع الزيارات.
- CSR (العرض الكامل في الواجهة الأمامية): لا يعيد الخادم سوى هيكل HTML شبه فارغ، ثم يُدرج المحتوى الحقيقي بعد أن ينزّل المتصفح JS وينفّذه. وإذا كان زاحف الذكاء الاصطناعي لا يشغّل JS، فلن يرى سوى ذلك الهيكل الخالي تقريباً من أي نص قابل للاقتباس.
بعبارة مباشرة، لا يوجد فرق جوهري بين SSG وSSR من منظور زواحف الذكاء الاصطناعي؛ فكلاهما يكتب المحتوى داخل HTML على الخادم. الفارق الوحيد هو توقيت المعالجة: تنفّذها SSG مسبقاً، بينما تنفّذها SSR عند الطلب. أما الحد الفاصل الحقيقي فهو CSR. فإذا لم يطبّق إطار تطبيق الصفحة الواحدة (SPA) العرض من جانب الخادم، فغالباً لا يحتوي HTML الأولي إلا على حاوية جذر div فارغة وسلسلة من وسوم script. هذا كل ما يقرأه زاحف الذكاء الاصطناعي، بلا أي نص فعلي.
اختبار ذاتي خلال 30 ثانية
يمكنك معرفة ما إذا كان موقعك يقدّم محتواه بصورة قابلة للقراءة من دون أدوات أو مساعدة المهندسين. افتح صفحة مهمة في المتصفح، وانقر بزر الفأرة الأيمن، ثم اختر «عرض مصدر الصفحة». انتبه: لا تستخدم لوحة Elements في أدوات المطور، لأنها تعرض النتيجة بعد تشغيل JS وقد تمنحك انطباعاً مضللاً. أما «عرض مصدر الصفحة» فيكشف HTML الأصلي الذي أعاده الخادم أولاً، وهو ما يقرأه زاحف الذكاء الاصطناعي فعلياً.
كيف تعالج موقعاً يعتمد على CSR؟
إذا اكتشفت أن موقعك يعتمد على CSR، فلا يلزم هدم الواجهة الأمامية وإعادة بنائها بالكامل. عادةً ما تتوفر ثلاثة مسارات، مرتبة من الأقل إلى الأعلى من حيث كلفة التنفيذ.
- العرض المسبق: عند زيارة الزاحف، يُعاد إليه ملف HTML ثابت جرى إنشاؤه مسبقاً. إنه علاج سريع لتطبيق SPA قائم ولا يتطلب تغييرات كبيرة، لكنه يفرض صيانة إضافية لتحديث اللقطات الثابتة.
- الانتقال إلى إطار يدعم SSR/SSG: تتيح أطر مثل Next.js وNuxt وSvelteKit عرض محتوى الجزء الظاهر أولاً على الخادم مع الاحتفاظ بتفاعلات الواجهة الأمامية. وهذا هو الخيار الافتراضي الأكثر موثوقية الذي نوصي به لمعظم عملاء B2B.
- تطبيق SSR أولاً على الصفحات الأساسية: عندما تكون الموارد محدودة، لا حاجة إلى تحويل الموقع كله دفعة واحدة. ابدأ بالصفحات الأهم كمصادر لإجابات الذكاء الاصطناعي، مثل صفحات المنتجات والخطط والأسعار والمقالات المتعمقة. ويمكن إبقاء لوحة الإدارة والأدوات التفاعلية الأخرى على CSR من دون مشكلة.
ليست كل صفحة بحاجة إلى SSR
استراتيجية العرض قرار موازنة، لا عقيدة تقنية. فلوحات المعلومات والأدوات الداخلية وصفحات الإعداد شديدة التفاعل بعد تسجيل الدخول ليست محتوى يُراد للذكاء الاصطناعي الاستشهاد به. من المنطقي تماماً إبقاؤها على CSR؛ بل إن فرض SSR عليها يزيد حمل الخادم بلا فائدة واضحة. الأولوية الحقيقية للصفحات التي تريد أن «يستخدمها الذكاء الاصطناعي مصدراً للإجابة»: الصفحات التي تشرح المشكلة التي تحلها، وسبب أهمية الحل، وما يميّزه عن البدائل. والقاعدة العملية بسيطة: إذا أردت لمحتوى الصفحة أن يظهر في إجابات ChatGPT أو Perplexity، فيجب أن يكون موجوداً بالكامل داخل HTML القادم من الخادم.
قد ينتظر Googlebot حتى ينتهي JavaScript من العمل، لكن زواحف الذكاء الاصطناعي لن تنتظر. وفي عالم يقرر فيه الذكاء الاصطناعي مَن يستشهد به، يصبح المحتوى غير المرئي كأنه غير موجود.— Tenten GEO
مشكلة قابلية الزحف في معظم مواقع B2B التايوانية ليست ضعف جودة المحتوى، بل أن المحتوى لا يصل إلى الذكاء الاصطناعي من الأساس. وغالباً ما تختبئ المشكلة في اختيار إطار العمل وإعدادات العرض: يبدو الموقع طبيعياً تماماً للعين، ولا ينكشف الخلل إلا عبر «عرض مصدر الصفحة». إذا لم تكن متأكداً من قدرة الذكاء الاصطناعي على قراءة صفحاتك المهمة، فسيستخدم تشخيص GEO الذي نقدمه خلال 30 دقيقة عنوان URL الخاص بك ليبيّن مباشرةً ما إذا كان HTML للجزء الظاهر أولاً يحتوي على محتوى، وأي الصفحات يجب أن تحظى بالأولوية عند تطبيق العرض من جانب الخادم.
