排查收錄时，多數人從标题、正文、内鏈查起，但有一類情况常被忽略：内容本身没問题，sitemap 也提交過，蜘蛛却始终没能把頁面完整取回去。這时候問题往往不在頁面里，而在服務器對抓取請求给出的回應上。回應不稳定，後面的索引判断就缺少可用的輸入。
三類常见的回應異常
超时與连接中断
服務器响應慢、首字节時間過長，或者抓取中途连接被掐断，爬虫通常拿不到完整的 HTML。偶尔一次影响有限，但如果同一批 URL 反复如此，抓取频次會逐步下調，URL 的排队位置也會往後挪。
5xx 狀態碼
500、502、503、504 表示服務端目前無法正常交付頁面。短時間内的 5xx 一般會被当作临时故障，爬虫過一阵再来；若持續多天，已收錄頁面就可能被重新评估，嚴重时從索引中拿掉。計划内维護更适合用 503 並附上 Retry-After，明确告诉爬虫什么时候再来，而不是让頁面直接报 200 却交不出正文。
429 與限流、拦截
429 表示請求過多，通常由站点侧的频控、CDN 或 WAF 触發。另一種是返回 403，或者干脆给出驗證頁面，常见于把爬虫 UA 一並挡掉的規則。這類回應不是“頁面内容有問题”，而是爬虫根本没被允许讀到頁面，排查方向完全不同。
回應異常會带来哪些连鎖後果
- 抓取频次下調，新 URL 的發現和抓取都變慢；
- 已發現、待抓取的 URL 排队時間被拉長；
- 已收錄頁面在多次抓取失敗後，索引狀態可能發生變化；
- 日誌里的抓取记錄看着不少，實际能成功解析的比例却很低。
按這個顺序排查更快
- 從服務器訪問日誌里按狀態碼分组統計，先看 5xx、429、403 和超时各自占比，而不是先看總請求量；
- 對照應用日誌、CDN 與 WAF 日誌，確認異常是源站产生還是邊缘节点产生；
- 区分“只對爬虫異常”和“對所有訪客異常”。只有爬虫 UA 才报错，多半是拦截規則；全站都慢，問题通常出在源站；
- 用命令行工具或抓取測試复核同一條 URL，確認回應能否稳定复現；
- 修复後繼續观察一段時間的抓取频次與成功比例，不要只看單日資料。
让回應稳定下来的几件基础事
- 盯住可用率，而不是只看平均值。少量長時間的 5xx，影响往往大于整体平均响應時間的小幅波動；
- 频控按来源细分，给搜尋引擎留出獨立配額，避免按 IP 一刀切；同时控制站内並發，减少自己把自己拖慢的情况；
- WAF 與 CDN 規則上线前，先確認不會誤伤正常爬虫，必要时做驗證或白名單；
- 减少不必要的跳轉鏈，缩短首字节時間，让一次抓取能拿完核心内容；
- 维護窗口使用 503 加 Retry-After，而不是把错誤頁以 200 返回。
抓取阶段的稳定性属于基础項：它做不好，内容、结构和内鏈上的優化都很难被完整看到。
還要提醒一点，修好回應不等于頁面立刻回到索引。抓取频次和索引狀態都需要一段观察窗口，建议以周為單位對比抓取成功率、狀態碼分布和索引數量的變化，再判断是否需要繼續往内容與结构层面排查。