站点跑久了，出现 404 是很正常的事：页面下线、栏目调整、文章合并、外链指向的旧地址失效，都会留下打不开的 URL。真正麻烦的不是 404 本身，而是分不清哪些该修、哪些该留、哪些其实是被伪装成 404 的正常页面。这篇讲的是排查思路，不涉及具体平台的操作细节，重点是让判断有依据。

先分清三种“打不开”

同样表现为“页面不对”，背后的状态码和原因完全不同，处理方式也完全相反：

• 真 404：内容确实不存在，服务器返回 404 状态码，这是符合预期的结果，不需要慌张。
• 软 404：页面没有实际内容（空搜索结果、空分类、已下架条目），但服务器返回 200，对外看起来是一个“正常页面”。
• 假 404：页面其实存在，却因为规则、权限或大小写问题返回了 404，等于把本来能用的地址挡在门外。

软 404 和假 404 都不会在页面上写“我出错了”，只能靠状态码和内容比对发现，这也是它们容易被忽略的原因。

软 404 为什么值得花时间处理

一个空结果页如果长期返回 200，会被当成有效地址反复访问，占用抓取资源，也容易让用户点进去后一无所获。更麻烦的是，这类地址数量往往不少，因为筛选参数、搜索参数、翻页参数可以组合出大量变体。处理它不追求“全部消灭”，而是让空页面不要假装自己是内容页。

自查清单

1. 看状态码，不看页面长相

用命令行或抓取工具批量请求一批 URL，只看返回码。页面长得像模板、带着导航和页脚，并不代表它是有效内容页。

2. 检查空结果与筛选组合

站内搜索、标签筛选、价格区间、排序参数，都是空页面的高发区。挑几组极端条件的组合访问，看返回的是 200 还是 404，页面上有没有提示“没有找到结果”。

3. 检查大小写与尾部斜杠

同一篇文章，/News/123 和 /news/123 是否都能打开？带斜杠和不带斜杠是否都返回 200？如果是，说明同一内容存在多个可访问地址，需要统一到一个正式地址上，其余做跳转。

4. 检查改版遗留地址

栏目改名、目录层级调整之后，旧地址通常还能在外部链接、旧站内地图、历史页面里找到。把它们整理成一张清单，逐个确认是恢复、跳转还是放弃。

5. 检查 404 页面本身

访问一个确定不存在的地址，确认它确实返回 404，而不是 200；页面里有没有返回首页或主要栏目的入口；有没有站内搜索框。一个正常工作的 404 页面，比整站返回空白已经好很多。

失效地址的处理方式怎么选

1. 内容还在，只是换了地址：做 301 跳转到最接近的正式页面，注意跳转目标要和原内容主题相关，不要全站跳首页。
2. 内容已合并：跳到合并后的页面，并确认该页面确实覆盖了原来的主题。
3. 内容彻底不再提供：保留 404，或明确返回 410，不必强行制造跳转。
4. 只是暂时不可用：考虑临时性处理，不要急着做永久跳转，避免后续再改回来。

判断标准很简单：用户顺着链接点进来，看到跳转后的页面会不会觉得“找错地方了”。如果答案是会，那这个跳转不如不做。

404 页面该做成什么样

• 返回正确的 404 状态码，不要用 200 伪装。
• 给出返回首页、主要栏目、最近内容的入口，别只写一句“页面不存在”。
• 提供站内搜索，让用户有机会自己找到目标。
• 不要在 404 页面上自动跳转，用户和抓取都可能来不及看清发生了什么。

记录与观察

把排查结果落到一张简单的表里：地址、发现时间、原因、处理方式、处理日期。过一段时间再看同一批地址是否还会被访问，如果反复出现，说明有页面在不断产生失效链接，需要回头检查内链和模板。站内链接、站点地图、旧版导航，都是失效地址的常见来源。

提示：不必追求站内一个 404 都没有，那既不现实也没有必要。重点是让失效地址可解释、可追踪，不要出现大量看似正常、实则空白的页面。

这类排查不需要一次性做完，按栏目分批处理即可。每处理一批，链接结构就干净一点，用户点开空页面的概率也会低一点。