Cloudflare Pay Per Use 深度拆解：2026 年 AI 爬虫的免费午餐正式终结

本文由莫潇羽@无忆研习社（www.wuyi.wiki）撰写，转载请注明出处。

快速摘要

2026 年 9 月 15 日，Cloudflare 将正式施行一项震动整个 AI 行业的默认规则：凡是页面上有广告的网站，默认屏蔽「混合用途」AI 爬虫。同一天，去年推出的 Pay Per Crawl（按抓取付费）正式升级为 Pay Per Use（按使用付费）——爬虫抓取内容不再收费，只有抓到的内容真的被 AI 产品引用、展示、使用时才记账。这背后是一套由 Monetization Gateway（支付通道）、爬虫用途拆分与屏蔽、以及 AEO 归因报告组成的「三件套」基础设施。生态合作伙伴中，Ceramic.ai 以 $0.05/1000 次查询的白菜价把搜索层成本压到接近零，为「按使用付费」腾出了经济空间；You.com 则从高端 API 侧切入，为企业 Agent 场景建立按需付费习惯。对 Google 而言，混合爬虫「一次抓取、搜索+AI+训练三份收益」的历史红利被明码标价，被迫拆账；而中小 AI 公司反而因此拉平了起跑线。这场变革的本质不是「帮内容创作者收钱」，而是 Cloudflare 借 publisher 之名、用基础设施定价权对 AI 搜索市场做了一次结构性削平。

想看完整拆解，往下翻。

我是莫潇羽，在无忆研习社（www.wuyi.wiki）写技术趋势拆解有几年了。2026 年上半年如果要选一个对整个互联网生态影响最深远的商业决策，我会投给 Cloudflare 7 月 1 日那场发布。

事情的脉络不复杂：去年（2025 年）Cloudflare 搞了个 Pay Per Crawl，允许网站主向 AI 爬虫收费——说白了就是「你抓我内容，你得付钱」。当时业界普遍觉得这是个姿态性的动作，象征意义大于实际。但到了 2026 年 7 月 1 日，Cloudflare 一口气抛出了三样东西，把姿态变成了可以运转的商业机器：Monetization Gateway（支付网关）、x402 开源支付协议的量产落地、以及 9 月 15 日的「混合用途爬虫默认屏蔽」deadline。

我自己折腾技术内容这些年，对「内容被白嫖」这件事有切身体会。写了几天几夜的文章，被爬虫一秒抓走，变成了某个 AI 回答里的一句「据分析……」——读者得到了答案，不会点进原文，而我的网站连个 UV 都收不到。Cloudflare 这次的逻辑不复杂：既然流量模型变了，结算模型也必须跟着变。本文就是我对这套新机制的全方位拆解，从数据、技术原理、商业博弈到独立开发者实操建议，一条条捋清楚。

背景篇：当机器人成为互联网的「多数居民」

在拆解 Pay Per Use 之前，需要先看懂一个底层变化：互联网的流量版图已经被彻底改写。

机器流量首次超越人类：一个被提前到来的拐点

2026 年 6 月 3 日，Cloudflare CEO Matthew Prince 在 X（原 Twitter）上发了一条推文，原话大意是：这件事发生得比我预想的快——我原本以为要到 2027 年底甚至 2028 年初，结果 AI 代理流量增长太快，机器流量已经超过了人类流量，这是互联网历史上的第一次。

就这一句话，被 Forbes、NBC News、TechCrunch 等几十家主流媒体轮番引用，成了 2026 年科技圈被截屏次数最多的 CEO 发言之一。

具体数字是这样的：Cloudflare Radar 的数据显示，截至 2026 年年中，流经 Cloudflare 网络（覆盖全球约 20% 到 23% 的网站）的全部 HTTP 请求中，约 57.4% 来自自动化程序（bots），只有 42.6% 来自真实人类用户。两年前这个比例还倒过来——人类占大头，机器是小头。

更值得关注的是 AI 代理流量的增速。HUMAN Security 发布的《2026 State of AI Traffic》报告给出了一个令人瞠目结舌的数字：Agentic AI 流量同比增长约 7851%，自动化流量的增长速度是人类流量的约 8 倍。这意味着每过一个月，机器产生的请求量就把人类甩开更远一截。

这个拐点有多重要？它意味着互联网的默认假设要从「服务人类」切换到「服务机器」。以前建网站，默认访客是一个人——他用浏览器打开页面，用眼睛读内容，用鼠标点链接。现在建网站，最大量的访客是一个 AI 代理——它用 HTTP 请求抓页面，用 NLP 提取结构化数据，用向量数据库存 embedding，然后在一个远方的数据中心里把信息喂给某个大模型。

「抓一万次，带回一个人」：AI 爬虫的效率悖论

Cloudflare 官方博客里有一个我反复咂摸的数据：在整个 Web 上，AI 爬虫每给网站带回一个真实访客，中间要发出约 100 到数万次内容请求。

翻译成大白话：一个 AI 搜索产品为了偶尔在答案里引用你网站的一句话，可能已经把你的整个站点爬了几百遍。这些爬取绝大多数不会产生任何「回流」——读者在 AI 界面里看到了答案，不需要点进来源链接，甚至很多 AI 产品根本不提供可点击的来源链接。

Pew Research Center 在 2025 年的一项研究也观察到了类似的趋势：当 Google 搜索结果中出现 AI 生成的摘要时，用户点击传统搜索结果链接的意愿显著降低（详见 Pew 2025 年 7 月发布的「Google users are less likely to click on links when an AI summary appears in the results」）。Ahrefs 在同年的量化分析中给出了更具体的数字——AI Overviews 出现时，排名第一的搜索结果平均点击率下降了约 58%。也就是说，AI 帮用户「消化」了内容之后，大多数场景下用户不会再去原始网页看一眼。

我在无忆研习社写文章这几年对此感受非常直观。一篇花两周写的深度拆解，发布后通过搜索引擎来的自然流量明显在逐年下降——不是文章质量不行，是搜索引擎直接把答案贴在搜索结果页上了，读者不需要点进来。

爬虫分类：不是所有 bot 都「坏」

这里需要做一个对新手友好的说明：互联网上的「爬虫」不等于「恶意程序」。Cloudflare 把爬虫分成几种：

• Search bots（搜索爬虫）：Googlebot、Bingbot 这类，它们抓页面是为了建搜索索引，长期来看会给网站带来搜索流量。这是传统互联网的「默契」——你让我抓，我给你流量。
• AI training bots（训练爬虫）：GPTBot、ClaudeBot、Bytespider 这类，抓页面是为了训练大语言模型。它们不会给网站带来任何回流。
• AI agent bots（代理爬虫）：Perplexity、You.com 的爬虫等，抓页面是为了实时回答用户问题。偶尔会给网站带来引用和点击。
• 混合用途爬虫（Mixed-use crawlers）：同一个爬虫，同时干搜索、同时喂 Agent、同时喂训练。这在 2026 年 9 月 15 日之前是常态——Googlebot 就是最典型的例子。

问题出在最后一个分类。当同一个 bot 用一个身份做三件事，被爬的网站完全没法区分「这次抓我是为了搜索引擎还是为了训模型」，也没法分别计价。Cloudflare 这次要拆的就是这个。

打个比方：你去超市买东西，同一个购物车里既有自己吃的零食（搜索用途）、也有要送给朋友的礼物（Agent 用途）、还有买来研究包装设计的样品（训练用途），但结账时只扫一个总价码——超市不知道你分别买了什么、分别该收多少钱。Cloudflare 的做法相当于在超市门口装了三个通道：零食走 A 通道、礼物走 B 通道、样品走 C 通道，每个通道有自己的计价规则。先分流，再算账。

原理篇：为什么从「按抓取」改成「按使用」

Cloudflare 去年推出的 Pay Per Crawl 本质上是「按次数计费」：AI 公司的爬虫每抓一次页面，网站主就可以收到一笔极其微小的费用。这个模型听起来合理，跑起来却有两笔账根本算不平。

第一笔算不平的账：一半流量是重复抓取

Cloudflare 官方给了一个非常刺眼的数据：在 "good bot"（非恶意的合规爬虫）产生的流量中，超过 50% 是在重抓没有发生任何变化的页面。

想象一下：你写了一篇技术文章，发布后三个月没有改过一个字。但 AI 爬虫可能已经来抓了 30 次、50 次、100 次——因为不同的 AI 产品、不同的用户查询、不同的模型版本，都在重复拉取同一份内容。如果按「抓一次付一次」来结算，AI 公司要为一堆根本没用的重复流量付钱，而网站主收到的钱里也有一半对应的是无意义的重复劳动——双方都在为「噪音」付账。

用伪代码来表达这个逻辑会更直观：

# Pay Per Crawl 的问题：重复抓取也被计费
page_content = fetch_url("https://example.com/article/123")
page_hash   = md5(page_content)

# 第一次抓：计费 ✓
charge(ai_company, publisher, rate=0.001)  # $0.001 per crawl

# 30 天后，页面没变，但又被抓了
page_content = fetch_url("https://example.com/article/123")
new_hash     = md5(page_content)

if new_hash == page_hash:
    # 内容完全相同，但 Pay Per Crawl 仍然计费 ✗
    # 这对 AI 公司和 publisher 都没有价值
    charge(ai_company, publisher, rate=0.001)  # 冤枉钱

这就是「按抓取付费」的第一个致命缺陷：它计量的是动作（有没有抓），而不是价值（抓到的内容有没有被用到）。

第二笔算不平的账：抓取量与实际引用的鸿沟

再回头看那个「抓一万次，带回一个人」的比例。

假设一个中型技术博客每天被各类 AI 爬虫抓取 20000 次，其中只有 2 次最终出现在某个 AI 产品的回答引用里，给网站带来了 1 个真实点击。如果按每次抓取 $0.001 计算，AI 公司一天要付 $20，一年是 $7300——但这 20000 次抓取里 19998 次对 AI 公司来说是「库存」，根本没被用上。AI 公司不愿意为库存付钱，网站主也清楚自己的内容在 AI 生态里的真实价值远不止每天 $20——因为如果那 2 次引用帮 AI 产品解决的是高价值查询（比如「2026 年 AI 爬虫政策的最新变化」），它创造的商业价值远高于几分钱。

Pay Per Use 的解决思路干脆利落：抓取本身免费，只有当内容真的被 Agent 引用、被搜索结果展示、被用于回答用户查询时，才按使用次数结账。

# Pay Per Use 的计费逻辑（简化版）
crawl(url)            → 免费（不计费）
store_in_index(url)   → 免费（不计费）
use_in_answer(url)    → 计费 ✓ （每使用一次，AI 公司付一次）
show_in_results(url)  → 计费 ✓ （每展示一次，AI 公司付一次）

# 关键：谁用了、用了几次、值多少钱，全部需要归因

这套逻辑背后藏着一个非常朴素但一直被忽视的商业常识：为结果付费，而不是为过程付费。 我在自己的知识付费和内容创作经历中也反复体会到这一点——读者愿意为一篇解决了他实际问题的文章付费，但不会为你「写文章的过程」付费。Cloudflare 只是把同样的逻辑搬到了机器对机器的结算层面。

一个容易被忽略的细节：Pay Per Use 不是 Pay Per Crawl 的「升级」，而是「推倒重来」

外面很多报道把 Pay Per Use 描述成 Pay Per Crawl 的「迭代版本」，但两者底层的结算哲学完全不同。Pay Per Crawl 是「按投入收费」——你抓了，无论用不用，都得付。Pay Per Use 是「按产出收费」——你用了才付，不用不付。这个转变之大，差不多相当于从「按小时租用服务器」变成「按实际计算量付费」——前者不管你跑没跑任务都收费，后者只看实际消耗。

Cloudflare 之所以敢这么改，是因为它手里有三个基础设施级别的组件（下一章详细拆），没有这三样，Pay Per Use 就是空中楼阁。但先把结论放在这里：从 Pay Per Crawl 到 Pay Per Use，本质上是把 AI 公司与内容创作者之间的结算关系从「流量生意」变成了「价值生意」。

机制篇：Pay Per Use 三件套深度拆解

外面绝大多数科技媒体把 Pay Per Use 当成「一个功能升级」来写——标题清一色是「Cloudflare 把 Pay Per Crawl 升级成了 Pay Per Use」。这个理解不够。我花了一个下午把 Cloudflare 同一天（2026 年 7 月 1 日）发布的两篇官方博客并排读完，结论是：Pay Per Use 不是单一功能，而是三个独立但相互咬合的基础设施组件叠在一起。 少任何一件，这套机制就跑不起来。

三个组件分别是：

下面逐一拆开讲。

第一件：Monetization Gateway——把「付款」做成基础设施

Monetization Gateway 是这套三件套里最底层、也最容易被外行忽略的组件。简单说，它是一套部署在 Cloudflare 边缘节点上的支付引擎，让任何被 Cloudflare 保护的资源——网页、API、数据集、甚至是 MCP 工具调用——都可以挂上一个「按使用付费」的标签。

它的技术底座是两个东西：

x402 协议：HTTP 状态码里有一个基本不用的码叫 402 "Payment Required"。这个码在 HTTP/1.0 时代就被定义了，但二十多年来几乎没人正经用过。Coinbase 将 x402 协议贡献给 Linux Foundation 后，Cloudflare 与 Coinbase、Stripe 等 22 个以上的行业伙伴共同参与了 x402 Foundation 治理机构的初始建设，把 402 状态码扩展成了一整套面向机器对机器支付的开放协议。工作流程大致如下：

客户端（AI 爬虫）                     Cloudflare 边缘节点
       │                                      │
       │  GET /article/ai-trends-2026         │
       │ ──────────────────────────────────▶  │
       │                                      │  检查：该资源是否需要付费？
       │                                      │  → 需要，费率：$0.0005/次使用
       │                                      │
       │  402 Payment Required                │
       │  Header: x402-amount: 0.0005         │
       │  Header: x402-currency: USDC         │
       │  Header: x402-recipient: 0xABCD...   │
       │ ◀──────────────────────────────────  │
       │                                      │
       │  客户端签名交易，提交 USDC 支付        │
       │ ──────────────────────────────────▶  │
       │                                      │  验证支付 → 放行内容
       │  200 OK + 完整内容                     │
       │ ◀──────────────────────────────────  │

USDC 稳定币结算：为什么不用传统支付（信用卡、银行转账）？因为传统支付渠道根本不适合微支付场景。你想一下——一个网站主可能一次只收到 $0.0005，如果用信用卡结算，光是手续费就远超交易金额本身。USDC 这种链上稳定币（1 USDC ≈ 1 美元）的转账成本极低，且在 x402 的设计目标中是「亚秒级到账」。这意味着 AI 爬虫可以在发出 HTTP 请求的同一个往返时间内完成支付和内容获取，不需要额外的结算周期。

Cloudflare 博客里给出的示例定价很能说明这套系统的想象空间：

• 一次 web search 查询：几美分
• 上传接口：$0.001 起价 + $0.01/MB
• 每解决一张客服工单：$0.99

注意第三个例子——它已经超越了「AI 爬虫付费抓内容」的范畴，进入了「任何 API 或服务都可以按结果计费」的领域。这是 Monetization Gateway 真正野心所在：它不只是给 publisher 收钱的工具，而是一套面向「代理经济」的通用支付基础设施。

第二件：拆分与屏蔽——9 月 15 日的默认规则为什么是关键

2026 年 9 月 15 日起，Cloudflare 的默认设置会做一件事：凡是页面上有广告的网站，自动屏蔽"混合用途"爬虫。

什么叫「混合用途」？就是同一个爬虫身份同时用于搜索索引、AI 代理检索和模型训练。Cloudflare 的立场非常明确：你要抓可以，但得先拆开——搜索是搜索，Agent 是 Agent，训练是训练，三个身份三条通道。

你可能想问：这不就是改个 robots.txt 的事吗？不是的。传统 robots.txt 只能「按 bot 名屏蔽」——你可以在文件里写 User-agent: GPTBot Disallow: / 来阻止 OpenAI 的训练爬虫，但如果 Google 用同一个 Googlebot 既做搜索又做 AI Overviews 又做 Gemini 训练，你没法靠 robots.txt 把它们拆开。你只能要么全放，要么全禁。要么接受自己的内容被 AI 白嫖，要么放弃搜索流量——这对任何依赖搜索流量生存的内容网站来说都是不可接受的选择。

Cloudflare 这一次不是提供「工具让你自己选」，而是直接在默认配置里把「混合用途」设为了屏蔽项。从 opt-out（网站主得自己主动去屏蔽）变成了 opt-in（AI 公司必须先申报用途、获得明确许可才能抓）。Nieman Lab 的报道第一时间抓住了这个转变的意义："Cloudflare 成为第一家默认屏蔽 AI 抓取的主要互联网基础设施公司。"

这为什么是 Pay Per Use 能跑通的前提？因为如果混合爬虫不被拆分，同一个爬虫抓一次、三个用途一起用，你根本没法给「这次抓取在 Agent 场景里被用了 3 次，在训练场景里被用了 1 次」分别计费。账算不清，钱就没法分。先拆身份，再谈钱——这是 Cloudflare 出牌的逻辑顺序。

第三件：归因报告——没有它，「按使用付」就是瞎猜

加入 Ceramic 合作的网站主，会收到一份叫 AEO（AI Engine Optimization，AI 引擎优化）的报告，里面包含：

• Top queries：哪些用户查询触发了你内容的引用
• Snapshot snippets：AI 产品在回答中使用了你文章的哪些片段
• 平均排名：你的内容在 AI 搜索结果中的排位

这是 Pay Per Use 和 Pay Per Crawl 之间最本质的技术分水岭。Pay Per Crawl 不需要归因——你只要数爬虫来了多少次就行，和网站主的内容被实际使用了多少次没关系。但 Pay Per Use 必须归因——你必须能准确追踪「哪次抓取产生了哪次引用、那次引用对应多少价值」。

打个比方：Pay Per Crawl 像是按「进店人数」收租——不管进店的人买没买东西，只要踏进门槛就要付钱。Pay Per Use 像是按「实际成交」抽佣——只有顾客真的买了东西，才按成交额的一定比例收费。要做「按成交抽佣」，你必须有一套 POS 系统记录每一笔交易。AEO 就是这套 POS 系统。

在实际操作中，AEO 报告的价值不只是「记账」——它还给内容创作者提供了一个全新的 SEO 维度。以前我们优化内容只能看 Google Analytics 和 Search Console，优化目标是「在 Google 搜索结果中排名靠前」。现在有了 AEO，内容创作者可以知道自己的文章在 AI 产品中的表现如何，进而开始做 AEO 优化：什么样的内容结构容易被 AI 引用？什么样的摘要格式能让 AI 更准确地提炼关键信息？这些都是全新的领域，我后续会单独写一篇来拆。

三件套咬合关系的一览表

三件套齐了，Pay Per Use 才是真的。这是我读完两篇官方博客之后最核心的一个判断——而这个判断在绝大多数外部报道里被漏掉了，媒体普遍只把它当成「一个功能升级」来报道，没有看到它内部三个组件的咬合关系。

定价篇：Ceramic.ai 把搜索打到白菜价的经济账

Cloudflare 在 Pay Per Use 生态中引入 Ceramic.ai 和 You.com 作为首批合作伙伴，不是随便找两家 AI 搜索公司来凑数——这俩分别在价格光谱的两端各占一个生态位，合在一起恰好演示了 Pay Per Use 在「低端」和「高端」两个方向上的可行性。

Ceramic.ai：$0.05/1000 次查询——搜索成本的天花板被打穿了

Ceramic.ai 官网首页的定价写得很直白：每 1000 次查询 $0.05，延迟 50 毫秒，覆盖 400 亿以上网页。 注意，这里的 $0.05 不是 per query，是 per thousand queries。折算下来，单次搜索查询的成本是 $0.00005——也就是 0.005 美分。

这个价格有多夸张？Ceramic 自己做了一个对比：用 Grok-4-1-fast 搭配某主流搜索 API，跑 1000 次 query 的成本是 $14.15。同样的 1000 次查询用 Ceramic，成本是 $0.20。这中间的差距大约是 70 倍。

但实际差距比这个数字更大——因为 Grok 是推理模型，推理成本是必须花的，而搜索 API 那 $14 是纯搜索层的开销。如果只看搜索层，Ceramic 的 $0.05/1K 和竞品的 $5/1K 到 $14/1K 之间的差距是 100 到 280 倍。

我列一个对比表会更清楚：

注：以上价格为 2026 年中写稿时的近似行情。各家 API 的定价模型差异较大——有的含免费额度，有的按 token 额外计费，有的区分基础搜索和深度提取。价格变动很快，请以各平台官方定价页面的实时数据为准。

为什么「把搜索搞便宜」是 Pay Per Use 能跑通的经济前提？

这里有一个容易被忽视的经济学逻辑。一个 AI 产品每回答一次用户查询，成本结构大致是这样的：

单次 AI 回答的总成本 =
    模型推理成本（token in + token out）
  + 搜索成本（调用搜索 API 获取实时信息）
  + 内容成本（Pay Per Use 向 publisher 付费）

模型推理成本是硬性的，由 GPU 算力和模型效率决定，短期内压不下来太多。如果搜索 API 一层还要收 $14/1000 次查询，那每次回答光搜索成本就是 1.4 美分。这时候再在「内容」这一层叠一个「按使用付内容费」——哪怕每次只收 0.1 美分——对于一天要处理几百万次查询的 AI 产品来说，年化下来就是一笔巨大的额外开支。

Ceramic 做的事情，本质上就是把搜索这一层压到接近零（$0.00005/次），把利润空间让给内容和模型。 当一个 AI 产品发现「搜索成本」几乎可以忽略不计时，它才有预算空间去为「内容」单独付一笔费用。换句话说——搜索不压到地板，publisher 就永远见不到钱。

这也是为什么 Cloudflare 挑 Ceramic 作为首批合作伙伴——不是因为它技术最牛或覆盖面最广，而是因为它主动把搜索层利润砍到了让竞争对手无法跟随的级别。谁做基础设施，谁就有话语权决定「上下游怎么分账」。Cloudflare 借 Ceramic 展示的是：如果搜索这一层愿意把利润让出来，内容创作者是有可能分到钱的。

You.com：另一端的打法——不做低价，做高价值

同一天官宣的 You.com 走的是完全不同的路线。

You.com 不做低价通用搜索，它做的是 Research API——面向企业 Agent 场景的深度研究服务。它的 API 会执行多步骤搜索、跨多个来源交叉验证，最后返回带有明确引用来源的结构化答案。价格当然比 Ceramic 贵得多——每 100 次查询收费不低——但它的目标客户是 DuckDuckGo、阿里巴巴、Amazon 这种对答案质量有极高要求的企业客户。SLA 拉到 99.99%，p99 延迟控制在 300ms 以内。

You.com 在 Pay Per Use 生态里的角色是「帮 AI 公司建立按需付费习惯」。它的逻辑是：如果你的 Agent 要回答一个需要深度调研的问题（比如「对比 2026 年所有主流 AI 搜索 API 的定价模型」），它不能只靠免费网页抓取——它需要读付费墙后面的深度内容、需要访问专业数据库、需要调用结构化数据接口。这些内容从来不是免费的，You.com 做的事情就是让 Agent 在关键时刻能按需付费获取这些 premium 内容。

Ceramic 负责把成本压到地板，You.com 负责把 Agent 拉进付费习惯。一个打价格战，一个打价值战——合在一起，恰好构成了 Pay Per Use 在低端和高端两个维度上的完整演示。

格局篇：这场博弈的真正靶心

读到这里，你可能已经感觉到了：Pay Per Use 表面上是在帮内容创作者收钱，实际上 Cloudflare 在打的是一场更大的牌——借 publisher 之名，用基础设施定价权对 AI 搜索市场做结构性削平。 真正的靶心是 Google。

Google 的「一份成本，三份收益」被明码标价了

这件事的背景要拉回到 2025 年。那一年 Google 全面铺开了 AI Overviews——在搜索结果页顶部用 AI 直接生成摘要，用户读完摘要就走，不再点击任何链接。Pew 2025 年的研究已经揭示了这一趋势：AI 摘要出现时，用户点击传统搜索结果链接的意愿显著下降。Ahrefs 的量化数据进一步显示，AI Overviews 让排名第一的结果平均点击率下降了约 58%。

更关键的是：Googlebot 是互联网上最大的混合用途爬虫。同一次抓取，Google 把它同时用于三个目的：

• 搜索索引：让网页能在 Google 搜索结果中出现
• AI Overviews：提取内容生成 AI 摘要
• Gemini 训练：把内容喂给大模型做训练

以前这三个用途用的是同一个 Googlebot 身份，一次抓取、一份成本、三份收益。网站主没法拒绝——你如果屏蔽 Googlebot，你的网站就从 Google 搜索结果里消失，这对大多数依赖搜索流量的内容网站来说是致命的。

Cloudflare 这次等于把 Google 的隐形优势公开标了价。9 月 15 日之后，混合用途爬虫被默认屏蔽。Google 想要继续抓取 Cloudflare 网络内的内容，就必须把 Googlebot 拆成三个独立身份：搜索一个、AI 一个、训练一个。搜索用途可能继续免费（因为它是传统搜索引擎的「默契」），但 AI 用途和训练用途都得单独付钱。

做同一件事，Google 突然要多付两笔钱。 这是 Cloudflare 给 Google 出的难题——不是技术上做不到，而是商业模式上不好消化。Google 如果接受拆分，意味着每年多出几十亿美元的内容成本；Google 如果不接受拆分，意味着在 Cloudflare 网络内（覆盖约 23% 的全球网站）的 AI 内容竞争力下降。

为什么中小 AI 公司反而受益？

对 Perplexity、Ceramic、You.com 这批中小 AI 搜索公司来说，Pay Per Use 反而是一个好消息。

道理很简单：在旧的「随便抓」模式下，Google 靠 Googlebot 的规模优势碾压一切——它的爬虫覆盖范围无人能及，它的索引更新速度无人能及，这些都是「免费抓取」时代的竞争壁垒。但当大家都进入「按使用付费」模式后，Google 的规模优势被削弱了——因为比的不再是「谁爬得多」，而是「谁用得好」。你爬再多、存再多，如果不用或者用不好，就不用付钱；但你每用一次就要付一次。

起跑线被拉平了。 中小公司本来就付不起 Google 那种规模的爬虫基础设施，现在大家都一样：抓取免费，使用付费。这让竞争回归到了产品本身——谁的 AI 回答更准确、谁的引用更透明、谁的归因做得更好——而不是谁的钱包更鼓、服务器更多。

Cloudflare CEO Matthew Prince 在 2025 年 7 月 1 日发了那条著名的推文："Welcome to Content Independence Day! No AI crawl without compensation."（欢迎来到内容独立日！没有补偿就不能抓取。）当时很多人觉得这只是 PR 话术。但一年后的 2026 年 7 月 1 日，Cloudflare 用三件套把这句话变成了可以运转的商业机器——从姿态到执行，刚好一年。

博弈格局一览

用一张表来概括这场博弈中各方的位置和得失：

一场「代理经济」的提前博弈

我一直认为，Pay Per Use 真正的历史意义不在于它能不能帮内容创作者赚到钱——这个需要时间来验证——而在于它是第一个把「机器对机器的按使用付费」做成标准化基础设施的案例。

在一个人和机器各占一半流量的互联网里，「谁使用了什么、该付多少钱」这个问题会变得越来越核心。Cloudflare 赌的是：未来最大的流量消费者不是人类，是 AI 代理；所以未来的支付基础设施不能只为人类设计，必须为机器对机器的微支付场景重新设计。Pay Per Use 只是第一步。

这也是我（莫潇羽@无忆研习社）为什么花这么大力气拆这套机制——它不是某个公司的产品升级，而是一个可能重塑互联网商业底层逻辑的信号。不管你是做 AI 产品、做内容创作、还是做独立开发，理解这套逻辑都会影响你未来三到五年的技术选型和商业模式判断。

实操篇：独立开发者怎么应对这场变革

前面一直在讲大厂博弈——Google vs Cloudflare、Ceramic vs 传统搜索 API——听起来挺热闹，但对独立开发者和小团队来说，真正有用的是从这套机制里提取出可以落地的东西。我自己折腾过几个小产品，也在带一些独立开发者朋友做项目，下面三条是我认为最有实操价值的观察。

观察一：把「内容成本」当成独立预算项

在 2026 年 9 月 15 日之前，做一个 AI 搜索类产品（或者任何需要实时检索网页的 Agent 产品），算成本时大家基本上就看两样：

• 模型推理（token in + token out）
• 搜索 API 调用费

内容这一层是零成本——随便抓，不用付钱。但 9 月 15 日之后，这个假设崩塌了。如果你的产品需要高质量、实时、来自 Cloudflare 网络内网站的内容，你迟早要在预算表里加上一栏「内容使用费」。

我建议你现在就开始做三件事：

第一，梳理你的产品依赖哪些外部内容源。哪些是 Cloudflare 网络内的？哪些是广告支持的页面（这类页面 9 月 15 日之后默认屏蔽混合爬虫）？哪些是关键内容、不可替代？列一个清单出来。

第二，估算潜在的内容成本。假设你的产品每天处理 10000 次用户查询，其中 30% 需要引用外部网页内容，每次引用按 $0.0005 到 $0.005 来估算（这是目前比较合理的猜测区间——实际价格取决于 Cloudflare 和 publisher 之间的具体费率，目前还没有公开的统一价目表）。那么：

每天内容使用次数 = 10000 × 30% = 3000 次
每天内容成本（低估算） = 3000 × $0.0005 = $1.50/天
每天内容成本（高估算） = 3000 × $0.005  = $15.00/天
每月内容成本范围             = $45 到 $450
每年内容成本范围             = $540 到 $5400

对于一个月活几万的产品来说，这个成本不算高。但如果你做的是面向大众消费者的免费产品、靠广告赚钱，那每一笔开支都得精打细算。关键是提前把这笔账算清楚，不要等到 9 月 15 日之后被账单打个措手不及。

第三，在技术架构上预留内容成本的计量和上报能力。你的 Agent 每引用一次外部内容，应该能在日志里记录下来：引用了哪个 URL、属于哪个 publisher、当前累计产生了多少次引用。这不是过度设计——如果你将来要和 publisher 或 Cloudflare 结算，这些数据就是你的账本。

有一个实操小技巧值得分享：如果你用的是常见的 Agent 框架（比如 LangChain、CrewAI 或国产的 Dify、Coze），大部分框架已经内置了「引用来源追踪」的能力。你只需要在配置里打开 source attribution 选项，就能在每次 Agent 回答中拿到它引用了哪些 URL。把这些 URL 汇总到一个简单的统计表里（甚至一个 CSV 文件就行），你就能快速估算出自己的产品对每个内容源的依赖程度。对于那些被高频引用的内容源，如果它们恰好是 Cloudflare 网络内的广告支持页面——提前做好备案，看看能不能通过 Monetization Gateway 建立正式的结算关系，或者寻找替代内容源。不要等到收到账单才发现某