抓取量下滑时，多數人先怀疑内容、内鏈或 Sitemap。但有一類原因更靠近底层：蜘蛛确實来了，也發出了請求，只是服務器、CDN 或 WAF 没有把正常响應交出去，而是在交出之前先回了 403、429 或 503。對蜘蛛来说，這跟頁面打不開没有区別，抓取安排會随即調整。
誤伤通常不是一個動作造成的
把蜘蛛拦下来，很少是某一條規則主動针對搜尋引擎。更常见的情况是几條正常配置叠在一起：CDN 預設開啟的 Bot 管理、面板里一键啟用的防護等級、按 IP 計數的频率限制、對空 UA 或異常 UA 的拦截。單看每一條都不算离谱，叠起来之後，来自同一批 IP 段的高频請求就會先被判定為異常流量。
- WAF 規則库把爬虫特征、高频訪問、空 Referer 一並视為風險。
- 频率限制按 IP 計數，而蜘蛛的出口 IP 往往集中在有限的几個段内，很容易触顶。
- Bot 管理或 JS 挑战返回一段需要执行脚本才能通過的頁面，蜘蛛拿到的是挑战頁而不是内容。
- 地域或机房封禁：蜘蛛出口 IP 的归属地不在业務范围内，被整段屏蔽。
- 驗證碼與登入墙被誤用到公開頁面上，蜘蛛無法通過。
先確認拦截發生在哪一层
判断依據是訪問日誌里蜘蛛請求的响應狀態碼與响應体。如果日誌顯示 UA 明确是搜尋引擎蜘蛛、狀態碼却是 403 或 429，或者虽然返回 200 但内容是一段只有几十字节的挑战頁，基本可以确定被中間层拦了。响應头里的服務器标识、WAF 厂商特征也能帮你定位是哪一层返回的。
同时對照搜尋引擎後台的抓取統計：主机可用性、抓取响應分布、平均响應時間。几項同时變差，通常指向服務端而不是内容侧。
排查與放行的顺序
- 從最外层往里逐层看：CDN、Bot 管理、负载均衡、應用防火墙、應用本身。
- 在每一层查看命中規則，確認是哪條規則命中了蜘蛛的請求。
- 针對已驗證的搜尋引擎 IP 段建立放行策略，而不是把整层防護關掉。
- 放行後重新观察日誌，確認蜘蛛請求拿到的是正常頁面，响應体大小合理。
- 保留一條獨立通道：让 sitemap、robots.txt 和主要列表頁不參與挑战與驗證。
放行不等于全放開
只靠 User-Agent 放行並不安全，UA 可以伪造，等于给自己開了個口子。更稳妥的做法是反向 DNS 驗證：先看請求 IP 是否属于搜尋引擎公布的反向解析域名，再做一次正向解析確認能解析回同一個 IP，两步都通過才放行。主流搜尋引擎都提供了各自的驗證方式，按官方說明配置即可。
如果做不到完整驗證，至少不要用「UA 里含 bot 就封」這類規則，它對蜘蛛和恶意爬虫一视同仁。
限流阈值怎么定才不誤伤
频率限制的目标是異常流量，而不是所有高频流量。可以把限速粒度放在 IP 加路径上，對静態资源和 HTML 分開計數；對返回 200 的正常請求放宽阈值，只對 404 密集、參數異常、單一 IP 打大量不同 URL 的行為收紧；阈值應能承载蜘蛛正常的抓取节奏，而不是按人工浏览的速度来定。
判断限流是否合理的简單办法：看它在正常日子里有没有拦下過任何一次搜尋引擎請求。如果有，阈值就偏紧了。
恢复之後還要看几天
規則調整之後，抓取量不會立刻回到原来的水平。蜘蛛有自己的抓取安排和重试节奏，被拒绝過的 URL 往往要等下一轮才會重新進入队列。建议连續观察几天日誌，比較調整前後同一批 URL 的抓取次數、狀態碼分布和响應時間，確認 403 與 429 已经消失，再判断其他环节是否還有問题。
把這套检查寫進运维清單：每次調整 CDN 配置、更換 WAF 規則、修改限流阈值之後，都回头看一眼蜘蛛的請求有没有被誤伤。這比抓取量掉下来之後再排查要省事得多。