抓取量掉了，先看狀態碼分布
蜘蛛抓取量下滑，很多人的第一反應是内容质量或者收錄策略出了問题。但如果日誌里出現大量 403、406、429，甚至請求根本没到源站，那問题多半出在入口這一层。服務器、CDN、WAF、防火墙、限流插件，任何一环加了規則，都可能把正常搜尋引擎一起挡在外面。
排查的第一步不是急着改規則，而是先看資料：
- 按狀態碼統計最近 7 天與 30 天的抓取响應，看 403、429 的占比有没有明顯抬头；
- 按 UA 分组，確認常用搜尋引擎的爬虫是否還能拿到 200；
- 按 IP 反查，看被拦的是不是集中在官方公布的爬虫 IP 段；
- 對比 WAF 後台的拦截日誌與源站訪問日誌，確認請求到底在哪一层被拦下。
常见的誤拦来源
UA 黑名單寫得太粗
有些規則為了挡采集，直接寫 curl、python、Bot 之類的關鍵詞，或者用正則匹配到半個字符串，很容易把搜尋引擎的正規 UA 一並命中。更隐蔽的是反向情况：只允许少數几個 UA 通過，结果新出現的搜尋爬虫 UA 全被拦。
频率限制触發 429
限速通常按 IP 或按會话計數。搜尋引擎會從同一批 IP 高並發抓取，一旦阈值设得偏低，就會连續收到 429。短時間被限速影响不大，但持續數天，抓取预算往往會往別的站倾斜。
地域封禁與 IP 段誤伤
為了防攻击而封掉某些海外 IP 段是常见做法，但爬虫节点可能分布在多個地区，封得太宽會把正常抓取一起挡掉。
驗證碼與 JS 挑战頁
開啟人机驗證後，返回给爬虫的是一個挑战頁而不是正文。蜘蛛拿不到内容，短時間只是抓取失敗，長期就可能出現頁面掉出索引的情况。
云 WAF 的預設 BOT 規則
不少云厂商預設開啟 BOT 管理，規則集里包含疑似自動化工具、高频訪問這類策略。上线时没有逐條核對，就容易誤伤。
一套可执行的自查顺序
- 確認拦截层級：先在源站记錄真實来訪 IP（例如通過 CDN 回源头），弄清楚請求有没有到源站。
- 核對官方 IP 段：主流搜尋引擎都公布了爬虫 IP 段，比 UA 更可靠，優先用 IP 做白名單。
- 做反向解析驗證：對可疑 IP 做反向 DNS 查询，確認域名归属，再决定放行還是拦截。
- 临时放行再观察：把確認的爬虫 IP 段加入白名單，观察 3 到 7 天日誌里的狀態碼與抓取量變化。
- 調整限速阈值：把驗證過的搜尋引擎單獨分组，给一個更宽松的速率，而不是和普通訪客共用同一條限流規則。
- 记錄改動：每次改規則都寫清時間、原因、影响范围，方便出問题时回滚。
不要一看到抓取量下滑就去重新提交 Sitemap 或者改标题。先確認請求有没有進门，比什么都重要。
白名單長期维護的几個习惯
- 每季度复核一次白名單，删掉過期 IP 段，避免名單只增不减；
- 把 WAF 拦截日誌纳入日常巡检，至少每周掃一眼異常拦截量；
- 驗證過是真實搜尋引擎的流量，別因為频率高就自動拉黑；
- 采集與蜘蛛分開處理：對異常采集做封禁與限速，對正規爬虫保證稳定响應；
- 服務器與 CDN 两侧的規則保持同步，避免一邊放行、一邊拦截。
限速不能代替内容治理
限流只是入口管理，不是解决抓取预算問题的萬能办法。如果站点存在大量低质量聚合頁、參數组合頁，蜘蛛本来就會减少抓取，這时候把限速調松，意义有限。先把该合並的合並、该 noindex 的标清楚，再回来處理入口規則，顺序會更顺。