الروبوتات 57% من حركة الويب: هندسة المواقع للوكلاء

طوال تاريخ الويب، كان الطرف الآخر من أي طلب إنساناً. هذا الافتراض صار اليوم خاطئاً أكثر مما هو صحيح.

قياسات Cloudflare لعام 2026 تضع الطلبات الآلية عند نحو 57.5% من حركة الويب بصيغة HTML، مقابل 42.5% من البشر — وهو أول تقاطع تسجّله الشركة على الإطلاق. وقد أشار رئيسها التنفيذي ماثيو برنس إلى أن هذه العتبة بلغت قبل نحو ثمانية عشر شهراً من توقعاتهم الخاصة. والمحرّك هنا ليس القصة القديمة عن أدوات الكشط والروبوتات المزعجة، بل الذكاء الاصطناعي الوكيل: برامج ذاتية التشغيل تتصفح نيابة عن المساعدين، حيث قد يتفرّع سؤال واحد من مستخدم إلى مئات عمليات جلب الصفحات.

معظم الفرق الهندسية لم تُعدّل بنيتها بعد. تحليلاتها ما زالت تفترض مساراً بشرياً، وحدود المعدّل لديها ما زالت تفترض إيقاعاً بشرياً، وسياستها تجاه الروبوتات ما زالت ثنائية — سماح أو حظر — مبنية على سلاسل user-agent يستطيع أي أحد تزويرها. هذا المقال يتناول ما يتغيّر فعلياً على مستوى البنية التحتية.

ليست كل الحركة سواء

الخطأ الأول هو معاملة "حركة الروبوتات" كفئة واحدة. تفصيل Cloudflare لشهر مايو 2026 لطلبات زواحف الذكاء الاصطناعي مفيد هنا:

• 51.8% لأغراض تدريب النماذج — جمع ضخم للنصوص، قيمة ضئيلة لك وتكلفة نطاق ترددي مرتفعة
• 9.3% لفهرسة البحث — العلاقة التقليدية القائمة على الزحف والترتيب
• والباقي نشاط وكيل يُطلقه مستخدم — شخص ما سأل مساعداً سؤالاً، والمساعد يجلب صفحتك الآن ليجيب

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

إن كانت سياستك تجاه الروبوتات عاجزة عن التمييز بين هذه الحالات الثلاث، فهي ليست سياسة بل قرعة.

الهوية: لماذا انتهى عصر سلاسل user-agent

الطريقة التاريخية للتعرّف على الزاحف كانت ترويسة user-agent مع فحص DNS عكسي مقابل نطاقات عناوين IP منشورة. كلا الآليتين تنهار اليوم. فسلاسل user-agent تُزوَّر بلا عناء — ولا يكلّف شيئاً أن يزعم كاشط أنه GPTBot. وقوائم عناوين IP المسموح بها لا تصمد في عصر تعمل فيه الوكلاء من وكلاء سكنية ودوال طرفية وأجهزة المستخدمين.

البديل تشفيري، وهو يتحوّل إلى معيار بسرعة.

Web Bot Auth هو مقترح لدى IETF بقيادة Cloudflare يبني على RFC 9421 (توقيعات رسائل HTTP)، وهو معيار مقترح مُصادق عليه منذ فبراير 2024. الفكرة بسيطة: مشغّل الوكيل يولّد زوج مفاتيح Ed25519، وينشر المفتاح العام في دليل قابل للاكتشاف، ويوقّع كل طلب صادر بالمفتاح الخاص. ثم يتحقق خادمك من التوقيع. وبذلك يصبح الانتحال مستحيلاً تشفيرياً بدل أن يكون مجرّد أمر غير مُستحسن.

الطلب الموقّع يحمل ثلاث ترويسات:

Signature-Input: sig=("@authority" "signature-agent");
                 created=1700000000;
                 expires=1700011111;
                 keyid="ba3e64==";
                 tag="web-bot-auth"
Signature: sig=abc==
Signature-Agent: signer.example.com

ترويسة Signature-Agent تدلّك على موضع جلب المفاتيح العامة. وSignature-Input تُعلن المكوّنات الموقَّعة — هنا سلطة العنوان المستهدف وترويسة Signature-Agent نفسها — إضافة إلى نافذة صلاحية وبصمة المفتاح (RFC 7638). أما Signature فتحمل القيمة.

الدعم الصناعي جاد: Cloudflare وAmazon وAkamai وOpenAI، مع مجموعة عمل في IETF تأسست عام 2026. وكبار المشغّلين ينشرون أدلّتهم في مسارات مثل https://anthropic.com/.well-known/http-message-signatures-directory.

وقد فتحت Cloudflare مصدر حزمة التحقق في مستودع cloudflare/web-bot-auth، وهي تشمل:

• web-bot-auth — حزمة npm وحزمة Rust تُنفّذان مسودة البروتوكول
• http-message-sig — التوقيع والتحقق وفق RFC 9421
• jsonwebkey-thumbprint — بصمات المفاتيح وفق RFC 7638
• تطبيقات مرجعية على هيئة Cloudflare Worker وإضافة لخادم Caddy

كما تتوفر نقطة اختبار حيّة على http-message-signatures-example.research.cloudflare.com للتحقق من تنفيذك مقابل مفتاح اختبار Ed25519 الخاص بـ RFC 9421 قبل الإطلاق.

بالنسبة لمعظم الفرق، الخطوة العملية ليست كتابة مُتحقّق من الصفر، بل تفعيل التحقق من التوقيع على طبقتك الطرفية القائمة — إذ أدرجت Cloudflare توقيعات الرسائل ضمن برنامج Verified Bots — ثم اتخاذ قرار مدروس لكل مشغّل مُتحقَّق منه.

كيف تبدو سياسة وكلاء حقيقية

بمجرد تمييز الوكلاء الموقَّعين عن الحركة المجهولة، يصبح التدرّج ممكناً:

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

تقديم صفحات يستطيع الوكيل استخدامها فعلاً

التحقق يحسم مسألة "من". النصف الآخر هو ما إذا كانت الاستجابة قابلة للاستخدام.

تتعامل الوكلاء مع الصفحات بطريقة تشبه إلى حد بعيد قارئ الشاشة — عبر DOM لا عبر البكسل. ولهذا آثار ملموسة:

اعرض المحتوى من الخادم. الوكيل الذي يتلقى هيكلاً فارغاً وحزمة JavaScript قد ينفّذها وقد لا ينفّذها. كثيرون لن يفعلوا، ومن يفعل يستهلك ميزانيته في ذلك. إن كان محتواك لا يوجد إلا بعد الترطيب (hydration)، فاعتبره غير مرئي.

استخدم دلالات النماذج الأصلية. عنصر form حقيقي بحقول موسومة وزر إرسال قابل للتنقّل. أما div مع معالج نقر فلا. وهذا هو الانضباط نفسه الذي يجتاز تدقيق إمكانية الوصول في Lighthouse — الهدفان يتقاربان تقاريباً شبه تام.

انشر بيانات منظّمة. يمنح ترميز JSON-LD وschema.org الوكيلَ حقائق قاطعة بدل استنتاجات مستمدة من التخطيط البصري. ولكل ما يحمل سعراً أو توفراً أو عنواناً أو تاريخاً، هذا هو الفارق بين أن تُقتبس بدقة وأن تُقتبس خطأً.

فكّر في مفاوضة المحتوى. تقديم Markdown بدل HTML للزواحف المعروفة يقلّص حجم الاستجابة بشكل ملموس، ما يخفّض فاتورة الصادر ويرفع احتمال تحليلك بشكل صحيح. وحالما تستطيع التعرّف تشفيرياً على مُرسل الطلب، يصبح هذا الخيار آمناً.

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

يتقاطع جزء من هذا مع دليلنا حول تحسين الظهور في بحث الذكاء الاصطناعي وAEO — لكن ذلك المقال يعالج مسألة أن يُعثر عليك، وهذا المقال يعالج أن تُخدَم بشكل صحيح بعد وصول الوكيل.

أبعد من القراءة: تمكين الوكلاء من إتمام المعاملات

قراءة الصفحة هي الجزء السطحي. التحوّل الأعمق هو الوكلاء الذين يحتاجون إلى فعل شيء: الحجز، الشراء، الإرسال، الاستعلام.

ثلاثة مسارات تتقارب اليوم:

1. اعرض واجهات برمجية للمعاملات بدل إجبار الوكيل على محاكاة الواجهة. فالوكيل الذي يقود سلة الشراء بنقرات DOM هش لكليكما.
2. تبنَّ بروتوكول تجارة ناشئاً — Agentic Commerce Protocol لعمليات الشراء عبر ChatGPT، أو Universal Commerce Protocol كمسار محايد.
3. اعرض الدوال مباشرة لوكلاء داخل الصفحة عبر WebMCP، الذي يتيح للموقع الإعلان عن أدوات قابلة للاستدعاء لوكيل مقيم في المتصفح بدل انتظار استنتاجها من الترميز.

المسارات الثلاثة تتطلب نموذج تفويض واضحاً. وقد استقر النمط على OAuth 2.1 ببيانات اعتماد محدودة النطاق مع تحكم بالوصول على مستوى المورد: الوكيل الذي يتصرف نيابة عن مستخدم يحصل على رمز ضيّق وقابل للإبطال وللتدقيق — لا على كعكة جلسة المستخدم. وأي تساهل أكثر من ذلك يعني أنك بنيت مضخّماً لـحقن الأوامر وقاعدة بياناتك خلفه.

قِس قبل أن تقرّر

الخطوة التي يتخطاها الجميع تقريباً: قِس توزيعك أنت أولاً.

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

لا يمكنك اتخاذ قرار سليم بشأن حركة لم تفصلها قط. نسبة 57.5% من Cloudflare متوسط على مستوى الإنترنت، لا رقمك أنت. اعثر على رقمك.

الخلاصة

لم يعد الويب وسيطاً بشرياً خالصاً، وأصبحت الأدوات اللازمة للتعامل مع ذلك بصدق متاحة. معيار RFC 9421 مُصادق عليه، ولـ Web Bot Auth مجموعة عمل في IETF وتطبيقات بلغتي TypeScript وRust. أما البيانات المنظّمة والترميز المتاح — وهي ممارسات يتبعها المهندسون الجيدون أصلاً — فتبيّن أنها تحديداً ما تحتاجه الوكلاء.

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

تبني للويب الوكيل؟ نقطة تساعد الفرق في تونس والسعودية على تصميم بنية جاهزة للوكلاء — من هوية الروبوتات وسياسة الطبقة الطرفية إلى تكامل MCP والمحتوى المنظّم. تواصل معنا.