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 秒后可以”——这比让它面对超时、连接重置或一片空白要有用得多。限速的目的始终是保住服务器的可用性，而不是把抓取通道关掉。