软 404 是什么，和 404 差在哪
正常的 404 是服务器明确告诉爬虫：这个地址没有对应内容。软 404 则相反——服务器返回 200 OK，URL 可以访问，但页面里没有实际内容，或者内容与“页面不存在”基本无异。对用户来说可能是一片空白，对搜索引擎来说则是一个需要自己判断真假的信号。
这个判断的成本不低。搜索引擎要先抓取、解析、渲染，再比对正文长度、是否与站内其他页面高度相似、是否还有有效链接，最后才决定把它归入废页。整个过程比一个干脆的 404 慢，也更容易出现反复。
为什么这件事值得单独拿出来说
软 404 的直接后果不是“被惩罚”，而是收录判断被拖延。当同一批 URL 里混着大量空壳页时，抓取资源会被分摊，真正的内容页拿到的信号也会变得模糊。站点越大、模板化生成的页面越多，这个问题越明显。
另外，软 404 页面如果还带着完整的导航和页脚，爬虫可能会顺着继续走，把一个本该结束的分支当成有效路径，进一步放大无效抓取。
常见的软 404 来源
- 商品下架、文章删除，模板还在，正文区域被清空
- 筛选、排序、站内搜索在没有结果时仍返回 200 的空列表页
- 分页翻到了没有数据的页码，URL 却依然可以访问
- 需要登录或权限不足，直接返回空白正文而不是提示状态
- 只写了一行“敬请期待”或“内容整理中”的占位页
- 前端渲染出错，返回的是 200，但 HTML 里只剩框架容器
怎么把它们找出来
只看状态码没用，因为软 404 的状态码本来就是 200。更实用的做法是几路并行：
- 看索引覆盖率报告里的软 404 分类，它通常会直接列出被判定为空壳的 URL 样本
- 抽样检查日志里被高频抓取、但正文很短或几乎没有内链的地址
- 用站内搜索或模板关键词（如“暂无内容”“敬请期待”）反查可能的空壳页
- 按模板分组统计正文字数，同一模板里字数明显偏低的那一批，往往就是问题源头
- 对被删除的内容做一次 URL 清点，看下架之后地址是否还在返回 200
处理方式：先分类，再动手
- 内容彻底不用了：让地址返回 410 或 404，而不是继续返回 200 空壳。删除是明确的信号，比让搜索引擎自己猜要干净。
- 内容暂时下线，之后可能恢复：可以返回 404，或者用 noindex 暂时挡住，但不要长期挂着一个空壳页面。等内容回来再放开。
- 页面本身有价值，只是当前数据为空：比如空筛选结果。更好的做法是从源头控制——无结果时不生成可访问的 URL，或给出提示页并设置 noindex。
- 整站模板问题：不要在单个页面上一处处改。找出生成空壳的模板逻辑统一处理，否则今天补完，明天又冒出来一批。
- 需要保留入口的页面：如果 URL 本身有外部链接或用户收藏，可以考虑保留并给出替代内容与跳转，而不是留白。
几个容易踩的坑
- 把软 404 当成 404 批量删除，误伤了调整后本可以恢复的页面。动手前最好留一份 URL 与内容状态的对应记录。
- 只处理了 PC 模板，移动端或独立版本仍返回空壳。
- 依赖 JS 渲染的页面，服务端返回的 HTML 里什么都没有，抓取时看到的就是空白。
- 批量改动上线后不复查，覆盖率报告里的软 404 数量没有下降，说明改的可能不是同一批 URL。
软 404 不会立刻让页面从索引里消失，但它会让搜索引擎对页面价值的判断变得困难。与其等它被归入废页，不如在页面上线或下线的环节，就把状态表达清楚。