文章目录
-
- 一、入门回顾：最基础的 Product Schema 能做什么
- 二、组合式 Schema 嵌套：把一个页面变成多个展示卡片
- 三、变体产品的 Schema 策略：一个模型处理所有颜色和尺寸
- 四、评价 Schema：慎用虚高的评分数据
- 五、电商 Schema 常被忽略的字段
- 六、B2B 产品页的 Schema 差异
- 七、GSC 验证与监控
- 结语
Product Schema 是电商站用得最多的结构化数据，但大多数站点只用到了最基础的三件套：名称、价格、库存。搜索引擎结果里别人家的产品页能展示评分、配送时效、退换政策、价格范围——你的产品页只有一行蓝字标题。
这不是 Google 偏袒竞品，是你的 Schema 只填了必填项，没填加分项。
本文不重复 Product Schema 的入门教程，专注于三个方向：组合式 Schema 嵌套、B2B 产品的独有标签，以及大部分站点 Schema 审计中暴露的高频错误。
意图判断准了，内容做对了，排名和转化会同时往上涨；意图判断偏了，排名再高的流量都是噪音。（注：此句为本系列另一篇的收尾，这里替换为核心判断——）
Schema 标记的内容必须是页面上真正有的、对用户做购买决策有帮助的、且不和页面可见内容矛盾的。
一、入门回顾：最基础的 Product Schema 能做什么
一个最小化的 Product Schema 只包含五件事——名称、图片、描述、价格和库存状态。下面用表格拆解它的字段构成：
| @type | 类型声明 | Product |
| name | 产品名称 | 产品名称 |
| image | 产品图片 URL | 产品图片URL |
| description | 产品简述 | 产品简述 |
| offers.@type | 报价节点类型 | Offer |
| offers.price | 价格 | 99.00 |
| offers.priceCurrency | 货币类型 | USD |
| offers.availability | 库存状态 | InStock |
这决定了产品页能否在搜索结果中显示三个关键信息：产品标题、价格、库存状态。
不加 Schema，Google 仍能从页面中提取这些信息——但提取出来的内容格式和完整性完全由 Google 决定，你无法控制它展示哪一段文字做描述、会不会把价格读错、怎么判定库存状态。
二、组合式 Schema 嵌套：把一个页面变成多个展示卡片
大多数站点的产品页上 Schema 只有 Product 一个节点，但一个页面可以同时部署多个 Schema 节点，彼此用 @id 相互引用，构成一个结构化数据网络。这能让搜索结果中同时出现多个显示面板。 以下是四种最常见的组合方式：
| Product + FAQPage | FAQ 用 FAQPage 单独声明，与 Product 用 @id 互引 | 产品信息下展开三个可点开的问题，适合回答"最小起订量"“是否支持定制”“交期多久” |
| Product + Article | Article 用 about 字段关联 Product | 同时显示产品卡和信息文章卡，适合带选购指南的长文案页 |
| Product + BreadcrumbList | 面包屑 Schema 独立于 Product 单独声明 | 决定结果地址栏里的面包屑是乱的还是清晰的 |
| Product + VideoObject | 视频用 VideoObject 标记并关联产品节点 | 出现视频缩略图，点击率明显高于纯文字结果 |
@id 引用机制示例（以 Product + FAQ 为例，节点间通过 #product 互相关联）：
- Product 节点声明 "@id": "#product"
- FAQPage 独立声明，两者处于同一 JSON-LD 块内，Google 据此理解"这是同一页面的不同结构化信息"
在产品页加 FAQ Schema 之前先确认一个问题：你的产品页上真的有这些 FAQ 的可见文字吗？Schema 标记的内容必须是页面上真实展示的，不能只埋在代码里。
about 字段建立了 Article 和 Product 之间的关联——告诉 Google"这篇文章讨论的是这个产品"，这比两个独立节点更有语义准确度。
BreadcrumbList 的最后一个位置不加 item 字段——当前页面不需要链接到自身。
三、变体产品的 Schema 策略：一个模型处理所有颜色和尺寸
变体产品（多颜色、多尺寸、多规格）是 Schema 最容易出错的地方。
| 错误：每个变体独立 Product | 500 个变体 = 500 个 URL | 重复内容问题 |
| 正确：一个 Product + offers 数组 | 所有变体共享一个产品主体节点，差异放各自 Offer | —— |
| 不同价格：AggregateOffer | 标 lowPrice / highPrice | 结果显"$79.00 – $119.00" |
| 正确做法的字段结构： | ||
| 字段 | 说明 | |
| — | — | |
| @type | Product（单一节点） | |
| name | 产品名，如 Classic Running Shoe | |
| offers[] | 数组，每个变体一个 Offer | |
| offers[].sku | 变体编号，如 SHOE-RED-8 | |
| offers[].price | 该变体价格 | |
| offers[].availability | 该变体库存，可个别为 OutOfStock |
变体的差异信息（颜色、尺寸、价格、库存）放在各自 Offer 的独立字段中，而非新建独立页面。
价格区间用 AggregateOffer：
| @type | AggregateOffer | —— |
| lowPrice | 最低价 | 79.00 |
| highPrice | 最高价 | 119.00 |
| priceCurrency | 货币 | USD |
| offerCount | 报价数量 | 5 |
Google 在搜索结果中显示"$79.00 – $119.00"——用户直接看到价格区间，点进来的已经接受了价格范围，跳出的概率更低。
四、评价 Schema：慎用虚高的评分数据
AggregateRating 和 Review 是最能提升搜索 CTR 的 Schema 类型——星星评分在搜索结果中是视觉磁铁。也是被滥用最多的。
基本完整性要求： 如果你要标记评分数据，必须同时提供 ratingCount（有多少条评价）和 ratingValue（平均分是多少）。缺失任何一个字段，Google 都不太可能将其展示为富文本样式。
三个关键注意事项：
评价必须是真实收集的且对应这个产品。 用全站平均评分来标记所有产品、直接把别的站点的评分值写进自己站点的 Schema——如果页面内容中没有这些评分数据，这就是误导性标记，属于违规操作。Google 在做"结构化数据与页面内容一致性校验"时，如果发现 Schema 里的评分和页面上实际展示的评价不一致，整个 Schema 可能被忽略。
评分数据放在独立页面元素中。 最佳实践是把评分数据放在页面可见区域的独立模块中（一个带评价数据的 div），Schema 在 JSON-LD 中同步声明。两者互相印证，Google 的一致性校验直接通过。
内页评价 vs 汇总评分的区别。 产品页应该展示这个产品的独立评分，不是全站汇总评分。aggregateRating 对应的评价数据应该只反映这个产品的真实评价——用全站评分来代替特定产品评分会造成用户评估偏差。
五、电商 Schema 常被忽略的字段
下面五个字段，九成站点没认真填，却最能拉开搜索结果的丰富度。
| shippingDetails | 在 Offer 节点附运送信息（费率+时效） | 结果展示"最快 X 日送达"或"满 $X 免运费" |
| hasMerchantReturnPolicy | 退换政策节点 | 展示"30 天免费退换"，首次购买强点击信号 |
| brand | 用 Brand 节点（带 logo），非字符串 | 强化品牌识别 |
| mpn / gtin | 制造商零件编号 / 全球贸易项目编号 | 电子和标品靠它匹配 Google Shopping |
| category | 用 Google 标准品类编号 | 归入 Shopping 正确品类 |
shippingDetails 字段结构：
| @type | OfferShippingDetails | —— |
| shippingRate.value | 运费 | 5.00 |
| shippingRate.currency | 货币 | USD |
| deliveryTime.handlingTime | 处理时间（min/max） | 0 / 1 |
| deliveryTime.transitTime | 运输时间（min/max） | 2 / 4 |
hasMerchantReturnPolicy 字段结构：
| returnPolicyCategory | 退货窗口类型 | MerchantReturnFiniteReturnWindow |
| merchantReturnDays | 天数 | 30 |
| returnMethod | 退货方式 | ReturnByMail |
| returnFees | 退货运费 | FreeReturn |
brand 的正确写法：
| 错误（字符串） | brand: "品牌名称" |
| 正确（节点） | brand: { "@type": "Brand", "name": "品牌名称", "logo": "Logo图片URL" } |
category 用 Google 产品类别编号而非自定义分类词，例如 "Apparel & Accessories > Clothing > Outerwear > Coats & Jackets" 而非 "jackets"。
六、B2B 产品页的 Schema 差异
B2B 产品页的 Schema 不能照搬 B2C 的逻辑。B2B 采购方在意的最小起订量（MOQ）、交货期、定制能力、认证标准——在 Schema 中需要用 additionalProperty 扩展来表达。
| 最小起订量 | 500 件 |
| 认证标准 | ISO 13485, FDA |
如果 B2B 产品有价格但无固定价格（需询价），更安全的做法是不在 Schema 中给具体 price 值，只在描述中注明"价格根据数量、规格不同，请联系获取报价"。一个不准确的固定价格 Schema 反而会引发用户不满并导致高跳出率信号。
B2B 采购决策链中有多个角色——产品页面对的不仅有终端用户，还有采购经理、工程师、财务审核人。
description 字段在 Schema 中不仅用于搜索展示，Google 还会用它参与对页面主题的理解。描述应该兼顾不同角色的信息需求，而不是只写终端用户的卖点。
七、GSC 验证与监控
Schema 实施后直接进入 Search Console → “增强功能”，可以按产品类型查看验证状态：
| 有效 | 通过格式校验和内容一致性校验，可展示为增强搜索结果 |
| 有效，但有警告 | 基本功能不受影响，但某些增强（价格、库存、评分星星）不会出现 |
| 错误 | Schema 存在严重问题，整个增强展示都不会显示 |
触发错误的常见原因按频率排序：
- 缺少必填字段
- 价格格式不对（price: "99" 是错的，必须包含货币类型声明且与价格数值一一对应）
- 缺少货币字段
- Schema 和页面可见内容不匹配（Schema 标记的是版本号但页面上只有产品型号）
- 节点嵌套关系错误导致 Google 无法理解产品树状信息结构
结语
产品页 Schema 的优化没有止境——你永远可以在细节层再加一个字段、再嵌套一个节点让搜索结果更丰富。但核心原则不变：
Schema 标记的内容必须是页面上真正有的、对用户做购买决策有帮助的、且不和页面可见内容矛盾的。
满足这三个条件，每多加一个字段，都是为搜索点击率增加一个被打开的理由。
