抓取日志里最常被用到的数字是总量和状态码，时间维度反而经常被忽略。把一天的请求按小时分组，画出一条访问曲线，就能看到蜘蛛在哪些时段更活跃、哪些时段几乎不进站。曲线的形状，通常比总量更能说明站点和抓取端之间的配合状态。
为什么时段比总量更稳定
抓取总量容易被外部因素带偏：提交一次 Sitemap、被一个大页面推荐、站内新增几千条 URL，都可能让当天数字突然放大。时段分布则相对稳定，它更多反映抓取端对站点的调度习惯——什么时间分配了多少抓取资源，以及站点在那些时间是否回应得足够快。
如果曲线的峰谷长期漂移，通常是站点这边发生了变化：响应变慢、部分 URL 返回错误、robots.txt 或 CDN 规则改动，都会在时间轴上留下痕迹。
日志里常见的三种曲线
平缓型
各小时抓取量差异不大，白天略高、凌晨略低。这类站点一般是更新节奏稳定、URL 总量不大且结构清晰。它不代表抓得更多，只是抓取端的调度没有明显波动。
尖峰型
大部分请求集中在少数几个小时，其余时段很低。常见于更新集中在某个时间点发布的站点，也可能是抓取端把有限资源攒在某一时段使用。尖峰本身不是问题，问题在于尖峰时段服务器同时要服务真实用户，响应时间容易被拉长。
断续型
曲线忽高忽低，中间有大段空白。这种形态更值得排查：可能是站点在某些时段对抓取端返回了 5xx 或超时，也可能是 CDN、防火墙规则按区域或按 UA 做了拦截，让一部分请求根本没到达源站。
把更新节奏往抓取高峰靠一靠
新页面被发现之后，还需要一次实际抓取才会进入后续处理。如果发布时间和抓取高峰错开较远，中间就会多出一段等待。可以做的调整比较朴素：
- 把例行更新放在固定的时间窗口，让抓取端的调度更容易形成规律；
- 发布后立刻通过内链把新 URL 挂到已有页面，而不是只等 Sitemap 被读取；
- 列表页、栏目页保持可访问，让蜘蛛顺着结构往下走时不会断在中途；
- 批量发布时分散到多个时间点，避免短时间内产生大量新 URL 挤在同一队列里。
服务器负载和抓取时段重叠怎么办
抓取高峰如果正好撞上业务高峰，两边会互相拖慢。比较稳妥的处理顺序是：先确认源站响应时间是否稳定，再考虑缓存静态页面、把动态查询结果做短时缓存，最后才谈限速。限速本身也会带来代价——被压低之后，重新爬升需要时间。
如果确实需要在高峰期降低抓取压力，用 429 配合 Retry-After 明确告知等待时间，比直接返回 403 或断开连接更友好，也更容易让抓取端按预期退避。
一个简单的观察循环
- 每天记录各小时抓取量、平均响应时间和状态码分布；
- 标出更新发布的时间点，看新 URL 首次被抓大概落在发布后多久；
- 把响应异常的时间段和服务器监控对照，确认是源站问题还是中间层拦截；
- 每次只调整一个变量，观察一到两周再决定是否继续。
抓取曲线只是一个观察工具，它说明的是“发生过什么”，不能保证某个页面一定会被收录或排名。把时段、响应和结构一起看，比盯住单一数字更有用。