内容下线时，最常见的两个选择是返回 404 或 410。不少站长把它们当成同一件事，随手用框架默认的 404 处理，结果发现索引里的页面挂了几个月还在。这两种状态码都在说“这个地址没有内容了”，但表达的确定性不同，后续的处理路径也会略有差别。
先把边界说清楚：状态码影响的是移除判断的速度和确定性，不是“一定多少天删除”。页面最终何时从索引里消失，还取决于它被引用的程度、被抓取的频率，以及搜索引擎自己的调度节奏。
404 表示“暂未找到”，410 表示“永久不存在”
404 的字面含义是“这里现在没有东西”，它并不排除将来恢复的可能。搜索引擎遇到 404 时，往往会在之后一段时间里继续回访，确认不是临时故障，再决定是否移除。
410 的语义是“永久删除，不会再回来”。这是一个更明确的信号，通常能让移除判断更快落地，回访频率也会相应降低。对于确实不会再上线的页面，410 比 404 更省事。
什么情况下该用 301，而不是 404 或 410
比较稳妥的选择顺序是：能找到替代页面就 301，找不到才用 404 或 410。
值得转 301 的情况
- 旧页面有外部链接或自然流量，可以转到内容最接近的新页面；
- 产品换型号、栏目合并，新旧内容主题基本一致；
- 页面被站内其他文章引用，直接停掉会留下一堆死链。
可以干脆停掉的情况
- 活动页、临时专题页，结束后没有可承接的内容；
- 测试页、参数拼接批量生成的重复 URL；
- 内容已删除且不打算提供替代，站内也没有入口引用。
需要注意的是，301 是“内容搬家”，不是“删除”。把一堆不相干的旧页面统一 301 到首页，是常见但效果一般的做法：主题对不上，跳转容易被忽略，用户也会觉得被误导。如果确实没有对应页面，用 404 或 410 反而更清楚。
批量下架时，别一次全开
一次性把几千个 URL 全改成 404，会让抓取端在短时间内收到大量“消失”信号，也容易误伤那些其实还能救的页面。可以按顺序处理：
- 先导出这批 URL 的抓取与流量数据，筛出仍有访问和外链的部分；
- 对这部分优先安排 301，其余暂时保持原状；
- 观察一到两周，再对确认无价值的部分批量置为 404 或 410；
- 更新 sitemap，把已下架的 URL 移出，避免继续主动提交；
- 检查站内链接，把指向已下架页面的入口改成有效地址。
比较稳妥的节奏是分批，每批控制在几百个 URL 的量级，中间留出观察期。中大型站点尤其如此——一次性变更会同时影响抓取和索引两端，出问题时很难判断是哪一批带来的。
几个容易踩的坑
- 返回 200 的空页面：模板还在、正文被清空，状态码仍是 200，这属于软 404。抓取端会把它当正常页面反复抓取，比直接 404 更麻烦。
- 只删内容不改状态码：把正文清掉、留一句“暂无内容”，对索引来说这个页面依然存在。
- 404 页面返回 200：自定义错误页没有正确设置状态码，等于告诉搜索引擎“这个地址一切正常”。
- 下架后立刻删除所有内链：如果页面还有外部链接，建议先保留一段时间的 301 过渡，而不是瞬间断掉。
- 用 robots 屏蔽代替下架：被 robots 挡住的 URL 抓不到，状态码也读不到，索引里的旧内容反而可能停留更久。
怎么确认处理结果
下架之后主要看两件事：一是日志里这些 URL 的抓取频次是否下降，二是索引报告里对应的条目是否逐步减少。如果一两个月后仍被频繁抓取，通常说明还有内部或外部链接指向它们，需要回到链接层面检查。
下架处理的目标不是“让页面立刻消失”，而是让搜索引擎清楚地知道：这个地址以后不用再来了。状态码说得越明确，后续的抓取和索引负担越轻。
最后回到一个基本判断：能不能找到内容相近的替代页，是所有决策的起点。能找到就 301，找不到就用 404 或 410 明确结束。把这个顺序理顺，下架这件事就不会越处理越乱。