先确认压力是不是蜘蛛造成的
服务器一慢，很多人的第一反应是蜘蛛抓太狠了。但在动手限速之前，先把访问日志按 UA 和路径分组看一遍：蜘蛛请求占总请求的比例是多少、集中在哪些 URL、这些 URL 的平均响应时间、5xx 出现在哪个时间段。有些站点其实是自身的慢查询或缓存失效拖垮了响应，蜘蛛只是恰好在那时来访，把原因归到抓取上，后面的动作就会做偏。
一个简单的判断方法：蜘蛛请求只占总请求的一小部分，而响应时间已经很长，问题多半在应用层；蜘蛛请求量明显高于平时，且集中在列表页、筛选页、站内搜索这类一个入口就生成一批 URL 的位置，才轮到抓取节奏这个话题。
robots.txt 里的 Crawl-delay 能指望多少
Crawl-delay 是最省事的写法，但各家支持情况并不统一。Google 明确不遵循这个指令，它按自己的抓取预算和服务器响应状况来调整；部分其他爬虫会读取并遵守。写上去没有坏处，但不能把它当成限速的主力。
同样需要留意的是 Disallow。临时限流时用 Disallow 关掉一批目录，蜘蛛会把这些 URL 从抓取队列里清掉，等你放开之后要重新经历一轮发现，恢复得比预期慢。限流和屏蔽是两件事，尽量不要混用。
服务器端和 CDN 层的限速更可控
真正管用的措施通常在离服务器最近的地方：
- 按 UA 或 IP 段限制并发：在 Nginx、WAF 或 CDN 上给已知爬虫单独的并发上限，与正常用户流量分开，避免限速误伤真实访客。
- 返回 429 而不是 403 或 5xx：429 表示请求过多、请稍后再来，蜘蛛会退避重试；长期 403 容易被理解成拒之门外，5xx 则会被当成服务器故障，两种反应都不是你想要的。
- 配合 Retry-After：在 429 响应里给出建议等待时间，比让蜘蛛自己猜要温和。
- 让缓存层多挡一层：静态资源和模板化列表页尽可能命中 CDN 缓存，蜘蛛拿到的是缓存副本，源站压力会小很多。
限速的目标不是让蜘蛛少来，而是让它每次来都能拿到稳定的 200。宁可慢一点、稳一点，也不要快而乱。
限速之外，先减少低价值抓取
如果站点每天被大量参数 URL、站内搜索结果页、重复排序页消耗掉抓取额度，与其硬顶并发，不如先收缩这些入口：
- 筛选和排序参数尽量做规范化，让一组参数只对应一个可抓取 URL；
- 站内搜索结果页用 robots.txt 或 noindex 明确挡掉，别让它们进入索引；
- 列表页的分页保留真实的分页链接，不要把加载更多全部交给接口；
- 检查 Sitemap 里是否存在已失效、已合并的旧地址，减少蜘蛛对无效 URL 的重复确认。
把这些做掉之后，同样的抓取总量会更多落在有价值的页面上，服务器承受的无效请求也会同步下降。
限速之后要盯什么
限速不是设置完就结束了。调整后的一到两周，重点看几个指标：蜘蛛请求数是否落到可接受区间、平均响应时间是否回落、5xx 比例是否降下来、被抓取的 URL 中有效页面占比是否上升。如果抓取量降了，有效页面被抓的次数也一路跟着降，说明限速过头了，需要把阈值往上调。
另外，日志里如果出现某个 IP 段请求量异常大且不遵守 robots.txt，先别急着一刀切封网段，先确认是不是自己站点上的递归调用或镜像导致的。误封正常爬虫，恢复起来往往比限速本身更麻烦。