Product、FAQPage、HowTo怎么正确使用

拿到 Product、FAQPage、HowTo 三段代码模板，先别急着全部复制进网站。

Product（产品信息）、FAQPage（常见问题页面）和 HowTo（操作教程），都是 Schema.org 定义的结构化数据类型。所谓结构化数据，就是用一组标准字段告诉搜索引擎：这个页面介绍的是什么，页面中哪些内容属于产品名称、价格、问答或操作步骤。

JSON-LD 是编写结构化数据的一种常用格式。它通常以一段代码的形式放进网页源代码，但只能标记页面已经提供的信息，不能代替页面正文。

如果页面没有展示价格、库存、评价、问答、操作步骤或耗时，就不能只在 JSON-LD 中补写这些内容。模板包含多少字段并不重要，真正决定该用哪类结构化数据的，是当前页面写了什么。

这三类结构化数据的用途和 Google 目前的支持情况也不相同：

类型	适合什么页面	主要标记什么	Google 目前的支持情况
Product	单个商品或产品详情页	名称、图片、型号、价格、库存等真实信息	仍支持商品相关搜索功能
FAQPage	展示多组站方固定问答的页面	页面上完整可见的问题和答案	FAQ 富结果通常只向权威政府和健康网站展示
HowTo	有明确操作顺序的教程	步骤、工具、材料和耗时	HowTo 富结果已经停用

这里所说的“富结果”，是指搜索结果中可能额外出现的商品价格、库存、问答等扩展信息。

正确的使用顺序是：先检查页面内容，再选择结构化数据类型，最后填写字段并完成验证。

写代码前，先确认这5件事

1. 只标记页面上真实可见的内容

商品价格、库存、FAQ 答案和操作步骤，都不能只存在于 JSON-LD 中。用户在页面上能看到什么，结构化数据才能标记什么。

FAQ 可以使用折叠组件展示，但用户展开后必须能够看到完整的问题和答案。

2. 不存在或无法确认的字段，直接删除

模板中的示例价格、网址、评分、库存和日期，上线前都必须替换。

如果页面没有对应信息，就删除相关字段。不要保留示例值，也不要为了让验证工具少报一条警告而编造数据。

3. 使用正确的 JSON-LD 格式

JSON-LD 应放在下面这组 HTML 标签中。HTML 指网页源代码使用的标记语言。

<script type="application/ld+json">

Google 通常推荐使用 JSON-LD。但格式和放置位置正确，只能说明代码写法没有明显问题，不能证明代码中的价格、库存、评价等内容真实。

4. 分清 Schema.org 规范与 Google 搜索功能

Schema.org 负责定义可以使用哪些结构化数据类型和字段，Google 则决定哪些类型能够触发搜索结果中的扩展展示。

因此，代码符合 Schema.org 规范，不等于 Google 一定会展示富结果。

FAQPage 和 HowTo 仍是有效的 Schema.org 类型，但 Google 对相应富结果的支持已经发生变化。判断是否部署时，不能只看这个类型是否存在，还要看网站的使用目的和维护能力。

5. 验证代码后，还要检查实际抓取结果

先检查代码语法，再用对应工具验证。页面上线后，还要查看网页源代码和 Google 的网址抓取结果，确认：

• 网站模板没有转义或破坏 JSON-LD；
• 页面输出的是新版本代码；
• 缓存没有继续提供旧数据；
• Google 实际抓取到的内容与当前页面一致。

验证工具显示“有效”，只说明代码通过了对应规则，不代表 Google 一定会展示富结果。

Product：用于明确的商品或产品详情页

如果页面介绍的是一个可以明确识别的商品，可以从下面这份简化模板开始。

模板使用 offers 标记商品报价信息，没有加入评价字段，适合没有真实评分数据的商品页面。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://example.com/products/model-a#product",
  "name": "示例产品A",
  "image": [
    "https://example.com/images/model-a.jpg"
  ],
  "description": "用一句与页面一致的话说明产品用途和关键规格。",
  "sku": "MODEL-A-001",
  "brand": {
    "@type": "Brand",
    "name": "示例品牌"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/products/model-a",
    "priceCurrency": "CNY",
    "price": "999.00",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  }
}
</script>

上线前，至少要逐项检查并替换以下内容：

字段	含义
@id	当前产品对象的唯一标识
url	产品页面的网址
name	产品名称
image	产品图片地址
description	与页面一致的产品说明
sku	SKU，即用于识别具体商品的库存单位编号
brand	品牌名称
priceCurrency	价格使用的币种，CNY 表示人民币
price	页面实际展示的价格
availability	当前库存状态
itemCondition	商品状态，例如模板中的 NewCondition 表示新品

Google 的 Product snippet，也就是商品摘要搜索展示，要求提供 name，同时要求 review、aggregateRating、offers 至少有一项。上面的模板选择了 offers。

如果页面属于可以直接购买的商品页，还应对照 Merchant listing，也就是商家商品列表展示的相关文档，判断是否需要补充其他字段。

只有页面真实展示、来源可以核验的评价或汇总评分，才能加入 review 或 aggregateRating。没有真实评价就删除这些字段，不要编造评分。

价格、币种和库存状态也必须与页面可见内容一致。

没有价格的 B2B 产品页怎么办

B2B 指企业面向其他企业开展的业务。

没有价格的 B2B 产品页，仍然可以使用 Schema.org 的 Product 类型描述产品。但它是否满足 Google 某类商品富结果的要求，需要根据 Product snippet 或 Merchant listing 的具体规则判断。

页面没有真实价格时，不要用虚构价格填充 offers。

FAQPage：用于页面上的站方固定问答

FAQ 是“常见问题”的英文缩写。FAQPage 适合标记由网站提供的多组固定问答，每个问题和答案都要完整展示在页面上，不能只写进结构化数据。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "产品A支持哪些使用场景？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "产品A适用于场景一和场景二，具体限制以页面规格表为准。"
      }
    },
    {
      "@type": "Question",
      "name": "产品A如何申请售后？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "请在订单页提交售后申请，并上传订单号和问题说明。"
      }
    }
  ]
}
</script>

Question.name 要对应页面上的完整问题，acceptedAnswer.text 要对应页面上的完整答案。页面可以使用折叠组件，但用户必须能够查看全部内容。

如果一个页面只围绕一个问题展开，并允许用户提交多个答案，就不属于这里所说的站方固定问答。这类页面应另行查看 QAPage，也就是多人问答页面结构化数据的相关规则。

还要注意，Google 从2023年起，通常只向权威政府和健康网站展示 FAQ 富结果。

普通企业网站仍然可以保留与页面一致、维护成本较低的 FAQPage 标记，但不能把它当作稳定的搜索展示入口，更不能承诺添加代码后一定出现问答富结果。

HowTo：用于有明确顺序的操作教程

HowTo 适合具有明确操作顺序的教程。步骤、工具、材料和耗时，都要与页面正文一一对应。

下面的模板以30分钟、两项材料、一件工具和三个步骤为例。页面正文必须同步展示这些信息。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "如何安装示例产品A",
  "description": "完成安装前检查、固定和通电测试。",
  "totalTime": "PT30M",
  "supply": [
    {"@type": "HowToSupply", "name": "安装螺丝"},
    {"@type": "HowToSupply", "name": "绝缘胶带"}
  ],
  "tool": [
    {"@type": "HowToTool", "name": "十字螺丝刀"}
  ],
  "step": [
    {
      "@type": "HowToStep",
      "name": "检查配件",
      "text": "核对主机、螺丝和说明书是否齐全。",
      "url": "https://example.com/guides/install-model-a#step1"
    },
    {
      "@type": "HowToStep",
      "name": "固定设备",
      "text": "按说明书标注的位置固定设备并检查松动。",
      "url": "https://example.com/guides/install-model-a#step2"
    },
    {
      "@type": "HowToStep",
      "name": "完成测试",
      "text": "通电后按页面检查表完成首次运行测试。",
      "url": "https://example.com/guides/install-model-a#step3"
    }
  ]
}
</script>

totalTime 使用 ISO 8601 时长格式。这是一套通用的日期和时间表示标准，其中30分钟写作 PT30M。

步骤名称、步骤说明和锚点网址，都要与页面内容对应。锚点网址是可以直接跳转到页面中某个具体步骤的链接。

页面没有材料或工具时，应删除 supply 或 tool 等相应字段。

Google 已经停止展示 HowTo 富结果，Rich Results Test（富结果测试工具）也不再支持这项搜索功能。因此，部署 HowTo 的理由不应是等待 Google 展示步骤卡片，而应是让仍然识别 Schema.org 规则的系统更清楚地理解教程内容及其组成部分。

如果网站没有持续维护 HowTo 数据的能力，只保留结构清楚的网页步骤也可以。

三类结构化数据能不能放在同一页

可以，但页面必须确实同时提供这三类内容。

例如，一个产品详情页同时展示了具体商品、多组站方 FAQ 和完整安装教程，就可以使用 @graph 把多个数据对象组织在同一段 JSON-LD 中，也可以把不同类型拆成多个 JSON-LD 代码块。

无论采用哪种写法，都要满足三个条件：

1. 每个数据对象对应的主体明确；
2. @id 和页面网址对应正确；
3. 结构化数据与页面可见内容一致。

关键不在于代码块有几个，而在于每个对象是否真实、对象之间的关系是否清楚。不能因为手里有三份模板，就把三类结构化数据直接放进全站所有页面。

检查项	Product	FAQPage	HowTo
对应主体	一个具体商品	多组站方问答	一个完整操作过程
页面必须展示	名称、价格、库存等实际填写的信息	每个问题和答案	步骤、工具、材料、耗时等实际填写的信息
最容易出现的虚假字段	评分、评价、价格	页面不存在的答案	不存在的步骤和耗时
Google 目前的支持情况	仍支持商品相关功能	富结果通常限权威政府和健康网站	富结果已经停用

上线前，按这个顺序验证

第一步：检查 JSON 语法

先用 JSON 解析器检查括号、逗号、引号等语法问题，确保代码能够正常读取。JSON 解析器就是检查这类文本代码能否被程序正确识别的工具。

第二步：检查 Schema.org 规范

使用 Schema.org Validator（Schema.org 验证器）检查类型、字段和嵌套关系是否符合 Schema.org 规范。嵌套关系指一个数据对象被放在另一个对象内部时，两者的从属关系是否正确。

第三步：检查 Google 支持的搜索功能

Product 可以使用 Rich Results Test，并根据 Product snippet 或 Merchant listing 的具体使用场景处理错误。

FAQPage 是否显示富结果，要考虑 Google 目前的展示限制。HowTo 已不再属于 Rich Results Test 支持的搜索功能。

第四步：检查 Google 实际抓取的版本

页面上线后，使用 URL Inspection（网址检查工具）查看 Google 抓取到的内容，确认它读取的是新版本，而不是被网站模板破坏的代码或缓存中的旧数据。

需要再次说明：验证通过，不等于 Google 一定展示富结果。实际展示还会受到页面质量、展示资格、抓取状态、用户搜索内容和对应搜索功能状态的影响。

同样，HowTo 不再出现在 Google 富结果测试的支持项目中，也不代表 Schema.org 删除了 HowTo 类型。Schema.org 是否保留某个类型，与 Google 是否支持相应富结果，是两个不同的问题。

5个容易误判的问题

1. Product 必须同时填写 offers、review 和 aggregateRating 吗

不必须。

Product snippet 要求提供 name，并要求 offers、review、aggregateRating 至少有一项。页面上有什么真实信息就写什么，没有真实评价就不要补写。

2. 普通企业网站还要不要使用 FAQPage

可以保留与页面一致、维护成本较低的 FAQPage。

但 Google 的 FAQ 富结果通常只向权威政府和健康网站展示，普通企业网站不能把它视为稳定的富结果入口。

3. HowTo 富结果停用后，HowTo 还有没有用

Google 的 HowTo 富结果已经停用，但 Schema.org 仍然保留 HowTo 类型。

是否继续部署，应根据其他使用方和网站的维护能力判断，不应再把 Google 步骤富结果作为主要理由。

4. 三种结构化数据能不能写进同一个 JSON-LD

可以使用 @graph 把多个对象放在同一个 JSON-LD 代码块中，也可以拆成多个代码块。

真正需要检查的是对象关系、@id、网址，以及每项数据能否在页面内容中找到对应信息。

5. 为什么验证通过后仍然没有富结果

因为验证通过只说明当前代码符合对应工具的规则，不代表 Google 必须展示。

页面质量、展示资格、抓取状态、用户搜索内容和对应搜索功能的当前状态，都可能影响最终结果。

最后只看三个判断标准

Product、FAQPage 和 HowTo 不是三份复制后就能直接使用的通用代码。每个页面是否需要部署、应该填写哪些字段，都要回到页面本身判断。

上线前只问三件事：

1. 页面是否真的提供了这些内容？
2. 结构化数据是否与用户看到的内容一致？
3. 网站是否有能力持续维护这些字段？

三项都能确认，再部署对应的结构化数据。缺少真实内容时，删除字段或暂不使用，都比把示例数据直接上线更合适。

公开资料入口

• Google Product structured data：https://developers.google.com/search/docs/appearance/structured-data/product
• Google Product snippet：https://developers.google.com/search/docs/appearance/structured-data/product-snippet
• Google FAQ 与 HowTo 变更说明：https://developers.google.com/search/blog/2023/08/howto-faq-changes
• Schema.org Product：https://schema.org/Product
• Schema.org FAQPage：https://schema.org/FAQPage
• Schema.org HowTo：https://schema.org/HowTo