404 页面常被当成一个随便放放的兜底页：模板沿用建站程序自带的那一版，写一句“页面不存在”，加个返回首页的按钮，就算完事。但它在站点运营里的位置比想象中重要——它是访客走错路时看到的最后一屏，也是搜索引擎爬到失效 URL 时拿到的唯一反馈。
更麻烦的是，不少站点的 404 页面其实并不“404”：它返回 200，或者 302 跳到首页，看上去用户没受影响，但对方拿到的是错误信号。这篇按自查思路，把 404 页面从状态码到内容文案过一遍。
先分清三种情况
- 真正的 404：地址确实不存在，或者早已删除且没有替代页面。
- 应该跳转的旧地址：栏目迁移、文章换 URL，有明确对应新地址时用 301。
- 服务端错误：数据库连不上、接口超时等，属于 5xx，不是 404，别用自定义错误页把它盖过去。
这三种情况混在一起，后面所有排查都会变得困难。
状态码自查：长得像 404 不等于返回 404
- 用 curl -I 或浏览器开发者工具的 Network 面板看响应头，确认返回的是 404，而不是 200 或 302。
- 别把不存在的地址统一跳到首页。用户会以为网址还有效，搜索引擎也容易把它当成软 404 处理。
- 自定义错误页要由服务器正确返回 404 状态码，页面里引用的图片、样式表失效时同样应返回 404，而不是 200。
- 整站下线或栏目整体迁移，用 301 指向最接近的新页面，不要全部指到首页。
内容自查：这个页面该给访客什么
- 一句人话说明白：地址可能输错、内容已删除或已移动。
- 给出口：搜索框、主导航、几个高频栏目入口，让人有下一步可走。
- 保持和站内一致的头部与视觉风格，别跳到一个空白的默认错误页。
- 移动端字号和可点区域要够用，别让返回按钮小到点不中。
404 页的目标不是强行留住访客，而是让他在三秒内知道发生了什么、接下来能去哪。
记录自查：404 日志是一份现成的诊断报告
- 每周导出服务器 404 日志，按 URL 出现次数排序。
- 区分来源：站内链写错、外部链接失效、改版遗留、爬虫试探的地址。
- 对出现频率高、且有明确新地址的 URL，补上 301。
- 对本来就不该存在的地址（后台路径、临时文件），让它安静地返回 404 即可，同时确认不会拖慢服务器。
- 站内文章里引用错的链接，直接改正比加跳转更干净。
常见误区
- 为了“用户体验”把所有 404 都跳首页，等于把问题藏起来，日志里也看不出痕迹。
- 在 404 页堆大量推荐内容，如果状态码还是 200，容易被当成正常内容页处理。
- 用 robots.txt 屏蔽 404 页，没有意义，反而让对方看不到真实状态。
- 错误页里塞自动播放视频或大图，网络本来就有问题时体验更差。
上线前的复查清单
- 随机访问几个不存在的地址，确认返回 404。
- 确认错误页在手机小屏下可读、可点、可返回。
- 确认页面没有自动跳转，也没有与错误页冲突的 canonical 或额外 meta 标记。
- 确认站内没有大量链接指向这个错误页本身。
404 页面不需要花哨，它只需要三件事：状态码说真话、文案说人话、页面给出口。定期花十分钟翻一翻日志，通常比急着改十篇旧文章更能解决实际问题。