结构化标记本身不直接提升排名，但缺失BreadcrumbList会导致面包屑无法以富片段展示，而富片段能显著提高点击率；Google依赖JSON-LD中严格符合规范的BreadcrumbList（@type必须为"BreadcrumbList"、position从1递增、@id为绝对URL、name与HTML文本完全一致、当前页item不可省略）来识别层级关系，且须服务端固化、与HTML面包屑严格同步，否则影响可信度或导致富片段失效。
结构化标记本身不直接提升排名，但没它，面包屑在搜索结果里大概率不会以富片段形式出现；而富片段能显著提高点击率——这是真实可测的增益点。
为什么只写<nav><ol>对SEO几乎没用
搜索引擎（尤其是 Google）不靠 DOM 结构推断层级，它依赖明确的语义信号。纯 HTML 面包屑只是视觉和可访问性组件，爬虫不会从中提取“首页 → 分类 → 详情”这样的逻辑关系。
-
BreadcrumbList是唯一被广泛支持的、专用于面包屑的 Schema 类型，必须用 JSON-LD 注入<head>或页面顶部 - 漏掉
@type: "BreadcrumbList"，或把@type写成"Breadcrumb"（少个 List），整个标记就失效 - 如果页面是 SSR 渲染但 JSON-LD 是客户端 JS 动态插入的，多数爬虫会跳过——必须服务端吐出或构建时固化
BreadcrumbList 必须和 HTML 面包屑严格同步
两者字段不一致，等于主动告诉搜索引擎：“我前后矛盾”。轻则富片段不展示，重则影响该页在结构化数据维度的可信度。
-
position必须从1开始递增，不能是0起始或跳号（如1,2,4） -
@id必须是绝对 URL（含https://和域名），写/products/或#top会被忽略 -
name要和 HTML 中对应<li>的文本完全一致（包括空格、标点），大小写敏感 - 当前页的
item字段不能省：即使不加链接，也要有@id和name，否则末尾项语义断裂
动态生成时最容易错的三件事
电商、文档站等多级路径场景下，硬编码 JSON-LD 不现实，但动态生成极易踩坑。
立即学习“前端免费学习笔记（深入）”；
- 用
location.pathname解析路径再映射名称？——客户端 JS 做这事，SSR 页面首屏无数据，爬虫看到空标记 - 把 URL 段（如
electronics/headphones/wh-1000xm5）直接当名称用？——wh-1000xm5不是用户语言，应查表转为“WH-1000XM5 降噪耳机” - 过滤查询参数（
?color=red&size=m）后没做 canonical 校验？——带参数的 URL 若未设<link rel="canonical">，可能被当成重复页面，连带面包屑标记失效
真正起作用的不是“写了结构化数据”，而是 URL 路径、HTML 层级、JSON-LD 三者构成的闭环是否稳定且可验证。其中任意一环在不同设备、不同渲染时机、不同抓取环境下表现不一致，增益就会打折扣甚至反向干扰。
