有些页面其实已经不再提供内容了，但服务器仍然返回 200。用户点进去看到的是一句“内容不存在”或者一片空白，蜘蛛拿到的也是一个正常状态码。这类页面就是常说的软 404。它比直接返回 404 更隐蔽，也更容易在站点运营里被长期忽略。
软 404 常见的几种表现
- 商品或文章下架后，详情页模板还在，只是正文区域为空，页面头尾导航照常输出。
- 站内搜索无结果时，直接渲染一个空列表页，状态码仍然是 200。
- 参数错误或 ID 不存在时，程序没有报错，而是落到一个默认模板上。
- 栏目被合并后，旧列表页还在，但里面没有任何条目。
- 内容被设为隐藏或草稿状态，前台仍可访问，只是不显示主体信息。
这些页面的共同点是：HTTP 状态码正常，正文有效信息很少，模板痕迹明显。它们看起来像正常页面，实际上没有承担任何内容职责。
为什么它比 404 更难处理
真正的 404 会让蜘蛛快速放弃，也会在日志里留下清晰记录。软 404 不同，蜘蛛看到的是 200，会把它当作正式页面对待，继续抓取、继续排队，甚至可能进入索引。抓取预算被这类页面占用，真正需要更新的内容反而排到后面。对运营来说，日志和监控也会失真：状态码统计看起来正常，但有效页面数量在缩水。
对用户而言，软 404 同样不友好。页面能打开，却找不到想要的信息，用户不确定是内容下架、链接过期，还是站点出了问题。缺少明确提示，往往会直接离开。
排查软 404 的几个入手点
- 抽样检查。从栏目列表、Sitemap、站内搜索里各抽一批 URL，看状态码，也看正文长度和主要区域是否有实质内容。
- 看日志里的“小页面”。状态码 200、响应字节数很小、又被重复抓取的 URL，值得单独拉出来看。
- 搜模板提示词。用站点搜索或数据库检索“暂无内容”“已下架”“未找到”等文案，看哪些模板在输出这些提示，同时返回 200。
- 检查下架流程。内容编辑下架一篇文章或商品时，程序是删除、隐藏还是只清空正文？如果只是隐藏，软 404 就会持续产生。
- 核对栏目调整记录。每次合并、改名、改路径之后，旧地址有没有留下空壳页面。
处理原则：让状态码和页面实际状态一致
- 确定不再提供的内容：返回 404 或 410，并给出简短说明和返回入口。
- 已经迁移到新地址的内容：用 301 指向最相关的新页面，不要统一跳到首页。
- 临时不可用：考虑 503 并设置合理的 Retry-After，不要用 200 假装正常。
- 空列表页：如果没有持续维护计划，返回 404 比保留一个空壳更清晰；如果有价值，就补上说明和替代入口。
- 清理入口：把指向这些页面的内链、Sitemap 条目、导航项一并处理，避免蜘蛛反复发现。
一个常见误区：用前端跳转代替状态码
有些站点在空页面上放一段脚本或 meta refresh，直接跳到首页。用户看到的是首页，蜘蛛拿到的仍然是 200。这既没有传递正确的页面状态，也让跳转关系变得混乱。处理软 404 时，优先让服务端返回对应状态码，而不是靠前端补救。
把状态码规则写进日常流程
软 404 往往不是一次性问题，而是内容下架、栏目调整、模板改动之后留下的尾巴。可以在发布流程里加一条检查：新页面和下线页面分别应该返回什么状态码。技术侧则可以把“200 但正文为空”纳入监控，按周看一次趋势，发现某个模板集中产出空页面时及时处理。
不需要追求一次清理干净。先把访问量较高、被外链引用较多的软 404 处理掉，再逐步覆盖长尾。状态码准确了，日志和抓取数据才有参考价值，后续的栏目规划和内容更新也才有可靠依据。
状态码是页面状态的第一句话。页面已经不在，就让它如实说明。