评价与评分对商品页的影响，集中在"这一页会被怎么理解"这一层，而不是"这一页排第几"。Google 把商品类结构化数据分成两套，评价只出现在其中一套的推荐项里，而且带了一串前提条件。功能上怎么把评价显示出来，站内已有两篇专门文章，本文只谈这些评价一旦存在，会在搜索与索引上被怎么处理、以及什么时候不该标。
两个字段，两种性质
Google 的商家商品列表字段定义里，评价相关的是两个推荐项：aggregateRating 表示"基于一批评价或评分汇总出来的整体评分"，review 表示"该商品的一条嵌套评价"。两者的差别在实践中很关键：汇总评分是页面上一行数字，评价是若干条带文字的记录，而官方对后者的措辞更严——如果添加评价，评价者的姓名必须是有效的个人或团队名称，官方在这一条后面还给了反例与正例对照：像"黑色星期五五折"这样的营销词不适合当评价者名称，"詹姆斯·史密斯"或某评测机构名才是合适的。
字段本身的含义可以在 schema.org 的 Review 词条里查到：itemReviewed 是被评价的对象，reviewRating 是这条评价给出的评分，reviewBody 是评价正文，reviewAspect 表示这条评分针对的是商品的哪一部分。词条里还有一对容易忽略的说明：positiveNotes 与 negativeNotes 既可以描述评价里的优缺点清单，也可以描述商品本身的优缺点。要注意分工——词条只解释字段含义，"推荐项""评价者名称要有效"这类要求来自 Google 的功能指南。
怎么改：官方对评价内容的三条硬要求
三条都出自结构化数据总则，而且每一条踩中都会带来实际后果，不是风格建议：
- 不得标记页面上看不到的内容。总则的原话是不要标记页面上读者看不到的内容，并给了对照：如果你在 JSON-LD 里描述了某位表演者，HTML 正文必须描述同一位。这一条落到商品页上，就是结构化数据里的评价条数不能多于页面上真实渲染出来的条数。
- 页面上的评价要标全。总则里还有一条针对多条内容的要求：如果页面上有多条评价，标记里必须包含页面上所有对用户可见的评价，只标一部分会被视为对期待看到全部评价的用户构成误导。
- 非真实用户的评价或评分可能触发人工处理。总则在"完整性"一节写明，用户更信任带真实用户评价与真实评星的内容，同时提示不是由真实用户给出的评价或评分可能导致人工处理；同一节的"内容"一节还把"虚假评价"直接列为不可标记的内容。
所以正确的做法是：让结构化数据成为页面上已经存在的那部分内容的机器化副本，而不是额外再生产一份评价数据。
什么时候评价字段反而不该出现
有几种情况宁可不标：
- 页面上一条真实评价都没有。为了好看而先用占位的评分顶上，属于第一条的直接违反。
- 评分来自与商品无关的来源。例如把整个店铺的总体评分复制到每个商品上——评分所描述的对象与商品本身不一致。
- 评价需要登录或展开才能看到。它对多数访问者不可见，符合"页面看不到"的定义。
- 这一页不是商家可购买的商品页。商家商品列表的技术条款限定了适用页面；编辑型评测页走的是另一套要求，两套不能互相套用——评价字段该按哪一套写，取决于这一页能不能让读者在你这里下单。
怎么验证评价标记被正确读取
验证的第一原则是先确认标记与页面一致，再看工具结果。顺序如下：
| 步骤 | 检查什么 | 通过标准 |
|---|---|---|
| 数一遍页面 | 页面上实际渲染出来的评价条数与汇总评分 | 拿到确切数字 |
| 对照源代码 | 结构化数据里的评价条数、评分值 | 条数与数值与页面一致 |
| 查评价者名称 | 是不是具体的人或团队 | 不是营销词、不是"匿名买家"这类占位 |
| 跑单页测试 | 富媒体结果测试工具报的必填项缺失 | 没有关键错误 |
| 看长期报告 | Search Console 商家商品列表报告 | 这些页不在错误列表里 |
最后一条路径是那份内容自查清单里给的一个角度：它专门问"这些内容是怎么做出来的"，并举了商品评测为例——读者知道测了多少件产品、测试结果如何、测试怎么做的、还配有照片作证据时，信任感会明显不同。这条比任何标记技巧都更根本，因为标记只是把已经存在的事实翻译成机器可读的形式。
收尾要说清两条边界：其一，官方从未公布评价数量、评分分布对排名的影响方式，商家商品列表指南也只把"提供越多的推荐信息，用户体验越好"当作富结果的排序考虑，没有给出任何权重口径；其二，Google 明确表示不保证任何结构化数据一定出现在结果里，它列出的常见原因包括内容对用户不可见、标记与页面主体不符等。功能层面的操作步骤见站内WooCommerce 的产品打分怎么操作与如何给 WordPress 产品页面增加评价和评分；如果想靠对比类内容把这类页面做成能被引用的目标页，看对比和选型页为什么容易被引用。