Cloudflare 给已验证机器人加「持续问责」：身份之外，还要用长期行为来证明可信

Cloudflare 在 2026 年 10 月 16 日的官方博客中公布一套针对已验证机器人的持续评估机制：在身份之外，持续考察机器人是否遵守站点偏好，包括是否遵守 robots.txt、收到 HTTP 429 后是否降速。观察结果会转成可解释的信任区间，并计划向所有客户开放、由客户自行设定信任阈值。

这次发布的是什么

Cloudflare 在 2026 年 10 月 16 日的官方博客里公布了一套针对「已验证机器人」的持续评估机制。官方的说法是：验证一个机器人的身份只解决了「你是谁」，并不代表它接下来会守规矩；这套系统要解决的是第二个问题——能不能一直信任它。

按照官方描述，成为 Cloudflare 已验证机器人大致需要满足三条：准确且安全地表明身份、只做声明要做的事、不进行滥用行为。身份这一环此前已经由 Web Bot Auth 承担——机器人用它对请求签名，BotBase 再以开放格式把这些身份编目起来。这次补上的是行为那一环。

系统会持续观察两个信号：机器人是否遵守站点公布的偏好（以 robots.txt 为主，对齐 RFC 9309），以及它在收到站点的直接反馈后是否调整行为（典型是收到 HTTP 429 之后有没有放慢或暂停）。这些观察会汇总成一个可解释的信任区间，官方强调它反映一段时间内的行为一致性，而不是对某个机器人或其运营方的永久判定。

可用性与限制

• 上线状态：官方称这套系统目前已在内部用于评估已验证机器人的表现，处于积累历史与打磨口径的阶段。
• 开放计划：官方称未来会面向所有 Cloudflare 客户开放，由客户自己选择用哪个信任阈值来决定如何处理已验证机器人的流量；时间与具体形态以官方页面为准。
• 公开范围：官方称计划把相关评分放到 Radar 上公开，并会继续扩展评估维度；当前尚未公开，以官方页面为准。
• 评估维度：初期只看两个信号——是否遵守指令、是否响应直接反馈；官方称后续会扩展。
• 判定性质：官方明确它不是永久判定，也不是对运营方的定性，而是对一段时间内行为一致性的描述。
• 适用对象：面向 Cloudflare 的已验证机器人体系，未走验证流程的自动化流量不在本次公布的范围内。
• 产品关系：它与 Bot Preference Sync、Bot Management 构成一个闭环——前者帮站点发布偏好，后者让站点决定如何处理流量。
• 费用与版本：不同套餐下的可用范围以官方页面为准，本文不对具体套餐做判断。

主要功能

• 身份签名：机器人用 Web Bot Auth 对请求签名，身份可核验
• 身份编目：BotBase 以开放格式记录已验证机器人
• 偏好合规评估：考察机器人流量与站点 robots.txt 是否长期一致
• 反馈响应评估：收到 HTTP 429 后是否降速、暂停，纳入行为记录
• 可解释的信任区间：给出行为一致性的范围，并说明由哪些观察得出
• 阈值可控：后续由站点自行设定信任阈值来决定如何处理流量

技术原理

这套机制的两个信号都不复杂，但指向了爬虫治理里最容易扯皮的两个地方。

第一个是 robots.txt。官方的说法是：机器人应当查阅并遵守站点公布的偏好，对齐 RFC 9309 的口径。系统看的不是单次越界——偶发的孤立违规可能只是配置错误或缺陷——而是重复出现的、无视站点偏好的行为模式。官方还补了一句：robots.txt 规定的是「不该做什么」的下限，没写到的并不等于允许。

第二个是 HTTP 429。429 是站点要求访客降低请求速率的直接信号，有时还带着该等多久的提示。系统看的是机器人在收到这个信号之后有没有调整：持续降速或暂停会提高信任，反复无视则会降低。

把这两类观察合起来，得到的不是一个简单的黑白名单，而是一个随时间变化的信任区间。官方把它与 Bot Preference Sync、Bot Management 串成闭环：站点发布偏好，系统观察机器人是否长期遵守，站点再据此决定这些流量怎么被处理。

实际体验

这篇不提供第一人称实测，只给出站点方可以自己做的核查步骤。

第一步先理清自己公布的偏好。检查 robots.txt 是否真实反映了你的意图——很多站点的规则是多年累积下来的，实际允许的范围可能比想象中宽。系统的评估基准就是这个文件，基准写错了，后面的判断都会偏。

第二步开启并核对限流信号。确认站点在高负载时能正确返回 HTTP 429，并且带上重试时间的提示；如果一个机器人从未收到过 429，系统就少了一个重要的观察维度。

第三步先看流量结构再谈策略。用现有的机器人管理或日志工具，把已验证机器人与未声明的自动化流量分开看，别把所有机器流量当成同一类问题处理。

第四步等能力开放后再设阈值。按官方说明，阈值由站点自行选择，过严会误伤正常的检索与引用流量，过松则失去意义；建议先用观察模式跑一段时间，再定策略。

项目地址与获取方式

官方公告：https://blog.cloudflare.com/verified-bots-accountability/

相关产品：官方指向 Bot Management 用于管理自动化流量，Bot Preference Sync 用于把站点公布的偏好与配置策略对齐。

公开数据：官方称相关趋势与已验证机器人名录可在 Radar 上查看。

接口与配置入口以 Cloudflare 官方控制台与官方文档为准，请以官方页面当前的表述为准。

适合谁用

• 内容站点与媒体：关心检索与引用流量是否遵守自己的抓取规则
• 有 API 与文档的开发者平台：需要区分善意自动化与滥用流量
• 做搜索与问答产品的团队：自己的爬虫也需要一套可证明的合规记录
• 运维与治理岗位：需要把「是否放行」从拍脑袋改成可配置的阈值
• 不必用的人：站点规模很小、几乎不受自动化流量影响的个人页面

常见问题

这和之前的「已验证机器人」有什么不同？

此前主要解决身份问题：机器人用 Web Bot Auth 签名，身份可核验。这次补的是行为问题——持续考察它是否真的遵守站点偏好，并把结果转成可解释的信任区间。

信任区间是永久判定吗？

官方明确说不是。它描述的是一段时间内行为的一致性，会随观察结果变化，也不是对机器人或其运营方的定性结论。

现在就能在控制台里用吗？

按官方说法，目前系统已在内部用于积累历史与调整口径，并计划向所有客户开放、由客户自定阈值。可用时间以官方页面为准。

站点方现在能做什么？

先把 robots.txt 与限流响应做对。系统的评估基准就是站点公布的偏好与 429 反馈，这两处写得含糊，后续的策略就没有可靠依据。

robots.txt 没写到的，是不是就允许？

官方的说法是否定的：robots.txt 规定的是「不该做什么」的下限，没写到的并不等于被允许，站点仍可通过其他信号表达不欢迎继续访问。

相关工具与内容

• 分类：其他 AI 工具、AI 搜索、AI 智能体
• 工具页：Perplexity、秘塔 AI 搜索、夸克
• 同题材快讯：Cloudflare 与 OpenAI 的 AI 发现试点、Cloudflare 推出 Web Search API
• 延伸阅读：为智能体配置联网搜索