站点更新之后迟迟看不到抓取动静，很多人会先去改内链、调 Sitemap，但排查到后面才发现，请求根本没到达源站——它们被 CDN、WAF 或者服务器上的安全模块挡在了外面。抓取路径的第一环不是 URL 发现，而是请求能不能进来。这一环被切断，后面所有的调整都没有意义。
抓取被拦时，会看到哪些信号
拦截往往不是“全断”，而是部分、间歇地发生，所以很容易被误判成抓取频率低。可以先看几个特征：
- 源站日志里完全没有蜘蛛 UA 的请求记录，但抓取统计工具显示有访问；
- 日志里出现集中的 403、406、429，且时间段比较规律；
- 用同一台服务器直接请求页面正常，换成抓取来源的 IP 段就被拒；
- 抓取量在某个时间点明显下滑，站内结构和内容却没有变化；
- CDN 或防火墙后台的“已拦截请求”数量突然上升。
出现两条以上，就值得把排查方向从页面层移到网络层。
拦截通常发生在哪一层
CDN 与边缘节点
边缘节点上的机器人防护、频次限制、地区策略，都可能把抓取请求提前拦掉。源站日志很干净，是因为请求在边缘就结束了，压根没有回源。这类情况最容易被误认为“内容没被收录”。
WAF 规则
WAF 的默认规则集偏向拦截可疑流量。抓取请求如果短时间内集中访问大量 URL、带上较长的参数，或者触发了注入、路径穿越之类的误报特征，就可能被判定为攻击。抓取速率越高，越容易踩到频次阈值。
源站防火墙与安全插件
iptables、云主机安全组，以及部分 CMS 自带的防护插件，也会按 IP 或请求特征做拦截。它们的特点是日志分散，需要分别查看，容易在排查时被漏掉。
限速与并发限制
Nginx 的 limit_req、limit_conn，或者应用层的连接上限，会让并发的抓取请求被直接丢弃。表现出来是响应时间忽长忽短，或者一部分请求干脆超时。
按什么顺序排查
- 先确认请求有没有到达源站。对比源站日志与 CDN 日志，看抓取请求是在边缘消失，还是回源之后才被拒。
- 如果请求没有回源，检查边缘节点的机器人规则、频次限制和地区策略。
- 如果回源后被拒，看状态码分布。403 多为规则拦截，429 多与限速有关，406 常与请求头校验相关。
- 用测试工具模拟抓取请求，逐个关闭防护模块，把问题定位到具体规则，而不是停在“可能是 WAF”。
- 确认是规则问题后，按最小范围放行，而不是整体关掉防护。
放行时的几个原则
- 不要只按 UA 放行。UA 可以伪造，只认 UA 既不能保证真实蜘蛛一定通过，也等于给攻击者留了一扇门。
- 优先用 IP 段或反向 DNS 验证。把官方公布的抓取 IP 段加入白名单，或做反向解析校验，可靠性更高。
- 频次阈值要留余量。限速卡得太紧，正常抓取也会被丢包，可以对已验证的来源单独放宽。
- 区分不同路径的防护强度。登录、搜索、表单提交等路径保持严格，正文页和列表页可以适度放宽。
放行的目标是让正常抓取稳定通过，而不是让防护失效。每次调整后记录改动时间与规则编号，出问题时能快速回退。
放行之后要观察什么
规则改完不等于问题解决，还要看恢复情况：源站日志里抓取请求是否重新出现、状态码是否转为 200、抓取频率是否逐步回升。如果请求回来了但抓取量仍然偏低，那才需要回到 Sitemap、内链结构、抓取预算这些层面继续查。
把网络层和页面层的排查分开，能少走很多弯路。抓取请求先要进得来，URL 发现和抓取路径才有讨论的空间。