不少站点會遇到這样的情况：白天真人訪問高峰时，頁面响應明顯變慢，同一時間段抓取日誌里的超时和 5xx 也跟着變多。這種波動未必是被拦截，也可能只是服務器在同一时段被真人請求和抓取請求一起压住了。抓取时段本身很难直接控制，但站点侧的负载分布是可以調整的。
高峰重叠时會看到哪些現象
如果抓取請求正好落在业務高峰，通常會同时出現几類信号：
- 平均响應時間上升，TTFB 從几百毫秒涨到一两秒甚至更高；
- 部分請求超时中断，蜘蛛可能重试或直接跳過；
- 5xx 返回增多，尤其是依赖資料库或第三方接口的頁面；
- 單位時間内成功抓取的 URL 數量下降，抓取节奏被拉長。
這些現象叠加起来，容易让人誤判為“抓取被限制”。先区分是限速還是负载，再决定處理方向。
先從訪問日誌確認時間分布
把訪問日誌按小时聚合，分別統計搜尋蜘蛛請求數量與平均响應時間、错誤碼占比。重点看两件事：抓取請求最集中的时段，是否與站点自身的訪問峰值重合；重合时段内的错誤是否集中在少數几類模板頁面上。
如果發現错誤几乎都出現在需要實时查询的列表頁或搜尋结果頁，而静態的詳情頁响應正常，那問题更可能在單條路径的實現上，而不是整站带宽不足。
可用的错峰與降载手段
让高峰本身更轻
- 對更新频率低的頁面做静態化或長缓存，减少每次請求都回源查询；
- 检查 CDN 缓存命中率，把图片、样式、脚本這類静態资源與頁面請求分開承载；
- 梳理慢查询與外部接口調用，避免單個頁面拖住整個连接池；
- 為列表頁設定合理的翻頁上限，减少深分頁带来的重复計算。
让抓取路径更省
- 在 Sitemap 中只保留規范 URL，避免同一内容的多個入口被反复抓取；
- 收敛带篩選、排序參數的連結，减少蜘蛛在無效路径上消耗時間；
- 内鏈尽量指向稳定的規范地址，减少多跳跳轉；
- 對确實不需要被抓取的路径，用 robots.txt 明确說明，而不是靠响應變慢来“劝退”。
一份可执行的排查清單
- 導出最近 7 天日誌，按小时統計蜘蛛請求量、平均响應時間與错誤碼分布；
- 标出响應最差的时段，對照站点监控里的 CPU、資料库连接數、带宽曲线；
- 抽样查看该时段的错誤 URL，判断是否集中在某一類模板或某几個參數路径；
- 對高频且低價值的入口做缓存或入口收敛，观察下一周期的日誌變化；
- 確認没有把正常抓取誤当成攻击而触發限速規則，必要时核對放行配置；
- 记錄調整前後同一时段的表現，形成可對比的基线。
調整後的观察與回稳
负载類問题通常不會一次調整就彻底消失，需要观察几個抓取周期。建议至少跨過一周，對比同一时段的响應時間、错誤率和成功抓取數量，再看變化是否稳定。如果只是把峰值從 A 时段推到 B 时段，說明總量没有降下来，還需要繼續從入口數量和頁面成本入手。
抓取时段的重合是客观存在的，站点能做的是把單位抓取的成本降下来，让同样的服務器资源能承接更多有效請求。任何調整都不應承诺具体的抓取量或收錄结果，只以日誌中的實际表現為准。