抓取量突然下降，或者某个目录的 URL 长时间只有“发现”没有“抓取”，很多站长第一反应是 Sitemap 或内链出了问题。但在实际排查中，还有一类原因是入口本身正常，只是请求在到达源站前后被挡下了：安全策略、频次限制、验证码页面。这几种情况在抓取日志里往往会留下比较固定的痕迹，值得单独核对一次。
一、先区分“没来抓”和“来了被挡”
这两种情况的表现很像，处理方向却完全相反。前者要回到 URL 发现和内链入口上找原因，后者则要考虑服务器与安全策略。判断方法很简单：看日志里到底有没有对应的请求记录。如果连请求行都没有，说明蜘蛛没走到这一步；如果请求存在但状态码或响应体异常，问题就在返回环节。
二、三类常见的拦截信号
1. 状态码异常且集中在同一时间段
403、429、503 是比较典型的三类。单独看某一个 403 说明不了什么，但如果同一个 UA 或同一网段在十几分钟内连续出现大量 403，而此前是正常的 200，大概率是触发了频次或规则限制。429 通常带有 Retry-After 头，可以看出对方建议的等待时间；如果这个头由边缘节点生成而源站日志里没有，就需要到 CDN 侧的日志里确认。
2. 内容层被替换
状态码仍然是 200，但返回的正文是验证码页、跳转脚本或一段极短的提示文字。这类情况比 403 更隐蔽，因为状态码统计上看不出异常。核对方式是对比同一 URL 在浏览器中的正常返回与日志中记录的响应体字节数，如果抓取记录的体积明显偏小，例如只有几百字节，基本可以判断内容被替换了。
3. 抓取行为本身的变化
被拦截之后，蜘蛛的表现也会变：对同一目录的抓取间隔拉长、只拿列表页不跟进详情页、或者干脆放弃该路径。这类变化不会写在状态码里，需要结合抓取频次的时间序列来判断。
三、日志核对可以做哪几步
- 按小时统计 403、429、503 的数量，找出突变点，与改版、CDN 规则调整、活动上量的时间对齐。
- 把出现异常状态码的 URL 按目录聚类，判断是全站现象还是集中在某个栏目。
- 对比响应体字节数，把明显偏小的页面单独列出来复核。
- 检查 UA 与来源网段：同一 UA 是否在短时间内请求了大量 URL，这更接近频次问题而不是身份问题。
- 确认 robots.txt 与 CDN 规则近期是否被改动，尤其是新增的限速、防爬、地域限制。
四、修复的先后顺序
- 先在 WAF 或 CDN 层放行已验证的搜索蜘蛛网段与 UA，而不是直接关掉全部防护。
- 再调整限速阈值，给抓取留出独立的并发额度，避免和真实用户共用一个桶。
- 然后处理内容层替换页，确认验证码与跳转只作用于可疑请求，不覆盖整个目录。
- 最后回看日志，确认异常状态码回落到正常水平，并观察内页是否重新被跟进。
拦截比例上升和抓取预算下降经常同时出现，不要只凭一个指标就下结论。
五、几个容易误判的边界
第一，偶发的 403 不一定是拦截，也可能是源站权限配置问题，或者不存在的文件被规则改写成了拒绝。第二，429 有时来自共享出口，站点自己没有限速，但同一出口的其他站点触发了限制。第三，缓存回源失败也会表现为 5xx，与拦截是两回事，需要看回源日志。第四，如果站点使用多种来源的入口分发，日志中的来源会混杂在一起，建议先按来源分组，再看每一组的异常比例，否则很容易把正常的频次波动当成拦截。
把拦截识别清楚之后，再回头核对 URL 发现、Sitemap 与内链结构，排查顺序会顺很多：先确认请求能正常到达并拿到完整内容，再讨论抓取路径与覆盖差异。