429 不是把蜘蛛拒之门外
429 Too Many Requests 的意思是：服務器還在，也能處理請求，只是你現在這個速度我接不住。它和 403、404 的性质完全不同——後两者表示“没有”或者“不给”，而 429 表示“等一會儿再来”。對搜尋蜘蛛来说，這個区別會直接影响它接下来怎么安排你的站点：前者是可协商的临时狀態，後者是明确的拒绝。
Retry-After 怎么给
429 本身只表達了“太快了”，但快到什么程度、什么时候能回来，需要 Retry-After 响應头来說明。常见的两種寫法：
- 秒數：例如 Retry-After: 30，表示 30 秒後可以再试。實現简單，推荐優先用這種。
- HTTP 日期：例如一個具体的 GMT 時間点。适合你已经有明确恢复时刻的情况，但要留意服務器时钟偏差。
如果两個都不寫，蜘蛛只能自己猜一個退避区間。猜得保守，抓取恢复得慢；猜得激進，你這邊又會再被压一遍。與其让它猜，不如把時間说清楚。
什么场景适合用 429
- 站点有整点批量任務、定时導出或後台重建索引，带宽和连接數被占满的一小段時間；
- 活動開始前後，查询較重的動態頁面压力骤增；
- 某個目錄下的接口型頁面本身就不适合高频抓取。
需要提醒的是，429 是临时手段，不适合当作長期策略。如果蜘蛛每次来都吃 429，它不會跟你死磕，而是降低對這個站点的訪問频次，把抓取安排挪到別處。抓取量掉下来容易，恢复起来慢。
几類常见的誤用
- 返回 429 却不带 Retry-After：蜘蛛只能凭经驗退避，恢复节奏不可控。
- 全站一刀切：首頁、栏目頁、静態资源一起被限速，连正常的少量訪問也進不来，日誌里會出現大段 429。
- 把 429 当 403 用：想屏蔽某個目錄却返回 429，蜘蛛會理解成只是暂时狀態，過段時間還會回来敲门，不如用 403 或 robots.txt 明确表達。
- 只在 CDN 或 WAF 层限速：源站日誌看不到 429，只看到流量曲线掉下去，排查时容易誤判成服務器故障。
限速之後，怎么確認没有伤到自己
調整完限速規則，最好连着几天看几件事：狀態碼分布里 429 的占比是不是在下降；同一批 URL 的再次抓取間隔有没有被拉長；服務器响應時間是否回到正常区間。如果 429 消失了，但蜘蛛来的次數也明顯變少，說明限速期間的体驗已经影响到它的調度判断，這时需要让它重新確認站点是稳定的。
恢复期可以分几步走
- 先把限速阈值放宽一档，不要一次性全部取消，观察半天的响應時間再决定下一步。
- 按目錄放開，優先放開内容頁，接口型和搜尋结果頁繼續保留限制。
- 把静態资源和 HTML 分開處理，图片、CSS、JS 這類资源通常不占資料库连接，没必要跟着一起限。
- 如果最近改過站点结构或上线了新頁面，恢复抓取节奏时可以顺带检查 Sitemap 和内鏈是否同步，別让蜘蛛回来之後走進死胡同。
和 robots.txt 里的 crawl-delay 怎么分工
crawl-delay 更像進门之前商量好的速度，粒度粗，而且並不是所有蜘蛛都遵守；429 更像進门之後临时的红绿灯，可以按路径、按時間段、按目前负载動態調整。两者不冲突，但也不该互相替代。稳態用小阈值，突發用 429，是相對好维護的组合。
小结
蜘蛛能不能稳定抓取，很大程度上取决于它每次来的时候，站点给不给得出确定性的回應。429 加上明确的 Retry-After，等于在说“現在不行，X 秒後可以”——這比让它面對超时、连接重置或一片空白要有用得多。限速的目的始终是保住服務器的可用性，而不是把抓取通道關掉。