hreflang 与多语言 AI 可见度档案
多语言站点在 AI 端的核心风险，不是翻译质量，而是一种更隐蔽的错位：回答用对了语言，给出的 URL 却是另一种语言。用户用西班牙语提问，AI 用西语作答，引用链接却指向美式英文版页面——检索命中了、体验错了、转化断在最后一跳。目前对这个问题唯一的系统性实证来自 Glenn Gabe 的多语言实测（G-Squared Interactive，2025-12-01），本页把这份实测的结论矩阵、那条悲观的判断原话、以及 hreflang 在搜索栈的官方机制拆开来讲，最后落到多语言站的监测改法。
Gabe 实测矩阵：五类平台的三档表现
Gabe 用法/意/西语查询测试了主流 AI 平台对翻译内容的处理，按表现分三档：
| 平台组 | 多语言查询下的表现 | 档位 |
|---|---|---|
| ChatGPT、Perplexity、Claude | 频繁返回美式英文版页面——回答对语言、URL 错 | 差 |
| Copilot（Bing 系）与 Gemini | 最好，能对齐语言与页面版本 | 好 |
| AIO 与 AI Mode（Google 搜索栈） | 较好但非每次都稳，AI Mode 比 AIO 稳 | 中 |
差档的原话值得引用存证：「AI Search platforms like ChatGPT, Perplexity, and Claude did not do a great job」。三档分布背后有一条结构线：凡是从搜索检索栈长出来的 AI 功能（Copilot、Gemini、AIO、AI Mode），表现都不差；独立 AI 平台（ChatGPT、Perplexity、Claude）普遍错位。这暗示错位的根源不在「翻译」，在「检索后选版本」这一步——搜索栈有现成的语言路由逻辑可复用，独立平台要么没有、要么没启用。AIO 这一层的机制底座见AI Overviews，两个搜索栈 AI 功能的差异展开见AIO 与 AI Mode 对比，AI Mode 的单独档案见AI Mode。
「疑似不支持 hreflang」：判断原文与推论
对这批独立平台为什么不认语言版本，Gabe 的判断原文是：「we have no idea if the other AI Search platforms support hreflang at all. My guess is they don’t.」——连深耕 hreflang 十几年的从业者都无法确认这些平台是否解析这个标签，倾向于认为根本不支持。
这条判断的推论比判断本身重要：如果 hreflang 在独立 AI 平台那里大概率失效，那么语言信号就必须回到标签之外的地方——内容语言本身（页面正文写什么语言）、URL 与域名结构（子目录、子域名、ccTLD）、站内语言导航的链接文本。这些信号不依赖平台解析任何标签，是唯一「平台不配合也生效」的路由依据。hreflang 从「多语言站的必修配置」降级为「搜索栈专用优化」，是这份实测对多语言 GEO 最实际的改写。
hreflang 在搜索栈的机制：三种官方实现
搜索栈侧 hreflang 依然有效，Google 官方给的三种实现方式如下：
| 实现方式 | 形态 | 适用场景 |
|---|---|---|
| HTML link | <link rel="alternate" hreflang="x"> 进 <head> |
常规网页，静态可输出 head 的页面 |
| HTTP 头 | 响应头携带 Link: 与 hreflang |
非 HTML 资源（如 PDF 的语言版本） |
| sitemap 交叉引用 | sitemap 条目内嵌 xhtml:link |
大型站点，免改页面模板 |
三种实现等价，选哪种取决于渲染架构——head 能否稳定输出、模板是否可控，这正是 SSR 与 SSG 决策的延伸问题，渲染架构对 head 输出的影响见SSR 与 SSG。实现面还有一条官方纪律：hreflang 的互指必须是双向闭环——每个语言版本既指向其他版本，也指向自己（自指），单向声明不构成有效集合。这也是三实现共有的验收标准：版本集合里任何一个成员断链，整个互指组都可能被引擎整体弃用。
要强调边界：这三种实现的「有效」目前只承诺到搜索栈——Google、Bing 及长在它们检索结果上的 AI 功能（AIO、AI Mode、Copilot、Gemini）；上一节已经说过，独立 AI 平台不在此承诺范围内。
监测改法：按「查询语言 × 返回 URL 语言」审计
实测带来的监测动作很具体：多语言站的 AI 可见度审计要按两个维度交叉记账——查询用什么语言，返回的 URL 是什么语言版本。单看「有没有被引用」会漏掉 Gabe 发现的那类错位：引用发生了，但语言版本错了，流量与转化照样流失。执行上按语言对建矩阵，每格记录引用频次与版本命中率：
| 查询语言 → URL 语言 | 本语种版本 | 英文（美式）版本 | 第三语言版本 |
|---|---|---|---|
| 本语种查询 | 命中格：正常 | 错位格：Gabe 实测的典型病灶 | 严重错位：优先排查 |
| 英文查询 | 反向错位：常见于本地化站 | 命中格：正常 | 罕见 |
「小语种查询返回美式英文 URL」就是要盯的第一格——它正是 ChatGPT、Perplexity、Claude 在实测里反复落入的格子。修正手段对应上一节的推论：错位格高发时，与其继续调 hreflang，不如核对内容语言本身与 URL 结构信号是否被稀释（比如英文主站的内链权重压过了本地化版本）。
一个附带的计量陷阱也来自这份实测：Gemini 默认常不给来源链接，需要追问才出现——而「很多人不会追问」。这意味着以「引用链接出现率」为指标的工具在 Gemini 侧会系统性低估其真实引用，审计脚本要么补追问动作，要么在口径里声明这个盲区。
对站长的操作清单
- hreflang 继续做，但把它归类为「搜索栈优化」：三种官方实现任选其一做扎实，不要指望它约束 ChatGPT/Perplexity/Claude 的版本选择。
- 独立 AI 平台的语言路由靠内容本身：正文语言、URL 语言标识（子目录/ccTLD）、语言导航链接文本，三项逐页检查。
- 建立语言对审计矩阵：按「查询语言 × 返回 URL 语言」双维度采样，重点盯「小语种查询返回英文 URL」的格子。
- 审计脚本对 Gemini 补追问动作，否则引用数据系统性偏低；无法补的，在报告口径里显式声明。
- 混合部署时优先保证各语言版本的 head 可被服务端稳定输出——HTTP 头实现是非 HTML 资源的唯一通道。
- 语言版本之间不要互相抢占 canonical，各版本各自声明自指 canonical 加 hreflang 互指，这是版本错乱的第一道保险。
限制与待核实
- Gabe 实测为单人测评（2025-12-01 发布），查询样本集与测试次数未公开，结论外推到其他语言对（如中英）需谨慎。
- 各独立 AI 平台对 hreflang 的支持情况无任何官方表态，「疑似不支持」是从业者推断，待平台文档或实证推翻/确认。
- 「独立平台错位于搜索栈」的结构解释为机制推断，样本内成立，未做跨样本验证。
- Gemini 默认不给来源链接、追问后才显示的行为，存在随版本迭代的可能，引用时注意时点。
引用来源
- Glenn Gabe——AI Search, hreflang, and translated content（G-Squared Interactive，2025-12-01）
- Google 多区域多语言站点官方文档