抓取量掉了，先看状态码分布
蜘蛛抓取量下滑，很多人的第一反应是内容质量或者收录策略出了问题。但如果日志里出现大量 403、406、429，甚至请求根本没到源站，那问题多半出在入口这一层。服务器、CDN、WAF、防火墙、限流插件，任何一环加了规则，都可能把正常搜索引擎一起挡在外面。
排查的第一步不是急着改规则，而是先看数据：
- 按状态码统计最近 7 天与 30 天的抓取响应，看 403、429 的占比有没有明显抬头；
- 按 UA 分组，确认常用搜索引擎的爬虫是否还能拿到 200；
- 按 IP 反查，看被拦的是不是集中在官方公布的爬虫 IP 段；
- 对比 WAF 后台的拦截日志与源站访问日志，确认请求到底在哪一层被拦下。
常见的误拦来源
UA 黑名单写得太粗
有些规则为了挡采集，直接写 curl、python、Bot 之类的关键词，或者用正则匹配到半个字符串，很容易把搜索引擎的正规 UA 一并命中。更隐蔽的是反向情况：只允许少数几个 UA 通过，结果新出现的搜索爬虫 UA 全被拦。
频率限制触发 429
限速通常按 IP 或按会话计数。搜索引擎会从同一批 IP 高并发抓取，一旦阈值设得偏低，就会连续收到 429。短时间被限速影响不大，但持续数天，抓取预算往往会往别的站倾斜。
地域封禁与 IP 段误伤
为了防攻击而封掉某些海外 IP 段是常见做法，但爬虫节点可能分布在多个地区，封得太宽会把正常抓取一起挡掉。
验证码与 JS 挑战页
开启人机验证后，返回给爬虫的是一个挑战页而不是正文。蜘蛛拿不到内容，短时间只是抓取失败，长期就可能出现页面掉出索引的情况。
云 WAF 的默认 BOT 规则
不少云厂商默认开启 BOT 管理，规则集里包含疑似自动化工具、高频访问这类策略。上线时没有逐条核对，就容易误伤。
一套可执行的自查顺序
- 确认拦截层级：先在源站记录真实来访 IP（例如通过 CDN 回源头），弄清楚请求有没有到源站。
- 核对官方 IP 段：主流搜索引擎都公布了爬虫 IP 段，比 UA 更可靠，优先用 IP 做白名单。
- 做反向解析验证：对可疑 IP 做反向 DNS 查询，确认域名归属，再决定放行还是拦截。
- 临时放行再观察：把确认的爬虫 IP 段加入白名单，观察 3 到 7 天日志里的状态码与抓取量变化。
- 调整限速阈值：把验证过的搜索引擎单独分组，给一个更宽松的速率，而不是和普通访客共用同一条限流规则。
- 记录改动：每次改规则都写清时间、原因、影响范围，方便出问题时回滚。
不要一看到抓取量下滑就去重新提交 Sitemap 或者改标题。先确认请求有没有进门，比什么都重要。
白名单长期维护的几个习惯
- 每季度复核一次白名单，删掉过期 IP 段，避免名单只增不减；
- 把 WAF 拦截日志纳入日常巡检，至少每周扫一眼异常拦截量；
- 验证过是真实搜索引擎的流量，别因为频率高就自动拉黑；
- 采集与蜘蛛分开处理：对异常采集做封禁与限速，对正规爬虫保证稳定响应；
- 服务器与 CDN 两侧的规则保持同步，避免一边放行、一边拦截。
限速不能代替内容治理
限流只是入口管理，不是解决抓取预算问题的万能办法。如果站点存在大量低质量聚合页、参数组合页，蜘蛛本来就会减少抓取，这时候把限速调松，意义有限。先把该合并的合并、该 noindex 的标清楚，再回来处理入口规则，顺序会更顺。