蜘蛛池入口页能不能发挥作用，前提是搜索蜘蛛真的抓到了那个页面。但不少站点在入口页前面挂了 WAF、CDN 或自建防火墙，结果蜘蛛请求被拦下，返回 403、429，甚至一个验证码页，入口页里的目标 URL 自然也就无从被发现。这里把拦截的几种情况拆开说。
先看清楚拦截发生在哪一层
不同层的拦截，蜘蛛看到的结果完全不一样：
- 网络层：按 IP、IP 段或地区直接拒绝，蜘蛛可能连连接都建不起来，源站日志里看不到任何请求记录。
- UA 与请求头层：识别 User-Agent 或缺失的请求头，直接返回 403。
- 频率层：短时间内请求过多触发限速，返回 429 或 503。
- 人机校验层：返回 JS 挑战或验证码页面，HTTP 状态码通常还是 200。
被拦截时，蜘蛛实际看到了什么
403、429、503 这类状态码，等于明确告诉蜘蛛这次抓取失败。多数搜索引擎会在一段时间后重试，但如果长期如此，抓取频率会明显下降，入口页上的链接也就一直没机会被解析。返回 503 时，如果能在响应头里带上 Retry-After，给出一个明确的重试时间，比让蜘蛛反复试错要友好一些。
更麻烦的是返回 200 的验证码页或空壳页。状态码正常，蜘蛛会当成一次成功的抓取，把页面解析一遍，可页面里既没有正文也没有目标链接。抓取额度被消耗掉了，URL 发现却没有发生，日志上还会显示蜘蛛来过。
判断标准很简单：蜘蛛拿到的 HTML 里有没有可解析的 a 标签。没有，这次抓取对 URL 发现就是无效的。
怎么确认是被拦了，而不是蜘蛛没来
- 查服务器访问日志，按搜索引擎官方公布的 IP 段过滤，看有没有对应的请求记录。
- 对出现的 IP 做反向 DNS 查询，确认域名归属，不要只看 User-Agent。
- 统计响应码分布，看这些请求是否集中在 403、429、503。
- 用工具模拟不同 UA 请求入口页，对比返回内容是否一致。
- 确认 CDN 或 WAF 侧是否有独立的拦截日志，很多拦截根本不会落到源站日志里。
想让发现能力恢复，可以调整的方向
- 在 WAF 中为已通过验证的搜索引擎 IP 段放行，同时保留反向 DNS 校验，而不是只匹配 UA 字符串。
- 对来自搜索引擎的请求关闭 JS 挑战和验证码，直接返回静态 HTML。
- 给入口页设置独立的限速规则，不要和普通用户请求共用同一个阈值。
- 保持入口页链接以普通的 a 标签加 href 形式输出，不依赖脚本渲染后再拼出地址。
- 如果确实没法放开拦截，可以把 URL 发现渠道分散到 sitemap 或 HTTP Link 响应头，而不是死磕入口页这一条路。
入口页数量多时，拦截的代价会被放大
如果同一批入口页部署在相近的 IP 段上，一个网段被整体限速，往往会牵连整批页面。这种情况下，比起逐个调整 WAF 规则，更实际的做法是把入口页分散到不同 IP、不同域名，避免一个节点出问题就全量停摆。
两个常见误区
一是认为只靠 User-Agent 白名单就够了。UA 可以随意伪造，正规做法是 UA 加 IP 反查双重验证，既拦住假冒流量，也不误伤真蜘蛛。
二是认为拦截只是影响抓取速度。实际上当入口页对蜘蛛始终不可读时，它连“被发现的页面”都算不上，后续所有依赖它传递链接的环节都不会启动。