站点运维里关于抓取速率的抱怨通常有两个方向：一种是蜘蛛来得太密，服务器被打满；另一种是蜘蛛几乎不来，新页面迟迟没人看。这两种情况看着对立，处理逻辑却不一样。抓取速率是蜘蛛根据站点响应情况动态调整的结果，不是一个能随意拧大拧小的水龙头。
速率是谁定的：蜘蛛的参考信号
主流搜索引擎的抓取调度会综合几类信号，其中站点端能直接影响的是前两类：
- 服务器响应时间、超时比例与 5xx 错误率；
- 同一主机下可抓 URL 的总量与更新频率；
- 历史抓取表现，包括连接被拒、重试次数；
- 站点是否让蜘蛛频繁撞上重复地址、空壳页与无意义参数。
站点响应越稳，蜘蛛越可能提高并发；一旦出现持续超时或大面积错误，它通常会自己踩刹车。所以当抓取量突然下降，先别急着找“降权”的原因，看看服务器日志里是不是同一时段出现了 5xx 或响应变慢。
抓得太猛：先分清是错觉还是真问题
有时候“太猛”只是错觉。日志里同一秒出现多条记录，可能来自同一批并发连接，也可能只是不同搜索引擎的蜘蛛叠加，看起来热闹，实际对带宽的压力有限。判断标准应该是：
- CPU、数据库连接数、带宽是否在抓取高峰被明显拉高；
- 是否存在同一个蜘蛛对少量 URL 的重复高频抓取；
- 是否集中在某几个动态接口或筛选参数页上。
如果是最后一种，问题往往不在速率，而在可抓 URL 的边界没划清：参数组合被当成新地址，蜘蛛自然会一遍遍走。这种情况下收紧参数入口、减少重复路径，比降速更有效。
让蜘蛛慢下来：可用手段与边界
- 返回合适的错误码：服务器真的扛不住时，返回 503 并带上 Retry-After，比让请求长时间挂着直到超时更好。持续 5xx 会让蜘蛛降低抓取频率，但滥用会损伤整站信任，只适合短时应急。
- robots.txt 里的 Crawl-delay：只有部分爬虫会遵守，不能当作通用限速开关，写之前先确认目标爬虫的支持情况。
- CDN 或网关层的限速：可以按 User-Agent 单独限流，但要避免把正常抓取一并掐掉，也不要返回让蜘蛛误判为“页面已消失”的状态码。
- 减少被抓对象：把无收录价值的地址挡在抓取之外，比压低整体速率更精准。
什么时候该让它多抓一些
需要“提量”的场景其实很少，而且手段主要是间接的：缩短重要页面的跳转层级、让内链指向稳定、保证响应时间在可控范围、及时清理长期 404 与重定向链。蜘蛛愿意多走，通常是因为走起来顺畅，而不是因为收到了某个提速请求。
一个可执行的检查顺序
- 从服务器日志里按爬虫归类，区分不同蜘蛛的请求量与时段分布；
- 看抓取高峰时段的响应时间、5xx 比例与超时数；
- 确认被抓最多的 URL 是不是重复参数、筛选页或空壳页；
- 检查是否有大面积重定向链与长期存在的错误地址；
- 把无价值地址的入口收掉，再观察一到两周的日志变化；
- 只有确认服务器确有压力且无法从结构上减负时，才考虑限速手段。
抓取速率更像体温而不是旋钮：它反映的是站点当前的健康状况。把响应、结构和可抓边界整理好，速率会自己走回合理区间；反过来，只盯着速率做文章，往往解决不了真正的问题。