抓取量突然下滑时，很多人第一反應是内容质量或 Sitemap 出了問题。但如果抓取日誌里集中出現 403、429、503，問题的位置往往在服務器前面的防護层。CDN 和 WAF 為了保護源站，會對高频請求做拦截，而搜尋蜘蛛的抓取特征如果没被正确识別，就會和普通爬虫一起被挡在门外。

先分清是被拒绝，還是没被發現

動手改規則前，先確認日誌的形態。被拦截通常表現為：同一路径在短時間内返回大量 403 或 429；不同 User-Agent 的請求都失敗；响應時間极短，因為請求根本没有到達源站應用层。

如果日誌里蜘蛛压根没出現，那更可能是 URL 發現、robots 規則或 Sitemap 的問题。两種情况混在一起排查，容易把安全規則改乱，反而放大風險。

常见的誤伤来源

• User-Agent 白名單寫得過窄，只匹配完整字符串，蜘蛛版本更新後就對不上。
• 只放行了 IPv4 段，忽略了蜘蛛的 IPv6 出口。
• 速率限制按普通用戶設定，蜘蛛连續抓取时分頁和静態资源一起触發限流。
• CDN 安全等級調高後，對無 Cookie、不执行 JS 的請求直接發起挑战。
• 站内搜尋、篩選參數被当成攻击特征，正常抓取路径被規則命中。

這些問题往往不是一次性出現，而是在某次安全策略調整、CDN 配置變更或源站扩容之後集中暴露。

用抓取日誌定位拦截点

把日誌按狀態碼、路径、User-Agent、来源 IP 分组，看拦截是否集中在某一层。如果 CDN 日誌和源站日誌的狀態碼不一致，比如 CDN 记錄 403 而源站没有對應记錄，說明請求被邊缘节点拦下了。如果源站记錄 429，則要检查應用层或源站 WAF 的限速配置。

放行與驗證的顺序

1. 核對防護产品對搜尋蜘蛛的官方說明，按其提供的 IP 段或驗證方式配置，不要靠猜 User-Agent。
2. 對搜尋蜘蛛關閉 JS 挑战、驗證碼和浏览器指纹校驗，這些机制蜘蛛通常不會执行。
3. 把速率限制從全站统一改為按路径或按来源区分，给列表頁和静態资源留出余量。
4. 检查 CDN 與源站两层的白名單是否一致，避免只改了一层。
5. 放行後不要立刻看排名，先看抓取日誌中 403、429 的比例是否回落，再观察新 URL 是否重新出現在抓取记錄里。

放行不等于放任。白名單和限速規則仍需要定期复核，尤其是蜘蛛 IP 段更新、CDN 产品升級之後。

拦截對 URL 發現的影响

抓取被拒绝不只是少抓几個頁面。蜘蛛在连續失敗後，通常會降低對该站点的抓取频次，新提交的 Sitemap、新上线的栏目頁、内鏈新增的入口，都可能被推迟發現。所以拦截修复後，抓取覆盖的恢复往往比狀態碼恢复更慢一些。

日常维護建议

• 把搜尋蜘蛛的抓取狀態加入监控，關注狀態碼分布，而不只是抓取總量。
• 安全策略變更前，先在測試环境用真實抓取特征驗證一遍。
• 保留一份放行規則清單，记錄修改時間與原因，方便出問题时回滚。
• Sitemap 和内鏈入口保持稳定，减少蜘蛛在失敗路径上的重复尝试。

抓取問题的排查顺序，通常是先確認進得来，再谈 URL 發現是否充分。把防護层的誤伤排除掉，後面的 Sitemap、内鏈结构和服務器稳定性優化才有意义。