多语言 GEO

1. 多语言 GEO 是什么

多语言 GEO（Multilingual GEO）是 GEO 在跨语言场景下的延伸：研究 答案循环 中哪些步骤与语言无关、哪些会随语言改变，并讨论对会改变的那部分该如何应对。

定义（GEO Wiki 工作定义）：多语言 GEO 是针对 AI 引擎所做的优化实践，而这类引擎检索、采信和引用的来源，都来自按语言划分的一片网页切片。其前提是：答案循环的整体形态保持不变，但有四类机制会随语言一同改变，即来源池、跨语言实体绑定、内容块的可引用度、信任来源的佐证。

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

• 来源池（source pool）：检索按语言进行，引擎实际拉取的语料库由查询的语言决定，并不是跨语言统一的一个池子。
• 实体绑定（entity binding）：品牌在每种语言里都有一个表面形式，但只对应一个规范实体；引擎能否跨语言地把表面形式连接到这个规范实体，是另一道独立的关卡。
• 内容块形态（chunk shape）：判断可引用度的那一套经验（段落密度、句长、标点、结构）都是在某一种语言的语料上校准出来的；在英语上训练出的抽取经验，无法干净地迁移到中文，反过来也一样。
• 信任来源池（trust pool）：什么样的来源算权威，每种语言里都不相同；E-E-A-T 这一概念本身是稳定的，但能够支撑它的具体可观察形态会因语言而不同。

语言是 生成式引擎优化 循环中每一步内部都需要分情况处理的一个维度，而不是叠加在英语默认流程之上的翻译问题。下文给出的框架是通用的，具体的 zh ↔ en 例子只是目前现场证据最为充分的一对。

2. 四个维度的速览

维度	与语言无关的部分	随语言改变的部分	见
来源池	检索总是从某个具体语料库里发生，并不是从一个全球共享的总池子里发生	具体是哪个语料库由查询的语言决定，引擎抓取的是按语言划分的一片网页切片	§3
实体绑定	信用归属到的是一个规范实体，而不是一串字符串	表面形式因语言而异；引擎能否跨语言把表面形式连接到规范实体，是另一道独立关卡	§4
内容块抽取	可引用的内容必须是结构化、可扫读、可归属的	按英语标点和结构校准的抽取经验，无法干净地迁移到中文	§5.1
归属形态	引用要把「这一论断从哪里来」写进答案	归属的形态（编号脚注 vs 行内具名）会因语言而不同	§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 原生助手。小红书这种形态在西方找不到完全对应的例子：发现行为直接发生在一个社交内容 App 里，而不是搜索框前。

屏蔽 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；跨语言场景是这道凭据最严苛的考场：多种表面形式必须收敛到同一个节点，而且彼此之间不能互相矛盾。

按出现频率排序的失败形态：

失败形态	为什么会让身份被切散	修复方向
音译/译名漂移	同一品牌在中文里出现三种不同写法：拼音（Aikemi）、译名（艾克米）、商标译名（亚克美），三者都让引擎认不出它们指的是英文 Acme 这同一个节点	选定一种规范的中文写法，在所有中文渠道里保持一致，并用 sameAs 在两侧把它和英文形式连起来
中文完全没有存在感	只有英文表面形式；中文查询连一个可落脚的中文字符串都没有，更谈不上解析	先打下中文一侧的佐证基础（Wikipedia-zh 页面、百度百科条目、中文厂商文档、中文池权威来源的提及），再去优化标记
中英确实是两个不同的名字（本地化产品名），却没有 sameAs 把它们连起来	引擎会把两者当作不相关的两个实体，先验也被分到了两个节点上	在两边页面和 Wikidata 上都加 sameAs；再用同时点名两种形式的编辑稿件或媒体报道，把这道连接佐证起来
两边的提及池从不交叠	英中两侧的提及都存在，但从来没有在同一篇来源里和这道凭据同时出现过	至少做出一份扎实的佐证材料：Wikidata 条目、双语新闻通稿或 Wikipedia 页面，里面同时点名两种表面形式

与 实体识别 §6 关于长尾品牌的判断相对应，跨语言场景下的结论是：**实体能否被识别，取决于它在两种语言池中同时被广泛佐证的程度。**跨语言实体链接的研究把 Wikidata 当作主干，能把 100 多种语言里的提及连接到一个约 2000 万实体的共享 KB（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 检索里，把语种和地区变体送到正确的 SERP 位置；Google 明确说过它不用 hreflang 做语言识别，语言由它自己的算法判断（Google Search Central）	多语言站点在传统检索上需要它来做语种区分。在纯 LLM 的答案场景下作用要弱得多，因为 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 万实体的单一 KB（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 把两边连起来，也没有中文侧的佐证），按语言划分的来源池被忽略；而且直译会把西式段落节奏带进中文，读起来僵硬，比一份写得到位的原生中文页面更难被抽取
「子目录 vs 子域名 vs ccTLD 是最关键的决定」	既显得技术性又显得果断	这只是基础规范层面的选择，有运营层面的后果；无论选哪种 URL 形态，来源池的结论都同样成立。一个目录结构完美、却在中文池里没有任何佐证的站点，中文存在感依然为零
「hreflang 修好，多语言 GEO 就修好了」	hreflang 是多语言 SEO 中最容易被搜到的话题	hreflang 的作用是在传统检索里做语种区分；Google 自己也声明，它甚至不用 hreflang 做语言识别。在纯 LLM 的答案场景下，HTML 头部元数据不会在答案生成时被当作知识图谱来解析；真正起作用的是来源池和实体绑定，而不是头部标签
「百度、通义、豆包不提供 SERP API，所以没法做优化」	看起来是一道测量上的天花板	来源池的结论告诉你该优化哪些输入，本身与是否有测量工具无关。把中文侧的佐证赚到手、把实体绑定修好、为中文内容块形态搭好骨架，这些输入是否做到，和你能否测到输出之间没有必然联系
「品牌名在英文里到处都有，到了中文也会被识别」	看上去是一致的	没有中文侧的佐证，中文查询根本没有可对应的目标。sameAs 只是一项声明；识别靠的是佐证，不是声明
「我的英文页面在 Google AIO 里被引用过，那中文页面在通义里也会被引用」	看上去具有可传递性	这是两次互不相交的检索事件，作用在两个互不相交的池子上，背后是不同的引擎、不同的司法管辖。跨池的可传递性不是默认结果，必须一个池子一个池子地赚出来

失败的常见情形很少是「忘了翻译」，更多的是把 §2 中四个维度里的某一个误判成与语言无关，而实际上它并不是。

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

多语言 GEO 并不是另起炉灶的一门学科，它就是对每一个语言池各跑一遍 GEO，把 §2 的四个维度作为每个池子的审计清单。

你的意图	从这里入手
审计按语言划分的来源池存在感	GEO 审计 playbook（按语言切分跑）
让中文页面在结构上可被抽取	可引用度 playbook（待发布）；§5.1 已给出形态
让品牌身份跨语言绑定	实体识别 + Schema 实施 playbook
赢得中文池里的提及	品牌提及，按独立于语言的提及池角度去读
拿下结构化节点（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