Schema 不是排名按钮。
结构化数据的主要作用，是帮助搜索引擎更明确地理解页面里的实体、内容类型和关系。它可以让页面具备某些搜索展现资格，但不保证排名提升，也不保证一定展示富结果。
文章页做 Schema，先问一个问题：这段标记是否真实代表页面上用户可见的内容？
文章页最常见的三类结构化数据
1. Article / BlogPosting
适合新闻、博客、教程、指南类页面。
它可以帮助 Google 理解标题、作者、发布时间、更新时间和图片等信息。Google 的 Article 文档也说明，添加 Article 标记可以更明确地告诉 Google 内容是什么，但 Google News 等展示并不要求必须有 Article 标记。
常见字段包括：
- headline；
- image；
- datePublished；
- dateModified；
- author；
- publisher；
- mainEntityOfPage。
2. BreadcrumbList
适合有清晰层级的网站。
比如：首页 > 文章 > 技术 SEO > 文章页 Schema 怎么做。
Breadcrumb 的价值在于表达站点层级和页面位置。它不应该和页面实际导航冲突。
3. FAQ
FAQ 只适合页面上真实存在问答，并且这些问答确实服务页面主题的情况。
不要为了 Schema 硬造 FAQ。Google 已经减少 FAQ rich result 的展示，普通内容站不应该把它当成可预期的流量增长手段。
先遵守通用结构化数据原则
Google 的结构化数据通用指南有几个关键点：
- 标记内容必须和页面可见内容一致；
- 不要标记无关或误导性内容；
- 图片 URL 要可抓取、可索引；
- 可以用 Rich Results Test 和 URL Inspection 检查技术问题；
- 即使标记正确，也不保证展示富结果；
- 结构化数据问题可能导致富结果资格受影响。
这些原则比“加哪种 Schema”更重要。
文章页 Schema 决策表
| 页面情况 | 推荐标记 | 不推荐 |
|---|---|---|
| 普通教程或博客文章 | Article 或 BlogPosting | 用 Product、Recipe 等不相关类型 |
| 有清晰栏目层级 | BreadcrumbList | 面包屑和页面导航不一致 |
| 页面有真实短问答 | 可以考虑 FAQ | 为了富结果硬塞问答 |
| 页面只有一个定义 | Article 即可 | 加多种无关 Schema |
| 多个结构化数据共存 | 用 @id 或嵌套表达关系 | 每个实体互相孤立 |
最容易犯的错误
以为加了 Schema 就会涨排名
结构化数据不是内容质量的替代品。页面本身仍然要满足搜索意图。
标记页面上看不到的内容
如果 JSON-LD 里写了 FAQ、评分、作者信息，但页面上用户看不到，这就是风险。
类型选择过度
不是越多类型越好。文章页的主类型通常是 Article 或 BlogPosting。其他类型要服务真实页面内容。
图片不可访问
Article 的 image 字段如果指向被 robots、noindex、鉴权或错误路径阻挡的图片，搜索引擎就无法使用。
一个实施流程
- 确认页面主类型：文章、产品、工具、专题还是 FAQ；
- 列出页面上用户可见的实体和信息；
- 选择最具体且最相关的 Schema 类型；
- 用 JSON-LD 实现；
- 确认 canonical、标题、日期、作者和页面内容一致；
- 用 Rich Results Test 验证技术错误；
- 上线后用 URL Inspection 观察 Google 是否能抓取；
- 不把富结果展示当作唯一成功指标。
三类读者的盲点
SEO 新手常见盲点是以为加 Schema 就能涨排名。
有一定经验的人会写 JSON-LD，但容易类型选择混乱，或者标记页面上不可见的内容。
更资深的人需要结合页面实体、富结果资格和内容真实性判断：哪些标记必要，哪些只是噪音，哪些可能带来结构化数据风险。