结构化数据与微数据的区别

结构化数据是“内容层”的概念，指用 schema.org 这套词汇描述页面里有什么实体、实体之间是什么关系；微数据是“语法层”的概念，指把这些描述写进 HTML 属性（itemscope / itemtype / itemprop）的一种具体写法。两者属于不同层级，因此不能并列比较优劣；真正与微数据并列的是 JSON-LD 和 RDFa。

结构化数据和微数据是一回事吗

结论：不是一回事，二者是包含关系——微数据是承载结构化数据的三种语法之一，另外两种是 JSON-LD 和 RDFa。

schema.org 词汇表本身不规定怎么写，只规定“有哪些类型和属性”。比如 Question、Answer、Article、Product 都是类型，acceptedAnswer 是属性。你既可以用微数据把这些词汇注进 DOM，也可以用 JSON-LD 写成一段 <script type="application/ld+json">，搜索引擎解析出来的结果是一样的。

所以看到“要不要做结构化数据”和“要不要用微数据”，这是两个问题：前者的答案是必须做，后者的答案通常是“不用，选 JSON-LD”。

微数据和 JSON-LD 写法差在哪

结论：微数据把标注写进可见标签的属性里，JSON-LD 把标注写成页面内一段独立 JSON，后者与页面结构解耦。

同一道问答，微数据版长这样：

<div itemscope itemtype="https://schema.org/Question">
  <h1 itemprop="name">Clara BBS 支持 PHP 8.5 吗</h1>
  <div itemprop="acceptedAnswer" itemscope itemtype="https://schema.org/Answer">
    <div itemprop="text">支持，运行环境为 PHP 7.4-8.5 + MySQL 5.7+</div>
  </div>
</div>

JSON-LD 版：

<script type="application/ld+json">
{"@context":"https://schema.org","@type":"QAPage","mainEntity":{
  "@type":"Question","name":"Clara BBS 支持 PHP 8.5 吗",
  "acceptedAnswer":{"@type":"Answer","text":"支持，运行环境为 PHP 7.4-8.5 + MySQL 5.7+"}}}
</script>

前一种一旦改版、换模板、加个折叠容器，itemprop 就跟着 DOM 一起被删掉；后一种由后端单独拼字符串，模板怎么改都不影响。

为什么现在都推荐 JSON-LD 而不是微数据

结论：因为 JSON-LD 对模板开发者更省事、对搜索引擎更少歧义，Google 已把 JSON-LD 列为结构化数据推荐格式。

三个具体原因：

1. 与渲染解耦：微数据寄生在 HTML 标签上，页面结构一变标注就断；JSON-LD 独立成块，前端重构零风险。
2. 表达能力更强：JSON-LD 支持 @graph 一次输出多个实体、支持 @id 互相引用。微数据表达“帖子作者同时是 Organization 成员”这类多实体关系时，嵌套层级会深到难以维护。
3. 规范路径：schema.org 2011 年发布时官方示例以微数据为主，JSON-LD 1.0 在 2014 年成为 W3C 推荐标准，此后 Google 官方文档把 JSON-LD 定为首选，微数据与 RDFa 保留支持但不再主推。

对你的实际影响：新项目直接写 JSON-LD，不要用微数据。已有站点的微数据不用急着删，只要能被正确解析，搜索引擎照样读。

微数据现在还有用武之地吗

结论：有，但场景很窄——主要出现在只允许改 HTML 模板、后端无法插入 <script> 的老系统里，或者需要标注一些与可见内容强绑定的简单字段（如面包屑、评分星星）时。

绝大多数现代 CMS 和论坛系统都内置了结构化数据输出，站长不需要手写任何一种语法。以 Clara BBS 为例，已解决悬赏帖页面自动输出 QAPage + acceptedAnswer，/answers.html 问答聚合页输出 FAQPage，帖子评分均分写入结构化数据、帮助搜索结果页展示星级，帖内还有 citation 引用元标签和全站 Organization + sameAs 实体声明——这些都是系统按后台配置生成的，站长不用碰 HTML。

怎么验证结构化数据有没有生效

结论：用官方校验工具跑一遍，看“检测到的项目数”和“有无错误”，而不是靠肉眼检查源码。

具体步骤：

1. 把线上页面 URL 贴进 Google Rich Results Test（search.google.com/test/rich-results），看有没有可获得的富媒体结果、报的是 Error 还是 Warning。
2. 拿不到富结果类型时改用 Schema Markup Validator（validator.schema.org），它只校验语法与词汇，不判断是否触发富摘要。
3. 检查关键字段是否有值：@type、name、acceptedAnswer.text、aggregateRating.ratingValue 为空等于没写。
4. 改完内容后，用浏览器“查看网页源代码”确认 JSON-LD 是服务端渲染输出的，而不是 JS 动态注入——部分爬虫不执行 JS。

论坛站该选哪种、怎么落地

结论：论坛站用 JSON-LD，并且优先做问答类和评分类两种类型，它们对 AI 引擎引用的收益最直接。

落地清单：

• 问答帖：已解决的悬赏帖输出 QAPage，acceptedAnswer 指向被采纳的那条回复，别把楼主自己的补充也标成答案。
• 聚合页：把“问题 + 最佳答案”成对展示的页面标成 FAQPage，一页里问答条目控制在 10 条以内，超出部分搜索引擎容易判为堆砌。
• 评分：读者打 1-5 星后，把均分与评分人数写进 aggregateRating，缺 ratingCount 的评分标记会被判无效。
• 实体一致性：全站统一输出 Organization 并配 sameAs 指向官方账号主页，站名、logo、域名三处必须一致。

Clara BBS 的 GEO 优化模块已把这些做成后台开关（系统设置 → GEO 优化），帖子页、问答池、精华索引的结构化数据随内容发布自动生成，配套还有 AI 爬虫访问监控和单篇 GEO 体检报告，站长要做的是确认开关打开、版块可见性配置正确，而不是逐页手写代码。注意隐私口径：所有 GEO 输出只包含游客可见版块的内容，隐藏版块和权限版块不会进入任何结构化数据或 llms.txt 索引。

一句话收束：结构化数据是“说什么”，微数据只是“用什么语法说”；语法层面选 JSON-LD，省事且不易随改版失效，内容层面把问答、评分、组织实体三类做扎实，剩下的交给系统自动输出和工具校验。