先確認压力是不是蜘蛛造成的
服務器一慢，很多人的第一反應是蜘蛛抓太狠了。但在動手限速之前，先把訪問日誌按 UA 和路径分组看一遍：蜘蛛請求占總請求的比例是多少、集中在哪些 URL、這些 URL 的平均响應時間、5xx 出現在哪個時間段。有些站点其實是自身的慢查询或缓存失效拖垮了响應，蜘蛛只是恰好在那时来訪，把原因归到抓取上，後面的動作就會做偏。
一個简單的判断方法：蜘蛛請求只占總請求的一小部分，而响應時間已经很長，問题多半在應用层；蜘蛛請求量明顯高于平时，且集中在列表頁、篩選頁、站内搜尋這類一個入口就生成一批 URL 的位置，才轮到抓取节奏這個话题。
robots.txt 里的 Crawl-delay 能指望多少
Crawl-delay 是最省事的寫法，但各家支持情况並不统一。Google 明确不遵循這個指令，它按自己的抓取预算和服務器响應状况来調整；部分其他爬虫會讀取並遵守。寫上去没有坏處，但不能把它当成限速的主力。
同样需要留意的是 Disallow。临时限流时用 Disallow 關掉一批目錄，蜘蛛會把這些 URL 從抓取队列里清掉，等你放開之後要重新经歷一轮發現，恢复得比预期慢。限流和屏蔽是两件事，尽量不要混用。
服務器端和 CDN 层的限速更可控
真正管用的措施通常在离服務器最近的地方：
- 按 UA 或 IP 段限制並發：在 Nginx、WAF 或 CDN 上给已知爬虫單獨的並發上限，與正常用戶流量分開，避免限速誤伤真實訪客。
- 返回 429 而不是 403 或 5xx：429 表示請求過多、請稍後再来，蜘蛛會退避重试；長期 403 容易被理解成拒之门外，5xx 則會被当成服務器故障，两種反應都不是你想要的。
- 配合 Retry-After：在 429 响應里给出建议等待時間，比让蜘蛛自己猜要温和。
- 让缓存层多挡一层：静態资源和模板化列表頁尽可能命中 CDN 缓存，蜘蛛拿到的是缓存副本，源站压力會小很多。
限速的目标不是让蜘蛛少来，而是让它每次来都能拿到稳定的 200。宁可慢一点、稳一点，也不要快而乱。
限速之外，先减少低價值抓取
如果站点每天被大量參數 URL、站内搜尋结果頁、重复排序頁消耗掉抓取額度，與其硬顶並發，不如先收缩這些入口：
- 篩選和排序參數尽量做規范化，让一组參數只對應一個可抓取 URL；
- 站内搜尋结果頁用 robots.txt 或 noindex 明确挡掉，別让它們進入索引；
- 列表頁的分頁保留真實的分頁連結，不要把加载更多全部交给接口；
- 检查 Sitemap 里是否存在已失效、已合並的舊地址，减少蜘蛛對無效 URL 的重复確認。
把這些做掉之後，同样的抓取總量會更多落在有價值的頁面上，服務器承受的無效請求也會同步下降。
限速之後要盯什么
限速不是設定完就結束了。調整後的一到两周，重点看几個指标：蜘蛛請求數是否落到可接受区間、平均响應時間是否回落、5xx 比例是否降下来、被抓取的 URL 中有效頁面占比是否上升。如果抓取量降了，有效頁面被抓的次數也一路跟着降，說明限速過头了，需要把阈值往上調。
另外，日誌里如果出現某個 IP 段請求量異常大且不遵守 robots.txt，先別急着一刀切封網段，先確認是不是自己站点上的递归調用或镜像導致的。誤封正常爬虫，恢复起来往往比限速本身更麻烦。