在收录相关的操作里，robots.txt、noindex 和 canonical 是最常被混在一起用的三个手段。它们的共同点是看起来都能减少页面被收录，但实际作用的位置完全不同：一个在抓取层，一个在索引层，一个在归一化层。用错层级，最常见的后果不是页面被屏蔽，而是指令根本没生效，或者页面卡在一个尴尬的中间状态。
先分清三道闸门各管哪一层
可以按抓取流程的先后顺序理解：
- robots.txt：作用在抓取层，决定蜘蛛能不能请求这个 URL。它是站点级的文件，按路径前缀匹配。
- noindex：作用在索引层，决定已经抓取到的内容要不要进索引。它写在页面里，属于页面级指令。
- canonical：作用在归一化层，告诉搜索引擎这几个 URL 里哪个是自己希望被采用的主版本。它是建议，不是强制。
顺序很重要：抓取在前，索引在后，归一化跟在两者之后。一个页面如果抓不到，后面两层就没有机会被执行。
robots.txt 屏蔽的是抓取，不是收录状态
robots.txt 里写 Disallow，蜘蛛就不会去请求对应路径。但这并不等于该页面立刻从索引里消失。已经进入索引的 URL，可能还会以链接形式出现在结果中，只是缺少标题和摘要。想让它彻底退出，通常需要先放开抓取，让蜘蛛能读到页面上的 noindex，处理完成后再重新屏蔽。反过来，一边 Disallow 一边在页面上写 noindex，等于让 noindex 永远读不到，页面会长期停在已收录但内容不可见的状态。
判断顺序很简单：只要 robots.txt 不允许抓取，页面上任何关于索引的指令都等于没写。
noindex 生效的前提是页面能被抓取
noindex 是一个页面级指令，可以放在 meta robots 里，也可以通过 HTTP 响应头 X-Robots-Tag 下发。它需要蜘蛛真正拿到这个页面才能读到。所以常见失效场景有两个：
- 页面被 robots.txt 屏蔽，指令读不到。
- 页面返回 404、5xx 或者经过重定向，响应头里的 X-Robots-Tag 不一定能传递到最终 URL。
另外，noindex 与 canonical 同时出现在一个页面上时，如果 canonical 指向了别的 URL，而那个目标 URL 本身是可索引的，处理结果会变得难以预测。比较稳妥的做法是：确认要移出索引的页面，就让它自己 noindex，不要同时再指一个可索引的 canonical 出去。
canonical 解决的是多个 URL 选哪个，不是删掉哪个
canonical 常被当成合并重复内容的工具，但它做的是版本选择。它不会让被指向的 URL 从抓取范围里消失，也不保证一定被采纳。搜索引擎会综合内链、sitemap、历史收录情况做判断。如果站点里同时存在参数版本、排序版本、打印版本，先用 canonical 做归一化是合理的；但如果希望某个页面根本不进入索引，canonical 不是合适的工具，应该用 noindex。
还有一点容易忽略：canonical 指向的页面本身如果被 noindex 或 robots 屏蔽，整条信号链就断了，被指向的 URL 不会因此获得收录。
实际操作的组合顺序
把三道闸门按流程排一下，处理起来会清晰很多：
- 先确认这个 URL 希望处于什么状态：可抓可索引、可抓不索引，还是既不抓也不索引。
- 只想移出索引：保持 robots.txt 允许抓取，在页面或响应头加 noindex，等索引状态更新后再考虑是否屏蔽抓取。
- 只想节省抓取配额、不涉及移出索引：用 robots.txt 屏蔽，并接受它可能仍以 URL 形式存在。
- 多个 URL 指向同一内容：用 canonical 选主版本，同时把其他版本从内链和 sitemap 中收敛。
- 改完指令后，回到抓取日志和索引状态里核对，而不是只看配置文件有没有写对。
这三种手段经常被并列写进同一份收录优化清单，但它们的生效条件和观察口径都不一样。写之前先问一句：我卡住的是抓取、索引，还是版本选择？答案不同，该动的开关也不同。