评价插件能输出星级，不代表这些星级就符合Google搜索的展示要求。排查应从评价实际说了什么、来自哪里、评的是谁开始，再检查页面与结构化数据是否表达了同一件事。
2026年7月24日，Google在评价摘要文档中加入关于虚假评价和未披露激励评价的要求。官方更新记录将它列为文档规则补充，不能把它当成一次核心算法发布。本文于9月21日重新核对相关文档，按已有网站的修正过程展开。
先确定评价对象，再看插件字段
一条关于收纳盒实际使用的反馈，与一条称赞商家服务的反馈，描述的是不同对象。前者要对应具体产品，后者则可能属于组织口碑。不要先在插件里选一个看起来容易出星级的类型，再把内容硬套进去。
Google的评价摘要指南对LocalBusiness及Organization的自我评价有额外限制：被评价实体控制自己网站上的评价时，该页面不符合这种星级展示资格，嵌入第三方组件也不会改变这一点。指南还要求评价针对具体对象，不能把其他网站的评分直接汇总为本站评价。
例如，建站公司在“关于我们”展示真实客户故事，可以帮助访客了解合作体验；但换一个Product类型，不能把原本评价公司的内容变成具体商品评价。同理，分类页上的“客户都很满意”，不能直接当成下面所有型号共用的产品评分。
这一步会决定修正方向：有的页面需要纠正标记，有的需要拆清评价对象，有的只是合理展示客户故事而不争取该星级形式。页面内容与转化检查可以结合页面SEO清单进行。
一条评价，追到提交记录和前台展示
新要求同时涉及页面内容与结构化数据。没有真实体验的评价，以及获得好处但没有清楚、显著披露关系的评价，都不能仅靠JSON-LD语法正确获得资格。披露也不等于自动满足其他全部条件。评价摘要技术要求
实际排查时，先选一条评价，从原始提交记录往前台追。最好使用插件中的记录编号或导入行号，不只凭作者昵称；同名作者、译文和重复导入都可能让人工匹配出错。
假设一位用户收到免费收纳盒样品，提交了真实使用反馈。运营记录中写着试用安排，导入网站时却只保留了星级与正文。问题发生在信息转移过程中：掌握样品安排的人知道这层关系，读者却看不到。
沿着同一条记录，核对以下四处：
- 原反馈对应哪件产品，是否确有体验。
- 活动记录中有没有赠品、折扣或其他安排。
- 导入字段是否把该关系带进前台评价。
- 手机上的卡片能否清楚读到披露文字。
如果后台保存了样品说明，前台却没有，修正字段映射或卡片输出后，应重新检查这条记录；重复导入前先核对编号，避免同一反馈被算两次。
文案可以直说“该用户收到本产品的免费试用样品”，前提是实际安排确实如此。不要给所有旧评价统一补一个合作标签，也不要为找不到来源的文字补造使用经历。
评分数量和文字评论数量，不要混算
假设某产品有五条评分：5、4、5、3、5。总分22，平均4.4。核查后确认其中一条5分没有真实体验，将其移除，剩余总分17、四条评分，平均4.25。
此时前台若显示一位小数，可以按网站统一的舍入规则展示；评分数量及标记也要使用同一批有效记录。不能页面已经移除一条，插件仍输出原来的五条与4.4。
还有一种常见情况：新增一位用户只写了评论，没有给星。它可以增加文字评论数量，但不应被当成0分拉低平均值，也不能为了凑齐字段由编辑替他填写5分。
| 自拟记录状态 | 进入评分平均值吗 | 核查重点 |
|---|---|---|
| 四条有效数字评分 | 按真实分值计算 | 当前合计17，平均4.25 |
| 新增一条无星级文字评论 | 不凭空补分 | 单独识别文字评论计数 |
| 已确认虚假的5分记录 | 移出展示与计算 | 同步前台、缓存和标记 |
字段名称也有区别：官方将ratingCount定义为评分总数，reviewCount对应提供评论的人数，有无随附评分都可能计入。不能因为两个字段都像“评价数”，就永远填写同一个数字。按实际插件的数据模型核对，也要解释前台“评分”与“评论”各在统计什么。字段定义
把计数落到这个例子里，还需要补一个条件：假设剩下四位评分者中只有两位写了文字评论，后来又新增一位只写评论、不打分的用户。此时ratingCount为4，reviewCount为3，平均分仍为4.25。前台可分别标明“4次评分”“3条评论”，不应把五位参与者统称为“五个星级评分”。这里人数关系是为演示另行设定的，真实页面必须从自己的有效记录计算。
这个例子用于说明数据修正的连带影响，不是建议挑选高分或删除负评。真实低分同样属于实际用户体验。
WordPress修正，要定位谁在输出数据
主题、商品组件、评价插件和SEO插件都有可能输出结构化数据。某个后台开关关掉了，另一个组件仍在生成旧值，这时反复改同一个设置不会解决问题。
先记录一个公开产品URL，查看前台评价、汇总数字及Rich Results Test识别到的评价对象。然后按对象名称、类型和标识查对应输出来源。若多个节点描述不同对象，不必为了“只剩一条”全部删除；需要处理的是同一个对象的矛盾数据，或不该出现在该页面的标记。
可以把一次修正记录成：原记录范围是什么，哪个组件计算平均值，哪个组件输出标记，前台从哪里加载评价。修改数据后，清理相关缓存，再从未登录的公开页面复查。后台预览正确而访客页仍旧，往往说明修改尚未进入实际交付给用户的版本。
工具通过也只完成了技术检查的一部分。Google的通用结构化数据指南说明，自动测试不能识别所有质量问题，合格标记也不保证显示富结果。客户是否真的用过产品，仍要回到评价来源判断。
历史导入缺资料，先缩小到受影响批次
找不到证据与已经确认造假，是两种状态。对于多年导入的数据，先确定是哪批文件、哪些产品和哪些字段缺失；暂停继续按同一方式导入，再向掌握活动资料或客户反馈的人补核。
例如，某批试用反馈全部缺少激励说明，就重点追查活动安排及导入字段，而不必先给整站所有自然购买评价加标签。若只有某型号的评价被错误映射到另一个型号，则应修正对象归属，同时重新计算受影响页面的数字。
无法确认真实性和展示条件的记录，不应继续作为已经核实的推荐证据使用。可以先保存内部排查记录，处理前台和标记中的问题，再根据找回的真实资料决定如何恢复。不要为了保住原来的评分，反过来改写原始反馈。
改完以后，看内容、标记和报告三个结果
完成修正后，按读者实际看到的顺序验收：
- 打开那款产品，找到原记录编号对应的反馈，确认产品、正文和试用说明没有错配。
- 对照同一批有效记录，重算平均分与两类数量，再核对前台和公开标记。若页面已经是4次评分，标记还是5次，继续查计算来源或缓存。
- 用Rich Results Test查看对应对象；再查看Search Console是否有问题或人工处置提示。不要把“工具未报错”写成“评价真实性已核实”。
记录修正日期、URL和受影响范围，便于之后比较。星级没有立即出现，不足以证明修正失败，也不能仅凭一次搜索看不到星级就判定受罚。若存在结构化数据人工处置，应按具体报告处理；这类富结果资格问题也不等同于网页必然退出普通搜索。通用指南
如果同时发生流量下降，另行比较查询、页面和时间，按Google更新期间的检查顺序定位原因。把这次评价修正保留为独立记录，才能看清实际改过什么，而不把同期所有变化都归到7月的这条要求上。
常见问题
真实试用评价补上披露，就一定能显示星级吗？
披露只解决关系透明的问题，还要看评价对象、实际内容和其他资格条件。Google也不保证合格页面一定显示星级。
只删除JSON-LD中的虚假评价够吗？
不够。页面仍然展示虚假推荐时，内容问题还在。需要同时处理用户可见内容、汇总计算及实际输出标记。
一条没有星级的文字评论要按0分计算吗？
不要补造数字评分。评分数量、评论数量和平均分应按真实记录分别计算，并核对插件使用的字段含义。
公司官网嵌入外部评价组件能避开自我评价限制吗？
不能这样推断。Google明确将相关第三方嵌入列入自我评价限制的例子，关键仍是评价对象和控制关系。