面包屑导航必须严格匹配真实URL路径且用nav+ol语义化结构：每级href需返回200，当前页用aria-current="page"，分隔符用CSS伪元素实现，静态页中禁止JS动态生成。
面包屑导航必须严格匹配真实URL路径
面包屑不是装饰，它直接绑定网站的物理路径结构。如果 href 指向的地址 404、跳转错页、或用了伪路径（比如 /products/iphone 实际却渲染在 /category/mobile/iphone.html），用户点击就断链，搜索引擎也会判定结构混乱。
常见错误现象：
- 用 JavaScript 拼接出“看起来对”的路径，但没验证对应页面是否真实存在
- 静态页中硬编码了
/blog/2024/01/post.html，但实际部署后路径是/posts/2024-01-01-post/ - 面包屑里写了“首页 > 博客 > 技术”，但“博客”链接指向的是
/blog/，而该路径返回 404 或重定向到/articles/
实操建议：
- 每级
<a href="...">必须能被 curl 或浏览器直接访问且返回 200 - 构建脚本（如 Hugo、Jekyll 的 layout）中生成面包屑时，优先读取页面 front matter 中定义的
breadcrumb_path字段，而非靠目录名自动推导 - 上线前跑一次简单检查：提取所有面包屑中的
href，批量发起 HEAD 请求，过滤非 200 响应
nav + ol 是唯一推荐的语义化写法
用 <div class="breadcrumb"> 或 <ul> 写面包屑，等于放弃可访问性和 SEO 基础支持。屏幕阅读器不会识别它是导航，Google 也可能忽略层级关系。
立即学习“前端免费学习笔记（深入）”；
正确结构必须是：
<nav aria-label="Breadcrumb">
<ol>
<li><a href="/">首页</a></li>
<li><a href="/products/">产品</a></li>
<li><span aria-current="page">iPhone</span></li>
</ol>
</nav>
关键点：
-
<nav>提供导航上下文，aria-label不可省略 -
<ol>表达明确顺序，不能换成<ul>或<div> - 当前页节点必须用
<span>（无href），并带aria-current="page"属性 - 每个
<li>只含一个链接或 span，不嵌套其他标签
CSS 分隔符别用 HTML 字符硬写
写成 <li><a>首页</a></li><li>></li><li><a>产品</a></li> 看似省事，但带来三个问题：分隔符无法独立控制样式、响应式缩放失效、无障碍阅读器会把 “>” 当作可读内容播报。
应该用 CSS 伪元素控制：
nav[aria-label="Breadcrumb"] ol li:not(:last-child)::after {
content: " > ";
margin: 0 0.5em;
}
nav[aria-label="Breadcrumb"] ol li:last-child::after {
content: "";
}
这样做的好处：
- 分隔符不参与 DOM 结构，不影响语义和读屏逻辑
- 可通过
font-size统一缩放，适配移动端 - 禁用或替换分隔符只需改 CSS，不用动 HTML
- 支持 RTL（从右向左）语言时，
::after可配合direction自动翻转
静态页面包屑没有“动态推导”这回事
所谓“根据 URL 自动解析面包屑”，在纯静态 HTML 部署场景下是危险幻觉。浏览器拿到的只是最终 HTML 文件，它既不知道路由规则，也不理解你用的框架约定（比如 Next.js 的 app/ 目录结构）。
真实限制就一条：面包屑内容必须由构建时确定，且与输出文件路径一一对应。
所以：
- 不要在静态页里塞
<script>location.pathname.split("/").map(...)</script>—— 它可能生成错误层级，且对 SEO 无效 - 如果你用 Vite + Markdown，就在每个
.md文件 front matter 里手动写：breadcrumb: [{text: "首页", href: "/"}, {text: "文档", href: "/docs/"}] - 生成的 HTML 中，
<nav>块必须是静态字符串，不能依赖客户端 JS 渲染
最易被忽略的一点：很多人以为“只要链接能点开就行”，但忘了搜索引擎抓取的是初始 HTML，它只信任构建时写死的 <nav><ol> 结构。JS 后续注入的面包屑，Google 不认，屏幕阅读器也读不到。
