AI 爬虫该封禁还是收费？Cloudflare AI Crawl Control 与 Pay Per Crawl 实战

更新日期：2026-08-30

AI 爬虫访问网站时，站长通常只有两个直觉反应：全部放行，希望换来引用和流量；或者全部封禁，避免内容被无偿抓取。Cloudflare AI Crawl Control 提供了第三种思路：先观察不同 crawler 的行为，再分别选择 Allow、Block，或者在 Pay Per Crawl 中选择 Charge。

但“收费”目前还不是所有网站都能立即开启的功能。Cloudflare 官方文档明确标注 Pay Per Crawl 仍处于 closed/private beta。本文会把已经普遍可用的监控与封禁能力，和需要申请资格的收费能力分开说明。

先说结论

不建议在没有流量数据时一键封禁所有 AI bot。先观察哪些 crawler 在访问、访问哪些路径、是否带来 referral，再决定策略。
robots.txt 是偏好声明，不是防火墙。需要强制阻止访问时，应使用 AI Crawl Control 或 WAF。
搜索引擎 crawler 与纯训练 crawler 的价值不同。误封或收费搜索引擎 crawler 可能影响收录和 SEO。
Pay Per Crawl 当前是 closed beta，不能把它当作所有 Cloudflare 账号都已具备的稳定收入渠道。
WAF 和 Bot Management 先于 Pay Per Crawl 执行。请求如果已被上游规则拦截，就不会进入收费流程。

AI Crawl Control 能做什么

AI Crawl Control 原名 AI Audit，当前可以在 Cloudflare 中提供四类能力：

查看哪些已识别的 AI 服务访问了网站。
按 crawler 或 operator 分析请求数、流量、状态码、hostname 和路径。
观察 crawler 是否违反 robots.txt。
对不同 crawler 设置 Allow、Block；获得 beta 资格后还可设置 Charge。

功能虽然标注为所有套餐可用，但检测能力并不完全相同。Free 方案主要根据公开 user-agent 识别自报身份的 crawler，Metrics 通常只显示最近 24 小时；Enterprise 配合 Bot Management 可以使用更强的检测信号和更长的分析周期。

这意味着面板中的“没有 AI crawler”不一定等于真实流量为零。伪造 user-agent、通用浏览器自动化和未被识别的 bot 仍需要结合 WAF、Bot Management 和源站日志判断。

第一步：先观察，不急着全部 Block

域名需要已经接入 Cloudflare并开启代理。进入控制台的 AI Crawl Control 后，先检查 Overview、Crawlers 和 Metrics：

哪些 crawler 请求最多？
主要抓取文章、首页、搜索页还是 API？
是否反复抓取同一个 URL？
成功响应与 4xx/5xx 的比例如何？
是否遵守 robots.txt？
这些 operator 是否带来引用或真实访问？

建议至少收集一个完整内容周期的数据。新闻站可能按天观察，低频技术博客可能需要更长时间。不要只看请求数量：一个 crawler 请求很多但严格使用缓存，和一个不断抓取动态搜索 URL 的 crawler，给源站带来的成本完全不同。

第二步：理解 robots.txt、Content Signals 和强制封锁的区别

robots.txt 的作用是向 crawler 表达抓取偏好。Cloudflare managed robots.txt 可以为已知 AI crawler 生成或补充规则，并加入 Content Signals。

Cloudflare 当前定义的主要信号包括：

信号	含义
search	建立搜索索引并提供链接或简短摘要
ai-input	将内容用于即时 AI 回答、RAG 或 grounding
ai-train	将内容用于训练或微调模型
use	Cloudflare 正在测试的内容保留与复用范围

官方文档给出的 managed robots.txt 示例当前包含类似下面的内容：

User-Agent: *
Content-signal: search=yes, ai-train=no, use=reference
Allow: /

应优先在 Cloudflare 控制台开启和管理该能力，而不是复制一段规则后长期不维护。Content Signals 仍属于机器可读偏好，crawler 是否遵守取决于运营方；Google Search Console 也可能把新指令报告为“不理解”，Cloudflare 表示其观察中未发现因此影响正常抓取。

如果目标是技术上阻止某个 crawler，请在 AI Crawl Control 的 Crawlers 标签中选择 Block。Cloudflare 会创建或更新名为 AI Crawl Control 的 WAF custom rule。与 Disallow 相比，这是在 Cloudflare 边缘直接返回拦截响应。

第三步：为不同 crawler 选择 Allow、Block 或 Charge

可以先使用下面的决策矩阵：

情况	建议动作	原因
传统搜索引擎 crawler，能带来收录与点击	Allow	Block/Charge 可能影响 SEO
提供清晰引用、带来 referral 的 AI assistant	先 Allow 并观察	可能形成新的发现入口
纯训练 crawler，与你的内容策略不一致	Block 或表达 ai-train=no	减少不希望的训练使用
高频抓取、无引用、增加明显源站成本	Block	先止损，再讨论许可
已加入 Pay Per Crawl 且 crawler 支持付款	Charge	用明确价格换取成功访问
登录、搜索、结算和后台路径	Block 或排除	这些通常不是可销售内容

分类不是永久决定。operator 可能调整产品和 user-agent，网站的内容策略也会变化，应定期复查。

第四步：配置 Block 时保留可维护性

AI Crawl Control 的基础界面适合按 crawler 操作。如果需要路径级例外，例如允许 crawler 查看公开博客、阻止动态搜索和 API，可以扩展底层 WAF rule。

修改前先注意两点：

WAF 中的直接修改不会完整同步回 AI Crawl Control 面板。
如果把表达式改到 AI Crawl Control 无法解析，控制台会显示警告。

因此应把 Crawlers 标签作为主要入口，只在面板无法表达路径或 hostname 规则时修改 WAF。修改后分别测试普通浏览器、搜索引擎 crawler 和目标 AI crawler，不要只看一条 curl 响应。

付费套餐还可以自定义 Block response，返回 403 Forbidden 或 402 Payment Required，并在纯文本响应中提供许可联系方法。返回 402 本身并不会自动完成支付；真正的结算需要 Pay Per Crawl 或其他支付协议。

Pay Per Crawl 到底怎样工作

Pay Per Crawl 允许站长按 Cloudflare zone 设置价格，再对每个受支持 crawler 选择 Charge。Crawler 请求内容时通过签名请求头表达支付意图：

支付条件满足并成功取得 HTTP 200 内容后产生费用。
没有表达支付意图或可接受价格不足时，可收到 HTTP 402 与价格信息。
Cloudflare 在该功能中作为 Merchant of Record，并提供计费基础设施。
相同页面每次重新抓取都可能重新计费，crawler 运营方需要自行控制预算。
错误响应不计费。

下面这些发现和安全路径始终可以免费抓取：

/robots.txt
/sitemap.xml
/security.txt
/.well-known/security.txt
/crawlers.json

这种设计让 crawler 能先发现规则、站点地图和价格，再决定是否访问收费内容。

申请 beta 后的站点配置顺序

只有控制台已经出现 Pay Per Crawl 权限时，才继续下面的配置：

在账户设置中启用 Pay Per Crawl，并按官方流程连接结算账户。
为 zone 设置默认价格。
在 Crawlers 页面分别选择 Charge、Allow 或 Block。
为首页、分类页和发现路径设置免费规则，让 crawler 能找到收费文章。
排除登录、站内搜索、API 等不应收费的功能路径。
监控成功交付、402、错误率和 payout，不要只看请求数。

默认价格作用于整个 zone。若启用 dynamic pricing，源站或 Worker 可以在符合条件的响应中返回：

Crawler-Price: USD 0.25

Cloudflare 会在源站请求上增加 cf-pay-per-crawl，用于表示当前是 bypass、zone-default 还是 in-band pricing。只有开启动态价格并准确理解协议时才生成 Crawler-Price；不要对所有普通响应随意添加这个 header。

WAF 为什么可能让收费失效

Cloudflare 的执行顺序是：WAF custom rules 和 AI Crawl Control block 在前，Bot Solutions 在中间，Pay Per Crawl 在后。

常见冲突是：

通用规则先封禁所有 bot，Pay Per Crawl 永远收不到请求。
国家/地区规则先拦截，即使 crawler 愿意付费也无法访问。
AI Crawl Control 中选择 Allow，但另一条更早执行的 WAF rule 仍然 Block。

启用收费前应在 Security Rules 中审查规则顺序，并用 Cloudflare 提供的分析数据确认请求究竟在哪一层结束。不要为了收费而放宽与 AI crawler 无关的安全规则。

Pay Per Crawl 和 x402 Monetization Gateway 不是一回事

Cloudflare 还发布了基于 x402 的 Monetization Gateway，用于给 API、文件、推理结果或其他资源增加机器支付。两者目标相近，但使用场景不同：

Pay Per Crawl：面向已识别、支持该协议的 AI crawler，按成功抓取计费。
Monetization Gateway：面向更通用的机器客户端和资源，通过 x402 完成访问支付。

技术博客希望对 crawler 抓取文章收费，优先研究 Pay Per Crawl；提供付费 API 或数据集，则更适合单独评估 Monetization Gateway。不要在同一路径叠加两套未知的 402 流程。

一个更现实的上线策略

对于普通技术博客，可以分四步推进：

阶段 A：只监控

启用 AI Crawl Control，观察 crawler、路径、带宽、robots.txt violation 和 referral，不改访问策略。

阶段 B：表达偏好

开启 managed robots.txt，明确 search、AI input 和 training 的偏好，同时确认 Googlebot 等搜索 crawler 没有被误伤。

阶段 C：精确封禁

只 Block 明确不符合策略或产生异常成本的 crawler；为公开索引和有价值引用保留 Allow。

阶段 D：小范围收费

获得 beta 资格后，先选择少量高价值内容测试 Charge，保留首页、分类和 sitemap 免费。观察 200、402、收入、源站成本和 referral 变化，再决定是否扩大。

没有抓取量、付费 crawler 支持和独家内容时，Pay Per Crawl 收入可能很低。应把它视为访问策略实验，而不是预先承诺的商业模式。