蜘蛛抓走一个 URL 之后，站点回头看日志，最容易只关注状态码：200 就放过去，404 才去处理。但实际运营中更麻烦的一类情况是——HTTP 状态明明写着 200，页面却什么都没给。这就是常说的软 404，也是抓取效率被悄悄吃掉的主要来源之一。
什么是软 404
软 404 指的是：服务器返回 200，但页面主体没有与这个 URL 预期相符的内容。用户打开看到的是空列表、空白正文区、只剩导航和页脚的模板页，或者一句“暂无数据”。从协议上看它是正常页面，从内容上看它其实是死页面。
对蜘蛛来说，这个信号是矛盾的：状态码说“这页有效，欢迎再来”，实际内容却说“这里没东西”。蜘蛛只能按前者处理，于是下次可能还会来，你就多花了一次抓取机会。
常见的软 404 来源
- 筛选、排序、分页参数组合出来的空结果列表页
- 站内搜索无结果时渲染出来的搜索页
- 商品或文章下架后，只留下模板框架的详情页
- 需要登录才能看到正文的页面，未登录时正文区是空的
- 正文靠前端交互或延迟请求加载，初次响应里没有内容
- 改版或迁移后，旧路径上留下的占位说明页
为什么它比硬 404 更麻烦
硬 404 是明确的：蜘蛛收到之后会逐步降低访问频率，并在一段时间后把 URL 从索引里清理掉，链路是闭合的。软 404 则不闭合，它的状态码一直在邀请蜘蛛回来。
数量少的时候影响有限；一旦站点上堆积了几千个这类 URL——尤其是它们还被内链或 Sitemap 指向——抓取时间就会被大量分给没有内容的页面，真正需要被发现的页面反而排到后面。同时，蜘蛛对站点整体内容质量的判断也可能受到影响。这里不存在一个可以精确量化的阈值，重点是看这些空壳页在抓取记录里的占比。
怎么自查
- 翻服务端日志，筛出返回 200 但响应体明显偏小的 URL，正文区字节数低于正常页面一半以上的优先看。
- 抽样打开这些页面，把 JS 关掉再看一遍，确认正文是不是真的存在于 HTML 里。
- 把 Sitemap 里提交的 URL 和内链指向的 URL 分别列出来，找交集里的空内容模板页。
- 用站内搜索和筛选条件主动生成一批 URL，看它们在空结果时返回什么状态码。
- 观察同一批空壳 URL 在一段时间内是否被反复抓取，反复出现说明信号没有给对。
处理思路
- 确认确实没有内容的页面，直接返回 404；已经确定永久移除的可以用 410，让信号更明确。
- 内容下架但有明确替代页面的，用 301 指向新的地址；没有替代的，不要为了保住旧 URL 而保留一个 200 的空模板。
- 筛选页和搜索页在结果为空时，至少返回 404，或者在页面头部加上 noindex 的 robots meta，避免留下 200 的空白页。
- 需要登录的内容，可以把标题、摘要、发布时间等可见部分正常输出，正文区不要留一个空容器假装有内容。
- 把确认的软 404 从 Sitemap 和内链里清掉，尤其是导航、标签云、相关推荐这些批量输出链接的位置。
- 关键正文尽量在服务端渲染出来，别让首次响应只剩一个空的挂载节点。
软 404 没有统一的判定标准，比较实用的判断方式是：用户和蜘蛛打开这个 URL，能不能拿到与 URL 预期一致的内容。拿不到，就应该给出对应的状态码。
把它排进日常节奏
软 404 不是一次性问题，站点每次上线下架、每次加筛选维度、每次改版模板，都可能新增一批。比较省事的做法是固定一个检查节奏，比如每月看一次日志里的小响应体 URL 列表，改版后一周内重点复查一遍新模板的空状态表现。
这类工作不需要复杂工具，日志加抽样打开就能覆盖大部分情况。真正要花心思的地方在于：确定这页到底该返回 404、410 还是 301，然后把它同步到内链和 Sitemap 里，让蜘蛛收到的信号前后一致。