كيف تجعلون موقع علامتكم متعددة الفروع جاهزاً للوكلاء الذكيين في 2026

حدث تحوّل في طريقة عثور الناس على الشركات. ليس تحولاً تدريجياً، بل تحولاً بنيوياً. يستقبل ChatGPT وحده الآن أكثر من 5 مليارات زيارة شهرياً من 900 مليون مستخدم نشط أسبوعياً، فيما نمت حركة Gemini الشهرية بنسبة 647 بالمئة لتبلغ ملياري زيارة خلال السنة المنتهية في مارس 2026. ويتعلق عدد متزايد من هذه الزيارات باستفسارات محلية: “ابحث لي عن طبيب أسنان بتقييمات جيدة قرب Kungsholmen” أو “أي معرض سيارات في Gothenburg لديه أفضل تقييمات للخدمة؟” وداخل ChatGPT، تُطلق المطالبات ذات النية المحلية بحثاً مباشراً على الويب في 59 بالمئة من الحالات، مما يجعل السؤال “ماذا يُعيد موقعك حين يستفسر عنه وكيل ذكاء اصطناعي؟” محركاً مباشراً لزيارات الفروع.

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

هذا هو ما يعنيه مصطلح الموقع “الجاهز للوكلاء”: موقعكم مبنيّ بحيث يمكن لأنظمة الذكاء الاصطناعي اكتشافه وفهمه والتفاعل معه دون توجيه بشري.

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

كيف يختلف اكتشاف وكلاء الذكاء الاصطناعي عن البحث التقليدي؟

تزحف محركات البحث على HTML، وتتبع الروابط، وتبني فهرساً. أما وكلاء الذكاء الاصطناعي فيفعلون شيئاً مختلفاً جوهرياً. فهم:

• يقرؤون البيانات المنظمة مثل JSON-LD وMarkdown بدلاً من تحليل HTML الفوضوي
• يستعلمون عن البروتوكولات لاكتشاف ما يقدّمه الموقع قبل التفاعل معه
• يستدعون الأدوات لتنفيذ إجراءات (الحجز والمقارنة والبحث) بدلاً من مجرد قراءة الصفحات
• يتصلون بالخدمات عبر بروتوكولات موحّدة مثل MCP للوصول إلى بيانات الأعمال الحيّة

يعني هذا التحول أن القواعد قد تغيرت. فقد يكون الموقع الذي يحتل مرتبة جيدة في Google غير مرئي تماماً لوكيل الذكاء الاصطناعي إذا لم يطبّق معايير الاكتشاف التي يعتمد عليها هؤلاء الوكلاء.

والخبر السار أن هذه المعايير موجودة، ومفتوحة، ويمكنكم تطبيقها اليوم.

ما هي حزمة الجاهزية للوكلاء؟

الجاهزية للوكلاء ليست خانة اختيار واحدة. إنها حزمة من المعايير المتكاملة، يعالج كل منها جانباً مختلفاً من تفاعل وكلاء الذكاء الاصطناعي مع موقعكم.

الطبقة الأولى: الوصول إلى المحتوى

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

تُعدّ robots.txt المزوّدة بقواعد صريحة لروبوتات الذكاء الاصطناعي نقطة البداية. فجميع الزواحف الذكية الكبرى تُعلن عن وكلاء المستخدم الخاصة بها، وأبسط ما يمكنكم فعله اليوم وأفضلها دعماً هو تسميتها صراحةً والبتّ في Allow أو Disallow لكل منها:

User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: Applebot-Extended
Allow: /

ولمعظم العلامات متعددة الفروع، يكون السماح لها جميعاً هو القرار الصحيح. فأنتم تريدون أن يُستشهد بكم. وهذه القواعد توجيهات قياسية وفق RFC 9309 تقرؤها جميع الزواحف المُسمّاة، فهذه الطبقة تستند إلى أرضية ثابتة.

أما Content Signals فهي طبقة أحدث وأكثر دقّة فوق robots.txt. تضيف مسودة Content Signals (وهي مسودة إنترنت من IETF من إعداد Michael Tremante وLeah Romm من Cloudflare) توجيهات Content-Signal التي تُعلن كيف يجوز للذكاء الاصطناعي استخدام محتواكم، لا مجرد ما إذا كان يستطيع جلبه:

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

يُخبر هذا زواحف الذكاء الاصطناعي بأنه يمكن استخدام محتواكم في تدريب النماذج (ai-train)، وبناء فهارس البحث (search)، وتوليد إجابات بالذكاء الاصطناعي (ai-input). ويحصل كل قسم User-Agent على Content-Signal خاص به، فيمكنكم تعيين أذونات مختلفة لزواحف مختلفة.

والمقترح واعد ويستحق المتابعة. لكنه لا يزال مسودة مبكرة في IETF، لذا فإن الاعتماد متفاوت: فقد دمجته Cloudflare في robots.txt الذي تديره للمواقع على شبكتها، بينما لم تؤكد مختبرات الذكاء الاصطناعي الكبرى علناً بعدُ ما إذا كانت تقرأ توجيه Content-Signal. وإضافته اليوم هي إعلان عن نواياكم أكثر منها فرضاً لها، وهذا أمر معقول تماماً.

تنبيه صغير: حتى أواخر مايو 2026، كانت إضافة أسطر Content-Signal تُظهر إشعاراً شكلياً بأن “robots.txt غير صالح” في PageSpeed Insights، لأن المدقق كان يعرف فقط التوجيهات الواردة في RFC الأصلي لـrobots.txt. وقد جرى تحديث مدقق Google منذ ذلك الحين، واعتباراً من 26 مايو 2026 لم يعد الإشعار يظهر. قد تستمر بعض أدوات تحسين محركات البحث الأقدم في رصده، لكن التوجيه آمن في كل الأحوال: فـRFC 9309 يُلزم الزواحف بتجاهل الأسطر التي لا تتعرف عليها، وبذلك لن يضرّ بترتيبكم في البحث ولا بوصول الذكاء الاصطناعي.

تمنح مفاوضة المحتوى عبر Markdown وكلاء الذكاء الاصطناعي محتوى نظيفاً ومنظماً بدلاً من HTML الخام. فعندما يرسل وكيل ما Accept: text/markdown في طلب HTTP، يُعيد الخادم Markdown لنفس الرابط القانوني بينما تواصل المتصفحات تلقي HTML. ويمكن توليد Markdown فورياً عند الحافة (نهج Cloudflare) أو بناؤه مسبقاً كملف .md شقيق عند نقطة الأصل (النمط الذي يستخدمه Vercel وSentry وSanity وهذا الموقع). وفي الحالتين، هناك رابط واحد للمحتوى وتتغيّر الاستجابة بحسب ترويسة Accept.

لماذا يهتم الوكلاء. الحجة لصالح Markdown اقتصادية في معظمها. فكل رمز (token) يقرؤه الوكيل أو يولّده يكلّف قدرات حوسبة، وهذا يُترجم مباشرةً إلى زمن استجابة، وإنفاق على واجهات برمجة التطبيقات، وعرض نطاق ترددي. فعنوان Markdown بسيط يكلّف نحو ثلاثة رموز، بينما يستهلك ترميز HTML المكافئ من اثني عشر إلى خمسة عشر رمزاً، وفقاً لإعلان Cloudflare عن “Markdown for Agents”. وعلى مستوى الصفحة كاملةً، عادةً ما يكون HTML النظيف أكثر تكلفة بمرتين إلى ثلاث مرات من المحتوى نفسه بـMarkdown، أما HTML الواقعي مع CSS وJavaScript وأدوات التتبع فيمكن أن يتضخّم ليصير أكثر بثماني إلى عشر مرات، وفقاً لتحليل Beam.ai لـHTML مقابل Markdown. وقاست Cloudflare منشور إعلانها فبلغ 16,180 رمزاً بصيغة HTML و3,150 رمزاً بصيغة Markdown، أي انخفاض بنسبة 80%. وأبلغت Vercel عن قصة مماثلة من زاوية عرض النطاق الترددي: فقد بلغ حجم نسخة HTML لصفحة على موقعها نحو 500 كيلوبايت بينما جاءت نسخة Markdown بحجم 3 كيلوبايت، أي تقليصاً بنسبة 99% في الحمولة فوق توفير الرموز. والرقمان يقيسان أمرين مختلفين (رموز مقابل بايتات) ويأتيان من شركتين مختلفتين بمنهجيتين مختلفتين، لكنهما يلتقيان عند القصة نفسها. وعلى أسعار النماذج الرائدة، يتراكم هذا الفارق بسرعة عبر جلسة كاملة، ويمكن إنفاق ما يُوفَّر من حوسبة وعرض نطاق على مزيد من الاستدلال، أو مزيد من استدعاءات الأدوات، أو ببساطة على طلب أرخص.

ولا تتوقف الفوائد عند التكلفة. فعدد الرموز الأقل يعني مساحة أوسع في نافذة سياق الوكيل للمهمة الفعلية، وزمناً أسرع للحصول على أول رمز لأن ما يجب جلبه وتحليله أقل، ونسبة إشارة إلى ضجيج أنظف للاسترجاع (لا قوائم تنقّل ولا إعلانات ولا نوافذ منبثقة ولا أغلفة تخطيط تنافس المحتوى). كما أن Markdown هو التنسيق الذي دُرِّبت عليه النماذج اللغوية الكبيرة إلى حد بعيد (ملفات README على GitHub، والوثائق التقنية، والمخرجات المولَّدة)، فيميل إلى أن يكون أكثر مدخلاتها انسيابيةً افتراضياً. بل تُضيف Cloudflare ترويسة استجابة x-markdown-tokens بجانب المخرجات المحوَّلة، وفق توثيق Cloudflare Fundamentals، حتى يتمكن الوكيل من فحص عدد الرموز مسبقاً وتقرير ما إذا كانت الوثيقة تناسب نافذة سياقه أم تحتاج إلى تقسيم.

من يدعمها اليوم. بحسب متعقّب الحالة في acceptmarkdown.com، بدأ دعم العملاء في أدوات البرمجة وينتشر الآن في أسطح العمل ذات الأغراض العامة. ترسل Claude من Anthropic ترويسة Accept: text/markdown من Claude Code ومن Cowork في تطبيق Claude لسطح المكتب (تم التحقق من ذلك في اختبارات سجل الطلبات الخاصة بنا وقت كتابة هذه السطور)، ما يعني أن مفاوضة المحتوى عبر Markdown لم تعد شأناً يخصّ وكلاء البرمجة وحدهم: فـCowork هو سطح البحث والصياغة والتصفح داخل تطبيق سطح المكتب، فأي وثيقة عمل أو مراجعة منافس أو مقالة يطلب مستخدم Claude من Cowork جلبها تمرّ عبر هذا المسار. أما تجربة الدردشة العادية في تطبيق سطح المكتب وعلى claude.ai فلا ترسل الترويسة بعد. وترسلها أيضاً Cursor وOpenCode وOpenClaw. ويدعمها Codex CLI من OpenAI دعماً جزئياً، إذ يجلب أولاً الرابط القانوني بصيغة HTML ثم يبحث عن <link rel="alternate" type="text/markdown"> في الترويسة قبل طلب ملف Markdown الشقيق. أما الأسطح الموجهة للمستهلكين (ChatGPT browse وGemini وPerplexity وCopilot browse) فلا ترسل الترويسة في الغالب اليوم، ولذلك يُفهم هذا في الوقت الحالي على أنه تحسين لوكلاء البرمجة وأسطح عمل Claude، مع ترجيح أن تلحق به الوكلاء الموجهة للمستهلكين. ويستحق الأمر إجراء فحص خاص بكم قبل الاعتماد على عميل بعينه، فهذه السلوكيات تتغيّر بسرعة.

من يدفع بها. هذا عُرف متعدد البائعين، لا دفعة من شركة واحدة. ولا يوجد عمل رسمي في IETF بشأنه، بل مجرد نمط مبنيّ على معايير قائمة (مفاوضة المحتوى في RFC 7231 ونوع الوسائط text/markdown في RFC 7763). على جانب البنية التحتية والمنصات، يحوّل “Markdown for Agents” من Cloudflare HTML إلى Markdown عند الحافة للمواقع المشتركة في خطط Pro وBusiness وEnterprise، بينما تُقدّم Vercel Markdown عبر مفاوضة المحتوى على ممتلكاتها الخاصة مع دليل تطبيق على Next.js. كما تتراكم تطبيقات نقطة الأصل عبر منظومة أنظمة إدارة المحتوى وأدوات المطورين: يُقدّم Sentry Markdown عبر ترويسات Accept، ونشرت Sanity دليلاً ميدانياً لتقديم المحتوى للوكلاء، ويوثّق DeployHQ هذا النمط عبر Laravel وExpress وDjango والمواقع الساكنة، وأصدرت Roots إضافة لـWordPress تعالج مفاوضة المحتوى على الروابط القانونية. وهناك أيضاً نقاش على GitHub حول Next.js يعمل فيه مستخدمو الإطار على كيفية توصيله، وأدلة تطبيق مخصّصة لمسار خارج Cloudflare. وعلى جانب العملاء، قادت Anthropic وAnysphere الاعتماد أولاً عبر Claude Code وCursor. لا توجد شركة واحدة تتحكم في العُرف، وما يجعل الانتشار حقيقياً هو سعة الحزم التي تتبنّاه بشكل مستقل.

أين تقف Google. أبدى John Mueller من Google تشكّكاً علنياً تجاه فكرة “Markdown للروبوتات” عموماً، واصفاً الفكرة بأنها “فكرة سخيفة” على Bluesky، وسائلاً على Reddit لماذا يحتاج الوكلاء إلى صفحة لا يراها أي مستخدم، طالما أن النماذج اللغوية الكبيرة دُرّبت دائماً على HTML وحلّلته. ويتبنّى دليل تحسين الذكاء الاصطناعي الرسمي من Google الموقف نفسه، إذ يدرج ملفات Markdown الخاصة بالذكاء الاصطناعي ضمن الأشياء التي لا تحتاجون إلى إضافتها لتظهر صفحاتكم في أسطح الذكاء الاصطناعي التوليدي لديها. وقد أبدى Fabrice Canel من Microsoft قلقاً مماثلاً من إنشاء نسخ منفصلة من المحتوى للزواحف، مستشهداً بحمل زحف إضافي وخطر إهمال النسخ التي لا يراها المستخدم وانحرافها عن التحديث. غير أنه يستحق قراءة اعتراضاتهما بعناية، لأنها تستهدف نمطاً قريباً لكنه مختلف: تقديم Markdown مختلف تماماً على رابط منفصل بناءً على استشعار وكيل المستخدم. أما مفاوضة المحتوى الحقيقية، حيث يقدّم الرابط ذاته إما HTML أو Markdown للمحتوى نفسه بناءً على ترويسة Accept، فهي آلية HTTP راسخة منذ زمن (تماماً كما يمكن تقديم الصور بصيغة WebP أو JPEG بحسب ما يدعمه العميل). ومن الجدير الانتباه إلى أن إرشادات Google تتعلق بـالظهور في منتجاتها الخاصة للذكاء الاصطناعي، بينما حُجّة اقتصاديات الرموز أعلاه تتعلق بـالكفاءة لأي وكيل اختار بالفعل قراءة محتواكم. والخط الفاصل بين الأمرين مهم.

مفاضلات يجب معرفتها. أكثر المخاطر مناقشةً هي صيغة من الإخفاء (cloaking). فقد أظهر الباحث في تحسين محركات البحث David McSweeney أن تطبيق Cloudflare على الحافة يُمرّر ترويسة Accept: text/markdown إلى نقطة الأصل، أي أنه يُخبر نقطة الأصل فعلياً بأن “هذا الطلب من وكيل ذكاء اصطناعي”. وفي مثاله التوضيحي، أعادت نقطة الأصل صفحة للبشر وصفحة مختلفة تماماً للوكلاء، وحوّلت Cloudflare بأمانة HTML المستهدف للوكلاء إلى Markdown. والحلّ المقترح هو أن يُجرّد مزوّدو الحافة الترويسةَ قبل الجلب من نقطة الأصل، رغم أن ذلك ليس الإعداد الافتراضي بعد. والخاصية نفسها تفتح ثغرة لحقن المطالبات للوكلاء الذين يتخذون إجراءات نيابةً عن المستخدم، إذ لا يرى المستخدم أبداً ما يقرؤه الوكيل. أمور أخرى يجب وزنها: تُفعّل Vary: Accept التخزين المؤقت السليم لكلا التمثيلين لكنها قد تُخفّض نسب الإصابة وتُعقّد سلوك شبكة توصيل المحتوى، كما أن Markdown المحوَّل عند الحافة عام، فبالنسبة إلى الصفحات التسويقية والمنتجاتية الغنية بالتصميم، تكون نسخة Markdown المؤلَّفة عند نقطة الأصل عادةً أفضل قراءةً مما ينجو من جولة تحويل آلية من HTML إلى MD.

و**llms.txt** هو ملف Markdown في جذر موقعكم يقدّم نظرة عامة منسّقة عن الموقع لأنظمة الذكاء الاصطناعي. اقتُرح هذا العُرف في 2024 وتبنّته بعض المواقع، لكن لا يوجد زاحف ذكاء اصطناعي كبير يعتمده رسمياً بعدُ بوصفه إشارة اكتشاف. ويُجمّع دليل تحسين الذكاء الاصطناعي من Google صراحةً llms.txt ضمن الأشياء التي لا تحتاجون إلى إنشائها، بحجّة أن أنظمة الذكاء الاصطناعي قادرة على تحليل HTML العادي بكفاءة. ومع ذلك، أضاف مدقق Lighthouse التابع لـGoogle فئة “Agentic Browsing” في الإصدار v13.2 (أبريل 2026) وجعلها جزءاً من الإعدادات الافتراضية في الإصدار v13.3 في الأسبوع التالي. وهذه الفئة تتحقق صراحةً من وجود llms.txt في جذر النطاق، فالصورة إذاً مختلطة. والفئة لا تُمنح درجة مرجّحة على مقياس من 0 إلى 100 ما دامت المعايير في طور النضج، مما يجعل فحص llms.txt إشارة استرشادية لا إشارة ترتيب. ومع توفّر مفاوضة المحتوى عبر Markdown، يحصل الوكلاء بالفعل على Markdown نظيف لأي صفحة يجلبونها، مما يُلغي معظم حالة الاستخدام الأصلية. ويُمكن القول إن llms.txt أكثر فائدةً للمواقع ذات الوثائق التقنية الكثيفة، حيث تُساعد الخريطة المنسّقة الوكلاء على إيجاد نقطة الدخول الصحيحة. أما للعلامات متعددة الفروع، حيث يكون كل فرع وكل منشور مدوّنة قابلاً للاكتشاف بشكل مستقل عبر خريطة الموقع ومفاوضة Markdown، فالعائد أصغر.

الطبقة الثانية: البيانات المنظمة

هل يستطيع وكلاء الذكاء الاصطناعي فهم معنى محتواكم؟

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

أضيفوا مخططات FAQPage وProduct وArticle وBreadcrumbList حيث يلزم. وكلما زادت البيانات المنظمة التي تقدّمونها، زادت قدرة وكيل الذكاء الاصطناعي على اقتباسكم وتوصيتكم بثقة.

الطبقة الثالثة: اكتشاف البروتوكولات

هل يستطيع وكلاء الذكاء الاصطناعي العثور على أدواتكم وقدراتكم؟

هذه أحدث طبقة والأسرع تطوراً. وثمة ثلاثة معايير ناشئة تعالج جوانب مختلفة من اكتشاف الأدوات:

تتيح لكم MCP Server Cards (SEP-2127، المقترحة من فريق MCP بقيادة David Soria Parra في Anthropic) الإعلانَ عن خادم Model Context Protocol الخاص بكم على /.well-known/mcp-server-card. وإذا كان لدى نشاطكم خادم MCP، فإن هذا يُخبر عملاء الذكاء الاصطناعي بالطريقة الدقيقة للعثور عليه والاتصال به.

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/v1/server-card.schema.json",
  "name": "com.example/my-location-mcp",
  "version": "1.0.0",
  "description": "Query location data across all business locations"
}

وتنشر Agent Skills (Cloudflare RFC) فهرساً لقدرات موقعكم على /.well-known/skills/index.json. وكل مهارة هي ملف Markdown يصف ما يستطيع الوكلاء فعله في موقعكم، من البحث في قاعدة المعرفة إلى مقارنة منتجاتكم بمنتجات المنافسين.

أما WebMCP (وهي مواصفة من مجموعة مجتمع W3C يحررها مهندسون من Google وMicrosoft) فتسجّل أدوات عبر navigator.modelContext.registerTool() يمكن لوكلاء الذكاء الاصطناعي العاملين في المتصفح استدعاؤها مباشرة. فبدلاً من أن يخمّن الوكيل وجود زر “طلب عرض تجريبي” في مكان ما على صفحتكم، تسجّلون أداة request_demo مع وصف ومعاملات ودالة استدعاء للتنفيذ.

navigator.modelContext.registerTool({
  name: "request_demo",
  description: "Book a personalized demo of the platform",
  execute: async () => {
    window.location.href = "/requestademo/";
    return { navigated: "/requestademo/" };
  }
});

وتصف Google WebMCP بأنها “قناة اتصال مباشرة” تُزيل الغموض وتُتيح مسارات عمل أسرع وأكثر متانة للوكلاء.

الطبقة الرابعة: التحكم في الوصول

أي الوكلاء يمكنه فعل ماذا؟

صُمِّمت Content Signals (المذكورة في الطبقة الأولى) للتعامل مع أذونات استخدام المحتوى. يمكنكم التعبير عن السماح بفهرسة البحث مع منع التدريب، أو السماح بكل شيء. ولا يزال الاعتماد في بداياته، فاعتبروه إعلاناً عن تفضيلاتكم لا فرضاً مضموناً.

وتتيح قواعد روبوتات الذكاء الاصطناعي في robots.txt السماحَ صراحةً لزواحف بعينها أو حجبها: GPTBot وClaudeBot وPerplexityBot وGoogle-Extended وApplebot-Extended وغيرها. ويكون السماح لجميع زواحف الذكاء الاصطناعي منطقياً لمعظم العلامات التجارية، لأنكم تريدون أن تكونوا قابلين للاكتشاف.

لماذا تستفيد العلامات متعددة الفروع أكثر من غيرها من الجاهزية للوكلاء؟

قد يُعثر على مقهى بفرع واحد عبر Google Maps وحدها. لكن العلامة التي تمتلك 500 فرع في 12 دولة تواجه تحدياً مختلفاً جوهرياً. فكل فرع يحتاج إلى أن يكون قابلاً للاكتشاف بصورة منفردة من قِبَل وكلاء الذكاء الاصطناعي، ويجب أن تكون البيانات عبر جميع الفروع متسقة ومنظمة وقابلة للقراءة آلياً.

يضاعف الحجمُ الميزةَ. فإذا كان فرع منافس واحد جاهزاً للوكلاء بينما فرعكم ليس كذلك، تخسرون تلك التوصية الواحدة. أما إذا كان لديكم 500 فرع جاهز للوكلاء ولدى منافسكم صفر، فأنتم تكسبون 500 توصية.

تتحوّل الاستفسارات المحلية إلى الوكلاء أولاً. إذ يُعدّ السؤال “ابحث لي عن … قرب …” من أكثر الاستفسارات شيوعاً التي يطرحها الناس على مساعدي الذكاء الاصطناعي. وهذه هي الاستفسارات التي تقود مباشرة إلى زيارات الفروع، وتتطلب بيانات فروع منظمة ومراجعات ومعلومات عن النشاط يستطيع الوكلاء الوصول إليها برمجياً.

يحتاج وكلاء الذكاء الاصطناعي إلى بيانات لحظية. يمكن لخادم MCP تقديم درجات المراجعات الحيّة، وساعات العمل الحالية، وقوائم الخدمات المحدّثة. أما صفحات HTML الساكنة فلا تستطيع ذلك. والعلامات التي تربط بياناتها الحيّة عبر MCP تمنح الوكلاء أحدث المعلومات وأكثرها دقة، مما يجعل الوكلاء أكثر ميلاً إلى التوصية بها.

أولوية التطبيق للعلامات متعددة الفروع

ليست جميع المعايير متساوية الأهمية اليوم. إليكم الترتيب الذي يمنحكم أعلى ظهور بأقل جهد:

ابدؤوا هنا

1. حدّثوا robots.txt بقواعد صريحة لروبوتات الذكاء الاصطناعي (GPTBot وClaudeBot وPerplexityBot وGoogle-Extended وApplebot-Extended)
2. تحققوا من JSON-LD للبيانات المنظمة على جميع أنواع الصفحات (LocalBusiness للفروع، وProduct وFAQPage وArticle)

الخطوات التالية

3. طبّقوا مفاوضة المحتوى عبر Markdown ليحصل وكلاء الذكاء الاصطناعي على محتوى نظيف

المستوى المتقدم

4. انشروا MCP Server Card إذا كان لديكم خادم MCP
5. طبّقوا أدوات WebMCP للإجراءات الرئيسية (طلبات العروض التجريبية، والبحث عن الفروع، والتنقل بين المنتجات)
6. انشروا Agent Skills التي تسرد قدرات موقعكم

إن توفّر لديكم الوقت والموارد، قد يفيدكم هذا

7. أضيفوا llms.txt وllms-full.txt فقط إذا كنتم تُديرون وثائق تقنية كثيفة. أما معظم العلامات متعددة الفروع فيمكنها تخطّي هذا. فالاعتماد متفاوت بين زواحف الذكاء الاصطناعي الكبرى، ويقول دليل تحسين الذكاء الاصطناعي من Google صراحةً إنكم لا تحتاجون إليه، ومفاوضة المحتوى عبر Markdown تُغطّي بالفعل الأرضية نفسها لأي صفحة يجلبها الوكيل. ونمط النظرة العامة المنسّقة أكثر فائدة عندما يحتاج الوكلاء إلى مساعدة في إيجاد نقطة الدخول الصحيحة في وثائق مطورين عميقة، لا حين يكون كل فرع وكل منشور مدوّنة قابلاً للاكتشاف بشكل مستقل عبر خريطة الموقع.
8. أضيفوا توجيهات Content Signals إلى robots.txt لإعلان كيف يجوز للذكاء الاصطناعي استخدام محتواكم. مسودة IETF تتحرّك وتستحق المتابعة. الاعتماد بين زواحف الذكاء الاصطناعي الكبرى لا يزال مبكراً، لكن التوجيه آمن للإضافة (تتجاهل الزواحف الأسطر التي لا تتعرف عليها)، وطريقة لطيفة لتثبيت موقفكم استعداداً للمستقبل.

اختبروا كل شيء

شغّلوا موقعكم عبر isitagentready.com، وهو الماسح الرسمي لجاهزية الوكلاء من Cloudflare (أُطلق في أبريل 2026)، لترَوا أي الفحوصات اجتازها. يُقيِّم الماسح حزمة الطبقات الأربع نفسها المستخدمة في تنظيم هذه المقالة (قابلية الاكتشاف، وقابلية الوصول إلى المحتوى، والتحكم في وصول الروبوتات، والقدرات)، ويُظهر بدقة ما هو مفقود.

وللحصول على رأي ثانٍ، فإن Agent Readiness Score من GEO Metrics مجاني أيضاً ويغطّي الأبعاد الأربعة نفسها، مع محور تحريري إضافي للبيانات المنظمة، والتأليف، وغيرها من إشارات الاقتباس بالذكاء الاصطناعي. وهو فحص مرجعي مفيد عندما تريدون التحقق من صمود نتائجكم أمام منهجية مختلفة.

علاوةً على ذلك، أضاف Lighthouse فئة جديدة “Agentic Browsing” في الإصدار v13.2 (أبريل 2026)، وجرى تفعيلها افتراضياً في v13.3، مع تدقيقات لتسجيل أدوات WebMCP وصحة المخطط ووجود llms.txt في جذر النطاق وبعض إشارات إمكانية الوصول الخاصة بالوكلاء. ولا تُمنح الفئة درجة مرجّحة على مقياس من 0 إلى 100 (“معايير الويب الوكيلي لا تزال في طور التشكّل”)، لذا تعاملوا معها كقائمة تحقق لا كرقم يُطلب تحسينه. وتعمل التدقيقات داخل Chrome DevTools، مما يجعلها مكمّلاً سريعاً للماسحات المتخصّصة في جاهزية الوكلاء المذكورة أعلاه.

المعايير (مايو 2026)

تتحرك هذه المعايير بسرعة. إليكم المشهد الراهن:

والقاسم المشترك بينها جميعاً أنها معايير مفتوحة تدعمها شركات تكنولوجيا كبرى. ولا تخضع أي منها لبائع واحد. ويعني تطبيقها اليوم أنكم تبنون على أسس يتّجه إليها القطاع بأكمله.

ما المعايير القادمة في مجال الجاهزية للوكلاء؟

لا تزال المعايير المتعلقة بالجاهزية للوكلاء في تطور سريع. إليكم بعض الأمور التي يجدر متابعتها:

يسعى Agent Card (من مشروع AI Card) إلى أن يكون صيغة اكتشاف مستقلة عن البروتوكول على /.well-known/ai-catalog.json. اعتبروه دليل هاتف لخدمات الذكاء الاصطناعي على النطاق.

انتقلت بروتوكولات التجارة من خانة “الناشئة” إلى خانة “المُطلقة”. ففي 11 يناير 2026، أطلقت Google Universal Commerce Protocol (UCP)، وهو معيار مفتوح للتجارة الوكيلة طُوِّر بالاشتراك مع Shopify وEtsy وWayfair وTarget وWalmart، وأيّده أكثر من عشرين آخرين منهم Best Buy وThe Home Depot وMacy’s وAdyen وStripe وVisa وMastercard وFlipkart وZalando. وUCP متوافق صراحةً مع MCP وA2A وAP2، فالبيانات المنظمة وعمل البروتوكولات الذي غطّيناه سابقاً في هذه المقالة قابل لإعادة الاستخدام لا للرمي. ويُغطّي Agentic Commerce Protocol (ACP) من Stripe وOpenAI المشكلة نفسها من زاوية المدفوعات، ويبقى x402 خياراً للمدفوعات الصغيرة. وإذا كنتم تبيعون عبر الإنترنت، فالتجارة الوكيلة هي محطة التطبيق التالية بعد حزمة الاكتشاف، لا بنداً يُكتفى بمراقبته وانتظاره.

تُستكشف حالياً مصادقة الروبوتات الموثوقة، حيث يستطيع وكلاء الذكاء الاصطناعي إثبات هويتهم والحصول على مستويات وصول مختلفة. وقد يتيح ذلك منح الوكلاء الموثوقين وصولاً إلى بيانات أغنى مع تقييد الروبوتات غير المعروفة.

وكلاء بهوية العلامة في البحث: Google Business Agent

في يناير 2026، أطلقت Google Business Agent، وهو مساعد مبيعات افتراضي قابل للتخصيص تُفعّله العلامات من Merchant Center ويظهر مباشرةً داخل بحث Google. بحسب إعلان Google، انطلق مع الإطلاق الأول متاجر تجزئة أمريكية مؤهلة منها Lowe’s وMichael’s وPoshmark وReebok، مع وضع التدريب الخاص بكل متجر على بياناته، والعروض على المنتجات ذات الصلة، والدفع الوكيل ضمن القدرات اللاحقة. وميزات التدريب وعروض المنتجات ذات الصلة والدفع مرتبطة بجدول طرح Google، فتحققوا من Merchant Center لمعرفة المتاح حالياً لحسابكم قبل الالتزام بتواريخ محددة مع أصحاب المصلحة.

بالتوازي مع Business Agent، قدّمت Google عشرات السمات الجديدة لبيانات Merchant Center المصممة لأسطح AI Mode وGemini وBusiness Agent. وتتجاوز هذه السمات الكلمات المفتاحية لتشمل إجابات الأسئلة الشائعة عن المنتجات، والملحقات المتوافقة، والبدائل.

بالنسبة إلى العلامات متعددة الفروع، فالدلالة واضحة. فالبيانات المنظمة ومخطط الأسئلة الشائعة وتغذيات الفروع الحيّة التي تنشرونها لحزمة الجاهزية للوكلاء هي نفسها التي تُغذّي السطح الحواري الذي يبدأ منه المتسوقون رحلتهم بشكل متزايد. وإذا نشر منافسٌ سمات الأسئلة الشائعة في Merchant Center ولم تفعلوا أنتم، فإن Business Agent الذي يُجيب على سؤال متسوّق أكثر ميلاً إلى إظهار علامته بدلاً من علامتكم.

كيف تطبّقون الجاهزية للوكلاء عبر مئات الفروع؟

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

وهنا تصبح منصات إدارة الفروع ضرورية. تُدير PLACES AI من PinMeTo البياناتِ المنظمةَ عبر أكثر من 100 شبكة قوائم، وتربط بيانات الفروع الحيّة بمساعدي الذكاء الاصطناعي من خلال PinMeTo Location MCP، ممّا يمنح الوكلاء تغذية مباشرة وفي الوقت الفعلي لمعلومات نشاطكم بدلاً من HTML قديم.

ولمزيد من التعمق في كيفية إعادة تشكيل البحث بالذكاء الاصطناعي للاكتشاف المحلي، اقرؤوا دليلنا الشامل حول GEO للعلامات متعددة الفروع ومدخلَي المسرد حول AI Overviews وتحسين محركات التوليد.

التحديثات

هذا موضوع يتطور بسرعة، لذلك نعود إلى هذه التدوينة كلما استقرّت المعايير. أحدث التغييرات:

• 2026-05-27: أُضيفت ملاحظة عن فئة Lighthouse الجديدة “Agentic Browsing” (WebMCP، llms.txt، إمكانية الوصول للوكلاء، استقرار التخطيط). لا تزال درجة الفئة غير مرجّحة على مقياس من 0 إلى 100 ما دامت المعايير في طور النضج، فالفحوصات استرشادية اليوم. أُضيفت في قسم llms.txt وفي قائمة أدوات الاختبار.
• 2026-05-26: أصبح مدقق Google PageSpeed Insights يتعرف على توجيه Content-Signal، فلم تعد إضافة Content Signals إلى robots.txt تُظهر تحذير “robots.txt غير صالح”. جرى تحديث قسم الوصول إلى المحتوى وقائمة أولويات التطبيق.
• 2026-05-22: أُضيف سياق حول Google Business Agent ومدخل في الأسئلة الشائعة عن Universal Commerce Protocol (UCP) بعد إعلانات Google في يناير 2026.

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

كيف أختبر ما إذا كان موقعي جاهزاً للوكلاء الذكيين؟

زوروا isitagentready.com، وهو الماسح الرسمي لجاهزية الوكلاء من Cloudflare، وأدخلوا رابط موقعكم. يفحص الماسح جميع المعايير الحالية ويمنحكم تقريراً بالنتائج مع توصيات قابلة للتنفيذ. وللحصول على رأي ثانٍ يغطي بُعداً إضافياً للإشارات التحريرية، يستحق Agent Readiness Score من GEO Metrics أيضاً تشغيله بجانبه فهو مجاني.

هل سيؤدي تطبيق معايير الجاهزية للوكلاء إلى تعطيل تحسين محركات البحث لديّ؟

لا. تُبنى الجاهزية للوكلاء فوق أفضل ممارسات تحسين محركات البحث القائمة. فـrobots.txt والبيانات المنظمة وخرائط الموقع هي بالفعل جزء من تحسين محركات البحث. أما المعايير الجديدة (Content Signals وMCP Server Cards وWebMCP) فهي إضافية، ولا تغيّر طريقة تفاعل محركات البحث مع موقعكم.

هل أحتاج إلى مطوّر لتطبيق هذا؟

يمكن لأي شخص يجيد تحرير الملفات النصية وملفات الإعداد تطبيق الأساسيات (قواعد robots.txt، والبيانات المنظمة بـJSON-LD، وتوجيهات Content Signals). أما مفاوضة المحتوى عبر Markdown فهي خيار يُفعَّل بضغطة واحدة إذا كان موقعكم خلف Cloudflare Pro أو أعلى، وإلا فإنها تحتاج إلى مطوّر لتوصيل توليد ملف .md شقيق في مرحلة البناء أو إعادة كتابة من نقطة الأصل. وتتطلب WebMCP وMCP Server Cards بعض المعرفة بـJavaScript وJSON. وفي التطبيقات المؤسسية التي تمتد على مئات الفروع، ينبغي أن يتولى ذلك فريق التطوير لديكم أو شريك المنصة.

ما هو Google Business Agent وهل أحتاج إلى فعل شيء جديد من أجله؟

Business Agent هو مساعد مبيعات افتراضي قابل للتخصيص أطلقته Google في يناير 2026. تُفعّله العلامات التجارية من Merchant Center، ويظهر داخل بحث Google ليجيب على أسئلة المتسوقين نيابةً عن العلامة. وكان بين أوائل من شارك في الإطلاق متاجر تجزئة أمريكية مؤهلة منها Lowe’s وMichael’s وPoshmark وReebok. وبالنسبة إلى العلامات متعددة الفروع، تتمثّل الخطوة العملية في تعبئة سمات البيانات الجديدة في Merchant Center التي طرحتها Google بالتوازي معه (إجابات الأسئلة الشائعة عن المنتجات، والملحقات المتوافقة، والبدائل)، لأن هذه السمات تغذّي Business Agent وAI Mode وGemini. وعمل الجاهزية للوكلاء الذي يغطّيه بقية هذا الدليل (البيانات المنظمة، ومخطط الأسئلة الشائعة، وتغذيات الفروع الحيّة) هو مجموعة المدخلات نفسها، لذا فإن معظم الجهد ينتقل إليه مباشرة.

ماذا يحدث إذا تغيرت هذه المعايير؟

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

هل الجاهزية للوكلاء مقتصرة على المواقع الإلكترونية، أم تنطبق على التطبيقات والمنصات الأخرى أيضاً؟

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

كيف يتلاءم Universal Commerce Protocol (UCP) من Google مع الجاهزية للوكلاء؟

UCP هو طبقة المعاملات فوق طبقة الاكتشاف التي يركّز عليها هذا الدليل. وهو معيار مفتوح أطلقته Google في يناير 2026، ومن بين شركائه المؤسسين Shopify وEtsy وWayfair وTarget وWalmart، وهو متوافق مع MCP وA2A وAP2. وإذا كنتم تنشرون بالفعل بيانات منظمة للمنتجات والفروع، وتعرضون أدوات عبر MCP، وتتبعون حزمة الجاهزية للوكلاء، فأنتم في وضع جيد للاندماج مع UCP. وأعلنت Google عند الإطلاق أن UCP سيشغّل عمليات الدفع لقوائم المنتجات المؤهلة في AI Mode وGemini لمتاجر التجزئة الأمريكية، مع توسّع دولي لاحقاً. تحققوا من حالة الطرح الحالية لدى Google قبل افتراض التوفر في سوقكم.

هل تبحثون عن طرق لجعل فروعكم مرئية لوكلاء الذكاء الاصطناعي؟ احجزوا عرضاً تجريبياً لترَوا كيف تساعد PLACES AI العلاماتِ متعددة الفروع على البقاء قابلة للاكتشاف عبر البحث التقليدي والاكتشاف المدعوم بالذكاء الاصطناعي.

المصادر والمراجع

• Content Signals for Automated Processing - مسودة إنترنت من IETF من إعداد Michael Tremante وLeah Romm حول توجيهات أذونات محتوى الذكاء الاصطناعي
• SEP-2127: MCP Server Cards - مقترح Model Context Protocol للإعلان عن خوادم MCP عبر روابط well-known
• WebMCP Specification - مواصفة مجموعة مجتمع تعلم الآلة للويب التابعة لـW3C لأدوات وكلاء الذكاء الاصطناعي في المتصفح
• WebMCP: An API for the Agentic Web - نظرة عامة من Chrome for Developers حول WebMCP ودورها في مسارات عمل الوكلاء
• Agent Skills Discovery RFC - المعيار الذي اقترحته Cloudflare لنشر قدرات المواقع لوكلاء الذكاء الاصطناعي
• Introducing the Model Context Protocol - إعلان Anthropic عن MCP معياراً مفتوحاً لتكامل أدوات الذكاء الاصطناعي
• Introducing Markdown for Agents - الإعلان الرئيسي من Cloudflare، بما في ذلك معيار 16,180 مقابل 3,150 رمزاً والمقارنة بتكلفة كل عنصر
• Markdown for Agents (Cloudflare Fundamentals docs) - التوثيق الرسمي، بما في ذلك ترويسة الاستجابة x-markdown-tokens
• HTML vs Markdown for AI Agents (Beam.ai) - مقارنة تُظهر HTML النظيف بتكلفة 2-3 أضعاف وHTML الواقعي بتكلفة 8-10 أضعاف Markdown المكافئ
• Cloudflare Markdown for Agents: Complete Technical Guide (ALM Corp) - دليل تقني ثانوي يستعرض معيار خفض الرموز بنسبة 80% وآثاره على تحسين محركات البحث
• Making agent-friendly pages with content negotiation (Vercel) - منشور Vercel الرئيسي حول تقديم Markdown عبر ترويسات Accept، بما في ذلك تقليص الحمولة من 500 كيلوبايت إلى 3 كيلوبايت على موقعها
• Make your documentation readable by AI agents (Vercel) - دليل قاعدة معرفة Vercel لمفاوضة المحتوى لمواقع الوثائق
• Allow pages to be served in markdown for AI Agents (Next.js Discussion #90579) - نقاش مجتمعي حول تطبيق مفاوضة المحتوى عبر Markdown في Next.js
• How to serve content to agents: a field guide (Sanity) - دليل Sanity لتقديم المحتوى مباشرةً لوكلاء الذكاء الاصطناعي
• Content Negotiation for AI Agents: Why Sentry Serves Markdown Over HTML - دراسة حالة عن تطبيق Sentry لمفاوضة المحتوى عبر Markdown
• How to Make Your Documentation AI-Friendly (DeployHQ) - دليل تطبيق يغطي مفاوضة المحتوى عبر Laravel وExpress وDjango والمواقع الساكنة
• Serve Your WordPress Posts as Markdown (Roots) - شرح Roots لتقديم Markdown من WordPress عبر ترويسة Accept
• post-content-to-markdown WordPress plugin (Roots, GitHub) - إضافة مفتوحة المصدر لـWordPress تُقدّم محتوى المنشورات بصيغة Markdown عبر ترويسات Accept وروابط .md
• Implementing Markdown for Agents Without Cloudflare (Pragmate) - دليل تطبيق مخصّص عمداً لمسار خارج Cloudflare
• AI Statistics and Trends - بيانات الاستخدام حول نمو روبوتات الدردشة الذكية واعتمادها (2024-2025)، تم الاحتفاظ بها كسياق تاريخي
• Generative AI Statistics for 2026 (Similarweb) - أرقام محدّثة للزيارات الشهرية والمستخدمين النشطين أسبوعياً لـ ChatGPT وغيره من روبوتات الدردشة الرائدة
• AI Search Market Share 2026: ChatGPT, Gemini & Perplexity Stats (Stackmatix) - نمو Gemini بنسبة 647 بالمئة سنوياً وإعادة توزيع حصص السوق حتى مارس 2026
• New Data Study: What Queries Is ChatGPT Using Behind The Scenes? (Nectiv) - دراسة Nectiv الصادرة في أكتوبر 2025 بتحليل أكثر من 8500 مطالبة في ChatGPT، وهي المصدر الأصلي لنسبة 59 بالمئة التي تُطلق فيها المطالبات ذات النية المحلية بحثاً مباشراً على الويب داخل ChatGPT
• Is Your Site Agent Ready? - ماسح Cloudflare الرسمي لجاهزية الوكلاء لاختبار موقعكم مقارنةً بالمعايير الحالية
• Introducing the Agent Readiness Score (Cloudflare) - إعلان Cloudflare عن ماسح isitagentready.com (أبريل 2026)، بما في ذلك نموذج التقييم رباعي الأبعاد
• Agent Readiness Score (GEO Metrics) - ماسح مستقل مجاني يضيف إشارات تحريرية وإشارات اقتباس بالذكاء الاصطناعي فوق الحزمة التقنية رباعية الطبقات نفسها
• Model Context Protocol - وثائق MCP الرسمية ومواصفتها
• robots.txt RFC 9309 - معيار IETF لبروتوكول استبعاد الروبوتات
• New tech and tools for retailers to succeed in an agentic shopping era - مدوّنة Google Ads & Commerce، 11 يناير 2026، حول UCP وBusiness Agent وسمات Merchant Center الجديدة وعروض Direct Offers
• Universal Commerce Protocol - مواصفة UCP الرسمية ودليل الشركاء
• Business Agent in Merchant Center - توثيق Google Merchant Center لتفعيل Business Agent وتهيئته
• Agent Payments Protocol (AP2) - بروتوكول Google Cloud المفتوح للمدفوعات التي يقودها الوكلاء، يُشير إليه UCP
• Agent2Agent Protocol (A2A) - بروتوكول مفتوح للتشغيل البيني بين وكلاء الذكاء الاصطناعي، يُشير إليه UCP
• Agentic checkout for the holiday shopping season - إعلان Google السابق عن التسوق الوكيل الذي يُبنى عليه UCP
• acceptmarkdown.com Status - متعقّب يديره المجتمع لعملاء الذكاء الاصطناعي الذين يرسلون Accept: text/markdown
• AI features and your website (Google Search Central) - دليل تحسين الذكاء الاصطناعي الرسمي من Google، بما في ذلك قسم تفنيد الأساطير الذي يقول صراحةً إنكم لا تحتاجون إلى llms.txt أو ملفات نصية للذكاء الاصطناعي أو Markdown للظهور في أسطح البحث التوليدي لديها
• Google’s Mueller Calls Markdown-For-Bots Idea ‘A Stupid Idea’ - تغطية Search Engine Journal لاعتراض John Mueller العلني على صفحات Markdown الخاصة بالروبوتات
• Google & Bing don’t recommend separate markdown pages for LLMs - Search Engine Land حول النقاش الأوسع في القطاع، بما في ذلك مخاوف استشعار وكيل المستخدم والإخفاء
• HTTP Content Negotiation (RFC 7231) - الأساس المعياري لمفاوضة ترويسة Accept بين العميل والخادم
• text/markdown media type (RFC 7763) - تسجيل IETF لنوع الوسائط text/markdown المستخدم في مفاوضة المحتوى