服务器负载一高，很多站长的第一反应是限制蜘蛛。但直接封 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 试运行，再根据日志调整阈值。服务器稳定和抓取覆盖并不必然对立，关键是别用“一刀切”的方式解决具体问题。