Schema.org JSON-LD 结构化数据 SEO 实战：Article/面包屑/FAQ 标注、WordPress 落地与验证排错

Author： zz1984
发布时间：October 10, 2026
6 views
No comments
7287 字数
Categories： SEO优化

为什么结构化数据值得每个站长认真做一次

你有没有在 Google 搜索结果里见过带星级评分、价格区间、面包屑路径、有时还带"常见问答"展开的富媒体结果？那些不是 Google 自动猜出来的，而是站长通过结构化数据（structured data）明确告诉搜索引擎"这个页面是什么、里面有什么"得到的回报。对个人站长来说，这是投入产出比很高的一件事：一次配置，长期享受更高点击率和更精准的流量。

目前搜索引擎最推荐的结构化数据格式是 JSON-LD——一段嵌在页面里的 JSON 脚本，不侵入 HTML 结构，维护方便。这篇教程从零讲清楚主要类型、写法、在 WordPress 与自研站点里的落地方式，以及上线前怎么验证和排错。

JSON-LD 相比微数据、RDFa 好在哪

结构化数据有三种主流写法：Microdata（在 HTML 标签里加 itemprop）、RDFa、以及 JSON-LD。三者搜索引擎都认，但 JSON-LD 有明显优势：

内容和展示解耦：JSON-LD 放在 <script type="application/ld+json"> 里，不要求和可见文字一一对应，改版式不会破坏结构化数据。
一处集中维护：所有字段写在一个 JSON 块里，比散落在几十个标签上的 itemprop 好读好改。
Google 官方推荐：Google 文档明确表示优先支持 JSON-LD，工具链和校验也最完善。

所以除非你有遗留系统必须用 Microdata，否则直接上 JSON-LD。

基础骨架：@context 与 @type

最简单的 JSON-LD 长这样，放在 <head> 或 <body> 里都行：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "一个草根站长的博客",
  "url": "https://www.zz1984.com/"
}
</script>

两个必填字段：

@context：固定为 https://schema.org，声明用哪套词汇表。
@type：说明这个对象是什么类型。常用类型见下表。

最常用的几种类型与字段

1. Article / BlogPosting（文章页）

博客文章页最该加的就是这个，配合 Google 的"头条内容轮播"展示：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "rsync --link-dest 快照备份实战",
  "datePublished": "2026-10-10T09:00:00+08:00",
  "dateModified": "2026-10-10T09:00:00+08:00",
  "author": {
    "@type": "Person",
    "name": "草根站长"
  },
  "publisher": {
    "@type": "Organization",
    "name": "一个草根站长的博客",
    "logo": {
      "@type": "ImageObject",
      "url": "https://www.zz1984.com/logo.png"
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://www.zz1984.com/1569.html"
  },
  "image": "https://www.zz1984.com/cover/1569.png"
}
</script>

几点注意：headline 建议控制在 110 字符内；datePublished 用 ISO 8601 带时区偏移的格式，别写"2026/10/10"这种；image 至少 1200px 宽、能被 Google 抓取，否则富结果可能不展示。

2. BreadcrumbList（面包屑）

让搜索结果里显示层级路径，提升可读性：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {"@type": "ListItem", "position": 1, "name": "首页", "item": "https://www.zz1984.com/"},
    {"@type": "ListItem", "position": 2, "name": "服务器运维", "item": "https://www.zz1984.com/category/ops/"},
    {"@type": "ListItem", "position": 3, "name": "rsync 快照备份实战"}
  ]
}
</script>

position 必须从 1 开始连续递增，最后一项可以省略 item（因为就是当前页）。

3. FAQPage（常见问答）

把页面里的问答块标记成 FAQ，有机会在结果里直接展开答案，抢占更多展示面积：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "JSON-LD 应该放在 head 还是 body？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "两者都可以，Google 都能解析。习惯上放在 head 便于集中管理。"
      }
    },
    {
      "@type": "Question",
      "name": "结构化数据和可见内容必须一致吗？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "必须一致。标记了页面上不存在的问答属于误导，会被判定为垃圾结构化数据。"
      }
    }
  ]
}
</script>

重要红线：结构化数据里的内容必须和页面可见内容对应。凭空捏造评分、价格、问答来骗富结果，一旦被识别，会导致整站结构化数据被降权甚至人工惩罚。

4. Organization 与 SiteNavigationElement

首页可以加 Organization 声明站点主体信息（名称、logo、社交账号），帮助建立"品牌实体"，对 E-E-A-T 有正面作用。同域名下建议用 @id 做实体引用，避免重复声明：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.zz1984.com/#org",
  "name": "一个草根站长的博客",
  "url": "https://www.zz1984.com/",
  "sameAs": ["https://github.com/yourname"]
}
</script>

在 WordPress 站点里落地

如果你用 WordPress，有两条路径：

装插件（如 Yoast、Rank Math）：它们会自动输出 Article 和 BreadcrumbList，省事但字段固化，想加自定义类型要写过滤器。
主题函数手动输出：在 header.php 或通过 wp_head 钩子注入。给文章页动态拼 JSON 的示例：

add_action('wp_head', function () {
    if (!is_singular('post')) return;
    $data = [
        '@context' => 'https://schema.org',
        '@type'    => 'BlogPosting',
        'headline' => get_the_title(),
        'datePublished' => get_the_date('c'),
        'dateModified'  => get_the_modified_date('c'),
        'author'   => ['@type' => 'Person', 'name' => get_the_author()],
        'mainEntityOfPage' => get_permalink(),
    ];
    echo '<script type="application/ld+json">'
       . wp_json_encode($data, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE)
       . '</script>';
});

关键点：用 wp_json_encode 而不是 json_encode，并带上 JSON_UNESCAPED_UNICODE，否则中文会被转义成 \uXXXX，虽然合法但可读性差；date('c') 输出 ISO 8601 格式，正好满足要求。别忘了用 esc_js 或确保标题里没有 </script> 之类的破坏字符——用 wp_json_encode 本身会安全转义。

自研站点（PHP/静态）怎么加

纯手工站点就更直接了，在生成 HTML 模板时把字段拼进去即可。要保证每个页面的 @id 唯一且稳定（用永久链接），同一实体在多个页面出现时用相同的 @id 引用，形成互相印证的知识图谱，而不是各写各的。

上线验证：三个必做步骤

Rich Results Test：Google 官方的富结果测试工具，粘贴 URL 或代码，直接告诉你检测到哪些类型、有没有错误或警告。这是上线前必跑的第一道关。
Schema Markup Validator（validator.schema.org）：比 Google 工具更严格，能校验词汇表层面的合法性，排查拼写错误、类型不匹配。
Search Console 的"增强功能"报告：上线几天后回来看，Google 会列出实际抓取到的结构化数据有效项、无效项和警告趋势。这是唯一反映"真实收录效果"的地方。

验证时常见报错和对策：

"Missing field 'image'"：Article 类型强烈建议提供 image，补上可抓取的图片 URL。
"Invalid date format"：日期必须是 ISO 8601（2026-10-10T09:00:00+08:00），不能是 2026-10-10 09:00。
"Value in 'position' not a number"：面包屑的 position 被写成了字符串，改成数字。
抓取工具看不到 JSON-LD：多半是页面用了前端框架异步注入、而 Google 抓取时脚本没执行完。优先在服务端渲染时输出，别依赖纯客户端 JS。

别踩的几个坑

不要堆类型：一页一个主类型即可，硬塞 Article + Product + FAQ 混在一起反而让解析器困惑，选最贴合页面内容的那个。
内容和标记必须一致：这是最容易招致惩罚的点。页面上写"评分 5 星"才标评分，没有就别标。
别用已经被废弃的类型：查询前先看 Google 文档里当前支持的类型列表，一些老类型（如某些 HowTo 场景）已停止富结果展示，标了也没用。
JSON 必须合法：少个逗号、多个尾逗号都会让整块数据失效。发布前用 jq 校验一遍：echo "$JSON" | jq .。
同域名保持统一：别一部分页面写 www、一部分不写，URL 要和你站点 canonical 保持一致。

结构化数据不是一次性配置就完事的活儿——每次改版、新增内容类型，都要回头看 Search Console 的增强报告。但只要基础打对了，它带来的富媒体展示和更高点击率，是纯靠"写更多文章"很难在短期内达到的。花一个下午把 Article、BreadcrumbList 和几个 FAQ 配好，可能就是这一年性价比最高的一次 SEO 投入。

Last modification：October 10th, 2026 at 07:27 pm

暂无相关文章

Schema.org JSON-LD 结构化数据 SEO 实战：Article/面包屑/FAQ 标注、WordPress 落地与验证排错

zz1984 • 2026 年 10 月 10 日

为什么结构化数据值得每个站长认真做一次

JSON-LD 相比微数据、RDFa 好在哪

结构化数据有三种主流写法：Microdata（在 HTML 标签里加 itemprop）、RDFa、以及 JSON-LD。三者搜索引擎都认，但 JSON-LD 有明显优势：

内容和展示解耦：JSON-LD 放在 <script type="application/ld+json"> 里，不要求和可见文字一一对应，改版式不会破坏结构化数据。
一处集中维护：所有字段写在一个 JSON 块里，比散落在几十个标签上的 itemprop 好读好改。
Google 官方推荐：Google 文档明确表示优先支持 JSON-LD，工具链和校验也最完善。

所以除非你有遗留系统必须用 Microdata，否则直接上 JSON-LD。

基础骨架：@context 与 @type

最简单的 JSON-LD 长这样，放在 <head> 或 <body> 里都行：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "一个草根站长的博客",
  "url": "https://www.zz1984.com/"
}
</script>

两个必填字段：

@context：固定为 https://schema.org，声明用哪套词汇表。
@type：说明这个对象是什么类型。常用类型见下表。

最常用的几种类型与字段

1. Article / BlogPosting（文章页）

博客文章页最该加的就是这个，配合 Google 的"头条内容轮播"展示：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "rsync --link-dest 快照备份实战",
  "datePublished": "2026-10-10T09:00:00+08:00",
  "dateModified": "2026-10-10T09:00:00+08:00",
  "author": {
    "@type": "Person",
    "name": "草根站长"
  },
  "publisher": {
    "@type": "Organization",
    "name": "一个草根站长的博客",
    "logo": {
      "@type": "ImageObject",
      "url": "https://www.zz1984.com/logo.png"
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://www.zz1984.com/1569.html"
  },
  "image": "https://www.zz1984.com/cover/1569.png"
}
</script>

2. BreadcrumbList（面包屑）

让搜索结果里显示层级路径，提升可读性：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {"@type": "ListItem", "position": 1, "name": "首页", "item": "https://www.zz1984.com/"},
    {"@type": "ListItem", "position": 2, "name": "服务器运维", "item": "https://www.zz1984.com/category/ops/"},
    {"@type": "ListItem", "position": 3, "name": "rsync 快照备份实战"}
  ]
}
</script>

position 必须从 1 开始连续递增，最后一项可以省略 item（因为就是当前页）。

3. FAQPage（常见问答）

把页面里的问答块标记成 FAQ，有机会在结果里直接展开答案，抢占更多展示面积：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "JSON-LD 应该放在 head 还是 body？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "两者都可以，Google 都能解析。习惯上放在 head 便于集中管理。"
      }
    },
    {
      "@type": "Question",
      "name": "结构化数据和可见内容必须一致吗？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "必须一致。标记了页面上不存在的问答属于误导，会被判定为垃圾结构化数据。"
      }
    }
  ]
}
</script>

4. Organization 与 SiteNavigationElement

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.zz1984.com/#org",
  "name": "一个草根站长的博客",
  "url": "https://www.zz1984.com/",
  "sameAs": ["https://github.com/yourname"]
}
</script>

在 WordPress 站点里落地

如果你用 WordPress，有两条路径：

装插件（如 Yoast、Rank Math）：它们会自动输出 Article 和 BreadcrumbList，省事但字段固化，想加自定义类型要写过滤器。
主题函数手动输出：在 header.php 或通过 wp_head 钩子注入。给文章页动态拼 JSON 的示例：

add_action('wp_head', function () {
    if (!is_singular('post')) return;
    $data = [
        '@context' => 'https://schema.org',
        '@type'    => 'BlogPosting',
        'headline' => get_the_title(),
        'datePublished' => get_the_date('c'),
        'dateModified'  => get_the_modified_date('c'),
        'author'   => ['@type' => 'Person', 'name' => get_the_author()],
        'mainEntityOfPage' => get_permalink(),
    ];
    echo '<script type="application/ld+json">'
       . wp_json_encode($data, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE)
       . '</script>';
});

自研站点（PHP/静态）怎么加

上线验证：三个必做步骤

Rich Results Test：Google 官方的富结果测试工具，粘贴 URL 或代码，直接告诉你检测到哪些类型、有没有错误或警告。这是上线前必跑的第一道关。
Schema Markup Validator（validator.schema.org）：比 Google 工具更严格，能校验词汇表层面的合法性，排查拼写错误、类型不匹配。
Search Console 的"增强功能"报告：上线几天后回来看，Google 会列出实际抓取到的结构化数据有效项、无效项和警告趋势。这是唯一反映"真实收录效果"的地方。

验证时常见报错和对策：

"Missing field 'image'"：Article 类型强烈建议提供 image，补上可抓取的图片 URL。
"Invalid date format"：日期必须是 ISO 8601（2026-10-10T09:00:00+08:00），不能是 2026-10-10 09:00。
"Value in 'position' not a number"：面包屑的 position 被写成了字符串，改成数字。
抓取工具看不到 JSON-LD：多半是页面用了前端框架异步注入、而 Google 抓取时脚本没执行完。优先在服务端渲染时输出，别依赖纯客户端 JS。

别踩的几个坑

不要堆类型：一页一个主类型即可，硬塞 Article + Product + FAQ 混在一起反而让解析器困惑，选最贴合页面内容的那个。
内容和标记必须一致：这是最容易招致惩罚的点。页面上写"评分 5 星"才标评分，没有就别标。
别用已经被废弃的类型：查询前先看 Google 文档里当前支持的类型列表，一些老类型（如某些 HowTo 场景）已停止富结果展示，标了也没用。
JSON 必须合法：少个逗号、多个尾逗号都会让整块数据失效。发布前用 jq 校验一遍：echo "$JSON" | jq .。
同域名保持统一：别一部分页面写 www、一部分不写，URL 要和你站点 canonical 保持一致。

Schema.org JSON-LD 结构化数据 SEO 实战：Article/面包屑/FAQ 标注、WordPress 落地与验证排错

为什么结构化数据值得每个站长认真做一次

JSON-LD 相比微数据、RDFa 好在哪

基础骨架：@context 与 @type

最常用的几种类型与字段

1. Article / BlogPosting（文章页）

2. BreadcrumbList（面包屑）

3. FAQPage（常见问答）

4. Organization 与 SiteNavigationElement

在 WordPress 站点里落地

自研站点（PHP/静态）怎么加

上线验证：三个必做步骤

别踩的几个坑

相关文章

Leave a Comment Cancel reply

自建CF节点之反代Cloudflare加速网站(Gost/iptables转发)

技术学习路径与资源导航

LayerStack：香港原生IP服务器无限流量四网直连外加双向cn2

js底部飘浮广告代码

lnmp 去除防跨域问题

JSON-LD 结构化数据实战：BlogPosting、面包屑与 WebSite 三段配置，让搜索结果长出富媒体

MySQL 性能调优与慢查询优化实战指南

MySQL 慢查询排查与索引优化实战：从日志定位到 EXPLAIN 调优

OpenVPN 自建实战：Easy-RSA 搭 PKI、签发与吊销客户端证书、内核转发 NAT 与 .ovpn 生成全流程

Shell 脚本入门实战：写给个人站长的自动化备份与运维第一课

Schema.org JSON-LD 结构化数据 SEO 实战：Article/面包屑/FAQ 标注、WordPress 落地与验证排错

为什么结构化数据值得每个站长认真做一次

JSON-LD 相比微数据、RDFa 好在哪

基础骨架：@context 与 @type

最常用的几种类型与字段

1. Article / BlogPosting（文章页）

2. BreadcrumbList（面包屑）

3. FAQPage（常见问答）

4. Organization 与 SiteNavigationElement

在 WordPress 站点里落地

自研站点（PHP/静态）怎么加

上线验证：三个必做步骤

别踩的几个坑