适用读者：给外贸独立站维护中英双语站的前端与 SEO 工程师；负责让 AI 搜索引擎正确引用自家产品资料的技术负责人；已经上了 JSON-LD，但发现 AI 引用总是"串台"的人。

5 月 26 日晚上，一家做汽配出口的独立站运营阿May 在群里甩了张截图，配了一句原话："AI 引我们的产品页，耐压参数引的是英文版，型号口径引的是中文版，它是不是觉得我们发了两篇稿子？"截图里的 AI 答案确实这样：客户用中文问"DN15 黄铜卡套接头的工作压力"，答案主体来自中文页，括号里补的 psi 参数却单独标注来源是英文页，两条引用被并排摆着，看不出是一家的东西。

这件事正好落在生成式引擎优化（Generative Engine Optimization, GEO）的地盘上：GEO 管的不是排名，而是 AI 在生成答案时，愿不愿意把你的内容当成口径统一、来源可信的材料去引。当天我把 4 月 26 日到 5 月 25 日这 30 天的 AI 引用记录翻了一遍，统计下来跨语言引用占比只有 12%，而且这 12% 里一多半还是口径打架的错配引用——中文提问引英文数字、英文提问引中文描述，AI 把两个语言版本当成了两个独立卖家。

后面的事按时间线讲：6 月 10 日上线结构化数据改造，7 月 25 日复盘，跨语言引用占比做到 34%，错配引用基本归零。改动核心就两个 schema.org 属性：workTranslation 和 translationOfWork。

问题是从日志里看出来的

我们的站是 Next.js 双语路由，中文页 /blog/xxx，英文页 /en/blog/xxx，URL 一一对应。内容是两个团队各写各的：中文版一个型号写 1400 字，带选型指南和安装注意事项；英文版只有 600 字，纯参数表。传统 Google 搜索一直没出大问题，hreflang 声明是全的，两个版本在搜索结果里也能正确聚合。

翻 AI 爬虫日志才发现不对。GPTBot、ClaudeBot、PerplexityBot 这三类抓取里，ref 指向另一个语言版本的记录整月只有个位数，几乎没有一条英文页抓取是从中文页"顺着"过来的。也就是说，在 AI 爬虫眼里，这两个页面就是两份互不相干的内容，它各自建索引，各自引用，谁也不知道谁。

AI 引擎目前并不继承 Google 那套 hreflang 聚合逻辑，它只认自己抓到的 URL 和页面里声明的结构化数据。

小陈是负责日志这块的后端工程师，他的原话是："我以为 hreflang 挂上就完事了，AI 爬虫根本不看那个。"这句话后来成了我们这次改造的起点。

互认机制是怎么断的

这里得把 schema.org 的机制讲清楚。CreativeWork 类型上定义了一对互逆属性：

• workTranslation：挂在原文页上，语义是"有一个作品是本作品的翻译版"，指向翻译版；
• translationOfWork：挂在翻译页上，语义是"本作品翻译自哪个原作"，指向原文。

两个属性互为逆关系：A 页面的 workTranslation 指向 B，等价于 B 的 translationOfWork 指回 A。schema.org 官方建议成对声明，因为 AI 引擎做实体对齐时，看的是证据链是否闭合——单向声明只是弱信号，双向都声明了，两个页面才会被合并成同一个实体的两个语言表现。再配合 @id 固定组织实体、sameAs 挂外部权威档案，证据链才算完整。

我们改造前的状态是：这对属性压根没挂，中文页和英文页的 JSON-LD 里 publisher 也没有统一的 @id，sameAs 更是只在关于我们页面上出现过一次。三处信号全缺，AI 爬虫没有理由认为这是一家公司的同一份资料。

graph LR
  EN["英文版 Article<br/>/en/blog/2205"] -- "workTranslation" --> ZH["中文版 Article<br/>/blog/2205"]
  ZH -- "translationOfWork" --> EN
  ORG["Organization<br/>@id: /#org"] -. "sameAs 证据链" .-> EN
  ORG -. "sameAs 证据链" .-> ZH
  LINK["head hreflang en / zh"] -. "HTML 层辅助信号" .-> EN
  LINK -. "HTML 层辅助信号" .-> ZH

顺带把三个容易混淆的属性摆在一起对比，做 GEO 的人迟早都会遇到：

动手改造：三个动作，两天上线

6 月 10 日上线，改动分三层：JSON-LD 互挂、hreflang 补齐、内容口径对齐。工程量最大的是第一层，因为要动构建脚本；后两层半天搞定。

动作一，英文原文页挂 workTranslation。下面这段 JSON-LD 由构建脚本注入每个英文文章页，依赖是 slug 映射表（en 与 zh 的 URL 对应关系维护在构建配置里），环境是静态站点生成器，页面在服务端渲染时输出：

// 前置依赖：/en/blog/:slug 与 /blog/:slug 的映射表维护在构建配置里
// 环境：静态生成器在服务端渲染时注入 JSON-LD，改动后全量重建
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "url": "https://www.example.com/en/blog/2205-brass-fitting-tolerance",
  "inLanguage": "en",
  // 关键行：workTranslation 挂在原文页，指向中文翻译版
  "workTranslation": {
    "@type": "Article",
    "url": "https://www.example.com/blog/2205-huangtong-katao-jietou"
  },
  // 关键行：组织实体用固定 @id，给 AI 引擎一个可对齐的锚点
  "publisher": {
    "@type": "Organization",
    "@id": "https://www.example.com/#org",
    "name": "Example Auto Parts",
    // sameAs 挂权威外部档案，实体证据链更完整
    "sameAs": ["https://www.linkedin.com/company/example-autoparts"]
  }
}
</script>

动作二，中文翻译页挂反向声明。单向声明只是弱信号，两边都挂、指向彼此，实体对齐才会生效。这段由同一个渲染函数输出，只是属性名和指向反过来：

// 前置依赖：中文版模板与英文版共用同一个 JSON-LD 渲染函数
// 环境：inLanguage 写 zh，页面暂无地区定向需求，不写地区码
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "url": "https://www.example.com/blog/2205-huangtong-katao-jietou",
  "inLanguage": "zh",
  // 关键行：translationOfWork 挂在翻译页，指向英文原作
  "translationOfWork": {
    "@type": "Article",
    "url": "https://www.example.com/en/blog/2205-brass-fitting-tolerance"
  },
  // 关键行：publisher 的 @id 必须与英文页完全一致
  "publisher": {
    "@type": "Organization",
    "@id": "https://www.example.com/#org",
    "name": "Example Auto Parts"
  }
}
</script>

动作三，head 里的 hreflang 补齐校对。hreflang 对 AI 引用不是决定性信号，但它便宜，而且和 JSON-LD 里的 url 形成互相印证，没有理由不挂对：

<!-- 依赖：每个语言版本的 head 模板注入同一组 alternate 链接 -->
<!-- 环境：hreflang 与 JSON-LD 里的 url 必须逐字符一致，含协议与域名 -->
<link rel="alternate" hreflang="en" href="https://www.example.com/en/blog/2205-brass-fitting-tolerance" />
<!-- 简体中文写 zh 即可，别凭空造地区码 -->
<link rel="alternate" hreflang="zh" href="https://www.example.com/blog/2205-huangtong-katao-jietou" />
<!-- x-default 指向主语言版本，给未匹配语言的请求兜底 -->
<link rel="alternate" hreflang="x-default" href="https://www.example.com/en/blog/2205-brass-fitting-tolerance" />

内容层还有一件事：把英文参数表的口径改成和中文版逐行对应，单位、公差写法保持一致。英文内容外包负责人老金开始不太情愿，原话是："参数我一个字不动，你让我加一句'单位换算与中文版一致'我就加。"后来真就加了这一句。

flowchart TD
  A["AI 爬虫抓到中文产品页"] --> B{"页面带 workTranslation / translationOfWork 吗"}
  B -- "带" --> C["取互挂的英文版 URL 加入抓取队列"]
  C --> D["两个版本按同一实体合并"]
  D --> E["中文提问：主体引中文版<br/>参数缺口补引英文版并标注同源"]
  B -- "不带" --> F["按两份独立内容分别建索引"]
  F --> G["中文提问只引中文版<br/>英文参数被当成另一来源"]

60 天数据：改造前后对比

统计口径说明：改造前窗口取 4 月 26 日至 5 月 25 日，改造后窗口取 6 月 26 日至 7 月 25 日，中间留了一个月给 AI 爬虫重新抓取和更新索引。数据来自站内日志和结构化数据校验工具，AI 引用样本是每周人工抽检 60 条答案得到的。

爬虫日志是最直接的佐证。下面是 7 月 8 日的抓取片段（域名已脱敏，ref 是爬虫声明的来源页）：

# 7 月 8 日 GPTBot 抓取片段，域名已脱敏，ref 为爬虫声明的来源页
[GPTBot] GET /en/blog/2205-brass-fitting-tolerance ref=/blog/2205-huangtong-katao-jietou
# 上面这行的 ref 说明：爬虫是从中文版顺着互挂声明跳到英文版的
[GPTBot] GET /blog/2205-huangtong-katao-jietou ref=/en/blog/2205-brass-fitting-tolerance
# 5 月份同类日志里，ref 指向另一语言版本的记录整月只有个位数
# 7 月上旬，跨语言跳转抓取日均 40 条以上，占同类抓取的两成八
[PerplexityBot] GET /blog/2205-huangtong-katao-jietou ref=/en/blog/2205-brass-fitting-tolerance
# 这条 PerplexityBot 抓取同样来自英文版跳转，且中文版先被抓到

34% 不是什么惊人数字，但结构变了。中文提问时 AI 仍然优先引中文页，跨语言的那 34% 大多出现在中文页没写透的参数上——公差等级、材质牌号、认证编号，这些恰好是英文参数表更全的部分。引用顺序也从"两个陌生来源并排"变成了"同一来源的不同语言版本互相补充"，阿May 复盘时的原话："现在截图里两条引用是挨着的，客户不会再问'这俩什么关系'。"

踩过的坑，按代价从大到小

• 单向声明基本没用。第一版只给英文页挂了 workTranslation，中文页漏了反向声明，前两周跨语言跳转几乎没涨。6 月 12 日补上 translationOfWork，第二天日志里就有 ref 指向英文版的抓取记录了。
• 互挂的 url 必须是带域名的完整地址，而且能 200 访问。有个测试页用了相对路径，校验工具直接把它当失效实体丢了，日志里也看不到跳转。
• 内容差异太大时互挂救不了。中文 1400 字、英文 600 字的差距还在，AI 依旧各引各的主体内容，互挂对齐的是身份，不是内容覆盖度。想让它引英文版的参数，前提是中文版确实没写那个参数。
• sitemap 里两个语言版本都要收录。我们有个分类页只把中文版放进了 sitemap，英文版迟迟不被 AI 爬虫光顾，互挂声明形同虚设。

误区澄清与趋势预判

误区：把 hreflang 当多语言问题的万能解。它主要服务传统搜索的结果聚合，主流 AI 爬虫目前并不解析它的语义。做 GEO 的时候，真正让 AI 引擎认账的，是 JSON-LD 里成对的实体关系声明和稳定的 @id，hreflang 只能算辅助印证。

趋势判断：AI 引擎对站点自声明实体信号的依赖会越来越重，因为它们抓不起全网的链接图，只能靠页面自己把关系讲清楚。workTranslation 和 translationOfWork 这类属性的声明成本接近于零——改一次构建脚本，全站生效——对有多语言版本的内容站来说，属于早挂早受益的事。你们的双语站被 AI 引用时串过台吗？评论区可以聊聊各自的日志长什么样。

参考与延伸

• schema.org workTranslation 属性定义：https://schema.org/workTranslation
• schema.org translationOfWork 属性定义：https://schema.org/translationOfWork
• Google 搜索中心国际化文档（多语言与多地区页面规范）：https://developers.google.com/search/docs/specialty/international

多语言 SEO、workTranslation、translationOfWork、JSON-LD、GEO、AI 搜索、外贸独立站、hreflang