发现某个页面迟迟不进索引，很多人第一反应是去看蜘蛛日志、去查 sitemap、去改内链。这些方向没错，但顺序上有个更省时间的起点：先确认这个 URL 在指令层有没有被明确挡在外面。抓取和收录是两个阶段，而 robots.txt、noindex 类指令、canonical 指向，恰好卡在这两个阶段的前面。如果页面本身被拒绝处理，后面的抓取频率、内链权重都谈不上。
指令层先看四样东西
所谓指令层，指的是网站主动告诉搜索引擎「这个页面可以怎么处理」的那些信号。它们分布在几个不同位置，容易被漏掉。
- robots.txt：整站或整个目录被 Disallow 之后，蜘蛛通常连请求都不会发出。这类页面在访问日志里看不到，但在 sitemap 里可能还挂着。
- HTML 里的 noindex 元标签：页面能被抓取，但抓完不会进索引。典型特征是「日志里有请求、索引里没有结果」。
- 响应头里的 X-Robots-Tag：常由服务器、CDN 或中间层下发，不在模板文件里，排查时最容易漏。它的作用和元标签类似，但生效位置和优先级需要单独确认。
- canonical 指向：页面没被禁止，却把「我是主版本」的身份让给了别的 URL。核对时看到索引里那条，其实是另一个地址。
被挡住时，症状各不相同
同样是「不收录」，指令层原因不同，表现出来也不一样，可以先按症状缩小范围。
日志里完全没有这个 URL
优先怀疑 robots.txt。逐条看规则，注意目录深度、通配符和行末是否被注释掉。站点改过目录结构时，旧规则可能还在屏蔽已经不存在的路径，也可能恰好覆盖了新路径。
日志里有请求，但就是没有索引
这种情况去看页面源码里的 noindex，以及响应头里的 X-Robots-Tag。两者只要有一个生效，页面就会被排除在索引之外。用命令行直接看响应头，比在浏览器里查看源码更可靠。
索引里出现的是另一个地址
多半是 canonical 规则出了问题。由程序统一生成的 canonical，一旦匹配逻辑写错，可能把全部内容页指向列表页或首页。此时正文页能抓取、能返回正常状态码，但索引里收录的是被指向的那个 URL。
排查一个 URL 的实操顺序
- 用无痕模式打开该 URL，查看页面源代码，搜索 noindex 关键字。
- 用命令行查看响应头，确认状态码和 X-Robots-Tag，顺便数一下中间经过几次跳转。
- 打开 robots.txt，对照该 URL 所在目录，判断是否被规则覆盖。
- 确认 canonical 指向的是自己还是别的地址，是否与实际主版本一致。
- 以上都干净，再去看抓取频率、页面内容和内链层面的问题。
一个页面同时出现 noindex 和 canonical 指向别处的情况并不少见。两个信号叠加时，不要凭印象判断谁优先，以实际生效的结果为准。
最常踩的坑是环境不一致
测试环境为了不被收录，模板里加了 noindex，上线时忘了去掉；或者反过来，正式环境被整体套上了一个限制抓取的头。也有站点把 robots.txt 当成临时开关，测试结束忘了改回来。这类问题一旦发生，影响通常是整批页面，而不是单页。
还有一种更隐蔽的情况：分环境配置写在 CDN 规则里，代码仓库里完全看不到痕迹。排查时只看模板文件，很容易得出「一切正常」的错误结论。
把检查做成固定动作
上新栏目、站点改版、更换 CDN、调整模板，都是容易碰到指令层的节点。与其每次出问题再回头查，不如把这几项做成发布前的固定动作：抽样几个有代表性的 URL，看响应头、看源码、看 robots.txt、看 canonical。花费的时间不多，但能省掉后面大量无意义的抓取分析。
顺序上记住一句话：先确认页面有没有被允许进，再讨论页面值不值得进。前者是开关问题，后者是质量与竞争问题。混在一起查，只会让排查周期越拉越长。