乌克兰语SEO要面对的是两种语言都看得懂的用户，而你的站只能有一套URL

摘要：同一个人上午用俄语搜、下午读乌克兰语页面，这在乌克兰是常态，而你的站只能给一个URL一种语言。这篇讲按搜索词语言而不是按用户国籍分配内容，附上四个互不重叠字母的自动识别法、键盘布局错位造出的整类错拼，以及那个能把促销排期整整推错一周的假朋友。

接手办公家具那个项目的时候，我先要的不是关键词表，是站内搜索日志。

日志拉出来一看，很有意思：同一个会话里，用户先用一种语言搜，翻了两页没找到，换另一种语言再搜一遍。

不是偶发，是相当一部分会话都这样。

这就是乌克兰市场跟其他双语市场最不一样的地方——不是两拨人各用各的语言，是同一拨人两种语言都用，而且在一次购买决策里来回切。

这个前提一旦确认，内容该怎么分就完全变了。

这篇跟俄语那篇讲的不是同一件事

先把分工写死，免得读到一半觉得重复。

俄语那一篇讲的是俄语这门语言本身：六个格怎么变、一个名词能变出多少种搜索写法、工具口径为什么会把它们合并成一个数字。那是单一语言的词法问题。

本篇一个词形都不重讲。

本篇讲的是市场层的问题：一个国家里两套语言同时在用，内容资产该怎么分配、按什么口径分、哪些能共用哪些不能。

换句话说，那篇回答怎么把一个俄语词的所有写法接住，这篇回答这个页面到底该用哪种语言写。

这样切分不是为了凑两篇，是因为这两件事的决策者经常不是同一拨人：词形覆盖归做关键词的，内容分配归定预算的。

如果你现在要做的是选词和覆盖词形，先去看那一篇；要做的是决定这个页面写哪种语言，接着往下读。

为什么不能按用户国籍分配内容？

因为国籍跟他此刻用哪种语言搜索没有稳定关系。

很多站的做法是按访问来源的国家自动切换语言，来自乌克兰就给乌克兰语。这套逻辑在单语市场没问题，在这里会持续错。

用户刚用俄语搜到了你，点进来被自动切成乌克兰语，他刚才搜的那个词在页面上一个都找不到。

正确的口径只有一个：按他用来找到你的那个查询是哪种语言，就给他哪种语言的页面。

这个口径实施起来比按国籍麻烦，但它是唯一跟用户真实意图对齐的。

退一步说，就算自动切换的判断是对的，也应该让用户能一键切回去，并且记住他的选择。强制跳转在这个市场引起的反感格外强烈。

还有一个常被忽略的场景：从社交平台和聚合站进来的流量，来源国家判断本来就不准，按国籍切换在这批流量上错得更离谱。

这条口径定下来之后还有个附带收益：你的关键词表、内链规则、站内搜索权重终于有了同一个依据，不会各按各的来。

那两套内容要不要都做全？

这就回到近亲市场那套三档判据了，只是这次两个市场在同一个国家里。

第一档可以整块共用：商品图、尺寸表、参数数值、结构化数据里的数字字段、支付与配送的技术配置。

第二档只换词不动结构：属性名与属性值、筛选器标签、行业术语表。

第三档必须各写一份：标题、元描述、正文、促销文案、客服话术、常见问题。

跟其他近亲市场不同的是，这里第一档的比重更大——因为是同一个国家，物流、支付、法务、货币全都一样，那批最容易分叉的非语言字段这次不用分。

所以在这个市场，不要一上来就问要不要做两套，先把第一档那批共用资产的边界划出来，剩下的工作量会比预想的小。

划边界的时候建议直接把资产清单列出来，一行一项标上档位。这张表拉完，预算怎么排基本就明确了，比开三次会有用。

两套内容会不会互相蚕食？

会，而且比跨国的近亲语言更容易。

两个版本面对的是同一个国家、同一批用户、同一个搜索引擎的同一个地区索引。它们真的在同一个池子里竞争。

典型症状是同一个商品的两个语言版本轮流出现在结果里，排名都不高不低地卡在中间。

处理这件事的手段在架构层——语言与地区标注、规范化、内部链接的指向。国际化SEO那一篇讲了这套标注怎么落地，这里不重复。

语言层能做的是把两个版本的用词分叉做足，让它们在词面上真的不像，减少检索侧混淆的机会。

判断有没有发生的方法是抽一批核心词，看结果页里是不是同一个商品的两个语言版本轮番出现，出现两次以上就说明分叉不够。

还有一个容易忽略的诱因：两个版本的内链如果互相穿插，会把权重在两套之间来回倒腾，反而加剧了竞争。

真发生了也别慌，多数情况靠加大用词分叉加上把标注做对就能缓解，很少需要下架其中一个版本。

乌克兰语有俄语没有的第七个格，这个格在哪儿看得见？

在称呼里。

乌克兰语保留了一个专门用于呼唤对方的格，现代标准俄语里这个格已经基本消失，只剩几个固定说法。

所以给乌克兰语用户发邮件、在客服窗口叫名字、在页面上写一句您好加姓名的时候，那个名字要变形，不能直接用词典形态。

直接用原形不会让人看不懂，但会显得生硬，像机器发的。

乌克兰语在线词典给出的词条会列出各个格的形态，这个格是明确单列的，做模板时可以对着查。

这个格还有个特点：它只用于称呼，不出现在搜索查询里。所以它影响的是文案和邮件，不影响关键词表。

还有一处会用到：客服对话的开场白。人工客服知道该怎么说，自动回复的模板得有人专门去改。

呼格该怎么在系统里落地？

最省事的办法是绕开它。

把带称呼的模板改写成不需要变形的句式：用问候语加一句话，把名字放在句子的其他位置，或者干脆不用名字。

如果一定要用名字打招呼，那就得建一张名字到呼格形态的对照表，覆盖最常见的那几百个名字，剩下的走原形兜底。

这件事的投入产出比取决于你的邮件量。邮件是主要触达渠道的，值得做；只在客服窗口用一下的，绕开就行。

顺带说一句，这也是俄语篇那套格变化知识在本篇唯一有交集的地方——但方向相反：那边讲的是搜索词的变形，这边讲的是称呼的变形。

如果决定要做对照表，记得把外国名字也考虑进去。跨境业务里非本地名字不少，这批名字不适用变形规则，要单独走原形分支。

判断值不值得做，我一般看一个数：带称呼的邮件打开率跟不带称呼的差多少。差得不明显就别折腾。

四个互不重叠的字母怎么用来做语言识别？

这是本篇最实用的一个工程点。

乌克兰语字母表里有四个字母是俄语没有的，俄语字母表里也有四个是乌克兰语没有的。八个字母，两两互斥。

所以判断一段西里尔文本是哪种语言，不需要上语言检测模型，扫一遍看命中哪一组就行。

这个方法的准确率在实际文本上高得惊人，因为这几个字母都是高频字母，一段正常长度的文本几乎不可能一个都不出现。

它比读页面上的语言标注可靠得多——标注是人填的，会填错；字母是文本自带的，不会撒谎。

实现上就是两个字符集合加一次遍历，几行代码的事，却能替掉一个动辄几十兆的语言检测模型。

要注意的是这套判据只区分这两门语言，遇到第三种西里尔语言会误判，所以用之前先确认你的数据源里只有这两种。

这个识别法能用在哪些地方？

四个地方我都用过。

一是查询日志的语言归类，这是最主要的用途，直接决定你的关键词表怎么分。

二是用户生成内容的自动分区，评价和问答按语言归到对应版本下。

三是内容审核，抓出那些声称是乌克兰语版本、实际正文还是俄语的页面。这类页面在迁移项目里成批出现。

四是外链分析，判断一个引用你的页面是哪种语言的受众，比看域名后缀准。

还有第五个用途：给内容团队做交付验收，扫一遍就知道这批稿子有没有混进另一种语言的句子，比人工抽查快得多。

这几个用途里价值最高的是第一个。关键词表分不干净，后面所有的排期和评估都建立在一个混合口径上。

把这段扫描代码封成一个内部小工具，让内容和运营都能自己跑，比每次找技术要数据快得多。

短文本上这个方法会不会失效？

会，这是它唯一的短板。

短查询里可能一个特征字母都没有，比如两三个字符的品牌词或者型号。这时候扫描给不出结论。

兜底办法是看上下文：同一会话里的其他查询、来源页面的语言、用户之前的行为。

还有一类无法判定的情况是两种语言里拼写完全相同的词——这类词确实存在，而且往往是高频词。

对这批词的处理是不判定，把它们标为通用，在两个版本里都做。反正它们本来就两边通用。

实践中一个可用的阈值是文本长度超过二十个字符时结论可信，短于这个数就交给上下文判断，别硬下结论。

通用词这一批还值得单独统计一下规模。如果占比很高，说明两个版本的内容天然会有一部分重叠，蚕食的风险要提前防。

键盘布局错位会造出哪些错拼？

这是我在这个市场见过的最有意思的一类查询，也几乎没人写过。

乌克兰语键盘和俄语键盘的布局不完全一样。乌克兰语特有的那几个字母，占的正是俄语键盘上另外几个字母的位置。

用户如果没切换键盘布局，或者切了但肌肉记忆还在，打出来的就是同一个位置上的另一个字母。

结果是一整类结构性的错拼查询：词是对的，就那么一两个字母系统性地写成了另一个。

这类错拼不是随机的打字错误，是规律性的，可以枚举出来。把它们收进站内搜索的同义词表，能直接接住一批本来会零结果的查询。

采集这批错拼的最好来源是站内搜索的零结果日志。零结果里排前面的那些查询，很大一部分就是这类系统性错拼。

枚举的方式是把两套键盘布局的字符位置做个映射表，然后对高频词批量生成错拼形态，人工核一遍留下合理的。

这类错拼要不要写进页面？

不要，一个都不要。

页面上出现错拼形态，损害的是专业度，而且这些形态在检索侧本来就会被纠错逻辑处理掉，写了也没有额外收益。

正确的位置是站内搜索的同义词表、自动补全的候选映射、以及客服机器人的意图识别。

这三处是用户输入直接落地的地方，容错做在这里最划算。

页面负责规范，系统负责容错，两件事别混在一起做。

同义词表也要定期回顾。输入习惯会变，两三年前高频的错拼形态，今天可能已经没人打了，留着只是噪声。

有一个例外值得说明：如果某个错拼形态已经流行到成了事实上的通用写法，那它就不再是错拼，可以正常使用。

那个能把促销排期推错一周的假朋友是什么？

是表示星期日的那个词。

在乌克兰语里，这个词指的是一周里的某一天，也就是星期日。在俄语里，几乎相同的一个词指的是整整一周。

所以一句本周特惠，如果按俄语的语感写、按乌克兰语的语感读，说的可能是这个星期日限定。

反过来更糟：你想说的是星期日一天的活动，另一边的用户理解成整周有效，第二天来找你要优惠。

另一个高频假朋友是表示时间的那个词，在两门语言里指的分别是时间和小时，配送时效的文案里天天要用到它。

所以活动文案里凡是涉及时间范围的，一律写明确的日期，别用相对说法。这条规则在这个市场是硬要求，不是建议。

这类词还有个共同特点：它们太常用了，常用到审校时眼睛会直接滑过去，必须靠清单强制逐条核。

还有哪些假朋友值得单独核？

有一个词特别值得警惕：它在一边指家庭，在另一边指祖国。

这个词在家居、家电、亲子类目的品牌文案里出现频率很高，用错了不只是意思偏差，语气也整个变了。

还有一批是城市与地名相关的词，两门语言的说法不同，而且这批词在本地SEO里权重很高。

核假朋友的方法跟其他近亲语言一样：两边高频词取交集，逐条查权威词典，对不上的交母语者判定。

区别在于这里的核对优先级要按出现位置排——按钮、价格区、配送说明、活动规则，这四处先核。

核对时建议把结果按严重程度分三级：会造成误解的、只是不自然的、纯粹用词偏好。三级的处理优先级完全不同。

还有一批不算严格意义的假朋友，但语体色彩不同——同一个词在一边是中性的，在另一边偏正式或者偏陈旧，用在营销文案里会显得别扭。

月份名两套完全不同的词，会在哪儿出事？

在日期本地化上，而且是静默出错。

俄语的月份名是从拉丁语借来的，跟大多数欧洲语言同源，看起来眼熟。乌克兰语用的是本土的斯拉夫月份名，跟拉丁名毫无关系。

问题出在很多日期库对乌克兰语的支持不如俄语完整。找不到乌克兰语的数据时，有些实现会静默回落到俄语。

页面上于是出现了俄语月份名，混在一段乌克兰语文案里。

用户看得懂，但一眼就知道这站没认真做。而且这种错误不会报任何异常，测试环境也未必能发现。

自查方法很直接：把页面切到乌克兰语版本，找一个显示日期的位置，看月份名是不是本土形态。三十秒的事，很多站从来没做过。

除了月份和星期，季度、节假日名称、以及一些时间副词也存在同类风险，值得一并排查。

日期格式和星期起点两边一样吗？

格式一样，起点也一样，这一块反而省心。

两边都是日在前月在后，一周从周一开始。这跟一些邻近市场不同，值得在配置时确认一次。

要注意的是星期名的词本身两边不同，跟月份名一个道理，同样存在回落风险。

还有一个细节：日期里的月份用数字还是用词，两边的正式程度感觉不太一样。

商品页上用数字最安全，营销文案里用词更自然，这一条两边一致。

还有一个跟时间有关的细节：营业时间和客服时段的表述方式两边略有不同，这类文案属于第三档，各写各的。

时区只有一个，这一点省事。但如果你的服务器在别处，记得把渲染时区显式指定，别让它跟着服务器走。

地址表单和邮编要不要分两套？

字段结构一套就够，字段名和选项值要两套。

因为是同一个国家，行政层级、邮编位数、地址书写顺序都是一样的，表单结构不用改。

但每一级行政区划的名称在两门语言里写法不同，街道名也常常有两个版本。

这批地名数据是这个市场里工作量最大的一块，因为条目多、更新频繁，而且错了直接影响物流。

我的建议是把地名当成独立的数据资产维护，两列并排存，别塞在翻译文件里。

地名数据还有一个隐藏成本：它会变。行政区划调整、街道更名都会发生，这张表需要定期同步，不能一次导入就不管了。

还有一个实务建议：地址字段的自动补全一定要同时接受两种语言的输入，用户输入习惯跟他当前看到的界面语言未必一致。

用哪个字母的域名后缀？

这个国家有拉丁字母的国别后缀，也有一个西里尔字母的后缀。

西里尔那个已经进了根区，IANA根区数据库里能查到它的委派记录，写进浏览器时用的是Punycode形式。

拉丁字母的那个是绝对主流，几乎所有商业站点都用它。

西里尔后缀的定位跟其他本地字符域名一样——适合做品牌保护性注册，不适合当主站入口。键盘切换成本和链接复制时的还原率是主要障碍。

如果注册了，记得配好跳转并统一规范形态，别让同一个页面在两套域名下都能打开。

还有一个现实考虑：西里尔域名在一些第三方平台的链接识别和跳转处理上仍然不够稳，投放和联盟场景里尤其明显。

总的判断是：主站用拉丁后缀，西里尔那个注册下来放着。这个结论在多数非拉丁字母市场都成立，这里也不例外。

转写成拉丁字母时，两边用的不是同一套规则

这一点在处理URL和人名时会撞上。

乌克兰有官方的拉丁转写规范，跟通行的俄语转写体系规则不同。同一个地名，按两套规则转出来的拉丁形态可能差好几个字母。

如果你的URL用拉丁转写生成，选哪一套会直接影响这批URL的形态。

更麻烦的是历史遗留：早期做的页面可能用的是俄语那套转写，后来的用了乌克兰那套，同一个站里两种形态并存。

统一到一套，把另一套做跳转。这活越早做越便宜。

统一之前先盘一遍现有URL里哪一套占多数，向多数那边统一，需要做跳转的页面最少。这个决定五分钟能做完，能省下一半的跳转配置。

人名的转写还有一层麻烦：证件上的拼法可能跟任何一套规范都不一致，涉及实名或者物流对接时以证件为准。

同形词与视觉混淆是个真问题吗？

是，而且不只影响安全，也影响你的数据准确性。

西里尔字母里有一批字形跟拉丁字母几乎一样，肉眼分不出来。用户复制粘贴、输入法自动纠正、从不同来源导入数据，都可能混进来。

结果是你的关键词表里同一个词有两份，字符不同但看起来一模一样，怎么找都找不出区别。

Unicode的安全机制报告里有一份完整的易混字符对照表，可以直接拿来做检测。

处理办法是在数据入口处做一次规范化，把混进来的拉丁字母替换成对应的西里尔字母，或者反过来，看你的主语言是哪一个。

检测的时机很关键：要放在数据入库之前，不是查询的时候临时处理。入库时清干净，后面所有环节都省心。

一个快速自查：把关键词表按去掉字母差异之后的形态分组，同一组里出现两条以上就说明有混淆字符混进来了。

词干还原两门语言能不能共用一套？

不能，虽然它们的形态变化系统很像。

两门语言的词尾变化表有相当程度的重合，但不完全一样，而且乌克兰语的辅音交替规则更多一些。

用俄语的词干算法去处理乌克兰语文本，大部分词能对，剩下那部分错得没有规律，很难排查。波兰语那篇讲过屈折语的词形覆盖该怎么估工作量，这里的量级跟它是一个档次的。

Snowball的俄语词干算法定义了完整的词尾剥离顺序，可以看出这套规则的针对性有多强。

乌克兰语要另找方案。实在没有现成的，宁可只做简单的词尾归一，也别拿俄语那套硬套。

退一步的方案是只处理最高频的那几十个词尾，覆盖八成左右的情况，剩下的留给精确匹配。不完美，但比错得没规律强。

判断词干处理有没有做到位，最直接的指标还是分语言看的站内搜索零结果率，这个数字骗不了人。

2014年前后的变化对内容策略意味着什么？

意味着一个变量：语言使用的自我申报比例和实际搜索行为，这两个数字开始出现明显的分离。

调查问卷里说自己主要用哪种语言，跟他在搜索框里实际打哪种语言，本来就不完全一致。这几年这个差距在拉大。

对做内容的人来说，结论很简单：别用人口调查数据来分配内容预算，用你自己的查询日志。

调查数据反映的是态度，日志反映的是行为。花钱要跟着行为走。

而且行为的迁移是渐进的——界面语言、键盘布局、书签、习惯用语，这些不会一夜之间切换。趋势可以观察，但不能替代当期数据。

需要提醒的是，观察这类变化时别只看总量，要按品类看。不同品类的用户构成不一样，语言比例的差异有时比想象中大。

还有一点要说清楚：这里讨论的是内容资源怎么分配，不是判断哪种语言该用或者不该用。这两件事完全不同。

这个趋势该怎么在排期上体现？

不要一次性押注，按季度调比例。

具体做法是每个季度重新拉一次查询日志的语言分布，用这个比例来决定下个季度新内容的语言配比。

存量内容不动，只调增量。这样既跟得上变化，又不会为了追一个趋势把已有资产废掉。

我在办公家具那个项目上用的就是这套，两年下来两个语言版本的比重变化很明显，但没有任何一次是靠拍脑袋决定的。

这也是这类市场唯一稳妥的做法——用数据跟随，不用判断预测。

存量内容也不是完全不动，值得做的是给高流量的老页面补一个另一种语言的版本，成本低而且见效快。

按季度调这个节奏也别太死板，遇到大促或者品类结构调整，中途重新拉一次数据是合理的。

这和其他近亲语言市场的分工有什么不同？

最大的不同是这里两个市场在同一个国家里。

捷克语与斯洛伐克语那一对是两个国家，货币、法律、物流、域名全都分开，语言只是分叉里的一项。

这里不一样：非语言的东西全部共用，分叉百分之百落在语言上。

这让第一档的可复用面比任何一对跨国近亲语言都大，同时也让第三档的重写变得更纯粹——你只需要换语言，不需要顺带改配送、改货币、改条款。

算总账的话，这个市场做两套内容的边际成本，比跨国的近亲市场低不少。这是个好消息，值得说清楚。

另一个不同是这里的用户会主动切换语言，跨国近亲市场的用户不会——他不会为了买个东西去看邻国站点。

所以在做资源评估时，别直接套用跨国近亲市场的经验数字，那套数字里有一大块是非语言分叉的成本。

那要不要顺手把这套内容卖给其他俄语市场？

这是个诱人但要慎重的想法。

俄语在若干个国家都有使用者，从纯语言角度看内容确实能读。

但这些市场之间的货币、物流、法务、支付方式全都不同，属于第一档里那些平时最好复用的字段，在这里反而全部分叉。

所以这不是语言层的决策，是市场准入的决策，要按市场逐个算账。

语言层唯一要提醒的是：不同国家的俄语在词汇上也有本地差异，尤其在日常用品的叫法上，别默认一套通吃。

真要做的话，把这套内容当成起点而不是成品：结构和骨架能复用，词汇和本地信息全部重来一遍。

一个可操作的先后顺序是：先把本国这两套做扎实，再拿其中一套去试第二个市场，别三线同时铺开。

两个版本的内链要不要互相链？

不要交叉链，各成一张网。

让乌克兰语页面链乌克兰语页面，俄语页面链俄语页面。交叉的链接会把用户从他刚选定的语言里拽出去。

唯一的例外是语言切换器本身，那是显式的用户选择，应该做，而且要做得明显。

切换器的选项名要用目标语言自己的写法，别用英文或者国旗图标。国旗在这个市场尤其不合适，因为语言和国家并不是一一对应的。

这条不只是政治敏感度的问题，也是准确性问题——用一面旗代表一门语言，逻辑上本来就不成立。

切换器的位置也有讲究，放在页头显眼处比塞进页脚有效得多。这个市场的用户是真的会用它。

还有一处要注意：面包屑和分页导航也算内链，模板里如果写死了某一种语言的路径，另一个版本会静默串到对面去。

锚文本在两套内容里要不要各写一份？

要，理由跟其他屈折语一样，但这里多一层。

两门语言的名词都会随格变形，锚文本落在句子里要用对应的形态，不能用词典原形硬塞。

多出来的那一层是：同一个概念在两门语言里可能是完全不同的词，不只是形态不同。

所以内链词表要按语言各存一份，两份表的键都对不上，不能靠一份表加变形规则生成。

这跟同一门语言的两个地区变体是完全不同的工作量，规划时别按后者估。

自动加内链的规则也要按语言各配一套，同一条规则跑两个版本，另一边不是漏链就是链错。

维护上把两份词表放同一张表的两列里，改的时候同时看得见，比拆成两个文件靠谱。

站内搜索该怎么设计？

一个索引还是两个索引，这是要先定的。

我的建议是一个索引、按语言打标签，检索时按当前版本的语言优先，但不完全排除另一种语言的结果。

理由回到开头那个观察：用户会在两种语言之间切换。完全隔离的话，他用另一种语言搜自己看过的商品会搜不到。

排序上给当前语言更高的权重，另一种语言的结果排在后面并标注出来，是个平衡的方案。

零结果的时候更要放开——宁可给一个另一种语言的结果，也别给一个空页面。

另一种语言的结果要显式标注出来，别混在一起不说明。用户看到标注会理解，看不到标注只会觉得结果乱。

还有一个细节：搜索结果页本身的标题和提示文案，要跟当前版本的语言一致，别用一套通用的模板对付两边。

用户评价能不能两个版本共用？

数字共用，文字按语言分区，跟其他双语市场的处理一致。

但这里有个额外的好处：因为是同一个国家，评价里提到的配送时效、客服体验、包装状态全都适用，不存在跨市场失真的问题。

所以文字部分虽然按语言分区展示，但两边的可信度是一样的，不需要额外说明。

可以在每条评价上标出它的原始语言，让用户自己判断要不要看。

这比强行翻译评价好——翻译过的评价读起来就不像真人写的，反而降低信任。

评价的筛选器里可以加一个按语言过滤的选项，让偏好某一种语言的用户自己收窄。成本很低，体验提升明显。

要避免的一个做法是把评价机器翻译之后当原文展示，读起来就不像真人写的，反而把好评的说服力削掉一半。

结构化数据里哪些字段要分开？

语言字段和文本字段分开，其余全部共用。

价格、货币、可用性、配送区域这些在跨国市场里必须分开的字段，在这里可以放心共用，因为是同一个国家。

商品名称和描述跟着正文走，正文分了这里自然也分。

评价汇总的数字字段共用，这一点跟前面评价的处理保持一致。

整体看，这个市场的结构化数据是所有双语场景里最省事的一种，别把它做复杂了。

唯一要多留意的是语言字段本身别写错，这个字段错了，前面所有的分叉工作在检索侧都白做。

还有一条实务提醒：两个版本的标记要各自校验一遍，别只验主语言那一套就当全站都对。

母语审校该找什么样的人？

找在当地生活、两种语言都在用的人，而不是只用其中一种的人。

因为你要他判断的不只是这句话对不对，还有这句话放在这个语言版本里合不合适、会不会显得生硬或者过时。

这种判断需要对两边都有语感的人才能做。

审校清单里要专门列一条：检查有没有另一种语言的残留。迁移和复用过程中，总会有几个词漏掉。

用前面那个字母扫描法可以自动抓一遍，剩下的靠人眼。工具先跑，人再看，顺序别反。

预算允许的话，两个语言版本各配一个主审，再让他们互相看一遍对方的稿子，能捞出不少单向审校发现不了的问题。

如果只能找到单语背景的审校，那就明确告诉他只看自己那一套，别让他去判断另一边的内容合不合适。

验收看哪几个数字？

四个。

第一，两个语言版本的查询覆盖率，也就是各自接住了多少查询日志里的对应语言查询。

第二，站内搜索的零结果率，分语言看，能反映词干还原和同义词表做得够不够。

第三，语言残留页面的数量，用字母扫描法统计，目标是零。

第四，两个版本互相蚕食的程度，看同一商品的两个版本是否在同一批查询上竞争。这个数字下降，说明分叉做到位了。

这四个数字建议按月出一次，做成一张固定的表。趋势比单次的绝对值更有价值，尤其是第四个。

第三个数字是唯一应该硬性归零的，其他三个都是趋势指标，看方向不看绝对值。

还有一个可选项：分语言看落地页的跳出率，如果某一侧明显偏高，多半是语言分配的口径出了问题。

品牌名在两门语言里要不要用同一个写法？

如果品牌名是拉丁字母的，两边照搬，不用动。

麻烦的是做了西里尔转写的品牌名。两门语言的音系有差异，同一个外语名字按两边的习惯转写出来，可能差一到两个字母。

这时候你有两个选择：统一用一种转写，或者两边各用各的。

我的建议是统一用一种，并且在两个版本的页面上都同时出现拉丁原名。品牌名分裂成两个形态的代价，比稍微有点不自然的代价大得多。

但要把另一种转写形态收进站内搜索的同义词表，用户会用他习惯的那种写法来搜。

决定之前先查一下市场上现有的提及形态，如果已经有一种转写形成了事实标准，跟着它走比自己重新定一套省事。

图片的文件名和替代文本怎么处理？

文件名用拉丁转写并且全站统一一套规则，替代文本按语言各写一份。

文件名这块的坑前面提过：两套转写规范并存会让同一个概念的图片路径长得不一样，检索和管理都受影响。

替代文本必须分开，因为它是给用户和图片检索用的，得跟页面语言一致。

这里有个偷懒但有效的做法：图片本身共用一份，只在数据库里给替代文本存两个字段。存储成本没变，覆盖面翻倍。

顺带提醒，替代文本里的地名也要用对应语言的写法，这是最容易漏的一处。

批量补替代文本的时候别用模板句式套，那样生成出来的文本高度雷同，对图片检索基本没有帮助。

两个版本的标题和描述该按同样的长度写吗？

长度策略可以一样，但实际写出来的长度会不一样。

两门语言表达同样的意思，词长和句子结构有细微差别，硬套同一个字符上限，总有一边会写得局促。

更实际的做法是定信息点数量而不是定字符数：这条标题必须包含品类、关键属性、品牌，三样都进去，长度自然落在合理区间。

然后各自渲染出来看一眼，超了的再压。

把两边都按同一个数字卡死，是我见过最常见也最没必要的一种自我限制。

实际操作时把两个版本的标题并排放在一张表里写，一眼能看出哪一条明显长出一截，比各写各的容易控制。

产品参数的单位与缩写两边一致吗？

国际单位的符号一致，本土的缩写习惯不完全一致。

尺寸、重量、功率这些用国际符号写就没问题，两边通用。

但一些行业内的简写、包装规格的表述、以及数量单位的口语说法，两门语言各有各的习惯。

办公家具这个类目里，板材厚度、承重、可调节范围的表述方式，我们最后是两边各写了一份对照表才理顺的。

这批内容属于第二档，只换词不动结构，但条目数比想象中多，得留出时间。

这批对照表最好由懂这个行业的母语者来做，纯语言背景的译者在专业缩写上经常给不出准确答案。

关键词工具的数据为什么必须分语言看？

因为工具的地区维度和语言维度经常是混在一起的。

你在工具里选了这个国家，拿到的是这个国家所有查询的合计，里面两种语言的查询混在一起。

如果两门语言里某个概念用的是同一个词，这个词的量看起来会很大；如果是不同的词，各自的量看起来又都不大。

两种情况都会误导你的优先级判断。

正确做法是先用字母扫描法把词表按语言分开，分别排序，再决定各自的投入。合在一起排的那张表，看看就好，别当依据。

还有一个数据源值得用：自家的站内搜索日志。它天然带着语言归属，而且反映的是已经到站用户的真实说法。

历史内容迁移最容易出什么错？

最容易出的是语言残留：页面标注成一种语言，正文里还混着另一种语言的段落。

这在批量迁移里几乎必然发生，尤其是当原站只有一种语言、新站要拆成两套的时候。

第二容易出的是URL转写规则不统一，前面提过，两套转写并存会留下一堆需要跳转的旧路径。

第三是内链指向错版本：乌克兰语页面里的链接指到俄语页面上，用户点一下语言就换了。

这三样都能用脚本扫出来。迁移完先跑一遍扫描，别等用户来告诉你。

迁移后的第一周建议每天扫一次，问题通常集中在头几天暴露，过了这段就趋于稳定。

客服和邮件模板要不要做两套？

要，而且这是最容易被漏掉的一块，因为它不在网站上。

下单确认、发货通知、退换货说明、催付提醒，这些模板发出去的量比多数落地页的访问量还大。

它们通常由技术同事在后台配置，跟内容团队隔着一层，很容易在做双语规划时被整个忘掉。

更麻烦的是模板里往往嵌着变量：姓名、订单号、日期、金额。姓名要用呼格，日期要用对应语言的月份名，两个坑正好都在这里。

我的建议是把邮件模板跟落地页放在同一份内容清单里，一起排期。它们本来就是同一批文案。

一个省事的验收办法：给自己下一单，把整条链路的邮件全收一遍，逐封看语言对不对、变量渲染对不对。

用户该怎么知道有另一种语言的版本？

靠切换器，但切换器要放对地方、写对文字。

放在页头显眼处，不要塞进页脚。这个市场的用户是真的会用它，藏起来等于没有。

选项名用目标语言自己的写法，别用英文，更别用国旗图标——语言和国家在这里不是一一对应的，用旗子表示语言逻辑上就不成立。

切换之后要记住用户的选择，下次直接给他选定的那一套，别每次都重新判断一遍。

还有一条：切换语言时应该停在当前这个页面的对应版本上，而不是甩回首页。甩回首页是最让人恼火的实现方式，可惜相当常见。

如果做不到页面级对应，至少要落到同一个品类页上，别让用户从商品页一步跳回首页重新找。

引擎那半边的事，本篇不重复讲

这个市场用哪个搜索引擎、各家的份额怎么变、投放侧怎么配比，这些属于引擎层，站内已经有专门的文章讲。

域名结构、语言与地区标注怎么落地，属于架构层，前面已经用一句话加内链交出去了。

本篇只回答一件事：乌克兰语和俄语这一对语言在同一个市场里同时存在，给内容资产的分配带来了哪些别处没有的约束。

判据还是那一条——把语种换成英语就不成立的，才归这里。

按这条标准，呼格、四个互斥字母、键盘布局错拼、月份名回落、转写规则分叉全部合格；这个市场的物流成本和支付习惯就不合格，那是另一篇的事。

把边界写明白，读者才知道剩下那半边该去哪儿找，也省得在一篇文章里什么都提一句、什么都不讲透。

按这条边界，本篇讲完的东西换成英语市场一条都不成立，这就是它该待在语言层的理由。

常见问题解答

内容到底该按用户国籍分配还是按查询语言分配？

按查询语言。国籍跟用户此刻用哪种语言搜索没有稳定关系，很多站按访问来源国家自动切语言，结果是用户刚用一种语言搜到你，点进来被切成另一种，他刚搜的那个词在页面上一个都找不到。正确口径是他用来找到你的那个查询是哪种语言，就给他哪种语言的页面。实施起来比按国籍麻烦，但这是唯一跟真实意图对齐的口径。退一步说，就算自动判断是对的，也必须让用户能一键切回并记住选择——强制跳转在这个市场引起的反感格外强烈。这条口径确定之后，关键词表、内链规则、站内搜索的语言权重才有统一的依据。

那四个互不重叠的字母具体怎么用？

乌克兰语字母表里有四个字母是俄语没有的，俄语里也有四个是乌克兰语没有的，八个字母两两互斥。判断一段西里尔文本是哪种语言，扫一遍看命中哪一组就行，不需要语言检测模型。这几个都是高频字母，正常长度的文本几乎不可能一个都不出现，所以准确率很高。它比读页面上的语言标注可靠——标注是人填的会填错，字母是文本自带的不会撒谎。实现上就是两个字符集合加一次遍历，几行代码替掉一个动辄几十兆的语言检测模型。可用的阈值是文本超过二十个字符时结论可信，更短的交给上下文——同会话的其他查询、来源页面语言、历史行为。

键盘布局造成的错拼要不要写进页面？

一个都不要。页面上出现错拼形态会损害专业度，而这些形态在检索侧本来就会被纠错逻辑处理掉，写了没有额外收益。正确位置是站内搜索的同义词表、自动补全的候选映射、客服机器人的意图识别，这三处是用户输入直接落地的地方，容错做在这里最划算。页面负责规范，系统负责容错，两件事别混在一起做。采集这批错拼最好的来源是站内搜索的零结果日志，排在前面的那些查询很大一部分就是这类系统性错拼。同义词表还要定期回顾，输入习惯会变，两三年前高频的形态今天可能只剩噪声。

那个星期日与整周的假朋友到底会造成什么后果？

促销排期整整错一周。乌克兰语里那个词指一周里的某一天也就是星期日，俄语里几乎相同的词指整整一周。你想说星期日一天限定，另一边的用户理解成整周有效，第二天来找你要优惠。反方向则是你说本周特惠，被读成星期日限定，白白损失六天的转化。核假朋友时优先核按钮、价格区、配送说明、活动规则这四处，代价最高。所以活动文案里凡是涉及时间范围的一律写明确日期，别用相对说法。这在这个市场是硬要求不是建议，一次说不清就是整场活动的转化打折。

月份名的问题为什么测试环境发现不了？

因为它是静默回落。俄语月份名从拉丁语借来，乌克兰语用本土斯拉夫名，两套词毫无关系。很多日期库对乌克兰语的支持不如俄语完整，找不到数据时有些实现会静默回落到俄语，不报任何异常。页面上就出现俄语月份名混在乌克兰语文案里，用户看得懂但一眼知道这站没认真做。要在测试用例里显式断言渲染出来的月份名，而不是只断言日期没报错。最快的自查是把页面切到乌克兰语版本，找一个显示日期的位置，看月份名是不是本土形态，三十秒的事，很多站从来没做过。星期名同理，同样存在回落风险。

两门语言的词干还原能不能共用一套？

不能。两门语言的词尾变化表有相当程度的重合但不完全一样，乌克兰语的辅音交替规则还更多一些。用俄语的词干算法处理乌克兰语文本，大部分词能对，剩下那部分错得没有规律，排查起来非常费劲。实在找不到现成的乌克兰语方案，宁可只做简单的词尾归一，也别拿俄语那套硬套——错得有规律还能补，错得没规律只能一条条查。退一步的方案是只处理最高频的那几十个词尾，覆盖八成左右的情况，剩下的留给精确匹配。这个方案不完美，但错得有规律，后面还能补；拿俄语那套硬套是错得没规律，只能一条条查。

做两套内容的成本，比跨国的近亲语言市场高还是低？

低不少。因为两个市场在同一个国家里，货币、物流、法务、支付方式、配送区域全部共用，那批在跨国近亲市场里必须分开的非语言字段这次一项都不用分。分叉百分之百落在语言上，第一档的可复用面比任何一对跨国近亲语言都大，第三档的重写也更纯粹——只换语言，不用顺带改配送改货币改条款。算总账，边际成本明显更低。还有一个跨国市场没有的特点：这里的用户会主动在两种语言之间切换，而跨国近亲市场的用户不会为了买东西去看邻国站点。这既是麻烦，也意味着你的两套内容其实在服务同一批人，投入更容易摊薄。

权威参考资料