做站点运营的人常会遇到一个现象：蜘蛛池入口页本身没什么改动，搜索蜘蛛的抓取量却突然下降。翻日志发现，入口页返回的要么是 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 与普通爬虫区分开，给一个独立的、相对宽松的配额；同时减少入口页的链接数量和页面体积，降低单次抓取对源站的压力。
两种情况都建议持续观察一段时间的状态码分布，而不是看某一天的日志就下结论。抓取量的恢复通常是一个渐进过程，和入口页的稳定性直接相关。