站上字最少的那几类页面最赚钱，也最容易被机器认成另一门语言

摘要：你在页面头部写了语言，也配了地区标注，但机器并不完全按你写的来。它会自己数一遍页面上的字符和词，得出一个结论，两个结论打架时赢的往往是它数出来的那个。而文本越短判错概率越高，偏偏分类页、筛选页、商品列表这些最赚钱的页面文本最短。本文讲清判错怎么发生、往哪一边倒、怎么在半天内测出来。

机器为什么不完全相信你写在页面上的语言声明？

声明和猜测是两条并行的链路

页面上有几处可以声明语言：文档根元素的属性、响应头、站点地图里的标注、页面之间的互指标签。

这几处都属于声明，意思是你说这页是什么语言，它就登记成什么语言。前提是对方愿意读，而且读得到。

另一条链路完全不看这些。它拿到页面文本，统计字符分布和常见词，算出一个最像的语言，附带一个置信度。

两条链路的输出经常一致，一致的时候没人会注意到有两条链路。不一致的时候，事情才开始变得难查。

更麻烦的是，你在后台看不到任何关于第二条链路的信息。它不产出报告，不发告警，只在结果里悄悄生效。

这里可以先立一条判据：声明是给愿意读它的人准备的，猜测是给不读的人准备的。而在任何一条真实链路上，不读声明的环节永远比读声明的环节多，尤其是那些顺手抓一段文本就拿去用的环节。

把这两条链路画在一张纸上，会发现它们的使用者也不一样。读声明的多半是那些要按语言做分发决策的环节，比如把哪个版本推给哪个市场；靠猜测的多半是那些拿到一段文本就要立刻处理的环节，比如判断要不要提示翻译、要不要做分词、用哪套词典去切词。后者的数量远多于前者，而且它们大多不在你的可观测范围之内。

为什么猜测常常赢过声明

猜测发生得更早。文本一到手就能算，不需要等页面渲染完，也不需要额外请求任何资源。

声明的读取要晚一步，而且要求解析器认得那个字段，还要求那个字段没写错。

写错的概率并不低。地区码写成语言码、大小写不规范、写了一个根本不存在的标签，这几种在真实站点上都很常见。

一旦声明的值解析不出来，链路会静默地退回到猜测，不会告诉你它退回了。

这就是很多团队的困惑来源：明明配好了，行为却像没配。原因不是配置没生效，是配置被判成了无效值。

还有一类更隐蔽的情形：声明写对了，但跟页面内容明显矛盾。声明说这页是荷兰语，正文九成是英语，这时候不少实现会选择相信内容而不是相信标签。标签只在跟内容不冲突时才被采纳，冲突时它降级成一个次要信号，这一点在任何官方文档里都不会明说。

还有一个现实原因：很多环节根本拿不到你的声明。它们处理的是从页面上抠出来的一段纯文本，标签在抽取那一步就被剥掉了。W3C国际化问答关于HTML语言声明的说明里讲得很清楚：声明属于文档，而文本片段一旦离开文档就不再携带它。

这跟地区定向不是一回事

语言和地区是两个维度，判错语言和定向错国家是两类问题，混在一起讨论会一直谈不拢。

地区定向靠的是域名、服务器位置、站点地图和后台设置，都是你能控制的信号。

语言识别靠的是页面上的字，这部分你也能控制，只是从来没人把它当成一个可以主动设计的东西。

把两者分开的好处是排查路径完全不同：定向问题去后台看设置，识别问题去页面上数字。

本文只讲后面那一半，前面那一半属于架构层，可以按国际化SEO与hreflang的完整实现清单那一套去排查。

一个很实用的分辨办法：问这个现象在单一市场的单语言站上会不会发生。会，那多半是识别层的问题；只在多市场多版本的站上出现，那多半是定向层的问题。用这一个问题就能把绝大多数议题分到正确的那一堆里去，会议上争论不下的时候尤其好用。

还有一个信号可以帮你快速定位：如果同一个页面在不同国家的搜索结果里都缺席，那多半是识别层；如果只在某一个国家缺席而在别的国家正常，那多半是定向层。缺席的范围本身就携带着诊断信息，看一眼就能省掉半天的排查。

语言识别到底在数什么？

字符分布是第一道筛子

如果页面上出现了某套书写系统专有的字符，语言范围立刻被收窄到几门语言之内。

希腊字母、谚文、天城文这类专属性很强的书写系统，第一道筛子就能筛得很准。

麻烦的是共用拉丁字母的那几十门语言，它们的字符集高度重叠，第一道筛子几乎不起作用。

西里尔字母也一样，俄语、乌克兰语、保加利亚语、塞尔维亚语共用大部分字母。

只有那几个专有字母能提供区分度，而它们在短文本里出现的概率并不高，Universal Dependencies的多语言树库项目里各语言的语料规模差异，也间接反映了模型能拿到多少这类区分证据。

这就解释了一个反直觉的现象：书写系统越独特的语言越不容易被判错，书写系统越常见的语言反而越危险。做小语种的人通常觉得非拉丁字母的语言更麻烦，在识别这一层上恰恰相反。

不过书写系统这一层也有陷阱：同一套书写系统里那几个专有字母，恰恰是最容易被用户省略的。塞尔维亚语的西里尔专有字母、乌克兰语的四个专有字母、罗马尼亚语带逗号的两个字母，用户在移动端经常打不出来，你的商品名如果照着用户的输入习惯写，判别力最强的那批字符就正好缺席了。

字符组合的频率是主力信号

主流做法是数字符组合的出现频率，比如连续三个字符构成的片段在这门语言里常不常见。

每门语言都有自己的高频组合，把页面上的组合分布跟已知分布比一比，最像的那个就是答案。

这种做法不需要理解语义，也不需要词典，速度快，覆盖语言多，所以被用得最广。

代价是它完全依赖统计，而统计需要样本。样本太少的时候，分布本身就不稳定。

常用的开源实现会同时给出一个置信度，但很多调用方直接取最高分那一个，把置信度丢掉了。

置信度被丢掉这件事影响很大：一个零点九的判定和一个零点三的判定，在下游看来是一样的结论。fastText的语言识别模型文档里明确给出了预测接口会返回概率值，能不能用起来取决于调用方，而调用方通常图省事。

还有一个容易忽略的点：这类模型通常有一个语言清单，清单之外的语言根本不会出现在结果里。如果你做的语言不在清单上，它会被强行归到最接近的那一门，而且置信度可能还不低。CLD3语言识别器的源码仓库里就列出了支持的语言清单，先去查一眼自己在不在上面，这是最省事的一次核对。

停用词和高频功能词是补充信号

有些实现会额外看一批高频功能词，比如冠词、介词、连词的出现情况。

这批词在同一语族内部差别很大，判别力比字符组合更强，尤其是在近亲语言之间。

但功能词恰恰是短页面上最缺的东西。一个分类页上全是名词短语，几乎没有完整句子。

没有完整句子就没有功能词，这道补充信号在最需要它的地方正好失灵。

这是短页面判错率高的一个具体机制，而不是一句笼统的样本太少。

反过来说，这也给了一个很便宜的改进方向：让短页面上多出现几个完整句子。一段两三句话的说明，带来的功能词数量比几十个商品名还多。这就是为什么给分类页加一小段说明文字的效果，往往比把商品名从二十个加到四十个更明显——加的不是字数，是句子结构。

功能词这条信号还有一个副作用值得知道：它对写作风格敏感。电商站的商品描述习惯写成短语堆叠，功能词天然就少；而同样一门语言的资讯类站点句子完整，功能词充足。所以同一门语言在不同类型的站点上，判定难度可以差出一个档次。

模板骨架也会被一起数进去

页面上的字不只有正文。导航、页脚、按钮、面包屑、筛选项标签，这些都是文本。

如果这些位置没有本地化，或者用的是英文缩写，它们会被一并统计进去。

骨架文本在长文页面上占比很小，在分类页上可能占到七成以上。

于是同一个站的两类页面会被判成两门语言，而团队从来没意识到这是同一套模板的结果。

这里可以提炼一条：骨架语言和内容语言是两个东西，判定结果取决于两者的比例。

模板骨架占比按语言重算一遍这件事，在一个模板生成十种语言的重复内容风险里是从重复度角度讲的，这里是同一个数字的另一种用法：那篇关心骨架占比高会不会造成十份内容雷同，本篇关心骨架占比高会不会把页面的语言判定整个带偏。

骨架文本还有一个特点：它在全站每一页上都一样。也就是说，如果骨架用的是英语，那这份英语证据会被均匀地撒在你所有的页面上，而本地语言的证据分布极不均匀。全站的语言判定因此会呈现一种奇怪的形态：长文页面判对，列表页判错，中间的商品页看运气。

为什么文本越短，判错的概率越高？

统计需要样本，短文本给不了

字符组合分布是一个统计量，样本少的时候方差大，偶然出现的几个组合就能改变结论。

公开的评测里，判定准确率随文本长度上升得很快，几十个字符和几百个字符是两个量级的可靠度。

短到十几个字符的时候，很多实现干脆给不出有意义的结论，只能返回一个低置信度的猜测。

而下游拿到这个猜测之后，通常不会区分它是高置信度还是低置信度。

结果就是一个几乎等于抛硬币的判定，被当成一个确定的事实往下传。

更值得警惕的是，这种误差不是随机分布的。它有系统性的偏向，会稳定地往某一个方向倒，这一点下一节专门讲。

有一个细节值得单独提：很多实现在文本极短时会返回一个表示未知的标签，而下游代码常常没处理这个分支，直接把它当成某个默认语言。默认值是什么，取决于写代码那个人当时在做哪个市场，通常是英语。这是一条你在任何文档里都查不到、只能靠读源码才能发现的行为。

最短的页面恰好是最值钱的页面

把站内页面按正文字数排一遍，最少的那一批通常是分类页、筛选结果页、品牌页、商品列表。

这几类页面在电商站上承接的是购买意图最强的那批查询，转化率通常高出内容页几倍。

于是出现了一个很别扭的结构：判错风险最高的地方，正好是商业价值最高的地方。

反过来，那些洋洋洒洒几千字的指南类文章，语言判定几乎不会错，但它们的转化贡献有限。

投入和风险的分布正好错位，这也是这个问题长期没人管的原因之一。

这条错位可以直接搬成一个排查顺序：先查最短的页面，别从首页和长文开始。多数团队的直觉正相反，他们从首页开始查，而首页往往是全站语言证据最充分的一页。

还有一个层面的错位：这几类短页面往往是自动生成的，没有内容团队参与，所以它们从来没进过任何一次内容评审。评审流程盯的是文章和商品描述，而真正承接购买意图的那批页面，从生成到上线全程没有人从语言角度看过一眼。

动态加载会让文本更短

不少站的商品列表是异步加载的，首屏返回的文档里几乎没有商品名。

抓取工具如果不执行脚本，拿到的就是一个只有骨架的文档，正文近乎为零。

这种页面被判成什么语言，基本取决于导航和页脚用的是什么语言。

如果模板里还留着英文的按钮文案，那这页大概率会被判成英语。

排查这一类的办法是直接看未执行脚本时的文档内容，而不是看浏览器里渲染完的样子。

缓解办法不一定要改渲染架构。在原始文档里保留一份精简的商品名列表、把分类描述写进服务端返回的文档、给筛选项标签用服务端渲染，这三样都是局部改动，加起来就能让原始文档里有足够的本地语言文本，比整站换渲染方式现实得多。

还有一个折中办法：给这类页面配一份服务端渲染的精简版本，专门给不执行脚本的访问方使用。这不是做两套内容，而是同一批数据的两种输出形态，维护成本很低。前提是两个版本的内容必须一致，否则会引出另一类麻烦。

哪几对语言最容易互相认错？

误判总是往语料多的那一边倒

近亲语言之间的判错不是对称的。资源多的那门语言更容易成为默认答案。

原因很直接：分类器的先验来自训练语料的分布，语料多的语言在模型里的权重天然更大，Common Crawl按语言统计的网页占比图能直观看出这个分布有多陡。

所以马来语容易被判成印尼语，乌克兰语容易被判成俄语，波斯尼亚语容易被判成塞尔维亚语或克罗地亚语。

反方向的误判也存在，但概率明显低一档，这在实践里意味着小语种一侧承担了大部分损失。

这条不对称性是本文最值得记住的一句：你做的语言越小众，被吸收进邻居的概率就越高。

它还有一个推论：这类问题不可能靠等待模型变好来解决。语料分布的差距是长期存在的结构性事实，模型换代只会让高资源语言的判定更准，两边的差距未必收窄。

这条不对称性还能解释一个常见的困惑：为什么同样的模板，做印尼语没事，做马来语就出问题。团队往往会往技术实现上找原因，其实原因在语料分布上，跟你的实现一个字都没关系。识别层的风险是按语言的资源量分配的，不是按你的投入分配的。

共用书写系统的那几对最危险

克罗地亚语、塞尔维亚语的拉丁写法、波斯尼亚语，三者的短文本几乎无法区分。

印尼语和马来语的商品名重合度极高，很多品类词根本一模一样。

捷克语和斯洛伐克语在长文本上分得开，在几个词的标签上分不开。

葡萄牙语的两个变体属于同一门语言，判定不会错，但地区判定会错，那是另一个问题。

这几对语言的市场决策差异在克罗地亚语和斯洛文尼亚语的两个小市场决策与印尼语与马来语能不能合并成一套两篇里各有拆解，本篇只补识别层这一角。

近亲语言之间还有一个更细的分层：书写系统相同、词汇相近、语法相近，三样占得越多越危险。捷克语和斯洛伐克语三样全占，判错概率最高；克罗地亚语和斯洛文尼亚语只占前两样，稍好一点。这个三分法在捷克语和斯洛伐克语的内容复用决策里是用来判断内容能不能共用的，在这里可以直接拿来估判错风险。

双语市场的页面最容易两头不靠

有些市场的用户日常混用两门语言，页面上也就自然出现两门语言的词。

这类页面的判定结果高度不稳定，同一页在不同实现下可能得到不同答案。

更常见的情况是被判成其中较强势的那一门，而你想覆盖的恰恰是另一门。

处理办法不是硬把另一门语言的词删掉，那会损害真实的用户覆盖。

正确的做法是在页面级别做取舍：主体语言只留一门，另一门以标注、括注、独立区块的形式存在，让统计上的主次分明。

嵌套型双语市场的关键词处理在菲律宾市场混合语言的关键词研究里讲过一套完整框架，识别层这一角可以直接接在那套框架后面用。

双语页面还有一个额外风险：它可能被判成两门语言之外的第三门。混合文本的字符组合分布跟任何一门单一语言都不像，识别器给出的结果有时会很离奇。遇到这种情况别急着调内容，先确认一下检测用的到底是哪一段文本，很多时候问题出在抽取环节而不是内容本身。

转写内容是最隐蔽的一类

用拉丁字母拼写本来用其他书写系统的语言，是很多市场的真实输入习惯。

这类文本在识别器眼里既不是原语言，也不是任何一门拉丁语言，判定结果会非常随机。

如果你为了覆盖转写查询单独做了页面，这些页面的语言判定几乎一定是错的。

这类页面本身仍然有价值，只是不能指望它们在语言维度上被正确归类。

务实的做法是给这类页面显式声明语言并接受判定可能错，同时不要让它们成为某个语言版本的主力落地页。

转写页面还有一个连带问题：它跟本语言的正式页面在内容上高度重合，而两者的语言判定又不一致，很容易被当成两个不相关的页面各自对待。稳妥的做法是让转写页面明确指向正式页面，把它当成一个入口而不是一个独立版本，这样即便判定错了，损失也被限制在入口这一层。

还有一个务实的判断：如果转写页面带来的流量本来就不多，那它的语言判定错不错其实无所谓，不必为它单独投入。判断依据是把这类页面的自然流量占比算出来，低于一个很小的比例就归到不管的那一类，把精力放回主力页面上。

混写页面会把整页拉向哪一门语言？

参数表是最大的一块英文飞地

商品参数表里往往全是型号、单位、材质缩写、认证编号，这些几乎都是拉丁字母。

一张二十行的参数表贡献的字符数，可能超过页面上所有本地语言正文的总和。

拿园艺工具站举例，一把修枝剪的参数表里，刃长、开合角度、材质牌号全是数字和英文缩写。

本地语言只剩下几个字段名，而字段名往往还被做成了图片或者缩写。

结果是这一页在统计上更像英语，而它恰恰是最重要的一类商品页。

解法不是删掉参数，而是把字段名写全、写成本地语言的完整词，并在参数值旁边补上本地语言的说明短语。字段名从缩写改成完整词，通常能把本地语言的字符占比拉高一大截，而这件事对用户也是有好处的。

参数表还有一个更简单的改法：把单位写成本地语言的完整词而不是国际缩写，比如厘米写成本地语言的完整拼写。这类词在每一行都出现，改一次就能在整张表上生效。缺点是表格会变宽，需要跟前端商量一下移动端的排版，但这属于可以解决的问题。

品牌名和型号不算证据

品牌名、型号、系列名在任何语言的页面上都长得一样，它们对判定没有贡献，还会稀释有效信号。

标题里如果品牌名和型号占了大半，剩下几个本地语言的词很难撑起判定。

这一点在标题模板设计上有直接影响：本地语言的品类词应该出现在标题里，而不是只靠品牌加型号。

顺带一提，这个改动对用户查询匹配也是正向的，属于一改两得。

品牌名在不同语言里的写法问题另有一套判断，本篇不展开。

还有一个相关的细节是替代文本。图片的替代文本属于页面文本的一部分，很多站的替代文本直接用了商品编号或者文件名，等于又贡献了一批无效字符。把替代文本写成本地语言的完整描述，既是无障碍要求，也顺手补了语言证据，这一条的性价比在非拉丁字母站点的图片替代文本写法里有专门的拆解。

另外还有一处：面包屑。面包屑里的分类名如果用的是英文标识而不是本地语言的显示名，它会出现在几乎每一个商品页上。这一处的改动量通常只是一次配置，收益却是全站级别的，属于最容易被漏掉也最容易补上的位置。

数字和单位有本地写法，别浪费

小数点、千位分隔符、日期顺序、货币位置，这些在各语言里写法不同。

它们本身就是语言证据，写对了不仅用户看着自然，识别器也能多拿到几个信号。

很多站的这些格式是从后台直接输出的，用的是系统默认，也就是英语习惯。

改成本地格式的成本很低，通常只是配置一个地区参数的事。

顺带还能解决一批用户困惑，比如把一千零五十写成带点的形态在某些市场会被读成一点零五。

格式这件事还有一个更深的层面：日期和数字的本地格式属于地区数据，各语言的规则由公开的地区数据库统一维护，实现只要调用就行。Unicode通用地区数据仓库就是这份数据的来源，绝大多数系统的本地格式化能力最终都指向它，不需要自己写规则。

判错之后，具体哪些环节会跟着出错

互指标签可能被整组忽略

页面之间的语言互指标签，前提是每一页的语言声明可信。

如果某一页被判成了另一门语言，这组标签的自洽性就出现了矛盾。

矛盾的处理方式各家不同，最坏的情况是整组标签被降权或忽略。

表现出来就是明明配得完全对称，某几门语言的版本还是不出现在对应市场。

排查时先别怀疑标签写法，先去看这几页被判成了什么语言。

排查这一类问题有个取巧的顺序：先挑一组配置最简单、页面最长的互指标签来验证，比如两个语言版本的长文章。如果这组正常而分类页那组不正常，问题基本可以锁定在识别层。用一组已知正常的配置当对照，比逐条检查标签写法快得多。

自动翻译会盖住你的原版

如果一页被判成了跟用户语言不同的语言，用户端可能出现自动翻译的提示或结果。

你精心做的本地化正文，被机器再翻一遍呈现给本来就说这门语言的用户。

翻出来的措辞通常比原文差，品牌语气也没了，而你在后台看不出这一层。

唯一的线索是转化率异常、跳出率异常，或者用户在反馈里提到读着奇怪。

这类现象的识别与防御属于另一个话题，本篇只指出它的上游可能是语言判错。

还有一个更容易被忽略的场景：站内的自动翻译插件。有些多语言插件会先检测当前内容的语言，再决定要不要翻译，如果它判错了，就会把本来已经是目标语言的内容再翻一遍。这类问题往往在上线很久之后才被用户投诉发现，而投诉的措辞通常是这页读着像机器翻的。

候选池和引用来源会挑错语言

问答类结果和生成式回答在挑来源时，会优先挑跟提问语言一致的页面。

被判成另一门语言的页面，在这一步会被整体跳过，而你在任何后台里都看不到这次跳过。

更糟的是，如果它被判成了一门高资源语言，它可能被拉去回答那门语言的问题。

那些提问者根本不是你的目标用户，展现有了，转化不会有。

这一层的观测手段极少，只能靠自己按语言抽样提问去反推。

反推的办法可以做得更结构化一点：用本语言问十条你最想被引用的问题，记录来源清单里有没有你的页面，再用邻近的高资源语言问同样十条，看你的页面有没有反而出现在那边。出现在错误的那一边，比两边都不出现更能说明是识别层出了问题，因为它证明你的内容是可见的，只是被归错了类。

站内的语言路由也会跟着乱

不少站会根据检测到的内容语言做一些自动化处理，比如推荐相关文章、生成站点地图分组、给内容打标签。

只要某一环用了自动检测而不是你的声明，判错就会顺着这条路扩散。

最常见的表现是相关推荐里混进了另一门语言的文章，用户点进去发现看不懂。

这类问题查起来不难，把内部所有做语言检测的位置列一遍就行，通常只有两三处。

把这几处统一改成读取声明值而不是自己检测，是成本最低的一次收口。

还要留意那些第三方服务：站内搜索、推荐引擎、评论过滤、广告投放平台，它们各自都可能做一次语言检测。这些服务不在你的代码库里，列表也就不会自动完整，需要按接入的服务逐个问一遍。问题清单其实只有一句话：你们是按我传的语言字段来，还是自己检测。

顺带说一个真实的排查经验：这类问题最常见的根因不是某个服务判错了，而是根本没人把语言字段传给它。接口文档里明明有这个字段，接入的时候图省事没填，服务只好自己检测。问一句有没有传，往往比问它怎么检测更快找到问题。

怎么在不装任何工具的情况下测出自己有没有被判错？

看浏览器给不给你弹翻译提示

浏览器的翻译提示本身就是一次语言判定的结果输出，而且是免费的、随时可用的。

用一个界面语言设成目标语言的浏览器打开你的页面，如果弹出了翻译提示，说明它认为这页不是那门语言。

逐类页面试一遍：首页、分类页、商品页、文章页、购物车，记录哪几类弹了提示。

弹提示的那几类就是判错风险最高的，通常正是文本最短的那几类。

这个方法粗糙，但它是唯一一个不需要任何权限、几分钟就能跑完的方法。

要提高准确度，可以在浏览器的翻译菜单里看它把源语言标成了什么，那个值就是它的判定结果，比有没有提示更精确。

这个测试还有一个变体：把浏览器界面语言设成一门完全无关的语言，比如英语，再打开你的页面，看它提示要把这页从什么语言翻译过来。提示里那个源语言就是判定结果，而且这个形态比有没有弹提示更直接，几秒钟就能记一条。

把文本粘进任意一个检测接口

公开的语言检测实现有好几个，把页面正文粘进去就能拿到判定结果和置信度。

关键是粘什么。要粘的是抓取工具实际能拿到的文本，不是你眼睛看到的全部内容。

做法是查看页面源码，把纯文本抽出来，去掉脚本和样式，再拿去检测。

同一页做两次对照：只用正文一次，正文加骨架一次，看结论会不会变。

如果两次结论不同，就说明骨架文本的比重已经足以影响判定，这是一个很明确的改进信号。

粘文本这一步有个容易搞错的地方：不要粘渲染后的可见文本，要粘原始文档里的文本。两者在动态站上差别巨大，而抓取方拿到的往往是前者。取原始文档只需要查看页面源代码，或者用命令行直接请求一次，不需要任何工具。

用同站两类页面做对照组

拿一篇长文和一个分类页做对照，两者用的是同一套模板、同一门语言。

如果长文判对而分类页判错，问题一定在文本量和骨架占比上，跟你的声明写法无关。

这个对照能省掉大量无用的排查，因为它一次性排除了配置层的嫌疑。

反过来如果两者都判错，那才需要回头去查声明值是不是写成了无效标签。

对照组的另一个好处是它在你换模板、换语言之后仍然可用，方法本身不会过期。

对照组还可以再加一层：拿同一门语言下不同类型的页面各测一遍，把结果排成一张小表。表里那几行判错的页面类型，就是这一轮要改的对象，而判对的那几行则告诉你证据密度到什么程度就够了。用自己的站当基准，比套用任何外部阈值都准。

对照组这套办法还有一个长期价值：它不依赖任何具体工具，也不依赖某个实现的当前行为。工具会换，接口会下线，模型会升级，但拿自己站上判对的页面当基准这件事永远成立，方法本身不会过期，这在这个变化很快的领域里相当难得。

短页面该怎么补足语言证据？

先算一算本地语言的字符占比

把一个典型分类页的纯文本导出来，人工标一遍哪些是本地语言、哪些是品牌型号和英文缩写。

算出本地语言字符的占比，这个数字就是你这一类页面的语言证据密度。

经验上，这个比例低于一半的页面就已经进入危险区，低于三成基本会被判错。

这个数字不需要精确，量级对就够用，它的作用是让讨论从感觉变成一个可比较的值。

把几类页面各算一个数，排个序，改进顺序自然就出来了。

这个测量还有一个额外用途：它给出的是一条可以持续跟踪的曲线。改版之后重算一次，就知道这次改版是把证据密度拉高了还是拉低了，而不必等几个月看流量。

标注的时候有个简化办法：不必逐字判断，按块估就行。把页面分成导航、筛选、商品名、参数、说明文字、页脚六块，每块估一个本地语言比例和字符数，加权求和。误差在几个百分点以内，完全够用来排优先级，而全部工作量不超过半小时。

把骨架文本本地化，优先级比想象中高

导航、筛选项、按钮、排序选项、分页文案，这些在分类页上的字符占比往往超过商品名。

把它们完整本地化，既是用户体验问题，也是语言判定问题，一次改动两头受益。

最容易被漏掉的是筛选项的值，比如颜色名、材质名、尺寸单位，很多站直接用了英文。

这几处的翻译量其实很小，通常几十个词，但它们在每一个分类页上都会出现。

换句话说，投入是一次性的，收益是乘以页面数量的，性价比在整套改动里最高。

这里有一个容易被漏掉的位置：错误提示和空状态文案。搜索无结果、筛选无结果、库存不足这类提示，往往是从组件库里直接带过来的英文，而它们出现在用户最需要引导的时刻。本地化这几句话，既是体验修复，也顺手把几个高频页面的证据密度拉了上去。

给短页面加一段真正有信息量的本地文字

在分类页顶部或底部加一段本地语言的说明文字，是最直接的补证据办法。

但要写成有信息量的段落，别写成关键词堆砌，后者既伤体验也不产生额外的判定价值。

一百到两百字就足够把判定拉稳，不需要写成一篇文章。

写作角度可以是选购建议、尺寸对照、本地使用场景，都是用户真的会看的内容。

顺带说一句，这段文字对长尾覆盖也有用，属于同一笔投入的两份回报。

这段文字放在哪里也有讲究。放在商品列表下方通常比放在最上方好，既不挤压商品的首屏位置，也仍然是文档里的正文。如果放在上方，控制在两三行以内，别把用户想看的东西推到折叠线以下——语言判定重要，但没有重要到可以牺牲转化。

一份按页面类型排的语言证据自检表

先按类型分组，别按单页排查

同一类型的页面用的是同一套模板，问题也是同一个，逐页排查纯属浪费。

把站内页面分成五到八个类型，每个类型抽两页做样本，结论可以覆盖整类。

抽样时挑正文最短的那一页，因为最短的那一页决定了这一类的风险下限。

每个类型记三个数：本地语言字符占比、检测结果、置信度。

三个数一填，哪一类要改、改到什么程度就都清楚了。

分组的时候建议按模板分，而不是按业务分类分。同一个模板生成的页面，语言证据结构是一样的，测一个就代表一批；按业务分类分组则可能把两套不同模板的页面混在一起，结论互相污染。问一句这批页面是不是同一个模板渲染的，就能分对组。

分组还有一个附带收益：它天然形成了一份模板清单。很多团队其实说不清自己站上到底有多少套模板，做这次排查的时候顺手把清单列出来，后面做任何模板级的改动都能复用，包括结构化数据、内链规则、页面速度优化。

把声明值单独核一遍

核对语言标签的写法是否合法，语言码和地区码有没有写反，有没有用了已废弃的标签。

合法性可以对着IANA语言子标签注册表核，那是所有语言标签的权威来源，三段式标签的组合规则则写在RFC 5646语言标签规范里。

注册表里能查到每个子标签的类型、是否废弃、废弃后该用哪一个替代。

顺手核一遍书写系统子标签有没有在该写的时候写上，这一条在多书写系统的语言上是必需的。

这一步半小时能做完，属于低成本高确定性的部分，建议放在最前面做。

核对时特别注意那几个看起来对、其实不对的写法：只写语言码却在内容上用了地区变体、书写系统子标签该写没写、把地区码写成了小写或者把语言码写成了大写。这些写法有的会被容错处理，有的会被判成无效，而你无法预知每个实现的容错策略，唯一稳妥的做法是完全按规范写。

改完之后怎么验收

验收不要只看检测结果变没变，还要看置信度有没有明显上升。

从零点四涨到零点五和从零点四涨到零点九，稳定性完全不是一回事。

再跑一遍浏览器翻译提示的测试，看那几类页面还弹不弹。

两个信号都变好，才算这一轮改动生效，只有一个变好通常意味着还差一层。

把这两个数字记进上线前的检查清单，之后每次改模板顺手跑一遍，成本几乎为零。

验收还要留一道回归：把这份检查加进模板改动的上线清单里。语言证据密度是很容易被一次改版打回原形的，比如某次改版把说明文字挪到了脚本加载的区块里，或者把字段名换回了缩写。加一道自动化的抽样检查，成本是一次性的，而它防的是一类会反复发生的回退。

哪些问题不归语言层，该交给谁？

地区归属那一半交给架构层

判错语言和定向错市场是两回事，后者靠域名结构、后台设置和互指标签解决。

本篇讨论的所有动作都不影响地区归属，别指望改了文案就能换一个市场。

两个议题混在一起谈，通常会以互相甩锅收场，因为负责的团队都不是同一个。

把它们分成两张排查表，各自有各自的验收标准，会议效率立刻不一样。

地区那一半的完整拆解不在本篇范围内，架构层的文章讲得更细。

还有一类容易混进来的议题是同一门语言在多个市场的分配，比如西班牙语在西班牙和拉美、葡萄牙语在巴西和葡萄牙。那属于同语言多地区的问题，判定层根本分不出来，也不该由判定层负责。识别层只回答这是哪门语言，回答不了这是给哪个市场看的。

翻译质量那一半交给内容层

语言判对了不代表内容读着自然，判错了也不代表翻译质量差，两者没有必然联系。

本篇讲的是能不能被数出来，不是写得好不好，这两个目标偶尔还会互相拉扯。

比如为了提高证据密度硬加文字，就可能伤到内容质量，这时候要以内容质量优先。

加文字的正确姿势是加真正有用的信息，而不是为了凑字符数。

验收标准也该分开：内容质量交给母语审校，证据密度交给这张自检表。

两个目标真冲突的时候，有一个简单的排序：先保证内容对人有用，再考虑对机器好数。因为内容差是确定的损失，判定错是概率性的损失，用确定的损失去换概率性的收益从来都不划算。这条排序也能防住一类常见的过度优化。

还有一种情况要提前说清楚：如果某一类页面的本地语言文本注定上不去，比如纯参数型的技术规格页，那就别硬凑。接受它的判定不稳定，把它排除在主力落地页之外，用别的页面去承接这批查询，这是一个正当的选择，不是妥协。

引擎自己怎么判，不是你能优化的对象

你无法改变识别模型，也拿不到它的判定日志，能做的只有让页面上的证据更充分。

所以目标要定成让判对的概率更高，而不是让某个引擎给出某个具体结论。

把目标定错的团队会去做各种试探性的改动，结果不可复现，也没法沉淀成规范。

可复现的只有一件事：本地语言字符占比上去了，判对的概率就上去了。

这条因果关系足够简单，也足够稳，值得写进模板开发的验收标准里。

最后补一句关于预期管理的话：这套改动的效果不会立刻体现在流量上，它先体现在判定结果和置信度上，再传导到收录、展现和引用。中间隔着几周甚至更久。所以验收标准要定在你能直接测到的那两个数字上，而不是定在流量上，否则很容易在效果显现之前就被判定为无效而砍掉。

常见问题解答

我的站只做一门小语种，也会被判错吗？

会，而且比多语言站更容易被忽略。多语言站至少有版本之间的对照，一旦某个版本表现异常，还有个参照物；单语言站没有参照，判错之后所有页面一起偏，看上去反而像是市场本身不行。单语言站的另一个风险是模板往往是从英文站直接改过来的，骨架文案留了一堆英文，而这些文案在每一页上都出现。先做的事很简单：找一个正文最少的页面，把它的纯文本拿去检测一次，几分钟就知道有没有问题。

页面头部的语言属性到底还有没有用？

有用，而且必须写对，只是别指望它单独就能定调。它的作用是在证据充分的时候提供确认，在证据不充分的时候提供一个默认值，以及给浏览器、屏幕阅读器、断词规则、拼写检查这些渲染侧的功能当开关，MDN关于lang全局属性的说明把这几项影响列得很全。真正没用的是写错的属性值，比如把地区码写在语言码的位置、用了废弃标签、或者整站硬编码成同一个值。写对它的成本几乎为零，收益是让另一条链路至少有机会站在你这边。

用脚本渲染的商品列表，判定拿的是哪一版文本？

取决于抓取方执行不执行脚本，而不同抓取方的答案不一样。主流搜索引擎会渲染，但渲染有排队和预算；很多轻量抓取工具、部分内容聚合方、一部分模型训练用的抓取器不渲染。所以稳妥的假设是同时存在两个版本的文本，一个有商品名，一个没有。判断办法是直接请求页面拿原始文档，看里面有多少本地语言的字。如果原始文档几乎是空的，那就说明有一批抓取方看到的是一个没有语言证据的骨架。

本地语言字符占比多少才算安全？

没有一个官方阈值，但从实测经验看，超过六成基本稳定，五成左右开始出现波动，低于三成的页面判错概率相当高。更实用的做法不是盯绝对值，而是盯同站内的相对值：把长文页面的占比当成对照组，看短页面差多少。差距在十几个百分点以内通常没事，差到三十个百分点以上就该动手。用相对值的好处是它自动排除了品牌名、型号这类每个站都不一样的干扰。

被判成了高资源语言，会不会反而多拿一点流量？

基本不会，而且这个想法很危险。被判成另一门语言，意味着你的页面进了一个自己完全不占优势的池子，跟母语内容同台竞争，排名机会极低；同时它在真正属于你的那个池子里缺席了。展现数据上可能看起来有一点点起色，但转化会告诉你真相：那批人根本看不懂你的页面。这跟做一个自己不擅长的市场是同一类错误，只不过这次不是你主动选的。

加一段本地文字算不算为了SEO凑字数？

看你加的是什么。加一段真正回答用户问题的说明文字，是内容改进，顺便解决了证据密度；把关键词换着花样重复十遍，那是凑字数，既不解决判定问题也伤体验。判断标准很朴素：把这段文字单独拿给一个从没见过这页的人看，他能不能获得新信息。能，就留下；不能，就删掉重写。分类页最容易写出真信息的角度是选购判断、尺寸对照和本地使用场景。

这件事该由谁负责，前端还是内容？

责任要拆成两半。声明值的正确性、原始文档里有没有文本、模板骨架是否本地化，这三样归前端和模板负责，属于一次性的工程改动；补充说明文字、字段名写全、本地格式的数字与单位，这些归内容和运营负责，属于持续性的工作。麻烦的是这两半必须一起做才有效果，只做一半通常看不出变化，所以最好一次排期把两边都放进去，别拆成两个季度。

权威参考资料