Cloudflare 扩展网站所有者的 AI 爬取控制
Cloudflare AI··作者 Bryan Becker
关键信息
Cloudflare 不再只把机器人简单分成“AI”或“非 AI”，而是按行为分类：它们是在索引内容以便日后回答问题，还是代表用户实时执行操作，或是把内容用于模型训练。公司还表示，它也会对广告验证、信息源抓取和代理式交易等其他行为进行分类，但希望所有客户都能轻松管理这三类以 AI 为中心的用例。
资讯摘要
Cloudflare 表示，这次更新是其“Content Independence Day”之后的延续；当时公司推出了“一键阻止 AI Bots”和“Pay-Per-Crawl”市场。Cloudflare 认为，过去 30 年里爬虫和网站之间“我抓取你，你给我引流”的关系已经失效，因为 AI 系统正在大量获取内容，却没有把价值回流给内容所有者。过去一年里，围绕“AI bots”的讨论也从单纯阻止 AI 训练，转向更细致地思考如何保护内容并为原创内容获得补偿。Cloudflare 还指出，完全封锁并不是许多网站的现实选择，尤其是小网站，因为它们仍然需要被用户找到。公司认为，很多发布者被迫在“保留搜索可见性”和“允许 AI 训练内容”之间二选一。Cloudflare 还警告，这种局面可能让现有搜索提供商占据优势，也会促使新玩家为了追赶而采取更隐蔽的抓取方式。
为了解决这些问题，Cloudflare 提出了一个更务实的分类法，重点关注 Search、Agent 和 Training 三类用法。Search 指的是收集或索引内容、以便之后回答问题的系统，网站所有者应当期待因此获得引流或其他公平补偿。Agent 指的是代表用户实时执行操作的自动化行为，包括聊天取数机器人以及像 Gemini 或 Claude 驱动 Chrome 这类浏览器代理。Training 指的是把内容抓取去训练或微调模型，内容会被永久吸收到模型能力之中。Cloudflare 表示，许多常见爬虫都属于这些类别中的一种或多种，它希望网站所有者能够分别管理这些访问，从而获得更高的透明度和控制权。
资讯正文
一年前，我们宣布了首个内容独立日（Content Independence Day），并赋予网站所有者重新夺回其内容控制权的手段。此前，爬虫与网站所有者之间维持了 30 年的交易——“我们抓取你们，你们获得引荐流量”——已经不再成立。AI 正在攫取一切却什么也不回馈，这对网站所有者构成了生存层面的威胁。因此，我们推出了一键式“阻止 AI 机器人”（Block AI Bots）选项，以及一个按抓取付费市场（Pay-Per-Crawl marketplace）。
一年过去了，很多事情都变了。去年 7 月，围绕“AI 机器人”的讨论主要集中在阻止 AI 训练且不给予补偿上，矛头指向那种“内容被用于模型训练，却没有任何价值回流给网站所有者”的输赢失衡交易。但如今，人们开始追求更多细致区分：内容所有者仍然希望能够保护自己的内容，而他们辛苦创作、整理和分享的原创内容也理应获得补偿。我们也知道，锁定内容并不是放之四海而皆准的解决方案；网站所有者想要的不只是“每次都阻止一切自动化”。
如果你经营的是一个小型网站，问题不仅仅是有人可能会用你的内容训练模型——更严重的是，根本没人能先找到你。于是你不得不与魔鬼做交易：要么出现在搜索结果里并允许 AI 在你的网站上训练，要么冒着失去可发现性的风险。这种做法会不公平地让既有搜索提供商占尽优势，因为它们如果用同样的机器人同时做搜索和训练，就会获得不当优势；而这种不公平优势又会激励新的竞争者在追赶差距时变得更隐蔽、更回避。
现在，AI 可以出现在任何地方。
如今，AI 可以融入任何事物之中。Google 搜索已经从“由 AI 排序”演变为一种“完整答案引擎”，能够直接在结果页上回答你的问题。而 Google 并不是唯一处于这种位置的公司——这正是“搜索”正在前进的方向。
我们当然可以争论今天什么才算“AI”，结果只是标准明天又会变。于是，与其主要把机器人定义为“AI”还是“非 AI”，我们更新后的分类方法将从更深层次的问题出发，关注机器人或代理的行为：它们在我的网站上做什么？它们存储了什么？它们又将如何再次分享我的内容？
一个务实的分类体系
为了回答这些问题，我们需要更细致的视角——一个与客户关心的 AI 使用场景相匹配的务实分类体系。因此，我们将讨论范围从仅仅是 AI 训练扩展开来，重点聚焦三种我们希望所有客户都能管理的 AI 使用场景：
搜索：任何会收集或索引你内容的行为，以便之后能够回答与之相关的问题。关键在于，搜索是在主动为你的网站建立数据库，以便日后响应查询。网站所有者应当预期因此获得引荐流量，或其他公平的补偿。
代理：自动化
一种行为，通常是实时代表某个人行事，以便立即把某件事完成。这包括聊天抓取机器人（例如 ChatGPT-User）以及使用浏览器的代理（例如由 Gemini 或 Claude 驱动 Chrome）。关键在于，它访问你的网站应用是为了完成一项任务，而且通常另一端有人在等待。
训练
：一种抓取器将你的内容用于训练或微调模型。关键在于，你的数据会被永久吸收到 AI 的底层架构中，以提升其能力。
网络上许多流行的抓取器都属于上述一种或多种分类；还有一些属于多种分类。我们还对上述三类之外的许多其他行为进行了分类——包括广告验证、Feed 抓取，以及代理式交易（下文将详细说明）。但我们认为，对于所有网站所有者来说，管理这三类以 AI 为中心的用例访问权限都应该很简单。我们认为，机器人运营方应该将其抓取器分开，因为这能为网站所有者带来更多透明度：让他们更好地理解某个抓取器为何访问自己的网站，也更好地管理自己授予该抓取器的访问权限。如果一家公司运行的自动化系统既构建
搜索
索引，又充当
代理
，还收集数据来
训练
其模型，那么我们强烈建议这家公司将这套自动化拆分为三个独立的抓取器。
我们希望有一套可扩展、且能代表自动化流量随时间演进现实的分类体系。跟踪机器人目的并不新鲜，但我们的新分类法带来了一些更新，更能反映当今机器人流量的状态。最值得注意的是，我们希望识别出具有多个目的的机器人，应按其所有目的进行跟踪，而不只是其中一个。
管理 AI 流量的新选项
我们希望向 Cloudflare 网络上的
所有
网站所有者，提供更多管理不同类型 AI 流量的选项。
我们此前宣布的“阻止 AI bots”管理预设，包括了单一用途的机器人，这些机器人会抓取数据用于模型训练，如下所示：
2025 年 7 月 1 日用于管理 AI 机器人流量的现有设置截图。
但并非所有 AI 用途都一样，我们希望客户拥有所需的控制能力。因此，我们推出了基于
三
大用例来
管理 AI 流量的能力：搜索、代理和训练
抓取器。借助这些新选项，我们的客户可以更精细地调整他们管理 AI 机器人流量的方式——包括 Free 套餐的客户。
2026 年 7 月 1 日用于管理 AI 机器人流量的新选项截图。
设置新的默认值
在 2026 年 9 月 15 日，我们将为这三种分类中的每一种设置新的默认值。
对于所有新接入 Cloudflare 的域名，
训练
和
代理
类别将在展示广告的页面上默认被阻止，
而
搜索
将继续默认允许。
广告意味着网站所有者希望有人访问该页面并看到它——这是一种可变现、并能为业务提供支撑的内容。因此，在这些页面上，我们把人类注意力视为最终目标，并会避开可能阻碍这种注意力的机器人（也就是 Training 和 Agent bots）。另一方面，Search 是最自然地把访问者带回网站的行为，我们认为允许这类行为符合大多数网站所有者的利益。
将于 9 月 15 日生效的另一项变化是，多用途爬虫（具体指那些将 Search 与 Training 结合起来的爬虫）将根据它们的所有行为来决定允许/阻止，这与我们对网站所有者透明度的要求一致。由于默认设置将由适用范围最严格的规则来执行，像 Googlebot、Applebot 和 BingBot 这样的多用途爬虫，将会被那些选择阻止 Training 的客户拦截（无论是通过新的“manage AI traffic”选项，还是通过旧版的 Block AI bots 服务）。
当然，客户选择至高无上：如果网站所有者想退出这些新的默认配置，他们可以在 9 月 15 日之前随时在 Security 设置中轻松标记这一点，这将确认他们希望对那些也会出于 Search 目的抓取内容的 Training 爬虫不作任何更改。随着 9 月 15 日临近，我们还会继续就即将到来的默认设置变化通知客户，以确保那些希望采用与默认设置不同配置的客户有机会进行选择。
BotBase：面向 Enterprise 客户的新可见性层
我们也很高兴推出一项作为 Enterprise Bot Management 新功能的重大可见性更新。随着 Cloudflare 已跟踪的 bot 目录不断扩展，人们也越来越希望以合理的分组方式管理这些 bots，并了解某个特定 bot 的更多细节。
现在推出 BotBase。BotBase 是我们全新的数据库，用于跟踪所有已知 bots，包括 Verified bots 和 agents。这个数据库在 Cloudflare 仪表板上直接提供了一个全面、可搜索的视图，覆盖我们整个 bots 目录。我们首先要解决的是可见性问题，但在今年晚些时候，我们将扩展 BotBase，使其能够成为你网站上已知自动化内容的直接控制中心。
借助这个新的视图，Enterprise Bot Management 客户可以查看所有 Verified bots/agents 的完整目录，以及它们在这一更新后的分类体系中被归入何处——这是我们此前从未在 Cloudflare 仪表板上动态展示过的视图。希望精确锁定某个特定 bot 的客户，也可以轻松筛选该 bot 的全部流量，并复制 detection ID 以用于 Security 规则。以上功能现在都已在一个专门页面中上线，可通过 Bot Management configuration card 访问。
在构建 BotBase 时，我们希望纳入所有能够帮助我们从一个 bot 延伸到另一个 bot，构建可扩展且强大的洞察能力的信息。其中之一是我们更新后分类体系的基石，它基于 bot 可能在你的网站上做什么——也就是它的行为。
我们如下所示对这些分类进行区分，每个 bot 都会被归入其中一种或多种行为。
Bot classification
行为与用途
搜索
抓取网站以帮助其出现在搜索引擎结果中
代理
代表人类访问页面的用户指向型代理
训练
抓取以训练或微调模型
交易
代表用户进行结账操作
数据收集
包括价格抓取、竞争情报收集和第三方分析
安全测试
包括漏洞扫描和渗透测试
SEO
SEO 抓取、网站审计、可访问性检查
广告验证
广告位验证、广告欺诈检测
社交 / 链接预览
用于社交平台和消息应用的链接预览
源订阅抓取
包括 RSS 阅读器、播客聚合器和新闻订阅源机器人
监控与运维
包括正常运行时间监控、webhook 和健康检查
加粗并带斜体的行表示所有客户现在都可用的新可配置选项。
抓取器如何使用我的内容？
我们从客户那里听到的另一条重要信息，是机器人对内容的使用方式——也就是机器人在抓取你的内容之后，可能会保留并再次分享哪些内容。
为了解决这一点，我们正在为 Bot Management 客户构建能力，使其可以基于“内容使用”来选择并进行阻止。这个设置可以设为三种级别，从限制最少到最宽松依次为：
immediate
——可以交互，但不存储也不复用任何内容
reference
（默认）——索引、摘要，并回链
full
——总结并复现
这些值可以与机器人分类结合使用，以表达更细致的规则，例如：“允许所有用于搜索、SEO 和广告验证的机器人，但内容使用级别只能到 reference。”这让网站所有者能够按合理的组别做决定，而不必逐个机器人分别管理规则。
为了进一步支持这一点，从今天开始，我们正在测试一个新的信号 use，它扩展了 Content Signals，并位于你的 robots.txt 中。它在第一版 Content Signals 的三个字段基础上增加了第四个可选字段，用来表达与上文相同的偏好：
use=immediate
use=reference
use=full
与 robots.txt 文件中列出的其他所有项目一样，内容使用值表达的是网站所有者的偏好，而不是直接发出阻止指令。我们现在正在为这一扩展添加支持：所有已经启用 managed robots.txt 的客户——也就是在 robots.txt 中前置表明“用于搜索的抓取可以，但用于训练的抓取不可以”这一偏好的客户——现在还会在他们的 robots.txt 中加入额外的偏好 use=reference。
# 带有原始 Content Signals 的 Cloudflare Managed 内容
User-agent: *
Content-Signal: search=yes,ai-train=no
Allow: /
Cloudflare managed robots.txt 在原始 Content Signals 值下的内容。
# 带有新的 content-use 信号的 Cloudflare Managed 内容
User-agent: *
Content-Signal: search=yes,ai-train=no,use=reference
Allow: /
Cloudflare managed robots.txt 在增加该参数后的内容。
我们也开始在 BotBase 中跟踪每个 bot 的内容使用情况；一旦我们发现某个 bot 滥用这些信号，它就会失去“Verified”状态，从而不再被允许。今天，完整复现内容的 bot 不能拥有 Verified 状态。
对于一个 bot 来说，什么叫做 Verified？
说到“Verified”，其定义正在更新，以反映即将到来的默认允许和默认阻止基线的变化。此前，所有 Verified bot 都是默认允许的，这一点体现在我们用于阻止不受欢迎自动流量的基础 Bot Fight Mode 产品中，也体现在我们为 Enterprise Bot Management 客户提供的规则模板中。
从今天开始，我们正在对这一点作出更细致的调整：未通过验证的 bot 仍然会被默认阻止，但我们不再将 Verified 视为“默认允许”。现在，Verified 标记意味着某个 bot 可在其相关类别下被允许，也就是说，允许的类别（例如允许 Search）将决定什么可以访问网站。
为了平衡这一变化，我们正在开放成为 Verified bot 的流程，并让这一过程更加透明。要“Verify”一个 bot，bot 运营方需要证明两件事：你诚实地代表自己，且不会滥用这种诚实所带来的访问权限。为让 bot 运营方更容易做到这一点，我们目前正在为 bot 运营方构建管理工具，以更好地确保他们能通过 Cloudflare 的分类系统得到准确呈现（将在不久的将来公布）。
这是一张即将推出的平台预览截图，该平台是直接为 BotBase 的参与者、或希望加入 BotBase 的 bot 运营方打造的——BotBase 是 Cloudflare Bots Directory 的下一代产品。
试验传递性信任
还有一点：如今站在你门前的 bot（或 agent）越来越不是由打造它的公司在运行。像 Cloudflare Developer Platform 这样的平台，会同时为成千上万不同的运营方运行自动化任务，覆盖从企业到你从未听说过的开发者。你可能信任 Stripe，但你未必信任把 Stripe 的工具接入某个周末项目的每一个人。
我们把（网站所有者 → bot 所属公司 → 终端用户）这种情形称为传递性信任（transitive trust），并提议利用 RFC 7239 中定义的现有 Forwarded header。该 header 会随请求一起传递，并允许“代理组件披露在代理过程中丢失的信息”。
这与 X-Forwarded-For 在 IP 地址上的作用类似，也与 X-Forwarded-Host 用于保留原始 Host header 的作用类似。因此，当网站所有者说“允许这个运营方”时，这一偏好将继续生效，无论该运营方是直接接入，还是通过三层仍受信任的中介接入。更多细节可参见我们的文档，下面给出一个简短示例来说明其格式。
Forwarded: for="openai"
在加入上文讨论的 content-use 扩展后，header 的新增内容大致会像下面这样，用于指定运营方声称会如何使用其访问到的内容：
Forwarded: for="openai";use="reference"
这也与我们希望培育的激励机制相吻合。对于超过 20% 受 Cloudflare 保护的网站域而言，失去受信任状态，是一种具有实质威慑力的惩罚。信任会变成一种你可以随身携带、也可能失去的东西。
然而，随着机器人流量与人工流量相互交织，这种传递信任的体系，可能无法覆盖那些负担得起被识别身份的用户之外的人群。我们今天提出的这些措施有助于传递信任，但它们并不可能永远适用于整个互联网。小规模流量来源需要隐私，而希望维护自身隐私承诺的公司，也应该能够探索面向未来的智能代理互联网的公平构建模块，例如私有速率限制。
今天就设定你的条款
这些都是朝同一方向迈进的小变化：网站所有者能够更好地掌控谁在使用他们的内容，以及如何使用。我们相信，今天讨论并将很快实施的新默认设置，能够鼓励透明度，也更能反映世界正在前进的方向。
当然，互联网的潮起潮落仍会继续在我们脚下变化，而我们也会随着它不断调整。但方向不会改变，因为这正是 Cloudflare 最初的出发点：一个围绕信任构建的网络生态。在这里，创造内容的人可以决定这些内容如何被使用；一个诚实说明自己所做之事，会换来更多访问权限，而不是更少的网络。
这些用于管理 AI 流量的新选项现已上线，所有现有客户都可以在他们的 zone Settings 中进行配置。还没加入 Cloudflare？
立即免费开始
，今天就设置你想要的流量控制。
内容独立日快乐。
来源与参考
收录于 2026-07-02