rich snippets 依赖 h1–h6 的语义结构而非标签名，h1 应唯一且与 title、schema headline 主题一致；faq/how-to 要求 h2/h3 严格嵌套，dom 结构与 schema 必须交叉验证一致。
Rich Snippets 会读取 H1-H6 的语义结构，但不直接依赖标签名
Google 的富媒体摘要（Rich Snippets）本身不把 h1 当作“必须字段”，也不会因为用了 h2 就拒接展示。但它依赖页面整体的结构化信号——而 h1–h6 是其中最基础、最稳定的语义锚点。如果标题层级混乱，Schema.org 标记再规范，也可能被降权或忽略。
-
h1文本常被用作 Rich Snippet 中的「主标题」候选，尤其当它与<title></title>和 Schema 的headline高度一致时 - 多个
h1会让 Google 怀疑页面主题模糊，降低对整页结构化数据的信任度，间接影响 snippet 展示概率 -
h2常对应 Rich Snippet 中的「章节标题」，比如 FAQ 或 How-To 类型中各子项的标题；若h2缺失或跳级（如h1→h3），Google 可能无法准确提取子模块边界 - 用
<div class="title"> 模拟 <code>h2，即使加了itemprop="name"，也大概率失败——因为解析器优先信任原生 heading 标签的嵌套关系FAQ 和 How-To 类型 Rich Snippets 对 H2-H3 的嵌套有硬性要求
Google 明确文档指出：FAQPage 和 HowTo 结构化数据，需配合清晰的视觉+语义标题层级。不是“有 Schema 就行”，而是要让机器能从 DOM 结构里自然推导出问答/步骤的分组关系。
- 每个
Question应由一个h2标记，且该h2必须是其所属<section></section>或<article></article>的第一个子元素 -
Answer内容应紧跟在对应h2后，中间不能插其他h2或未包裹的块级元素（如空<p></p>） - How-To 步骤中，每个
step的标题必须用h3，且必须严格嵌套在h2（整个教程主标题）之下；h2→h4或h2→p→h3都会导致解析失败 - Chrome DevTools 的「Elements → Accessibility」面板会标出「Heading order」警告，这类问题在 Rich Snippets 测试工具中通常表现为“无法识别步骤”或“问答未分组”
标题文本与 Schema 内容不一致时，Rich Snippets 会优先采信 DOM 结构
很多人以为只要 JSON-LD 里写清楚
headline和question，HTML 标签怎么写都无所谓。实际不是——Google 会交叉验证。一旦发现h1写的是“前端性能优化”，而 Schema 的headline是“React 面试题”，它会标记该页为“意图冲突”，Rich Snippet 直接不触发。-
h1和<title></title>必须语义一致（不必字字相同，但核心主题不能偏移）；否则 Rich Snippet 可能截断标题或替换为<title></title>内容 - FAQ 中每个
h2的文本必须与 Schema 里对应Question的name字段高度匹配；微小差异（如多一个“？”或少一个“的”）可能被容忍，但语序颠倒或关键词缺失会被判定为不匹配 - 测试时别只看 Structured Data Testing Tool，一定要用
view-source:查原始 HTML 源码——SPA 路由未 hydrate 前的 SSR 输出，才是 Google 真正看到的结构
移动端 Rich Snippet 展示受 H6 行高渲染异常影响
iOS Safari 对
h6的默认line-height渲染不一致，可能导致 Rich Snippet 折行错位或文字挤压。这不是 SEO 问题，但会影响用户点击意愿——而点击率反向影响 snippet 的长期保留概率。- 不要用
h6做富媒体摘要里的副标题或备注（那是small或aside的职责）；日常业务页几乎用不到h6 - 若必须使用
h6（如法律条款页），显式声明line-height: 1.2，并在 iOS 真机上验证折行效果 - Rich Snippet 预览图中，字体大小由 Google 控制，但行高和间距依赖原始 CSS；
h6若没重置，可能在 snippet 中显得过于紧凑，降低可读性
h1的唯一性和h2–h3的嵌套链——机器不看“你本意是什么”，只认 DOM 里那一行标签。 - 每个
