429 不是“封禁”，而是一次减速信号
当服務器返回 429 Too Many Requests，意思是“請求太多了，先停一停”。它和 403 不同，403 更像拒绝訪問，429 則是限流。對搜尋蜘蛛来说，429 通常不會直接導致頁面被永久放弃，但會打乱原本的抓取节奏。蜘蛛會根據响應头、歷史抓取表現和站点整体稳定性，决定是降低频率、延後重试，還是暂时减少對该目錄的抓取。
很多站点在压力大时會用防火墙或 CDN 規則统一返回 429，這能保護源站，但也可能让蜘蛛把“暂时繁忙”理解成“這個站点不太稳定”。如果 429 持續出現，抓取队列里的 URL 可能被排到更後面，新頁面和更新内容的發現速度也會變慢。
Retry-After 是给蜘蛛的等待提示
429 响應里可以带一個 Retry-After 头，告诉客戶端多久之後可以再试。它可以是秒數，也可以是一個 HTTP 日期。蜘蛛通常會參考這個值来調整重试時間，而不是立刻反复請求。
如果 Retry-After 设得太短，蜘蛛可能很快回来，服務器压力没有真正缓解；设得太長，又可能让正常抓取被拖延。
比較稳妥的做法是结合目前负载設定一個合理的等待窗口，比如几分钟到几小时，而不是几秒。對于短期高峰，可以短一些；如果是計划内维護或持續限流，宁可長一点，也不要让蜘蛛在门口反复撞。
429、503 和 Crawl-delay 各管什么
- 429：针對“請求频率過高”的限流，适合短时保護。
- 503：表示服務暂时不可用，更适合维護、過载或後端故障；带 Retry-After 同样有用。
- Crawl-delay：寫在 robots.txt 里，是站点對抓取間隔的長期建议，但支持程度不一。
三者不要混用。比如源站已经恢复，却因為 CDN 缓存或規則繼續返回 429，蜘蛛會一直收到错誤的减速信号。反過来，如果只是某個接口被刷，却把整站都设成 429，也會誤伤正常的頁面抓取。
站点侧可以做的几件事
- 先看日誌里 429 的比例和来源。如果集中在少數路径，優先修這些路径的限流規則，而不是全站加碼。
- 检查 Retry-After 是否合理，避免過短或過長；没有這個头时，蜘蛛只能按自己的策略退让。
- 区分蜘蛛與普通用戶的限流策略。可以用 User-Agent 或反向 DNS 驗證，但不要完全依赖 UA 做唯一判断。
- 如果站点長期资源紧張，先優化動態查询、缓存和資料库，再考虑調整抓取频率。
- 观察抓取覆盖和服務器错誤率的變化。429 下降後，抓取节奏通常會逐步恢复，但不會瞬間回到原水平。
別让限流變成長期狀態
429 适合應急，不适合当常態。長期返回 429，等于不断告诉蜘蛛“這里很挤”。蜘蛛可能會减少對站点的抓取投入，把预算分给更稳定的站点。對于内容更新频繁的栏目，這種减速會直接影响新 URL 的發現和舊頁面的重訪。
如果确實需要控制抓取，優先用 robots.txt 的 Crawl-delay 或更精细的路径規則，並确保規則不會挡住關键頁面。限流的目标是保護服務器，而不是把蜘蛛挡在门外。
最後，定期從服務器日誌里看 429 的時間分布和路径分布，比只看單日總數更有用。抓取节奏的變化往往先出現在日誌里，再反映到抓取覆盖資料上。