站点做维护、发版、切数据库，服务器短时间出问题，是很难完全避免的事。但对搜索蜘蛛来说，这几十分钟的“关门”会被记进抓取账本：它不只看你返回了什么状态码，也看这个状态持续了多久、恢复之后稳不稳定。很多站点的问题不在于停机本身，而在于停机的方式让蜘蛛读不懂。
先分清几种状态码在蜘蛛眼里的含义
同样是“现在打不开”，不同的状态码给蜘蛛的信号差别很大：
- 200：正常内容，蜘蛛按常规处理，继续往后抓。
- 301 / 302：跳转，蜘蛛会跟过去，但跳转链太长会额外消耗抓取资源。
- 404 / 410：页面不存在。410 表达得更明确，通常能更快让蜘蛛放下这类 URL。
- 5xx：服务端出错。蜘蛛一般会当成临时故障，不会马上把页面判死，但会降低再来看看的意愿。
- 503 加 Retry-After：比较清晰的“我现在忙，请稍后再来”。
- 429：请求过多，多见于你主动限流的场景。
维护期间最怕的，是用“不该用的状态码”表达“我在维护”。比如全站返回 404，蜘蛛会理解成这些 URL 已经消失；返回 200 但内容只是一句“系统维护中”，蜘蛛可能把这句提示当成页面正文。两种做法都会给后面的恢复期添麻烦。
503 加 Retry-After，把维护说得清楚一点
计划内的维护窗口，比较稳妥的做法是让需要暂停的页面统一返回 503，并带上 Retry-After 头。它可以填秒数，也可以填一个 HTTP 日期。重点是给出的等待时间要接近真实恢复时间：填得过短，蜘蛛可能很快又回来撞墙；填得过长，恢复之后的抓取回补会慢一些。
同时，Sitemap 和 robots.txt 这类基础文件建议保持可访问。如果一个站点连 robots.txt 都返回 5xx，蜘蛛对整站可用性的判断会更保守。维护页本身也不用做得复杂，写清预计恢复时间即可，不必让蜘蛛抓到一堆临时内容。
间歇性 5xx 往往比一次干脆的停机更麻烦
一次计划内的停机，开始和结束都很明确。更常见的情况是：服务器没有整体挂掉，但部分请求间歇性地超时或返回 5xx，白天正常、晚上抽风，或者某个接口拖慢了整页渲染。这种抖动会让蜘蛛难以判断“这是临时故障还是长期状态”。
结果通常不是立刻掉抓取量，而是在一段时间里慢慢降低频率，减少对深层 URL 的尝试。恢复之后，抓取节奏未必马上回到原来的水平，需要一段时间的稳定输出来重新建立信任。所以如果你的日志里 5xx 比例长期在低位徘徊，值得当成一个持续的观察指标，而不是等它变成大面积故障才处理。
恢复期该盯的几件事
- 先确认状态码已经干净：随机抽检若干 URL，看是否都是 200，日志里 5xx 的占比是否降下来。
- 确认 Sitemap 可访问且内容有效：文件能被正常读取，里面没有大量已删除的地址。lastmod 只在内容真的变化时更新，不要为了“催抓取”而反复刷时间。
- 重点页面的内链入口要能走通：从首页到栏目页再到详情页，顺着导航点下去是否都有可用链接，避免只依赖 Sitemap 一条发现路径。
- 看日志而不是凭感觉：抓取总量、抓取到的层级、新 URL 首次被抓的时间，这几项放在一起看，比单看一天的总请求数更有意义。
几个容易踩的小坑
- 把维护提示页返回成 200，导致它短暂进入索引。
- 为了“让蜘蛛别抓”，用 404 代替 503，等于告诉蜘蛛这些 URL 没了。
- 维护刚结束就立刻做全站改版或大批量 URL 调整，让蜘蛛同时面对“刚恢复”和“结构变了”两件事。
- 恢复后只在 Sitemap 里补充地址，内链却仍然是断的，深层页面依旧缺少入口。
维护本身不是问题，问题在于蜘蛛无法区分“你在维护”和“你坏了”。前者可以用状态码说清楚，后者只能靠持续的稳定输出慢慢修复。
把维护当作一次正常的对外沟通来对待：提前想好返回什么状态、恢复后先验证什么、日志里看哪些指标。至于抓取量什么时候回到原来的水平，不同站点差异很大，能做的只是把可控的部分做扎实。