先明确：返回码正常，不等于页面有效
服务器返回 200，只说明这个 URL 还能正常响应请求，不代表它上面有值得索引的内容。当页面因为数据被删、商品下架、模板报错或前端渲染失败，最终只输出一个空壳时，搜索引擎看到的仍然是一个可访问的页面。这类页面通常被称为软 404。
它比真正的 404 更麻烦的地方在于：404 是一个明确信号，蜘蛛会逐步把该地址从索引和抓取队列里淡出；而软 404 每天都会被当成正常页面抓一遍，占着抓取配额，却不贡献任何有效内容。数量一多，站点整体的抓取效率会被稀释，质量判断也会受影响。
常见的几种软 404 形态
- 详情页数据被删除或下架，页面仍保留页头、页脚和推荐位，正文区域为空或只剩一句提示语。
- 筛选、排序、分页参数超出了实际结果范围，返回一个没有任何条目的空列表页。
- 模板变量取值为空导致渲染异常，比如标题、正文全是占位符或报错文本。
- 正文依赖 JS 异步加载，接口出错或超时，浏览器里只剩骨架屏或空白区，原始响应里同样没有正文。
- 站点改版或迁移后，旧的动态地址没有做 301，直接输出了一个空模板。
这些情况表面上各不相同，共同点是：状态码是 200，正文里没有真正可索引的内容。
核对顺序：从响应到索引状态
- 先看状态码和响应体。用抓取工具请求一次，确认返回的是 200，再查看原始 HTML 里正文区域是否为空。只看浏览器渲染后的效果容易被误导。
- 对比同类正常页面。把出问题的 URL 和同栏目下正常收录的页面放在一起，对比响应内容、模板结构、数据来源，判断是数据缺失还是模板问题。
- 确认内容是不是后来才加载。如果正文由 JS 注入，检查接口是否报错、是否被 robots.txt 拦掉、是否需要登录态。这类问题在原始响应里表现为空，但页面本身的设计是有内容的。
- 查看索引报告里的标记。索引覆盖率报告中，已抓取但尚未编入索引之类的项目里，经常会混着这类页面。把它们的数量、URL 规律同站点结构对照，能判断是零星问题还是批量问题。
- 判断这个 URL 该不该继续存在。这是决定处理方式的关键：内容应该存在，就去修数据或模板；内容确实没有了，就不要再用 200 硬撑。
该修的修，该撤的撤
页面应当存在
- 数据被误删或状态异常：恢复数据、修正状态字段，让页面重新输出正文。
- 模板报错：排查变量为空、接口超时、缓存脏数据等具体原因。
- 前端渲染失败：修接口，把关键内容放到服务端渲染或预渲染，保证原始响应里能拿到正文。
- 空结果页：只对确实有结果的参数组合开放抓取，无结果的组合不生成站内链接，或统一做规范化处理。
页面确实不该存在
- 内容已被永久删除且无替代页：返回 410 或 404，比用 200 输出空壳更清晰。
- 有替代页面：用 301 指向最接近的有效页面，不要把所有下架页都笼统指向首页。
- 页面仍需保留给用户，但不适合索引：确认没有其它收录入口后，再评估是否加 noindex。注意 noindex 只是不索引，页面仍会被抓取。
容易混淆的两种情况
一种是内容单薄。页面有正文，只是信息量少、和别处高度重复，它不算软 404，处理思路是补内容或做合并，而不是简单删掉。
另一种是抓取异常。服务器超时、限流、返回 5xx 时，蜘蛛拿到的是错误页；如果错误页本身也返回 200，就同时叠加了软 404 的问题。核对时要先把服务端稳定性排除掉，再谈内容层面。
软 404 的关键不是页面打不开，而是打开之后没有东西。先确认状态码与正文是否匹配，再决定修复还是下线，比反复提交站点地图更有用。