404.html必须严格小写并置于根目录，GitHub Pages等平台仅识别该确切文件名；须返回真实HTTP 404状态码，HTML中<h1>必须含“404”字样以满足SEO与可访问性要求。
404.html 文件必须严格命名为小写并放在根目录
GitHub Pages、Vercel、Netlify、Cloudflare Pages 这些平台只识别 404.html 这个确切文件名，且必须位于仓库或项目最顶层。写成 404.htm、error-404.html、/pages/404.html 或 404.HTML 都不会被接管。
常见错误现象：页面内容明明写了“404”，但访问不存在路径时，仍看到平台默认的灰色错误页（比如 GitHub 的 “There isn’t a GitHub Pages site here.”）。
- 用
git ls-files | grep 404确认 Git 已提交该文件（Windows 记事本可能悄悄加 BOM） - Jekyll 用户需在
404.html开头加---\npermalink: /404.html\npublished: false\n---，否则会被当作普通文章渲染 - 检查文件系统是否区分大小写——macOS 默认不区分，但部署到 Linux 服务器后会失效
服务器必须返回真实 HTTP 404 状态码，不能是 200 或 302
页面上写再多“404”也没用，关键看响应头里有没有 Status: 404 Not Found。返回 200 会让搜索引擎持续索引死链，用户刷新也得不到重试提示。
常见错误现象：控制台显示 Failed to load resource: the server responded with a status of 200 OK，但 URL 明显是错的；Google Search Console 把你的 404.html 当作正常页面收录。
立即学习“前端免费学习笔记（深入）”；
- 静态托管：GitHub Pages 自动处理；Netlify 需在
_redirects中写/* /404.html 404；Vercel 要启用errorPages或确保staticPageGeneration开启且404.html存在 - 后端（如 Express）必须显式调用
res.status(404).sendFile()，不能只res.sendFile() - SPA 应用（React/Vue）的
try_files $uri $uri/ /index.html规则会吞掉所有 404，要加条件排除/404.html
HTML 结构必须语义化，<h1> 里得有“404”字样
搜索引擎和屏幕阅读器靠结构识别意图。<h1>404 Not Found</h1> 不是装饰，而是可访问性和 SEO 的硬性要求。用 SVG 文字、CSS 伪元素或 JS 插入“404”，都会让视障用户听不到、爬虫读不到。
常见错误现象：页面看着像 404，但 Google 把它当普通页面索引；用户用读屏软件听到的是“网页标题”，而非“404 页面未找到”。
- 必须用
<main>包裹核心内容，<h1>是唯一且必需的顶级标题 - 主视觉可用
<figure>包裹内联 SVG，避免外部资源请求失败导致空白 - 搜索框用
<form action="/search" method="GET">，不要绑定 JS 监听 submit 事件
引导链接要分层可点击，别依赖 history.back()
“返回上一页”按钮在用户从外站直接进入 404 时会跳到空页甚至报错，纯属无效操作。真正有用的引导必须明确、可点击、不依赖 JS。
第一优先级是展示用户刚访问的路径：location.pathname 读出来，放进 <code> 标签里，帮用户确认是不是拼写错了。
- 第二优先级：3–4 个高频目标链接，如
/（首页）、/blog（最新文章）、/help（帮助中心），地址必须真实存在 - 第三优先级：带
name="q"的搜索框，后端要支持/search?q=xxx；别调第三方搜索 API，离线即失效 - 所有链接加
rel="noreferrer"，首页用绝对路径/，避免相对路径在深层 URL 下失效
最容易被忽略的是服务端日志联动——哪怕页面再友好，如果没记录原始 Referer 和 path，就无法判断是内部链接写错、还是爬虫在扫废弃接口。
