打開一份訪問日誌，你會發現自称 Googlebot 的請求數量常常遠超预期。其中一部分确實来自搜尋引擎，另一部分来自采集脚本、掃描器、压测工具，甚至是随便填的 UA。如果只按 User-Agent 放行或拦截，很容易两头出错：把真蜘蛛挡在门外，或者给假蜘蛛開了绿灯。
只看 User-Agent 為什么不够
User-Agent 是客戶端自己填寫的字符串，没有任何强制校驗。任何程序都能把它改成 "Googlebot/2.1"。反過来，真蜘蛛的 UA 也會带版本号、平台後缀等變化，硬编碼匹配容易漏掉。
更麻烦的是，一旦在 WAF 或防火墙里按 UA 屏蔽，出問题的往往不是假蜘蛛，而是真蜘蛛：它的請求被拦截後返回 403，抓取频次下降，頁面更新迟迟不被發現。這類問题在日誌里通常表現為“蜘蛛忽然不来了”，而不是一條明顯的报错。
官方推荐的驗證顺序
Google 與 Bing 都提供了基于 DNS 的驗證思路，核心是先看 IP，再用 DNS 双向確認。顺序不建议颠倒，也不建议只做其中一步。
第一步：從日誌取出訪問 IP
日誌里记錄的是 IP，不是 UA。先把可疑請求的 IP 挑出来，注意同一台机器可能有多個出口 IP。如果站点在 CDN 或反向代理後面，要確認日誌里拿到的是真實客戶端 IP，而不是节点 IP，否則後續所有解析结论都是错的。
第二步：做反向解析
對 IP 执行反向 DNS 查询，看解析出的域名是否属于搜尋引擎官方域。如果结果是一串随机字符、家庭宽带的域名，或者根本没有 PTR 记錄，基本可以判定為伪装。
第三步：正向解析比對
反向解析還不够，因為 PTR 记錄理论上也能被伪造。把反向解析得到的域名再做一次正向解析，看返回的 IP 是否與最初日誌里的 IP 一致。只有两轮都通過，才能較有把握地認定為真蜘蛛。
常见誤判與處理
- 把 CDN 回源 IP 当成蜘蛛 IP：日誌里是节点地址，解析结果自然對不上，需要先配置好真實 IP 的透传头。
- 只驗證一次就長期放行：蜘蛛出口 IP 會變動，建议定期重新抽样。
- 把驗證失敗等同于恶意：部分合規工具也會抓取，先限速观察，比直接封禁更稳妥。
- 忽略 IPv6：只查 IPv4 會漏掉相当一部分记錄。
站点侧可以落地的做法
- 日誌中保留完整的 IP、UA、時間與請求路径，至少留存數周，便于回溯。
- 每周抽样一批自称蜘蛛的 IP，走一遍反向加正向解析。
- 通過驗證的地址段在防火墙里單獨放行，不要按 UA 匹配。
- 驗證失敗的請求做限速和观察，而不是立即返回 403。
- 把驗證结果與抓取频次、抓取路径的记錄放在一起看，避免把两類流量混在一起分析。
驗證的目的是分清“谁在抓”，而不是把抓取請求都拒之门外。真蜘蛛被拦住，代價通常比多放几個假蜘蛛更大。
把驗證做成一個固定的小流程之後，日誌里的蜘蛛資料才有參考價值。否則你看到的抓取频次、URL 發現节奏和内鏈走訪路径，可能掺着一半與搜尋引擎無關的流量，據此做出的运营判断也會跟着偏。