站长常把注意力放在“蜘蛛来了没有”，却容易忽略另一面：抓取本身就是一串真实的 HTTP 请求，它和你自己的用户共用同一份 CPU、带宽、数据库连接和磁盘 IO。当页面变重、模板里多了几个实时查询，抓取压力就会和真实流量叠加，表现为响应变慢、连接超时，甚至零星 5xx。要判断抓取是否顺畅，先要看服务器还有没有余量，而不是只盯着日志条数。
蜘蛛请求的负载画像
不同类型的 URL，抓取成本差别很大。同样是“一次请求”，静态页和带筛选的列表页对后端的压力可能差一个数量级。
- 静态页与缓存命中的页面：成本最低，通常只消耗带宽和连接数。
- 列表页翻页与筛选参数页：容易触发多次数据库查询，是负载的主要来源。
- 搜索页、价格比较页、日历类页面：如果允许被抓，可能产生大量组合 URL，压力会放大。
- 静态资源：单次开销小，但数量多，带宽占用不容忽视。
把这几类分开看，才知道限速该限在哪儿。对高成本路径收紧，比对全站统一降速更有效。
先量化：日志里要看的几个数
不量化就只能凭感觉调。按小时切分服务器日志，统计下面几项，通常两三天就能看出规律。
- 单位时间的蜘蛛请求数，以及它占全部请求的比例。
- 抓取高峰出现的时段，是否和业务高峰重叠。
- 被请求最多的前 20 条路径，看有没有无意义的参数组合。
- 蜘蛛请求的 5xx 比例与平均响应时间，和普通用户对比。
- 响应时间的分位数，而不只是平均值——平均 200 毫秒背后可能藏着大量 3 秒以上的请求。
能调的旋钮有哪些
robots.txt 里的 crawl-delay
需要说明的是，主流引擎中明确支持 crawl-delay 的以 Bing 等为主，Google 并不依赖这条指令来调度抓取。把它当作兜底手段可以，但不要指望它解决全部问题。对不支持的引擎，服务器侧的限制更实际。
WAF 与速率限制
不少“蜘蛛被挡”的情况，其实来自 CDN 或云 WAF 的通用反爬规则：短时间高频访问、缺少常见浏览器指纹、命中某条频率阈值，都会被拦下来。处理方式不是简单放宽阈值，而是先核对来源——反向解析、UA 与官方公布的 IP 段三者比对后再放行，误伤会少很多。
页面本身的成本
抓取慢，多数时候不是蜘蛛慢，而是页面本来就慢。给列表页加缓存、减少同步的外部调用、把实时统计改成定时任务，往往比调限速更省事。
抓取时段与发布节奏
大规模生成新 URL、上线新目录、批量推送 Sitemap，这些动作会让蜘蛛在短时间内集中来访。如果又恰好压在业务高峰，服务器很容易吃不消。
- 批量发布安排在访问低谷，给抓取留出缓冲。
- 新目录上线时先放出部分入口，让蜘蛛分批发现，而不是一次性挂上几万条链接。
- 大促、秒杀等确定性高峰前，提前检查缓存命中率和 5xx 比例。
蜘蛛的抓取请求是可以用日志预测的流量。既然能预测，就不该让它成为压垮服务器的意外。
不建议一路限到底
另一个极端是把速率压得极低。抓取被过度限制后，新页面和更新的 URL 被发现的速度会明显变慢，问题排查时也更难拿到足够的抓取样本。限速的目标是让抓取有节奏地发生，而不是让它停下来。判断标准可以很简单：蜘蛛的 5xx 比例接近零、响应时间在可接受区间、业务高峰时段服务器仍有明显余量。三条都满足，就不必再往下压。