從 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 的請求量趋势。当其中一個出現異常时，再按上面的顺序核對身份、检查規則、缩小放行范围。這样比等到抓取量整体下滑後再倒查要省事得多。