首页/博客/SEO教程/结构化数据 Schema 教程：先选型，再上 FAQ、Product、Article、Breadcrumb

结构化数据 Schema 教程：先选型，再上 FAQ、Product、Article、Breadcrumb

搜
搜投工具 SEOSEMTool 编辑部
内容作者 / SEO 编辑
适合读者
SEO 团队 / 独立站运营 / 内容负责人
SEO教程2026-04-2512 分钟50 阅读

结构化数据 Schema 教程：先选型，再上 FAQ、Product、Article、Breadcrumb

结构化数据的目标不是“多贴几个标签”，而是让搜索引擎更准确理解页面是什么、卖什么、讲什么，以及它在站内处于哪一层。中文站点最常用、也最容易选错的，就是 FAQPage、Product、Article、BreadcrumbList。本文先讲选型逻辑，再分别讲四种 Schema 的适用场景、反例和落地方法。

结构化数据 Schema 教程：先选型，再上 FAQ、Product、Article、Breadcrumb

一、先选型：先看页面意图，再看网站类型

1. 先问 4 个问题

  • 这个页面是来买东西、看文章、找答案，还是看路径？
  • 页面上是否真实展示了对应内容？
  • 这个内容是否有稳定模板，适合批量配置？
  • 结构化数据能不能帮助搜索引擎更准确理解页面？

在写任何 Schema 之前，建议先用本站的 搜索意图挖掘机 判断页面意图，把页面归到信息型、交易型、问答型或导航型，再决定主 Schema。若站点模板很多，还可以用 ROI 决策工作台 先评估优先级，优先做流量高、转化强、内容稳定的模板。

2. 电商站、内容站、企业官网怎么选

  • 电商站：商品详情页优先 Product + BreadcrumbList；售后、发货、退款页优先 FAQPage；类目页通常只做 BreadcrumbList，不要把整页列表硬写成 Product。
  • 内容站：博客、教程、新闻、专题页优先 Article + BreadcrumbList；文章里如果有真实问答区块，再补 FAQPage。
  • 企业官网：品牌介绍页、关于我们页不要强行写 Product；新闻、案例、知识库更适合 Article；帮助中心和售后页适合 FAQPage；所有有层级的页面都建议加 BreadcrumbList。

3. 什么时候不要乱用

  • 页面没有对应内容，却为了富结果硬加。
  • 页面内容会频繁变化，但 Schema 没有同步更新。
  • 一个页面同时塞多个主实体，语义冲突。
  • FAQ 问答不是页面可见内容，而是后台临时拼出来的。
  • 商品页没有真实价格、库存或评价，却强行写 Product。

一、先选型：先看页面意图，再看网站类型 配图

二、FAQPage：只给真实问答内容

1. 适用场景

  • 帮助中心页面，正文就是一问一答。
  • 售后、发货、退款、保修等政策页。
  • 产品详情页下方有真实的“常见问题”模块。
  • 知识库文章中包含固定的问答区块。

2. 反例

  • 把搜索词强行改写成问答句式。
  • 为了富结果，硬塞 20 条问题，但页面正文并没有这些内容。
  • 问答内容与页面主题无关，或者只是拼凑关键词。
  • 页面本身是商品详情页，但没有实际 FAQ 区块，却想挂 FAQPage。

FAQPage 的核心不是“让页面看起来像问答”，而是让机器更准确识别“问题—答案”的关系。即使 FAQ 富结果并不是所有站点都稳定开放，FAQPage 本身仍然有语义价值。需要批量用 AI 生成问答时，建议先用 AI 搜索避雷针 检查是否重复、空泛、前后矛盾。

3. JSON-LD 示例

下面这个例子适合“退款政策”页面，页面正文里也应该真实展示这两个问题和答案。

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "订单支付后可以申请退款吗？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "未发货订单可在 24 小时内申请退款；已发货订单需先签收后按退货流程处理。"
      }
    },
    {
      "@type": "Question",
      "name": "退款多久能到账？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "平台审核通过后，原路退款通常需要 3 到 7 个工作日到账，具体以支付渠道为准。"
      }
    }
  ]
}

这段代码解决的问题是：让搜索引擎明确知道页面上哪些内容是问题，哪些内容是答案，避免把政策页误判成普通说明页。写法要点有三个：name 必须和页面可见问题一致，acceptedAnswer.text 必须和页面可见答案一致，问题数量不要为了凑数而硬加。

三、Product：只给有明确商品或套餐属性的页面用

1. 适用场景

  • 电商商品详情页。
  • SaaS 套餐页或订阅页。
  • 线上课程售卖页。
  • 具备明确价格、库存、品牌、评分的销售型页面。

2. 反例

  • 品牌故事页、公司介绍页。
  • 活动专题页没有具体商品。
  • 页面显示价格，但前端并没有真实展示。
  • 库存、价格与前端页面不一致。
  • 把一个类目页里所有商品都堆进主 Product，导致主实体混乱。

Product 的目标不是描述“这是一篇介绍文章”，而是告诉搜索引擎：这个页面对应一个可购买、可定价、可比较的商品或服务。电商站最常见，企业官网则要谨慎：如果只是服务介绍，不卖标准化套餐，就不要硬写 Product；如果已经明确写了套餐名、价格和购买入口，才可以考虑 Product。

3. JSON-LD 示例

下面是一个无线耳机详情页的写法，适合标准商品页。

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "降噪无线耳机 X1",
  "image": [
    "https://example.com/images/x1-1.jpg"
  ],
  "description": "适合通勤与办公的主动降噪无线耳机，支持蓝牙 5.3 与快速充电。",
  "sku": "X1-BLK-128",
  "brand": {
    "@type": "Brand",
    "name": "Acme"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/product/x1",
    "priceCurrency": "CNY",
    "price": "699.00",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  }
}

这段代码解决的问题是：把商品名称、品牌、价格、库存和购买页绑定到同一个实体，帮助搜索引擎理解这是一个真实可购买的商品页。注意两点：offers.url 应该指向真实购买页，不要写首页；availability 必须和前端库存状态一致。页面如果没有真实评分，就不要补 aggregateRating。

4. 什么时候可以组合 FAQPage

如果商品详情页下面真的有常见问题模块，而且页面可见、内容稳定，可以再叠加 FAQPage。顺序建议是先保证 Product 正确，再补 FAQPage，不要先为了问答把商品语义冲淡。

三、Product：只给有明确商品或套餐属性的页面用 配图

四、Article：博客、新闻、教程、专题页的首选

1. 适用场景

  • 博客文章。
  • SEO 教程、行业分析、操作指南。
  • 新闻稿、品牌动态、专题稿。
  • 以阅读和理解为主的页面。

2. 反例

  • 把商品详情页写成 Article。
  • 把品牌首页或公司介绍页硬套成新闻稿。
  • 文章页标题和 headline 不一致。
  • dateModified 长期不更新，内容改了却没同步。

如果页面核心是“内容传播”和“信息解释”，优先考虑 Article。对内容站、品牌媒体站、知识中心来说，Article 往往是最基础、也最稳妥的结构化数据。教程类内容即使很技术，只要本质是内容阅读页，依然优先用 Article。

3. JSON-LD 示例

下面是一个“结构化数据入门指南”类文章的写法。

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "结构化数据 Schema 入门指南",
  "description": "讲清 FAQ、Product、Article、Breadcrumb 的适用场景与落地方法。",
  "author": {
    "@type": "Person",
    "name": "张三"
  },
  "datePublished": "2025-01-10",
  "dateModified": "2025-02-18",
  "image": [
    "https://example.com/images/schema-guide-cover.jpg"
  ],
  "publisher": {
    "@type": "Organization",
    "name": "示例站点",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/images/logo.png"
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/schema-guide"
  }
}

这段代码解决的问题是：把文章标题、作者、发布时间、更新时间、头图和发布方统一给到搜索引擎，让它更准确地判断页面是文章而不是商品页或落地页。headline 最好与页面主标题一致，dateModified 要随内容更新同步修改。

五、BreadcrumbList：有层级的页面基本都该有

1. 适用场景

  • 电商详情页。
  • 博客文章页。
  • 文档中心、帮助中心。
  • 目录层级明确的内容站。

2. 反例

  • 前端没有面包屑，却在 Schema 里强写。
  • 路径跳级、重复，和真实导航不一致。
  • position 不连续，或者层级名称与页面文案完全不同。

Breadcrumb 的价值常被低估。它不仅能帮助搜索引擎理解页面在站内的位置，也能让搜索结果更清晰地展示路径。在信息架构较深的网站上，Breadcrumb 基本属于低风险、高收益项。

3. JSON-LD 示例

下面是一个从首页到文章详情页的路径示例。

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "首页",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "SEO教程",
      "item": "https://example.com/seo-tutorial/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "结构化数据 Schema 教程",
      "item": "https://example.com/seo-tutorial/schema-guide"
    }
  ]
}

这段代码解决的问题是：让搜索引擎理解页面在站内的层级关系，减少“这个页面属于哪个目录”的歧义。写法要点是 position 必须连续，name 尽量和前端面包屑一致，item 指向真实可访问的层级页面。

六、不同页面怎么组合使用

1. 电商详情页

推荐组合：Product + BreadcrumbList。

如果商品页下面真的有常见问题模块，还可以再加 FAQPage，但前提是问答内容真实存在、可见且不与商品信息冲突。不要为了把四种 Schema 都塞满，而让主实体失焦。

2. 内容站文章页

推荐组合：Article + BreadcrumbList。

如果文章页底部有一个独立 FAQ 区块，比如“这篇教程常见问题”，且页面上真的展示了问答内容，可以再增加 FAQPage。反过来，如果文章只是普通长文，就不要硬加 FAQPage。

3. 企业官网

企业官网最容易乱配。一个实用判断是：

  • 品牌故事页、关于我们页：通常只保留 BreadcrumbList，必要时用 Article，但不要写 Product。
  • 服务/解决方案页：如果只是介绍方案，优先按 Article 思路处理；如果已经有明确套餐、价格和购买入口，才考虑 Product。
  • 帮助中心、售后说明页：FAQPage + BreadcrumbList 最合适。

4. 不要乱配的页面

  • 关于我们页，不要硬写 Product。
  • 企业品牌故事页，不要硬写 FAQPage。
  • 分类页如果只是列表，不要把每个商品都塞进主 Schema 里。
  • 新闻页不要为了“看起来高级”叠加一堆互相冲突的标记。

六、不同页面怎么组合使用 配图

七、上线前检查清单

1. 内容一致性

  • Schema 中的标题、价格、作者、时间是否和页面一致。
  • FAQ 的问答是否真的出现在页面里。
  • Breadcrumb 的层级是否与实际导航一致。
  • 商品库存、价格是否会随页面变化而更新。

2. 技术验证

上线前至少做三类检查：

  • Google Rich Results Test：看富结果资格。
  • Schema Markup Validator：看结构化数据语法是否完整。
  • Search Console 增强功能报告：上线后监控索引与报错。

3. 批量生成时的风险控制

如果你打算用 AI 批量生成 FAQ、摘要或文章说明，建议先用 AI 搜索避雷针 做内容风险检查，重点看三件事：

  • 是否与页面事实一致。
  • 是否存在重复、空泛、堆砌表达。
  • 是否能被人工快速复核。

4. 投入产出评估

如果站点模板很多，不建议一口气全站铺开。先用 ROI 决策工作台 评估优先级，通常顺序是：高流量商品详情页、核心文章页、帮助中心页，再到长尾模板页。

八、最实用的落地顺序

1. 先上 Breadcrumb

Breadcrumb 风险低、改动小，通常是最容易先落地的结构化数据。

2. 再上主 Schema

  • 商品页先做 Product。
  • 文章页先做 Article。
  • 问答页先做 FAQPage。

3. 最后补组合 Schema

当主 Schema 稳定后，再考虑添加 FAQPage 或更细的辅助标记。不要一开始就追求“全家桶”，先保证语义准确、可维护、可扩展。

4. 以页面模板为单位管理

对于中大型站点，最稳妥的方式不是按单页手工写，而是按模板配置：商品模板、文章模板、帮助中心模板、专题模板分别输出不同 Schema。这样更容易维护，也更不容易出错。

九、结论：四类 Schema 的决策口诀

  • 有真实问答，才用 FAQPage。
  • 有明确商品或套餐，才用 Product。
  • 有内容阅读属性，优先 Article。
  • 有清晰层级路径，几乎都该加 BreadcrumbList。

如果你把“页面意图”放在第一位，再去选 Schema，结构化数据就不会变成装饰代码，而会变成真正服务 SEO 的页面语义资产。