404 页面不只是报错页：设计要点和软 404 陷阱
4
404 页面不只是报错页：设计要点和软 404 陷阱
每个站都有 404，但多数人只把它当成一个"报错页面"来对待。实际上这里埋着两个问题：一个是体验问题——用户走进死胡同时你给了他什么；另一个是技术问题——很多站的真实状态根本不是 404，而是更麻烦的"软 404"。
图片来源：网络，版权归原作者所有，侵权请联系删除
什么是软 404：返回 200，却说页面不存在
软 404 指的是：服务器返回 200（成功）状态码，但页面内容明确告诉用户"这个页面不存在"，或者干脆是个空页面。
谷歌从 2010 年就开始在站长工具里报告这类错误，到今天它仍是索引报告里的常见项。最常见的产生来源：
- 站内搜索无结果页。用户搜了一个没结果的词，页面返回 200，正文写着"未找到相关内容"——这是教科书级的软 404。
- CMS 模板变量没取到值。条目被删了，模板还在渲染，标题空着、正文空着，状态码照样 200。
- 数据库或接口异常的兜底页。后端出错时前端展示"页面加载失败"，但 HTTP 状态是 200。
为什么必须修
200 状态码在搜索引擎那里的含义是"这是个正常页面，抓吧、索引吧"。于是蜘蛛抓了一个没有内容的页面，占了收录名额，浪费了抓取预算；用户那边看到的则是一个"看起来正常、打开却是错误"的割裂体验。两头的亏都吃了。
软 404 的本质是撒谎：对机器说"我很好"，对用户说"不存在"。
三种修法，对号入座
| 页面真实状态 | 正确处理 |
|---|---|
| 内容真没了，也没有替代 | 返回 404 或 410 状态码，让页面退出索引 |
| 内容搬家了，有明确新地址 | 301 重定向到新 URL |
| 内容其实存在，却被误报 | 用 URL 检查工具看谷歌实际渲染出的内容，排查资源加载和渲染错误 |
404 页面本身的设计要点
404 页面是给用户看的，搜索引擎对它没有内容要求。一个及格的 404 页面需要：
- 说清楚发生了什么。"页面不存在或已被移动"比一串错误代码友好得多。
- 保留全站导航和视觉一致性。用户此刻最需要的是"接着去哪"，别把他扔在一个孤立页面。
- 给替代路径。热门页面入口、站内搜索框、返回首页的链接，三样至少给两样。
- 给报错渠道。留个"报告此问题"的入口，坏链是内容团队最需要的反馈。
最关键的一条：页面做得再漂亮，状态码必须是 404。用 200 返回一个精美设计的 404 页面，等于给搜索引擎递了个软 404——设计越用心，错得越远。
每月五分钟的自查
- 搜索控制台的网页索引报告里看"软 404"条目数，突增通常对应一次模板或数据故障。
- 命令行抽查：对几个确定不存在的 URL 发请求，确认返回的是 404 而不是 200。
- 顺手测站内搜索：随便输个乱码，看无结果页的 HTTP 状态。
404 是站里最不起眼的页面，却是少数能同时暴露"技术底子"和"产品良心"的地方。状态码别撒谎，页面别冷漠，这事就做到位了。