JSON-LD 是你告诉机器「品牌名、域名和产品是同一件事,而不是三次巧合」的方式。 没有它,模型只能去推断你 <title> 里的字符串和你的域名是同一个实体。 结构化数据消除了这层猜测。
JSON-LD 为 AI 引擎解决了什么问题? 实体消歧。如果你的产品叫 Northwind ,而恰好还有一家叫 Northwind 的电影工作室,AI 系统就没有可靠的办法把一次提及归到你头上。带有稳定 @id、规范 url 和 sameAs 列表的 Organization 标记,提供了它需要的连接点。
How a sameAs list resolves one name to one entity A model meets the string Northwind and cannot tell whether it means a film studio or a software product. One JSON-LD graph answers that by giving every node a stable id. The Organization node names the brand and lists its external profiles under sameAs, and the WebSite node points at the Organization by id instead of repeating its data. The profiles are the join that turns the name into a resolvable entity; a profile that was abandoned points at nothing and is worse than leaving it out. A model meets the string: Northwind a film studio, or a software product? one @graph - every node carries an @id Organization @id: #organization name, url, sameAs publisher WebSite @id: #website sameAs x.com/yourhandle github.com/you/repo x.com/your-old-handle worse than no link at all The joins are the point: name, domain and profiles become one entity. That is what lets a model tell your Northwind from the film studio, and cite the right one. Every node needs a stable @id, and every sameAs needs a profile somebody still updates. The @id is how the nodes find each other; the sameAs list is how a model finds you. 哪些 schema 类型对 GEO 最重要? Organization —— 把你的品牌锚定为一个实体。单个价值最高的节点。WebSite —— 把域名绑定到该实体上。SoftwareApplication 或 Product —— 描述你实际卖的东西。FAQPage —— 把问题和答案配对。只在同一组问答确实显示在页面上时才使用。Article —— 在编辑类页面上标明作者和日期。如何把多个节点连成一个实体? 使用单个 @graph,并给每个节点一个 @id。 其他节点随后引用这些标识符,而不是重复数据。正是这一点把彼此分离的片段变成一段连贯的实体描述。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://your-domain.com/#organization",
"name": "Your Brand Name",
"url": "https://your-domain.com",
"logo": "https://your-domain.com/logo.png",
"sameAs": [
"https://x.com/yourhandle",
"https://github.com/you/repo"
]
},
{
"@type": "WebSite",
"@id": "https://your-domain.com/#website",
"url": "https://your-domain.com",
"name": "Your Brand Name",
"publisher": { "@id": "https://your-domain.com/#organization" }
}
]
}
</script> 最常被跳过的一点:name 必须在你的 <title>、你的 <h1>、你的 llms.txt 和这段标记里完全一致。 同一个页面上出现三个不同的名字,会让整件事彻底失效。
如何验证这些标记? 把 URL 提交给 Schema.org 验证器 。零错误是及格线。 确认你想要的节点类型确实被检测到了——而不只是「没有报错」。 检查渲染后的 HTML 源码,而不是编辑器。客户端渲染可能让脚本从初始响应里消失。 注意,Google 已把 FAQ 富媒体结果 收窄到少数站点,所以 FAQPage 的资格很低并不意味着这段标记没用——生成式引擎仍然会解析它。另见 为直接 AI 引用优化标题 。
关于实体标记的问题 哪些 schema 类型最重要? Organization 和 WebSite。它们让模型把你的品牌名、域名和产品绑定到同一个实体上,而不是去猜三个彼此独立的字符串是不是同一个意思。
sameAs 到底起什么作用? 它列出同一实体在其他平台上的档案,正是它把字符串变成一个已解析的实体。指向空档案或废弃档案的链接,比没有链接更糟。
如何验证这些标记? 把它粘贴到结构化数据验证器里,检查两件事:每个节点都有一个稳定的 @id;该类型要求的属性确实存在,而不只是打算写。
证据与来源 GEO can boost visibility by up to 40% overall in generative engine responses, and in the paper's Table 1 the best of the tested methods improve on the no-optimization baseline by 41% and 28%. — Generative Engine Optimization, KDD 2024 本站使用的权重遵循这项测量,因此可引用性与证据各占 11%,而 AI 上下文文件维度占 5%。完整权重,以及单 URL 扫描看不到的部分,都在 方法论页面 。
Primary sources