🕸️

实体与语义 SEO

从关键词转向实体——帮助 Google 知识图谱理解你是谁、你覆盖了什么。

📖 13 分钟阅读 🕑 更新于 2026-06-22

在搜索历史的大部分时间里，Google 都是一台字符串匹配机器。你输入 cheapest flights to tokyo，引擎就去查找包含这些精确字符串的文档。相应地，SEO 就是一场把正确的字符串放到正确位置的游戏：标题标签、H1、锚文本，以及——在那段不堪回首的岁月里——塞满关键词的页脚。

那个世界已经过去了。自 2012 年知识图谱（Knowledge Graph）问世、2013 年 Hummingbird 更新重组排名管线以来，Google 一直在从「字符串」迁移到「事物」。它在官方公告里的措辞非常直白：「things, not strings」（事物，而非字符串）。现代 Google 问的不再是「哪些页面包含这些词」，而是「这个查询是关于哪些现实世界的实体，又有哪些页面是这些实体的权威来源？」

这一转变是 2026 年高级 SEO 最重要的一个心智模型。如果你还在用关键词思考，那你优化的是一个早已不存在的引擎。本指南将向你展示如何改用实体来思考——以及如何标记。

实体 vs 关键词

关键词是一串文本。实体则是一个事物——人、组织、地点、产品、概念或事件——它独立于任何特定措辞而存在。

以实体 Tim Berners-Lee 为例。关键词 tim berners-lee、inventor of the world wide web、creator of HTTP 和 TBL 全都指向同一个实体。Google 把它们解析到知识图谱里的同一个节点，赋予它一个机器可读的 ID（一个知识图谱 MID，如 /m/07d5b，或一个 Wikidata QID，如 Q80），并把它与其他实体相连：World Wide Web、CERN、MIT、W3C。

下面这张表道出了区别：

方面关键词（字符串）实体（事物）
本质一串字符一个带有稳定 ID 的现实世界概念
同一性nyc ≠ new york citynyc = new york city = Q60
歧义「Jaguar」只是一个字符串动物 vs 汽车 vs 操作系统——三个实体
关系本身没有在图中互相连接（isA、partOf、worksFor）
Google 如何使用词法匹配消歧 + 推理 + 检索

🧑‍💻 开发者视角：把关键词想成原始的 string 输入，把实体想成已解析的外键。搜索过去是 WHERE body LIKE '%term%'，现在前面多了一层实体解析层——查询字符串被解析成实体 ID，排名有一部分发生在这些 ID 构成的图上。你的工作，就是让你的页面能干净地 join 到正确的节点。

这在实践中为什么重要？

  • 消歧。 当 Google 理解你关于「Python」的页面讲的是编程语言（Q28865）而不是蛇（Q472）时，它就不再在不相关的 SERP 里跟你较劲，而是开始把你排到该排的地方。
  • 同义词与意图覆盖。 你不再需要重复十五个关键词变体。把实体覆盖好，你就能为解析到它的那一簇字符串排名。
  • 推理。 Google 能推断出一个覆盖 React、JSX、hooks 和 virtual DOM 的页面是前端框架领域的真正权威，因为这些实体在图中互为邻居。关键词密度伪造不出这一点。

成为一个实体

第一步战略动作，是把你自己——你的品牌和你的作者——变成 Google 能识别的实体。一个未被识别的品牌对推理层是隐形的，它只是又一个字符串。一个被识别的实体会获得知识面板（Knowledge Panel），赢得信任信号（E-E-A-T 里的那个「T」），并有资格被引用为来源。

Google 通过整个网络上互相印证的证据来构建一个实体。你的工作，是给它喂入一致的、机器可读的、交叉引用的信号。其中三个杠杆最为关键。

1. sameAs——把你的实体链接到已知权威

schema.org 标记里的 sameAs 属性，是说「本页上的实体等同于你早已信任的这个节点」最直接的方式。把它指向 Wikidata、Wikipedia、LinkedIn、GitHub、Crunchbase 和官方社交资料。Wikidata 和 Wikipedia 是价值最高的目标，因为 Google 的知识图谱有一部分正是从它们播种而来。

下面是一家虚构开发者工具公司的 Organization 标记。把它以 JSON-LD 形式放进你的 <head> 或 </body> 之前，最好放在首页和「关于」页上：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://acme.dev/#organization",
  "name": "Acme Dev Tools",
  "url": "https://acme.dev/",
  "logo": "https://acme.dev/logo.png",
  "foundingDate": "2019-04-01",
  "description": "Acme builds open-source observability tooling for distributed systems.",
  "sameAs": [
    "https://www.wikidata.org/wiki/Q123456789",
    "https://en.wikipedia.org/wiki/Acme_Dev_Tools",
    "https://www.linkedin.com/company/acme-dev-tools",
    "https://github.com/acme-dev",
    "https://www.crunchbase.com/organization/acme-dev-tools",
    "https://x.com/acmedev"
  ]
}
</script>

以及与之匹配、用于某位作者的 Person 标记——注意这位作者 worksFor 该组织，从而把两个实体接到了一起：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://acme.dev/team/jane-doe/#person",
  "name": "Jane Doe",
  "jobTitle": "Principal Engineer",
  "worksFor": { "@id": "https://acme.dev/#organization" },
  "url": "https://acme.dev/team/jane-doe/",
  "knowsAbout": ["Distributed tracing", "OpenTelemetry", "Go"],
  "sameAs": [
    "https://www.linkedin.com/in/janedoe",
    "https://github.com/janedoe",
    "https://orcid.org/0000-0002-1825-0097"
  ]
}
</script>

💡 提示：@id 的值是内部锚点，让你的 schema 图能够引用自身。使用像 #organization 这样稳定的 URL 片段，意味着你的 Article、Person 和 BreadcrumbList 块都能指回同一个规范的组织节点，而不必反复重新定义它。这正是图应有的建模方式——定义一次，处处引用。

2. about / mentions——声明你的内容覆盖了什么

about 表示「本页主要是关于实体 X」。mentions 表示「本页提及了实体 Y」。使用真实的实体 ID，这样就毫无歧义：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "OpenTelemetry vs Jaeger: choosing a tracing backend",
  "author": { "@id": "https://acme.dev/team/jane-doe/#person" },
  "publisher": { "@id": "https://acme.dev/#organization" },
  "about": {
    "@type": "Thing",
    "name": "OpenTelemetry",
    "sameAs": "https://www.wikidata.org/wiki/Q98961422"
  },
  "mentions": [
    { "@type": "SoftwareApplication", "name": "Jaeger",
      "sameAs": "https://www.wikidata.org/wiki/Q60803298" },
    { "@type": "Thing", "name": "Distributed tracing",
      "sameAs": "https://www.wikidata.org/wiki/Q105749746" }
  ]
}
</script>

3. 一致的 NAP 与命名

NAP——Name（名称）、Address（地址）、Phone（电话）——必须在所有地方逐字节完全一致：你的站点、Google Business Profile、LinkedIn、Crunchbase、各类目录。不一致的 NAP 会把你的实体撕裂成几个支撑薄弱的候选项，而 Google 可能无法把它们合并。把你规范的实体事实当作配置里的单一可信来源来对待：

# entity.yml — the one place your NAP lives; render everything from this
name:    "Acme Dev Tools, Inc."
url:     "https://acme.dev/"
phone:   "+1-415-555-0142"
address:
  street:  "500 Howard St, Suite 400"
  city:    "San Francisco"
  region:  "CA"
  postal:  "94105"
  country: "US"

⚠️ 注意：对一个朴素的匹配器来说，「Acme Dev Tools」「Acme Dev Tools, Inc.」「ACME」是三个不同的字符串。选定一个法定名称和一个通用名称，并始终如一地使用。同样的纪律也适用于你的域名：除非你有刻意设计的跳转策略，否则别把品牌权威分散到 acme.dev、acme.io 和 getacme.com 上。

主题权威

实体不会独居——它们成簇而活。OpenTelemetry 与 distributed tracing、spans、OTLP 协议、Prometheus、采样策略、埋点库 相连。主题权威（topical authority）意味着可证明地覆盖整片实体邻域以及用户围绕它们提出的问题，而不是为某一个大词排名。

旧的关键词打法会产出十个各自瞄准一个短语的单薄页面（opentelemetry tutorial、opentelemetry vs jaeger、opentelemetry python……），而且常常互相蚕食。实体打法则产出一个内容簇（content cluster）：一根全面的支柱页（pillar）加上彼此互链的支撑页，共同覆盖每一个有意义的子实体和子问题。

关键词方法实体 / 主题方法
规划单元一个搜索短语一个主题及其子实体
页面数量逻辑每个关键词一页页面映射到一张知识图谱
内部链接随意 / 凭相关性直觉围绕实体关系结构化
成功指标为那一个关键词排名在整个 SERP 上占据该主题
风险蚕食、内容单薄覆盖缺口

要构建这张图，就去挖掘 Google 已经与你的主题相关联的实体：

  • People Also Ask 框和「相关搜索」——每一条实际上都是一个子问题或子实体。
  • 你核心实体的 Wikipedia 目录和「See also」——一张免费的、人工策划的实体图。
  • Wikidata 的属性面板——真正的图的边（subclass of、uses、has part）。
  • 用程序快速拉取相关的知识图谱实体：
curl -s "https://kgsearch.googleapis.com/v1/entities:search" \
  --data-urlencode "query=OpenTelemetry" \
  --data-urlencode "types=Thing" \
  --data-urlencode "limit=10" \
  --data-urlencode "key=$GOOGLE_KG_API_KEY" -G \
  | jq '.itemListElement[].result | {name, id: ."@id", desc: .description}'

💡 提示：一条实用的经验法则——要让一个主题赢得权威，你的内容簇应当能回答一位内行同事在 30 分钟对话里可能问到的每一个问题。如果某个子问题既没有页面、也没有章节，那就是一个竞争对手会去填补的覆盖缺口。

收益会复利式增长。一旦 Google 信任你是 distributed tracing 领域的权威，该簇里的新页面排名会更快，因为信任附着在你在该主题内的实体上，而不只是附着在单个 URL 上。

实操步骤

下面是端到端的工作流。每一步都足够具体，可以直接写进工单。

1. 做一次实体盘点。 列出你的站点本身是哪些实体（品牌、产品、作者、地点），以及你想为之成为权威的实体（你的核心主题及其子实体）。对每一个，找到或创建其规范引用——如果有就用 Wikidata QID，没有就用内部 @id。

We ARE:        Acme Dev Tools (Q123456789), Jane Doe (no QID → /team/jane-doe/#person)
We OWN:        distributed tracing, OpenTelemetry, observability, OTLP, span sampling
Gaps to fill:  span sampling (no page), OTLP (only a passing mention)

2. 用 schema 标记实体。 在你的身份页面加上 Organization + Person，在内容页面加上带 about/mentions 的 Article，全部通过 @id 接到一起。用 Schema 生成器 生成并校验 JSON-LD，再用 Google 的 Rich Results Test 和 Schema.org 校验器确认。这正是 第 4 层：内容与结构 中深入讲解的结构化数据纪律。

3. 按实体而非随性来组织内部链接。 每个支撑页都应向上链接到它的支柱页、横向链接到兄弟实体，并使用点明实体名的描述性锚文本（distributed tracing，而非「点这里」）。这就是让你的内容簇作为一张图被读懂的方式：

        [ Pillar: Distributed Tracing ]
        /        |          |         \
 [OpenTelemetry][Jaeger][Span sampling][OTLP]
        \________cross-links between siblings________/

4. 赢得权威性提及。 sameAs 是你的主张；第三方的印证才是证据。让你被 Google 早已信任的来源所引用、报道和链接——会议演讲、热门项目的 GitHub README、行业刊物，以及在确有理由时，一条 Wikidata 词条。无链接的品牌提及同样算数；Google 会把它们读作实体关联信号。

5. 度量并迭代。 跟踪你的品牌是否出现了知识面板、你是否出现在「From sources across the web」和 AI Overviews 里，以及内容簇里哪些页面在排名。填补缺口；加深薄弱节点；做完后刷新 updated 日期。

  • 实体盘点完成（we-are + we-own + 缺口）
  • 带完整 sameAs 的 Organization 和 Person schema 已上线
  • 每个重要内容页都有 about/mentions
  • NAP 在所有渠道一致
  • 内部链接围绕实体图结构化
  • 每季度至少新增一条权威的第三方提及

关键要点

  • ✅ Google 排名的是实体（事物），而非关键词（字符串）——为概念优化，而不是为精确短语优化。
  • ✅ 用 Organization/Person schema 和指向 Wikidata、LinkedIn、GitHub、Crunchbase 的 sameAs 链接，把你的品牌和作者变成被识别的实体。
  • ✅ 使用带真实实体 ID 的 about 和 mentions，精确告诉 Google 每个页面覆盖了什么。
  • ✅ 让你的 NAP 与命名逐字节一致，这样 Google 永远不会把你的实体一分为二。
  • ✅ 通过在一个互链的内容簇里覆盖一个主题的完整实体邻域来建立主题权威，而不是一个关键词一页。
  • ✅ 用 Schema 生成器 生成并校验你的标记，并通过 第 4 层：内容与结构 落地应用。