google只认严格合规的结构化数据标记，不解析dom或js；json-ld breadcrumblist需满足@type为"breadcrumblist"、position从1连续递增、@id为绝对url、name与可见文本逐字一致四大硬性要求。
Google 不会从 HTML 的视觉结构或 DOM 层级里“猜”语义，只认严格合规的结构化数据标记。仅靠 <nav><ol></ol></nav>、<breadcrumbitem></breadcrumbitem> 组件、CSS 类名或 ARIA 属性，无法触发 Rich Snippets（富摘要）展示。
为什么
Googlebot 不解析渲染后的 DOM 来推断面包屑逻辑。你写 <nav aria-label="Breadcrumb"><ol>
<li>首页</li>
<li>数码</li>
<li>耳机</li>
</ol></nav>，对可访问性和样式有效，但对爬虫只是普通列表 —— 缺少明确的 @type、position、@id 等机器可读信号，整个语义链就断了。
JSON-LD BreadcrumbList 的 4 个硬性校验点
Google 只接受完全符合 Schema.org 规范的 BreadcrumbList，漏掉任意一条，标记即失效：
-
@type必须是"BreadcrumbList"（不是"Breadcrumb"、"ItemList"或大小写混写） -
position必须从1开始连续递增（1, 2, 3），不能跳号、不能从0起 -
@id必须是绝对 URL（如"https://example.com/products/"），相对路径"/products/"或锚点"#top"全部被忽略 -
name必须与页面中对应链接的可见文本**逐字一致**（空格、标点、大小写全敏感；"WH-1000XM5"≠"wh-1000xm5"）
服务端注入 vs 客户端 JS 动态拼接
绝大多数爬虫（包括 Googlebot）不执行 JS，所以以下写法等于没写：
useEffect(() => {
const breadcrumb = { "@context": "https://schema.org", "@type": "BreadcrumbList", ... };
const script = document.createElement("script");
script.type = "application/ld+json";
script.textContent = JSON.stringify(breadcrumb);
document.head.appendChild(script);
}, []);
真正有效的只有两种方式：
- 服务端直出：Node.js/Koa/Nuxt 在 HTTP 响应头发出前，就把 JSON-LD 写进
- 构建时固化：Next.js SSG、Hugo 等静态生成器，在构建阶段根据路由路径预计算并注入
动态路径下最常踩的三个语义断裂点
电商、文档站等多级路径场景，容易在自动化生成时破坏语义一致性：
- 把 URL 路径段（如
electronics/headphones/wh-1000xm5）直接当name—— 用户看不懂，必须查数据库或映射表转成自然语言 - 过滤查询参数（如
?color=red&size=m）后，没同步检查<link rel="canonical">—— 若 canonical 指向带参 URL，而 JSON-LD 用无参路径，两者冲突，标记失效 - HTML 面包屑文本（如 “首页 > 数码 > 耳机”）和服务端 JSON-LD 中的
name字段不一致 —— 即使只差一个空格，Google 也会拒绝富摘要
所有这些细节都发生在 HTML 源码层面，且必须在首次响应中完整存在。任何依赖浏览器运行时解析、重写或补全的行为，对 Google 来说都是不可见的。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
