Review 结构化数据：聚合评分与单条评论

示例：五月的复盘会上，一家做人体工学椅的出海品牌把商品页截图投上屏——4.8 星、1,284 条评论，JSON-LD 里也规规矩矩写着 AggregateRating。技术负责人接着打开前台：评论区加载出来只有 128 条，翻到第三页就到底了；那 1,284 是过去十二个月的订单数。同一天，他们在 Perplexity 里问“这把椅子坐久了腰托会不会塌”，答案引的是 Reddit 上一条讲腰托异响的帖子，评分一个字没提。

评分标记的价值不在星星，而在这个数字能被追溯到哪些可见评论；聚合评分与单条评论是两种证据，标错一次，AI 学到的不是 4.8，而是“这家的数据对不上”。

模型读的是字段关系，不是星星

JSON-LD 里的评分对模型不是一张图，而是一组可以互相校验的断言：ratingValue 是多少、reviewCount 是几条、bestRating 按几分制、这条评分挂在哪个 itemReviewed 上、单条评论的 author 是谁、datePublished 是什么时候。少一个，这组断言就从“事实”降级为“说法”。

聚合与单条回答不同的问题。买家问“整体口碑怎么样”，模型要的是均值、样本量与时间窗；问“有什么缺点”，模型要的是一条具体、可引用的负面描述。只有聚合，答案只能是“评分 4.8”，没有信息增量；只有单条，模型无法判断这条是不是特例。

模型还会做交叉验证：页面正文、JSON-LD、站外语料三处对不上时，它倾向退回最保守的表述——“该品牌有用户评分”。这种保守表述为什么进不了推荐位，机制在AI 推荐你的四个信任前提里拆过：证据不一致，等于没有证据。

被忽略的变量是分母。reviewCount: 1284 如果不说明这是订单数、评论数还是各市场相加，模型既无法判断 4.8 的置信度，也无法解释德语页面为什么只有 128 条德语评论。

字段与资格：两类标记不要混

先分清资产，再谈字段。聚合评分是结论，单条评论是证据；前者挂在 Product 或 Offer 上，后者一条 Review 只对应一次真实评价。

FAQ、HowTo、Review 三类标记的展示价值在收窄，但“机器能不能读懂”这一层没有变。展示是平台的开关，字段正确才是自己的事。

标记	挂在哪	关键字段	通过标准
AggregateRating	Product / Offer	ratingValue、reviewCount 或 ratingCount、bestRating	均值能由页面上可见评论复算出来
Review	Product / Organization	author、datePublished、reviewRating、reviewBody	页面上能找到同一段文字与同一作者
资格	全站	实体具体，是某款商品而不是整个类目	评论由用户产生，且用户能读到

两条硬要求：评论必须对用户可见，只给爬虫的输出不算数；品牌自己给自己写的评分不是用户评价，Google 的 review snippet 文档长期把这类自评列为不适用，具体条款以官方文档当前版本为准（截至 2026-05）。字段名对、口径错，是最难查的一类问题。

三种违规，后果都是“整站不可信”

第一种，搬运与自评。把 Trustpilot、Amazon 的星级复制进自家 JSON-LD，或把市场部写的“专业评测”标成用户评价。author 一栏填公司名，模型和审核方都看得出源不对；一处被判定为搬运，同站其他评分会一起被打折。

第二种，分母注水。reviewCount 写订单数、写“服务客户数”，或把各国评分数加总后挂到每个市场页。德国买家看到 1,284 条，点开只有 128 条德语评论，这种落差比没有评分更伤。

第三种，隐藏与条件渲染。低分评论用 CSS 折叠、评论只在“加载更多”后出现、JSON-LD 由爬虫 UA 单独返回。用户看不到的内容不该被标记，模型也不该被要求相信它；一旦被识别，等于告诉平台“这站给人和给机器准备了两套数据”。

五步落地：从对账到回归

顺序不是先写 JSON-LD，而是先把评论数据做成单一事实源，再让它同时喂页面和结构化数据。

步骤	做什么	谁来做	怎么算过
1 建主数据	SKU × 市场 × 时间窗，定义评分、计数与分母口径	数据 / 电商	页面、JSON-LD、feed 三处同源
2 分两类标记	聚合挂商品，单条只标页面上真实可读的评论	前端 / 内容	每条标记都能在页面找到原文
3 补必填字段	author、datePublished、bestRating、reviewRating	前端	校验工具零 error
4 加 CI 门禁	评分为空、计数变小、评论不足 5 条时不输出聚合	前端 / QA	构建期拦截，不靠人眼
5 月度回归	抽 20 个 SKU 人工对账	内容 / 增长	差异为 0，偏差有记录

第 4 步最值得先做。评分字段的腐化是静默的：换一版模板、评论系统换了供应商、某个市场的接口超时，ratingValue 变成空字符串，页面照常渲染，只有抓取日志里多出一批缺字段的请求。

示例：同一把椅子，两版标记

以下品牌、评分与评论均为虚构，只用来说明字段关系。改前是 ratingValue: 4.8、reviewCount: 1284、没有 bestRating、没有单条 Review，德语页直接复用美国站数据。改后：

{
  "@type": "Product",
  "name": "Ergo Chair S2",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": 4.6,
    "reviewCount": 128,
    "bestRating": 5
  },
  "review": [{
    "@type": "Review",
    "author": { "@type": "Person", "name": "M. Weber" },
    "datePublished": "2026-03-11",
    "reviewRating": { "@type": "Rating", "ratingValue": 2, "bestRating": 5 },
    "reviewBody": "腰托在第三个月开始异响，客服寄了替换件，两周到货。"
  }]
}

改动只有三处：均值按页面上 128 条可读评论重算，计数改成评论数而不是订单数，补一条带作者和日期的负面评论。主动标低分不是自曝，而是让“有什么缺点”这个问题有官方答案；处理差评的逻辑在差评怎么处理，AI 才不放大里有更完整的做法。

边界：什么情况下不该标评分

第一，评论太少。新品只有 3 条评论时，聚合评分不标，只标单条真实评论；5.0 分、3 条评论挂在页面上，暴露的是样本不足，不是质量。

第二，成交几乎都在平台内。平台 AI 读的是 listing、评论与履约指标，官网评分的权重往后放；先看清AI 搜索把海外电商流量切成了四段里的入口分工。

第三，定制、B2B 报价、工程单。没有公开评分体系，硬造一个“综合评分”只会多一个被质疑的面。

第四，评论来源本身有问题。返现换评、刷单、把测评机构的分数当用户评分，schema 只会把问题放大；欧盟消费者保护规则要求商家说明评论真实性如何保障，具体适用请以当地法务判断为准。

第五，把 schema 当排名开关。它提高的是“被正确理解”的概率，不保证富媒体展示，也不保证被引用。

评分标记属于技术底座这条线，和抓取、Offer、实体一样，都是让机器能核对的事实层。

这个月先做一件事：挑一个主力 SKU，把 JSON-LD 里的 ratingValue、reviewCount、bestRating 与页面上能点开的评论导出成一张对账表，把三个数字拉平，再把“评论不足 5 条不输出聚合评分”写进模板。做完这一步，再谈扩展。