抓取速率不是站点单方面能定的
不少站长以为在 robots.txt 里写一句 Crawl-delay，或者在服务端设定好抓取速度，蜘蛛就会照着执行。实际情况是：抓取速率是搜索引擎根据站点表现动态调整的结果，站点能做的更多是创造条件，而不是下命令。Crawl-delay 只有部分爬虫支持，主流搜索引擎更看重自己测到的响应时间和错误率。
这件事和 URL 发现直接相关：蜘蛛愿意开多少并发、多久跑一轮，决定了队列里那些已经被发现、但还没被抓取的 URL 要等多久。
响应时间决定了蜘蛛愿意开多大并发
调度逻辑并不复杂。如果每次请求都很快返回，蜘蛛会认为站点还有余力，于是提高并发、缩短回访间隔；如果请求经常要等两三秒，它会主动降速，既不把站点压垮，也不浪费自己的资源。
所以优化抓取速率的第一件事不是催，而是让页面变便宜：
- 静态资源和入口页尽量走 CDN 或反向代理缓存；
- 列表页、分类页这类被抓取最频繁的模板，做好数据缓存；
- 避免页面渲染时同步调用外部接口，尤其是容易超时的接口；
- 数据库慢查询单独排查，列表页的首字节时间通常卡在这里。
错误率是速率的刹车
比慢更糟的是错。5xx 和连接超时会被记为失败，失败比例一高，抓取速率会被明显压低，而且恢复需要一段时间。几个常见坑：
- 限流误伤：站点自己的防护规则把蜘蛛当成异常流量拦掉，返回 429 或 403；
- 发布时短暂宕机：批量生成静态页或重建缓存时，站点整体不可用；
- 个别页面拖垮整体：某个页面查询极慢，蜘蛛的并发请求都堵在这类 URL 上。
如果确实需要临时维护，返回 503 并带上 Retry-After，比直接返回 404 或 500 更合适。前者表示暂时不可用，后者容易被理解成页面消失或站点故障。
用日志估算站点能承受的量
与其猜，不如看日志。把最近一段时间的蜘蛛请求按小时统计，重点看：
- 峰值时段每小时来了多少请求；
- 这些请求的平均响应时间与 P95 响应时间；
- 其中有多少是 5xx、429 和超时；
- 被抓取的 URL 里，有多少是你真正希望被发现的。
如果峰值时段响应时间明显抬升，说明当前速率已经接近上限，再提高只会带来更多失败；反过来，如果响应时间平稳、错误率极低，说明还有余量。
让值得抓的 URL 优先被消耗
速率提升之后，真正被消耗的是抓取队列。队列里的 URL 越多、越杂，有效页面分到的时间就越少。所以速率和 URL 质量要一起看：
- 参数页、筛选组合、无内容的空结果页尽量挡住，别让它们占队列；
- Sitemap 只放需要被抓的规范地址，不要把全部历史 URL 都塞进去；
- 重要栏目放在浅层，靠稳定的内链让它们持续被回访。
这几点做好之后，同样的抓取速率能覆盖更多有效页面。
几个实际取舍
与其追求蜘蛛来得越多越好，不如追求每次来都能顺畅抓完该抓的页面。
大促、上线、发布会这类流量高峰，不要同时做全站重建和大规模 URL 变更，容易把响应时间和错误率一起推高。日常则可以持续观察首字节时间、5xx 比例和蜘蛛请求量三者的关系，提前发现容量问题。
最后提醒一点：抓取速率是结果，不是开关。站点响应快、错误少、结构清晰，蜘蛛自然会来得更勤；反过来，任何单点优化都很难长期奏效。