الأساس التقني في تحسين محركات البحث الذي تفوّته مواقع الذكاء الاصطناعي

روبوتان مختلفان يقومان بمهمتين مختلفتين

أوضح بيانات مباشرة (first-party) حول هذا الموضوع تأتي من شركة Vercel، التي تدير جزءاً كبيراً من بنية الويب الحديثة، وبالتالي تستطيع رصد حركة الروبوتات الفعلية على نطاق واسع. في تحليلها "صعود روبوت الذكاء الاصطناعي" (The rise of the AI crawler)، تذكر Vercel أن Googlebot يقوم بنحو 4.5 مليار طلب شهرياً عبر شبكتها، مقابل 569 مليون لـGPTBot، و370 مليوناً لروبوتات Claude، و314 مليوناً لـAppleBot، و24.4 مليوناً فقط لـPerplexityBot — وأن إجمالي حركة روبوتات الذكاء الاصطناعي مجتمعة لا يتجاوز ربع حجم حركة Googlebot تقريباً. لكن الحجم ليس الجزء المثير للاهتمام في هذا التقرير. الجزء المثير هو هذا: تقول Vercel صريحاً إن "لا أحد من روبوتات الذكاء الاصطناعي الكبرى ينفّذ جافاسكريبت فعلياً حالياً"، وتُسمّي من بينها OAI-SearchBot وChatGPT-User وGPTBot التابعة لOpenAI، وClaudeBot التابع لAnthropic، وMeta-ExternalAgent التابع لMeta، وBytespider التابع لByteDance، وPerplexityBot — جميعها تسحب كود HTML الخام للصفحة وتتوقف عند ذلك. هي تُنزّل ملفات جافاسكريبت كنص عادي — GPTBot يفعل ذلك في 11.5% من طلباته، وClaude في 23.84% — لكن لا توجد بيئة تنفيذ خلف تلك الروبوتات تحوّل ذلك الكود إلى محتوى معروض فعلياً. من بين الروبوتات التي تتبعها Vercel، AppleBot وزاحف Gemini التابع لGoogle فقط هما من يشغّلان محرك متصفح حقيقياً.

هذا فرق بنيوي حقيقي عن الطريقة التي تعاملت بها Google مع الويب منذ سنوات، منذ تحوّلها إلى ما تسميه "Googlebot الدائم التحديث" الذي يشغّل نسخة حديثة من Chromium. لكنه، من زاوية أخرى، ليس فرقاً جديداً بالمعنى الحقيقي: توجيهات Google نفسها، في وثيقة "Rendering on the Web"، توصي منذ سنوات بالعرض من جهة الخادم (server-side) أو العرض الثابت (static) بدلاً من الاعتماد الكامل على إعادة البناء من جهة المتصفح (client-side rehydration) — ليس كتنازل خاص بعصر الذكاء الاصطناعي، بل كممارسة جيدة عادية، لأنها تُنتج عرضاً أولياً أسرع، وإمكانية وصول أفضل، ومحتوى مقروء لأي شيء يقرأ HTML مباشرة بدلاً من تنفيذ كود لبنائه. روبوتات الذكاء الاصطناعي لم تخترع شرطاً جديداً. هي فقط أزالت شبكة الأمان التي سمحت للمواقع بتجاهل الشرط القديم لسنوات. استعداد Googlebot للانتظار وتشغيل جافاسكريبت الموقع كان دائماً الاستثناء، لا القاعدة، بين كل ما يقرأ الويب — لكنه كان الاستثناء الذي أنفقت الشركات خمسة عشر عاماً في تحسين مواقعها حوله، لدرجة أن معظمها لم يفكر أبداً في بقية الحالات.

ما تقوله OpenAI وAnthropic وPerplexity فعلاً عن روبوتاتها

يستحق الأمر قراءة الوثائق الأصلية بدلاً من ملخص عنها، لأن الشركات الكبرى الثلاث تفصل بين التدريب والبحث بشكل مختلف عمّا تفترضه معظم محتويات SEO. وثائق OpenAI الرسمية للروبوتات تفصل بين GPTBot (لجمع بيانات التدريب)، وOAI-SearchBot (الروبوت الذي يشغّل فعلياً إجابات ChatGPT المرتكزة على البحث)، وChatGPT-User (يُستدعى مباشرة، وسط محادثة، عندما يدفع سؤال المستخدم النموذج للذهاب وجلب صفحة محددة) — ثلاثة عناوين مستخدم (user agents) مختلفة بثلاث وظائف مختلفة، وحظر واحد منها لا يحظر الآخرين. Anthropic تتبع تقسيماً مشابهاً، كما ذكرت Search Engine Land بناءً على تحديث وثائق Anthropic نفسها: ClaudeBot لتدريب النموذج، وClaude-User للطلبات المباشرة التي يقوم بها Claude عندما يسأله مستخدم عن شيء يتطلب صفحة محددة، وClaude-SearchBot لجودة نتائج البحث تحديداً. لا شيء في أي من هذه الوثائق يذكر تنفيذ جافاسكريبت كميزة، عند أي من الشركتين — وهذا يتطابق تماماً مع ما تُظهره بيانات Vercel الفعلية عن سلوكها الحقيقي.

النتيجة العملية هي أن سؤال "هل أحظر روبوتات الذكاء الاصطناعي" وسؤال "هل تستطيع روبوتات الذكاء الاصطناعي قراءة صفحتي فعلاً" هما سؤالان منفصلان تماماً، ومعظم الشركات لا تتحقق إلا من الأول. قد يكون لدى موقع ملف robots.txt متسامح تماماً، يرحّب بكل روبوت معروف باسمه، ومع ذلك يُقدّم لكل واحد منها صفحة شبه فارغة إذا كان المحتوى نفسه غير موجود في HTML الذي يولّده الخادم.

هل سرعة الصفحة مهمة فعلاً هنا؟

هنا يصبح البحث أكثر تعقيداً بصدق، وهنا يبالغ كثير من نصائح AEO في تبسيط الأمر. دراسة دقيقة نُشرت على Search Engine Land في يناير 2026، أجراها Dan Taylor من وكالة SALT.agency على 107,352 صفحة ظاهرة في نتائج AI Overviews وAI Mode من Google، وجدت ارتباطات ضعيفة فقط بين مؤشرات Core Web Vitals والظهور في الذكاء الاصطناعي، باستخدام معامل ارتباط Spearman — إذ تراوح ارتباط Largest Contentful Paint بين -0.12 و-0.18، وCumulative Layout Shift بين -0.05 و-0.09. صياغة Taylor نفسه للنتيجة هي الجزء المفيد: "مؤشرات Core Web Vitals لا تعمل كرافعة نمو للظهور في الذكاء الاصطناعي. هي تعمل كقيد (constraint)." أن تكون سريعاً لا يمنحك استشهادات إضافية. أن تكون بطيئاً بشكل كارثي، أو غير مستقر بشكل كارثي، كافٍ لأن يستبعدك النظام بهدوء من المنافسة قبل أن تبدأ حتى مقارنة جودة المحتوى.

هذا التمييز مهم لأنه يواجه نسخة مبتذلة من هذا الجدل، سهلة التكرار: "الذكاء الاصطناعي يهتم بسرعة الصفحة، فحسّن مؤشرات Core Web Vitals وستحصل على استشهادات أكثر." البيانات الفعلية تقول شيئاً أضيق وأكثر فائدة — Core Web Vitals هي حد أدنى، لا عامل ترتيب، وبعد تجاوز هذا الحد، عوامل أخرى تقوم بأغلب العمل الفعلي. تحليل Ahrefs لـ75,000 علامة تجارية وظهورها في AI Overviews وجد أن الإشارات النصية للعلامة التجارية (branded web mentions) ترتبط بمعدل 0.664 مع تكرار الاستشهاد، مقابل 0.218 فقط للروابط الخلفية (backlinks) — العلامات التجارية في النصف الأدنى من الإشارات النصية حصلت في المتوسط على 0 إلى 3 ظهورات فقط في AI Overviews، مقابل 169 ظهوراً للربع الأعلى، فجوة عشرية كاملة لا علاقة لها بزمن تحميل الصفحة. لا شيء من ذلك يجعل الأساس التقني اختيارياً. هو فقط يعيد تعريف وظيفته الحقيقية: ليس رافعة نمو بذاته، بل الشرط المسبق الذي يسمح لكل شيء آخر — المحتوى، والبيانات المنظمة، وإشارات العلامة التجارية — أن يُقرأ أصلاً.

الطبقة البنيوية تحت طبقة المحتوى

بمجرد أن تتجاوز الصفحة عتبة العرض — أي يصبح المحتوى موجوداً كنص HTML حقيقي يستطيع روبوت الذكاء الاصطناعي تحليله دون تنفيذ أي شيء — تصبح الطبقة التالية هي ما إذا كان الموقع يخبر ذلك الروبوت بما ينظر إليه فعلاً. هنا تتوقف البيانات المنظمة (structured data)، وعلامات canonical، ونظافة خريطة الموقع (sitemap) عن كونها خانة امتثال شكلية، وتصبح الفرق بين صفحة تُفهم بشكل صحيح وصفحة يُخمَّن محتواها. صفحة منتج بلا بيانات منظمة من نوع Product وOffer تفرض على النموذج استنتاج السعر والتوافر والهوية من نص عادي؛ صفحة مكرّرة عبر ثلاث معاملات رابط مختلفة بلا علامة canonical تُقسّم أي سلطة أو إشارة حداثة تملكها الصفحة على ثلاثة اتجاهات بدلاً من تجميعها في مكان واحد. لا شيء من هذا حكمة SEO جديدة — إنه نفس الأساس التقني الذي كافأته محركات البحث لعقد كامل. ما تغيّر هو أن أنظمة الاسترجاع بالذكاء الاصطناعي وَرِثت المتطلب نفسه بتسامح أقل مع الإهمال، لأنه لا توجد لديها خطوة عرض (rendering) تعود إليها عندما لا يتعاون الترميز.

هذا هو الحجة الفعلية لاعتبار إعادة التصميم أو إعادة البناء الخطوة الأولى، لا خطوة تحسين لاحقة، عندما تكون مشكلة ظهور شركة في الذكاء الاصطناعي بنيوية في جوهرها لا تحريرية. استراتيجية المحتوى، وبيانات FAQ المنظمة، والكتابة الموجّهة للاستشهاد، كل ذلك عمل حقيقي بعائد حقيقي — لكنه يُبنى فوق أساس، وإذا كان ذلك الأساس تطبيق صفحة واحدة يُعرض بالكامل من جهة المتصفح بلا بديل من جهة الخادم، أو ملف robots.txt يحظر بهدوء نصف الروبوتات المهمة، أو خريطة موقع لم تُعاد إنشاؤها منذ تغيير بنية الروابط قبل ثمانية عشر شهراً، فإن عمل المحتوى يُبنى على رمال. خدمتنا في تطوير المواقع الإلكترونية موجودة بالضبط بسبب مشكلة الترتيب هذه — مواقع مخصصة، ولوحات تحكم، ومواقع WordPress ومتاجر WooCommerce، مصمَّمة منذ أول سطر برمجي لأداء حقيقي في Core Web Vitals، وHTML دلالي صحيح، وبيانات منظمة تعمل فعلاً، وقابلية زحف حقيقية لكل من محركات البحث التقليدية ومحركات إجابة الذكاء الاصطناعي، بدلاً من بناء يبدأ بالتصميم ثم يحصل على "لمسة SEO تقنية" لاحقاً عندما يتضح أن شيئاً لا يعمل.

ما الذي دار حوله النقاش الفعلي على Hacker News

الجزء الأكثر فائدة في نقاش aggeeinn الأصلي لم يكن الإحصائيات الرئيسية — بل الخلاف الذي دار تحتها. عندما شكّك معلّق باسم JohnFen في ما إذا كان رقم 30% حظراً "بالخطأ" فعلاً أو مجرد خيار متعمد من الشركات، رسم رد aggeeinn تمييزاً يستحق التذكر:

"نميّز بينهما بحسب دقة القاعدة نفسها. إذا كان ملف robots.txt يذكر GPTBot أو CCBot بالاسم صريحاً، نعتبر ذلك حظراً متعمداً. المجموعة العرضية هي المواقع التي تستخدم قواعد عامة من نوع User-agent: * disallow (وغالباً متبقية من بيئة staging)..."

— aggeeinn، في نقاش Hacker News "زحفت إلى 1,500 موقع"

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

معلّق آخر، باسم CableNinja، اتخذ موقفاً معارضاً تماماً — يريد فعلياً حظر كل روبوت ذكاء اصطناعي يستطيع تحديده، ووصف قاعدة صغيرة في إعدادات nginx تُعيد استجابة HTTP 418 ("أنا إبريق شاي") لعناوين المستخدم المعروفة للذكاء الاصطناعي. رد aggeeinn سمّى التكلفة الحقيقية لهذا النهج بصدق: الحفاظ على قائمة حظر يدوية محدَّثة في مواجهة عناوين مستخدم تتغيّر باستمرار هو "مشكلة لعبة الخُلد" (whack-a-mole)، لأن روبوتات جديدة أو عناوين مُعاد تسميتها تظهر أسرع من قدرة معظم فرق التشغيل على تحديث إعداداتها. آخر تعليق في النقاش هو الأكثر إثارة للاهتمام فعلاً — لاحظ aggeeinn أن Perplexity بدأت بالفعل تستشهد بإحصائية الـ0.2% (نسبة استخدام llms.txt) من النقاش نفسه في إجاباتها على استعلامات غير مرتبطة حول جاهزية المواقع لروبوتات الذكاء الاصطناعي، بعد نحو ثلاث ساعات فقط من نشر الموضوع — وهو بحد ذاته دليل صغير وحقيقي على مدى سرعة تحوّل رقم محدد وموثّق جيداً على Hacker News إلى إجابة يولّدها الذكاء الاصطناعي في مكان آخر تماماً. يمكن قراءة النقاش كاملاً على news.ycombinator.com/item?id=46632157.

لماذا تصمد حجة "إعادة البناء أولاً" أكثر في سوق ثنائي اللغة

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

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

ما يبدو عليه بناء متين تقنياً فعلاً

عند جمع هذا البحث معاً، تصبح القائمة العملية محددة فعلاً، لا مثالية طموحة. يجب أن يوجد المحتوى في الاستجابة الأولى من الخادم كـHTML حقيقي وقابل للتحليل — لا داخل حزمة جافاسكريبت فقط يجب تشغيلها قبل ظهور النص — سواء كان ذلك عرضاً حقيقياً من جهة الخادم، أو توليداً ثابتاً للموقع، أو نهجاً هجيناً مع بديل فعّال بلا جافاسكريبت لأي جزء يُعرض من جهة المتصفح. يجب أن تطابق البيانات المنظمة فعلاً ما هو موجود على الصفحة: بيانات Product وOffer على صفحات المتاجر، وترميز Organization وLocalBusiness متسق عبر كل صفحة يظهر فيها، وبيانات FAQ منظَّمة تعكس أسئلة شائعة مرئية فعلاً بدلاً من حشوها بكلمات مفتاحية لم يسألها أحد. يجب أن تشير علامات canonical إلى نسخة واضحة واحدة من كل صفحة، ويحتاج ملف robots.txt إلى تدقيق فعلي مقابل القائمة الحالية لعناوين مستخدم الذكاء الاصطناعي المعروفة بدلاً من إعداد افتراضي عمره خمس سنوات، وتحتاج خريطة الموقع XML إلى إعادة إنشاء تلقائية عند تغيّر بنية الروابط بدلاً من تحديث يدوي، عرضي، يعتمد على تذكّر شخص ما له. لا تحتاج Core Web Vitals إلى أن تكون استثنائية — بيانات Search Engine Land واضحة في أنها لا تشتري استشهادات إضافية — لكنها تحتاج إلى تجاوز عتبة الفشل، لأن صفحة تنتهي مهلتها أو تتحرك عناصرها بشكل كافٍ للإخلال قد تُستبعد من مجموعة الاسترجاع قبل أن يهمّ أي شيء آخر مما سبق.

التحقق من موقع محدد مقابل هذه القائمة، بدلاً من التخمين، هو بالضبط ما تكشفه أداة AEO Score في دقائق قليلة — نقطة انطلاق حقيقية ومدعومة بالدليل قبل الالتزام بميزانية لبرنامج محتوى أو لإعادة بناء كاملة.

أين يترك هذا شركة تحاول تحديد ما تُصلحه أولاً

الجزء غير المريح في هذا البحث، مجتمعاً، هو أنه يعيد ترتيب النصيحة المعتادة. معظم نقاشات AEO تبدأ بالمحتوى — ماذا تكتب، وكيف تبني الإجابة، وأي الأسئلة تستهدف — وتعامل البناء التقني كافتراض في الخلفية يُفترض أنه سليم. البيانات القادمة من Vercel، ومن Search Engine Land، ومن Ahrefs، ومن مطوّر شعر بفضول كافٍ لكي يزحف إلى 1,500 موقع وينشر نتائجه، كلها تشير في الاتجاه نفسه: بالنسبة لجزء كبير من الشركات، هذا الافتراض خاطئ، ولا يمكن لأي كمّية من استراتيجية المحتوى أن تُصلح صفحة لا يستطيع روبوت الذكاء الاصطناعي قراءتها فعلاً. الترتيب الصحيح، حين تكون مشكلة ظهور موقع في الذكاء الاصطناعي بنيوية لا تحريرية، هو إصلاح الأساس أولاً — العرض، والترميز، وقابلية الزحف — ثم جعل عمل المحتوى يقع فعلاً على شيء يمكن أن يُرى.

الأسئلة الشائعة