做站点运营，迟早会遇到这个场景：日志里大批请求自称 Googlebot、Bingbot，抓取频率高得离谱，路径也乱。这时候需要先回答一个问题——它们真的是搜索蜘蛛吗。分不清这一点，后面的内链调整、抓取路径分析、服务器限速策略，判断依据都会是歪的。

User-Agent 是可以随便写的

UA 字符串没有任何强制校验机制，客户端想写什么就写什么。所以在日志里看到“Googlebot”字样，只能说明对方自称是蜘蛛，不能说明它就是。真正的判断要靠 IP 层面的信息。

搜索引擎官方通常会在帮助文档里公布蜘蛛的 IP 段或 IP 列表，部分还提供 JSON 格式的文件供程序读取。用自己的日志 IP 去和官方地址段做比对，是最直接的一步。如果某个 IP 不在官方公布的范围内却自称 Googlebot，基本可以直接当作普通爬虫处理。

反向解析再正向确认

比 IP 段更进一步的做法是反向解析。以 Google 为例，思路是：先对访问 IP 做一次 DNS 反查，看它解析出来的主机名是否落在官方域名后缀里；再拿这个主机名做一次正向解析，看是否指回原来的 IP。两步都通过，才认为是真蜘蛛。

只做第一步是不够的。任何人有能力给自己的 IP 配一个反向解析记录，主机名起得像官方并不难，但没法控制那个域名指向哪台机器。正反双向对上，伪造成本就高很多。

需要注意的是中间有 CDN 或反向代理的情况。请求到达源站时看到的可能是回源 IP，而不是蜘蛛本身的 IP。这时候要么在边缘层把原始 IP 传到后端日志里，要么就直接看 CDN 提供的日志，别拿回源 IP 去做反查，那结果没有意义。

日志里可以顺手做的几件事

• 按 UA 分组，看每组的请求量、IP 数量、抓取时段。真蜘蛛的 IP 分布相对集中，时段也有规律；采集脚本往往集中在少数几个 IP 上，且昼夜不停。
• 看抓取路径。真蜘蛛一般从入口页、内链、Sitemap 一路走；采集脚本常常直接对着 URL 列表猛拉，路径跳跃很大。
• 看对 robots.txt 和响应码的反应。真蜘蛛会先读 robots.txt，遇到 5xx 会退让重试；脚本往往不管这些。

真蜘蛛被挡在门外，通常不是因为验证本身

很多站点的问题反过来，是验证做得太粗暴，把真的蜘蛛也拦了。常见原因有几个：

1. WAF 或防护规则按 UA 关键词一刀切，误伤了官方 UA 的正常请求。
2. 限速规则按 IP 计数，蜘蛛集中从一个 IP 段抓取，触发限流被拒。
3. robots.txt 里顺手加了 Disallow: /，上线测试时忘记删。
4. CDN 缓存规则把 .xml、.json 这类文件也缓存了，蜘蛛拿到过期内容。
5. 服务器对 HEAD 请求或大范围并发直接返回 403。

判断是不是误拦，最直接的办法还是回到日志：看真蜘蛛的 IP 收到的状态码分布。如果 403、429 占比明显上升，同时页面更新的收录节奏变慢，那就值得查一下防护规则。

一个够用的小流程

不需要一上来就搞复杂的系统。可以先做三件事：把官方公布的 IP 段拉下来定期更新；对自称蜘蛛的请求做反查加正向确认，结果写进日志字段；每周看一眼真蜘蛛的响应码分布和抓取量趋势。有了这三个基础，再谈内链结构、Sitemap 分片、抓取预算这些更有意义的调整，判断才有依据。

把验证做成一次性的判断，而不是每个请求都重新推一遍，能省下不少开销。对已确认的真实 IP 段做短期缓存，是常见做法。

至于那些自称蜘蛛、实际是采集脚本的请求，处理方式取决于你的目标。如果它们给服务器带来明显压力，可以在边缘层限制频率；如果只是零星抓取，忽略也是一种选择。但前提是你已经能清楚地区分这两类流量。