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 頁面不需要花哨，它只需要三件事：狀態碼说真话、文案说人话、頁面给出口。定期花十分钟翻一翻日誌，通常比急着改十篇舊文章更能解决實际問题。