打开服务器日志，按访问量排序，你会看到大量以 Googlebot、Bingbot 开头的记录。这些请求里有一部分是真的搜索引擎抓取，也有一部分是采集脚本、监控服务或安全扫描工具随手填的 UA。把两者混在一起看，抓取分析基本就失去了意义。

为什么要费力核对

核对的目的不是「抓出坏人」，而是让两件事不被搞混。

• 把假蜘蛛当成真抓取，会让你对抓取频率、抓取路径的判断整体偏高，甚至为一种并不存在的高频抓取去做优化。
• 把真蜘蛛当成攻击流量，可能会在防火墙或 WAF 层面把它拦掉，之后你会发现收录和更新变慢，却找不到原因。

核对的三步

第一步：UA 字符串只能算线索

UA 是客户端自己写上去的，任何脚本都能写出一模一样的字符串。所以看到 Googlebot 不要直接下结论，它只是一个待验证的线索，而不是证据。

第二步：比对来源 IP 段

主流搜索引擎都会公布自己的抓取 IP 段，Google 会提供一份可定期下载的地址列表，Bing 也有对应文档。把日志里的来源 IP 拿去比对，落在官方段里的请求，基本可以认为是真抓取。这一步能筛掉绝大多数伪装者，成本低，效果直接。

第三步：反向 DNS 正查

针对 Googlebot 的官方做法是：对来源 IP 做反向解析，看域名是否落在 googlebot.com 或 google.com 下，然后再用这个域名做一次正向解析，确认识别出的 IP 与原始 IP 一致。只有双向都吻合，才算通过。只做反向解析是不够的，伪造的 PTR 记录能骗过这一步。

如果嫌手工麻烦，可以在日志处理流程里加一步定期比对官方 IP 列表，比单纯按 UA 过滤靠谱得多。

几个容易误判的场景

• CDN 或反向代理回源：站点前面有 CDN 时，日志里记下的可能是回源节点 IP，而不是蜘蛛的真实 IP。这时要看 X-Forwarded-For 一类的头部，并确认该头部是由可信代理写入的，否则它同样可以被伪造。
• IPv6 抓取：Googlebot 大量使用 IPv6 地址，核对时要同时比对 IPv6 段，否则会把真抓取误判成可疑请求。
• 验证与测试类请求：站点验证、Search Console 的抓取测试，来源与常规抓取并不总是同一批地址，对不上不必紧张。
• 假蜘蛛并不一定有害：有些监控工具只是借用热门 UA 来保证自己不被拦截。判断影响时看它请求了什么页面、频率多高，而不是只看名字。

发现假蜘蛛后怎么处理

先看行为，再决定动作。如果它只是低频访问公开页面，通常不值得处理；如果它在翻参数页、试表单、压测接口，按普通异常流量处理即可。

• 优先按 IP 或行为特征限流，而不是整体封禁某个 UA 字符串。封字符串会连带影响到真实抓取，属于典型的误伤。
• 如果某个假蜘蛛持续消耗资源，可以在 robots.txt 里做说明，但真正起作用的还是服务器层的限流与鉴权。
• 不要以为拦掉一个 UA 就等于关上了抓取入口，robots.txt 的规则和服务器拦截是两件不同的事。

顺带检查真蜘蛛有没有被挡住

核对完真假，别忘了反过来看：真蜘蛛来了，是否拿得到内容。验证码页、地区限制、UA 黑名单、过严的频率限制，都可能让真抓取拿到 403 或者一段空响应。

做法很简单：拿日志里已经确认为真的蜘蛛 IP，在测试环境手动发一次请求，看返回的状态码和内容长度是否与正常用户一致。如果返回的是验证码页或跳转页，说明入口层挡过了头，需要回过头调整规则。

一个务实的做法

不必每天核对，但建议定期抽样：每周或每月挑一段日志，把请求量靠前的蜘蛛 UA 及其来源 IP 过一遍官方地址段和双向解析，记录比对结果。这样你既清楚真实抓取的规模，也知道有多少是伪装流量，后续做抓取分析、日志报表和防护策略时，才有可靠的基础。核对本身不会提升抓取量，但它能让你的判断不建立在错误的前提上。