poxiaoxi博客很多人搜索“结构化数据有哪些种类”，真正想解决的并不是背一套 Schema 名称，而是判断自己的页面应该标记什么。结构化数据的核心作用，是把网页中原本给人看的内容，用机器更容易理解的方式表达出来，例如这是一篇文章、一个商品、一家公司、一个视频，还是一个活动。
在网站优化场景里，结构化数据通常和 Schema.org、JSON-LD、Google 富媒体搜索结果一起出现。它不是给页面“加关键词”，也不是只要添加就一定会带来特殊展示。更准确的理解是：它为搜索引擎提供清晰的语义说明，让页面有机会参与对应的搜索展现形式。
两种分类方式
谈结构化数据的种类，容易混在一起说。实际上可以分成两条线：一种是“怎么写”，也就是标记格式；另一种是“写什么”，也就是页面内容对应的 Schema 类型。
| 分类角度 | 常见种类 | 解决的问题 |
|---|---|---|
| 按写法格式 | JSON-LD、Microdata、RDFa | 决定结构化数据嵌入网页的技术方式 |
| 按内容类型 | Article、Product、Breadcrumb、Organization、VideoObject 等 | 说明页面主体内容是什么，以及包含哪些属性 |
| 按搜索展现 | 文章结果、商品结果、面包屑、视频结果、活动结果等 | 判断某类标记是否可能参与搜索结果中的增强展示 |
Schema.org 是一个很大的结构化数据词汇库，包含大量类型和属性。实际做网站时，不需要把所有类型都记住，更重要的是选择与页面内容匹配的类型。Google 搜索支持的富媒体结果只是其中一部分，不能把“Schema.org 有这个类型”直接理解为“Google 搜索一定会展示这个效果”。
三种写法
从技术实现看，结构化数据常见写法主要有 JSON-LD、Microdata 和 RDFa。Google 搜索文档支持这三种格式，其中 JSON-LD 是更常见、也更便于维护的方式。它通常放在页面代码中，不需要把每一个 HTML 标签都改成带属性的写法。
JSON-LD
JSON-LD 使用 JSON 形式描述页面信息，适合大多数现代网站。它与页面正文相对分离，后期修改字段、排查错误、由 CMS 或插件统一生成都比较方便。
{
"@type": "Article",
"headline": "结构化数据有哪些种类",
"author": {
"@type": "Person",
"name": "网站编辑"
},
"datePublished": "2026-07-09"
}上面的例子表达的是：当前页面主体是一篇文章，文章有标题、作者和发布日期。实际部署时，还需要按照对应平台文档补齐必要字段，并确保这些信息在页面上对用户可见。
Microdata
Microdata 是把结构化属性写进 HTML 标签里的方式。它和页面内容绑定得更紧，直观但维护成本较高。对于模板复杂、字段经常变化的网站，后期改动可能不如 JSON-LD 灵活。
RDFa
RDFa 也可以嵌入 HTML 中描述语义关系，适合对语义网、知识图谱或复杂数据关系有更高要求的场景。普通内容站、企业站、电商站通常不需要优先选择 RDFa。
文章类标记
内容站最常接触的是 Article、BlogPosting、NewsArticle 这类结构化数据。它们适合新闻稿、教程、博客文章、评测文章、知识科普等页面，用来说明标题、作者、发布时间、更新时间、图片、正文主体等信息。
| 类型 | 适合页面 | 例子 |
|---|---|---|
| Article | 通用文章、资讯、专题内容 | 一篇介绍“结构化数据是什么”的站内文章 |
| BlogPosting | 博客风格内容、经验分享 | 个人博客中的 SEO 实操记录 |
| NewsArticle | 新闻属性更强的内容 | 产品发布、行业事件、公司动态报道 |
这类标记的价值在于帮助搜索引擎识别文章主体，而不是替代文章质量。标题、作者、发布时间等信息如果页面上没有展示，或者结构化数据与正文不一致，反而可能带来质量问题。
面包屑标记
BreadcrumbList 是很多网站都适合添加的类型，尤其是栏目层级明显的内容站、电商站、资源站。它用于说明当前页面在网站结构中的位置，例如：首页 > 技术 SEO > 结构化数据。
{
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "首页"
},
{
"@type": "ListItem",
"position": 2,
"name": "技术SEO"
},
{
"@type": "ListItem",
"position": 3,
"name": "结构化数据"
}
]
}面包屑结构化数据的意义不是“多放几个内链”，而是帮助搜索引擎理解页面层级。对于文章页、分类页、产品详情页来说，它通常比一些复杂标记更基础，也更容易稳定维护。
实体类标记
如果页面主要介绍一个品牌、公司、机构、作者或线下门店，可以考虑 Organization、Person、LocalBusiness 等类型。它们描述的不是某一篇文章，而是网页中的实体对象。
| 类型 | 说明 | 适合场景 |
|---|---|---|
| Organization | 组织、公司、品牌、机构信息 | 关于我们、品牌介绍、企业官网首页 |
| Person | 个人身份、作者、专家、公开人物 | 作者页、专家介绍页、个人作品页 |
| LocalBusiness | 有线下地址或本地服务属性的商家 | 餐厅、门店、维修服务、诊所、培训机构 |
这类结构化数据最怕“过度包装”。例如一个普通博客作者页可以标记 Person，但不应该把没有实际营业地点的网站标记成 LocalBusiness；一个品牌介绍页可以写 Organization，但不要添加页面上不存在的联系电话、地址或评分。
产品类标记
电商网站、软件下载站、SaaS 产品页经常会遇到 Product、Offer、AggregateRating、Review 等类型。它们用于描述商品或服务名称、价格、库存、评分、评价等信息。
{
"@type": "Product",
"name": "某款截图工具",
"description": "一款用于网页截图和图片标注的软件",
"offers": {
"@type": "Offer",
"price": "29.00",
"priceCurrency": "CNY"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.6",
"reviewCount": "128"
}
}产品类结构化数据对信息真实性要求较高。价格、库存、评分、评价数量应当与页面可见内容一致，不能为了搜索展示随意生成评分。对于没有真实用户评价的页面，强行添加 AggregateRating 并不是好的做法。
媒体类标记
VideoObject 适合视频教程、产品演示、课程视频、新闻视频等页面。它可以描述视频标题、缩略图、上传时间、时长、播放地址等信息。ImageObject 或图片元数据则更偏向图片版权、作者、授权方式等信息。
如果一个页面只是普通文章中插入了一张配图，通常不需要为每张图片都写复杂结构化数据；如果页面核心内容就是视频、图库、摄影作品或素材授权信息，媒体类标记才更有价值。
问答类标记
问答相关结构化数据容易被误用。Schema.org 中有 FAQPage、QAPage、Question、Answer 等类型，Google 搜索文档中也有面向特定问答、教育问答、讨论论坛等场景的结构化数据说明。
| 类型 | 适合内容 | 容易误用的地方 |
|---|---|---|
| FAQPage | 页面列出多个常见问题，并由站点自己给出答案 | 把普通正文的小标题强行包装成问答 |
| QAPage | 一个问题下面有用户回答、最佳答案或多条答案 | 把官方 FAQ 页面误标成社区问答页 |
| DiscussionForumPosting | 论坛、社区、讨论帖等用户生成内容 | 把普通文章评论区当成论坛主题页 |
判断这类标记是否适合，关键看页面形态。如果页面是“站点自己整理的问题与答案”，更接近 FAQ；如果页面是“用户提出问题，其他用户回答”，才更接近 Q&A；如果是多用户围绕主题持续讨论，则更接近论坛内容。
行业类标记
有些结构化数据并不适合所有网站，但在特定行业很重要。例如 Event 适合演出、展会、讲座、线下活动；JobPosting 适合招聘详情页；Recipe 适合菜谱；Course 适合课程列表；Dataset 适合数据集说明页面；SoftwareApplication 适合软件或应用介绍页。
| 类型 | 页面例子 | 重点字段 |
|---|---|---|
| Event | 一场线下技术沙龙报名页 | 活动名称、时间、地点、状态、票务信息 |
| JobPosting | 公司招聘某个岗位的详情页 | 职位名称、工作地点、薪资、发布日期、雇主信息 |
| Recipe | 一道菜的制作教程 | 食材、步骤、耗时、图片、营养信息 |
| Course | 在线课程或培训课程列表 | 课程名称、提供方、描述、课程链接 |
| Dataset | 开放数据集介绍页 | 数据集名称、描述、创建者、下载方式 |
| SoftwareApplication | 软件、插件、App 介绍页面 | 软件名称、系统平台、应用类别、评分、下载信息 |
行业场景类结构化数据通常有更严格的字段要求。比如职位页需要真实岗位信息，活动页需要明确时间和地点，软件页需要避免虚构评分和下载数据。字段越贴近交易、招聘、评价，越要注意准确性。
类型怎么选
结构化数据的选择顺序应该是：先判断页面主内容，再选择最贴近的 Schema 类型，之后补充必要属性。不要反过来因为想要某种搜索展示，就把页面标记成不相干的类型。
文章页：优先考虑 Article、BlogPosting，并可配合 BreadcrumbList。
产品页：优先考虑 Product、Offer，真实存在评价时再考虑 Review 或 AggregateRating。
企业介绍页：优先考虑 Organization，线下门店页面再考虑 LocalBusiness。
视频为主的页面：优先考虑 VideoObject，而不是只把视频当作文章附件。
招聘页：使用 JobPosting，而不是普通 Article 代替。
课程列表页：考虑 Course 或 ItemList，而不是把每个课程都写成普通文章。
一个页面也可以有多个结构化数据对象。例如一篇菜谱文章可以同时包含 Recipe、VideoObject、BreadcrumbList；一个软件介绍页可以包含 SoftwareApplication 和 BreadcrumbList。但每个对象都应当对应页面上真实可见的信息。
常见误区
结构化数据更像“语义说明书”，不是搜索排名开关。即使代码通过测试，也不代表搜索结果一定出现富媒体展示。搜索平台还会结合页面质量、内容相关性、设备、地区、查询意图以及具体功能支持情况来决定是否展示。
实施时可以用几个问题自查：
页面上的用户是否能看到结构化数据描述的信息？
所选类型是否准确代表页面主体，而不是为了蹭某种展示？
必填字段是否完整，推荐字段是否尽量补充？
价格、评分、库存、日期等信息是否会同步更新？
页面是否允许搜索引擎抓取，没有被 robots、noindex 或登录限制挡住？
添加后是否用富媒体结果测试工具或站长平台检查错误？
对普通内容站来说，Article、BreadcrumbList、Organization 通常是更基础的起点；对电商和软件站来说，Product、SoftwareApplication、Review 相关标记更值得关注；对本地服务、课程、招聘、活动类网站，则应围绕具体业务页面选择类型。结构化数据做得好，重点不在数量多，而在类型准确、字段真实、维护稳定。
精彩评论