抓取日誌里最常被用到的數字是總量和狀態碼，時間维度反而经常被忽略。把一天的請求按小时分组，画出一條訪問曲线，就能看到蜘蛛在哪些时段更活跃、哪些时段几乎不進站。曲线的形状，通常比總量更能說明站点和抓取端之間的配合狀態。
為什么时段比總量更稳定
抓取總量容易被外部因素带偏：提交一次 Sitemap、被一個大頁面推荐、站内新增几千條 URL，都可能让当天數字突然放大。时段分布則相對稳定，它更多反映抓取端對站点的調度习惯——什么時間分配了多少抓取资源，以及站点在那些時間是否回應得足够快。
如果曲线的峰谷長期漂移，通常是站点這邊發生了變化：响應變慢、部分 URL 返回错誤、robots.txt 或 CDN 規則改動，都會在時間轴上留下痕迹。
日誌里常见的三種曲线
平缓型
各小时抓取量差异不大，白天略高、凌晨略低。這類站点一般是更新节奏稳定、URL 總量不大且结构清晰。它不代表抓得更多，只是抓取端的調度没有明顯波動。
尖峰型
大部分請求集中在少數几個小时，其余时段很低。常见于更新集中在某個時間点發布的站点，也可能是抓取端把有限资源攒在某一时段使用。尖峰本身不是問题，問题在于尖峰时段服務器同时要服務真實用戶，响應時間容易被拉長。
断續型
曲线忽高忽低，中間有大段空白。這種形態更值得排查：可能是站点在某些时段對抓取端返回了 5xx 或超时，也可能是 CDN、防火墙規則按区域或按 UA 做了拦截，让一部分請求根本没到達源站。
把更新节奏往抓取高峰靠一靠
新頁面被發現之後，還需要一次實际抓取才會進入後續處理。如果發布時間和抓取高峰错開較遠，中間就會多出一段等待。可以做的調整比較朴素：
- 把例行更新放在固定的時間窗口，让抓取端的調度更容易形成規律；
- 發布後立刻通過内鏈把新 URL 挂到已有頁面，而不是只等 Sitemap 被讀取；
- 列表頁、栏目頁保持可訪問，让蜘蛛顺着结构往下走时不會断在中途；
- 批量發布时分散到多個時間点，避免短時間内产生大量新 URL 挤在同一队列里。
服務器负载和抓取时段重叠怎么办
抓取高峰如果正好撞上业務高峰，两邊會互相拖慢。比較稳妥的處理顺序是：先確認源站响應時間是否稳定，再考虑缓存静態頁面、把動態查询结果做短时缓存，最後才谈限速。限速本身也會带来代價——被压低之後，重新爬升需要時間。
如果确實需要在高峰期降低抓取压力，用 429 配合 Retry-After 明确告知等待時間，比直接返回 403 或断開连接更友好，也更容易让抓取端按预期退避。
一個简單的观察循环
- 每天记錄各小时抓取量、平均响應時間和狀態碼分布；
- 标出更新發布的時間点，看新 URL 首次被抓大概落在發布後多久；
- 把响應異常的時間段和服務器监控對照，確認是源站問题還是中間层拦截；
- 每次只調整一個變量，观察一到两周再决定是否繼續。
抓取曲线只是一個观察工具，它說明的是“發生過什么”，不能保證某個頁面一定會被收錄或排名。把时段、响應和结构一起看，比盯住單一數字更有用。