SEO2026第206期 | 谷歌7月24日文档更新解读!

索未 · SEO ｜ SEO 深度解读

阅读与成长 · 索未

官方更新日期：2026 年 7 月 24 日官方来源：Google Search Central 文档更新日志、Review Snippet 结构化数据指南更新类型：评价摘要结构化数据规则更新，不是核心算法或排名系统更新

2026 年 7 月 24 日，Google Search Central 在文档更新日志中新增一项 Review Snippet 评价摘要规则。

Google 明确表示，网站不得在页面内容或结构化数据中加入虚假评价，也不得加入没有清晰、显著披露利益关系的激励评价。Google 给出的更新理由是：提高用户评价信息的透明度。[1]

此次更新直接涉及Review和AggregateRating结构化数据，也就是产品页、服务页、课程页、软件页等搜索结果中可能出现的评价文本、平均评分、评价数量和星级摘要。

但需要准确理解其边界。

这不是一次核心算法更新，也不代表所有带有客户评价的网站都会排名下降。它首先影响的是页面是否符合评价富结果资格，以及网站是否可能因为滥用结构化数据而收到人工处置。

对外贸独立站而言，真正需要检查的不是页面上有没有五星评价，而是：

这些评价是否来自真实体验，是否对应具体产品，是否在页面上真实可见，评分数量能否核验，以及评价人与企业之间是否存在未披露的利益关系。

Google 在 Review Snippet 指南中新增了两类明确禁止的评价。[2]

第一类，是没有基于真实产品或服务体验的评价。

例如：

• 评价人实际上没有使用过产品；
• 企业员工编写一段客户口吻的评价；
• AI 根据产品参数虚构所谓客户体验；
• 销售人员把普通咨询邮件改写成完整使用评价；
• 企业根据项目结果自行推断客户满意度并生成五星评分。

第二类，是通过利益交换产生，但没有清晰披露激励关系的评价。

Google 列出的利益形式包括：

• 现金；
• 折扣；
• 代金券；
• 免费产品；
• 其他能够影响评价人判断或表达的利益。

需要注意的是，Google 并没有把所有激励评价一概描述为绝对禁止。

它此次强调的是：不得使用未披露的激励评价。

如果评价人因为免费样品、折扣订单或其他利益提交了评价，页面必须清晰、显著地说明这一关系，而不能把披露隐藏在网站底部、隐私政策、服务条款或需要点击后才能查看的说明中。

很多 WordPress 网站把结构化数据理解成一个插件配置问题。

只要 Rank Math、Yoast、WooCommerce 或其他 Schema 插件显示代码有效，就认为评价标记符合 Google 要求。

但 Google 的一般结构化数据指南明确区分了两种问题：

一种是技术问题，例如字段缺失、格式错误或类型不匹配；

另一种是质量与政策问题，例如评价虚假、内容误导、结构化数据描述了页面上不存在的信息。[3]

Rich Results Test 主要用于检查代码是否能够被读取、必需字段是否完整。它不能验证：

• 客户是否真实存在；
• 客户是否实际使用过产品；
• 评分是不是企业自行编写；
• 评价数量是否经过人为放大；
• 客户是否因为折扣或赠品提交评价；
• 激励关系是否得到充分披露。

因此，一个页面完全可能通过 Rich Results Test，却仍然不符合 Google 的评价摘要政策。

代码有效，不等于评价真实；Schema 无报错，也不等于页面有资格持续显示星级。

Google 在 Review Snippet 指南中警告，如果网站违反相关规则，Google 可能采取人工处置。网站完成整改后，可以提交重新审核申请。[2]

不过，这里必须避免夸大。

Google 的一般结构化数据指南明确说明：

结构化数据人工处置的直接结果，是页面失去富结果展示资格，通常并不直接影响普通网页在 Google 自然搜索中的排名。[3]

也就是说，网站可能仍然被抓取、索引和参与普通搜索排序，但无法继续显示星级、评分摘要等增强型搜索结果。

当然，如果网站不仅滥用 Review Schema，还存在规模化虚假内容、欺骗用户或其他违反垃圾内容政策的行为，则可能产生独立于结构化数据之外的搜索风险。

因此，应区分三个层次：

第一，代码错误，可能导致 Google 无法读取评价数据；

第二，评价结构化数据违反质量指南，可能导致富结果资格被取消；

第三，网站存在更广泛的欺骗或垃圾内容行为，才可能进一步涉及普通搜索可见性。

不能把这三种情况混为一谈。

此次更新并不是 Google 第一次规范评价结构化数据，而是在原有规则上增加了更明确的真实性与披露要求。

Google 目前要求或建议网站同时注意以下事项。[2]

如果 JSON-LD 中写入了一段评价，用户进入页面后也应能看到这段评价及对应评分。

如果标记了AggregateRating，页面上也应显示平均分和评价数量。

不能在源代码中写入：

``json "ratingValue": "4.9", "reviewCount": "186" ``

但前端页面完全看不到 4.9 分、186 条评价或任何评价内容。

结构化数据应描述页面的真实内容，而不是建立一个只供搜索引擎读取的评价层。

Google 要求评价信息针对具体产品或服务，而不是模糊的产品分类或产品列表。

例如：

合理对象：

• 某一具体型号产品；
• 某一软件应用；
• 某一课程；
• 某一活动；
• 某一本书；
• 某一部电影。

风险较高的对象：

• “全部工业设备”；
• “所有出口产品”；
• “公司全部解决方案”；
• “热门产品合集”。

外贸独立站不能把网站整体的几条客户评价，平均分配到每个具体产品页上。

如果页面展示多条独立评价，可以同时提供这些评价对应的AggregateRating。

但平均分、评价数量和页面实际内容应一致。

例如，页面只有 6 条评价，却在 Schema 中填写“基于 128 条评价”，就存在明显的数据真实性问题。

评价被删除、合并或迁移后，reviewCount、ratingCount和ratingValue也应同步更新。

Google 明确规定，不应把其他网站上的评分或评价汇总到自己网站的 Review Schema 中。[2]

因此，以下做法并不稳妥：

• 把 Google Business Profile 评分写入官网AggregateRating；
• 把 Facebook 评价汇总成官网平均分；
• 把 Amazon、Alibaba 或其他第三方平台评分写入产品 Schema；
• 把多个行业目录的星级合并成一个“全网综合评分”。

企业可以在页面上引用或展示第三方评价，但不能因此假设自己有资格把这些外部评分汇总成官网的结构化评价数据。

Google 建议网站只接受同时具有文字评论和作者名称的评分。[2]

这一项目前属于建议，而不是所有场景下的绝对必需字段。

但它反映出 Google 希望用户能够看到评分背后的上下文，而不是只看到一个缺乏依据的星级数字。

对 B2B 外贸网站来说，一条更可信的评价通常应至少包含：

• 评价对象；
• 客户角色或可披露身份；
• 使用或项目场景；
• 实际体验；
• 评价日期；
• 对应评分；
• 是否存在激励关系。

外贸企业尤其需要注意 Google 针对LocalBusiness和Organization的自利评价限制。

Google 明确表示，如果被评价的企业可以控制自己官网上的评价，那么该企业官网使用LocalBusiness或其他Organization结构化数据时，不符合组织星级评价功能的资格。[2]

这种限制同样适用于通过第三方小工具嵌入的评价。

例如，企业把自己的 Google Business 评价或 Facebook 评价嵌入官网，并不意味着可以在官网 Organization Schema 中添加五星评分。

这条规则的逻辑是：

被评价者不能同时控制评价的发布页面、评价展示方式和结构化评分结果，然后再要求 Google 把这种自我控制的评分作为企业星级展示。

但产品评价与企业组织评价需要分开判断。

一家企业可以在具体产品页收集真实用户对具体产品的评价，并在满足 Google 要求的前提下使用 Product Review Schema。

它不能简单地把“客户认为我们公司服务很好”转换成官网 Organization 五星评分。

B2B 外贸网站大量使用客户证言、案例反馈、项目推荐语和合作评价。

这些内容具有真实的信任价值，但不一定都适合标记为Review。

例如：

这句话可能是一条真实客户反馈，也可以放在案例页或客户证言模块中。

但要将其标记为结构化评价，还需要确认：

• 它具体评价了什么产品或服务；
• 是否来自客户本人；
• 是否获得公开授权；
• 是否存在评分；
• 是否经过企业大幅改写；
• 是否因折扣、赠品或佣金产生；
• 用户是否能在页面中看到相同内容。

如果无法确认这些事实，保留为普通客户证言，比强行添加Review或AggregateRating更安全。

不是所有积极反馈都必须变成星级，也不是所有案例都需要 Review Schema。

外贸企业常通过免费样品、试用设备、折扣订单、返现或合作项目收集反馈。

Google 本次更新要求，存在利益交换的评价必须清晰、显著地披露。[2]

更稳妥的披露方式应直接出现在具体评价附近，例如：

或者：

披露不应只出现在：

• 网站统一免责声明；
• 隐私政策；
• 页面最底部；
• 鼠标悬停提示；
• 默认折叠且不易发现的区域；
• 需要点击另一个链接才能打开的说明。

美国联邦贸易委员会对评价激励关系也强调“清晰且显著”的披露原则，并指出，企业不能把奖励明确或暗示地与五星、正面评价或特定倾向绑定。[5][6][7]

例如：

这种方式的问题不只是没有披露，而是奖励直接以正面评价为条件。

相较之下：

这种方式没有把奖励与评价倾向绑定，但仍然需要披露激励关系，并且还要遵守评价发布平台自己的规则。

Google 结构化数据政策、第三方平台规则和当地广告法律是三个不同层面。满足其中一个，不代表自动满足另外两个。

外贸企业常见的一种运营流程是：

先通过客服或销售判断哪些客户比较满意，只向这些客户发送评价邀请；对存在投诉、交付延迟或产品问题的客户，则不发送邀请。

这种做法容易让最终呈现的评分失去代表性。

美国 FTC 的评价营销指南建议，企业不要只向预计会留下正面评价的客户征集评价，也不要以删除、压制真实负面评价的方式改善评分。[8]

Google 此次文档更新没有专门新增“不得选择性邀请”的文字，但从真实性和透明度原则看，外贸独立站应避免建立明显偏向正面结果的评价流程。

较稳妥的方法是：

• 对符合条件的真实客户使用统一邀请规则；
• 不以满意程度决定是否发送邀请；
• 不要求客户必须给出正面评价；
• 保留合理的负面和中性评价；
• 允许企业公开回复并说明解决过程；
• 不把问题已解决作为删除评价的强制条件。

真实评价体系不应只有五星，也不应把所有负面反馈都视为需要清理的 SEO 问题。

Google 新增规则明确把“没有基于真实体验的评价”排除在允许范围之外。[2]

这意味着，企业可以使用 AI 帮助完成以下工作：

• 翻译客户原始评价；
• 修正语法；
• 去除敏感商业信息；
• 统一格式；
• 总结大量评价趋势。

但 AI 不能凭空创造客户、项目、使用过程或满意结论。

例如，销售人员输入：

AI 生成：

如果客户没有真正表达这些内容，那么即使订单和客户都真实存在，这段评价仍然包含未经证实的体验描述。

FTC 在 2024 年的虚假评价规则中也把不存在的人、没有实际体验的人以及歪曲真实体验的评价纳入虚假或错误评价范围，并明确提到 AI 生成的虚假评价。[5]

因此，企业使用 AI 处理客户评价时，应坚持一个边界：

AI 可以整理客户说过的话，不能替客户说没有说过的话。

使用 WordPress、WooCommerce、Rank Math、Yoast、Elementor 或第三方评论插件的网站，容易出现自动化 Schema 与实际评价脱节的问题。

建议按以下顺序审查。

搜索页面源代码中的：

• Review
• AggregateRating
• ratingValue
• reviewCount
• ratingCount
• reviewRating
• itemReviewed

不要只检查前端看得到星级的页面。

一些主题和插件会在用户看不到评价的位置自动输出 Schema。

检查 Schema 中的评分、评价数量、评价对象和评价人，是否都能在页面上找到对应内容。

如果结构化数据写着：

• 评分 4.9；
• 评价总数 87；
• 作者 John Smith；

页面上就应存在能够支持这些数据的可见内容和后台记录。

部分产品主题会自动给所有产品输出相同评分。

例如：

• 所有产品都是 5.0 分；
• 所有产品都是 12 条评价；
• 新发布产品立即拥有评分；
• 多语言版本评价数量完全相同，但评价内容没有翻译或迁移。

这些现象通常说明评分来自模板，而不是评价系统。

如果网站嵌入 Google、Facebook 或其他第三方评价组件，要确认插件是否同时把外部评分写入本地AggregateRating。

页面可以展示外部评价，但 Google 明确不允许把其他网站的评价汇总为自己网站的 Review Schema。[2]

多语言插件可能复制原始产品页的评分数据，却没有同步评价文本。

如果英文页面有 10 条真实评价，而法语页面只复制了"4.8 分、10 条评价”，用户却看不到评价正文，就会出现结构化数据与页面内容不一致。

当评价被删除、隐藏、合并或迁移时，应同步调整：

• 平均评分；
• 评价数量；
• 结构化数据；
• 页面显示；
• 缓存；
• 多语言版本。

否则，旧评分可能继续留在页面缓存或 JSON-LD 中。

评价治理不应只由 SEO 插件负责。

建议企业为每条公开评价保留基本记录：

• 客户提交日期；
• 对应订单、产品或项目；
• 原始评价内容；
• 提交渠道；
• 是否实际使用产品或服务；
• 是否授权公开；
• 是否进行过翻译或编辑；
• 编辑前后的版本；
• 是否提供样品、折扣、返现或其他利益；
• 页面是否已披露利益关系；
• 对应评分；
• 当前发布页面。

这些信息不需要全部公开，也不应泄露客户隐私。

它们的作用是让企业能够回答：

这条评价从哪里来？

谁提交的？

评价对象是什么？

客户是否具有真实体验？

企业是否改写过？

是否存在利益交换？

为什么页面上的评分是这个数字？

对于订单金额较高、采购周期较长的 B2B 业务，这种证据链比单纯增加评价数量更重要。

企业不必因为此次更新删除全部客户反馈。

可以按照以下优先级处理。

最高优先级：立即清理明显虚假数据

包括虚构客户、虚构评价、AI 批量生成评价、默认五星、伪造评价数量、没有真实体验的评价。

第二优先级：移除无法核验的 AggregateRating

如果网站无法证明评分总数、平均分和评价来源，应先移除星级 Schema。

普通客户证言仍可保留，但不要继续输出无法核验的结构化评分。

第三优先级：补充激励披露

检查免费样品、折扣、返现、佣金、赠品和合作项目产生的评价，在每条相关评价附近增加清晰说明。

第四优先级：分离企业证言与产品评价

企业服务反馈放在案例或证言模块中。

具体产品使用评价才进入 Product Review 体系。

不要把对企业服务的表扬批量复制到所有产品页。

第五优先级：修复插件自动输出

关闭默认评分、虚假数量、外部评分聚合和页面不可见的评价 Schema。

修复后通过 Rich Results Test 检查代码，再通过页面人工检查验证内容真实性。

此次更新的直接影响主要集中在评价富结果资格，而不是普通网页排名。

符合以下情况的网站风险较高：

• 产品刚发布就有大量五星评价；
• 每个产品使用完全相同的评分；
• 页面评价数量与 Schema 不一致；
• 评价全部来自企业自己编写；
• 把第三方平台评分汇总到官网；
• 免费样品评价没有披露；
• 员工或关联方评价没有说明关系；
• 前端没有评价，源代码却输出评分；
• 企业官网给自己的 Organization 添加星级；
• 只展示正面评价，系统性隐藏负面反馈。

风险较低的做法包括：

• 评价来自真实客户和真实使用；
• 评价对象明确；
• 页面内容与 Schema 一致；
• 平均分可以根据实际评价重新计算；
• 激励关系得到清晰披露；
• 不把奖励与正面倾向绑定；
• 不汇总其他网站评分；
• 不用 AI 虚构体验；
• 保留评价来源和授权记录。

Google 在 2026 年 7 月 24 日新增的 Review Snippet 规则，看似只是结构化数据文档中的一项调整，实际上进一步明确了搜索结果中评价信息的真实性边界。

评价结构化数据不只是几段 JSON-LD 代码。

它背后必须存在一套可以核验的事实：

谁进行了评价；

评价了哪个具体产品或服务；

评价人是否真实体验过；

评分和评论是否真实可见；

评价数量是否准确；

企业是否修改了评价含义；

评价人与企业是否存在利益关系；

这种关系是否已经清晰披露。

对外贸独立站来说，客户评价仍然是重要的信任资产，但评价数量和五星比例不应成为唯一目标。

真正长期有效的做法，是建立真实、可追溯、允许正负反馈并能够说明利益关系的评价体系。

可信度来自证据链，而不是来自永远接近满分的星级数字。