站点做维護、發版、切資料库，服務器短時間出問题，是很难完全避免的事。但對搜尋蜘蛛来说，這几十分钟的“關门”會被记進抓取帳本：它不只看你返回了什么狀態碼，也看這個狀態持續了多久、恢复之後稳不稳定。很多站点的問题不在于停机本身，而在于停机的方式让蜘蛛讀不懂。
先分清几種狀態碼在蜘蛛眼里的含义
同样是“現在打不開”，不同的狀態碼给蜘蛛的信号差別很大：
- 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 里补充地址，内鏈却仍然是断的，深层頁面依舊缺少入口。
维護本身不是問题，問题在于蜘蛛無法区分“你在维護”和“你坏了”。前者可以用狀態碼说清楚，後者只能靠持續的稳定輸出慢慢修复。
把维護当作一次正常的對外沟通来對待：提前想好返回什么狀態、恢复後先驗證什么、日誌里看哪些指标。至于抓取量什么时候回到原来的水平，不同站点差异很大，能做的只是把可控的部分做扎實。