多语言版本各说各话，AI 只信了一半：workTranslation 与 translationOfWork 的 60 天引用数据

多语言版本各说各话AI 只信了一半workTranslation 与 translationOfWork 的 60 天引用数据适用读者给外贸独立站维护中英双语站的前端与 SEO 工程师负责让 AI 搜索引擎正确引用自家产品资料的技术负责人已经上了 JSON-LD但发现 AI 引用总是串台的人。TL;DR核心问题主流 AI 爬虫不认 hreflang把中英文两个版本当成两份独立内容引用时各说各话。解法在 JSON-LD 里成对互挂workTranslation/translationOfWork让 AI 引擎把两个版本合并成同一实体。改造成果跨语言引用占比从 12% 提升到 34%错配引用从 61% 降到 7%基本归零。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/xxxURL 一一对应。内容是两个团队各写各的中文版一个型号写 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 也没有统一的idsameAs 更是只在关于我们页面上出现过一次。三处信号全缺AI 爬虫没有理由认为这是一家公司的同一份资料。workTranslationtranslationOfWorksameAs 证据链sameAs 证据链HTML 层辅助信号HTML 层辅助信号英文版 Article/en/blog/2205中文版 Article/blog/2205Organizationid: /#orghead hreflang en / zh顺带把三个容易混淆的属性摆在一起对比做 GEO 的人迟早都会遇到属性声明位置语义我们见过的误用workTranslation原文页存在一个本作品的翻译版被当成相关文章随便互挂translationOfWork翻译页本作品翻译自哪个原文只挂单向原文页没有对应声明inLanguage每个语言版本本页正文的语言只写 zh 不写具体版本或干脆漏写动手改造三个动作两天上线6 月 10 日上线改动分三层JSON-LD 互挂、hreflang 补齐、内容口径对齐。工程量最大的是第一层因为要动构建脚本后两层半天搞定。动作一英文原文页挂 workTranslation。下面这段 JSON-LD 由构建脚本注入每个英文文章页依赖是 slug 映射表en 与 zh 的 URL 对应关系维护在构建配置里环境是静态站点生成器页面在服务端渲染时输出// 前置依赖/en/blog/:slug 与 /blog/:slug 的映射表维护在构建配置里// 环境静态生成器在服务端渲染时注入 JSON-LD改动后全量重建script typeapplication/ldjson{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 typeapplication/ldjson{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 必须逐字符一致含协议与域名 --linkrelalternatehreflangenhrefhttps://www.example.com/en/blog/2205-brass-fitting-tolerance/!-- 简体中文写 zh 即可别凭空造地区码 --linkrelalternatehreflangzhhrefhttps://www.example.com/blog/2205-huangtong-katao-jietou/!-- x-default 指向主语言版本给未匹配语言的请求兜底 --linkrelalternatehreflangx-defaulthrefhttps://www.example.com/en/blog/2205-brass-fitting-tolerance/内容层还有一件事把英文参数表的口径改成和中文版逐行对应单位、公差写法保持一致。英文内容外包负责人老金开始不太情愿原话是参数我一个字不动你让我加一句’单位换算与中文版一致’我就加。后来真就加了这一句。带不带AI 爬虫抓到中文产品页页面带 workTranslation / translationOfWork 吗取互挂的英文版 URL 加入抓取队列两个版本按同一实体合并中文提问主体引中文版参数缺口补引英文版并标注同源按两份独立内容分别建索引中文提问只引中文版英文参数被当成另一来源60 天数据改造前后对比统计口径说明改造前窗口取 4 月 26 日至 5 月 25 日改造后窗口取 6 月 26 日至 7 月 25 日中间留了一个月给 AI 爬虫重新抓取和更新索引。数据来自站内日志和结构化数据校验工具AI 引用样本是每周人工抽检 60 条答案得到的。指标改造前4/26–5/25改造后6/26–7/25变化跨语言引用占比12%34%22 个百分点错配引用占跨语言引用的比例61%7%基本消失结构化数据校验告警41 条3 条剩下 3 条是历史页面hreflang 校验错误12 处0 处清零AI 爬虫跨语言跳转抓取日均 2 条日均 47 条明显增加中文提问引用英文参数的条数周均 6 条周均 19 条约三倍爬虫日志是最直接的佐证。下面是 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 里成对的实体关系声明和稳定的idhreflang 只能算辅助印证。趋势判断AI 引擎对站点自声明实体信号的依赖会越来越重因为它们抓不起全网的链接图只能靠页面自己把关系讲清楚。workTranslation 和 translationOfWork 这类属性的声明成本接近于零——改一次构建脚本全站生效——对有多语言版本的内容站来说属于早挂早受益的事。你们的双语站被 AI 引用时串过台吗评论区可以聊聊各自的日志长什么样。对比方案hreflang 与 JSON-LD 互挂的适用场景两种方案不是二选一而是按目标分层。下面这张表把差异摆开方便你按自己的处境对号入座维度hreflangJSON-LD 互挂workTranslation / translationOfWork传统搜索强。Google 用它聚合多语言版本避免重复内容判定弱。传统爬虫基本不读这对属性对排名无直接影响AI 引用弱。主流 AI 爬虫目前不解析 hreflang 语义强。AI 引擎靠成对声明做实体对齐把两个版本合并成同一来源实施成本低。head 模板里加一组 alternate 链接即可中。要动构建脚本维护 slug 映射表两边成对声明维护难度低。URL 不变就基本不用管中。新增语言版本时容易漏挂反向声明需校验工具兜底建议很直接如果只做传统 SEO让 Google 正确聚合多语言页面挂 hreflang 就够了成本最低、收益最稳。但如果你需要 AI 引用时统一口径——让 AI 把中文版和英文版当成同一份资料、跨语言互相补充而不是各说各话——那就必须在 hreflang 之外加上 JSON-LD 互挂。两者叠加才是完整方案hreflang 管传统搜索的聚合JSON-LD 互挂管 AI 引擎的实体对齐各司其职互不替代。参考与延伸schema.org workTranslation 属性定义https://schema.org/workTranslationschema.org translationOfWork 属性定义https://schema.org/translationOfWorkGoogle 搜索中心国际化文档多语言与多地区页面规范https://developers.google.com/search/docs/specialty/international多语言 SEO、workTranslation、translationOfWork、JSON-LD、GEO、AI 搜索、外贸独立站、hreflang