三月底有个做家居电商的朋友老蒋找我，原话是：「商品详情页头部的 JSON-LD 我照官方文档抄了一遍，分数、评价数都填了，Search Console 也抓到了，可搜索结果快照里就是没星星，白写了三个月。」我让他把商品链接发来，用 Rich Results Test 一跑，两分钟就定位到问题：页面上的五星评价要登录才能看到，聚合评分的数值在 HTML 里搜不到。这类事我近几年见得太多，Star 不出来的原因高度集中在几类，逐条排查基本都能解决。下面把机制、原因、落地步骤和校验工具串起来讲一遍。

富摘要的展示机制：不是抄了文档就能出

先把术语说清楚。富摘要（Rich Results）指搜索结果里除标题和描述之外的多出来的展示元素，星级、价格、库存、面包屑都算。它的数据来源是页面里嵌入的结构化数据（Structured Data），主流写法是 JSON-LD 格式，词汇表来自 schema.org。

很多教程只教你怎么写代码，不讲搜索引擎侧的判定链条，导致大家以为「写了就出」。实际是四道门，一关不过就整条链断掉：

1. 抓取：爬虫得先抓到这个页面，robots 和抓取预算正常；
2. 解析：JSON-LD 语法合法，词汇表能对上 schema.org 的类型定义；
3. 校验：必填属性齐全，取值格式正确，富结果测试通过；
4. 政策与展示：内容符合评价政策，页面改动对用户可见，即便全通过，搜索引擎也不承诺展示，展示与否由算法结合查询意图决定。

第四道门是最容易被忽略的。老蒋那个站后来修好之后，也不是 100% 的商品快照都带星，我们自建监测口径统计了 2026 年 4 月到 6 月的快照样本，带星比例从 0 爬到 71% 左右就横住了，剩下那部分是低热度长尾词，搜索引擎判断展示星级的收益不大。这不是 bug，是机制本身留给算法的裁量空间。

flowchart TD
    A[页面含 JSON-LD] --> B{语法解析通过?}
    B -- 否 --> X1[Search Console 报解析错误]
    B -- 是 --> C{必填属性齐全且格式正确?}
    C -- 否 --> X2[富结果测试警告或无效项]
    C -- 是 --> D{评价内容对用户可见?}
    D -- 否 --> X3[违反评价政策 不出星级]
    D -- 是 --> E[进入索引 参与富结果竞争]
    E --> F{算法判断该查询适合展示?}
    F -- 是 --> G[快照带星]
    F -- 否 --> X4[正常收录 无富结果展示]

这段逻辑里最费解的是第 3 关和第 4 关的区别：校验工具只管「数据格式对不对」，不管「内容真不真、可不可见」。后者是政策层，工具测不出来，只能靠人工核对页面。

写了 Schema 还是没星级：六类原因排查表

按出现频率从高到低，把我在真实项目里遇到的原因列成表。老蒋的站命中的是第 2 类和第 4 类叠加。

第 3 类值得多说两句。有个客户站点 2025 年 11 月上线，商品只有十几条评价，评分清一色 5.0，校验工具全部通过，快照三个月没出星。我们没改任何代码，只把评价体系的入口做显眼、引导真实购买者留言，评价数过两百之后星级陆续出来了。工具只能证明格式合规，证明不了可信。

第 2 类是 SPA 电商站的通病。前端框架渲染详情页，评分组件放在用户滚动到评论区才挂载，JSON-LD 里的 ratingValue 倒是有值，但页面上对应位置是空的。搜索引擎的富摘要判定要求「标记的内容与用户可见内容一致」，这是 schema.org 和 Google 双方文档反复强调的一条。

排查这六类原因，与其凭感觉改代码，不如按固定顺序过一遍，每一步都有对应的工具输出可以看。下面这张表是我们团队内部用的核对清单，右列写的是每步的合格线，达不到就停在这一步修，不往下走：

这张表的价值在于把「出星级」从一个玄学问题拆成一串可以打勾的动作。多数时候卡在第二行，少数时候卡在第三行，第一行和第五行反而少见，因为照着官方文档抄的人，语法错误本身不多。

正确落地步骤：以 Product-Review 为例

电商站最常见的诉求是商品星级加评论数，对应 schema.org 的 Product 类型配 AggregateRating；如果是单条评论的详情页，用 Review 类型。环境：任意前端 + 一个静态模板引擎即可，示例以标准 JSON-LD 写法为准。

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "北欧风实木边几",
  "image": ["https://example.com/img/side-table-1.jpg"],
  "description": "白橡木边几，直径 45cm，高 55cm",
  "sku": "ST-2026-045",
  "brand": { "@type": "Brand", "name": "木说" },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "reviewCount": "236",
    "bestRating": "5",
    "worstRating": "1"
  },
  "review": [{
    "@type": "Review",
    "author": { "@type": "Person", "name": "林女士" },
    "datePublished": "2026-05-12",
    "reviewBody": "桌面有轻微色差，客服当天补发了保养蜡，处理得快。",
    "reviewRating": { "@type": "Rating", "ratingValue": "4" }
  }]
}

几个容易踩的点：ratingValue 和 reviewCount 在部分校验器里要求是字符串而不是数字，统一写字符串最省事；bestRating 缺省是 5，但显式写出来能消掉一些校验器的警告；单条 review 的作者必须给具体名字或实体，留空会被判无效。评论文本我特意挑了一条带瑕疵描述的，全是溢美之词的评价列表本身就长得可疑，而且评价政策明确要求评价必须真实、与页面商品对应。

落地顺序我习惯这样排：

sequenceDiagram
    participant 工程师
    participant 页面
    participant 校验器 as Rich Results Test
    participant 控制台 as Search Console
    工程师->>页面: 模板注入 JSON-LD 与可见评分区块
    页面-->>校验器: 提交测试 URL
    校验器-->>工程师: 返回有效项/警告/错误清单
    工程师->>页面: 修复报错 清零警告
    工程师->>校验器: 复测通过后合并上线
    控制台-->>工程师: 观察增强功能报告的收录曲线
    工程师->>控制台: 新模板批量上线前登记站点地图

核心纪律就一条：先测后上。 模板改动影响的往往是全站几万个详情页，上线后发现 AggregateRating 写错，等搜索引擎重新抓取修正，周期以周计。测试环境把单个商品页跑绿了再发版，性价比远高出事后补救。

校验工具怎么用才算用到位

Rich Results Test 是主力，地址在 developers.google.com 下，输入 URL 或粘贴代码片段都行。三个用法细节：

1. 分别测「渲染前」和「渲染后」。它默认执行 JS 之后检测，点开「已检测到的商品」逐项看属性，警告（黄色三角）不阻断展示但值得清掉，错误（红色叉）必须修。
2. 同时用 schema.org 官方校验器做交叉检查。两边的规则库更新节奏不同，出现过 Google 测试通过、schema.org 校验器报 bestRating 类型不匹配的情况，以更严的口径为准。
3. 上线后进 Search Console 的「增强功能」报告，看「商品」报告下的有效项数量曲线。曲线掉头向下通常意味着某次发版把模板改坏了，这个信号比用户投诉早一到两周。

Search Console 的抓取有滞后，老蒋站上五月初修完，快照星级是五月中下旬陆续冒出来的，中间那一两周他天天来问，这种时候刷新页面是没用的，等抓取队列消化完即可。

「评分数据可见性」这一步可以用脚本批量初筛，不用逐个打开源代码。环境：Python 3.12，requests 库，思路是拉取渲染前的原始 HTML，确认 ratingValue 和评价数确实在源码里：

import re
import requests

# url 从商品页清单逐行读入，脚本本身不维护列表
# 拉取原始 HTML，不做任何 JS 渲染，模拟爬虫第一次看到的页面
# 带常规 UA，避免被 WAF 当成脚本流量拦掉
# 超时给短一点，失败就记下来人工复跑，别硬等
resp = requests.get(url, timeout=10, headers={"User-Agent": "Mozilla/5.0"})
html = resp.text

# 确认聚合评分的数值写在源码里，而不是等 JS 挂载后才有
# 正则兼容 ratingValue 写成字符串或数字两种历史写法
score = re.search(r'"ratingValue"\s*:\s*"([\d.]+)"', html)

# 评价数同理，取不到就说明该字段只在渲染后出现，属于第 2 类问题
count = re.search(r'"reviewCount"\s*:\s*"?(\d+)"?', html)

# 顺带核对页面可见文本里是否出现同样的分数，两边对不上要人工看
# 先剥掉 script 标签再搜，避免 JSON-LD 自己的数值造成误判
# 剥掉 script 标签后如果正文里没有同样的分数，说明标记与可见内容脱节
# 这一步是初筛，别指望它判断内容质量和政策合规
visible = re.sub(r"<script[\s\S]*?</script>", "", html)
ok = bool(score) and bool(count) and (score.group(1) in visible)

# 输出核对结论，进批量队列跑全站商品页
# 只分两档，别在这里做精细打分，精判交给富结果测试
# 批量跑时加 sleep 限速，把人家站爬挂了得不偿失
print(url, "PASS" if ok else "CHECK-MANUALLY")

这个脚本只是初筛，判断不了内容质量和政策合规，但能把几万个商品页里明显有问题的那批捞出来，人工只需要看 CHECK-MANUALLY 的部分。老蒋站当时全站四万多个详情页，脚本一轮跑下来标了六千多页，比逐页人肉看省了不知道多少事。

再补一句 GEO 的衔接：AI 搜索引擎（Generative Engine，如 AI Overviews 类产品）在生成回答时同样读取结构化数据和评价信号，把星级这层基础打扎实，内容被 AI 引用时的可信度参照是同一套。传统 SEO 做到位，往生成式引擎优化（Generative Engine Optimization, GEO）迁移时大部分工作是复用的。

还有个承接新项目时的习惯做法值得记一笔：接手任何电商站，我先跑一遍全站结构化数据的分布统计，哪些模板带了 Product、哪些带了 AggregateRating、哪些字段是硬编码假数据，一上午能摸清整个站的历史底子。老蒋站最早那版 JSON-LD 是 2023 年某次改版时外包写的，里面 ratingValue 干脆写死成 5.0，这种埋雷不排掉，后面做再多网站优化动作都是白费劲。排查先行，再谈增长，顺序不能反。

参考与延伸

• Google 富结果测试工具与文档：https://developers.google.com/search/docs/appearance/structured-data
• schema.org Product 与 AggregateRating 定义：https://schema.org/Product
• Google 结构化数据通用指南（含评价政策）：https://developers.google.com/search/docs/appearance/structured-data/sd-policies
• web.dev 关于结构化数据与搜索外观的实践文章：https://web.dev/learn/

SEO · 富摘要 · 结构化数据 · JSON-LD · AggregateRating · Rich Results Test · 网站优化