翻服務器日誌时，经常會看到 UA 字段寫着 Googlebot、Bingbot 的請求。但 UA 是一段可以随手伪造的文本，谁都能寫。真正需要確認的是：這個 IP 背後到底是搜尋引擎的抓取程序，還是伪装成蜘蛛的采集器、掃描器。核驗身份是站点运营里比較基础、又经常被跳過的一步。
為什么要先核驗，再谈拦截
伪装爬虫带来的麻烦通常有三類：一是持續高频抓取，把带宽、資料库连接占满，正常用戶的訪問變慢；二是把訪問日誌和統計工具搅乱，让人誤判站点的抓取情况；三是部分伪装者會顺带掃描後台路径、尝试常见漏洞。反過来，如果防護規則只認 UA，很可能把真蜘蛛也一起挡掉，頁面長期不被發現，代價比多几條日誌大得多。
核驗蜘蛛的三種依據
反向 DNS 双向驗證
以 Googlebot 為例，官方推荐的做法是：先對来源 IP 做反向解析，得到的主机名應当落在 googlebot.com 或 google.com 域名下；再對這個主机名做一次正向解析，確認解析结果能回到同一個 IP。只有双向對得上，才認為身份可信。Bingbot 的思路類似，可信主机名通常落在 search.msn.com 下。只做單向解析是不够的，攻击者可以给自己控制的 IP 配置一個看起来很像的主机名。
官方 IP 段比對
主流搜尋引擎都會公開抓取所用 IP 的列表文件，可以定期拉取、與日誌中的 IP 做比對。這種方式的好處是执行成本低，适合先在本地跑一遍。缺点是列表會更新，如果長期不刷新，容易把新增的 IP 段誤判成可疑来源，所以要么设定較短的更新周期，要么把它作為辅助手段，而不是唯一依據。
請求行為特征
在無法立即做 DNS 查询的场景下，行為特征可以当作快速线索：
- 請求频率是否明顯超出正常抓取节奏，尤其是深夜持續满速。
- 是否只抓參數頁、搜尋结果頁、篩選组合，而不抓正文和静態资源。
- 是否完全不請求 robots.txt，或者請求後照样抓被禁止的路径。
- 是否大量請求後台入口、配置文件、备份文件這類與内容無關的地址。
- 是否忽略頁面上的 CSS、JS，說明它多半不是需要渲染頁面的抓取程序。
這些特征單獨看都不够决定性，组合起来看會更可靠。
身份核驗自查清單
- 訪問控制規則里，是否把 User-Agent 当成了唯一的判定條件。
- 對于声称是搜尋引擎的請求，是否有办法批量做反查，而不是逐條手動驗證。
- WAF 或防火墙策略中，有没有會誤伤真蜘蛛的規則，比如限制單 IP 並發數、拦截無 Cookie 請求。
- 站点的限速策略是否過嚴，導致真蜘蛛的抓取速度被压到很低。
- 日誌中同一個 UA 對應的 IP 是否高度分散，分散程度是判断伪造的重要信号。
- 是否曾封禁過一批 IP，之後有没有复查是否封错。
- 服務器是否長期被同一批參數頁反复抓取，造成無意义的负载。
- IP 段列表和校驗脚本是否有固定的更新與执行周期。
確認之後的處理方式
對于確認為伪装的来源，可以按影响程度分級處理：轻度占用带宽的，先做限速或返回 429，告诉對方現在不宜高频訪問；有掃描、探测行為的，直接拒绝並记錄，便于後續观察是否換 IP 再来。對真蜘蛛則應保持稳定响應，尽量不要因為负载升高就返回 5xx 或超时，那會让抓取程序降低對站点的信任。
核驗的目的不是把所有外来請求都挡住，而是把有限的服務器资源留给真正有價值的抓取。门關得太死，损失的是自己的頁面被發現的机會。
把核驗變成常規動作
搜尋引擎的 IP 段會變動，伪造者的手法也會跟着調整，所以核驗很难一次做完就長期有效。比較務實的做法是把它放進例行工作：每隔一段時間導出訪問日誌，統計声称来自搜尋引擎的請求里，真伪各占多少、抓取了哪些頁面、集中訪問了哪些路径。当某天伪蜘蛛比例突然升高，或者真蜘蛛的抓取量明顯下滑，就能更早發現問题，而不是等到收錄出現波動才回头翻日誌。
另外要注意，日誌里的資料只是一個观察窗口，並不等于搜尋引擎内部的真實抓取情况。它的價值在于帮你判断服務器這一端有没有異常，而不是用来推断排名走向。