google不解析dom推断语义，仅认服务端注入、字段严格匹配、内容完全同步的json-ld breadcrumblist：@type必须为"breadcrumblist"，position从1连续递增，@id为绝对url，name与html文本逐字一致，当前页item不可省略。
Google 不从 <nav><ol></ol></nav> 里“看出”面包屑，也不靠 <h1></h1> 标签名决定是否展示 Rich Snippets——它只认服务端注入、字段严格匹配、内容完全同步的结构化数据。
为什么 <nav><ol></ol></nav> 面包屑对 Rich Snippets 完全无效
Googlebot 不解析 DOM 层级推断语义。你写再标准的 <nav aria-label="Breadcrumb"><ol>
<li>首页</li>
<li>数码</li>
</ol></nav>，爬虫看到的只是普通导航块，没有 @type: "BreadcrumbList" 这类明确信号，就不会触发富片段。
- aria-label、CSS 类名、
<ol></ol>的序号都不构成结构化语义 - 屏幕阅读器能读、样式能调，但对 SEO 来说等于没写
- 所有依赖客户端 JS 动态生成的 HTML 面包屑（比如用
useEffect拼<li>），源码里为空，爬虫抓不到
BreadcrumbList JSON-LD 必须满足的硬性条件
哪怕语法合法，漏掉任意一条，整个标记就被 Google 忽略：
-
@type必须是"BreadcrumbList"（不是"Breadcrumb"或自定义字符串） - 每个
itemListElement必须含@type: "ListItem"、position（从 1 开始连续，不能跳或为 0）、item -
item至少要有@id（绝对 URL，如https://example.com/products/，不能是/products/）和name - 当前页必须有
item对象，哪怕没链接——漏掉就语义断裂 -
name字符串与 HTML 中对应文字**逐字一致**（空格、标点、大小写全敏感）
服务端注入 vs 客户端 JS：哪个能被 Google 看到
Googlebot 几乎不执行 JS，动态插入的 <script type="application/ld+json"></script> 在源码里是空的，等于没写。
Google Workspace Automation
下载
设计Gmail、Drive、Sheets和Calendar自动化，使用范围感知的计划。用于可重复的每日任务自动化，具备明确的OAuth范围和审计功能。
- 可靠方式只有两种：服务端直出（Koa/Next.js SSR/Nuxt 在响应头发出前写入
）、构建时固化（Next.js SSG/Hugo 静态生成时预计算注入） - 用
location.pathname在浏览器里解析路径再拼 JSON-LD？SEO 视为不存在 - 验证必须用 Rich Results Test，它模拟 Googlebot 实际处理逻辑，不是语法检查器
动态面包屑最容易翻车的三个点
电商、文档站等多级路径场景下，硬编码不现实，但动态生成极易失效：
- 把 URL 路径段（如
electronics/headphones/wh-1000xm5）直接当name——必须查表映射成用户语言（如"WH-1000XM5 降噪耳机"） - 过滤查询参数（如
?color=red&size=m）后，没同步校验<link rel="canonical">——带参 URL 若无 canonical，可能被判定为重复页面，连带面包屑标记失效 - HTML 面包屑和服务端 JSON-LD 不同步：比如 HTML 显示
"首页 > 数码 > 耳机"，而 JSON-LD 里写成"首页 > 电子产品 > 无线耳机"，只要一个字符不一致，整个标记就挂掉
最常被忽略的是：JSON-LD 和 HTML 文本必须完全一致，且必须服务端输出——这两点卡住绝大多数动态站点的 Rich Snippets 上线。不是写了就能生效，而是写了还必须写对、写准、写在对的地方。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
