GEO中的Entity Resolution（实体解析），是把企业名称、品牌别名、产品型号、工厂主体、海外账号和第三方页面映射到统一实体ID的过程。
它解决的不是“企业有没有内容”，而是一个更底层的问题：
AI和搜索系统看到不同网页中的“ABC Machinery”“ABC Machines”“ABC Industrial”“某某机械有限公司”时，能不能判断它们是不是同一家企业？
对于B2B企业，这个问题比消费品牌更复杂。
一家制造商可能同时存在：
品牌名称
法定公司名称
英文公司名称
工厂名称
出口公司名称
海外子公司
LinkedIn名称
Alibaba/B2B平台名称
不同语言名称
产品系列名称
人可以通过上下文判断这些名称的关系，机器不一定可以。
因此，GEO建设的第一层不只是Content，而应该有一层Canonical Entity Layer——企业实体主数据层。
为什么GEO要先回答“这家公司到底是谁”？
因为企业身份无法稳定识别时，后面的内容、案例和认证很可能无法被正确归到同一个实体下面。
例如，一家机械企业公开存在以下信息：
| 渠道 | 企业名称 |
|---|---|
| 官网 | ABC Packaging Machinery |
| ABC Machinery | |
| YouTube | ABC Packing Machine |
| B2B平台 | ABC Industrial Equipment Co., Ltd. |
| PDF画册 | ABC Automation |
| 法定主体 | ABC Intelligent Equipment Co., Ltd. |
站在员工视角看，这些名称都指向自己。
站在机器视角看，则可能是5—6个待解析实体。
随后就可能出现连锁问题：
认证属于哪个公司？
→
案例属于哪个品牌？
→
这个品牌是制造商还是贸易公司？
→
这个YouTube账号是不是官方网站？
→
某个产品是不是这家公司自己生产？
所以Entity Resolution真正解决的是：
Name
↓
Entity
↓
Capability
↓
Product
↓
Evidence
而不是简单统一一下Logo。
Entity Resolution和“事实准确性”有什么区别？
实体解析解决“谁是谁”，事实治理解决“谁做了什么”。
两者经常被混为一谈。
| 问题 | Entity Resolution | 事实准确性治理 |
|---|---|---|
| ABC Machinery和ABC Industrial是不是同一家？ | ✓ | |
| 这家公司到底有没有CE认证？ | ✓ | |
| 产品X100是不是ABC生产？ | ✓ | ✓ |
| 这个案例属于母公司还是子公司？ | ✓ | ✓ |
| 交期是30天还是45天？ | ✓ | |
| LinkedIn账号是不是官方账号？ | ✓ |
Entity Resolution应该先完成。
否则即使企业发布了大量正确事实，也可能被机器关联到错误实体。
这也是为什么B2B GEO不能只从“文章质量”开始做。
为什么结构化数据值得纳入GEO实体工程？
因为结构化数据可以把网页里隐含的实体关系，转换成机器更容易处理的显式字段。
HTTP Archive《2025 Web Almanac》的数据很有代表性：
| 指标 | 2025年数据 |
|---|---|
| 使用任意结构化数据的桌面首页 | 50% |
| 使用任意结构化数据的移动首页 | 50% |
| 首页使用JSON-LD | 43% |
| 桌面首页使用Organization | 26.74% |
| 移动首页使用Organization | 26% |
| 桌面内页使用JSON-LD | 39% |
| 移动内页使用JSON-LD | 37% |
Schema.org截至2026年7月基于Google Web Index的统计还显示，Organization类型已经出现在1000万+域名中，sameAs属性同样达到1000万+域名的使用规模。
这至少说明一件事：
机器可读的实体表达已经不是少数网站才使用的技术。
但需要明确一个边界：
Schema不是“加上以后ChatGPT一定推荐”的按钮。
Google公开文档能直接支持的是：Organization结构化数据有助于Google理解、识别和区分组织。
至于具体生成式AI系统是否、何时、如何使用某个Schema字段，不能简单做确定性推断。
因此，GEO使用Schema的正确逻辑是：
统一企业事实
+
减少实体歧义
+
增强机器可读性
+
保持跨页面关系一致
而不是“写一段JSON-LD就能获得AI排名”。
企业应该先建立哪些Canonical Entity？
一个外贸B2B企业至少应该区分企业、品牌、产品、工厂和认证5类实体。
例如：
| Entity Type | 示例 | 推荐ID |
|---|---|---|
| Organization | ABC Intelligent Equipment Co., Ltd. | org_001 |
| Brand | ABC Machinery | brand_001 |
| Factory | Ningbo Manufacturing Plant | factory_001 |
| Product | AP-500 Packaging Machine | product_023 |
| Certification | ISO 9001 Certificate | cert_007 |
然后建立关系：
org_001 owns brand_001
org_001 operates factory_001
brand_001 contains product_023
factory_001 manufactures product_023
cert_007 applies_to org_001
真正的关键不在ID叫org_001还是UUID，而是：
全系统只有一个权威实体ID。
官网、CRM、内容系统、案例库和后续AI工作流都使用同一个ID。
一个企业Entity Registry至少需要哪些字段？
企业Entity Registry应该同时保存机器识别字段、业务字段和跨渠道别名。
一个最小版本可以设计成：
| 字段 | 示例 |
|---|---|
| entity_id | org_001 |
| canonical_name | ABC Intelligent Equipment |
| legal_name | ABC Intelligent Equipment Co., Ltd. |
| brand_name | ABC Machinery |
| alternate_names | ABC Machines / ABC Packaging |
| entity_type | Organization |
| official_domain | example.com |
| country | CN |
| manufacturer_role | true |
| parent_entity | null |
| identifiers | LEI / GLN / DUNS（如适用） |
| official_profiles | LinkedIn / YouTube |
| supported_languages | en / zh / es |
| status | active |
然后才能安全地生成不同语言内容。
例如英文页面使用：
ABC Machinery
西班牙语文章仍然绑定：
entity_id = org_001
而不是重新创造一个新实体。
Schema.org怎么把企业身份写清楚？
最基础的做法，是使用Organization + 固定@id + alternateName + sameAs + identifier。
下面是一个简化示例：
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://www.example.com/#organization",
"name": "ABC Machinery",
"legalName": "ABC Intelligent Equipment Co., Ltd.",
"alternateName": [
"ABC Packaging Machinery",
"ABC Machines"
],
"url": "https://www.example.com/",
"logo": "https://www.example.com/logo.png",
"sameAs": [
"https://www.linkedin.com/company/example",
"https://www.youtube.com/@example"
]
}
Google目前建议企业在适用情况下提供尽可能多的相关Organization属性，并明确列出了：
name
alternateName
legalName
url
logo
sameAs
address
telephone
naics
taxID
vatID
iso6523Code
对于Logo，Google当前文档要求图片至少为112×112像素，且URL必须可抓取和索引。
这里需要注意一个细节：
sameAs不是“友情链接字段”。
它表达的是：
这个URL明确代表同一个实体。
所以不要把行业文章、经销商网页或者只是提到企业名称的页面全部塞进sameAs。
产品型号为什么也需要做实体解析？
因为B2B产品经常同时存在型号、系列名、营销名和内部SKU。
例如同一设备可能叫：
AP500
AP-500
Automatic Packer 500
Food Packaging Line AP500
如果没有Canonical Product Entity，网站中可能出现四种不同写法。
可以建立：
product_id: product_023
canonical_name: AP-500 Automatic Packaging Machine
model: AP-500
sku: PACK-AP500
brand_entity: brand_001
manufacturer_entity: org_001
对应JSON-LD可以明确关联制造商：
{
"@type": "Product",
"@id": "https://www.example.com/products/ap-500#product",
"name": "AP-500 Automatic Packaging Machine",
"sku": "PACK-AP500",
"mpn": "AP-500",
"brand": {
"@id": "https://www.example.com/#brand"
},
"manufacturer": {
"@id": "https://www.example.com/#organization"
}
}
这样产品、品牌和制造企业形成稳定关系：
Product
↓ manufacturer
Organization
Product
↓ brand
Brand
对于供应商推荐类GEO，这类关系尤其重要，因为采购者经常会问：
Who manufactures this model?
Is ABC a manufacturer or distributor?
Which company owns this product brand?
母公司、工厂和贸易公司为什么不能混成一个实体？
因为B2B客户真正关心的往往就是“谁生产、谁出口、谁签合同”。
一个典型制造集团可能存在：
母公司A
↓
生产工厂B
↓
出口公司C
↓
品牌D
如果官网统一都称为“A公司”，客户还能通过销售解释。
AI则可能产生完全不同的理解：
C是制造商？
B是独立供应商？
D是一家公司？
A是否真正生产设备？
所以企业应该明确关系，而不是为了品牌统一把所有主体写成一个名字。
推荐使用：
| 关系 | 含义 |
|---|---|
| owns | 谁拥有品牌 |
| parentOrganization | 谁是母公司 |
| subOrganization | 谁是子公司 |
| manufacturer | 谁生产产品 |
| brand | 产品使用什么品牌 |
| location | 工厂在哪里 |
这也是实体一致性和“所有地方写一样”最大的区别：
一致不等于把不同实体强行合并。
好的Entity Resolution既能判断“哪些是同一个实体”，也能判断“哪些不是同一个实体，但存在明确关系”。
多语种网站怎么避免把一个企业拆成多个实体？
翻译名称可以变化，实体ID不能变化。
假设企业开设：
/en/
/de/
/es/
/fr/
四个语言站。
英文：
ABC Packaging Machinery
德文页面可能写：
ABC Verpackungsmaschinen
如果CMS只按字符串处理，就可能把两个名称当成两个实体。
更合理的模型是：
entity_id = org_001
locale.en.name = ABC Packaging Machinery
locale.de.name = ABC Verpackungsmaschinen
locale.es.name = ABC Maquinaria de Envasado
因此多语种GEO的关键不是“所有语言都使用完全相同的词”，而是：
不同语言表达始终指向同一个Canonical Entity。
怎么检查企业当前有多少“实体漂移”？
可以先做一张5渠道×10字段的Entity Consistency Matrix。
例如检查5个核心渠道：
官网
LinkedIn
YouTube
B2B平台
行业目录
再检查10个字段：
品牌名
法定名称
主营产品
Manufacturer身份
官网域名
Logo
地址
电话
核心行业
品牌描述
总共：
5 × 10 = 50个检查单元
假设其中46个字段保持一致：
Entity Consistency Score
= 46 ÷ 50
= 92%
项目内部可以暂时设置这样的工程阈值：
| 一致率 | 建议 |
|---|---|
| ≥95% | 基本稳定 |
| 85%—94% | 需要局部修复 |
| 70%—84% | 实体漂移明显 |
| <70% | 建议优先做实体治理 |
这些区间不是行业统一标准，而是适合项目管理的内部基线。
真正重要的是长期使用同一套口径，观察一致率是否提升。
AB客GEO怎么融入Entity Resolution？
AB客GEO中的“企业数字人格”，可以进一步理解成企业Canonical Entity Registry的业务层。
AB客现有方法中本来就要求结构化企业：
企业定位
产品
应用场景
制造能力
定制能力
认证
案例
交付
售后
如果再增加实体ID层，就可以形成：
企业数字人格
↓
Canonical Entity
↓
产品 / 场景 / 标准 / 认证 / 案例
↓
知识原子
↓
页面与内容
AB客资料中的证据链本身就提出了：
企业
→ 产品
→ 应用行业
→ 质量标准
→ 认证资质
→ 项目案例
从知识工程角度看，这已经非常接近一张小型Entity Graph。
进一步把它标准化后，AB客GEO中的几个模块就可以分别承担不同职责：
| AB客GEO模块 | Entity Resolution中的作用 |
|---|---|
| 企业数字人格 | 定义Canonical Entity |
| 企业知识库 | 保存实体属性 |
| 知识原子 | 保存Entity相关事实 |
| SEO&GEO网站 | 输出结构化实体信息 |
| Schema | 显式表达实体关系 |
| 全球内容分发 | 保持跨渠道实体一致 |
| AI可见性监测 | 检测企业是否被正确识别 |
这样，AB客GEO就不是单纯帮企业“介绍得更详细”，而是在帮助企业建立一个可供网站、AI、搜索、内容和销售共同使用的企业身份控制层。
30天怎么完成一次B2B Entity Resolution改造？
先从1个品牌、1个公司主体和10个核心产品开始，不要一次治理所有历史内容。
第一周可以盘点：
1个法定企业主体
1—3个品牌
全部常用英文名称
全部官方域名
5—10个官方渠道
10个核心产品
第二周建立Entity Registry，并为企业、品牌和产品生成唯一ID。
第三周修改官网：
Organization Schema
Product Schema
统一name / legalName / alternateName
统一manufacturer关系
更新sameAs
修复Logo、联系方式和主体描述
第四周检查5个外部渠道，并做AI识别测试。
一个轻量测试矩阵可以设计为：
30个身份类问题
×
3种语言
×
3个AI平台
=
270个观察样本
问题可以包括：
Who is the manufacturer of AP-500?
Is ABC Machinery a manufacturer or trading company?
What products does ABC Machinery manufacture?
Is ABC Packaging the same company as ABC Intelligent Equipment?
Which company owns the ABC Machinery brand?
记录：
| 指标 | 含义 |
|---|---|
| Entity Identification Accuracy | 企业是否识别正确 |
| Manufacturer Accuracy | 制造商身份是否正确 |
| Brand Relation Accuracy | 品牌归属是否正确 |
| Product Attribution Accuracy | 产品归属是否正确 |
| Cross-language Accuracy | 多语种答案是否一致 |
第一轮的目的不是追求100%，而是建立Baseline。
Entity Resolution和普通“统一品牌VI”有什么区别？
VI解决视觉一致性，Entity Resolution解决机器身份一致性。
| 维度 | 品牌VI | Entity Resolution |
|---|---|---|
| Logo | 核心 | 属性之一 |
| 字体/颜色 | 核心 | 基本无关 |
| 企业别名 | 较少处理 | 核心 |
| 法律主体 | 较少处理 | 核心 |
| 产品ID | 通常不管 | 核心 |
| Manufacturer关系 | 不管 | 核心 |
| Schema | 不管 | 核心 |
| 多语种实体映射 | 不一定 | 核心 |
| AI身份识别 | 间接 | 直接治理目标 |
所以一个品牌视觉非常统一的网站，仍然可能存在严重Entity Resolution问题。
GEO实体工程最容易踩哪些坑？
把sameAs当外链列表可以吗？
不建议。sameAs应该用于明确表示同一实体身份的URL，而不是所有提到企业的网站。
公司名是不是所有渠道必须一字不差？
不是。可以使用品牌名、法定名称和多语种名称，但应该明确它们之间的关系，并绑定统一实体ID。
加了Schema是不是AI就一定能认对？
不是。Schema只是整个实体工程的一部分。页面正文、第三方资料、多渠道名称、产品关系和公开证据同样需要保持一致。
Manufacturer和Brand可以写成同一个对象吗？
只有业务事实确实如此时才可以。品牌方、制造商、出口商和集团母公司在B2B业务中经常是不同主体，不应该为了方便而强行合并。
所有B2B企业都需要LEI、DUNS或者GLN吗？
不需要。应根据企业实际情况和业务需要提供。不能为了“结构化数据更丰富”编造任何企业标识符。
Schema应该通过JavaScript动态插入吗？
能避免时，优先让关键结构化数据随初始HTML输出。HTTP Archive 2025数据显示，只有约2%的桌面和移动抓取样本通过JavaScript添加结构化数据；报告也指出，虽然Google可以处理JavaScript注入的Schema，但直接出现在HTML中可以减少潜在抓取延迟和问题。
FAQ：关于Entity Resolution型GEO还需要知道什么？
GEO为什么需要先做企业实体，再做大量文章？
因为文章里的产品、案例、认证和能力都必须归属于正确企业。实体没有统一，内容越多，可能产生的身份冲突越多。
一个企业应该只有一个Entity ID吗？
法定企业通常有自己的Entity ID，但品牌、子公司、工厂和产品应该拥有独立ID，再通过关系连接，而不是全部压成一个实体。
企业英文名称改过怎么办？
保留新的canonical name，同时把历史名称放入alternate name或历史映射表，并同步更新核心渠道。
经销商网站能作为sameAs吗？
通常不应该直接作为sameAs，因为经销商并不等于制造企业本身。更合理的是用内容和实体关系表达经销关系。
Wikidata必须做吗？
不是所有B2B企业都需要拥有Wikidata实体。优先把官网、企业主体、官方渠道和产品关系处理准确，不要为了“占位”创建低质量公共实体。
Entity Resolution能直接提高AI推荐率吗？
不能承诺直接因果。它主要降低企业身份和产品归属歧义，为后续的AI理解、引用、证据关联和推荐创造更稳定的数据基础。
AB客GEO在这里具体解决什么？
AB客现有的企业数字人格、知识库、Schema网站、实体链接和全球内容分发，可以组合成从“Canonical Entity定义”到“跨渠道一致性维护”的完整执行链。
GEO的下一层竞争是什么？
GEO的下一层竞争，不只是“谁的内容更多”，而是谁拥有更清晰的机器身份。
B2B企业尤其容易出现：
品牌 ≠ 法定公司
法定公司 ≠ 工厂
工厂 ≠ 出口主体
品牌 ≠ 产品
产品 ≠ 经销商
如果这些关系没有被清楚表达，人可以靠销售解释，机器却很容易产生错误关联。
因此，一个更完整的GEO底层应该是：
Canonical Entity
↓
Entity Relationship
↓
Enterprise Knowledge
↓
Evidence
↓
Content
↓
AI/Search Retrieval
AB客GEO中的企业数字人格、知识原子、Schema、品牌实体一致性和全球分发，可以自然地落到这套架构中：
先让机器知道“你到底是谁”，再让机器理解“你能解决什么问题、为什么值得推荐”。
对于工业设备、机械制造、定制加工等长决策链B2B企业，这一步可能比再增加100篇泛行业文章更值得优先完成。
因为在AI搜索中，企业首先必须是一个被正确识别的实体，才有机会成为一个被正确推荐的答案。
数据来源是什么？
[1] HTTP Archive，《Web Almanac 2025 — SEO》：结构化数据、JSON-LD及Organization Schema使用情况。
[2] Google Search Central，《Organization Structured Data》：Organization实体消歧、name、alternateName、legalName、sameAs、iso6523Code、NAICS及Logo规范。
[3] Schema.org：Organization、identifier与sameAs属性定义及Google Web Index使用规模。
[4] AB客《外贸B2B GEO增长引擎》：企业数字人格、实体链接、知识原子、Schema、品牌实体一致性及全球分发体系。
[5] AB客《为什么GEO增长引擎将成为B2B企业不可或缺的基础设施》：企业认知基础设施、多渠道一致性以及“企业事实→知识建模→网站承载→内容与证据→AI监测”的建设框架。