服務器偶尔抖一下，站長往往只看到“這次請求失敗了”。但對搜尋蜘蛛来说，一次 5xx 不只是丢了一個頁面，它還會影响接下来一段時間里對你整個站点的抓取安排。

蜘蛛看到 5xx 时，先判断的是“暂时還是坏了”

503 Service Unavailable 通常被理解為临时狀態，蜘蛛會保留這個 URL，過一段時間再来。500、502、504 這類更像是服務端出了問题，蜘蛛也會重试，但连續多次之後，抓取频次往往會下降，重要頁面也可能被延後訪問。

最需要避免的是：故障时返回 200 的“维護中”頁面。這會让蜘蛛把维護文案当成正常内容，如果持續時間較長，原来頁面的快照就可能被替換掉。

• 全站维護：统一返回 503，不要让部分路径繼續返回 200。
• 單頁故障：不要用 200 的空頁面或错誤提示頁掩饰。
• 维護期間：不要同步更新 Sitemap，避免把不稳定的狀態传递出去。

维護模式怎么開才不容易被誤讀

如果维護窗口是可预期的，短時間返回 503 是常见做法。可以在响應头里带上 Retry-After 提示多久後再来，但不要設定得過長，也不要反复延長，否則蜘蛛可能把整個站点当成長期不可用。

维護頁面本身不要放大量内鏈，也不要让它成為一個可被抓取的入口。窗口結束後，應尽快让原 URL 恢复 200，而不是让维護頁繼續挂在同一批地址上。

部分节点故障：最难查的一種 5xx

负载均衡、多台應用服務器或 CDN 回源，只要有一台出错，蜘蛛就會“随机”拿到 5xx。站長自己在浏览器里刷新可能一切正常，但日誌里蜘蛛的失敗請求却断断續續，這種問题最容易被忽略。

• 按狀態碼分组看日誌，確認 5xx 是否集中在某個 IP 或某個时段。
• 检查 CDN 回源失敗率，而不只是訪客侧的错誤率。
• 確認是否有定时任務、备份或訪問防護在高峰期占用资源。

判断影响范围的三步

1. 從日誌中筛出 5xx 的 URL 數量與占比，看是零星還是成片。
2. 確認這些 URL 是不是重要頁面，例如首頁、栏目頁和内容詳情頁。
3. 對比故障前後的抓取量，判断蜘蛛是否已经降低回訪频次。

恢复之後別急着“补提交”

服務器恢复後，抓取量不會立刻回到原来的水平。可以先確認重要 URL 都返回 200，再观察几天的日誌，而不是马上把整站地址集中提交一遍。

• 不要把全部 URL 一次性塞進 Sitemap 或提交接口。
• 關注蜘蛛是否重新訪問了故障期間失敗的那些頁面。
• 如果某批頁面持續不被回訪，再考虑從内鏈和 Sitemap 上补充入口。

日常预防比故障後补救更重要

• 监控 5xx 比例，而不是等抓取量下滑才發現問题。
• 给静態頁面加缓存，减少高峰期的源站压力。
• 抓取压力大的站点，可以把内容發布安排在非高峰时段。
• 提前准备维護模式開關流程，避免临时用 200 頁面顶替。

蜘蛛對故障的记忆不是永久的，但恢复需要時間。把 5xx 当成一次沟通，比当成一次意外更有用。

服務器稳定性是抓取的地基。狀態碼用得清楚，蜘蛛的抓取节奏就更容易回到正常轨道。