结构化数据解决的是“明确表达”

自由文本中，作者、发布时间、所属网站和页面关系可能散落在不同位置。结构化数据使用机器可读的词汇把这些事实显式表达，帮助支持它的系统理解页面含义，也可能让页面具备参与特定搜索展示形式的资格。

但它不是“引用开关”：正确的 JSON-LD 不保证搜索排名、富结果展示或大模型引用，更不能替代正文质量、可访问性、来源证据与外部信誉。

最常用的几种类型

  • Article / BlogPosting：文章标题、作者、发布与更新时间；
  • Person / Organization：你是谁、你的站点；
  • BreadcrumbList：页面在站点中的位置；
  • FAQPage：表达页面中真实可见的问答内容；是否展示或被采用取决于具体平台规则。

一个完整的文章页示例

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "headline": "结构化数据为什么是 GEO 的底座",
      "datePublished": "2026-07-06",
      "author": { "@type": "Person", "name": "Beason" }
    },
    {
      "@type": "BreadcrumbList",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "首页" },
        { "@type": "ListItem", "position": 2, "name": "博客" }
      ]
    }
  ]
}

工程化建议

不要每页手写。建一个 seo.ts，按页面类型返回对应 JSON-LD，再在统一的布局里注入：

// 首页 → Person + WebSite
// 文章页 → Article + BreadcrumbList
// 关于页 → Person + ProfilePage

实施时还要保证标记内容与页面可见事实一致，使用稳定的 @id 连接作者、网站和文章，并在事实变化时同步更新。它的价值是减少歧义，不是制造权威。

结构化数据是可理解性的基础设施之一，不是 GEO 效果保证。