结构化数据到底是什么，为什么值得做

你有没有注意过，同样是搜索结果，有些页面下面会多出一行评分星星、一个面包屑导航路径、或者一个发布时间和作者？那些多出来的东西，就是结构化数据（structured data）带来的「富媒体搜索结果」（rich results）。

结构化数据的本质，是用一套搜索引擎能读懂的标准格式，把你页面里的信息「标注」出来：这篇是文章、作者是谁、什么时候发的、标题是什么、图片在哪、评分多少。它不会直接提升你的排名，但它决定了搜索结果里你的那条「长什么样」。一个带星级和发布日期的结果，点击率往往比一条光秃秃的蓝色链接高出可观的一截，而点击率又反过来影响排名——这是个正循环。

目前搜索引擎（尤其是 Google、Bing、百度）最推荐的结构化数据格式是 JSON-LD。它相比早期的微数据（microdata）和 RDFa 有几个明显优势：不侵入 HTML 结构、单独放在一个 <script> 标签里、维护起来像改一段配置，而不是在正文标签里到处塞属性。这篇教程带你从零给一个博客站加 JSON-LD，并结合 Search Console 做验证。

第一步：理解 Schema.org 词汇表

结构化数据的「语言」由 Schema.org 定义，它是一套共享的词汇表。你不需要背全部，博客站常用的就那么几个类型：

• Article / BlogPosting：文章类，最常用。
• BreadcrumbList：面包屑导航，让搜索结果显示层级路径。
• Organization / Person：站点主体和作者信息。
• WebSite：站点整体信息，配合搜索框使用。
• FAQPage：问答页，能让结果里直接展示问答折叠。

这些类型还可以嵌套。比如一篇 BlogPosting 里，author 字段的值本身就是一个 Person 对象。理解这种嵌套关系，是写出正确 JSON-LD 的关键。

第二步：写第一段 JSON-LD

给它加在页面的 <head> 或 <body> 里都行，搜索引擎两种都能识别。下面是一篇博客文章的最小可用结构：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "文章标题，控制在 110 字符以内",
  "datePublished": "2026-10-06T10:00:00+08:00",
  "dateModified": "2026-10-06T12:00:00+08:00",
  "author": {
    "@type": "Person",
    "name": "站长名",
    "url": "https://www.example.com/about/"
  },
  "publisher": {
    "@type": "Organization",
    "name": "网站名称",
    "logo": {
      "@type": "ImageObject",
      "url": "https://www.example.com/logo.png"
    }
  },
  "mainEntityOfPage": "https://www.example.com/posts/example/",
  "image": "https://www.example.com/cover.jpg"
}
</script>

逐个字段说清楚，因为这些正是搜索引擎判定「合不合格」的依据。@context 固定是 https://schema.org，不能漏；@type 决定后续字段的语义；headline 是标题，官方建议控制在 110 个字符以内，超了会在验证工具里报 warning；datePublished 和 dateModified 都要用 ISO 8601 带时区的格式，写成 2026/10/06 这种是无效的。

publisher 里的 logo 是硬性要求——Google 对文章类结构化数据，要求必须提供发布方的 logo，否则富媒体结果不会展示。图片 URL 必须是可公开访问的绝对地址，本地相对路径 /logo.png 无效。

第三步：加面包屑结构化数据

面包屑能让搜索结果里显示「首页 > 分类 > 文章」这样的路径，既提升点击率，也帮搜索引擎理解站点结构。它独立于文章结构，是另一段 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": "技术教程", "item": "https://www.example.com/category/tech/" },
    { "@type": "ListItem", "position": 3, "name": "当前文章标题" }
  ]
}
</script>

两个细节容易出错。第一，position 必须从 1 开始连续递增，跳号会导致整段失效。第二，最后一项（当前页面）可以省略 item 字段，因为它就是当前页本身，写上反而可能引发歧义。每一层的 item 都要是可访问的绝对 URL，指向不存在的分类页会在验证时报错。

第四步：做一个站点级 WebSite 结构

除了文章，建议在首页加一段 WebSite 结构，声明站点名称和搜索行为。它能让搜索引擎在结果里用你的站名而不是域名，长期看对品牌识别有帮助：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "我的个人站",
  "url": "https://www.example.com/",
  "potentialAction": {
    "@type": "SearchAction",
    "target": "https://www.example.com/search?q={search_term_string}",
    "query-input": "required name=search_term_string"
  }
}
</script>

potentialAction 里的 {search_term_string} 是占位符，必须原样保留（花括号不能改），它表示用户搜索时关键词会被填进这个位置。如果你的站点没有站内搜索，这一段可以省略，但 name 和 url 建议保留。

第五步：用工具验证

写完绝不能凭感觉发布，一定要验证。有三层验证方式，从松到严：

1. Schema Markup Validator（validator.schema.org）：通用校验，检查语法和字段是否符合 Schema.org 定义，任何站点都能用。
2. Google Rich Results Test（search.google.com/test/rich-results）：针对性校验，直接告诉你这个页面能拿到哪些富媒体结果、有没有报错。
3. Search Console → 增强功能：上线后的持续监控，统计有多少页面被识别为有效、多少有错误，是长期最该关注的。

验证时最常见的三个报错，我列出来帮你快速定位：

这三点覆盖了绝大多数新手报错。尤其是日期格式和 logo 缺失，几乎每个第一次做结构化数据的人都会撞上。

第六步：在模板中自动化生成

手动给每篇文章贴 JSON-LD 不现实，一定要在模板里自动生成。以 Hugo 为例，在文章模板里这样写，字段从 front matter 自动取值：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": {{ .Title | jsonify }},
  "datePublished": {{ .Date.Format "2006-01-02T15:04:05-07:00" | jsonify }},
  "dateModified": {{ .Lastmod.Format "2006-01-02T15:04:05-07:00" | jsonify }},
  "author": { "@type": "Person", "name": {{ .Site.Params.author | jsonify }} },
  "mainEntityOfPage": {{ .Permalink | jsonify }},
  "image": {{ (index .Params.images 0) | absURL | jsonify }}
}
</script>

这里 jsonify 是关键。JSON-LD 里字符串必须用双引号包裹，如果标题里恰好含有双引号或反斜杠，直接拼接会产出非法 JSON，整段结构化数据就废了。jsonify 会自动做转义，这是模板自动生成结构化数据时最不能省的一步。用 Typecho 或 WordPress 的话，思路一样：把固定字段换成对应模板变量并做 JSON 转义即可。

一次真实的点击率对比

讲个我自己站上的实测。我有一批教程文章，之前都只有基础的标题和描述，没有结构化数据。某次我给其中一部分文章加了 BlogPosting + BreadcrumbList，另一部分保持原样，做个对照。

排查过程反而是重点。加完一周后我在 Search Console 看增强功能报告，发现有相当比例的页面报「缺少字段 logo」——原来填的是相对路径，被判定为无效，那段结构化数据压根没生效。这提醒我一个关键点：结构化数据不是「写了就行」，必须等到 Search Console 报告里显示「有效」才算数。我把 logo 换成绝对 URL 重新提交后，才真正生效。

生效后的数据对比：加了结构化数据的那批文章，搜索结果里的展现形式多了面包屑路径，点击率相比对照组有明显提升，而且因为层级结构清晰，搜索引擎对这批页面的抓取也更规律了。整体流量没有立刻暴涨，但每一条曝光都变得更「值钱」。方法论提炼：结构化数据对流量是「润物细无声」的作用，不要指望一夜暴涨，它的价值在于长期稳定地优化每一次曝光的转化，而且要经得起工具验证——在 Search Console 里看到「有效」之前，一切都还没落地。

常见问题

Q：加了结构化数据排名会涨吗？不直接涨。它影响的是搜索结果的展示形式（富媒体），通过提升点击率间接帮助排名。别指望它当排名神器。

Q：一个页面能放多段 JSON-LD 吗？可以，也可以合并成一个数组。文章、面包屑、FAQ 各放一段是最清晰的写法，搜索引擎都能解析，不必强行合并。

Q：中文内容需要注意什么？字段值直接写中文即可，JSON-LD 用 UTF-8 编码，无需转成拼音或英文。但建议页面声明 <meta charset="utf-8">，避免编码不一致导致乱码。

Q：结构化数据会被惩罚吗？名副其实地标注不会。但如果标注与页面实际内容不符（比如没评分却标了评分），会被判为垃圾结构化数据，导致富媒体结果被取消，严重时影响整站。如实标注是底线。

Q：多久能生效？提交后在 Search Console 里通常几天到几周内能看到识别结果。可用 Rich Results Test 立即验证语法是否通过，但展示到搜索结果需要等重新抓取和索引。

总结

结构化数据是那种「做一次、长期受益」的 SEO 基础工作。它不改内容、不动排名算法，只是用搜索引擎听得懂的语言，把你已有的信息标注清楚，让每一次搜索结果曝光都更有可能被点击。

上手路径很清晰：先用 BlogPosting 把文章标好，补上必需的 logo 和规范日期格式，再加 BreadcrumbList 优化展示，最后把这套逻辑写进模板自动生成、用 jsonify 保证转义正确。发布前用 Rich Results Test 过一遍，上线后在 Search Console 持续盯「增强功能」报告。只要你养成「看到『有效』才算完成」的习惯，这份投入就会以更高的点击率、更清晰的站点结构，一点点回馈到你的流量上。对于认真经营个人站的站长来说，这是性价比很高的一个动作。