多语言GEO：如何在每种语言里都被引用
几乎每一份GEO指南都默认网站只有英语版本。我的不是——它跑在13种语言上——一旦我把目光放到英语之外，就有三件事出了问题或表现不佳：hreflang/x-default的正确性、llms.txt的覆盖范围，以及跨语言的结构化数据一致性。这篇讲的是实际会变的东西，外加我用来一次性审查多语言网站的审计提示词。
每周三。28,400+ 读者。纯干货。
✓ 请查收邮箱 — 点击确认链接以完成订阅。
✓ 订阅成功！
✓ 您已在订阅列表中。
2026年9月发布。
TL;DR： 几乎每一份GEO指南都默认网站只有英语版本。我的不是——它跑在13种语言上——一旦我把目光放到英语之外，就有三件事出了问题或表现不佳：hreflang/x-default的正确性、llms.txt的覆盖范围，以及跨语言的结构化数据一致性。这篇讲的是实际会变的东西，外加我用来一次性审查多语言网站的审计提示词。
【运营者视角】 我读过的每一份GEO清单，包括我自己写的两份，都是只针对一种语言写的。直到我去查为什么西班牙语和日语页面没有得到跟英语原版一样的对待——内容一样，结构化数据模板一样，结果却天差地别——我才意识到这些建议默认了多少英语前提。
目录
展开目录
为什么多语言GEO不只是多做12种语言的SEO
传统的国际SEO有一套成熟打法：hreflang标签、翻译内容，完事。GEO多加了一层这套打法覆盖不到的东西，因为AI引擎不只是给你的页面建索引——它要按每次查询、每种语言分别决定，把哪一个唯一的来源引用给用户。这个决定在引擎服务的每种语言里都单独进行，面对不同的竞争对手集合、不同的可引用来源池，有时甚至是完全不同的引擎。
英语版的ChatGPT回答,取用的候选池跟同一个问题的日语版完全不同。忽视这一点，你就会把全部GEO工作只做一遍——用英语——然后假设它会自动传播到其他语言。它不会。
最先出问题的：hreflang和x-default
这是那种会悄悄吃掉你的可见度、却从不以错误形式出现的问题。两种失效模式，都很隐蔽：
- 缺失或错误的x-default。 每个hreflang集群都需要一条
x-default记录，告诉引擎和爬虫，当访问者的语言跟你的任何一个翻译都不匹配时该展示哪个版本。省略它，等于告诉每个没有明确目标的爬虫”自己猜”。 - hreflang指向的不是真正的翻译页面。 这个问题比看起来更隐蔽，也更常见。如果你的语言切换器在某种语言的翻译还不存在时，退回到那种语言的首页，而你又给这些兜底链接打上了
hreflang标签，那你实际上是在宣称一篇纯英语文章是它自己的西班牙语翻译版。事实并非如此。Google的爬虫最终会不再信任整个集群；而依靠你的<link>标签构建引用图谱的AI引擎，会继承同样有缺陷的信号。
我自己就踩过这个坑。我网站页头的语言切换器会在每个语言链接上都输出hreflang，包括那些因为翻译还不存在而退回到某语言首页的链接。每篇纯英语文章都在悄悄地宣称自己有十二个并不存在的翻译版本。找到问题后，修复就是机械性的：只在真正存在翻译时才标注hreflang，并且始终输出x-default——当某个集群没有英语成员时，退回到第一个可用的替代项——这样每个真实的集群都会有一个。
以下是修复后在页面<head>里实际渲染出来的样子：
<link rel="alternate" hreflang="es" href="https://example.com/es/post-slug/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/post-slug/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/post-slug/" />值得在自己网站上按这个顺序检查的三条规则：每个hreflang集群恰好只有一个x-default；没有任何hreflang链接指向一个不是真正翻译的页面；同一个集群里没有两个<link>标签使用相同的语言代码（否则Google会丢弃整个集群，而不只是那个重复项）。
没人检查的漏洞：llms.txt只覆盖英语
llms.txt是一种新兴惯例，用来给AI爬虫提供一份经过整理的优质内容索引，而不是让它们自己爬取、自己猜。我几个月前就为这个网站建了一份。直到为写这篇文章去找数据时，我才注意到：决定哪些文章能进入索引的过滤条件是lang === 'en'，到此为止。
这意味着这个网站十三分之十二的内容，对任何把llms.txt当作索引而不只是建议的爬虫来说都是不可见的。每篇非英语文章仍然会通过网站地图和内部链接被爬取，但那份经过整理、高信任度的索引——专门为了把你最好的页面交给AI引擎而建的那份——只覆盖英语，是因为疏忽,而不是因为决定。
如果你维护着一份多语言的llms.txt，现在就检查一下：这个文件（或这些文件）是不是真的列出了你的翻译文章，还是像我的那样，索引悄悄坍缩回了你的源语言？一份只列出英语URL的共享llms.txt，倒也说不上错——它只是对你网站存在的其他语言完全没起作用。
跨语言的结构化数据与实体一致性
你已经在用的FAQPage、Article和Person结构化数据（如果还没配置，可以看看我的结构化数据拆解），必须在每种语言里说的都是同一件事，因为AI引擎会把所有这些语言合并成一张实体图谱。
有两件事要做对：
- 标识符不翻译，面向人的字符串才翻译。 你的
Person或Organization结构化数据里的@id、url、sameAs数组和jobTitle值，必须在每种语言里完全一致——这才是告诉引擎”跨语言看这是同一个实体”的关键。变化的只应该是周围的文字和面向人阅读的标签。 - 别让过时的翻译落后于结构化数据。 如果你更新了Article结构化数据里的
dateModified，或者在英语版里新加了一条FAQ，同样的改动必须同步到每种语言的JSON-LD里，而不只是文字部分。一个引擎如果看到英语内容上周刚更新，而同一页面的法语版结构化数据还是半年前的，就会把它们读成两个不同的页面，而不是一个页面的两种语言版本。
语言不同，AI引擎也不同
关于GEO的讨论默认围绕ChatGPT、Perplexity和Google AI Overviews展开，因为英语世界的对话就发生在那里。一旦你开始用俄语、中文或韩语发布内容，这就不是全貌了。
Yandex为俄语查询运行着自己的生成式回答层，在俄语搜索市场的份额明显高于Google。百度基于文心一言（ERNIE）的回答对中文内容很重要。Naver的AI摘要对韩语内容很重要。如果你的GEO清单只考虑那三个以美国为中心的引擎，你可能只是在为国际读者实际使用的答案引擎中的60%做优化——而你不会察觉，因为这些引擎都不会出现在Google Search Console里。
我在这里没有干净的方式去检查Yandex或百度上的引用率，我宁愿直说，也不假装不是这样。我能说的是：不要假设你为英语优化的那三个引擎清单，在所有地方都是完整清单。
来自我自己网站的真实证据
这个我可以量化。这是同一篇GEO对比SEO的文章，同样的内容模板，同样的结构化数据，被翻译成每一种语言——数据来自Search Console，时间范围是2026年6月15日到9月11日：
| 语言 | 展示次数 | 平均排名 |
|---|---|---|
| 西班牙语 | 2077 | 31.9 |
| 荷兰语 | 3370 | 46.6 |
| 法语 | 1393 | 25.1 |
| 日语 | 106 | 14.8 |
| 韩语 | 57 | 24.9 |
| 德语 | 86 | 60.6 |
| 意大利语 | 32 | 67.8 |
| 英语 | 569 | 58.2 |
同一篇文章，同样的结构，同样的结构化数据模板，排名区间却从14.8一路跨到67.8。我想诚实地说清楚这能证明什么、不能证明什么：这些是Search Console里的经典Google排名数据，不是AI引用数据——我没有按语言拆分的、干净的ChatGPT或Perplexity引用归因，我也不认识谁有。它确实证明的是：“翻译了之后，同样的优化工作在哪儿都一样有效”这句话，在我自己的网站上是错的。日语版展示次数只占一小部分，排名却超过了包括英语原版在内的所有其他语言。这个页面上有某种东西——竞争程度、翻译质量、实体在日语里如何被识别——在起作用，而这种作用在结构化数据模板完全相同的德语和意大利语版本上并不存在。
让Claude或ChatGPT替你做：一份多语言GEO审计提示词
不用去读hreflang规范就能检查这些。把下面这段连同你网站的URL粘贴给Claude或ChatGPT：
我有一个多语言内容的网站。针对[URL]，帮我检查：（1）这个页面是否输出了
x-default的hreflang标签，页面上每个hreflang标签是否都指向真正的翻译页面，而不是一个兜底的首页；（2）这个页面的JSON-LD结构化数据（Person、Organization或Article）在不同语言之间的@id、url和sameAs值是否一致，还是每种语言都不一样；（3）如果网站有llms.txt文件，它是否列出了英语以外语言的页面。告诉我这几项里具体哪一项不通过，并引用出问题的具体标签或字段，而不是给一段笼统的总结。
在信任这个回答之前，一定要对照页面的实际源代码核实一遍——如果你不让模型看到真实情况，它会很自信地描述一个根本不存在的x-default标签。
应该跳过的做法
不要在没有真实证据的情况下建十三份独立的llms.txt文件——证据指的是能显示各子域AI爬虫访问情况的服务器日志，不是直觉——去证明引擎把你的各语言当作独立的资源来对待。一份划定得当、真正列出了你翻译文章的文件，就能解决上面那个漏洞，而不必承担维护十三份文件的成本。
不要为了填上某个语言的空位，就机器翻译一个页面。粗糙、逐字的翻译对GEO来说比没有翻译更糟——它给AI引擎提供了一个低质量的来源，去跟竞争对手的母语内容比较，而这是最快让你被支持论坛引用为”翻译很奇怪的那个网站”的方式。
结论
如果你的GEO清单是只针对一种语言写的，在把它当作一套系统去信任之前，先拿你表现最差的那个语言去检验它。我自己就有一个真实、隐蔽的hreflang漏洞，还有一份只覆盖英语的引用索引，在我去查之前已经放了好几个月。两个问题修起来都很简单。要不是我带着”第二种语言”的思路去找问题，两个都不会浮出水面。
多语言GEO常见问题
hreflang真的会影响AI引擎的引用吗，还是只影响传统的Google排名？
两者都会，只是作用机制不同。对传统Google来说，hreflang告诉爬虫在搜索结果里该给哪种语言展示哪个URL。对AI引擎来说，hreflang和你的结构化数据一起，是引擎判断”这是不是跨语言的同一个实体/内容”的依据之一——搞错了，就有可能让引擎把你的英语页面和西班牙语页面当成两个不相关的来源，而不是同一个主题被讲了两遍。
是不是我网站支持的每种语言，每篇文章都要翻译？
不需要。在主题和搜索需求能在该市场证明其价值的地方去翻译文章——一篇针对美国的定价指南可能不需要阿拉伯语翻译，而一篇全球性的GEO科普文章大概率需要。跨语言的、没翻译的近似重复内容，比篇数更少但每篇都完整翻译的内容更糟。
怎么判断我的llms.txt范围划定得对不对？
打开这个文件，检查列出的URL里有没有源语言之外的路径。如果所有URL都是同一种语言,而你的网站是多语言发布的，那这个索引的范围就被限制在那一种语言里了，不管这是不是你的本意。
每种语言都需要单独的结构化数据，还是一套结构化数据模块可以到处复用？
一个实体，多语言呈现。标识字段（@id、url、sameAs）在各语言间保持完全一致；面向人阅读的文字（headline、description、FAQ答案）按语言翻译。把它当作一个用多种语言描述的实体，而不是多个实体。
相关阅读： GEO的结构化数据 · 如何用一个智能体把一篇博客文章翻译成13种语言 · 单人运营者的GEO
想让人帮你检查一下自己网站的多语言配置吗？联系我——我为多语言发布的网站做GEO审计，或者你也可以今天就用Claude自己跑一遍上面那段提示词。
每周三。28,400+ 读者。纯干货。
✓ 请查收邮箱 — 点击确认链接以完成订阅。
✓ 订阅成功！
✓ 您已在订阅列表中。
相关文章
将AI实战手册发送到您的邮箱
每周三。28,400+ 读者。纯干货。
请查收邮箱。
我们已向您发送确认邮件 — 点击其中的链接以完成订阅。如果一分钟内没收到，请检查垃圾邮件。
订阅成功。
欢迎 — 下一期很快就会送达您的邮箱。
您已在订阅列表中 — 每周三留意查收。