Cloudflare重划AI爬虫边界

Cloudflare 最近宣布重做 AI 流量管理逻辑，不再简单判断一个机器人“是不是 AI”，而是根据它抓取内容后的用途，将流量拆成搜索、AI 代理和模型训练三类。网站所有者可以分别放行或屏蔽三类流量，免费计划也能使用这些选项。

这次更新的关键不是增加了几个开关，而是 Cloudflare 承认，过去那个笼统的“屏蔽 AI 机器人”按钮已经不够用了。搜索引擎正在生成答案，AI 助手需要实时访问网页，训练爬虫又可能长期保存内容；三者都带有 AI 属性，但对网站流量、版权和商业模式的影响完全不同。

按照 Cloudflare 在官方博客公布的时间表，新的默认策略将于 2026 年 9 月 15 日生效。对于届时新接入 Cloudflare 的域名，系统将在展示广告的页面上默认屏蔽训练和 AI 代理流量，同时继续允许搜索流量。

AI 流量控制是什么

**AI 流量控制是按照自动化程序使用网页内容的目的，对其访问权限进行分类管理的机制。**它与传统机器人管理的区别在于，后者主要关心访问者是不是机器人、是否恶意；前者进一步追问它抓取内容是为了建立搜索索引、即时回答用户问题，还是训练未来的模型。

Cloudflare 此前提供的一键式“阻止 AI 机器人”托管预设，重点针对抓取训练数据的机器人。这种做法适合希望全面保护内容的出版商，却不适合仍然依赖搜索分发、又希望接入 AI 助手流量的网站。

新的三分类体系试图解决这组矛盾：

| AI 流量类别 | Cloudflare 对其用途的界定 | 典型访问方式 | 对网站的潜在价值 | 主要风险 | 9月15日新域名默认值 | |---|---|---|---|---|---| | 搜索 Search | 建立或更新搜索索引，并向用户提供搜索结果 | 周期性抓取页面、链接和元数据 | 带来搜索曝光与外部点击 | 搜索结果直接生成答案后，点击率可能下降 | 允许 | | AI 代理 AI Agent | 代表用户实时访问、理解或操作网页 | 围绕一次任务临时读取页面 | 可能带来高意图访问或完成交易 | 内容被直接摘要，用户不再进入原站 | 广告页面默认屏蔽 | | 训练 AI Training | 收集并保存内容，用于训练或改进模型 | 大规模、重复、批量抓取 | 对网站通常缺乏直接流量回报 | 内容被长期吸收，难以追踪后续使用 | 广告页面默认屏蔽 |

**搜索类爬虫是以建立搜索索引和展示搜索结果为主要目的的自动化程序。**传统 Web 生态长期依靠“允许抓取，换取流量”的契约运转，网站把页面交给 Google、Bing 等搜索服务，后者通过搜索结果把用户送回原站。

**AI 代理是代表具体用户即时获取或处理网页信息的自动化程序。**例如，用户要求助手比较三款产品，代理可能临时访问官网、读取参数并整理答案；它与训练爬虫最大的区别，是访问通常对应一个正在发生的用户任务，而不是为未来模型批量积累语料。

**训练爬虫是为了训练、微调或改进机器学习模型而收集网页内容的自动化程序。**它对内容网站最具争议，因为一次抓取可能让模型长期获得知识，却不保证署名、引用或后续访问。

真正需要警惕的是“多用途爬虫”

**多用途爬虫是同时承担搜索索引、AI 功能或模型训练等多个任务的同一机器人身份。**Cloudflare 将从 9 月 15 日起按照该爬虫的全部用途执行策略，并采用最严格的适用规则，而不是只看它访问当下声称要完成的任务。

这项规则比三分类开关更值得站长注意。Cloudflare 明确点名，Googlebot、Applebot 和 Bingbot 等机器人可能同时具有搜索与训练用途；如果网站选择允许搜索、阻止训练，最严格策略仍可能导致这些多用途爬虫被拦截。

换句话说，“禁止拿我的内容训练模型”不再必然是一个与 SEO 相互独立的开关。对于依赖 Google 或 Bing 收录的媒体、电商和工具网站，错误配置可能让搜索可见度一并受损。

| 配置情形 | 单用途搜索爬虫 | 单用途训练爬虫 | 同时用于搜索和训练的爬虫 | |---|---:|---:|---:| | 搜索允许、训练允许 | 放行 | 放行 | 放行 | | 搜索允许、训练阻止 | 放行 | 阻止 | 按最严格策略阻止 | | 搜索阻止、训练允许 | 阻止 | 放行 | 按最严格策略阻止 | | 搜索阻止、训练阻止 | 阻止 | 阻止 | 阻止 |

**Cloudflare 选择最严格策略，是在用访问损失换取用途透明度。**如果一个平台希望自己的搜索爬虫继续被放行，就需要更清楚地拆分搜索、生成式回答和训练行为，而不能让同一身份获得一揽子权限。

这个方向有合理性，但代价也很现实。Googlebot 这类爬虫过去相当于网站必须接待的“大客户”，Cloudflare 现在把选择权交回站长，同时也把误伤搜索流量的责任交给站长。对个人博客来说，这可能只是少几个索引页面；对依赖自然搜索获客的商业网站来说，可能直接影响收入。

robots.txt表达偏好，边缘网络负责执行

**robots.txt 是网站向爬虫声明抓取偏好的文本文件，但它本身通常不具备强制执行能力。**守规矩的机器人会读取并遵守，伪装身份或无视规则的抓取程序则可以直接绕过，因此不能把修改 robots.txt 等同于真正完成封禁。

Cloudflare 正在扩展 Content Signals，让启用托管 robots.txt 的客户表达更细的内容使用意愿。官方给出的信号包括：

• search=yes：允许内容用于搜索；
• ai-train=no：不允许内容用于 AI 训练；
• use=reference：允许将内容作为参考资料使用。

**use=reference 表示网站允许系统参考内容来回答问题，但不代表允许将内容纳入模型训练。**这试图在“完全禁止 AI 使用”和“任由内容进入训练集”之间增加一个中间选项，适用于愿意被引用、却不愿永久让渡训练权的创作者。

不过，Content Signals 仍然只是偏好声明，而不是新的互联网法律或通用授权协议。它能否发挥作用，最终取决于抓取方是否识别、接受并遵守这些字段；真正的访问阻断仍要依靠 Cloudflare 在边缘网络上的机器人识别和安全规则。

BotBase先解决“看不见谁在爬”

**BotBase 是 Cloudflare 建立的已知机器人与自动化代理目录。**Enterprise Bot Management 客户现在可以在控制台中检索已验证机器人，查看它们属于搜索、代理还是训练类别，并复制检测 ID，用于配置更具体的安全规则。

BotBase 当前首先解决的是可见性，而不是完全自动化的控制。Cloudflare 表示将在 2026 年晚些时候继续扩展 BotBase，把它变成管理站点已知自动化流量的直接控制中心。

| 能力 | 适用范围 | 当前状态 | 实际用途 | |---|---|---|---| | 搜索、代理、训练三分类 | 包括 Free 在内的所有计划 | 正在推出，9月15日切换新默认值 | 分别允许或屏蔽不同用途的流量 | | 多用途爬虫最严格策略 | 使用相关 AI 流量策略的客户 | 9月15日生效 | 防止同一爬虫以搜索身份兼做训练 | | BotBase 机器人目录 | Enterprise Bot Management | 目录与检索功能已上线 | 查询机器人分类、流量和检测 ID | | BotBase 直接控制中心 | Enterprise Bot Management | 计划于今年晚些时候扩展 | 集中管理已知自动化程序 | | Content Signals | 启用托管 robots.txt 的客户 | 扩展支持中 | 声明搜索、训练和参考使用偏好 |

**BotBase 的价值建立在 Cloudflare 的网络可见性之上。**根据 Cloudflare 的产品资料，其服务覆盖约 20% 的 Web 资产，机器人管理系统每天参考约 2470 亿条威胁信号，并结合机器学习、行为分析和指纹识别判断访问者身份。

这些数字说明 Cloudflare 比单个网站更容易观察爬虫的跨站行为，但并不意味着识别可以达到 100% 准确。公开身份、固定 User-Agent 和可验证 IP 的机器人相对容易分类，使用住宅代理、无头浏览器或频繁切换基础设施的抓取程序仍可能被识别为普通访客。

这不是封掉AI，而是重新谈分发条件

**Cloudflare 的核心判断是，过去三十年的“抓取换点击”契约已经失效。**生成式搜索可以在结果页直接回答问题，AI 助手也能把多个网站的内容压缩成一段结论，网站承担了创作和托管成本，却未必再获得访问量。

Cloudflare 在 AI Crawl Control 的产品材料中称，生成式 AI 爬虫可能为了带来一次推荐访问而抓取网页数千次。即使不讨论版权，这也是一笔不对称的资源账：服务器承担抓取负载，内容被转化为答案，但广告展示、订阅转化和品牌触达可能都没有发生。

**彻底封闭内容也不是大多数网站的最优解。**一个新品评测网站可能愿意被搜索引擎索引，也愿意让购物代理在用户询价时读取页面，却不愿历史文章被批量收集进训练集；一个文档站可能希望 AI 编程助手实时引用最新文档，因为这会增加开发者采用率，但仍然反对离线复制整个知识库。

三分类开关正好对应这些场景。它把原来的“允许所有机器人”或“屏蔽所有 AI”两极选择，变成更接近内容业务实际需求的权限矩阵。

网站现在应该做什么

**网站管理员应在 9 月 15 日之前完成一次 AI 流量与搜索依赖审计。**最重要的不是立即打开所有阻止选项，而是先弄清楚哪些爬虫正在访问、它们带来了多少真实用户，以及业务能承受多大的搜索收录波动。

建议重点检查以下事项：

1. **核对当前 AI 机器人预设。**已经使用旧版“阻止 AI 机器人”功能的网站，需要确认迁移到新分类后是否仍符合原意。
2. **区分搜索曝光与直接内容消费。**不要把所有来自 Google、Microsoft 或 Apple 的自动化流量视为同一种用途。
3. **单独评估多用途爬虫。**如果自然搜索是主要获客渠道，阻止训练前应先确认是否会连带阻断 Googlebot、BingBot 或 Applebot。
4. **观察广告页面策略。**Cloudflare 将新域名的默认阻断范围与展示广告的页面关联，但站长仍应在控制台核实页面识别和实际命中情况，避免只根据公告推测。
5. **把 robots.txt 当声明，不要当防火墙。**需要强制阻断时，应使用边缘规则和机器人管理能力。
6. **建立变更前后的基线。**至少记录抓取请求量、带宽消耗、搜索索引量、自然搜索点击和 AI 引荐访问，方便判断策略效果。

**免费开放三分类控制是这次更新最实用的部分。**过去精细机器人管理通常属于企业安全产品，而 Cloudflare 现在把最关键的用途开关下放给 Free 用户，意味着个人博客、开源文档站和小型媒体也能参与内容访问规则的制定。

我们的判断：方向正确，但默认值只是谈判筹码

**Cloudflare 这次更新的方向是正确的，因为“AI 机器人”已经不是一个有实际管理价值的单一类别。**搜索引擎、任务代理和训练系统对网站的价值交换完全不同，把它们塞进同一个黑名单既粗暴，也容易误伤。

这套方案最强的地方是执行层。robots.txt 只能表达愿望，Cloudflare 可以在请求到达源站前直接放行或阻断；对于缺乏安全团队的小网站，这比自行维护 IP 列表、User-Agent 规则和行为模型可靠得多。

这套方案最大的风险则是多用途爬虫。最严格策略会迫使大型平台公开拆分用途，却也可能让普通站长先承受 SEO 和收录损失。Cloudflare 把权力还给网站的同时，并没有替网站消除选择成本。

更长远看，搜索、引用、代理执行和训练可能还需要继续拆分。仅仅允许“参考”并不能回答署名位置、引用长度、缓存期限、商业使用和收益分配等问题，按抓取付费也仍未成为 Web 的通用标准。

**这次更新因此不是 AI 内容版权问题的终点，而是基础设施层开始拒绝默认无限抓取。**当占据可观 Web 流量入口的 Cloudflare 把用途分类、访问控制和内容信号放进同一套产品里，AI 公司以后要获得高质量内容，可能需要提供更清楚的身份、更单一的用途，以及更可验证的回报。

参考与延伸讨论

• Reddit：检索 Cloudflare AI traffic options 相关讨论——查看开发者和站长对三分类策略及搜索误伤风险的讨论。
• Reddit：检索 Content Signals 与 robots.txt 讨论——了解社区对 ai-train、search 和 use=reference 等声明的看法。