入口页写好了，代码里也没有任何屏蔽写法，但服务器日志里几乎看不到搜索蜘蛛的访问记录，目标 URL 也迟迟没有被发现。这种情况问题往往不在 HTML，而在请求还没抵达入口页之前就被拦下了。
被拦截时，搜索蜘蛛实际会看到什么
防火墙、CDN 安全模块或主机自带的安全插件，通常在请求到达应用层之前就做出判断。对抓取而言，结果大致分三类：
- 直接拒绝：返回 403、406 或 503，蜘蛛这次抓取失败，可能稍后重试，也可能把入口页标记为暂时不可用。
- 软拦截：返回状态码 200，但页面内容是验证页、跳转页或一段空壳 HTML。蜘蛛拿到了响应，却没有拿到任何链接。
- 排队或降速：返回 429，或者把请求放进慢速通道，抓取频率被压得很低，发现目标 URL 的时间被拉长。
第三种情况最容易被忽略，因为状态码看起来不算严重，但在日志里会表现为蜘蛛来过一两次之后就再也不出现。
几种容易被忽略的拦截形式
整站级的 WAF 规则
有些规则是为了防刷和防采集，命中条件可能是请求频率、请求头缺失、访问路径特征，甚至 IP 所属的机房号段。蜘蛛从固定 IP 段发起请求，反而容易撞上这类规则。入口页如果只是一堆链接、没有正文，还可能命中“疑似采集页面”的规则。
JavaScript 挑战与验证码
这类拦截返回的也是 200，内容是一个需要执行脚本或点击验证的页面。搜索蜘蛛基本不会去完成验证，于是它拿到的就是一个没有链接的页面。判断方法很简单：用不带 Cookie、不执行 JS 的方式请求入口页，看返回的 HTML 里到底有没有目标链接。
速率限制
如果同一台服务器上放了很多入口页，或者入口页在短时间内被大量访问，速率限制很容易被触发。触发之后不一定立刻返回错误，有时只是把后续请求延迟处理，表现就是抓取断断续续。
怎么确认是拦截，而不是蜘蛛根本没来
- 在服务器日志或 CDN 日志里按搜索引擎的 User-Agent 过滤，先看有没有记录。完全没有记录，说明请求在更前面就被丢弃了。
- 看响应码分布。大量 403、429、503，基本可以锁定是拦截。
- 用命令行模拟一次请求，对比带与不带常见蜘蛛 UA 的返回结果。如果两者返回内容不同，说明存在基于 UA 的分流。
- 检查 robots.txt 本身是否也被拦截。如果连它都返回 403，蜘蛛可能连抓取范围都读不到。
- 看安全插件或 WAF 的控制台日志，确认命中的是哪条规则，而不是凭猜测调整。
放行时要注意的边界
确认真的是误拦之后，处理方式通常是给已知的搜索引擎 IP 段或验证过的 UA 加白名单、单独给入口页路径降低拦截等级、关闭 JS 挑战、放宽速率限制。这里有几个容易踩的坑：
- 只靠 User-Agent 白名单并不安全，UA 可以伪造，更稳妥的做法是 IP 段与反向解析结合验证。
- 不要为了放行而整站关闭安全模块，其他路径可能正在依赖这些规则。
- 放行后不要立刻下结论，蜘蛛重新抓取需要时间，观察一到两周的日志趋势更可靠。
- 拦截解除不等于链接一定被发现。入口页还需要能被正常解析、链接确实存在于 HTML 中，并且没有其他屏蔽手段叠加。
排查顺序建议从“请求有没有到达”开始，而不是从 HTML 写法开始。很多所谓的链接不被发现，其实是响应根本没让蜘蛛读到内容。
把拦截问题解决之后，入口页只负责让目标 URL 进入待抓取队列，什么时候真正被抓取、抓取之后如何处理，仍然取决于目标页本身的可访问性和内容质量。这部分没有捷径，只能靠持续观察日志来判断。