الخلاصة

  • يسجل Pay Per Crawl واقعة قابلة للفوترة عندما يعلن زاحف موثّق استعداده للدفع ويتلقى استجابة ناجحة تحمل crawler-charged. هذا إثبات لوصول مدفوع، لا لإحالة أو تدريب أو منفعة اقتصادية لاحقة.
  • تقول Cloudflare إن عدد مرات الزحف مقياس خشن للقيمة. وتنقل تجارب Pay Per Use نقطة الدفع إلى ما بعد الوصول: تدفع Ceramic.ai عند ظهور محتوى الناشر في نتيجة، بينما يشتري وكيل You.com مادة مميزة بعينها عند الحاجة.
  • يطابق Bot Preference Sync، المعلن في 21 أغسطس، إعدادات Search وAgent وTraining مع robots.txt. يقل التناقض بين التفضيل المنشور والحظر الفعلي، لكن إثبات الغرض والاستخدام النهائي يظل بحاجة إلى سجل آخر.
  • ما زال Monetization Gateway في قائمة وصول مبكر. لم تُفصح Cloudflare عن موعد إتاحة عامة أو حجم معاملات أو عوائد ناشرين أو رسوم المنتج أو مساهمته في الإيرادات.

ما تستطيع الحافة إثباته بدقة

يمنح تصميم Pay Per Crawl مالك النطاق ثلاثة خيارات لكل زاحف: Allow أو Charge أو Block. يحدد الموقع سعراً موحداً لكل طلب. وقد يكتشف الزاحف السعر من استجابة 402 Payment Required ثم يعيد الطلب موافقاً على المبلغ، أو يرسل منذ البداية الحد الأقصى الذي يقبل دفعه.

واقعة الفوترة محددة. يجب أن تنجح الهوية، وأن تسمح السياسة بالعبور، وأن يحمل الطلب نية دفع، وأن تنتهي العملية باستجابة ناجحة فيها crawler-charged. تقول Cloudflare إنها تجمع هذه الوقائع، وتحاسب الزاحف، وتوزع العائد على الناشر بصفتها Merchant of Record. وإذا لم تكن للزاحف علاقة فوترة معها، يعمل خيار Charge كحظر على مستوى الشبكة؛ إظهار السعر وحده لا يصنع عملية بيع.

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

تعترف Cloudflare بهذا الفارق في شرح الانتقال من Pay Per Crawl إلى Pay Per Use. فقد تُجلب صفحة مرة واحدة ثم تظهر في آلاف الإجابات، أو تُجلب مرات كثيرة من دون استخدام. عدد عمليات التسليم وقيمة الاستخدام لا يتحركان على الساعة نفسها.

التفضيل المنشور لا يساوي التنفيذ

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

يعالج Bot Preference Sync الحلقة الأولى. فهو يعكس خيارات Search وAgent وTraining في لوحة المنطقة على robots.txt مع الإبقاء على أوامر المنع السابقة. وتوضح Cloudflare أن الملف قد يعلن رفض زاحف بينما لا تحظره قواعد الحافة فعلياً. بعض الزواحف تتخذ هذا التضارب ذريعة لتجاهل التفضيل أو محاولة تجاوز القاعدة.

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

والهوية تحتاج إلى أكثر من اسم User-Agent. يعتمد Pay Per Crawl على Web Bot Auth وتوقيعات الرسائل. كما تضع Cloudflare شروطاً إضافية أمام المشغل الذي يجمع Search وTraining ويريد الاحتفاظ بوصول البحث حين يرفض الموقع التدريب: احترام تفضيل عدم التدريب، وإتاحة الانسحاب من ملخصات الذكاء الاصطناعي، وتقديم رؤية على مستوى الرابط ومقاييس البحث، وإثبات أن رفض التدريب لا يضر البحث التقليدي.

تزيد هذه الالتزامات قابلية التحقق من تسمية الغرض، لكنها تعتمد أيضاً على معلومات يقدمها المشغل من داخل منظومته. تطابق robots.txt مع لوحة التحكم لا يثبت وحده أن نموذجاً لم يستخدم المحتوى.

15 سبتمبر موعد لاختبار القاعدة الافتراضية

حدد إعلان يوليو عن التصنيفات والقواعد الجديدة يوم 15 سبتمبر 2026 موعداً نهائياً. نصت الصيغة الأولى على السماح لـSearch في المواقع الجديدة، مع حظر Training وAgent في الصفحات التي تعرض إعلانات. وكان يفترض حظر الزواحف المختلطة التي لا تفصل أغراضها في تلك الصفحات، وإدخال الحسابات المجانية القائمة التي لم تختر إعداداً ضمن التغيير.

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

للقاعدة الافتراضية قوة تفاوضية لأن Cloudflare تقف على بوابة واسعة. تقول الشركة في تقريرها بعد عام إن 52% من طلبات الزواحف التي قاستها على شبكتها في يونيو 2026 كانت للتدريب، وإن الزواحف المختلطة مثّلت أكثر من 36% من النشاط. وتقول أيضاً إن أكثر من 20% من الويب يقع خلف شبكتها. هذه قياسات Cloudflare وتعريفاتها، وليست تعداداً عالمياً، لكنها تفسر قدرة قرار على الحافة على خلق ندرة.

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

سجل الاستخدام يبدأ حيث تتكون النتيجة

تنقل تجربتا Ceramic.ai وYou.com واقعة الدفع إلى أسفل السلسلة. في نموذج Ceramic.ai الموصوف، يحصل الناشر المشارك على مقابل عندما يظهر محتواه في نتيجة بحث، مع بيانات عن الاستعلام والصفحة والمقتطف والترتيب. وفي مثال You.com، يشتري الوكيل مادة مميزة محددة حين يحتاج إليها.

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

تصف Cloudflare نماذج Pay per Query وPay per Result وغيرها بأنها تجارب. لم تتحدد وحدة قياس واحدة. الوصول سهل العد وبعيد عن القيمة؛ والنتيجة أقرب إلى القيمة لكنها تعتمد على السجل الداخلي للمشتري وتفتح باب النزاع.

تعطي Attribution Business Insights عملاء Bot Management معلومات عن الوصول الناجح ونسبة الزحف إلى الإحالة وعرض النطاق والمشغل والتصنيف السلوكي. تحسن هذه البيانات موقف الناشر في التفاوض، لكنها لا تعيد وحدها بناء بيانات التدريب أو المسار الكامل الذي أنتج إجابة.

x402 يوسع ما يمكن تسعيره

يهدف Monetization Gateway المقترح إلى تسعير صفحات وبيانات وواجهات API واستدعاءات أدوات MCP. يتلقى العميل تعليمات x402، ويدفع بعملة مستقرة، ويعيد الطلب مع إثبات، ولا يصل إلى الخادم الأصلي إلا بعد التحقق. ويمكن أن تختلف القاعدة بحسب المسار أو طريقة الطلب أو تعقيد العمل، وأن تُدار من اللوحة أو API أو Terraform.

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

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

ولا تسد القوائم المالية هذه الفجوة. سجلت Cloudflare 696.1 مليون دولار من الإيرادات الفصلية، بزيادة 36%، وتدفقاً نقدياً حراً قدره 56.4 مليون دولار. ويقول نموذج 10-Q إن الاشتراك والدعم يمثلان تقريباً كل الإيرادات، وإن المقابل القائم على الاستخدام المذكور يتعلق أساساً بعرض النطاق الزائد. لا يفصل الملف عملاء أو إيرادات أو RPO لهذه المبادرات. نمو الأعمال القائمة لا يثبت أن السوق الجديد بدأ التحويل.

كيف يتطابق السجلان

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

يحمل HTTP سعراً وإثبات دفع، لكنه لا يكتب حقوق الاستغلال ضمناً. استجابة 200 بعد 402 ليست تلقائياً موافقة على التدريب أو الحفظ أو إعادة التوزيع. تجعل Cloudflare إيصال الوصول أقوى. وانتقالها نحو Pay Per Use هو اعتراف بأن إيصال القيمة يصدر في مكان آخر.

المصادر