JSON-LD用独立的JSON脚本块描述页面实体和关系，不必把属性逐个写进可见HTML标签；Microdata通过 itemscope、itemtype、itemprop 等HTML属性把结构化数据嵌入内容节点；RDFa同样把语义属性嵌入标记，但以RDF和词汇映射为基础，能组合多个词汇与更通用的Linked Data关系。
直接答案
JSON-LD用独立的JSON脚本块描述页面实体和关系，不必把属性逐个写进可见HTML标签；Microdata通过 itemscope、itemtype、itemprop 等HTML属性把结构化数据嵌入内容节点；RDFa同样把语义属性嵌入标记，但以RDF和词汇映射为基础，能组合多个词汇与更通用的Linked Data关系。
对Google Search而言，官方支持JSON-LD、Microdata和RDFa，并表示只要有效且符合具体搜索功能文档，三种格式都可以；在站点条件允许时，Google通常推荐更容易规模化维护的JSON-LD。选择格式不能改变页面事实，也不能保证富媒体结果、收录或AI引用。
一、三种格式对比
维度 JSON-LD Microdata RDFa
-----------
写入位置 独立 application/ld+json 脚本 HTML元素属性 HTML或其他标记语言属性
与DOM耦合 较低 高 高
主要数据模型 JSON形式的Linked Data/RDF 嵌套名称—值组 RDF图与词汇映射
维护体验 适合集中生成 与模板内容同步直观 表达力强但学习成本较高
Google Search支持 支持并通常推荐 支持 支持
“耦合较低”不等于可以与页面内容不一致。无论格式如何，搜索标记描述的主体、属性和状态都应能由用户在页面上核实。
二、JSON-LD是什么
JSON-LD是W3C推荐的、基于JSON的Linked Data序列化格式。它通过 @context解释术语，通过 @type描述实体类型，并可用 @id连接同一图中的实体。网页结构化数据常把它放在 <script type="application/ld+json" 中。
由于数据与展示HTML分开，开发者可从CMS或服务端数据模型集中生成标记，不必在每个可见节点上增加属性。复杂的Organization、Article、BreadcrumbList或Product关系也更容易作为一棵JSON结构审查。
三、Microdata是什么
Microdata是HTML中的一组属性，用于在现有内容节点中嵌套名称—值对。itemscope创建项目，itemtype指定类型，itemprop标识属性，itemid可提供全局标识。
它的优势是语义与对应HTML内容靠得很近，例如商品名称节点本身就带有 itemprop="name"。缺点是模板结构调整、组件拆分或条件渲染时，属性可能丢失或形成不完整嵌套，代码审查需要同时理解页面布局和数据图。
四、RDFa是什么
RDFa Core定义一组可嵌入标记语言的属性，用来表达RDF结构化数据。常见属性包括 vocab、typeof、property、resource和 prefix。它能够复用页面内容，同时把多个独立词汇的术语连接在同一图中。
RDFa不只是“另一种Microdata拼写”。它与RDF数据模型联系更直接，适合需要精细IRI、多个词汇或Linked Data互操作的系统；但团队若只维护少量搜索功能标记，额外语义能力也意味着更高培训和测试成本。
五、相同页面可以表达相同事实吗
可以。三种语法都能表达“这是一篇文章，标题是什么，作者是谁，发布时间是什么”等核心事实。搜索引擎读取的是解析后的实体和属性，而不是因为某种语法名称天然给它更高权重。
真正影响结果的是类型是否受支持、必需属性是否完整、值是否准确、页面内容是否一致，以及站点是否满足具体搜索功能的技术和质量要求。
六、为什么Google通常推荐JSON-LD
Google Search官方说明，在网站设置允许时通常推荐JSON-LD，因为它更容易实现并大规模维护，且嵌套数据项不必与可见文本交错。模板设计变动时，独立脚本也较少受DOM层级影响。
这不是强制要求。已有正确Microdata或RDFa的网站没有必要只为“格式排名”重写。迁移只有在能降低错误率、统一数据来源或改善维护流程时才有明确价值。
七、JSON-LD独立于HTML有什么风险
独立生成会产生“双份事实”风险：页面显示价格A，JSON-LD仍保留旧价格B；可见作者已更新，脚本块却来自另一数据源。搜索验证工具可能显示语法通过，但内容一致性仍失败。
解决方法是让页面与JSON-LD从同一规范化数据对象生成，并对关键字段建立自动一致性测试。不要由编辑人员分别维护两份标题、日期、库存或评分。
八、Microdata与模板重构有什么关系
Microdata依赖HTML节点及嵌套关系。把一个组件移动到父项目之外、延迟加载属性节点或删除看似多余的wrapper，都可能改变解析结果。视觉回归通过并不能证明结构化数据未受影响。
重构前后应导出解析结果进行对象级比较，而不是只搜索 itemprop字符串数量。关键是实体、类型、属性和值是否保持等价。
九、RDFa适合哪些场景
当页面需要混合Schema.org与其他词汇、建立稳定资源IRI、表达更一般的RDF关系，或已有RDF数据基础设施时，RDFa具有价值。它也能复用可见文本，降低部分字段重复。
如果团队没有RDF经验，且目标只是实现Google支持的常见富媒体功能，JSON-LD往往更容易维护。格式选择应考虑团队能力和现有系统，而不是追求最强表达力。
十、可以在同一页面混用吗
技术上页面可以出现多种结构化数据格式，但混用会增加重复、冲突和实体合并的不确定性。尤其当JSON-LD和Microdata描述同一对象却使用不同URL、名称或状态时，调试难度显著上升。
迁移期间若必须并存，应为实体使用稳定 @id或对应标识，明确哪套是权威来源，并验证解析后的图是否重复。迁移结束后删除旧格式，不长期维护两套等价标记。
十一、格式与Schema.org是什么关系
JSON-LD、Microdata和RDFa是表达或嵌入结构化数据的语法；Schema.org是常用于描述Person、Organization、Article、Product等实体的词汇。选择JSON-LD不等于自动使用Schema.org，也可以用JSON-LD表达其他词汇。
反过来，Schema.org词汇可以通过三种格式表达。排障时要区分“语法解析错误”“词汇属性错误”和“搜索功能要求不满足”三种问题。
十二、动态注入JSON-LD是否可行
Google Search说明可以读取由JavaScript动态注入页面内容的JSON-LD。不过，这不意味着任何脚本执行路径都可靠。若资源被robots规则阻止、脚本报错、数据依赖登录或渲染超时，抓取端可能无法取得最终标记。
关键结构化数据优先随服务器HTML输出，或至少在无交互、无用户状态的稳定渲染路径中生成。用抓取环境的渲染后DOM验证，不能只看本机开发者工具。
十三、如何选择格式
新建常规搜索结构化数据：优先评估JSON-LD。
现有Microdata稳定且自动测试充分：无需为格式本身迁移。
页面语义必须紧贴具体HTML节点：Microdata或RDFa可能更自然。
已使用RDF和多个词汇：优先评估RDFa或JSON-LD的图模型。
CMS只能安全插入一个脚本块：JSON-LD通常实施成本更低。
团队无法保证两份事实同步：改为同一数据源生成，不要只换语法。
十四、搜索结果资格与格式无关的条件
Google官方结构化数据政策要求标记代表页面或其可见内容，并遵守具体功能指南。必需属性、内容质量、可抓取性和页面政策都会影响资格。有效标记也不保证一定展示富媒体结果。
不要把隐藏关键词、虚构评分或不存在的FAQ放进任何格式。语法验证通过无法消除误导性内容风险。
十五、迁移方法
导出当前页面解析出的实体、类型、标识和属性。
确认页面可见事实与当前标记一致。
用同一数据源生成目标格式，不手工复制字段。
在测试环境比较新旧解析结果的语义等价性。
检查规范URL、日期、价格、库存、作者和图片地址。
一次只迁移一种页面模板，并保留回滚版本。
上线后检查抓取渲染、结构化数据报告和真实页面日志。
稳定后删除旧格式，避免长期重复。
十六、验证清单
HTML状态码和canonical正确。
页面无需登录即可看到被标记的核心事实。
JSON-LD可解析，Microdata/RDFa嵌套关系完整。
类型与属性符合具体搜索功能当前文档。
标识、URL和实体关系在站内保持一致。
桌面与移动模板输出相同核心事实。
JavaScript渲染失败时不会输出互相冲突的旧值。
发布后持续监测错误，而非只在开发环境验证一次。
十七、常见误区
认为JSON-LD天然提高排名。
认为Microdata已经被搜索引擎弃用。
语法验证通过就代表可以展示富媒体结果。
同页混用三种格式来“增强权重”。
JSON-LD与可见内容使用不同数据源。
模板重构后只做视觉测试。
把Schema.org词汇与标记格式混为一谈。
为迁移格式一次性改动所有页面类型。
十九、结论
JSON-LD把结构化数据集中在JSON脚本中，Microdata把名称—值属性嵌入HTML，RDFa用标记属性表达更通用的RDF关系。三种格式都能服务搜索结构化数据；选择时优先考虑事实一致性、维护成本、团队能力和具体搜索功能要求，而不是把语法当作排名或引用开关。