Cloudflare 推出全新AI流量管理选项：区分搜索、智能体与训练爬虫，保护广告页面

一年前，我们宣布了第一个“内容独立日”，并赋予网站所有者夺回内容控制权的手段。爬虫与网站所有者之间维持了30年的协议——我们爬取你的内容，你获得流量引荐——已不复存在。人工智能正在攫取一切，却不回馈任何东西，这对网站所有者构成了生存威胁。因此，我们推出了“一键屏蔽AI爬虫”选项，以及一个按爬取次数付费的市场。

一年间，情况发生了很大变化。去年七月，围绕“AI爬虫”的讨论主要集中在未经补偿地阻止AI训练上，指向那种内容被用于模型训练、却未给网站所有者带来任何价值的零和交易。但如今，人们渴望更细致的处理方式：内容所有者仍然希望能够保护自己的内容，并且他们应该为自己努力创作、整理和分享的原创内容获得补偿。我们也知道，封锁内容并非放之四海而皆准的解决方案；网站所有者希望有更多选择，而不仅仅是“每次都屏蔽所有自动化程序”。

如果你运营一个小型网站，问题不仅仅在于有人可能用你的内容训练模型——更根本的是，用户一开始根本找不到你。因此，你不得不做出一个浮士德式的交易：要么出现在搜索结果中，让AI在你身上训练；要么冒着失去可发现性的风险。如果现有的搜索提供商对搜索和训练使用相同的爬虫，这就会不公平地让他们占据优势；而这种不公平优势又会激励新玩家采取规避手段，试图缩小竞争差距。

如今，AI可以是一切

如今，AI可以存在于一切之中。谷歌搜索已从由AI排序转变为一种完整的答案引擎，直接在结果页面上回答你的问题。而谷歌并非唯一如此——这正是“搜索”发展的方向。

我们可以争论今天什么才算“AI”的界限，结果却发现标准明天就变了。因此，我们更新的分类方法不再主要根据是否为“AI”来定义爬虫，而是会针对爬虫或智能体的行为提出更深层次的问题：它们在我的网站上做什么？它们存储了什么？它们将如何重新分享我的内容？

一套实用的分类体系

为了回答这些问题，我们需要一个更细致的视角——一套与客户关心的 AI 用例相契合的实用分类体系。因此，我们将讨论范围扩大到 AI 训练之外，聚焦于我们希望所有客户都能管理的三个 AI 用例：

• 搜索：任何收集或索引你内容的行为，以便之后能回答关于这些内容的问题。关键在于，搜索行为是主动建立你网站的数据库，以便日后响应查询。网站所有者应期望因此获得引荐流量或其他公平补偿。
• 智能体：代表个人自动执行操作的行为，通常是实时操作，以立即完成某项任务。这包括聊天获取爬虫（例如 ChatGPT-User）和浏览器使用智能体（例如驱动 Chrome 的 Gemini 或 Claude）。关键在于，它访问你的网络应用是为了完成一项工作，并且通常另一端有人在等待。
• 训练：爬虫获取你的内容以训练或微调模型。关键在于，你的数据被永久吸收到 AI 的基础架构中，以提升其能力。

网络上许多流行的爬虫都属于上述分类中的某一类；有些则同时属于多个类别。除了上述三种行为之外，我们还对许多其他行为进行了分类——包括广告验证、信息流获取以及智能体交易（下文会详述）。但我们认为，所有网站所有者都应该能够轻松管理针对这三个以AI为核心用途的访问权限。我们认为，机器人运营者应该将其爬虫分开，因为这能为网站所有者带来更高的透明度：让他们更好地理解某个特定爬虫为何访问他们的网站，并能更好地管理他们向该爬虫授予的访问权限。如果一家公司运行的自动化程序既用于构建搜索索引，又充当智能体，还收集数据来训练其模型，那么我们强烈建议该公司将该自动化程序拆分为三个独立的爬虫。

我们希望建立一个可扩展且能代表自动化流量世界演变的分类系统。追踪机器人的目的并非新鲜事，但我们的新分类法进行了一些更新，以更好地反映当今机器人流量的状况。最值得注意的是，我们希望认识到，具有多种目的的机器人应被追踪其所有目的，而不仅仅是其中之一。

管理AI流量的新选项

我们希望为Cloudflare网络上的所有网站所有者提供更多选项，以管理不同类型的AI流量。

我们之前宣布的“拦截AI机器人”托管预设，包含了那些为模型训练而爬取数据的单一用途机器人，如下所示：

2025年7月1日管理AI机器人流量的现有设置截图。

但并非所有AI用途都相同，我们希望我们的客户拥有他们所需的控制权。因此，我们推出了基于三大主要用例来管理AI流量的能力：搜索爬虫、智能体爬虫和训练爬虫。通过这些新选项，我们的客户——包括我们免费套餐的客户——可以更精细地调整他们管理AI机器人流量的方式。

2026年7月1日管理AI机器人流量的新选项截图。

设置新的默认值

2026年9月15日，我们将为这三类分类分别设置新的默认规则。对于所有新接入Cloudflare的域名，在展示广告的页面上，训练和智能体类别默认将被拦截，而搜索类别则默认保持允许。

广告是网站所有者希望用户访问并看到的一种信号——这是一种可盈利、能推动业务发展的内容。因此，在这些页面上，我们将人类注意力视为最终目标，并阻止可能干扰这种注意力的机器人（即训练和智能体机器人）。另一方面，搜索是最能自然引导访客回流的行为，我们认为允许搜索符合大多数网站所有者的利益。

另一项将于9月15日生效的变更是：多功能爬虫（特别是那些将搜索与训练结合在一起的爬虫）将根据其所有行为被允许或拦截，这符合我们要求对网站所有者保持透明的呼吁。由于默认规则将按最严格的适用规则执行，因此，对于选择了拦截训练（无论是通过管理AI流量的新选项，还是通过传统的拦截AI机器人服务）的客户，Googlebot、Applebot和BingBot等多功能爬虫将被拦截。

当然，客户的选择至关重要：如果网站所有者希望退出这些新的默认配置，他们可以在9月15日之前的任何时间，在其安全设置中轻松标记此选项，以确认他们不希望改变针对同时为搜索目的而爬取的训练爬虫的规则。随着9月15日的临近，我们还将持续通知客户即将发生的默认规则变更，以确保希望选择与默认设置不同规则的客户有机会进行更改。

BotBase：面向企业客户的新可视化平台

我们也很高兴地宣布，作为企业版机器人管理的一项新功能，我们将推出一次重大的可视化更新。随着Cloudflare跟踪机器人目录的不断增长，用户按合理分组管理这些机器人、并深入了解特定机器人更多细节的需求也日益增加。

推出 BotBase。BotBase 是我们新的数据库，用于追踪所有已知的机器人，包括已验证的机器人和智能体。该数据库在 Cloudflare 仪表盘上直接提供了我们整个机器人目录的全面、可搜索视图。我们首先解决可见性问题，但今年晚些时候，我们将扩展 BotBase，为你的网站上的已知自动化内容提供一个直接的控制中心。

借助这一新视图，企业版机器人管理客户可以查看所有已验证机器人/智能体的完整目录，以及它们在此更新分类体系中的归类位置——这是我们此前从未在 Cloudflare 仪表盘上动态展示过的视图。希望精准定位某个特定机器人的客户，也可以轻松筛选来自该机器人的所有流量，并复制检测 ID 以在安全规则中使用。所有这些功能现已上线，位于一个专用页面内，可通过机器人管理配置卡片访问。

在构建 BotBase 时，我们希望囊括所有能让我们在不同机器人之间构建可扩展、强有力洞察的信息片段。其中一个信息片段是我们更新后分类体系的基石，它基于机器人在你网站上可能执行的操作——即其行为。我们按如下方式划分这些分类，每个机器人会被归入一种或多种行为类别。

加粗斜体行表示所有客户均可使用的新可配置选项。

爬虫如何使用我的内容？

我们了解到，客户关心的另一个重要信息是机器人的内容使用方式——即机器人在抓取你的内容后，可能会保留和重新分享哪些内容。为了解决这个问题，我们正在为 Bot Management 客户构建一项功能，使其能够根据“内容使用”进行选择和屏蔽。该设置可设为以下三个级别之一，从限制最严到最宽松：

• 即时——可交互，但不存储和复用任何内容
• 引用（默认）——可索引、摘录并附上回链
• 完整——可总结和再现

这些值可以与机器人分类相结合，以表达精细化的规则，例如“允许所有用于搜索、SEO 和广告验证的机器人，但仅限于引用使用级别”。这使得网站所有者能够按合理的分组做出决策，而无需逐条管理单个机器人的规则。

为进一步支持这一点，从今天开始，我们正在测试一个新的信号 `use`，它扩展了 Content Signals 并存在于你的 `robots.txt` 文件中。这为第一版 Content Signals 的三个字段增加了一个可选的第四个字段，用于表达与上述相同的偏好：

• use=immediate
• use=reference
• use=full

与 `robots.txt` 文件中列出的所有其他条目一样，内容使用信号的值表示网站所有者的偏好，而非直接发出屏蔽指令。我们现在正在增加对此扩展的支持：所有已启用托管 robots.txt（该功能会在 `robots.txt` 中预先添加一条偏好，表明允许为搜索目的进行爬取，但禁止为训练目的进行爬取）的客户，其 `robots.txt` 中现在将额外添加 `use=reference` 这一偏好。

# Cloudflare Managed content with original Content Signals

User-agent: *
Content-Signal: search=yes,ai-train=no
Allow: /

包含原始 Content Signals 值的 Cloudflare 托管 robots.txt 内容。

# Cloudflare Managed content with the new content-use signal

User-agent: *
Content-Signal: search=yes,ai-train=no,use=reference
Allow: /

添加了参数后的 Cloudflare 托管 robots.txt 内容。

我们还开始跟踪 BotBase 中每个机器人的内容使用情况，一旦发现某个机器人滥用这些信号，它将失去“已验证”状态，从而不再被允许。目前，那些完整再现内容的机器人无法获得“已验证”状态。

机器人获得“已验证”状态意味着什么？

说到“已验证”，我们正在更新“已验证”的定义，以反映即将对默认允许和阻止基线所做的更改。此前，所有已验证的机器人默认都是允许的，这一点体现在我们基础的 Bot Fight Mode（机器人战斗模式）产品（用于阻止不需要的自动流量）以及面向企业版 Bot Management（机器人管理）客户的规则模板中。

从今天开始，我们正在调整这一规则以增加细微差别：未验证的机器人仍默认被阻止，但我们不再将“已验证”视为“默认允许”。现在，“已验证”标签使机器人能够在其相关类别下被允许，这意味着允许的类别（例如，允许搜索）将决定哪些内容可以访问网站。

为了平衡这一变化，我们正在开放成为已验证机器人的流程，并使其更加透明。要“验证”一个机器人，机器人运营者需要展示两点：你诚实地代表自己，并且你不会滥用这种诚实所赢得的访问权限。为了让机器人运营者更容易操作，我们目前正在为机器人运营者构建管理工具，以更好地确保他们被 Cloudflare 的分类系统准确描述（即将在近期公布）。

即将推出的平台预览截图，该平台直接面向已加入或希望加入 BotBase（Cloudflare 机器人目录的下一代产品）的机器人运营者。

尝试传递信任

还有一点：出现在你网站上的机器人（或智能体）越来越多地并非由其构建公司直接运营。像 Cloudflare 开发者平台这样的平台，同时为成千上万不同的运营者运行自动化任务，从企业到你从未听说过的开发者。你可能信任 Stripe，但你未必信任每一个将 Stripe 的工具整合到一个周末项目中的人。

我们将（网站所有者 → 机器人拥有公司 → 最终用户）这种情况称为传递信任问题，我们提议利用 RFC 7239 中定义的现有 Forwarded 标头，该标头随请求一起传递，并允许“代理组件披露在代理过程中丢失的信息”。

这与 X-Forwarded-For 对 IP 地址的处理方式类似，也类似于 X-Forwarded-Host 保留原始 Host 头部的方式。因此，当网站所有者说“允许这个操作者”时，无论该操作者是直接访问你，还是通过三层受信任的中介访问，这一偏好都将生效。更多详情可在我们的文档中找到，下方附有一个简要示例展示其格式。

Forwarded: for="openai"

结合上文讨论的 content-use 扩展，添加后的头部将类似如下所示，指定操作者声明将如何使用其访问的内容：

Forwarded: for="openai";use="reference"

这也与我们希望建立的激励模式相吻合。在 Cloudflare 背后超过 20% 的网站域名中失去受信任状态，是一种具有威慑力的惩罚。信任成为你可以随身携带、也可能失去的东西。

然而，随着机器人流量与人类流量日益融合，这种传递信任体系可能无法惠及那些无法承担被识别成本的用户。我们今天提出的措施有助于传递信任，但无法永远适用于整个互联网。小规模流量来源需要隐私保护，而那些希望履行自身隐私承诺的公司，应当能够探索面向智能体互联网未来的公平构建模块，例如私有速率限制。

现在就设定你的条款

这些都是朝着同一方向前进的小改变：网站所有者能更精细地控制谁在使用他们的内容，以及如何使用。我们认为，我们今天讨论并将很快实施的新默认设置，是鼓励透明度、更能反映世界发展趋势的。

当然，互联网的潮起潮落会持续在我们脚下变化，我们也会随之不断调整。但方向不会改变，因为这是 Cloudflare 从一开始就秉持的方向：一个建立在信任之上的网络生态。在这里，创造内容的人可以决定其内容如何被使用——在这里，坦诚说明你的用途，会让你获得更多访问权限，而非更少。

这些管理 AI 流量的新选项现已上线，所有现有客户均可在其站点设置中进行配置。还没用上 Cloudflare？立即免费开始使用，设置你想要的流量控制。

内容独立日快乐。