抓取日志里通常有两类记录：成功的 200，以及超时、5xx、连接被重置这类失败。多数人只盯前者，其实后者同样会影响 URL 发现的速度——蜘蛛按批抓取，一次失败意味着这条 URL 要排队等下一轮，等待期间它与内链、更新节奏全都错开。搞清楚失败之后会发生什么，比单纯数“抓了多少”更有用。
抓取失败之后，蜘蛛会做哪些动作
不同失败类型，处理方式并不一样，粗略分三档：
- 临时连接问题：超时、连接重置、DNS 抖动。这类通常被当成“没抓到”而不是“页面没了”，蜘蛛倾向重试，而不是立刻放弃这条 URL。
- 服务器主动报错：500、502、503，以及偶发的 429。这些会被记成抓取受阻，直接推高站点维度的失败率。
- 明确的内容状态：404、410、401、403。这类不算失败，而是结果，蜘蛛按状态码处理对应的 URL，和超时是两回事。
关键在于：临时失败会让 URL 留在待抓队列里，但排序会往后退。如果同一条 URL 反复失败，重试间隔会越拉越长，从小时级变成天级，最后可能需要外部链接或 Sitemap 重新把它唤回来。
服务器抖动怎样传导到 URL 发现
假设站点平时响应 200ms，某天开始偶尔 1-2 秒才返回。表面看只是慢，实际效果是：同一批抓取任务里部分请求超时，那部分 URL 这一轮白跑；下一轮再来时，优先级已经被其它任务挤到后面。站点越大，这种延迟累积越明显——列表页、分页、详情页本就串成一条链，链上某一环慢，后面的 URL 就晚被发现。
更麻烦的是失败率统计。蜘蛛一般按站点维度评估抓取表现，如果一段时间里 5xx 占比偏高，它会降低整站的抓取安排，而不只是那几个慢接口。也就是说，几个不稳定的动态接口，可能拖累全站的 URL 发现进度。
抓取频率更像一种信任额度：稳定就多给，抖动就回收。恢复稳定后额度会慢慢回来，但通常是渐进的，不会一次到位。
让失败 URL 尽快回到队列的几件事
- 先分清是“慢”还是“挂”：在服务器日志里按状态码和响应时长分组，看失败集中在哪些路径、哪个时段，是数据库超时，还是某个接口被扫描拖死。
- 把 5xx 当作可用性问题处理：排查代码报错、连接池耗尽、磁盘 IO 打满，别让蜘蛛替你做压力测试。
- 合理使用 503 与 Retry-After：计划内维护时，返回 503 并给出 Retry-After，比直接断开连接清晰得多，蜘蛛知道这是暂时状态。
- 谨慎使用 429：只有确实需要限速时才用，并确认被限的是异常流量，而不是正常搜索蜘蛛。用错了会把抓取路径掐断。
- 给重要 URL 留可重新发现的入口：Sitemap 的 lastmod、首页或栏目页的内链，都能在失败之后提供一次新的发现机会，不必只等蜘蛛自己想起来。
- 观察恢复曲线：修好之后别急着下结论，看两到四周的抓取量与失败率变化，确认队列确实在回补。
页面侧可以做的小调整
- 减少首屏不必要的同步请求，让 HTML 能在超时之前吐出来。
- 把关键 URL 放在稳定的静态入口里，别都塞进需要复杂查询的动态列表。
- 检查图片、脚本是否挂在阻塞位置，资源加载失败不应拖住主文档。
- 日志里区分蜘蛛访问和用户访问，否则限速策略很容易误伤。
复盘时看什么
建议每周固定看三组数：按状态码拆分的失败率、平均响应时间的分位值、新 URL 从发现到被抓取的间隔变化。三者一起看，才能判断问题出在服务器、内链结构，还是更新节奏。单独看抓取总量，很容易把“抓得少”误判成“蜘蛛不来了”。
抓取失败本身不可怕，可怕的是失败之后没有留下可重新发现的路径。把服务器稳定性、内链入口和 Sitemap 维护当成同一件事来做，URL 发现才不至于被一次抖动打断太久。