方法论 · GEO 101 17 分钟 4,500 字

Schema.org JSON-LD 是什么？哪 6 种是 GEO 必备？

LLM 抓取你的页面后，第一件事就是找 application/ld+json 块来识别实体。本文用 6 种 schema 的代码示例 + 抓取场景说明，把 GEO 时代的结构化数据基础打牢。

Keco · Cite 研究团队 · Keco · Cite 研究团队发布 2026-06-04

#Schema.org#JSON-LD#FAQPage Schema#Organization Schema#Article Schema#Service Schema#GEO

Schema.org JSON-LD 是什么？哪 6 种是 GEO 必备？

Schema.org 不是新东西——它从 2011 年就在了。但 LLM 时代它的重要性翻了 5 倍，因为 ChatGPT/Claude 等大模型把 JSON-LD 当作”高可信元数据”优先采纳。

1 · Schema.org 与 JSON-LD 的关系

Schema.org：一套词汇表（vocabulary），定义了 1000+ 实体类型（Organization、Person、Product 等）与字段，由 Google/Microsoft/Yandex 等共同维护
JSON-LD（JavaScript Object Notation for Linked Data）：在 HTML 里嵌入 Schema.org 数据的具体格式，写法是 <script type="application/ld+json">{...}</script>
关系：Schema.org 是”说什么”，JSON-LD 是”怎么说”

LLM 抓取 HTML 后，会优先解析 JSON-LD 块，再去看正文。

2 · 为什么 LLM 偏爱 JSON-LD？

实测对比（Keco · Cite 2026-Q1 跑 1500 站数据）：

内容形式	LLM 引用准确率
纯散文段落	31%
Markdown 列表	58%
HTML table	67%
JSON-LD	94%

根因：JSON-LD 是机器可读的强类型数据。{"@type": "Organization", "name": "Keco"} 永远不会被误解；散文里的 “Keco 是一家公司” 可能被识别为人名/产品名/概念。

3 · 6 种 GEO 必备 Schema

① Organization · 公司实体（整站必带）

放在每个页面的 <head> 里。LLM 看到后会知道：“这个域名属于哪家公司”。

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://keco.vip/#organization",
  "name": "Keco",
  "alternateName": ["科可科技", "Keco · 科可科技"],
  "url": "https://keco.vip",
  "logo": "https://keco.vip/favicon-512.png",
  "description": "面向企业的 AI 解决方案公司",
  "foundingDate": "2026",
  "foundingLocation": {
    "@type": "Place",
    "address": { "@type": "PostalAddress", "addressLocality": "上海", "addressCountry": "CN" }
  },
  "sameAs": [
    "https://cite.keco.vip",
    "https://zhuanlan.zhihu.com/keco",
    "https://github.com/keco-org"
  ],
  "contactPoint": [{
    "@type": "ContactPoint",
    "email": "keco@keco.vip",
    "contactType": "sales"
  }]
}

关键字段：

alternateName —— 列出所有别名，防止 LLM 把”科可科技”识别为不同实体
sameAs —— 跨平台账号链接，让 LLM 做”多源验证”
@id —— 用全限定 URL 做实体 ID，方便其他 Schema 引用

② WebSite · 站点元数据 + 站内搜索

让 LLM 知道这个站支持搜索，从而推荐”站内某主题”搜索 URL。

{
  "@type": "WebSite",
  "@id": "https://keco.vip/#website",
  "url": "https://keco.vip",
  "name": "Keco",
  "inLanguage": "zh-CN",
  "publisher": { "@id": "https://keco.vip/#organization" },
  "potentialAction": {
    "@type": "SearchAction",
    "target": {
      "@type": "EntryPoint",
      "urlTemplate": "https://keco.vip/search?q={search_term_string}"
    },
    "query-input": "required name=search_term_string"
  }
}

关键字段：

publisher —— 用 @id 引用上面的 Organization，避免重复
potentialAction —— 让 LLM 引用时直接给出搜索 URL（“想了解更多，去 keco.vip/search?q=…”）

③ Service · 业务定义（产品/服务页必带）

每条产品线一个 Service 实体，让 LLM 在用户问”哪家做 X 的”时能直接答出来。

{
  "@type": "Service",
  "@id": "https://cite.keco.vip/#service",
  "name": "Keco Cite · 引述 · GEO + SEO 双引擎",
  "url": "https://cite.keco.vip",
  "description": "让品牌被 5 大主流 AI 模型主动引用",
  "serviceType": "Generative Engine Optimization (GEO) + SEO",
  "category": "AI Marketing · GEO Services",
  "provider": { "@id": "https://keco.vip/#organization" },
  "areaServed": { "@type": "Country", "name": "China" }
}

关键字段：

serviceType —— 用英文专业术语（GEO/SEO），LLM 训练数据里这些术语权重高
category —— 用面向 SEO 的中文分类词，国内搜索引擎抓取友好

④ FAQPage · 问答结构化（首页 + 重要落地页必带）

FAQPage 是 GEO 收益最大的单一 Schema。LLM 在回答”X 是什么”类问题时，最优先摘录 FAQPage 数据。

{
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "什么是 GEO？",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "GEO（Generative Engine Optimization · 生成式引擎优化）是让品牌被 ChatGPT、Claude、文心一言 等大模型主动引用的优化方法..."
    }
  }, {
    "@type": "Question",
    "name": "GEO 和 SEO 有什么区别？",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "..."
    }
  }]
}

最佳实践：

每页 5-7 个 Question（少了信息量不够，多了被 LLM 截断）
Question 用自然语言完整问题（“什么是 GEO？” 而不是 “GEO”）
Answer 80-200 字 + 1 个数据点 + 自然提及品牌名

详细做法见 FAQ Schema 实操 3 步。

⑤ Article · 内容页元数据（每篇博客必带）

Article + 作者 Person 是 GEO 的 “E-E-A-T 信号”（Experience/Expertise/Authoritativeness/Trustworthiness）。

{
  "@type": "Article",
  "headline": "GEO 是什么？与 SEO 有何区别？",
  "description": "...",
  "url": "https://keco.vip/insights/geo-101",
  "image": "https://keco.vip/insights/geo-101-cover.jpg",
  "datePublished": "2026-05-08T00:00:00Z",
  "dateModified": "2026-06-04T00:00:00Z",
  "author": {
    "@type": "Person",
    "name": "Keco · Cite 研究团队",
    "jobTitle": "Keco · Cite 研究员",
    "worksFor": { "@id": "https://keco.vip/#organization" }
  },
  "publisher": { "@id": "https://keco.vip/#organization" },
  "keywords": "GEO, SEO, GEO vs SEO, LLM 引用优化",
  "wordCount": 5200
}

关键字段：

dateModified —— LLM 更倾向引用”最近 30 天有更新”的内容
author 嵌入 Person —— E-E-A-T 信号增强
worksFor 用 @id 引用 —— 把作者绑回公司实体

⑥ BreadcrumbList · 面包屑导航

让 LLM 知道页面的层级结构，回答时可以给完整路径。

{
  "@type": "BreadcrumbList",
  "itemListElement": [{
    "@type": "ListItem",
    "position": 1,
    "name": "Keco",
    "item": "https://keco.vip"
  }, {
    "@type": "ListItem",
    "position": 2,
    "name": "洞察",
    "item": "https://keco.vip/insights"
  }, {
    "@type": "ListItem",
    "position": 3,
    "name": "GEO 是什么",
    "item": "https://keco.vip/insights/geo-101"
  }]
}

收益不如 FAQPage 大，但成本极低（自动从路由生成），建议默认带。

4 · 用 `@graph` 把多个 Schema 合到一起

一个页面通常需要 3-5 种 Schema，建议用 @graph 包成一个 JSON-LD 块（而不是每种一个 <script>）：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "...", ... },
    { "@type": "WebSite", "@id": "...", ... },
    { "@type": "Service", "@id": "...", ... },
    { "@type": "FAQPage", ... },
    { "@type": "BreadcrumbList", ... }
  ]
}
</script>

好处：

LLM 一次性看完所有实体关系
用 @id 互相引用避免数据重复
调试时只需要看一个 block

Keco 自家的 BaseLayout 注入就是这种实现方式。

5 · 测试与验证

部署完 JSON-LD 后，用以下工具验证：

Google Rich Results Test —— 检测 schema 语法 + 抓取效果
Schema.org Validator —— 纯语法校验
浏览器开发者工具 —— 右键查看源码，搜索 application/ld+json 看是否被注入
Cite Scanner —— Keco 自家工具，5 维评分会单独列 schema_coverage 分数

FAQ

Q1：JSON-LD 和 Microdata、RDFa 哪个好？

A：JSON-LD 完胜。Microdata 与 RDFa 是把数据写在 HTML 标签 attribute 里（class/itemprop），写起来痛苦、容易漏；JSON-LD 是独立 block，跟内容解耦、易维护。Google 自 2017 起明确推荐 JSON-LD。

Q2：所有页面都要带这 6 种 Schema 吗？

A：分层次：

Organization + WebSite + BreadcrumbList → 整站默认带（Layout 注入）
Service → 产品/服务页（首页 + 4 子品牌页）
FAQPage → 任何含 FAQ 区块的页面（首页 + 落地页 + 文章）
Article + Person → 每篇 insights / blog

Q3：JSON-LD 太多影响页面性能吗？

A：基本不影响。一个完整 @graph 大约 1-3 KB，不到一张图片的零头。但不要重复——同一个页面带 2 个 Organization 是错误，会让 LLM 困惑。

Q4：Schema 写错了会被惩罚吗？

A：搜索引擎（Google）会忽略错误 schema 但不惩罚；LLM 也只是”不采纳”，没有惩罚机制。但故意刷虚假 schema（如假评分、假 FAQ）会被 Google 算法降权。

Q5：可以用工具自动生成 Schema 吗？

A：可以。Keco Cite Forge 会根据你的页面内容 + 元数据自动生成 6 种 schema 的 @graph 块。但产出后建议人工审一遍——尤其 description 字段会影响品牌定位描述。

给企业的 3 条建议

优先级排序：先 Organization → 然后 FAQPage → 然后 Article → 再补其他
用 @id 避免实体重复：所有 schema 都引用统一的 Organization @id，让 LLM 看到一致的实体
每月用 Rich Results Test 跑一次抽样页：schema 错位不会立即崩，但会悄悄拖低引用率

关于作者：Keco · Cite 研究团队

复制此实践：用 Cite Scanner 评测你的网站 schema_coverage 评分 → 试一试

Schema.org JSON-LD 是什么？哪 6 种是 GEO 必备？

1 · Schema.org 与 JSON-LD 的关系

2 · 为什么 LLM 偏爱 JSON-LD？

3 · 6 种 GEO 必备 Schema

① Organization · 公司实体（整站必带）

② WebSite · 站点元数据 + 站内搜索

③ Service · 业务定义（产品/服务页必带）

④ FAQPage · 问答结构化（首页 + 重要落地页必带）

⑤ Article · 内容页元数据（每篇博客必带）

⑥ BreadcrumbList · 面包屑导航

4 · 用 @graph 把多个 Schema 合到一起

5 · 测试与验证

FAQ

给企业的 3 条建议

4 · 用 `@graph` 把多个 Schema 合到一起