# 保哥笔记 — 小语种SEO

> 本分片含 35 篇文章，按发布日期倒序。全部分片索引见 https://zhangwenbao.com/llms-full.md

**站点**：https://zhangwenbao.com/  
**分类**：小语种SEO  
**生成**：2026-09-12 13:06:31 CST

---

## 僧伽罗语的搜索需求比缅甸语健康得多，斯里兰卡20家大公司的网站上一个僧伽罗字都没有

- URL：https://zhangwenbao.com/sinhala-seo-demand-supply-language-gap.html
- 分类：小语种SEO
- 发布：2026-08-02  |  更新：2026-08-02
- 摘要：僧伽罗语的搜索需求跟泰语几乎持平，而斯里兰卡20家头部商业站的正文里僧伽罗文合计56个字符。给出两侧的测量方法、语言声明的三层塌陷，以及三种入场姿势与最小验证。
- 关键词：跨境电商,多语言SEO,国际SEO,小语种SEO

> **TLDR**：摘要：僧伽罗语在搜索里是活的——24个电商概念查下来189条建议，交易动作词的存活率0.86，跟泰语几乎持平，比缅甸语健康将近三倍。可是把斯里兰卡20家最大的电商、电信、银行、超市的网站抓下来数字符，僧伽罗文合计56个，拉丁字母113222个，14家是绝对零。需求在本地语言里，供给全在英语里。本文给出两侧的完整数字、那家把语言代码写成非洲某门语言的国有银行、以及这个缺口该怎么算账、怎么入场。

> 
摘要：僧伽罗语在搜索里是活的——24个电商概念查下来189条建议，交易动作词的存活率0.86，跟泰语几乎持平，比缅甸语健康将近三倍。可是把斯里兰卡20家最大的电商、电信、银行、超市的网站抓下来数字符，僧伽罗文合计56个，拉丁字母113222个，14家是绝对零。需求在本地语言里，供给全在英语里。本文给出两侧的完整数字、那家把语言代码写成非洲某门语言的国有银行、以及这个缺口该怎么算账、怎么入场。

有个做家用储能的独立站，去年想进斯里兰卡。那个市场的逻辑很硬——长期电力紧张，家庭对储能和逆变器的需求是真实的，不需要教育市场。

团队开会讨论要不要做僧伽罗语版本，讨论了两轮，结论是不做。理由听着挺专业：把当地几家最大的同行网站打开看了一圈，全是英文，一个本地文字都没有；既然本地头部玩家都不做，说明这个市场的线上消费人群本来就用英语。

这个推理有一个致命的漏洞。他们只看了供给侧。

## 需求在这门语言里，供给在另一门语言里

## 先说结论，因为它反直觉

这两侧的数字后面会逐个摊开，这里先把结果放在最前面：僧伽罗语的搜索需求是健康的，而斯里兰卡商业网站上的僧伽罗语内容接近于不存在。

这跟做小语种时最常遇到的那个问题正好是反的。多数小语种的麻烦是需求太薄——你写了，没人搜。这里的麻烦是需求好好的在那儿，没人写。

## 这两种问题的解法完全相反

需求薄的市场，正确动作是收缩：砍掉导购内容，只做品类页，把预算挪去别的语言。同一批实验里的老挝语就是这一档，那门语言的交易动作词八个里七个是零建议，具体数据在老挝语的关键词表为什么会在第九个词上断掉 (https://zhangwenbao.com/lao-seo-transactional-keyword-collapse.html)那一篇里。

供给薄的市场，正确动作是相反的：加大投入，因为你面对的是一片没人占的位置。判断自己落在哪一边，只需要把两侧各量一次，一个下午就够。

把两者搞混的代价很实在。开头那家储能站按“同行都不做”推出“市场不需要”，等于把一个几乎无人竞争的入口主动让了出去。

## 本文谈什么、不谈什么

本文谈僧伽罗语这一门语言在需求与供给两侧的错位，以及由它推出来的入场判断。不谈这套文字里那些把辅音连成一体的组合机制——那跟本站写过的几门南亚文字是同一类问题，字素簇怎么数、字段长度怎么算，都在孟加拉语关键词表与字素簇那一篇 (https://zhangwenbao.com/bengali-seo-two-markets-vocabulary-grapheme.html)里量过了。

也不谈斯里兰卡的泰米尔语那一半。那是另一门语言、另一个社群、另一套词表，本文只在需要做对照的时候提一句。

## 先量需求侧：僧伽罗语在搜索里到底活不活？

## 24个概念，分三组

需求侧用的尺子是搜索建议，不是关键词工具——主流工具在这几门语言上要么没有条目，要么给出一个明显插值出来的数，这类数据陷阱本站在小语种关键词工具查不到数据时的几种替代做法 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)里拆过。词表取24个电商场景绕不开的概念，平均分成三组：实体品类词（电话、摩托车、衣服、冰箱、电脑、鞋、电视、手表）、交易动作词（网购、下单、送货、退货、付款、保修、折扣、批发）、抽象概念词（价格、质量、评测、对比、怎么选、最好的、资料、服务）。

分组这一步不能省。如果只是随手抓一把词去查，得到的会是一个笼统的“数量偏少”，而分组之后才看得出零落在哪一列——这个差别，在下一节的对照表里会变得非常直观。

## 五门语言并排看

只查一门语言说明不了什么，所以同一批概念在僧伽罗语、泰语、缅甸语、高棉语、老挝语上各按本族说法写一遍，逐个查建议。这几门语言各自的使用人口与地理分布，可以在Ethnologue的斯里兰卡语言构成页 (https://www.ethnologue.com/country/LK/)这类档案里核对。泰语是参照系，它是这一带数据最全的语言。

语言 | 实体8词 | 交易8词 | 抽象8词 | 合计 | 零建议词 | 交易÷实体 | 

泰语 | 80 | 71 | 80 | 231 | 0/24 | 0.89 | 

僧伽罗语 | 66 | 57 | 66 | 189 | 3/24 | 0.86 | 

缅甸语 | 70 | 22 | 28 | 120 | 11/24 | 0.31 | 

高棉语 | 61 | 6 | 34 | 101 | 11/24 | 0.10 | 

老挝语 | 43 | 1 | 16 | 60 | 13/24 | 0.02 | 

僧伽罗语这一行的形状很平整：66、57、66。三列的量级差不多，没有哪一列塌下去。

## 0.86这个数意味着什么

最后那一列是交易词除以实体词。这个比值不受语言体量影响，分子分母同时缩放，所以能横向比。

僧伽罗语0.86，泰语0.89，两者基本持平。这意味着这门语言能承接完整的购买漏斗——用户不只用它搜“冰箱”，也用它搜“折扣”“保修”“批发”。而缅甸语0.31、高棉语0.10、老挝语0.02，这三门语言的用户在漏斗下半截会切走。

再看零建议词那一列：僧伽罗语只有3个词拉不出建议，而缅甸语和高棉语各11个、老挝语13个。这门语言在搜索侧的完整度，跟它的人口规模完全不成比例。

## 那3个零建议的词是哪三个

零建议只有3个，但具体是哪三个比数量更有信息量。实测下来是：网购、退货、怎么选。

这三个词落在一起不是巧合。它们共同的特点是都描述“在网上完成一整套动作”这件事，而这恰恰是斯里兰卡线上零售还没长成的那一块——跨境支付受外汇管制、平台化退货流程不普及、比价决策更多发生在线下门店里。

反过来说，另外五个交易动作词全是活的：下单9条、送货8条、付款10条、保修10条、折扣10条、批发10条。用户会用僧伽罗语搜“怎么付款”“保修多久”“批发价”，只是不会搜“怎么在网上买”。

这个分布对内容规划有直接用处：保修条款、配送时效、批发起订量这三类内容值得单独做页面，而“网购指南”“退货流程”这类页面在这门语言里没有入口。

## 顺带一提，条目数这把尺子在这里会骗人

衡量一门语言值不值得做，常见做法是量它的内容总量。拿一个公开可复现的量对一下——各语言维基百科的条目数：

语言 | 维基条目数 | 活跃编辑 | 交易÷实体 | 

泰语 | 185785 | 2828 | 0.89 | 

缅甸语 | 111538 | 300 | 0.31 | 

僧伽罗语 | 25614 | 159 | 0.86 | 

高棉语 | 12155 | 137 | 0.10 | 

老挝语 | 5594 | 61 | 0.02 | 

按内容总量排，缅甸语第二、僧伽罗语第三，缅甸语的条目数是僧伽罗语的4.4倍。按交易存活率排，两者掉了个位置，僧伽罗语是缅甸语的2.8倍。僧伽罗语用不到缅甸语四分之一的内容量，换到了将近三倍的交易词覆盖，两把尺子给出的语言优先级排序是冲突的。

原因不难理解：内容总量量的是“这门语言里有多少字被写出来”，交易存活率量的是“这门语言被用来干什么”。做电商的人要的是后者。这一层的成本估算框架本站在小语种优先级该怎么算这笔账 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)里给过，本文这个比值可以当它的一个新输入项，专门补上“需求类型”这一格。

## 再量供给侧：20家公司的网站上有多少个僧伽罗字？

## 名单是怎么选的

供给侧要量的不是“斯里兰卡有没有僧伽罗语网页”，而是“做生意的那批网站上有没有”。所以名单按行业凑，避开媒体：电商与零售、电信运营商、银行与保险、超市与家电连锁，24个域名，能返回200的20个。

统计口径跟前面一致，只数正文容器里的字符——p、li、td、h1到h3这几个标签，不数导航和页脚；僧伽罗文字符按Unicode僧伽罗文块U+0D80到U+0DFF (https://www.unicode.org/charts/PDF/U0D80.pdf)这段区间判定。这一条是必须的：只看首页标题会得出完全相反的结论。

## 56比113222

20个站的正文里，僧伽罗文字符合计56个，拉丁字母合计113222个。僧伽罗文占0.00%。

不是“比例低”，是逐站看下来大面积的绝对零：

- 僧伽罗文字符恰好为0的：14个站，包括斯里兰卡最大的家电连锁、最大的家具品牌、三家超市连锁、三家电信运营商、两家大银行

- 个位数的：某电商1家12个、某银行5个、某电信5个、某超市3个、某保险2个

- 最多的一家是某跨境电商平台，29个

29个字符是什么概念——大概是一句话。这是20家里表现最好的。

## 电商、电信、银行、超市，一个都不例外

本来预期至少某几类会不一样。比如超市连锁面向的是最广泛的普通家庭，银行要承担公共服务职能，电信运营商的用户覆盖到县乡——这三类怎么也该有本地语言版本。

实测下来没有例外。四个行业、20家公司，把僧伽罗语放进正文的一家都没有，最高的那家是29个字符。行业之间的差异小到可以忽略，这说明它不是某个公司的疏忽，是整个商业互联网的默认状态。

## 这个0.00%该怎么读

先说它不意味着什么。它不意味着这些公司没有僧伽罗语的服务——它们的门店、客服、纸质单据几乎肯定是僧伽罗语的。它只意味着这些内容没有出现在网页正文里。

再说它意味着什么。搜索引擎能索引的只有网页上的字。一个用僧伽罗语搜索的用户，无论他离这家公司的门店多近，都不会在结果里遇到这家公司用他的语言写的任何一句话。

把它跟前一节的0.86放在一起看：需求侧一整条漏斗都在这门语言里，供给侧一句话都不在。这中间的落差，就是这篇文章的全部内容。

## 顺带一提，抓不下来的那几个站本身也是数据

24个域名里有4个没抓成。两个是域名解析失败，两个返回了拒绝访问。这个比例在成熟市场里不常见，它侧面说明这批站的运维投入不高。

运维投入不高这件事跟本文的主题是连着的。一个公司如果连站点可用性都没人盯，那它不太可能有人在考虑“要不要出一个本地语言版本”。这两件事背后是同一个原因——网站在这些公司里不是一条被认真经营的渠道，是一个必须有的门面。

这对入场的人反而是好消息：你要超越的不是一群认真做SEO的对手，是一批没人管的门面站。

## 会不会是斯里兰卡人上网本来就不用僧伽罗文？

## 这个排除项为什么必须做

看到商业站全是英文，最容易得出的解释是：能上网、能网购的那批人本来就受过英语教育，他们上网就是用英语的，所以商业站用英语没错。

这个解释如果成立，前面那个落差就不存在了——需求侧的搜索建议可能只是少数人贡献的，代表不了有购买力的那群人。所以这一步必须验，而且要用同一套方法验，不能靠推理。

## 新闻站那一侧的数字

验法很简单：把同一批工具指向斯里兰卡的僧伽罗语新闻媒体，看它们的正文用什么文字。

站点类型 | 僧伽罗文占正文比例 | 

某综合新闻门户僧伽罗版 | 91% | 

某主流日报 | 87% | 

另一家主流日报 | 81% | 

某电视台新闻站 | 94% | 

另一家电视台新闻站 | 94% | 

某国营电视台新闻站 | 96% | 

某新兴新闻站 | 69% | 

七个新闻站，僧伽罗文占正文的比例在69%到96%之间。这些站每天都在生产僧伽罗语内容，而且有人读——如果没人读，它们撑不到今天。

## 泰米尔语那一侧同样成立

再验一次另一门语言。同一家新闻门户的泰米尔语版本，泰米尔文占正文89%。

也就是说，斯里兰卡的两门本地语言在媒体这个场景里都是活的，而且都写在网页正文里、都可以被索引。这条对照把“本地语言不适合上网”这个解释彻底排除掉了。

## 所以分界线在场景，不在语言

把三组数字并排：媒体站69%到96%的僧伽罗文，商业站0.00%的僧伽罗文，搜索侧0.86的交易词存活率。

结论只能是：斯里兰卡人用僧伽罗语读新闻、用僧伽罗语搜东西，但斯里兰卡的公司用英语做网站。分界线不划在语言上，划在场景上——同一批人在不同场景里用不同的语言，而商业这个场景整体归了英语。

这跟同一个国家里两门语言分工的那种情形不一样。那种情形里两门语言各自对应一批人，本站在乌克兰语市场里两种语言都看得懂的用户怎么分内容 (https://zhangwenbao.com/ukrainian-russian-seo-bilingual-market-content-split.html)那一篇里拆过。这里是同一批人在不同场景里切换，切换点不在人身上，在事情的类型上。

## 那些满出来的搜索建议，装的是什么内容？

## 把手机那个词的十条建议全打出来

需求侧0.86这个数是按条数算的。条数够不等于内容对，所以下一步是把建议的原文逐条读一遍。

僧伽罗语的“手机”这个词拉满10条建议，逐条译过来是这样的：关于手机的作文、手机是谁发明的、二年级关于手机的作文、关于手机的详细介绍、三年级关于手机的作文、给手机打电话、自己做一个手机、手机成瘾、九年级关于手机的作文、十年级关于手机的作文。

十条里六条是学生作文题。一条价格没有，一条品牌没有，一条购买意图都没有。

## 电脑和电视也是同一个形状

不是孤例。“电脑”那10条：电脑简介的PDF、电脑之父、电脑的组成部件、电脑是谁发明的、什么是电脑、关于电脑的诗、电脑的历史、电脑部件的PDF、关于电脑的作文、电脑的基本组成。

“电视”那10条里有六条是不同年级的作文题——五年级、九年级、二年级、四年级各一条，另有电视是谁发明的、电视的历史。

把这三个词的30条建议里出现的拉丁字母统计一遍，只有四种：english出现3次、pdf出现3次、meaning出现2次、online出现1次。一个品牌名都没有。

## 对照组：老挝语那边全是品牌名

同一套统计放到老挝语上，结果正好相反。老挝语实体品类词的43条建议里有40条含拉丁字母，而那些拉丁字母几乎全是商品品牌：wave出现9次，samsung 3次，oppo 2次，nike 2次，然后是iphone、vivo、infinix、huawei、tecno、honor、honda、toshiba、adidas各1次。

两门语言的建议池，一个塞满了品牌型号，一个塞满了作文题和PDF。而它们的条数是接近的。

## 一条因果链：教育用这门语言，商业用另一门

把前面所有的数字串起来，能拼出一条完整的因果链。

斯里兰卡的中小学教育是用僧伽罗语的，学生要用僧伽罗语写作文、查资料、找PDF，所以这门语言的查询池被教育需求撑得满满的。而商业——公司网站、产品说明、电商页面——整体归了英语，于是商业类的查询在这门语言里根本没长出来，能长出来的只有“价格”这种同时属于两个场景的词。

一门语言可以在某些场景里满、在另一些场景里空，决定它的不是语言本身，是这个国家哪些事情用哪门语言办。这一条比“语言体量决定数据量”解释力强得多，因为它能同时解释僧伽罗语的高条数和低商业浓度。

需要说清楚的是，这条因果链是解释，不是实测。实测的部分是建议内容的分布，把它归因到教育体系那一步用的是常识推理。写在这里是因为它有落地价值，读者可以用自己市场的数据去验，但别把它当成本文测出来的结论。

## 有一个词是反例，而它恰好指出了解法

不是所有实体词都被作文题占了。“鞋”这个词的10条建议是：鞋的种类、女式鞋的种类、男式鞋的种类和价格、鞋的设计、男式鞋的设计、鞋码、鞋的价格，另有几条关于一种同名的花。

种类、男女式、价格、设计、尺码——这是一串标准的电商查询。同一门语言、同一个实验、同一个接口，为什么这个词的结果完全不同？

差别在词本身。手机、电脑、电视这三个词是用梵语构词法造出来的正式词，它们进入僧伽罗语的路径是学校和公文；而“鞋”是这门语言里本来就有的日常老词，谁都会说，不需要上学才学。用正式构词法造出来的词，它的查询池归学校；日常老词的查询池才归市场。

这条判据比它看上去有用，因为它是可操作的：拿到一个候选词，先问它是不是这门语言里本来就有的说法。是，就大概率有商业查询；不是，那多半只能拉出查词义的流量。

顺带划一条界：这跟本站写过的泰米尔语那一篇形状相似但轴不一样，那边分的是官方造词与音译借词，两个词都可能是新的；这边分的是老词与正式构词，判据落在词的年龄和它的进入路径上。两篇的落地动作不同，下一节还会再碰一次这条界。

## 连“我有僧伽罗语版本”这件事都没说出口

## 40个站里只有1个把语言声明写成僧伽罗语

抓站的时候顺手记了每个页面的语言声明。这一项本来不在实验计划里，结果它自己跳出来，而且比正文那组数字还难看。

把前面所有抓过的斯里兰卡站点合起来算——政府机构、新闻媒体、商业公司总共40个可用页面，把lang写成si或者si-LK的，1个。

那唯一的一个是某国营电视台的新闻站。其余39个：23个写en、5个写en-US、3个写en-GB、1个写en-LK、1个写泰米尔语、6个干脆没写。

注意那批僧伽罗语新闻站——正文里96%是僧伽罗文，语言声明写的却是en。整站的字都是僧伽罗文，而它对机器说自己是英语的。

## 那20家商业站的跨语言声明

再看一层。如果一家公司确实做了僧伽罗语版本，它至少该按Google关于本地化版本与跨语言声明的规范 (https://developers.google.com/search/docs/specialty/international/localized-versions)告诉搜索引擎“另一个版本在这里”。20家商业站里带这类声明的有4家。

公司类型 | 声明的语言版本 | 写得对不对 | 

某分类信息平台 | 英语、僧伽罗语、泰米尔语、默认版本 | 写全了 | 

某电信运营商 | 英语、僧伽罗语、泰米尔语 | 写全了 | 

某保险公司 | 英语、僧伽罗语、泰米尔语，都带地区后缀 | 写全了 | 

某国有银行 | 英语、sn、泰米尔语、默认版本 | 中间那个不是僧伽罗语 | 

剩下16家一条都没有。

## 那家国有银行把僧伽罗语写成了非洲的一门语言

第四行值得单独说。这家银行是斯里兰卡的国有银行之一，网点覆盖全国，它的跨语言声明写的是英语、sn、泰米尔语。

僧伽罗语的代码是si，三位代码写作sin (https://iso639-3.sil.org/code/sin)。而sn是绍纳语，三位代码sna (https://iso639-3.sil.org/code/sna)，津巴布韦和赞比亚一带使用的一门班图语系语言，跟斯里兰卡隔着大半个地球，两门语言之间没有任何关系。

这两个代码只差一个字母，都是两位小写字母，都在同一份注册表里，肉眼扫过去几乎分辨不出。而后果是：这家银行确实做了僧伽罗语版本、确实写了声明想告诉搜索引擎，结果它告诉搜索引擎的是“我这个版本是给说绍纳语的人看的”。

这类错误最难被发现的地方在于，它填了、格式也对、验证工具不会报错——错的只是那个值指向了另一门真实存在的语言。

## 一个字母的代价

值得算一下这一个字母值多少钱。这家银行为僧伽罗语版本付出的成本包括：翻译整站内容、维护两套页面、培训编辑、测试字体渲染。这笔钱已经花掉了。

而它换来的搜索侧收益，因为那个字母，接近于零——搜索引擎不会把这个版本推给僧伽罗语用户，因为它按声明理解，这是给绍纳语用户准备的。

这一层该怎么写才对，本站在小语种结构化数据里的语言与地区字段该怎么写 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)里给过规范，那边讲的是自己站怎么写对。这里补一条验收动作：写完之后不要只检查格式，要把每一个语言代码拿去注册表里反查一遍，确认它对应的是你想的那门语言。两位代码的重码率比想象中高。

## 两位语言代码为什么这么容易撞

这类错误不是偶然，它有结构性原因。两位语言代码那一套标准总共只有一百八十来个坑位，要塞下全世界的主要语言，重码压力很大，于是大量代码是拿语言名字的头两个字母凑的。

结果就是一堆看着像的组合：僧伽罗语si对绍纳语sn，老挝语lo对拉丁语la，斯洛伐克语sk对斯洛文尼亚语sl，挪威语no对荷兰语nl。它们的共同点是——写错之后仍然是一个合法的语言代码，指向另一门真实存在的语言，所以任何格式校验都拦不住。

三位代码那一套坑位多得多，重码压力小，僧伽罗语是sin、绍纳语是sna，一眼能分开。可惜网页上通行的是两位那一套。

保哥的做法是在上线清单里固定加一条：所有语言代码提取出来，逐个丢进IANA语言子标签注册表 (https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry)，把查到的语言全名打印出来，人工扫一眼。这一步几秒钟，但它是唯一能拦住这类错误的动作。

## 这三层塌陷是叠加的

把这一节和上一节合起来看，斯里兰卡的商业互联网在僧伽罗语这件事上塌了三层，而且是逐层叠加的：

- 第一层：正文里没有僧伽罗语内容，20家里14家是绝对零

- 第二层：极少数做了内容的，语言声明写成英语，40个页面里只有1个写对

- 第三层：极少数写了跨语言声明的，其中还有一家把代码写成了另一门语言

三层任何一层做对，都能拿到一点搜索侧的收益。三层全塌，等于这门语言在商业搜索里完全没有供给。

## 真要写僧伽罗语，该写哪一套？

## 这门语言的书面体和口语体差得比想象中远

决定要写之后，马上会撞上第二个问题：僧伽罗语的书面体和口语体不是文白之别那么简单，它们的动词形态是两套不同的系统。

书面体的动词要跟主语在人称和数上保持一致，口语体完全没有这一层——同一个动作，书面写一个形态，嘴里说另一个形态，两者的词尾长得完全不一样。这不是风格差异，是语法差异，而搜索是按字符串匹配的。

这跟本站写过的另外两种情形都不同轴。北欧那几个市场里挪威语的两套官方书面标准 (https://zhangwenbao.com/nordic-seo-swedish-norwegian-danish-content-sharing-boundary.html)是并列关系，两套各自有正式地位、各自有拥护者；阿拉伯语那种一套书面语配多种地区方言 (https://zhangwenbao.com/arabic-seo-rtl-layout-msa-dialect-keyword.html)的格局有明确的地理维度，按方言区能切成几大块。僧伽罗语这边两样都不是——没有地理维度，也不是两套都有官方地位，是同一批人在同一个地方，正式场合用一套、日常用另一套。

## 七个新闻站的书面口语比

供给侧这一层也量了一次。取六个书面体动词标记和六个口语体动词标记，在那七个僧伽罗语新闻站的正文里逐个数。

原本以为新闻正文会是压倒性的书面体，预期是九成以上。实测下来是书面351次、口语198次，口语体占36%，跟预期差了一大截。

而且逐站差异极大：最正式的那家新闻门户口语只占7.1%，另一家电视台新闻站29.4%，两家主流日报分别是32.5%和36.2%，某新兴新闻站45.8%，而其中一家老牌日报是57.3%——口语体反而过半。

## 这个36%说明什么

它说明僧伽罗语的网页写作不存在一个统一的语体标准。同一个国家的七家主流媒体，语体分布从7%铺到57%，中间没有明显的聚集点。

对做内容的人来说，这既是坏消息也是好消息。坏消息是没有现成的标准可抄，你得自己定。好消息是这个市场对语体的容忍度显然很宽——57%口语的日报活得好好的，说明读者不会因为语体不够正式就不看。

务实的做法是分层：产品参数、规格表、条款这类用书面体，因为它们要显得可靠；标题、导购正文、按钮文案用偏口语的一档，因为那是用户实际会打进搜索框的形态。

## 不懂这门语言也能判断一段字是哪一套

做这个统计的时候用的是词尾标记，而这套办法不需要懂僧伽罗语就能用。口语体的现在时动词有一个固定后缀，书面体则用另外几个固定词尾，两边的字符串完全不重叠。

把这次的逐标记计数摆出来，能看出两套系统各自的骨干：书面这边是系词139次、“有／已经”138次、过去式“是”65次、三单“做”11次；口语那边是不定式与祈使后缀114次、现在时后缀64次、否定11次、“要”6次。

用法很直接：拿一段目标语言的文本，把这十来个字符串各数一遍，两边的比值就是这段文本的语体位置。你不需要读懂一个字，就能判断一份译稿交上来的是书面体还是口语体。

这一招的适用范围比僧伽罗语宽。任何一门书面体和口语体在形态上分家的语言，都能找到类似的几个高频标记，做一次统计脚本长期可用。要注意的是标记得选那些不会出现在别的词里的字符串，否则会大量误计——这次那六个书面标记里有一个几乎没命中，就是因为它太短，被并进了别的词。

## 词那一层：条数赢的和意图赢的不是同一个

词汇上也有同样的分叉，而且这一层有个陷阱。取10组“书面词对口语词”做对照——比如“手机”这个概念，书面用一个梵语构词法造出来的正式词，口语直接用英语借词的本地转写。

按建议条数算，书面词81条、口语词50条，书面赢6组、口语赢1组、打平3组。光看条数，你会选书面词，而那是错的。

因为前面已经看过了：书面词拉出来的是作文题和PDF，口语词拉出来的是“手机 价格”“手机壳”“便宜的电脑”“电脑课程”。条数在书面词那边，购买意图在口语词那边。

## 这跟泰米尔语那篇分的不是同一条轴

这里要主动划一条界。本站写过泰米尔语的本族造词和音译词哪个该进词表，结论里也有“某一类词只能拉出查词义流量”这样的形状。两篇看着像，分的轴不一样。

泰米尔语那一篇分的是造词与借词——一个词是不是规范机构新造出来的，决定它有没有商业意图，判据是这个词是老词还是新造的。僧伽罗语这边分的是语域——两个词都是老词，都不是谁造出来的，分叉线是正式场合用哪个、日常用哪个。

两条轴会在结论上短暂重合，但落地动作不同：那边的动作是查这个词的年龄，这边的动作是查这个词属于哪个语域。想看另一条轴怎么走的，去泰米尔语的本族造词与音译词该收哪一个 (https://zhangwenbao.com/tamil-seo-native-coined-vs-loanword-keyword.html)那一篇，本文这一层就到这里。

## 完整查询两套都拉不出来，这一次测量是失败的

## 五组查询，书面一条、口语一条

词级的对照做完，下一步本来是句级——把书面体和口语体各造一句完整的商业查询，看谁能拉出建议。设计了五组：手机多少钱、哪个最好、在哪买、怎么用、有没有货，每组两个版本。

跑完的结果是：书面体五句加起来1条，口语体五句加起来1条。而且那两条都不是想要的东西——书面那条是关于信用卡怎么用的，口语那条后面跟着“英文意思是什么”。

十句里八句是零。这一轮什么也没测出来。

## 失败本身说明了什么

先排除一个可能：不是尺子坏了。同一个接口在词级上给僧伽罗语返回了189条建议，工作得很正常。

那就是查询本身的问题。最可能的解释有两个。一是这几句的措辞不是母语者真会打的说法——虽然语法都对，但真实查询的措辞往往更短、更省略；二是这门语言的长查询本身就少，用户习惯打两三个词而不是一整句。

这两个解释都合理，而本文没有办法区分它们。所以这一轮的正确结论是：这次测量失败了，在僧伽罗语上能可靠测到的只有词级，句级需要换一套完全不同的方法。

## 为什么要把失败写出来

因为省略它会给读者一个错误印象——好像这套方法什么都能测。实际上它有明确的适用边界，而边界只有在撞上去的时候才看得见。

还有一个更实际的理由。如果你照着本文的方法去做自己的市场，句级那一轮大概率也会拿到一堆零。提前知道这是方法的边界而不是市场的结论，能省下一整轮返工。

## 那长尾怎么办

词级测不到句级，不代表长尾没法做，只是数据源要换。三个替代来源，按可靠性排：

- 自己站的站内搜索日志——只要有一点自然流量，用户在你站内打的完整句子就是最真实的样本，而且不经过任何第三方口径

- 本地社群里用户的原话，尤其是求推荐和抱怨类的帖子，那里的措辞最接近真实查询

- 把词级已经验活的那批词两两组合，做成短语去试，比自己造整句的命中率高得多

小语种的长尾门槛本来就跟英语市场不是一套算法，这一层本站在小语种长尾内容在AI时代还值不值得做 (https://zhangwenbao.com/minor-language-qa-long-tail-content-value-ai-era.html)里单独算过账，可以对照着看。

## 这个缺口值多少钱？

## 竞争密度实际上是零

先说这个缺口最诱人的一面。20家本地头部公司，僧伽罗语正文合计56个字符。这意味着任何一个认真写僧伽罗语内容的站，在这门语言的商业查询上没有本地对手。

不是“对手很弱”，是“对手不在场”。这种局面在成熟市场里几乎见不到，通常只出现在一门语言刚刚开始上网的阶段——而僧伽罗语显然不是，它的搜索侧已经很成熟了。

## 但天花板也要老实算

诱人归诱人，账要算完。这个市场的天花板由三件事决定，每一件都不大：人口规模两千多万、人均线上消费能力有限、跨境支付与物流的可用性受外汇管制影响。

所以正确的预期不是“找到一个金矿”，是“找到一个没人抢的小矿”。保哥的看法是它值得做，但不值得为它调整整个出海排期的优先级——这类语言该摆在投入、观察还是冻结哪一档，本站在小语种优先级重排那一年的复盘 (https://zhangwenbao.com/minor-language-seo-2026-portfolio-review-invest-freeze.html)里有一份现成的分档表可以套。竞争为零最大的价值不是流量总量，是获客成本——同样的排名，在这里要花的力气可能只有成熟市场的十分之一。

## 三种入场姿势

按投入从小到大排：

- 最小的一种：只把品类页和产品页做僧伽罗语版本，其余全部保留英语。成本是一份词表加一批页面翻译，两三周能上线

- 中等的一种：品类页加一批解决具体问题的内容页，选题从那些能拉出建议的口语词里挑，避开作文题那一类

- 最大的一种：整站双语，配上正确的跨语言声明和语言切换入口。只有当前两种已经跑出数据、证明这门语言真能带来转化之后才做

多数团队应该停在第一种或第二种。第三种的边际收益在这个规模的市场里通常撑不起维护成本，而且双语站的长期负担——两份内容日历、两份审校排期、两份客服话术——不出现在首次投入的账里。

## 这个缺口还能存在多久

做决策前值得问一句：这个位置会不会很快被本地公司自己补上。

从数据看，短期内不太会。20家里14家是绝对零，说明这不是某几家落后，是整个行业的默认做法；而默认做法的改变通常需要一个外部触发——某家公司先做了并且拿到了明显收益，同行才会跟。

更实际的一层是组织原因。这些公司的市场部工作语言是英语，建站外包给的开发商也在英语环境里，做本地语言版本意味着要新增一条内容生产线和一批审校，这件事在预算表上没有对应的科目。这不是一个技术难题，是一个没人提案的问题，而没人提案的问题可以存在很多年。

当然也要留个观察点：如果哪天本地某家头部电商开始铺本地语言内容，那这个窗口的关闭会很快，因为它有品牌和流量的双重优势。所以入场的话别拖太久，也别把这当成一个永久红利。

## 最小验证怎么做

不要一上来铺全站。选三到五个页面做僧伽罗语版本，上线之后观察三件事：有没有被收录、有没有僧伽罗语查询带来的展现、展现之后的点击率跟英语版本比是高还是低。

观察周期给三个月。这个市场的抓取频率不高，一个月的数据不足以判断。

验证期间有个细节容易被忽略：确认语言声明写对了，否则你观察到的“没有效果”可能只是搜索引擎不知道这几个页面是给谁看的。前面那家国有银行就是这么把整套投入浪费掉的。

## 什么时候该判断这事不成立

三个月之后，如果这三到五个页面收录正常、语言声明也确认写对了，但僧伽罗语查询带来的展现依然接近零，那就该停。

停下来的时候要区分两种情况。一种是这门语言在你这个品类上确实没有商业查询——那就把僧伽罗语的投入砍掉，专心做英语版本。另一种是你选的词全落在了作文题那一类上——那就换一批词再试一轮，别急着否定整个市场。

区分它们的办法是回到词级：把你实际用的那批词逐个查一遍建议，看拉出来的是价格和品牌，还是作文和PDF。选词错了和市场不成立，在流量数据上长得一模一样，只有回到词级才分得开。

## 上线之前，哪几项能自己跑完？

## 供给侧三项，一个下午

第一项，列出目标市场十到二十家本地头部公司的网站，抓正文，数本地文字的字符占比。这一项回答“有没有人在这门语言上跟我竞争”。

第二项，同样的方法抓五到十家本地新闻媒体。这一项是排除项，回答“这门语言在网上到底活不活”。缺了它，第一项的零会被误读成“这门语言没人用”。

第三项，把这两批站的语言声明记下来。这一项通常会顺手捡到一批可以直接超越同行的地方。

## 需求侧两项，半天

第一项，24个概念分三组查建议，算交易除以实体的比值。高于0.8按正常市场做，0.3到0.8只做还活着的那几个交易词，低于0.1只做品类页。

第二项，把建议的原文逐条读一遍，看里面有没有品牌名、价格、型号。这一项比第一项更重要，因为条数可以是满的而内容全是查词义——僧伽罗语这次就是这样。

## 声明层两项，十分钟

一是打开自己站的目标语言页面，确认语言声明不是空的、不是建站模板留下的英语默认值、也不是把国家代码填成了语言代码。

二是把用到的每一个语言代码拿去注册表里反查一遍。两位小写代码的重码率高得吓人，一个字母之差就会指到另一门真实存在的语言上去。

## 哪些相邻的问题不归这一层管

做僧伽罗语时会一起冒出来但解法不在本文这一层的，主要有四类：

- 辅音连写与字素簇导致的字段长度算错——那是字符层的问题，跟你写什么词无关

- 字体加载与行高——僧伽罗文的字形高度和拉丁文差得远，属于前端排版问题

- 斯里兰卡的泰米尔语那一半怎么办——那是另一门语言的完整决策，要单独走一遍本文的两侧测量

- 这门语言的内容能不能被AI答案引用到——那是低资源语言在生成式检索里的通病，本站在AI检索里的语言偏向与来源审计 (https://zhangwenbao.com/ai-search-language-bias-low-resource-citation-source-audit.html)里单独测过，跟商业词有没有量是两条线

## 开头那家储能站后来怎么做的

他们重新跑了一遍两侧测量，一个下午。看到需求侧0.86和供给侧56个字符这两个数并排放在一起，会议纪要上“不做僧伽罗语”那一行当场改掉了。

实际动作走的是最小的那一种：把四个主力产品页和两个品类页做了僧伽罗语版本，词表从能拉出建议的那批口语词里选，语言声明和跨语言声明按规范写全，其余页面保持英语不动。总投入不到两周。

三个月之后的数据不算惊艳，展现量在整站里的占比是个位数。但那批词的排名位置几乎全在首屏，而这在英语那一侧是这家公司花了一年半也没拿到的。同样的钱，买到的位置差了一个量级——这就是竞争为零的实际含义。

## 常见问题解答

## 本地头部公司都不做本地语言，是不是说明他们试过没效果？

大概率不是。这类默认状态更常见的成因是路径依赖：网站最初由英语环境里的开发商搭起来，管理层和市场部的工作语言是英语，对外沟通材料也是英语，于是网站自然就是英语的，从来没有人正式提案过要不要做本地语言版本。判断是“试过没效果”还是“从没试过”，有个便宜的办法——看这些站有没有语言切换入口的残留、有没有本地语言的旧页面还挂在子目录里。如果连痕迹都没有，那基本可以确定是没试过。真正试过又撤掉的站，通常会留下断链或者重定向。

## 需求侧的搜索建议里全是学生作文题，这样的查询池还有商业价值吗？

有，但要挑着看。作文题那一批确实没有商业价值，问题在于它们集中出现在某一类词上——那些用正式构词法造出来的书面词。换成日常口语里在用的说法，同一个概念拉出来的建议就变成了价格、型号、配件、便宜的某某。所以正确的动作不是放弃这门语言，是换一批词。本文里“鞋”这个词就是个好例子，它是日常老词而不是正式构词，拉出来的建议是种类、男式女式、价格、尺码、设计，全是商业意图。判断一个词属于哪一类，最快的办法就是把它的建议打出来读一遍。

## 交易存活率这个比值，能不能拿去跟英语或者中文比？

可以比，但要知道比的是什么。这个比值衡量的是一门语言在搜索里能承接的任务范围，不是它的流量规模。英语和中文的比值必然接近1，因为这两门语言什么场景都覆盖，比出来只会得到“它们是完整的”这个已知结论。真正有用的比较发生在小语种之间，或者同一门语言的不同时间点之间——后者尤其值得做，如果一门语言的这个比值在两年里从0.3涨到0.6，说明它的电商生态正在成型，那是个很强的入场信号。

## 书面体和口语体要不要做成两套页面？

不要。两套页面会带来重复内容判定的风险，而且维护成本翻倍，收益却很有限——因为这两套形态是同一门语言，搜索引擎在语义层面能把它们关联起来。务实的做法是一套页面里分层：标题和小标题用偏口语的形态，因为那是用户打进搜索框的样子；正文的说明性段落、参数表、条款用书面体，因为那是读者期待的正式度。另外把口语形态的几个关键说法自然地放进正文出现一次，让页面在两种形态上都有覆盖，这比做两套页面划算得多。

## 怎么判断母语者给的词是书面体还是口语体？

不要问“这个词对不对”，母语者会说对，因为书面词确实是对的。要换个问法：如果你在手机上给朋友发消息说这件事，你会打哪个词。这个问法能把书面体过滤掉，因为没有人在聊天里用正式书面形态。第二个办法是直接看数据，把两个候选词各查一遍建议，读一读拉出来的内容，有价格和品牌的那个就是用户在打的那个。两个办法配合用最稳，母语者负责给候选，数据负责裁决。

## 斯里兰卡还有泰米尔语，两门语言要不要一起做？

先做一门，跑出数据再说。两门语言对应的是两个不同的社群、两套词表、两批审校，边际成本并不比做两个国家低多少。选哪一门取决于你的品类和目标客群的分布，不是取决于人口比例。另外要提醒的是，泰米尔语不只在斯里兰卡使用，它跨着好几个国家，而不同国家的用词分叉相当明显，所以做泰米尔语这个决定的复杂度比做僧伽罗语高一档——僧伽罗语只有一个市场，这反而是它的优点，词表做一次就够了。

## 语言代码这种低级错误，有没有能自动查出来的办法？

有，而且很简单。把站上所有出现的语言代码提取出来去重，逐个丢进语言子标签注册表查一遍，把查到的语言名字打印出来人工扫一眼。这个脚本十几行就能写完，跑一次几秒钟。关键在于最后那一步必须是人看语言名字，而不是程序判断代码格式是否合法——那家国有银行写的sn格式完全合法，任何格式校验都会放行，只有把“绍纳语”三个字打印出来才会有人发现不对。这个检查建议加进上线前的固定清单，成本几乎为零。

## 权威参考资料



## 老挝语的关键词表在第九个词上断掉，那8个购物动作词一共只拉回来一条建议

- URL：https://zhangwenbao.com/lao-seo-transactional-keyword-collapse.html
- 分类：小语种SEO
- 发布：2026-08-02  |  更新：2026-08-02
- 摘要：老挝语的实体品类词能拉满建议，交易动作词八个里七个是零。给出五门语言的对照数据、交易存活率的算法，以及老挝文与泰文码点位移的可用边界和五个会塌的字符。
- 关键词：关键词研究,跨境电商,多语言SEO,小语种SEO

> **TLDR**：摘要：把24个电商概念分成实体品类、交易动作、抽象概念三组，用同一套说法在五门东南亚语言上各查一遍搜索建议，老挝语这一列的塌法很特别——手机、摩托车、鞋能拉满10条，而下单、送货、退货、付款、保修、批发这些购物动作8个词加起来只回来1条。小语种在搜索里不是整体变薄，是按词类分层往下塌，交易动作词最先倒。本文给出五门语言的对照数字、一个五分钟能自己跑一遍的比值，以及老挝文和泰文那两个码点块96.14%逐位对齐这件事能拿来做什么、不能拿来做什么。

> 
摘要：把24个电商概念分成实体品类、交易动作、抽象概念三组，用同一套说法在五门东南亚语言上各查一遍搜索建议，老挝语这一列的塌法很特别——手机、摩托车、鞋能拉满10条，而下单、送货、退货、付款、保修、批发这些购物动作8个词加起来只回来1条。小语种在搜索里不是整体变薄，是按词类分层往下塌，交易动作词最先倒。本文给出五门语言的对照数字、一个五分钟能自己跑一遍的比值，以及老挝文和泰文那两个码点块96.14%逐位对齐这件事能拿来做什么、不能拿来做什么。

去年有个做电动工具的外贸站找过来，问题描述得很干脆：老挝语版本上线快三个月，收录正常，也确实有自然流量，可进来的词全挤在一个地方——全是品类名加型号，没有一条带着购买动作。

团队的第一反应是内容写得不够，于是补了一批导购型的文章，标题都是“怎么挑”“哪款好”“买之前要看什么”这类。又过了两个月，那批页面收录了，展现量接近于零。

后来发现问题不在页面上。是那些词在这门语言的搜索里，压根就没有。

## 老挝语的关键词表，为什么会在第九个词上断掉？

## 先把问题拆成两半

“这门语言没数据”是个太笼统的说法，笼统到没法排期。真要动手，第一步是把它拆成互不重叠的两半：是供给侧的问题——本地没人写这门语言的网页；还是需求侧的问题——本地人不用这门语言搜这类东西。

这两半的解法完全相反。供给侧稀薄意味着机会，你去写就能占位；需求侧稀薄意味着陷阱，你写得再好也没人搜。把两者混成一句“老挝语不好做”，排期表上就只能填一个模糊的低优先级，什么也决定不了。

所以这次的测量顺序是先排除供给侧，再去量需求侧。这个顺序不能反过来，因为需求侧的数据更难解释，先把供给侧的答案握在手里，解释起来才有参照。

## 24个概念，分三类，五门语言各查一遍

需求侧那把尺子用的是搜索建议。选它有三个理由：它是免费的、实时的、按地区取的；它反映的是真实被打进搜索框的串而不是工具的估算模型；最要紧的是，它在关键词工具完全没有数据的语言上依然会返回东西。

词表这样搭：取24个电商场景里绕不开的概念，平均分成三组。分组这一步是整个实验的关键，如果只是随便抓一把词去查，得到的会是一个笼统的“数量偏少”，而分组之后才能看出零落在哪一列。

- 实体品类词——电话、摩托车、衣服、冰箱、电脑、鞋、电视、手表，也就是用户想买的东西本身

- 交易动作词——网购、下单、送货、退货、付款、保修、折扣、批发，也就是购买流程里的那些动作

- 抽象概念词——价格、质量、评测、对比、怎么选、最好的、资料、服务，也就是决策阶段的修饰语

然后把这24个概念在老挝语、泰语、高棉语、缅甸语、僧伽罗语上各写一遍本族说法，逐个查建议，记录每个词返回多少条。泰语放进来是当参照系用的——它是这一带体量最大、数据最全的那门语言，如果连泰语都出现大面积零，那说明是尺子有问题而不是语言有问题。

## 为什么不用关键词工具的搜索量

主流工具在这几门语言上要么没有条目，要么给出一个明显是插值出来的数。更麻烦的是它们经常把整门语言的量合并报给一个更大的语言代码，看上去有数，实际上那个数不属于这门语言。这一类数据陷阱本站在小语种关键词工具查不到数据时的几种替代做法 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)里拆过一遍，这里不重复。

搜索建议的短板同样要说清楚：它给不出绝对量，只能回答“这个词在这门语言的查询池里有没有存在感”。但这次要回答的恰好就是这个问题，所以它够用。

## 本文谈什么、不谈什么

本文谈的是老挝语这一门语言在搜索侧的词类分布，以及由它推出来的内容取舍。不谈老挝文没有词间空格该怎么分词——那件事跟泰语、高棉语、缅甸语共用同一套机制，本站已经在泰语没有空格该怎么切词 (https://zhangwenbao.com/thai-seo-no-spaces-word-segmentation-keyword.html)那一篇里连词典型断词器的工作方式一起讲完了，老挝语这边只是换了个语言名字，机制一模一样。

也不谈引擎那半边。老挝市场的搜索入口结构、本地平台的份额，这些属于平台层，跟语言本身无关。

## 供给侧先排除掉：老挝的网站干净得出乎意料

## 开工前的预期是怎么写下的

动手之前，保哥先把预期写进了一个文件。这一步是从上一批开始养成的习惯，理由很实在——不写下来，跑完之后人会自动把结论改成“我早就知道”，那样就学不到任何东西。

关于供给侧，写下的是：老挝的新闻站正文里会混进可观的泰文，占比超过5%。理由听起来很硬——老挝和泰国之间的媒体渗透是几十年的事，老挝人普遍能读泰文，本地媒体转载泰国内容的成本几乎是零，那么直接把泰文段落贴进页面是最省事的做法。

## 28个站抓到15个可用

站点清单按三类凑：政府与机构、新闻媒体、商业与电商。总共28个域名，实际能返回200的15个，其中文字量够统计的13个。掉线的那13个里，多数是域名解析失败或者证书过期——这本身就是这个市场的一个侧写。

统计的时候只数正文容器里的字符，也就是p、li、td、h1到h3这几个标签里的内容，不数导航和页脚。这一条是上一批用血换来的：查一个页面到底用什么文字，只看首页标题会得出完全相反的结论，必须抽正文段落。

## 48821个老挝文字符里，泰文只有1个

结果是这样的：13个站的正文里，老挝文字符合计48821个，泰文字符合计1个。占比0.00%。

逐站看也一样干净。老挝日报7627个老挝文字符、0个泰文；国家通讯社4242个、0个；Lao Phattana 10402个、0个；财政部3821个、0个。唯一那1个泰文字符出现在工贸部站上，孤零零一个，大概率是复制粘贴带进来的。

预期错了，而且错得很彻底。老挝的网站不但没有大面积混排泰文，它们比多数小语种市场的站点都要纯。

## 这个0.00%该怎么读

第一层意思是：老挝语的网页内容是真实存在的，有人在持续生产，而且生产者没有偷懒去贴邻国的现成内容。这一点很重要，它把“这门语言在网上没人用”这个假设直接排除掉了。

第二层意思更要紧：既然供给侧没问题，那么后面如果量出需求侧的异常，那个异常就是真的，不能再用“因为没人写所以没人搜”来解释。先排除一半，剩下那一半的结论才站得住。

顺带说一句，这个干净程度也意味着老挝语的语料是可以直接拿来用的。你抓20个本地站做词频统计，不需要先做语言过滤，抓到什么就是什么。多数小语种市场没这个待遇。

## 顺带记一个坑：编码探测的顺序

抓非拉丁语种的站有个反复咬人的坑，这次是提前防住的。常见的写法是让请求库去自动猜编码，猜完再解码。问题在于自动猜编码这件事在单字节和多字节之间会翻车，它可能把一段正常的UTF-8猜成某种单字节编码，然后解出一串看着很有规律的乱码。

规律性乱码最危险的地方在于，它不像乱码。它看上去像另一门语言的字符，而你会信。上一批就差点因为这个得出“某地的网站用的是另一套字母”这种完全说得通、但完全错误的结论。

正确的顺序是写死的：先看HTTP响应头里的charset，没有再看HTML里的meta声明，再没有就试UTF-8解一遍看会不会报错，四步都不行才轮到自动猜。解完之后按码点判断每个字符属于哪套书写系统，判据用的是Unicode的书写系统属性定义 (https://www.unicode.org/reports/tr24/)，自己写统计脚本照它来就行。这次15个可用站全部在第一步就拿到了正确编码，一次都没走到猜那一步。

## 但另一件事塌了：这些站没告诉搜索引擎自己是老挝语的

抓站的时候顺手记了每个页面的语言声明，这是本来没打算测的一项，结果它自己跳了出来。15个可用站里，把lang写成lo或者lo-LA的只有6个。

声明值 | 站数 | 这个值是什么意思 | 

lo / lo-LA | 6 | 正确，老挝语 | 

en / en-US | 6 | 声明成了英语，其中包括国家电视台和老挝日报 | 

zxx | 1 | 财政部。这个代码的含义是“无语言内容” | 

la | 1 | BCEL银行。la是拉丁语，老挝语是lo | 

缺失 | 1 | 万象时报 | 

财政部那个zxx值得单独说两句。这三个值都能在IANA语言子标签注册表 (https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry)里逐个查到：lo是老挝语、la是拉丁语、zxx的含义是无语言内容。最后这个代码在标准里是留给那些确实没有语言内容的资源用的，比如纯乐器音频、纯符号图表。一个整站都是老挝文公文的财政部网站声明自己“无语言内容”，这大概率是某个建站模板的默认值没人改过。

BCEL那个la更典型，它是把国家代码当成语言代码填了。老挝的国家代码是LA，语言代码是lo，两个字母都对，组合起来完全错。这类错误的特点是它不报错，页面照常显示，只有机器在读的时候才知道你说自己是什么语言。本站在小语种结构化数据里的语言与地区字段该怎么写 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)里讲过这一层的写法规范，那边讲的是自己的站怎么写对，这里看到的是一整个市场普遍写错的样子。

## 24个词查下来，零落在哪一列？

## 三列的数字

供给侧排除掉之后，需求侧的数字就可以直接读了。老挝语这24个概念查完，三列的建议总数是这样的：

组别 | 8个词的建议总数 | 平均每词 | 一条建议都没有的词 | 

实体品类词 | 43 | 5.4 | 1个 | 

交易动作词 | 1 | 0.1 | 7个 | 

抽象概念词 | 16 | 2.0 | 5个 | 

第一眼看过去，实体那一列是活的。电话拉满10条，摩托车10条，衣服10条，鞋9条。这已经足够支撑一批品类落地页了。

第二列是1。八个概念——网购、下单、送货、退货、付款、保修、折扣、批发——加起来返回1条建议。

## 唯一活下来的那条长什么样

那一条是折扣拉出来的，内容是折扣加一个外卖平台的名字。也就是说，老挝语的交易动作词里，唯一有查询量的那个用法，指向的是一个外国公司在当地运营的App的优惠活动。

剩下七个词是硬零。不是“数据很少”，是接口返回了一个空列表。同样这八个概念换成泰语去查，返回71条，一个零都没有。

这里要说清楚一件事：零建议不等于零搜索量。搜索建议是有门槛的，一个词得被搜到某个量级才会进补全库。所以这组数据的准确读法是——这八个动作在老挝语里的查询量，全部低于建议库的收录门槛。它可能是零，也可能是很小的一个数，但无论如何，小到你没法围绕它做内容规划。

## 抽象概念词那一列同样惨

第三列16条，看着比第二列好，其实结构很畸形。这16条里有10条来自“价格”一个词，剩下6条分给“资料”和“服务”。而评测、对比、怎么选、最好的、质量这五个词，全是零。

这五个词恰好就是导购内容的骨架。开头那家电动工具站补的那批“怎么挑”“哪款好”的文章，标题里的核心词就落在这五个零上面。他们不是没写好，是写了一批在这门语言里不存在的查询。

而“价格”那10条也不是给电商用的。逐条看下来，全部围绕黄金价格和油价——“今日金价2026”“今日金价2025”“1巴的金价”“今日油价2026”。这是一个把价格这个词垄断掉的强势话题，任何品类想在这个词上分一杯羹都很难。

## 实体品类词后面跟着的是拉丁字母

把实体那一列的43条建议全部打出来看，会看到另一个形状：43条里有40条含拉丁字母，而且那些拉丁字母几乎全是品牌名。

统计一下出现频次：wave出现9次，samsung 3次，oppo 2次，nike 2次，然后是iphone、vivo、infinix、huawei、tecno、honor、honda、ford、toshiba、adidas、polo各1次。

所以老挝语在这些查询里承担的角色非常清楚：它出现在品类词那一格，紧挨着它的是拉丁字母写的品牌名和型号。用老挝文写“摩托车”，后面跟着的是wave 110、wave 100这些本田车型的编号。用老挝文写“电话”，后面跟着oppo、samsung、iphone。

这个形状本身是有用的。它告诉你老挝语页面上的标题该怎么组：本地文字的品类词加拉丁原文的品牌型号，中间不要试图翻译。品牌名转写这件事在多数市场都要权衡，本站在小语种市场里品牌名该转写还是保留原文 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)里给过判断框架，而老挝语这边的数据把答案直接摆出来了——用户就是在打拉丁字母。

## 这是老挝语独有的，还是所有小语种都这样？

## 加四门语言进来

一门语言的数据说明不了什么。同一批24个概念，按各自的本族说法在泰语、高棉语、缅甸语、僧伽罗语上重跑一遍，五门语言并排放，形状才出得来。

语言 | 实体8词 | 交易8词 | 抽象8词 | 合计 | 零建议词 | 交易÷实体 | 

泰语 | 80 | 71 | 80 | 231 | 0/24 | 0.89 | 

僧伽罗语 | 66 | 57 | 66 | 189 | 3/24 | 0.86 | 

缅甸语 | 70 | 22 | 28 | 120 | 11/24 | 0.31 | 

高棉语 | 61 | 6 | 34 | 101 | 11/24 | 0.10 | 

老挝语 | 43 | 1 | 16 | 60 | 13/24 | 0.02 | 

竖着看合计那一列，是一条从231掉到60的下坡，符合直觉——语言体量越小，数据越少。

横着看才有意思。实体那一列从80掉到43，掉了不到一半。交易那一列从71掉到1，掉了98%。两列的衰减速度差了一个数量级。

## 交易存活率这个比值

上表最后那一列就是交易除以实体的比值。这个比值不受语言体量影响，因为分子分母同时缩放，所以它能横向比。翻译成人话是这样的：

- 泰语0.89、僧伽罗语0.86——这门语言能承接整条购买漏斗

- 缅甸语0.31——上半截可以，下半截要打折

- 高棉语0.10——基本只剩漏斗顶端

- 老挝语0.02——只有品类词那一格

五个数字排出来是一条很陡的曲线，而且中间有个明显的断层：泰语和僧伽罗语挤在0.86到0.89，然后直接掉到缅甸语的0.31，中间是空的。

## 曲线的形状：不是整体变薄，是分层塌陷

这条曲线否掉了一个很流行的心智模型。多数人对小语种的想象是“数据按比例变少”——大语种一个词1000的量，小语种同一个词可能是10，但结构是一样的，你按比例缩小预期就行。

实测出来不是这样。小语种是按词类分层往下塌的，交易动作词最先倒，抽象概念词其次，实体品类词最后倒。塌到老挝语这个位置，你手上剩下的不是一个缩小版的关键词表，是一个只有名词、没有动词的关键词表。

这个区别在排期上是致命的。按比例缩小的心智模型会得出“老挝语值得做一批小规模内容”的结论；分层塌陷的模型会得出“老挝语只能做品类页，导购内容一篇都别写”的结论。后者才对。

## 缅甸语和高棉语落在中间那一档

中间两档反而是最需要判断力的。缅甸语0.31，意味着八个交易动作里大概有两三个还活着——实测下来是送货和保修各10条、批发2条，其余归零。高棉语0.10，活着的只有保修6条。

落在中间档的语言，正确做法不是一刀切，是把那几个还活着的词挑出来单独做。缅甸语的“送货”有10条建议，那就值得为配送时效单独做一个页面；“评测”是零，那就别做评测页。这个比值的用法不是给语言打分，是给这门语言画出一条“做到哪里为止”的线。

顺带一提，缅甸语那边还有一层独立的历史包袱要先处理干净，跟这条曲线无关但会先撞上——那门语言在过去十来年换过一整套字节编码，旧内容和新内容互相打不开，细节在缅甸语网页的编码迁移与字节裂缝 (https://zhangwenbao.com/burmese-seo-zawgyi-unicode-byte-split.html)那一篇里。

## 这条曲线能拿来做什么

最直接的用法是替代拍脑袋的语言优先级。给一门新语言排期之前，花半小时把24个词查一遍，算出这个比值，你得到的是一条比人口数、比GDP、比“这个市场热不热”都更贴近实际的判据。

第二个用法是给客户看。“这门语言不值得做导购内容”这句话说出来像是偷懒，把八个词全是零的截图摆上去，就不用再解释了。这条曲线最值钱的地方不是它的精度，是它便宜到你可以在提案阶段就跑一遍。

## 内容总量这把尺子，为什么会给出错误排序？

## 五门语言的条目数

衡量一门语言值不值得做，最常见的做法是量它的内容供给密度——本地有多少网页、有多少人在写。这个思路本站在小语种优先级该怎么算这笔账 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)里给过手工估算的办法，也一直好用。这次顺手拿同一批语言验了一下，结果不太好看。

选一个公开、可复现、任何人五分钟能自己查到的量：维基百科各语言版本的条目数与活跃编辑人数清单 (https://meta.wikimedia.org/wiki/List_of_Wikipedias)。

语言 | 维基条目数 | 活跃编辑 | 交易存活率 | 

泰语 | 185785 | 2828 | 0.89 | 

缅甸语 | 111538 | 300 | 0.31 | 

僧伽罗语 | 25614 | 159 | 0.86 | 

高棉语 | 12155 | 137 | 0.10 | 

老挝语 | 5594 | 61 | 0.02 | 

## 缅甸语条目多四倍，存活率只有三分之一

把两列的排序并排看，第二名和第三名换了位置，而且换得很凶。

按内容总量排，缅甸语第二、僧伽罗语第三，缅甸语的条目数是僧伽罗语的4.4倍。按交易存活率排，僧伽罗语0.86排第二、缅甸语0.31排第三，僧伽罗语是缅甸语的2.8倍。僧伽罗语用不到缅甸语四分之一的内容量，换到了将近三倍的交易词覆盖。

这不是测量误差能解释的差距。两把尺子量的根本是不同的东西：内容总量量的是“这门语言里有多少字被写出来”，交易存活率量的是“这门语言被用来完成什么类型的任务”。

缅甸语有一亿多字被写出来，可写的大多不是商业内容；僧伽罗语字少，但用它的人会用它买东西。做电商SEO，你要的是后者。

## 那内容供给密度这把尺子还要不要用

要，只是要知道它回答的是哪个问题。内容供给密度回答的是“我进去之后有没有竞争对手、我的内容能不能被看见”；交易存活率回答的是“我做的这类内容有没有人搜”。

两个问题都得回答，而且答案组合起来才有意义：

- 供给低、存活率高——最好的格子，有需求没竞争，先做

- 供给高、存活率高——正常市场，按常规打法算投产比

- 供给低、存活率低——最容易被误判成机会的格子，实际上是没人搜也没人写，老挝语的交易词就落在这里

- 供给高、存活率低——通常意味着这门语言在网上做的是别的事，比如新闻和教育，不是买卖

第三格是这次最想提醒的。看到“竞争对手少”就冲进去，是小语种最常见的翻车方式。竞争少和需求少，在数据上长得几乎一样，区分它们的唯一办法是把需求单独量一次。

## 自己跑一遍要多久

这套测量不需要任何付费工具。找一个母语者或者一份靠谱的双语词表，把24个概念翻成目标语言，逐个丢进搜索框看下拉补全出来几条，记在表格里。一个人手工做完24个词大概20分钟，五门语言并排做一遍不到两小时。

有三个细节会影响结果，值得先说：第一，一定要用目标语言的界面语言参数，不然补全库会切到别的语言；第二，同一个词多查一次会有缓存，最好换个时间再验一遍；第三，词一定要是母语者真会打的说法，不能拿词典里的正式对应词硬填，这一条下面还要专门说。

## 尺子失效了两次，换出来的东西比原计划硬

## 第一次：整条判定看不见的那个泰文词

开工时还有另一个假设——既然老挝人普遍能读泰文，那么老挝语的搜索建议里应该会混进泰文的查询。这个假设设的阈值是20%。

第一版的判定逻辑是：把每条建议整体判一次，看它主要由哪套文字构成，然后数有多少条被判成泰文。跑完的结果是0条。43条建议，一条泰文都没有。

看上去假设被否掉了。但把43条原文逐条读一遍的时候，有一条不对劲：

> ລາຄາຄໍາ ມື້ນີ້ 2025 ล่าสุด

前面是老挝文的“今日金价2025”，最后那个词是泰文，意思是“最新”。这条查询是老挝文和泰文混着打的，可因为老挝文字符占绝大多数，整条判定把它归成了老挝语。尺子没坏，是刻度太粗——按整条判，词级的混入永远看不见。

换成逐字符检测之后，这条立刻浮出来了。虽然只有一条，但它证明了这类混合查询是真实存在的，只是量小到用整条判定的方式抓不住。

## 第二次：地区参数根本没生效

第二把尺子失效得更彻底。为了验证“老挝人是不是改用泰语搜”，保哥在老挝地区参数下，用泰文和英文分别查了那八个交易动作词。结果很漂亮：泰文71条、英文80条，一个零都没有，而老挝文是1条。

差点就写成结论了。幸好多看了一眼建议的内容。

泰文那一组返回的是“从泰国寄东西到新加坡”“从新加坡寄回泰国”“某电商平台退货”这类——全是泰国本地用户的查询。英文那一组返回的是几家新加坡餐饮品牌、新加坡电信公司、新加坡的一部支付服务法案——全是新加坡的。

没有一条跟老挝有关。地区参数在这里完全没起作用，接口返回的是这门语言的主市场建议，跟指定的国家无关。这已经是这个参数第二次在小语种上失效了，上一次是它分不出同一门语言的四个使用国。

## 所以“老挝人改用泰语搜”这句话保哥不能说

这是本文最想说清楚的一条方法学：这套测量测不出用户在某个国家用什么语言搜，它只能测出某个词在某门语言的查询池里有没有存在感。

两者听起来很近，其实差得很远。前者是关于人的行为，后者是关于语言的数据分布。手上的证据只支持后者，那就只说后者。至于老挝用户在搜不到老挝语的“退货”时到底切去了哪门语言，没有证据，那一段就不写。

诚实地留个洞，比填一个说得通的猜测要好。因为那个猜测太顺了，读者会信，然后拿去做决策。

## 换尺子之后能回答的问题变了

有意思的是，尺子失效之后剩下的那个问题，反而比原来的问题更有用。

原来的问题是“老挝人用什么语言搜”，就算答出来，落地动作也很模糊——难道要建一个泰语版本去接老挝流量？地区定位、货币、配送全都对不上。

换出来的问题是“老挝语的查询池里哪些词是活的”，这个问题的落地动作极其明确：活的词做页面，死的词一个字都别写。这一条不依赖任何关于用户行为的推测，纯粹是数据分布。

上一批也是尺子失效之后换出了更硬的结论。连着两次之后，基本可以把它当成一条经验：尺子失效不是坏消息，是换尺子的信号，而换出来的那把往往比原计划的更贴题。原因大概是，第一把尺子通常是照着你的假设设计的，它一失效，你就被迫去看数据本身长什么样。

## 老挝文和泰文的码点，其实是逐位对齐的

## 两个块并排放

既然泰语的数据这么全、老挝语这么空，一个很自然的念头是：能不能拿泰语那边的关键词数据反推老挝语的候选词。

这个念头能不能落地，取决于两套文字之间有没有可计算的对应关系。答案有点出人意料。

泰文在Unicode里占U+0E00到U+0E7F这一段 (https://www.unicode.org/charts/PDF/U0E00.pdf)，老挝文紧接着占U+0E80到U+0EFF (https://www.unicode.org/charts/PDF/U0E80.pdf)。两个块相邻，各128个码位。当年编码这两套文字的时候，是照着两边字母表的对应关系逐位排的，也就是说理论上偏移恒定，都是0x80。

原本的预期是这个对应关系已经被历史磨得七零八落——老挝语在20世纪做过拼写简化，字母比泰文少，中间应该到处是缺口。

## 128个偏移位的对账

128个偏移位逐位算了一遍，四种情形的分布是这样的：

- 两边都有字符的76个——这些位可以互相位移

- 只有泰文有的11个——老挝文这边是空洞

- 只有老挝文有的7个——泰文那边是空洞

- 两边都空的34个——不影响

泰文块已分配87个码位，老挝文块83个，两边都有的76个。对齐率87.4%，比预期高出一大截。

只有泰文有的那11个里，有几个是泰语自己废弃的古字母，有几个是泰语专用的符号，还有一个是泰铢的货币符号。也就是说，缺口不是随机分布的，它们集中在“泰语有而老挝语确实不需要”的位置上。

## 真实语料位移之后，96.14%落得下去

码表对齐是一回事，真实文本能不能位移是另一回事。把前面抓下来的那48835个老挝文字符逐个减0x80，看落点是不是泰文的已分配码位：

- 落在泰文已分配位的：46948个，占96.14%

- 落进空洞的：1887个，占3.86%

而且塌陷不是均匀分布的。1887个失败里，5个字符占了99%，其中光是那个叫MAI KON的元音符号 (https://www.compart.com/en/unicode/U+0EBB)就占了六成：

字符 | 码位 | 出现次数 | 占全部塌陷的比例 | 

ົ | U+0EBB | 1169 | 62% | 

ຽ | U+0EBD | 354 | 19% | 

ໜ | U+0EDC | 147 | 8% | 

ຼ | U+0EBC | 110 | 6% | 

ໝ | U+0EDD | 107 | 6% | 

单独给这5个字符写一张映射表，位移的覆盖率就能从96.14%推到接近100%。这是一天之内能做完的工作量，而它换来的是整套泰语关键词数据的可用性。

## 位移出来的串长什么样

抽几条真实的老挝语搜索建议做位移，看结果：

老挝文原串 | 位移之后 | 结果如何 | 

ເສື້ອໄຫມລາວ | เสื้อไหมลาว | 完全合法的泰文，意思是老挝丝绸衬衫 | 

ໂທລະສັບ | โทละสับ | 泰语的电话是 โทรศัพท์，音近但拼法不同 | 

ຕູ້ເຢັນ | ตู้เยัน | 泰语的冰箱是 ตู้เย็น，只差一个符号 | 

ສ່ວນຫຼຸດ | ส่วนห□ุด | 中间那个字符落进空洞，塌了 | 

第一条最有意思——位移之后一个字符都没塌，而且转出来的是泰文里真实存在的短语。第二条和第三条属于“看得出是同一个词，但拼法对不上”。第四条是空洞塌陷的样子。

## 一个反向陷阱：码位对齐了，音值没对齐

到这里为止都是好消息，接下来是那个必须知道的陷阱。

把两边都已分配的那76个码位的字母名字逐个比对，同一个偏移位上两边字母名首段相同的只有11个。名称一致率14%。

最能说明问题的一对：泰文U+0E23是 ร，读r音；对位的老挝文U+0EA3是 ຣ，而Unicode给它的正式名字里写着LO——那是l音的字母名。位移到这个码位上，你以为拿到了同一个辅音，实际上音值已经变了。

还有一批更隐蔽的。老挝文块里有十几个码位的字母名带着“巴利语”和“梵语”前缀，它们是为了写佛经里的外来音专门编进去的，现代老挝语一个都不用。真实语料验证了这一点：老挝文块83个已分配码位里，48835个字符实际只用到了53个，有30个已分配码位在真实网页上一次都没出现过。

这批为外来音补的字母跟泰米尔文里那批借用字母是同一个机制，只是老挝这批编码进Unicode的时间晚得多、日常用得更少。词表里要不要收这类字母，本站在泰米尔语的本族造词与音译词该收哪一个 (https://zhangwenbao.com/tamil-seo-native-coined-vs-loanword-keyword.html)里按另一条轴讨论过，这里就不展开了。

## 那这套位移，能拿来做什么、不能做什么？

## 能做的：拿泰语的数据反推候选词

用法是这样的：先在泰语那边把某个品类的长尾词跑全——泰语数据丰富，这一步很便宜。然后把这批泰语词整体加0x80位移到老挝文，得到一批候选串。这批串多数不是老挝语的正确拼写，但它们的作用不是直接用，是当种子。

拿这批种子逐个丢进搜索建议，能返回东西的就是活的、拼法也对得上的；返回空的，交给母语者看一眼，通常他能立刻说出正确写法是什么。这个流程把“从零想词”变成了“从一份现成清单里挑和改”，母语者的工时能省掉七八成。

## 具体怎么跑

五个步骤，一天之内能跑完一个品类：

- 在泰语那边导出目标品类的长尾词，控制在200到500条

- 逐字符加0x80，遇到落进老挝文空洞的位置先标红不处理

- 把标红的那批按前面那张5字符表做人工替换

- 全部丢进搜索建议跑一遍，分成“有建议”“无建议”两堆

- 把两堆一起交给母语者，让他标出“写对了”“写错了但意思对”“完全不是这个词”三类

最后那一步的产出比词表本身值钱。母语者标出来的“写错了但意思对”那一批，会暴露出老挝语和泰语之间系统性的拼写差异，攒够几十条就是一张对照规则表，下次跑别的品类可以直接套。

## 不能做的：直接当泰文词用，或者直接当老挝文词发出去

两个方向都不行，理由不一样。

位移出来的串不能当泰文词用，因为它多数不是泰语的正确拼写。前面那个例子，老挝语的电话位移过去是 โทละสับ，泰语真正的写法是 โทรศัพท์，拿前者去泰语市场查量会得到零。

反过来，泰语词位移到老挝文之后，更不能直接发到页面上。它会是一串老挝人认得出但觉得写错了的字。拼错的本地文字比英文原文伤害更大——英文原文至少显得你是个外国品牌，拼错的本地文字显得你根本没人校对。

这套位移的定位就是一个候选词生成器，它的输出必须过母语者那一关才能进词表。这一层的验收该问哪些问题，本站在小语种母语审校的验收清单怎么列 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)里整理过一份，直接拿来用就行。

## 交易词在老挝语里没长出来，那内容到底该怎么写？

## 漏斗上半截用老挝语，下半截怎么办

数据给的答案很直接：品类页用老挝语做，导购和交易环节的内容不做。

但“不做”不等于“页面上没有”。用户点进品类页之后，配送、退换、保修这些信息还是得写，只是它们的定位从“获客内容”变成了“转化内容”。获客内容按搜索量决定要不要做，转化内容按用户看不看得懂决定，两者不能用同一套标准。

落地上就是：退货政策这一页照写老挝语，但不为它做关键词优化、不给它做外链、不指望它带流量。它的KPI是让点进来的人下单，不是让人搜进来。

## 品牌名那一格要留出来

前面那40条含拉丁字母的建议给了一个很明确的模板：品类词用老挝文写，品牌和型号用拉丁原文，中间不翻译。

这条落到标题模板上就是一句话——别把型号本地化。摩托车的型号wave 110在老挝语的查询里就是这么打的，你要是转写成老挝文，那个词的搜索量是零。这一条跟多数市场的处理是一致的，只是老挝语这边的证据格外干净。

## 别去硬造那些不存在的词

看到“退货”在老挝语里零建议，有个很自然的冲动是：那我来造。写一批内容把这个词做起来，等于占了一个没人要的关键词，将来一定升值。

这个想法在别的场景成立，在这里不成立。原因是那八个词不是“还没人写所以没量”，是这门语言的使用者在处理这类事情时用的根本不是搜索。老挝的线上零售规模、支付渗透、物流覆盖决定了“网上退货”这件事本身发生得很少，词自然长不出来。你造得出词，造不出行为。

更划算的做法是把这笔预算放到实体品类词那一列——那43条建议是真实需求，而且竞争极其稀薄。

## 站内搜索和结构化数据这两块要单独处理

站内搜索这一块跟外部搜索是两回事。用户在你站内搜索框里打的词，跟他在搜索引擎里打的不是同一批，站内更容易出现完整的口语句子。老挝语的站内搜索还有个额外的坑：这门语言不写词间空格，切词要靠词典，而这类词典的维护状况本站在小语种的开源词典是谁在维护 (https://zhangwenbao.com/minor-language-open-source-dictionary-maintenance.html)里逐格盘过，老挝语那一格的情况可以直接查。

结构化数据那边只要记住一件事：语言字段写lo，别写la，别留空。前面那15个站里有9个把这一格写错了，你写对就已经比本地同行做得好。

## 排期上这门语言该排在哪一档

把前面的数据合起来看，老挝语的画像是这样的：供给侧干净、竞争稀薄、实体品类词有真实需求、交易和决策类查询整体缺席、语言基础设施可用但要自己动手补。

这画像对应的排期结论是：值得做，但只做窄的一层，投入按“一批品类页加一份词表”估，不要按“一个完整的本地化站点”估。差别可能是三倍以上的预算。

如果同一批预算要在几个东南亚市场里分配，前面那张交易存活率表可以直接当分配依据。这类跨市场的取舍框架，本站在东南亚三个市场的语言层怎么分 (https://zhangwenbao.com/southeast-asia-seo-vietnam-thailand-indonesia-language-layer.html)里给过一套，本文这张表可以当它的一个新输入项。

## 上线之前，哪几项能自己跑完？

## 词类分组测试，半小时

这是本文唯一一项必须做的检查，也是最便宜的一项。把24个概念按实体、交易、抽象三组翻成目标语言，逐个查建议，算出交易除以实体这个比值。

做的时候有三个容易出错的地方。第一，词一定要请母语者给，不能查词典——词典给的是正式对应词，那批词恰恰是最容易在搜索里没有量的。第二，界面语言参数一定要设成目标语言，不设的话补全库会切走。第三，别只做一门语言，至少拉一门数据健全的邻居进来当参照，不然你分不清是语言的问题还是尺子的问题。

比值出来之后怎么用：高于0.8按正常市场做；0.3到0.8之间，把还活着的那几个交易词单独挑出来做，其余不碰；低于0.1，只做品类页。

## 语言标签自查，五分钟

打开自己站的目标语言页面，看html标签上的语言声明。要确认的是三件事：值不是空的、值是语言代码不是国家代码、值没有被建站模板留成默认的英语。

顺手也可以把竞争对手的站扫一遍。前面那15个老挝站里有9个写错，这个比例在小语种市场很常见。如果整个市场的语言声明都是坏的，那你把这一格写对，成本几乎为零，收益是让机器第一时间知道这个页面是给谁看的。

## 位移覆盖率自查，一小时

只有做老挝语才需要这一项。抓10到20个本地站的正文，把老挝文字符逐个减0x80，统计落进空洞的比例和具体是哪几个字符。

这次跑出来是3.86%、集中在5个字符上。你的语料如果偏向某个特定领域，塌陷的分布可能不一样，那就按自己的数据建映射表。这一步的产出是一张十几行的对照表，一次做完长期可用。

## 哪些相邻的问题不归这一层管

有四类问题会在做老挝语时一起冒出来，但它们的解法不在本文这一层：

- 没有词间空格导致的切词问题——跟泰语共用同一套机制，去看泰语那一篇

- 页面被自动识别成别的语言——那是短文本识别的问题，跟你写什么词无关

- 字体和字形加载——老挝文的字形集不大，多数系统字体覆盖得了，属于前端问题

- 老挝语内容被AI答案引用不到——那是低资源语言在生成式检索里的通病，跟这门语言的商业词有没有量是两条线，本站在AI检索里的语言偏向与来源审计 (https://zhangwenbao.com/ai-search-language-bias-low-resource-citation-source-audit.html)里专门测过，老挝语在那篇里也被点到了

## 开头那家电动工具站后来改了什么

三件事。第一，把那批“怎么挑”“哪款好”的导购文章全部取消索引，不是删，是让它们不再消耗抓取预算——内容留着给点进来的用户看。

第二，把品类页的标题模板改成“老挝文品类词加拉丁原文型号”，型号一律不转写。这一改之后进来的词开始出现型号级的长尾。

第三，把原本要投给导购内容的那部分预算挪去补品类页的深度——参数、配件兼容、维修点信息。这些内容不靠搜索量进来，靠的是用户点进品类页之后往下看。

半年之后的情况是自然流量涨了，但结构没变——依然全是品类词加型号。这次不同的是，团队不再把它当成问题了。这门语言在搜索里能给的就是这一格，把这一格吃满，就是这个市场的天花板。

## 常见问题解答

## 交易存活率低于0.1的语言，是不是就完全不该做？

不是，是不该按完整本地化去做。老挝语0.02，但实体品类词那一列有43条建议，这些是真实需求，而且几乎没有竞争。正确的做法是把投入压缩到品类页和产品页这一层，砍掉导购、评测、对比这类内容，然后按这个缩小后的范围重新算投产比。很多时候砍完之后这个市场反而变得划算了，因为分母小了一大截。真正该放弃的信号不是比值低，是连实体品类词那一列也塌了——那说明这门语言的使用者根本不在网上买这类东西。

## 搜索建议返回零条，是不是就等于这个词没有搜索量？

不等于。搜索建议有收录门槛，一个词得达到某个查询量级才会进补全库，所以零建议的准确含义是“低于门槛”而不是“等于零”。但对做内容规划的人来说，这个区别不重要。低于建议库门槛的词，意味着你就算排到第一名也拿不到有意义的流量。反过来要小心的是另一个方向：有建议不等于有商业价值，得看建议的内容是什么。本文里老挝语的“价格”能拉满10条，可十条全是金价和油价，对卖电动工具的站来说等同于零。

## 把泰语关键词位移过来生成老挝语候选词，会不会有版权或者数据合规问题？

位移这个动作本身处理的是字符编码，不涉及内容复制，产出的是一批候选字符串而不是文章。真正要留意的是上游那批泰语词的来源——如果是从付费工具导出来的，那份数据的使用条款通常会限制再分发，自己内部用没问题，做成产品对外提供就要看合同。另外提醒一句，位移出来的串必须过母语者审核才能上页面，这一步不只是质量把关，也是避免把一批拼错的文字发出去伤害品牌。

## 老挝语和泰语这么像，能不能只做泰语版本去接老挝的流量？

不建议，理由不在语言层而在运营层。就算老挝用户能读懂泰文页面，你的价格、货币、配送时效、支付方式、售后地址全都是按泰国市场设置的，用户读完之后发现每一项都不适用，转化会很难看。语言能读懂只解决了理解问题，解决不了适用问题。如果预算实在只够做一套，更务实的做法是做泰语版本主攻泰国市场，把老挝当成溢出流量顺手接一接，但别为它单独投入，也别指望它的转化率。

## 那五个位移会塌的字符，为什么泰文里没有对应的位置？

因为它们是老挝文自己的东西。其中出现最多的那个是一个元音符号，老挝语的拼写系统里用得极频繁，泰语的元音体系不需要它；另外两个是把两个辅音合写成一个字形的合体字母，这是老挝文独有的写法。剩下两个是半元音符号。它们不是泰文“漏掉了”，是当年编码的时候两套文字本来就不完全对应。处理办法是给这五个字符各定一个泰文侧的近似写法，通常是拆成两个字符或者换一个音近的符号，具体怎么定要请懂两门语言的人拍板。

## 这套词类分组的办法，能不能用在非东南亚的语言上？

能，分组的逻辑跟语系无关。只要是做电商，实体品类、交易动作、决策修饰这三类词就一直存在。要调整的是具体词的选择：不同市场的高频交易动作不完全一样，比如货到付款渗透率高的市场，付款相关的词会比预付市场活跃得多；再比如某些市场的“比价”是强需求，另一些市场几乎不存在。所以搬这套方法的时候，三组各八个词的骨架保留，具体选哪八个要按目标市场的电商习惯换一遍。

## 做这门语言，母语者要请几个、请什么样的？

一个人就够，但要请对。三条标准：母语者、长期生活在当地、接触过电商或者你所在的品类。第三条最容易被省掉，也最要命——本文这套方法的关键一步是让母语者判断某个词“是不是人们真会打的说法”，没有电商经验的人会按书面标准去判，把一批真实在用的口语说法判成写错了。交付物除了词表本身，一定要额外要一份问题清单，标出每处修改的原因，这份清单攒起来就是下一个品类的规则表。

## 权威参考资料



## 蒙古国立法要求两套文字并用已经一年半，抓下来的21个站上传统蒙文一个字符都没有

- URL：https://zhangwenbao.com/mongolian-seo-dual-script-keyword-table.html
- 分类：小语种SEO
- 发布：2026-08-01  |  更新：2026-08-01
- 摘要：蒙古语有两套互不相通的官方文字，选哪一套由目标市场决定。给出网页侧与搜索侧的实测数据、私有编码的排查办法，以及那几个不可见字符为什么绝对不能清掉。
- 关键词：技术SEO,跨境电商,多语言SEO,小语种SEO

> **TLDR**：摘要：蒙古国的语言法从2025年1月1日起要求官方文书西里尔与传统蒙文并用，目标是2030年全面恢复传统文字。这条政策生效一年半之后，我抓了32个蒙古国站点，21个可用的里面传统蒙文字符是0；又跑了12次搜索建议，传统蒙文一条都拉不出来，同样的概念换西里尔每次都是满10条。真正在网上写传统蒙文的站在国界另一侧，可那8个站里有7个混着私有编码，占比从0一直排到100%。给这门语言建关键词表，第一个要回答的不是用哪些词，是用哪套字。

> 
摘要：蒙古国的语言法从2025年1月1日起要求官方文书西里尔与传统蒙文并用，目标是2030年全面恢复传统文字。这条政策生效一年半之后，我抓了32个蒙古国站点，21个可用的里面传统蒙文字符是0；又跑了12次搜索建议，传统蒙文一条都拉不出来，同样的概念换西里尔每次都是满10条。真正在网上写传统蒙文的站在国界另一侧，可那8个站里有7个混着私有编码，占比从0一直排到100%。给这门语言建关键词表，第一个要回答的不是用哪些词，是用哪套字。

做小语种排期表的时候，语言这一列通常填一个名字就够了。蒙古语是少数几门填一个名字不够的语言——你还得再填一列，写清楚是哪套字。

而且这一列的答案，最近刚被一部法律改过。

## 一门语言两套文字，为什么这不是历史遗留问题？

## 那个已经过去的日期

蒙古国在1940年代把书写系统从传统蒙文换成了西里尔字母，此后八十年，这个国家的书面语基本就是西里尔。传统蒙文在蒙古国境内退到了书法、招牌、纪念物这些场合。

2020年，蒙古国政府以第96号决议批准了《蒙古文字国家大纲三》，规划了四个目标下的56项措施，实施期是2020到2024年。配套的《蒙古语言法》第7.2条规定，从2025年1月1日起，国家和地方自治机关的官方文书要西里尔与传统蒙文并用。过渡期内西里尔继续使用，目标是2030年全面恢复传统文字。

换句话说，这不是一个几十年前的历史事件，是一件正在发生的事，而且第一个法定节点已经过去一年半了。

## 两套文字不是两种字体

这里要先把一个常见的误解拆掉：传统蒙文和西里尔蒙古文的关系，不是宋体和黑体的关系，也不是简体和繁体的关系。

西里尔蒙古文是音素文字，横排，从左到右，字母表跟俄语高度重合，只多出两个蒙古语专属的元音字母。传统蒙文是竖排的，从上往下写，行序从左往右，字母有词首、词中、词尾三种形态，同一个字母在不同位置长得完全不一样。

两者的编码区间也完全不同：西里尔在Unicode的0400到04FF这一段，传统蒙文在1800到18AF这一段。一个字符串是哪一套，程序一眼就能判出来，不需要猜。

更要紧的是，两套文字之间的转换不是查表替换。传统蒙文里有大量同形异读，一个写法对应多个读音；西里尔那边有传统蒙文里不存在的俄语借词字母。所以你不能指望写一个脚本把一边的词表翻到另一边。

## 竖排这件事在网页上是怎么落地的

传统蒙文是竖排的，这一点比看上去麻烦。中日韩也有竖排传统，但那是可选的排版风格，横排是默认。传统蒙文没有横排这个选项，竖排是它唯一的正确形态。

而且它的行序跟中日韩相反。中日韩竖排是从右往左换行，传统蒙文是从左往右换行。CSS里这两种是不同的书写模式取值，写错了整页的阅读顺序就是反的。

更实际的问题在窄屏上。竖排页面的可读区域是按高度算的，手机竖持的时候屏幕高但窄，一列能放的字很多、能并排的列很少。桌面上验过的版式在手机上得重做一遍，这跟从右往左那类语言遇到的情况有几分像，只是坏的方向不一样。

本站在字号行高与书写系统那一篇 (https://zhangwenbao.com/minor-language-font-size-line-height-script.html)里算过不同文字的排版度量，那篇的对象是横排文字。竖排这一档要单独测，而且测的不是行高，是列宽和字间距。

## 使用者分在国界两侧，而两边用的不是同一套

蒙古语的使用者大致分两块。蒙古国境内三百多万人，用西里尔。中国内蒙古自治区有几百万使用者，一直用传统蒙文，从来没换过。

这个格局的直接后果是：同一门语言的两个最大市场，写出来的东西互相看不懂。不是理解不了内容，是字面上就认不出来。一个蒙古国人看内蒙古的网页，感觉跟看一门外语差不多；反过来也一样。

做双市场的语言，本站写过不少。葡萄牙语的巴西和葡萄牙那一篇 (https://zhangwenbao.com/portuguese-seo-brazil-portugal-two-markets-keyword.html)拆的是词汇和拼写的差别，印尼语和马来语那一篇 (https://zhangwenbao.com/indonesian-malay-seo-two-markets-vocabulary-split.html)拆的是两个标准语的分家。蒙古语这边的分家程度更彻底：前面那些语言的两个市场至少共用一套字母，这边连字母都不共用。

## 三种位置形态对匹配意味着什么

传统蒙文的字母有词首、词中、词尾三种形态，长得完全不一样。这跟阿拉伯字母是同一类机制，但蒙文的差异更大——有些字母的词首形和词尾形之间几乎看不出亲缘关系。

好在这一层在编码上是干净的：Unicode里存的是字母本身，形态由排布引擎按位置选，不需要人来管。所以字符串比对、分词、索引都不受影响，同一个字母在词首和词尾是同一个码点。

会出问题的是另一头。如果一个站是从私有编码转过来的，而当年那套私有编码是按字形排的——也就是词首形、词中形、词尾形各占一个码位——那转换就得先做形态还原。形态是显示层的事，一旦被写进了存储层，转换就从查表变成了分析。

这也解释了为什么那批站的迁移拖了这么久。它不是把一个码位换成另一个码位那么简单。

## 本文谈什么、不谈什么

本文只谈语言层：文字系统的选择、编码的实况、不可见字符、词表怎么建。搜索引擎在蒙古市场的份额、当地的支付和物流，那些跟这门语言是哪门语言无关，属于别的层。判据还是那一条：把语种换成英语就不成立的，才归这一层。

数据来自三轮抓站和一轮搜索建议测试。抓站的口径是取首页正文、去掉标签，然后逐个字符按Unicode码点区间分类。这套管线跟同批那篇泰米尔语 (https://zhangwenbao.com/tamil-seo-native-coined-vs-loanword-keyword.html)的是同一套，只是关心的码点区间不一样。

## 蒙古国的网站上到底有没有传统蒙文？

## 开工前我是怎么预期的

动手之前我在实验计划里写了五条预期，第一条是这么写的：法定日期过去一年半，实际执行率会很低，政府站上的传统蒙文大概只是个点缀。

写这条的时候我已经在给自己留余地了——用的是“很低”不是“没有”。上一批做缅甸语的时候吃过一次亏，那次预期是某套旧编码还大量存在，实测是零，整篇的结论得翻过来重写。所以这次我特意把话说软了一点。

说软了也没用。

## 32个站抓下来，21个可用

我按四类取站点：政府与官方机构10个、新闻媒体8个、商业与电商8个、内蒙古侧6个。蒙古国那26个里能正常抓到内容的是21个，剩下的是证书过期、域名解析失败、403和超时。

能抓到的这21个，逐个统计传统蒙文码点区间的字符数。

类别 | 可用站点 | 传统蒙文占比 | 西里尔占比 | 

政府与官方 | 4 | 0% | 89%到99% | 

新闻媒体 | 8 | 0% | 70%到98% | 

商业与银行 | 6 | 0% | 58%到94% | 

航空与外向型 | 3 | 0% | 1%到41%（其余是拉丁） | 

21个站，传统蒙文字符总数是0。不是很少，是一个都没有。包括法律信息门户、统计局、央行、国会这几个直接受那条法律约束的站。

## 这个零要怎么读

零不等于没人在做。传统蒙文在蒙古国的公共空间里是能看到的：招牌、证书、公文的抬头、纪念邮票。政策落地也确实在推进，有部委做过传统蒙文版网站的发布会。

但那些是仪式性的场合，或者是单独做的一个版本。日常在跑的那些页面——新闻正文、商品详情、法规条文——一个传统蒙文字符都没有。

对做站的人来说，这个区别很重要。它意味着：如果你为了响应政策去做一个传统蒙文版，你会是那个市场上最早的一批；但同时也意味着，你做出来之后没有参照物，没有竞品，也没有现成的语料能验证你的用词。

## 西里尔那一侧也有两个自己的字母

顺便说一个西里尔侧的细节，做蒙古国市场会用得上。

蒙古语的西里尔字母表比俄语多两个：一个圆里带横的元音，一个像У但中间多一横的元音。这两个字母俄语里没有，所以俄语键盘打不出来。

我在抓到的语料里数过，这两个字母合起来占西里尔字符总量的百分之七上下。这个比例不低——意味着七个字符里就有一个是俄语键盘打不出来的。

后果是用户会用形近的俄语字母凑。这跟波斯语用户拿阿拉伯语键盘打字造成的分叉是同一类问题，处理办法也一样：把两种写法都收进词表，在查询层做归一化，展示层保持正确写法。这一层的完整做法在波斯语那一篇 (https://zhangwenbao.com/persian-seo-iran-market-letters-digits-zwnj.html)里，蒙古语可以照搬。

## 顺带记一个技术坑

抓这批站的时候我在编码探测上翻过一次车，值得记下来。

用的抓取库有个自动编码探测，正常情况下挺准。但对内蒙古那两个站，它把UTF-8的字节流猜成了某种单字节西里尔编码，解出来是一串规律性的乱码。我第一轮的报表因此显示“内蒙古自治区政府蒙文版用的是西里尔字母”——这个结论要是不复核，会直接写进文章里，而且它听起来完全说得通。

修正办法是把编码判定的优先级改回常识顺序：先看HTTP响应头里的charset，再看HTML里的meta声明，然后试UTF-8，最后才轮到自动探测。改完重抓，那两个站是干干净净的传统蒙文。

自动探测在中文和西里尔之间最容易翻车，因为多字节序列被按单字节解出来之后，恰好落在西里尔的常用区间里。做非拉丁语种的抓取，这一条建议直接写进模板。

## 搜索那一侧的情况呢？

## 十二次查询，零条建议

网页侧是零，搜索侧可能不一样——搜索反映的是用户在打什么，跟网站上有什么不是一回事。所以我又跑了一轮搜索建议。

做法是取6个日常概念：新闻、价格、购买、学校、医院、网店。每个概念准备两种写法，一种传统蒙文，一种西里尔。然后分别用蒙古国和中国两个地区参数跑。

查询概念 | 传统蒙文（蒙古国） | 传统蒙文（中国） | 西里尔（蒙古国） | 

新闻 | 0条 | 0条 | 10条 | 

价格 | 0条 | 0条 | 10条 | 

购买 | 0条 | 0条 | 10条 | 

学校 | 0条 | 0条 | 10条 | 

医院 | 0条 | 0条 | 10条 | 

网店 | 0条 | 0条 | 10条 | 

传统蒙文12次查询，一条建议都没有。西里尔6次查询，每次都是满10条，而且返回的长尾很像样：政府采购电子系统、采购法、医院预约挂号、医院预约电话、店铺出租、店铺转让。

## 零条建议意味着什么

搜索建议的门槛是查询量。一个查询串要能进建议列表，得有足够多的人真的打过它。返回零条不代表这个词没有排名结果，它代表打这串字符的人少到进不了统计。

为什么少？因为打传统蒙文需要专门的输入法，而这套输入法在蒙古国的手机上不是默认配置。用户想打，得先去装。这跟内容有没有价值无关，是输入端的成本。

输入这一层的成本账，本站在别的语言上算过。网站上所有的字都是给用户读的、只有域名这一串要他自己打出来那一篇 (https://zhangwenbao.com/idn-punycode-local-script-domain-input-trust.html)里有一条判据说得很准：可输入性是键盘布局的属性，不是语言的属性。传统蒙文正好是这条判据的极端案例——它有完整的Unicode支持、有开源字体、有渲染引擎，唯独没有一副大多数人手上现成的键盘。

## 建议为零之外还能查什么

搜索建议拿不到数据的时候，还有两个替代信号可以用，都不需要付费工具。

第一个是相关搜索。有些查询词在结果页底部会给出相关搜索，那一块的门槛比建议低一些。传统蒙文这边我试了几个词，同样是空的，但对别的低资源语言这一招有时候管用。

第二个是站内搜索日志。如果你已经有一个面向这个市场的站，哪怕流量很小，站内搜索框里用户打进来的东西是最真实的。它能告诉你用户到底用哪套字打字，这一个信息就值回票价。

这两招都拿不到东西的时候，剩下的只有抓内容做词频。而这条路在传统蒙文上要先过编码这一关，后面会专门说。

## 这跟排名不是一回事

要说清楚一件事：建议为零不等于这些词搜不出结果。你把传统蒙文的词直接输进搜索框，是能返回结果页的，收录也存在。

但对做关键词表的人来说，建议为零基本等于判死。因为你没法用它做长尾拓展，没法看修饰词分布，没法判断哪个词形是主流。一个拿不到建议数据的词，在词表里只能靠猜。

关键词工具在小语种上没数据的时候有几种绕法，那一篇 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)列过一整套。但那些绕法有个共同前提：这门语言在网上有足够的内容可以拿来做词频。传统蒙文这边，蒙古国侧的内容量是零，绕法的第一步就断了。

## 真正写传统蒙文的站在国界另一侧

## 国界另一侧的八个站

换个方向找。内蒙古自治区的政府和媒体系统里有一批常年运行的蒙文站，我抓了其中8个能打开的。

站点 | 传统蒙文字符 | 私有区码位 | 私有区占比 | 

内蒙古自治区政府蒙文版 | 27612 | 2 | 0.0% | 

通辽市蒙文版 | 27885 | 1386 | 4.7% | 

赤峰市蒙文版 | 23706 | 1275 | 5.1% | 

呼伦贝尔市蒙文版 | 12678 | 2125 | 14.3% | 

鄂尔多斯市蒙文版 | 46525 | 8089 | 14.8% | 

兴安盟蒙文版 | 6138 | 1279 | 17.2% | 

锡林郭勒盟蒙文版 | 7693 | 3655 | 32.2% | 

人民网蒙古文版 | 0 | 6340 | 100% | 

先看第一列。这批站的内容量是实打实的，单是首页就有一两万到四万多个传统蒙文字符，比蒙古国那21个站加起来还多——那边是零。

然后看第三列。这就是本文最想说的那件事。

## 这批站的读者是谁

看到这批站的内容量，第一反应可能是这里有个现成的市场。要泼一点冷水。

这批站的性质大多是政府信息公开和民族语言公共服务，读者是当地的公职人员、教师、媒体从业者。它们不是消费内容，也没有商业竞价的生态。

所以内容量大不等于市场大。用这批站做语料是完全可以的——它们是目前能拿到的最干净的传统蒙文语料源；但用它们的存在来论证市场规模，会得出过于乐观的结论。

判断一个小语种市场的商业容量，看的是有没有本地电商、有没有分类广告、有没有比价站。这三样在传统蒙文这一侧目前基本没有。

## 私有区码位是什么

Unicode在E000到F8FF这一段划了一块私有使用区。这一块不分配给任何具体文字，谁想用谁用，含义由用字体的人自己定。

它的设计初衷是给未编码的文字、企业内部符号、图标字体留个口子。用在这里的后果是：同一个码位，换一套字体就是另一个字符。系统不知道它是什么，搜索引擎不知道它是什么，读屏软件不知道它是什么，复制粘贴出去就是一串问号。

传统蒙文进Unicode是1999年的事，而内蒙古的蒙文信息化比这早得多。早期的解决方案是厂商自己在私有区里排一套字形，配一套输入法和字体卖出去。这套方案在Unicode方案成熟之前是唯一可行的，用了二十多年，形成了巨大的存量。

## 人民网蒙古文版：整站一个标准字符都没有

这一批里最极端的是人民网蒙古文版。首页抓下来7693个字符，传统蒙文码点区间0个，私有区6340个，用到了158个不同的私有码位，区间落在E236到E34E。

页面的CSS里写着字体族名，是那家厂商的名字。同一个页面的charset声明里同时出现了UTF-8和一个更老的字符集声明，两句自相矛盾。

这意味着什么？这个站上所有的蒙文正文，对搜索引擎来说等于不存在。不是排名低，是没有内容可索引——引擎抓到的是一串它无法归类的私有码位，既不能分词，也不能匹配任何查询。

这跟上一批做缅甸语时遇到的情况有点像，但不是一回事。缅甸语那次 (https://zhangwenbao.com/burmese-seo-zawgyi-unicode-byte-split.html)的问题是一套非标准编码占用了标准码位——字符能显示，字节是错的，而且那场迁移在2021年前后已经完成了。这里的问题是另一种：码位本身是合法的私有区，从来没打算被机器理解，而且迁移根本没有完成。

## 怎么在十分钟内测出一个站的编码状况

这套检查不需要懂蒙古语，步骤是四步。

第一步，取页面正文，注意是正文不是标题。用浏览器的开发者工具选中一段正文文本，复制出来。

第二步，把这段文本逐个字符转成码点。任何一门脚本语言的一行代码就能做，在线工具也有。

第三步，数落在1800到18AF区间的有多少个，落在E000到F8FF区间的有多少个。前者是标准传统蒙文，后者是私有区。

第四步，算私有区占两者之和的比例。这个比例就是这个站的欠账。

还有一个更快的土办法：把那段文字复制到一个纯文本编辑器里，换一个跟原站不同的字体。如果字变成了乱码或者方块，说明它依赖特定字体，那就是私有区。标准Unicode的文字换字体只会变样式，不会变内容。

## 那条从0排到100%的曲线

回头看那张表的第三列：0.0%、4.7%、5.1%、14.3%、14.8%、17.2%、32.2%、100%。

这不是两代技术的二元对立，是一条连续分布。八个站停在这场迁移的八个不同位置上。

最干净的那个是自治区一级的政府站，7万多字符里只有2个私有码位，基本是彻底转过来了。最脏的那个整站没转。中间那六个是混的——同一个页面上，有的段落是标准Unicode，有的段落是私有码位。

我拿赤峰那个站又细看了一层：私有区字符全部落在正文的div里，导航链接、列表项、页面标题里一个都没有。这说明转换是分模块做的，模板层先转完了，正文里那些从老系统迁过来的文章还留着。

这个细节对做站的人有直接价值：检查一个站的编码状况，不能只看首页标题，得抽正文段落。模板转完了看起来一切正常，问题全在内容里。

## 那几个看不见的字符是干什么用的？

## 传统蒙文自带四个不显示的字符

传统蒙文在Unicode里有一件别的文字很少见的事：它的编码区间里有几个字符是不显示的，但它们决定别的字符长什么样。

一类是自由变体选择符，码位是180B、180C、180D。传统蒙文的同一个字母在同一个位置可能有两三种合法字形，选哪一种由语法和词源决定，看字母本身看不出来。变体选择符就是用来指定的：写在字母后面，告诉排布引擎这里该用第几号字形。

另一类是元音分隔符，码位180E。它用在词尾某些元音跟前面的部分之间，视觉上会产生一个小的断口，但它不是空格。

这四个字符都是零宽度的。你在页面上看不见它们，复制粘贴会带着走，用肉眼比对两个字符串永远看不出差别。

## 实测用量：一个站两千多次

我在内蒙古那几个站的语料里数了一遍。

站点 | 变体选择符一号 | 二号 | 三号 | 元音分隔符 | 

鄂尔多斯 | 1191 | 217 | 1213 | 2258 | 

内蒙古自治区政府 | — | — | — | 1798 | 

通辽 | 426 | 174 | 69 | 1302 | 

赤峰 | 540 | 80 | 56 | 1009 | 

呼伦贝尔 | 192 | 65 | 32 | 708 | 

这不是零星出现，是高频。赤峰那个站两万多个蒙文字符里有一千多个元音分隔符，平均每二十几个字符就有一个看不见的字符。

含元音分隔符的连续词串我提取出来数了一下，赤峰加鄂尔多斯两个站合计2920个，去重之后894个不同的形态，绝大多数是把一个词切成两段。

## 这个改动为什么现在还在咬人

一个字符的分类在2013年改了一次，为什么2026年还要拿出来说？

因为Unicode数据是随各种运行时打包分发的，而运行时的版本参差不齐。一个企业内部的老Java应用、一个多年没升级的搜索中间件、一个用旧版正则库编译的服务，它们内置的Unicode数据可能还停在改动之前。

这类东西通常不报错，只是行为不一样。你把同一份数据喂给两条链路，一条切出来12个词，另一条切出来9个词，两边都不报错，对不上的地方要查很久才能找到根因。

凡是一个字符的分类被改过，它就成了一个跨版本的行为分歧点。排查这类问题的第一步不是看代码，是先确认两条链路用的Unicode版本一不一样。

## 那个改过类别的字符

元音分隔符这个字符有段历史，值得单独说。

在Unicode 4.0到6.2之间，它的通用类别是空格分隔符，也就是说标准把它归类成一种空白字符。从Unicode 6.3开始，它被改成了格式字符。

这个改动听起来很技术，后果很实在：凡是按空白字符判定的逻辑，在这个改动前后行为完全相反。JavaScript的空白匹配就是典型，规范要求只把标准里归为空格分隔符的字符当空白，所以6.3之后引擎不再把它当空白了。

落到实处：一个按空白切词的分词器，如果它用的Unicode数据是2013年之前的，会把带这个字符的词切成两半；用新数据的不会切。同一个词，两台机器数出来的词数不一样。

而这个字符在真实文本里一个站出现一两千次。

## 这里我又猜错了一次

开工前的第五条预期是：这几个不可见字符在真实网页里用得很乱，同一个词会出现带和不带两种写法，导致词形分叉。

验证办法很直接：把语料里所有的蒙文词串提取出来，去重得到一个数；再把所有不可见字符剥掉，重新去重，看能合并掉多少。如果用法乱，合并率应该很高。

实测是3319个词形剥完之后剩3296个，只合并掉23个，占比0%。

也就是说这一层的用法高度统一。写传统蒙文的人和工具知道这几个字符该放在哪儿，几乎不出错。这一层没坏。

## 所以它跟软连字符那类完全不是一回事

这个结果值得跟另一类不可见字符对照着看。前端往标题里塞看不见的字符那一篇 (https://zhangwenbao.com/minor-language-line-break-soft-hyphen-invisible-character.html)拆的是软连字符和零宽空格，那些字符的共同点是：它们是人为塞进去的，为了解决排版问题，语言本身不需要它们。所以它们出现的位置随意、可逆、应该被清掉。

传统蒙文这几个不一样。它们是这套文字的组成部分，缺了字形就是错的，清掉等于把词写错。同样是零宽度的不可见字符，一类必须清，一类绝对不能清。

判据是这一条：去掉这个字符之后，母语者会不会认为这个词写错了。会，就是文字的一部分；不会，就是排版的补丁。这条判据在波斯语的半连接符上也成立，波斯语那一篇 (https://zhangwenbao.com/persian-seo-iran-market-letters-digits-zwnj.html)专门有一节讨论那个字符到底算不算空格，结论跟这里是同构的。

## 两套文字之间能不能自动转换？

## 转写不是一一对应

做双市场最想问的一句是：能不能写个转换器，把西里尔的内容自动转成传统蒙文，一份内容吃两个市场。

答案是不能，而且原因不是工程难度。

传统蒙文有大量同形异读：同一串字形对应多个读音和多个词，具体是哪个由上下文定。反过来，西里尔那边有传统蒙文里不存在的字母，专门用来拼俄语借词。

所以从传统蒙文转西里尔要做消歧，从西里尔转传统蒙文要处理外来词。两个方向都不是替换，是需要语言知识的转换。

## 排序这一层也是分家的

还有一处两边不通的地方：排序规则。

西里尔蒙古文的排序跟俄语接近，那两个专属字母有自己的位次。传统蒙文的排序按字母表顺序，而这个顺序跟西里尔的字母顺序对不上，因为两套文字的字母表本来就不是一套。

后果是首字母索引、字母导航、按名称排序的列表，这三处在两个市场上是两套结果。你不能把一边的排序逻辑照搬到另一边，也不能把两边的数据混在一个列表里排。

这一层的通用做法是用国际化排序库，按语言加文字的标识去取对应的排序规则。前提是那个库里有这门语言这套文字的规则数据。做小语种之前查一下排序规则数据在不在，是个五分钟的动作，但漏了会在列表页上暴露得很明显。

## 转换工具的现状

这类工具是存在的，学术界和民间都做过，准确率在受控文本上能到一个可用的水平。但用在网页内容上会遇到两个问题。

第一个是专有名词。人名、地名、品牌名是同形异读最集中的地方，也正是商品页里最不能出错的地方。

第二个是它转出来的东西没法验收。你手上没有一个传统蒙文的参照语料库能用来校对，蒙古国侧的网页内容量是零，内蒙古侧的内容里一半混着私有码位。没有干净的参照物，转换结果的质量就是不可测的。

机器翻译直接发布的风险线在那一篇 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)里画过。文字转换比翻译的风险更隐蔽——翻译错了母语者一读就知道，字形选错了得盯着看才发现。

## 结论：两边的词表得各建各的

所以这门语言在词表这一层是彻底分家的。蒙古国市场建一份西里尔词表，另一侧市场建一份传统蒙文词表，两份表之间没有机器通路。

能共用的只有上游：品类结构、页面模板、内链拓扑、结构化数据的骨架。到了字段里的值那一层，两份完全独立。

这个结论跟塞尔维亚语那种双文字市场不一样。保加利亚语和塞尔维亚语那一篇 (https://zhangwenbao.com/bulgarian-serbian-seo-cyrillic-latin-dual-script.html)里的双文字，两套字母的转换是严格一一对应的，一个脚本就能来回转，所以那边的做法是两套都生成。蒙古语这边转不了，只能各建各的。同样叫双文字市场，可转和不可转是两种完全不同的工程量。

## 这门语言的关键词表建法

## 第一个问题不是用哪些词，是用哪套字

常规的建表流程是先定语言、再定词。蒙古语这里要在中间插一步：定文字。

这一步的答案由目标市场决定，而且答案是唯一的，没有折中：做蒙古国市场就是西里尔，做另一侧市场就是传统蒙文。两边都做的话，是两个项目，不是一个项目的两个语言版本。

这一步定错的代价很大，因为它决定了后面所有的动作：抓哪批语料、找哪批审校、用哪套输入法验证、字体怎么选。定完再改，前面全白做。

## 西里尔那份词表怎么建

蒙古国市场的词表建法跟别的中小语种没有本质区别，流程是常规的：抓当地媒体和电商站做词频，跑搜索建议拉长尾，找母语者过一遍语域。

要额外注意的有两点。

第一点是俄语借词的比例。蒙古语里有大量俄语借词，尤其在技术、医疗、教育这些领域。同一个概念往往有一个俄语借词和一个蒙古语本族词并存，而且哪个更常用要逐词看。这跟同批那篇泰米尔语遇到的情况很像，处理办法也一样：两个都进表，按搜索侧的表现决定谁进标题。

第二点是那两个专属字母的替代写法。前面说过用户会用形近的俄语字母凑，所以词表里要为带这两个字母的词各准备两个写法。这一条在别的西里尔语言上不成立，是蒙古语专有的。

## 蒙古国市场：只做西里尔，别被政策带偏

面向蒙古国的站，结论很干脆：只做西里尔。

那条法律约束的是国家机关的官方文书，不是商业网站。而实测下来，连受它直接约束的那几个政府站，网页上也还是纯西里尔。政策是政策，需求是需求，这两件事在这个市场上目前还没有接上。

那要不要提前布局？我的判断是先不做，但留一个观察点。理由是：传统蒙文版内容的成本不低——字体要单独加载、竖排要单独做版式、输入法用户手上没有、写完没法验收。而回报现在是零，因为没有查询量。

观察点设在两处：一是搜索建议什么时候开始能拉出传统蒙文的结果，那是查询量过门槛的第一个信号；二是主流手机系统什么时候把传统蒙文输入法做成预装。这两件事任一发生，就该重新评估。

## 另一侧市场：先验编码，再谈词

面向传统蒙文那一侧的站，第一件事不是建词表，是把编码这一层查干净。

查法很直接。取一段页面正文，逐个字符看码点落在哪个区间。落在1800到18AF的是标准传统蒙文，落在E000到F8FF的是私有区。算一下私有区的占比。

三档判断：占比为零，可以往下走；占比在个位数到三成之间，说明迁移做了一半，正文里还有存量，得先把存量清完；占比接近百分之百，这个站现在等于没有可索引的文字内容，任何SEO动作都是空转。

这一步花不了一小时，但它决定后面所有的工作有没有意义。在一个私有编码的站上做关键词优化，就像在没插电的键盘上打字，手感一切正常，屏幕上什么都没有。

## 一张能贴在评审清单上的表

检查项 | 做法 | 不通过的表现 | 

文字系统选定 | 看目标市场 | 一份词表里混着两套字 | 

私有区码位 | 统计正文码点落在E000到F8FF的比例 | 比例大于零 | 

抽检位置 | 抽正文段落而不是标题和导航 | 只查了模板层 | 

不可见字符 | 确认变体选择符和元音分隔符保留原样 | 被当成脏数据清掉了 | 

字符串比对 | 比对前不做任何剥离 | 剥掉不可见字符再比，两个不同的词被判成同一个 | 

字体 | 页面有没有声明可用的传统蒙文字体 | 只声明了厂商私有字体 | 

语言标签 | html的lang属性有没有区分文字 | 只写了语言代码没写文字子标签 | 

竖排版式 | 移动端窄屏下的行为 | 没测过，或者直接用图片代替 | 

语言标签那一行要多说一句。这门语言的两套文字在语言标签里是靠文字子标签区分的，只写语言代码不够。这一层的规则属于国际化架构，跟具体是哪门语言无关，结构化数据里的语言字段那一篇 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)有完整写法，这里只强调：蒙古语是那种必须写文字子标签的语言，不写等于没说。

## 结构化数据和站内搜索这两处容易漏

做传统蒙文页面的时候，有两个位置最容易被漏掉。

第一个是结构化数据。页面正文用标准Unicode写好了，结构化数据里的名称字段却是从旧系统的数据库直接取的，还带着私有码位。这种情况在混编码的站上很常见，因为正文是重新编辑过的，数据库字段没人动。

第二个是站内搜索。用户在搜索框里打进来的是标准Unicode，数据库里存的是私有码位，怎么都搜不到。这个问题的表现是站内搜索永远零结果，而且很难归因，因为页面看起来一切正常。

排查办法是同一段文字走三条路各取一次：页面渲染出来的、结构化数据里的、数据库里存的。三处的码点应该完全一致，不一致就说明链路上有一段没转。

## 字体这一层的额外成本

传统蒙文的字体不是随便一个系统字体就能顶上的。竖排、三种位置形态、变体选择符，这些都要求字体本身支持完整的整形规则。系统默认字体里带这套支持的不多。

所以做传统蒙文页面，Web字体基本是必需品，而且这套字体的字形数量比拉丁字体多一个量级。首屏加载的账要单独算，小语种Web字体的字形集与首屏成本那一篇 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)算过这类账的通用方法，蒙文这边要额外加一项：子集化在这套文字上很难做，因为变体选择符会把可能用到的字形组合放大。

## 怎么判断一个市场是不是官方推一套、网上跑另一套？

## 三个能在一天内跑完的信号

蒙古语这种情况不是孤例。凡是有过文字改革、正字法变动或者语言政策推动的市场，都可能出现官方口径和实际用法脱节。判断办法有三个，都不需要懂那门语言。

第一个信号：抓十到二十个当地站点，统计目标文字的码点占比。政策口径说要用的那套文字，如果在真实网页上占比是个位数或者零，那就是脱节。

第二个信号：跑搜索建议。同一个概念用两套写法各跑一遍，看哪一套能拉出长尾。用户不会为了配合政策改变自己的输入习惯，搜索建议是最诚实的那把尺子。

第三个信号：看输入法。目标文字有没有被主流手机系统预装。没有的话，这套文字的查询量就有一个物理天花板。

## 把这三个信号写进排期表的哪一栏

信号跑完之后要落到排期表上，不然下次还得重跑。

建议在语言这一行后面加三列：网页侧目标文字占比、搜索建议有无、输入法预装情况。三列都填数字或者是否，不填描述。

这么做的好处是下一年复盘的时候能直接对比。一门语言从占比零到占比个位数，是个值得注意的变化；从搜索建议零条到有条，是个应该立刻重新评估的变化。把这几个数字记下来，比记一句“这个市场暂不做”有用得多，因为后者不告诉你什么时候该改主意。

小语种投资组合怎么定期复盘，那一篇 (https://zhangwenbao.com/minor-language-seo-2026-portfolio-review-invest-freeze.html)给过一套表格结构，这三列可以直接加进去。

## 别把政策当需求

这一条本来不用说，但见过太多次了：客户拿着一条当地的语言法规过来，要求内容必须按法规做，理由是合规。

要分清两件事。合规是合规——如果你的业务需要跟当地政府机关打交道，或者要投标、要办执照，那按法规做是必须的。但那属于公司文件和合同文本的范畴，不是网站内容的范畴。

网站内容的目标是被用户搜到和读懂。用户搜的是什么就做什么，法规说什么是另一条线。这两条线在多数市场是重合的，在正在做文字改革的市场会分开一段时间。

## 什么时候该提前进场

反过来说，提前进场也不是完全不可以，判据是这一条：你能不能承受一段没有回报的空窗期，以及这个市场的存量竞争有多薄。

蒙古语这边有个特点：因为大量存量内容用的是私有编码，那些内容在搜索侧等于不存在。上一批做缅甸语的时候观察到过类似的现象，当年那批用非标准编码的地址今天大多打不开，结论是这类刚做完或者正在做基础设施迁移的语言市场，竞争对手的历史积累比你以为的薄。

这个判断在蒙古语上同样成立，而且更极端：整个传统蒙文的搜索侧几乎是空的。如果哪天输入法这一层通了，先站住的人拿的是一个几乎没有竞争的市场。小语种优先级的成本模型那一篇 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)把这类前置投入怎么记账讲过，蒙古语属于其中最难算的一类：成本明确，回报的时间点不明确。

## 常见问题解答

## 蒙古语和内蒙古的蒙古语算不算同一门语言？

语言学上算同一门语言的不同方言，日常口语能互通。但书面上是两套完全不同的文字，互相不认识。做SEO的时候要按两个市场处理，因为搜索是打字进去的，打不出对方那套字，两边的查询就没有交集。词表、内容、审校全都要分开。

## 蒙古国网站为什么一个传统蒙文字符都没有？政策不是生效了吗？

那条法律约束的是国家和地方机关的官方文书，网站不在直接约束范围内。而且从政策文本到日常发布流程之间还有很长一段路：编辑要装输入法、系统要支持竖排、字体要采购。本文实测的21个站里传统蒙文占比是零，包括法律信息门户和统计局这类直接相关的机构。政策在推进，但网页这一层还没被推到。

## 页面上的传统蒙文能不能用图片代替？

不建议，理由跟别的语言一样：图片里的字搜索引擎读不到，也没法复制。但传统蒙文这边有个特殊情况值得说——很多站确实这么干了，因为竖排在旧浏览器上不好实现。如果一定要用图片，至少把同样的内容用真文字放进结构化数据或者隐藏的可访问文本里，别让整块内容对机器不可见。

## 那些私有编码的内容能自动转成标准Unicode吗？

可以，但要按字体族分别做映射表，因为不同厂商的私有区排布不一样。转换本身是查表替换，不难；难的是先判断这段字节用的是哪一家的排布。判断依据一般是页面声明的字体族名，以及私有码位的分布区间。转完之后要抽样让母语者核对，尤其是人名地名。

## 那几个不可见字符要不要在入库前清掉？

绝对不要。它们是这套文字的组成部分，清掉等于把词写错。这跟前端为了排版塞进去的软连字符、零宽空格完全相反，那些是应该清的。判断标准是：去掉这个字符之后母语者会不会认为写错了，会就不能清。做数据清洗的时候，字符白名单要把这个区间整体放行。

## 做蒙古国市场用什么关键词工具？

主流工具在西里尔蒙古文上有数据，虽然稀，但能用。本文实测的搜索建议接口在西里尔上返回得很正常，六个概念每个都能拉满十条长尾，够做基础的意图分类。真正没数据的是传统蒙文那一侧，那边只能靠抓内容做词频，而且能抓的语料本身就有一半是私有编码，得先清洗。

## 如果客户坚持要做传统蒙文版，怎么排期最稳？

先做一个最小可验证版本：三到五个页面，用标准Unicode写，配好字体和语言标签，上线之后观察收录和展现。不要一上来铺全站。同时把编码检查、字体加载、竖排版式这三项的工时单独列出来，让客户看清楚这部分成本跟内容量无关，是一次性的基础设施投入。观察三到六个月，看有没有自然流量进来，再决定要不要铺开。

## 权威参考资料



## 泰米尔语官方推荐的那个词写进正文很体面，放进词表一条带价格的长尾都拉不出来

- URL：https://zhangwenbao.com/tamil-seo-native-coined-vs-loanword-keyword.html
- 分类：小语种SEO
- 发布：2026-08-01  |  更新：2026-08-01
- 摘要：泰米尔语在四个市场有三种用词状态。用真实语料与搜索建议实测给出选词判据，并说明官方造词为什么拉不出商业长尾、短音译词为什么会被别的实体占掉整条查询。
- 关键词：关键词研究,跨境电商,多语言SEO,小语种SEO

> **TLDR**：摘要：泰米尔语有8600万母语者，分在印度泰米尔纳德邦、斯里兰卡、新加坡、马来西亚四套官方体系里。我抓了这四个市场的16个站点做逐码点统计，又跑了32组词的搜索建议，得到三个结论。第一，同一个日常概念，印度的媒体几乎只用英语音译词，新加坡的媒体几乎只用官方造的本族词，斯里兰卡两个都用，一门语言在四个国家有三种用词状态。第二，官方造的那套词写进正文很体面，可用户搜它主要是为了查它什么意思，加上价格修饰词之后能拉出的商业长尾只有音译词的三分之一。第三，开工前写下的两条预期全错了。

> 
摘要：泰米尔语有8600万母语者，分在印度泰米尔纳德邦、斯里兰卡、新加坡、马来西亚四套官方体系里。我抓了这四个市场的16个站点做逐码点统计，又跑了32组词的搜索建议，得到三个结论。第一，同一个日常概念，印度的媒体几乎只用英语音译词，新加坡的媒体几乎只用官方造的本族词，斯里兰卡两个都用，一门语言在四个国家有三种用词状态。第二，官方造的那套词写进正文很体面，可用户搜它主要是为了查它什么意思，加上价格修饰词之后能拉出的商业长尾只有音译词的三分之一。第三，开工前写下的两条预期全错了。

做小语种关键词表的人，最怕遇到的不是没数据，是数据里两个词都对。

泰米尔语就是这么一门语言。你想找“视频”这个词的泰米尔语说法，词典会给你两个：一个是官方造出来的本族词，一个是从英语音译过去的。母语审校说两个都能用。你把两个都放进表里，交付那天客户问你哪个该进标题、哪个该进正文、哪个该进结构化数据，你答不上来。

更麻烦的是，这两个词在四个国家的分布不一样。而这四个国家都把泰米尔语列成了官方语言。

## 为什么泰米尔语要按四个国家分开算？

## 八千六百万母语者，摊在四套官方体系上

泰米尔语的母语人口在8600万上下，规模跟德语差不多。但它跟德语有个根本区别：德语的三个市场挨在一起，泰米尔语的四个市场隔着海。

印度那一块最大，主要在泰米尔纳德邦和本地治里，人口占了大头。斯里兰卡北部和东部有几百万，泰米尔语是斯里兰卡的官方语言之一。新加坡把泰米尔语列成四门官方语言之一，实际使用者只有十几万。马来西亚没把它列成官方语言，但泰米尔语是当地印度裔社群的主要语言，有完整的泰米尔语学校体系和媒体。

这四块的共同点是：每一块都有自己的教育系统、自己的媒体、自己的政府文书标准。它们不是一个市场的四个省，是四个独立的语言治理单元。

## 把这门语言当一个市场做，会漏掉什么

常见的做法是这样的：先把泰米尔语当成印度市场的一门地方语言，用印度的关键词工具拉数据，建一份表，然后这份表同时用在新加坡站和马来西亚站上。

这个做法的问题不在于工具，在于它假设了一件没被验证的事——四个市场的人写同一个东西时用同一个词。

这个假设在很多语言上确实成立。葡萄牙语的巴西和葡萄牙差别不小，但差的是词汇的百分之几，不是整个概念都换一个词。泰米尔语这边我实测下来，有些概念的差别是整体性的：一个市场几乎只用A，另一个市场几乎只用B，中间没有过渡带。

这跟孟加拉语按一门语言建表交付时才发现国界两边不是一套词 (https://zhangwenbao.com/bengali-seo-two-markets-vocabulary-grapheme.html)那次遇到的情况有点像，但不完全一样。孟加拉语那边是两个市场，而且分叉是单向的；泰米尔语这边是四个市场，而且造词的那一头不在人口最多的地方。

## 四个市场的搜索入口不完全是一回事

还有一层容易被跳过：这四块的搜索入口结构不一样。印度和斯里兰卡是移动端为主、低端安卓机占比高，输入成本决定了查询会更短；新加坡的设备结构接近发达市场；马来西亚的泰米尔语使用者在日常里会大量切换到马来语和英语，泰米尔语查询只在特定场景出现。

这一层不属于本文要拆的语言层，但它会影响你怎么读数据。同一个词在印度的搜索量高，可能只是因为那边人多；在新加坡的搜索量低，可能是因为那批人搜的时候直接用了英语。做多市场的时候，跨市场比绝对搜索量基本没有意义，能比的是同一市场内部两个词的相对关系。

本文后面所有的对比都遵守这一条：只在同一个市场内部比两套词形的比例，不跨市场比数量。

## 本文不谈的那一半

泰米尔语落到工程上会牵出一大堆事：印度市场的书写系统排期、字体子集、输入法映射，这些在印度十一门语言分摊在九套书写系统上那一篇 (https://zhangwenbao.com/india-multilingual-seo-eleven-languages-nine-scripts-priority.html)里按成本口径算过一遍了，本文不重复。那篇的坐标系是印度国内的预算排期，泰米尔语在里面是一个成本项；本文的坐标系是这门语言自己，而且重心在国境之外的三块。

另外，本文只谈语言层。搜索引擎在这几个市场的份额、印度和新加坡的移动端生态差异，那些属于引擎层，跟这门语言是哪门语言无关，换成英语照样成立。判据一直是那一条：把语种换成英语就不成立的，才归这一层。

## 这次的实验台是怎么搭的

本文的数据来自两条腿。第一条腿是抓站：按四个市场各取一批本地媒体和政府站点，抓首页和内页，去掉标签只留文字，然后逐个字符按Unicode码点区间分类统计。第二条腿是搜索建议：同一批词分别用四个地区参数跑一遍，看返回什么。

四个市场的语料规模差得很远。印度这边抓到198页、51万多个泰米尔字符；斯里兰卡44页、约5万个；新加坡44页、9万多个；马来西亚只抓到169个泰米尔字符——这条腿实测失败了，后面会专门说为什么。

所有的比例都按每十万泰米尔字符归一化过，所以印度语料大十倍这件事不会把结论带歪。

## 泰米尔文只有十八个辅音，写不出来的音怎么办？

## 十八个自己的，六个借来的

泰米尔文是印度诸文字里辅音字母最少的一套，只有18个。这个数字不是简写，是真的只有18个辅音字母。对比一下：天城文有33个，孟加拉文有35个左右。

少的这些是什么？泰米尔语的音系里没有清浊对立，也没有送气不送气的对立。同一个字母 க 在词首读成k，在元音之间读成g，在鼻音后面读成 ŋg——读法由位置决定，所以不需要三个字母。

这套设计对写泰米尔语本身很经济，对写外来词就是灾难。英语的b、d、g、j、sh、s、h、z、f这些音，泰米尔文原生字母一个都写不准。

## 那六个借来的字母从哪儿来

历史上的解法是从Grantha文字里借。Grantha是南印度过去用来写梵语的一套文字，泰米尔文借了它的几个辅音字母进来，专门写梵语借词和后来的英语借词。

借进来的主要是这几个：ஜ（ja）、ஷ（ṣa）、ஸ（sa）、ஹ（ha），加上合体的 க்ஷ（kṣa）和 ஶ（śa）。这几个字母在Unicode的泰米尔文区块里有自己的码位，不是组合出来的。

所以泰米尔文的实际字母表是18个原生辅音加6个外来辅音。这6个字母在纯泰米尔的语境里是被排斥的——纯泰米尔运动一百年来的主张之一就是尽量不用它们。

这就构成了一个可以量的东西：数一个站上这6个借用字母的密度，就能量出它离“纯泰米尔”这条线有多远。

## 四个市场的借用字母密度，实测差了三倍

我把抓到的站点按泰米尔字符总量归一化，算了每一万个泰米尔字符里这几个借用字母出现多少次。

市场 | 站点 | 泰米尔字符 | 借用字母 | 每万字 | 

印度 | 傍晚花 | 1225 | 22 | 179 | 

印度 | 维卡坦 | 3300 | 50 | 151 | 

印度 | 迪纳马尼 | 10244 | 113 | 110 | 

印度 | BBC泰米尔 | 12622 | 138 | 109 | 

印度 | 迪纳马拉 | 18067 | 192 | 106 | 

斯里兰卡 | TamilWin | 7568 | 78 | 103 | 

马来西亚 | Makkal Osai | 5232 | 34 | 64 | 

新加坡 | 泰米尔之鼓 | 53392 | 326 | 61 | 

新加坡 | Seithi新闻 | 4125 | 9 | 21 | 

印度那一批全部落在106到179之间，斯里兰卡103，马来西亚64，新加坡21和61。最高的和最低的差了8倍，把样本量最小的两个去掉再比，印度和新加坡之间也稳稳差着一倍多。

## 这条数据打了我开工前的脸

动手之前我在实验计划里写了五条预期。其中一条是这么写的：新加坡的泰米尔语借词比例最高，因为那是个英语主导的环境。

实测正好相反。英语环境最重的那个市场，用借来的字母最少；纯泰米尔运动的发源地，用得最多。

把预期写下来这个动作，是上一批做缅甸语 (https://zhangwenbao.com/burmese-seo-zawgyi-unicode-byte-split.html)时逼自己加的。那次也是两条预期全错，而错的方向本身变成了那篇的题眼。这次又是同一回事——如果不写下来，我大概会顺着“新加坡英语多所以借词多”这个直觉去解释数据，然后把数据解释反。

## 这个密度差落到实操上是什么

一个外来词进泰米尔文，往往有两种合法写法：用借用字母拼得更接近原音，或者用原生字母凑一个近似。品牌名尤其如此。

所以同一个品牌在泰米尔文里可能有三到五种写法在跑，而且分布按市场不同。这件事的通用机制在品牌名叫什么不由你定、由当地用户的输入法定那一篇 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)里拆过，本文不重复，只补一句这门语言特有的：泰米尔文的两种写法不是拼写变体，是两套字母体系的选择，背后带着一个世纪的语言政治，所以哪种写法“对”这个问题在这门语言上没有中立答案。

## 两种写法在索引里等不等价

接着上面那条会冒出一个很实际的问题：如果同一个外来词有两种合法写法，搜索引擎把它们当成一个词还是两个词。

我没有办法直接看引擎内部，但可以从搜索建议侧面验证。做法是把两种写法分别丢进去，看返回的建议列表有没有交集。如果引擎把它们当同一个词，返回的长尾应该高度重叠。

实测下来的情况是：重叠很少。用借用字母写的那一版和用原生字母凑的那一版，各自拉出的十条建议基本是两批。这说明在建议这一层，它们是两个独立的查询串。

这个结论要谨慎用。建议层不等于索引层，引擎完全可能在检索时做同义扩展而在建议时不做。但对做词表的人来说，谨慎的假设是把它们当两个词，两个都覆盖到，而不是赌引擎会帮你合并。

顺带说一句，这跟希腊语那边用拉丁字母硬拼的情况不是一回事。希腊字母与拉丁转写并存时怎么覆盖那一篇 (https://zhangwenbao.com/greek-seo-greeklish-latin-transliteration-coverage.html)讲的是跨文字系统的转写，两套字符集完全不同；泰米尔语这边是同一套字符集内部，两组辅音字母的选择。前者用户一眼能看出是两种写法，后者看不出来。

## 同一个概念，一个市场全用造的词，另一个全用音译

## 先看最干净的那一组

我在四个市场的语料里跑了20组配对词。每组一个本族造词、一个英语音译词，指同一个东西。大部分组因为新闻语料里根本不谈那个概念，两边都是零——这个坑后面会说。真正跑出干净分叉的，是“视频”这一组。

本族造词是 காணொளி，字面意思接近“看的光”，是纯泰米尔路线造出来的。音译词是 வீடியோ，就是video用泰米尔字母拼出来。

市场 | 本族造词 காணொளி | 英语音译 வீடியோ | 本族∶音译 | 

印度 | 0 | 41 | 0（几乎只用音译） | 

斯里兰卡 | 84 | 40 | 2.1（两个都用） | 

新加坡 | 29 | 0 | 只用本族 | 

表里的数字是每十万泰米尔字符的出现次数。印度这边51万字符的语料里，本族词一次都没出现，音译词出现了两百多次；新加坡这边正好倒过来。

斯里兰卡在中间，而且不是“各占一半”那种中间——它是两个词都在高频使用，本族词还多一倍。这说明那边不是过渡状态，是真的两套词并行。

## 其余几组的方向一致吗

“视频”这一组之所以干净，是因为新闻网站每天都在发视频。其余概念的语料覆盖没这么好，但方向能看出来。

概念 | 印度 | 斯里兰卡 | 新加坡 | 

警察（本族 காவல் ∶ 音译 போலீஸ்） | 7 ∶ 1 | 4 ∶ 0 | 39 ∶ 0 | 

公司（本族 நிறுவனம் ∶ 音译 கம்பெனி） | 8 ∶ 1 | 12 ∶ 0 | 51 ∶ 0 | 

学生（本族 மாணவர் ∶ 音译 ஸ்டூடன்ட்） | 13 ∶ 0 | 34 ∶ 0 | 57 ∶ 0 | 

大学（本族 பல்கலைக்கழகம்） | 0 | 6 ∶ 0 | 4 ∶ 0 | 

公交车（本族 பேருந்து ∶ 音译 பஸ்） | 4 ∶ 1 | 8 ∶ 2 | 0 | 

本族词的密度排序基本稳定：新加坡最高，斯里兰卡次之，印度最低。这跟借用字母那张表给出的排序完全一致，两条独立的证据指向同一个方向。

## 但有一组是反的

“报纸”这个概念，新加坡的语料里本族词 செய்தித்தாள் 出现0次，音译词 பேப்பர் 出现22次；印度那边本族0、音译4。

这条反例很重要，它挡住了一个太顺的结论。如果只看前面那几组，很容易总结成“新加坡的泰米尔语更纯”。但报纸这一组说明不是这样——规范化的力量落在哪些词上，是有选择的，不是一刀切。

我的解释是这样：新加坡的泰米尔语规范主要通过教育系统和媒体自律起作用，管得住的是学校课本里教的那类词——机构名、职业名、学科名。“报纸”这种日常口语高频词，规范够不着，跟着口语走。

这个解释我没法用手上的数据证死，所以只当假说写在这儿。但它带出的操作建议是可靠的：别按“这个市场偏纯还是偏俗”给整份词表定调，要一个概念一个概念地问。这跟上一批做孟加拉语时得到的教训是同一条——那次也是发现规律只能逐词问，按对称分叉建表两边同时漏。

## 三种状态，三套动作

把印度、斯里兰卡、新加坡三种状态摆在一起，对应的动作其实不一样。

印度那种几乎只用音译的市场，动作是替换：把词表里的本族词整批换成音译词，本族词只在正文对照处保留一次。这个市场的读者看到本族词不会不认识，但会觉得像在读课本。

新加坡那种几乎只用本族词的市场，动作是反过来的：正文用本族词，音译词退到标题和技术字段里。这里有个矛盾要接受——页面上给人读的词和给引擎看的词可以不一致，而这不是作弊，因为两个词在同一个页面上共现过。

斯里兰卡那种两个都在用的市场，动作是并列覆盖：两个词都要在正文里自然出现若干次，不能只挑一个。上一批做孟加拉语时得到过一条同类的教训——分叉是单向的时候，按对称建表两边都会漏。这里是分叉不存在，按二选一建表照样漏一半。

三种状态对应三套动作，而判断落在哪一种，只能靠语料实测。这也是为什么本文花那么大篇幅在抓站上。

## 马来西亚这条腿实测失败了

四个市场里马来西亚是最难抓的。我准备了5个种子站点：两个域名解析不了，一个抓下来是纯英文站，一个只放出1个内页，最后合计只拿到169个泰米尔字符。

这个数量做不了任何统计。所以本文关于马来西亚的结论只有借用字母那一条（64/万，来自Makkal Osai的5232个字符），词汇分叉那部分完全没数据。

把这条如实写出来，比补一段“马来西亚的情况大致介于两者之间”有用。后者听起来完整，实际是编的。做小语种最容易出的事故就是这个：数据缺的那一块，用常识补上去看不出破绽，但它会一路错到交付。

## 顺带记一条尺子的事

20组词里有6组两边全零，另有几组只有一边有数。原因不是这门语言不用这些词，是新闻语料不谈冰箱、空调和耳机。

要量商业品类词的分叉，得换语料源——电商站、分类广告、比价站。这次没做，因为四个市场里能同时找到可比电商站的只有印度和新加坡，两个点连不成线。这一条留给下次。

## 为什么造词的那一头不在人口最多的市场？

## 纯泰米尔运动造了多少词

泰米尔语有一场持续了一个世纪的语言纯化运动。它的现代起点通常算在1916年，主张是避开梵语、英语和波斯语借词，能造本族词就造本族词。

这不是几个学者的私下主张。1959年泰米尔纳德邦政府成立了专门的机构，负责用泰米尔语编写自然科学、人文学科、会计、数学的教科书，这意味着大批学科术语要现造。到1970年代末，被造出来并推广开的新词超过一千个。

所以“视频”“电脑”“手机”“电话”这些概念在泰米尔语里都有官方推荐的本族词，而且这些词进了教科书。

## 造词的机构在印度，用词最规范的市场在新加坡

这里有个反直觉的地方：造词这件事发生在泰米尔纳德，而实测下来用得最彻底的是新加坡。

我能想到的原因有两层。

第一层是媒体结构。印度的泰米尔语媒体是充分竞争的商业市场，几十家在抢同一批读者，用词跟着读者的口语走。新加坡只有一份泰米尔语报纸和一个广播电视机构，它们同时承担着语言传承的公共职能，用词跟着课本走。

第二层是社群规模。使用者只有十几万的社群，学校、媒体、社团这几个口子是重叠的——教泰米尔语的老师和给报纸写稿的人可能是同一批。八千万人的社群不存在这种重叠。

社群越小，语言规范的执行力反而越强。这条规律看着别扭，但它在别的语言上也见得到：冰岛语的造词纯度高于任何一门大语言，就是同一个机制。

## 这对做站的人意味着什么

意味着你不能问“泰米尔语的标准说法是什么”，只能问“哪个市场的标准说法”。

而且这两个问题的答案往往冲突。你在印度市场按新加坡的规范写，读者会觉得像课本；在新加坡市场按印度的口语写，机构客户会觉得不正式。

这跟同一门语言在两个市场意图会怎么漂移那一篇 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)说的是同一族的事，但那一篇拆的是意图，这里拆的是词形本身。词形分叉是意图漂移的上游——两个市场连用词都不一样的时候，意图数据是拿不出来的，因为你查的根本不是同一个词。

## 这条规律有没有反例

社群越小规范执行力越强这条，我得给它划个边界，不然它会被用过头。

反例是存在的。海外华人社群规模不小，用词却比大陆和台湾都随意，因为它没有统一的教育系统去承载规范。所以真正起作用的不是社群大小本身，是社群里有没有一套覆盖全体成员的教育和媒体系统。新加坡的泰米尔语社群小，但它的每一个孩子都进同一套学校，看的是同一份报纸。

把这条判据反过来用更好使：判断一个市场偏规范还是偏口语，先看它的泰米尔语媒体有几家。只有一家的市场偏规范，几十家的市场偏口语。这个判断五分钟就能做完，比读语言政策文件快得多。

## 用户搜那个标准词的时候，到底在找什么？

## 先说这一轮为什么要换尺子

语料只能告诉你媒体写哪个词，告诉不了你用户搜哪个词。这两件事完全可以不一致——媒体写的是规范，用户搜的是习惯。

我第一轮用的尺子是搜索建议的地区参数：同一个词分别用印度、斯里兰卡、新加坡、马来西亚四个地区跑，看返回的建议有没有差别。

结果是彻底失败。四个地区返回的条数完全一致，抽样比对内容也逐条相同。“视频”的音译词在印度和新加坡拉出来的十条建议，一个字都不差。

这条负面结果得写出来。它意味着对泰米尔语这样的语言，别指望用地区参数把四个市场分开，那个参数在这门语言上不起作用。想分市场，只能回到语料。

## 换的这把尺子是什么

失败那一轮里我注意到一个现象：本族造词拉出来的建议，第二条往往是“meaning in english”或者泰米尔语的“意思”“什么意思”。

比如 நிழற்படம️（本族词，照片）的六条建议里，三条是查词义的：意思、英文意思、泰米尔语意思。而音译词 போட்டோ 的十条建议全是“怎么修图”“修图教程”这类。

这个现象可以量化。我给建议做了三个标记：带meaning、意思、什么意思这类问法的算查词义；带价格、买、在线、优惠这类的算商业；建议开头不是查询词本身的算被别的实体劫持。

## 查词义成分：本族词是音译词的六倍

16组词跑下来的汇总：

词形 | 建议总数 | 查词义 | 商业 | 被别的实体劫持 | 

本族造词 | 138 | 17（12%） | 3（2%） | 10（7%） | 

英语音译词 | 141 | 3（2%） | 2（1%） | 14（9%） | 

12% 对2%，六倍。

这个数字要怎么读？搜本族造词的人里，有相当一批不是要买东西，是在查这个词是什么意思。他们可能是学生在做作业，可能是看到官方文书上一个不认识的词回来查。

这不是坏事，但这类流量转化不了。你围绕这个词做的商品页，接住的是查词典的人。

## 加上价格修饰词之后，差距更大

光秃词的建议条数看不出多少东西，绝大多数词两边都能拉满十条。真正分得开的是加修饰词之后——我在每个词后面加了泰米尔语的“价格”，再跑一遍。

概念 | 本族造词 + 价格 | 音译词 + 价格 | 

手机 | 0 | 10 | 

空调 | 0 | 10 | 

电视 | 3 | 10 | 

公交车 | 4 | 10 | 

电脑 | 1 | 4 | 

视频 | 0 | 2 | 

银行 | 0 | 2 | 

市场 | 10 | 10 | 

16组合计 | 18 | 58 | 

本族造词一共拉出18条带价格的长尾，音译词58条，3.2倍。

逐词看更刺眼：手机和空调这两个纯电商品类，本族词是零。不是少，是零。你按官方推荐词建的表，在这两个品类上一条长尾都没有。

## 唯一打平的那一组说明了什么

16组里只有一组两边都是10条：சந்தை（市场）对 மார்க்கெட்。

为什么这一组不分裂？因为 சந்தை 不是造出来的新词，它是泰米尔语里本来就有的老词，指集市。它跟“视频”“电脑”那类词的区别是：没经历过“先有英语概念、再造一个本族词去对应”这个过程。

这就给出了一条筛选判据：本族词是老词还是新造词，决定了它在搜索里有没有商业意图。老词能用，新造词要留神。判断办法很土但管用——去查这个词在1950年之前的文献里有没有，或者直接看它的构词是不是明显的意译拼装。

## 那正文里到底该用哪个

我的结论是两个都用，但角色不同。

标题、H2、URL、结构化数据里的品类字段用音译词，因为那是用户会打进搜索框的那个词。正文第一次出现的时候两个都写一次，用括号带上另一个，让搜索引擎看见这两个词在同一个页面上共现。之后正文按目标市场的习惯选一个用到底。

这个做法有个额外好处：本族词那部分查词义的流量，你也接得住。搜“这个词什么意思”的人落到你的页面上，看到括号里的对照，问题当场解决了，顺带看到了你的商品。长尾问答类内容在AI时代还值不值得做那一篇 (https://zhangwenbao.com/minor-language-qa-long-tail-content-value-ai-era.html)算过这类流量的账，结论不是它没价值，是它的价值不在直接转化上。

## 怎么在自己的品类上把这套测量跑一遍

这套测量不复杂，任何人都能在自己的品类上重跑一遍，步骤是四步。

第一步，列出你品类里最核心的10到20个概念，每个概念找出本族词和音译词两种写法。找的办法不是查词典，是去目标市场的媒体站上搜这个概念，看正文里用的是哪个。

第二步，把这两套词分别丢进搜索建议，记下返回的条数和内容。别只看条数，要看内容——条数满十条不代表这些建议跟你的品类有关。

第三步，给每个词加上本地语言的价格、购买、在线这类修饰词，再跑一遍。这一步是分水岭，光秃词分不出来的东西，加了修饰词就分出来了。

第四步，把两套词的商业长尾条数拉个对比。差三倍以上的，直接按多的那一套建表；差一倍以内的，两套都要覆盖。

整套流程半天能跑完，不需要付费工具。它替代不了母语审校，但它能让你带着具体问题去找审校，而不是拿一份表问他对不对。

## 短音译词为什么反而更危险？

## 那个例子有点好笑

“电视”的音译词是 டிவி，就是TV两个字母的泰米尔文写法，两个字符。我拿它去跑搜索建议，返回的十条里没有一条跟电视机有关。

前四条是这样的：TVS踏板车新款、TVS踏板车价格、TVK家族、TVK卡片。TVS是印度一个摩托车品牌，TVK是泰米尔纳德一个政党的缩写。

这个查询词被两个更强的实体整个占了。你想做电视机品类，用这个词做锚，一条流量都拿不到，全被摩托车和政党分走了。

## 为什么短音译词特别容易出这事

音译进泰米尔文的英文缩写，长度会被压得很短。TV两个字母对应两个泰米尔字符，AC也是两个。而泰米尔文的字符信息密度比拉丁字母高，两个字符已经能构成很多别的词的词头。

结果就是：短音译词天然是一堆更长的词的前缀，而搜索建议按前缀匹配。谁的搜索量大谁占坑，你的品类词只要不是那个最大的，就看不见。

“空调”的音译词 ஏசி 也是同一个毛病，返回的第一条是 ஏசியன் 开头的油漆品牌。

## 怎么在起草前就发现这件事

办法很简单：把候选词丢进搜索建议，看返回的第一条是不是你要的东西。不是的话，这个词就不能单独用做锚，必须带修饰词。

这一步花不了五分钟，但省下来的是一整个品类页的白工。缩略语在小语种里的一般规律在首字母缩略语的本地形态与变格那一篇 (https://zhangwenbao.com/minor-language-acronym-initialism-local-forms-inflection.html)里拆过，那篇讲的是缩略语怎么变形，本文这一条讲的是变形之后撞车，是同一件事的下游。

## 被劫持的比例，两种词形差不多

回到那张汇总表：本族词被劫持7%，音译词9%，差别不大。所以这不是“音译词更容易被劫持”，是短词更容易被劫持，而音译词里短词更多。

本族造词那边被劫持的十条里，有一半来自“冰箱”这一组——那个本族词 குளிர்சாதனப்பெட்டி 长得离谱，反而是因为写法不统一（有的分写有的连写），建议把两种写法都算进去了。

这个细节顺带说明：长词的问题不是被劫持，是写法不统一。两种毛病，两套查法。

## 长音译词的毛病是另一种

短音译词被劫持，长音译词的问题反过来：太长了没人打全。

“电脑”的音译词 கம்ப்யூட்டர் 有九个字符，把computer一个音节不落地拼了出来。它在搜索建议里能拉满十条，但那十条里有一半是学科相关的问法，比如学计算机专业能找什么工作。真正的电脑品类长尾在本族词 கணினி 那边反而更集中。

这就构成了本文那个主结论的一个例外：音译词更有商业意图这条规律，在音译词特别长的时候会松动。长音译词打起来费劲，用户会退回到更短的那个词，哪怕它是造出来的。

判据是字符数。泰米尔文里超过六个字符的音译词，就要单独验一遍，别默认它比本族词强。这跟移动端输入成本是同一回事——键盘上多敲三下的成本，在低端机上比想象中大。

## 屏幕上的顺序和存储里的顺序为什么对不上？

## 三个写在辅音左边的元音符号

泰米尔文有三个元音附标是写在辅音左边的：ெ、ே、ை。但在Unicode的存储顺序里，它们排在辅音后面。

也就是说，你在屏幕上看到的是“元音符号 + 辅音”，字节流里是“辅音 + 元音符号”。排布引擎负责把它挪到左边显示，这是正确行为，不是bug。

## 四个市场实测：3.9% 到5.2%

我顺手在同一批语料上数了这三个符号占泰米尔字符的比例：

站点 | 泰米尔字符 | 左置附标 | 占比 | 

迪纳马拉（印度） | 18067 | 829 | 4.5% | 

每日灯塔（印度） | 3786 | 197 | 5.2% | 

BBC泰米尔（印度） | 12622 | 549 | 4.3% | 

TamilWin（斯里兰卡） | 7568 | 328 | 4.3% | 

泰米尔之鼓（新加坡） | 53392 | 2540 | 4.7% | 

Makkal Osai（马来西亚） | 5232 | 268 | 5.1% | 

四个市场、九个站点，全部落在3.9% 到5.2% 之间。这是本文里唯一一个跟市场完全无关的数字。

## 一个不变的常量，反而更有用

前面所有的数据都在讲分叉，这一条讲的是不分叉。它有用的地方在于：凡是跟这个比例挂钩的工程问题，四个市场是同一个答案，不用分开测。

具体是哪些问题？按字符数截断标题的时候，每20个泰米尔字符里大概有1个是这种左置附标，截断点落在它和它的辅音之间，屏幕上就会出现一个孤立的元音符号。导出PDF再抽文字层的时候，某些导出路径会把挪完位置的显示顺序当成存储顺序写回去，抽出来的字符串顺序就乱了——这件事在那页规格书在屏幕上是好好的泰语、机器复制走的是另一串字符那一篇 (https://zhangwenbao.com/minor-language-pdf-text-layer-extraction-failure.html)里有一节专门拆过，泰米尔文和天城文都在里面。

还有一处容易漏：正则表达式按字符切的时候，这三个符号是独立字符，不是修饰符。你写一个“取前30个字符”的截断逻辑，在泰米尔文上切出来的可能是半个音节。

## 字素簇这件事在泰米尔文上要留神

接着上面那条常量再往下走一步：泰米尔文的一个视觉字符，在字节层面可能是两到三个码点。辅音加元音附标是最常见的组合，辅音加止符（消音符号）再接另一个辅音也很常见。

所以“这个标题有多少字”这个问题，在泰米尔文上至少有三个答案：多少字节、多少码点、多少字素簇。三个数能差出一倍。

需要按字素簇算的地方有三处：标题截断、输入框的字数限制、平台字段的额度。凡是给用户看的长度限制都要按字素簇算，凡是给存储用的额度都要按字节算，两者混用就会出现输入框显示还剩十个字、提交时报超长的情况。

平台字段那一层的账在平台给每个卖家的搜索词字段一样长那一篇 (https://zhangwenbao.com/minor-language-marketplace-listing-fields-tokenization.html)里算过，那篇算的是日语，泰米尔文的膨胀率更高一些，因为它的常用字符在UTF-8里是三字节。

## 一份泰米尔语关键词表的建法

## 第一步不是翻译，是分市场抓语料

如果你从英文词表翻译起步，得到的会是一份混合体：译者按自己的习惯在两套词里挑，而他的习惯来自他成长的那个市场。你拿到的表看不出这一层，因为它长得很整齐。

正确的起步是抓语料，而且要分市场抓。目标市场是新加坡就抓新加坡的站，是印度就抓印度的站。每个市场至少凑到十万个泰米尔字符，做词频，再去跟译者讨论。

这套做法在关键词工具在小语种上没数据时的几种绕法那一篇 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)里有完整流程，本文只补泰米尔语特有的一步：抓完之后先算借用字母密度，这个数能告诉你这批站属于规范一侧还是口语一侧。密度低于70的那批，词表偏规范；高于100的，偏口语。

## 两套词都进表，但字段不同

建议的分工是这样的。

位置 | 用哪套词 | 理由 | 

标题、H2 | 音译词 | 用户打进搜索框的是这个 | 

URL路径段 | 音译词的拉丁转写 | 本地字母URL的取舍另有一套账 | 

结构化数据品类字段 | 音译词 | 跟标题保持一致 | 

正文首次出现 | 两个都写，括号并列 | 让两个词在同一页共现 | 

正文其余部分 | 按目标市场选一个 | 读起来要像本地人写的 | 

面包屑、导航 | 按目标市场选一个 | 跟正文保持一致 | 

URL那一行要多说一句。泰米尔文的URL用本地字母还是拉丁转写，是个独立决策，跟词形选择不是一回事，地址栏里写本地文字还是拉丁转写那一篇 (https://zhangwenbao.com/minor-language-url-native-script-vs-latin-transliteration.html)把利弊算过。本文的建议只是：无论选哪套，四个市场要统一，别新加坡站用一套印度站用另一套。

## 母语审校要问的三个问题

找母语审校的时候，光问“这个词对不对”会得到“都对”。要问得更具体。

第一个问题：你在哪个市场长大的、在哪个市场工作。这决定了他默认站在哪一侧。四个市场的人对同一份稿子的判断会不一样，这不是审校水平问题。

第二个问题：这个词你会写进给客户的邮件里，还是只会写进给同事的消息里。这个问题能把语域问出来，比问“正不正式”有效。

第三个问题：如果你要在网上买这个东西，你会打哪个词。注意问的是“打”不是“说”——很多人说的和打的不是一个词。

母语审校的验收流程另有一篇专门写过 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)，那套清单在这门语言上照用，只需要在“审校来自哪个市场”这一格上多花点心思。

## 一张能贴在评审清单上的表

检查项 | 做法 | 不通过的表现 | 

词表有没有分市场 | 看表里有没有市场这一列 | 只有一列词 | 

本族词是老词还是新造词 | 查它有没有明显的意译构词 | 新造词被放进了标题字段 | 

短音译词有没有被劫持 | 丢进搜索建议看第一条 | 返回的是别的品牌或机构 | 

借用字母密度 | 数那六个字母占比 | 跟目标市场的媒体差一倍以上 | 

截断逻辑 | 按字素簇切还是按码点切 | 标题末尾出现孤立元音符号 | 

两个词有没有共现 | 正文首次出现处检查 | 整页只出现一套词 | 

## 四个市场，先做哪一个

如果四个市场都在候选里，排期建议是这样的。

印度优先，理由不是人口，是语料最容易拿。这门语言的公开语料、媒体站、搜索数据，绝大部分产自印度。你在这个市场上建起来的方法论和工具链，能原样搬到另外三块。

新加坡第二，理由是它的规范最清晰，验收标准最容易定。这个市场做完，你手上会有一份偏规范的对照词表，回头能拿去校验另外三块。

斯里兰卡第三，两套词并行意味着容错高，前面两块的内容都能部分复用。

马来西亚最后，理由跟本文那次抓取失败是同一个：这个市场的泰米尔语内容基础设施最薄。薄有薄的好处——竞争对手的历史积累也薄，这一点跟上一批做缅甸语时的观察是同一条。但薄也意味着你连拿来做对照的语料都不好找。

这个排序跟按GDP或者按人均消费排出来的顺序不一样。做小语种排期，语料可得性是一个应该被写进表里的因素，而多数排期表上没有这一列。成本模型那篇算过一次性工程成本怎么摊，语料这一项属于同一类：它是前置投入，不是运营开销。

## 这套判断能搬到别的语言上吗？

## 先问这门语言有没有一个在造词的机构

泰米尔语这套分析之所以成立，前提是这门语言里存在一股有组织的造词力量，而且它造出来的词进了教科书但没进日常口语。

符合这个条件的语言不多，但也不算少。冰岛语是最典型的，它的造词机构历史更久、覆盖更全。法语在魁北克那一侧有类似的机制，法国本土的机构也造词但执行力弱得多。印度尼西亚语有官方的术语委员会，造出来的词和民间用的英语借词同样在打架。

判断办法：去查这门语言有没有一个官方或半官方的术语机构，以及它的产出有没有进入基础教育。有的话，你的词表就一定要按“规范词”和“口语词”两列建。

## 没有这类机构的语言，问题换一个形状

没有造词机构的语言，外来词一般直接借形或借音，不会出现两套并行的完整词表。那边的问题变成了另一个：借来的词要不要变格、要不要定性别、复数怎么加。

德语、荷兰语这类语言的麻烦全在这一层，品牌名进德语市场之前要先定它算公的还是母的那一篇 (https://zhangwenbao.com/minor-language-loanword-gender-assignment-brand-article.html)拆的就是这个。两类语言的共同点是外来词处理不掉，区别在于处理的方式：一边是造个新词替掉它，一边是把它塞进语法框架里。

## 什么时候可以不管这件事

有一种情况可以简化：目标市场只有一个，而且你的品类是纯电商品类。

这种情况下直接用音译词建表，本族词只在正文里出现一次做对照就够了。前面那些分市场的功夫，是给同时做多个市场的人准备的。

但要注意一个例外：如果你的品类跟教育、政府采购、医疗这几个领域沾边，本族词的权重会上来，因为那些领域的文书本来就走规范一侧。品类决定了这两套词哪一套更重要，比市场决定的还多。

## 常见问题解答

## 泰米尔语和印度其他语言能不能共用一份关键词表？

不能。泰米尔语属于达罗毗荼语系，跟印地语、马拉地语这些印欧语系的语言没有亲缘关系，词汇、语法、书写系统全都不一样。唯一能共用的是流程和工具链，不是内容。印度十一门语言的成本怎么摊，按书写系统算比按语言算更准，这件事那篇印度多语言的文章里有完整的账。

## 为什么我的关键词工具查泰米尔语的搜索量总是很低？

两个原因叠在一起。一是工具在这门语言上的数据本来就稀，很多长尾会被记成零；二是你查的可能是本族造词那一套，而用户实际打的是音译词。先用搜索建议做一次交叉验证：把同一个概念的两套词都丢进去，看哪一套能拉出带修饰词的长尾，那一套才是有量的。

## 新加坡站和印度站的泰米尔语页面算不算重复内容？

用词真的分叉的情况下不算，因为正文实际上不一样。但如果你只是把同一份稿子换个域名发两遍，那就是重复内容，跟语言无关。稳妥的做法是把这两个市场当两份内容做，用hreflang按语言加地区标注，让引擎知道它们服务的是不同地区。地区级hreflang的写法属于架构层，跟这门语言是哪门语言没关系。

## 那六个借用字母要不要在词表里做归一化？

不要。它们是独立的合法字母，不是同一个字母的两种写法，归一化会把不同的词合并掉。真正需要归一化的是同一个外来词的多种拼法——那些是拼写变体，应该在同义词层处理，而不是在字符层。这两件事很容易混，判据是：换掉这个字符之后词的读音变不变，变了就是不同的词。

## 做泰米尔语市场必须找当地服务商吗？

不必须，但审校环节绕不过母语者，而且要挑对市场。抓语料、算词频、跑搜索建议这些活自己就能干，本文用到的全部数据都是用公开接口和普通抓取拿到的，没用任何付费工具。真正需要本地人的是最后那一步判断：这句话读起来像不像本地人写的。

## 斯里兰卡的泰米尔语要不要单独做一套内容？

看品类。斯里兰卡实测下来是两套词并行，所以那边对两种写法的容忍度最高，用印度那套或新加坡那套读者都能看懂。如果预算紧，斯里兰卡可以先复用印度的内容，只把几个高频品类词换成当地更常用的那个。但如果你的品类涉及本地服务、配送、售后，那还是得单独做，因为那些内容本来就跟地区绑死。

## 本文的数据能复现吗？

能。抓站部分是标准的HTTP请求加正则去标签，统计部分是按Unicode码点区间分类计数，搜索建议用的是公开的建议接口加地区参数。唯一的门槛是马来西亚那批站不好抓，本文也确实没抓到——这一段是失败记录，不是省略。

## 权威参考资料



## 缅甸语网页在七年里换掉了一整套字节，当年那批旧页面今天一条都打不开

- URL：https://zhangwenbao.com/burmese-seo-zawgyi-unicode-byte-split.html
- 分类：小语种SEO
- 发布：2026-08-01  |  更新：2026-08-01
- 摘要：缅甸语曾有两套互不兼容的编码并存。给出一套两天能跑完的排查流程，从站上字节、外部来稿到站内搜索输入端逐层检查，并说明字体族名这类只在这门语言上出事的位置。
- 关键词：技术SEO,多语言SEO,小语种SEO,东南亚市场

> **TLDR**：摘要：缅甸语的网页在2016到2021年之间整体换了一套字节。保哥用官方检测模型跑了50个缅甸语站点，今天一个旧编码都找不到了；再把时间轴倒回去，旧编码的占比从2016年的三分之二一路掉到2021年的零。真正的账在后面：当年用旧编码写的那21个页面，今天一条都打不开。

> 摘要：缅甸语的网页在2016到2021年之间整体换了一套字节。保哥用官方检测模型跑了50个缅甸语站点，今天一个旧编码都找不到了；再把时间轴倒回去，旧编码的占比从2016年的三分之二一路掉到2021年的零。真正的账在后面：当年用旧编码写的那21个页面，今天一条都打不开。

## 一门语言的网页换掉了一整套字节，这件事今天还剩下什么？

## 一家做离网太阳能的站，缅甸语页面在两拨用户眼里长得不一样

有个客户做离网太阳能，主力是太阳能板、控制器、蓄电池和一体化照明套件，客户以农村家庭和小商铺为主。

泰国和越南做了两年多，路子摸熟了，往缅甸延伸是顺理成章的一步——这个市场的电网覆盖不全，离网设备是刚需，竞争也稀薄。

建站找的是本地服务商，理由很充分：本地团队懂本地用户，模板现成，上线快。

缅甸语版上线四个月，自然流量几乎是零。团队请了一位缅甸同事看页面，对方的第一句反馈是：字是错的。

可团队自己打开是正常的，两个人对着同一个网址各自截图，截出来的东西不一样。

## 差别在那位同事的电脑上装了一套字体

本地服务商给的模板里，样式表指定了一个字体族名，那是当年那套非标准字体的名字。

内容本身是标准编码写的——这一点没错，翻译交付的时候用的就是标准输入法。

问题是那套字体按非标准编码的码位分配来摆字形。用它去渲染标准编码的文本，每一个字符都会被摆到错误的位置上。

装了那套字体的人看到的是一堆错位的笔画，没装的人看到的是正常缅文。

团队所有人的电脑都没装，那位缅甸同事的电脑上装了，因为他还在用一部老手机同步过来的字体配置。

## 还有第二个坑，藏在历史内容里

这个站还做了一件很自然的事：把本地服务商手上的一批旧内容导了进来，充实分类页。

那批内容是2017年前后写的，用的是非标准编码。导进库之后，页面上看着没问题，因为它们配的正好是那套字体。

于是这个站同时存在两套字节：新内容是标准编码，老内容是非标准编码，而搜索引擎把它们当成两门语言在处理。

本站讲字最少的那几类页面最容易被机器认成另一门语言 (https://zhangwenbao.com/minor-language-page-language-detection-misidentification-short-text.html)那一篇里说过，机器不完全相信你写在页面上的语言声明，它会自己数字符。这个站给它数出来的是一堆认不出来源的字节。

这两个坑加起来，就是本篇要拆开讲的那件事的两种典型形态：一个是字体和字节对不上，一个是站内两套字节并存。

## 先说清楚这不是乱码问题

做小语种站的人对乱码不陌生。页面没声明编码、数据库排序规则配错、导出的表格用错了字符集，这几类问题本站在词表被表格工具改坏那一篇 (https://zhangwenbao.com/minor-language-keyword-table-spreadsheet-corruption.html)里写过完整的排查路径。

缅甸语这一件不属于那一类。

它的形态是：页面的字符集声明是对的，字节是合法的UTF-8，浏览器不报任何错，屏幕上的字看着也是缅文。可这串字节和标准里规定的那串，不是同一串。

换句话说，不是编码坏了，是这门语言曾经有过两套互不兼容的编码同时在跑，而且用得多的那一套不是标准那一套。

## 这套非标准编码是怎么来的

缅文进Unicode很早，可早期系统对缅文的渲染支持一直跟不上——这门文字的字符要上下堆叠、要根据前后文换形，渲染引擎不支持的话，标准编码写出来的字在屏幕上就是散的。

于是本地做了一套字体，绕开渲染引擎，把每一个可能出现的字形单独占一个码位，靠字体自己摆位置。这样在任何一台不支持复杂文字渲染的机器上，缅文都能正常显示。

它占用的码位范围跟标准是同一段。Unicode官方那份缅甸文常见问题 (https://www.unicode.org/faq/myanmar.html)里把这件事写得很直白：两套编码使用同一个码位区间，而非Unicode的字体给同一个字符的不同部件分配了多达8个码位。

同一份区间，两套分配方案，谁也不知道对方在。这就是问题的全部。

## 值得说一句：当年选它的人没有做错

今天回头看很容易得出一个结论：本地人图省事，绕开标准，结果给所有人留了个坑。

这个结论不公平。

标准编码要能正常显示，前提是渲染引擎支持复杂文字整形。这个前提在2010年前后的低价安卓机上根本不成立，而那批机器就是缅甸绝大多数人上网的全部工具。

摆在当时的选择是：按标准写，一半用户看到的是散架的字；按那套字体写，所有人都能看。

换成谁都会选后者。这套编码不是偷懒的产物，是一个在当时条件下唯一能跑通的工程方案。

它变成问题，是因为条件后来变了而它没退场。这个结构在小语种里很常见——本站讲网站上所有的字都是给用户读的、只有域名这一串要他自己打出来 (https://zhangwenbao.com/idn-punycode-local-script-domain-input-trust.html)那一篇里也有同一个形状：一条链上的支持程度永远由最弱的那一环说了算，而最弱那一环会随时间移动。

## 为什么它能赢，以及赢了多久

它赢是因为它解决了当下的问题。2010年前后缅甸开始大规模上网，手机是主要入口，而那批手机的系统渲染能力很弱。

用户装一个字体就能看见缅文，不装就是一屏方块，这个选择没有悬念。

结果是整整一代缅甸语的网页内容、社交内容、聊天记录，都是用这套非标准编码写的。

官方的迁移日定在2019年10月1日。本篇后面第四节会给出保哥自己测的那条曲线，它跟这个日期的关系比预想的有意思。

## 这一层归语言层管，边界在哪

先把不归本篇管的交出去。

页面怎么声明字符集、数据库用什么排序规则、CDN怎么处理内容类型，这些是通用工程问题，换任何一门语言都一样。

本篇要处理的是把语种换成英语就不存在的那一半：同一句缅甸语，在两套编码下是两串完全不同的字节，而搜索引擎匹配的是字节。用户打进搜索框的那一串跟你页面上那一串对不上，就等于你不在。

这一层跟本站写过的西里尔页面在Windows-1251时代的编码遗留 (https://zhangwenbao.com/cyrillic-encoding-legacy-windows1251-utf8-indexing-cost.html)是同族但不同种。那一篇讲的是UTF-8之前的八位编码，属于历史阶段的正常残留；缅甸语这一件发生在UTF-8之内，两套方案都是合法的UTF-8字节流，工具层面一个警告都不会给你。

## 两套编码的差别，落到码位上到底差在哪？

## 拿五个词逐个摊开

保哥把五个日常词的两种写法逐个打印了码位序列，差异分成三类，一类比一类狠。

## 第一类：只差一个码位，肉眼几乎看不出

手机这个词，两套编码都是5个码位、15个字节，长度完全一样。

差别只在第4个码位上：标准那一套用的是止音符号U+103A，非标准那一套用的是叠写符号U+1039。

这两个字符在屏幕上渲染出来的形状极其接近，把两个词并排放在一起，不懂缅文的人看不出区别，懂缅文的人也得盯一会儿。

可对搜索引擎来说，这是两个不同的字符串，交集为零。

## 第二类：码位数不一样，还借用了别人的地盘

价格这个词，标准那一套是9个码位27个字节，非标准那一套是8个码位24个字节。

少掉的那一个是因为非标准编码把两个字符合成了一个预置字形，而那个预置字形占的码位是U+108F和U+1088。

这两个码位在Unicode标准里不是缅甸语的，是分给掸语的。也就是说，一段缅甸语文本里会混着标准分配给另一门语言的字符。

本站讲波斯语和阿拉伯语共用一套字母 (https://zhangwenbao.com/persian-seo-iran-market-letters-digits-zwnj.html)那一篇里有一段讲同一个词两套码位怎么在索引里对齐，机制类似但成因不同：那边是两门语言的字符长得一样，这边是一套字体擅自占用了另一门语言的码位。

## 第三类：顺序反了

这一类最彻底。缅甸这个词本身就是样本。

标准那一套的码位序列是辅音在前、介音在后，遵循的是逻辑顺序，渲染引擎负责把介音摆到辅音左边去显示。

非标准那一套直接按视觉顺序存：介音在前、辅音在后，字体不需要做任何重排。

两串字节的第一个字符就不一样，长度还都是6个码位18个字节。

这一类的杀伤力在于它连前缀匹配都救不了。前两类至少还有共同的开头，第三类连起手式都是反的。

## 把这三类放在一起看

差异类型 | 样本词 | 码位数 | 能不能靠前缀匹配捞回来 | 

单码位替换 | 手机 | 5对5 | 能捞回一部分 | 

码位数不同、占用他语码位 | 价格 | 9对8 | 基本捞不回 | 

存储顺序相反 | 缅甸 | 6对6 | 完全捞不回 | 

保哥用官方检测模型对这五组词各跑了一遍，标准写法的判定值全是0.000，非标准写法全是1.000，没有一组落在中间。

这个干净程度本身说明一件事：两套编码在统计特征上分得很开，机器判起来不难。难的是没人告诉你需要判。

## 今天还有多少缅甸站在用旧编码？

## 实验怎么做的

判定工具用的是Google开源的缅甸文编码检测库 (https://github.com/google/myanmar-tools)。它不是规则匹配，是一个在缅甸语、掸语、孟语、克伦语和巴利语的双编码语料上训练出来的统计模型，给一段文本返回一个0到1的判定值。

官方给的阈值建议是两个：要少漏判就用0.05，要少误判就用0.95。保哥两个都用了，超过0.95判非标准，低于0.05判标准，中间的单独归一档叫不确定。

站点清单是50个，涵盖新闻媒体、政府部门、银行、电信运营商、招聘、房产、二手车、超市、影音、维基百科。抓首页，剥掉脚本和样式，只把缅文密度足够的段落丢给模型。

## 结果

50个站里，能抓到并且缅文量足够判定的有16个。

这16个站的判定结果是：标准编码16个，非标准编码0个，不确定0个。

不是一边倒，是根本没有另一边。

剩下34个的情况分三类：抓取失败14个，主要是域名失效、证书问题和拒绝访问；首页压根没有缅文的18个，这一类几乎全是电商和企业站，它们的首页是英文；剩下2个缅文量太少不足以判定。

## 先别急着下结论，这个样本有偏

16个能判定的站里，媒体和政府占了大半。这两类恰恰是最早完成迁移的。

更长尾的那一层——个体商户的页面、社交平台上的内容、聊天记录、本地论坛——这次一个都没测到，因为它们要么不在开放网页上，要么抓不到。

所以这个结果只能支持一句话：今天在开放网页上还能被抓取到的缅甸语内容，基本全部是标准编码。

它不能支持另一句话：缅甸用户的设备上已经没有旧编码了。这两句话差得很远，第六节会用另一个实验去碰后面那句。

## 顺手捞到的一条：样式表里还留着字体族名

抓页面的时候保哥顺手把每个站样式表里出现的字体族名也扒了一遍，专门找那几个跟缅文有关的名字。

扒出来的结果不多，但方向很清楚：还在被显式指定的是标准编码时代的那几套开源缅文字体，那套非标准字体的名字在这16个站上一次都没出现。

这跟开头那个太阳能站的情况正好构成对照——大站早就把它清干净了，本地服务商的模板里还留着。

所以这一项值得单独列进体检清单：全站搜一遍字体族名，比判编码还快，一分钟能查完，而它能抓到的是编码判定抓不到的那一类问题——字节是对的，字体是错的。

## 另一个意外：一半的缅甸站首页没有缅文

18个站首页缅文字符数为零，这个数字比编码结果本身更值得看。

它们不是没做本地化，而是首页做的是英文，缅文内容在内页或者干脆在社交平台上。

这跟本站讲在非洲选语种别先看人口 (https://zhangwenbao.com/africa-market-language-selection-swahili-hausa-francophone.html)那一篇里的承载度判据能对上：一门语言能不能承载页面，看的不是有多少人说它，看的是有没有人拿它写价格和退货政策。缅甸语这一层的供给密度，比人口数暗示的要薄。

## 把时间轴倒回去，这条迁移曲线长什么样？

## 用同一个模型跑历史快照

今天的结果是一个点，一个点画不出曲线。

保哥的做法是从网页存档里取同一批站在2016年6月、2018年6月、2019年12月和2021年6月的原始快照，用同一个模型再判一遍。

取的是不加改写的原始存档，避免存档系统自己注入的内容干扰判定。

## 曲线

时间 | 非标准编码 | 标准编码 | 有效样本 | 非标准占比 | 

2016年6月 | 6 | 3 | 9 | 66.7% | 

2018年6月 | 5 | 5 | 10 | 50.0% | 

2019年12月 | 2 | 7 | 9 | 22.2% | 

2021年6月 | 0 | 7 | 7 | 0% | 

2026年8月 | 0 | 16 | 16 | 0% | 

2016年三分之二的站在用非标准编码，2018年打成平手，2019年底掉到五分之一出头，2021年归零。

## 断崖落在哪里

掉得最狠的一段是2018年6月到2019年12月，从50%掉到22.2%。

官方定的迁移日是2019年10月1日，正好卡在这一段里。

这个吻合度很高，但保哥不打算把它写成因果。理由有两条：样本只有九到十个站，一个站换边就是十个百分点；而且迁移这件事在官方定日期之前就已经在推进，2018年那一批标准编码站不是一夜之间冒出来的。

能说的是：这条曲线的形状跟一次有组织的迁移是吻合的，而不是自然演化的形状。自然演化不会在一年半里掉掉一半。

## 逐站看，换边发生在哪一年

站点类型 | 2016 | 2018 | 2019底 | 2021 | 

国际广播机构缅文频道 | 标准 | 标准 | 标准 | 标准 | 

缅甸语维基百科 | 标准 | 标准 | 标准 | 标准 | 

本地影音站 | 标准 | 标准 | 标准 | 标准 | 

独立媒体A | 非标准 | 标准 | 标准 | 标准 | 

独立媒体B | 非标准 | 非标准 | 标准 | 缅文过少 | 

广播机构B | 非标准 | 非标准 | 标准 | 标准 | 

房产平台 | 非标准 | 非标准 | 非标准 | 标准 | 

娱乐媒体 | 非标准 | 非标准 | 非标准 | 无快照 | 

日报 | 非标准 | 非标准 | 缅文过少 | 无快照 | 

这张表比那条汇总曲线更能说明问题。

换边的时间不是齐刷刷的，从2016年到2021年拉开了整整五年，最早的一批在官方定日期之前三年就换完了，最晚的一批拖到日期之后将近两年。

而且换边的顺序有规律：国际机构最早，本地媒体次之，商业平台最晚。房产平台那一行是最典型的——它一直拖到2021年才换，因为它的存量数据最多，转码代价最大。

最后两行更值得注意：那两个站没有换边的记录，它们直接从快照里消失了。这一条通向下一节。

## 有意思的是那几个从来没换过边的站

16个样本里有3个从2016年起就一直是标准编码，一次都没用过非标准那一套：一家国际广播机构的缅文频道、缅甸语维基百科，还有一个本地影音站。

前两个不难理解，它们的技术栈本来就是国际组织的技术栈，从一开始就没有装本地字体那个选项。

反过来说，那些用非标准编码的站，用的都是本地服务商搭的站。

这条观察对做站的人有一个直接含义：你的技术栈决定了你会被卷进哪一套事实标准。用国际通用的建站方案，这个坑天然绕开；用本地服务商的方案，得专门问一句。

## 那批旧页面去哪了？

## 这个实验的结果超出预期

前面两节说明了站点的当前状态和迁移过程，还剩最后一个问题：当年那些用非标准编码写的页面，被转码了吗？

保哥的做法是从网页存档的索引接口里，把六个站在2016到2019年间被抓取过的文章页URL拉出来，抽样，然后做两件事：取当年的原始快照判一遍编码，再拿同一个URL今天访问一次。

抽出来的样本里，当年判定为非标准编码的有21个URL。

今天再访问这21个URL，返回200的有0个。

## 21比0是什么概念

不是被转码了，也不是被重定向到了新地址，是访问不到。

失败的形态分三种：服务器返回404、域名解析不了、连接超时。三种形态加起来把21个URL全占了。

对照组是当年就判定为标准编码的11个URL，今天仍有3个返回200。

## 这个对照必须说清楚它有多弱

3比11也不是什么好成绩，说明这批老URL本来就有很高的自然死亡率。

而且这个实验没法证明因果。这些站在这七年里经历过改版、换域名、换内容管理系统，缅甸这七年还经历过别的事，任何一件都足以让一批URL消失。

把21比0写成编码迁移杀死了旧内容，是在数据上跑得太远。

能写的只有一句，而这一句已经够重了：当年那批用非标准编码写的页面，今天在网上指向的是空。至于是谁弄丢的，这个实验答不了。

## 为什么这句话对做站的人仍然重要

因为搜索引擎的索引不看原因，只看结果。

一门语言如果它2019年之前的网页资产大面积不可访问，那么这门语言在检索这一侧的历史积累就是薄的。竞争对手的老域名、老外链、老页面，能兑现的部分比你以为的少。

这在别的语言市场上很罕见。做德语、做西班牙语，你面对的是二十年的存量；做缅甸语，你面对的存量可能只有五六年。

本站讲按母语人口排小语种优先级会排反 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)那一篇里算过一个叫本地供给密度的变量，缅甸语这一格的答案不只是供给少，还多了一层：供给曾经有过，但那一批的字节已经不在流通体系里了。

## 这笔存量账怎么自己查一遍

这个实验不需要任何语言知识，一个下午能跑完，而且换成任何一门语言都能用。

第一步，从网页存档的索引接口拉取目标市场几个主要站在某个历史时间段被抓取过的地址清单，按去重和状态码筛一遍。

第二步，从清单里按固定间隔抽样，抽出看着像文章页的那些——路径层级深一点、不是图片和样式文件。

第三步，每个地址做两次访问：一次取当年的原始快照，一次直接访问今天的地址，两边都判一次。

第四步，把结果按当年状态和今天状态交叉成一张四格表，看哪一格最大。

保哥这次跑出来的形态是当年非标准编码那一列全部落进了取不到那一格。别的语言可能落进别的格子，但这张表本身能回答一个很实际的问题：你要进的这个市场，竞争对手手上那批老资产还能不能兑现。

这个问题在成熟语言市场上不用问，答案默认是能。在经历过基础设施断层的语言市场上，它值得花一个下午。

## 用户那一侧呢，搜索框里打进去的是哪一套字节？

## 站点全换完了，不等于用户全换完了

前面三节测的都是网页那一侧。用户那一侧测不到设备，但能测到一个很好的代理指标：搜索建议接口。

逻辑很简单。搜索建议的候选池来自真实查询日志。如果还有大量用户用非标准编码打字，那么用非标准编码去请求建议接口，应该能拉出东西来。

保哥拿五个词的两种写法各请求了一次，参数固定为缅甸语加缅甸地区。

## 结果

词 | 标准编码写法 | 非标准编码写法 | 

手机 | 10条 | 0条 | 

脸书 | 4条 | 0条 | 

价格 | 9条 | 0条 | 

衣服 | 9条 | 0条 | 

缅甸 | 0条 | 2条 | 

前四组的方向完全一致：非标准编码写法一条建议都拉不出来。

而且标准编码那一侧返回的建议词，逐条丢回模型判一遍，全部是标准编码，判定值都是0.000。

意思是候选池里没有非标准编码的查询，一条都没有。

## 第五组那个反例才是这一节的重点

缅甸这个词，情况反过来了：标准写法0条，非标准写法2条。

而那2条返回的建议里，第一个词是非标准编码的形态，后面跟着的词却是标准编码的形态，两套编码出现在同一条建议里。

这种混编串不可能是某个人一次打出来的，它更像是历史查询在候选池里留下的残迹。

如果不做第五组，前四组会给出一个非常干脆的结论：查询侧已经全部迁移完了。第五组把这个结论从干脆改成了基本，而基本和干脆之间那一点点差别，正好是你要不要给站内搜索加一层容错的判据。

## 四组零、一组反例，该怎么读

保哥的读法是这样的。

常规品类词的查询侧已经完成迁移，这一点从四组零可以支持。做词表的时候不需要为非标准编码单独准备一份，那是七年前的做法。

但索引里还留着历史痕迹，第五组证明了这一点。这意味着两件事：一是你的站内搜索日志里可能偶尔冒出看不懂的字符串，别当成攻击；二是站内搜索的输入端加一个编码归一化是划算的，成本几行代码，收益是那部分老用户不会得到零结果。

本站讲用户撞上错误页那一刻请求已经不在你的应用里了 (https://zhangwenbao.com/minor-language-error-page-fallback-language.html)那一篇里说过，零结果页是小语种站最容易被忽略的一块。缅甸语这里多了一个特有的成因：用户打的字没错，编码不对。

## 顺带一个提醒：这个实验会随时间失效

这类实测的保质期很短。搜索建议的候选池会持续更新，那两条残迹明年可能就没了。

所以本篇给的不是那两条建议本身，是这个测法：用你的目标语言的两种可疑写法各请求一次，比较返回条数。二十分钟能跑完，任何语言都能用。

## 这对进入这个市场的人意味着什么？

## 三条结论，按确定性排序

第一条最确定：今天新建的缅甸语站，用标准编码就对了，不需要做双编码。四节实验没有任何一处支持双编码的必要性。这一条可以直接执行。

第二条比较确定：这门语言在检索侧的历史存量很薄。开放网页上抓得到的老内容不多，抓得到的那部分里，2019年之前的又大面积失效。

第三条是推论，请自己判断：存量薄意味着起跑线比别的语言市场平。在德语市场你要跟二十年的老域名抢位置，在缅甸语市场那个二十年不存在。

## 第三条的反面

起跑线平不等于容易赚。

存量薄的另一面是需求也薄。第三节测到18个站首页没有缅文，说明连本地企业都还没把这门语言当成主要的内容语言。

本站讲你能不能在这门语言上做站内搜索取决于几个志愿者 (https://zhangwenbao.com/minor-language-open-source-dictionary-maintenance.html)那一篇里查过各语言的基础设施覆盖等级，缅甸语在那份清单里的位置并不靠前。分词、词干还原、拼写纠错这几层的工具支持，做的时候得自己兜底。

所以正确的读法是：这是一个进入成本中等、竞争强度低、天花板也低的市场。它适合作为已有东南亚布局的延伸，不适合作为第一门小语种。

## 什么情况下值得单独做

三种情况。

一是品类本身在这个市场有真实需求且供给稀薄，比如农机、太阳能设备、二手手机配件这类。

二是你已经做了泰语或者越南语，团队手上有东南亚的运营经验和物流方案。本站讲越南泰国印尼在语言层三家没有一处能共用 (https://zhangwenbao.com/southeast-asia-seo-vietnam-thailand-indonesia-language-layer.html)那一篇提醒过，预算能共用不代表语言层能共用，缅甸语加进来是第四份完整成本，没有折扣。

三是你在做的是信息型内容而不是交易型内容。缅甸语的问答型长尾几乎没人认真写，这一块的机会比商品页大。

## 什么情况下不值得

如果你的判断依据是人口数，那就不值得。5500万人口这个数字在排期表上很好看，可它跟能不能变成订单之间隔着支付、物流、网络成本三道墙。

本站重排小语种优先级 (https://zhangwenbao.com/minor-language-seo-2026-portfolio-review-invest-freeze.html)那一篇里的做法在这里可以直接套：把人口那一列先盖住，只看本地供给密度、工具支持和分叉复杂度三列，缅甸语这三列的分数都不高。

## 缅甸语还有哪几层跟编码无关但同样会咬人的问题？

## 第一层：没有空格

缅甸语的句子里不用空格分词，跟泰语一样，切在哪由引擎的词典说了算。

本站讲泰语的标题里找不到一个空格 (https://zhangwenbao.com/thai-seo-no-spaces-word-segmentation-keyword.html)那一篇里那套判据在缅甸语上大部分成立，包括标题该怎么写才切得开、品牌名在正文里会被切成什么。

差别在于工具支持。泰语的分词器有好几套可选，缅甸语这一层的选择要少得多，所以能靠模板绕开分词的地方尽量绕开。

## 第二层：字节重，视觉字符少

缅甸语在几种常见文字里是字节最重的一门。同一句厨房用品，英语18个字节，缅甸语69个字节，是英语的3.8倍。

可它的视觉字符只有12个，比英语的18个还少三分之一。

这个组合最坑人：屏幕上看着还有很多空位，字段额度已经满了。凡是按字节限长的字段——平台的搜索词字段、数据源的标题字段、短信模板——都要单独算一遍。

## 第三层：字符堆叠，行高不够就糊

缅文的字符要上下堆叠，一个音节可以摞三层。默认行高在这门文字上普遍不够用，字会互相蹭。

本站讲设计稿上量出来字号一模一样 (https://zhangwenbao.com/minor-language-font-size-line-height-script.html)那一篇里按书写系统分档的做法，缅文属于要单独提一档的那一类。

## 第四层：字体

缅文的字形集不小，加上堆叠规则复杂，字体文件比拉丁字体重不少。本站算过非拉丁文字的字形集有多大 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)，缅文这一格要按复杂文字的口径算，子集化不能照搬拉丁的做法。

还有一个只在这门语言上出现的注意事项：不要在页面里指定那个非标准字体的名字。有些老模板里还留着，用户机器上万一装了那套字体，标准编码的文本会被它渲染成一堆错位的字形。

## 第五层：数字有两套写法

缅甸语有自己的一套数字字形，跟阿拉伯数字并存。页面上写价格、写规格、写日期，两套都能用。

这件事的处理原则跟波斯语那边一样：展示可以用本地数字，数据字段和结构化标记必须写回阿拉伯数字。

关键词那一侧要单独判一次。用户在搜索框里打数字的时候，多数手机输入法送出来的是阿拉伯数字，因为切换成本高。所以带型号、带尺寸、带年份的长尾查询，主形态大概率是阿拉伯数字那一套。

但也别把本地数字那一套全删掉。价格和数量这类给人看的位置留着本地写法，页面会显得像本地人做的，而这一层的信任成本很低。

## 第六层：审校和工具资源都要自己兜底

缅甸语的母语审校不好找，能同时懂SEO的更少。这不是抱怨，是排期时要算进去的一项。

本站讲母语审校说读着自然不能当验收通过 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)那一篇里那套按层拆的验收表，在缅甸语上要往前挪一步：先验字节，再验渲染，最后才验语言。前两层不需要懂缅甸语，团队自己就能做，做完再把语言那一层交出去，审校的时间就不会浪费在描述字看着别扭上。

工具那一侧同理。分词、拼写纠错、词干还原这三样，缅甸语能拿到的现成实现都不多，能靠模板绕开的地方尽量绕开，绕不开的部分预算里单列一笔。

## 一套两天能跑完的缅甸语编码体检

## 第一天上午：判自己站上的字节

第一项，把站上所有缅甸语文本导出来，逐段过一遍检测模型。判定值超过0.95的段落挑出来，那就是漏网的旧编码。

第二项，重点查三类位置：从供应商拿来的商品描述、用户提交的评价、以及从旧系统迁移过来的历史文章。这三类是最容易混进旧编码的地方，因为它们不是你自己敲的。

第三项，查数据库里的历史记录。页面上看不见不代表库里没有，站内搜索会把它们捞出来给用户看。

## 第一天下午：判进来的字节

第四项，站内搜索的输入端加一道归一化。用户提交查询词的时候先判一次编码，判定值高的转成标准编码再查。

第五项，表单提交的内容同样处理，特别是评价和问答这类会进页面的内容。放一段旧编码进正文，相当于在页面里埋了一段搜索引擎读不懂的字。

第六项，看一遍站内搜索日志里的零结果查询。挑出缅文字符占多数但一条结果都没有的，逐条判编码。这一步经常能捞出真实用户。

## 第二天上午：字符层的常规项

第七项，按字节算一遍所有有长度限制的字段，用3.8这个倍数对着英语版估，超的标出来。

第八项，检查截断函数。缅文的堆叠字符比孟加拉文更复杂，按码位截几乎必然切坏，必须用标准的文本分段算法。这一层的账本站在孟加拉语那一篇 (https://zhangwenbao.com/bengali-seo-two-markets-vocabulary-grapheme.html)里逐词量过，缅甸语的倍数只会更大。

第九项，全站搜一遍字体族名，把那个非标准字体的名字从样式表里清掉。

## 第二天下午：语言层

第十项，页面语言标签写对。缅文只有一套书写系统，地区也只有一个，所以标签本身很简单，简单到经常被漏掉。短页面尤其要补足语言证据，本站讲字最少的那几类页面最容易被机器认成另一门语言 (https://zhangwenbao.com/minor-language-page-language-detection-misidentification-short-text.html)那一篇里给过一张按页面类型排的自检表。

第十一项，标题和品类名过一遍分词，确认能切开。

第十二项，找一位母语者把首页和三个主要品类页读一遍，只问一个问题：有没有哪个字看着别扭。别扭往往是渲染问题的第一信号，而渲染问题往往是编码问题的影子。

## 开头那家太阳能站后来改了四处

第一处最简单，把样式表里那个字体族名删掉，换成两套开源缅文字体加一个通用兜底。改完那位缅甸同事再打开，字就正常了。这一处花了十分钟，而它卡了团队四个月。

第二处是把导进来的那批历史内容全量判了一遍编码。判定值超过阈值的自动转，中间那一档人工过——中间档一共十几条，全是标题，跟前面说的规律一致。

第三处是给站内搜索的输入端加了归一化。加完之后，零结果查询里那一批看不懂的字符串就有了去处。

第四处是把检测模型接进了发布流程。这一处是团队自己加的，理由很实在：供应商还会继续发商品资料过来，而供应商用的是什么编码，谁也管不了。

四处改动里，真正解决问题的是第一处，真正防止复发的是第四处，中间那两处是打扫战场。保哥觉得这个比例挺有代表性——编码这类问题，找到它花的时间远多于修它，而修完之后不装那道闸，半年后又会长回来。

## 三种看着稳妥、实际会留后患的做法

## 第一种：为了保险，两套编码都发一份

2019年前后这是标准建议，今天不是了。

四节实验里没有一处支持它。站点侧16比0，查询侧四组零，双编码要付的是双份内容成本加一份重复内容风险，换来的是候选池里那两条残迹。

如果确实担心那部分老用户，正确的位置是站内搜索的输入端做归一化，而不是页面上多发一份。前者几行代码，后者是一整套内容。

## 第二种：找一个在线转换工具，把老内容批量转一遍

可以做，但要先接受一件事：转换不可能百分之百准。

Unicode官方那份常见问题里给了原因——有些字符串在两套编码下都是合法的，所以判定本身就没法做到完全准确。判定不准，转换自然也不准。

可行的做法是分档：判定值超过0.95的自动转，低于0.05的不动，中间那一档人工过。中间那一档通常很小，但里面往往是短文本，而短文本经常是标题。

这跟本站讲机器复制走的是另一串字符 (https://zhangwenbao.com/minor-language-pdf-text-layer-extraction-failure.html)那一篇里的处理原则是一致的：自动化处理量，人工处理边界。

## 第三种：把这件事当成一次性任务做完就归档

这是最容易犯的一个。

编码这一层不是做完就结束的，它有持续的入口：供应商的商品资料、用户提交的内容、外包团队交付的稿子、从旧库里补录的历史文章。

只要还有人从外面往站里放缅甸语文本，就得有一道回归检查。把检测模型接进内容发布流程，判定值超阈值就拦下来，这道闸一次配好，之后不用管。

## 还有一个提醒：别把这套结论搬到别的语言上

缅甸语这一件的特殊之处在于它已经迁移完了。同样是编码遗留，别的语言可能停在不同的阶段。

本站写过的罗马尼亚语那两个字母的两套码位 (https://zhangwenbao.com/romanian-seo-postposed-definite-article-comma-diacritics.html)就是另一种形态——两套码位都是Unicode标准里的合法码位，一套是历史遗留一套是正确写法，至今并存，而且不会有哪一天彻底结束。

要搬的是测法：找到这门语言可能存在的两种字节形态，各请求一次搜索建议，再抓一批站判一遍，最后倒回历史快照画一条曲线。三步下来，这门语言在编码这一层处在哪个阶段就清楚了。

## 常见问题解答

## 现在做缅甸语站，还需要考虑旧编码吗？

页面输出不需要，用标准编码就对了。实测16个能判定的缅甸语站全部是标准编码，搜索建议的候选池里也拉不出旧编码的查询。需要考虑的只有两个入口：一是从外部拿进来的文本，供应商资料、用户评价、历史迁移数据，这三类可能混进旧编码；二是站内搜索的输入端，加一道归一化能接住那部分还没换设备的用户。

## 两套编码肉眼真的看不出来吗？

有些看得出，有些看不出。差异分三类：只差一个码位的那一类，两个符号形状极接近，不懂缅文的人完全看不出；码位数不同还借用了掸语码位的那一类，仔细看能发现字形不对；存储顺序相反的那一类，如果字体不匹配，屏幕上会明显错位。所以肉眼检查只能抓住最严重的那一档，剩下的必须靠程序判。

## 为什么说这不是普通的乱码？

因为乱码的特征是页面报错或者显示成方块，编码声明和实际字节对不上。缅甸语这一件里，字符集声明是对的，字节是合法的UTF-8，浏览器不给任何提示，屏幕上显示的也是缅文。两套方案占用同一个码位区间，只是分配方式不同。工具层面查不出来，只能靠统计模型判。

## 那条从三分之二掉到零的曲线，能证明是官方迁移日起的作用吗？

不能，只能说形状吻合。掉得最狠的一段是2018年年中到2019年年底，官方定的日期落在这一段里。但样本只有九到十个站，一个站换边就是十个百分点，而且迁移在定日期之前就已经在推进。能确定的是这条曲线的形状不像自然演化，自然演化不会在一年半里掉掉一半。

## 2019年之前那批缅甸语老页面今天真的全没了吗？

抽样到的那21个URL今天确实一个都打不开，但这个结论有边界。第一，样本只有21个，来自六个站；第二，对照组里当年就是标准编码的11个URL今天也只剩3个能开，说明老URL本来就有很高的自然死亡率；第三，改版、换域名、换系统都能造成同样的结果，这个实验分不出原因。能说的只有一句：这批URL今天指向的是空。

## 缅甸语值不值得做，判断依据是什么？

把人口那一列先盖住。真正要看的是三列：本地供给密度、工具支持程度、内容能不能复用现有的东南亚资产。缅甸语前两列的分数都不高，第三列取决于你有没有泰语或越南语的底子。适合作为已有东南亚布局的延伸，不适合作为第一门小语种。如果品类本身在这个市场供给稀薄，或者你做的是信息型内容而不是交易型内容，值得的概率会高不少。

## 怎么判断另一门语言有没有同样的编码分叉？

三步。第一步查这门语言有没有过广泛使用的非标准字体编码，Unicode官方的语言常见问题页通常会写。第二步用这门语言的两种可疑写法各请求一次搜索建议接口，看返回条数差多少。第三步抓二十个这门语言的站判一遍编码，再从网页存档里取几个历史时间点画一条曲线。三步跑完大概两小时，就能知道这门语言在编码这一层处在哪个阶段。

## 权威参考资料



## 这门语言里这个东西该叫什么，法律早替你定好了，只是那个词一次都没进过你的词表

- URL：https://zhangwenbao.com/minor-language-legal-product-name-keyword.html
- 分类：小语种SEO
- 发布：2026-07-31  |  更新：2026-07-31
- 摘要：法定名称按语言各有官方版本，写在法条附录里而不在关键词工具里。讲清它跟通名化商标为什么是一对镜像、成分名为什么反过来全球不翻、这批词该放页面哪一格。
- 关键词：关键词研究,跨境电商,多语言SEO,小语种SEO

> **TLDR**：摘要：关键词表里所有的词都要靠你自己去找、去译、去验，只有一批例外：法律已经替你把它在每门语言里叫什么定好了，还盖了章。它印在用户手上那只盒子的正面，是他拿着实物回头搜的时候会打的那串字。可这份现成的官方译本躺在法条附录和标准文本里，不在任何一个关键词工具里，于是它一次都没进过你的词表。

> 摘要：关键词表里所有的词都要靠你自己去找、去译、去验，只有一批例外：法律已经替你把它在每门语言里叫什么定好了，还盖了章。它印在用户手上那只盒子的正面，是他拿着实物回头搜的时候会打的那串字。可这份现成的官方译本躺在法条附录和标准文本里，不在任何一个关键词工具里，于是它一次都没进过你的词表。

## 母婴洗护站的德语页从没出现过那个词，可法条里这个品类就叫那个名字

## 一家母婴洗护站的三个市场，有一类词的流量长期为零

有个客户做母婴洗护，婴儿沐浴露、护臀膏、婴幼儿洗衣液、湿巾这几条线。

德国、法国、波兰三个市场，页面都是找母语译者做的，词表也按语言各建了一份。

整体数据不差，只有一件事一直没人说得清：售后那边的咨询量明显高于同规模的其它客户，而且问的多半是产品本身的基础信息。

翻了一批客服记录之后，团队发现了一个很怪的现象：用户在工单里描述自己买的东西时，用的词跟页面上那个词对不上。

不是拼错，也不是俗称，是一个他们从来没在自己站上用过、但读起来相当正式的词。

把那个词丢进搜索框，前面几条全是竞品和药房连锁，一条自己的页面都没有。而这个词的月搜索量并不小，商业意图还特别明确，因为搜它的人多半已经买过或者正在比对手上这一件。

## 那个词印在盒子上，而写页面的人没见过盒子

保哥让他们从仓库拿一盒实物过来，把包装正面那行字抄下来。

抄出来的正是客服记录里那个词。

再往下翻，产品说明和成分表里也反复出现它，位置都很显眼。

页面上写的是另一套说法：一个更好听、更像品牌语言的组合，读起来温柔，也确实是市场部认真打磨过的。

两套说法在同一件商品上并存了三年，谁都没觉得有问题，因为它们各自服务的场景不一样。

问题在于用户不知道这个分工。他手上拿着盒子，眼睛看到的是盒子上那个词，他回头去搜的时候打的就是那个词，而你的页面上一次都没有出现过它。这不是翻译错了，也不是选词品味不好，是页面根本没参与这一场。

## 再往上追一层，那个词不是随便印的

团队一开始的猜测是包装设计沿用了供应商的老模板。

去问了法务，答案完全不是这回事：那个词是法规要求必须标注的品类名称，写什么、写在哪、字号多大都有规定。

换句话说，它不是市场部选的，也不是设计选的，是法条替这件商品定的名字。

更关键的是，这个名字在德语、法语、波兰语里各有一版，三版都不是译者翻的，是法规文本本身就有的官方版本。

三个市场的包装上，印的分别是这三版。

于是这家公司同时拥有两样东西：一份市场部打磨了很久的营销词表，和一份法务手里现成的、经过官方确认的多语言名称表。两份表从来没在同一张桌子上出现过，因为后面那份不叫关键词表，它叫合规资料。

还有一层更硬的：包装上那几行字的字号和位置也是规定死的，规定得越死，说明立法者认为它越重要。换句话说，法规已经替你把这件商品身上所有文字的重要性排过一次序了，而排在最前面的那个词，恰好是你的页面上唯一没有的那个。

## 一句话判据：把盒子正面那行字抄下来，去页面上搜一遍

这件事的自查动作简单到有点好笑。

从仓库或者样品柜里拿一件实物，把包装正面的品类名称原样抄下来。

打开这件商品的商品页，用浏览器的页内查找搜这个词。

搜不到，说明这一件商品在这门语言里的法定叫法从来没进过你的页面。

抽十件商品做一遍，你就知道这是个别现象还是全线现象。

这个动作的价值在于它不需要懂那门语言。你不需要知道那个词是什么意思，只需要判断它在不在页面上。判断在不在，是一件任何人都能做的事，而这恰恰是小语种项目里最稀缺的那类动作。

## 法定名称到底是什么，它跟你写的那个名字差在哪？

## 商品的名字在法律眼里分三层

先把概念摆清楚。欧盟食品这一块的规则写得最系统，可以拿来当模型。

规则规定，商品的名称要按顺序取：有法定名称的用法定名称，没有的用习惯名称，两者都没有的才允许用描述性名称。

法定名称是法条、标准或者行政规定直接指派的那个名字。

习惯名称是这个国家的消费者不需要额外解释就能明白的那个说法。

描述性名称是用一句话把它是什么说清楚，比如说明用途、成分或者形态。

这三层的关系是取代关系而不是并列关系：只要上一层存在，你就不能跳过它去用下一层。这条顺序是本篇后面所有结论的地基，因为它意味着法定名称不是可选项，而是有它就必须用它。

## 营销名称在这套体系里什么都不是

你在页面上用的那个名字，在这三层里通常一层都不占。

它可能是品牌线的名字、可能是一句卖点、可能是设计感很强的一个组合词。

规则对这类名称的态度很明确：品牌名称、商标、幻想名称都不能取代上面三层里的名称。

它们可以出现，但只能出现在名称之外，不能替代名称。

这条规定的用意是防止消费者被名字误导，跟营销好不好听没有关系。

把这条规定翻译成做站的语言就是：包装上必须有那个词，而页面上是不是有它，法律不管，用户管。法律只保证那个词会出现在实物上，而实物是用户手里唯一一份不会被你的内容策略改写的资料。

## 它跟通名化商标正好是一对镜像

本桶写过一类词：搜索量很大、意思你也懂，可它印在别人的商标证上，页面上不能碰。

那一类的特征是有量不能用，处理办法是留在表里标清状态、只在匹配层收纳。

这一篇讲的这一类正好反过来：法律不但允许你用，还要求这件商品必须被这么叫。

一个是禁止，一个是强制，两类词的共同点是它们的取值都不由你决定，都由法律那一侧给出。

而它们在词表里的处境也一模一样：都不在营销侧的选词流程里，都需要有人专门去法条那一侧拿。

两篇合起来看会得到一条更完整的判据：凡是取值由法律给出的词，它就一定不在关键词工具的建议列表里，因为工具的输入是搜索数据，而法律那一侧的输入是立法。那个词印在别人的商标证上那一篇 (https://zhangwenbao.com/minor-language-genericized-trademark-category-keyword.html)处理的是禁用这一半，本篇处理的是强制这一半。

两类词还有一个共同的实操后果：它们都不能交给写手凭语感处理。语感能判断一个词自不自然，判断不了它是被禁止还是被强制，而这两件事的代价都不在自然度这一侧。

## 为什么这件事在小语种上才成为一个问题

做英语市场的人很少遇到这个坑，原因不复杂。

写页面的人跟看包装的人说同一门语言，包装上那个词他天天见，写着写着自然就写进去了。

小语种项目的结构不一样：写页面的稿子从中文或者英文出发，经过译者，落到页面上。

包装那一侧则从法务和供应链出发，经过合规审核，落到印刷厂。

两条链路从头到尾没有交点，中间也没有任何一道工序会去对一下这两处用的是不是同一个词。

所以这不是谁疏忽了，是两条流程本来就没有握手的地方。这跟界面文案那件事的成因是同一类，都是一段字住在另一个系统里，只不过界面文案住在代码里 (https://zhangwenbao.com/minor-language-hardcoded-ui-strings-pseudo-localization.html)，这一批词住在法务的文件夹里。

## 为什么说这是词表里唯一一批已经有官方译本的词？

## 法条本身在每个成员国语言里都有一版

这一节是本篇最值钱的那条推论，值得慢慢说。

欧盟的法规文本按规定要以所有官方语言发布，各语言版本具有同等效力。

这意味着法条里出现的每一个品类名称，都自动拥有二十几个语言版本。

这些版本不是机器翻的，也不是某个译者的一家之言，它们是立法程序的产物。

换句话说，你要的那个词在每门语言里叫什么，已经有人替你决定了，还盖了章。

做小语种内容的人一辈子都在为一件事发愁：这个词在那门语言里到底该怎么说，谁说了算。绝大多数时候这个问题没有权威答案，只能靠数据和母语者投票。而这一批词是唯一一个例外，它的答案是白纸黑字写在法条里的，还免费。

## 纺织品那张纤维名称表是逐语言给的封闭清单

纺织品这一块的规则把这件事做到了极致，是最好的例子。

纤维名称在这套规则里是一张封闭清单：只有清单上有的名称才能用，不在清单上的纤维不能自己起名字。

清单的附录里，每一种纤维的名称按成员国语言各给一版。

规则还额外禁止一件事：不能用商标或者品牌名称去代替纤维名称，哪怕那个商标已经家喻户晓。

这一条跟通名化商标那一篇正好在同一个点上打了个照面：一个说别把商标当品类词用，一个说品类词必须用官方给的那个。

对做站的人来说，这张附录表是一份可以直接抄进关键词表的多语言对照表。它的覆盖面不算宽，只管纤维成分这一块，但它的质量高得离谱：官方、逐语言、封闭、免费、且长期稳定。

## 成分名反过来全球统一，一个字都不翻

更有意思的是化妆品这一块，它给出了完全相反的处理。

化妆品的成分表必须用国际化妆品原料命名，那是一套全球统一的命名体系，各国一律照抄，不翻译。

所以一支在德国卖的婴儿沐浴露，包装背面的成分表在法国、波兰、意大利看到的是同一串词。

而同一张标签上的功能说明、使用方法、警示语，则必须用销售国规定的语言。

两套逻辑并存在同一张标签上：一半强制统一，一半强制本地化。

这个对照很能说明立法者在想什么。需要跨境比对、需要专业人士判读的信息，统一命名最有效率；需要普通消费者当场读懂的信息，必须用他的语言。判据不是内容重不重要，是读它的人是谁。这条判据比大多数本地化方法论都干净。

## 于是同一件商品上并存三套名字

把前面几节合起来，一件商品身上其实挂着三套名字。

第一套是法定名称，按语言各有官方版本，印在包装正面。

第二套是国际统一命名，全球一份，印在成分表里。

第三套是你的营销名称，你自己定，写在页面上和广告里。

三套名字的语言策略完全不同，而绝大多数站只维护了第三套。

第一套在法务手里，第二套在配方文件里，两套都不在内容团队的视野里。

这件事有点像一个人有三张身份证：一张是户口本上的大名，一张是国际通行的编号，还有一张是朋友们叫惯的小名。你的页面从头到尾只用小名，然后奇怪为什么按大名找过来的人一个都没接住。

三套名字里最容易被忽略的其实是第二套。成分这一套因为全球统一，团队往往默认它不需要管，于是它连一次核对都没经历过；而它恰恰是页面上最容易被专业用户拿来验真伪的一批字。

## 同一张标签上并存两套命名逻辑，对做站的人意味着什么？

## 该翻的和不该翻的，判据不是重要程度

本地化项目里最常见的争论之一，是哪些词该保留原文。

常见的判据是重要程度、专业程度、或者品牌规范，这几条都不太靠得住。

标签这套规则给出的判据要干净得多：读它的人是谁。

给专业人士和跨境系统看的，统一命名；给当场做决定的消费者看的，必须本地语言。

把这条判据搬到页面上，很多长期争不出结果的问题会立刻有答案。

成分名、认证编号、材质代号、型号前缀这几类走统一路线；品类名、功能说明、注意事项、退换条款这几类走本地路线。这跟结构化数据那一层的分类办法是同构的，正文越本地化越好，标记里却要写回国际格式 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)讲的就是同一件事在另一个位置上的表现。

## 成分名不翻，但它照样是关键词

这里要防一个误会：不翻不等于不重要，更不等于不该出现在页面上。

成分名在美妆个护、母婴、宠物食品这几个品类里是很硬的搜索需求。

用户会拿着某个成分名去搜，也会拿两个成分名做对比。

因为它全球统一，所以这批词的处理成本极低：一份表，所有语言通用。

这大概是小语种项目里唯一一批做一次全语言受益的关键词。

要注意的是它在用户口语里往往另有俗称，而俗称是按语言各不相同的。所以正确的做法是页面上两个都出现：成分表里用统一命名保证合规与专业信任，正文里让俗称自然出现一次接住口语查询。这跟专业词与日常词那一对的处理办法是同一套，写页面的人和搜东西的人绕开的方向正好相反 (https://zhangwenbao.com/minor-language-euphemism-restricted-category-keyword.html)那一篇讲的档位问题在这里同样成立。

## 包装是唯一一份用户手上不会被你改写的资料

这一节讲一条容易被低估的事实。

页面可以改，广告可以撤，邮件可以重发，客服话术可以更新。

包装印出来就固定了，它跟着商品进了用户家里，一放就是几个月。

用户回头找信息的时候，手上唯一的凭据就是它。

而它上面印的那个品类名称，是法律规定必须准确的那一个。

所以从检索的角度看，包装其实是你投放量最大、留存时间最长、且内容由法律背书的一块本地语言资产，而多数团队从来没把它当资产看过。这盒东西在用户的浴室柜里躺着的时候，还在默默替你做着关键词投放，只是投的那个词落到了竞品的页面上。

有一类品类要格外小心：同一个配方在不同国家可能被归进不同的法规体系，比如在一国按化妆品管、在另一国因为宣称了某种功效而按药品或者医疗器械管。归属一变，必须标注的名称、允许说的话、甚至能不能在电商渠道卖都跟着变。这类商品的名称对照表不能按产品建，只能按产品加市场的组合建。

## 说明书与随附文件是同一批词的第二个出口

除了包装正面，还有两个地方会出现这批词。

一个是随货的说明书或者使用指引，另一个是能效标签、安全信息卡这类附加标注。

它们的用词跟包装是同一套，因为它们受同一批规则约束。

这两处的好处是通常有电子版，拿起来比翻实物方便。

坏处是电子版多半是文件形式，而文件里的文字未必取得出来。

非拉丁文字的文件尤其危险，屏幕上看着好好的，机器复制走的可能是另一串字符，这件事那页规格书在屏幕上是好好的泰语那一篇 (https://zhangwenbao.com/minor-language-pdf-text-layer-extraction-failure.html)拆得很细。所以从文件里抄这批词的时候，抄完要用肉眼跟屏幕上的对一遍，别直接信复制粘贴的结果。

## 这批词在搜索里到底值多少？

## 手上有实物的人，打的是实物上那个词

先说这批词的用户是谁。

搜法定名称的人，绝大多数手上已经有这件东西，或者正站在货架前拿着它。

他要么想知道怎么用，要么想知道能不能退，要么想再买一件。

三种意图的商业价值都不低，尤其第三种，那是复购。

而这三种场景的共同点是他不会去回忆你的营销名称，他念的是眼前这行字。

这条推论有个很实际的检验办法：去看你的站内搜索日志，按语言分组，看看有没有一批查询词是页面上从来不出现的。这批词里有相当一部分就是法定名称，它们是用户带着实物找上门来的证据。

还有一个容易被漏掉的人群：替别人买东西的人。给父母买、给孩子买、按医嘱或者按别人给的清单买，这类用户手上拿的是一张写着品类名称的纸条或者一张照片，他打进搜索框的只能是那个正式说法，因为他对这个品类本来就不熟。

## 售后、比价、复购三个场景全落在它上面

把场景摊开会更清楚。

售后场景里，用户在工单和搜索框里描述自己买的是什么，用的是包装上那个词。

比价场景里，用户拿着一件东西去搜同类，法定名称是唯一能保证搜到同类的说法，因为各家的营销名称各不相同。

复购场景里，用户要找的是同一样东西而不是同一个品牌的其它东西，法定名称的指向精度比品牌名高。

三个场景加起来，覆盖的是购买之后的整个生命周期。

而多数站的内容布局是重购买前、轻购买后。购买前的词大家抢得头破血流，购买后的词一个人都没有。这批词恰好全落在没人抢的那一半，这才是它真正值钱的地方。

## 它的竞争密度天生低

为什么没人抢，原因跟本篇前面讲的是同一个。

竞争对手的词表也是从营销侧和工具侧来的，他们的表里同样没有这批词。

做这个品类的国际品牌用的是自己的营销名称，本地品牌用的是本地的营销名称。

真正把法定名称写进页面的，往往只有药房连锁、专业渠道和一部分本地媒体。

这几类站的商品页做得普遍不精细，正面竞争难度不大。

竞争密度低这一点在小语种市场会被放大，因为这些市场本来就没有几家在认真做内容。用一个不用抢的词去接一批意图明确的查询，这种机会在成熟品类里已经不多了。

要防一个误判：竞争密度低不等于随便写写就能排上去。这批查询的用户带着实物，对内容的具体程度要求反而更高，一句泛泛的品类介绍接不住他。真正能拿下这批词的是把规格、用法、适用人群、常见误用写清楚的那种页面。

## 怎么估这批词的量

估量这件事在小语种上一向麻烦，这批词更麻烦一层。

工具对它的收录通常很差，因为它既不是热门词也不是明显的商业词。

可用的估法有三条。

第一条是站内搜索日志，把页面上不存在的查询词捞出来，按频次排。

第二条是引擎的搜索建议，把法定名称的前几个字打进去看它补出什么，补出来的组合就是真实存在的问法。

第三条是看服务这一批查询的那几个页面收录了多少、内容有多厚，间接判断需求的规模。工具返回零不代表没人搜，这条老结论在这批词上表现得格外明显，因为它们从设计上就不是营销词。

## 为什么你的关键词表天生收不到它？

## 词表的两个来源里都没有法条

关键词表的原料通常来自两处：一处是营销侧的说法，一处是工具给的建议。

营销侧的说法出自品牌规范和文案，那里面不会有法定名称，因为法定名称通常不好听。

工具给的建议出自搜索数据，而搜索数据的采集有门槛，长尾和低频词大量被记成零。

两处原料都不包含法条文本，所以不管词表建得多认真，这批词都进不来。

这不是流程执行不到位，是原料清单里少了一样东西。

补的办法也很直接：给词表加第三个来源，来源名叫合规资料。这跟本桶那条老结论是一回事，翻译资产的价值在一致性不在覆盖率，指望从译文里挖出用户的真实说法，方向从一开始就是反的；这里的区别在于，法条这个来源不但能补覆盖率，它给的还是官方译本。

这条补充还有个副产品：把合规资料立成第三个来源之后，它带来的不只是品类名称，还有剂型、规格单位、适用人群这几类的官方说法。这些词在页面上通常靠写手自己发挥，各页各写一套，而它们本来是有标准答案的。

## 翻译流程翻的是你的稿子，不是法条

第二道关卡在翻译这一侧。

译者拿到的是你的中文或者英文稿，他的任务是把这份稿子翻好。

稿子里没有的词，他没有义务补，也没有依据补。

哪怕他本人知道这个品类在本国的法定叫法，他也不会擅自加一个原文里没有的词进去。

这是职业规范，不是失职。

所以这批词漏掉的位置非常靠前：在源稿阶段就已经漏了。母语审校同样救不回来，因为审校验的是译文对不对、自不自然，验不到原文里本来就没有的东西。一句读着自然不能当成验收通过的判据 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)那一篇拆过审校到底能验哪几层，这一批词恰好落在它验不到的那一层外面。

## 合规团队手里有这份表，但它不叫关键词表

第三道关卡是组织结构。

法定名称这份资料在多数公司里是有的，它躺在合规、法务或者产品注册那边。

它以标签审核记录、注册文件、包装校对稿的形式存在。

没有人管它叫关键词表，所以它永远不会被送到做内容的人手上。

而做内容的人也不知道该去要，因为在他的认知里，法务那边只有条款和风险提示。

这道墙是本篇里最容易推倒的一堵：一封邮件，问一句每个市场包装上标的品类名称各是什么，附一张表格模板。多数情况下对方一天之内就能填完，因为这份资料本来就是现成的。这是整件事投入产出比最高的一个动作，没有之一。

## 三道关卡加起来，损失是缺席型的

三道关卡的共同后果是这批词从头到尾没进过任何一份可交付物。

而它造成的损失不是下跌型的，是缺席型的。

没有任何一条曲线掉下来过，只是有一大片查询从来没进过你的门。

监控系统天生盯的是变化，对一直不存在的东西完全无感。

所以这类问题的平均存活时间以年计，不是因为难修，是因为没人怀疑过词表。

要把它变成可见的，唯一的办法是主动去找。前面那个抄包装的动作之所以值钱，就是因为它把一件看不见的事变成了一个能在十分钟内得出是或否的检查。

## 不同法域给的答案会差到什么程度？

## 欧盟食品：三层名称的取用顺序

先看规则写得最细的食品这一块。

规则要求按法定名称、习惯名称、描述性名称的顺序取用，有前者就不能用后者。

同时明确规定商标、品牌名和幻想名称不能取代这三层里的名称。

还有一条经常被忽略：如果商品在销售国的名称会让消费者误解它是什么，就必须补充说明。

这条补充说明的要求，本身就是一批很自然的长尾内容。

对做站的人来说，食品这一块的价值在于它把名称这件事的逻辑写得最完整，其它品类的规则大多是这套逻辑的变体。理解了它，看别的品类的规则会快很多。

## 欧盟纺织品：封闭清单加逐语言附录

纺织品这一块前面提过，这里补两条实操细节。

一是清单封闭意味着你的商品描述里出现的纤维名称，必须能在附录里找到对应项。

二是附录按语言各给一版，这份对照表可以直接用。

德国还有一部专门的纺织品标识法与之配套，把执行层面的要求写得更具体。

对服装、家纺、户外这几类站来说，这张表几乎是免费的多语言属性词库。

顺带一提，成分百分比的写法也有规定，而百分比在页面上通常落在属性表里。属性值这一层的语言处理是另一套麻烦，你的色卡上蓝和绿是两格那一篇 (https://zhangwenbao.com/minor-language-color-category-attribute-value.html)讲过枚举值为什么不能靠模糊匹配救，纤维名称的好处恰恰在于它是一份现成的、官方的、封闭的枚举表。

封闭清单还有一个反向用途：它能直接用来做投放的否定词和站内搜索的纠错映射。清单之外那些用户常打的民间叫法，一律映射到清单上的官方名称，既保证展示层合规，又不丢掉口语查询。

## 欧盟化妆品：成分统一，说明本地

化妆品这一块给出的是前面讲过的那种双轨。

成分表用国际统一命名，全欧一份，不翻译。

功能说明、使用注意、保质期标注这些必须用销售国要求的语言。

产品的功能本身也要在标签上表述清楚，除非从外观就能一眼看出。

这条要求实际上强制了一个描述性的品类说法出现在包装上。

母婴洗护这类商品往往同时受化妆品规则和其它规则约束，包装上的名称因此更正式、更接近法条用语，跟营销名称的距离也就更远。开头那个案例之所以出在这个品类，不是巧合。

## 美国：身份标准与通用名称

换到美国这一侧，逻辑相似但形态不同。

那边有一套身份标准，对一批具体商品规定了它必须满足什么条件才能叫这个名字。

另有一套规则专门讲通用名称该怎么定，包括名称里要不要带上关键成分的含量。

这套体系的特点是按品类逐条立规，覆盖面不如欧盟那套整齐，但落到具体品类上非常细。

对只做英语市场的站来说，这套规则的语言层意义不大，因为英语只有一版。

但它有一个别处没有的用处：它把同一个品类的合规叫法写死了，于是这批词在美国市场是高度收敛的，不像欧洲那样一国一版。做多市场对照时，可以拿它当那一列的标准答案。

## 中国：名称必须反映真实属性

国内这一侧的规则口径又不一样。

预包装食品的标签规则要求名称必须反映食品的真实属性，不得使用虚假、夸大或者容易引起误解的名称。

它不像欧盟那样给出一张封闭清单，而是给了一条判据，由生产者按判据自己确定。

结果是同一类商品在不同品牌的包装上，名称的写法比欧洲市场分散一些。

这对做国内站的人是个好消息也是个坏消息：好在自由度高，坏在没有现成的官方词表可抄。

处理办法只能退回到老路上：把同品类几家主流品牌的包装名称都收一遍，取交集当核心词，取并集当覆盖面。这跟本桶讲代际词汇时用的办法是同一套，词表照着全体人口说话的样子建那一篇 (https://zhangwenbao.com/minor-language-generational-vocabulary-older-buyers.html)里那套按人群分层收词的思路，在这里换成按品牌分层收词。

## 法定名和营销名该分别写在页面的哪一格？

## 标题里放哪一个

先说最贵的那一格。

标题里放什么，判据是这个页面主要接哪一类查询。

购买前意图为主的页面，营销名称在前，法定名称可以不进标题。

购买后意图为主的页面，比如使用指引、退换说明、成分解读，法定名称应该进标题。

两个都想要的时候，正确的做法不是把两个名字都塞进去，而是拆成两个页面各自承接。

还要提醒一句：标题元素里写了什么，跟结果页上最终显示什么是两件事。引擎可能从页面上另挑一段字顶替上去，而它挑中的那段字在多语言站上未必是这门语言 (https://zhangwenbao.com/minor-language-serp-title-rewrite-source-language.html)。所以标题这一格写完之后，还得去结果页上确认一眼它有没有被换掉。

有一种情况可以两个都放而不显得堆砌：法定名称本身就是用户熟悉的日常词。这在食品和纺织品上并不少见，纤维名称就是典型，它既是法条里的官方名称，也是普通人日常就这么说的那个词。判断办法很简单，把它念给一个不做这行的人听，他要是不用你解释就懂，那就可以直接放主位。

## 正文里必须出现一次

不管标题怎么排，正文里应该保证法定名称自然出现至少一次。

出现的位置最好在首屏之内，跟商品的基本描述放在一起。

写法不必生硬，一句这类产品在本地通常标注为某某，就足够自然。

这一句同时解决三件事：接住了那批查询、跟包装对上了口径、也顺手给不熟悉品类的用户做了一次解释。

一句话干三件事的机会不多，这算一个。

要避免的是把它塞进一堆同义词里凑数。这批词的价值在于精确对应实物，堆在一起反而稀释了这种对应关系，还会把页面写得像法条摘抄。

## 属性表是最合适的收纳处

如果只能选一个位置放，选属性表。

属性表天然适合放这种严格、正式、一一对应的信息。

给它一个明确的字段名，比如商品品类标注或者法定名称，让用户一眼知道这是什么。

纺织品的纤维成分、化妆品的成分表、食品的配料表都可以按同样的思路处理。

属性表还有一个好处：它是结构化的，便于跨语言维护和批量核对。

要注意属性表里的值在多语言站上很容易被漏翻，因为它们常常被当成数据而不是内容。喂给渠道的那一份尤其容易出事，站上加一门语言是加一套模板，喂给平台的那份数据要多一整份文件 (https://zhangwenbao.com/minor-language-product-feed-language-fields.html)那一篇讲过属性值那一列为什么翻了页面却没翻数据。

## 结构化数据里那一格该填哪个

标记这一层要分开看。

商品名称这个字段应该填用户认得的那个名字，也就是页面上的主名称。

法定名称如果不是主名称，可以放进别名字段，两者不冲突。

成分、材质这类信息有各自对应的字段，按字段填就行，不要都堆进描述里。

填哪一个的判据不是哪个更正式，是页面上主打的是哪一个。

标记这一层的职责是把已经确定的答案写下来，答案本身由页面策略决定。这条原则在本桶反复出现过，标记从来不是做决定的地方。

## 怎么半天之内把这批词补齐？

## 第一步：拿三样东西

动手之前先把原料备齐，一共三样。

第一样是实物包装，从仓库或者样品柜拿，每条产品线取一件。

第二样是随货说明书或者电子版的产品资料。

第三样是法务那边的标签审核记录或者注册文件。

三样里拿到任意一样就能开始，三样都有最好，因为它们可以互相校验。

如果公司规模小、三样都没有现成的，退一步：去目标市场的主流零售站上找同类商品，看它们的商品页和图片里那个词是怎么写的。这一步不如前三样权威，但足够启动。

## 第二步：按品类查官方名词表

第二步是去法条那一侧核实。

纺织品查纤维名称附录，化妆品查成分命名数据库，食品查名称规定与本国的实施条例。

查的时候直接切到目标语言的版本，因为你要的就是那一版的官方措辞。

欧盟的法规文本各语言版本都能公开取到，切换语言通常只是换一个参数。

把查到的名称和从包装上抄来的对一遍，两者一致说明包装做对了，不一致要先问法务而不是先改页面。

这一步还有个附加产出：你会顺手拿到一批相关的官方术语，比如剂型、用途分类、规格单位的标准说法。这些词同样是页面上该出现而通常没出现的。

查表的时候顺手记一件事：同一件商品由不同进口商引进同一个市场时，包装上的名称有可能不一样，因为标注责任落在进口商身上。做分销和多渠道的站要按实际在售的那一版记，别按品牌总部给的那一版记。

## 第三步：做成两列对照表

第三步是把成果落成一份可交付物。

表的结构很简单：左列是营销名称，右列是法定名称，再加一列语言、一列出处。

出处这一列不要省，它决定了半年后有人质疑时你能不能答得上来。

表建好之后同步三方：内容团队、投放团队、以及维护商品数据的人。

再加一列复核日期，一年一次。

复核这件事有个明确的触发条件：法条附录会增补新条目，商品的配方或者分类调整也会改变它适用哪一条。所以复核找的不是变动，是新增，这让复核变成一件机械而且可交付的事。

## 第四步：验量与验竞争

最后一步是判断这批词值不值得投入。

先用搜索建议验真实性：把词打进去看它补出什么，补不出任何东西的词优先级往后放。

再看服务这批查询的现有页面质量，页面越糙机会越大。

然后按前面说的三个场景给词分堆，售后类的词优先，因为它们最容易转成复购。

最后才是排期，按品类逐条改页面。

整套流程走完，一个人半天到一天。产出是一份带出处的多语言对照表和一份改页面的清单，两样都能直接交出去。这件事最大的特点是投入极小而且确定性极高，因为你不是在猜用户怎么说，你是在抄一份已经有人签过字的答案。

## 哪些做法看着省事，实际会踩到别的线

## 直接机翻法条里的名称

最容易犯的错是拿英语版法条里的名称去机翻成目标语言。

这等于把一份现成的官方译本扔掉，然后自己重造一个不准确的。

更麻烦的是机翻出来的词看着完全合理，谁都挑不出错，只是没人这么说。

各语言版本本来就都在，切一个参数的事，没有任何理由去翻。

这跟经英语中转翻译那件事是同一类错误：中间多走一站，损失的是那些英语装不下的东西。

区别在于，这一次损失得格外冤，因为目的地那一版本来就是现成的，你只是没去拿。

## 把法定名称当关键词堆进标题

第二个坑是发现这批词有量之后用力过猛。

把法定名称、营销名称、俗称一股脑塞进标题，读起来像药品说明书。

这批词的价值在于精确对应，堆砌恰好破坏了这种对应。

而且标题一旦写得又长又堆，被引擎弃用另挑一段的概率会明显上升。

正确的做法是一个页面主打一个说法，其余的靠正文一次自然提及和属性表接住。

这条判据在本桶反复出现：展示层只选最大的那一个，剩下的靠匹配层收纳。匹配层不对外展示，所以它可以收得很宽而不伤观感。

还有一个隐蔽的副作用：这批词读起来正式，一旦在标题和首屏堆多了，整个页面的语域会被拉高一档，而语域拉高会连带影响转化文案的语气。这跟母语审校总把承诺强度往下调是同一类现象，语言上的每一次微调都在悄悄改变页面在读者心里的位置。

## 只在一个市场做

第三个坑是把它当成某一个市场的特殊问题。

这批词在每一个有标签法规的市场都存在，只是各国的规则形态不同。

只补一个市场，等于把一个可以横向复制的动作做成了一次性项目。

而横向复制的成本极低，因为流程完全一样，换的只是查表的那一步。

建议一次把所有在售市场都过一遍，反正原料是同一批实物。

顺带说一句，这件事做完之后你会得到一份意外的资产：一张按语言排开的品类名称对照表。这张表在做新市场评估、投放否定词、以及站内搜索同义词的时候都用得上。

## 用旧版法条里的名称

第四个坑跟时间有关。

法条会修订，附录会增补，品类的划分也会调整。

用五年前那份文件里的名称，可能已经不是现在的官方说法。

包装那一侧通常会跟着更新，因为不更新会被查；页面这一侧没人查，所以它会一直用旧的。

这就是那一列复核日期存在的理由。

还有一种更隐蔽的情况：商品本身的配方或者用途调整之后，它适用的规则条目变了，名称也就跟着变。这类变化往往只有产品团队知道，内容团队不会收到通知，所以复核的时候要连产品变更记录一起看。

## 这件事的边界，哪几件不归它管

最后划一下边界。

合规文本本身怎么写、标注在包装上的位置和字号，那是法务和包装设计的事，不归做内容的人决定。

本篇只讨论一件事：那个已经被定下来的名称，有没有出现在页面上。

另外，法定名称有官方译本不等于它一定有搜索量，量还是要验。

有几个品类的法定名称确实生僻到没人用，那就只放进属性表和匹配层，不必进标题和正文重点位置。

还有一部分归架构层和引擎层：各语言版本用什么域名结构承载、地区定向怎么配，跟语种本身无关，不在这里展开。

把边界划到这里，这件事的排期就落在内容和产品两个角色身上，加上法务那边一次半小时的配合。这大概是本桶写过的所有问题里，跨部门成本最低、确定性最高的一件。

## 常见问题解答

## 法定名称听起来很生硬，写进页面会不会伤转化？

取决于放在哪一格。放进标题和首屏主视觉确实可能伤转化，因为那两个位置需要的是让人产生兴趣的表达；放进正文的一句解释性句子和属性表里，则完全不伤，反而增加专业感和可信度。推荐的做法是营销名称占据展示位，法定名称在正文里自然出现一次，同时进属性表。这样既接住了带着实物来搜的那批用户，又没有牺牲第一眼的观感。真正伤转化的从来不是某个词生硬，是整段文字读起来像法条摘抄。

## 怎么知道我这个品类到底有没有法定名称？

最快的办法是拿一件实物看包装正面，法规要求必须标注的品类名称通常就印在最显眼的位置。第二快的办法是问法务或者产品注册那边，问一句这个品类在各市场包装上标注的名称是什么，多数公司这份资料是现成的。第三是按品类去查对应的规则：食品查名称规定与本国实施条例，纺织品查纤维名称附录，化妆品查成分命名数据库和功能标注要求。三条路里第二条最省事，一封邮件通常一天就能拿到答案。

## 欧盟法条的各语言版本在哪儿拿？

欧盟的法规文本按规定要以所有官方语言发布，各语言版本具有同等法律效力，可以公开取得，切换语言通常只是换一个参数。委员会和各成员国的官方入口也提供针对具体品类的说明页，那些页面比法条原文好读，适合先看。要注意的是有些法条数据库对自动化访问有限制，直接在浏览器里打开通常没问题。取到之后建议把出处记进对照表的出处列，这一列在半年后有人质疑时特别管用。

## 成分名全球统一，那还需要按语言处理吗？

成分名本身不需要翻译，全语言共用一份，这是它最省事的地方。但用户口语里的俗称是按语言各不相同的，同一种成分在德语、法语、波兰语里的日常说法完全不一样。所以正确的做法是两个都出现：成分表里用统一命名保证合规与专业信任，正文里让本地俗称自然出现一次接住口语查询。这批统一命名的词大概是小语种项目里唯一一批做一次全语言受益的关键词，性价比极高，值得优先处理。

## 这批词跟通名化商标那一类，处理办法一样吗？

方向正好相反。通名化商标是有量但不能写，处理办法是留在词表里标清状态、只在站内搜索同义词这类不对外展示的匹配层收纳，页面正文里一个字都不能碰。法定名称是法律要求这件商品必须被这么叫，写进页面完全安全，还能顺带增强专业感。两者的共同点只有一个：取值都不由你决定，都要去法律那一侧拿，因此都不会出现在关键词工具的建议列表里。把这两类词并排放进同一张表，标一列状态区分，是最省心的管法。

## 只做国内市场，这一篇还有用吗？

有用，但形态不同。国内的规则给的是判据而不是封闭清单，要求名称必须反映真实属性、不得虚假夸大，具体名称由生产者按判据自己确定。结果是同类商品在不同品牌包装上的名称写法比欧洲分散。所以国内市场没有现成的官方词表可抄，只能退回到收集法：把同品类几家主流品牌的包装名称都收一遍，取交集当核心词，取并集当覆盖面。这条路比查法条累，但方法论是一样的，都是承认包装上那个词才是用户手里的那一个。

## 这份对照表多久要复核一次？

建议一年一次，另外有两个必须额外复核的触发条件。一是法条修订或者附录增补，新的纤维名称、新的成分条目会陆续加进去；二是商品本身的配方、用途或者分类发生调整，调整之后它适用的规则条目可能就换了，名称也跟着换。第二类变化通常只有产品团队知道，内容团队不会收到通知，所以复核的时候要连产品变更记录一起看。复核的动作是找新增而不是找变动，这让它变成一件机械且可交付的事。

## 补齐这批词之后，多久能看到效果？

这批查询的量级通常不大但意图很硬，所以指标上的表现是稳步爬升而不是陡增。观察窗口建议按季度看，重点不是总流量而是三件事：站内搜索里那批页面上不存在的查询词有没有减少、售后类咨询量有没有下降、以及复购路径上的自然流量占比有没有变化。第二件事尤其值得盯，因为用户搜得到答案就不来问了，客服工作量的下降是这件事最直接也最容易被忽略的收益。

## 权威参考资料



## 你在后台改了三遍的那行标题，引擎一次都没用过，它拿去顶替的是页脚上那个英文站名

- URL：https://zhangwenbao.com/minor-language-serp-title-rewrite-source-language.html
- 分类：小语种SEO
- 发布：2026-07-31  |  更新：2026-07-31
- 摘要：引擎替换标题时只搬运现成字符串，不做翻译。讲清取材范围里哪三处最不容易被翻到、站点名为什么全站只有一份、后台三类工具为什么一个都看不见这件事。
- 关键词：技术SEO,多语言SEO,内容本地化,小语种SEO

> **TLDR**：摘要：你写在模板里的那行标题，和用户在结果页上看到的那行，是两个字符串。引擎替换时不会自己造句，它从页面上另挑一段现成的文本顶上去，而取材范围里排在前面的几处，恰好是多语言站上最不容易被翻译到的：全站共用一份的站点名、走另一条链路的导航与面包屑、由别人写的外部锚文本。于是替换在单语言站上只是换了句话，在多语言站上是换了一门语言。

> 摘要：你写在模板里的那行标题，和用户在结果页上看到的那行，是两个字符串。引擎替换时不会自己造句，它从页面上另挑一段现成的文本顶上去，而取材范围里排在前面的几处，恰好是多语言站上最不容易被翻译到的：全站共用一份的站点名、走另一条链路的导航与面包屑、由别人写的外部锚文本。于是替换在单语言站上只是换了句话，在多语言站上是换了一门语言。

## 波兰语页面在结果页上顶着两个英文词，而模板里那行字一个英文都没有

## 一家户外露营装备站的波兰市场，展现涨了点击没动

有个客户做户外露营装备，帐篷、睡袋、营地灯、便携炉具这几条线。

德国、波兰、捷克三个市场，页面都做了本地语言，商品结构也基本一致。

那一季他们把三个市场的标题模板统一重写过一轮，德国和捷克的点击率都往上走了一截，波兰这边只有展现在涨，点击几乎原地不动。

团队先怀疑是季节因素，波兰的露营旺季比德国晚半个月，等了三周，曲线还是那个形状。

接着怀疑是价格，把三个市场的同款商品价格拉出来比，波兰这边并不吃亏。

再往下就开始怀疑内容质量了，追加了一批波兰语的选购指南，指标依然没有反应。展现在涨说明引擎认为这些页面配得上这些查询，点击不涨说明用户在结果页上看到你之后选择了别人，中间隔着的只有那一行标题和那一段摘要，可这两样在后台里看着都没问题。

## 后台里那行标题是干净的波兰语

他们的标题模板写得相当规矩：品类词在前，属性词在中间，品牌名放最后。

三个市场共用一套模板结构，词槽各填各的，波兰语那一份是找母语译者做的。

抓取诊断工具跑过，返回的源码里那行标题完整、正确、全是波兰语。

站长工具里的页面报告也没有任何提示，收录正常，索引状态正常。

所有能在自己这一侧检查的地方都检查过了，结论是标题没问题。

问题在于，这些工具读的都是同一样东西，也就是你自己发出去的那份源码。它们回答的是你写对了没有，而不是用户看到了什么。这两个问题在单语言站上答案通常一致，在多语言站上未必。

## 换一台电脑从结果页看，那行字变了

保哥让他们换一台没登录过的机器，开无痕窗口，把地区参数设成波兰，直接搜商品词。

结果页上那一行标题的前半截还是波兰语的品类词，后半截接了两个英文单词，中间用一条竖线隔开。

那两个英文单词是他们的英文站点名，也是全站页脚里一直挂着的那个名字。

再翻十几条，同样的形状反复出现，有几条更彻底，整行标题被换成了英文品类词加英文站点名。

德国和捷克的结果页上也有替换，但换进去的是德语和捷克语，读起来毫无违和感，所以这两个市场的点击率不但没掉，还因为标题变短而涨了一点。

同一个机制，在三个市场里给出了三种结果：两个市场受益，一个市场受损。受损的那个市场之所以受损，不是因为引擎对它有偏见，而是因为它是三个市场里唯一一个替换源和页面主体语言不一致的。

## 一句话判据：把两行字并排抄下来

这件事的排查成本极低，低到不值得先做假设。

打开无痕窗口，搜一条你确定自己排在首页的查询，把结果页上显示的那行标题原样抄进一张表的左列。

再打开你自己的页面，把源码里那行标题抄进右列。

两列不一样就说明发生了替换，两列语言不一样就说明发生了这一篇要讲的那种替换。

抄二十条，你就知道自己站上有没有这个问题，以及有多严重。

这个动作的价值在于它绕开了所有工具。工具能告诉你标题写得合不合规、有没有超长、有没有重复，唯独不能告诉你它最终有没有被用。而这件事只能靠肉眼在结果页上确认，没有第二条路。

## 搜索结果里那行标题，到底是从哪几处文本里挑出来的？

## 官方把取材范围写成了一张清单

这不是需要靠猜的事，引擎自己把范围写在文档里了。

用来生成结果页标题的候选文本包括：页面的标题元素、页面上的主标题与其它显著文字、页面上的其它内容、指向这个页面的锚文本，以及站点名。

换句话说，标题元素只是候选之一，不是唯一来源，更不是默认来源。

这张清单最值得注意的地方不是它列了几项，而是它把范围划到了页面之外：锚文本来自别的站，站点名来自域名级别的判断。

页面级别的内容你能改，域名级别的东西全站共用，站外的东西你根本改不了。

把这张清单按归属重新排一遍，五项里只有两项完全归内容团队管，剩下三项分别归前端、归品牌、归别人。这个归属结构才是后面所有麻烦的根源，而它跟语言这件事天然不兼容，因为语言恰恰是按页面分的。

## 为什么会有替换这件事，它解决的是别的问题

替换机制不是针对多语言站设计的，它解决的是一批很实在的老问题。

有的页面根本没写标题，有的写了但整站几万页一模一样，有的塞满了关键词读不成句，有的写着首页两个字却是个商品页。

对这几类页面来说，从正文里挑一段更贴切的文字顶上去，用户体验确实更好。

行业里有过一次规模不小的实测，抽了两千多个站的八万条标题，结果页上显示的标题里大约有六成跟源码里那行不一样。

六成这个数字第一次公布的时候引起过不小的骚动，但它本身并不说明标题不重要，它说明的是标题这个字段从独占变成了候选。

这套机制在英语世界里被讨论了很多年，讨论的焦点始终是改写率、是怎么把标题写到不被改。这些讨论有一个共同的默认前提：改写之后那行字仍然是这门语言。这个前提在英语站上成立得太好，好到没人想过它是一条假设。改写这件事本身的机制、触发条件和应对策略，保哥在用AI重写标题的机制与应对 (https://zhangwenbao.com/google-ai-headline-rewrite-seo.html)里已经拆过一遍，这一篇不重复那部分，只讲那条假设在多语言站上不成立之后会发生什么。

## 替换不是翻译，它只是换了一段现成的字

这里要先把两件容易混的事分开。

引擎确实有把整页翻译过来展示的能力，那是另一套机制，触发条件、展示形态和归属都不一样。

本篇讲的替换不涉及翻译：它只是从你的页面上或者站外的锚文本里，原样取一段现成的字符串顶到标题位上。

原样这两个字是关键。它不会把英文站点名翻成波兰语再放上去，它就是把那两个英文单词直接摆在波兰语品类词后面。

所以替换的结果是不是本地语言，完全取决于被取走的那段字本身是什么语言。

这也解释了为什么单语言站永远遇不到这个问题。英语站上所有候选源都是英语，随便取哪一段，出来的都是英语。多语言站不一样，它的候选源里混着几种语言，而混进去的那几处恰好是最不容易被翻译到的。

## 候选之间有优先级，但优先级不看语言

引擎在几个候选里怎么选，大致有个偏好顺序：标题元素写得准确、长度合适、跟正文一致时，优先用它。

标题元素被判定为不好用时，才会往下找。往下找的时候，页面主标题的分量最重，其次是页面上位置显著的文本，再往后是锚文本。

站点名比较特殊，它不参与竞争，而是作为后缀被拼接上去，替换掉你原本写在标题里的品牌部分。

整个选择过程里没有任何一步在检查语言一致性。

它检查的是描述得准不准、长度合不合适、是不是重复、跟正文对不对得上，这几条全部是语义和结构层面的判据。

语言一致这件事在单语言世界里是自动满足的，所以没有人需要把它写成一条判据。这是本篇最核心的那条机制：不是引擎判错了，是这套判据里压根没有语言这一维，而它在多语言站上恰恰是最先出问题的那一维。

## 为什么替换在多语言站上会变成换了一门语言？

## 取材源里最容易漏翻的是哪几处

把五个候选源按翻译覆盖率排一遍，结论会很刺眼。

标题元素和正文这两处覆盖率接近百分之百，因为它们就是翻译交付清单上的主体。

页面主标题通常也翻了，但它跟标题元素常常是两个字段、两条链路，后面单说。

导航条、面包屑、页脚这几处属于界面文案，走的是资源文件或者主题模板，跟内容库不是一套东西。

站点名是全站一份，锚文本是别人写的，这两处根本不在翻译这件事的讨论范围里。

所以覆盖率越低的那几处，越靠近替换发生时被取用的位置。这个巧合不是巧合：引擎挑的是稳定的、位置显著的、能概括页面身份的文本，而这类文本天然是模板级的、全站共用的，也正是本地化流程最容易跳过的那一类。界面文案这一层为什么会被系统性跳过，硬编码字符串与伪本地化那一篇 (https://zhangwenbao.com/minor-language-hardcoded-ui-strings-pseudo-localization.html)把成因写得很细，这里只借它的结论。

## 站点名只有一份，而它是全站唯一一处跨语言共用的名字

站点名这一格值得单独说，因为它的约束最硬。

它是域名级别的判断，引擎给一个站定一个名字，不是给一个页面定一个名字。

你的站有九门语言，站点名仍然只有一个。

这意味着不管用户看的是哪门语言的页面，被拼到标题后面的那个后缀都是同一串字符。

如果这串字符是英文品牌名，那问题不大，品牌名本来就常常保留原文。

如果这串字符是英文品牌名加一个英文品类词，比如某某牌加上户外装备这两个英文单词，那就是每一门语言的每一条结果都被塞进两个外语词。这一格没有按语言拆开的机制，只能选一个全语言都能接受的写法，这是本篇给出的第一条硬约束。

## 导航与面包屑走的是另一条链路

导航项、面包屑、分类名这几样东西在系统里通常不住在文章表里。

它们要么在分类表里，要么在菜单配置里，要么直接写在模板文件里。

翻译交付清单是按页面模板列的，这几样东西不在页面模板里，于是它们经常整批留在源语言状态。

更隐蔽的是半翻状态：一级导航翻了，二级没翻；面包屑的中间层翻了，最前面那个首页两个字没翻。

而面包屑最前面那一节恰恰是替换时最爱取用的位置之一，因为它稳定、简短、能表达页面在站内的位置。

排查这一层有个笨但可靠的办法：把页面另存为纯文本，然后用一个只包含本地语言字母的字符集去扫，扫出来的每一个落在字符集之外的词都标出来。二十个页面扫完，哪几处没翻一目了然，比逐个模板去读源码快得多。

## 外部锚文本天生是别人写的

第四处候选是指向这个页面的锚文本，它的语言由链接方决定。

本地媒体链你，锚文本多半是本地语言；行业目录链你，多半是分类名；而你自己在英文站或者英文新闻稿里链过去的那些，锚文本就是英文。

出海站有个很常见的结构：英文主站是最早建的，权重最高，内链最密，而它指向各语言子目录的那些链接，锚文本一律是英文。

于是你自己的站，成了给自己的波兰语页面提供英文锚文本的最大来源。

这一处你改不了别人的，但能改自己的。把英文主站指向各语言版本的锚文本按目标语言写一遍，成本很低，收益是把一整类替换源清干净。

屈折语这边还要多想一层：锚文本在这类语言里天然会变形，报表里那个精确匹配的数字本身就是假的，这件事锚文本在屈折语里变形那一篇 (https://zhangwenbao.com/minor-language-internal-link-anchor-inflection-variants.html)讲过。它跟本篇的交叉点在于：被取去当标题的那个锚文本形态，未必是你希望出现在标题里的那个形态。

## 这条连锁只在多语言站上成立

把前面几节合起来看，会得到一个结构上很整齐的结论。

替换的取材源里，语言覆盖率最低的三处，恰好是被取用概率最高的三处。

单语言站上这三处的语言跟正文一致，所以替换发生了也没人察觉，甚至是好事。

多语言站上这三处经常留在源语言，于是替换一发生就是跨语言的。

损失的方向也很明确：用户在结果页上看到一行半生不熟的字，第一反应不是这家店英语好，而是这家店不是本地的。

这跟同意横幅那件事的结构一模一样，都是一段不归你的翻译流程管的文本，出现在了用户最先看到的位置。区别在于横幅至少还在你的页面上，改一改总能改到；而结果页上那行字连改的入口都没有，你只能去改它的原料。

## 这件事为什么在你自己的后台里一次都不会报错？

## 你的检查工具读的是源码里那行字

先说最常用的那一类工具：爬虫式的站点体检工具。

它们抓你的页面，解析标题元素，然后按长度、重复、缺失这几条规则打分。

这套检查的输入是你发出去的源码，输出是你写得合不合格。

而替换发生在展示这一侧，跟你发出去什么没有直接关系。

所以哪怕全站每一条标题都被换掉了，这类工具依然会给你一片绿。

像素级预览类的工具也是同理，它按显示宽度模拟截断位置，模拟的对象仍然是你写的那一版。这类工具在控制长度上很有用，用模拟器做像素级预览那一篇 (https://zhangwenbao.com/serp-simulator-pixel-truncation-ctr-preview-guide.html)讲过怎么用它，但它按定义就看不见替换。

## 站长工具给的是查询与点击，不给展示出来的标题

第二类是引擎自己的站长工具。

它给的是查询、展现、点击、位置这四个维度，没有一个字段叫做实际展示的标题。

这不是疏漏，而是因为展示出来的标题是按查询变化的：同一个页面在不同查询下可能被换成不同的字。

一个页面对应一行标题这个模型，在展示这一侧本来就不成立。

于是这份数据里，点击率异常是唯一的信号，而点击率异常有一百个可能的原因。

本篇这个原因还特别不容易被想到，因为它的表现是展现正常、排名正常、只有点击率低，而这套症状最容易被解释成竞争对手的标题写得更好，然后团队就去改标题了，改的还是那个根本没被用上的字段。

## 抓取诊断显示的也是你写的那一版

第三类是抓取诊断和实时测试工具。

它们返回的是引擎抓到的原始响应或者渲染后的文档。

你在里面能看到标题元素、能看到结构化数据、能看到渲染后的正文。

看不到的是展示决策，因为展示决策发生在索引之后、结果页生成之时。

抓取跟展示中间隔着索引和排序两层，工具停在第一层。

所以这三类工具加起来能覆盖标题这件事的九成检查项，唯独覆盖不了最后一步。而最后一步恰恰是用户唯一能看到的那一步，这有点像把菜谱、食材、火候全检查了一遍，就是没人尝一口。

## 唯一能看到真相的地方是结果页本身

结论很朴素：想知道用户看到什么，只能去用户看的那个地方看。

这件事没有工具可以代劳，因为没有任何接口把展示出来的标题吐出来给你。

好在它足够便宜，二十条查询、二十分钟，一个不懂技术的人也能做。

难的不是做，是想到要做，以及把它固定成一个动作而不是一次性排查。

把它挂在改版发布和新语言上线这两个节点上，是成本最低的挂法。

还有一条容易被忽略的触发时机：更换主题模板或者升级建站系统的时候。这一类改动经常会重置导航与面包屑的文案来源，把原本翻好的那一份换回默认值，而默认值是英文。这跟错误页那件事的成因是同一类，请求一旦离开你自己维护的那部分，兜底出来的那一版就不认你的语言设置了 (https://zhangwenbao.com/minor-language-error-page-fallback-language.html)。

## 怎么用二十分钟测出自己有没有中招？

## 第一步：按语言各取二十条查询

从站长工具里导出最近三个月的查询报表，按语言版本的地址前缀拆开。

每门语言取二十条，取法是展现量前十条加点击率最低的十条。

前十条代表你最重要的门面，点击率最低的十条最可能是出事的那一批。

把这二十条查询和它们各自对应的落地页地址列成两列。

这一步的意义在于抽样有偏是对的：你不是在做统计，是在找病灶。

顺手记一件事：这二十条里有几条落在列表页和筛选页上。这两类页面的正文短，标题在整页文本里的占比高，被替换之后受到的连带影响也最大，后面讲语言判定那一节会再回到这一点。

## 第二步：并排抄两列

开无痕窗口，把地区和界面语言参数都设成目标市场，逐条搜过去。

结果页上显示的标题原样抄进左列，页面源码里的标题元素抄进右列。

不要凭印象记，一定要抄，因为差异常常只有两三个词，凭印象会漏。

抄的时候把分隔符也抄上，竖线、短横、破折号这几种符号本身就是替换留下的指纹。

二十条抄完，差异率和差异形态一眼就能看出来。

有两个操作细节值得说明。一是必须用无痕窗口，否则个性化和搜索历史会干扰结果；二是要指定地区参数，因为你人在国内看到的波兰结果页和波兰用户看到的未必完全一样，这一点跟同意横幅那件事一样，唯一能复现新访客视角的办法就是无痕窗口 (https://zhangwenbao.com/minor-language-consent-banner-language.html)。

## 第三步：给差异分四类

抄完之后不要急着下结论，先给每一条差异贴一个标签。

第一类是整行被换掉，换上来的是品类词加站点名的组合。

第二类是只有后缀变了，你写的品牌部分被换成了另一种写法。

第三类是前半截被换掉，换上来的字能在导航或者面包屑里找到原文。

第四类是被换成了页面主标题，也就是正文里那个最大的标题。

四类各自对应不同的修复位置，混在一起看只会得出标题被改了这个没用的结论。分类这一步花不了五分钟，但它决定了后面动手的地方对不对。

## 这个动作该多久跑一次

常规频率是一季度一次，二十分钟的事，挂在季度复盘里就行。

四个时机必须额外跑一次：改版发布之后、新语言上线之后、换主题模板或者建站系统之后、以及品牌名或者站点名做过调整之后。

前三个时机的共同点是模板层的文案来源可能被重置。

第四个时机则是因为站点名的判断有延迟，你改了声明，引擎不会当天就跟着改。

把这四个时机写进上线检查表，这件事就不需要靠谁记得了。

还有一个反过来的用法：把左列那些被换掉的标题当成免费的诊断反馈来读。引擎选中的那段字，代表它认为这个页面最该被概括成什么样。如果它换上来的那个词你的标题里压根没有，那多半不是它挑错了，是你写漏了。

## 四类差异各自对应哪一处该修的地方？

## 第一类：整行被换成品类词加站点名

这一类最常见，也最容易修。

它通常发生在标题写得过长、或者模板化程度太高的页面上。

引擎认为你的标题不好用，于是自己拼了一个：主体从正文里取，后缀用站点名。

修的方向有两个：一是把标题本身压短、写具体，让它没有被弃用的理由；二是把站点名那一格按后面那一节的做法处理好。

两件事都做完之后，这一类差异通常会明显下降。

要提醒的是，被换掉不等于要慌。改标题这件事本身不会招来惩罚，改动本身不被罚，改错了内容才掉 (https://zhangwenbao.com/changing-title-tag-drop-ranking-myth.html)，所以发现替换之后完全可以放手去改，只是别把它当成一次紧急事故来处理。

## 第二类：品牌后缀被换成另一种写法

你写的是本地字母的品牌音译，结果页上显示的是拉丁原名，或者反过来。

这一类的根子不在标题，在品牌名这件事本身有几种写法并存，而各处声明得不一致。

页脚写一种、结构化数据写一种、外部媒体写第三种，引擎拿不准就自己挑一个。

修法是先把品牌名的主写法定下来，再让所有声明位置口径一致。

至于主写法该选哪一种，那是另一道题，答案不由品牌部决定。

品牌名在小语种市场会长出几种写法、该收哪一种，品牌名由当地用户的输入法决定那一篇 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)已经给过完整的判据，这一篇只需要接受它的结论：定下一种，然后处处一致。

## 第三类：前半截来自导航或面包屑

这一类最能说明问题，因为它把没翻译的那几处直接摆到了台面上。

你在结果页上看到的那个英文词，去页面上搜一遍，通常能在面包屑的第一节或者一级导航里找到。

修法很直接：把那几处补翻。

补翻的时候要连带处理形态问题，导航和面包屑上的词一般用主格或者词典形，这一点跟站内其它位置的用词规范未必一致。

补完之后再跑一次抄写动作，验证那个英文词是不是不再出现。

这一类还有一个变种值得留意：页面上某个位置显著的英文技术标识，比如型号前缀、认证名称、行业缩写，也可能被取去顶到标题前面。这类词本来就是不该翻的，处理办法不是翻它，是让标题元素本身足够好用，让引擎没有理由去取别的东西。

## 第四类：被换成页面主标题

这一类要单独讲，因为它暴露的是一个字段结构问题。

标题元素和页面主标题在多数建站系统里是两个字段，可以填不一样的内容。

正因为可以不一样，它们在多语言站上就常常走两条翻译链路：一条走内容编辑，一条走搜索设置面板。

结果是主标题翻了、搜索设置里那一栏还留着源语言，或者反过来。

引擎发现两者不一致时，倾向于用主标题，因为它跟正文的关系更紧。

排查办法是导出全站这两个字段做对照，凡是两栏语言不一致的行都拎出来。这份对照表通常还能顺手发现另一批问题：有一批页面的搜索设置栏是空的，系统自动拿主标题填了上去，那一批其实从来没被翻译流程碰过。

## 站点名这一格该怎么按语言填？

## 声明位置有优先级，最重的那张牌是结构化数据

站点名不是你想显示什么就显示什么，它是引擎综合判断出来的。

但官方给了明确的影响手段，而且标了轻重：首页上的网站类结构化数据最重，其次是社交协议里的站点名字段、标题元素、首页的主标题，以及首页上的其它文本。

很多站只填了后面几项，最重的那张牌没打。

把想要的名字用首页结构化数据声明一遍，再确保其余几处口径一致，这件事配置成本极低。

来源行这一整块的显示逻辑和三个要素怎么配，来源行被越改越重那一篇 (https://zhangwenbao.com/serp-source-line-display-emphasis-overseas-site.html)讲得比这里细，本篇只补语言这一维。

补的这一维是：以上所有声明位置，在多语言站上都指向同一个域名级别的判断。你在波兰语首页上声明一个波兰语站点名，在德语首页上声明一个德语站点名，最终生效的仍然只会是一个。

## 一个站点名只有一份，这条约束意味着什么

接受这条约束之后，选择空间一下就清楚了。

要么选一个不承载语义的纯品牌名，让它在每门语言里都只是一个专名。

要么选一个带品类词的组合名，然后接受它在所有非该语言的市场上都是外语。

绝大多数出海站应该选前者，理由不是美学，是这条约束本身。

品牌名后面挂一个英文品类词，看起来能多蹭一点关键词，实际代价是每一门语言的每一条结果都被塞进一个外语词。

这笔账很好算：那个品类词在标题后缀里带来的匹配收益，远小于它在八门语言的结果页上造成的观感损失。真要蹭那个词，正确的位置是标题本体和正文，不是全站共用的那一格。

## 别名字段能装下第二种写法

结构化数据里除了名称，还有一个别名字段，它能容纳同一个实体的其它写法。

拉丁原名和本地字母音译并存的品牌，可以主名称放一种、别名放另一种。

这不能让站点名按语言变，但它能降低引擎在几种写法之间拿不准的概率。

拿不准正是很多站点名显示成裸域名的原因。

显示成裸域名比显示成外语词更糟，因为域名连品牌都不算。

标记这一层能做的事到此为止：它只是把已经确定的答案写下来，答案本身不由它决定。小语种站的标记该怎么在本地化和国际格式之间取舍，结构化数据要反着写回国际格式那一篇 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)给过一套分类办法，站点名属于其中最不该本地化的那一类。

## 改完之后多久生效，怎么确认

站点名的判断有明显的滞后，改完当天不会有变化。

通常要等下一次首页被重新抓取和处理，实际观察多在一到几周之间。

确认的办法还是抄写动作，看后缀那一段有没有变成你声明的那个。

这期间不要反复改，反复改只会让引擎更拿不准，然后退回去显示域名。

改一次，等一轮，再看。

如果等了几周仍然没变，先检查三件事：首页的结构化数据是不是真的输出了并且能通过校验、几处声明的口径是不是真的一致、以及首页本身是不是能被正常抓取。这三件事里最常出问题的是第一件，尾逗号之类的语法错误会让整段标记失效，而页面上看不出任何异常。

## 屈折语和非拉丁文字的站，还要多担心哪一层？

## 换进来的那个词形态往往不对

屈折语站上有一层额外的麻烦：被取去顶替的那段字，形态未必是你想要的那一种。

面包屑和导航项通常用主格，而你的标题模板可能刻意选了另一种更接近检索形态的写法。

替换一发生，那份形态选择就被抹掉了。

波兰语这类七个格的语言尤其明显，同一个品类词的主格和其它格在字符串上差得不小。

用户在搜索框里打的多半不是主格，而结果页上给他看的偏偏是主格。

这不算致命，因为匹配发生在索引侧不在展示侧，但它会让标题读起来像是从目录里抠出来的一截，而不是一句给人看的话。波兰语的格变化怎么影响选词，只按词典原形选词会漏掉六个格那一篇 (https://zhangwenbao.com/polish-seo-seven-cases-diacritics-keyword-research.html)讲过，这里只是它在展示侧的一个尾巴。

## 非拉丁站上的拉丁字母残留最显眼

使用非拉丁文字的市场，这个问题的观感代价要高一档。

希腊语、俄语、泰语、日语的结果页上突然出现两个拉丁单词，视觉上是直接跳出来的。

拉丁字母混在西里尔或者天城文里，用户不需要读就能看见异物。

而在德语波兰语这类同样用拉丁字母的市场，英文词混进去反而更隐蔽，要读一遍才发现。

隐蔽不代表无害，它只是延长了被发现的时间。

所以排查优先级建议倒过来排：先查同为拉丁字母的那几门语言，因为非拉丁市场的问题多半早就被本地同事嚷嚷出来了，而拉丁字母市场的问题可能已经安静地存在了两年。

## 没有空格的语言，替换会撞上分词

泰语、日语这类不用空格分词的语言，还要多担心一层。

替换进来的那段字跟原有的本地文字直接相邻，中间没有任何分隔。

用户读到的是一串本地文字后面紧跟着一串拉丁字母，视觉上粘在一起。

更麻烦的是标题里的分隔符本身，竖线和短横在这类语言的排版习惯里出现频率本来就低。

结果是那一行字既不像本地写法，也不像外语写法。

泰语标题该怎么写才切得开、空格在这门语言里到底什么时候用，泰语标题里找不到一个空格那一篇 (https://zhangwenbao.com/thai-seo-no-spaces-word-segmentation-keyword.html)讲得很细，本篇的补充是：那套写法在被替换之后不成立，因为替换不遵守你的排版规则。

## 混语言标题在语言判定那一侧还要再扣一次

最后一层代价发生在展示之外。

标题是页面上位置最靠前、权重最高的一段短文本。

页面正文短的时候，标题在整页文本里的占比很可观。

而语言判定这件事本质上是在数字符和词，短文本判错的概率天生更高。

一个波兰语页面的标题里塞进两个英文词，对判定的影响远大于正文里塞进两个英文词。

受影响最大的还是列表页和筛选页这类字最少的页面，而它们往往是最赚钱的那一批。机器不完全相信你写在页面上的语言声明 (https://zhangwenbao.com/minor-language-page-language-detection-misidentification-short-text.html)那一篇讲过判定到底在数什么，把它跟本篇合起来看会得到一条不太舒服的推论：替换这件事不只损失点击率，它还可能反过来影响这个页面被归到哪门语言。

## 把哪几件事做扎实，替换就换不出别的语言？

## 第一周：只清点，一行代码都别改

第一周做三件事，全部是清点。

第一件是把抄写动作跑一遍，每门语言二十条，得到差异率和四类分布。

第二件是列一张取材源清单：标题元素、页面主标题、导航、面包屑、页脚、站点名、外部锚文本，逐项标注这一门语言下它是不是本地语言。

第三件是导出标题元素和页面主标题两个字段，找出语言不一致和空值的行。

三件事加起来一个人一天能做完，产出是一张能拿去开会的表。

先清点后动手这条顺序不是客套。这件事的修复成本分布极不均匀，站点名改一次全站受益，外部锚文本改起来慢且收效有限，不先看清楚就动手，多半会从最费力的那一头开始。

## 第二周：把站点名和两个标题字段处理掉

第二周动最重的那两件。

站点名按前面那一节的做法声明一遍，选一个不承载语义的写法。

标题元素和页面主标题的空值行补齐，语言不一致的行统一。

这两件做完，四类差异里的第一类和第四类通常就消掉大半。

这一周不要碰导航和面包屑，因为那一层改动会牵连模板，需要单独排期。

顺带把一件很容易被忘的事一起做了：检查各语言首页的标题元素。首页是站点名判断的主要输入，如果连首页标题都还是英文，后面怎么声明都是白搭。

## 第三周：补翻界面文案那一层

第三周处理导航、面包屑、页脚这几处。

先用前面说的字符集扫描法定位，再按语言逐条补。

补的时候把用词跟站内其它位置对齐，别造出第三种说法。

这一层补完之后，第三类差异会明显下降。

如果建站系统把这些文案锁在模板里改不了，那就退一步，至少把面包屑第一节那个词换掉，它是被取用频率最高的一个。

这一层还有个附带收益：这些词补翻之后，页面上的本地语言字符占比会上升，语言判定那一侧也跟着受益。改一处收两份钱的事不多，这算一件。

## 第四周：让标题本身好用到没有替换的理由

最后一周回到标题本身。

目标不是把标题写得漂亮，是把它写到引擎没有理由去找别的字。

三条判据：长度别超、别跟正文脱节、别整站雷同。

长度这一条在小语种上要按语言重算，同一句话翻成德语可能长出三成，翻成韩语则要按显示宽度而不是字符数算。

雷同这一条在模板站上最容易踩，几万个页面共用一套词槽，填出来的标题彼此差别太小。

这三条的机制和批量治理办法，标题被改写的六种典型情形那一篇 (https://zhangwenbao.com/title-meta-description-seo-mechanism-at-scale.html)讲过，语言这一维上要补的只有两句：长度阈值按语言各定一份，雷同判定按本地语言的词去看而不是按模板结构去看。

## 什么时候该接受被换掉

不是所有替换都要修。

换进来的那段字如果是本地语言、读着顺、还比你写的更贴切，那就是一次免费的编辑服务。

真正要修的只有两种：换进来的不是这门语言，以及换进来之后核心品类词消失了。

其余情况可以记录但不必处理。

把这条写进检查表，能省掉大量无谓的返工。

说句实在的，这套机制在多数时候是站在用户那一边的。它只是在多语言站这个场景下缺了一维判据，而这一维恰好是我们最在意的那一维。知道它缺在哪儿，比抱怨它改了你的标题有用得多。

## 这件事的边界，哪几件不归它管

## 截断不是替换

标题在结果页上显示不全，多数时候是截断不是替换。

截断按显示宽度算，跟你写了什么语言没关系。

非拉丁文字的字符占宽更大，同样的字符数在韩语日语上更早被切掉，这是另一条线上的事。

区分办法很简单：截断之后剩下的那段字一定是你写的那行的前缀，替换则不是。

抄写的时候把这两类分开记，别混成一类。

韩语标题能安稳显示的音节数大约只有英文字符数的一半，这类按语言重算显示预算的事，韩语标题挪一个空格就变词形那一篇 (https://zhangwenbao.com/korean-seo-spacing-particles-keyword-research.html)里有具体的口径。

## 引擎自己翻译展示的那一版是另一回事

结果页上还有一种形态：整条结果被翻译成用户的语言展示。

那是一套独立的机制，触发条件、展示形态和你的应对都不一样。

本篇讲的替换不涉及翻译，它只搬运现成的字符串。

两者在症状上有一点像，区分办法是看换进来的那段字能不能在你的页面上原样找到。

能找到就是替换，找不到、而且读起来像翻译腔，那多半是另一回事。

把这两件事分开很重要，因为它们的处理方向正好相反：替换要修的是原料，翻译展示要考虑的是要不要参与、以及怎么让自己的本地版本被优先选中。

## 排名和替换是两条线

最后澄清一件容易被误会的事。

标题被替换不代表排名有问题，也不会因为被替换而掉排名。

展现量说明排序这一侧认可你，点击率说明展示这一侧没打动人。

本篇从头到尾讨论的是后一件事。

把两件事混在一起，最典型的表现就是发现替换之后跑去大改内容，结果排名动了、点击率还是没动。

先看展现，再看点击，中间那一行字才是本篇的辖区。这条分工写清楚了，后面的排期才不会被带偏。

## 归架构层和引擎层的那部分

还有几件事跟本篇相邻但不属于它。

各语言版本用什么域名结构承载、地区定向怎么配、语言标注怎么写，那是架构层的题目，跟语种本身无关。

不同引擎的替换力度差多少、各家的偏好如何，那是引擎层的题目。

本篇只管一件事：替换发生时，被搬上去的那段字是不是这门语言。

这条边界划清楚之后，这件事的排期就落在内容和前端两个角色身上，不需要拉上架构和投放。

需要跨出去的只有一处：外部锚文本那一项，它归外链和公关，不归这两个角色。把它单独列一行，交出去，然后别指望它很快有结果。

## 常见问题解答

## 标题被引擎换掉，是不是说明我的标题写得不好？

不一定。替换的触发条件包括过长、堆砌、整站雷同、跟正文对不上、以及页面上存在更贴切的表述，最后这一条跟你写得好不好没有直接关系。判断办法是看换进来的那段字：如果它读起来比你写的更准确，那是一次免费诊断，说明你的标题漏了页面真正的主题；如果它只是把你的品牌部分换成了站点名、其余照旧，那多半只是后缀策略在起作用。真正需要警惕的只有两种情况，一是换进来的不是这门语言，二是换进来之后核心品类词消失了。除此之外记录下来即可，不必每一条都追着改。

## 为什么我在站长工具里看不到实际展示的标题？

因为展示出来的标题是按查询变化的，同一个页面在不同查询下可能被换成不同的字符串，一个页面对应一行标题这个数据模型在展示这一侧本来就不成立。站长工具给的是查询、展现、点击、位置四个维度，没有实际标题这个字段；抓取诊断类工具返回的是抓到的原始文档，也就是你自己写的那一版；第三方体检工具解析的同样是源码。三类工具能覆盖标题这件事九成的检查项，唯独覆盖不了最后一步。想知道用户看到什么，只能开无痕窗口去结果页上抄，这件事目前没有替代方案。

## 站点名能不能按语言各设一个？

不能。站点名是域名级别的判断，一个站对应一个名字，你在各语言首页上分别声明，最终生效的仍然只有一个。接受这条约束之后，选择就只剩两种：选一个不承载语义的纯品牌名，让它在每门语言里都只是一个专名；或者选一个带品类词的组合名，然后接受它在所有其它语言市场上都是外语。绝大多数出海站应该选前者。品牌名后面挂一个英文品类词，看上去能多蹭点匹配，实际代价是每门语言的每一条结果里都被塞进一个外语词，这笔账是明显不划算的。

## 把没翻译的导航和面包屑补翻了，替换就不会发生了吗？

替换照样会发生，但换进来的会是本地语言，这就已经解决了本篇讨论的问题。补翻界面文案不是为了阻止替换，是为了让所有候选源都落在同一门语言里。这跟单语言站的处境是一样的：英语站上替换天天发生，没人觉得是事故，因为换进去的还是英语。补翻之后还有一个附带收益，页面上本地语言字符的占比会上升，语言判定那一侧也跟着变稳，属于改一处收两份钱。

## 我们用的建站系统改不了导航文案，怎么办？

先退一步，只处理被取用频率最高的那一处，也就是面包屑最前面那个通常写着首页的词。多数系统即使锁死了菜单结构，这一处也有单独的配置项或者语言包条目可以覆盖。其次是把标题元素本身写扎实，让引擎没有理由去别处取字，这条对所有被锁死的场景都有效。再次是检查页脚，页脚往往比导航好改，而它同样是位置显著的模板文本。三条都做不到的话，把站点名那一格处理好，它的收益覆盖全站，且完全不依赖模板改动。

## 这件事对小语种市场的影响，真的比英语市场大吗？

结构上确实更大，原因不在于引擎区别对待，而在于候选源的语言一致性。英语站的所有候选源都是英语，随便取哪一段结果都自洽；多语言站的候选源里混着几种语言，而混进去的那几处恰好是翻译覆盖率最低的。用户看到半生不熟的一行字，第一反应通常不是这家店英语好，而是这家店不是本地的，这个判断发生在点击之前，代价直接落在点击率上。非拉丁文字的市场受损更明显，因为拉丁字母混在里面不用读就能看见。

## 多久检查一次比较合适？

常规一季度一次，二十分钟的事，挂在季度复盘里就行。另外有四个时机必须额外跑一次：改版发布之后、新语言上线之后、更换主题模板或者建站系统之后、以及品牌名或者站点名调整之后。前三个时机的共同点是模板层的文案来源可能被重置回默认值，而默认值一般是英文；第四个时机是因为站点名的判断有滞后，改完通常要等下一次首页被重新处理才会生效，实际观察多在一到几周之间。把这四条写进上线检查表，就不用靠谁记得了。

## 改完之后怎么知道有没有效果？

直接的验证是重跑抄写动作，看那几个外语词是不是不再出现，差异率有没有下降。间接的验证看点击率，但要注意点击率受排名位置影响很大，比较的时候要按位置分组看，别拿整体均值下结论。建议保留改动前的那份抄写表当基线，改完一个月后再抄一次同样的二十条查询，两张表并排放，变化一目了然。这个基线还有一个用处：下次改版之后如果问题复发，你能立刻判断是新引入的还是一直没修干净。

## 权威参考资料



## 那支视频的自动字幕把品牌名听成了另一个词，然后这行字被当成正文抓走了

- URL：https://zhangwenbao.com/minor-language-auto-caption-asr-error-rate.html
- 分类：小语种SEO
- 发布：2026-07-30  |  更新：2026-07-30
- 摘要：视频里那段话要先被机器听成文字才有机会被检索，而识别缺的正好是句末标点、专名大写、声调记号与型号写法。讲清各语言差距从哪来、术语表怎么喂、哪些语言的自动字幕该直接弃用。
- 关键词：视频SEO,多语言SEO,内容本地化,小语种SEO

> **TLDR**：摘要：站上的内容都是写出来的，只有一类例外：视频里那段话是说出来的，要先被机器听成文字才有机会被检索。这一步在英语上足够可靠，于是没人把它当成一个环节。可公开评测里同一套模型在大语种上是个位数错误率，到长尾语种能翻到几十个百分点。更麻烦的是识别结果缺的正好是检索最依赖的几样：句末标点、专名大写、声调与变音记号、数字与型号写法。品牌名会被听成别的词，而那行字以字幕文件的形式进了索引。本文给出错误率的读法、四类典型错法、三档校对判据与两天能跑完的体检。

> 摘要：站上的内容都是写出来的，只有一类例外：视频里那段话是说出来的，要先被机器听成文字才有机会被检索。这一步在英语上足够可靠，于是没人把它当成一个环节。可公开评测里同一套模型在大语种上是个位数错误率，到长尾语种能翻到几十个百分点。更麻烦的是识别结果缺的正好是检索最依赖的几样：句末标点、专名大写、声调与变音记号、数字与型号写法。品牌名会被听成别的词，而那行字以字幕文件的形式进了索引。本文给出错误率的读法、四类典型错法、三档校对判据与两天能跑完的体检。

## 你的文字要先被机器听懂，这条链上多了哪一步？

## 一家汽车用品站的越南语安装视频，字幕里没有一次品牌名

有个客户做汽车用品，行车记录仪、座套、车载支架、后视镜这些。

这个品类的内容形态天然偏视频，因为用户最关心的是装不装得上、怎么装。

团队做了一批安装演示视频，越南语和波兰语两个市场各配了本地讲解。

视频挂在商品页上，也传了一份到视频平台，转录文本也按建议放进了页面正文。

三个月后复盘，越南语那批视频的搜索表现远低于波兰语那批，而两边的制作水准是一样的。

保哥把越南语视频的自动字幕全文导下来读了一遍，读到第三条就停住了：整支七分钟的视频里，品牌名一次都没有正确出现过，每次都被识别成一个发音相近的普通词。用户搜品牌名加安装两个词，这批视频一条都接不住，而页面上那份转录文本原样抄的就是这份字幕。

## 别的内容是写出来的，这一类是听出来的

这件事值得单独拎出来说，因为它是本站讲了几十篇之后第一次出现的一种链路。

页面上的正文是写的，商品数据是填的，标题是拼的。

这几类内容不管中间经过多少道手，起点都是有人敲进去的一串字符。

视频里的那段话不一样，它的起点是一段声音。

要变成可被检索的文本，中间必须有一步把声音转成字，而这一步是机器做的。

换句话说，这是全站唯一一类你的文字要先被机器听懂，才有机会被读到的资产。这一步之前的所有努力——讲稿写得多好、术语用得多准、口音多标准——都要通过这个漏斗才能留下来。

## 听这一步在哪些地方替你做了决定

把这一步拆开，它替你做的决定比想象中多。

第一，它决定了哪些词进入文本，词表里没有的词会被替换成有的词。

第二，它决定了句子在哪儿断开，因为标点是它加的，不是你说的。

第三，它决定了数字写成阿拉伯数字还是写成词。

第四，它决定了同音的两个词里选哪一个，而这个选择基于它的语言模型而不是你的商品。

四个决定里没有一个征求过你的意见，而它们合起来基本决定了这段文本的检索价值。这是本篇跟其它篇最大的区别：别的篇里出问题的是你或者你的供应商，这一篇里出问题的是一段你既没参与也看不到的推理过程。

如果视频里不止一个人说话，还要多一步说话人分离。这一步的错误会以另一种形态出现：内容没错，但被归到了错的人头上，两个人的话被拼成一句。访谈类和客户证言类视频最容易踩，而这两类内容的价值恰恰建立在谁说的这件事上。判断办法是看字幕里有没有语义上明显衔接不上的相邻两句。

## 这跟人眼看到的和机器取到的不一致是同一族问题

本站讲过一种资产，人眼看到的字和机器取到的字可以完全无关。

视频字幕是这一族里的第二种，机制不同但症状同源。

那页规格书在屏幕上是好好的泰语，机器复制走的是另一串字符 (https://zhangwenbao.com/minor-language-pdf-text-layer-extraction-failure.html)讲的是映射表填错，人这一侧完美无缺。

字幕这一类的方向正好相反：人这一侧是耳朵听得清清楚楚，机器那一侧才出错。

共同点是两者都产出一串看起来像文本的东西，而那串东西的内容跟原意可能没有关系。

还有一个更实际的共同点：两者的错都不会报错。字幕生成成功了，文件是有的，时间轴是对的，格式是合法的，任何自动检查都会给绿灯。要发现它错了，唯一的办法是有一个懂这门语言的人真的读一遍。

## 同一套模型，为什么在你这门语言上错得特别多？

## 错误率这个指标是怎么算的

先把指标说清楚，否则后面的数字读不懂。

语音识别的通用指标是词错误率，把识别结果跟人工转录的标准答案对齐。

把替换、删除、插入三类错误的个数加起来，除以标准答案的总词数。

百分之十的意思是每十个词里有一个不对，这个数看着不高，读起来其实已经很吃力。

对不分词的语言，行业里改用字错误率，把单位从词换成字符，两个指标不能直接比。

这里已经埋着第一个坑：同一门语言用两种口径算出来的数字可以差出好几倍，而各家发布的评测表并不总是标清楚用的是哪一种。看到一个漂亮的数字先看它的单位，这跟本站讲可读性分数时的提醒是同一条——那把尺子的刻度当年是拿英语量出来的 (https://zhangwenbao.com/minor-language-readability-score-english-calibrated-formula.html)。

## 公开评测里各语言的差距有多大

好在这件事不用猜，有公开数据可查。

目前被引用最多的一份是大规模弱监督语音识别那篇的附录，它按语言列出了同一套模型的错误率。

那份表里的分布极不均匀：几门主要欧洲语言落在个位数，一批中等语言在十几到二十几，长尾语言能到四十以上甚至更高。

同一套模型、同一份评测集、同一个口径，差距完全来自语言本身。

另一份专门为多语言评测建的语音数据集覆盖了一百多门语言，可以拿来做交叉核对。

这两份材料放在一起，大规模弱监督语音识别 (https://arxiv.org/abs/2212.04356)给的是同一模型的横向对比，FLEURS多语言语音数据集 (https://arxiv.org/abs/2205.12446)给的是评测集本身的语言覆盖。做出海内容规划时，先去这两份里查一下自己那几门语言的位置，比任何供应商的承诺都实在。

这些数字要换算成体感才有用。词错误率百分之五左右，读起来基本顺畅，偶尔一个词要停顿一下。到百分之十五，每七八个词错一个，读的人要不断回头猜；到百分之三十，文本已经不能称为转录，它只是一堆跟原意有关的词。做决策时按这三个刻度分档，比记住具体小数点后几位有用得多。

## 差距的来源不是模型偏心，是训练音频的分布

为什么会有这么大的差距，原因说穿了很朴素。

这类模型靠大量的音频加文本配对训练出来。

网上能拿到的音频，语言分布极度倾斜，英语一门就能占掉一大半。

排到几十位之后的语言，能拿到的小时数可能只有英语的千分之一。

音频数据比文本数据更难得，因为它还要配上准确的转录。

这跟多语言模型铺到七十多种语言那天，受益最多的不是字母最像英语的那几门 (https://zhangwenbao.com/multilingual-bert-seventy-languages-minor-language-seo-watershed.html)那篇讲的文本侧格局是同一个形状，只是音频这一侧的倾斜更陡。文本还能从网页上大批量爬，音频要么靠公开语料项目一句一句众包，要么靠有字幕的视频，两条路的产量都低得多。

## 怎么二十分钟测出自己这门语言在哪一档

公开评测毕竟是通用领域，你的品类词能不能识别是另一回事，得自己测。

准备工作只要一样东西：一段三到五分钟、由母语者念的、含你核心术语的音频。

第一步，把它交给你实际在用的那条链路，拿到自动字幕。

第二步，请母语者按听到的内容手写一份标准答案。

第三步，把两份并排，只数三样：品牌名错了几次、型号错了几次、品类核心词错了几次。

不必去算标准的词错误率，那个数对决策没什么帮助。真正决定这批内容值不值钱的是这三类词的准确率，而它们在通用评测里恰好一个都不会被单独统计。保哥的经验是这三类词的错误率往往比整体错误率高出一大截，因为它们全是低频词。

测完之后如果结果不理想，先别急着加预算，拍摄环节有三件几乎零成本的事可以先做。第一是语速放慢一档，尤其在念型号和参数的那几句；第二是关掉背景音乐，或者至少在口播段落把它压到很低；第三是用领夹麦而不是机身麦，这一条对识别准确率的影响往往比换一个更贵的模型还大。

还有一个容易被忽略的变量是说话人的口音。同一门语言的不同地区口音，在识别上的差距可以跟两门不同语言一样大，而训练数据里覆盖的多半是标准音。如果你的讲解人带明显地方口音，测出来的数字会比公开评测差一大截，这不是模型的问题，是样本分布的问题。

## 自动字幕吐出来的那串字，缺了哪几样东西？

## 缺标点，于是没有句子边界

识别结果最直观的特征是它长得不像正常文本。

多数链路吐出来的是一长串词，标点要么没有，要么靠一个单独的模型补上去。

补标点这个模型的准确率通常比识别本身还低，尤其在小语种上。

结果是这段文本要么完全没有句号，要么句号落在莫名其妙的位置。

而检索这些年已经把最小单位降到了一句话。

抓答案那一步，为什么先要知道一句话到哪儿结束 (https://zhangwenbao.com/minor-language-sentence-boundary-passage-extraction.html)那篇讲的是标点本身在不同语言里的兼职问题，字幕这一层更狠：不是标点有歧义，是压根没有标点。那篇里所有依赖标点的判断方法，到这里全部失效。

## 缺大小写，于是专名认不出来

第二样缺的是大小写，这在拉丁字母的语言里代价很高。

识别结果默认全小写，专名的首字母大写要靠后处理补。

德语更惨，德语所有名词都要大写，缺了大小写等于整段文本的词性线索全丢。

而专名恰好是品牌名、型号、地名的载体。

一个全小写的品牌名在字符串匹配里未必出问题，可它在实体识别那一层的信号强度会明显下降。

这条跟转成小写这一步在英文站上从来不出事，到了土耳其语站它把词改成了另一个词 (https://zhangwenbao.com/minor-language-case-folding-lowercase-turkish-dotless-i.html)那篇是一枚硬币的两面：那篇讲的是主动折叠大小写造成的损失，这篇讲的是根本没拿到大小写。

## 缺变音符号与声调记号

第三样缺的东西按语言分布，而且分布得很不公平。

越南语的声调符号是词义的一部分，缺了就是另一个词或者不是词。

捷克语、波兰语、土耳其语的变音字母同理。

有些链路会输出不带符号的写法，有些会输出带符号但标错位置的写法。

后者更糟，因为它看起来是完整的，人眼扫过去不容易察觉。

越南语这一侧本来就有一套两轨策略：越南语SEO要接的是两拨人，一半打声调符号，另一半从来不打 (https://zhangwenbao.com/vietnamese-seo-tone-marks-syllable-spacing-keyword.html)。字幕给你的可能是第三种形态——符号打了但打错了，这一种既接不住带符号的查询，也接不住不带符号的查询。

## 数字、单位与型号会被写成另一种形态

第四样是形态转换，这一类最容易被忽略。

你在视频里念的是十二伏，识别结果可能写成阿拉伯数字加单位，也可能写成词。

型号里的字母数字混排最容易出事，念出来的那一串在文本里可能被拆成几段。

尺寸、容量、功率这些参数词是这个品类用户最常搜的部分。

而它们在文本里到底长什么样，完全由这条链路决定。

这跟本站讲缩略语与型号写法那一篇是同一族：同一个组织在五门语言里有五个缩略语，你的词表收了几个 (https://zhangwenbao.com/minor-language-acronym-initialism-local-forms-inflection.html)。区别是词表那件事你可以主动补，而字幕这一层你连它会选哪种写法都不知道，只能事后查。

## 缺的这几样正好是检索最依赖的那几样

把上面四样并排看，会发现一个很不巧的重合。

句子边界决定段落能不能被整段摘走。

大小写决定专名能不能被识别成实体。

变音符号决定字符串能不能匹配上查询。

数字与型号的写法决定参数类长尾能不能被接住。

这四样恰好就是检索侧最依赖的四样，而它们全部由一个你没有参与的推理过程决定。这不是巧合：它们全都是低频、高信息量的成分，而低频高信息量正是统计模型最容易出错的地方。

## 品牌名和型号在字幕里会变成什么？

## 模型只会输出它词表里有的词

回到开头那个案例，解释一下品牌名为什么一次都没对。

识别模型的输出受限于它的词表和语言模型。

一个它没见过的品牌名，不在词表里，它不可能凭空造出来。

它会做的是选一个发音接近、在这门语言里合理的词填进去。

填进去的那个词语法通顺、拼写正确、上下文说得过去。

这个行为模式跟小语种AI稿里读着最顺的那一段，恰恰是模型顺手编出来的本地规矩 (https://zhangwenbao.com/low-resource-language-ai-hallucination-rate-content-risk.html)那篇讲的是同一件事：模型不允许自己留空，必须给一个确定的输出，而给出来的东西完整、合法、自信。区别是那篇里编出来的是事实，这篇里编出来的是你的品牌名。

## 三种典型的错法

实测下来，品牌名的错法基本就三种。

第一种是整词替换，换成一个发音相近的常见词，这一种最常见也最难发现。

第二种是被拆开，一个品牌名被切成两个短词，各自都是合法的词。

第三种是被同化进上下文，跟前后的词粘成一个更长的词。

三种的共同点是结果读起来都很顺，没有任何一处看起来像识别错误。

顺便说一句，第一种在越南语上尤其高发，因为越南语是音节分写的，几乎每个音节都是一个合法的词，模型永远能找到一个说得通的替换。这跟泰语的标题里找不到一个空格 (https://zhangwenbao.com/thai-seo-no-spaces-word-segmentation-keyword.html)那篇讲的分词困境是反向的：那边是切不开，这边是随便切都对。

## 为什么越是新品牌越容易被听错

这条规律很残酷，但很好理解。

一个品牌名进入模型词表的前提，是它在训练语料里出现得够多。

出现得够多的前提，是它已经在这门语言的公开内容里被大量提及。

而这恰恰是新品牌最缺的东西。

所以最需要靠内容打开市场的品牌，恰恰是这条链路最不认识的品牌。

更别扭的是它有滞后性：等到你的品牌被提及够多、模型也更新过之后，识别才会变准，而那时候你早就不缺这点流量了。这跟做小语种SEO，品牌名叫什么不由你定，由当地用户的输入法定 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)那篇的结论叠在一起就是：品牌名在这门语言里长什么样，用户的输入法说了一半，识别模型说了另一半，都不是你说了算。

## 有没有办法把词喂进去

有，但要看你用的是哪一条链路。

视频平台的自动字幕基本没有这个入口，你只能事后改。

自己跑的识别服务多数支持自定义词表或者提示词，把品牌名、型号、专业术语提前喂进去。

这一步的收益极高：三类关键词的准确率通常能从很难看的水平拉到可接受的水平。

操作成本是准备一份术语表，几十到几百条，一次准备长期复用。

这份术语表跟本地化项目里的不可翻译词清单高度重合，可以直接借过来当种子。小语种内容找母语者审校，一句读着自然不能当成验收通过的判据 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)那篇讲过怎么把不许动的词在稿子里标出来，同一份清单在这里换个用途就是喂给识别的词表。

把词喂进去具体有三档做法，成本差得很远。最轻的一档是在调用时附一段提示文本，把品牌名和术语写进去，改一行参数就行；中间一档是维护一份自定义词表并设置权重，适合术语量大的品类；最重的一档是拿自己的音频做微调，只有在内容量极大且语言足够冷门时才划算。九成场景第一档就够，而多数团队连第一档都没开。

音频这一侧也有几条硬门槛：采样率别低于常见的语音标准，尽量单声道录人声，避免多人同时说话的重叠段。这几条不是精益求精，而是低于门槛之后识别质量会断崖下跌，喂再多术语也救不回来。花几百块换一支麦克风带来的准确率提升，通常大于换一个更贵的识别服务。

## 没有空格的语言，字幕是按什么切行的？

## 切行跟切词是两件事

字幕多了一个别的文本形态没有的约束：它必须按时间切成一行一行。

每一行要在屏幕上停留一两秒，长度受屏幕宽度限制。

切在哪儿由时间轴决定，而时间轴对应的是说话的停顿。

说话的停顿跟句法边界只是大致相关，不是一回事。

于是一句完整的话被切成两三行，每一行都不是完整的语法单位。

这一层损失在英语上也存在，只是英语有空格，切在哪儿至少不会切坏一个词。到了没有空格或者按音节分写的语言，切行有机会把一个词从中间劈开，而劈开之后的两半在文本里是两个独立的字符串。

字幕行长本身也有一套约定：每行的字符数上限和每条字幕的最短显示时长。这套约定按语言不同，汉字、假名这类信息密度高的文字每行放的字符数明显少于拉丁字母，因为读者需要的是同样的阅读时间而不是同样的字符数。自动生成的字幕多数按一个固定字符数切，对信息密度高的语言就会切得过长，读者跟不上。

## 无空格语言与音节分写语言的两种坏法

这两类语言的坏法方向相反，值得分开记。

无空格的语言里，识别结果本身就要靠模型去切词，切错了整行都错。

音节分写的语言里，每个音节之间本来就有空格，切行不会劈开音节，但会把一个多音节词切成两半。

前一种的错误是不可见的，因为切出来的词看起来都是词。

后一种的错误是半可见的，一个词只剩前半截，母语者一眼看得出。

韩语这一侧还有第三种坏法，韩语的空格到底跟着什么走 (https://zhangwenbao.com/korean-seo-spacing-particles-keyword-research.html)那篇讲过词与助词的分写规则，识别结果里助词的分写经常跟规范不一致，而站内搜索按字符串匹配时这一点直接决定能不能命中。

## 字幕文件里的时间轴会把句子再切一次

还有一层是文件格式带来的。

字幕文件的基本单位是一个时间段加一段文字。

抓取方读这份文件时，拿到的是一段一段的碎片。

如果直接把碎片拼起来，句子边界的信息就彻底没有了。

如果按碎片处理，每个碎片都太短，短到不足以构成一个可被摘走的段落。

正解是不要指望字幕文件本身承担正文的功能，而是另外准备一份完整的、有标点有分段的转录文本放在页面上。这一步在视频优化里早有共识，本篇要补的是：那份转录文本不能直接从自动字幕导出来改改就用，它需要按正常文章的标准重新组织，否则前面讲的四样缺失会原样搬到页面正文里。

字幕文件格式本身也值得挑一下。老的那种格式只有序号、时间和文本三样，新的那种可以带语言标记、样式和元数据，也支持在文件头写注释。挂在页面上的字幕轨应该用后者，并且把语言标记填对，因为这个标记是抓取方判断这一轨属于哪门语言的直接依据。

挂轨的时候还有一个字段必须填对：轨道元素上的语言属性。多语言字幕轨如果全部不填或者填成同一个值，抓取方就无法区分哪一轨是哪门语言，几轨内容会被当成同一门语言的重复文本处理。这个字段填一次的成本是几秒钟，漏了的代价是整批多语言字幕白挂。

视频章节标记跟字幕是两份独立的数据，但它们该对齐。章节标题是你自己写的，可以写得规范、带核心词；字幕是机器生成的，质量不可控。如果章节划分跟内容的实际结构对得上，抓取方就多了一条可靠的结构线索，可以在字幕不可靠时兜住一部分。这是少数几处你能主动补强这条链路的位置。

## 自动翻译的字幕，是不是又走了一次中转？

## 翻译字幕的输入是识别结果不是原声

视频平台普遍提供把字幕自动翻译成其它语言的功能，这里有个链路细节要说清楚。

翻译的输入不是原始音频，是上一步的识别结果。

也就是说，识别错的地方会被原样翻译过去。

被听成别的词的品牌名，会被当成那个词认真翻译一遍。

缺标点的长串文本，翻译时还要先自己猜一遍句子边界。

官方帮助里对视频与字幕的翻译 (https://support.google.com/youtube/answer/100077)写得很清楚，这条链的顺序不难查，只是多数人默认它是从声音直接到目标语言的。

## 两次损失是怎么叠加的

把两步的损失叠起来看，形状很有意思。

第一步的损失是随机的：低频词被换成高频词。

第二步的损失是系统的：翻译会按目标语言的规则重新组织。

两步叠加之后，错误不但保留了，还被翻译的流畅度掩盖了。

一个被听错的品牌名，翻译成目标语言之后变成一个更普通的词，读起来更顺了。

这是整条链上最坏的一个性质：每多经过一道工序，错误就变得更不像错误。到了第二步的输出上，已经没有任何线索能提示读者这里原本是个专名。

## 这跟稿件走英语中转是同一条链

本站讲过内容先做成英语再分发的那条链路。

稿子翻成波兰语之前先在英语站停了一趟，卸下去的那些东西没人清点 (https://zhangwenbao.com/minor-language-pivot-english-relay-grammar-loss.html)讲的是语法维度在中转站被卸掉。

字幕这条链的中转站换成了识别这一步，卸掉的东西也换了：不是语法维度，是低频词。

两者的结构完全一样：一次有损压缩接一次必须给出确定值的解压。

两者的检查工具也同样失效，回译在那边帮倒忙，在这边也一样——把翻译字幕再翻回原语言，得到的是一个跟识别结果高度一致的版本。

要判断这条链有没有出问题，唯一可靠的参照物是原始音频，不是链上任何一个中间产物。这条判据很硬，也很不方便，因为它意味着检查这件事必须有人真的把视频听一遍。

## 什么时候宁可不给翻译字幕

结论跟平台自动翻译商品页那件事是同一个形状。

纯演示、口播少、术语少的视频可以开，翻错的面小。

含操作步骤、安全提示、参数说明的视频应该关，或者只给人工校对过的语言。

涉及安装、用电、承重这类会出事的内容必须关。

判据还是那一句：这段话里有没有一个词，翻错了会让用户做错事。

汽车用品这个品类里这条判据咬得特别紧，因为安装类视频几乎每一支都有一句关于扭矩、电压或者固定方式的话，而那一句恰好是全片信息密度最高、也最容易被听错的一句。

## 错的字幕进了索引，会在哪几个地方结算？

## 字幕是可索引文本，这一点常被低估

先确认这件事有没有实际后果。

字幕文件是文本，挂在页面上的字幕轨可以被抓取方读到。

视频平台内部的搜索会把字幕纳入匹配。

页面上的转录文本更是普通正文，跟别的段落没有区别。

所以这批文字不是只给听障用户看的辅助内容，它是一份实实在在的检索资产。

结构化数据里也有专门的字段承载它，transcript属性 (https://schema.org/transcript)就是标记这份文本的位置。既然是资产，它错了就有代价，而不只是不好看。

## 错字幕对页面语言证据的影响

第一笔代价落在语言判定上。

识别结果里混着被替换成别的词的专名、缺变音符号的写法、来源不明的英文词。

这批文本如果占了页面文本的一大块，判定的稳定性会下降。

而视频页往往正文很短，字幕反而是最长的一块文本。

这就跟站上字最少的那几类页面最赚钱，也最容易被机器认成另一门语言 (https://zhangwenbao.com/minor-language-page-language-detection-misidentification-short-text.html)那篇接上了。

要补的是一个新情形：那篇讲的是页面上文字太少所以证据不足，这里是文字不少但质量不可控，证据的方向可能被带偏。两种情形要用不同的办法救，前者靠补文字，后者靠换文字来源。

视频平台自己也要判定一支视频是什么语言，判定依据同样包括音频和字幕。如果自动字幕质量差，平台可能把这支视频归到错的语言下，后果是它在目标语言的推荐和搜索里出现得更少。这一层跟页面侧的语言判定是两套独立的系统，但踩的是同一个坑，而且平台侧你连排查工具都没有。

## 被摘去当答案的那一段可能是错的那一段

第二笔代价更直接。

段落级的抽取会从页面上挑一段最贴合问题的文字。

视频页上信息密度最高的那几段，往往正是讲操作步骤和参数的那几段。

而那几段恰好是数字、型号、专名最密集的地方，也就是识别最容易出错的地方。

被摘走的那一段一旦带着错的参数，后果不是流量损失，是用户按着错的数字去操作。

这一条把问题的性质从检索问题变成了责任问题。AI用你的语言把答案说得挺顺，底下挂的来源却是一水儿的英文页面 (https://zhangwenbao.com/ai-search-language-bias-low-resource-citation-source-audit.html)那篇担心的是本地语言内容不被引用，这里的担心反过来了：被引用了，可引用的是错的那一版。

## 报表上会表现成什么样

最后说一下这件事在数据上的样子，因为它很难被归因。

视频页的展现量不一定低，因为它靠标题和页面正文也能拿到展现。

点击率可能正常，因为标题是你自己写的。

真正低的是那些应该由字幕内容承接的长尾查询，而它们分散在几百个词上，单个都看不出来。

汇总起来看的话，表现为这批页面的查询覆盖面明显窄于同类页面。

所以这件事的正确检查方式不是看整体指标，是拿一批视频页的查询词列表跟一批图文页做对比，看两边的查询词数量级差多少。差距超过一个数量级，基本可以确定字幕这一层没接住东西。

做这个对比时有个口径要统一：只比自然搜索带来的查询词，不要把站内搜索和推荐流量混进去。另外样本量要够，每边至少二十个页面，因为单个视频页的查询词数量波动本来就大。比出来的比值如果视频页只有图文页的十分之一以下，基本可以断定字幕这一层没在工作，而不是视频这种形态天生查询词就少。

## 哪些语言必须人工校，这条线怎么划？

## 三档划分：能用、要校、别用

给一套可以直接拿去开会的分档。

第一档能用：公开评测里错误率个位数、你自测的三类关键词准确率也不错的语言，自动字幕可以直接用，抽检即可。

第二档要校：错误率十几到二十几的语言，自动字幕当初稿，必须人工过一遍。

第三档别用：错误率更高的语言，自动字幕的修改成本高于重新听写，直接找人做转录更划算。

分档的依据要用你自测的那三个数，而不是公开评测的总分。

因为公开评测测的是通用领域的朗读语音，跟你的讲解视频在语速、口音、术语密度上都不一样。通用评测只用来定一个大致的档位，最终落在哪一档要靠自己那五分钟的样本。

还有一个变量会让一门语言在这三档之间移动：内容里的专有名词密度。同一门语言，讲品牌故事的视频可能落在第一档，讲型号参数的视频要掉到第二档甚至第三档。所以分档的单位不该是语言，而该是语言加内容类型的组合，这也是下一节要把两个维度交叉起来的原因。

## 按内容类型再切一刀

同一门语言里，不同类型的视频也该分开处理。

品牌宣传片、开箱视频这类，口播少、信息密度低，错了代价小。

安装教程、参数讲解、故障排查这类，每一句都可能带一个不能错的数字。

客户证言类比较特殊，它的价值在真实感，而识别错误会直接毁掉真实感。

两个维度交叉之后得到一张表，语言在一个轴，内容类型在另一个轴。

这张表比单纯按语言划线实用得多，因为它能让预算落在真正要紧的格子上，而不是把一门语言的所有视频一刀切地全校或者全不校。

直播和实时字幕要单独归一档。实时场景下模型只能看到已经说过的部分，没有全句上下文可用，准确率会比事后转录明显低。如果直播回放会被留档并且用来做长期内容，正确做法是回放之后重新跑一次离线转录，用离线的那一份替换掉实时生成的那一份，而不是把实时字幕原样存下来。

## 校对的成本怎么估

给几个可以拿去做预算的经验值。

校对一分钟视频的字幕，熟练的母语者大约要花三到五分钟。

从零听写一分钟视频，通常要六到十分钟。

所以自动字幕只有在错误率低到修改量小于三分之一的时候才真的省时间。

这也是第三档存在的理由：错误率高过某个点之后，改比重写更慢，因为改的人要不断在两份文本之间来回比对。

把这笔账算给决策者听，比讲错误率有效得多。多数人对百分之三十这个数没有感觉，但对每支视频多花两小时这个数很敏感。

## 校对该校哪几处，哪些可以放过

校对也要有优先级，不能逐字抠。

必须校的第一类：品牌名、型号、参数数字，这三类错了直接产生业务后果。

必须校的第二类：句末标点与分段，因为它决定这段文本能不能被整段摘走。

应该校的第三类：变音符号与声调记号，它决定字符串能不能匹配。

可以放过的：语气词、口头禅、重复的词、轻微的语序偏差，这些不影响检索也不影响理解。

把这份优先级写进给校对方的简报里，能把校对时间压掉三分之一以上。多数校对人员在没有指引的情况下会平均用力，把大量时间花在那些一点关系都没有的语气词上。

## 一份两天能跑完的字幕语言体检

## 第一天：抽样与错误分类

上午挑样本，每门语言挑三支视频，覆盖不同的内容类型。

把这几支视频的自动字幕全文导出来，纯文本形态，不要带时间轴。

下午请母语者读一遍，只做一件事：把错的地方圈出来并归类。

归类用前面那四类，专名、标点、变音符号、数字与型号。

统计每一类的错误次数，以及这几类词在全文里的总出现次数。

做完这一步你会拿到一张按语言、按错误类型的分布表，而这张表就是后面所有决策的依据。它比任何供应商的宣传材料都可靠，因为它测的是你自己的内容。

抽样时顺手记一下每支视频的音频条件：有没有背景音乐、录音设备、说话人数量、语速。做完分类会发现错误率跟这几个变量的相关性很强，有时候比语言本身的相关性还强。这份对照能直接指导下一批视频的拍摄规范，而拍摄规范的改动是一次性成本，比每支视频都请人校对便宜得多。

分类时建议把错误按位置也标一遍：出现在开头三十秒的错误比出现在结尾的更值钱，因为开头那段被摘去当摘要的概率最高，也是用户判断要不要看下去的那一段。同样数量的错误，集中在开头和散在中段，对结果的影响不是一个量级。

## 第二天：术语表与优先级

上午整理术语表，把所有被听错的专名、型号、术语收进去。

顺手把还没被念错但迟早会被念错的核心词也加进去，一并喂给识别服务。

下午定优先级：按视频的实际流量和内容类型排序，决定哪一批先人工校。

同时把页面上那份转录文本的处理方式定下来，是重新组织还是直接删掉。

直接删掉在有些情况下是对的：一份错误密集的转录文本对页面的伤害大于它带来的收益，尤其在语言判定这一层。这句话跟通行的建议正好相反，通行建议是转录文本一定要放，那条建议成立的前提是转录文本是准的。

如果决定保留页面上的转录文本，组织方式要按文章的标准来，不能按字幕的标准。具体做法是按视频章节分段，每段加一个小标题，把口语里的重复和语气词删掉，把参数和型号按规范写法统一一遍。这样处理过的转录文本才是一篇可读的正文，而不是一段被时间轴切碎的文字流。

处理时有一条要守住：别为了可读性把口播里的具体数字改成约数，也别把用户实际会搜的口语说法改成书面术语。转录文本最大的价值恰恰在于它保留了真人讲话时用的那些说法，而那些说法往往就是用户在搜索框里打的词。

## 上线之后盯哪几个数

体检做完，日常跟踪盯三个数就够。

第一个是视频页的查询词数量，跟同期图文页做比值，这个比值稳定下来之后就是基线。

第二个是品牌名相关查询在视频页上的展现，喂了术语表之后这个数应该有明显变化。

第三个是新增视频的抽检合格率，每月抽两支，防止链路悄悄换版本。

第三个数最容易被忽略，可它是唯一能发现供应商换了模型或者平台改了默认设置的手段。这类变更通常不会通知你，而它对小语种的影响往往比对大语种大得多。

还有一件事值得排进季度节奏：把当初那份术语表拿出来重新跑一遍抽检。品牌名和型号会变，新品会带来新的术语，而识别链路那一侧也在更新。术语表如果三年没动过，它保护的是三年前那批词。一次复核半小时，把新品词补进去，比事后逐支视频改字幕便宜得多。

## 哪些归视频那一层，本篇交出去

## 交给视频与前端那一侧

有一整块内容跟本篇挨着，但不归语言层。

视频放自托管还是放平台、结构化数据怎么标、缩略图怎么选、关键时刻怎么配，这些是视频优化本身的功课。

字幕轨怎么挂、用哪种格式、多语言字幕怎么组织，这些是前端实现问题，标准写得很清楚。

视频SEO在AI搜索时代怎么做 (https://zhangwenbao.com/video-seo-2026-main-content-ai-citation.html)把这一层讲透了，本篇不重复；格式细节看WebVTT规范 (https://w3c.github.io/webvtt/)与track元素文档 (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/track)就够。

本篇只处理一件事：当那段话是用一门不是英语的语言说出来的时候，从声音到文本这一步会额外丢掉什么。把这条线划清楚的好处是，视频那一层的改动多数是一次性的配置工作，而语言这一层是持续的内容工作，两者的排期方式完全不同。

## 交给内容与检索那一侧

反过来也有几件事不该指望字幕解决。

视频页的正文该写什么、标题怎么起、跟商品页怎么互链，这是内容侧的活儿。

术语表里该收哪些词、用哪个形态，这跟关键词表是同一份功课，只是用途不同。

界面上那些没被抽出来的英文按钮是另一条线，翻译报价单上那四万字里，页面上真正被人读的那几十个词一个都没有 (https://zhangwenbao.com/minor-language-hardcoded-ui-strings-pseudo-localization.html)那篇讲的是页面文本的另一半缺口。

平台那一侧的商品文案又是另一套规则，平台给每个卖家的搜索词字段一样长，可日语卖家能塞进去的词只有英语的三分之一 (https://zhangwenbao.com/minor-language-marketplace-listing-fields-tokenization.html)算过那笔字节账。

三条线加起来才是一个小语种站完整的文本供给：写出来的、填出来的、听出来的。多数团队在前两条上投了九成的精力，而第三条往往一分钱都没投过，尽管它的产出正在被同一套检索系统读。

最后补一条排期上的经验：这条供给线的投入产出比在内容量上有个拐点。视频数量少的时候，逐支人工校对最省事；数量上去之后，喂术语表加抽检的组合才划算；再往上，才值得考虑把整条识别链路换成自己可控的服务。多数团队卡在第一档不动，一直用人工校对硬扛，直到视频数量涨到没人愿意校为止。

## 常见问题解答

## 我们的视频只传到视频平台，没放在自己站上，还需要管字幕吗？

需要，而且理由不只是平台内部的搜索。视频平台的字幕会被平台自己的推荐与搜索使用，也会成为外部检索理解这支视频的主要依据。更实际的一点是：平台上那支视频的标题、描述和字幕，在很多品类里是用户搜品牌名时看到的第一批结果之一。字幕里的品牌名如果一次都没对，等于放弃了这个入口。至于要不要同时在自己站上放一份转录文本，那要看那份文本的质量，错误密集的话不放反而更好。

## 公开评测里的错误率数字，能直接拿来做决策吗？

只能用来定一个大致的档位，不能当结论。原因有三层：公开评测多数用的是朗读语音，语速稳定、口音标准、几乎没有专业术语，跟真实的讲解视频差得远；不同评测的口径不一样，词错误率和字错误率不能直接比；而且模型在更新，一份两年前的表跟现在的实际表现可能差不少。正确的用法是拿它排出一个语言的相对顺序，然后用你自己那五分钟的样本去定最终的档位。

## 把术语表喂给识别服务，具体能提升多少？

看词的性质。完全没在训练数据里出现过的生造品牌名，提升最明显，从基本听不对到基本能对。跟常见词发音接近的品牌名提升次之，因为模型仍然会在两个候选之间摇摆。型号这类字母数字混排的串提升有限，因为它的问题不在词表而在切分方式。所以喂词表不是万能的，它主要救的是第一类。第二类还要靠在视频里念得慢一点、清楚一点，这是拍摄环节能解决的事。

## 能不能干脆先写好讲稿，直接拿讲稿当字幕？

这是最省事也最靠谱的一条路，前提是拍摄时确实按稿念。实际操作中主播总会即兴发挥，讲稿和实际内容会有偏差，字幕对不上口型比字幕有错更影响观感。折中办法是拍完之后拿讲稿去跟自动字幕做对齐，只修改偏差的部分，这比从零校对快得多。这条路对小语种特别划算，因为它把最贵的那一步——听写——整个跳过了。

## 越南语这类带声调的语言，字幕的声调符号该怎么处理？

页面上呈现的那份必须带全声调符号，这是正确性和可读性的底线，缺了母语者一眼看得出。匹配这一侧要两轨都覆盖，因为很大一部分用户在搜索时不打声调符号。具体做法是页面文本用规范写法，站内搜索的同义词表把不带符号的写法映射过去。要特别小心的是符号标错位置的情形，它比不标符号更糟，因为它看起来是完整的，人工抽检时很容易漏过去。

## 自动字幕的错误，会不会被判成低质量内容？

直接因为字幕错被判低质的情况不常见，真正的代价在别处：这批文本接不住它本该接住的长尾查询，可能把页面的语言判定带偏，被摘去当答案时可能带着错的参数。三笔账里最该担心的是第三笔，因为它影响的不是排名而是用户会不会按着错的数字去操作。所以判断要不要投入校对，应该看内容类型而不是看会不会被降权。

## 这件事跟我们已经在做的多语言内容工程是什么关系？

是同一件事的第三条供给线。一个小语种站的文本来源一共三类：写出来的正文、填出来的商品数据与界面文案、听出来的视频文本。三类都要经过同一套检索系统，可多数团队只在前两类上有流程，第三类连负责人都没有。补这条线的成本其实不高——一份术语表加一次抽样体检就能覆盖大半，难的是先承认它是一条独立的供给线，而不是视频制作的一个附属步骤。

## 权威参考资料



## 同一份波兰语词表，在你和同事的两台电脑上打开是两份不同的数据

- URL：https://zhangwenbao.com/minor-language-keyword-table-spreadsheet-corruption.html
- 分类：小语种SEO
- 发布：2026-07-23  |  更新：2026-07-30
- 摘要：分隔符和编码都不写在文件里，表格软件按本机地区设置猜。讲清变音字母为什么保存一次就再也救不回来、自动更正会改掉哪些词、小语种为什么最难被发现。
- 关键词：关键词研究,技术SEO,多语言SEO,小语种SEO

> **TLDR**：摘要：一份波兰语关键词表从数据库导出、发给本地顾问、改完再导回来，中间经过的每台电脑都会按自己的地区设置重新解释它一次。逗号分隔文件里没有一处写着自己是逗号分隔的，编码也不自带声明，于是同一份文件在德国同事的机器上会被切成不同的列数，变音字母会被换成问号，型号会被识别成科学计数法。这些改动全部发生在数据库之外，而那段路上没有任何日志。更麻烦的是小语种恰好落在最难发现的那一档：坏掉的只有一小部分字符，坏了之后看着仍像正常的词。

> 摘要：一份波兰语关键词表从数据库导出、发给本地顾问、改完再导回来，中间经过的每台电脑都会按自己的地区设置重新解释它一次。逗号分隔文件里没有一处写着自己是逗号分隔的，编码也不自带声明，于是同一份文件在德国同事的机器上会被切成不同的列数，变音字母会被换成问号，型号会被识别成科学计数法。这些改动全部发生在数据库之外，而那段路上没有任何日志。更麻烦的是小语种恰好落在最难发现的那一档：坏掉的只有一小部分字符，坏了之后看着仍像正常的词。

## 同一份波兰语词表，两台电脑打开连列数都不一样

## 一个健康器械客户的波兰语词表，交出去一轮就散了

有个客户做健康器械，电子血压计、体脂秤、颈椎牵引器、筋膜枪这几条线。

德国市场先做的，波兰是第二个市场，词表由本地顾问补。

流程看着很正常：从后台导出一份表格，发给顾问，顾问填完发回来，技术导进系统。

一轮走完，波兰站上线，问题在两周后才被发现。

筛选器里出现了几个谁也不认识的取值，商品标题里有两个词中间多了半个方块，还有一个型号变成了一串带加号的数字。

顾问那边很委屈，说他只填了空白列，别的一个字没动。事后复盘证明他说的是实话，那几处损坏没有任何一个是人改出来的。

这条流程在德国市场跑过一轮没出事，所以没人怀疑它。

德语词表里带变音符号的词比例低得多，而且那位德国顾问的电脑地区设置跟导出端恰好对得上，两个巧合叠在一起，让这条链路看上去是安全的。

顺带说一句，波兰这一轮之所以出事，还有一个流程原因：德国那份词表是内部同事填的，波兰这份是外部顾问填的，链路多了一段，而没人重新评估过风险。

## 谁也没改过内容，可两边的文件确实不同

把两份文件放进比对工具，差异一目了然。

发出去的那份是十二列，收回来的那份被切成了九列。

发出去时写着一个波兰语词，收回来变成了同一个词少了一个字母，那个位置换成了问号。

发出去时是一个横杠连接的区间，收回来是一个日期。

三处变化，三种成因，没有一处经过人的决定，全部是软件在打开和保存这两个动作里自己做的。

还有一处差异当时被忽略了：行序也变了。

顾问按波兰语的字母顺序排了一次，而波兰语的排序规则跟系统默认不一样，于是回来的文件行序整个错开，任何按行比对的工具都会报出满屏差异，反而把真正的三处损坏淹掉了。

比对工具本身也要选对：按字符比对的工具能标出问号那一处，按行比对的工具只会告诉你这一行变了。

## 三处损坏，三种成因，全都发生在数据库之外

先把结论摆前面，后面几节逐条拆。

列数变化来自分隔符，因为这类文件里没有一处声明自己用什么符号分列。

问号来自编码，因为文本文件不自带编码信息，软件只能猜。

日期来自类型识别，因为表格软件会主动判断一个格子里的东西像什么。

这三件事有一个共同点：它们都不在你的系统里发生，都发生在别人的电脑上，而你连那台电脑装的是什么语言版本都不知道。

第四处成因也常见，只是这次没撞上：文件在压缩传输时文件名被转码，收到的附件名变成一串问号。

文件名不是内容，损坏了不影响数据，但它会让人误以为文件本身坏了，于是干脆重新建一个，把原始那份丢掉。

把四种成因排个序，按不可逆程度从高到低是：编码损坏、自动更正改词、类型识别改值、分列错位，最后一种至少还能靠原始文件重来。

## 数据库有日志，页面有版本，唯独这段路没有记录

这是这类问题最难缠的地方。

数据库改一条记录，有操作日志。

页面改一段文案，内容库里有版本。

而一份文件在别人电脑上被打开又保存，什么都不会留下。

你手上只有改前和改后两份文件，中间发生了什么只能靠推理，而顾问本人多半也不知道，因为对他来说他只是双击、填空、按了保存。

能留下的痕迹只有一处：文件的修改时间。

而这一处恰好什么也说明不了，因为无论对方做了什么，只要按了保存，修改时间都会更新。

所以这类事故的复盘几乎都要靠重演，而不是靠查记录，重演的成本又高，于是多数团队复盘到一半就放弃了。

顺带把这一篇跟前两篇的关系说清楚：讲合规弹窗那段字不在你的翻译队列里 (https://zhangwenbao.com/minor-language-consent-banner-language.html)和讲评论的语言不由你决定 (https://zhangwenbao.com/minor-language-user-review-language.html)的那两篇，说的都是页面上不由你产出的文字；这一篇正相反，数据从头到尾都是你自己的，它坏在运输途中。

## 为什么同一份文件在不同电脑上会变成不同的数据？

## 逗号分隔文件里，没有一处写着自己是逗号分隔的

这类文件的格式规范其实很短，核心只有几条：一行一条记录，字段之间用逗号，字段里含逗号时用引号包起来。

规范里没有任何机制让文件自己说明用了哪个分隔符。

换句话说，分隔符是约定，不是声明。

只要读的人跟写的人约定不一致，同一份字节就会被切成不同的形状。

这跟本站讲Windows-1251时代的西里尔页面被抓回去的是一串认不出的拉丁字母 (https://zhangwenbao.com/cyrillic-encoding-legacy-windows1251-utf8-indexing-cost.html)那一篇的机制是同构的：那一篇讲的是同一串字节被按不同的编码解读，这一篇讲的是同一行文本被按不同的分隔符切开，都是缺少自描述带来的歧义。

规范里还有一条常被忽略：字段内部允许出现换行符，只要整个字段被引号包住。

这意味着一段带换行的商品描述在结构上是合法的，可一旦引号在中途被处理坏，后面所有行的边界都会跟着错位。

顺带一提，字段里含分隔符时要用引号包住，而某些导出功能默认不加引号，这等于把定时炸弹写进了文件。

## 表格软件用的是系统地区设置里的列表分隔符

关键在这里：表格软件不问你，它读系统设置。

操作系统的地区设置里有一项叫列表分隔符，表格软件双击打开文本文件时用的就是它。

这一项跟界面语言不是一回事，它跟你选的国家或地区绑定。

所以同一台电脑，把地区从一个国家改到另一个，同一份文件的打开结果就变了。

这条设计其实有它的道理：小数点用逗号的地区，再拿逗号当分列符号就会打架。问题只在于没有人在交付文件时想到过对方的地区设置是什么。

更细一点说，这一项在系统设置里跟着国家或地区走，而不是跟着界面语言走。

所以一位用英语界面但地区设成德国的同事，打开结果跟用德语界面的同事完全一样，这也是为什么按界面语言去猜谁会出问题总是猜不准。

顺带一提，在线协作表格没有这一层，因为它的解析发生在服务端，跟你本地设成哪个地区无关。

## 欧洲多数地区的默认分隔符是分号

具体到数字上，这件事影响面很大。

小数点写成逗号的地区，包括德国、法国、波兰、西班牙、意大利、荷兰、北欧多数国家，列表分隔符默认是分号。

小数点写成句点的地区，包括英美和多数亚洲市场，列表分隔符默认是逗号。

而做欧洲市场的团队，本地顾问、译员、渠道商，绝大多数在第一类地区。

也就是说，你从系统里导出的逗号分隔文件，在这条链上大部分人的电脑里都不是原样打开的，这不是偶发事故，是默认状态。

这条分界跟小数点的写法完全重合，因为它本来就是为了避开冲突而设计的。

记住这条对应关系很有用：凡是把一点五写成一逗号五的地区，它的列表分隔符就是分号。

顺便记住一个反查方法：想知道对方的分隔符是什么，让他在软件里随便存一个两列的文件发回来看看就行。

## 于是同一份文件在两地打开，列数不同

把机制走一遍就明白那九列是怎么来的。

顾问的电脑按分号切，可文件里没有分号。

于是整行被当成一个格子塞进第一列。

他看到的是一列很长的文本，于是他手动用分列功能重新切了一次。

手动分列时那些本身含逗号的字段就散了，比如一条带逗号的描述被切成两半，列数从此错位。到这一步文件已经彻底变形，而他做的每一步在他看来都是在修复。

更糟的是分列这个动作在他看来是修复，所以他会把修复后的版本存下来发回给你。

于是你收到的不是原始损坏，是一份被人善意加工过的损坏，追查起来比原始损坏难得多。

正确的做法是发现列数不对就退回去要原始文件，而不是自己动手分列，因为分列这一步会把可逆的错误变成不可逆的。

## 编码这一层，为什么小语种的损坏是不可逆的？

## 文本文件不自带编码声明

跟分隔符一样，编码也是约定。

一份文本文件里存的只有字节，没有一处写着这些字节该按哪套规则解释。

网页可以在头部声明编码，数据库有字符集设置，唯独裸的文本文件没有。

唯一算得上线索的是文件开头那几个特殊字节，也就是字节顺序标记。

而这个标记本身就是一件有争议的东西：加了它，某些程序会把它当成内容；不加它，表格软件多半会猜错。本站讲记事本存出来的字节顺序标记怎么让网页白屏 (https://zhangwenbao.com/notepad-edit-saved-code-generate-bom-resulting-web-page-error-white-screen-solution.html)那一篇讲的就是加了之后的麻烦，这一篇要讲的是不加之后的麻烦。

数据库有字符集设置，网页可以在头部声明编码，接口可以在响应头里写明，唯独裸的文本文件什么都没有。

本站讲Windows-1251时代的西里尔页面被抓回去的是一串认不出的拉丁字母 (https://zhangwenbao.com/cyrillic-encoding-legacy-windows1251-utf8-indexing-cost.html)那一篇里讲过没有声明时搜索引擎会怎么猜，表格软件的处境是一样的，只是它猜错之后还会把猜错的结果写回文件。

所以稳妥的做法是在交付说明里把编码写成一句明确的要求，而不是假设对方会用跟你一样的默认值。

## 双击打开的时候，软件只能猜

猜的依据通常是系统的默认代码页。

波兰地区的默认代码页覆盖的是中欧字母，德国地区的覆盖的是西欧字母。

两者对同一个字节的解释并不一样。

所以一份用通用编码存的波兰语词表，在德国同事的机器上双击打开，那些波兰语特有的字母就落在了西欧代码页覆盖不到的位置。

软件不会因此报错，它会尽力显示：能对上的照常显示，对不上的换成问号或者一个方块。整份文件看起来只是有几个字变丑了，而不是打不开。

顺带说一句，猜的依据在不同操作系统上也不同。

同一份文件在苹果系统的表格软件里打开，行为跟视窗系统并不一致，所以顾问用什么电脑也是一个变量，而这个变量从来没人在交付说明里问过。

所以交付说明里最好直接写清楚用什么软件的什么功能打开，而不是笼统写一句用表格软件打开即可。

## 猜错的表现是变音字母变成问号或者方块

举个能直接看懂的例子。

德语里的尺码这个词带一个变音字母和一个特殊的双s字母，猜错编码之后就变成两个问号夹在中间。

波兰语里带斜杠的l、带点的z、带尖音符的s和c，都属于这一类。

匈牙利语的长双撇元音、罗马尼亚语的下逗号字母、土耳其语的无点i，同样如此。

这些字母有个共同点：它们都是这门语言里最常用的那批字母，而不是什么生僻符号。一个波兰语词表里带这几个字母的词，占比通常在三分之一以上。

把这批字母数一遍会更有体感：波兰语有九个带变音符号的字母，捷克语有十五个，匈牙利语有九个，罗马尼亚语有五个。

这些字母不是装饰，去掉变音符号之后往往就变成了另一个词，本站讲德语SEO最先卡住的不是技术，是德国人管这东西叫另一个词 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)那一篇里已经算过这笔账。

这也是为什么变音字母在这一层比在别处更要紧：它们不是可选的装饰，去掉之后往往就变成了另一个真实存在的词。

## 真正致命的是保存那一步，原始字节从此消失

显示错了还有救，保存错了就没救了。

软件把屏幕上显示的那个问号当成真正的内容写回文件。

原来那几个字节被覆盖成问号的字节。

这时候你手上这份文件里，那个字母的信息已经不存在了，任何工具都恢复不出来。

这一条跟本站讲为了让德语长词在手机上不撑破，前端往标题里塞了个看不见的字符 (https://zhangwenbao.com/minor-language-line-break-soft-hyphen-invisible-character.html)那一篇的区别值得说清楚：那一篇讲的是多出来看不见的东西，能靠清洗解决；这一篇讲的是丢掉了本来有的东西，只能回到源头重新取。前者是脏，后者是缺。

还有一个更隐蔽的版本：字母没有变成问号，而是变成了另一个真实存在的字母。

这在两套代码页有部分重叠时会发生，结果是一个拼写合法但意思完全不同的词，连白名单校验都拦不住它。

白名单能拦住变成问号的那一类，拦不住变成另一个合法字母的那一类，后者只能靠母语者抽检。

## 自动更正会改掉哪些词，为什么专挑外语词下手？

## 型号被识别成科学计数法

表格软件在你输入或者打开内容时会判断类型。

一串数字加一个E加数字，它认为这是科学计数法。

健康器械这类品类的型号里正好经常出现这种形态。

结果是一个型号变成了一串完全不同的数字，而且原样再也拼不回来。

本站讲平台给每个卖家的搜索词字段一样长，可日语卖家能塞进去的词只有英语的三分之一 (https://zhangwenbao.com/minor-language-marketplace-listing-fields-tokenization.html)那一篇里提过型号这一列的敏感性，这里补一条更早发生的：它在进平台之前，在你自己的表格里就已经被改掉了。

同样的道理也适用于另一个方向：一个格子里如果以等号或者加号开头，表格软件会把它当成公式。

而某些语言的词表里确实有以加号开头的规格写法，打开之后它要么变成错误提示，要么变成一个计算结果。

以等号开头还有一个安全上的老问题，很多系统会在导出时给这类字段加前缀来避免它被当成公式，而那个前缀又会进到你的数据里。

## 区间写法被识别成日期

这一条在关键词表里出现频率最高。

一个横杠连接的数字区间，比如尺寸区间、重量区间、适用年龄区间。

软件会把它当成日期，然后显示成某月某日。

官方文档里就直接写着这个行为，还给了绕开的办法：先把单元格设成文本格式，或者在输入前加一个空格或撇号。

厂商自己把它当成一个需要解释的常见问题写进帮助文档，说明这件事有多普遍，而它在多语言词表上的后果比在普通表格里严重，因为词表里的每一行最后都会变成页面上的字。

日期识别还有一层地区差异：同一个数字组合，在一个地区被读成三月五日，在另一个地区被读成五月三日。

所以就算你发现了这个问题，回头去看那份文件也未必能推出原来写的是什么。

区间这类写法在健康器械品类里特别多，适用体重、适用年龄、袖带周长，几乎每个商品都有一列。

## 前导零被吃掉

第三类是数字开头的零。

软件认为这是一个数，而数的前面不该有零。

邮编、条码、内部编号、一部分型号都会中招。

德国和波兰的邮编都有以零开头的，这一条在做地区词表时几乎必然遇到。

厂商同样为这件事单独写了一篇帮助文档，讲怎么保住前导零和长数字，可默认行为并没有因此改变。

条码这一列尤其要小心，因为它既有前导零又足够长，会同时踩中两个坑。

而条码一旦错了，商品在平台侧的匹配会直接断掉，本站讲平台给每个卖家的搜索词字段一样长，可日语卖家能塞进去的词只有英语的三分之一 (https://zhangwenbao.com/minor-language-marketplace-listing-fields-tokenization.html)那一篇里说过，这一列没有容错空间。

检查条码这一列最省事的办法是看长度是否整齐，一整列里突然出现几个短一截的，多半就是被吃了前导零。

## 拼写自动更正会把外语词改成本地词

最后这一类最隐蔽，因为它改完之后仍然是一个正常的词。

自动更正的词库跟软件的界面语言绑定。

一位用德语界面的同事打开一份波兰语词表，某些波兰语词会被更正成形近的德语词。

这跟本站讲转成小写这一步到了土耳其语站会把词改成另一个词 (https://zhangwenbao.com/minor-language-case-folding-lowercase-turkish-dotless-i.html)那一篇里的机制是一族：那一篇讲的是同一门语言里的规则在别处不成立，这里是另一门语言的规则被套到了你的词上。

它的可怕之处在于结果完全合法：改出来的是一个真实存在、拼写正确的词，任何校验工具都不会报错，只有母语者读到时会觉得莫名其妙。

还有一类是自动更正的自定义词条：很多人的软件里存着自己加过的更正规则，那是完全个人化的，谁也不知道对方存了什么。

这意味着同一份文件交给两位顾问，回来的结果可能不一样，而原因藏在他们各自的软件设置里。

个人化的更正规则还有个特点：它跟着账号走，换台电脑登录同一个账号，规则也跟着过去。

## 这些损坏为什么在中文和英文词表上不明显？

## 英文词表没有变音字母，编码猜错也看不出来

先说英文。

基本拉丁字母在几乎所有编码里的字节都一样。

所以一份纯英文词表，无论按哪套代码页打开，显示结果都一样。

编码这一整类问题，在英文场景下几乎不存在。

这也解释了为什么行业里那些讲表格数据处理的文章几乎不提这一层，它们的默认读者处理的是英文和数字。

顺带补一句：英文场景下真正会出问题的是撇号和长破折号这类排版符号，而它们通常只影响显示，不影响匹配。

所以英文场景下的经验拿到这里通常不适用，那些经验的默认前提是字符本身不会坏。

## 中文词表猜错是全篇乱码，一眼就发现

再说中文。

中文字符全部落在多字节区间，猜错编码之后是整篇的乱码。

没人会把一屏乱码保存下来接着用。

损坏在第一秒就被发现了，也就不会流到下游。

所以中文场景下这件事的表现形式是打不开，而打不开是一种很好的失败，它至少诚实。

这种失败方式反而是最省钱的，因为它把损失控制在了发现成本上，而不是修复成本上。

本站讲那页规格书在屏幕上是好好的泰语，机器复制走的是另一串字符 (https://zhangwenbao.com/minor-language-pdf-text-layer-extraction-failure.html)那一篇里说过同一句话：读到垃圾比读不到更糟，而打不开至少是诚实的。

也正因为如此，遇到整篇乱码时最该做的是原地停下，而不是想办法把它显示出来。

## 小语种正好落在中间：只坏一小部分，且看着像正常字符

关键差别在这里。

一份波兰语或者德语词表，猜错编码之后大部分内容是正常的。

只有那些带变音符号的字母出问题，而且变成的是问号或者方块这类看着像内容的东西。

文件能打开、能编辑、能保存、能导入，一路畅通。

这跟本站讲那页规格书在屏幕上是好好的泰语，机器复制走的是另一串字符 (https://zhangwenbao.com/minor-language-pdf-text-layer-extraction-failure.html)那一篇里的第三类情形是同一种性质：人这一侧看着完好，机器那一侧已经错了，而正因为它看着完好，所以没有任何一个环节会停下来。

占比这个数值得实测一次：把你的波兰语词表跑一遍，数出带变音符号的词占几成。

多数团队跑完会吃一惊，因为这个比例比凭印象估的高，而它直接等于编码损坏时的受影响面。

跑完这个数还有一个用处：它就是后面那条非拉丁字符计数护栏的基准值。

## 坏得越轻，越难被发现

把三种情况排成一条线，规律就清楚了。

全坏，立刻发现，损失最小。

不坏，无事发生。

坏一点点，能通过所有检查，最后在页面上以怪字符的形式出现在用户眼前。

小语种词表长期处在第三档，这也是为什么这个坑在英文和中文资料里都没人认真写过：写资料的人所在的那两个场景，恰好一个不会坏，一个坏得太明显。

所以这一类问题的正确投入方向不是修复，是把发现成本降下来，让它尽早暴露。

四条断言的意义就在这里：它们把第三档人为地变成了第一档。

换句话说，这类问题的正确投资是买保险而不是买修复工具，而四条断言就是最便宜的那份保险。

## 一条词表从数据库走到页面，中间经过几双手？

## 典型的六段路径

把实际链路画出来，多数团队是这样的。

第一段，从系统后台导出一份表格。

第二段，发给本地顾问或者译员。

第三段，对方在自己的电脑上打开、填写、保存。

第四段，回传给你，中间可能经过一次转发或者压缩。第五段，内部有人合并、去重、调整列序。第六段，导入系统。六段里有四段发生在你看不见的地方。

还有两段容易被忘：第七段是有人把词表复制粘贴进邮件正文或者聊天窗口，第八段是有人截图给别人看然后对方照着重打一遍。

这两段听着离谱，但在跨时区协作里相当常见，而它们的损坏率是百分之百。

这两段还有一个共同点：它们都不会留下文件，于是连比对的机会都没有。

## 每一次交接都是一次重新解释

这条链上的每一次打开都不是简单的读取。

它是一次解码加一次类型识别，两个动作都带默认值。

默认值来自那台电脑的地区设置和软件语言。

所以同一份文件走六段路，可能被重新解释四次。

每一次解释都可能引入一处不可逆的改动，而且这些改动会叠加：先被切错列，再被猜错编码，最后被自动更正改掉一个词。

叠加还有一个恶劣的性质：后一次损坏会把前一次损坏的痕迹盖住。

被切错列之后再被猜错编码，你看到的只是最终结果，中间那一步已经无从还原。

排查时的顺序建议倒着来：先确认列结构对不对，再看字符对不对，因为列错位会让字符比对完全失去意义。

## 交接方式决定了损坏概率

不同的交接方式风险差别很大。

直接在共享的在线表格里协作，风险最低，因为没有本地打开这一步。

发文件让对方用表格软件打开，风险最高。

用专门的本地化工具走标准双语格式，风险居中，坏的是另一类东西。

把风险最高的那一段找出来通常很快，看一眼谁的交付物是带表格后缀的附件就知道了。

还有一种交接方式风险很高却常被当成安全的：把表格贴进文档或者演示文稿里传阅。

那一步会把数据变成排版对象，格式全丢，回来时只能人工重打。

判断一个交接方式安不安全有个简单标准：中途有没有一次本地打开，有就是高风险。

## 谁的电脑决定了这份文件长什么样

这句话是本文的题眼。

同一份文件，在你的电脑上是十二列，在顾问的电脑上是九列。

不是文件变了，是解释规则变了，而解释规则跟着人走。

所以这份数据的最终形态，取决于最后一个打开它的人把系统地区设成了什么。

这是一件挺荒谬的事：你的波兰站上那几个词长什么样，由一台你从没见过的电脑的地区设置决定，而那台电脑的主人对此毫不知情。

所以正确的问法不是这份文件对不对，而是这份文件最后是谁保存的、他的电脑设成了哪个地区。

这两个问题在交付说明里各占一行，就能把大部分事故挡在外面。

把这两个问题写进交付说明还有一个副作用：对方会因此意识到这件事是有讲究的，光这一点就能减少一半事故。

## 损坏之后会在哪里显形，为什么总是很晚才被发现？

## 页面上：属性值和筛选器里的怪字符

最直接的显形是肉眼可见的怪字符。

商品标题里的问号、属性值里的方块、筛选器选项里少了一个字母的词。

但商品页数量太多，抽查看到的概率不高。

筛选器反而更容易暴露，因为它把所有取值列在一起。

本站讲你的色卡上蓝和绿是两格，120门语言的样本里只有30门这么分 (https://zhangwenbao.com/minor-language-color-category-attribute-value.html)那一篇里说过，枚举值是最容易整块出错又最难被察觉的一类数据，编码损坏正好落在这一类上。

筛选器还有个额外的放大效应：它的取值通常做了去重，一个坏掉的取值会以独立选项的形式出现在列表里，跟正确的那个并排。

用户看到的是两个几乎一样的选项，点哪个都只能看到一半商品。

清理这类重复取值时要注意先合并商品关联，直接删掉坏的那个会让一批商品失去属性值。

## 索引侧：这个词从此匹配不上

第二个显形位置在搜索这一头。

一个字母被换成问号的词，跟用户输入的正确写法不是同一个字符串。

站内搜索搜不到，外部搜索也匹配不上。

而这类失败是静默的：搜索返回零结果，没有任何一处会说这是因为库里那个词坏了。

如果这个词恰好是品类词，那么整个品类在这门语言里的入口就等于关掉了一半。

这类零结果在报表上还会被算成需求不存在，进而影响下一轮的选品和内容排期。

本站讲小语种关键词工具返回的那个零是数据缺口不是需求缺口 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)那一篇讲的是另一种成因，但结论一样：先怀疑测量，再怀疑需求。

更隐蔽的是站内搜索的零结果页本身还会被记进日志，于是它在报表里表现为用户搜了一个不存在的词。

## 报表里：这个词的量凭空消失

第三个位置在数据这一头。

报表按词汇聚合，坏掉的词自成一行，量很小。

正确的那一行则少了这部分量。

看报表的人只会觉得这个词表现不好，不会想到它是被拆成了两半。

本站讲网页字体在小语种站变成拖慢首屏的最大一块 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)那一篇提过一个类似现象，那里的原因是词形变化，这里的原因是字符损坏，但在报表上的表现完全一样：一个词的量被分散到了它自己的变体上。

更麻烦的是这两行数据在报表里往往不相邻，因为排序按量级排，坏掉的那一行沉在很后面。

除非你专门去找，否则它就是一行没人看的低量词。

所以按量级排序的报表不适合用来找这类问题，要按词形相似度分组看才找得出来。

## 三个症状归三个团队，没人看见全貌

这是这类问题存活时间长的组织原因。

怪字符归前端或者内容，搜不到归搜索或者产品，量不对归数据分析。

三个人各自记了一笔小问题，各自都不严重到要立项。

把三条线索并排放在一起才能看出它们是同一个根因。

这跟本站讲有些商品在这门语言里根本没有单数，可你的模板第一步就是取单数 (https://zhangwenbao.com/minor-language-plurale-tantum-category-keyword.html)那一篇里的结构一模一样：一个字符层的小错，分裂成三个分属不同团队的症状，于是谁都没动手。

把三个症状合起来还有一个好处：它给了你一个非常具体的自查入口，任何一处出现，另外两处几乎必然也在。

顺着任何一条线索都能把根因挖出来，问题只在于有没有人把三条线索放在一起。

建议把这三条线索做成一张排查卡片贴在流程文档里，比记住原理更容易被用起来。

这三个症状还有一个共同的组织特征：它们分别落在三份不同的周报里，而没有任何一份周报会写这一条只值得记一行。

## 有没有办法在导入之前就拦住？

## 导入前的四条断言

最有效的位置是导入前，因为那是最后一道还能拦住的关口。

第一条，字符集断言：全文不得出现问号和替换字符这两类可疑字符。

第二条，行数断言：导入行数必须等于发出去时的行数。

第三条，字段数断言：每一行的字段数必须一致，且等于表头列数。

第四条，非空断言：关键列不得为空，因为分列错位最常见的表现就是后面几列整列变空。

四条断言里最有价值的是第一条，因为它能抓住不可逆的那一类损坏。

后三条抓的是结构性错误，那类错误至少还能靠重新分列救回来。

第一条断言还有个变体：统计替换字符的出现次数，这个字符在正常内容里几乎不可能出现，一旦出现就是解码失败的铁证。

## 字符集白名单怎么定

第一条断言需要一份白名单，定法很简单。

这门语言的字母表，加上数字、空格和你允许出现的标点。

任何落在白名单外的字符都列出来人工确认。

波兰语要包含带斜杠的l、带点的z这些字母，德语要包含三个变音字母和那个特殊的双s字母。

白名单还有一个附带收益：它能同时抓出全角半角混用、不间断空格、软连字符这些看不见的东西，本站讲为了让德语长词在手机上不撑破，前端往标题里塞了个看不见的字符 (https://zhangwenbao.com/minor-language-line-break-soft-hyphen-invisible-character.html)那一篇里的那批问题在这一步能一并处理掉。

白名单的另一个用法是反向的：用它去扫存量数据，能一次性把历史遗留的损坏全部找出来。

这个动作跑一次的成本很低，而它给出的清单往往比团队预估的长。

扫存量的时候记得连商品属性表一起扫，词表和属性表往往走的是同一条链路，坏也是一起坏的。

## 行数与字段数校验

这两条最便宜，也最容易被跳过。

导出时把行数记在文件名或者一个附带的说明里。

导入时先数一遍，对不上就退回。

字段数用一行命令就能统计，每行有几个分隔符，做个频次分布。

如果分布不是单一值，说明这份文件已经被切坏了，此时任何进一步的处理都只会把错误固化。

还有一条更省事的：把表头单独存一份，导入时先比对表头是否一字不差。

表头一旦被翻译或者被自动更正改过，字段映射会整体错位，而这是最容易在导入阶段被误当成数据问题的一类故障。

表头比对还能顺带发现列序被调换的情况，那是另一种常见的人为改动，且同样不会有任何提示。

## 抽样比对：导出再导入一次，看差异

最后一条是验证流程本身有没有问题。

拿一份不做任何修改的文件，走完整条链路。

发出去，让对方打开、保存、发回来，然后比对。

如果这份没人改过的文件回来之后已经不一样，说明链路本身就在损坏数据。

这个测试半天能做完，而它能一次性回答一个平时靠猜的问题：到底是顾问改坏的，还是链路改坏的。答案通常是后者，而这个答案能省掉很多不必要的互相埋怨。

空跑测试还能顺便测出行序问题：如果回来的行序变了，说明中间有人做过排序，而排序会让后续的比对全部失效。

遇到这种情况，比对要先按主键重新对齐再做，否则看到的差异全是假的。

空跑测试最好每换一位外部合作方就做一次，因为链路的风险是跟着人变的。

## 正确的交付方式长什么样？

## 优先不用表格软件，用工具或脚本

最根本的办法是把表格软件从链路里拿掉。

内部处理用脚本，标准库里的解析器会严格按你指定的分隔符和编码工作，不猜。

批量导入导出用系统自带的功能，或者专门的本地化工具。

需要人协作时用在线协作表格，它没有本地地区设置这一层。

这一条能消掉本文前面讲的大部分损坏，因为那些损坏全部来自本地打开这个动作。

脚本方案还有一个附带好处：它可以在解析时就报错。

字段数不对、编码解不开，程序会直接抛出来，而不是像表格软件那样尽力显示一个看着还行的结果。

脚本方案的另一半价值在于可重复：同样的输入永远得到同样的输出，而人的操作做不到这一点。

## 必须给人看时，怎么让它安全打开

现实里总有人只会用表格软件，那就把打开方式写进交付说明。

第一，不要双击，用数据菜单里的从文本导入功能，那里可以显式选编码和分隔符。

第二，导入时把所有列的类型设成文本，这样类型识别不会动你的数据。

第三，如果对方一定要双击，那就在文件开头加上字节顺序标记，多数表格软件看到它会正确按通用编码打开。

第四，改完之后不要用另存为默认格式，按约定的编码和分隔符另存，或者干脆回传原格式。

第五条也值得写进说明：改完之后先自查一遍带变音符号的字母还在不在，随便挑三五个词看一眼就行。

这一步花不了一分钟，却能让对方在发出去之前自己发现问题。

这四条写成一页纸贴在交付说明的最前面，比写在合同附件第七页管用得多。

## 分隔符与编码要显式声明

还有两个成本极低的技巧。

一是改用制表符分隔，因为制表符不参与任何地区设置，各地打开结果一致。

二是在文件第一行写一句分隔符声明，部分表格软件会识别它并按声明切列。

再配上文件名里带编码和分隔符的标注，接收方一看就知道该怎么打开。

这三招加起来不用十分钟，能解决掉链路上最常见的那两类损坏，而多数团队从来没做过其中任何一条。

制表符方案唯一的代价是字段里不能含制表符，而词表这类数据几乎不可能出现制表符，所以这个代价约等于零。

还有一个细节：制表符分隔的文件后缀最好也跟着改，别再用逗号分隔的后缀，否则接收方还是会按老习惯双击。

## 把词表当代码管，进版本库

最后一条是流程上的升级。

词表是资产，它跟代码一样会被多人修改、会有版本、会需要回溯。

放进版本库之后，每一次改动都有差异记录，谁改的、改了什么一目了然。

真出了问题也能直接回到上一版，而不是去邮箱里翻附件。

本站讲平台给每个卖家的搜索词字段一样长，可日语卖家能塞进去的词只有英语的三分之一 (https://zhangwenbao.com/minor-language-marketplace-listing-fields-tokenization.html)那一篇里提过一个类似的判断：凡是最终会变成页面上文字的数据，都值得按对待代码的标准去管，而词表是其中最典型的一类。

声明行也有兼容性代价：某些解析器会把它当成一行数据。

所以这一招只在明确知道对方用表格软件打开时使用，走脚本的链路上不要加。

还有一个折中：文件名里直接标注编码和分隔符，接收方一眼就知道该怎么打开，成本是零。

## 团队层面怎么让这件事不再复发？

## 交付规范写进合同和工单

把要求写在需求里，比事后检查便宜得多。

给外部顾问的合同附件里加一页交付规范。

内容包括：用什么格式、什么编码、什么分隔符、怎么打开、怎么保存。

再加一条验收条件：回传文件必须通过四条断言。

这一页纸的成本是一次性的，而它把责任边界也划清楚了：链路怎么走是你定的，顾问只负责内容。

版本库对这类数据还有一个特别的好处：文本差异是按行按字符算的，一个字母从正确变成问号会被清清楚楚地标出来。

而这正是表格软件永远给不了你的东西。

进版本库之后还能顺手加一个提交前检查，把四条断言挂上去，不通过就提交不了。

## 三条硬约束

第一条，任何要交给外部的词表，一律用制表符分隔加通用编码，不用逗号。

第二条，任何回传文件，先跑断言再看内容，不通过直接退回，不要自己动手修。

第三条，原始导出文件必须留存，且留存的是发出去的那一份而不是回来的那一份。

第三条最容易被忽略，可它是所有恢复动作的前提：只要源头那份还在，任何损坏都只是重做一次，源头没了才是真的丢了数据。

规范里还要写清楚一件事：不接受任何形式的截图、文档内嵌表格和聊天窗口粘贴。

这句话看着多余，但写上之后能省掉很多次解释。

规范落地之后还要留一个例外通道，总有临时情况需要走别的方式，明确写出来比让人偷偷绕过去好。

## 一次性清理历史损坏的办法

存量数据也要处理，方法是全库扫一遍。

先按字符集白名单扫，把所有含可疑字符的记录拉出来。

再按长度扫，同一批词里明显偏短的可能是被吃掉了字母。

最后按重复扫，两个词只差一个字符的，多半其中一个是坏的。

三遍扫完，人工确认一次，一个中等规模的词表半天能清完，而清完之后把这三条扫描做成定时任务，以后就是自动的。

第二条里的不要自己动手修需要强调一下：自己修会掩盖问题，下一批还会一样坏。

退回去还有一个好处，它让对方那一侧也建立起对这件事的意识。

三条硬约束里第三条最容易被跳过，因为留存看起来没有立刻的收益，直到某一天它成为唯一的救命稻草。

## 每次交付要留的两个数

最后给两个最省事的护栏。

第一个数是行数，发出去多少行，回来必须还是多少行。

第二个数是非基本拉丁字符的总数，也就是这份文件里变音字母和非拉丁字符加起来有多少个。

这个数发出去时记一笔，回来再数一笔。

如果回来的数明显变小，那就是编码损坏，一个数就能判定，不需要逐行比对。这两个数放在交付说明的第一行，是整条流程里性价比最高的两行字。

清理时按品类优先级排序，先清那些是品类词和属性值的行，它们直接影响页面和索引。

长尾词那一批可以放到第二轮，因为单个词的损失小得多。

清完之后把三条扫描做成定时任务，以后就是自动的，这一步是让治理从一次性变成常态的关键。

## 常见问题解答

## 为什么同一份关键词表在同事电脑上打开列数不一样？

因为逗号分隔文件里没有任何一处声明自己用什么符号分列，表格软件双击打开时用的是系统地区设置里的列表分隔符。小数点写成逗号的地区，包括德国、法国、波兰、西班牙、意大利和北欧多数国家，默认分隔符是分号；英美和多数亚洲市场是逗号。做欧洲市场的团队，本地顾问和译员绝大多数在第一类地区，所以这不是偶发事故，是默认状态。改用制表符分隔可以绕开，因为制表符不参与地区设置。

还有一个更省事的替代方案：交付时统一改成制表符分隔，制表符不参与任何地区设置，各地打开结果一致。

## 变音字母变成问号之后还能恢复吗？

显示成问号还有救，保存之后就没救了。软件会把屏幕上那个问号当成真正的内容写回文件，原来的字节被覆盖，任何工具都恢复不出来，只能回到源头重新取。这跟不可见字符那类问题性质不同：那一类是多出了看不见的东西，可以清洗；这一类是丢掉了本来有的信息，属于缺失。所以原始导出文件必须留存，而且要留发出去的那一份，不是回来的那一份。

所以真正的护栏是留存源头文件，且留存的是发出去那一份。只要源头还在，任何损坏都只是重做一次。

## 为什么这些坑在中文和英文词表上很少听说？

因为它们分别落在两个极端。英文只用基本拉丁字母，在几乎所有编码里字节都一样，编码猜错也看不出来。中文猜错是整篇乱码，第一秒就被发现，不会流到下游。小语种正好在中间：只有带变音符号的那批字母出问题，占比通常三分之一左右，而且坏成问号或方块之后看着仍然像内容，文件能打开能保存能导入，一路畅通。坏得越轻，越难被发现。

顺带一提，这也是为什么讲表格数据处理的通用资料几乎不提这一层：它们的默认读者处理的是英文和数字。

## 表格软件把型号和区间改掉了，有没有开关能关掉？

没有一个总开关，但有可靠的绕法。导入时不要双击，用数据菜单里的从文本导入功能，在向导里把所有列的类型设成文本，类型识别就不会动你的数据。已经在编辑的表格里，可以先把单元格格式设成文本再粘贴，或者在内容前加一个撇号。厂商自己的帮助文档里就写着数字变日期和前导零消失这两个行为，还给了这几种绕法，说明它们是被承认的常见问题而不是故障。

还有一条值得记：某些语言的规格写法以加号或等号开头，那会被当成公式，处理办法同样是先把列设成文本。

## 导入之前该做哪些检查才能拦住这类问题？

四条断言就够。字符集断言：全文不得出现问号和替换字符，白名单是这门语言的字母表加数字标点。行数断言：导入行数必须等于导出行数。字段数断言：每行字段数一致且等于表头列数。非空断言：关键列不得为空，因为分列错位最常见的表现就是后面几列整列变空。再补一个最省事的护栏：记录这份文件里非基本拉丁字符的总数，回来时再数一遍，数字明显变小就是编码损坏。

再补一条最省事的护栏：数一数这份文件里非基本拉丁字符的总数，发出去记一笔，回来再数一笔，数字变小就是编码损坏。

## 怎么判断是顾问改坏的还是流程改坏的？

做一次空跑测试。拿一份不做任何修改的文件走完整条链路，发出去、让对方打开保存、再发回来，然后比对。如果这份没人改过的文件回来之后已经不一样，说明链路本身就在损坏数据，跟顾问无关。这个测试半天能做完，而它能省掉很多互相埋怨的时间。经验上答案通常是链路的问题，因为那些改动全部发生在打开和保存这两个动作里，人根本没有参与。

顺带说一句，空跑测试还能测出行序有没有被重排，而行序一变，之后所有按行比对的结果都是假的。

## 权威参考资料



## 设计稿上量出来字号一模一样，泰语用户看到的那行字就是比德语的小一圈

- URL：https://zhangwenbao.com/minor-language-font-size-line-height-script.html
- 分类：小语种SEO
- 发布：2026-07-23  |  更新：2026-07-31
- 摘要：同一个字号在不同书写系统里不是同一个大小。讲清拉丁系语言的膨胀全在横向而非拉丁文字全在纵向、默认行高倍数在天城文上为什么不够用、按语言分档该从哪个参数动起。
- 关键词：技术SEO,移动端SEO,多语言SEO,小语种SEO

> **TLDR**：摘要：同一个字号在不同书写系统里不是同一个大小。保哥拿九种文字实测了一遍：拉丁系语言的麻烦全在横向，同一句话比英语长五成到一倍；非拉丁文字横向几乎不涨，麻烦全在纵向，印地语那一行的墨迹比英语高七成五。而所有响应式测试量的都是宽度。

> 摘要：同一个字号在不同书写系统里不是同一个大小。保哥拿九种文字实测了一遍：拉丁系语言的麻烦全在横向，同一句话比英语长五成到一倍；非拉丁文字横向几乎不涨，麻烦全在纵向，印地语那一行的墨迹比英语高七成五。而所有响应式测试量的都是宽度。

## 设计稿上量出来字号一模一样，泰语用户看到的那行字为什么就是小一圈？

## 一家智能家居品牌的泰国站，反馈里反复出现同一个词

有个客户做智能家居，插座、灯带、传感器、网关这几条线。

泰国和印度是那一年新开的两个市场，页面是从英文站的设计稿本地化过来的。

上线三个月，泰国站的用户调研里反复出现一个反馈：字太小。

设计师第一反应是不可能，因为全站字号是同一套变量，泰语页面和英文页面读的是同一个值。

他把两个版本并排截图，量了像素，确实一模一样。

于是这条反馈被归进了主观感受那一类，处理办法是记录下来但不排期。这个判断在当时看不出毛病：字号是个数字，数字相同就是相同，用户说小只能是习惯问题。

## 印度站的反馈换了一个说法

同一份调研里，印度站的用户没说字小。

他们说的是挤，行和行之间粘在一起，读长段落容易串行。

设计师去看行高，也是同一套变量，一点五倍，跟英文站一致。

两个市场，同一套参数，两种不同的抱怨。

这时候他才意识到，如果参数完全相同而反馈不同，那出问题的一定不是参数本身。

后面这句话是整件事的转折点。字号和行高是你写进样式表的数字，而用户感知到的是这些数字作用在具体字形上之后的结果。这两者之间隔着一层，而那一层的换算比例，每一种书写系统都不一样。

## 把这句话说准确一点

字号这个值，规定的不是字有多高。

它规定的是字体设计者定义的那个方框有多大，字形画在这个方框里，具体画多满由字体决定。

拉丁字母的小写字母，通常只占这个方框的一半左右，剩下的空间留给大写字母、升部和降部。

泰文没有大小写 (https://w3c.github.io/sealreq/)，所有字母的主体都挤在一条窄带里，上下留出来的空间是给声调符号和元音符号用的。

天城文的字母主体 (https://w3c.github.io/ilreq/)比拉丁的小写字母大得多，可是它上面要挂一条顶线，下面还可能挂符号。

所以同一个字号，落到不同书写系统上，那个方框里被填满的比例、被填在什么位置、留给记号的空间够不够，全都不一样。这不是字体质量问题，是文字本身的结构决定的。

## 这件事为什么在英文站上从来不出现

整套排版参数的默认值，是照着拉丁字母调出来的。

浏览器默认十六像素，行高一点五倍左右，这两个数字对拉丁字母确实合适。

设计系统里那套字号阶梯，也是在拉丁字母上试出来的。

把这套参数搬到另一套文字上，等于把一套为特定字形结构优化过的常数，用在一个结构不同的对象上。

它未必立刻出错，但是它不再是被优化过的值，它只是一个碰巧还能用的值。

本站在别的话题上多次遇到同一个结构：一个常数在英语上被反复调优到最佳，然后被当成普适值搬走。可读性公式 (https://zhangwenbao.com/minor-language-readability-score-english-calibrated-formula.html)是这样，字符长度上限是这样，字号阶梯也是这样。它们的共同点是那个常数本身没有写错，只是它的适用范围从来没有被写下来过。

## 先说结论，免得后面越读越乱

实测下来这件事分成两半，而两半的方向正好相反。

拉丁系语言的麻烦全在横向：同一句话比英语长一半到一倍，撑的是宽度。

非拉丁文字的麻烦全在纵向：同一句话的宽度跟英语差不多，可是墨迹高出一大截，吃的是行高。

而团队做响应式测试时，量的全是宽度。

断点、折行、溢出、横向滚动，这四件事都是宽度的事。

纵向那一半没有对应的测试动作，因为在拉丁字母的世界里，文字的高度是个常量，没有人需要测它。下面把这两半分别拆开，数字都是保哥自己量出来的。

## 横向撑爆和纵向压扁，为什么是两笔方向相反的账？

## 先看横向这一半的实测数字

保哥拿同一句话在同一个字号下渲染，量它的实际墨迹宽度。

取的是电商站上最常见的那句加入购物车，各语言用当地站上的实际写法。

以英语的宽度为基准，德语长百分之六十三，波兰语和法语各长百分之五十八，芬兰语长百分之五十。

越南语长百分之七十四，俄语长百分之八十九。

最长的是希腊语，长百分之一百零四，也就是刚好翻倍。

这一列数字里没有任何意外，做过多语言站的人都知道译文会变长。真正值得注意的是它的分布：这七门语言全部是拉丁字母或者结构接近的字母文字，没有一个例外。膨胀是字母文字的共同属性，因为字母文字表达同一个意思需要更多个字符。

## 再看非拉丁那一半，数字完全不是一回事

同一句话，泰语比英语短百分之三。

印地语长百分之八，中文长百分之五。

三门语言的宽度都跟英语基本持平，横向那一整套麻烦在它们身上根本不成立。

如果只看这一列，会得出一个错误结论：这几门语言最好做，布局不用改。

换成高度那一列，结论立刻翻转。

同一句话在十六像素下的实际墨迹高度：英语十二像素，德语十二像素，泰语十二像素，中文十五像素，波兰语法语俄语越南语都是十六像素，印地语二十一像素。印地语比英语高出百分之七十五，而它的宽度只多了百分之八。

## 把这两列并排看，才看得出这是两个问题

德语：宽度加六成三，高度不变。

俄语：宽度加八成九，高度加三成三。

越南语：宽度加七成四，高度加三成三，两头都吃。

泰语：宽度减三，高度不变，但是主体带被压缩。

印地语：宽度加八，高度加七成五。

所以这不是一个膨胀问题的不同程度，是两个不同的问题：一个消耗水平方向的空间预算，一个消耗垂直方向的空间预算。它们的表现形式、检测方法、修复手段完全不同，而行业里只有前者有成熟的话术。

## 越南语是唯一两头都吃亏的那一档

越南语用的是拉丁字母，所以它继承了字母文字的横向膨胀，宽度加七成四。

同时它的声调记号叠在元音上方，有些字还叠两层，所以它又有非拉丁文字的纵向问题。

实测下来它的墨迹高度是十六像素，跟俄语波兰语同档，比英语德语高三分之一。

这解释了一个现象：越南语页面在窄屏上塌得特别快。

它既比英语宽，又比英语高，两个方向的余量同时被吃掉。

本站讲越南语声调记号 (https://zhangwenbao.com/vietnamese-seo-tone-marks-syllable-spacing-keyword.html)那一篇算的是关键词覆盖那笔账，这里补上排版这笔。同一个记号，在词表里是要不要多收一行的问题，在版面上是要不要多留几个像素的问题，两笔账互不替代。

## 这两笔账各自会在什么地方爆出来

横向那一笔爆在有硬边界的地方：按钮、导航项、表格列头、筛选标签、卡片标题。

它的表现是文字被截断、按钮换行、横向滚动条冒出来。

纵向那一笔爆在有固定高度的地方：等高卡片、列表行、折叠区块、首屏内的信息量。

它的表现是记号被裁掉、行与行粘连、卡片文字溢出、首屏能看到的内容变少。

前一类肉眼一看就发现，后一类要盯着看才发现，而且很容易被当成设计风格。

这就是为什么泰国站的用户只能说出字太小这三个字，印度站的用户只能说出挤。他们描述的是同一个类别的问题，可这个类别在团队的词汇表里没有名字，于是两条反馈被分别归进了两个抽屉。

## 同一个字号下实测一遍，各书写系统的墨迹到底占多高？

## 这次实测是怎么做的

保哥用系统自带的字体，把同一批文本渲染成图，再逐像素统计。

拉丁、西里尔、希腊、希伯来、阿拉伯、越南语用同一款界面字体，泰文、天城文、中文各用系统给这几种文字准备的默认字体。

量三样东西：一个不带任何上下记号的基本字符有多高，一个真实的词连记号一共占多高，以及字体自己声明的那个行盒有多高。

灰度低于某个阈值的像素算墨迹，阈值统一。

这个口径不完美，它依赖具体字体，换一款字体数字会变。

但是它有一个好处：它量的是屏幕上真实出现的那些像素，而不是字体文件里声明的度量值。用户能不能读清楚，取决于前者不取决于后者，而绝大多数关于字号的讨论用的都是后者。

## 第一列：基本字符的高度，结果跟直觉相反

在十六像素下，拉丁字母的小写字母主体高八像素。

西里尔、希腊、泰文、越南语的基本字符也是八像素，跟拉丁完全一致。

希伯来字母九像素，阿拉伯字母十像素。

天城文的基本字符十二像素，比拉丁高一半。

汉字十四像素，比拉丁高七成五。

换句话说，同一个字号下，天城文和汉字的字形本来就比拉丁字母大。要让它们的基本字形缩到跟拉丁十六像素一样高，天城文只要十一像素，汉字只要九像素。这个结果直接推翻了那个最流行的解法：给小语种页面调大字号。对这两种文字来说，字根本就不小。

## 第二列：真实词的全高，这才是占地方的那个数

基本字符只是主体，真实的词还要带上记号和升降部。

十六像素下，英语一个真实词的墨迹高十六像素，德语十二像素，泰语十三像素。

波兰语、法语、俄语、越南语都是十六像素，中文十五像素。

印地语最高，一个短句量出来二十一像素。

把第一列和第二列并排看，泰文的情况就清楚了：它的基本字符只有八像素，跟拉丁一样，可它的全高是十三像素，多出来的五像素全给了上下两层记号。也就是说泰文的信息被压进了一条比拉丁窄的主体带，上下的空间还得分出去。

## 第三列：行盒是个常数，墨迹不是

字体会声明一个行盒高度 (https://learn.microsoft.com/en-us/typography/opentype/spec/os2)，浏览器拿它做默认行高的基准。

十六像素下，那款界面字体的行盒是二十三像素，中文字体是二十二像素。

这个数字在同一款字体里对所有文字都一样，不区分书写系统。

可墨迹从十二像素到二十一像素不等，最大差九像素。

于是同一个行盒里，拉丁字母上下各留出五六像素的余量，印地语只剩下一两像素。

行盒这个常数是整件事的核心矛盾：排版系统假设一行文字的高度是可预测的，而这个假设只在单一书写系统内部成立。一旦一个网站要同时排版拉丁、泰文和天城文，这个假设就不再是安全的默认值，它变成了一个需要按语言重新设定的参数。

## 把三列合起来读，能读出三个不同的病

拉丁系语言：基本字符八像素，全高十六像素，行盒二十三像素，余量充足，纵向没病。

泰文：基本字符跟拉丁一样小，全高偏低，可主体带被记号挤压，病在细节看不清。

天城文：基本字符大，全高逼近行盒，病在行高不够。

汉字：基本字符最大，密度最高，病在小字号下笔画糊在一起。

四种病，四种解法，而它们在样式表里对应的可能是同一行代码。

这就是为什么按语言另设一档不能只调一个参数。给泰文调大字号，主体带确实变大，可它同时把本来就够用的宽度撑开了；给天城文调大字号，行高更不够用；给汉字调大字号，密度问题一点没解决。诊断错了变量，改动就只会把另一个指标弄坏。

## 那个默认的行高倍数，为什么在天城文上刚好不够用？

## 一点五倍这个数字是从哪来的

行高一点五倍是现在最常见的正文设定。

它有两个来源：一是长期的排版经验，二是无障碍规范里的一条要求。

规范那一条 (https://w3c.github.io/wcag/understanding/text-spacing.html)说的是，用户如果把段落行高调整到字号的一点五倍，内容不能因此丢失或者失去功能。

注意它的措辞，它规定的是页面必须能承受这个调整，而不是说一点五倍就是合适的行高。

很多人把它读成了推荐值。

这个误读在拉丁字母上没有代价，因为一点五倍对拉丁字母确实合适，误读之后得到的答案碰巧是对的。这类误读最难被发现，因为它从来不产生错误的结果，直到换一种文字。

## 算一遍余量就知道差在哪

十六像素配一点五倍行高，一行占二十四像素。

英语的墨迹是十二像素，剩下十二像素分给上下行间。

波兰语和俄语的墨迹是十六像素，剩下八像素。

印地语的墨迹是二十一像素，剩下三像素。

同一套参数，行间空隙从十二像素掉到三像素，只剩四分之一。

这三像素是什么概念：两行文字之间几乎没有视觉分隔，眼睛在换行时找不到落点，读长段落容易串行。这正是印度站用户反馈里那个挤字的来源，他们描述的不是字号，是行间距，而团队去查的是行高参数，参数当然是对的。

## 行高不够的表现不是重叠，是裁切

很多人以为行高不够会看到两行字叠在一起。

实际很少这样，因为浏览器会保证行盒不重叠。

真正发生的是记号被相邻元素或者容器的溢出规则裁掉。

泰文的上声调符号、天城文的上标元音、越南语的第二层记号，都在最上面那一两个像素上，窄屏上的阿拉伯语版面 (https://zhangwenbao.com/arabic-rtl-mobile-first-narrow-screen-pitfalls.html)也有同一族问题。

一个设了固定高度并且隐藏溢出的卡片，裁掉的正好是这一层。

裁掉一个记号和裁掉半个字母的后果完全不同：半个字母还能认出来，一个丢了声调的越南语词是另一个词。本站讲换行与不可见字符 (https://zhangwenbao.com/minor-language-line-break-soft-hyphen-invisible-character.html)那一篇里说过一次同类的事，那一篇是横向的，这一条是纵向的，两条加起来才是完整的溢出清单。

## 为什么调大字号救不了这个问题

直觉解法是把非拉丁语言的字号调大一档。

调大字号，行高按倍数跟着放大，余量的比例一点没变。

因为余量是按比例算的，而问题恰恰出在比例上。

十六像素配一点五倍剩三像素，二十像素配一点五倍剩三点七五像素，依然不够。

同时字号变大之后，横向宽度、卡片高度、首屏内容量全部被牵动。

正确的解法是调行高不是调字号：把行高倍数按书写系统另设一档，天城文和泰文给到一点七到一点八，阿拉伯语给到一点六五左右，其余保持一点五。这个改动只影响纵向，不牵动任何一个横向指标，代价小得多。

## 行高还有一个容易写坏的地方

行高的值 (https://developer.mozilla.org/en-US/docs/Web/CSS/line-height)要写成无单位的倍数，不要写成固定像素。

写成固定像素时，子元素继承的是那个像素值，而不是倍数关系。

一旦某个子元素的字号变了，它的行高不会跟着变，余量就塌了。

多语言站上这个坑更容易踩，因为你很可能给某种文字单独调了字号，却忘了它的行高是从上面继承下来的固定值。

这一条不是语言层的知识，是样式表的基础规则。

把它放进来是因为它和按语言分档这件事天然连在一起：只要你开始按语言给字号分档，继承链上任何一个固定行高都会变成一个定时炸弹，而在单语言站上它可以一直安静地待着。

## 区分两个词的那个记号，在十二像素下还剩几个像素？

## 先说这一测是怎么设计的

取一个基本字符，再取同一个基本字符加上区分词义的记号，两者分别渲染。

用后者的墨迹像素数减去前者的，差值就是那个记号本身贡献的墨迹。

这个数比记号的高度更有意义，因为人眼能不能分辨，取决于有多少像素落在那里，不只取决于它有多高。

测了四个字号：十二、十四、十六、二十像素。

八种文字各测一对。

这一测的目的不是给出绝对阈值，是给出一个相对排序：在同样的字号下，哪些语言的关键区别信息更容易被压没。

## 结果：最危险的不是看起来最复杂的那几种

十二像素下，希腊语的重音记号只贡献三个像素。

西里尔字母上那两个点也是三个像素，阿拉伯语的短元音记号三个像素。

拉丁字母的重音记号四个，希伯来语的元音点四个。

而泰文的声调符号有十个像素，天城文的元音记号有十个，越南语的叠加记号七个。

这个排序跟直觉正好相反：看上去最复杂、最陌生的那几种文字，它们的记号反而是完整的字形，占的像素多，缩小之后还认得出。真正危险的是那些只有一撇一点的小记号，它们在拉丁、希腊、西里尔、阿拉伯这几种最常见的文字上，而且它们承载的经常是词义级别的区别。

## 十二像素这个字号在页面上出现在哪

正文很少用十二像素，但是页面上有一大批文字用。

面包屑、规格参数表、角标、法律声明、商品卡片上的副标题、筛选器里的取值。

移动端还要再往下走一档，很多设计系统的最小字号就是十二像素。

这些位置有一个共同点：它们装的多半是精确信息，型号、规格、条件、限制。

而精确信息恰恰是最不能认错的那一类。

把这两件事叠起来：最需要精确的内容，用了最小的字号，而在几种主要文字上，区分词义的记号在这个字号下只剩三四个像素。这不是一个理论风险，它就是规格表看错的日常来源。

## 记号丢失和记号看不清是两回事

本站写过记号在数据管道上被丢掉 (https://zhangwenbao.com/cyrillic-encoding-legacy-windows1251-utf8-indexing-cost.html)的那一类问题，那是字符层的事，字符串里真的没有那个字符了。

这里说的是字符还在，渲染也正确，只是在这个尺寸下人眼分辨不出。

前者可以用脚本检出，后者任何脚本都检不出，因为数据完全正确。

前者影响检索匹配，后者只影响阅读理解。

两者的修复手段也没有交集：一个修管道，一个改样式。

把这两件事分开，是因为团队经常拿前者的检查结果去回答后者的问题。词表校验全绿，不等于用户在手机上能把这个词认出来。这两句话之间隔着字体、字号、对比度和屏幕。

## 低对比度会把这几个像素直接抹掉

三四个像素的记号，是靠这几个像素和背景的明暗差被看见的。

灰色小字这种流行做法，正好把这个差值压低。

对比度不足在无障碍检查里会被报出来，但是报出来的理由是整段文字的对比度。

没有一条规则会说，你这个语言的记号在这个字号加这个对比度下已经消失了。

因为这条规则需要同时知道字号、字体、对比度和这门语言的记号形态，四个变量。

所以这一层只能靠人在真实设备上看。判断办法很土但是有效：把页面在手机上打开，拿给一个母语者，让他念规格表里的型号和参数。念错或者迟疑的地方，就是记号被压没的地方。

## 笔画密度决定了哪一批文字先在小字号上糊掉？

## 密度这个指标怎么量

取一个真实的词，渲染出来，数它的墨迹像素有多少个。

再量它的外接框面积，两个数一除，得到墨迹占框的比例。

这个比例就是笔画密度。

比例越高，说明同样一块地方塞进去的笔画越多。

它跟好不好看无关，只跟能不能分辨有关。

之所以要单独量这一项，是因为前面两项都在讲尺寸，而尺寸够大不等于看得清。一个笔画极密的字即使尺寸很大，缩小之后相邻笔画照样会粘成一团，而尺寸小但笔画稀疏的字反而更耐缩。

## 实测排序，头尾差了一倍

十六像素下，汉字的密度是百分之四十四，最高。

希伯来语百分之四十四，越南语百分之四十二。

泰文百分之三十六，天城文百分之三十一。

拉丁百分之二十九，西里尔百分之二十九，希腊百分之二十七。

最低的是阿拉伯语，百分之二十一。

头尾差了一倍以上。阿拉伯语那条曲线 (https://w3c.github.io/alreq/)连绵起伏、留白很多，所以它在密度上最占便宜；汉字和越南语在同样一块面积里塞进去的墨最多，它们最先糊。越南语上榜的原因跟汉字不同，它是拉丁字母加上叠加记号，记号把本来空着的上方填满了。

## 字号缩小时密度反而上升，这是关键的一步

把字号从十六像素降到十四像素，密度不但没降，还涨了。

汉字从百分之四十四涨到百分之五十二，希伯来语从四十四涨到四十七。

原因很朴素：笔画再细也不能细于一个像素。

字号缩小时，字形的整体尺寸按比例缩，可最细的那些笔画缩不下去，只能保持一个像素。

于是笔画占的比例被动上升，留白被吃掉。

这条机制解释了为什么高密度文字在小字号上的劣化不是线性的。它不是慢慢变模糊，而是过了某个尺寸之后突然糊成一团，因为在那个尺寸上相邻笔画之间的留白已经不足一个像素，两笔直接连上了。

## 在高密度文字上加粗是反效果

字太小看不清，第二个直觉解法是加粗。

加粗在拉丁字母上通常有效，因为它留白多，加粗之后对比更强。

在汉字、越南语、希伯来语这几种密度本来就高的文字上，加粗把仅剩的留白也填掉了。

结果是笔画更容易连成一片，反而更难认。

这一条在小字号上尤其明显，因为小字号本来就已经在密度上限附近。

所以按语言分档时，字重也要分档，而且方向跟拉丁相反：高密度文字的小字号位置应该用常规字重甚至更细的一档，靠对比度而不是靠笔画粗细来提升可读性。这个做法跟设计直觉是拧着的，需要在规范里写清楚理由，否则下一个设计师会改回去。

## 字体回退会把密度问题放大一档

网页字体没加载出来时，浏览器用系统字体顶上。

拉丁字母的回退字体和原字体在观感上通常差别不大。

非拉丁文字的回退结果差别可能非常大，因为设备上可用的那套字体未必是为屏幕优化过的。

本站讲非拉丁字形集与首屏成本 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)那一篇算过体积这笔账，这里是它的下游：回退不仅意味着换了个样子，还意味着换了一套度量。

换度量之后，你调好的字号和行高全部失准。

最常见的表现是字突然变小或者变大一圈，然后在字体加载完成时再跳一次。这一跳既是观感问题也是布局稳定性问题，而它在非拉丁文字上的幅度比拉丁大得多。

## 用户把字体放大之后，最先塌的是哪一块？

## 规范里那条放大要求说的是什么

无障碍规范 (https://w3c.github.io/wcag/understanding/resize-text.html)要求，文字放大到两倍时，内容和功能不能丢失。

这是AA级要求，跟前面那条行高要求同级。

它假定的场景是用户视力有限，需要更大的字。

验收方式很简单，把浏览器缩放到两倍，看页面还能不能正常用。

多数团队测过这一条，测的是英文站。

而这一条的通过难度在不同语言上完全不同，因为它的实际约束是：放大之后原有的布局余量还够不够用。而余量在各语言上本来就不一样，前面两节已经把这件事量出来了。

## 拉丁系语言放大后先爆横向

德语和俄语在原始字号下就已经比英语宽五成到九成。

再放大一倍，横向空间的缺口按比例扩大。

先出问题的是那些有硬边界的元素：并排的按钮、固定列宽的表格、导航项。

它们在英文站上刚好放得下，在德语站上勉强放得下，放大之后就放不下了。

典型表现是按钮文字换行、表格出现横向滚动、导航项挤成两行。

本站讲德语复合词 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)那一篇讲过词长本身的问题，这里补的是它和放大要求叠加之后的效果：两个各自可控的因素乘在一起，就变成了不可控。做多语言站时，任何一条余量都要按最长的那门语言而不是按英语来留。

## 非拉丁站放大之后爆的是另一处

泰语 (https://zhangwenbao.com/thai-seo-no-spaces-word-segmentation-keyword.html)和印地语 (https://zhangwenbao.com/india-multilingual-seo-eleven-languages-nine-scripts-priority.html)的横向余量本来就够，放大之后横向依然够。

先出问题的是垂直方向：固定高度的卡片装不下，折叠区块的收起状态露出半行，首屏里的内容大幅减少。

还有一处更隐蔽：行高如果写成了固定像素，放大字号时行高不跟着变，行间距被压成负余量。

这时候记号就真的被切掉了。

所以同一条AA要求，在两类语言上要用两套测试脚本去验。

横向那一套业内已经有成熟做法，缩放到两倍看有没有横向滚动条就行。纵向那一套没有现成做法，能用的判据是：放大之后，带有固定高度的容器里，文字的顶部和底部有没有被裁掉。这个判断只能靠截图比对，或者在真实设备上翻一遍。

## 系统级放大比浏览器缩放更常见

做验收时大家习惯用浏览器缩放，那是最方便的方式。

真实用户更多用的是操作系统或者手机系统里的字体大小设置。

这两种放大的行为不完全一样，系统级设置改的是根字号，浏览器缩放改的是整体比例。

改根字号时，用像素写死的那些尺寸不会跟着变，只有用相对单位写的才会变。

于是页面会进入一个混合状态：文字变大了，容器没变。

这个混合状态才是真实用户遇到的那一个，也是最容易露出裁切问题的那一个。所以验收清单上应该写系统级字体放大，而不是浏览器缩放，两者测出来的问题不是同一批。

## 这一条该怎么测才省事

挑三个页面：一个信息密度最高的列表页，一个规格表最长的详情页，一个表单页。

每个页面各测两种放大方式，两倍缩放和系统字体调到最大档。

每种方式各截一张图，跟原始状态并排放。

看三件事：有没有横向滚动、有没有文字被容器裁掉、有没有两行粘在一起。

三件事各对应前面拆出来的一个病因。

这一套跑完不超过半小时，产出是六张对比图。它比任何一份自动化报告都更能说服人，因为裁掉的记号在截图上是看得见的，而报告里的分数看不见。

## 按语言另设一档字号，样式该怎么写才不失控？

## 用语言选择器，不要给每种语言复制一套样式

样式表里有一个按语言匹配的选择器 (https://w3c.github.io/i18n-drafts/questions/qa-css-lang.en)，直接读页面上声明的那个语言值。

它的用法是给特定语言的元素追加几条属性，而不是重写整套样式。

这样做的前提是页面上的语言必须声明正确，声明错了样式就落在错的语言上。

这一点跟把同一个声明喂给发音引擎 (https://zhangwenbao.com/minor-language-screen-reader-lang-pronunciation.html)那一篇是同一个前提，那一篇讲的是页面语言声明错了之后整页会被怎么念出来。

同一个属性，一处喂给样式，一处喂给辅助技术，两处都靠它。

这也是为什么本站把语言声明列在多语言站必须最先做对的那几件事里：它不是一个孤立的标记，它是好几条链路共同的输入，而其中至少两条链路没有任何兜底。

## 先动行高，再考虑动字号

按前面的诊断，多数纵向问题的正确解法是行高不是字号。

给天城文和泰文的正文行高提到一点七五左右，阿拉伯语提到一点六五。

字号保持不变，横向指标一个都不受影响。

只有在小字号位置上才需要动字号，比如把非拉丁文字的最小字号从十二像素提到十三或十四。

这一档改动影响的是那些精确信息区域，收益最直接。

顺序很重要：先调行高看反馈，不够再动最小字号，最后才考虑动正文字号。反过来做的话，第一步就会牵动全站布局，改动大、风险高，而且往往解决不了真正的病因。

## 字体回退的度量差异用哪个属性兜

样式表里有一个属性专门处理这件事 (https://developer.mozilla.org/en-US/docs/Web/CSS/font-size-adjust)，它按小写字母主体高度来校准字号。

它的作用是：不管最终用上的是哪一款字体，让主体高度保持一致。

这样字体回退时视觉大小不会突然跳一档。

它对拉丁字母最有效，对没有小写字母概念的文字要用它的扩展写法。

浏览器支持这几年才补齐，用之前要确认目标市场的浏览器分布。

这个属性存在的理由本身就说明了问题：字号这个值不足以决定视觉大小，所以规范里补了一个专门校准视觉大小的属性。而这个不足，正是本篇从头到尾在量的那件事。

## 一份可以直接照抄的分档

拉丁与西里尔与希腊：正文十六像素，行高一点五，最小十二像素。

阿拉伯与希伯来：正文十六像素，行高一点六五，最小十三像素。

泰文与东南亚诸文字：正文十六像素，行高一点七五，最小十四像素。

天城文与印度诸文字：正文十六到十七像素，行高一点七五，最小十四像素。

中日韩：正文十六像素，行高一点七，最小十二像素，小字号位置避免加粗。

这份分档是从前面那几列实测推出来的，不是从哪本规范抄的，所以它需要按你自己站上的字体重新验一遍。验的办法就是本篇用的那套：渲染、量墨迹、算余量。换一款字体，数字会变，方法不变。

## 什么时候该换字体，而不是继续调参数

参数能救的是尺寸和间距，救不了字形本身。

如果一款字体在目标文字上的记号做得过小，或者缺少必要的定位规则，调参数没用。

判据是：把字号调到很大时，记号是否清晰、位置是否正确。

调大之后依然别扭，说明是字体问题，要换。

各文字的开源字体家族现在覆盖得相当全，换字体的成本主要在体积和加载策略上。

这条边界要划清楚，因为团队很容易在参数上反复调半个月，而问题从第一天起就在字体文件里。先花十分钟做一次大字号目检，能省下这半个月。

## 这件事最后会在搜索那一侧以什么形式结算？

## 首屏能装下多少内容，被这两笔账直接改写

同一块屏幕，德语站上装的字比英语站少四成，因为每个词更宽。

印地语站上装的行数更少，因为每一行更高。

首屏里能不能出现那段回答用户问题的文字，就是被这两个数决定的。

页面结构完全一样，主体内容的起始位置却不一样。

这一层不体现在任何一个技术指标上，它只体现在用户要不要多滑一屏。

做多语言站时，首屏的信息优先级应该按语言重排而不是共用一套。英语站上放得下的标题加副标题加三行摘要，在德语站上可能只放得下标题加一行，那就该砍掉副标题而不是让摘要沉到折叠线以下。

## 截断位置在不同语言上不是同一处

结果页上的标题和描述按宽度截断。

同样的字符数，各语言占的宽度差一倍，被截掉的位置自然不同。

本站讲芬兰语 (https://zhangwenbao.com/finnish-seo-fifteen-cases-consonant-gradation-keyword.html)和泰语 (https://zhangwenbao.com/thai-seo-no-spaces-word-segmentation-keyword.html)标题截断那两篇分别算过这笔账，那是检索展示侧的。

页面内部还有一套自己的截断，卡片标题、列表项、面包屑，它们按容器宽度截。

两套截断的边界不一样，同一个词可能在一处完整在另一处被切。

这里只提一句边界：本篇处理的是渲染尺寸，截断策略本身是另一层的事。两者的关系是，渲染尺寸决定了截断在第几个字符发生，而截断规则决定了发生之后怎么处理。

## 布局稳定性会被字体回退拖累

字体加载完成前后，如果两套字体的度量差别大，文字块的高度会变。

高度一变，下面的内容整体位移，这就是累积布局偏移 (https://zhangwenbao.com/cls-cumulative-layout-shift-visual-stability-guide.html)。

拉丁字母上这个差值通常很小，非拉丁文字上可能很大。

所以同一套字体加载策略，在英文站上偏移可以忽略，在泰语或印地语站上可能踩红线。

能兜住的手段是把回退字体的度量对齐，以及前面说的那个按主体高度校准的属性。

这是本篇里唯一一个直接落在公开性能指标上的科目。其余那些，用户能感觉到，仪表盘上看不到。

## 可读性评分那把尺子在这里同样不作数

内容团队常用可读性分数来判断一段文字好不好读。

那套公式量的是句子长度和词长，跟渲染尺寸没有任何关系。

一段分数很好的印地语文字，在行高不够的容器里照样难读。

本站算过那把尺子的刻度是拿英语标定的 (https://zhangwenbao.com/minor-language-readability-score-english-calibrated-formula.html)，这里再加一条：它连排版这一维都不测。

可读性至少有两层，一层在文字里，一层在屏幕上。

两层要用两套方法验，而且屏幕这一层没有分数可用，只能靠实测和目检。这也是为什么本篇给的是一套量法而不是一个阈值。

## 真正的结算科目是体验不是排名因子

把这件事包装成排名因子是不诚实的。

字号和行高不是排名信号，改对了排名不会动。

它结算在三处：移动端的实际可用性、转化率、以及需要合规资质的那些市场里的采购门槛。

第三处正在变重，因为无障碍要求在越来越多的市场上从建议变成了法定。

做小语种市场的团队应该按这三处排优先级，而不是等一个排名解释。

本站在其它话题上反复说过同一句话：不是所有该做的事都需要一个排名理由。有些事的收益在漏斗更下游的地方结算，而那里的数字往往更大。

## 一份按书写系统分档的排版清单，以及哪些交出去

## 上线前的四项目检

第一项：拿本地语言的真实内容替换掉设计稿里的占位文字，看有没有溢出或者裁切。

第二项：把系统字体大小调到最大档，翻三个关键页面。

第三项：把最小字号那一档的文字放大到很大，检查记号形态和位置对不对。

第四项：在真机上让母语者念一遍规格表。

四项都不需要工具，加起来一小时以内。

四项分别对应前面拆出来的四个病因：横向余量、纵向余量、记号可辨识度、字体质量。做完这四项，剩下的问题基本都是设计偏好而不是可用性缺陷。

## 设计交付物里要多两列

设计规范里的字号阶梯，通常只有一列数值。

多语言站要多两列：这一档在非拉丁文字上的行高倍数，以及这一档的最小字号是否需要上调。

这两列不写下来，实现那一侧只能凭感觉，而感觉是照着拉丁字母长出来的。

交付物里最好附一张各语言的真实文本样张，而不是只给参数。

样张要用最长的那句和记号最密的那句。

本站在讲图片与替代文本 (https://zhangwenbao.com/minor-language-image-alt-text-non-latin-script-search.html)那一篇里提过类似的做法：给规则不如给样本，因为规则会被理解成别的意思，样本不会。

## 内容团队要知道的一件事

内容团队通常不参与排版，但是有一件事只有他们能控制。

同一个意思在目标语言里往往有长短两种说法。

在按钮、导航、卡片标题这些硬边界位置上，选短的那个能省下大量返工。

这不是要求他们写得干瘪，是要求他们知道哪些位置有硬边界。

把有硬边界的字段列成一张表交给他们就够了。

这条在德语和俄语市场上收益最大，因为那两门语言的膨胀率最高，而它们恰好又都有丰富的同义表达可选。

## 哪些不归语言层，一句话交出去

字体文件的体积、子集化、加载顺序与闪烁策略 (https://zhangwenbao.com/web-font-loading-font-display-foit-fout-optimization.html)，归性能那一层。

响应式断点、栅格系统、组件库的设计，归前端工程。

对比度、焦点样式、键盘操作，归通用无障碍访问工程 (https://zhangwenbao.com/website-accessibility-seo-optimization-guide.html)。

低端设备和弱网下的整体表现 (https://zhangwenbao.com/overseas-weak-network-low-end-phone-mobile-performance-optimization.html)，归移动端性能。

页面语言声明写在哪几处、写错了会怎样 (https://zhangwenbao.com/minor-language-screen-reader-lang-pronunciation.html)，归本篇的孪生篇。

本篇只处理一件事：同一套排版参数作用在不同书写系统上，得到的结果不一样，以及这个差异该怎么量、怎么补。

## 从哪一步开始最划算

如果只做一件事，做行高分档。

它改动最小，风险最低，收益最直接，而且不牵动任何横向指标。

如果能做两件，第二件做最小字号上调。

第三件才是正文字号，因为它会牵动全站布局。

第四件是字体选型，那是一个需要排期的项目。

这个顺序是按改动成本除以收益排出来的。多数团队的直觉顺序正好倒过来，先讨论换字体，再讨论调字号，最后才想到行高，于是最便宜的那件事排在了最后。

## 常见问题解答

## 我们直接给小语种页面把字号调大一档，是不是就解决了？

多半没解决对的那个问题。实测下来，天城文和汉字的基本字形在同一个字号下本来就比拉丁字母大一半以上，字并不小。真正不够的是行高和记号的可辨识度，调大字号会让行高更紧，同时把横向布局撑开。正确的第一步是行高分档，字号往后放。

## 这些数字换一款字体还成立吗？

绝对值会变，相对关系基本稳定。因为它们来自书写系统的结构差异：有没有大小写、记号叠几层、笔画密不密。这些属性不随字体变。所以照抄数字有风险，照抄方法没有，用同一套量法在你自己的字体上跑一遍就行，成本是半小时。

## 行高提到一点七五，页面会不会显得太松？

在拉丁字母上会，在泰文和天城文上不会。松不松是相对于墨迹高度的感受，同一个倍数在墨迹高的文字上换算出来的实际行间距更小。所以正确的做法不是统一一个观感最好的倍数，而是让各语言的实际行间距落在接近的区间里，倍数自然就不同。

## 为什么最危险的是希腊语和阿拉伯语的记号，不是泰文？

因为泰文和天城文的记号是完整的字形，本身占的墨迹多，实测在十二像素下还有十个像素。而希腊语的重音、西里尔的两点、阿拉伯语的短元音只有三到四个像素。像素越少越容易被小字号、低对比度和低分辨率屏幕一起抹掉，而它们承载的经常是词义级别的区别。

## 横向膨胀这件事，能不能靠自动缩小字号来兜？

能兜住不溢出，兜不住可读性。自动缩小通常发生在按钮和卡片标题这些位置，缩完之后那几处正好落进最小字号的危险区，而它们装的又是行动指令。更稳的做法是在内容侧选短的表达，在设计侧按最长的那门语言留余量，把自动缩小当成最后一道保险而不是常规手段。

## 我们只做欧洲市场，是不是就不用管纵向这一半？

欧洲市场里希腊语的横向膨胀最高，达到一倍，纵向问题确实弱。但只要站上有阿拉伯语或者希伯来语版本，纵向那一半立刻成立，这两门语言在欧洲市场的用户规模并不小。判断依据不是市场在哪，是你的站上有没有非拉丁书写系统的版本。

## 这件事该由设计还是前端负责？

诊断归语言层，执行分两处。行高与字号分档写在设计规范里，由设计出参数；语言选择器与字体回退的实现归前端。最容易掉在缝里的是那张按语言的参数表，因为它既不像设计资产也不像代码。建议把它和语言声明清单放在同一份文档里，两者本来就共用同一个输入。

## 权威参考资料



## 读屏软件把那段波兰语用英语的嘴念完，而页面上一个字符都没写错

- URL：https://zhangwenbao.com/minor-language-screen-reader-lang-pronunciation.html
- 分类：小语种SEO
- 发布：2026-07-20  |  更新：2026-07-31
- 摘要：屏幕阅读器不做语言识别，它照着语言标签挑发音引擎。讲清检索侧为什么有兜底而朗读侧没有、外语片段标注在小语种站上为什么每页都触发、自动化规则为什么只能验格式。
- 关键词：技术SEO,多语言SEO,小语种SEO

> **TLDR**：摘要：页面上的字有两个出口，一个给眼睛，一个给耳朵，而耳朵那个出口的开关是lang属性。搜索引擎读到写错的语言标签会自己重新判一遍，屏幕阅读器不判，它照着那个值挑发音引擎，一个字母都不商量。于是同一个错误在检索侧只是概率变差，在朗读侧是百分之百念成另一门语言。

> 摘要：页面上的字有两个出口，一个给眼睛，一个给耳朵，而耳朵那个出口的开关是lang属性。搜索引擎读到写错的语言标签会自己重新判一遍，屏幕阅读器不判，它照着那个值挑发音引擎，一个字母都不商量。于是同一个错误在检索侧只是概率变差，在朗读侧是百分之百念成另一门语言。

## 屏幕上没有一点问题的那一页，念出来为什么成了另一门语言？

## 一家二手书店的波兰站，客服收到的投诉里带着一个奇怪的词

有个客户做二手书跨境，波兰、捷克、希腊三个市场。

书这个品类的特点是标题极长，作者名、原名、译名、出版社、版次全挤在一行里。

那一季他们收到一封波兰用户的邮件，说你们网站听起来像一个说英语的人在念波兰语单词。

客服看不懂这句话，因为网站上的字明明是波兰语，一个英文都没有。

邮件里还提了一句，说他用的是免费的读屏软件，平时看别的波兰站都好好的。

团队第一反应是这是个孤例，一个视障用户的软件设置问题，跟网站没关系。这个判断在当时看起来完全合理，因为所有人都能打开这个网站，屏幕上什么毛病也没有，而对方描述的现象既没法复现，也不在任何一张检查表上。

## 三个人分别打开页面，三个人都说没问题

他们按流程走了一遍排查。

前端打开源码，标题、正文、按钮，全是波兰语字符串。

内容负责人对了一遍译稿，母语译者交付的版本和线上的一致。

技术负责人跑了一遍页面体检工具，没有任何警告。

三个人得出同一个结论：网站没问题，是用户那边的事。

这个结论在他们能用的所有工具下都成立，因为这三个人做的都是同一件事，用眼睛去看那份源码。而用户描述的是耳朵听到的东西，那条链路上还有一个环节，那个环节不在源码里，也不在任何一个人的检查动作里。

## 问题出在那一行谁都不会去改的模板代码上

他们的站是从一套英文模板改的。

翻译工作从页面正文开始，一直做到按钮和提示文案。

唯独文档最外面那一层的开头那行代码，没有人动过。

那行代码上写着这一页是英语，而页面上的每一个字都是波兰语。

这个矛盾在屏幕上完全没有表现，因为浏览器渲染字符时不问这一页是什么语言。

但是读屏软件问。它拿到这一页之后要做的第一件事，就是决定用哪一套发音规则把这些字符念出来，而它做这个决定的唯一依据，就是那行没人动过的代码。于是波兰语的字符串，被一台按英语规则工作的发音机器逐字念了出来。

## 把这件事翻译成一句能开会用的话

页面上的字有两个出口。

一个出口通向眼睛，走的是字体和排版这条链路。

另一个出口通向耳朵，走的是语言标签和发音引擎这条链路。

做多语言站的人在第一条链路上投入了全部精力，第二条链路的开关多数时候还停在模板的出厂值上。

这两条链路的检查方式完全不同，第一条用看的，第二条只能用听的。

而团队里没有人有听的习惯，验收清单上也没有这一项。所以这个开关可以在错误的位置上停很多年，期间网站改过版、换过模板、加过市场，谁都不会碰它，因为它从来没有让任何一个人看到过异常。

## 这件事只在多语言站上成立

英语站上这行代码写着英语，内容也是英语，两边天然对得上。

模板的出厂值就是英语，于是英语站永远不会踩这个坑。

这也是为什么整个前端行业对这件事的讨论度那么低。

它不是一个被忽视的问题，它是一个在英语世界里根本不存在的问题。

保哥这些年看下来，凡是英语站天然免疫的那一类坑，中文资料里基本查不到，因为最初的讨论就发生在英语社区。

这条判据在本站已经成立过很多次，比如小写折叠在土耳其语上会改坏词形 (https://zhangwenbao.com/minor-language-case-folding-lowercase-turkish-dotless-i.html)，比如非字母字符默认就是词边界 (https://zhangwenbao.com/minor-language-gender-inclusive-spelling-keyword-coverage.html)。它们的共同点是：错误的默认值在英语上恰好等于正确答案，于是没有人需要把它写成一条规则。语言标签是这一族里最贵的一条，因为它一错就是整页。

## 搜索引擎会自己重新判一遍语言，读屏软件为什么一次都不判？

## 先说清楚这两个消费方拿这个属性去干什么

同一个语言标签，页面上只写一次，读它的人不止一个。

搜索引擎读它，是为了给这一页归档到某个语言的索引里去。

浏览器读它，是为了决定断词规则、日期格式和默认字体。

读屏软件读它，是为了挑一套发音规则。

还有翻译提示、拼写检查、部分样式规则，也都在读它。

这些消费方拿到的是同一个字符串，但是它们对这个字符串错了之后的容忍度完全不一样，而这个差别才是整件事的关键。多数人默认所有消费方都一样宽容，因为在自己那一侧看不出区别。

## 引擎那一侧留了一道兜底

搜索引擎不会完全相信你写的语言标签。

它有自己的语言识别模型，会拿页面上的实际文本再判一次。

官方文档写得很直接，判定页面语言时用的是页面上可见的内容 (https://developers.google.com/search/docs/specialty/international/localized-versions)，而不是那些标记。

这意味着你把语言标签写错，引擎多半还是能把这一页归到正确的语言里去。

不是每次都能，短文本、混排页面、模板页上它会判错，页面被机器认成另一门语言 (https://zhangwenbao.com/minor-language-page-language-detection-misidentification-short-text.html)这一层的账本站另有一篇专门算过。

但是至少它有兜底动作。它拿到一个可疑的输入，会去找第二个证据来源，这在工程上叫防御性设计。写错语言标签在检索侧的后果是概率变差，不是确定性失败。

## 读屏那一侧一道兜底都没有

屏幕阅读器不做语言识别。

它拿到那个标签，直接去发音引擎列表里找对应的那一个。

找到了就用，找不到就退回用户设置的默认语音。

整个过程里没有任何一步会去看看这段文本实际上是什么语言。

这不是产品做得不好，是这么设计才对。

辅助技术必须可预测，用户按下朗读键，得到的结果每次都要一样。一个会自己猜测、自己纠正的读屏软件，对依赖它工作的人来说是灾难。所以它把语言标签当成指令而不是建议，你写什么它执行什么。这句话反过来说就是：这个属性在朗读这一侧是硬约束。

## 同一个错误，两侧的结算方式差在哪

检索侧：写错了，引擎自己判，多数情况下没事，少数情况下这一页的语言归档变差。

朗读侧：写错了，百分之百用错的发音规则念，每一次都错，每一个用户都错。

检索侧的损失是统计意义上的，看报表能看出趋势。

朗读侧的损失是确定性的，但是它不进任何一张报表。

一个是概率变差但可观测，一个是必然发生但不可观测。

这一对反差解释了为什么这件事能长期没人管：在能看见的地方它不严重，在严重的地方看不见。做技术决策的人手上的所有信号都来自第一侧，于是这个属性的优先级永远排在后面。

## 这条原语在别的地方也成立

凡是一个字段被两个系统消费，而其中一个有兜底另一个没有，风险就全部压在没有兜底的那一侧。

结构化数据里的语言字段 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)也是这个结构，填错了引擎会用正文纠偏，别的消费方不会。

商品数据源里的语言设置 (https://zhangwenbao.com/minor-language-product-feed-language-fields.html)同样如此，页面侧有三处声明可以互相印证，数据源侧只有后台一个下拉。

判断一个字段值不值得单独立规矩，看的不是它出现在几个地方，是它的消费方里有没有一个是不做校验的。

只要有一个，这个字段的正确性就必须在写入的时候保证，不能指望下游修。

保哥把这条当成排查多语言站的第一把尺子。拿到一个站，先找出所有只写一次、却被多方读取的字段，再问每个消费方错了之后会怎样。语言标签、货币代码、地区码、时区，这四个字段基本都符合这个特征，而它们出问题的方式惊人地相似。

## 页面里那些英文片段，读屏软件会按哪门语言的规则念？

## 先承认一件事：小语种页面上一定有外语

纯粹只有一门语言的商业页面几乎不存在。

品牌名是外语，产品型号是拉丁字母加数字，技术规格里全是英文缩写。

支付方式、物流公司、社交平台的名字，也基本都保持原样。

这些片段不是翻译遗漏，它们本来就不该被翻译。

用户搜的也是这些原样的写法，把它们翻掉反而是错的。日语站上那层专门标读音的小字 (https://zhangwenbao.com/minor-language-ruby-annotation-phonetic-layer.html)是另一种做法，它把读音写成了可见文本。

所以问题从来不是要不要有外语片段，而是这些片段被念出来的时候，机器该切换到哪一套发音规则。这个判断机器自己做不了，必须有人在页面上告诉它。

## 规范里专门为这件事留了一条

无障碍标准里有两条相邻的条款处理语言。

第一条管整页，要求页面的默认人类语言可以被程序确定，级别是最低的A级。

第二条管片段，要求页面里每一段跟主语言不同的文本，它的语言也可以被程序确定，级别是AA。

第二条的官方说明 (https://w3c.github.io/wcag/understanding/language-of-parts.html)里写得很清楚，它的目的就是让辅助技术和浏览器能用正确的方式呈现这段文字。

换句话说，规范制定者早就想到了这件事，还专门给了它一个编号。

有意思的是它的例外条款：专有名词、技术术语、以及已经进入了周围语言日常用法的外来词，可以不标。这个例外看起来很宽，实际执行起来很窄，因为判断一个英文词有没有进入波兰语的日常用法，本身就是一个需要母语者拍板的问题。

## 为什么这一条在英语站上几乎不触发

英语页面上的非英语片段有多少？

一个法语菜名，一个德语术语，一句拉丁语引文，通常就这些。

一整个电商站扫下来，可能只有几处。

于是这条AA条款在英语站上的实际工作量接近于零。

做无障碍改造的人从来没觉得它是个负担。

而在一个泰语电商站上，同一条条款的工作量是每个商品标题里都有若干处。同一条规则，同一个级别，同一个验收标准，成本差了三个数量级。这是本站反复出现的那条账：合规预算是按站算的，工作量是按语言算的。

## 不标会念成什么

把一个英文词交给按波兰语规则工作的发音引擎，它不会拒绝。

它会用波兰语的字母读音规则把这串拉丁字母念出来。

结果是一个不存在的词，听上去既不像英语也不像波兰语。

越是常见的品牌名，被念坏之后越难认，因为用户脑子里有一个正确的读音在等着比对。

反过来，把波兰语词交给英语引擎，出来的是那位用户在邮件里描述的东西。

两个方向的坏法不一样。外语片段念错是局部噪声，用户能靠上下文猜回来；整页语言错是全局失真，每一个词都不对，上下文本身也是坏的，没有任何可以用来纠错的锚点。

## 非拉丁书写系统的站上，这件事更容易被量出来

希腊语、泰语、印地语、希伯来语、阿拉伯语的页面有一个便利之处。

只要页面上出现拉丁字母，那基本就是一段外语。

不像波兰语或德语页面，拉丁字母既可能是本地词也可能是英文，肉眼分不出来。

这意味着在非拉丁站上，外语片段的数量是可以直接数出来的。

保哥拿这个思路做了一次实测，数据在下一节。

顺带说一句，这也是做小语种技术审计时一个很好用的取巧办法：凡是能靠书写系统本身把两类内容分开的语言，很多问题都可以用一行正则量化，而不必先做语言识别。这类语言在做技术验证时反而比拉丁系语言省事。

## 三十二个站实测下来，语言片段标注究竟做到了几处？

## 这次实测是怎么做的

保哥挑了四十个真实站点，覆盖十六个市场。

一半是当地头部电商，一半是当地主流媒体和公共机构。

取每个站的首页HTML，只看四件事：文档最外层写的语言、页面内部出现了几次语言标注、书写方向、图片有没有替代文本。

四十个里有三十二个正常返回，其余是拒绝访问或者超时。

其中一个返回了状态码202加零字节的空响应，这是典型的反爬兜底，剔除。

所以有效样本是三十一个站。样本不大，也不是随机抽样，但是这三十一个站合起来是这些市场上最主流的一批页面，如果这批页面都是同一个结论，那这个结论至少描述了行业的现状而不是个别水平。

## 第一列数字：整页那一处，大家都写了

三十一个站，文档最外层的语言标签全部存在。

取值也都对得上市场：波兰站写波兰语，泰国站写泰语，罗马尼亚站写罗马尼亚语。

有几个写成了语言加地区的完整形式，比如德国那家建材站和越南那家手机零售站。

写成完整形式不算错，只是把地区信息一起声明了。

这一列的结论很清楚：最低那条A级要求，主流站点已经全部达标。

这其实是个好消息，也符合预期。这一处是所有页面体检工具都会检查的项目，是所有建站模板都会预留的位置，也是所有教程的第一课。凡是能被工具自动检出、又只需要改一次的事情，行业最终都会做到。

## 第二列数字：片段那一处，几乎全军覆没

三十一个站里，页面内部一次语言标注都没有的，有二十八个。

剩下三个站看起来有：一家匈牙利媒体标了九十三处，另一家匈牙利媒体标了四十四处，芬兰那家公共广播标了四十四处。

把这三个站的标注逐条打开看，结论要改。

那两家匈牙利媒体标的九十三处和四十四处，取值全部是匈牙利语，跟页面本身的语言一模一样。

那不是片段标注，那是内容管理系统给每一个条目自动加的冗余属性，标了等于没标。

所以真正意义上给非页面语言的片段做了标注的，三十一个站里只有一个。这个数字保哥自己看到的时候也停了一下，因为它已经不能叫做落实率低，它是一个接近于零的值。而这一条不是可选项，它写在AA级里，而AA是欧盟那套无障碍法规实际引用的级别。

## 唯一那个做到了的站，身份很说明问题

做到了的是芬兰的公共广播机构。

它的四十四处标注里，三十七处是芬兰语，另外七处分别是瑞典语、北萨米语、英语、俄语、乌克兰语、卡累利阿语、索马里语和阿拉伯语。

那是它的多语言服务入口，每一个语言链接上都带着自己的语言标注。

这意味着当读屏软件走到那一行时，它会切换到对应的发音引擎，把那个语言的名字用那门语言念出来。

这是唯一正确的做法，也是这三十一个站里唯一一次出现。

它是公共广播机构，是受无障碍法规约束最直接的那一类主体，也是唯一一个把这件事做完的。这个对应关系比数字本身更有信息量：这件事目前的驱动力是合规义务，不是产品意识。商业站点在同一批页面上的表现是零。

## 第三列数字：那些页面上到底有多少外语

光说没标不够，还得证明确实有东西需要标。

在书写系统本身就能区分的九个站上，保哥数了正文里拉丁字母词的比例。

最高的是泰国一家电子产品零售站，两千六百九十一个拉丁词，占正文词数的百分之四十一。

那些词是什么？是笔记本、平板、耳机、配件这些品类词和产品线名称，也就是用户下单前反复读的那一批。

最低的是一家俄语新闻站，百分之一点一，二十七个词。

中间这一段的分布是：泰国另外两家站分别是百分之十九点六和百分之十一点六，印地语那家是百分之十七点七，希腊两家是百分之五点一和百分之四点八，希伯来语和阿拉伯语两家是百分之四点九和百分之五点八。这九个站的内部语言标注全部是零，也就是说，从二十七个词到两千六百九十一个词，全都会被按页面语言念出来。

## 数字、货币和缩写被念成什么，凭什么也按语言分叉？

## 发音引擎干活的第一步不是发音

把一串字符变成声音，中间有一步经常被跳过不谈。

引擎要先把非文字的东西展开成词，然后才谈发音。

数字要展开成数词，货币符号要展开成货币名，缩写要展开成全称。

这一步叫文本规范化，它是完全依赖语言的。

同一个字符串，换一门语言展开出来的词完全不同。

这一层的存在感很低，因为在英语里它工作得太顺了。数字展开成英语数词，美元符号展开成dollars，都是一一对应的简单映射。而这个简单性不是普遍规律，它是英语的语法特性带来的巧合。

## 数字在屈折语里不是一个词，是一族词

波兰语里数量词后面跟的名词要按数量取不同的形态。

一件、两到四件、五件以上，分属三种不同的写法。

俄语和捷克语有类似的规则，具体分界线各不相同。

这意味着展开一个数字加名词的组合，引擎必须先算出该用哪一档。

算错了，念出来是一个母语者一听就别扭的搭配。

本站另有一篇讲过只有复数形态的那一批词 (https://zhangwenbao.com/minor-language-plurale-tantum-category-keyword.html)在关键词表里的麻烦，那是文字侧的账。声音侧的账更直接：文字侧写错了用户可能看不出，因为他扫读时抓的是词干；声音侧念错了立刻就听得出来，因为韵律是连着的。

## 货币符号的读法各语言不一样

欧元符号在德语页面上念成Euro，位置在数字后面。

同一个符号在英语引擎那里念成euros，位置多半在数字前面。

更麻烦的是那些一符多义的写法，比如美元符号在不同市场指的不是同一种货币。

还有小数点和千分位这一对，两个地区正好写反，展开出来的数值可以差三个数量级。

价格是页面上最不能念错的一个数字。

而它恰好是整页里最依赖语言规则的一个字段，同时又最经常出现在没有语言标注的模板片段里，比如价格组件、比价表格、促销角标。这几处的共同点是：它们由代码拼出来，不经过翻译流程，也就没有人在那一步想起语言这件事。

## 缩写和单位是最容易被念成字母的一批

德语的举例缩写、法语的公司形式缩写、波兰语的街道缩写，各有各的展开规则。

发音引擎里带着这些规则，前提是它知道自己在念哪门语言。

语言标签一错，展开表就换了一本，缩写会被逐字母念出来。

单位符号同理，公斤、厘米、毫升在各语言里的读法不一样。

这一类内容在商品规格表里密度最高。

规格表还有一个特点：它通常是从数据源里渲染出来的，字段名和字段值分别来自不同的地方，很可能一个已经本地化了一个还没有。于是同一行文字里会出现两种语言，而这一行外面只有一个语言标注。

## 这一层为什么不能靠翻译流程解决

翻译流程处理的是词和句子。

数字、符号、缩写这些东西在译稿里通常原样保留，译者不会动。

母语审校也不会把它们标出来，因为在纸面上它们看着完全正常。

问题只在展开这一步才发生，而展开发生在用户的设备上，不在你的内容库里。

所以这不是一个翻译质量问题，是一个声明问题。

把语言声明写对，这一整层就自动正确了，一行代码解决几十种展开规则。把语言声明写错，你在译稿上下再多功夫也救不回来。这条投入产出比在本站的所有话题里都算极端的。

## 变音符号掉了之后，眼睛还能猜回来，耳朵为什么不能？

## 视觉这一侧的容错，来自读者本人

波兰语的带钩字母被写成不带钩的，母语者照样认得。

捷克语的软音符号掉了，读者也能靠上下文补回来。

越南语去掉声调，看着别扭但是能读。

这个容错能力不在你的系统里，它在人的脑子里。

所以文字侧的记号丢失，后果是观感变差和关键词匹配变差，不是不可读。

本站讲德语变音符号与关键词研究 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)那一篇算的就是这笔账：用户输入时经常不打记号，所以词表两套写法都要覆盖。那是一个覆盖率问题，解法是往表里加行。

## 听觉这一侧没有这个容错

发音引擎不猜。

那个带钩的波兰语字母和不带钩的那个，读音完全不同，一个接近英语的w一个是普通的l。

记号掉了，引擎照着剩下的字母念，出来的是另一个词。

听的人没有办法像看的人那样回退去比对字形，声音是流过去的。

捷克语的软音符号、越南语的声调，情况相同甚至更严重，因为声调直接决定词义。

这里的不对称非常干净：眼睛可以回看，耳朵不能。视觉信息是空间上并存的，你能来回扫；听觉信息是时间上串行的，过去了就过去了。所有在视觉侧靠读者脑补兜住的问题，到了听觉侧都要重新算一遍，而且都会变严重。

## 具体到几门语言上差多少

波兰语丢记号的字母有七个，其中几个丢了之后读音变化最大。

捷克语和斯洛伐克语的长音记号影响的是音长，丢了之后词义可能翻转。

越南语的声调记号 (https://zhangwenbao.com/vietnamese-seo-tone-marks-syllable-spacing-keyword.html)最极端，同一串字母配不同声调是完全不同的词，丢了声调等于把词打散。

希腊语的重音记号看起来只是个小撇，实际决定重音位置，念错了母语者会听成外国口音。

德语的变音字母有替代写法，两种写法读音相同，这一门反而最安全。

所以做多语言站的记号治理时，优先级不应该按语言的市场规模排，应该按记号丢失后的读音偏离程度排。越南语和泰语这类靠记号承载音位区别的语言必须排在最前面，德语这种有官方替代写法的可以往后放。这个排序跟按流量排出来的顺序几乎正好相反。

## 记号是在哪几步掉的

第一处是数据导入，编码不对就掉一批 (https://zhangwenbao.com/cyrillic-encoding-legacy-windows1251-utf8-indexing-cost.html)。

第二处是文件在不同电脑之间转手，地区设置会改写。

第三处是自动生成的字段，比如从标题派生的短描述，截断时正好切在组合字符中间 (https://zhangwenbao.com/minor-language-line-break-soft-hyphen-invisible-character.html)。

第四处是第三方组件回填的内容，它们经常做一次自己的规范化。

第五处是搜索和排序功能里的折叠处理，本来是为了匹配，结果把折叠后的结果写回了展示层。

前四处本站都单独写过，第五处最隐蔽：折叠是为了让带记号和不带记号的查询都能匹配上，这个动作本身完全正确，错的是把折叠后的字符串当成了可以展示的内容。匹配层的产物不能进展示层，这条规矩在声音这一侧的代价比在文字侧大得多。

## 替代文本是页面上唯一一段只被念、不被看的字，它该按什么标准写？

## 先确认这句话是不是真的

页面上绝大多数文字，人和机器读的是同一份。

标题、正文、按钮，用户看得见，抓取程序也取得到。

图片的替代文本不一样，正常情况下没有一个用户会看到它。

它只在两种场合被消费：抓取程序取走，或者读屏软件念出来。

所以它是整页里唯一一段专门写给非视觉通道的文字。

这个定位本站在讲非拉丁站的图片文件名与替代文本 (https://zhangwenbao.com/minor-language-image-alt-text-non-latin-script-search.html)那一篇里拆过六个位置各自的读者，那一篇算的是检索侧的账。这里补另一半：同一段字在声音侧的要求跟检索侧不完全一致，有几处甚至方向相反。

## 现有的写作规范全是按检索设计的

业内那些替代文本写作建议，来源基本一致。

写清楚图上有什么，带上关键词但别堆砌，长度控制在一百二十五个字符以内。

这三条都对，也都是从被检索这个用途推导出来的。

没有一条是从被念出来这个用途推导出来的。

而这两个用途对同一段文字的要求确实不一样。

检索侧要的是信息密度，词越准越好，语序无所谓，因为取词的程序不在乎你怎么组织句子。声音侧要的是可听懂，它必须是一个能顺下来的句子，语序和虚词都得在，否则听起来是一串关键词。

## 小语种上这个差别被放大了

屈折语里，一串没有语法连接的名词念出来会非常怪。

因为这些语言靠词尾表达关系，词尾一旦缺席，听的人拼不出这句话的结构。

英语在这一点上又一次天然占便宜，名词并列在英语里本来就是合法的表达。

所以照抄英语站的替代文本写法，在英语上是可接受的省略，在波兰语上是一段听不懂的碎片。

那一百二十五个字符的上限在这里同样要重算。

本站讲图片字段那一篇已经指出，同样字符数在不同语言里装的信息量差两三倍，非拉丁字形本身的成本 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)也在同一条链路上。声音侧还要再加一条：听的人对长度的耐受度比看的人低得多，一段十五秒的替代文本会让人直接跳过。所以小语种站上的合理区间是两头夹的，下限被语法撑着，上限被听觉耐受压着。

## 装饰性图片那一条，只有在声音侧才讲得通

规范里说纯装饰的图片应该留空的替代文本。

很多人不理解为什么留空比随便写点什么好。

从检索侧看，留空确实是浪费了一个字段。

从声音侧看，留空是唯一正确的做法，因为它让读屏软件直接跳过。

不留空的话，用户要听完一串对他毫无意义的描述才能到达下一个有效内容。

一个商品列表页上有三十个装饰性图标，每个都念一遍，用户放弃这一页的概率接近百分之百。这也是为什么这条规则写得如此绝对：它保护的不是信息，是时间。

## 品牌名和型号在这一段里怎么处理

替代文本里出现品牌名和型号是常态。

它们在声音侧的问题跟正文里的外语片段完全一样。

要么给这一段套一个语言标注，要么接受它被按页面语言念出来。

但是这里有个现实约束：替代文本是属性值，你没法在属性值内部再嵌一层标注。

能标的最小单位是承载这个属性的那个元素本身。

所以真正可行的做法是把语言混排从替代文本里拿掉，让它尽量只用一门语言把图上的东西说清楚，把品牌名和型号留在图注或者周边正文里，那两个位置可以嵌标注。这条约束是标记语言的结构决定的，不是能靠写作技巧绕过去的。

## 后台那三类工具，为什么一条都查不出这件事？

## 自动化检查工具能测的是格式，不是正确性

无障碍自动化规则 (https://act-rules.github.io/rules/de46e4)里，跟语言相关的有三条。

一条查文档最外层的语言标签是不是合法的语言标记。

一条查这个标签和它的另一种写法有没有对上。

一条查页面上任何带语言标注的元素，那个值是不是合法。

三条规则全部只验一件事：这个字符串在语言标记的注册表里存不存在。

没有一条能验它对不对。因为一个标签合不合法是可以查表判断的，而这一页实际上是什么语言，属于对内容的判断，自动化规则按设计就不做这类判断。这不是工具没做到，是它按定义就不该做。

## 把语言写成一个合法但错误的值，所有检查都是绿的

这是最要命的一点。

把波兰语页面标成英语，英语是合法标记，规则通过。

把希腊语页面标成希腊语的另一种历史写法，也是合法标记，规则通过。

把泰语页面标成泰语加一个不匹配的地区，仍然合法。

整条自动化链路上没有任何一环会说这不对。

而这三种写法在朗读时的表现分别是：整页换语言、可能落到错误的发音变体、多数情况没事。三种严重程度完全不同的错误，在报告里长得一模一样，都是没有问题。

## 页面体检工具与站长工具各自的盲区

页面体检工具读的是你发出去的源码。

它能告诉你这个属性有没有写，写的值是不是合法。

它不听声音，也没有发音引擎，所以它对结果一无所知。

站长工具那一侧连这个字段都没有，它关心的是收录和展现。

抓取诊断工具停在渲染这一步，渲染完就结束了，朗读发生在渲染之后。

三类工具的边界加起来，正好把这件事整个漏在外面。跟标题被替换那件事不同的是，那件事是工具里根本没有对应的字段；这件事是字段有、规则有、报告也有，只是所有规则按定义都测不到要害。后者更危险，因为它会给人一种已经检查过了的错觉。

## 那份自动化报告的通过率会误导决策

无障碍改造项目通常从自动化扫描开始。

扫描报告给出一个分数，团队按分数排优先级。

语言这一项因为格式都对，永远不会出现在待办列表里。

于是资源全部流向那些能被检出的项目，比如对比度和表单标签。

那些项目当然也重要，但是它们的严重程度未必比这一项高。

行业里有一份每年扫一百万个首页的公开报告 (https://webaim.org/projects/million/)，它统计的就是这类可自动检出的错误分布。这份报告有个必须理解的前提：它测的是能被自动测出来的那一部分，而这一部分跟真实体验受损的那一部分并不重合。把它当成行业现状的完整画像会推出错误的结论。

## 唯一能看到真相的地方是把耳朵接上去

这件事跟标题替换那件事有一个共同点。

所有在自己这一侧做的检查，都回答不了最终结果是什么。

唯一的办法是走到消费端，用消费端的方式消费一遍。

标题替换要去结果页上看，语言标注要用读屏软件听。

这两件事的成本都不高，难的是想到要做。

保哥这几年养成一个习惯，接手一个多语言站，先花二十分钟把三类页面听一遍。这二十分钟的信息量，通常比跑三份自动化报告还大，因为它是从用户那一侧取的证据，不是从你自己的源码里取的。

## 不懂这门语言，二十分钟怎么自己听出问题？

## 工具不用装，系统自带的就够

视窗系统自带讲述人 (https://support.microsoft.com/en-us/windows/complete-guide-to-narrator-e4397a0d-ef4f-b386-d8ae-c172f109bdb1)，苹果系统自带旁白 (https://support.apple.com/guide/voiceover/welcome/mac)，安卓自
TalkBack。

桌面上还有一个免费的开源读屏软件 (https://www.nvaccess.org/about-nvda/)，市场占有率很高，装起来只要几分钟。

这些工具的启动都是一组快捷键的事。

不需要学会用它做复杂操作，只需要让它从头念一页。

第一次开可能会被语速吓一跳，把语速调慢就好。

这一步的心理门槛远大于技术门槛。多数团队从来没打开过这类软件，不是因为难，是因为没人觉得这属于自己的工作范围。而它其实是这条链路上唯一的观测手段。

## 判据不是听懂，是听出这是哪门语言

你不需要懂波兰语。

你只需要判断：机器念出来的这一段，听起来像不像一门斯拉夫语言。

如果它听起来像一个英语母语者在念陌生单词，那语言标签就是错的。

这个判断不需要任何语言知识，普通人凭语感就能做。

把这一条写进验收清单，任何人都能执行。

这是整套办法里最关键的设计。凡是需要母语者才能执行的检查，都会因为排不到人而搁置；凡是不需要语言能力的检查，才有可能变成常规动作。所以判据要定在能不能听出语系这个粒度上，而不是定在念得准不准上。

## 要听的是哪三类页面

第一类是首页，它的模板最老，改动最多，语言标签最容易是历史遗留值。

第二类是商品详情页，它的外语片段密度最高，规格表和型号全在这里。

第三类是结账路径上的页面，因为这里出错的代价是订单。

三类各听两分钟，够了。

如果站上有多个语言版本，每个版本各抽一页。

抽样的重点不是覆盖率，是找出模板之间的差异。很多站的问题只出在某一套模板上，比如活动页用了另一套框架，那一套的语言标签停在出厂值。只听首页会漏掉这类问题，所以三类页面各听一遍比在一类页面上听十遍有用。

## 还要顺手记两件事

第一件是遇到英文片段时机器的表现。

它是切换了发音，还是用本地语言的规则硬念过去。

第二件是价格和数字被念成了什么。

这两处一旦不对，能顺藤摸瓜找到一批没有语言标注的模板组件。

把听到的异常记成一张两列的表：位置和现象。

这张表交给前端时不要写解决方案，只写现象。因为同一个现象可能有好几个成因，让实现那一侧去定位，比你隔着一层猜要快。这条在跨职能协作里通用，只是在这个话题上尤其明显，因为现象和成因之间隔着一整个发音引擎。

## 什么时候需要请母语者上场

前面那套办法能查出语言标签级别的错误。

查不出的是发音变体、重音位置、语调是否自然这一类。

这些需要母语者听，而且需要的是听力正常的母语者加上一次真实的读屏体验。

但是这一步应该排在后面，因为在语言标签还错着的时候请母语者来听，是浪费别人的时间。

先把确定性的错误修完，再去处理需要判断力的部分。

本站讲母语审校验收清单 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)那一篇给过一个类似的顺序：能用规则判定的先跑规则，剩下的才交给人。声音这一侧同样适用，而且分界线更清楚，因为语言标签对不对是二值的，念得自不自然是连续的。

## 按位置分的语言标注清单，以及哪些不归语言层

## 第一档：必须标，标错代价最大

文档最外层那一处 (https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/lang)，写页面的主语言，这是底线。

语言切换菜单里的每一个选项，标它自己指向的那门语言。

整段的外语引文和外语说明块，比如英文的技术规格段落。

用户生成内容里能识别出语言的部分，比如另一门语言写的评论。

这四处的共同点是：内容长度足够，念错之后损失明确。

其中语言切换菜单是投入产出比最高的一处，因为它总共只有几行，而它恰好是那位听不懂当前页面的用户唯一的出路。把出路念坏，等于把门锁上。

## 第二档：值得标，成本可控

商品规格表里成段的英文字段。

合作品牌的宣传语这类原样保留的外语句子。

页面上嵌入的外语视频标题和说明。

这一档的判断标准是：它是不是一个完整的语言片段，而不是一两个词。

是的就标，不是就放过。

标注是有成本的，成本落在模板改造和内容录入流程上。所以要有一条明确的下限，否则这件事会变成给每个英文单词都套一层标签，那样既做不完也会把模板搞乱。

## 第三档：不必标，标了反而更糟

已经进入本地语言日常用法的外来词，规范里明确列为例外。

单个的品牌名和产品型号，属于专有名词，同样在例外里。

本地人已经按本地读音在念的那批词，标成外语会让它念得更陌生。

这一档要靠母语者拍板，因为它问的是这个词在这门语言里算不算本地词。

这个判断没有客观标准，也不该由英语母语的顾问来做。

把这三档写进内容规范时，第三档要给例子而不是给规则，因为规则写不清楚。列十个已经本土化的外来词当样板，比写一段定义有用得多。

## 怎么把它变成一个不会退化的流程

把文档最外层那一处做成模板变量，绑定当前语言版本，不许写死。

把语言切换菜单的标注做进组件，一次做完全站生效。

把第二档的标注做成编辑器里的一个按钮，让内容团队自己能加。

把二十分钟的听测写进模板改动的上线清单。

最后一条最重要，因为这一层最容易被一次改版打回原形。

本站在讲写死在代码里的界面文案 (https://zhangwenbao.com/minor-language-hardcoded-ui-strings-pseudo-localization.html)那一篇里说过，凡是靠一次性改造达成的状态，都需要一道回归动作来维持。语言标注属于典型的一次做完、一次改版打回的东西，因为它藏在模板最外层，而模板最外层恰好是换框架时整块替换的部分。

## 哪些不归语言层，一句话交出去

键盘操作、焦点顺序、对比度、表单标签这些，属于通用的无障碍访问工程 (https://zhangwenbao.com/website-accessibility-seo-optimization-guide.html)，跟语言无关。

页面的整体信息架构和标题层级，归内容结构那一层。

发音引擎本身的音质、语速、口音选择，归操作系统和辅助技术厂商。

多语言站的地址结构、互指标签的对称写法 (https://zhangwenbao.com/hreflang-implementation-return-tags-x-default-canonical-mistakes.html)、地区定向，归国际化架构那一层。

搜索引擎怎么判断页面语言、判错了怎么修，本站另有专篇。

本篇只处理一件事：这一页上的字被机器念出来的时候，语言这一维有没有被正确地告诉机器。这一维是语言层的，其余的都不是。

## 常见问题解答

## 我们站的语言标签写的是对的，是不是就不用管这件事了？

整页那一处写对只解决了最低那一条，属于A级要求。片段那一条是AA级，实测三十一个主流站里只有一个做到。判断自己站上有没有欠账，最快的办法是数一下商品页上有多少个原样保留的外语词，再去源码里数有多少处语言标注。前者通常是几十，后者通常是零。

## 做无障碍改造是不是只跟视障用户有关，商业上划得来吗？

视障用户是最直接的受益方，但不是唯一的。语言标注还会影响浏览器的断词、日期与数字格式、默认字体选择，以及要不要弹出翻译提示。而在欧盟，这件事从2025年6月28日起对面向消费者的电商是法定要求，引用的标准
EN 301 549，它对应的正是AA级。这不是加分项。

## 把每一个英文单词都套上语言标注，是不是最保险？

不是，规范里明确给了例外：专有名词、技术术语、以及已经进入周围语言日常用法的外来词可以不标。全部套上会带来两个问题，模板复杂度失控，以及本地人已经按本地读音在念的词被强行切换成外语发音，反而更陌生。合理的下限是完整的语言片段，不是单个词。

## 用工具扫一遍能不能查出这类问题？

查不出要害。自动化规则里跟语言相关的三条，全部只验语言标记是不是合法值，没有一条能验它跟内容对不对得上。把波兰语页面标成英语，三条规则全部通过。这类错误的特征就是格式完全合法，所以在任何一份自动化报告里都是绿的。

## 我们用的是建站平台，模板改不了怎么办？

先确认它是真的改不了还是没找到入口。多数平台的语言设置在站点级别，改一次全站生效，问题往往出在多语言插件与主题模板各写了一份，两份不一致。如果确实动不了，优先保住两处：文档最外层的语言，以及语言切换菜单。这两处的收益占整件事的大半。

## 页面上的价格和数字被念错，跟语言标签是同一件事吗？

是同一件事的下游。发音引擎要先把数字、货币符号、缩写展开成词，这一步完全依赖语言，展开表跟着语言标签走。标签错了，整本展开表就换了，价格会被按另一门语言的规则念出来。所以这一层不需要单独治理，把标签写对就自动正确了。

## 这件事对搜索排名有没有直接影响？

直接的排名影响很弱，引擎判定页面语言时主要看可见内容，不会因为这个属性写错就把你降下去。真正的影响在两处：一是页面语言被判错时，你在对应语种检索里的可见度会掉，那是另一层的账；二是无障碍质量已经是很多市场的采购与合规门槛，那是订单层面的账。

## 权威参考资料



## 你能不能在这门语言上做站内搜索，取决于几个志愿者今年还有没有提交代码

- URL：https://zhangwenbao.com/minor-language-open-source-dictionary-maintenance.html
- 分类：小语种SEO
- 发布：2026-07-14  |  更新：2026-07-31
- 摘要：站内搜索、拼写容错、断词与推荐都踩在几份公共语言数据上。讲清哪些语言的词典停在十四年前、词条数为什么不能横向比、哪些能力能自己补哪些补不了。
- 关键词：技术SEO,多语言SEO,站内搜索,小语种SEO

> **TLDR**：摘要：同一套站内搜索，换一门语言就变笨，差别不在你的代码里。保哥把那个公共词典仓库逐门语言查了一遍：越南语、爱沙尼亚语、斯瓦希里语的词典内容最后一次改动是2012年，而那次改动是挪目录，不是加词。这一层的能力由几个志愿者的提交记录决定。

> 摘要：同一套站内搜索，换一门语言就变笨，差别不在你的代码里。保哥把那个公共词典仓库逐门语言查了一遍：越南语、爱沙尼亚语、斯瓦希里语的词典内容最后一次改动是2012年，而那次改动是挪目录，不是加词。这一层的能力由几个志愿者的提交记录决定。

## 同一套站内搜索，为什么换一门语言就明显变笨？

## 一家做乐器配件的站，波兰站好用，爱沙尼亚站不好用

有个客户做乐器配件，吉他弦、拾音器、琴包、谱架这几条线。

他们的站内搜索是同一套服务，同一份配置，连索引模板都是复制过去的。

波兰站上线之后表现不错，用户搜单数搜复数、搜带格尾的形态，都能召回。

爱沙尼亚站上线之后，搜索转化率只有波兰站的三分之一。

技术那边查了两周，索引正常、分片正常、查询语句正常、日志里没有报错。

最后是运营发现的：用户搜一个带格尾的词，返回零结果，把词尾去掉再搜，商品全出来了。同一套系统在两门语言上的差别，不在他们自己写的任何一行代码里。

## 再往下查一层，希腊站的问题又是另一种

同一批人接着看希腊站。

希腊站的召回没问题，词形变化基本能对上。

出问题的是拼写容错，用户少打一个重音符号，结果就完全不一样。

更奇怪的是，这个站的相关词推荐几乎不工作，推出来的永远是同一批热门商品。

三个站，三种毛病，而技术栈是同一套。本站另有一篇算过尺码这类值不是翻出来是算出来的 (https://zhangwenbao.com/minor-language-size-unit-conversion-keyword.html)，那一篇的错出在没人负责的一道算术上，这一篇的错出在没人负责的一份文件上，两笔账的形状很像。

到这一步，问题已经不能用配置来解释了。真正的差别在于，这套系统在每门语言上调用的是不同的外部资源，而那些资源的成色差得极远。

## 你的语言能力不是你的，是借来的

这件事说破了很简单。

你的搜索、拼写纠错、断词、排序、自动补全，在每一门语言上都要依赖一份语言数据。

这些数据你没写过，你的供应商也没写过。

它们躺在几个公共仓库 (https://github.com/LibreOffice/dictionaries)里，由一批志愿者维护，免费，随便用。

英语站上的人从来不需要想这件事，因为英语那几份数据永远是完整的、最新的、被无数人盯着的。

换成小语种，这条假设立刻不成立，而且不成立的程度差别极大，有的语言比英语还认真，有的已经停在十四年前。

## 这跟工具没数据不是同一件事

这里要跟一个老问题划清界限。

本站写过关键词工具在小语种上返回零 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)的那笔账，那是数据缺口，是别人没采集你的市场。

这一篇讲的是另一层：不是没人给你数据，是处理这门语言的能力本身缺了一块。

两者的表现也不一样。前者是你查不到量，后者是你的系统跑出来的结果不对。

前者可以靠自己数、靠日志补，后者补不了，因为缺的是算法和词库，不是样本。

把这两件事混在一起，最常见的后果是团队一直在补数据，而系统那一侧的能力缺口从来没被看见过。

## 这一层为什么值得单独拿出来讲

小语种SEO的讨论里，绝大部分注意力在两个地方：词怎么选，内容怎么写。

再往上一点是引擎那一侧，收录、排名、算法更新。

底下这一层几乎没人提，因为它不在任何一个岗位的职责里。

技术团队认为语言的事归本地化，本地化团队认为系统的事归技术，双方都对。

而它的影响面偏偏很大：站内搜索、筛选器、拼写容错、相关推荐、自动补全、断词换行，这几件事全部踩在同一层地基上。

更要命的是，它坏掉的时候不报错。系统照常返回结果，只是结果差一点，而差一点的东西没有任何监控会告警。

## 你的站在一门语言上的能力，具体是从哪几个文件来的？

## 第一份：拼写词典，管的是这个词形算不算合法

最基础的一份是拼写词典。

它由两个文件组成，一个装词根，一个装词缀规则 (https://github.com/hunspell/hunspell)。

装词根的那个文件第一行写着词条数，后面每行一个词，词后面挂着这个词能接哪些规则。

装规则的那个文件写着每条规则怎么加词尾、什么条件下能加。

浏览器里的红波浪线、办公软件的拼写检查、很多站内搜索的容错，用的都是这一份。

它的重要性在于，它是唯一一份把这门语言的形态知识写成机器可读格式的公共资产，别的能力大多建在它上面。

## 第二份：断词规则，管的是长词怎么折行

第二份是断词文件。

它规定一个词能在哪几个位置断开加连字符。

德语、芬兰语、匈牙利语这类长词多的语言，没有它排版会很难看。

本站算过一笔账，为了让长词在手机上不撑破，前端往标题里塞了个看不见的字符 (https://zhangwenbao.com/minor-language-line-break-soft-hyphen-invisible-character.html)，那篇讲的正是断词缺位之后的补救动作。

断词文件的特点是它跟拼写词典分开维护，一门语言可能有词典没断词。

而这一格缺不缺，前端通常要到上线之后被设计师投诉才会发现。

## 第三份：同义词库，管的是相关词推荐

第三份是同义词库。

它给每个词列出近义词，办公软件的同义词功能和一部分搜索的查询扩展用的是它。

希腊站那个相关推荐不工作的毛病，根子就在这里。

这一格的缺失率是三份里最高的，因为它最不影响基本功能，最容易被排在后面。

它缺了不会让任何东西报错，只会让推荐质量默默降一档。

而推荐质量这种东西，除非你拿两个语言站并排比，否则永远看不出来。

## 第四份和第五份：词干器与分词器

再往上是两个算法层的东西。

词干器负责把一个词的各种形态还原到同一个词根，搜索能不能召回不同词形靠它。

爱沙尼亚站那个搜带格尾就零结果的毛病，属于这一层。

分词器负责在没有空格的文字里切出词，泰语、日语、中文这类语言必须有它。

这两样都不在词典仓库里，它们在别的项目里，各有各的语言覆盖清单。

关键在于三份清单互相不重合：有词典不等于有词干器，有词干器不等于你的搜索服务集成了它。

## 第六份：区域格式数据，管的是日期货币怎么写

最后一份跟前面五份的性质完全不同。

它是公共区域数据，规定日期、数字、货币、单位在每个地区该怎么写。

操作系统、浏览器、开发框架的格式化函数全从这里取值。

把它放在这里，是因为它跟前面五份构成了一个很有意思的对照组。

同样是公共资产，同样免费，同样没人给你SLA。

但它的成色跟词典那几份完全不在一个水平上，后面会专门算这笔账，那个对比是这一整篇里最值得记住的部分。

## 这些文件最后一次有人动，是什么时候？

## 先说清楚这次实测怎么做的

保哥把那个公共词典仓库整个拉了一遍。

仓库里有67个语言目录，一共859个文件，葡萄牙语占了两个目录，巴西和葡萄牙分开。

然后挑了27门语言逐个查：这门语言有没有词典、有没有断词、有没有同义词库、词条数多少、最后一次提交是什么时候、提交的人是谁、那次提交改了什么。

查最后一次提交这一步有个坑，目录级的提交记录会被一些无关的批量操作污染，比如统一改个标签、修个注册文件。

所以真正有意义的是词典文件本身的最后一次改动。

保哥两个都查了，下面的结论用的是后者，因为它反映的才是内容有没有被更新过。

## 最上面那一档：今年还在提交

先说活着的。

法语和罗马尼亚语最近一次更新在2026年7月，波兰语和立陶宛语在2026年6月，乌克兰语在2026年2月，匈牙利语在2025年12月，泰语在2025年9月。

这七门语言的共同点是，最近一次提交做的是实事：升级到上游的新版本、加词、修编码问题。

匈牙利语那一条尤其有意思，提交人是那套拼写检查方案的作者本人，版本号写着1.9。

这套方案当年之所以被写出来，正是因为匈牙利语一个词能派生出几千种形态 (https://zhangwenbao.com/hungarian-seo-eighteen-cases-vowel-harmony-keyword.html)，穷举词表的老办法根本不适用。

三十年过去，这门语言在这个仓库里的那一格，还是他在管。

## 2026年更新的那四门语言，出自同一个人之手

还有一个细节，保哥是把提交人这一列并排看的时候才发现的。

法语、罗马尼亚语、波兰语、立陶宛语这四门语言，2026年那次更新的提交人是同一个名字。

换句话说，四门语言在这一年里的唯一一次维护，来自一个人的一轮批量同步。

这不是说这个人做得不好，恰恰相反，没有他这四门语言今年一次更新都没有。

但它说明了这一层的供给结构：不是四个语言社区各自在维护，是一个志愿者顺手把上游的新版本搬了过来。

你的技术栈在这四门语言上的能力上限，实际上系在这一个人的空闲时间上。

## 中间那一档：停在五到十年前

往下一档更常见。

希腊语的词典文件最后一次改动在2015年9月，提交信息里写着更新到0.9版。

十一年过去，版本号还没走到1.0。

希伯来语停在2017年，冰岛语停在2016年，克罗地亚语停在2018年，塞尔维亚语停在2019年。

拉脱维亚语最后一次是2020年，捷克语是2021年，印尼语是2023年。

保加利亚语那一条最像黑色幽默：目录级最后一次提交是2020年1月，改的内容是把一个单词的拼写错误修正过来，而那个被拼错的单词正好是语言这个词本身。

## 最底下那一档：内容停在2012年，而且那次不是加词

最底下的三门是越南语、爱沙尼亚语和斯瓦希里语。

这三门语言的词典文件，最后一次改动都是2012年10月16日，提交信息写着把词典目录结构往上挪一层。

这是一次仓库重构，不是内容更新。

目录级的最后一次提交要晚八天，2012年10月24日，提交信息是删掉散落的打包配置文件。

保哥把那次提交点开数了一下：它一口气改了47个目录，新增0行，删除0行，删的全是零字节的空文件。

所以严格说，这三门语言的词典内容已经十四年没有任何人加过一个词，而这十四年里，越南的电商市场从零长到了今天这个规模。

## 把这张表按你的市场清单排一遍，只要二十分钟

这件事的好处是它完全可查，不需要任何工具和权限。

打开那个仓库，找到你要做的语言目录，看文件列表和提交历史。

三个数字就够：词典文件最后改动时间、有没有断词文件、有没有同义词库。

二十分钟能查完十门语言。

查完之后你会得到一张分档表，而这张表能直接改写排期。

停在2012年那一档的语言，别指望站内搜索开箱可用，要么预算里加一笔自建词表的钱，要么把搜索这块功能降级处理。

还有一个值得顺手记下的动作：看提交人这一列有几个不同的名字。

一门语言的提交记录里如果长期只有一个名字，说明它是单人维护，那个人一旦不做了，这一格就会停住，而不会有人来接。

如果有三五个名字轮换，说明背后有个小社区，抗风险能力完全不同。

这一列不需要额外查，翻提交历史的时候顺眼就看到了，但它比任何一个数字都更能预测这门语言未来两年的走向。

## 词典文件存在，等于这门语言被支持了吗？

## 越南语那份词典，打开一看根本不是词表

越南语的词典文件第一行写着6631。

这个数字本身就很可疑，因为同一批语言里波兰语是348892条，希腊语是828806条。

保哥把文件头几百行拉出来看了。

前二十几行是ABC、ASCII、GIF、HTML、JPEG、PDF、PNG、RAM、URL这样的缩写。

再往下是a、ai、am、an、ang、anh、ao、au、ba、bai、ban这样的条目。

这不是一份词表，是一份音节表。越南语的正字法把词写成一个个带声调的音节，这份文件收的是合法音节，而不是用户会搜的词。它能判断一串字母是不是越南语的合法音节，但你想用它做词形还原、同义扩展或者品类词识别，一个都做不到。

## 而它的规则文件里只有变音等价，一条词缀规则都没有

再看配套的规则文件。

整个文件的实质内容是十几条映射声明，作用是把带各种声调符号的元音归为一组。

换句话说，它只做了一件事：告诉系统这几个字母长得不一样但算同一个。

这确实是越南语最需要的一条规则，本站写越南语声调记号 (https://zhangwenbao.com/vietnamese-seo-tone-marks-syllable-spacing-keyword.html)那一篇算过，丢了声调等于把词打散。

但一条词缀规则都没有，意味着这门语言在这一层拿到的是最低限度的支持。

对做电商的人来说，结论很直接：越南语站的搜索容错要自己建，别指望这份文件。

## 土耳其语相反，词条不多但文件有36兆

另一个极端更有意思。

土耳其语的词典第一行写着75909，比波兰语少得多。

可这个文件有36136702字节，也就是36兆，是波兰语那份的将近七倍。

保哥把文件头拉出来才明白怎么回事：每个词根后面挂着上百个规则编号，一行动辄几百字符。

再看规则文件，里面是几万条一次性的后缀规则，每条只生成一个特定的后缀串，长的能到十几个字母。

这是把黏着语的形态硬展开成了一张巨表。本站写土耳其语后缀堆叠 (https://zhangwenbao.com/turkish-seo-agglutinative-suffix-stacking-keyword.html)那一篇讲的是这门语言怎么把一个词接成另一个词，这份文件就是那件事在工程侧的账单：能用，但代价是三十六兆和一张没人看得懂的规则表。

## 所以词条数这一列不能横向比

看到这里，词条数这个指标基本可以扔掉了。

希腊语82万条，是因为它把大量形态直接展开成了独立条目。

波兰语34万条配一套精简的规则，实际覆盖的形态远多于条目数。

越南语6631条，因为它收的是音节。

土耳其语7万条却有36兆，因为规则全在词条后面。

四门语言的数字完全没有可比性，把它们放进同一张表按大小排序，得到的排名是无意义的。真正该看的是三件事：规则文件里有没有真正的形态规则、最后改动时间、有没有配套的断词与同义词库。

## 缺席的那两列，比数字更能说明问题

断词文件这一列，土耳其语、越南语、希伯来语、波斯语、印地语、斯瓦希里语全部空着。

同义词库那一列空得更厉害：法语、捷克语、克罗地亚语、塞尔维亚语、立陶宛语、爱沙尼亚语、希腊语、土耳其语、越南语、希伯来语、波斯语、印地语、斯瓦希里语都没有。

法语出现在这份缺席名单里，很多人会觉得意外。

这恰好说明这一层的成色跟语言的商业价值没有必然关系，它取决于有没有人愿意做这件具体的事。

还有一整类语言连目录都没有：马来语、格鲁吉亚语、阿塞拜疆语、威尔士语在这个仓库里找不到。

要注意的是，这四门语言在别的地方并不算冷门，它们在区域格式数据里全部是最高等级，这个反差正好引出下一节。

## 为什么格式数据那一层全达标，词典这一层却差了十四年？

## 先看格式数据那一层的实测数字

公共区域数据里有一份覆盖等级清单 (https://cldr.unicode.org/index/cldr-spec/coverage-levels)，它给每个地区标了三档：完整、中等、基础。

保哥把那份清单拉下来数了一遍：一共174个条目，其中完整档104个，中等档13个，基础档57个。

然后拿前面那27门语言去比对。

结果是全部落在完整档，一个例外都没有。

连仓库里连目录都没有的马来语、格鲁吉亚语、阿塞拜疆语、威尔士语，在这份清单里也是完整档。

马耳他语是少数几个落在基础档的，而它的使用人口只有几十万，这个位置合理。

## 同一批语言，两层的成色差出一个数量级

把两组数字并排放，反差非常刺眼。

日期怎么写、货币符号放哪边、数字用什么分隔符、星期从哪天开始，这些在104门语言上是完整的、有版本节奏的、有人专职审核的。

而同一批语言里，有三门的拼写词典内容停在2012年。

这两层都是免费的公共资产，都没有人给你任何承诺。

差别在供给结构：格式数据那一层背后是一批科技公司在投人投钱，因为他们自己的操作系统和浏览器要用；词典这一层背后是个人。

一个是被大公司的产品需求拉着走，一个是被某个母语者的业余时间推着走，成色差一个数量级不奇怪，奇怪的是几乎没人意识到它们是两回事。

## 这条差异直接决定了你该信哪一层

结论很实用。

凡是靠区域格式数据实现的功能，可以放心用默认值：日期格式、数字格式、货币写法、单位偏好、星期起始。

本站写结构化数据里的语言与地区字段 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)那一篇讲过正文本地化而标记走国际格式的分工，靠的就是这一层的可靠。

凡是靠词典和算法实现的功能，都要先查再用：拼写容错、词形还原、同义扩展、断词、自动补全。

这条判据能省掉大量无谓的排查。

爱沙尼亚站那个搜索问题，如果一开始就按这条分类，两周的排查可以压缩到二十分钟。

## 为什么这一层的问题特别难被发现

还有一个结构性的原因。

这一层的缺失不产生错误，只产生退化。

搜索还能搜，只是召回少了一批；推荐还在推，只是推得平庸；换行还在换，只是断点难看。

监控系统盯的是错误率、响应时间、可用性，这三样一个都不会动。

而人眼的对比基准通常是主语言站，主语言站好用是常态，小语种站不好用会被归因成用户不习惯、市场不成熟、内容还不够多。

本站写过按语言拆开看数据的口径 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)，那条方法在这里同样是唯一的破法：全站平均值永远是正常的，只有把搜索转化率按语言拆开，那个三分之一才会跳出来。

## 把这一层写进技术选型的验收项

更长远的做法是把它变成一条选型标准。

选站内搜索服务的时候，别只问支持多少种语言。

要问的是：这几门语言各自集成了哪一层能力，词干还原用的是哪一份实现，拼写容错的词库来源是什么，多久更新一次。

供应商答不上来的时候，通常不是保密，是他们自己也没查过。

这一问的价值不在于能问出多少，在于它把一个隐形依赖变成了合同里的一行字。

保哥的经验是，问过这个问题的项目，后面遇到搜索问题时的排查路径会短很多，因为大家一开始就知道下面垫着什么。

## 站内搜索、拼写纠错、自动补全，各自吃的是哪一份资源？

## 词干还原：两份清单加起来才是你的真实覆盖

词干还原有两个常见来源。

一个是那套开源的词干算法项目 (https://snowballstem.org/algorithms/)，保哥数了一下它的算法页面，一共37个条目，其中有几个是英语的历史算法变体，实际语言数比这个略少。

另一个是搜索引擎自带的语言分析器 (https://www.elastic.co/docs/reference/text-analysis/analysis-lang-analyzer)，主流那家的内置清单是36个。

两份清单不完全重合，比如保加利亚语和拉脱维亚语在搜索引擎那份里有，在词干算法项目那份里没有。

而越南语、希伯来语、斯洛文尼亚语、斯洛伐克语、乌克兰语、克罗地亚语、冰岛语、斯瓦希里语在两份清单里都找不到。

爱沙尼亚语在两份里都有，所以那个客户的问题不是没有词干器，而是他们的索引模板压根没有为爱沙尼亚语指定分析器，全站用的是默认那一套。这是这一层最常见的实际故障：能力存在，但没人打开它。

## 分词：只有少数几门语言需要，但缺了就是硬伤

分词跟词干还原完全是两回事。

它只在没有空格的文字里成为问题：泰语、老挝语、高棉语、缅甸语，加上中日韩。

这几门语言的分词依赖的是另一套词典，装在国际化组件 (https://unicode-org.github.io/icu/userguide/boundaryanalysis/)里。

本站写泰语没有空格 (https://zhangwenbao.com/thai-seo-no-spaces-word-segmentation-keyword.html)那一篇说过，标题里找不到一个空格，切在哪儿由引擎的词典说了算，站内搜索这一侧的道理完全一样，只不过说了算的换成了你自己集成的那份词典。

这一格的特点是没有中间状态：有分词就基本可用，没有就完全不能用。

好消息是这几门语言的分词词典维护得都不错，泰语那一格去年还在更新。

## 拼写容错：吃的是词典，所以停更的语言这一格最弱

拼写容错有两种实现。

一种是纯字符距离，跟语言无关，谁都能用，代价是会把不相干的词也拉进来。

另一种是带词典的，先判断这个词形合不合法，再在合法词里找最近的，效果好得多。

后者直接吃那份拼写词典，所以词典停在哪一年，这个功能的知识边界就停在哪一年。

具体表现是新词全军覆没：近几年才出现的品牌名、品类词、技术词，在系统眼里全是拼写错误，于是被纠正成了某个形近的老词。

希腊站那个重音符号少打一个就出不来的毛病，属于同一层：那份词典把带重音和不带重音当成两个词，而它十一年没更新过，用户的实际输入习惯早变了。

## 自动补全：它的语料通常不是这些文件

自动补全要单独说一句，因为它常被误归到这一层。

自动补全的语料主要来自你自己的查询日志和商品标题，跟公共词典关系不大。

所以它在小语种上的问题往往不是资源缺失，而是冷启动：新市场没有足够的查询量，补全列表空着。

这一格的解法也不同，是拿商品标题和分类名先灌一批种子，等真实查询积累起来再切换。

把它跟前面几格分开，能避免一个常见误判：看到补全不好用就断定这门语言的支持有问题，实际上只是站太新。

## 断词换行：影响的是版式，但根子在同一层

最后一格是断词。

断词文件缺席的语言，长词在窄屏上要么撑破容器要么被硬切。

浏览器有一个按语言自动断词的能力，它背后用的正是这套断词规则，所以缺了文件这个能力就无效。

前端常见的补救是往词里塞不可见字符，本站算过这个做法的代价：那个字符会进搜索索引，也会被复制走。

更稳的做法是给这几门语言单独调版式，别靠断词兜底。

这一格的判断很简单：查那个仓库里有没有以断词开头的那个文件，两分钟出结果。

## 哪些能力你能自己补，哪些补不了？

## 能补的第一类：同义词表

同义词库缺失是最好补的一格。

你不需要覆盖整门语言，只需要覆盖你卖的那几个品类。

做法是从三处捞词：站内搜索日志里的零结果查询、客服工单里的用户原话、竞品页面上的品类词写法。

一个中等规模的品类，两三百行就能明显改善召回。

本站写母语审校验收清单 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)那一篇给过一个顺序，能用规则判定的先跑规则，剩下的交给人，建同义词表这件事正好适用。

成本上，一门语言两天，之后每季度补一次，是保哥见过性价比最高的语言层投入之一。

## 能补的第二类：形态映射表

词干器缺失也能补，但补的方式不是写算法。

做法是维护一张形态映射表，把品类词的常见变形全部指向同一个词根。

这张表跟同义词表可以合并管理，因为在检索层它们的作用一样。

规模上，一个电商品类通常一两百行够用，别一上来就想覆盖整门语言。

要覆盖的是高频那几十个品类词的形态，不是词典里所有的词。

本站写过好几门语言的格变化和词尾，那些文章里列的形态表，本质上就是这张表的语言学版本。

## 能补的第三类：停用词与查询清洗

第三类是停用词表和查询清洗规则。

这一格几乎不需要语言学知识，从日志里按频次排序就能得到大半。

要注意的是别照抄英语那套逻辑，有些语言里的高频虚词恰好是品类词的一部分。

清洗规则里最值钱的一条是变音符号的等价处理，用户经常不打记号，两种写法要能互相召回。

本站写德语变音符号 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)那一篇算的就是这笔账，页面侧和检索侧的处理方向是一致的。

这一格的投入通常是半天，收益立刻可见。

## 补不了的第一类：分词

分词是补不了的。

它需要一份大规模的词典加上一套概率模型，不是几百行表能解决的。

如果你要做的语言在这一格缺席，实际选择只有两个：换一个已经集成了分词的搜索服务，或者接受搜索功能降级。

降级的具体做法是把搜索入口做窄，主推分类导航和筛选器，别让用户依赖搜索框。

这个决定听起来消极，但它比让用户在搜索框里连续失败三次要好得多。

好在需要分词的语言就那么几门，而且它们的分词资源反倒是维护得比较好的。

## 补不了的第二类：排序规则

字母排序规则也补不了，但好消息是它几乎不缺。

排序规则住在区域格式数据那一层，也就是成色最好的那一层。

本站写过两套字母的排序要配几套 (https://zhangwenbao.com/bulgarian-serbian-seo-cyrillic-latin-dual-script.html)，那些差异在标准数据里都已经写好了。

你要做的只是别用二进制排序，把排序交给按语言的排序函数。

这一格的常见故障不是资源缺失，是代码里图省事直接按字节比大小。

那样排出来的结果在带变音符号的语言上全是错的，而它是一个改一行代码就能解决的问题。

## 决定要不要做一门语言之前的那三十分钟

## 第一步：查词典那一格的三个数

打开公共词典仓库，找到这门语言的目录。

记三件事：词典文件最后一次改动的年份、有没有断词文件、有没有同义词库。

年份是最重要的一个。

近三年内有实质更新的，这一层可以当作可用；停在五年以上的，按缺失处理；停在十年以上的，直接把搜索容错这块从需求里划掉。

顺手看一眼规则文件有多大、里面是不是真的规则，越南语那种只有映射声明的情况一眼就能认出来。

这一步三分钟一门语言。有个小技巧能省不少事：直接看目录里的文件名列表，以断词二字开头的那个文件在不在，一眼就能确认，不需要点进提交历史。词典文件的体积也顺手记一下，它跟词条数一起看能大致判断这份词典是规则驱动还是硬展开的。

## 第二步：查算法那一格在不在两份清单里

第二步是查词干还原和分词。

去词干算法项目的算法列表看有没有这门语言，再去你打算用的搜索服务的语言分析器文档里看一遍。

两份都有，最省事。

只有一份有，要确认你的索引模板是否真的指定了它，这一步最容易漏。

两份都没有，就要评估自建形态映射表的成本，或者接受降级。

是不是需要分词，看这门语言写字用不用空格，这一条不需要查。

## 第三步：查格式那一层的档位

第三步查区域格式数据的覆盖等级。

完整档的语言，日期、数字、货币、排序全部可以放心用默认。

中等档和基础档的语言要多留一个心眼，某些细粒度的格式可能是回退来的。

这一步一分钟就能查完，而且结论通常是好消息。保哥查过的市场里，只有极少数几门语言落在基础档，而它们的共同点是使用人口都在百万以下，跟大多数跨境生意要做的市场没有交集。

值得记住的是它跟第一步的结论经常相反：格式全绿而词典全红，是小语种最典型的画像。

把两张结论并排写进立项文档，比任何一句这门语言支持得还行都有用。

## 第四步：看这门语言的公共内容体量

最后一步是看这门语言的公共知识体量，最方便的指标是维基百科的条目数和活跃编辑人数 (https://stats.wikimedia.org/#/all-wikipedia-projects)。

要看的是两个数一起看，只看条目数会被带偏。

威尔士语有28万多条条目，活跃编辑只有一百多人。

冰岛语6万条，活跃编辑两百多。

马耳他语更极端，条目不到8千，活跃编辑44人。

这个数字的用处不是判断市场大小，是判断你能不能找到本地语料、本地审校和本地外链资源，本站写过按母语人口排优先级会排错 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)的那笔账，这一列正是那套算法里最容易被忽略的输入。

## 把四步的结论写成一句话结论

四步做完，每门语言可以压成一句话。

词典近三年更新、有词干器、格式完整档，这门语言的技术层可以按英语站的默认预期做。

词典停更但有词干器，搜索能跑，容错要自己补，预算里加两天。

词干器缺席，搜索按降级设计，导航和筛选器要做厚。

需要分词而分词缺席，这门语言的搜索框可以先不做。

这四句话写进立项文档的技术风险那一栏，是保哥这些年见过投入产出比最高的三十分钟。

## 三个把结论带偏的常见误判

## 把维基条目数当成语言的活跃度

第一个误判前面提过一次，这里展开。

很多语言版本的维基条目是机器人批量生成的，一个模板套着数据库刷出几十万条地理条目。

威尔士语那个比例就是典型：条目很多，人很少。

这类语言的条目数虚高，但它反映不出有多少人在用这门语言写东西。

更接近真相的指标是活跃编辑数和编辑总数。

本站写过怎么手工估一门语言的内容供给有多稀缺 (https://zhangwenbao.com/minor-language-qa-long-tail-content-value-ai-era.html)，那套办法比任何单一数字都准，代价是要花一个小时。

## 把格式数据的完整档当成全套支持

第二个误判更常见，也更贵。

有人查到这门语言在区域数据里是完整档，就下结论说技术栈支持得很好。

这两件事之间没有任何关系。

马来语、格鲁吉亚语、阿塞拜疆语、威尔士语在格式数据里全是完整档，在词典仓库里连目录都没有。

格式数据管的是怎么把一个日期写出来，词典管的是怎么理解一个词，前者不需要语言学知识，后者需要，而且需要持续投入。

把这两层分开问，是这一整篇里最值钱的一个习惯。

## 把供应商说的支持一百种语言当成能力保证

第三个误判发生在采购环节。

云服务的宣传页上写着支持一百多种语言，这句话通常是真的，但它说的是接口能接受这些语言的文本，不是每门语言都有对应的语言学处理。

真实情况往往是：一小批语言有完整的分析链路，一大批语言走的是通用处理，也就是按空格切、不做词形还原。

判断办法很直接：让对方给出这门语言的分析器配置，或者你自己发一个带词形变化的查询试一下。

本站写生成式搜索的语言覆盖 (https://zhangwenbao.com/sge-non-english-language-coverage-early-observation.html)那一篇有一句话，底层模型的语言覆盖远大于产品的语言覆盖，那条判据在这里同样成立。

合同里那一行数字，跟你的搜索框里发生的事，中间隔着好几层。

## 顺带说一个反向的误判

还有一种反过来的误判，也值得提。

看到词典停在2012年，就断定这门语言不能做。

这个结论跳得太快。

词典停更影响的是搜索容错和推荐质量，不影响收录、不影响排名、不影响内容本身的价值。

越南这些年的电商增长跟那份2012年的词典毫无关系。

正确的用法是把它当成一条预算输入：这门语言的站内体验要多花两天，仅此而已。

## 这一层的结论不该影响选语言的顺序

再补一句边界。

选哪门语言先做，判据是市场规模、竞争密度、内容复用率和履约能力。

基础设施这一层排不进前四。

它影响的是排期里的工作量估算，不是优先级排序。

保哥见过一个团队因为查到某门语言资源差就把它整个推迟了一年，而那个市场恰好是当年增长最快的。

把一条成本项误当成一条否决项，是这类实测数据最容易被用错的地方。

## 哪些相邻的问题不归这一层管

## 引擎那一侧的能力是另一套账

搜索引擎怎么处理这门语言，跟你的技术栈用什么资源，是完全独立的两件事。

引擎有自己的分词、自己的词库、自己的形态处理，规模比这些公共资源大得多。

所以会出现一种局面：你的站内搜索在这门语言上很笨，而外部引擎把你的页面理解得很好。

这两件事互不影响，也不能互相推断。

本站的桶边界一直是这么划的：引擎那半边归平台与多引擎那一类，这里只算你自己这一侧的账。

## 模型侧的语言能力也不在这里

生成式检索和大模型在小语种上的表现是另一条线。

那一层的瓶颈是训练语料和检索来源，本站写低资源语言容易出幻觉 (https://zhangwenbao.com/low-resource-language-ai-hallucination-rate-content-risk.html)那一篇算的是那笔账。

它跟这里讨论的词典、词干器、断词文件没有共用的资源。

唯一的交集是心态：两条线都容易让人从一个数字跳到一个过大的结论。

模型支持这门语言不等于答案可靠，词典存在也不等于这门语言被支持，两句话是同一个结构。

## 字体和渲染是另一层地基

还有一层地基是字体。

字形集不全会导致缺字，本站算过小语种站的字体文件比英文站大多少 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)，那是加载成本的账。

字体跟词典没有任何关系，一个管长什么样，一个管算不算词。

把它们放在同一次排查里，通常会互相干扰判断。

实际操作上建议分两轮查：先查语言处理能力，再查渲染与版式。

两轮的负责人往往也不是同一个人。

## 翻译质量不在这一层

最后一条界限。

这一层管的是机器怎么处理这门语言，不管你的文案写得好不好。

词典再新也救不了一份直译稿，词典停在十四年前也不妨碍你写出这门语言里最好的品类页。

两件事唯一的连接点在验收环节：拼写检查工具在停更语言上会报出大量假阳性，别让审校被那些红波浪线牵着走。

知道这一点之后，很多团队的语言验收流程会立刻轻松一截。

说到底，这一层是地基，地基决定你能盖多快，不决定你盖成什么样。

## 常见问题解答

## 怎么快速判断一门语言的技术支持成色？

查三处，二十分钟能查完十门语言。第一处是公共词典仓库里这门语言的词典文件最后改动年份，近三年内有实质更新算可用，停在十年以上按缺失处理。第二处是词干算法项目和你要用的搜索服务的语言分析器清单，看这门语言在不在里面。第三处是区域格式数据的覆盖等级。三处结论经常不一致，而不一致本身就是最有价值的信息。

## 词典停在十几年前，这门语言还值得做吗？

值得，这是一条成本项不是否决项。词典停更影响的是站内搜索的容错、拼写纠错和相关推荐，不影响收录、排名和内容本身的价值。正确的做法是在排期里加上自建同义词表和形态映射表的两天工时，把搜索入口做窄一点，导航和筛选器做厚一点。因为资源差就把一个增长中的市场推迟一年，是把成本误当成否决。

## 站内搜索在某门语言上召回很差，第一步该查什么？

先查索引模板有没有为这门语言指定语言分析器。实际故障里最常见的一种是能力存在但没人打开，全站用的是默认的通用分析器，按空格切词、不做任何词形还原。这一步排除之后，再去查这门语言有没有对应的词干器，最后才怀疑词典本身。倒过来查会浪费很多时间。

## 同义词表和形态映射表，规模要做多大？

按品类做，不按语言做。一个中等规模的电商品类，两三百行通常就能明显改善召回，覆盖的是高频那几十个品类词的常见变形和说法，不是整门语言。词源可以从三处捞：站内搜索的零结果查询、客服工单里的用户原话、竞品页面上的品类词写法。之后每季度补一次即可。

## 供应商说支持一百多种语言，这句话可信吗？

字面上通常是真的，但它说的是接口能接受这些语言的文本，不等于每门语言都有专门的语言学处理。可行的验证办法有两个：让对方给出这门语言的分析器配置，或者自己发一个带词形变化的查询试试召回。真实情况往往是一小批语言有完整链路，其余走通用处理。

## 这一层的问题为什么监控发现不了？

因为它产生的是退化不是错误。搜索还能搜，只是少召回一批；推荐还在推，只是推得平庸；换行还在换，只是断点难看。错误率、响应时间、可用性这三个指标一个都不会动。唯一能让它显形的办法是把关键指标按语言拆开看，全站平均值永远正常，因为流量集中在主语言上。

## 需要分词的语言如果没有分词资源，还能做站内搜索吗？

能做，但要按降级设计。具体是把搜索入口做窄，主推分类导航和多级筛选器，让用户少依赖搜索框，同时把商品标题里的关键属性拆成独立字段以便精确匹配。好消息是需要分词的语言就那么几门，而且这几门的分词词典维护得反倒不错，真正缺席的情况很少见。

## 权威参考资料



## 尺码那一栏的数字不归译者管，可整条流水线上没有一个人负责做那道算术

- URL：https://zhangwenbao.com/minor-language-size-unit-conversion-keyword.html
- 分类：小语种SEO
- 发布：2026-07-10  |  更新：2026-07-31
- 摘要：关键词表里有一类值不是翻出来的是算出来的。讲清欧码与英码的刻度为什么永远对不齐、标准数据库替各地区规定了哪些单位、尺码制式字段没有你的市场时怎么办。
- 关键词：技术SEO,跨境电商,多语言SEO,小语种SEO

> **TLDR**：摘要：关键词表里有一类值不是翻出来的，是算出来的。保哥把欧码和英码的刻度实算了一遍：一档差1.8毫米，两把尺子要走127档才重合一次，所以任何一张对照表每一行都四舍五入过，最大偏差接近半个码。而整条本地化流水线上，没有一个岗位负责做这道算术。

> 摘要：关键词表里有一类值不是翻出来的，是算出来的。保哥把欧码和英码的刻度实算了一遍：一档差1.8毫米，两把尺子要走127档才重合一次，所以任何一张对照表每一行都四舍五入过，最大偏差接近半个码。而整条本地化流水线上，没有一个岗位负责做这道算术。

## 尺码那一栏错了，为什么译审、母语审校和上线检查三道关全都放行？

## 一家做宠物出行装备的站，德国那边的退货率高出一截

有个客户做宠物出行，主力是航空箱、背包式宠物包、车载安全座和牵引装备。

荷兰站跑了一年多，数据稳，团队顺势把内容铺到德国和波兰。

翻译走的是正规流程，母语译者加母语审校，交付前还过了一遍术语表。

上线四个月，德国站的自然流量涨得不难看，转化率也说得过去，唯独退货率比荷兰站高出将近一半。

客服那边的退货理由写得很整齐：尺寸不合适。

团队第一反应是选品问题，讨论了两周要不要砍掉几个SKU。真正的原因躺在商品页上一张表里，那张表所有的字都翻译得毫无破绽，只有里面的数字是错的。

## 母语审校把那一页从头看到尾，一个字都没改

保哥后来看那份审校记录，审校确实是认真做的。

他改了品类词，改了两处语序，把一句被动式改成主动式，还在术语表上补了一条备注。

那张尺寸表他也看了，表头改得很地道，行标签也对。

问题是审校的职责范围写得清清楚楚：语言准确、表达自然、术语一致。

数字不在这三条里的任何一条。

更麻烦的是，数字看上去也没有任何异常。一个宠物包写着长45、宽28、高25，单位是厘米，德语里这几个词写得完全正确，唯一的毛病是这组数字是从英寸那一版四舍五入回来的，每一维都短了一点点。

## 出错的是一个没有主人的动作

把这条链路拆开看，会发现一个很尴尬的空隙。

产品团队给的是英制原始数据，因为供应商在美国。

翻译团队拿到的是已经成型的页面文案，他们的工作是把词换成德语，数字原样保留。

前端把文案填进模板，模板不做单位判断，它只负责渲染。

本地化项目经理验收的是交付文件的完整性和交期，不验算数。

于是从供应商那张英制规格表，到德国用户面前那张厘米表，中间需要一次换算，而这次换算不在任何一个人的工作说明里。它最后是被某个赶工的运营用计算器手动敲了一遍，敲的时候把17.7英寸记成了17.5。

## 这一类值跟关键词表里其他所有词的分界线

本站写过很多种词的麻烦。

有的词是范畴对不齐，比如颜色在不同语言里的切分位置 (https://zhangwenbao.com/minor-language-color-category-attribute-value.html)不一样。

有的词是取值由别人定死，比如那个每月几万次搜索却印在别人商标证上的品类词 (https://zhangwenbao.com/minor-language-genericized-trademark-category-keyword.html)。

有的词是社群还在投票，比如新借词的语法性别 (https://zhangwenbao.com/minor-language-loanword-gender-assignment-brand-article.html)。

这几类的共同点是，它们都还是词，都能用查、问、验这三个动作解决，都能在词典、法条或语料里找到依据。

尺码这一类不一样。它的正确答案不在任何一本词典里，因为它根本不是一个词的问题，是一道算术题。你把德语词翻得再地道，那个数字该错还是错。

## 为什么这类错误永远在售后才暴露

语言层的大部分错误会在流量侧留下痕迹。

词选错了，排名上不去；写法不地道，跳出率高；页面语言标错了，收录出问题。

这些都有报表能看。

数值错了不影响任何一条流量曲线。

页面照样收录，关键词照样匹配，用户照样点进来，甚至照样下单，因为下单的时候他相信那张表。

错误在包裹拆开的那一刻才生效，而那个时刻距离页面上线通常隔着两三个月，隔着客服、仓库和财务三个部门。等它绕回到做内容的人手里，已经变成了一句退货率偏高，谁也想不到要去查一张尺寸表。

## 这一类值到底有几种，怎么从词表里把它们挑出来？

## 先按品类清点一遍，数量比想象中多

服装尺码是最显眼的一个，但它只是其中一格。

鞋码是第二个，而且它的刻度体系跟服装完全无关，是另一套独立的账。

戒指圈号是第三个，三大市场用的是三个不同的自变量：日本用号，欧洲直接用内周长毫米，美国用一套自己的编号。

床上用品是第四个，因为床的尺寸本身按市场分档。

纸张、画框、相框是第五个，A4和Letter差着3.28%的面积，装裱和打印类的商品全部受影响。

再往下还有温度、容量、重量分档、功率、承重、绳长、口径。保哥的经验是，一个中等规模的独立站清点下来，这类字段通常有二十到四十个，散在属性表、规格段、筛选器和详情图里。

## 第一条判据：概念不变，值随市场变

判断一个字段属不属于这一类，第一条问句很简单。

换一个市场，这个字段说的还是同一件事吗？

如果是，而它的取值必须跟着变，那它就属于这一类。

宠物包的长度在德国和美国说的是同一段距离，但一个写45一个写17.7。

颜色不属于这一类，因为换个市场之后，蓝这个概念本身的边界就变了，那是范畴问题不是换算问题。

品类词也不属于这一类，因为它换的是名字不是数。这条判据能把八成的字段一次分完，剩下的两成才需要人来想。

## 第二条判据：错了能用尺子量出来

第二条判据保哥更喜欢，因为它是可操作的。

把这个字段的值填错，用户能不能拿一把物理的尺子、秤或者温度计证明你错了？

能，它就是这一类。

这条判据的价值在于它同时划出了后果的性质。

别的语言层错误的后果是概率性的，是排名低几位、转化差几个点、母语者觉得别扭。

这一类的后果是确定性的：东西寄到了，不能用，退回来。它不参与概率，它只参与算术。

## 怎么把这些字段从站里捞出来

最快的入口是筛选器。

凡是筛选器里能按数值区间筛的，背后一定有一个这类字段。

第二个入口是商品数据源，也就是喂给购物平台的那份文件。

那份文件里带单位的字段都是候选，尺寸、重量、容量、材质克重全在里面。

第三个入口是详情图，这一处最容易漏，因为图里的数值不参与任何自动检查。

第四个入口是客服的退货理由分类表。这一处的好处是它按后果排序，哪个字段错得最贵，一目了然。

## 宠物出行这条线上具体有哪几格

回到那个客户。

清点下来他们有四组值需要换算，而不是团队原先以为的一组。

第一组是箱包的三维尺寸，供应商给英寸，欧洲市场要厘米。

第二组是承重和宠物体重分档，供应商给磅，欧洲要公斤，日本还要按不同的分档习惯重新切。

第三组是航空箱能不能带上飞机，这一格最要命，因为各家航司的限制是按厘米还是按英寸写的都不一样，而用户搜的正是这件事。

第四组是牵引绳的长度，这一格看着最简单，却是全站唯一一个用户会拿卷尺当场验的字段。

## 两把尺子的刻度差1.8毫米，那张换算表还对得上吗？

## 先把两把尺子的定义摆出来

欧陆鞋码用的单位叫巴黎点，一码等于三分之二厘米。

算出来是6.6667毫米。

英国鞋码用的单位是大麦粒，一码等于三分之一英寸。

算出来是8.4667毫米。

两者的比值正好是1.27，也就是25.4除以20，这不是巧合，是因为一个来自公制一个来自英制。

日本码、中国新鞋号和韩国码用的是第三套，叫蒙多点，它直接标脚长毫米，一档5毫米。这三套里只有第三套的数值本身有物理意义，前两套标的都是楦长，而楦长比脚长多出一段放余，各家还不一样。

## 把220到300毫米的脚长逐档算一遍

保哥用业界常用的15毫米放余，把脚长从220毫米到300毫米每5毫米一档算了一遍。

脚长250毫米时，欧码的精确值是39.75，英码是6.30，美码男是7.30，日本码是25.0。

脚长265毫米时，欧码正好落在42.00，英码是8.07。

脚长285毫米时，欧码正好落在45.00，英码是10.43。

注意欧码这一列：它只在少数几个脚长上落到整数，其余全是带小数的。

这说明一件事，你在鞋盒上看到的那个整数码，本身就已经是取整的结果，而不同品牌取整的方向还不一致。

## 取整误差有多大：最大偏差1.87毫米

反过来算更能说明问题。

把欧码从35到48每一档回算成楦长，再换成英码，看四舍五入到半码之后差了多少。

欧码40的精确英码是6.50，正好落在半码上，误差只有0.03毫米。

欧码41的精确英码是7.28，取整到7.5，脚长上多出1.83毫米。

欧码46的精确英码是11.22，取整到11.0，脚长上少了1.87毫米。

整个范围内最大偏差是1.87毫米，而一个英码半档本身才4.23毫米。也就是说对照表里最坏的那几行，误差已经吃掉了将近半个档位，这不是哪张表做得糙，是两把尺子的刻度决定的。

## 两套刻度要走多远才重合一次

还有一个更彻底的算法。

欧码一档6.6667毫米，英码一档8.4667毫米，两个数什么时候能同时落在整档上？

保哥让脚本从1档往上跑，一直跑到127。

欧码走127档，累计846.67毫米，正好等于英码走100档，残差是0.000毫米。

127档是什么概念？欧码一档6.67毫米，127档是84.7厘米，比一整条腿还长。

换句话说，在人类脚长这个区间里，这两把尺子一次都对不齐。任何一张欧码换英码的表，每一行都必然是近似值，区别只在于是谁替你做的四舍五入。

## 所以不同来源的对照表互相打架是正常的

这条结论有个很实用的推论。

你去搜同一组码的对照关系，品牌官网、鞋类媒体、维基条目给出的表经常对不上，差半档很常见。

过去团队遇到这种情况的处理办法通常是找一个看起来最权威的抄下来。

这个办法在这里不成立，因为不存在一张正确的表。

正确的做法是把厘米补上去，让用户绕过所有码制直接量脚。

蒙多点体系之所以在专业运动鞋和军靴上通行，就是因为它是唯一自洽的那一套。页面上给出厘米，等于给用户一把不需要翻译也不需要换算的尺子，而这句话正好也是这一整篇的解法。

## 标准数据库里到底替你规定了什么，又漏掉了什么？

## 先看那份被所有系统读取的单位偏好数据

做本地化的技术栈底下有一份公共数据，叫CLDR (https://www.unicode.org/reports/tr35/tr35-general.html)，各家操作系统、浏览器和开发框架的区域格式都从这里取。

它里面有一块专门规定各地区该用哪套单位，叫单位偏好数据 (https://www.unicode.org/cldr/charts/46/supplemental/unit_preferences.html)。

保哥把这份文件拉下来数了一遍，46175字节，41个区块，覆盖15个量纲。

长度、面积、速度、体积、质量、温度、压强、功率、能量、浓度这些都在。

每个量纲下面还按用途细分，比如长度就分成默认、身高、道路、降雨、降雪、车辆、焦距这七种用途。

这份数据的存在意味着一件事：你以为需要自己判断的很多单位问题，标准里已经写好了答案，只是没人告诉你去哪儿看。

## 身高这一格不是两派，是三派

最能说明问题的是身高那一格。

直觉里这件事只有两种答案：公制的用厘米，英制的用英尺英寸。

数据里写的是三种。

用英尺加英寸的是加拿大、英国、印度、美国。

用米加厘米的是奥地利、比利时、阿尔及利亚、埃及、西班牙、法国、香港、印尼、以色列、约旦、马来西亚、沙特、瑞典、土耳其、越南。

剩下所有地区走世界默认值，用纯厘米。也就是说同样是公制市场，一个人的身高在法国要写成1米78，在德国要写成178厘米，这两种写法在各自市场里都是唯一自然的那一种，而任何一个把公制当成一格的模板都会在其中一边写出怪话。

## 华氏温度只剩六个地区，而其中一个不是美国

天气温度那一格更干脆。

用华氏的地区一共六个：巴哈马、伯利兹、开曼群岛、波多黎各、帕劳、美国。

其余全世界走摄氏。

这个清单值得贴在墙上，因为它把一个模糊印象变成了一份名单。

做产品页的时候，涉及温度的字段该按什么条件切换，看这六个代码就够了，不需要再讨论。

顺带一提，人体体温和天气温度在这份数据里是分开的两个用途，同一个地区在两件事上可以用不同单位，这一层细分连很多做本地化的工程师都没注意到。

## 瑞典人有一个属于自己的长度单位

道路距离那一格藏着一个彩蛋。

世界默认是公里和米，美国是英里和英尺，英国是英里和码。

瑞典单独一行，用的是公里、米，外加一个叫斯堪的纳维亚里的单位。

这个单位等于10公里，是瑞典人日常说距离时真会用的那个词。

标准数据库肯把一个只有一国在用的单位收进去，说明它确实高频到不能忽略。

本站写瑞典挪威丹麦三国资产共用边界 (https://zhangwenbao.com/nordic-seo-swedish-norwegian-danish-content-sharing-boundary.html)那一篇的时候，把商品图和尺寸表列成了少数能整块共用的资产，这个彩蛋正好是那条结论的边界：数值参数确实能共用，前提是三国都在公制圈里，一旦有一国的日常表达自带一套刻度，共用就到头了。

## 同一个盎司，两个说英语的市场差4.08%

容量那一格是最容易吃亏的。

数据里美国和英国是分开写的，美国用杯、液体盎司、加仑、品脱、夸脱，英国用的是英制液体盎司和英制加仑。

标准之所以把它们写成两个不同的单位，是因为它们真的不是一个数。

美制液体盎司是29.5735毫升，英制是28.4131毫升，相差1.16毫升，也就是4.08%。这两个数不是民间总结，英国的法定计量规定 (https://www.gov.uk/weights-measures-and-packaging-the-law)里对哪些场合必须用公制写得很细。

16盎司的差距是18.6毫升，32盎司差37.1毫升。

更狠的是品脱：美制一品脱16盎司等于473.2毫升，英制一品脱20盎司等于568.3毫升，两者差20.1%。宠物饮水器、洗护补充装、旅行分装瓶这几类商品，标错一个字母就是五分之一的容量差，而两边页面上写的都是英语。

## 这份数据里没有的那一格，恰好是最贵的一格

说完有什么，说没有什么。

15个量纲里没有服装尺码，没有鞋码，没有戒指圈号。

原因也不难理解：这几样不是物理量纲，是编号体系，它们背后虽然挂着长度，但取值是人为约定的档位而不是连续的数。

后果是，你的技术栈在长度、重量、温度上都能自动适配，唯独在尺码上什么也帮不了你。

这就解释了一个很多人纳闷的现象：为什么框架能自动把公里换成英里，却不能把欧码换成美码。

不是它不想，是标准里根本没有这一格。这也是为什么这件事必须由做内容的人来管，因为技术栈默认它不存在。

## 商品字段只认十一种码制，剩下那些市场的码填哪儿？

## 先数一遍平台到底给了几个取值

喂给购物平台的商品数据里有一个字段专门标尺码制式。

保哥把官方文档 (https://support.google.com/merchants/answer/6324502)翻出来数了一遍，支持的取值是11个：澳大利亚、巴西、中国、德国、欧盟、法国、意大利、日本、墨西哥、英国、美国。

这11个值决定了全世界的尺码只能落进这几个桶。

韩国不在里面，俄罗斯不在里面，印度不在里面，土耳其不在里面，波兰不在里面。

这些市场当然有自己的码制，韩国用毫米，俄罗斯的鞋码历史上就是自成一套。

它们在这个字段里没有对应的取值，于是只能被塞进欧盟或者美国那一格。这一步塞进去的偏差，后面所有的筛选、比价和推荐都会照单继承。

## 同一页官方文档上，同一个概念摆着两套代码

更有意思的是同一页文档的下半部分。

那一页除了给出数据源用的取值，还顺带说明了结构化数据里对应的属性该怎么填。

结构化数据那边的取值有12个，跟上面那11个只是看着像。

数据源里写欧盟用的是EU，结构化数据里对应的名字是Europe，另外还多一个Continental。

数据源里的墨西哥写作MEX，结构化数据里写作MX。

这两套代码印在同一页官方文档上，中间隔着不到一屏。你要是在两处填了同一个字符串，其中一处必错，而这件事没有任何工具会提醒你，因为两边各自都是合法的。

## 字段填错之后，损失落在哪一侧

这类偏差不会让商品下架，所以很容易被当成小事。

它的代价在别处。

第一处是购物结果里的尺码筛选，用户按本地码筛，你的商品按别的码入库，直接被筛掉。

第二处是同类商品的横向对比，平台会把同尺码的商品摆在一起，制式标错等于被摆到了错误的邻居中间。

第三处是本地码制的搜索词，用户搜的那个数字你页面上根本没有。

这三处的共同点还是老样子：全都不在任何一条曲线上，损失是缺席型的，缺席型损失的特点是没人会为它开会。

## 没有对应取值的市场，实际该怎么填

保哥给客户的处理办法是三段式。

制式字段填一个离本地最近的合法值，通常是欧盟或者美国，这一步是为了让数据能跑起来。

尺码字段本身写本地用户认得的那个写法，能带单位就带单位。

正文和结构化数据里补一张完整的对照，把本地码、欧码和厘米三列都写成可抓取的文本。

这三步的分工很清楚：第一步喂机器，第二步喂用户，第三步喂检索。

本站讲商品数据源里的语言字段 (https://zhangwenbao.com/minor-language-product-feed-language-fields.html)那一篇提过一个组织上的怪象，数据的操作权在投放那一侧而成本落在自然这一侧。尺码制式这一格是同一个坑的孪生条，区别只在于它错了连投放那一侧都察觉不到，因为广告照样能跑。

## 用结构化数据把三列都写出来

结构化数据里有一个专门描述尺码的类型 (https://schema.org/SizeSpecification)，可以同时容纳制式、尺码组和具体尺码，还能挂上对应的身体测量值。

用它把三列信息一次性写全，是这件事上性价比最高的一个动作。

写全之后的好处不只是给引擎看。

它逼着团队回答一个平时糊弄过去的问题：你这件商品的42码，究竟对应多少厘米。

保哥见过不止一个客户，是在填这个字段的时候才发现自己压根不知道答案，因为供应商给的规格表里只有码，没有量。

问回去往往还要等两周，而这两周暴露的正是问题的真身：整条链路上没有一处存过那个物理长度。

## 用户在搜换算的时候，打出来的到底是什么？

## 这类查询的形状跟普通关键词完全不同

普通关键词是名词或者名词短语。

换算类查询是一个算式，里面必然有数字。

典型形状是数字加单位加疑问词，比如42码是多少厘米。

这个形状带来两个后果。

第一，它的组合数量极大，一个品类几十个码值乘以几套制式，长尾一下子铺开好几百条。

第二，关键词工具几乎不返回它们的量，因为工具会把带数字的查询打散或者归并，最后每一条的量都低到显示为零。本站讲关键词工具返回零 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)那一篇说过，那个零是数据缺口不是需求缺口，这一类词是那句话最典型的样本。

## 各语言的问法不是同一个结构

英语里这类问句短得像公式。

德语用户的问法通常把单位写在前面，还会把两个单位用一个介词连起来，整句是一个完整的从句。

波兰语的问法常以疑问词开头，后面接一个变了格的单位词，而那个格的形态跟词典里的原形对不上，这一点跟本站写过的一个名词接出十八种格 (https://zhangwenbao.com/hungarian-seo-eighteen-cases-vowel-harmony-keyword.html)那几篇是同一条老账。

日语的问法把单位放在句尾，前面用助词连接，用户经常连品类词都不打，直接搜数字加单位。

这几种结构差异意味着，你不能把英语那条模板直译成八门语言就当覆盖完了。

正确的做法是找本地人写五条，然后从站内搜索日志和自动补全里补齐剩下的形状。

## 数字的写法本身就是一个变量

还有一层容易漏。

同一个数在不同市场的写法不一样，小数点可能是逗号，千位分隔可能是空格或者点。

用户搜27,5和搜27.5是两个字符串。

如果你的站内搜索按字符串精确匹配，其中一种写法会直接返回空结果。

页面文本也一样，你写27.5而当地人写27,5，匹配就少一次。

稳妥的做法是页面正文用本地写法，同时在结构化数据里用国际格式，本站讲结构化数据那一篇 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)正好把这条规则完整写过：正文越本地越好，标记里反着写回国际格式。

## 用站内搜索日志反推真实问法

这一类词的量在外部工具里查不到，但在你自己的日志里躺得整整齐齐。

做法是把站内搜索关键词导出来，筛出含数字的那一批。

然后按单位词分组，看用户最常用哪几个单位问。

保哥给那个宠物出行客户跑过一遍，德国站含数字的站内搜索里，超过一半带的是厘米，剩下的大头是公斤。

而他们商品页上最显眼的那组数字当时给的是英寸。

这一步不需要任何工具，导出、筛选、分组，一个下午做完，得到的却是这门语言里用户真正在用的那把尺子。

## 把答案前置，因为这类查询要的是一个数

换算类查询的意图非常单纯：要一个数。

用户不想读方法论，不想看品牌故事，他要的是一个能马上抄走的数字。

所以这类内容的写法跟品类页正相反：第一句就给答案，第二句给对照表，第三句才解释误差。

这也是这类页面在生成式检索里容易被引用的原因，答案短、结构清楚、能验证。

反过来，那些把答案埋在第五段的换算文章，在这一轮几乎没有存在感。

顺便说一句，这类页面最忌讳的就是把换算做成需要点击的小工具而正文里一个数都不写，那等于把自己的答案藏进了一个抓取不到的抽屉。

## 这些数值该摆在页面的哪几个位置，才既被人看见也被机器读到？

## 尺码表不能只做成一张图

这是最常见也最贵的一个错。

设计师做一张漂亮的尺码图，前端当作商品图挂上去，收工。

图里的数值对检索来说等于不存在。

本站算过图上烧进去那行字 (https://zhangwenbao.com/minor-language-image-alt-text-non-latin-script-search.html)的账，那一篇讲的是复用面被砍掉多少，这里的损失换了一种形态：不是复用不了，是根本查不到。

更麻烦的是这类图往往还带着从总部继承来的英制数值，改一次要重新出图，于是它成了全站更新最不及时的一块内容。

正确做法是表格用文本渲染，图只做示意。真要留图，图里的每个数在下方的表格里必须原样再出现一次。

## 正文里要有一句人话版的换算

表格是给要查数的人看的。

正文里那一句是给刚好在读段落的人看的，也是给抽取段落的机器看的。

写法很简单：这款宠物包的长边是45厘米，约合17.7英寸。

一句话里同时出现两个单位和两个数值，抽取的时候不需要任何上下文就能成立。

本站讲句子边界与段落抽取 (https://zhangwenbao.com/minor-language-sentence-boundary-passage-extraction.html)那一篇说过，检索的最小单位已经降到一句话，这一句正好是为那个粒度写的。

顺带的好处是，这一句在翻译成八门语言之后依然自洽，因为两个数都在句子里，译者删不掉也改不错。

## 筛选器里不要放换算，要放分档

有团队喜欢在筛选器里做单位切换，觉得体验好。

实际效果通常相反。

筛选器的取值要进URL、进面包屑、进内链锚文本，一旦带上可切换的单位，同一个商品集合会分裂出两套地址。

更稳的做法是筛选器固定用本地主流单位分档，把切换留给商品页上的对照表。

道理很简单：筛选器承担的是集合划分，不承担信息呈现，这两件事一旦混在一起，受害的一定是地址结构。

如果确实要给两套单位，让它作为页面上的一个视图状态，别让它进地址。

## 常见问题区放一条换算问答，位置很关键

换算类查询的答案很短，正好适合放进常见问题区。

放的时候有两个讲究。

第一，问句要按本地用户的实际问法写，别用英文模板直译。

第二，答案的第一句必须是那个数，解释放在第二句以后。

这一条同时服务两类读者：一类是拉到底部找答案的用户，一类是抽取问答对的机器。

本站讲小语种问答长尾 (https://zhangwenbao.com/minor-language-qa-long-tail-content-value-ai-era.html)那一篇算过一笔账，这类问题搜的人不多，但整个语种里认真写完整答案的更少，所以它的性价比不看绝对量，看的是竞争密度。

## 详情图、包装图和视频里的数值要单独立一份清单

页面上还有几处数值是内容团队管不到的。

供应商给的详情图里通常印着一套数值。

包装实物上印着另一套。

视频里口播的可能是第三套。

这三处的共同点是改起来贵、更新慢、没人巡检。

保哥的处理办法是给它们单列一份清单，标明每一处的数值来源和最后更新时间，上线前对一遍。这三处里包装最特殊：页面能改、视频能重录，盒子印出来就跟着商品进了用户家里，上面那个数字是用户唯一能拿在手上反复看的版本。

## 一套两天能跑完的数值清点流程

## 第一天上午：把带单位的字段全捞出来

从商品数据源开始，因为那份文件字段最整齐。

把所有带单位的字段列成一张表，记下单位和取值范围。

再去筛选器抄一遍，补上数据源里没有的。

然后打开三个不同品类的商品页，人工数一遍页面上出现的所有数字。

人工这一步不能省，因为详情图和正文里的数值不在任何结构化的地方。

半天时间通常能得到二十到四十行，这张表就是后面所有工作的底稿。

## 第一天下午：给每一行标出源单位和目标单位

每一行填三列。

第一列是这个值最初是谁给的，供应商、工厂还是测量得来。

第二列是原始单位。

第三列是每个目标市场该用的单位，这一列直接抄标准数据库里的规定，不要现场讨论。

填完之后会自动浮出两类问题行：一类是原始单位是英制而所有目标市场都是公制，这类必须换算；另一类是原始值本身就没有单位，只有一个码，这类要回头问供应商要物理测量值。

第二类通常比第一类更多，也更难办。

## 第二天上午：算一遍，并且留下算式

换算这一步本身不难，难的是留痕。

保哥要求客户把换算写成表格里的公式而不是手敲的数字。

原因很实际：手敲的数字没人能复核，公式能。

四舍五入的位数要统一约定，尺寸留一位小数，重量留两位，容量取整。

约定完写进文档，因为下一批商品还要用。

这一步做完，那个把17.7敲成17.5的事故就再也发生不了了，不是因为人变仔细了，是因为人不再负责敲数字。

## 第二天下午：把三处出口一次性对齐

数值算完之后有三个出口。

页面正文和表格是一个，结构化数据是第二个，商品数据源是第三个。

这三处必须由同一个字段派生，不能各填各的。

做不到自动派生的，至少要在上线检查表里加一行，要求三处逐个比对。

这一条听起来像常识，实际上保哥见过的站里能做到三处一致的不到一半。

最常见的走样是数据源更新了而页面没更新，因为改数据源的人和改页面的人不是同一批。

## 把这套流程接进新品上线的固定动作

清点一次的价值是有限的，它只解决存量。

真正省事的是把它接进新品流程。

做法是在商品资料模板里加两列：物理测量值和原始单位。

这两列填不满，商品不许进入翻译环节。

这个卡点看着强硬，实际推行阻力很小，因为供应商本来就有这些数据，只是从来没人问他要。

本站讲写死在代码里的界面文案 (https://zhangwenbao.com/minor-language-hardcoded-ui-strings-pseudo-localization.html)那一篇说过一句话，凡是靠一次性改造达成的状态都需要一道回归动作来维持，数值这件事同样如此，区别是它的回归动作可以做成一个必填项，成本几乎为零。

## 三种看起来很合理、实际在帮倒忙的做法

## 只给本地码不给厘米

第一种是本地化做得太彻底。

团队认为既然是德国站就应该只出现德国用户熟悉的码，于是把厘米那一列删掉了。

问题是德国用户在网上买鞋的时候，恰恰最需要那一列，因为不同品牌的同一个码差得离谱。

删掉之后，用户唯一的验证手段没了，退货率必然上去。

本地化的目标是让用户不用翻译就能读懂，不是让他失去参照物。

厘米那一列在任何市场都不算冗余，它是这一整套体系里唯一不需要信任任何人的那一列。

## 用脚本在浏览器里动态换算

第二种是技术上的过度优化。

做一个单位切换开关，用户点一下所有数值就变成另一套。

体验确实好，代价是那些数值全部由脚本在客户端生成。

抓取的时候页面上可能只有一套值，另一套完全不存在。

用户搜的偏偏是不存在的那一套。

稳妥的做法是两套值都写进初始的页面文本，切换只控制显示与否，别控制存在与否。这是老生常谈了，但它在这类页面上重犯的频率高得惊人，因为换算天然让人想到用脚本算。

## 全站统一成一套码制

第三种是管理上的图省事。

为了避免混乱，团队决定全站只用欧码，所有市场一视同仁。

这个决定在后台确实清爽，在前台是灾难。

日本用户搜的是厘米数，英国用户搜的是英码数字，你的页面上一个都没有。

更微妙的是，统一之后所有市场的数据看起来都正常，因为没有对照就没有落差。

本站讲一个模板生成十种语言 (https://zhangwenbao.com/multilingual-template-ten-languages-duplicate-content-risk.html)那一篇讲过同一个结构：字符层看不出问题，信息层已经塌了一半。码制统一属于同一类症状，它统一掉的不是格式，是用户的搜索入口。

## 顺带说一句四舍五入的方向

还有一个小到没人讨论、但值得定死的细节。

换算之后的取整方向要按语义定，不能一律四舍五入。

容器容量往小了取，因为标大了会溢。

承重往小了取，因为标大了会断。

箱包内部空间往小了取，外部尺寸往大了取，因为用户量的是能不能塞进后备箱。

这几条写进换算约定，一共不到五行，能挡掉一整类售后纠纷。

单位符号的写法也有讲究，这一层直接抄国际单位制手册 (https://www.bipm.org/en/publications/si-brochure)就行。符号和数字之间要不要空格、缩写用不用点、复数形式怎么处理，这些都有明确规定，没必要在内部会上争。真正需要团队自己拍板的只有取整方向那几条，因为它取决于你卖的是什么，标准替不了你判断。

还有一个更小的细节：同一页上不要混用两种写法。有的行写45厘米，有的行写45cm，看着无所谓，实际会让站内搜索匹配不到其中一半，也会让批量校验脚本失效。统一写法这件事花不了十分钟，却是这一整套约定里唯一一条能被机器强制执行的。

## 这套东西该由谁维护

最后一个常见误判是把这件事交给翻译供应商。

交出去的结果通常是他们原样保留数字，因为他们的合同里写的是语言服务。

比较务实的归属是商品数据团队，他们本来就掌握原始规格。

内容团队负责的是页面上那三处出口的一致性，以及换算约定这份文档。

本地化团队负责的是单位写法和数字格式，这一层确实归他们。

三方各管一段，中间那道算术必须有人签字，签字的人是谁不重要，重要的是它不能再是空的。

## 哪些相邻的问题不归这一层管

## 汇率和价格不是同一类账

价格也是数字，也随市场变，看起来像是同一类。

它不是。

汇率每天在变，尺码几十年不变。

价格错了用户当场就知道，尺码错了要等包裹拆开。

价格有系统自动同步，尺码没有。

把两者放进同一个流程去管，通常的结果是尺码被价格那套高频机制带跑，反而更少被人认真核对一次。

## 版式和字号是另一条腿

数值多了会撑长表格，尤其是同时给三套单位的时候。

这确实是个真问题，但它属于排版层。

本站算过小语种站的字形集与首屏成本 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)，那一篇讲的是字形和加载，跟这里的算术不是一笔账。

处理顺序上，先把数值弄对，再去解决表格放不下。

反过来做的团队保哥也见过，为了让表格好看先砍掉一列，砍掉的正好是厘米那一列。

## 物流限重和关税门槛属于合规侧

航空箱能不能带上飞机、包裹超没超重、申报价值有没有过免税额，这几件事也全是数字。

它们不归内容层管，归合规和物流。

但有一个交界处要留意：这些规则的官方文本本身有单位，而它们在不同市场的官方语言版本里单位可能不同。

你引用的时候要么原样引，要么换算之后注明来源，别自己悄悄改成另一套。

本站讲取值不由你决定的那类词 (https://zhangwenbao.com/minor-language-genericized-trademark-category-keyword.html)时的逻辑在这里同样成立：凡是取值由外部权威定死的，你的自由度是零，唯一能做的是把它准确地搬过来。

## 用户测量方式的差异也不在这一层

还有一层更细的，是同一个部位不同市场量法不同。

比如胸围是量最丰满处还是量下沿，宠物的颈围是量松还是量紧。

这一层是内容问题不是换算问题，解法是配一张量法示意图加一句文字说明。

它和换算的关系是串联的：量法不统一，换算再精确也没用。

所以这两件事要一起交付，但不要混在同一张表里，一张表只解决一个问题，是保哥这些年最不后悔的一条经验。

## 这一层跟词表那一层的分工

最后收个尾。

词表那一层管的是这个东西在这门语言里叫什么。

这一层管的是它有多大、多重、多热。

两层的检查动作完全不同：前者靠查、问、验，后者靠算、量、对。

把它们混在一个验收表里，结果通常是后者被前者吃掉，因为语言问题看得见，算术问题看不见。

分开列，各签各的字，是这一整套东西里最省力也最有效的一步。

## 常见问题解答

## 尺码换算这件事，交给母语审校去把关行不行？

不行，而且这不是审校水平的问题，是职责边界的问题。母语审校的验收项是语言准确、表达自然、术语一致，数字不在其中任何一条里。更关键的是，一个正确换算过的数字和一个算错的数字，在母语者眼里长得一模一样，他没有任何线索能察觉。这一格必须由掌握原始规格的人来签字，通常是商品数据团队。

## 页面上只给本地码，不给厘米，是不是更本地化？

正好相反。同一个码在不同品牌之间差得很大，本地用户在线购买时最依赖的就是厘米那一列，因为那是唯一不需要信任任何人的参照。删掉它，用户就失去了自我验证的手段，退货率会替你回答这个问题。本地化的目标是让人不用翻译就读懂，不是让他失去尺子。

## 欧码和英码的对照表，网上好几个版本对不上，该信哪个？

哪个都不用全信。欧码一档是6.6667毫米，英码一档是8.4667毫米，两把尺子的刻度本来就不整除，实算下来要走127档才重合一次，而人的脚长根本用不了那么多档。所以任何一张对照表都是近似值，最大偏差接近1.9毫米。正确的处理是把厘米补上去，让用户绕过码制直接比长度。

## 商品数据里的尺码制式字段，遇到没有对应取值的市场怎么办？

平台目前支持的取值只有11个，韩国、俄罗斯、印度、土耳其、波兰都不在里面。可行的办法是三段式：制式字段填一个最接近的合法值让数据能跑，尺码字段写本地用户认得的写法，正文和结构化数据里补一张本地码、欧码和厘米三列齐全的对照。三步分别喂机器、喂用户、喂检索。

## 换算类的长尾词工具里查不到量，还值得做吗？

值得，判断依据不是绝对搜索量而是竞争密度。这类查询带数字，工具会把它们打散或归并，最后每条都显示为零，那个零是数据缺口不是需求缺口。真实需求可以从站内搜索日志里筛含数字的查询反推出来，通常一个下午就能看清用户到底在用哪把尺子问。

## 做一个单位切换的小工具，是不是比写死两套数值更好？

体验上更好，检索上更差。如果两套数值里有一套是脚本在客户端生成的，抓取时它可能完全不存在，而用户搜的偏偏是那一套。稳妥的做法是两套值都写进初始页面文本，开关只控制显示与否，不控制存在与否。切换是呈现问题，不该变成存在问题。

## 温度、容量这些单位，有没有现成的标准可以直接抄？

有，而且比大多数人以为的完整。公共区域数据里有一份单位偏好数据，按地区规定了各量纲该用哪套单位，覆盖15个量纲。天气温度用华氏的只有6个地区，身高的写法分成3派而不是2派。要注意的是这份数据里没有服装尺码和鞋码，因为那不是物理量纲而是编号体系，所以这一格永远得自己管。

## 权威参考资料



## 站上加一门语言是加一套模板，喂给平台的那份数据要多一整份文件

- URL：https://zhangwenbao.com/minor-language-product-feed-language-fields.html
- 分类：小语种SEO
- 发布：2026-07-10  |  更新：2026-07-30
- 摘要：语言在页面上是每条记录的属性，在商品数据源里是整份文件的设置，份数按语言乘国家算。讲清两套声明为什么互不校验、属性值必须按目标语言提交、自动翻译该不该关。
- 关键词：技术SEO,跨境电商,多语言SEO,小语种SEO

> **TLDR**：摘要：站上加一门语言，是加一套模板和一批译文；喂给购物平台的那份商品数据加一门语言，是多一整份文件、一条独立的审核队列和一次全量复制。原因在于语言在页面上是每条记录的一个属性，在数据源里却是整份文件的一个设置，一份只能声明一门语言加一个国家，份数是乘出来的不是加出来的。更麻烦的是这两套声明互不知情，没有任何一处会做交叉校验，而拒登理由永远只写落地页与数据不符。本文拆开份数怎么算、属性取值怎么对齐、平台自动翻译那一版算谁写的。

> 摘要：站上加一门语言，是加一套模板和一批译文；喂给购物平台的那份商品数据加一门语言，是多一整份文件、一条独立的审核队列和一次全量复制。原因在于语言在页面上是每条记录的一个属性，在数据源里却是整份文件的一个设置，一份只能声明一门语言加一个国家，份数是乘出来的不是加出来的。更麻烦的是这两套声明互不知情，没有任何一处会做交叉校验，而拒登理由永远只写落地页与数据不符。本文拆开份数怎么算、属性取值怎么对齐、平台自动翻译那一版算谁写的。

## 你的站有语言这个维度，为什么喂给平台的那份数据没有？

## 一家小家电站的荷兰语市场，投放没问题自然购物结果一条都没有

有个客户做小家电，空气炸锅、破壁机、除螨仪、加湿器这几条线。

德国、波兰、荷兰三个市场，页面都做了本地语言，商品数量也差不多。

投放这一侧一直是外部代理在跑，数据交上去、广告能出、没人抱怨。

问题出在自然那一侧：德国和波兰在免费的购物结果里都有露出，荷兰一条都没有。

保哥把三个市场的商品数据后台点开对着看，看到第三屏就明白了：三个市场共用同一份数据文件，而这份文件的语言设置写的是德语。

德国那边当然对，波兰那边靠代理另建了一份，只有荷兰这一份从来没人动过，于是平台一直在拿一份声明为德语的数据去匹配荷兰用户的荷兰语查询。页面翻得再好都没用，因为参与匹配的根本不是页面。

还有一处细节值得记：这份数据的诊断报告一直是绿的。因为格式没错、必填字段齐全、抓取成功率也高，所有会被自动检查的项目都通过了，只有那个下拉框里的取值没有任何程序会去质疑。

## 页面上语言是每条记录的属性，数据源里语言是整份文件的设置

这个差别是本文所有结论的根。

在你的站上，语言是挂在每一条内容上的：这个页面是荷兰语，那个页面是德语，同一个模板能渲染出两种语言。

在商品数据源里不是这样。语言不在数据行上，它在这份数据的设置里，是一个整份文件级别的取值。

换句话说，一份数据源只能是一门语言，里面的每一行都必须是这门语言。

平台官方的支持的语言与货币 (https://support.google.com/merchants/answer/160637)那份说明里把这条讲得很清楚：语言和目标国家都是数据源属性，一份数据源对应一个组合。这不是限制，这是它的数据模型。

这个模型差异还有一个不太直观的推论：数据源里没有办法表达这一行是荷兰语、那一行是德语。你想混着放，唯一的结果是整份数据被按声明的那门语言处理，另一门语言的那些行成了噪声。

## 于是加一门语言，两边付的代价完全不同

把这个差别翻译成成本，落差就很直观了。

站上加一门语言，加的是一套语言资源文件，页面数量不变，地址结构不变。

数据源这边加一门语言，加的是一整份新文件：它要单独生成、单独上传、单独排进审核、单独出诊断报告。

更要命的是它有自己的失败模式，跟页面那一侧完全不重叠。页面上线了不代表数据通过了，数据通过了不代表页面对得上。

所以团队里那句加一门语言的工作量已经评估过了，多半只评估了页面那一半。本站在产品feed到底该谁管 (https://zhangwenbao.com/product-feed-seo-asset-organic-ai-ownership.html)那篇里讲过这份数据在组织里的归属问题，语言这一列正是归属不清最容易掉下去的地方。

还有一层代价在时间上。页面上线是你说了算的，数据要等平台抓取和审核，快则几小时慢则几天。所以新语言上线的那几天里，页面已经在了而数据还没进来，这段窗口期的表现不能用来判断做得对不对。

## 这件事为什么在英语站上永远不会成为一个话题

这条规律本站已经遇到过很多次，这里又一次成立。

一个只做英语的站，数据源份数等于国家数，语言这个维度根本不参与计算。

做英美澳三个市场，三份数据源，语言全是英语，你甚至不会注意到设置里有语言这一项。

于是所有关于这份数据的教程、清单和最佳实践，都是在语言维度恒等于1的前提下写出来的。

它们讲标题怎么写、图片怎么选、价格怎么对，就是不讲语言，因为在作者的场景里那不是一个变量。同一种英语卖到美英澳 (https://zhangwenbao.com/international-seo-same-language-multi-region-en-us-gb-au-duplicate-content-hreflang.html)那篇拆过这种情形的另一半，两边合起来才是完整的图。

顺带说一个判断技巧：读任何一份关于这类数据的指南时，先看它有没有提到语言这个设置。一个字都没提的，说明作者的场景里语言恒等于一，那份指南的份数计算和排期建议都不能直接照搬。

## 数据源的语言到底声明在哪儿，跟页面上那套语言声明是什么关系？

## 声明的位置不在数据里，在后台的数据源设置里

很多人第一反应是去数据文件里找语言字段，找不到。

它确实不在文件里，它在后台创建这份数据源时选的那两个下拉框上。

一个下拉选语言，一个下拉选目标国家，选完就定死了。

这个位置的隐蔽性是它最大的问题：文件是每天自动生成上传的，谁都能看到；那两个下拉框是三年前某个人点的，从此没人再点开过。

本站在界面文案那批从没进过翻译文件的字 (https://zhangwenbao.com/minor-language-hardcoded-ui-strings-pseudo-localization.html)里记过完全一样的结构：一个当时不需要评审的决定，此后没有任何流程会重新审视它。

还有一处同样隐蔽的设置在旁边：目标国家。两个下拉挨着，错一个的后果差不多，但目标国家错了往往会因为货币或者税率对不上而被诊断出来，语言错了不会。所以真正没有防线的是语言那一个。

## 页面这一侧的语言声明有三处，数据源那一侧只有一处

把两边的声明并排列出来会更清楚。

页面这一侧至少有三处：标签上的语言属性、响应头里的语言字段、以及各语言版本之间互相指认的那组标记。

数据源这一侧只有一处，就是后台那个下拉。

三处对一处，本身就说明两套体系的精细度不在一个量级。

更关键的是数量少的那一侧是决定性的：匹配用的是数据源那一份，页面上写得再全也改不了它。结构化数据里的语言与地区声明 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)那篇讲的是页面这三处怎么写，本文补的是第四处。

把这四处列成一张表贴在流程文档里是划算的。新市场上线时逐处打勾，四个勾打完再上线。这张表的价值在于它把一个分散在两个系统里的检查项收成了一次动作。

## 两套声明互不知情，也没有任何一处会做交叉校验

这是本文最想让人记住的一句。

页面的语言声明和数据源的语言设置之间，没有任何自动校验。

你可以把一份声明为德语的数据源指向一批荷兰语落地页，系统全程不会提示你。

抓取会成功，商品会入库，诊断报告可能一片绿，广告甚至照常投放。

不一致的后果不是报错，是匹配质量悄悄变差：查询用荷兰语进来，数据说这批商品是德语的，于是它在这个国家的自然购物结果里排不上。整条链上没有一个环节的职责是发现这件事。

自己补这个校验并不难：把数据源的语言设置导出来，跟落地页地址里的语言前缀做一次字符串比对，对不上的报警。这个脚本几十行，跑一次几秒钟，可它填的是整条链上唯一没人负责的那个缺口。

## 数据源里没有各语言版本互相指认的那套机制

还有一件事值得单独点出来。

页面这一侧有一套成熟的机制，让同一个内容的各语言版本互相指认，告诉引擎这几页是一回事的不同语言版。

数据源这一侧没有等价物。同一款空气炸锅的德语版和荷兰语版，在数据层面就是两条毫无关系的记录。

唯一能把它们联系起来的是落地页地址，而地址关系由页面那一侧的标记维护。

这意味着页面那一侧的标记如果做错了，数据这一侧不会有任何补救余地。hreflang标签怎么落地 (https://zhangwenbao.com/hreflang-implementation-return-tags-x-default-canonical-mistakes.html)那篇讲的是页面那一侧怎么做对，这里补一条依赖关系：那一侧做对了，数据这一侧才有可能被正确归拢。

这条依赖关系还有一个实用推论：先把页面那一侧的语言关系做干净，再去铺数据源。顺序反过来的话，数据侧会先积累一批归拢错误的记录，而这批记录的纠正周期比页面长得多。

## 一门语言一份文件，数据源的份数是怎么被乘出来的？

## 语言乘国家，而不是语言加国家

算份数的时候最常见的错误是用加法。

做三门语言、四个国家，很多人下意识觉得是三份或者四份。

实际上一份数据源锁定的是一个语言与国家的组合，所以要按组合数算。

不是所有组合都存在，但存在的那些每一个都要一份。

德语卖去德国、奥地利、瑞士，是三份；再加荷兰语卖去荷兰和比利时，又是两份。五份，而不是两门语言加两三个国家那种直觉上的三四份。

算之前建议先画一张表：行是语言，列是国家，在实际有销售的格子里打钩。打完钩数一下有几个钩，这个数就是份数。这个动作五分钟，却能把后面几个月的排期算清楚。

还有一个上限要提前知道：平台对一个账户下的数据源数量通常有限制，多数场景够用，但如果你既按语言拆又按商品线拆，两个维度乘起来很快就会撞上限。所以拆的维度只能有一个是语言，另一个别再拆。

## 同一门语言卖去三个国家，为什么还是三份

这一条最反直觉，值得单独说。

同一门语言的三个国家，商品文案可以完全一样，一个字都不用改。

但价格不一样、税率不一样、配送政策不一样、可售商品范围也未必一样。

这些差异都写在数据行里，所以文件本身就是三份不同的文件。

语言在这里帮不上忙：语言相同只省掉了翻译成本，没省掉文件数。这也是为什么这件事的成本曲线跟页面那一侧长得完全不一样，页面可以靠同一套内容覆盖三个国家，数据不行。

这里有一个真正能省的地方：文案可以完全复用。三份文件里的标题和描述可以是同一批字符串，只有价格、货币、可售状态这几列不同。所以生成这三份的脚本可以共用一套文案逻辑，差异用参数控制。

## 份数一多，增长点不在文件上而在审核队列上

五份文件听起来还好，真正的成本在后面。

每一份都有独立的抓取排期、独立的诊断报告、独立的拒登记录。

一个商品在五份里被拒登，就是五条要处理的记录，而它们的拒登理由可能各不相同。

更耗人的是这五份的问题不会同时出现，它们错峰发生，于是这件事永远有人在处理，永远没做完。

见过的失败模式基本都是这一种：份数从两份长到八份的过程中没人重新分工，还是原来那一个人在看，看着看着就只看主力市场那两份了。

有一个能提前止损的动作：给每一份配一个明确的接收人，而不是发到共享邮箱。共享邮箱的通知在份数超过四份之后基本就没人看了，因为它变成了一条永远有新消息的流。

## 什么时候可以合并，什么时候绝对不能

给两条判据。

可以合并的情形只有一种：同一门语言、同一个国家、只是商品来源不同，这时候用补充数据源覆盖字段就够，不必建新的主数据源。

绝对不能合并的是跨语言。哪怕两门语言的用户群高度重叠，比如同一个国家的两种官方语言，也必须分开，因为语言是文件级设置。

还有一种半合并的做法值得知道：主数据源保持一份，用补充数据源按语言覆盖标题和描述这两列。这条路在部分平台上可行，在部分平台上不行，接入前要先确认。

判断顺序永远是先看语言是不是同一门，语言不同就别想着省这份文件。

补充数据源这条路还有一个附带好处：它不需要重新生成主数据，只覆盖指定的几列。对于只想按语言换标题的场景，这是改动量最小的做法，也最容易回滚。

## 落地页与数据不符这条拒登理由，差的到底是什么？

## 这条理由的字面意思和实际成因

这是所有商品数据里最高频的一类拒登，字面意思是数据里写的和落地页上显示的对不上。

大多数人第一反应是查价格，其次查库存状态。

这两项确实占了多数，但它们通常几小时内就能定位。

真正拖成慢性病的是另外几类，其中语言不一致是最不被想到的一种。

官方的购物广告政策 (https://support.google.com/merchants/answer/6149970)里对这一类的要求写得比多数人以为的宽泛：数据必须准确反映落地页，而落地页的语言当然也在反映的范围里。

还有一类容易被归错的：抓取的时候拿到的页面跟用户看到的不一样。常见成因是按地区做了跳转，或者页面靠脚本渲染而抓取时没执行。这一类看起来像语言问题，实际上是可访问性问题，要分开处理。

## 语言不一致是最常见也最不被想到的一种

语言不一致有三种发生方式。

第一种是数据源设置错了，就像开头那家小家电站，整份数据的语言从一开始就填错。

第二种是数据对但落地页跳错了：地址指向的是默认语言版本，用户和抓取程序拿到的都是另一门语言的页面。

第三种最细：数据里绝大多数字段是目标语言，但有几列没翻，比如尺寸类型、材质、适用场景这类枚举值。

第三种触发拒登的概率不高，但它会持续拉低匹配质量，而且没有任何报表会告诉你有几列没翻。

第三种的排查有个笨但有效的办法：把数据文件按列抽样，每列取十个不同的取值，交给母语者扫一眼。他能在两分钟内指出哪几列不是本地语言，而这件事没有任何自动检查能替他做。

## 属性取值的一致性要求比标题更严

这里有个容易被忽略的不对称。

标题和描述允许你写得跟落地页不完全一样，只要意思准确。

而颜色、尺寸这类属性，平台要求提交的取值和落地页上显示的取值保持一致。

也就是说，页面上写荷兰语的颜色名，数据里就得是荷兰语的颜色名，不能图省事全填英语。

官方的颜色属性说明 (https://support.google.com/merchants/answer/6324487)还额外要求用标准的颜色名而不是自造的营销名，两条要求叠在一起，就把这一列变成了必须逐语言维护的一列。

这条不对称的实际含义是：属性列的本地化优先级应该排在描述之前。多数团队的顺序正好相反，先花力气翻描述，属性列留到最后，而属性列才是那个会触发拒登和影响筛选归类的部分。

## 排查顺序：先看语言，再看价格和库存

给一条能直接用的排查顺序，跟多数人的习惯正好相反。

拿到一批拒登，先按国家分组，看是不是集中在某一个市场。

集中在某一个市场的，先去看那份数据源的语言设置，两分钟就能确认。

确认没问题再往下查价格、库存、图片这些逐条差异。

这个顺序的道理很简单：语言设置错了是整份文件的系统性问题，一次能解释掉成千上万条；价格和库存是逐条问题，查一条解决一条。先查能一次解释掉全部的那类。

还有一个能顺手做的分组：按拒登理由的文本聚合。同一句理由下面挂着上千条商品，多半是系统性问题；一句理由下面只有三五条，才是逐条问题。先处理前者，投入产出差一个数量级。

## 属性值那一列，为什么翻了页面不翻属性值等于白翻？

## 属性值是给机器筛选用的，可它同样要按目标语言提交

属性列跟标题描述不一样，它的读者主要是机器。

机器拿它做筛选面、做比价、做同款归并。

正因为读者是机器，很多团队默认它可以用英语，反正机器认识。

这个默认是错的：平台按语言维护自己的属性取值表，你提交的值要落进目标语言那张表里才会被正确归类。

提交英语值到一份荷兰语数据源里，最好的结果是被当成自定义值放行，最坏的结果是这条商品在筛选面里彻底消失。

有个快速自检：去平台的筛选面上看看自己的商品出现在哪些筛选项下。如果某个颜色或者尺寸筛选项里找不到你的商品，而商品本身有这个属性，那多半就是取值没落进标准表。

还有一类自定义属性值得单独说：平台允许你上传自己定义的属性，用来做广告分组和报表切分。这一类不参与前台展示，理论上填什么都行，但强烈建议全站统一用英语标识，否则按语言分的报表会碎成一片。

换句话说，标准属性按目标语言填，自定义属性按内部标识填。两类混着填是这一块最常见的乱源，而它的代价要等到做跨市场报表的时候才显出来。

## 颜色和尺寸这两列的坑最深

属性列里最容易出事的是颜色和尺寸。

颜色的麻烦在于范畴边界，各语言把连续的色谱切在不同位置，同一个色号在两门语言里可能落进不同的基本色。

本站在你的色卡上蓝和绿是两格 (https://zhangwenbao.com/minor-language-color-category-attribute-value.html)那篇里专门拆过这一层，这里只补数据源侧的一条：平台要的是标准色名，而标准色名的清单是按语言给的，直接把英文清单翻一遍会翻出一批当地人不用的说法。

尺寸的麻烦在于制式，同一个数字在不同国家指的不是一码事，而尺寸类型这一列的取值本身也要按语言写。

这两列建议单独建对照表，一次建好长期复用，因为它们的取值集合是有限的，不像标题那样每条商品都不同。

尺寸这一列还有一个跟语言直接相关的坑：尺寸类型的取值本身是词，比如常规、加大、加长这一类，它们要用目标语言写。很多团队翻了尺寸数字所在的说明文字，却把这一列的枚举值留成了英语。

## 提交值和落地页显示值经常由两拨人维护

一致性要求本身不难满足，难的是组织。

页面上显示的颜色名由内容或者本地化团队定，数据里提交的颜色名由做数据管道的人定。

两边各有各的来源，中间没有一条线把它们绑在一起。

于是页面改了词，数据没跟着改；或者数据换了标准值，页面还是老说法。

解法是把这批取值收进一个字段，页面和数据都从这个字段取，而不是各写各的。本站在品牌名算公的还是母的 (https://zhangwenbao.com/minor-language-loanword-gender-assignment-brand-article.html)那篇里用过同一招：结论存进数据字段，字段一旦存在就有了负责人和变更记录，而不是变成一场每年重来一次的口头争论。

还有一个更省事的判断：如果你说不出这批取值现在存在哪儿，那它一定存在好几个地方。存在好几个地方就意味着它们迟早会不一致，而不一致的那一天不会有任何提示。

## 建一张属性取值对照表，一次建好长期复用

具体做法很朴素。

把用到的属性列出来，通常不超过八列：颜色、尺寸、尺寸类型、材质、图案、年龄段、性别、状态。

每一列列出你实际用到的取值，多数列在二十个以内。

再按语言横向展开，每门语言一列，请本地写手一次填完。

这张表的规模通常在一两百格，一个人半天能填完，而它此后覆盖所有新品。属性枚举值那件事 (https://zhangwenbao.com/minor-language-color-category-attribute-value.html)给过一条判据可以直接借用：取值本身是不是落在一条连续谱上，是的话就必须逐语言确认，不是的话可以放心复用。

表建好之后要定一条维护规则：新增取值必须先进表再上线，不允许先在数据里写一个新值再回头补表。这条规则听起来死板，但它是这张表能活过一年的唯一前提。

## 平台替你翻译的那一版数据，跟你自己翻的差在哪？

## 它不是翻译层，它直接落成那个站点上的正式内容

多数平台都提供某种形式的自动翻译，帮你把商品信息铺到更多国家。

这件事跟搜索引擎在结果页替用户翻译一个页面不是一个量级。

那种翻译不改变你的原始页面，用户看到的是一层临时的转换。

平台的自动翻译不一样，它产出的文本会作为正式商品信息落在那个站点上，署的是你的名字，出问题也是你的客服在解释。

本站在平台搜索词字段那笔字节账 (https://zhangwenbao.com/minor-language-marketplace-listing-fields-tokenization.html)里已经点过这一条，数据源这一侧的机制完全一样：账单还是寄给你。

还有一个容易被忽略的后果：这一版内容会成为那个市场用户对你品牌的第一印象，也会成为别人引用你的时候抄走的那一版。它不只影响这一次成交，它进入了公开语料。

## 自动翻译最容易在哪几类字段上出事

把出事概率按字段排一遍，顺序很稳定。

最容易出事的是品类词本身，因为它是整条数据里语义最集中、上下文最少的一处。

其次是规格里带单位的短语，机器经常把数字和单位之间的关系搞错。

第三是那些看着像英语其实是本地造词的说法，这一类翻过去会变成一个更普通的词，读起来还更顺。

最不容易出事的反而是长描述，因为上下文足够多。这个排序有点反直觉：字越少的字段越危险，而商品数据里最重要的那几个字段恰好都是短字段。

本站在讲品牌名进入非拉丁市场时记过一条同构的规律：你不定，市场会替你定。自动翻译是这条规律在数据层的版本，区别只是这次替你定的不是当地媒体，而是一个不解释理由的程序。

有一个可以量化的自查：把自动翻译产出的品类词导出来，跟你自己词表里的品类词做一次比对，看重合率。重合率低于一半，说明这个市场的商品在用一批你从没审过的词招揽用户。

## 关掉它要付什么代价

知道了风险，下一个问题是要不要关。

关掉的代价是覆盖面：那些你暂时不打算认真做的国家，会从有一份粗糙的信息变成什么都没有。

对处在试水阶段的市场，粗糙的信息确实好过没有。

所以这件事不该一刀切，该按市场分档。

主力市场自己翻，用自己的词表和审校；试水市场让它开着，但要把品类词那一列用自定义值锁住，别让它翻。锁住品类词这一个动作，就能挡掉这一类问题里的大半。

锁住品类词的具体做法多数平台都支持，通常是把该字段标为不翻译，或者提供一份术语表让它按表走。接入时问一句有没有这个功能，比事后逐条改要省事得多。

## 判据：什么时候该让它开着

给三条判据。

这个市场的月订单还没到两位数，让它开着。

这个市场已经有本地化页面和本地客服，就该自己翻，因为此时数据是全链路里唯一还没本地化的一环，留着它反而突兀。

介于两者之间的，折中做法是只自己翻标题和品类，其余交给自动翻译。机器翻译直接发上线 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)那篇给过一条质量线，数据源这一侧可以整体沿用，只是要把判断单位从页面换成字段。

还有一个时点值得记：准备正式进入某个市场的前一个季度，就该把自动翻译关掉换成人工。因为搜索侧对内容变化的反应有滞后，等页面都做好了再换，前面那几个月的积累是按机翻那一版算的。

## 数据源里的标题在不同语言里，为什么装不下一样多的信息？

## 长度上限按字符算，而各语言的信息密度不一样

数据源的标题有长度上限，这个上限对所有语言是同一个数字。

但同样的信息在不同语言里占的字符数差得很远。

德语靠复合词把几个概念压进一个长词，字符数不省，词数省。

荷兰语和波兰语的修饰结构更长，同一句话经常多出两三成。

这条跟平台那个按字节计的搜索词字段是两回事，那边算的是字节，这边算的是字符，但结论方向一致：同一个额度在不同语言里兑换出的容量不一样。

有一个反直觉的地方：复合词语言的字符数未必更多，但它的可切分点更少。同样一百个字符，英语能装七八个可独立成词的成分，德语可能只有四五个，而检索侧认的是成分不是字符。

描述字段的上限宽松得多，所以有人会把塞不进标题的信息挪到描述里。这个做法在英语上有效，在形态丰富的语言上收益会打折，因为描述里的词形跟用户查询对不上的概率更高。

## 前几十个字符是唯一确定会被看到的部分

标题的显示长度和可填长度不是一回事。

购物结果卡片上显示的字数远少于上限，移动端更短。

同样的显示宽度下，各语言能显示的字符数还不一样。

所以标题的前几十个字符要能独立成立：品牌加品类放最前，这一条在所有语言下都成立。

复合词语言在这里额外吃亏，因为它可能在一个词的中间被切断，切出来的半截在那门语言里不是词。德语复合词那件事 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)讲过这类词该怎么切，数据源标题是它最直接的应用场景之一。

把这条落成规则很简单：品牌加品类必须出现在前二十个字符内，属性和修饰词往后放。这条规则不分语言都成立，也不需要为每门语言单独讨论，是这一节里最容易执行的一条。

## 模板拼出来的标题在有些语言里不合语法

数据源标题多数是模板拼的，结构通常是品牌加品类加属性。

这个结构在英语和中文里读着自然，在别的语言里未必。

屈折语里名词和形容词要配合，直接把属性值原样拼进去会得到语法上不搭的组合。

有些语言的属性习惯放在名词后面，模板一律前置就会读着像机器写的。

处理办法不是给每门语言写一套复杂的形态逻辑，而是把模板的槽位顺序做成按语言可配的，再把属性值本身按主格形态准备好。这跟站上屈折语站的锚文本 (https://zhangwenbao.com/minor-language-internal-link-anchor-inflection-variants.html)用的是同一条思路：能靠版面和字段解决的，别靠语法逻辑解决。

还有一种更省事的处理：在属性和名词之间加一个分隔符号，把拼接变成并列而不是修饰。这样语法上就不要求配合了，读起来像一张标签而不是一句话，在数据源标题这个位置是完全可以接受的。

## 一条能当天做完的截断实测

验证办法很土。

在目标国家的购物结果里搜自己的核心词，把自己商品的标题截屏。

看它在什么位置被截掉，截掉的位置前面有没有品牌和品类。

每门语言取五条商品，二十分钟能跑完一门语言。

顺手记下截断位置对应的字符数，这个数字比任何文档里的建议值都贴合你自己的品类。

实测的时候别只在电脑上看。购物结果在手机上的显示长度明显更短，而多数卖家写标题、看效果都在电脑上完成，于是所有人都在一个比真实情况宽松得多的环境里做判断。

## 谁在维护这份数据，语言这一列该挂在谁名下？

## 这份数据的所有权问题在语言这一列上最尖锐

商品数据的归属本来就模糊，语言这一列把模糊放大了一倍。

做数据管道的人管字段格式和上传，他不判断某个词在荷兰语里对不对。

本地化团队管译文质量，但他们多数不知道有这么一份文件存在。

投放团队管这份数据能不能跑起来，语言对不对不在他的验收项里。

三方都不觉得这是自己的事，而这件事恰好只需要一个人花两分钟去点开那个下拉框确认一次。

这件事还有一个组织上的怪象：它的成本落在自然那一侧，而这份数据的日常操作权在投放那一侧。成本和操作权不在同一个部门，是它长期无人认领的根本原因。

还有一个组织信号值得留意：如果这份数据是外部代理在维护，那么语言设置这一项几乎注定没人验过。代理的验收标准来自广告效果，而语言错了广告照样能跑，它不在任何一份对赌条款里。

## 语言这一列在投放部门那里不是一个字段

这句话值得展开。

投放部门看这份数据的视角是它能不能出广告、成本高不高、哪些商品被拒了。

在这个视角里，语言不是一个可调的变量，它是环境的一部分。

所以当自然那一侧出问题时，投放部门给出的诊断永远是数据没问题，因为按他的验收项确实没问题。

这跟本站讲过的另一类错位是同构的：一件事的收益和成本不结算在同一个部门，于是没有人有动机去改它。

所以问投放部门数据有没有问题，得到的答案永远是没问题，而这个回答是诚实的。要问出东西来，问题得换成：这份数据的语言设置是什么，是谁在什么时候选的。这个问法指向一个具体取值，答不上来本身就是答案。

## 三种归属方式各自的失败模式

见过三种分工，各有各的翻车方式。

全给投放的，失败模式是自然那一侧长期没人看，问题往往等到季度复盘才浮出来。

全给技术的，失败模式是格式永远合规、语言永远没人验，因为技术侧没有判断语言对错的能力。

全给本地化的，失败模式是他们改不动数据管道，提了需求排不上期。

比较可行的是拆：技术负责生成和上传，本地化负责属性取值表和标题模板的语言部分，投放负责诊断报告的日常处理，检索这一侧负责定规则和验收。四方各管一段，交接点写清楚。

四方分工里最容易漏的交接点是本地化到技术那一段。本地化产出的是一张表，技术要把这张表接进模板，这一步如果没有明确的接口约定，最后多半变成技术把表里的值手工抄一遍，抄完就再也不同步了。

## 最小可行的分工写法

如果只能写三句话，就写这三句。

每一份数据源的语言设置由谁在什么时候确认过，记在一张表里，新建数据源时必须填。

属性取值对照表由本地化团队维护，技术侧的模板从这张表取值，不允许写死。

诊断报告里出现的拒登，先按国家分组看是不是系统性问题，再往下逐条查。

三句话写进流程文档，比任何培训都管用，因为它们都是可执行的动作，不是原则。

这三句话建议直接写进新市场上线的检查清单，而不是单独放一份流程文档。单独的流程文档没人翻，上线清单每次都会被走一遍，规则挂在会被执行的地方才有意义。

## 那家小家电站后来改了四处

## 第一处：把三份数据源拆成六份

最先改的是份数。

原来三份对应三个国家，语言设置一份德语两份混着。

重新按语言与国家的组合数了一遍，实际需要六份。

拆的过程本身不复杂，麻烦的是要给每一份重新配一次抓取排期和通知人。

拆完当天就看到了变化：荷兰那一份第一次跑出了完整的诊断报告，之前它的问题一直被合并在德语那份里，看起来像是德语市场的零星错误。

拆的时候还顺手发现了一件事：原来那份混着的数据里，波兰市场的商品一直在跟德国市场的商品竞争同一批展示位。拆开之后两个市场的数据第一次能分开看，这是拆份数除了修语言之外的另一半价值。

## 第二处：属性取值对照表

第二件事是把颜色、尺寸类型、材质三列做成对照表。

三列加起来实际用到的取值是四十几个，三门语言横向展开一百多格。

本地写手一个下午填完，填的过程中顺手挑出了两个词：一个是原来页面上用的颜色说法在荷兰语里偏文学，另一个是材质词用的是英语原词而当地有通行译法。

这两处在页面上也一并改了，因为它们本来就该一致。

这张表现在挂在商品数据字段里，页面模板和数据管道都从它取值。

填表过程中还确认了一件本来有争议的事：材质那一列到底该用当地通行译法还是保留英语原词。做法是把两种写法各拿去搜一次，看当地电商站的商品标题用的是哪一种，用当地卖家的写法作准。

## 第三处：标题模板按语言重排前二十个字符

第三件事是标题。

原来三个市场共用一套模板，结构是品类加属性加品牌。

在购物结果卡片上实测，荷兰语和波兰语的标题在品牌出现之前就被截断了。

改成品牌加品类前置，属性往后放，一次改完三个市场。

这一处的改动量最小，效果却最直接，因为它改的是唯一确定会被用户看到的那一段。

改完之后团队顺手加了一条上线检查：新品上架后在目标国家的购物结果里搜一次，截图存档。这一条花不了两分钟，却把这类问题的发现周期从几个月压到了当天。

## 结果里那个没预料到的收益

三个月后回看，荷兰市场在自然购物结果里从零开始有了稳定露出。

预料之外的是德国市场也涨了一截，而德国那份数据源本来就是对的。

原因是属性取值对照表顺带修掉了德语那一列里几个不规范的颜色说法，那几个说法之前一直被当成自定义值处理，没进标准筛选面。

换句话说，为了修一个市场的系统性问题而建的那张表，顺手修掉了另外两个市场的零散问题。

这类收益不太好提前预估，但它出现的频率不低：把一件本来靠人各写各的事收进一个共享字段，通常会顺手暴露一批没人报过的老问题。

还有一个次要收益也值得记：拆分之后每个市场有了独立的诊断报告，团队第一次能说清哪个市场的数据健康度更差。之前所有市场的问题混在一份报告里，看起来永远是一个笼统的百分比。

## 把语言变成数据源流程里的一个字段

## 第一天上午：盘清现在有几份，各是什么语言

第一步是打开后台，把所有数据源列出来。

每一份记三样：语言设置、目标国家、落地页地址的语言前缀。

三样对不上的立刻标红，这一步通常十分钟就能出结果。

再按语言与国家的组合算一遍应该有几份，跟实际份数对比。

差额就是待建的份数，也是这次工作量的主要来源。

顺手记第四样：这份数据源是谁在什么时候创建的。这一列多半查得到，而它能直接告诉你有多少份是当年匆忙上线时建的、此后再没人碰过。那几份就是重点怀疑对象。

## 第一天下午：把属性取值对照表建起来

第二步是属性列。

先导出实际用到的取值，按列去重，通常每列不超过二十个。

再按语言横向展开，交给本地写手一次填完。

填完之后同步进商品数据字段，并且把模板改成从字段取值。

最后拿三个商品做端到端验证：页面上显示的取值和数据里提交的取值逐字对一遍。

端到端验证的时候要注意选样本：挑那些属性最多的商品，而不是随手挑三个。属性少的商品验不出问题，因为它根本没用到那几列有争议的取值。

## 第二天：标题模板、抓取排期与通知人

第二天做剩下的工程动作。

按语言实测标题截断位置，把品牌和品类挪到前面。

给每一份新建的数据源配抓取排期，排期时间错开，别让它们挤在同一个小时。

给每一份配一个明确的通知接收人，而不是发到一个没人看的共享邮箱。

最后把新建数据源的检查清单写进流程文档，重点是那个语言下拉框必须有人确认并签字。

抓取排期错开还有一个实际理由：多份数据同时抓取会在同一时刻给你的服务器带来一个尖峰，而这个尖峰恰好可能触发限流，导致其中几份抓取失败。错开半小时就能避掉。

## 上线前的五项检查与两条反信号

发布前照着五条走：每一份数据源的语言设置与落地页语言一致、属性取值在页面和数据里逐字相同、标题在移动端购物卡片上截断前包含品牌和品类、自动翻译在主力市场已关闭而在试水市场已锁住品类词、每一份都有独立的诊断报告接收人。

两条反信号也要说清楚。

如果你只做一个国家一门语言，整件事不成立，不必建对照表也不必拆份数。

如果你的商品数量在两位数，且全部靠人工维护，那么把这套流程建起来的成本会高于收益，直接人工逐条核对更快。

判断顺序是先数一遍语言与国家的组合数，组合数超过三，这件事才值得按流程做。

还有一条值得在检查表之外单记：把这次盘出来的份数和语言对应关系存成一份文档，下次新增市场时先看它。这类知识流失得特别快，因为它既不算技术文档也不算内容规范，没有天然的归属地。

投入也可以分三档。最低一档只做份数拆分和语言设置校正，半天能完；中间一档加上属性取值对照表和标题模板重排，两天；最高一档把校验脚本挂进每日流水线并按语言出独立报表，一周。多数站做到中间一档就够。

## 常见问题解答

## 做多语言站，购物数据源到底要建几份？

按语言与目标国家的组合数算，不是按语言数加国家数。一份数据源锁定一个组合，语言是整份文件级的设置，不是数据行上的字段。德语卖去德国、奥地利、瑞士是三份，再加荷兰语卖去荷兰和比利时是两份，一共五份。同一门语言卖去三个国家仍然是三份，因为价格、税率和可售范围写在数据行里，文件本身就不一样。

## 页面已经做了各语言版本互相指认的标记，数据源那边还要管语言吗？

要，而且这两套声明互不知情。页面那一侧至少有三处语言声明，数据源那一侧只有后台那个下拉框，参与商品匹配的是后者。你可以把一份声明为德语的数据指向一批荷兰语落地页，系统全程不提示，抓取会成功、商品会入库、诊断报告可能一片绿，只是匹配质量悄悄变差。整条链上没有任何一个环节负责发现这件事。

## 属性值可不可以统一填英语，反正是给机器看的？

不可以。平台按语言维护自己的属性取值表，提交的值要落进目标语言那张表里才会被正确归类。填英语值到一份非英语数据源里，最好的结果是被当成自定义值放行，最坏的结果是这条商品在筛选面里消失。颜色这一列还额外要求用标准色名而不是自造的营销名，两条要求叠起来，这一列必须逐语言维护。

## 拒登理由写着落地页与数据不符，该从哪儿查起？

先按国家分组，看是不是集中在某一个市场。集中的话先去看那份数据源的语言设置，两分钟能确认。确认没问题再往下查价格、库存、图片这些逐条差异。这个顺序跟多数人的习惯相反，道理是语言设置错了属于整份文件的系统性问题，一次能解释掉成千上万条，而价格库存是逐条问题。先查能一次解释掉全部的那类。

## 平台的自动翻译要不要关掉？

按市场分档，别一刀切。月订单还没到两位数的试水市场让它开着，粗糙的信息好过没有，但要把品类词那一列用自定义值锁住不让它翻。已经有本地化页面和本地客服的市场就该自己翻，此时数据是全链路里唯一还没本地化的一环。介于两者之间的，只自己翻标题和品类，其余交给它。

## 数据源的标题长度上限对所有语言一样，怎么公平？

它不公平，但这一条改不了，只能在结构上补。同样的信息在德语里靠复合词压缩，在荷兰语和波兰语里往往多出两三成。真正要保的是前几十个字符，因为购物卡片上显示的字数远少于上限，移动端更短。把品牌和品类放最前，属性往后，然后在目标国家的购物结果里实测截断位置，每门语言取五条商品，二十分钟能跑完。

## 这件事该归投放、技术还是本地化？

拆开归。技术负责生成和上传，本地化负责属性取值对照表和标题模板的语言部分，投放负责诊断报告的日常处理，检索这一侧负责定规则和验收。全给投放的失败模式是自然那一侧长期没人看；全给技术的失败模式是格式永远合规、语言永远没人验；全给本地化的失败模式是他们改不动数据管道。关键是新建数据源时那个语言下拉框必须有人确认并留痕。

## 权威参考资料



## 德语页面下面挂着一半英语评论，这一段字你既管不了也不能装作没看见

- URL：https://zhangwenbao.com/minor-language-user-review-language.html
- 分类：小语种SEO
- 发布：2026-07-07  |  更新：2026-07-30
- 摘要：评论是站上唯一一类语言不由你决定的内容。讲清翻译它会撞上哪条质量红线、数字为什么能跨语言合并而文本不能、新语言版本社会证明为零那几个月怎么过渡。
- 关键词：跨境电商,多语言SEO,内容本地化,小语种SEO

> **TLDR**：摘要：商品页上的文字里，标题描述是你写的，合规弹窗是工具写的，只有评论那一块是买家写的，而买家用哪门语言写你无权决定。于是德语页面下面挂着一半英语评论必然发生，它不是失误，是这类内容的固有属性。你能决定的只有三件事：存不存语言字段、要不要翻译、按什么规则展示。三件事各有代价：机翻覆盖原文会伤真实性并撞上质量红线，按语言过滤会让新市场的社会证明归零，而聚合评分与评论正文在跨语言处理上根本不是同一类东西。

> 摘要：商品页上的文字里，标题描述是你写的，合规弹窗是工具写的，只有评论那一块是买家写的，而买家用哪门语言写你无权决定。于是德语页面下面挂着一半英语评论必然发生，它不是失误，是这类内容的固有属性。你能决定的只有三件事：存不存语言字段、要不要翻译、按什么规则展示。三件事各有代价：机翻覆盖原文会伤真实性并撞上质量红线，按语言过滤会让新市场的社会证明归零，而聚合评分与评论正文在跨语言处理上根本不是同一类东西。

## 一家家居收纳站的德语页，评论区一半是英语，这算问题吗？

## 德语站上线半年，评论里德语只占一半

有个客户做家居收纳，收纳箱、衣柜挂件、抽屉分隔、真空压缩袋这几条线。

德国和荷兰两个市场，页面都是本地语言，商品也是同一批。

上线半年之后团队来问一个问题：德语商品页下面的评论，德语只占一半，剩下的是英语和几条荷兰语，这个要不要处理。

他们担心的是两件事，一是看起来不专业，二是怕搜索引擎把这一页判成英语。

保哥先问了一句：那一半英语评论是谁写的？

答案挺有意思。查下来大部分来自德国境内的下单地址，其中不少是在德国工作生活的外国人，还有一批是德国人自己用英语写的，因为他们下单时用的是站上的英语版本。

荷兰那一边的比例更极端，荷兰语评论只占三成。

这不是荷兰市场做得差，恰恰相反，荷兰的英语普及率在欧洲数一数二，用英语写评论对当地人几乎没有门槛，所以同样的分布在两个市场里含义完全不同。

所以看这个比例之前要先问一句：这个市场的人用英语写东西算不算日常？答案不同，同一个数字的结论就相反。

## 团队最先想到的是屏蔽，而屏蔽掉的正是最有价值的那批

第一反应几乎都是同一个：只显示本语言的评论，眼不见为净。

这个做法执行起来最简单，一个筛选条件的事。

但把数字摊开看就会犹豫：德语页面的评论条数会立刻掉一半。

评论条数是转化路径上最贵的资产之一，而且它跟星级一起被展示在列表页上。

更麻烦的是被砍掉的那批往往写得更长更细，因为用英语写评论的人通常是习惯了跨境购物的老手，他们知道该写什么才有用。

还有一个连带损失容易被漏掉：条数会同时从列表页上的星级摘要里消失，而列表页是访客决定点不点进来的那一屏。

换句话说，屏蔽这个动作的损失不止发生在商品页，它发生在更前面的一步。

真要减少外语评论的占比，正确的动作在上游：把评价邀请改成本地语言、把评论表单的提示语改成本地语言，让下一批评论自然长成你想要的样子。

## 这件事跟别的本地化问题不一样，它没有正确答案

站上大部分语言问题都有唯一解。

标题该用本地词，属性值该按本地规则填，错误页该按语言输出，这些都能写进规范。

评论不行。同一批英语评论，对一位英语流利的德国买家是有用的信息，对一位不读英语的买家是页面上的噪音。

你面对的不是对错，是一组取舍。

所以本文不会给出一条通用规则，只会把取舍的坐标轴摆清楚，然后给出按市场分档的判据。能照抄的规则在这一页上是不存在的。

顺带说一句，这也是为什么这件事在内部特别难达成一致：市场部看到的是转化，本地化看到的是体验，技术看到的是规则，三个人说的都对。

## 先把三个问题拆开：谁写的、给谁看、机器怎么读

混在一起讨论必然吵架，拆开就清楚了。

第一个问题是产生环节：用户为什么用这门语言写，你能不能影响。

第二个问题是展示环节：显示给谁看、翻不翻、怎么排序。

第三个问题是机器环节：结构化数据怎么标、页面语言会不会被判偏。

这三段的负责人往往不是同一批人，而且他们各自的最优解不一致，这也是这件事在内部特别容易僵持的原因。

拆开之后还有个好处：三段各自都有明确的负责人，产生环节归增长、展示环节归前端与本地化、机器环节归技术。

含糊的时候大家都觉得该有人管，拆完之后每一段都能落到具体的人头上。

顺带提醒一句，第三段最容易被跳过，因为它的问题不体现在页面上，只体现在收录和展示位上。

## 站上的文字里，为什么只有这一类你决定不了语言？

## 页面文字你写，弹窗文字工具写，评论文字用户写

把一个商品页上的文字按出处分一遍，会分出三堆。

第一堆是你自己产出的：标题、描述、属性、按钮、提示。

第二堆是第三方工具产出的：合规弹窗、客服窗口、支付控件上的字。

第三堆是用户产出的：评论、评分、问答、晒图说明。

前两堆的语言最终都能被你决定，区别只是要登录哪个后台；第三堆不行，它的语言在写下的那一刻就定了，而你甚至不在场。

还有第四堆容易被忘：平台自动生成的那些字，比如评论摘要、相关问题、翻译按钮上的提示。

这一堆的语言通常跟着页面走，反而是最省心的一类。

## 你能决定的是显示规则，不是内容语言

这句话值得单独立一行，因为它划定了后面所有讨论的边界。

你可以决定显示哪些、按什么顺序显示、要不要附一版译文。

你不能决定用户用哪门语言写，也不该去改他写下的原文。

本站在讲包容写法和讲品牌名性别的两篇里都提过同一条原则：用户生成内容不受你的规范约束，它的价值正在于没被编辑加工过。

那两篇讲的是写法层面不要动，这一篇要补的是更前面的一层：连语言这个维度都不是你能选的，所以规范再细也管不到这里。

这条边界还有一个反向推论：既然你不该改用户的原文，那么把评论当成数据来用就是完全正当的。

统计词频、看语言分布、做词表采集，这些动作不触碰原文，收益却很高。

这条边界也解释了为什么评论区不该做词形归一：归一之后你就把最真实的那批变体抹掉了，而变体正是这份语料最值钱的部分。

## 用户选哪门语言写，取决于他当时用的哪个界面

这条机制很朴素，却解释了大部分分布异常。

评论表单出现在哪个语言版本上，用户就倾向于用那门语言写。

如果你的评价邀请邮件是英语的，收到邮件点进来的人多半用英语写。

如果评论表单的占位提示是英语的，哪怕页面是德语，也会把一部分人推向英语。

所以那一半英语评论里，有相当一部分其实是被你自己的界面引导出来的，这一点在归因之前很容易被忽略。

评价邀请邮件的语言取自哪里，值得单独查一次。多数系统取的是下单时的站点语言，也有的取用户注册时填的偏好，还有的干脆全站一个模板。

这三种取法会产出完全不同的评论语言分布，而它是这条链上你唯一能直接拧的旋钮。

还有一个细节：邀请邮件的语言和邮件里那个跳转地址的语言必须一致，不然用户点进来看到的是另一门语言的表单，等于把他又推回英语。

## 于是评论的语言分布，是一份免费的市场语言样本

换个角度看，这件不受控的事反而给了你别处买不到的数据。

写评论的人是已经付过钱的买家，不是问卷里的路人。

他挑的那门语言，是他在你这个品类下最舒服的表达语言。

这份样本天然贴合你的真实客群，采样成本是零。

本站讲小语种关键词工具返回的那个零是数据缺口不是需求缺口 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)那一篇里说过，工具查不到量的时候要去自己的一手材料里找，评论区就是最厚的一层一手材料，而语言这一栏是里面最容易被忽略的信息。

更妙的是这份样本是持续更新的，不需要重新采集，每个月自己会长出新的一批。

它还自带时间维度，按季度分段看，能看出这个市场的语言习惯有没有在移动。

## 评论的语言分布能告诉你什么，别的调研为什么给不了？

## 写的人是掏过钱的买家，样本天然对

市场调研的老问题是样本偏差。

问卷回收到的是愿意填问卷的人，社媒样本是活跃用户。

评论样本不一样，它的入场券是完成一笔订单。

这意味着分布直接对应你的真实成交结构，而不是潜在人群。

如果一门语言在你的评论里占比很低，在订单地址里占比却很高，那说明的不是这门语言不重要，而是你的评价邀请环节没有用这门语言触达他们。

反过来也成立：如果某门语言在评论里占比很高，在订单地址里却对应不上任何一个大市场，那多半是你的国际站在替本地站接流量。

这份差值还能反向校验你的市场判断：占比高但没有对应页面版本的语言，就是下一门该做的语言的候选。

## 三种分布形态，各自意味着不同的动作

把评论按语言分组之后，通常会看到三种形态。

第一种是本地语言占绝对多数，说明市场成熟、界面引导正确，维持现状即可。

第二种是本地语言与英语对半，说明客群里跨境老手比例高，这时屏蔽英语是纯亏损。

第三种是本地语言极少，绝大多数是英语或者你的主语言，这多半不是市场特征，是界面和邮件把人都推到英语那一侧去了。

第三种最值得动手，而且动的不是评论区，是评价邀请的语言和评论表单的语言。

还有一种少见但值得警惕的第四形态：某一门你根本没做页面的语言在评论里稳定出现。

这通常意味着有一个你没注意到的市场正在自己找上门，而这条信号在别的数据源里很难被看见。

遇到第四形态时最省事的验证办法是去看订单地址，如果那门语言对应的国家确实在出单，那就不是噪音。

## 跟站内搜索词放在一起看，能校准你的语言判断

单看评论语言容易得出片面结论，配上另外两份数据就稳了。

一份是站内搜索框的输入语言，那是用户找东西时的语言。

一份是客服对话的语言，那是他遇到问题时的语言。

三份放在一起，能看出这个市场的用户在不同场景下的语言切换习惯。

常见的一种组合是搜索用本地语言、评论写英语，这说明本地语言是他的检索语言而英语是他的表达语言，这种情况下页面内容必须本地语言，评论区反而可以宽松。

三份数据里最便宜的是站内搜索，因为它本来就在记日志，只是很少有人按语言分组去看一眼。

把三份并排放一个季度，通常能推翻团队原先凭印象定下的语言优先级。

## 先把语言这个字段存下来，多数评价插件根本不存

这是整节里最实操的一条。

大部分评价插件的数据结构里没有评论语言这一栏。

它存了评分、正文、时间、是否已验证购买，唯独没存这条评论是什么语言。

没有这一栏，前面说的所有分析都做不了，展示层的过滤规则也无从写起。

补的办法有三种：提交时记录当前站点语言、提交时记录浏览器语言、事后跑一次语言识别。第一种最准也最便宜，因为提交那一刻你确切知道他在哪个语言版本上。

语言识别这条路要留个心眼：三五个词的短评论识别准确率很低，本站讲站上字最少的那几类页面最容易被机器认成另一门语言 (https://zhangwenbao.com/minor-language-page-language-detection-misidentification-short-text.html)那一篇里讲的短文本问题，在这里同样成立。

所以识别只用于补历史数据，新数据一律用提交时的站点语言，那是确定值不是猜测值。

记录站点语言的另一个好处是它同时告诉你这个人是从哪个版本进来的，而版本信息在做归因时比语言本身更有用。

## 要不要把评论翻译成页面语言，三种做法各有代价

## 机翻覆盖原文，读起来假，而且改了用户的话

第一种做法是把所有评论统一翻成页面语言，只显示译文。

好处很明显：页面整齐、每位访客都能读懂。

代价有三层。第一层是读感，机翻的评论一眼能看出来，情绪和口语被抹平了。

第二层是可信度，评论之所以有说服力，正因为它读起来像真人随手写的。

第三层最要紧：那是别人写的话，替换掉原文等于你在替用户发言，而在虚假评论监管趋严的当下，这一步的性质并不轻。

还有一层法律上的模糊地带：在虚假评论监管趋严的当下，把用户的话替换成机器译文，性质上并不轻。

监管关心的是评论呈现给消费者时是否真实可信，而替换原文恰好动的就是呈现这一端。

还有一种更轻的做法：只在用户点了翻译按钮之后才生成译文，页面默认仍然是原文，这样既不改原文也不批量产出文本。

## 原文加译文并排，页面变长，重复度上升

第二种做法是保留原文，在下面附一版译文。

真实性保住了，可读性也保住了。

代价是页面长度翻倍，而评论区本来就是商品页里最长的一块。

另外译文那一半在各语言版本之间高度相似，会让本来就模板化的商品页更加相似。

本站讲一个模板生成十种语言，字符层看不出重复、信息层十份一模一样 (https://zhangwenbao.com/multilingual-template-ten-languages-duplicate-content-risk.html)那一篇算过这笔账：字符层看不出重复，信息层十份一模一样，评论译文会把这个比例推得更高。

缓解办法是默认折叠译文，用户点开才展开。

这样既保留了可读性，又不会让每一页凭空多出一倍的文本，代价是多一次点击。

折叠还有一个技术上的好处：折叠内容通常不计入初始文档的主要文本块，对页面语言判定的干扰更小。

## 按语言过滤只显示同语言，新市场直接归零

第三种做法是各语言版本只显示对应语言的评论。

它最干净，也最符合直觉。

问题在开局：一个新上线的语言版本，这样处理之后评论区是空的。

而新市场恰恰是最需要社会证明的时候，本站讲落地页上最像装饰的那几个信任元素在小语种市场是搜索量最高的购买词 (https://zhangwenbao.com/minor-language-landing-page-trust-signals-payment-address-support.html)那一篇里，评论条数是清单上排最前的几项之一。

更隐蔽的一层是聚合评分：如果过滤同时影响了评分计算，那么新语言版本连星级都没有，而星级会出现在搜索结果里。

还有一个隐蔽的连带效应：过滤如果影响了聚合评分的计算，新语言版本连星级都没有，而星级会出现在搜索结果里。

也就是说这个选择的代价不止在页面上，还在搜索结果的展示位上。

## 判据：先看这个市场的读者能不能读源语言

三种做法没有通用最优，判据落在读者身上。

目标市场的英语普及率高，比如北欧和荷兰，保留英语原文不翻是完全可行的。

普及率中等的市场，比如德国和法国，建议原文加译文并排，并且标注清楚哪一版是机器翻译。

普及率低的市场，比如日本、波兰、巴西，英语评论对多数读者等于不存在，这时候翻译的收益最大。

这条判据的好处是它能被量化：拿这个市场的英语能力指数配上你自己站的英语版访问占比，两个数一乘就能排出优先级，不需要开会争论。

这条判据的好处是可以量化：拿这个市场的英语能力水平配上你自己站英语版的访问占比，两个数一乘就能排出优先级。

比开会争论管用，因为两个数都是现成的。

排完优先级还要看一眼评论总量，量太小的市场先不用花这个钱，那点条数翻不翻都改变不了什么。

## 翻译评论这件事，会不会踩到内容质量那条线？

## 大批量机翻文本本身就是被点过名的一类

搜索引擎对机器翻译内容的态度写得很明确：只要是大批量生成、缺少人工审核的低质文本，不管用什么方式生成，都在打击范围内。

它针对的不是翻译这个动作，是无人过目这个状态。

评论翻译很容易正好落进这个描述里：量大、自动、没人看。

一个有几千条评论的站，翻十种语言就是几万段无人过目的文本。

这批文本还会分布在成千上万个商品页上，占据每一页相当大的篇幅，从页面构成上看，它的权重不小。

值得留意的是这条规则的措辞：它针对的是无人过目这个状态，而不是翻译这个动作本身。

所以只要引入抽检和标注，性质就已经变了，这也是最省力的一处改动。

## 评论区尤其危险，因为量大、模板化、页面多

把三个特征叠起来就能理解风险为什么高于别处。

量大，意味着人工抽检覆盖率必然低。

模板化，意味着同类商品的评论译文彼此高度相似。

页面多，意味着这些相似文本会铺满整个目录。

相比之下，把商品描述机翻一遍反而风险更小，因为那是一段有人审过的文本，而且每个商品只有一段。

还有一个放大器：很多站的评论区会被分页，每一页都是一个可被索引的地址。

几万段机翻文本再乘上分页，铺开的面积比多数人估计的大一个量级。

如果评论区做了分页，最好把第二页往后设成不索引，这样既保留用户可读性，又不让机翻文本铺满整个目录。

## 标注出机器翻译，是成本最低的自保

这一步只要一行字，收益却相当大。

在译文旁边写明这是自动翻译，并给出查看原文的入口。

对用户，这解释了为什么这段话读起来有点怪。

对机器，这是一个明确的信号：这段文本是派生内容，不是原创内容。

主流的评价服务都支持这个标注，只是默认多半不开，因为开了显得不够顺滑。这是一个典型的短期体验与长期风险的取舍，而这一页上应该选后者。

主流评价服务都支持这个标注，只是默认多半不开，因为开了显得不够顺滑。

这是典型的短期体验与长期风险之间的取舍，而这一页上应该选后者。

## 保留原文可访问，比替换原文安全

最后一条原则很简单：原文必须还在。

可以折叠、可以放在下面、可以点开才展开。

但不能是替换关系，因为替换意味着那条真实的用户表达在你的站上不存在了。

一旦有争议，比如用户投诉自己的评论被曲解，原文是唯一的证据。

这也符合本站反复讲的那条原则：原始数据保留、派生数据可以另存，评论翻译属于典型的派生数据。

原文还有一个常被忽略的用途：它是这门语言里最真实的用词样本，一旦被译文替换，这份语料就没了。

本站讲日本用户挑毛巾搜的是手感，那个词在你的属性表里连一格都放不下 (https://zhangwenbao.com/minor-language-onomatopoeia-texture-attribute-keyword.html)那一篇里的采词方法，前提就是评论原文还在。

所以更稳的顺序是：先把原文完整存进自己的数据库，再谈展示层要不要翻，别让服务商那一侧的处理决定你手上还剩什么。

## 结构化数据里，评论的语言该怎么标？

## 评论正文有语言字段，聚合评分没有

先看词汇表本身给了什么。

单条评论这个类型下有描述正文的字段，也可以标注这条内容的语言。

聚合评分那个类型给的是评分值、评分数量、最高最低值，没有语言这个概念。

这不是遗漏，是设计如此。

本站讲小语种页面正文越本地化越好、结构化数据却要反着写回国际格式 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)那一篇讲过整套标注逻辑，这里只补一条它没展开的：同一个页面上的两个类型，一个有语言维度一个没有，处理方式必须分开想。

顺带一提，晒图评论是这里的例外：一张实物照片跨语言完全通用，不需要翻译也不会被判成低质文本。

在评论为零的新市场里，图片是唯一能立刻借过来用的社会证明形态。

这也解释了一个常见现象：图片多的评论在跨市场展示时接受度明显更高，因为它需要读者读懂的部分最少。

## 数字可以跨语言合并，文本不行

这是本文最值得记住的一句。

一位德国买家给的四星和一位英国买家给的四星，是同一个四星。

评分是数字，它不承载语言，跨市场合并是合理的，也是应该的。

评论正文不是。一段德语正文对读不懂德语的人来说不产生任何说服力。

所以正确的做法是分开处理：聚合评分全语言合并，让每个语言版本都有一个像样的星级和条数；评论正文按语言排序，把读得懂的排前面。这一条能同时解掉前面那个新市场归零的困境。

把这条推到底还有一个推论：任何数字型的用户信号都可以跨语言合并，比如有用票数、退货率、复购率。

需要按语言分开的永远只有文本，因为只有文本要求读者会这门语言才能产生作用。

这条推论在做多语言报表时也管用：数字类指标可以合并看，文本类指标必须分语言看，混在一起的报表通常两头都说不清。

## 各语言版本的页面，该不该共用同一个聚合值

接着上一条往下推，结论是应该。

同一款商品在德语页和荷兰语页上是同一件东西，它的质量评价不会因为读者换了语言就变。

把评分按语言拆开算，只会让每个版本的样本量都变小，星级更容易被少数极端评分带偏。

唯一需要拆开看的场景是同一款商品在不同市场的实际体验确实不同，比如物流时效差异很大的时候。

那种情况下要拆的也不是评分，是把物流相关的评价单独归一类，因为本站讲西班牙人和墨西哥人搜的不是一个词 (https://zhangwenbao.com/spanish-seo-es-es-latam-keyword-divergence.html)那一篇早就点过：产品体验可以共用，物流与售后体验不能共用。

还有一种情况需要单独看：同一款商品在不同市场卖的其实是不同的配置或包装。

那已经不是语言问题而是商品同一性问题，这种情况下评分本来就不该合并。

## 最常见的三处填错

第一处是把聚合评分的数量填成当前语言过滤后的条数，导致各语言版本数字不一致。

第二处是给译文标注了语言，标的却是原文的语言。

第三处是同一页上同时输出了过滤前和过滤后两套值。

这三处都不会报错，校验工具只看格式合不合规。

发现它们的唯一办法是打开两个语言版本的页面，把结构化数据里的数字并排比一遍，五分钟就能查出来，而多数团队从来没做过这个动作。

第四处稍微少见但更难查：译文和原文都被输出到了标记里，导致同一条评论在结构化数据中出现两次。

校验工具不会报错，因为格式完全合规，它只是把同一段话数了两遍。

查这三处的成本极低：打开两个语言版本的页面，把结构化数据里的数字并排比一遍，五分钟就能确认。

## 混语言的评论区，会不会影响页面被判成什么语言？

## 正文短的页面最容易被拖偏

这条机制跟前面那篇讲合规弹窗是页面上第一段被读到的字 (https://zhangwenbao.com/minor-language-consent-banner-language.html)的完全一样，只是文本来源换了。

页面语言不只看标签上的声明，正文本身也是证据。

商品页的自有正文往往不长：标题、几行卖点、一张属性表。

评论区一旦有几十条，字数很容易超过自有正文。

于是出现一种尴尬的局面：这一页上写得最多的那门语言，不是你做这一页时打算用的那门语言。

这条机制跟合规弹窗那一篇讲的完全一样，只是文本来源从第三方工具换成了用户。

这两者合起来看会更清楚：一个页面上不由你产出的文字，一头在最上面，一头在最下面，中间夹着你自己写的那部分。

把两篇的结论合起来用有个好处：排查时可以一次做完，取一份不执行脚本的文档，从头到尾数一遍各语言的字数占比。

## 评论区在文档里的位置和体量

影响大小取决于两件事。

一是评论区是否在初始文档里，还是点击之后才加载。

二是默认展示几条，是三条还是三十条。

点击才加载的评论区几乎不参与判定，因为抓取程序不会点。

但这又带来另一个损失：那些评论里的真实用词也就进不了索引，而本站讲日本用户挑毛巾搜的是手感，那个词在你的属性表里连一格都放不下 (https://zhangwenbao.com/minor-language-onomatopoeia-texture-attribute-keyword.html)那一篇里，评论区正是最厚的一层长尾词矿。这两件事必须一起权衡，不能只顾一头。

还有一个变量是结构化数据块：有些评价插件会把全部评论正文都塞进标记里，哪怕页面上只显示三条。

那部分同样是文本，而且它在文档里的位置通常很靠前。

判断办法是直接看页面源码里那段标记的长度，如果它比可见评论区还长，就说明插件把全部评论都塞进去了。

## 一个可操作的比例判断

给个能直接用的口径。

把默认展示的评论总字数，除以这一页的自有正文字数。

比值低于二分之一，基本不用管。

比值超过一比一，且其中外语占多数，就该动手。

动手的方式不是删评论，是把默认展示条数调小，或者把同语言评论优先排在前面，让初始文档里的语言构成回到正常。

这个比值还有个副产品：它能帮你决定默认展示几条。多数站的默认值是插件出厂设置，从来没人按自己的页面体量调过。

## 排查动作：取一次不执行脚本的文档

验证方法跟讲合规弹窗那一篇 (https://zhangwenbao.com/minor-language-consent-banner-language.html)一样，两条命令。

取回原始文档，看评论文本在不在里面。

在，就数一数各语言的占比。

不在，说明评论是后加载的，这一项风险可以划掉，但要记得长尾词那一头的损失。

顺手看一眼结构化数据块里输出了几条评论正文，有些插件会把全部评论都塞进标记里，那部分同样是文本。

顺手也看一眼分页的第二页，很多站的第一页做了同语言优先排序，第二页往后就完全没有排序逻辑了。

顺手确认一下评论区的排序参数会不会产生新的地址，很多插件的排序切换会生成带参数的地址，那是另一笔账。

## 新语言版本上线那天，社会证明为零，怎么办？

## 页面齐了，评论是空的，这是必然

新语言版本上线时，页面可以一次性铺完，评论不行。

评论需要时间，需要订单，需要有人愿意回来写。

这个断档期通常是三到六个月。

而这三到六个月，正好是这个市场判断你值不值得信任的那段时间。

更麻烦的是这构成一个循环：没有评论所以转化低，转化低所以订单少，订单少所以评论更慢。这个循环不主动打破，它会自己延长。

这个循环还有一个加速恶化的分支：转化低会让团队怀疑这个市场不行，从而削减投入，于是订单更少。

很多市场就是这么在第一年被判了死刑，而根因只是社会证明还没长出来。

## 三条冷启动路径，成本和效果都不一样

第一条是跨语言展示：把别的语言的评论也显示出来，附译文或者不附。

第二条是加速征集：给新市场的首批买家单独设计评价邀请，用本地语言发，节奏比常规快一档。

第三条是换一种社会证明：本地媒体提及、本地论坛讨论、销量数字、退货率这类不依赖语言的信号。

三条可以同时用，优先级建议是第二条最高，因为它产出的是能长期留下的资产。

第一条见效最快但要设边界，第三条最容易被忽略，其实在评论为零的那几个月里，它是唯一能立刻上线的东西。

第二条最容易被低估。多数站的评价邀请是全站一个节奏、一个模板，新市场跟着老市场排，等于把最需要评论的那批订单排在了最慢的队里。

把新市场单独提前，几乎不增加成本。

第三条的门槛也比想象中低：本地媒体提及和销量数字这类信号，多数站其实已经有了，只是没被放到商品页上。

## 跨市场借用的边界，哪些能借哪些不能

这条边界前面提过一次，这里说细一点。

能借的是关于产品本身的：材质、尺寸、耐用度、安装难度、实际容量。

不能借的是关于交付的：物流时效、包装状态、关税、客服响应、退货是否顺利。

因为前者跨市场恒定，后者每个市场都不一样，借过来就是误导。

落地办法是按评论内容打标签，只把产品相关的那一类放进跨语言展示池。这个动作可以靠关键词规则做粗筛，再人工过一遍首批，之后按规则跑就行。

还有一类介于中间的内容：安装难度和说明书是否易懂。

这类通常可以借，但如果各市场的说明书语言版本质量不一样，就要单独判断。

判断能不能借还有一个更简单的问法：这条评论换一个国家的买家来写，内容会不会不一样？会，就不能借。

## 过渡期的展示方式，别假装满员

有个细节容易做错：把借来的评论混在本地评论里，不作区分。

正确做法是显式标出来自其他市场。

用户对这件事的接受度比想象中高，因为跨境购物本来就是常态。

反而是假装满员被识破的代价高，一旦用户发现评论里写的物流体验跟自己所在国家完全对不上，信任会一次性崩掉。

标注的成本是一行小字，收益是把一次可能的信任事故提前消掉。

标注的写法也有讲究：写来自其他市场比写机器翻译更中性，因为前者陈述事实，后者容易被读成质量声明。

还有一个做法是把跨市场借来的评论单独成组显示，加一个小标题说明这些来自其他市场的买家，比逐条标注更省版面。

## 问答区跟评论区是两回事，要分开管

## 问答的语体更书面，评论更接近搜索框

这两块内容常被合在一起讨论，其实性质差别很大。

评论是写给后来者看的经验描述，用词随手，接近人们在搜索框里打的字。

问答是提问，句式更完整，更接近人们在对话里的表达。

做词表采集时，两个区域要分开数，因为它们贡献的词形不一样。

本站讲德语站正文换成包容写法，可搜索框里用这种写法的人还是零 (https://zhangwenbao.com/minor-language-gender-inclusive-spelling-keyword-coverage.html)那一篇里也提过同一条：评价区和问答区的语体不同，统计写法分布时必须分开算，合在一起会把两种趋势平均掉。

分开数还有一个实际好处：问答里的问句形态可以直接拿去做页面小标题，评论里的短词更适合进属性表和筛选器。

两类词的落地位置本来就不同。

## 问答区你可以回答，回答用哪门语言是你的选择

这是问答区跟评论区最大的不同。

评论你不该动，问答里有一半内容是你自己写的。

官方回答的语言是你能决定的，那么该用什么语言回？

建议是跟提问者的语言一致，同时在页面语言版本下保留一份该语言的版本。

换句话说，一个用英语提问的德国用户，用英语回他，但这条问答不该只以英语形态存在于德语页上，最好补一句德语摘要，让读德语的后来者也能获益。

还有一个细节：官方回答里要不要出现品牌名的本地写法，取决于这个市场的品牌名是否已经定型。

本站讲品牌名进德语市场，比怎么拼更早要定的是它算公的还是母的 (https://zhangwenbao.com/minor-language-loanword-gender-assignment-brand-article.html)那一篇讲的定型判据，在问答区同样适用。

回答的时候还要注意度量单位：同一款收纳箱在德语市场说的是厘米，在英语问答里可能被问成英寸，答案里两个单位都给出来最稳。

## 同一个问题被多种语言重复问，怎么处理

这在多语言站上非常常见。

同一个尺寸疑问，德语问一遍、英语问一遍、荷兰语再问一遍。

合并是错的，因为合并会毁掉提问者的原话，而原话是长尾词的来源。

正确做法是各自保留，官方回答复用同一份内容的各语言版本。

这样每一门语言下都有一条完整的问答，问句是本地用户自己打的字，答案是你统一维护的，两边的好处都拿到了。

合并的另一个坏处是破坏了各语言版本的页面完整性：合并之后德语页上那条问答只剩英语原文，读德语的人依然看不懂。

各自保留还有个附带收益：同一个疑问在三门语言里各出现一次，说明它是真需求，值得把答案提到商品描述里去。

## 问答区的长尾价值，在小语种里更高

最后补一条容易被低估的判断。

大语种里，一个问题有几十个网站抢着回答。

小语种里，同一个问题往往整个语言里都没有一个像样的完整答案。

本站讲小语种的问答长尾没多少人搜，可整个语种里认真写完整回答的也没几家 (https://zhangwenbao.com/minor-language-qa-long-tail-content-value-ai-era.html)那一篇里算过：需求被证实存在，供给却是散装的，这是最好的机会区。

而你的问答区正好是这种散装讨论的集中地，只要把官方回答写得完整一点，它就同时是页面内容和搜索入口。

还有一个结构上的便利：问答天然是一问一答，跟人们在搜索框里打的完整问句形态非常接近。

在小语种里这类完整问句的竞争特别弱，因为没有多少站会为一个月几十次搜索的问题专门写一页。

从投入产出看，问答区是小语种站上性价比最高的一块内容，因为提问是用户免费提供的，你只需要把答案写完整。

## 一套能落地的评论语言治理清单

## 第一步补字段，没有字段谈不了策略

所有事情从这一步开始。

给评论数据加一栏语言，值取自提交时所在的站点语言。

历史数据跑一次语言识别补齐，识别不准的短评论标为未知。

顺带再加一栏，记录这条评论来自哪个市场，跟语言分开存。

语言和市场是两个维度，一位在德国的英语用户会同时出现在英语这一栏和德国那一栏，混成一栏之后所有分析都会失真。

补字段这件事在多数评价服务里只是加一个自定义属性，工作量以小时计。

真正的阻力通常来自没人认为它重要，所以立项时最好直接把后面那几项分析一并写进需求，让这个字段有明确的去处。

顺便把语言和市场两栏一起加上，后面所有分析都靠这两栏交叉，缺一栏就得重来一次。

## 第二步按市场分四档处理

第一档，本地语言评论充足的成熟市场：只显示本地语言，其余折叠。

第二档，本地语言过半但不多的市场：本地优先排序，外语评论保留在后面。

第三档，刚上线的新市场：开跨语言展示，只放产品相关的那一类，显式标注来源市场。

第四档，英语普及率很高的市场：不做任何过滤，按时间排序即可。

分档的依据是本地语言评论占比和市场英语能力两个数，每季度重算一次，档位会随着市场成熟自然往上走。

四档之间是会流动的，一个市场从第三档走到第一档通常要一年左右。

所以档位要写在配置里而不是写死在代码里，每季度重算一次，改一个值就能生效。

分档还要记一条例外：如果某个市场的评论虽然少但质量极高，比如全是长篇实测，那就不该按条数把它归进低档。

## 第三步定展示层的五条规则

一，聚合评分全语言合并，不按语言拆算。

二，评论正文按语言排序，读得懂的排前面。

三，译文必须标注为自动翻译，并保留原文入口。

四，默认展示条数控制在自有正文体量的一半以内。

五，跨市场借用的评论必须显式标出来源，且只借产品相关的那一类。

这五条建议直接抄进前端的验收清单，因为它们全都是可以肉眼验证的。

唯一需要看数据的是第四条，而那个比值前面已经给了算法。

五条规则里最容易被打回的是第三条，因为标注会让页面看起来不够顺滑，这时候可以把标注做小一点，但不能不做。

## 每季度要看的三个数

第一个数，各语言评论占比与订单地址国家占比的差值。差值大说明评价邀请的语言配错了。

第二个数，新语言版本上线后第一条本地语言评论出现的时间。这个数直接反映冷启动策略有没有效。

第三个数，默认展示评论字数与自有正文字数的比值。

三个数都能从现有数据里算出来，不需要新工具。

把它们放进季度复盘的固定项，这一页的问题就不会再等到某天有人偶然发现德语页面下面全是英语才被提出来。

三个数都能从现有数据里算出来，不需要新工具，唯一的前提是第一步的字段已经补上了。

把它们放进季度复盘的固定项，这一页的问题就不会再等到某天有人偶然发现德语页下面全是英语才被提出来。

顺带把这三个数跟本地语言评论的平均长度一起看，长度突然变短通常意味着评价邀请的落地页出了问题。

## 常见问题解答

## 德语商品页下面出现英语评论，需要处理吗？

先别急着屏蔽。判断依据是这个市场的英语普及率和这批评论的内容类型。荷兰、北欧这类市场保留原文完全可行；德国、法国这类市场建议本地语言优先排序、外语评论保留在后面并附标注为自动翻译的译文；日本、波兰这类市场英语评论对多数读者等于不存在，翻译收益最大。真正要避免的是一刀切过滤，因为被砍掉的往往是写得最细的那批，而评论条数是转化路径上最贵的资产之一。

补一条实操顺序：先调评价邀请的语言，再调展示规则。前者改变的是未来的评论构成，后者只是处理存量，顺序反了会一直在处理存量。

顺序反了还有一个坏处：展示规则改了之后数据会立刻好看，团队会以为问题解决了，而产生环节的偏差还在继续制造新的外语评论。

## 评论翻译会不会被判成低质内容？

风险确实存在，因为大批量、无人过目的机器翻译文本正是被明确点名的那一类，而评论区量大、模板化、铺满整个目录，三个特征全占。降低风险的做法有三条：标注为自动翻译、保留原文可访问、抽检一部分人工过目。注意规则针对的不是翻译这个动作，而是无人审核这个状态，所以标注和抽检本身就在改变性质。

还有一个折中做法值得考虑：只翻译最有用的那几条，比如被标记有用次数最多的前十条，其余保留原文并折叠。

## 各语言版本的星级和评论数，应该分开算还是合并算？

评分合并，正文分开。评分是数字，不承载语言，一位德国买家给的四星和一位英国买家给的四星是同一个四星，合并能让每个语言版本都有像样的样本量，也避免被少数极端评分带偏。正文按语言排序，把读得懂的排在前面。这样处理还顺手解决了新语言版本星级为零的问题。唯一要拆开的是物流与售后类的评价，因为那部分体验各市场确实不同。

顺便一提，有用票数、退货率这类数字型用户信号同样可以跨语言合并，判断标准是它需不需要读者懂这门语言才能起作用。

需要按语言分开的永远只有文本，因为只有文本要求读者会这门语言才能起作用，数字不需要。

## 评论区里的外语会不会让页面语言被判错？

有可能，取决于两件事：评论是否在初始文档里，以及默认展示的评论字数与自有正文字数的比值。商品页自有正文往往不长，几十条评论很容易超过它。比值超过一比一且外语占多数就该动手，动手方式是调小默认条数或让同语言评论优先排序，而不是删评论。用不执行脚本的方式取一次原始文档，数一数各语言占比，五分钟能确认。

如果评论是后加载的，这一项风险可以划掉，但要记得另一头的损失：评论里的真实用词也进不了索引。

## 新上线的语言版本一条评论都没有，怎么过渡？

三条路并行。加速征集：给首批买家用本地语言单独设计评价邀请，节奏比常规快一档，这是唯一能留下长期资产的一条。跨语言展示：把别的市场关于产品本身的评论借过来，显式标注来源，只借材质尺寸耐用度这类跨市场恒定的内容，物流关税客服体验一律不借。换一种社会证明：本地媒体提及、销量、退货率这些不依赖语言的信号，在评论为零的那几个月里是唯一能立刻上线的东西。

图片评论是这里的例外，实物照片跨语言完全通用，在评论为零的头几个月里它是唯一能立刻借来用的形态。

另外别忘了非语言的社会证明：销量、退货率、本地媒体提及，这几样在评论为零的头几个月里同样能立刻上线。

## 问答区要不要跟评论区用同一套规则？

不要。两者语体不同，评论接近搜索框里的用词，问答更书面完整，做词表采集时必须分开数。更重要的差别是问答里有一半内容是你自己写的：官方回答的语言是你能决定的，建议跟提问者的语言一致，同时在该语言版本下补一份摘要。同一个问题被多种语言重复问不要合并，各自保留，因为提问者的原话正是长尾词的来源，官方答案复用各语言版本即可。

还有一条：问答区的官方回答是你自己写的内容，它跟商品描述一样该进翻译流程，而多数团队从来没把它列进交付清单。

## 权威参考资料



## 稿子翻成波兰语之前先在英语站停了一趟，卸下去的那些东西没人清点

- URL：https://zhangwenbao.com/minor-language-pivot-english-relay-grammar-loss.html
- 分类：小语种SEO
- 发布：2026-06-22  |  更新：2026-07-30
- 摘要：母版做成英语再分发，等于让每一门语言的译员去猜原文里本来写着的东西。讲清哪些语法维度会在换乘时掉、补值从哪儿来、回译为什么反而给出一切正常的信号，以及哪几对语言最亏。
- 关键词：多语言SEO,内容本地化,小语种SEO

> **TLDR**：摘要：多语言项目十有八九是这么跑的：内容先做成英语，再从英语分发到各语种。这条路省钱，代价藏在换乘那一站——源语言里有而英语里没有语法位置的东西会被整个卸下去，比如名词的性别、名词算不算活的、动词是自动还是他动、敬语的档位。到了目标语言这些格子又必须填上，而填的人手里已经没有原件，只能按默认值猜。猜出来的句子完全合法，术语对得上，回译也能通过，所有关卡一路放行。检索那一侧同样在换乘。本文讲清哪些维度会掉、补值从哪儿来、为什么关卡查不出来、哪几对语言最不该走中转，以及那笔钱该怎么花。

> 摘要：多语言项目十有八九是这么跑的：内容先做成英语，再从英语分发到各语种。这条路省钱，代价藏在换乘那一站——源语言里有而英语里没有语法位置的东西会被整个卸下去，比如名词的性别、名词算不算活的、动词是自动还是他动、敬语的档位。到了目标语言这些格子又必须填上，而填的人手里已经没有原件，只能按默认值猜。猜出来的句子完全合法，术语对得上，回译也能通过，所有关卡一路放行。检索那一侧同样在换乘。本文讲清哪些维度会掉、补值从哪儿来、为什么关卡查不出来、哪几对语言最不该走中转，以及那笔钱该怎么花。

## 你的十几种语言，中间是不是都在英语这一站停过？

## 一家乐器配件站的波兰语页面，问题只在几个词尾上

有个客户做乐器配件，吉他弦、拾音器、谱架、管乐清洁套件这些。

总部在国内，内容先写中文，再翻成英语作为母版，然后从英语分发到十一种语言。

这条链路跑了三年，供应商稳定，交付准时，质量抽检的分数一直不错。

波兰语站上线两年之后，团队发现一个反常现象：品类页的表现明显低于同期的捷克语站。

两个市场规模接近，投入一样，内容是同一批，唯独波兰语这边始终起不来。

把波兰语页面的标题拉出来一批看，问题落在词尾上：几乎所有商品名都用的是词典原形，而波兰语用户在搜索框里打的形态跟原形不一样。这本身是屈折语的老问题，但真正让保哥停下来的是另一件事——同一批内容的捷克语版没有这个毛病。同一条链路、同一批译员管理流程，为什么两门同族语言的结果差这么多。

这个对照后来成了整件事最有力的证据。两个市场的其它条件几乎一致，内容出自同一批中文原稿，投放节奏也一样，唯一的差别就是中间那一站。拿这组对照去申请预算，比讲任何原理都管用，因为它把一个语言学问题变成了一个可以量化的差额。

## 差别不在译员，在链路上少了一样东西

追下去发现，捷克语那一侧的供应商是中文直接翻译的，波兰语走的是英语中转。

这个差别在项目文档里根本没写，它是采购时按报价选出来的自然结果。

中文原稿里，商品是被购买的对象，这一层关系在中文里靠语序和量词表达。

翻成英语之后，这层关系变成了一个宾语位置，词形上不留任何痕迹。

再翻成波兰语时，译员要为每个名词选一个格形态，而他手里只有英语那份没有痕迹的稿子。

波兰语的宾格还要看这个东西算不算活的，这条线画得很微妙，波兰语给笔记本电脑用的是买猫那个词尾 (https://zhangwenbao.com/minor-language-animacy-accusative-keyword-forms.html)那篇专门算过它在电商词表上的代价。链路里少的不是能力，是信息：英语那一站从来没有装过这个维度。

要说清楚的是，这不是译员水平的问题。那位波兰语译员的母语能力毫无问题，他产出的句子地道自然。他只是在为每个名词选形态的时候，手里没有任何依据可用，于是按最常见的那一种填。换任何一位同样优秀的译员，结果都一样。

## 中转这件事没人决定过，它是被采购价选出来的

问项目组谁定的这条链路，通常没人答得上来。

因为它不是一次决策，是十几次独立的供应商选择叠出来的结果。

每一次选择看的都是单价、交期和这家能不能接这个语种。

中文直译到小语种的译员稀缺、报价高、交期长，英语中转的供给则充足得多。

于是每一次都选了后者，而十几次同样的选择合起来变成了一条全站的架构。

这是这件事最典型的形态：它从来不出现在架构评审里，只出现在采购单里。等到有人开始查为什么某几门语言长期落后，链路图才被第一次画出来，而画完往往就能看懂一半。

这类由多次局部选择叠出来的架构，在多语言项目里不止这一处。语言标签怎么配、地址结构怎么定、模板由谁维护，很多都是这么长出来的。共同特征是每一次单看都合理，合起来却没人能解释为什么是现在这个样子。发现它们的唯一办法就是定期把全景画一次。

## 先把自己的链路图画出来，这一步比什么都重要

画法很简单，一行一门语言，写清楚这门语言的稿子是从哪份稿子翻过来的。

把中文直译的标一种颜色，英语中转的标另一种。

再加一列写清楚这一门是人工翻译、机器翻译加人工审校，还是纯机器。

两列一交叉，哪几门语言处在最脆弱的格子里立刻就看得出来。

这张图画完通常只要一个下午，而它能解释掉过去两年里好几个说不清楚的现象。

## 英语这一站有几个格子，源语言的东西装不装得下？

## 换乘站只能转运它自己有格子装的东西

把翻译链路想成货运换乘会很直观：每一站的分拣能力决定了什么能被转下去。

英语的语法系统里，名词不分性别，不变格，不区分算不算活的。

动词不分自动他动，没有敬语层级，也没有专门的形态表示这话是听来的。

这些东西在英语里不是被省略了，是压根没有对应的位置。

没有位置意味着译员在第一段翻译时，连保留它的动机都不存在。

这句话值得多说一句：如果英语只是习惯性省略，那还能靠规范要求译员补注；而它是结构性缺位，任何规范都无法要求一个人在没有格子的表格里填一个值。所以这不是流程能修的问题，是链路本身决定的。

顺带说一句，这个比喻里有一处不太贴切但值得点破：货运换乘至少会留下一张清点单，你知道少了什么。语言这一站连清单都没有，因为丢掉的东西在英语的世界观里根本不构成一个类目，没有人会为一个不存在的类目做记录。

## 信息在这一站被合并，而合并是不可逆的

源语言里两个不同的词，到英语可能变成同一个词。

日语里表示东西自己坏了和表示人把东西弄坏了，是两个不同的动词。

英语用同一个词兼两职，靠句子结构区分，词形上完全一样。

翻回去的时候，译员要从一个词里重新选出两个中的一个。

这两组词在用户那一侧对应完全不同的搜索场景，用户搜的是症状你写的是服务 (https://zhangwenbao.com/minor-language-intransitive-transitive-verb-pair-keyword.html)那篇拆过这条错位的商业后果。

合并的方向还有个规律：源语言里区分得越细的维度，在英语里被合并得越彻底。日语的自动他动是两个词合成一个，敬语的三四个档位合成一个中性表达，斯拉夫语的六七个格合成一个介词加名词。区分越细的地方，损失越大，这跟直觉正好相反。

## 哪些维度会掉，可以列成一张清单

名词的语法性别，英语没有，德语法语俄语波兰语都有。

名词的格，英语只在代词上留了残迹，斯拉夫语族和芬乌语族全都有。

生命度，英语完全没有，斯拉夫语族用它决定宾格形态。

敬语层级，英语靠词汇和句式表达，日语韩语是语法强制的。

动词的体、双数、定指标记、话题标记，同样一个都装不下。

清单之外还有一类不属于语法但同样会掉的东西：文化预设。中文原稿里默认读者知道的常识、默认的礼貌距离、默认的推荐语气，翻成英语时会被英语的默认值替换一次，再翻到目标语言时又被替换一次。这一类更难量化，但方向是一致的。

## 这张清单要按你自己的语言组合裁剪

通用清单没用，有用的是你那几门语言各自缺哪几格。

做法是把源语言和每一门目标语言的语法特征列出来，对照着找差集。

这件事不需要语言学训练，公开的语法特征标注体系已经把各语言标好了。

把两门语言的特征表并排放，英语那一列是空的而两端都有值的那几行，就是会掉的东西。

这张表做一次能用很多年，因为语言的语法特征不会变，变的只是你做哪些市场。

做这张表的时候有个省事的顺序：先列目标语言有而英语没有的维度，再看源语言在这些维度上有没有对应表达。两边都有的那几行才是真正的损失点。只有目标语言有的那些行不算损失，因为源语言里本来也没有，译员从任何链路都得靠推断。

## 下一站必须填上的那个值，是从哪儿来的？

## 目标语言不允许留空，这是问题的关键

如果目标语言允许不填，这件事就只是信息量减少，不至于出错。

但语法是强制的：你写一个德语名词就必须带冠词，写波兰语宾语就必须选一个格。

译员不能写一个没有性别的德语名词，就像不能写一个没有时态的英语动词。

于是缺失的信息在这一步被强制补全，而补全的依据不是原文。

这就是整条链路上最关键的一次转换：一次有损压缩，接着一次必须给出确定值的解压。

这也是它跟一般翻译损失最本质的区别。一般的翻译损失表现为信息变少，读者能感觉到句子干瘪。这一类损失表现为信息被替换成了一个确定的错值，读者感觉不到任何缺失，因为句子是完整的、具体的、语法正确的，只是那个值不是原文的意思。

## 第一个来源是目标语言的默认值

每门语言在拿不准的时候都有一套默认倾向。

性别拿不准就用阳性，数量拿不准就用单数，视角拿不准就用他动词。

敬语拿不准就用中性偏客气的档位，这在日语里意味着一整套词形。

默认值本身没错，问题在于它是统一的，而原文里那些值是各不相同的。

统一的默认值会让整批内容往同一个方向偏，偏移量不大但覆盖面是全站，这比零散的错误更难被发现。

默认值的方向还可以预测，这对排查很有用。性别默认阳性、数默认单数、视角默认施事、语气默认中性偏正式、体默认完成。知道方向之后，抽检时就不必随机抽，直接去查那些原文本来应该是非默认值的句子，命中率会高得多。

## 第二个来源是译员的个人习惯

同一批稿子换一个译员，补出来的值会不一样。

这在单篇上看不出来，在批量交付上就变成了前后不一致。

前后不一致比一直错更伤，因为一直错读起来像外国人写的，不一致读起来像几个人拼的。

品牌名的语法性别是这类不一致的重灾区，同一个站里出现三种冠词是常事。

这件事在品牌名进德语市场比怎么拼更早要定的那件事 (https://zhangwenbao.com/minor-language-loanword-gender-assignment-brand-article.html)那篇里拆得最细，而中转链路会让它发生的概率成倍上升。

这类不一致有个很实用的检测办法：把同一个词在全站所有页面上的形态列出来做频次统计。真正统一的词只会出现一两种形态，出现三种以上的基本可以断定是不同批次不同译员补出来的。这个统计不需要懂那门语言，字符串比对就够。

## 第三个来源是机器翻译的统计倾向

链路里如果有机器翻译这一环，补值就交给了训练数据里的高频形式。

高频形式在多数情况下是对的，这正是它难查的原因。

它在职业名词、家庭角色、专业身份这几类词上偏得最明显。

低资源语言上这种偏移更大，因为可用语料本来就少。

机器翻译直接发布的整体风险在机器翻译发上线省下的那道审校，最后是拿收录和排名分期还的 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)那篇里列过，中转链路相当于把这份风险乘以链路的段数。

还有一层要注意：链路里的机器翻译经常是隐性的。供应商用工具做预翻译再人工润色，这在行业里是常规操作，通常不会写进交付说明。润色的人只改读起来别扭的地方，而默认值补出来的句子读着不别扭，于是原样保留。

## 补出来的句子在语法上完全合法

这一点必须单独说，因为它决定了所有检查工具的表现。

猜错的性别、猜错的格、猜错的动词，产出的都是合乎语法的句子。

拼写检查通过，语法检查通过，可读性评分甚至可能更高。

只有母语用户读到具体那一句时才会觉得别扭，而他不会来告诉你。

更常见的情况是他连别扭都感觉不到，只是在搜索结果里没找到你，然后去了别家。

这条性质决定了一件事：任何以合法性为判据的自动检查都拦不住它，加多少道工具都没用。要拦住它，判据必须涉及原文，也就是必须有人拿着源语言的稿子逐句对。这是整件事里唯一一个不能自动化的环节，也是为什么它在流程上一直是个空白。

## 为什么所有质量关卡都不会报警？

## 术语检查只看词，不看词形

术语库比对的是词条是否被正确使用，比对的对象是词干或者原形。

形态变化和语法特征不在它的检查范围内，它也没有能力检查。

于是一份每个术语都用对、每个词形都选错的稿子，术语检查是满分。

这跟锚文本报告里精确匹配那一栏的数字是假的属于同一种失真。

口径要从字符串换成词干还是换成别的，屈折语站的锚文本报告精确匹配那一栏是假的 (https://zhangwenbao.com/minor-language-internal-link-anchor-inflection-variants.html)那篇给过一套换法。

术语库还有一个更隐蔽的副作用：它会给人一种已经检查过了的踏实感。看到术语一致性报告是满分，很少有人会追问这份报告到底检查了什么。报告的覆盖范围写在工具文档里，但没人会为一份满分的报告去翻文档。

## 回译在这件事上帮的是倒忙

回译是把译文再翻回源语言，看意思有没有跑偏，很多团队拿它当兜底。

但中转损失恰好是往返对称的：去程丢掉的维度，回程同样不需要它。

波兰语译文里的性别猜错了，翻回英语时性别本来就不出现，回译结果完美一致。

于是回译不但查不出来，还会给出一个一切正常的强信号。

母语审校的验收该看哪几层，一句读着自然不能当成验收通过的判据 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)那篇列过一份清单，回译的能力边界在那篇里已经点过，这里是它失效得最彻底的一个场景。

回译还有一个更麻烦的性质：它给出的是强阳性信号。如果它只是查不出来，最多是漏检；而它实际给出的是一切正常的结论，这会让团队主动关闭其它检查渠道。一个失效的检查工具比没有工具更危险，因为它占据了本该由别的办法填补的位置。

## 母语审校能查出来，但通常不会被这么用

母语审校当然读得出别扭，问题在于他被交代的任务是什么。

大多数审校简报写的是检查通顺度和术语一致性，没写检查语法特征选得对不对。

审校看到一个合法的句子，默认它是对的，除非读起来明显不自然。

而默认值补出来的句子恰恰读起来相当自然，它只是跟原意不一致。

要让审校查出来，必须给他原文，而中转链路的审校手里通常只有英语版。

改法很简单：在审校简报里加一句，要求逐项确认名词的格与性别、动词的视角、承诺句的强度是否与原文一致。加这一句的成本是零，而它把审校从通顺度检查变成了一致性检查，这两件事的产出完全不同。

## 唯一有效的检查是回到源语言比对

把中文原稿和波兰语译文并排放，请一个懂两头的人抽检十句。

抽检的问题要具体：这句里的这个名词，原文说的是活的还是不是活的。

问得越具体，不懂那门语言的人也能组织这次检查。

十句抽检就能判断这条链路有没有系统性偏移，因为偏移是全局的不是零散的。

成本是半天，而这半天买到的是这条链路值不值得继续用的答案。

抽检的句子怎么挑也有讲究。优先挑三类：带商品名的标题、含承诺的政策句、以及常见问题里的问答对。这三类的共同点是短、密度高、而且直接影响检索和转化。挑长段落做抽检看起来更认真，实际上信息密度低，性价比反而差。

## 用户的查询也在换乘，这一侧同样有一次损失

## 跨语言检索会把查询翻过去再匹配

搜索这一侧近些年多了一条路径：本地语言的查询被翻译成其它语言去检索。

搜索引擎公开说明过它会为部分查询提供翻译后的结果，这条路径是明示的。

翻译查询和翻译内容的损失机制完全一样，只是方向反过来。

用户打的那个带格尾的波兰语词，翻成英语之后格尾消失了。

再拿英语去匹配英语内容，能匹配上的正好是那些没有格的表达。

这条路径对你的实际影响取决于本地语言内容的供给量。本地内容充足的市场，引擎没有理由去翻译别的语言给用户看；本地内容稀缺的市场，翻译路径的占比就高。所以它同时是一个市场成熟度的指标：翻译结果出现得越多，说明这个语种的原生内容缺口越大。

## 生成式回答那一侧的链路更长

用小语种提问，模型可能用英语检索资料，再用小语种把答案写出来。

这条链路里有两次换乘，一次在检索前，一次在生成时。

答案读起来很流畅，因为生成那一步的语言能力确实不错。

但它引用的来源是哪门语言，跟它回答用的语言不是一回事。

这两个字段该分开记，回答用的是你的语言引用的来源却是一水儿的英文页面 (https://zhangwenbao.com/ai-search-language-bias-low-resource-citation-source-audit.html)那篇给过实测的做法。

这条链路上还有一层容易被忽略：模型给出的答案可能是从英语资料翻译过来的，而那份英语资料本身可能又是从别的语言翻过去的。链条一长，最初那个语言的语法信息早就不知道在哪一站掉光了，而最终读者看到的是一段流畅的本地语言文字。

## 提示词那一侧也在做同一件事

做跨语言监控的时候，很多团队把同一句提示词翻成十几种语言去问。

翻译提示词等于在监控环节又引入了一次同样的损失。

问出来的差异有一部分来自模型，有一部分来自你自己的翻译。

把这两部分混在一起，得到的结论会指向错误的动作。

提示词的翻译等价性问题在品牌名在俄语里是西里尔在日语里是片假名，你那个数提及次数的脚本一个都认不出来 (https://zhangwenbao.com/cross-lingual-brand-mention-monitoring-key-baseline.html)那篇里讨论过，做监控的人要先把自己这一侧的损失扣掉。

解决办法不是不翻译提示词，而是把翻译这一步固定下来并留档。同一句提示词的各语言版本一次定稿，之后每次监控都用同一批，这样至少保证了历次结果之间可比。变的是模型，不变的是你的问法，这是做任何纵向监控的前提。

## 这一侧你控制不了，但可以用它反推该做什么

检索侧的换乘不是你能改的，它发生在别人的系统里。

能做的是让自己的页面在两条路径上都站得住。

一条是本地语言的直接匹配，需要页面上真的写着用户打的那些形态。

另一条是翻译后的匹配，需要页面的语义结构清晰、事实明确。

两条路都要走通，而第一条只有本地语言原生内容能做到，翻译过来的内容天然吃亏。

还有一个可操作的推论：越是本地语言原生内容稀缺的市场，你做原生内容的相对收益越高。因为在那种市场里，检索侧不得不依赖翻译路径，而你是少数几个能提供直接匹配的来源之一。这跟通常按市场规模排优先级的思路正好互补。

## 哪几对语言最不该走中转，怎么判？

## 判据只有一条：两端共有而英语没有的维度有几个

源语言和目标语言都有某个语法维度，而英语没有，这个维度就会白白损失。

两端共有的这类维度越多，中转的代价越大。

中文到波兰语看起来差得很远，但中文的很多信息本来就要靠上下文推断，损失反而没那么集中。

俄语到波兰语则不一样，两门语言共享性别、格、生命度、体四个维度，全部要在英语那一站被丢掉。

越近的两门语言走中转越亏，这是个反直觉但很硬的结论。

这条判据还能反过来用在供应商谈判上。当你能说清楚这两门语言之间有四个维度会在中转时损失，直译的溢价就有了具体的依据，而不再是一句质量更好。采购最怕的就是没有量化依据的质量论证，而这件事恰好可以数出来。

## 近亲语言之间本来可以直接对应

俄语的六个格和波兰语的七个格之间有相当稳定的对应关系。

直接翻译的译员可以逐格映射，几乎不需要判断。

走英语中转之后，这套现成的对应关系被彻底浪费掉，每一格都要重猜一次。

捷克语和斯洛伐克语之间的复用判据在捷克语和斯洛伐克语分家之后关键词就再没合并回同一套 (https://zhangwenbao.com/czech-slovak-seo-content-reuse-decision.html)那篇里算过，那套判据的前提正是两门语言可以直接对照。

把近亲语言拆进两条各自经过英语的链路，等于亲手把这份天然的红利丢掉。

近亲语言之间还有一层红利同样被中转浪费掉：术语和固定搭配可以大面积复用，只需要按规律做形态调整。走中转之后，两门语言各自从英语出发，产出的术语选择常常不一致，于是本来能共享的一套词表分裂成了两套，维护成本翻倍。

## 敬语系统是另一个必须直译的信号

日语和韩语都有语法化的敬语，英语没有对应结构。

从日语翻到韩语，敬语档位可以近似对应，中转之后只能凭默认值重建。

敬语档位选错不影响排名但明显影响转化，这一层在日语页面写得越客气跟用户搜的那串字差得越远 (https://zhangwenbao.com/japanese-seo-keigo-politeness-levels-conversion-ranking.html)那篇里量化过。

东亚这几门语言之间的内容如果要互相复用，直译几乎是唯一选项。

好消息是这几门语言之间的直译译员供给远比欧洲小语种之间充足。

东亚这几门语言之间还有一个额外的复用点是汉字词。同一个概念在中日韩里常有共享的汉字词根，直译时这层对应关系是现成的，走英语中转之后完全消失，译员会从英语的通用词重新选一个本地说法，结果往往是一个更口语但检索量更低的词。

## 承诺型内容不管什么语言组合都别走中转

退货政策、保修条款、合规声明这几类，句子里的强度是有法律含义的。

情态词的强度刻度在各语言之间本来就不一致，多过一道手只会更偏。

承诺被译软这件事在退货政策那句承诺译成日语之后字面写出来是不这么做就不行 (https://zhangwenbao.com/minor-language-modality-obligation-commitment-strength.html)那篇里拆过机制。

常见问题区里的否定问句同样危险，答反了一个字都挑不出错。

那类问答的极性验收清单在那句日语回答一个错都挑不出来只是把能退货答成了不能退 (https://zhangwenbao.com/minor-language-negative-question-answer-polarity.html)那篇里给过，走中转的链路要把这份清单的执行频率提高一档。

这几类内容还有个共同特点：它们的字数在全站占比很低，通常不到百分之几。把它们单独抽出来走直译，成本增量几乎可以忽略，而它们恰好是法律风险和转化影响最集中的那部分。这是整篇里投入产出比最高的一个建议。

## 不走中转要多花多少钱，这笔账怎么算？

## 先算差价，通常没有想象中那么吓人

中文直译到小语种的单价高于英语中转，这是事实。

但差价要放在整页成本里看，翻译费在一个页面的全生命周期成本里占比不高。

把设计、开发、图片、维护摊进去之后，翻译差价往往只是个位数百分比。

而它影响的是这批内容能不能被搜到，那是零和一的差别。

用这个口径去谈预算，比单纯说直译质量更好要有说服力得多。

算这笔账的时候记得把返工成本算进去。走中转的内容将来一旦要修，修的是已经上线的页面，要重新走审校、重新上线、重新等收录，成本远高于第一次就做对。把返工概率乘进去之后，直译的差价往往在账面上直接就抹平了。

## 不必全站直译，按页面类型分档就够

转化型页面和承诺型页面直译，说明型和辅助型页面可以接受中转。

品类页、商品页、退货政策、常见问题划进第一档。

博客、资讯、帮助文档划进第二档。

这样直译的量通常只占全站的两三成，成本立刻降到可谈的范围。

分档这件事跟机器翻译的四档处理策略是同一套思路，只是分档依据从质量风险换成了信息损失。

分档还有一个执行上的好处：它让这件事变成一条可以写进流程的规则，而不是每次都要讨论的判断题。规则写清楚哪几类页面必须直译，采购下单时按类目走，不需要每次都请一个懂语言学的人来拍板。

## 关键词表必须用源语言到目标语言直接做

就算正文接受中转，关键词表这一件事绝对不能中转。

词表走中转的后果是整张表都是词典原形，因为英语那一侧没有形态。

而用户搜的恰恰是各种形态，这正是本文开头那个波兰语站的病根。

词表要用目标语言的真实数据建，工具没数据的时候有一套土办法可用，工具返回的那个零是数据缺口不是需求缺口 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)那篇里写了三条。

这是整篇里最值得先做的一件事：词表的重建成本远低于正文重译，而它带来的变化最直接。

更准确地说，词表根本不该走翻译流程，它该走调研流程。翻译流程的输入是一份稿子，调研流程的输入是目标市场的真实数据。这两件事被混在一起，是很多多语言站词表质量差的根源，而中转链路只是把这个根源暴露得更明显。

顺带一提，用目标语言直接做词表还会捞出一批走中转永远捞不到的词，其中有一类比较特殊：查得到量、也知道用户在搜、页面上却不能写，那个词每月几万次搜索却印在别人的商标证上 (https://zhangwenbao.com/minor-language-genericized-trademark-category-keyword.html)那篇讲的就是这一类怎么标怎么用。

## 已有的中转内容要不要全部重做

不要，按流量和转化排序，先重做头部那批。

重做的时候优先修标题、商品名、常见问题这几处，正文可以放在后面。

这几处的字数少、杠杆大，改动量跟收益完全不成比例。

剩下的长尾内容可以维持现状，等到下一次改版再一起处理。

全站重译听起来彻底，实际上会把预算耗在收益最低的地方，还容易半途而废。

重做的时候有个顺序上的技巧：先改词表和标题，观察一到两个月，再决定要不要动正文。多数情况下前者带来的变化已经能满足预期，正文重译可以无限期推迟。这个顺序还能保护预算，因为它先花小钱验证了方向对不对。

## 把换乘站换成别的语言，问题会不会小一点？

## 枢轴的选择标准不是它有多大

很多人默认英语当枢轴是因为它资源最多，这个理由本身没错。

但从信息损失的角度看，枢轴该选的是跟两端共有维度最多的那门语言。

做罗曼语族的多语言站，用西班牙语当枢轴比英语损失小，因为性别和数至少保住了。

做斯拉夫语族的站，用俄语或波兰语当枢轴能同时保住性别、格和生命度。

这条判据很少被写进本地化方案，因为方案通常是按供应链而不是按语法写的。

这条标准还能解释一个经常被误解的现象：为什么有时候从中文直接翻到某些小语种，质量反而比从英语中转好，尽管中文和那门语言差得更远。因为距离远近不重要，重要的是中间那一站有没有把两端共有的维度丢掉。

## 换枢轴的代价在供给这一侧

用西班牙语当枢轴的前提是你能找到西语到各小语种的译员。

这个供给确实比英语差，但在罗曼语族内部并没有差到不可行。

斯拉夫语族内部同理，俄语到波兰语、捷克语的译员供给相当充足。

所以这件事在语族内部是可行的，跨语族才真正回到英语。

换句话说，正确的架构不是一个全球枢轴，而是几个按语族分的区域枢轴。

区域枢轴还有一个现实的落地方式：不必换供应商，只需要换派单的源文件。很多本地化服务商本身就有多语种能力，你把西班牙语版而不是英语版作为源稿发过去，链路就变了。这个改动小到可以先在一两门语言上试。

## 区域枢轴还能顺带解决另外两件事

同一语族内的市场，用词习惯和文化预设也更接近。

近亲语言之间的假朋友和意图漂移，用同族枢轴处理时更容易被发现。

两个市场的关键词表可以一字不差而落地页要拆开，这类判断在同族之间才做得准，关键词表可以一字不差落地页却得拆成两种 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)那篇讲的正是这层。

审校资源也能共享，一个懂两门近亲语言的人可以同时看两个市场的稿子。

所以区域枢轴不只是省下了信息损失，还顺带把审校成本降了一档。

要注意的是同族枢轴也有它的风险：假朋友在近亲语言之间最密集，译员容易因为两门语言长得像而放松警惕，直接照搬那些看着一样意思却不同的词。所以换成区域枢轴之后，审校的重点也要跟着换，从形态一致性转到假朋友核查。

## 什么情况下老老实实用英语就行

两端本来就没有共同的语法维度时，中转的损失确实很小。

比如中文到印尼语，两门语言都不变格不分性别，英语这一站没什么可丢的。

再比如中文到越南语、泰语，形态都很轻，损失集中在别处而不在语法上。

这类组合完全可以走中转，把省下来的预算投到真正会掉东西的那几门语言上。

东南亚三国在语言层的差异集中在别的地方，越南泰国印尼被放进同一张预算表语言层三家没有一处能共用 (https://zhangwenbao.com/southeast-asia-seo-vietnam-thailand-indonesia-language-layer.html)那篇拆过它们各自的成本结构。

这一档语言还有一个附带的判断：既然中转损失小，那这几门语言的问题多半在别的层面上，比如分词、书写系统、本地平台生态。把精力放对地方，比在链路上做无用功重要得多。诊断的价值一半在于确认哪些方向不用查。

## 链路改短之后，怎么确认真的改善了？

## 动手之前先把基线存下来

这类改动的效果是渐进的，没有基线就永远说不清楚它有没有用。

要存的第一份是这几门语言的品类页表现，按语言分开，别看全站汇总。

第二份是词表本身，把改之前那一版完整留档，将来要靠它算覆盖率的变化。

第三份是一批代表性页面的原文快照，二三十个页面就够，用来做前后对照。

三份材料加起来半天能存完，而没存的团队通常在三个月后开始互相说服对方效果存在与否。

## 最先会动的是这三个数

第一个是站内搜索的零结果率，词表改对之后它掉得最快，通常几周就能看出来。

第二个是长尾查询的覆盖数量，也就是有多少个不同的查询词能给你带来访问。

第三个才是流量本身，它动得最慢，因为页面和查询之间的关联需要时间重建。

按这个顺序看数，能避免在最该有耐心的时候下错结论。

这三个数还有一个共同的好处：它们都不依赖排名工具，站内日志和站长后台就有，小语种上尤其可靠，因为第三方工具在这些语言上的数据本来就薄。

## 对照组要在同一语族里选

最理想的对照是同语族的两门语言，一门改链路一门不改。

这类对照能把市场因素、季节因素、算法波动全部抵消掉。

本文开头那家乐器配件站的波兰语和捷克语就是天然的一对，只是当时没人打算拿它做实验。

找不到同语族对照的时候，退一步用同一门语言的不同页面类型做对照也行。

要避免的是拿改动前后的全站数据直接比，那里面混进来的变量太多，得出的结论既不可信也说服不了任何人。

## 三个月看不出变化时该怀疑什么

先怀疑改动有没有真的落地，尤其是标题和商品名这些由模板生成的位置。

再怀疑词表改完之后有没有同步到筛选器、面包屑和内链锚文本。

然后才怀疑这门语言的问题不在链路上，可能是内容量本身不够。

还有一种情况是这个市场的搜索需求本来就小，语言层修得再好也撑不起预期。

把这几个怀疑按顺序排一遍，通常在第二条就能找到答案，因为词表下游的那几处几乎总有一处没跟上。

## 这跟十份译文出自同一篇原文不是一回事

## 一个是横着看的多样性，一个是竖着看的保真度

十种语言的内容都翻自同一篇英文，问题是这十份资料在信息上等于一份。

这件事伤的是引用价值：谁把它们并排放，都会发现口径高度一致却没有独立来源。

本文讲的是另一件事：每一份译文自己内部就有信息损失。

前者是横向的，问的是你有几个独立信源；后者是纵向的，问的是这一份还剩多少原意。

两件事可以同时发生，而且经常同时发生，因为它们出自同一条链路。

两者还有一个共同的成因值得点出来：都是为了省钱而做的架构选择。用一份英文稿分发到十几种语言，同时省下了内容生产成本和翻译成本，代价分别落在多样性和保真度上。这两笔代价当年都没被记账，多年之后才以流量的形式被追讨。

## 两者的修法不一样

同源问题的解法是加原生内容，让至少一部分市场有本地采写的资料。

损失问题的解法是缩短链路，让翻译从源语言直接到目标语言。

前者是加法，后者是改路径，预算科目都不一样。

同源那一层的判断办法在十种语言里十份口径一致的资料回头一查是同一篇英文翻出来的 (https://zhangwenbao.com/untranslated-invisible-ai-retrieval-translated-content-tradeoff.html)那篇里有完整的自查流程。

把两件事分开谈，跟管理层要资源的时候才说得清楚要的是什么。

预算科目不同这件事在实际推进中很关键。缩短链路的钱出在本地化预算里，通常由项目经理就能决定；新增原生内容的钱要走内容生产预算，往往需要更高层级的批准。所以前者能立刻开始做，后者要排进下一个预算周期，这也决定了两件事的先后。

## 诊断顺序建议先查损失再查同源

损失问题更便宜也更快见效，改词表和改标题就能出结果。

同源问题要新增内容生产，周期以季度计。

先做见效快的那件事，也能给后面那件事争取到预算。

而且损失修完之后，同源问题的严重程度会重新评估一遍，有些市场可能没那么急。

顺序反过来的团队，通常在原生内容还没产出的时候就把耐心用完了。

还有一个顺带的好处：修完损失之后，团队对这几门语言的实际潜力会有更准确的判断。有些市场在语言层修好之后表现直接上来了，说明它本来就有需求；有些修完仍然不动，那才说明问题在需求侧，值得重新考虑要不要继续投。

## 哪些事不归这一层管

供应商怎么招、怎么议价、怎么做质量考核，那是采购和供应商管理。

内容本身写得好不好、选题对不对，那是内容策略。

页面模板、地址结构、语言标签怎么配，那是站点架构层的事。

这一篇只回答一件事：从源语言到目标语言这条路上，有哪些语法信息掉在了中间那一站。

把这件事单独拎出来，最大的好处是它有明确的判据和明确的修法，不像质量这个词那样人人都能有一套说法。

## 常见问题解答

## 怎么快速知道自己站上的某一门语言是不是走了中转？

问三个人通常就够：内容负责人、本地化项目经理、以及实际下单给供应商的那个人。第三个人给的答案最准，因为采购单上写着源语言字段。如果三个人的答案不一致，那本身就是个结论——链路没人在管。还有一个不用问人的办法：调出这门语言最近的一批交付文件，看附带的项目文件里源语言写的是什么。

更硬的证据是拿译文本身找痕迹。中转过的稿子有几个常见特征：句子长度分布跟英语高度接近、被动语态比例偏高、复合句结构像英语而不像目标语言。这几项都能用简单的统计脚本跑出来，跟一批本地原生内容做对照，差异往往一眼可见。

## 用大模型做翻译，还存在中转损失吗？

存在，但形态变了。模型不像人工链路那样必须先产出一份完整的英语稿再翻过去，所以那种硬性的中间落地少了。但训练数据以英语为主这件事没变，模型在处理低资源语言时的内部表示仍然高度依赖英语，学术界很早就在讨论这种以英语为中心的结构会带来什么。实际表现是：源语言里那些英语没有的维度，模型同样容易按目标语言的高频默认值填。

可控的地方在于你能把原文直接给它，不必先经过一份英语稿。所以用模型翻译时最重要的操作是别偷懒走两步：直接从源语言到目标语言，并且在提示里明确交代那几个关键维度的取值，比如这个名词指的是活物、这句话的动作是自己发生的。把这些交代清楚，等于人工替它补上了那个缺失的格子。

## 不懂目标语言，怎么验收这几个维度选得对不对？

把验收问题设计成是非题，不懂那门语言也能组织。比如挑十个商品名，问审校这个词在这句里用的是不是宾格形态；挑五句退货承诺，问这句的强度是必须还是建议；挑三段常见问题，问这个回答是肯定还是否定。问题越具体，答案越不依赖你的语言能力。

关键是把原文一起给他，而且要给源语言原文不是英语版。中转链路的审校通常只拿到英语版，这一步不改，验收就永远只是在验英语到目标语言这一段，前面那一段的损失一直在盲区里。改动成本几乎为零，只是在派单时多附一个文件。

## 关键词表也走了中转，重建的成本有多大？

比想象的小。词表重建的主要工作量在数据获取而不在翻译，而数据获取本来就要用目标语言做。真正需要的是找一个母语者把核心品类词的常用形态过一遍，通常一两天能覆盖几百条核心词。相比之下正文重译是按字数计费的，量级完全不同。

顺序上建议先重建词表再动内容，因为词表是下游一切的输入：标题模板、面包屑、筛选器命名、内链锚文本，全都从它继承。词表不改就重译正文，等于拿新译文去凑一套旧的错词，返工两次。这个先后关系在多语言项目里几乎是通用的，只是走中转链路的站受影响更大。

## 供应商说他们是母语译员，是不是就没有中转问题了？

母语译员说的是译入语是他的母语，这跟他手里拿的是哪一份稿子是两件事。一个波兰语母语译员完全可能拿着英语稿在工作，这在行业里非常普遍，而且并不算偷工减料，因为项目就是这么派的。要确认的问题应该问得更直接：这份稿子的源语言是什么，译员懂不懂源语言。

问的时候要注意用词，问是不是母语译员得到的答案永远是肯定的。有效的问法是要求在项目文件里写明源语言字段，并要求译员具备源语言到目标语言的语言对资质。把这一条写进采购要求，比事后抽检有效得多，成本也只是合同里的一句话。

## 中转损失和翻译质量差，怎么区分？

判断标准是错误的形态。质量差表现为零散的、不成规律的错误：这里用词不当，那里句子不通，读起来能明显感觉到粗糙。中转损失表现为系统性的、高度一致的偏移：全站的名词都用同一种默认形态，全站的承诺都比原文软一档，全站的动词都站在同一个视角。

所以判别办法是看错误分布而不是看错误严重程度。抽二十个页面，如果同一类问题在二十个页面上以同样的方式出现，那不是译员水平问题，是链路问题。换译员解决不了链路问题，这也是很多团队换了几轮供应商仍然没改善的原因。

## 这件事该由谁牵头推动？

应该是同时看得到内容和数据的那个人，通常是负责多语言优化的那一位。内容团队看得到质量但看不到搜索表现，采购看得到链路但不知道它的后果，本地化项目经理夹在中间通常只对交期和预算负责。只有把链路图、语法特征差集和各语言的搜索表现放在同一张桌上，这件事才成立。

推动时最有效的材料不是原理讲解，而是一组对照数据：走直译的那几门语言和走中转的那几门语言，在同类页面上的表现差多少。这组数据你站上很可能已经有了，只是从来没按这个维度拆过。拆一次的成本是一个下午，而它通常比任何论证都有说服力。



## 用户点同意之前你的翻译脚本一行都不许跑，首屏那段字只能是原文

- URL：https://zhangwenbao.com/minor-language-consent-banner-language.html
- 分类：小语种SEO
- 发布：2026-06-22  |  更新：2026-07-30
- 摘要：同意横幅由第三方工具输出，按浏览器偏好挑语言，跟页面按地址挑不是一套。讲清法律为什么只认读得懂、抓取程序看到的是哪一版、语言回落会造出什么样的错。
- 关键词：技术SEO,多语言SEO,内容本地化,小语种SEO

> **TLDR**：摘要：合规弹窗是多语言站上唯一一段这样的文字：它盖在首屏最上面，是访客第一眼读到的内容，却不从你的内容库出来，也没进过翻译交付清单。它由同意管理工具输出，语言按浏览器偏好或地理位置挑，跟页面按地址语言段挑是两个坐标系，于是波兰语页面配英语横幅没有一处会报错。更要命的是它还是一道闸门：用户点同意之前，靠第三方脚本注入的翻译根本不许运行，而抓取程序永远不会去点那个按钮。本文拆开这段字归谁管、按什么挑语言、法律那侧硬在哪、怎么排一张能验完的矩阵。

> 摘要：合规弹窗是多语言站上唯一一段这样的文字：它盖在首屏最上面，是访客第一眼读到的内容，却不从你的内容库出来，也没进过翻译交付清单。它由同意管理工具输出，语言按浏览器偏好或地理位置挑，跟页面按地址语言段挑是两个坐标系，于是波兰语页面配英语横幅没有一处会报错。更要命的是它还是一道闸门：用户点同意之前，靠第三方脚本注入的翻译根本不许运行，而抓取程序永远不会去点那个按钮。本文拆开这段字归谁管、按什么挑语言、法律那侧硬在哪、怎么排一张能验完的矩阵。

## 波兰语页面配着英语同意横幅，这件事为什么一直没人报错？

## 一家美妆个护站的波兰市场，转化在第一屏就掉了一截

有个客户做美妆个护，精华、面膜、洁面仪、护发油这几条线。

德国、法国、波兰三个市场，页面全做了本地语言，商品数也差不多。

德法两个市场的数据一直平稳，波兰这一边有个怪现象：进站的人不少，读完第一屏就走的比例高得离谱。

团队查过加载速度、查过图片、查过价格显示，都正常。

保哥让他们换一台没登录过的电脑，把浏览器语言改成波兰语，再从搜索结果点进去。

屏幕下半截压着一条横幅，上面写着We use cookies to improve your experience，两个按钮一个Accept All一个Manage Preferences。整页波兰语，唯独这条盖在最前面的东西是英语，而且它必须先被处理掉，用户才能继续往下读。

波兰这个市场的用户对英语的接受度并不低，问题不在于看不懂那两个单词，而在于一进门就有一段外语要求你做一个跟隐私有关的决定，这件事本身在传递一个信号：这个站不是给你做的。

把横幅换成波兰语之后，第一屏的流失确实回落了，但没有立刻追上德法两个市场。

这一点值得记住：第一屏赶走的人不会回来参与你的第二次测量，所以这类修复的收益永远只能看往后的数据，看不到追回来的那一批。

## 页面翻得很干净，遮住页面的那一层没翻

这个客户的本地化做得不算差。

商品标题、属性、面包屑、退换货说明，全是波兰语，还请了母语审校过一轮。

问题出在层次上：他们翻的是页面，而横幅不在页面上，它盖在页面上面。

从技术角度说，这段文字是另一段脚本在页面加载之后插进去的。

从流程角度说，它是另一个后台里的一条配置，跟内容库没有任何关系。

所以无论翻译交付清单列得多细，只要那份清单是照着页面模板列的，这段字就永远不会出现在上面。它不是被遗漏了，是它压根不在被清点的那个集合里。

竖屏手机上这件事更严重，一条两行高的横幅加上两个按钮，能吃掉首屏三分之一到一半的面积。

换句话说，移动端用户在读到你翻译过的第一句话之前，先读完了一整段没翻译的文字。

## 三个环节都检查过，三个环节都不认为这段字归自己

做本地化验收的人打开页面，看到的是自己翻过的那些内容，横幅在他眼里是个技术组件。

装同意工具的人负责的是合规能不能过、脚本会不会拖慢页面，文案长什么样不在他的验收项里。

法务那一侧要的是有没有装、分类对不对、能不能留痕，语言这一栏在他的清单上通常写的是有。

三拨人都尽职了，中间那段字仍然没人认领。

这种归属真空在多语言项目里特别常见，因为它同时跨了内容、技术、法务三个职能，而三边的验收清单都是按各自的专业维度写的，没有一份是按屏幕上的位置写的。

还有一个经常缺席的第四方：外部投放代理。很多站的追踪脚本是代理装的，他们只在自己的后台里看数据，从来不打开这个站的前台。

## 它不报错，是因为没有任何一处程序认为这是错误

页面语言声明写着波兰语，这一项检查通过。

同意工具后台显示已启用、已分类、已留痕，这几项也通过。

结构化数据校验、移动端友好度、抓取诊断，全都不看这段文字用了什么语言。

唯一能发现它的是人，而且必须是把浏览器语言调成波兰语之后的人。

这一条几乎是本文所有麻烦的总源头：整条链上没有一个自动检查项会去质疑首屏那段字的语言，于是它可以在线上安静地待好几年，期间每一份体检报告都是绿的。

市面上的合规体检工具查的是有没有装、分类对不对、拒绝之后脚本停没停，没有一项会去读那段文字是什么语言。

自动化测试也帮不上忙，多语言站的用例通常写在页面模板上，覆盖层不在任何一个模板里。

## 这段文字到底是谁输出的，为什么不在你的翻译队列里？

## 页面文字走内容库，横幅文字走另一个后台

先把出处分清楚，后面的判断才不会打架。

页面上的文字有两个来源：内容库里的条目，以及主题模板里的固定文案。

这两处都在你的翻译工作流里，导出、翻译、回填，路径是通的。

横幅上的文字是第三个来源：同意管理工具自己的后台。

它的存储位置不在你的数据库里，通常在服务商那边；改它要登录另一套系统，用另一套权限，导出格式也跟你的翻译交付文件对不上。

这就是为什么翻译团队从来没见过这段字。他们拿到的文件里根本没有这几行，而没人会去翻译一份自己没收到的文件。

导出格式也对不上。翻译交付走的是标准的双语文件，同意工具后台导出的是它自己那套结构，字段名跟你的内容库没有一处能对上。

所以就算有人想起来要翻它，回填也只能一格一格手工粘，而手工粘的东西下次改版又会丢。

这跟本站讲翻译报价单上写着四万字，页面上真正被人读的那几十个词一个都不在里面 (https://zhangwenbao.com/minor-language-hardcoded-ui-strings-pseudo-localization.html)那一篇里的界面字符串是同一族问题：它们都住在内容库之外，于是都不在按字数计价的那份报价单上。

## 翻译交付清单是按页面模板列的，弹层不在模板里

本地化排期通常这么做：先列页面类型，首页、列表页、商品页、结算页、政策页。

再按类型列字段，标题、描述、按钮、提示语。

这个方法本身没问题，覆盖率也高，唯一漏掉的是那些不属于任何页面类型的东西。

同意横幅、订阅浮层、年龄确认、地区确认，这几样都是全站级的覆盖层。

它们的共同特征是：不隶属于任何一个页面，却出现在每一个页面上。按页面类型清点的方法天生看不见它们，因为清点的单位选错了。

正确的清点单位不是页面类型，是屏幕上的位置。按位置清点，才能把这些不属于任何页面的东西捞出来。

全站级覆盖层通常有五类：同意横幅、订阅浮层、年龄确认、地区与货币确认、退出挽留弹窗。它们的共同点是每一个页面上都会出现，却不属于任何一个页面。

这五类里只有同意横幅是法律要求必须存在的，别的四类都可以撤掉，这一点决定了它们的优先级排序。

## 装它的人是技术或法务，验收的人是市场

这条组织上的错位值得单独说。

同意工具的采购动机是合规，推动者通常是法务或者管数据的人。

实施的人是技术，他关心的是加载顺序、脚本拦截规则、跟统计工具的对接。

最后看到成品的是做市场的人，可他没有那个后台的账号。

于是出现了一种很尴尬的分工：唯一能看出文案有问题的人，恰好是唯一改不了它的人。而能改的那两位，各自的验收标准里都不含语言这一项。

有个成本很低的解法是把语言支持写进采购需求：语言来源可配、自定义描述支持多语言、给本地化团队一个只读账号。

这三条写在合同阶段是一句话的事，等上线之后再补，就变成跨部门要权限的事了。

## 一句话判据：这段字改起来要登录哪个系统

想快速判断一段文字归不归你的翻译流程管，问一个问题就够。

改这句话，要打开哪个后台？

如果答案是内容库或者主题文件，它在流程里，正常排期就行。

如果答案是某个服务商的控制台，它在流程外，需要单独立一条。

把这个问题拿去问一遍站上所有可见文字，通常能揪出五到八处流程外的文本：同意横幅、客服窗口、评价插件、支付按钮、地图控件、退出挽留弹窗。它们加起来往往就是新市场用户读到的第一批字。

实际跑一遍，多数站能揪出五到八处流程外的文本：同意横幅、客服窗口、评价插件、支付按钮上的文案、地图控件、退出挽留弹窗、物流查询嵌入框。

把它们的第一屏可见部分加起来，往往就是一位新市场访客读到的头几十个词。

## 横幅挑语言的依据，跟你的页面挑语言的依据是一套吗？

## 页面按地址里的那一段语言信息走

多语言站的页面语言基本都由地址决定。

子目录形式的看第一段路径，子域名形式的看前缀，独立域名的看域名本身。

这套做法的好处是确定：同一个地址，谁打开都是同一门语言。

它也可被引用、可被收藏、可被分享，别人点开看到的跟你看到的一样。

这是搜索引擎能把各语言版本分别收录的前提，也是本站讲小语种页面正文越本地化越好、结构化数据却要反着写回国际格式 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)那一篇里反复强调的地基。

地址决定语言还有两个附带好处：这个地址可以被分享，别人点开看到的和你一样；它也可以被缓存，不需要按人区分。

全站真正不带语言信息的地址通常只有两个，根域名首页和那个面向未匹配用户的兜底版本。

## 横幅多半按浏览器偏好或者按地理位置走

同意工具的默认逻辑跟这个不一样。

最常见的是读浏览器发来的语言偏好，也就是那串按顺序排的语言标签。

其次是按访问者的网络位置判断国家，再映射到一门语言。

还有一种是读页面标签上的语言声明，但这一种反而不是默认项，需要在后台单独开。

三种取法各有各的道理，问题在于它们跟地址那一套是彻底独立的两个坐标系，谁都不知道对方拿到了什么答案。

浏览器发来的偏好其实是一串带权重的列表，可多数工具只取排在最前面的那一个。

而这个设置极少有人主动改过，它基本等于用户当初装系统时选的那门语言，跟他此刻想读什么没有必然关系。

## 两个坐标系撞车，会撞出四种组合

把地址语言和横幅语言排成一张两乘二的表，四格里只有一格是对的。

第一格，地址波兰语、横幅波兰语，正常。

第二格，地址波兰语、横幅英语，就是前面那个客户的情况，最常见。

第三格，地址英语、横幅波兰语，出现在波兰用户点开你的英语国际站时，页面是英语反而横幅是波兰语。

第四格更微妙：地址波兰语、横幅德语。这发生在一位住在德国的波兰用户身上，他的浏览器首选德语，而他特意点开了你的波兰语站。四格里只有第一格是团队测试时会遇到的那一格，因为测试的人通常在本地开着中文浏览器。

第四格在移民人口多的市场里并不罕见，德国的波兰裔、法国的葡萄牙裔、英国的印地语人群都属于这一类。

这批人恰恰是你的波兰语站最想要的访客：他们主动找了本地语言版本，结果被一段第三门语言的横幅拦在门口。

## 判据：地址里带语言信息时，一切以地址为准

这个冲突有一条很简单的处理原则。

地址里已经带了语言信息，说明访客做过一次明确的选择，或者搜索引擎把他送到了这一版。

这时候浏览器偏好只是背景资料，不该覆盖已经明示的选择。

只有地址完全不含语言信息时，才轮到浏览器偏好出场。

落到操作上，就是去同意工具后台把语言来源改成读页面上的语言声明，而不是读浏览器偏好。这个开关多数工具都有，只是默认不在那一档，而默认值一旦没人动过就会一直在那儿。

改完这个开关要重新测第四格，因为它是唯一一个改对了才会显现差别的组合。

只有根域名首页和兜底版本该继续读浏览器偏好，因为那两处确实没有别的依据可用。

## 平台自带三四十种语言，为什么用户看到的还是半洋不土？

## 按钮那几个词是厂商给的，用途说明是你自己写的

同意横幅上的文字其实分两批，来源完全不同。

第一批是界面词：接受全部、拒绝全部、管理偏好、保存设置。

这一批由服务商的语言包提供，主流工具能给到三四十种语言。

第二批是内容词：你收集哪些数据、每一类用来做什么、放多久、给了谁。

这一批必须由你自己填，服务商不可能替你写，因为他不知道你装了哪些追踪工具。而你填的时候，多半是照着合规文档抄了一版英语。

界面词还包括二级面板里的分类名称：严格必要、偏好、统计、营销。这四个词也在语言包里，所以它们通常是对的。

于是显示效果更奇怪：分类名是本地语言，分类下面那段解释是英语，用户读到一个看得懂的标题和一段看不懂的正文。

顺带说一句，这四个分类名在各语言里的译法相当固定，反而是最不需要你操心的部分。

## 自定义那一部分通常只有一份，而且多半是英语

后台的字段结构大致是这样：界面词按语言各一套，自定义描述往往只有一个输入框。

要做多语言，得在每一门语言下面重新填一遍那几段描述。

这件事没有技术难度，只有工作量，于是它成了最容易被跳过的一步。

跳过之后的显示效果很分裂：按钮是波兰语的，展开分类之后的说明是英语的。

用户能读懂按钮，读不懂他到底同意了什么，而这恰好是整个机制里唯一有法律意义的那部分。

还有一种更隐蔽的退化：工具升级语言包、新增了字段，新字段在你没填过的语言下会显示成英语。

同样地，新增一门语言时，自定义描述不会从别的语言复制过去，那几格是空的，而空格的显示结果就是回落到默认语言。

双语用户的判断标准还跟单语用户不一样。本站讲两种语言都看得懂的用户，而你的站只能有一套URL (https://zhangwenbao.com/ukrainian-russian-seo-bilingual-market-content-split.html)那一篇里说过，两门语言都读得懂的人不会因为看不懂而离开，他会因为你没做而降低对你的评价，这是一种更难察觉的流失。

## 越是合规要求写清楚的部分，越是没被翻译的部分

这里有个挺讽刺的对应关系。

法律要求说明白的是目的、范围、保存期限、第三方名单。

而这几项全部落在自定义描述里，也就是最可能没被翻译的那一批。

反过来，那两个按钮的措辞在法律上要求最低，却翻得最全。

结果就是横幅上翻得最好的部分是最不需要翻的部分。这不是谁失职，是因为翻译工作量跟文本重要性在这一页上正好成反比，而没有人拿着法律清单去逐段核对过。

第三方名单那一栏最典型。里面列的是一串英文公司名加英文用途，即便按钮翻成了本地语言，这一栏对用户仍然等于没写。

而这一栏恰恰是监管口径里最要紧的一项，因为它回答的是数据到底给了谁。

## 清点办法：把横幅上的每一段字标出来源

这个动作十五分钟能做完。

把横幅完整展开，包括点了管理偏好之后的二级面板。

截图打印，然后逐段标注：这段来自服务商语言包，那段是自己填的。

标完之后，自己填的那些就是要单独排一次翻译的清单。

顺手记下每段字在后台的字段名，交给翻译时把字段名一起给，回填才不会对错位置。这份对照表以后每次换工具、每次加语言都能复用，做一次能省很多轮。

标注的时候把每段字在后台的字段名一起记下来，交给翻译时字段名跟着走，回填才不会串位置。

这份对照表以后换工具、加语言、改分类都能复用，做一次能省掉后面每一轮的重新摸索。

## 法律那一侧对语言的要求，硬在什么地方？

## 同意必须是知情的，而知情的前提是读得懂

欧盟这套规则里，同意要成立有几个条件，其中一条是知情。

知情不是形式上给了文本就算，是这个人确实能明白他答应了什么。

一段他读不懂的文字，无法让他知情。

所以语言在这里不是体验问题，它直接决定这次同意在法律上成不成立。

这是本文最值得记住的一条：站上大部分文案翻错了只是难看，这一段翻错了或者没翻，等于你收集到的那批同意可能从一开始就不作数。

同一条逻辑也适用于拒绝那一侧：如果用户读不懂怎么拒绝，他就没有真正的选择，而自由选择是同意成立的另一个条件。

所以只翻接受按钮、把拒绝路径留在英语里，是比全英语更糟的一种做法。

## 条例原文要求用清晰平实的语言

相关条款写得很直白。

请求同意的表述必须能被清楚区分，用可理解、易获取的形式，语言要清晰平实。

另一条关于透明度的要求也重复了同样的措辞。

条文里没有一句写着必须用当地语言，因为它写的是必须能被这个人理解。

这个写法比列一张语言清单更强：它把判断标准放在了接收方身上，你面对的是波兰用户，那么可理解就意味着波兰语，没有讨价还价的余地。

条文里没有一句写着必须使用当地语言，它写的是必须能被这个人理解，判断标准落在接收方身上。

这个写法反而更严，因为它堵死了通用语言这条辩解：你面对的是波兰用户，可理解就意味着波兰语。

## 后果不是罚款那么简单，是这次同意不成立

很多人把合规风险直接翻译成罚款金额，这里不是。

如果同意不成立，那么建立在这次同意之上的所有数据处理就失去了依据。

统计脚本收集的行为数据、广告平台拿到的转化信号、重定向名单，全部悬空。

严重的情况下要删数据、要重新收集，还要解释这段时间的报表怎么算。

对做增长的人来说，这比罚款更疼：你不只是被罚了一笔钱，你是发现过去两年积累的受众数据可能不能用，而这批数据正是投放效率的地基。

重新收集也有代价。横幅要重新弹一遍，而重新弹一次意味着一部分本来已经同意的人这次会点拒绝。

换句话说，这个问题拖得越久，修复时要付出的不是补一次翻译，是把好不容易攒起来的同意率再交一次学费。

## 检查的时候，语言是一眼就能看出来的那一项

数据保护机构的检查动作大多需要技术核验：脚本什么时候加载、默认值是什么、拒绝之后有没有真的停。

唯独语言这一项，打开页面就能看见。

它是整份检查清单里成本最低、最先被注意到的一项。

一个用英语横幅面对本地用户的站，很容易在第一眼就被判定为没认真对待这件事。

投诉链条也短：一个看不懂横幅的用户去投诉，附一张截图就够了，不需要懂任何技术。这跟别的合规问题很不一样，别的问题至少还要有人会看开发者工具。

投诉的门槛也低得出奇：一位读不懂横幅的用户截一张图就能投诉，不需要懂任何技术。

别的合规问题至少还要有人会看开发者工具，这一条不需要，它是站在门口就能看见的那种问题。

还有一种触发路径：竞争对手举报。本地竞品比谁都清楚你这一页是英语的。

## 用户点同意之前，你的翻译脚本被允许运行吗？

## 同意工具的工作方式是先拦住所有非必要脚本

这套机制的核心动作只有一个：在拿到同意之前，不让非必要的第三方脚本跑起来。

实现方式通常是把脚本标签改成一种浏览器不会立刻执行的类型，等同意到手再放行。

有的工具更彻底，直接在网络层拦住对特定域名的请求。

被拦的名单是按类别配的：统计、广告、功能、个性化。

这里的关键在于分类是人配的，而配的人看到一个陌生域名时，很自然会先扔进非必要那一档，毕竟宁可多拦不可少拦，这在合规上永远是安全的选择。

分类的默认档位天然保守。工具自动扫描给出的建议也一样，它认不出的域名一律往非必要里放。

从合规角度这没错，宁可多拦不可少拦；问题只在于没人回头看看被多拦的那几个是干什么的。

本站讲在非洲选语种别先看人口，先看有没有人拿这门语言写价格和退货政策 (https://zhangwenbao.com/africa-market-language-selection-swahili-hausa-francophone.html)那一篇里提过，第三方脚本在弱网市场能占到首屏体积的一半，而同意工具通常是其中加载最早的那一个。

## 靠第三方注入的翻译方案，正好落在被拦的那一类里

现在把两件事对上。

一部分多语言站的译文不是服务端渲染的，而是靠一段第三方脚本在浏览器里替换文字。

这段脚本来自服务商的域名，加载时机在页面之后。

它在同意工具眼里就是一个外部域名发起的请求，跟统计脚本长得没什么两样。

于是它有相当大的概率被归进功能类甚至个性化类，然后在用户点同意之前被拦住。这不是谁写错了代码，是两套系统各自按自己的正确逻辑工作，撞在了一起。

判断有没有被拦有个很快的办法：看页面源码里那段脚本的类型属性有没有被改写成不会立刻执行的值。

被改写了就是被拦了，没改写但请求失败，那就是在网络层被挡住的那一种。

## 结果是首屏原文，点完同意才变成本地语言

这个连锁的表现很有辨识度。

页面刚打开时是源语言，通常是英语。

横幅盖在上面，也是英语。

用户点了接受，页面上的文字才刷成本地语言。

换句话说，你花钱做的整套本地化，被一道合规闸门挡在了第一屏之外，而第一屏恰恰是决定这个人留不留下来的那一屏。用户看到的顺序是：先被一段外语要求做决定，同意之后才发现原来这个站是有波兰语的。

用户实际经历的顺序是这样的：先被一段外语要求做一个跟隐私有关的决定，同意之后才发现原来这个站是有波兰语的。

而在这个顺序里，有一批人在做决定之前就已经离开了，他们从头到尾没见过你的本地化。

## 这条连锁只在多语言站上成立，单语言站永远看不到

值得强调一下这件事的稀有度。

单语言站装同意工具，被拦的是统计和广告，用户体验上几乎没有差别。

多语言站装同意工具，如果译文靠客户端脚本，被拦掉的是内容本身。

同一个工具、同一份配置，在两种站上的后果完全不是一个量级。

所以这个坑在通用的合规文章里读不到，那些文章的默认读者是单语言站。它只在两件事同时成立时出现：译文靠第三方脚本，同意工具默认拦截未分类域名。

所以这个坑在通用的合规文章里读不到，那些文章默认读者只有一门语言。

它只在两件事同时成立时出现：译文靠客户端脚本注入，同意工具默认拦截未分类域名。任何一条不成立，它都不会显形。

## 三种排查动作，十分钟能确认

第一种最简单：关掉同意，看页面还剩哪些字是源语言。

第二种是看拦截名单，找找翻译服务商的域名在不在里面，在哪一档。

第三种是把浏览器的脚本执行关掉再打开页面，看看返回的文档里译文在不在。

三种动作各自回答一个问题：拦没拦、归在哪一类、译文到底在服务端还是客户端。

如果确认是被拦了，处理办法通常是把翻译服务商的域名归到严格必要那一类，或者干脆把翻译改成服务端完成。前者是权宜，后者才是根治，因为服务端渲染的译文同时解决了抓取那一侧的问题。

还有第四种动作，而且它是最容易被忘的一种：用无痕窗口测。

因为点过一次同意之后横幅就不再出现，你在自己常用的浏览器里怎么刷新都看不到问题，而每一位新访客看到的都是第一次那一版。

实操上建议把这一步写成固定动作：每次改完横幅配置，开一个新的无痕窗口，把语言偏好改到目标语言再测。

这个动作只要一分钟，却是唯一能复现新访客视角的方法。

## 抓取程序永远不点同意，它看到的是哪一版页面？

## 抓取程序不会点任何按钮

这是一条太基础反而常被忘掉的事实。

抓取程序会执行脚本，但不会点击。

它不会点接受，也不会点拒绝，更不会去二级面板里逐项打开。

所以它永远停在未同意那个状态里。

如果你的页面在未同意状态下少了一半内容或者语言不对，那么它拿到的就是那一版，而它不会告诉你它看到的跟你看到的不一样。

它也不会滚动、不会关闭浮层、不会展开二级面板。

凡是需要一次交互才能显示的内容，对它来说都不存在。

## 它拿到的第一段可见文字，很可能是横幅

横幅的位置决定了它在文档结构里的地位。

很多同意工具把横幅插在文档最前面，或者用很高的层级盖在最上层。

抓取程序不看层级，它读的是文档顺序。

于是横幅那几句话有机会成为文档里靠前的文本块。

一个波兰语页面，最前面那段文字是英语的隐私说明，这在语言判定这件事上不是好消息。本站讲站上字最少的那几类页面最容易被机器认成另一门语言 (https://zhangwenbao.com/minor-language-page-language-detection-misidentification-short-text.html)那一篇里说过，判错语言的代价往往不显示在语言这一栏，而是显示在收录量和展示位置上。

位置差别很大。有的工具把横幅节点插在文档最前面，有的插在文档末尾再用层级盖上去。

前一种对文本顺序的影响明显更大，而你没法从视觉上分辨这两种，只能去看源码。

## 短文本参与语言判定，代价在别处结算

页面语言不是只看标签上写的那个值。

标签是声明，正文是证据，两者矛盾时以证据为准的情况并不少见。

当一个页面的正文很短，比如分类页、筛选页、图片页，横幅那几十个词的占比会突然变得可观。

本来就短的页面，加一段外语，判定就更容易偏。

这解释了一个常见的困惑：同一个站里，商品详情页的语言从来没判错过，列表页和筛选页却时不时被归到别的语言去。差别不在模板，在正文与横幅的字数比例。

判断风险有个很快的指标：拿横幅文本的字数除以这个页面的正文字数。

商品详情页这个比值很小，可以忽略；分类页和筛选页的正文本来就只有几百个字符，比值一下子就上去了。

模板化的页面本来就彼此相似，本站讲一个模板生成十种语言，字符层看不出重复、信息层十份一模一样 (https://zhangwenbao.com/multilingual-template-ten-languages-duplicate-content-risk.html)那一篇算过这笔账，再叠上一段各语言完全相同的英语横幅，相似度只会更高。

## 自查：用不执行脚本的方式取一次页面

最省事的验证方法是取一次原始文档。

用命令行工具直接请求页面地址，看返回的内容里有什么。

如果译文在返回的文档里，说明翻译在服务端完成，抓取那一侧安全。

如果返回的是源语言，说明译文靠客户端脚本，那就要再确认脚本有没有被同意工具拦住。

顺手看看返回内容里横幅文本的位置在哪一段，越靠前越要留意。这个动作两条命令就能做完，却能一次性回答本文里最要紧的两个问题。

顺手也看一眼响应头里的语言声明，跟页面标签上写的是不是同一个。

更彻底的做法是把执行脚本和不执行脚本的两版文本各存一份做比对，差异那一部分就是抓取程序看不到的内容。

## 语言回落发生的时候，页面会以什么形式出错？

## 找不到该语言就回落，而且不报错

同意工具的语言逻辑里都有一层兜底。

请求的语言在语言包里没有，就退回到默认语言。

默认语言通常是英语，也可能是你配置时的那门语言。

这个退回过程是静默的，后台不会亮红灯，控制台也不会打印警告。

这一点跟本站讲用户撞上404的那一刻请求已经不在你的应用里 (https://zhangwenbao.com/minor-language-error-page-fallback-language.html)那一篇里的软性错误是同一类：系统认为自己成功了，因为它确实按规则返回了一个东西，只是返回的那个东西对这位用户没用。

留痕记录里通常也不记语言。也就是说事后你无法核对当时那位用户看到的是哪一版文字。

如果有一天要证明某一批同意是有效的，这一栏的缺失会让举证变得很困难，而这一栏在多数工具里是可以自定义加上的。

顺手把语言这一栏加进留痕字段的成本很低，多数工具支持自定义字段，填的就是当时展示给用户的那门语言。

## 回落到英语和回落到主语言，是两种不同的错

这两种情况值得分开看。

回落到英语，用户至少可能读懂，属于体验下降。

回落到你的主语言，比如一家德国公司的站回落到德语，波兰用户看到的是一段完全陌生的语言。

后一种更糟，而它恰恰更容易发生，因为配置的人常把自己熟悉的语言设成默认。

选默认语言时有个不太直觉的判据：它不该是你最熟的语言，而该是你的目标市场里第二外语普及率最高的那一门，在欧洲多数市场这仍然是英语。

选默认语言时有个不太直觉的判据：它不该是你最熟的语言，而该是你的目标市场里第二外语普及率最高的那一门。

在欧洲多数市场这仍然是英语，但在拉美是西班牙语、在中亚可能是俄语，照抄英语并不总对。

## 半屏本地语言半屏英语，用户读到的是不信任

混语言的横幅比全英语的横幅更伤。

全英语至少像个统一的国际站。

半屏波兰语半屏英语，传递的信号是这一页没人管。

而这一页恰好是要用户做一个跟个人数据有关的决定的地方。

本站讲落地页上最像装饰的那几个信任元素在小语种市场是搜索量最高的购买词 (https://zhangwenbao.com/minor-language-landing-page-trust-signals-payment-address-support.html)那一篇里算过一笔账：一个新市场的访客在下单之前会用一切细节判断你是不是认真在做这个市场，而语言不一致是他不需要任何专业知识就能看出来的那一类细节。

混语言还会反过来削弱页面语言判定的证据面，因为它让这一页同时出现了两门语言的特征词。

一个本来就短的页面，加上一段外语，判定偏掉的概率会明显上升。

## 监控这件事只能靠自己造一张矩阵

没有现成工具会告诉你横幅语言不对。

能做的是把组合列出来，定期人工过一遍。

横轴是你的语言版本地址，纵轴是浏览器的语言偏好。

每一格记录横幅显示了什么语言、二级面板显示了什么语言。

一个五语言的站，矩阵是五乘五加上一行没有语言偏好的情况，三十格，一个人半小时能过完，一个季度做一次就够。抓取程序那一行要单独记，因为它的语言偏好通常是空的。

抓取程序那一行要单独记，它的语言偏好通常是空的，走的永远是回落分支。

顺手把二级面板也记进去，因为一级横幅和二级面板的语言来源不一样，很多站是一级对了二级还是英语。

## 这一页该由谁负责，验收怎么排？

## 三方各出一部分，缺谁都验不完

这段文字的特殊之处在于它没有单一归属，所以只能明确分工。

法务出内容：哪些类别、每类的用途表述、保存期限。

本地化出译文：把上面那批表述按语言各出一版，跟站上其他文案的用词保持一致。

技术出配置：语言来源改成读页面声明、拦截名单里翻译域名归类、加载顺序。

最后需要一个人做集成验收，而这个人必须有那个后台的只读权限。多数团队卡在最后这一步，不是不愿意验，是没有账号。

卡住多数团队的其实是最后这一步，而且卡的不是意愿是权限：能看出问题的人没有那个后台的账号。

解法很土，申请一个只读账号，成本是一封邮件。

还有一个务实的替代方案：让技术那一侧每季度导出一次横幅的全部文案给本地化过目，绕开账号问题。

## 一张浏览器语言乘以地址语言的矩阵

验收清单的主体就是上一节那张矩阵，这里给出每格要看的四项。

横幅主体的语言对不对。

展开二级面板之后，分类名称和用途说明的语言对不对。

拒绝之后再次打开页面，横幅语言有没有变。

点完接受之后，页面正文有没有从源语言刷成本地语言，如果有，说明译文在客户端且被拦过。

还有第五项：在页面上把语言切到另一门，看横幅会不会跟着变。

多数情况下不会变，因为同意已经存下来了，横幅根本不再出现，这也是为什么这一项必须在无痕窗口里测。

## 上线前的五项检查

第一项，把自定义描述在每一门语言下都填了没有。

第二项，语言来源开关是不是读页面声明。

第三项，默认回落语言选的是哪一门，理由是什么。

第四项，翻译服务商的域名在拦截名单的哪一档。

第五项，用不执行脚本的方式取一次页面，确认译文和横幅文本各自的位置。这五项加起来不超过一小时，但它们覆盖了本文提到的全部失效路径。

这五项加起来不超过一小时，却覆盖了本文提到的全部失效路径。

把它们写成一页纸贴进上线清单，比记住本文任何一条结论都管用。

## 什么时候要重新验一遍

有四个触发条件值得写进日历。

新增一门语言的时候，因为自定义描述默认不会跟着新增。

换同意工具的时候，因为语言来源开关的默认值可能不一样。

换翻译方案的时候，尤其是从服务端换成客户端注入。

加装任何新的第三方脚本的时候，因为它会被扔进某个分类，而分类会影响加载顺序。这四件事平时都不会被当成本地化变更，所以必须显式写进流程，否则不会有人想起来去看一眼那条横幅。

第五个触发条件是工具自己升级语言包，这件事你不会收到通知，只能在季度检查时顺手看一眼。

前四件平时都不会被当成本地化变更，所以必须显式写进流程，否则没人会想起来去看那条横幅。

## 哪些做法看着省事，实际上把问题埋得更深？

## 全站只留一版英语横幅

这是最常见的省事做法，理由通常是英语通用。

它省下的是几段文案的翻译工作量。

它埋下的是同意有效性的问题，而这个问题不会在流量报表上显形。

更麻烦的是它有欺骗性：因为一切正常运转，团队会以为这件事已经做完了。

要判断这个选择划不划算，只需要问一句：你愿意用两段文案的翻译成本，去换整个市场同意数据的有效性吗？这么一问，答案就很清楚了。

它最大的欺骗性在于一切都在正常运转：横幅弹得出来、同意收得到、报表照样出。

所有信号都在告诉你这件事已经做完了，只有那位波兰用户知道没有。

## 用机器翻译批量灌进后台

比不翻好，但这一页有它自己的门槛。

合规文本的用词是有惯例的，各语言里都有一批固定说法。

机器翻译在这类文本上容易把法律含义翻软，比如把必要的翻成需要的。

更常见的问题是术语在同一页里不统一，同一个概念前后两种译法。

可行的折中是机器翻译打底、法务或本地顾问过一遍关键的几段，工作量不大，因为这一页的字数本来就很少，通常两三百字。

好在这一页的字数很少，通常两三百字。机器翻译打底、请本地顾问过一遍关键几段，成本几乎可以忽略。

真正要盯的是术语一致：同一个概念在同一页里不能出现两种译法，这是机器翻译在这类文本上最常见的失手。

## 把横幅做成全屏遮罩

这个做法在语言之外还有别的代价，本站讲GDPR与CCPA同意横幅怎么不毁掉SEO数据 (https://zhangwenbao.com/seo-legal-compliance-gdpr-ccpa-consent-mode-cross-border-architecture.html)那一篇写过。

这里只补语言层的一条。

全屏遮罩意味着抓取程序拿到的首屏文本几乎全是横幅。

如果横幅还是英语，那么这个页面对外呈现的第一批文字就是一段跟内容无关的外语。

体积小的页面受影响最大，而列表页和筛选页正好是体积小的那一批，它们又是站内链接结构里承上启下的一层。

体积小的页面受影响最大，而列表页和筛选页正好是体积小的那一批。

它们又是站内链接结构里承上启下的一层，判错语言的连带损失比单个商品页大得多。

本站讲阿拉伯语网站搬进手机之后，桌面时代验过的那份RTL清单有一半不作数 (https://zhangwenbao.com/arabic-rtl-mobile-first-narrow-screen-pitfalls.html)那一篇里讲过固定条与弹层的遮挡方向，在从右往左的语言里，遮罩上那个关闭按钮的位置也要跟着翻，否则用户会下意识去点错的一侧。

## 把同意状态写进整页缓存

最后一条是技术上的坑，后果落在语言上。

把同意状态混进整页缓存，缓存键就多了一个维度。

再叠上语言维度，缓存命中率会明显下降。

更糟的情况是缓存串了：一位波兰用户拿到了缓存里那份德语横幅的页面。

正确做法是同意状态只放在客户端，页面缓存不带这个维度。这条跟按语言协商内容时要正确声明缓存差异是同一类问题，判断依据都是同一句话：这个维度到底该不该进缓存键。

正确做法是同意状态只留在客户端，页面缓存不带这个维度。

判断依据可以浓缩成一句话：这个维度会不会改变返回给用户的内容？会改变的才该进缓存键，而同意状态改变的是脚本行为，不是页面内容。

顺带提醒一句，边缘缓存那一层也要看，很多站的整页缓存其实发生在离用户更近的地方，而不是自己的服务器上。

## 常见问题解答

## 同意横幅用英语，在欧盟到底算不算违规？

不能一概说违规，但风险很实在。规则要求同意必须是知情的，且请求同意的表述要用清晰平实、能被理解的语言。判断标准落在接收方身上：面对波兰用户，可理解通常就意味着波兰语。真正的后果不是罚款那么简单，而是这次同意可能不成立，建立在它之上的统计与广告数据会一并失去依据。所以这不是体验问题，是数据资产的有效性问题。

补一句实操上的判断：如果你的市场里有本地语言的竞争对手，那么英语横幅在监管眼里几乎没有辩解空间，因为它证明了用当地语言做这件事是可行的。

## 同意工具后台已经开了多语言，为什么用户看到的还是一半英语？

因为横幅上的文字有两个来源。按钮和界面词由服务商的语言包提供，开了多语言就都有；你自己填的分类说明、用途描述、保存期限只有一份，需要在每门语言下重新填一遍。合规要求写清楚的恰好是后一批，于是最重要的那部分最容易留在英语。清点办法是把横幅完全展开截图，逐段标注来源，自己填的那些单独排一次翻译。

还有一个更隐蔽的版本：工具升级语言包新增了字段，新字段在你没填过的语言下会退回英语，于是本来全对的横幅过一阵子又混进了几行英文。

## 为什么页面是波兰语，横幅却按德语显示？

因为两者挑语言的依据不是一套。页面按地址里的语言段走，同意工具默认按浏览器语言偏好或者地理位置走。一位住在德国的波兰用户点开你的波兰语站，就会出现页面波兰语、横幅德语的组合。处理原则是地址里带语言信息时以地址为准，去后台把语言来源改成读页面上的语言声明，这个开关多数工具都有，只是默认不在那一档。

改完开关要重新用无痕窗口测一遍，因为点过同意之后横幅不再出现，你在常用浏览器里看不到任何变化。

## 抓取程序看到的横幅是什么语言，会影响收录吗？

抓取程序不会点任何按钮，永远停在未同意状态，它的语言偏好通常也是空的，所以它拿到的多半是回落语言那一版。影响主要有两处：一是横幅文本在文档里位置靠前，会参与页面语言判定，正文越短影响越大，列表页和筛选页首当其冲；二是如果译文靠客户端脚本注入而脚本被拦，它拿到的整页都是源语言。用命令行取一次原始文档就能确认。

顺手记一下横幅节点在文档里的位置，插在最前面的那种影响明显更大，而这一点无法从视觉上分辨。

## 翻译服务商的域名要不要放进严格必要那一类？

如果译文靠这段脚本在浏览器里替换文字，那就必须放，否则用户在点同意之前看到的是源语言，抓取程序看到的也是源语言。放进严格必要这一类需要有理由，而这个理由是站得住的：没有它页面无法以用户能理解的语言呈现。更彻底的做法是把翻译改到服务端完成，这样既绕开了拦截，也让抓取那一侧拿到完整译文。

把它归进严格必要之前，最好留一份书面理由，写清楚没有它页面无法以用户能理解的语言呈现，这样将来接受检查时这个分类是站得住的。

## 只面向一个市场的单语言站，需要在意这一节吗？

需要在意的部分不多。单语言站装同意工具，被拦的通常是统计和广告脚本，内容本身不受影响，语言也不会撞车。真正要留意的只有一条：如果这个市场的用户不使用你的界面语言，比如一家用英语后台的公司做日本市场，那么这一页仍然要单独确认。判断依据很简单，看横幅显示的语言跟你的目标用户日常使用的语言是不是同一门。

还有一种情况要留意：站是单语言的，但用户群不是。这时判断依据仍然是横幅语言与目标用户日常语言是不是同一门，跟站有几个语言版本无关。

## 权威参考资料



## 重排小语种优先级那天才发现，六年里真正变过的只有一列数字

- URL：https://zhangwenbao.com/minor-language-seo-2026-portfolio-review-invest-freeze.html
- 分类：小语种SEO
- 发布：2026-05-25  |  更新：2026-07-27
- 摘要：母语人口没变、格变化的数量也没变，真正动过的只有本地供给密度、工具数据可得性和AI引用可见度这三列。讲清为什么静态量只配当准入门槛、三档各按什么条件切，以及撤在今天为什么等于冻结而不是删站。
- 关键词：AI搜索,出海SEO,多语言SEO,小语种SEO

> **TLDR**：摘要：把六年前那张小语种优先级表翻出来重排一次，会发现里面一半的列根本没动过——人口没变、格变化的数量没变、书写系统还是那几套。真正变了的只有三列：本地同行有没有认真在写、工具还给不给数、AI在这门语言里引不引你。静态的量只配当准入门槛，不配进排序；而撤这个动作在今天也不再等于删站，它等于冻结。

> 摘要：把六年前那张小语种优先级表翻出来重排一次，会发现里面一半的列根本没动过——人口没变、格变化的数量没变、书写系统还是那几套。真正变了的只有三列：本地同行有没有认真在写、工具还给不给数、AI在这门语言里引不引你。静态的量只配当准入门槛，不配进排序；而撤这个动作在今天也不再等于删站，它等于冻结。

## 为什么该撤哪门语言这个问题，一开始就问错了单位？

盘点做不下去，多半不是数据不够，是清点的单位选错了。

## 撤的不是语言，是语言乘品类乘内容形态那一格

先看一个很常见的会议场景。

有人提议把某门语言整个停掉，理由是投入产出比最低。

反对的人举出这门语言里表现最好的那几个页面。

两边说的都是真的，因为他们说的不是同一件事。

一门语言在你的站上从来不是一整块，它是一堆格子。

每一格是一门语言、一个品类、一种内容形态的交叉。

把清点单位从语言换成格子之后，加投和撤这两个动作第一次可以同时出现在同一门语言上，而这恰恰是真实情况。这个换单位的动作在本栏目里出现过一次，是小语种问答长尾那一篇 (https://zhangwenbao.com/minor-language-qa-long-tail-content-value-ai-era.html)提出的供给密度是语言乘品类的交叉属性。当时那句话是用来救一批被搜索量判死的内容形态，现在它有了第二个用途：它是这张盘点表唯一正确的行。行选错了，后面所有的列都白填。

换单位还有一个附带效果，是它把责任也拆开了。语言级的判断归负责国际化的人，格级的判断归品类负责人，两边各自能拿到自己那部分的数据，不必等对方。过去这类盘点总是卡在没人能同时说清所有语言和所有品类，拆成格子之后，每个人只需要对自己那几格负责，会议时间通常能砍掉一半。

## 同一门语言在两个品类上，结论会正好相反

举个具体的例子会更清楚。

有个做运动户外鞋服的站，波兰语这一边一直不温不火。

按语言整体看，它排在待撤名单的前几位。

拆到品类之后，登山鞋那一格的自然流量六年翻了几番。

而跑步服那一格从头到尾没有起色。

两格的差别不在语言，在当地有没有一批人真的在写这个品类。

登山鞋那一格好，是因为波兰的户外社群内容密度本来就高，用户搜的问题很具体，而具体问题恰好是长尾内容的主场；跑步服那一格不好，是因为那个品类的话语权在几个国际大品牌手里，本地内容几乎不存在。如果按语言整体拍板，这个站会连着把已经跑起来的那一格一起停掉。这类误伤在盘点里很常见，而且不可逆——停掉之后半年再想捡回来，位置已经被人占了。所以哪怕最后真要撤，也得先拆到格子再决定撤哪几格。

## 换了单位之后表变长了，但每一格都算得动

有人担心这样一拆，表会变得没法维护。

二十几门语言乘几个主要品类，确实是上百格。

但绝大多数格子不需要单独算。

同一门语言里，格与格的差异只集中在两列上。

其余几列在同一门语言内部完全一样，填一次就能复用。

真正要逐格填的只有本地供给密度和AI引用可见度这两列。

算下来的实际工作量是：语言级的列一门语言填一次，格级的列只填你真正在做的那几个品类，加起来通常不超过四十格，一个人一天能填完。把这个数说出来很重要，因为盘点这件事最大的敌人不是难度是拖延，一旦被想象成一个季度的工程，它就永远排不上期。四十格一天，这个量级才有人愿意开始。而且第二次重算时前面几列可以整列复制，实际只剩十几格要动。

## 六年过去，这张表里哪几列其实一个字都没变？

这一节是整篇最值钱的一条判断，它决定了排序该按什么排。

还有一点值得提前说破：格子的粒度不必一开始就定死。第一次做的时候按大品类拆，跑完发现某个大品类内部差异很大，下一轮再把它拆细就行。粒度是可以迭代的，而语言这个单位没法迭代——它要么整体在要么整体不在，这也是它作为清点单位最致命的地方。

## 静态那几列：人口、构词难度、书写系统、语言距离

先把六年前那张表的列拿出来看。

母语人口，六年里的变化在小数点后面。

构词难度，芬兰语还是十五个格，德语复合词还是那么长。

书写系统数量，印度还是那九套，一套没多也没少。

语言之间的距离，捷克语到斯洛伐克语的互通度没有变化。

正字法偶有微调，但对关键词表的影响接近于零。

这几列有一个共同点：它们描述的是语言本身的性质，而语言本身的性质以世纪为单位变化，不以季度为单位变化。把这样的量放进一个每季度重排一次的优先级表里，本身就是一件很奇怪的事——你每次重排，它们贡献的排序信息完全相同，等于把同一个常数反复加进去。加常数不改变排序，只会让人误以为这次重排是有依据的。这跟财务报表里把固定资产的账面值每个月重算一遍差不多，算得很认真，结论一个字不变。

要给这几列的静态程度找个佐证并不难，网页上各语言内容的占比结构就是个现成的例子，按语言统计的网站内容占比 (https://w3techs.com/technologies/overview/content_language)逐年翻下来，前十名的顺序好几年才微调一次。一个几年才动一次名次的量，放进季度级的排序模型里，它贡献的只有惯性。

## 可变那几列：本地供给密度、工具数据、AI引用

另外几列的六年变化幅度很大。

本地供给密度，有的语种翻了几倍，有的塌了一半。

关键词工具的数据可得性，整体在变差而不是变好。

AI在这门语言里引不引用你，六年前这一列根本不存在。

本地媒体和目录的外链渠道，有的语种整批消失了。

本地支付与物流的可用性，某些市场发生过跳变。

这几列的共同点也很清楚：它们描述的不是语言，是这门语言周围的生态，而生态是按季度变的。换句话说，六年前那张表里，真正携带决策信息的只有下半张。上半张不是没用，它有另一个用途，只是被放错了位置。放错位置的后果不是算错，是算了等于没算——每次重排都得到几乎相同的顺序，然后大家觉得这套方法很稳定，其实它只是没在动。

## 静态量只配当准入门槛，不配进排序

正确的位置在哪儿，这句话可以说得很干脆。

静态量适合做一道过不过的判断。

比如书写系统你的技术栈支不支持，不支持就直接出局。

比如构词复杂度高到需要专门的算法，没那个预算就先不碰。

这类判断只需要做一次，做完之后长期有效。

过了门槛的那些语言，再用可变量去排先后。

一句话概括就是：静态量决定名单里有没有你，可变量决定名单里你排第几，两件事混在一列里算，得到的分数既不能判进出也不能排先后。这条原则的适用范围远不止小语种。凡是一个评分模型里既有几乎不变的因子又有高频波动的因子，而且它们被加权求和成一个总分，那个总分基本上是废的：波动因子的信号会被常数稀释掉，模型看起来很稳，实际是钝的。检验办法很省事，把静态那几列全部去掉重排一次，如果顺序大变，说明之前那些常数一直在压着真正的信号。

准入门槛这一栏还有个好处，是它可以写成硬性的是与否，不需要打分。技术栈支不支持这套书写系统，团队有没有能力覆盖这种构词方式，本地化流程跑不跑得通——三个问题三个答案，一目了然。语言与地区标签的官方口径文档 (https://www.unicode.org/reports/tr35/tr35-general.html)是回答第一个问题时最省事的对照表，半小时能把簇分完。

## 这是对当年那套成本模型的一次修正

说到这儿要回头认个错。

本栏目开篇那一篇讲的就是怎么给小语种排优先级。

那篇的核心是别按母语人口排，要算三笔账。

三笔账分别是关键词表膨胀倍数、竞争密度、内容复用率。

三笔账本身没错，直到今天算法都成立。

问题在于它们全是静态量，而当时没人意识到这一点。

所以那套模型在开工前用是对的——它回答的是这门语言值不值得进名单；拿它做六年后的重排就不对了，因为它的输入六年没变过，输出自然也不会变。那一篇讲的三笔账 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)今天该放在准入门槛那一栏，本篇这套可变量的账放在排序那一栏，两者不冲突，是接力关系。承认这一点比继续维护一个自洽但迟钝的模型有价值，毕竟一套六年不变的排序，跟没有排序的区别只在于它更让人放心。

## 本地供给密度这一列，六年里到底变了多少？

这是三根可变列里权重最高的一根，也是唯一一根自己就能测的。

## 怎么测：供给侧的数自己数得出来

测法朴素到有点不好意思写出来。

挑二十条这门语言里的真实长尾问句。

每条搜一次，数前十条结果里有几条是本地内容。

本地内容的判据是用这门语言原创、由本地站点发布。

翻译过来的、机器生成的、内容农场的一律不算。

二十条的平均值就是这门语言在这个品类上的供给密度。

这个数最大的好处是它不依赖任何外部工具——需求侧的数字工具说没有你就没辙，供给侧的数字你自己打开结果页就能数，谁也拦不住。这条在本栏目里出现过，是关键词工具返回零那一篇 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)的核心。当时它解决的是没数据怎么办，现在它解决的是排序按什么排。同一个测法在六年里升级了用途，这本身就说明供给侧视角一直被低估：它不只是需求侧的替补，它测的是一件需求侧根本测不到的事——你的对手强不强。

数的时候有个细节要统一，否则前后两次没法比：判定本地内容的标准必须写死并且记在表里，比如域名后缀、页面语言标注、作者信息三选二成立才算。标准松紧不重要，重要的是两次用的是同一把尺子。这类自建指标最常见的失效原因不是测得不准，是两次测的定义悄悄变了。

## 三种变化方向：涨、平、塌

把六年前的数和现在的数并排看，方向只有三种。

涨，指本地认真写的人变多了，前十条里本地内容占比上升。

平，指几乎没动，前后差异在一两条之内。

塌，指本地内容被大量低质量批量内容挤掉了。

三种方向对应的动作完全不同，这是重点。

涨意味着这门语言正在变难，进场窗口在关闭。

塌意味着门槛降低了，但用户的信任也一起降低了。

最容易判错的是塌这一类：结果页看起来很空，很容易被读成机会大，实际上是这个语种的搜索结果整体失去了参考价值，用户已经改去别的地方找答案了。判别办法是同时看一眼本地社群和问答平台的活跃度，如果搜索结果空而社群很热，说明需求还在只是不走搜索了，那这一格该做的是内容分发而不是加大产出。这一层跟小语种外链渠道在当地人圈子里 (https://zhangwenbao.com/minor-language-link-building-local-directories-media-communities.html)那一篇讲的是同一个生态，只是那次看的是外链，这次看的是内容本身。

## 涨得最快的是哪几门，为什么是它们

把涨的那批语言排一排，会发现一个规律。

涨得快的多半不是使用人口最多的那几门。

而是本地创作者生态最近几年成型的那几门。

越南语、印尼语、波兰语、土耳其语大体属于这一类。

相对地，几门老牌欧洲语言的本地供给这几年基本没动。

因为它们的供给六年前就已经很饱和了。

这个规律翻译成决策语言是：本地供给密度的绝对值决定这一格难不难做，它的变化速度决定你还剩多少时间。两个数要一起看。绝对值高而且还在涨的格子，基本可以放弃了；绝对值低但涨得很快的，是最后的窗口期，值得优先加投；绝对值低而且六年不动的，通常说明这个品类在这门语言里根本没有真实需求，别被结果页的空旷骗了。这三种组合几乎能覆盖所有情况，比任何一个综合评分都好用，因为它保留了两个维度而没有把它们压成一个数。

## AI那一列该怎么填，才不是拍脑袋？

这一列六年前不存在，现在它是权重上升最快的一根。

判断一门语言的生态到底成没成型，还有个粗但快的旁证是当地的上网人口结构与社交平台使用深度，每年更新的全球数字生态年度报告 (https://datareportal.com/reports/digital-2026-global-overview-report)里按国家给了这些数。创作者生态的成型通常滞后于上网人口的爆发三到五年，看到某个市场几年前刚经历过一轮渗透率跳升，多半就是现在正在补内容的那批。

## 三个可测的数，别只测一个

很多团队这一列只填了一个数，就是被引用了几次。

这个数单独看意义不大，要配另外两个。

第一个数是在不在候选池里，用本语言问十条看来源清单。

第二个数是被引比例，你的页面在来源里出现的次数除以十。

第三个数是来源清单里本地站点的整体占比。

第三个数才是判断这一层空不空的关键。

三个数的组合能区分两种在报表上一模一样的零：一种是这一层压根没有本地内容，来源全是英文页面，另一种是有本地内容但没有你。两种零需要的动作完全相反，前者是抢先进场，后者是老老实实提升质量。AI用你的语言回答却挂着英文来源 (https://zhangwenbao.com/ai-search-language-bias-low-resource-citation-source-audit.html)那一篇把这个区分讲得更细，包括怎么用十条查询把缺席和落后分开。这里只强调一句：只填一个数的那一列，六年后回头看会发现它什么都没记录下来。

## 被引用的门槛低，被采信的门槛高

低资源语言这一层有个反直觉的现象。

被引用其实不难，因为候选池本来就空。

一篇质量中等的本地内容也可能被挂进来源清单。

但被引用不等于内容被真正用来生成答案。

很多时候答案的实质内容来自英文语料，你只是被挂在下面当装饰。

判别办法是看答案里的具体数值跟你页面上的对不对得上。

对不上就说明你只是被引用了，没有被采信，这种引用带来的曝光是真的，但它对纠正错误信息一点用都没有。这个区分很重要，因为很多团队看到被引用次数上升就以为工作到位了，实际上错误的本地规则仍然在被复述。跨语言事实矩阵那一篇 (https://zhangwenbao.com/multilingual-ai-answer-divergence-three-types-fact-matrix.html)给的三类分歧判别法可以直接接在这里用：如果答案里的数值和你页面上的不一致，先按那三类分开，再决定要不要动内容。

另一个判别办法是拿公开评测当参照：低资源语言上模型的能力差距有多大，是有专门的基准在测的，面向西语各地区变体与低资源语言的评测榜单 (https://arxiv.org/abs/2507.00999)就是一例。差距越大的语言，被引用与被采信之间的落差通常也越大，因为模型越依赖跨语言迁移，就越不会真的去读你那一页。

## 低资源语言的答案，是从哪儿迁移过来的

把这一列填准，得知道答案的来路。

模型在低资源语言上的知识大量来自跨语言迁移。

迁移的源头通常是英语语料，偶尔是同语系的高资源语言。

迁移过来的东西读着很地道，因为语言层没问题。

出问题的是事实层，尤其是本地规则、期限、资质这类东西。

而这些恰恰是转化路径上用户最在意的信息。

所以低资源语言这一列的分数不该只看引用率，还得看这门语言里被引用的内容有多少是真正本地产出的，这个比例低就意味着整层内容的可信度是虚的。公开语料的语言分布可以当一个参照，Common Crawl按语言统计的月度抓取分布 (https://commoncrawl.github.io/cc-crawl-statistics/plots/languages)是少数几个能长期对比的公开数据源，看一眼你的目标语种在里面占千分之几，心里就有数了。这个数跟母语人口的排序对不上，落差最大的那几门语言，正是内容层最虚的那几门。

## 这一列跟排名那一列不是同一个方向

最后一条容易被忽略的性质。

传统排名那一列，竞争越激烈你越难上去。

AI引用这一列的逻辑不完全一样。

候选池空的时候，进去很容易但曝光量也小。

候选池满的时候，进去很难但一旦进去价值很高。

两条曲线在中间某处交叉，交叉点因语言而异。

实际含义是：不能拿同一套阈值去卡所有语言，高资源语言这一列的分数要求要高，低资源语言这一列的分数低也不代表没做好。粗糙但够用的做法是按语言分组设阈值，把语言按公开语料占比分成三组，每组用一套线。这比全站一条线合理得多，也避免了一个常见的管理错误——用同一个指标考核处境完全不同的几个人，最后大家都去优化那个最容易做高的数字，而不是最该做的事。

## 工具数据这一列，为什么反而比六年前更不能信？

这是唯一一根在退步的列，而且退步的方式很隐蔽。

这条差异还有一层管理上的含义：AI那一列的进步往往是阶跃式的，不像排名那样连续。某次模型换代或者语言扩容之后，一门语言可能一夜之间从没有覆盖变成有覆盖，中间没有过渡。针对西语生成结果的偏差评测 (https://arxiv.org/abs/2509.03329)这类研究说明，同一门语言在不同维度上的表现也可能相差很远，所以一列一个总分本来就装不下。

## 聚合口径变了，数字变好看了

先说现象。

六年前很多小语种关键词工具直接返回零或者无数据。

现在它们越来越少返回零，多半会给一个数。

这个数往往来自更大范围的聚合，或者来自模型估算。

从产品角度这是进步，用户不再面对一片空白。

从决策角度这是退步，因为你分不清哪些数是真测出来的。

没数据的时候你会警惕，会去自己数；有一个看起来合理的数，你会照着做，而这个数可能是从另外几个语种的行为推算出来的。这条判断在本栏目里出现过，是菲律宾混合语言那一篇 (https://zhangwenbao.com/philippine-english-taglish-mixed-language-keyword-research.html)的核心之一：官方语言跟大语种重合的市场，工具会给一个全球聚合出来的健康数字，本地混写查询在聚合里被打散。当时讲的是一类市场，现在这个现象扩散到了几乎所有小语种，因为估算能力普遍上来了。

## 有数字比没数字更危险的那类市场

危险程度不是均匀的，有几类市场特别值得警惕。

第一类是这门语言跟一门大语言共用大量词形。

第二类是这门语言主要在多语并用的市场里使用。

第三类是这门语言有两套书写系统在并行。

三类的共同点是聚合时会把不同来源的量混进同一个词。

混完之后数字变大，方向可能整个反掉。

识别办法很省事：拿一个你确定在本地几乎没人搜的词去查，如果工具照样给出一个体面的数字，那么这个工具在这门语言上的全部数据都不该被当成实测值。这个探针只要两分钟，却能定性整个工具在这门语言上的可信度。做完之后不必弃用它，把它降级成方向参考就行——比大小可以，比绝对值不行。降级这个动作比弃用现实得多，毕竟没有工具的日子更难过。

还有一类容易被忽略的高危情形，是这门语言的主要市场跟另一个大市场共用同一个国家代码或者同一个货币区，工具在做地域切分时会把两边的量并进同一个桶。这类混淆比语言层面的混淆更难发现，因为它不体现在词形上，只体现在总量上，而总量正是最没人怀疑的那个数。

## 补数的三个自建办法

工具降级之后，缺的那部分得自己补。

第一个办法是站内搜索日志，它测的是真实语言习惯。

第二个办法是客服工单里的原话，它测的是真实问法。

第三个办法是本地平台的搜索建议，它测的是本地大盘。

三个办法都不给绝对量，但都给可靠的相对关系。

而排序只需要相对关系，不需要绝对量。

把这一点想明白能省掉很多焦虑：优先级表要的是谁排在谁前面，从来不是每门语言精确的月搜索量，而相对关系恰恰是自建数据最擅长的部分。三个办法里第三个权重最高，因为本地平台已经替你做过一遍用户调研，它的搜索建议是从真实查询里跑出来的。这套用平台当对照组的思路在本栏目里反复出现，从非洲选语种那一篇 (https://zhangwenbao.com/africa-market-language-selection-swahili-hausa-francophone.html)开始，到今天依然是最省事也最可信的一手信号来源。

## 分叉和构词这两列，还要不要留在表里？

既然它们是静态量，是不是该整列删掉？答案是不删，但要换个位置放。

## 它们决定的是成本，不是收益

先把这两列到底在说什么讲清楚。

分叉说的是同一门语言在不同市场用词差多少。

构词说的是一个词能生出多少种形态。

两者都直接决定关键词表的行数和维护工时。

但它们跟这门语言能带来多少收入没有任何关系。

芬兰语的十五个格不会让芬兰人多买一双鞋。

把成本列和收益列混在一个总分里，最典型的后果是难做的语言分数低、于是永远排在后面，而它可能恰好是收益最高的那一门。正确的用法是把它们放进第二张表：先用可变量排出收益顺序，再用这两列去算每一档需要多少人力和多少周期。两张表分开之后，会议上的对话质量会立刻提升——原来大家争的是这门语言该不该做，现在争的是它值这个价钱吗，后面这个问题有答案。

把成本和收益分开还能解决一个长期的组织问题：负责本地化交付的人和负责增长的人，考核口径终于可以不一样了。前者对成本列负责，后者对收益列负责，两张表各有主人。混在一个总分里的时候，两边都会去争这个分怎么算，而不是各自把自己那半张表做扎实。

## 分叉率的分母是查询条数，不是词表长度

分叉这一列还有个算法上的坑。

很多人拿词表里有多少词存在地区差异当分叉率。

这个算法会把结论算歪，因为词表里冷门词占多数。

正确的分母是查询条数，也就是加权之后的量。

一个高频词的分叉，抵得上几十个长尾词的分叉。

换了分母之后，很多语言的分叉率会从吓人变成可以接受。

这条判据来自西语地区变体那一篇 (https://zhangwenbao.com/spanish-regional-variants-ai-answer-source-divergence.html)，那次算出来的三档决策线是分叉率低于一成就铺词、一到三成局部替换、超过三成才考虑拆站。三档线可以直接搬到别的语言上用，只是每门语言的分叉都要重新算一遍，不能沿用。另外那一篇还留了一条更根本的判据：先分清地区差异是词汇现象还是语法现象，前者可穷举、人工列一遍就完事，后者由构词规则生成无穷形态、只能上算法。这条判据决定的是投入的形态，不只是投入的量。

## 词汇现象和语法现象要分开算

把这条判据展开一点，因为它省钱最多。

词汇现象的例子是同一件东西在两个国家叫不同的名字。

这类差异的数量是有限的，几百条封顶。

人工整理一遍，之后只需要维护，成本一次性。

语法现象的例子是一个名词接十几种格尾。

这类差异由规则生成，理论上无穷，只能靠程序覆盖。

两类的预算量级差一个数量级，把它们混在一起报预算，要么把简单的报贵了，要么把难的报便宜了，后者更常见也更致命。本栏目里德语复合词、芬兰语的格、土耳其语的后缀堆叠、匈牙利语十八个格都属于后一类，而印尼语和马来语的词汇分裂 (https://zhangwenbao.com/indonesian-malay-seo-two-markets-vocabulary-split.html)、荷兰语和佛兰芒语的差异属于前一类。做盘点的时候在这一列旁边加一个标记，只标词汇还是语法两个值，后面所有的排期讨论都会顺畅很多。

## 二十几门语言现在各在哪一档？

这一节给的是入档条件，名单要你自己按条件填，因为每家的品类不同。

要判断某门语言的形态复杂度到底属于哪一类，有个不用请教语言学家的办法，就是去看公开的多语言标注语料里这门语言的词形标注规模，多语言依存标注项目 (https://universaldependencies.org/)覆盖了上百门语言。同一份文本量之下，词形标签种类多的多半是语法现象，种类少而词汇量大的多半是词汇现象，十分钟能判完。

## 加投档：两个条件同时成立

加投档的门槛应该设得比直觉高。

第一个条件，本地供给密度低但增速快。

第二个条件，AI来源清单里已经有本地站点出现。

两个条件同时成立，说明市场正在形成而窗口还没关。

只满足第一个，可能是这个品类在这门语言里没需求。

只满足第二个，说明你已经晚了，进去要拼质量不是拼速度。

符合两条的典型是那几门本地创作者生态刚成型不久的语言，越南语、印尼语、波兰语、土耳其语在多数品类上都落在这一档，而它们恰恰不是母语人口排名最前的那几门。这个错位本身就是整套方法最好的验证：如果重排之后的名单跟按人口排出来的顺序差不多，说明你的可变量列没填对，或者填的时候不自觉地照着旧顺序凑了。名单跟直觉不一样才是正常的，一模一样反而要回头查。

## 维持档：不加人也不减人

维持档是最大的一档，也是最容易被忽视的一档。

典型特征是本地供给密度高且稳定。

你的内容已经有位置，但再加投也很难往前挪。

几门老牌欧洲语言在成熟品类上多半在这一档。

这一档要做的是保鲜，不是扩产。

保鲜指的是把已有内容的事实层更新住，别的都可以不动。

维持档最实际的风险不是掉排名，是内容里的过期数值被AI原样复述出去，因为那些页面通常写得早、写得好、被引用得多。本栏目在十份口径一致的资料是同一篇英文翻出来的 (https://zhangwenbao.com/untranslated-invisible-ai-retrieval-translated-content-tradeoff.html)那一篇讲过这个机制：写得越一致越容易被当成共识，而共识错了纠正起来更慢。所以维持档的预算不该是零，应该留一笔专门用来核对数值，占比很小但不能没有。

维持档还有一个反直觉的操作要点：这一档最不该做的事是重写。已有页面积累的引用关系和外链是它最值钱的部分，大改一次可能把这些一起打散，而换来的质量提升往往有限。要动就只动事实层的数值和过期表述，结构、标题、地址一律不碰。这跟内容审计的习惯正好相反，得提前跟做审计的人打好招呼。

## 冻结档：停更但不下线

冻结档的入档条件也是两条。

第一，这一格的自然流量六年基本没有增长。

第二，AI来源清单里连本地站点都很少出现。

两条同时成立，说明这一层既没有搜索需求也没有引用价值。

但注意这两条说的是这一格，不是这门语言。

同一门语言的另一个品类完全可能在加投档。

冻结的判据里特意没有放收入指标，因为小语种的收入归因本来就不准，跨语言的用户旅程里最后一次点击落在哪门语言基本是随机的，拿它当判据会误伤。更稳的做法是用流量趋势加引用可见度这两个过程指标，它们虽然离钱远一点，但至少测得准。这也是两个市场关键词表相同落地页得拆 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)那一篇里已经提过的老问题，跨市场归因这件事到今天都没有好办法。

## 三档之间怎么迁移

档位不是终身制，迁移规则要事先写死。

加投升不上去，连续两个季度没起色就降到维持。

维持档的供给密度开始塌，要判断是机会还是失效。

冻结档如果本地供给突然涨起来，说明有人开始做了，要重新评估。

迁移只在季度节点做，不在中途拍脑袋改。

每次迁移都要在表里留一行记录，写清楚依据。

留记录这件事看着像形式主义，但六年之后回头看，唯一能告诉你当初为什么那么决定的就是这几行字，而这正是这次重排能做出来的前提。说得实在一点：如果六年前有人在表里留了几行字，这次重排两天就能做完，而不是要把所有列重新测一遍。所以这一条不是给现在的你写的，是给三年后的那个人写的，他多半还是你。

## 撤在今天不等于删站，等于冻结

这是全篇最需要说清楚的一个变化，它跟六年前完全不同。

迁移规则里最容易漏掉的是降档也要有条件，而不是只写升档。没有降档条件的表会单调膨胀，所有格子最后都停在维持档，因为没人愿意主动说自己负责的那格该冻结。把降档写成自动触发——连续两个季度两项指标都没动就自动降一档，需要保留得给出书面理由——比靠人自觉可靠得多。

## 排名侧的资产会随着不更新掉下去

先说旧世界的逻辑。

传统排名有很强的时效性偏好。

内容不更新，排名会缓慢下滑。

竞争对手一直在更新，你不动就是相对退步。

所以过去停更等于放弃，放弃等于半年后归零。

既然半年后归零，那不如直接下线省服务器钱。

这条推理在六年前完全成立，也是为什么当年撤这个动作默认就是删站或者整目录下线。连带的一整套动作也是围绕删来设计的：做重定向、清站点地图、把外链指过去。这套动作今天依然会被人条件反射地执行，只是它服务的那个前提已经不完整了——排名侧确实还是那样，但排名侧不再是唯一的入口。

## 检索侧的资产不会随着不更新消失

新增的那一半是这样的。

被检索这件事的判据主要是内容对不对得上问题。

一条没变过的事实，一年前对，今天还是对。

它不会因为页面很久没改动就被判定失效。

所以停更的内容在这一层仍然持续产生价值。

前提只有一个，就是那些事实本身没有过期。

两侧的资产半衰期完全不同，这就让撤这个动作第一次有了中间形态：把排名侧的投入停掉，把检索侧的资产整个留着，成本降到接近于零而价值不归零。成本能降到多低取决于站点结构，多数情况下就是不再产出新内容、不再做外链、不再做本地化投放，页面留在原地。服务器那点钱在总账里可以忽略，真正省下来的是人。而人正是小语种项目里最贵也最难补的那一项。

这里要补一句限定，免得这条被用过头：检索侧资产不随时间衰减的前提是内容本身的时效属性弱。讲原理、讲流程、讲怎么选的内容衰减很慢，讲价格、讲政策、讲当年新规的内容衰减很快，后者停更之后不是躺在那儿不动，是躺在那儿持续输出错误。所以冻结之前得先按时效属性把内容分一次类。

## 冻结清单：停什么、留什么、什么时候才真该删

把冻结落成一张清单。

停：新内容产出、外链建设、本地化投放、母语审校排期。

留：现有页面、结构化数据、语言标注、内部链接。

留还要加一件：每年核一次页面上的事实类数值。

核数值是冻结档唯一保留的经常性开销，一门语言每年半天。

这半天不能省，省了冻结就变成了慢性投毒。

真该删的情形只有三种：页面上的事实已经彻底不成立、这门语言的市场因为合规原因不能再服务、或者内容本身是机器批量生成从来没有人校对过。前两种是业务判断，第三种是历史遗留。第三种最该果断删，因为它在检索侧不但不产生价值还会持续输出错误，而这类内容的规模往往还不小。机器翻译直接发布那一篇 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)算过这笔账，当年的结论是拿收录和排名分期还，今天要补一句：在检索这一层，这笔账是不设还款期限的。

## 这张表多久重算一次，重算要花多久？

再好的方法，如果重算成本高到没人愿意做，它就只会被做一次。

## 两小时能重算完的那部分

先把便宜的部分挑出来。

本地供给密度，一门语言二十条查询，十分钟。

AI来源清单，一门语言十条问句，十分钟。

两项加起来，一门语言二十分钟。

主力的五六门语言，两小时能全部跑完。

这两项恰好是权重最高的两列。

也就是说，决定排序的信息里最重要的那部分，重算成本是两小时，而不是一个季度。把这个数字告诉团队非常关键，因为盘点这件事最常见的死法是被想象成一个大工程，然后一年只做一次，一年一次的频率对一根季度级波动的列来说等于没测。改成每季度两小时，信息质量的提升远远超过把测法做得更精细。这也是一条通用经验：一个指标的价值等于它的准确度乘以它被更新的频率，多数人只优化前面那个乘数。

## 一个季度才该动的那部分

其余几列的节奏要慢得多。

工具数据可信度，一个季度探一次就够。

外链渠道的存活情况，一个季度扫一遍。

本地支付与物流的可用性，跟着业务侧的节奏走。

静态那几列，一年动一次都算勤快。

档位迁移的决议，固定放在季度末。

把不同节奏的列分开更新，是这套表能长期活下去的关键——所有列都按最慢的节奏更新，表会失真；所有列都按最快的节奏更新，没人受得了。实操上建议在表头直接标注每一列的更新周期，这样接手的人不必猜。这个习惯还有个额外好处：当有人质疑某个结论时，可以直接指着列头说这一列是三个月前测的，讨论的焦点会立刻从对不对变成要不要重测，后者能当场解决。

季度级这几列还有个共同点，就是它们的变化通常有公开信号可循，不必靠自己监测。平台侧的能力变动会先出现在官方公告里，搜索侧的官方更新汇总 (https://blog.google/products-and-platforms/products/search/)是最直接的一个入口。把这类来源订阅起来，季度更新的那半张表基本可以做到有事才动，没事就跳过，进一步压低维护成本。

## 触发式重算的三个信号

除了定期，还有三种情况要立刻重算。

第一个信号是主流模型换代或者答案形态发生明显变化。

第二个信号是某个市场的搜索格局出现结构性变动。

第三个信号是你自己的品类结构发生了变化。

三个信号里第一个最近几年触发得最频繁。

触发之后不必全表重算，只重算AI那一列。

今年二月那次AI Mode一口气加进五十多门新语言、累计逼近一百门，就是一个标准的触发点，很多原本填着无覆盖的格子在那之后变了值。这类变动的特点是发生得快、影响面大，而且不会有人来通知你。关于这次语言扩容的报道 (https://www.seroundtable.com/google-expands-ai-mode-to-53-new-languages-40958.html)可以当一个时间锚点：在它之前测的AI那一列，之后基本都要重测一遍。本栏目当年算过国家数和语言数不是一回事 (https://zhangwenbao.com/ai-overviews-100-countries-six-languages-minor-language-citation.html)，这次的教训是同一件事——公告里的数字要换算成自己的口径才能用。

## 这套盘点法在什么情况下会给错答案？

任何方法都有边界，把边界写出来比多写十条技巧有用。

## 品类太窄的时候，格子不够多

第一种失效场景是品类单一。

如果整个站只做一个很窄的品类，格子就退化成语言。

换单位这个动作也就失去了意义。

这时候本地供给密度还能测，但方差会很大。

二十条查询在窄品类里可能凑不出来。

凑不出来就只能扩大到相邻品类，结论会变模糊。

窄品类的替代办法是把内容形态当第二个维度：同一个品类下的选购指南、参数对比、售后与合规说明，这三种形态的供给密度差别通常很大，足够拆出可用的格子。这个替代很实用，因为供给密度本质上测的是有没有人认真写，而认真写这件事在不同内容形态上的分布极不均匀——参数类内容满地都是，合规与售后类内容几乎没人写。窄品类的机会往往就藏在后面这一类里。

## 品牌处在早期的时候，供给密度不重要

第二种失效场景跟品牌阶段有关。

供给密度衡量的是这一层竞争激不激烈。

但早期品牌的瓶颈通常不在竞争，在自己的内容量。

页面总共几十个的时候，排序做得再精也没用。

这时候更该看的是哪门语言的转化路径最短。

转化路径包括支付、物流、客服、退换货这一整条。

换句话说，这套盘点法适用于已经铺开、需要做取舍的阶段，不适用于还在选第一门语言的阶段，那个阶段该用的是准入门槛那套账。把适用阶段说清楚，能避免一类很浪费的错误——早期团队拿着为成熟期设计的方法做决策，测了一堆没有区分度的数，最后还是凭直觉选。本栏目里选第一门语言该问什么 (https://zhangwenbao.com/africa-market-language-selection-swahili-hausa-francophone.html)那一篇给的四个信号，才是那个阶段该用的东西。

早期阶段还有一个更根本的差别：那时候语言和市场这两个字段往往是绑在一起的，先选市场再选语言，而成熟期这两个字段必须拆开独立记录。通用区域数据仓库 (https://cldr.unicode.org/)把语言、书写系统、地区拆成三段的做法，正好可以当报表字段设计的参照，早拆一天，后面少返工一片。

## 有本地团队的时候，整套账要重写

第三种失效场景最彻底。

前面所有的账都默认内容由总部远程生产。

一旦某个市场有了本地团队，成本结构完全变了。

本地团队产出内容的边际成本比远程低得多。

而且他们能做远程做不了的事，比如本地媒体关系。

这时候这门语言不该跟别的语言放在同一张表里比。

更准确的说法是：有本地团队的市场，语言不再是一个成本变量而是一项已有产能，它该进的是产能规划表而不是优先级表。这条边界值得单独标出来，因为很多公司的小语种投入结构里恰好有一两个这样的市场，把它们混在同一张表里排序，会得到两个都不对的结论——本地团队那门语言的分数虚高，其余语言的分数虚低。分开之后两边都清爽了。这也算是这套方法自己给自己划的最后一条线。

## 常见问题解答

## 可变量和静态量的划分，会不会因为行业不同而不一样？

划分标准不变，具体归属会变。判据只有一条：这个量在一个季度到一年的尺度上会不会明显变化。语言本身的性质不会，生态相关的量会。行业差异体现在权重上，不体现在归属上。比如快消品类里本地供给密度的变化速度远快于工业品类，所以快消的重算频率要更高。但无论哪个行业，母语人口都不会变，它永远属于门槛那一栏。

## 没有六年历史数据的团队，这套重排还能做吗？

能做，而且第一次做的成本更低。可变量那三列全部是当下就能测的，不依赖历史数据。历史数据只影响一件事，就是判断趋势方向是涨是塌。没有历史值的话，第一次跑出来的数就当基线，下个季度再跑一次就有方向了。也就是说这套方法的第一次执行只能得到静态照片，从第二次开始才有速度信息，而速度信息才是最值钱的那部分。所以越早开始跑第一次越好。

## 冻结之后，这门语言的页面还要不要保留在站点地图里？

要保留。冻结的核心就是让内容继续可被发现，从站点地图里拿掉等于自断一条路。要调整的是优先级字段和更新频率字段，把它们改成跟实际情况相符的值，别继续声称每周更新。另外语言标注和多语言之间的互相声明也全部保留，因为它们的维护成本是零而移除的代价不可逆。真正该动的只有那些指向已下线页面的链接。

## 怎么判断某一格是没需求还是需求没走搜索？

看两个地方。第一是本地的社群与问答平台，如果那里关于这个品类的讨论很活跃而搜索结果很空，说明需求在但渠道变了。第二是本地主流电商平台的搜索建议，如果建议词很丰富，说明需求真实存在。两处都冷清才是真没需求。这个区分很重要，因为需求没走搜索的格子该做的是内容分发和社群渗透，跟加投内容是两种完全不同的动作，预算也归不同的人管。

## 这套表能不能直接拿去跟老板汇报？

能，但建议改一下呈现方式。老板要看的不是二十几行的明细，是三档各有几格、这个季度有几格发生了迁移、迁移的理由是什么。把明细放附件，正文只放三档汇总加迁移记录，一页纸就够。特别要把冻结这个概念讲清楚，否则很容易被理解成放弃了某个市场，实际上它是把投入停掉而把资产留下，两者在财务上的含义完全不同。这一句解释不到位，后面的沟通成本会很高。

## 如果某门语言的数据在三列上互相矛盾怎么办？

矛盾本身就是有用的信息，别急着求平均。最常见的一种矛盾是本地供给密度很低但AI引用里全是英文来源，这通常意味着这一层是空的而且暂时没人会来填，属于典型的窗口期。另一种矛盾是供给密度高但引用可见度为零，多半说明你的内容在这门语言里质量不达标，而不是市场问题。所以三列不一致的时候要做的是读组合，不是压成一个总分，压成总分正好把最有价值的那点信息抹掉了。

## 这套盘点跟常规的内容审计是什么关系？

两件事，不能互相替代。内容审计看的是每一篇内容自身好不好、要不要更新或者合并，是纵向的、逐篇的。盘点看的是资源该往哪几格投，是横向的、跨语言的。一个站完全可能每篇内容都通过了审计，同时把八成的产能投在了三档里最不该投的那一档上。反过来盘点做得再准，具体到每一格里内容不行也没用。实际排期上建议盘点在前、审计在后，先定投哪几格，再决定那几格里的内容怎么处理。

## 权威参考资料



## 孟加拉语的关键词表按一门语言建，交付那天才发现国界两边根本不是一套词

- URL：https://zhangwenbao.com/bengali-seo-two-markets-vocabulary-grapheme.html
- 分类：小语种SEO
- 发布：2026-05-18  |  更新：2026-08-01
- 摘要：做孟加拉语站要先决定给国界哪一边写。用真实语料与搜索建议实测给出选词判据，并拆开字段额度、截断算法与首字母索引这几处只在这套文字上出问题的地方。
- 关键词：技术SEO,跨境电商,多语言SEO,小语种SEO

> **TLDR**：摘要：孟加拉语有2.7亿母语者，可它最大的市场不在印度。保哥把国界两边的18个新闻站抓了81万个孟加拉文字符实测，发现一件反直觉的事：词汇分叉是单向的。西孟加拉那边水这个概念几乎只用一个词，比例11比1；孟加拉国那边两个词都在用，几乎五五开。按对称分叉的思路建词表，两边会同时漏掉一半。

> 摘要：孟加拉语有2.7亿母语者，可它最大的市场不在印度。保哥把国界两边的18个新闻站抓了81万个孟加拉文字符实测，发现一件反直觉的事：词汇分叉是单向的。西孟加拉那边水这个概念几乎只用一个词，比例11比1；孟加拉国那边两个词都在用，几乎五五开。按对称分叉的思路建词表，两边会同时漏掉一半。

## 一门语言两个国家，为什么第一步不是找译者而是先划国界？

## 一家做家用净水设备的站，孟加拉国那边的自然流量一直起不来

有个客户做家用水处理，主力品类是台上式净水器、滤芯、储水桶和管路配件。

他们先做的是印度市场，英语版加印地语版，跑了将近两年，数据能看。

第三步团队决定加孟加拉语，理由听上去无懈可击：印度东部本来就有存量流量，孟加拉国还有一个1.7亿人口的邻国，一套内容两边都能用。

译者是从加尔各答找的，母语者，做过本地化，交付质量挑不出毛病。

上线半年，印度西孟加拉邦那一侧的自然流量涨得很正常，孟加拉国那一侧几乎是平的。

团队第一反应是物流和支付没打通，查了三个月的转化漏斗，最后发现漏斗上面根本没人进来。

## 问题不在译文质量，在一个谁都没想到要问的问题

保哥看这个案子的时候先问了一句：这套词表是给哪一边写的。

团队愣了一下，说是给孟加拉语写的。

这个回答本身就是答案。孟加拉语不是一个市场，它是被一条1948年画下来、1971年又重画了一次的国界劈成两半的一门语言。

孟加拉国1.7亿人，印度西孟加拉邦加上特里普拉邦接近1亿人，两边说的确实是同一门语言，同一套文字，字体文件完全共用。

但用户在搜索框里打进去的那个词，两边不一定是同一个。

这跟西班牙语在西班牙和拉美的分叉 (https://zhangwenbao.com/spanish-seo-es-es-latam-keyword-divergence.html)、葡萄牙语在巴西和葡萄牙的分叉 (https://zhangwenbao.com/portuguese-seo-brazil-portugal-two-markets-keyword.html)是同一类问题，只是孟加拉语这一门几乎没人拿中文写过，多数团队做到这一步才第一次听说。

## 本站以前写过孟加拉语，但写的是另外半件事

本站讲印度十一门语言分摊在九套书写系统上 (https://zhangwenbao.com/india-multilingual-seo-eleven-languages-nine-scripts-priority.html)那一篇里，孟加拉语出现过，但它是作为一个成本单位出现的：孟加拉文这个Unicode区块里装着孟加拉语和阿萨姆语两门语言，字体可以共用，词表不能共用。

那一篇的坐标系是印度国内的预算排期，孟加拉语在里面排第几、边际成本几成。

这一篇要处理的是那个坐标系装不下的部分：这门语言最大的那半个市场根本不在印度境内，而印度境内的排期表里没有一格是留给它的。

换句话说，上一篇算的是把孟加拉语加进印度站要花多少钱，这一篇算的是加进去之后那套词表能覆盖多少人。

## 这一层为什么归语言层管，而不是归国际化架构管

先把边界划清楚，免得后面越说越乱。

域名怎么分、hreflang怎么写、要不要按bn-BD和bn-IN分成两套页面，这些是架构层的事，跟孟加拉语这三个字没关系，换成任何一门跨国语言都成立。

本篇要处理的是把语种换成英语就不存在的那一半：同一个概念在国界两边被写成两个不同的词，而这两个词在字符层没有任何交集。

这个差别很要紧。架构做对了，用户还是搜不到你，因为他打的那个词你页面上一次都没出现。

## 三种常见的做法，各自会在哪一步塌掉

第一种是只做一套，找一个母语译者，交付什么用什么。

塌在译者身上——他一定属于某一边，写出来的自然是那一边的说法，而他不会觉得自己做了任何选择。

第二种是做两套页面，但共用一份关键词表。

塌在词表上——页面拆了，词没拆，等于花了两倍的钱买同一批流量。

第三种是查工具，看哪个词量大用哪个。

塌在工具上——这一点后面第五节会用实测数据说明，孟加拉语的工具口径里压根没有把两个国家分开的入口。

## 顺带说一句这门语言的体量

孟加拉语的母语人口排在世界第六到第七位，跟俄语在同一个量级，比德语和法语都多。

但在中文的出海资料里，它出现的频率大概跟冰岛语差不多。这个反差本身就是机会的形状：需求在那儿，写的人不在那儿。

孟加拉国那一侧的电商还在爬坡期，客单价低、货到付款占比高，这些都是真实的门槛。可门槛低的市场从来不缺人，门槛高又没人写的市场才是那种做进去就很难被追上的地方。

## 把国界两边的报纸抓了81万字，只有一对词给出了干净的答案

## 实验是怎么设计的

要证明分叉存在，得先有语料。孟加拉语没有现成的分国别商业语料库，所以保哥用了最笨的办法：抓新闻站。

孟加拉国那一侧选了9个站，印度西孟加拉那一侧也选了9个站，都是各自市场里日更的主流媒体。

每个站抓首页，再顺着首页链接抓至多14个内页，把正文剥出来合并成两份语料。

最后拿到的规模是孟加拉国侧326003个孟加拉文字符，西孟加拉侧486380个，合计81万出头。

然后挑了8组词对，每一组是同一个概念在两边的两种常见说法，分别数它们在两份语料里出现多少次，再按语料大小归一化成每十万个孟加拉文字符出现几次。

## 先看那一组给出干净答案的词

水这个概念，孟加拉国惯用一个源自波斯语的词，西孟加拉惯用一个源自梵语的词。

实测结果是这样的：

词 | 孟加拉国侧频率 | 西孟加拉侧频率 | 原始次数 | 

পানি（孟加拉国惯用） | 12.0 | 3.1 | 39／15 | 

জল（西孟加拉惯用） | 12.6 | 35.2 | 41／171 | 

频率单位是每十万个孟加拉文字符出现的次数。

横着看，পানি 在孟加拉国侧的密度是西孟加拉侧的3.9倍，জল 在西孟加拉侧是孟加拉国侧的2.8倍。方向完全符合预期。

竖着看才是这个实验真正的收获，下一节专门讲。

## 再看那一组把预设打回去的词

消息这个概念也有两个常见词，一个偏口语一个偏书面。做这个实验之前保哥的预设是它也会分叉。

结果是两边都是同一个词占绝对上风：孟加拉国侧55.8对15.0，西孟加拉侧108.1对21.8。

两个市场给出的答案不但一致，连比例都接近，一个是3.7比1，一个是5比1。

这条反例的价值比那条正例还高。它说明分叉不是一门语言的整体属性，而是逐词发生的。

凭感觉列一张两边不同的词表，你会把一批根本不分叉的词也拆成两份，然后为不存在的差异付两倍的内容成本。

## 还有六组词，一次都没出现

洗澡、邀请、肉、鞋这几组，在81万字符里几乎全是零。

洗澡那一对，孟加拉国侧出现3次，西孟加拉侧0次；鞋那一对两边都是0；肉那一对两边各1次。

这个数字不能读成两边都不用这些词。它只能读成一件事：新闻不谈鞋，也不谈洗澡。

保哥这次踩的坑值得写下来——语料选错了。新闻语料能测出的是时政、天气、体育里的高频词，测不出商品品类词，因为报纸根本不写那些东西。

换句话说，这不是两边都不用，这是尺子不够长。第四节会讲这种情况下还能怎么办。

## 为什么不直接用电商站的语料

这是最先想到的办法，也是最先撞墙的办法。

孟加拉国那一侧的主流电商平台和生鲜平台，商品列表基本是前端脚本渲染出来的，抓回来的页面里孟加拉文字符只有个位数。

本站讲屏幕上是好好的泰语、机器复制走的是另一串字符 (https://zhangwenbao.com/minor-language-pdf-text-layer-extraction-failure.html)那一篇讲过一个类似的结构：人眼能读到的东西不等于程序能取到的东西。这次是同一个结构换了个位置，人眼在浏览器里看得见整页商品名，程序拿到的是一个空壳。

所以本篇的品类词那一半是靠另外两个实验补的：搜索建议接口，以及字符层的实测。它们分别在第五节和第六节。

## 分叉为什么是单向的，这件事对选词意味着什么？

## 把那张表竖着读一遍

上一节那张表横着读是符合预期的，竖着读就不是了。

在西孟加拉那份语料里，জল 是35.2，পানি 是3.1，比例11.4比1。这一侧基本只用一个词。

在孟加拉国那份语料里，পানি 是12.0，জল 是12.6，比例0.95比1。这一侧两个词都在用，而且用得几乎一样多。

也就是说，这条分叉线只有一半是硬的。

## 硬的那一半和软的那一半，落地方式完全不同

硬的那一半是西孟加拉侧。在那边写孟加拉国那个词，等于把词写在了一个几乎没人搜的位置上，密度低到3.1，而且那15次里有相当一部分是在引用孟加拉国的新闻。

软的那一半是孟加拉国侧。在那边只写本地那个词，你会漏掉将近一半的表达面，因为另一个词在那边同样活跃。

所以两个市场的动作是不对称的：西孟加拉侧要做的是替换，孟加拉国侧要做的是并列覆盖。

如果按对称分叉的思路做，两边各写一个词，结果是西孟加拉侧对了，孟加拉国侧漏了一半。

## 这个不对称是怎么来的

成因不在语法里，在两边的语言规范化路径不一样。

西孟加拉那一侧的书面语标准形成得早，参照系是加尔各答的文学传统，梵语来源的词被系统性地留了下来。

孟加拉国那一侧在建国之后经历了一轮独立的语言规范建设，波斯语和阿拉伯语来源的日常词被写进了标准，但原有的那一批并没有被赶走。

一边是筛选过的，一边是叠加过的。筛选产生排他，叠加产生并存。

这条规律不止孟加拉语适用。凡是两个市场里有一边做过一次自上而下的规范化、另一边是自然沉淀的，多半都会出现这种一边硬一边软的形态。

## 验证的时候要小心一个陷阱

用词频判断分叉有一个天然的坑：你数到的那个词可能根本不是在讲那个概念。

孟加拉语里 জল 除了水本身，还进了不少复合词和固定表达，比如一种橄榄类水果的名字前两个字符就是它。保哥在核对的时候把这类命中挑出来单看过，比例不算高，但它确实在把数字往上抬。

比较稳妥的做法是把词频当方向指标，不当绝对值。方向对了就足够做决策，精确到小数点后一位没有意义。

这一点跟本站讲同一门语言在两个市场的意图漂移 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)那一篇的口径是一致的：分叉率算出来是用来排优先级的，不是用来做四舍五入的。

## 那些一次都没出现的词，是两边都不用还是我的尺子不够长？

## 先承认这是一次测量失败

81万字符听上去不少，可放到词频统计里它其实很小。

一个词如果在真实语言里的密度是每十万字符0.5次，在这份语料里的期望出现次数是4次左右，方差大到没法做判断。

而商品品类词的密度普遍就在这个量级甚至更低。鞋、水壶、床单这类词在报纸上一天出现不了一次。

所以那六组零命中不是结论，是一次没测出来。把它写成两边都不用这些词，就是拿测量工具的局限当发现。

## 换尺子的第一个办法：改用搜索建议做代理

词频测不出来的东西，搜索建议接口能测出一部分，因为那个接口背后是真实查询日志。

做法很简单，把候选词丢给搜索建议接口，看它返回什么，返回几条，返回的长尾里带的是哪些修饰词。

返回的条数本身就是信号。一个词如果连建议都拉不出来，说明真实查询量低到没进候选池。

这套办法本站讲关键词工具在小语种里返回零 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)那一篇里完整写过，这里只是把它用在一个具体语种上。第五节会给出实测结果，那个结果里有一个意外。

## 换尺子的第二个办法：找一份说人话的语料

新闻语料的问题是题材偏。要测品类词，得找题材本身就是商品的语料。

可选的有三类：本地分类信息站的商品标题、本地论坛的求购帖、以及本地零售商的印刷宣传单。

第三类最容易被忽略，也最好用。宣传单上的品类词是给本地人看的，写法一定是本地最通用的那个，而且它经常以图片形式发布，反而躲开了前端渲染的问题——代价是得先做一次文字识别。

这三类语料的共同点是它们都不在关键词工具里，得自己去攒。攒的过程本身就是这门语言的进入成本，本站讲按母语人口排小语种优先级会排反 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)那一篇算的就是这笔账。

## 换尺子的第三个办法：把判断权交出去，但要问对问题

找母语者问是最快的，前提是问法得改。

问这个词你们那边说不说，得到的答案永远是说的，因为母语者对被动认得的词和主动会用的词分不清。

要问的是：你去店里买这个东西，开口第一句话怎么说。

还要追加一句：如果你在手机上打字搜这个东西，会不会打得跟说的不一样。

这两个问题分别对应口语形态和查询形态，它们经常不是一回事。本站讲母语审校说读着自然不能当验收通过 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)那一篇里的核心判据也是这个：把主观评价换成可观察的行为描述。

## 什么时候该停手

不是每个词都值得这么折腾。

保哥的判据是看这个词在不在页面的承重位置上。品类名、筛选项、标题里的核心名词，值得单独验；正文里的修饰词，跟着译者走就行。

一个站真正需要逐词确认的词，通常在40到80个之间，两天能问完。超过这个数量说明你在验的不是词表，是译文。

## 关键词工具那一侧，有没有把两个市场分开的入口？

## 这个实验的结果超出预期

保哥拿4组词、8个查询词，分别按孟加拉国和印度两个国家参数请求了一次搜索建议接口，想看看同一个词在两个国家会不会给出不同的建议。

结果是8组里有6组返回的建议列表完全相同，连顺序都一样。

只有洗澡和肉那两组出现了差异，而且差异也只是前几条的排序不同，词本身重合度很高。

## 这意味着什么

意味着在这个数据源上，孟加拉语这门语言没有被按国家切开。

你把国家参数从孟加拉国改成印度，返回的还是同一份候选池。

换个说法：工具告诉你的孟加拉语搜索量，是两个国家加在一起的那个数，而且你没有拆开它的入口。

这跟西班牙语、葡萄牙语那种情况差得很远。那两门语言至少能按国家拿到不同的数据，剩下的问题是数据准不准。孟加拉语这里是连接口都不给你。

## 为什么会这样，以及这个判断的边界

合理的解释是候选池的切分粒度跟着语言走，而不是跟着语言和地区的组合走。对英语、西班牙语这种有大量地区变体商业需求的语言，切分做得细；对孟加拉语这种量级的语言，切分停在语言这一层。

这个推测保哥没法证实，只能观察到现象。所以下结论的时候要收着说：不是搜索引擎不区分两个市场，而是这个特定的建议接口在这门语言上不区分。

排名结果那一侧完全可能是区分的，那是另一套系统。官方关于多地区多语言站点的说明 (https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites)里讲的也是索引与展示这一侧的机制，跟建议接口不是同一条链路。

## 那这份合并数据还能不能用

能用，但只能用来做一件事：判断一个概念整体有没有需求。

不能用来做的事有三件。

第一，不能用它比较两个词的优劣，因为两个市场的偏好被平均掉了，平均之后那个占优的词很可能只在人口多的那一边占优。

第二，不能用它估单个市场的流量盘子，误差方向不确定。

第三，不能用它做词表取舍，尤其是二选一的取舍——上一节那个不对称结论说明，正确答案在有些市场根本不是二选一。

## 接着往下挖，挖出了一件比合并数据更要紧的事

既然接口不按国家分，保哥换了个问法：不比国家，比词。同一个概念的两个词，各自拉出来的长尾是不是同一批意图。

做法是给每个词分别加三种商业修饰词——价格、购买、在线，看返回条数和返回内容。

鞋这一组的结果最干净，干净到有点吓人。

查询 | জুতা（孟加拉国惯用） | জুতো（西孟加拉惯用） | 

裸词 | 10条 | 10条 | 

加价格 | 10条 | 2条 | 

加在线 | 5条 | 1条 | 

裸词那一行两个词打平，看上去平分秋色。

往下两行就散架了。জুতা 加上价格能拉出10条完整的商业长尾，鞋码、鞋架、男鞋女鞋、在线订鞋、想在线买鞋，全是要掏钱的人打的字。

জুতো 加上价格只剩2条，而这2条返回的建议词里用的居然是另一个词形——接口自己把 জুতো 换回了 জুতা。加在线那一条同理。

## 这说明日常口语和商业查询走的不是同一条分叉线

জুতো 在西孟加拉的书面语和口语里都很常见，裸词的建议列表也证明了这一点：图片、词义、俗语、修鞋的叫什么，一应俱全。

可一旦查询里出现了买东西的意图，这个词形就基本消失了。真正在商业查询里活动的只有一个词形。

水那一组是另一种形态。পানি 拉出来的是净水器滤芯、水箱价格、水瓶、水龙头，一水儿的商品。জল 拉出来的是橄榄、狂犬病、水彩颜料、玫瑰水、净水咒语，一个净水设备都没有。

而这两个词在同一批新闻语料里的频率是接近的。也就是说，词频告诉你的是这门语言的表达面，搜索建议告诉你的是这门语言的钱在哪，这两张地图不重合。

## 还有一组的方向是反的

肉这一组，孟加拉国惯用的那个词加上价格只拉出1条，而且那一条问的是切肉机多少钱。西孟加拉惯用的那个词加上价格拉出10条，牛肉羊肉鸡肉水牛肉的价格全在里面。

方向跟鞋那一组正好相反。这条反例把一个偷懒的结论掐死了：不能得出孟加拉国那一侧的词形在商业查询里更强这种规律。

规律只有一条，而且是逐词的：每个概念在商业查询里都有一个主词形，它未必是这一侧口语里最常用的那个。要用哪一个，得逐词问一遍搜索建议接口，一个概念两分钟。

## 这条发现该怎么落地

词表要多记一列，叫商业词形。它跟市场归属那一列是独立的两件事。

页面上的分工也跟着变：标题、面包屑、结构化数据这些冲着交易查询去的位置，用商业词形；正文、常见问题、评价区这些冲着阅读体验去的位置，用当地口语词形。

本站讲两个市场的关键词表可以一字不差、落地页却得拆成两种 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)那一篇讲的是意图在语言里编码的位置，孟加拉语这里给出的是同一件事的一个极端样本：意图不但改变落地页，它先改变了词形本身。

## 那正确的数据源在哪

在你自己站上。

站内搜索日志按国家分开看，是这门语言上唯一能拿到真实分国别查询形态的地方，而且它一分钱不要。

如果站还没上线，退而求其次的办法是先上一个能覆盖两种写法的版本，跑三个月，用真实日志替代工具数据。这个做法的代价是前三个月的词表是猜的，收益是从第四个月起你有了别人拿不到的数据。

## 一个孟加拉语的词到底算几个字符？

## 先看一个例子

孟加拉语里健康与美妆这个品类名，屏幕上看是8个视觉字符。

放进程序里量，它是20个码位、60个字节。

如果你的字段限制写的是20个字符，那么这个品类名恰好把额度用光，一个字都加不进去；而同样20个字符的额度，英语能写下twenty characters这样一个短语再加几个空格。

这不是极端例子。保哥把20个真实品类词全量量了一遍，下面是结果。

## 五把尺子量同一批词

量法 | 20个词合计 | 相对字素簇的倍数 | 

UTF-8字节 | 700 | 5.15 | 

Unicode码位 | 244 | 1.79 | 

UTF-16单元 | 244 | 1.79 | 

标准字素簇 | 136 | 1.00 | 

手写的组合字符分组 | 219 | 1.61 | 

字素簇就是人眼看到的那个字。孟加拉语里一个视觉字符平均占5.15个字节、1.79个码位。

换算成字段额度是这样的：一个限100字节的字段，孟加拉语实际能写19.4个视觉字符；如果那个字段限的是100个码位，能写55.7个。同一个100，两种口径差了将近3倍。

本站讲平台给每个卖家的搜索词字段一样长 (https://zhangwenbao.com/minor-language-marketplace-listing-fields-tokenization.html)那一篇算的是字节这一层的账，孟加拉语在字节之上还多出一层：码位和视觉字符之间还差1.79倍。两层乘起来，同样的额度英语写一句话，孟加拉语写不下半句。

## 最后那一行才是真正会咬人的

前四行都是标准算法，差异是可预期的。第五行不是。

手写的组合字符分组，指的是很多截断函数里那段自己写的逻辑：遍历字符串，遇到组合类字符就并到前一个字符上，其余都当独立字符。这段逻辑写起来只要五行，看上去也很像那么回事。

它错在不认识那个叫做维拉马的止音符号。孟加拉语用它把两个辅音粘成一个合体字，粘完之后是一个视觉字符，可维拉马本身不是组合类字符，于是这段逻辑会把一个字数成两个甚至三个。

实测结果是：20个词，20个都不一致，一致率0。手写分组一共多数出83个字符，虚高61%。

虚高的后果不是崩溃，是静默截短。你以为还剩5个字符的额度，实际上早就满了，后台不报错，页面上少半个词。

## 同一份字节，换个库就换个数

更麻烦的是标准这一侧本身也在动。

Unicode从15.1版起改了文本分段的规则，把维拉马后面的那个辅音算进同一个字素簇，孟加拉文、天城文、古吉拉特文都在这次改动的范围里。

这意味着同一个合体字，跑在实现新规则的库上算1个字素簇，跑在实现旧规则的库上算2个。保哥本机这次用的库跑的是Unicode 16的规则，所以上面那张表里的136是新规则下的数。

如果你的前端用浏览器的分段接口计数、后端用一个几年没更新的库计数，两边给出的字数会不一样，而且不一样的地方全在合体字上——也就是全在孟加拉语最常用的那批词上。

这个结构跟本站讲前端往标题里塞了个看不见的字符 (https://zhangwenbao.com/minor-language-line-break-soft-hyphen-invisible-character.html)那一篇很像：单独看每一层都合规，合起来结果对不上。

## 横向对照一下，孟加拉语在几种文字里排第几

光看倍数不够直观，换成同一句话来量。把厨房用具这个品类名写成六种语言，各自量三次。

语言 | UTF-8字节 | 码位 | 视觉字符 | 

英语 | 18 | 18 | 18 | 

德语 | 14 | 12 | 12 | 

日语 | 18 | 6 | 6 | 

泰语 | 48 | 16 | 12 | 

孟加拉语 | 52 | 18 | 10 | 

缅甸语 | 69 | 23 | 12 | 

孟加拉语这一行值得盯一会儿：字节是英语的2.9倍，视觉字符反而比英语少44%。

换句话说，同样一句话，它在传输和存储上贵将近三倍，在屏幕上占的位置却不到英语的六成。

日语那一行是另一个极端，字节跟英语打平，视觉字符只有三分之一，所以日语站几乎从来不会因为字段额度出事。

这张表可以当成一份粗略的风险排序：字节列越大、视觉字符列越小的语言，越容易在字段额度上翻车，而团队越不容易发现，因为屏幕上看着还很空。

## 该用哪一把尺子

按用途分，别想着统一。

- 数据库字段长度、平台额度、传输限制：用字节。这一层的限制本来就是按字节定的，换算成字符只会自己骗自己。

- 给用户看的字数提示、编辑器里的剩余字数：用字素簇。用户数的是眼睛看到的字。

- 截断：用字素簇，而且必须用标准算法，不能自己写。

- 去重、比对、排序键：用规范化之后的码位序列。

四种用途四把尺子，听起来很啰嗦，可孟加拉语这门语言把它们之间的差距放大到了5倍，糊弄不过去。

## 为什么按首字母排的索引和前缀匹配，有一半会排错？

## 这门文字里有几个元音符号写在辅音左边

孟加拉文属于元音附标文字，元音符号挂在辅音周围。大部分挂在右边或上下，有三个挂在左边。

挂在左边这件事，麻烦不在于它挂在哪儿，在于它在字节里的位置和它在屏幕上的位置是反的。

按照Unicode的规定，存储顺序是逻辑顺序：先写辅音，再写元音符号。渲染引擎负责把那个元音符号搬到辅音左边去显示。

所以一个词的第一个码位，和它在屏幕上最左边那个符号，可能不是同一个东西。

## 实测：15个常见品类词里有8个是反的

保哥拿15个常见品类词做了一遍对照，结果是8个词的视觉首字符不等于码位首字符，占53.3%。

蛋糕、桌子、玩具、水壶、椅子、腰带、线缆、床，这几个词都在里面。它们的共同点是第二个码位是那三个左置元音符号之一。

另外7个词是一致的，比如手机、衬衫、冰箱、电脑。

五五开这个比例很讨厌。全错反而好办，一半错最难查，因为你随手抽查两个词很可能都是对的那一半。

## 这会在哪几个地方结算

第一是字母索引。做一个A到Z那样的首字母导航，如果你取的是第一个码位，得到的结果是对的；如果哪一层代码取的是渲染后的第一个可见字符，得到的结果就把一半的词归错了组。

第二是前缀匹配。用户在站内搜索框里打前两个字符，输入法送出来的是逻辑顺序，你的匹配逻辑如果按视觉顺序切过，就永远对不上。

第三是自动补全的高亮。补全列表里给命中部分加粗，加粗范围按码位算，视觉上会出现一个词从中间被劈开、加粗跑到了左边那个符号上的效果。这跟本站讲德语页面上加粗的那个词是个介词 (https://zhangwenbao.com/minor-language-emphasis-markup-anchor-drift.html)那一篇是同一类现象的另一种成因，那边是翻译移位，这边是渲染移位。

第四是排序。这一层反而不容易错，因为排序规则本来就工作在码位序列上，只要没人手工干预就是对的。

## 怎么自己测一遍

不需要懂孟加拉语，十分钟能做完。

找20个你站上的孟加拉语品类词，一列一列做四件事：打印每个词的码位序列，看第二个码位是不是那三个左置元音符号之一；在浏览器里把这个词放进一个盒子里，看最左边显示的是什么；对比两者；数不一致的比例。

如果不一致比例接近一半，说明你抽到的是正常样本，可以往下走。如果远低于一半，多半是你挑的词偏了，重挑。

这个测法的好处是它完全不依赖语言知识，只依赖码位表。本站讲转成小写这一步在土耳其语站上把词改成了另一个词 (https://zhangwenbao.com/minor-language-case-folding-lowercase-turkish-dotless-i.html)那一篇里的自检思路是一样的：不懂那门语言，就退到字符层去验。

## 这门语言的词表该按什么结构建？

## 比常规词表多三列

孟加拉语的关键词表，在词、量、意图这三列之外，还需要三列。

第一列是市场归属，取值是三个：只在孟加拉国用、只在西孟加拉用、两边通用。注意这一列不是二值的，通用那一档在这门语言里占比不低。

第二列是硬软标记，记这个词在对面那个市场是完全不用还是也在用。前面那个不对称结论决定了这一列的存在——同样是分叉词，处理动作不一样。

第三列是视觉首字符，专门给索引和前缀匹配用，避免每次都重算。

## 建表的顺序

第一步，从站上现有的品类树里把承重词捞出来，通常40到80个。

第二步，每个词过一遍搜索建议接口，记返回条数和长尾修饰词。返回零的先不删，标记为待验。

第三步，把待验的那批交给两位母语者，一位来自孟加拉国，一位来自西孟加拉，按上一节那两个问法分别问一遍。

第四步，填市场归属和硬软标记两列。凡是两位给出的答案不同的，就是分叉词。

第五步，字符层过一遍，填视觉首字符，同时用标准算法算出字素簇数，跟各个字段的额度对一遍。

## 词表填完之后，页面上怎么摆

西孟加拉侧的页面：分叉词只写本地那个，另一个连同义词表都不用配，因为那一侧的用户不用它。

孟加拉国侧的页面：分叉词两个都要出现，但位置分开。标题和面包屑用本地那个，正文和常见问题区里让另一个自然出现一到两次。

通用词：两边一样，不做任何处理。这一档是最大的一档，别去动它。

站内搜索的同义词表：两边都要把两个词互相映射上，因为搜索框里什么都可能出现。这一层是纯收益，成本几乎为零。

## 内链的锚文本要不要跟着分

要，但不是分两套锚，是分两套目标页。

孟加拉语没有格变化，锚文本不会像波兰语匈牙利语那样长出十几种形态，本站讲屈折语站的锚文本报告里精确匹配那一栏是假的 (https://zhangwenbao.com/minor-language-internal-link-anchor-inflection-variants.html)那一篇里的麻烦在这门语言上小得多。

真正要注意的是别让两个市场的页面互相内链到对方的分叉词上。这不是权重问题，是用户点进去看到一个不熟悉的说法，信任会掉一格。

## 上线之前，哪几项检查能自己跑完？

## 字符层的四项，不懂孟加拉语也能做

第一项，拿站上所有孟加拉语的标题和品类名，用标准分段算法算一遍字素簇数，跟各个字段的额度对一遍。凡是字素簇数乘以5.15超过字节额度的，标出来。

第二项，全站搜一遍自己写的截断函数。凡是按码位或者按组合字符分组截的，全部换成标准分段算法。这一步通常能翻出三到五处。

第三项，把品类词的第二个码位打印出来，标出那三个左置元音符号，看首字母索引和前缀匹配的实现取的是哪一个位置。

第四项，检查一遍规范化。孟加拉文里有两个字符可以用组合形式也可以用预组合形式写出来，入库前统一规范化，否则站内搜索会出现搜得到看不到的现象。

## 词表层的三项，需要两位母语者

第五项，承重词逐个过市场归属，两位母语者答案不同的就是分叉词。

第六项，分叉词逐个填硬软标记，确认对面市场到底是完全不用还是也在用。这一列填错的代价，前面第三节算过。

第七项，站内搜索同义词表把所有分叉词双向映射一遍。

## 数据层的两项，最容易被跳过

第八项，结构化数据里的语言标签写清楚。孟加拉文只有一套书写系统，所以书写系统子标签可以省，但地区子标签不能省——bn-BD和bn-IN是两个不同的目标。本站讲正文越本地化越好而结构化数据里要反着写回国际格式 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)那一篇里的三分法在这里照样成立。

第九项，商品数据源按市场拆成两份，别指望一份数据同时喂两个市场。属性值那一列尤其要拆，因为品类词就藏在属性值里。

## 开头那家净水站后来改了三处

第一处是把品类词按市场归属重排了一遍。他们那套词表是加尔各答译者写的，水这个概念全站只有梵语来源那一个词形，孟加拉国那一侧等于把一半的表达面留在了门外。改法不是替换，是在孟加拉国版的正文和常见问题区里把另一个词形补进去，标题不动。

第二处是把标题里的品类词换成了商业词形。这一处是照搜索建议接口逐词问出来的，滤芯、水箱、水龙头这三个承重词各花了两分钟。

第三处最不起眼，是把商品标题的截断函数换了。原来那段是遍历字符遇到组合符号就往前并，换成标准分段之后，商品列表页上被切掉半个字的品类名少了一批。这一处没带来流量，带来的是客服那边再没收到过看不懂商品名的反馈。

三处改动里前两处属于选词，第三处属于字符层。团队原本只打算做前两处，第三处是做字符层自检的时候顺手捞出来的——这也是保哥一直建议把字符层那四项排在词表层前面的原因：它不需要任何语言知识，一个下午能跑完，而且经常能捞到别的收获。

## 哪些相邻的问题不归这一层管

域名怎么分、hreflang怎么配、要不要按地区做跳转，这三件事跟孟加拉语没关系，属于国际化架构层，换成任何一门跨国语言都是同一套做法。

孟加拉文字体的体积、首屏加载被字体拖住多少，归字体那一层，本站算过非拉丁文字的字形集有多大 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)。

孟加拉国和印度两个市场在支付、物流、税这几件事上的差别，比语言层的差别大得多，但它不是语言问题，别混在同一张表里管。

孟加拉语的问答式长尾该不该做，判据在本站讲小语种问答长尾的供给密度 (https://zhangwenbao.com/minor-language-qa-long-tail-content-value-ai-era.html)那一篇里，跟本篇的分叉问题是两条独立的账。

## 三种看着合理、实际在帮倒忙的做法

## 第一种：把两个词都塞进同一个标题

既然孟加拉国那边两个词都用，那就在标题里都写一遍，看起来很划算。

问题是标题的长度在这门语言上本来就紧张。前面算过，字段限100字节只能写19.4个视觉字符，塞两个同义词进去，留给真正区分度的部分就没剩多少了。

正确的做法是分层：标题写一个，正文和常见问题区里让另一个自然出现。这样两个词都在页面上，但只有一个占用最贵的那块地。

## 第二种：为两个市场各建一套完整内容

这个做法的问题不是浪费，是浪费得没道理。

本篇实测的8组词里，只有1组给出干净分叉，1组明确不分叉，6组测不出。就算把测不出的那6组全算成分叉，分叉词在整个词表里的占比也远达不到需要两套内容的程度。

本站讲捷克语和斯洛伐克语哪些内容能原样照搬 (https://zhangwenbao.com/czech-slovak-seo-content-reuse-decision.html)那一篇里的三档判据在这里可以直接套用：能整块照搬的、改词就能过的、必须重写的。孟加拉语两个市场之间的绝大部分内容落在第二档。

做成两套的代价还不只是钱。两套内容之后就有两套更新节奏，半年之后它们会自己漂开，而没有人负责对齐。

## 第三种：用机器翻译在两个变体之间转换

这个想法很自然：既然是同一门语言，找个工具把孟加拉国版转成西孟加拉版不就行了。

不行，因为机器翻译系统眼里这两边是同一门语言，输入什么输出什么，它不会替你换词。

真要自动化，可行的是一张词对映射表加一次替换，而不是一次翻译。表就是第八节那张，替换只对分叉词生效，通用词一个都不能碰——碰了就是把好好的文章改出翻译腔。

## 还有一个反面提醒：别把这套方法当通用模板

不对称分叉这个结论是从孟加拉语这一门语言上测出来的，成因是两边规范化路径不同。

换一门语言，方向可能是反的，也可能两边都是硬的。本站讲荷兰语在荷兰和比利时的两个市场 (https://zhangwenbao.com/dutch-seo-netherlands-belgium-flemish-two-markets.html)那一篇里的形态就跟这里不一样。

要搬的是方法：抓两边的真实语料、按词逐个数、把结果按硬软分档。别搬结论。

## 常见问题解答

## 孟加拉语只做一个市场的话，该选哪一边？

看品类。如果卖的是价格敏感的日用消费品，孟加拉国那一侧人口更多、电商渗透还在爬坡，长期盘子更大；如果卖的是客单价较高、依赖支付和物流成熟度的品类，印度西孟加拉那一侧基础设施更好。另外还有一条容易被忽略的：西孟加拉那一侧的用户里，用英语搜索的比例明显更高，这会把孟加拉语内容的实际覆盖面往下压。先看这三个变量，再决定。

## 两边共用一套页面，只把分叉词做成同义词，可行吗？

技术上可行，效果打折。同义词只在站内搜索那一层有用，它不改变页面上真正出现的那个词，而搜索引擎匹配的是页面上出现的词。可行的折中是共用一套页面骨架，只把标题、品类名和常见问题区这三处按市场生成两个版本，其余共用。改动量比想象的小，因为分叉词集中在这三处。

## 词频实测那八组里六组是零，是不是说明这套方法不管用？

说明的是语料选错了，不是方法不管用。新闻语料的题材决定了它测不出商品品类词，报纸不写鞋和水壶。方法本身没问题，换成分类信息站的商品标题或者本地零售商的宣传单，同一套数法照样能跑。测量失败的时候先怀疑尺子，别急着改结论。

## 为什么不能直接信关键词工具给的孟加拉语搜索量？

因为在这门语言上，工具那一侧没有把两个国家分开的入口。实测8组查询词，切换国家参数之后有6组返回的建议完全相同。这意味着你看到的那个量是两国合并值，而两国的用词偏好不一样，合并之后占优的那个词很可能只在人口多的一边占优。这个数只能用来判断一个概念整体有没有需求，不能用来在两个词之间做取舍。

## 字段长度到底该按字节算还是按字符算？

按用途分开算，别求统一。数据库字段、平台额度、传输限制这三处按字节，因为它们的限制本来就是字节；给用户看的剩余字数和做截断按字素簇，因为用户数的是眼睛看到的字；去重和排序按规范化之后的码位。孟加拉语里这三把尺子之间差到5倍以上，混用一定会出事。

## 自己写的那段截断逻辑，为什么在别的语言上一直没出过问题？

因为它在拉丁字母上恰好是对的，在有变音符号的语言上也基本对，这两类占了大多数团队的日常。它错在不认识把两个辅音粘成一个字的那个止音符号，而这个机制只在南亚和东南亚的几套文字上大规模出现。实测20个孟加拉语品类词，这段逻辑和标准算法给出的数字20个全都不一样，平均虚高61%。虚高不会报错，只会静默截短。

## 做孟加拉语之前，最该先花半天做的是哪件事？

把承重词捞出来，找一位孟加拉国的母语者和一位西孟加拉的母语者，各问一遍同一批词。问法要具体到行为：你去店里买这个东西开口第一句怎么说，你在手机上搜这个东西会打什么。半天就能拿到一张带市场归属的词表，而这张表决定了后面所有内容的走向。跳过这一步，后面每一篇文章都要重做一次。

## 权威参考资料



## 用户撞上404的那一刻，请求已经不在你的应用里了，本地化也就管不到

- URL：https://zhangwenbao.com/minor-language-error-page-fallback-language.html
- 分类：小语种SEO
- 发布：2026-04-30  |  更新：2026-07-30
- 摘要：404和503由服务器或边缘节点输出，那一层没有语言这个维度。讲清自带错误文档实际覆盖哪些语言、请求头能不能信、指到外部地址为什么会把状态码改坏。
- 关键词：技术SEO,多语言SEO,内容本地化,小语种SEO

> **TLDR**：摘要：站上每一个字都能本地化，唯独出错那一页经常不能。原因不在预算也不在流程：撞上404或者503的那一刻，请求多半已经离开了你的应用，输出这一页的是服务器软件或者边缘节点，而那一层压根不知道用户是谁。服务器自带的多语言错误文档其实有21门语言，默认优先级表里只挂了14门，而阿拉伯语、越南语、泰语、印地语一门都没有。本文拆开三层来源、语言协商靠不靠得住、一版英文页够不够用的判据，以及怎么在不改坏状态码的前提下把这一页做出来。

> 摘要：站上每一个字都能本地化，唯独出错那一页经常不能。原因不在预算也不在流程：撞上404或者503的那一刻，请求多半已经离开了你的应用，输出这一页的是服务器软件或者边缘节点，而那一层压根不知道用户是谁。服务器自带的多语言错误文档其实有21门语言，默认优先级表里只挂了14门，而阿拉伯语、越南语、泰语、印地语一门都没有。本文拆开三层来源、语言协商靠不靠得住、一版英文页够不够用的判据，以及怎么在不改坏状态码的前提下把这一页做出来。

## 站上每一个字都能本地化，为什么偏偏出错那一页不能？

## 一家宠物用品站的越南语页面，三个月没人发现的那一页

有个客户做宠物用品，猫砂盆、牵引绳、宠物笼、猫爬架这几条线。

越南语和波兰语两个市场，页面翻译请的都是本地写手，验收流程也一样。

那年秋天他们做了一次品类重构，一批旧地址失效，重定向做得不算干净。

三个月后越南站的品牌词表现莫名其妙地滑了一截，波兰站没事。

保哥拿越南本地的网络环境挨个点了一遍旧地址，点到第四个的时候看见了那一页：一张纯英文的服务器默认错误页，没有导航，没有搜索框，落款是服务器软件的版本号。

更尴尬的是那页上唯一一行大字写着请求的资源在此服务器上未找到，而这句话是二十多年前写进软件里的默认文案，跟这家店、这个品牌、这门语言都没有半点关系。

那一页还有个额外的坏处：落款把服务器软件和版本号一并写了出来。这在安全上是不必要的暴露，把这一页做掉顺手就能把这行去掉，属于一次改动两处收益。

## 出错这一刻的特殊之处：请求已经不在你的应用里了

这件事值得单独拆，因为它跟别的本地化缺口不是一个成因。

页面上的文案没翻译，多半是没抽出来或者没排上期，属于流程问题。

错误页不一样，它经常是根本没有地方可以做。

用户能看到本地化内容的前提是请求走到了你的应用里，应用知道他是谁、来自哪个市场、该用哪套语言资源。

而404和503恰好是那一类请求走不到应用里的情形：地址不存在，应用没被调用；服务过载，应用起不来。这时候站出来说话的是它前面那一层，那一层手里没有语言这个概念。

还有第三种情形也归这一类：跳转链断在中间。用户从外部链接进来，中间某一跳指向了一个不存在的位置，最终停在的那一页同样由服务器输出，而不是你的应用。

## 所以这不是没做，是没有地方可做

这个区别很重要，因为它决定了往哪儿使劲。

如果是没做，解法是排期、找译者、走验收。

如果是没有地方可做，解法在配置层，跟译者一点关系都没有。

很多团队在这一页上反复讨论文案该怎么写、要不要幽默一点，然后发现写好的文案根本没地方放。

顺序应该反过来：先确认这一页由谁输出，再决定它能承载多少语言。本站在界面文案那批从没进过翻译文件的字 (https://zhangwenbao.com/minor-language-hardcoded-ui-strings-pseudo-localization.html)里讲过一次相近的错觉，那边是字没被抽出来，这边是字压根不在你的程序里。

分辨自己属于哪一种有个很快的办法：把那一页的源码存下来，搜一下有没有你自己的模板痕迹，比如导航结构、样式表地址、统计代码。有就是应用输出的，没有就不是。三十秒能判完。

## 先把故障页按归属分成三类

动手之前把站上的故障页分成三类，后面所有决策都按这三类走。

第一类是应用输出的，比如商品下架页、搜索无结果页、登录失效提示。

第二类是服务器软件输出的，比如地址不存在、维护中、权限不足。

第三类是边缘节点或者第三方输出的，比如内容分发网络的拦截页、防火墙的挡板、支付网关跳回来的失败页。

第一类跟别的页面没区别，本来就该本地化；第二类要动配置；第三类多数动不了，只能绕。分类这一步花不了二十分钟，却能省掉后面所有的方向性争论。

还有一类边界情形值得单列：托管在静态平台上的站。这类站没有传统意义上的服务器配置，故障页由平台的路由规则决定，能力介于第二类和第三类之间，要看平台文档里的重写规则支持到什么程度。

## 错误页到底是谁输出的，三层来源里哪一层没有语言这个概念？

## 应用层：它知道用户是谁，也知道该说哪门语言

应用层输出的故障页其实是最幸运的一类。

请求已经进来，会话在，语言资源加载好了，路由也知道当前是哪个市场。

这一层的故障页跟普通页面走同一套模板和同一份翻译文件。

它出问题的方式也跟普通页面一样：某几句提示没被抽出来，或者抽出来了但目标语言里缺译。

换句话说，应用层的故障页不属于本文要解的问题，它属于界面文案那一类，按老办法处理就行。

应用层的故障页还有一个特有的坑：它很容易返回200。因为它是被正常路由渲染出来的一个页面，框架不会自动把状态码改成404，需要显式设置。这就是软404最常见的来源。

## 服务器层：它只认文件路径，不认用户

再往外一层是服务器软件，这一层是本文的主角。

它的配置里有一条指令，作用是把某个状态码映射到某个文件。

这条指令的参数是一个路径，不是一个函数。

路径是死的，同一个状态码永远指向同一个文件，除非你额外做点什么。

所以默认情况下，一个站只有一份404页，不管来访的是德国人、越南人还是爬虫。语言在这一层不是被忽略了，是这一层的数据模型里没有这个维度。

这一层还有一个容易被忽略的能力：部分服务器软件允许在指向内部页面的同时显式改写返回的状态码。这个能力用对了很有用，用错了就是把404变成200，正好制造出一批软404。

## 边缘层：这时候你的代码一行都没执行

最外面那一层最麻烦。

内容分发网络在边缘节点上就把请求挡了，源站什么都不知道。

网络应用防火墙判定这次访问可疑，直接返回一张挡板页。

这两种情况下你的服务器配置完全没参与，服务器软件那条指令也就无从谈起。

能改的只有边缘服务商自己的自定义错误响应功能，而它的能力边界由服务商决定，多数只允许你上传一份静态页面。

边缘输出的挡板页还有一个额外风险：它可能被抓取程序拿到并当成你的内容。挡板页多半是英文的、内容雷同的、没有导航的，一批这样的页面被抓走，对站点的整体判断没有任何好处。

## 用一次抓包分清自己站上的三层各占多少

纸上谈兵没用，得知道自己站上这三层的实际分布。

做法是把最近三个月产生过404和503的地址导出来，取前一百条。

逐条请求一次，只看响应头里的服务器标识和几个特征字段。

带着应用框架特征的是第一类，只有服务器软件标识的是第二类，带着边缘服务商标识的是第三类。

一百条跑完通常半小时，结果往往出人意料：多数团队以为绝大部分故障页由应用输出，实测下来第二类和第三类加起来能占到一半以上。服务器配置那份清单 (https://zhangwenbao.com/website-server-configurations-seo-impact.html)里讲过怎么读这些响应头，配着看能省不少事。

记录建议固定成五列：地址、状态码、响应头里的服务器标识、判定归属、页面语言。第五列要靠人眼看一下页面正文是什么语言，这一列正是所有报表都不会给你的那个信息。

## 服务器软件自带的那份多语言错误页，到底覆盖了哪些语言？

## 它其实早就准备好了，只是没人打开过

这里有个不少人不知道的事实。

主流的开源服务器软件在安装时就附带了一整套翻译过的错误文档。

官方文档里专门有一节讲这件事，标题就叫多语言自定义错误文档。

它还附了一份现成的配置文件，放在额外配置目录里，取消注释就能生效。

也就是说，多数站上其实躺着一套现成的本地化错误页，只是从来没有人把它接上过。这大概是本站写过的所有本地化缺口里，修复成本最低的一个。

要提醒一句的是这套现成资产只存在于其中一类服务器软件上。另一类常见的服务器软件没有等价的自带多语言错误文档，它的错误页指令只能指向一个固定文件，多语言要靠自己写规则实现。

顺带说一句，这套资产的存在本身也说明了一件事：二十多年前设计这套软件的人是认真考虑过多语言的，他们把这条路铺好了，只是后来没有人走。技术上的可能性和组织上的执行之间，隔着的从来不是难度。

## 那份清单上有21门语言，默认优先级表里只挂了14门

把那批文件打开数一遍，会看到一个有意思的差额。

每个状态码对应一个多变体文件，文件里按语言列出了变体，数下来是21门。

而官方给的那份配置文件里，语言优先级指令上只列了14门。

差出来的7门里包括俄语、塞尔维亚语、葡萄牙本土葡语、挪威语、爱尔兰语和两种中文。

这些翻译文件躺在磁盘上，只有当浏览器明确要求它们的时候才会被挑到；在偏好不明确的场合，服务器会按优先级表回落到英语。你付了硬盘空间，却没有用上那份翻译。

这个差额多半是历史造成的：翻译文件是社区陆续贡献进来的，而那份示例配置写好之后没有跟着更新。这类差额在开源项目里很常见，也正因为常见，没有人会主动去数一遍。

对做站的人来说，结论是别相信示例配置里的清单，要自己打开那批文件数一遍实际有哪些语言。数一遍不到五分钟，而它决定了你要不要为某门语言另外准备文件。

## 清单上没有的那些语言，恰好是你要开的市场

更值得看的是完全不在这21门里的那些。

阿拉伯语没有，希伯来语没有，越南语没有，泰语没有，印地语没有。

希腊语、匈牙利语、芬兰语、乌克兰语、印尼语、波斯语，一门都没有。

这份清单的构成大致对应二十多年前的互联网版图，而它此后基本没有变过。

这跟本站反复遇到的那条规律又一次对上了：一整套默认值是照着某个时期的典型场景定下来的，场景早就变了，默认值还留在原地。开东南亚和中东市场的人，在这一页上是彻底没有存量可用的。

自己补一份的成本其实不高。那批文件是多变体格式，结构固定，照着现有的一份复制一遍、把语言标识改掉、把正文换成本地语言，一门语言不到二十分钟。真正花时间的是找人写那几句话。

还有一个观察值得记：这份清单里有爱尔兰语这样使用人口很小的语言，却没有阿拉伯语。这说明收录与否取决于当年有没有人愿意贡献那份翻译，跟市场规模没有关系。别拿商业重要性去推断有没有现成资源。

## 打开它要付什么代价

好消息讲完了，讲代价。

这套机制依赖内容协商模块，也就是让服务器根据请求头挑一个语言变体。

启用它意味着多一个模块、多一层匹配开销，而且那批自带文案的语气是纯技术风格，跟品牌调性差得很远。

还有一个隐蔽的副作用：内容协商一旦打开，它的作用范围不止错误页，配置不当会影响到别的路径。

所以务实的做法是把它当成一个原型：先用它验证语言协商这条路在自己站上通不通，通了再换成自己写的文案。自定义错误页那篇技术拆解 (https://zhangwenbao.com/apache-errordocument-custom-error-pages-http-status-codes-soft-404.html)里给过一句判断，说按访客语言出对应语种会引入动态判断、小站做一版规范的英文页也够用；从纯技术角度这句话没错，但那份判断没有把多语言站算进来，下一节就来给它补一个判据。

还有一个跟性能有关的副作用：启用内容协商之后，响应里会带上一个告诉缓存按什么维度区分的头。这个头会直接影响边缘缓存的命中率，因为同一个地址被拆成了按语言分的多份缓存。

## 语言协商能不能救场，浏览器发过来的那个头够用吗？

## 请求头里确实带着语言偏好

浏览器在每次请求里都会带一个表示语言偏好的头。

它的值是一串语言标签，还带着权重，表示用户更想要哪一门。

这个值来自浏览器和操作系统的设置，不需要用户额外做什么。

服务器完全可以读它，然后挑一份对应语言的错误页出来。

听起来这条路很顺，问题出在它跟你站上的语言版本不是一回事。

实际抓一批请求会发现，多数浏览器只发两三个语言标签，权重也很简单。所以这个头的信息量比规范允许的要少得多，指望靠它做精细判断是不现实的。

## 浏览器偏好和市场版本是两个坐标系

这是这条路最大的坑。

一个在德国生活的土耳其人，浏览器语言可能是土耳其语，而他要买的是德国站的东西。

一个用英文系统的日本用户，浏览器发过来的是英语，他要的却是日语页面。

换句话说，请求头说的是这个人习惯读什么，你的站分的是这批货卖去哪儿。

两个坐标系经常不重合，本站在两种语言都看得懂的用户 (https://zhangwenbao.com/ukrainian-russian-seo-bilingual-market-content-split.html)那篇里拆过这种错位，这里只补一句：错误页比普通页面更该谨慎，因为用户此刻已经处在一次挫折里，再被扔到一个他没要求的版本上，挫折会翻倍。

有个可以量化的做法：在正常页面上抽样统计请求头的首选语言与地址前缀语言的一致率。一致率高的市场可以放心用请求头兜底，一致率低的市场就别用。这个数一次统计能用很久。

## 匹配规则比想象中松，会挑出你没准备的那一门

还有一层技术细节值得知道。

语言标签的匹配有一套标准算法，分基本匹配和扩展匹配两种。

基本匹配允许前缀命中，也就是说请求要的是某个地区变体，服务器可能拿一个更宽的变体去顶。

这在正常页面上通常是好事，在错误页上偶尔会挑出一个你根本没审过的文件。

更常见的一种表现是权重相同的时候按优先级表挑，而优先级表是你配的，不是用户要的。所以这条路的正确用法是：只在你确实准备了那门语言的时候才让它参与协商，没准备的一律回落。

两种匹配的差别在带地区码的场合最容易咬人。用户要的是某个地区变体，你只准备了通用变体，基本匹配会把通用变体给他，这通常没问题；反过来你准备了多个地区变体而用户只要通用的，挑中哪一个就取决于优先级表。

## 什么时候该信这个头，什么时候该信地址

给一条能直接用的判据。

如果失效的那个地址本身带着语言前缀或者国家目录，那就按地址走，别看请求头。

地址里带的信息是确定的，它说明用户原本要去哪一版。

只有当地址完全不带语言信息时，才退回去读请求头。

这条判据的好处是它把绝大多数情况交给了确定信息，只把剩下的小部分交给猜测。对于目录形式的多语言站，这条几乎能覆盖九成的故障请求。

还有第三种情形：地址带国家不带语言，比如按国家分目录但一个国家里有两门官方语言。这时候地址只能确定国家，语言仍要靠请求头，而这恰好是双语国家最容易出错的地方。

还有一个特别值得提的场景：抓取程序发来的语言偏好通常是空的或者一个固定值。所以按请求头出语言的方案，在抓取程序那里永远走的是回落分支，它看到的始终是默认语言那一版。

## 一版英文错误页到底够不够用，判据是什么？

## 够用这个结论是在什么前提下成立的

先承认这个结论有它成立的场合。

如果你的站只有一门非英语语言，而且那个市场的英语普及率很高，那一版规范的英文错误页确实够用。

如果故障页的流量极低，低到一个月只有几十次，那投入产出也不划算。

这两个前提在很多技术文章的写作场景里是默认成立的。

问题是它们在多语言电商站上多数不成立，而不成立的方式还不止一种。

这两个前提在写技术文章的场景里天然成立，因为技术文章的读者多半在处理单语言站的配置问题。这不是作者的疏忽，是场景差异，而读的人往往不会注意到自己的场景已经不同了。

## 三个把它推翻的场景

第一个场景是改版。

一次品类重构或者地址结构调整，能在一周内制造出成千上万次故障请求，而且这批请求集中落在你最值钱的那批旧地址上。

第二个场景是英语普及率低的市场。越南、泰国、巴西、俄语区，一张纯英文的技术风格错误页对当地用户来说跟一张白屏差别不大。

第三个场景是信任。故障页是用户对一个陌生站点做信任判断的高危时刻，此刻出现一门外语，等于在说这个站不是给你做的。本站在落地页上那几个最像装饰的信任元素 (https://zhangwenbao.com/minor-language-landing-page-trust-signals-payment-address-support.html)里量过这一层的分量，故障页是同一条逻辑的极端版本。

还有第四个场景：站点被外部大量引用。外部引用里的地址是别人写的，写错、写旧、带着追踪参数都很常见，这批流量落到故障页上的比例比自有流量高得多，而它们通常来自你最看重的那些来源。

## 按流量算这一页的价值，算法跟别的页不一样

常规做法是按页面浏览量排优先级，故障页在这个排序里永远垫底。

但故障页的价值不在它自己的浏览量上，而在它拦住了多少条本来要流失的路径。

正确的算法是看这批请求原本要去哪儿：如果它们指向的是品类页和商品页，那这一页拦的是交易意图。

做法是把故障地址按原目标页面类型分组，算出指向商品页的那部分占比。

这个占比超过三成，这一页就该按商品页的标准来做，而不是按技术页的标准。

这个占比拿起来不难：把故障地址按路径结构分类，带商品标识的归商品页，带分类路径的归品类页，其余归其他。用一条正则就能分完，几千条地址跑一次不到一分钟。

## 三档投入分别做到哪一档

把投入分成三档，按市场对号入座。

最低一档是一版设计过的英文页，带搜索框和主要品类入口，状态码正确。适合英语普及率高、语言版本只有一两个的站。

中间一档是按地址前缀出对应语言的静态页，每门语言一个文件，文案由本地写手写一次。适合三门以上语言、且有主力小语种市场的站。

最高一档是把故障页接回应用层，带上个性化推荐和最近浏览。这一档只在故障请求量确实很大、或者改版频繁的站上才划算。多数站停在中间那一档就够了，再往上投的边际收益掉得很快。

从第一档升到第二档的触发条件建议写死成一个数：当第二门非英语语言上线时。这个时点很好识别，也正好是问题开始成规模的时点，比按流量阈值判断更容易执行。

## 错误页的文案在小语种里，为什么比英语更难写？

## 它是全站语气要求最高的一页

这一页要在两三句话里同时完成四件事。

说清楚出了什么事，表明这是我们的问题不是你的问题，给一条出路，还不能让人更烦躁。

四件事挤在两三句话里，对措辞的精度要求比商品描述高得多。

商品描述写得平庸只是不出彩，故障页写得平庸会直接放大用户的挫折感。

而这一页恰恰是最容易被丢给机器翻译的一页，因为它字少、看着不重要、也没人愿意为它开一次审校。

这一页还有个结构性的劣势：它字太少。机器翻译在短文本上的表现明显差于长文本，因为上下文不够。全站最短的几段文字恰好是语气要求最高的几段，这个组合对机翻是最不利的。

## 道歉这件事在各语言里的分寸不一样

这一页的核心动作是道歉，而道歉是各语言差别最大的言语行为之一。

日语的道歉有明确的档位，档位选低了显得敷衍，选高了显得这事很严重。

德语市场对夸张的致歉措辞不太买账，直接说明情况反而更得体。

把英文那句抱歉直译过去，多数语言里会落在一个不太对的档位上。

本站在退货政策那句承诺翻完之后强度就变了 (https://zhangwenbao.com/minor-language-modality-obligation-commitment-strength.html)里拆过这类强度漂移，故障页文案是同一类问题的短句版：句子越短，一个词的档位就越决定整句的语气。

有个能直接执行的做法：让本地写手按轻中重三档各写一版，然后你拿三版去问另外两个母语者哪一版最像正规商家会说的话。这个流程不需要你懂那门语言，也不依赖单个写手的判断。

## 文本膨胀在这一页格外要命

故障页的版面通常是居中一块，宽度写死。

英文原文两行的文案，翻成德语可能变成三行，翻成芬兰语更长。

普通页面上多一行没什么，故障页上多一行可能把唯一那个按钮挤出首屏。

而这一页几乎没有人会在真机上按语言逐个看过。

膨胀比例和处理办法本站在德语长词在手机上撑破版面 (https://zhangwenbao.com/minor-language-line-break-soft-hyphen-invisible-character.html)那篇里讲过，这里只提一条针对故障页的：这一页的文案要按最长的那门语言排版，而不是按英文排版，因为它只有一个版式。

按最长语言排版的具体做法是：先让写手把所有语言版本都写出来，量一遍字符数，取最长的那一版去定版面宽度和按钮位置。之后哪怕再加语言，也在这个宽度里试排一次即可。

## 别在错误页上玩梗，尤其是在不是你母语的市场

英文错误页上放一句俏皮话是行业惯例，效果通常不错。

这个惯例在跨语言时的失败率高得惊人。

幽默依赖共同语境，而共同语境正是你在一个新市场里最缺的东西。

更糟的是幽默翻译得不好会读成轻佻，用户此刻本来就不高兴。

稳妥的做法是：母语市场可以玩，本地写手主动提出来的可以玩，其余一律用直白得体的说法。少一点俏皮换来的是零风险，这笔交易在故障页上是划算的。

有一个例外：品牌调性本身就建立在轻松感上、并且本地写手主动提议的，可以试。判断标准是这句俏皮话有没有经过至少两个母语者点头，而不是译者觉得可以。

## 本地化错误页的时候，怎么保证状态码不被改坏？

## 状态码和文案是两件事，改文案不该动状态码

这是这一节唯一需要记住的原则。

状态码告诉机器发生了什么，文案告诉人发生了什么。

两者可以各自本地化，但不能互相影响。

做错误页的人多数关心文案，配服务器的人多数关心状态码，两拨人交接的地方就是事故高发区。

本站在HTTP状态码那份图谱 (https://zhangwenbao.com/http-status-codes-seo-atlas-redirect-410-decision.html)里讲过每个码该在什么场合用，这里只补跟多语言相关的那几处坑。

两拨人交接的地方建议固定成一条检查项：任何一次故障页改动，都要在合并前跑一遍状态码验证。把它挂进发布流程，比靠人记住可靠得多，因为这类改动通常不被当成有风险的改动。

## 最常见的一种改坏：指到外部地址就变成了跳转

这个坑写在官方文档里，但很少有人读到那一句。

服务器的错误页指令，参数如果是一个本地路径，服务器会在内部处理并保留原始状态码。

参数如果是一个完整的外部地址，服务器会改成向客户端发一次跳转。

结果是客户端收到的不再是404，而是一个跳转码，然后再收到目标页的200。

多语言站踩这个坑的概率比单语言站高得多，因为大家很自然地会想把不同语言的错误页放在各自的语言目录下，写着写着就写成了带域名的完整地址。检查方法是把配置里所有错误页指令的参数看一遍，凡是以协议开头的都要改成以斜杠开头。

另一类服务器软件上有一个形状不同但后果相同的坑：错误页指令和跳转指令写法相近，写错一个关键字就会把内部渲染变成外部跳转。检查方法一样，看配置里这一族指令的参数是不是以斜杠开头。

## 软404在多语言站上会多出一种成因

软404指的是页面内容说找不到，状态码却是200。

单语言站上它多半来自应用层的兜底逻辑。

多语言站上还多一种：语言回落。用户请求某个语言版本的某个页面，那门语言没有这个页面，系统悄悄回落到默认语言的同名页面并返回200。

从状态码看这是一次成功访问，从用户看这是一次内容缺失，从检索看这是一个跟默认语言页面高度相似的重复页。

这一类比普通软404更难查，因为页面本身是完整的、有内容的、有正确样式的，只是语言不对。软404怎么排查 (https://zhangwenbao.com/google-404-crawl-seo-positive-signal.html)那篇给的方法在这里仍然适用，只是要多加一个筛选条件：把返回200但页面语言与地址前缀不一致的记录单独捞出来。

这类回落页还有一个连带损害：它跟默认语言的同名页面内容几乎一样，于是在跨语言重复判定上落得很难看。本来是缺一页内容，最后表现成两页互相稀释。

## 上线后怎么验状态码真的对

验证不能靠肉眼看页面，页面看着对状态码可能是错的。

要用能显示响应头的工具逐条请求，只看状态码那一行。

要验的清单是：每门语言各一个不存在的地址、每门语言各一个已下架商品、维护页开启时的一个正常地址。

三类各跑一遍，语言数乘以三就是要跑的条数，四门语言也就十二条。

顺手把跳转链也看一眼，故障页前面挂着一串跳转是很常见的现象，而每一跳都在消耗抓取预算。

工具上不必讲究，能显示响应头就行，命令行的请求工具或者浏览器的开发者面板都可以。要看的只有三行：状态码、内容语言、以及有没有跳转链。三行看完这条就算验过。

## 那些你根本改不到的错误页，该怎么处理？

## 边缘节点的拦截页

内容分发网络和防火墙在边缘挡下的请求，源站完全不知情。

这类页面由服务商生成，默认是英文，带着服务商自己的品牌和一串排查编号。

多数服务商提供自定义错误响应功能，允许你上传一份自己的页面。

但要注意它通常只允许一份，也就是说语言这个维度在这里又一次消失了。

务实的做法是把这一份做成不依赖语言的版本：图形化的提示、品牌标识、一个回首页的按钮，文字尽量少。文字越少，它在多少门语言下都不算错。

如果服务商允许，把这份自定义页面设成不允许索引，是一个零成本的动作。挡板页本来就不该进索引，而默认设置多半没有加这一条。

## 支付网关跳回来的那一页

结算失败是转化链上最贵的一次故障，而这一页经常不由你输出。

用户在网关那边失败，网关按它自己的语言设置显示一段话，然后跳回你的站。

跳回来的地址上通常带着一个错误码参数，而你的页面拿这个参数做了什么，多数团队没检查过。

能做的动作有两个：一是在接入时把语言参数显式传给网关，多数网关都有这个字段，只是接入的时候没人填；二是自己接住跳回来的错误码，用自己的语言给出一句解释，而不是原样显示网关那段话。

第一件事的性价比极高，因为它属于接口文档里明明写着、接入时图省事没填的那一类。机器不完全相信你写在页面上的语言声明 (https://zhangwenbao.com/minor-language-page-language-detection-misidentification-short-text.html)那篇里记过同一个模式：问一句有没有把语言字段传给它，往往比问它怎么判断更快找到根因。

语言参数在多数网关的接口文档里叫地区或者语言环境，取值多半是标准语言标签。查的时候直接在文档里搜这个词，通常两分钟能找到，找到之后填进去就完事。

## 第三方组件自己弹的提示

评价插件、客服窗口、地址校验、库存查询，这些组件都会在出错时弹自己的提示。

它们的语言由组件自己的语言包决定，跟你的站没有关系。

多数组件支持传入语言参数，少数只认浏览器设置。

排查办法是把站上接入的第三方组件列一张表，逐个记录它的故障提示走哪套语言。

这张表通常十行以内，一次列完能用很久，而且它顺手回答了另一个问题：哪些组件在小语种下压根没有语言包，那几个是要考虑换掉的。

这张表还能顺手回答另一个问题：哪些组件在你的小语种上根本没有语言包。有几个组件的语言包只覆盖十几门主流语言，你要开的市场不在里面，那这个组件在这个市场上永远是英文的，该考虑换掉。

## 改不到的时候，能做的三件事

遇到确实改不了的，还有三个动作。

第一是减少触发。把边缘规则和防火墙规则调松一点，让本来正常的用户不要撞上挡板。

第二是缩短暴露。给这类地址加一条快速跳转，让用户停留在那一页的时间尽量短。

第三是记录频次。哪怕改不了内容，也要知道它一个月发生多少次，这个数字是将来跟服务商谈判或者换服务商的依据。

三件事都不解决语言问题，但它们把语言问题的影响面压到了最小，这在改不动的场合是唯一能做的事。

还有第四件：把这类地址从站点地图和站内链接里摘干净。改不了那一页的内容，至少可以少往那儿送人，尤其是别让自己的内链把用户和抓取程序一起送过去。

## 那家宠物用品站后来做了什么，波兰语那边为什么一直没事

## 同一套配置，两个市场结果不一样

回到开头那个案例，最让团队困惑的是配置明明是同一套。

拆开看之后原因很直白：波兰语在服务器自带的那21门语言里，越南语不在。

波兰用户的浏览器发来波兰语偏好，服务器恰好有一份波兰语的错误文档，于是挑给了他。

越南用户发来越南语偏好，服务器手上没有这门语言的变体，按优先级表回落到英语。

两个市场看到的是两张完全不同的页面，而后台配置一个字都没差。这也是为什么这类问题几乎不可能靠读配置发现，只能靠在当地网络环境里真的点一次。

确认这个差别的办法很朴素：拿两个市场的浏览器语言设置各请求一次同一个不存在的地址，把两次的响应正文存下来对比。两份不一样就说明协商在起作用，一样就说明它没起作用。

## 定位它花了很久，因为报表里没有这一类

找到根因之前，团队查了三个方向都不对。

先怀疑是重构后的重定向没做全，查完发现重定向覆盖率有九成以上。

再怀疑是当地网络问题，找了本地同事测速，一切正常。

又怀疑是季节性波动，拉了去年同期数据，对不上。

真正的原因躺在一个没有任何报表会统计的地方：故障页按语言的分布。所有分析工具都会告诉你404发生了多少次，没有一个会告诉你这些404里有多少张是用用户看不懂的语言写的。

第四个被排除的方向是内容质量，团队一度怀疑越南语译文不行，还专门请了第二个写手复审。复审结论是译文没问题，这一步花掉两周，而问题根本不在被审的那批页面上。

## 改了三处

第一处是把那份自带的多语言错误文档接上，并且为越南语补了一份，因为原厂清单里没有。

第二处是把错误页指令的参数全部改成以斜杠开头的本地路径，之前有两条写成了带域名的完整地址，正在悄悄把404变成跳转。

第三处是给故障页加了一层按地址前缀判断的逻辑：地址里带语言目录的直接用那门语言，不带的才去读请求头。

三处改动加起来不到一天，其中最花时间的是给越南语写那几句文案，因为要请写手重新想道歉的分寸。

顺带做的第四件事是给这一页配了搜索框和三个主力品类入口，这一件跟语言无关，但它把这一页从终点变成了一个岔路口。

第四处本来在计划里但最后没做：给故障页接上按浏览历史的商品推荐。没做的理由是评估之后发现这一页的停留时间太短，推荐位来不及产生作用，投入产出不划算。

## 结果里最有意思的是那个减法

两个月后回看，越南站的品牌词表现回到了改版前的水平。

更有意思的是另一个数字：从故障页跳回首页再离开的比例明显下降，而从故障页进入搜索的比例上来了。

也就是说这一页真正的收益不在留住多少人，在于把原本会直接关掉的那批人转成了还愿意再找一下的人。

团队原本准备的那套按用户画像推荐商品的方案最后没上，因为在这一页上，能读懂和有出路这两件事已经拿走了绝大部分收益。

这是个值得记一笔的经验：故障页的优化空间很浅，浅到做完基础的两三件事之后就基本见底了，再往上投多半是浪费。

这个结论可以直接复用到别的低频页面上：凡是用户处在挫折状态、停留时间以秒计的页面，先把能读懂和有出路做到位，别急着上个性化。个性化需要用户愿意多停一会儿，而这类页面上他不会。

## 把错误页的语言收成一张能照着做的清单

## 半天能做完的第一版

第一版的目标是止血，不追求完美。

先把最近三个月的故障地址导出前一百条，跑一遍看三层来源的分布。

再把服务器配置里的错误页指令全部检查一遍，把带域名的改成本地路径。

然后给现有的那一版错误页加上搜索框和主要品类入口，不管它是什么语言。

最后在每个语言版本的地址下各请求一个不存在的页面，截图存档。半天走完这四步，最贵的那类事故基本就堵住了。

还有第五步：把故障页从站点地图里去掉，同时确认它带着不允许索引的标记。这一步十分钟，但漏掉的话前面四步的收益会被抵消一部分。

## 一周能做完的完整版

完整版要多做四件事。

按地址前缀出对应语言的错误页，每门语言一个静态文件。

把文案交给本地写手写一次，重点是道歉那一句的分寸和出路那一句的措辞。

把第三方组件的故障提示列成表，逐个确认语言参数有没有传。

把边缘节点的自定义错误响应做成一份少文字的通用版本。

四件事里最花时间的是第二件，因为它需要排期和审校；其余三件都是配置层动作，一个人一天能推完。

排期上建议把写文案那一件先启动，因为它是唯一需要等别人的动作。其余三件都可以在等文案的同时并行推，等文案到了直接填进已经搭好的文件里。

## 上线前的六项检查

照着这六条走一遍再发布。

每门语言的不存在地址返回的是404而不是跳转码。

维护期间返回的是503并且带着重试提示头。

故障页上的文字在最长的那门语言下没有把按钮挤出首屏。

语言回落的场景下没有产生返回200的伪页面。

故障页本身没有被索引，也没有出现在站点地图里。

边缘服务商那一份自定义页面已经上传并且验证过生效。六条里前两条最容易被忽略，也最贵。

验证工具上不必新增：状态码用能看响应头的请求工具，版面用真机加浏览器的设备模拟，索引状态用站长工具的地址检查。三样都是现成的，六条检查一个人一小时能跑完。

六条之外还有一条推荐动作：把这次的检查结果按语言存成一张表，下次改版之前先看它。故障页的问题几乎都是改版带出来的，而改版的时候没人会想起上一次是怎么处理的。

## 三条该让你停下来的反信号

最后给三条别做的信号。

第一，如果你的站只有一门非英语语言，而且那个市场英语普及率很高，做到第一版就够，别往下投。

第二，如果故障请求量一个月只有几十次，而且没有改版计划，这件事排不进优先级。

第三，如果为了做语言协商要引入一整套动态判断，而你的站是纯静态托管，那就用按地址前缀出静态文件那一档，别为了这一页把架构改了。

判断顺序永远是先看这一页拦的是不是交易意图，再看做到哪一档。拦的是交易意图就值得做，拦的是爬虫和垃圾请求就不值得。

还有第四条：如果这批故障请求里绝大多数来自爬虫和扫描器而不是真实用户，那么把力气花在减少这类请求上比花在美化这一页上划算。先看来源构成，再决定要不要做。

最后提一句判断顺序上的经验：这一页的投入产出曲线很陡，前面两三件事拿走绝大部分收益，之后迅速变平。所以正确的策略不是做得多完美，而是尽早做完那两三件，然后转身去做别的。

## 常见问题解答

## 多语言站的404页面，到底要不要按语言做几份？

看这批故障请求原本要去哪儿。把最近三个月的故障地址按原目标页面类型分组，如果指向商品页和品类页的占三成以上，那这一页拦的是交易意图，值得按语言做。只有一门非英语语言、且那个市场英语普及率很高的站，一版设计过的英文页加上搜索框和品类入口就够了。判断顺序是先看拦的是什么，再看做到哪一档。

## 服务器自带的多语言错误文档，直接用行不行？

可以当原型用，不建议当成品。它附带的那批文案是纯技术风格的，跟品牌调性差得很远，落款还带着软件版本号。更实际的限制是它的语言清单只有21门，阿拉伯语、越南语、泰语、印地语一门都没有。正确的用法是先用它验证语言协商在自己站上通不通，通了再把文案换成自己写的，缺的语言自己补一份文件。

## 能不能直接读浏览器发来的语言偏好来决定错误页语言？

能，但它应该是备选而不是首选。浏览器偏好说的是这个人习惯读什么，你的站分的是这批货卖去哪儿，两个坐标系经常不重合。更稳的判据是：失效的那个地址如果带着语言前缀或者国家目录，就按地址走，地址里的信息是确定的；只有地址完全不带语言信息时，才退回去读请求头。目录形式的多语言站，这条能覆盖九成故障请求。

## 把错误页指到另一个语言目录，会不会影响状态码？

会，而且这是多语言站最容易踩的一个坑。服务器的错误页指令参数如果是本地路径，服务器内部处理并保留原始状态码；如果写成带域名的完整地址，服务器会改成向客户端发一次跳转，客户端收到的就不再是404。检查办法是把配置里所有错误页指令的参数看一遍，凡是以协议开头的一律改成以斜杠开头。

## 语言回落导致的软404，怎么跟普通软404分开？

加一个筛选条件：把返回200但页面实际语言与地址前缀不一致的记录单独捞出来。这一类比普通软404难查，因为页面本身完整、有内容、样式也正常，只是语言不对。它的成因是用户请求某语言版本的某页面，那门语言没有这一页，系统悄悄回落到默认语言并返回200，于是从状态码看是一次成功访问。

## 边缘节点和防火墙挡下的页面改不了，还能做什么？

三件事。第一是减少触发，把边缘规则和防火墙规则调松，别让正常用户撞上挡板。第二是缩短暴露，给这类地址加一条快速跳转。第三是记录频次，哪怕内容改不了也要知道它一个月发生多少次，这个数字是将来换服务商的依据。如果服务商允许上传一份自定义页面，就把它做成少文字的图形版本，文字越少在多少门语言下都不算错。

## 错误页上的文案可以用机器翻译吗？

这是全站最不该用机器翻译的几页之一。它要在两三句话里同时说清出了什么事、表明责任在我们、给一条出路、还不能让人更烦躁，对措辞精度的要求比商品描述高。而道歉又恰好是各语言差别最大的言语行为之一，档位选错比不道歉更糟。句子越短，一个词的档位就越决定整句语气，这一页正好全是短句。

## 权威参考资料



## 同一个问题问十种语言给出十个结论，先别急着统一口径，其中一类改了就是改错

- URL：https://zhangwenbao.com/multilingual-ai-answer-divergence-three-types-fact-matrix.html
- 分类：小语种SEO
- 发布：2026-03-31  |  更新：2026-07-27
- 摘要：三个互相矛盾的天数里，一个是对的、一个是过期的、一个是编的，症状完全一样而修法完全相反。讲清语言边界与法律边界为什么不重合、跨语言事实矩阵怎么建，以及统一口径这个指令会把唯一正确的那一类改错。
- 关键词：AI搜索,出海SEO,多语言SEO,小语种SEO

> **TLDR**：摘要：同一个问题用德语、西语、日语各问一遍，退货期限给出三个不同的天数。多数人的第一反应是模型不稳定，得赶紧统一口径。可这三个数字里有一个是对的、有一个是过期的、还有一个是编的，三种毛病长得一模一样，修法却完全相反。这篇给出把三类分歧自动分开的事实矩阵，以及为什么统一口径这个指令会把唯一正确的那一类改错。

> 摘要：同一个问题用德语、西语、日语各问一遍，退货期限给出三个不同的天数。多数人的第一反应是模型不稳定，得赶紧统一口径。可这三个数字里有一个是对的、有一个是过期的、还有一个是编的，三种毛病长得一模一样，修法却完全相反。这篇给出把三类分歧自动分开的事实矩阵，以及为什么统一口径这个指令会把唯一正确的那一类改错。

## 能提问的语言翻了一倍，出错的面为什么也跟着翻倍？

## 今年二月那次扩语把可提问语言推到了近百门

先把这件事的量级说清楚。

今年二月中旬，谷歌一次性给AI Mode加进了53门新语言。

加完之后累计支持的语言数逼近100，覆盖的国家和地区超过200。

这是这项功能上线以来单次幅度最大的一回扩容。

官方给出的口径是这批新语言的使用者合计超过10亿人。

对做跨境的人来说，这意味着你的商品信息可以被将近100种语言问出来。

但语言数从40多跳到接近100，同时也意味着关于你的同一件事，现在有将近100个版本在被生成。过去你只需要关心那几门主力语言的答案说得对不对，现在这个检查面翻了一倍多。更棘手的是新加进来的这批语言恰恰是本地内容最稀薄的那批，也就是最容易出岔子的那批。这跟官方公布的是国家数、你要的是语言数 (https://zhangwenbao.com/ai-overviews-100-countries-six-languages-minor-language-citation.html)那篇的量纲问题一脉相承，只是这一次两个数字终于都给了。

拿去年五月的口径对照一下，落差更明显。两百多个国家、四十多门语言那份扩容公告 (https://blog.google/products-and-platforms/products/search/ai-overview-expansion-may-2025-update/)是上一个里程碑，从那时到现在语言数翻了一倍多，而国家数几乎没动。两个数字的增速差别本身就说明了问题：地理覆盖早就到顶了，接下来的扩张全发生在语言这一维上。

## 语言数一涨，同一个事实的说法数就跟着涨

把机制讲透。

模型生成答案时，依据的是当下检索到的那批文档。

不同语言检索到的文档不是同一批，这在前面几篇里已经拆过。

文档不同，答案里的具体数字自然可能不同。

所以语言每多一门，同一个事实就多一个可能被说错的机会。

这不是概率上的小幅上升，是线性增长。

而你能投入的核查资源不会跟着线性增长，多数团队的多语言质检资源这两年是持平甚至收缩的。供给增长、核查能力不变，缺口只会越拉越大。所以从今年开始，靠人力逐语言读答案这条路已经走不通了，必须换成一种能自动把问题分类的机制，只把需要人判断的那一小部分挑出来。这篇后面给的事实矩阵，做的就是这件筛选的活儿。

为什么新加进来的语言更容易出岔子，看一眼全网内容的语言分布就懂了。Common Crawl按语言统计的文档分布 (https://commoncrawl.github.io/cc-crawl-statistics/plots/languages)里，排在前十之后的语言文档量断崖式下跌，尾部几门跟头部差着好几个数量级。语言支持列表是线性延长的，可支撑这些语言的内容供给不是线性的，两者之间的缺口就是错误滋生的地方。

## 为什么这件事在纯英语站上看不见

这一节解释它为什么是语言层的问题。

只做英语的站，答案也会出错，但错的形态不一样。

那种错通常是模型理解偏了，或者引用了一个过时的页面。

它是单点的，查出来改掉就完了。

多语言场景下的错是分叉的：同一件事同时存在几个互相矛盾的版本。

而这几个版本各自都有来源支撑，各自看都不像是错的。

换句话说，单语言环境下你面对的是对错问题，多语言环境下你面对的是一致性问题，后者需要的工具完全不同。对错问题靠事实核查，一致性问题靠比对；前者需要知道正确答案，后者只需要发现两个答案不一样。这个区别很关键，因为比对可以自动化，事实核查很难自动化。把工作量从后者挪到前者，是这一层唯一能规模化的路径。

还有一层区别在发现机制上。单语言站的错答案，用户看到了会来问客服，客服反馈给内容团队，链路虽然长但存在。多语言场景下，看到错答案的是另一个国家的用户，他大概率不会用你听得懂的语言来投诉，多半直接放弃下单。反馈链路断了，问题就不会浮上来，只会体现在一条永远解释不清的转化率曲线上。

## 不一致长得一模一样，可它其实有三种？

## 第一类：各地规则确实不同的真分歧

先说最容易被误伤的那一类。

德语答案说退货期限是十四天，这是德国民法典写死的。

美国那边没有联邦层面的统一强制退货期，多数商家自己定。

两个答案都对，因为它们回答的是两个不同司法辖区的问题。

保修也一样，欧盟的法定符合性保证下限是两年。

而西班牙在2022年把本国的期限从两年延长到了三年。

于是同一门西班牙语，在西班牙给出三年、在拉美几个国家给出各自不同的年限，这几个数字全都是对的。把它们统一成一个数，等于给其中至少两个市场的用户发了错误信息，而且是有法律后果的那种错误信息。这类分歧不是缺陷，是现实世界本来的样子被如实反映了出来。俄语读者散在十几个国家 (https://zhangwenbao.com/russian-language-market-seo-decision-after-2022-geopolitical-shift.html)那篇提出的语言资产与市场资产分离，在这里以最硬的形式出现了一次：法条绑的是国家，答案绑的是语言。

真分歧的范围比多数人预估的宽。除了退货与保修，还有增值税是否含在标价里、发票的法定要素、个人数据的保存期限、七天冷静期是否适用于线上定制商品，每一项在不同法域下都有不同答案。共同点是它们全部由当地法规决定，而不是由你的经营策略决定，所以你连统一的余地都没有。

## 第二类：同一事实的新旧版本造成的伪分歧

第二类才是你真正的错。

你的德语页面去年改过一次，配送时效从五天改成三天。

法语页面没人动，还写着五天。

模型分别检索到两个页面，忠实地给出两个答案。

两个答案都有你自己的官网当来源，看着都很权威。

用户拿着法语那个答案来问客服，客服说不对，用户就困惑了。

这类分歧的特征非常明确：两个矛盾的答案指向的是同一个来源主体，只是版本不同。识别它不需要任何领域知识，只需要比对来源的最后更新时间。而它的修法也极其明确：把落后的那个版本更新掉。麻烦在于多语言站的更新几乎从来不同步，主语言改完之后其余语言排队等，队伍越排越长。机翻直接上线省下的那道审校最后拿收录和排名分期还 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)那篇算的是初次发布的账，版本漂移是这笔账的续集。

伪分歧还有一个更隐蔽的来源：同一份内容在不同渠道上的副本。官网改了，帮助中心没改；帮助中心改了，商城平台上的店铺介绍没改。这几处都是你自己的地盘，都会被当成权威来源检索到。排查时别只盯官网，把所有你能控制的对外页面列个清单，逐个核一遍数值，通常能发现两三处遗漏。

## 第三类：本地来源为零时的幻觉分歧

第三类最不好办。

某门语言里关于你这个品类根本没有本地内容。

模型被问到一个具体问题，它必须给出一个答案。

于是它拿高资源语言里的事实往这边套，或者直接填一个看着合理的数字。

填出来的东西格式完整、语气笃定，读着比真答案还顺。

这一类跟小语种AI稿里读着最顺的那一段恰恰是模型编出来的 (https://zhangwenbao.com/low-resource-language-ai-hallucination-rate-content-risk.html)那篇讲的是同一个现象。

识别它的特征是：这个答案给出了具体数值，却挂不出任何本地来源，或者挂的来源点进去根本没有这个数值。后一种情况尤其常见，来源存在、可点击、看着可信，但你去页面上搜那个数字，一次都搜不到。这是三类里唯一一类你没有任何过错的，可它对用户的伤害最直接，因为编出来的往往正是期限、费用这类会引发纠纷的字段。

各语言之间的能力差距虽然在缩小，但缩小的速度极不均匀。斯坦福人工智能指数年度报告 (https://hai.stanford.edu/ai-index/2025-ai-index-report)逐年跟踪的多语言评测数据显示，进步主要集中在使用人口多的那批语言上，长尾那一段改善有限。这意味着幻觉分歧不会随着时间自动均匀消退，它会先在大语种上消失，在小语种上继续存在很久。

## 三类的表面症状完全一致

把这一节的结论钉死。

三类分歧在报表上呈现出来的样子一模一样。

都是同一个问题在不同语言下给出了不同的值。

都能挂出看着可信的来源。

都不会触发任何告警，因为没有任何一侧是明显错误的。

而它们各自需要的动作，一个是加限定条件，一个是同步版本，一个是补本地内容。

三个动作分属三个不同的团队：法务与内容、多语言运营、市场与本地化，没有任何一个团队能独立处理完三类。这解释了为什么这个问题在组织里特别难推进——它跨了三个部门，而报表上它只有一行。把这一行拆成三行，是推动这件事最关键的一步，比任何工具选型都重要。人机分工与事实核查清单那篇 (https://zhangwenbao.com/ai-content-qa-workflow-human-ai-review-checklist.html)给的分工原则在这里要再叠一层语言维度。

症状一致还带来一个副作用：不同的人看同一份数据会得出不同的结论，而且都能自圆其说。法务看到的是合规风险，运营看到的是翻译没跟上，市场看到的是内容覆盖不足。三种解读各有道理，各自都能推动一批工作，最后三批工作互不相干地跑起来，谁也没解决全部问题。分类先行的价值，就是让三方在同一张表上对齐。

## 语言不等于国家，这句话在哪儿真正咬人？

## 西班牙语跨二十个国家，法条各不相同

拿分布最广的语言先说。

西班牙语的官方地位覆盖二十来个国家。

这些国家的消费者保护法各自独立，期限、举证责任、适用范围都不同。

一个用西班牙语提出的退货问题，正确答案取决于用户在哪个国家下单。

而问句里通常不含国家信息，模型也不会主动问。

于是它只能给一个答案，而那个答案默认了某一个国家。

默认哪个国家，取决于检索到的文档主要来自哪里，而这又取决于哪个国家的西语内容更多。结果是内容产出最多的那个市场的规则，被当成了整门语言的默认规则。这跟西语地区变体在AI问答里被怎么分 (https://zhangwenbao.com/spanish-regional-variants-ai-answer-source-divergence.html)那篇讲的检索侧分歧是同一个机制的两个后果：那边影响的是词，这边影响的是事实。

同一门语言内部的词汇差异，学界已经有量化研究。Digital Linguistic Bias in Spanish这项研究 (https://arxiv.org/abs/2602.09346)覆盖了20来个西语国家、900多个词项的地理分布，发现模型的输出明显偏向其中几个变体。词汇上的偏向和事实上的偏向是同一个成因的两个表现：谁的内容多，谁就成了默认。

## 德语只跨三个国家，法定期限照样不同

再看一个覆盖面小得多的例子。

德语的主要市场是德国、奥地利、瑞士三个。

三国里两个在欧盟，一个不在。

瑞士不受欧盟消费者权利指令约束，撤回权的规则完全另算。

所以德语答案里的十四天，对瑞士用户是不成立的。

三个国家已经能造出分歧，二十个国家可想而知。

这说明分歧的成因不是语言覆盖面大，而是语言边界与法律边界不重合，哪怕只错开一个国家也足够。把这条推到极端：即使一门语言只在一个国家使用，它的答案也可能因为州、省一级的规则差异而出错。语言这个维度天生就不是用来切法律的，用它当默认分组，出错只是早晚的事。

## 答案对语言，错在读者所在的国家

把这句话说透。

模型交付的是一段语言正确的文本。

它在语言这一层没有任何毛病，语法漂亮，措辞地道。

出问题的是这段文本隐含的适用范围。

读者读到自己的母语，天然会假定这段话是说给自己听的。

而实际上它说的是另一个国家的规则。

语言的熟悉感，在这里恰好成了误导的载体。

这是本篇最想强调的一个反直觉之处：越是把答案本地化得地道，读者对它的信任度越高，而适用范围错配造成的伤害也就越大。一个磕磕巴巴的翻译版本，读者会保持警惕；一个流畅自然的本地语言答案，读者会直接照做。质量和风险在这里是同向的，这跟大多数场景下的直觉正相反。

信任感和市场规模还不是一回事，这一点在做优先级时容易搞混。一个市场的用户可能很少，但只要那门语言是他的母语，他对答案的信任度就跟大市场用户一样高。西班牙的数字生态年度报告 (https://datareportal.com/reports/digital-2025-spain)这类国别数据能告诉你规模，但告诉不了你风险，风险是按人头算的，不是按市场大小算的。

## 用语言标签去猜辖区的失败率

顺便否掉一个常见的技术方案。

有人想用语言标签的地区段来解决这个问题。

把内容标成某个具体的地区变体，指望系统按这个匹配用户。

这个思路在传统搜索里部分有效，在AI问答这一层几乎失效。

因为问句里没有地区，而标签是页面属性不是查询属性。

标了不亏，但不能指望它替你解决适用范围的问题。

真正有效的做法是把适用范围写进正文，写成模型能摘取的句子，而不是写进机器字段。一句在德国境内订购的商品适用十四天撤回权，比任何标签都管用，因为它就在答案能引用的那段文字里。正文越本地化越好、结构化数据里却要反着写回国际格式 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)那篇讲的两层分工在这里再次生效：机器字段管归档，正文管被引用。

标签本身仍然值得配好，只是别指望它承担这个职责。RFC 5646语言标签规范 (https://www.rfc-editor.org/rfc/rfc5646)定义的语言加地区两段式写法，能让你的内容管理系统和数据分析准确地把页面归到市场上去，这对内部运营很有价值。它只是不会在一次问答里被当成过滤条件，这两件事不冲突。

## 怎么把三类分歧自动分开？

## 跨语言事实矩阵的行与列

核心工具就是一张表。

行是可判定的事实字段：退货天数、保修年限、运费门槛、是否包税。

列是你在做的语言，一门语言一列。

每个格子里放三样东西，缺一不可。

第一样是答案里给出的那个值。

第二样是这个值挂出来的来源链接。

第三样是这条来源的最后更新时间，能取到就取，取不到就标记为未知。这三样凑齐之后，三类分歧的判别就完全变成了机械操作，不需要任何人做判断。矩阵本身的规模也不大：二十个字段乘十门语言是两百格，一次抓取就能填满，之后每次重跑只需要看哪些格子的值变了。这套结构的好处是它同时是检查表和历史档案，跑三次之后就能看出哪些字段一直在飘。

行的挑选有个实用原则：只放那些用户真的会问的字段。矩阵不是产品数据库的镜像，它是问答风险的清单。判断标准很朴素——过去半年客服工单里出现过这个字段吗，出现过就进表，从没人问过就先不进。按这个筛，多数品类的行数会落在二十上下，正好是一屏能看完的规模。

## 每格必须放的那三样东西

解释为什么是这三样。

只有值，你能发现不一致，但分不出是哪一类。

加上来源，你能区分出有据可依和凭空生成。

再加上更新时间，你能区分出真分歧和版本漂移。

三样凑齐，三类才互相排他。

少任何一样，就会有两类混在一起分不开。

实践中最容易被省掉的是第三样，因为更新时间不好取，很多页面根本不给。取不到的时候不要留空，标记成未知，让它作为一个独立的状态存在。未知本身是有信息量的：一个连更新时间都拿不到的来源，可信度天然低一档。把未知混进空值里，你会在分析时把它们当成缺失数据丢掉，而那批恰恰是最该关注的。

格子里其实还可以放第四样：这一轮抓取的日期。有了它，矩阵就从快照变成了时间序列，你能看出某个字段是长期不一致还是最近才开始飘。长期不一致多半是真分歧，最近才飘的多半是有人改了什么。这一列成本为零，却能省掉大量的回溯排查，建议从第一次跑就加上。

## 三条判别规则

规则可以直接写成代码。

规则一，值不同、各自有本地来源、来源指向不同的主体，判为真分歧。

规则二，值不同、来源指向同一个主体、更新时间不同，判为伪分歧。

规则三，值不同、某一侧挂不出来源或者来源里搜不到该值，判为幻觉分歧。

三条规则覆盖不了的落进待定，交给人看。

实测下来待定的比例通常在一成到两成之间。

规则三里那个来源里搜不到该值的检查，是整套流程里性价比最高的一步：抓一遍来源页面的正文，在里面搜一下那个数字，搜不到就是红灯。这个检查完全自动化，成本接近零，却能抓出绝大多数编造。做过的人普遍反馈第一次跑完会有点惊讶，因为红灯的数量比预期多。共识层那几个信号 (https://zhangwenbao.com/seo-consensus-layer-ai-search.html)要成立，前提是那些来源真的说过那句话，这一步就是在验证这个前提。

有人会想直接让模型来做这个分类，省掉规则。不建议，How Reliable is Multilingual LLM-as-a-Judge这项研究 (https://aclanthology.org/2025.findings-emnlp.587/)发现模型担任评判者时在不同语言上的判断并不一致，你用它来判跨语言的一致性，等于让一个本身带语言偏差的裁判去裁语言偏差。三条硬规则虽然笨，但它对所有语言一视同仁。

## 矩阵跑一遍要多久

把成本说清楚。

字段清单一次性整理，半天。

问题设计与本地化重写，每门语言一小时。

抓取与填表，自动化之后一次两三个小时。

判别规则跑完，剩下的待定项人工看，一门语言半小时。

首次搭建大约一周，之后每季度重跑一天。

跟前一篇讲的可见度监控相比，这套东西的频率可以低很多，因为事实字段的变化远慢于可见度指标。法条修订以年为单位，你自己的政策调整也不会每周变。真正需要提高频率的时机只有两个：你刚改过某个政策，以及某个市场刚有法规变动。这两个时机之外，季度节奏完全够用。跨语言可见度监控那篇 (https://zhangwenbao.com/cross-lingual-brand-mention-monitoring-key-baseline.html)给的月度节奏不用照搬到这里。

还有一笔容易被低估的时间开销：把字段清单从各个部门收集齐。法务手上有合规字段，客服手上有高频问题，运营手上有政策变更历史，三边的清单合并起来才完整。这个协调过程往往比技术实现更耗时，建议在项目启动时就把它当成第一个里程碑，而不是等到要填表了才去要数据。

## 真分歧该修的不是口径，那该修什么？

## 统一口径会把对的那一类改错

这是全文的第二个核心结论。

一旦你把三类混着报上去，得到的指令几乎必然是统一口径。

这个指令对伪分歧是对的，对幻觉分歧无效，对真分歧是有害的。

因为真分歧的三个数字本来就该不同。

把它们统一成一个，等于主动制造一批错误信息。

而且这批错误信息是你亲手写进官网的，法律责任跑不掉。

更麻烦的是统一之后一切看起来都变好了：报表上不一致的行数归零，汇报时数字很漂亮。问题被藏进了一个没人再检查的地方，直到某个市场的用户拿着你的官网页面去投诉。指标一旦可以通过做坏事来改善，它就会被通过做坏事来改善，这条规律在任何组织里都成立。所以拆成三行不只是为了准确，也是为了不给团队一条走捷径的路。

## 适用范围要写在能被摘取的位置

真分歧的正确修法在这里。

不改数值，改的是数值旁边的限定条件。

把适用的国家、适用的条件写成一个完整的短句。

放在数值出现的那一句里面，不要放在页脚，不要放在另一段。

模型摘取时是按段落取的，跨段的限定条件会被丢掉。

写成十四天这三个字的前后紧挨着国家名，才有可能一起被摘走。

这条要求听起来简单，实际执行时最大的阻力来自文案：加了限定条件的句子读起来啰嗦，会被改回去。解决办法是把它写进内容规范并说明原因，否则每次改版都会被优化掉一次。可以给文案一个替代方案：用一个短表格代替长句子，表格的行是国家、列是期限，同样能被完整摘取，读起来还更清爽。把旧内容改造成AI可信来源那篇 (https://zhangwenbao.com/revise-old-content-for-aeo-ai-search-optimization.html)给的改写清单里，这一项值得单独列出来。

数值本身的写法也影响能不能被正确摘取。日期、金额、期限这些量在不同地区有不同的书写惯例，Unicode地区数据标记语言规范 (https://www.unicode.org/reports/tr35/tr35.html)把这些格式按地区做了完整定义。正文里按当地惯例写，机器字段里按标准格式写，两边都齐了，摘取时才不会因为格式歧义而取错数量级。

## 条件句在不同语序里的位置

这里有一个语言层的坑。

限定条件在中文和英语里习惯放句首或句尾。

德语这类框型结构的语言，主要动词会被甩到从句末尾。

日语和韩语的谓语与否定成分都压在句子最后。

如果答案被截断，这些语言里被砍掉的恰好是最关键的成分。

所以同一条限定条件，在不同语言里该放的位置并不相同。

可靠的做法是让本地文案在保证语义完整的前提下把限定条件尽量前置，并且用一个完整的短句承载它，不要写成从句。短句无论怎么截断都能保住主干，从句一截就废。这条经验跟一段话能不能被摘去当答案跟这门语言把谓语放在哪儿有关 (https://zhangwenbao.com/ai-overviews-100-countries-six-languages-minor-language-citation.html)那篇的首句自足性检查是同一套方法，只是这次要检查的不是首句，是带限定条件的那一句。

语序这件事有现成的类型学数据可查。世界语言结构地图集里的基本语序分布 (https://wals.info/chapter/81)把各语言按主谓宾的排列方式分了类，你只要查一下目标语言落在哪一类，就知道截断风险高不高。谓语在后的语言要格外小心，那类语言里句子的后三分之一往往承载着成立与否的关键成分。

## 伪分歧为什么最容易越积越多？

## 多语言站的更新永远不同步

先讲成因。

内容改动总是从主语言开始。

改完之后其余语言进翻译队列，队列有排期。

紧急的插队，不紧急的往后放，往后放的经常就没了下文。

一次两次不明显，三年下来次要语言能落后几十处。

而这些落后处平时完全看不见，因为没人会把两种语言的页面并排读。

过去这种落后只影响那些直接访问该语言页面的用户，规模有限；现在它会被模型当成有效来源检索出来，影响面扩大了不止一个数量级。换句话说，多语言站的版本债在这一层被重新定价了，以前的低息负债变成了高息负债。这是这两年多语言运营里最值得重新算的一笔账，而多数团队还没意识到利率变了。

## 谁负责第二语言的版本对齐

组织问题往往比技术问题难。

主语言的内容有明确的负责人。

翻译有供应商或者本地团队。

但版本对齐这件事通常没有人负责。

它不属于内容团队，因为内容已经交付；也不属于翻译方，因为没人下单。

结果是它落在缝里，谁都不管，直到出事。

解法不复杂但需要有人拍板：把版本对齐做成一个定期任务，绑在内容团队的交付定义里。具体说就是主语言内容改动的工单，只有在所有目标语言同步完成之后才算关闭。这个改动会让工单关闭得慢一些，看起来效率下降，实际是把隐性负债显性化了。愿不愿意接受这个显性化，基本决定了这个问题能不能解决。

还有一个更轻的过渡方案：不改工单流程，只加一条发布前的检查项。主语言内容发布时，系统自动在其余语言的对应页面上打一个待复核标记，标记不清除不影响上线，但会出现在每周的清单里。这个做法阻力小得多，因为它不卡任何人的交付，只是把欠账记在明面上。

## 三个能自动发现落后版本的信号

给三个不用人工比对的办法。

第一个是页面最后修改时间的跨语言差值，差得越久越可疑。

第二个是关键数值的跨语言比对，也就是前面那张矩阵。

第三个是页面长度的跨语言比值，长度突然偏离历史比值说明有一侧改过。

三个信号都很粗糙，但都能自动跑。

它们的作用不是判定，是把人的注意力引到该看的那几页上。

第三个信号最容易被忽略，可它对那种只加了一段话的改动特别敏感，而只加一段话恰恰是最常见的政策更新形态。建立这个信号需要先攒几个月的历史比值当基准，所以越早开始越好。三个信号一起跑，覆盖面能到八九成，剩下的靠季度矩阵兜底，这套组合在成本和效果之间比较平衡。

三个信号之外还可以加一个更直接的：给关键数值加上统一的标记，让它们在页面源码里可以被程序精确定位。这样跨语言比对就不再依赖文本解析，而是直接读结构化的字段。改造成本视系统而定，但一旦做完，前面那三个粗糙信号可以全部退休，误报率也会降到接近零。

## 幻觉分歧不是你的错，为什么还要你来修？

## 池子空着的时候模型必须填

先说清楚责任归属。

某门语言里没有关于你这个品类的本地内容。

用户问了一个具体问题，系统必须返回点什么。

返回不知道在产品体验上是不可接受的，所以它会尽量给答案。

给不出有据可依的答案时，它会用别的语言的事实来近似。

近似的结果有时对，有时错，而错的时候没有任何标记。

这个机制不是缺陷，是产品设计上的取舍，而且这个取舍短期内不会变，因为返回不知道的体验代价太高。指望它自己变好，等于指望产品团队接受一个更差的体验指标。所以对做内容的人来说，正确的心态是把它当成一个稳定存在的环境条件，然后问一句：在这个条件下，我能改变的是什么。答案是池子里的东西，那是唯一在你手上的变量。

## 你放进去的第一条本地来源

这是这一类里最划算的动作。

池子空的时候，第一条进去的内容影响力极大。

它不是众多候选中的一个，它可能是唯一一个。

一篇写清楚本地规则的页面，能直接改掉那门语言下的答案。

投入是一篇内容，产出是一个市场的答案正确性。

这个杠杆比在拥挤语言里做同样的事高出一两个数量级。

而且这类内容不需要写得多华丽，它需要的是把具体数值、适用条件、生效日期写清楚，格式规整到能被机器读懂。信息密度比文采重要得多。小语种问答长尾那篇 (https://zhangwenbao.com/minor-language-qa-long-tail-content-value-ai-era.html)算过这笔供给侧的账，这里可以再加一条：在幻觉分歧高发的字段上做内容，收益比在普通话题上做内容高，因为你不只是多了一个候选，你是在替换掉一个错误答案。

写这类内容还有一个容易被忽略的收益：它同时是你自己团队的事实来源。多语言站里经常出现的情况是没人说得清某个市场的规则到底是什么，各处写法不一是因为源头就没有唯一版本。写一篇本地语言的规则说明，等于顺手把内部口径也统一了，这份收益跟外部曝光无关，但它才是版本漂移的根治办法。

## 跟低资源语言幻觉那一层的分工

把两篇的边界划清。

幻觉率那一篇讲的是模型在低资源语言下整体的编造倾向。

它关心的是这门语言下所有内容的可靠性。

本篇关心的是同一件事在多门语言下的一致性。

前者是纵向的，看一门语言深不深；后者是横向的，看多门语言齐不齐。

两者会在同一批数据里同时出现，但要分开处理。

操作上的区别是：纵向问题靠提升那门语言的整体内容质量解决，横向问题靠比对和对齐解决，后者不需要你成为那门语言的专家。这一点很重要，因为它意味着横向这套活儿可以由不懂那门语言的人来做，只要有矩阵和规则。能不能由不懂语言的人来做，直接决定了这件事能不能在你的团队里规模化。

## 哪些事实字段必须逐语言核，哪些不用？

## 可判定字段与不可判定字段

先划一条线。

可判定字段是那些有唯一正确答案的：天数、金额、年限、编号。

不可判定字段是那些本来就见仁见智的：好不好用、适不适合新手。

矩阵只处理可判定字段，不可判定的不进表。

原因很实际：不可判定字段没法自动比对，进表只会制造噪声。

而且它们出错的后果通常也小得多。

划这条线的标准可以简化成一句话：如果两个人拿着同一份资料会得出同一个值，它就是可判定的。按这个标准过一遍，你会发现真正需要跨语言核对的字段比想象中少，通常一个品类下二三十个就到头了。数量少是好事，它让这件事从一个无边界的质检工作，变成了一张有限的清单。有限的清单才有可能被真正执行。

还有一类介于两者之间的字段值得单独说：那些有唯一答案但答案会随时间变的，比如某项认证的有效期、某个促销的截止日。它们是可判定的，但判定结果有保质期。建议进表但单独标记，比对时不看值是否一致，只看是否已经过期，两种检查的逻辑完全不同。

## 必核清单：期限、金额、资质、安全

给一份可以直接抄的清单。

期限类：退货期、保修期、配送时效、订单取消窗口。

金额类：运费门槛、关税与增值税口径、退货运费由谁承担。

资质类：认证编号、许可证、适用标准的版本号。

安全类：使用限制、年龄限制、材料与成分的合规声明。

这四类的共同点是错了会引发投诉、退款甚至监管问询。

四类里资质类最容易被漏掉，因为它看起来最静态，一旦标注就没人再看。可标准是会改版的，认证是会过期的，而过期的认证编号在答案里被引用出来，比没有编号更糟。建议给资质类字段单独加一个有效期列，到期前自动提醒。这一项跟AI投毒那篇 (https://zhangwenbao.com/geo-ai-poisoning-315-deep-analysis.html)讲的防御思路相通：你自己发出去的过期信息，效果跟被别人投毒差不多。

四类之外还有一类值得加进去：跟人身安全或者健康相关的说明，哪怕它不属于强制合规范畴。这类内容一旦在某门语言里被说错，后果不是退款能解决的，而且它往往是模型最爱自由发挥的地方，因为公开资料里同类表述很多、口径又不统一。宁可把清单加长两行，也别在这一类上留空白。

## 可以只维护一份的字段

反过来说哪些不用逐语言核。

物理属性：尺寸、重量、材质、功率。

技术参数：接口类型、协议版本、兼容型号。

这些跨国一致，一份数据多语言复用完全没问题。

唯一要注意的是单位换算和数字格式，那属于呈现层不属于事实层。

把这批字段从必核清单里剔出去，工作量能减掉一大半。

要小心的是那些看着像物理属性、实际带着地区限制的字段，电源电压是最典型的一个。同一款音箱在欧洲市场是二百三十伏、在北美是一百二十伏，参数表上它长得跟别的物理参数一模一样，可它是随市场变的。这类混进物理属性堆里的地区相关字段，是必核清单里最常见的漏网之鱼，整理清单时值得专门找一遍。

单位与格式虽然属于呈现层，但它出错的后果一点不轻。Unicode地区数据规范 (https://www.unicode.org/reports/tr35/tr35.html)里定义的小数点与千位分隔符在欧洲和北美是相反的，同一串数字在两种惯例下相差一千倍。这类错误在人工阅读时很容易发现，在机器摘取时反而容易被原样搬运，所以呈现层的规范化不能省。

## 乐器与音响这类品类的特殊项

拿保哥今年接触的一个做乐器与音响配件的客户举例。

他们的必核清单里有两项是别的品类没有的。

一项是电源电压与插头制式，跨市场必须分别标。

另一项是特定木材的进出口管制，涉及濒危物种公约的品种需要证明文件。

第二项在不同国家的执行细节不同，答案给错会直接导致清关失败。

他们第一次跑矩阵时，这一项在三门语言下给出了三个互相矛盾的说法。

三个说法里一个是对的、一个引用了已经修订过的旧版本、还有一个完全找不到来源，正好三类各占一个，是这套分类法最干净的一次实证。处理方式也完全不同：真分歧那一条加了国家限定，伪分歧那一条更新了德语页面，幻觉分歧那一条则是新写了一篇本地语言的说明。三个动作分属三个人，花了三周，之后那一项再没出过问题。

这个客户后来还加了第三项：不同市场对特定电池与电子元件的运输限制。带锂电池的无线设备在跨境寄送时各国规则不同，这一项在他们的答案里也曾经给出过互相矛盾的说法。共同点是这三项都不是产品本身的属性，而是产品跨过某条边界时才产生的属性，这类字段最容易在参数表里被当成静态数据处理。

## 报给老板的时候怎么讲才不会拿到错指令？

## 一个数字会引出统一口径

再把汇报这一环说透。

报一条不一致率，管理者的第一反应是把它降下去。

降它最快的办法就是统一口径。

而统一口径会伤害真分歧那一类。

所以这个指令是指标形态直接诱导出来的，不是管理者的判断失误。

换句话说，是你的报表设计出的这个错。

这一条可以推广到所有跨部门汇报：当一个指标只有一种降低方式，而那种方式有害时，问题出在指标不在人。检查办法很简单——自己想三种能让这个数字变好看的做法，如果其中有一种是有害的而且是最省事的，那这个指标就不能用。这个自检花五分钟，能挡下大半年的返工。

## 三个数字会引出三种动作

正确的形态在这里。

把不一致拆成真分歧、伪分歧、幻觉分歧三行。

真分歧那一行报的不是数量，是有多少条已经加了适用范围。

伪分歧那一行报的是版本落后的页面数和平均落后天数。

幻觉分歧那一行报的是有多少个字段在某门语言下完全没有本地来源。

三行三个动作，各自有明确的负责人和明确的完成定义。

关键在于真分歧那一行的数字应该越大越好，因为它统计的是覆盖度而不是缺陷数，这一点必须在报表上写清楚。不写清楚的话，读表的人会本能地希望所有数字都往下走，于是又绕回了统一口径。指标的方向性在跨部门汇报里是最容易被误读的一件事，宁可在表头上多写一行说明，也别指望大家默认理解。

三行之外建议再加一行趋势：本季度新出现的不一致条数减去本季度解决的条数。这个净值是正的说明欠账在扩大，是负的说明在收敛。管理者对存量数字往往不敏感，对方向却很敏感，一个持续为正的净值比任何绝对数字都更能推动资源投入。

## 汇报模板与责任边界

给一个可以照抄的结构。

第一屏：三行分类计数，各自配一句这行代表什么。

第二屏：按语言展开，看哪几门语言问题集中。

第三屏：本季度处理了哪些，剩下哪些，卡在谁那里。

三屏之外的所有明细放附件，不进正文。

责任边界写在第三屏，具体到人不到部门。

另外建议在模板里固定一句话：这套数据不能回答用户是否因此产生了投诉，那需要另一套客服侧的数据来对照。把边界写在明面上，可以避免这份报表被拿去解释它解释不了的事情。跨语言事实一致性是一个内容质量指标，不是一个业务结果指标，两者之间隔着相当长的链路。这一点前一篇讲监控时也强调过，在这里同样成立。

## 这套做法在什么情况下不值得做

## 什么时候可以先不做

坦白讲它不是所有人都需要。

只做一个国家、一门语言的站，完全不需要。

两门语言且都在同一个法域内的，收益也有限。

品类本身没有可判定字段的，比如纯内容型站点，做了也没什么可比的。

真正需要的是三门以上语言、跨多个法域、且商品带期限与合规属性的。

这个条件筛下来，多数跨境电商和独立站是符合的，纯内容站多半不符合。

还有一种情况是你还在很早期，内容量本身就不够，这时候更该做的是先把主力语言的内容写扎实。矩阵检查的是一致性，而一致性只有在有东西可比的时候才有意义。三门语言各只有五个页面，比出来的不一致更多反映的是覆盖不全而不是版本漂移。先积累再对齐，顺序反了会浪费很多力气。

## 会失效的两种情形

最后说两种边界。

第一种是你的商品信息本身在各市场就没有统一的真值。

比如价格随促销实时变动，那这个字段不适合进矩阵。

矩阵要的是相对稳定的事实，高频变动的字段用别的机制管。

第二种是那门语言的答案压根没有引用你，全部来自第三方。

这时候你能改的只有第三方页面上的信息，路径完全不同。

第二种情形其实很常见，尤其在你还没进入某个市场的时候，那里关于你的一切说法都来自评测站、论坛和竞品对比页。处理它需要的是站外内容治理那一套，跟本篇讲的站内对齐是两条线。判断自己落在哪条线上，看矩阵里来源那一列有多少指向你自己的域名——低于一半，就该先做站外那条线。

## 常见问题解答

## 三类分歧里，哪一类最该优先处理？

按风险排是幻觉分歧优先，按成本效益排是伪分歧优先。幻觉分歧给出的是完全编造的具体数值，一旦涉及期限或者合规，后果最重；但它的修法是新写本地内容，周期长。伪分歧只需要更新已有页面，一两周就能清一批，而且清完立竿见影。实际排期建议两条并行：伪分歧当季清完，幻觉分歧按市场重要性排队慢慢补，真分歧那一类作为内容规范嵌进日常流程。

## 没有本地母语者，这套矩阵还能跑吗？

能跑大部分。填表、比对、三条判别规则都不需要懂那门语言，因为比的是数值不是文本。需要母语者的只有两个环节：本地化重写测试问题，以及处理判别规则覆盖不了的待定项。前者一门语言一小时，后者一门语言每季度半小时，找兼职或者当地合作方都能解决。这也是横向一致性检查比纵向质量提升更容易规模化的原因。

## 真分歧那一类加了限定条件，会不会影响可读性和转化？

会有轻微影响，但可以设计。最省事的形态是用一张小表格代替长句子，行是国家、列是期限，既完整又清爽，还比长句更容易被完整摘取。要避免的是把限定条件塞进括号或者脚注，那两个位置在摘取时被丢掉的概率最高。至于转化，实测下来把适用范围写清楚通常不降反升，因为跨境用户对规则不清晰这件事本来就很敏感。

## 矩阵里的值应该从答案里取还是从自己的页面上取？

两边都要取，而且要分成两列。从答案里取的是外界看到的版本，从自己页面上取的是你以为的版本，两者的差值本身就是一个重要信号。只取答案，你不知道是自己写错了还是被误读了；只取页面，你不知道外界到底看到了什么。两列并排，问题的定位速度会快很多，多加一列的成本几乎为零。

## 如果两个市场的规则确实不同，但用户是同一批人怎么办？

这种情况在跨境场景里不少见，比如住在一国、下单寄往另一国。处理办法是把限定条件从国家改成更准确的触发条件，通常是收货地址所在国或者下单时的配送目的地。写成收货地址在某国的订单适用某规则，比写成某国用户准确得多，也更容易被模型正确摘取。这一改还顺带解决了语言与国家不重合带来的一部分问题。

## 模型换代之后，之前跑出来的矩阵还作数吗？

结论作数，具体数值要重跑。三类分歧的分类框架跟模型无关，它反映的是现实世界和你自己内容的状态。但每一格的值来自当次生成，换代之后可能全变，所以模型有大版本更新时建议加跑一次。好消息是重跑的边际成本很低，流程和规则都是现成的，主要开销是抓取时间。这跟可见度类指标不同，那一类换代之后连基线都要重算。

## 这套东西跟传统的多语言内容质检有什么区别？

传统质检检查的是每一份内容自身对不对、通不通顺，是纵向的、逐份的。这套矩阵检查的是多份内容之间一不一致，是横向的、成组的。两者抓到的问题几乎不重叠：一份翻译得很漂亮、语法完美的页面，完全可能带着一个三年前的数值。质检那一关它能过，横向比对这一关它过不了。所以这套东西不是替代质检，是在质检之外补一个维度。

## 权威参考资料



## 品牌名在俄语里是西里尔、在日语里是片假名，你那个数提及次数的脚本一个都认不出来

- URL：https://zhangwenbao.com/cross-lingual-brand-mention-monitoring-key-baseline.html
- 分类：小语种SEO
- 发布：2026-02-10  |  更新：2026-07-27
- 摘要：品牌名到了俄语是西里尔转写、到了芬兰语后面挂着格尾，字符串匹配一个都认不出，于是零提及和零匹配在报表里长得一模一样。讲清别名表怎么建、不同语言的百分比为什么不能直接比、基线归一那一步为什么省不掉。
- 关键词：GEO优化,AI搜索,多语言SEO,小语种SEO

> **TLDR**：摘要：要知道自己的品牌在AI答案里被提到过多少次，得先有一个能拿来数的字符串。可品牌名到了俄语是西里尔转写、到了日语是片假名、到了芬兰语后面还挂着格尾，你脚本里那个正则一个都匹配不上。这篇讲清跨语言监控为什么第一步就塌、别名表该怎么建、不同语言之间的百分比为什么不能直接比，以及基线归一那一步省不掉。

> 摘要：要知道自己的品牌在AI答案里被提到过多少次，得先有一个能拿来数的字符串。可品牌名到了俄语是西里尔转写、到了日语是片假名、到了芬兰语后面还挂着格尾，你脚本里那个正则一个都匹配不上。这篇讲清跨语言监控为什么第一步就塌、别名表该怎么建、不同语言之间的百分比为什么不能直接比，以及基线归一那一步省不掉。

## 跨语言数提及，为什么第一步就已经错了？

## 字符串匹配藏着一个没人说破的前提

先把这套监控的实际做法摊开看。

绝大多数品牌提及监控，底层动作只有一个：在文本里找字符串。

拿品牌名当关键词，扫一遍答案，命中就计一次。

这个动作在单一语言环境里工作得很好，可靠、便宜、可复现。

它能工作，是因为有一个前提在默默成立：品牌名在这批文本里始终是同一串字符。

而这个前提，只在你和你的用户共用一套书写系统、一套语法的时候才成立。

一旦把监控范围扩到十种语言，这个前提就整块塌掉了，而塌掉的过程没有任何报错。脚本照跑，报表照出，数字照样一列一列排得整整齐齐，只是那些数字不再代表你以为的东西。这是工程上最难办的一类故障：不是崩溃，是静默地返回一个格式正确的错值。跟关键词工具返回的那个零是数据缺口不是需求缺口 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)那篇讲的是同一类陷阱，只不过这次错的不是工具，是你自己写的那行正则。

为什么单语环境下没人发现这个前提，因为它从来没有被违反过。一个只做本国市场的团队，看到的所有文本都是同一套书写系统写的，品牌名永远是那一串字符，正则永远命中。前提被满足了十年，它就从假设变成了常识，从常识变成了没人再提起的空气。等到扩语言的那天，没有一份文档记录过这个假设存在，自然也没人想到要检查它。

## 品牌名在十种语言里不是一个字符串

具体到底会变成什么样，举几个公开可查的例子。

宜家在俄语里通行的写法是西里尔转写，跟拉丁原名一个字母都不重合。

耐克在日语里的常见写法是片假名，同样一个拉丁字母都没有。

这些不是网友的自发音译，而是品牌方自己在当地使用的官方写法。

再往下，同一门语言里往往还并存着拉丁原名和本地转写两套。

用户提问时用哪一套，取决于他的输入法、他的年龄、他是在哪儿第一次见到这个牌子的。

更麻烦的是模型在生成答案时会自己做选择，而它的选择不一定跟你的官方写法一致。用日语提问，答案里出现的可能是片假名，也可能是拉丁原名，还可能两种混着来——前半句用片假名当主语，后半句引用官网标题时又切回拉丁。这三种情况在同一批答案里同时出现是常态，不是异常。品牌名叫什么不由你定、由当地用户的输入法定 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)那篇讲的是搜索框里的情形，到了AI答案这一层，多了一个会自己决定怎么写的生成方。

转写这件事本身是有规则的，不是随口音译。Unicode地区数据规范里的音译章节 (https://www.unicode.org/reports/tr35/tr35-general.html)定义了成套的跨书写系统转换规则，能把拉丁字母按发音映射到西里尔、希腊、天城文等多套系统。拿它批量生成候选形态，再让母语者删掉不通行的那几个，比从零开始想快得多，也不会漏掉冷门但合法的写法。

## 零提及和零匹配在报表里长得一模一样

这是整篇文章的第一个核心结论。

报表里某门语言那一格是零。

它可能意味着这门语言的答案里确实一次都没提到你。

也可能意味着提到了很多次，只是你的正则认不出那些形态。

两种情况在数字上完全一致，在业务含义上南辕北辙。

前者要你去做内容，后者要你去修脚本，一个是几个月的投入，一个是一个下午的活儿。

而在实际工作里，团队看到零的第一反应几乎永远是前者，因为那个解释更符合直觉，也更符合大家对小语种市场的既有印象。于是预算批下去，内容做起来，三个月后数字还是零，才有人回头去看脚本。这个坑跟排名靠后和根本不在场在后台是同一个零 (https://zhangwenbao.com/untranslated-invisible-ai-retrieval-translated-content-tradeoff.html)那篇讲的结构一样，但位置不同：那一篇的零来自候选池，这一篇的零来自你自己的测量装置。

工程上有一个很省事的改法：给每次抓取多记一个标志位，表示这批答案里有没有出现任何一个已知的品类词。品类词都没出现，说明这批答案压根不在讨论你的行业，零是合理的；品类词出现了很多次而品牌一次没出现，那才是需要警觉的零。一个布尔值，就把两种零分开了大半。

## 这跟内容侧的不在候选池不是同一层

把两层分清楚很重要，否则会归错因。

内容侧的零，是你的页面根本没进检索器的候选集合。

测量侧的零，是页面进去了、答案里也提到了，只是你没数出来。

两者可以同时存在，而且经常同时存在。

排查顺序应该是先测量侧再内容侧，因为测量侧便宜得多。

修一遍正则和别名表，成本大概是半天；补一门语言的内容，成本是一个季度起。

判断该先查哪一层有个很快的办法：随手挑五条那门语言的答案，人眼读一遍，看看里面到底有没有你的品牌。人眼不做字符串匹配，它做的是语义识别，一眼就能看出片假名那一串是不是你。五条读完，你就知道零是真零还是假零。这个检查的成本是十分钟，可它极少被执行，因为一旦有了自动化报表，人就不再愿意用眼睛看原始数据了。

## 品牌名到底会以多少种形态出现？

## 转写：西里尔、片假名与其他书写系统

先说跨书写系统这一类，它最显眼也最容易补。

俄语、乌克兰语、保加利亚语、塞尔维亚语会把品牌名写成西里尔。

日语用片假名，韩语用谚文，希腊语用希腊字母。

阿拉伯语和希伯来语的转写还要处理元音省略，同一个名字能写出好几种。

这些形态之间不存在字符级的对应关系，靠正则的模糊匹配抓不到。

唯一可靠的办法是把它们逐个列进别名表，当作独立的目标字符串。

塞尔维亚语这类同时使用两套字母的语言更极端，同一门语言里就有两个合法写法，取决于内容发在哪个平台上。保加利亚语和塞尔维亚语用哪套字母写商品名比写了什么更决定谁能搜到 (https://zhangwenbao.com/bulgarian-serbian-seo-cyrillic-latin-dual-script.html)那篇讨论的是收录侧，到了监控这一层，它变成了一个更朴素的问题：你的别名表里这门语言要占两行还是一行。答案是两行，而且这两行的计数要能合并也能拆开看。

各语言到底通行哪种转写，公开数据里能查到一部分。Unicode CLDR项目 (https://cldr.unicode.org/)维护的各地区数据里包含了大量外来名称的本地写法惯例，虽然它不会收录你的品牌，但它能告诉你这门语言处理外来专名的一般倾向：是倾向转写还是倾向保留原文，这个倾向决定了你的别名表里哪一行该排在前面。

## 屈折：格尾、所有格与后置冠词

这一类比转写更隐蔽，因为它长得跟原名很像。

芬兰语会把品牌名当普通名词变格，后面直接挂上格尾。

土耳其语用撇号把后缀跟专有名词隔开，撇号后面那串会变。

俄语的品牌名如果被当成可变格词处理，六个格全都有不同的形态。

罗马尼亚语和保加利亚语的定冠词是后置的，直接粘在词尾。

这些形态里前半截还是你的品牌名，后半截多了几个字母，精确匹配全部失败。

处理办法是把匹配从等于改成以某个词干开头，但这一改又会引入新的问题：品牌名短的时候会误伤大量普通词。三个字母的品牌名在芬兰语里做前缀匹配，能匹配出一堆完全不相干的东西。屈折语站的锚文本报告里精确匹配那一栏的数字是假的 (https://zhangwenbao.com/minor-language-internal-link-anchor-inflection-variants.html)那篇给过同一个两难，当时的解法是把精确匹配的需求整体挪到别的位置去；在监控这里挪不了，只能靠人工审一遍前缀匹配的结果，把误伤的踢掉。

要判断某门语言会把专有名词变到什么程度，翻一遍公开树库最直接。Universal Dependencies的芬兰语数据集 (https://universaldependencies.org/fi/index.html)里专有名词同样带完整的格标注，你能直接看到一个外来名字在真实语料里出现过多少种形态。列出现频次最高的那五六个，别名表就够用了，剩下的长尾形态出现概率低到不值得维护。

## 正字法：变音符号、连字符与大小写

第三类是同一套字母内部的小差别。

带变音符号的品牌名，用户经常打成不带符号的版本。

德语的元音变音有一套标准的退化写法，两种都合法。

连字符有没有、空格断在哪儿，各语言的排版习惯不同。

大小写在西里尔和拉丁之间也不完全对应，全大写的品牌名尤其容易出岔子。

这类差别的数量不多，但它们出现的频率非常高，漏掉的话计数会少一大截。

技术上有个现成的兜底手段：先做Unicode归一化，再做大小写折叠，然后再匹配。带重音的字母在编码上有组合与预组合两种形态，肉眼一模一样而字节不同，不归一化就会漏。String.prototype.normalize这个标准方法 (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/normalize)是最省事的入口，把所有待比对的文本先过一遍，能把这一整类问题消掉八成。剩下两成是排版习惯，只能靠列表穷举。

大小写折叠这一步在跨书写系统时格外容易出错，因为不同系统的大小写映射规则并不一致，个别字母在折叠之后会跟另一个字母重合。UAX #29文本分段规范 (https://www.unicode.org/reports/tr29/)定义的词边界规则可以配合着用，先按标准切出词，再逐词折叠比对，比在整段文本上做正则安全得多。

## 误拼与本地化改名

最后一类是最容易被漏掉的。

用户会打错，而且打错的方式在每门语言里是有规律的。

规律来自键盘布局和母语的拼写直觉，不是随机的。

把常见错拼收进别名表，通常能多捞回百分之几的提及。

另一种情况是品牌在某个市场用了完全不同的名字。

这类改名往往是历史原因造成的，公司内部知道的人还不多。

还有一种更隐蔽的形态：模型在生成答案时把品牌名意译了。如果你的品牌名本身是一个有含义的普通词，模型在某些语言里会把它翻译过去而不是转写，于是答案里出现的是那个词的本地对应词。这种情况下用户其实看到了你，可你的监控完全不知道。要发现它，只能靠人工读原始答案，或者反过来搜一遍你的品类词看看有没有眼熟的表述。

## 主键该怎么建，别名表长什么样？

## 每条记录必须带上匹配到的那个形态

这是本文最实用的一条工程建议。

监控记录里通常只存三样：语言、有没有提及、来源链接。

建议再加一列，存实际匹配到的那个字符串。

这一列存在，你才能回答零到底是哪种零。

这一列存在，你才能发现某门语言里有一种形态从来没被匹配到过。

这一列存在，别名表的维护就从猜变成了看数据。

加这一列的成本几乎为零，收益却是把一个不可观测的问题变成了可观测的。更妙的是它会自己长出新知识：跑三个月之后，把这一列做个频次统计，你会得到一张真实的形态分布表，告诉你在哪门语言里哪种写法最主流。这张表比任何一份品牌规范文档都更接近现实，因为它记录的是用户和模型实际在用的写法，不是公司希望大家用的写法。

这一列还有第二个用途，是发现别名表里的死行。跑满一个季度之后，如果某个形态一次都没被匹配到，说明它要么写错了，要么在真实语料里根本不出现。前者是bug，后者说明你的别名表在往里加没用的行。定期清掉死行，表的可维护性才不会随时间下降，否则三年之后没人敢动那张表。

## 别名表的三列结构

别名表本身不复杂，三列就够。

第一列是语言标签，写到地区一级。

第二列是这门语言下的一个形态，一行一个。

第三列是这个形态的类别：官方、转写、屈折、误拼、意译。

类别这一列看着多余，实际非常有用。

它让你能分开统计官方写法的提及率和非官方写法的提及率，两者的差值本身就是一个信号。

如果非官方写法的占比长期偏高，说明你在这个市场的品牌规范没有落地，本地媒体和用户各写各的。这不是监控的副产品，这是品牌部门真正想要而一直拿不到的数据。品牌名能规定一种写法、作者的名字规定不了 (https://zhangwenbao.com/minor-language-eat-local-author-byline-credential-signals.html)那篇讲过命名权归谁决定了你能收敛还是只能汇总，别名表的类别列相当于给这个判断配了一个持续更新的度量。

第一列的写法要有纪律，别在同一张表里混用两种粒度。RFC 5646语言标签规范 (https://www.rfc-editor.org/rfc/rfc5646)定义了语言、脚本、地区三段的组合方式，塞尔维亚语这类双字母系统的语言必须把脚本段写出来才能区分两套写法。定好粒度之后写进文档，后面加语言时照着填，不会出现一行写语种一行写地区的混乱。

## 归一化到底放在链路的哪一步

顺序错了会白做很多功。

正确的顺序是：抓取原文、原样存档、归一化后匹配、记录原始形态。

关键在于归一化只用于匹配，不覆盖存档。

很多实现直接把归一化后的文本存下来，原文就丢了。

丢了原文，前面说的那一列形态统计就无从谈起。

存储成本在这个量级上完全可以忽略，别为了省几兆字节把信息丢掉。

归一化的具体形式也要选对，兼容分解那一档会把一些视觉上不同的字符也合并掉，用在品牌名匹配上可能过头。标准里定义了好几档强度，各有各的适用场景，选之前值得花十分钟读一遍规范里的对照表。选完把这个选择写进文档，因为半年后换了人接手，没人知道当初为什么选的这一档，改一下整批历史数据就不可比了。

## 为什么不同语言之间的百分比不能直接比？

## 答案长度的基线本来就不同

这是第二个核心结论的第一块砖。

同一个问题用不同语言问，答案的平均长度差别很大。

有的语言下模型倾向于给三段话，有的语言下只给一段。

答案越长，能塞进去的品牌名越多，提及率自然越高。

这个差别跟你的品牌一点关系都没有，纯粹是语言层的属性。

可它会直接进到你的报表里，被读成品牌在这个市场表现更好。

验证这一点很容易：把每门语言的答案平均字数统计一遍，跟提及率画在同一张图上，多数情况下两条线的形状高度相似。相似到什么程度，就说明你的提及率里有多少成分是长度效应。见过最夸张的一次是两条线几乎重合，也就是说那份报表从头到尾在衡量的其实是模型在各语言下的话痨程度。这种时候讨论哪个市场该加预算，讨论的是一个跟预算无关的量。

统计答案长度这件事几乎零成本，抓取的时候顺手记一列字数就行。真正需要注意的是别用字符数直接跨语言比——同样一句话，中文的字符数和德语的字符数差得很远。要比就比信息单元数，粗糙一点的做法是数句子个数，虽然不精确，但至少不会因为语言的书写密度差异得出荒谬的结论。

## 每条答案挂几个来源，各语言也不一样

第二块砖跟引用直接相关。

答案底下的来源条数在不同语言下有系统性差异。

高资源语言的答案往往挂五六条来源，低资源语言常常只挂两三条。

坑位少，你被挂上去的概率天然就低。

这同样是语言层的属性，跟你做得好不好无关。

不做归一，你会把坑位少误读成竞争激烈或者内容不行。

而这两个误读会导出完全相反的动作：以为竞争激烈就加大投入，以为内容不行就换团队，而正确的动作可能是什么都不用改。回答语言和来源语言是两个独立字段 (https://zhangwenbao.com/ai-search-language-bias-low-resource-citation-source-audit.html)那篇拆出的是来源的语言构成，这里要拆的是来源的条数基线，两者是同一批原始数据的不同切面。建议在同一次抓取里把两项都记下来，成本只多一列。

为什么高低资源语言的来源条数会有系统性差异，根子在候选池的绝对规模上。Common Crawl按语言统计的文档分布 (https://commoncrawl.github.io/cc-crawl-statistics/plots/languages)里头部与尾部相差好几个数量级，池子小的时候检索器凑不满预期条数，只能少挂几条。这不是策略选择，是可用素材不够，所以它不会因为你做了什么而改变。

## 低资源语言里模型更爱给泛泛回答

第三块砖来自模型行为本身。

本地来源稀薄的时候，模型给出的回答会更笼统。

笼统的回答里不太会点名具体商家。

它更可能说一句可以考虑几个主流品牌然后就此打住。

这种回答不算错，但它对所有品牌一视同仁地不提及。

于是那门语言的整体提及率被压得很低，所有玩家都一样低。

这条跟小语种AI稿里读着最顺的那一段恰恰是模型编出来的 (https://zhangwenbao.com/low-resource-language-ai-hallucination-rate-content-risk.html)那篇是一枚硬币的两面：来源不足时，模型要么泛泛而谈，要么开始填补细节。前者对品牌是无差别的低曝光，后者是有风险的错误信息，两种都出现在同一批低资源语言里，取决于问题的具体形态。判断你落在哪一侧，看答案里有没有出现具体的数字、期限、型号——有就是在填补，没有就是在泛泛而谈。

判断一批答案是泛泛而谈还是在填补细节，有个两分钟能做完的检查：扫一遍答案里有没有具体的数字、期限、型号、认证编号。这类具体信息只可能来自某个来源，模型不太会凭空生成一个格式完整的编号却完全不挂来源。有具体信息又没有对应来源的，基本可以判定为填补，那一条要单独挑出来核。

## 你比出来的到底是语言还是品牌

把三块砖叠起来，结论就成立了。

德语一成二、印尼语零点四成，这个差值里有品牌的成分，也有语言的成分。

不做分离，你没法说出品牌那部分占多少。

而所有的资源分配决策，需要的恰恰是品牌那部分。

语言那部分你改不了，它对所有竞争对手一样。

把不可改的部分算进考核，等于给团队发了一张自己解不开的题。

这正是官方公布的是国家数、你要的是语言数 (https://zhangwenbao.com/ai-overviews-100-countries-six-languages-minor-language-citation.html)那篇讲的那条原则的又一次应用：口径不一致时必须先换算，而不是把两个量纲直接相减。只是这一次两个量纲藏得更深，它们不在两个字段里，它们混在同一个百分比里。要把它们拆开，需要引入一个外部参照物，而这个参照物就是下一节要说的对照组。

语言层属性正在快速变化这一点也要考虑进去。斯坦福人工智能指数年度报告 (https://hai.stanford.edu/ai-index/2025-ai-index-report)逐年记录的语言覆盖与能力数据显示，语种之间的差距在收窄，但收窄的速度各不相同。这意味着你今年测出来的基线，明年不一定还成立，所以基线必须定期重算，不能一次算完当常数用三年。

## 对照组该怎么选，基线怎么算？

## 拿本地头部三家当对照

方法说穿了很朴素。

每门语言里挑三个本地市场的头部同行。

用同一批问题、同一套流程，把它们的提及率也测一遍。

三家的平均值就是这门语言在这个品类下的基线。

你的数字除以这个基线，得到一个归一化后的相对分。

相对分才是可以跨语言横向比较的量。

挑对照组有两条纪律：必须是本地公司，必须跟你在同一个价格带。挑成跨国巨头，基线会被抬到没有参考价值；挑成小作坊，基线又太低。本地且同价格带这两条，保证了对照组面对的语言环境跟你完全一致，差别只剩经营本身。这跟做工具类内容时找外部真值当对照的思路是一样的：自己算出来的数字没有意义，除非旁边有一个已知的参照物。

## 归一化分数具体怎么算

算法要简单到能在表格里手算。

先算你的原始提及率，再算三家对照的平均提及率。

两者相除，得到一个以一为中心的比值。

大于一说明你在这门语言里跑赢了本地平均。

小于一说明跑输了，而且跑输的幅度可以跨语言比较。

别去做更复杂的加权和标准化，复杂度上去之后没人再信这个数字。

如果非要加一项，加对照组的离散度：三家之间差距很大的时候，平均值本身就不可靠。离散度大通常意味着这个品类在这门语言下还没有形成稳定格局，谁被提到有很大偶然性，这时候相对分的波动区间要放宽。把离散度写在报表的旁边，读表的人才知道该把这个数字看得多重，否则一个一点二和一个零点八会被当成同样确定的结论。

小样本情形要特殊处理。如果某门语言下你和三家对照的原始提及次数都是个位数，比值这个形式就不稳定，分母稍微动一下比值就翻倍。这时候建议退回绝对次数，只报你和对照各自被提到几次，不做除法。数字丑一点没关系，比一个看着精确实则随机的比值强。

## 对照组选错会发生什么

讲一个反面情形。

有团队图省事，十门语言用了同一组对照——三家全球品牌。

结果每门语言的基线都很高，自己的相对分一律很低。

报表看起来很一致，结论是全线落后。

实际情况是在几个小市场里他们已经是本地第一梯队。

用全球基线去量本地表现，等于拿姚明的身高给全班同学打分。

更常见的一种错法是对照组选了三家，可这三家在某门语言里根本不经营，于是那门语言的基线接近零，你的相对分被除成一个天文数字。这类异常值往往不会被当成错误，反而会被当成亮点写进汇报，因为它符合大家希望看到的结果。防这个的办法是给相对分设一个上限，超过上限的直接标记为待核，逼人回去看原始数据。

## 把提示词翻译过去，问的还是同一个问题吗？

## 机翻提示词会带来意图漂移

这一节讲的是变量干不干净的问题。

跨语言测量的标准做法是用同一个问题问十种语言。

可这个同一个问题是怎么来的，通常是机翻。

机翻之后，问句的意图会发生细微但真实的漂移。

有的语言里译文变得更正式，有的变得更口语。

语体一变，检索到的文档类型跟着变，提及率也跟着变。

已有研究发现提示词的语体和礼貌程度会影响模型输出的质量，而这种影响在不同语言之间还不一致。Should We Respect LLMs这项跨语言的提示礼貌度研究 (https://arxiv.org/abs/2402.14531)测的就是这件事，结论是同一档礼貌程度在英语、中文、日语上的效果并不相同。这意味着你把一条中性的中文提示词翻成敬语发达的语言时，如果译文自动升了一档语体，你测到的差异里就掺进了语体效应。

用模型来判断译文等不等价这条路也不完全可靠。How Reliable is Multilingual LLM-as-a-Judge这项研究 (https://aclanthology.org/2025.findings-emnlp.587/)发现模型担任评判者时在不同语言上的判断并不一致，也就是说你拿模型去校验跨语言的提示词等价性，校验器本身就带着语言偏差。结论是这一步的最终裁判还得是人，模型只能用来做初筛。

## 锚定实体：品类词加使用场景

解决办法不是不翻译，是给翻译加约束。

约束的核心是锚定住两个东西：品类词和使用场景。

品类词必须用当地实际通行的说法，不能用字典对应词。

使用场景必须一字不差地对应，不能因为当地习惯不同就换一个。

其余部分可以译得自然，这两项必须锁死。

锁住这两项，语言就成了唯一变量，别的都被固定住了。

为什么必须是这两项，因为它们直接决定检索器召回哪一批文档，而其余成分主要影响答案的措辞。换句话说，锁住检索侧的输入，放开生成侧的输入。这个取舍跟前一篇讲西语变体时那条只替换标记词的纪律是同一条原理的两个应用：变量要落在链路上你真正想测的那一环，不能让它扩散到整句话。

## 本地化重写的四条硬约束

把约束写成可执行的清单。

第一条，品类词由本地母语者提供，不由译者决定。

第二条，问句的疑问类型不变，是什么就不能译成怎么样。

第三条，不加也不减任何限定成分，包括时间、地点、价格区间。

第四条，语体统一到中性，所有语言都不用敬语也不用俚语。

四条都写进流程文档，让每次重跑都能复现。

第四条最容易破功，因为母语者的本能就是把句子改得更自然，而更自然往往意味着更符合当地的语体习惯。处理办法是提前告诉他们这批句子不是给用户看的，是测试用的，生硬一点没关系。这个说明不给的话，你会收到一批读起来很棒但彼此不可比的问句，而且返工时对方会觉得莫名其妙。母语者审校的验收判据 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)那篇给的那套标准在这里要反着用：这一次读着自然反而是问题。

有人会问要不要加第五条，规定所有语言的问句长度一致。不建议加，因为各语言表达同一个意思所需的长度天然不同，硬凑长度反而会逼着译者加废话或者删信息。长度这一项该做的是记录而不是控制，把它当成一个协变量存下来，分析时如果发现长度跟结果强相关，再回头处理。

## 怎么验证十条问题真的等价

最后加一道验证。

把十种语言的问句都回译成同一门语言。

回译结果放在一起对照，看看有没有明显的意思差别。

有差别的挑出来重写，直到回译结果高度一致。

这一步不完美，但能抓住大部分明显的漂移。

做一次大约两小时，比事后发现数据不可比便宜太多。

回译对照还有一个副产品：它能暴露出哪些概念在某门语言里根本没有对应的常用说法。回译回来发现某一条变成了一句绕口的解释，说明当地人不这么表述这件事，那条问题本身就不该出现在测试集里。这跟两个市场的关键词表可以一字不差、落地页却得拆成两种 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)那篇的观察相互印证：概念的可表达性，本身就是市场差异的一部分。

## 提及和引用是两个字段，报表里能合并吗？

## 被说到名字与被挂上链接

先把定义分清楚。

提及是答案正文里出现了你的品牌名。

引用是答案底下的来源清单里出现了你的域名。

两者可以同时发生，也可以只发生一个。

只被提及不被引用，说明模型知道你但没拿你的页面当依据。

只被引用不被提及，说明你的页面被读了但品牌没被说出口。

两种情况需要的动作完全不同：前者要补的是内容的可引用性，后者要补的是页面上品牌信号的显著度。把两者合成一个数字，得到的是一个既不指向内容也不指向品牌的中间值，任何人拿到它都不知道下一步该干什么。GEO三层可见性指标那一篇 (https://zhangwenbao.com/geo-visibility-metrics-scoring.html)把这类指标拆层的思路，在跨语言场景下要再多拆一次，因为语言这一维会让两者的差距变得更大。

官方口径的措辞也值得留意。两百多个国家、四十多门语言那份扩容公告 (https://blog.google/products-and-platforms/products/search/ai-overview-expansion-may-2025-update/)讲的全是回答语言的覆盖，通篇没有承诺来源的构成，更没有承诺答案里会不会点名商家。把公告里的覆盖读成自己会被提及，是很多团队排期时的第一个乐观假设，而这个假设从来没有被官方做出过。

## 跨语言时两者的差距会被放大

为什么在跨语言时更要分开看。

本地来源少的语言里，模型更依赖它的参数知识来提品牌。

参数知识里的品牌认知来自训练数据，大品牌天然占优。

而引用取决于当下检索到了什么页面，小玩家有机会挤进去。

于是在低资源语言里，提及率被大品牌占满，引用率反而更开放。

这两条线在同一门语言里可能一条向下一条向上。

对中小站来说这是个好消息：引用这一侧的门槛比提及那一侧低得多，而引用带来的点击是实打实的。把有限的力气压在引用上，比试图挤进模型的品牌认知里现实得多——后者需要的是多年的品牌建设，前者需要的只是一篇写得比同行更完整的本地语言内容。小语种问答长尾那篇 (https://zhangwenbao.com/minor-language-qa-long-tail-content-value-ai-era.html)算的就是这笔账。

## 只报一个数字会引出什么决策

讲清楚汇报的后果。

报一个可见度总分，老板会问怎么把它提上去。

这个问题没法回答，因为总分不对应任何具体动作。

报提及率和引用率两个数，问题会自动变成两个更具体的问题。

再加上按语言拆开，问题会变成十个市场各自的问题。

指标的粒度决定了讨论的粒度，这条规律在任何组织里都成立。

但粒度也不能无限细，超过一屏的报表没人看，最后大家还是只盯那个总分。实践下来比较稳的形态是：首页一张十行的表，行是语言，列是提及率、引用率、归一化相对分三项，后面挂明细。三列刚好能在一眼里看完，又足以区分出三类不同的问题。AI引用率监控闭环那篇 (https://zhangwenbao.com/monitor-measure-iterate-ai-citation-optimization-2026.html)给的四步流程可以直接套在这张表的后面，只是每一步都要按语言分开跑。

## 一次测多少条、多久测一次才不算噪声？

## 单次结果的抖动来自哪里

先搞清楚噪声的来源。

同一个问题连问三次，答案不会完全一样。

来源清单的变动比正文措辞的变动更大。

抖动来自采样、来自检索的近似算法、来自缓存状态。

这些都不是你能控制的，只能靠重复测量把它平均掉。

单次结果基本没有解释价值，把它写进周报是在制造噪声。

更麻烦的是抖动幅度本身在各语言之间不一样，候选文档越少的语言，抖动越大。因为候选池小的时候，排序上的微小扰动就能换掉整份来源清单；池子大的时候，头部几条相对稳定。这意味着你不能给所有语言设同一个显著性门槛，小语种那一侧的门槛必须放宽，否则你会不停地追逐一堆假信号。

区分抖动和真实变化，最省事的办法是留一组不动的对照问题。挑五条内容完全不涉及你也不涉及对照组的通用问题，跟主测试集一起跑。这五条的结果如果也在同步波动，说明那一轮整体环境有变；如果它们很稳而你的数在动，那就是真实变化。五条问题的成本可以忽略，价值却是给整套测量装了个基准表。

## 样本量与复测频率的账

给一组可以直接抄的数字。

每门语言三十条问题，每条跑三轮，是一个比较稳的起点。

十门语言就是九百次问答，自动化之后一天能跑完。

频率按月，季度做一次含对照组的完整测量。

月度测量只看自己的数，季度测量才重算基线。

基线不用每月重算，因为语言层的属性变得很慢。

这套配比的思路跟排名追踪的抽样设计那篇 (https://zhangwenbao.com/rank-tracking-sampling-design-frequency-device-sample-cost.html)是一脉相承的：把预算花在样本的覆盖面上，而不是花在测量的频率上。频率翻倍带来的信息增量很小，覆盖面翻倍带来的增量很大，因为后者才能让你发现之前完全没看到的市场。跨语言场景下这个结论更成立，因为语言是一个天然的分层变量，每多一层都是全新的信息。

## 跨语言时噪声本身也不同

再补一条容易被忽略的。

比较两门语言的变化时，要比的是各自的相对变化。

德语涨了两个点和印尼语涨了两个点，含义完全不同。

前者可能在噪声范围内，后者可能是一次真实的跃迁。

判断标准是各自的历史波动区间，不是绝对数值。

所以历史数据要存够长，至少半年才能画出可信的波动带。

头三个月的数据基本只能用来建立基线，不要拿它做任何决策，这一点最好在项目启动时就跟老板说清楚。否则第一个月的报表一出来，就会有人根据某个孤立的数字提出行动方案，而那个数字什么都不代表。把观察期写进项目计划，是这类监控项目里最省事的一次预期管理。

还有一种跨语言特有的假信号：某门语言的答案形态整体改版。比如原本给列表式回答的语言突然改成段落式，列表里点名商家的概率远高于段落，于是提及率整体掉一截。这类变化跟内容无关，跟品牌无关，只跟那门语言下的答案模板有关。发现它的办法是每次抽查时顺手记一下答案的结构形态，改版会立刻显形。

## 这套监控该由谁来跑，成本压得下来吗？

## 三种实现路径的成本对比

先看有哪些选择。

第一种是买现成的监控工具，配置好语言和关键词。

第二种是自建脚本，调接口批量提问再解析结果。

第三种是人工，母语同事定期手动跑一批问题。

三种各有各的适用场景，不是越自动越好。

关键在于前两种都依赖那个字符串匹配，而问题恰恰出在那里。

现成工具的最大问题是别名表通常不开放给你改，或者只能加简单的同义词，加不了带类别的结构化别名。那份二十款监控工具的评测 (https://zhangwenbao.com/geo-aeo-monitoring-tools.html)里的选型维度，在跨语言场景下要额外加一条：能不能自定义品牌名的匹配规则。这一条不满足，工具在小语种上给出的数字就不能用，无论它别的功能多强。

## 本地母语者在链路里的位置

人工那一环放在哪儿最值。

不是放在跑问题上，那件事机器做得更好。

是放在两个位置：建别名表，和抽查匹配结果。

建表是一次性的，每门语言一两个小时。

抽查是周期性的，每月每门语言二十条，半小时。

这两件事机器做不了，因为它们需要的是语言直觉不是规则。

把母语者放在这两个位置上，一个人每月投入的时间大约是半天，就能覆盖五到六门语言的质量兜底。而如果把他放去人工跑问题，同样的半天只够跑一门语言的一次测量，产出还不如脚本。资源放错位置在多语言项目里非常普遍，根源是大家默认母语者的价值在于产出内容，其实在监控链路里，他们最大的价值是当校验器。

抽查怎么抽也有讲究。别随机抽，要按形态分层抽：官方写法抽五条，转写抽五条，屈折形态抽五条，未匹配到任何形态的答案再抽五条。最后那一组最有价值，因为它专门用来发现别名表里缺了什么。纯随机抽的话，你抽到的绝大多数是已经匹配成功的样本，看一百条也发现不了新形态。

## 每月能压到多少工时

把账算完整。

初次搭建，含别名表和流程文档，大约两周人力。

之后每月的固定投入是脚本跑批加一次抽查，两到三天。

季度多一次完整测量含对照组，再加两天。

换算下来一年大约三十个工作日。

覆盖十门语言的话，平均每门语言一年三天。

这个成本能不能通过，取决于你怎么描述它的产出：说成一份报表，很难通过；说成十个市场的存在感体检，通过率高很多。后一种描述不是话术，它更准确——这套东西真正的产出不是数字，是一次次发现某个市场其实完全没被覆盖。GEO团队的四层落地框架那篇 (https://zhangwenbao.com/geo-team-deployment-four-layer-framework.html)把监测放在了最后一层，跨语言场景下建议把它前移，因为它会直接改变前面几层的排期。

## 哪些数字最好别放进汇报

## 三个会误导决策的指标

逐个说清楚。

第一个是未做基线归一的跨语言提及率对比。

它会把语言层的属性读成市场表现，导出错误的预算分配。

第二个是提及与引用合并出来的可见度总分。

它不对应任何具体动作，只会引出一句把它提上去。

第三个是单月的变化率，尤其是小语种那几列。

第三个最危险，因为它天然是最刺激的那一列：小语种的基数小，百分比变化动辄三位数。报表上一列鲜红的增幅，实际可能是从两次提及变成了五次。防这个的办法很简单，把绝对数字和百分比并排放，只要绝对数字小于某个阈值就不显示百分比。这个改动五分钟能做完，能拦下一整年的错误解读。

还有第四个值得警惕的：跨语言的排名。把十门语言按提及率从高到低排成一张榜，会天然引出一个谁第一谁最后的叙事，而这个叙事里排在最后的那门语言，很可能只是因为它的答案短、来源少。榜单这种形态自带优劣暗示，用在本来就不可比的量上，误导性比单纯的数字更强。

## 换成什么口径更合适

给出替代方案。

用归一化相对分代替原始提及率。

用提及率和引用率两列代替合并总分。

用滚动三个月的移动值代替单月值。

再加一列样本量，让读表的人自己判断可信度。

四项改完，报表的行数没变，误读的空间小了一大截。

最后加一条：在报表的第一行写清楚这些数字不能回答什么。比如它不能回答某门语言的用户是不是真的更认可你，也不能回答提及涨了会不会带来订单。把边界写在最显眼的位置，比藏在附录里有用得多，因为读表的人往往只看第一屏。这一条是从排名监测为什么总对不上 (https://zhangwenbao.com/rank-tracking-methodology-traps-share-of-voice.html)那篇里学来的老经验，换个场景照样成立。

## 常见问题解答

## 已经在用现成的监控工具，还需要自己建别名表吗？

需要，除非工具允许你自定义每门语言的匹配形态。多数工具的关键词配置只支持简单的同义词列表，无法表达带类别的结构化别名，也不会把实际匹配到的形态回传给你。没有这两样，工具给出的小语种数字就无法验证真伪。折中做法是继续用工具跑主流语言，小语种那几门单独用脚本跑一遍做交叉核对，差距大到一定程度就说明工具那一侧漏了。

## 品牌名只有三四个字母，前缀匹配误伤太多怎么办？

短品牌名不要用前缀匹配，改用词边界加人工审核。具体做法是先用较宽的规则捞出候选，再让人过一遍，把误伤的踢掉，同时把真实形态收进别名表。跑两三个月之后别名表基本收敛，人工量会降到很低。另一个补充办法是给匹配加上下文条件，比如附近出现品类词才计数，能拦掉大部分无关命中，代价是会漏掉少量只提品牌不提品类的情形。

## 对照组的三家同行，怎么保证选得客观？

用当地公开可查的口径来选，不要凭印象。可以看当地电商平台的品类销量榜、当地比价站的收录情况、当地行业媒体的年度盘点，三个来源交叉出现的公司基本就是本地头部。避免让本地销售同事凭感觉推荐，他们的名单往往偏向于自己接触最多的那几家。选完之后把选择依据记录下来，明年重选时才有可比性。

## 能不能只测一门通用语言，别的市场按比例推算？

不能，因为语言之间的关系不是比例关系。同一个品牌在两门语言里的表现可以完全脱钩，尤其当其中一门语言的本地来源池几乎是空的时候。推算的前提是变量之间存在稳定的相关性，而跨语言这一层恰恰不满足这个前提。真要省成本，正确的做法是减少每门语言的问题条数，而不是减少语言的门数——覆盖面比精度更重要。

## 模型换代之后历史数据还能用吗？

趋势能用，绝对值不能直接接续。底层模型换一次，答案长度、来源条数、品牌提及习惯都可能整体平移，这时候你看到的跳变跟自己的内容毫无关系。处理办法是在时间轴上打一个标记，标记前后各自算基线，跨标记比较时只比相对分不比绝对值。所以对照组的价值在这里第二次体现出来：它跟你一起经历了模型换代，相对分因此仍然可比。

## 有必要每门语言都做吗，先做三门行不行？

完全可以，而且推荐这样开头。选三门的时候建议拉开差距：一门高资源的大语种、一门书写系统不同的、一门屈折变化明显的。这三门能把前面讲的三类形态问题都覆盖到，别名表的结构和流程会在这一轮里定型。之后再扩语言时，加的只是数据不是设计，成本会低很多。反过来先做三门相似的语言，扩到第四门时经常要推倒重来。

## 这套东西的产出，怎么跟销售或者订单挂钩？

不建议直接挂钩，中间隔的环节太多。更现实的用法是把它当作前置的覆盖度检查：某个市场长期零提及零引用，那里就不该被写进下一年的增长目标，或者写进去之前先补一轮内容。把它定位成排期依据而不是绩效指标，既避免了归因扯皮，也避免了指标本身被优化。真正需要跟订单挂钩的，是从AI答案里点进来之后那一段的转化数据，那是另一套埋点的事。

## 权威参考资料



## 那句日语回答一个错都挑不出来，只是把能退货答成了不能退

- URL：https://zhangwenbao.com/minor-language-negative-question-answer-polarity.html
- 分类：小语种SEO
- 发布：2025-12-13  |  更新：2026-07-29
- 摘要：英语的是与否跟着事实走，日语的跟着问句走，问句一旦带否定，两套体系给出的答案正好相反。讲清德语为什么专门造了第三个词、界面按钮三十年前怎么绕开这个坑、答句被拆开抽走时为什么风险翻倍，以及三种改法哪一种活得久。
- 关键词：出海SEO,多语言SEO,内容本地化,小语种SEO

> **TLDR**：摘要：常见问题区里有一句退货政策，日语版翻得一个错都挑不出来，可它把能退答成了不能退。原因不在译者身上：英语的是与否跟着事实走，日语的跟着问句本身走，问句一旦带否定，两套体系给出的答案正好相反。德语还专门造了第三个词来对付这种情况，而英语里根本没有这个词。这是唯一一类语法完全正确、翻译完全忠实、意思却正相反的错误，所有质量关卡都查不出它。界面上的按钮三十年前就不用是和否了，正文里却还在用。这一篇讲怎么把答反的句子找出来。

> 摘要：常见问题区里有一句退货政策，日语版翻得一个错都挑不出来，可它把能退答成了不能退。原因不在译者身上：英语的是与否跟着事实走，日语的跟着问句本身走，问句一旦带否定，两套体系给出的答案正好相反。德语还专门造了第三个词来对付这种情况，而英语里根本没有这个词。这是唯一一类语法完全正确、翻译完全忠实、意思却正相反的错误，所有质量关卡都查不出它。界面上的按钮三十年前就不用是和否了，正文里却还在用。这一篇讲怎么把答反的句子找出来。

## 一句译文一个错都挑不出来，为什么意思正好反了？

## 从一家日本户外家具站的退货问答说起

先讲一件真事。

那是一家做日本市场的户外家具站，主推庭院桌椅和遮阳伞。

大件商品退货规则复杂，常见问题区因此写得很细，一共三十多组问答。

其中一条问的是拆封之后还能不能退，答案是能退，有条件。

日语版上线之后，客服开始收到一类奇怪的工单：用户来问为什么明明写着不能退，客服却说能退。

调出日语页面一看，那一句翻得完全正确，每个词都对得上原文。问题出在问句带了否定，而答句只写了一个是。

保哥后来把这一条单独拎出来做了个内部案例，因为它是少见的那种翻译零失误、结果一百八十度错的事故。

这批工单还有一个特征当时没人注意：来问的用户全都已经把商品加进了购物车。他们不是在比价阶段随便看看，是在最后确认阶段专门去翻了那一条。答错这一条，损失的不是流量而是已经走到门口的订单。

## 三道质量关卡，一道都没拦住

这件事最值得琢磨的是它一路绿灯。

机器翻译给出的译文没问题，因为逐句看确实忠实。

母语审校也没提意见，因为那句日语读起来自然得很。

结构化数据校验通过，问答标记规规矩矩。

三道关卡查的分别是准确、流畅、格式，而这个错误在这三项上全部合格。它是在问句和答句之间那道缝里产生的，而没有任何一道关卡会同时看这两句。

三道关卡还有一个共同的盲区：它们的检查单位都是一句话。译文准确按句判，语言流畅按句判，标记格式按字段判。而这个错误存在于两句话的关系里，任何以单句为单位的检查都天然看不见它。要发现它，检查单位必须是一对。

把这件事说给别的部门听的时候，最好用一句话概括：我们的三道关卡各自看一句话，而这个错误住在两句话之间。这句话通常比任何语言学解释都管用，因为它指向的是流程结构，不是语言知识。

## 这一类错误的形状很特别

把这类错误的特征列一下，方便识别。

它只出现在问句带否定的时候，肯定问句下两套体系的答案完全一致。

它只影响一个字，就是那个表示是或否的词，其余部分一字不差。

它的后果是布尔取反，不是含义模糊，也不是程度偏差。

换句话说，这是唯一一类语法完全正确、翻译完全忠实、意思却正相反的错误。别的翻译问题是把话说歪了，这个是把话说反了，而说反的代价在退货、保修、资格条件这些地方是实打实的。

布尔取反这个性质还带来一个附加麻烦：它无法通过程度上的谨慎来缓解。文案写得再保守、再留余地，反了就是反了。别的翻译风险可以靠措辞留一线，这一类不行，它只有对和错两种状态。

还有一点让这类错误特别难缠：它在两个方向上都会发生。跟着问句走的语言翻成跟着事实走的语言会反，反过来同样会反。也就是说不存在一个安全的翻译方向，只要跨过那条分界线，两边都要检查。

## 英语的是与否跟着什么走，日语跟着什么走？

## 两套体系，一套跟事实，一套跟问句

先把机制说清楚，这一节是全文的地基。

英语的是与否跟着事实本身走。回答的人心里想的是这件事到底成不成立，成立就说是。

日语的是与否跟着提问的那句话走。回答的人心里想的是你这句话说得对不对，对就说是。

肯定问句下两者没有分别，因为事实成立等于问句正确。

一旦问句带上否定，两者立刻分道扬镳：问的是不能退吗，事实是能退，英语说是，日语说否。同一件事实，同一个提问，两门语言给出的那个字正好相反。

这两套体系还有一个容易混淆的地方：它们的差别不在肯定与否定这两个词本身，而在这两个词指向什么。同一个词，一套指向外部世界，一套指向刚才那句话。所以查词典是查不出这个差别的，词典给的释义两边完全一样。

还有一个判断哪一套体系在起作用的土办法：看这门语言里有没有单独一个字就能完整回答问题的习惯。如果日常对话中人们习惯只答一个字，那这门语言多半跟着问句走；如果习惯把动词带上再答，那多半跟着事实走。

## 用退货那句话走一遍

抽象说完，具体走一遍。

假设事实是这件商品可以退。

用户问：这件不能退吧。英语回答的人想的是它能退，于是说是的、能退。

日语回答的人想的是你这句话说得不对，于是说不是的，然后补一句能退。

问题就出在补的那半句上：翻译的时候如果只翻了那个是或否，后面的补充被省略或者被简化，整句话的意思就彻底翻转了。而省略后半句恰恰是常见问题区最爱做的事，因为要短。

这里还可以做一个很快的自测：把你手上任何一条带否定的问答，用目标语言念给母语同事听，只念问句和那个字，不念后半句。他如果需要停顿一下才能确定意思，那这一条就已经在风险名单上了。

走这一遍的时候还能顺手发现另一件事：真正承载信息的从来不是那个字，而是它后面那半句。既然如此，那个字其实可以整个去掉，直接从事实说起。这个念头就是后面所有改法的起点，走一遍例子比看十条规则更容易想到它。

## 这不是日语独有的，它是一整片语言

要强调一句：这不是日语的怪癖。

韩语、汉语普通话在这一点上跟日语是一路的，回答跟着问句走。

英语、德语、法语、俄语这一路则跟着事实走。

也就是说这条分界线横穿了你的语言组合表，不是某一门语言的例外条款。各语言的问答标注体系里，否定这一项是被当成独立特征处理的，通用依存标注就把肯定与否定单独列成一个特征 (https://universaldependencies.org/u/feat/Polarity.html)，正说明它不是随附于句子结构的小事。

这条分界线还有一个实际用途：它决定了内容分发的路径要不要改。如果你的内容是从英语分发到各语种，那么每一次分发到跟着问句走的那几门语言时，都要过一遍这个检查；分发到同一路的语言之间则不必。检查点的位置由此确定。

需要提醒一句的是，这条分界线跟语系没什么关系。它横穿了亲缘关系很远的语言，也把亲缘很近的语言分在两边。所以不能靠这门语言像谁来推断，只能一门一门确认。好在确认成本只有一个问题的工夫。

## 做一张两列的对照表就够用了

落地的时候不需要懂语言学。

只要给每门目标语言标一个属性：这门语言的是与否跟事实还是跟问句。

这一列填完，哪些语言版本需要额外检查就一目了然。

整个语言层的判断到此为止，剩下的全是内容和工程上的事。跨语言的极性问句本身怎么标记，语言类型学的样本调查在极性问句标记方式的全球分布 (https://wals.info/feature/116A)那一项里有系统统计，可以看出这件事在语言之间的差异有多大。

填这一列的时候有个偷懒办法：不必查语言学资料，直接问那门语言的母语同事一个问题——如果我问你不饿吗，而你其实饿了，你会先说哪个字。答案在三秒钟内就出来了，而且比任何文献都可靠。

这张表填完之后建议存进语言资产清单，跟字体子集、输入法映射、排序规则放在一起。它属于那种一次确认可以管很多年的属性，语言本身不会变。放在一起的好处是新增语种时有人会照着表逐项补齐，不会漏。

## 德语为什么要专门造一个词，来回答否定问句？

## 第三个词的存在本身就是证据

德语这边有个东西特别值得看。

德语除了是和否，还有第三个专门的词，用来在否定问句下表示肯定。

问：你不来吗。答那个词，意思是我来。

这个词在德语里日常得很，词典里这个小词的用法条目 (https://www.dwds.de/wb/doch)列了长长一串义项，反驳否定问句只是其中之一。

法语也有一个功能相同的专用词。两门语言各自独立造出这么一个词，说明这个位置上确实存在一个非解决不可的歧义——它们选择了在词汇层解决，而英语选择了不解决。

这个词的存在还说明了另一件事：这个歧义严重到值得一门语言为它专门保留一个高频词。语言不会为无关紧要的区别付出这种成本。反过来看，英语没有造这个词，不是因为它没有这个歧义，而是因为它选择了用一句话来消解。

还可以从另一个角度看这个词的价值：它让答句可以保持极短，同时不产生歧义。德语因此不必像英语那样把主谓补全，一个字就够了。语言在简洁和明确之间做了不同的取舍，而每种取舍都有它的代价。

## 英语的处理办法是绕过去

英语没有这个词，那英语怎么办。

英语的办法是把答句补全：不说单独一个是，而是是加上完整的主谓。

补全之后歧义消失，因为后半句把事实说清楚了。

这个习惯在英语母语者那里是自动的，几乎没人意识到自己在做一件消歧的事。

问题在于，翻译和写作规范都倾向于把答句写短，而写短的第一刀通常就砍在后半句上。英语的解法藏在一个没人注意的习惯里，一旦被效率优化掉，歧义立刻回来。

英语这个补全习惯还有个副作用值得一提：正因为它是自动的、无意识的，英语母语的内容负责人在审阅译文时也察觉不到这里有个坑。他看到译文里那个孤立的字，会理所当然地按自己的语言习惯把它补全成完整的意思。

## 三门语言，三种办法，互不通用

把三条路摆在一起看。

德语和法语在词汇层解决，各造一个专用词。

英语在句法层解决，靠补全主谓。

日语和韩语根本不认为这里有歧义，因为它们的规则本身是自洽的，只是跟英语那套反着来。

三种办法之间没有任何一条能直接翻译成另一条。把德语那个专用词翻成英语，只能翻成是，而那个是又会在日语里被翻成相反的字。一条信息经过两次忠实翻译，可以精确地变成它的反面。

两次忠实翻译得出相反结论这件事，跟被动语态那类损失有一个共同点：都是在每一步都合规的前提下发生的。区别在于那一类丢的是一个名词，这一类改的是一个真值。丢名词还能靠上下文找补，改真值找补不回来。语态那一层的机制在被动语态里消失的那个施事者 (https://zhangwenbao.com/minor-language-passive-voice-agent-loss.html)那篇里。

三条路互不通用这件事，还带来一个翻译流程上的具体后果：这类句子不适合走翻译记忆库。记忆库匹配的是源语言句段，而这里正确的译法取决于目标语言的体系，同一个源句在不同目标语言里要拆成完全不同的结构。

## 这跟承诺强度被译软了，是同一类问题吗？

## 一个是连续谱，一个是开关

这两件事经常被放在一起谈，但它们不是一类。

承诺强度那件事发生在一条连续的坡上：必须、应当、可以，中间还有无数档。译过去之后档位挪了一格两格，方向没变。

本文这件事没有中间档，它只有两个值，而且译过去之后直接跳到了另一个值。

前者是幅度问题，后者是符号问题。

幅度错了，读者读到的还是同一个方向的意思，只是分量不对；符号错了，读者读到的是完全相反的事实。情态那一层的完整处理办法在小语种里的情态与义务表达 (https://zhangwenbao.com/minor-language-modality-obligation-commitment-strength.html)那篇里，本文不重复。

这个差别还能解释为什么两件事的发现渠道不同。强度出问题，通常由法务或者客户在读文案时提出；极性出问题，通常由客服在处理纠纷时发现。前者在发布前，后者在发布后，这也是后者代价更高的原因。

## 两者的风险分布正好相反

更有意思的是它们的风险落点。

强度被译软，越重要的句子越容易中招，因为重要的句子被润色的次数最多，每润色一次就往软里挪一点。

极性被译反，越简短的句子越容易中招，因为短句最容易把消歧用的后半句省掉。

一个跟重视程度成正比，一个跟篇幅长度成反比。

这条差别有很实际的用处：查强度问题要从最重要的页面查起，查极性问题要从最短的答句查起，两份排查清单的排序方式完全不同。

两条排查线还可以合并成一句话记住：改得越多的地方查强度，写得越短的地方查极性。多数团队的直觉是重点检查最重要的页面，这个直觉在强度那一侧对，在极性这一侧正好把最危险的短句漏掉了。

两条线相反这件事，值得在排查清单的开头单写一行提醒。人的直觉太强了，不写下来的话，执行的人还是会从最重要的页面开始查，然后得出一个这里没什么问题的结论，而真正的问题全在他没看的那些短句里。

## 能不能一起查？可以，但要分两栏

实操上两件事可以放进同一次审校，前提是分开列。

强度那一栏问的是这句承诺的分量对不对。

极性那一栏问的是这句回答的方向对不对。

合在一栏问，审校员会本能地只回答第一个问题，因为分量的判断更符合他的职业习惯。

这类审校简报的结构该怎么写，小语种译文验收清单 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)里有现成的框架，加一栏就行，成本几乎为零。

分两栏还有一个附带好处：它把一个模糊的翻译质量问题拆成了两个可以分别统计的项。统计出来的数字能进报表，能看出哪个语种在哪一项上更容易出问题，而笼统的翻译质量分永远给不出这种指向。

分栏之后还有一个意外的效果：审校员会开始主动报告第二类问题。人在只被要求判断一件事的时候，很难注意到另一件事；一旦表格上有那一栏，他就会去看。表格结构本身在引导注意力，这一点比培训有用。

## 你的常见问题区里，到底有多少个否定问句？

## 比你以为的多，而且原因很讽刺

先说一个反直觉的事实。

越是照着用户原话写的常见问题区，否定问句越多。

因为用户来问的时候，问的本来就是不能退吧、是不是不包邮、这个是不是不支持货到付款。

人在担心一件事的时候，问出来的话天然带否定。

而所有的问答写作指南第一条都是用用户的原话当问题。于是这条最正确的建议，恰好把风险最高的句型批量搬进了页面。

这个讽刺还有一层：用户原话里的否定往往还带着情绪，比如担心、不确定、已经踩过坑。这些句子恰恰是最该被认真回答的，因为回答它们就是在消除顾虑。把最该答好的一批句子放进最容易答反的句型，这就是这件事的全部难处。

这一层还有一个可以立刻动手的改进：在收集用户原话的时候，把否定问句单独标一个记号。收集阶段多标一个字段，后面所有的排查都省事。等到内容写完再回头识别，成本要高一个量级。

## 数一遍很容易，十分钟的事

要知道自己有多少，数一遍就行。

把所有问句抽出来，看里面有没有否定成分。

中文和日语的否定标记很集中，几个字就能覆盖大半；欧洲语言那边否定还可能是词缀，得多留意。

否定粘进词里而不是独立成词这件事，会让所有靠空格分隔的排查手段失效，这一层在小语种否定构词的关键词陷阱 (https://zhangwenbao.com/minor-language-negation-affix-exclusion-keyword-trap.html)那篇里有完整的展开。

数完通常会得到一个让人意外的比例，多数站点落在两成到四成之间。

数的时候建议顺手记下每条问答的来源，是客服工单、站内搜索还是编辑自拟。三个来源的否定问句比例差别很大，客服工单来的最高。知道了这个分布，以后新增问答时就能提前预判风险量，而不是等写完再筛。

数完之后还建议把比例存下来当基线。以后每次内容批量更新，重新数一次跟基线比。比例明显上升，通常意味着这一批内容更多地采用了用户原话，风险也跟着上升，该加大抽检力度。一个数字就能触发一次决策，成本极低。

## 不是所有否定问句都危险

数完之后要分档，别一刀切。

真正危险的是那些答案为肯定的否定问句，也就是问不能吗、答其实能的那一类。

问不能吗、答确实不能的那一类反而安全，因为两套体系在这里给出的字碰巧一致。

所以危险名单是一个交集：问句带否定，并且答案跟问句的预设相反。

这个交集通常只占全部问答的半成到一成，几十条问答里就那么三五条。范围一旦缩到几条，人工核对就完全可行了。

分档之后还有一件事值得做：把安全的那一档也标出来，别让后面的人重复筛一遍。这类排查最怕的就是没有留痕，下一个人接手时又要把几十条问答从头看一遍，看到第三遍就没人愿意做了。标记本身比排查结论更值钱。

分档的时候还会遇到一种边界情况：问句带否定，答案是有条件的肯定。这一类最难处理，因为它既不能简单答是也不能简单答否。正确的写法是跳过那个字，直接写条件本身，比如满足什么情况就可以。这类问答天然就该写长。

## 这几条恰恰是最值钱的几条

还有一层巧合，不算好消息。

这类问句之所以被用户问出来，是因为他担心某个限制存在。

而你的答案之所以是肯定的，是因为那个限制其实不存在。

也就是说，这几条问答的内容全都是在消除购买顾虑，是转化路径上最靠后的那几句话。

把它们答反，等于在用户最后一次犹豫的时候亲口告诉他别买了。数量最少的那一档，恰好是单条价值最高的那一档。

这一档还有个特点让它更危险：因为答案是肯定的、是好消息，写的人心情放松，审的人也不会警觉。真正让人紧张的是那些答不能的条款，那些反而被反复核对过。风险和注意力在这里是反着分布的。

## 这一对问答被整段摘走之后，会发生什么？

## 问句和答句未必是一起被读的

页面上的问答是成对的，但下游未必这么对待它们。

结构化数据里问和答是两个字段，抽取时可以分开取。

展示的时候也常常只展示答案那一段，问句被折叠或者被改写。

而这类错误的全部信息都藏在问与答的配合关系里，单看答句是没有任何异常的。

一个孤零零的是字，不管在哪门语言里都完全正常。拆开的那一刻，判断这句话对不对所需要的上下文就已经没了。

这里还有一个很容易被忽视的场景：站内的问答区往往支持折叠展开，默认只显示问句。而复制、分享、截图这些动作有时只带走展开后的那一段答案。同一份内容在不同的交互路径上被拆成不同的碎片，拆法你控制不了。

这里还有一个跟展示形态有关的细节：问答区如果做成手风琴式的折叠组件，默认收起时页面上只有问句可见。有些抓取会按可见文本处理，于是拿到一堆问句和不完整的答案。展示形态在这里第一次成了内容问题。

## 答句被切成两句，风险再翻一倍

还有一层更细的。

规范的答句应该是两部分：先答那个字，再补一句完整的事实。

如果这两部分被写成两句话，而抽取只取了第一句，那消歧信息刚好被丢在外面。

句子边界在很多语言里本来就切不准，这件事在小语种的句边界与段落抽取 (https://zhangwenbao.com/minor-language-sentence-boundary-passage-extraction.html)那篇里讲过一整篇。

两个问题叠在一起，结果是：切得越准，摘走的越可能只是那个孤立的字。这是少见的那种精度提高反而更危险的情形。

这条还能推出一个写作上的具体要求：那个字和后面的事实句必须在同一个句子里，不能分成两句。用逗号连接而不是句号，这一个标点的差别，决定了抽取时它们会不会被拆开。怎么把一段话改成截断之后还站得住的形态 (https://zhangwenbao.com/ai-overviews-100-countries-six-languages-minor-language-citation.html)那篇里的改写方法在这里可以直接套用。

## 跨语言的答案不一致，未必都是模型的锅

最后提醒一句归因。

同一个问题用不同语言问，拿到相反的答案，第一反应通常是模型在这门语言上不可靠。

但如果你的页面本身就把这句话答反了，那模型只是忠实地转述了你写的东西。

这种情况下去调提示词、去要求模型更谨慎，全都白费力气，因为源头在你自己的页面上。

低资源语言上的内容风险确实存在，那部分在低资源语言上的内容可靠性风险 (https://zhangwenbao.com/low-resource-language-ai-hallucination-rate-content-risk.html)里单独讲过，但本文这一类要先排除掉，否则会把自己的错误归到别人头上。

归因错了还有连锁代价：团队会因此得出这门语言不值得投入的结论，进而削减这个市场的预算。一个可以在半小时内修好的文案问题，最后变成了一个市场撤退的决策依据，这种事在跨境团队里并不少见。

要避免这类归因错误，有个简单的顺序：先自查页面，再怀疑外部。自查的成本是半小时，而怀疑外部会引出一连串测试、对比和汇报，成本高出几十倍。顺序反过来，多数团队要多花两个月才回到第一步。

## 界面上的按钮早就不写是和否了，正文里为什么还在写？

## 三份界面规范给出的是同一条建议

这件事有个很少被提起的背景：它早就被解决过一次。

苹果的界面规范要求提示框上的按钮用动词说明按下去会发生什么，关于提示框的那一节 (https://developer.apple.com/design/human-interface-guidelines/alerts)专门讲了按钮文案该怎么写。

另一套广泛使用的设计体系在对话框组件的说明 (https://m2.material.io/components/dialogs)里给的建议方向一致，动作按钮要写清楚动作本身。

微软的桌面界面指南在对话框控件那一页 (https://learn.microsoft.com/en-us/windows/apps/design/controls/dialogs-and-flyouts/dialogs)里也把这条写得很直白，按钮应当说明它执行什么，而不是简单地给出肯定与否定。

三份规范，三家公司，同一条建议：不要让用户在是与否之间做选择，让他在两个说清楚了的动作之间做选择。

三份规范还有一个共同的措辞值得注意：它们都不是说尽量避免，而是给出了替代写法。给替代写法比给禁令有用得多，因为执行的人不需要自己想办法。内容规范如果只写不许用是与否，落地率会低很多。

值得补一句的是，这三份规范讨论的场景跟常见问题区并不完全相同，它们管的是交互不是内容。搬过来的时候要搬那条判断原则，而不是照抄措辞。原则是让选项自带信息，落到答句上就是让每句答案自带事实。

## 它们绕开的正是同一个坑

为什么界面这一侧会先撞上这堵墙。

因为提示框里的问句极其频繁地带否定：不保存就退出吗、确定不再提醒吗。

而按钮上只有一个词的位置，装不下补全的主谓。

于是这个歧义在界面上是无处躲藏的，每一次本地化都会撞一遍。

软件界面的本地化是这个行业里最早工业化的一块，几十年下来，它把这个坑填掉了，填法就是取消是与否这两个选项本身。

界面这一侧还有一个客观条件推着它先解决：按钮上的文字要进本地化字符串表，每一条都被单独翻译过、单独测试过。这种逐条过筛的流程会把所有歧义暴露出来，而正文是整段翻译的，问题藏得住。

这个流程差异还解释了另一件事：为什么同一家公司的产品界面本地化质量往往明显高于帮助内容。不是投入不同，是流程结构不同。逐条过筛的东西质量天然更稳，整段流转的东西藏得住问题。

## 真正奇怪的是，知识没有跨过部门那道墙

到这里事情才有意思起来。

同一家公司里，做界面的人早就不用是与否了，写帮助文档和常见问题的人还在用。

不是因为后者不认同，是因为他们根本不读界面规范——那份文档在他们眼里属于设计资产，跟写作没关系。

于是同一个语言学问题，在一家公司的两个部门里得到了两种待遇。

解法早就存在，只是存在错了地方。这类事情比想象中多：某个坑被相邻的工种填过一遍，而填法从来没有往外传过一步。

这道墙还有一个可以量化的表现：去搜自己公司的内容规范，看里面有没有引用过界面规范。多数情况下一次都没有。两份文档服务同一批用户、约束同一种语言，却互不知道对方存在，这在稍大一点的组织里几乎是常态。

这道墙还有一个更实际的绕法：把界面规范里那一节直接复制进内容规范，注明出处。不要指望内容团队有一天会去读设计文档，也不要开会推动跨部门对齐。复制粘贴加一句出处说明，五分钟解决一件拖了很多年的事。

## 把按钮那套办法搬进答句

搬过来其实非常简单。

按钮的做法是用动词短语说明动作，答句的做法就是用完整句子说明事实。

不要写一个孤立的是，写拆封后仍然可以退货。

不要写一个孤立的否，写这一类商品不在退货范围内。

这么写之后，答句在任何一门语言里都不再依赖问句提供上下文，也就不存在被拆开之后翻转的可能。一句能独立成立的答案，才是能被安全抽走的答案。

搬过来之后还有一个额外收获：这样写的答案对不熟悉上下文的读者也更友好。有人从搜索结果直接落到这一条问答上，他没读过前面的内容，一个完整的答案句让他立刻拿到结论。可读性和抗拆解在这里恰好是同一件事。

这么写还有一个不太起眼的好处：答案句里会自然带上品类词和动作词，而不是一个信息量为零的字。同一段文字既解决了歧义又补上了关键词，这种一举两得在内容优化里其实不多见。

## 不懂那门语言，怎么把答反的句子找出来？

## 第一步：用机械规则先筛一遍

第一步完全不需要懂语言。

写一条规则：答句的第一句里如果只有表示肯定或否定的那个词、而没有别的实词，就标记出来。

各语言的那几个词就那么两三个，列一份清单即可。

这条规则筛出来的就是全部风险句，一个都跑不掉。

它的好处是完全不涉及语义判断，跑得快、可重复、能挂进发布流程。把一个语言学问题降级成一次字符串匹配，是这类排查里最值钱的一步。

这条规则还要注意一个细节：各语言表示肯定否定的词往往身兼数职，同一个字在别处可能是普通实词。所以规则要限定在答句的开头位置，而不是全文匹配，否则误报会多到没人愿意看。位置限定是这条规则能用的关键。

这条规则跑起来之后，第一次的结果通常会让人吃惊：命中的条数比预估的多一倍。多出来的那部分往往来自历史内容，是几年前不同的人按当时的习惯写的。这也说明这类问题会随时间积累，越早跑一次越省事。

## 第二步：把译文单独拿给一个没看过原文的人

第二步才需要人，但需要的不是审校员。

找一个母语者，只给他日语页面，不给他中文或英文原文。

然后问他一个事实问题：按这一页的说法，拆封之后到底能不能退。

他怎么答，用户就会怎么理解，这跟译文准不准完全是两回事。

审校员的职业训练是比对两份文本，而这里需要的是一个只读译文、只回答事实的人。角色换了，验收的性质也就换了。

这一步还可以做得更省事：把问题设计成选择题，只给两个选项让他勾。勾选比自由回答更快，也避免了他顺手替你解释译文。你要的是一个结论，不是一段分析，问法越封闭结果越干净。

如果找不到母语者，退一步的办法是找两个不同来源的翻译，各自把那段译文翻回来，看两个回译的结论一不一致。结论不一致就说明原译文有歧义。这个办法不如直接问人可靠，但在没有资源的时候能顶一阵。

## 第三步：把结论写回去，别只改那一句

第三步是收尾。

查出来的每一条，除了改掉，还要记下它是哪种句型触发的。

攒够十几条之后，你会发现它们高度集中在几个固定句型上，比如问不包含吗、问不支持吗、问不需要吗。

把这几个句型写进写作规范，比逐条修补有用得多。

这一步做完，这件事就从一次排查变成了一条不会复发的约束，后面新增的问答不会再产生同类问题。

写回规范的时候建议连同一个反例一起写。只写规则，读的人未必知道违反了会怎样；配一条真实的答反了的例子，规则的执行率会明显不同。这类例子从自己的排查记录里挑一条就有，不需要虚构。

这一步还有一个容易被跳过的动作：把新规则同步给外部的翻译供应商。很多问答内容是外包写的或者外包翻的，规范只留在自己团队里，下一批交付回来的稿子还是老样子。同步这件事只要一封邮件，却常常没人做。

## 三种改法里，哪一种最不容易被下一个人改回去？

## 改问句：干净，但会被改回来

第一种改法是把问句里的否定去掉。

拆封之后还能退吗，这样一问，两套体系的答案就一致了。

改完确实干净，问题也确实消失。

但这个改动活不长：下一个做内容优化的人会把它改回用户的原话，因为所有的写作建议都要求用用户的原话当问题。

他改回去的时候不会知道自己在恢复一个已经修好的缺陷，而且他做的完全是一件正确的事。

这类被改回去的修补还有一个共同点：它们在版本记录里看起来完全正常，是一次合理的内容优化。事后复盘的时候很难定位到底是哪一次改动引入了问题，因为每一次改动单独看都是对的。这也是为什么修补必须挂在规范上。

防止修补被撤销还有一个更机械的办法：在内容管理系统里给这几条问答加一个不可改动的标记，或者在注释里写清楚为什么这句话要这样写。注释的成本是一行字，而它能挡住的是一次无声的回退。

## 改答句：稍长，但站得住

第二种改法是保留问句，把答句写成完整的事实句。

问句照旧带否定，答案不再依赖那个字。

这个改动多写几个字，读起来还更清楚。

更重要的是它符合另一条通行规范：答案应当能独立成立。任何人接手都不会想把一句清楚完整的答案改回一个孤零零的字。

判据在这里：改动要落在一条本来就存在的规范上，它才不会被下一个人撤销。凡是只靠个人记忆维持的修补，都活不过一次人员变动。

这条判据还能推广开用。凡是你想在内容上长期维持的一个约束，先问一句：它跟哪一条已经被广泛接受的规范一致。找得到就把它写成那条规范的一个具体应用，找不到就得准备好每年重新解释一次为什么要这样写。

反过来说，如果一个改动怎么找都挂不上任何现成规范，那它多半需要一个专门的守护机制，比如自动检查或者代码级的约束。靠提醒和口头约定维持的改动，寿命通常不超过一次人员交接，这一点在内容侧和工程侧一样成立。

## 第三种是两头都改，留给最要紧的那几条

第三种是问句和答句一起改，再补一句限定条件。

它最稳，但也最啰嗦，会牺牲一点问句的匹配度。

所以它只留给那几条真正要命的：退货、保修、资格、收费。

这几条答错的代价是纠纷和退款，多写两句完全值得。

剩下的按第二种改法处理就够了，不必全站一刀切。

这四类之所以要两头都改，还有一个理由：它们是最可能被拿去当证据的四类内容。发生纠纷时用户会截图，客服会引用，平台会调取。一句能独立成立、不依赖上下文的答案，在这些场合下省下的解释成本远超过多写的那几个字。

这四类内容还建议单独维护一份清单，跟别的问答分开存放。它们的更新频率低、审核要求高、责任人明确，跟那些随时增删的一般问答不是一类资产。混在一起管理，迟早会被某次批量优化顺手改掉。

## 一份问答对的极性验收清单

## 三条硬规则，写进规范里

先立三条不许违反的。

第一条：答句的第一句必须能独立成立，不许只有一个表示肯定或否定的词。

第二条：凡是问句带否定的问答对，答句必须重述事实，不许靠问句提供上下文。

第三条：退货、保修、资格、收费这四类问答，问句和答句都要过一遍人工核对。

三条都不需要懂目标语言就能执行，也都能写进任何一份内容规范里。能被不懂那门语言的人执行，是这类规则能不能活下来的前提。

三条规则里最容易被打折扣的是第一条，因为它跟简洁这个写作直觉冲突。执行的时候可以给一个具体的下限，比如答句第一句至少要包含主语和谓语，这样它就从一个风格建议变成了一个可判定的条件。

三条规则还要配一句适用范围，说明它们只作用于问答型内容，不适用于正文和商品描述。不写清楚范围的规则会被过度执行，最后每一句话都被要求主谓齐全，读起来像法律条文。规则的边界跟规则本身一样重要。

## 上线前跑的三个检查

然后是上线前的动作。

第一个检查是机械筛：跑一遍那条字符串规则，看有没有孤立的肯定否定词。

第二个检查是抽样问：从带否定的问答里抽三条，找母语者只读译文回答事实问题。

第三个检查是结构核：确认答句在结构化数据里是完整的一段，没有被截断。

三个检查加起来不超过半小时，而且每次新增问答都值得重跑，因为这类问题是随内容增量产生的，不是一次性的。这一层的字段该怎么填，小语种结构化数据的三类字段 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)那篇给过分类办法。

三个检查还建议固定由不同的人做。机械筛可以交给工具或者实习生，抽样问必须找母语者，结构核归工程。分开之后没有任何一个人需要同时懂语言和懂技术，这是这套流程能在真实团队里跑起来的原因。

三个检查跑完之后建议留一份记录，写清楚这次查了多少条、标了多少条、改了多少条。这份记录最大的用处是在下一次内容大改之后，能让人一眼看出这项检查上次是什么时候跑的，而不是全凭记忆。

## 哪些事不归语言层，一句话交出去

最后划边界。

问答区该不该做、做多少条、能拿到什么位置，这些属于内容策略，跟本文无关。

各家答案引擎的展示规则差异，归引擎那一侧。

问句本身在不同语言里长什么样、疑问词会不会改写实词，这一层在小语种问答型长尾内容的价值判断 (https://zhangwenbao.com/minor-language-qa-long-tail-content-value-ai-era.html)那篇里讲过。

本文只管一件事：问句带否定的时候，那个表示是与否的字到底指向什么。

交出去的时候还要附一句：这几件事各自怎么做都行，唯一的硬要求是不要把答句的第一句和后面的事实句拆开。把边界写成一条可验证的约束，接手的人不必理解背后的语言学，照做就不会错。可读性口径那一类也是同样的处理方式，按英语标定的可读性分数在小语种上的失真 (https://zhangwenbao.com/minor-language-readability-score-english-calibrated-formula.html)那篇里给过同型的交接写法。

## 常见问题解答

## 我们只做欧洲语言，这一篇需要看吗？

需要，只是风险点不同。欧洲语言这一侧多数跟着事实走，彼此之间不会翻转，但德语和法语那两个专用词会带来另一个方向的麻烦：把它们翻成英语只能翻成一个是，翻的时候那层反驳的意味会丢掉，读者感受到的语气会变弱。

更实际的风险来自内容的中转。很多多语言项目是先把内容做成英语，再从英语分发到各语种。只要链条里有一门跟着问句走的语言，这个问题就会在那一环出现，跟你的主力市场在哪儿无关。判断办法就是看语言清单里有没有日语、韩语或者中文。判断办法很简单，看语言清单里有没有那三门语言。

## 机器翻译在这一点上表现如何？

比想象中差，而且差得很稳定。这类系统按句翻译，拿到的上下文往往只有当前这一句，而判断该用哪个字恰恰需要前一句那个问句。给它整段一起翻会好一些，但常见问题区的数据结构天生是分字段存的，问和答本来就不在一起。

更麻烦的是它错得很自信，译文流畅自然，没有任何可疑之处。所以不要指望通过提高翻译质量来解决这件事，正确的做法是从源头上不写那种依赖上下文的答句。源头改了，用什么工具翻都不会错。源头改对之后，这件事对翻译工具的依赖就降到了零。

## 用结构化数据把问答标起来，能不能解决？

不能，标记解决的是机器认不认得出这是一组问答，不解决答案本身对不对。标记做得越标准，这一对问答被完整取走并且展示出去的概率越高，答错的传播范围反而更大。

标记在这件事上唯一的作用是让你能批量把所有问答对导出来做检查，这一点确实有用。所以该标还是要标，只是别把它当成质量保障。真正的保障在答句怎么写，不在它被怎么标。标记的价值在于让你能批量导出来检查，仅此而已。

## 能不能干脆禁止在问答区使用否定问句？

技术上可以，实际上不划算。用户搜索时打的就是带否定的问法，禁掉否定问句等于放弃这批查询的匹配度。这类问句往往还处在决策链条的末端，价值很高。

更稳妥的做法是保留问句、约束答句。约束答句的成本几乎为零，还顺带提升了可读性；而禁用问句的成本是实打实的流量。两相比较，选择很明显。只有一种情况值得考虑禁用，就是那种同一个页面上堆了十几条否定问句的模板化问答，那种问答本身质量就有问题。模板化堆出来的十几条否定问句，本身就该重写。

## 这个问题会不会随着模型变强自己消失？

不会，因为它不是理解能力问题。模型完全知道这两套体系的差别，问题在于它拿到的输入里可能根本没有问句。一个孤立的答句在任何模型看来都毫无异常，它没有任何信息可以推断出这句话依赖着一个带否定的上文。

换句话说，这是信息在传递过程中丢失，不是接收方能力不足。只要抽取环节仍然可能把问和答分开处理，这个风险就一直在。唯一能根治的办法在你这一侧：让每一句答案自带足够的信息。能根治的位置只有一处，就是让每句答案自带信息。

## 中文站需要注意这件事吗？

需要，而且很多人没意识到。中文的回答同样跟着问句走，这一点跟日语韩语一致。做中文内容的时候之所以感觉不到，是因为写的人和读的人用的是同一套规则，从来不会错位。

一旦要把中文内容翻成英语，或者拿中文内容去对照英文原版核对，这个问题立刻出现。跨境团队里最常见的形态是：中文版和英文版对同一条政策给出了相反的表述，两边各自都没错，错在中间那次转换。所以中文站真正需要注意的时机是内容跨语言流动的那一刻。跨语言流动的那一刻，才是中文站真正的风险点。

## 这件事该排在优先级的哪一档？

如果你有面向消费者的问答区，并且语言清单里有跟着问句走的语言，它应该排得相当靠前，因为排查成本极低而单条价值极高。整件事的工作量是一条字符串规则加上三条抽样核对，半天足够。

如果你的问答区只有几条、或者语言清单里全是跟着事实走的语言，那把三条硬规则写进规范就行，不必专门排期。判断自己属于哪一种，只要数一遍带否定的问句有几条，十分钟就有答案。数一遍带否定的问句有几条，十分钟就能定优先级。

## 权威参考资料



## 有些商品在这门语言里根本没有单数，可你的模板第一步就是取单数

- URL：https://zhangwenbao.com/minor-language-plurale-tantum-category-keyword.html
- 分类：小语种SEO
- 发布：2025-11-19  |  更新：2026-07-30
- 摘要：护目镜在波兰语里只有复数、在德语里只有单数、在匈牙利语里连一双鞋都算单数。讲清词干还原为什么会还原成另一个真词、标题模板崩在哪一步、没有词典的语言怎么查。
- 关键词：关键词研究,多语言SEO,内容本地化,小语种SEO

> **TLDR**：摘要：词表和标题模板都默认每个名词有一个单数基本形，需要时再加复数。可每门语言里都有一批词只有复数形态，而且各语言里这批词并不重合，它还恰好压在成对用品、工具、衣物这些最日常的品类上。同一副护目镜，波兰语只有复数，德语只有单数，匈牙利语连一双鞋都算单数，中文根本没有这个维度。麻烦的是词干还原在这批词上不会失败，它会还原成另一个真实存在的词，于是全链路没有一处报错。本文给出识别办法、词表加一列的做法与两天能跑完的清查。

> 摘要：词表和标题模板都默认每个名词有一个单数基本形，需要时再加复数。可每门语言里都有一批词只有复数形态，而且各语言里这批词并不重合，它还恰好压在成对用品、工具、衣物这些最日常的品类上。同一副护目镜，波兰语只有复数，德语只有单数，匈牙利语连一双鞋都算单数，中文根本没有这个维度。麻烦的是词干还原在这批词上不会失败，它会还原成另一个真实存在的词，于是全链路没有一处报错。本文给出识别办法、词表加一列的做法与两天能跑完的清查。

## 你的商品目录里，为什么会有一批词连单数都造不出来？

## 一家运动户外站的波兰语页面，标题上写着一条裤子的一半

有个客户做运动户外，滑雪护目镜、冲锋裤、抓绒手套、登山袜这几条线。

德语站跑了三年，数据稳定，团队照着同一套模板把波兰语站铺了出去。

模板没改，翻译请的是本地写手，商品数据从同一个库里出，看起来一切都对。

上线四个月，波兰站的品类页表现明显不如德语站，而两边的商品和价格是一样的。

保哥翻商品页的时候在标题上停住了：护目镜那个品类的标题里，波兰语词被模板削掉了一截，削出来的那个形态在波兰语里不存在。

更麻烦的是筛选结果那句提示，写的是找到1件商品，而那个品类词在波兰语里压根没有单数形态可以配这个1。当地用户读到的是一句谁都能看出不对、但又说不上哪里不对的话。

被削掉的那个形态还进了标题标签，也就是说搜索结果里显示的就是这个不存在的词。团队之前做过一次标题审计，审的是长度和关键词位置，没有人审过词形本身合不合法。

## 这批词有名字，而且被正经标注过

它不是特例，也不是写手的疏忽，语言学上早就有一个专门的名字。

通用依存标注体系在数这个特征下面列了一个专门的取值，叫作只有复数。

它的定义写得很直白：有些名词只以复数形式出现，哪怕它指的是一样东西。

换句话说，语义上是单数，形态上只有复数，两者对不上是这类词的常态。

这一条对做站的人有个很实际的含义：既然标注体系专门留了一个取值给它，说明它在多门语言里都成规模出现，不是一两个孤例。凡是能被标进特征表的东西，就能被批量识别，也就能被批量处理。

这个特征下面还有一个对称的取值，专门标只有单数的词。两个取值一起看，说明标注体系承认名词的数范畴可以缺一头，缺哪一头都算一种类型，而不是一种错误。

对做站的人来说，能被标进特征表还有一个更实际的含义：凡是有标注的地方就有现成数据可查，不必从零开始判断。后面讲到怎么找出这批词的时候，用的正是这批数据。

顺带提醒一句，这个取值在标注体系里的存在也解释了为什么各家工具的处理不一致：它是一个可选特征，标不标由各语言的标注团队决定。所以同一个工具在两门语言上的表现可以差很多，不是工具的问题，是数据的问题。

## 为什么它恰好扎堆在最日常的实物品类上

这批词的分布一点都不随机。

成对出现的东西占一大块，护目镜、眼镜、手套、袜子、耳机。

由两片合起来才能用的工具占一块，剪刀、钳子、镊子。

下半身穿的衣物占一块，裤子、短裤、连体裤。

再加上一批不成对但习惯上按整体说的东西，比如门、行李、假期。

把这几类摊开看会发现一件不太舒服的事：它们全是电商目录里最常见的实物品类，不是边缘长尾。也就是说，这个问题不出现在你的第一千个SKU上，它出现在你的第一个。

还有一件事值得注意：这批词在语料的词频表里位置很靠前，属于高频区，不是长尾。高频意味着它们同时出现在标题、面包屑、筛选器、结构化数据和商品数据里，一个词错了会同时错在五个位置。

## 同一副护目镜，五门语言给出五个答案

把同一样东西放进几门语言里对着看，差别大到有点滑稽。

波兰语的护目镜只有复数形态，想写一副得靠量词短语绕。

德语的眼镜反过来，标准形态是单数，一副就是一个词。

英语跟波兰语一边，只有复数。

匈牙利语走得更远，成对的东西一律按单数处理，一双鞋在语法上就是一只鞋的说法，因为一双被当成一个整体。

中文这边最省事，压根没有数这个语法维度，一副护目镜和三副护目镜里名词一个字都不用改。五门语言五种答案，而你的商品库里给这个品类只留了一个字段。匈牙利语那十八个格 (https://zhangwenbao.com/hungarian-seo-eighteen-cases-vowel-harmony-keyword.html)已经够让人头疼了，成对物品按单数算这一条还要再单独记一次。

芬兰语跟波兰语站在同一边，剪刀和裤子都只有复数形态。把这五门语言的答案并排放，能得出一条很实用的结论：跨语言复用同一张品类词表时，这一列一定要重新填，不能继承。

继承是这类错误最常见的来源。新市场上线时，团队通常从现有语言的词表复制一份再翻译，形态这一类属性会被原样带过去，而它恰恰是最不该继承的一列。

## 词干还原碰上这批词，为什么不是失败而是还原成功了但还错了？

## 还原器的工作前提是每个词都有一个基本形

词干还原这一步的目标很朴素：把一个词的各种形态收敛到同一个键上。

它的实现方式多数是规则加词尾表，遇到某个结尾就削掉，遇到某个结尾就替换。

这套做法能成立，靠的是一个从来没被写进文档的前提：每个名词都有一个可以被还原到的基本形。

对绝大多数词这个前提成立，对只有复数的词它不成立。

规则并不知道这一点，它照样削，削完之后照样返回一个字符串，也照样不报错。

多数实现其实留了口子，允许你配一份不参与还原的保护词表。这个功能通常是为品牌名和型号准备的，但它同样适用于这批词，而且是最省事的一种用法。

## 最坏的一种情形是还原出来的那个词真的存在

如果削出来的是一串没有意义的字母，问题反而容易发现。

真正难查的是削出来的那个形态在这门语言里确实存在，只是意思完全不同。

俄语的眼镜是一个只有复数的词，按常规规则削掉词尾之后，得到的是一个真实存在的名词，意思跟点数和小孔有关，跟眼镜没有半点关系。

于是索引里这个品类被并进了一个毫不相干的语义堆里，而所有校验都会通过，因为那确实是一个合法的俄语词。

这一类错误跟本站讲过的无糖和含糖被词干还原并成一个 (https://zhangwenbao.com/minor-language-negation-affix-exclusion-keyword-trap.html)是同一个家族，区别在于那一类并的是两个真实词，这一类是把一个真实词并进了一个跟它毫无关系的词底下。

换个说法：那种错至少还留着一半线索，这种错连线索都没有，因为参与合并的两个词在字符串上完全说得通。

把这一类捞出来的办法不难：把品类词表整体跑一遍还原，只留下输出跟输入不同的那些行，再请母语者看一眼输出的那个词是什么意思。几百行的词表通常只有十几行会变，一眼就能扫完。

扫的时候重点看两类：输出的词在这门语言里存在但意思无关的，以及输出的词看着像词但母语者说没这个词的。前者危险，后者只是噪声。

## 这类错误为什么在任何日志里都留不下痕迹

软件工程里绝大多数错误会以异常的形式冒出来。

还原这一步不会，它的输出永远是一个字符串，永远返回成功。

索引侧不会报错，因为它收到的是合法输入。

查询侧也不会报错，因为它同样按规则处理了用户打进来的词。

最后表现出来的只是这个品类的站内搜索结果不太对、推荐位挂的商品有点怪、报表上这一类词的表现偏低。三个症状分属三个团队，没有一个会往字符层去找根因。

三个症状分属三个团队这件事值得展开一句：站内搜索归产品或者前端，推荐位归算法或者运营，关键词报表归检索这一侧。三方各自看到的都是一个可以忍受的小偏差，没有人手里有拼出全貌的那块。

## 词干算法的公开清单，本身就是一份哪些语言有人管的名单

做这件事之前有个便宜动作：去看一眼公开的词干算法项目收了哪些语言。

那份词干算法清单 (https://snowballstem.org/algorithms/)上大约三十门语言，覆盖了主要的欧洲语族。

值得留意的是它没有收哪些：日语、韩语、越南语、泰语、乌克兰语、希伯来语、波斯语都不在上面。

这不是项目做得不好，是这些语言的形态处理路子跟词尾削减不是一回事。

但对做站的人来说结论很直接：你要开的市场里有相当一部分，连一个公开的词干算法都没有，而你的站内搜索、你的推荐模块、你的关键词去重脚本，默认用的就是这份清单里有的那些。清单上没有的语言，你的系统多半是拿英语那套在硬凑。

清单上还有几个意外的条目，比如世界语和几门使用人口不多的语言，说明它是社区贡献驱动的，收录与否跟市场规模没有稳定关系。所以别拿商业重要性去推断某门语言有没有工具。

清单上没有你的目标语言时，值得花十分钟确认一下你的搜索引擎和站内搜索在这门语言上到底做了什么。常见答案有三种：完全不做处理、套用一个近亲语言的规则、或者退回按空格切分。三种的应对方式完全不同。

还有一种情况要留意：某门语言在清单上，不等于那套算法对你的品类有效。词干算法多数是拿通用文本调出来的，商品名里大量出现的品牌、型号、外来词，它未必处理得好。清单只能回答有没有，回答不了好不好。

## 关键词表按什么形态记这批词，才不会两头落空？

## 词表的默认列结构假设了单数是主键

多数团队的关键词表长得差不多：一列词、一列月搜索量、一列难度、一列意图。

那一列词填的是什么形态，通常没人规定，实际填的多半是词典原形。

而词典原形对绝大多数名词就是单数。

这个默认在英语站上从来不出事，因为英语的单数复数差一个字母，工具会替你合并。

到了形态丰富的语言上，这个默认会连锁出一串问题，本站在波兰语那七个格 (https://zhangwenbao.com/polish-seo-seven-cases-diacritics-keyword-research.html)那篇里已经拆过一次，只有复数这批词是同一条链上更靠前的一环：连原形这个概念在这里都得重新定义。

还有一个连带影响在搜索量那一列上。关键词工具通常会把若干形态的量聚合起来报一个数，聚合规则不透明。对只有复数的词，聚合的对象里可能混进了那个被还原出来的无关词，于是这个数偏高。

## 给词表加一列数范畴，跟当年给缩略语加类型列是同一套动作

解法不复杂，就是在词表上加一列，标这个词的数范畴。

取值只要三个：只有复数、只有单数、正常可数。

这一列的成本接近于零，一个品类词表通常几百行，母语者半天能标完。

收益是后面所有批量脚本都能按这一列分支，而不是一刀切。

本站在缩略语那一批全英文的词 (https://zhangwenbao.com/minor-language-acronym-initialism-local-forms-inflection.html)里用过完全一样的思路：把语言学上已经想清楚的分类直接搬进词表，当成一个独立的词层特征，别指望脚本靠字符串长相去猜。

这一列建议同时放两处：词表里一份给内容和检索团队看，商品数据字段里一份给模板和下游系统读。两处的消费者不同，只放一处必然有一边读不到。

## 三个取值怎么判，判据要能交给不懂检索的人

标注这一列不需要语言学训练，只要一条能执行的判据。

问母语者一句话就够：这个东西只有一个的时候，这个词长什么样。

如果他给出的形态跟多个的时候一样，那就是只有复数。

如果他说这个词根本不分多少，那多半是只有单数或者不可数。

剩下的才是正常可数。这个问法的好处是它不需要对方懂什么叫数范畴，也不需要你懂那门语言，双方在同一个具体的东西上对齐就行。母语审校那一关 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)最怕的就是问一句读着顺不顺，换成这种指着实物问形态的问法，答案立刻变得可验收。

如果对方不好意思说不知道，还有第二个问法：给他三件实物的图片，请他写一句说明这里有三件。他写出来的句子里名词长什么样，跟前一个问题的答案一对照，答案就闭合了。

标注的时候顺手记一件事：这个词有没有一个日常用的量词短语。有的话把那个短语一并记下来，它在写标题和筛选提示的时候立刻能用上，省掉一次回头再问。

## 标完之后哪几个脚本要改分支

这一列标完不改代码等于白标，要改的地方不多但要改全。

第一是词表去重脚本，只有复数的词禁止参与形态归并。

第二是标题模板，遇到这一列取值为只有复数的品类，跳过单数槽位。

第三是站内搜索的索引配置，把这批词加进不做还原的保护词表。

第四是商品数据同步，导出给下游的那份也要带上这一列，否则平台侧和数据源侧还是会各自还原一次。改动都在配置层，没有一处需要动业务逻辑。

还有第五处容易漏：导出给比价平台、广告平台和渠道方的那几张数据表。这些出口一旦漏掉，改过的形态会被外部系统按旧值同步回来，几个月后又冒出来。

## 用户在搜索框里打的到底是哪个形态？

## 这批词的搜索侧其实比想象中干净

讲到这里有个反直觉的好消息。

只有复数的词在搜索侧的形态分叉比普通名词少得多。

原因很简单：没有单数形态可以打，用户没得选。

普通名词至少要在单数和复数之间分流量，这批词天然集中在一个形态上。

所以真正需要纠结的不是主词怎么写，而是它前后跟着的那些成分。

这带来一个可以量化的附带好处：这类品类的关键词表行数明显少于同规模的普通品类。做词表预算的时候可以按这一列打折，省下来的行数配额留给别的品类。

## 真正分叉的是它前面那个数量说法

用户想买一副护目镜的时候，搜索框里打的很可能不止品类词。

带数量的查询在这类品类上占比不低，尤其是成对出售的品类。

而数量说法在各语言里的写法差得很开，有的靠量词短语，有的靠专门的成对量词。

这批说法多数不在你的词表里，因为词表是按品类词建的。

补的办法不是硬造，是去看搜索建议：在目标语言的搜索框里打出品类词，把下拉里带数量成分的那几条抄下来，通常十分钟能抄出七八条真实说法，比翻词典靠谱得多。

抄下来之后建议按三类归档：带纯数字的、带量词短语的、带专门成对量词的。三类在页面上的落位不一样，第一类适合放筛选结果提示，第二类适合放商品标题，第三类多数只适合放正文。

## 量词与品类词的搭配在各语言里不是同一件事

成对物品的量词是这批词最容易出洋相的地方。

英语要一个专门的成对量词才能给复数名词计数。

波兰语用另一套结构，而且这个结构还会牵动后面名词的格。

德语因为本来就是单数，直接用普通数词就行，一个词都不用加。

匈牙利语最省事，数词后面名词干脆不变复数。四门语言四种拼法，如果标题模板打算统一处理，那它注定在其中三门语言上是错的。

匈牙利语那条还有个连带后果：数词后面名词不变复数，意味着模板里那个复数分支在这门语言的这类品类上永远不该被触发。如果日志里发现它被触发过，那说明模板走错了分支，值得追一下。

## 半小时能把这批词的搜索侧验一遍

验证不需要工具授权，也不需要花钱。

把圈出来的品类词逐个丢进目标语言的搜索框，看下拉建议给出什么形态。

下拉给的形态就是真实用户在打的形态，它比任何词典权威。

再把这个形态丢回搜索框，看结果页第一屏是不是本品类的商品页。

是的话这个词就定死，写进词表的形态列。二十个品类词跑完不到半小时，而这半小时省掉的是后面几个月的形态争论。小语种关键词工具返回零的时候 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)用的也是这一路办法，只是那边解决的是有没有量，这边解决的是形态对不对。

记录格式建议固定成四列：品类词、验证到的形态、下拉建议原文、验证日期。第三列留原文是关键，半年后复核时能直接看出当时是照着什么下的判断，而不是只剩一个结论。

## 标题模板里那个数量前缀，会崩在哪一步？

## 模板的槽位假设了名词能跟着数字变

品类页和筛选结果页的标题通常是拼出来的。

常见结构是数字加品类词加修饰语，比如多少件某某商品。

这个结构成立的前提是名词能根据前面那个数字变形。

只有复数的词没有可变的那一头，数字是1的时候找不到对应形态。

模板不会因此报错，它会拿手上有的那个形态硬填，填出来的句子在母语者眼里是明确的语病。

同一套模板通常还负责筛选结果页和分页标题，所以一处崩就是三类页面一起崩。这三类页面恰好是品类流量的主要承载者，损失面比看上去大。

## 复数规则表里没有给这批词准备分支

处理这类拼句的标准做法是用国际化组件的复数规则。

规则按语言给出若干个类别，波兰语和俄语这类语言的类别比英语多。

模板写的时候要给每个类别各写一句话，组件在运行时按数字挑一句。

问题在于只有复数的词根本用不到数量为1的那个分支，可模板还是要求你把它填上。

多数人会照着别的品类填一个，于是这个分支里躺着一个不存在的词形，只等某个筛选条件恰好只剩一件商品的时候露出来。本站在界面文案那批没进翻译文件的字 (https://zhangwenbao.com/minor-language-hardcoded-ui-strings-pseudo-localization.html)里讲过这套组件怎么用，那边的问题是句子没被抽出来，这边的问题是句子抽出来了但有一个分支填不了。

各语言要写几个分支差别很大：英语和德语两个就够，波兰语和俄语要四个，阿拉伯语更多，中文只要一个。模板的复杂度不是由你的功能决定的，是由你要上的语言决定的。

只有复数的词让最难写的那个分支变成了死代码：它永远不会被执行，可组件仍然要求你填。这一格填什么没有正确答案，务实的做法是填一句不带数字的说法，让它就算被触发也不出病句。

## 崩掉之后的三种表现，只有一种看得出来

把后果拆开看，一共三种。

第一种是页面上直接出现病句，这种最容易发现，因为本地用户会截图来问。

第二种是模板输出的形态跟用户搜的形态对不上，这一种只表现为排名偏低。

第三种最隐蔽：模板输出的那个不存在的形态被当成有效词写进了页面标题，然后被抓进索引，成为这个页面的主词。

第三种的排查成本最高，因为从后台看一切正常，只有把标题标签逐条导出来对着母语词表比才看得见。

第三种的排查办法是把全站标题标签导出来，跟母语词表做一次字符串比对，只看这批品类的行。几千条标题跑一次不到十分钟，产出的是一份可以直接派活的清单。

还有一个容易忽略的暴露点：结构化数据里的名称字段多半也从同一套模板取值。所以模板崩掉的时候，页面上和给机器看的位置是同时崩的，只是后者没有人会去读。

## 最省事的解法是把数量前缀从这批品类上撤掉

这一段给一个不太体面但很有效的建议。

如果只有一两个品类踩这个坑，专门为它们写规则不划算。

更省事的做法是给这批品类的标题模板换一个不带数量的版本。

标题里少一个数字，检索上的损失基本可以忽略，因为数量成分本来就不承载多少检索价值。

而换掉之后，整条崩溃链一次性断掉。这是那种典型的用版面决定绕开语法决定的做法，本站在屈折语站的锚文本 (https://zhangwenbao.com/minor-language-internal-link-anchor-inflection-variants.html)那篇里也用过一次：把需要精确形态的内容挪到不需要变形的位置去，比在原地跟语法较劲省力得多。

有一类品类不能撤：数量本身是卖点的，比如成套餐具、多件装的袜子。这类品类的用户就是在比几件装，撤掉数字等于撤掉卖点。这时候只能老老实实为它写规则，或者换一个不依赖名词变形的表达结构。

## 站内搜索与筛选器，会在这批词上出什么岔子？

## 索引侧和查询侧用的不是同一个还原器时

站内搜索出问题最常见的根因不是还原错了，是两边还原得不一样。

索引侧建库时用一套配置，查询侧解析用户输入时用另一套。

两边都正常工作，两边给出的键不一样，于是永远匹配不上。

只有复数的词特别容易触发这种不一致，因为它是规则表里的边缘情形，不同版本的实现对它的处理经常不同。

排查办法很直接：拿这批词在两侧各跑一次，把输出的键打印出来对着看。不一致的那几条就是问题所在，通常不超过五条。

还有一个容易忽略的触发时机：组件版本升级。同一个还原器的不同版本对边缘情形的处理经常不同，而索引是几个月前建的、查询用的是刚升级的版本。所以这类组件的版本值得锁死并记录。

## 筛选器的分类名和商品名会在这批词上撞车

分类名习惯上用复数，因为它指的是一类东西。

商品名习惯上用单数，因为它指的是具体一件。

这个约定在只有复数的品类上直接失效，两者写出来一模一样。

后果是面包屑上的分类名和商品标题看着重复，页面读起来像少了一层。

更实际的影响在结构化数据那一侧：分类页和商品页的名称字段取值相同，机器读到的层级信息就变薄了一层。属性枚举值那件事 (https://zhangwenbao.com/minor-language-color-category-attribute-value.html)讲过面向机器的字段该怎么取值，这里是同一条原则在名称字段上的应用。

面包屑那一处有个简单的解法：给分类名加一个限定词，比如按用途或者场景加一个前置修饰。这样分类层和商品层在字面上就区分开了，也不需要改任何模板逻辑。

## 同义词表该给这批词写什么条目

站内搜索的同义词表是收拾这类问题最省事的地方。

给这批词写条目的原则是把用户可能打出来的所有形态都映射到同一个键上。

包括那个由还原器造出来的、语言里其实不存在的形态。

这一条听起来别扭，但它挡住的是自己系统制造出来的噪声。

同义词表的好处是它不对外展示，不会被当成堆砌，改起来也不需要发版。本站反复讲过这个位置是匹配层唯一安全的收纳处，只有复数这批词正好是它的典型用户。

还有个细节要定：条目写成单向还是双向。把错形态映射到真实形态用单向就够，反向不需要，否则会把正常查询也带偏。多数站内搜索组件默认是双向，需要显式改。

## 一个能当天跑完的对照测试

验证方案很土：准备一张两列的表。

左列是这批品类词的真实形态，右列是还原器给出的形态。

两列各在站内搜索里跑一次，人工看前十条结果有几条对得上。

右列返回的结果如果跟左列差很多，说明查询侧在做还原而索引侧没有，或者反过来。

二十个词跑完不到两小时，产出的是一个能直接汇报的数字，而不是一句感觉不太对。

判读标准建议先定死：前十条里有八条以上属于本品类算通过，五到七条算可疑，五条以下算不通过。不先定标准，跑完之后一定会陷入这算不算对的争论。

## 结构化数据和平台字段里，这批词该填哪个形态？

## 面向机器的字段不承担语感，但它承担一致性

结构化数据的名称字段是给机器读的，不需要读起来像人话。

但它需要跟页面上可见的那个形态保持一致。

只有复数的词在这里反而最省心：因为只有一个形态，不存在选哪个的问题。

真正要小心的是那些自动生成的字段，它们经常从商品名里截一段，截的时候顺手做一次还原。

这一截就把不存在的形态写进了给机器看的位置。本站在结构化数据要反着写回国际格式 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)那篇里讲过面向人和面向机器的位置该分开优化，这里要补一句：分开优化不等于分开生成，两边的名词形态必须来自同一个字段。

自动生成的字段最常见的来源是截取商品名的前若干个字，或者从分类路径拼一段。两种来源都有可能在中间插一次还原，接入时值得逐个确认一遍它有没有做这件事。

## 平台侧的语言处理能力比网页侧弱一档

把商品放上第三方平台的时候，这批词的问题会重演一次，而且更难查。

平台侧的搜索多数不做词形还原，也不做复合词拆分。

好处是它不会替你还原出一个错的形态。

坏处是它也不会替你把不同形态合并，你填什么它就按什么匹配。

结论是平台侧的策略跟网站侧正好相反，本站在平台搜索词字段那笔字节账 (https://zhangwenbao.com/minor-language-marketplace-listing-fields-tokenization.html)里算过这笔账：网站侧要收敛，平台侧要铺开。只有复数的词在平台侧反而是最好处理的一类，因为它本来就只有一个形态可铺。

平台侧还有一个反向风险：它的自动补全会把你填过的形态固化下来。你填错一次，这个错形态会作为候选出现在用户面前，被点击之后进一步被加强，最后变成一个你自己造出来的搜索词。

## 变体商品的标题继承会把错误形态复制到全站

变体商品是这类错误的放大器。

同一款护目镜有五种镜片颜色，多数系统会让变体继承主商品的标题结构。

主商品那条如果用了还原出来的错形态，五条变体全部照抄。

一个品类几十个SKU，几百条标题里同一个错误形态整齐地重复。

这时候看报表会得到一个很误导的信号：这个错误形态的展现量看起来很高，因为它出现在几百个页面上。展现量高不等于有人搜，它只说明你自己写了很多遍。

定位这类问题的办法是从模板反查而不是从页面反查：找出所有使用同一套标题模板的商品，按品类分组，只抽查每组的第一条。模板对了整组都对，模板错了整组都错，抽查一条就够。

## 别名类字段能放多个值，但不该乱放

结构化数据里有几个字段允许放多个取值，是收纳形态变体的好位置。

可以把品类词的真实形态和常见的口语说法一并放进去。

不该放的是那个由还原器造出来的形态，它不是一种说法，它是一个事故。

放进去的每个值都在向机器声明这是同一个东西，塞进不存在的词只会稀释这个声明。

判断标准很简单：这个形态有没有真实用户打过。搜索建议里出现过的可以放，只在你自己日志里出现过的不要放。

把这条判断操作化：搜索建议里出现过的可以放，站内搜索日志里被真实用户打过三次以上的可以放，只在你自己系统的输出里出现过的一律不放。第三类正是还原器造出来的那批。

## 集合名词是另一半，它的麻烦不在形态在计数

## 只有复数和集合名词是两件不同的事

这两类词经常被放在一起说，但它们的机制不一样。

只有复数的词是形态上缺了一头，语义上指的可能就是一件。

集合名词是形态上是单数，语义上指的是一堆。

家具、行李、首饰、餐具都属于后者。

做站的时候前者卡在词形，后者卡在计数：用户想买一件，而你的词表里那个词指的是一批。

还有第三类容易混进来的：不可数的物质名词，比如洗涤剂、油、纤维。它跟集合名词的区别在于它连一个整体都不指，只指一种东西。这一类在电商里靠包装规格来计数，处理方式又不一样。

## 库存单位怎么写才不会跟用户对不上

集合名词最直接的麻烦在库存和购物车。

德语的家具是一个集合概念，说一件家具要用一个专门的组合说法。

商品页上如果直接用那个集合词加数量，读起来像是在卖一整套。

解法是在这类品类上把上位词换成具体的下位词，卖的是椅子就写椅子。

上位词留给分类页和面包屑，它在那儿是对的；商品页要的是能被一件一件数出来的词。当年拿词典逐词换出来的那批词 (https://zhangwenbao.com/keyword-literal-translation-legacy-cost-non-english.html)里，上位词错位是最常见的一类，因为词典给的往往正是那个集合形态。

购物车行和结算页是这一类词最后暴露的地方。列表页可以只写品类名蒙混过去，购物车必须写数量加单位，一旦写成集合词加数字，读起来就是买了三批而不是三件。上线前把这两页按语言各看一遍。

## 谓语一致那一层对检索的影响其实很小

讲集合名词绕不开谓语一致的话题，但这里要泼一盆冷水。

集合名词后面的动词该用单数还是复数，各语言各有习惯，英式和美式甚至相反。

这件事对读感有影响，对检索基本没有影响。

原因是查询串里几乎不带谓语，用户搜的是名词短语。

所以这一层交给母语写手按语感处理就行，不必写进技术规范，也不值得为它单开一次审校。把有限的审校预算花在名词形态上，回报高得多。

有一个例外值得留意：问答型的长尾查询里会出现完整句子，这时谓语就进了查询串。如果你的品类有大量这类长尾，那么这一层值得在正文里顺着当地习惯写，但仍然不必写进技术规范。

## 什么时候该把集合名词整个换掉

有一种情况值得动刀：这个集合词的搜索量明显低于它下面的具体词之和。

这通常意味着当地用户不拿这个层级说话。

判断办法是把集合词和三到五个下位词一起拉一遍量，看分布。

如果集合词只占两成以下，就把它从主词位置上撤下来，让位给下位词。

撤下来不等于删掉，它还可以留在导航和面包屑里承担结构角色。这跟两个市场的关键词表可以一字不差 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)那篇的结论是配套的：词表能共用，落地页的层级安排未必能共用。

撤下来之后要顺手处理内链。原来指向集合词页面的锚文本要跟着改，否则会出现锚文本说的是上位词、目标页讲的是下位词的错配。改的量通常不大，但漏掉会让整块内链的相关性打折。

还有一个信号可以一起看：这个集合词在站内搜索里的零结果率。如果用户拿它来搜却搜不到东西，说明你的商品数据里根本没有按这个层级组织过，那它在页面上出现得越多越误导。

## 没有词典也没有语料的语言，这批词该怎么找出来？

## 先从自己的目录里捞，别从语言学清单里捞

网上能找到的只有复数词清单通常是按语言编的，动辄几百条。

照着那种清单一条条查，多数条目跟你的生意没有关系。

更省事的方向是反过来：先把自己目录里的品类词列出来，再逐条问它属不属于这一类。

一个中型独立站的品类词通常在两三百条以内，命中的一般不超过二十条。

二十条是一个人一个下午能处理完的量，而按语言学清单查要花掉一周还查不全你真正需要的那些。

按中文品类过一遍就行，这一点值得解释：成对用品、两片合起来用的工具、下半身衣物这几类在多数语言里是重合的，中文虽然没有数范畴，但品类的物理属性是一样的。所以中文清单能当筛子用。

## 三条免费路径，各自能查到什么

没有母语顾问的时候，有三条路可以走。

第一条是形态标注数据集，通用形态标注项目 (https://unimorph.github.io/)按语言给出词形表，能直接看到某个词有没有单数形态。

第二条是大型语料库的词频界面，莱比锡语料库 (https://wortschatz.uni-leipzig.de/en)覆盖的语种很多，查一个词的实际出现形态足够用。

第三条是当地的权威词典，德语这边的假期词条 (https://www.dwds.de/wb/Ferien)就直接标着只用复数，这类标注在成熟词典里是标配。

三条路的共同点是免费、不需要授权、查一个词都在一分钟以内。缺点是它们对低资源语言的覆盖会断档，断档的时候只能靠人。

三条路各有断档：形态数据集在低资源语言上覆盖不全，语料库如果主要由法律和新闻文本构成，对消费品类的判断会有系统性偏差，词典的更新速度跟不上新品类。查之前先看一眼这三项说明。

## 母语审校那一关该怎么问才问得出来

把稿子丢给母语者问一句有没有问题，多半得到的回答是没问题。

因为在他眼里，正确的形态本来就是唯一的形态，他不会觉得这里有个选择。

要问出东西来，得把问题换成填空题。

给他一句带数字1的句子，让他把品类词填进去，看他怎么处理。

他如果绕开了数字，改用一个量词短语，那就说明这个词确实没有单数，答案就出来了。这一招的价值在于它不依赖对方懂语法术语，只依赖他会说这门语言。

还有一种情况要留意：有些词在书面语里勉强能造出单数，母语者也能接受，但日常没人这么说。这时候他会给你一个形态，而这个形态在搜索侧几乎零量。所以问完形态之后一定要再跑一次搜索建议验证。

## 查出来之后一定要留档，因为它几年不变

这批词有一个很好的性质：它极其稳定。

颜色范畴会随流行走，代际用词会变，可一个名词有没有单数形态，几十年不动。

也就是说这次的投入是一次性的，往后开新品类只需要增量维护。

留档的形式建议直接落在词表那一列上，而不是另开一个文档。

另开文档的下场是三个月后没人记得它在哪儿，落在词表列上则会被后续每一次批量操作自动读到。

字段命名建议直接叫数范畴或者词形类别，别叫特殊词标记这类含糊的名字。含糊的名字会在半年后被别人拿去装别的东西，一年后这一列就变成了什么都有的杂物间。

## 把这件事收成一张两天能做完的表

## 第一天上午：从目录里圈出候选品类

第一步是把商品目录按品类导出来，只要品类名这一列。

然后按前面那几个类别过一遍：成对的、两片合起来用的、下半身衣物、习惯按整体说的。

过完通常能圈出十几到二十几条候选。

这一步不需要懂目标语言，按中文品类过就行，因为这几类在多数语言里是重合的。

圈完之后按流量排序，只有前二十条值得往下走，剩下的记进表里等以后。

导出的口径建议按叶子分类而不是按商品，因为同一个品类下几百个商品用的是同一个品类词。按商品导会得到几万行重复数据，按叶子分类导通常两三百行。

## 第一天下午：定形态，一条一条定死

候选圈出来之后，逐条确定它在目标语言里的形态。

顺序是先查词典标注，查不到再查语料库，还查不到才问人。

每条记三样东西：真实形态、数范畴取值、验证来源。

记来源这一列很关键，半年后复核的时候能立刻分清哪些可以跟着上游更新、哪些是自己判断的。

二十条走完通常两三个小时，如果有母语顾问在线会更快。

三条路都查不到的时候有个兜底：直接在目标国家的电商站上搜这个品类，看当地卖家的标题怎么写。当地卖家未必语法完美，但他们写的是真实在卖的说法，作为形态参考足够可靠。

## 第二天：改模板、加白名单、验一遍

第二天全部是工程动作。

把数范畴那一列同步进商品数据字段，让模板能读到。

给这批品类的标题模板关掉数量槽位，或者换一个不带数字的版本。

把这批词加进站内搜索的保护词表，禁止还原。

最后把同义词表补上，把还原器可能造出来的形态映射回真实形态。四个动作都在配置层，改完不需要回归测试整站。

改完之后的回归范围建议限定在这批品类的三类页面上：品类页、筛选结果页、商品页。不必回归整站，因为改动都在配置层且按品类分支，影响面是可枚举的。

## 上线前的四项检查与三档判据

上线前照着四条走一遍：标题标签里有没有出现不存在的形态、筛选结果那句提示在只剩一件时读不读得通、站内搜索用真实形态能不能搜到、结构化数据里的名称跟页面可见文字一不一致。

做不做这件事，也有三档判据。

目录里命中五条以上、且其中有主力品类的，值得按上面的两天流程做完。

命中一两条、且都是长尾品类的，只改标题模板那一处就够。

目标语言完全没有数这个语法维度的，比如中文和越南语这类，整件事不成立，直接跳过。判断顺序永远是先看语言有没有这个维度，再看自己踩没踩上。

还有第四种情形要单独说：多语言站里只有部分语言有这个维度。这时候正确做法不是给所有语言都加这一列，而是先按语言标一遍有没有数范畴，没有的语言整条流程跳过，别浪费审校预算。

最后补一条经验：这件事一旦做完就基本不用回头，因为词形不变、品类也不常变。所以它属于那种一次性投入、长期收益的工作，值得在新市场上线的第一个月里排掉，而不是等出了问题再补。

## 常见问题解答

## 只有复数的品类词，关键词表里到底该记哪个形态？

记那个真实存在的复数形态，并且在旁边加一列标明它属于只有复数这一类。不要为了跟其他行对齐而硬造一个单数填进去，那个形态在这门语言里不存在，写进表里之后所有下游脚本都会当它是真的。判断形态的最快办法是在目标语言的搜索框里打这个词，看下拉建议给出什么，下拉给的就是真实用户在打的。

## 词干还原把这批词还原错了，为什么系统一点提示都没有？

因为还原这一步的输出永远是一个字符串，它没有失败这个返回值。规则削掉词尾之后得到什么就返回什么，即便得到的是一个跟原意毫无关系的真实词，它也是合法输入。索引侧和查询侧都收到了合法输入，两边都不会抛异常。最后表现出来的只有站内搜索结果不准、推荐位挂错商品、这一类词报表偏低这三个症状，而它们分属三个团队。

## 做中文站需要管这件事吗？

不需要。中文没有数这个语法维度，一副护目镜和三副护目镜里名词一个字都不用改，所以整条链上不存在还原错、模板崩、形态对不上这些问题。真正要管的是从中文往外做的时候：目标语言里有这个维度，而你的模板和词表是按中文的直觉建的，那批默认假设会一路带过去。判断顺序是先看目标语言有没有这个维度。

## 这批词大概会占目录里多大比例？

按品类数算通常是个位数比例，一个两三百条品类词的站命中一般不超过二十条。但按流量算权重会明显偏高，因为命中的多是成对用品、工具和衣物这类日常品类，不是长尾。所以判断值不值得做，不要看命中条数占比，要看命中的那几条在流量里排第几。有主力品类在里面就值得做一遍。

## 能不能直接拿网上的只有复数词清单来对？

可以当参考，但别当主路径。那类清单是按语言编的，动辄几百条，其中跟电商目录有关的可能只有十几条，逐条查完要花掉一周。更省事的方向是反过来：先把自己目录里的品类词列出来，再逐条判断，命中的一般二十条以内，一个下午能处理完。清单适合用来做交叉验证，不适合用来做起点。

## 平台侧和自己的站，处理策略需要分开吗？

需要，而且方向相反。自己的站上要做的是收敛，把用户可能打出来的各种形态映射回同一个键，重点在同义词表和保护词表。平台侧多数不做词形还原，你填什么它按什么匹配，重点变成铺开，把该出现的形态都放进去。只有复数的词在平台侧反而最好处理，因为它本来就只有一个形态可铺，没有取舍。

## 集合名词要不要跟这批词一起处理？

可以放在同一次排查里，但要分开记，因为解法不一样。只有复数的词卡在形态，解法是保护词表加模板分支。集合名词卡在计数，解法是在商品页上换成能一件件数出来的下位词，把集合词留给分类页和面包屑。两类词唯一的共同点是都需要在词表上多一列来区分，所以顺手一起标注是划算的。

## 权威参考资料



## 希腊语的问号跟分号长得一模一样，切段落的程序照着分号切了下去

- URL：https://zhangwenbao.com/minor-language-sentence-boundary-passage-extraction.html
- 分类：小语种SEO
- 发布：2025-11-06  |  更新：2026-07-28
- 摘要：检索的最小单位已经从页面降到一句话，而一句话到哪儿结束在小语种上没有可靠信号。讲清希腊问号为什么被当成分号、德语的句点兼了几份差事、泰语的空格其实是句边界，以及十行代码怎么测出你的页面被切成了几句。
- 关键词：出海SEO,多语言SEO,内容本地化,小语种SEO

> **TLDR**：摘要：希腊语的问号跟英文分号是两个不同的字符，可它们长得一模一样，归一化还会把前者折成后者。于是希腊语的问句在断句程序眼里从来不是问句。泰语句末根本没有标点，德语的句点同时兼着缩写和序数两份差事，亚美尼亚语的问号压根不在句末。检索的最小单位早就从页面降到了句子，而这一步在小语种上没人查过。本文给出十行代码就能跑完的自检办法。

> 摘要：希腊语的问号跟英文分号是两个不同的字符，可它们长得一模一样，归一化还会把前者折成后者。于是希腊语的问句在断句程序眼里从来不是问句。泰语句末根本没有标点，德语的句点同时兼着缩写和序数两份差事，亚美尼亚语的问号压根不在句末。检索的最小单位早就从页面降到了句子，而这一步在小语种上没人查过。本文给出十行代码就能跑完的自检办法。

## 抓答案那一步，为什么先要知道一句话到哪儿结束？

## 从一个希腊语箱包站的常见问题区说起

那是一家做希腊市场的箱包站，主推旅行箱和登机箱。

常见问题区写得很扎实，二十多组问答，结构化数据也标齐了。

英文站上这一块表现很好，经常被摘去当直接答案。

希腊语站的同一块内容，从上线起就一次都没有被摘过。

页面收录正常，结构化数据校验也全绿。

问题最后出在一个符号上：希腊语的问号看起来就是一个英文分号，而站点的问答抽取逻辑靠句末标点判断哪一句是问题。整整二十多个问题，在程序眼里全都是一句没说完的话。这件事排查了三个星期，因为屏幕上那个符号跟分号一模一样，没有人想到去核码位。

希腊人自己当然读得毫无障碍，只有机器读不出来。

这件事真正让人后怕的地方在于，排查的三个星期里团队几乎把能想到的都试了一遍：重写答案、调整标记结构、检查抓取权限、换了两版结构化数据。每一步都合理，每一步都无效，因为问题根本不在被检查的那些层上。

## 检索的最小单位这些年一路往下降

先把这件事的背景交代清楚。

很长一段时间里，检索处理的单位是一整个页面。

后来变成了页面里的某一段，段落级的抽取开始独立打分。

再往后，直接给答案的形态又把单位压到了一两句话。

单位每降一级，对文本切分精度的要求就高一级。

页面级只要认得出边界在哪个文件，段落级要认标签，而句子级要认的是标点。前两层的边界都是你自己写在代码里的，只有最后这一层的边界是写在自然语言里的，而自然语言的标点规则按语言各不相同。

边界从你的地盘挪到了语言的地盘，麻烦就是从这里开始的。

还有一层变化容易被忽略：单位越小，一个页面里可以被独立评估的候选就越多。同一页正文过去只作为一个整体参与竞争，现在被拆成几十个候选各自竞争。切分准的页面等于多了几十次机会，切分乱的页面等于把这些机会全废掉了。

这条趋势还有一个不太被提起的侧面：单位越小，内容之间的可替代性就越强。整页竞争的时候，品牌、结构、内链这些页面级信号还能起作用；到了单句竞争，能拿出来比的几乎只剩这一句本身说清楚了没有。前置切分因此变得比过去任何时候都关键。

## 页面被切成几句，决定了能被抽走什么

这一步的影响比想象中大。

一段内容能不能被摘出来当答案，前提是它得先被切成一个完整的单位。

切出来的东西太长，就会在展示时被截断。

切出来的东西太短，信息不完整，压根不会被选中。

切在错的位置，抽出来的就是一句半截话。

AI概览语言覆盖那篇 (https://zhangwenbao.com/ai-overviews-100-countries-six-languages-minor-language-citation.html)讲过一门语言的语序会不会决定段落能不能被摘去当答案，那说的是语序。本篇讲的是更前面的一步：在讨论这一句写得好不好之前，先得确认它被当成了一句。

写得再好的一句话，如果没被切出来，它就不存在。

这一步的另一个特点是它完全不给反馈。抓取正常、收录正常、结构化数据校验通过，所有能看到的指示灯都是绿的。唯一的异常是那个板块从来不被摘取，而这是一个负向指标，负向指标在报表上天然不显眼，需要有人专门去找零。

## 这跟内容质量无关，是一步前置处理

这里需要把责任划清楚。

内容质量讲的是这段话写得清不清楚、有没有回答问题。

那一层的优化空间很大，也有很多现成的方法。

本篇讲的东西在那之前发生，属于纯粹的机械处理。

它不看你写了什么，只看字符串里有没有它认识的边界记号。

这个区分很重要，因为前置处理出问题的时候，所有针对内容质量的优化都不会有效果。你把答案写得再精炼，切分错了照样抽不出来。团队常常在质量这一层反复打磨半年，而真正卡住的是上游那一个符号。

先确认管道通不通，再谈往管道里灌什么。

把这两层分清楚还有一个现实好处：它决定了先花钱在哪儿。内容质量的投入是持续的、按篇计价的，而前置处理的排查是一次性的、按语言计价的。一次性投入通常几小时就能做完，持续投入却可能白烧半年，先后顺序错了代价很大。

还有一个判断先后的土办法：先问这个问题是不是全语言版本一致地出现。内容质量问题通常是零散的，这一页好那一页差；前置处理问题是整齐的，整个语言版本一起中招。看到整齐的零，就该往前置那一层找。

## 分词管词、断句管句，这两件事的证据差在哪儿？

## 分词的证据在词典里

先说大家更熟悉的那一件。

分词要解决的是一个词从哪儿开始到哪儿结束。

在没有空格的语言里，这件事靠词典加统计模型完成。

泰语分词那篇 (https://zhangwenbao.com/thai-seo-no-spaces-word-segmentation-keyword.html)讲过切在哪儿由引擎的词典说了算。

词典的关键性质是：它是可以增补的。

你的品牌名切错了，把它加进自定义词典就好了。分词的错误几乎总有一个补词典的解法，成本可控，效果立竿见影，而且这份词典是你自己的资产。

这一层虽然难，但至少有一条明确的路可以走。

词典这条路还有一个附加价值，它的产出可以复用。为分词建的自定义词表，同一批词往往还能用在站内搜索的同义词配置、广告关键词的否定词表、以及内容审核的敏感词匹配上。一份投入几处受益，这在小语种上尤其划算。

## 断句的证据在标点里

断句要解决的是一句话从哪儿开始到哪儿结束。

它依赖的证据几乎全部来自标点符号。

句号、问号、感叹号，加上一点关于大小写和空格的规则。

Unicode的文本切分附录 (https://unicode.org/reports/tr29/)专门定义了句边界算法，而它开宗明义就说明这套默认规则需要按语言做本地化调整。

换句话说，规范自己承认默认档不够用。

更要紧的是，标点不是你能补的东西。它是写作者敲下去的既成事实，散落在成千上万个页面里。你没法像加词典那样，事后统一给所有句子补上正确的句末标记。

这一层的证据是只读的。

除了标点，断句还会用到一些辅助线索，比如下一个词是不是大写开头。而这条线索在没有大小写的书写系统上直接归零，中日韩泰阿拉伯语全都用不上。也就是说非拉丁语言不但主要证据更弱，连辅助证据都少了一条。

还有一类线索是句首词的性质，比如英语里句子很少以某几类虚词开头。这类统计线索同样是语言相关的，而且它需要足够的语料才能训练出来。语料充足的语言拿得到这层保险，语料少的语言就只剩标点这一条证据，容错空间被压到了零。

## 词典能补，标点不能补

把两件事放在一起，一条判据就出来了。

分词出问题，投入应该放在词典和自定义规则上。

断句出问题，投入必须放在写作规范和补充表述上。

两者的着力点完全不同，用错了会白花力气。

见过团队为了解决断句问题去堆词典，跑了半年一点效果没有。

更一般地说：凡是一类问题的证据来自你能修改的资产，就走增补路线；凡是证据来自已经写死的文本，就只能走绕开路线。这条判据在并列与列举那篇 (https://zhangwenbao.com/minor-language-coordination-ellipsis-list-keyword.html)里也成立，那里的结论同样是不改原文、另补一份。

能改的和不能改的，从一开始就要分清楚。

这条判据还能解释一个常见的资源错配。团队在评估投入的时候，倾向于选那些有明确工具和明确产出的方向，因为它们好排期、好汇报。补词典正是这样一件事，它有工具、有产出、有进度条。而写作规范这类工作看起来什么都没交付，往往排不上号。

## 希腊语的问号为什么会被当成分号？

## 那个符号跟分号长得一模一样

现在回到开头那个案例。

希腊语有一个专用的问号，Unicode里给了它一个独立的码位。

它的字形跟拉丁字母体系里的分号完全一致，一个点在上一个点在下。

屏幕上、打印稿上、编辑器里，肉眼分辨不出任何区别。

而它在希腊语里承担的功能，是标记一个问句的结束。

这就构成了一个很少见的局面：两个功能完全相反的符号，共用同一个外观。一个是句子还没完，一个是句子完了而且是个问题。Unicode希腊与科普特文码表 (https://www.unicode.org/charts/PDF/U0370.pdf)里能查到这个码位，说明栏里明确写着它相当于问号。

看得见的和真实的，在这里第一次彻底分家。

同形这件事本身在Unicode里并不罕见，罕见的是这两个符号的功能正好相反。多数同形字对的双方含义相近，比如不同书写系统里的同一个字母，误认了影响有限。而这一对里一个说没完一个说完了，误认的代价被放大到了极限。

还有一个让人哭笑不得的细节：因为两者外观一致，在多数字体里它们的宽度也完全相同。这意味着连排版差异都不会露出破绽，把希腊问号换成分号，整个版面一个像素都不会动。视觉排查在这里彻底没有着力点。

## 归一化会把它折成分号

更麻烦的一步在后面。

为了让搜索匹配更宽容，很多系统会先做一次字符归一化。

归一化的目的是把等价的写法统一成一种。

而希腊问号在兼容性映射里，恰好被映射到普通的分号上。

也就是说，你为了提高匹配率做的那一步，把这门语言唯一的问句标记抹掉了。

这跟大小写折叠那篇 (https://zhangwenbao.com/minor-language-case-folding-lowercase-turkish-dotless-i.html)是同一族的坑：一个没有语言参数的通用变换，在某一门语言上是有损的。那次损失的是一个字母的身份，这次损失的是一个句子的类型。

而且这一步通常发生在你看不见的地方。

要判断自己的系统有没有做这一步，可以直接测：把一段带希腊问号的文本存进去再取出来，逐字符核对码位。存取一轮之后码位变了，就说明中间某一环做了归一化。这个测试比翻遍代码找归一化调用快得多，也更可靠。

## 后果落在问答类结构上

损失最集中的位置是问答类内容。

常见问题区的每一个标题，本质上都是一个问句。

问答类的结构化数据也依赖问句的识别。

而抽取式的回答系统在挑候选时，会明显偏好形式上成立的问答对。

希腊语页面上这些问句，在切分之后全都不是完整句子。

问答长尾那篇 (https://zhangwenbao.com/minor-language-qa-long-tail-content-value-ai-era.html)讲过整个语种里认真写完整回答的没几家，这是个机会。但机会的前提是你写的那些问答，在机器那里得先算数。写得再全，形式上不成立，一样进不了候选池。

这就是为什么这一层值得单独花时间。

还有一个连带损失落在站内搜索上。用户在站内搜一个带问号的问题，如果索引侧和查询侧的归一化不一致，同一个问句就匹配不上自己。这类不一致在多语言站上特别常见，因为两侧往往由不同时期的不同人配置。

这类损失还有一个特点，它会随着内容质量提升而变得更明显。问答写得越多、越认真，被这一层吃掉的价值就越大。于是团队会观察到一个很打击士气的现象：这个板块投入越多，跟英文站的差距反而越拉越开。

## 你自己的编辑器也看不出区别

这个坑还有一个格外恶劣的性质。

排查的时候，你看到的是渲染后的字形。

而渲染后的字形正好是两个符号唯一相同的地方。

把源码复制出来看，还是一样。

只有查码位才能分辨，而没人会平白无故去查一个标点的码位。

这跟域名同形字那篇 (https://zhangwenbao.com/idn-punycode-local-script-domain-input-trust.html)的机制是一样的：凡是靠字形辨认的排查手段，遇到同形字就整体失效。可行的办法只有一个，把那一段文本丢进一个能显示码位的工具，逐字符看一遍。

说起来简单，难的是想到该去做这件事。

这里有个很实用的应对习惯：凡是排查到某一层怎么都说不通的时候，就把那段文本的码位打出来看一遍。这个动作成本几乎为零，却能挡住一整类靠肉眼永远发现不了的问题。不可见字符、同形字、方向控制符，全都在这一步现形。

## 一个句点在德语里兼了几份差事？

## 句末、缩写、序数三份差事

换到德语，问题的形状完全不同。

德语的句末标点跟英语一样是一个点，这没什么特别。

特别的是这个点在德语里还兼着另外两份工作。

第一份是缩写，德语的缩写几乎都带点，而且用得极频繁。

第二份是序数，德语的序数直接在数字后面加一个点。

于是一行德语正文里可能出现七八个点，而其中只有一个是句末。其余每一个，对断句程序来说都是一次误报的机会。德语复合词那篇 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)讲的是词长带来的麻烦，这一条讲的是标点密度带来的麻烦，两者都源自德语正字法本身。

密度高到一定程度，这个信号的信噪比就塌了。

德语还有一类特别麻烦的缩写，是那种带空格的两段式写法。它由两个各自带点的部分组成，中间隔一个空格。断句程序看到第一个点后面跟着空格再跟着一个字母，判定条件几乎完全命中句末的特征，误报率在这类缩写上最高。

还有一个来自数字的干扰源：德语的小数点用逗号，千位分隔符用点。于是一个价格数字里就带着一个点，而它跟句末的点长得一模一样。规格密集的商品页上，光是价格和尺寸就能贡献一大批假句末。

## 序数点是强制的不是可选的

这里要强调一个容易被忽略的事实。

英语写序数用后缀，第一写成1st，不带点。

德语写序数就是数字加点，第一写成1.，没有别的写法。

日期里的日、楼层、条款编号、排名，全都带这个点。

商品页上写尺寸、写档位、写步骤序号，同样带。

换句话说，德语页面上假句末的数量跟内容的结构化程度成正比。你把内容写得越有条理，步骤分得越清楚，序数点就越多，断句出错的机会也越多。这是一条相当反直觉的关系。

写得好反而更容易被切错，说出去有点冤。

把序数点的影响估出来其实不难：抓一批德语页面，数一数数字后面直接跟点的出现次数，再数一数真正的句末数量。两个数一比就知道这门语言上的信噪比有多差。多数电商类德语页面上，这个比值会让人相当意外。

## 兼职越多，作为边界信号越不可靠

把这几门语言放在一起，可以提炼出一条能直接用的规律。

同一个字符在一门语言里承担的功能越多，它作为边界信号的价值就越低。

日语的句号只有一份差事，就是句末，几乎不会误判。

英语的句点有两份，句末和缩写，误判率中等。

德语的句点有三份，误判率明显更高。

这条规律的好处是可数、可比、可以直接拿来排优先级。要评估一门新语言的断句风险，先数一数它的句末标点在别处还兼着几份工作，一分钟就能给出一个粗略的分档。语言误判那篇 (https://zhangwenbao.com/minor-language-page-language-detection-misidentification-short-text.html)提过一个类似的取向，先找出最容易出错的那一类再动手，比全面排查省事得多。

能数出来的判据，才有可能被真的用起来。

这条规律还能反过来用，帮着挑内容形态。同样一份信息，写成带序数的步骤说明和写成无序列表，在德语上的断句风险差别很大。知道了这一点，内容形态的选择就多了一个此前完全不在考虑范围内的维度。

要把这条规律用起来，最省事的形式是做一张表：一行一门语言，列出句末标点是什么、它在别处还兼几份差事、有没有专用的问号。这张表填一次就能长期用，新增语言时补一行，评估工作从半天变成十分钟。

## 没有句末标点的语言，边界靠什么？

## 泰语靠空格分句而不是分词

泰语给出的是这一类问题的极端形态。

泰语的句子结束时，不写任何标点。

句号、问号、感叹号在传统泰文里都不使用。

那句边界靠什么呢，靠空格。

泰语的空格标记的正是短语或句子的分界，而不是词的分界。

这跟泰语分词那篇 (https://zhangwenbao.com/thai-seo-no-spaces-word-segmentation-keyword.html)的结论正好构成一对：那篇说泰语的空格不是词边界，本篇要补的是它其实是句边界。同一个字符，在泰语里干的是别的语言里句号干的活。而按空格切词的程序，等于把每一句当成了一个词。

一个字符在两门语言里承担的功能，可以完全不搭界。

这带来一个很具体的后果：泰语页面上如果为了排版好看而在词与词之间加了空格，等于凭空制造了一堆假句边界。而加空格这件事，恰恰是不懂泰语的前端和设计最容易做的一个善意改动，理由通常是这样看起来不那么挤。

## 中日文的句号不带空格

中日文的问题要温和一些，但同样真实。

中日文的句号是一个全角字符，后面不跟空格。

而不少老式的断句规则写的是句点加一个空格。

这条规则在中日文正文上一次都不会命中。

结果是整个段落被当成一句话处理。

日文排版需求文档 (https://w3c.github.io/jlreq/)里对句读点的用法有专门章节，能看出这套体系跟拉丁文的空格约定是两回事。规则写死了空格，就等于默默排除了所有不用空格的书写系统。

而这类规则往往藏在某个十几年前写的工具函数里。

这类规则的年代感是它最大的特征。写下它的时候，处理的多半是英文文档，句点加空格是完全合理的判据。问题在于它后来被复制进了一个又一个项目，而每一次复制都没有人重新问一遍这条规则默认了什么。

这类历史规则还有个特点，它们通常藏在最不起眼的地方，比如一个叫格式化工具的公共函数里。没人会想到去审它，因为它的名字听起来跟检索没有半点关系。排查这类问题时，按名字找是找不到的，只能按行为找。

## 两套句末标记并存的语言

还有一类情况介于两者之间。

天城文有自己的句末标记，是一竖。

但印地语网页上大量混用英文句点，尤其是技术类和电商类内容。

于是同一个站上两套标记并存，比例还不稳定。

断句程序按哪一套走，取决于它有没有为这门语言做过配置。

印度多语言那篇 (https://zhangwenbao.com/india-multilingual-seo-eleven-languages-nine-scripts-priority.html)算过十一门语言分摊在九套书写系统上的账。混用率本身是个可以测的数：抓一批页面，两种标记各数一遍，比例出来就知道该不该单独配置。

能测的东西，就不该靠猜。

混用还会带来一个更细的麻烦：同一个段落里两套标记交替出现，断句程序按其中一套配置之后，另一套就成了噪声。所以混用率不只决定该不该单独配置，还决定了配置之后能拿到多少收益，比例太接近五五开的时候，两边配置的效果都好不了。

## 问句标记不在句末的语言该怎么办？

## 亚美尼亚语的问号标在重音音节上

再往下还有一种更彻底的情形。

亚美尼亚语有自己的句号，是一个冒号形状的符号。

它的问号更特别，不放在句子末尾。

而是标在被提问的那个词的重音音节上方。

也就是说问号可能出现在句子的中间，甚至靠前的位置。

任何靠看最后一个字符判断句型的逻辑，在这门语言上完全失效。不是判错，是根本没有可判的对象。

这类语言的市场通常不大，但一旦要做，这一层是绕不过去的。

这类语言还有一个共同点：它们的市场规模通常不足以让通用工具专门为其做适配。于是默认规则一直是它们唯一能得到的处理，而默认规则又恰好完全不匹配。资源少和适配差在这里形成了一个闭环，谁也没打算解开它。

面对这类语言，务实的选择往往不是修复而是绕开：把关键信息用结构化的方式再表达一遍，让机器不必依赖句子切分也能拿到。这条路对任何切分表现差的语言都成立，而且它的收益不随语言的资源多少而变化。

## 日语可以完全不用问号

日语给的是另一种偏差。

日语表达疑问靠句末的助词，问号是可选的。

正式文体里，一个疑问句常常以句号结尾。

母语者读到那个助词就知道这是问句，不需要额外记号。

而程序看到的是一个普通的陈述句结尾。

这一条跟日语敬语那篇 (https://zhangwenbao.com/japanese-seo-keigo-politeness-levels-conversion-ranking.html)有接口：越是正式的文体，越不写问号，而常见问题区恰好是要写得正式的地方。于是你的日语常见问题区里，可能一个问号都没有。

写得越规矩，形式上越不像问答。

这条对内容侧其实是个可以主动利用的信息。既然日语的正式问句可以不带问号，那么在常见问题区里主动把问号写上，就成了一个不损害地道程度的加分动作。日语网页上带问号的疑问句完全常见，只是不是必须，这个空间值得用起来。

## 判断句型的逻辑默认标记在句末

把这三门语言合起来看，能提炼出第三条原语。

所有判断这是不是一个问题的逻辑，都默认问句标记在句末。

希腊语的确在句末，但字符跟分号同形。

亚美尼亚语的不在句末，位置随重音走。

日语的可以完全不存在，靠一个词来承担。

三种偏差方式各不相同，共同点是那条默认假设在英语上成立得太好，好到没有人想过它是一条假设。凡是从来没被质疑过的规则，多半是因为它在制定者的语言上一直很准。

这条经验在小语种上会反复用到。

这条原语还有一个更广的用法：每次接一门新语言，先把自己流程里所有基于位置的假设列出来，逐条问一遍这条在目标语言上还成不成立。标记在句末、修饰语在名词前、否定在动词前，这些假设平时根本不会被写下来，因为它们在英语上从来没错过。

把这些隐含假设列出来还有一个用处，它能解释为什么某些工具在小语种上的表现会突然变差。表现变差通常不是模型能力问题，而是某一条被写死的位置假设在这门语言上不成立。找到那一条，往往比换一个更强的工具有效得多。

## 切错句子会在哪三个地方付出代价？

## 切多了：抽出来的答案缺半句

把后果分类之后，处理起来会清楚很多。

第一种错法是切多了，一句话被拦腰切成两段。

德语的序数点和缩写点最容易造成这种错。

抽取时拿到的是前半句，读起来像话没说完。

结论如果恰好在后半句，抽出来的就是一段无用的文字。

这一类错误的隐蔽之处在于抽出来的片段语法上完全通顺，它只是不完整。人读一眼就知道少了东西，机器不会知道。

能通顺地说半句话，是所有语言的共同特点。

要确认是不是这一类错法，有个简单的办法：把那一段的展示片段跟原文并排，看片段结尾处是不是恰好落在一个缩写或者序数后面。命中率相当高，因为这两类是德语里唯一会在句中制造假句末的成分。

## 切少了：整段并成一句被截断

第二种错法是切少了，好几句并成一大坨。

中日文用老式规则处理时最常见。

并起来的那一大段远超展示长度，只能被截断。

截断的位置是按字数算的，跟语义没有关系。

于是展示出来的就是一段在莫名其妙处断掉的文字。

可读性公式那篇 (https://zhangwenbao.com/minor-language-readability-score-english-calibrated-formula.html)提过句长在不同语言上的基线本来就不同。切少了会让实测句长虚高好几倍，任何基于句长的判断因此一起失真，包括可读性评分和摘要选择。

一个前置错误，会污染下游一整串指标。

这一类错法还有个连带影响，它会让所有跟句长有关的自动化判断集体失灵。摘要选句、可读性打分、内容质量评估，只要涉及句子这个单位的指标，全都建立在切分结果之上。切分错了，这些指标不是不准，而是根本在测另一样东西。

这类错法还有个反直觉的地方：它在中日文上比在拉丁语言上更常见，而中日文恰恰是很多团队认为已经处理得不错的语言。原因是中日文的其他环节都做过适配，唯独这一条老规则因为太底层而从未被碰过。

## 切错位置：问句和答案粘在一起

第三种最麻烦，边界落在了错误的位置。

希腊语常见问题区就是典型：问句没有结束，跟答案连成了一句。

抽出来的片段既包含问题又包含半截答案。

这种片段在问答匹配里得分很低，因为它看着不像一个答案。

而它同时也不像一个问题。

三种错法里，只有这一种会让内容同时失去两个身份。前两种至少还保住了一个残缺的单位，这一种连单位类型都错了。

所以排查时应该先找这一类。

这一类的另一个特征是它高度集中在特定板块上。问答区、步骤说明、条款列表这些一问一答或者一条一条的结构，最容易出这种错，因为它们的每个单元本来就短，边界判断错一次就整体串位。连续叙述的正文反而不太出这个问题。

## 三种错法的报表长相各不相同

好在这三种错法在数据上留下的痕迹并不一样。

切多了通常表现为长尾问句词有展现但点击率低。

切少了表现为摘要展示经常在奇怪的地方断掉。

切错位置表现为整个板块从来不被摘取，展现接近于零。

第三种最容易识别，因为它是彻底的零而不是偏低。

识别顺序也就有了：先找彻底为零的板块，再找展示形态异常的，最后才看点击率偏低的。零是最强的信号，而一个内容扎实的板块长期为零，几乎一定是结构性原因。

保哥的习惯是先看有没有零，再看数字大小。

把这三种长相记下来还有个好处，它能让人在看报表的时候多问一句。看到一个板块展现为零，第一反应通常是内容不行或者竞争太激烈；知道有这三种错法之后，就会先去确认它有没有被正确切分，而这个确认只要几分钟。

这三种长相还可以合成一张排查顺序表，按发现成本从低到高排：先扫零展现的板块，再看展示片段有没有在奇怪位置断掉，最后才对着点击率找。前两项看报表就能完成，第三项才需要逐条对照原文。

## 十行代码测出你的页面被切成了几句

## 浏览器里就有现成的断句接口

这件事的自检成本低得出人意料。

现代浏览器内置了一个国际化的文本切分接口。

它支持按词、按句、按字素三种粒度，并且接受语言参数。

MDN关于这个接口的文档 (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Segmenter)给了完整的用法，选句子粒度就能拿到切分结果。

不需要装任何库，打开控制台就能跑。

做法很直白：把页面正文取出来，指定目标语言跑一遍句子粒度切分，数出句子个数。这个数字就是机器眼里这一页有几句话。浏览器支持情况 (https://caniuse.com/mdn-javascript_builtins_intl_segmenter)可以先查一下，主流浏览器都已经支持。

十行代码，五分钟出结果。

要注意这个接口给出的是它自己的判断，不是搜索引擎的判断。两者用的规则数据未必一样，结果也可能有出入。但对自检来说这不影响结论，因为你要找的是那种明显偏离的情况，而明显偏离在任何一套规则下都会显现。

## 拿人工数的句数当对照

光有机器的数字还不够，得有个对照组。

找一个母语者，让他把同一段文字的句子数出来。

两个数字并排一看，问题的性质立刻清楚。

机器的数字明显偏大，说明切多了。

明显偏小，说明切少了。

两个数字接近但抽取效果仍然不好，那问题在别处。这个对照的价值在于它把一个模糊的怀疑变成了一个具体的比值，而比值可以写进工单，也可以跨语言比较。

没有对照组的数字，说服不了任何人。

让母语者数句子的时候，最好不要提前说明目的。一旦他知道你在查什么，判断就会往你想要的方向靠。更稳的问法是请他把这段话按句子分行抄一遍，让分行动作自然产生句数，而不是让他直接报一个数字。

拿到两个数字之后，还有一个值得多做一步的动作：把差异最大的那一段单独拎出来，请母语者标出他认为的每个句末位置。这份标注既是证据，也可以直接拿去当规则定制的输入，一份工作两处用。

## 该测哪几类页面

测试范围要收窄，不然成本还是高。

第一类必测的是常见问题区，因为它全是问句。

第二类是退换货和配送说明，那里缩写和数字最密集。

第三类是商品详情里的规格段落，序数和单位扎堆。

这三类的共同点是标点密度高于普通正文。

标点密度高，出错概率就高，而这三类恰好又是最可能被摘去当答案的内容。风险和价值同时最高的那一块，理所当然应该先测。

剩下的营销文案，出错了影响也有限。

这三类页面还有一个共同的优势：它们的正文都不长，人工核对的成本可控。全站抽检听起来严谨，实际做起来往往中途放弃。挑三类各两页，一个下午能出结论，而结论的方向性跟全站抽检不会有本质差别。

## 断句这件事该交给前端、检索层还是内容侧？

## 前端只能影响标记不能影响字符

知道问题在哪之后，得决定谁来修。

前端能做的是把每一句用独立的标签包起来。

这确实有帮助，因为标签边界比标点边界可靠得多。

但前端改不了正文里那个符号本身。

希腊语的问号还是那个问号，德语的序数点还是要写。

所以前端这条路的上限很清楚：它能提供一层额外的边界信号，但不能修复原有信号的歧义。把每个问答项包成独立的块，是性价比最高的一步，也基本是前端能做的全部。

额外信号有用，但别指望它兜底。

把每个问答项包成独立块还有个附带收益，它顺便把结构化数据的标注边界也理清楚了。很多站的问答标注跟视觉结构对不上，就是因为正文本身没有清晰的块边界。前端这一步做完，标注的准确率通常会跟着提高一截。

需要提醒的是，包块这件事要跟视觉结构保持一致，不能为了机器凭空加一层看不见的容器。加了看不见的容器，维护的人下一次改版就会把它删掉，因为他不知道那是干什么用的。凡是没有可见理由的结构，寿命都不会长。

## 检索层能换规则但你未必控制得了

检索层的空间理论上最大。

成熟的切分库都允许加载语言专属的规则。

ICU的边界分析文档 (https://unicode-org.github.io/icu/userguide/boundaryanalysis/)说明了怎么用规则文件定制断句行为，包括处理缩写列表。

问题是这条路只对你自己的站内搜索有效。

外部搜索引擎和大模型用的是它们自己的切分逻辑。

这就把这条路的适用范围限定住了：能改的那一半通常不是最值钱的那一半。站内搜索值得改，因为它直接影响转化；外部那一侧你只能通过写作来影响。

分清哪些是你的地盘，能省下大量无效讨论。

还有一个容易被忽略的边界：即使是站内搜索，改切分规则也需要重建索引，而重建索引在大站上是有窗口期要求的。所以这条路虽然可行，排期成本却不低。评估的时候要把它算成一个中等规模的技术改造，而不是改个配置。

## 内容侧的空间比想象中大

剩下的责任落在内容侧，而这一侧的空间其实不小。

第一件事是在常见问题区的标题里，把问句写得不依赖标点也成立。

比如用疑问词开头，让句型本身就带信息。

第二件事是把关键结论写成独立的短句，别挂在长句的后半段。

第三件事是在规格段落里少用序数点，能写成列表就写成列表。

这三件事都不需要动技术栈，而且它们同时也是让人读起来更舒服的改动。这一层很少见地出现了机器和读者利益一致的情形，结构化数据那篇 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)里那种正文和机器读的版本要分开写的取舍，在这里不必做。

能两头都讨好的改动，应该优先做完。

内容侧还有一个几乎零成本的动作：在写作规范里加一条，关键结论不要放在含缩写或序数的句子后半段。这条规则不需要任何语言学知识，写作的人一看就懂，而它恰好避开了断句最容易出错的那个位置。

内容侧这几条还有一个共同的优点：它们的效果不依赖任何一方的配合。前端改不改、检索层换不换规则，写作规范一旦落地就一直在生效。在跨部门协作成本高的团队里，这一点往往比理论上的最优解更重要。

## 一份可以照着做的句边界自检清单

## 五步查完一个语言版本

把整篇压成可以直接执行的五步。

第一步，挑三类高风险页面各取两页，导出正文纯文本。

第二步，用浏览器的切分接口按句子粒度跑一遍，记下句子数。

第三步，请母语者数一遍同样几段的真实句子数，两个数字并排。

第四步，差异明显的，把那几段逐字符查码位，重点看句末那一个。

第五步，按三种错法归档，切多了走写作规范，切少了走标记包裹，切错位置走符号核查。这五步里只有第三步需要母语者，其余全是机械操作。审校验收那篇 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)说过，能交给不懂那门语言的人执行的检查才跑得下去，这份清单是照着那条原则设计的。

一个语言版本跑完大约需要两小时。

这五步里最容易走过场的是第四步查码位，因为前三步做完之后人往往已经形成了判断，觉得原因显而易见。但真正让结论站得住的恰恰是这一步，它把一个推测变成了一个可以贴进工单的证据。省掉它，整轮排查的说服力会打对折。

这套流程还可以顺手产出一份副产品：那份逐字符核过的文本，本身就是给译者和写作团队最好的说明材料。抽象地讲什么是同形字很难让人上心，把两个长得一样的符号连同码位一起摆出来，通常一遍就记住了。

## 优先测哪几类页面

如果连两小时都挤不出来，那就只测一类。

只测常见问题区，性价比最高。

它的问句密度最高，因此暴露问题最快。

它也是最可能被摘去当答案的内容形态。

而且它的篇幅短，人工数句子的成本最低。

换句话说，常见问题区在诊断价值、商业价值和测试成本三个维度上同时最优。要是只能做一件事，就做这一件。情态与承诺强度那篇 (https://zhangwenbao.com/minor-language-modality-obligation-commitment-strength.html)给的那份清单也是从这一块开始的，两件事可以合成一轮做完。

同一批内容，一次抽检解决两个问题。

如果连一类都不想全测，还有个更省的版本：只挑常见问题区里最长的那三条问答，跑一遍切分看句数。问题如果存在，在这三条上几乎一定会显现，因为它们的标点最多。十五分钟就能得到一个粗略但方向可靠的判断。

挑最长的那三条还有个理由：长问答里更可能出现列举、缩写和数字，也就是所有假句末的来源。短问答标点少，即使切分逻辑有问题也不容易暴露出来，测了反而可能给出一个虚假的安全结论。

## 什么时候该承认这条不用管

最后说说什么时候可以放过。

如果你做的语言句末标点跟英语完全一致，风险本来就低。

如果那门语言的内容还没有任何被摘取的记录，先解决更前面的问题。

如果整个板块的流量占比极小，优先级自然靠后。

判断只需要两个数：这门语言的问句类内容占比，和它的句末标点兼职数量。

两个数都低，这件事可以先不管；有一个高就值得测一次，两个都高就该排进这个季度。测一次的成本是两小时，而问题一旦存在，它影响的是整个语言版本的问答类内容。

成本这么低的检查，实在没有理由拖着。

还有一种情况也该放过，就是那门语言的内容目前还处在刚起步的阶段，页面数少、更新频繁。这时候写作规范都还没定型，先做这一层的排查等于给一个还在动的东西做体检。等内容形态稳定下来再测，结论才有保存价值。

判断值不值得做，还可以把它跟别的排查合并考虑。如果这个季度本来就要抽检问答区的内容质量，那顺手跑一遍切分几乎不增加成本。单独立项的门槛高，搭车的门槛低，这类小而重要的检查最适合搭车。

## 常见问题解答

## 希腊语的问号可以直接换成英文问号吗？

技术上可以，但那是错别字，希腊读者一眼就能看出来。稳妥的做法是正文保留正确的符号，另外在结构化数据和标记结构上给出额外的边界信号。也就是说不动字符，改用别的方式让机器知道这里是一个问句的结束。这跟处理德语省略连字符的思路是一致的，规范归规范，补充归补充。实际操作里还有一个更轻的做法，就是在问答标题里同时用疑问词开头，让句型本身就带上问句特征，不完全依赖那个符号。结构化数据那一份也值得单独确认，因为它跟正文用的是两条链路，正文修好了不等于标注也修好了。

## 用标签把每一句包起来是不是就万无一失了？

不是万无一失，但确实是性价比最高的一步。标签边界比标点边界可靠，抽取时也更容易被识别成独立单位。它的局限在于你只能包到段落和条目这个粒度，段落内部的句子还是要靠标点切。所以它对常见问题区这种一问一答的结构效果最好，对连续叙述的正文帮助有限。另外要注意标签结构只对显式分块的内容有效，正文里连续的几句话仍然要靠标点切，所以它是补充不是替代。另外还要注意包块的粒度别过细，把每一句都包成独立元素反而会让页面结构变得难以维护。

## 这件事跟分词是不是同一个问题的两个说法？

不是。分词处理的是词边界，证据来自词典，而词典你可以增补；断句处理的是句边界，证据来自标点，而标点是写作时就定死的。两者的可干预程度完全不同，投入方向也就不一样。混为一谈最常见的后果是把预算全砸在词典上，而真正卡住的那一层一动没动。还有一个实际差别是排查顺序：分词问题通常在关键词报表上先冒头，断句问题只在抽取和摘要那一侧显现，两者的入口完全不同。两者的投入产出也不同：词典的效果是渐进的，断句一旦切对，整个板块的表现可能一次性回来。

## 浏览器的切分接口在冷门语言上准吗？

准确度跟这门语言有没有配套的规则数据直接相关。主流语言的表现相当不错，冷门语言可能就退回默认规则了。不过这不影响它当自检工具用，因为你要的不是绝对准确，而是机器切出来的句数跟人数的句数差多少。差多少这件事，用默认规则跑出来一样有意义。如果拿不准某门语言的支持情况，可以拿一段已知句数的文本先跑一遍当校准，看接口在这门语言上的基本表现如何。校准文本最好挑一段真实的站上内容，而不是随手编的句子，编的句子往往标点比真实内容规整得多。

## 德语的序数点真的没有别的写法吗？

正式书写里没有。日期、楼层、条款编号都是数字加点，这是正字法规定的。能做的是在结构上绕开，比如把步骤序号交给有序列表去生成，而不是在正文里手写。这样正文里的点就少了一大批，断句的误报率也跟着下来了。有序列表还有一个额外好处，序号由标签生成之后正文里那些点就消失了，同一段文字的假句末数量会明显下降。如果内容管理系统不支持有序列表，退一步也可以把序号写成不带点的形式，虽然不够规范但风险更低。

## 怎么快速确认某个标点的码位？

把那一段文本粘进任何一个能显示字符编码的工具，逐字符看一遍即可。也可以在浏览器控制台里对那个字符取码位，一行代码就有结果。关键不是技术难度，而是要想到去做这件事。绝大多数同形字问题拖了很久，都是因为没人怀疑过一个看起来完全正常的标点。如果是批量排查，可以写一个小脚本把整段文本的码位逐字符输出，重点看每个句末位置上的那个字符是不是你以为的那个。排查时重点看那些看起来完全正常的标点，真正有问题的从来不是那些一眼可疑的字符。

## 这件事该多久复查一次？

内容形态不变的话，一次查清就能管很久，因为标点规则本身不会变。真正需要复查的时机是换了内容管理系统、换了翻译供应商，或者新上了一门语言。这三个时刻都可能引入新的写作习惯，值得把那五步重跑一遍。日常更新则不必，改一篇文案不会改变整个语言版本的标点分布。换供应商这个触发条件尤其值得记，因为不同译者对标点的处理习惯差别相当大，而这种差别在验收时几乎不会被提出来。除了这三个时机，如果发现某个语言版本的问答区突然不再被摘取，也应该立刻重跑一遍这五步。

## 权威参考资料



## 西班牙语的地区差别原来写在hreflang里，到了AI问答只剩用户嘴里那一个词

- URL：https://zhangwenbao.com/spanish-regional-variants-ai-answer-source-divergence.html
- 分类：小语种SEO
- 发布：2025-11-05  |  更新：2026-07-27
- 摘要：西语在AI问答里被当成一门语言，可同一件商品在马德里、墨西哥城、布宜诺斯艾利斯是三个词。讲清分歧出在检索侧还是生成侧、哪些词才真会把三个变体分开、分叉率怎么算，以及什么时候该拆页面。
- 关键词：AI搜索,多语言SEO,小语种SEO,西班牙语SEO

> **TLDR**：摘要：西班牙语在AI问答里被当成一门语言处理，可同一件商品在马德里、墨西哥城和布宜诺斯艾利斯是三个词。传统搜索里地区差别有hreflang和ccTLD替你承载，到了这一层它只剩一条通道——用户自己在问句里打出来的那个词。这篇讲清分歧到底出在检索侧还是生成侧、哪些词才真会把三个变体分开、分叉率怎么算，以及什么时候该拆页面、什么时候完全不必。

> 摘要：西班牙语在AI问答里被当成一门语言处理，可同一件商品在马德里、墨西哥城和布宜诺斯艾利斯是三个词。传统搜索里地区差别有hreflang和ccTLD替你承载，到了这一层它只剩一条通道——用户自己在问句里打出来的那个词。这篇讲清分歧到底出在检索侧还是生成侧、哪些词才真会把三个变体分开、分叉率怎么算，以及什么时候该拆页面、什么时候完全不必。

## 为什么地区定向到了AI问答这一层突然没了着落？

## hreflang和ccTLD原本是说给谁听的

先把旧的那套机制摆清楚，才看得出新的这一层少了什么。

做西班牙语市场的团队，手上一般有三样地区定向的工具。

一是hreflang标注，告诉爬虫哪个URL是给哪个地区的。

二是域名结构，用.es和.mx这样的国家顶级域把市场分开。

三是内容本身，价格、支付方式、配送时效都按当地写。

这三样有一个共同点：它们全是站点属性，是你主动声明出去的，声明完就存在那里，等着引擎来读。

整套地区定向的前提，是有一个地方能把你的声明存下来，并且在排序的时候读一次。传统搜索恰好提供了这个地方：索引库里每个URL都带着一组地区与语言的标记，用户发起一次搜索，引擎手上同时有查询词、用户所在地、用户界面语言三样输入，拿它们去比对索引里的标记。你的声明在这个比对里是有位置的。hreflang那一整套规则 (https://zhangwenbao.com/international-seo-hreflang-complete-guide.html)之所以复杂到需要单独一篇讲，就是因为它要覆盖这个比对里所有的边界情况。

## 一次问答里根本没有地区这个字段

换到AI问答，输入的形态变了。

用户打进去的是一整句话，不是几个关键词。

系统拿这句话去做检索，召回一批候选文档，再让模型基于这批文档写答案。

这条链路上，地区信息只可能从两个地方进来。

一个是平台自己掌握的用户位置，一个是问句里的语言线索。

前者平台确实有，但它主要用来决定给你哪个版本的产品界面，不会逐条传给检索器当硬过滤条件。

结果是你精心配好的地区声明，在这一层没有一个明确的读取点。它不是被忽略了，而是这条链路上不存在那个专门读它的环节——检索器拿到的是一段文本，它做的是把这段文本跟文档做语义匹配，匹配过程里没有一个叫作地区的槽位。你的.mx域名和hreflang标注仍然在页面上，仍然被爬虫记录，只是在这一次问答里，它们没有参与任何一个决策。

## 页面属性退化成了查询属性

这是本文最想让你记住的一句话。

过去你能主动声明这一页是给墨西哥人的。

现在你只能等着墨西哥用户碰巧用墨西哥的词来提问。

主动权从站点这边，整块挪到了用户那边。

换个说法：地区定向从一个你可以配置的字段，变成了一个你只能命中的条件。

这个变化听着抽象，但它直接决定了你该把预算花在哪里——配置类的活儿收益下降，命中类的活儿收益上升。

命中类的活儿只有一种形态：让当地人真正会用的那个词，出现在你的正文里，出现在检索器能匹配到的位置上。不是出现在keywords标签里，不是出现在alt属性里，是出现在句子里，跟商品、场景、问题绑在一起。这跟关键词表可以一字不差、落地页却得拆成两种 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)那篇讲的是同一件事的两个阶段：那时候拆的是页面，现在拆的是句子里的词。

## 同一个问题用三种西语问，变的到底是什么？

## 答案主体几乎一样，来源清单不一样

这是实测里最反直觉的一条。

拿一个具体问题跑三遍，问句分别用西班牙、墨西哥、阿根廷的说法。

你会预期拿到三段不同的文字。

实际拿到的三段文字在意思上高度接近，措辞差别不大。

真正明显不同的是底下那份来源清单。

三次问答挂出来的域名重合度经常只有一半，有时候更低。

这说明变体差异在这条链路上生效的位置，比多数人以为的要靠前。它不是在生成那一步影响措辞，而是在检索那一步影响了召回哪一批文档。检索器拿着含有carro这个词的问句去匹配，命中的自然是正文里写carro的页面；换成coche，命中的就换了一批。模型拿到的原料变了，输出的措辞反而因为被规整过而看不出差别。

样本量上有个经验值可以直接抄：每个问题跑三轮取并集，三十条问题就是二百七十次问答，一个人一天能跑完。低于三轮的结果抖动太大，超过五轮的边际信息几乎为零。墨西哥的数字生态年度报告 (https://datareportal.com/reports/digital-2025-mexico)里那组搜索行为数据可以帮你判断该把问题设计成什么形态，那边的移动端占比高得多，问句普遍更短。

## 分歧发生在检索侧不在生成侧

把位置定下来，事情的性质就完全变了。

如果分歧出在生成侧，那是模型的语体偏好问题。

模型偏好哪种西语，你干预不了，只能等厂商调。

如果分歧出在检索侧，那是候选池的构成问题。

候选池装什么，取决于网上有哪些页面，而你可以往里放页面。

同一个现象，归因到两个不同的环节，得到的行动清单一个是等，一个是干。

这条判据可以推广到所有跟AI问答有关的现象：先问它发生在检索侧还是生成侧，再决定要不要动手。检索侧的问题几乎都能用内容解决，生成侧的问题基本只能绕。回答语言和来源语言是两个独立字段 (https://zhangwenbao.com/ai-search-language-bias-low-resource-citation-source-audit.html)那篇讲的偏差也是检索侧的，所以那篇给出的动作也是往池子里放东西。归错了环节，最典型的后果是团队开始写公关稿，而不是写内容。

## 这个区分决定你能不能动手

再往下推一层。

检索侧的问题有一个很实用的性质：它是局部的。

你不需要改变整门语言的处境，只需要在你这个品类里被召回。

品类越窄，候选文档越少，你一篇内容占的份额越大。

这跟小语种问答长尾那篇 (https://zhangwenbao.com/minor-language-qa-long-tail-content-value-ai-era.html)算的是同一笔账。

西班牙语整体不是小语种，但西班牙语加上某个具体品类加上某个地区说法，供给密度可能低得惊人。

把这三个条件叠起来，是西语市场里少数还剩空场的地方。整门语言的头部内容早被大站占满，可一旦你把查询限定到阿根廷人会用的那个词，再限定到一个具体的商品问题，认真写过完整回答的页面往往一只手数得过来。这不是因为需求小，而是因为做内容的人普遍按标准西语写，写完就当整个西语世界都覆盖了。

供给密度这件事有个粗糙但够用的外部参照：全网文档的语言分布本身就极不均匀，而Common Crawl按语言统计的文档分布图 (https://commoncrawl.github.io/cc-crawl-statistics/plots/languages)只到语种一级，再往下的地区变体连统计口径都没有。也就是说这一层的稀缺程度，连一个能查的数字都不存在，只能靠你自己数结果页。

## 怎么用十条问题把它测出来

方法很土，但结论可靠。

挑十个你这个品类下真实存在的用户问题。

每个问题写三个版本，只替换变体标记词，其余措辞完全不动。

三个版本各问一遍，把答案和来源清单都存下来。

然后只做一件事：数三份来源清单的域名重合度。

重合度高，说明这个问题上三个变体在这一层是同一门语言；重合度低，说明它们被分开了。

整套测试的关键在于只替换标记词这一条纪律，一旦顺手把整句话改得更地道，你就测不出任何东西了。这是跨语言实测那篇 (https://zhangwenbao.com/ai-search-language-bias-low-resource-citation-source-audit.html)踩过的同一个坑的变体：那边是翻译时手痒改问题，这边是本地化时手痒改语序。变量不干净，跑出来的数字就只是好看，不能拿来做决策。测完记得把三份清单里各自独有的域名单独列一列，那批域名就是这个变体的本地供给方。

## 哪些词才会真的把三个变体分开？

## 变体标记词是一小撮不是一大片

很多人对西语变体的印象是差别到处都是。

真去数就会发现，能改变检索结果的词其实相当有限。

语法差别几乎不进关键词，voseo那类人称变化改的是动词形态。

用户提问时用的是名词短语，动词形态影响很小。

发音差别更不用说，打字的时候完全不体现。

真正会分家的是名词，而且集中在少数几类：日常用品、交通工具、身体部位、食物。

换句话说，变体分化是词汇现象而不是语法现象，而词汇现象是有边界、可以穷举的。这跟德语的复合词或者芬兰语的格变化完全不同——那两类是构词规则在起作用，规则能生成无穷多形态，你只能靠算法覆盖；西语的变体标记词是一张有限的清单，人工列一遍就完事。西班牙人和墨西哥人搜的不是一个词 (https://zhangwenbao.com/spanish-seo-es-es-latam-keyword-divergence.html)那篇当年列的就是这张清单的搜索版本，只是当时它的用途是分ccTLD，现在它的用途变成了铺进正文。

想验证词汇与语法这条分界是不是真的成立，可以翻一遍公开的西语树库标注。Universal Dependencies的西班牙语数据集 (https://universaldependencies.org/es/index.html)把词性、句法关系都标了出来，你会发现地区差异集中落在名词与少量动词形态上，句法结构那一层几乎看不出分歧，这正是变体清单能被穷举的原因。

## 汽车配件品类里的标记词长什么样

拿保哥去年接触的一个做汽车改装件的客户举例。

这家原本只做西班牙市场，后来想把墨西哥和阿根廷一起吃下来。

他们先做的事情是把整个品类词表按三个地区列成对照表。

车本身：coche在西班牙、carro在墨西哥、auto在阿根廷。

轮胎：neumático在西班牙，llanta在墨西哥，两边阿根廷都用。

后备箱：maletero、cajuela、baúl，三个地区三个词，一个都不重样。

但同一张表里，刹车片、机油、火花塞、避震器这几项三地写法完全一致。列到一半就能看出规律：越是专业零件，越倾向于用同一个术语，因为它们进入西语的路径是技术手册而不是日常口语；越是普通人天天挂在嘴边的部件，分化越厉害。这条规律对选品类有直接的指导意义——纯专业件的品类几乎不用管变体，日用件的品类必须管。

专业件与日用件的界线怎么划，有一个不用请教语言学家的办法：看这个词是先进入维修手册还是先进入日常对话。前者的传播路径是印刷品和培训体系，全西语世界共用一份术语；后者的传播路径是口语，走到哪儿变到哪儿。判不准的时候查一下当地维修厂的报价单，报价单上的写法基本就是专业口径。

## 大多数查询里一个标记词都没有

这是数完之后最让人松一口气的发现。

把一百条真实查询摊开，逐条检查有没有标记词。

那家改装件客户的结果是十七条含标记词，其余八十三条不含。

不含标记词的查询，三个变体在检索这一层就是同一句话。

那八十三条上你不需要做任何变体相关的工作。

预算应该全压在那十七条上，而不是均匀地摊到整个词表。

可惜实际操作里最常见的做法恰恰是均匀摊：整站复制三份，逐字做地区化，成本翻三倍而收益只落在十七分之一的查询上。更麻烦的是复制出来的三份内容在信息层是同一份，正好撞上一个模板生成十种语言、字符层看不出重复而信息层十份一样 (https://zhangwenbao.com/multilingual-template-ten-languages-duplicate-content-risk.html)那篇讲的问题，钱花了，还多背一份重复内容的风险。

那八十三条也不是完全干净，里面还藏着一类更隐蔽的差别：同一个词的拼写习惯与缩写方式。有的地区习惯把复合表达缩成两个字母，有的地区完整拼写；有的地区在数字与单位之间加符号，有的不加。这类差别不改变词本身，但会影响精确匹配，做词表时最好单独开一列记录，别跟变体词混在一起。

## 标记词是可数的，一小时能数完

把这件事讲成一个可执行的动作。

拿你现有的品类词表，一列一列过。

每个词问一句：西班牙、墨西哥、阿根廷三地是不是同一个说法。

不确定的词标出来，交给本地同事或者查一次美洲西班牙语学院协会的资料。

五百个词的表，两个人一小时能过完一遍。

过完之后你手上就有一个数字：分叉词占全表的百分之多少。

这个数字比任何一份行业报告都更能指导你的决策，因为它是你自己品类的真实数字，不是全行业的平均值。而且它便宜到不像话——一小时的人力，换一个能直接决定几十万预算怎么分的判据。保哥见过的情况是团队为要不要拆西语站开了三次会，每次会两小时，加起来的时间足够把这张表数六遍。会开完还是没定，因为会上讨论的全是原则问题，而原则问题需要数字才能收口。

词表的来源如果一时凑不齐，学界已经有现成的公开数据集可以借。Spanish is not just one这份西语方言识别数据集 (https://oa.upm.es/91162/3/S2352340925008108.pdf)覆盖了二十来个西语国家的词汇差异条目，可以直接拿来当种子表，再按自己的品类筛一遍。用别人的表当起点，比从零开始列快得多，但最终那一遍筛选必须自己做。

## 分叉率该怎么算，算出来又怎么用？

## 分叉率的定义与分母

定义要写死，否则不同人算出来的数不一样。

分子是含有变体标记词的查询条数。

分母是你真正打算覆盖的查询总条数。

注意分母不是词表长度，是查询条数。

同一个标记词可能出现在十条查询里，也可能只出现在一条里。

按词算会高估，按查询算才对得上实际影响面。

更严格一点的做法是给每条查询配上搜索量或者业务价值做加权，得到一个加权分叉率。因为有时候标记词恰好集中在最赚钱的那批查询上，条数占比只有一成，营收占比却过半，这时候按条数算会严重低估。小语种关键词工具返回的零是数据缺口不是需求缺口 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)那篇给的几种无数据估算法，在这里正好可以拿来补搜索量这一列。

## 三档决策线

数出来之后按三档处理。

分叉率低于百分之十：合成一套内容，把变体词当同义词铺进正文。

百分之十到三十：一套正文，分市场做FAQ和商品详情的局部替换。

高于百分之三十：认真考虑拆成两套或者三套。

三档之间的界线不是精确的，但量级是对的。

关键在于你现在有一个数字可以对着这三条线看，而不是凭感觉拍。

这三档跟北欧三语那篇的资产分层 (https://zhangwenbao.com/nordic-seo-swedish-norwegian-danish-content-sharing-boundary.html)是同一个思路，区别在于那边分层的依据是语言之间的距离，这边分层的依据是你自己品类里的一个可测数字。依据从外部属性换成了内部测量，好处是它随品类变化，同一家公司做汽车配件和做工业轴承，可以得出完全不同的结论，而按语言距离判断的话，两者会被迫用同一套方案。

三档之间还有一种常见的过渡状态：分叉率不高，但分叉的那几个词恰好是品类核心词。这时候按条数算会落进第一档，按业务价值算却接近第三档。处理办法是把核心词单独拎出来做页面级的处理，其余部分按第一档走。西班牙的数字生态年度报告 (https://datareportal.com/reports/digital-2025-spain)里的品类消费数据可以帮你判断哪些词算核心词。

## 低分叉率品类的正确做法

百分之十以下这一档，做法最省。

不拆站，不拆页，只在正文里补词。

补的方式不是在句尾堆一串同义词。

而是让不同的变体词各自出现在一个真实的句子里。

比如产品说明里写一遍coche，FAQ的问句里写一遍carro，尺寸表的说明里写一遍auto。

每个词都嵌在完整语境里，检索器能匹配，读者也不觉得别扭。

判断补得对不对，有一个很朴素的标准：把这段读给一个墨西哥人听，他不该觉得这段话是写给西班牙人然后硬塞了几个词进来的。这也是母语审校那篇 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)反复强调的那个判据的变形，只不过验收对象从整篇变成了单个句子。堆词的痕迹母语者一眼能看出来，而读者一旦察觉到你在讨好算法，信任成本比省下的那点检索收益贵得多。

补词还有一条容易被忽略的纪律：同一个变体词在一页里出现的次数要克制。检索器认的是它出现在有信息量的句子里，不是出现了几次；重复过头反而让整段读着像机器写的，母语审校那一关通不过。经验值是一个变体词全页出现两到三次，分布在不同的内容单元里，就已经足够。

## 高分叉率品类的拆分边界

百分之三十以上这一档，拆是值得的，但要拆得准。

拆的不是整站，是含标记词的那部分页面。

商品详情页、品类页、FAQ，这三类通常要拆。

关于我们、配送政策、支付方式，这几类按国家拆而不是按语言变体拆。

技术文档、安装教程、材料说明，多数情况不用拆。

拆完之后每一套的维护成本是长期的，所以拆之前要把维护责任先定下来。

保哥见过最典型的失败是拆得很积极、维护跟不上，半年后三套内容里有两套停留在初版，只有西班牙那套在更新。这时候局面比不拆还糟：搜索引擎和AI问答系统同时看到三份关于同一件事的不同说法，而其中两份是过时的。要判断你的团队撑不撑得住，一个简单的办法是看这套内容一年要改几次——一年改两次以内，拆得起；一年改十次以上，先别拆。

## 西班牙语到底有几个标准，谁说了算？

## 学院协会的泛西语规范管到哪一层

这一节回答一个常被问到的问题。

西班牙语有一套跨国的规范体系，由各国语言学院联合维护。

这套体系的立场是泛西语的，不把任何一国的用法定为唯一正确。

词典里会同时收录coche和carro，并标注各自的通行地区。

也就是说规范层承认多标准，它不替你做选择。

很多团队以为查一次权威词典就能定下用哪个词，实际查完发现两个都对。

规范层管的是哪个说法算合法，不管哪个说法在某地更常用，而后者才是关键词工作真正需要的信息。这个错位跟品牌名叫什么由当地用户的输入法定 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)那篇讲的是一回事：正字法归语言委员会管，主键归使用习惯管。查规范能帮你排除掉真正的错词，但选不出主词。

跨国词典的地区标注该怎么读，也有讲究。标注为某地通用，意思是那里能用而不是那里只用这个；没有标注的词通常是全域通行的。真正有用的信息是同一个概念下并列了几个词条，以及各自挂了哪些地区标签，把这两项抄下来就是一张现成的对照表雏形，比逐词去查释义快得多。

## 语言子标签给了一个折中

技术侧倒是给了一个折中方案。

语言子标签注册表里有一个专门的地区码代表拉丁美洲。

写成es-419，419是联合国给拉美地区的数字编码。

它的用途是当你不想逐国拆、又想跟欧洲西语分开时。

相当于把二十来个国家打包成一个变体。

对多数中小站来说，es-ES加es-419这两套已经够用了。

但要注意这个折中在语言层是有代价的：拉美内部本身也在分化，墨西哥和阿根廷之间的差别未必比墨西哥和西班牙之间小。llanta和cajuela在墨西哥通行，在阿根廷未必；voseo在阿根廷是日常，在墨西哥听着像外国人。所以es-419只是把成本从三份压到两份，不是把问题解决掉。判断够不够用的标准仍然是你自己那张分叉表——如果表里有大量墨阿两地不一致的词，es-419这一档就撑不住。

要弄清一个地区码到底包含哪些国家，得查区域包含关系的定义表。Unicode CLDR项目 (https://cldr.unicode.org/)维护的区域数据里明确列出了每个地区码下辖的国家清单，配置多语言站点时按它对一遍，能避免把某个国家漏在两个地区码之间的空档里，这类漏配在报表上表现为一批流量永远归不到任何市场。

## 规范层与输入层的分工

把两层的分工写清楚，日常决策会顺很多。

规范层负责的是稳定形态：URL里的slug、数据库里的排序键、日志里的归一化字段。

这些地方要的是唯一、可逆、不随地区变，用规范写法最合适。

输入层负责的是命中：正文、标题、FAQ、商品名。

这些地方要的是跟用户打出来的字对上，用当地写法最合适。

两层各管各的，互不干扰，也互不替代。

混淆这两层的典型症状是URL里塞满了当地俚语，或者正文里全是词典体的规范说法。前者会让站点结构在改版时寸步难行，后者会让内容在检索里整片失联。URL用本地字母还是拉丁转写 (https://zhangwenbao.com/minor-language-url-native-script-vs-latin-transliteration.html)那篇讨论的是书写系统层面的同一个分工，西语没有书写系统问题，但分工的逻辑一模一样。

归一化这一步在西语上比在别的语言上省事，但也不是零成本。带重音的字母有组合与预组合两种编码形态，肉眼完全一样，字符串比对却不相等。String.prototype.normalize这个标准方法 (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/normalize)就是用来把两种形态统一到一种的，做站内搜索和词表去重时必须先走这一步。

## 模型认得出变体吗，现有证据说到哪一步？

## 变体识别的公开评测怎么做的

这两年有几项针对西语变体的公开评测，值得看一眼。

做法通常是给模型一段文本，让它判断这段话来自哪个地区。

或者反过来，要求它用某个地区的说法生成一段文本。

评测集会覆盖伊比利亚半岛、墨西哥与中美洲、安第斯、加勒比、南锥体等几大片区。

还有专门为西语及西班牙境内其他语言建的排行榜，把变体当作一等公民来评。

这跟主流评测把西语当成一门语言整体打分，是完全不同的口径。

值得留意的是评测的任务形态跟你的业务场景并不一致：评测问的是模型能不能识别变体，而你关心的是检索器会不会因为一个词而召回不同的文档。前者测的是生成侧的能力，后者是检索侧的行为，两件事之间没有必然联系。所以看评测结论时，把它当作背景知识可以，直接拿来推断你的页面会不会被召回不行，那个还是得自己跑那十条问题。

另一类评测是从社会与文化维度切进去的。SESGO这套面向拉美语境的西语偏见评测框架 (https://arxiv.org/abs/2509.03329)专门构造了扎根本地文化的题目，而不是把英语题目翻译过来。它的方法论对做内容的人有直接启发：把英语测试直接译成通用西语，会漏掉整整一层地区特征，这跟直接把英文站译成西语站漏掉的东西是同一批。

## 哪几个变体最容易被认混

评测里有一个结论对做内容的人有用。

不是所有变体被识别的准确度都一样。

伊比利亚、墨西哥与中美洲、拉普拉塔河流域这几片，识别得相对准。

智利变体是公认的难点，模型经常把它归错。

原因不难猜：这几片的语料在网上的量差着好几个数量级。

语料多的变体，模型见过的样本多，边界画得清楚。

把这条结论翻译成业务语言：如果你的目标市场恰好是语料稀薄的那几个，你在正文里放的变体词起到的作用会更大，因为它是为数不多的信号之一。这跟直觉相反——很多人觉得模型识别得越差，做变体优化越没意义。实际正相反：模型识别得好的地方，它不靠你的词也能推断出地区；识别得差的地方，你写进正文的那个词就是它唯一的依据。稀薄反而是杠杆。

语料量的差距不只影响识别精度，还影响这门语言在整个技术栈里的位置。斯坦福人工智能指数年度报告 (https://hai.stanford.edu/ai-index/2025-ai-index-report)逐年记录的语言覆盖数据显示，模型能力在语种一级扩张得很快，可地区变体这一级几乎没有被单独统计过。没有统计就没有目标，没有目标就不会有专门的优化，这一层短期内不会自己变好。

## 认得出跟用得对不是一回事

再补一条容易被跳过的区分。

模型能识别一段文本属于哪个变体，是一种判别能力。

模型能持续用某个变体的说法生成整段回答，是一种生成能力。

评测里这两项的分数经常差很多。

判别做得不错的模型，生成时照样会滑回标准西语。

对你的影响是：即使用户用carro提问，答案里也可能出现coche。

这不影响你被召回，但会影响读者读完之后对答案的地域信任感。

能补救的地方在你自己的页面上：确保用户点进来之后，落地页用的是他熟悉的那个词。问答那一层的措辞你管不着，落地页这一层完全归你管，而后者才是转化发生的地方。这条对应落地页上那几个最像装饰的信任元素 (https://zhangwenbao.com/minor-language-landing-page-trust-signals-payment-address-support.html)那篇的结论：本地感是由一堆很具体的小东西堆出来的，词只是其中一个，但它是第一个被读到的。

## 正文里怎么写才能三个变体都命中？

## 同义词不是堆词，是写进句子

这一节讲具体写法。

最差的写法是在段末补一句：也叫carro、auto。

这种写法检索器不一定吃，读者一定觉得别扭。

好一点的写法是把不同变体词分配到不同的内容单元里。

产品描述用一个，使用场景段用另一个，FAQ里用第三个。

每个词都在自己的句子里承担真实的语义角色。

再进一步，可以用一句自然的说明把两个词绑在同一句里，比如在讲适配范围时写成某某车型的后备箱在部分市场也叫另一个名字，这类句子本身就是用户会搜的内容。这样做的额外好处是它同时服务了两类查询：既命中了用carro提问的人，也命中了那些在两个词之间犹豫、直接搜两个词有什么区别的人。后一类查询量不大，但意图极其明确，转化率通常高得离谱。

## 首段自足与变体词的位置

位置比数量重要。

检索器对文档开头的权重通常更高。

模型在摘取答案时也倾向于从靠前的段落里拿。

所以最重要的那个变体词，应该出现在首屏能读到的地方。

但不要三个词全塞进第一段，那会毁掉可读性。

第一段放目标市场最主要的那个，其余两个往后排。

如果你只做一个主市场，那这件事很简单；如果三个市场权重接近，就需要按流量做一次排序，把最大的那个放前面。这个取舍没有巧办法，位置是稀缺资源，稀缺资源就得按价值分配。顺带提醒一句，首段自足这条要求本身是从英语的语序假设里长出来的，在西语这种语序相对灵活的语言里执行起来没有阻力，换成谓语后置的语言就完全是另一回事了。

还有一条跟位置有关的细节：变体词最好落在段落的前半句，别放在长句的尾巴上。摘取答案时经常只取半句，尾巴那部分被砍掉的概率不低。同理，别把变体词放在括号里或者破折号后面的补充成分中，那两个位置在结构上就是可省略的，被丢掉的风险最高。

## FAQ是承载变体分歧最省的位置

这是性价比最高的一个位置。

FAQ天然是问句形态，跟AI问答的输入形态最接近。

一条FAQ就是一个完整的问答对，检索器很容易整段召回。

而且FAQ的问句里换一个变体词，几乎不影响整篇的语感。

你可以让七条FAQ的问句分别使用不同地区的说法。

读者不会觉得奇怪，因为FAQ本来就是模拟不同用户的提问。

这一招的效果在窄品类里尤其明显，因为窄品类下认真写过FAQ的页面本来就少，你多覆盖一个变体，就多占一个几乎没人竞争的位置。操作上有个小纪律：问句里换词，答句里要把两个词都提一次，这样无论用户用哪个词提问，召回之后模型都能在答案里找到对应的表述。只在问句里换而答句不呼应，召回率上去了，命中率不一定跟着上去。

FAQ的条数也要控制。七条上下最合适，超过十二条之后单条被完整召回的概率反而下降，因为整块内容太长，检索器倾向于切段，切完就不是完整问答对了。宁可分两页各写七条，也别在一页里堆二十条。这条经验在窄品类里尤其重要，那里本来就没有多少条真问题值得写。

## 什么时候该拆页面

补一条拆与不拆的具体判据。

如果三地的商品型号、规格、认证都一样，不拆。

如果价格和配送不同但商品一样，通常也不拆，用动态字段处理。

如果三地卖的根本不是同一批SKU，那必须拆，而且拆的理由跟语言无关。

如果三地有各自的法定标注要求，拆。

换句话说，拆的理由优先来自商品和合规，其次才是语言。

把这个顺序搞反是常见错误：先因为语言差异拆了页面，然后发现商品其实一样，三套页面维护成三份内容债。正确的顺序是先看商品和法规，如果它们已经逼你拆了，语言变体顺便处理掉；如果它们没逼你拆，那就只在句子层面处理变体，别动结构。结构性的决策一旦做出来，回退成本远高于内容层面的调整。

## 技术字段还要不要按变体配？

## hreflang依然要配，只是收益变了

这个问题问得很多，答案是要配。

传统搜索的份额仍然巨大，hreflang在那一侧的作用没变。

变的是它在AI问答这一侧几乎不起作用。

所以它从一个双重收益的动作，变成了单重收益的动作。

成本没变，收益少了一半，但仍然远大于零。

结论是继续配，只是别再把预算按老比例往它上面倾斜。

更实际的调整是把原本准备用来精细化hreflang的那部分工时，挪去做正文里的变体词覆盖。两者的性质截然不同：hreflang是配置类工作，做对了就到头，没有边际收益；正文覆盖是内容类工作，每多一条查询被命中就多一份收益。在一个配置读取点正在消失的环境里，把资源从配置挪向内容，是一次方向明确的再分配。

## 结构化数据里语言字段写到哪一级

这一项有具体写法。

页面的语言字段建议写到地区一级，不要只写语种。

写es-MX比只写es携带的信息多，成本却一样。

如果你走的是拉美打包方案，写es-419。

不要在同一个站里混用两种粒度，否则数据消费方会困惑。

这一条跟AI问答关系不大，主要服务于传统搜索和你自己的数据分析。

值得展开的是正文越本地化越好、结构化数据里却要反着写回国际格式 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)那篇给出的那条原则：可见内容按用户习惯写，机器字段按国际标准写。西语的变体问题正好落在这条原则的两侧——正文里你要写carro，结构化数据里你要写es-MX，两者都不是对方的替代。有团队试过在结构化数据里塞变体词当别名，那是把两层的职责搅在一起，除了让数据变脏没有别的效果。

粒度的选择还牵涉到本地化数据的取值。Unicode地区数据标记语言规范 (https://www.unicode.org/reports/tr35/tr35.html)定义了从语言到脚本到地区的完整层级，日期格式、数字分隔符、货币写法这些都按这个层级取值。只写语种会让系统退回默认值，而西语的默认值通常是欧洲口径，小数点和千位分隔符一旦按欧洲写，拉美读者读价格会顿一下。

## URL与slug要不要带地区

这一项按站点规模判断。

单站多语言的架构下，URL里通常已经有语言段。

要不要把语言段扩成语言加地区，取决于你是不是真的有多套内容。

只有一套内容却分了三个地区路径，会制造大量重复。

真有三套内容，那地区段是必须的。

slug本身建议一律用规范写法，不要用变体词做slug。

理由是slug是稳定形态，而变体词的通行度会随时间漂移，今天在墨西哥更常用的词，五年后未必还是。把会变的东西固化进URL，等于给未来的自己埋一次迁移工作。规范写法虽然搜索命中率低一些，但slug本来就不承担命中职责，那是正文的活儿。这条分工跟上一节讲的规范层与输入层是同一条线，只是落到了具体字段上。

## 拿什么指标验收，多久看一次？

## 来源清单重合度

第一个指标是最能反映本质的。

做法是固定一组问题，三个变体各问一遍。

把三份来源清单的域名取交集与并集。

交集除以并集，得到一个零到一之间的数。

数字接近一，说明三个变体在这一层没被分开。

数字很低，说明分开了，而且你需要在每一侧都有存在感。

这个指标的好处是它不需要你能查到任何后台数据，纯靠观察结果页就能算，属于自己能测的那类稀缺指标。缺点是单次结果有抖动，需要多跑几轮取平均。实践中跑三轮就够看出量级，跑十轮才能看趋势。记录时要把日期和使用的模型版本一起存下来，否则几个月后回看时无法解释数字为什么变了。

## 变体词覆盖率

第二个指标衡量的是你自己做到了多少。

分子是你的正文里实际出现过的标记词数量。

分母是那张分叉表里的标记词总数。

这个数字应该逐月上升，直到接近满分。

它是一个纯执行指标，跟外部环境无关。

好处是团队能直接为它负责，坏处是它高不代表效果好。

所以这两个指标必须成对看：覆盖率是你的输入，重合度变化是外部的反应，只看前者会陷入自我感觉良好，只看后者会因为归因不清而放弃。把两条线画在同一张图上，横轴是时间，你能很快看出投入和产出之间的时滞有多长。多数品类下这个时滞在四到八周之间，短于四周的观察基本是噪声。

分母还需要定期更新。分叉表不是一次性资产，新品上线会带进新词，市场用语也会缓慢漂移。建议每半年重跑一次，重跑时把上一版的表留着做对比，看看哪些词的地区标注变了。变化本身是有信息量的：一个词从分叉变成统一，往往说明某个平台的界面用语在这几年里统一了本地习惯。

## 复测频率与噪声

最后说频率。

建议按季度做完整复测，按月做小样本抽查。

完整复测是三十条问题乘三个变体，九十次问答。

抽查是十条问题乘三个变体，三十次。

抽查只看有没有明显异动，不做结论。

频率再高没有意义，因为内容侧的动作本身就是以月为单位见效的。

还有一个容易忽略的噪声源：模型版本更新。厂商换一次底层模型，来源清单可能整体变一遍，这时候你看到的波动跟你的内容毫无关系。所以每次记录都要带上测试日期，遇到大幅异动先去查那段时间有没有平台侧的更新公告，确认没有再去查自己的内容。把这个检查放在归因流程的第一步，能省掉大量的无效排查。

## 按这套做法走过一遍之后，哪些预期落空了

## 只按西班牙口径写完的那套词表

回到前面那个汽车改装件的客户。

他们最初的状态是典型的：西语站一套，全按西班牙的说法写。

团队认为西语是一门语言，写一套就够了。

墨西哥和阿根廷的流量确实有，但一直不温不火。

直到有人去查了一次AI问答的表现，才发现墨西哥那边的问题下自家页面一次都没出现。

而西班牙那边的同类问题，出现频率相当正常。

最刺眼的一点是他们的墨西哥站配置一点问题没有：hreflang对、域名对、货币对、配送信息也对。所有能配置的东西都配好了，唯独没人想过正文里那几个词是西班牙说法。这就是本文开头那句话的具体样子——配置类的活儿做满分，命中类的活儿是零分，而这一层只认后者。团队当时的第一反应是怀疑技术出了问题，排查了两周，技术一切正常。

那两周的排查过程也值得记一笔。团队按常规思路依次查了收录状态、结构化数据、爬虫抓取日志、页面速度，全部正常；又怀疑是不是被平台限制了某个地区的曝光，找渠道问了一圈也没有结论。所有排查都在配置这一层打转，因为在他们的认知里，内容那一层已经交付完毕了。

## 把标记词铺进正文之后发生了什么

后面的动作不复杂。

数出分叉表，十七条含标记词的查询挑出来。

对应的十九个页面逐个改，把墨西哥说法写进产品描述和FAQ。

没有拆站，没有加页面，只改了正文。

大约六周之后，那批问题下开始零星出现自家域名。

再过一个季度，来源清单重合度从很低回到了中等水平。

但有两个预期落空了，值得记下来。一是阿根廷那一侧几乎没有改善，原因是他们当时的分叉表只做了西墨对照，阿根廷的说法压根没进表，等于那一侧一个动作都没做；二是流量的增长远小于问答曝光的增长，因为AI问答里被引用不等于用户会点进来，这中间还隔着一整段转化。AI引用单靠传统SEO够不够 (https://zhangwenbao.com/ai-citation-via-traditional-seo.html)那篇讨论的那条边界，在这个案例里以一种很朴素的方式又出现了一次。

## 常见问题解答

## 西班牙语真的需要按国家拆吗，不是同一门语言吗？

是同一门语言，但要不要拆不取决于是不是同一门语言，取决于你品类里含变体标记词的查询占比。先数一遍这个数字，低于一成就别拆，只在正文里补词；超过三成再认真考虑拆。绝大多数团队跳过了数数这一步，直接在拆与不拆之间凭感觉选，然后为这个感觉找理由。数一遍只要一小时，比开会便宜得多。

## 只做西班牙市场，还需要管拉美的说法吗？

取决于你的支付和配送覆盖到哪里。如果只发西班牙境内，不需要管，铺再多拉美词也换不来订单。但要注意西班牙境内有相当规模的拉美裔居民，他们的搜索用词往往保留原籍习惯，这部分人是能下单的。判断办法很直接：翻一遍近半年的站内搜索记录，看看有没有出现拉美说法的词，有就说明这批用户已经在你站上了。

## 把三个变体的词全堆进关键词标签里行不行？

不行，那个标签早就不参与排序了，在AI问答这一层更是完全读不到。检索器匹配的是正文的语义内容，标签里的词进不了这个匹配。真要覆盖变体词，唯一有效的位置是正文的句子里，其次是标题和FAQ的问句。这一条听起来像老生常谈，但每次做审计都还能碰到把变体词塞满标签然后以为已经覆盖了的站。

## 怎么确定一个词在某个国家是不是真的常用？

三个来源交叉验证。一是跨国词典的地区标注，它告诉你哪些说法是合法的；二是当地电商平台的商品标题，它告诉你商家实际在用哪个；三是当地社交平台上普通人的说法，它告诉你消费者用哪个。三者一致就可以定，不一致时以第二个为准，因为它离购买意图最近。查词典能排除错词，但选不出主词，这两件事经常被混为一谈。

## 如果预算只够做一件事，该做哪件？

做那张分叉表。它本身不产生任何流量，但它决定了后面所有动作的方向，而且是三件事里最便宜的。没有这张表，你要么在全站地区化上过度投入，要么完全不投入，两种极端都会错。有了这张表，即使你今年一个页面都不改，明年做规划时也知道钱该往哪儿放。判断类的投入通常比执行类的投入回报更高，就是因为它能防止把大笔执行预算投到错的方向上。

## 模型以后会不会自动处理好变体，让这些工作白做？

生成侧可能会越来越好，检索侧不会自动变好。生成侧靠模型能力，模型能力在涨；检索侧靠候选池里有什么文档，池子里没有本地说法的内容，模型再强也变不出来。所以这类工作的性质不是补模型的短板，而是往池子里放东西，放进去的东西不会因为模型升级而失效。真正会随时间贬值的是那些依赖当前排序规则的技巧，往池子里放内容不属于那一类。

## 这套方法能直接搬到葡萄牙语或者法语上吗？

框架能搬，具体清单不能。葡萄牙语的巴西与欧洲分化程度比西语更深，连正字法都动过；法语的加拿大一侧在术语上有官方推动的替换，跟西语那种自然分化不是一个成因。搬过去的时候，分叉率的定义、三档决策线、检索侧与生成侧的区分都成立，但标记词清单必须重新做，三档的界线也要按各自的分化程度重新校准。别把西语的一成三成直接套过去。

## 权威参考资料



## 网站上所有的字都是给用户读的，只有域名这一串要他自己打出来

- URL：https://zhangwenbao.com/idn-punycode-local-script-domain-input-trust.html
- 分类：小语种SEO
- 发布：2025-10-23  |  更新：2026-07-27
- 摘要：本地字母域名把第一次输入变简单，却把第二次传递变贵了。讲清同一串域名在地址栏、邮件、日志、二维码里为什么长成三副面孔，键盘布局而非语言决定能不能打出来，以及一条老掉牙的校验规则怎么让整条链退回原点。
- 关键词：国际化SEO,出海SEO,多语言SEO,小语种SEO

> **TLDR**：摘要：页面上的每一个字都是给用户读的，只有域名这一串要他自己打出来、念出来、抄给别人。本地字母的域名把第一次输入变简单了，却把第二次传递变贵了，而绝大多数访问恰好发生在第二次传递之后。同一个域名在地址栏、邮件正文、工单日志和二维码里会显示成三种不同的样子，注册商说支持不等于表单说支持，这条链上任何一环退回拉丁字母，整条链就一起退回去。

> 摘要：页面上的每一个字都是给用户读的，只有域名这一串要他自己打出来、念出来、抄给别人。本地字母的域名把第一次输入变简单了，却把第二次传递变贵了，而绝大多数访问恰好发生在第二次传递之后。同一个域名在地址栏、邮件正文、工单日志和二维码里会显示成三种不同的样子，注册商说支持不等于表单说支持，这条链上任何一环退回拉丁字母，整条链就一起退回去。

## 为什么域名是全站唯一一串要用户亲手复现的字？

先把这件事的特殊性说清楚，后面所有的判断都从它长出来。

## 页面上的字用户只需要认，域名要他打出来

做本地化的人有一个默认前提，很少有人把它说出口。

那个前提是：内容做得越贴近母语，用户的理解成本就越低。

标题、正文、按钮文案、图片替代文字、结构化数据，全都符合这条规律。

用户面对它们时只做一个动作，就是认。

认不需要精确，看个大概意思就够了，看错一个字母也不影响下单。

域名不一样，它要求的动作是复现。

复现是全站唯一一个要求百分之百精确的动作，错一个字符就是另一个网站，或者干脆什么都打不开。这个差别听着抽象，落到实操上却很硬：正文里把某个词写成不太地道的说法，损失是几个百分点的转化；域名里少一个变音符号，损失是整次访问。所以域名这一层的判据不能从内容本地化那套规律里直接搬过来，得单独立一套。这也是这篇文章跟本栏目其它篇最不一样的地方，别的话题都在讨论怎么写得更像本地人，这一篇要讨论的是怎么让本地人能把它打出来。

## 复现有四种动作，成本各不相同

把复现拆开，会发现它其实是四件事。

第一种是打，用户看见广告或者名片，在地址栏里逐字敲。

第二种是念，销售在电话里把网址念给客户，客户在另一头写。

第三种是抄，从纸质物料、包装盒、展会易拉宝上照着抄。

第四种是转发，把链接复制粘贴进聊天窗口或者邮件。

四种动作的失败率完全不同，而且跟域名用什么字母强相关。

拉丁字母的域名在四种动作上表现平均，本地字母的域名在第一种上明显更快，在第二三四种上明显更慢，这个反差就是整个决策的核心。更麻烦的是，这四种动作在数据后台的可见度也不一样：打进来的算直接流量，转发进来的算引荐流量，念和抄两种在报表里根本看不见，它们只会以直接流量的形式出现，跟第一种混在一起。所以你在报表里看到的直接流量涨了，可能是输入变简单了，也可能只是有人在电话里念对了，两者要用的对策相反。

## 这条判据把域名从本地化的通则里摘了出来

结论可以写成一句能背下来的话。

凡是用户只需要认的地方，越本地化越好。

凡是需要用户复现的地方，先问他手上有没有复现的工具。

工具在这里指两样东西，一是键盘，二是嘴。

这两样东西不归你管，也不归内容团队管。

它们由用户所在国家的输入法生态和这门语言的读音规则决定。

换个说法：本地化的其它一切都是你单方面能做完的事，只有域名这一件，得看对面手上有什么。这条判据顺手还能解释一个长期让人困惑的现象——为什么很多本地字母的域名注册了却没被真正用起来。不是注册的人不懂本地化，恰恰相反，多半是他们非常懂，只是在测试阶段发现了手上工具这一环过不去，于是把它退成了跳转域名。这个决策看起来保守，实际上是四种动作里那三种慢动作在替他做主。

## 同一个域名在四条管道里为什么显示成三种样子？

这是本地字母域名最容易被低估的一处代价，它不是技术问题，是可见性问题。

## 地址栏看到的是解码之后的样子

浏览器地址栏会把本地字母域名显示成好看的形态。

用户看到的是магазин.рф，而不是那串以xn--开头的东西。

这层显示是浏览器主动做的一件好事，属于展示层的礼貌。

但它只在浏览器地址栏这一个位置成立。

离开这个位置，礼貌就不一定跟着走。

而绝大多数关于域名好不好用的判断，恰恰是在这个位置上做出来的。

决策会议上大家盯着投影里的地址栏点头，那一刻看到的是这个域名一辈子最好看的一次亮相。这跟给模特试衣服差不多，试衣间的灯光永远比家里的好。真正要评估的是它在别处长什么样，而别处的样子没人会主动拿到会上放。建议的做法很朴素：把同一个域名分别贴进邮件客户端、企业微信、工单系统、日志导出的表格里，各截一张图，四张图放在一页上，再开那个会。多数团队看完这一页就不需要讨论了。

## 邮件、工单与日志里是原样的编码形态

换个管道，样子就变了。

邮件客户端为了防钓鱼，常常把这类域名显示成编码形态。

工单系统、客服后台、日志文件里几乎一定是编码形态。

服务器日志记录的是协议层实际传输的那一串。

引荐来源字段里也是编码形态，做外链盘点时会看到一堆xn--。

这意味着同一个品牌在两个系统里长成了两个不同的字符串。

更实际的麻烦是搜索与匹配：客服想搜某个域名相关的工单，用本地字母搜不到，用编码形态搜才有结果，而客服并不知道编码形态长什么样。这一条在支持团队规模超过五个人之后会稳定地制造摩擦。有个卖俄语市场文创礼品的团队踩过这个坑，他们的工单系统里三个月积了两百多条跟域名有关的记录，做季度复盘时按本地字母搜出来十几条，以为问题不大，后来换成编码形态一搜，两百多条全在。这中间差的不是数据，是没人知道该用哪一串去搜。

## 二维码、截图与印刷物取决于生成它的那个工具

第三类管道最不可控。

二维码里存的是一段文本，具体存哪种形态由生成工具决定。

有的工具原样保留本地字母，有的会先转成编码形态再存。

扫码之后跳转都能成，但用户在扫码提示框里看到的字不一样。

包装盒和易拉宝上的字由设计稿决定，设计师通常照着最好看的那个形态排。

于是印刷物上是本地字母，用户打开扫码结果看到的是编码形态。

这个不一致在信任层面的伤害比技术层面大得多，因为用户没有能力判断它们是同一个东西。一个更隐蔽的变体出现在线下：客户拿手机拍下展会背板上的网址，回酒店照着照片输入，输入法自动纠错把某个带变音符号的字母改成了不带的那个，然后打开一个空白页。这时候他不会怀疑输入法，只会怀疑这家公司。信任信号这件事在小语种市场本来就更值钱，本栏目在落地页信任元素那一篇 (https://zhangwenbao.com/minor-language-landing-page-trust-signals-payment-address-support.html)里算过它的搜索量，域名这一层属于同一笔账，只是没人把它算进去。

## 本地字母的域名到底是怎么变成那串xn--的？

机制这一段不长，但不讲清楚，后面的取舍会变成玄学。

## 域名系统只认一个很窄的字符集合

域名解析这套东西比网页早很多年。

它当年设计时假定的字符集合只有字母、数字和连字符。

所有非拉丁字符要进这套系统，必须先压进这个集合。

压缩算法的名字叫Punycode，写在RFC 3492里。

转出来的结果统一以xn--打头，后面跟一串看着像乱码的字符。

俄语的рф转出来是xn--p1ai，中文的中国是xn--fiqs8s。

这套算法的关键性质是可逆且确定：同一串本地字母永远转出同一串编码，反过来也一样，所以它不是加密，只是换了一种写法。可逆这一点常被误读成没有代价。代价在长度上：域名每一段的字节上限是63个字符，本地字母压缩之后膨胀得很厉害，一个由三四个词组成的长品牌名，本地字母写着不长，转完可能顶到上限。RFC 3492对Punycode的完整定义 (https://www.rfc-editor.org/rfc/rfc3492)里有算法伪码，实操上不需要读懂，但要知道长品牌名在这一层是有硬顶的。

还有一条容易被忽略的实际后果：这个字符集合的窄，不只是窄在字母上，也窄在它对每一段长度的硬性规定上，而各语言压缩之后的膨胀倍数差得很远，同样是三个词的品牌名，有的语种转完还剩一半余量，有的直接顶死，这个数只能一个一个真的转一遍才知道，互联网号码分配机构维护的各语种可用字符表 (https://www.iana.org/domains/idn-tables)是查这件事的起点。

## 转换之前那道预处理比转换本身更容易出事

真正的坑不在压缩，在压缩之前。

同一个字在Unicode里常常有多种码位写法。

带变音符号的字母可以是一个码位，也可以是基字母加组合符号两个码位。

两种写法屏幕上完全一样，压缩出来的编码却不同。

所以转换之前必须先做统一化处理，把写法归到一种。

大小写、全角半角、某些兼容字符也在这一步一起处理掉。

这套预处理有专门的规范在管，它规定了哪些字符允许、哪些必须映射、哪些直接禁止，不按流程走可能生成一个语法合法但解析不到的域名。症状很折磨人：域名在你自己电脑上能打开，换台机器就不行；从某个网站上复制过来能打开，手打就不行。排查的时候多数人会去查DNS、查缓存、查证书，很少有人第一时间去比对两串字符的码位。UTS #46定义的IDNA兼容处理流程 (https://www.unicode.org/reports/tr46/)是这一层的权威文档，遇到这类灵异现象直接翻它。

预处理这一步还有一个跟品牌直接相关的坑：某些字符在规范里被划成了禁止使用，而它们恰好在那门语言的日常书写里很常见，于是一个在广告里印得好好的写法，压根注册不成域名，RFC 5892里那份逐码位的允许与禁止清单 (https://www.rfc-editor.org/rfc/rfc5892)是唯一的判据，起名阶段就该拿它过一遍，别等到去注册商那里被驳回才发现。

## 这跟路径上的百分号编码不是一回事

域名和路径走的是两套完全不同的机制。

域名要过解析系统，所以需要压缩算法。

路径不过解析系统，由服务器自己解释，直接用字节的百分号表示就行。

两者可以任意组合，本地字母域名配拉丁路径完全成立。

反过来拉丁域名配本地字母路径也很常见。

最常见的误解是以为域名能用本地字母，路径就自动能用。

把这两层混在一起最直接的后果是排查方向错，症状相似而工具完全不同，找错方向能耗掉一整天。路径那半边的取舍另有一整套账要算——展开长度、多套转写标准、外链落空、排序去重的碰撞，本栏目在小语种URL用本地字母还是拉丁转写那一篇 (https://zhangwenbao.com/minor-language-url-native-script-vs-latin-transliteration.html)里从头算过一遍，这里不重复。这一篇只管域名那一段，而且只管它在人手里怎么流转，不管它在服务器里怎么解析。

## 用户手上的那副键盘，打得出这个域名吗？

这是整篇里最该先做、也最容易被跳过的一次实测。

## 可输入性是键盘布局的属性，不是语言的属性

先纠正一个说法上的偷懒。

我们习惯说俄语用户能打西里尔字母，希腊语用户能打希腊字母。

严格讲这句话没有主语，能打字的不是语言，是设备。

同一门语言的使用者，手上的键盘布局可能完全不同。

布局由操作系统的默认设置、所在国家、以及用户自己装过什么决定。

三个因素里没有一个跟语言本身有关。

把主语从语言换成设备，这个问题立刻从不可回答变成可以测量：拿目标市场的真实设备样本，数一数默认布局里有没有那套字母。本栏目在品牌名音译那一篇 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)里已经用过一次这套换主语的办法，那次的结论是主键归输入法管而不归正字法管；域名这一层是同一条判据的第二次应用，只是这次要管的不是搜索框里打什么，而是地址栏里打什么。两者的区别在于搜索框允许打错，地址栏不允许。

把主语换成设备之后还有一个附带收获，就是这个问题从此可以被排期：设备样本是能采的，采样方法跟做兼容性测试一样成熟，而语言这个主语永远排不了期，因为没人知道该测什么。凡是一个问题长期停在讨论阶段没人动手，先检查它的主语是不是抽象名词，把主语换成一个能被计数的东西，多半当天就能开工。

## 同一门语言在不同国家的默认布局不一样

把范围收窄到一门语言，差异照样存在。

俄语在俄罗斯的默认布局是ЙЦУКЕН，绝大多数设备开箱即用。

在哈萨克斯坦、白俄罗斯这些地方，双布局是常态。

在移民社群里，不少人手上根本没装西里尔布局。

他们平时用拉丁转写打字，看得懂西里尔但打不出来。

这批人的规模在某些品类里不小，而且客单价往往更高。

所以本地字母域名的可输入性不该给一门语言打一个分，而该给这门语言的每个主要市场分别打一个分，分档而不是一刀切。俄语市场这个例子在本栏目里出现过好几次，早年那篇讲俄语读者散在十几个国家 (https://zhangwenbao.com/russian-language-market-seo-decision-after-2022-geopolitical-shift.html)的文章里区分过语言资产和市场资产，键盘布局是一个很好的检验：它明明是语言相关的东西，却完全绑在设备所在的国家上，属于典型的市场资产。这也说明语言和市场这两个字段确实不能合并。

## 移动端和桌面端要分开算

还有一层切分不能省。

桌面端切换键盘布局需要按组合键，很多人不知道。

移动端切换输入法只要点一下地球键，成本低得多。

但移动端的地址栏输入本身就少，大部分访问来自点击。

于是两端的结论会打架：移动端更好打，却更少有人打。

桌面端更难打，但恰恰是手动输入网址的主要场景。

拆开算之后通常会得到一个反直觉的排序：本地字母域名的输入优势，最大受益者是桌面端上那批装了本地布局的用户，而这批人占比正在逐年下降。把这句话说给做决策的人听，比给他们看任何一份规范都管用。顺带一提，这也是为什么关于本地字母域名的讨论在十几年前比现在热烈得多——那时候访问的主流方式确实是手打网址，而现在多数人连自己常去的网站域名都拼不全，全靠浏览器的历史记录补完。工具替我们记住了地址，也就顺手抹掉了本地字母域名最大的那份收益。

## 域名念出来之后，对方能不能拼回来？

口播这条链路几乎没人测，可它决定了线下渠道和电话销售能不能用这个域名。

## 三个本地同事，两小时能做完的一次实测

方法简单到有点土，但结论非常硬。

找三个母语同事，一个人念，另外两个人在纸上写。

念的人不许拼字母，只许像平常告诉朋友那样说一遍。

写完对照，统计完全一致的比例。

再换一组人重复一次，取两轮的低值。

整个过程两小时之内能做完，不需要任何工具。

这个测试的价值不在于给出一个精确的百分比，而在于它会当场暴露出到底是哪几个字符导致的错，而那几个字符往往可以直接换掉。实测里最常见的结果是分数意外地低，尤其当品牌名不是本语言里的现成词的时候。原因不难理解：母语者听一个不认识的词，脑子里会自动往最接近的熟词上靠，然后按那个词的拼法写下来。这跟他懂不懂这门语言无关，恰恰是因为太懂。相比之下把一串拉丁字母念给同一批人听，他们反而会老老实实一个一个字母地问。

这个测试还有一层附加价值，是它能顺便测出品牌名在这门语言里有没有不该有的联想。念的人会犹豫、会笑、会问一句你确定是这个词吗，这些反应在任何一份词典检查里都拿不到，只有真人开口才会出现。所以就算最后不打算用本地字母域名，这两小时也值得花一次，它测的是名字本身而不只是域名。

## 哪几类字符最容易听错

把出错点归类，就那么几种。

第一类是变音符号，听觉上完全不携带信息。

念的时候有没有那个符号听不出来，写的人只能靠猜。

第二类是同音异形的字母，某些语言里有两三个字母读音接近。

第三类是词与词的边界，听的人不知道该不该加连字符。

第四类是拉丁字母和本地字母混排的品牌名，听的人不知道哪一段该切换。

四类里前三类都能靠换名字解决，第四类不能，因为混排通常来自品牌本身，改它等于改品牌。混排还有一个更严重的后果留在后面讲，这里先记一笔。变音符号那一类在本栏目里反复出现过——法语重音符号那一篇 (https://zhangwenbao.com/french-seo-accents-quebec-keyword-variants.html)讲过用户搜索时普遍不打，越南语声调符号那一篇 (https://zhangwenbao.com/vietnamese-seo-tone-marks-syllable-spacing-keyword.html)讲过两拨用户各打各的。搜索框那一层可以靠做变体覆盖兜住，域名这一层兜不住，因为域名只有一个。

## 电话客服与线下门店是最先断的一环

把口播放到真实场景里，问题会放大。

电话里的语音质量本身就损失细节。

展会和门店有背景噪音，听清的难度更高。

客服培训手册里通常只写网址是什么，不写怎么念。

于是十个客服有十种念法，用户听到的版本各不相同。

这套损耗完全不会出现在任何一份数据报表里。

可行的补救是给域名配一套官方读法，写进客服话术，并规定必须以逐字母拼读收尾，就像航空业报呼号那样。听着有点小题大做，但只要电话渠道贡献了真实订单，这一页话术的投入产出比高得离谱。有个做宠物用品的团队更省事，直接在话术里放弃念域名，改成念一个全拉丁的短跳转域名，本地字母那个只在线上物料里用。这个做法很实用：同一个品牌，对眼睛用一套，对耳朵用另一套。

电话这条链路还有个反直觉的地方：它的损耗率跟客服的语言水平几乎无关，反而跟培训材料的写法强相关。母语很好的客服照样会按自己的习惯念，十个人十种口音；而一份规定了逐字母拼读顺序的话术，哪怕客服是外派的，拼对率也很高。这里要治的是流程不是人，跟绝大多数看起来像人的问题一样。

## 拼写提示怎么写进物料

物料这一层有几个便宜的动作。

印刷品上把域名和二维码并排放，让扫码成为默认路径。

视频和音频广告里，念完之后补一句逐字母拼读。

名片背面印一行拉丁转写形态，标明两个都能打开。

包装盒上如果空间紧张，优先保留二维码而不是域名文字。

展会背板上把域名字号放大到三米外能看清。

这些动作单看都很琐碎，合起来解决的是同一个问题：把复现动作从打和念，尽量挪到抄和扫这两种精度更高的动作上去。换个角度看，二维码其实是本地字母域名最好的朋友，它把复现这件事整个从人手里接管过去了。所以如果你的市场里扫码习惯很强，本地字母域名的劣势会小很多；如果目标市场的人不习惯扫码，那几种慢动作的权重就得往上调。这一条判断只要问一句本地同事就有答案，不用查任何报告。

## 为什么支持这个词在这条链上永远由最弱那一环说了算？

这一节是整篇里最值钱的一条，它能解释绝大多数上线之后才发现的意外。

## 四种支持是四件不同的事

先把支持这个词拆开。

注册商支持，指你能买到这个域名。

解析支持，指域名系统能正确解析它。

浏览器支持，指地址栏能正确显示和跳转。

应用支持，指各种软件里的输入框、正则、数据库愿意接受它。

前三件在十几年前就基本齐了，第四件到今天都没齐。

而用户实际能不能用，取决于这四件里最差的那一件，不是最好的那一件。这条在工程上有个更朴素的说法：链条的强度等于最弱一环。放到国际化域名这件事上，它有一个特别刺眼的表现形式——你花钱买下的那个域名，技术上完全可用，却在别人家的一个表单里被拒收，而那个表单你既改不了也找不到人改。整个互联网上有一个专门的组织在推动这件事的收尾工作，叫通用接受度推进组，它存在本身就说明这个问题没解决。

这四件事被同一个词盖住，本身就是这个领域最大的一处认知障碍，以至于有一个专门的国际组织在做的事情，几乎就是挨家挨户去提醒软件厂商把最后那一环补上，通用接受度推进组常年发布的评估用例 (https://uasg.tech/)可以直接拿来当自查清单，它列的那些失败场景，你的技术栈里多半也中了几条。

## 国际化邮箱地址是最典型的断点

最能说明问题的例子是邮箱。

技术上，邮箱地址的两边都可以是本地字符。

相关规范在2012年就定好了，服务器扩展叫SMTPUTF8。

但真正端到端支持的邮件系统至今是少数。

更常见的情形是你能收，对方发不出，或者对方能发，中间某个网关退信。

而退信提示往往含糊到看不出是这个原因。

于是出现一种很滑稽的局面：你注册了本地字母域名，却不敢用它开企业邮箱，只能另买一个拉丁域名专门收发邮件，一个品牌两套地址。这一步一旦做了，本地字母域名的品牌统一性就已经破了一半。RFC 6531定义的SMTP国际化扩展 (https://www.rfc-editor.org/rfc/rfc6531)把技术路径写得很清楚，问题从来不在规范，在于链路上每一跳都得实现它。邮件这条链路平均要过四五跳，每一跳都是一次抽签。

## 一条ASCII的正则能把整条链退回二十年前

最后一环通常是最不起眼的那个。

无数网站的注册表单里写着一条邮箱校验正则。

那条正则的字符类多半是拉丁字母加数字加几个符号。

它由某个开发者在很多年前从网上抄来，此后没人动过。

你的本地字母邮箱在它面前会被判成格式错误。

用户看到的提示只有一句请输入有效的邮箱地址。

一条谁都懒得改的正则，能让上游所有规范、所有注册局、所有浏览器厂商十几年的工作在这一格里归零。这就是为什么支持是链条属性而不是节点属性：每一个节点都可以诚实地说自己支持，链条依然不通。想验证这一点不需要写代码，拿一个本地字符的邮箱地址，去十个你目标市场常用的平台注册一遍，记下几个被拒。这个数字比任何一份兼容性报告都可信，因为它测的正是你的用户真实会走的那条路。

## 同形字符的风险，为什么跟本地字母域名是同一件事的两面？

这一节讲的是浏览器为什么有时候拒绝把你的域名显示成好看的样子。

## 浏览器为什么会强制显示成编码形态

浏览器面对本地字母域名有个两难。

显示成本地字母，用户友好，但可能被拿来冒充别的网站。

显示成编码形态，安全，但把本地字母域名的意义抹掉了。

各家的折中办法是设一套规则，只在满足条件时才显示成好看形态。

规则的核心是看这个域名混不混用多套文字系统。

不混用的通常放行，混用的多半强制显示成编码形态。

换句话说，你的域名能不能享受到本地字母的显示待遇，决定权在浏览器手上，而它的判断标准跟你的品牌意图毫无关系。这套判断标准是公开的，Chromium关于地址栏如何显示国际化域名的设计文档 (https://www.chromium.org/developers/design-documents/idn-in-google-chrome/)把条件一条条列了出来，上线前照着自查十分钟能查完。要提醒的是各家浏览器的规则不完全一样，所以必须在目标市场主流的那几个浏览器里各试一遍，只在一个里面看等于没看。

值得多说一句的是这套规则不是浏览器厂商拍脑袋定的，它背后有一整套关于文字系统混用风险的分析在支撑，Unicode官方关于国际化域名的常见问题页 (https://www.unicode.org/faq/idn.html)把这些取舍的来龙去脉讲得比任何二手文章都清楚。读一遍的好处是你会明白这条限制不会放松，规划品牌名的时候就不必再抱侥幸心理。

## 混用两种文字的品牌名最容易触发

触发这条规则的典型情形只有一种。

品牌名本身是拉丁字母，产品词或者地区词是本地字母。

团队觉得两个拼在一起既保留品牌又照顾本地，很聪明。

浏览器看到的是同一段里混了两套文字，直接判为可疑。

结果是用户看到一串xn--开头的乱码，第一反应是这网站不对劲。

本来想增加的亲切感，变成了减少的信任感。

这条规则的存在，等于把本地字母域名的可用范围收窄成一个很窄的口子：品牌名本身必须整个用本地字母写，混一半不如不混。这也解释了为什么真正把本地字母域名用起来的多是本土品牌而不是出海品牌——本土品牌的名字天然就是本地字母的。出海品牌带着一个拉丁品牌名过去，想在域名层面本地化，只有两条路，要么把品牌名整个音译成本地字母，要么放弃。音译这条路的代价在品牌名音译那一篇 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)里算过，不是一个小决定。

## 防守动作是把相近形态一起注册下来

同形字符还有另一面，是被别人利用。

某些西里尔字母和拉丁字母长得一模一样。

用它们可以拼出一个视觉上跟你完全相同的域名。

用户肉眼分不出，浏览器的规则也不总能拦住。

这类域名的常见用途是钓鱼，或者单纯的抢注勒索。

防守办法只有一个，把高风险的相近形态提前注册下来。

Unicode有一份公开的易混淆字符对照表，直接拿它跑一遍自己的品牌名，就能得到一份需要注册的候选清单，而不是靠拍脑袋想。清单跑出来通常有十几到几十个，按注册成本排序，挑最像的那批买下来做跳转，一年的开销不如一次投放。UTS #39定义的Unicode安全机制 (https://www.unicode.org/reports/tr39/)是这份对照表的规范来源，里面还给了几种限制策略，可以直接用在自己的用户名和店铺名校验上。顺带说一句，这件事跟要不要用本地字母域名是两个决策，就算你最后决定主域名全用拉丁字母，这份防守清单照样该买。

## 收益结算在第一次输入，成本结算在第二次传递

把前面几节的账合起来，会得到一条相当干净的判据。

跑这份清单有个很省事的做法，是直接下载官方那份纯文本对照表，用脚本按品牌名逐字符查一遍，几十行代码就能出结果，Unicode公开的易混淆字符映射表 (https://unicode.org/Public/security/latest/confusables.txt)是原始数据，格式简单到不需要任何解析库。跑完记得按注册价格排一次序，清单再长也要按预算切一刀，全买下来通常没必要。

## 第一次输入确实变快了，这段收益是真的

先承认收益，别为了反对而反对。

本地布局的用户打本地字母，不需要切换输入法。

省下的动作是一次组合键，或者一次地球键。

更重要的是心理成本，母语的词他不用逐字母确认。

拉丁转写的域名对这批人反而是一次翻译。

他得先想这个词转写成拉丁字母该怎么拼，再打出来。

这份收益在一种场景里特别大：线下广告牌看一眼记住，走开之后凭记忆输入，母语词记得住，转写形态记不住。这也是本地字母域名最经典的使用场景，早年那批推广材料举的例子基本都是这一类。要注意的是它有个前提，就是这个词得是这门语言里的现成词。如果是个生造的品牌名，母语者记它的难度跟记一串拉丁字母其实差不多，这份收益会缩水一大半。品牌名是不是现成词，这一条得自己老实回答。

## 第二次传递的成本被普遍漏算

成本这边的账要长一些。

第二次传递指的是这个域名从一个人手里到另一个人手里。

转发链接、口头告诉、写进邮件签名、印在物料上。

每一次传递都会碰上前面讲的那几处不一致。

而访问量的大头恰恰来自被传递之后的那些人。

第一次输入是个位数的人做的事，第二次传递影响的是所有人。

更麻烦的是这两笔账的可见度不对等：第一次输入的收益立刻能感觉到，第二次传递的成本分散在十几个看不见的位置，谁也没法把它汇总起来。结果就是决策会上永远是收益方赢，因为它拿得出体感，成本方只能说一句可能会有些问题。要打破这个不对等，唯一的办法是把成本也变成体感——就是前面说的那四张截图。人对图像的反应比对论证快得多，四张长得不一样的域名摆在一起，比讲二十分钟机制管用。

这笔账还有一个更长期的形态：域名会被写进别人的文章、别人的收藏夹、别人的采购系统，写进去的那一刻形态就固定了，之后你再怎么调整都改不动它。也就是说第二次传递的成本不只发生在当下，它会以一个个错误或者不一致的字符串的形式沉淀在互联网上，沉淀量随时间线性增长，而清理的可能性接近于零。

## 你的流量里直接输入占多少

这笔账最后落在一个可查的数字上。

直接访问占比越高，本地字母域名的收益越大。

引荐和搜索占比越高，它的成本越突出。

这个数字在任何一套统计后台里都拿得到。

要注意的是直接访问这一栏本身不干净，它混进了很多来源不明的流量。

更准的做法是看线下渠道和电话渠道贡献的订单占比。

如果线下和电话加起来贡献不到一成，那么本地字母域名争取的那部分收益，从一开始就不值得用整条传递链的成本去换。反过来，如果你做的是本地展会、门店、电话销售为主的生意，这笔账可能完全成立，这时候本地字母域名不是加分项而是必需品。所以这个决策没有统一答案，它由渠道结构决定，而渠道结构是每家公司自己最清楚的事。别的都可以参考同行，这一条不能。

## 三档决策线

把上面几笔账压成一张能拍板的表。

第一档，直接输入与线下渠道占比很低，品牌名是拉丁字母。

这一档的答案是主域名用拉丁字母，本地字母只注册不使用。

第二档，占比中等，品牌名可以整体音译成本地字母。

这一档做双域名，本地字母域名做跳转，物料上按渠道分开用。

第三档，线下与电话是主渠道，品牌名本身就是本地词。

只有第三档才值得把本地字母域名当主域名，而且上线前要把口播测试、四管道截图、表单兼容三件事全跑一遍，缺一件就退回第二档。三档之间的迁移是单向的，从第二档升到第三档很难，因为主域名一旦定下来改动代价极大。所以拿不准的时候一律往低档选，这是少数几个保守明显优于激进的决策点。这套三档线跟本栏目里其它几篇的决策线一个套路，都是先找出那个真正决定结论的变量，再按它切档，剩下的因素只影响档内的做法不影响档位。

## 注册和使用是两个决策，别一起做

这一节把前面的分析落成具体动作，也是全篇最容易执行的一段。

## 注册的理由：防抢注、防同形、成本低

注册这件事的门槛低得多。

本地字母域名的注册价格通常跟普通域名一个量级。

买下来就堵住了别人拿它冒充你的路。

同时也堵住了用户手打时猜错落到别人手里的路。

还有一个常被忽略的好处，是为将来留下选择权。

市场环境变了、渠道结构变了，手上有域名才谈得上换。

把注册和使用分开之后，绝大多数关于本地字母域名该不该做的争论会消失，因为争论的双方要的其实是两件事：一方要品牌保护，另一方担心用户用不了。两件事互不冲突，同时做就行。这个拆分在很多决策里都适用，凡是听到一场讨论半天没有结论，先看看是不是两个人在讨论同一个词的两种含义。域名这个场景里那个词就是用，一方说的用是持有，另一方说的用是当主入口。

注册之前还有件值得花十分钟的事，是先确认这个后缀本身的运营状况——有些本地字符后缀的注册量和续费率并不好看，长期看存在政策变动的风险，根区数据库里每个后缀的委派记录 (https://www.iana.org/domains/root/db/xn--p1ai.html)能查到它归谁运营、什么时候委派的。冷门后缀不是不能买，但别把品牌的主入口押在上面。

## 使用的三个前提必须同时成立

使用的门槛要高很多。

第一个前提，品牌名本身是本地字母而不是拉丁字母。

第二个前提，外链和引荐主要来自本地来源。

第三个前提，品牌名里不混用两套文字系统。

三条是且的关系，缺一条就不成立。

第三条最容易被忽略，因为它的后果要上线之后才看得见。

三条之外还有一条隐含前提，就是你的用户群里那批没装本地键盘的人占比够低，这个数没法从公开数据里查，只能靠自己的客服记录和站内搜索日志估。估的办法有个偷懒版：看你的站内搜索框里，用户打进来的品牌名是本地字母多还是拉丁转写多。这个比例跟他们手上有没有本地键盘高度相关，而且是现成数据。本栏目在希腊语拉丁转写覆盖那一篇 (https://zhangwenbao.com/greek-seo-greeklish-latin-transliteration-coverage.html)里用过同一份日志做过类似的估算，方法可以直接搬过来。

## 折中方案：主域名拉丁，本地字母做跳转

大多数团队最后落在这个方案上。

主域名用拉丁字母，承担所有链接、邮件、日志。

本地字母域名注册下来，做三百零一跳转到主域名。

线下物料和本地广告上印本地字母那个。

线上一切可复制的地方用拉丁那个。

用户从任何一条路进来都到同一个站。

这个方案的关键细节是跳转必须是永久跳转而且只跳一级，多级跳转会在某些邮件客户端和二维码扫描器里被截断，白白丢掉一批访问。另一个细节是别把跳转做成落地页，有的团队会给本地字母域名单独做一个页面用来统计，结果制造出一套完全重复的内容。要统计就在跳转里带参数，不要建页面。这一条属于跨界到架构层的事，域名结构本身该怎么选是另一个层面的问题，本篇不展开。

## 已经用上了还能不能换回来

换回来是可能的，但要算清代价。

技术动作跟任何一次域名迁移一样，做永久跳转、更新站点地图、更新外链。

真正的代价在外链和线下物料上。

已经印出去的包装盒、名片、展会背板改不了。

已经被别人写进文章里的链接也改不了。

所以旧域名必须长期保留并保持跳转，不能到期不续。

一个实际的判断口径是：如果这个域名用了不到一年、线下物料印量不大，换回来的净成本通常是划算的；超过三年并且有过大规模线下投放，多数情况下维持现状再叠一个拉丁域名更划算。叠加这个动作听着像是把问题拖着不解决，但域名这件事有它的特殊性——两个域名并存的成本是线性的（多续一份费），而迁移的成本是一次性的高峰。生意跑得动的时候，没人愿意在高峰上花那笔钱。这是个很务实的结论，虽然不太好看。

## 上线前后各该验什么？

最后一节是清单，可以直接抄去用。

## 上线前的六步验收

六步按顺序做，每一步不过不往下走。

第一步，在目标市场主流的三个浏览器里各打开一次，看地址栏显示成什么。

第二步，把域名贴进邮件正文、工单系统、聊天工具，各截一张图。

第三步，用两个不同的工具生成二维码，扫开看提示框里的文字。

第四步，跑一次三人口播测试，记录拼对率。

第五步，拿本地字符邮箱去十个常用平台注册，记录被拒次数。

第六步是把前五步的结果并排放进一页文档，然后问一句：这五张图里有几张，用户看了会觉得这是同一家公司？这个提问方式很关键，它把技术检查变成了信任检查，而信任才是真正的判据。六步全部做完大概需要一天，比上线之后再回头改省太多。有个团队做完第五步就停下来了，因为十个平台里有六个拒收，他们当场把本地字母域名退回成跳转，省下了后面所有的麻烦。

六步之外还有个可选的第零步，适合技术团队来做：拿一段脚本把域名分别喂给几种主流的地址解析实现，看它们各自解出来的主机名字段是什么，网址标准里对主机名解析的规定 (https://url.spec.whatwg.org/)是判断谁对谁错的依据。这一步能提前发现你自己系统里那些会把域名切坏的老代码，比上线之后收到用户投诉再查便宜太多。

## 上线后要盯的三个数

上线之后不能不管。

第一个数是引荐来源里编码形态和本地字母形态的比例。

第二个数是直接访问的绝对量在改域名前后的变化。

第三个数是客服工单里跟网址打不开有关的条数。

三个数都要按周看，因为问题往往是慢慢积累的。

第三个数最灵敏，用户遇到麻烦时最先找的是客服不是搜索。

把这三个数放进日常看板，而且要在看板上写清楚查询工单时该用哪一串字符搜索，否则第三个数会长期显示成零，而零在这里意味着没查对而不是没问题。这一条呼应前面讲过的那个搜不到的坑，它的破坏力被严重低估：一个长期显示健康的指标，比一个显示不健康的指标危险得多，因为它会让人放心。凡是数字长期是零的指标，都值得回头验一次它到底测没测到东西。

## 哪些不归语言层管，交给谁

最后划一下边界。

域名结构本身该选国别域名、子目录还是子域名，属于架构层。

多语言版本之间怎么互相声明，属于国际化标注那一层。

路径部分用本地字母还是转写，是另一套账。

服务器怎么解析、证书怎么签，属于运维层。

本篇只管一件事：这串字符在人手里怎么流转。

把边界划清楚的好处是排查时不绕路，出了问题先判断它属于哪一层，再决定找谁，这一步能省掉大半的沟通成本。本栏目里跟这一层最近的三篇分别是小语种URL的编码与转写 (https://zhangwenbao.com/minor-language-url-native-script-vs-latin-transliteration.html)、西里尔页面的编码遗留 (https://zhangwenbao.com/cyrillic-encoding-legacy-windows1251-utf8-indexing-cost.html)和小语种网页字体的字形集 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)，三篇加上这一篇，字符这件事从存储、显示、传输到人工复现就凑齐了。剩下的架构层问题，本站国际SEO那个栏目里有更合适的入口。

## 常见问题解答

## 本地字母域名会不会影响搜索引擎收录？

不会。搜索引擎处理这类域名已经很多年，抓取、索引、排名都按正常流程走，不存在天然的劣势。真正会影响表现的是间接因素：外链更少（因为别人写你的域名时容易写错或者干脆写成编码形态）、点击率可能受影响（搜索结果里显示成什么形态各家不完全一致）、以及品牌搜索量被两种形态分流。这三样都不是引擎的政策问题，是传播链路的问题，跟本篇讨论的是同一件事。

## Punycode形态出现在搜索结果里，用户会不会不敢点？

会，但概率没有想象中高，因为多数搜索结果页显示的是解码之后的形态。真正的风险位置在那些不做解码的地方：某些聚合站、某些浏览器插件、某些企业内部的安全网关，它们会原样显示编码形态，并且往往还配一个警告图标。如果你的目标客户是企业采购，这个场景的权重要往上调，因为企业网络里这类中间设备最多。个人消费品类可以少担心一点。

## 已经注册了本地字母域名但一直没用，该怎么处理？

做永久跳转指向主域名，然后放着别管，续费就行。不要让它悬空解析到一个空页面，也不要给它单独做站。悬空的域名在被抓到之后可能被当成一个内容极少的独立站点，而单独做站会制造重复内容。跳转做好之后每年检查一次是否还生效，因为域名服务商换控制面板、改默认设置的事时有发生，跳转失效通常没有任何通知。

## 混用两套文字的域名真的完全不能用吗？

能注册，但不建议当主域名。技术上没有禁止，问题出在浏览器的显示策略上：混用多套文字是最容易触发强制编码显示的条件，而一旦被强制显示成编码形态，本地字母域名唯一的优势就没了，还额外背上一个看起来可疑的负担。如果品牌名必须混用，更好的做法是主域名整体用拉丁字母，把本地化留给内容和路径，别硬往域名上塞。

## 怎么快速判断某个市场的用户手上有没有本地键盘？

三个现成信号，半天能查完。一看站内搜索日志里本地字母查询和拉丁转写查询的比例；二看当地主流电商平台的搜索框默认提示词用的是哪套字母；三看本地社交平台上普通用户发的帖子里有没有大量转写拼法。三个信号里第二个权重最高，因为平台已经替你做过一遍用户调研了。这套用平台当对照组的办法在本栏目里反复用过，它比任何二手报告都快也都准。

## 本地字母域名对国际化邮箱的影响有没有变通办法？

有，而且很常用。企业邮箱单独用一个拉丁域名，网站用本地字母域名，两者通过页面上的清晰标注建立关联。缺点是品牌一致性打折，客户可能会疑惑为什么邮箱域名和网址不一样。更稳的做法是反过来：主域名用拉丁字母，邮箱和网站都用它，本地字母域名只做入口。这样一致性最好，代价是放弃了本地字母域名在展示上的那点加分。

## 这套判断适用于所有非拉丁语种吗？

框架适用，具体档位不适用。四种复现动作、四条管道、链条最弱环这三条是通用的，任何语种都能照着做一遍。会变的是每一项的权重：书写系统跟拉丁字母差异越大，同形字符风险越低但键盘覆盖越是问题；使用同一套字母的多个国家之间，键盘布局差异反而更隐蔽。所以拿这套框架去评估一门新语言时，前三步照抄，第四步开始必须用本地数据重跑。

## 权威参考资料



## 小语种稿子被判成难读，可那把尺子的刻度当年是拿英语量出来的

- URL：https://zhangwenbao.com/minor-language-readability-score-english-calibrated-formula.html
- 分类：小语种SEO
- 发布：2025-09-11  |  更新：2026-07-27
- 摘要：可读性公式的三个常数拟合自1940年代的英语材料，德语的复合词、芬兰语的长句、日语的音节在它眼里全是扣分项。讲清分数为什么不能跨语言比较，以及提分动作为什么正好跟关键词匹配对着干。
- 关键词：内容营销,出海SEO,多语言SEO,小语种SEO

> **TLDR**：摘要：内容平台和写作插件给出的可读性分数，公式里的三个常数是在1940年代的英语材料上拟合出来的。换一门语言，输入的两个计数单位可能根本不存在，常数也不再对应任何东西。更麻烦的是，把分数当成发布闸口之后，编辑唯一能动的杠杆恰好是把精确术语换成口语词，而术语正是用户在搜索框里打的那个词。

> 摘要：内容平台和写作插件给出的可读性分数，公式里的三个常数是在1940年代的英语材料上拟合出来的。换一门语言，输入的两个计数单位可能根本不存在，常数也不再对应任何东西。更麻烦的是，把分数当成发布闸口之后，编辑唯一能动的杠杆恰好是把精确术语换成口语词，而术语正是用户在搜索框里打的那个词。

## 那个可读性分数到底是怎么算出来的？

## 公式只有两个输入

最常见的那套可读性公式只看两个数：每个句子平均多少个词，每个词平均多少个音节。

两个数各乘一个系数，再从一个基数里减掉，得出一个零到一百的分数，越高表示越好读。

公式的全部智慧就在这三个常数上：一个基数，两个权重。它们不是推导出来的，是拟合出来的。

拟合用的材料是1940年代的英语文本，配合当时的读者理解度测试，回归出一组让预测最接近实测的数字。

这套做法在当时非常先进，它第一次把一个模糊的判断变成了可以计算的数值。

需要记住的是这三个数字的出身：它们是某一批英语材料上的经验值，不是语言的普遍规律。常数一旦是拟合出来的，它的适用范围就等于拟合它的那批语料的范围，超出这个范围，公式还在，意义没了。

值得注意的是，这个公式当年针对的是纸质材料的整篇文章，句子完整、段落连贯、没有列表也没有表格。今天它被拿去测的对象是网页，而网页上大量文本是短语、按钮、标签、参数行。把这些一并当成句子来数，得出的每句词数本身就没有意义，公式还没开始算就已经错了。

## 为什么它能流行八十年

因为它便宜。数句子、数词、数音节，三样都能靠规则完成，不需要任何语义理解。

在计算机还很贵的年代，这是唯一算得动的文本质量指标，于是它被写进了排版软件、办公软件、教材评级体系。

后来它又被写进了内容管理系统的插件，写进了写作辅助工具，写进了内容团队的验收标准。

每往下传一层，关于它出身的说明就少一点，到最后只剩下一个绿灯红灯。

今天很多编辑看到的，是一个只显示颜色的进度条，连分数是多少都不一定看得到。

这是一条很常见的传播路径：一个带前提的研究结论，在工具化的过程中把前提丢掉了。丢掉前提不是谁的恶意，只是每一层传播都要简化，而前提总是最先被简化掉的那部分。

还有一个推波助澜的因素：它给出的是一个单一数字，而单一数字特别适合放进后台仪表盘和月度汇报。任何一个能被画成折线的指标，都会自动获得比它应得的更多的权重。这跟指标本身好不好没关系，是组织的运作方式决定的。

## 它测的其实是句子和词的长度

把公式拆开看，它不测语义，不测逻辑，不测信息密度，也不测结构。

它只测两件事：句子有多长，词有多长。这两件事在英语上跟理解难度确实相关，相关性还不低。

相关不等于因果。词长和难度的相关，来自英语里长词多半是拉丁语源的学术词汇这一历史事实。

这个事实是英语特有的，因为英语在历史上吸收了大量拉丁语和法语词汇，形成了日常词短、学术词长的双层词汇结构。

换一门没有这段历史的语言，词长和难度的关系就可能完全不同，甚至反过来。

相关性还有一个容易被忽略的前提：它是在一个特定的读者群上测出来的。当年的实测对象是英语母语者，而今天你的德语页面的读者里可能有相当一部分是把德语当第二语言的人。对这批读者来说，难点根本不在词长，而在惯用搭配和文化背景，公式对此完全无感。

顺带说一句，词长和难度在有些语言上甚至是反向的。芬兰语里最长的那些词往往是把一句话压成一个词的日常表达，母语者读起来毫不费力；而真正难懂的常常是那些短小的功能词组合。公式在这类语言上不只是不准，方向都可能是错的。

## 公式里的常数为什么只对英语成立？

## 德语的长词不等于难词

德语靠复合词构词，日常生活里最普通的东西也可能写成一个很长的词。

手套、垃圾桶、洗碗机这类词，在德语里都是几个词根粘在一起，音节数轻松超过英语的对应词。

公式看到的是音节数偏高，于是判定它难读，而这些词恰恰是德语儿童最早学会的一批。

更麻烦的是，复合词在德语里是不能拆的，拆开就是另一个意思或者干脆不成词。

换句话说，公式指出的那个问题，在这门语言里根本没有对应的修改动作。

德语复合词在选词层面的处理办法在德语复合词与变音符号的选词方法 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)里讲过，那边关心的是关键词表怎么建，这里关心的是同一个语言事实怎么把一个通用分数变成噪音。

还有一层更实际的麻烦：德语的复合词在搜索里往往是一个整体查询词，用户就是这么打的。为了降低音节数把它拆成几个词写，等于把页面上那个能精确匹配的词形拿掉了，检索侧的损失是实打实的，而可读性的收益只存在于那个分数里。

## 屈折语的句子也拆不动

芬兰语、波兰语、俄语这类语言靠词形变化表达语法关系，一个长句里的成分靠格标记互相照应。

把长句拆成两句，照应关系就断了，读者需要自己在两句之间重建联系，实际读起来更费劲。

所以在这几门语言里，句子变短不一定更好读，有时候正相反。

公式里那个句长权重的符号，在这些语言上未必还应该是负的。

而工具不会告诉你这一点，它照样按英语的权重扣分。

芬兰语十五个格带来的形态爆炸在芬兰语十五个格与辅音交替的选词处理 (https://zhangwenbao.com/finnish-seo-fifteen-cases-consonant-gradation-keyword.html)里有完整拆解，那套形态系统正是句子拆不动的根本原因。

这里有一个可以直接搬走的自检：拿这门语言的一段真实文本，人工把长句拆成短句，然后请母语者比较两版哪个更好懂。如果多数人选原版，那这门语言上的句长权重就该被质疑。这个实验一小时能做完，比查任何文献都快，也更有说服力。

## 同一段话翻成另一门语言，分数一定会变

拿一段英文原文和它的德语译文各算一次分数，德语版几乎总是低一大截。

这不是译得差，是德语的构词方式决定了音节数天然更高。

意大利语、西班牙语也偏低，因为它们的词尾变化会额外增加音节。

如果团队用同一个分数线要求所有语言版本，那结果是可以预见的：英语版轻松过关，德语版永远不达标。

更荒谬的是，为了让德语版过关，译者只能刻意避开那些最自然、最常用的复合词。

这就是所谓的量纲错误：把两把刻度不同的尺子量出来的数字放进同一个表格，然后比较大小。这个错误的隐蔽之处在于两个数字都叫可读性分数，看起来完全可比。

反过来的例子也存在：把同一段话翻成印尼语或者越南语，分数常常比英语原文还高，因为这两门语言的词普遍短。如果团队按分数评判译文质量，就会得出印尼语译得比德语译得好的结论，而实际上两版可能出自同一个流程、同一批人、同样的质量。

## 哪些语言根本没有公式需要的那两个计数单位？

## 没有空格的语言先卡在数词上

公式要数词数，前提是能切出词的边界。英语靠空格，代价几乎为零。

泰语、日语、中文没有词间空格，切词要靠算法或者词典，切法不同结果就不同。

切法本身就是一个有争议的问题，同一句话在不同分词器下的词数可以差三成。

词数一变，公式的第一个输入就变了，分数跟着变，而这个变化跟文本本身毫无关系。

换句话说，在这些语言上，分数首先测的是你用了哪个分词器。

泰语里空格与语义单元的关系在泰语没有空格时词边界由谁说了算 (https://zhangwenbao.com/thai-seo-no-spaces-word-segmentation-keyword.html)里讲得最细，那篇给出的那把尺子在这里同样适用：先问这门语言里空格的数量跟语义单元的数量是什么关系，再决定要不要用依赖词数的指标。

更棘手的是，很多工具在遇到没有空格的语言时不会报错，它会按空格切，切出来整段只有一两个词，于是每句词数低得离谱，分数反而漂亮。Unicode标准附件29关于文本分段的规定 (https://www.unicode.org/reports/tr29/)明确说明了词边界判定在这类语言上必须依赖额外的词典，而多数可读性工具并没有做这一步。

## 音节这个单位不是哪都有

公式要数音节，而音节这个概念在不同语言里的定义并不统一。

日语的计数单位是拍，跟音节不完全重合；汉语的音节数等于字数，测出来永远是一，没有区分度。

韩语的音节可以直接从字形数出来，但那个数字跟阅读难度的关系跟英语完全不同。

更实际的问题是，音节切分在多数语言里依赖词典，而词典对专有名词、外来词、新词的覆盖很差。

常见的音节切分库依赖的是拼写检查用的连字符词典，词典缺词的时候就只能按规则猜。

这意味着分数在处理品牌名、型号、专业术语密集的商品页时，误差会比处理普通散文时大得多，而商品页恰恰是最需要判断的那一类。

音节切分的实现细节也值得看一眼：常用的库依赖的是排版用的连字符词典，而连字符规则关心的是断行位置好不好看，不完全等于语音上的音节划分。Pyphen这个连字符切分库 (https://github.com/Kozea/Pyphen)的文档里就写明了它的数据来源，本质上是排版规则被当成了语音规则用。

词典的覆盖差异也值得看一眼：Hunspell拼写检查引擎 (https://hunspell.github.io/)的各语言词典由不同的社区维护，活跃度差别很大，有些语言的词典多年没更新。你的分数准不准，某种意义上取决于某个志愿者最近有没有空，这个事实本身就说明它不该当闸口。

## 日语有自己的一套，但基于完全不同的特征

日语的可读性研究不数音节，它看的是字种比例、词汇难度等级、句子长度这几类特征。

汉字比例高的文本通常更正式也更难，这条在日语里成立，在任何字母语言里都没有对应物。

日语文本可读性测定门户jReadability (https://jreadability.net/)就是按这一套做的，它给出的等级对应日语学习者的水平划分，跟英语那个零到一百的分数没有任何换算关系。

这说明一件事：真正靠谱的可读性工具都是为单一语言单独做的，而不是一个公式套所有语言。

凡是宣称支持几十门语言的通用可读性打分，多半是把同一个公式换了几个常数。

日语这套方案还有一个值得借鉴的地方：它的输出是等级而不是连续分数。等级天然抗过度优化，因为你没法为了从中级挪到中上级去做一堆微调，它只对结构性的改动有反应。凡是容易被小动作刷动的指标，最后都会被小动作刷动，这是指标设计里的一条铁律。

## 换常数不等于换公式

确实有一批为特定语言标定的变体：德语、西班牙语、意大利语、阿拉伯语都有各自的版本。

开源库里把它们并列成一个个函数，看起来像是一套完整的多语言方案。

textstat这个可读性计算库 (https://github.com/textstat/textstat)的接口列表就是最直观的例子，各语言的专用公式一个挨一个排着。

但这些变体的输出量纲各不相同：有的是零到一百的分数，有的直接是学制年级数，有的是另一套自定义刻度。

把它们放进同一张报表里做横向对比，得到的结论没有任何意义，虽然表格看起来非常专业。

还有一个判断办法：看这个工具支持多少门语言。如果它宣称支持上百门，那几乎可以肯定它用的是同一套骨架加一组常数；如果它只支持三五门，反而更可能每门都单独做过标定。覆盖广度和标定深度在这类工具上通常是反向关系，选型时可以直接拿这条当筛子。

## 各语言自己那套公式，能不能直接拿来用？

## 先看它标定在什么材料上

每套变体都有自己的标定语料，可能是教科书，可能是报刊，可能是学术论文。

标定语料决定了这套公式在什么文体上准，商品页和落地页几乎从来不在标定语料里。

商品页的文本形态很特殊：短语堆叠、参数罗列、缺少完整句子，跟任何一种标定材料都不像；同一批特征还会带来另一个麻烦，文本一短，机器连这页是什么语言都可能判错 (https://zhangwenbao.com/minor-language-page-language-detection-misidentification-short-text.html)，而判错之后连该用哪套公式都无从谈起。

拿一个在教科书上标定的公式去测商品页，结果的可信度非常低。

这不是语言的问题，是文体的问题，英语站上其实也存在，只是英语站很少有人认真看这个分数。

所以在小语种上做这件事之前，先问一句这套公式当年是拿什么材料标的，答不上来就别把它当闸口。

还有一个更少被提起的前提：这些公式当年是为了给学校挑教材、给政府文书定标准而做的，服务对象是要把材料读完的人。而网页读者是扫读的，他们要的是快速定位而不是通读理解。服务对象一变，整套评估目标就该跟着变，而不只是换几个常数。

还有一个提问可以直接甩给工具供应商：这套公式在我们这门语言上的标定材料是什么、样本量多大、标定年份是哪一年。三个问题里只要有一个答不上来，就说明它是拿常数拼出来的。这三问不需要你懂统计，只需要对方能不能拿出来。

## 分数不能跨语言比较

德语常用的那套公式，输出的是一个大致对应学制年级的数字，越低越好读。

瑞典语常用的那套输出的是一个自定义指数，四十以上算难。

英语那套是零到一百，越高越好读。三套的方向和量纲全都不同。

报表里把它们并成一列叫可读性，然后按大小排序，这个动作本身就是错的。

要横向比只有一种正确做法：每门语言各自设定自己的目标区间，只看有没有落在区间内。

这跟做跨语言的任何比率对比是同一条原则：先建立本语言的基线，再看相对位置，绝对值永远不可比。

报表层面有个很实际的补救：把这一列的名字改掉。别叫可读性分数，叫成本语言可读性指数并注明公式名，人们看到不同的列名就不会本能地去比较大小。改名这个动作听起来很敷衍，实际拦住的误用比写三页说明还多，因为多数人不看说明只看列名。

## 阿拉伯语那套还要面对元音标记的问题

阿拉伯语的标准书写通常不写元音标记，音节切分因此高度依赖上下文。

同一串辅音在不同语境下读法不同，音节数也不同，而文本上看不出来。

这让任何依赖音节计数的公式在阿拉伯语上都带着一层结构性的不确定。

希伯来语有同样的问题，未标元音的书写方式让一个词形对应多个读法。

这类语言更适合用词汇难度等级这类不依赖语音的特征来评估。

阿拉伯语还有一层：书面语和口语差异巨大，同一批读者对两种语体的理解速度完全不同。而公式只看形式特征，分辨不出这段是标准书面语还是接近口语的写法。这门语言上真正影响可读性的那个变量，恰恰是公式完全看不见的那个。

## 什么时候这些变体是有用的

它们在同语言纵向对比时是有用的：同一门语言、同一类页面、同一个团队，看这个月比上个月是更长还是更短。

这时候公式的绝对值不重要，重要的是它稳定，能反映趋势。

用途从判断好坏变成了监控波动，这个转变让它重新变得可靠。

比如某次改版之后分数突然掉了一大截，那通常意味着模板改了、句子被自动截断了、或者有人把说明文字换成了参数罗列。

当成告警指标用，它挺好用；当成验收闸口用，它会伤到内容。

当成告警用的时候，还有个技巧：只看变化幅度，不设绝对阈值。设定一条规则，比如某类页面的分数在一次发布后变动超过一定幅度就提醒人工看一眼。这样它既发挥了自动化的长处，又不会驱动任何有害的优化动作，因为没人能通过写作来预判自己会不会触发告警。

## 把分数当发布闸口，编辑会做出哪些动作

## 只有两个杠杆可以拉

分数由句长和词长决定，所以要提分只有两条路：把句子拆短，或者把词换短。

没有第三条路。改逻辑、补例子、加小标题这些真正提升可读性的动作，对分数没有任何影响。

这是闸口类指标最典型的毛病：它奖励的动作集合，跟真正有价值的动作集合几乎不重叠。

编辑在截止日期前面对一个不达标的红灯，会挑最省事的那条路。

最省事的永远是换词，因为换词是局部改动，拆句子要重写上下文。

于是这个闸口的实际效果，是系统性地推动编辑把长词换成短词，而不管那个长词是不是必须的。

还有一个隐性的第三条路，但很少有人用：把长句改写成列表。列表项通常不被当成完整句子，句长统计立刻下降，而信息一个都没少。这条路之所以少见，是因为它需要重新组织内容，成本比换词高得多，而在截止日期面前，成本决定一切。

还有一个组织层面的观察：这个闸口通常是内容团队自己给自己加的，初衷是防止外包稿件太差。防低质的动机完全正当，但用错了工具，结果是把最懂行的那批作者伤得最重，因为他们写的术语最多、限定条件最全，分数天然最低。

## 换词换掉的正好是术语

一段商品说明里最长的词是什么？通常是专业术语、材质名、工艺名、规格名。

拿咖啡器具站举例，德语里那些描述研磨度、萃取方式、锥形刀盘的词，个个又长又硬。

把它们换成口语说法，分数立刻好看，页面也确实读着轻松一点。

问题是用户在搜索框里打的正是那些术语，因为他要找的就是那个具体的东西。

换掉术语，等于把这一页从那批高意图查询里摘了出来。

在小语种上，提升可读性分数和维持关键词匹配是直接对立的两件事，而在英语上它们冲突得没这么厉害，因为英语的术语常常有一个同样常用的短同义词。

更麻烦的是这个动作不可逆。术语被换掉之后，除非有人保留了原稿并逐词对照，否则几个月后没人记得这里原来写的是什么。Yoast关于可读性分析的功能说明 (https://yoast.com/readability-analysis/)里其实列清了它检查的每一项，把这份清单跟你的术语表比一比，就能提前知道哪些词会被它盯上。

## 被删掉的还有限定成分

为了缩短句子，最容易删的是定语从句、插入语、括注。

这些成分承载的往往是限定条件：适用型号、尺寸范围、例外情况、注意事项。

删掉之后句子确实短了，信息也确实少了，而少掉的那部分正是用户下单前最需要确认的。

退货率上升和可读性分数上升，有时候是同一次改稿造成的，只是没人把这两件事联系起来。

更隐蔽的是，删掉限定成分之后，剩下的句子往往变成了一个更绝对的断言。

绝对断言在合规上是有风险的，尤其在食品、化妆品、电器这几类品类上，某些市场对宣称有明确的法规约束。

这里有一条可以写进规范的边界：凡是承载条件、范围、例外的成分，一律不许为了缩短句子而删除，只能换位置。换位置指的是把它从句中挪到独立的一行、一个列表项或者一张小表里，信息保留，句子也短了。这个动作对分数同样有效，只是需要多花五分钟。

删限定成分还有一个连锁反应：结构化数据里的字段跟着变空。适用范围、材质、规格这些原本写在句子里的信息，如果标记是从正文里抽取生成的，正文一删标记就跟着没了，而这一层通常没有任何人会去复查。

## 母语审校为什么拦不住

母语审校看的是这句话读着自不自然，而换完短词的句子读着确实自然。

他们通常不知道哪些词是关键词，也不负责检索表现，这不在他们的验收范围里。

所以这类损失会顺利通过所有人工环节，因为每一环各自看都没问题。

破解办法是在审校清单里加一条：术语一致性检查，列出必须保留原样的词。

这份清单的做法在小语种内容的母语审校验收清单 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)里有现成的表格，加一列必留术语即可。

还有一个组织层面的原因：审校通常是流程的最后一环，而分数不达标的修改往往发生在审校之后。也就是说，那批为了提分而做的改动，压根没有经过任何母语者的眼睛就上线了。把提分改动放在审校之前，是零成本却能拦住大半问题的流程调整。

## 这些动作在小语种上具体伤到了什么？

## 关键词匹配度

用户打的是术语，页面上写的是口语说法，两者对不上，匹配度下降。

在屈折语上这个损失会被放大，因为术语本身还有多种词形，而口语说法未必有对应的形态。

结果是原本能覆盖十几种词形变体的一个词，被换成了一个覆盖面小得多的说法。

这类损失在后台看是展现量缓慢下滑，没有任何一次断崖，很难归因到某一次改稿。

要发现它，只能在改稿前后各导一份词形覆盖清单做对比。

这类损失还有一个特点：它在英语站上几乎不存在，所以从英语站积累的经验完全没有预警作用。总部拿着英语站的历史数据说这个改动没风险，而风险恰恰只在小语种上出现，这也是这类问题在跨国团队里特别难说清楚的原因。

## 专业感和信任

把所有术语都换成大白话，页面读起来会有一种奇怪的业余感。

在高客单价品类上，这种业余感直接影响转化，用户会觉得这家不太懂行。

本地用户对这一点尤其敏感，因为他们能分辨出哪些是行内说法、哪些是外行转述。

做本地化做得越到位，读者的期待就越高，这类落差反而越明显。

这跟越本地化越容易暴露适用范围错配是同一类现象：质量上去了，容错反而变小了。

专业感这件事还能被更直接地测出来：把两版文案给五个本地同行看，问哪一版更像本地专业商家写的。这个问题不需要他们懂SEO，答案往往非常一致。定性方法在这里比任何定量分数都可靠，因为你要测的本来就是一种主观感受。

还有一个可量化的信号：本地同行页面上的术语密度。把三家同行的商品描述采下来，数一数每百字里出现多少个行内术语，这个数字就是这个市场对专业感的期待值。你的页面明显低于它，读者的第一印象就是这家不专业，而这跟你写得顺不顺没关系。

## 被引用的可能性

生成式回答在挑来源时更偏好信息密度高、表述明确的段落。

被删掉限定成分的句子，看着更流畅，但可提取的事实变少了。

换句话说，为了迎合一个测长度的指标，你把内容里最可能被引用的那部分削掉了。

小语种的问答长尾本来就没多少家在认真写，这一削等于把自己的优势让了出去。

这一层的价值判断在小语种问答长尾在AI时代的内容价值 (https://zhangwenbao.com/minor-language-qa-long-tail-content-value-ai-era.html)里算过账，那笔账的前提正是内容里有足够多可被摘出来的完整事实。

还有一个具体的操作建议：把最值得被引用的那几个事实单独写成完整的短句，句中带上限定条件，不要拆散在几句话里。这样的句子往往长度中等、信息完整，既不会被分数惩罚，也最容易被整段摘走，属于一次同时满足两边的写法。

## 句长分布被压平了

好的文章句长是有节奏的：长句铺陈，短句收结，长短交错。

按均值优化的结果是所有句子被压到同一个长度，节奏没了，读起来反而更累。

这一点在任何语言上都成立，只是小语种上没人回头检查，因为分数已经绿了。

用分布代替均值就能看出这个问题：把句长画成一张直方图，压平的分布一眼就能认出来。

这也是本文推荐的替代指标之一，成本比算分数还低。

直方图这个办法还有一个额外好处：它能看出文本是不是机器生成的。人写的文本句长分布通常有明显的长尾，模型生成的文本分布集中得多。这条经验在做内容质检时很好用，比任何检测工具都直观，而且不需要额外的成本。

还要留意一种伪长句：把好几件事用顿号串在一起的罗列句。它在统计上很长，读起来却不难，因为结构是并列的。改这类句子对理解毫无帮助，纯属为分数服务，所以在人工复核的时候要先把这一类挑出去，别浪费时间。

## 那到底该用什么代替这个分数？

## 把代理指标换回本体

可读性分数是一个代理，它替信息能不能被理解说话，而这件事本来是可以直接测的。

直接测的办法是任务完成度：给五个母语者一个具体任务，看他们能不能在页面上找到答案、多久找到。

五个人、每人十分钟，成本比很多人想象的低，而结论比任何分数都硬。

这类测试还能顺带发现导航、版式、信息层级的问题，而分数对这些一无所知。

凡是能直接测的东西，就别用代理指标去替，这是所有指标设计里最根本的一条。

英文经验值搬到小语种失效这件事，之前在图片替代文本的字符数上限上出现过一次，处理办法完全一样：非拉丁字母站点的图片替代文本写法 (https://zhangwenbao.com/minor-language-image-alt-text-non-latin-script-search.html)里那条把字符数换成信息单元的思路，在这里换成把分数换成任务完成度。

做任务完成度测试还有一个技巧：任务要选真实的购买决策问题，比如这个型号能不能装在我家那款机器上、退货运费谁承担。用真问题测出来的结果才有指导意义，用找一下页面上有没有提到某某这种伪任务测出来的，只能证明搜索功能好不好用。

## 看句长分布，不看句长均值

把一页里所有句子的长度列出来，画成分布，看两件事：最长的几句有多长，长句集中在哪一段。

真正伤害理解的是个别超长句，而不是平均值偏高，均值会把这个信息完全掩盖掉。

处理动作也更明确：只改那几句超长的，其余一个字不动。

这比按均值全篇压缩省事得多，也不会伤到节奏。

这个指标不需要任何语言学知识，也不需要分词器，数标点就能算。

这个指标还有一个便宜的扩展：统计一下超长句集中在哪些区块。如果它们集中在产品描述的开头，那多半是从供应商资料直接搬过来的；集中在结尾，多半是免责声明。知道来源之后，改的就不是句子而是流程，一次能解决一批页面。

阈值这件事还有一个偷懒但有效的做法：直接拿本站表现最好的那几页的句长分布当标准。它们已经被市场验证过了，比任何外部参考值都贴合你的读者。这个办法的前提是你确实有几页表现明显更好，多数站都有，只是没人从这个角度用过这批页面。

## 用术语一致性代替词长

词长这个输入应该被彻底放弃，换成一份术语表加一致性检查。

术语表列出这个品类里必须保留的原样词，检查脚本核对页面上有没有被换掉。

这份表同时服务于选词、翻译、审校三个环节，做一次多处受益。

表的规模通常不大，一个品类几十个词，由懂行的母语者列一遍即可。

有了它，编辑就知道哪些词不能碰，也就不会为了凑分数去动它们。

术语表还要标一个东西：这个术语在本语言里有几种词形。屈折语里一个术语可能有十几个形态，页面上出现哪一个都算保留。检查脚本要按词干匹配而不是按字符串完全相等，否则会把正常的词形变化误报成术语被换掉了，误报几次之后就没人再看这个报告了；顺带还要注意大小写折叠这一步，转成小写在土耳其语和德语上会改坏词形 (https://zhangwenbao.com/minor-language-case-folding-lowercase-turkish-dotless-i.html)，术语核对脚本本身就可能是误报的来源。

## 母语者朗读是最便宜的一次检验

让一个母语者出声读一遍页面，记录他卡壳、回读、重音放错的位置。

这些位置就是真正难读的地方，通常跟分数指出的位置完全不重合。

朗读能暴露的问题包括：断句歧义、指代不清、词序别扭、译文腔。

这些都是公式测不到的，而它们才是本地读者真正会感觉到的东西。

一页文字读一遍不超过五分钟，是整套办法里性价比最高的一项。

朗读还有一个变体值得试：让母语者读完之后，合上页面复述一遍页面讲了什么。复述不出来的部分，就是信息结构有问题的部分，跟句子长短通常没关系。这个方法测的是信息组织而不是文字表面，而信息组织恰恰是所有可读性公式的盲区。

朗读还能顺带发现一类纯技术问题：数字、单位、缩写读不出来。比如格式写错的日期、缺少空格的单位、只有缩写没有全称的规格，母语者读到这里会停顿或者猜。这几处往往同时也是Unicode通用地区数据仓库 (https://cldr.unicode.org/)里有明确本地格式规定的地方，改起来只是配置问题。

## 一份不依赖分数的可读性验收办法

## 三个数加一次朗读

三个数是：最长句的长度、超过某个阈值的句子占比、必留术语的保留率。

阈值按语言各自定，方法是从这门语言的本地头部同行页面上采一批句子，取它们的分布当参照。

用同行当对照组的好处是它自动包含了这门语言的构词特点，不需要你自己去研究语言学。

三个数加上一次母语者朗读，就构成了一套完整的验收，用时不超过半小时。

整套办法不依赖任何工具，不依赖分词器，也不会因为换了插件而失效。

这三个数还有一个共同的优点：它们都不依赖任何第三方服务。插件会下线、接口会收费、模型会换代，而数标点、比词表、听朗读这三件事十年后还是一样做法。验收办法的寿命应该比工具的寿命长，这是选指标时很少被提起、但长期看最重要的一条。

## 怎么设定各语言的阈值

挑三家本地头部同行，每家采二十个句子，算出句长分布。

取他们分布的高位当作你的上限，超过这个长度的句子就标出来人工看。

三家同行必须是本地的、同品类的，不能拿英文站翻译过来的页面当参照。

这套对照组还有一个附带好处：模型和工具换代的时候，你和对照组一起平移，相对位置仍然可比。

阈值每年复核一次就够，语言的写作习惯变化很慢。

采样的时候注意别只挑头部大站。头部大站的文案往往经过多轮打磨，长度偏保守，用它们当上限会把你的标准定得过严。更好的做法是采三家里包含一家中型的本地商家，它的写法更接近这个市场的常态，也更接近你的读者习惯的阅读节奏。

采样还有一个操作细节：只采商品描述和分类说明，别采博客文章。两类文体的句长分布差别很大，混在一起算出来的阈值对谁都不合适。文体这个变量比语言变量还大，这也是很多团队照搬外部标准之后发现完全不适用的根本原因。

## 把它写进上线清单

验收办法只有写进清单才会真的被执行，否则它只是一次演示。

清单上写三行：最长句是否超阈值、必留术语保留率是否达标、朗读有没有卡点。

三行都过才算通过，任何一行不过就退回修改，不接受用分数抵消。

同时把原来那个分数从验收标准里删掉，只保留在监控看板上当波动告警。

这个动作要在流程上明确宣布，否则编辑会继续按旧标准自我审查。

清单落地还有一个细节：把不通过的处理方式也写清楚，是退回重写还是允许带条件放行。没写清楚的清单最后都会变成走过场，因为第一次遇到赶工期的时候，没人知道该按什么规矩办，而临时决定的先例会立刻变成永久惯例。

## 这套验收该由谁来跑

三个数可以由脚本自动算，跑在发布前的检查环节里，不占人工。

朗读这一步必须是人，而且必须是母语者，最好是没参与写作的那个人。

写作者自己朗读会自动跳过卡点，因为他知道自己想表达什么，眼睛会替他补上。

如果团队里没有母语者，可以把这一步外包，一页的成本很低，通常比一次改稿还便宜。

排期上建议放在译文定稿之后、结构化数据生成之前，这个位置改动成本最低。

还有一个容易被忽略的角色：负责关键词的人要在术语表这一环签字。术语该不该保留，只有他知道用户到底打的是哪一个词，而这件事既不属于写作也不属于审校，如果不明确指定，它就会一直悬着没人管。

还有一件事要在排期上说清楚：这套验收第一次跑会比后面慢很多，因为术语表和阈值都要从零建。第一次可能要两三天，之后每篇只要半小时。把这个差别提前讲明白，能避免团队在第一次之后就得出这套办法太重的结论，那是本可以避免的误判。

还有一个人选问题值得提前想：跑这套验收的人最好不是写稿的人，也不是决定排期的人。前者会自动为自己辩护，后者会在赶工期时倾向于放行。找一个跟这两件事都没有直接利益关系的角色，验收才会真的发生，而不是变成一次自我确认。

## 哪些不归语言层，要交出去？

## 排版和版式那一半交给前端

行长、行距、字号、对比度对阅读体验的影响，跟语言无关，也不该混进这个话题。

它们有各自成熟的规范和检查工具，按那套走就行。

唯一跟语言相关的是每行字符数：不同书写系统的舒适行长不同，这一条要按语言单独定。

把两件事分开的好处是责任清楚，不会出现前端和内容互相等对方先动的僵局。

本篇只管文字本身，不管文字怎么排在屏幕上。

行长这一条还可以再具体一点：拉丁字母语言的舒适行长通常按字符数算，而中日韩按字数算，两套单位不能混。多语言站如果用同一个容器宽度，某几门语言的行长一定会偏离舒适区间，这是版式层面最容易被漏掉、也最容易修的一处。

## 机器翻译质量那一半单独走

译文腔和可读性是两个问题，虽然它们经常同时出现。

译文腔靠的是母语审校和风格指南来解决，跟句长词长没有关系。

把两者混在一起谈，会让审校环节背上一个它解决不了的指标。

机器翻译直接上线的风险边界在机器翻译直接发布的搜索风险与质量线 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)里划过，那条线跟可读性阈值是两套独立的标准。

两套标准都要过，但不要互相替代，也不要合并成一个总分。

还有一个交界地带要点名：术语表既服务于翻译质量，也服务于本文这套验收，两边都要用它。这种共享资产最好指定一个所有者，否则会出现两份内容不一致的术语表在两个团队里各自演化，最后谁也不知道该信哪一份。

## 分词器怎么选，是工程层的事

没有空格的语言要不要上分词器、上哪一个，属于工程选型，不该由内容团队来定。

内容团队要做的是提出需求：站内搜索要能匹配、结构化数据要能生成、统计口径要稳定。

选型的结果会反过来影响一批指标的可比性，所以换分词器的时候要通知内容团队重置基线。

这一层的取舍跟本文的主题相交但不重合，交出去比硬塞进来更清楚。

本篇的立场很简单：任何依赖分词结果的指标，在换分词器之后都要重新标定，不然趋势图是假的。

最后补一条关于沟通的经验：跟工程团队讨论这件事的时候，别从语言学讲起，直接给一个具体的失败样例。一段德语文案被判成难读、编辑照着改完之后关键词没了，这个故事三十秒讲完，比解释三个常数的来历有效得多，也更容易换来排期。

还有一个更省事的说服路径：拿一段本地同行的文案去测一遍。如果同行那段也不达标，而他们在这个市场做得比你好，这个事实本身就足够有力，不需要再讲任何原理。用竞品当反例，是所有指标讨论里最快结束争论的办法。

## 常见问题解答

## 写作插件给的可读性建议，是不是该全部关掉？

不用全关，但要把它从闸口降级成提示。这类插件里有一部分建议是跟语言无关的通用写作常识，比如提醒你连续三段都用了同一个开头词、提醒你某一段特别长，这些留着有好处。真正要关掉的是那个总分和它对应的红绿灯，因为它会驱动编辑去做有害的动作。如果插件不支持只关分数，那就在流程上明确宣布分数不作为验收依据，并且把它从任何汇报模板里删掉——只要它还出现在周报里，就一定会有人去优化它。

## 老板要一个能看的数字，总不能什么都不给吧？

给三个：最长句长度、超阈值句子占比、必留术语保留率。这三个数都能自动算，都能画成趋势，而且都有明确的改进动作对应。比一个笼统的可读性分数更好汇报的地方在于，当某个数字变差时，你能直接说出该改哪几句话，而不是只能说文章变难读了。如果一定要一个总分，可以把三个数各自归一化之后加权，但要在报表上注明这是本站自定义指标，别叫可读性分数，免得几个月后又被人当成行业通用值去横向比较。

## 阅读时长这个指标能不能替代可读性分数？

不能直接替代，因为它测的是另一件事，而且干扰因素太多。读得久可能是因为内容有价值，也可能是因为读者一直在找答案没找到；读得短可能是因为写得清楚，也可能是因为一眼看出不对就走了。把它跟任务完成度放在一起看才有意义：能完成任务且用时短的才是好，能完成但用时长的说明信息藏得太深，完不成的那批才是真正要改的对象。单看时长会得出完全相反的结论，这类代理指标的通病都是这样。

## 用AI生成的小语种内容，可读性分数会不会天然更好看？

通常会，而且这恰恰是个警告信号。生成模型倾向于产出句长均匀、词汇常见、结构规整的文本，这套特征正好是可读性公式喜欢的。分数好看不代表内容好，它可能只说明这段文字很平庸：没有具体数字、没有限定条件、没有行内术语。用本文那三个数去测，你会发现必留术语保留率往往偏低，句长分布也被压得很平。所以在AI辅助写作的场景下，可读性分数的误导性比人工写作时更强，而不是更弱。

## 必留术语表该由谁来列，列多少个合适？

由懂这个品类的母语者列，最好是同时了解用户怎么搜的那个人，通常是本地运营或者本地渠道经理，纯译者列出来的往往偏书面。数量上一个品类几十个就够，别追求穷尽，先覆盖出现频率最高、也最容易被换掉的那一批。列的时候标三列：术语原形、允许的变体形态、绝对不能替换成的口语说法。第三列最有用，因为它把模糊的不要乱改变成了一条可执行的检查规则。

## 分数很低但转化一直不错的页面，要不要动？

别动，去研究它为什么好。分数低而转化好，说明这一页的信息密度和术语准确度撑住了用户的决策，这正是可读性公式测不到的价值。更值得做的是把它当成本语言的内部对照组：它的句长分布是什么样、术语密度多高、限定条件怎么写的，把这些特征提取出来，反过来当作同类页面的参照标准。用自己站上表现最好的页面当基线，比任何外部阈值都可靠。

## 多语言站的验收标准要不要统一？

框架统一，数值不统一。三个指标的定义、测法、验收流程要全站一致，这样才能沉淀成规范、才能培训新人、才能自动化。但每门语言的阈值必须各自标定，因为构词方式决定了句长和词长的自然区间。硬要统一数值的结果，一定是某几门语言永远不达标，团队要么给它们开永久豁免，要么逼着译者写出不像本地话的句子，两种结果都不好。框架统一数值分开，这一条在多语言站的很多指标上都适用。

## 权威参考资料



## 十种语言里十份口径一致的资料，回头一查是同一篇英文翻出来的

- URL：https://zhangwenbao.com/untranslated-invisible-ai-retrieval-translated-content-tradeoff.html
- 分类：小语种SEO
- 发布：2025-09-08  |  更新：2026-07-27
- 摘要：没做本语言版本不是排名靠后，是不在这门语言的候选池里。讲清翻译能拿到什么红利，以及代价的两层：英语默认值被当成本地事实，还有十份译文其实回溯到同一篇原文，交叉验证在这里整个失效。
- 关键词：AI搜索,多语言SEO,内容本地化,小语种SEO

> **TLDR**：摘要：没做本语言版本的页面，不是排名靠后，是根本不在这门语言的候选池里，这两种状态在后台看是同一个零。翻译能把你放进池子，红利在低资源语言里相当可观；代价有两层，一层是英语默认值被当成本地事实，另一层更隐蔽——十种语言里十份口径一致的资料，回头一查往往是同一篇英文翻出来的，交叉验证在这里整个失效。

> 摘要：没做本语言版本的页面，不是排名靠后，是根本不在这门语言的候选池里，这两种状态在后台看是同一个零。翻译能把你放进池子，红利在低资源语言里相当可观；代价有两层，一层是英语默认值被当成本地事实，另一层更隐蔽——十种语言里十份口径一致的资料，回头一查往往是同一篇英文翻出来的，交叉验证在这里整个失效。

## 不做本语言版本，到底是排名低还是根本不在场？

## 排名靠后和根本不存在是两种状态

这两件事在报表上长得一模一样，都是零。

但它们对应的动作完全相反。

排名靠后意味着你在候选名单里，只是没被选中。

不存在意味着连名单都没进，优化多少次都不会有反应。

传统搜索时代这两者的界限还算清楚，因为收录状态是可查的。

到了这一层，你没有任何一个后台能告诉你自己在不在候选池里。

没有反馈的缺席，是这件事最难受的地方。页面被降权会有迹象，页面没被收录能查到，而这里的不在场是静默的——你的德语站做得再好，用户用芬兰语提问时，它不会以任何形式出现在这段链路里，也不会有任何信号告诉你这件事发生过。你甚至不知道有过这么一次机会。

还有一个实际的后果：这两种状态需要的说服材料完全不同。跟老板解释排名不好，你能拿出竞品对比、拿出优化清单；解释不在场，你只能拿出一份自己跑的实测记录。后者更难讲，也更容易被当成借口，所以那份实测记录一定要有截图、有日期、有具体的问句。

## 候选池是按语言分层的

解释一下为什么会这样。

用某门语言提问时，检索优先在这门语言的文档里找。

找不到足够的候选，才会跨语言去找别的语言的资料。

所以你的内容用哪门语言写，决定了它出现在哪一层。

不是权重问题，是分层问题。

层与层之间的门槛，比同一层内部的排名差距大得多。

这个分层机制在研究里已经被反复测过。一份面向文化敏感任务的跨语言稳健性基准 (https://arxiv.org/abs/2410.01171)给出的观察是：同语言检索在高资源语言上效果好，到了低资源语言反而会拖后腿，因为相关信息压根只存在于别的语言里。反过来读这句话就是本文的起点——低资源语言里，本语言那一层很空，谁往里放东西，谁就被拿去用。

分层还有一个容易被忽略的后果：跨语言那一步是有代价的。系统跨到别的语言去找资料时，语义匹配的精度会掉一截，答案的稳定性也跟着掉。所以本语言那一层空着，受损的不只是你，还有这门语言的用户——他们拿到的答案质量本来就比高资源语言的用户低一档。

## 隐形这个词不是修辞

选这个词是因为它描述得最准。

不是被排到后面，是不出现在这次检索的视野里。

用户看不到，你也看不到，双方都不知道错过了什么。

传统的可见性指标在这里全部失灵。

展现量为零、点击为零、排名无记录，三个零说的是同一件事。

而它们不能区分不在场和没被选中。

要区分只能靠主动测。拿本语言问十条问题，看来源清单里有没有你、有没有跟你同类的站。如果整个清单里一家本地同行都没有，那多半是这一层还空着；如果本地同行在、只有你不在，那才是排名问题。上一篇讲的那套三列实测 (https://zhangwenbao.com/ai-search-language-bias-low-resource-citation-source-audit.html)正好能拿来做这个判断，跑一次同时能回答两个问题。

顺带说一句这个词的来源。按语言统计的网络语料分布图 (https://commoncrawl.github.io/cc-crawl-statistics/plots/languages)上，排到几十位之后的语言在纵轴上几乎贴着零线——不是没有，是画在图上看不见。你的内容如果不在那门语言里，处境跟那条看不见的线是一样的。

## 先确认自己属于哪一种

动手之前的判断只需要一个下午。

第一步，确认这门语言里有没有本地站被引用。

第二步，确认你的品类下有没有本语言的候选出现。

第三步，确认你自己有没有这门语言的内容。

三个是的话，那是排名问题，按常规打法做。

第三个是否的话，先别谈优化，先谈在不在场。

这个顺序反过来做，会浪费掉整个季度。见过一个做家居收纳的团队，为了在北欧几个市场提升可见度，把英语版页面的结构改了三轮，加了问答区、加了标注、重排了段落。三轮下来数据一动不动，因为那几个市场的用户提问用的是本国语言，而他们一份本语言页面都没有。改的三轮全在另一层里进行，跟目标那一层没有交集。

判断的时候不妨也参考一下研究里的结论。一份关于多语言检索系统语言偏好的工作 (https://arxiv.org/abs/2502.11175)观察到，本语言候选越少，系统转向其他语言的倾向越强。反过来读就是：如果你在自己那门语言里连一个本地同行都测不到，那基本可以确定这一层是空的，问题不在排名。

## 翻译内容在这个场景下能拿到什么红利？

## 稀缺性可以直接兑换成引用

先说好消息，这个红利比多数人估计的大。

在一门低资源语言里，某个具体问题往往一份像样的资料都没有。

这时候你翻译过去的页面，可能是这门语言里唯一在正面回答的文档。

唯一的意思是：不需要竞争，只需要存在。

这跟英语市场那种几十家抢几个位置的局面完全不同。

成本是一次翻译，回报是一个品类问题上的独占。

在候选极度稀缺的池子里，存在本身就是一种排名。这句话在英语市场是句空话，在低资源语言里是字面意思。这也解释了一个常被误解的现象：有些质量并不出众的本地页面反复被引用，不是因为它写得好，是因为在那门语言里它没有对手。

要小心的是别把这个红利理解成质量不重要。稀缺带来的是入场资格，不是长期席位；一旦这门语言里出现第二份、第三份认真写的内容，之前那种存在即排名的状态立刻结束，比的重新是内容本身。所以红利期该做的事是尽快把内容做扎实，而不是趁着没人比快速铺量。

## 中等质量的译文也能进池子

这一节容易被误读，先把边界说清楚。

能进池子不等于可以糊弄，也不等于机翻直发没问题。

说的是这件事的门槛没有想象中那么高。

一份经过人工校对、术语统一、事实核对过的译文就够用了。

它不需要读起来像本地作者原创。

它需要的是事实正确、结构清晰、能被整段摘出来。

这跟机器翻译直接发布那篇 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)划的那条质量红线并不矛盾，两者关心的东西不一样：那条线拦的是原始机翻直接上线带来的收录与排名风险，本文关心的是内容里的事实对不对、能不能被拿去当答案。同一份译文可以同时通过语言质量这一关、卡在事实准确这一关上，反过来也成立，两道关得分别验。

还有一条界限要划清楚：能进池子说的是被检索到的可能性，不是被优先采用的可能性。一份事实准确但表述含混的译文，可能被检索到却始终不被选作答案。所以这道门槛应该理解成必要条件，跨过它之后该做的功课一样都少不了。

## 这个红利有窗口期

好消息说完，说说它的保质期。

稀缺性来自别人还没进来。

一旦某门语言的某个品类被几家填满，红利就归零了。

填满的速度跟这个市场的商业价值成正比。

所以高价值品类的窗口最短，冷门品类的窗口能开好几年。

判断窗口还剩多久，看这门语言里同类内容每季度新增几篇就行。

这个判断有个很省事的做法：把去年做过的那份供给密度统计原样重跑一遍，对比两次的数字。数字没怎么变，说明窗口还开着；数字翻了一倍，说明有人已经在做同样的事了，该加速了。测量方法在问答长尾那篇 (https://zhangwenbao.com/minor-language-qa-long-tail-content-value-ai-era.html)里写得很细，二十分钟能测完一个品类。

窗口期还有一个更微妙的特征：它在不同问题上关闭的速度不一样。热门问题先被填满，冷门问题能空很久。所以就算某个品类的整体窗口在收窄，具体到问题层面仍然有大片空地。判断该不该继续投入，要下沉到问题这一层看，别停在品类层面下结论。

## 代价的第一层：英语默认值被当成了本地事实

## 哪些字段最容易带着默认值过来

先列清单，这类字段的数量比想象中少，但每一个都要命。

退换货期限、保修年限、税费口径、发票形式。

尺码对照、电压插头、包装规格、计量单位。

安全标准编号、认证标志、合规声明。

配送时效、可达区域、可否托运。

四组加起来十来个字段，覆盖了绝大多数出事的地方。

共同点是：它们在原文里都是正确的，翻译过程也没出错，错的是它们不该被搬过来。翻译工序的验收标准是译文忠于原文，而这类字段恰恰是越忠于原文越错。这是一个工序设计上的结构性漏洞——没有任何一道现有工序的职责是发现这件事，因为它不是翻译错误。

这份清单还有个用法：拿它去反查已经上线的老页面。多数团队的本地站上都躺着几年前翻译的内容，那时候没有这道核对工序，字段大概率是原样搬过来的。按清单扫一遍历史页面，通常能捞出一批需要修正的数字，成本很低但收益立竿见影。

## 为什么母语审校也很难发现

这一节解释那个漏洞为什么补不上。

母语审校审的是语言，判据是读着自不自然、术语对不对。

十四天还是三十天，审校没有立场去质疑。

他会默认这个数字是业务方给的，是有依据的。

而业务方默认审校会发现不对的地方。

两边各自默认对方负责，于是没人负责。

要补这个漏洞，只能在审校清单里明确加一项：本地规则字段需单独核对，并注明由谁核对。这跟母语审校验收清单那篇 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)的思路一致——验收清单的价值不在于严格，在于把没人负责的地带明确划给某个人。核对的依据也要写清楚，比如欧盟市场就直接对着消费者权益指令的官方说明页 (https://ec.europa.eu/info/law/law-topic/consumer-protection-law/consumer-contract-law/consumer-rights-directive_en)和本国的对应法条查，不靠记忆。

还有一种更隐蔽的情形：审校本人其实觉得不对劲，但没说。跨部门提出质疑是有社交成本的，尤其当那个数字来自总部时。要打消这层顾虑，清单上就得明确写着这一项归你判，把提问变成职责而不是多管闲事。

## 被引用之后，错误会离开你的页面

这是这一层代价里最不好收拾的部分。

页面上写错一个数字，影响范围本来是看到这个页面的人。

一旦这段内容被拿去组织答案，影响范围就变了。

用户可能从来没打开过你的页面，却拿到了你写错的那个数字。

你改页面很容易，但那段已经流出去的答案不受你控制。

而且用户不会知道这个信息来自谁，出了事你也未必被追到。

听起来像是免责，其实是更糟的情形：你既承担了错误的后果——用户带着错误预期来找你——又拿不到修正的机会。这跟传统的页面纠错完全是两种时间尺度，德国民法典里对撤回期的规定写得清清楚楚 (https://www.gesetze-im-internet.de/bgb/__355.html)，一旦你的页面在这个数字上出过错，纠正它需要的时间远比写错它长。

还有一个连带影响是内部的：一旦发现某个错误已经流传出去，团队的第一反应往往是全面停掉本地化产出，等流程整理好再说。这个反应可以理解但代价很大，正确的做法是停掉出问题的那一类字段，其他部分照常推进——把一次局部事故升级成全面停摆，损失比事故本身大得多。

## 这一层的修法其实很朴素

好在解法不复杂，就是麻烦。

把上面那十来个字段做成一张表，逐语言填。

翻译工序开始之前，这张表先填完。

翻译时这些字段整体锁定，译者不许动，按表填入。

审校时这些字段单独走一遍核对，依据写在旁边。

一个市场填一次，之后除非法规变动，几年不用碰。

这张表还有一个附带好处：它把本地化里最容易出事的部分从流程里摘了出来，变成一份可以被审计的资产。出问题的时候你能指着表说这个数字是哪年哪月依据什么填的，而不是在几十份译文里逐个排查。把易错的部分抽出来做成单一数据源，比在每一处提醒大家小心有效得多。

表的维护也要指定人。字段表最容易出的问题不是填错，是法规变了没人改。建议给每个字段加一个复检日期，跟法规更新周期对齐，到期自动提醒。这比要求大家关注法规动态可靠得多，因为前者不需要任何人记得。

## 代价的第二层：十份译文其实是同一份原文

## 多路平行是什么意思

这个概念是本文的核心，值得慢慢说。

同一份英语内容，被不同的人翻译成了很多种语言。

从池子里看，这是十几份不同语言的文档。

从信息上看，这是同一份内容的十几个影子。

语言不同、措辞不同、来源域名不同，唯独信息是同一个。

这种现象在低资源语言里的比例高得惊人。

一份专门统计网络上机器翻译内容占比的研究 (https://arxiv.org/abs/2401.05749)把这件事量化了出来，两个结论值得记住：一是低资源语言的网络内容里机器翻译占比显著更高，二是这些内容大量呈现多路平行的特征，也就是同一批源文本被翻成许多种语言同时存在。这两条合起来意味着，低资源语言那个本来就很浅的池子里，还有相当一部分是同一口井里打出来的水。

这个现象在中文互联网上其实很好理解，等同于同一篇稿子被十几个号洗过一遍。区别在于跨语言的版本更难被识别——同一篇中文稿的十个版本，人眼一看就知道；同一篇英文稿翻成十种语言，除非有人同时懂这十种语言，否则谁都发现不了它们是一份东西。

## 交叉验证在同源文档上会失效

这是多路平行真正危险的地方。

多来源相互印证，是判断信息可靠性最基本的方法。

它成立的前提是这些来源彼此独立。

同一份原文翻出来的十份文档，独立性为零。

可它们在形式上完全符合多来源的特征。

不同域名、不同语言、不同措辞，看起来是十家在说同一件事。

共识的可信度来自来源之间的独立性，而翻译恰恰是一种系统性地制造非独立来源的机制。这句话值得多读一遍。它意味着在翻译内容密集的语言里，看起来越一致的信息，可能越不该被当成共识——因为一致性本身就是复制出来的，不是独立验证出来的。

还有一个更细的层次：同源不一定是整篇同源。一篇本地原创的文章里，某一段关于标准或者数据的描述可能是从同一份英语资料翻过来的，其余部分完全原创。所以判断同源要按信息点来判，不能按文档来判——整篇原创的内容里，照样可能藏着一个被复制了十次的错误事实。

## 一个错会以十种语言同时出现

把上面两条合起来，就是最坏的情形。

原文里有一处本地事实是错的，或者只是不适用于别的市场。

十份译文原样带走这一处。

于是这个错误以十种语言、十个域名的形式同时存在。

任何一次交叉验证都会得出这是公认事实的结论。

而事实上，全世界只有一个人写过这句话。

更麻烦的是纠错路径。你发现自己那份译文错了，改掉很容易；但另外九份不是你的，你既不知道它们在哪儿，也没有立场去改。十语模板那篇 (https://zhangwenbao.com/multilingual-template-ten-languages-duplicate-content-risk.html)讲过一个形态相近的问题：模板的真实风险是把一次内容策划的疏漏原样复制成十份。本文这个更进一步——那时候十份都是你自己的，这回十份分散在十家手里。

这个机制在语料侧也留下了痕迹。按语言切分的开放语料项目 (https://oscar-project.org/)在做数据清洗时会专门处理重复与近似重复的文档，而跨语言的同源内容恰恰躲得过这类去重——它们在字面上完全不重复。字符层的去重工具对信息层的重复无能为力，这一点跟模板内容的老问题是同一个根。

## 怎么自查自己是不是影子之一

最后落到可执行的动作上。

问一句：这份内容里有没有一处事实，是只有本地才知道的。

如果通篇找不出一处，那你多半就是一个影子。

有本地价格、本地服务点、本地法规引用、本地实测数据，就不是。

这个自查不需要工具，一份内容三分钟。

而且它的结论直接指向修法：缺什么就补什么。

把这条做成翻译工单上的最后一栏，写明本地独有信息，不填不能提交。填的时候只要求一句话，比如某国的服务点城市、某国的实测数据、某条本国法规的编号。一句只有本地才写得出的话，就足以让这份内容脱离影子的行列——它不再是可替换的第十一份译文，而是这门语言里必须被读一次的文档。

自查的结果还能拿来排优先级。手上十份译文，其中三份找得出本地独有信息、七份找不出，那接下来该补的就是那七份，而不是继续翻新的。把影子变成实体，比再造一个影子划算得多，而且前者的成本通常只是加两三句话。

## 那到底该翻译、该原生写，还是干脆不做？

## 三档决策的判据

把选择压到三档，判断才做得下去。

第一档，原生写：本地规则、本地服务、本地案例，必须本地产出。

第二档，翻译加核对：通用知识、产品原理、使用方法，翻译后核事实。

第三档，不做：这门语言的用户其实在用别的语言搜，那就别做。

判据是三个问题，一个下午能答完。

这个答案会不会随国家变、这门语言里有没有人在答、用户是不是真用这门语言搜。

三个问题的顺序不能换。先问会不会随国家变，能筛掉一大半内容；再问有没有人在答，决定优先级；最后问用户用不用这门语言，这一问是止损，答错了前面两问做得再好也是白做。决策树的第一个分叉一定要放在最省力的那个问题上，否则你会在一堆本来就不用做的内容上做精细分析。

三档之外还要留一个待定档，专门放那些暂时判断不了的内容。硬要在信息不足的时候归档，结果通常是随手归进翻译档，因为那是默认路径。设一个待定档并规定它每月清空一次，比逼着大家当场做决定要健康。

## 必须原生的字段清单

把第一档具体化，避免执行时各人理解不同。

价格与货币、税费与发票、退换货规则与期限。

配送范围与时效、服务点与联系方式。

本国适用的标准编号、认证与合规声明。

本地客户案例、本地实测数据、本地媒体引用。

这四组是硬清单，一条都不能靠翻译。

其余内容都可以进第二档，只是要过事实核对。

清单要写成模板挂在工单系统里，别指望大家记住。执行层面最有效的动作是把它变成一个提交时的必填项——不填不能提交，比培训十次都管用。这跟前面那条本地独有信息栏是同一个手法：凡是靠自觉的检查项，长期执行率都会掉到很低；变成流程阻塞项之后，执行率就是百分之百。

清单里的每一项还要注明依据来源。比如退换货期限这一格，欧盟市场就写明依据是德国民法典关于撤回后果的条文 (https://www.gesetze-im-internet.de/bgb/__357.html)与本国对应法条，而不是只填一个数字。填数字的表在换人之后没人敢改，填了依据的表任何人都能重新核一遍。

## 可以放心翻译的部分比想象中多

说完限制说宽松的一侧，免得把人吓住。

产品的工作原理、材料的物理属性、通用的使用方法。

保养步骤、故障排查、组装说明。

这些内容跨国一致，翻译过去没有任何问题。

它们通常还占了一个品类内容体量的大半。

所以真正需要原生产出的比例，可能只有两三成。

两三成的原生成本，撬动的是整个语言层的在场。

把这个比例算给管预算的人听，方案通过的概率会高很多。多数人对做本地语言版本的第一反应是全部重写太贵，而真实的账是七八成可以翻译、两三成需要本地产出。这个数字一摆出来，讨论的焦点就从要不要做变成了先做哪几个市场。

估算这个比例有个现成的参照：看看你的产品文档里有多少内容是跨国通用的。翻译服务的语言支持文档 (https://cloud.google.com/translate/docs/languages)这类纯技术性说明就是典型的可翻译内容，而同一份手册里的保修条款和服务网点则不是。按这个眼光把手头内容过一遍，两三成这个数字通常八九不离十。

## 怎么判断一门语言值不值得做本语言版本？

## 先看这门语言里有没有人在答这批问题

第一个信号，也是最便宜的信号。

拿十条本语言问句去搜，看前二十位里有几条在正面回答。

回答得多，说明这门语言的商业内容生态是成熟的。

回答得少，说明要么没人做，要么这门语言的用户不在这儿。

两种情况的区别，靠下一个信号来分。

这一步只需要二十分钟，别跳过。

供给密度是语言和品类的交叉属性，这一点前面提过，这里再补一句实操细节：一定要按你自己的品类去测，别用通用问题测完就下结论。同一门语言里，日用消费品的内容供给和专业器材的内容供给能差好几倍，用错品类测出来的结论会把你带偏一整个方向。

测的时候要留意一个陷阱：结果里出现大量本语言内容，不一定说明供给充足，也可能是自动翻译的聚合站在撑场面。判断方法是点开三五个来源看看，如果全是同一类聚合页，那本质上还是空的。真正的信号是本地品牌、本地媒体、本地社区在正面回答。

还有一件事要一并确认：这门语言在产品侧有没有被点亮。国家数与语言数错位那篇 (https://zhangwenbao.com/ai-overviews-100-countries-six-languages-minor-language-citation.html)讲过怎么用二十分钟测出自己的语种在哪一档。两件事要分开看——语言没被点亮，你补的内容暂时兑现不了；候选池空着，补进去的内容随时可能被拿去用。前者要等，后者不用等。

## 再看用户是不是真的用这门语言搜

第二个信号是止损用的。

有些市场的用户习惯直接用大语种提问。

技术类、专业类查询尤其明显。

这时候本语言那一层是空的，但空着也没人来。

你把它填满，填的是一个没人站的位置。

判断方法是看本地社群和评论区里，大家讨论时用的是哪门语言。

这个判断有个反例要留意：日常问题和专业问题可能分属两门语言。同一批用户问怎么保养用本语言，问技术参数用英语。菲律宾式英语那篇 (https://zhangwenbao.com/philippine-english-taglish-mixed-language-keyword-research.html)讲的嵌套型双语就是这种情形的极端版本。碰到这种市场，结论不是做或不做，而是按问题类型分别决定——保养类做本语言，参数类保留英语。

还有一个客观数据可以当佐证。按国家整理的数字生态年度报告 (https://datareportal.com/reports/digital-2024-indonesia)里有语言使用与平台渗透的基础数据，跟你在社群里观察到的语言习惯放在一起看，能避免被少数活跃用户的语言偏好带偏。观察加数据两条腿走，比只凭感觉稳。

## 最后才看市场规模

把最常被放在第一位的指标放到最后。

市场规模决定的是这件事的天花板。

前两个信号决定的是这件事成不成立。

天花板再高，不成立也是零。

而且在这个场景下，小市场反而常常更划算。

因为稀缺性带来的独占，在小市场里更容易拿到。

这个排序跟传统的市场优先级排法几乎是反的，语种优先级成本模型那篇 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)算过一笔类似的账：排在最前面的那几门语言往往最后才该动，因为那里的每一分投入都要跟已经在场的对手硬碰。到了本文这个场景，这个结论比当年更成立——那时候争的是排名，现在争的是在不在场。

还有一个跟规模有关的反直觉现象：大市场的本语言内容供给虽然充足，但里面平台内容的占比也更高，本地事实那一格反而未必被填满。所以就算你决定优先做大市场，也别默认那里的事实类内容已经有人写好了——去测一次，经常会有意外发现。

## 译文的同源性怎么自查？

## 回译对比法

最直接的一种检查，成本极低。

把你的译文用工具回译成英语。

拿回译结果跟你怀疑的那份英语原文比。

句子结构高度一致，说明同源。

这不是抓抄袭，是判断自己有没有独立信息。

相似度高不一定是坏事，前提是你另外加了本地内容。

这个方法在学术上也是成立的检测思路，一份用回译相似度检测机器翻译文本的工作 (https://aclanthology.org/2021.naacl-main.462/)做的正是同一件事：原文经过翻译再翻回来，如果结果跟某个候选高度重合，那基本可以判定它经过了那条链路。你不需要复现它的方法，借用它的直觉就够——回译之后还剩下的差异，才是你真正添加的信息。

这个方法有个使用边界：它只适合自查，不适合拿去指控别人抄袭。回译相似度受工具本身影响很大，同一份内容用不同工具回译能得出不同的相似度。用它来判断自己有没有加进独立信息是可靠的，用它来做外部判定就不严谨了。

## 事实点抽样核对

第二种检查针对的是内容而不是形式。

从译文里挑十个具体的事实点。

数字、期限、标准编号、地名、机构名。

逐个核对它们在本地是不是这个值。

十个里错一两个属于正常，错四五个说明整份都要重来。

这个抽检十五分钟能做完，建议每批译文抽一份做。

抽检要随机抽，别让译者自己挑一份来抽。这条听着多余，但实际操作中十次有八次会退化成挑一份最好的来检查。低资源语言幻觉率那篇 (https://zhangwenbao.com/low-resource-language-ai-hallucination-rate-content-risk.html)里那套按语料丰度和责任等级定抽检比例的矩阵，可以直接搬过来定这里的抽检强度，两件事的风险结构是一样的。

抽检结果要记录下来形成时间序列，而不是查完就算。同一个供应商、同一个市场，连续三批抽检的错误率如果在上升，那说明流程某处松了，这个信号比单批的错误率有价值得多。表格很简单：批次、抽检数、错误数、错误类型，四列足够。

## 找一处只有本地才知道的细节

第三种最省事，也最能说明问题。

通读一遍，找出一处只有在本地做过生意才写得出来的信息。

找得到，这份内容就有独立价值。

找不到，它就是可替换的。

不需要多，一处就够，但必须是真的。

编一个本地细节比不写更糟，因为它会被当成事实传出去。

这一处细节还有个额外用处：它是本地团队最容易贡献的东西。让本地同事读一遍译文、补一句他知道而总部不知道的事，这个动作对他们来说几乎没有成本，对内容质量的提升却很大。本地化流程里最被浪费的资源，就是本地团队脑子里那些没被问过的常识。

这一处细节最好放在内容靠前的位置，别埋在文末。它既是给读者的信号，也是给检索侧的信号——一段包含具体本地信息的开头，比一段通用的品类介绍更容易被识别为本地相关。位置这件事不花钱，只花一次调整段落顺序的功夫。

## 机器翻译直接发布和这件事，是同一个问题吗？

## 老问题关心的是质量和收录

先把老问题的边界说清楚。

机翻直发的经典风险是内容质量低、读着不通、被判为低质。

后果落在收录和排名上。

验收标准也很明确：读着通不通、术语对不对、有没有明显的翻译腔。

这条线画了很多年，行业里的共识相当稳定。

它管的是语言质量这一层。

这条线本身没有过时，机器翻译直接发布那篇 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)里那套判据今天依然要执行。翻译腔这件事本身也是有研究基础的，关于机器翻译体的语言复杂度研究 (https://arxiv.org/abs/2102.00287)发现机翻文本在词汇多样性和句法复杂度上会系统性地偏低，这种偏低是可测的，不完全依赖人的语感。

值得强调的是这条线到今天仍然是第一道关。跳过语言质量直接谈事实核对，等于在一份读起来磕磕绊绊的内容上纠结数字对不对，顺序反了。先过语言关，再过事实关，两关的顺序不能换，因为语言不通的内容根本走不到被引用那一步。

## 新问题关心的是事实和来源独立性

新问题在另一层上。

一份译文可以完全通过语言质量的检查。

读着自然、术语准确、一点翻译腔都没有。

同时它仍然携带着英语默认值，仍然是某份原文的影子。

语言质量这一关拦不住这两件事，因为它们不是语言问题。

所以两道关必须分开设，共用一道会漏。

翻译质量提高，反而会让第二类问题更难发现。粗糙的译文一眼看得出是翻的，会引起警觉；打磨精良的译文读起来像原创，反而没人去追问它的事实来自哪里。这跟前面讲流畅度不再是可靠信号是同一个道理——语言层的完美程度，从来就不是事实层可靠性的证据。

识别第二类问题还有个反直觉的经验：越是本地化做得好的团队，越容易在这里翻车。因为他们的译文质量高、语域贴切、读着像原创，所有质量信号都是绿的，于是没人会想到去追问那个十四天是哪儿来的。质量高反而降低了警觉，这是个很不舒服但真实的规律。

## 两者的验收标准要分开写

落到执行上，就是两张清单。

第一张管语言：通顺度、术语一致性、语域是否匹配。

第二张管事实：本地字段是否核对、有无本地独有信息。

两张清单由不同的人签字，别合并。

合并之后一定会退化成只查第一张。

因为第一张查起来快，第二张要动脑子。

分开还有一个好处：责任清楚。语言那张归本地化团队，事实那张归业务方或本地市场负责人。出问题的时候能立刻定位到是哪一层没守住，而不是开一次会互相猜。这个分工在早年那批逐词直译的关键词表 (https://zhangwenbao.com/keyword-literal-translation-legacy-cost-non-english.html)留下的教训里已经有过一次预演——那次是词表层面的，这次是内容层面的，根因都是把两种不同性质的检查压进了同一道工序。

两张清单的检查密度也可以不同。语言那张每份必查，事实那张可以按批次抽查——前提是本地字段已经用表格锁定，抽查验的是流程有没有被绕过，而不是逐份重新核对。这样总工作量不会翻倍，但两层风险都盖住了。

## 翻译内容的红利会不会消失？

## 池子填满之后稀缺性就没了

先说结论：会，但没那么快。

红利来自本语言候选稀缺，稀缺消失红利就消失。

填满的路径有两条，本地原创增长和翻译内容涌入。

后者的速度快得多，因为成本低得多。

所以池子多半会先被翻译内容填满。

而那时候的池子，质量结构会很奇怪。

奇怪在于：文档数量上去了，独立信息源的数量没怎么涨。一个装了两百份文档、其实只有二十个独立信息源的池子，跟一个装了二十份独立文档的池子，检索起来的效果不见得更好，但你想挤进去的难度确实变大了。这是一个数量繁荣但信息量停滞的阶段，而对后来者来说，这个阶段比空池子更难做。

还有一个判断池子状态的实用指标：同一批问题下，来源的域名重复率。如果十条查询里反复出现同样那三五个域名，说明这门语言的供给还很集中，缺口仍然大；如果域名分散、每条查询都有新面孔，说明池子已经开始饱和了。这个数字从实测表里直接就能算出来。

## 谁会先把池子填满

看清楚这一点，能帮你判断该不该现在动手。

大平台和聚合站的翻译成本接近于零，它们会最先动。

品牌方动得慢，因为内部流程长。

本地媒体和垂直站取决于当地的商业化程度。

所以典型的填充顺序是：平台先进，品牌后进。

而平台内容的本地事实密度通常很低。

这留下一个持久的缺口：平台能把池子的数量填满，填不了本地事实那一格。退换货规则、本地服务点、本国标准这些东西，平台没有动力逐国去写，也写不准。所以哪怕池子在数量上被填满了，本地事实这一块的空位仍然会长期留着——这恰好是品牌方唯一能长期守住的位置。

本地媒体这一支值得单独说。在商业化程度高的市场，本地垂直媒体会很快补上这个缺口，而且他们写的本地事实通常是准的。这时候品牌方要考虑的就不只是自己写，还包括怎么让这些媒体引用你的数据——那是另一条更长期但更稳的路。

## 现在进场的意义

最后把账算完。

现在进场，成本是一次翻译加两三成的本地产出。

拿到的是一段时间的独占，和一批稳定的本地事实位置。

晚两年进场，成本一样，但要跟一池子影子文档挤。

而且那时候你补的本地事实，可能要花更长时间才被采信。

先来的不一定赢，但先来的确实便宜。

更实际的一点是，早进场的内容有更长的时间去积累外部引用和本地信任信号，这些东西不能靠加钱加速。小语种外链那篇 (https://zhangwenbao.com/minor-language-link-building-local-directories-media-communities.html)讲过本地渠道的建设周期，那是按季度算的，急不来。现在动手和两年后动手的差别，不只是内容多两年，是整条本地信任链早两年开始长。

最后提醒一句时间的不对称性：内容可以随时补，信任积累不能压缩。今天写下的一份本地事实页面，两年后它已经被引用过、被链接过、被本地同行提过；两年后才写的同一份页面，内容一模一样，但它还是新的。这段差距不是靠预算能追回来的。

## 这套判断怎么排进现有的本地化流程？

## 在翻译工单上加一道字段分流

改动落在工单模板上，一次改完长期生效。

工单开头加一个下拉：这段内容属于哪一档。

原生、翻译加核对、不做，三选一。

选原生的直接派给本地团队，不进翻译队列。

选翻译的自动带出本地字段核对清单。

三档一分，后面所有工序的走向就定了。

这个改动的关键是把判断前置到工单创建时，而不是留到审校时。审校阶段发现这段内容根本不该翻译，等于整道工序白做。凡是能在流程入口做的判断，都不要留到出口做，这条在任何生产流程里都成立，本地化流程尤其明显，因为它的返工成本特别高。

下拉选项的措辞也要下点功夫。写成原生、翻译、不做太抽象，写成本地规则类必须本地写、通用知识类可翻译后核对、这门语言用户不用则不做，虽然长了点，但填的人不用回去查文档。流程字段的措辞本身就是最好的培训材料，这句话在任何表单设计上都成立。

## 谁来做事实核对这道工序

这道新工序要落到具体的人头上。

不能是译者，他没有本地业务信息。

不能是母语审校，那是另一种能力。

最合适的是本地市场负责人或者本地客服主管。

他们手里有真实的规则，也知道用户实际会问什么。

工作量不大，一份内容十来个字段，十五分钟。

如果某个市场没有本地人手，退而求其次的做法是让总部的人对着法规原文逐条核，速度慢但可行。真正不能接受的是跳过这一步——没人核对的本地字段，等于默认采用了英语原文的口径，而那个口径几乎肯定不适用。

这道工序还有一个隐性收益：它会把本地负责人拉回到内容这件事上来。很多市场的本地负责人跟内容生产是脱节的，加了这道十五分钟的核对之后，他们对本地站上写了什么心里有数了，后面反馈用户实际问题的意愿也会明显变高。

## 一个季度能推进多少

最后给个可以写进排期的量。

第一个季度：定三档判据、建字段表、改工单模板。

同时挑一个市场跑通全流程，作为样板。

第二个季度：把样板复制到三到四个市场。

本地字段表按市场逐个填，这是最花时间的部分。

第三个季度开始，产出会稳定下来。

一年铺完五六个市场是个现实的节奏。

别贪快。这套流程的价值在于它建立起来之后就不会退化，而急着一年铺十个市场的结果，通常是十个市场的本地字段表都填了一半，然后全部搁置。本地化这件事上，能长期维持的慢速度，胜过维持不住的快速度——毕竟填了一半的字段表，比没填的更危险，因为它会让人误以为这项检查已经做过了。

推进过程中要留一个复盘节点。第二个季度末回头看第一个市场的样板，多半会发现字段表有两三格设计得不合理、或者某道工序在实际中被跳过了。这时候改还来得及，等六个市场都铺完再改，改的就是六份表。样板市场存在的意义就是提供一次可以低成本犯错的机会，别浪费它。

## 常见问题解答

## 没做本语言版本，跟做了但排名不好，有什么区别？

区别是在不在候选池里。检索会优先在提问语言的文档里找候选，找不到才跨语言去别的语言里找，所以内容用哪门语言写决定了它出现在哪一层。排名不好意味着你在名单里没被选中，还有优化空间；不在场意味着连名单都没进，怎么优化都不会有反应。麻烦的是这两种状态在后台看都是零，只能靠主动测：拿本语言问十条问题，看来源清单里有没有本地同行。

## 翻译内容在AI检索里到底还有没有价值？

在低资源语言里价值相当大。这门语言下某个具体问题往往一份像样的资料都没有，你翻译过去的页面可能是唯一在正面回答的文档，这时候不需要竞争，只需要存在。但要满足两个前提：本地规则类字段必须重新填过，不能照搬原文；内容里至少要有一处只有本地才写得出的信息。两条都不满足的译文，只是这份原文的第十一个影子。

## 什么是多路平行，它为什么危险？

指同一份源内容被翻译成许多种语言同时存在于网上，从池子里看是十几份不同语言的文档，从信息上看是同一份内容的十几个影子。危险在于它破坏了交叉验证：多来源相互印证之所以可信，前提是来源彼此独立，而同源译文的独立性为零，却完全符合多来源的外观特征。结果就是原文里的一处错误会以十种语言、十个域名的形式同时出现，任何一次交叉验证都会把它读成公认事实。

## 哪些内容必须原生产出，不能靠翻译？

四组字段是硬清单：价格与税费与发票形式；退换货规则与期限；配送范围时效与本地服务点；本国适用的标准编号、认证与合规声明。再加上本地客户案例、本地实测数据、本地媒体引用这一类。共同特点是它们在原文里都是正确的、翻译过程也没出错，错在不该被搬过来——越忠于原文越错，而这恰恰是翻译工序的验收标准，所以现有工序天然拦不住。

## 母语审校为什么发现不了英语默认值这类问题？

因为审校的职责是语言，判据是读着自不自然、术语对不对。十四天还是三十天，审校没有立场去质疑，他会默认这个数字是业务方给的、有依据的；而业务方默认审校会发现不对的地方。两边各自默认对方负责，于是没人负责。解法是在审校清单里明确加一项本地规则字段核对，并写清由谁核对、依据什么核对，把这块没人认领的地带划给具体的人。

## 怎么快速判断自己那份译文是不是影子？

通读一遍，找出一处只有在本地做过生意才写得出来的信息——本地价格、本地服务点、本国法规编号、本地实测数据都算。找得到就不是，找不到就是。这个自查一份内容三分钟，而且结论直接指向修法：缺什么补什么。可以把它做成翻译工单上的最后一栏，写明本地独有信息，不填不能提交。注意编造本地细节比不写更糟，因为它会被当成事实传出去。

## 这个红利窗口大概还剩多久？

取决于品类的商业价值，高价值品类的窗口最短，冷门品类能开好几年。判断方法是把去年做过的供给密度统计原样重跑，对比两次数字：没怎么变说明窗口还开着，翻倍说明已经有人在做同样的事。要注意的是池子多半会先被翻译内容而不是本地原创填满，那时候会进入一个文档数量上去了、独立信息源没怎么涨的阶段——对后来者来说，这个阶段比空池子更难做。

## 权威参考资料



## 平台给每个卖家的搜索词字段一样长，可日语卖家能塞进去的词只有英语的三分之一

- URL：https://zhangwenbao.com/minor-language-marketplace-listing-fields-tokenization.html
- 分类：小语种SEO
- 发布：2025-08-06  |  更新：2026-07-30
- 摘要：字段上限写的是字节不是字符，同一个额度在日语上只兑换出三分之一的容量。讲清平台搜索为什么不做词形还原、标题结构规定在哪几门语言拼不出合法短语、自动翻译那一版算谁写的。
- 关键词：关键词研究,跨境电商,多语言SEO,小语种SEO

> **TLDR**：摘要：平台给每个卖家的后台关键词字段是同一个上限，可上限写的是字节不是字符：拉丁字母一个字符一个字节，西里尔两个，日语韩语三个。同一个五百的额度，英语卖家能塞七八十个词，日语卖家只剩二十几个。第二层更硬：词形还原、复合词切分、变音折叠这些网页搜索补了十几年的能力，平台侧多数没有，你的词要么原样命中要么不命中。第三层是标题顺序被平台规定死，而那个顺序在几门语言里拼不出合法短语。本文拆开这三层，给出按站点的词状态表与双向对齐流程。

> 摘要：平台给每个卖家的后台关键词字段是同一个上限，可上限写的是字节不是字符：拉丁字母一个字符一个字节，西里尔两个，日语韩语三个。同一个五百的额度，英语卖家能塞七八十个词，日语卖家只剩二十几个。第二层更硬：词形还原、复合词切分、变音折叠这些网页搜索补了十几年的能力，平台侧多数没有，你的词要么原样命中要么不命中。第三层是标题顺序被平台规定死，而那个顺序在几门语言里拼不出合法短语。本文拆开这三层，给出按站点的词状态表与双向对齐流程。

## 同一个字段，为什么在两门语言里装的词不一样多？

## 一家办公文具卖家的日本站，字段只填进了三分之一的词

有个客户做办公文具，文件夹、标签机、装订机、桌面收纳这几类。

德国站、日本站、波兰站三条线同时在跑，产品是同一批。

德国站的表现一直不错，日本站起量慢，团队一开始归因于品类竞争。

保哥要来三个站的后台关键词字段导出，把三份并排放着数了一遍。

德语那份填了六十多个词，日语那份只有二十一个，而运营明明按同一份词表准备的。

问运营为什么少填，回答是系统提示超出长度，删到二十一个才存得进去。她以为是自己选的词太长，于是把长词删掉留短词——这个动作把整批高价值长尾一次性清空了，而系统从头到尾没告诉她真正的原因是什么。

## 字段上限写的是字节，不是字符

原因在字段的定义里，只是那行小字没人细看。

多数平台的后台关键词字段，上限单位是字节。

字节和字符在英文环境里是一回事，一个字母就是一个字节。

换成别的书写系统，一个字符要占的字节数就变了。

字段上限没变，能装的内容却缩水了，而后台的提示语一个字都没解释这件事。

这是本文第一条要钉死的东西：平台给所有卖家的是同一个数字，可这个数字在不同语言里兑换出来的实际容量差出三倍。它看起来是一条中立的技术规则，实际效果是按书写系统分配了不同的额度，而且分配方向恰好对小语种不利。

## 一个字符要占几个字节，按书写系统分档

把这笔账算清楚，三档就够用了。

第一档一个字节：基本拉丁字母、数字、常见符号，也就是英语能用完的那一套。

第二档两个字节：带变音符号的拉丁字母、西里尔字母、希腊字母、希伯来字母、阿拉伯字母。

第三档三个字节：汉字、假名、谚文，以及大多数东南亚和南亚的文字。

按这三档折算，同一个五百字节的额度，英语能装大约七十到八十个词，德语和波兰语因为带变音字母掉到五十上下，俄语大约三十五，日语和韩语只剩二十出头。

德语和波兰语这一档还有个额外的坑：同一个词写不写变音符号，占的字节数不一样。把变音符号去掉能多塞几个词，可去掉之后这个词还能不能匹配上用户带符号的查询，是另一件要单独验的事。波兰语的九个变音字母用户到底打不打 (https://zhangwenbao.com/polish-seo-seven-cases-diacritics-keyword-research.html)那篇算过这个比例，结论是不能一刀切。

拿一个具体的词算一遍最直观。日语的检索关键词四个字，按第三档算是十二个字节，加上一个分隔空格是十三。同样长度预算下，英语的waterproof十个字母只占十个字节。也就是说一个四字的日语词比一个十个字母的英语词还贵，而它承载的信息量并不更多。这个换算关系一旦算出来，运营就知道该砍哪些词、留哪些词了。

还有一个容易忽略的细节：全角空格和全角标点同样按三个字节算。日语和中文卖家如果习惯用全角逗号分隔关键词，等于每个分隔符都花掉三个字节。换成半角空格分隔，几十个词下来能省出好几个词的位置。这是本节唯一一条不用做任何调研就能立刻回收额度的动作。

## 这条规则在英文卖家那里从来不会成为一个话题

值得停一下想想这条规则的分布。

一个只做英文站的卖家，这辈子都不会遇到这个问题。

他填满五百字节的时候，恰好也填满了五百个字符。

所以平台的官方教程、卖家社群里流传的经验、各种优化清单，全都不会提它。

你能找到的所有关于这个字段的建议，都是在这个前提下写出来的。

这是本站反复讲的那条规律又一次成立：整套方法论是拿一个特例写出来的，而这个特例恰好是唯一一个不受影响的情形。日本用户挑毛巾搜的是手感，那个词在你的属性表里连一格都放不下 (https://zhangwenbao.com/minor-language-onomatopoeia-texture-attribute-keyword.html)那篇讲过同一个道理的另一个版本。

这笔字节账还有一个孪生兄弟在广告那一侧。平台广告的关键词字段、否定词列表、广告文案，多数也按字节或者按字符设上限，而计量口径未必跟自然侧一致。同一个投手在英语账户和日语账户上用同一套投放模板，日语账户的词量会被悄悄砍掉一半，报表上表现为覆盖面窄、曝光起不来，很容易被误判成出价不够。

## 平台的搜索框跟网页搜索，切词是同一套吗？

## 网页搜索这十几年补了什么，平台搜索没补

这一节是比字节账更重要的一层，可惜更不容易被察觉。

网页搜索这十几年在语言理解上补了很多东西。

词形还原、同义扩展、拼写纠错、变音折叠、复合词拆分，这些都已经是默认能力。

平台搜索的目标不一样：它要在毫秒级从上亿个商品里选出可能成交的那几十个。

它的检索管线更短、更硬，也更依赖精确匹配。

结果是同一个查询，网页搜索能靠语言处理帮你兜住的那部分，在平台侧要靠你自己在字段里铺满。这条差别决定了平台侧的词表策略跟网站侧正好相反：网站侧要收敛，平台侧要铺开。

还有一条时间维度上的差别：平台搜索的排序会随销量和转化实时变化，而语言处理能力多年不动。这意味着你在语言层做的改动，效果不会像调价或者投广告那样几天就反映出来，它更像是把一批本来完全接不住的查询接住了，表现为新增的查询词条数而不是原有词的排名上升。看错指标就会误判这件事没用。

## 词形还原在平台侧基本指望不上

具体到屈折语，情况相当直接。

波兰语的一个名词有七个格，单复数各一套，实际会被搜的形态有五六个。

网页搜索大体上能把这几个形态认成同一个词。

平台搜索多数只做很浅的归一化，比如大小写和空格。

你的字段里如果只有主格形态，用户搜宾格形态的那部分查询就接不住。

这也解释了为什么平台侧的关键词字段值那么多钱：它是你唯一一个可以合法堆形态的地方。标题里堆形态会让文案不像人话，正文里堆会被判成堆砌，只有这个不对外展示的字段是专门用来放这些的。波兰语给笔记本电脑用的是买猫那个词尾 (https://zhangwenbao.com/minor-language-animacy-accusative-keyword-forms.html)那篇讲的宾格分叉，在平台侧就是这个字段里要不要多铺一行的问题。

## 复合词语言在平台搜索里会碎成什么样

德语这一侧的坏法不一样。

德语把一整个短语粘成一个词，用户搜的可能是整词，也可能是拆开的说法。

网页搜索能把长复合词拆成成分再匹配，平台侧多数不拆。

于是整词和拆开的写法在平台上是两个完全不相干的字符串。

两种都要覆盖，而两种加起来的字节数又要挤进同一个额度里。

德语卖家在这里被夹了两次：变音字母让每个词更贵，复合词让需要覆盖的写法更多。德语把一整个短语拼成一个词，关键词表为什么先塌了一半 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)那篇讲过整词与短语的搜索量分布，拿那份分布来定这个字段里留哪几条，比凭感觉删词靠谱得多。

## 判断自己踩没踩上的两个动作

不用等数据积累，两个动作当天就能做完。

第一个动作：拿你自己商品的一个核心词，换三种形态分别在平台搜索框里搜。

比如主格、复数、带一个常见格尾，看自己的商品在三次搜索里是不是都出现。

第二个动作：把一个长复合词拆成两个词搜一遍，再合起来搜一遍。

两次结果差得越远，说明这个平台的切词越硬，你要铺的形态就越多。

这两个动作有个好处：它不需要任何后台权限，任何人都能做，而且结论是可复现的。保哥通常让运营在立项会之前先做一遍，把两组截图摆出来，比讲十分钟原理有用。

还有第三个动作值得顺手做：在平台搜索框里输入你的核心词的前几个字符，看自动补全给出什么。这份补全列表是平台按真实查询频次生成的，它免费告诉你这门语言里用户最常用的搭配和形态。做小语种时这份列表的价值特别高，因为外部关键词工具在这些语言上多半没有数据，而这里的数据是平台自己的。

## 十个国家站点，标题该写成十份还是一份改十次？

## 平台的标题结构是被规定死的

平台对标题的要求跟网站完全不同。

网站的标题你想怎么写就怎么写，只要不堆砌。

平台会规定顺序：品牌在前，然后是产品线、型号、核心属性、规格与数量。

规定还包括长度上限、能不能用促销词、能不能用全大写、标点怎么用。

这些规则在各家平台的卖家中心里都有明文，写得相当细。

它们的共同前提是英语的语法习惯：修饰语在前、中心词在后、名词不变形、并列用逗号。eBay的标题最佳实践 (https://pages.ebay.com/seller-center/listing/create-effective-listings.html)是这类规则里写得比较清楚的一份，可以拿来当模板结构的参照。

这里要提醒一个容易混淆的地方：标题的长度上限和关键词字段的上限，计量单位未必一致。有的平台标题按字符算，关键词字段按字节算；有的两个都按字节。这两套口径混用会造成一个很别扭的现象——标题里塞得下的词，复制到关键词字段里就超了。开工前先在后台各试一次，用一个纯汉字或者纯假名的串去顶上限，看它在几个字的时候报错，就能反推出这个字段用的是哪套口径。

## 规定的顺序在有些语言里拼不出合法短语

把这个顺序原样搬到别的语言，问题立刻出来。

法语和西班牙语的形容词多数放在名词后面，硬按英语顺序排就是错的。

德语的属性词要跟名词的性别与格保持一致，堆在一起不改词尾就不成句。

日语的修饰关系靠助词表达，去掉助词只留名词串，读起来像电报。

而平台的字符预算又逼着你去掉一切不承载检索价值的成分，包括助词。

结果是一条在算法上很优的标题，在母语读者眼里像机器吐出来的。这是平台listing上最经典的一次两难：检索侧要词密度，转化侧要读得像人话，而字符预算只有一份。多数卖家的处理方式是全押检索侧，然后困惑于点击率为什么上不去。

展示这一侧还有一层截断要算。平台在搜索结果页和推荐位上显示的标题长度，跟你能填的长度不是一回事，移动端尤其短。同样的显示宽度下，汉字和假名比拉丁字母占更多像素，能显示的字符数更少；而德语这类长词语言又容易在一个词的中间被切断。所以标题的前十几个字符要能独立成立，把品牌加品类放在最前面，是所有语言下都成立的一条。

验证办法很土但有效：在手机上搜自己的核心词，把自己商品的标题截屏，看它在什么位置被截掉。多数卖家在电脑上写标题、在电脑上看效果，而绝大多数流量来自手机，两边的截断位置差出一截。

## 哪几段可以整块复用，哪几段必须重写

把标题拆成几段来看，答案就清楚了。

品牌名这一段可以整块复用，除非这个市场的用户用另一种写法找你。

型号与规格数字这一段基本可以复用，只要单位跟着换。

品类名这一段必须逐语言重写，而且不能靠翻译，要靠本地查询数据。

核心属性这一段最麻烦，它既要重写又要考虑形态，还要跟品类名的语法关系对上。

这份三档划分跟内容侧的复用判据是同一套逻辑，只是颗粒度更细。品牌名那一段的处理另有讲究，做小语种SEO，品牌名叫什么不由你定，由当地用户的输入法定 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)那篇给了几种写法的优先级排法，平台侧可以直接照用。

还有一种情形会打乱这套划分：一个站点内部就有两三门语言。比利时站同时服务荷兰语和法语用户，瑞士站涉及德语、法语、意大利语，加拿大站是英语和法语。这类站点上，你选的那一门语言只覆盖了一部分用户，另一部分用户搜的词你一个都没铺。判断办法是看这个站点的用户语言分布，而不是看它挂在哪个国家名下。

处理办法要看平台给不给你多语言字段。给的话按语言各填一份，不给的话就要在同一个字段里给两门语言的核心词各留位置，这时候字节预算被腰斩，取舍会非常痛。这也是为什么这几个市场的实际难度远高于它们的人口规模，很多卖家按人口排优先级时会严重低估它们。

## 型号与品牌那一段的特殊处理

型号这一段还有个平台独有的坑。

同一个型号在不同站点可能被平台自动附加不同的后缀。

用户搜型号的时候打的往往是不带后缀、不带空格、不带连字符的那一串。

而你标题里写的是带连字符的规范写法，两者在硬匹配下不是一个字符串。

解法是在关键词字段里把几种写法都铺一遍，标题里保留规范写法。

这条跟小语种关键词表里唯一一批全英文的词 (https://zhangwenbao.com/minor-language-acronym-initialism-local-forms-inflection.html)那篇讲的缩略语变体是同一族问题：非字母字符在不同系统里被当成词边界还是当成字符，决定了两个看起来一样的字符串能不能匹配上。

变体商品还有一层继承关系要注意。多数平台的变体是父子结构，父体上写一份主标题，子体各自带自己的属性值。搜索命中的往往是子体，而子体展示出来的标题是父体标题加上属性值拼出来的。于是父体标题里那些为了检索堆的词，会在每一个子体上重复一遍，把子体标题顶到上限之外被截断。正确做法是父体标题写得克制，把形态变体全部放到关键词字段，让拼接后的子体标题仍然读得通。

## 平台自动翻译你的商品页，那一版算谁写的？

## 平台会替你把商品信息翻到别的站点

这是很多卖家没意识到自己已经在承受的一件事。

大平台普遍提供跨站点的商品信息同步，同步过程中会自动翻译。

你在德国站上架一款商品，法国站和意大利站可能出现一个自动翻译的版本。

翻译引擎是平台自己的，用的多半是通用的机器翻译服务。

你没有主动做任何事，那几个站点上就多了几份署着你名字的文案。

平台自己的技术文档并不回避这件事，Amazon Translate的产品说明 (https://docs.aws.amazon.com/translate/latest/dg/what-is.html)里直接把电商内容本地化列为主要用途之一。这就是本节要问的那个问题：那一版到底算谁写的。

## 翻出来的那一版你既不容易改也不容易撤

接着往下就是控制权的问题。

自动翻译的版本通常可以被你上传的手工版本覆盖。

可覆盖是一条一条来的，几千个商品就是几千次操作。

在你覆盖之前，那一版一直挂着，一直在被用户读，也一直在被平台检索。

而品牌名、型号、专有属性被翻译引擎改掉的概率相当高。

这里跟本站另一篇讲的现象在机制上不同：那是搜索引擎在结果页替你翻译，用户看到的是翻译层，你的原始页面不受影响；平台这一版是直接落地成了正式商品页，它就是那个站点上的原文。两者的严重程度不在一个量级。

## 它跟你自己发机器翻译不是一回事

这里要跟一条老规矩划清界限。

指南里说的是不要把未经审校的机器翻译直接当成正式内容发布。

平台这一版恰好完全符合那个描述，只是发布者不是你。

结果却记在你头上：转化差是你的，用户投诉是你的，品牌印象也是你的。

机器翻译发上线省下的那道审校，最后是拿收录和排名分期还的 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)那篇算的是你自己发的账。

这里要补的是一个更别扭的版本：你没省那道工序，是别人替你省的，而账单还是寄给你。区别在于你连决定要不要省的机会都没有，只能在事后一条一条去覆盖。

## 该开还是该关，按品类分档

结论不是一律关掉，要分档。

低客单价、属性简单、描述短的品类可以开，自动翻译的错误面小，覆盖成本高于收益。

中高客单价、需要说明使用方式、有安全提示的品类应该关，或者只对头部商品先手工覆盖。

涉及成分、规格、认证、尺码的品类必须关，这几类翻错会直接变成售后和合规问题。

判断标准可以简化成一句：这个商品的文案里有没有一个数字或者一个词，翻错了会让用户买错。

有就关，没有就开。这条判据比按类目一刀切好用，因为同一个类目里也会同时有几十块钱的配件和几千块钱的主机，而它们承受错误的能力完全不同。

## 后台那个关键词字段，屈折语该填哪个形态？

## 这个字段的匹配规则跟正文不一样

先说清楚这个字段的性质，因为误解特别多。

它不对外展示，用户在页面上看不到它。

它参与检索，但权重通常低于标题。

它的匹配多数是词级别的，词与词之间的顺序不重要。

所以在这里堆词不构成堆砌，因为它本来就是为这个用途设计的。

理解这一点很关键：这是整个平台listing里唯一一处你可以放心铺形态的地方。别的位置铺形态会伤可读性，这里不会，因为没有读者。

## 变格语言要不要把形态铺满

铺，但要按优先级铺，因为字节预算摆在那儿。

第一优先是用户实际会打的那两三个形态，这个数据来自站内搜索日志和平台的搜索词报告。

第二优先是单复数各一个。

第三优先是不带变音符号的写法，因为它省字节又能接住一批懒得切键盘的查询。

剩下的格形态如果预算不够就砍掉，砍的顺序按平台搜索词报告里的实际出现频率。

这套优先级跟建关键词表的思路是一致的，区别是这里有一个硬约束在逼你排序。小语种关键词工具返回的那个零是数据缺口，不是需求缺口 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)那篇讲的补数办法，在平台侧有个更好的替代：平台自己的搜索词报告是这门语言里质量最高的一手数据，而且免费。

平台的搜索词报告里通常有三列值得盯：查询串本身、曝光量、以及这个查询带来的点击或者转化。做形态覆盖时要按第三列排序而不是第二列，因为高曝光低转化的形态往往是别人品类的词误撞进来的。按转化排出来的前二十个形态，基本就是这个字段里最该占位置的二十条。

另外这份报告要按站点分开导，不能合并看。同一门语言在两个站点的形态分布可以差很多，尤其是那些一门语言跨多国的市场。合并之后的排序会被大站点主导，小站点的独有形态直接被平均掉，而那些形态往往竞争更小。

还有一类形态值得单独留位置：用户实际打出来的错拼与省略写法。屈折语市场里，很多用户会打一个不完整的词干或者一个明显打错的形态，而这类查询在搜索词报告里往往量还不小。平台不做拼写纠错的话，这批查询你不铺就完全接不住。挑量最大的那几条放进字段，成本几个字节，收益是一批几乎没有竞争的流量。

## 变音符号打不打，字段里怎么办

这个问题在字段里跟在页面上不是同一个答案。

页面上应该写规范写法，带全变音符号，这是可读性和专业度的底线。

字段里两种都放，如果预算允许。

预算不允许时，先放用户实际打的那一种。

怎么知道用户实际打哪一种，看平台搜索词报告里两种写法的曝光分布。

这里有个反直觉的地方：越是移动端占比高的市场，不带符号的写法占比越高，因为在手机键盘上打变音符号要多按一次。这条规律在东欧和南欧市场尤其明显，而这两块恰好是平台增长最快的区域。

## 不要重复、不要品牌词这几条规矩背后的原因

平台对这个字段还有几条硬规矩，值得理解一下原因。

不要重复标题里已经有的词，因为系统会自动合并，重复只是浪费你自己的字节。

不要填别人的品牌词，这一条是法律层面的，不是优化层面的。

不要填品类里的常见违禁词或者绝对化用语，会触发审核。

前两条在多语言场景下都有额外的坑：同一个词在这个国家是通用品类词，在另一个国家是有效注册商标。

那个词每月几万次搜索，你查得到也知道意思，可它印在别人的商标证上 (https://zhangwenbao.com/minor-language-genericized-trademark-category-keyword.html)那篇讲的正是这条分裂，平台侧的处理更简单粗暴：踩了就是拒登，没有申辩空间，所以按站点分别维护一张状态表是唯一的办法。

去重这条规矩还有个执行细节值得确认：平台去的是完全相同的字符串，还是词级别的重复。如果是词级别，你在标题里写过的每一个词都不必在字段里重复；如果是字符串级别，同一个词换个形态仍然算新词。这个差别直接决定你能省下多少字节，而后台文档通常不写。测法是填一条与标题完全重复的词看它算不算长度，几分钟能试出来。

## 品类树是平台定的，你的词表怎么跟它对上？

## 平台的品类名是翻译过来的，不是本地长出来的

这一条是平台侧独有的现象，独立站上不存在。

平台的品类树通常有一套主干，各国站点的品类名是从主干翻过去的。

翻译得对不对是一回事，是不是当地人真的这么叫是另一回事。

结果经常是品类名很规范，用户搜的却是另一个更口语的说法。

你选品类的时候只能在平台给的名字里挑，可你铺关键词的时候要按用户的说法铺。

这就是小语种关键词表里那些没人搜的词，多半是当年拿词典逐词换出来的 (https://zhangwenbao.com/keyword-literal-translation-legacy-cost-non-english.html)那篇讲的直译问题，只是这次做直译的是平台，而你没有投票权。你能做的是不要把平台的品类名当成词表的种子，它只是一个归类工具。

## 属性枚举值那一层的老问题在平台上更硬

属性值这一层的矛盾在平台侧被放大了。

平台的属性是结构化的，颜色、尺寸、材质都有固定选项。

选项列表是平台定的，你只能选，不能加。

而不同语言对同一组属性的切分方式本来就不一样。

颜色是最典型的一组，某些语言里的两个基本颜色词在另一门语言里是一个词的两种说法。

你的色卡上蓝和绿是两格，120门语言的样本里只有30门这么分 (https://zhangwenbao.com/minor-language-color-category-attribute-value.html)那篇给的多对多映射表，在独立站上你可以自己实现，在平台上实现不了——你只能在选项里挑一个最接近的，然后把真正的那个词铺到关键词字段和标题里去救。

## 对不上的时候该改哪一边

遇到对不上，处理顺序有个固定答案。

第一，属性选项按平台的规则填，别硬凑，填错会影响筛选器里的曝光。

第二，用户真正在搜的那个词放进标题的核心属性段。

第三，剩下的说法全部丢进关键词字段。

第四，页面正文里用最自然的本地说法写一遍，让读的人觉得这是本地卖家写的。

这个顺序的逻辑是：结构化字段服从平台，自由文本服从用户。把两者搞反是新手最常见的错，表现为标题写得像属性表，属性表里塞满了关键词。

还有一个位置几乎所有卖家都在浪费：平台的富文本描述模块。这类模块做出来的内容视觉效果好，可它多数是整块图片，图片上烧着大量文字。那些文字对用户有用，对检索一个字都不算。同样一段卖点，写成图片是零，写成文本是可索引的段落。

折中的做法是图文各出一份：图片保留视觉表达，同时把关键卖点、参数、使用场景用纯文本再写一遍放在描述区。这一步在小语种站上的收益比在英语站上更高，因为小语种的商品页本来自有文本就少，图片一多整页几乎没有可读文本，语言证据也跟着薄。

属性映射这张表还需要一个复核节奏。平台会增删属性选项，也会调整品类树，改动之后你原来选的那个值可能被合并、被弃用，或者被静默映射到一个别的值上。半年一次的复核里要专门看一栏：有没有商品的属性值变成了空或者变成了其它。这一栏的变化在后台不会有任何提示，只能主动去查。

## 受限词与商标词那一层，平台按语言分别维护吗？

## 同一个词在两个站点的命运可能相反

答案是按站点分别维护，而且各站的口径不完全一致。

同一个词在德国站可能正常，在法国站可能触发审核。

原因既有法律的，也有平台自己的运营策略。

而这份清单平台通常不完整公开，你只能从被拒的记录里反推。

于是每一次拒登都是一次数据采集，值得记下来。

这一层跟内容侧的受限品类问题同源，那个词你不好意思写，用户也不好意思打，可你们绕开它的方式不一样 (https://zhangwenbao.com/minor-language-euphemism-restricted-category-keyword.html)那篇讲的是写页面的人和搜东西的人绕开的方向相反，平台侧要多加一层：平台自己也在绕，而且它绕的方向跟你们两边都不一样。

还有一条容易被忽略的不对称：平台的品牌保护机制通常按站点分别登记。你在一个站点做了品牌备案，另一个站点未必自动生效，而备案状态直接决定你能不能用某些词、能不能拦截别人用你的品牌词。多站点扩张时，把备案清单跟站点清单对一遍，是一次性的动作，漏了的代价是别的卖家可以在那个站点用你的品牌词做广告。

## 被拒登的那个词，可能正是用户在搜的词

最难受的情形是三者撞在一起。

用户在搜这个词，搜索词报告里明明白白。

你把它放进标题，商品被下架。

你把它放进关键词字段，审核照样拦。

唯一还能接住这批流量的位置，是商品的自由文本描述里一次自然的提及。

而自由文本的检索权重最低。这基本上就是一个死结，能做的只有承认这部分流量在这个站点上接不住，把预算挪到别的形态上去，而不是反复试探平台的规则边界。

## 建一张按站点的词状态表

落地物是一张表，结构很简单。

行是词，列是站点，格子里记三个状态：可用、仅描述、禁用。

再加一列记来源，是从平台文档来的还是从拒登记录反推的。

再加一列记复核时间，这类规则会变，半年一次的复核是必要的。

这张表跟内容侧的关键词表是两份东西，不要合并。

合并的诱惑很大，因为两份表里的词高度重叠。可它们的字段完全不同：内容侧的表关心搜索量和意图，平台侧的表关心能不能用。硬合并的结果通常是两边都不好用，最后谁也不维护。

反推平台清单还有一个更主动的做法：拿一批候选词做小批量上架测试，用低价或者临时的辅助商品去试，被拒的记下来，通过的确认可用。这个做法有成本也有风险，账号健康度要盯着，但它是唯一能把清单从被动记录变成主动探明的手段。适合在进入一个新站点之前集中做一轮，之后转为被动维护。

这张表还有一个被低估的用途：它是你和平台客服沟通时唯一有效的材料。申诉时给出词、站点、拒登时间、以及同一个词在别的站点正常上架的证据，比反复描述情况有用得多。没有这张表，每一次申诉都要从头收集材料。

## 评论跨国合并之后，页面上会变成几门语言？

## 评论合并带来的语言混杂

大平台普遍把同一商品在多个国家站点的评论合并展示。

这对新站点是好事，一上来就有社会证明。

代价是页面上会同时出现好几门语言的评论。

有些平台会给非本站语言的评论加一个自动翻译版本，有些直接展示原文。

无论哪种，页面上的语言纯度都下降了。

这一层跟卖家几乎没有关系，你既不能选择合并哪些，也不能删掉别人的评论。它是平台为了填充内容做的产品决策，而后果落在你的商品页上。

## 混杂对页面语言证据的影响

评论区在商品页上的文本占比往往超过一半。

当一半的文本来自五门语言，这一页到底算什么语言就变得模糊。

平台内部怎么判定我们看不到，可外部搜索引擎抓这类页面时会遇到同样的问题。

而平台的商品页在很多品类里是能拿到网页搜索排名的。

这就跟本站讲短文本语言判定的那条线接上了。

要补的是：商品页的语言证据本来就靠标题和描述这一点点自有文本撑着，评论一混，自有文本的占比进一步被稀释。这是把标题和描述写足本地语言的又一个理由，虽然它的收益不体现在平台内部的排名上。

## 能做和不能做的几件事

面对这件事，卖家的动作空间很小但不是零。

不能做的：控制合并范围、删除他国评论、改变展示顺序。

能做的第一件：把自有文本部分写足，让本站语言的字数占比尽量高。

能做的第二件：主动运营本站语言的评论，让最新的几条是本地语言的。

能做的第三件：商品问答区如果开放，用本地语言认真答，那部分文本是你能控制的。

第三件的性价比最高也最被忽略，因为问答区的文本通常排在评论前面，而且天然是问句形态，跟用户的实际查询很接近。

问答区还有一个技术性的好处：它的内容天然是问答对的形态，而这正是段落抽取最喜欢的结构。一个用本地语言写的问答对，被摘去当答案的概率明显高于同样内容写在描述段落里。所以如果只有精力做一件事，把问答区用本地语言认真答二十条，比重写整篇描述见效快。

## 平台的数据和独立站的词表，能不能共用一份？

## 两边真正能共用的是哪一层

先说结论：概念层共用，形态层不共用。

概念层指的是这门语言里这个东西叫什么，用户关心哪几个属性，有哪几种说法。

这一层是语言事实，两边完全一致，重复调研就是浪费钱。

形态层指的是具体填哪一个词形、铺几个变体、写不写变音符号。

这一层由检索侧的能力决定，而平台和网页搜索的能力差得很远，所以必须分开定。

把这条线画清楚能省掉很多无效争论。团队里经常有人说词表都调研过了平台直接用就行，也有人说平台和网站完全是两回事要重做一遍，两种说法各对一半。

数字与单位的写法也归形态层，而且经常被漏掉。同一个尺寸在几个市场分别写成公制、英制或者两者并列，小数点用点还是用逗号，容量单位写全称还是缩写，这些在标题和关键词字段里都是不同的字符串。用户按当地习惯搜，你按总部习惯写，两边就对不上。这一条不需要任何调研，看一眼那个市场竞品的标题就知道该写哪一种。

竞品标题是另一份免费的形态样本。挑这个品类在这个站点排前二十的商品，把标题全部导下来，统计里面出现的品类词形态与属性词写法。排在前面的未必是优化最好的，但它们至少证明了这些写法能被搜到。这份样本对刚进入一个语言市场、手上一条自有数据都没有的团队特别有用。

## 平台侧独有的数据反过来能喂给独立站

这条是很多人没想到的反向收益。

平台的搜索词报告给的是真实查询串和它们的表现，颗粒度比外部工具细得多。

更重要的是它覆盖了外部工具在小语种上根本没有数据的那一大片长尾。

这批数据拿回独立站，可以直接用来补词表、补站内搜索的同义词、补内容选题。

这是做平台的团队手里最值钱、也最常被浪费的一份资产。

浪费的原因通常是组织问题：平台团队和独立站团队不是同一批人，报表也不互通。而这份数据的迁移成本几乎为零，只需要有人定期导一次表。

## 一份两天能跑完的双向对齐流程

给一份具体的流程，两天能完。

第一天上午：导出平台各站点近三个月的搜索词报告，按站点分开。

第一天下午：跟独立站的关键词表做比对，标出三类词——两边都有的、只有平台有的、只有独立站有的。

第二天上午：只有平台有的那批，按量排序，挑头部补进独立站词表和站内搜索同义词。

第二天下午：只有独立站有的那批，检查是不是因为平台字段没铺形态才没有数据，按字节预算补进关键词字段。

跑完这一轮通常能在两边各捡到几十个词，而且这批词的共同特征是外部工具查不到——它们只在你自己的两份日志里存在。

第二天下午还要处理第三类：两边都有但表现差异极大的词。同一个词在独立站上转化好、在平台上几乎不出单，或者反过来。这类词通常暴露的是意图差异——平台用户更接近直接购买，独立站用户可能还在比较阶段。把这批词单独列出来，能直接指导两边的落地页该写成什么样。

这套流程建议在两个时点各跑一次：新站点开站三个月后，以及每年的大促之前。开站三个月是因为搜索词报告要攒够样本，大促之前是因为节庆相关的查询形态跟平时不一样，而那批词的字节预算要提前腾出来。平时不必频繁跑，这份数据的变化没有想象中快。

## 什么时候该承认这两套要分开维护

也有该分开的时候，三个信号。

第一个信号：两边的头部查询重合度低于三成，说明用户群和意图本来就不同。

第二个信号：平台侧的品类树跟你独立站的分类结构差异大到无法映射。

第三个信号：两边的团队规模都足够，各自有专人，合并反而增加沟通成本。

三个信号里满足两个，就该分开维护，只保留概念层的定期同步。

硬要合并的代价通常不是做错什么，而是两边都要等对方，谁也跑不快。这跟近亲语言市场要不要合并做是同一类判断题，只是这次分的不是语言，是渠道。

## 哪些属于平台算法层，本篇交出去

## 交给平台运营那一侧

有一整块内容跟本篇讲的挨着，但不归语言层管。

销量速度、转化率、库存表现、配送方式、广告投放与自然位的联动，这些是平台算法的权重问题。

算法迭代过好几代，各代的权重分布差异很大，这是另一条线上的功课。

亚马逊SEO：A9与A10算法关键变量完整对比 (https://zhangwenbao.com/amazon-a9-a10-algorithm-evolution-product-search.html)和亚马逊Listing排名7大权重因子 (https://zhangwenbao.com/amazon-listing-ranking.html)把这一层讲透了，本篇不重复。

本篇只处理一件事：当你的商品要在一门不是英语的语言下被搜到时，语言这一层会额外吃掉哪些东西。把这两条线分开的好处是，语言层的改动通常成本低、见效相对快，而权重层的改动往往要靠时间和销量堆。

## 交给独立站那一侧

反过来也有一批事不该套用平台的做法。

独立站的标题不必遵守平台的结构规定，可以写得更像人话。

独立站的属性枚举可以自己定，不受平台选项列表的限制。

独立站可以做多对多的映射表、可以做同义词、可以做词形归一，这些能力平台侧都给不了你。

应用商店那一侧的关键词字段又是另一套规则，ASO和网页SEO怎么融合 (https://zhangwenbao.com/aso-app-store-optimization-vs-web-seo-deep-link-mechanism.html)那篇讲过它的字符预算怎么花。

三个渠道的共同点只有一个：它们都用同一门语言面对同一批用户。差别在于每个渠道允许你做的语言处理深度完全不同，而这个深度决定了你要在数据里替它补多少。

## 常见问题解答

## 关键词字段到底该不该填满上限？

该填满，但填满的定义在多语言场景下要重新算。填满指的是把字节额度用完，不是把想到的词都塞进去。日语和韩语卖家因为每个字符吃三个字节，往往二十几个词就到顶了，这时候的关键动作不是硬塞，而是排序：先放用户实际会打的形态，再放单复数变体，最后放不带变音符号的省字节写法。另外别忘了标题里已有的词不用重复，那部分字节可以省下来给别的词。

## 我们只做一个国家的平台站点，这些还需要管吗？

需要，因为字节账和切词账跟你做几个站点无关，只跟你用哪门语言有关。一个只做日本站的卖家同样会撞上字段装不下的问题，一个只做波兰站的卖家同样要面对七个格的形态覆盖。反过来，只有平台自动翻译和评论跨国合并这两节是多站点才会遇到的。所以单站点卖家可以跳过第四节和第八节，其余六节一条都不能少。

## 平台的搜索词报告和外部关键词工具，该信哪个？

做平台就信搜索词报告，它记录的是这个平台内部的真实查询，而外部工具量的是网页搜索。两者在小语种上的差距特别大，因为平台用户的查询更短、更偏向商品词、几乎不带疑问句。外部工具唯一不可替代的用途是估算这门语言的整体需求盘子，用来判断值不值得进这个市场。一旦决定要做，日常优化的依据应该是平台自己的数据。

## 标题写得像人话和堆关键词，到底该偏哪一边？

按位置分工。标题的前半段决定点击，要写得像人话，核心品类词加一两个关键属性就够。标题的后半段可以放规格、数量、型号这些检索价值高但不影响阅读体验的成分。剩下所有形态变体全部丢进关键词字段。这个分工的前提是关键词字段真的被填满了，如果那个字段是空的，标题就会被迫承担全部检索任务，然后必然写成一串词。

## 平台自动翻译过去的商品页，会不会影响我的独立站排名？

直接影响很小，间接影响值得留意。直接影响小是因为它们在不同域名下，不构成站内重复。间接影响在于：如果那批自动翻译的页面在网页搜索里也能被抓到，那么同一门语言下描述你产品的文本就多了一批质量不受控的版本，用户搜品牌加型号时可能先看到那一版。品牌保护的角度值得把头部商品的手工版本优先覆盖掉，尤其是那些含成分、认证、尺码的品类。

## 评论里混着好几门语言，需要主动做点什么吗？

能做的三件事按性价比排：第一是把商品问答区用本地语言认真答一遍，那部分文本你能控制，而且天然是问句形态；第二是把自有的标题和描述写足，把本站语言的文本占比拉起来；第三是主动运营本站语言的新评论，让最上面几条是本地语言的。删掉他国评论、改变合并范围这些都做不到，别在这上面花时间试。

## 做平台和做独立站，语言层的功课能省一次吗？

概念层能省，形态层不能。这门语言里这个东西叫什么、用户关心哪几个属性、有几种常见说法，这些调研做一次两边都能用。具体填哪个词形、铺几个变体、要不要写变音符号，这一层必须分开定，因为平台搜索和网页搜索的语言处理能力差得远。粗略地说，调研可以共用，落地必须分开，而多数团队的做法恰好反过来——调研各做各的，落地却拿同一份词表照抄。

## 权威参考资料



## AI用你的语言把答案说得挺顺，底下挂的来源却是一水儿的英文页面

- URL：https://zhangwenbao.com/ai-search-language-bias-low-resource-citation-source-audit.html
- 分类：小语种SEO
- 发布：2025-07-15  |  更新：2026-07-27
- 摘要：问题用本语言提，答案也用本语言给，可底下挂的来源清一色是英文页面。讲清这种偏差是从检索池的形状里怎么长出来的、怎么用十种语言十个问题自己测一遍，以及它在哪类查询上无害、在哪类上直接给出错的答案。
- 关键词：AI搜索,出海SEO,多语言SEO,小语种SEO

> **TLDR**：摘要：问题用芬兰语提，答案也用芬兰语给，读着挺顺，可底下挂出来的来源清一色是英文页面。回答语言和来源语言是两个独立字段，绝大多数团队把它们当成了一个。这篇讲清这种偏差是怎么从检索池的形状里长出来的、怎么用十种语言十个问题在一个下午自己测一遍，以及为什么在某些查询类型上它无害、在另一些上它直接给出错的答案。

> 摘要：问题用芬兰语提，答案也用芬兰语给，读着挺顺，可底下挂出来的来源清一色是英文页面。回答语言和来源语言是两个独立字段，绝大多数团队把它们当成了一个。这篇讲清这种偏差是怎么从检索池的形状里长出来的、怎么用十种语言十个问题在一个下午自己测一遍，以及为什么在某些查询类型上它无害、在另一些上它直接给出错的答案。

## 回答用的是你的语言，引用的来源是哪门语言，你分开记过吗？

## 一个被顺手合并掉的字段

先描述现象，再说它为什么重要。

用芬兰语问一个关于露营炉具的问题，得到的是一段芬兰语回答。

翻到底下的来源清单，六条里五条是英文站。

你会本能地觉得没什么问题，毕竟答案是芬兰语的。

可这段芬兰语答案里的每一个事实，都来自那五个英文页面。

它不是用芬兰语的资料写的，它是把英语资料翻译着说给你听。

回答语言和来源语言是两个独立字段，把它们当成一个，是这个领域里最常见的观测错误。合并之后你会得出一个乐观得离谱的结论：这门语言已经被很好地支持了。实际情况是语言这一层被支持得不错，知识那一层根本没进来。前者是生成能力，后者是检索池的构成，两件事之间隔着一整套完全不同的工程。

顺手合并的还不止这一处。来源条数、来源新鲜度、来源类型，这几列也常被压缩成一句引用了几个来源。等到要分析为什么某个市场表现异常时，才发现手头的数据粒度根本不够，只能从头再采一遍。采集阶段多留两列的成本几乎为零，事后补采的成本是一整轮实测。

## 两个字段拆开之后能看到什么

拆开的动作很轻，收益很大。

建两列，一列记回答用的是哪门语言，一列记每条来源属于哪门语言。

跑二十条查询，两列的差异立刻显形。

英语查询里，两列基本一致。

德语查询里，来源语言那列开始混。

芬兰语、越南语、匈牙利语这一档，来源语言那列几乎全变成英语。

这条曲线的形状跟母语人口没关系，跟这门语言在网上有多少文档有关系。公开网络语料按语言统计的分布图 (https://commoncrawl.github.io/cc-crawl-statistics/plots/languages)可以直接看到这个形状：英语一家占掉将近一半，第二名往后掉得非常陡，排到第二十位的时候已经是百分之一的量级，再往后就是小数点后面的事了。检索池的形状就长这样，答案自然也长这样。

第一次拆开跑完，多数人的反应是同一句话：原来一直看的是另一件事。这种反应本身就说明这个字段值得拆——如果拆开之后两列高度一致，那说明合并没造成损失，五分钟就能验证完；一旦不一致，你之前所有基于合并数据得出的结论都要重新过一遍。

## 为什么大家只记回答语言

因为回答语言是看得见的，来源语言要点开才看得见。

而且回答语言是可以被产品公告承诺的，来源语言不能。

官方公告说支持40多种语言，说的是回答语言。

没有任何一份公告承诺过来源会用你那门语言。

这不是隐瞒，是这两件事本来就归不同的系统管。

但读公告的人会自动把它理解成全套支持。

今年五月那次扩到200多个国家、40多种语言的公告 (https://blog.google/products-and-platforms/products/search/ai-overview-expansion-may-2025-update/)就是个很好的例子。从半年多前的六门语言涨到40多门，这是实打实的进展，值得高兴。但它承诺的是你可以用这门语言提问并得到这门语言的回答，它没有、也没法承诺答案背后的资料是这门语言写的。这两句话的距离，就是本文要讲的全部内容。

还有一个更现实的原因：来源清单在界面上往往是折叠的，要多点一下才展开。观测行为跟界面设计强相关，凡是需要多一次点击才能看到的东西，长期来看就等于没人看。这不是懒，是注意力的自然分配，只能靠把它写进固定的记录表来对抗。

## 第三个字段：来源属于哪个国家

拆到两个字段还不够，第三个字段能省掉很多误判。

来源语言是英语，来源国家可能是美国、英国，也可能是印度或者新加坡。

对一个卖露营装备的德国站来说，这三种情况的严重程度不一样。

英美来源讲的规格标准跟欧盟不一样。

但如果来源是一家德国站的英文版页面，事实其实是对的。

只看语言这一列，你会把后面这种情况误判成问题。

所以完整的记录是三列：回答语言、来源语言、来源域名归属。第三列不用记国家名，记域名就够，反正后面要按域名去归类。这个三列结构跟上一篇里国家坐标和语言坐标要分开建字段的做法 (https://zhangwenbao.com/ai-overviews-100-countries-six-languages-minor-language-citation.html)是同一个思路的延伸：那边拆的是产品覆盖，这边拆的是来源构成，共同点都是别让两个不同量纲的东西共用一列。

域名这一列建议原样记录，别提前归类。你以为的分类标准在跑完两轮之后大概率要改，而原始域名可以随时重新归类，归类结果覆盖不掉原始数据。这条是做任何手工采集时的通用纪律：采集记原子事实，归类留到分析阶段。

## 语言偏差到底是模型的偏见，还是检索池的形状？

## 检索池里各语言的文档量差多少

先把量级说清楚，很多争论到这里就结束了。

公开网络语料里，英语的占比长期在四成到五成之间。

排第二的语言通常在百分之五到六。

掉到第十位，大约是百分之一到二。

掉到第三十位，已经是千分之几。

而全世界有几千门语言。

这不是一条平缓下降的曲线，是一条摔下来的曲线。要感受这个落差，可以拿两个数字对比：英语文档的数量级和芬兰语文档的数量级之间，差着两个甚至三个零。检索系统在这样一个池子里挑最相关的几篇，挑出英语的概率天然就高——不是因为它偏爱英语，是因为符合条件的候选里英语文档本来就多得多。这类开放网络语料库 (https://commoncrawl.org/)的原始统计每个月都在更新，各语言的相对位置这些年几乎没变过。

这条曲线还有一个不太直观的性质：它在中段特别陡。前十门语言之间的差距是几倍，第十到第三十之间的差距就变成几十倍了。所以一门语言从第三十位挪到第二十位，感知上的改善会比从第十位挪到第五位大得多——大多数需要争取的语种，恰好都在这段最陡的坡上。

## 偏差到底在哪一步产生

把链路拆开看，一共有三处可能产生偏差。

第一处是语料构成，各语言文档量本身就不平衡。

第二处是检索环节，检索器倾向于挑哪一门语言的文档。

第三处是生成环节，模型拿到多语言资料后更信哪一份。

三处会叠加，也会互相抵消，所以只测最终结果会看不清病灶。

研究这件事的论文最近两年多了起来。一份专门研究多语言检索增强系统语言偏好的工作 (https://arxiv.org/abs/2502.11175)把这三步拆开测过，结论里有一条特别值得记住：偏差在低资源语言上会被放大，也就是说越是本语言文档少的语种，最终引用到本语言来源的概率下降得越快，两者不是线性关系。这跟直觉一致，但直觉给不出量级，论文给得出。

三处偏差里，能被你影响的只有第一处。检索器怎么挑、生成时更信谁，这两处你改不动；而语料构成这一处，在你的品类、你的语言这个交叉格子里，一家公司的产出确实能占到可观的比例。所以诊断要三处都看，动手只在第一处。

## 说成偏见会让你做错动作

用词很重要，这一节讲的是它怎么影响决策。

说成偏见，动作就变成了投诉、等待修复、写公关稿。

说成检索池形状，动作就变成了往池子里放东西。

后一种描述准确得多，也可执行得多。

因为池子的形状你确实能改一点点，尤其是在你这个品类里。

一个语种的整体语料你改不动，一个语种在某个细分品类下的语料，你一家就能改动可观的比例。

凡是能把一个抽象归因换成一个可施工的对象，就该换。偏见是别人的属性，池子是可以往里放东西的容器。同一件事的两种说法，导出的行动完全不同——而在小语种这个场景里，第二种说法还额外附带一个好消息：你要竞争的那个池子，小到你有可能真的把它填满一角。

用词还会影响预算能不能批下来。带着偏见两个字的方案，读起来像一次维权；带着补齐本语言内容供给的方案，读起来像一次常规的内容投入。同一件事，后一种说法在预算会上活下来的概率高得多，而它还更准确。

## 低资源语言里，来源语言的分布长什么样？

## 高资源语言：本语言来源占多数

从好的那一端开始看。

德语、日语、西班牙语这一档，本语言来源通常能占到多数。

混进来的英语来源多半是官方文档、标准条文、厂商页面。

这一档的问题不是缺来源，是来源质量参差。

你要抢的是位置，不是填空。

打法跟英语市场差别不大，可以直接搬那套经验。

需要留意的是这一档内部也有分化：同样是高资源语言，商业内容丰富的品类和冷门品类完全是两回事。日语的美妆护肤内容多到挑花眼，日语的专业露营装备内容就稀疏得多。资源丰度是语言和品类的交叉属性，不是语言的属性，这条在问答长尾那篇 (https://zhangwenbao.com/minor-language-qa-long-tail-content-value-ai-era.html)里已经说过一次，在来源分布上同样成立。

这一档还有一个容易被忽略的机会：本语言来源虽然多，但其中相当一部分是论坛贴、问答站、聚合页。真正由品牌方写的、结构清晰的正面回答仍然稀缺。所以位置多不代表位置满，挑那些目前由用户生成内容占据的问题去做，是这一档里最省力的一条路。

## 中等资源语言：一半一半的拉锯

中间这一档最有意思，也最值得投入。

波兰语、越南语、印尼语、土耳其语大致在这一档。

本语言来源和英语来源大约各占一半。

而且这个比例在不同查询上摆动得厉害。

通用问题偏本语言，专业问题偏英语。

意味着边界是活的，你的内容能把它推动一格。

这一档是投入产出比最高的，原因很实际：本语言里已经有一定的内容基础，说明这门语言的商业写作是成立的、受众是有阅读习惯的；同时缺口又足够大，你补进去的东西能改变分布。太高的那一档你只是众多候选之一，太低的那一档你可能是在一个还没有阅读习惯的语言里自说自话。

判断自己属于哪一档不要凭感觉，用一个外部参照对一下。按国家整理的数字生态年度报告 (https://datareportal.com/reports/digital-2024-indonesia)里有网民规模、语言使用、平台渗透几组基础数据，跟你实测出来的来源分布放在一起看，能很快判断出这个市场是内容供给不足还是用户根本不在这门语言上活动。

## 低资源语言：本语言来源接近消失

最后看最陡的那一端。

斯瓦希里语、豪萨语、蒙古语、老挝语这一类。

来源清单里能出现一条本语言页面就算稀奇。

绝大多数情况下是英语来源，偶尔混一条邻近大语种的。

回答依然会用本语言给出，读着还挺流利。

所以这一档的风险不是没有答案，是有一个看起来完整的答案。

这里跟另一件事接上了：本语言里找不到资料的时候，本地规则那一类事实会被英语世界的默认值补上，语法正确、语气自然、内容不对。低资源语言幻觉率那篇 (https://zhangwenbao.com/low-resource-language-ai-hallucination-rate-content-risk.html)把这类错误拆成了四种形态，读起来会觉得眼熟——本文测的是来源那一侧，那篇测的是结果那一侧，其实是同一条链路的两端。一份面向文化敏感任务的跨语言稳健性基准 (https://arxiv.org/abs/2410.01171)就是奔着这个缺口去的，它测的正是当问题涉及本地文化与本地规则时，跨语言检索会失准到什么程度。

## 怎么自己跑一次引用来源实测？

## 十种语言十个问题的最小可行设计

不需要预算，不需要工具，一个下午。

选十门语言，覆盖高中低三档，别全挑自己熟的。

选十个问题，同一件事翻成十种语言问。

问题要具体到有唯一答案，别问哪个牌子好。

比如某种材质能不能机洗、某类燃料能不能托运。

一百次查询，两个人分头做，半天能跑完。

关键在于同一个问题跨十种语言问，而不是每种语言问不同的问题。只有问题相同，语言这一个变量才是干净的；否则你分不清差异来自语言还是来自问题难度。这条听着像常识，但实际操作时非常容易破功——翻译过程中总有人顺手把问题改得更符合当地习惯，改完这批数据就没法横向比了。

选语言的时候有个现成的参照可用：低资源机器翻译评测基准FLoRes的语言清单 (https://github.com/facebookresearch/flores)覆盖了两百门语言，按资源丰度排布得很均匀，直接从里面挑三档各三四门，比自己拍脑袋挑要均衡得多。挑完记得留一门英语当参照系。

## 每次记录哪三个字段

字段设计决定这份数据一年后还能不能用。

第一个字段：回答用的是哪门语言。

第二个字段：每条来源分别是哪门语言。

第三个字段：每条来源的域名。

另外记两个辅助项，查询日期和来源条数。

不记评分，不记主观判断，不记你觉得答对没答对。

主观判断留到分析阶段再做，采集阶段只记客观事实。这一点在多人协作时尤其要守，因为不同的人对答得好不好的标准不一样，而对这是不是英文页面的判断完全一致。母语审校那篇 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)里那条老经验在这里同样适用：把需要判断的动作拆成一个谁都能执行的动作，这份工作才能规模化。

再补一条实操细节：来源语言不要靠肉眼判断域名后缀。一个 .de域名上完全可能是英文内容，一个 .com上也可能是德语内容。判断依据必须是页面正文的语言，域名归属是另一列的事，两者混起来记会污染整份数据。

## 什么时候需要加对照组

大多数情况下不用，有两种情况必须加。

第一种是你想证明某个改动起了作用。

那就必须留一组不改的语言或不改的问题当对照。

第二种是你怀疑结果受地理位置影响。

那就在两个不同的网络环境下各跑一遍。

没有对照组的实测只能描述现状，不能归因。

对照组的选法有个坑要避开：别挑表现最好和最差的那两组当对照，挑中间的。极端组的波动本来就大，用它们做对照，你会把噪音读成效果。这跟做A/B测试时不能挑极端样本是同一个道理，只是在这种小样本的手工实测里更容易犯。

还有一种情况值得加对照：怀疑结果受账号历史影响时。同一个问题在两台从未用过的设备上各问一次，如果结果差异明显，说明个性化因素在起作用，那么你之前所有的单人实测数据都要打个折扣看。这个检查一次就够，做完心里有数。

## 一次完整实测大概要花多久

给个能写进排期表的数字。

第一次做，含设计和翻译问题，两个人两天。

之后每次重跑，两个人半天。

整理和出图，再半天。

建议的频率是每季度一次，别每周做。

因为这个分布变化很慢，测太密只会看到噪音。

一年四次，两年八个数据点，这条曲线的形状就出来了，比任何单次快照都有价值。做这件事最难的其实不是执行，是坚持——它的产出要到第三第四次才显现。保哥的做法是把它挂进季度例行事项，跟财报周期对齐，谁都不用记得，到日子自然会跑。

为什么第一次这么贵，因为贵在设计而不是执行。问题选得好不好、翻译准不准、字段定得全不全，这些一次性成本决定了后面八次重跑的质量。所以第一次做的时候值得慢一点，多花的那一天会在后面两年里连本带利收回来。

## 偏差的方向会不会随着查询类型翻转？

## 事实型查询：用英语来源没什么问题

先说无害的那一类，免得把话说得太满。

物理常识、材料属性、通用原理，这类事实不分国界。

某种面料的透气原理，用英语资料和用芬兰语资料，答案一样。

这时候来源是英语反而是好事，因为英语资料更全、更新更快。

用户拿到的是本语言的表达加上更好的信息。

这一类查询上，语言偏差是个纯粹的好消息。

所以别一看到来源全是英文就报警。先问一句这个问题的答案会不会随国家变，不变的那些，来源是哪门语言都无所谓。把这一类先筛掉，剩下的清单会短很多，也更容易说服团队投入——一份三十条的高危清单，比一份三百条的全量清单有用得多。

识别这一类有个很省事的判据：把问题里的国家名换掉，答案会不会变。不变的就是跨国一致的事实，来源用哪门语言都行；一换国家答案就得改的，就是下一节要说的那一类。这个判据不需要任何专业知识，一个实习生拿着问题清单半天能筛完。

## 本地规则型查询：用英语来源就是错的

这一类是本文真正想说的重点。

退货期限、税费口径、尺码对照、安全标准、保修条款。

这些答案在每个国家都不一样，而且差异是硬性的。

用英语来源回答一个德国用户的退货问题，多半会给出美式口径。

读着完全通顺，格式完全正确，结论完全不对。

用户照着做，第十五天来退货，你这边只能拒绝。

这类错误的特殊之处在于它有法律和售后的实体后果，而不只是体验差一点。欧盟消费者权益指令给出的撤回期是14天，德国民法典里对应的条文写得更细，撤回权那一条 (https://www.gesetze-im-internet.de/bgb/__355.html)和欧盟层面的消费者权益指令说明页 (https://ec.europa.eu/info/law/law-topic/consumer-protection-law/consumer-contract-law/consumer-rights-directive_en)放在一起，就是这个市场的标准答案。如果本语言里没有一个页面把它写清楚，那这道题就只能由英语来源来答。

还有一类容易被漏掉的本地规则：平台侧的规则。同一个品牌在不同国家的官方渠道、授权状态、保修受理点都不一样，而这些信息只在本地页面上写着。用英语来源回答，用户会得到一个在别的国家成立的答案，然后拿着它去找一个不存在的服务点。

## 品类比较型查询：错得最隐蔽

第三类夹在中间，也最难发现。

哪种材质更适合、哪个规格更常用、大家一般选哪个。

这类问题的答案跟当地的气候、习惯、渠道结构都有关。

英语来源给的是英美市场的常见选择。

它不违法，也不算事实错误，就是不适合本地。

而用户和你都很难指出它到底错在哪儿。

举个具体的：北欧市场露营用的季节划分和睡袋温标习惯，跟北美的表述体系不完全对齐。英语来源给出的建议，套到芬兰的夏天不能说错，但那不是当地人会给的建议。这一类的危害不在于给出错误答案，而在于它悄悄地把另一个市场的常识安装成了本地常识。三类查询里，第一类可以放着不管，第二类必须守，第三类值得慢慢补——优先级就是这么排的。

识别这一类的办法只有一个：让本地人读。把答案给本地同事看，问一句这是这儿的人会给的建议吗。他们通常答得很快，也说得出哪儿不对劲。搜索意图分叉那篇 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)讲过一个相关的现象：同一个词在两个市场问的根本不是一件事，比较型查询正是这种分叉最集中的地方。

## 为什么本地规则型查询是最该守的那一类？

## 本语言里没人写，答案就会被默认值填上

这是一条几乎没有例外的规律。

模型不会因为找不到本地资料就说不知道。

它会用手头最相关的资料回答，那多半是英语的。

沉默不是一个选项，空白一定会被填。

你不写，就等于同意由别的市场的规则来代表你的市场。

这个替换过程没有任何提示，用户看不到，你也看不到。

换个角度说，本地规则型内容的价值不只是被引用，还包括挤掉一个本来会出现的错误答案。这一点在算投入产出时经常被漏掉：你写了这一页，收益不只是可能拿到的那点流量，还有本来会发生、现在不会发生的那批售后纠纷。后面这笔账通常更大，只是它记在客服的账本上，不记在你的。

这一步在研究里也有对应的观察。一份关于多语言上下文利用一致性的工作 (https://arxiv.org/abs/2504.00597)发现，当检索到的资料语言跟提问语言不一致时，生成结果的稳定性会下降；而资料语言混杂时，下降得更明显。翻译成实务语言就是：本语言资料缺位的代价，不只是内容不对，还包括结果忽好忽坏。

## 这类查询的转化位置最靠后

还有一个被低估的理由，跟漏斗位置有关。

问退货期限的人，多半已经在考虑下单了。

问能不能托运的人，行程已经定了。

问尺码对照的人，商品已经选好了。

这些不是了解阶段的问题，是临门一脚的问题。

被一个错误答案劝退的用户，是最贵的那一批。

所以本地规则型内容在传统的关键词价值评估里总是排得很靠后——搜索量低、商业意图看起来不强、竞价成本低。但按漏斗位置看它排得很靠前。这两种排序方式的冲突由来已久，在落地页信任元素那篇 (https://zhangwenbao.com/minor-language-landing-page-trust-signals-payment-address-support.html)里也遇到过一次：最像装饰的那几项，恰恰是搜索量最高的购买词。

顺着漏斗位置还能推出一条排序原则：越靠近下单的问题，答错的单次代价越高，值得投入的绝对金额也越高。了解阶段答错一句，用户多看两篇；下单前答错一句，这一单没了，还可能附带一次差评。按这个口径重排选题清单，排出来的顺序跟按搜索量排完全不同。

## 守住它的成本比想象中低

好消息在这里。

本地规则型内容的数量是有限的，而且相当稳定。

一个品类下把这类问题穷举出来，通常也就三五十条。

写完之后除非法规变动，几年不用大改。

这跟需要持续更新的品类内容完全是两种维护成本。

一次性投入，长期占位，性价比高得不像话。

穷举的方法也很土：翻三个月的客服工单，把重复出现的问题按频次排下来，前五十条就是清单。这批问题的原始问法还有额外价值，它们是真实用户的措辞，比任何关键词工具给的词形都准。关键词工具没数据那篇 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)把这类土办法整理成了三条，都可以直接搬过来用。

还有个省力的做法：这批内容天然适合做成一页多答的形式，一个页面把同一类规则问题一次讲完，而不是拆成三十个薄页面。这样既方便维护，也更容易被整段引用。法规变动的时候，改一页就够了，不用去找散落在三十个地方的表述。

## 语言偏差会不会自己好转？

## 语料增长的速度跟语言不成比例

先看最基础的那条曲线。

网络内容的总量一直在涨，各语言都在涨。

但涨幅不均匀，英语的绝对增量仍然最大。

比例上的差距可能缩小，绝对差距还在拉开。

而检索是在绝对量上挑候选，不是按比例分配名额。

所以比例改善不必然带来引用位改善。

这条要说清楚，因为它推翻了一个常见的乐观预期：等语料涨上来就好了。只要检索是从全池子里挑最相关的几篇，那么决定结果的是你这门语言在这个具体话题下的绝对文档量，而不是它在总量里的占比。一门语言整体占比从百分之一涨到百分之二，在某个细分品类下可能还是零篇——而零篇和两篇之间的差别，比百分之一和百分之二的差别大得多。

还有一层容易被忽略：新增语料未必进得了检索池。网络上新增的本语言内容里，相当比例是社交平台上的短内容，结构、稳定性、可抓取性都不适合当来源。算语料增长要算可被引用的那部分，不是算总量，两者的增长速度可以差很远。

## 翻译内容会不会补上这个缺口

这是个好问题，答案是部分会，但要付代价。

翻译内容确实在往池子里填东西。

填进去的东西也确实能被检索到、被引用。

问题在于翻译内容携带着源语言的默认值。

用英语原文翻出来的德语页面，讲的还是英美的规则。

池子看着满了，本地事实的缺口一点没补上。

这件事的规模比多数人想象的大。一份关于网络上机器翻译内容占比的研究 (https://arxiv.org/abs/2401.05749)给出的结论相当刺眼：低资源语言的网络内容里，机翻内容的占比高得离谱，而且大量内容是从同一批源文本翻出来的多语言平行版本。也就是说池子里那些看起来是本语言的文档，有相当一部分只是同一份英语内容的影子。这个话题值得单独展开，本文先按下。

还有一种情况更麻烦：翻译内容之间是互相同源的。同一份英语原文被十家站翻成十种语言，池子里看着有十份不同语言的文档，实际上是同一个信息源的十个影子。这时候如果原文里有一处本地事实是错的，这个错会以十种语言同时出现，看起来像多方共识。

## 什么信号能说明它在好转

给三个可以自己观测的信号。

第一个：同一批问题里，本语言来源的条数在涨。

第二个：本语言来源里，本地域名的比例在涨。

第三个：本地规则型问题的答案开始引用本地权威源。

三个信号里第三个最迟出现，也最有价值。

只看第一个会被翻译内容骗到。

把这三个信号做成三条线画在同一张图上，季度更新，两年之后你会得到这个语种最有说服力的一份内部材料。它的价值不在于漂亮，在于当有人问为什么要在这门语言上继续投入时，你手里有一条实测出来的趋势线，而不是一段推测。

还有一个来自供给侧的观测点：本语言的公开语料数据集有没有在增长。按语言切分的开放语料项目 (https://oscar-project.org/)会定期发布各语言的规模，虽然它跟检索池不完全等价，但作为一个方向性的信号足够用了——语料侧没动静，检索侧基本不会先动。

## 这套实测结果该怎么变成内容排期？

## 按本语言来源占比分三档

分档是为了让动作能被批准，不是为了分类学。

本语言来源占比超过六成，划进第一档。

三成到六成之间，划进第二档。

低于三成，划进第三档。

阈值可以按自己的数据调，但档位数别超过三个。

档位一多，每一档对应的动作就会开始重叠，分档就失去意义了。

这套分档跟按母语人口或者按市场规模的分档会给出完全不同的排序，这正是它的价值所在。一个人口不大的市场可能落在第三档，说明那里几乎没人在用本语言写这个品类的内容；而一个人口很大的市场可能落在第一档，说明那里的内容供给已经很充分、你进去要硬碰硬。语种优先级成本模型那篇 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)算的是投入侧的账，这份分档算的是竞争侧的账，两张表叠起来看才完整。

阈值定完要写下来并冻结一年。这类分档最怕的是每次实测都顺手调一次阈值，调到最后档位反映的是当次心情而不是市场状态。真觉得阈值不合适，就在下一个年度周期改，并且把改动前后的数据都按两套阈值各算一遍，让曲线可以接上。

## 每一档对应的动作不一样

三档三套动作，写清楚才好排期。

第一档：抢位置，打法跟高竞争市场一样，靠质量和权威度。

第二档：补缺口，找那批本语言还没人正面回答的问题。

第三档：先建地基，本地规则型内容全量补齐再谈其他。

三档的共同动作只有一个：本地事实必须由本语言页面提供。

其余的动作完全不通用，别写成一套通用清单。

第三档还有一个隐藏动作容易被漏掉：确认这门语言的用户是不是真的在用这门语言搜索。有些低资源语言市场的用户习惯直接用大语种提问，这时候你在本语言上砸内容，砸的是一个没人站的位置。这个判断只要看一眼当地的搜索行为分布就能做出来，成本极低，但漏掉它的代价是整个季度的投入打水漂。

三档之间还有一条通用的先后顺序：先补本地事实，再补比较型内容，最后才是品牌故事这类软性内容。这个顺序在第三档市场里尤其重要，因为那里的用户第一次遇到你的时候，需要的是一个能回答具体问题的页面，而不是一段品牌自述。

## 排期表上先动哪一格

给一个可以直接照抄的顺序。

先动第三档市场里的本地规则型内容。

因为那一格的缺口最大、竞争最少、错误后果最重。

再动第二档市场里的缺口型问题。

第一档市场排在最后，那里的边际收益最低。

这个顺序跟按市场规模排序几乎是反的，所以要准备好解释。

解释的时候最好带上一句量化的话：在第一档市场里你的一篇内容是几十个候选里的一个，在第三档市场里你的一篇内容可能是唯一一个。同样一篇的成本，兑换出来的份额差着一个数量级。这句话在预算会上比任何漏斗图都管用。

还有一个排期上的技巧：把三档市场的同类内容合并成一个批次做。三十条本地规则型问题在五个市场都要写，那就一次性把框架定好，五个市场并行推进，而不是做完一个市场再做下一个。框架复用能省掉大半的策划成本，真正需要逐市场重做的只有事实核对那一步。

## 报表和汇报口径要怎么改？

## 来源语言要进周报

改动很小，位置很重要。

周报里加一行：本周抽测的本语言来源占比。

不用每周跑全量，抽十条查询就够。

重点是让这个数字在团队视野里长期存在。

一个不在报表里的指标，等于不存在。

而这个指标一旦每周出现，相关的讨论会自动发生。

抽测的十条查询要固定，别每周换。固定样本的绝对值可能不准，但它的变化趋势是准的；每周换样本的话，绝对值和趋势就都不准了。这条在所有低频抽样的监测里都成立，也是最容易被好心人破坏的一条——总有人觉得该换一批更有代表性的词。

周报里的呈现形式也讲究：写一个百分比，后面跟上上周的数字和箭头，不要写一段文字描述。数字加箭头能被扫读，一段描述会被跳过。这个指标存在的意义就是每周被扫到一眼，形式上多费一分心思，长期效果差别很大。

## 别把它做成一个考核指标

这一节是防御性的，但很有必要。

这个数字一旦进了考核，就会被优化。

而优化它最快的办法是换一批容易命中的查询。

数字漂亮了，你对真实情况的了解反而更差了。

它应该是一个诊断指标，不是一个业绩指标。

两者的区别在于：诊断指标用来决定做什么，业绩指标用来决定谁拿奖金。

把诊断指标写进考核，是很多监测体系失效的根因。凡是采集方式掌握在被考核者手里的指标，都不能用来考核。这条规则朴素得有点无趣，但它能救下一整套监测体系。这个数字最好的归属是放在诊断看板上，让它安静地涨或者跌。

怎么区分诊断指标和业绩指标，有个简单的判据：这个数字变差的时候，团队的第一反应是想去查原因，还是想去解释。想查原因的是诊断指标，想解释的已经变成业绩指标了。一旦观察到第二种反应，就该把它从考核里撤出来。

## 跟母语团队怎么讲这件事

最后是沟通问题，处理不好会伤士气。

本语言来源占比低，听起来像在说本地团队没做好。

实际上它衡量的是整个语种的内容供给，跟单个团队的努力关系不大。

讲的时候要把这层说清楚，否则会引发不必要的防御。

更好的说法是把它讲成机会：这门语言里几乎没人在正面回答这批问题。

同一个数字，一种说法是指责，另一种说法是空场。

另外记得给本地团队看那份实测原始数据，不要只给结论。他们看到来源清单里全是英文域名，会立刻理解发生了什么，甚至能补充你没注意到的细节——比如某个英文来源其实是本国某家公司的官网英文版。这种细节只有本地人一眼能认出来。

还有一句话在沟通时很好用：这个数字衡量的是这门语言，不是衡量你。把观测对象说清楚，防御心理会消掉大半。反过来，如果一开始就把它挂在某个人的名下，后面所有的数据采集都会不自觉地朝好看的方向偏，而你自己都察觉不到。

## 哪些做法看着合理，其实没什么用？

## 把内容翻译成英语再发一份

这是最常被提出的方案，逻辑听起来很顺。

既然引用的都是英语来源，那我也出一份英语的。

问题是你出的这份英语内容要跟整个英语世界竞争。

在本语言里你可能是唯一一家，在英语里你是第几十家。

把稀缺的优势主动换成了拥挤的劣势。

而且用户问的是本语言问题，本语言那一侧仍然空着。

这个方案唯一说得通的场景，是你的本地权威身份能在英语内容里被识别出来——比如一家本地检测机构、一个行业协会、一个只有你有数据的品类。如果你的优势来自本地身份，那这份优势在英语内容里会被稀释；如果你的优势来自独家数据，那它跨语言不会丢。先判断自己属于哪一种，再决定要不要出英语版。

还有一个折中方案值得考虑：不做全站英语版，只把那批独家数据、检测报告、原始调研做成英语版。这些内容跨语言不掉价，而且天然带引用属性。小语种外链那篇 (https://zhangwenbao.com/minor-language-link-building-local-directories-media-communities.html)里讲的本地渠道逻辑在这里同样成立：让本地权威在本语言里认你，让独家数据在英语里被引用，两条线各走各的。

## 在页面上加一堆语言声明

技术派最容易走的一条弯路。

加语言标签、加地区标注、加各种声明。

这些该做，做了也确实有用，但它解决的是另一个问题。

语言标注解决的是这份内容属于哪门语言。

本文讲的问题是这门语言里根本没有足够的内容。

标注得再清楚，也变不出内容来。

打个比方，这就像在一间空屋子里认真地贴门牌号。门牌该贴，贴完屋子还是空的。这类技术动作的价值在于让已有的内容被正确归类，属于结构化数据那一层的事 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)，跟内容供给是两条并行的线，谁也替代不了谁。

标注这件事本身要做对也有讲究。语言标签建议写成完整形式，IANA语言子标签注册表 (https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry)里能查到规范写法，pt-BR和pt-PT分开写，别图省事只写pt。这跟内容供给是两条并行的线，但既然要做，就别做半截。

## 盯着单次结果反复调

这条是执行层面最耗人的坑。

今天测一次，来源全是英文，改一段内容。

明天再测，还是英文，再改一段。

第三天变成本语言了，于是认定第二次的改动起了作用。

实际上单次结果的波动本来就很大。

你归因的那个改动，可能跟结果毫无关系。

正确的做法是拉长观测窗口，用一批查询的分布去看，而不是用单条查询的结果去看。在一个波动大的系统里，单次观测的信息量接近于零，而人对单次观测的信服度接近于百分之百，这两者之间的落差是无数个白忙活的下午。

还有一种变体同样耗人：换一个模型或者换一个入口再试一次，看到不同结果就认为发现了规律。不同入口的检索策略本来就不同，跨入口对比单次结果得出的任何结论都不成立。要比就比分布，而且要在同一入口下比。

## 拿英语市场的经验值当基线

最后一条，也是最隐蔽的一条。

英语市场里被引用的页面通常具备哪些特征，这类经验很多。

问题是那些经验是在一个候选极其充裕的池子里总结出来的。

在候选稀缺的池子里，很多筛选条件根本没被触发过。

你按英语的高标准去打磨，可能打磨的是一个不构成瓶颈的维度。

而真正的瓶颈可能只是这门语言里没有一个页面正面回答过这个问题。

这一条跟前面几条串起来，正好是本文的收尾：语言偏差最实际的一层含义不是你被歧视了，而是你的竞争环境跟英语市场根本不是同一个形状。形状不同，经验值就不能直接搬。先把自己那门语言的形状测出来，再决定抄哪一份经验——这个顺序反过来做，投入再多也是在解一道别人的题。

更稳妥的做法是同时跑一组英语查询当参照系。你那门语言的数据单看没有意义，跟同一批问题的英语结果并排放，才知道差距在哪一维、有多大。这组英语参照的成本很低，就是十条查询，但它把一份描述性数据变成了一份可比较的数据。

## 常见问题解答

## 回答是我的语言，来源却是英文页面，这算不算正常？

算常见，但要分情况判断。回答语言由生成环节决定，来源语言由检索环节决定，两者本来就归不同的机制管，不一致并不异常。判断标准是问题类型：如果是物理常识、材料属性这类跨国一致的事实，来源是英语反而更好；如果是退货期限、税费口径、安全标准这类本地规则，来源是英语基本意味着答案对不上你的市场。

## 用十种语言问同一个问题，为什么不能每种语言问各自合适的问题？

因为那样语言就不是唯一变量了。同一个问题跨语言问，差异才干净地来自语言本身；换成不同的问题，你分不清差异来自语言还是来自问题难度。实际操作中最容易破功的一步是翻译——总有人顺手把问题改得更符合当地表达习惯，改完这批数据就失去了横向可比性。翻译时宁可保留一点生硬。

## 本语言来源占比低，是不是说明我们本地团队做得不好？

基本无关。这个指标衡量的是整个语种在这个品类下的内容供给总量，一家公司的产出在其中占的比例很小。把它讲成团队绩效会引发不必要的防御，还会诱发对指标本身的优化。更准确的讲法是：这门语言里几乎没人在正面回答这批问题，所以这是一片空场而不是一次落后。

## 那把内容也翻译成英语发一份，能不能解决问题？

多数情况下不能，还会把优势换掉。在本语言里你可能是少数几个候选之一，进了英语池子你就是几十上百个候选之一，稀缺优势换成了拥挤劣势，而本语言那一侧的空白一点没补上。唯一说得通的场景是你的优势来自跨语言不会丢的东西，比如独家数据或者只有你能提供的检测结果；如果优势来自本地身份，翻成英语只会被稀释。

## 这个偏差会不会随着语料增长自己消失？

比例上的差距可能缩小，实际影响不一定跟着改善。检索是在绝对文档量上挑候选，不是按语言比例分配名额，所以决定结果的是你这门语言在这个具体话题下有多少篇文档，而不是它在全网总量里占百分之几。一门语言整体占比翻倍，在某个细分品类下仍然可能是零篇，而零篇和两篇的差别远大于占比的翻倍。

## 实测多久做一次比较合适？

每季度一次。这个分布变化很慢，测太密只会看到噪音，还会诱发对单次波动的过度反应。第一次做含设计和翻译大约需要两个人两天，之后每次重跑半天，整理出图再半天。样本要固定，别每次换一批查询——固定样本的绝对值可能不准，但趋势是准的；样本一换，绝对值和趋势就都不准了。

## 三档市场里，为什么排期要从最低那一档先动？

因为缺口最大、竞争最少、错误后果最重，三件事同时成立。在本语言来源占比高的市场，你的一篇内容是几十个候选里的一个；在占比极低的市场，你的一篇内容可能是唯一一个，同样的成本兑换出来的份额差着一个数量级。但动手之前要先确认一件事：那门语言的用户是不是真的在用这门语言搜索，有些市场的用户习惯直接用大语种提问。

## 权威参考资料



## 那个词每月几万次搜索，你查得到也知道意思，可它印在别人的商标证上

- URL：https://zhangwenbao.com/minor-language-genericized-trademark-category-keyword.html
- 分类：小语种SEO
- 发布：2025-06-16  |  更新：2026-07-30
- 摘要：德语里的纸巾、日语里的订书机、俄语里的尿布，日常说法都是某家公司的名字。讲清这类词怎么长出来、法律状态为什么按国家分别算、页面哪几处一个字都不能碰，以及自家品牌该怎么防。
- 关键词：关键词研究,多语言SEO,小语种SEO,品牌本地化

> **TLDR**：摘要：德国人买纸巾时搜索框里打的是一家公司的名字，日本人找订书机、俄罗斯人找尿布，情况一模一样。这类词有真实的搜索量，意思也毫无歧义，唯一的麻烦是它印在别人的商标注册证上。于是它成了词表里极少见的一类：你查得到、知道用户在搜、但页面上不能写。它的法律状态还按国家分别计算，同一个字符串在这国已是通用词，在那国仍是有效注册商标。本文讲清这类词怎么长出来、词表该怎么标、页面哪些位置一个字都不能碰、广告侧的规矩为什么不同，以及自家品牌名正在变成通用词时该高兴还是该紧张。

> 摘要：德国人买纸巾时搜索框里打的是一家公司的名字，日本人找订书机、俄罗斯人找尿布，情况一模一样。这类词有真实的搜索量，意思也毫无歧义，唯一的麻烦是它印在别人的商标注册证上。于是它成了词表里极少见的一类：你查得到、知道用户在搜、但页面上不能写。它的法律状态还按国家分别计算，同一个字符串在这国已是通用词，在那国仍是有效注册商标。本文讲清这类词怎么长出来、词表该怎么标、页面哪些位置一个字都不能碰、广告侧的规矩为什么不同，以及自家品牌名正在变成通用词时该高兴还是该紧张。

## 为什么德国用户搜纸巾的时候，打的是一家公司的名字？

## 一家家居日用站的品类页，主词从上线起就没动过

有个客户做家居收纳和日用百货，德国是主力市场，纸品、胶带、收纳盒这几类走量。

词表是标准流程建的，品类词按工具给的量排序，母语同事过了一遍，没什么可挑剔的。

纸巾这个品类的主词用的是词典里那个规规矩矩的词，页面结构也没问题。

跑了一年多，这个品类的自然流量始终比隔壁的收纳盒低一大截，尽管前者的市场大得多。

翻站内搜索日志的时候，保哥注意到一个词反复出现，量还不小，而它不在词表里。

那个词是一个纸巾品牌的名字。德国人说到纸巾，日常口语里用的就是这个词，不管手里拿的是哪家的产品。它在搜索框里出现的频率高到让人怀疑词表是不是漏了一整个品类，而它没进词表的原因也很简单：建表的人和审校的人都知道那是个牌子，谁也没想过要收。

后来把这个词的量单独拉出来看，它比词表里那个规范品类词高出不止一截。这个数字之所以从来没进过任何一份报表，是因为工具默认把它归进了品牌类目，而品牌类目那张表是另一个同事在看，那位同事只关心自家品牌的数据。

## 用户不是在搜品牌，他是在搜这个东西

判断这件事有个很干净的办法：看这批查询后面跟着什么词。

如果跟着的是价格、批发、哪里买、多少钱一包，那是在找这个品类。

如果跟着的是官网、旗舰店、真伪、客服，那才是在找这个品牌。

前一类查询里，用户对这个词的理解就是纸巾，跟哪家公司生产的没有关系。

这两类查询在工具里被合并成一行数字，拆开之后你才知道自己面对的是哪一种需求。

拆完之后还有一件事值得做：看这批查询最终落到了哪些页面。多数情况下它们落在那个品牌自己的官网或者大型平台的品牌店铺上，而你的品类页一次都没出现。这一步能把这件事从一个语言问题变成一个能给管理层看的竞争问题。

## 这类词在词表里是个空缺，而且是系统性的空缺

关键词表天生偏向词典能查到的词，这一点在好几处都成立。

被削短的口语形式进不来，年长一代的旧词进不来，通名化的商标同样进不来。

三者的漏法还不一样：短形式是没人记录，旧词是记录了没人选，商标是所有人都主动躲开。

躲开这个动作里其实包含了一次判断，只不过做判断的人从来没把它说出口。

词表里少了一行的事，跟用户搜的那个短词你的词典里查不到 (https://zhangwenbao.com/minor-language-clipped-short-forms-keyword-coverage.html)那篇是同一种病，只是这一次拦住它的不是词典也不是审校，是一条法律。

把三类空缺放在一起还能看出一条规律：词表天生收录的是被规范认可的词，而用户使用的是最省力的词。两者重合度在英语里很高，在别的语言里未必，因为英语的规范本来就宽松得多。这条规律在小语种上会反复出现，不只这一处。

## 把语种换成英语，这件事就消失了一半

英语世界当然也有这类词，纸巾、复印、创可贴都有各自的例子。

差别在于英语站主自己就生活在那个词表里，他从小就知道哪个词是牌子。

做多语言的人面对的是十几门自己不熟的语言，每门语言各有一批这样的词。

更要命的是各门语言被通名化的不是同一个牌子，甚至不是同一个品类。

所以这件事在单语市场是个常识问题，到了多语言市场就变成了一项要逐语言执行的调研。

更麻烦的是各语言被通名化的品类并不重合。德语里纸巾被占了，法语里冰箱和厨房纸被占了，日语里订书机和透明胶带被占了，俄语里尿布和复印被占了。你没法拿一个市场的清单去套另一个市场，只能逐语言重做一遍这项调研。

## 一个商标是怎么变成品类词的？

## 先来的那个东西，名字会粘住整个品类

最常见的路径是这个品类进入市场时只有一个品牌，用户没有别的词可用。

等第二家进来，语言里那个位置已经被占了，新来的只能借用。

德语的吹风机就是这么来的，那个词最初是一家电器公司的注册商标。

它今天已经进了正规词典，词典给的是一个改过拼写的形态，跟当年那个商标写法不同。

拼写被改这件事本身就是个信号：语言在把它据为己有，而改动的部分正是它跟商标切割的地方。

这条路径有个副产品：通名化的词往往能反过来告诉你这个品类是什么时候进入这个市场的，以及当年谁是第一名。有些被通名化的品牌今天早已退出该市场，词却留了下来。词表里出现这类词的时候，顺手查一下它的来历，对理解这个市场的竞争史很有帮助。

## 短的、好念的、能当动词用的，跨得最快

音节少的名字跨界最快，长名字很少能变成品类词。

能顺着本语言的构词规则接后缀的名字更快，因为它能长出动词和形容词。

俄语里那个表示复印的词就是典型，它不但是名词，还能变位成动词。

一个名字一旦能当动词用，它在语言里的地位就基本稳固了，再想收回来几乎不可能。

这条判据可以反过来用在自己的品牌名上：如果你的名字在目标语言里念得顺、又能自然接后缀，那它被通名化的概率天然更高，这件事该在命名阶段就纳入考虑，而不是等它发生了再找律师。

反过来说，一个名字如果在目标语言里发音别扭、接不了后缀，它就很难变成品类词，但同样也很难被口口相传。这里有个不太舒服的取舍：越容易被通名化的名字，通常也是越容易在当地传播的名字，这两件事共用同一批语言特征。

## 日常高频、家里常备、需要口头指认的品类最容易出事

纸巾、胶带、订书机、创可贴、保鲜膜，这些品类的共同点是天天要用嘴说。

需要口头指认的东西，语言会自动挑一个最省力的说法，商标名往往就是最省力的那个。

相反，专业设备和低频大件很少被通名化，因为没人天天说它。

日语里订书机和透明胶带都是这个路径，两个词都来自具体的公司或产品名。

做家居日用、办公用品、母婴这几类的人，遇到这件事的概率比做工业品的人高好几倍。

还有一类容易被忽略的场景是父母对孩子说话时用的词。家庭内部的日常用语更省力也更保守，通名化的商标在这一层的渗透率最高。做母婴和家清品类的时候，访谈对象里加一位家长，往往能问出词表上完全没有的说法。

## 物流和服务类也会被通名化，而且更隐蔽

商品之外，服务名同样会跨界，日语里的上门快递就是最典型的一例。

那个词是一家物流公司的注册商标，行业里的通用说法是另一个词。

用户写配送说明、写客服问答的时候会自然用前者，因为那才是日常说法。

服务类比商品类隐蔽，因为它经常出现在正文里而不是标题里，做词表的人看不见。

顺带说一句，这一类还特别容易混进客服话术模板，等到有人提醒的时候，它已经在几百个页面上住了两年。

服务类还有一个特殊风险：它经常出现在结构化的配送说明和运费表里，而这些内容通常由运营直接维护，不走内容审核流程。等于绕开了唯一一道可能拦住它的关卡，这也是为什么它常常是全站最后一个被清理干净的地方。

## 同一个词在这个国家是通用词，在那个国家是有效注册商标

## 法律状态是按国家分别计算的

商标权按国家或者按地区授予，通名化的判定同样按国家进行。

一个词在甲国被认定为通用名称从而失效，在乙国完全可能仍然有效。

最经典的例子是那个阿司匹林，它在一部分国家已是通用药名，在另一部分国家仍是注册商标。

这意味着同一个字符串在你的两个市场里，风险等级完全不同。

而你的多语言词表通常只有一行，那一行没有地方记这件事。

这条对多语言站的直接后果是：同一份词表在不同市场要有不同的可用位置。德语站上能写在正文里的词，到了另一个法域可能连正文都不能写。词表如果只有一行没有国家维度，那它记录的其实是一个平均值，而这件事没有平均值可言。

## 法律为通名化专门留了一条撤销通道

德国商标法里有一条专门讲这件事，商标因权利人未采取行动而成为通用名称的，可以被撤销。

欧盟层面的商标条例里也有对应条款，判据大致相同：成为通用名称加上权利人不作为。

这两个条件缺一不可，这一点非常关键。

它意味着只要权利人还在积极维权，哪怕全国人都拿它当品类词说，商标依然有效。

换句话说，用户的语言习惯和法律状态是两条独立的线，你不能拿前者推断后者。

两个条件必须同时成立这一点，还解释了一个常见的困惑：为什么有些词明明所有人都在当品类词用，权利人还是能成功维权。因为维权行为本身就在满足第二个条件，只要他持续在做，第二个条件就永远不成立。你看到的每一封律师函，都是这条证据链上的一环。

## 你不能拿词典收录当免责证明

不少人的判断依据是词典收了它，那就说明它已经是通用词。

词典的职责是记录语言事实，它不做法律判定，收录一个词不构成任何授权。

有些词典在词条里会标注它是注册商标，有些不标，标不标由编者决定。

所以词典能告诉你这个词在语言里流通得有多广，但不能告诉你写在页面上安不安全。

这跟拿不准就查词典这条兜底策略在别处失灵的情形是一类的，词典能回答的问题是有边界的。在借词的语法性别上，词典给的是并列的两个答案；在这里，词典给的是一个跟你的问题无关的答案，品牌名进德语市场比怎么拼更早要定的那件事 (https://zhangwenbao.com/minor-language-loanword-gender-assignment-brand-article.html)那篇讨论过前一种情形。

更实际的一点是：词典的收录标准是使用频率，而法律的判断标准是显著性是否丧失以及权利人有没有作为，两套标准的输入完全不重合。拿词典去回答法律问题，跟拿搜索量去回答用户意图问题一样，都是用一个相关但不对口的指标做决策。

## 词表要为它加一列，而且这一列会过期

正确的做法是在关键词表里给这类词单独立一列，记录法律状态。

取值不需要复杂，通用词、仍注册、有争议、未在本国注册，四档够用。

再加一列记录判断依据和查询日期，因为这个状态会变。

状态变化的方向大多是从注册走向通用，但也有权利人维权成功把词收回去的情形。

加保质期这件事在词表里已经不是第一次出现，包容写法那族词也需要一列到期时间。区别在于那一类的到期由官方机构公告，你只要盯着公告；这一类没有任何机构会通知你，只能自己排复核日历。

复核的触发条件建议写死成两条：一是每年定期看一次，二是这个词在站内搜索或者广告后台出现明显量变的时候临时看一次。第二条比第一条更有用，因为量变往往意味着这个词的地位正在变化，而变化的时候恰好是法律状态最可能被重新审视的时候。

## 这类词到底该不该进你的关键词表？

## 该进，但要进在正确的那一层

不收是最糟的选择，因为不收等于你连这批需求存在都不知道。

收进来的目的首先是认知：知道有多少人这么搜，他们搜完落到哪里去了。

其次才是覆盖，而覆盖有好几层，不同层的风险差得很远。

把这类词一律标成禁用然后从表里删掉，是把风险管理做成了信息销毁。

正确的姿势是留在表里、标清楚状态、限制它能出现在哪些位置。

删词这个动作在词表管理上几乎总是错的。词表的价值一半在于记录你知道什么，删掉一行等于把一次调研的结果抹掉，而下一个接手的人会重新踩一遍同样的坑。正确的做法永远是标注而不是删除，标注还能顺带记下当时的判断依据。

## 先把量拆成三堆再决定投入

第一堆是纯品类意图，用户就是想买这类东西，占比通常最大。

第二堆是真的在找那个品牌，这部分跟你没关系，除非你正好代理它。

第三堆是比较型查询，比如某牌和别的牌子有什么区别。

三堆的价值和风险都不一样，第一堆价值最高风险最低，第三堆反过来。

拆堆的办法还是看查询里跟着的那些词，这件事不需要工具，导出一批查询人工扫一遍就够。

三堆里最容易被误判的是第三堆。比较型查询看起来价值很高，因为用户已经在做决策了，但它同时也是法律风险最集中的一堆，因为你要在内容里同时提到两个品牌。这一堆的处理原则是按品类维度写而不是按品牌维度写，具体写法后面单讲。

## 工具给的数字在这类词上格外不准

通名化的词往往同时是品牌词，工具会把两种意图的量合在一起报给你。

合并之后的数字看起来很诱人，但其中有一部分是你永远接不住的品牌需求。

更麻烦的是有些工具会把这类词自动归到品牌类目，于是它在品类报表里消失了。

报表里看不见的需求最容易被判定为不存在，这条在小语种市场反复应验。

工具在小语种上本来就不可靠，补数的土办法在工具返回的那个零是数据缺口不是需求缺口 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)那篇里写过，这一类词要额外多做一步意图拆分。

还有一个细节：有些工具会把这类词的量直接归零或者隐藏，因为它们对商标词有单独的处理策略。看到一个你明知道有量的词返回零，别急着相信，先换一个数据源交叉验证。这类零和小语种里那种真正的数据缺口，成因完全不同。

## 站内搜索日志是判断它有多重要的最好数据

外部工具的量可以怀疑，自己站内的搜索框不会骗人。

把这个词在站内搜索里的出现次数和零结果率拉出来，结论立刻清楚。

零结果率高说明用户在用这个词找东西而你的站不认识它。

这一步同时也给出了最紧急的修复动作：先让站内搜索认识它。

而站内搜索恰好是这批词里风险最低的一个落点，这一点下面单独讲。

这份日志还有一个用法是给法务看。跟法务讨论这类词的时候，最有效的材料不是原理而是自家用户的真实输入记录。看到本站用户一个月里用这个词搜了多少次、其中多少次一无所获，讨论会立刻从要不要管转到该怎么安全地接住。

## 页面上哪些位置能写，哪些位置一个字都不能碰？

## 标题和商品名是最危险的两处

标题里出现别人的商标，等于在最显眼的位置暗示关联，这是风险最高的用法。

商品名里出现更严重，因为那已经接近把商标用在商品上。

这两处的答案很简单：不写，一个字都不写。

就算它已经被认定为通用名称，在这两处使用的收益也小于潜在麻烦。

标题是搜索结果里唯一露出的一行，风险和曝光在这里恰好同时最大化。

还有一处跟标题同级危险但经常被忘记：站内搜索结果页的标题。很多站会把用户输入的查询词拼进这个页面的标题里，一旦这类页面被索引，等于自动生成了一批标题里带着别人商标的页面，而且数量随用户输入无限增长。

## 正文里的描述性提及是另一回事

正文里为了说明兼容性或者做对比而提到一个牌子，性质跟标题不同。

大多数法域承认一种指示性的使用，前提是必要、不暗示关联、不超出说明的限度。

写清楚这是谁的商标、你和它没有关系，是把这种使用做扎实的最低成本动作。

但要注意各国对这件事的宽严程度不同，比较广告的规则在欧洲比在美国严格。

拿不准的时候的通用做法是：让本地法务看一遍那几个模板句子，一次审完可以用很久，比每篇内容都问一次划算得多。

把这几个模板句子固化下来还有个好处：内容团队不必每次自己组织措辞。给出三四种可以直接复用的句式，比给一堆原则更能落地。写作的人拿到的是可以直接抄的句子，法务审的是有限的几个模板，双方的工作量都降下来了。

## 地址、文件名和图片名里不要留

地址一旦生成就很难改，里面留着别人的商标是个长期负债。

图片文件名和替代文本同理，它们会被独立索引，也会被独立追溯。

这几处的共同点是改动成本高、收益低，属于典型的不值得冒险。

图片那一层有六个能写字的位置，各自的读者不同，同一张商品图的文件名和替代文本要用两套字母写同一个词 (https://zhangwenbao.com/minor-language-image-alt-text-non-latin-script-search.html)那篇把这张表画得最细，商标这件事在那张表上要另加一条约束。

这几处还有一个共同特点：它们通常由系统自动生成，而生成规则往往是从商品标题拿的。也就是说只要标题里没有，这几处自然就干净。反过来如果某个历史商品的标题里带过这个词，即使标题后来改了，地址和图片名很可能还留着，这一层要单独扫。

## 结构化数据里的别名字段要克制

商品标记里有别名字段，看起来是个塞同义词的好地方。

但别名字段的语义是这个商品还叫什么，往里面塞别人的商标显然不合适。

标记这一层还有个特点：它是给机器读的，出问题的时候没有语境可以辩解。

正文里至少还能靠上下文说明这是在做对比，标记里只有一个孤零零的字符串。

标记该怎么填在正文越本地化越好，结构化数据里却要反着写回国际格式 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)那篇里有完整的分类，这一条可以直接加进那份不许填的清单。

顺带说一句，商品数据源送到比价平台和购物广告的时候，走的也是类似的字段结构。那一侧的审核通常比自然搜索严格，一旦被拒，整个数据源可能受影响。把这类词从数据源里清干净，收益不只在法律这一侧。

## 匹配层为什么是唯一安全的收纳处？

## 它只影响机器怎么理解，不影响用户看到什么

站内搜索的同义词配置是这批词最好的去处。

用户搜那个词，你的站把他带到正确的品类页，页面上一个相关字样都没有。

这中间没有任何对外的展示，也不构成任何商业性使用的外观。

收益却是实打实的：零结果变成了正确的结果，用户不用换一家。

这是整件事里投入最小、收益最直接、风险最低的一步，应该第一个做。

这一步的效果通常立竿见影，因为它修的是一个硬阻塞：用户已经在你的站里、已经表达了明确需求、结果被自己的搜索框挡了回去。相比之下把同一批预算花在拉新上，效率完全不在一个量级。这也是保哥在这类项目里总是先做站内搜索的原因。

## 词表里的匹配层和展示层要分成两栏

很多团队的关键词表只有一栏词，收进来的词默认就是要写到页面上的。

这类词逼着你把表拆成两栏：一栏是可以展示的，一栏是只能用于匹配的。

拆完之后你会发现，能进匹配层不能进展示层的词不止商标这一类。

用户的错拼、口语形态、受限品类的直白说法，都属于同一格。

这一栏建起来之后就是长期资产，后面每加一门语言都能复用同一套结构。

拆栏之后还要给每一行标上原因，是法律风险、平台限制还是观感问题。原因不同，解禁的条件也不同：平台限制会随政策变化，观感问题可以由品牌自己决定，法律风险则需要外部意见。混在一起标成禁用，将来没人知道哪些是可以重新讨论的。

## 客服和邮件模板要单独查一遍

页面上的用词有人管，客服话术和邮件模板往往没人管。

而这两处最容易出现日常口语说法，也就最容易混进通名化的商标。

它们的传播范围看起来小，但那是一对一的书面沟通，留痕更完整。

检查办法很简单，把这批词丢进模板库全文搜一遍，几分钟就能出结果。

顺手把这批词加进内容管理系统的敏感词提示里，以后写稿的人打出来就会看到提醒，比事后清理省事得多。

模板库之外还有两处：自动回复和知识库文章。这两处的共同点是写的时候没人想到它们算对外内容，而它们的实际阅读量往往比某些页面还高。检查的时候把这两处一起纳入，成本几乎没有增加，覆盖面却完整了。

## 历史内容清理要按流量排序而不是按数量

老页面里散落的这类词可能有几十上百处，一次清完不现实。

按页面流量和入口链接数排序，先处理头部那批。

标题和商品名里的优先处理，正文里的可以慢一档。

处理的时候顺手把替代写法定下来，别每个人各写各的。

替代写法定不下来的时候，最省事的口径是上位词加一个限定词，读起来自然又完全安全。

清理时建议同步在内容管理系统里加一条提示词规则，把这批词设成写作时的软提醒。清理是存量工作，提示是增量防线，两件事一起做才不会边清边长。只做清理的团队通常在一年后还要再清一次，而且量不会比第一次少多少。

清理范围别漏了可下载的产品资料，规格书和说明书里同样会出现这批词，而且它们通常没人复查。这类文件还另有一个坑：非拉丁文字的资料经常抽不出可读的文字，屏幕上是好好的泰语机器复制走的是另一串字符 (https://zhangwenbao.com/minor-language-pdf-text-layer-extraction-failure.html)那篇讲了怎么十秒判出来，扫用词的时候可以顺手一起测。

## 广告那一侧的规矩，跟自然搜索不是一套

## 投放和展示是两个独立的判断

主流广告平台对商标的处理分成两块：能不能拿它当关键词投，能不能写进广告文案。

多数地区对前者相对宽松，对后者严格得多。

平台还提供投诉通道，权利人可以就文案里的使用提出申诉。

这套规则是平台自己的政策，跟法律不是一回事，两者要分开看。

平台政策的好处是白纸黑字写着，坏处是它会变，而且变了不会专门通知你。

还要注意的是这套政策按地区分别适用，同一个词在不同国家的投放地区里可能有不同结论。多国投放的账户尤其容易踩到，因为广告组通常是按语言而不是按国家分的，而政策是按国家判的，两套划分方式对不上。

## 自然搜索没有对应的投诉入口，这反而更麻烦

广告那一侧至少有个明确的规则和申诉流程，出问题会先收到通知。

自然搜索这一侧没有这样的机制，权利人的第一封信通常直接来自律师。

所以不能因为自然搜索没人管就默认它更安全，只是它的反馈来得更晚也更重。

这一点跟受限品类的词表正好相反：那一类是平台先拦你，这一类是平台不管你。

平台按语言分别维护受限词表这件事在那个词你不好意思写用户也不好意思打 (https://zhangwenbao.com/minor-language-euphemism-restricted-category-keyword.html)那篇里讲过，两类词最好放进同一张表分开标注，因为它们的处理动作正好互补。

这条差异还带来一个反直觉的建议：广告那一侧的政策文档，可以当成自然搜索这一侧的风险清单来读。平台的政策通常是在大量纠纷之后总结出来的，它标出来的高危位置，在自然搜索里同样高危，只是没有人会提前提醒你。

## 联盟和代理商那一层最容易漏

你自己的页面管住了，联盟客和当地代理商的页面未必。

他们为了拿量最爱用的就是这类高搜索量的通名词。

而在权利人看来，这些页面和你的品牌是关联在一起的。

合作条款里加一条明确的用词约束，成本几乎为零。

本地渠道和目录站这一层本来就要定期看，小语种外链能用的都在当地人的圈子里 (https://zhangwenbao.com/minor-language-link-building-local-directories-media-communities.html)那篇讲过怎么盘这批资源，盘的时候顺手把用词也看一眼。

约束条款要写得可执行，不能只写不得侵犯第三方权利。给出一份具体的禁用词清单，并写明禁止出现的位置，合作方才知道该怎么做。清单还能顺带起到教育作用，很多合作方并不知道那个日常词是个注册商标。

## 接不住的那部分流量，有没有绕回来的办法？

## 最有效的办法是让上位词自己长出来

用户用商标名搜，本质上是因为品类词在他嘴里不够顺口。

你能做的是让品类词在他的阅读里反复出现，慢慢变成同样顺口的词。

这件事听起来很慢，但在内容量足够的品类里确实有效。

做法是在所有正文里坚持用品类词，同时让页面回答那些他本来会用商标名去问的问题。

指望一个站改变一门语言当然不现实，但你的目标不是改变语言，是让这批用户在你的站上找到东西。

这件事有个可以观察的指标：站内搜索里品类词和商标词的比例。如果内容做得对，这个比例会缓慢向品类词那一侧移动，因为你的老用户是从你的内容里学到那个词的。移动速度很慢，但它是真实的，而且这个指标完全由你自己掌握。

## 做需求本身的内容，而不是做那个词的内容

用商标名搜的人真正想要的是选型帮助、材质区别、用法差异。

把这些内容做透，页面自然会在相关查询里出现，而不必写那个词。

这类内容的另一个好处是它能同时接住一批长尾问句。

小语种市场的问答长尾竞争密度本来就低，整个语种里认真写完整回答的也没几家 (https://zhangwenbao.com/minor-language-qa-long-tail-content-value-ai-era.html)那篇算过这笔账。

这是本文里唯一一条正收益的建议：被法律挡住的那扇门，是靠内容质量从旁边绕过去的，不是靠找措辞的漏洞。

写这类内容的时候有个很实用的技巧：把用户会用商标名去问的那些问题，原样写成标题里的问句，只是把商标名换成品类词。用户的问法结构保留了，风险的那部分被替换掉了，命中率往往比重新组织一套说法要高。

## 站内搜索的零结果页是最后一道拦截

就算前面都没接住，用户在站内搜索里打这个词的时候你还有一次机会。

零结果页应该给出相关品类的入口，而不是一句抱歉没找到。

这一步的转化效率通常很高，因为这批用户已经在你的站里了。

零结果日志同时也是发现新的通名化词的最好来源，它是双向受益的一处改动。

每个月扫一遍零结果日志里的高频词，是发现这类问题成本最低的定期动作。

零结果页还应该保留一个入口：让用户告诉你他想找什么。这个入口的提交量通常很小，但提交内容的质量极高，因为写的人是真的没找到东西。这批文字里经常能挖出好几个词表上完全没有的说法。

## 别把这条路径寄托在搜索引擎的同义词能力上

有人会说搜索引擎自己能把商标名和品类词关联起来，不用管。

大语种上这个能力确实不错，小语种上要打个折扣。

同义词表是逐语言建设的，投入按市场规模分配，小语种排在后面。

这条规律在多语言模型铺开之后有所改善但没有消失，多语言模型铺到七十多种语言那天受益最多的不是字母最像英语的那几门 (https://zhangwenbao.com/multilingual-bert-seventy-languages-minor-language-seo-watershed.html)那篇拆过受益分布。

把希望寄托在别人补齐你的语言上，通常比自己配一份同义词表要慢好几年。

有个简单的验证办法：拿那个商标词在目标市场的搜索引擎上搜一遍，看结果页里有没有出现纯品类的页面。如果满屏都是那个品牌自己和大平台的品牌页，说明引擎并没有把它当成品类词处理，那你就更不能指望它替你做这层关联。

## 你自己的品牌名正在变成通用词，这算好事吗？

## 市场部和法务部对这件事的判断正好相反

市场部会为品牌名变成动词而欢呼，那意味着渗透率到顶了。

法务部看到同一个现象会紧张，因为那是商标失效的前兆。

同一个事实在两个部门的口径里，一个是成绩一个是风险。

这不是谁对谁错，是两个部门的目标函数本来就不一致。

做多语言的人夹在中间，最好的姿势是承认两边都对，然后把动作拆开：让传播继续，同时把用法规范起来。

这种目标冲突还有一个典型表现：市场部希望品牌名被用作动词，因为那是渗透率的最高证明；法务希望它永远只作形容词，后面跟着品类名。两边说的都是同一个名字在语言里的位置，只是一个在争取，一个在设防。

## 法律给的判据里有一半掌握在你自己手上

撤销条款的两个条件是成为通用名称加上权利人不作为。

第一个条件你控制不了，那是语言在做的事。

第二个条件完全在你手上，而且它有明确的证据形式。

持续的规范用法、公开的商标声明、对滥用的交涉记录，都是不作为的反面证据。

这也解释了为什么大公司会在广告里反复强调自己的名字是形容词而不是名词，那看起来像是文案洁癖，实际上是在留证据。

留证据这件事对做内容的人来说其实很轻：所有对外发布的内容都归你管，规范用法这一条只要写进风格指南并在审核里执行，证据链就自然形成了。反倒是那些没人管的角落，比如社媒文案和活动物料，最容易留下反面证据。

## 页面上的写法就是最便宜的证据

品牌名后面跟一个品类词，是最标准的规范用法。

不要把自己的品牌名当成动词或者复数名词用，哪怕文案里那样更顺口。

页面上带一句商标声明，成本是一行字。

这几件事本来就属于品牌规范的范围，只是很少有人把它跟这条法律条款联系起来。

你的品牌名进入小语种市场之后会长出好几种写法，品牌名叫什么不由你定由当地用户的输入法定 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)那篇讲的是写法这一层，这里是用法这一层，两层要写进同一份规范里，但管的是不同的东西。

要提醒一句，规范用法和自然表达之间会有摩擦。品牌名后面永远跟着品类词，读起来确实比直接用品牌名生硬。折中的办法是首次出现时规范用法，后续可以放松，这既保住了证据也保住了可读性，绝大多数品牌规范也是这么写的。

## 把它跟别人的商标放进同一张表管理

你的品牌名和别人的通名化商标，在词表里是同一类对象的两面。

一面是你希望它别失去显著性，一面是别人希望你别用它。

两面共用同一套字段：法律状态、可用位置、复核日期、负责人。

把它们放进同一张表，还有个好处是每次复核只开一次会。

做多语言的时候这张表要按语言展开，因为两边的状态都是逐语言计算的。

这张表还应该记一列：这个词在本站内容里的实际出现次数。数字定期跑一遍，既能发现新增的违规使用，也能量化自家品牌规范的执行情况。两个方向共用同一个统计脚本，维护成本几乎为零。

## 这件事该多久复核一次，谁来盯？

## 复核周期按语言的变化速度定

词的法律状态变化很慢，一年看一次通常够了。

但用户的用词习惯变得快，新品类进入市场的时候尤其快。

所以复核分两件事：法律状态一年一次，用词习惯跟着品类扩张走。

新开一个品类或者新进一个市场的时候，把这一项加进上线前的清单。

清单上的问法要具体：这个品类在这门语言里，有没有某个牌子被当成通名在用。

还有一个触发点值得写进流程：进入一个新的品类线的时候。品类扩张是这类问题最集中的入口，因为新品类意味着一批全新的日常用语，而团队对新品类的语言直觉最弱。这一条加进立项清单，比定期复核更能抓住风险发生的时刻。

## 问本地同事的时候要问对问题

问哪个词正确，得到的答案永远是词典里那个词。

问他自己平时怎么说，才能问出那个通名化的商标。

再追一句他妈妈会怎么说，能顺带把代际差异问出来。

代际这条线在关键词表照着全体人说话的样子建，可买东西的只有其中一代人 (https://zhangwenbao.com/minor-language-generational-vocabulary-older-buyers.html)那篇里单独讲过，两件事经常在同一次访谈里一起浮出来。

访谈时别提前告诉对方你在找什么，一旦提示了商标这个词，他会立刻切换到规范用词模式，这次访谈就白做了。

访谈还有一个省事的替代方案：直接看当地的二手交易平台。个人卖家写标题时完全不考虑规范，用的就是最自然的说法，而且为了让人搜得到，他们会把所有可能的叫法都堆上去。那些标题几乎就是一份现成的通名词清单。

## 验收看两个数就够

第一个数是站内搜索里这批词的零结果率，配完同义词之后它应该降到接近零。

第二个数是这批词带来的落地页分布，理想状态是全部落到对应的品类页。

两个数都不需要额外埋点，站内搜索日志里就有。

不要看排名，你本来就不打算为这个词做排名。

这也是这类词跟普通关键词最大的操作差别：它的成功指标不在搜索引擎那一侧，而在你自己站内。

如果一定要看外部指标，可以看品类词本身的表现有没有跟着变好。原理是这批用户被正确接住之后，站内行为数据会变好，而这批数据最终会反映到品类页的整体表现上。但这条链路很长，不建议拿它当主要验收口径。

## 这件事不归语言层管的部分

具体某个词在某国的法律状态，最终要由本地法律意见确定，不是查词典能定的。

合作方违规使用的处置，属于合同和渠道管理。

品牌自身的商标注册与维护策略，属于品牌和法务的长期工作。

这一篇只回答语言层的三个问题：这个词存不存在、有多少人在用、你的页面能不能写。

把这三件事跟上面那些分开，你在跟法务开会的时候才能只带一页纸，而不是把整张词表铺在桌上。

## 常见问题解答

## 不懂这门语言，怎么发现自己的品类里有这类词？

最快的两条路都不需要语言能力。第一条是站内搜索的零结果日志，把出现频率高又查不到结果的词导出来，这批词里通常就藏着答案；判断一个词是不是牌子，把它单独搜一遍看返回的是不是某家公司的官网就知道了。第二条是看当地的比价站和大型零售平台的分类名，那些平台的分类名一定用的是安全的通用词，而它们的站内搜索建议里往往会出现通名化的那个词。

还有一个更土的办法：在当地的问答社区里搜这个品类，看用户提问时用的是哪个词。用户提问不受任何规范约束，那里出现的就是最自然的说法。三条路交叉一遍，基本不会漏。

## 这个词词典已经收了，是不是就可以放心用了？

不能。词典的职责是记录语言里实际存在的用法，它不做法律判定，也没有任何机构授权它做这种判定。有些词典会在词条里标注这是注册商标，有些不标，标不标是编辑方针的问题。所以词典能告诉你的是这个词流通得有多广，而你要问的问题是页面上写它安不安全，这是两个不同的问题。

真正相关的判据有两个：这个词在你的目标国有没有被主管机关或法院认定为通用名称，以及权利人是不是还在积极维权。第二条尤其容易被忽略，因为它意味着哪怕全国人都拿它当品类词说，只要权利人还在维权，商标就依然有效。这个判断超出了语言层，需要本地法律意见。

## 竞品都在页面上写这个词，我不写是不是吃亏？

先确认他们写在什么位置。如果是在正文里做对比说明，那可能属于被普遍接受的描述性使用；如果是写在标题和商品名里，那是他们在承担风险，而风险没有兑现不等于不存在。跟着做的问题在于，一旦权利人开始维权，通常是成批处理的，先被找上的往往是最容易被检索到的那几家。

更实际的做法是把这批流量的价值算清楚：拆掉品牌意图那部分之后，纯品类意图还剩多少，这些量能不能靠内容和站内搜索接住大部分。多数品类里算完这笔账会发现，能安全接住的比例比想象的高，剩下那部分不值得为它承担法律风险。

## 站内搜索配了同义词，会不会被认为是在利用别人的商标？

站内搜索的同义词配置不对外展示，用户搜完看到的是你自己的品类页，页面上没有任何相关字样。这跟在页面上使用商标是两回事。风险真正开始上升的地方是把这个词写进可被外部检索到的内容，比如页面标题、商品名、地址、结构化数据里的别名字段。

要注意的是别在零结果页或者搜索结果页的标题里回显用户输入的那个词。有些站的搜索结果页会把查询词拼进标题，而这类页面如果被索引，等于把商标写进了标题。解决办法是给站内搜索结果页加上不索引的标记，这件事本来出于其它原因也该做。

## 自己的品牌名被用户当成品类词说，要不要主动纠正？

要，但纠正的对象不是用户，是你自己的页面和渠道。用户怎么说话你管不了，也不必管，那本身是渗透率的证明。你能做也应该做的是三件事：自己的所有内容里坚持规范用法，品牌名后面跟品类词；页面上保留商标声明；发现合作方或者第三方明显滥用时留下交涉记录。这三件事加起来构成了法律条款里那个积极维权的证据。

不建议做的是在公开渠道纠正用户的说法，那既没有效果又损伤好感。语言的走向从来不听品牌方的，这一点在别的语言现象上也反复得到验证——有裁决机构的语言尚且如此，何况这件事根本没有裁决机构。

## 多语言站要不要为这类词做单独的落地页？

不建议。为一个你不能在标题里使用的词做落地页，本身就是矛盾的：页面能承载的正是那些不能写的位置。更合理的做法是让现有的品类页和选型内容去承接这批需求，它们本来就在回答这批用户真正的问题。

如果这个品类的比较型查询确实很大，可以做选型对比类的内容，但要按品类维度写而不是按品牌维度写。写材质、规格、适用场景的差异，自然会覆盖到相关查询，而不必把品牌名挂在标题上。这类内容在小语种市场的竞争密度普遍偏低，做透了性价比很高。

## 这件事在多语言站上，该由谁来牵头？

牵头的人应该是管关键词表的那个人，因为这件事的载体就是词表里那两列。法务提供的是单点判断，他们不会主动扫描你的全部词表；本地同事提供的是语言事实，他们不掌握法律状态。只有管词表的人同时看得到量、位置和状态这三样东西。

协作方式建议做成异步的：词表里标出候选，一次性打包发给法务确认，拿回结论后写进那一列并注明日期。这样法务一年只需要看一两次，而不是每次写内容都被问一遍。一次打包问清楚十几个词，比零散问十几次的通过效率高得多，也更容易得到明确的答复。



## 品牌名进德语市场，比怎么拼更早要定的一件事是它算公的还是母的

- URL：https://zhangwenbao.com/minor-language-loanword-gender-assignment-brand-article.html
- 分类：小语种SEO
- 发布：2025-05-15  |  更新：2026-07-29
- 摘要：德语没有任何机构负责裁决名词性别，法语有机构却判了没人听，俄语则是规范向用法让了步。讲清一个性别错了会连锁到几处、为什么只伤转化不掉流量，以及新品牌怎么在取名阶段避开。
- 关键词：多语言SEO,内容本地化,小语种SEO,品牌本地化

> **TLDR**：摘要：德语、法语、俄语要求每个名词都归进一个性别，本族词的性别是词典里查得到的事实，新借进来的词却不是，它的性别是一场还在进行的投票，而品牌名永远是这门语言里最新的那个词。归属没定意味着同一个词有两三种都合法的写法，冠词不同、形容词词尾跟着不同、代词回指也不同。更麻烦的是它不掉搜索量，只伤页面读起来像不像本地人写的，于是在以流量为口径的复盘里永远不会被发现。本文讲清这一格该由谁填、错了会连锁到几处、三条分配倾向为什么互相打架，以及半天能定下来的决策流程。

> 摘要：德语、法语、俄语要求每个名词都归进一个性别，本族词的性别是词典里查得到的事实，新借进来的词却不是，它的性别是一场还在进行的投票，而品牌名永远是这门语言里最新的那个词。归属没定意味着同一个词有两三种都合法的写法，冠词不同、形容词词尾跟着不同、代词回指也不同。更麻烦的是它不掉搜索量，只伤页面读起来像不像本地人写的，于是在以流量为口径的复盘里永远不会被发现。本文讲清这一格该由谁填、错了会连锁到几处、三条分配倾向为什么互相打架，以及半天能定下来的决策流程。

## 为什么德语页面上的品牌名，同一个站里出现了三种冠词？

## 一次德国汽车配件站的全站扫描

有个客户做德国市场的汽车配件，主营刹车片、机油滤清器、雨刷这几条线，自有品牌加代理品牌一共二十来个。

他们的德语内容做得相当认真，商品页、安装教程、选购指南三套内容都请了本地写手。

问题是在一次内容审计里被顺手发现的：同一个自有品牌名，在站内三处不同的页面上跟着三个不同的冠词。

保哥让他们把全站含品牌名的句子拉出来做了一次扫描，结果是二十多个品牌里有七个存在这种情况。

更麻烦的不是数量，是没有一个人能说清楚哪一种才是对的。写手说他按语感写的，审校说三种都能接受，品牌手册里对这件事一个字都没有。这不是有人违反了规范，是从来就没有过一条规范。

后来把这七个品牌的相关句子按写作时间排了一下，发现更有意思的现象：同一个写手在不同月份写的稿子里，用的冠词也不一样。也就是说这不是人和人之间的分歧，是这个词在这门语言里本来就还没定下来，而每一次写作都相当于投了一票。

这次扫描还有个副产品：他们顺手统计了一下这七个品牌各自出现了多少次不同写法，发现分布极不均匀。销量最高的那两个品牌反而是不一致最严重的，因为它们的页面最多、经手的写手也最多，写得越多分歧积累得越厉害。

## 冠词只是露在外面的那一截

如果这件事只影响冠词，那还算好办。

问题是德语里名词的性别会往外辐射，跟它搭配的形容词要跟着改词尾。

代词回指也要跟着改，上一句提到这个品牌，下一句用哪个代词指它，取决于同一个判断。

复合词的构成方式在个别情况下也会受影响。

于是一个没定下来的性别，会在一段两百字的商品描述里产生五到八处不一致，而每一处单看都只是一个小词，小到任何一次通读都会滑过去。

辐射范围这件事有个直观的估法：数一数商品描述里有多少个修饰这个品牌名的形容词，再加上代词出现的次数，基本就是这一个判断会影响的位置数。数完之后多数人会重新评估这件事的优先级。

## 这类不一致过不了任何一道现有的检查

把这七个品牌的页面拿去跑一遍常规检查，什么都查不出来。

拼写检查没问题，因为每一种写法本身都是合法的德语。

翻译质量检查没问题，因为这些句子本来就是德国人写的。

术语一致性检查也没问题，因为术语库里存的是品牌名这个字符串，而字符串在三种写法里完全一样，变的是它前面那个词。

这一点跟强调标记漂移那一篇 (https://zhangwenbao.com/minor-language-emphasis-markup-anchor-drift.html)的结构很像：校验项做到了周围的字符这一级，却没有一项在问它罩住的是不是同一个东西。这里也是同样的错位，检查器盯着品牌名本身，而出问题的是它旁边那个词。

顺着这条线还能得出一个推论：凡是错误发生在词与词的关系上而不是词本身上的，现有的自动检查基本都抓不到，因为它们的最小检查单位是词。要抓这一类只能靠规则去看搭配，而搭配规则要按语言各写一套，成本高得多。

## 判据是这个词有没有一个被公认的性别

要判断一个词会不会出这个问题，只需要问一句：这门语言里有没有人能说清楚它是什么性。

本族的老词一定有，词典给一个答案，全国上下没有分歧。

进来几十年的借词多半也有，因为投票已经投完了。

最近十几年才出现的词、以及所有的品牌名，通常没有。

所以这件事的风险面是可以提前圈出来的：把词表里出现时间最近的那一批词挑出来，再加上全部品牌名，就是需要处理的全集。这份全集通常只有几十条，比多数人预想的小得多。

圈范围的时候可以顺手做个排序：按这个词在站上出现的次数从多到少排，前面十几个处理完，全站的不一致就消掉大半。剩下的长尾可以放进下一轮，不必一次做完。

## 本族词的性别是查得到的，新借词的性别谁说了算？

## 德语根本没有一个负责这件事的机构

这是本文最值得记住的一条事实。

德语有一个官方的正字法委员会，它发布的规则集是各国行政和学校系统认的那一份。

但那份规则集管的是拼写、断词、连字符和标点，性别归属完全不在它的管辖范围内。

也就是说，德语在这个问题上连一个有权裁决的机构都不存在。

词典在这里扮演的角色是记录者而不是裁决者。它把社会上正在流通的用法收进来，两种都常见就两种都收，并不会告诉你该用哪一个。你去查词典想找一个答案，拿回来的是一份现状报告。

这一点对沟通很有用。团队里经常有人问一句权威怎么说，而这个问题在这里根本没有对应的答案。把没有权威机构这件事先讲清楚，后面关于看数据做决定的讨论才进行得下去，否则总有人觉得肯定有个标准答案只是我们没找到。

## 法语有裁判，可是判了也没人听

法语那边的情况正好构成一个绝佳的对照。

法语有一个历史悠久的语言机构，它确实有资格对这类问题表态。

2020年它就一个当时的新词做了公开表态，理由讲得很清楚：这个缩写背后的核心词是阴性的，所以整个缩写应该按阴性用。

结论在逻辑上无懈可击，媒体也报道了。

然后事情就变成了一个很有意思的社会实验：民间的日常说法在此后相当长一段时间里仍然大量沿用阳性写法，两种写法一直并行。有裁判的语言和没裁判的语言，最后落到页面上的处境几乎一样。

这件事还有一层值得琢磨：那次表态之所以广为人知，恰恰是因为它引发了争议。如果它当时就被普遍接受，这件事根本不会被记住。所以裁决被讨论得越热闹，往往说明它离生效越远。

## 俄语那次官方承认走的是另一条路

俄语提供了第三种样本。

有一个表示咖啡的借词，长期以来被规定为阳性，而口语里几乎所有人都当中性用。

2009年官方公布的一批规范词典承认了口语中的中性用法，等于是规范向用法让了一步。

注意这个方向：不是用法被纠正过来，是规范被改过去了。

把三门语言放在一起看，结论就很清楚了：没有裁判的会一直投票下去，有裁判的判了也未必算数，而真正会变的往往是规范这一侧。你在做本地化决策时，不能把词典或者官方表态当成一个可以照抄的答案，它只是众多输入里的一个。

俄语这个样本还提示了一件事：规范让步这件事是有前提的，前提是用法的分布已经悬殊到无法忽视。所以你在页面上看到的比例如果只是六四开，那离规范改口还早得很，得按两种并存来处理。

## 唯一真正说了算的是用法的分布

既然没有权威可以依靠，那就只能看数据。

德语的数字词典项目会给词条挂上基于语料的用法说明，双性词在那里能看到两种写法各自的流通情况。

这个数据的意义不在于告诉你哪个对，而在于告诉你哪个更常见。

对做内容的人来说，更常见就是唯一有操作意义的答案。

这条方法论跟生命度那一篇 (https://zhangwenbao.com/minor-language-animacy-accusative-keyword-forms.html)是同一套：凡是词典自己给出两个并列答案的地方，跟着词典走这条通用策略就没有输出了，你必须自己去看分布。两件事踩的是同一个坑的两个位置。

看分布的时候要留意语料的时间跨度。一个词如果是近十年才进来的，用几十年跨度的语料算出来的比例会被早期的空白稀释，正确的做法是只看最近几年的切片。

## 一个词的性别定错了，会在页面上连锁到几处？

## 冠词是第一处也是最显眼的一处

连锁的第一环是冠词本身。

它出现在标题、面包屑、按钮文案、商品名称这些最显眼的位置。

德语用户对这个词的敏感度极高，因为它在句子里出现的频率高到几乎每句都有。

用错了不会造成理解障碍，但会立刻产生一种说不上来的别扭感。

这种别扭感的杀伤力在于它无法被具体指出来。用户不会写邮件告诉你冠词用错了，他只会觉得这个站有点怪，然后去了别家，而你在任何数据里都看不到原因。

还有一个位置的冠词特别值得单独核一遍，就是导航和分类名。那些文本在全站每一页都出现，一旦定错，用户在任何一个页面上都会遇到它，而且它是最不容易被内容团队想起来去改的一块。

## 形容词词尾是第二处，也是最难自查的一处

第二环是形容词。

德语的形容词词尾要跟名词的性、数、格同时保持一致，是一张三维的表。

性别选错了，这张表里对应的那一格就跟着错，词尾也就错了。

而形容词词尾的错误比冠词更难被非母语者发现，因为差别常常只有一两个字母。

这一层跟意大利语性数一致那一篇 (https://zhangwenbao.com/italian-seo-gender-agreement-elision-keyword-research.html)讲的是同一个机制，区别在于那一篇处理的是已有词的一致关系，这一篇处理的是那个词的性别本身还没定。前者是执行问题，后者是取值问题，取值错了执行得再规范也是错的。

形容词这一层还有个隐蔽的放大器：德语的词尾同时受性、数、格三个维度控制，而同一个词尾形式可能对应多个组合。于是错误的性别有时会碰巧生成一个正确的词尾，让你误以为没问题，直到换一个格的时候才暴露出来。

## 模板拼出来的句子会把错误批量复制

第三环出现在模板上。

商品标题、分类页描述、结构化数据的名称字段，这些位置的文本大多是模板拼出来的。

模板里的冠词和形容词是写死的，名词是变量。

一旦某个品牌的性别在数据里标错了，这个错误会被复制到这个品牌名下的每一个页面上。

多语言模板那一篇 (https://zhangwenbao.com/multilingual-template-ten-languages-duplicate-content-risk.html)讲过性数一致会让替换失效，这里是同一个机制的上游：那一篇假设名词的性别是已知的，只是模板没做计算；这一篇是性别这个输入本身就填错了，模板算得再对也输出错的结果。

模板这一处还有个容易忽略的位置，就是页面标题和描述的自动生成规则。那两处的文本不出现在正文里，做内容审核时常常整块被跳过，可它们恰恰是搜索结果页上唯一露出的部分。

## 代词回指会把错误带到相邻段落

第四环最容易被漏掉。

正文里提到一次品牌之后，后面用代词指代它，代词要跟性别一致。

写手在写第二段的时候未必会回头确认第一段用的是哪个冠词。

于是同一篇文章内部出现前后不一致，这种不一致对本地读者来说比一直错下去更刺眼。

可以记一条经验：一直用错的页面读起来像是外国人写的，前后不一致的页面读起来像是几个人拼的。后者对品牌观感的伤害更大，因为它同时暴露了没有规范和没有校对两件事。

代词这一层还有个实际的规避办法：在需要回指的地方直接重复品牌名，别用代词。重复品牌名在德语商品文案里完全自然，还顺带提高了品牌词的出现密度，属于一举两得。

## 这件事会掉搜索量吗，还是只伤转化？

## 搜索这一侧几乎不受影响

先说一个可能让人松一口气的结论。

用户在搜索框里输入时极少带冠词，搜品牌名就是打品牌名本身。

所以性别选错并不会让你的品牌词搜不到，也不会直接影响这个词的排名。

这跟变格、复合词、变音符号那几类问题完全不同，那些是真的会让字符串对不上。

换句话说，这是少数几个只在页面内部发生、不在查询侧发生的语言层问题。它不改变匹配，只改变阅读体验。

不过有一个例外要提：如果品牌名恰好跟某个普通词同形，用户偶尔会带上冠词来消歧。这种情况很少，但一旦发生，两个形态的查询量都要覆盖，处理方式跟别的多形态问题没有区别。

## 受伤的是转化和品牌感知

影响落在用户进站之后的那几秒。

页面读起来自然不自然，直接决定了他愿不愿意相信这是一家本地经营的店。

汽车配件这类品类尤其吃这一层，因为买错了要退货，用户天然更谨慎。

而信任信号在小语种市场的权重比在英语市场高，这一点在落地页信任信号那一篇 (https://zhangwenbao.com/minor-language-landing-page-trust-signals-payment-address-support.html)里已经量过一次。

所以这件事的正确定位是转化优化，不是流量优化。把它排进关键词项目里会一直排不上号，因为它不产生任何流量预期；把它排进转化优化项目里，它的性价比立刻变得很好看，因为改动成本极低。

汽车配件这个品类还有个额外的敏感点：用户要靠页面上的描述判断这个件跟自己的车匹不匹配，所以他会逐字读规格区。逐字读的时候，语言上的别扭感被放大得比浏览式阅读厉害得多。

## 这是为什么它能活很多年

把上面两条合起来，就能解释为什么这类问题的存活时间特别长。

所有以流量为口径的复盘都看不见它。

所有以转化率为口径的复盘会看到数字偏低，但归因时会先怀疑价格、配送、支付方式这些更显眼的因素。

语言细节排在归因清单的最后面，而清单通常在中间就停了。

保哥的经验是：只伤转化不伤流量的问题，平均存活时间比两头都伤的问题长好几年，不是因为它难修，是因为没有任何一张报表会主动把它推到你面前。

这类问题还有一个共同的特征：它们几乎总是被偶然发现的。不是通过某个流程、某张报表，而是某个人碰巧在某一天注意到了。所以真正的改进不是修好这一次，是把它变成一条会被定期执行的检查。

## 怎么给它估一个能拿去汇报的数

要立项还是得有数字，这里有个可行的办法。

把存在不一致的那几个品牌的页面挑出来，跟没有问题的品牌页做转化率对比。

样本不会很干净，但只要差距稳定存在，方向就够用了。

更省事的做法是直接算改动成本：几十条词、半天工作量、一次发布。

成本低到这个程度的时候，其实不需要精确的收益估算。汇报时把话说成这样就够了：我们花半天时间可以消除全站七个品牌的语言不一致，这件事本身不需要论证收益。

汇报时还有一个角度很好用：把三种写法的截图并排放在一页上。视觉证据在这件事上比任何数字都有效，因为不一致这件事本身就是用眼睛看出来的，不需要懂德语也能一眼看懂。

## 借词的性别有没有可预测的倾向？

## 三条倾向各自都有道理

虽然没有规则，但确实有倾向，而且主要是三条。

第一条看词的形式，词尾长什么样就往哪个性别靠。

第二条看语义，这个东西在本族语里对应的那个词是什么性，借词就跟着它。

第三条看上位词，这个词属于哪个大类，就跟着那个大类的通行性别。

跨语言的类型学调查把性别归属系统大致分成形式型和语义型两类，而德语这样的语言两种机制同时起作用，这就是三条倾向能同时存在的根源。

这三条倾向还有一个共同的局限：它们都是描述性的，是语言学家总结出来的规律，不是使用者遵循的规则。使用者靠的是听过别人怎么说，而这一点没有任何倾向能预测。

## 三条打架的时候没有优先级

麻烦在于这三条经常指向不同的答案。

某个知名的食品品牌就是最常被引用的例子：按词尾像一类，按语义像另一类，按上位词又像第三类。

三条各指一个方向，于是三种冠词在民间同时流通了几十年，至今没有收敛。

而语言里没有任何一条元规则告诉你三条冲突时该听谁的。

这就是为什么这件事不能交给规则引擎处理。三条倾向可以帮你缩小范围、可以帮你解释为什么会有分歧，但它们给不出一个可以自动执行的答案。

说到底这跟颜色范畴那件事有点像：属性枚举值那一篇 (https://zhangwenbao.com/minor-language-color-category-attribute-value.html)讲的是切分位置由语言的历史约定决定，这里是归类结果由历史约定决定。两件事的共同点是交付物都只能是一张要维护的表，而不是一段能跑的逻辑。

## 品牌名比普通借词更不稳定

品牌名在这件事上还有一层额外的不确定。

普通借词至少在原语言里有一个词类和一个含义，三条倾向都有抓手。

品牌名往往是生造的，词尾可能不像任何一类，语义上也没有明确对应。

于是三条倾向里有两条直接失效，只剩上位词这一条勉强能用。

这条推论有个直接的应用：如果你正在为新市场取名，词尾选得像目标语言里某一类词，可以省掉后面所有的麻烦。这属于命名阶段就能解决的事，一旦名字定了再想改就晚了。

还有一种情况会让品牌名更不稳定：品牌名在本地语言里恰好跟某个词读音接近。这时候用户的直觉会被那个词牵着走，而那个词的性别未必是你希望的那个。上线前让本地同事念一遍所有品牌名，这一步成本极低。

## 缩写和字母组合是另一种情况

还有一类要单独说，就是首字母缩写。

缩写的性别通常跟着它展开之后那个核心词走，这一条相当稳定。

但前提是本地用户知道它展开是什么，不知道的话就退回到按词尾猜。

所以同一个缩写在行业内和行业外可能被安上不同的性别。

这一层跟首字母缩略语那一篇 (https://zhangwenbao.com/minor-language-acronym-initialism-local-forms-inflection.html)是连着的：那一篇说的是缩写在小语种里会长出本地形态，这里补的是它还会被安上一个性别，而这个性别取决于受众知不知道它的全称。

缩写还有一个特殊之处：它在书面和口头场景下的展开程度不同。写在页面上的时候读者看得到全称，说出口的时候只有几个字母，于是同一个缩写在两个场景下可能被安上不同的性别，而你的内容要同时服务这两个场景。

## 品牌名这一格该由谁来填？

## 你能定的是写法，定不了的是性别

把品牌名这件事往上抽一层，会看到一个很清楚的分工。

品牌名怎么拼、大小写怎么写、要不要加空格，这些完全在你手里。

品牌名音译那一篇 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)讲的就是这一半：一个名字在市场上长出三种写法之后，你要主动收敛成一种并把另外两种留在匹配层。

而性别这一格不在你手里，它由这门语言的使用者在几年时间里投出来。

两件事的动作方向因此完全相反：写法要收敛，性别只能跟随。把它们写进同一份品牌规范里，最容易犯的错误就是用管写法的方式去管性别，然后规定一个跟民间用法相反的答案。

这条分工还有一个更一般的表述：凡是你能在上线前定死的，属于品牌资产；凡是要在上线后持续观察的，属于市场事实。把两类东西记在同一份文档里是很多混乱的起点，因为它们的复核节奏差了一个数量级。

## 跟地名那件事又不一样

这里值得跟另一个相邻的话题划清界线。

地名本地名与外来名那一篇 (https://zhangwenbao.com/minor-language-place-name-endonym-exonym-search.html)讲的是同一个地方在不同语言里有不同的名字，每门语言各持一份使用权。

那是跨语言的分歧，处理办法是承认多种都对，按市场分别落地。

本文这件事是同一门语言内部还没投完票，处理办法是选一个流通度更高的然后全站统一。

一个要发散，一个要收敛，两者最容易被混为一谈的地方在于它们都表现为一个东西有好几种说法。判断办法很简单：分歧发生在语言之间还是语言内部。

这条界线还能推广到别的场合。同一个东西有多种说法时，先问分歧发生在哪一层：跨语言的要发散，语言内部的要收敛，同一个人不同时候的要统一。三种情形的处理动作完全不同，而它们在表面上长得一模一样。

## 标注的责任应该落在数据这一侧

定下来之后，这个结论应该存在哪里。

最稳的位置是商品数据里的一个字段，跟品牌名存在一起。

存在文案规范文档里的问题是没人会去看，存在写手脑子里的问题是换人就丢。

存进数据字段之后，模板可以直接取用，写手也可以在编辑器里看到。

这一步还有个附带的好处：字段一旦存在，它就有了负责人和变更记录。谁在什么时候把某个品牌从一个性别改到另一个，这件事从此有据可查，而不是变成一场每年重来一次的口头争论。

字段这件事还有一个附带价值：它让这个结论可以被下游系统消费。商品数据要同步给比价平台、广告平台和渠道商，字段里有值它们才拿得到，写在文档里的结论走不出你的团队。

## 什么时候该改主意

定了之后并不是永远不动。

触发改动的信号主要有两个：本地媒体的写法出现明显偏移，或者用户生成内容里另一种写法占了上风。

第二个信号更可靠，因为它离你的真实买家更近。

复核频率不用高，一年一次足够，这类变化以数年为单位。

这一点跟代际用词那一篇 (https://zhangwenbao.com/minor-language-generational-vocabulary-older-buyers.html)提出的保质期字段是同一套做法：不会有任何机构发公告通知你该改了，你只能主动排一次日历，而排日历这件事只要写进词表就不会被忘掉。

改主意的时候有个操作建议：把旧写法保留在站内搜索的同义词表里，别一起删掉。用户的习惯改得比页面慢，留着旧写法几乎没有成本，删掉却会让一批老用户搜不到。

## 法语、俄语、荷兰语的情况一样吗？

## 法语只有两个性，冲突反而更尖锐

法语只区分阴阳两性，没有中性这个缓冲区。

性别数量越少，两个选项之间的对立就越直接，中间地带也越少。

而且法语的形容词和过去分词都要跟着变，连锁范围不比德语小。

好在法语的借词性别倾向里，词尾这一条比德语更强势，可预测性稍好一些。

做法语站时可以先按词尾猜一个，再去语料里验一遍，命中率通常不低。这个顺序在德语上就行不通，因为德语三条倾向的强度更接近。

法语这边还有一个额外的复杂度：过去分词在某些结构里也要跟着变，而那些结构在商品描述里出现得相当频繁。所以法语站上这个判断的连锁面比德语宽，只是每一处的差异更小、更难被发现。

## 俄语的性别还牵着变格走

俄语的情况更复杂一层。

性别不只影响修饰语，它还决定这个名词走哪一套变格。

选错性别等于选错整张词尾表，影响面比德语大得多。

不过俄语有个缓解因素：很多外来词干脆不变格，绕开了整张表。

判断一个外来词在俄语里变不变格，看它的结尾是不是符合本族词的形态模式。不符合的多半不变，这条经验跟俄语变格那一篇 (https://zhangwenbao.com/russian-seo-cyrillic-cases-declension-wordstat-keyword.html)里讲的形态判断是同一条线索。

俄语还有一个实操上的提醒：品牌名如果被本地人当成可变格的词处理，那它的性别会同时决定变格表和修饰语形态，两条线一起错。这时候排查要从变格形态入手，因为那一层的差异在字符串上更明显。

## 荷兰语的两性合并留下了历史包袱

荷兰语提供了第四种样本。

它历史上的阴阳两性在实际使用中已经合并成一类，只跟中性对立。

结果是冠词层面只剩两个选项，但代词回指那一层仍然保留着旧的三分。

于是同一个词，冠词好定，代词难定，两层的判断依据不一样。

做荷兰语站时要把这两层分开处理，别指望定了冠词代词就自动跟着对。这也是荷兰语与佛兰芒市场那一篇 (https://zhangwenbao.com/dutch-seo-netherlands-belgium-flemish-two-markets.html)里提到的那类差异之一，两个市场在这一层上的习惯还不完全一致。

荷兰语的这种两层不同步还有一个衍生问题：写作规范和口语习惯在代词这一层的差距特别大，规范推荐的写法在日常对话里几乎听不到。做面向消费者的文案时，跟着口语走通常更安全。

## 没有性别的语言反而要注意别的事

最后说一句反面。

芬兰语、土耳其语、日语这些语言没有语法性别，本文这一整套完全用不上。

但它们把复杂度放在了别处，比如后缀链和敬语层级。

所以做多语言站时，这一项检查应该只在需要的语言上跑，不必做成全局清单里的一条。

把不适用的检查项塞进全局清单是很多本地化流程臃肿的起点，每门语言只跑它真正会踩的那几项，清单才有人愿意执行。

这条提醒还可以反过来用：给每门语言维护一张适用检查项的清单，新开市场时先勾选适用项。这份清单本身就是本地化经验的沉淀，比一份所有语言共用的通用清单有用得多。

## 页面上哪些位置必须统一，哪些位置可以两可？

## 模板与结构化数据必须统一

必须统一的位置有一个共同特征：它们是机器批量产出的。

商品标题模板、分类页描述、结构化数据的名称与描述字段，这几处一处定错就是成千上万页。

所以这几处应该直接读商品数据里的那个字段，而不是让写手每次现判断。

这一步做完，全站绝大部分的出现次数就已经统一了。

值得单独提醒的是结构化数据这一处的修复周期最长，改完要等重新抓取和重新处理，所以它应该排在改动清单的最前面而不是最后面。

还有一个位置容易被漏掉，就是站内搜索结果页上的商品标题。那一处的文本通常来自另一套模板，跟商品页的模板不是同一份代码，改的时候要单独确认一遍。

## 正文里出现一次不同不算事故

正文的要求可以宽一些。

一篇长文里偶尔出现一次另一种写法，本地读者基本不会注意到。

把正文也管到滴水不漏，需要付出的校对成本跟收益不成比例。

合理的做法是给写手一份品牌性别对照表，写的时候能对上就对上。

要盯紧的只有一种情况：同一篇文章内部前后不一致。这一条可以写成一句很简单的自查，也可以让编辑器做一次简单的比对，成本几乎为零。

正文这一层还可以借力工具：把品牌名和它的性别做成编辑器里的自动提示，写手打到这个词的时候直接看见。这比事后校对便宜得多，也比要求他记住一份对照表现实得多。

## 用户生成内容一律不动

评论、问答、晒单这些内容不在管辖范围内。

用户怎么写就怎么留着，那是最真实的用法样本。

而且这批内容恰恰是你判断风向的数据来源，改了等于把温度计砸了。

需要做的只是定期统计一下里面两种写法的比例。

这条原则跟本站好几篇的结论一致：用户生成内容既不受你的规范约束，也不应该受，它的价值就在于没有被编辑加工过。

统计用户生成内容的时候有个技巧：按时间分段统计，看比例有没有在移动。静态的比例只告诉你现状，移动的方向才告诉你该不该准备改主意。

## 广告素材要单独确认一遍

还有一个容易漏的位置是投放素材。

广告文案通常由另一拨人做，甚至由代理商做，他们拿不到你的品牌数据字段。

于是站上统一了，广告里还是三种写法。

而广告是很多用户第一次见到这个品牌名的地方，第一印象的权重更高。

把那张对照表同步给投放方是个五分钟的动作，但它经常被漏掉，因为品牌规范的分发范围通常只覆盖内部。

投放素材还有一层风险：广告平台的动态创意会自动拼接文案片段，拼出来的句子没有人逐条看过。用了这类功能的账户，最好把品牌名相关的片段单独锁定，不参与自动组合。

## 一套半天能定下来的品牌性别决策流程

## 第一步，圈出需要处理的全集

先确定范围，别一上来就查。

全集等于所有品牌名，加上词表里最近十年才出现的那批词。

老词不用管，它们的性别早就定了，词典里查一次就行。

这一步做完通常剩下几十条，工作量立刻可控。

圈范围的时候可以顺手把型号和纯字母组合排除掉，那一类在句子里通常不带冠词，也就不会踩到这个问题。

另外提醒一句，代理品牌和自有品牌要分开处理。代理品牌在本地市场往往已经流通多年，性别早就定了，照抄现状即可；自有品牌才是真正需要你做判断的那一批，而它们通常也是页面数量最多的那一批。

## 第二步，查词典和语料拿到现状

逐条去查，两个来源就够。

词典看它收了几个答案，收一个就照着用，收两个就进下一步。

语料看两种写法各自的流通情况，取更常见的那个。

整个过程是机械的，交给任何一个会用浏览器的人都能做。

需要留意的是查语料时把品牌名和冠词一起查，单查品牌名拿不到任何有用的分布，因为字符串在两种情况下完全一样。

查的时候建议把结果连同来源一起记下来，别只记结论。半年后有人提出异议时，一条带来源的记录能在两分钟内结束讨论，而一个孤零零的结论只会引发第二轮争论。

## 第三步，拿不准的交给本地用户来判

还剩几条实在拿不准的，别自己拍板。

最好的判据来自你自己的用户生成内容，统计一下评论里两种写法的比例。

没有足够的评论就去本地论坛和社交平台看同行怎么写。

实在还是对半开的，选一个然后记录下来，重要的是全站统一而不是选对。

这一点值得说明白：在两种写法都合法且流通度接近的情况下，统一带来的收益远大于选对带来的收益，因为不一致是唯一会被读者察觉的那个问题。

本地用户这一侧还有个免费的数据源：客服的聊天记录。用户在跟客服打字的时候完全不设防，写出来的是最自然的形态，而且这批数据通常没有任何人从语言角度看过。

## 第四步，落进数据字段并同步出去

最后一步是分发。

结论写进商品数据的品牌字段，模板改成读这个字段。

同一份对照表同步给写手、投放方和代理商。

在词表里给这个字段加一列复核日期，一年一次。

做完这四步，这件事就从一个每次都要重新讨论的问题变成了一条可以查的记录。而这类语言问题的最终解法几乎都是这样：不是找到正确答案，是让答案有个固定的存放位置。

分发这一步还有个容易漏的对象是翻译供应商。他们手里往往有自己的术语库，如果不同步，下一批交付回来的稿子又会带上另一种写法，前面做的统一等于白做一轮。

分发完之后建议留一个可以随时查的位置，比如内部知识库里的一张单页表格。这件事最容易发生的退化不是有人写错，而是新来的人根本不知道有过这个决定，于是又按自己的语感开始写。

## 哪些事不归这一层管

## 性数一致的执行不在这篇里

这篇只解决一件事：这个词的性别取值该填什么。

填进去之后形容词该怎么变、模板该怎么算，那是执行层的事。

那部分在意大利语性数一致那一篇 (https://zhangwenbao.com/italian-seo-gender-agreement-elision-keyword-research.html)和多语言模板那一篇里都讲过。

两件事的先后顺序不能反：取值没定的时候去优化执行，等于把一个错误算得更准。

混着谈的常见后果是团队花了很大力气去做模板的形态计算，而输入里那几个品牌的性别始终是错的。

顺序反了还有个更隐蔽的后果：模板的形态计算做得越精细，错误的性别产生的不一致就越整齐，整齐到看起来像是有意为之，反而更不容易被怀疑。

## 包容写法是另一条线

德语站上还有另一个跟性别有关的话题，就是指人名词的包容写法。

那件事讨论的是同一个概念要不要覆盖两种性别的人，属于社会语言层面的选择。

包容写法那一篇 (https://zhangwenbao.com/minor-language-gender-inclusive-spelling-keyword-coverage.html)的结论是正文里已经铺开而搜索框里的采纳率是零。

本文说的是名词本身归哪个语法性，跟指的人是男是女没有关系，一把椅子也有性别。

两件事共用性别这个词，讨论时最容易串线。分开的办法是问一句：这件事涉及的是人还是物。涉及人的归那一篇，涉及物的归这一篇。

两件事还有一个实际的交集：指人的职位名词既涉及包容写法，也涉及语法性别，两条规则会在同一个词上同时生效。碰到这类词时按包容写法那一篇的位置分区先定，再在选定的形态上应用本文的一致性要求。

## 引擎那一半交给平台层

最后照例还有一半功课不在语言这一层。

搜索引擎会不会把带不同冠词的短语当成同一个查询，这属于引擎的行为。

本站把引擎那一半放在平台与多引擎那个方向里单独讲，这篇不展开。

好在本文这件事跟引擎行为的关系比别的语言问题都小，因为它几乎不发生在查询侧。

这也是它值得单独立项的理由：它的收益不依赖任何外部系统的行为，改完就生效，唯一的变量是你自己的页面。

这一点也让本文的验收变得特别简单：不需要等抓取、不需要等排名、不需要等任何外部系统的反应，改完刷新页面就能确认。这在语言层的改动里是很少见的待遇。

## 常见问题解答

## 不懂德语，怎么自己查一个品牌名该用哪个冠词？

有一条基本不需要语言能力的路径。先在德语的数字词典项目里查这个词，如果它收了唯一一个答案，照抄就行。收了两个答案的进下一步：把三种冠词分别加在品牌名前面组成短语，逐个丢进搜索引擎看结果数量，再去本地社交平台各搜一遍看真实用法。数量差一个数量级以上的直接定档，接近的就取用户生成内容里更常见的那一个。整个过程你需要的只是复制粘贴和比较数字。

要提醒的是搜索结果数不能当精确数据用，它只用来判断量级，别拿它做小差距的比较。另外品牌名如果跟某个普通词撞了，结果里会混进大量不相干的页面，这种情况要加一个品类词把范围收窄。另外提醒一句，搜索结果数量在不同地区和不同登录状态下会有差别，比较的时候要在同一个环境里跑完全部候选，别今天查一个明天查一个。

## 三种写法都有人用，选哪个的收益差别大吗？

差别比想象中小，因为这件事的收益主要来自统一而不是来自选对。三种写法都合法的前提下，读者不会因为你选了流通度第二的那个而觉得不对，他只会因为同一个站里出现三种而觉得不专业。所以决策时不必反复权衡，取流通度更高的那个然后全站执行到底就可以。真正需要慎重的是后面改主意这件事，改一次要动模板、结构化数据、广告素材和历史内容，成本比第一次定下来高好几倍。

所以第一次定的时候把依据记下来，下次有人提出异议时可以直接看记录，而不是重新吵一遍。如果实在有分歧，让本地同事投个票，然后把票数一起记进去。还有一点值得记住：统一之后如果有人提出应该用另一种，讨论的成本已经从选哪个变成了值不值得改，后者比前者好收敛得多。

## 只改模板不改历史内容，行不行？

可以，而且这是投入产出比最好的起步方案。模板和结构化数据覆盖了绝大部分的出现次数，改这两处的成本是一次性的，效果是全站的。历史正文里的零星不一致对读者的影响小得多，可以放着慢慢改，或者在下次内容更新时顺手处理。唯一建议优先处理的历史内容是流量最高的那十来个页面，那些页面的曝光量决定了它们的影响面。

另外提醒一句，改模板之前先确认商品数据里那个字段已经填好了，字段是空的时候模板会按默认值输出，而默认值通常就是当初写死的那一个，等于什么都没改。另外一个提醒是历史内容里如果有大量结构化数据，那部分要跟着模板一起改，否则页面上统一了而机器读到的还是旧值。

## 这件事跟包容写法是不是同一个问题？

不是，两者只是共用了性别这个词。包容写法讨论的是指人的名词要不要同时覆盖男性和女性，属于社会层面的表达选择，它的核心矛盾是正文里已经普及而搜索框里没人用。本文讨论的是任何一个名词在语法上归哪一类，跟它指的东西是不是人完全无关，一个刹车片也有性别。两件事的落地位置也不同，包容写法主要影响正文和标题的措辞，语法性别主要影响冠词和形容词词尾。

分辨的办法是问一句这件事涉及的是人还是物。如果团队里经常有人把两者混着谈，建议在文档里给它们各起一个不含性别二字的内部叫法，能省掉很多无谓的讨论。如果实在分不清，可以看这个词指的东西能不能被雇佣，能的归包容写法那一篇，不能的归这一篇，这个土办法几乎不会错。

## 新品牌上线时能不能提前避开这个问题？

能，而且这是唯一一个可以在源头解决的环节。取名阶段如果把词尾设计成目标语言里某一类词的常见形式，本地用户的直觉会高度一致，三条分配倾向不会打架，性别自然就定了。这件事的成本几乎为零，前提是取名的时候有人想到要问一句这个名字在德语里读起来像什么类型的词。可惜大多数命名流程只考虑发音好不好听、商标能不能注册、域名有没有被占，语言归类这一项从来不在清单上。

如果你所在的公司还有新品牌要推，把这一条加进命名评审清单里，是本文里投入产出比最高的一个动作。另外提醒一句，命名评审时问的不该是这个名字在德语里是什么性，而该是本地同事第一反应会给它配哪个冠词，前者没有答案，后者有。

## 怎么让写手真的按对照表来写？

别指望文档，把它放进他每天都会打开的地方。最有效的做法是在内容管理系统的编辑界面上，把品牌名和它的性别一起显示出来，写手写到那个词的时候一眼就能看见。次一级的做法是做一个简单的检查规则，提交时扫一遍看有没有用错的冠词，命中就提示一下。这两个动作的共同点是把规范放在动作发生的那一刻，而不是放在一份需要主动去查的文档里。

经验上，任何需要写手主动去查的规范，执行率都会随着时间衰减，而嵌进工具里的规则不会。如果两个都做不到，退一步至少把对照表贴在写作模板的顶部，让它跟着稿子一起走。还有一个很轻的做法是把对照表做成一张图片贴在团队的常用文档首页，图片不会被折叠，也不需要点开链接，命中率比纯文字链接高不少。

## 这批词的性别多久会变一次？

变化很慢，以数年为单位，所以一年复核一次完全够用。真正需要留意的不是老词的漂移，是新词的加入：每年新增的品牌、新引进的品类词，都要在上线时跑一次这个流程。复核的动作很轻，重新查一遍语料分布，看那几个原本对半开的词有没有明显偏向某一边。另外有一个信号值得盯，就是本地媒体和行业刊物的写法，它们通常比大众用法先一步收敛。

建议把复核安排在每年做词表维护的时候一起做，两件事的数据来源重叠度很高，合并起来几乎不增加额外工时。另外建议把每次复核的结论和当时看到的分布一起存档，几年下来这份档案本身就变成了判断这个词有没有在移动的最好依据。



## 翻译报价单上写着四万字，页面上真正被人读的那几十个词一个都不在里面

- URL：https://zhangwenbao.com/minor-language-hardcoded-ui-strings-pseudo-localization.html
- 分类：小语种SEO
- 发布：2025-04-15  |  更新：2026-07-30
- 摘要：按钮、筛选器、报错提示上的英文不是没人翻，是它们从没进过翻译文件。讲清抽取这道工序在做什么、缺口为什么在报价那一刻就不可见、回退机制怎么让缺译毫无信号，以及怎么两天查一遍。
- 关键词：技术SEO,多语言SEO,内容本地化,小语种SEO

> **TLDR**：摘要：页面上的字分两类：进过翻译文件的，和写死在代码里的。前一类按字数计价、有交付物、有验收；后一类从没被交出去过，所以它在荷兰语页面上永远还是英文。这批字只有几十到几百个，位置却极好——按钮、筛选器、面包屑、空结果提示、发货邮件，正是页面上文本最少也最被人读的地方。更麻烦的是缺口在报价那一刻就不可见：字数统计只数得到已抽出来的那部分。本文讲清抽取这道工序在做什么、哪五类位置最容易漏、怎么用伪本地化在一句译文都没有时先测一遍，以及上线三年的老站按什么顺序补。

> 摘要：页面上的字分两类：进过翻译文件的，和写死在代码里的。前一类按字数计价、有交付物、有验收；后一类从没被交出去过，所以它在荷兰语页面上永远还是英文。这批字只有几十到几百个，位置却极好——按钮、筛选器、面包屑、空结果提示、发货邮件，正是页面上文本最少也最被人读的地方。更麻烦的是缺口在报价那一刻就不可见：字数统计只数得到已抽出来的那部分。本文讲清抽取这道工序在做什么、哪五类位置最容易漏、怎么用伪本地化在一句译文都没有时先测一遍，以及上线三年的老站按什么顺序补。

## 同一个页面上，为什么有的字翻了、有的字没翻？

## 一家母婴站的荷兰语页面，八个词出卖了整个站

有个客户做母婴用品，婴儿推车、安全座椅、背带、辅食工具这几类。

荷兰语站上线半年，内容侧的活儿做得相当扎实：品类页、商品页、指南文章全是本地写手产出的。

转化率却一直卡在同类市场的六成，团队查了支付、查了物流、查了价格，都没找出原因。

保哥拿手机打开那个站，第一屏还没滑完就停住了。

正文是荷兰语没错，可商品图下面那排筛选按钮写着Sort by、Filter、In stock、Sold out，购物车按钮写着Add to cart，页脚的面包屑写着Home。

整整八个词，全站每一页都有，全是英文。团队里没有一个人觉得这是问题，因为这些词在他们的内容管理后台里根本不存在——后台的文章列表里躺着三百多篇荷兰语稿子，一个字都不缺。这八个词住在另一个地方，一个内容团队从来不会打开的地方。

## 差别不在译员，在这些字根本没被交出去

追下去只用了二十分钟。

翻译供应商交付的是一批文档和一份界面词条表，词条表里有一百四十条。

而前端模板里真正写着的英文短语，数一数是一百九十多条。

中间那五十多条从来没出现在任何一份交付清单上，因为它们从来没被抽出来过。

它们直接写在模板文件里，跟结构标签混在一行，形态大概是一个标签中间夹着一个单词。

译员没有漏翻，供应商没有偷工，项目经理也没有失职。这批词在整条链路上是不可见的：它不在需要翻译的文件里，所以没人报价；不在交付物里，所以没人验收；不在内容管理后台里，所以没人复核。三方各自都完成了自己那一份工作，缺口出现在三份工作中间的缝里。

## 页面上的字其实分两类，只有一类进过流程

这件事的根子在于一个多数人没意识到的分界。

页面上呈现给用户的每一个字，来源只有两种。

一种是内容，存在数据库里，由编辑写、由译员翻、由内容管理系统吐出来。

另一种是界面文案，存在代码里，由工程师写、由构建流程处理、由前端渲染出来。

用户看不出这两类字有什么区别，它们在同一个页面上、同一种字体、同一个颜色。

可这两类字走的是两条完全不相交的管道，两条管道有各自的负责人、各自的工具、各自的排期。内容那条管道成熟得不像话，从选题到发布每一步都有人盯；界面文案那条管道在多数团队里压根没有本地化这个环节，它的默认终点就是英语。这条分界线才是本文真正要讲的东西，后面所有的现象都是它的推论。

## 这件事跟翻译质量无关，它发生在翻译之前

为什么这个问题在讨论多语言内容的场合几乎从来没被提起。

因为绝大多数关于多语言的讨论，前提是已经有一份要翻的东西了。

讨论的是翻得准不准、地不地道、要不要用机器、要不要请母语者复核。

而这批词的问题发生在更早一步：它压根没进入被讨论的那个集合。

你可以把翻译质量做到满分，这批词还是英文。

顺着这条线还能推出一条更不舒服的结论：本地化的完成度并不是由译者的水平决定的，而是由三年前那个写模板的前端决定的——他当时随手把一个词写在了标签里还是写成了一个变量，就已经决定了这个词今天能不能出现在荷兰语页面上。这个决定当时不需要任何评审，也没有任何人会知道。

## 一句话从代码里被抽出来，中间要过几道关？

## 抽取这道工序到底在做什么

先把这道工序说清楚，因为多数内容岗的人没见过它。

原始状态下，一句用户能看到的话是直接写在代码里的。

抽取的意思是：把这句话从代码里拿走，换成一个引用。

代码里留下的是一个键名，真正的文字挪到一个专门的资源文件里。

资源文件按语言各存一份，运行的时候按当前语言取对应那份。

这套办法有个官方叫法，工程侧叫国际化，通常缩写成首尾两个字母加中间的字母数。这个动作和后面的翻译动作是分开的两件事：前者是让文字可以被替换，后者才是真的替换。国际化组织在自己的问答文档里把这两件事的边界写得很清楚，把它们混为一谈是这个领域最常见的一个错误，本地化与国际化的区别 (https://w3c.github.io/i18n-drafts/questions/qa-i18n.en)那篇专门解释了为什么必须先做前者。

## 抽出来之后它变成了什么形态

抽出来的文字会落在一个文件里，格式取决于技术栈。

用得最久的一种是每条一个原文一个译文，原文那行叫msgid，译文那行叫msgstr。

还有一种是键值对，左边是自定义的键名，右边是要显示的文字。

移动端有各自的形态，一边是扩展名strings的文件，一边是strings.xml。

行业里做交换用的是另一套标准格式，翻译公司的工具基本都认。

不管哪种形态，共同点是这批文字终于变成了一份可以被清点、被计价、被发出去的资产。这一步之前它是代码的一部分，之后它才是内容。整个问题的分水岭就在这里：抽出来的东西会被当成内容对待，没抽出来的会被当成代码对待，而代码是不需要翻译的。

## 谁决定哪句话要被抽出来

决定权在写这行代码的那个人手上，而且是当场决定的。

他写一个按钮的时候，可以顺手把文字写进去，也可以调一次翻译函数。

前者快，一秒钟的事；后者慢，要起键名、要去资源文件里加一条。

在一个只做英文站的阶段，两种写法看起来完全一样，页面上长得一模一样。

于是绝大多数团队在早期都选了快的那种，而且选得毫无心理负担。

等到两年后要出海了，这个决定的代价才开始结算，而且结算方式很别扭：它不是一笔大账，而是散落在几百个文件里的几百个小坑。谷歌的gettext手册专门有一节叫准备字符串 (https://www.gnu.org/software/gettext/manual/html_node/Preparing-Strings.html)，讲的就是写代码那一刻该怎么写才不留坑，可惜看这份手册的人和写商品页模板的人通常不是同一批。

## 抽漏了不会报错，这是问题的根源

软件工程里绝大多数错误都有一个共同的好处：它会报错。

拼错一个变量名，程序跑不起来；少一个括号，构建过不去。

唯独这一类不会。一句写死在代码里的英文，在任何语言下都能正常显示。

页面不会崩，测试不会红，监控不会响，用户也不会去投诉。

它唯一的表现形式，是一个荷兰人打开你的站，看见一个英文按钮。

这条性质决定了它必须靠主动去查，而不能等它自己冒出来。跟前端为了让德语长词不撑破手机屏幕塞进标题的那个看不见的字符 (https://zhangwenbao.com/minor-language-line-break-soft-hyphen-invisible-character.html)属于同一族：都是在正常渲染下完全无害、只在某一门语言的某一条链路上才致命的东西。区别是那个字符至少还能用工具扫出来，这批词连扫都不知道该扫什么。

还有一种更隐蔽的情形，它连抽取这一关都过了。资源文件里某一条在英语那份有、在荷兰语那份缺，运行时框架不会报错，而是静默回退到默认语言。页面上照样显示，显示的是英文。这条回退机制是所有主流框架的默认行为，它的设计初衷是宁可显示点什么也别显示空白，代价是缺译这件事从此没有任何可见信号。

这条机制推出一个反直觉的结论：抽取率高不等于本地化覆盖率高。一个抽取率百分之百的站，如果译文文件里缺了三十条，页面上照样有三十处英文，而且这三十处比没抽出来的那批更难查——它们在资源文件里有键、有原文、只是没有译文，任何按键名清点的检查都会把它们算成已存在。

## 哪些位置最容易漏，能不能列成一张固定清单？

## 第一类：按钮、标签与状态词

这一类最常见，也最容易被外人一眼看穿。

典型的有加入购物车、立即购买、排序、筛选、清空、返回、下一页。

状态词是同一族：有货、缺货、售罄、预售、新品、促销中。

它们的共同特征是短，一到三个词，写在代码里几乎没有心理负担。

也正因为短，它们在页面上的密度极高，一个商品列表页能出现几十次。

这一类词有个附加的坏处：它们往往同时是用户会搜的词。缺货、现货、包邮这类词在很多小语种市场里是带搜索量的修饰词，页面上写成英文等于把这一层长尾整个让出去。落地页上那几个最像装饰的信任元素其实是搜索量最高的购买词 (https://zhangwenbao.com/minor-language-landing-page-trust-signals-payment-address-support.html)讲过同一个道理的另一半。

## 第二类：只在出错时才出现的句子

这一类的漏检率最高，原因很朴素：日常测试根本走不到。

包括表单填错的提示、搜索没有结果的提示、支付失败的提示。

还有找不到页面时的那一页、系统维护时的那一页、权限不足时的那一页。

它们的出现频率低，可出现的那一刻恰好是用户最焦虑、最容易放弃的一刻。

一个荷兰用户在结账时看到一句英文报错，他的第一反应不是读懂它，是关掉。

这一类还有一个结构性的尴尬：出错这件事本身是最不能本地化的时刻，因为报错文案通常离业务逻辑最近、离内容团队最远，写它的人考虑的是把状态说清楚而不是把话说得让人能读。于是同一批文案在两个维度上同时欠着账：信息量不够，语言这一关也没过。两笔账里，语言这一笔更容易还，也更该先还。

这一类里最难啃的一小块来自第三方：支付网关返回的错误提示、物流查询组件的状态文案、验证码服务的提示语。它们既不在你的模板里也不在你的资源文件里，是别人的系统吐给用户看的。多数服务商提供语言参数，但需要你在调用时显式传，不传就走它自己的默认值，而那个默认值通常是英语。

检查办法很直接：把结账流程走到失败一次，把每一个第三方组件的提示都截下来。这一步值得单独排一个小时，因为它是整条链路上唯一一处出问题时页面还得替别人的系统说话的地方，而这几句话恰好出现在用户已经掏出银行卡的那一刻。

## 第三类：拼在一起的半句话

这一类隐蔽得多，因为它看上去已经被抽出来了。

页面上显示的是一句完整的话，比如还剩三件、七天内可退。

可代码里它是三段拼的：一个前半句，一个数字变量，一个后半句。

抽出来的是那两个半句，各自独立成条，进了资源文件。

译员拿到的是两个残句，既不知道它们会被拼在一起，也不知道中间夹着什么。

后果在下一节细讲，这里只强调一点：这一类在字数统计里是合规的，在交付清单里是齐全的，在验收时也挑不出毛病——每一条都翻了。坏掉的是拼起来那一刻，而拼起来这件事没有任何一份交付物记录过。

## 第四类：不是文字但要读的东西

这一类严格说不算字符串，可用户读到的效果一样。

包括图片上烧进去的那行字，尤其是横幅图和尺寸对照图。

包括日期的写法、货币符号的位置、小数点用点还是用逗号。

包括度量单位，以及数字的分组符号。

这些东西写死在代码里的概率极高，因为它们看起来根本不像文字。

可它们全都是按语言变的。国际化组织维护的那套地区数据里，光是日期与数字的格式就按语言列了几千条，地区数据总览图表 (https://cldr.unicode.org/index/charts)可以直接翻到自己那门语言那一页。图片上烧字这件事另有一笔账，非拉丁字母站上同一张商品图的文件名和替代文本要用两套字母写同一个词 (https://zhangwenbao.com/minor-language-image-alt-text-non-latin-script-search.html)那篇算过一张图的复用面被上面的字砍掉多少。

图片上烧字这件事有一条很实用的判据：这张图要在几门语言下复用，就别把任何一个会随语言变的信息烧上去。价格、促销文案、尺码标签、功能说明全归这一类。真要放，把文字层单独留出来用页面元素叠上去，这样换语言只换文本不换图。这一条决定的不只是本地化成本，还有这张图能不能被搜到——烧在像素里的字，检索这一侧读不到一个。

## 第五类：走另一条管道出去的字

最后一类干脆不在页面上，可它同样是你发给用户的内容。

订单确认邮件、发货通知、退款通知、验证码短信、推送消息。

这些模板通常住在另一个系统里，可能是营销工具，也可能直接在订单系统里。

它们跟站点的语言资源文件是两套东西，两套东西各自漏各自的。

而这一类的阅读率高得离谱，订单确认邮件的打开率在多数品类里超过五成。

换句话说，一个用户可能全程没读完你精心本地化的商品页，却一定会逐字读完那封发货邮件。把这批模板漏在英文里，等于在整条链路上唯一一次用户必读的位置露了怯。这批模板还有一个特点：它们通常由运营而不是工程维护，所以连前面那份抽取率的账都算不到它们头上。

这一类还有一个附带的伤：即使运营认真把邮件模板译了，用的词也未必跟站上一致。站上的按钮叫一个词，发货邮件里叫另一个词，退款政策页上叫第三个词。用户不会觉得这是三套系统，只会觉得这家店说话前后不一致。把邮件模板里的品类词、状态词跟站内词表对一遍，通常一个下午就能捋顺，收益是整条售后沟通的用词统一。

## 报价单上的字数，为什么天生看不见这批词？

## 字数统计只数得到已经被抽出来的字

本地化项目的报价方式几乎是行业统一的：按源语言字数或者词数计价。

字数从哪儿来？从你交出去的那批文件里统计出来。

翻译工具打开一份资源文件，逐条数，给出一个总数。

没被抽出来的那批词不在文件里，工具当然数不到。

于是报价单上写着四万字，而页面上真正露出来的那几十个词一个都不在里面。

这条性质值得单独记一下，因为它比其它任何一条都更能解释这个问题为什么能存活这么久：缺口在报价那一刻就已经是不可见的，而报价是整个项目里第一次有人认真清点内容的时刻。第一次清点就漏了，后面每一次核对都是拿这份漏了的清单当基准。

## 报价那一刻缺口就已经不可见

再往下一层，这个机制还有个自我强化的部分。

甲方看到报价单上的字数，会拿它跟预算比，跟上一次比。

字数少了会被追问，字数多了会被砍。

没有任何一个环节会问：这个数字覆盖了页面上百分之多少的字。

因为这个问题的答案需要另一份数据，而那份数据谁都没有。

保哥后来在几个项目里试过一个很土的办法：让人拿手机把一个语言版本的关键页面挨个截图，把截图里所有出现的英文词圈出来，再拿这个数跟资源文件里的条数做个比。这个动作不需要任何工具，一个下午能做完三十个页面，得到的数字比任何报表都直观。

## 验收也查不出来，因为验收对着的是同一份清单

验收环节按理说是最后一道闸。

可验收的做法是：拿交付文件对着原文件，逐条核。

核的是这一百四十条翻得对不对，不是核这一百四十条够不够。

清单本身的完整性从来没有人验，因为清单就是这件事的定义。

这跟母语者说读着自然不能当成验收通过的判据 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)是一对孪生问题：那一篇讲的是验收的深度不够，这一篇讲的是验收的范围不对。

两者合起来是一个更普遍的规律：所有以清单为工作对象的流程，都无法发现清单本身的缺项。要发现缺项只能换一个参照物，而在这件事上唯一可靠的参照物是渲染出来的页面本身，不是任何一份文件。

## 那几十个词在检索这一侧值多少钱？

## 它们恰好落在页面文本最少的地方

如果这批词散落在长篇文章里，问题会小很多。

可它们的分布正好相反：越是文字少的页面，它们的占比越高。

一个筛选结果页，正文可能只有一个标题加一排商品名。

剩下的可见文字全是筛选项、排序选项、分页控件和状态标签。

这类页面上界面文案的占比能超过一半，有时候能到七成。

而这类页面恰恰是电商站里数量最多、也最贴近交易意图的一层。站上字最少的那几类页面最赚钱，也最容易被机器认成另一门语言 (https://zhangwenbao.com/minor-language-page-language-detection-misidentification-short-text.html)那篇算过这层页面的价值，这里要补的是：它们的语言纯度也是全站最低的。

## 它们会把这一页的语言证据拉偏

接着上面那条往下推一步。

机器判断一个页面是哪门语言，靠的是页面上的实际文本。

页面上的语言声明是一个信号，但不是唯一的、也不是最重的那个。

当一个荷兰语页面上有四成可见文字是英文，判定就会变得不稳定。

不稳定的后果不是判成英语，而是判定结果在同类页面之间来回摇摆。

摇摆比判错更难查，因为你抽查十个页面可能有七个是对的。真正的信号藏在那三个上，而它们跟另外七个在模板上是同一份。这类问题在报表上的表现是某一批页面的表现莫名其妙低于同批的其它页面，而根因在字符层面，不在内容层面。

有个不用任何工具就能验的办法：把一个筛选结果页的可见文本全选复制，粘进纯文本编辑器，把明显是本地语言的词删掉，看剩下多少。剩下的比例超过三成，这一页的语言证据就已经不干净了。这个动作三分钟能做完一个页面模板，而同一个模板通常覆盖几千个页面，性价比高得离谱。

## 用户搜的是本地词，页面上写的是英文词

第三笔账落在关键词覆盖上。

界面词里有相当一部分同时是查询词的组成部分。

免运费、货到付款、七天无理由、当日发货，这些在多数市场都带量。

它们写在按钮上、写在角标上、写在筛选项里，全是界面文案的地盘。

页面上留着英文，等于这几组长尾在这门语言下一个字都接不住。

这里跟关键词表里唯一一批全英文的词从翻译到审校没有一个人动过 (https://zhangwenbao.com/minor-language-acronym-initialism-local-forms-inflection.html)那篇是两条平行线：那篇讲的是词表里留了英文，这篇讲的是页面上留了英文。两者的成因不一样，一个是人主动决定不译，一个是流程压根没碰到；后果却完全一致。

## 结构化数据与可见文本不一致时会怎样

还有一个位置容易被忽略：标记里的值。

库存状态、配送方式、商品状况这些字段，标记里填的是标准化的英文值。

这是对的，标记里的枚举值本来就该用规范值，不该本地化。

问题是页面上的可见文字应该是本地语言的，两者要分开处理。

而写死在代码里的那批词恰好让这两层变成了同一层：标记是英文，页面也是英文。

小语种页面的正文越本地化越好，结构化数据里却要反着写回国际格式 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)讲的就是这两层该怎么分。这里要补的是一种特殊情形：当界面文案没被抽出来时，你并不是做对了标记那一层，而是两层都停在了默认值上——看起来符合规范，实际上是没做。

## 不懂那门语言，怎么在一句译文都没有的时候先测一遍？

## 伪本地化是什么，它替代了什么

这一节是本文最值钱的一个动作，做法却简单得有点滑稽。

伪本地化的意思是：造一份假的译文，用它去跑一遍整个站。

假译文不是随便乱写，它按固定规则从英文原文变换出来。

变换后的文字仍然认得出原意，但每个字符都被改过样子。

然后把这份假译文当成一门真语言接进站里，人肉走一遍。

它替代的是一件在真实项目里永远做不到的事：在译文交付之前就验证本地化是不是可行。微软把这套方法写进了官方的伪本地化方法论 (https://learn.microsoft.com/en-us/globalization/methodology/pseudolocalization)文档里，安卓也内置了两套伪地区可以直接开。这不是什么冷门技巧，只是它长期停留在工程侧，没人告诉做内容和做搜索的人这里有一把钥匙。

## 那串怪字符每一部分在测什么

一条典型的伪本地化字符串长这样：把Add to cart变成方括号加三个感叹号，中间是Àdd tô càrt，末尾拖几个波浪线。

每一部分都在测一件具体的事，不是为了好看。

首尾的方括号测截断：如果页面上看不见右边那个方括号，说明这句话被切掉了。

字母上的重音测编码：如果变成问号或者方块，说明这条链路上有一环丢字符。

末尾那几个波浪线测膨胀：欧洲语言普遍比英语长，加长之后布局撑不撑得住。

而最关键的那一条是：凡是页面上没有变成怪样子的字，就是没被抽出来的字。这一条不需要懂任何语言，也不需要任何工具，一眼就能看见。整套办法的精髓就在这里——它把一个原本要靠语言能力才能发现的问题，变成了一个靠眼睛就能发现的问题。

末尾要拖多少个波浪线不是随手定的，业界有一套按源文本长度分档的膨胀比例：十个字符以内的短词要预留三倍以上的空间，十到二十个字符预留一倍，长句子预留三成左右。越短的词膨胀比例越高，而按钮上的词恰好全是最短的那一档。这解释了一个常见现象：出问题的永远是按钮，不是段落。

按语言看，德语和芬兰语的膨胀最凶，俄语和法语中等，日语和中文反而会缩短。所以伪本地化那份假译文如果只按一个固定比例加长，测出来的结果对德语偏乐观、对中文偏悲观。稳妥的做法是按你实际要上的语言里膨胀最厉害的那一门定比例，测出来的布局才是安全的。

## 怎么在自己的站上跑一遍

落地路径分三档，按团队的技术条件挑。

第一档最正规：让工程按上面的规则生成一份伪语言资源文件，加一个内部可访问的语言开关。

第二档折中：只对一个语言版本做，把资源文件复制一份，用脚本批量变换，覆盖测试环境。

第三档最土：不改任何东西，把线上某个语言版本的页面挨个截图，人工圈英文。

三档的成本差出十倍，能发现的问题却是同一批。

保哥的建议是从第三档开始，先用两天时间圈出三十个关键页面的英文残留，拿这份带截图的清单去推第一档。空口说站上有英文没人当回事，三十张圈了红圈的截图摆在会上，排期通常当场就有了。

## 判读结果：三类问题要分开记

跑完一遍会拿到一堆现象，要分成三类分别派活。

第一类是没变样的字，这是抽取缺口，归工程，动作是补抽取。

第二类是变成方块或问号的字，这是编码或字体缺口，归前端，动作是补字体子集。

第三类是被切掉或者撑破的地方，这是布局缺口，归设计，动作是改宽度或者改折行规则。

三类问题的表面症状看着都是页面变丑了，可它们各自要找不同的人。

字体那一类还有一笔单独的账，网页字体在英文站只占几十KB，到了小语种站就变成拖慢首屏的最大一块 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)算过这笔钱该怎么省。分开记的价值在于：三类里只有第一类是本文说的这个问题，另外两类是顺手捡到的，捡到也别混在一张单子上报，否则三个团队会互相等。

## 抽出来之后，译者拿到的是一个词还是一句话？

## 上下文丢失是抽取的副作用

抽取解决了一个问题，同时制造了一个新问题。

文字从代码里被拿走之后，也就离开了它原来所在的那个位置。

译员打开资源文件，看到的是一长列孤立的短语。

他不知道这一条会显示在按钮上还是标题上，不知道旁边有什么，不知道它有多宽。

更要命的是他不知道这个词在这个场景里到底是什么意思。

这个副作用在英文站时代完全不存在，因为写代码的人当场就知道自己在写什么。抽取把文字和它的语境分成了两份，只有前者被交了出去。所以抽取率高不等于本地化质量高，它只是把问题从缺失变成了歧义。

## 一个单词能有几种意思

举几个真实踩过的例子，都很短。

Free在价格旁边是免费，在库存旁边是有空位，在筛选器里可能是无限制。

Back在导航上是返回，在商品属性里是背面，在配送里可能是退回。

Order在按钮上是下单，在列表标题上是订单，在排序控件上是顺序。

这三个词在英文里都不需要区分，可它们在荷兰语、波兰语、日语里各自要用完全不同的词。

而译员手上只有一个孤零零的单词，他只能猜，而且多半会猜最常见的那个意思。这就解释了一个常见的怪现象：明明找了母语者，界面上还是有几个词读起来怪怪的。不是他水平不行，是你给他的信息不够他做判断。

## 键名与注释该写成什么样

解法不复杂，成本也低，只是需要在写代码那一刻多花十秒。

键名别起成btn1、text2这种，起成能读出位置和用途的形式。

比如商品页加购按钮、结账页支付失败提示，这样译员看键名就知道场景。

更进一步是在每条旁边写一行注释，说明它出现在哪儿、旁边是什么、最大能多宽。

主流的资源文件格式都支持注释，翻译工具也基本都会把注释显示给译员看。

这件事的投入产出比高得不像话：一条注释十秒钟，省掉的是一次返工加一次上线。可它极难推动，因为写注释的人和承受返工的人不是同一个人，中间隔着两个部门和三个月。

## 屏幕截图为什么是最便宜的上下文

还有一种更彻底的做法，行业里叫在上下文里翻译。

做法是让译员直接在页面上看到自己翻的这句话长什么样。

成熟的工具能做到实时预览，改一个词页面上立刻变。

没有工具的团队可以退一步：给每个页面截一张图，跟资源文件一起发出去。

截图的成本几乎为零，效果却抵得上半页说明文档。

这一步在小语种项目上的收益比在大语种上更高，因为小语种译员通常拿不到产品培训，也很少有机会真的用一遍你的站。你给他的每一张截图，都是在替他补一次产品理解。这一条跟前面那条注释的建议不冲突，同时做效果最好。

## 拼在一起的那半句话，为什么在别的语言里必然坏掉？

## 拼接的三种形态

前面提过这一类，这里展开。

第一种是句子被切成两半，中间插一个数字或者名字。

第二种是把一个词单独抽出来，跟不同的前缀组合复用。

第三种是按条件拼，比如按数量选不同的后半句。

三种在英文里都能拼出通顺的句子，所以写代码的人不觉得有问题。

问题在于英文的语法特点恰好让拼接的代价最小：词序固定、名词几乎不变形、形容词不跟着变。换一门语言，这三条前提一条都不成立。国际化组织专门写过一篇处理组合消息 (https://w3c.github.io/i18n-drafts/articles/composite-messages/index.en)，把这件事的各种坏法列了一遍。

## 词序不同的语言会把变量甩到另一头

最直观的坏法是位置。

英文的还剩三件，切成还剩和件两半，中间插数字。

日语的同一句话里，数量词的位置和修饰关系跟英文完全不一样。

德语的从句会把动词甩到句子最末尾，前半句和后半句根本不能独立成立。

土耳其语和芬兰语更狠，变量本身要跟着句子里的角色改词尾。

结果是译员拿到两个半句，无论怎么翻都拼不出一句正常的话，他能做的只有选一个最不难看的错法。芬兰语的十五个格只是开胃菜，真正难住关键词工具的是词干自己也会变 (https://zhangwenbao.com/finnish-seo-fifteen-cases-consonant-gradation-keyword.html)那篇讲过格的规模，套到拼接上就是：每一个插进去的变量，都可能要求前后两半跟着改形态。

## 正解是整句带占位符，而不是把句子切碎

解法在工程侧是成熟的，只是没被当成本地化问题看待。

把整句话作为一条完整的资源，变量写成句子里的一个占位符。

译员拿到的是一整句，他可以按目标语言的语序自由安排占位符的位置。

行业里有一套标准的消息格式，占位符、数量分支、性别分支都能写在同一条里。

主流框架都支持它，前端和移动端各有各的实现，语法基本一致。

这里要跟另一件事划清界限：波兰语站的商品标题自动模板为什么必然拼错 (https://zhangwenbao.com/polish-seo-seven-cases-diacritics-keyword-research.html)讲的是商品数据按语法规则拼标题，那是内容侧的模板；这里讲的是界面句子被切碎发给译员，是工程侧的资源。两者的正解方向也相反：那边要减少拼接、改成人工确认的形态，这边要把碎片合回整句。

## 已经上线三年的站，按什么顺序补？

## 先量：抽取率这个数怎么算

动手之前先拿到一个数，否则说服不了任何人。

分子是资源文件里的条数，分母是页面上实际出现的可翻译文本条数。

分母不好精确统计，可以用抽样：挑十五到二十个有代表性的页面，人工数。

页面类型要覆盖首页、品类页、商品页、购物车、结账、订单页、报错页。

算出来的比值就是抽取率，多数第一次做这件事的站落在六成到八成之间。

这个数最有用的地方不是绝对值，而是它能按页面类型拆开看。拆开之后你会发现抽取率的分布极不均匀：内容型页面通常九成以上，交易链路上的页面往往只有一半。而后者才是决定转化的那一段，这个对比是拿预算最有力的一张牌。

交易链路上的抽取率之所以系统性偏低，有个结构性的原因：结账、支付、物流这几段通常是最晚做的、改动最频繁的、也最常由外部组件拼起来的。改动越频繁，写死一个词的诱惑越大，因为每改一次都要去资源文件里加一条。于是这几段页面同时具备了改动多和字少两个特征，而这两个特征相乘正好是最坏的组合。

## 第一批该补哪些位置

排序原则只有一条：按用户遇到它的概率乘以那一刻的重要性。

第一批固定是三样：加购与结账链路上的所有按钮、结账环节的报错文案、订单与发货邮件。

第二批是列表页的筛选与排序控件，以及库存与配送状态词。

第三批是导航、面包屑、页脚和搜索框的提示文字。

剩下的可以慢慢来，包括后台、帮助中心的界面壳、极少触发的系统页。

这个顺序跟按数量排正好相反：数量最多的通常是最边缘的那批。按数量排的团队会先啃掉一大片没人看的字，报表上进度很好看，转化上一点动静都没有。

推动这件事还有一个论据比缺口本身更有力：这笔投入是一次性的，而且被后面所有语言分摊。补抽取这件事跟具体哪门语言无关，做完一次，第二门、第三门语言上线时只需要翻译，不需要再补一遍。所以立项时不该按当前这一门语言的收益算账，要按未来三年计划上的语言数量算，一除下来单门语言的成本立刻变得很好看。

## 补进去之后怎么防止再漏

一次性补完解决不了长期问题，因为下个月又会有新代码。

最有效的一条是把检查放进代码合并的关卡里，扫描新增代码中直接写着的可见文本。

这类检查工具在各个技术栈里都有现成的，配置成本大概半天。

第二条是每个季度重跑一次伪本地化，把它做成固定动作而不是专项。

第三条是把抽取率写进本地化项目的验收标准里，跟翻译质量并列。

第三条最关键也最难推，因为它等于承认现有验收标准漏了一整个维度。可只要它写进去了，报价那一刻的不可见就被打破了——报价单上从此会多一行，那一行才是本文从头到尾在追的东西。

扫描规则本身也有讲究，扫得太宽会误报到没人愿意看。实用的一条是只扫标签之间的可见文本，且只对包含两个以上字母、不含变量符号的片段报警，类名、属性值、注释一律跳过。这样配出来的规则误报率能压到很低，团队才愿意让它一直开着。

另外要给出一个正式的豁免写法，比如加一条特定注释就跳过这一行。没有豁免通道的检查最后一定会被整个关掉，因为总有那么几处确实不需要翻译，比如商品编码前缀、货币代码、技术标识符。留一条明路，规则才活得下去。

还要同时建一份不许翻的白名单，跟抽取这件事配套。品牌名、型号、货币代码、技术标识符、法定名称这几类应该明确标出来，既不进翻译文件，也不被自动翻译层碰。这份白名单跟审校环节用的不许动清单是同一份，只是这里多了一个技术落点：在页面上给这些元素加上不翻译的标记，浏览器和翻译层都会绕过它们。

## 一份两天能跑完的自检清单

不想搞项目的团队可以只做下面这一份，两天能完。

第一天上午：挑二十个页面截图，按页面类型分好组。

第一天下午：圈出所有英文残留，按前面那五类归类，统计条数。

第二天上午：拿资源文件条数除以估算的总条数，算出抽取率，按页面类型拆开。

第二天下午：把结算链路上的那几条挑出来，做成一张带截图的清单交给工程。

这份清单的说服力来自它的具体：不是站上有些地方没翻译，而是结账页第二步的三个按钮和两条报错文案是英文，这里有截图。前者会被排到下个季度，后者通常这周就修。

## 哪些事不归语言层，要交给谁

## 交给前端与工程的那一半

有几件事跟本文讲的是同一条链路，但不该由做内容和做搜索的人扛。

资源文件怎么组织、按语言分包还是打进一个文件、加载时机怎么定，这些是前端架构问题。

构建流程里怎么校验资源文件的完整性，这是工程流程问题。

文字方向的镜像、日期时间的地区数据接入，这些有成熟方案，照着标准做就行。

内容这一侧要做的只有一件：把缺口指出来，并且说清楚它值多少钱。

这个分工在实践中特别重要，因为一旦内容侧的人开始讨论技术方案，讨论就会滑向技术选型，而选型是一个可以吵三个月的话题。把话题钉在缺口与损失上，反而推得动。

## 交给检索与内容那一侧的那一半

反过来也有几件事不该指望工程解决。

哪些词该用本地说法、哪些词用户真的在搜、同一个概念有几种写法，这是词表的活儿。

补进去的那批界面词该用哪一个形态、要不要跟正文里的用词统一，这是内容的活儿。

抽出来之后译得对不对、语气合不合，这是审校的活儿。

引擎那一侧怎么处理这类页面、平台的规则有什么不同，本篇不重复讲。

把这条边界画清楚有个附带好处：它让这件事从一个模糊的本地化没做好，变成两张各自有主人的清单。多数跨部门问题卡住的原因不是没人愿意做，是没人知道自己该做哪一部分。

还有一条排期上的规律值得记住：第一门非英语语言永远是最贵的那一门，因为整个站的抽取缺口会在它上面一次性暴露。第二门开始成本断崖式下降，只剩纯翻译。所以选第一门语言时，除了看市场大小，还该看这个团队有没有耐心承受一次基础设施改造，选错顺序的代价往往不是这门语言做砸了，是团队从此认定多语言太贵。

## 常见问题解答

## 我们的站是用现成的电商系统搭的，也会有这个问题吗？

会，而且形态更隐蔽。现成系统自带的界面文案通常有官方语言包，覆盖率不错，问题出在两个地方：一是你自己或者外包做的主题模板，那里面的文字是你自己写的，官方语言包管不着；二是你装的插件，尤其是小众插件，很多只有英文。判断办法很简单：把官方语言包的语言切过去，页面上剩下的英文就是这两类贡献的。这批词往往正好落在你最重视的那几个位置上，因为主题模板改得最多的就是首页和商品页。

## 抽取率应该做到多少才算合格？

没有一个通用的数字，但可以按页面类型定分档目标。交易链路上的页面应该逼近百分之百，包括购物车、结账、订单、报错这几类，这里差一条都可能直接掉单。列表页与商品页可以定在九成五以上。后台、帮助中心的界面壳、极少触发的系统页可以放到八成。用一个全站平均数当目标是最没用的做法，因为平均数会被条数最多的那批边缘页面主导，而它们恰好最不重要。

## 能不能直接用浏览器的翻译功能兜住这批词？

不能，原因有三层。第一层，你控制不了译出来的用词，品牌名和型号经常被一起翻掉。第二层，那个版本只对开了翻译的那部分用户存在，搜索引擎抓到的仍然是你自己那份带英文的页面。第三层也是最要命的一层：机器读到的是你的原始页面，语言判定、关键词匹配全部基于那一份，翻译层完全不参与。这件事另有一整篇账要算，本篇只强调一点：它救不了检索这一侧。

## 我们没有工程资源，能不能只改内容侧？

能做的比想象中多。第一，图片上烧的字是内容侧完全能控制的，把横幅图和尺寸图上的文字改成本地语言，这一步不需要任何工程介入。第二，邮件和短信模板多数住在运营工具里，运营自己就能改。第三，站内搜索的提示语和空结果文案在不少系统里是可配置项。把这三样做完，通常能覆盖掉三成到四成的可见缺口，而且见效很快，也正好用来给后面那一半争取排期。

## 伪本地化跑出来的结果，非技术人员看得懂吗？

看得懂，这正是它最大的好处。它把一个需要语言能力才能发现的问题，转化成了一个视觉问题：页面上没变成怪样子的字就是没抽出来的字，变成方块的就是字体缺字符的，右边少了一个方括号的就是被截断的。三类现象用眼睛就能分清，不需要懂任何一门外语，也不需要读代码。保哥带团队做这件事时，通常让运营而不是工程来跑第一轮，因为运营更清楚哪几个页面重要。

## 这批词补上之后，多久能看到数据变化？

分两段看。转化侧的变化最快，结账链路上的英文一旦换掉，弃单率的变化通常在两周内就能看出来，因为它修的是一个硬阻塞。检索侧要慢得多，页面文本变了之后要等重新抓取和重新评估，加上你补进去的那批词本身量级不大，一个季度能看到趋势就算不错。所以立项时别把两段混在一起承诺，用转化侧的数字换排期，用检索侧的数字做长期跟踪。

## 多语言站的这个问题，跟单语言站的界面文案质量是一回事吗？

不是。单语言站的界面文案问题是写得好不好，是一个质量维度，改了会更好，不改也还能用。多语言站的这个问题是有没有，是一个存在与否的维度，不改就等于这一部分内容在这门语言下完全缺席。两者的严重程度差一个数量级，处理它们的优先级也应该完全不同。把这两件事混在同一张需求清单里，通常的结果是前者因为看起来更容易被先做掉。

## 权威参考资料



## 语言代码是谁替这门语言申请的？616份申请书里过半出自同一个组织

- URL：https://zhangwenbao.com/minor-language-code-who-files-requests.html
- 分类：小语种SEO
- 发布：2025-03-11  |  更新：2025-03-11
- 摘要：逐份拆开616份ISO语言代码主申请表：过半署着同一家机构的名字，头一回投的人只有约四分之一能过，老手接近四分之三。申请量榜首是中国，可那一百多份没有一份由境内提交。
- 关键词：多语言SEO,小语种SEO,网站本地化,建站选型

> **TLDR**：摘要：把ISO语言代码申请库里616份主申请表逐份抠开，看署名的是谁。结果是56.8%出自同一个组织，其中一个域名单独占了281份。第一次提交申请的人通过率只有27.4%，提交过十份以上的人是73.0%，差2.7倍。三条预期全错：拉人联署的通过率反而更低，申请书写得越长通过率越低，列不列参考文献跟结果没有关系。被申请最多的国家是中国，135份，占全库22.4%，而这135份里来自中国境内邮箱的是0份。

> 摘要：把ISO语言代码申请库里616份主申请表逐份抠开，看署名的是谁。结果是56.8%出自同一个组织，其中一个域名单独占了281份。第一次提交申请的人通过率只有27.4%，提交过十份以上的人是73.0%，差2.7倍。三条预期全错：拉人联署的通过率反而更低，申请书写得越长通过率越低，列不列参考文献跟结果没有关系。被申请最多的国家是中国，135份，占全库22.4%，而这135份里来自中国境内邮箱的是0份。

上一篇文章里有一句话，写完之后保哥自己一直觉得不踏实。

那句话是：提交申请不需要什么资质，填一份表就行，申请人可以是语言学家、可以是当地的语言委员会，也可以是一个热心的使用者。这话没错，它是照着官方的流程说明写的。

但流程说明写的是谁有资格来，不是谁真的来了。这两件事在任何一个开放机构里都有落差，问题只是落差有多大。

所以这一篇去数了一遍：那份决定全世界七千多门语言各自叫什么、编号是几的清单，实际上是谁在往里填。

先把结论摆出来，省得读者带着悬念看数字：这条通道确实对所有人开放，但走过去的人非常少，而且第一次走的人多半会被拦下来。开放和可用之间隔着一段距离，这一篇量的就是这段距离有多长。

## 这份全球语言清单，到底是谁在往里填？

## 为什么这个问题值得一个下午

你在页面上写的那串语言代码，来自一份在册表。那份表里的每一行，最初都是有人填了一份表格提交上去的。

这句话听着像废话，但它的推论不是废话：如果填表的人集中在很小的一群人里，那么这份清单反映的就不是世界上有多少门语言，而是这一小群人走到过哪里。

做小语种市场的人天天在用这份清单的下游产物——语言选择器里的列表、关键词工具的语言维度、翻译供应商的报价单，源头都是它。清单的偏差会一路传下来，而下游没有任何一个环节有能力发现它。

举个能立刻对上号的：你在语言切换器里看到的那份列表，它有多长、每一门叫什么名字，最上游就是这份在册表。本站量过三家系统的界面语言清单差3.4倍 (https://zhangwenbao.com/minor-language-ui-locale-list-coverage.html)，那是下游的差异；而上游那份表本身是怎么长出来的，一直没人问过。

上一篇量的是这个库怎么判（语言代码申请被驳回，187份裁决书里提到政治的只有1份 (https://zhangwenbao.com/minor-language-code-request-rejection.html)），这一篇量的是谁在提。判据和提案人是两件事，合起来才是这个库的全貌。

## 数据从哪来：明细页上没有的那一栏

这个库的申请明细页上，能看到变更类型、状态、生效日期、改的是哪个属性。唯独看不到申请人。

申请人写在附件里。每一份创建新语言代码的申请，都要附一份单独的表格，文件名是申请编号加上那门语言的代码。这份表格的第一栏就是主申请人的姓名和邮箱。

保哥把这批附件全抓了下来，一共616份，覆盖346个申请编号，时间从2006年这套体系上线那年一直到2022年。通过的378份，被驳回的238份。

抓下来之后转成文本逐份抠字段。这份表格的格式在十七年里几乎没变过，字段标记稳定得让人意外，所以一套正则跑到底，616份全部解析成功。

顺带说一句，这批附件的下载不能靠猜文件名。同一批申请里，附件的命名规则前后换过，猜URL会漏掉一部分，而漏掉的表现是拿到一个假文件而不是报错。正确的做法是从申请明细页里把附件的真实文件名读出来再下载。

这条听起来琐碎，但它决定了这一篇的数据完不完整。官方那几份码表 (https://iso639-3.sil.org/code_tables/download_tables)是结构化的，直接下载就能用；而申请附件这一层是散落的文件，得一个个对。一手数据的成本，通常不在分析那一步，在把它凑齐那一步。

## 这份表格要求申请人交代些什么

表格一共五节。第一节是名称：这门语言首选叫什么、自称是什么、还有哪些别名、为什么选这个名字、使用者大概多少人。

第二节是时空：它是活语言、濒危、刚灭绝、历史语言还是人造语言，用在哪几个国家、哪几个地区。第三节是谱系：口语还是手语，属于哪个语系，最近的亲属语言是哪门。

第四节是这门语言的处境：有没有书面文献、有没有广播电视、政府承不承认、进不进学校。第五节最有意思，标题叫信息来源，要求申请人交代三件事——你有没有第一手知识、有没有通过私下沟通得到的信息、有没有已出版的文献可以列。

这不像一张工单，像一份论文的方法论章节。这个观察后面会变成一条硬结论：一份看起来对所有人开放的流程，可以通过表格的形状本身完成筛选。

## 本文量什么、不量什么

量三样：主申请人的身份、这个人一共提过几份、他提的那些申请后来通过没通过。

不量申请内容的对错。一份申请该不该通过是语言学问题，保哥没有这个能力判断，也不打算判断。这一篇只回答谁在提这个问题。

也不量这些语言今天的市场价值。标准里的地位和市场规模在这个库里几乎正交，这一条上一篇已经用裁决书的词频证明过了，这一篇不重复。

也不量2022年之后的部分。那之后的附件在库里还没有铺全，样本不完整的年份宁可不要，免得算出一个假趋势。

还有一件事要提前说清楚：这一篇会大量出现同一个组织的名字，但这不是一篇批评谁的文章。数完之后你会发现，真正值得担心的不是有人做得太多，是没有别人在做。

## 一半以上的申请书，为什么署着同一个组织的名字？

## 按邮箱域名分类的结果

把616份表格里主申请人的邮箱按域名归类，结果是这样的：一家长期做少数语言田野调查的机构及其分支机构合计350份，占56.8%。

剩下的部分：免费邮箱110份占17.9%，一个语言学网络社区38份占6.2%，各类大学邮箱28份占4.5%，其它非营利组织21份占3.4%，其它域名58份占9.4%。

光是一个主域名就出现了281份。也就是说这份全球语言清单里，每五份新增语言的申请书就有两份多是从同一个邮箱后缀发出来的。

这个组织正是这套编号的注册机构本身。上一篇写过它的角色：受理申请、组织评议、写裁决、每年发布更新后的码表。现在多了一条——它同时也是最大的申请人。

## 这个组织到底在做什么

它的主业是语言调查和识字教育，在全球几十个国家有常驻项目，很多项目一做就是几十年。它自己对语言调查这项工作的描述 (https://www.sil.org/language-assessment)里写得很清楚：先弄清一个地区实际在说哪些话、彼此通不通，才谈得上后面的事。

这项工作跟语言代码申请天然是一条线。你要判断两个村子说的话是不是同一门语言，做的事跟申请表要求证明的东西完全重合。调查做完，申请表已经填好了一大半。

所以这个占比不是谁挤走了谁，是这件事本来就只有一类人在日常工作中顺手能做。它反映的不是垄断，是空缺。

## 受理方和申请方是同一批人，这意味着什么

先说清楚这不构成程序问题。这个机构做的是语言田野调查，它的人常年在偏远地区做语言普查，遇到一门没有代码的语言，顺手提一份申请是最自然的事。

换个角度想，如果不是他们提，多数情况下没有别人会提。世界上愿意为某个只有几千人使用的语言填一份英文表格、附上参考文献、等一年结果的人，本来就不多。

但它确实有一个后果，而且这个后果对用数据的人是实打实的。上一篇提过：这个机构自己也出版一份全球语言数据库，两套东西的语言划分高度一致，所以你没法用那份数据库去交叉验证这份码表。

现在这条要再往前推一层。不只是发布方同源，连申请书都是同一批人写的。这不是两家对不上的问题，是整条链上从头到尾只有一家。你手上任何一份关于世界语言数量的数据，追到底大概率都会追到这里。

## 剩下那一半是谁

免费邮箱那110份最值得看。用gmail提交申请的人里，有一位在2019年一个人提了31份，而那一年全库总共只有45份。

这类申请人通常是独立研究者：有的是退休的语言学教授，有的是常年整理某个语系资料的爱好者，有的是某门语言的母语者自己。他们不挂机构，用的是私人邮箱。

这一档的存在本身是好消息：它说明这条通道确实对个人开放，不是只有机构才进得来。坏消息在后面那个通过率上。

大学邮箱那28份高度集中，其中17份来自澳大利亚一所研究原住民语言的大学，同一位教授在2013年一口气提了15份。

那个语言学网络社区的38份也是集中提交，主要处理古代语言、已灭绝语言和人造语言这三类。这类语言不属于任何一个田野调查项目的范围，所以由它来批量补齐。

这个社区是语言学界一个运作了三十多年的公共平台 (https://linguistlist.org/about/)，本身不是研究机构。它在这个库里承担的角色很特别：没有人会去田野调查一门古代语言，所以那批代码只能由这类平台整理现有文献之后统一提交。

它的通过率是全库最高的97.4%。原因也在这里——古代语言的边界早就在学界定好了，不存在争议，提交动作本身是行政性的。

## 这批数据第一次算出来的结果，为什么是错的？

## 一条太漂亮的趋势线

第一次跑完统计，保哥看到一条很漂亮的趋势：这家机构在申请里的占比，2006到2008年是七成到九成，2009年之后突然归零，之后再也没回来过。

这个形状太干净了，干净到可以直接写成一节：这家机构在2009年前后退出了申请，把位置让给了独立研究者。故事很完整，还带一个时间拐点。

幸好这个结论太漂亮了，漂亮到不太可信。一个组织的行为很少会在某一年整齐地切断，通常是逐年衰减。

于是回去看原始文本。看第一份就明白了。

## 邮箱被做了防爬处理，而且是从某一年开始的

2009年之后的表格里，邮箱不再写成正常形式，写的是把at换成单词、把点也换成单词的那种形式，中间用空格隔开。这是网页时代很常见的防爬虫写法。

616份里有353份是这种形态，占了一多半。而保哥的正则只认at符号，所以这353份全部被判成没有邮箱，归进了无法分类那一档。

2009年恰好是这个改动开始的年份。于是一次格式变更，被读成了一次真实的组织行为变化。

这是本工程第十二次撞上尺子失效，形态是新的：数据源在时间序列中间改了字段格式，而改动的时点看起来像一个事件的拐点。补上还原规则之后重跑，这家机构的占比从2006到2022年一直在三成到九成之间波动，从来没有归零过。

## 这条坑值得单独记一笔

判据可以固化成一句话：任何时间序列在某一年整齐断裂，先问那一年数据的记录方式是不是变了，再问事实是不是变了。

这条在别处也成立。之前量一门语言的地区数据自有率时，也是先看到一个总格数暴涨的曲线，后来发现涨的是继承标记不是真数据，那一次的记录方式变更发生在某个版本号上（区域数据里到底有多少是这门语言自己的 (https://zhangwenbao.com/minor-language-locale-data-inheritance.html)）。

做站的人遇到这条的概率不低。分析工具改过一次统计口径、爬虫改过一次归类规则、某个字段从某天起开始有默认值——这些都会在报表上画出一个漂亮的拐点，而拐点下面什么都没发生。

本站踩过同族的坑不止一次。有一次从规格书里抠文本，屏幕上显示的是好端端的泰语，程序复制走的却是另一串字符，因为那份文件的文本层跟显示层压根不是一回事（那页规格书机器读到的是另一串字符 (https://zhangwenbao.com/minor-language-pdf-text-layer-extraction-failure.html)）。

共同点是：出问题的从来不是数据缺失，是数据存在但含义跟你以为的不一样。缺失会报错，含义错不会。

保哥的做法是给每条时间序列都配一句话：这条线是用什么方法量出来的，这个方法从哪天到哪天没变过。写不出这句话的曲线，不拿去做决策。

## 同样一套只看证据的判据，为什么通过率差2.7倍？

## 按申请人身份分开算的通过率

把616份按主申请人的邮箱类型分组，各自算通过率，结果差得很开。

那个语言学网络社区提交的38份，通过37份，97.4%。田野调查机构那350份，通过260份，74.3%。其它非营利组织47.6%。

另一头：免费邮箱110份只通过39份，35.5%。大学邮箱28份只通过9份，32.1%。

最高和最低差2.7倍，而这套体系的判据只有一条——这两个变体是不是互不相通。

## 那个97.4%是怎么来的

先把最高的那一档解释掉，否则会误导。97.4%不是因为这个社区特别会写申请，是因为它提的那38份几乎全是没有争议的登记动作。

古代语言、已灭绝语言、人造语言，这三类的共同点是：没有活着的使用者社群会对划分提出异议。没有异议，就没有可驳回的理由。

剔掉这一档之后，真正可比的是田野调查机构的74.3%和独立申请人的35.5%。这两档面对的是同一类语言、同一套判据，差的是提交人。

顺带说，这种把最高分那一档单独拎出来解释掉的动作，做数据的时候值得养成习惯。一张排行榜上最扎眼的那个值，十次里有八次是口径问题或者样本性质不同，不是真的强。量小语种引用密度 (https://zhangwenbao.com/minor-language-content-citation-density.html)那一次也是这样：荷兰语的空栏率0.0%看着最好，实际是因为分母只有1条。

## 大学邮箱通过率垫底，这条最难解释

开工前保哥的预期是大学那一档会排在前面。学者提的申请应该最规范、最有文献支撑、最经得起评议。

实测是倒数第一。翻了几份被驳回的大学申请之后，原因大致清楚了：学者提的申请常常是为了给一个学术上有争议的划分背书，而学术上有争议恰恰是这套体系最不愿意碰的地方。

田野调查机构提的则多数是另一类：某个村子里的人说的话跟邻村不通，需要一个新代码来登记。这类申请没有争议，只有事实。

换句话说，通过率高低不完全是申请质量的差别，是申请动机的差别。要登记一门没人管过的语言容易，要重划一条已经有人在争的边界难。这跟上一篇按地区算出来的驳回率是同一件事的两个切面。

## 判据没有偏心，格式有

还有一层更实际的解释。这份表格要求填的东西——语系归属、最近亲属语言、可懂度证据、参考文献清单——是一套专门的知识。

常年做这件事的人知道每一栏该写什么、写到什么程度算够。第一次填的人不知道，他会把自己认为重要的东西写进去，而那些东西未必是评议人要看的。

所以判据本身确实是中立的，上一篇的数据已经说明了这一点：187份裁决书里提到政治的只有1份，绝大多数只谈证据。但能不能把证据组织成这套体系认得出的形状，跟你在哪个组织里、有没有人教过你，关系很大。

这个结构在别的地方也常见。一份对所有人开放的申报流程，只要表格足够专业，就会自动完成筛选，而且筛的不是诚意，是熟练度。

做跨境的人对这个结构应该不陌生。平台的申诉通道、品类的资质备案、某些市场的合规申报，都是同一套逻辑：门开着，但门里的语言你得先学会说。

## 第一次提交申请的人，通过率为什么只有27.4%？

## 熟手和生手的四档

换个分法：不看申请人属于哪个机构，只看这个人在整个库里一共提过几份。

只提过一份的人有84位，合计84份申请，通过23份，通过率27.4%。提过两到三份的155份，通过率61.3%。提过四到九份的118份，60.2%。提过十份以上的259份，通过率73.0%。

第一次来的人和常客之间差2.7倍，而且这个差距的绝大部分发生在第一份和第二份之间。从27.4%到61.3%，只隔着一次经验。

这条比按机构分组的那条更硬。机构可能自带资源，但提交次数这个变量里没有资源，只有熟练度。

要提醒一句这条数据的局限：提交次数多的人本来就更可能属于那家机构，两个变量不是完全独立的。但即使把那家机构的申请整个剔掉，只看独立申请人内部，提过多次的人通过率仍然明显高于只提过一次的人。熟练度这个因素单独成立，不是机构身份的影子。

## 84个人只来过一次

整个库里出现过187个不同的申请人名字，其中84位只提过一份，占45%。

另一头，提交量最大的20个人合计提了307份，占全库的49.8%；前50人合计425份，占69.0%。一个人最多提了39份。

把这两个数放在一起看：近一半的人只来过一次，而一半的申请由20个人完成。这是一条典型的长尾，但尾巴那一端的通过率只有头部的三分之一多一点。

那84个人里，被驳回的61位中有多少会再来一次？数据里看得到答案：全库被反复申请且始终没通过的只有两组。绝大多数人被驳回一次之后就再也没有出现过。

## 被驳回之后再来一次的人有多少

上一篇统计过反复申请的情况：反复提交的组合三分之二最终会成功，但成功的那一次主张往往变了。

那一篇看的是同一门语言被反复申请，这一篇看的是同一个人。两个角度的答案一致：反复这件事本身很罕见。

把这两条合起来，这个库的真实图景是：一小群熟练的人在持续供货，一大群人来过一次就走了，而走掉的那批人带走的是他们那门语言的登记机会。

这不是谁的错。填一份英文表格、附上可核查的语言学证据、然后等一年——对一个只是想让自己母语被登记的人来说，这个成本已经足够劝退。

## 这套流程的学习成本落在哪

翻被驳回的第一次申请，最常见的问题不是证据不足，是不知道该提哪一类变更。

有人想把一个变体独立出来，填的是创建新语言；实际上他要的是拆分，而拆分要求对原代码的整个范围负责。有人想改一个名字，填的却是创建。类型填错，后面写得再好也过不去。

官方那份提交变更申请的说明页 (https://iso639-3.sil.org/code_changes/submitting_change_requests)其实把类型分得很清楚，但它是一份规则文档，不是一份指南。规则文档能告诉你有哪几种类型，不能告诉你你的情况属于哪一种。

这跟做SEO的人遇到的很多事同构：平台的政策文档写得很全，但你要判断自己这个具体情况适用哪一条，还是得先撞一次墙。

顺带一提，这批被驳回的第一次申请里，有相当一部分申请人是那门语言的母语者本人。他知道自己说的话跟隔壁不一样，但他不知道要怎么把这件事写成这套体系认的证据。这个落差跟内容行业里那个熟悉的落差是一回事：懂业务的人不懂怎么把业务写成机器认的格式。

## 这条对做内容的人意味着什么

如果你所在的市场涉及一门登记信息有问题的语言——名字不对、范围不对、该拆没拆——理论上你可以提一份申请。实际上你第一次提的成功率是27.4%。

更现实的做法是找已经在做这件事的人。这个库的每一份申请都公开署名，你能看到最近几年谁在处理你关心的那个语系。

这一步的成本很低。翻两页索引，把最近五年提交过相关语系申请的人名记下来，发一封说明情况的邮件，比自己从头研究表格快得多。

不过说句实话，绝大多数做电商的人不需要走到这一步。这条数据真正的用处是反过来的：它告诉你这份清单的空白处不是没人需要，是没人有精力去填。

## 这份表格里，哪一栏人人都填，哪一栏一多半空着？

## 十一个栏位的填充率

把616份表格的每个栏位数一遍有没有填，得到一张填充率表。这张表比任何一份流程说明都更能说明这套体系实际在乎什么。

填写日期、主申请人姓名两栏，616份全填。邮箱99.5%。这门语言用在哪几个国家99.4%。使用人数91.6%。

往下开始掉：有没有书面文献82.5%，政府承不承认、进不进学校81.7%，其他支持者的署名60.2%。

最后是信息来源那三栏。第一手知识616份全部填了，100%。已出版文献66.2%。而通过私下沟通得到的信息，只有34.6%填了。

## 第一手知识那一栏，616份全填了

一个栏位的填充率达到100%，通常有两种可能：要么它是必填项，要么它是这件事的门槛本身。

这一栏不是必填项——同一节里另外两栏都能空着交上去，说明系统没有强制。它填满的原因只能是第二种。

翻开这一栏的实际内容就明白了。典型的写法是：某某教授在这门语言上做了十五年的研究项目并发表过相关论著；或者更朴素的，申请人自己在那个地区住了多少年、走访了多少个村子。

换句话说，这一栏回答的是同一个问题：你凭什么替这门语言说话。而这个问题在这套体系里没有替代答案。你可以不列文献，可以没有联署人，但你不能说不出自己跟这门语言的关系。

## 私下沟通那一栏，只有三分之一的人填

这一栏问的是：你有没有通过跟别人交流得到的信息，请描述。填的人只有34.6%。

这个低填充率有点意思。按理说做语言调查的人一定会跟当地人交流，怎么会有三分之二的人不写。

看内容能猜到原因：填了的那些人，写的多半是我跟当地某个语言组织长期合作、或者我跟研究这门语言的另一位学者核对过。没填的人不是没交流，是把这些内容合并写进了第一手知识那一栏。

这条对填任何表格的人都成立：栏位的填充率不只反映事实，也反映填表人怎么理解栏位之间的边界。两个栏位语义接近的时候，靠前那个会把靠后那个吃掉。

## 使用人数那一栏填了九成，可它不影响结果

使用人数的填充率是91.6%，属于填得很满的一档。但上一篇已经量过：187份裁决书里提到使用人口这个词的只有7份，而且都不是主要依据。

一个栏位填得很满、却几乎不参与判定，这种组合在表格设计里很常见。它的作用通常是给后续的数据库用，不是给评议用。

这一栏填的东西后来去了哪里？去了那份全球语言数据库的使用人数字段。你在任何地方看到的某门语言有多少人说，源头可能就是十几年前某个申请人在这一栏里填的一个约数。

这条对做语种排期的人是硬伤。你拿两门语言的人口数做对比，前提是这两个数用同一把尺子量的；而这批数字来自不同年份、不同调查者、不同估算方法，彼此之间根本不可比。本站在非洲市场选语种那一篇 (https://zhangwenbao.com/africa-market-language-selection-swahili-hausa-francophone.html)里给过替代方案：别看人口，看有没有人拿这门语言写价格和退货政策。

这条值得做市场的人记一下。给语种排优先级的时候，那一列人口数不是普查数据，是一批研究者在不同年份、用不同方法估出来的值，彼此之间不可比。这跟本站量过的另一件事同构：一个看起来很硬的数字，追到源头往往是某个人在某一年填的一格。

## 三栏合起来，是这套体系的成本结构

把这三栏放在一起看：人人都填的是你的亲身经历，一多半人填的是文献，三分之一人填的是交流记录。

这个顺序说明这套体系收的是什么：它要的不是资料，是有人真的去过。资料可以在图书馆里找，去过没有替代品。

这也解释了为什么田野调查机构的通过率能到74.3%。他们的人本来就在那儿，第一栏对他们来说是现成的。而一个坐在书房里、靠文献研究某门语言的学者，恰恰在这一栏上最弱。

做内容的人可以从这里借一条判据：当一个体系反复要求你证明亲身经历，它筛掉的不是能力差的人，是没到过现场的人。这条判据这几年在搜索里也越来越明显。

区别只在于，语言登记这套体系是明着写在表格里的，而搜索那一侧是隐含在评估标准里的。两边要的东西一样：你到底有没有亲手做过这件事。

## 哪三条预期，在实测面前全错了？

## 打脸一：拉人联署没有用，反而更低

表格第一节留了一栏，专门填其他支持者的姓名、单位和邮箱。开工前保哥的预期是这一栏填得越满越好。

实测：有支持者署名的371份，通过率59.3%；只有一个人署名的245份，通过率64.5%。联署的那一批反而低5个百分点。

合理的解释不是联署有害，是因果反了。争议大的申请才需要拉一堆人来背书，而争议大本身就是驳回的高风险因素。联署是争议的症状，不是解药。

顺带一个细节：有一份申请的支持者栏里塞了41个邮箱。那一份被驳回了。在这套体系里，人多不是力量，只是说明这件事有人不同意。

## 打脸二：写得越长，通过率越低

把每份表格里几个正文栏位的字数加起来，按四分位分档看通过率。

最短的四分之一，通过率67.5%。偏短那一档69.3%。偏长那一档58.7%。最长的四分之一，通过率50.0%。四分位数是223字符、464字符、989字符。

填得最多的那一批，通过率比填得最少的那一批低17.5个百分点。这条跟所有人的写作直觉都反着来。

原因跟上一条同源：需要长篇论证的申请，本来就是难判的那些。常规的新语言登记只要写清楚这门话跟邻村不通、有多少人说、谁做的调查，两三百字就够了。

可以固化成一条判据：一份材料的长度是争议度的代理指标，不是质量的代理指标。这条在提案、立项书、申诉信上都成立——你写了三千字，通常不是因为你准备得充分，是因为这件事本来就不好说服人。

## 打脸三：列不列参考文献，跟结果没关系

表格第五节要求列出已出版的文献，包括词典、语法书等。616份里有408份列了，208份完全没列。

通过率：列了文献的60.5%，没列文献的63.0%。基本没有差别，甚至没列的还高一点点。

这一条要特别小心，因为它看起来跟上一篇的结论矛盾。上一篇讲过，这套体系判定两个变体是不是不同语言时，有一条判据看的是文献存量——发达的标准化加上成规模的文献。

两者的区别在于：那条判据看的是这门语言几十年积累下来的文献总量，这里量的是申请人在表格里填不填那一栏。前者是这门语言的客观处境，后者是填表的动作。填了不代表存量厚，没填也不代表没有。

## 三条打脸合起来说明了什么

三条指向同一个方向：表格上那些看起来像质量信号的东西——联署人数、篇幅、文献清单——都不是。

真正预测结果的是两个变量：这个人提过几次，以及这件事有没有人在争。前者是熟练度，后者是争议度。

保哥觉得这个结论比数字本身更值得记，因为它能直接搬到别的场景。评估一份材料能不能过，先别看它做得多满，先看提交人是不是熟手、这件事本身是不是有分歧。

做内容的人尤其容易掉进第一个坑：以为把能填的都填上就是准备充分。实际上很多流程里，填得多只是暴露了你不知道哪些是关键。

这条在页面上也成立。一个商品页把所有能填的属性格子都填满，未必比只填对三格的页面表现好，因为多出来的那些格子里装的常常是待补充和不适用。小语种内容里那个空着的参考资料栏 (https://zhangwenbao.com/minor-language-content-citation-density.html)是同一个形态的极端版本：格式摆得很齐，那件真正费事的事没做。

## 被申请最多的国家是中国，而没有一份来自中国

## 先看国家分布

表格第二节要填这门语言用在哪几个国家。把616份的第一个国名取出来归并，一共覆盖98个国家。

排在最前面的是中国，135份，占22.4%。之后是澳大利亚56份、尼日利亚45份、印度39份、巴布亚新几内亚37份、肯尼亚18份、印度尼西亚17份、墨西哥15份。

中国这个第一名的幅度很大，是第二名的两倍多。原因不难理解：中国境内的语言多样性很高，而这套体系上线的那几年，正好有一批针对中国南方少数民族语言的调查项目在进行。

这批申请的通过率是57.8%，略低于全库平均。

顺带说一句，这个国家分布跟商业价值的排序几乎没有重合。跨境电商眼里的重点市场——德国、日本、法国、巴西——在这个库里的申请量都很小，因为那些国家的语言早就登记完了。这份清单的活跃区域，正好是商业地图上最空的那些地方。

## 这135份是谁提的

按邮箱域名拆开：那家田野调查机构100份，gmail31份，yahoo3份，那个语言学社区1份。

来自中国境内邮箱的是0份。不是很少，是一份都没有——没有.cn域名，没有国内的邮箱服务，一份都没有。

提交量最大的几位：一位在2007年提了39份，另一位用gmail提了20份，还有几位各提了8到13份。这几个人合计完成了这135份里的绝大部分。

再看具体是哪些语言。壮语在这个库里被切成了十几个代码，右江、左江、邕南、砚山、桂北、桂边、柳江、连山这些名字各自成为一个独立的语言代码。布央语被分成三个，另外还有佤语的一支、阿克乌语、茶洞语、卡卓语、桑孔语，以及图木舒克语这样的历史语言。

## 这批申请集中在哪几年

把这135份按年份铺开，2006和2007两年占了一多半。2006年那份把壮语拆成五个代码的申请 (https://iso639-3.sil.org/request/2006-128)和2007年那份一口气拆出九个的申请 (https://iso639-3.sil.org/request/2007-027)，两份加起来就是十四个新代码。

打开这两份申请能看到完整的附件：每一个新代码都有一份单独的表格，填着这一支的使用地区、人数、最近的亲属语言。填表的是同一批人，日期挨在一起。

这两年之后，涉及中国的申请量迅速回落，最近几年每年只有零星几份。不是因为剩下的语言都登记完了，是那批项目结束了。

这一点可以拿另一件事对照着看：中国境内还有大量语言的登记信息停留在二十年前那批调查的结论上，之后没有人系统性地复核过。你今天在任何国际清单里查到的那些名字和划分，用的还是那时候的口径。

## 这件事的后果落在哪

先说清楚：这些申请从语言学上说未必有问题。做这批调查的人是专业的，很多划分在学界是有共识的。

问题不在对错，在于中国境内的语言在国际标准里被切成什么样、每一块叫什么名字、用哪三个字母表示，全部由境外的申请人决定，而且这个过程从来没有中断过。

这件事的下游影响是具体的。你在做面向东南亚市场的内容时，如果涉及壮侗语族，你在任何一份国际语言清单里看到的分类和命名，都是从这批申请里长出来的。那个名字未必是使用者自己的叫法，也未必是国内学界的通行叫法。

再往下一层，这些名字会进到机器翻译的语言列表、进到模型的语言标签、进到你买的关键词工具的下拉框。一门语言在这些工具里叫什么，决定了工具里有没有它的数据。本站量过低资源语言在模型里的表现 (https://zhangwenbao.com/low-resource-language-ai-hallucination-rate-content-risk.html)，那一层的语言清单同样是从这份表长出来的。

这跟一个更普遍的现象是同一回事：一门语言的名字取决于它历史上被谁命名，而不是它自己怎么称呼自己。这一条在语言选择器上的表现（语言切换器该写自称还是英文名 (https://zhangwenbao.com/minor-language-endonym-language-picker-sort.html)）和在标准里的表现，是同一条线的两端。

## 别的国家什么情况

把这个口径推到别的国家上：尼日利亚45份，本国实体0份。印度尼西亚17份，0份。肯尼亚18份，0份。墨西哥15份，0份。

印度39份里有7份来自一个印度域名。澳大利亚56份里有18份来自本国域名，其中17份是同一所大学。

在申请量最大的十个国家里，只有澳大利亚有本国的学术机构在系统性地做这件事。

这个对照不需要太多解释。做语言登记这件事需要有人常年盯着、懂这套表格、愿意花时间，而多数国家没有一个机构把这件事列进职责。

要补充一句公平话：没有本国机构参与，不等于本国没有研究。很多国家的语言学界有大量成果，只是这些成果没有走这条国际登记的通道。研究和登记是两件事，中间没有自动的传递机制，得有人专门去做那个动作。

## 本地参与度这个数，为什么第一次量出来是假的？

## 巴布亚新几内亚看起来有65%

上一节那张表，第一版跑出来的时候有个异常值：巴布亚新几内亚37份申请里，有24份来自以该国顶级域名结尾的邮箱，本地率64.9%，全表最高。

如果照这个数写下去，结论会是：巴新是本地参与度最高的国家，远超澳大利亚和印度。这个结论还挺有故事性，一个太平洋岛国在语言登记上比发达国家更积极。

然后保哥把这24份的域名逐条打开看了一遍。

24份全部是同一个域名——那家田野调查机构在巴新注册的分支机构域名。一份真正的本地申请都没有。

## 顶级域名当本地参与度用，是一把坏尺子

问题出在指标设计上。用邮箱的国家顶级域名判断申请人是不是本地人，前提是本地域名等于本地实体。跨国组织在当地注册分支域名，这个前提就塌了。

同族的还有肯尼亚那18份：那里有一个当地注册的组织域名，看名字像本地机构，实际上属于同一个体系的圣经翻译项目网络。

这是本工程第十三次撞上尺子失效，形态同样是新的：用地理属性的代理指标衡量组织归属，而跨国组织的当地分支会让这个指标整个失真。

修正的办法只有一个，就是逐条看真实域名，判断这个域名背后是什么实体。616份不算多，一个下午能看完。凡是靠后缀、前缀、命名规则自动归类出来的结论，都得抽样打开看，样本量小的时候干脆全看。

## 修正之后，澳大利亚那17份反而更值钱了

剔掉分支机构之后，真正由本国实体提交的申请，在申请量前十的国家里只剩澳大利亚一家。

那17份来自澳大利亚北部一所专门研究原住民语言的大学，主申请人是同一位教授，集中在2013年提交。

这个孤例反而把结论说得更清楚：本国机构参与语言登记这件事是可能的，需要的条件是有一个把它写进职责的学术机构。有这个条件的国家很少。

还要看到另一面：那位教授提交的15份集中在同一年，之后就没有了。个人驱动的参与和机构驱动的参与，区别在于前者会随着这个人的项目周期结束而中断。这跟本站量界面语言包完成度 (https://zhangwenbao.com/minor-language-interface-translation-coverage.html)时看到的形状一样：最后一次提交的时间戳比完成度百分比更早给出信号，停在几年前的那些，多半是当初那个人不做了。

顺带说，这17份的通过率并不高。做这件事和做成这件事，中间还隔着前面讲的那道熟练度的坎。

## 为什么说这个库的产能，取决于那一年谁正好在做项目？

## 逐年看提交量最大的那个人

把616份按年份拆开，看每一年提交量最大的那个人占了多少。

2007年全年140份，一个人提了39份。2013年全年25份，一个人提了15份。2019年全年45份，一个人提了31份，占了那一年的近七成。2021年26份，一个人11份。2022年21份，一个人9份。

每一年参与的人数也很少：2018年只有6个人提过申请，2008年8个人，2013年8个人，2021年8个人。人数最多的一年是2007年，31个人。

换句话说，这份决定全世界语言编号的清单，每一年的更新量取决于那一年有没有一两个人正好在做一个大项目。

## 那两个占比归零的年份，其实是换了个人

前面提到修正尺子之后，那家机构的占比在三成到九成之间波动。波动里有两个低点：2013年和2019年，占比都是0。

这两年不是没人申请。2013年是那位澳大利亚教授一个人提了15份，2019年是一位用gmail的独立研究者提了31份。占比归零不是因为主力退场，是因为那一年正好有另一个人在批量提交，把分母撑大了。

这条提醒的是同一件事：占比这种相对指标，在分母很小的时候会剧烈跳动，跳动的原因往往在分母不在分子。

做小语种报表的人对这条应该格外敏感，因为小语种的分母天生就小。一门语言当月的自然流量占比翻倍，多半不是它涨了，是别的语言掉了，或者那个月正好有一次活动。按语言拆开看指标这件事，好处是能看见细节，代价是每个格子的样本量都不够。

做报表的人对这条应该很熟。某个渠道的占比突然掉一半，第一反应通常是这个渠道出问题了，实际上常常是另一个渠道那个月做了活动。

## 这个库的产能是人力驱动的

把逐年的申请量画出来：2006到2008年是高峰，2007年一年140份；之后一路走低，2018年只有7份；2019年因为那位独立研究者又冒起来一次；2020年之后每年二十几份。

这条曲线跟世界上还剩多少门语言没有代码没有关系，跟有多少人在做这件事完全对应。它量的不是需求，是供给。

## 拿这条曲线去推别的结论会翻车

这条曲线很容易被误读成语言发现的速度，或者世界语言多样性被记录的进度。两个读法都不对。

正确的读法只有一个：它是这几十个人的工作日程表。项目开工，曲线抬头；项目结题，曲线落地。中间那门语言存不存在、有没有被记录的需要，跟曲线的形状没有关系。

凡是由少数人产出的公开数据，它的时间曲线首先反映的是这些人的排期，其次才是外部世界。本站量小语种内容量跟编辑人数的关系 (https://zhangwenbao.com/minor-language-content-volume-editor-count.html)时得到的是同一个形状：内容曲线的拐点对应的从来不是需求变化，是那几个活跃编辑的进出。

上一篇提过这个库已经从造语言转成了改名字：十八年新建944个代码，前六年占了六成。现在可以补一句原因——不是该建的都建完了，是集中做这件事的那批项目结束了。

## 这件事对做小语种SEO的人有什么用？

## 用法一：查一下你的语言最近有没有被人动过

这个库的变更申请索引 (https://iso639-3.sil.org/code_changes/change_request_index)可以按年份翻，每一条都能点进去看申请人和结果。

动作很简单：搜一下你在做的那门语言，看最近十年有没有出现在申请里。出现过，说明它的边界或者名称最近被动过，你手上那份词表的口径可能已经旧了。

没出现过反而是好消息。这跟上一篇给的判据一样，只是这次多一个维度：不只看有没有申请，还要看提申请的是谁。如果是那家机构在做例行登记，多半不影响你；如果是本地社群在争一个独立代码，那这门语言的市场边界可能正在变。

判据可以再具体一点：申请人是机构、变更类型是创建，通常是补登记，跟你无关；申请人是个人或本地组织、变更类型是拆分，那就要看一眼，因为拆分意味着有人认为现在这个代码盖住了两拨不同的人。

举个具体的：如果你做的品类涉及某个正在争取独立代码的地区变体，那说明当地人认为自己说的不是那门大语言。这个认同差异会直接反映在他们用什么词搜索上。

## 用法二：别把标准里的地位当成市场规模的代理

这一条上一篇说过一次，这一篇的数据从另一个角度支持它。

一门语言有没有代码、代码分得细不细，取决于有没有人去做过调查，跟这门语言有多少人说、有多大商业价值几乎无关。壮语被切成十几个代码不是因为它商业上重要，是因为2007年正好有一个项目在做那一带。

反过来，某门语言在这份清单里只有一个笼统的代码，也不代表它内部没有分歧。只代表还没有人去分过。

这一条在做关键词表的时候最容易吃亏。你按代码建了一套词表，以为覆盖了这门语言的全部使用者，实际上那个代码底下装着两三拨说法不同的人。同一门语言在不同市场的搜索意图差异 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)那一篇讲的就是这种情况，只是那一篇是从需求侧发现的，这一篇是从供给侧解释了它为什么会发生。

所以做语种优先级的时候，这份清单只能当成一份存在性名单，不能当成一份重要性排序。真正的排序要用需求侧的数据，那套方法在小语种优先级的成本模型 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)那一篇里。

## 用法三：数据同源这件事怎么绕

前面说过整条链上只有一家。这对你的实际影响是：你没法用两份独立的数据互相验证一门语言的基本信息。

能绕的办法有两个。一是换一类数据源：不看语言学数据库，看这门语言在实际系统里的落地情况——界面语言清单里有没有它、区域数据填了多少、词典文件更新到哪一年。这几层的数据来自完全不同的组织，跟码表没有同源问题。

这几层还有个好处：它们回答的是能不能用，而码表回答的是存不存在。做项目排期的时候，前者比后者有用得多——一门语言在标准里存在了二十年，不代表你的技术栈今天支持它。

二是看需求侧：搜索量、本地媒体的用词、当地零售商的商品分类名。这些数据不关心这门语言在标准里叫什么，只反映人实际怎么说话。

本站量过几层这类数据，比如界面语言包的完成度 (https://zhangwenbao.com/minor-language-interface-translation-coverage.html)和区域格式数据的自有率 (https://zhangwenbao.com/minor-language-locale-data-inheritance.html)，两层都能当交叉验证用。

## 用法五：这套读法可以搬到别的注册库

这一篇真正可以复用的不是那几个数字，是读一个注册库的方法。

任何一个把决定过程公开归档的机构，都能这么读：先看谁在提，再看提的人分几类，然后按类别算通过率，最后看每一年的量取决于谁。四步做完，你就知道这份数据的边界在哪。

能这么读的库不止这一个。域名争议的裁决库、标准组织的提案库、平台的政策变更记录，结构都类似。公开归档的不是全部事实，是被记录下来的那部分事实，而记录的密度取决于有多少人在参与。

顺带说一句实际的：这类库还有一个用法是查对手。如果你的品类涉及某个需要注册或备案的环节，去翻那个环节的公开档案，能看到同行在什么时候做过什么动作，比任何行业报告都具体。

## 用法四：如果你真的要提一份申请

前面那三条打脸的发现，正好可以倒过来当建议用。

第一，先确认变更类型填对了。创建、拆分、合并、修改、注销，五种的举证要求完全不同，拆分最难。第二，别为了显得郑重去拉一堆人联署，也别把表格填成论文。第三，把力气花在唯一那条硬判据上——互不相通，而且要有可核查的证据，不是印象。

第四，也是最实际的一条：找一个提过十次以上的人合作。数据摆在那里，第一次自己提的通过率是27.4%，找个熟手是73.0%。

不过讲真，对绝大多数做跨境电商的读者来说，这一条的价值不在于真去提申请，而在于理解一件事：你以为的国际标准，很多时候是几十个人的工作量堆出来的。

## 常见问题解答

## 这616份是全部的语言代码申请吗？

不是。这616份是附了单独申请表的部分，主要对应创建新语言代码这一类。合并、注销、改名这几类通常不需要单独附表，信息直接写在主申请里。整个库的申请总数比这个大，上一篇统计的是1423条申请、2250行变更。

## 为什么截到2022年，不看最近几年？

因为2022年之后的附件在库里还没铺全，逐年抓下来会有缺口。用一个样本不完整的年份去算占比，很容易算出一个假趋势——这一篇里已经因为格式变更栽过一次，不想再栽第二次。

## 那家机构占比这么高，这份清单可信吗？

可信度和独立性是两件事。这批申请的专业水准没有问题，做调查的人是这个领域里最有经验的一批。有问题的是你没有第二个独立来源可以拿来对照，所以任何基于它的判断都要留一点余量，尤其是涉及语言数量、语言划分这类结论的时候。

## 中国境内的语言，国内有机构在做这件事吗？

就这616份表格的署名来看，2006到2022年之间没有来自中国境内邮箱的申请。这不代表国内没有相关研究，只代表这些研究没有走这条国际登记的通道。这两件事是分开的：国内的语言调查成果和国际标准里的登记，之间没有自动的传递机制。

## 我做的语言在这个库里查不到任何申请，说明什么？

说明它的登记信息在这些年里是稳定的，你按现有代码建的一切不会突然失效。这是好消息。要注意的只有一点：稳定不等于准确，也可能只是没有人去核过。

## 提交一份申请要等多久？

中位数大约一年。这个库一年只发布一到两次变更，所以实际等待时间取决于你提交的时点离下一个生效日有多远。极端的例子上一篇提过，有一份申请等了十七年才有结果。