網站跑得稳不稳，很多时候不取决于内容量，而取决于爬虫来的时候服務器扛不扛得住。尤其是做了蜘蛛池、批量提交 URL 或者内容更新频繁的站点，抓取請求會在短時間里集中出現。如果頁面大多是動態查询、又没有缓存层，資料库连接數會被迅速占满，最後表現為 5xx 增多、响應變慢，訪客和爬虫一起受影响。
先分清是谁在抓
打開日誌，看 User-Agent 和 IP 段。大致分三類：主流搜尋引擎的爬虫、自己發起的蜘蛛池或批量請求、第三方采集與掃描工具。三類請求的處理方式完全不同，混在一起做限速，很容易把正常抓取也一起挡掉。
- 主流搜尋引擎：核對 IP 反查與 UA 是否一致，通常可以放行，靠抓取频次設定来調节。
- 自建抓取：自己發的請求最可控，控制並發數、加延时即可，不必上服務器层策略。
- 采集與掃描：數量大、路径杂乱、常集中在搜尋頁或參數頁，需要單獨限速。
從日誌里看出压力来源
按时段統計請求量
把日誌按小时切分，統計總請求數、動態請求數和 5xx 數量。如果某几個小时的曲线和服務器负载曲线几乎重合，說明压力确實来自抓取，而不是正常訪問高峰，這时再去優化頁面就有的放矢。
区分頁面類型
同一個站点的頁面，抓取成本差別很大。列表頁、詳情頁通常有缓存，站内搜尋结果頁、篩選排序頁、日歷归档頁往往每次都要查库。統計這些路径在日誌中的請求占比，就能知道抓取预算到底花在了哪里。
减少被抓的頁面數量
與其在服務器端硬扛，不如让爬虫少抓一些没價值的地址。抓取预算和服務器资源一样，都是有限资源。
- 站内搜尋结果頁加 noindex，並在 robots.txt 里屏蔽查询參數路径。
- 篩選、排序、對比類參數頁做規范化，只保留一個可抓取入口。
- 空结果頁、無内容的标簽頁與作者頁，要么补内容，要么別让入口外露。
- 分頁過深的列表，考虑用加载更多配合站点地图，减少無效翻頁。
服務器端的缓冲手段
- 静態资源和可缓存頁面交给 CDN，让回源請求尽量少。
- 给詳情頁做頁面缓存或對象缓存，减少重复查询。
- 在 Nginx 层配置连接數與請求速率限制，先限並發再限總量。
- 資料库慢查询單獨记錄，別让爬虫触發的查询把连接池占满。
限速與封禁的邊界
限速手段要留後路。直接按 IP 段封禁、一律返回 403，可能誤伤正常的搜尋引擎爬虫，也可能让已经收錄的頁面慢慢失去抓取。比較稳妥的顺序是：先屏蔽無價值路径，再限制並發，最後才對確認的恶意来源做封禁。
一個實用的判断标准：如果某個来源的請求几乎不产生有效訪問，路径集中在搜尋頁和參數頁，且频次明顯超出正常范围，才考虑收紧策略。
形成定期复盘
抓取压力不是一次配置就完事。站点结构變了、内容更新节奏變了、蜘蛛池規模變了，压力分布都會跟着變。建议每個月看一次日誌匯總：抓取總量、動態請求占比、5xx 次數、平均响應時間。四個數字稳定，說明目前策略還够用；其中一個突然抬头，就去日誌里找那批請求。
把抓取当成一種需要分配的资源来看待，往往比單纯加机器更有效。让爬虫多看该看的頁面，少碰没價值的地址，服務器自然轻松一些。