企业官网建设流程全解析

Front-End-Checklist 实战：为产品与服务页面添加 Review 与 AggregateRating 结构化数据，获取星评富结果

【免费下载链接】Front-End-Checklist🗂 The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist

导读

本文围绕 Front-End-Checklist 仓库中seo/technical领域的 review 规则展开，系统讲解如何通过 Schema.org 的Review与AggregateRating结构化数据，让 Google 在搜索结果中直接展示星级评分，从而提升点击率。读完本文，你将掌握两种 JSON-LD 的标准写法、富结果必需的属性清单、Google 政策红线以及从源码层面验证结构化数据生成质量的完整流程。

规则背景与适用场景

在 skills/review/SKILL.md 中，该技能被明确定位为 SEO 类目下的一条规则：适用于产品页、本地商家页、菜谱、应用、图书，以及任何聚合用户评价的页面；在审核电商或点评类站点的富结果资格时使用。

对应的规则内容仓库位于 packages/content/rules/en/seo/review.mdx，其 frontmatter 记录了规则的元数据：

• 优先级（priority）：medium
• 难度（difficulty）：intermediate
• 预估耗时（estimatedTime）：10 分钟
• 分类：seo / technical

规则的 tldr 概括了核心要点：在单个评论页使用Reviewschema，在产品/服务页使用AggregateRatingschema；AggregateRating必须包含ratingValue、ratingCount或reviewCount以及合法的bestRating/worstRating；评分必须反映真实用户评价，Google 会惩罚自卖自夸或伪造的评分；上线前用 Google 的 Rich Results Test 校验标记。

为什么值得做：星级评分的价值

Review与AggregateRating结构化数据可以让 Google 直接在搜索结果中渲染星标评分，形成与普通蓝色链接截然不同的富摘要（rich snippet）。

规则文档给出的数据是：搜索结果中的星级评分最多可将点击率（CTR）提升约 35%；相应地，缺失或错误的 schema 意味着拥有合法标记的竞争对手会拿走这部分可见性优势。从源码角度看，本仓库自身也在用同样的机制为规则页生成结构化数据——详见下文"源码级实现"一节。

核心代码示例：在 Product 上嵌套 AggregateRating

最常见的落地方式是将AggregateRating嵌套在页面主实体（如Product）内部，声明该商品的综合评分与评分数量。以下是 skills/review/references/rule.md 提供的标准 JSON-LD 写法：

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Product", "name": "Wireless Noise-Cancelling Headphones", "image": "https://example.com/headphones.jpg", "description": "Premium headphones with 30-hour battery life.", "aggregateRating": { "@type": "AggregateRating", "ratingValue": "4.7", "reviewCount": "312", "bestRating": "5", "worstRating": "1" } } </script>

要点说明：

• aggregateRating是嵌套对象，其@type必须是AggregateRating；
• ratingValue是平均分的数字字符串（如"4.7"），应与页面上对用户可见的平均分一致；
• reviewCount表示参与评分的总人数，与页面展示的计数一致。

单个评价的 Review Schema

当页面展示的是某一条具体评价（如"用户评价详情页"）时，使用Review类型，并通过itemReviewed指向被评价对象、author声明评价者、reviewRating声明该条评价的打分：

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Review", "itemReviewed": { "@type": "Product", "name": "Wireless Headphones" }, "author": { "@type": "Person", "name": "Jane Smith" }, "datePublished": "2025-02-14", "reviewBody": "Excellent sound quality and very comfortable for long sessions.", "reviewRating": { "@type": "Rating", "ratingValue": "5", "bestRating": "5" } } </script>

注意这里的reviewRating是单条评价的打分（Rating类型），与代表整体平均分的AggregateRating是两种不同的结构，使用场景不要混淆。

富结果必需属性清单

AggregateRating（嵌套在受支持的实体类型内）

Review

支持星评富结果的实体类型

Google 目前会对以下类型的评价展示星标评分：Product（产品）、Recipe（菜谱）、Movie（电影）、Book（图书）、Software（软件）、LocalBusiness（本地商家）、Course（课程）、Event（活动）。

规则文档特别强调（见Exceptions小节）：只添加页面能够如实支撑的 schema 类型，与页面内容无关的结构化数据比没有更糟。此外，即使 schema 在技术上合法，如果页面内容无法直观印证（例如页面上根本没有展示评分与评价），该标记仍可能具有误导性。

政策红线（Google 明令禁止的违规）

规则文档列举了以下会被视为违规的做法：

• 自写评价：自己给自己的业务写评价（"Review your own business"）；
• 不能反映真实用户体验的评价；
• AggregateRating中reviewCount: 0的空评分；
• 在页面并未向用户展示评价内容的情况下放置评价标记。

这些红线与 packages/content/rules/en/seo/review.mdx 的 frontmatter 中声明的指导方针一致：评分必须来自真实用户，伪造评分违反 Google 的结构化数据政策，且ratingValue、ratingCount必须来自真实评价数据。

验证与上线流程

使用 Rich Results Test 验证

规则文档给出的标准验证步骤：

1. Schema 能被无错误地检测到；
2. 正确的富结果类型具备资格（eligible）；
3. 所有必需属性均已提供。

（Google 的 Rich Results Test 是官方富结果验证工具，将页面 URL 或代码粘贴进去即可看到解析结果与错误提示。）

自动化检查（Automated Checks）

• 检查渲染后的 HTML 与 HTTP 响应头，确认预期的元数据或可抓取性信号存在；
• 对受影响的 URL 使用 Google Search Console 或等价工具测试；
• 部署后对代表性页面集合重新抓取（re-crawl）。

人工检查（Manual Checks）

• 确认改动没有引入与 canonical-url、robots 或结构化数据信号之间的冲突；
• 若indexability（可索引性）、canonical-url（规范链接）或主内容质量本身存在问题，应优先修复这些基础问题，再优化 schema 细节——这是规则文档Exceptions小节给出的优先级建议。

源码级实现：仓库如何生成与渲染 JSON-LD

Front-End-Checklist 的@repo/seo包（packages/seo/src/index.ts）为所有规则页统一提供结构化数据能力，是实现上述模式的可参考范本。

统一入口generateStructuredData

packages/seo/src/structured-data.ts 定义了生成任何 Schema.org 类型的基础函数：

export function generateStructuredData( type: string, data: Record<string, unknown> ): StructuredData { return { '@context': 'https://schema.org', '@type': type, ...data } }

它固定输出@context: "https://schema.org"，再根据传入的type与属性展开，这正是文档中所有 JSON-LD 示例的公共骨架。基于它派生了generateWebsiteStructuredData（WebSite + SearchAction）、generateRuleStructuredData（Article）、generateBreadcrumbStructuredData（BreadcrumbList）与generateFAQStructuredData（FAQPage）等具体实现。

渲染为<script type="application/ld+json">

renderStructuredData 将结构化数据对象序列化为<script>标签描述符：

export function renderStructuredData(structuredData: StructuredData) { return { type: 'script', props: { key: 'structured-data', type: 'application/ld+json', dangerouslySetInnerHTML: { __html: JSON.stringify(structuredData) } } } }

输出type: 'application/ld+json'，与规则文档示例中的<script type="application/ld+json">完全对应，说明仓库在实际渲染层面严格执行了 JSON-LD 标准。

测试如何验证输出质量

packages/seo/src/tests/seo.test.ts 覆盖了结构化数据的生成断言：

• generateStructuredData('Thing', { name: 'Example' })['@type']必须等于'Thing'；
• generateWebsiteStructuredData()、generateRuleStructuredData()、generateBreadcrumbStructuredData()、generateFAQStructuredData()的@type分别正确；

而在 渲染测试 中，renderStructuredData(generateWebsiteStructuredData())断言返回描述符的type为script、props.type为application/ld+json——这组测试可以视为"检查页面最终输出是否包含正确 JSON-LD 块"的自动化落地示例，与规则文档Automated Checks中"检查渲染后 HTML 中结构化数据信号"的要求一一对应。

与规则配套的相邻检查

该规则在内容仓库中有若干关联规则（见 packages/content/rules/en/seo/review.mdx 的relatedRules）：product（产品 schema）、json-ld-valid（JSON-LD 合法性）、structured-data（结构化数据总体规范）与schema-noindex-conflict（schema 与 noindex 冲突），它们同属seo/technical领域，评审时常被一起审查。如果你在站点上同时实施这几条规则，可以对照仓库中对应的技能文档（如 skills/json-ld-valid）进行联合验证。

完整落地检查清单

把上述内容整合成一份可直接对照执行的清单：

1. 确定页面主实体类型是否属于支持星评富结果的八类实体（Product / Recipe / Movie / Book / Software / LocalBusiness / Course / Event）；
2. 页面是否向用户真实展示了评分与评价内容（政策合规的前提）；
3. 选择正确结构：聚合平均分用aggregateRating（AggregateRating），单条评价用Review；
4. 补齐必需属性：ratingValue+ratingCount/reviewCount，建议补充bestRating（默认 5）与worstRating（默认 1）；单条Review必须含author、reviewRating、itemReviewed；
5. 用 Rich Results Test 验证：无解析错误、富结果类型具备资格、必需属性齐全；
6. 上线后用 Search Console 确认富结果展示，并对代表性页面重新抓取；
7. 复查未引入 canonical-url、robots、结构化数据之间的信号冲突。

结论

为产品、服务与商家页面添加Review/AggregateRating结构化数据，是用极低的实现成本换取搜索结果可见性提升的高性价比 SEO 手段。关键是守住两条底线：属性必须齐全（参照文中的必需属性表），数据必须真实（评分来自真实用户评价且页面对用户可见）。Front-End-Checklist 仓库自身通过@repo/seo包统一生成 JSON-LD 并用测试锁定输出格式，这套"生成-渲染-测试-验证"的工程化路径，值得在你的项目中复制。

【免费下载链接】Front-End-Checklist🗂 The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist