اجعل موقعك الإلكتروني جاهزًا للوكلاء: الزواحف، llms.txt، البيانات المنظمة، وبروتوكولات التجارة

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

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

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

ما الذي يغيره "العامل الوكيل" فعليًا

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

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

هذا يغير سؤال التحسين. لا تزال حركة المرور مهمة، ولكن أيضًا الدقة القابلة للقراءة آليًا، وسلطة المصدر، والاستعداد للتنفيذ. الصفحة التي تبدو ممتازة ولكنها تخفي سعرها في صورة، أو تتعارض مع بياناتها المنظمة، أو ليس لديها سياسة توصيل واضحة، يصعب على كل من الوكلاء والعملاء الثقة بها.

الخطوة الأولى: تدقيق وصول الزاحف بشكل صحيح

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

توثق OpenAI عناصر تحكم منفصلة لـ OAI-SearchBot و GPTBot. يرتبط OAI-SearchBot بعرض المواقع في بحث ChatGPT، بينما يتحكم GPTBot في الاستخدام المحتمل للمحتوى الذي تم الزحف إليه لتدريب النماذج الأساسية. يمكن للموقع السماح للأول ومنع الثاني. هذه خيارات سياسة مستقلة.

يتطلب عنصر تحكم Google-Extended من Google أيضًا صياغة دقيقة. إنه رمز تحكم في robots.txt، وليس وكيل مستخدم زاحف HTTP منفصل، وتذكر Google أنه لا يؤثر على الإدراج أو الترتيب في بحث Google.

قد تبدو السياسة المقصودة كما يلي:

User-agent: OAI-SearchBot
Allow: /

User-agent: GPTBot
Disallow: /

هذا المثال ليس توصية عامة. تختلف المتطلبات القانونية والترخيص والخصوصية والتجارية. المهم هو اتخاذ القرار عن قصد بدلاً من وراثة قاعدة شاملة قديمة من إضافة أمان.

ما يجب التحقق منه

• تعود الصفحات العامة المهمة برمز 200 دون الحاجة إلى ملفات تعريف الارتباط أو JavaScript.
• يعكس ملف robots.txt سياسات البحث والذكاء الاصطناعي الفعلية للشركة.
• لا تختبر شبكة CDN الزواحف المشروعة باستخدام اختبار CAPTCHA تفاعلي.
• عناوين URL الأساسية قابلة للزحف ولا تعيد التوجيه عبر روابط تتبع غير ضرورية.
• تؤكد سجلات الخادم ما إذا كانت الزواحف ذات الصلة تصل إلى صفحات المنتجات والخدمات والسياسات.

طبقة الوصف: llms.txt بدون ادعاءات سحرية

يقترح llms.txt ملف Markdown في جذر النطاق يمنح نماذج اللغة خريطة منسقة للمحتوى المفيد. يمكنه تحديد المؤسسة، وشرح ما يقدمه الموقع، والإشارة إلى الوثائق الموثوقة والسياسات والمنتجات أو مراجع API.

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

ومع ذلك، فهو ليس اختصارًا مثبتًا لتحسين ترتيب الاستشهادات من الذكاء الاصطناعي. نشر /llms.txt لا يصلح الصفحات غير القابلة للوصول، أو بيانات المنتج الضعيفة، أو الأسعار المتناقضة، أو البيانات المنظمة المفقودة. تعامل معه كوثائق منخفضة التكلفة موجهة للآلات، وليس كبديل لتحسين محركات البحث التقني.

يمكن أن يكون ملف بسيط كالتالي:

# Example Company

> A short, factual description of the business and its market.

## Products
- [Product catalog](https://example.com/products)

## Policies
- [Delivery](https://example.com/delivery)
- [Returns](https://example.com/returns)

## Support
- [Contact](https://example.com/contact)

اكتبه يدويًا أو راجع المخرجات المُنشأة بعناية. يعرف مولد خريطة الموقع عناوين URL الموجودة، لكنه لا يعرف أي الصفحات مهمة تجاريًا أو قانونية أو آمنة للوكيل للاعتماد عليها.

ماذا عن agents.md؟

ملف agents.md مفيد في مستودعات البرمجيات كاتفاقية لإعطاء وكلاء البرمجة تعليمات المشروع. في مواقع التجارة الإلكترونية العامة، ليس معيار اكتشاف معتمدًا عالميًا يمكن مقارنته بـ robots.txt أو Schema.org.

يمكن للشركة نشر وثائق إجراءات موجهة للآلات، لكن لا ينبغي أن تفترض أن الوكلاء الخارجيين سيكتشفون تلقائيًا أو يمتثلون لملف /agents.md الجذري. من الأفضل وصف قدرات الإجراءات من خلال البروتوكول أو واجهة برمجة التطبيقات التي تعرضها فعليًا، مع تحديد المصادقة والأذونات وسلوك الأخطاء هناك. إذا احتفظت بملف agents.md، فتعامل معه كوثائق تكميلية وليس كأساس للتكامل.

طبقة البيانات: البيانات المنظمة يجب أن تطابق الواقع

طبقة الوصف تخبر الآلة أين تبحث. البيانات المنظمة تساعدها في تفسير ما تجده. لصفحات التجارة، يعني ذلك عادةً أنواع Schema.org المناسبة مثل Product وOffer وAggregateRating وBreadcrumbList، باستخدام حقول تطابق فعليًا الصفحة المعروضة وحالة الخلفية.

العبارة المفتاحية هي تطابق الواقع. لا ينبغي أن يتعارض السعر والعملة والتوفر والحالة ومعلومات التوصيل وإجمالي المراجعات عبر HTML المرئي وJSON-LD والخلاصات وعملية الدفع. الوكيل الذي يرى حقائق متضاربة لا يمكنه التوصية أو إجراء المعاملات بشكل موثوق.

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

قائمة تحقق موثوقة لبيانات المنتج

• معرفات منتج ثابتة وعناوين URL أساسية
• السعر الحالي والعملة
• توفر حسب النوع
• صور دقيقة ونص بديل وصفي
• شروط التوصيل والإرجاع والإلغاء
• عدد التقييمات المطابق للتقييمات المرئية
• بيانات متسقة عبر HTML وschema والتغذيات وواجهات API

طبقة الإجراءات: MCP وACP وUCP وAP2

الصفحات المنظمة تساعد الوكيل على فهم العرض. البروتوكولات وواجهات API تسمح له بتنفيذ إجراءات محكومة. هذه التقنيات تتداخل، لكنها ليست قابلة للتبادل.

MCP: أدوات وسياق، وليس نظام تجارة بمفرده

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

ACP: بنية تحتية للتجارة لـ ChatGPT

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

UCP: دورة حياة تجارية أوسع

يحدد بروتوكول التجارة العالمي اللبنات الأساسية للتجارة الوكيلة عبر الاكتشاف، سلة التسوق، الدفع، ربط الهوية، الطلبات، ودعم ما بعد الشراء. صُمم هذا البروتوكول ليعمل مع وسائل النقل المعتمدة والمعايير ذات الصلة، بما في ذلك MCP وAP2.

تصف وثائق التجارة الوكيلة الحالية لـ Shopify التجارب القائمة على UCP وخوادم MCP المتوافقة مع UCP لسير عمل الاكتشاف، سلة التسوق، الدفع، والطلبات. هذه إمكانية منصة، وليست تصريحًا بافتراض أن كل متجر تم تكوينه تلقائيًا، أو مؤهل، أو مكشوف في كل قناة وكيل. لا يزال التجار بحاجة إلى التحقق من إعداداتهم الفعلية وجودة بياناتهم.

AP2: تفويض دفع قابل للتحقق

يركز بروتوكول مدفوعات الوكيل (AP2) على طبقة التفويض: كيف يمكن للمستخدم تقديم نية قابلة للتحقق لدفع بوساطة وكيل. يكمل بروتوكولات التجارة؛ ولا يحل محل عملية الدفع للتاجر، أو ضوابط الاحتيال، أو معالج الدفع، أو نظام الطلبات.

ما هو الواقعي على Shopify وWooCommerce والبنيات المخصصة؟

Shopify

تتحرك Shopify بسرعة في مجال التجارة الوكيلة وتوفر لبنات بناء موثقة لاكتشاف المنتجات وتدفقات المعاملات. يجب على التجار أولاً التأكد من اكتمال بيانات المنتج، المخزون، الأسواق، الشحن، والسياسات داخل Shopify. دعم المنصة قيم فقط عندما يكون الكتالوج الأساسي موثوقًا.

ووكومرس

يمنح ووكومرس مالك الموقع السيطرة على جذر الويب والبنية التحتية لـ REST، مما يجعل نشر llms.txt، وتحسين المخطط، أو بناء تكامل مخصص أمرًا بسيطًا من الناحية التقنية. الجزء الأصعب هو الجانب التشغيلي: تعارض الإضافات، التخزين المؤقت، قواعد الأمان، البيانات المتغيرة، والإضافات التي تعتقد كل منها أنها تمتلك نفس الحقل.

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

المنصات المخصصة

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

أفضل بنية مخصصة لا تسمح للوكيل بالكتابة مباشرة إلى قاعدة البيانات. إنها تعرض إجراءات تجارية ضيقة مثل search_products، check_inventory، create_cart، أو request_quote، وتطبق نفس القواعد المستخدمة من قبل التطبيق الموجه للبشر.

ترتيب تنفيذ معقول

إذا كنا نجهز موقعًا موجودًا للوكلاء، فسنعمل بهذا الترتيب:

1. تدقيق الوصول. تحقق من قواعد الروبوتات، تحديات CDN، عمليات إعادة التوجيه، الصفحات الأساسية، وسجلات الخادم.
2. إصلاح البيانات المصدر. اجعل الأسعار، التوفر، المعرفات، السياسات، وتفاصيل الاتصال متسقة.
3. التحقق من صحة البيانات المنظمة المقدمة. اختبر صفحات المنتجات والخدمات الفعلية، وليس القوالب فقط.
4. إنشاء ملف llms.txt منسق. وجه الوكلاء نحو الصفحات الموثوقة والمهمة تجاريًا.
5. توثيق الإجراءات. حدد ما يمكن للوكيل قراءته أو فعله، بما في ذلك المصادقة وسلوك الفشل.
6. إضافة البروتوكولات فقط لقناة حقيقية. قم ببناء ACP أو UCP أو MCP أو تكاملات الدفع عندما تبرر فرصة التوزيع تكاليف الإنتاج.
7. المراقبة المستمرة. تتبع وصول الزاحف، أخطاء الأدوات، البيانات القديمة، الإجراءات المهجورة، والنتائج المكتملة.

لاحظ ما ليس في المقام الأول: الملف أو البروتوكول العصري. تبدأ جاهزية الوكيل بصفحات وبيانات موثوقة. الإضافات الموجهة للآلات تعزز هذا الأساس؛ لا يمكنها أن تحل محله.

كيفية تدقيق ما إذا كان العمل يؤتي ثماره

لا تقيس النجاح فقط بوجود /llms.txt. تتبع النتائج التي تربط العمل التنفيذي بالظهور والإيرادات:

• طلبات زاحف الذكاء الاصطناعي وجودة الاستجابة في سجلات الخادم
• الإشارات والاستشهادات لأسئلة العملاء التمثيلية
• حركة الإحالة من البحث بالذكاء الاصطناعي ومنتجات المساعد
• أخطاء خلاصة المنتج وفشل التحقق من صحة المخطط
• نجاح أدوات الوكيل، زمن الاستجابة، ومعدلات الهجر
• العملاء المحتملون، سلات التسوق، الطلبات، والإيرادات المدعومة
• التوصيات غير الصحيحة الناتجة عن بيانات قديمة أو غامضة

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

الخلاصة الصادقة

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

ابدأ من هناك. أضف llms.txt كتوثيق منظم، وليس كوعد بترتيب. تعامل مع agents.md كاتفاقية اختيارية، وليس كمعيار ويب عالمي. قم ببناء تكاملات المعاملات فقط عندما توجد قناة مدعومة وحالة استخدام تجارية.

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

إذا كنت تريد أن ترى ما يمكن للوكيل فهمه وتنفيذه على موقعك الإلكتروني اليوم، يمكن لـ DigiForge تدقيق وصول الزاحف، والبيانات المنظمة، والتوثيق الموجه للآلة، وخلاصات المنتجات، وجاهزية المعاملات. ستحصل على خطة تنفيذ ذات أولويات بدلاً من حزمة من الملفات العصرية.

ابدأ تدقيق جاهزية الوكيل