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 收入可能很低。应把它视为访问策略实验，而不是预先承诺的商业模式。
上线检查清单
- 已区分搜索 crawler、AI assistant 和纯训练 crawler。
- 已检查 robots.txt 实际响应，而不只看控制台开关。
- 需要强制阻止的 crawler 使用 AI Crawl Control/WAF，而不是只写 Disallow。
- 搜索引擎 crawler 没有被误设为 Block 或 Charge。
- 已确认账号确实获得 Pay Per Crawl beta 权限。
- WAF、Bot Management 与收费规则不存在优先级冲突。
- 首页、sitemap 和发现路径保持免费可达。
- 登录、搜索、后台和隐私内容不会进入收费交付。
- 已设置费用、错误率和源站负载观察方式。
- 自定义 402 response 没有被误认为自动支付能力。