為什么要盯住抓取频次
站点运营里，URL 發現只是第一步，真正落到服務器上的是一個個 HTTP 請求。蜘蛛池或者站内連結把地址喂出去之後，抓取會不會變成压力，取决于频次和站点本身的承载能力。频次太低，新頁面發現慢；频次太高，带宽、資料库连接、動態渲染都會被拖住，最後连正常用戶訪問也一起變慢。观察频次不是為了让蜘蛛多来，而是让訪問曲线落在服務器能承受的范围里。
從哪里看抓取情况
最直接的資料来源還是訪問日誌。建议至少把這些字段留下来，方便按小时聚合：
- 時間戳、請求路径、查询串
- 狀態碼分布：2xx、3xx、4xx、5xx 各占多少
- 响應時間，特別是慢請求集中在哪些路径
- 来源 IP 與 User-Agent 的集中程度
- 是否命中缓存，回源比例大概是多少
把這些資料按小时画出来，就能判断抓取是平稳的還是有明顯尖峰。很多站点的問题不是總量大，而是集中在几分钟之内。
几種常见的異常信号
- 某個 IP 或某個 User-Agent 在短時間内反复請求同一批地址。
- 5xx 明顯上升，說明後端已经被压到超时或者连接耗尽。
- 大量請求落在搜尋、篩選、排序這類带參數的動態地址上。
- 带宽峰值與抓取峰值重合，用戶訪問在同一時間變慢。
處理思路：先分流，再限速
把静態和動態分開
静態资源交给缓存或 CDN，减少回源次數；動態頁面尽量把公共部分先缓存起来。這样即使抓取频次上升，回源压力也不會等比例增加，服務器侧的可控空間會大很多。
限制要讲方式
robots.txt 里的 Crawl-delay 支持度並不统一，不能当作唯一手段。更稳妥的做法是在服務端做並發限制、排队或按路径设定配額，必要时對明顯異常的来源做临时限速。同时注意区分搜尋引擎蜘蛛和普通采集程序，別一刀切把正常的抓取也挡在门外。
狀態碼要给出真實信号
压力大时返回 429 或 503 並带上 Retry-After，比让請求一直挂着直到超时要友好得多。但不要長期返回 503，否則站点在抓取侧會被当成不稳定，恢复之後也需要一段時間才回到正常节奏。
蜘蛛池與 URL 發現的邊界
蜘蛛池的作用是让地址更容易被發現，而不是替站点决定抓取节奏。投放的地址最好與站点真實栏目對應，避免把大量低價值的動態頁推给蜘蛛。發現通道稳定、落地頁可訪問、内容确實存在，這三件事同时成立，抓取才不會空轉。
建立自己的观察节奏
- 每天看一眼 5xx 和慢請求，超過阈值就去查原因。
- 每周對比抓取總量與带宽曲线，看两者是否同步上涨。
- 每月回顾一次被抓取最多的路径，清理没有意义的動態地址。
抓取频次是结果，不是目标。站点结构清楚、頁面响應稳定，蜘蛛自然會按合适的节奏来。
把這些观察固定成习惯，站点运营就有了一個可复用的基线：變動發生时，你能分清是内容更新带来的正常波動，還是抓取異常带来的額外负载。