不少站点会遇到这样的情况：白天真人访问高峰时，页面响应明显变慢，同一时间段抓取日志里的超时和 5xx 也跟着变多。这种波动未必是被拦截，也可能只是服务器在同一时段被真人请求和抓取请求一起压住了。抓取时段本身很难直接控制，但站点侧的负载分布是可以调整的。
高峰重叠时会看到哪些现象
如果抓取请求正好落在业务高峰，通常会同时出现几类信号：
- 平均响应时间上升，TTFB 从几百毫秒涨到一两秒甚至更高；
- 部分请求超时中断，蜘蛛可能重试或直接跳过；
- 5xx 返回增多，尤其是依赖数据库或第三方接口的页面；
- 单位时间内成功抓取的 URL 数量下降，抓取节奏被拉长。
这些现象叠加起来，容易让人误判为“抓取被限制”。先区分是限速还是负载，再决定处理方向。
先从访问日志确认时间分布
把访问日志按小时聚合，分别统计搜索蜘蛛请求数量与平均响应时间、错误码占比。重点看两件事：抓取请求最集中的时段，是否与站点自身的访问峰值重合；重合时段内的错误是否集中在少数几类模板页面上。
如果发现错误几乎都出现在需要实时查询的列表页或搜索结果页，而静态的详情页响应正常，那问题更可能在单条路径的实现上，而不是整站带宽不足。
可用的错峰与降载手段
让高峰本身更轻
- 对更新频率低的页面做静态化或长缓存，减少每次请求都回源查询；
- 检查 CDN 缓存命中率，把图片、样式、脚本这类静态资源与页面请求分开承载；
- 梳理慢查询与外部接口调用，避免单个页面拖住整个连接池；
- 为列表页设置合理的翻页上限，减少深分页带来的重复计算。
让抓取路径更省
- 在 Sitemap 中只保留规范 URL，避免同一内容的多个入口被反复抓取；
- 收敛带筛选、排序参数的链接，减少蜘蛛在无效路径上消耗时间；
- 内链尽量指向稳定的规范地址，减少多跳跳转；
- 对确实不需要被抓取的路径，用 robots.txt 明确说明，而不是靠响应变慢来“劝退”。
一份可执行的排查清单
- 导出最近 7 天日志，按小时统计蜘蛛请求量、平均响应时间与错误码分布；
- 标出响应最差的时段，对照站点监控里的 CPU、数据库连接数、带宽曲线；
- 抽样查看该时段的错误 URL，判断是否集中在某一类模板或某几个参数路径；
- 对高频且低价值的入口做缓存或入口收敛，观察下一周期的日志变化；
- 确认没有把正常抓取误当成攻击而触发限速规则，必要时核对放行配置；
- 记录调整前后同一时段的表现，形成可对比的基线。
调整后的观察与回稳
负载类问题通常不会一次调整就彻底消失，需要观察几个抓取周期。建议至少跨过一周，对比同一时段的响应时间、错误率和成功抓取数量，再看变化是否稳定。如果只是把峰值从 A 时段推到 B 时段，说明总量没有降下来，还需要继续从入口数量和页面成本入手。
抓取时段的重合是客观存在的，站点能做的是把单位抓取的成本降下来，让同样的服务器资源能承接更多有效请求。任何调整都不应承诺具体的抓取量或收录结果，只以日志中的实际表现为准。