摘要

  • Cloudflare 的 Pay Per Crawl 以一次可验证的交付为记账点：爬虫通过身份与价格检查，带着付款意愿取得成功响应，边缘回传 crawler-charged。这张收据证明付费访问，不证明引用、训练或商业使用。
  • Cloudflare 自己已承认，抓取次数只是价值的粗糙代理。Pay Per Use 实验把触发点后移：Ceramic.ai 按内容出现在搜索结果中付费，You.com 则让代理按需购买特定的优质内容。
  • 8 月 21 日公布的 Bot Preference Sync 让后台策略与 robots.txt 对齐，有助于消除声明和执行的漂移；用途仍需爬虫分身、签名、透明度以及下游记录来证明。
  • Monetization Gateway 目前只有早期访问等候名单。通用上线时间、交易量、发行方收入、Cloudflare 收费和产品收入均未披露，不能把公司整体增长当成这项市场已经兑现。

一次内容交付，至少经过五道门

市场最容易误判的地方，是把“服务器返回了内容”写成“内容产生了价值”。两者之间并非修辞差异，而是控制权和证据边界的变化。

第一道门是站点所有者的偏好：允许搜索、拒绝训练，还是按爬虫区别对待。第二道门是边缘执行：一条写在 robots.txt 里的要求，是否真的对应阻断或放行规则。第三道门是身份：请求者是不是它声称的爬虫。第四道门是用途：Search、Agent、Training 的标签是否真实且保持分离。第五道门才是访问或付款。内容离开边缘之后，还有第六个事件——它是否真的进入结果、回答、训练集或代理任务。

Cloudflare 可以直接观察前五道门中的大部分，却无法仅凭一次 HTTP 交付看见第六道门。这正是两本账必须分开的原因。

同步策略，修复的是记录漂移

Bot Preference Sync 把 Cloudflare 区域后台对 Search、Agent 和 Training 的分类选择写进站点的 robots.txt，并保留原有的 Disallow。Cloudflare 对问题的描述很坦率：公开偏好和实际执行规则可能互相矛盾；有些爬虫会把这种矛盾当作无视偏好或绕过限制的理由。

同步让公开记录更可信，但它不是新的事实裁判。Cloudflare 依据 BotBase 维护的爬虫清单定期更新文件，处理的是分类级规则，不会自动读懂每一条定制例外。出版商若与某家公司单独签约、只允许一个代理或为某组路径设定特殊许可，仍要维护更细的规则。

8 月的方案还要求同时从事 Search 与 Training 的运营者承担额外透明义务：尊重“不训练”偏好，提供退出 AI 摘要的方式，给出 URL 级训练可见性和搜索指标，并证明退出训练不会伤害传统搜索结果。这些要求使“用途标签”更可核验，却仍依赖运营者提供下游证据。一个整齐的 robots.txt 能证明站点表达了什么，不能单独证明模型没有学过什么。

9 月 15 日是控制切换，不是付款日

Cloudflare 7 月发布的新分类与默认规则 把 9 月 15 日设为截止点。当时的描述是：新站点对 Search 放行，在含广告页面阻断 Training 与 Agent；不肯拆分用途的混合爬虫也会在广告页面被阻断；尚未主动设置的现有免费客户同样在调整范围内。

8 月的产品说明更细：出版或广告支持站点在入驻时可以选择让 Training 默认为 Disallow，非出版站点则不会被自动加入阻断；旧版托管 robots.txt 用户会在新同步功能上线时被要求复核。两份披露并非已经完成的生产回执，而是仍在细化的计划。9 月 15 日以后，真正需要核验的是默认矩阵是否如期生效、多少站点主动覆盖默认值，以及混合爬虫是否真的拆分身份和用途。

默认值具有市场力量，因为 Cloudflare 站在分发入口。该公司在一周年爬虫报告中称，2026 年 6 月其所测网络里的爬虫请求有 52% 用于 AI 训练，混合用途爬虫占比超过 36%；Cloudflare 还称其网络承载超过 20% 的网站。这些都是 Cloudflare 自己口径下的网络数据，并非全网普查，但足以解释为什么一项边缘默认值会改变谈判筹码。

阻断可以制造稀缺，强制拆分用途可以降低信息不对称。两者都不会自动产生版权许可，也不会把钱转给内容生产者。谈判杠杆与现金结算仍是两张收据。

Pay Per Crawl 记的是交付账

在 Pay Per Crawl 的私测设计中，出版商可以按爬虫选择 Allow、Charge 或 Block，并为全站设定统一的单次请求价格。爬虫可先收到 402 Payment Required 与报价，再携带精确价格重试；也可在初次请求时给出可接受的最高价。

只有当请求通过身份验证、明确表达付款意愿并收到带 crawler-charged 的成功响应，Cloudflare 才记录计费事件。该公司称自己在此产品中担任 Merchant of Record，汇总请求、向爬虫收费并把收入分配给出版商。若爬虫与 Cloudflare 没有计费关系，“Charge” 实际上等同于网络阻断，而不是一笔未收款应收账。

这套机制的价值在于可对账：请求者、价格、访问决策和成功交付都有记录。它的边界同样清楚。付款者买到了访问，是否买到保存、引用、再分发或训练权，要由真实合同说明；一个 200 响应不会凭空生成这些权利。

Pay Per Use 试图记价值账

Cloudflare 在 2026 年 7 月的搜索商业模式说明中直言，抓取是价值的粗糙计量。一篇页面可能只抓取一次，却出现在数千条答案里；另一篇可能被重复抓取，最终一次也没被使用。

因此，Cloudflare 与 Ceramic.ai、You.com 测试新的触发点。Ceramic.ai 的模型是在出版商内容进入搜索结果时按查询付款，并让出版商看到查询、页面、摘要片段和结果位置。You.com 的例子是代理需要某项优质内容时按需购买。前者试图把钱与结果出现相连，后者把钱与明确的采购动作相连。

它们比抓取次数更接近价值，也更难审计。多来源综合答案该如何分账？出现引用是否等于产生因果价值？相似页面如何去重？漏记由谁纠正？应该按查询、结果、任务成功、token 还是许可期定价？Cloudflare 把 Pay per Query、Pay per Result 等列为实验，尚未宣布一个统一单位。

Attribution Business Insights 为 Bot Management 客户提供成功访问、爬取与引流比、带宽、运营者和用途分类。这能改善出版商谈判时的信息地位，但网络观测终止于网络边界：它能看见某个爬虫拿走了页面，也能看见后来有没有带来访问，不能据此完整重建训练语料或回答生成路径。

x402 扩大可售对象，尚未证明市场规模

拟议中的 Monetization Gateway 把收费对象从爬虫扩展到网页、数据集、API 和 MCP 工具调用。Cloudflare 设想由边缘返回 x402 价格说明，调用者使用稳定币支付并携带凭证重试，验证通过后才抵达源站。价格规则可以按路径、请求方法或任务复杂度设置，并由后台、API 或 Terraform 管理。

这可能显著降低微小数字商品的交易成本：代理无须先注册账户或购买月度订阅，卖方也无须让未付款流量进入源站。对于 Cloudflare，身份、策略、验款与交付会聚到同一个控制面。

不过，公告中的关键动词仍是“将会”。目前入口是早期访问等候名单。已审阅披露没有给出通用上线日期、生产交易量、出版商净收入、Cloudflare 费率、退款争议流程或稳定币兑换细节；“亚秒级结算”是目标，不是运营记录。

财务披露也没有补上这张收据。Cloudflare 第二季度总收入为 6.961 亿美元，同比增长 36%，自由现金流 5640 万美元。其 10-Q称收入几乎全部来自订阅与支持，单列的使用型对价主要是超额带宽。文件没有披露 Monetization Gateway、Pay Per Crawl 或 Pay Per Use 的客户、收入或剩余履约义务。公司经营强劲可反驳“业务困境”，却不能证明这套新市场已经商业化。

市场要闭环，必须分别关账

访问账需要核对付费请求、成功交付、出版商净收款、结算时间、失败支付、例外和争议。使用账需要核对哪次查询或任务调用了哪项资源、在何种许可下产生了什么结果，以及付款如何分配。买方还要判断内容是否独特、及时、没有被重复定价。

HTTP 能携带报价和付款凭证，不能默默替合同补写权利范围。一次经过 402 的成功交付，不等于训练许可，不等于引用证明，也不等于价值已经实现。Cloudflare 已把访问账做得越来越可验证；它最重要的市场判断，是承认使用账必须另做。

来源