服务器出故障的那几个小时，站点的 URL 发现往往比页面本身更早受影响。页面打不开只是暂时看不到内容，但抓取路径断了之后，新 URL 进入队列的节奏会被推迟很久。下面按故障窗口、恢复顺序和事后核对三部分说说怎么处理。
故障期间搜索蜘蛛会遇到什么
同一段时间里，不同 URL 的返回结果可能完全不一样：
- 连接超时或连接被拒：通常发生在负载打满、进程挂掉的时候，蜘蛛拿到的是网络层的失败。
- 5xx 响应：程序还在跑，但数据库或缓存不可用，返回 500、502、503。
- 正常返回：静态页、CDN 缓存命中的页面照常打开。
这几种情况的后续影响不同。5xx 一般被当作临时故障处理，蜘蛛会隔一段时间回来重试；连接失败也类似。但如果故障期间返回的是 200 状态码的空页面或错误提示页，问题就从服务层变成了内容层，处理起来反而更麻烦。
为什么 URL 发现会先断
URL 发现依赖的是「抓到页面 → 读出链接 → 把新 URL 放进队列」这条链，链路前段一断，后面全停：
- 列表页、栏目页打不开，新发布的详情页就没有入口被读出来。
- Sitemap 如果和主站放在同一台机器、同一个域名下，故障期间可能一起拿不到。
- 内链集中在导航和侧栏，导航又依赖动态查询，故障时往往最先失效。
已经进过队列的 URL 不会因为一次故障就消失，但「已发现未抓取」的数量会在这段时间停止增长，恢复后也不会立刻补上。
恢复时的顺序
如果只能分批恢复，建议按下面顺序，把发现路径最短的环节先放出来：
- 首页与主要栏目页，保证入口可访问。
- 站内搜索、分类列表等承载大量链接的聚合页。
- Sitemap 文件本身，以及 Sitemap 索引。
- 详情页、评论、用户中心等末端页面。
恢复过程中可以留意抓取日志里的状态码分布，如果 5xx 比例还在高位，说明还没到可以让蜘蛛放心抓的阶段。
故障期间不建议做的事
- 不要用 200 返回空白页或错误提示页。蜘蛛会当成正常内容抓走，后面要靠内容更新来纠正。
- 不要全站 301 到首页。这会改变大量 URL 的落地位置，恢复正常后需要重新校正。
- 不要临时加 Disallow。robots.txt 的拦截是长期的，忘了改回来会直接影响发现。
- 不要顺手改版。故障窗口内做结构改动，出问题后很难判断是哪一步造成的。
临时维护更稳妥的做法是返回 503 并带上 Retry-After，让蜘蛛知道这是短时状态，而不是内容消失。
恢复后的核对清单
服务恢复不代表影响结束，可以按这几项对一遍：
- 抓取日志中故障时间段的 5xx 数量与持续时间，判断影响范围。
- Sitemap 是否已能被正常访问，索引文件与分片是否齐全。
- 最近发布的页面是否已经被列表页、导航重新链接到。
- 「已发现未抓取」的数量是否开始回落。
- 首页到详情页的链接路径是否和故障前一致，有没有因为临时改动留下断链。
站点稳定性本身就是抓取效率的一部分。与其在故障后反复提交，不如把入口页、Sitemap、列表页做成故障时也能撑住的静态兜底，把 URL 发现这条链保护住。