站内总有一些 URL 不希望出现在搜索结果里：后台页面、测试环境、参数组合页。处理这类页面时，最常见的动作是往 robots.txt 里加一条 Disallow，或者给页面加上 noindex。这两种手段经常被当成同一件事来用，但它们在抓取和索引链条上所处的位置并不相同，用错场景会得到一个尴尬的结果——URL 还留在索引里，而你却抓不到它的最新状态。
两种手段卡在不同的位置
把搜索处理的流程简化成三步：发现 URL、抓取内容、决定是否索引。robots.txt 起作用的是第一步到第二步之间，它在爬虫发出请求之前就告诉对方“这个路径别抓了”。而 noindex 是一个写在页面里的指令，它必须等爬虫把页面抓下来、读到这行标记之后才会生效，作用点在第三步。
位置不同，带来的直接后果就是：robots.txt 能阻止抓取，但不能直接移除一条已经存在的索引记录。如果一个 URL 早就被抓过、进了索引，之后再补上 Disallow，爬虫只是不再去读它，那条旧记录可能长期保留，摘要信息还可能停留在很早的版本上。
常见的第一种误用：用屏蔽代替移除
典型场景是发现某个目录被索引了，第一反应是加 Disallow。加完之后去查，URL 依然在，于是以为指令没生效，又反复调整写法。实际上指令是生效的，只是屏蔽本来就不负责移除。更麻烦的是，因为爬虫不再抓取，你后续想通过修改页面、加上 noindex 来让它退出，这条路也被自己堵住了——爬虫进不来，读不到 noindex。
还有一种情况是页面被屏蔽后仍出现在结果里，但不再显示摘要，用户看到的是一个空壳条目。有人据此判断“屏蔽没用”，其实这是屏蔽生效后的正常表现之一，只是它没有完成你真正想要的那一步。
常见的第二种误用：该屏蔽的却只加了 noindex
反过来，如果一类 URL 数量巨大、彼此高度相似，而且你确定它们没有任何进入索引的价值，那只加 noindex 并不划算。爬虫仍会持续抓取这些页面，读完整篇内容后发现是 noindex，白白消耗抓取额度。这类页面更适合用 robots.txt 挡在抓取之前，前提是它们本来就没被索引过。
所以判断的关键不在“哪种更强”，而在页面当前处于哪个状态。
按状态选手段
- 从未被抓取、也不想被抓取：robots.txt 屏蔽，成本最低，直接省掉抓取。
- 已经被索引、想要移除：先让它可被抓取，页面返回 noindex，或直接返回 404 / 410，等重新抓取后记录才会更新。
- 内容本身要保留、只是不希望被搜到：用 noindex，配合登录或其他访问控制。
- 整站临时不希望被抓：用 robots.txt，但要清楚已索引的页面不会因此消失。
从发现到移除的核对顺序
- 确认 URL 当前是否真的在索引里，用多种方式交叉核对，避免只看单一结果。
- 确认该 URL 是否可被抓取：如果 robots.txt 里已有屏蔽规则，先把它放开。
- 给页面加上正确的 noindex 标记，注意是响应头还是 meta 标签，两者不要重复冲突。
- 确认页面本身返回的状态码合理，不要出现“200 但内容是空的”这类情况。
- 等待爬虫重新抓取。这个周期取决于站点规模、更新频率和外部链接情况，没有固定天数。
- 重新核对索引状态，未消失时先检查是否又被新的屏蔽规则挡住。
一个反复出现的死循环是：先屏蔽、后想移除、发现移除不了、再加屏蔽。理顺顺序比反复改规则更有用。
几个容易忽略的细节
noindex 和 canonical 同时存在时，指令之间可能互相影响，处理前最好只保留一个明确意图。另外，robots.txt 的规则是前缀匹配，写得过宽可能连带屏蔽掉本该被收录的目录，改动后建议用抓取测试工具验证几条代表性 URL。
搜索引擎也提供过临时的移除入口，可以在记录更新前先把 URL 从结果里撤下来。但它是临时的，页面本身的问题不解决，过一段时间还会回来，所以它适合配合上面的固定处理一起用，不适合单独依赖。
最后，把这类规则当成需要维护的配置，而不是一次性的开关。站点结构调整、目录改名、参数规则变化时，回头看一遍 robots.txt 和页面上的索引指令，能省掉不少事后排查。