搜索照常、训练免谈：Cloudflare 如何拆开混合用途爬虫

网站过去很难清楚表达一个看似简单的要求：搜索引擎可以收录页面，但不要把内容用于训练 AI。问题不只在于 robots.txt 能否写规则，而在于部分大型平台使用同一个爬虫完成搜索索引、模型训练和 AI 问答取材。站长一旦封禁这个爬虫，搜索可见度也可能一起消失。

Cloudflare 推出的 Disallow AI Training 方案，试图把这些用途拆成不同的内容信号。它让站点声明“允许搜索、拒绝训练”，而不必把整个爬虫拒之门外。不过，这首先是一套用途声明机制，并不等同于不可绕过的访问控制。

真正要拆分的是“用途”，不只是 User-Agent

传统 robots.txt 主要围绕爬虫身份配置规则：

User-agent: GPTBot
Disallow: /

这种方式适合处理拥有独立 User-Agent 的 AI 爬虫。但如果某个平台让同一个机器人同时承担搜索索引和 AI 训练，站长只能允许或拒绝整个机器人，无法表达“页面可以进入搜索索引，但不能进入训练数据集”。

Cloudflare 的思路是增加用途级信号。以 Content Signals 的表达方式为例，策略可以写成：

Content-Signal: search=yes, ai-input=no, ai-train=no

三个维度分别表达不同意图：

• search=yes：允许内容用于传统搜索索引和结果展示。
• ai-input=no：不希望内容被实时提供给生成式 AI，或者用于检索增强生成等输入场景。
• ai-train=no：不允许内容用于模型训练或微调。

这比单纯屏蔽 User-Agent 更精确。需要注意的是，实际可用字段、默认值以及 Cloudflare 控制台生成的内容可能随产品版本调整，应以站点最终对外提供的策略文件为准。

启用之后，先验证公网看到的结果

如果站点已接入 Cloudflare，可以在相关爬虫或 AI 内容控制页面启用 Disallow AI Training。启用后不要只相信控制台状态，还要从公网检查 robots.txt，确认规则没有被源站配置、缓存或部署流程覆盖。

将下面的域名改成自己的站点即可执行：

DOMAIN=example.com

curl -fsS "https://${DOMAIN}/robots.txt"

可以进一步检查关键内容：

DOMAIN=example.com

curl -fsS "https://${DOMAIN}/robots.txt" \
  | grep -Ei 'content-signal|ai-train|ai-input|user-agent|disallow'

再查看响应头，排查缓存和内容类型问题：

DOMAIN=example.com

curl -sSI "https://${DOMAIN}/robots.txt" \
  | grep -Ei 'HTTP/|content-type|cache-control|age|cf-cache-status'

验证时至少回答四个问题：

1. robots.txt 是否能匿名访问并返回 200？
2. 搜索用途是否仍被允许？
3. AI 训练用途是否明确标记为拒绝？
4. Cloudflare 与源站是否同时生成 robots.txt，导致一方覆盖另一方？

同一个文件最好只有一个明确的配置来源。如果源站已经维护 robots.txt，启用边缘侧托管能力前应先比较两边内容，避免丢失原有的 Sitemap、目录屏蔽和特定爬虫规则。

仍可保留传统机器人规则作为补充

用途信号和 User-Agent 规则解决的是不同问题。对于身份独立、行为明确的 AI 爬虫，仍然可以使用传统规则直接禁止抓取。例如，可以这样实践：

User-agent: *
Allow: /

User-agent: GPTBot
Disallow: /

User-agent: CCBot
Disallow: /

Content-Signal: search=yes, ai-input=no, ai-train=no

这份示例表达了两层策略：普通搜索爬虫可以访问；列出的专用 AI 爬虫不能抓取；对于无法按身份拆分的混合用途爬虫，则通过 Content Signals 声明允许搜索、拒绝 AI 输入和训练。

上线前应根据业务调整名单，不要机械复制。某些站点可能允许 AI 搜索引用，但拒绝训练，此时可将意图调整为类似下面的组合：

Content-Signal: search=yes, ai-input=yes, ai-train=no

这种策略适合希望出现在 AI 搜索答案中、但不愿内容进入后续训练集的出版商。它也说明“AI 使用”不是单一开关：实时检索、摘要生成、模型训练和搜索索引对应不同的数据处理目的。

声明不等于强制执行

这套方案最重要的边界是：机器可读的偏好仍需要抓取方遵守。它不像登录鉴权、WAF 阻断或付费墙那样从网络层阻止内容获取。恶意爬虫可以忽略 robots.txt，也可能伪装 User-Agent，甚至通过住宅代理分散请求。

因此应按内容敏感程度选择控制手段：

• 公开文章和文档：可以使用用途信号表达授权边界，同时保留搜索可见度。
• 高价值原创内容：结合爬虫日志、速率限制、Bot 管理和异常流量告警。
• 付费或私有数据：使用身份认证和服务端授权，不要依赖 robots.txt。
• 涉及合同或版权要求的内容：保留策略发布时间、配置版本和访问日志，便于后续举证，但具体法律效力仍需专业判断。

还要持续观察搜索流量。混合用途爬虫是否真的按信号拆分处理，取决于平台支持和执行情况。启用策略后，可以对比搜索控制台中的抓取量、索引覆盖率和自然搜索流量，避免错误配置悄悄影响收录。

一份务实的上线清单

准备采用这项能力时，可以按以下顺序推进：

• 明确团队对搜索索引、AI 实时引用和 AI 训练的不同态度。
• 检查当前 robots.txt 的生成方和已有规则。
• 在 Cloudflare 中启用对应策略，并从公网验证最终文件。
• 保留独立 AI 爬虫的 User-Agent 阻断规则，形成分层控制。
• 监控搜索收录、爬虫请求量、缓存状态和异常来源。
• 对真正敏感的内容使用认证、授权或网络层阻断。

Cloudflare 解决的核心不是“彻底阻止 AI”，而是让网站拥有更细粒度的表达方式。对大多数内容站而言，这是一个值得启用的默认信号；但它只有与访问控制、流量监控和明确的内容授权策略结合，才能成为完整的防护方案。