有些页面在浏览器里显示的是“没有找到”“该内容已下架”，但服务器返回的状态码却是 200。这类页面通常被称为软 404。它不像硬 404 那样明确告诉搜索引擎“这里没有内容”，反而会让抓取程序把一个空壳或错误提示当作正常页面处理。收录核对时，这类页面往往是最容易被忽略的一类。
软 404 为什么会被收进去
从抓取的角度看，状态码是判断页面是否有效的第一道信号。返回 200 时，搜索引擎会继续读取页面内容；如果内容里又有可索引的文字、标题和内链，它就可能进入索引。至于页面实际展示的是错误提示，抓取程序不一定能像人一样立刻判断。
常见的软 404 来源包括：参数错误但未做拦截的详情页、商品或文章下架后仍返回 200 的模板页、地区限制或登录限制导致的空内容页、JS 渲染失败后只剩骨架的页面，以及 CMS 默认生成的空白分类页。
先判断这个 URL 应该是什么状态
处理软 404 的第一步不是改代码，而是先分类。不同性质的 URL，正确状态并不一样。
- 内容永久移除：适合返回 404 或 410。410 表达更明确，但 404 同样能被识别，不必为了追求 410 而大动模板。
- 内容迁移到新地址：用 301 指向新 URL，并确保新旧页面主题一致，不要跳到首页或栏目页。
- 暂时不可用：如果只是短期维护，返回 503 并带上重试时间，比返回 200 的错误页更合适。
- 页面本身应该正常：那问题不在状态码，而在内容渲染或数据缺失，需要修复页面本身。
识别软 404 的几个入口
不想靠猜，可以从几个地方交叉核对：
- 抓取日志里返回 200、但响应体长度明显偏短的 URL。
- 搜索后台的软 404 报告，以及已编入索引但内容为空的页面样本。
- 站内搜索、筛选参数、排序参数生成的结果页，尤其是无结果时仍返回 200 的页面。
- 下架内容的列表页和详情页，检查它们是否还保留着可索引的标题与正文。
把这些 URL 按模板归类，比逐个处理更高效。同一模板的问题，通常一次调整就能覆盖一批页面。
处理顺序：先收内链，再改状态码
顺序弄反是常见问题。如果先改状态码，站内却还有大量链接指向这些 URL，抓取程序会反复回访，索引移除也会被拖慢。比较稳妥的顺序是：
- 先从站点地图中移除这些 URL，避免继续主动提交。
- 清理站内链接：导航、侧栏、相关推荐、列表页里的入口，能去掉的去掉，能指向替代页面的改为 301。
- 确认页面确实没有保留价值后，再把返回状态改为 404 或 410。
- 保留一段时间的日志观察，确认回访频次下降、状态码稳定。
- 如果页面已经进入索引，等待搜索引擎自然刷新；不要频繁在 noindex 与 404 之间来回切换。
两件容易弄反的事
一是把 noindex 和 404 叠加使用。页面既然要返回 404，就不需要再挂 noindex；反过来，如果页面还要保留给用户访问，只想让它退出索引，那就用 noindex，而不是返回错误状态码。两种信号混在一起，会让抓取程序难以判断。
二是把 404 当成万能清理工具。有些页面只是内容暂时缺失，或者渲染依赖接口返回数据，直接改成 404 会把本可以恢复的页面一起清掉。先确认页面的真实意图，再决定状态码。
状态码是给抓取程序的第一层说明。页面想表达什么，最好和状态码保持一致；不一致时，搜索引擎只能按自己的规则去猜。
处理后的核对
调整完成后，可以定期抽查：抓取日志中这些 URL 的返回码是否稳定、站内是否还有指向它们的链接、站点地图是否已经清理干净、搜索后台的软 404 数量是否在缓慢下降。收录状态的变化通常有延迟，短时间内反复修改反而会延长观察周期。
软 404 本身不是特别严重的问题，但它会持续占用抓取资源，也会让索引里混入没有实际内容的页面。把它当成一次常规的 URL 清理工作来做，按模板归类、按顺序推进，比零散修补更省力。