打開服務器日誌，按訪問量排序，你會看到大量以 Googlebot、Bingbot 開头的记錄。這些請求里有一部分是真的搜尋引擎抓取，也有一部分是采集脚本、监控服務或安全掃描工具随手填的 UA。把两者混在一起看，抓取分析基本就失去了意义。

為什么要費力核對

核對的目的不是「抓出坏人」，而是让两件事不被搞混。

• 把假蜘蛛当成真抓取，會让你對抓取频率、抓取路径的判断整体偏高，甚至為一種並不存在的高频抓取去做優化。
• 把真蜘蛛当成攻击流量，可能會在防火墙或 WAF 层面把它拦掉，之後你會發現收錄和更新變慢，却找不到原因。

核對的三步

第一步：UA 字符串只能算线索

UA 是客戶端自己寫上去的，任何脚本都能寫出一模一样的字符串。所以看到 Googlebot 不要直接下结论，它只是一個待驗證的线索，而不是證據。

第二步：比對来源 IP 段

主流搜尋引擎都會公布自己的抓取 IP 段，Google 會提供一份可定期下载的地址列表，Bing 也有對應文档。把日誌里的来源 IP 拿去比對，落在官方段里的請求，基本可以認為是真抓取。這一步能筛掉绝大多數伪装者，成本低，效果直接。

第三步：反向 DNS 正查

针對 Googlebot 的官方做法是：對来源 IP 做反向解析，看域名是否落在 googlebot.com 或 google.com 下，然後再用這個域名做一次正向解析，確認识別出的 IP 與原始 IP 一致。只有双向都吻合，才算通過。只做反向解析是不够的，伪造的 PTR 记錄能骗過這一步。

如果嫌手工麻烦，可以在日誌處理流程里加一步定期比對官方 IP 列表，比單纯按 UA 過滤靠谱得多。

几個容易誤判的场景

• CDN 或反向代理回源：站点前面有 CDN 时，日誌里记下的可能是回源节点 IP，而不是蜘蛛的真實 IP。這时要看 X-Forwarded-For 一類的头部，並確認该头部是由可信代理寫入的，否則它同样可以被伪造。
• IPv6 抓取：Googlebot 大量使用 IPv6 地址，核對时要同时比對 IPv6 段，否則會把真抓取誤判成可疑請求。
• 驗證與測試類請求：站点驗證、Search Console 的抓取測試，来源與常規抓取並不總是同一批地址，對不上不必紧張。
• 假蜘蛛並不一定有害：有些监控工具只是借用热门 UA 来保證自己不被拦截。判断影响时看它請求了什么頁面、频率多高，而不是只看名字。

發現假蜘蛛後怎么處理

先看行為，再决定動作。如果它只是低频訪問公開頁面，通常不值得處理；如果它在翻參數頁、试表單、压测接口，按普通異常流量處理即可。

• 優先按 IP 或行為特征限流，而不是整体封禁某個 UA 字符串。封字符串會连带影响到真實抓取，属于典型的誤伤。
• 如果某個假蜘蛛持續消耗资源，可以在 robots.txt 里做說明，但真正起作用的還是服務器层的限流與鉴權。
• 不要以為拦掉一個 UA 就等于關上了抓取入口，robots.txt 的規則和服務器拦截是两件不同的事。

顺带检查真蜘蛛有没有被挡住

核對完真假，別忘了反過来看：真蜘蛛来了，是否拿得到内容。驗證碼頁、地区限制、UA 黑名單、過嚴的频率限制，都可能让真抓取拿到 403 或者一段空响應。

做法很简單：拿日誌里已经確認為真的蜘蛛 IP，在測試环境手動發一次請求，看返回的狀態碼和内容長度是否與正常用戶一致。如果返回的是驗證碼頁或跳轉頁，說明入口层挡過了头，需要回過头調整規則。

一個務實的做法

不必每天核對，但建议定期抽样：每周或每月挑一段日誌，把請求量靠前的蜘蛛 UA 及其来源 IP 過一遍官方地址段和双向解析，记錄比對结果。這样你既清楚真實抓取的規模，也知道有多少是伪装流量，後續做抓取分析、日誌报表和防護策略时，才有可靠的基础。核對本身不會提升抓取量，但它能让你的判断不建立在错誤的前提上。