做蜘蛛池和站点运营时，很多人只盯着一件事：入口页有没有被访问、目标 URL 有没有出现在日志里。但还有一种情况更麻烦——链接是通的，状态码是 200，搜索蜘蛛也确实来抓了，可抓到的目标页打开后只有一句“内容不存在”，或者除了一堆模板和推荐位什么都没有。这就是软 404。
它和返回 404 的硬错误不一样，处理起来也更容易被忽略。
软 404 到底是什么
简单说，软 404 指的是：服务器对某个 URL 返回了 200，但页面本身并没有实质内容。搜索蜘蛛第一步看的是状态码，200 意味着“这个 URL 有效、可以继续抓”，第二步才去解析正文。如果正文是空的，蜘蛛拿到的是一个有效 URL 加一份没有价值的页面。
常见的软 404 表现有：
- 页面标题写着“内容已删除”“页面不存在”，正文只有几十个字；
- 需要登录、需要下载 App、需要扫码才能看到真正内容；
- 内容被清空后模板还在，导航、页脚、推荐位照常渲染；
- 成百上千个 URL 返回的是同一段空壳模板，只有标题或参数不同。
硬 404 是明确告诉搜索蜘蛛“这里没有东西”，软 404 是含糊地表示“这里有一个页面，但没什么好看的”。前者会被快速剔除，后者往往被反复抓取。
为什么它对蜘蛛池的影响比硬 404 更大
返回 404 的 URL，搜索蜘蛛抓过一两次之后通常就会降低频率甚至不再访问。而软 404 的状态码是 200，从抓取调度的角度看它仍然是“正常页面”，于是会被排进后续的抓取队列。
结果就是：抓取预算被一批没有内容的 URL 占着，真正需要被发现的 URL 反而排队更久。对靠入口页不断递出新链接的站点来说，这个影响是间接但持续的——不是某天突然掉抓取，而是新 URL 的发现和回访节奏慢慢变慢。
另外，如果一个目录或域名下大面积是这种空壳页，站点整体在抓取侧的印象也会变差。这里不展开效果层面的猜测，只提醒一点：软 404 不会让发现停止，但会让发现变得没有产出。
怎么确认目标 URL 是软 404
- 先看状态码。用 curl -I 或抓包工具确认返回的是 200、301 还是 404。很多“看起来打不开”的页面其实是 200。
- 再看正文长度和结构。把目标页和站内正常页面对比，看正文段落数、字符数、是否存在有效标题层级。
- 查日志。同一个 URL 在一段时间内被抓取多次，但抓取结果没有任何变化，值得重点核对。
- 看搜索后台的“已抓取—尚未编入索引”一类报告。如果一批 URL 长期停在这个状态，且人工打开确实没有内容，基本可以判定。
不要只看状态码，也不要只看页面能不能打开。判断软 404 的关键是“状态码 + 内容”两个条件同时看。
入口页层面可以怎么处理
1. 确实没有内容的 URL
该返回 404 或 410 就返回，不要用 200 的提示页兜着。一个明确的错误状态，比一个假装正常的空页面更容易让抓取资源流向别处。
2. 内容存在但没渲染出来
前端单页应用容易出现首屏空白、正文靠 JS 异步加载的情况。搜索蜘蛛拿到的 HTML 里如果没有主体内容，效果和软 404 很接近。可以考虑服务端渲染或预渲染，至少保证首屏 HTML 里有真实正文。
3. 内容重复、被合并的页面
如果若干 URL 指向的是同一份内容，用 canonical 指向主页面，但同时要保证被指向的页面本身有内容，而不是把一堆空壳互相指来指去。
4. 入口页这一侧的习惯
- 入口页只链接到有实际内容的 URL，不要在入口页里塞一批空壳地址凑数量；
- 控制单个入口页的外链总量，把关键链接放在靠前、容易被解析到的位置；
- 定期抽样：从日志里挑出被抓取频次高的目标 URL，人工打开看正文是否完整；
- 把入口页的链接清单和目标页的状态码清单对齐，及时发现已经变成空壳的地址。
一个容易看走眼的情况：验证页和防护页
有些站点前面有 WAF 或访问验证，搜索蜘蛛请求时可能拿到一个 200 的验证页或提示页。它和软 404 在表现上很像：状态码正常，内容不是真正内容。这类问题要从日志里结合 UA、状态码和响应长度一起看，必要时单独测试不同来源 IP 下的返回结果，不要直接当成页面本身的问题去改模板。
小结
软 404 不会阻止搜索蜘蛛发现 URL，它拦不住抓取，只是让抓取回来的东西没有价值。入口页的职责是把 URL 递出去，目标页的职责是接住它。检查蜘蛛池效果时，除了看“有没有被抓”，也值得花一点时间看“抓到的是什么”。把空壳页整理成明确的 404，或者补上真实内容，通常比继续增加入口页数量更实际。