页面删了、合并了、改版换地址了，过一阵子再去搜，仍然能看到旧 URL。用户点进来要么是 404，要么被丢到首页却找不到想要的内容，体验和信任都会打折扣。让旧地址从索引里退出，并不是发一个 404 就立刻完成的，中间有几个先后顺序值得理一理。

第一步：先判断这个 URL 该合并还是该消失

这一步决定了后面所有动作的方向，判断错了，后面的清理都是白做。

• 有等价或更好的替代页面：用 301 把旧地址指向新地址，用户和权重都落到新页面上，索引会逐步替换成新地址。
• 内容确实不再提供，也没有替代：让它返回 404 或 410，明确告诉蜘蛛这个地址不存在了。
• 只是暂时下线维护：不要急着改成 404，保留页面并返回 503，或者干脆维持可访问状态，否则反复下线再恢复，抓取和索引状态会来回摇摆。

第二步：状态码别绕弯

决定让页面消失之后，最直接的做法就是让它返回 404 或 410。两者对搜索引擎来说都表示页面不存在，410 的表达更坚决一些，而 404 在多数场景下已经够用。真正需要注意的是两种绕弯写法：一种是返回 200 的“内容已删除”提示页，另一种是用 302 或 301 把旧地址指向首页。

返回 200 的错误提示页属于典型的软 404，蜘蛛会认为页面仍然存在，索引可能长期停在旧版本上；把无关的旧页面跳到首页，则等于用大量地址去指向同一个页面，容易被当成低价值跳转。

第三步：不要指望 robots.txt 和 canonical 帮你移除

robots.txt 拦的是抓取，不是索引。已经被收录的地址即使被 Disallow 掉，它仍可能留在索引里，只是标题和摘要信息变得不完整。更麻烦的是，被挡住之后蜘蛛抓不到页面，也就看不到页面上的 noindex。

canonical 表达的是“这两个地址属于同一个页面”，用在下线页面上并不合适。如果你确实想把旧地址合并到新页面，直接做 301 比在旧页面上写 canonical 更清楚。

第四步：站内清理要同步跟上

页面状态码改好只是对外的一侧，站内的引用不改，蜘蛛还会顺着旧链接一次次回来。

• 找出指向旧 URL 的内链，改指到替代页面，或者直接删掉。
• 从 sitemap 中移除该地址，避免提交明确的失效链接。
• 检查导航、面包屑、文章相关推荐、结构化数据里的地址是否还指向旧版本。
• 如果站内有搜索或聚合功能会自动拼出这个地址，也要一并处理，否则它会不断被重新生成。

第五步：确实需要加速时再用移除工具

搜索引擎后台一般提供移除请求，分临时和永久两类思路。临时移除相当于一个短期的遮挡，通常只维持几个月，到期后如果页面本身仍然可访问，它还是会重新出现。要让移除长期有效，前提仍然是页面本身返回 404、410，或者带有 noindex 且能被正常抓到。

这里有个容易被忽略的顺序问题：如果你先把地址写进 robots.txt 再请求移除，蜘蛛抓不到页面，也就确认不了 noindex，反而更容易长期留在索引里。合理的顺序是先让页面状态或 noindex 生效，再考虑提交移除请求。

多久能看到变化，以及怎么确认

生效时间取决于站点被抓取的频率，可能是几天，也可能是几周，没有固定值。想确认进度，可以看几个地方：用后台的 URL 检查工具查看当前状态，用站内搜索或指令查询旧地址是否还在，翻一段时间的抓取日志，看旧地址返回的状态码是否已经被蜘蛛读到。如果日志里旧地址还在被频繁抓取，通常说明站内还有入口没清理干净。

整个过程可以简单记成一句话：先把状态定清楚，再把入口清干净，最后才谈加速。跳过前面两步直接提交移除，往往只是把问题往后推一段时间。