先把结论说清楚
503、429 在搜索蜘蛛眼里属于“暂时拿不到”，不等于“这个页面没了”。所以它通常不会马上把你这个 URL 从索引里删掉，也不会立刻放弃，而是往后放一放，隔一段时间再回来试。代价是：整个站点的抓取频率会被拉低，同一时间其他正常 URL 也跟着少抓。入口页做得再顺，目标 URL 一直拿不到内容，这条链路就等于空转。
5xx、429、403、404 对搜索蜘蛛不是一回事
- 404 / 410：内容不存在。通常会停止重试，索引里慢慢清掉。
- 500：服务器内部错误，一般当作临时故障，会重试。
- 503：服务暂时不可用。如果带上 Retry-After 响应头，重试节奏会更明确。
- 429：请求过多被限流，同样是临时性质，但会被当成“抓太快了”，抓取速度会往下调。
- 403：权限被拒。短时间出现没什么，长期如此会被视为无法访问，和 404 的结果接近。
区分这四类的意义在于：如果只是临时限流，你的处理方式是降低压力；如果已经变成长期 403，那问题在规则配置，不在服务器性能。
入口页返回 503，比目标 URL 返回 503 更麻烦
目标 URL 挂了，损失的是那一条 URL 的抓取机会。入口页挂了，损失的是发现层：搜索蜘蛛这次来什么都没看到，也就不会知道底下那些目标 URL 还在。多个入口页如果都指向同一个不稳定的服务器，很容易出现“一次全挂”的情况。建议把入口页和业务页分开部署，至少不要让它们共用同一台容易被打满的机器。
限流到底是谁在限，按这个顺序查
- 看服务器负载和连接数，是不是并发被打满，正常请求也在排队超时。
- 看 CDN 或 WAF 的拦截日志，规则是不是把来源 IP 段整体拦了，返回 403 或 503。
- 看程序自身有没有对 UA 或 IP 做速率限制，被限的请求返回的是 429 还是自定义空页。
- 对照访问日志里的状态码分布，确认是全局性问题还是集中在某几个路径。
几个容易踩的坑
- 软 503：服务器明明撑不住，却返回 200，页面正文写着“系统繁忙”。搜索蜘蛛认为抓取成功，拿到的是空内容，重试机制也用不上，反而更容易被判定为低质量页面。
- 计划维护不写状态码：维护期间直接返回 200 加一个提示页，效果和上面一样。需要停机时返回 503 并带上 Retry-After 更合适。
- 用改 URL 绕限流：不断换新地址并不能解决压力问题，还会让一批 URL 都处在半死不活的状态。
- 靠 503 屏蔽蜘蛛：这是个误解。长期 503 只会让抓取频率持续走低，真实用户访问同样受影响。真要控制抓取，用 robots.txt 或服务器端的正常限速手段。
判断标准很简单：这个 URL 现在是真的拿不到内容，还是服务器在正常返回一个空壳。前者是状态码问题，后者是内容问题，两者的处理方式完全不同。
日常可以固定做的几件事
- 在日志里按状态码分组，定期看一眼 5xx 和 429 的占比，占比高了先查基础设施，而不是先怀疑蜘蛛池。
- 入口页保持轻量、稳定，不要和重业务接口绑在同一资源池里。
- 限流阈值给爬虫留出余量，一旦误伤，恢复期往往比预想的长。
- 确保 robots.txt 没有把入口页或目标目录意外封掉，这类问题和 403 经常一起出现。
抓取是长期动作，任何一次大规模 5xx 都会在之后一段时间里留下痕迹。与其反复换入口页、换链接形式，不如先把“目标 URL 能不能稳定返回内容”这件事做扎实。