HTML中<nav><ol>面包屑本身不提升SEO权重或触发富片段，仅服务可访问性和样式；真正影响搜索展示的是严格符合规范的JSON-LD BreadcrumbList结构化数据，需服务端固化、与HTML完全同步，否则富片段失效。
HTML结构层面的<nav><ol>面包屑本身不提升搜索引擎权重，也不触发富片段——它只服务可访问性和CSS样式，对Google索引和排名无直接增益。
为什么<nav aria-label="Breadcrumb"><ol>对SEO无效
Google不解析DOM层级推断“首页 → 分类 → 文章”这种语义。即使你写得再规范：<nav aria-label="Breadcrumb"><ol><li><a href="/">首页</a></li><li><a href="/blog/">博客</a></li><li aria-current="page">如何写JSON-LD</li></ol></nav>，爬虫看到的只是普通导航区块，不会提取路径关系。
-
aria-label="Breadcrumb"必须写，否则屏幕阅读器可能朗读为“导航”，而非“面包屑” -
aria-current="page"不能省，否则辅助技术无法识别当前页，语义断裂 - 分隔符（如
>）必须用<span>包裹，否则会被朗读出来，干扰体验 - 把面包屑塞进
<div>或<p>里，连可访问性都丢失，更别说SEO
BreadcrumbList JSON-LD 才是唯一被Google认可的结构化信号
只有严格符合Schema.org规范的BreadcrumbList才能让搜索结果出现富片段（例如“example.com › Blog › 如何写JSON-LD”）。漏掉任意一条硬约束，标记就失效：
-
@context必须是"https://schema.org"（注意是https，不是http，也不是拼错成schmea） -
@type必须是"BreadcrumbList"（大小写敏感；"breadcrumblist"或"Breadcrumb"都无效） -
itemListElement必须是数组，每个元素含@type: "ListItem"、position（从1开始的连续整数）、name和item -
item字段必须是对象，至少含@id（推荐绝对URL）或name；只写字符串如"https://example.com/blog"会校验失败 -
position值必须是数字类型（不是字符串"1"），且不能跳号（1,2,4不行）
服务端注入 vs 客户端JS动态生成：爬虫根本看不到后者
React/Vue里用useEffect或mounted往<head>里插<script type="application/ld+json">？那对SEO等于没写。Googlebot几乎不执行JS，首屏源码里是空的，就抓不到任何结构化数据。
立即学习“前端免费学习笔记（深入）”；
- 真正可靠的方式只有两种：服务端直出（如Node.js/Koa在响应前写入）或构建时固化（如Next.js SSG、Hugo根据路由预生成）
- 用
location.pathname在浏览器里解析路径再拼JSON-LD？SSR页面首屏无数据，爬虫看到的是占位符或空<script> -
<script type="application/ld+json">必须写全，漏掉type属性、或写成text/json、application/，整个标记就白写
HTML面包屑与JSON-LD不同步，等于主动误导搜索引擎
两者文本不一致，轻则富片段不展示，重则影响该页在结构化数据维度的可信度。常见翻车点：
- HTML显示
首页 > 数码 > 耳机，JSON-LD却写首页 > 电子产品 > 无线耳机——大小写、标点、空格全要一致 - 把URL段
electronics/headphones/wh-1000xm5直接当name用？用户语言应是"WH-1000XM5 降噪耳机"，需查表映射 - 过滤查询参数（如
?color=red）后没同步校验<link rel="canonical">，带参URL可能被当重复页，连带面包屑标记失效
真正起作用的不是“写了结构化数据”，而是URL路径、HTML层级、JSON-LD三者构成的闭环是否稳定且可验证。其中任意一环在不同设备、不同渲染时机、不同抓取环境下表现不一致，增益就会打折扣甚至反向干扰。
