抓取频率這件事，很多站長是在服務器開始卡之後才認真看的。平时只關注蜘蛛来過没有，一旦搜尋蜘蛛的請求量翻了几倍，带宽、資料库连接、CPU 會被慢慢吃满，最先受影响的其實是真實訪客的打開速度。抓取和体驗之間需要一個可持續的平衡点，而不是一味放大。
先確認压力是不是真的来自抓取
服務器變慢的原因有很多，先別急着改 robots.txt 或上防火墙。用一两天的資料做個简單归因，方向會清楚很多。
日誌里看四個數字
- 爬虫請求占比：按 User-Agent 和 IP 段統計，看爬虫請求占總請求的比例。這個比例長期偏高，說明抓取预算和带宽都被大量非訪客請求占據。
- 時間分布：把請求按小时画一條线，看看是全天均匀，還是集中在一两個时段形成尖峰。尖峰更容易触發超时和 5xx。
- 狀態碼结构：如果 5xx、超时、499 的比例在上升，說明後端已经扛不住目前並發，這比抓了多少頁更值得關注。
- 請求集中度：同一批地址被反复請求，往往意味着列表頁、篩選頁或參數组合产生了大量近似 URL。
带宽與负载监控
日誌之外，再看一眼监控面板：带宽曲线的峰值时段是否和抓取高峰重合，入站流量與出站流量的比例是否異常，資料库连接數有没有被打满。如果這几條曲线對得上，基本可以確認抓取压力是主因。
常见的几個放大因素
- 列表頁、篩選頁、排序參數没有做归一化，同一批内容生成出大量不同地址；
- 動態頁面没有缓存，每次抓取都走一遍完整查询；
- 图片和静態资源体积偏大，抓取时消耗的带宽比 HTML 高得多；
- 站点地图里的更新時間频繁變動，让蜘蛛誤以為整站天天在更新；
- 站内搜尋、日歷、打印頁這類低價值地址可以被批量抓取，却没有做任何限制。
一份可执行的自查清單
- 導出最近 7 天的日誌，按小时統計爬虫請求量與訪客請求量的比值。
- 找出被請求次數最高的 50 個地址，判断里面有多少是參數頁面或重复内容。
- 检查服務器返回碼分布，確認 5xx 與超时是否集中在抓取高峰。
- 查看带宽峰值是否與抓取高峰重合，必要时给静態资源加缓存與压缩。
- 確認 robots.txt 與站点地图没有互相矛盾，避免蜘蛛反复试探無效地址。
- 對列表頁的分頁、篩選參數設定合理的規范方式，减少近似 URL。
- 给動態頁面加一层缓存，哪怕只有几十秒，也能明顯削平尖峰。
- 在服務器层面設定合理的並發上限與超时時間，保證訪客請求優先。
處理顺序：先止血，再優化
遇到明顯压力时，先做能立刻见效的動作：限制單 IP 並發、给動態頁加短缓存、把明顯的低價值地址挡在门外。這些改動不涉及内容調整，風險小、见效快。等站点稳下来，再做结构层面的優化，比如收敛參數、合並重复列表、精简站点地图。顺序反了，容易在站点還不稳定的时候大改结构，反而让蜘蛛和訪客一起迷路。
抓取量本身不是运营指标。真正需要盯的是：在保證訪客体驗的前提下，新内容能不能被稳定發現。如果訪客開始抱怨打不開，抓取量再高也没有意义。
小结
抓取频率和服務器压力這筆帳，最好在出問题之前就算清楚。定期看一眼日誌里的爬虫占比、狀態碼结构和带宽曲线，比等到报警响起来再排查要從容得多。把资源留给真實訪客，抓取這件事才谈得上可持續。