Product schema 的 2026 写法：从必填到可引用

周一早上，一家做折叠露营家具的独立站，运营在 ChatGPT 里问“这张桌子承重多少、德国多久能到”。助手答得流利，引用的却是一个德国测评博客和一家平台店铺，官网不在其中。技术同事打开 PDP 源码：JSON-LD 有，校验也是绿的，只是 gtin 空着，price 写死在模板里，availability 永远是 InStock。

Product schema 的价值不在于通过校验，而在于让 AI 能独立确认四件事：这是什么、现在多少钱、有没有货、别人怎么评；缺任何一项，页面在答案里就退回“待核实”。

校验通过，为什么还是不被引用

校验工具检查语法与必填，不检查事实。一个把 price 写成 0.01 的页面，同样能拿到绿色对勾。

更要紧的是，必填项本来就是一个很低的地板。同一份 Product 标记，可能面对两套要求：能被摘成商品摘要是一套，能进商家列表、带价格与配送信息是另一套。只满足前者，页面在“多少钱、有没有货”这类问题上依旧没有发言权。

AI 选择引用谁时，做的不是“读字段”，而是“确认事实”。同一个价格，JSON-LD、页面可见文本、商家 feed、第三方页面各说一套，模型最理性的选择是不信你，转去引用一个说法一致的第三方。冲突时它不会报错，只会安静地换掉引用源。 这就是很多团队“结构化数据全绿”却始终进不了价格类回答的原因。

可以把它想成两张清单。硬事实是价格、库存、尺寸、材质，能被逐字比对；软事实是卖点、场景、适用人群，只能被整体理解。schema 只承载硬事实，也正因为如此，硬事实错一处，软事实写得再好也救不回来。

所以 schema 要重新定位：它是你向机器提交的事实声明，页面上那行字只是另一个副本。两者不一致，声明就作废。模型认的是实体与关系，不是孤立字段，这一点在商品实体与 Product Graph 里已经拆过。

字段分三层，优先级不能反

层	字段	回答的问题	缺了会怎样
身份	brand、sku/mpn、gtin	这是哪一个商品	变体被合并或错配，跨平台对不上号
交易	price、priceCurrency、availability、priceValidUntil、shippingDetails、hasMerchantReturnPolicy	现在能不能买、到手多少钱	价格类问题改引第三方，agent 不敢下单
信任	aggregateRating、review	别人怎么评	进不了候选集，或只被当成无评价新品

顺序必须是身份、交易、信任。身份错了，后两层全错，而且错得很安静：六个颜色被当成一个商品，评论和评分混在一起，AI 那句“4.8 分、三个颜色”没有一个字是真的。

信任层是唯一“没有就别写”的层。没有真实评价就留空，比填一个系列平均分安全。字段要求会变，一律以官方文档为准，别照抄二手清单。

评分字段还有一层特殊性：它既是给机器看的事实，也是给买家看的宣传，同时受平台政策约束。把系列评分复制到每个变体，短期让页面更好看，长期会让整批标记失去可信度。

到了第二个市场，最先丢的往往不是翻译，而是 GTIN 与币种：几个语言站共用一套标记，价格却按站点写死，最后两个市场互相污染。

五个最常见的标记错误

错误	典型表现	实际后果	修法
价格硬编码	模板写死，或缓存数天	与页面、促销不一致，价格回答改引第三方	由价格服务在渲染时注入，JSON-LD 与 HTML 同源
库存永远有货	缺货页不更新	用户点进去买不到，agent 下单失败	由库存服务生成，缺货写 OutOfStock 或 BackOrder
GTIN 缺失或拿内部 SKU 顶替	字段“填了”，却对不上任何外部库	无法与平台 feed、知识图谱合并	用厂商 GTIN；没有就留空，不要编
评分跨变体混用	系列一个 4.8 分，套到每个颜色	与页面显示不符，有政策风险	按真实评价的粒度标，不足就不写
只在客户端注入	源码没有，JS 执行后才有	部分抓取端读到空壳	服务端渲染或静态输出

表格里 GTIN 那一行最容易被“补齐”的心态带偏。GTIN 是外部世界的身份证，编一个比空着更糟：它会把你的商品和别人的商品绑在一起。

价格那一行常和最后一行一起出现：模板在浏览器里算完价格，再顺手写进 JSON-LD，看着省事，实际是把一致性交给了客户端。

验证：四步，能回归才算完成

步骤	做什么	谁来做	怎么算过
1 盘点	全站 PDP 导出 JSON-LD，按模板、市场、变体分组	工程	每个模板至少 10 个 URL 有样本
2 对源	价格、库存、评分只留一个上游，与 HTML 同源渲染	工程	后台改一次，两处同时变
3 回归	校验与一致性比对进发布流程	工程	模板改动自动跑，冲突即阻断
4 复测	同一批问题看引用来源有没有换	增长	有前后对比，能解释差异

常见的情况是只做第 1 步和第 3 步，跳过第 2 步，于是每次发版都“修好一次，再坏一次”。一致性不是校验出来的，是同源渲染保证的；收益怎么量，参考结构化数据的收益衡量。

第 4 步最容易被省，因为它不像校验那样立刻给出红绿结果。但少了它，团队只能证明标记合法，证明不了标记被用过。

示例：一个 SKU 页的改法

示例（假设场景，不含真实品牌与数据）：一款折叠桌，三种颜色、两个尺寸。改前 JSON-LD 只有名称、图片、一个从不随促销变的价格，gtin 为空，aggregateRating 用整个系列的分数。

改法五件事：六个变体各有独立 URL 与 Offer；价格由价格服务注入并带有效期；availability 跟随库存；GTIN 从供应商数据补齐，缺失的变体留空；系列评分删掉，只保留该变体真实评论的聚合。验收看三点：不执行 JS 拿到的 HTML 里就有完整 JSON-LD；改一次价，两处同时变；同一批问题复测时，价格类回答的引用来源里出现官网域名。更细的币种、税与运费表达，见Offer、价格与库存。

边界：什么时候别把力气花在这里

第一，成交集中在平台内的品类。亚马逊、Shopee 的 AI 读 listing、评论与履约，官网 schema 影响有限，先修 feed。

第二，没有 GTIN 的品类。手工、定制、组合装无法编造编码，只能用品牌加型号加标题一致性替代，并接受变体难以合并。

第三，页面本身没有可读的属性与场景。schema 只能把已有事实翻译成字段，翻译不了空话。

第四，白牌或同一 GTIN 多卖家。标注越完整，越容易被放进比价答案，这未必是你想要的。

第五，把 schema 当排名开关。它改变的是被正确理解的概率，不是权重；指望补几个字段就换来引用，通常两个月后就整套放弃。

这套写法属于技术底座这条线；如果商品页还没有一句能被摘走的答案，先看AI 答案里的商品长什么样。

本月只做一件事：导出销量前 20 的 SKU 页 JSON-LD，把价格和库存改成与 HTML 同源渲染，没有真实评价的页面直接删掉评分字段，然后把这三项加进发布检查。