做站点运营的人常會遇到一個現象：蜘蛛池入口頁本身没什么改動，搜尋蜘蛛的抓取量却突然下降。翻日誌發現，入口頁返回的要么是 503，要么是 429。這两個狀態碼看起来都是“服務器暂时不给你看”，但搜尋蜘蛛對它們的理解和後續處理並不一样。分清差別，排查方向才不會跑偏。
先看两個狀態碼各自在说什么
503 Service Unavailable
503 的含义是服務器目前無法處理請求，通常是临时狀態：後端進程挂了、資料库连不上、正在重啟、被上游網關挡下，或者站点主動進入了维護模式。它传達的信息是“我現在不行，稍後可能行”。
429 Too Many Requests
429 的含义是請求本身没問题，但你發得太密了。它通常来自限流层：Nginx 的 limit_req、CDN 的频次規則、WAF 的訪問频率策略，或者應用自己寫的令牌桶。它传達的信息是“慢点来”。
搜尋蜘蛛對這两種响應的處理差异
不同搜尋引擎、不同抓取场景下的行為會有差別，但大方向上可以這样理解：
- 503 更接近“服務不可用”。抓取端一般會認為這是临时故障，倾向于降低對该主机的抓取频率，過一段時間再回来试。如果 503 持續很久，抓取节奏會被明顯压低。
- 429 更接近“频率超限”。抓取端通常理解為需要降速，而不是站点故障，因此更可能調整請求間隔，而不是整体判定该主机有問题。
- 两者都可能触發退避。也就是说，抓取量下降往往不是“被惩罚”，而是抓取端主動放慢了节奏。
- 响應头里的信号很重要。带 Retry-After 的 503 或 429，比不带任何提示的同類响應，更容易让抓取端按你给出的节奏来。
排查时先看這几處
- 日誌里的狀態碼分布。把入口頁日誌按狀態碼聚合，看 503 和 429 各占多少、集中在哪個時間段、是否集中在某台後端或某個 IP 段。
- 响應头。重点看 Retry-After、Cache-Control 以及 CDN 回源相關的头，確認限流是在哪一层触發的。
- 限流規則。检查 WAF、CDN、Nginx 的频次策略里，是否把搜尋蜘蛛的 UA 也一起限了。
- 源站负载。如果 503 集中在流量高峰，多半是源站扛不住，而不是抓取端的問题。
- robots.txt 與抓取設定。確認没有在 robots 里给出互相矛盾的指令，也没有在维護期間忘了恢复。
几個容易踩的誤区
- “返回 503 就等于被降權”。這只是临时不可用信号，真正影响判断的是持續時間和你後續的恢复情况。
- “429 說明被拉黑了”。多數情况下只是限流层生效，不等于封禁。
- “给入口頁加 noindex 就能绕開問题”。noindex 解决的是收錄意图問题，和 503、429 是两件事。
- “把搜尋蜘蛛的 UA 加入白名單就萬事大吉”。白名單只解决限流，源站本身扛不住的問题依然在。
狀態碼是抓取端和你之間的沟通語言。503 说的是“我坏了”，429 说的是“你太快了”，把這两句话听混，排查就會做無用功。
可以怎么處理
如果確認是 503，優先修源站：查看後端進程、连接池、慢查询和上游依赖。维護窗口尽量短，並在维護期間返回带 Retry-After 的 503，而不是直接断開连接。
如果確認是 429，優先調限流：把搜尋蜘蛛的 UA 與普通爬虫区分開，给一個獨立的、相對宽松的配額；同时减少入口頁的連結數量和頁面体积，降低單次抓取對源站的压力。
两種情况都建议持續观察一段時間的狀態碼分布，而不是看某一天的日誌就下结论。抓取量的恢复通常是一個渐進過程，和入口頁的稳定性直接相關。