爬虫日志验证方法档案

把某条流量认成“厂商的爬虫”，是 robots 决策、限流策略与日志统计的起点——认错了，后面全错。本档案给 2026 年的验证工具箱：Google 三类请求的对照验证物、各厂商验证端点表、以及正在落地的密码学验证（Web Bot Auth）。前置知识（爬虫名单与用途）见AI 爬虫全景档案表与AI 爬虫术语卡。

日志里那条 GPTBot 是真的吗

先看官方警示——Google 爬虫文档页顶部的 Caution 原文：“The HTTP user agent string can be spoofed”。UA 只是线索，不是身份；判定真伪要叠加 IP 段核对与反解/正解 DNS。2026 年的两个现势变化让老脚本需要检修：其一，Google 把请求分成三类、各配验证物（2026-03-20 更新）；其二，Google 的 IP 段 JSON 已于 2026-03-31 迁址。而 Web Bot Auth 密码学验签虽在三家落地，官方口径都明确它不能单独作为判据。

Google 三类请求与验证物对照表

Google 2026-03-20 更新后的官方分类，每类配自己的反解掩码与 IP 段 JSON——验证规则要按类建，不能只有一套。

三类之所以分着验，依据是行为差异。Common crawlers 做全站级抓取，走数据中心 IP 段；Special-case crawlers（AdsBot、APIs-Google、Mediapartners-Google 等）走限频代理，触发场景特殊；User-triggered fetchers 按用户动作即时取页，来源是应用前端代理。混着验的代价具体而直接：把 user-triggered 当 Googlebot 统计，会高估“搜索抓取量”、误判收录健康度；把特殊爬虫的限频代理当常规流量限流，会误伤广告审核这类业务环节。

手动验证三步与 IP 段 JSON 迁址

官方手动流程三步：对可疑 IP 执行 host <IP> 反解——域名必须落在 googlebot.com / google.com / googleusercontent.com 之下；再对反解到的域名做正解——必须回到原 IP；两步都过才算 Google 流量。IP 段 JSON 迁址是 2026-03-31 的官方公告：从 /search/apis/ipranges/ 迁至 developers.google.com/crawling/ipranges/，旧路径保留约 6 个月的 301 重定向——定时拉取 IP 段的脚本、WAF 规则、监控面板，都要在这个窗口内改地址。

Web Bot Auth：三家现势与“不能只靠签名”

密码学验证在 2026 年从提案变成现实，三家各就各位。Google：实验性签署其 AI agent 流量——身份标识 https://agent.bot.goog，公钥集发布于 .well-known/http-message-signatures-directory，请求携带 Signature-Agent 头，按 RFC 9421 验签；官方同时明示并非所有请求都签名——必须回退到 IP/反解/UA 三件套。OpenAI：ChatGPT agent 与 Operator 的出站请求采用 RFC 9421 加 Web Bot Auth（ed25519）。Cloudflare：2025-02 的首发推动方（npm 包 web-bot-auth），DataDome、Fingerprint、Fastly 等风控厂商已支持验签。共同结论：验签通过是强信号，验签缺失不是伪信号——覆盖率不足决定了三件套回退必须保留。

对站长工具链的现实含义：如果你的 WAF 或风控厂商已在支持名单里（DataDome、Fingerprint、Fastly），验签能力是现成开关，不必自建 RFC 9421 验签逻辑；自建 CDN 与裸 Nginx 的站点则要么引 web-bot-auth 包做验签，要么先只跑三件套并接受 agent 流量判定偏保守。

各厂商验证端点与立场差异

表格外补两句立场细节。Anthropic 的“不鼓励 IP 封锁”带官方理由——封锁会妨碍它读取你的 robots.txt，结果与你的配置意图相反；它同时声明不绕过 CAPTCHA，想限它的速优先用它支持的 Crawl-delay。Perplexity 的三件套（UA 前缀、IP JSON、自动刷新）是唯一一家把 WAF 配置范式写进官方文档的厂商，可直接抄作自家防火墙规则的模板。OpenAI 的验证粒度最细：四条爬虫各有一个 JSON，判定时用对应爬虫的 JSON 而不是“OpenAI 的 IP”这种笼统概念（四条爬虫的名单见AI 爬虫全景档案表）。

反面案例立此存照：2025-07（Cloudflare 博客 2025-07-21）Cloudflare 发文指控 Perplexity 伪装浏览器 UA 隐身爬取，Perplexity 否认——事件双方各执一词，本档案不作定性，但它说明了为什么“UA 匹配”必须叠加 IP 核验：伪装 UA 的流量，连匹配起点都是假的。Perplexity 自家的双验范式（见PerplexityBot）正是对这类风险的官方回应。验证解决“谁在抓”，屏蔽与放行的语义层见robots.txt AI 配置矩阵。

落地为判定规则时，验证结果只有三种形态，各自的处理路径如下。

第三行是纪律所在：判定失败不等于“另一个厂商”，而是“未验证流量”——把它留在业务账本里，统计与决策就都被污染了。

对站长的操作清单

1. 判真顺序固定三关：UA 命中，再到官方 IP JSON 核对，最后反解/正解 DNS——三关全过再归类。
2. 在约 6 个月的 301 窗口内，把 IP 段拉取脚本改到 developers.google.com/crawling/ipranges/。
3. 按 Google 三类请求分别建验证规则，别把 user-triggered fetchers 当成 Googlebot 统计或处置。
4. 对 agent 流量加 WBA 验签分支，同时保留 IP/反解/UA 三件套回退。
5. 各家 IP JSON 设定时自动刷新（Perplexity 官方建议的 WAF 范式）。
6. 三关全不过的“知名 UA”流量移交安全团队，按伪装处理。

限制与待核实

• Cloudflare 与 Perplexity 的 2025-07 争端无第三方裁定，档案只记录事件不判真伪。
• WBA 在 Google 侧为实验性且非全量签名，实际签名覆盖率无公开数字。
• 长尾厂商的验证物细节（如 Amazonbot 反解）未直接核实官方原文。
• 各家 IP JSON 的更新频率无官方承诺，“自动刷新”的周期需自行折衷新鲜度与请求量。