AI把你认成经销商？我用12个字段做GEO实体消歧，修掉品牌同名、多语言站和Schema冲突

摘要：本文围绕GEO实体消歧展开，系统讲解如何把企业名称、法定主体、官网、品牌别名、地址、行业、社交账号和第三方标识符统一描述成同一个可识别实体，减少搜索系统和生成式AI把“你是谁”判断错的概率。文章从“为什么AI会把制造商、经销商和同名公司搞混”切入，依次说明品牌一致的真实含义、12个核心实体字段、公司标识符的价值、Organization Schema的正确写法、@id与sameAs的用法、WebSite与Organization的区别、多语言网站与hreflang/canonical的配置要点，并给出实体一致性评分、Python自动审计脚本以及常见踩坑清单，最后强调做GEO前应先建立Entity Truth Table，确保AI先确认“你到底是谁”。

GEO实体消歧，是把企业名称、法定主体、官网、品牌别名、地址、行业、社交账号和第三方标识符统一描述成同一个可识别实体，减少搜索系统和生成式AI把“你是谁”判断错的概率。

很多网站真正的问题不是：

AI不知道我的产品。

而是更靠前的一层：

AI到底有没有确认“这些网页、账号、品牌名和公司名称说的是同一家企业”？

例如一家制造企业同时存在：

官网：
ABC Machinery
公司注册名：
ABC Intelligent Equipment Co., Ltd.
LinkedIn：
ABC Machinery Group
YouTube：
ABC Machines
英文站：
abc-machinery.com
德国站：
de.abc-machinery.com
Alibaba：
ABC Equipment
某经销商：
ABC Machinery USA

对于人来说，也许一眼能判断这些名称之间的关系。

对于机器来说，却至少存在6个问题：

ABC Machinery 是公司还是品牌？
ABC Equipment 是不是同一家公司？
ABC Machinery USA 是总部还是经销商？
德国站是不是独立企业？
ABC Machines 是不是另一个品牌？
哪个域名才是官方主体？

Google目前甚至在Organization结构化数据官方文档中直接使用了“识别和区分组织”这样的描述，并明确表示，iso6523Code、naics等部分属性可以在后台帮助区分组织。

所以做GEO时，还有一个经常被内容团队忽略的基础工程：

先解决Entity Identity，再讨论Entity Authority。

为什么AI会把制造商、经销商和同名公司搞混？

因为网站上的“品牌身份”经常不是一个值，而是一组互相冲突的值。

来看一个典型现场。

企业首页：

ABC Machinery

About页面：

ABC Industrial Equipment Co., Ltd.

页脚：

ABC Equipment

LinkedIn：

ABC Machines

产品PDF：

ABC Technology

Schema：

{
"@type": "Organization",
"name": "ABC Group"
}

Google Business Profile：

ABC Machinery Co.

一家公司，出现了：

7个名字

如果这些名字没有明确的关系说明，机器需要自己推断：

ABC Machinery
↓
是不是
↓
ABC Industrial Equipment Co., Ltd.
↓
是不是
↓
ABC Group

一旦外部又存在一个真实的：

ABC Group

歧义进一步放大。

所以GEO里的实体问题，可以抽象成：

flowchart LR
A[品牌名] –> G[企业实体]
B[法定公司名] –> G
C[官方网站] –> G
D[LinkedIn] –> G
E[行业目录] –> G
F[公司标识符] –> G
G –> H[产品]
G –> I[行业]
G –> J[地址]
G –> K[认证]
G –> L[子品牌]
M[经销商] -.不要错误合并.-> G
N[同名公司] -.不要错误合并.-> G

真正的目标不是“所有地方必须一字不差”。

而是：

不同名称之间必须存在明确、可机器理解的关系。

GEO里的“品牌一致”是不是要求所有平台公司名完全一样？

不是。

这是非常重要的区别。

企业可能合理地同时拥有：

品牌名：
Novatek
法定公司名：
Novatek Precision Manufacturing Co., Ltd.
网站简称：
Novatek Precision
历史简称：
NPM
域名：
novatek-precision.com

这些并不冲突。

真正有问题的是：

机器不知道它们为什么不同。

Google的Organization结构化数据正好提供了多个不同字段：

Google明确说明，legalName适合记录与name不同的法定注册名称，而alternateName可以表达其他常用名称。

也就是说，正确做法不是：

把所有名称强行改成一个

而是：

告诉机器：
Novatek
品牌/组织常用名称
Novatek Precision
常用别名
Novatek Precision Manufacturing Co., Ltd.
法定主体

这叫：

实体关系明确。

一个企业到底应该固定哪12个实体字段？

可以先建立一份“Entity Truth Table”，即企业身份事实表。

建议至少维护下面12项：

这张表应该成为：

官网
Schema
社交账号
B2B平台
新闻稿
产品PDF
公司介绍
行业目录

共同引用的“身份基线”。

最危险的不是字段缺失。

而是同一个字段出现多个互相矛盾的版本。

例如：

此时AI遇到问题：

When was Example Company founded?

它应该回答哪一个？

这就是典型的：

Entity Fact Conflict。

为什么公司标识符比“我们是专业厂家”更适合做实体消歧？

因为标识符的歧义远低于营销描述。

下面两句话：

We are a professional manufacturer.

和：

We are a leading machinery supplier.

几乎无法帮助机器区分公司。

但下面这些字段完全不同：

DUNS
GLN
LEI
VAT ID
Tax ID

Google当前的Organization文档甚至给出了ISO 6523企业标识符的具体编码：

例如LEI可以写成：

{
"@type": "Organization",
"iso6523Code": "0199:724500PMK2A2M1SQQ228"
}

DUNS则可以使用：

0060:xxxxxxxxx

Google明确表示，iso6523Code等字段可以帮助系统区分组织，并推荐在适用情况下使用这些标准化标识。

这里要强调：

没有DUNS、GLN或LEI，不代表不能做GEO。

这些字段只在企业真实拥有相应编号时使用。

绝对不要为了Schema完整度：

随机生成一个LEI

那不是优化。

那是制造错误数据。

Organization Schema应该怎么写才不会把公司身份越写越乱？

一个相对完整的B2B企业示例可以这样写：

<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://www.example.com/#organization",
"name": "Novatek",
"alternateName": [
"Novatek Precision",
"NPM"
],
"legalName":
"Novatek Precision Manufacturing Co., Ltd.",
"url": "https://www.example.com/",
"logo": {
"@type": "ImageObject",
"url":
"https://www.example.com/assets/logo.png"
},
"description":
"Manufacturer of precision machined components.",
"foundingDate": "2011-06-18",
"address": {
"@type": "PostalAddress",
"addressLocality": "Ningbo",
"addressRegion": "Zhejiang",
"addressCountry": "CN"
},
"contactPoint": {
"@type": "ContactPoint",
"telephone": "+86-574-12345678",
"email": "sales@example.com",
"contactType": "sales"
},
"sameAs": [
"https://www.linkedin.com/company/example",
"https://www.youtube.com/@example"
]
}
</script>

这里最重要的不是字段越多越好。

而是：

Schema里的每一个事实，都应该和页面可见信息及真实企业资料一致。

Google当前并没有要求Organization必须包含某些字段，而是建议尽可能添加与组织真正相关、且对用户有用的属性。

另外，Google明确表示：

Organization Schema

通常放在：

首页
或
一个描述组织的页面

即可。

不需要机械地把完整组织Schema复制到网站3万个页面。

@id到底是干什么的，为什么很多Schema插件写了一堆？

@id可以理解为：

给Schema图谱中的实体分配一个稳定URI。

例如：

{
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example"
}

然后文章作者、网站、品牌、产品可以引用这个节点，而不是每次重新制造一个“新公司”。

例如：

{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example Manufacturing"
},
{
"@type": "WebSite",
"@id": "https://example.com/#website",
"url": "https://example.com/",
"publisher": {
"@id": "https://example.com/#organization"
}
}
]
}

逻辑变成：

WebSite
↓ publisher
Organization

而不是：

页面1 → Example
页面2 → Example Company
页面3 → Example Ltd
页面4 → Example Group

需要注意：

@id本身不是一个公开的“GEO排名加分项”。

它更大的工程价值在于：

避免自己生成的结构化数据图谱内部出现多个本应相同的实体节点。

sameAs应该链接什么，为什么不能把所有外链都塞进去？

sameAs不是友情链接列表。

Google当前对该字段的解释是：

指向其他网站中包含该组织相关信息的页面，例如社交媒体资料页或评价网站资料页，并且可以提供多个URL。

所以比较合理的是：

"sameAs": [
"https://www.linkedin.com/company/example",
"https://www.youtube.com/@example"
]

而下面这种做法就不合理：

"sameAs": [
"https://customer-a.com",
"https://supplier-b.com",
"https://random-directory.com/article-123",
"https://news-site.com/industry-news"
]

因为这些URL只是：

与你有关

不代表：

就是你这个实体

可以用一个简单原则：

如果这个URL代表的是“这个企业自己的资料身份页”，才优先考虑sameAs。

WebSite Schema和Organization Schema为什么不能混成一个东西？

因为它们描述的是两个不同实体。

Organization
=
企业
WebSite
网站

例如：

{
"@type": "Organization",
"name": "Novatek Precision Manufacturing"
}

描述公司。

而：

{
"@type": "WebSite",
"name": "Novatek",
"url": "https://example.com/"
}

描述网站。

Google当前明确要求，如果希望指定搜索结果里的站点名称，应在网站首页提供WebSite结构化数据。一个域名或子域名目前只支持一个网站名称，子目录不能拥有独立的网站名称。

例如：

https://example.com/

可以有站点名。

https://docs.example.com/

作为子域也可以有。

但：

https://example.com/de/

不能因为它是德语目录，就单独设置一个完全不同的Google网站名称。

推荐的首页结构可以是：

<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id":
"https://example.com/#organization",
"name": "Novatek",
"legalName":
"Novatek Precision Manufacturing Co., Ltd.",
"url": "https://example.com/"
},
{
"@type": "WebSite",
"@id":
"https://example.com/#website",
"name": "Novatek",
"alternateName": [
"Novatek Precision",
"example.com"
],
"url": "https://example.com/",
"publisher": {
"@id":
"https://example.com/#organization"
}
}
]
}
</script>

品牌有简称时到底应该怎么告诉搜索系统？

不要把简称偷偷塞在50篇文章里碰运气。

用：

alternateName

明确表达。

例如：

{
"@type": "WebSite",
"name": "China National Petroleum Corporation",
"alternateName": [
"CNPC"
]
}

Google当前明确支持WebSite.alternateName，而且允许提供多个备用名称，并建议按优先级排列。

同样的逻辑可以用于组织：

{
"@type": "Organization",
"name": "Novatek",
"alternateName": [
"Novatek Precision",
"NPM"
]
}

但不要滥用。

例如：

"alternateName": [
"Best CNC Manufacturer",
"Top CNC Supplier",
"Best Chinese CNC Factory",
"Cheap CNC Manufacturer"
]

这些不是品牌别名。

这是关键词。

多语言网站为什么最容易制造“两个公司”？

因为很多企业翻译网站时，连品牌身份一起“翻译”了。

英文站：

Example Precision Machinery

西班牙语站：

Ejemplo Maquinaria de Precisión

德语站：

Beispiel Präzisionsmaschinen

如果品牌官方名称本来就是：

Example Precision

这种把品牌名全部意译的做法，可能增加实体关联难度。

更合理的是：

Brand:
Example Precision
Description EN:
Precision machining manufacturer
Description DE:
Hersteller für Präzisionsbearbeitung
Description ES:
Fabricante de mecanizado de precisión

即：

品牌身份尽量稳定，描述内容本地化。

多语言页面的hreflang到底应该怎么配置？

Google目前建议，不同语言版本使用不同URL，并通过hreflang明确这些URL之间的语言或地区关系。

假设有：

英语：
https://example.com/en/product
德语：
https://example.com/de/product
西班牙语：
https://example.com/es/product

英语页面可以配置：

<link
rel="alternate"
hreflang="en"
href="https://example.com/en/product"
/>
<link
rel="alternate"
hreflang="de"
href="https://example.com/de/product"
/>
<link
rel="alternate"
hreflang="es"
href="https://example.com/es/product"
/>
<link
rel="alternate"
hreflang="x-default"
href="https://example.com/en/product"
/>

德语和西班牙语页面也要互相声明。

Google明确要求：

每个语言版本
→ 包含自己
→ 包含其他所有语言版本

同时URL必须使用完整的绝对URL。Google支持通过HTML、HTTP Header和Sitemap三种方式表达本地化版本，而且官方明确表示，这三种方式从Google角度是等效的；同时使用三种并不会带来额外搜索收益。

所以完全没有必要：

HTML写一份
+
Header写一份
+
Sitemap再写一份

然后让三个版本半年后互相打架。

选一种自己能维护好的即可。

canonical和hreflang为什么经常互相打架？

这是多语言网站最经典的坑之一。

假设：

/en/product
/de/product
/fr/product

结果三页都写：

<link
rel="canonical"
href="https://example.com/en/product"
/>

等于告诉Google：

德语页面：
我不是主要版本
法语页面：
我也不是主要版本
英语页面：
它才是主要版本

如果三个页面是真正翻译过的独立语言版本，一般不应该这样互相canonical。

Google当前说明，不同语言页面只有在主要正文实际上仍为同一种语言、只是模板被翻译时，才可能被视为重复；对于同语言的地区版本，例如美国英语和英国英语，则可以配合canonical和hreflang使用。

可以简单记成：

错误做法：

把所有全球页面canonical回英文首页

很可能直接削弱本地化页面本身的搜索可发现性。

经销商页面为什么不能写成“官方公司实体”？

假设总部是：

Nova Pump Manufacturing Co., Ltd.

美国经销商是：

Atlantic Pump Solutions LLC

但经销商网页写：

{
"@type": "Organization",
"name": "Nova Pump",
"url": "https://atlantic-pump.example"
}

问题来了。

搜索系统同时看到：

novapump.com
→ Nova Pump
atlantic-pump.example
→ Nova Pump

到底哪个是主体？

更清楚的做法是：

经销商保持自己的法律/商业主体

然后在人类可读内容中说明：

Authorized distributor of Nova Pump

必要时再使用符合实际语义的Schema关系。

千万不要为了“蹭品牌实体”：

让经销商冒充品牌总部

实体数据越脏，后续越难修。

同一个集团有3个品牌时应该合并还是拆开？

判断标准不是“是不是一个老板”。

而是：

用户和市场是否把它们认作独立实体。

例如：

集团：
Atlas Industrial Group
品牌A：
Atlas Pumps
品牌B：
Atlas Filtration
品牌C：
FlowTek

如果三个品牌：

拥有独立产品
独立Logo
独立网站
独立社交账号
独立市场认知

那就不应该为了Schema方便全部写成：

Atlas Industrial Group

可以明确关系：

graph TD
A[Atlas Industrial Group]
A –> B[Atlas Pumps]
A –> C[Atlas Filtration]
A –> D[FlowTek]
B –&gt; E[Pumps]
C –&gt; F[Filters]
D –&gt; G[Valves]

GEO实体设计真正追求的是：

谁是谁
谁属于谁
谁生产什么
谁运营哪个网站

而不是：

所有名字越少越好

为什么Logo也属于GEO实体数据，而不只是UI设计？

因为Logo本身也是组织身份信号的一部分。

Google当前Organization文档明确规定，用于组织Logo的图片：

至少112 × 112像素

同时：

URL必须可抓取
URL必须可索引
必须使用Google Images支持的格式

Google还明确说明，logo属性有助于其理解应该在搜索结果和知识面板中展示哪个组织Logo。

典型错误是：

Schema：
/logo-new.png
首页：
/logo.svg
Open Graph：
/brand-logo-dark.png
第三方资料：
10年前的旧Logo

这不意味着机器一定无法识别企业。

但如果可以减少不必要的身份冲突，就没有必要主动增加噪声。

能不能做一个实体一致性评分？

可以，但要明确：

这不是Google、ChatGPT、Gemini或Perplexity的官方评分。

只是团队内部QA指标。

例如定义12个核心字段：

name
legal_name
domain
country
address
phone
email
founding_date
logo
linkedin
youtube
company_identifier

每个平台每匹配一个：

+1

则：

Entity Consistency Score
=
匹配字段数
÷
可比较字段总数
×
100

例如官网和LinkedIn有10项可以比较：

8项一致
2项冲突

得到：

8 / 10 × 100
=
80

可以自己设置内部规则：

再次强调：

这些阈值只是：

内部项目管理规则

不是搜索算法阈值。

能不能用Python自动检查不同平台的实体资料冲突？

可以。

最简单的做法是不先做复杂爬虫，而是让运营人员把各平台公开资料导出成CSV。

新建：

entity_sources.csv

内容：

source,name,legal_name,domain,country,phone,email,founding_date
website,Novatek,Novatek Precision Manufacturing Co. Ltd.,example.com,CN,+86-574-12345678,sales@example.com,2011-06-18
linkedin,Novatek Precision,Novatek Precision Manufacturing Co. Ltd.,example.com,CN,+86-574-12345678,sales@example.com,2011-06-18
youtube,Novatek,,,CN,,,2011
directory,Novatek Machinery,Novatek Machinery Ltd.,example-machinery.com,CN,+86-574-87654321,info@example-machinery.com,2013

可以明显看到：

directory

这行很可疑。

下面用一个完整Python脚本检查。

保存为：

entity_audit.py

代码如下：

import csv
import re
import sys
from collections import Counter
from pathlib import Path
FIELDS = [
"name",
"legal_name",
"domain",
"country",
"phone",
"email",
"founding_date"
]
def normalize_text(value):
"""
普通文本归一化：
– 转小写
– 去首尾空格
– 连续空格压缩
"""
value = (value or "").strip().lower()
value = re.sub(r"\\s+", " ", value)
return value
def normalize_domain(value):
"""
域名归一化：
https://www.example.com/
www.example.com
example.com
最终都变成：
example.com
"""
value = normalize_text(value)
value = re.sub(
r"^https?://",
"",
value
)
value = re.sub(
r"^www.",
"",
value
)
value = value.split("/")[0]
return value
def normalize_phone(value):
"""
电话只保留数字和开头的+。
"""
value = (value or "").strip()
if not value:
return ""
has_plus = value.startswith("+")
digits = re.sub(
r"\\D",
"",
value
)
return (
"+" + digits
if has_plus
else digits
)
def normalize_date(value):
"""
简单日期归一化。
2011-06-18 保留完整日期；
2011 仍然保留2011。
本脚本不会擅自认为
2011 = 2011-06-18，
因为两者精度不同。
"""
return normalize_text(value)
def normalize(field, value):
if field == "domain":
return normalize_domain(value)
if field == "phone":
return normalize_phone(value)
if field == "founding_date":
return normalize_date(value)
return normalize_text(value)
def load_csv(path):
with open(
path,
"r",
encoding="utf-8-sig",
newline=""
) as file:
return list(
csv.DictReader(file)
)
def choose_reference(rows):
"""
优先把website当作事实基准。
如果没有website，
使用第一条记录。
"""
for row in rows:
if (
normalize_text(
row.get("source")
)
== "website"
):
return row
return rows[0]
def compare_field(
field,
reference_value,
current_value
):
"""
返回：
MATCH
CONFLICT
MISSING
"""
ref = normalize(
field,
reference_value
)
cur = normalize(
field,
current_value
)
if not cur:
return "MISSING"
if not ref:
return "NO_REFERENCE"
if ref == cur:
return "MATCH"
return "CONFLICT"
def audit(rows):
reference = choose_reference(rows)
print("=" * 90)
print("ENTITY CONSISTENCY AUDIT")
print("=" * 90)
print(
"Reference source:",
reference.get(
"source",
"unknown"
)
)
print("-" * 90)
results = []
for row in rows:
source = row.get(
"source",
"unknown"
)
comparable = 0
matches = 0
conflicts = []
for field in FIELDS:
ref_value = reference.get(
field,
""
)

current_value = row.get(
field,
""
)

status = compare_field(
field,
ref_value,
current_value
)

if status in [
"MATCH",
"CONFLICT"
]:
comparable += 1

if status == "MATCH":
matches += 1

if status == "CONFLICT":
conflicts.append(
(
field,
ref_value,
current_value
)
)
score = (
matches / comparable * 100
if comparable
else 0
)
results.append({
"source": source,
"score": score,
"conflicts": conflicts
})
print(
f"{source:&amp;lt;20}"
f"Score: {score:&amp;gt;6.1f}%"
f" Conflicts: {len(conflicts)}"
)
print("-" * 90)
return reference, results
def print_conflicts(results):
print()
print("=" * 90)
print("CONFLICT DETAILS")
print("=" * 90)
conflict_count = 0
for result in results:
for (
field,
reference,
current
) in result["conflicts"]:
conflict_count += 1

print(
f"\\n[{result['source']}] "
f"{field}"
)

print(
" Reference:",
reference
)

print(
" Current: ",
current
)
if conflict_count == 0:
print(
"No explicit conflicts found."
)
def field_consensus(rows):
"""
查看每个字段到底出现了多少个版本。
"""
print()
print("=" * 90)
print("FIELD VERSION SUMMARY")
print("=" * 90)
for field in FIELDS:
values = []
for row in rows:
value = normalize(
field,
row.get(
field,
""
)
)

if value:
values.append(value)
counter = Counter(values)
print(
f"\\n{field}: "
f"{len(counter)} version(s)"
)
for value, count in (
counter.most_common()
):
print(
f" {count:&amp;gt;2}x {value}"
)
def main():
if len(sys.argv) != 2:
print(
"Usage: "
"python entity_audit.py "
"entity_sources.csv"
)
sys.exit(1)
path = Path(
sys.argv[1]
)
if not path.exists():
print(
f"File not found: {path}"
)
sys.exit(1)
rows = load_csv(path)
if not rows:
print(
"CSV contains no data."
)
sys.exit(1)
reference, results = audit(
rows
)
print_conflicts(
results
)
field_consensus(
rows
)
if name == "main":
main()

运行：

python entity_audit.py entity_sources.csv

可能输出：

==========================================================================================
ENTITY CONSISTENCY AUDIT
==========================================================================================
Reference source: website
——————————————————————————————
website Score: 100.0% Conflicts: 0
linkedin Score: 85.7% Conflicts: 1
youtube Score: 100.0% Conflicts: 0
directory Score: 14.3% Conflicts: 6
——————————————————————————————

进一步会输出：

==========================================================================================
CONFLICT DETAILS
==========================================================================================
[directory] legal_name
Reference: Novatek Precision Manufacturing Co. Ltd.
Current: Novatek Machinery Ltd.
[directory] domain
Reference: example.com
Current: example-machinery.com
[directory] phone
Reference: +86-574-12345678
Current: +86-574-87654321
[directory] founding_date
Reference: 2011-06-18
Current: 2013

此时就应该人工判断：

这是旧资料？
经销商？
同名企业？
历史公司名？
还是第三方网站写错了？

脚本负责：

发现冲突

人负责：

解释冲突

不要反过来让程序自动修改企业事实。

为什么脚本没有把“Novatek”和“Novatek Precision”自动判断为同一个？

因为这是故意的。

如果我们写模糊匹配：

if "novatek" in company_name:
same_company = True

那么：

Novatek Precision
Novatek Pumps
Novatek Automation
Novatek Germany

都有可能被错误合并。

实体消歧最怕的不是：

少合并一个

而是：

错误合并两个真实不同的公司

所以更合理的工程策略是：

确定性数据
→ 自动处理
模糊关系
→ 标记人工复核

“厂家”和“贸易公司”这种身份应该怎么处理？

不要只写一句：

We are a manufacturer.

最好让可验证事实支撑这个实体属性。

例如：

如果认证证书写的是：

ABC Manufacturing Co., Ltd.

网站却写：

XYZ Global Group

而页面从来没有解释：

ABC Manufacturing
和
XYZ Global Group
是什么关系

这就会制造新的身份歧义。

解决方法不是隐藏ABC。

而是明确：

XYZ Global
=
对外品牌
ABC Manufacturing Co., Ltd.
生产与注册主体

如果事实确实如此。

为什么多语言站自动跳转也会伤害实体识别？

因为机器可能根本抓不到全部语言版本。

Google当前明确提醒，对于根据IP或Accept-Language动态改变内容的locale-adaptive页面，Google可能无法抓取、索引或排名全部地区版本。

原因之一是Googlebot通常从美国IP抓取，并且请求通常不会设置Accept-Language。Google因此推荐使用独立语言URL配合hreflang。

所以这种配置：

example.com
↓
检测IP
↓
德国IP自动跳/de/
↓
美国IP自动跳/en/

比：

example.com/en/
example.com/de/
example.com/fr/

更容易产生抓取和管理问题。

尤其不要：

Googlebot访问
→ 永远被强制跳英文

然后团队奇怪：

为什么德国页面一直没表现？

做GEO实体审计时应该检查哪些“问题现场”？

可以直接使用下面这张检查表。

GEO实体消歧最容易踩哪些坑？

为什么不能把关键词塞进公司名？

错误：

{
"name":
"Best CNC Machining Manufacturer China"
}

如果真实品牌叫：

Xingda Precision

就应该写真实名称。

Schema描述的是实体事实。

不是Meta Keywords。

为什么不能把分公司和总部都写成同一个Organization？

因为法律和运营主体可能不同。

如果：

ABC Germany GmbH

是真实独立法人，就不应该为了“统一品牌”直接伪装成：

ABC Manufacturing Co., Ltd.

正确目标是：

表达关系

而不是：

删除差异

为什么不能随便往sameAs里放Wikipedia、新闻报道和客户网站？

因为：

mentions you

和：

represents you

不是一个概念。

sameAs应优先表达：

这个页面代表同一实体的在线身份

Google官方示例同样使用社交资料等组织页面作为典型情况。

为什么不能每种语言把品牌名都翻译掉？

因为产品介绍可以本地化，但品牌实体最好保持稳定识别。

例如：

Siemens

不会因为法语页面就改造成一个完全不同的法语品牌。

除非企业本身就存在正式的本地化品牌名称。

为什么不能把Schema写得比真实业务更“豪华”？

例如网站实际上只有一个地址，却写：

"address": [
{"addressCountry": "US"},
{"addressCountry": "DE"},
{"addressCountry": "FR"}
]

只是因为：

产品卖到这些国家

这是错误语义。

销售市场不是企业地址。

FAQ：关于GEO实体消歧还有哪些常见问题？

企业没有LEI、DUNS怎么办？

完全可以不填。

Google的Organization结构化数据没有规定这些字段为必填项。只填写真实存在、适用于企业的字段即可。

缺失比伪造安全得多。

Organization Schema能保证AI正确理解企业吗？

不能。

结构化数据只是帮助搜索系统理解实体的一种机器可读表达，不存在“加上Schema就保证被AI正确识别”的官方承诺。

Google也明确说明，即使使用结构化数据，也不能保证对应搜索功能一定展示。

为什么这件事和GEO有关，而不只是SEO？

以Google为例，其2026年生成式AI搜索指南明确说明，AI Overviews和AI Mode仍然建立在核心搜索排名、质量系统和搜索索引之上，并通过RAG从搜索索引检索网页作为生成回答的依据。

因此：

组织身份识别
搜索索引理解
网页实体关系

仍然构成Google生成式搜索的基础设施。

需要注意的是，把同样的实体工程原则推广到其他AI搜索平台，是合理的工程方法，但不能声称Google的具体Schema规则等于所有生成式引擎的官方排名规则。

网站名称和公司名称必须完全相同吗？

不一定。

例如：

网站名称：
IBM
法律主体：
International Business Machines Corporation

完全可以合理共存。

关键是通过：

name
alternateName
legalName

把关系表达清楚。

Logo最低应该多大？

Google当前Organization Logo指南要求：

至少112 × 112像素

并且Logo URL需要可抓取、可索引。

一个网站能设置几个Google Site Name？

Google目前支持：

每个域名或子域名一个

但不支持：

子目录独立Site Name

例如：

example.com

可以。

news.example.com

可以。

example.com/news/

不能被当成独立站点名称。

多语言网站需要同时使用HTML、HTTP Header和Sitemap三套hreflang吗？

不用。

Google明确表示三种方式效果等价，同时使用并不会获得额外搜索收益，反而增加维护难度。

选一套最容易长期维护的即可。

企业改名后应该怎么办？

不要只改首页Logo。

至少同步检查：

首页
About页面
WebSite Schema
Organization Schema
legalName
alternateName
Logo
社交账号
公司PDF
行业目录
新闻资料
canonical
重定向
第三方企业资料

如果旧品牌仍然被市场使用，可以在事实成立的情况下把旧名保留为：

alternateName

形成：

旧实体名称
→
新实体名称

的连续关系。

最后总结：做GEO前，先确保AI知道“你到底是谁”

GEO经常被理解成：

写更多文章
→
回答更多问题
→
提高AI引用

但还有一条更基础的链路：

品牌名称
↓
法定主体
↓
网站
↓
别名
↓
地址
↓
公司标识符
↓
社交账号
↓
产品
↓
品牌关系

这些数据如果互相冲突，后面的内容越多，甚至可能只是：

更大规模地复制身份噪声。

真正值得先做的是建立一份：

Entity Truth Table

把企业最核心的身份事实固定下来。

然后依次检查：

网站怎么称呼你？
Schema怎么称呼你？
第三方平台怎么称呼你？
不同语言怎么称呼你？
品牌和法定公司是什么关系？
总部和经销商是什么关系？
旧品牌和新品牌是什么关系？

如果这些问题都无法明确回答，就不要急着研究：

“为什么AI还没推荐我？”

因为在“推荐谁”之前，还有一个更基础的问题：

机器是否已经确定，这些散落在互联网不同位置的信息，说的真的是同一个你？

这就是GEO里经常被忽略，却非常适合工程化解决的一层：

实体消歧。