很多站点在服务器返回 200 的情况下，页面其实是空的：站内搜索没有结果、商品已经下架、分页翻过头、标签下没有任何内容。这类地址在访问日志里和正常页面长得一样，状态码正常、响应体也不算小，但它对搜索蜘蛛来说是一条死胡同。数量积累起来，抓取频次会被大量无效入口分走，真正需要更新的页面反而等不到回访。
软 404 的常见形态
先明确一点：软 404 不是指服务器配错了，而是指页面在业务上已经没有内容，但依然以 200 返回。常见的几种：
- 站内搜索无结果页，URL 带查询参数，仍返回完整模板
- 商品或文章下架后，详情模板保留，正文区域为空
- 分页超出实际范围，如 page=99 返回空列表
- 筛选条件组合没有命中，只渲染出筛选条和一句提示
- 标签、分类未绑定任何内容，只剩标题和一段说明文字
- 活动结束后页面未下线，只留下已过期的文案框架
为什么它在抓取层面是负担
从 URL 发现的角度看，这些地址并不缺曝光：它们大多来自站内搜索框、筛选组件、分页链接和标签云，链接位置还往往比较靠近首页。搜索蜘蛛顺着这些入口抓过去，拿到的是一个没有独特内容、也没有下一跳有效链接的页面。结果有三层损耗：
- 抓取频次被摊薄，同样的配额要分给更多低价值地址
- 内链结构失真，大量空壳地址与正常页面混在一起，路径层级看起来变深了
- 判断依据被污染，做入口梳理时，很难一眼分清哪些地址是真正有内容的
更麻烦的是，很多软 404 是由参数组合生成的，理论上可以无限扩展，一个筛选组件就能产出成百上千个变体。
排查顺序建议
- 先从访问日志抽样。筛出状态码为 200、但响应体长度明显偏小、或大量 URL 正文高度相似的记录。响应体字节数是很好的第一个筛子，比人工点开页面快得多。
- 核对模板与判断逻辑。找到对应的页面模板，看它在数据为空时会走到哪个分支，是否只是渲染了空容器而没有做状态处理。
- 检查边界场景。分页的最后一页往后、筛选的极端组合、已删除对象的历史 URL，这几类要单独测一遍，它们往往是软 404 的主要来源。
- 区分服务端与前端渲染。有些页面服务端返回的是空壳，内容靠脚本补；如果脚本拿不到数据，最终呈现就是空白。这类需要从原始 HTML 层面确认，而不是看浏览器截图。
- 确认规范化与索引指令。同一个空状态页如果还带着 self canonical，等于在向搜索引擎确认这就是正式版本，处理时要一并调整。
处理策略怎么选
处理方式取决于这个地址未来还会不会有内容：
- 确定不再有内容：直接返回 404，必要时用 410。比返回 200 空页更清晰。
- 暂时无内容但会恢复：可以返回 404 或保留页面但收敛入口，不建议长期挂着空页。
- 参数组合生成的空页：从源头收敛，比如限制筛选组合的可抓取范围，或对无结果状态不输出可抓链接。
- 确实有少量内容但重复度高：优先考虑合并到上一级页面，而不是保留独立地址。
用 noindex 处理软 404 是一种折中，但它并不等于问题消失：地址仍然会被发现、被抓取，只是不再进入索引。如果目标是减少无效抓取，404 通常比 noindex 更直接。
处理后的观察方式
改完之后不要只看一次日志。可以按周对比三件事：同一路径下的 200 响应数量是否下降、404 数量是否相应上升、以及有内容的页面回访间隔有没有缩短。同时检查 Sitemap 和内链中是否还残留这些地址——如果入口还在，抓取请求就不会停。
另外可以留意服务器错误率的变化。把空状态页改成 404 之后，如果 404 占比短期明显上升，属于预期内现象，重点是确认它不是由新的路径规则错误引起的。