HTML结构层面的<nav><ol>面包屑本身不提升SEO权重，也不触发富片段，仅服务可访问性和样式；真正起作用的是服务端固化、严格符合Schema.org规范的JSON-LD BreadcrumbList标记，需满足@context为"https://schema.org"、@type为"BreadcrumbList"、position从1连续递增、@id为绝对URL、name与HTML文本完全一致且三者严格同步。
HTML结构层面的 <nav><ol> 面包屑本身不提升搜索引擎权重，也不触发富片段——它只服务可访问性和样式。
为什么 <nav aria-label="Breadcrumb"><ol> 对 SEO 无效
Google 不解析 DOM 层级来推断“首页 → 分类 → 文章”这种语义。即使你写得再规范：<nav aria-label="Breadcrumb"><ol><li>首页</li><li>博客</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/，整个标记就作废
动态生成时最容易崩的三个点
电商、文档站这类多级路径站点，硬编码 JSON-LD 不现实，但动态注入极易出错：
- 把 URL 段（如
electronics/headphones/wh-1000xm5）直接当name用？wh-1000xm5不是用户语言，应查表转为“WH-1000XM5 降噪耳机” - 过滤查询参数后没校验
<link rel="canonical">？带?color=red的 URL 若没设 canonical，可能被当重复页，连带面包屑标记失效 - HTML 面包屑和服务端 JSON-LD 不同步：比如 HTML 显示“首页 > 数码 > 耳机”，而 JSON-LD 里写成“首页 > 电子产品 > 无线耳机”，Google 会认为信号矛盾，富片段大概率不展示
真正起作用的不是“写了结构化数据”，而是 URL 路径、HTML 层级、JSON-LD 三者构成的闭环是否稳定且可验证。其中任意一环在不同设备、不同渲染时机、不同抓取环境下表现不一致，增益就会打折扣甚至反向干扰。
