从 403 与 429 的分布开始看

当站点抓取量在几天内明显下滑，第一步通常不是改页面，而是去看服务器或 WAF 日志里的状态码分布。如果 403、429 的占比突然上升，并且请求的 User-Agent 中带有 spider、bot 之类字样，就要怀疑是防护策略把搜索蜘蛛一起拦了。

反过来，如果这些 403 请求集中在少数几个 IP、访问路径杂乱、频率极高，那更可能是伪装 UA 的采集行为，处理方向完全不同。把日志按 IP、UA、状态码、命中规则四个字段分组统计，能较快看出问题落在哪一类。

验证蜘蛛身份的正确顺序

只凭 User-Agent 判断蜘蛛身份并不安全，因为 UA 可以随意伪造。相对稳妥的做法是反向验证，顺序如下：

1. 取请求来源 IP，做反向 DNS 查询，看解析出的域名是否属于对应搜索引擎的官方域名后缀。
2. 再对该域名做一次正向解析，确认解析结果能回到原来的 IP。只有这一步通过，IP 身份才算可信。
3. 与官方公布的 IP 段列表交叉核对，并注意搜索引擎会不定期增删网段。

如果站点前面有 CDN 或云 WAF，来源 IP 可能已被替换成回源地址，此时要去读平台提供的真实客户端 IP 字段，否则验证会整体失效。

容易被忽略的误拦原因

• 速率限制按 IP 计数：同一出口 IP 上的蜘蛛请求被当成 CC 攻击。
• 规则匹配过宽：把 UA 中包含 bot 字符串的请求一律拦截。
• 请求头缺失：蜘蛛请求往往不带 Cookie、Referer，被异常检测判为可疑。
• 只放行了 IPv4：搜索引擎的 IPv6 抓取节点没有加白名单。
• HEAD 请求或 Sitemap 拉取被单独拦截，导致 URL 发现环节断掉。
• 云厂商 IP 段被整体封禁，误伤了托管在其中的抓取节点。

放行策略怎么定

放行不建议只按 UA 关键字，那样等于给伪装流量开了一道门。更稳的方式是按已验证 IP 段放行，并尽量做路径级粒度：robots.txt、Sitemap、静态资源、列表页可以先放开，涉及写入或高频查询的接口继续保留严格限制。

放行范围越大，维护成本越高。每次搜索引擎更新 IP 段，都需要有人能及时同步规则，否则今天放行的段明天可能已经不属于对方。

调整后如何确认恢复

改完规则后，观察点包括：抓取日志里 403 是否下降、robots.txt 与 Sitemap 的拉取是否恢复、被抓取 URL 数量是否回到调整前水平。抓取恢复通常有延迟，不必因为一两天没变化就反复改规则，频繁变动反而会让判断失去参照。

把排查做成固定动作

可以在监控里固定几个指标：蜘蛛请求的 403 占比、Sitemap 获取成功率、不同 UA 的请求量趋势。当其中一个出现异常时，再按上面的顺序核对身份、检查规则、缩小放行范围。这样比等到抓取量整体下滑后再倒查要省事得多。