很多人排查收录问题时只盯状态码，看到页面返回 200 就认为“服务器没问题”。但搜索引擎判断一个 URL 能不能留在索引里，不只看状态码，还要看这个页面到底有没有内容。返回 200、内容却是空壳的页面，通常被称为软 404。
软 404 和真 404 的区别
真 404 是服务器明确告诉抓取程序：这个地址已经不存在。抓取程序收到信号后会较快地把 URL 从索引中移除，也不会反复浪费抓取预算。
软 404 则相反：状态码是 200，页面也能打开，但正文几乎是空的，或者只剩模板、导航、推荐位和一句“暂无数据”。抓取程序需要额外判断内容是否有价值，处理周期更长，而且这类 URL 往往会被反复抓取，长期占用抓取预算。
判断标准不是“页面能不能打开”，而是“用户带着明确需求进来，能不能得到答案”。
常见的软 404 场景
- 商品或内容下架后，页面保留 200，仅显示“该商品已下架”加推荐列表；
- 筛选、排序参数组合出大量没有结果的结果页；
- 栏目页内容为空，只靠模板撑起一屏；
- 站内搜索、用户主页、标签页在数据不足时仍返回 200；
- 分页超出实际范围，返回空白页而不是 404；
- 接口报错被前端兜底成“暂无内容”，但 HTTP 状态仍是 200。
自查顺序：从日志到页面
- 先看抓取日志。统计哪些 URL 被抓得最多，如果大量抓取集中在无结果页、空列表页上，问题基本坐实。
- 再看索引状态。在搜索控制台里筛出“已编入索引”但实际无内容的 URL，观察它们的索引量变化。
- 抽样打开页面。关掉缓存、用无痕窗口，确认正文区域是真有内容，还是模板占位。
- 对比正文占比。正文文字远少于导航、推荐、广告部分时，即使技术上不是空页，也容易被视为低质量。
- 核对状态码与实际内容是否一致。很多站点前端做了统一错误页，后端统一返回 200，这就是典型的信号错位。
几个容易误判的地方
一是把“内容少”直接等同于软 404。短页面只要满足搜索意图，仍然可以正常收录。二是把“页面变慢”当成软 404，那是抓取性能问题，处理方式不同。三是只处理前端，忽略后端返回码，改完看起来正常，抓取程序看到的仍然是 200。
处理方式与收敛策略
- 内容确实下架且不会恢复：返回 410 或 301 到最相关的替代页面，不要留着 200；
- 参数组合出的空结果页：用 robots.txt 或 noindex 收敛，同时在页面里给出合理的默认结果；
- 搜索、用户中心等内部页面：默认不放开收录，避免消耗抓取预算；
- 分页超范围：直接返回 404，不要渲染空页；
- 栏目长期没有内容：先补齐内容，或者暂时合并到上级栏目。
需要提醒的是，处理之后索引不会立刻变化。抓取、重新评估、移除是分阶段进行的，通常要以周为单位观察，而不是改完第二天就下结论。
把软 404 当成一次结构体检
软 404 集中出现的位置，往往就是站内 URL 最容易失控的地方：参数、分页、筛选、用户生成内容。与其逐个修补，不如顺手把这几类 URL 的生成规则梳理一遍，能提前避免一大半后续的收录问题。