蜘蛛抓取时遇到 5xx，和遇到 404 是两回事。404 说的是这个地址确实没有内容，是一个内容层面的结论；5xx 说的是服务器这一次没把请求接住，是一个环境层面的临时状态。蜘蛛对这两种信号的反应完全不同，处理方式自然也不该一样。
两种信号，两套反应
对蜘蛛来说，404 和 410 是相对确定的答案，抓取队列会逐步减少对这类地址的访问；而 500、502、503、504 更像是“现在不方便”，蜘蛛倾向于过一段时间再来。正因为如此，把服务器故障当成页面删除来处理，反而容易误伤。
- 404 / 410：确定性结果，地址会被慢慢淡出抓取队列。
- 500 / 502 / 503 / 504：临时性结果，蜘蛛会保留重试的意愿。
- 403：有时介于两者之间，持续出现会被理解为不欢迎访问，抓取节奏同样会放缓。
判断错的代价是不对称的：把临时故障当永久删除，可能丢掉本可以恢复的页面；把永久删除当临时故障，只是多浪费几次抓取。
退避：蜘蛛的耐心是有上限的
如果同一个目录在短时间内连续返回错误，蜘蛛通常不会一直按原节奏试探，而是降低该目录、有时甚至是整个站点的抓取频次。这个下调是渐进的，恢复也不是一键完成的，它会根据之后一段时间的响应情况慢慢回升。
常见的表现
- 单位时间内的抓取请求数下降，访问间隔拉长。
- 已经抓过的页面，重抓时间被推后。
- 新发现的 URL 排队更久，发现到抓取之间的时差变大。
这些变化通常不会立刻体现在报表里，需要看一段时间内的日志趋势，而不是盯着某一天的抓取总量下结论。
超时与连接中断同样算失败
有些请求并不是返回了 5xx，而是压根没走完：连接被重置、响应只传了一半、首字节等待时间过长导致蜘蛛提前断开。对蜘蛛来说，这些和 5xx 属于同一类体验——它没能完整拿到页面。
可以检查的几个点
- 首字节时间是否偏长，动态页面里有没有慢查询在拖后腿。
- 是否存在突发流量把请求排队，导致正常抓取被挤在后面。
- CDN 回源链路是否稳定，回源失败会不会直接暴露成 5xx。
- 数据库连接池、后端依赖服务是否有间歇性抖动。
这些问题往往不是全天性的，而是集中在某个时段。对照日志里蜘蛛访问的时间分布，更容易定位。
恢复期该怎么做
故障排除之后，最容易犯的错是急着“补回来”。大量提交新 URL、频繁刷新 Sitemap，并不会让蜘蛛立刻恢复原来的节奏，反而可能加重服务器刚刚恢复时的负担。
- 先确认状态码连续稳定一段时间，再考虑推动新的抓取。
- 如果需要提交，分批进行，观察每次提交后的日志反应。
- 重点看恢复后蜘蛛的返回时间分布，而不是只看它有没有来。
- 错误页面要返回正确的状态码，不要用 200 包着一个“出错了”的页面，这会让蜘蛛把故障页当成正常内容存下来。
日常预防比事后补救省力
抓取的底座是服务器能不能稳定地把页面交出去。健康检查、静态页缓存、异常时的降级页面、业务高峰与抓取高峰的错开，这些看起来和“抓取优化”距离很远，实际影响却最直接。一个能稳定返回 200 的站点，不需要太多技巧就能维持正常的抓取节奏；一个经常抖动的站点，再多的结构优化也会被反复拖慢。