服务器日志里出现大量“Googlebot”“Bingbot”“Baiduspider”的访问记录，并不代表这些请求都来自搜索引擎。UA 字符串可以随便写，一个脚本改个参数就能冒充。真正需要区分的，是两类完全不同的访问：搜索引擎的抓取，和假装成搜索引擎的采集或扫描。
为什么要做蜘蛛校验
- 假蜘蛛消耗资源：它们往往并发高、路径乱，把带宽和数据库连接占住，真蜘蛛反而排队。
- 真蜘蛛被误伤：防火墙或 WAF 一旦误封，页面可能连续几天抓取失败，恢复后节奏也会变慢。
- 日志统计失真：把假蜘蛛的请求算进“抓取量”，会让后续的抓取分析得出完全错误的结论。
三种校验方式，从弱到强
UA 字符串：只能当线索
UA 是请求头里最容易伪造的部分，单独用它做判断几乎没有意义。但可以先用它筛出“自称蜘蛛”的请求，再做进一步验证。
反向 DNS 解析：目前最实用
Google 官方建议的方式是两步：先对访问 IP 做反向 DNS 查询，如果得到的域名以 googlebot.com 或 google.com 结尾，再对该域名做一次正向解析，确认解析结果与原始 IP 一致。两步都通过，才可以基本确认。Bingbot 的思路类似，反向域名后缀是 search.msn.com。
官方 IP 段：适合做批量白名单
Google 会发布 googlebot.json、special-crawlers.json 等文件，Bing 也提供 bingbot.json，可以定期拉取并导入防火墙或 WAF 白名单。Baiduspider 的 IP 段则需要对照百度搜索资源平台公布的列表，注意这类列表会更新，别做完一次就丢在角落。
容易被忽略的误伤场景
- 站点整体挂了 JS 挑战或验证码，蜘蛛拿不到内容，等于对搜索引擎关闭了整站。
- 速率限制按“每 IP 每秒 N 次”一刀切，蜘蛛并发稍高就被 429，抓取节奏被打乱。
- CDN 或 WAF 的默认规则里带了“拦截已知爬虫 UA”的开关，结果连真蜘蛛一起挡了。
- 按 IP 段封禁时把云服务商整段拉黑，而部分搜索引擎的抓取 IP 恰好托管在云上。
一套可以落地的流程
- 从日志抽样，导出 UA、IP、状态码、响应时间，先看有多少自称蜘蛛的请求能通过反向 DNS 校验。
- 把校验通过的 IP 段与维护中的官方列表合并，形成动态白名单，设定固定的更新周期。
- 给白名单中的访问设置更宽松的速率阈值，其余请求按普通用户规则处理。
- 对假蜘蛛不必全用 403 制造海量错误日志，降速、返回精简页面或 429 都可以，关键是别让它拖垮源站。
- 每月复盘一次：真蜘蛛抓取成功率、5xx 占比、假蜘蛛请求占比，这三个指标比“今天被抓了多少次”更有参考价值。
robots.txt 不是访问控制
robots.txt 只对守规矩的爬虫有效，而且它控制的是“是否抓取”，不是“是否访问”。用它去挡恶意爬虫，基本等于贴一张纸条。真要限制访问，还得靠服务器层或 WAF 规则。反过来，也不要用 robots.txt 屏蔽 CSS、JS 这类渲染必需资源，否则蜘蛛拿到的页面是残缺的。
校验的目的是把资源优先留给真正的抓取，而不是把服务器变成只对搜索引擎开放的封闭系统。
无论你是在做 URL 发现、维护蜘蛛池，还是单纯运营一个内容站点，先把访问者身份分清楚，后面的抓取分析、日志巡检和结构优化才有意义。