服务器偶尔抖一下，站长往往只看到“这次请求失败了”。但对搜索蜘蛛来说，一次 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 当成一次沟通，比当成一次意外更有用。

服务器稳定性是抓取的地基。状态码用得清楚，蜘蛛的抓取节奏就更容易回到正常轨道。