很多站点在看抓取数据时只关心“今天被爬了多少次”，却忽略了这些请求分散在哪个时段。把日志按小时聚合之后，通常会看到明显的波峰和波谷：有的时段蜘蛛密集到影响服务器，有的时段几个小时不见一次。先搞清楚波峰的来源，再决定要不要干预，比直接改抓取速率更稳妥。
先把日志按小时切一遍
不需要复杂工具，把最近 7～30 天的访问日志导出，按小时统计三组数字就够了：
- 每个小时的蜘蛛请求数，并按 UA 区分不同来源；
- 每个小时的平均响应时间和 P95 响应时间；
- 每个小时的 5xx、超时、连接中断比例。
注意日志里的时间戳很可能是 UTC 或服务器时区，先换算成主要受众所在的时区，否则容易把凌晨和上午看反。三项数字叠在一起看，往往能发现问题：请求数最高的时段如果同时是响应时间最长的时段，抓取效率其实是打折的，蜘蛛拿到的东西变慢，站点承担的压力也没换来实际价值。
波峰是怎么形成的
蜘蛛什么时候来，站点无法直接指定，但有几件事会影响它的选择：
- 历史响应记录。以前在某个时段响应快，蜘蛛更容易把抓取安排在这个时段；
- 内容更新节奏。固定时间发布新内容，抓取会逐渐向发布时间靠拢；
- 蜘蛛自身的调度。多个站点共享抓取资源，时段会随时变化，不要指望它长期稳定；
- 站点的受众分布。面向不同时区的站点，波峰出现的时间也不同。
所以看到上午被爬了几百次、下午只爬了几十次，多数情况下不是谁在针对你，而是历史响应速度和更新节奏共同作用的结果。想改变这个分布，最直接的办法是让每个时段的响应都足够快，而不是只在某个时段做特殊处理。
高峰期要不要给蜘蛛让路
先判断三件事再动手：
- 抓取高峰和业务高峰是否真的重叠？有些站点用户高峰在晚上，蜘蛛高峰在凌晨，两者互不干扰，就没有必要调整。
- 服务器有没有余量？如果高峰期 CPU、数据库连接数已接近上限，蜘蛛的请求确实会挤占用户请求。
- 抓取是否真的影响了用户？看真实用户的响应时间和错误率，而不是只看蜘蛛的。
如果三条都成立，优先做的也不是封禁，而是降低单次抓取的代价：给静态资源加缓存、缩短动态页面的数据库查询、把列表页和详情页的渲染拆开、对未变化的页面返回 304、避免返回体积异常的 HTML。只有当服务器确实扛不住时，才考虑用限速把抓取流量引导到负载较低的时段。
robots.txt 里的 crawl-delay 只有部分搜索引擎支持，主流引擎大多忽略。想调整抓取节奏，更可靠的做法是在负载过高时对蜘蛛请求返回 503 并带上 Retry-After，让蜘蛛自行退避，同时在站长后台持续关注抓取统计的变化。
哪些情况其实不用调
如果日志里没有明显超时、5xx 比例很低、用户侧响应正常，那么抓取量的波动属于正常现象。频繁调整反而会让蜘蛛重新试探，抓取节奏变得更不稳定。抓取速率是蜘蛛根据历史表现自己算出来的，站点能做的是别让它算错：保持稳定响应，别让它在某个时段连续失败。
一份可执行的自查顺序
- 导出近 30 天日志，按小时聚合并换算时区；
- 标出抓取请求数、响应时间、错误率三条曲线的重叠区间；
- 确认该区间的负载来自蜘蛛还是真实用户；
- 先做缓存、查询优化和 304，再评估是否需要限速；
- 调整后观察两周，看抓取量是否回升、错误率是否下降，再决定是否继续。