抓取失败这件事，很多站长只在日志里看到一片 5xx 或超时才想起来。蜘蛛处理失败的方式其实比较克制：它默认“先当临时问题”，而不是立刻把页面判死刑。但这份耐心有次数和时间上的边界，越早修好，页面恢复得越快。
先分清失败的类型
不同状态码在蜘蛛那里的分量不一样，后续动作也完全不同。
- 5xx（500、502、503、504）：一般被当作服务器端临时故障。蜘蛛会保留这条 URL，过一段时间再来试，而不是马上删掉。
- 连接超时、连接被重置：和 5xx 类似，属于“这一趟没拿到内容”，但不会因此判定页面已经失效。
- 429 与带 Retry-After 的 503：属于明确的“现在别来”。蜘蛛通常会按你给出的时间窗口收敛抓取频率。
- 403、401：这类多半被理解为“不让抓”。如果只是防火墙误伤，蜘蛛可能长期不再尝试。
- 404、410：这才是真正意义上的“不存在”，其中 410 的信号更明确，页面会更快从索引中退出。
失败之后，重试的节奏会怎么变
单条 URL 的失败不会孤立存在。当同一个主机在短时间内持续超时或返回 5xx，蜘蛛会把这个域名整体标记为“暂时不稳定”，然后做两件事：降低对这个站点的抓取频率，把省下来的抓取能力分给其他站点；同时把已经排队的 URL 往后挪。表现出来就是：日志里的抓取量突然掉下去，几小时甚至几天之后才慢慢恢复。
如果失败集中在某几个目录或某类页面，影响通常只落在那一块；但如果是全站性的响应变慢、数据库抖动，整个站点的抓取节奏都会被牵连。
内链和 Sitemap 救不了服务端错误
有个常见误解：以为 Sitemap 里写了、内链里挂着，蜘蛛就一定会反复来抓。链接解决的是“发现自己”，不是“拿得到内容”。如果某条 URL 每次访问都返回 504，再多的内链也只能让它多失败几次。反过来，只要服务恢复正常，之前已经发现过的 URL 依然在队列里，并不一定需要重新推送。
在日志里确认“失败—重试”的痕迹
- 按状态码聚合当天日志，看 5xx 的数量和出现时段，是否集中在某个时间窗。
- 挑几个失败 URL 单独跟踪一段时间，看后面是否出现同样 User-Agent 的再次请求，间隔多长。
- 对比服务器错误率和蜘蛛抓取量的两条曲线，两者通常一前一后。
- 留意抓取量下滑的起点，往往就是第一次大面积超时的时刻。
能做的几件事
- 先修故障，再看抓取。恢复稳定比任何提交动作都更有效。
- 主动限速时用 503 加 Retry-After，而不是直接断连，或者返回一堆 404。
- 临时维护页面用 503，不要返回 200 的空壳页面，也不要统一重定向到首页。
- 确认是永久下线的页面，直接给 404 或 410，让它干脆地退出队列。
- 把监控盯在服务器错误率上，而不是等日志里堆满失败记录才发现问题。
蜘蛛的耐心不是无限的：短期故障它会等，长期不稳定它会绕开。让服务器先稳住，抓取路径自然就顺了。