JSON-LD vs Microdata vs RDFa：三种结构化数据格式怎么选？
搜"结构化数据怎么加"，你会看到三种格式：JSON-LD、Microdata、RDFa。 它们表达的信息一样，但写法、维护成本和 Google 的支持态度完全不同。 这篇文章做三种格式的完整对比，并给出 2026 年的选型结论。 选定 JSON-LD 后直接用 Schema 结构化数据生成器生成。
三种格式一句话概括
| 格式 | 本质 | 写法位置 | 维护体验 |
|---|---|---|---|
| JSON-LD | 独立 JSON 代码块 | <script> 标签 | 与正文分离，最省心 |
| Microdata | HTML 属性标注 | itemscope/itemprop 属性 | 嵌入标签，改版易漏 |
| RDFa | HTML 属性标注（更强） | typeof/property 属性 | 属性冗长，门槛高 |
JSON-LD：2026 年的明确首选
Google 官方文档长期推荐 JSON-LD，理由很实在：不影响正文 HTML、出错不影响
页面渲染、批量替换容易（Google 开发者文档，查询时间 2026-09-13）。
对静态站和自建系统尤其友好——改 Schema 只动 ld+json 代码块，
不用碰内容模板。语法拆解见
JSON-LD 格式详解。
Microdata：老代码与历史项目在用的格式
Microdata 把结构化信息写进 HTML 属性：<div itemscope
itemtype="https://schema.org/Product">。它的优点是
"数据就在标签旁边"，一眼能看到；缺点是与页面结构强耦合：
改版时漏删一个 itemprop 就会残留过期信息，测试工具也会报
页面不可见的内容。老项目维护可以接受，新项目不推荐。
RDFa：能力最强但回报不成比例
RDFa 是属性标注的"增强版"，支持更复杂的语义表达（前缀、多词汇表混合）， 但代价是属性极其冗长、可读性差。对绝大多数网站来说， 它的表达能力远超出日常 SEO 需求，投入产出比最低。
三种格式能混用吗
能但没必要。同一页面重复声明同一实体容易造成信息冲突 （比如 JSON-LD 说价格 299、Microdata 写 399，搜索引擎不知道该信谁）。 建议一个页面只使用一种格式，站点内统一。混用出问题时的排查方式 与常见错误清单一致， 先删到只剩一种再看结果。
选型决策表
| 你的情况 | 推荐格式 | 理由 |
|---|---|---|
| 新站/静态站/自建系统 | JSON-LD | 改动隔离、批量易维护 |
| 维护老项目（已在用 Microdata） | 维持 Microdata | 避免大改，逐步迁移再说 |
| 需要强语义表达（研究类项目） | RDFa（罕见） | 一般站点用不到 |
独立站卖家如果把 RDFa 换成 JSON-LD 还能顺便统一商品页结构， 见Product Schema 指南。
从 Microdata 迁移到 JSON-LD 怎么做
第1步 用生成器为每个页面生成等价 JSON-LD（先做主页/权重页） 第2步 部署 JSON-LD 代码块，保留 Microdata 观察 1-2 周 第3步 确认测试通过、Search Console 无报错后删除 Microdata 属性
渐进式迁移比一把梭安全，避免切换期间搜索展示出现真空期。
迁移时机的三个信号
老项目一直用 Microdata 也没出事，什么时候值得花力气迁到 JSON-LD？ 看三个信号：一是改版频繁，模板每次改动都要小心 不破坏 itemscope 属性；二是报错反复出现， 测试工具频繁抓出不规范标记；三是新增页面量大， Microdata 的逐条人工维护成本已经高于自动化迁移成本。
三个信号出现任意两个，就可以启动迁移——用 JSON-LD 重建等价结构， 并行观察 1-2 周后删除旧标记（渐进迁移步骤见上文）。
迁移完成后记得做一次全站验证 + 更新 Search Console 监控， 确保新格式稳定运行。如果只有一个信号出现， 维持现状也未尝不可——技术债还不算高的时候，不动比乱动更安全。
小结
三种格式的结论很清晰：新项目一律 JSON-LD，老项目逐步迁移， RDFa 除非特殊需求否则不必碰。JSON-LD 的生成与维护有工具兜底， 选型焦虑可以直接消除。立刻开工： → 打开 Schema 生成器，用 JSON-LD 格式生成第一段结构化数据。