服務器负载一高，很多站長的第一反應是限制蜘蛛。但直接封 IP、返回 403，或者用 robots.txt 把整站 Disallow，往往會连正常抓取一起停掉。更稳妥的做法是给蜘蛛一個明确的“慢一点”信号，同时保留繼續訪問的通道。不同限速方式的兼容性和副作用差別很大，選之前最好先想清楚代價。
先看日誌，確認压力来自谁
日誌里先区分几類請求：搜尋引擎蜘蛛、普通用戶、爬虫工具、以及来源不明的采集。看它們的請求频率、目标 URL 分布和响應時間。如果高频請求集中在篩選參數、搜尋頁或重复 URL 上，問题可能不在“蜘蛛太多”，而在站点放出了太多低價值入口。這種情况下，先收紧内鏈和 Sitemap，比直接限速更有效。
robots.txt 的 Crawl-delay
Crawl-delay 寫的是两次請求之間的間隔秒數，例如設定為 5，表示建议蜘蛛每 5 秒抓一次。它的優点是配置简單，不需要改服務器逻辑。但要注意，主流搜尋引擎對它的支持並不一致：有的會參考，有的基本忽略。它更适合作為辅助信号，不适合当作唯一的限速手段。如果站点已经被大量抓取，單靠改 Crawl-delay 往往看不到立竿见影的效果。
HTTP 429 Too Many Requests 與 Retry-After
当某個 IP 或某個蜘蛛的請求超過阈值时，返回 429 是比較明确的“請求過多”信号。配合 Retry-After 响應头，可以告诉對方建议等待多少秒再来。它的好處是粒度可控：可以只對超频的那部分請求生效，不影响正常抓取。需要注意的是，429 用得太频繁或阈值太紧，蜘蛛可能會降低整站抓取频次，恢复起来比预期慢。阈值最好從宽松開始，观察几天再收紧。
503 Service Unavailable 的临时用法
503 通常用于维護或過载，配合 Retry-After 表示“暂时不可用，稍後再来”。它比 403、404 更合适，因為後两者容易被理解為永久性狀態。但 503 不适合長期挂着：如果蜘蛛连續多次遇到 503，它可能顯著降低對站点的抓取节奏，甚至暂时减少抓取量。建议只在短时压力峰值或計划维護时使用，並确保恢复後及时返回正常响應。
在 CDN 或 WAF 层按 UA、IP 限速
如果服務器压力来自少數高频来源，可以在 CDN 或 WAF 层做速率限制，按 IP、UA 或請求路径設定阈值。這種方式對源站保護直接，但規則要谨慎：搜尋引擎蜘蛛的 UA 可以伪造，不能只凭 UA 放行；反過来，也不能因為某個 IP 段請求多就整体拦截。更稳妥的是结合反向 DNS 驗證、請求路径和频率综合判断，並保留观察日誌。誤拦蜘蛛的代價，往往比多扛一点流量更高。
限速之後要观察什么
- 服務器响應碼分布：429、503 的比例是否在可接受范围。
- 蜘蛛抓取频次：是短期下降還是持續走低。
- 抓取覆盖率：重要目錄和詳情頁是否還在被訪問。
- 抓取深度：蜘蛛是否仍愿意顺着内鏈往下走。
- 恢复情况：限速解除後，抓取节奏多久回到正常。
不建议的做法
用 403、404 来挡蜘蛛，容易让抓取狀態變得混乱；返回 200 但内容為空，也會浪費抓取预算。用 robots.txt 全站 Disallow 来限速，等于同时關掉了 URL 發現和更新检查。還有一種常见誤区：一邊限速，一邊又希望新頁面尽快被收錄，這两件事本身有冲突。限速期間，最好把重要頁面的内鏈和 Sitemap 整理清楚，让蜘蛛在有限次數里優先走到有價值的地方。
限速的目标不是把蜘蛛赶走，而是让它在服務器能承受的节奏里繼續工作。任何让抓取狀態變得模糊的做法，短期省了资源，長期往往要花更多時間恢复。
如果压力只出現在特定时段，可以先用較宽松的 429 加 Retry-After 试執行，再根據日誌調整阈值。服務器稳定和抓取覆盖並不必然對立，關键是別用“一刀切”的方式解决具体問题。