产品页的结构化数据出问题，多数不是"没标"，而是标的内容和页面上能看见的不是一回事。价格差一个币种、库存卖完了还标着有货、评分来自页面上根本看不到的评论源，这些都会让展示资格直接消失。所以核对的重点不是"代码在不在"，而是"代码说的和页面说的是不是同一件事"。
先分清两种标注，再查页面已经输出了什么
Google 把产品结构化数据分成两类：产品摘要用于不能直接购买的页面，商家信息用于可以直接下单的页面，后者支持更细的字段，比如服饰尺码、运费和退货政策；把商家信息要求的必填属性标全，页面同时也有资格进入产品摘要那一类（见 Google 的产品结构化数据说明）。
页面看不到的数字不要标（光算 · 示意图）
动手顺序比字段清单更重要。Shopify 的帮助文档写着，官方支持的主题以及主题商店里的主题默认已经包含价格、库存、评价这类结构化数据，不需要另外加代码（Shopify 站点地图与搜索结果显示说明）。所以多数店铺的问题不是缺标记，而是标记里的值不对。第一件事是打开产品页源码，找两类输出：属性形式的微数据，以及脚本块形式的 JSON-LD。平台默认输出的是前者，应用和自定义代码注入的通常是后者，两种可能同时存在，核对时要一起看。
必须与页面一致的五个字段
| 字段 | 页面上应该能看到 | 常见的不一致 |
|---|---|---|
| 价格与币种 | 买家当前环境下显示的价格 | 标注写基础货币，页面显示本地货币 |
| 库存状态 | 页面上的可购买状态 | 卖完了还标有货，或变体之间矛盾 |
| 评分与评价 | 页面上真实可见的评价 | 数值来自页面看不到的评论源 |
| 运费与交期 | 结算流程里能确认的口径 | 标了平台并没有承诺的信息 |
| 图片 | 页面实际展示的主图 | 指向已替换或删除的图片 |
这五项里，价格、库存、评价三项是主题默认会输出的，另外两项通常要自己补。顺序上先查默认输出的有没有错，再决定要不要补，理由是默认字段由主题维护，改它等于改模板；后补的字段是额外代码，出问题时更难定位来源。把这五个字段抄成一张固定表格，每次核对只填值不重建格式，坚持三个月比一个月做得很细更有用。
价格与币种是最容易错的一项
开了币种切换的店铺，同一个地址在不同环境下显示的价格可能不同，而结构化数据往往只输出一个值。Google 的说明里还提到，如果页面结构化数据里没有价格，产品摘要可能改用 Merchant Center feed 里的价格；两边都有但数值不一致时，等于把矛盾直接交给搜索引擎判断。
先看输出来源，再决定改哪里（光算 · 示意图）
核对的原则只有一条：结构化数据里的价格必须是当前页面上买家能看到的价格，不是后台的基础价，也不是把原价和折扣说明叠在一起写。同一件商品同时存在于带集合目录和不带集合目录的两个地址时，先确认哪个地址是搜索结果里真正被选中的那一个，路径重复的判定办法见同一产品出现两种路径时先查主题里的 within。价格区间的写法涉及变体，规格多的商品单独处理，见变体与 Offer 该怎么写。
评分与评价：没有真实来源就不要标
评价类字段风险最高，因为它直接影响展示样式，也最容易想当然。硬性要求只有一条：标注里的评分和评价数必须对应页面上真实可见的评价内容。从评论应用取数据时，先确认这些评价确实渲染在页面上；只在应用后台存在、页面上看不到的评价，标上去就是不一致。自己凑一组好看的数字，或者用工具生成评价，属于明确不该做的事。
标注与实际不一致可能被忽略，也可能引发 Google 对结构化数据的相应处理，具体判定以 Google 官方政策为准。这篇文章只讲技术层面的核对，不讲怎么绕过去。核对出来的问题里，有一半其实来自"没打开页面看"。
库存状态：标记要跟着实际变化走
库存是变化最频繁的字段，也是最容易长期挂着错值的一项。判断标准是页面：如果一个变体在页面上已经不可选或者标着补货中，标记里就不该继续写成有货；一件商品有多个规格时，每个可售规格的状态和价格要各自对得上，页面上显示的汇总区间也必须与这些规格一致。变体多的商品在这方面出问题的概率最高，抽样核对时优先挑规格多、销量好的款，而不是随机点一个基础款看。
顺带一个容易被忽略的连锁影响：改价格规则、改库存同步方式、换库存管理应用，都可能改变页面输出。核对清单里把它记为触发条件，改动当天做一次抽样，比一个月后发现整类商品标错要便宜。
运费与交期：只标页面真的写清楚的部分
运费和退货这类信息，只有在业务上真的写明、页面上真的能被买家看到时才适合标注。Shopify 帮助文档说明的是主题默认已经包含价格、库存、评价这类结构化数据，并不等于运费与退货政策会自动被标好——这部分通常需要自己补，或者依赖你在页面上写了什么。反过来，如果店铺的运费规则是按地区、按重量、按金额门槛计算的，那就不该用一个笼统的免费运费标注去覆盖，页面上写不清的口径，标注也写不清。
核对方式是打开结算前的页面，看运费是怎么呈现的：写上明确的金额门槛、或者写清计算方式，标注再跟随同样的口径。做不到这一点时，宁可不标这一项，也不要给一个买家到结算时会发现不成立的数字。
核对方法：一套可以按月重复的动作
- 挑一个字段最全的产品页，比如有变体、有促销价、有评价的那个，查看源码，搜微数据属性与 JSON-LD 脚本块，把价格、币种、库存、评分、评价数、运费相关字段抄进表格；
- 打开同一个页面，把页面上显示的价格、库存状态、评价数抄下来，两边逐行对照；
- 用富媒体结果测试跑一遍，先处理它标出的关键错误，非关键问题按影响排序处理（Google 关于结构化数据构建与测试的流程）；
- 用网址检查工具看 Google 抓到的渲染版本里有没有这段数据，脚本注入的内容尤其要这样验证；
- Search Console 里的结构化数据报告按月记录有效项与错误项的变化，出现新增错误先定位来源是主题还是应用；
- 换主题、换应用、调过价格规则之后重复第一步，这三件事都会改变页面输出。
核对频率要有取舍：字段多、应用多、价格规则复杂的店铺一个月一次；商品少、改动不频繁的店铺一个季度一次就够。频率定得比实际能坚持的高，结果是核对表停在第一个月再也没动过。
改过主题的店铺要特别注意：结构化数据能输出，通常靠模板里的一段条件判断，改版时这段代码最容易丢。产品页字段的改动代价排序里把这类改动归为"改的时候看不见、丢了影响一大片"，主题改版的核对清单应该给它单列一项。
报告里的状态和实际展示是两件事
结构化数据分为三层：代码里标了什么、报告认可了什么、用户实际看到了什么。三层之间会拉开距离，常见原因是模板的条件输出、应用的重复注入和变体价格变化。核对这三层差距的流程，见富媒体结果报告与实际展示的差距。
Google 的说明里写着，结果增强由各展示位自行决定，并且可能随时间变化，官方因此建议尽量提供丰富的产品信息，而不要纠结具体会被哪个展示用到；价格下降这类信息由 Google 通过观察价格变化计算，不保证展示。这决定了结构化数据的定位：它是入场资格，不是展示承诺。报告里没有错误只能说明代码层面正常，不能说明用户看得到价格、评分或运费。
改动顺序：先试再发，一次只动一类字段
有一个硬规矩：先在副本主题或者单个模板上验证输出，确认无误再发布，不要在营业时段直接改线上主题。一次只改一类字段，比如先处理价格，过几天再动库存，出问题时才定位得到原因。每次改动记下日期、改动的模板或应用、抽样了哪些页面，这三条信息在两个月后交给别人接手时，比代码里的注释有用得多。
什么情况不值得花这笔时间
- 主题默认输出已经正确时，为了"更完整"重写一遍标记，收益很小，风险是整段消失；
- 产品描述还是供应商原文、图片混乱、库存状态自己都不清楚时，先把这些做好，结构化数据只是把现状描述得更准确；
- 商品数量过万、字段没有维护流程时，先固定一个抽样比例，比如销量靠前的若干款加随机抽样，比一次性全量核对更容易坚持下去。
这些字段更像产品数据的纪律，而不是优化技巧。数据本身错的时候，标注只是把错误说得更清楚一点。整站范围的核对一般会和谷歌 SEO的技术盘点一起做：先确认哪些页面该被收录、哪些页面的信息本身就不完整，再谈标记怎么写。