很多站点在看抓取資料时只關心“今天被爬了多少次”，却忽略了這些請求分散在哪個时段。把日誌按小时聚合之後，通常會看到明顯的波峰和波谷：有的时段蜘蛛密集到影响服務器，有的时段几個小时不见一次。先搞清楚波峰的来源，再决定要不要干预，比直接改抓取速率更稳妥。
先把日誌按小时切一遍
不需要复杂工具，把最近 7～30 天的訪問日誌導出，按小时統計三组數字就够了：
- 每個小时的蜘蛛請求數，並按 UA 区分不同来源；
- 每個小时的平均响應時間和 P95 响應時間；
- 每個小时的 5xx、超时、连接中断比例。
注意日誌里的時間戳很可能是 UTC 或服務器时区，先換算成主要受众所在的时区，否則容易把凌晨和上午看反。三項數字叠在一起看，往往能發現問题：請求數最高的时段如果同时是响應時間最長的时段，抓取效率其實是打折的，蜘蛛拿到的東西變慢，站点承担的压力也没換来實际價值。
波峰是怎么形成的
蜘蛛什么时候来，站点無法直接指定，但有几件事會影响它的選擇：
- 歷史响應记錄。以前在某個时段响應快，蜘蛛更容易把抓取安排在這個时段；
- 内容更新节奏。固定時間發布新内容，抓取會逐渐向發布時間靠拢；
- 蜘蛛自身的調度。多個站点共享抓取资源，时段會随时變化，不要指望它長期稳定；
- 站点的受众分布。面向不同时区的站点，波峰出現的時間也不同。
所以看到上午被爬了几百次、下午只爬了几十次，多數情况下不是谁在针對你，而是歷史响應速度和更新节奏共同作用的结果。想改變這個分布，最直接的办法是让每個时段的响應都足够快，而不是只在某個时段做特殊處理。
高峰期要不要给蜘蛛让路
先判断三件事再動手：
- 抓取高峰和业務高峰是否真的重叠？有些站点用戶高峰在晚上，蜘蛛高峰在凌晨，两者互不干扰，就没有必要調整。
- 服務器有没有余量？如果高峰期 CPU、資料库连接數已接近上限，蜘蛛的請求确實會挤占用戶請求。
- 抓取是否真的影响了用戶？看真實用戶的响應時間和错誤率，而不是只看蜘蛛的。
如果三條都成立，優先做的也不是封禁，而是降低單次抓取的代價：给静態资源加缓存、缩短動態頁面的資料库查询、把列表頁和詳情頁的渲染拆開、對未變化的頁面返回 304、避免返回体积異常的 HTML。只有当服務器确實扛不住时，才考虑用限速把抓取流量引導到负载較低的时段。
robots.txt 里的 crawl-delay 只有部分搜尋引擎支持，主流引擎大多忽略。想調整抓取节奏，更可靠的做法是在负载過高时對蜘蛛請求返回 503 並带上 Retry-After，让蜘蛛自行退避，同时在站長後台持續關注抓取統計的變化。
哪些情况其實不用調
如果日誌里没有明顯超时、5xx 比例很低、用戶侧响應正常，那么抓取量的波動属于正常現象。频繁調整反而會让蜘蛛重新试探，抓取节奏變得更不稳定。抓取速率是蜘蛛根據歷史表現自己算出来的，站点能做的是別让它算错：保持稳定响應，別让它在某個时段连續失敗。
一份可执行的自查顺序
- 導出近 30 天日誌，按小时聚合並換算时区；
- 标出抓取請求數、响應時間、错誤率三條曲线的重叠区間；
- 確認该区間的负载来自蜘蛛還是真實用戶；
- 先做缓存、查询優化和 304，再评估是否需要限速；
- 調整後观察两周，看抓取量是否回升、错誤率是否下降，再决定是否繼續。