服務器日誌里出現大量“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 發現、维護蜘蛛池，還是單纯运营一個内容站点，先把訪問者身份分清楚，後面的抓取分析、日誌巡检和结构優化才有意义。