Cloudflare 禁止 AI 训练：将搜索可见性与模型训练分离

Cloudflare 推出了 Disallow AI Training，这项新控制功能旨在保留搜索索引，同时拒绝同一爬虫将内容用于模型训练。此前，发布商面对用途混合的机器人时，往往只能做出非此即彼的选择：要么接受两种用途，要么彻底屏蔽该爬虫。

这一变化涵盖 Applebot、Googlebot 和 Bingbot。Cloudflare 将它们归类为混合用途爬虫，因为每一种都可同时服务于搜索和 AI 相关用途。如今，若这些机器人的运营方提供控制选项、报告机制，并保证退出训练不会降低传统搜索可见性，Cloudflare 便将其称为“Accountable”。

这一认定在 Cloudflare、Apple、Google 和 Microsoft 之间建立了共同的运营模式，但并未形成具有约束力的技术标准。新系统结合了控制台设置、robots.txt 指令、公司承诺，以及 Cloudflare 对其他训练爬虫实施的拦截。

这正是核心权衡所在。发布商获得了更简洁的方式来表达授权意愿，而无需从搜索结果中消失；但保护措施在很大程度上仍依赖爬虫运营方是否尊重这一选择。

Cloudflare Disallow AI Training 改变默认选择

Cloudflare 正将一个负担过重的屏蔽决策，拆分为针对搜索、训练和用户指令型代理的独立选择。

Cloudflare 的 AI 爬虫控制按行为对自动化活动分类，而非将所有与 AI 有关的请求混为一谈。搜索爬虫构建索引，训练爬虫为模型开发收集材料，代理则代表用户获取页面。

这些类别之所以重要，是因为它们带来的经济影响不同。搜索引擎通常会展示链接，从而将用户引向原始网站。训练过程则可以吸收信息，却不会立即带来访问。代理可能获取页面并交付其内容，而用户甚至从未打开该页面。

一个爬虫可能同时属于多个类别。Googlebot、Applebot 和 Bingbot 就是重要例子，因为它们的搜索功能使发布商难以屏蔽它们。移除其访问权限，最终可能影响索引、内容新鲜度和可发现性。

Cloudflare 先前的控制机制通过将混合用途爬虫排除在部分训练拦截之外，来应对这一问题。这保护了搜索可见性，但也让发布商无法通过同一设置直接拒绝其训练用途。

新的 crawler control model 将 Disallow AI Training 作为中间选项引入。它通过 robots.txt 发布禁止训练的偏好，保留 Accountable 混合用途爬虫的搜索访问权限，并拦截其他与训练相关的爬虫。

Cloudflare 表示，由 Amazon、Anthropic、Meta 和 OpenAI 运营的纯训练爬虫可以被屏蔽，而不会影响其独立的搜索爬虫。这些公司针对不同用途使用不同机器人，因此更易在网络层面实施限制。

Cloudflare 也在改变其更严格设置的含义。“Block”和“Block on pages with ads”现在适用于混合用途爬虫，包括 Googlebot、Applebot 和 Bingbot。因此，选择其中任一选项都可能同时影响搜索和训练。

这一差异使配置的影响更为重大。Disallow AI Training 在保留搜索访问的同时表达有限的偏好；Block 则直接拒绝该爬虫，无论某次具体请求是用于搜索还是训练。

现有配置正迁移至新控制项。此前使用通用 AI 屏蔽选项的域名，通常会在保留搜索访问的同时，将训练偏好迁移至 Disallow AI Training。已有细粒度策略的域名，其实际选择也会被延续。

对于新的广告支持型域名，Cloudflare 建议允许搜索、禁止训练，并在展示广告的页面上屏蔽代理。对于不含广告的新域名，则会获得限制较少的建议，即允许这三类活动。

这些预设只是建议，并非永久规则。网站所有者可在引导设置期间，或之后通过 Security Settings 修改它们。这些控制项适用于所有 Cloudflare 套餐，并在域名级别运行。

结果是一个更清晰的决策树。发布商可以允许常规索引、拒绝训练，并为代理制定单独政策。这一结构更准确地反映了自动化系统如今与网站交互的方式。

它也让错误配置更容易诊断。如果发布商选择 Block，之后失去爬虫访问权限，这一后果便直接源于所选设置。Disallow AI Training 的目标更为狭窄：在拒绝模型开发用途的同时保留搜索。

这不仅是一次机器人开关的改名。它将控制单位从单纯的爬虫身份，转变为身份、公开用途和运营方行为的组合。

为什么混合用途爬虫让发布商承受压力

矛盾在于，能够带来宝贵搜索流量的爬虫，也可能为完全不同的商业目的收集内容。

开放网络的传统交换关系相对容易理解。发布商允许搜索引擎抓取页面，搜索引擎则回馈链接、摘要和潜在访客。广告、订阅、销售和读者关系，都依赖其中一部分用户实际访问网站。

生成式 AI 让这种交换变得复杂。模型可以在训练期间使用收集的材料，而 AI 答案可能在读者访问任何被引用来源之前就满足其查询。因此，搜索、模型开发和答案生成创造的是不同形式的价值。

Cloudflare 自身的测量结果说明了发布商为何担忧。该公司报告称，在 12 个月期间，训练占已分类 AI 抓取活动的 80%。在随后的六个月观察中，训练占比升至 82%，搜索占 15%，用户操作占 3%。

这些数据描述的是 Cloudflare 观察并分类的流量，而非整个网络。尽管如此，它们仍表明，训练活动可能主导抵达内容提供商的自动化需求。

屏蔽纯训练爬虫的发布商面临的计算相对可控。该屏蔽可阻止不受欢迎的收集行为，同时不会移除主要搜索索引器。GPTBot 和 OAI-SearchBot 等独立机器人使这些用途更容易区分。

混合用途爬虫带来了更棘手的问题。如果同一爬虫同时服务于搜索和训练，那么基础设施层面的拦截无法判断内容到达运营方后将如何被使用。屏蔽访问能保护材料，却也会移除搜索功能。

允许访问能保留内容发现能力，却需要另一种机制来限制后续用途。这正是 Cloudflare Disallow AI Training 设置试图填补的空白。

Cloudflare 最初通过 Content Signals 着手解决这一问题，这是一种建议放置在 robots.txt 中的词汇体系。content signal policy 区分了三种声明用途：search、ai-input 和 ai-train。

搜索信号涵盖索引和传统搜索结果，不包括 AI 生成的摘要。ai-input 信号涉及 AI 系统的实时使用，包括检索和 grounding。ai-train 信号则针对模型训练和微调。

因此，一个网站可以发布 search=yes 和 ai-train=no。如果所有者尚未决定生成式答案应如何使用内容，也可以不指定 ai-input。

这种分离很重要，因为缺少偏好不应被解释为同意或拒绝。Cloudflare 的政策将被省略的信号视为中性，而非猜测发布商的意图。

不过，Content Signals 只是偏好的表达，并不是能够在物理上阻止爬虫下载页面的屏障。Cloudflare 此前曾建议发布商，在需要技术强制执行时，将此类信号与机器人控制或防火墙规则结合使用。

新的 Accountable 认定试图连接这些层面。它识别出 Cloudflare 所称已提供或承诺提供特定控制和透明度的爬虫运营方。相关要求包括训练退出选项、AI 摘要退出选项、URL 级别可见性，以及对传统搜索排名的保护。

Apple、Google 和 Microsoft 通过现有功能与限时承诺的不同组合达到这一门槛。该认定并不意味着它们的实现完全相同，而是意味着 Cloudflare 认为每个运营方都已接受相同的基本责任。

这也给其他爬虫运营方带来压力。希望获得广泛访问权限的公司，现在可以依据一套公开的授权、检查和搜索中立性基准进行比较。分离机器人身份仍是满足该基准的一种方式，但已不再是唯一途径。

发布商也面临新的运营责任。搜索可见性、AI 训练、答案生成和代理访问，如今都需要单独的政策。一个“屏蔽 AI”的决定已无法涵盖所有商业权衡。

依靠页面浏览量盈利的新闻网站，可能会在广告页面上同时拒绝训练和代理访问。零售商即便 AI 引荐流量较低，也可能重视其中更有价值的潜在客户。文档网站则可能欢迎实时 AI 检索，同时拒绝长期模型训练。

关键问题不再是 AI 机器人究竟好还是坏，而是哪一种用途足以证明访问的合理性、会向发布商回馈何种价值，以及该用途能否得到验证。

Apple、Google 和 Microsoft 共享的是模式，而非同一种实现

这三家公司支持相同原则，但其控制机制在技术上仍不均衡，推出时间线也各不相同。

Apple 已允许发布商通过 Applebot-Extended 处理训练用途。网站所有者可在 robots.txt 中禁止该 user agent，同时继续允许 Applebot 的常规搜索功能。

Apple 的文档称，Applebot-Extended 偏好不会影响网站在搜索结果中的展示方式。它也支持与生成式输出相关的页面级机制，包括 nosnippet 及付费墙内容标签。

这些工具尚未提供 Cloudflare Accountable 框架中的全部要素。Cloudflare 表示，Apple 尚缺乏针对这一用途的 URL 级检查机制。据报道，Apple 已分享正在开发中的解决方案细节，预计将于明年推出。

因此，当前的 Applebot controls 实现了搜索与训练之间的有效分离，但对访问后发生情况的可见性仍不完整。Cloudflare 正接受其弥补这一差距的承诺。

Google 使用类似的扩展模型。发布商可屏蔽 Google-Extended，而无需屏蔽 Googlebot。Google-Extended 是一个控制标记，管理某些生成式 AI 用途，而非一个始终自行发出请求的独立爬虫。

这一细节很重要。Googlebot 仍可能为搜索而获取内容，而 Google 会通过 Google-Extended 偏好决定材料是否可用于受涵盖的 AI 系统。发布商通过政策控制后续用途，而非依赖独立的网络身份。

Google 表示，通过 Google-Extended 选择退出不会影响网站被收录或在 Google Search 中的排名。其训练退出指南说明了 Googlebot 与 Google-Extended 之间的关系。

Google 还提供与生成式搜索体验相关的搜索表现报告和控制选项。Cloudflare 表示，Google 正在开发与 Google-Extended 相关的更多 URL 级透明度功能，预计将在数周内推出。

在这一特定机制下，Microsoft 是三者中支持最不完整的一家。Bing 支持细粒度的网站管理员控制，发布者也可使用 NOARCHIVE meta 标签来限制缓存内容或展示内容的某些用途。

Microsoft 表示，NOARCHIVE 不会将页面从搜索排名中移除。网站所有者还可以使用 Bing Webmaster Tools 进行内容移除和 URL 管理。

不过，Bingbot 尚未通过 robots.txt 自动遵守 Cloudflare 的域级禁止训练偏好。Cloudflare 表示，Microsoft 正在开发这一能力，目标是在 2027 年初推出。

在此之前，选择“禁止 AI 训练”不会通过这一新工作流自动将预期限制传达给 Bing。希望立即限制 Bing 的发布者，仍需使用 Microsoft 现有工具及页面级元数据。

Microsoft 将其 AI 控制选项描述为一种在保留搜索发现能力的同时，限制内容如何出现在生成式体验中的方式。不过，Cloudflare 的统一开关目前尚未与这些控制功能完全打通。

这一实施缺口是此次发布最重要的注意事项。Cloudflare 将 Applebot、Googlebot 和 Bingbot 归入同一个“Accountable”标签之下，但目前只有 Apple 和 Google 提供了针对训练偏好的特定扩展用户代理路径。

Microsoft 的纳入部分建立在一项较早的承诺之上。这或许适合用于确立合作标准，但发布者应理解，已可执行的限制与承诺中的兼容性并不相同。

这一共享模型还取决于各运营方如何界定“训练”。预训练新模型、微调现有系统、为实时回答提供依据，以及生成搜索摘要，都是不同的活动。“禁止训练”的选择并不必然拒绝所有由 AI 介导的使用方式。

Cloudflare 明确将 AI 输入和 AI 摘要视为两个不同的问题。这避免了一项偏好悄然覆盖无关用途，但也意味着，这项新控制功能的范围比其简洁的仪表板标签所暗示的更窄。

发布者可以拒绝模型训练，同时仍有资格出现在 AI 生成的搜索摘要中。另一家发布者则可以使用运营方特定的摘要控制，同时允许训练。这些选择可能带来不同的流量和归因结果。

因此，Accountable 框架最好被理解为一份最低限度的契约。它要求运营方区分用途、遵守偏好、提供检查能力，并避免因拒绝训练而在传统搜索中惩罚发布者。

它并未让 Apple、Google 和 Microsoft 在技术上变得可互换，也不保证这些公司提供的每项 AI 功能都属于同一种退出机制。

其即时价值在于整合。Cloudflare 客户可以在同一处表达共同偏好，而各运营方则将该偏好映射至其现有或即将推出的控制功能。

其长期价值取决于这些映射能否变得足够透明，使发布者能够在 URL 层面进行审计。

该设置是一种同意信号，而非合规证明

Cloudflare 简化了指令，但网站发布该指令并不能证明每一种下游使用都已停止。

这一限制始于 robots.txt。该文件被设计为一种自愿遵守的爬虫协议，而非访问控制系统。遵守协议的爬虫会读取它并调整行为。除非另有控制措施阻断流量，否则无视该协议的运营方仍可请求公开可访问的页面。

当 Cloudflare 识别出某个爬虫时，可以在其网络边缘执行相关决定。这使得封锁比偏好信号更具约束力。但执行依赖于可靠的身份识别，而用户代理字符串可能被无关机器人复制。

经过验证的机器人计划可通过将请求来源与运营方提供的信息核对来降低这一风险。加密认证可以提供更强的证明，但其在爬虫市场中的采用仍不完整。

即使是经验证的请求，也只能说明谁获取了页面，未必能揭示其内容之后的所有用途。爬虫运营方必须在内部将搜索索引、模型训练、答案生成和其他处理相互隔离。

Cloudflare 的 Accountable 要求通过报告和承诺来弥合这一信任缺口。URL 级可见性应有助于发布者了解哪些页面可用于训练，以及内容如何出现在搜索中。

关键词是“应当”。Apple 的检查系统仍在开发中，Google 的附加工具尚待推出，而 Microsoft 对域级 robots.txt 的支持目标是 2027 年初。

因此，这一 designation 结合了当前能力与未来承诺。Cloudflare 并未声称这四项要求如今都拥有完全相同的生产级实现。

发布者也不应将“禁止 AI 训练”理解为一项普适性的法律解决方案。版权例外、合同条款、司法辖区差异以及既往采集仍是独立问题。一项新偏好无法追溯性地从现有模型中移除材料。

该设置规范的是参与运营方和 Cloudflare 所实施的未来爬虫行为。它并不确认先前收集的副本已经删除，也无法界定训练后的模型可能如何保留或复现信息。

另一个不确定性在于分类。Cloudflare 基于运营方披露的信息及其他观察到的信息，将行为归为搜索、训练和 Agent。爬虫所声明的用途可能发生变化，而一项服务也可能支持多种产品。

当分类滞后于产品变化时，一项策略可能允许超出发布者预期的活动。随着时间推移，透明的变更日志和独立监控将与最初的仪表板设计同样重要。

AI 摘要暴露出更大的缺口。训练决定内容是否参与模型开发；摘要则决定当前内容是否被转化为可能降低访问需求的答案。

Cloudflare 引用了研究，显示 AI 摘要已在搜索行为中相当常见。一项搜索行为研究发现，当出现 AI 摘要时，用户点击搜索结果链接的可能性更低。

这与训练并非同一个问题。发布者即使成功拒绝训练，在搜索产品总结新近索引的材料时，仍可能失去访问量。

Cloudflare 表示，Accountable 运营方必须直接提供 AI 摘要退出选项，并最终通过 Cloudflare 提供该选项。其下一目标是更细粒度地控制摘要可包含多少内容。

该计划承认二元同意机制的弱点。允许附带清晰链接的简短引文，与允许取代原始来源的详尽答案，并不相同。两者在技术上都可能被视为摘要使用。

商业模式也会改变可接受的平衡。依赖广告的发布者需要访问量，因为展示量支撑其收入。零售商或许可以接受较少访问，只要 AI 引流能带来更多购买。订阅制发布者可能比起原始点击量，更重视归因和读者认知。

Cloudflare 曾引用第三方估算，认为 AI 引流的转化率可能高于传统搜索引流。这些数据因数据集和方法论而异，因此不应被视为对流量损失的普遍补偿。

真正的衡量难题在于因果关系。发布者必须知道哪个爬虫访问了某个 URL、哪个产品使用了它、是否出现摘要、展示了多少内容，以及互动是否带来了访问。

如今，大多数组织并不具备这条完整链路。服务器日志会显示请求，搜索控制台则显示展示量和点击量。单独依靠任何一方，都无法确定内容如何流经某项 AI 产品。

这些新控制功能在实现全面问责之前，先提升了发布者的自主权。它们让发布者能够声明更细化的策略，并对不符合 Accountable 例外条件的爬虫施加更强的封锁。

它们并未消除监控需求。发布者应在更改设置后检查搜索覆盖情况、爬虫日志、引流模式以及主要 AI 产品的公开输出。

对于维护研究资料、文档或机构记忆的团队而言，爬虫策略只是信息治理的一层。一个可搜索的知识库能够在外部平台对公开版本进行摘要时，仍在内部保留来源语境。

审慎的结论很直接。Cloudflare 已创建了一个可信的控制界面，但合规仍是由技术执行、自愿标准、运营方政策和未来透明度构成的体系。

将某个爬虫称为 Accountable 提高了预期标准，但并未让底层的信任问题消失。

三个信号将显示这一新模型是否奏效

下一项考验在于 Cloudflare 的共享政策能否带来可衡量的行为，而不是是否有更多公司认同其表述。

第一个信号是 Microsoft 承诺在 robots.txt 中支持域级禁止训练偏好。Cloudflare 表示，这项能力目标是在 2027 年初推出。

一项可用的实现将弥合三家混合用途爬虫运营方之间当前最大的缺口。它将使同一项 Cloudflare 设置能够向 Bing 传达拒绝训练的意愿，而无需单独部署 NOARCHIVE 或执行移除工作流。

若出现延迟，将削弱 Accountable designation 的意义，因为其最重要的参与者之一仍需依赖手动或页面级替代方案。该实现还应明确 Microsoft 的哪些 AI 用途属于“训练”，以及哪些用途仍受单独控制机制约束。

第二个信号是 Apple 和 Google 提供 URL 级报告。发布者需要的不只是确认域级偏好存在；他们还需要知道哪些页面被访问、哪些用途获准，以及该偏好是否改变了后续处理。

Google 针对 Google-Extended 承诺的新增功能提供了一项早期测试。Apple 计划中的检查能力则提供了更长期的测试。有效的报告应足够具体，能够将爬虫访问与搜索表现及 AI 可见性进行比较。

泛泛的仪表板计数只能提供有限问责。页面级记录、易懂的用途标签以及稳定的历史数据，将强化 Cloudflare 关于发布者能够作出知情决策的主张。

第三个信号是 Cloudflare 在 AI 摘要控制方面的工作。训练退出仅解决发布者冲突的一部分。即使不存在模型训练许可，搜索生成的答案仍可能影响流量。

Cloudflare 计划控制摘要中显示多少内容，这比简单的退出选项更具雄心。它需要运营方一致地解释共享偏好，并提供足够的数据，让发布者评估结果。

成功将强化 Cloudflare Disallow AI Training 背后的更广泛原则：访问应当目的明确、可衡量，并可由内容所有者随时调整。失败则意味着，发布者仍需在每一家搜索和 AI 服务提供商之间辗转应对各自独立的控制机制。

当前务实的做法，是将此次发布视为一次政策升级，而不是一项一劳永逸的保障。网站所有者应检查每个域名迁移后的设置，尤其是此前启用过广泛 AI 阻止选项的站点。

他们应确认 Search 是否仍被允许，以及 Training 是否已显示为 Disallow AI Training，而非 Block。选择完整的 Block 可能会阻止 Applebot、Googlebot 和 Bingbot，这与公开表达“不用于训练”的偏好会产生截然不同的结果。

团队还应记录允许或拒绝每一类别访问的原因。搜索、训练和智能代理服务于不同目的，因此政策应反映网站的营收模式及其与受众之间的关系。

任何变更后，都应监测爬虫响应和索引情况。搜索覆盖率下降可能表明选错了设置，或有其他防火墙规则覆盖了这一偏好。

同样的检查也应覆盖重要子域名。文档、支持中心、博客和应用页面即使共享同一母品牌，也可能处于不同的配置之下。

Cloudflare 此次发布之所以重要，是因为它以更贴近现实的选择取代了人为设定的二元对立。一个网站不应仅仅为了继续出现在传统搜索索引中，就不得不将素材贡献给模型开发。

不过，这套系统的可信度仍将取决于可验证的结果。Microsoft 必须完成其集成，Apple 和 Google 必须提供有用的检查机制，而 Cloudflare 必须将概要控制转化为发布者能够衡量的实际能力。

目前，Cloudflare Disallow AI Training 为网站所有者提供了更清晰的指令，以及一条更稳妥的中间路径。接下来的问题是，最大的爬虫运营商是否会让这项指令变得足够可观察，从而值得信任。

检查你的域名的三项爬虫政策，记录预期结果，并在每次变更后关注搜索覆盖率。如果流量保持稳定，同时训练访问量下降，那么这一共享模式就通过了首个实践检验。