Cloudflare拆开搜索与AI训练授权

Cloudflare 这次更新把网站所有者最难处理的一组选择拆开：内容可以继续被搜索引擎索引，但同一个混合用途爬虫不能因此自动获得 AI 训练授权。它比过去“屏蔽 AI”的总开关更细，也更贴近出版商实际担心的分发损失。

可核实的新事实来自 Cloudflare 在 2026 年 9 月 15 日发布的文章。它宣布 Disallow AI Training 设置，并给出 Accountable mixed-use crawler operators 标识。Cloudflare 的原文说法是，Apple、Google、Microsoft honor or have committed in a specified time frame to honor this setting；中文必须保留这个状态差异，区分已遵守与限期承诺。

这条新闻的边界也很清楚。Disallow AI Training 当前解决的是 Training 控制，不是 Search 或 Agent 控制。Cloudflare还说，到明年初，它的目标是让站点所有者控制多少内容可被纳入 AI summaries；这仍是 goal，当前交付范围不包括摘要比例控制。

对出版商、品牌站和开发者社区而言，实际影响在于谈判位置。过去 robots.txt 只表达偏好，边缘阻断才负责执行；现在 Cloudflare 试图把偏好发布、爬虫识别、用途分类、违规阻断和公开报告放进同一套基础设施里，让“我允许搜索但不同意训练”成为机器可读、平台可执行、运营商可被追责的一句话。

9月15日具体改了什么

Cloudflare 的文章从一个长期矛盾起笔：网站需要搜索可发现性，但不一定同意自己的内容被拿去训练模型。问题最难的部分在混合用途爬虫。一个 crawler 同时服务 Search 和 Training 时，站点如果拒绝它，可能连搜索索引也一起失去；如果放行它，又担心训练用途不受控制。

Disallow AI Training 的新增价值就在这里。Cloudflare写道，这个设置让站点“stay indexed for search while refusing to let that same crawler train on your content”。中文应写成“保留搜索索引，同时拒绝同一爬虫把内容用于训练”，而不是“Cloudflare全面封禁AI爬虫”。

技术路径是 Bot Preference Sync。站点在 Cloudflare 控制台设置 Training 为 Disallow AI Training 后，Cloudflare会在 robots.txt 中发布适用的 no-training preference。对被 Cloudflare 归为 Accountable 的混合用途爬虫，它们仍可为了搜索访问站点；对其他训练爬虫，Cloudflare会在边缘阻断。Cloudflare特别点名，Amazon、Anthropic、Meta 和 OpenAI 的相关 training-only crawlers 可被阻断，且这种阻断不影响搜索。

同时，Block 的含义也改变了。Cloudflare说，Block 和 Block on pages with ads 过去不适用于混合用途爬虫，因为那可能影响搜索可发现性；现在有了 Disallow AI Training，Block 和 Block on pages with ads 会适用于所有 training crawlers，包括 mixed-use crawlers。换句话说，如果站点想让 Applebot、Bingbot、Googlebot 完全离开，应该选择 Block；如果目标是停止训练但保留搜索，就应该选择 Disallow AI Training。

Cloudflare还在9月15日公布了迁移和默认配置变化。旧的 Block AI Bots 将被更细的 Search、Training、Agent 控制取代。Managed Robots.txt 将迁移到 Bot Preference Sync。对此前设置过粒度控制的域名，Cloudflare说会保留 practical effect；此前 Training 选择 Block 或 Block on pages with ads 的情况，会迁移到 Disallow AI Training。

这张表说明了本次新闻的关键状态迁移。Cloudflare在搜索和训练之间增加了一个中间层，让“让搜索进来”和“把训练挡住”可以分开设置。

Accountable到底承诺了什么

Cloudflare把 Accountable 定义成一组当前能力和有时间约束的承诺。一个 bot operator 要达到这个标识，需要满足或承诺满足四项要求：让站点通过 robots.txt 或类似标准退出 AI training；让站点退出 AI summaries，并且未来可通过 Cloudflare 设置；提供 URL-level visibility，说明哪些页面可被训练使用，并给出内容在搜索中出现的指标；保证退出 AI training 不影响传统搜索结果。

这里最容易误写的是“已经完成”和“承诺完成”的区别。Cloudflare原文说，Accountable designation recognizes both capabilities available today and concrete commitments to deliver them。它还写道，Apple、Google、Microsoft all demonstrate that they meet the qualifications to be Accountable，并补充 each combines capabilities available today with time-bound commitments for those still in development。中文应理解为：三家公司被 Cloudflare 认定满足 Accountable 资格，但其中部分能力仍处于按时间表交付的承诺状态。

具体到 Applebot，Cloudflare说站点可通过 robots.txt 中针对 Applebot-Extended 的 Disallow rule 表达训练退出。站点也可用 nosnippet 指令表达 AI summaries 偏好，并可把内容标记为 paywalled content 以排除 generative output。Applebot 尚未提供 URL-level inspection 工具；Cloudflare称已与 Apple 团队会面，对方分享了明年的 in-progress solution。Apple还表示，disallowing training does not impact search ranking。

Googlebot 的状态更接近“已有控制加近期补齐”。Cloudflare说，站点可通过 Google-Extended 的 Disallow rule 退出训练，Google在 webmaster portal 提供把站点内容排除出 generative search results 的 toggle，并提供 search results 和 AI summary results 的 metrics and reporting。Google还向 Cloudflare 分享了已上线和近期推出的控制，以及与 Google-Extended 相关的额外 URL-level transparency tools，Cloudflare称这些工具预计在数周内推出。Google文档也说明，Google-Extended does not impact a site’s inclusion in Google Search nor is it used as a ranking signal in Google Search。

Microsoft 的边界更需要保守。Cloudflare说，Bingbot通过 Webmaster Tools 提供granular controls and transparency，站点可用 NOARCHIVE meta tag 表达 AI training preferences。Microsoft 正在扩展这些能力，并正在构建在 domain 或 site level 也尊重 robots.txt no-training preference 的机制，目标是 early 2027。在这个支持上线前，选择 Disallow AI Training 不会自动通过 robots.txt 向 Bing 传达 no-training preference；Cloudflare明确说，这与此前 Training Block 对 Bingbot 这类混合用途爬虫不适用的实际行为相同。

这个差异很重要。Accountable不是一个纯粹的技术标准认证，更像 Cloudflare 面向站点所有者和爬虫运营商建立的市场规则：被列入者可以继续享受搜索抓取通道，但需要接受偏好、透明度和报告义务；未提供透明度的训练爬虫不会得到同样的信任假设。

为什么robots.txt本身不够

Cloudflare在文中直接写到，robots.txt directive alone cannot solve this problem。robots.txt仍有表达价值，但它只能发布文本偏好，不能识别谁在抓取、判断为什么抓取，也不能拦住忽略偏好的 crawler。

IETF aipref 草案说明了另一侧背景。draft-ietf-aipref-vocab-08 定义了一套表达数字资产被自动处理系统使用偏好的词汇，覆盖训练和 AI 模型使用。它同时提醒读者，该草案仍是 working document，contents do not reflect consensus of the Working Group。换言之，行业正在把“用途偏好”变成标准化语言，但仍没有最终 RFC 结论。

draft-ietf-aipref-attach-05 则关注偏好如何附着到内容上。它定义了两类机制：HTTP Content-Usage header field，以及 Robots Exclusion Protocol 中的 Content-Usage rule。草案的目标是让自动系统在获取内容的同一流程里获取内容使用偏好。这与 Cloudflare 的做法方向一致：把偏好从法律声明或页面说明，转成爬虫可自动读取的协议层信号。

区别在执行层。IETF草案回答“如何表达偏好”，Cloudflare回答“如果对方不遵守，谁来识别和阻断”。Cloudflare自称能发布偏好、识别爬虫、分类用途、阻断忽略偏好的爬虫，并在 Radar 上报告各运营商实际行为。这里的判断链条比单纯修改 robots.txt 长：它需要 Cloudflare 的 bot classification、Verified bots、BotBase 和客户控制台设置共同工作。

Bot Preference Sync 是中间环节。Cloudflare在背景文章中说，该功能把站点在AI bot配置里对 Search、Agent、Training 的选择同步到 robots.txt。如果站点已有 robots.txt，Cloudflare会把新增内容 prepended 到既有文件前面，并保留原有 Disallow directives。对于网站管理员，这减少了一个常见断点：控制台规则和公开 robots.txt 口径不一致。

但这套机制也留下两个开放边界。第一，robots.txt 或 Content-Usage 仍是偏好表达，不是全球统一执法机制；Cloudflare能在其网络边缘阻断它能识别的请求，但无法替所有网络空间执行。第二，站点级偏好不等于授权合同。发布商如果有个别授权、收入分成或白名单安排，仍需要更细的例外逻辑，而不是只依赖类别级开关。

Agent和AI summaries被放在下一阶段

这次更新没有把 Agent 访问纳入 Disallow 设置。Cloudflare解释说，Agents 不会制造与 mixed-use crawlers 相同的搜索可发现性权衡，互联网也还没有成熟的 directive 来表达对 agents 的 Disallow preferences。因此目前没有给 Agents 加 Disallow setting，Cloudflare表示会随着 ai-prefs 等标准成熟重新评估。

这个边界对企业站点很关键。用户导向的 agent 访问，例如 chat fetch bots 或 browser-use agents，可能代表真实用户完成任务；它既不同于传统搜索索引，也不同于离线训练抓取。简单阻断会降低可访问性和转化机会，完全放行又可能冲击广告展示、付费墙、反爬策略和安全审计。

AI summaries 是另一条更直接的商业线。Cloudflare把它写成 next focus，并强调 training 和 summaries 是不同问题。Training 关系到内容是否被用于构建模型；summaries 关系到用户是否还会访问原站点。Cloudflare引用研究和市场数据说明影响混合：更多用户在搜索顶部阅读摘要，阅读摘要后更可能结束搜索；但 AI Search 带来的访问可能转化率更高。

这些数字不能直接当成所有站点的通用结论。Cloudflare自己的表述也很克制：That is not inherently good or bad。广告驱动的出版商可能更看重访问量，零售商可能更看重少量高意图访客。Cloudflare的立场是提供 visibility and control，而不是替客户决定是否允许摘要。

最需要保留原文时态的是下一步。Cloudflare写的是：By early next year, our goal is to let you control how much of your content is included。准确中文是“到明年初，Cloudflare的目标是让站点所有者控制有多少内容被纳入摘要，并且在Cloudflare上设置一次，而不是分别找每个运营商设置”。这不是今天已经上线的功能，也不是Cloudflare保证所有运营商届时都会完成跨平台标准化。

对站点所有者的操作含义

如果站点目标是保留搜索，同时拒绝训练，Cloudflare给出的新路径是 Training 选择 Disallow AI Training。这个设置会通过 Bot Preference Sync 发布 no-training preference，并让 Accountable mixed-use crawlers 继续为了搜索索引访问。这里的关键词是 keep search，而不是 block search。

如果站点目标是完全拒绝 Applebot、Bingbot、Googlebot 这类混合用途爬虫，Cloudflare明确说应选择 Block。选择 Block 会让它们 entirely stopped，search included。这会影响搜索发现，因此不能把 Block 写成“更强版Disallow AI Training”。

如果站点依赖广告，Cloudflare的推荐配置会更保守。文章说，自9月15日起，新域名会根据是否通过广告赚钱获得两类预设配置。广告收入依赖真实用户看到页面；训练会把访问替换为答案，agents 也可能抓取页面但没有人看到广告。因此广告支持站点的默认建议会更严格，不过客户可在 onboarding 或之后随时修改。

已有客户大多不需要手动迁移。Cloudflare说，几乎所有情况下当前设置会自行沿用。此前没有使用过 Search、Training、Agent 粒度控制的域名，会按 legacy Block AI Bots 设置迁移；此前已经配置粒度控制的域名，会保留 practical effect。这里也不能写成“所有客户配置不变”，因为 Cloudflare同时改变了 Block 对 mixed-use crawlers 的适用范围。

后续时间表

三家Accountable运营商的承诺兑现，是这条新闻最直接的后续检验。Apple的URL级inspection方案、Google的Google-Extended URL级透明工具、Microsoft的robots no-training支持分别处在不同时间状态。只要其中任何一项拖延，Accountable就会从“控制面”退回“信任声明”。

站点端要用流量数据复核影响。Cloudflare和运营商都强调训练退出不影响传统搜索结果，但站点所有者关心的是实际抓取频率、索引覆盖、Search Console或Webmaster Tools报告，以及AI summary展示。这个层面需要站点端数据，而不是只看公告文本。

标准化仍在路上。IETF aipref文档仍是Internet-Draft，明确写着不代表工作组共识。Cloudflare可以先把产品做出来，但要让跨运营商的一次设置长期有效，仍需要HTTP header、robots.txt directive、词汇定义、错误处理和合规报告逐步收敛。

Agent访问会成为下一轮争议。Cloudflare暂时没有给Agents提供Disallow设置，这是合理边界，也是未来争议区。用户授权的agent访问可能带来商业转化，也可能绕开广告展示和页面交互。Search、Training、Agent 被拆成三类之后，内容控制争论很可能会从“训练是否允许”转向“代表用户的agent应该遵守哪些商业和技术边界”。