Review 与 AggregateRating 标记教程

想让搜索引擎和 AI 引擎在结果里显示"★★★★☆ 4.6 分（128 人评）"，做法不是堆一段 schema 就行：Review 标记用来标注单条评价，AggregateRating 标记用来标注这堆评分的汇总值，两者必须挂在同一个被评对象上，且分数必须在页面上真实可见、来自真实用户提交。缺任何一条，富摘要就不会出现。

Review 和 AggregateRating 有什么区别？

结论：Review 描述的是一条具体评价（谁、什么时候、打几分、说了什么），AggregateRating 描述的是多条评分的统计结果（平均分、参评人数、满分制）。

两者是"个体"和"汇总"的关系，可以单独用，也可以嵌套在一起。字段对应关系如下：

• Review 的核心字段：author（Person 或 Organization，不能匿名）、datePublished、reviewRating（类型是 Rating，不是 AggregateRating）、reviewBody
• AggregateRating 的核心字段：ratingValue（平均分）、bestRating（默认 5）、worstRating、ratingCount 或 reviewCount

ratingCount 与 reviewCount 的区别常被写错：ratingCount 统计所有打分（包括只点星没写字的），reviewCount 只统计带正文的评价。论坛场景绝大多数是"点星为主"，用 ratingCount 更贴近事实。

AggregateRating 的最小可用 JSON-LD 怎么写？

结论：一个能通过校验的 AggregateRating 最少需要 @type、ratingValue、ratingCount 四个字段里的三个，加 bestRating 更稳妥。

{
  "@context": "https://schema.org",
  "@type": "DiscussionForumPosting",
  "headline": "Clara BBS 怎么开启 Redis 缓存",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "bestRating": "5",
    "worstRating": "1",
    "ratingCount": "128"
  }
}

三个硬性约束：ratingValue 必须和页面上显示的数字完全一致（页面写 4.6，标记就不能写 5 或 4.60 之外的加工值）；用 10 分制必须显式写 bestRating: "10"，否则默认按 5 分制解析；同一页面同一对象只输出一次 aggregateRating，重复会被判为冲突。

怎么把 Review 嵌进 AggregateRating？

结论：Review 用数组挂在被评对象的 review 属性上，与 aggregateRating 平级，不是嵌套进 aggregateRating 里面。

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "示例产品",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "ratingCount": "36"
  },
  "review": [{
    "@type": "Review",
    "author": { "@type": "Person", "name": "阿乐" },
    "datePublished": "2025-03-18",
    "reviewRating": { "@type": "Rating", "ratingValue": "5", "bestRating": "5" },
    "reviewBody": "装完即用，后台开启 Redis 只点了两下。"
  }]
}

注意 reviewRating 里写的是 Rating，不是 AggregateRating——这是校验报错里出现频率最高的一处。

为什么标记写了星级却不显示？

结论：最常见的原因不是代码写错，而是评分对象不满足 Google 的展示政策，或者页面根本看不见分数。

高频原因有四个。第一，自评不展示：Organization、LocalBusiness 给自己的站点打分属于 self-serving review，政策明确不展示。第二，可展示类型很窄：2019 年之后 Review 富摘要大幅收缩，目前稳定出星的主要是 Product、Book、Recipe、Course、Event、Movie、Software App 等，普通 Article 或论坛帖的星级大多不出现在搜索结果里——但结构化数据仍会被 AI 引擎读取，用于判断内容质量与引用优先级。第三，分数没在页面上以文字或星星形式露出，只有 JSON-LD 里有。第四，JSON-LD 由 JS 在交互后才注入，爬虫首屏拿不到。

结论：即使不出星级，AggregateRating 依然值得做——它让 AI 引擎拿到"这篇内容被多少人认可"的量化信号，这是纯文本抓取拿不到的信息。

在 Clara BBS 里怎么落地？

结论：Clara BBS 内置帖子评分功能，读者给文章打 1-5 星，均分直接写入结构化数据，不需要手动改模板。

具体做法是：帖子页开放评分后，读者点星提交，系统把均分与参评人数写进该页的结构化数据，帮助搜索引擎在结果页展示星级富摘要。配套能看到效果的地方有三处：后台「系统设置 → GEO 优化」查看 AI 爬虫访问监控（哪个爬虫、抓取频率、最近抓的页面）；「内容可见性反馈」插件在帖子页展示该内容是否已被收录进 AI 知识库、是否生成 AI 摘要、结构化数据输出情况；「单篇 GEO 体检」插件检测任意帖子的收录状态、爬虫到访与结构化数据输出，生成可视化报告。

均分属于典型热点数据，走系统内置的 Redis 与文件双驱动缓存（后台「系统工具 → 缓存设置」可视化开启，Redis 异常自动降级文件驱动），不必每次请求都重算。全站 GEO 输出只包含游客可见版块内容，隐藏或权限版块不会外泄。

上线前要过哪几道检查？

结论：上线前至少跑三件事——富媒体搜索结果测试、Schema Markup Validator 校验、页面可见性人工核对。

具体步骤：用 Google 富媒体搜索结果测试粘贴 URL 或代码，看能否被识别为合格类型；用 Schema Markup Validator 只校验语法与字段完整性（它不管展示政策）；打开页面肉眼确认分数、人数与 JSON-LD 一一对应；把 ratingValue 保留一位小数并与前端显示格式统一；评分变化后确认输出同步更新，别出现"页面 4.2、标记 4.6"的错位。

收尾一句：Review 管单条、AggregateRating 管汇总，字段别写错类型、分数别脱离页面、类型别超出可展示范围，剩下的交给真实用户去打分。