有些页面在浏览器里打开会看到“内容不存在”“没有找到相关结果”“该商品已下架”，但服务器返回的状态码是 200。对搜索引擎来说，这看起来就是一个正常可访问的页面，于是被当成有效内容收录进索引。这类页面通常被叫做软 404（soft 404）。它和真正的 404 不同：真 404 明确告诉爬虫“这里没有东西”，软 404 则是在说“有东西”却又没什么内容，判断权被交回给了搜索引擎。
软 404 常见的几种来源
- 站内搜索无结果页：用户搜到空结果，页面返回 200，正文里只有一句“没有找到”。
- 商品或内容下架后保留的旧 URL：正文被清空，替换成“已下架”提示。
- 筛选组合无结果：多条件筛选后结果为零，URL 仍可正常访问。
- 错误处理的降级逻辑：程序出错时返回 200，同时把首页或通用模板内容吐出来。
- URL 拼接错误：参数缺失导致模板渲染出空白区块，但页面本身照常返回。
这类页面数量不大时不容易被注意，但一旦和参数组合、筛选条件、历史下架数据叠加，就可能出现成千上万个，把索引占满，也稀释了站内真正有价值的页面。
先分清三种页面，再决定怎么处理
确实不存在的页面
内容永久移除、且没有替代版本，应该返回 410 或 404，而不是用 200 加一句提示。让爬虫拿到明确信号，比让它反复抓取一个空壳更省事。
功能性的空状态页
站内搜索结果为空时，页面本身是功能的一部分，用户仍需要搜索框去改条件。可以考虑保留可访问性，但不要让这种 URL 大批量进入索引，常见做法是加 noindex，或对空结果状态做规范化处理。
降级返回的通用页
服务异常时返回首页内容是最容易出问题的一类：多个不同 URL 返回同一份正文，既像软 404，又像重复内容。这种情况更应该修服务端逻辑，而不是在收录层面打补丁。
一次可执行的排查路径
- 抽样：从索引报表、站点地图或抓取日志里挑出一批正文极短、标题重复的 URL，覆盖不同目录和参数类型。
- 查看原始响应：用固定 UA 请求这些 URL，记录状态码、响应体大小、正文字数，注意区分原始 HTML 与渲染后的 DOM。
- 比对渲染结果：如果页面依赖 JS 渲染，用抓取工具查看渲染后的内容，确认“空”是真的空，还是内容没被渲染出来。
- 查抓取记录：看这些 URL 是否被反复抓取、返回状态是否稳定，判断是偶发情况还是长期存在。
- 给出归属：逐个判定是应该返回 410、加 noindex，还是补齐内容。判定要留记录，避免下次重复排查。
处理时容易踩的几个坑
- 用 robots.txt 屏蔽整段目录来“解决”软 404。屏蔽只是阻止抓取，已收录的 URL 不会因此消失，还可能因为无法重新抓取而长期停留在索引里。
- 把有真实价值的空状态页一并屏蔽。比如某类目页在淡季本来就没内容，但旺季会恢复，简单屏蔽会误伤。
- 为了通过“有内容”的检查，在空页面上堆砌无关文字。这类内容既帮不到用户，也容易被判定为低质。
- 只改前端展示，不改状态码。前端显示“未找到”但服务端仍返回 200，问题依旧。
状态码是给机器看的第一手信号，页面内容才是最终判断依据。两者不一致时，被误解的概率会明显上升。
改动之后如何确认收敛
上线后不要期待第二天就见变化。先看服务端日志里这些 URL 的返回状态是否已经稳定，再观察索引报表中“已排除”类别的数量变化。可以挑几个代表 URL 单独跟踪，确认它们从“已收录”转为“未找到”或“已排除”的时间。如果几周后仍有大批软 404 停留在索引里，多半是内链或站点地图还在持续指向它们，需要回头检查入口，而不是继续等。
最后，把软 404 检查做成常规动作：每次新增内容模板、调整筛选逻辑、上线新功能时，顺手看一眼无结果状态返回的是什么。这类问题发现得越早，处理成本越低。