多语言 GEO

1. 多语言 GEO 是什么

多语言 GEO（Multilingual GEO）是 GEO 在跨语言场景中的应用：分析 答案循环 中哪些步骤与语言无关、哪些会随语言改变，并说明如何应对这些变化。

定义（GEO Wiki 工作定义）：多语言 GEO 是针对 AI 引擎开展的优化实践。这类引擎会根据语言确定检索范围，再从中采信和引用来源。答案循环的基本流程保持不变，但来源池、跨语言实体绑定、内容块的可引用度和可信来源池都会随语言改变。

会随语言改变的四类机制，每类用一句话概括：

• 来源池（source pool）：检索按语言进行，查询语言决定引擎实际使用的语料库；不同语言并不共用一个统一的来源池。
• 实体绑定（entity binding）：品牌在不同语言中会采用不同的名称，但这些名称只对应一个规范实体。引擎还需单独判断，能否跨语言确认各个名称与该实体的对应关系。
• 内容块的组织方式（chunk shape）：用于判断可引用度的经验标准（段落密度、句长、标点和结构）都根据特定语言的语料校准。用英语语料训练的抽取方法不能直接套用到中文，反过来也一样。
• 可信来源池（trust pool）：每种语言对权威来源的认定都不相同。E-E-A-T 这一概念本身不会改变，但用来证明来源权威性的具体信号会因语言而异。

在 生成式引擎优化 循环的每一步中，都需要根据语言分别处理；多语言 GEO 不能简化为在英语流程上增加翻译。下文的框架适用于各种语言，之所以采用 zh ↔ en 作为具体例子，只是因为目前这对语言的实证材料最充分。

2. 四个维度的速览

维度	与语言无关的部分	随语言改变的部分	见
来源池	每次检索都会使用某个具体语料库，并不存在全球共享的统一语料库	查询语言决定引擎使用哪个语料库，不同语言对应不同的网页范围	§3
实体绑定	信誉信号归属于一个规范实体，而不是某一种名称字符串	实体名称因语言而异；引擎能否跨语言确认各个名称都对应同一实体，需要单独判断	§4
内容块抽取	可引用的内容必须结构清楚、便于快速阅读，并能明确归属到具体来源	根据英语标点和结构校准的抽取方法，不能直接套用到中文	§5.1
归属方式	引用必须在答案中说明论断来自哪里	具体归属方式（编号脚注与行内具名）会因语言而不同	§5.2
可信来源池	E-E-A-T 取决于佐证，而不是自我声明	可供佐证的来源池按语言划分，各种语言认可的权威信号也不相同	§5.3

3. 不同语言的来源池与相关引擎

AI 引擎会先根据查询语言确定检索范围，再从检索到的来源中生成答案，并不存在跨语言共享的全局语料库。因此，在英文答案中出现，不代表也会在中文答案中出现，反过来同样如此；两者是针对不同网页范围进行的两次独立检索。

                  "best CRM for SMB"
                        │
            ┌───────────┴───────────┐
            ▼                       ▼
      en query path           zh query path
            │                       │
       retrieves from          retrieves from
       en web slice            zh web slice
       (Wikipedia-en,          (Wikipedia-zh, Baidu
       vendor docs,            Baike, Zhihu, vendor
       SE Land, Reddit,        cn docs, Weixin 公众号
       G2, Capterra…)          articles, 36kr, …)
            │                       │
            ▼                       ▼
       en answer               zh answer
       (different sources, often different conclusions)

两种语言对应的来源范围并不一致。Wikipedia-zh 的条目数大约只有 Wikipedia-en 的五分之一；百度百科在中国境内的体量明显大于 Wikipedia-zh，但西方引擎无法访问；知乎与微信公众号是主要的内容发现入口，西方没有完全对应的渠道；厂商文档的中文译本通常更新较慢，有时根本没有。即使查询和品牌相同，中英文环境下也会得到不同的 SERP 和答案。

以下列出使用各个来源池的引擎，以及相应需要放行的爬虫：

引擎	来源池	运营方	需要放行的爬虫 UA
Google AI Overviews	以英文为主，依托 Google 检索覆盖多种语言	Google	Googlebot、Google-Extended
ChatGPT search	以英文为主，多语言检索	OpenAI	GPTBot、OAI-SearchBot、ChatGPT-User
Perplexity	以英文为主，多语言检索	Perplexity	PerplexityBot、Perplexity-User
Google Gemini	以英文为主，依托检索覆盖多种语言	Google	Google-Extended
百度 AI 搜索	中文，与百度索引一体	百度	Baiduspider
通义千问（前身 通义）	中文，基于 Qwen	阿里	未公开网页爬虫 UA
豆包	中文，字节跳动生态	字节跳动	Bytespider（火山引擎有相关文档）
元宝	中文，混元 + 微信公众号语料	腾讯	未公开
DeepSeek	中英双语，由 API 模型提供支持的对话产品	DeepSeek	没有公开的网页爬虫 UA：产品由 API 模型支撑，并不是索引引擎

这里有三点需要注意。元宝会检索微信公众号内容，而任何西方引擎都无法访问这类语料，这是来源池不对称的典型案例。Baiduspider 在 www.baidu.com/search/spider.html 提供了公开说明，并遵守 robots.txt 指令；其他几家中文厂商的透明度要低得多。DeepSeek 的产品是由 API 模型提供支持的对话界面，并不是网页检索器，因此无需专门放行 DeepSeek 爬虫。所谓「被 DeepSeek 引用」，通常是指内容被纳入模型训练数据，或由接入的第三方检索服务提供，并非来自实时检索。

2025 年的中国 AI 搜索市场在结构上与西方截然不同。36 氪（2025 年 2 月） 的从业者综述显示，中国 AI 用户已超过 2.3 亿，整个生态分为三类：传统的百度/Google 检索、由小红书主导的社交搜索（应用内日搜索约 6 亿次），以及 AI 原生助手。西方没有与小红书完全对应的产品：用户直接在社交内容应用中发现信息，而不是从搜索框开始。

屏蔽 GPTBot 不等于屏蔽 Baiduspider，反过来也一样。不同来源池由不同的爬虫抓取，只监测其中一种语言，也就无法发现另一种语言的覆盖缺口：只监测英文排名的工具，不会发现中文来源池中的内容空白。

4. 跨语言实体绑定

一个品牌在不同语言中会采用不同的名称，但这些名称只对应一个规范实体。引擎能否跨语言确认各个名称与该实体的关系，需要单独判断；这与 实体识别 在单语场景中处理的是同一类解析问题，只是范围扩大到了多种语言。

可以这样理解：一个规范实体可以在多种语言中采用多种名称。Wikidata 的 Q-id 是不受语言限制的共同实体标识；分语种的 Wikipedia 页面（en-Wikipedia、zh-Wikipedia 等）则分别提供同一实体在不同语言中的佐证。自 2013 年起，Wikidata 集中维护所有 Wikipedia 条目之间的跨语言链接：标签与描述可以存入任意数量的语言；如果请求的语言没有对应标签，系统会按预设顺序查找其他语言版本（Wikidata Help:Multilingual）。

跨语言解析可以使用 sameAs 明确标出对应关系，指向不同语种的 Wikipedia 页面和 Wikidata URI。Schema.org 对这个属性的定义正是这种用法：sameAs 是 “URL of a reference Web page that unambiguously indicates the item’s identity. E.g. the URL of the item’s Wikipedia page, Wikidata entry, or official website”（schema.org/sameAs）。JSON-LD 的写法见 Schema.org 与 AI。在跨语言场景中，sameAs 对一致性的要求尤其高：不同语言中的名称必须对应同一实体，而且彼此不能矛盾。

以下是按出现频率排序的常见问题：

常见问题	为什么会导致身份信息分散	如何处理
音译/译名不统一	同一品牌在中文里出现三种不同写法：拼音（Aikemi）、译名（艾克米）、商标译名（亚克美）。写法不统一会妨碍引擎判断它们都指向英文 Acme 这一实体	选定一种规范的中文写法，在所有中文渠道中保持一致，并用 sameAs 将中文和英文形式对应起来
中文互联网中完全没有存在感	只有英文名称；中文查询找不到对应的中文名称和页面，也就无法完成解析	先积累中文互联网中的佐证（Wikipedia-zh 页面、百度百科条目、中文厂商文档，以及中文来源池中权威网站的提及），再优化标记
中英文确实采用两个不同名称（本地化产品名），却没有用 sameAs 标明二者关系	引擎会把两个名称视为互不相关的实体，已经掌握的相关信息也会分别归入两个实体	在两种语言的页面和 Wikidata 上都添加 sameAs；再通过同时提到两个名称的正式稿件或媒体报道，进一步证明二者的对应关系
两种语言的提及从不交叉	中英文提及都存在，但没有任何一篇来源同时包含两种名称和 sameAs 标记	至少提供一份可靠的佐证材料，例如 Wikidata 条目、双语新闻通稿或 Wikipedia 页面，并在其中同时写明两种名称

与 实体识别 §6 对长尾品牌的判断相对应，跨语言场景下的结论是：实体能否被识别，取决于它在两种语言的来源池中都得到多大程度的佐证。跨语言实体链接研究以 Wikidata 作为共同实体标识，可以将 100 多种语言中的提及对应到同一个包含约 2000 万个实体的知识库（Botha、Shan & Gillick，EMNLP 2020）；但这项研究使用的是 Wikipedia 摘要，而不是开放网络中的长尾品牌。全球知名品牌可以稳定地被跨语言识别；长尾品牌即使添加了 sameAs，也常常无法被识别，因为两种语言中都缺少可供该标记比对的材料。

5. 可引用度、归属方式和可信度判断都会随语言变化

业界常常把三件事视为与语言无关：段落如何被抽取、引用如何说明来源、哪些来源值得信任。实际并非如此。针对这三项的判断标准，都是依据某一种语言的网页训练或校准的。概念本身不会改变，但各语言用来体现这些概念的具体方式并不相同。

5.1 内容块的组织方式与可引用度

用于判断 可引用度 的内容块抽取方法，包括段落长度、句子密度、标题安排和是否便于快速阅读等，主要根据英语语料校准。中文内容块的结构并不相同：

维度	英文常态	中文常态	对以英文语料训练的抽取系统有何影响
句长	句子较短，以句号收尾	句子偏长，常用逗号连接多个分句（即「流水句」）	系统容易把一句中文视为长度接近英文段落，从而无法按单句抽取和引用
标点	使用 ASCII 半角 . , ;	使用不带空格的全角 。 ， ；	系统对字符跨度和分词方式的假设不再适用，容易错误划分内容块边界
段落密度	通常一段表达一个想法	一段承载多个想法很常见	即使中文读者阅读顺畅，系统也可能认为段落信息过密，不适合按短段抽取
行内结构	常用项目符号、子标题和空白行区分结构	以连续行文为主，结构关系写在段落中	这类经验可能低估中文页面的可引用度：内容组织得当，但缺少西式版面层级

解决办法不是模仿英文写法，那样只会产生僵硬的 AI 腔中文，既不利于读者理解，也未必能提高机器抽取的准确性。更合适的做法是为中文内容提供清楚的层级结构：使用明确的 H3 小标题，让每段第一句概括要点，提供汇总表，并把核心论断写在支撑材料之前。应在保留中文行文节奏的基础上明确层级，而不是让中文迁就英文表达。

5.2 具名来源密度与归属方式

英文专业内容通常使用编号引用或脚注式上标（[1]、[2]）注明来源；中文专业内容则更习惯直接在行文中写出来源，例如「据 IDC 报告」「Gartner 数据显示」，而较少使用编号。引用 vs 提及 所述的具名来源密度与可引用度之间的关系，在两种语言中同样成立，但归属的具体呈现方式不同。

如果引擎主要根据编号引用模式校准，即使中文内容清楚、归属方式规范，也可能漏掉其中一部分来源信息。照搬英文脚注习惯往往不符合中文阅读习惯；采用自然的中文行内具名方式，同样有助于提高可引用度，但相关判断标准需要针对中文重新校准。

5.3 可信来源池与佐证

E-E-A-T 需要判断哪些来源具有权威性，而可供判断的来源池按语言划分。以下是简单对比：

层级	英文池示例	中文池示例
百科/KB	Wikipedia-en、Wikidata	Wikipedia-zh、百度百科、Wikidata
优质媒体	NYT、FT、The Economist、WSJ	财新、第一财经、南方周末
行业权威	TechCrunch、Stratechery、MIT Tech Review	36 氪、虎嗅、IT 之家
从业者长文	Substack、行业博客、Hacker News 讨论	知乎、微信公众号长文
政府/官方	gov.uk、ec.europa.eu、.gov	gov.cn、各部委站点、央视网

不同语言认可的权威信号并不相同。在中文来源池中，政府类来源的权重高于英文来源池。平台原生内容（知乎、微信公众号、小红书帖子）的权重也明显更高，因为中文互联网中的公共讨论很大程度上发生在这些平台。在某些行业，中文来源池中 KOL 的影响力甚至高于机构来源，这种情况在英文来源池中相对少见。可信度判断之所以要按语言区分佐证来源，并不是因为信任在不同语言中有不同含义，而是因为各语言可用的权威来源不同。

可引用度和可信度都是稳定的概念，但用于判断二者的具体信号会随语言而变。

6. 技术层：hreflang、URL 国际化与区域爬虫

hreflang 属于基础规范；实际检索则以按语言划分的来源池为基础。

技术项	作用	对 GEO 的影响
hreflang 标注	在传统 Google 检索中，帮助系统为用户展示合适的语言和地区版本；Google 明确表示，它不用 hreflang 识别语言，而是由自身算法判断（Google Search Central）	多语言站点在传统检索中需要用它区分语种。在纯 LLM 答案场景下，hreflang 的作用要弱得多，因为生成答案时不会把 HTML 头部元数据和 JSON-LD 当作知识图谱解析（见 Schema.org 与 AI §5）。它是基础规范，并非决定性因素
URL 国际化方式：子目录（/zh/...）、子域名（zh.example.com）、ccTLD（example.cn）	决定爬虫可以访问的范围、托管/CDN 所在区域，以及不同语种版本之间如何合并链接权重	这个选择会带来 SEO 和运营方面的后果（.cn 站点通常需要 ICP 备案；在某些信号上，子域名会被视为独立站点）。但对 GEO 来说，更重要的是内容通常会进入哪个语言的来源池，而不是 URL 本身采用哪种形式。主流做法是使用子目录
区域爬虫可达性	负责各语言来源抓取的爬虫能否访问站点：西方一侧有 GPTBot、PerplexityBot、Google-Extended；中文一侧有 Baiduspider、Bytespider；两侧分别受到不同的防火墙、CDN 区域规则和按 UA 设置的 robots.txt 影响	影响最大：内容无法抓取，也就无法进入检索。Baiduspider 如果不能访问某个站点，无论中文内容质量多高，该站点在中文来源池中的存在感都是零。这是多语言 GEO 审计的首要检查项

即使 hreflang 标注完善，如果内容在中文来源池中毫无存在感，仍然不会在中文场景中被引用；即使 hreflang 不完整，只要中文来源池中有扎实的佐证，内容依然能被引用。技术配置很重要，因为爬虫能够访问站点是参与检索的必要条件；hreflang 也很重要，因为 AI 引擎的大量检索仍然依赖传统搜索。但二者都不是决定来源选择的机制，真正需要关注的是哪些来源会被实际检索到。

按语言独立维护的 robots.txt 配套文件见 llms.txt；更广义的爬虫访问规范见 AI 爬虫。

7. 现有证据的结论与适用范围

现有证据足以支持三项机制层面的判断：来源池不同、实体信息会分散、内容抽取方式存在差异。但在品牌层面，中文引擎与英文引擎的引用偏好相差多少、哪些来源的差异更大、相差几倍，目前都没有严谨的公开数据。

研究或资料支持的结论	适用范围
多语言 LLM 在检索增强生成中系统性偏向选用英文来源：高资源语言主导单语知识抽取；在跨语言知识选择中，英文也具有结构性优势（Wu 等人，arXiv:2410.21970）	这是 RAG 知识选择基准的测试结果，并不是对已上线产品品牌引用行为的测量。由此可以判断英文偏向来自系统结构，而非文风；但不能据此直接计算某个品牌在中英文环境中的引用系数
跨语言实体链接使用 Wikidata Q-id 作为不受语言限制的共同实体标识：双编码器模型能把 100 多种语言中的提及对应到同一个包含约 2000 万个实体的知识库（Botha、Shan & Gillick，EMNLP 2020）	测试数据来自 Wikipedia 摘要和一个精选的多语言基准，并不是对开放网络中长尾品牌识别情况的测试。Wikidata 可以作为共同实体标识，sameAs 可以明确标出对应关系；但具体长尾品牌能否被识别，取决于两种语言的来源池中是否都有充分佐证，单靠标记并不够
GEO 研究中的 +40% 提升数字是基于英文测得的：Aggarwal 等人在内部引擎和 Perplexity 上，对改写后的英文内容和英文查询做了测试（论文摘要 · arXiv:2311.09735）	这一数字不能跨语言迁移。大致可以借鉴的是总体方向：对内容进行实质性改写，例如增加引用、统计和引述，比使用关键词技巧更有效。但 +40% 只代表 2023–24 年英文引擎采用特定方法、处理特定领域内容时的上界
中国 AI 搜索生态在结构上有所不同：市场主要分为三类，即传统的百度/Google 检索、由小红书主导的社交搜索，以及 AI 原生助手；中国 AI 用户约 2.3 亿，小红书应用内日搜索约 6 亿次（36 氪，2025 年 2 月）	这是从业者和市场层面的佐证，说明不同来源池不仅语言不同，内容生态的构成也不同；它并没有测量某个具体品牌在中英文环境中的引用偏好差值
只靠翻译的本地化，在 AI 参与内容检索和排序后越来越难以奏效：AI 引擎会在排序前进行跨语言检索并统一处理内容；在更新速度影响结果的情况下，内容更新较快的市场会在全球范围内占据优势（Search Engine Land，Hunt，2026 年 1 月）	这是西方从业者提供的佐证，与上述结构性结论方向一致；它仍然只能说明总体方向，无法给出可引用的具体系数

截至 2026 年 5 月，关于中英 AI 引擎在品牌引用偏好上的差异，尚无公开发表的严谨基准。目前没有任何公开研究系统比较过 ChatGPT、Perplexity、Gemini 与豆包、元宝、百度 AI 搜索，分别在各自主要语言的场景中如何回答针对同一品牌、同一意图的查询。任何人若声称中文 AI 引擎对品牌具名来源的引用比英文引擎多某个具体百分比，都夸大了现有证据。现阶段可根据四个维度的总体变化开展工作，但不能把英文来源池中测得的系数直接用于中文来源池的决策。

8. 多语言场景下的常见误区

误区	为何看似合理	为什么不成立
「把英文条目翻译过来就够了」	翻译确实是必须完成的工作	不同语言中的名称没有通过 sameAs 建立对应关系，也缺少中文佐证，实体信息因而分散；同时，按语言划分的来源池也被忽略。直译还会把英文段落节奏带入中文，导致行文僵硬，比写得到位的原生中文页面更难抽取
「子目录、子域名和 ccTLD 是最关键的决定」	这些选择确实会带来明确的技术和运营后果	这仍然只是基础规范层面的选择；无论采用哪种 URL 形式，来源池的结论都不变。站点即使目录结构完善，如果在中文来源池中没有任何佐证，中文存在感依然为零
「正确设置 hreflang，就完成了多语言 GEO」	hreflang 是多语言 SEO 中最常被讨论的问题	hreflang 用于传统检索中的语种区分；Google 也声明，它甚至不使用 hreflang 做语言识别。在纯 LLM 答案场景中，生成答案时不会把 HTML 头部元数据当作知识图谱解析；真正起作用的是来源池和实体绑定，而不是头部标签
「百度、通义、豆包不提供 SERP API，所以无法优化」	缺少 API，看起来就无法衡量优化结果	来源池仍能帮助判断需要优化哪些基础内容和信号，并不取决于是否有测量工具。积累中文互联网中的佐证、完善实体绑定，并按中文内容块的特点提供清晰结构，这些工作能否完成，与目前能否测量输出没有必然关系
「品牌名在英文里到处都有，到了中文也会被识别」	同一个品牌看似应当在各种语言中得到一致识别	没有中文互联网中的佐证，中文查询就找不到对应实体。sameAs 只是一项声明；能否识别取决于佐证，而不是声明
「我的英文页面在 Google AIO 里被引用过，那中文页面在通义里也会被引用」	一种语言中的引用看似可以延续到另一种语言	这是针对两个不同来源池进行的两次独立检索，使用的引擎不同，所处的监管环境也不同。一个来源池中的可见度不会自动延续到另一个来源池，必须分别建立

常见问题很少只是「忘了翻译」，更多时候是误以为 §2 所列四个维度中的某一项与语言无关，而实际并非如此。

9. 为什么这对 GEO 有意义，以及该怎么做

多语言 GEO 并不是一门全新的学科，而是针对每一个语言来源池分别开展 GEO 优化，并以 §2 的四个维度作为各来源池的审计清单。

目标	相关内容
检查不同语言来源池中的存在感	GEO 审计 操作指南（按语言分别检查）
让中文页面具备便于抽取的结构	可引用度 操作指南（待发布）；§5.1 已说明具体形式
建立品牌身份在不同语言间的对应关系	实体识别 和 Schema 实施指南
获得中文来源池中的提及	见 品牌提及，重点关注不局限于单一语言的提及来源
完善结构化实体页面（Wikidata、各语种 Wikipedia）	知识图谱存在
判断英文来源池认可哪些可信度信号	E-E-A-T
了解各引擎从哪些来源池检索	见上文 §3 与 生成式引擎
从完整循环中理解这一过程	答案循环
系统掌握整套方法	生成式引擎优化

实际执行时，应逐一审计业务涉及的各语言来源池，并分别检查四个维度。大多数团队会发现，自己只在一种语言的来源池中积累了充分的内容和佐证，而在其他语言中要么几乎不可见，要么内容和信号并不适配；通常是因为团队误以为完成「翻译加 hreflang」就等于完成了其他工作。

参考资料

学术：

• Wu, S., Tang, S., Yang, J., Wang, S., Jia, R., Yu, S., Yao, S. & Su, J. (2024). Not All Languages Are Equal: Insights into Multilingual Retrieval-Augmented Generation. arXiv:2410.21970
• Botha, J. A., Shan, Z. & Gillick, D. (2020). Entity Linking in 100 Languages. EMNLP 2020. ACL Anthology
• Aggarwal, P. 等（2024）。GEO: Generative Engine Optimization。KDD ‘24。arXiv:2311.09735 · 论文摘要（适用范围：研究仅测试英文内容和英文查询）

官方/标准：

• Schema.org — sameAs — “URL of a reference Web page that unambiguously indicates the item’s identity”
• Google Search Central — 向 Google 说明你的页面有本地化版本（hreflang） — hreflang 标注方法，以及「Google 不用 hreflang 做语言检测」的明示
• Wikidata — Help:Multilingual — 多语言标签、缺少所需语言时的查找顺序、集中维护的跨语言链接

中文 AI 引擎（官方入口）：

• 百度 — chat.baidu.com（面向用户的 AI 搜索） · 千帆智能问答 API
• 阿里 — 通义千问（前身通义；Qwen 模型系列）
• 字节跳动 — 豆包
• 腾讯 — 元宝（混元，整合微信公众号内容作为引用来源）
• DeepSeek — deepseek.com（API 服务；没有公开的网页爬虫 UA）

业界：

• Hunt, M.（2026-01-21）。International SEO in 2026: What still works, what no longer does, and why。Search Engine Land
• 36 氪（2025-02-11）。2025 搜索之战愈演愈乱：从新旧王朝到三’族’鼎立。36kr.com