一个商品有几种规格，标记里填了最低价、库存最多的一款，再配上页面默认图片。每个值都能在后台找到，组合起来却可能是一件客户根本买不到的商品。
Product写商品身份，Offer写同一件商品当前实际出售的条件。型号、价格、币种、库存和购买链接要对应同一规格。没有公开报价、真实评分或商品标识，就先核资料，不用虚构字段换取检测工具的绿色提示。
下面用一件蓝色M码T恤写出基础JSON-LD。商品、SKU、金额、图片与网址均为教学设定，不是真实销售报价，也不是本站的商品数据。
先固定哪件商品、哪一组出售条件
先把对象写清，而不是一上来搜最大的代码模板。本例给蓝色M码独立正式URL，页面展示这款的购买条件：
| 事实对象 | 本例值 |
|---|---|
| 商品与规格 | 基础款T恤，蓝色，M码 |
| 店内SKU | TS-BL-M |
| 当前商品售价 | 29.00 USD，不含另列运费 |
| 当前销售状态 | 新品，有货，可购买 |
| 正式页与图片 | 蓝M专属网址，以及这款的代表图片 |
假如黑色L码售价39美元、有货，也不能拿它的库存填蓝色M码。蓝M实际缺货时，“整个系列还有货”无法证明这一件可售。
还要区分标识：SKU是店内管理值，不自动等于GTIN条码或制造商料号。示例只有已确认SKU，没有GTIN，因此不编一串数字放进去。字段为空时，补资料的价值比补一个看似正式的号码大得多。
Product和Offer分别写什么
Product回答“是什么”：名称、图片、型号或SKU等商品信息。Offer回答“怎样出售”：当前价格、币种、可用性和相应购买地址。Offer不是只有打折才使用的对象，正常售价同样可以属于一项Offer。
Google的产品结构化数据说明区分产品摘要与商家信息等体验。能直接购买的页面和只有介绍或询价的页面，条件并不相同；不能把某张报告未出现直接翻译成代码一定出错。
基础实现先围绕一个明确商品和它的实际条件。Google各功能的必需、推荐字段可能不同，继续配置时应查看对应文档，而不是把网上的“必须有价格、五星、退货、运费”整包当成通用标准。
一件29美元商品的JSON-LD示例
代码只描述前面的蓝色M码
以下片段是教学输出。示例中的地址、图片、商品与售价都要按真实页面替换，不能直接发布为自己的商品标记。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"@id": "https://example.com/products/t-shirt-blue-m/#product",
"name": "基础款T恤 蓝色 M码",
"description": "蓝色M码基础款T恤，商品规格与购买条件见本页。",
"image": "https://example.com/images/t-shirt-blue-m.webp",
"sku": "TS-BL-M",
"color": "蓝色",
"size": "M",
"offers": {
"@type": "Offer",
"url": "https://example.com/products/t-shirt-blue-m/",
"price": "29.00",
"priceCurrency": "USD",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition"
}
}
</script>
offers里的条件属于外层那件蓝M商品。price只写金额，不把货币符号和“起”放进数值；priceCurrency说明币种，避免把29美元误读成其他货币。availability与itemCondition各表达销售可用性和新旧状态，不能混成一个开关。
示例没有加入评分、品牌故事、GTIN或促销截止日期，因为没有给出这些事实。它也没有穷尽每种商家体验的全部推荐信息。可以沿Google商家信息标记文档补充确实适用的运送、退货等资料；缺真实依据时，不照抄别人店铺的政策。
完整，并不意味着字段越多越好
本地解析检查可以发现JSON语法错误，却无法知道你填的29美元是否真实。最直接的人工核对是：在当前正式页上，这个SKU是否确实能按29美元的商品价格购买？图片和规格是否同一款？库存与销售条件是否相符？
如果代码填29，网页明明是39，语法再完整也不满足事实一致。若当前要查的是旧价从哪里来，可以接着看网页、标记与商品数据的价格排查，不必再复制一份正确价格的静态代码盖在旧输出旁边。
只有询盘，没有公开价格时怎么办
外贸产品页常见“提交需求后报价”。这不是零元商品。为了出现Offer而填price: 0，会把尚未确定的交易条件变成明确价格，读者与搜索系统都可能被误导。
先确认页面实际提供什么：是否有公开、适用的售价，能否直接完成购买，报价是否随配置和数量变化。没有就保留真实产品资料，按适用类型与功能要求判断是否具备对应资格。
Google对产品摘要与商家信息的要求不同。不能因为某页面有Product，就承诺一定显示价格或星级；也不能因为没有公开Offer，就虚构评价来满足另一组条件。
询盘页的正文承接仍然重要。让客户看到规格、适用范围、限制、需要提供哪些参数，以及如何进入询价，比一个不存在的零元价格更有用。这些信息可以参与页面SEO优化，但不应伪装成已存在的购买交易。
规格和促销变化，要跟着同一商品改
多个规格不能拼成一项不存在的Offer
先核目标URL打开后预选哪款、显示哪款价格，以及对应Product/Offer实际描述谁。独立规格页、同页选择器和一组相关产品，可能需要不同的变体表示方式；必要时按照Google的变体文档组织ProductGroup及相关关系。
本例蓝M是29美元，黑L是39美元。不能只因为客户能在同一选择器中切换，就把蓝M最低价配上黑L库存。若不同规格有不同目标URL，Offer链接也要带读者到正确规格，而不是始终回默认款。
促销改的是当前条件，未知截止日别编
若蓝M确实从29美元降到24美元，本页当前生效价格与相应Offer应按适用规则更新。页面展示的划线原价、当前成交商品价与Merchant数据中的不同价格字段，各有职责，不能只看字段都叫price就机械要求全部相等。
没有确定截止日，不要为了填priceValidUntil编一个年底日期。活动到期后还要确认页面和实际购买条件已经恢复，标记不能保留旧促销价。本文只解释同商品条件维护，具体活动可以沿促销生效时间与价格核对处理。
验收时，把代码对回页面和实际输出
先检查现有商品输出来自主题、商品插件还是SEO组件。已经有Product/Offer时，优先修该来源与商品记录的映射，避免每篇手填一份静态副本。否则商品改价后，页面变了，第二段代码可能还留在29美元。
再做三项核对：
| 检查对象 | 本例应该看到什么 |
|---|---|
| 单品事实 | 蓝M、TS-BL-M、29.00 USD与实际可售状态相符 |
| JSON-LD | Product和Offer同对象，语法能解析，没有虚构评分或标识 |
| 正式页面输出 | 当前URL确实输出正确标记，目标规格与购买入口一致 |
本文教学代码已进行本地JSON解析与关键字段对照，这不代表真实商品上线或Google测试通过。实际实施后，使用富媒体搜索结果测试核对应功能；既测代码，也测正式URL，再把结果与可见商品事实对回去。
如果页面连商品正文都没有正常提供，就先处理抓取与索引可访问性。标记准确也不能代替一个可用的购买或询价页面。
最后保留SKU、正式URL、当前价、库存来源、输出负责组件与测试日期。测试有效只说明当前检查支持相应结论，不保证搜索展示、星级或排名。商品条件变化时，按同一个SKU重新核对，记录才可以继续使用。
常见问题
不打折，也要写Offer吗？
Offer不等于优惠活动，它描述实际出售条件。正常价格也可以用Offer表达；是否需要以及哪些属性必需，要按页面类型与目标功能确认。
没有GTIN，能用SKU填进去吗？
不能把两者当成同一个标识。SKU按店内管理填写，GTIN需要真实对应的商品标识。没有就先核供应或制造商资料，别生成一串数字，也不要把店内SKU复制成条码。
加一组五星评分，会不会更容易显示商品结果？
不能虚构评分或评价数量。只有确实存在、与该商品对应且符合可见内容和功能政策的评价，才能按规则标注。字段更多不代表事实更可靠，误导标记反而需要修正。
