收錄报告里的數字通常滞後。当服務器端開始出現間歇性 5xx 或超时，最先變化的往往不是收錄量，而是抓取日誌里的失敗记錄和爬虫的訪問频次。等到收錄量出現波動时，問题其實已经發生了一段時間。
先分清：是抓不到，還是不想收
抓取和收錄是两個阶段。抓取失敗意味着爬虫没拿到内容；收錄判断發生在拿到内容之後，决定這個 URL 要不要放進索引。服務器問题属于前者，它一般不會直接把頁面判定為“质量差”，但會推迟後面所有环节：没抓到，就谈不上渲染、比對和收錄。
所以看到收錄不動时，先別急着改内容，第一步是確認爬虫到底有没有成功拿到頁面。
常见响應狀態碼對爬虫意味着什么
- 200 / 304：正常返回或内容未變，是最理想的狀態。
- 301 / 302：跳轉本身没問题，但跳轉鏈過長會消耗抓取額度，長期使用 302 也容易被当作临时跳轉處理。
- 403 / 401：常见于 WAF 或權限規則誤拦。爬虫看到的頁面和你浏览器里看到的可能完全不同。
- 404 / 410：内容明确消失，索引會逐步清理，属于正常回收。
- 429：請求過多，通常是限速触發。短時間密集訪問同一目錄容易踩到。
- 500 / 502 / 503 / 504：服務端問题。其中 503 如果带上 Retry-After，相当于告诉爬虫“過一會儿再来”，比裸奔的 500 更友好。
- 连接超时：日誌里可能只留下一條没有狀態碼的记錄，容易被統計漏掉。
持續 5xx 會带来什么连鎖反應
偶尔一次失敗，爬虫會把 URL 放回队列重试，影响有限。真正麻烦的是持續失敗：重试會占用抓取額度，挤压其他正常頁面的抓取机會；如果某個目錄甚至整站大面积 5xx，爬虫可能主動降低訪問频率，等站点恢复後，還需要一段時間才能回到原来的抓取节奏。
已经收錄的頁面長期返回 5xx，也可能從索引中消失。這通常不是惩罚，而是系統判断该 URL 無法稳定提供内容，先把它挪出结果。
容易被忽略的几處
- CDN 回源超时，源站日誌看起来正常，邊缘节点却在报错。
- 缓存失效瞬間的並發，導致部分請求集中失敗。
- JS、CSS 等静態资源被拦或超时，頁面虽然返回 200，渲染出来的内容却是残缺的。
- 安全策略把搜尋引擎的 IP 段限速過狠，正常訪問被当成異常流量。
- 日誌里把 5xx 当偶發噪声，没有按 URL 做聚合統計。
自查顺序
- 導出服務器日誌，按爬虫 UA 與狀態碼分组，算出 5xx 占比，並看清集中在哪些目錄或接口。
- 区分偶發與持續：單次失敗可以先放過，同一 URL 连續多日失敗就需要查。
- 检查 WAF、CDN 和安全插件規則，確認没有整段屏蔽或過度限速。
- 把静態资源單獨看一遍，渲染所需的文件拿不到，頁面等于只交付了一半内容。
- 修复後繼續观察抓取日誌，確認狀態碼回到 200，再等收錄层面的變化。
服務器修好不等于马上收錄。抓取频次回升、頁面被重新抓取、内容被重新评估，這几步都需要排队，中間隔着的時間往往比想象中長。
故障期間不建议做的几件事
不要在服務不稳的时候批量提交新 URL，抓取額度本来就紧張；不要反复修改 robots.txt，規則一變會让排查线索更难對上；也不要因為几天没收錄就換模板或大改 URL 结构。故障期的频繁動作，容易把真正的原因埋在噪声里。
把服務器稳定性当成日常监控項，比每天刷新收錄數字更有意义。抓取通畅了，收錄才有讨论的前提。