百度结构化数据（JSON-LD）支持类型盘点：字段要点与标注规范

引言：找了一圈资料，没人说得清支持哪些类型

想给站点加结构化数据，搜中文资料得到的多是 Google 的文档，照着标注完却发现百度没有反应；搜”百度支持哪些结构化数据类型”，得到的答案往往是几年前的截图，或者干脆把 schema.org 全站类型都算上去。这种信息混乱导致两种极端：一种人完全放弃结构化数据，觉得”百度不支持”；另一种人把所有类型都往页面上堆，结果谁都没生效。真实情况是：百度对结构化数据的支持是”分类型、分阶段”的，且支持范围、字段要求与展现形式会随平台迭代调整，官方文档以外的任何静态列表都可能过期。所以正确的做法是——以百度搜索资源平台后台实际提供的可选类型为准，同时理解那些长期稳定、普适性强的类型的标注规范。本文盘点的正是后者：文章、问答、面包屑、站点/组织、商品这几类最常见也最稳妥的类型，讲清各自适用场景、必填字段与高频错误，并给出可套用的 JSON-LD 示例。需要强调的是，本文的示例遵循 schema.org 规范，具体采用情况请以平台校验结果为准。

原理分析：类型不是越多越好，匹配才是关键

结构化数据的作用是告诉搜索引擎”这个页面是什么”，所以类型选择的第一原则是”页面是什么就标什么”。

为什么”匹配”这么重要？因为搜索引擎会把结构化数据当作理解页面的辅助证据，当声明与页面性质冲突时（比如给文章页声明 Product），它会选择忽略这块数据，极端情况下还会影响对页面主体的判断。另一个常被误解的点是”必填字段”：平台对必填字段有明确要求，缺一个就可能导致整块数据不被采用，而不是”部分生效”。所以宁可少标几个类型，也要把每个类型的字段填全填准。还有一点：所有声明的内容必须在页面上有对应的可见信息。写了 aggregateRating 但页面上没有评分展示，是最典型的失真，也是很多”提交成功却不被采用”的直接原因。

保姆级实操

步骤 1：先给站点做类型规划

按页面模板规划类型，而不是按文章逐篇决定：首页输出 WebSite + Organization；文章详情页输出 BlogPosting + BreadcrumbList；带常见问题板块的页面额外输出 FAQPage；商品详情页输出 Product；分类/标签页只输出 BreadcrumbList。规划结果写成一张表，作为后续检查的依据。

步骤 2：按类型套用规范示例

下面是一份组合示例，覆盖站点、文章、面包屑与问答四类。注意其中 datePublished/dateModified 使用 ISO 8601 格式，position 从 1 开始连续递增：

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://mimangfei.com/#organization",
      "name": "迷茫飞",
      "url": "https://mimangfei.com/",
      "logo": {
        "@type": "ImageObject",
        "url": "https://mimangfei.com/logo.png"
      }
    },
    {
      "@type": "WebSite",
      "@id": "https://mimangfei.com/#website",
      "url": "https://mimangfei.com/",
      "name": "迷茫飞",
      "publisher": { "@id": "https://mimangfei.com/#organization" },
      "potentialAction": {
        "@type": "SearchAction",
        "target": "https://mimangfei.com/?s={search_term_string}",
        "query-input": "required name=search_term_string"
      }
    },
    {
      "@type": "BreadcrumbList",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "首页", "item": "https://mimangfei.com/" },
        { "@type": "ListItem", "position": 2, "name": "百度SEO", "item": "https://mimangfei.com/baidu-seo/" },
        { "@type": "ListItem", "position": 3, "name": "结构化数据类型盘点" }
      ]
    },
    {
      "@type": "BlogPosting",
      "headline": "百度结构化数据（JSON-LD）支持类型盘点",
      "description": "盘点百度常见结构化数据类型的适用场景、必填字段与高频错误。",
      "image": ["https://mimangfei.com/cover/jsonld-types.png"],
      "datePublished": "2026-10-11T09:00:00+08:00",
      "dateModified": "2026-10-11T09:00:00+08:00",
      "author": { "@type": "Person", "name": "迷茫飞" },
      "publisher": { "@id": "https://mimangfei.com/#organization" },
      "mainEntityOfPage": { "@type": "WebPage", "@id": "https://mimangfei.com/jsonld-types/" }
    },
    {
      "@type": "FAQPage",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "百度支持哪些结构化数据类型？",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "支持范围会随平台迭代调整，常见且稳妥的类型包括文章、问答、面包屑、站点与组织等，具体以百度搜索资源平台后台显示的可选类型为准。"
          }
        },
        {
          "@type": "Question",
          "name": "结构化数据提交后多久生效？",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "需要先被正常抓取与解析，之后是否采用取决于字段完整性与页面质量，通常按周观察，不能期待即时展现。"
          }
        }
      ]
    }
  ]
}

步骤 3：核对每个类型的必填项

逐项对照：BlogPosting 的 headline 不要超过合理长度、image 必须是真实可访问的绝对地址、author 与 publisher 不能为空；BreadcrumbList 的末级可以没有 item，但 position 必须连续；FAQPage 的每一条 answer 必须在页面上以可见文字出现。

步骤 4：确认声明内容与页面一致

这一条最容易被忽略。检查：结构化数据里的标题是否就是页面标题、时间是否与页面显示一致、作者是否是页面上展示的作者、FAQ 的问答对是否真的在正文里、商品评分是否有真实来源。任何不一致都要改，改不了就删掉这个字段。

步骤 5：上线后检查解析情况

页面上线并被抓取后，在搜索资源平台的结构化数据相关模块查看解析到的类型与数量，以及是否存在报错。有报错就按提示修字段，不要置之不理。

步骤 6：保持随页面更新

主题改版、SEO 插件更换、文章大改之后，重新检查输出。结构化数据一旦与页面脱节，就变成了噪音信号。具体的提交与观察流程见百度搜索开放平台结构化数据提交。

常见踩坑

1. 照抄示例不改域名和 ID：@id、url 还写着示例域名，等于把实体指向了别人的站。
2. 日期格式不是 ISO 8601：写成”2026年10月11日”或时间戳，解析会失败。
3. FAQ 的答案是隐藏内容：页面上折叠但不可见的答案，可能被判定为不实声明。
4. 面包屑末级多写了 item：末级指向自身会造成循环，通常应省略 item。
5. 一个页面标多个不相关类型：文章页同时标 Product 与 Recipe，解析结果不可预期。
6. 图片用了相对路径：必须是 https 绝对地址且可公开访问。
7. 案例：某站点用插件批量生成结构化数据，插件默认给每篇文章都加上了 FAQPage，而绝大多数文章根本没有问答板块，acceptedAnswer 的内容是从正文首段截取的、页面上并不以问答形式呈现。结果平台长期显示”部分解析失败”，且这批页面的摘要抽取变得混乱。站长后来改成只在含”常见问题”小标题的文章上输出 FAQPage，其余文章只保留 BlogPosting 与 BreadcrumbList，一个月后解析报错清零，搜索结果里的摘要抽取也恢复了正常。

总结

结构化数据类型的选择标准只有一条：这个页面在真实世界里是什么，就标什么。行动清单：按模板规划类型 → 套用规范示例并替换真实域名与 ID → 核对每个类型的必填字段 → 确认声明内容与页面可见信息一致 → 上线后在平台查看解析与报错 → 主题与插件变更后复查。支持范围会变，但”真实、完整、匹配”这三条原则不会变。提交与观察流程见百度搜索开放平台结构化数据提交；站点级实体声明可配合百度官网标识与品牌词保护；页面更新时间的准确输出则与百度时效性要求与文章更新策略相关。