用浏览器打开入口页，看到的是完整内容；换一个不带 Cookie 的工具再抓一次，可能只剩一个登录提示或者一段空壳。这种落差在蜘蛛池里很常见，原因往往不在页面本身，而在服务端的会话逻辑。
蜘蛛手里没有你昨天留下的 Cookie
搜索引擎蜘蛛的抓取请求通常是无状态的：它第一次来不带 Cookie，服务器下发 Set-Cookie 之后，它下一次来大概率还是不带。也就是说，任何“首次访问给一种内容、回访给另一种内容”的设计，在蜘蛛眼里都会被压缩成同一个版本——几乎永远是“首次访问”那个版本。
如果那个版本恰好是被精简、被拦截、被要求验证的版本，入口页对蜘蛛的可用性就会大打折扣。你用浏览器换 IP 测试十次都正常，是因为浏览器替你保留了 Cookie，蜘蛛没有这个过程。
依赖 Session 的判断最容易踩空
- 访问计数：靠 session 记录“今天第几次来”，蜘蛛每次都算第一次，可能永远命中限流分支。
- 内容分级：以“未登录只显示摘要”作为默认逻辑，蜘蛛拿到的就是摘要。
- 弹窗同意：如果服务端在缺少某个同意 Cookie 时直接返回遮挡层，蜘蛛读到的也是遮挡层。
- 验证跳转：先种一个 Cookie，再靠 JavaScript 校验它是否被带回来，蜘蛛基本过不去这一关。
这些问题在普通用户视角几乎看不出来，但在入口页这种专门给蜘蛛看的位置上，代价会被放大。
Set-Cookie 本身不拦蜘蛛，拦的是依赖它的逻辑
下发 Cookie 是正常行为，搜索引擎不会因为响应里有 Set-Cookie 就拒绝抓取。真正有风险的是后续那套“必须有 Cookie 才放行”的机制：它把蜘蛛推到了一个它无法满足的条件上。同理，CDN 或 WAF 如果在 Set-Cookie 之后加了校验，也可能让入口页对蜘蛛返回一个中间态页面。
还有一种情况是 Cookie 与缓存互相干扰：CDN 缓存了一份带 Set-Cookie 的响应，不同访客拿到的状态彼此污染。入口页最好保持可缓存、无个性化，减少这类不确定性。
几个常见误区
- “我关了 JavaScript 也能看到内容，所以蜘蛛没问题”：脚本执行只是其中一个变量，Cookie 和会话是另一条独立的线，要分别验证。
- “用无痕模式就等于蜘蛛视角”：无痕只是不保留 Cookie，请求头、UA、IP 依然和蜘蛛不同，只能算近似。
- “加了防爬顺带就把坏蜘蛛挡了”：多数通用防爬手段不区分好坏，容易连同正常蜘蛛一起挡在门外。
- “测试时正常，上线就一定正常”：上线后 CDN、WAF、负载均衡各自可能引入新的会话行为，最好在真实链路再验一次。
使用建议
- 让入口页尽量无状态：不依赖 session 决定返回什么内容，第一屏对任何访客保持一致。
- 验证时用不带 Cookie的方式抓取，例如命令行请求或明确禁用 Cookie 的抓取工具，把返回体与浏览器看到的版本做对比。
- 如果业务上必须有登录或验证逻辑，确认存在一条对蜘蛛放行的路径，并且这条路径返回的是真实内容而不是占位页。
- 想区分访客类型，靠日志里的 UA、IP 段和访问频率去分析，不要用 Cookie 当作蜘蛛检测手段。
- 检查 CDN 与 WAF 规则，避免“种 Cookie 再二次校验”的链路把入口页变成一道门槛。
把入口页当成一个公开、无状态的页面来对待，通常比研究各种识别技巧更省事。蜘蛛不需要被特别接待，它只需要不被拦住。