服務器偶尔出一次 500，你可能觉得訪客刷新一下就好了。但對搜尋引擎蜘蛛来说，這属于“没拿到内容”，而且它會记住這次失敗。5xx 和超时不像 404 那样明确告诉蜘蛛“這個地址没了”，它传递的信息是“過會儿再来”，来得多了，来訪频率就會下調。
5xx 和 404 的区別在哪
404 是一個确定的答案：頁面不存在。蜘蛛收到之後會逐步把地址從索引里移除，處理逻辑清晰。5xx 是“服務器暂时無法處理請求”，属于模糊信号。短期内蜘蛛會重试，如果连續多次都失敗，抓取预算會被明顯压缩，恢复速度也慢于一次性故障。
更麻烦的是，很多站点出的是“局部 5xx”：某個栏目接口超时、某個動態頁面在特定參數下报错。首頁和文章頁都正常，你從外部看完全没感觉，只有服務器日誌和抓取日誌里能看到那些零散的失敗记錄。
常见的几種故障形態
- 500：程序異常，通常是未捕获的错誤、資料库连接失敗或模板报错。
- 502：網關拿到了無效响應，常见于後端進程崩溃、重啟或 PHP-FPM 队列打满。
- 503：服務暂时不可用，可能是维護、限流或资源耗尽。如果是有計划的维護，這是相對合适的返回碼。
- 504：網關等待後端超时，通常意味着某個請求處理時間過長。
- 连接超时：蜘蛛根本没连上，连狀態碼都拿不到，這類情况在日誌里往往表現為請求中断。
自查步骤
- 登入服務器，查看 Web 服務器错誤日誌，按小时統計 5xx 數量，找到突增的時間点。
- 對照同時間段的抓取日誌，看蜘蛛請求的 URL 是否集中在某几個路径或參數上。
- 把出错的 URL 單獨拎出来，用命令行請求一遍，记錄响應時間與返回碼。
- 检查後端服務：資料库连接數、缓存命中、慢查询、第三方接口調用是否超时。
- 確認是否存在容量問题：高峰时段 CPU、内存、並發连接數是否打满。
抓取日誌怎么看
不要只盯着總請求量，重点是看狀態碼分布和响應時間。把 5xx 的 URL 归一下類，如果集中在某一個目錄或某一種參數组合，問题基本就在對應的程序模块上，而不是整台服務器。
別只看平均响應時間
平均 200 毫秒說明不了問题。如果 1% 的請求耗时 10 秒，蜘蛛遇到的可能恰好是這些慢請求，尤其当它並發不高、每次只抓一两個地址的时候。建议單獨統計慢請求的比例，而不是被平均值安慰。
出問题时的應對
- 短暂故障尽快修复即可，但不要用 200 狀態碼返回一個错誤提示頁，那會让蜘蛛把错誤頁当成正常内容處理。
- 計划内维護可以返回 503 並带上 Retry-After 头，這是一個明确的“稍後再来”。
- 某個模块長期不稳定，先把它從導航和内鏈里摘掉，或者直接下线，別让蜘蛛反复撞墙。
不要用 200 掩盖错誤。把故障包装成正常頁面，短期看起来干净，長期會让索引里混進一批没有實际内容的頁面。
恢复之後的收尾
服務恢复不等于影响結束。建议在故障後的一周内關注抓取日誌中的狀態碼分布，確認 5xx 比例回到正常水位；同时抽查故障期間被抓到的頁面，看是否有错誤内容被当成正常頁面记錄。如果确實产生了错誤頁，及时修正内容並让它恢复正常的返回狀態，比反复提交地址更有效。
把检查做在平时
- 每周看一次 5xx 匯總，不用很细，重点看趋势。
- 给慢請求設定阈值，超過 3 秒的請求记一條日誌，方便事後定位。
- 改版、加功能、上线新接口之後，主動跑一遍全站主要路径，確認狀態碼正常。
- 流量高峰前评估一次容量，留出余量。
多數抓取異常都不是突然發生的，而是先從服務器端的小波動開始。把這些指标放在日常视野里，比等蜘蛛不来了再回头排查要省力得多。