Schema.org 结构化数据实战：Article/BreadcrumbList/FAQPage 的 JSON-LD 写法、@graph 组合与验证排错

  1.  Home
  2. Text  
    3. Share to：

结构化数据不是玄学，是给搜索引擎的「填空题」

很多人做 SEO 只盯着标题和正文关键词，却忽略了一件事：搜索引擎在理解一个页面时，除了读你的文字，还会看你是不是用 Schema.org 的结构化数据把关键信息「结构化」地标注出来了。你可以把它理解成一份填好的表格——文章标题是什么、作者是谁、发布时间、面包屑路径、有没有常见问题，都写得清清楚楚。

填得好，页面在搜索结果里就能拿到富媒体结果（rich result）：面包屑显示成带层级的路径、文章带上日期和作者、FAQ 直接展开问答。这些展示形态的点击率普遍高于普通蓝色链接。对个人站长来说，结构化数据是少数「一次配置、长期吃流量」的技术活。

三种最基本也最值得做的类型

Schema.org 的类型有几百种，但个人博客真正需要的是这三种：

  • Article：告诉搜索引擎这是一篇文章，附带标题、作者、发布时间、封面图。覆盖大多数技术博客页。
  • BreadcrumbList：面包屑导航。能在搜索结果里把 URL 显示成分层路径，比如「首页 › SEO教程 › 本文」，替代难看的绿字 URL。
  • FAQPage：把页面底部的常见问答结构化成 Q&A，有机会在结果里直接展开显示。

另外还有 WebSite（站点级，含站内搜索框）和 Organization（品牌信息），可以作为补充。不建议一上来全做，先把上面三个做对做准。

用 JSON-LD 而不是微数据

标注结构化数据有三种写法：微数据（HTML 属性）、RDFa、JSON-LD。强烈推荐 JSON-LD，理由是：它是一段独立的 <script type="application/ld+json">，不改动页面可见 HTML 结构，插入和删除都很干净，也是 Google 官方现在最推荐的形式。

把这段放到页面的 <head> 里即可：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Nginx 性能调优的十个实用项",
  "datePublished": "2026-10-14T08:00:00+08:00",
  "dateModified": "2026-10-14T08:00:00+08:00",
  "author": {
    "@type": "Person",
    "name": "老张"
  },
  "publisher": {
    "@type": "Organization",
    "name": "我的技术博客"
  },
  "mainEntityOfPage": "https://www.example.com/nginx-perf.html"
}
</script>

注意 JSON 里字符串末尾不要多写逗号，这是最常见的低级错误，会导致整段解析失败。

BreadcrumbList：让搜索结果里的 URL 变好看

面包屑的数据要和你页面上真实的面包屑导航一一对应，层级从首页开始。假设页面路径是「首页 › SEO教程 › 本文」，JSON-LD 这样写：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {"@type": "ListItem", "position": 1, "name": "首页", "item": "https://www.example.com/"},
    {"@type": "ListItem", "position": 2, "name": "SEO 优化教程", "item": "https://www.example.com/seo-tutorial"},
    {"@type": "ListItem", "position": 3, "name": "结构化数据实战", "item": "https://www.example.com/schema-org.html"}
  ]
}
</script>

三个要点：position 必须从 1 开始连续递增；最后一层的 item 可以省略（表示当前页），但写上更稳妥；name 用中文原名，和面包屑显示文字保持一致。

FAQPage：把问答变成可展开结果

在文章末尾放 3 到 5 条真实常见问题，同时用 FAQPage 标注。注意：内容必须是页面上真实可见的问答，不能只写在 JSON 里而对用户隐藏，否则会被判为欺骗性标记。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "结构化数据不生效怎么办？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "先用 Google 富媒体测试工具验证 JSON 语法，再确认数据与页面可见内容一致，最后等待重新抓取。"
      }
    },
    {
      "@type": "Question",
      "name": "一个页面能放几种结构化数据吗？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "可以。用 @graph 把多个类型组合在一段 JSON-LD 里，或分成多段 script 标签分别标注。"
      }
    }
  ]
}
</script>

用 @graph 把它们组合起来

一个页面同时要有 Article、BreadcrumbList、FAQPage，可以把它们放进同一个 @graph 数组，减少 script 标签数量，也便于统一维护。Typecho/WordPress 模板里可以做成一个函数统一输出。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Article", "headline": "…", "datePublished": "…" },
    { "@type": "BreadcrumbList", "itemListElement": [ … ] },
    { "@type": "FAQPage", "mainEntity": [ … ] }
  ]
}
</script>

用 @graph 时不要在每个子项里再写 @context，外层的就够了。重复写有时会导致解析歧义。

怎么验证「我做对了」

生产环境上线前，务必先验证，别等抓取异常了才发现。三种手段：

  1. Google Rich Results Test：输入 URL 或粘贴代码，直接告诉你识别出了哪些类型、有没有错误、能不能出富媒体。
  2. Schema Markup Validator（validator.schema.org）：更偏纯语法与规范校验，能查出类型字段用错。
  3. Search Console 的「增强功能」报告：上线一段时间后，这里会汇总全站结构化数据的有效/无效页面数，是长期监控的主力。

本地排查时，也可以直接在浏览器控制台里检查 JSON 是否能解析：

// 在控制台执行，把页面里所有 ld+json 抽出来逐个 JSON.parse
[...document.querySelectorAll('script[type="application/ld+json"]')]
  .forEach((el, i) => {
    try { JSON.parse(el.textContent); console.log(i, 'OK'); }
    catch (e) { console.error(i, 'FAIL', e.message); }
  });

哪一段报 FAIL，就是哪一段 JSON 有语法错误，十有八九是多了个尾逗号或少了引号。

五个高频错误

  1. JSON 语法错误。 尾逗号、单引号、缺转义。JSON 只认双引号，字符串里的双引号要写成 \"。
  2. 数据与页面可见内容不一致。 比如 JSON 里标了发布日期，页面上却没显示；或 FAQ 标了但用户看不到。这会被判欺骗。
  3. 日期格式不规范。 用 ISO 8601，带时区，如 2026-10-14T08:00:00+08:00，不要写「2026年10月14日」。
  4. URL 用了相对路径或 http。 item、mainEntityOfPage 等字段要用完整 https 绝对地址，且与实际 URL 完全一致（含末尾斜杠与否）。
  5. 标记了不存在的实体。 比如 Article 的 author 指向一个没有页面的名字，或 publisher logo 尺寸不合规。尽量填写真实存在、可访问的信息。

和已有 SEO 工作的配合

结构化数据不是独立存在的，它和 canonical、sitemap、robots 是一套的。优先级上：先确保页面能被正常抓取（robots 放行、canonical 唯一），再确保内容本身质量过硬，最后才是结构化数据锦上添花。如果页面本身因为 noindex 或 canonical 指向别处而进不了索引，做得再漂亮的结构化数据也不会被展示。

把 Article、BreadcrumbList、FAQPage 三种做扎实，配合 Search Console 的增强功能报告长期观察，是个人技术博客在「技术型 SEO」上最容易拿到正反馈的一步。它不依赖外链，不依赖运气，只依赖你把格式写对——这正是技术站长最擅长的部分。

Last modification：October 14th, 2026 at 01:24 pm
© 允许规范转载

相关文章

Leave a Comment