关闭

Tryaivo™技术

Review标记踩新规:星级被人工处置收回

2026-11-08 02:38:06 浏览:

一句话结论:Google 在 2026 年 7 月 24 日的 review snippet 文档里把"未披露的激励评价"写成了禁止项,踩线的后果不是排名下滑,而是结构化数据被单独作废、星级整块消失——而大部分站点的暴露点是"折扣码换评价"这种无意识操作。

背景:评分富媒体是最赚的一块,也是最脆的一块

Review 与 AggregateRating 是搜索结果里少数几个直接作用于点击率的元素:星级不改变排位,但同一排位下变成点击的比例会差一大截。也正因为如此,Google 对它的处置方式和其他垃圾内容不一样——不降权,直接让你这块标记失效,页面照旧在索引里。

2026 年 7 月 24 日更新后的原文表述是:"Don't include fake or undisclosed incentivized reviews on your page or in your structured data markup." 注意中间那个词:激励评价本身没被禁,被禁的是拿了好处(钱、折扣、代金券、免费产品)却*没有清晰显著披露*的评价。

适用范围比多数人以为的宽。Review snippet 可以出现在 Book、Course list、Event、Local business、Movie、Product、Recipe、Software App 上,涉及的类型还包括 Game、MediaObject、MusicRecording、Organization。也就是说,一个 SaaS 在 Organization 标记里挂 AggregateRating,同样在规则覆盖范围内;本地商家在 LocalBusiness 上挂评分,也一样。

执法路径:据 PPC Land 2026 年 7 月 24 日的报道,后果是 Search Console 里的人工处置通知,标记被忽略、页面仍在索引(这一具体后果我们标注为该来源的描述,Google 自己的 manual actions 文档只写了通用后果:站点部分或全部内容不展示)。

落地清单:先判风险,再改标记

1)五类隐蔽激励,逐条对照

这五条基本覆盖了中小站点的全部暴露面,绝大多数是"不小心"而不是"故意买评":

  1. 购后折扣邮件:"留个评价,下次下单打九折。"——代金券换评价,产出的评价在展示处必须披露。

  2. 免费样品:给创作者、测评组、试用团寄样,写出来的内容被当作评价或客户见证上墙。

  3. 联盟榜单:你拿佣金的"best of"页面给产品打分,佣金是与结果挂钩的好处;这类页面同时也贴着 thin affiliate 人工处置的边。

  4. 员工与关联人评价:员工、外包、创始人家属评价产品而不说明身份。

  5. 抽奖换评价:"评价即可参与抽奖"——中奖机会也是好处。

2)披露只能放两处,且必须同时满足

"清晰显著"落到执行上只有三条硬要求,第一条最容易做错:

  • 写在评价旁边,不是写进政策页。条款里一句"部分用户会获得免费产品",相对于读者正在看的那一条评价,不构成显著。

  • 页面上看得见,不能只写在 JSON-LD 里。规则同时点名 "your page" 和 "your structured data markup";隐藏内容本身也是结构化数据人工处置的触发项。

  • 写具体。"Sponsored" 太模糊,"该用户免费获得产品""该评价以九折优惠码为交换"才叫说明了是什么。

可直接粘贴的披露文案,放在评价人名称下方或正文上方:

激励披露:该用户以九折优惠码为交换提交本条评价,评价文字未经我方修改或审核。

(第二句不是 Google 要求,但能回答读者下一个疑问——披露做得好是加分,做得敷衍是伤害。)

3)JSON-LD 改法:补字段,不要删标记

最容易犯的错是一刀切:把全站 Review 和 AggregateRating 删干净,问题没了,资产也没了。真实评价只要必填项齐全,资格照旧。必填项按 Google review snippet 文档(2026-07-24 版):author、itemReviewed、reviewRating(内嵌 ratingValue)、name;聚合评分侧 ratingValue 必填,reviewCount 或 ratingCount 至少给一个。

整改前(我们审计脚本判定 FIX 的形态):

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Sample Air Fryer X2",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "250"
  },
  "review": [
    {
      "@type": "Review",
      "reviewRating": { "@type": "Rating", "ratingValue": "5" },
      "author": { "@type": "Person", "name": "A客户" }
    }
  ]
}

问题:Review 缺 itemReviewed、缺 datePublished,聚合评分没给 bestRating/worstRating,页面正文也没有任何激励披露。

整改后:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Sample Air Fryer X2",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "250",
    "bestRating": "5",
    "worstRating": "1"
  },
  "review": [
    {
      "@type": "Review",
      "itemReviewed": { "@type": "Product", "name": "Sample Air Fryer X2" },
      "reviewRating": { "@type": "Rating", "ratingValue": "5", "bestRating": "5" },
      "author": { "@type": "Person", "name": "A客户" },
      "datePublished": "2026-10-12",
      "reviewBody": "用了一周,炸薯条很脆。"
    }
  ]
}

4)注入位置:SSR 输出,别在客户端拼

JSON-LD 必须在服务端渲染时就进 HTML。Next/Nuxt 里用客户端 useEffect 注入,常见结果是:Googlebot 首次抓取拿到空 body,标记时有时无;同时和 GSC 里"检测到但未展示"的沉默失败互相掩盖。EyouCMS、Dedecms 这类模板站点,直接把 <script type="application/ld+json"> 放在详情页模板的 {/eyou:arclist} 循环外、</head> 前,字段从数据库字段取,不要写死。

5)自查:一个能跑的审计脚本

人工翻页查不现实,下面的脚本抓页面 JSON-LD、遍历 @graph 与嵌套结构,比对必填项,同时检查页面可见文本里有没有披露语句:

import sys, json, re, urllib.request

REQ_REVIEW = [&#x27;itemReviewed&#x27;, &#x27;reviewRating&#x27;, &#x27;author&#x27;]
DISCLOSURE = [&#x27;incentive disclosure&#x27;, &#x27;in exchange for&#x27;, &#x27;received the product free&#x27;, &#x27;激励&#x27;, &#x27;优惠码&#x27;]

def blocks(html):
    for m in re.finditer(r&#x27;<script[^>]+application/ld\+json[^>]*>(.*?)</script>&#x27;, html, re.S | re.I):
        try:
            yield json.loads(m.group(1).strip())
        except Exception:
            yield {&#x27;__parse_error&#x27;: True}

def walk(node, want):
    if isinstance(node, dict):
        t = node.get(&#x27;@type&#x27;)
        ts = t if isinstance(t, list) else [t]
        if any(x in want for x in ts if x):
            yield node
        for v in node.values():
            yield from walk(v, want)
    elif isinstance(node, list):
        for v in node:
            yield from walk(v, want)

def visible(html):
    t = re.sub(r&#x27;<script.*?</script>|<style.*?</style>&#x27;, &#x27; &#x27;, html, flags=re.S | re.I)
    return re.sub(r&#x27;\s+&#x27;, &#x27; &#x27;, re.sub(r&#x27;<[^>]+>&#x27;, &#x27; &#x27;, t)).lower()

html = urllib.request.urlopen(sys.argv[1], timeout=20).read().decode(&#x27;utf-8&#x27;, &#x27;ignore&#x27;) \
       if sys.argv[1].startswith(&#x27;http&#x27;) else open(sys.argv[1], encoding=&#x27;utf-8&#x27;).read()

reviews, aggs = [], []
for b in blocks(html):
    reviews += list(walk(b, {&#x27;Review&#x27;}))
    aggs += list(walk(b, {&#x27;AggregateRating&#x27;}))

for r in reviews:
    miss = [k for k in REQ_REVIEW if not r.get(k)]
    print(&#x27;Review&#x27;, r.get(&#x27;author&#x27;), &#x27;missing:&#x27;, miss or &#x27;none&#x27;)
for a in aggs:
    print(&#x27;Agg&#x27;, a.get(&#x27;ratingValue&#x27;), a.get(&#x27;reviewCount&#x27;) or a.get(&#x27;ratingCount&#x27;),
          &#x27;missing:&#x27;, [k for k in [&#x27;ratingValue&#x27;] if not a.get(k)] or &#x27;none&#x27;)
print(&#x27;visible disclosure:&#x27;, any(d in visible(html) for d in DISCLOSURE))

对同一页面的整改前、整改后两个版本实跑,输出如下(脚本完整版见同目录,判定逻辑为必填项缺失即 FIX):

版本Review 缺失字段AggregateRating可见披露结论
整改前itemReviewed完整无FIX
整改后无完整(含 best/worstRating)有PASS

6)验证工具

  • Google Rich Results Test:看 Review snippet 是否被识别,报错会直接点名缺哪个属性。

  • Schema.org Validator:查语法与类型合法性(注意它只管语法,不管 Google 的展示政策)。

  • GSC「评价片段」报告 +「人工处置」报告:前者看有效/无效项数量,后者看有没有已经下发的处置。有处置时按页面模式逐条修、修完再提交复审申请,别先提交再修——复审时钟会重置。

结果:这套改动能测到什么

诚实说:这一轮公开可查的量化数据几乎没有。新规 2026 年 7 月 24 日生效,到本文复盘时间(2026-11-08)不足四个月,Google 没有发布任何关于处置数量或恢复周期的统计,也没有第三方复现研究。

能给出的只有定性观察,且标明口径:

  • 有折扣码换评价历史的品类(小家电、美妆、SaaS 免费试用),在 GSC 评价片段报告里的"无效项"数量在补齐字段后归零;

  • 页面可见披露补上之后,客服侧"这条好评是不是刷的"类质疑明显减少(内部工单口径,非外部数据);

  • 星级恢复没有公开的时长基准。Google 文档写复审"需要数天到数周",这指的是人工处置复审,不等于标记恢复展示的时间。

不要拿"我们补了披露,星级一周内回来了"当因果结论——同期可能有算法重算、站点权重变化在起作用,没有对照组就不是效果数据。

复盘:三条动作 + 两条红线

可以直接抄的三条:

  1. 全站导出评价类 JSON-LD,先跑一遍上面的脚本,把 itemReviewed、datePublished、reviewRating.ratingValue 缺失的页面列成清单,按页面模板批量补,不要逐页改。

  2. 凡是评价来源带任何好处(折扣、样品、佣金、抽奖),在评价人名称下方加一句具体披露,同一条文案同时出现在可见正文和 reviewBody 里。

  3. JSON-LD 走 SSR 输出,模板层面注入,禁止客户端拼接。

两条红线:

  1. 别整体删标记。删掉 Review 和 AggregateRating 等于把展示资格一起扔掉,真实评价只要字段齐全本来就合规。

  2. 别把披露只写进 JSON-LD。规则同时管页面和标记,只藏在结构化数据里的披露视为隐藏内容,属于另一条独立的处置触发项。


标注:Schema.org 版本 v30.1(2026-09-16 发布,2026-11-08 查询,来源 schema.org/docs/releases.html);Google review snippet 文档版本 2026-07-24 UTC(本次直连抓取超时,原文表述经 builtplain.com 2026 年 7 月同期分析与 PPC Land 2026-07-24 报道交叉核对,标注为二手转述)。美国的独立法定义务见 FTC《消费者评价与推荐使用规则》16 CFR Part 465(2024-08-22 发布于 89 FR 68077),条款编号为公开信息,具体罚则未在本文引用。验证工具:Google Rich Results Test、Schema.org Validator、Search Console。复盘时间 2026-11-08。本文脚本在本地对整改前后两版样例实跑,未对真实站点批量执行。

标签:Schema.org、结构化数据、JSON-LD、AI可见度、GEO、Review、AggregateRating