站点临时故障、活動上线瞬間的流量峰值、被压测或者限流策略配置不当，都會让搜尋引擎蜘蛛在抓取时拿到 5xx 或 429。這類错誤本身不直接决定收錄，但它會改變搜尋引擎對站点可用性的判断，進而影响抓取节奏，也影响已经收錄的頁面是否繼續留在索引里。處理這類問题，先分清错誤類型，再决定要不要動手。
先分清這几類狀態碼
- 500、502、504：服務端異常或網關超时，通常是程序、資料库或反向代理的問题，属于被動出错。
- 503：服務不可用，用于計划内维護最合适，可以配合 Retry-After 說明大概多久後再来。
- 429：請求過多，說明抓取速率超過了服務器能承受的范围，或者触發了站点自己的限流規則。
- 403、404：属于另一類問题，一個是拒绝訪問，一個是頁面不存在，不要和 5xx 混在一起排查。
蜘蛛遇到 5xx 會做什么
多數搜尋引擎會把 5xx 当作临时性错誤：短時間内會重试，同时降低對這台服務器的整体抓取频率。也就是说，出错的往往不只是报错的那几個 URL，同站其他頁面的抓取速度也可能一起變慢。
如果某個 URL 连續多次返回 5xx，它有可能被暂时從索引中拿掉，等恢复後再重新抓取才會回来。這個動作不是惩罚，而是可用性判断的结果——索引里的頁面打不開，繼續展示對用戶没有價值。因此關注点應该放在恢复速度上，而不是纠结某一次抓取失敗。
503 的正确用法與常见誤用
計划内维護时，503 比 404、也比返回 200 的空頁更合适。加一個 Retry-After 响應头，给出大概的恢复時間，蜘蛛會把這個頁面当作“稍後再来”，而不是当作已经消失。
把 503 当作長期的“暫停收錄”開關，结果往往是全站抓取量持續下降。恢复之後，需要更長時間才能回到原来的抓取节奏。
不要用 robots.txt 挡掉故障中的頁面
故障是临时的，而 robots.txt 的 disallow 會让蜘蛛连狀態碼都拿不到，無法区分頁面是暂时不可用還是已经刪除。等問题修复，還要花額外時間解除這種誤解，排查方向也容易被带偏。
429 與抓取速率
429 一般出現在抓取频率超過服務器處理能力，或者触發了自身限流規則的时候。如果站点没有主動做限流，那就說明高峰期服務器确實吃紧——調整方向是提升可用性或優化响應時間，而不是把抓取频率繼續往上推。
短時間内大量新增 URL、同时上线的多個活動頁，也可能触發這種情况。把新頁面分散提交、错開上线時間，有时比反复提交更有效。
恢复之後按什么顺序收尾
- 確認服務端稳定：连續观察一段時間，5xx 比例降到可以忽略的水平，而不是刚恢复正常就開始操作。
- 检查抓取日誌：看错誤是否集中在某個目錄、某類模板或某個接口，属于局部問题還是全站問题。
- 確認索引狀態：抽查之前报错的頁面是否仍在索引里，優先看那些本来有自然流量的頁面。
- 提交與观察：關键頁面可以用站点地图或抓取工具提醒一次，不必反复提交，重复提交不會加快處理。
- 记錄時間点：把故障開始與恢复的時間记下来，方便之後對照收錄曲线的變化，也方便判断影响范围。
几個容易踩的坑
- 把错誤頁返回 200：用戶和蜘蛛都拿到“正常”狀態，問题被藏起来，之後的排查會更难。
- 長時間挂着 503 不恢复：可用性信号持續變差，抓取量下降，恢复期會被拉長。
- 一出現 5xx 就先改 robots.txt：多半让排查方向偏掉，把临时問题變成長期問题。
- 只看首頁是否正常：蜘蛛抓的是全站，列表頁、詳情頁、接口頁都要一起看。
服務器错誤與收錄之間的關系，更像是“可用性影响抓取节奏，抓取节奏影响索引更新”，而不是一個直接的開關。把狀態碼還给它本来的含义，通常比任何提交動作都更有用。稳定之後，收錄與索引狀態一般會自己慢慢回到常態，需要的是观察和等待，而不是频繁干预。