产品实体与服务实体优化

本节导读

这一节是「从策略到页面落地」。前面定义了实体、画了关系图、找了外部证据，接下来要把这些实体正确地写进页面和代码。

Google 明确说明，结构化数据是帮助其理解页面含义的标准化方式，并推荐使用 JSON-LD，同时强调数据应准确、完整、与用户可见内容一致（依据：Google）。本节围绕产品实体、服务实体、组织实体等高频对象，讲清页面层与代码层的实施方法。

核心讲解

页面层：先认清每类页面的主实体

先区分六类高频页面，并为每一类回答同一个问题——「这个页面最想让搜索引擎理解的主实体是谁」：

• 首页 / 品牌页
• 关于我们 / 团队页
• 产品页 / 服务页
• 品类页 / 聚合页
• 文章页 / 指南页
• FAQ / 对比页 / 案例页

产品页和服务页尤其要想清楚主实体是 Product 还是 Service，这决定了后续 Schema 的类型选择。

代码层：最实用的 Schema 实施

落地时优先覆盖这几类最常用的 Schema：

• Organization
• WebSite
• Person
• Product
• Article
• FAQPage
• BreadcrumbList

Google 的 Organization 文档说明，logo 可帮助 Google 理解你希望展示的官方 Logo，sameAs 可指向社媒或评论站等其他资料页，同时建议尽可能提供适用的推荐属性（依据：Google）。产品实体的一个最小示例：

{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://example.com/products/x/#product",
  "name": "示例产品 X",
  "brand": { "@id": "https://example.com/#organization" },
  "mainEntityOfPage": "https://example.com/products/x/"
}

必须讲透的四个关键动作

1）用 JSON-LD 做统一管理。 Google 推荐 JSON-LD 作为更易维护的实现格式（依据：Google）。

2）一页一个主实体意识。 哪怕页面会提到多个实体，也要清楚谁是主角。这正是 mainEntityOfPage 的应用场景之一（依据：Schema.org）。

3）跨页面复用同一个 @id。 不要每个页面都造一个新的「品牌对象」。品牌实体、组织实体、创始人实体都应有稳定 ID，让产品页、文章页都能引用同一个对象。

4）结构化数据不能和可见内容脱节。 Google 官方明确反对「仅为了放结构化数据而创建空白页」，也反对「标记页面上用户不可见的信息」（依据：Google）。标记的内容必须与用户实际看到的一致。

课堂练习

完成三个页面的结构化数据实施：给品牌首页写 Organization + WebSite；给产品页写 Product；给文章页写 Article + mainEntityOfPage。完成后用结构化数据验证工具跑一次验证，并走一遍部署检查流程，记录并修复报错。

学习产出

• 站点 Schema 覆盖清单
• JSON-LD 模板库
• 实施优先级排期表
• 验证错误修复表