服务器偶尔出一次 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 秒的请求记一条日志，方便事后定位。
- 改版、加功能、上线新接口之后，主动跑一遍全站主要路径，确认状态码正常。
- 流量高峰前评估一次容量，留出余量。
多数抓取异常都不是突然发生的，而是先从服务器端的小波动开始。把这些指标放在日常视野里，比等蜘蛛不来了再回头排查要省力得多。