独立站为了提高商品页转化，常见做法包括：下单后发优惠券换评价、寄送免费样品邀请测评、从第三方平台导入历史评论，或者用评价应用自动生成星级结构化数据。问题是，页面上出现五星并不等于 Google 会把它当成可信评价。
2026 年 7 月 24 日，Google 在 Review snippet（评价摘要）结构化数据文档中新增规则：页面和结构化数据不得包含虚假评价，也不得包含未清楚、显著披露激励关系的评价。
这次更新不是“再加一个 Schema 字段”，而是把评价真实性、激励披露和结构化数据资格连在了一起。对面向欧美市场的中国出海品牌来说，SEO、站内评价应用、客服邀评、达人寄样和 Merchant Center 评价 Feed 不能再各自管理。
Google这次到底新增了什么？
Google 官方更新页说明，此次新增规则的目的，是提高用户评价透明度。Review snippet 文档给出了两类直接违规示例：
- 评价并非基于真实的产品或服务体验；
- 评价者因金钱、折扣、优惠券或免费产品获得利益，但页面没有清楚且显著地披露激励关系。
Google 同时提醒，违反评价摘要指南可能触发结构化数据人工处置。根据通用结构化数据指南，这类人工处置通常会让页面失去富结果资格，并不等同于网页自然排名一定下降；但如果背后还存在垃圾内容或欺骗行为，风险就不再局限于星级展示。
这里最容易被误读的一点是：Google 不是在这条规则里宣布“所有激励评价都禁止”。它禁止的是虚假评价和未披露的激励评价。真实体验、没有要求必须给好评、并且清楚披露利益关系的评价，与“付费买五星”不是同一类行为。
| 评价场景 | Review Snippet判断 | 独立站处理建议 |
|---|---|---|
| 真实买家自愿评价 | 可保留 | 保存订单或体验证据，评价正文、作者与星级在页面可见 |
| 送样或发无门槛优惠后提交真实评价，并显著披露 | 不属于“未披露激励评价” | 保留激励记录，在评价附近披露；还要核对目标市场法律和平台政策 |
| 要求“给五星才返现” | 高风险 | 立即停止活动，不要继续展示或标记为可参与富结果的评价 |
| 没有使用经历，由员工、供应商或AI批量编写 | 虚假评价 | 不应发布，也不应进入Review或AggregateRating结构化数据 |
| 从其他网站复制评价并汇总到自己的星级 | 不符合既有指南 | 不要把第三方网站评价聚合进自己的Review snippet标记 |
不要把Search、Merchant Center和美国FTC规则混成一条
独立站团队经常把“Google 星级”当成同一套系统，实际上至少有三套不同口径。
1. Google Search Review Snippet
这是网页自然搜索富结果使用的
Review、AggregateRating 结构化数据。Google
要求评价真实、与具体产品或服务有关、在页面上对用户可见，并且不能从其他网站聚合评价。
新规进一步明确：虚假评价和未披露激励评价不能出现在页面或结构化数据中。即使代码能通过 Rich Results Test，也不代表评价真实性已经合规，因为测试工具主要检查语法和必填字段，无法判断评价者是否真实使用过产品。
2. Google Merchant Center Product Ratings
Product Ratings 是 Shopping 广告和免费商品列表里的商品评分体系，不等同于网页上的 Review snippet。
Google Merchant Center 官方政策允许展示通过激励获得的评价，但必须同时满足两个关键条件：
- 激励不能取决于评价态度，不能要求必须是正面或五星；
- 评价 Feed 必须使用
<is_incentivized_review>标记披露激励。
Merchant Center 还要求商家提交完整评价，包括低星评价，并定期更新 Feed。不能为了抬高平均分只提交五星，也不应把其他零售商或评价网站的内容当成自己拥有的评价提交。
这和商品页的 Merchant Listing结构化数据 是两条数据链：前者管理评价 Feed，后者管理产品、价格、库存等商品事实。两边最终都需要和页面可见内容一致。
3. 美国FTC消费者评价规则
如果品牌面向美国市场，还要单独评估 FTC 的 Consumer Reviews and Testimonials Rule。
FTC 禁止企业购买、制作或传播明知或应知为虚假的评价，也禁止以报酬或其他利益为条件，要求评价必须表达特定正面或负面态度。FTC 官方问答同时说明，向消费者提供激励以换取诚实评价本身并非一律禁止，但不能要求特定倾向，而且未披露激励关系仍可能构成欺骗。
因此，“我们在评论下写了送券”并不能让“五星返现”变成低风险。披露解决的是利益关系透明度，不会消除“评价必须是正面”这一条件本身的问题。不同国家和平台规则并不完全相同，正式活动上线前仍应由熟悉目标市场的法务确认。
独立站评价要建立一条可审计的数据链
评价合规不能只靠前端加一句提示。真正需要的是从订单、邀评、审核到页面和结构化数据的一条完整链路。
第一步：证明评价来自真实体验
每条评价至少应能追溯到订单、试用、服务记录或其他合理的使用证据。前台可以匿名显示部分姓名，但后台不能完全没有来源。
建议保留：
- 订单号或体验记录；
- 评价提交时间；
- 评价者标识；
- 邀评渠道；
- 是否提供激励；
- 激励内容和发放时间；
- 是否要求特定评分或态度；
- 审核和修改记录。
第二步：把激励披露放在评价附近
“显著披露”不能只藏在网站条款、FAQ 或页面底部。用户看到具体评价时，就应该同时看到这条评价是否来自送样、折扣、礼品卡或其他利益。
可使用清楚、直接的表述，例如：
- “该用户获得免费产品，并提交了独立评价。”
- “激励评价：用户获得下次订单折扣；评价内容和评分不受限制。”
不要使用含糊标签，例如“合作体验”“精选用户”或一个没有解释的礼物图标。具体文案是否满足当地法律要求，应按目标市场单独确认。
第三步：页面内容和JSON-LD必须一致
Google 要求被标记的评价内容对用户可见。技术团队需要同时核对：
| 页面可见内容 | JSON-LD对应数据 | 检查重点 |
|---|---|---|
| 商品名称 | Product.name | 必须是同一具体商品，不能把分类页当单品 |
| 评价者 | Review.author | 使用有效姓名或组织名称，不要填促销文案 |
| 星级 | Review.reviewRating.ratingValue | 与页面显示一致 |
| 评价正文 | Review.reviewBody | 内容真实可见，不要只在代码里存在 |
| 平均分 | AggregateRating.ratingValue | 与当前可见评价集合一致 |
| 评价数量 | AggregateRating.reviewCount | 不能用虚构数量或已删除评价抬高计数 |
Review Schema 里不要自行发明 isIncentivized
一类非标准字段。Merchant Center 的
<is_incentivized_review> 是评价 Feed 字段，不是网页
Review JSON-LD
的通用属性。网页端的激励关系要在人能看到的位置清楚披露。
第四步：不要把第三方星级直接抄进AggregateRating
Google Review snippet
既有指南明确要求，不要聚合其他网站的评价或评分。将
Amazon、Trustpilot、Google Business Profile
或行业平台的总分直接写进自己商品页的
AggregateRating，不是稳妥做法。
如果确实要展示第三方评价，可以清楚标明来源并让用户查看原始内容，但不要把外部总分伪装成本站直接收集的评价，再用于自己的富结果结构化数据。
第五步：将评价系统纳入网站发布流程
评价问题通常横跨客服、运营、技术和SEO。只让 SEO 改 JSON-LD，很快会被评价应用、主题更新或 Feed 插件覆盖。
在 外贸网站建设 或改版阶段，应提前明确：
- 哪个系统是评价数据源；
- 谁负责激励字段；
- 谁审核异常评价；
- 页面如何展示披露；
- JSON-LD由主题、插件还是自定义代码生成；
- Merchant Center评价Feed由谁提交；
- 评价删除、退款或商品合并后如何同步计数。
14天整改清单：先控制风险，再补技术
第1—3天：盘点所有评价入口
- 列出 Shopify、WooCommerce、WordPress 或自建站的评价应用和插件；
- 导出商品页评价、评价者、星级、日期、订单关联和激励状态；
- 检查客服、邮件、短信、联盟客和达人团队的邀评话术；
- 找出页面 Review JSON-LD、AggregateRating 和 Merchant Center评价Feed的生成位置；
- 抽查高流量、高转化和高评价量商品页。
第4—7天：给评价分级
将评价分为四组：
- 有真实体验证据、无激励；
- 有真实体验证据、有激励且已清楚披露；
- 有真实体验证据、有激励但未披露；
- 无法证明真实体验、复制、批量生成或要求五星。
第三组先补披露并核对政策；第四组不应继续参与页面评价和结构化数据。不要为了“快速合规”一刀切删除所有低星或所有激励评价，这会破坏评价完整性，也可能让平均分失真。
第8—10天：修页面、Schema和Feed
- 在具体评价旁增加清楚的激励披露；
- 取消“五星返现”“好评送券”一类带评分倾向的条件；
- 确保页面显示的评价、平均分和数量与JSON-LD一致；
- 删除结构化数据中虚构、隐藏或从第三方聚合的评价；
- 在 Merchant Center评价Feed中正确标记激励评价；
- 把低星评价纳入完整 Feed，不要只提交正面评价。
第11—14天：测试和监控
- 用 Rich Results Test 检查
Review和AggregateRating语法； - 用 URL Inspection 查看 Google 抓取到的页面与渲染内容；
- 检查 Search Console 的“人工处置”和“商品摘要/评价摘要”报告；
- 抽查前台页面，确认披露没有被折叠组件、懒加载或移动端样式隐藏；
- 记录整改前后的评价数量、平均分、富结果曝光和自然点击。
如果需要把这类审计纳入长期的 独立站SEO优化 工作，不要只监控星级是否出现。更重要的是持续检查评价来源、披露状态、页面可见内容、JSON-LD和 Merchant Center Feed 是否同步。
负责人可以直接问团队的10个问题
- 每条评价能否关联订单、试用或真实服务记录？
- 当前有没有“五星返现”“好评送券”或默认正面评价的机制？
- 送样、折扣或礼品卡评价是否在具体评价旁披露？
- 页面、评价应用和 Merchant Center Feed 是否使用同一个激励状态？
- 低星评价是否被隐藏、删除或排除在 Feed 外？
- 有没有把其他网站的评分汇总到本站
AggregateRating？ - 页面显示的平均分和评价数是否与JSON-LD完全一致？
- 移动端用户能否直接看到评价正文和激励披露？
- Rich Results Test通过后，是否还做了真实性和政策人工审核？
- 谁负责每月抽查高流量商品页和评价Feed？
FAQ
Google现在禁止所有激励评价吗？
不是。此次 Review snippet 新规明确禁止虚假评价和未清楚、显著披露的激励评价。真实体验、没有要求特定评分或态度、并在页面显著披露利益关系的评价，不属于“未披露激励评价”。但还要同时遵守目标市场法律和所用平台政策。
免费送样后得到的评价可以写入Review Schema吗？
不能只看“送样”两个字。需要确认评价基于真实体验、没有要求必须给正面或五星、页面显著披露送样关系，并且结构化数据与页面可见内容一致。面向 Merchant Center 提交评价 Feed 时，还要使用相应的激励评价标记。
把Amazon或Trustpilot评价导入独立站可以吗？
页面是否可以展示，要看内容授权和平台条款；但 Google Review snippet
指南明确不允许把其他网站的评价或评分聚合进自己的评价摘要结构化数据。不要把外部平台总分直接写成本页面的
AggregateRating。
Rich Results Test通过就代表评价合规吗？
不代表。该工具主要检查结构化数据格式、必填字段和可解析性，无法判断评价是否来自真实体验，也无法验证激励是否充分披露。技术通过和内容合规是两次不同检查。
结构化数据人工处置会让自然排名下降吗？
Google 通用结构化数据指南说明，结构化数据人工处置会让页面失去富结果资格，本身不直接影响网页自然排名。但如果同时存在垃圾内容、欺骗或其他搜索政策违规，可能出现额外影响。
Shopify或WordPress独立站先从哪里查？
先确认评价应用或插件如何收集评价、如何保存订单关联和激励状态，再查看主题输出的 Product、Review、AggregateRating JSON-LD。最后对照 Merchant Center评价Feed，确认三处的评价数量、星级、来源和披露状态一致。
来源参考
- Google Search Central：Latest documentation updates
- Google Search Central：Review snippet structured data
- Google Search Central：General structured data guidelines
- Google Merchant Center Help：Product Ratings policies
- Google Merchant Center Help：Product Ratings basics
- FTC：Consumer Reviews and Testimonials Rule Q&A
- FTC：Final Rule Banning Fake Reviews and Testimonials
