必须让服务器真实返回404状态码，否则自定义页面只是“好看摆设”；需用curl -I验证响应头为HTTP/2 404而非200，GitHub Pages要求404.html在根目录，Vercel需errorPages配置或staticPageGeneration启用，且页面中禁用自动跳转、确保title和h1含“404”。
必须让服务器真实返回 404 状态码，否则自定义页面只是个“好看摆设”——搜索引擎当它是个正常页面收录，用户刷新也看不到你写的提示。
怎么确认服务器真返回了 404 状态码
很多静态托管平台（GitHub Pages、Vercel、Netlify）默认把 404.html 当普通页面返回 200，这是最常被忽略的底层错误。
- 用
curl -I https://yoursite.com/xxx检查响应头，必须看到HTTP/2 404，而不是HTTP/2 200 - GitHub Pages：文件名必须是
404.html，且放在仓库根目录；/a/404.html不生效 - Vercel：不能靠
rewrites实现，得用errorPages配置，或确保构建时生成了404.html并启用staticPageGeneration - 本地开发时，
file://协议下永远拿不到真实状态码，必须走 HTTP 服务测试（如npx serve）
404.html 里不能写的三件事
很多页面看着像 404，实则破坏 SEO 和用户体验，因为它们悄悄改了 HTTP 状态或行为逻辑。
- 别用
自动跳首页——这会让状态码变成200，Google 会认为那个失效链接内容已迁移到首页 - 别在 JS 里写
window.location.href = '/'且不加用户交互——对禁用 JS 的用户或爬虫无效，且干扰状态码判断 - 别把
必须明确含 “404” 或 “Not Found”，否则屏幕阅读器和搜索引擎无法识别这是错误页
用户真正需要的导航，不是越多越好
用户点进 404 页面时，平均停留时间不到 8 秒。堆按钮、列栏目、塞搜索框，反而增加决策负担。
- 第一层：明确显示当前请求路径（从
location.pathname读取），加粗或高亮，帮助核对拼写 - 第二层：提供 3–4 个真实存在的高频链接，比如
/posts、/products、/help，全部用绝对路径，不用./或../ - 第三层：站内搜索表单，
，action 必须指向后端已实现的/search路由，别调 Algolia 或 Google Custom Search - 所有链接加
rel="noreferrer"，防止 Referer 泄漏；禁止用meta或 JS 自动跳转
服务端要记录原始请求信息
再友好的页面，如果服务端日志里没存 Referer 和完整 path，就无法区分是内部链接写错、还是爬虫扫废链。
- NGINX 日志格式中确保包含
$request_uri和$http_referer - Apache 的
CustomLog同理，别只记%r（请求行），漏掉来源 - 如果用了 CDN，需确认它是否透传原始
Referer；部分 CDN 默认清空，得手动配置
最易被忽略的其实是“真实状态码验证”和“JS 渲染依赖”——前者让所有优化归零，后者让页面在离线、禁用 JS 或首屏加载失败时直接变空白页。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
