موقع جاهز لوكلاء الذكاء الاصطناعي: ما الذي يقرؤونه فعلاً؟

كل أسبوع بيطلع اقتراح جديد اسمه «خلي موقعك جاهز للـ AI»: ملف هنا، وترويسة هناك، وفولدر غريب اسمه .well-known. السؤال الحقيقي: إيه اللي الوكلاء بيقروه فعلاً النهارده، وإيه اللي لسه كلام على ورق؟ هنفرزهم واحد واحد، ونخرج بقائمة تنفّذها على موقعك في ساعة.

بصراحة: هذا المقال قراءة لما نشره فريق Elementor عن حالة هذه الأساليب بتاريخ أكتوبر 2026، وليس نتيجة اختبار على موقع عندنا. معظم ما يلي ما زال مقترحات وليس معايير منشورة، وشركات الذكاء الاصطناعي لا تعلن أيها تقرأ زواحفها.

ما معنى أن يكون موقعك جاهزاً للوكلاء؟

وكيل الذكاء الاصطناعي (AI Agent) هو برنامج يقرأ صفحاتك ويبحث فيها وقد ينفذ إجراءً عليها نيابةً عن مستخدم، مثل مساعد يُسأل «فين أرخص كوب سيراميك متاح عند المتجر ده؟». الموقع الجاهز يسمح للوكيل بثلاثة أشياء: أن يقرأ المحتوى، وأن يستعلم عن إجابة محددة، وأن يتصرف، مع بقاء القرار بيدك في من يدخل وماذا يفعل.

لكل وظيفة من هذه أدواتها، ومستوى نضجها مختلف تماماً:

الوظيفة	الأسلوب	الحالة اليوم
القراءة	llms.txt ونسخ Markdown من الصفحات	منتشر، غير معتمد كمعيار
—	—	—
الاستعلام	البيانات المنظمة وخوادم MCP	البيانات المنظمة قديمة وراسخة، وMCP منتشر بين المساعدين
الاكتشاف	ترويسة Link وملفات /.well-known/	ملف واحد فقط أصبح معياراً منشوراً
الثقة	Content Signals	طوعي، ومعظم الزواحف لا تقرؤه بعد
التنفيذ	WebMCP	مقترح مبكر

جاهزية الوكلاء

ما الذي يقرؤه الوكلاء اليوم؟

• قراءة
  

  صفحة HTML واضحة

  المصدر الأول للوكلاء: عناوين مرتبة ومحتوى ظاهر دون JavaScript.

• استعلام
  

  البيانات المنظمة

  Schema بصيغة JSON-LD، مع إبقاء الحقائق في النص الظاهر أيضاً.

• قراءة
  

  نسخ Markdown

  رابط .md وتفاوض على المحتوى، مع Vary: Accept في الكاش.

• فهرس
  

  llms.txt

  خريطة مختصرة لأهم صفحاتك، اختيارية ولا تتحكم في شيء.

• ثقة
  

  Content Signals

  سطر في robots.txt يحدد البحث وإجابات الذكاء الاصطناعي والتدريب.

• استعلام
  

  خادم MCP

  إجابات حية لمن يربط مساعده بموقعك، لا للزائر العابر.

ابن موقعك قطعة قطعةarabcms.com

ابدأ بالصفحة نفسها قبل أي ملف جديد

أكثر ما يقرؤه الوكلاء اليوم هو صفحة HTML العادية، لذلك فهي صاحبة الأثر الأكبر. إذا كان المحتوى يظهر فقط بعد تحميل JavaScript، فقد يصل الوكيل إلى صفحة فارغة تقريباً.

راجع هذه النقاط على أهم صفحاتك:

1. عناوين حقيقية بترتيب منطقي: h1 ثم h2 ثم h3، دون قفز.
2. الرابط رابط والزر زر، وليس div يستجيب للنقر.
3. النص الأساسي موجود في HTML عند التحميل، وليس محمّلاً لاحقاً.
4. النماذج سهلة الوصول: لكل حقل label، وقيم autocomplete صحيحة، ورسائل الخطأ مرتبطة بحقولها عبر aria-describedby، ورسالة نجاح تُعلَن بعد الإرسال.

في Elementor: يذكر فريق Elementor أن أداة Ally Checker عندهم تكشف مشكلات إمكانية الوصول في النماذج والصفحات. وتحقق كذلك من أن ودجت الـ Tabs والـ Accordion لا تخفي محتوى مهماً لا يظهر إلا بالنقر.

ملف llms.txt: فهرس مختصر، لا أكثر

ملف llms.txt ملف بصيغة Markdown في جذر الموقع (example.com/llms.txt) اقترحه Jeremy Howard على llmstxt.org. يبدأ باسم الموقع وسطر يلخصه، ثم يسرد أهم الصفحات تحت عناوين، مع رابط وجملة لكل صفحة.

الفرق الجوهري عن robots.txt: الأخير يحدد ما يُسمح بجلبه، أما llms.txt فلا يتحكم في شيء. هو مجرد فهرس يختصر على الوكيل الزحف على الموقع كله.

مثال لموقع خدمات عربي (عدّل الروابط والوصف لموقعك):

# ArabCMS

> Arabic tutorials for WordPress, Elementor and JetEngine site builders.

## Tutorials

- [JetEngine Query Builder](https://example.com/jetengine-query-builder/): Build dynamic listings from custom fields.
- [Speed up WordPress](https://example.com/wordpress-speed/): Caching, images and Core Web Vitals.

## Services

- [Contact](https://example.com/contact/): Project inquiries and consulting.

بحسب Elementor، أضافت النسخة الثانية من المقترح هذا العام شرطاً واحداً: أن تشير الصفحة إلى الملف بترويسة Link أو بوسم <link rel="describedby">. أبسط صورة للوسم داخل <head>:

<link rel="describedby" href="https://example.com/llms.txt">

في ووردبريس: توجد في مستودع ووردبريس إضافات تولّد llms.txt تلقائياً من صفحاتك ومقالاتك، وبعض إضافات السيو أضافت الميزة أيضاً. افتح الملف الناتج بنفسك بعد التوليد، فالقائمة التلقائية غالباً تحتاج إلى حذف صفحات لا قيمة لها مثل الوسوم والأرشيف.

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

نسخ Markdown من صفحاتك: أخف وأرخص على الوكيل

الصفحة نفسها بصيغة Markdown أصغر بكثير من نسختها HTML، لأن القوائم والسكربتات والتنسيقات والإعلانات تختفي ويبقى المحتوى. الصفحة الأخف أرخص في المعالجة، وتترك مساحة أكبر في نافذة السياق (Context Window) لسؤال المستخدم نفسه.

هناك طريقتان لتقديم هذه النسخة، والأفضل أن تقدّمهما معاً من نسخة واحدة محفوظة:

• رابط .md منفصل: عادةً هو رابط الصفحة مع .md في آخره. يحتاج الوكيل أن يعرف بوجوده، فتشير إليه بوسم <link rel="alternate"> أو ترويسة Link أو ضمن llms.txt.
• التفاوض على المحتوى (Content Negotiation): يطلب الوكيل رابط الصفحة العادي مع ترويسة Accept: text/markdown، فيرد الخادم بـ Markdown بدل HTML. يذكر المصدر أن وكلاء البرمجة مثل Claude Code يرسلون هذه الترويسة بالفعل.

تنبيه: التفاوض يشارك HTML وMarkdown في رابط واحد، فلا بد أن يرسل الخادم Vary: Accept، وأن يحترمها الكاش والـ CDN ويخزنا النسختين منفصلتين. إن لم يحدث ذلك فقد يصل الزائر العادي إلى نسخة Markdown المخزنة، وقد يعرضها المتصفح كملف للتنزيل. اسأل استضافتك صراحةً عن هذا قبل التفعيل.

خيار Cloudflare: التحويل على الحافة

إن كان موقعك خلف Cloudflare، فخدمة Markdown for Agents تجلب HTML صفحتك وتحوّلها إلى Markdown على خوادمها، وتضيف البيانات المنظمة في آخرها، وترفق ترويسة x-markdown-tokens بتقدير لحجم الصفحة. هذا أسهل خيار لأنه لا يحتاج نسخة ثانية من المحتوى.

العيب أن النتيجة بجودة HTML الأصلي فقط، ولا تتحكم فيما يخرج. فإذا كان المحتوى يظهر عبر JavaScript فلن يحلّ التحويل المشكلة.

ملاحظة: لم نجد ما يوضح كيف تتعامل هذه التحويلات مع صفحات عربية من اليمين لليسار، ولم يُختبر بالعربية في هذا المقال. النص العربي نفسه لا يتأثر بصيغة Markdown، لكن راجع أن الجداول وأكواد الـ shortcode لا تتحول إلى بقايا غير مفهومة.

في Elementor: يشير الفريق إلى ميزة Generate website markdown لتوليد نسخ Markdown من صفحات الموقع. أياً كانت الأداة، القاعدة واحدة: نسخة محفوظة تُحدَّث عند النشر، والكاش يفصل بين النسختين.

البيانات المنظمة: أقدم أداة وما زالت الأنفع

البيانات المنظمة (Schema markup) موجودة منذ 2011، وتصف حقائق الصفحة بمفردات schema.org مثل Product وArticle وFAQPage وOrganization، غالباً بصيغة JSON-LD. هكذا لا يخمّن الوكيل أي رقم في الصفحة هو السعر، أو أي تاريخ هو تاريخ النشر.

هذا هو المثال الذي أورده المصدر لمنتج في متجر:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Ceramic coffee mug",
  "offers": {
    "@type": "Offer",
    "price": "24.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  }
}
</script>

في متجر مصري تصبح priceCurrency هي EGP، وفي متجر سعودي SAR. لا تترك الدولار لأن القالب جاء به.

المشكلة الوحيدة: أدوات كثيرة يستخدمها الوكلاء لجلب الصفحات تحذف كل وسوم <script>، ومنها JSON-LD. لذلك اجعل الحقائق المهمة كالسعر والتوفر وأوقات العمل مكتوبة في نص الصفحة الظاهر أيضاً، لا في الوسوم وحدها.

في ووردبريس: إضافات السيو المعروفة تولّد معظم هذه البيانات تلقائياً، وWooCommerce يضيف بيانات المنتج. افحص صفحة منتج واحدة بأداة اختبار النتائج المنسقة من Google قبل أن تضيف أي شيء يدوياً، حتى لا تكرر الـ Schema مرتين.

ملفات الاكتشاف تحت /.well-known/

الاكتشاف هو كيف يعرف الوكيل ما يوفره موقعك دون تخمين الروابط. أبسط أدواته ترويسة Link في استجابة الخادم، لأنها تشير في سطر واحد إلى llms.txt وخريطة الموقع والـ Feed معاً، دون أن يحمّل الوكيل الصفحة.

أما الجديد فهو مجموعة ملفات في المجلد /.well-known/:

• /.well-known/api-catalog: يسرد واجهات الـ API في موقعك، وهو الوحيد بين هذه المقترحات الذي صار معياراً منشوراً من IETF (‏RFC 9727).
• /.well-known/agent-skills/index.json: يسرد «مهارات» مكتوبة بـ Markdown تشرح للوكيل كيف يستخدم الموقع، وما زال مسودة.
• /.well-known/ai-catalog.json و/.well-known/agent-card.json: بطاقات تصف خادم MCP أو وكيل الموقع الخاص، وقليل جداً من المواقع والوكلاء يستخدمها.

بصراحة: أغلب الوكلاء المعروفين لا يبحثون عن هذه الملفات بعد، لكن أدوات تقييم «جاهزية الوكلاء» تحتسبها. لو موقعك صغير، أجّلها لما بعد البنود الأساسية.

Content Signals: قل ماذا يفعلون بمحتواك

robots.txt يحدد من يجلب ماذا. أما إشارات المحتوى (Content Signals)، التي قدمتها Cloudflare في 2025، فتضيف سطراً يقول ماذا يفعل البوت بالمحتوى بعد جلبه. هذا المثال يسمح بالفهرسة وبالاستخدام في إجابات الذكاء الاصطناعي، ويمنع التدريب:

User-agent: *
Allow: /
Content-Signal: search=yes, ai-input=yes, ai-train=no

• search: فهرسة محركات البحث.
• ai-input: استخدام الصفحة مدخلاً مباشراً في إجابة ذكاء اصطناعي.
• ai-train: تدريب النماذج.

تنبيه: بحسب Elementor، إذا لم يرسل خادمك ترويسة Content-Signal، فنسخ Markdown التي تقدمها Cloudflare لصفحاتك تفترض السماح بكل شيء بما فيه التدريب. إن كنت ترفض التدريب، أرسل الترويسة من خادمك أيضاً ولا تكتفِ بسطر robots.txt.

الإشارات طوعية، ومعظم الزواحف لا تقرؤها بعد، لكنها أوضح طريقة متاحة لإعلان موقفك. وراجع أيضاً إعدادات البوتات في لوحة الاستضافة والـ CDN، فقد تحجب وكلاء الذكاء الاصطناعي دون علمك.

خوادم MCP: للعملاء الدائمين لا للزائر العابر

إذا كان llms.txt وMarkdown يساعدان الوكيل على القراءة، فإن خادم MCP (MCP Server) يسمح له بطرح سؤال مباشر والحصول على إجابة حية، مثل «ابحث عن الأكواب المتاحة بأقل من 30 دولاراً» في استدعاء واحد. يذكر المصدر أن كل متجر Shopify لديه خادم MCP للواجهة يبحث في الكتالوج ويدير سلة الشراء.

العائق أن شخصاً لا بد أن يضيف عنوان الخادم إلى مساعده، وأحياناً أن يسجل دخوله. لذلك يناسب MCP صاحب الموقع وفريقه والعملاء الدائمين أكثر من زائر يدخل لأول مرة. وWebMCP، وهو مقترح من مهندسين في Google وMicrosoft، يحاول سد هذه الفجوة بأن تقدم الصفحة أدواتها لوكيل يعمل داخل متصفح الزائر.

في ووردبريس: ووردبريس يبدأ بأفضلية: Feeds وخريطة موقع وREST API مدمجة. ومع Abilities API في النواة وإضافة MCP Adapter تستطيع الإضافات وصف ما يمكن للوكيل فعله على موقعك وعرضه عبر MCP.

قائمة التنفيذ: بالترتيب

ابنِ الجاهزية قطعة قطعة، وابدأ بما يفيد البشر والوكلاء معاً:

1. نظّف HTML: عناوين مرتبة، ومحتوى ظاهر دون JavaScript، ونماذج سهلة الوصول.
2. البيانات المنظمة: تأكد من وجودها وصحتها، وأن الحقائق ظاهرة في النص أيضاً.
3. راجع الحجب: robots.txt وإعدادات البوتات في الاستضافة والـ CDN، ثم أضف سطر Content Signals.
4. نسخ Markdown: رابط .md وتفاوض على المحتوى، مع Vary: Accept وكاش يفصل النسختين.
5. llms.txt: مع وسم <link rel="describedby"> يشير إليه.
6. أعلن ما تنشره: Feeds وخريطة الموقع والـ API في ترويسات Link.
7. راقب السجلات: سجلات الخادم تكشف أي الوكلاء يزورك وماذا يطلبون، وهي أصدق من أي تقرير جاهزية.

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

س: هل ملف llms.txt يحسّن ظهور موقعي في ChatGPT أو جوجل؟
ج: لا يوجد ما يثبت ذلك. شركات الذكاء الاصطناعي لا تعلن أن زواحفها تقرؤه، وهو فهرس اختياري. أضفه لأنه سهل، ولا تتوقع منه نتيجة وحده.

س: ما الفرق بين robots.txt وllms.txt؟
ج: robots.txt يحدد ما يُسمح للزواحف بجلبه، وقد يمنع الوصول فعلاً. أما llms.txt فلا يمنع ولا يسمح بشيء، بل يقدّم قائمة مختصرة بأهم صفحاتك.

س: كيف أمنع تدريب الذكاء الاصطناعي على محتوى موقعي؟
ج: أضف Content-Signal: search=yes, ai-input=yes, ai-train=no إلى robots.txt وأرسله كترويسة من خادمك. الإشارة طوعية، فبعض البوتات قد تتجاهلها، لكنها أوضح إعلان متاح حالياً.

س: هل تقديم نسخة Markdown من صفحاتي يضر بالسيو؟
ج: لا يضر إن ضُبط الكاش بشكل صحيح. الخطر الحقيقي أن يخزن الكاش نسخة Markdown ويقدمها للزوار، لذلك تأكد من ترويسة Vary: Accept ومن دعم استضافتك لها.

س: هل أحتاج خادم MCP لموقع شركة صغيرة؟
ج: غالباً لا في البداية. MCP مفيد لمن يستخدم خدمتك بانتظام من مساعده، أما للزائر الجديد فالصفحة الواضحة والبيانات المنظمة أهم بكثير.

الخلاصة

ما يقرؤه الوكلاء اليوم هو صفحتك العادية: HTML واضح، وبيانات منظمة، ونسخة Markdown من الصفحة نفسها. الملفات الجديدة سهلة الإضافة لكنها تخدم وكلاء قليلين حتى الآن، والثقة ما زالت الحلقة الأضعف.

ابدأ بالبندين الأول والثاني من القائمة النهارده، والباقي خده على مهلك.

مرجع المقال (بالإنجليزية): The agent-ready approaches that are catching on, and what AI agents actually use
المقال ده مش ترجمة حرفية: متكيّف للقارئ العربي ومضاف عليه سياق ووردبريس وElementor وJetEngine.