抓取量下滑时，多数人先怀疑内容、内链或 Sitemap。但有一类原因更靠近底层：蜘蛛确实来了，也发出了请求，只是服务器、CDN 或 WAF 没有把正常响应交出去，而是在交出之前先回了 403、429 或 503。对蜘蛛来说，这跟页面打不开没有区别，抓取安排会随即调整。

误伤通常不是一个动作造成的

把蜘蛛拦下来，很少是某一条规则主动针对搜索引擎。更常见的情况是几条正常配置叠在一起：CDN 默认开启的 Bot 管理、面板里一键启用的防护等级、按 IP 计数的频率限制、对空 UA 或异常 UA 的拦截。单看每一条都不算离谱，叠起来之后，来自同一批 IP 段的高频请求就会先被判定为异常流量。

• WAF 规则库把爬虫特征、高频访问、空 Referer 一并视为风险。
• 频率限制按 IP 计数，而蜘蛛的出口 IP 往往集中在有限的几个段内，很容易触顶。
• Bot 管理或 JS 挑战返回一段需要执行脚本才能通过的页面，蜘蛛拿到的是挑战页而不是内容。
• 地域或机房封禁：蜘蛛出口 IP 的归属地不在业务范围内，被整段屏蔽。
• 验证码与登录墙被误用到公开页面上，蜘蛛无法通过。

先确认拦截发生在哪一层

判断依据是访问日志里蜘蛛请求的响应状态码与响应体。如果日志显示 UA 明确是搜索引擎蜘蛛、状态码却是 403 或 429，或者虽然返回 200 但内容是一段只有几十字节的挑战页，基本可以确定被中间层拦了。响应头里的服务器标识、WAF 厂商特征也能帮你定位是哪一层返回的。

同时对照搜索引擎后台的抓取统计：主机可用性、抓取响应分布、平均响应时间。几项同时变差，通常指向服务端而不是内容侧。

排查与放行的顺序

1. 从最外层往里逐层看：CDN、Bot 管理、负载均衡、应用防火墙、应用本身。
2. 在每一层查看命中规则，确认是哪条规则命中了蜘蛛的请求。
3. 针对已验证的搜索引擎 IP 段建立放行策略，而不是把整层防护关掉。
4. 放行后重新观察日志，确认蜘蛛请求拿到的是正常页面，响应体大小合理。
5. 保留一条独立通道：让 sitemap、robots.txt 和主要列表页不参与挑战与验证。

放行不等于全放开

只靠 User-Agent 放行并不安全，UA 可以伪造，等于给自己开了个口子。更稳妥的做法是反向 DNS 验证：先看请求 IP 是否属于搜索引擎公布的反向解析域名，再做一次正向解析确认能解析回同一个 IP，两步都通过才放行。主流搜索引擎都提供了各自的验证方式，按官方说明配置即可。

如果做不到完整验证，至少不要用「UA 里含 bot 就封」这类规则，它对蜘蛛和恶意爬虫一视同仁。

限流阈值怎么定才不误伤

频率限制的目标是异常流量，而不是所有高频流量。可以把限速粒度放在 IP 加路径上，对静态资源和 HTML 分开计数；对返回 200 的正常请求放宽阈值，只对 404 密集、参数异常、单一 IP 打大量不同 URL 的行为收紧；阈值应能承载蜘蛛正常的抓取节奏，而不是按人工浏览的速度来定。

判断限流是否合理的简单办法：看它在正常日子里有没有拦下过任何一次搜索引擎请求。如果有，阈值就偏紧了。

恢复之后还要看几天

规则调整之后，抓取量不会立刻回到原来的水平。蜘蛛有自己的抓取安排和重试节奏，被拒绝过的 URL 往往要等下一轮才会重新进入队列。建议连续观察几天日志，比较调整前后同一批 URL 的抓取次数、状态码分布和响应时间，确认 403 与 429 已经消失，再判断其他环节是否还有问题。

把这套检查写进运维清单：每次调整 CDN 配置、更换 WAF 规则、修改限流阈值之后，都回头看一眼蜘蛛的请求有没有被误伤。这比抓取量掉下来之后再排查要省事得多。