搜尋蜘蛛来訪本身不产生收益，但它消耗的是和真實用戶同一份服務器资源。当一批 URL 同时被抓取，尤其是詳情頁需要查库、拼装模板或調用接口时，站点响應會明顯變慢；而變慢又會反過来让蜘蛛降低抓取频次。要處理這個問题，先把两件事分開：是蜘蛛請求太集中，還是站点本身容量就不够。
先判断瓶颈落在哪一层
翻一段時間的日誌，把蜘蛛請求的响應時間和普通用戶請求放在一起對比。如果只有蜘蛛這批請求變慢，多半是並發太高；如果用戶侧同样慢，那就是容量問题，單靠限速解决不了。
- 單 IP 並發數：短時間内同一来源打出大量請求，通常是調度集中的表現
- 慢查询比例：詳情頁動態生成，抓取一次等于跑一遍完整业務逻辑
- 带宽占用：图片、脚本等子资源被成批拉取，抢占了出口带宽
- 缓存命中率：命中率低时，每次抓取都直接回源打到資料库
限速该放在哪一层
robots.txt 里的 crawl-delay 只對一部分蜘蛛生效，可以寫，但不要当成主要手段。更稳妥的做法是在反向代理或 CDN 层按 User-Agent 和路径做速率控制，這样對来訪方是否遵守约定不敏感。
- 先给蜘蛛單獨划一個並發上限，避免它挤占用戶通道
- 再把列表頁、篩選頁、排序頁這類重复度高的地址限得更紧一些
- 詳情頁等真正需要被收錄的頁面，保留相對宽松的額度
- 對明顯異常的高频請求可以返回 429，但不宜作為常態手段
资源有限时该優先保住哪些頁面
總量固定，就需要排一個先後顺序：首頁、栏目頁、更新频繁的詳情頁優先；參數组合頁、歷史归档、站内搜尋结果頁可以放慢。這個顺序最好和 sitemap 里的權重設定、站内連結密度保持一致，不要出現地图里标成重点、限速时又被压到最低的矛盾。
降級时不要用 503 糊弄
如果服務器确實過载，短時間内返回 503 並带上 Retry-After，比让請求直接超时更清楚，蜘蛛能识別這是暂时狀態。但要注意两点：長時間反复返回 503，蜘蛛會逐步减少来訪；如果只是想让某些頁面不被抓，應该用 404、410 或 robots.txt，而不是拿 503 顶替。狀態碼用错，损失的是整站的抓取信任。
找到抓取量和承载力的平衡点
需要盯的指标並不复杂：蜘蛛請求量、平均响應時間、5xx 比例、缓存命中率。調整一次之後观察几天再决定下一步，不必天天改配置。稳定比激進更重要——让蜘蛛每次来都能顺利取走頁面，比偶尔多抓几千個 URL 更有價值。
限速的目标不是把蜘蛛赶走，而是让它抓得久、抓得稳，让抓取节奏和站点的實际承载能力對得上。