外贸站上了 6 个小语种客服页，客服团队等了一个月，AI 搜索渠道带来的询单几乎是零。用英语问 DeepSeek「哪里能找到说西班牙语的外贸客服」，返回的列表里从来没有我们——直到翻 Structured Data 测试工具的输出才发现，schema 里写的语言是「西班牙语」三个汉字。

问题是怎么被发现的

先交代背景。我们的独立站去年做了多语言客服体系：西语、阿语、俄语、葡语、日语、法语各一个客服落地页，每个页面挂着 ContactPoint，页面底下还有一个「首席客服顾问」的 Person 实体。内容本身没问题，母语客服写的，翻译也过了审。

9 月第二周做例行数据盘点，我拉了两个渠道的引用记录对比。Google 自然搜索里，西语页和葡语页各有零星展示，说明收录没问题。但 AI 搜索这边，用英语提问「Spanish speaking customer service for B2B supplier」，DeepSeek 和另外两家引擎给出的答案里，我们站只出现在英文主站上，六个小语种客服页一次都没被引用过。

一开始以为是权重问题，后来看了同行业一个规模更小的站，人家的西语页在 AI 答案里能被引出来。这就不是权重了。

排查从结构化数据入手。用 Rich Results Test 跑了西语客服页，工具没报错，一切 "valid"。但把 JSON-LD 源码拉出来逐行看，问题就露出来了：

// 坏示例：修复前西语页的原始写法
// availableLanguage 直接放了中文语言名
// 语法合规，但 AI 引擎的实体对齐匹配不上
// 修复思路：值换成 BCP 47 代码
// 同时如实列出英语服务能力
{
  "@type": "ContactPoint",
  "contactType": "customer service",
  // 服务覆盖市场，配合语言声明用
  "areaServed": "ES",
  "availableLanguage": "西班牙语"
}

availableLanguage 里塞的是「西班牙语」三个中文字符。同站的俄语页写的是「俄语」，阿语页写的是「阿拉伯语」。这不是报错，工具照样判 valid——但对一个用英语提问的 AI 引擎来说，这三个汉字既匹配不上 "Spanish"，也匹配不上 "es"。

第二个问题藏在 Person 实体上。客服顾问这个 Person 只写了 name、jobTitle 和 image，翻 schema.org 的 Person 定义才发现有个 knowsLanguage 属性，我们压根没用。也就是说，即使 AI 引擎想确认「这个客服会不会讲西语」，页面上没有任何机器可读的线索。

生成式引擎怎么读语言标记

实体对齐的底层机制

这里得把机制讲透，不然修复就是照抄改一改，下次换个字段还是踩坑。

传统搜索引擎处理语言主要靠两件事：HTML 的 lang 属性和 hreflang 注解，信号弱一点也能靠内容识别兜底。生成式引擎优化（Generative Engine Optimization, GEO）的逻辑不一样——AI 引擎在回答「找会讲 X 语言的客服」这类问题时，倾向于直接消费结构化数据里显式声明的实体属性，而不是去正文里做语言推断。

schema.org 里和语言相关的属性有三层分工，很多人混着用：

我们的问题 precisely 出在第二层和第三层：服务声明层写了错误的值，人员实体层干脆没写。AI 引擎做实体对齐的时候，「西班牙语」这三个字在它的语言实体库里对应不上 ISO 639-1 代码 es，这条 availableLanguage 等于白写。

关于值的格式，schema.org 规范里 Language 类型的值可以是一个语言名称文本，但实践中对 AI 引擎最稳的写法是 BCP 47 语言代码（比如 es、ar、pt-BR）。BCP 47 是 IETF 的语言标签标准，前两位小写字母是 ISO 639-1 语言码，后面可以带地区子标签。写代码而不是写语言中文名，好处是绕开了翻译歧义——「西班牙语」在英语世界是 Spanish，在引擎的中文语料里可能又对齐到别的实体，而 es 这个码位在 BCP 47 注册表里只对应西班牙语一种语言，没有第二种解读。

还有一个容易被忽略的点：AI 引擎回答多语言服务问题时，经常把 Person 和 ContactPoint 关联起来交叉验证。如果 Person 上没有 knowsLanguage，ContactPoint 上那句语言声明就成了孤证，置信度打不上去，答案里就不会引你。

flowchart TD
    A[用户用英语提问<br>寻找西语客服] --> B[AI 引擎检索候选页面]
    B --> C{读取 ContactPoint<br>availableLanguage}
    C -->|值是 es / Spanish| D[进入候选池]
    C -->|值是「西班牙语」| E[实体对齐失败<br>跳过该页面]
    D --> F{读取关联 Person<br>knowsLanguage}
    F -->|声明一致| G[引用进答案]
    F -->|缺失 knowsLanguage| H[置信度不足<br>降低引用优先级]

动手改：三步修完六个页面

改动本身不大，难的是想清楚每个页面该写什么。我们把 6 个客服页的 JSON-LD 全部重构了一遍。

第一步，Language 值全部换成 BCP 47 代码。西语页的 ContactPoint 改成这样：

// 修复后：西语页 ContactPoint 的写法
// 值全部换成实体对齐友好的结构
// name 放英文语言名，alternateName 放代码
{
  "@context": "https://schema.org",
  "@type": "ContactPoint",
  "contactType": "customer service",
  "areaServed": "ES",
  // 语言能力如实声明，西语加英语
  "availableLanguage": [
    // 西语是主打，放数组第一位
    {
      "@type": "Language",
      "name": "Spanish",
      "alternateName": "es"
    },
    {
      "@type": "Language",
      "name": "English",
      // 客服能接英语询单，所以列进来
      "alternateName": "en"
    }
  ]
}

关键决策是 name 用英文语言名、alternateName 放语言代码，两头都照顾：引擎按名称匹配拿到 "Spanish"，按代码匹配拿到 "es"。西语客服实际也接英语询单，所以英语也列进 availableLanguage，这符合真实服务能力，不虚标。

第二步，给客服 Person 补 knowsLanguage。这位首席客服顾问是秘鲁人，母语西语、工作语言英语和葡语，那就如实写三个：

// 客服 Person 实体：补 knowsLanguage
// 语言能力按真实情况写，不虚标
// name 用英文语言名，alternateName 放代码
// 三个条目结构一致，方便引擎逐一对齐
// 实体里别放电话号码，用 telephone 单独挂
{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Maria",
  "jobTitle": "Chief Customer Advisor",
  // 母语西语、工作语言葡语和英语
  // 数组顺序按熟练度排，无强制要求
  "knowsLanguage": [
    // 第一条：母语，引擎权重最高的一条
    {
      "@type": "Language",
      "name": "Spanish",
      // 语言代码与名称双写，两头匹配
      "alternateName": "es"
    },
    {
      "@type": "Language",
      "name": "Portuguese",
      // 第二外语，客服实际能接葡语询单
      "alternateName": "pt"
    },
    {
      "@type": "Language",
      "name": "English",
      // 国际询盘主力语言，必须声明
      "alternateName": "en"
    }
  ]
}

第三步，页面级补 inLanguage。每个客服页的 WebPage 节点加上自己正文的语言代码，西语页写 es，阿语页写 ar。这一步是给「页面内容语言」和「服务语言」划清边界——页面是阿语写的、但客服能用英语沟通，这两个声明不冲突，反而互相印证。

改动节奏是 9 月第三周一个下午做完的，6 个页面合计动了 14 处 JSON-LD。改完当天用 Rich Results Test 和 validator.schema.org 各跑了一遍，全部通过。之后用 site 检索确认新版本 JSON-LD 已被抓取，等了 11 天看数据。

修复前后的数据对比

我们统计了修复前 4 周和修复后 4 周的 AI 渠道引用记录，口径是：用英、西两种语言各提问 20 个固定问题（找西语客服、找葡语客服、多语言 B2B 服务商等），记录 AI 答案里各语言客服页被引用的次数。

两个变化值得单独说。一是英文提问场景从 0 到 9，这正是 availableLanguage 换成 BCP 47 代码的直接效果——引擎用英语问句去匹配 es/Spanish，两边终于对上了。二是 Person 信息开始出现在引用文本里，「说西语和葡语的客服顾问」这类描述被引擎采信，说明 knowsLanguage 起了交叉验证作用。

修正一下预期：引用量起来了，但询单转化没有同步线性增长，西语页的 AI 渠道询单 4 周只多了 5 条。结构化数据解决的是「被看见」，落地页本身的信任要素是另一场仗。

几个容易踩的坑

坑一：工具判 valid 不代表引擎看得懂。 schema.org 允许 Language 的值是普通文本，validator 不会拦「西班牙语」，但生成式引擎的实体对齐会。校验工具只能保证语法合规，语义层面的对齐要自己把关。

坑二：hreflang 不能替代 availableLanguage。 有同事问过，页面已经做了 hreflang，是不是就够了。不是一回事——hreflang 告诉引擎「这个页面给什么语言的用户看」，availableLanguage 告诉引擎「这个客服能用什么语言服务」。阿语页面配英语客服是完全合法的组合，hreflang 表达不了后一层。

坑三：别照抄别人的语言清单。 每个客服页的 availableLanguage 应该如实反映该页客服的真实服务能力。全部页面堆十种语言，看似曝光面大，实际是拿置信度换曝光，AI 引擎交叉验证不过关反而降权。按实际能力写，宁可少。

flowchart LR
    A[多语言客服页] --> B[WebPage inLanguage<br>页面正文语言]
    A --> C[ContactPoint availableLanguage<br>服务提供语言]
    A --> D[Person knowsLanguage<br>客服个人语言能力]
    B --> E[三层声明互相印证]
    C --> E
    D --> E
    E --> F[AI 引擎高置信引用]

往后看，AI 搜索对多语言服务实体的要求只会更细。现在写 BCP 47 一级代码够用，但像 pt-BR 和 pt-PT 这种地区变体，引擎迟早会区分着问。语言标记这层基础建设，早做比晚做便宜得多。

参考与延伸

• schema.org availableLanguage — 属性定义与可挂载类型
• schema.org knowsLanguage — Person/Organization 语言能力属性
• IANA Language Subtag Registry — BCP 47 语言代码官方注册表
• Google 搜索中心：结构化数据标记指南 — 通用结构化数据规范

有做多语言站的朋友，可以把自己页面的 availableLanguage 拉出来看看值写的是什么，评论区聊聊你们踩过的版本。

关键词：GEO、availableLanguage、knowsLanguage、BCP 47、Schema.org、多语言客服、AI 引用