排查收录时，很多人最先做的动作是在浏览器里打开链接，看到页面正常显示，就默认蜘蛛看到的也是这一份内容。实际情况经常不是这样：浏览器带着登录态、Cookie、本地缓存和完整的 JavaScript 执行环境，蜘蛛只有一次干净的请求。收录问题的第一步，往往不是猜算法，而是先把这两种视角对齐。
把“我能看到”换成“蜘蛛能看到”
最直接的办法是用一个不带任何身份的请求去访问页面，然后把结果和你在浏览器里看到的内容逐段比对。重点看三件事：返回的状态码是什么、原始 HTML 里有没有正文、渲染之后的 DOM 和原始 HTML 差多少。
如果原始 HTML 里只有导航和骨架，正文全靠 JavaScript 填充，那就要确认渲染这一步在你的站点上是否真的能完成。渲染不成功，蜘蛛拿到的就是一份空壳，后面讨论索引和质量都没有意义。
常见的几类差异点
- robots.txt 规则：某条 Disallow 覆盖了目标路径，或者规则写得太宽，把整个目录都挡在外面。
- 服务器或 CDN 按 UA 拦截：部分防护策略默认拦截没有浏览器特征的请求，直接返回 403 或跳转到验证页。
- 访问门槛：需要登录、需要验证码、限制特定地区访问，蜘蛛都进不来。
- 内容依赖渲染：原始 HTML 里没有正文，或关键链接是脚本生成的。
- 状态码异常：返回 200 但内容是错误提示页，或者每次访问都跳到首页。
- 页面级指令：head 里有 noindex，或者 canonical 指向了另一个 URL。
- 遮挡与延迟加载：正文在首屏之外、需要交互才加载，或整段内容被弹窗盖住。
一次可复用的自检顺序
- 用无 Cookie 的方式请求目标 URL，记录状态码和完整响应的头部。
- 查看响应体的前若干 KB，确认标题、正文首段、主要链接是否已经存在。
- 跟踪重定向链，确认最终落地的 URL 和预期一致，链条不要过长。
- 检查 head 区域的 robots meta 与 canonical，确认没有互相矛盾的指令。
- 用平台自带的 URL 检查功能查看渲染结果和抓取记录，与自己的请求结果对照。
- 如果站点有日志，把这次请求的时间点和日志里的记录对上，确认蜘蛛看到的是同一份响应。
抓取问题和索引问题要分开
自检结果通常落在两类里。一类是抓不到：规则拦截、状态码异常、内容根本没出现在响应里。这类问题的处理方向很明确，先把可访问性修好，再谈其他。
另一类是抓到了但不进索引：蜘蛛能正常拿到完整页面，状态码和指令都没问题，只是最终没有进入索引。这时继续调整抓取路径基本没有帮助，需要回到内容本身去看，例如页面之间是否高度相似、正文是否有独立价值、模板部分占比是否过高。把两类问题混在一起处理，很容易在不相关的方向上反复折腾。
能抓取只是前提，不是收录的保证。先把“蜘蛛能不能拿到”这一步确认清楚，再去判断“值不值得收”，排查效率会高很多。
建议把这次自检固定成一个上线前的动作，尤其是模板调整、CDN 策略变更、前后端渲染方式改动之后。与其在索引状态里反复猜测，不如直接看一眼蜘蛛收到的那份响应。