抓取日志里，URL 和状态码最容易被注意，时间戳往往被跳过。但把时间戳单独拿出来按小时聚合，能得到一条很实用的信息：搜索蜘蛛一天里大致什么时候来、来得多密、有没有整段空白。这条信息直接影响两件事——服务器限速怎么设、维护窗口怎么排。
先对齐时区，再谈时段
日志时间不准时，后面所有结论都会偏。常见三种时间源要分清：
- 源站 Nginx / Apache 日志默认写服务器本地时间，行尾会带 +0800 之类的偏移；
- CDN 与云负载均衡日志多数用 UTC；
- 后台报表（Search Console 等）用的又是另一套时区，且按天聚合，不按小时。
把 UTC 当成东八区看，抓取高峰会凭空前移八小时。核对方法很简单：取一条自己手动访问的请求，看它在日志里的时间戳和实际点击时间差多少。
按小时聚合，看分布的形状
把某一天的抓取请求按小时分组，画成一根根柱子。正常的形态通常是全天铺开、白天略高、夜间不断流。真正值得关注的是两种形状：
- 极度集中：几十秒内几百个请求，之后长时间安静。这可能是抓取端在短时间内消耗完配额，也可能是站点把大量 URL 同时暴露了出去，值得回看当天有没有批量发布或 Sitemap 大改。
- 整段空白：连续几小时零抓取。先排除日志采集断档、CDN 回源规则变更，再考虑是不是那段时间服务器返回了大量超时或 5xx，把抓取端劝退了。
单日数据噪声大，建议看七天滚动，避免被一次活动带偏。
抓取高峰和站点高峰撞车
抓取请求本身也占连接数。如果站点的访问高峰和抓取高峰重叠，再叠加一次全站发布或缓存刷新，响应时间容易被推上去。比较稳妥的做法是：
- 批量操作（改版、批量改标题、强制刷缓存）避开日志里抓取最密的那一两个小时；
- 给动态接口单独预留资源，别让抓取和用户请求抢同一个连接池；
- 发布节奏尽量平摊，而不是一天里全部堆在一个时间点。
维护窗口不要靠“关站”来猜
很多人默认凌晨蜘蛛不来，于是把维护安排在凌晨。抓取时段是分散的，凌晨同样可能有请求。与其猜，不如用响应状态表达：
维护期间让服务器明确返回 503，并在 Retry-After 里写清预计恢复时间，比直接断连、返回超时或返回 200 空页面都更容易被正确理解。
断连和超时会让抓取端把这段时间记为失败，重试时机不可控；200 空页面则更麻烦，等于告诉对方“内容就是这样”，容易留下空壳记录。503 是临时性信号，语义清晰。
限速和抓取节奏怎么配合
如果你发现某些时段抓取过密、拖慢了服务，优先用限速而不是拦截：
- 先确认是不是自己的链接结构把对方引到了同一批 URL，比如列表页无限下拉、筛选参数相互引用；
- 服务器侧对单个来源设并发上限，超出的请求返回 429 或 503，而不是排队到超时；
- 把重点页面（首页、栏目页、近期更新）留在正常响应里，非重点页面允许被延后。
需要说明的是，限速只能影响节奏，不能决定对方来不来、抓多少。它解决的是“别把服务器拖垮”，不是“多抓一点”。
可以固定下来的核对动作
- 确认日志时区，并和手动访问记录比对一次；
- 按小时聚合最近七天抓取量，找出高峰段和空白段；
- 把高峰段和站点自身的发布、缓存刷新、备份任务对照，看有没有撞车；
- 检查空白段前后是否有集中 5xx 或超时；
- 调整维护窗口与限速参数，观察一周后再看分布形状。
抓取时段属于操作层信息，它的价值在于帮你安排维护、限速和发布节奏。至于抓多少、抓多快，仍然取决于页面质量、链接结构和服务器是否稳定——把这几件事做好，比精确计算蜘蛛几点来更划算。