打开一份访问日志，你会发现自称 Googlebot 的请求数量常常远超预期。其中一部分确实来自搜索引擎，另一部分来自采集脚本、扫描器、压测工具，甚至是随便填的 UA。如果只按 User-Agent 放行或拦截，很容易两头出错：把真蜘蛛挡在门外，或者给假蜘蛛开了绿灯。
只看 User-Agent 为什么不够
User-Agent 是客户端自己填写的字符串，没有任何强制校验。任何程序都能把它改成 "Googlebot/2.1"。反过来，真蜘蛛的 UA 也会带版本号、平台后缀等变化，硬编码匹配容易漏掉。
更麻烦的是，一旦在 WAF 或防火墙里按 UA 屏蔽，出问题的往往不是假蜘蛛，而是真蜘蛛：它的请求被拦截后返回 403，抓取频次下降，页面更新迟迟不被发现。这类问题在日志里通常表现为“蜘蛛忽然不来了”，而不是一条明显的报错。
官方推荐的验证顺序
Google 与 Bing 都提供了基于 DNS 的验证思路，核心是先看 IP，再用 DNS 双向确认。顺序不建议颠倒，也不建议只做其中一步。
第一步：从日志取出访问 IP
日志里记录的是 IP，不是 UA。先把可疑请求的 IP 挑出来，注意同一台机器可能有多个出口 IP。如果站点在 CDN 或反向代理后面，要确认日志里拿到的是真实客户端 IP，而不是节点 IP，否则后续所有解析结论都是错的。
第二步：做反向解析
对 IP 执行反向 DNS 查询，看解析出的域名是否属于搜索引擎官方域。如果结果是一串随机字符、家庭宽带的域名，或者根本没有 PTR 记录，基本可以判定为伪装。
第三步：正向解析比对
反向解析还不够，因为 PTR 记录理论上也能被伪造。把反向解析得到的域名再做一次正向解析，看返回的 IP 是否与最初日志里的 IP 一致。只有两轮都通过，才能较有把握地认定为真蜘蛛。
常见误判与处理
- 把 CDN 回源 IP 当成蜘蛛 IP：日志里是节点地址，解析结果自然对不上，需要先配置好真实 IP 的透传头。
- 只验证一次就长期放行：蜘蛛出口 IP 会变动，建议定期重新抽样。
- 把验证失败等同于恶意：部分合规工具也会抓取，先限速观察，比直接封禁更稳妥。
- 忽略 IPv6：只查 IPv4 会漏掉相当一部分记录。
站点侧可以落地的做法
- 日志中保留完整的 IP、UA、时间与请求路径，至少留存数周，便于回溯。
- 每周抽样一批自称蜘蛛的 IP，走一遍反向加正向解析。
- 通过验证的地址段在防火墙里单独放行，不要按 UA 匹配。
- 验证失败的请求做限速和观察，而不是立即返回 403。
- 把验证结果与抓取频次、抓取路径的记录放在一起看，避免把两类流量混在一起分析。
验证的目的是分清“谁在抓”，而不是把抓取请求都拒之门外。真蜘蛛被拦住，代价通常比多放几个假蜘蛛更大。
把验证做成一个固定的小流程之后，日志里的蜘蛛数据才有参考价值。否则你看到的抓取频次、URL 发现节奏和内链走访路径，可能掺着一半与搜索引擎无关的流量，据此做出的运营判断也会跟着偏。