有些站点内容本身没问题，链接也能打开，但蜘蛛拿到的永远是首页、登录页或一段验证脚本。排查时先别急着怀疑内容质量，看看服务器和前端有没有在蜘蛛到达内容之前就把它拦下来了。
蜘蛛常见的几种被拦现场
- 整站或部分栏目需要登录才能查看，未登录请求被 302 跳到登录页。
- Cookie 同意弹窗、地区选择弹窗、订阅弹窗盖住正文，未点击时内容不渲染。
- CDN 或主机面板开启的人机验证、等待跳转对未知 UA 一律返回 403 或 503。
- 防火墙按 UA、IP、请求频率做限制，蜘蛛的 IP 段被误伤。
- 测试环境加了 basic auth，正式上线时忘了摘掉。
先确认蜘蛛到底拿到了什么
最直接的办法是看服务器日志里蜘蛛 UA 对应请求的状态码分布。如果某个目录下大量返回 302、401、403、429 而不是 200，基本可以判断拦截发生在内容之前。这类响应同样会消耗抓取配额，日志里塞满非 200 记录，真正的内容页反而被访问得更少。
用匿名请求模拟一次
- 用命令行工具带上蜘蛛 UA 请求一个具体内容页，只看响应头和状态码。
- 清掉所有 Cookie 再请求一次，对比两次返回是否一致。
- 如果第一次是 200，清 Cookie 后变成 302，说明存在基于会话的跳转。
- 把请求频率稍微提高，看是否出现 429，判断限速阈值是不是设得过低。
移动端与主机端一起看
有些跳转是前端脚本做的：页面先返回 200，再由 JS 判断登录状态跳走。这种在原始 HTML 里能看到完整内容，但渲染后的页面会变成登录页。两种状态都要检查，别只看其中一边。主机侧的防火墙规则、CDN 的机器人策略，也只能在服务端日志里才能看清。
该放行的放行，该保护的保护
不是所有拦截都要取消。付费内容、用户中心、后台路径本来就该挡住蜘蛛，这部分要做的是让它明确知道不该抓，比如用 robots.txt 或页面指令声明，而不是让它一次次撞 401。真正需要放行的是公开内容页、栏目列表页和站点地图。
用 UA 或 IP 白名单放行要谨慎：UA 可以伪造，反向解析也不是所有主机都稳定支持。更稳妥的做法是让公开内容不依赖登录态，从根上减少需要放行的场景。
拦截问题排查清单
- 公开内容在未登录、无 Cookie 状态下能否直接返回 200。
- CDN 与防火墙的机器人规则里，是否把搜索引擎蜘蛛列进了挑战或限速名单。
- 弹窗组件是否阻塞了正文的首次渲染。
- 是否还有多余的 basic auth、内网 IP 限制、地域封锁仍在生效。
- 站点地图里的地址是否和返回 200 的地址一致，有没有指向登录跳转。
这类问题的特点是站点看起来一切正常，只有从蜘蛛的视角走一遍才会暴露。建议把匿名访问检查固定进上线流程：改版、调整防火墙规则、更换 CDN 之后都重新验证一次。