富媒体摘要必须使用JSON-LD格式的<script type="application/ld+json">，且结构化数据需与页面可见内容严格一致；Article类型须含headline、datePublished、author等字段，image须为可访问的数组，datePublished等日期须为带时区的ISO格式。
富媒体摘要要求哪些HTML结构必须存在
Google 的富媒体摘要（Rich Results）不是靠猜，而是严格依赖特定 HTML 结构和语义标记。没有 <script type="application/ld+json"> 或缺失关键属性，再漂亮的页面也进不了搜索结果的“精选框”。
最常被忽略的是：结构化数据本身必须可解析，且与页面可见内容强一致。比如 name 字段值必须和 <h1> 文本完全匹配（忽略空格和大小写差异不算“匹配”）；image 指向的 URL 必须真实可访问、尺寸达标（至少 1200×630 像素）、返回 200 状态码。
-
Article类型必须包含headline、datePublished、author（哪怕只是{"@type": "Person", "name": "Anonymous"}） -
Recipe类型中recipeIngredient必须是字符串数组，不能嵌套对象；prepTime必须用 ISO 8601 持续时间格式（如"PT15M"），写成"15 minutes"会直接失效 - 所有
@id值需为绝对 URL，相对路径（如"#recipe-1"）在 Google 工具中可能通过，但线上抓取时大概率被丢弃
为什么用 JSON-LD 而不是 Microdata 或 RDFa
JSON-LD 是当前唯一被 Google 官方明确推荐且长期稳定支持的格式。Microdata 在部分类型（如 QAPage）中已不被识别；RDFa 则因解析器兼容性差、容易和 CMS 模板冲突，上线后常出现字段丢失。
更实际的问题是维护成本：JSON-LD 可以整个塞进 <head>，不干扰 DOM 渲染逻辑；而 Microdata 要把属性硬插进 <div itemprop="author"> 这类标签里，前端改个 class 名或抽离组件就可能让结构化数据断掉。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- JSON-LD 允许动态注入（例如用
document.createElement("script")拼接后 append），适合 SSR/CSR 混合场景 - Google Search Console 的“富媒体测试工具”对 JSON-LD 的报错最具体，比如会指出
"datePublished is not a valid date"，而 Microdata 错误常只报"No rich results detected"，排查成本翻倍 - 不要在同一个页面混用多种格式——Google 会优先取第一个解析成功的，其余直接忽略，极易造成预期外覆盖
常见校验失败原因与修复代码片段
90% 的富媒体摘要未生效，问题不在逻辑，而在细节格式。下面三个例子直击高频雷区：
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "如何优化富媒体摘要",
"datePublished": "2024-03-15T08:30:00+08:00", // ✅ 正确：带时区的 ISO 格式
"dateModified": "2024-03-15T08:30:00+08:00", // ✅ 必须提供，即使和 published 相同
"author": {
"@type": "Organization",
"name": "技术团队"
},
"image": [
"https://example.com/img/cover.jpg" // ✅ 数组形式，且 URL 可公开访问
]
}
- 错误写法：
"datePublished": "2024/03/15"→ Google 解析为无效日期，返回"datePublished: Invalid date" - 错误写法：
"image": "https://example.com/img/cover.jpg"→ 必须是数组，单图也要写成["..."]，否则字段被静默丢弃 - 错误写法：
"author": "技术团队"→ 缺少@type，Google 不认作有效作者，富媒体摘要降级为无作者版
结构化数据和页面 DOM 内容不一致会怎样
Google 明确声明：当结构化数据中的字段（如 reviewRating.ratingValue）与用户可见文本（如页面上写的“评分：4.2”）无法对应时，该富媒体摘要会被拒绝，且可能影响同一域名下其他页面的富媒体资格。
这不是“建议一致”，而是硬性校验。Google 抓取时会做 OCR 或 DOM 文本比对，尤其关注数字、日期、名称类字段。例如你在 JSON-LD 里写 "ratingValue": 4.8，但页面 DOM 中只有 <p>用户评分：4.2</p>，就算其他所有字段都完美，这条也不会出现在搜索结果中。
- 动态渲染页面（React/Vue）要确保结构化数据在首屏 HTML 中已存在，或使用服务端注入——客户端 JS 后续写入的 JSON-LD，Googlebot 可能根本没等执行完就结束了抓取
- CMS 输出结构化数据时，避免用占位符（如
{{ post.author }}）未被替换就发到线上，这种空值或模板语法残留会直接导致整个脚本块解析失败 - 多语言站点必须为每种语言版本单独部署对应语言的结构化数据，混用（如英文页面塞中文
description）会导致富媒体摘要被过滤
真正卡住人的，往往不是“要不要加结构化数据”，而是“加了但字段对不上”“URL 写错协议”“时区漏了+号”这类肉眼难扫的字符级偏差。
