Cloudflare 为 BotBase 推出运营方工具:机器人提交、审核与身份维护进入可追踪阶段
Cloudflare 于 2026-08-28 推出 BotBase for Operators,新增在 Dashboard 中提交、查询、编辑与取消机器人身份的运营方工具,使机器人登记流程从黑箱转为可追踪可修正。该工具支持多标签行为声明、部分自动化审核与提交历史查看,但最终是否允许访问仍由网站所有者通过安全规则决定。
Cloudflare 于 2026-08-28 推出 BotBase for Operators,新增在 Dashboard 中提交、查询、编辑与取消机器人身份的运营方工具,使机器人登记流程从黑箱转为可追踪可修正。该工具支持多标签行为声明、部分自动化审核与提交历史查看,但最终是否允许访问仍由网站所有者通过安全规则决定。
Cloudflare 于 2026 年 8 月 28 日宣布,为 BotBase 机器人目录推出面向运营方的新工具。机器人和 AI Agent 的开发者现在可以在 Cloudflare Dashboard 中提交机器人、查看审核状态、了解被拒原因,并维护已经提交的身份信息。
这项更新的重点并不是让网站自动放行更多机器人,而是把过去近似“黑箱”的登记流程变成可追踪、可修正的运营流程。Cloudflare 同时强调,机器人是否被识别为 Verified、是否能够访问某个网站,最终仍由网站所有者依据自身规则决定。
提交流程从“提交后等待”转向可追踪
Cloudflare 表示,新入口位于 Dashboard 的 Protect & Connect → Application Security → BotBase,所有客户都可以从 Dashboard 访问这一面向运营方的提交体验。此前,提交表单位于 Manage Account → Configurations,运营方提交后缺少统一的进度查询和维护入口。
新的 BotBase for Operators 分为三个部分:
| 功能 | 作用 |
|---|---|
| Bots directory | 浏览、搜索和筛选 Cloudflare 已经追踪的机器人与 Agent |
| Submission form | 提交新的机器人身份和行为信息 |
| Submission history | 查看账户提交记录、审核状态和处理结果 |
在 Submission history 中,每条提交会显示三种状态:Waiting for review 表示已收到并进入队列;Accepted 表示已经审核并纳入目录;Rejected 表示提交信息需要调整,Cloudflare 会同时给出原因和可执行的修正步骤。
Cloudflare 称,在此之前,运营方往往需要通过支持渠道询问机器人是否已经完成审核。新工具将状态和处理结果直接放回 Dashboard,也允许运营方在目录中筛选当前账户提交的机器人。
机器人身份信息可以编辑和取消
机器人身份并非一成不变。例如,运营方可能更换 IP 列表地址,或者从 IP 白名单验证转向使用 Web Bot Auth 对请求进行签名。Cloudflare 表示,过去遇到这类变化,运营方通常需要重新填写表单并创建一条新的提交记录;现在则可以直接编辑已经提交的信息。
仍处于等待审核状态的提交也可以被取消。Cloudflare 鼓励运营方持续维护准确的身份信息,因为稳定的用户代理、IP 列表、反向 DNS 或 Web Bot Auth 签名,是机器人获得和保持 Verified 状态的重要组成部分。
不过,Verified 并不意味着网站必须允许机器人访问。Cloudflare 的文档将 Verified bot 定义为能够透明说明自身身份和行为、遵守 robots.txt 与抓取指令、维持合理请求速率且没有被观察到规避网站偏好的机器人或 Agent。网站所有者仍可以通过安全规则或 AI 流量选项阻止、限制或区别对待相关流量。
新表单不再要求机器人只选择一个标签
BotBase for Operators 的表单采用 Cloudflare 7 月 1 日公布的机器人行为与内容使用分类。运营方需要分别说明三个问题:机器人做什么、如何使用读取到的内容,以及由谁实际运营。
在行为层面,一个机器人可以同时选择多个类别,例如:
- Search:抓取页面以建立搜索索引或 RAG 数据库;
- Agent:代表用户访问页面并完成任务;
- Training:抓取内容用于训练或微调模型;
- Transact:代表用户进行结账或其他交易操作;
- Data Collection:价格抓取、竞争情报或第三方分析;
- Security Testing、SEO、Ads Verification、Feed Fetching 等其他用途。
在内容使用层面,运营方需要按照 Cloudflare 的 Content Signals 模型声明需求。一个机器人可能只需要读取页面来生成搜索摘要,另一个机器人则可能保存页面内容用于模型训练;二者对网站内容的使用方式并不相同。
Cloudflare 给出的示例是,网站可以在 robots.txt 中声明 Content-Signal: search=yes, ai-train=no, use=reference,表示允许搜索索引和保留参考信息,但不允许用于模型训练。提交表单中的内容使用声明,将用于与网站一侧的偏好进行对应检查。
运营方还要说明机器人属于 Direct 还是 Intermediary。前者指运营方直接从自己的基础设施运行机器人;后者则指平台承载了其他公司或产品发起的请求,但不一定是决定发送请求的一方。Cloudflare 认为,把这些信息拆开,有助于网站所有者理解一次访问背后的实际主体和用途。
审核自动化并不等于自动接受
Cloudflare 说,自 2023 年以来,机器人提交量约增长了 7 倍。如果每一条提交都按照过去的完全人工流程处理,审核规模将难以持续。因此,公司开始把部分检查自动化。
自动检查包括:
- 提交是否与目录中已有机器人重复;
- 用户代理模式是否足够具体,能否避免与其他已登记机器人重叠;
- 运营方声称的验证方法是否真实有效;
- IP 列表、反向 DNS 或 Web Bot Auth 签名能否被验证。
如果自动检查通过,机器人可能较快进入追踪目录;如果系统发现需要进一步判断的问题,则会把提交转交人工团队,并标记具体原因。Cloudflare 没有表示所有提交都会自动通过,自动化的作用是减少重复检查、提高一致性,并把人工注意力集中到需要判断的案例上。
这也意味着 BotBase 的核心变化更接近身份和治理基础设施,而不是访问许可系统。Cloudflare 文档目前将 BotBase 概括为一个用于查看和分析已追踪机器人及 Agent 的可见性层;网站所有者仍需通过安全规则或 AI 流量选项采取阻断或放行措施。文档还显示,面向企业客户的完整目录能力与 Enterprise Bot Management 相关,运营方新提交入口的可用范围则以 Cloudflare 8 月 28 日公告为准。
Cloudflare 正在把机器人治理扩展为双边系统
Cloudflare 在 7 月的 AI 流量选项更新 中,将自动化访问按 Search、Agent 和 Training 等内容用途区分,并把问题从“是不是 AI”推进到“机器人在网站上做什么、保存什么、如何重新分享内容”。BotBase 则为这种分类提供了一个目录和识别层。
8 月的运营方工具补上了另一侧的基础设施:如果网站所有者需要知道一个机器人是谁、它的用途是什么,机器人运营方也需要一个能够解释身份、跟踪审核并纠正信息的入口。Cloudflare 表示,当前发布主要解决的是 Visibility,后续计划继续推进所有权管理、运行观测,以及让运营方在能够证明自身带来价值时与网站建立更直接的沟通机制。
这条路线与 Cloudflare 近期提出的 Agent 开发生命周期 和 Cloudflare OS 的权限与责任设计 形成呼应:Agent 不仅需要完成任务,也需要能够被识别、观察、限制和追责。
但目前仍有几项问题有待观察。Cloudflare 尚未披露自动审核的准确率、平均处理时间、拒绝比例,以及网站所有者实际采用 BotBase 信息的程度。机器人进入目录后能否获得更稳定的访问,也不会由登记本身决定。对网站而言,真正的判断仍然是:某个机器人是否透明、是否遵守内容偏好,以及它带来的访问价值是否足以抵消运营和安全成本。
来源: Cloudflare 官方博客:BotBase for Operators;Cloudflare BotBase 开发者文档;Cloudflare Verified bots 文档。
不错过任何一条 AI 大事
订阅 AIFlux 早报,每天 3 分钟看懂产业动态。

