قد تتصدر صفحتك نتائج Google، ومع ذلك يعجز وكيل الذكاء الاصطناعي عن قراءتها. تطرح أدوات مثل isitagentready سؤالاً مختلفاً: عندما يزور موقعك برنامج الزحف الذي تعتمد عليه ChatGPT أو Perplexity أو Claude أو Google AI Overviews، هل يستطيع الوصول بوضوح إلى النص الذي تريد الاستشهاد به، من دون تشغيل JavaScript أو تخمين بنية الصفحة؟ نجري هذا الاختبار لعملائنا، وكثيراً ما نرى صفحات تحتل مراكز متقدمة لكنها تفشل فيه. الخلل في معظم الحالات لا يتعلق بجودة المحتوى، بل بالطبقة التي تتيح للآلة قراءته.
isitagentready يختبر ما تقرؤه الآلة، لا ما تراه العين
تركز أدوات SEO التقليدية على كثافة الكلمات المفتاحية والروابط الخارجية ودرجات سرعة الصفحة. أما أدوات مثل isitagentready فتغيّر زاوية النظر: تعامل مع الصفحة كما لو كنت وكيل ذكاء اصطناعي بلا متصفح، لا يرسل سوى طلبات HTTP، ثم افحص ما سيحصل عليه فعلياً. هذا الفارق جوهري؛ فمتصفح المستخدم يشغّل JavaScript ويحمّل الصور ويرتّب الواجهة، بينما تلتقط معظم برامج زحف الذكاء الاصطناعي ملف HTML الأصلي ولا تنتظر اكتمال تشغيل إطار الواجهة الأمامية. وإذا كان عرض المحتوى الأساسي يعتمد على JavaScript، فقد لا يجد الوكيل سوى هيكل شبه فارغ.
لهذا قد يحقق الموقع درجات مرتفعة في Lighthouse، ومع ذلك يظل غير مهيأ إطلاقاً لاستشهاد الذكاء الاصطناعي به. السرعة وسلاسة التفاعل مؤشرات تصف تجربة الإنسان، أما قدرة الآلة على استخراج المحتوى بوضوح فتخضع لمعايير أخرى. والمؤشرات الثمانية التالية هي أساس هذه المعايير.
ثمانية مؤشرات لقابلية القراءة لدى وكلاء الذكاء الاصطناعي
- صلاحيات وصول برامج الزحف: هل يسمح robots.txt وllms.txt لوكلاء الذكاء الاصطناعي مثل GPTBot وClaudeBot وPerplexityBot وGoogle-Extended بالوصول؟
- العرض من جانب الخادم: هل يظهر المحتوى الأساسي في ملف HTML الأصلي من دون الحاجة إلى تشغيل JavaScript؟
- سلامة HTTP: هل رمز الاستجابة هو 200؟ وهل توجد عمليات إعادة توجيه زائدة؟ وهل وسم canonical مضبوط بصورة صحيحة؟
- HTML الدلالي: هل يتبع تسلسل العناوين بنية منطقية؟ وهل تُستخدم الوسوم الدلالية مثل article وmain وnav وغيرها؟
- البيانات المنظَّمة: هل جرى ترميز مخططات Article وFAQPage وOrganization وغيرها باستخدام JSON-LD؟
- البيانات الوصفية: هل العنوان ووصف meta وبيانات Open Graph مكتملة، وهل يصف النص الصفحة بدقة؟
- بنية الإجابة القابلة للاستخراج: هل تُعرض المعلومات الأساسية بصيغ يسهل استخراجها، مثل الأسئلة والأجوبة والتعريفات والجداول؟
- التوافق مع Markdown: هل يمكن تحويل المحتوى الأساسي بوضوح إلى نص عادي أو Markdown من دون ضوضاء عناصر التنقل والتنسيق؟
تحدد المؤشرات الثلاثة الأولى ما إذا كان الوكيل سيتمكن من رؤيتك.
يأتي وصول برامج الزحف في صدارة الأولويات لأنه شرط حاسم. فإذا كان robots.txt يحظر GPTBot، أو كانت شبكة CDN تمنع افتراضياً أي User-Agent لا ينتمي إلى متصفح، فلن تفيدك بقية المؤشرات السبعة مهما أتقنتها؛ فالوكيل لن يدخل إلى الموقع أصلاً. المعالجة مباشرة: تأكد من أن robots.txt يسمح بوضوح لبرامج زحف الذكاء الاصطناعي الشائعة، وأضف ملف llms.txt يتضمن، بنص عادي، الصفحات التي تريد الاستشهاد بها أكثر من غيرها مع وصف موجز لكل صفحة. شركات كثيرة لا تدرك أنها تحظر هذه البرامج، وغالباً ما تكون هذه أول مشكلة نكتشفها منذ اليوم الأول.
المؤشر الثاني هو العرض من جانب الخادم. افتح الصفحة عبر «عرض المصدر» بدلاً من «فحص العنصر». إذا لم يظهر النص في المصدر، فالأرجح أن الوكيل لن يراه أيضاً. وتُعد تطبيقات الصفحة الواحدة (SPA) الأكثر تعرضاً لهذه المشكلة، إذ تحمّل الواجهة الأمامية المحتوى كله بينما لا يحتوي HTML الأصلي إلا على عنصر div فارغ. الحل هو تطبيق العرض من جانب الخادم أو التوليد الثابت، بحيث يصل النص كاملاً ضمن الاستجابة الأولى. أما المؤشر الثالث، وهو سلامة HTTP، فيعالج الأساس التقني: تأكد من أن الصفحة تعيد الرمز 200 بدلاً من soft 404، وأزل طبقات إعادة التوجيه، واجعل canonical يشير إلى عنوان URL الصحيح الوحيد، وامنع الخادم الوكيل من التقاط نسخ مكررة أو منتهية الصلاحية.
تحدد المؤشرات الثلاثة الوسطى ما إذا كان الوكيل سيفهم المحتوى.
بعد دخوله إلى الصفحة، يحتاج الوكيل إلى تمييز العنوان من النص الأساسي وعناصر التنقل. يمنحه HTML الدلالي هذه الخريطة: عنوان h1 واحد فقط في الصفحة، وتسلسل عناوين بلا قفزات، ومحتوى أساسي داخل main أو article، مع تمييز الشريط الجانبي والتذييل بوسومهما المناسبة. قد لا يلحظ الإنسان مشكلة في واجهة مبنية من عناصر div بلا دلالة، لكن الآلة لا ترى فيها سوى كتل متشابهة. بعد ذلك، أضف طبقة واضحة من البيانات المنظَّمة: استخدم JSON-LD لتخبر الوكيل مباشرة بأن «هذا مقال، وهذا مؤلفه، وهذا تاريخ نشره»، أو استخدم FAQPage لترميز أزواج الأسئلة والأجوبة. بهذه الخطوة تنتقل من مطالبة الآلة بالتخمين إلى تزويدها بالمعلومة صراحةً.
كثيراً ما تُعامل البيانات الوصفية، وهي المؤشر السادس، باعتبارها تفصيلاً هامشياً، مع أنها أول قرينة يعتمد عليها الوكيل لتحديد موضوع الصفحة. ينبغي أن يصف العنوان محتواها بدقة بدلاً من حشوه بالكلمات المفتاحية، وأن يصلح وصف meta للاقتباس كجملة مستقلة، بينما تحدد وسوم Open Graph شكل الرابط عند إعادة عرضه أو صياغته. لا تتجاوز هذه الحقول الثلاثة مجتمعة 20 سطراً من الشفرة، لكنها تؤثر مباشرة في قرار الوكيل بإدراج صفحتك ضمن الإجابة.
يحدد المؤشران الأخيران ما إذا كان الوكيل سيستشهد بك.
لا يكفي أن يفهم الوكيل المحتوى؛ بل يجب أن يستطيع اقتطاع فقرة واستخدامها مباشرة. وتعني بنية الإجابة القابلة للاستخراج أن تصوغ الخلاصة الأساسية في جملة مكتملة ومستقلة، ويفضل أن تأتي فور السؤال أو العنوان الفرعي ذي الصلة، لا بعد ثلاث فقرات تمهيدية. وتناسب الجداول والتعريفات وقوائم الخطوات الوكلاء على نحو خاص، لأن حدودها واضحة ويسهل فصلها عن بقية النص. أما التوافق مع Markdown فهو فحص الجودة الأخير: بعد تحويل الصفحة إلى نص عادي، هل يظل المتن واضحاً وسلساً، أم تقطّعه قوائم التنقل والإعلانات وأزرار الشبكات الاجتماعية؟ كلما ارتفعت نسبة المحتوى المفيد إلى الضوضاء، زادت فرص الاستشهاد به من دون تشويه.
بعد إجراء الاختبار، ما الذي ينبغي إصلاحه أولاً؟
لا حاجة إلى معالجة المؤشرات الثمانية دفعة واحدة. رتّب العمل وفق المراحل الثلاث: «أن يراك الوكيل، وأن يفهمك، وأن يستشهد بك». ابدأ بالشرطين الحاسمين، وهما وصول برامج الزحف والعرض من جانب الخادم، ثم أضف البيانات المنظَّمة والوسوم الدلالية، وأخيراً حسّن بنية الإجابات. عندما نجري عمليات تدقيق GEO لعملاء B2B SaaS، يكفي عادةً إصلاح الطبقتين الأوليين لوصول معظم الصفحات إلى مستوى الاجتياز خلال ثلاثين يوماً. وهما غالباً الأسرع أثراً في الظهور، لأنهما تعالجان الخلل الجوهري: «الوكلاء لا يستطيعون قراءة الصفحة أصلاً».
يمنحك isitagentready درجة، لكنه لا يحدد المؤشر الأشد تأثيراً في أعمالك ولا حجم الموارد الذي يستحقه الإصلاح. إذا أجريت الاختبار بالفعل ولم تعرف من أين تبدأ، يمكنك حجز جلسة تشخيص GEO مدتها ثلاثون دقيقة. سنختبر عنوان موقعك الفعلي وفق المؤشرات الثمانية، ونوضح الفجوات التي ينبغي معالجتها أولاً.
