SEO 百科

Web Bot Auth

本页目录

Web Bot Auth

Web Bot Auth 是一套实验性协议，给自动化请求做密码学签名，让网站能判断漫游器是否真实可靠[1]。它不再依赖自报的家门，改用签名证明发起方身份。Google 说自己正在测试这套协议，参与的是一些 AI 智能体，托管在 Google 的基础设施上[1]。

它补的是哪一段

以往的判定用两样：用户代理字符串和 IP 地址。字符串由客户端自己写，IP 段的公布总有滞后，仿冒因此可行。Web Bot Auth 允许智能体对请求加密签名，把身份与 IP 地址解耦[1]。

Google 列出三项好处。加密确定性指的是告别容易被伪造的标头，改用经过验证的身份；可观测性指网站能看清智能体与内容互动的具体情况；前瞻性布局指为智能体提供商与网站之间建立互信留出位置[1]。

验证的四步

第一步是配公钥。到智能体的目录地址读取公钥集，缓存时间按 Cache-Control 标头来[1]。 第二步看请求标头。参与实验的请求带一个 Signature-Agent 标头，值指向该目录[1]。第三步按 Signature-Input 验 Signature，规则依据 HTTP 消息签名标准 RFC 9421[1]。第四步保留基于 IP 的验证作为回退，因为并非所有请求都带签名[1]。

对延迟敏感的场合，Google 允许先返回响应，再在有效期内验证签名，处置动作事后执行，并把结果用在同一调用方后续的请求上[1]。

实验阶段的三条限制

Google 把话说在前面。并非所有 Google 用户代理都使用 Web Bot Auth；用了这一协议的智能体，Google 也尚未给它的每一项请求都签名[1]。

因此官方建议是并行采用：一边接 Web Bot Auth，一边继续沿用 IP 地址、反向 DNS 和 User-Agent 字符串这三样做验证[1]。

规范本身也是草案。它由 IETF 的 WBA 工作组制定，Google 说明未来可能会有所变动，自己仍在评估这一协议的技术特性，也还在看它会给生态带来什么影响[1]。理由也写得很直白：基于用户代理和 IP 的验证是行业事实标准，数十年的系统、政策和最佳实践都建在它上面，改变不是一朝一夕的事[1]。

接入方一侧

密钥要自己生成。Cloudflare 的接入文档写了做法：先生成一把 Ed25519 私钥，用它签名请求，再导出公钥发布出去[2]。

基础设施一侧的支持已经铺开。Google 说主流的漫游器检测服务、CDN 和 WAF 均支持 Web Bot Auth，部分服务已经给出识别 Google-Agent 用户代理、把它列入许可名单的方法，具体步骤要问自己的服务提供商[1]。

附录

参见

参考资料

官方（境外）

  1. 《使用 Web Bot Auth（实验性功能）对请求进行身份验证》，Google 抓取工具文档。
  2. 《Web Bot Auth》，Cloudflare Docs。

外部链接