抓取日誌里，URL 和狀態碼最容易被注意，時間戳往往被跳過。但把時間戳單獨拿出来按小时聚合，能得到一條很實用的信息：搜尋蜘蛛一天里大致什么时候来、来得多密、有没有整段空白。這條信息直接影响两件事——服務器限速怎么设、维護窗口怎么排。
先對齐时区，再谈时段
日誌時間不准时，後面所有结论都會偏。常见三種時間源要分清：
- 源站 Nginx / Apache 日誌預設寫服務器本地時間，行尾會带 +0800 之類的偏移；
- CDN 與云负载均衡日誌多數用 UTC；
- 後台报表（Search Console 等）用的又是另一套时区，且按天聚合，不按小时。
把 UTC 当成東八区看，抓取高峰會凭空前移八小时。核對方法很简單：取一條自己手動訪問的請求，看它在日誌里的時間戳和實际点击時間差多少。
按小时聚合，看分布的形状
把某一天的抓取請求按小时分组，画成一根根柱子。正常的形態通常是全天铺開、白天略高、夜間不断流。真正值得關注的是两種形状：
- 极度集中：几十秒内几百個請求，之後長時間安静。這可能是抓取端在短時間内消耗完配額，也可能是站点把大量 URL 同时暴露了出去，值得回看当天有没有批量發布或 Sitemap 大改。
- 整段空白：连續几小时零抓取。先排除日誌采集断档、CDN 回源規則變更，再考虑是不是那段時間服務器返回了大量超时或 5xx，把抓取端劝退了。
單日資料噪声大，建议看七天滚動，避免被一次活動带偏。
抓取高峰和站点高峰撞车
抓取請求本身也占连接數。如果站点的訪問高峰和抓取高峰重叠，再叠加一次全站發布或缓存刷新，响應時間容易被推上去。比較稳妥的做法是：
- 批量操作（改版、批量改标题、强制刷缓存）避開日誌里抓取最密的那一两個小时；
- 给動態接口單獨预留资源，別让抓取和用戶請求抢同一個连接池；
- 發布节奏尽量平摊，而不是一天里全部堆在一個時間点。
维護窗口不要靠“關站”来猜
很多人預設凌晨蜘蛛不来，于是把维護安排在凌晨。抓取时段是分散的，凌晨同样可能有請求。與其猜，不如用响應狀態表達：
维護期間让服務器明确返回 503，並在 Retry-After 里寫清预計恢复時間，比直接断连、返回超时或返回 200 空頁面都更容易被正确理解。
断连和超时會让抓取端把這段時間记為失敗，重试时机不可控；200 空頁面則更麻烦，等于告诉對方“内容就是這样”，容易留下空壳记錄。503 是临时性信号，语义清晰。
限速和抓取节奏怎么配合
如果你發現某些时段抓取過密、拖慢了服務，優先用限速而不是拦截：
- 先確認是不是自己的連結结构把對方引到了同一批 URL，比如列表頁無限下拉、篩選參數相互引用；
- 服務器侧對單個来源设並發上限，超出的請求返回 429 或 503，而不是排队到超时；
- 把重点頁面（首頁、栏目頁、近期更新）留在正常响應里，非重点頁面允许被延後。
需要說明的是，限速只能影响节奏，不能决定對方来不来、抓多少。它解决的是“別把服務器拖垮”，不是“多抓一点”。
可以固定下来的核對動作
- 確認日誌时区，並和手動訪問记錄比對一次；
- 按小时聚合最近七天抓取量，找出高峰段和空白段；
- 把高峰段和站点自身的發布、缓存刷新、备份任務對照，看有没有撞车；
- 检查空白段前後是否有集中 5xx 或超时；
- 調整维護窗口與限速參數，观察一周後再看分布形状。
抓取时段属于操作层信息，它的價值在于帮你安排维護、限速和發布节奏。至于抓多少、抓多快，仍然取决于頁面质量、連結结构和服務器是否稳定——把這几件事做好，比精确計算蜘蛛几点来更划算。