页面删掉、合并或者临时停用，是站点运营里很常见的事。但把文件从服务器上移走，并不等于索引里的记录会跟着消失。索引有它自己的节奏和判断逻辑，中间如果操作顺序不对，反而可能让旧地址停留更久，或者把本来该传递的信号一起切断。
先明确三种不同的下线
很多时候处理混乱，是因为把三种情况混为一谈：彻底删除（内容以后不再存在）、换地址（内容还在，只是位置变了）、暂时停用（过段时间还要恢复）。换地址适合用 301 指向新地址；彻底删除用 404 或 410；暂时停用更适合返回 503，或者保留页面但做适当处理，直接删成 404 并不划算。
404 和 410 的差别在哪
两者都表示页面不存在，410 更明确地表达“已永久移除”。实际抓取中，两者被处理的差异没有想象中那么大。真正关键的是：返回的必须是真实状态码，而不是用 200 状态返回一个“内容已删除”的提示页。后者容易被当成正常页面继续保留，旧地址反而更难退出。
先 noindex 再删除，还是直接删
常见建议是先给页面加 noindex，等它从索引里离开后再删。好处是页面还在，蜘蛛依然能抓到 noindex 信号，移除路径更确定。直接删成 404 也能最终移除，只是过程依赖蜘蛛再次抓取。两种做法都可以用，但如果页面上还挂着大量内链、仍被 sitemap 收录，先处理这些入口，往往比纠结顺序更重要。
停掉指向旧地址的入口
蜘蛛是靠链接发现 URL 的。旧地址的入口没清理干净，它会持续被抓取，看起来像“还活着”。需要一起检查的地方包括：
- 站内链接：导航、面包屑、正文引用、相关推荐、侧栏模块
- sitemap：把旧 URL 从提交文件中移除
- 结构化数据、RSS、站内搜索结果页
- 对外投放、合作页面或历史外链里的指向，能改的改，不能改的接受一段过渡期
这些入口不需要一次性全部处理完，但至少要保证主要入口不再指向已经不存在的地址。
canonical 和索引移除工具的使用边界
canonical 表达的是“合并信号”，不是删除指令。如果旧地址的内容迁到了新地址，用它做指向是合理的；但如果你只是想让旧地址从索引里消失，用 canonical 效果有限，因为它默认旧页面依然存在，只是不再作为代表版本。索引移除类工具适合紧急场景，比如误公开或不希望短期出现的内容。它有明确期限，属于临时手段，长期还是要靠页面本身的状态码和入口清理来配合。涉及隐私或法律类内容另有专门渠道，普通内容不必走那条路。
怎么判断旧地址是不是真走了
site: 指令只能看个大概，不能当作准确数字。更可靠的观察方式是站内定期抽样、看服务器日志里旧地址的抓取频率是否下降、看后台的索引相关报告。时间上没有统一答案，从几天到几周都有可能，取决于原来的抓取频率和页面在站内的位置。
几个容易踩的坑
- 用 200 状态返回“此内容已删除”的提示页
- 旧地址 301 到一个内容不相关的新页面，容易被判为软 404
- 页面删了，但 sitemap 和内链没动
- 一批页面同时删除，站内出现大量死链，影响其他页面的抓取
- 本来只是临时停用，却直接设成 404，恢复后又要重新等待
把“页面下线”拆成两件事看待：让 URL 不再可访问，和让索引里的记录离开。前者几分钟就能完成，后者需要状态码、入口清理和时间共同作用。
整体思路是：先确定下线类型，再选状态码，然后清理入口，最后留出观察期。顺序不必卡得很死，但每一步都要落实，否则索引里的旧地址可能比预期停留得更久。