结构化数据实战扩展：Google 当前还支持哪些类型，以及如何选型
结构化数据实战扩展：Google 当前还支持哪些类型，以及如何选型
这是“SEO教程”系列第 13 课。前一课我们已经讲了 JavaScript SEO，这一课回到结构化数据，但不是重复讲 FAQ / Product / Article / Breadcrumb，而是扩展到 Google Search 当前公开支持的更完整类型，并讲清楚：面对不同网站类型，应该怎么选，哪些值得优先做，哪些不要为了“看起来高级”乱上。
先给结论：Google 支持的结构化数据已经不只是 FAQ、Product、Article、Breadcrumb
如果你只接触过中文 SEO 的常见实务，很容易以为 Google Search 里最常用的结构化数据只有：
- FAQPage
- Product
- Article
- BreadcrumbList
这些当然仍然重要，但根据 Google Search Central 最新的 Structured data markup that Google Search supports，Google 当前公开支持的类型已经明显更多，包括：
- Article
- Breadcrumb
- Carousel
- Course list
- Dataset
- Discussion forum
- Education Q&A
- Employer aggregate rating
- Event
- FAQ
- Image metadata
- Job posting
- Local business
- Math solver
- Movie
- Organization
- Product
- Profile page
- Q&A
- Recipe
- Review snippet
- Software app
- Speakable
- Subscription and paywalled content
- Vacation rental
- Video
但这不意味着：
你的站点应该把所有类型都配上
真正正确的思路应该是：
先看页面本质是什么
再看 Google 对这类页面支持什么
最后判断值不值得维护
一、结构化数据选型的正确顺序
结构化数据最容易犯的错误，是从“我想要什么富结果”出发，而不是从“页面是什么”出发。
更合理的顺序是：
第一步：判断页面主任务
例如：
- 是内容页？
- 是商品页？
- 是本地商家页？
- 是课程列表页？
- 是职位发布页？
- 是视频页？
第二步：判断页面可见内容是否真的匹配
Google 在 General structured data guidelines 里强调：
结构化数据必须是页面可见内容的真实表达
所以：
- 页面没有 FAQ，就不要硬写 FAQPage
- 页面不是商品详情，就不要硬写 Product
- 页面不是文章，就不要乱挂 Article
- 页面没有层级导航，就不要伪造 BreadcrumbList
第三步：再看是否值得维护
不是所有支持的类型都值得你投入。
例如对大多数中文企业站来说，真正长期高价值的通常还是：
- Article
- BreadcrumbList
- Product
- Organization
- LocalBusiness
- FAQPage
- Review / Rating 相关
而像：
- Course list
- Employer aggregate rating
- Math solver
- Vacation rental
- Speakable
这类要看网站类型才值得做。
二、哪些类型最值得大多数站点优先做
1. Article
适合：
- 博客文章
- 教程页
- 行业分析页
- 新闻 / 专题内容页
价值：
- 帮搜索系统理解这是内容型页面
- 强化标题、作者、时间、发布方等信息
- 对教程站、内容站、品牌博客非常实用
2. BreadcrumbList
适合：
- 几乎所有有层级结构的网站
- 博客文章页
- 分类页
- 商品页
- 文档页
价值：
- 帮搜索系统理解页面层级
- 也是最稳定、最不容易乱用的一类结构化数据
3. Product
适合：
- 电商商品页
- SaaS 套餐页
- 课程销售页
- 有明确价格、库存、购买动作的页面
价值：
- 把商品/服务和价格、可购买性绑在一起
- 对电商和强商业页价值很高
4. FAQPage
适合：
- 帮助中心
- 售后政策页
- 商品或服务页中的真实 FAQ 区块
价值：
- 强化问答结构
- 对用户疑虑页面很有帮助
但要注意：FAQ 的展示资源位并不是无限开放，不能把它当成万能流量捷径。
5. Organization / LocalBusiness
适合：
- 企业官网
- 品牌站
- 本地服务站
- 线下门店业务
价值：
- 强化组织、品牌、联系方式、营业信息等实体信息
- 对本地业务尤其重要
三、不同网站类型优先做什么
电商网站
优先考虑：
- Product
- BreadcrumbList
- Review snippet
- Organization
- FAQPage（仅当页面真有 FAQ）
很多电商网站最容易犯的错是：
- 类目页乱写 Product
- 商品没价格 / 库存也硬写 Offer
- 评价是假的或前端看不到
电商示例 JSON-LD
{
"@context": "https://schema.org",
"@type": "Product",
"name": "无线机械键盘 K87",
"brand": {
"@type": "Brand",
"name": "Acme"
},
"offers": {
"@type": "Offer",
"priceCurrency": "CNY",
"price": "599.00",
"availability": "https://schema.org/InStock"
}
}
这段代码解决的问题是：让搜索系统明确知道这个页面是一个具体商品，并且有价格和库存状态。前提是页面正文里真的有这些信息。
SaaS / 工具站
优先考虑：
- SoftwareApplication
- Article
- BreadcrumbList
- FAQPage
- Review snippet（如果确有真实评分）
很多 SaaS 页其实不适合 Product，而更适合：
- Software app
- Article
- FAQPage
尤其是功能介绍页、模板页、教程页，不要因为商业化就全都用 Product。
SaaS 示例 JSON-LD
{
"@context": "https://schema.org",
"@type": "SoftwareApplication",
"name": "Acme CRM",
"applicationCategory": "BusinessApplication",
"operatingSystem": "Web",
"offers": {
"@type": "Offer",
"price": "99",
"priceCurrency": "USD"
}
}
这段代码解决的问题是：告诉搜索系统这是软件应用，而不是泛泛的品牌页。
内容站 / 教程站
优先考虑：
- Article
- BreadcrumbList
- FAQPage
- Video（如果页面核心就是视频内容）
- Image metadata（如果图片版权和来源管理重要）
内容站不要为了“类型多”去乱加 Product。
企业官网 / B2B 网站
优先考虑：
- Organization
- BreadcrumbList
- Article
- LocalBusiness（如果有线下业务）
- FAQPage（针对售前/售后高频问题）
B2B 站最容易误用的是：
把解决方案页硬写成 Product，但页面根本没有标准价格或购买结构。
本地服务网站
优先考虑：
- LocalBusiness
- BreadcrumbList
- FAQPage
- Review snippet（真实评价前提下）
- Article（内容型页）
LocalBusiness 示例 JSON-LD
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "Acme Bike Repair",
"address": {
"@type": "PostalAddress",
"addressLocality": "Shanghai",
"streetAddress": "No. 88 Example Road"
},
"telephone": "+86-21-12345678",
"openingHours": "Mo-Sa 09:00-18:00"
}
这段代码解决的问题是：把本地服务页的营业信息、地址和联系方式结构化表达出来。
四、哪些支持类型大多数站点不要乱上
以下类型虽然 Google Search 支持，但不是大多数中文站点的常规优先项：
- Dataset
- Employer aggregate rating
- Education Q&A
- Course list
- Math solver
- Speakable
- Vacation rental
- Recipe
- Movie
这些类型并不是“没价值”，而是：
如果页面类型不匹配，强上只会制造噪音
五、FAQ、Product、Article、Breadcrumb 之外，哪些类型容易被忽略
1. Organization
很多企业官网和品牌站其实最应该先补 Organization，但往往反而忽略了。
适合：
- 品牌官网
- 企业主页
- 关于我们页
2. LocalBusiness
做本地业务的站，如果连 LocalBusiness 都没配，往往比“有没有 FAQPage”更值得优先处理。
3. SoftwareApplication
SaaS 站和工具站经常只会写 Product，但 SoftwareApplication 往往更贴切。
4. Video
如果页面的核心资产是视频，而不是附带一条视频，那 Video 比 Article 更重要。
六、不要为了 rich result 乱写结构化数据
Google 在结构化数据总指南里强调过几个核心原则：
- 结构化数据必须和页面可见内容一致
- 不要写误导性内容
- 不要写虚假评分 / 虚假评论
- 不保证加了结构化数据就一定会出 rich result
所以正确目标应该是：
先帮助搜索引擎正确理解页面
再把 rich result 视为可能收益，而不是必然回报
七、JSON-LD 仍然是首选
Google 目前支持：
- JSON-LD
- Microdata
- RDFa
但官方在 Introduction to structured data markup in Google Search 里仍明确推荐：
优先使用 JSON-LD
原因很实际：
- 更容易实现
- 更容易维护
- 不容易把页面 HTML 搞乱
- 更适合模板化输出
所以大多数站点没必要再回头用 Microdata 或 RDFa。
八、结构化数据上线前检查清单
上线前至少检查：
- 页面内容和 Schema 是否一致
- 是否用的是最贴切的类型，而不是最“热”的类型
- 是否写全必填字段
- 是否用了推荐字段提升质量
- 价格、库存、作者、时间、地址等是否和页面一致
- 是否是 JSON-LD
- 是否能通过 Rich Results Test
九、怎么配合本站工具做优先级判断
如果你要决定“先做哪些类型”，可以这样配合工具：
- 用 搜索意图挖掘机 判断页面意图，决定是内容页、问答页、商品页还是导航页
- 用 ROI 决策工作台 判断哪些高价值页面值得优先加结构化数据
- 用 AI 搜索避雷针 判断哪些内容页容易被 AI 摘要截流，再决定是否补 FAQ、Article 或更强结构化语义
十、结论：支持范围变多了，但选型反而更需要克制
Google 当前支持的结构化数据类型确实已经比大多数中文 SEO 圈日常讨论的丰富得多。
但真正成熟的做法不是：
支持什么就全上什么
而是：
页面是什么
→ 选最贴切的结构化数据
→ 保证内容一致
→ 优先做高价值模板
如果只能记住一句话，就记住：
结构化数据的价值不在于“种类多”，而在于“页面语义更清楚、实现更准确、维护更稳定”。
下一课我们继续：