很多站点在清理低价值页面时，会在两个动作之间犹豫：一是加 noindex，二是在 robots.txt 里 disallow。看上去都在表达「我不想让这个页面出现在搜索结果里」，但对搜索蜘蛛来说，这是两件不同的事。前者的前提是蜘蛛已经进来了，后者是让蜘蛛根本进不来。
noindex 生效的前提，是页面先被抓取
noindex 只是一个写在 HTML 的 meta 标签，或者写在 HTTP 响应头里的指令。蜘蛛必须真正请求这个 URL、拿到响应、读到这条指令，才会把它记下来。也就是说，noindex 的页面依然会消耗抓取资源，依然会出现在服务器日志里。
而 disallow 是在抓取之前就生效的：蜘蛛读完 robots.txt 之后，多数情况下不会再去请求这个路径。代价是，如果这个 URL 已经被处理过，蜘蛛无法再进入页面读到 noindex，后续判断只能依赖其他信号，周期通常更长。
哪些页面适合 noindex，但保留抓取
- 站内搜索结果页：内容由用户输入决定，地址数量趋于无限，但每一条结果本身往往指向站内已有的正常页面。
- 标签页、分类归档靠后的翻页：有一定导航价值，但同质化严重。
- 用户中心、订单页、后台入口：不需要被索引，但蜘蛛能从外链或历史记录里找到，读到 noindex 后可以更快停止回访。
- 重复内容的变体：打印版、独立移动域名、参数化排序页等。
这些页面的共同点是：数量相对可控，或者本身就是站内链接结构的一部分。让蜘蛛读到 noindex，判断会更干净，也不会平白丢掉页面上的出链。
哪些情况更适合直接阻断抓取
- 参数组合爆炸的筛选页，比如多条件叠加生成的地址，数量没有上限。
- 内部接口、JSON 输出、调试地址，这些本来就不该被当成页面处理。
- 测试环境、灰度环境，如果和线上处在同一个域名下。
这类地址如果只加 noindex，蜘蛛仍然会一次次请求，抓取资源被摊薄。此时用 robots.txt 或者服务器层的访问控制更合适。
最常见的错误：disallow 之后指望 noindex 生效
如果页面已经被 disallow 挡住，蜘蛛读不到页面里的 noindex；如果页面没有被挡住，noindex 才能被读到。这两个指令叠在一起，通常得不到「既不被抓也不被收录」的干净结果，而是留下一个模糊的中间状态。
比较稳妥的顺序是：先撤掉 disallow，让页面可以被抓取，加上 noindex，等蜘蛛确实读到之后，再考虑用 robots.txt 挡住抓取。中间这段时间页面可能仍会出现在结果里，属于正常过渡，不必急着反复改动规则。
noindex 与 nofollow 不要混用
noindex 管的是这个 URL 本身要不要出现在结果里，nofollow 管的是页面上的链接还要不要被继续跟踪。给一个页面加 noindex，并不代表它的出链会被忽略。如果这个页面上有大量指向站外或低质量地址的链接，nofollow 是另一个需要单独考虑的动作。
反过来，一个页面即使被 noindex，它上面的内链依然可能帮助蜘蛛发现其他 URL。这也是为什么一些站点宁愿让这些页面继续被抓取，而不是一刀切地屏蔽。
非 HTML 资源怎么办
如果目标不是 HTML 页面，比如 PDF、图片，或者由接口返回的文件，meta 标签没有地方可写，就要用 HTTP 响应头里的 X-Robots-Tag。它和 meta 的作用类似，但覆盖面更广，也更适合在服务器或 CDN 层统一配置。
落地时的检查顺序
- 先列出真正需要排除的 URL 类型，按「数量是否可控」分成两堆。
- 数量可控的加 noindex，同时确认这些页面没有被 robots.txt 挡住。
- 数量不可控的走 robots.txt 或机房层的规则，并检查是否存在需要清理的历史入口。
- 确认 noindex 是写在 meta 还是响应头里，避免两处互相冲突。
- 观察一段时间的服务器日志，看这些路径的请求是否按预期变化。
最后一点提醒：noindex 是针对具体 URL 的，不是针对模板的。同一个模板渲染出来的页面，有的需要排除，有的需要保留，就要在输出层做判断，而不是在模板里一刀切。规则改完之后，给蜘蛛留出重新读取的时间，比频繁调整更容易得到稳定的结果。