بينما يقوم البعض بحظر الروبوتات، يقوم الآخرون بتعليمها كيفية تقديم جواز السفر. في عام 2026، اجتمعت Cloudflare وGoogle وAmazon وAkamai وOpenAI حول معيار واحد - Web Bot Auth. الفكرة بسيطة وجذرية: لم يعد يتم التحقق من حركة المرور الآلية بناءً على عنوان IP وسلسلة User-Agent، التي يمكن تزويرها بسهولة. بدلاً من ذلك، يقوم الوكيل بتوقيع كل طلب بشكل تشفيري، ويتحقق الموقع على الفور من التوقيع. في 2 مارس 2026، تم إصدار النسخة الخامسة من مسودة المعمارية (draft-meunier-web-bot-auth-architecture-05)، وفي مايو بدأت Google اختبارها في بيئة حقيقية، وهدفت مجموعة العمل IETF إلى إصدار المعيار بحلول أغسطس 2026. دعونا نفهم ما هو هذا الآلية، ومن يقف وراءها، ولماذا يعتبر هذا تحولًا بنسبة 180 درجة لكل من يعمل في مجال جمع البيانات وإدارة الحسابات المتعددة.
ما الذي حدث: ظهور هوية تشفيرية للروبوتات
كانت عملية التحقق الكلاسيكية "صديق أو عدو" على الويب تعتمد على عكازين. الأول - User-Agent: سلسلة يقوم العميل بالإبلاغ عنها بنفسه، والتي يقوم أي سكربت بإعادة كتابتها في سطر واحد من الشيفرة. الثاني - قوائم عناوين IP: يحتفظ الموقع بقائمة من "نطاقات" Googlebot وBingbot وغيرها ويتحقق من DNS العكسي. كلا النهجين انهارا تمامًا في عام 2026.
تحدد Cloudflare المشكلة بشكل مباشر في وثائقها الفنية: يمكن استخدام نفس عنوان IP من قبل العديد من المستخدمين أو الخدمات في نفس الوقت، كما أن النطاقات نفسها تتغير باستمرار مع البنية التحتية. أما User-Agent فهو ليس دليلاً على الإطلاق - إنه مجرد تمثيل ذاتي. التوقيع التشفيري، وفقًا لمؤلفيه، يوفر المصادقة دون الاعتماد على "نطاقات IP المتغيرة باستمرار" أو "رؤوس يمكن تزويرها مثل User-Agent".
تقنيًا، يعتمد Web Bot Auth على معيار HTTP Message Signatures (RFC 9421) الذي تم قبوله بالفعل. يتم منح كل وكيل زوجًا من المفاتيح Ed25519. قبل إرسال الطلب، يقوم الوكيل بتوقيع ليس كل شيء، بل authority URI المستهدف - أي النطاق الذي يتم الوصول إليه (عند زيارة example.com، يتم توقيع example.com فقط). يتم إضافة رؤوس Signature-Input (نافذة صلاحية مع علامات created وexpires، معرف المفتاح keyid بتنسيق JWK Thumbprint، ووسم web-bot-auth) وSignature-Agent، الذي يشير إلى الدليل الذي يحتوي على المفاتيح العامة (JWKS). يقوم الموقع بتنزيل المفتاح العام من هذا الدليل والتحقق من التوقيع. من المستحيل تزويره بدون المفتاح الخاص، وتوفر نافذة الصلاحية حماية من إعادة تشغيل الطلبات التي تم اعتراضها.
من يقف وراء المعيار
هذه ليست تجربة لشركة واحدة. يدعم Web Bot Auth كل من Cloudflare وAmazon وAkamai وOpenAI. يتم كتابة مسودة المعمارية بالتعاون بين تيبو مونييه (Cloudflare) وشاندور مايور (Google). لقد أضاف AWS WAF بالفعل دعمًا للتحقق من التوقيعات، ودمجت Cloudflare ذلك في برنامجها Verified Bots ونشطته على حافتها في الإنتاج. تم إنشاء مجموعة عمل منفصلة من IETF لـ Web Bot Auth في عام 2026 وتهدف إلى تقديم المواصفة للتوحيد بحلول أغسطس 2026.
تدخل Google - وهذه لحظة حاسمة
في 6 مايو 2026، تم الإعلان عن أن Google تختبر Web Bot Auth للتحقق من حركة مرور الروبوتات الخاصة بها. الهدف هو أن يتمكن الموقع من التأكد من أن الطلب الذي يبدو أنه صادر من Google هو بالفعل من Google، وليس من شخص ما قام ببساطة بكتابة Googlebot في User-Agent. يتم تمرير حركة مرور AI الموقعة من Google تحت هوية agent.bot.goog - يقوم مالكو المواقع بتنزيل المفاتيح العامة من Google من هذه النقطة والتحقق من رؤوس Signature وSignature-Input.
لماذا هذا مهم الآن. بالضبط بسبب ما كتبناه عن حظر متصفحات الوكلاء: اعتبارًا من 15 سبتمبر 2026، ستقوم Cloudflare افتراضيًا بحظر "الزاحفين" AI المختلطين على الصفحات الإعلانية للنطاقات الجديدة، وتمر حوالي خُمس الويب عبر شبكة Cloudflare. يتم إغلاق الويب. وWeb Bot Auth ليس عن "كيفية الحظر"، بل عن "من يُسمح له بالدخول". يظهر قائمة بيضاء من نوع جديد: ليست بناءً على IP، بل على الهوية التشفيرية. سيتمكن الموقع من تفعيل سياسة مثل "عرض الأسعار وتفاصيل المنتج فقط للوكالات الموقعة الموثوقة" - وكل شيء آخر سيبقى تلقائيًا في الخارج.
العملاء الموقعة: المجموعة الأولى
فئة منفصلة - signed agents (العملاء الموقعة). هؤلاء هم الروبوتات التي يديرها المستخدم النهائي، وليس شركة واحدة: المنصة أو المتصفح البعيد الذي يعمل عليه الوكيل، يقوم بتوقيع طلباته HTTP، وCloudflare يتحقق من التوقيعات. تشمل المجموعة الأولى ChatGPT agent (OpenAI)، Goose (Block)، Browserbase، Anchor Browser وCloudflare Browser Rendering. وصف داوي أوسينغا من Block الفائدة مباشرة: "Web Bot Auth يسمح للمواقع بالثقة في Goose، مع الحفاظ على ما يجعله فريدًا".
الاختلاف الرئيسي: العميل الموقّع يعمل باسم شخص (مساعد افتراضي يدخل الموقع بناءً على طلبك)، بينما "الزاحف" أو "الزاحف التدريبي" يعمل لصالح الشركة. تقوم Cloudflare بالفعل بفصل هذه الكيانات في قواعد الأمان - وهذه النقطة ستحدد من سيفتح له الأبواب في الويب بين 2026-2027، ومن لا.
ماذا يعني هذا لجمع البيانات والبروكسي
في البداية، يبدو أن التوقيع التشفيري يقضي على جمع البيانات المجهول. لكن في الواقع، الأمور أكثر تعقيدًا - الويب ينقسم إلى مسارين، وهذا يغير التكتيك لجمهورنا، بدلاً من إلغائه.
- مسار العملاء الموقعة. ممر ضيق ومميز للمنصات الكبيرة و"المساعدين" المستخدمين من القائمة البيضاء. للدخول إلى هناك، تحتاج إلى مفتاح خاص، دليل JWKS عام، تسجيل في CDN والامتثال للسياسات. بالنسبة لمشروع جمع البيانات النموذجي، أو مزارع مكافحة الكشف، أو أتمتة SMM، فإن هذا الطريق مغلق: أنت لست Google ولا OpenAI، لن تحصل على توقيع.
- مسار جميع الآخرين. هنا لا يزال يعيش جامعو البيانات المستقلون، ومراقبو الأسعار، وجمع البيانات، وإدارة الحسابات المتعددة. وهنا تزداد أهمية جودة البروكسي وموثوقية البصمة بشكل كبير. نظرًا لأن "الشرعيين" يُسمح لهم بالتوقيع، فإن التعامل مع كل حركة المرور غير الموقعة يصبح أكثر صرامة بشكل افتراضي.
بعبارة أخرى، Web Bot Auth لا يقضي على الحاجة إلى البروكسي - بل يرفع المعايير لأولئك الذين ليسوا في القائمة البيضاء. إذا كان من الممكن سابقًا الأمل في التسلل عبر User-Agent الرمادي، فإن الطلب غير الموقع الآن يقع مباشرة في فئة "أثبت أنك إنسان حي". ويتم إثبات ذلك من خلال مجموعة من IP النقي وسلوك موثوق.
لماذا تصبح عناوين IP السكنية والمحمولة أكثر قيمة
عندما يكون التوقيع غير متاح، فإن الطريقة الوحيدة للظهور بشكل شرعي هي أن تكون غير مميز عن المستخدم العادي. عناوين مراكز البيانات لا تحل هذه المشكلة: وفقًا لمختلف قياسات الحماية، تمر Cloudflare عناوين IP لمراكز البيانات فقط في 40-60% من الحالات، بينما توفر البروكسي السكنية نسبة مرور تتراوح بين 85-99%. السبب هو أن العنوان السكني ينتمي إلى مزود خدمة الإنترنت الحقيقي وعميل حي - من حيث سمعة IP، لا يمكن تمييزه عن شخص خلف نفس الموجه.
الوضع أكثر صعوبة مع أكثر المنصات حماية والتطبيقات المحمولة، حيث تلعب الشبكات الخلوية دورًا. هنا تأتي البروكسي المحمولة لإنقاذ الموقف: خلف نفس IP الخاص بالمشغل، يجلس الآلاف من العملاء الحيين، لذا فإن حظر هذا العنوان بشكل جماعي يعني قطع العملاء الحقيقيين. هذا التأثير لـ "الوعاء المشترك" يجعل عناوين IP المحمولة العملة الأكثر استقرارًا في عالم حيث يتم كشف كل شيء آخر.
لكن IP النقي لم يعد كافيًا. مع انتقال التحقق من الهوية من الشبكة إلى التشفير، تمر كل جيش الروبوتات غير الموقعة عبر البصمة السلوكية وبصمة المتصفح: TLS/JA4، canvas، WebGL، الخطوط، التوقيتات. البروكسي يزيل إشارة إنذار واحدة (سمعة العنوان)، لكنه لا يلغي البقية. المجموعة العملية لعام 2026 - IP سكني أو محمول بالإضافة إلى بيئة مكافحة الكشف مع بصمة متوافقة. مكون واحد بدون الآخر يكشف الروبوت عند أول مستوى حماية.
كيف تتصرف بالفعل الآن
- قم بتقسيم المشاريع حسب المسارات. إذا كانت المهمة هي تكامل رسمي باسم منتج كبير، فقم بدراسة طريق العميل الموقّع: التسجيل في CDN والحصول على المفاتيح. بالنسبة لكل شيء آخر، خطط للعمل في "مسار جميع الآخرين" وضع قواعده.
- استثمر في جودة IP، وليس في الكمية. أصبحت مجموعات مراكز البيانات الرخيصة في عام 2026 عامل توقف متزايد. ركز على العناوين السكنية والمحمولة مع التدوير وفقًا للمهمة.
- تزامن البصمة مع الشبكة. IP من دولة واحدة، بينما لغة المتصفح، المنطقة الزمنية، واللغة - من دولة أخرى - هذا فشل كلاسيكي. يجب أن تتطابق البصمة بشكل متسق مع الموقع الجغرافي للبروكسي.
- تابع المعيار. بحلول أغسطس 2026، تخطط IETF لإنهاء المواصفة. بمجرد أن يصبح Web Bot Auth شرطًا إلزاميًا للوصول إلى منصة معينة، سيتعين إعادة النظر في التكتيك لها مسبقًا، وليس بعد فوات الأوان.
الاستنتاج
Web Bot Auth ليس مجرد أداة مضادة للروبوتات، بل هو تغيير في منطق الثقة في الويب: من "من أنت حسب IP" إلى "أثبت بالتشفير من أنت". بالنسبة للعمالقة مثل Google وOpenAI، فإنها تذكرة إلى الإنترنت الذي يغلق. بالنسبة لجمع البيانات المستقل ومشاريع الحسابات المتعددة، فإنها إشارة إلى أن الأساليب الرمادية لم تعد تعمل، وأن الفجوة بين "الظهور كإنسان" و"الظهور كروبوت" تصبح حاسمة. سيفوز في الواقع الجديد ليس من لديه المزيد من IP، بل من لديه عنوان سكني أو محمول نقي وبصمة متوافقة تمامًا. لم يتم إصدار جواز السفر التشفيري للجميع - لذا سيتعين على الجميع الآخرين أن يكونوا أكثر إقناعًا.
```