很多人遇到过这种情况：一个页面早就不需要了，meta robots 里加了 noindex，robots.txt 里也屏蔽了抓取，过了几周去搜，URL 还在。于是开始怀疑是不是指令没写对。多数时候指令没问题，问题在于两条规则同时用，把蜘蛛需要读取指令的那条路先堵死了。
noindex 是一条页面级指令
noindex 的生效前提，是蜘蛛能抓到这个页面。它写在 HTML 的 head 里，或者通过 HTTP 响应头返回，蜘蛛只有实际发出请求、拿到响应，才可能读到。而 robots.txt 的 Disallow 作用在请求之前，它告诉蜘蛛：这个路径不要来抓。
两者叠在一起的结果是：蜘蛛不来抓，就读不到 noindex，索引里那条旧记录缺少新的判断依据。它可能继续留着 URL，也可能只保留一个不带摘要的结果。这不是 noindex 失效，而是指令根本没被送到。
先分清页面属于哪一类
- 彻底不要了：比如活动页下线、商品永久停售。这种情况让服务器返回 404 或 410 更直接，等于明确回答“这里没有内容”。
- URL 还要保留：比如有人外链，或者要被其他页面引用。这类页面应当允许抓取，加上 noindex，等索引里的记录移除后，再考虑是否需要屏蔽抓取。
- 不希望被访问：比如后台、测试页、内网入口。这类应该用登录校验、401/403 或 IP 限制，robots.txt 只能算补一层，不能当权限用。
多数“退不出索引”的案例，问题出在把第二类和第三类的做法混在了一起。
404、410 与 noindex 的分工
404 和 410 都是服务器对请求的响应，蜘蛛来了就能立刻得到信号，不需要读页面内容。410 比 404 更明确地表示永久移除，但两者的实际差别通常没有想象中那么大。noindex 需要蜘蛛抓取并渲染后才生效，链路更长一层。
如果页面还在线、只是内容不再适合出现在搜索结果里，用 noindex。如果页面本身已经不存在了，就让服务器正常返回 404/410，而不是返回 200 再挂一个 noindex，后者容易被当成软 404 处理，判断反而更慢。
已经屏蔽了抓取，怎么补救
确认页面策略后，可以按这个顺序处理：
- 先把 robots.txt 里针对该路径的 Disallow 去掉，让蜘蛛能够重新抓到页面。
- 保留或补上 noindex，确保它能被读到。如果是脚本动态写入的 meta，先确认渲染后的 HTML 里确实有这条标签。
- 观察服务器日志或抓取统计，确认蜘蛛确实重新请求过。没有被抓之前，状态不会变。
- 确认索引里的记录已经移除后，如果仍然不想被抓，再考虑恢复 robots.txt 屏蔽。
顺序反过来做，很容易卡在原地：屏蔽着抓取，又等着 noindex 生效，两边互相等待。
几个容易踩的坑
- 把 robots.txt 当删除工具：它只控制抓取，不控制索引。被屏蔽的 URL 仍然可能出现在结果里，只是没有摘要。
- 屏蔽后看到还在索引，就以为规则写错：规则生效需要蜘蛛的下一次访问，而访问频率取决于站点整体的抓取情况。
- 把 meta 标签写在 body 里：位置不对，通常读不到。
- X-Robots-Tag 路径写错：响应头是按请求匹配的，写错目录可能让整站都带上 noindex。
不承诺时间，但要留出观察窗口
索引更新没有固定周期。抓取频率高、内链多的页面处理得快一些，长期没有入口的页面可能拖得久。比较稳妥的做法是给每批处理留出至少几周的观察期，用抓取日志和索引状态两个维度对照，而不是只盯着搜索结果页面看。
先想清楚这个 URL 是“要删除”还是“要隐藏”，两者的处理路径完全不同。混用 robots.txt 和 noindex，只会让状态更模糊。