為什么 5xx 比 404 更值得優先處理
404 說明某個地址没了，搜尋蜘蛛记一筆就走；5xx 說明服務器当时根本没接住請求。對蜘蛛来说這是两種完全不同的信号。遇到 5xx，通常會被判定為一次抓取失敗，過一會儿再来，同一個地址可能在短時間内被反复重试。如果整站或某個栏目持續返回 5xx，抓取频次會被压缩，恢复之後也需要一段時間才能回到原来的水平。
更麻烦的是，5xx 往往是間歇性的：人工打開时一切正常，只有並發稍高或者某個後端接口超时才暴露出来。所以這類問题不能靠“我打開看了一眼没問题”来判断。
自查清單：先確認哪些地址在报错
- 随机抽 20～30 個已收錄的 URL，用脚本批量請求，记錄狀態碼和耗时。
- 單獨测一遍 Sitemap 里最近新增的地址，新頁面最容易命中没有预热的後端接口。
- 检查分頁、篩選、站内搜尋這類動態地址，它們更容易触發超时。
- 分別用移動端和桌面端的 UA 請求同一批頁面，有的站点移動模板會走另一套接口。
- 把响應時間明顯偏長的請求單獨列出来，即使返回 200 也要關注。
常见成因，按排查顺序看
應用层
- 資料库慢查询：缺索引，或者統計類查询直接跑在主库上。
- 缓存击穿：缓存過期的瞬間，大量請求同时回源。
- 第三方依赖超时：支付、地图、統計之類的外部接口卡住了主流程。
服務器與網關层
- 應用進程數不足，請求排队時間超過了網關的等待上限。
- 網關或负载均衡的超时阈值比應用短，應用還在處理就被判為失敗。
- 磁盘寫满、日誌文件過大導致寫入阻塞。
- 定时任務與抓取高峰撞在一起，抢同一批资源。
修复與驗證的顺序
- 先把持續报错的地址修掉，哪怕是临时屏蔽，也別让它一直返回 5xx。
- 對确實已经废弃、不再提供内容的地址，改成 404 或 410，让信号變清晰。
- 對偶發超时，先加缓存和限流，再考虑扩容。
- 核對網關與應用的超时設定，保持各层一致，避免一层已经放弃、另一层還在等。
- 改完之後连續观察几天日誌，確認错誤率回落再收工。
日誌里该看什么
不要只盯着總抓取次數。按狀態碼分组統計，再把 5xx 的 URL 按目錄聚合，通常很快就能看出是某一個栏目、某一類模板還是某一個接口的問题。
顺带提醒一句：错誤頁面如果本身返回 200，也可能被抓取並建索引，這比返回 5xx 更糟。至少要让它返回正确的狀態碼，並附上一句简短的說明文字。
計划内维護时怎么處理
如果确實要停机，尽量避免让蜘蛛長時間拿到 5xx。维護期間可以返回 503，並在响應头里寫上 Retry-After，告诉對方多久之後再来。這样比直接断開连接要清晰得多，恢复後也更容易回到正常的抓取节奏。
- 维護窗口尽量避開抓取高峰时段。
- 维護頁不要跳轉到首頁，否則容易被当成软跳轉。
- 维護結束後手動請求几個關键地址，確認狀態碼恢复正常。
把它變成日常习惯
- 把狀態碼监控加進例行巡检，而不是等流量掉了才回头查。
- 上线新功能时，同步检查它對抓取路径有没有影响。
- 记錄每次故障的時間和原因，方便對照日誌里抓取量的波動。
5xx 自查不是一次性任務，它更像一條底线：只有服務器在稳定地回應請求，後面的栏目規划和内容更新才有讨论的意义。