搜索蜘蛛来访本身不产生收益，但它消耗的是和真实用户同一份服务器资源。当一批 URL 同时被抓取，尤其是详情页需要查库、拼装模板或调用接口时，站点响应会明显变慢；而变慢又会反过来让蜘蛛降低抓取频次。要处理这个问题，先把两件事分开：是蜘蛛请求太集中，还是站点本身容量就不够。
先判断瓶颈落在哪一层
翻一段时间的日志，把蜘蛛请求的响应时间和普通用户请求放在一起对比。如果只有蜘蛛这批请求变慢，多半是并发太高；如果用户侧同样慢，那就是容量问题，单靠限速解决不了。
- 单 IP 并发数：短时间内同一来源打出大量请求，通常是调度集中的表现
- 慢查询比例：详情页动态生成，抓取一次等于跑一遍完整业务逻辑
- 带宽占用：图片、脚本等子资源被成批拉取，抢占了出口带宽
- 缓存命中率：命中率低时，每次抓取都直接回源打到数据库
限速该放在哪一层
robots.txt 里的 crawl-delay 只对一部分蜘蛛生效，可以写，但不要当成主要手段。更稳妥的做法是在反向代理或 CDN 层按 User-Agent 和路径做速率控制，这样对来访方是否遵守约定不敏感。
- 先给蜘蛛单独划一个并发上限，避免它挤占用户通道
- 再把列表页、筛选页、排序页这类重复度高的地址限得更紧一些
- 详情页等真正需要被收录的页面，保留相对宽松的额度
- 对明显异常的高频请求可以返回 429，但不宜作为常态手段
资源有限时该优先保住哪些页面
总量固定，就需要排一个先后顺序：首页、栏目页、更新频繁的详情页优先；参数组合页、历史归档、站内搜索结果页可以放慢。这个顺序最好和 sitemap 里的权重设置、站内链接密度保持一致，不要出现地图里标成重点、限速时又被压到最低的矛盾。
降级时不要用 503 糊弄
如果服务器确实过载，短时间内返回 503 并带上 Retry-After，比让请求直接超时更清楚，蜘蛛能识别这是暂时状态。但要注意两点：长时间反复返回 503，蜘蛛会逐步减少来访；如果只是想让某些页面不被抓，应该用 404、410 或 robots.txt，而不是拿 503 顶替。状态码用错，损失的是整站的抓取信任。
找到抓取量和承载力的平衡点
需要盯的指标并不复杂：蜘蛛请求量、平均响应时间、5xx 比例、缓存命中率。调整一次之后观察几天再决定下一步，不必天天改配置。稳定比激进更重要——让蜘蛛每次来都能顺利取走页面，比偶尔多抓几千个 URL 更有价值。
限速的目标不是把蜘蛛赶走，而是让它抓得久、抓得稳，让抓取节奏和站点的实际承载能力对得上。