做站点运营，迟早會遇到這個场景：日誌里大批請求自称 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 段做短期缓存，是常见做法。

至于那些自称蜘蛛、實际是采集脚本的請求，處理方式取决于你的目标。如果它們给服務器带来明顯压力，可以在邊缘层限制频率；如果只是零星抓取，忽略也是一種選擇。但前提是你已经能清楚地区分這两類流量。