本文约 3,844 字，预计阅读 10 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：五星好评挂上去那天，风险也挂上去了
星级评分（review snippets）是最立竿见影的富媒体形态：搜索结果里那排金黄的星星，能显著抬高点击率。正因为有用，它也是历史上 Google 出手最重的类型之一——2021 年前后，大量站点收到了标题为”结构化数据不符合 Review snippets 准则”的邮件人工处理通知，星星整片消失。最典型的违规形态是”自评自测”：一家本地服务商在自己的服务页面上，用自己录入的客户好评，给自己标了 5.0 分 48 条评价；或者一个跨境电商把自己的产品引导文案打包成 Review 节点。当事人往往很委屈——”评价是真的啊”。但 Google 的规则从来不是”内容是否真实”，而是”标注关系是否违规”。把这条线划清楚，比纠结星星能不能显示重要得多。
原理分析：政策管的是关系，不是真假
Google 的 Review snippets 政策有几条硬约束：
第一条，禁止自评自测（self-serving reviews）：如果评论内容是关于某个组织或个人，而它被放置在该组织或个人控制的网站上，则不符合资格。这里的关键是”控制”，不是”真假”。你在自家官网放自己写的产品评论，无论评价多真实，都属于此类。
第二条，被标记的内容必须可见：reviewCount、ratingCount、ratingValue 三个值必须在页面上对用户可见，且与实际展示的数据一致。
第三条，禁止把评论区以外的东西当 Review：例如把第三方豆瓣评分、无关行业的奖项、内部质检报告塞进去。
第四条，Freshness 与去重：翻页隐藏的评价不应被汇总，重复内容会被过滤。
| 标注主体 | 放在谁的页面上 | 是否合规 |
|---|---|---|
| 第三方用户对 A 产品的评价 | A 商家自己的商品页 | 合规（需真实可见） |
| A 商家自写的产品测评 | A 商家自己的商品页 | 违规（自评自测） |
| 第三方用户对 A 商家服务的评价 | 第三方评测站 | 合规 |
| A 商家为自己录入的好评 | A 商家的服务页 | 违规 |
| 用户在站内评论区写的评分 | 同一商品页 | 合规（前提是真用户 + 可见） |
对 LocalBusiness 还有一个额外限制：Google 明确不接受 LocalBusiness 节点上的 aggregateRating 如果这些评价是由站方自己收集并展示在服务对象自己的页面上。很多 LocalBusiness 插件默认就输出这笔数据，风险恰恰在这里。LocalBusiness 自身的字段写法见LocalBusiness 结构化数据（本地业务）。
保姆级实操
第一步：分清你的页面属于哪一格
按上面的表对号入座。如果是”自家页面标自家评价”，直接跳过 Review/AggregateRating，只保留 Product 或 Service 的基础字段。这一步用纸笔就能判断，不需要工具。
第二步：确保两个数字在页面上真看得见
让插件输出的评级必须在 DOM 里能找到对应的”共 48 条评价，平均 4.8 分”。
add_action( 'woocommerce_single_product_summary', function () {
global $product;
if ( ! wc_review_ratings_enabled() ) {
return;
}
/** @var WC_Product $product */
$count = $product->get_review_count();
$avg = $product->get_average_rating();
if ( $count < 1 ) {
return;
}
echo '<div class="mimangfei-rating-summary">';
echo esc_html( sprintf( '平均 %.1f 分，共 %d 条用户评价', $avg, $count ) );
echo '</div>';
}, 6 );
第三步：零评价时不要输出 AggregateRating
这是最容易被默认配置坑到的一条。条件判断要放在 schema 生成链路，不是放在显示链路。
add_filter( 'woocommerce_structured_data_product', function ( $markup, $product ) {
$count = $product->get_review_count();
if ( $count < 1 ) {
unset( $markup['aggregateRating'], $markup['review'] );
return $markup;
}
/** @var WC_Product $product */
$markup['aggregateRating'] = [
'@type' => 'AggregateRating',
'ratingValue' => (string) $product->get_average_rating(),
'reviewCount' => (int) $count,
'bestRating' => '5',
'worstRating' => '1',
];
return $markup;
}, 15, 2 );
第四步：把关等级插件不要自动搬运第三方数据
聚合平台评分、App Store 评分、社媒评分都不该被搬运。若必须引用，要在页面明确标注出处，并且不要把它们写成 AggregateRating。
第五步：爬取自己的 SERP 表现
上线后用 Rich Results Test 确认星星不被报错，并每隔一段时间在 Search Console 的 Review snippets 报表里查看未预期回落。
第六步：定期审计全站的评分节点
一次预处理能揪出模板升级带来的回退：
for u in $(curl -s https://mimangfei.com/wp-sitemap-products.xml | grep -o '<loc>[^<]*</loc>' | sed 's/<[^>]*>//g'); do
curl -sL "$u" | python -c "
import sys,re
h=sys.stdin.read()
print('$u', 'AggregateRating' if 'AggregateRating' in h else '-', 'reviewCount' if 'reviewCount' in h else '-')
"
done
常见踩坑
- 把 KPI 自测分当 AggregateRating：内部质检 4.9 分 ≠ 用户评价，属于典型的自评自测。
ratingValue用浮动-number 而不同 string：浮点精度会让程序往返解析出问题，官方推荐字符串或保留一位小数。- 评价数满了就用
reviewCount写ratingCount混用：两者含义不同，评论型用 reviewCount，纯评型用 ratingCount，不要互相替换。 - 极小的样本也输出：只有 2 条评价就挂星星，虽然不一定违规，但用户体验与信任度都受损，建议设阈值 5 条以上。
- 本地服务商侥幸心理：LocalBusiness 自评被处理的案例非常多，不要以为”本地板块没人查”。
- 案例：某英语培训机构在官网每个校区页输出 LocalBusiness 并挂上 5.0/126 条 aggregateRating，这些评价来自销售在签约现场引导客户填写的表单。半年后该域收到人工处理，全部校区的星星消失，且 GSC 明确提示营销页展转点弊端的描述。整改时他们删掉了全部 aggregateRating 节点，改为在页面展示真实评价并与第三方平台数据对齐，四个月后部分恢复。教训是：自评损失的从来不只是星星，还可能是整站富媒体资格。
- 把缓缓上升的 average rating 四舍五入到 5.0：与页面显示不符属于字段不一致，比自评更容易触发机械性报错。
总结
判断标准只有一句话：这个评分，是不是”站方控制者拿来评价自己”。若是，无论真实与否都别标。行动清单：按归属表格逐页分类 → 无真用户评价则不输出 → reviewCount/ratingValue 必须页面可见并与 DOM 一致 → 禁止搬运第三方评分 → 设阈值与定期全站审计脚本。星星带来的是短期点击，人工处理带走的是长期资格，这笔账很容易算清楚。想一起把商品侧的字段配好，可以接着读Product / Offer 结构化数据配置（电商）。
