抓取量突然下降，很多人第一反應是内容或内鏈出了問题。但在翻内鏈和 Sitemap 之前，先確認一件事：蜘蛛的請求到底有没有被服務器正常接住。如果請求来了却在中途被拦下，後面所有關于 URL 發現、抓取路径的分析都會跑偏。
先分清“被挡”和“被慢”
這两種情形的日誌表現不一样。被挡，是請求到達邊缘节点或源站後没有返回正常内容，常见的是 403、429，或者返回一個体积很小、内容奇怪的頁面；被慢，則是响應時間變長、超时增多，蜘蛛拿到的内容是對的，只是节奏被拖住了。前者属于訪問控制問题，後者更接近服務器性能問题，處理方向完全不同。
几種常见的拦截形式
- WAF 規則誤伤：某些規則會把带大量查询參數的 URL、異常查询串或特定 User-Agent 直接判成攻击行為。
- 频率限制：按 IP 或按 UA 限速。蜘蛛短時間内請求密集时触發限流，返回 429 或直接断開连接。
- 驗證碼與 JS 挑战：這類頁面需要执行脚本或人工交互才能通過。搜尋蜘蛛一般不會走完這套流程，只能拿到挑战頁，拿不到真正的 HTML。
- UA 或 IP 段封鎖：安全策略里简單地把某個 UA 關鍵詞或整段 IP 拉黑，可能把正常蜘蛛一起挡掉。
日誌里能看到的信号
把服務器日誌或 CDN 邊缘日誌按 UA 過滤出蜘蛛的請求，重点看几個指标：
- 狀態碼分布突然向 403、429 集中；
- 返回字节數明顯變小，說明拿到的是拦截頁而不是正文；
- 同一 IP 或同一 UA 的請求在某個時間点之後整体减少；
- 抓取频率没有異常上升，但被拒绝的比例明顯上升。
如果這些信号同时出現，基本可以判断問题在入口层，而不是内容层。
一個可执行的排查顺序
- 先確認蜘蛛身份。真正的搜尋蜘蛛可以通過反向 DNS 加正向解析驗證，不要只看 UA 字符串。
- 在 WAF 里為已驗證的蜘蛛 IP 段加白名單，或把已知蜘蛛 UA 從通用規則中排除。
- 检查限速配置。放開也要逐步来，邊調邊看服務器负载，而不是一次性全部取消。
- 把驗證碼和 JS 挑战從蜘蛛需要訪問的路径上移開，至少別让首頁、栏目頁、Sitemap 這些入口文件落在挑战之後。
- 修改後持續观察几天的日誌，看拒绝比例是否回落、抓取是否恢复。
別只看源站日誌
拦截有可能發生在 CDN 或邊缘节点，源站日誌里根本看不到這些請求。只看源站，容易誤判成“蜘蛛不来了”。排查时尽量拿到邊缘层日誌；也可以用 curl 带上蜘蛛 UA 訪問几個關键 URL，看返回的是正常頁面還是拦截頁。模拟只能驗證响應结果，不能代替對真實抓取日誌的观察。
和別的問题区分開
不少抓取異常看起来相似，成因却不同。日誌里完全没有蜘蛛請求，問题在 URL 發現或 robots 层面；有請求、狀態碼也正常、只是内容為空，更接近软 404 或渲染問题；請求正常、内容也對，只是来得少，那要往抓取優先級和站点更新频率上想。先把入口层排掉，後面的判断會省很多事。
抓取量下降时，先確認蜘蛛的請求有没有被服務器接住；接不住的請求，谈不上 URL 發現。