FAQPage 结构化数据：Schema.org 写法与 Google 展示现状

FAQPage 曾经是 SEO 圈很爱用的结构化数据，因为它可能在 Google 搜索结果中展示可折叠问答。但这个前提已经变了：Google 在 2026 年 5 月宣布 FAQ 富媒体结果不再显示，并在 2026 年 6 月移除了 FAQ 富媒体结果文档。因此，这篇文章不会教你“抢 FAQ 富媒体展示”，而是讲清 FAQPage 作为 Schema.org 语义标记应该怎么正确使用，以及现在是否还值得做。

当前状态：Google 不再展示 FAQ 富媒体结果#

截至 2026 年 6 月，Google 官方更新日志明确说明：FAQ 富媒体结果功能不再出现在 Google 搜索结果中，相关文档也已移除。这意味着：

FAQPage 不应再被当作“获得 Google 折叠问答结果”的 SEO 手段。
Rich Results Test 和 Search Console 对 FAQ 的支持状态可能与过去不同。
如果页面本来就有真实 FAQ，仍可以用 Schema.org 的 FAQPage 描述它，但目标应是语义清晰，而不是追求搜索结果额外占位。

FAQPage 当前状态示意：页面可见常见问题可以用 Schema.org FAQPage 描述，但 Google 搜索不再显示 FAQ 富媒体结果 — FAQPage 仍是 Schema.org 类型，但不再对应 Google 搜索中的 FAQ 富媒体结果展示。

策略变化如果你的结构化数据工作只服务 Google 搜索富媒体结果，FAQPage 的优先级应明显下降。优先做 Article、BreadcrumbList、Product、Review、Video 等仍有明确搜索用途的类型。

FAQPage 是什么#

Schema.org 对 FAQPage 的定义是：一个展示一个或多个常见问题的网页。典型场景包括：

产品或服务帮助中心的常见问题页；
教程文章文末的“常见问题”区块；
政策、价格、配送、退换货等说明页；
活动报名页中的规则问答。

核心要求仍然是可见内容一致：JSON-LD 标记的每个问题和答案，都应该能在页面上被用户看到。

FAQPage 和 QAPage 的区别#

类型	适合场景	答案来源	不要用于
`FAQPage`	站点自己整理的一组常见问题	官方答案、编辑答案	用户自由回答的讨论页
`QAPage`	一个问题有多个用户回答的问答页	用户回答、社区回答	静态帮助文档和教程文末 FAQ

如果页面是“一个问题 + 多个用户回答 + 可能有投票或最佳答案”，那更接近 QAPage。FAQPage 更适合站点自己给出的标准答案。

完整 JSON-LD 示例#

下面是一个 Schema.org FAQPage 示例。注意：这不是保证 Google 富媒体展示的代码，而是描述页面上真实可见的 FAQ 内容。

faqpage-json-ld.html

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "结构化数据一定会带来富媒体结果吗？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "不会。结构化数据只是帮助搜索引擎理解页面，是否展示富媒体结果由 Google 根据功能支持、页面质量、政策和搜索场景决定。"
      }
    },
    {
      "@type": "Question",
      "name": "FAQPage 可以标记页面上没有显示的问题吗？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "不应该。结构化数据必须和页面可见内容一致，不能夹带用户看不到的问题和答案。"
      }
    }
  ]
}
</script>

字段怎么理解#

字段	含义	写法
`FAQPage`	当前页面是 FAQ 页面或含 FAQ 的页面	作为顶层对象
`mainEntity`	页面的主要问答列表	数组，包含多个 `Question`
`Question.name`	问题文本	与页面可见问题一致
`acceptedAnswer`	官方答案	一个 `Answer` 对象
`Answer.text`	答案内容	与页面可见答案一致，可包含必要 HTML

什么时候还值得使用#

现在判断 FAQPage 是否值得做，可以按这个优先级：

页面本来就需要 FAQ：用户确实有反复出现的问题，FAQ 能减少理解成本。
问答质量高：答案具体、准确、可验证，不是营销套话。
模板生成成本低：已有文章模板能自动同步文末 FAQ 和 JSON-LD。
不是为了 Google 展示：即使 Google 不展示 FAQ 富媒体结果，页面本身仍有价值。

如果你只是为了“多占搜索结果空间”而给每页硬塞 FAQ，现在已经没有必要。

本站这一页如何示范#

本页文末有四个可见的常见问题，页面源码里也有一段 FAQPage JSON-LD，二者一一对应。本站保留这种标记，是为了完整示范 Schema.org 语义写法，而不是承诺 Google 会展示 FAQ 富媒体结果。

本站示范MagicSEO 后续如果继续在文章页输出 FAQPage，会把它标注为语义增强和内容结构示范，而不是富媒体结果增长手段。这比继续沿用过时的“FAQ 可以抢 SERP 空间”说法更准确。

如何验证#

用 Schema Markup Validator 验证 Schema.org 语法是否正确。
检查页面可见 FAQ 与 JSON-LD 中的 mainEntity 是否逐项一致。
不要再把 FAQPage 是否进入 Google 富媒体报告作为成功标准。
保留 Search Console 监控，但更关注页面索引、点击率和用户行为，而不是 FAQ 展示。

常见错误#

错误	为什么不对	修正
继续承诺 FAQ 富媒体展示	Google 已移除该功能	改为语义标记和内容结构说明
标记页面上没有的问题	违反可见内容一致原则	只标记用户能看到的 FAQ
把论坛问答标成 FAQPage	类型错配	用户回答页考虑 QAPage
每页硬塞模板化 FAQ	低价值、重复、对用户无帮助	只保留真实高频问题
答案过度营销	不解决问题，降低信任	直接回答问题，再给必要链接
JSON-LD 和文末 FAQ 不同步	信号不一致	用同一份内容源生成可见 FAQ 和标记

FAQPage 上线清单#

页面确实有用户可见的 FAQ 内容
不把 FAQPage 当成 Google 富媒体结果增长手段
每个 Question.name 与页面问题一致
每个 acceptedAnswer.text 与页面答案一致
FAQ 由站点提供官方答案，而不是用户讨论
不标记隐藏、虚构、重复或营销化问答
用 Schema Markup Validator 验证语法
页面继续以内容质量和用户帮助为核心
定期复核 Google 结构化数据政策变化

常见问题#

FAQPage 现在还能带来 Google 富媒体结果吗？

截至 2026 年 6 月，Google 已移除 FAQ 富媒体结果功能和相关文档，并说明 FAQ 富媒体结果不再显示在 Google 搜索结果中。因此，不应再把 FAQPage 当成争取 Google 折叠问答展示的手段。它仍然可以作为 Schema.org 语义标记，用来描述页面上真实可见的 FAQ 内容。

FAQPage 和 QAPage 有什么区别？

FAQPage 适合站点自己提供一组问题和官方答案，例如产品帮助页、政策说明、教程文末 FAQ。QAPage 适合一个问题有多个用户回答、投票或互动的问答页，例如论坛和问答社区。不要把用户讨论页错误标记成 FAQPage。

页面只有文末几个常见问题，可以加 FAQPage 吗？

可以，但前提是这些问答对用户可见、与页面主题直接相关、答案由站点提供并且内容真实。不要为了结构化数据而批量制造重复、营销化或页面上不存在的问题。

还值得继续保留 FAQPage 标记吗？

如果页面确实有高质量、可见的 FAQ，保留 FAQPage 语义标记没有问题，但不要把它列为获取 Google 搜索富媒体结果的重点工作。优先级应低于 Article、BreadcrumbList、Product、Review 等仍有明确 Google 搜索用途的类型。