翻服务器日志时，经常会看到 UA 字段写着 Googlebot、Bingbot 的请求。但 UA 是一段可以随手伪造的文本，谁都能写。真正需要确认的是：这个 IP 背后到底是搜索引擎的抓取程序，还是伪装成蜘蛛的采集器、扫描器。核验身份是站点运营里比较基础、又经常被跳过的一步。
为什么要先核验，再谈拦截
伪装爬虫带来的麻烦通常有三类：一是持续高频抓取，把带宽、数据库连接占满，正常用户的访问变慢；二是把访问日志和统计工具搅乱，让人误判站点的抓取情况；三是部分伪装者会顺带扫描后台路径、尝试常见漏洞。反过来，如果防护规则只认 UA，很可能把真蜘蛛也一起挡掉，页面长期不被发现，代价比多几条日志大得多。
核验蜘蛛的三种依据
反向 DNS 双向验证
以 Googlebot 为例，官方推荐的做法是：先对来源 IP 做反向解析，得到的主机名应当落在 googlebot.com 或 google.com 域名下；再对这个主机名做一次正向解析，确认解析结果能回到同一个 IP。只有双向对得上，才认为身份可信。Bingbot 的思路类似，可信主机名通常落在 search.msn.com 下。只做单向解析是不够的，攻击者可以给自己控制的 IP 配置一个看起来很像的主机名。
官方 IP 段比对
主流搜索引擎都会公开抓取所用 IP 的列表文件，可以定期拉取、与日志中的 IP 做比对。这种方式的好处是执行成本低，适合先在本地跑一遍。缺点是列表会更新，如果长期不刷新，容易把新增的 IP 段误判成可疑来源，所以要么设定较短的更新周期，要么把它作为辅助手段，而不是唯一依据。
请求行为特征
在无法立即做 DNS 查询的场景下，行为特征可以当作快速线索：
- 请求频率是否明显超出正常抓取节奏，尤其是深夜持续满速。
- 是否只抓参数页、搜索结果页、筛选组合，而不抓正文和静态资源。
- 是否完全不请求 robots.txt，或者请求后照样抓被禁止的路径。
- 是否大量请求后台入口、配置文件、备份文件这类与内容无关的地址。
- 是否忽略页面上的 CSS、JS，说明它多半不是需要渲染页面的抓取程序。
这些特征单独看都不够决定性，组合起来看会更可靠。
身份核验自查清单
- 访问控制规则里，是否把 User-Agent 当成了唯一的判定条件。
- 对于声称是搜索引擎的请求，是否有办法批量做反查，而不是逐条手动验证。
- WAF 或防火墙策略中，有没有会误伤真蜘蛛的规则，比如限制单 IP 并发数、拦截无 Cookie 请求。
- 站点的限速策略是否过严，导致真蜘蛛的抓取速度被压到很低。
- 日志中同一个 UA 对应的 IP 是否高度分散，分散程度是判断伪造的重要信号。
- 是否曾封禁过一批 IP，之后有没有复查是否封错。
- 服务器是否长期被同一批参数页反复抓取，造成无意义的负载。
- IP 段列表和校验脚本是否有固定的更新与执行周期。
确认之后的处理方式
对于确认为伪装的来源，可以按影响程度分级处理：轻度占用带宽的，先做限速或返回 429，告诉对方现在不宜高频访问；有扫描、探测行为的，直接拒绝并记录，便于后续观察是否换 IP 再来。对真蜘蛛则应保持稳定响应，尽量不要因为负载升高就返回 5xx 或超时，那会让抓取程序降低对站点的信任。
核验的目的不是把所有外来请求都挡住，而是把有限的服务器资源留给真正有价值的抓取。门关得太死，损失的是自己的页面被发现的机会。
把核验变成常规动作
搜索引擎的 IP 段会变动，伪造者的手法也会跟着调整，所以核验很难一次做完就长期有效。比较务实的做法是把它放进例行工作：每隔一段时间导出访问日志，统计声称来自搜索引擎的请求里，真伪各占多少、抓取了哪些页面、集中访问了哪些路径。当某天伪蜘蛛比例突然升高，或者真蜘蛛的抓取量明显下滑，就能更早发现问题，而不是等到收录出现波动才回头翻日志。
另外要注意，日志里的数据只是一个观察窗口，并不等于搜索引擎内部的真实抓取情况。它的价值在于帮你判断服务器这一端有没有异常，而不是用来推断排名走向。