不少站点在抓取异常时的第一反应是“蜘蛛来得太少”。但另一个同样常见的问题是反过来的：蜘蛛来得太频繁，服务器扛不住，于是开始返回 429 或 503，抓取量反而掉下去。抓取速率本质上是站点与搜索引擎之间的一次协商，站点并不是只能被动接受。
抓取速率由哪几方共同决定
- 搜索引擎的全局调度：不同引擎、不同站点权重，默认并发和频次并不相同。
- 站点声明：robots.txt 里的 crawl-delay，以及 HTTP 响应中的限速状态码。
- 平台侧设置：部分站长平台提供抓取频次或爬虫压力反馈入口。
- 服务器实际能力：带宽、CPU、数据库查询耗时、动态渲染开销。
任何一方单独变化，效果都会被另外几方抵消。所以调整之前，先确认自己面对的瓶颈究竟在哪一层。
三类常见的限速信号及适用范围
robots 中的 crawl-delay
在 robots.txt 中写 User-agent: * 与 Crawl-delay: 5，表示希望同一爬虫两次请求之间间隔约 5 秒。需要注意的是，各引擎对这个指令的支持程度并不一致，有的完全忽略，有的只对特定 UA 生效。把它当作建议而非开关，写完要用日志验证请求间隔有没有变化。
429 与 503 状态码
当服务器压力过大时，返回 429（请求过多）通常比返回 500 更合适，因为它语义明确，属于可恢复的限速信号。503 配合 Retry-After 响应头，可以告诉爬虫多久之后再试。两点要注意：一是不要长期返回 429/503，否则容易被理解为站点持续不稳定；二是不要用 200 状态码承载“稍后再来”的提示页，那只会让爬虫继续消耗抓取预算。
平台侧的抓取频次设置
部分站长平台允许手动指定抓取频次，或提供爬虫压力反馈。这类数值更像上限性质的建议值：调高不会立刻带来更多抓取，调低却会实际压低请求量。改动的观察周期通常需要几天到一两周，不宜频繁来回切换。
从访问日志读出真实压力
调整之前，先用日志确认现状，重点看以下几组数据：
- 单位时间内的蜘蛛请求数，按分钟聚合，观察峰值而非只看均值。
- 并发连接数，以及这些连接是否集中在少数耗时接口上。
- 响应时间分布，平均耗时容易被少量极慢请求拉偏，看 P95 更有参考价值。
- 状态码构成，以及 429、503、5xx 的占比和出现时段。
- 字节速率，大页面和大图片占用的带宽往往比页面数量更致命。
如果请求峰值恰好与业务高峰重叠，问题可能不是“抓取太多”，而是“抓取时段不合适”。
调整顺序：先保稳定，再谈提速
- 先解决导致超时的根因，例如慢查询、同步渲染、未加缓存的热点接口。
- 再为蜘蛛配置相对独立的资源配额或缓存策略，避免与真实用户争抢。
- 然后在 robots 或平台侧设置一个偏保守的频次，观察一到两周。
- 确认错误率、响应时间稳定后，再以较小幅度逐步上调。
- 每次调整后保留对照数据，避免多因素同时变化导致无法归因。
抓取速率调整的目标不是让蜘蛛来得更多，而是让每一次抓取都能拿到有效内容。稳定性下降时，抓取量的增长通常也维持不住。
几个容易踩的坑
- 用 IP 封禁代替限速：短时封禁可能触发更长的退避，恢复周期比预期更久。
- 对整站统一限速：栏目页、列表页与详情页的开销差别很大，分级处理更合理。
- 只在 robots 里写了 crawl-delay 就认为万事大吉，忽略日志验证。
- 把 429 当成长期补丁挂着，掩盖了真实的性能问题。
最后提醒一点：抓取速率与 URL 发现、内链结构是相互影响的。如果站点存在大量低价值入口，即使把速率调高，抓取预算也会被消耗在意义不大的页面上。先理清入口，再谈速率，往往更省力。