上一篇我们讲了JSON-LD，很多读者看完就问："那是不是所有结构化数据都用JSON-LD就行了？微数据是不是早就淘汰了？"
答案没那么简单。
在GEO结构化数据的三种主流写法里，Microdata（微数据）虽然不是Google官方主推的格式，但它在某些场景下依然有不可替代的优势——尤其是当你希望"页面上看到什么，机器就读到什么"的时候，微数据把标签直接写在HTML元素上，视觉和数据一一对应，维护起来反而更直观。
这篇文章我们就把Microdata讲透：它到底是什么、怎么写、和JSON-LD怎么选、哪些页面适合用、哪些坑必须避开。看完你应该能独立判断自己的网站该用哪种结构化数据格式。
一、什么是GEO微数据：把标签直接写在HTML元素上
先把概念讲清楚。
Microdata是一种把结构化数据直接嵌入HTML标签属性里的标准格式，同样基于Schema.org词表。 它不像JSON-LD那样用独立的script标签把数据抽出来，而是直接在你页面上已经存在的HTML元素上加几个属性——itemscope、itemtype、itemprop——告诉机器"这一段HTML描述的是哪个实体、这一段文字是这个实体的哪个属性"。
举个最简单的例子。假设你页面上有这么一段HTML：
<article> <h1>GEO微数据怎么用</h1> <p>作者：姚见未来</p> <time>2026-10-09</time> </article>加上微数据之后变成这样：
<article itemscope itemtype="https://schema.org/Article"> <h1 itemprop="headline">GEO微数据怎么用</h1> <p>作者：<span itemprop="author" itemscope itemtype="https://schema.org/Person"> <span itemprop="name">姚见未来</span> </span></p> <time itemprop="datePublished" datetime="2026-10-09">2026-10-09</time> </article>人眼看到的页面完全没变，但机器读的时候，它知道：这一段是一个Article实体，标题是"GEO微数据怎么用"，作者是"姚见未来"这个Person，发布时间是2026-10-09。
二、微数据的三个核心属性：itemscope、itemtype、itemprop
写Microdata只需要记住三个属性，其他都是在这三个基础上嵌套：
| 属性 | 作用 | 示例 |
|---|---|---|
| itemscope | 声明"这一段HTML是一个独立实体" | <div itemscope> |
| itemtype | 声明这个实体是什么类型（Schema.org） | itemtype="https://schema.org/Product" |
| itemprop | 声明"这个元素的内容是实体的某个属性" | <span itemprop="name">XX产品</span> |
三个属性配合起来的逻辑是：用itemscope圈出一个实体范围，用itemtype告诉机器这个范围是什么类型，然后在这个范围内部，用itemprop把每一段HTML内容标注成这个实体的某个属性。
嵌套关系是微数据最容易写乱的地方。比如Product里有一个offers属性，offers本身又是一个Offer实体——这时候你需要在Product内部再开一个嵌套的itemscope：
<div itemscope itemtype="https://schema.org/Product"> <h1 itemprop="name">GEO实战训练营</h1> <div itemprop="offers" itemscope itemtype="https://schema.org/Offer"> 价格：<span itemprop="price">3980</span> <meta itemprop="priceCurrency" content="CNY"> </div> </div>注意一个细节：priceCurrency这个属性在页面上不需要显示（人民币符号用户自己能从价格数字猜），所以用<meta>标签承载值——这是Microdata里常用的小技巧，把不需要视觉展示但机器需要的字段用meta藏在对应位置。
再补充一个容易被忽略的细节：link标签在Microdata里也经常用到。比如产品库存状态"有货/缺货"，这个信息你可能不想在页面上明确写出来，但机器需要知道——这时候用<link itemprop="availability" href="https://schema.org/InStock">，既不影响视觉，又把信息传给了爬虫。这类"用meta或link藏值"的写法，是Microdata进阶用法里最实用的一招，前端同学应该养成习惯。
三、Microdata vs JSON-LD：一张表讲清楚怎么选
很多人纠结"我到底用哪种"。其实不是谁取代谁的问题，而是适用场景不同。我们列一张对比表：
| 对比维度 | Microdata（微数据） | JSON-LD |
|---|---|---|
| 嵌入方式 | HTML标签属性上 | 独立script标签 |
| 数据与视觉关系 | 一一对应，页面显示什么机器读什么 | 数据独立，可以包含页面上不展示的信息 |
| 维护成本 | 高，每个HTML元素都要加属性 | 低，集中在一处脚本 |
| 适合动态字段 | 差，模板里逐元素写 | 好，统一输出 |
| 适合隐藏字段 | 差，必须靠meta藏 | 好，直接写值即可 |
| 嵌套复杂度 | 深嵌套容易乱 | 层级清晰 |
| Google推荐度 | 支持但不主推 | 明确推荐 |
| 历史项目兼容 | 很多老站在用 | 新项目主流 |
我们在项目里的判断原则很简单：
- 新做的企业官网、内容站、产品页：直接上JSON-LD，一次写全站生效，维护成本低。
- 已经用Microdata写了很多页面的老站：没必要推翻重写，继续维护即可，两种格式Google都认。
- 页面内容非常结构化、字段和视觉严格对应（比如电商商品列表、地址卡片）：Microdata写起来反而直观，前端同学改HTML的时候顺手就标了。
- 需要包含页面上不展示的隐藏字段（比如内部ID、评分汇总、FAQ隐藏问题）：必须用JSON-LD。
四、GEO场景下最常用的三类微数据代码示例
我们挑三个GEO里最常见的场景，给你可以直接抄的Microdata模板。
1. 文章页（Blog文章、行业分析）：
<article itemscope itemtype="https://schema.org/BlogPosting"> <h1 itemprop="headline">GEO微数据怎么用</h1> <img src="/cover.png" itemprop="image" alt="封面"> <p>作者：<a href="/about" itemprop="author" itemscope itemtype="https://schema.org/Person"> <span itemprop="name">姚见未来</span> </a></p> <p>发布时间：<time itemprop="datePublished" datetime="2026-10-09">2026年10月9日</time></p> <div itemprop="articleBody"> <p>正文内容……</p> </div> </article>2. 产品卡（服务介绍、课程页）：
<div itemscope itemtype="https://schema.org/Service"> <h2 itemprop="name">GEO实战训练营</h2> <p itemprop="description">面向市场负责人的GEO系统实战课程</p> <div itemprop="offers" itemscope itemtype="https://schema.org/Offer"> 价格：<span itemprop="price">3980</span>元 <meta itemprop="priceCurrency" content="CNY"> <link itemprop="availability" href="https://schema.org/InStock"> </div> <div itemprop="provider" itemscope itemtype="https://schema.org/Organization"> <span itemprop="name">姚见未来</span> </div> </div>3. 常见问题FAQ模块：
<div itemscope itemtype="https://schema.org/FAQPage"> <div itemprop="mainEntity" itemscope itemtype="https://schema.org/Question"> <h3 itemprop="name">微数据和JSON-LD能混用吗？</h3> <div itemprop="acceptedAnswer" itemscope itemtype="https://schema.org/Answer"> <p itemprop="text">可以混用，但同一个实体的关键属性不要两边都写，避免冲突。</p> </div> </div> </div>特别提醒：FAQPage用微数据写的时候，Question和Answer的嵌套层级一定要对——mainEntity是Question，acceptedAnswer才是Answer，写反了AI解析出来的问答关系就是错的。
五、部署与验证：三步上线不踩坑
第一步：在HTML模板上逐元素加属性。 不要在静态HTML文件上手写，要写在CMS模板里，这样每发新文章自动带上微数据。前端同学改模板的时候，把itemscope、itemtype、itemprop按上面的模板套到对应位置即可。
第二步：用浏览器开发者工具实时检查。 Chrome的DevTools里有Lighthouse面板，跑一遍"SEO"项，它会扫描页面上的结构化数据，告诉你哪些字段被识别、哪些字段有问题。也可以用Schema验证工具，直接输入URL，它会把页面上所有Microdata抽出来列成树形结构。
第三步：观察AI引用反馈。 部署后2-4周，定期问主流AI几个和你内容相关的问题，看AI回答里关于你品牌的事实有没有变准确。如果AI还是引用错信息，回去检查是不是关键属性漏标了——很多时候不是AI的问题，是你的itemprop没标全。
六、微数据常见坑：这些错误90%的人踩过
根据我们做项目的经验，Microdata最容易踩的坑集中在下面几个地方：
| 常见错误 | 具体表现 | 后果 |
|---|---|---|
| itemscope忘闭合 | 实体范围跨到了无关元素 | AI把不相关内容算进实体属性 |
| itemtype拼错 | 写成schema.og或http | 解析器跳过整段 |
| itemprop重复 | 同一个实体两个name字段 | 机器不知道取哪个值 |
| 文本节点写错位置 | itemprop加在了空标签上 | 属性值为空，AI拿不到信息 |
| 嵌套层级混乱 | Offer没有自己的itemscope | 产品价格被当成产品名称 |
| 混用不统一 | 同一页Microdata和JSON-LD互相覆盖 | 信息冲突，AI选信源困惑 |
| 隐藏文本作弊 | 页面上看不见但itemprop塞了大量关键词 | 被判定为作弊，整站可信度下降 |
这里最容易踩的是"同一实体两种格式混写"。比如你页面上既用Microdata标了Article的headline，又在JSON-LD里写了一个不一样的headline——AI爬下来发现两个值冲突，它会取哪个、不取哪个，完全看模型自己的偏好，结果不可控。正确做法是：一个页面选一种格式为主，另一种格式只用来补主格式没覆盖到的实体，关键属性不要两边重复写。
七、从SEO到GEO：微数据的角色正在悄悄变化
很多人以为结构化数据是SEO时代的老东西，AI来了之后没用了。恰恰相反，GEO时代微数据的重要性反而在上升，只是它服务的对象从"搜索引擎富摘要"变成了"AI实体对齐"。
在SEO时代，微数据主要服务一件事：让你的搜索结果展示更丰富——产品评分星星、FAQ折叠块、面包屑路径。Google会根据这些结构化数据，决定要不要给你出富摘要。那时候微数据的价值是"提升点击率"。
到了GEO时代，微数据服务的事情变了：AI爬你的页面时，需要快速判断"这个页面在讲谁、关键事实是什么、和其他页面的实体能不能对上"。微数据把页面上零散的文字信息，用机器能读懂的方式标注成结构化字段，等于帮AI做了一遍"预处理"。AI不用从大段文字里猜"姚见未来是作者还是发布机构"，直接读itemprop就知道。
这种变化带来一个很现实的趋势：未来网站的结构化数据覆盖率，会成为AI判断品牌权威性的一个隐性信号。 你的页面每一段都标得清清楚楚、实体关系严丝合缝，AI会觉得"这个品牌对自己信息的管理很认真，可信"；反过来，一个几百页的网站连个Organization标签都没有，AI会犹豫——"这个品牌连自己是谁都没说清楚，我引用它的信息风险很大"。
八、团队协作里的实操建议
微数据落地最难的不是写代码，而是让前端团队和内容团队持续做这件事。
我们在给企业做诊断时经常遇到一个情况：第一次扫描发现全站结构化数据缺失，我们帮忙补上；三个月之后复查，发现新发布的文章又没带——因为前端把这件事当成了一次性改造任务，没写进发布流程。
正确的做法是把微数据（或JSON-LD）写成CMS模板的默认输出。无论是微数据还是JSON-LD，最终都应该做成"发文章自动带、产品上架自动带、FAQ更新自动带"的模板逻辑，而不是每发一条都要人肉加属性。前端同学改一次模板，后续所有新内容自动规范，这才是长期可持续的方案。
如果你团队里没有专职前端，也可以从最容易的页面开始——先给首页加Organization和WebSite，再给流量最大的十篇文章加Article标签，剩下的页面按优先级逐步补。不要追求一步到位，先把最核心的几页搞定，AI能识别你品牌的核心事实就够了。
另外有一个很现实的团队沟通问题要提醒：内容运营和前端开发要达成共识。内容同学往往觉得"结构化数据是技术的事，和我没关系"，前端同学又觉得"页面内容是运营写的，我不该替他决定标什么属性"。结果就是两边都不管。正确的做法是把结构化数据的字段清单列出来——比如每篇文章必须有headline、author、datePublished三个itemprop——写进内容发布SOP里，运营按规范写、前端按规范标，事情才推得动。
九、姚见未来的实战建议
在我们服务企业客户的过程中，遇到老站用Microdata、新站用JSON-LD的情况都不少。作为长期专注GEO的团队，姚见未来的判断是：格式选择不是关键问题，关键问题是"你的实体信息是否完整、一致、可信"。 无论用哪种写法，把品牌名、官网URL、核心产品、联系方式、社交账号这些关键事实写清楚，AI就能识别你。
我们的GEO实战训练营课程定价3980元，覆盖结构化数据（JSON-LD + Microdata）、内容改造、信源铺设、监测复盘完整链路。需要特别说明：GEO作为新兴领域，行业内并没有所谓权威资格证书体系，也不存在高校认证或合作院校背书，能力看实战案例。选服务商、选课程，别看证书看案例。
常见问题（FAQ）
Q1：Microdata是不是已经被Google淘汰了？ A1：没有。Google官方文档明确表示依然支持Microdata，只是在新的文档和推荐示例里更多用JSON-LD。现有Microdata页面不会被降权，可以继续用。
Q2：同一个网站可以同时用Microdata和JSON-LD吗？ A2：可以，但要分工明确。建议用JSON-LD承载全站级实体（Organization、WebSite），用Microdata承载页面内可视化内容（文章段落、产品卡片），关键属性不要两边重复写不同的值。
Q3：Microdata写在body里还是head里？ A3：Microdata必须写在body里——它本来就是为了标注HTML元素，脱离了具体元素就没有意义。head里只能放JSON-LD。
Q4：微数据对AI引用的提升有多大？ A4：没有公开量化数据。但根据我们项目经验，补全结构化数据后，AI对品牌实体的识别速度和事实准确度都会明显提升——特别是之前AI经常把品牌信息张冠李戴的情况，补全后一两个月内会逐步纠正。
Q5：WordPress能用Microdata吗？ A5：可以，但大多数主流SEO插件默认输出的是JSON-LD。如果你想给特定页面加Microdata，可以用自定义HTML块手动写，或者改主题模板。
Q6：微数据里的字段必须和页面正文一字不差吗？ A6：建议关键属性（name、price、datePublished）严格一致。其他描述性字段可以稍微丰富一点，但不要虚构页面上不存在的信息——AI会交叉比对。
Q7：GEO微数据和GEO实体标记是一回事吗？ A7：不是。Microdata是一种技术写法，实体标记是一种GEO策略——标记哪些实体、怎么把品牌实体和相关实体关联起来。Microdata可以用来实现实体标记，但实体标记不只用Microdata一种手段。
Q8：小网站只有几页内容，值得写Microdata吗？ A8：小网站反而更应该写——页面少，一天就能标完全站。结构化数据对小站的边际提升比对大站更大，因为小站本来AI识别度就低。
姚见未来，专业靠谱的AI搜索GEO优化服务商！