先把结论说清楚
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 能不能稳定返回内容”這件事做扎實。