# 保哥笔记 — 小语种SEO > 本分片含 35 篇文章，按发布日期倒序。全部分片索引见 https://zhangwenbao.com/llms-full.md **站点**：https://zhangwenbao.com/ **分类**：小语种SEO **生成**：2026-09-12 13:06:31 CST --- ## 小语种站的品牌名能规定一种写法，作者的名字规定不了，本地媒体里早有另一种拼法 - URL：https://zhangwenbao.com/minor-language-eat-local-author-byline-credential-signals.html - 分类：小语种SEO - 发布：2021-06-24 | 更新：2026-07-27 - 摘要：小语种站的作者名不能像品牌名那样统一写法。讲清几种拼法怎么汇总并共现、站外足迹的三档判据、四种署名模型里为什么双署名最优，以及资质为什么不能跨国搬。 - 关键词：内容质量,出海SEO,多语言SEO,小语种SEO > **TLDR**：摘要：品牌名在小语种市场可以由公司定一种主写法，其余写法当变体覆盖，因为命名权在公司手里。作者的名字没有这个待遇：这个人在本地媒体、行业名录、学术论文、社媒上已经用了三四种拼法，而专业度与权威度这套信号恰恰要靠站内署名跟站外足迹能对上。所以人名的解法不是统一，是全部收进来——本地字母做主显示，其余已存在的写法进别名字段，站外足迹用同一个标识串起来。另外两笔：挂一个母语者的名字上去，失败点不是读者不信，是站外一条本语言足迹都查不到；资质由国家授予，本地用户认的不是徽章，是能对着公开库查的号码。 > 摘要：品牌名在小语种市场可以由公司定一种主写法，其余写法当变体覆盖，因为命名权在公司手里。作者的名字没有这个待遇：这个人在本地媒体、行业名录、学术论文、社媒上已经用了三四种拼法，而专业度与权威度这套信号恰恰要靠站内署名跟站外足迹能对上。所以人名的解法不是统一，是全部收进来——本地字母做主显示，其余已存在的写法进别名字段，站外足迹用同一个标识串起来。另外两笔：挂一个母语者的名字上去，失败点不是读者不信，是站外一条本语言足迹都查不到；资质由国家授予，本地用户认的不是徽章，是能对着公开库查的号码。 ## 品牌名那套统一写法的办法，为什么在人名上就不成立？ ## 品牌名的命名权在公司手里，人名的不在 小语种市场的品牌名有一套成熟解法：挑一种主写法定死，其余写法做变体覆盖。 这套解法能成立，前提是命名权在公司手里。 公司可以发一份规范，规定本地语言的官方写法是哪一种，全站统一，对外沟通统一。 时间一长，用户和媒体也会跟着用这一种。 作者的名字没有这个前提。这个人的名字怎么写，不由你的站决定。 他的护照、他发表过的论文、当地媒体报道他时用的拼法，都已经写定了。 这个差别看起来只是所有权归属的问题，落到操作上后果很大：品牌名可以做收敛，人名只能做汇总。收敛是选一个、放弃其余；汇总是全都留着、指定一个当门面。两个动作在字段设计、在页面呈现、在外链锚文本上的做法完全不同。品牌名叫什么由当地用户的输入法决定 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)那篇讲的是收敛怎么做，本文讲的是汇总怎么做。 ## 一个作者的名字在站外已经有了三四种写法 拿一个俄罗斯的作者举例，一个常见的名字在站外能有这么几种存在形态。 护照上是按官方转写规则拼的拉丁形态。 本地行业媒体报道他时用的是西里尔字母原文。 他早年发在国际期刊上的论文用的是另一套学术转写，跟护照那套差一两个字母。 社交平台上他的用户名是个缩写加数字，跟真名的关联要点进主页才看得出。 四种写法都真实存在，都能被搜到，也都指向同一个人。 问题在于机器不知道它们是同一个人。搜索引擎判断实体身份靠的是这些字符串在网上的共现关系——如果四种写法从来没在同一个页面上一起出现过，那它们在引擎眼里可能就是四个人，每个人各有一点点站外痕迹，加起来的权威度还不如一个人。把它们放在一起出现，是你唯一能主动做的事。 ## 统一不了，就只能全都收进来 既然改不了站外，那就在站内把四种写法聚齐。 作者页是唯一合适的位置，它就是这个人在你站上的身份档案。 页面上显示一种，其余写法放进标记的别名字段。 别名字段可以放多个值，这一点跟品牌名的处理是一样的。 再用一个字段把站外那几处足迹指出来：媒体报道页、行业名录条目、学术档案。 这一组信息合起来，就是让四个字符串在机器眼里收敛成一个人的最短路径。 别名这个字段的定义 (https://schema.org/alternateName)本身没有数量限制，写三四个值完全正常。要注意的只有一点：别把明显不属于这个人的写法塞进去凑数，比如把同名同姓的另一个人的拼法也放进来。这个字段的作用是消歧，塞了噪音就变成了制造歧义。 汇总这个动作有个上限：别把每一种能想到的拼法都收进来。判据是这种写法在站外有没有实际存在的痕迹——有报道、有条目、有作品用了它，就收；纯粹按规则推导出来但网上找不到的，不收。收了后者不会带来关联，只会让这个字段变成一份转写练习。 ## 收进来之后要指定一个主显示形态 汇总不等于全都平等展示。 页面上必须有一个主显示形态，就是署名那一行印出来的那个。 其余写法只在标记里，不在可见文字里。 主形态一旦定了就别改，改了会让外链锚文本和历史引用都对不上。 这个选择的判据不是哪种写法最正式，是这个作者页主要给谁看。 下一节专门讲这个判据。 提醒一句主形态和文件名、URL那一层不是同一件事。显示形态用本地字母，作者页的URL仍然可以走拉丁转写，两者不必一致，理由跟图片那边一样。同一张图的文件名和alt被迫用两套字母写同一个词 (https://zhangwenbao.com/minor-language-image-alt-text-non-latin-script-search.html)是同一个结构：可见层跟着用户走，地址层跟着可读性和可追踪性走。 ## 作者名的写法冲突是从哪几个地方来的？ ## 证件上的拉丁拼法 第一个来源是官方转写，也就是护照、签证、银行账户上的那种拼法。 各国的官方转写规则不同，有的按本国标准，有的按国际标准。 同一个名字在不同年份签发的证件上，拼法都可能不一样，因为规则改过。 这种拼法的特点是稳定、正式、但对本地用户来说很陌生。 本地人日常不会用这种写法称呼一个人。 它在你站上的价值主要是跨境场景：合同、发票、跨国合作页面。 官方转写有一个实用属性：它可逆或者接近可逆，所以适合做机器用的稳定标识。作者页的URL、内部数据库的作者键、跨语言版本之间的关联字段，都适合用它。它不适合当署名那一行的显示文字，因为它读起来不像一个本地人的名字。 ## 本地媒体和行业名录的拼法 第二个来源是本地媒体，这也是最有价值的一种。 如果这个人被本地行业媒体报道过、在行业协会名录里有条目，那里的写法就是本地共识。 这种写法通常是本地字母原文，或者本地习惯的简写形式。 它的价值在于它已经跟一批可验证的内容绑定在一起了。 换句话说，这种写法背后有站外足迹，其余几种可能没有。 所以主显示形态优先取这一种，不是取证件上那一种。 找这类写法的办法很土：拿这个人的名字在本地搜索引擎和本地行业站上搜一遍，看报道里怎么写。本地名录、媒体与社群那条渠道清单 (https://zhangwenbao.com/minor-language-link-building-local-directories-media-communities.html)本来是做外链用的，找作者足迹时也是同一批入口，顺手能一起做完。 本地媒体那一种写法还有个附带用途：它是外链锚文本最该用的形态。别人引用这位作者时，用的大概率是他在本地已经流通的那个名字，你自己在对外投稿、做访谈、给合作方发素材时也该统一用它，这样几年下来这一个字符串上会累积起最厚的一层痕迹。 ## 学术署名与社媒用户名 第三类来源是学术署名和社媒用户名，它们的形态更零散。 学术署名多半是拉丁转写，而且常常只给名的首字母。 期刊数据库里的转写规则跟护照那套不完全一样，容易差一两个字母。 社媒用户名跟真名的关联更弱，有时只是一个昵称。 这两类写法通常不适合进别名字段，除非它们本身有足够的可见度。 它们更适合作为足迹被指出来，而不是作为名字的变体被收录。 学术这一头有一个现成的工具能直接解决同名歧义：给研究者分配唯一标识的那套公开档案 (https://info.orcid.org/what-is-orcid/)。如果你的作者有这么一个标识，把它当成足迹指出来，比列举三种转写拼法有用得多，因为它是一个全球唯一的串，天然免疫拼写差异。 ## 站内主署名该用本地字母还是拉丁转写？ ## 判据是这个作者页要给谁看 这个选择容易被当成偏好问题，其实有明确判据。 问一句：来这个作者页的人主要是谁。 如果主要是本地用户在判断这篇内容可不可信，那用本地字母。 如果主要是国际合作方在核实这个人的资历，那用拉丁转写。 绝大多数小语种站属于前者，所以答案通常是本地字母。 例外是那种主要面向跨境采购的B2B站，作者页的访客里外国人占多数。 判据落地时还要看一个数字：这个作者页有多少流量是从本地搜索来的。本地搜索来的流量占多数，说明它已经被本地检索体系认成本地内容，主显示形态就该跟本地检索的口径一致。这个数据在流量报表里查作者页的着陆来源就能看出来，不需要额外埋点。 ## 本地字母做主显示，拉丁转写做别名 定下来之后的落地很简单。 署名那一行、作者页的标题、文章底部的作者卡，全部用本地字母。 拉丁转写放进别名字段，同时在作者页的简介里自然地提一次。 提的方式不需要刻意，写成括号里的原名或者国际场合用的拼法都可以。 这样两种写法在同一个页面上共现了，机器能建立关联。 共现这一步是整套做法里最关键的动作，比字段填得多齐都重要。 有个细节容易被漏掉：这两种写法要出现在同一个页面上，而不是分散在作者页和某个国际版页面上。分散在两个页面，共现关系就弱了很多。最省事的做法是在作者页的第一段里把两种写法都写一遍，一句话解决。 别名字段里各种写法的排序也有点讲究：把最可能被外部引用的那一种放在第一个。多数消费方在取值时只读第一个，排在后面的等于只对逐个遍历的程序有效。这条细节不影响正确性，但它决定了别名字段在实际抓取里能起多大作用。 ## URL那一层跟显示层要分开决定 作者页的URL用拉丁转写，理由跟图片文件名一致。 本地字母的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)那条经验在这里的对应说法是：母语者愿意署名，也不能当成信任信号已经建立。 ## 足迹的三档判据 把足迹分成三档，判断一个作者候选值不值得用。 第一档是零足迹：搜这个名字只搜到你自己站上的页面。 第二档是有社媒或者行业站足迹：他在本地平台上用这门语言发过内容，有可见的痕迹。 第三档是有本地权威媒体或者机构足迹：被本地行业媒体引用过、在协会名录里有条目、有可查的资质编号。 三档对应三种不同的用法，不是简单的好坏排序。 第三档的人贵且难找，第一档的人便宜但不能单独署名。 档位 | 站外足迹 | 能怎么用 | 不能怎么用 | 零足迹 | 只有你站上的页面 | 做本地复核并在页面上标出复核角色 | 单独署名为作者 | 有社媒或行业站足迹 | 本地平台有本语言内容 | 署名为作者，简介里链到那些痕迹 | 用于高风险品类的核心页 | 有权威媒体或机构足迹 | 被本地媒体引用、名录有条目、资质可查 | 署名为作者并承担高风险品类 | — | 这张表的实际用法是招人时先问一句：你之前用这门语言公开发表过什么，能不能给我看两个链接。答不上来的人不是不能合作，是只能安排在复核这个角色上。这一问能在合作开始前就把角色定清楚，比事后发现署名撑不起来再返工便宜得多。 ## 足迹必须是用这门语言留下的 有一个容易被跳过的限定：足迹要跟内容用的是同一门语言。 一个人在英文行业媒体上很活跃，但从来没用本地语言写过东西，这份足迹在本地市场的说服力有限。 反过来也成立：一个只在本地社群活跃、没有任何英文痕迹的人，在本地市场的说服力可能更强。 判断的角度是本地用户会怎么核实，而本地用户核实时用的是本地搜索和本地平台。 所以足迹的语言比足迹的国际知名度更要紧。 这一点在招人时经常判断反，因为国际知名度看起来更硬。 说清楚这条限定的价值在于它会改变你的招人渠道。按国际知名度招，你会去国际职业平台上找；按本地足迹招，你得去本地的行业社群、本地媒体的作者页、本地协会的名录里找。后者难一些，但找到的人质量对得上你的实际需求。 还有一种混合情况值得单独判断：这个人用本地语言写过东西，但发在一个国际平台上。这种足迹算不算本语言足迹，看的是本地用户能不能在本地搜索里找到它。找得到就算，找不到就等于不存在——足迹的有效性取决于可发现性，不取决于它托管在谁的服务器上。 ## 零足迹的作者怎么补 零足迹不是永久状态，它可以补，但要时间。 最快的一条是让他以本人身份在本地行业社群里回答几个专业问题。 第二条是让他在本地行业媒体上发一篇署名文章或者接受一次访谈。 第三条是把他在协会、执业机构、教育机构的现有条目找出来，那些可能已经存在只是没人搜过。 三条的共同点是它们都在站外，你不能在自己站上造足迹。 时间尺度通常是三到六个月，所以这件事要提前排。 提前排的做法是：签合作时就把公开露面这件事写进合作内容，而不是等内容上线半年后发现权威信号不够再去补。作者署名怎么做才被认可那六个信号 (https://zhangwenbao.com/author-byline-entity-eeat-ai-citation-content-mechanism.html)讲的是通用机制，小语种这边的差别只有一个：足迹必须是本语言的，所以能用的平台和媒体是另一批。 ## 原作者、译者、本地审校，署名只能写一个的时候写谁？ ## 三个角色各自承担什么 小语种内容通常有三个人参与，英文站只有一个。 原作者负责观点、结构和专业判断，通常不懂目标语言。 译者负责语言转换，专业深度一般不如原作者。 本地审校负责地道程度、本地法规与习惯的对齐，专业深度介于两者之间。 三个人对内容的贡献不一样，对信任信号的贡献也不一样。 署名只写一个人的时候，写谁就等于宣称谁是这份内容的责任人。 这就是小语种内容跟英文内容在署名上最根本的差别：英文内容的作者是唯一责任人，署名没有歧义；小语种内容的责任被三个人分担，署名却只有一行。这一行怎么写，是个既涉及诚信又涉及信号强度的选择，而绝大多数站是随手写的，没有做过这个选择。 ## 四种署名模型 把可选做法列出来只有四种。 第一种只署原作者，不提译者和审校。诚信上没问题，本地信任信号最弱。 第二种只署本地审校者为作者。本地信任最强，但把不是他写的内容挂到了他名下。 第三种双署名：原作者撰写，本地专家复核，两个人都出现。 第四种署机构不署人，比如署编辑部或者某个团队名。成本最低，权威度上限也最低。 四种模型的成本、诚信度、信号强度各不相同，得按品类和风险选。 模型 | 页面上怎么显示 | 本地信任信号 | 诚信风险 | 适合的品类 | 只署原作者 | 作者：原作者 | 弱 | 无 | 低风险的通用内容 | 只署本地审校 | 作者：本地专家 | 强 | 高，风格与其他作品对不上 | 不建议 | 双署名 | 撰写：原作者　本地复核：本地专家 | 强 | 无 | 大部分内容，尤其高风险品类 | 署机构 | 作者：某编辑部 | 中 | 无 | 产品说明、政策页、帮助文档 | 第二种模型的诚信风险值得多说一句。它的暴露方式不是有人举报，是这个本地专家自己的其他作品跟这批内容的风格、深度、关注点对不上。评估的一方如果顺着这个人的名字去看他别的东西，很容易看出这批内容不像他写的。这个不一致比署一个不认识的名字更伤，因为它同时损害了这个人本来有效的那份足迹。 ## 双署名为什么是唯一既不撒谎又建立本地信任的那种 双署名把三个角色的贡献都摆在明面上。 原作者的专业深度被保留，本地专家的本地资质被利用。 读者知道这份内容的观点来自谁、本地适用性由谁把关。 评估的一方也能分别核这两个人，两条足迹都能用上。 最重要的是它不需要任何虚构，页面上写的每一句都是真的。 成本上它只比单署名多一个复核环节，而这个环节本来就该有。 还有一个附带好处：双署名让本地专家更愿意合作。让一个真有资质的人把自己的名字挂在一篇不是他写的文章上，稍有职业顾虑的人都会犹豫；让他以复核者的身份出现，同时可以要求他真的复核一遍，双方都轻松。这个角色定位上的小改动，能显著扩大你能招到的人的范围。 双署名还有一层容易被忽略的收益：它把内容质量的责任落到了具体环节上。出了问题能查清是观点错了还是本地适用性没核对，追溯路径清楚。单署名的内容出问题只能整篇背锅，既不好复盘也不好改进流程，这在需要长期维护的品类上差别很明显。 ## 署机构不署人什么时候是对的 署机构不是偷懒的选项，它在某些页面类型上是最合适的。 产品说明、退换货政策、配送说明这类页面，读者要的是站方的承诺而不是某个人的判断。 帮助文档和常见问题也类似，署一个人反而奇怪。 这类页面署编辑部或者客服团队，比硬找一个作者更诚实。 判据是这页内容是不是表达了某个人的专业判断。 是就署人，不是就署机构。 一个常见的误区是把全站都改成署人，理由是署人的权威度信号更强。实际上在不该署人的页面上署人，会让整套署名体系显得随意，反过来削弱那些真正需要人名背书的页面。信号的强度来自它的选择性，全站一律署人等于没有选择。 ## 双署名怎么落到字段上才不含糊？ ## 撰写、翻译、复核三个角色对应三个字段 页面上写清楚了，标记里也要对得上。 撰写者放作者字段 (https://schema.org/author)，这是它本来的用途。 译者放译者这个字段 (https://schema.org/translator)，很多人不知道它本来就有，于是把译者塞进了作者。 本地复核者放贡献者字段，它的语义足够宽，能容纳复核这个角色。 三个字段的取值都是人物对象 (https://schema.org/Person)，各自可以带自己的别名和足迹链接。 三个字段填齐，一份内容的责任链在机器可读的层面就完整了。 译者这个字段是本节最实用的一条：它是标准词汇表里现成的属性，专门用来表示把作品译成当前语言的那一方。多语言站几乎没人用它，多数团队要么不填，要么把译者当作者填。填对它的收益不是立刻可见的排名，是让这份内容的生产链条在标记层面不再撒谎，同时把译者本人的足迹也接进来。 ## 页面上怎么写这一行才不别扭 字段是给机器的，页面上那一行是给人的，两者要分别设计。 最简洁的写法是两行：一行写撰写者，一行写本地复核者。 不要写成一长串三个人并列，读者分不清谁做了什么。 复核者那一行后面可以带上他的资质或者机构，一句话讲清他凭什么复核。 如果有译者且译者本身有资质，也可以单独列一行。 没有资质的译者不必出现在可见文字里，标记里填了就够。 这一行的位置放在正文开头比放在文末效果好。读者判断要不要读下去的时候就看到了责任人，而不是读完才发现。做家用血压计这类品类的站尤其要放在前面，因为读者在开头几秒就在决定这个信息可不可信。保哥给一个卖家用医疗器械的客户改过这一处，署名行从文末挪到标题下面，页面停留时间的变化很明显。 ## 别把复核写成审稿人这种含糊说法 可见文字里的角色名称要具体，别用含糊词。 审稿、把关、监制这类词读者看不出实际做了什么。 写成本地复核、本地适用性审核、按本地法规核对，都比审稿具体。 具体的说法能让读者判断这个复核的价值，含糊的说法只能让人觉得是走过场。 翻译成各语言时这个词更要挑，有些语言里对应的词带有明显的形式主义意味。 这一步要交给本地审校本人来定词，他知道哪个说法听起来是真在做事。 顺着这条再往前一点：如果复核确实只是走过场，那就别写。写了一个含糊角色，评估的一方会顺着去查这个人，查出来他跟这个领域没什么关系，损失比不写更大。角色名称的具体程度应该跟实际投入匹配，这条规矩听起来像常识，但它是这一节里最容易被违反的一条。 角色名称还要考虑一件事：它在这门语言里的搭配是否自然。有些语言把复核这个动作的名词形式写出来会显得非常官腔，本地读者读到会觉得像在看公文。这种情况下改成一句话说明比用一个名词更好，比如直接写这份内容由某人按本地规定核对过，读起来是人话。 ## 资质为什么不能跨国搬？ ## 资质是国家授予的，名称和门槛都不一样 英文的权威度手册会说展示作者的资质与认证，这句话本身没错。 问题是资质由国家或者国家授权的机构颁发，跨境不通用。 会计这一行，美国的执业资格和印度的注册会计师是两套体系，考试内容和执业范围都不同。 法律、医疗、税务、工程，情况都类似。 所以英文站上那个资质缩写，搬到本地页面上本地用户不认。 要展示的是这个市场自己的那一套。 这件事有个不太直观的后果：你的内容团队里那位很有资历的国际专家，在本地市场的资质栏里可能一片空白。这不是他不专业，是他的专业凭证在这个市场没有对应项。所以双署名模型里那位本地复核者的价值，很大一部分就是把资质栏填上——他有那个市场认的东西。 还有一类资质是行业自律组织颁的，不是国家颁的，它的可信度取决于这个组织在本地的认可度。判断办法是问本地同行知不知道这个组织，知道且认的就能用，本地人都没听说过的国际认证就别摆上去了——它占了版面又提供不了信任，还会让懂行的读者觉得你在虚张声势。 ## 翻译与本地化这一行的资质有哪些 如果你的内容主要是译文，那译者和审校的资质本身就是可展示的信号。 这一行有几个国家级的行业组织，会员资格是公开可查的。 英国有语言学会的特许会员资格 (https://www.ciol.org.uk/)和笔译口译协会的认证会员 (https://www.iti.org.uk/)两套体系。 德语市场有全国性的笔译口译联邦协会 (https://bdue.de/)，会员名录对外开放。 还有面向翻译服务流程的国际标准，服务商拿到认证后可以在页面上说明。 这些东西的共同点是可查：给出名字和会员编号，对方能在官方名录里核到。 翻译质量本身也有公开的评价框架可以引用，比如那套多维度质量错误类型学 (https://themqm.org/error-types-2/typology/)。在页面上说明你的译文按哪套框架验收，比笼统地说经过母语专家审校要具体得多。机器翻译直接发上线那笔账 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)算的是省下审校的代价，这一节算的是把审校做实之后怎么把它变成可见的信任信号，两笔账正好接得上。 ## 医疗、财税、法律类品类的额外要求 高风险品类对作者资质的要求明显更高。 家用医疗器械这类内容，本地读者会看写的人有没有临床或者器械相关背景。 财税内容会看有没有本地执业资格，比如印度那家注册会计师协会 (https://www.icai.org/)颁的那种，法律内容会看有没有本地律师资格。 这些资质不但要有，还要能在本地的公开注册库里查到。 本地读者查的时候用的是本地的库，不是国际数据库。 所以资质展示的落点是号码和可查的名录条目，不是一段自述。 高风险品类还有一个具体做法值得抄：把复核者的资质写在页面上，同时把他复核的日期也写上。日期这一项在医疗和财税类内容上格外有用，因为这类信息会过期，而读者最想知道的就是这份内容是按哪个时间点的规定核对的。质量评估指南那份自查清单 (https://zhangwenbao.com/search-quality-rater-guidelines-qrg-seo-self-review-checklist.html)里对高风险主题的要求，落到小语种站上主要就是加这两项。 ## 本地用户真正认的是徽章还是注册号？ ## 徽章可以做图，号码能对着库查 信任元素里最常见的做法是放一排徽章。 徽章的问题是它可以做图，谁都能画一个。 有经验的本地用户对徽章的信任度不高，因为他们见过太多假的。 注册号不一样：它是一串可以输进官方查询页的字符。 能查到就是真的，查不到就是假的，判断成本几乎为零。 所以在很多市场，一个不好看的注册号比一排精致的徽章更有说服力。 这条判据可以推广成一句话：信任标记的价值跟它的可验证性成正比，跟它的视觉精致度无关。按这个标准重新审一遍你的页面，会发现最占版面的那些元素往往是最不可验证的，而最有说服力的那几个字符串常常被排在页脚最底下的小字里。 徽章不是完全没用，它的作用是让页面在视觉上传达出这里有资质信息这个印象，读者的第一眼确实需要这个提示。正确的组合是徽章加号码加可点击的查询链接三件套：徽章负责被看见，号码负责被验证，链接负责把验证成本压到最低。只有徽章那一层的话，等于只做了第一步。 ## 各市场的注册号长什么样 不同市场的号码体系差异很大，形态也很不一样。 德语市场有商业登记号，配合法定的信息披露页一起出现。 俄语市场有纳税人识别号和统一登记号两套，位数不同用途不同。 印度市场有商品服务税号，格式固定，能对着官方的税务门户 (https://www.gst.gov.in/)查。 还有一些市场把执业个人的资质编号也做成公开可查的，英国那边笔译口译协会的认证会员名录 (https://www.iti.org.uk/)就是这样。 做哪个市场就查那个市场的号码体系，这件事没法通用。 市场 | 常见的可查号码 | 放在哪里 | 德语市场 | 商业登记号 | 法定披露页加页脚 | 俄语市场 | 纳税人识别号、统一登记号 | 页脚加关于我们 | 印度市场 | 商品服务税号 | 页脚加发票说明页 | 作者个人 | 执业或会员编号 | 作者页的资质栏 | 这张表里最后一行是本文关心的那一行，前三行属于站方的信任元素，本文不细讲。要说的是两者的关系：站方的号码建立的是这家公司可信，作者的号码建立的是这个人可信，两者不能互相替代。一个有完整商业登记信息但作者栏空白的站，在高风险品类上仍然撑不起来。 ## 号码放在哪几个位置 作者的资质编号放在作者页的资质栏，这是主位置。 文章页的署名行可以带一个简短形式，比如资质名称加机构缩写。 不要在每篇文章里都印完整编号，那会显得像在刷证书。 标记里用专门表示资质的字段承载，取值指向那个资质本身。 如果发证机构有公开的会员查询页，把作者页上的资质链到那里。 链过去这个动作比印一个号码更有效，因为它把验证的步骤减到一次点击。 能链就链，这条在小语种站上尤其值钱。本地用户面对一个外国公司的站，本来就带着一点戒心，一个能点过去查证的链接把戒心降下来的效率，比多写三段自我介绍都高。承载资质的那个字段 (https://schema.org/hasCredential)能把这层关系写进标记，页面上的链接和标记里的字段配合起来用。 ## 母语评估员会用什么路径来核你这个作者？ ## 他用的是本地路径，不是英文手册上那套 评估一个页面质量的人，通常是目标市场的母语者。 他核实作者身份时用的是自己熟悉的入口。 英文手册上那套路径——职业社交平台、行业媒体、公司官网团队页——在很多市场不是主渠道，质量评估指南原文 (https://guidelines.raterhub.com/searchqualityevaluatorguidelines.pdf)里的例子也多半取自英语市场。 有些市场职业社交平台渗透率很低，本地人根本不用。 有些市场的行业信息集中在几个本地论坛或者即时通讯群组里。 所以你按英文手册准备的那套证据，评估的人可能一条都不会去看。 这个错位是小语种站在权威度上最容易吃亏的地方：不是你没准备证据，是证据放在了对方不会去的地方。解法是先搞清楚这个市场的人核实一个专业人士时会去哪儿，再把证据放到那儿。这件事只能问本地人，任何英文资料都不会写。 这条错位还有一个反方向的表现：有些市场的读者反而更看重国际证据，因为本地体系他们自己也不太信。这种情况下英文手册那套路径就是对的。所以真正要做的判断不是本地还是国际，而是这个市场的人信谁，而这个问题的答案只能问在当地生活的人。 ## 三条本地核查路径 虽然各市场不同，但常见的路径可以归成三条。 第一条是本地搜索引擎搜名字，看首页有什么。 第二条是查本地的公开注册库，包括商业登记、执业名录、协会会员名录。 第三条是在本地主流社交或者社群平台搜这个名字，看有没有活跃痕迹。 三条路径查的东西不同：第一条查可见度，第二条查资质，第三条查真实性。 三条都空的作者，任何署名策略都救不回来。 把这三条写成一份自查表，招人时和内容上线前各跑一遍。跑起来很快，一个作者十分钟。它的价值在于把一个模糊的够不够权威的判断，变成三个可以回答是或否的具体问题。专业度权威度那套信号到底算不算排名因素 (https://zhangwenbao.com/eeat-ranking-factor-myth-signal-checklist.html)那篇讲了怎么把它落成可执行清单，小语种这边的改动就是把三条路径换成本地版本。 ## 反过来用这三条路径自查 自查的做法很直接：把自己当成评估员，用目标市场的搜索引擎搜一遍。 搜的时候要用本地字母的写法，不是拉丁转写。 看首页十条结果里有几条跟这个人有关。 零条就是零足迹，一到两条是第二档，有媒体或者名录条目就是第三档。 顺手记下这些结果的URL，它们就是作者页上该指出去的足迹。 这个动作每个季度重做一次，因为足迹会增加也会消失。 自查时有一个细节容易忽略：用不同写法各搜一遍。用本地字母搜到三条，用护照拼法搜到另外两条，这五条其实是同一个人的足迹分散在两个字符串上。发现这种分散之后，正确的动作就是本文开头讲的那件事——把两种写法放到同一个页面上共现，让它们收敛成一个人。 ## 作者体系从零到有，六个月里按什么顺序建？ ## 第一个月先把已有内容的责任人认领清楚 大多数小语种站不是没有作者体系，是从来没整理过。 第一个月不做新东西，只做认领：每一批内容是谁翻的、谁审的、谁定的观点。 能查到的记进表，查不到的标成来源不明。 来源不明的那批内容后面要么补复核要么下架，先别急着署名。 这一步的产出是一张内容与责任人的对应表。 没有这张表，后面任何署名动作都是在猜。 认领这一步经常会挖出一批尴尬的内容：既没人翻也没人审，是某次批量导入进来的。这批内容的处理原则是别给它们署人名，先署机构，然后排队做复核。硬给它们配一个作者，等于把这个作者的可信度押在一批没人看过的内容上。 ## 第二到第三个月建作者页与字段 有了对应表，接下来建作者页。 作者页要有的东西：主显示名、别名、简介、资质栏、足迹链接、负责的内容范围。 URL用拉丁转写，一次定死。 标记里把撰写、翻译、复核三个字段接进模板。 文章页的署名行改成两行制，撰写和复核分开写。 这两个月的工作量主要在前端和模板，内容侧只需要提供文案。 建页时把别名和足迹链接放在页面靠上的位置，别塞到最底下。这两项是给机器建立实体关联用的，位置靠上共现关系更明确；同时它们对读者也有用，读者想核实时第一眼就能看到。标记里的字段该按哪套格式写 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)那篇的规则在这里同样适用：人名的显示形态跟着本地走，语言标签和标识符跟着国际格式走。 ## 第四到第五个月补足迹 页面建好了，接下来是最慢的一步。 零足迹和第二档的作者要往上补，办法是站外露面。 本地行业社群回答问题、本地媒体署名文章或访谈、把已有的名录条目找出来。 这三件事的周期是三到六个月，所以要在第四个月就启动。 启动时把它写进作者的合作内容里，不要当成额外的人情请求。 补足迹的进度按季度复查，用上一节那三条路径量。 这一步的性价比会随时间提高。第一个作者的足迹要从零建起，第二个作者可以借第一个的渠道——同一家本地媒体、同一个行业社群，路已经踩熟了。所以作者体系的建设成本也是台阶状的，第一个最贵。 ## 第六个月开始按品类分级要求资质 最后一步是把资质要求跟品类风险绑起来。 低风险品类的内容，作者有第二档足迹就够。 高风险品类必须第三档，而且资质要能在本地注册库里查到。 分级之后，采购作者的预算就有了依据，不再是一个笼统的内容预算。 同时也给内容排期加了一条约束：高风险品类的页面在找到合格作者之前不上线。 这条约束会让某些品类的上线延后，但它换来的是这些页面能长期站得住。 六个月跑完，得到的不是一堆作者页，是一套能持续运转的规则：什么内容署谁、谁能署高风险品类、足迹怎么量、资质怎么查。规则比页面耐用，因为页面会改版，规则会一直在。 分级这件事还能顺手解决一个长期争论：内容量和内容质量哪个优先。分级之后这个问题自动有答案了——低风险品类可以放量，高风险品类必须等人，两条线各按自己的节奏跑。争论之所以一直没结论，是因为它把两类内容混在一起讨论了。 ## 常见问题解答 ## 找一个母语者把名字挂上去，算不算建立了本地信任信号？ 不算，除非这个人在这门语言的网络世界里有可查的足迹。挂名的失败点不是读者不信——普通读者不会去查作者；失败点是评估这个页面的人会去搜这个名字，然后什么也搜不到。搜不到就意味着这个署名提供的信号是零。更麻烦的是不一致：署名是本地人，但行文、举例、单位、法规引用全是从别的市场搬来的，这种不一致本地读者一眼能看出。可行的替代做法是让这个人以本地复核者的身份出现，同时真的让他复核一遍。 ## 作者名到底该用本地字母还是拉丁转写？ 显示层用本地字母，地址层用拉丁转写，两者不必一致。判据是这个作者页主要给谁看：本地用户判断内容可不可信，就用本地字母；主要给国际合作方核资历的B2B站，可以用拉丁转写。剩下那几种写法——护照拼法、学术转写、社媒用户名——放进标记的别名字段，同时在作者页的第一段里把主要的两种写法一起提一次，让它们在同一个页面上共现。共现这一步比字段填得齐更重要，它是让机器把几个字符串认成一个人的最短路径。 ## 译者应该写在哪个字段里？ 标准词汇表里有专门表示译者的属性，直接用它，不要把译者塞进作者字段。把译者当作者填，会让这份内容的责任链在机器可读的层面就是错的，而且浪费了作者字段本该承载的那个人。完整的填法是三个字段：撰写者放作者，译者放译者字段，本地复核者放贡献者字段，三个人各自带自己的别名和足迹链接。页面上可见的那部分不必三个都印，没有资质的译者标记里填了就够。 ## 英文站的作者资质能直接搬到本地页面上吗？ 不能，资质由国家或者国家授权的机构颁发，跨境不通用。会计、法律、医疗、税务这几行尤其明显，同一个职业在两个国家是两套考试、两套执业范围。本地用户不认那个外国缩写，他会去查本地的注册库。所以你那位很有资历的国际专家，在本地市场的资质栏里可能是空的，这不是他不专业，是他的凭证在这里没有对应项。这也正是双署名模型里本地复核者最大的价值——他有这个市场认的东西。 ## 页面上放一排认证徽章有用吗？ 有用但有限，因为徽章可以做图，谁都能画一个，有经验的本地用户对它的信任度不高。真正有说服力的是可以对着官方库查的注册号：给出编号，对方输进查询页，能查到就是真的。判据可以概括成一句话——信任标记的价值跟可验证性成正比，跟视觉精致度无关。按这个标准审一遍页面，往往会发现最占版面的元素最不可验证，而最有说服力的那串字符被排在页脚最下面的小字里。能链到发证机构的查询页就链过去，把验证成本降到一次点击。 ## 零足迹的作者要多久才能补起来？ 通常三到六个月，因为足迹只能在站外长，你不能在自己站上造。可行的三条是：以本人身份在本地行业社群里回答几个专业问题；在本地行业媒体上发一篇署名文章或者接受一次访谈；把他在协会、执业机构、学校的现有条目找出来，那些可能早就存在只是没人搜过。三条都要提前排，签合作时就写进合作内容，不要等内容上线半年后发现权威信号不够再去求人。第二个作者会比第一个快，因为渠道已经踩熟了。 ## 全站都改成署真人是不是更好？ 不是。产品说明、退换货政策、配送说明、帮助文档这类页面，读者要的是站方的承诺而不是某个人的专业判断，署机构比硬找一个作者更诚实。判据很简单：这页内容有没有表达某个人的专业判断，有就署人，没有就署机构。全站一律署人反而会削弱信号，因为署名的说服力来自它的选择性；处处都署，等于没有做过选择，那些真正需要人名背书的高风险页面也就跟着一起被稀释了。 ## 权威参考资料 ## 无糖和含糖在小语种词表里只差三个字母，词干还原把它们并成了一个 - URL：https://zhangwenbao.com/minor-language-negation-affix-exclusion-keyword-trap.html - 分类：小语种SEO - 发布：2021-06-15 | 更新：2026-07-28 - 摘要：无糖在德语是粘在词尾的四个字母，在芬兰语是一个后缀。讲清否定长进词里之后，广告否定关键词、站内搜索排除语法和词干还原器各在哪一步失效，为什么字符串越像语义越对立，以及词表该怎么给否定单独建一个维度。 - 关键词：关键词研究,技术SEO,多语言SEO,小语种SEO > **TLDR**：摘要：无糖、无线、免烫这类否定属性词，在英语里是两个词，在德语里是粘在词尾的四个字母，在芬兰语里是一个后缀。否定一旦长进词里，广告的否定关键词、站内搜索的排除语法、词干还原器全都失效，而失效的方式是把语义相反的两个词判成同一个。本文拆开这条链路上的六个落点，给出一份不需要懂那门语言就能跑的自检办法。 > 摘要：无糖、无线、免烫这类否定属性词，在英语里是两个词，在德语里是粘在词尾的四个字母，在芬兰语里是一个后缀。否定一旦长进词里，广告的否定关键词、站内搜索的排除语法、词干还原器全都失效，而失效的方式是把语义相反的两个词判成同一个。本文拆开这条链路上的六个落点，给出一份不需要懂那门语言就能跑的自检办法。 ## 无糖这两个字，在小语种里未必是两个词 ## 德语的frei是后缀不是一个独立的词 德语说无糖写成zuckerfrei，一个词，中间没有空格也没有连字符。 无麸质是glutenfrei，无咖啡因是koffeinfrei，构词方式完全一样。 这个frei单独拿出来确实是个词，意思是自由，但在这里它已经是后缀。 后缀和词的差别不在语感上，在处理上：后缀不能被空格切开。 凡是靠空格找边界的程序，看到zuckerfrei只会看到一个整体。 德语还有另一族否定后缀，比如无线写成kabellos，防水写成wasserdicht，构词逻辑跟frei那一族一样但用的是别的成分。这意味着你没法靠维护一张后缀清单来穷举，因为这类成分在德语里是开放的，新的组合随时会出现。 更麻烦的是同一个概念常常有两种写法并存，一种是后缀式的一个词，另一种是介词短语的三个词。两种写法的搜索量分布往往差得很远，而如果你只覆盖了其中一种，那就等于放弃了另一半。 ## 芬兰语的ton把否定压进了词尾 芬兰语的无糖是sokeriton，含糖是sokerillinen，两个词共用同一个词干。 词干是sokeri，也就是糖，后面接的那几个字母决定了意思是有还是没有。 这两个形态在字符串上极其接近，前六个字母一模一样。 而它们表达的是一对完全相反的意思，中间没有任何过渡地带。 芬兰语的这个后缀还会跟着元音和谐变形，同一个否定后缀有两个形态。 更进一步，芬兰语的名词有十几个格，每一个格都会给这个否定形态再加一层结尾。于是同一个概念在真实文本里能写出十几种形态，而这十几种形态全都以同一个词干开头，跟含糖那一族的十几种形态混在一起。 这种情况下，任何按前缀匹配的逻辑都会把两族词一起捞出来。搜索建议、自动补全、站内搜索的模糊匹配，全部会同时返回意思相反的两组结果，而系统本身完全不知道自己做错了什么。芬兰语词干本身的变化另见芬兰语十五个格与词干交替的处理办法 (https://zhangwenbao.com/finnish-seo-fifteen-cases-consonant-gradation-keyword.html)。 ## 英语的sugar-free为什么是个例外 英语的sugar-free中间有一个连字符，某些写法里干脆是两个词。 这个连字符不是装饰，它是一条机器能看见的边界。 因为有这条边界，英语的否定属性词可以被切分、被排除、被单独统计。 英语的常见否定成分数量有限，前缀那几个加上free这一族，基本能列完。 所以英语站上从来不需要专门处理否定这件事，它是自动被处理掉的。 问题在于，正因为英语从来不需要处理，所有以英语为默认假设写出来的工具、语法和最佳实践，都没有为这件事预留位置。你不会在任何一份广告投放手册里读到否定词可能不是一个独立词元这句话，因为写手册的人从来没遇到过。 这条判据可以直接拿来筛语种：把你的目标语言列一遍，逐个问一句无糖这个概念在这门语言里写出来是几个词。答案是一个词的语言全部需要单独处理，答案是两个词的可以先按英语经验走。 英语这个例外还有一个副作用：它让整个行业默认否定是一件不需要讨论的事。你去翻任何一份多语言SEO清单，里面会有变音符号、有词形变化、有书写系统，唯独没有否定这一条，因为它在英语里从来没成为过问题。 ## 否定粘进词里之后，会发生什么？ ## 一个词的意思被反转，长度只加了四个字母 从sokeri到sokeriton，字符串多了三个字母，语义整个翻了个面。 从Zucker到zuckerfrei，多了四个字母，同样是完全相反的意思。 这个比例在信息处理上很不友好：改动量极小，后果极大。 几乎所有基于相似度的算法，都会把这两个词判成高度相关。 而它们确实相关，只是相关的方式是对立，不是同义。 算法能识别的是距离，识别不了方向。编辑距离告诉你两个字符串差多少，它不会也不可能告诉你差出来的这几个字母是加了一个限定还是把整句话否定掉了。这是一个原理上的限制，不是实现得不够好。 这条性质还有一个反直觉的推论：两个词越像，被错误合并的概率越高，而否定形态天生就是最像的那一类。也就是说，语义上最需要被区分开的一对词，恰好落在算法最容易搞混的位置上。 ## 词表的行数不会变，语义面却翻了倍 做关键词表的时候，很容易把否定形态当成同一个词的变体收进去。 收进去之后表还是那么长，看不出有什么异常。 但这张表现在同时包含了两组意图完全相反的查询。 用它去分组、去算搜索量、去规划页面，得到的结论会混在一起。 最直接的后果是你以为某个词很值钱，其实值钱的是它的反面。 正确的做法是在词表里给否定加一列，把每一行标成肯定或者否定。这一列的填法可以半自动，先按后缀规则跑一遍，剩下拿不准的人工过一遍，一门语言通常一两个小时能标完。有了这一列，后面所有的分组和统计才是可信的。 这件事在英语项目上不需要做，因为否定词天然带着空格，分组的时候自然就分开了。到了德语芬兰语土耳其语这些语言，这一列不加，你的整张词表就是一份把正反混在一起的数据。相关的词表结构问题另见小语种关键词工具返回零时的补数据方法 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)。 还有一个实际的影响落在分组上。把否定形态和肯定形态放进同一个广告组，系统会按整体表现来分配预算，而两边的转化率往往差很远，结果是好的那一边被差的那一边拖着，报表上却看不出原因。 ## 分词器看不见这条边界 分词器的任务是找词与词之间的边界，它按空格、标点和词典来判断。 zuckerfrei在词典里就是一个条目，分词器没有理由把它切开。 就算切开了也未必是好事，切完之后否定的作用范围就丢了。 因为一个后缀被切下来之后，它跟哪个词干配对这条信息就不在了。 所以不切是对的，问题出在切与不切之外的那一层：语义标注。 跨语言的词边界判定有一套通用规则，可以参考Unicode标准附件29的词边界一节 (https://www.unicode.org/reports/tr29/#Word_Boundaries)，但要注意那份规则解决的是形式上的边界，它不负责告诉你这个边界两边的成分在语义上是什么关系。 真正能表达这层信息的是词法标注体系。Universal Dependencies的极性特征 (https://universaldependencies.org/u/feat/Polarity.html)就是专门为这件事准备的一个字段，它记录一个词形是肯定还是否定，跟词干和词性分开存放。这套字段存在本身就说明，语言学界很早就承认了这条信息没法从字符串里推出来。 ## 排除词和负关键词为什么会全部失效？ ## 广告的否定关键词是按词元匹配的 广告后台的否定关键词功能，工作方式是把查询切成词元再比对。 你添加一个否定词，系统会去查询里找有没有这个词元。 德语用户搜zuckerfrei的时候，查询里只有一个词元。 你想排除掉无糖那一类流量，就必须把整个zuckerfrei当成否定词加进去。 而这个词的形态有好几种，你得一个一个加，漏一个就漏一批。 更麻烦的是德语的复合能力，同一个概念可以出现在更长的复合词里，比如把品类词和这个属性直接拼成一个词。这类复合形态的数量在原理上是无限的，你不可能靠穷举把它们全部加进否定列表。 可行的应对是换一个层面处理：不在关键词层面排除，而在广告组层面拆分——专门开一组只投否定形态，出价和落地页都单独配。这样不需要排除，因为两类流量从一开始就走了两条不同的路。 顺便提醒一句，别指望靠给分词器加自定义词典解决。你可以把否定形态加进词典让它被识别成一个整体，但识别成整体之后系统仍然不知道它跟肯定形态是对立关系，缺的那条信息还是缺的。 ## 站内搜索的排除语法也是同一个道理 大部分站内搜索引擎支持在词前面加一个减号来排除。 这个语法的前提同样是否定作用于一个独立的词元。 用户想找不含某种成分的商品，在这类语言里没法用减号表达。 他只能整个打出那个否定形态的词，然后指望系统认识它。 而系统认不认识，取决于你有没有给它配过对应的同义词或者规则。 这里有个容易被忽略的细节：就算用户会用减号语法，他减掉的那个词元也可能不存在。他想减掉的是糖这个成分，可页面上写的是含糖那个后缀形态，两者的字符串对不上，减号减了个空。 解决办法是在搜索层配一张显式的映射表，把每一对正反形态绑起来，并且明确标注方向。这张表没法自动生成，但它的规模不大，一个品类通常十几对就覆盖完了。 还有一个常被忽略的细节是排除语法本身的可发现性。用户不知道减号能用，站内搜索的输入框也不会提示他，所以就算你把语法支持得很好，实际用到它的查询也只占极小一部分，靠这条路解决问题不现实。 ## 正则的否定前瞻救不了这一层 工程同学第一反应常常是写正则，用否定前瞻把某类形态排掉。 这个思路在单个词上能用，放到整张词表上就会开始出错。 因为否定后缀跟别的后缀在字符层面没有任何区别，正则分不出来。 芬兰语里以ton结尾的词并不都是否定，也有本来就长这样的词。 误伤一旦发生，你在结果里是看不出来的，只会觉得召回变少了。 正则的根本问题在于它工作在字符层，而这件事的信息在形态层。用字符层的工具去解决形态层的问题，能对付一部分特例，但没法收敛——每修一个误伤就要加一条例外，加到二十条之后没人敢动那个正则了。 更稳的路线是用现成的形态分析器。Hunspell拼写检查库 (https://github.com/hunspell/hunspell)的词典文件里带着完整的构词规则，能告诉你一个词形是由哪个词干加哪些词缀构成的，这个信息正是正则拿不到的那一层。 还有一种局面更难受：品牌方要求同时投正反两类商品。这时候两个广告组之间会互相抢量，因为查询里的词元有重叠，你需要在账户结构上再加一层否定或者用完全匹配把边界画死。 ## 保哥踩过的那次：无线那一组把有线的全带出来了 保哥有个做家纺和家居配件的客户，德语站上有一整组无线类商品。 投广告的时候把无线那个词加进了关键词，同时想排掉有线的流量。 排除列表里加的是有线那个词，看起来天经地义。 跑了两周发现搜索词报告里全是有线相关的查询，排除完全没生效。 原因是德语用户打的那个复合词里，有线那部分不是一个独立词元。 这件事最坑的地方在于报表看起来是正常的：曝光有、点击有、花费也在跑，只有转化率一直偏低。如果不去逐条看搜索词报告，你会以为是落地页的问题，然后去改落地页，改上一个月也不会有起色。 后来的处理办法很简单，把无线和有线拆成两个广告组，各自用各自的关键词，谁也不排除谁。当排除机制在某门语言上不可靠时，最省事的替代方案是不排除，改成正面圈定，这条经验后来在好几门语言上都用上了。 另外要留意的是搜索建议这一层。用户还没打完就被联想词带走了，而联想词多半来自一个更粗糙的前缀匹配逻辑，正反形态在那一层混得比正式搜索结果还厉害，很多误入是在这里发生的。 ## 词干还原为什么会把相反的两个词并到一起？ ## 词干还原器默认就是要剥掉后缀的 词干还原的目的是把同一个词的各种形态归到一个键上。 它的做法是识别并剥掉结尾的那些变化成分，只留下核心。 否定后缀在形式上跟别的后缀长得一样，所以也会被剥掉。 剥完之后，含糖和无糖两个词都变成了糖这一个词干。 从算法的角度这没有错，它做的正是它被设计来做的事。 要看具体的剥离规则可以直接查Snowball芬兰语词干提取算法说明 (https://snowballstem.org/algorithms/finnish/stemmer.html)，里面列出了这套算法会处理哪些结尾。把你关心的那几对正反形态照着规则手工跑一遍，十分钟就能确认它们会不会撞在一起。 德语那一侧同理，Snowball德语词干提取算法说明 (https://snowballstem.org/algorithms/german/stemmer.html)的规则更短，但它对复合词基本不做拆分，所以德语的问题表现形式跟芬兰语不一样：芬兰语是被剥错，德语是根本没被拆开。 另一个值得注意的点是索引侧和查询侧必须用同一套还原规则。两侧配置不一致的时候，问题会表现得毫无规律——有的词能搜到有的搜不到，排查起来比两侧都错还难，因为你找不到一条稳定的复现路径。 ## 芬兰语和土耳其语的情况更彻底 黏着语的后缀是一层一层挂上去的，还原器要剥好几层。 剥的层数越多，剥掉否定那一层的概率就越高。 土耳其语的否定后缀还会跟着元音和谐变出好几个形态。 这几个形态各自都要被识别，漏一个就会留下一批没归好的词。 结果是同一个概念的正反两族词，归并结果时对时错，不稳定。 土耳其语的规则可以参考Snowball土耳其语词干提取算法说明 (https://snowballstem.org/algorithms/turkish/stemmer.html)，这份算法的长度是德语版的两倍多，光是后缀处理就分了很多层，可以直观感受到黏着语的处理复杂度。土耳其语后缀堆叠的整体情况另见土耳其语后缀堆叠如何改变关键词形态 (https://zhangwenbao.com/turkish-seo-agglutinative-suffix-stacking-keyword.html)。 不稳定比稳定地错更麻烦。稳定地错你至少可以补一条规则修掉，时对时错意味着你没法用一条规则覆盖，只能逐词处理。 黏着语还有一个特有的麻烦：否定后缀不一定是最外层的那一个，它后面还可能挂着格尾和人称结尾。还原器从外往里剥，剥到否定这一层的时候前面已经做了好几个判断，任何一步偏差都会传导下来。 ## 为什么剥掉否定是一个合理的默认 词干还原被发明出来是为了提高召回，不是为了保证精确。 在信息检索的传统场景里，多召回一些不相干的结果代价很低。 用户扫一眼就能跳过，而漏掉相关结果的代价高得多。 所以整个技术路线的默认取向就是宁可多归并，不肯少归并。 这个取向在电商场景里正好相反，多召回一个反义商品是实打实的损失。 换句话说，问题不在算法有缺陷，而在于你把一个为图书馆检索优化的工具放进了一个要求精确匹配的商业场景。工具的默认取向永远来自它诞生时的那个场景，搬到新场景之前得先问一句它当初在优化什么。 把这条想清楚之后，选型的问题就变简单了：召回优先的场景继续用默认配置，精确优先的场景必须显式关掉否定后缀的剥离，或者干脆把这一族词放进保护词表。两种模式共存于同一个站是完全正常的。 ## 剥完之后的召回长什么样 最典型的表现是用户搜无糖，结果页第一屏里混着含糖的商品。 更隐蔽的表现是排序被打乱，相关商品被挤到了第二屏之后。 还有一种是筛选器的数量对不上，标着十二件点进去只有五件相关。 这三种表现在后台的报表里都不会触发任何告警。 因为从系统的角度看，查询有结果、结果有点击、一切正常。 要把这类问题捞出来，只能主动去测。方法是准备一组反义词对，每对都在站内搜索里跑一次，人工看前十条结果里有几条是反面的。二十对词跑完不到半小时，得到的却是一个能直接汇报的数字。 还有一种表现出现在推荐位上。相关商品模块通常按词干相似度取数，于是无糖商品页的下方会挂满含糖商品，这个位置的错配比搜索结果更伤，因为用户没有在主动筛选，他默认这是系统的推荐。 ## 字符串越像，语义越对立，这该怎么排查？ ## 编辑距离在这里是一个反指标 做词表清洗的时候常用编辑距离来找疑似重复项。 距离小的两个词被判成同一个词的不同拼法，然后合并。 否定形态跟它的肯定形态之间，编辑距离恰好非常小。 于是这套清洗逻辑会精准地把最不该合并的一对合并掉。 而且距离越小的越先被合并，也就是错得越彻底的先被处理。 这不是编辑距离用错了地方，是它在这一类词上的信号方向反了。凡是用相似度来推断同义的场合，都要先确认这门语言里有没有靠微小形态差别表达对立语义的机制，有的话相似度就必须降级成一个提示而不是一个判据。 实际操作上最简单的补救是加一条前置规则：合并之前先查这一对词里有没有一个带否定标记，有的话直接跳过不合并。这条规则的实现成本几乎为零，前提是你的词表里已经有了那一列极性标注。 顺便说一句，这条规律不只作用在否定上。任何靠一两个字母表达对立语义的机制都会踩同一个坑，比如某些语言里区分单复数、区分主动被动的那些结尾，它们的字符距离同样极小而语义差别同样明确。 ## 用一张正反对照表把陷阱穷举出来 这类问题的好处是范围有限，一个品类的属性词就那么多。 把品类里所有的属性词列出来，逐个写出它的否定形态。 写不出来的说明这个属性没有否定用法，直接跳过。 能写出来的就成对进表，一对占一行，正反两列。 一个品类通常十到二十对，一门语言半天能列完。 这张表的用处比想象中多：它同时是站内搜索的同义词配置来源、广告分组的依据、筛选器取值的命名规范，还是母语审校的核对清单。一份材料喂四个下游，这是它值得花半天时间的原因。 列表的时候有个小技巧，别只写词典形态，把每一对在真实文本里最常出现的两三种变形也带上。多写这几行不费事，但能省掉后面反复回来补的麻烦。 列表的时候顺手记一个信息很有用：这一对词在你的商品库里各自对应多少个SKU。数量为零的那一边说明你根本不卖，但它仍然要进排除逻辑；两边数量接近的说明这是一个真正的筛选维度，值得单独做落地页。 ## 检验办法是拿反义词对跑一遍还原器 有了对照表，检验就变成一个机械动作。 把每一对词分别喂给你在用的词干还原器，看输出是不是同一个。 输出相同的那些对，就是会在站内搜索里出问题的对。 把这批对单独拎出来，在搜索配置里给它们加硬规则。 整个过程不需要懂那门语言，也不需要母语者参与。 这个办法跟大小写转换那一类问题的自检思路是同一个：不去理解语言，只去观察工具在这门语言上的行为是不是符合预期。你不需要知道芬兰语的后缀体系有多复杂，你只需要知道这两个意思相反的词进去之后出来了同一个结果。 把这个检验做成一个可以重跑的脚本，每次换搜索引擎版本或者换分析器配置的时候跑一遍，能挡掉一整类升级引入的回归问题。 如果你用的是搜索引擎自带的分析器而不是独立的还原库，检验方式要换一下：直接调它的分析接口，把词丢进去看输出的词元序列。多数搜索引擎都提供这个调试入口，返回结果比你自己猜要可靠得多。 ## 站内搜索和筛选器会错到什么程度？ ## 筛选器的取值命名会跟着一起错 筛选器的取值通常直接取自后台的属性字典。 那张字典多半是从英文版翻过来的，一个属性对一个值。 翻译的时候译员会给出这门语言最自然的写法，也就是那个粘合形态。 于是筛选器的取值本身就成了一个不可切分的整体。 再往下游走，这个取值会进URL参数、进面包屑、进结构化数据。 一旦进了URL，改动的代价立刻上一个台阶，因为地址已经被收录、被分享、被外链。所以这件事值得在建站早期就处理掉，晚一年处理成本要高一个量级。 还有一个更早的介入点是属性字典的翻译环节。翻译的时候如果能同时给出一个规范化的取值键，让页面显示文本和内部取值分成两列，后面所有的下游问题都会轻很多，成本只是多一列。 ## 零结果和相反结果，哪个更糟 零结果至少是诚实的，用户知道这里没有他要的东西。 相反结果是不诚实的，用户以为找到了，点进去才发现不对。 从转化的角度看，第二种造成的流失更深，因为它消耗的是信任。 从排查的角度看，第二种也更难被发现，因为它不会出现在零结果报表里。 所以监控只盯零结果率的团队，会系统性地看不见这一类问题。 补一个指标不难：在站内搜索的日志里记录每次查询的前三条结果，定期抽样人工核对相关性。抽样量不需要大，每周三十条就能把明显的错配捞出来，而这三十条的人工成本大约是二十分钟。 这两种情况的处理优先级也不同。零结果可以慢慢补内容，相反结果必须立刻修配置，因为它每天都在消耗一部分本来会转化的流量，而且没有任何自愈的可能。 ## 日志里怎么把这类问题看出来 第一个信号是同一个用户在短时间内反复修改查询词。 他在试各种写法，说明系统没给他想要的东西。 第二个信号是搜索之后立刻返回，没有点击任何一个结果。 第三个信号是点击了但很快回到结果页，也就是不满意的往返。 这三个信号在否定类查询上的出现率，明显高于普通查询。 把查询按有没有否定标记分成两组，分别算这三个指标，两组之间的差距就是这个问题的量化结果。这个数字很好用，因为它把一个技术细节翻译成了一句业务方听得懂的话——这类查询的失败率是普通查询的几倍。 要注意别把这三个信号当成单独的告警指标用，它们在正常查询上也会出现。有意义的是分组对比出来的差值，不是绝对值本身，这一点在给业务方汇报的时候要说清楚，否则很容易被当成搜索质量整体不行。 ## 关键词表该怎么给否定词建结构？ ## 否定要单独占一个维度而不是一行标记 很多团队的做法是在词表里加一个是否否定的布尔列。 这个做法能解决分组问题，但解决不了配对问题。 更好的结构是让每一行都指向它的对立形态。 也就是加一列存放反义词，形成显式的成对关系。 有了这一列，后续所有的下游配置都能自动生成。 这个结构还有一个额外的价值：它让缺口显形。一个属性如果只出现了肯定形态而反义列是空的，要么是这个属性确实没有否定用法，要么是你漏了半边，两种情况都需要人看一眼确认。 这一列还有一个隐性价值是它能被复用到别的语言。属性之间的对立关系是概念层的，跟语言无关，所以第一门语言的对照关系建好之后，做第二门语言只需要填形态那两列，工作量能减掉一半以上。 ## 正反两个形态都要进表 常见的偷懒做法是只收自己商品对应的那一边。 卖无糖产品的只收无糖那一族，含糖那一族不管。 这个做法在英语项目上没什么问题，在这类语言上会漏掉排除逻辑的输入。 因为你要排除的正是另一边，而你手上没有另一边的形态清单。 所以两边都要收，哪怕其中一边你永远不会去投。 另一个理由是竞品分析。你的对手可能同时卖正反两类商品，他的页面结构和词覆盖会告诉你这个市场的实际分布，而你只有两边都收了才看得懂他的表。 还有一个理由是页面规划。看到两边的搜索量分布，你才知道该做一个页面还是两个页面。如果否定那一边的量足够大，它就应该有自己的落地页，而不是挤在一个通用分类页的筛选项里。 ## 词形变体该收到什么程度 屈折语和黏着语的形态数量很大，全收会让表爆掉。 实用的边界是只收在真实查询里出现过的形态。 拿不到查询数据的时候，退一步收最常用的三到五个格。 剩下的靠搜索引擎自己的词形理解能力去覆盖，一般够用。 过度收集变体的代价不是存储，是维护成本和统计噪音。 判断收得够不够有个简单的办法：拿一周的站内搜索日志，看有多少条查询在你的词表里找不到对应行。这个比例低于一成就够用了，高于三成说明变体收得太少。锚文本里的词形处理另见屈折语里的内链锚文本与词形变体 (https://zhangwenbao.com/minor-language-internal-link-anchor-inflection-variants.html)。 另一个实用的边界是别把只在正式文书里出现的形态收进来。词表的用途是接搜索，不是做语言学描述，一个形态如果一年到头没人在搜索框里打过，收进来只会稀释统计。 ## 优先级怎么排 第一优先是搜索量高且有明确否定语义的那一批词。 第二优先是虽然搜索量一般，但会造成反向召回的那一批。 第三优先是纯粹为了统计完整性收进来的形态。 前两类要进配置，第三类留在表里做参考就行。 这样分完，真正需要做技术配置的通常只有二三十个词。 把范围收到二三十个之后，这件事就从一个听起来很大的语言工程，变成了一张开发一天能配完的表。大多数看起来无从下手的语言层问题，收敛之后的实际工作量都不大，难的是收敛这一步。 还有一类词要单独拎出来看：那些同时是否定属性又是品类词的词。这类词的搜索意图往往已经是导航型的，用户心里想的就是那个品类，处理方式跟普通属性词不同，应该给它独立页面而不是筛选项。 ## 页面上的否定属性词该怎么写？ ## 标题里的否定词该放哪个位置 否定属性词在标题里最好靠前，因为它是筛选条件不是修饰。 用户扫标题的时候，先确认这个东西符不符合他的排除条件。 放在末尾容易被截断，而截断掉否定词的后果是意思整个反过来。 这一点比一般的关键词前置更要紧，因为代价不对称。 普通关键词被截断只是少一个词，否定词被截断是说反话。 移动端的截断位置比桌面更靠前，所以这条在移动端优先的语言上更关键。德语这类词长的语言尤其要小心，一个复合词本身就可能占掉标题一半的宽度。德语复合词的长度问题另见德语复合词、变音符号与关键词研究 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)。 另外要注意别把否定词写成缩写或者符号。有些团队为了省字符会用一个减号或者斜杠来表达不含，这在这类语言里读起来非常怪，也不会被任何检索机制理解成否定，纯粹是浪费了那几个字符。 ## 属性表里的写法必须全站统一 同一个属性在商品A页面写成一个词，在商品B页面写成一个短语。 这种不一致在人看来无所谓，在机器看来是两个不同的属性值。 后果是筛选器把同一批商品拆成两组，每组的数量都不对。 用户点进任何一组都看不全，而两组都存在会让筛选面板显得很乱。 统一的成本很低，前提是有那张正反对照表当作口径来源。 需要提醒的是统一不等于只留一种写法。页面上的可见文本可以按语境灵活写，必须统一的是属性值那个字段，这两层要分开管，混在一起会让文案变得很僵硬。 统一的执行难点通常不在规则而在存量。上千个商品的属性值已经写了好几种，批量改的时候要小心那些看起来像但其实是别的属性的取值，改之前先导出一份全量清单人工扫一遍，比直接跑替换脚本安全。 ## 别在同一段里把正反形态混着写 为了覆盖两个形态，有人会在一段话里把正反两个词都塞进去。 这个写法在中文里读着别扭，在这些语言里读着更别扭。 因为两个词长得几乎一样，连着出现会让读者以为是笔误。 而且这种写法会给机器一个混乱的信号，两个对立形态高频共现。 正确的做法是一页只主打一个方向，另一个方向放到别的页面。 如果确实需要在同一页说明两者的区别，把它放进对比表格或者问答区，用结构化的版面把对立关系表达出来，而不是靠句子里的并列。版面能表达的关系，不要用堆词去表达。 还有一个变体是在标题里同时塞两个形态，理由同样是想两边都覆盖。这个做法在这类语言上尤其糟糕，因为两个词几乎一样长又几乎一样拼，标题读起来像是排版出错了，点击率会掉得很明显。 ## 结构化数据的属性值怎么填 商品的属性字段应该填规范化的取值，而不是页面上的营销文案。 规范化取值的来源就是那张对照表里的标准形态。 如果这个属性有对应的行业标准或者法规定义，优先跟着标准写。 食品类的营养声称在欧盟有明确的法定条件，写法不能随便发挥。 跟着法定口径写，既避免了合规风险，也顺便统一了全站的用词。 具体的声称条件可以查欧盟营养与健康声称的官方说明 (https://food.ec.europa.eu/food-safety/labelling-and-nutrition/nutrition-and-health-claims_en)，那里规定了什么情况下才能标注无糖或者低糖这类字样。这类法定定义的存在其实帮了做内容的人一个大忙，它把一个原本各说各话的用词问题变成了一个有唯一答案的问题。结构化数据的语言字段另见小语种结构化数据的语言与地区字段怎么填 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)。 如果这个属性没有现成的法定或者行业口径，那就在内部定一个并写进文档，重点是全站唯一而不是绝对正确。属性值最怕的不是选错了一个词，是三个团队各自选了一个词都觉得自己是对的。 ## 一套两天能跑完的否定词审计流程 ## 六步审计流程 第一步，把品类里所有属性词列出来，标出哪些有否定用法。 第二步，给每个有否定用法的属性写出它在目标语言里的两种形态。 第三步，把每一对形态喂给词干还原器，记下输出相同的那些对。 第四步，在站内搜索里逐对试搜，人工核对前十条结果的方向。 第五步，把出问题的对写进搜索配置和广告分组，各自单独处理。 第六步，把这张表并进术语表和审校清单，让它有一个固定的存放位置。 六步里最花时间的是第二步，需要母语同事参与，其余五步都可以自己完成。整体两天能跑完一门语言，而这两天买到的是一整类问题的根治，性价比在语言层的工作里算高的。 如果时间实在紧，最少可以先做第三步和第四步。这两步不需要母语同事参与，一个人半天能跑完，产出是一份出问题的词对清单，已经足够支撑第一轮配置修改。 ## 一张能直接交给开发的规则表 这张表要有五列：肯定形态、否定形态、还原后是否冲突、处理方式、生效位置。 处理方式那一列只有几个固定取值，别写自由文本。 常见的取值是加同义词规则、加硬排除、拆广告组、不处理。 生效位置写清楚是站内搜索、广告后台还是商品属性字段。 有了这两列，开发拿到表就能直接排期，不需要再来问一遍。 另外建议加一列负责人，因为这张表的执行会横跨搜索、广告和内容三个团队，没有明确的归属，表会在中间环节停下来。表本身写得再清楚，也解决不了没人认领的问题。母语侧的验收另见小语种母语审校的验收清单怎么列 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)。 表里还可以加一列预计影响，简单标成高中低就行。这一列不是给开发看的，是给排期的人看的——没有它，这张表在需求池里会一直排在功能需求后面，因为语言层的问题听起来永远不如新功能紧急。 ## 哪些语言必须单独处理，哪些可以套模板？ ## 黏着语和屈折语的差别在哪 黏着语的否定后缀是一个独立的语素，位置固定、形态可预测。 芬兰语、土耳其语、匈牙利语都属于这一类，处理起来有规律可循。 屈折语的情况更杂，否定可能藏在前缀里，也可能改变整个词形。 俄语的否定前缀相对规整，但它跟别的前缀混在一起时不好区分。 所以黏着语可以靠规则批量处理，屈折语更依赖逐词核对。 判断一门语言属于哪一类，不需要查语言学资料，看一遍它的否定形态清单就知道：形态整齐、位置固定的是前者，形态各异、位置飘忽的是后者。匈牙利语的格尾体系另见匈牙利语十八个格与元音和谐的关键词处理 (https://zhangwenbao.com/hungarian-seo-eighteen-cases-vowel-harmony-keyword.html)。 还有一个粗略但好用的分类办法：看这门语言的否定形态能不能被一条正则大致覆盖。能被一条正则覆盖到八成以上的，按规则处理；覆盖不到一半的，老老实实逐词列表，别在这上面浪费工程时间。 ## 罗曼语系的情况介于两者之间 西班牙语、法语、意大利语的否定多数靠独立的介词短语表达。 这一点让它们接近英语，可以先按英语经验处理。 但它们也有一小批前缀式的否定形态，需要单独收进表里。 这批词的数量不大，通常十几个，人工列一遍就完了。 所以这几门语言的工作量小，但不能完全跳过。 值得注意的是，罗曼语系的形容词还要跟名词做性数一致，同一个否定形容词会有四种写法。这跟否定本身无关，但它会让你的词表行数翻倍。意大利语的性数一致问题另见意大利语形容词性数一致对选词的影响 (https://zhangwenbao.com/italian-seo-gender-agreement-elision-keyword-research.html)。 法语还有一个特有的坑是它的否定通常由两个成分组成，分别放在动词前后。这个结构在完整句子里没问题，但在关键词和属性值这类短片段里，常常只保留了其中一半，读起来意思就变得含糊。 ## 哪几门语言可以直接套英语经验 印尼语和马来语的否定基本靠独立的词，可以直接套。 越南语同样如此，它的词是按音节分写的，否定成分天然独立。 泰语的否定词也是独立成分，只是整句不分词带来的是另一类问题。 这几门语言可以把预算省下来，投到别的语言层问题上去。 判断标准还是那一句：把无糖这个概念写出来，看它是几个词。 需要提醒的是，可以套英语经验不等于不用检查。省掉的是配置工作，不是验证工作，至少要拿三五对反义词跑一遍站内搜索确认没问题，这一步十分钟就能做完，省掉它有时候会让你错过一个本来能提前发现的意外。东南亚三门语言的差异另见越南泰国印尼在语言层为什么一处都不能共用 (https://zhangwenbao.com/southeast-asia-seo-vietnam-thailand-indonesia-language-layer.html)。 还有一个值得单独提的类型是那些否定用前置独立词但会跟后面的词连写的语言。这一类看起来像英语，实际处理起来更接近德语，判断的时候别只看语法书上怎么说，要看真实文本里是怎么写的。 ## 常见问题解答 ## 只做德语一门语言，这件事值得花两天吗？ 看你的品类有没有强否定属性。食品、母婴、家纺、化妆品这几类几乎必然有，因为无糖、无麸质、无甲醛、免烫、防螨这些都是用户主动搜索的筛选条件，而且往往是高转化词。工业品和纯功能类目就弱得多，那些品类的属性词多是数值和规格，很少有否定用法。判断办法很直接：打开你的筛选面板看一眼，如果有一整栏是不含某某，那这两天值得花，否则可以推后。还有一个信号是看你的竞品有没有为否定属性单独做落地页，做了说明这个市场的需求已经被验证过。 ## 直接用搜索引擎自己的语言理解能力，不管这一层行不行？ 外部搜索引擎那一侧确实可以少管一些，主流引擎对常见语言的否定理解已经不差，你的页面写清楚它多半能理解。真正必须自己管的是站内搜索、广告后台和筛选器这三处，因为这三处用的是你自己配置的分析器和匹配规则，没有任何外部能力能替你兜底。换句话说，外部引擎的进步能帮你减轻一部分工作，但减轻不了你自己那一半，而自己那一半恰恰离转化更近。所以判断要不要投入，看的是你自己控制的那三处配置，而不是外部引擎的能力边界。 ## 怎么跟不懂这门语言的开发解释这个问题？ 别解释语言学，直接给他看两个字符串和一个还原结果。把含糖和无糖两个词并排放着，指出它们前六个字母一样，然后展示词干还原之后输出的是同一个键。整个演示不超过三十秒，开发立刻就懂了，因为这是他熟悉的语言：两个语义相反的输入，产生了同一个键。用这个方式沟通比讲后缀和词干省事得多，也不会让人觉得你在用专业术语压人。这个演示还有一个好处，它把问题从语言问题转成了数据问题，排期的时候更容易被接受。 ## 母语审校能不能发现这类问题？ 正文里的用词他们能发现，配置层的问题他们看不见。母语审校拿到的通常是文案稿件，看不到词干还原的输出，也接触不到广告后台的否定关键词列表。所以正确的分工是让审校负责确认那张正反对照表里的形态写得对不对，配置层的验证由你自己拿脚本跑。把审校的工作范围明确限定在语言判断上，他们的效率和准确率都会更高，也不会因为看不懂技术细节而给出模棱两可的意见。换句话说，让审校判断语言，让脚本判断行为，两边各做各最擅长的那部分。 ## 这套办法对AI搜索那一侧还成立吗？ 问题的形态变了，但没有消失。生成式系统对否定的处理本来就比对肯定弱，训练语料里的否定表达也更少，而小语种的语料总量又更少，两个因素叠在一起，误读的概率不低。可以做的事是在页面上把否定条件写得更显式，比如单独做一个属性区块或者一段明确的说明，而不是只把否定藏在一个复合词里。结构清晰的表达对任何一种检索方式都是有利的，这一条不因技术路线变化而失效。真正需要重新评估的是那些原本靠精确匹配兜底的环节，它们在生成式检索里没有对应物。 ## 如果站上根本没有站内搜索，还需要做吗？ 需要做的部分变少了，但不会归零。没有站内搜索意味着你少了一个出问题的地方，也少了一个最好用的诊断入口。广告那一侧的否定关键词问题照样存在，筛选器和属性字段的命名问题照样存在，关键词表里正反混淆的问题也照样存在。实际上没有站内搜索的站更需要那张正反对照表，因为你失去了从日志里发现问题的能力，只能靠事前把表列清楚。没有日志的站要靠事前列表补上这块缺口，投入反而要更早一点。 ## 这件事和大小写、变音符号那些坑是同一类吗？ 处理链路很像，性质不同。大小写和变音符号出问题的时候，结果是匹配不上，表现为召回变少，用户搜不到。否定出问题的时候，结果是匹配到了相反的东西，表现为召回变多但方向错了。前者是漏，后者是错，而错比漏更难被发现，因为漏会体现在零结果率上，错不会体现在任何一个现成的指标上。所以这两类问题虽然排查手法接近，但监控方式必须分开设计。监控指标也要分开设：漏看零结果率，错看结果相关性抽检，两个数字不能合并成一个。 ## 权威参考资料 ## 小语种关键词表里唯一一批全英文的词，从翻译到审校没有一个人动过它 - URL：https://zhangwenbao.com/minor-language-acronym-initialism-local-forms-inflection.html - 分类：小语种SEO - 发布：2021-04-13 | 更新：2026-07-28 - 摘要：同一个组织在五门语言里有五个缩略语，芬兰语还要用冒号把格尾接在后面。讲清缩略语要经过展开与重组两次转换、为什么分词器一定会把带冒号的形态切开，以及技术规格、机构名称、商业惯用三类缩写该走哪三条不同的处理路径。 - 关键词：关键词研究,出海SEO,多语言SEO,小语种SEO > **TLDR**：摘要：关键词表里总有那么几行是全英文的大写字母，它们从翻译派单到母语审校一路顺畅通过，因为每个环节都默认这种东西不用动。可是同一个组织在五门语言里有五个不同的缩略语，芬兰语还要用冒号把格尾接在后面，而所有分词器都把冒号当成词边界。本文把缩略语分成三类给出各自的处理策略，附一张能直接查的变体覆盖清单。 > 摘要：关键词表里总有那么几行是全英文的大写字母，它们从翻译派单到母语审校一路顺畅通过，因为每个环节都默认这种东西不用动。可是同一个组织在五门语言里有五个不同的缩略语，芬兰语还要用冒号把格尾接在后面，而所有分词器都把冒号当成词边界。本文把缩略语分成三类给出各自的处理策略，附一张能直接查的变体覆盖清单。 ## 为什么关键词表里那几行全英文的词从来没人改过？ ## 它们在流水线上长得像常量 打开任何一份小语种关键词表往下翻，总会看到几行是纯大写的拉丁字母。 USB、LED、PDF、EU、VAT，它们夹在一堆本地文字中间特别显眼。 显眼归显眼，这几行往往是整张表里唯一没被任何人碰过的几行。 原因很朴素，它们看起来像代码里的常量，不像需要翻译的内容。 翻译记忆库对这类片段的匹配度是百分之百，工具直接标成已完成。 做芬兰乐器配件那个项目的时候，我第一次注意到这件事。整张词表交回来，只有几行英文缩略语一个字符没变，而它们恰好是全站商品参数里出现频率最高的几个词。当时我们以为那是好消息，说明流水线足够聪明，认得出哪些东西不该动。 这几行还有一个共同点，它们通常是整张表里字符最短的几行，在表格里看着就像凑数用的。视觉上最不起眼的行，往往是被处理得最草率的行，因为审阅一张长表的时候注意力天然流向长句子和陌生词，一串三个字母的大写缩写既不长也不陌生，眼睛会直接滑过去，连停顿都不会有。 ## 匹配度百分之百的片段，就是没人看过的片段 这是我从这件事里带走的第一条判据，后来用在别的场合也一直成立。 翻译工具的完全匹配意味着这段内容被自动填充，不进人工队列。 不进人工队列意味着没有任何一双眼睛在上面停留过。 而缩略语正好是最容易触发完全匹配、也最需要人判断的那一类。 它同时占据了流程上最省事的位置和内容上最需要动脑的位置。 这条判据的用法是反过来的：拿到译稿之后不要先看被大改的部分，先把完全匹配率最高的那些行拉出来单独审一遍。改动多的部分至少证明有人在思考，而一个字没改的部分你连它有没有被看过都不知道。 这条判据还有个更一般的说法：自动化流程的成功率越高，它失败的那几次就越难被发现。翻译记忆库的匹配准确率如果只有六成，所有人都会逐条核对；准确率到了九成九，反倒没有人核对了，而剩下那百分之一恰好集中在缩略语这类特殊内容上，命中率高得不像巧合。 ## 缩略语跟截短词不是一回事 这两件事经常被混着说，实际上机制完全不同。 截短是把一个长词砍短，比如把大学砍成前两个音节。 缩略是把一个短语的每个词取首字母重新拼成一个新串。 截短之后的形态还是原来那门语言的词，读音也跟着原词走。 缩略之后的形态是一串字母，读法要另外规定。 之所以要分清楚，是因为两者在关键词层面的处理方向相反：截短词要做的是把用户常说的那个短形式补进词表 (https://zhangwenbao.com/minor-language-clipped-short-forms-keyword-coverage.html)，而缩略语要做的是判断这一串字母在目标语言里到底该不该保持原样。前者是补，后者是换，用同一套流程处理必错一半。 还有一个区分它们的简单信号是读法。截短之后的形态仍然按原来的音节读，是一个能说出口的词；缩略之后的形态要么逐字母念，要么按拼读规则当成一个新词念，两种读法在不同语言里的比例还不一样。读法决定了它会不会进入口语，进入口语的形态才会大量出现在搜索框里。 实际操作里最省事的分辨办法是看长度比。截短之后的形态通常是原词的一半左右，缩略之后的形态往往只剩三四个字符，压缩比差着好几倍。压缩比大的那一类几乎必然需要重新规定读法，也就必然要走本地重组那条路。 ## 同一个组织在五门语言里有五个缩略语，你的词表收了几个？ ## 缩略语要经过两次转换，两步都可能断 一个英文缩略语要进入目标语言，中间有两个动作。 第一步是把它展开成完整名称，第二步是把完整名称翻成目标语言。 第三步才是按目标语言的词序重新取首字母，拼出本地缩略语。 三步里任何一步没做，出来的都是原样的英文串。 而流水线默认执行的正是零步，因为它压根没意识到这里有工作。 这三步说起来简单，落到实际操作里最容易断的是第三步。译者往往会把全称翻对，然后在缩略这一步犹豫，因为他不确定当地是不是真的有一个通行的缩写。这个犹豫是对的，答案不在他脑子里，在本地媒体和本地行业文章里，得去查。 值得留意的是这三步里只有第二步是翻译工作，另外两步都是知识查证工作，而翻译工单的计价方式只覆盖第二步。凡是工单不计价的步骤，都会系统性地被跳过，这不是态度问题而是激励结构问题，想让它被执行就得把它单独列成一项可以计价的任务。 ## 词序一变，首字母跟着全变 联合国的英文缩写是三个字母，法语、西班牙语、俄语各有各的写法。 差别的根源是各语言的词序不同，取出来的首字母自然不同。 这不是翻译习惯问题，是构词规则决定的必然结果。 凡是修饰语位置跟英语不同的语言，这类缩略语几乎必然不一样。 罗曼语族和斯拉夫语族都属于这一类，德语和荷兰语也常见。 判断一个缩略语会不会本地重组，有个很快的办法：把全称翻成目标语言，看词序有没有变。词序没变的多半沿用英文缩写，词序变了的多半有本地版本。这个判断五分钟能做完一批，比逐个去查资料快得多，之后只需要对存疑的那几个做核实。 这条规律还有一个反向用法。如果你发现某个缩略语在目标语言里居然没有本地版本，那通常说明这个概念是随着英文材料一起进入当地的，本地媒体也直接用了英文缩写。DWDS收录的欧盟词条 (https://www.dwds.de/wb/EU)就是一个混合案例，德语有自己的缩写形式，同时英文缩写在专业语境里也通行。 ## 本地缩略语的搜索量往往比英文原版高 这一点跟直觉相反，很多人默认英文缩写是国际通用的。 通用的意思是懂的人多，不等于当地人搜索时会用它。 本地用户在自己的语言环境里长大，接触到的是本地媒体的写法。 他们在搜索框里打出来的自然是从新闻和课本里学到的那一串。 英文原版更多出现在跨国企业内部和专业文献里。 芬兰乐器配件那次实测下来，本地缩略语的月查询量是英文版本的好几倍，而我们的商品参数表上一个本地版本都没有。这一层的漏损是完全静默的，报表上看不出来任何异常，因为你从来没有为那些查询建过词，自然也就不会在任何报告里看见它们。 这个差距在不同行业之间还不一样，越是面向普通消费者的行业差距越大，越是面向专业买家的行业差距越小。原因也不复杂，专业买家读的是英文技术文档，普通消费者读的是本地新闻。所以判断该重点做哪个形态，先看你的客户平时读什么材料，比看任何行业报告都准。 这个结论还有一个前提值得说清楚，它只在有本地媒体生态的市场里成立。如果一门语言的本地内容极少，用户接触到的材料本身就是英文的，那么英文缩写反而是他们唯一熟悉的形态，硬造一个本地版本是没有人会搜的。 ## 词表要为缩略语单独留一个类型标记 把缩略语混在普通关键词里管理，早晚会出问题。 它们的变体规则跟普通词完全不同，需要单独的生成逻辑。 加一个类型列，值是缩略语、截短词、普通词三选一。 后续所有的批量操作都按这一列分流，不再一刀切。 这一列的成本是零，收益是让所有后续脚本都能正确分支。 通用依存标注体系里的Abbr特征 (https://universaldependencies.org/u/feat/Abbr.html)就是干这件事的，它把是不是缩略形式当成一个独立的词层特征标出来，而不是靠字符串长相去猜。借这个思路给词表加一列，等于把语言学上已经想清楚的分类直接搬过来用。 这一列还能顺手解决另一个长期麻烦，就是词表去重。缩略语和它的全称在字符串层面完全不像，任何相似度算法都不会把它们判成重复，于是同一个概念在表里存两行谁也发现不了。有了类型列就可以按原串做分组，把同一概念的所有形态归到一起看，重复和遗漏同时浮出来。 ## 哪三类缩略语要用完全不同的处理方式？ ## 第一类：全球统一的技术规格 接口名、文件格式、材质代号这一类，全世界写法一致。 用户在任何语言环境里搜索它们，打的都是同一串字母。 这一类确实不需要翻译，流水线跳过它是对的。 要注意的只有连字符和空格的写法差异，那是另一个话题。 这一类通常占缩略语总量的一半以上，所以流水线的默认行为大体不错。 问题在于流水线不区分类型，它对第二类和第三类也执行同样的跳过。默认行为在多数情况下正确，反而让例外情况更难被发现，因为没有人会去检查一个大部分时候都对的规则。 这一类里唯一需要花心思的是连字符和空格。同一个接口规格，有人写带连字符的，有人写不带的，有人在字母和数字之间留一个空格。三种写法在字符串匹配上是三个不同的串，而用户三种都会打，商品标题里只能选一种，剩下两种就得靠正文和参数说明去接。 ## 第二类：机构、组织与地理实体 国际组织、政府部门、国家名的缩写，几乎必然有本地版本。 这一类在内容里出现的位置通常是信任信号和合规说明。 写成英文缩写不会导致理解障碍，但会让页面读起来像译稿。 更实际的影响是，用户按本地缩写搜索时你完全不在场。 这一类的数量不多，一个行业十几个，人工列一遍就完。 这一类还有个特点是稳定，一旦确定下来几年不会变，维护成本几乎为零。所以尽管它需要人工判断，一次性投入之后就是一劳永逸的资产，跟工具返回的那个零是数据缺口而不是需求缺口 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)一样，都属于必须靠人补一次、补完就能长期吃的那类工作。 判断某个缩写属不属于这一类，有个很省事的信号：看它有没有出现在当地的政府网站或者新闻媒体上。这两类内容天然使用本地规范写法，如果它们用的是本地缩写而你的页面用的是英文缩写，那这个词就必须补一个本地形态，不必再做别的论证。 ## 第三类：商业与法务惯用缩写 税率、公司形式、单据类型这些，各国有各国的一套。 德语的增值税缩写、芬兰语的有限公司后缀，都是本地独有的。 这一类根本不存在英文对应版本，硬翻过去当地人看不懂。 它们在商品页上的出现频率极高，价格区、结算页、发票说明都有。 这一类是三类里最不能出错的，因为它直接关系到可信度。 DWDS收录的德语增值税缩写词条 (https://www.dwds.de/wb/MwSt.)能看出这类词在真实文本里的用法密度，乘用车那一条 (https://www.dwds.de/wb/Pkw)是另一个典型，它在德语里是一个完全本地的缩略语，跟英文毫无关系。这类词漏掉不会有任何报错，但当地用户一眼就能看出这个站不是本地人做的。 这一类还有一个容易被忽略的位置，就是页脚的公司信息和条款页。公司形式的后缀写错了不影响任何功能，却是当地用户判断一个站是不是本地经营的第一个信号，而这批文字通常由法务或者行政提供，从来不进内容团队的工作流，也就没人从检索角度看过它。 这一类词的另一个特点是它们经常带点号，而点号在很多系统里会触发意想不到的处理，比如被当成句子结束、被当成文件扩展名、或者在生成链接时被截断。上线之前拿几个带点的缩略语跑一遍全链路，能提前发现不少这类小故障。 ## 三类的处理策略要写进同一张表 把三类各自的处理规则写成三行，贴在词表的说明页上。 第一类保持原样，只做写法变体的覆盖。 第二类查本地媒体，确定本地版本后两个形态都进词表。 第三类完全按本地惯用来，英文版本根本不进表。 规则写清楚之后，新增缩略语的判断只需要三十秒。 这张表的真正价值是它把一个需要语言知识的判断，压缩成了一个任何人都能执行的分类动作。分类做完之后该查什么、该填几个形态都是确定的，不再依赖执行者对目标语言的熟悉程度。 这张表还要留一栏写清楚谁有权改动分类。缩略语的类型归属偶尔会变，比如某个技术规格在当地逐渐有了本地叫法，从第一类挪到了第二类。这种变化一年遇不上几次，但一旦发生，如果没有明确的责任人，改动往往会以某个人在某次会上口头说了一句的形式发生，然后没有任何记录。 ## 芬兰语的缩略语要用冒号接格尾，分词器会怎么切？ ## 格尾靠标点接在缩略语后面 芬兰语的名词要变格，缩略语进了句子同样要变。 可是缩略语是一串大写字母，直接把格尾粘上去读不出来。 解决办法是在中间加一个冒号，格尾写在冒号后面。 于是同一个缩略语在不同句法位置上会有好几种写法。 土耳其语用的是撇号，机制一样，符号不同。 芬兰语言办公室指南库里的缩略语条目 (https://www.kielitoimistonohjepankki.fi/haku/lyhenteet)把这套规则写得很细，包括什么时候该加冒号、什么时候直接接。这跟土耳其语一个词后面挂五层后缀 (https://zhangwenbao.com/turkish-seo-agglutinative-suffix-stacking-keyword.html)的处理是同一类问题，只不过缩略语这一层多了一个标点符号作为分隔。 这套规则在别的语言里也有对应版本，只是符号不同。芬兰国家语言中心的语言服务页面 (https://kotus.fi/ohjeet/)汇总了这类规范材料的入口。要注意的是这些是书面规范，而用户在搜索框里未必照着写，规范给你的是应该有哪些形态这个清单，真实份额还得回日志里看。 ## 标点在分词器眼里是词边界 这是整件事最要命的一环，也是最容易被忽略的一环。 几乎所有的分词器默认把非字母字符当作词与词之间的分隔。 于是带冒号的那个形态会被切成两段，前面是缩略语，后面是格尾。 切开之后，你的精确匹配永远命中不了用户打的那个完整串。 而用户打得出来，因为他们的输入法本来就这么打。 Unicode的文本分段标准附件 (https://unicode.org/reports/tr29/)定义了默认的词边界规则，冒号和撇号在这套规则里的处理值得逐条读一遍。这一层是唯一一类用户打得出来、机器切得开、你的词表却接不住的词，三个条件同时成立在别的词类上很难凑齐。 这一层还会引发一个更隐蔽的后果，就是数据被拆散。同一个缩略语的五个格尾形态，在报表里是五条各自独立的低频记录，每一条的量都不足以进入前一百名，于是这个词整体上就从你的视野里消失了。拆分不只让单条数据变小，它会让一个重要的词整个不出现。 ## 索引侧和查询侧要一起改才有用 只改索引不改查询，或者反过来，都等于没改。 站内搜索引擎允许自定义字符过滤规则，把冒号排除在分隔符之外。 改完之后要重建索引，否则旧数据仍然按老规则切着。 查询侧同样要跑一遍归一化，让用户输入和索引对齐。 两侧都改完，再拿几个真实查询做一次回归测试。 数据库全文检索的词典配置文档 (https://www.postgresql.org/docs/current/textsearch-dictionaries.html)说明了这类规则可以在哪一层调整，如果你的站内搜索直接跑在数据库上，改动点比想象中集中。开源检索引擎的语言分析文档 (https://solr.apache.org/guide/solr/latest/indexing-guide/language-analysis.html)则给出了按语言配置分析链的完整示例，芬兰语和土耳其语都在支持列表里。 做这类改动之前一定要先留一份基线数据，把改之前的零结果率和主要查询的命中情况存下来。检索配置的改动很容易顾此失彼，某一类查询好了另一类差了，没有基线的话事后完全说不清楚到底是变好了还是变坏了，只能凭感觉争论。 还有一件容易被忘掉的事是自动补全。补全的候选来自另一套索引，改了主索引不改补全，用户在输入框里打到一半看到的候选仍然是错的，而补全恰恰是影响用户最终打出什么字符串的那一环。 ## 缩略语和全称，哪一个该进标题？ ## 两者的搜索量和意图强度是分开的 缩略语好打，所以搜索量通常更高。 全称打起来费劲，愿意打的人往往目标更明确。 这就形成了一个典型的量与质分离的局面。 只做一个必然丢掉另一半，两个都做才是完整覆盖。 问题在于标题只有一个，容纳不下两个形态。 这个矛盾跟最高级词的形态多而落点少 (https://zhangwenbao.com/minor-language-comparative-superlative-keyword-forms.html)是同一个结构：意图集中的位置容量最小。解法也类似，把主形态放标题，次形态放正文和结构化数据，让两者在同一个页面上共现。 这个分离还有一个实际用处，它能帮你判断内容该写多深。搜缩略语的人可能只是随便看看，搜全称的人往往已经在比较具体方案了。同一个页面要同时接住这两批人，靠的是把浅层信息放前面、深层信息放后面，而不是为两批人各做一个页面。 ## 首次出现时全称加括号缩写 这是写作规范里的老做法，在这里正好一举两得。 正文第一次提到时写全称，后面用括号带上缩略语。 这样两个形态在同一段里共现，语义关联被明确建立。 后续段落只用缩略语，读起来不啰嗦。 规范本身是为可读性设计的，副产品是关键词覆盖。 微软风格指南里关于缩略语的一章 (https://learn.microsoft.com/en-us/style-guide/acronyms)把这套写法的适用边界讲得很清楚，包括哪些缩略语常见到根本不需要展开。这份指南是英文写作的，但它给出的判断标准可以直接搬到别的语言上用。 这个写法还有一个副作用值得利用：它天然在页面上制造了一次概念定义。搜索引擎在理解页面主题的时候，这种全称加括号的结构是一个很强的信号，比单独出现任何一个形态都清楚。所以即使某个缩略语已经家喻户晓，在正文里展开一次仍然不亏。 ## 结构化数据里放哪一个 结构化数据的字段值不需要考虑可读性，只需要考虑机器识别。 所以那里应该放最标准、最不容易产生歧义的那个形态。 多数情况下是全称，因为缩略语可能在别的领域里另有所指。 缩略语可以放进别名类的字段，让两者都被读到。 这一层跟正文的取舍逻辑完全不同，不要照抄。 这条跟小语种页面正文越本地化越好而结构化数据要反着写回国际格式 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)是同一条原则的另一次应用：面向人的位置和面向机器的位置，优化目标本来就不同，写成一样反而两边都不讨好。 还有一个实操细节是别名字段能放几个。多数结构化数据的别名类字段接受数组，可以把本地缩写、英文缩写和常见变体一并放进去。这是全站唯一一个可以不加节制地放多个形态而不影响可读性的位置，不用白不用，成本只是模板里多拼一个数组。 ## 有些语言几乎不用字母缩略语，规格表该怎么写？ ## 不是所有书写系统都适合首字母缩略 首字母缩略这个做法有个隐含前提，就是字母能单独读出来。 拉丁字母和西里尔字母都满足这个条件，字母名是现成的。 阿拉伯字母的情况不同，书写不标元音，一串辅音很难念。 于是阿拉伯语里的字母缩略语数量远少于欧洲语言。 用户不用它，自然也不会拿它来搜索。 这跟阿拉伯语那些从右往左带来的坑 (https://zhangwenbao.com/arabic-seo-rtl-layout-msa-dialect-keyword.html)属于同一个层面的问题：书写系统的性质会直接决定某一类语言现象存不存在，而不只是影响它长什么样。 这条限制还能推广开来看：一个语言现象存不存在，取决于它所依赖的那个底层条件成不成立。首字母缩略依赖字母可单独读出，词干还原依赖词有明确的边界，大小写变化依赖书写系统本身有大小写之分。做多语言方案之前把这些前提逐条列一遍，能省掉大量无效工作。 ## 规格表全是缩写等于零可搜索性 商品参数表是缩略语密度最高的地方，接口、材质、认证全是缩写。 在缩略语不流行的语言市场上，这张表几乎没有检索价值。 用户搜的是完整说法，而你的页面上一个完整说法都没有。 更麻烦的是这张表通常由系统自动生成，内容团队碰不到。 于是它成了一块所有人都看得见、却没有人负责的区域。 我们的处理办法是在参数表旁边加一段自然语言的规格说明，用完整说法把关键参数复述一遍。这段文字对已经懂行的用户是冗余的，但它是那些按完整说法搜索的用户唯一能命中的落点，成本只有一段话。 这块区域没人负责还有一个结构性原因，参数表在多数团队的认知里属于商品数据而不属于内容，商品数据的归属往往在运营或者供应链那边。凡是跨部门归属的页面区域，检索优化几乎必然缺位，因为没有任何一方把它算进自己的指标里。 这块区域的改造还有个成本优势，因为它是模板生成的，改一次全站生效。不像正文要逐页去改，参数表的说明段落只要在模板里加一次，几千个商品页同时获得这段内容，单位成本低到几乎可以忽略。 ## 希腊语和西班牙语的点号写法 希腊语的传统缩略写法要在每个字母后面加点。 西班牙语表示复数时会把字母重复一遍再加点。 这两种写法在字符串层面跟不加点的版本完全不同。 用户两种都会打，而词表里通常只有其中一种。 点号还会引发跟冒号一样的分词问题。 希腊语这一族的复杂度在用拉丁字母打希腊语那一层 (https://zhangwenbao.com/greek-seo-greeklish-latin-transliteration-coverage.html)之上又叠了一层，同一个缩略语可以有带点的希腊字母版、不带点的希腊字母版和拉丁转写版三种写法，三种在真实查询里都有份额。 这三种写法的份额可以直接测出来，办法是把三种分别投一小笔广告跑一周，看展现量的分布。测出来的结果经常反直觉，规范写法的份额往往不是最高的那个，因为规范是给编辑用的，而搜索框里的写法是由输入便利程度决定的，两者的驱动因素完全不同。 ## 大小写、点号和空格的变体，要不要都覆盖？ ## 变体清单一共只有五种，列一遍就完 全大写、首字母大写、全小写，这是大小写的三种。 加点和不加点，这是标点的两种。 字母之间加空格和不加空格，这是间隔的两种。 三个维度交叉，理论组合十来种，实际常用的只有五种上下。 一个缩略语列五个变体，人工做完全扛得住。 Duden关于缩略语的词条 (https://www.duden.de/rechtschreibung/Abkuerzung)能看到德语里带空格的规范写法，而真实查询里绝大多数人不打那个空格。规范写法和高频写法在这一层几乎总是不一致的，词表要收的是后者，正文要用的是前者。 列这张表的时候顺手记一个信息很有用，就是每种变体最可能出现在什么场景里。全大写常见于参数表和标题，首字母大写常见于正文句中，全小写常见于用户输入。知道变体的出没场景，比知道变体本身更有用，因为它直接告诉你该在哪个位置覆盖哪一个。 ## 不必都覆盖，但必须都知道 覆盖和知道是两件事，很多人把它们混在一起了。 知道的成本是列一张表，覆盖的成本是给每个变体找落点。 先把变体列全，再看哪几个有真实搜索量，只覆盖有量的。 没量的留在表里当档案，将来趋势变了随时可以启用。 这样既不浪费落点位置，也不会遗漏。 把这两件事分开还有个好处，讨论优先级的时候大家看的是同一张完整清单，只是在争论哪几行值得做，而不是各自凭印象举例。清单本身消除了大部分无效争论。 这个区分还能防住一类常见的返工。有人半年后发现某个变体有量，回头翻记录发现当初根本没考虑过它，于是重新做一遍全面调研。如果当初的清单是完整的，只是标注了暂不覆盖，这时候只需要把那一行的状态改一下，前面的调研成果一点没浪费。 ## 规范化要在存储层还是查询层做 这是个老问题，但在缩略语上答案比较明确。 存储层保留原样，绝对不要把用户的写法改掉。 归一化只在查询和索引这两个环节做，两边用同一套规则。 这样原始数据始终可回溯，规则改了重跑一遍就行。 把归一化写死在存储层，改规则就意味着数据回不去了。 这一条在图片文件名和替代文本要用两套字母写同一个词 (https://zhangwenbao.com/minor-language-image-alt-text-non-latin-script-search.html)那种场景里同样成立：凡是会改变字符串本身的转换，都不能发生在唯一的那一份数据上，必须发生在派生环节。 这条原则在缩略语上格外重要，因为大小写转换看着无害。把用户输入统一转成大写存进数据库，是这一层最常见的一次不可逆操作，转完之后你永远不知道当初用户打的是哪种写法，而那个分布正是决定标题该用哪个形态的唯一依据。 判断某个转换可不可逆有个十秒钟的测试：把转换后的结果再转回去，逐字节跟原串比较。回得去的可以放心用在存储层，回不去的一律只能用在派生环节。这个测试不需要懂目标语言，写十行代码就能跑完整张表。 ## abbr元素和括号并列，哪种写法真的有用？ ## 标记层能表达的和搜索能利用的不是一回事 HTML里有专门的缩略语元素，可以把全称写在属性里。 这个元素的设计目的是可访问性，让辅助技术读出完整名称。 属性值里的文本会不会被搜索索引，这件事从来没有明确答案。 所以不能把全称的覆盖寄托在这个属性上。 正文里明明白白写一遍，才是确定有效的做法。 这个元素的文档 (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/abbr)和规范里的文本级语义一章 (https://html.spec.whatwg.org/multipage/text-level-semantics.html)都强调了它的语义用途，两份材料里都没有任何关于检索权重的承诺。凡是规范不承诺的行为，工程上就不能当作依赖项。 这里还有一个更一般的判断方法：看规范文档里用的是描述性的词还是承诺性的词。规范中关于文本级语义的表述 (https://html.spec.whatwg.org/multipage/text-level-semantics.html)说的是这个元素表示什么，而不是处理器必须如何对待它。表示什么是语义约定，必须如何是行为承诺，只有后者才能当依赖项。 ## 可访问性收益是真的，别因此不用 说它对检索没把握，不等于说它没用。 屏幕阅读器确实会利用这个属性给出更完整的朗读。 在缩略语密集的规格表上，这个差别对使用者是实打实的。 成本几乎为零，加上就是了。 只是别把它算进关键词覆盖的账里。 这类工作的正确记账方式是把它记在可访问性那一栏，而不是往搜索那一栏里凑数。记错栏的后果是将来复盘的时候，你会以为搜索侧的某个提升来自这一步，从而在别的项目上重复一个其实没有作用的动作。 把可访问性和检索这两笔账分开记，还有一个组织上的好处。这两件事在多数公司归不同的人管，混在一起汇报会导致谁都不认领。分开记之后，可访问性那一栏的进展可以独立展示，不必依附在搜索的成绩上，长期看反而更容易拿到资源。 ## 括号并列的位置有讲究 全称在前缩写在后，还是反过来，取决于哪个更常用。 用户更熟悉缩写的时候，把缩写放前面读起来更顺。 但从关键词角度，放前面的那个更容易进摘要片段。 两个考虑打架的时候，优先照顾正文的可读性。 因为摘要片段的截取位置本来就不完全可控。 实操上我们定了一条简单规则：标题和第一段用主形态，第二段用括号把另一个形态带出来，之后全篇统一用主形态。这样既保证了两个形态在页面上共现，又不会让全文读起来像在反复自我解释。 还有一个位置容易被忘掉，就是图片的替代文本。参数表如果做成了图片，里面的缩略语在检索层面完全不存在，替代文本就是唯一的补救位置。这时候写全称还是写缩写要按图片的用途定，说明性的图片写全称，装饰性的图片干脆留空更好。 ## 词表里怎么给缩略语单独立一层 ## 四个字段就够：原串、类型、本地形态、变体组 原串是英文或原始语言里的那一串，作为跨语言对齐的锚。 类型是三类里的哪一类，决定后续走哪条处理分支。 本地形态是目标语言里的通行写法，可能跟原串相同。 变体组是一个数组，装着大小写和标点的各种写法。 四个字段能覆盖这一层几乎所有的操作需求。 字段设计上唯一要留心的是变体组不要拆成多列，因为变体数量是不定的。拆成固定的五列，遇到有七个变体的词就装不下，而多数词只有两三个变体，剩下的列全是空的，看着乱还容易被人误填。 这四个字段还要配一个隐含约定：原串那一列永远不许翻译，它的作用只是当锚。有人会好心地把它也翻成本地语言，理由是保持表格语言统一，翻完之后跨语言对齐立刻断掉，而这个断裂在单语言视角下完全看不出来，要等到做多语言对照的时候才会暴露。 这四个字段还有一个扩展位可以考虑加上，就是废弃标记。缩略语偶尔会被官方改掉，旧形态还有人在搜但已经不该出现在新内容里，用一个布尔字段标记比直接删掉安全得多，删掉之后没人记得当初为什么删。 ## 本地形态的确定要有出处 不要凭译者的印象填这一列，要求写出依据。 依据可以是本地媒体的用法、官方文书、或者行业协会的材料。 把出处链接直接填在旁边一列，将来复核不用重新查。 没有找到出处的，宁可先留空也不要猜一个填进去。 留空至少是个明确的待办，猜错了则会一直错下去。 这条要求刚提出来的时候会遇到阻力，因为它明显增加了工作量。缓解办法是只对第二类和第三类要求出处，第一类不需要，这样实际需要查证的行数只占全表的一小部分，抵触感会小很多。 出处这一列还有一个附带收益，它能让你看出某个缩略语的通行程度。如果三条出处来自三家不同类型的机构，说明这个形态是真正通行的；如果三条都指向同一个来源，那可能只是某一家的用法。来源的独立性比来源的数量更能说明问题，这一点在任何需要举证的场合都成立。 ## 跟品牌自造缩写划清界限 公司内部常有一套自己的缩写，写文档时用得很顺手。 这些缩写在公司外面的搜索量是零，一次都没有。 它们进标题就是纯粹的字符浪费，还会让页面显得费解。 判断办法很简单，拿去搜索框查一次，没有结果就是自造的。 自造缩写只能出现在内部文档里，一律不进对外内容。 这跟品牌名在当地叫什么不由你定 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)是同一条道理的延伸：命名权在市场那一边，公司能决定的只是自己的说法，决定不了别人的搜法。 自造缩写还有一个变体形式更难识别，就是行业内部通行但消费者完全不用的那些词。它们在搜索框里有量，只是搜的人全是同行和供应商，转化率接近零。这类词最好在词表里单独标一个内部词的标记，可以做内容但不该占用商品页的核心位置。 ## 交付给外包时要附什么 外包最容易在这一层上出错，因为他们更依赖工具的默认行为。 交付包里要带三样：三类的定义、已确定的本地形态表、出处要求。 还要明确说明哪些行不许改，避免好心办坏事。 验收时抽查的重点放在第二类和第三类上。 第一类基本不会出错，不必浪费抽查名额。 这套交付物准备一次就能反复用，换一门语言只要替换本地形态表那一份。母语者说读着自然不能当验收判据 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)这一条在这里格外适用，因为缩略语在句子里读起来永远都是自然的，无论它是不是当地人真正会用的那一个。 交付包里还要写清楚哪些位置允许出现英文缩写。参数表可以，正文第一段不行；筛选项的标签可以，页面标题不行。位置级别的规则比词级别的规则好执行得多，因为执行者不需要判断这个词属于哪一类，只需要看它出现在哪儿。 ## 上线后怎么验证这一层做对了 ## 第一个动作：拿本地缩略语搜一遍自己的站 用站点限定的搜索语法，把本地缩略语逐个查一遍。 返回零结果的，说明这个形态在站上一次都没出现过。 这个检查十分钟能做完一批，不需要任何工具。 它给出的是最直接的在场证明，比任何排名数据都清楚。 零结果和排名靠后是两件事，前者连候选池都没进。 这个动作最好在上线当天做一次，一个月后再做一次。当天做是为了确认内容确实上去了，一个月后做是为了确认索引确实收了，两次之间出问题的比例比想象中高。 这个动作还有一个变体值得一起做，就是用本地缩略语加品类词的组合去搜，看返回的是不是你想让它返回的那个页面。有时候站上确实有这个词，但它出现在一个不相干的页面上，用户搜到之后立刻跳出，这种情况比完全不在场更难从数据上看出来。 做完这个动作要把结果记在一张固定的表里，每次检查覆盖上一次的数字，保留时间序列。单次的检查结果只能告诉你现在的状态，连续几次的结果才能告诉你事情在变好还是变坏，而后者才是决定要不要继续投入的依据。 ## 第二个动作：看站内搜索的零结果查询 站内搜索的零结果列表是这一层最好的诊断材料。 带冒号或撇号的查询如果大量返回零结果，说明分词没改对。 本地缩略语大量出现在零结果里，说明词表漏了这个形态。 这份列表每周看一次，五分钟能扫完。 它同时暴露词表问题和检索配置问题，性价比极高。 看这份列表的时候要留意查询的书写形态而不只是它的意思，同一个意思用不同形态打进来是两条不同的记录。按意思归并之后你会觉得问题不大，按形态分开看才能发现某一个特定写法的失败率高得离谱。 这份列表还有一个用法是反向验证词表。把零结果查询里出现频率最高的二十条拿出来，逐条对照词表看有没有对应行，对不上的就是词表的空白。用户已经替你把需求写出来了，你只需要把它抄进表里，这比任何关键词工具给出的建议都更接近真实需求。 ## 第三个动作：对照本地同行的写法 挑三家本地头部同行，看它们的商品页怎么写这些缩略语。 重点看参数表和价格区，那是缩略语最集中的地方。 它们用的形态就是当地的通行形态，比任何词典都准。 这个对照每半年做一次就够，形态变化很慢。 如果三家写法不一致，说明这个词还没有形成共识。 没有形成共识的词处理起来反而简单，两种形态都覆盖就行，反正总量不大。真正要小心的是三家高度一致而你不一样的那几个词，那说明你用的形态在当地是明确的少数派，而不是一个可以并存的选项。在多语言市场里按书写系统分簇 (https://zhangwenbao.com/india-multilingual-seo-eleven-languages-nine-scripts-priority.html)的那套做法在这里同样管用，同一簇里的语言往往共用同一批缩略语习惯。 做这个对照的时候顺便看一眼同行的页面标题结构，注意他们把缩略语放在标题的什么位置。位置反映的是他们对这个词权重的判断，而他们的判断是长期试出来的。这不是让你照抄，而是当你的判断跟三家都不一样的时候，值得回头再确认一次自己的依据。 同行对照还有一个容易被忽略的对象，就是本地的比价站和垂直目录。这类站点的商品命名往往是各家数据汇总后的产物，某种程度上代表了当地市场的最大公约数写法，比单看一家同行更有参考价值。 ## 常见问题解答 ## 缩略语这一层的工作量大概有多大？ 按行业算，一个垂直行业需要单独处理的缩略语通常在三十到六十个之间，其中第一类占一半以上不需要动，真正要查证的是二三十个。一个人两天能把清单列完并找到出处，之后进入维护状态，每季度新增不超过三五个。相比它带来的覆盖提升，这是整个小语种项目里投入产出比最高的几件事之一，前提是你得先意识到这里存在工作。需要提醒的是这份清单要按行业而不是按语言来列，同一门语言在不同行业里的缩略语几乎没有重合，把上一个项目的清单直接搬过来通常只能复用其中很小的一部分。 ## 为什么翻译公司不会主动提这件事？ 因为在翻译的行业规范里，保留原文中的专有缩写本来就是一个合规的处理方式，甚至在很多场合是被推荐的做法。译者按规范交付，工具标记为完全匹配，审校读一遍觉得通顺，三个环节各自都没有失职。问题出在这套规范服务的目标是译文的准确与一致，而不是搜索覆盖，两者在这一层恰好指向相反的方向。所以正确的做法不是要求翻译公司改流程，而是把这一层作为独立的一项工作从翻译工单里拆出来，交给懂目标市场的人做，或者干脆自己做，因为它需要的是市场知识而不是语言能力。 ## 带冒号的形态到底要不要收进关键词表？ 要收，但不必给每一个格尾都建一行。收的方式是把基础形态和最高频的两三个格尾形态放进表里，其余的靠站内搜索和检索配置去兜。判断哪几个高频，看站内搜索日志里的实际分布，通常主格和一两个常用格就占了绝大部分。全部穷举既做不到也没必要，剩下的长尾形态贡献的量非常有限。另外要注意带格尾的形态在标题里通常不合适，因为标题多数是名词短语，用的是基础形态。这些形态真正的落点在正文的自然句子里，那里本来就需要它们，写对了顺手就覆盖掉了。 ## 如果目标市场同时通行英文缩写和本地缩写呢？ 这种情况很常见，处理办法是两个都收，然后按位置分工。搜索量高的那个进标题和一级导航，另一个放正文第一段和结构化数据的别名字段。关键是让两者在同一个页面上共现，建立起明确的等价关系，而不是分散到两个页面上互相竞争。判断谁的量高不要凭感觉，用广告后台跑一小笔预算测一周就有结果。还有一种情况是两个形态在不同人群里通行，比如专业买家用英文缩写、普通消费者用本地缩写，这时候按人群分页面比按形态分位置更合理，因为两批人要看的内容深度本来就不一样。 ## 规格参数表由系统自动生成，改不动怎么办？ 不必去改那张表，在它旁边加一段自然语言的说明就行。这段说明可以由模板从同样的字段生成，只是把缩写替换成完整说法并串成句子。工程量比改参数表小得多，也不会影响任何下游系统。对已经懂行的用户来说这段话是冗余的，但它是那批按完整说法搜索的用户唯一能命中的位置，这个交换很划算。如果连这段说明都不好加，退一步的做法是在页面的常见问题区里放一两条问答，用完整说法把最关键的那两三个参数讲一遍，成本更低，而且问答区本来就是接长尾查询的位置。 ## 怎么判断一个缩略语在当地有没有本地版本？ 最快的办法是把全称翻成目标语言，看词序有没有变化。词序变了的多半有本地缩写，没变的多半沿用原版。这个初判五分钟能做一批，之后只对存疑的几个做核实，核实的材料首选本地新闻媒体和政府文书，其次是本地同行的页面。不要用机器翻译反查，它在这一层的输出几乎全是英文原版。还有一个信号可以辅助判断，就是看这个概念是什么时候进入当地市场的。进入得早的概念通常已经沉淀出本地缩写，最近几年才进来的新概念多半还在直接沿用英文缩写，本地版本尚未形成。 ## 这套做法在中文站上有对应的场景吗？ 有，机制是一样的，只是表现形式不同。中文里的对应现象是英文缩写和中文全称并存，用户两种都会搜，而内容里往往只出现其中一种。判断方法也一样：把两个形态都列出来，看真实查询里的分布，然后按位置分工让它们在同一页共现。差别在于中文不存在格尾接标点的问题，所以分词那一层的麻烦要少很多。另外中文站上还有一类特殊情况是同一个英文缩写对应两个不同的中文译名，两个译名各有各的用户群。这时候不是选一个的问题，而是必须在页面上把两个译名都提一次，让搜任何一个的人都能落到这里。 ## 权威参考资料 ## 日语页面写得越客气，跟用户在搜索框里打的那串字差得越远 - URL：https://zhangwenbao.com/japanese-seo-keigo-politeness-levels-conversion-ranking.html - 分类：小语种SEO - 发布：2021-03-19 | 更新：2026-07-27 - 摘要：日语敬语不是一条礼貌滑杆，而是三套并行系统。讲清方向错为什么比档位错严重、用户打的常体裸词与页面上的敬体长句差在哪，以及六个页面位置各该用哪一档。 - 关键词：出海SEO,多语言SEO,小语种SEO,日语SEO > **TLDR**：摘要：日语的敬语不是一把从随便到客气的刻度尺，而是三套并行的系统：丁寧語管的是跟读者的距离，尊敬語和謙譲語管的是动作朝谁走。方向选错比档位选高选低严重得多，把尊敬語用到自家身上，母语者一眼就看出这站不是日本人做的。更麻烦的是检索那一侧：用户在搜索框里打的几乎全是常体裸词，页面上写的全是敬体长句，同一个意思在字面上根本不是同一串字。 > 摘要：日语的敬语不是一把从随便到客气的刻度尺，而是三套并行的系统：丁寧語管的是跟读者的距离，尊敬語和謙譲語管的是动作朝谁走。方向选错比档位选高选低严重得多，把尊敬語用到自家身上，母语者一眼就看出这站不是日本人做的。更麻烦的是检索那一侧：用户在搜索框里打的几乎全是常体裸词，页面上写的全是敬体长句，同一个意思在字面上根本不是同一串字。 ## 敬语不是一把刻度尺，它是三套同时在跑的系统 ## 丁寧語管的是你跟读者之间的距离 中文母语的运营第一次接触敬语，脑子里装的多半是一条从随便到客气的滑杆。 这条滑杆确实存在，它就是丁寧語。 買う是常体，買います是敬体，同一个动作，同一个方向，只是说话人跟听话人之间的距离拉开了一截。 丁寧語的特点是它只关心听的人是谁，不关心动作是谁做的。 所以它可以整段整页地统一，一个商品详情页从头到尾用ます形，读起来是干净的。 绝大多数出海团队对敬语的理解到这里就停了，然后把整站的敬体档位往上一推，以为这就叫做了本地化。 问题是丁寧語只占三分之一。它是三套系统里唯一一套可以整页统一处理的，也是唯一一套改错了不会让页面显得可笑的。真正会出事的另外两套，判断依据完全不在距离这个维度上，而是在动作的方向上，而方向这件事没法整页统一，只能一句一句看。日语选词那篇 (https://zhangwenbao.com/japanese-seo-hiragana-katakana-kanji-keyword-notation.html)讲的是同一个词有几种写法，这篇讲的是同一个动作有几种说法，两件事经常被混成一件。 ## 尊敬語和謙譲語管的是这个动作朝谁走 尊敬語抬的是动作的执行者，謙譲語压的是动作的执行者。 关键在于，被抬和被压的那个人，不是随便挑的。 用户做的动作用尊敬語，站方做的动作用謙譲語，这条方向是死的。 ご購入いただく是用户在买，承ります是站方在接单，两句话的礼貌程度差不多，方向正好相反。 换句话说，同一个礼貌档位，可以有两个方向，选错方向不是不够客气的问题，是把两边的位置搞反了。 日本人从小在这套系统里长大，方向感几乎是本能，不需要想。 非母语团队没有这个本能，于是最常见的翻车方式是：翻译工具给出一个看起来很客气的句子，运营看着挺好就用了，结果那句话把自家公司抬到了用户头上。这类错误的代价不是不礼貌，而是不像本地人写的，母语者读到会本能地停顿一下，然后开始怀疑这家店到底在哪里。信任就是在这半秒钟里掉下去的。 ## 美化語是另一件事，别把它塞进档位表 お茶、ご飯、お店，这些词前面挂着的お和ご，很多人也当成敬语来处理。 它们属于美化語，作用是让词本身显得体面，跟抬谁压谁没关系。 美化語不带方向，所以它不参与前面那套方向判断。 它真正的影响落在别处：加不加这个前缀，词的字面就变了。 お問い合わせ和問い合わせ在页面上是两个不同的字符串，用户搜的往往是后者。 把美化語混进档位表的后果，是团队会拿判断礼貌的标准去处理一件本质上是关键词写法的事。 保哥见过一个日本站的导航栏，六个一级入口里有五个带着お或者ご，看着确实庄重，问题是这五个词在关键词工具里的检索形态全是不带前缀的裸词。导航的锚文本因此一个都对不上，而导航恰恰是站内锚文本密度最高的地方。这件事跟礼貌一点关系都没有，纯粹是字面覆盖被前缀吃掉了。 ## 三套系统可以叠加，所以出错的组合比想象中多 一句日语可以同时带上丁寧語的ます、尊敬語的お～になる、以及美化語的お。 三套系统各自独立取值，组合数量就上去了。 这解释了一个现象：为什么日语的礼貌表达看起来有那么多层。 它不是一个维度上分了很多档，而是三个维度各分了两三档，乘起来的结果。 理解成乘法而不是加法，很多困惑会自动消失。 比如为什么有些句子听着又客气又别扭，往往是某一个维度取到了顶，另一个维度还停在底。 对做站的人来说，乘法这个理解有个实际好处：它告诉你不需要背表。你只要在每一句话上问清楚三个问题——听的人是谁、做动作的是谁、这个词要不要体面化——三个答案确定了，句子的形态就唯一确定了。这比记住几十个动词的敬语变形靠谱得多，也是非母语团队唯一能自己扛住的部分。 ## 为什么说方向错了比档位错了严重得多？ ## 把尊敬語用在自家身上是一类硬错 弊社がお届けになります，这句话语法上没毛病，用起来是错的。 お届けになる是尊敬語，抬的是送货的那一方，而送货的是自己。 自己抬自己，在日语的语感里不是傲慢，是荒唐。 它的效果接近于一个人用第三人称尊称介绍自己。 档位错误不一样，档位低了只是显得随意，高了只是显得生分。 方向错误是逻辑错误，它不在礼貌这条轴上，而在关系这条轴上。 这类错误在机器翻译输出里出现的频率相当高，因为翻译模型判断不了这个动作的执行者是站方还是用户——中文原文里根本没有这个信息，配送时间为三到五天这句话里，没有任何成分标出谁在配送。模型只能靠上下文猜，一猜就有一半概率猜反。机器翻译直接发布的风险线 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)那篇讲过一条判据，敬语方向就是最典型的那种机器判断不了、母语者一眼就看出的错。 ## 把謙譲語用在用户身上同样是硬错 反过来的错法出现得少一些，但杀伤力一样。 お客様が拝見する，这句是把用户的动作压低了。 拝見是謙譲語，只能用在自己看的时候。 用在用户身上，等于当着客人的面把客人矮化了一截。 这种错误在按钮文案和表单提示里最容易出现，因为那些位置的主语通常被省略掉了。 主语一省，翻译的人就失去了唯一的方向线索。 保哥后来给日语站定过一条硬规矩：凡是要送去翻译或者送去校对的短文案，一律在中文原稿的括号里补一句主语是谁。这条规矩不花钱，也不需要谁懂日语，却把方向类错误的返工量压掉了一大半。原因很简单——不是译者不会，是原稿从来没告诉过他这个动作是谁做的。 补一句判断技巧：謙譲語里有一批词是专用的，拝見、伺う、申す，看到这几个词就该立刻检查主语是不是站方。这批专用词数量有限，承る的词条 (https://ja.wiktionary.org/wiki/%E6%89%BF%E3%82%8B)那样的变形表里就能查到，做成一张二十几行的检查表就够用，不需要掌握整套变形规则。 ## 两个不需要日语能力也能用的方向判据 第一问：这个动作是谁做的。 用户做的，走尊敬語；站方做的，走謙譲語。 第二问：这句话里被省略的主语有没有可能被误认成另一方。 有可能，就把主语补回去，哪怕啰嗦一点。 这两问都不需要判断日语句子的对错，只需要判断中文原意里的角色，中文母语者完全做得到。 把这两问写进翻译交付单，验收时逐条对照，方向类错误基本就拦住了。 这套判据的价值在于它把一个语言能力问题换成了一个流程问题。团队里没人懂日语，照样能定义清楚什么算错、错在哪一步、该由谁在哪个环节补上信息。母语审校的验收清单 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)那篇提过同一个思路：验收项要写成不依赖语言能力的形式，否则整条质量线只能挂在一个母语者的判断上，人一走就断。 ## 方向错误在页面上的分布是有规律的 把一个日语站的方向错误标出来，分布几乎总是同一个形状。 商品描述正文里最少，因为句子长，主语通常写出来了。 按钮、表单标签、弹窗提示里最多，因为这些地方字数被压到极限，主语第一个被砍掉。 客服自动回复邮件里次多，因为那些模板往往是一次性写完就再没人看过。 知道这个分布，检查就有了先后顺序：先扫短文案，再扫邮件模板，最后才轮到正文。 反过来的顺序是最浪费人力的，正文占了全站九成的字数，却贡献不到两成的方向错误。 保哥给一个卖电子琴和吉他配件的日本站做过一次全站扫描，一共找出四十多处方向错误，其中三十一处在按钮和表单提示上，正文只有五处，剩下的全在下单确认邮件里。那封确认邮件是全站阅读率最高的一段文字，却也是最久没人碰过的一段——它在两年前上线时被翻译过一次，此后再没有任何人读过它。 ## 用户在搜索框里打的到底是哪一档？ ## 查询侧几乎全是常体和裸词 翻一遍日语站的搜索词报告，会看到一件很稳定的事。 用户打进搜索框的几乎没有敬体。 返品 いつまで、サイズ 交換 方法、送料 いくら，全是短、平、不带任何礼貌成分的形态。 这不难理解，用户是在对着一个框打字，不是在跟人说话。 搜索框不会因为你客气就多给你几条结果，用户很清楚这一点。 更进一步，用户还会主动砍掉助词，只留下几个实词，因为经验告诉他们这样搜得更准。 这个现象在任何语言里都存在，但在日语里后果格外大：别的语言从礼貌形态退回裸词，词干基本不变，德语的Sie和du换来换去，动词词干还在那儿；日语从お買い求めになる退回買う，中间掉的不只是礼貌，是整串字符。字面重合度低到匹配环节根本认不出这是同一个动作。 ## 页面侧几乎全是敬体 再翻页面这一侧，情况正好相反。 商品页、政策页、帮助中心，从头到尾都是ます和です。 这是对的，日语商业文本本来就该这么写。 但它带来一个副作用：页面上的字面形态跟用户输入的字面形态系统性地错开。 不是偶尔错开，是每一个动词性表达都错开。 名词还好，ブーツ就是ブーツ，敬体不敬体都不改它。 所以裂缝的位置很精确：它只出现在动词性和形容词性的表达上，名词性的关键词完全不受影响。这也解释了为什么很多日语站的品类词排名正常、问题型长尾却一片空白——品类词是名词，天生不受敬语影响；而问题型查询里必定有一个动词，那个动词在你的页面上穿着敬体的外衣，在用户的输入里光着身子。 ## 字面不重合会漏掉哪三类词 第一类是操作型查询：怎么退、怎么换、怎么改地址。 第二类是条件型查询：能不能退、几天内能退、超过期限还能不能。 第三类是状态型查询：有没有货、什么时候到、发到哪一步了。 这三类的共同点是核心信息都挂在动词上。 页面上这三件事其实都写了，写得还挺清楚，只是全写成了敬体长句。 用户搜的那串裸词，在整个页面里一次都没有以那个形态出现过。 这就是为什么很多日语站的帮助中心内容写得比竞品还全，自然流量却低一大截。内容没问题，覆盖也没问题，问题出在字面上：搜索引擎抓到的是页面上真实出现的字符串，不是页面表达的意思。意思对上了但字面没对上，在很多匹配环节里等于没对上，尤其是那些依赖精确形态的场景。关键词工具没数据时的替代办法 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)那篇讲的补数据思路，在这里同样管用。 ## 敬语层级到底影不影响排名，还是只影响转化？ ## 它影响的是词形匹配那一环，不是礼貌分 这个问题的标准答案是敬语只影响转化，跟排名无关。 这个答案对了一半。 搜索引擎确实不给礼貌打分，没有任何一个环节在衡量你的页面客气不客气。 但敬语档位不是一个只存在于语气层的东西，它会真实地改写页面上的字符串。 字符串一变，字面匹配、锚文本、结构化数据里的取值全跟着变。 所以敬语通过词形这条通道，间接地落在了排名这一侧。 把话说得更准确一点：敬语本身不是排名因素，敬语造成的词形差异是。这个区分很重要，因为它决定了该往哪儿使劲——不需要为了排名把页面写得不客气，只需要保证用户可能输入的那个形态在页面上真实出现过至少一次。礼貌照旧，覆盖补上，两件事不冲突。 还有一条通道容易被忽略：站内锚文本。敬语档位一高，锚文本就会从裸词变成一整个短句，而锚文本是站内传递主题的主要载体之一。导航和面包屑这两处的档位选择，实际影响的是全站的主题信号，不只是那一行字好不好看。 ## 段落级抽取那一侧，敬体长句是吃亏的 近年搜索结果里越来越多地直接抽出页面中的某一段来回答问题。 被抽中的段落有个共同特征：短、直接、答案在前面。 敬语档位一高，句子就长，答案往往被推到句尾。 返品は商品到着後14日以内に承っておりますこの一句，核心信息14日夹在中间，前后各挂着一截礼貌成分。 同样的意思写成短句，14日会跳到很靠前的位置。 这不是要求你放弃敬体，而是提醒你敬体和答案前置这两件事需要一起设计。 可行的做法是分层：段落的第一句用最短的敬体把答案说完，第二句再补条件和例外。这样礼貌没丢，抽取友好度也保住了。段落级排名的工程做法 (https://zhangwenbao.com/passage-ranking-paragraph-level-indexing-extractable-block-engineering.html)那篇讲的可抽取块设计，在日语站上要多考虑一层敬语带来的句长膨胀，同样一句话的日语敬体版本通常比常体版本长出三到四成。 句长膨胀的幅度可以量化。同一句话的常体版本和敬体版本，字符数通常差三到四成，再叠上尊敬語会到七成以上。日语这类东亚字符宽度的标准 (https://www.unicode.org/reports/tr11/)里定义的全宽字符，一个字占的版面也更大，结果是答案在句中的相对位置和在屏幕上的位置一起后移。 ## 专业度和权威度那一侧，敬语能加分吗 能，但加的方式跟大多数人想的不同。 敬语用得对，加的不是分，是不减分。 一个日语页面如果敬语方向错乱、档位忽高忽低，读者的第一反应是这内容不是本地人写的。 这个判断一旦成立，后面所有的专业性表述都会被打折。 评估这类信号的时候，语言的自然度是本地评估员最容易感知的那一层。 他们不需要懂你的行业，只需要读三段就能判断这是不是母语者写的。 所以敬语在专业度和权威度这条线上的作用是门槛而不是加分项：写对了，读者才会开始看你的内容本身；写错了，内容再好也过不了第一道感知关。质量评估指南的自查清单 (https://zhangwenbao.com/search-quality-rater-guidelines-qrg-seo-self-review-checklist.html)那篇里那套自查逻辑放到日语站上，第一条就该是找个母语者盲读三段，问他这站看着像哪国人做的。 还有个更实际的理由：本地评估员和真实用户是同一批人，感知路径也一样。他们不会逐句分析敬语对错，只会在读到第三段时形成一个模糊判断——这站像不像本地开的。这个判断一旦形成就很难翻盘，后面再好的证据也只是在跟第一印象拔河。 ## 六个页面位置各该用哪一档 ## 标题和大标题：把名词形留出来 标题这个位置的首要任务是被搜到，不是显得客气。 日语的标题传统上本来就偏向体言止め，也就是用名词收尾。 ブーツの返品方法比ブーツを返品なさる方法自然得多，也短得多。 名词形还有一个额外好处：它不带敬语方向，不存在抬错人的风险。 所以标题这一格的规则很简单，能用名词形就用名词形。 敬语让位给检索，在这个位置上不会有任何人觉得失礼。 下面这张表是保哥给日语站定的位置与档位对照，用了两年，中间只改过一格。它的用法不是查着写文案，而是反过来当审计单——上线前按位置逐格核对，看哪一格的实际档位跟表里对不上。 页面位置 | 丁寧語档位 | 尊敬語/謙譲語 | 首要目标 | 常见错法 | 标题与大标题 | 不用，走名词形 | 一律不用 | 检索覆盖 | 套上敬语后关键词被拆散 | 元描述 | ます形 | 不用 | 点击率与覆盖并重 | 写成纯敬语句，裸词一个不剩 | 正文段落 | ます形 | 按方向用 | 可读与自然 | 方向错、档位忽高忽低 | 问答的问句 | 常体或短敬体 | 不用 | 贴用户口吻 | 把问句也写成敬语长句 | 按钮与表单标签 | 短ます形或名词形 | 一律不用 | 无歧义 | 主语省略导致方向错 | 客服话术与邮件 | ます形起步 | 按方向用，可高一档 | 关系维护 | 模板写完两年没人再读 | 这张表最容易被误读的是元描述那一格。它不参与排名，很多人因此认为怎么写都行，实际上它决定用户看到结果时会不会停下来。敬体是给人的，裸词是给眼睛的，两者要在同一段一百来个字符里共存，日语的字符预算比英文紧得多。 ## 元描述：敬体可以，但裸词得塞进去 元描述是给人看的，写成敬体没问题。 它的坑在于很多人把它当成一段客气的宣传语来写。 写完一读，通篇是ございます和いたします，实词没剩几个。 这段文字不参与排名，但它决定用户看不看你这条结果。 用户扫一眼描述，找的是自己刚才打进去的那几个字。 那几个字全是裸词，你的描述里一个都没有，用户的眼睛就滑过去了。 务实的写法是前半句放裸词组成的事实陈述，后半句再用敬体收口。这样既有字面命中，读起来也不生硬。日语描述的字符预算本来就紧，礼貌成分吃掉的每一个字符，都是从事实那边扣出来的。 还有个细节：日语的元描述在移动端截断得更早，礼貌成分往往正好占掉开头那一截。把事实性的短句放在最前面，即使被截断，用户看到的那半句仍然带着他刚才输入的那几个字。电商体验趋势的用户研究更新 (https://www.nngroup.com/articles/e-commerce-usability/)里的扫读结论说得很直白，用户在结果页上停留的时间是以秒计的。 ## 问答区的问句必须用用户的口吻 整个页面上，问答区的问句是唯一一处应该主动降档的地方。 因为这一行的角色是复述用户的问题，不是站方在说话。 返品はいつまで这样的短问句，比丁寧に返品期限についてお教えいただけますか自然得多。 用户的原话什么样，这一行就该什么样。 答句再切回敬体，一问一答两档，读起来完全不违和。 这种一低一高的组合在日语的商业文本里很常见，客服的问答集就是这么写的。 这一格是整张表里性价比最高的一格：它同时解决了字面覆盖和结构化数据的取值问题，而且改起来不需要动正文一个字。把二十条问句从敬语长句改成用户口吻的裸问句，是保哥在日语站上做过的投入产出比最高的一次改动，用了不到一天。 要提醒的是降档只限于问句本身。答句还是敬体，而且答句第一句必须把答案说完。敬语在日语里的重要性 (https://www.tofugu.com/japanese/keigo/)里讲的那种日常场景，跟页面上的一问一答其实是同一个结构——问的人随意，答的人客气，两边都不觉得别扭。 ## 按钮和表单标签：短、无歧义、不许上尊敬語 按钮上的字数预算按个位数算。 敬语一进来，字数立刻翻倍。 更麻烦的是主语被压缩掉之后，方向判断失去依据。 所以这一格的规则是尊敬語和謙譲語一律不用，只留最短的ます形或者干脆名词形。 カートに入れる、購入手続きへ，这类形态在日本电商里是标准写法。 用户不会因为按钮不客气就不点，倒是会因为按钮太长而找不到重点。 表单标签同理，而且还要加一条：标签里的名词形往往就是用户搜索时用的形态，お届け先和配送先这两种写法，后者在搜索里出现得多得多。这一格顺手就做了字面覆盖，条件是别把前缀挂上去。 按钮文案还有一条日语特有的约束：假名和汉字混排的比例会影响识别速度。全假名的按钮在小字号下辨识度低，全汉字又显得生硬。稳妥写法是动词用汉字、助词用假名，カートに入れる正是这个结构，扫一眼过去重心自然落在汉字上。 ## 客服话术和邮件可以比商品页高一档 整站统一档位是最常见的错。 商品页是商品在说话，客服邮件是人在说话，两者本来就不该同档。 客服这一侧档位高一点是自然的，日本用户也确实期待这个。 但这一格有个隐藏风险：邮件模板通常在上线时翻译一次，此后再没人读过。 而这些模板的阅读量往往超过大部分商品页。 把邮件模板纳入定期复检，是这一格唯一需要的动作。 顺带一提，客服邮件里的敬语档位还有个功能是商品页给不了的：它能表达歉意的层次。发错货、延迟发货、缺货这三种情况在日语里对应的道歉表达是有明确梯度的，用错梯度比用错档位更容易激怒人。这一层已经超出了本文的范围，属于客服培训的内容，但它提醒我们敬语在不同页面上承担的功能并不相同。 ## 二重敬語为什么在商品页上代价更大？ ## 什么样的句子算二重敬語 同一个动作上叠了两层同方向的敬语，就叫二重敬語。 お召し上がりになられる是最常被拿来当例子的那一个，召し上がる本身已经是尊敬語，后面再加られる就多了一层。 官方语言机构的敬语指导文件里明确把这类形态列为不推荐。 它不是语法错误，是过头。 日本人自己也常犯，尤其是在紧张的场合，比如新人接电话。 所以你会在真实的日本服务业里听到不少二重敬語，这也是很多团队困惑的来源。 困惑的解法是分清场合：口语里的二重敬語是即时产生的，说完就散了，听的人多半只感到对方很客气；写在页面上的二重敬語是固定下来的，读者可以停下来反复看，而且它会出现在几百个页面的同一个位置上。同一个表达，在口语里是紧张，在页面上是风格。 还有一类形态介于合规和过头之间：させていただく。它在现代日语里用得极广，官方指导文件也承认难以简单判错，但页面上密集出现同样显得卑微。把它当成计数指标而不是对错判断，一页超过三次就标出来复核，比争论对错可操作得多。 ## 日本人也犯，但页面上的后果不一样 口语容错高，文本容错低，这条在任何语言里都成立。 日语的特殊之处在于差距特别大。 一个二重敬語在页面上出现一次不要紧，问题是它通常不会只出现一次。 模板化的站点会把同一句话渲染到成百上千个页面上。 读者第一次读觉得客气，第三次读开始觉得别扭，第十次读就变成这站有点怪。 而搜索引擎看到的是同一串文本在全站高频重复。 这里有个容易被忽略的连带效应：过度敬语的句子长，重复度又高，会让全站的模板文本占比上升。对以短内容为主的商品站来说，这个比例本来就紧张，礼貌成分把它推得更高。当一个品类页的可见文本里有四成是各个模块的客套话时，真正描述商品的那六成就被稀释了。 模板文本这个占比不是凭感觉判断的。把一个品类页的可见文本导出来，按模块归类统计字符数，客套话超过三成就该动手。这个数字在日本头部电商上通常在一成五到两成之间，超出太多的站，读起来的观感会明显不一样。 ## 过度敬语让商品页读起来像培训手册 这是最实际的那个后果。 日本电商的头部站点，商品页的文案其实相当克制。 敬体是基础，但不堆砌，句子短，信息密度高。 把敬语档位一路推到顶的页面，读起来像新人培训教材，而不像在卖东西。 用户要的是尺寸、材质、什么时候到，不是一段又一段的谦辞。 过度客气在日本市场并不加分，它传递的信号是这家店不太熟练。 三条可以机械检查的过度模式：同一句里出现两个以上敬语标记；させていただく这个形态在一页里超过三次；一个句子超过六十个字符还没出现实词。这三条都能写成脚本，不需要日语能力，检出来的结果交给母语审校复核。保哥用这三条扫过一个日语站，两百多个页面里命中了六十几处，其中八成集中在同一批模板上，改三个模板就全清了。 ## 关键词表要不要按敬语形态展开？ ## 两列对照表：用户打的形态和页面出现的形态 这是本文最实用的那个落地物，做法极简。 把关键词表加一列，左边写用户实际打的形态，右边写这个意思在你页面上出现的形态。 两列一样的，跳过。 两列不一样的，标出来，这就是裂缝清单。 裂缝清单不需要你去改正文，只需要保证那个裸词形态在页面的某一处真实出现。 问答的问句、表格的表头、面包屑、图片说明，都是可以放裸词的地方。 这张表最反直觉的一点是：它不要求你把页面写得更口语。恰恰相反，正文该多客气还是多客气，你只是在页面上另外找了几个不需要礼貌成分的位置，把用户输入的那串字面安置进去。语言风格和字面覆盖被分到了两个不同的容器里，谁也不用迁就谁。 意思 | 用户打的形态 | 页面上原有的形态 | 裂缝 | 安置位置 | 退货期限 | 返品 いつまで | 返品は商品到着後14日以内に承っております | 有 | 问答问句 | 换尺码 | サイズ 交換 方法 | サイズのご交換をご希望の場合は | 有 | 表格表头 | 运费 | 送料 いくら | 送料は全国一律でございます | 有 | 问答问句 | 商品品类 | ブーツ | ブーツ | 无 | 不需处理 | 库存状态 | 在庫 あり | ただいま在庫がございます | 有 | 标签与面包屑 | 裂缝那一列不必追求全覆盖。先处理既有裂缝、搜索量又集中的行，通常十行里有三四行值得动。剩下的记录在案，下次改版顺手带上。硬要一次补齐，页面会被塞成关键词清单，那是另一种伤害。 ## 哪些词需要同时收两种形态 不是所有词都值得收两遍。 判据是这个词的核心信息挂不挂在动词上。 挂在动词上的，收两种；纯名词的，收一种就够。 另一个判据是搜索量的分布：如果裸词形态的量级明显高于礼貌形态，那礼貌形态就不必单独做页面。 日语的实际情况几乎总是裸词形态占绝对多数。 所以真正需要的操作是单向的：把裸词补进页面，而不是把敬语形态补进关键词表。 这里要跟锚文本那件事分开看。屈折语里锚文本会变形 (https://zhangwenbao.com/minor-language-internal-link-anchor-inflection-variants.html)那篇讲的是词形随语法环境自动变化，站方管不住；日语敬语是站方主动选的档位，完全管得住。前者要靠版面位置绕开，后者只要定一张表就能定死，这是两种性质不同的词形问题。 判断搜索量分布时会遇到日语的额外麻烦：假名与汉字两种写法本来就在分流，敬语档位又切一刀，同一个意思可能散在四五个形态上。拿日语形态素解析器MeCab (https://taku910.github.io/mecab/)把它们还原成同一个原形，先按写法合并再按档位合并，剩下的才是真正要覆盖的形态数。 ## 动词性查询和名词性查询的分工 名词性查询进品类页和商品页。 动词性查询进帮助中心和问答区。 这个分工在英文站也成立，但在日语站上它多了一层意义。 因为动词性查询正是敬语裂缝的全部所在地。 把它们集中安置到帮助中心，等于把裂缝集中到一处来治理。 帮助中心的文本风格本来就允许更接近口语，治理成本因此很低。 这条分工还顺带解决了一个老问题：商品页要不要为了长尾去堆问答。答案是不必，日语站尤其不必——商品页堆问答会把敬语档位搅乱，而帮助中心天然容得下用户口吻的问句。两类页面各管一类查询，风格也就各自稳定了。 帮助中心还承担着另一层功能：法定告知。日本的特定商取引法 (https://www.caa.go.jp/policies/policy/consumer_transaction/specified_commercial_transactions/)对通信销售有一批必须表示的事项，退货条件正在其中。这些文本天然是敬体的，而它们跟用户口吻的问句放在同一页并不冲突，一个负责合规，一个负责被搜到。 ## 假名和汉字的选择跟敬语档位有关系吗？ ## 敬语前缀写成假名还是汉字 お和ご这两个前缀，写成假名是主流。 御问い合わせ这种全汉字写法在现代商业文本里已经少见。 这件事本身不影响敬语档位，只影响字面。 但既然影响字面，它就影响覆盖。 所以规则跟前面一致：跟着主流写法走，不必纠结，真正要盯的是有没有一个不带前缀的形态在页面上出现过。 前缀本身不是关键词，去掉前缀的那个词才是。 顺带说一个容易踩的坑：某些词去掉前缀之后意思会变，或者变得不自然，比如ご飯。这类词属于美化語里已经词汇化的那一批，前缀是词的一部分，不能拆。分辨方法是查词典看有没有独立词条，这一步不需要日语能力，查完标注在词表里就行。 前缀这件事还牵扯到排序和检索的规范化。お和ご在很多系统的排序键里是要被剥掉的，否则同一批商品会因为前缀分成两堆。这属于区域数据标记语言的通用部分 (https://www.unicode.org/reports/tr35/tr35-general.html)里排序与规范化那一块的常规处理，跟展示层写哪种形态是两回事。 ## 敬体文本里汉字比例通常更高 这是一个统计上的倾向，不是规则。 敬语表达偏书面，书面文本的汉字比例本来就高。 这个倾向会轻微改变页面的字面构成。 对检索的影响是间接的，主要落在同一个词的假名写法和汉字写法哪个更容易被搜到。 这件事跟敬语没有因果关系，只是相关。 把两件事分开处理，判断会清晰很多。 具体的分工是：写法这一层交给选词那套方法，档位这一层交给本文这张位置表。两者会在同一个词上相遇，但决策依据不同——写法看的是哪种形态被搜得多，档位看的是这个位置在跟谁说话。同一个词在标题里用汉字裸词、在正文里用假名敬体，一点也不矛盾。 汉字比例还有一个跟版面有关的连带影响：汉字和假名的字面宽度一样，信息密度却更高，同样一行装得下更多意思。而日语的换行位置由Unicode的行断算法 (https://www.unicode.org/reports/tr14/)决定，敬体长句在窄屏上折行的落点更难控制，移动端的标题区尤其明显。 ## 检索形态优先还是读感优先 这是团队里最容易吵起来的一件事。 母语审校倾向读感，运营倾向检索形态。 两边都有道理，所以需要一条事先约定的优先级。 保哥用的规则是按位置分权：标题、问答问句、表头这三处检索形态优先，其余位置读感优先。 规则写在验收单上，争议就不再需要每次重新吵一遍。 更重要的是它让母语审校知道自己在哪些格子里说了算。 没有这条约定的团队会陷入一种拉锯：审校把裸词改成敬语，运营又改回来，来回几轮之后双方都开始怀疑对方不专业。多语言内容的生产流水线 (https://zhangwenbao.com/multilingual-content-localization-production-pipeline-vs-translation.html)那篇讲过，这类冲突几乎全部源于没有事先划分决策权，而不是源于谁的判断错了。 划分决策权还有个附带好处：审校的意见可以被统计。哪一格争议最多，说明那一格的规则写得不够清楚，下一版规范就该改那一格。语气的四个维度 (https://www.nngroup.com/articles/tone-of-voice-dimensions/)那套拆法可以直接借来当规范的骨架，把语气拆成几条独立的轴，每条轴单独约定。 ## 团队里没人懂日语，这件事怎么验收？ ## 三条不依赖语言能力的自检 第一条是主语补全率：抽查一百条短文案，看有多少条在中文原稿里标出了动作的执行者。 这一条完全不涉及日语，中文原稿就能查。 第二条是裸词出现率：拿关键词表里的裸词形态，在页面全文里做字符串检索，看命中几个。 命中为零的词，就是裂缝。 第三条是句长分布：统计页面上句子的字符数，看有没有一批超长句集中在同一个模板里。 超长句扎堆的地方，通常就是敬语堆砌的地方。 这三条能在半天内跑完，结果是一份具体到行的清单，交给母语审校时不再是请帮我看看这个页面自不自然，而是这三十七处请逐条判断。审校的效率会高好几倍，因为判断的对象从整体印象变成了单点事实。语言能力这件事没法外包给流程，但判断的范围可以由流程来划定。 第二条那个裸词检索还有个升级版：不只查词在不在，还查它出现在哪一类标签里。想知道某个形态在真实书面语里常不常见，去现代日语书面语均衡语料库 (https://clrd.ninjal.ac.jp/bccwj/)查一次频次比凭感觉强。把命中位置和频次一起统计出来，清单的优先级排序就自动有了。 ## 该问母语审校哪三个问题 第一个问题：这一句里的动作是谁做的，敬语方向对不对。 这是唯一必须由母语者回答的问题，也是最值钱的那个。 第二个问题：这个档位跟这个位置匹配吗，是不是过头了。 第三个问题：这句话如果去掉所有礼貌成分，意思还完整吗。 第三个问题的用意是找出那些靠礼貌成分撑起来的空句子。 三个问题都是封闭式的，答案非黑即白，不需要审校写小作文。 把这三问做成一张表，每行一句待判文案，三列打勾，审校一小时能过掉两三百条。开放式的请你润色一下会让同一个人一小时只能过掉三十条，而且返回的结果没法统计、没法复用、下次换个人又是另一套标准。母语审校验收清单 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)那篇的核心主张就是这个：把审校的输出格式定死。 这三问还有个用法是招人时当面试题。给候选审校三句真实的站上文案，让他按三问各判一次。答得干脆的人，通常也是交付最稳的那个；把三问答成一段感想的人，日后每次返稿都会是一段感想。面试成本十分钟，省下的是后面几个月的来回。 ## 客服工单是最好也最便宜的语料 要知道日本用户怎么说话，不用去买语料库。 你自己的客服工单里全是。 用户写给客服的第一句话，用的是他自己的表达习惯。 把半年的工单导出来，按词频排一遍，裸词形态和真实说法就出来了。 这批词的商业价值极高，因为写这些话的人已经是买家或者准买家。 关键词工具给不了这个，它给的是聚合后的形态，前面已经说过那层损耗。 做这件事有个额外收获：工单里会出现一批你从没想过的问法。日本用户描述尺码问题时的说法跟中文运营脑子里的翻译版本经常对不上，而这些说法一旦补进帮助中心，命中的都是购买意图最强的那批查询。同一份关键词表在两个市场的意图分叉 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)那篇讲的分叉现象，在工单语料里看得最清楚。 工单语料还有一个别处拿不到的信息：同一个问题的两种问法背后往往是两类人。问返品 いつまで的多半已经收到货，问返品 できますか的多半还没下单。同一批词按购买阶段分个组，落地页该接哪一半就清楚了。 ## 这套判断能搬到别的语言上吗？ ## 韩语的阶称跟日语最像，但坑不在同一处 韩语也有成体系的敬语，而且档位比日语还多一层。 但韩语的检索裂缝主要不是敬语造成的。 它更大的麻烦在空格和助词上，同一个词加不加助词、空格切在哪里，直接决定能不能被搜到。 所以韩语站要先解决切分，再谈档位。 日语正好反过来，切分由引擎的词典处理，档位才是站方能控制的变量。 两门语言看着像，优先级完全不同。 这个对比说明一件事：礼貌层级这个语法特征本身并不决定你要花多少工程量，决定工程量的是这个特征有没有改写字面、以及站方能不能控制它。韩语的空格与助词 (https://zhangwenbao.com/korean-seo-spacing-particles-keyword-research.html)那篇里那条空格与语义单元的尺子，量的就是这个。 顺带把日语这一侧的边界说清楚：分词交给引擎的词典，不等于站方无事可做。面向商用的日语分词器Sudachi (https://github.com/WorksApplications/Sudachi)这类工具能让你在本地复现引擎大致会怎么切你的标题，切出来的结果跟你想强调的那个词对不对得上，跑一次就知道。 ## 判据换成一句话：档位差有没有改变字面 德语的Sie和du、法语的vous和tu，也是礼貌层级。 但它们换来换去，句子里的实词基本不动。 用户搜的那个名词、那个动词词干，两种档位下是同一串字符。 所以德法两语的礼貌选择是纯粹的品牌语气问题，跟检索无关。 日语不是，日语的档位差会整段改写动词。 这就是判据：先问档位差改不改字面，改的才需要做覆盖这层工作。 这条判据可以直接拿去筛你手上所有的目标语种，半小时就能筛完。改字面的那几门语言进检索治理清单，不改的那些交给品牌语气规范，两条线彻底分开。下面这张表是三门语言按这个判据的对照，第三列是真正要做的动作。 语言 | 礼貌层级 | 档位差改字面吗 | 检索影响 | 该做的动作 | 日语 | 三套并行，含方向 | 改，动词整段变形 | 大，动词性查询全线错位 | 按位置定档，补裸词覆盖 | 韩语 | 多档阶称 | 改，但空格与助词影响更大 | 中，主因在切分 | 先治切分，再谈档位 | 德语与法语 | 两档称呼 | 基本不改实词 | 几乎没有 | 只写进品牌语气规范 | 表里第三列那个改不改字面的判断，可以用更机械的办法做：把同一句话的两种档位分别丢进分词器，比较切出来的实词集合。集合一样就是不改字面，集合不一样就要做覆盖。日语的通用依存标注 (https://universaldependencies.org/ja/index.html)里对动词形态的标注方式，正好能说明变的是哪一层。 ## 常见问题解答 ## 日语站到底该用敬体还是常体？ 整站基调用敬体，这一点在日本商业站上没有争议。真正要决定的不是二选一，而是哪几个位置例外。标题、问答的问句、表格表头、按钮这四处走常体或者名词形，其余位置敬体。这样定完，全站风格是统一的敬体，同时用户输入的那批裸词也在页面上有了落脚点。把它写成一张位置表贴在文案规范里，比要求每个人自己拿捏可靠得多。 ## 敬语用错了会被搜索引擎判罚吗？ 不会。没有任何一个环节在给礼貌程度打分，敬语错了也不构成质量问题的判定依据。它的影响是间接的两条：一条是词形改变导致字面覆盖丢失，这条落在匹配上；另一条是母语读者感知到内容不像本地人写的，这条落在停留、回访和评估员的整体印象上。两条都不是判罚，但两条叠起来足以让一个内容不错的站长期跑不出量。 ## 把商品页改成常体会不会显得不专业？ 会，所以不要整页改。本文主张的从来不是降低敬语档位，而是在保持敬体的前提下，另外找几个不需要礼貌成分的位置来安置裸词。表头、面包屑、问答问句、图片说明这些地方在日语站上本来就不用敬体，把裸词放进去既不违和也不失礼。风格和覆盖是两件事，不必让其中一件迁就另一件。 ## 机器翻译能处理好敬语吗？ 档位能处理个大概，方向经常出错。原因不在模型能力，在于中文原文里通常根本没有写明动作的执行者，配送时间为三到五天这句话里没有任何成分标出谁在配送，模型只能猜。解法不是换更好的翻译工具，是在中文原稿上补主语。这一步由中文运营完成，成本几乎为零，却能把方向类错误砍掉大半。 ## 敬语档位需要按品类区分吗？ 需要，但区分的幅度比想象中小。高客单价、面向年长客群的品类可以整体高半档；面向年轻客群的品类可以更接近口语。真正要按品类区分的其实是另一件事——道歉和补偿类文案的表达梯度，这一层跟客单价强相关。商品页的常规档位在各品类之间的差别没那么大，不值得为它维护多套规范。 ## 怎么判断我的日语页面是不是过度敬语了？ 三条机械规则可以先跑一遍：同一句里出现两个以上敬语标记、させていただく在一页里超过三次、句子超过六十个字符还没出现实词。三条都能写成脚本，命中的结果交给母语审校复核。经验上命中会高度集中在少数几个模板上，改几个模板就能清掉大部分。这比逐页人工通读省事得多，也更容易在下次上线前重跑一遍。 ## 没有日语母语者，这套东西能落地吗？ 能落地一大半。主语补全、裸词覆盖检查、句长分布、三条过度敬语规则，这四件事都不需要日语能力。剩下必须由母语者判断的只有敬语方向对不对，以及档位跟位置匹不匹配这两项，而这两项可以打包成封闭式问题，按小时外包给一位母语审校。把不需要母语能力的部分先做完，再去买那一小块判断，是预算有限时最合理的顺序。 ## 权威参考资料 ## 非拉丁字母的站点上，同一张商品图的文件名和alt要用两套字母写同一个词 - URL：https://zhangwenbao.com/minor-language-image-alt-text-non-latin-script-search.html - 分类：小语种SEO - 发布：2020-12-09 | 更新：2026-07-27 - 摘要：非拉丁语种站上图片文件名只能走拉丁、alt只能走本地字母。讲清一张图的六个可写位置各归哪一层、alt该按信息单元数定长，以及图片关键词表为什么要比正文词表多两列。 - 关键词：图片SEO,技术SEO,多语言SEO,小语种SEO > **TLDR**：摘要：一张商品图身上有六个能写字的位置，其中两个属于URL层、四个属于文本层。在非拉丁字母的市场里这两层被强行分开：文件名这一层只能用拉丁字母，否则地址栏里变成一长串百分号编码，日志、外链、客服截图全部认不出来；alt和图注这一层只能用本地字母，因为用户搜的就是本地字母。同一个商品词，在同一张图上被迫写成两套字母。英文站永远碰不上这件事，因为它六处填的是同一个字符串。附带两笔账：alt不超过125字符那条经验值不能直接抄，各书写系统同字符数装的信息量差两三倍；图上烧了字，跨语言复用面直接掉到零。 > 摘要：一张商品图身上有六个能写字的位置，其中两个属于URL层、四个属于文本层。在非拉丁字母的市场里这两层被强行分开：文件名这一层只能用拉丁字母，否则地址栏里变成一长串百分号编码，日志、外链、客服截图全部认不出来；alt和图注这一层只能用本地字母，因为用户搜的就是本地字母。同一个商品词，在同一张图上被迫写成两套字母。英文站永远碰不上这件事，因为它六处填的是同一个字符串。附带两笔账：alt不超过125字符那条经验值不能直接抄，各书写系统同字符数装的信息量差两三倍；图上烧了字，跨语言复用面直接掉到零。 ## 为什么图片这一层是小语种站上最容易捡的那块流量？ ## 本地对手的图片字段多半是空的 做小语种站的人习惯把注意力放在标题和正文上，图片字段往后排。 本地的竞争对手也这么想，而且他们排得更后。 原因很实在：商品图大多是从供应商或者品牌方那儿拿的，连带文件名一起拿过来。 后台上传时alt字段留空，或者由系统自动填成文件名。 于是一个本地电商站上成千张图，alt里写的是一串英文字母加数字。 你只要把这个字段按本地语言认真填一遍，在这个赛道上就没什么对手。 这跟正文的竞争格局差别很大。正文这一层本地站有天然优势，他们的语言比你地道、内容比你贴近本地生活；图片字段这一层不比语言功底，比有没有人愿意把它当成一件正经事来做，而这件事全行业都懒。保哥手上一个做彩妆和防晒的客户，第一批图只是把alt从空白改成了本地语言的商品描述，两个月后图片入口的进站量涨了一截，正文一个字没改。 ## 图片是唯一不需要翻译的资产 做多语言站最贵的是内容，因为每加一门语言就要重写一遍。 图片是个例外：一张口红的产品图，在任何语言的站上都是同一张。 拍摄、修图、压缩、裁切这些成本只付一次。 需要按语言重做的只有围绕它的文字，而文字的成本远低于重拍。 所以图片在多语言项目里的性价比结构跟正文完全不同。 这个优势有一个前提，也是本文后面要专门讲的一节：图上不能烧文字。 把图片理解成一次生产多处复用的资产，会改变你排预算的方式。同样一万元，花在图片上产出的是十一个语言版本共用的东西，花在文案上产出的是一个语言版本的东西。这条账在印度那种十一门语言分摊九套书写系统的市场 (https://zhangwenbao.com/india-multilingual-seo-eleven-languages-nine-scripts-priority.html)里格外明显，因为语言门数越多，可复用资产的杠杆就越大。 ## 这块流量的入口不止图片搜索 图片字段填好之后，受益的入口不只有图片搜索这一处。 网页搜索的结果里越来越多带缩略图，能不能被选中跟图片字段有关。 用图找图这类以图为输入的搜索，靠的是图片内容加上下文文字。 社交平台抓取分享卡片时会读图片相关的标记。 站内搜索如果索引了alt，本地用户用本地词搜商品的命中率会提高。 无障碍这一头也顺带解决了，屏幕阅读器读的就是alt。 一个字段同时服务五六个消费方，这在SEO里不算常见。读图能力与视觉搜索那套机制 (https://zhangwenbao.com/image-seo-vision-ai-multimodal-search-google-lens-mechanism.html)讲的是引擎怎么理解图片本身，本文讲的是同一张图周围那些文字该用哪套字母写——前者是引擎侧的能力，后者是你这边能控制的输入。 这里要提醒一句别把图片入口当成救命稻草。它的量级通常是网页搜索入口的两三成，好处是它便宜、见效快、竞争少，坏处是它撑不起一个市场的主要流量。合理的定位是拿它当第一批可见成果去换团队对小语种项目的耐心，主力仍然要压在正文和类目结构上。 ## 一张图上到底有几个能写字的位置？ ## 六个位置，各自服务不同的读者 先把位置数清楚，不数清楚就没法讨论该用哪套字母。 第一个是图片文件名，出现在URL里。 第二个是alt属性，机器和屏幕阅读器读它。 第三个是title属性，鼠标悬停时显示，实际作用很小。 第四个是图注，figure与图注这一组结构 (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/figure)是它的标准写法，人和机器都读。 第五个是图片上下两段正文，它给图片提供语境。 第六个是结构化数据里描述这张图的那组字段。 六个位置里只有第三个可以省略不写，其余五个都值得填。省略title的理由是它在移动端根本不会触发，而且它和alt重复时反而会让屏幕阅读器读两遍。剩下五个位置的关系不是互相替代，是分工：URL层负责可读性和可追踪性，文本层负责检索匹配和无障碍。 ## 文件名和contentUrl属于URL层 文件名和结构化数据里的图片地址字段，本质上是同一个东西的两处出现。 它们的取值都是URL，而URL的字符集受规范约束。 国际化资源标识符那份规范 (https://www.rfc-editor.org/rfc/rfc3987)允许非ASCII字符，但要求传输时做百分号编码。 编码之后一个本地字母变成三到九个字符的转义序列。 浏览器地址栏可能会把它显示回原文，日志、报表、外链里通常不会。 所以这一层的约束不是不能用本地字母，是用了之后代价由你自己承担。 把这一层单独拎出来的意义在于：它的读者跟文本层完全不同。文件名的读者是你的运维、你的数据分析师、贴外链的站长、把商品链接发到客服窗口的用户。这些读者要么读的是纯文本日志，要么读的是被截断的URL片段，本地字母在这些场景下的还原率都不高。 ## alt、图注、周边正文属于文本层 文本层的三个位置有一个共同点：它们的读者是本地用户和搜索引擎的语言模型。 alt是给看不到图的那一方看的，包括屏幕阅读器和抓取程序。 图注是给看得到图的人补充信息的，语气可以更像一句人话。 周边正文提供语境，让引擎判断这张图跟这个页面的关系。 三处都必须用本地字母，因为用户输入的查询就是本地字母。 写成拉丁转写等于把匹配的机会主动扔掉。 三处内容不该完全一样。alt写得简洁准确，图注可以带一点场景和用途，周边正文承担的是解释和延展。三处都写同一句话，等于浪费了两处位置，而且屏幕阅读器用户会连着听到重复内容，体验不好。 还有一个位置上的细节：图注和周边正文都在页面可见区域里，它们要同时服务本地用户的阅读体验和检索匹配，所以不能写成关键词罗列。alt不在可见区域，理论上可以写得更贴近检索口径，但它要过屏幕阅读器这一关，所以也不能罗列。三处都受可读性约束，只是约束来自不同的读者。 ## 一张分治表把六个位置排清楚 把六个位置、该用的字母、读它的人、写错的后果排成一张表，落地时对着填就行。 这张表最有用的地方是它把书写系统这一列显式写出来了。 没有这一列，团队会默认六处用同一套字母，然后在某一处出问题。 出问题的方式通常不是报错，是某个入口的流量一直上不来。 表里还有一列标注这个位置能不能自动生成。 能自动生成的位置放进流水线，不能的留给人工。 位置 | 该用哪套字母 | 谁读它 | 写错的后果 | 能否自动生成 | 图片文件名 | 拉丁转写 | 运维、分析、贴链接的人 | 日志与外链里认不出 | 能，按转写规则 | alt属性 | 本地字母 | 抓取程序、屏幕阅读器 | 本地词查询匹配不上 | 半自动，模板加人工 | title属性 | 可省略 | 桌面端悬停用户 | 与alt重复被读两遍 | 建议不填 | 图注 | 本地字母 | 本地用户、引擎 | 浪费一处高可见位置 | 不能，需人工 | 周边正文 | 本地字母 | 本地用户、引擎 | 图与页面关联变弱 | 不能，需人工 | 结构化数据的图片字段 | 地址拉丁、说明本地字母 | 只有引擎 | 富媒体结果拿不到 | 能，模板输出 | 这张表的第二列是本文的核心：六个位置里两个必须拉丁、三个必须本地字母、一个建议留空。同一个商品词要在这六处按两套规则分别写一遍，而且不能写反。英文站的同一张表里，第二列六行全是同一个值，所以英文的图片SEO教程从来不讨论这一列，你照着抄就会在这里出错。 ## 文件名和alt为什么必须用两套字母写同一个词？ ## URL层不接受本地字母，除非你接受百分号编码 把一张口红图命名成本地语言的商品名，看起来是最自然的做法。 存到服务器上没问题，页面显示也没问题，问题出在URL被写成文本的时候。 俄语的靴子这个词做成文件名，编码之后是%D0%B1%D0%BE%D1%82%D0%B8%D0%BD%D0%BA%D0%B8这样一串。 一个词变成三十多个字符，而且完全不可读。 这串东西出现在日志里，排查某张图的抓取情况就得先解码一遍。 出现在别人贴的外链里，多半会被截断或者转义两次。 更麻烦的是二次编码。有些系统会把已经编码过的串再编码一次，百分号本身变成%25，图片直接404。这类问题的排查成本很高，因为出错的地方在传输链路上，页面源码看着完全正常。百分号编码的规则 (https://developer.mozilla.org/en-US/docs/Glossary/Percent-encoding)本身不复杂，麻烦的是链路上有几个环节各自编码一次。 ## 文本层不接受拉丁转写，因为用户搜的是本地字母 反过来看alt。把alt写成拉丁转写，页面照样正常，无障碍照样能用。 但用户在搜索框里打的是本地字母，转写形态跟查询串对不上。 引擎有一定的跨书写系统匹配能力，但它对这类匹配的置信度不高。 在商品词这种短查询上，字符串能不能对上仍然很重要。 而且屏幕阅读器读拉丁转写会读成一串怪音，本地用户听不懂。 所以alt这一层的答案是唯一的：本地字母，没有折中。 有个中间做法值得一提：alt写本地字母，另外在页内某处放一份拉丁写法当别名。这不是给alt用的，是给那些习惯用拉丁字母打本地词的用户准备的。拉丁字母打出来的那半边搜索 (https://zhangwenbao.com/greek-seo-greeklish-latin-transliteration-coverage.html)在希腊语和印度诸语言市场占比很高，但它该被放在页内文本里，不该挤进alt。 ## 英文站上这两处是同一个字符串，所以没人想过这个问题 英文站上一张口红图，文件名叫matte-lipstick-red.webp，alt写matte red lipstick。 两处的字符集完全一样，字符串几乎一样，写的人根本不需要做任何决定。 所以英文的图片优化教程里，文件名和alt永远被放在同一节里讲，规则也一样：写清楚、别堆词、用连字符分隔。 把这套规则搬到非拉丁市场，团队会自然地在两处填同一个值。 填成本地字母，URL那头出问题；填成拉丁转写，检索那头出问题。 两个后果都不会立刻暴露，所以这个错误能在站上待很久。 这是英文经验最容易失效的一类地方：不是规则本身错了，是规则背后有一个没写出来的前提。那个前提是文件名和alt用的是同一套字符集。前提在英文里恒成立，所以没人写下来；换到非拉丁语种，前提没了，规则跟着塌一半。文件名、alt与压缩那套通用做法 (https://zhangwenbao.com/website-photo-seo-optimization-techniques.html)照抄没错，唯独这一列要重新决定。 ## 两套字母之间要靠一份映射表对齐 两套写法各写一遍，接下来要保证它们对得上。 对不上的典型症状是文件名叫botinki，alt里写的却是另一个近义词。 解决办法是一份商品词映射表，一行记录本地写法、拉丁转写、英语对照。 转写规则要固定成一套，别让不同的人各转一版。 规则可以借用官方的罗马化方案，可读性略差但一致性最好。 表建好之后文件名可以按规则自动生成，人工只管alt那一列。 映射表还有一个副作用好处：它天然就是一份图片关键词表的骨架。后面讲图片词表要比正文词表多两列，多的那两列正好是这张映射表里的转写列和英语列。所以这两件事应该一起做，做完一份表两处用。 映射表要不要包含全部商品词，取决于站的规模。几百个SKU的站可以逐个词做，几万个SKU的站只做类目词和属性词，具体商品名靠模板拼接。折中的判据是看这个词会不会重复出现在多张图上：会重复的就进表，只出现一次的交给模板。这样表的规模能控制在几百行以内，一个人半天能维护一遍。 ## 图片文件名在非拉丁语种站上还剩多少价值？ ## 网页排名这一头本来就帮不上 先把一个流行说法摆平：给图片改个含关键词的文件名，能不能帮网页排名。 基本帮不上。网页的排名靠的是页面的文字内容和站外信号，图片文件名的权重低到可以忽略。 这一点在英文站上就已经成立，跟语种无关。 所以那种把商品全部关键词塞进文件名的做法，收益接近零。 它的真实用处在别处：图片检索的匹配、内部管理的可辨识、以及排查问题时的可读性。 三个用处里只有第一个跟排名有关，而且是弱信号。 把这个前提说清楚很重要，因为它决定了后面的取舍。如果文件名是强排名信号，那非拉丁语种站就得纠结要不要为了它承受百分号编码的代价；既然它只是弱信号加管理便利，那取舍就很清楚了——挑对管理更友好的那套字母。 ## 图片检索这一头的弱信号被编码吃掉了 图片检索这边，文件名确实是一个可读的弱信号。 引擎会把文件名里的词切出来，跟alt和周边文字一起参考。 问题是本地字母的文件名在传输时已经变成了百分号序列。 解码回原文对引擎不是难事，但这一步增加了不确定性。 更实际的损失在别处：这串编码贴到任何地方都不像一个词。 本来能顺手带来一点可读性收益的字段，变成了一串谁都不愿意看的乱码。 所以这里的结论不是本地字母的文件名会被惩罚，是它把一个本来微弱的正收益换成了一堆实际的麻烦。用一个弱信号去换日志可读性、外链可辨识、排查便利这三样东西，这笔交易怎么算都不划算。 顺着这条再多说一句：把本地字母的商品词写进文件名，还会让你的图片在被第三方引用时失去可追踪性。别人从你站上拿图，通常是复制URL，而复制过去的那串编码在他们的页面上就是一串乱码，谁也不会去查它原本是什么词。本来能顺手带一点品牌可辨识度的地方，也一起丢了。 ## 所以文件名一律走拉丁，语言信号全压到alt上 结论很干脆：图片文件名统一用拉丁转写，语言信号全交给alt，不做例外。 转写规则固定，全站一致，能自动生成。 语言层面的信号全部交给alt、图注和周边正文承担。 这三处加起来的信号强度远超文件名，所以损失几乎为零。 而收益是整套URL体系保持可读、可追踪、可粘贴。 这条规则简单到可以写进上传流程的校验里：文件名只允许小写拉丁字母、数字和连字符。 需要跟另一件事划清界限：页面URL和图片文件名的答案不一样。页面URL用本地字母还是拉丁转写 (https://zhangwenbao.com/minor-language-url-native-script-vs-latin-transliteration.html)那篇给出的是权衡，因为页面URL有几条支持本地字母的理由——它会出现在搜索结果里被加粗、它会被当成外链锚文本的一部分、它对本地用户有可读性。图片文件名一条都不成立：它不出现在结果页、不当锚文本、本地用户根本看不到它。同一个技术问题，两个位置的答案相反。 ## alt写多长才够，英文那个125字符能直接抄吗？ ## 125这个数字是怎么来的 alt不要超过125字符，这条建议流传很广，很多人以为它是规范条文。 它不是。HTML规范里关于alt的那一节 (https://html.spec.whatwg.org/multipage/images.html)只讲这个属性该表达什么，从头到尾没有字数上限。 125这个数字来自无障碍社区的实践经验，跟部分屏幕阅读器的朗读行为有关。 它的本意是提醒你写一句话，不要写一段话。 换算成英文大概是二十个词，正好是一句自然的描述句。 所以它约束的其实是信息量，字符数只是一个方便的代理指标。 把代理指标当成硬规则，是这类经验值最常见的误用方式。判断一条alt写得合不合适，看的是它能不能让听不到图的人在脑子里建立一个准确的印象，而不是它有几个字符。无障碍社区那份alt写法指南 (https://webaim.org/techniques/alttext/)讲得很清楚，重点在于表达图片在这个语境里的功能。 ## 同样125个字符，各语言装的信息量差两三倍 代理指标一旦跨语言就失灵了，因为字符的信息密度差得很远。 英文125个字符装二十个词，日语125个字符能装一段完整的商品描述加使用场景。 天城文和泰文的情况类似，一个字符携带的信息量明显高于拉丁字母。 照125这个上限写，非拉丁语种的alt会写得过长，读起来像一段说明书，写alt那几条常见反例 (https://www.deque.com/blog/great-alt-text-introduction/)里长得离谱是排第一位的。 屏幕阅读器把它一口气念完，用户听到一半就失去耐心了。 所以这些语种的实际上限应该更低，按字符算大概是英文的三分之一到二分之一。 这里有一件容易忽略的事：alt过长的害处不在SEO，在无障碍体验。引擎不会因为alt长就扣分，它会自己截取或者忽略多余部分；被折磨的是那些真正依赖alt的人。所以这条上限该按人的耐受度定，而人的耐受度是按听多久算的，不是按字符数算的。 ## 改成按信息单元数定：主体、属性、场景 可用的替代口径是数信息单元，一个信息单元就是一个能独立回答问题的点。 商品图的alt一般需要三个单元：这是什么、什么规格或颜色、在什么场景下用，怎么写出一条好alt (https://moz.com/learn/seo/alt-text)那份说明里的例子也是这个结构。 三个单元写完就停，不管这门语言用了多少字符。 如果图片本身传达了第四个信息，比如包装形态或者对比关系，可以加到四个。 超过四个说明你在写商品描述，那些内容该放到图注或者正文里。 这个口径的好处是它跨语言恒定，不需要为每门语言重新定一个字符上限。 信息单元 | 回答什么 | 彩妆类的例子（占位） | 必要性 | 主体 | 这是什么商品 | 哑光口红 | 必须 | 属性 | 颜色、规格、型号 | 正红色、3.5克 | 必须 | 场景 | 怎么用、给谁用 | 日常通勤妆 | 建议有 | 关系 | 与图中其他元素的对比 | 与裸色款并排对照 | 图里有才写 | 用这张表验收alt比数字符方便得多，因为它可以交给不懂那门语言的人做：把alt机器翻译回中文，数一数有几个单元、有没有缺主体。这是一个不依赖语言能力的检查，跟母语审校验收里那几个自己也能跑的自检 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)是同一类做法。 ## 复合词语言的反方向问题 信息密度这件事在德语这类语言上是反过来的。 德语把修饰关系拼成一个长单词，一个词就能占二十多个字符。 125个字符只装得下五六个词，一句完整的描述句都不一定装得下。 照125这个上限写，德语的alt会被迫写得过于简略。 所以同一条经验值在两个方向上都会出错，只是错的方向相反。 这也是为什么按信息单元数定的口径更稳：它不关心一个概念用了几个字符表达。 顺带一句，复合词在图片这一层还有别的影响。德语复合词把关键词拼成一个长单词 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)之后，alt里到底写整个复合词还是拆开写，答案跟正文关键词的处理一致：写用户实际会搜的那个形态，通常是整词。 再往前推一步，凝集程度高的语言在alt里还有个便利：一个复合词就把主体和属性两个信息单元一起说完了，剩下的字符可以全给场景。芬兰语、匈牙利语这类靠格尾承载关系的语言也类似，一个词形能表达出别的语言要三个词才说清的关系。这类语言的alt往往写得比英文短，但信息量不少。 ## 用户搜图时打的是本地字母还是拉丁字母？ ## 图片搜索是识别型查询，输入更随手 正文查询和图片查询的用户心态不一样。 搜文章的人想找到答案，愿意多花两秒把词打准。 搜图的人往往在辨认、比对、找灵感，输入更随手。 随手的直接后果就是不切输入法，用手边的英文键盘直接拼。 拼出来的可能是本地词的拉丁形态，也可能干脆是英语词。 这个比例在几个非拉丁市场都明显高于正文查询。 这条差异的实用价值在于：它意味着图片这一层的关键词策略不能直接沿用正文那一套。正文词表刚刚花了很大力气把拉丁变体和英语混词剔除干净，图片词表却需要把它们请回来。同一个团队在同一个季度里做两件方向相反的事，不写清楚就会来回改。 ## 拉丁与英语混着打的比例比正文查询高 混着打的形态有三种。 第一种是整串拉丁转写，比如把本地语言的口红那个词按音拼出来。 第二种是本地词加英语词，比如本地的颜色词配英语的商品品类词。 第三种是纯英语，尤其是国际品牌名和品类名。 三种形态在图片查询里都很常见，而在正文查询里第三种占比要低不少。 品牌名这一项尤其明显，因为品牌方自己就用拉丁字母写它。 品牌名的写法有它自己的一套讲究，品牌名叫什么由当地用户的输入法决定 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)那篇专门讲这个。图片这一层的处理更简单一点：品牌名两种写法都可以出现，因为它在alt里占的字符不多，写成本地写法加括号里的拉丁原名是个常见做法，也不会显得堆砌。 ## 这决定了图片关键词表要多两列 把三种输入形态折成两列加进词表：拉丁转写列、英语对照列。 这两列的取值不需要覆盖全部变体，取最主流的一到两种。 它们的用途也不是全部写进alt，而是分配到不同位置。 alt写本地字母，品牌名可以带拉丁原名。 拉丁转写放到页内的商品别名或者常见问法区块。 英语对照放到国际化版本的页面上，不混进本地语言页面。 分配这一步是关键。三种形态如果全塞进alt，alt就变成了关键词列表，既伤无障碍体验又容易被判成堆砌。正确的做法是让不同形态出现在不同位置，同一个页面覆盖三种查询，而每个位置各自读起来都很自然。 ## 图片关键词表凭什么要比正文关键词表多两列？ ## 正文词表要剔除的那两列，图片词表要保留 做正文关键词表时，第一件事往往是把拉丁转写和英语词剔掉。 剔的理由很正当：正文要写得地道，混着拉丁字母的正文读起来不像本地内容。 图片词表的目标不一样，它服务的是一批输入更随手的查询。 所以同一个词在正文词表里只留本地写法，在图片词表里要留三种写法。 两份词表的字段结构不同，是因为它们服务的查询分布不同。 把它们合成一份，必然有一边被将就。 这条差别在项目管理上有个具体后果：图片词表不能由正文词表导出，得单独建。很多团队图省事，直接拿正文词表当图片词表用，结果图片这一层只覆盖了本地字母那一种输入形态，而这一层恰好是拉丁输入占比最高的地方。工具查不到数据时那几个补数办法 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)在图片词表上同样适用，而且更好用，因为图片查询的形态更容易从站内搜索日志里看出来。 ## 五列结构长什么样 一份够用的图片关键词表有五列。 第一列本地写法，用于alt和图注。 第二列拉丁转写，取最主流的一到两种，用于页内别名。 第三列英语对照，用于国际版本和品牌名括注。 第四列文件名形态，按固定转写规则生成，小写加连字符。 第五列标注这个词属于哪个信息单元：主体、属性、场景。 列 | 取值来源 | 用在哪个位置 | 能否自动生成 | 本地写法 | 本地词表与站内搜索日志 | alt、图注、周边正文 | 不能 | 拉丁转写 | 站内日志里的真实拼法 | 页内商品别名区块 | 不能，须取真实拼法 | 英语对照 | 国际站现有词表 | 国际版本、品牌名括注 | 能，从英文站映射 | 文件名形态 | 固定转写规则 | 图片文件名、图片地址 | 能 | 信息单元归类 | 人工标注一次 | alt的组装与验收 | 不能 | 第五列是这张表里最容易被省掉也最值钱的一列。标了信息单元之后，alt可以按模板组装：主体加属性加场景，从表里各取一个词填进去。这样一批图的alt能半自动生成，人工只负责挑词和最后通读，效率比逐条手写高很多，而质量反而更稳定，因为模板保证了每条alt都有主体。 ## 两份词表分开维护，别合成一份 分开维护的成本没那么高，因为两份表共用第一列。 正文词表新增一个词，图片词表只需要补另外几列。 维护的关键是明确谁负责哪一份，别让两个人各自改同一份表。 常见的分工是内容负责正文词表，运营或者电商负责图片词表。 两份表定期对一遍第一列，保证核心词没有一边缺失。 对表这个动作一个季度做一次就够，不需要实时同步。 有一个不该分开的东西是转写规则。两份表里凡是涉及拉丁形态的，必须用同一套规则，否则文件名和页内别名会出现同一个词两种拼法。规则写成一份文档，或者直接写成一个函数挂进后台，比靠人记住可靠得多。 ## 图上烧进去的那行字，把一张图的复用面砍掉了多少？ ## 无字的图复用面是全部，烧了字就变成按语言重做 一张纯商品图，十一个语言版本用同一张，复用面是百分之百。 图上烧了一行促销文字，复用面立刻掉到零，每个语言都要重出一张。 中间没有过渡状态，因为图上的字要么全对要么全不对。 成本从一份变成N份，而N等于你的语言门数。 更麻烦的是维护：促销文案改一次，N张图全部重出。 设计排期在改版季会直接被这件事吃掉。 这条账在语言门数少的时候不明显，两三门语言的站烧点字也就是多做两三张。门数上到八门十门，它就变成了设计团队的主要负担，而且是那种看起来很琐碎、汇报时说不清、但确实占掉大半工时的负担。 还有一种中间状态值得单独说：图上的文字不是文案而是实物本身带的，比如包装上印的成分表、瓶身上的品牌名。这类图不算烧字，因为那些字是商品的一部分，不需要按语言替换。判断标准很简单：这行字是设计师后加的还是拍进去的，后加的按烧字算，拍进去的按商品特征算。 ## 四档处理办法 第一档最省：图上不放任何文字，文字全部走HTML层。 第二档次之：把文字做成叠在图上的HTML或者SVG层，视觉效果接近烧字，但文本可以按语言替换。 第三档是按语言各出一版图，成本最高但视觉控制最好。 第四档是把文字换成图形符号，比如用箭头、对勾、数字代替文字说明。 四档不是优劣排序，是按场景选：商品主图走第一档，营销横幅走第二档，包装展示图不得不走第三档。 第四档适合流程图和对比图，把语言依赖降到最低。 档位 | 做法 | 跨语言复用面 | 适合的图片类型 | 一 | 图上不放字 | 百分之百 | 商品主图、细节图 | 二 | 文字做HTML或SVG叠层 | 百分之百，只换文本 | 营销横幅、专题头图 | 三 | 每语言各出一版 | 零 | 包装图、含实物文字的图 | 四 | 文字换成图形符号 | 百分之百 | 流程图、对比图、尺码图 | 第二档是性价比最高的那一档，也是最容易被设计流程挡住的一档。它要求设计师交付的不是一张成品图，而是一张底图加一份文字位置说明，前端再把文字叠上去。这个交付方式的改变比技术实现难，因为它动的是设计和前端的协作习惯。改成了就一劳永逸，改不成就每季度重出一批图。 ## 烧字还会撞上字库缺字 图上烧非拉丁文字有一个额外的坑：设计软件里的字体不一定有那些字形。 常见的设计字体对天城文、泰文、谚文的覆盖非常有限。 缺字的表现是显示成空框，或者被替换成一个风格完全不搭的回退字体。 设计师如果不懂那门语言，很难发现某个字被替换了。 还有授权问题：覆盖多书写系统的商用字体授权费不便宜。 这笔钱在网页字体的预算里已经算过一遍，图上烧字要再算一遍。 说清一件事：图上烧字不占首屏的KB预算，因为它不加载字体文件。但它把成本换了个地方付——从带宽换成了设计工时和字体授权。小语种字体在首屏那笔KB账 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)算的是前者，这一节算的是后者，两笔账要分开记，不然会得出图上烧字更省这种错误结论。 ## 结构化数据里的图片字段该按哪套书写系统填？ ## 地址字段是拉丁，说明字段是本地字母 结构化数据里描述一张图的那组字段，同样被两套字母切开。 图片地址字段的取值是URL，所以走拉丁，跟文件名一致。 图注字段 (https://schema.org/caption)和名称字段的取值是给人看的文本，所以走本地字母。 这两类字段在同一个对象里紧挨着，最容易填反。 填反了页面不报错，校验工具也不报错，因为两者的取值类型都合法。 暴露方式是这张图始终拿不到应有的展现，而你查不出原因。 这跟正文与标记的方向问题是同一个家族的问题。正文越本地化越好而标记里要反着写回国际格式 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)那篇讲的是价格、日期、语言标签这几类字段；图片这一组字段的分界线更细：同一个对象里，地址类走机器格式，说明类走本地语言，中间没有统一规则可套。 ## 图片相关的几个字段容易整块复制错 多语言站的结构化数据模板通常从主站复制。 图片那一组字段里，地址会被模板变量替换掉，说明类字段经常留着写死的英文。 于是十一个语言版本的图注全是同一句英文，而且是从英文站带过来的那句。 这种错误的隐蔽性很高，因为它出现在页面源码里而不是页面上。 排查的办法只有一个：逐语种抓一遍源码，把说明类字段的语言核对一遍。 核对可以自动化，判断依据是这个字段的字符是不是落在该语言的码位区间里；顺手可以给图注区块补上声明语言的lang属性 (https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/lang)。 这个判断写成断言只要几行：取字段值，检查里面有没有本该出现的书写系统的字符。天城文站的图注里全是拉丁字母，那就一定有问题。反过来也要查：图片地址字段里出现了非拉丁字符，说明有人把本地字母的文件名写进了标记。两条断言挂进上线流程，这类错误就不会再回来。 ## 校验工具查不出书写系统填错 结构化数据的校验工具查的是语法和必填项。 它会告诉你缺了哪个字段、类型对不对、值能不能解析。 它不会告诉你这个字段的语言写错了，因为语言不是它的检查项。 换句话说，工具能保证你的标记是合法的，不能保证它是对的。 合法和正确之间那道缝，就是本节这类错误长期存在的地方。 补这道缝只能靠自己写断言，指望工具是没用的。 顺带说一下工具本身的变化：老的那个结构化数据测试工具已经宣布弃用，检查富媒体资格的活交给了富媒体测试工具。两者的检查口径略有不同，但对本节讨论的问题都一样无能——它们不关心你的图注是用哪套字母写的。 ## 一批商品图从供应商拿到手，六个位置怎么排成一条流水线？ ## 入库时先做文件名规范化 供应商给的图，文件名通常是型号、批次号或者一串数字。 入库第一步就把文件名换成规范形态，别等上线前再改。 换的依据是商品词映射表里的文件名列，加上型号和颜色代码。 规则固定成小写拉丁字母、数字、连字符三类字符。 这一步完全可以脚本化，人工只负责把商品和图对上。 规范化之后的文件名同时解决了管理和检索两件事。 放在最前面做的理由是文件名一旦上线就不好改了，改动会产生301或者404，还要连带更新缓存和CDN。图片URL的变更成本比页面URL低一些，但也不是零。趁入库时一次做对，比上线后返工便宜得多。 ## alt的生成分自动与人工两条路 alt不能全自动，也不该全人工。 可自动的部分是模板组装：从词表里取主体、属性、场景三个词填进句式。 需要人工的部分是挑词和通读，尤其是场景那一格。 人工那一步的工作量比逐条手写小很多，因为句式和候选词都是现成的。 句式要准备两三套轮换，避免一批图的alt全是同一个句式。 轮换不是为了骗引擎，是为了让屏幕阅读器连读几张图时不那么单调。 有一件事绝对不能自动化：拿英文alt机器翻译成本地语言。翻译出来的是语义正确但没人搜的词，跟关键词直译犯的是同一个错。拿词典逐词换出来的关键词表 (https://zhangwenbao.com/keyword-literal-translation-legacy-cost-non-english.html)那笔损失，在alt上会以图片入口长期没有流量的形式出现，而且很难归因，因为你看不出alt写得有什么不对。 ## 抽样验收查哪四项 一批图上线前抽百分之十，查四项。 第一项文件名合规：只有小写拉丁、数字、连字符。 第二项alt书写系统正确：里面有本该出现的那套字母的字符。 第三项信息单元齐全：主体和属性必须有，场景尽量有。 第四项长度合理：按信息单元数判断，不按字符数判断。 四项里前两项可以脚本查，后两项需要人工看，但不需要懂那门语言。 不懂那门语言也能查后两项，靠的是把alt机器翻译回中文再数单元。翻译回来的中文哪怕生硬，也足够看出缺不缺主体、有没有把三个单元写成一段说明书。这是个粗糙但有效的自检，比什么都不查好太多。 ## 上线后靠断言脚本兜住回退 图片字段的回退场景很固定。 换后台或者换插件时，alt字段的默认填充逻辑变了。 批量导入新商品时，导入模板里没有alt这一列。 前端改版时把图注模板换成了通用文案。 三种场景的共同点是改动的人不知道这些字段有语言要求。 所以防线只能是自动的：定期扫全站图片，查空alt、查拉丁alt、查非拉丁文件名。 脚本每周跑一次，结果丢进一个报表就够。真正的价值不在发现问题，在于让这件事有人负责——有报表就有人看，没报表这些字段会在下一次改版后集体退回原样，而且没人会注意到。 脚本要查的三项之外，还值得加一条对比项：本周的空alt数量跟上周的差值。绝对数量高不一定是问题，可能是新上了一批商品还没配文案；差值突然跳高才是真信号，说明某个环节的默认行为变了。这条差值比绝对值更适合当告警阈值，也更不容易被长期忽略。 ## 常见问题解答 ## alt里该不该写品牌名和型号？ 品牌名该写，型号看情况。品牌名是用户搜图时的高频输入，而且在非拉丁市场它常常以拉丁原名的形态出现，写成本地写法加括号里的拉丁原名是个稳妥做法，占不了几个字符。型号只在用户会拿型号搜的品类里写，比如3C和汽配；彩妆、服装这类品类用户不搜型号，写进去只是占位置。判断办法是看站内搜索日志里有没有型号查询，有就写，没有就省下这几个字符留给场景描述。 ## 图片文件名用本地字母到底会出什么问题？ 页面显示不会出问题，出问题的地方在URL被写成文本的时候。本地字母做文件名，传输时要做百分号编码，一个词能变成三十多个字符的转义串。这串东西在服务器日志里不可读，排查抓取要先解码；贴到外部平台常被截断或者二次编码，二次编码会让百分号本身变成%25，图片直接404。收益那一头呢，文件名对网页排名基本没用，对图片检索只是弱信号。用一个弱信号换掉日志可读、外链可辨识、排查便利这三样，怎么算都不划算。 ## alt能不能用机器翻译批量生成？ 不能直接用。机器翻译产出的是语义正确的表述，而alt需要的是用户实际会输入的那个词，两者经常不是同一个。更稳的做法是先建本地词表，再用模板组装：主体加属性加场景，三个词都从词表里取，机器只负责套句式。这样产出的alt既是本地真实用词，又能半自动化。机器翻译在这条流水线里有一个正当用途——把生成好的alt翻译回中文，供不懂那门语言的人做验收自检。 ## 一张图在不同语言版本要不要用不同的URL？ 不要，同一张图用同一个URL。同一个文件在多个语言页面上引用，能共享缓存、共享CDN命中、共享外链信号，而且省掉一大堆存储和同步工作。图片URL不需要带语言标识，因为图片本身没有语言。真正需要按语言变化的是围绕它的文字：alt、图注、周边正文，这三处按语言写。唯一的例外是图上烧了文字的图，那种图本质上已经是不同的资产，自然也是不同的URL。 ## 图注和alt写一样的内容算不算重复？ 算浪费，不算违规。两处的读者不同：alt是给看不到图的人和抓取程序看的，写得简洁准确；图注是给看得到图的人补充信息的，可以带上场景、用法、注意事项，语气更像一句人话。写成同一句话不会被惩罚，但等于把一处高可见位置白白丢掉了，而且屏幕阅读器用户会连着听到两遍同样的内容。分工写，两处加起来提供的信息量能翻倍。 ## 纯装饰性的图片，alt该怎么处理？ 留空，也就是写成一对空引号，不要删掉这个属性。空的alt是一个明确信号，告诉屏幕阅读器跳过这张图；完全没有alt属性会让阅读器去念文件名，那就变成了念一串拉丁字母加数字，体验反而更差。这条规则跟语种无关，但在非拉丁市场后果更严重：文件名是拉丁转写，念出来对本地用户是纯噪音。分割线、背景纹理、纯粹撑版式的图都属于这一类，商品图和信息图不属于。 ## 图片被搜到了，落地页却不对，怎么排？ 先确认这张图被引用在几个页面上。同一张图出现在类目页、详情页、专题页时，引擎要挑一个当落地页，挑的依据是哪个页面跟这张图的关联最强，而关联强度主要看图注和周边正文。想让它落到详情页，就在详情页给这张图配完整的图注和上下文，在类目页那边尽量少给它文字。如果落地页错在语言版本上，那多半是结构化数据里的说明类字段整块复制了另一个语种的文案，逐语种抓源码核对一遍就能查出来。 ## 权威参考资料 ## 小语种页面的正文越本地化越好，结构化数据里却要反着写回国际格式 - URL：https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html - 分类：小语种SEO - 发布：2020-10-14 | 更新：2026-07-26 - 摘要：inLanguage不是hreflang的副本，价格和日期在标记里必须去本地化。讲清小语种站的Schema字段该怎么分成三类处理、品牌名的本地写法与拉丁别名怎么配，以及哪些字段写错了没人看得见。 - 关键词：结构化数据,技术SEO,多语言SEO,小语种SEO > **TLDR**：摘要：页面上的价格、日期、地址要按当地习惯写，越像本地站越好；而结构化数据里的同一批值必须反过来写成机器格式，价格用小数点、日期用国际标准写法、货币用三字母代码。两个方向正好相反，混成一件事做，要么用户看到一串机器格式，要么标记整批解析失败。另一半麻烦出在语言字段上：inLanguage不是hreflang的副本，把带地区的语言标签整块抄过去，等于声明同一份德语内容是两种不同的语言。 > 摘要：页面上的价格、日期、地址要按当地习惯写，越像本地站越好；而结构化数据里的同一批值必须反过来写成机器格式，价格用小数点、日期用国际标准写法、货币用三字母代码。两个方向正好相反，混成一件事做，要么用户看到一串机器格式，要么标记整批解析失败。另一半麻烦出在语言字段上：inLanguage不是hreflang的副本，把带地区的语言标签整块抄过去，等于声明同一份德语内容是两种不同的语言。 ## 结构化数据为什么是全站唯一写错了没人会投诉的地方？ ## 正文错了有人说，标记错了只有机器知道 小语种站上线之后，正文里的错误迟早会被人发现。用户会在客服对话里提一句，母语审校会圈出来，同行也可能顺手指出。 结构化数据没有这条反馈路径。它藏在页面源码里，普通用户一辈子不会看一眼。 把语言标签写成英语、把价格写成本地格式、把国名写成本地文字，页面看上去完全正常。 唯一知道出错的是搜索引擎，而它的反馈方式是不给你富媒体结果，不会告诉你为什么。 于是这类错误可以在站上待很久，久到没人记得它是什么时候写进去的。 发现它们的契机往往是某次改版排查，或者某天突然想起来对比一下各语种的展现差异。 这个反馈缺失有个更麻烦的后果：它让结构化数据成了整个多语言站里最容易被复制粘贴的部分。没有人会因为它写错而被追责，也就没有人有动力去逐个语种核对，模板一复制，错误就同步到了所有语种。 这条差别还带来一个管理上的后果：结构化数据的质量完全依赖流程，不依赖人的责任心。正文写得好不好，写的人自己心里有数；标记写得对不对，写的人从页面上看不出任何反馈。没有反馈的环节只能靠断言和检查来兜，指望自觉是没用的。 ## 小语种站的标记通常是从英文站复制来的 多语言站的常见搭建顺序是先做英文站，跑通之后再复制出各语种站点。 结构化数据作为模板的一部分被整块带过去，这一步几乎没人会停下来检查。 带过去的东西里，有些字段是模板变量会自动替换，有些是写死的常量。 写死的那些就是问题所在：语言标签、国家代码、货币代码，全是英文站的值。 更隐蔽的是那些看起来被替换了的字段，比如价格。价格确实换成了当地数字，但格式跟着前端的本地化函数一起变了。 结果是标记里躺着一个当地格式的价格字符串，机器读不出数值。 要判断自家站有没有这个问题，最快的办法是随便打开一个小语种页面看源码里的标记块，逐个字段问一句：这个值是英文站带过来的，还是为这个语种单独产生的。答不上来的字段就是嫌疑对象，通常一看一个准。 ## 安全座椅站那次：富媒体结果整批消失 保哥去年经手过一个卖儿童安全座椅的独立站，欧洲三个语种，德语、波兰语、俄语。 产品页的富媒体结果在德语市场展现得好好的，另外两个语种一直没出来。 最初怀疑是页面质量问题，后来把三个语种的标记块导出来并排比对，问题一眼就看见了。 波兰语和俄语页面的价格字段写着当地格式的数字，千分位用空格分隔，小数点用逗号。 德语页面之所以正常，纯属运气：那批商品的价格都是整数，没有小数部分，所以没触发解析失败。 改成纯数字加小数点之后，两个语种的富媒体结果在下一轮抓取里就回来了。 这件事最值得记住的一点是排查顺序。当时先花了两周去查内容质量、页面速度、内链结构，全都没问题；标记块是最后才看的，因为它在德语站上工作正常，潜意识里就把它排除了。同一份模板在不同语种下表现不同的时候，第一个该怀疑的就是那些跟语言相关的值，而不是最后一个。 ## inLanguage和hreflang到底是不是一回事？ ## 一个是页面间关系，一个是内容属性 这两个东西经常被当成同一件事的两种写法，其实它们回答的是不同的问题。 hreflang回答的是：这个页面还有哪些其他语言或者地区的版本，它们分别在哪里。 它描述的是一组页面之间的关系，天然需要地区信息，因为同一门语言可能面向不同市场做了不同的版本。 inLanguage这个属性 (https://schema.org/inLanguage)回答的是另一个问题：这一份内容本身，是用什么语言写的。 它描述的是内容的固有属性，跟其他页面存不存在没有关系。 一份德语内容就是德语，不管它是给德国用户看的还是给奥地利用户看的。 把两者的职责分清楚之后，很多写法上的困惑会自己消失。hreflang那一套落地规则 (https://zhangwenbao.com/international-seo-hreflang-complete-guide.html)管的是站点架构层的事，而结构化数据这一层根本不参与架构，它只是在描述这个页面上有什么。两者的值恰好长得像，但作用域完全不重叠。 ## 把地区子标签写进inLanguage会声明出什么 最常见的做法是把hreflang的值直接抄进inLanguage，看起来省事又统一。 抄过去之后，德国站的页面写着一个带德国地区码的标签，奥地利站的页面写着带奥地利地区码的标签。 从机器的角度读这两份标记，得到的信息是：这是两种不同的内容语言。 而实际上它们是同一门语言的同一份内容，只是面向不同市场。 这个声明本身不会立刻造成可见的损失，但它把一个本可以合并的信号拆散了。 在实体关联和跨语言对齐这类处理里，语言维度被拆得越碎，越不利于系统把它们认成一回事。 这跟跨语言实体对齐里那些对不上的根因 (https://zhangwenbao.com/multilingual-entity-seo-cross-lingual-reconciliation.html)是同一类问题：每一层各自写了一点点不一致的信息，单独看每层都说得过去，叠起来就让系统无法确认这几个页面讲的是同一个东西。 这个错误的传播路径也很典型：某些建站插件的默认实现就是把hreflang的值直接复用，于是装了这类插件的站全都带上了地区码。抄来抄去之后它甚至显得像是行业惯例，很少有人回头看属性定义里到底怎么说的。遇到看起来大家都这么写的做法，回原始定义核一遍通常是值得的。 ## 什么时候inLanguage该带地区 也不是一概不能带，有两种情况带地区子标签是合理的。 第一种是这份内容确实针对某个地区做了实质性的语言调整，用词、拼写、术语都不同。 典型的例子是巴西葡萄牙语和欧洲葡萄牙语，两者的差异大到读者能立刻分辨。 第二种是这份内容里包含只在某个地区有效的信息，比如当地的法规编号或者服务范围。 除此之外，仅仅因为面向不同市场投放就带上地区码，属于过度声明。 判断方法很朴素：把两个版本的正文并排放，如果一个母语者看不出它们的语言差异，就别带地区。 这条判断标准跟两个葡语市场到底算不算两套内容 (https://zhangwenbao.com/portuguese-seo-brazil-portugal-two-markets-keyword.html)那个问题用的是同一把尺子。语言层面上真的分叉了，标记里就该体现出来；只是投放对象不同，标记里就不该体现。 还有一种情况介于两者之间：语言基本相同，但价格、法规、配送信息按地区不同。这时候差异全部落在格式字段和事实内容上，不在语言上，所以语言标签仍然不该带地区。差异该体现在别的字段里，比如适用区域、配送范围、价格与货币，这些字段本来就是为区域差异准备的。 ## 两者不一致时哪个说了算 如果hreflang写的是带地区的标签，inLanguage写的是纯语言码，算不算冲突？ 不算。两者描述的维度不同，纯语言码是带地区标签的语言部分，逻辑上完全一致。 真正的冲突是另一种：hreflang说这个页面是波兰语，inLanguage说是英语。 这种情况多半出现在模板变量没配对上的站点上，而且往往整个语种目录都错。 处理方式没有讨论余地，改到一致为止，以页面实际内容的语言为准。 加一条自动检查最省心：抓取每个页面，对比这两处的语言部分，不一致的报警。 这条检查还能顺手抓出另一类问题：页面上的语言属性、hreflang、inLanguage三处两两比对，往往能发现某个语种目录的模板配置从来就没配对过。三处一致才算干净，其中任何一处跟另外两处不同，都值得停下来查一遍模板变量的取值来源。 对比项 | hreflang | inLanguage | 回答什么问题 | 还有哪些语言地区版本，在哪里 | 这份内容是什么语言 | 作用域 | 一组页面之间的关系 | 单个页面的内容属性 | 要不要地区子标签 | 需要，用来区分市场 | 默认不要，语言真分叉才带 | 写错的表现 | 版本互指错乱、展现给错市场 | 无可见表现，只影响机器理解 | ## 小语种站的Schema字段要分成三类处理 ## 语言字段：说明内容是什么语言 第一类字段管的是语言本身，数量不多但最容易被忽略。 inLanguage是最常用的一个，文章、视频、商品描述都可以带。 availableLanguage这个属性 (https://schema.org/availableLanguage)用在客服和联系方式上，说明你的支持团队能用哪几种语言接待。 做小语种市场的时候这个字段有实际价值：用户想知道打电话过去有没有人说他的语言。 还有一个描述人物语言能力的属性，用在作者信息上，多语言内容站可以考虑。 这一类字段的值统一用标准语言标签，别用语言的名字，更别用中文或者本地文字写的语言名。 值的写法有个硬要求：必须是标准语言标签规范 (https://www.rfc-editor.org/rfc/rfc5646)定义的那种格式，也就是两三个字母的语言码，需要时后面接书写系统和地区子标签。写成德语、Deutsch或者German这类人类可读的名字都是无效的，解析方拿到之后只能丢弃。 ## 格式字段：机器要读的数值 第二类字段的共同点是它们的值是给机器算的，不是给人看的。 价格、评分、库存数量、日期、时长、电话号码，全在这一类。 这些字段有各自的格式规范，规范里定义的格式跟任何一门语言的书写习惯都不一样。 换句话说，它们不需要本地化，也不允许本地化。 页面上呈现给用户的那一份要本地化，标记里的这一份保持机器格式，两份值同源但形态不同。 实现上最干净的做法是从数据源直接取原始值写进标记，不要走前端的格式化函数。 这条实现建议值得单独强调，因为绝大多数格式错误都是同一个原因造成的：模板里用了同一个变量渲染页面和标记，而那个变量早就被本地化过一遍了。把两条路径分开，一条走格式化，一条走原始值，这类错误一次性根治。 判断一个字段属不属于这一类有个简单办法：想象把这个值交给一段程序去做计算或者比较，如果这件事说得通，它就是格式字段。价格要比大小，日期要排先后，评分要求平均，电话要拨号，全都说得通；而品牌名、描述、分类名这些拿去计算毫无意义，自然就不在这一类里。 ## 书写系统敏感字段：名字怎么写 第三类是名称类字段，它们既不是纯语言标签也不是纯数值，处理方式最微妙。 品牌名、产品名、机构名、人名，在非拉丁字母市场都面临一个选择：用本地文字写还是用拉丁字母写。至于这些名字进了正文之后还会跟着语法变形，那是锚文本层面的另一个问题 (https://zhangwenbao.com/minor-language-internal-link-anchor-inflection-variants.html)，标记这一层不受它影响。 这一类字段的答案不是二选一，而是两个都要，只是放在不同的属性上。 主名称字段填当地用户实际看到、实际会搜的那个写法。 alternateName这个属性 (https://schema.org/alternateName)就是为这种情况准备的，把另一种写法放进去。 这样一来两种写法都进了标记，而且主次分明，不必在两者之间做取舍。 字段类别 | 典型字段 | 该本地化吗 | 写错的后果 | 语言字段 | inLanguage、availableLanguage | 用标准语言标签，不写语言名 | 信号被拆散，无可见表现 | 格式字段 | 价格、日期、评分、电话 | 禁止本地化，一律机器格式 | 解析失败，富媒体结果消失 | 书写系统字段 | name、alternateName | 主名本地写法，别名补拉丁 | 实体对不上，品牌信号分散 | ## 价格和日期在标记里为什么必须去本地化？ ## 千分位和小数点写反了会发生什么 价格字段的规范要求很直接：纯数字，小数点用点号，不带千分位分隔符，不带货币符号。 德语、波兰语、俄语的习惯写法正好相反：千分位用点号或空格，小数点用逗号。 把当地写法直接塞进价格字段，解析器读到一个逗号，多半会在那里截断。 截断的结果是一个数量级完全不对的数字，或者干脆解析失败整个标记块作废。 更坏的情况是解析成功但值错了，比如把一千两百三十四点五六读成一点二三。 这种错误比解析失败更难发现，因为标记语法上完全合法，校验工具不会报错。 各语言的数字书写习惯差异有多大，区域数据规范里的数字格式部分 (https://www.unicode.org/reports/tr35/tr35-numbers.html)列得很清楚，同一个数值在不同地区能有五六种合法写法。正因为差异这么大，规范才干脆规定标记里只用一种写法，避免解析方去猜。 这类错误还有个特别不友好的地方：它跟商品价格本身有关，也就是说同一个站上有的商品会触发、有的不会。整数价格的商品一切正常，带小数的商品解析失败，于是你在后台看到的现象是富媒体结果时有时无，很容易被误判成抓取频率问题或者页面质量波动。 ## 货币代码用ISO三字母不用货币符号 货币这一项单独说，因为它错得特别频繁。 页面上显示的是货币符号，标记里要求的是三个字母的货币代码 (https://schema.org/priceCurrency)。 符号和代码不是一一对应的关系，好几个市场共用同一个符号，代码却不同。 还有一类符号在不同国家指向完全不同的货币，只写符号机器分不清是哪一种。 所以这个字段没有本地化的空间，只有一种正确写法。 顺便说一句，页面上显示符号还是代码是另一个问题，那个归本地惯例管。 ## 日期一律用国际标准写法，别用本地格式 日期字段的规范同样明确：年月日的顺序，用连字符分隔，需要时间的话按标准格式接上时区。 页面上给用户看的日期该怎么写就怎么写，日月顺序按当地习惯来。 标记里的那一份必须是互联网时间戳标准 (https://www.rfc-editor.org/rfc/rfc3339)定义的格式，没有例外。 发布时间、修改时间、活动时间、优惠有效期，全都适用。 有效期这类字段写错的代价最直接：促销标记可能因为时间解析错误而完全不展现。 时区部分容易被漏掉，尤其是跨市场的促销活动，没有时区的时间戳会被按默认时区解释。 做多市场促销的时候还有个连带的坑：促销的开始和结束时间在标记里必须写成带时区的绝对时间，而页面上给用户看的应该是他所在时区的本地时间。两者又是一次分离，跟价格那次一模一样，只是很多团队做完价格就以为万事大吉，忘了时间字段是同一类问题。 还有一类日期字段容易被漏掉：文章的发布与修改时间。这两个字段在内容站上直接关系到时效性判断，而它们通常由内容管理系统自动输出，格式取决于主题模板怎么写。换主题的时候是重灾区，新主题按自己的习惯输出了本地化日期，标记里的时间就全废了。 ## 电话号码用国际格式 电话字段的要求是带国家码的国际格式，前面加加号，中间不加括号和本地前缀。 各国的本地写法千差万别，有的习惯加括号，有的用点分隔，有的带一个拨号前缀。 这些写法在本地打得通，但机器无法判断这是哪个国家的号码。 页面上依然可以按当地习惯排版，标记里换成国际格式。 做本地商户标记的时候这一项直接影响能不能被正确关联到地图和拨号功能。 检查方法也简单：所有电话字段的值必须以加号开头，不满足的一律标出来。 ## 地址字段在小语种市场怎么填才不出错？ ## 国家字段要填代码不是国名 地址结构里的国家字段，规范建议填两个字母的国家代码。 常见错误是填了国名，而且是用当地语言写的国名。 德语站填德国的德语写法，俄语站填俄语写法，同一个国家出现了几种值。 机器没法把这几个字符串认成同一个国家，地理关联就断了。 改成两个字母的代码，所有语种共用同一个值，问题消失。 这是三类字段里最容易改的一处，全站替换一次就完事。 顺带提醒一句，地区和城市字段没有这样的标准代码可用，只能填名字。这时候用当地语言写是合理的，因为它本来就是给人看的文本。国家字段有代码可用是个例外，别把这个例外推广到整个地址结构上。 这个字段还有个变体错误：填了国家代码，但填的是三个字母的那一套。地址结构里要的是两个字母的那套，三字母代码属于另一个标准，用在这里同样无效。两套代码长得像、名字也像，混用相当常见，写规范表的时候要把位数明确写出来。 ## 街道与邮编的顺序归页面管，不归标记管 地址的书写顺序在各国差别很大，邮编在前在后、门牌在前在后都不一样。 这件事完全归页面呈现管，标记里不存在顺序问题。 因为地址在标记里是结构化的，每一部分放进各自的字段，顺序由消费方决定。 所以不要把整个地址塞进一个字段里了事，那样接收方只能拿到一串没法拆的文本。 逐字段填写虽然啰嗦，但它让地址在任何市场都能被正确重组。 这一点跟价格日期的思路一致：把值和呈现分开，值保持结构，呈现随地区变。 逐字段填还有个附带收益：地址一旦结构化，就能被复用到别的地方去，比如地图标注、配送范围计算、门店列表。塞成一整串文本的地址，每次要用都得先拆一遍，而拆的规则在每个国家都不同，最后不得不为每个市场写一套拆分逻辑。 ## 一个地址两种书写系统怎么办 在西里尔字母市场，同一个地址常常存在两种写法：本地文字的和拉丁转写的。 标记里该填哪一种？答案是填当地用户和当地邮政实际使用的那一种，也就是本地文字。 拉丁转写的作用是给国际用户看，属于页面呈现层的事，不必进标记。 如果确实需要两套，可以在页面上做切换，标记保持单一权威版本。 这跟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/multilingual-bert-seventy-languages-minor-language-seo-watershed.html)，但它补的是语义那一层，补不了你没声明的对应关系，猜错的后果就是品牌信号被分成两份。 被分成两份的表现是：搜其中一种写法能出品牌信息面板，搜另一种什么都没有。 这类问题在实体消歧的信号管控 (https://zhangwenbao.com/entity-disambiguation-mechanism-seo-signal-control.html)里很典型，而标记是成本最低的一处发力点。 这条证据的可信度还跟它出现在哪里有关。放在自己官网的标记里，是品牌方的第一人称声明，分量高于任何第三方页面上的对应关系。所以这件事别指望靠外部提及慢慢积累，自己标一次的效果比等半年更直接，成本也只是改一个字段。 ## 三种书写系统并存的市场怎么排 有些市场的情况更复杂，同一门语言存在两套官方字母，用户两套都在用。 塞尔维亚语是最典型的例子，西里尔和拉丁两套字母并行，同一个词有两种合法写法。 这时候主名称填哪一套，取决于目标用户群体的实际使用偏好，通常拉丁那一套在电商场景里更常见。 另一套放进别名，再把品牌的原文名也放进去，一个字段可以放多个值。 这类双字母市场的处理逻辑 (https://zhangwenbao.com/bulgarian-serbian-seo-cyrillic-latin-dual-script.html)在标记层比在内容层简单得多，因为标记允许并列，内容必须选一个。 别名字段不要滥用，只放真实存在的其他写法，别把关键词变体往里塞。 要避免的一个做法是主名称和别名两边都填拉丁原名，只是大小写或者空格不同。别名字段的意义在于提供一个真正不同的写法，让系统有机会把两个字符串关联起来；填两个几乎相同的值，等于什么信号都没提供，还让标记看起来像是被应付了一下。 ## 语言标签里的书写系统子标签什么时候必须写？ ## 同一门语言两套字母的市场 标准语言标签允许在语言码后面加一个书写系统子标签，四个字母那种。 绝大多数语言用不上它，因为一门语言通常只有一套通行的书写系统。 需要它的场景很具体：同一门语言确实有两套并行的书写系统，而且都在正式使用。 塞尔维亚语是标准案例，两套字母各有对应的子标签写法。 中文的简繁也属于这一类，这也是站内做简繁两套内容时会遇到的同一个问题。 除了这几个明确的场景，其他语言写上书写系统子标签属于多余，规范本身也建议省略。 省略这条规则的依据是标签规范里的一个原则：能从语言码推断出来的信息就不要重复写。既然某门语言只有一套通行文字，写出来不增加任何信息，反而让标签变得不标准、更难跟其他系统的值对齐。 要注意的是，这个子标签描述的是内容实际用了哪套文字，不是网站支持哪几套。如果你的站为两套字母各做了一份内容，那是两个页面各自声明各自的文字；如果只做了一份，就只声明那一份用的文字，别把支持能力写进内容属性里。 ## 书写系统子标签跟地区子标签不是一回事 这两个子标签经常被混淆，它们在标签里的位置和含义都不同。 书写系统子标签说的是用什么文字写，地区子标签说的是面向哪个地区。 一门语言可以在同一个地区有两套文字，也可以在两个地区用同一套文字。 所以两者是独立的维度，需要的时候可以同时出现在一个标签里。 顺序是固定的：语言码在前，书写系统在中间，地区在后。 写反了整个标签就不合法，解析方会当成未知标签处理。 实际维护里，这三段的取值都可以在语言子标签注册表 (https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry)里查到。这份注册表是所有合法子标签的唯一来源，拿不准某个写法存不存在的时候查它，比在网上搜到的示例可靠得多。 实际会同时用到两个子标签的场景并不多，最典型的是同一门语言在两个国家分别用两套文字的情况。绝大多数站点只需要语言码，少数需要语言码加书写系统，再少数才需要三段齐全。写标签的原则始终是能省则省，多写的每一段都是一次可能出错的机会。 ## 写错了会怎样，不写会怎样 先说不写：在只有一套文字的语言里不写，完全正确，没有任何损失。 在两套文字并行的语言里不写，损失是系统无法从标签判断这份内容用的是哪套字母。 它仍然可以从内容本身推断出来，所以损失有限，但你放弃了一次明确声明的机会。 再说写错：把地区子标签写在书写系统的位置上，标签直接不合法。 用了注册表里不存在的四字母组合，同样不合法。 两种情况的后果一样，解析方丢弃这个值，等于什么都没写。 两相比较，不写的风险远小于写错的风险：不写只是少了一个明确信号，写错则是整个值被丢弃，连语言码那部分也一起没了。所以拿不准的时候默认少写，等确认了注册表里的正确写法再补上，这个顺序在标签这件事上几乎总是对的。 ## 多语言站的Schema结构可以共用，值必须分开 ## 结构共用，值分开 做多语言站的时候，最省事也最正确的思路是：标记的结构在所有语种之间共用一套。 用哪些类型、有哪些字段、字段之间怎么嵌套，这些跟语言无关。 需要按语种分开的只有值，而值里面又只有一部分需要真正分开。 语言标签必须分开，名称类字段需要分开，格式字段其实不需要分开。 价格数值在所有语种下都是同一个格式，货币代码按市场定，跟语言无关。 把这层关系理清之后，模板的设计就很清楚了：一套结构，若干个按语种取值的变量。 ## 模板化输出的三个必须参数化的字段 如果只能改三个字段，优先把这三个做成参数。 第一个是语言标签，它必须跟当前页面的实际语言一致，绝不能写死。 第二个是名称类字段，非拉丁市场的主名称与别名要按语种取值。 第三个是货币代码，多市场站点上它跟着市场走，不能沿用英文站的值。 这三个改完，绝大多数跨语种的标记问题就解决了七八成。 剩下的格式字段问题，靠前面说的从数据源取原始值这条实现原则来兜。 这三个字段有个共同点：它们都是那种写死之后不会报错、也不会有任何可见异常的值。模板里的其他常量写错了，页面上多半会露馅，这三个不会。所以它们既是最容易出错的，也是最不容易被发现的，优先级自然排在最前面。 补充一句，参数化不等于自动化。语言标签可以从页面配置自动推导，货币代码可以从市场配置推导，但名称类字段推导不出来，它必须由懂当地市场的人填一次。把它做成配置项交给本地化团队维护，比让开发去猜靠谱得多。 ## 一个语种一份还是一个模板多份 实现方式上有两条路，各有各的适用场景。 一条是每个语种维护一份独立的标记模板，好处是灵活，坏处是改一处要改好几遍。 另一条是共用一个模板，所有语言相关的值走变量，好处是一致性有保障。 语种数量少于五个的时候两种都行，超过五个之后共用模板的优势会迅速拉大。 判断标准是：你有没有信心保证十份模板在下一次改版之后仍然完全一致。 多数团队没有这个信心，所以默认选共用模板那条路。 ## 标记写完怎么验，验哪几项？ ## 语法层的校验只能发现一半问题 写完之后第一步当然是跑校验工具，看语法有没有错、必填字段有没有缺。 这一步能发现的问题是：括号没闭合、字段名拼错、类型用错、必填项缺失。 发现不了的是：语言标签写的是英语而内容是波兰语，价格数值被本地化过，国家字段填了国名。 这些在语法上全部合法，工具挑不出毛病。 换句话说，校验工具管的是格式对不对，管不了内容对不对。 而小语种站上出问题的恰恰全是内容对不对那一类。 官方的测试工具这两年也在换代，早年那个通用的结构化数据测试工具已经宣布要退场，取而代之的是按富媒体类型来验的新工具。工具换了，能力边界没变：它们查的仍然是语法和资格，不是值的正确性。 还有一类问题两边都查不出来：字段填了，值也合法，但值是错的。比如库存状态永远写着有货，或者评分数量是个写死的常量。这类值在语法上无懈可击，只有拿它跟真实业务数据比对才能发现，属于第三层检查，需要接进数据源才做得了。 ## 语言与格式这一层要自己写检查 既然工具管不了，就得自己补一套检查，而且这套检查很容易写。 抓取页面，把标记块解析出来，逐条断言。 语言标签的语言部分必须等于该页面所属语种，不等就报警。 价格字段必须匹配纯数字加可选小数点的模式，出现逗号或空格就报警。 日期字段必须匹配标准时间格式，国家字段必须是两个大写字母。 电话字段必须以加号开头，货币代码必须是三个大写字母。 这套断言加起来不到二十行，一次写好可以用很多年，而且它抓到的问题正好是校验工具漏掉的那一半。JSON-LD这种格式 (https://json-ld.org/)本身就是结构化的，解析出来是标准的数据对象，写断言比写正则容易得多。 这套断言最好跟内容发布流程绑在一起，而不是当成独立的巡检任务。绑进流程的检查会在问题产生的那一刻拦下来，独立巡检则是在问题存在了一段时间之后才发现，而这段时间里搜索引擎已经按错误的标记抓过好几轮了。 ## 逐字段过一遍的清单 上线前的人工检查也需要一张清单，按前面的三分法排就行。 语言类：语言标签跟内容语言一致，客服语言字段填了标准标签而不是语言名。 格式类：价格纯数字，货币三字母代码，日期标准格式带时区，电话加号开头。 名称类：主名称是当地实际写法，别名补上另一种书写系统。 地址类：国家字段填代码，其余字段按结构逐项填，不要塞成一整串。 最后再看一眼：这些值是这个语种自己产生的，还是从英文站带过来的。名称类字段的取值对不对，最终还得靠母语审校那一道验收 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)确认，脚本只能查形态查不了地道不地道。 这张清单最好按语种各走一遍，不要抽一个语种代表全部。跨语种的标记问题有个特征：它往往只出现在部分语种上，因为不同语种的模板是在不同时间、由不同的人复制出去的。抽查一个语种全绿，另外几个语种可能各有各的错法。 检查项 | 判据 | 校验工具查得出吗 | 语言标签 | 语言部分等于页面语种 | 查不出 | 价格数值 | 纯数字，仅允许小数点 | 查不出 | 货币代码 | 三个大写字母 | 部分能查 | 日期时间 | 标准格式，带时区 | 部分能查 | 国家字段 | 两个大写字母代码 | 查不出 | 主名称与别名 | 本地写法在主名，另一种在别名 | 查不出 | ## 上线后的抽查怎么做 上线之后还要抽查，因为标记有一个特点：它会在你不知道的时候被改掉。 改动来源包括模板更新、插件升级、前端重构，任何一次都可能覆盖掉之前的修正。 抽查的频率按改版节奏定，稳定期一个季度一次，改版期每次上线后都跑。 抽查的对象不必是全站，每个语种抽几个代表性页面就够，问题通常是全站性的。 把断言脚本挂进定期任务，出问题自动报警，比人工抽查可靠。 报警要带上是哪个语种哪个字段，否则收到通知还得再排查一遍。 抽查还有个容易被忘掉的对象：那些不常更新的页面，比如关于我们、联系方式、配送政策。这些页面上的标记往往是最早写的，也是改版时最容易被漏掉的，而它们承载的恰恰是客服语言、地址、电话这几个跟本地化关系最紧的字段。 ## 这套做法怎么落进现有的开发流程？ ## 谁负责：前端、内容还是检索这一侧 职责不清是这类问题反复出现的根源，所以先把分工定下来。 前端负责实现：把值从数据源取出来写进标记，保证不走本地化函数。 内容或本地化团队负责名称类字段的取值，因为只有他们知道当地实际写法。 检索这一侧负责定义规则、写断言脚本、验收。 三方各管一段，中间的交接物是一份字段规范表，写清每个字段的格式要求。 规范表要具体到能直接照着写代码，不要写成原则性的描述。 这份表跟结构化数据本身的设计 (https://zhangwenbao.com/schema-org-advanced-graph-entity-knowledge-panel-mechanism.html)是两份文档，前者管值怎么填，后者管结构怎么搭，别混在一起写。 分工里最容易漏掉的一环是谁来复核。三方各管一段之后，需要有一个人在上线前把三段拼起来看一遍，确认字段规范表上的每一条都落地了。这个角色通常落在检索这一侧，因为只有这边同时关心值的正确性和它在搜索里的后果。 ## 什么时候会悄悄回退 修好的标记会回退，这几乎是必然的，值得提前防。 最常见的回退场景是换主题或者换插件，新模板带着一套自己的默认标记覆盖上来。 第二常见的是加了新语种，新语种的模板是从某个老语种复制的，把老问题一起复制了。 第三是前端做本地化改造时，顺手把标记里的值也接进了格式化函数。 三种场景的共同点是改动方并不知道这些字段有特殊要求。 防回退的办法只有一个：把断言脚本挂进上线流程，让它自动拦。 ## 六步落地路线 整篇压成六步，照着排期就行。 第一步，导出各语种页面的标记块并排比对，找出所有从英文站带过来的写死值。 第二步，把语言标签改对，去掉不必要的地区子标签，跟页面实际语言对齐。 第三步，把价格、日期、电话、货币这几个格式字段改成机器格式，实现上走原始值。 第四步，地址结构逐字段填，国家字段换成两字母代码。 第五步，非拉丁市场配好主名称与别名，两种书写系统都进标记。 第六步，写二十行断言脚本挂进上线流程，季度抽查一次。 六步里第三步的收益最直接，因为它修的是真正会导致富媒体结果消失的错误；第六步的收益最长久，因为它防的是同一批错误再回来。前面五步是一次性工程，第六步是长期保险，两者缺一不可——只做前五步的团队，通常在下一次换主题之后就回到了起点。 ## 常见问题解答 ## inLanguage到底该不该带地区子标签？ 默认不带，只写语言码。带地区的前提是这份内容在语言层面真的做了地区化调整，用词、拼写、术语都跟另一个地区的版本不同，比如巴西葡萄牙语和欧洲葡萄牙语那种程度的差异。仅仅因为投放给不同市场就带地区码属于过度声明，它会把本可以合并的语言信号拆成好几份。一个朴素的判断法：把两个版本的正文并排给母语者看，他看不出语言差异就别带。 ## 价格字段能不能带货币符号？ 不能，价格字段只接受纯数值，货币信息放在专门的货币字段里，用三个字母的国际代码。这是最常见的错误之一，因为页面上显示的价格天然带着符号，模板直接取用就出问题了。更隐蔽的版本是数值本身被本地化过，千分位和小数点按当地习惯写，解析器读到逗号会截断或者失败。根治办法是标记里的值直接从数据源取原始数字，绕开前端的格式化函数。 ## 品牌名在西里尔市场，主名称该填哪一种写法？ 填当地用户实际会搜、实际会看到的那一种。如果品牌在当地已经有被接受的音译写法，就填音译；如果当地用户习惯直接打拉丁原名，就填原名。判断依据是搜索数据和用户输入习惯，不是内部品牌规范。另一种写法放进别名字段，两者都进标记，这个组合对实体识别最有利，能避免同一个品牌被拆成两个不相关的实体。 ## 校验工具报告全绿，是不是就没问题了？ 不是。校验工具查的是语法和必填项，也就是格式对不对；它查不出内容对不对。语言标签写成英语而内容是波兰语、价格被本地化过、国家字段填了本地语言的国名，这些在语法上全部合法，工具一个都挑不出来。而小语种站上出问题的几乎全是这一类。补救办法是自己写一套断言，逐字段检查值的形态，二十行代码的事，抓到的正好是工具漏掉的那一半。 ## 多语言站是每个语种一份标记模板，还是共用一份？ 语种少于五个的时候两种都行，超过五个就该共用一份模板，所有语言相关的值走变量。判断标准很实际：你有没有信心保证十份独立模板在下一次改版之后仍然完全一致。多数团队没有，所以共用模板加参数化是更安全的默认选择。必须参数化的字段优先级排序是语言标签、名称类字段、货币代码，这三个改完能解决大部分跨语种的标记问题。 ## 地址里的城市和街道要不要也换成代码？ 不用，也没有通用代码可换。只有国家字段有两个字母的标准代码，那是个例外。城市、地区、街道这些字段本来就是给人看的文本，用当地语言写完全正确，也应该这么写。要注意的只有一点：别把整个地址塞进一个字段里，逐字段填写虽然啰嗦，但它让地址能在任何市场被正确重组，塞成一整串的话接收方只能拿到一段没法拆的文本。 ## 标记修好之后会不会又变回去？ 大概率会，而且回退的场景相当固定：换主题或换插件时新模板带着默认标记覆盖上来；新增语种时从某个老语种复制模板，把老问题一起复制过去；前端做本地化改造时顺手把标记里的值也接进了格式化函数。三种场景的共同点是改动的人并不知道这些字段有特殊要求。唯一有效的防线是把断言脚本挂进上线流程自动拦截，靠文档和口头交代拦不住。 ## 权威参考资料 ## 语言选择器里写Deutsch还是German，179门语言里有136门这两个词毫无关系 - URL：https://zhangwenbao.com/minor-language-endonym-language-picker-sort.html - 分类：小语种SEO - 发布：2020-06-30 | 更新：2020-06-30 - 摘要：179门语言自称与英文名逐条对照：四分之三连词根都不沾边，28.5%的自称不是拉丁字母，按代码排序跟按英文名排序只差5位。 - 关键词：多语言SEO,小语种SEO,网站本地化,建站选型 > **TLDR**：摘要：把179门语言的自称和英文名逐条摆在一起对了一遍。四分之三的语言，这两个名字连词根都不沾边，德语自己写作Deutsch，芬兰语写作suomi。近三成的自称根本不是拉丁字母，在一份按字母排的列表里没有位置。更要命的是排序键：按语言代码排跟按英文名排只差5位，跟按自称排差28位——按代码排序不是中立的技术选择，它就是按英语排序。 > 摘要：把179门语言的自称和英文名逐条摆在一起对了一遍。四分之三的语言，这两个名字连词根都不沾边，德语自己写作Deutsch，芬兰语写作suomi。近三成的自称根本不是拉丁字母，在一份按字母排的列表里没有位置。更要命的是排序键：按语言代码排跟按英文名排只差5位，跟按自称排差28位——按代码排序不是中立的技术选择，它就是按英语排序。 上一篇算完了一件事：你的目标语言在不在设备和浏览器的清单里。这一篇往前挪一格，问一个更早发生的问题。 这一格的问题比清单本身更早发生，也更容易被跳过——毕竟“把语言名写上去”看起来不像一个需要做决定的动作。 假设它在清单里。用户打开那个列表，往下翻，翻到第几行会停下来？ 他要找的是自己那门语言的名字。问题在于，那个列表上写的是不是他认得的那个词，以及那个词有没有排在他会去翻的位置。 这两件事互相牵扯：写哪个名字决定了用户认不认得，按什么排决定了他要翻多久。而这两个决定通常由不同的人在不同的时候做出，谁也没跟谁商量。 保哥把这两件事量了一遍。样本取的是安卓系统清单里那181门语言，逐门去公共区域数据仓库里取三样东西：这门语言自己怎么称呼自己、英语里怎么叫它、中文里怎么叫它。有179门三样都拿到了。 数据源用的是公共区域数据仓库2020年4月那一版 (https://cldr.unicode.org/index/downloads/cldr-37)，每门语言在自己的文件里都会写一遍自己叫什么，这就是自称的来源。英文名和中文名分别取自英语和中文那两份文件。三个数都可以按版本号翻回去复核。 结果里有一条数字比预想的高出一倍：179门语言里，自称和英文名连词根都对不上的有136门，占76.0%。 ## 用户在你的语言列表里找得到自己吗？ 先说这件事为什么值得单独量，因为它看起来像个体验细节。 ## 一个德国用户的十秒钟 你的站有一个语言切换器，里面按字母排着二十来个选项。一位德国用户想切成德语。 他不会读整份列表。眼睛会先估一个大致位置，跳过去，再上下微调。这个估位置的动作依赖的是他脑子里那个名字的首字母，而不是别的。 如果列表写的是英文名，他要找的是German，排在G。如果列表写的是自称，他要找的是Deutsch，排在D。这两个位置在一份二十项的列表里差着七八行，在一份一百项的列表里差着几十行。 更麻烦的是第三种做法：列表按英文名排序，但每一行显示自称。于是屏幕上出现的是一串按看不见的规则排列的陌生词，用户既没法按首字母定位，也没法一眼扫到。 这种组合在实际站点上并不罕见，因为排序往往写在后端，显示名往往写在前端模板里，两边各自都很合理，合起来就成了这样。 ## 这不是德语一门语言的问题 德语只是最好举的例子。同一类的还有一长串：芬兰语自称suomi，英文名Finnish；匈牙利语自称magyar，英文名Hungarian；巴斯克语自称euskara，英文名Basque；威尔士语自称Cymraeg，英文名Welsh；爱尔兰语自称Gaeilge，英文名Irish。 反方向也一样成立：一个只知道Finnish的运营，在一份写着自称的列表里找芬兰语，他要找的是suomi，排在s。这不是母语用户专属的麻烦，是两套名字之间的双向不透明。 这一层跟词表那边的分裂是同一个形状。本站在品牌名转写那一篇 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)里写过：一个东西在两个语言环境里有两个名字，而你的页面标题只能写一个。语言本身的名字也逃不掉这条。 这几对里没有一对能靠首字母对上，也没有一对能靠拼写猜出来。 有意思的是这几门语言的国家在国际上一点都不小众。这说明名字对不上跟这门语言的地位没关系，跟它历史上是被谁命名的有关系。 ## 量化之后的比例 把179门语言逐条比对，判据取得很宽松：只要自称和英文名的前三个字母重合，或者其中一个是另一个的前缀，就算共享词干。 之所以放这么宽，是想让结果尽量偏向“其实对得上”这一边。判据越宽，最后算出来的不同比例就越保守，结论也就越站得住。 这么宽松的判据下，共享词干的只有43门，24.0%。剩下的136门，也就是四分之三，两个名字之间没有任何字面线索。 那43门里多数是本来就同源的，比如Nederlands跟荷兰的关系、italiano跟Italian、português跟Portuguese。也就是说对得上的那批，是拉丁语系内部互相借词的结果，不是有人刻意统一过。 ## 这一篇要回答什么 三个问题。一，两个名字差多远，用数字说。二，按什么排序，用户的定位成本最低。三，你的切换器上到底该写哪一个。 这三个问题的共同点是：它们都不需要多语言能力就能自己验，只要一份对照表和一次排序。这跟本站在工具没有数据时自己补那一篇 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)里的思路一致，能自己量的东西就别等别人给。 不回答的是翻译质量、语言检测、以及切换器放在页面哪个位置。最后那件事归站点结构那一层。 ## 自称跟英文名到底差多远？ 光说“不一样”不够用，得知道不一样到什么程度。 下面四个数分别从四个角度量同一件事：字面关系、书写系统、跨语言的名字数量、以及有多少语言压根没有名字。 ## 四分之三没有字面关系 前面那个76.0%是第一个数。它的意思是，一个只认得自称的用户，看到英文名列表时，四分之三的情况下连蒙都蒙不出来。 反过来读更直观：一个只认得英文名的运营，看一份写着自称的列表，也是四分之三的情况下认不出来。这个双向对称性说明问题不在谁的英文好不好。 而且这不是小语种特有的现象。荷兰语自称Nederlands英文名Dutch，希腊语自称 Ελληνικά 英文名Greek，阿尔巴尼亚语自称shqip英文名Albanian——全是有独立国家、有完整教育体系的语言。 这一条对做判断的人挺重要：不要指望“大语言应该没问题”。德语、荷兰语、希腊语、匈牙利语、芬兰语，全在对不上的那一边。 ## 近三成的自称压根不是拉丁字母 第二个数更硬：179门语言里，自称不用拉丁字母写的有51门，占28.5%，横跨27种书写系统。 27种书写系统这个数字本身值得停一下——它意味着这份清单如果原样排出来，会同时出现二十多套互不兼容的字母表，而排序算法只能选一套规则。 西里尔字母12门，阿拉伯字母6门，天城文5门，汉字3门，孟加拉文和藏文各2门，剩下的埃塞俄比亚文、切罗基文、希腊文、古吉拉特文、亚美尼亚文、彝文、格鲁吉亚文、高棉文、卡纳达文、谚文、老挝文、马拉雅拉姆文、缅甸文、奥里亚文、古木基文、僧伽罗文、泰米尔文、泰卢固文、泰文、提非纳文各一门。 这里面几门本站单独写过：希腊语的自称 Ελληνικά 全是希腊字母，而希腊语那一篇 (https://zhangwenbao.com/greek-seo-greeklish-latin-transliteration-coverage.html)里量过，希腊用户自己在搜索框里大量使用拉丁转写。也就是说他打得出Ellinika，你的列表却只写 Ελληνικά，搜索框仍然接不住。 这批语言的名字在一份拉丁字母序的列表里，物理上没有位置——它们要么被一股脑堆在最后，要么按码位排出一个跟任何人的直觉都无关的顺序。 更麻烦的是不同的实现会给出不同的结果：有的按码位排，有的按语言无关的默认排序规则排，有的干脆保持原始顺序。同一份数据，三个前端框架能排出三种顺序。 ## 同一门语言在十份清单里有几个名字 再换个角度。取十种常见的界面语言，看同一门语言在这十份清单里分别叫什么。 这十种界面语言的选择不是随便挑的：它们各自的区域数据文件里都收了五百门以上的语言名，样本足够密，能横着对。 德语这一门：英语叫German，中文叫德语，法语叫allemand，俄语叫 немецкий，阿拉伯语叫 الألمانية，而它自己叫Deutsch。六种叫法，六个不同的词根。 再看一门非拉丁的：格鲁吉亚语自称 ქართული，英语叫Georgian，中文叫格鲁吉亚语，法语叫géorgien，俄语叫 грузинский。前四个还有点词根上的亲缘，俄语那个跟自称和英文名都不搭。 把179门语言全跑一遍，一门语言在十份清单里平均有6.7个互不相同的名字词头。换句话说，语言的名字不是一个标识符，是十份互不兼容的本地知识。 顺带说一句，中文这一份的名字几乎全是从英文名音译过来的，不是从自称音译的。芬兰语不叫“苏欧米语”，匈牙利语不叫“马扎尔语”。中文用户脑子里那张语言地图，底稿是英语的。 这条对做中文站的人有个直接后果：你在中文界面上写“芬兰语”，一个芬兰用户完全认不出来；写suomi，中国运营完全认不出来。中文站的语言列表比英文站更需要两个名字都写。 ## 规范其实说得很清楚 这件事不是没人管过。区域数据标记语言规范里关于显示名的那一部分 (https://www.unicode.org/reports/tr35/tr35-general.html)把语言名定义成一种需要逐语言翻译的数据：每一份区域数据文件里都有一整块，写着这门语言怎么称呼其他所有语言。 给译者的那份翻译指引 (https://cldr.unicode.org/translation/displaynames/languagelocale-names)写得更细，连什么时候该用简称、什么时候必须带限定词、名字该不该首字母大写都规定了。这类规则本身就说明这件事复杂到需要一份规范。 也就是说，语言名从设计上就不是全局唯一的，它是一个二元函数——你用哪门语言问，得到哪个答案。 这跟语言代码的性质正好相反：代码是全局唯一的，名字不是。很多系统把两者当成一回事，用代码当主键、把名字当代码的属性，这个模型从一开始就少了一维。 ## 能拿到名字的语言只有一小撮 还有一个数值得记住。语言子标签的官方注册表 (https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry)里登记了八千多门语言，而公共区域数据仓库能给出英文名的只有620门，7.5%。 差距还不止在数量上。那620门里，越靠后的语言名越可能是英文名的原样照抄，也就是说“有名字”和“有本地化的名字”之间还有一层落差。 能被安卓选成系统语言的181门，占登记语言的2.19%。绝大多数被正式登记过的语言，连一个可以显示在界面上的名字都没有。 这个2.19%可以当成一条粗判据：如果你的目标语言不在那181门里，那它大概率在剩下97.8%里，界面这一层的一切自动机制都指望不上。这跟本站在界面语言清单那一篇 (https://zhangwenbao.com/minor-language-ui-locale-list-coverage.html)里的三档判读是同一套输入。 ## 按字母排序，对哪批用户成立？ 排序这件事平时没人当回事，因为在英文语境里它天然成立。 英文名和英文界面天然共用一套字母表，所以在英语环境里，用户脑子里的顺序和屏幕上的顺序是同一个。这个巧合让整件事看起来根本不存在。 ## 一个可以直接量的指标 做法很简单：把179门语言按英文名排一遍，记下每门语言的位次；再按自称排一遍，记下位次；两者相减取绝对值。 非拉丁字母那批怎么处理？统一放在拉丁字母之后，组内按码位排，这也是多数默认实现的做法。换一种放法数字会变，但方向不会变。 这个差值就是“用户按自称去找、列表按英文名排”时，他实际要跨过的行数。 它量的不是认知负担，是物理距离。用户可能一眼就认出自己的语言，但如果那一行不在他估计的位置附近，他还是得翻。 ## 中位数34位 结果是：中位漂移34位，均值50位，最大167位。179门语言里，漂移超过50位的有68门，占38.0%。 均值50比中位34高不少，说明分布是右偏的——大多数语言漂移不算太远，但有一批漂得极远，把均值拉了上去。这批就是非拉丁字母那51门。 34位是什么概念？一屏能显示十几行，34位意味着用户要多翻两三屏，而且他不知道该往哪个方向翻。 而且方向是随机的。有的语言按自称排更靠前，有的更靠后，用户没法形成一个稳定的习惯，每次都得重新找。 ## 漂移最大的十门 排在最前面的是阿姆哈拉语，位次差167，几乎是整份列表的长度——英文名Amharic排在最前面那一段，自称 አማርኛ 用埃塞俄比亚字母写，在拉丁字母序里被甩到最后。 阿姆哈拉语这个例子还有一层：它在上一篇那份清单 (https://zhangwenbao.com/minor-language-ui-locale-list-coverage.html)里是Chrome桌面版仅有的5门本站关注语言之一，也就是说它是少数几门“能选到”的语言，结果在列表里被排到了最远端。能选到和找得到，是两件事。 后面依次是威尔士语159位、约鲁巴语155位、粤语152位、切罗基语150位、阿萨姆语147位、缅甸语145位、中文144位、弗里西亚语143位、孟加拉语142位。 威尔士语这个例子特别值得看：Cymraeg和Welsh，两个词一个字母都不重合。而威尔士语是英国境内的官方语言之一，双语标识随处可见，这仍然没能让两个名字靠近一点。 这十门里有七门是非拉丁字母，另外三门是威尔士语、约鲁巴语、弗里西亚语——自称是拉丁字母，但首字母跟英文名差得远。 中文那144位也很典型：自称写作中文，英文名Chinese。中文这两个字在拉丁字母序里没有位置，只能被归到最后那一堆。一门使用者最多的语言，在按字母排的列表里排在最不显眼的地方。 ## 拉丁字母那一半也没好到哪去 把非拉丁字母的51门剔掉，只看自称也用拉丁字母的128门。这一批理论上是最容易对上的。 这一批之所以值得单独看，是因为很多人会想当然地觉得“拉丁字母的至少能对上个大概”。 实测下来，首字母跟英文名不同的有64门，正好一半。捷克语自称 čeština英文名Czech，克罗地亚语自称hrvatski英文名Croatian，冰岛语自称 íslenska英文名Icelandic，卢森堡语自称Lëtzebuergesch英文名Luxembourgish。 还有更绕的：斯洛文尼亚语自称slovenščina，斯洛伐克语自称slovenčina，两个词只差三个字母，而它们的英文名Slovenian和Slovak差得明显。按自称排，这两门最容易被认混的语言会紧挨着；按英文名排，它们中间还隔着几行。本站在克罗地亚语与斯洛文尼亚语那一篇 (https://zhangwenbao.com/croatian-slovenian-seo-two-small-markets-decision.html)里说过这两个市场的距离，名字这一层又给它加了一道。 ## 所以按字母排序对谁成立 结论其实挺尴尬：一份按英文名排序的语言列表，只对已经知道自己语言英文名的用户成立。 这句话可以再往前推一步：一份按英文名排的列表，是给已经不需要它的人设计的。 而这批用户恰恰是最不需要这个列表的那批——他们的英文足够好，看英文版也没什么障碍。列表的排序方式，把定位成本精确地压在了最需要切换语言的那批人身上。 怎么破？后面那一节给具体做法，核心是排序键换成自称，非拉丁的单独分组。 ## 按语言代码排序是不是中立的？ 很多站的语言列表是按语言代码排的，因为代码是数据库里的主键，排起来最省事，而且看起来最中立。 “按代码排”这个决定通常压根没被当成一个决定。数据库里的顺序是什么，前端拿到的就是什么，谁也没想过要重排。 ## 三种排序键放在一起比 那就把第三种排法也量一遍：按语言代码排序，跟前两种各差多少位。 这一步是整篇最有说服力的一步，因为它把一个看起来是技术细节的选择，翻译成了用户要多翻几屏。 结果是这样：按代码排跟按英文名排，中位只差5位；按代码排跟按自称排，中位差28位。 ## 5位和28位的意思 5位差不多就是同一屏之内。也就是说，你按代码排出来的顺序，跟按英文名排出来的顺序，用户几乎感觉不出区别。 换个说法：如果你的产品经理坚持按代码排、而设计师坚持按英文名排，两边其实在吵同一个方案。 28位则要翻两屏。按语言代码排序不是一个中立的技术选择，它在用户那里就是按英语排序。 ## 因为代码本身就是按英语缩的 这个结果有个很直接的原因。把179门语言的代码前两位分别跟自称、英文名比对：跟英文名对上的54门，跟自称对上的只有9门，两者都对上的22门（词根本来就同源），两者都对不上的94门。 那94门两边都对不上的，多数是三位代码的小语种，它们的代码来自更早的编目体系，缩的既不是英文名也不是自称，而是当年编目者用的那个称呼。 这批代码的隐蔽麻烦在于它们看起来很随机，没法靠记忆校验。这跟本站在母语审校验收那一篇 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)里说的是同一类问题：读着顺、格式对，都不等于对。 只看两位代码那113门：像英文名的31门，像自称的8门，差将近四倍。三位代码那66门更极端，像英文名的23门，像自称的只有1门。 三位那一批更极端是有道理的：三位代码大批量分配的时候，编目的人手上拿的是英文清单，一门语言的自称往往根本没被记录下来。 ## 几个具体的例子 匈牙利语的代码是hu，来自Hungarian，不是来自magyar。芬兰语是fi，来自Finnish，不是suomi。威尔士语稍微好一点，代码cy来自Cymraeg，属于那9门里的。 再补两个：巴斯克语的eu来自Euskara，属于取自自称的；阿尔巴尼亚语的sq来自Shqip，也是。这两门都是自称跟英文名毫无关系、但代码跟着自称走的例子，正好说明这件事没有统一规则。 德语的de来自Deutsch，中文的zh来自中文的拼音，希腊语的el来自Elliniká——这几门是取自自称的。但它们是少数。语言标签的规范 (https://www.rfc-editor.org/rfc/rfc5646)只规定代码怎么组合，不规定代码从哪个名字缩来，历史上就是各缩各的。 这也解释了一类特别隐蔽的事故：僧伽罗语是si，绍纳语是sn，两个代码只差一个字母，而它们的自称和英文名毫无相似之处。把si写成sn，格式完全合法，任何校验都放行，光看代码没有任何提示能让人警觉，只有把语言全名打印出来才看得见。 ## 这条对做站的人意味着什么 意味着“我们按代码排，一视同仁”这句话在评审里说得过去，在用户那里说不过去。 补一句：这条不只对语言列表成立。任何一份用英文标识符当排序键的清单，在非英语用户那里都不是中立的，国家列表、时区列表、货币列表全一样。 如果你的列表超过十几项，而且面向的是非英语市场，按代码排等于把英语用户的定位成本转嫁给了所有人。 成本能不能量？能：中位28位乘上你的列表长度占比，就是平均每个用户多翻的行数。这个数拿去评审比任何形容词都管用。 ## 为什么一整族语言挤在同一个字母下？ 量首字母分布的时候撞见一件没预料到的事。 本来只是想画个首字母直方图看看分布均不均匀，结果有一根柱子明显比旁边高出一截。 ## 字母k那一段特别拥挤 自称用拉丁字母的128门语言里，首字母是k的有25门，占19.5%。而这128门语言的英文名里，首字母是k的只有10门，7.8%。 英文名那一侧的分布倒是挺平的，最高的s占15门，m占11门，l和k各10门，没有哪一根柱子特别突出。 两倍半的差距，不像是随机波动。 随机波动能解释一两门的差别，解释不了25比10。 ## 因为很多语言的名字自带一个类前缀 翻开那25门一看，规律非常明显：Kipare、Kitaita、Kimachame、Kikamba、Kishambaa、Kihorombo、Kinyarwanda、Kiruwa、Kiswahili…… 这些名字的英文对应分别是Asu、Taita、Machame、Kamba、Shambala、Rombo、Kinyarwanda、Rwa、Swahili——除了基尼亚卢旺达语，英文名里都没有那个前缀。 这些是班图语族的语言。在这一族里，名词按类分组，每一类有自己的前缀，而“某某语”这个意思的名词恰好归在一个用ki- 打头的类里。于是十几门互不相干、分布在几个国家的语言，因为一条语法规则，在字母表里被挤成了一堆。 顺着这条线还能推一步：既然前缀表示“语言”这个类，那把前缀去掉剩下的部分往往是族群名或者地名。Kiswahili去掉ki- 是Swahili，Kikamba去掉是Kamba。英文名取的正是去掉前缀之后那一截。 ## 不只是ki这一个前缀 同一族的还有别的写法：Ichibemba的ichi-、Ikirundi的iki-、Ekegusii的eke-、Rukiga和Runyankore的ru-、Luganda和Luluhia的lu-、Chimakonde的chi-、Gikuyu的gi-、isiZulu的isi-。 isiZulu这个写法尤其值得注意：它的前缀是isi-，所以按自称排会落在i那一段，而英文名Zulu在z，一头一尾。 把这些算上，179门语言里带类前缀的自称有23门。它们的英文名分别是Bemba、Rundi、Gusii、Chiga、Nyankole、Ganda、Luyia、Makonde、Kikuyu、Zulu——散落在B、R、G、C、L、N、Z各处，一点都不挤。 23门在179门里占12.8%，不算多，但它们全部集中在字母表的很小一段上，这个集中度才是关键。 ## 这件事对排序的直接后果 如果你的产品面向东非市场，列表里同时有斯瓦希里语、卢干达语、基尼亚卢旺达语、基库尤语，按自称排它们会紧挨着，按英文名排它们会散开。 顺带一提，东非这几门语言在界面语言清单那一篇 (https://zhangwenbao.com/minor-language-ui-locale-list-coverage.html)里的处境差别很大：斯瓦希里语在Chrome桌面版里有，卢干达语连Firefox都被移除过。列表里放在一起的选项，背后的软件成熟度可以差很远。 哪种更好？看用户是谁。对当地用户，挨着是对的——他一眼扫到那一段就知道自己的语言在附近；对总部做多市场配置的人，散开更符合他脑子里的地图。这不是审美问题，是两批人的检索路径不同。 如果实在拿不准，用分组解决：把同一地区的语言放一组，组内怎么排都不影响大局。 ## 顺带纠正一个常见的写法 还有个细节：这类语言的自称在正式场合是带前缀的，缩写场合会去掉，比如Kiswahili和Swahili都能见到。 做搜索匹配的时候则要反过来：带不带前缀都要能搜到，输入swahili和kiswahili应该落到同一项。 做多语言字段的时候，别自作主张把前缀砍掉统一格式。这跟本站在地名的本地名与外来名那一篇 (https://zhangwenbao.com/minor-language-place-name-endonym-exonym-search.html)里说的是同一条：名字的形态本身携带信息，规范化会把信息抹掉。 ## 一半的语言，自称根本打不出来？ 还有一个维度平时完全没人考虑：这个名字用户能不能敲进搜索框。 这个维度只有在给长列表加搜索框的时候才会浮出来，而加搜索框通常是列表变长之后的补救动作，那时候前面的决定都已经定死了。 ## 能用纯英文键盘打出来的不到一半 把179门语言的自称逐条检查，看它们是不是只由ASCII字符组成。 判据取的是纯ASCII，也就是标准英文键盘不用切换输入法、不用组合键就能直接敲出来的字符集。 结果是87门，48.6%。超过一半的语言，它的自称在一台只装了英文键盘的机器上打不出来。 这个数字的另一半含义是：如果搜索框只匹配自称，你等于要求用户先有能打出自己语言名字的输入环境。而这批用户里有相当一部分正处在没有本地输入法的机器前——不然他也不至于要来切语言。 ## 拉丁字母也不等于打得出来 非拉丁那51门打不出来是意料之中的。意外的是拉丁字母那128门里，有41门带非ASCII字符，占32.0%。 32.0%这个比例比预想的高。原因是欧洲语言的自称几乎人手一个变音符号，而英文名把这些符号全都抹平了。 čeština的 š 和 č、íslenska的 í、Gàidhlig的 à、español的 ñ、français的 ç、Ɓàsàa的 Ɓ、Kĩembu的 ĩ、Asụsụ Igbo的 ụ、Eʋegbe的 ʋ——这些字符在标准英文键盘上都要绕一道。 还有一类更隐蔽：字符看起来像ASCII，实际不是。比如某些语言用的是带钩的字母或者特殊形状的辅音，在小字号下跟普通字母几乎分不出来，复制粘贴过去却匹配不上。 ## 这直接决定了搜索框该怎么做 很多站给长语言列表加了搜索框，这本来是对的。但如果搜索框只按显示名匹配，那对上面这批用户等于没有。 这类搜索框还有个常见毛病：只做前缀匹配。用户输入nemet想找德语，前缀匹配对Deutsch和German都没用。做成子串匹配加多字段匹配，成本几乎没有增加。 可用的做法是让搜索框同时匹配三样：自称、英文名、语言代码，并且对变音符号做归一化，输入ceska也要能匹配到 čeština。这一层的坑本站在法语重音符号那一篇 (https://zhangwenbao.com/french-seo-accents-quebec-keyword-variants.html)里写过，机制是一样的。 如果想再进一步，把常见的第三方叫法也塞进匹配表，比如用户可能用自己母语里的叫法去搜另一门语言。这份表可以直接从区域数据仓库里导，一门语言一行。 ## 大小写这一层还有一个雷 做归一化的时候要小心土耳其语。土耳其语的i转成大写不是I，做全局大小写折叠会把词改成另一个词，本站在大小写转换那一篇 (https://zhangwenbao.com/minor-language-case-folding-lowercase-turkish-dotless-i.html)里专门写过这件事。 顺带还有一个跟排序有关的：不同语言对同一批字母的排序规则不一样，比如某些语言把带变音的字母当成独立的字母排在最后。做语言列表的时候通常用不区分语言的默认规则就够，但要知道自己用的是哪一套。 语言列表的搜索框正好是最容易踩这个雷的地方，因为它天然要做不区分大小写的匹配。 ## 一条容易被忽略的收益 把自称、英文名、代码三样都做成可匹配，还有个附带好处：站内搜索和客服工单里，用户提到自己语言时用的词五花八门，这份对照表可以直接复用。 另外这张表还能用来做一件小事：把用户提交的自由文本语言字段归一化。表单里那个“您使用什么语言”的填空框，收上来的答案会同时包含自称、英文名和各种缩写。 ## 那你的切换器上该写哪个名字？ 数据讲完了，说落地。这一节给的是可以照着做的判断。 下面这几条按决策顺序排：先定写什么，再定怎么排，最后才是搜索框这类补救措施。 ## 默认答案：写自称 先说结论。语言切换器上的每一项，应该用那门语言自己的名字写，而不是用当前界面语言的叫法。 这条结论在多数国际化指南里也是默认推荐，本文的贡献是给它配上了数字：76.0%的语言两个名字对不上，所以写错的代价不是偶发，是常态。 理由很直接：会来点这个切换器的人，是当前界面他看不懂或者不想看的人。用他看不懂的那门语言去标注他要切去的语言，等于让他在看不懂的东西里找看不懂的东西。 有个反例经常被拿出来：如果用户的英语足够好，写英文名他也认得。这话没错，但它把设计目标从“所有人都能用”降成了“会英语的人能用”，而这恰恰是切换器要解决的问题本身。 ## 但有两种情况要例外 第一种：面向企业采购或者内部管理后台的语言配置界面。用的人是运营，不是终端用户，他脑子里的地图是英文名，这时候写英文名反而对。 这一类界面还有个特点：使用者要在几十上百种语言之间做批量操作，他需要的是可预测的顺序，不是可辨认的名字。两种需求是冲突的，分开做是对的。 第二种：列表极短，三五项，而且用国旗或者地区名做主标识。这种情况下语言名只是辅助信息，写哪个都行。 不过就算只有三五项，也建议顺手把自称写上——成本是零，收益是那批英语不好的用户不用猜。 ## 两个名字都写行不行 行，而且在中大型列表上通常是最优解：主行写自称，后面用较小的字号跟一个当前界面语言的叫法。 两个名字的主次不能反。自称在前、当前界面语言的叫法在后，因为主要读者是前一种人。反过来放会让整份列表在视觉上还是一份英文列表。 这样按自称找的人和按英文名找的人都能扫到。代价是每一行变宽，在窄屏上要多占一行，这个账要自己算。 还有个附带好处：搜索引擎抓到的这一段文本会同时包含两套名字，这对本站在锚文本变形那一篇 (https://zhangwenbao.com/minor-language-internal-link-anchor-inflection-variants.html)里讲的那种匹配问题有一点点帮助，虽然不多。 ## 不要用国旗代替语言名 这条老生常谈但还是得说：国旗标的是国家，语言不是国家。西班牙语该挂哪面旗，阿拉伯语该挂哪面旗，英语该挂哪面旗，这些问题没有正确答案。 还有个更实际的理由：国旗图标在很多市场是政治敏感的，一个选错的旗子造成的麻烦比找不到语言大得多。 本站在西班牙语两个市场那一篇 (https://zhangwenbao.com/spanish-seo-es-es-latam-keyword-divergence.html)里说过，同一门语言在不同市场是两套词表；用一面旗去代表它，第一步就把这件事抹平了。 ## 把语言标签写对 切换器每一项的链接上，把语言标签写进标记里。MDN关于语言属性的说明 (https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/lang)里提到一个很实用的细节：链接可以带一个属性声明目标页面的语言，这跟元素自身内容的语言是两回事。 具体写法是两处：一是给这一项的文本声明它自己的语言，这样浏览器和读屏知道该用哪套规则处理；二是给链接声明目标页面的语言。两者容易被混成一个。 这一条对读屏软件影响很大——切换器里那一串外语词，如果不声明语言，读屏会用当前页面语言的发音规则去念。一个中文页面上的Deutsch，读屏会按中文的规则拼读，念出来的东西没人听得懂。语言列表恰好是全站外语词密度最高的一个控件，也就是最需要逐项声明的地方。 ## 排序和分组具体怎么做？ 知道了写什么，还得决定怎么排。 排序这件事的判断依据只有一个：列表有多长。长度决定用户是扫还是找，扫和找需要的顺序不一样。 ## 先问列表有多长 十项以内：怎么排都行，按流量大小排最实用，把主力市场放前面。 这一档反而要注意别过度设计。十项以内加搜索框、加分组，都是给自己找麻烦。 十到三十项：按自称的字母序排，非拉丁字母的单独成组放在后面或前面，组内按各自的顺序。 这一档是最需要认真做的，因为它长到不能一眼扫完，又短到用户不会想到去用搜索框。 三十项以上：必须加搜索框，排序退居次要，但仍然建议按自称排，因为用搜索框的人会先扫一眼。 这一档还建议在列表顶部单独放一个最近使用或者推荐的小组，三五项，直接命中大多数人。 ## 非拉丁字母那一组怎么放 最省事也最不容易出错的做法是按书写系统分组，每组给一个小标题。拉丁字母一组，西里尔一组，天城文一组，东亚一组，其余合并。 分组这件事还有个额外收益：它顺手把字体问题也分好了组。同一组内的语言共用一套字形，加载策略可以一起定，本站在网页字体那一篇 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)里算过这笔账。 分组的标题用什么语言写？用当前界面语言，因为组标题是导航信息，不是内容。这跟组内条目用自称写并不矛盾，两者承担的功能不同。 分组之后每一组内部的排序压力就小多了，因为组内条目通常不超过十几条。 东亚那一组要特别处理一下：中日韩三门语言的自称都是两三个字，按任何字母规则排都没有意义，按使用者规模排反而最直观。 印度那一组同样要单独想：本站在印度十一门语言九套书写系统那一篇 (https://zhangwenbao.com/india-multilingual-seo-eleven-languages-nine-scripts-priority.html)里算过，光印度一个市场就能在你的列表里塞进七八套互不相同的字母表，按书写系统分组之后这一段会立刻清爽很多。 ## 不要按代码排，除非列表很短 前面量过，按代码排等于按英语排。列表短的时候无所谓，长的时候这是一个实打实的成本转嫁。 如果你的列表是从某个开源组件里直接拿的，多半就是按代码排的。检查一下，这类默认值很少有人改。 如果因为技术原因必须按代码存储，那就在渲染时按显示名重排一次，这是前端几行代码的事。 重排的时候记得用一个稳定的排序，不然每次渲染顺序可能不一样，用户的肌肉记忆会被打乱。 ## 验收怎么做 找三个母语者，让他们在你的列表里找自己的语言，记录用了几秒、翻了几屏、有没有走错方向。三个人就够，问题会立刻暴露出来。 如果找不到母语者，退而求其次：把列表里的名字全部换成你完全不认识的语言，自己找一遍。这个土办法能重现大部分问题。 另外可以顺手验一件相关的事：切换之后落地页对不对。很多站的切换器会把用户丢回首页，这在内容站上是实打实的流失，本站在小语种URL那一篇 (https://zhangwenbao.com/minor-language-url-native-script-vs-latin-transliteration.html)里提过相近的路径问题。 顺带把语言代码逐个丢进注册表反查一遍语言全名，人工扫一眼。同族易撞的代码不少，僧伽罗语是si不是sn，老挝语是lo不是la，斯洛伐克语sk和斯洛文尼亚语sl只差一个字母。 这个动作花不了五分钟，但它抓到的是那种格式完全合法、任何校验都放行、只有把全名打印出来才看得见的错误。 ## 这套东西要不要做成配置 建议做成一张表，三列：语言代码、自称、当前界面语言的叫法。这张表跟本站在界面语言清单那一篇 (https://zhangwenbao.com/minor-language-ui-locale-list-coverage.html)里说的那份查询结果放在同一个文档里，因为它们的输入是同一批语言代码。 如果要更完整，可以加第四列：这门语言的书写系统，用来做分组；第五列：常见的别名与旧称，用来做搜索匹配。五列就足够支撑一个上百项的列表了。 这张表的维护成本几乎为零，因为语言名不会变。它是本站这几年做过的所有对照表里唯一一份可以做完就不管的。 做成表还有个好处：以后加语言只用加一行，不用回头改模板。 ## 我一开始猜错了哪几条？ 这一批的预期错得比上一批还狠。 开工前写了八条，最后只有一条完全猜对。这个比例本身也算一条信息：语言名字这一层，日常直觉的可靠度接近于零。 ## 以为自称跟英文名不同的占三四成 这是错得最厉害的一条。实测76.0%，比预估高出一倍还多。 低估之后会怎样？会觉得“大部分语言其实对得上，少数例外单独处理一下就行”，于是把一个需要系统性方案的问题当成了打补丁。 错的原因大概是脑子里的样本偏了——最先想到的例子是日语Japanese、韩语Korean、俄语Russian这类看起来对得上的，而这类恰恰是少数。 ## 以为排序漂移的中位数在十几位 实测34位，均值50位。低估了一倍以上。 这条错误跟上一条是连着的：既然以为名字大多对得上，自然也就以为位次差不了多少。两个错误互相加固，这是最难自查的一种情况。 顺着低估的判断会得出“差几行而已，用户翻一下就到了”的结论，而34位在多数屏幕上是两三屏。 ## 以为语言代码多半取自自称 这条错得有点丢人。因为最熟的两个例子德语de和中文zh恰好都是取自自称的，就默认这是常态。 而且这两个例子还都是本站最常用来举例的语言，等于把一个错误的样本反复强化了很多遍。 实测像英文名的是像自称的六倍。两个最熟悉的例子同时是例外，这种情况在做判断时几乎防不住，唯一的解法是把样本拉全再看比例。 补一句方法上的教训：判断“某类东西通常是什么样”的时候，先数一遍再说话，别从自己最熟的两三个例子外推。本站在译入比例那一篇 (https://zhangwenbao.com/minor-language-content-translated-share.html)里也吃过同一种亏。 顺带一提，本文这套量法有个明确的局限：它假设用户是按首字母定位的。对于自称和英文名都不认识、只认国旗或者只认地区名的用户，位次漂移这个指标解释不了他们的行为。 ## 以为班图语的前缀不成规模 以为会有几门，实测ki- 一个前缀就11门，算上同族的其他写法23门，把字母k那一段的占比从7.8%推到19.5%。 这条错得倒是愉快，因为它带出了整篇最有意思的一个机制——一条语法规则可以改变一整族语言在界面上的位置。 猜对的只有一条：非拉丁字母的自称约占三成，实测28.5%。 ## 哪些相邻的问题不归这一层管？ 照例划一下边界。 这一层的边界特别容易糊，因为语言选择器同时长在结构、交互、内容三个人的地盘上。 ## 切换器放在哪儿不归这里 切换器该放页头还是页脚、该不该跟着滚动、要不要在没匹配到语言时弹提示，这些属于站点结构和国际化架构，跟具体是哪门语言无关。 同理，切换语言之后是留在当前页面还是回首页，也是结构层的决定。它很重要，但跟这门语言叫什么无关。 ## 自动识别与跳转不归这里 按用户偏好自动选语言是另一套机制，而且它在很多小语种市场上是失效的——上一篇量过原因。本文假设的是用户已经决定自己动手切。 两者的关系是：自动识别越不可靠的市场，手动切换器越重要，于是本文这些细节的权重越高。 ## 地名的两套叫法不归这里 语言名和地名都有本地叫法与外来叫法的分裂，但两者的落地位置完全不同：语言名长在界面控件上，地名长在内容和标题里。后者归地名那一篇 (https://zhangwenbao.com/minor-language-place-name-endonym-exonym-search.html)。 还有一个相邻但不同的分裂：品牌名的本地写法。那个你能自己规定，语言名和地名都规定不了。 ## 交给谁 那张三列对照表归做本地化的人，一门语言两分钟。排序和分组归前端。最容易掉在缝里的是“该写哪个名字”这个决定本身——它看起来像文案，实际上是一次检索路径的设计，而文案通常不做这类决定。 验收也建议交给同一个人，因为他是唯一能一眼看出“这个名字写错了”的人。让做前端的人验收这份表，等于让他去核对一批他不认识的词。 ## 常见问题解答 ## 语言切换器上到底该写自称还是英文名？ 面向终端用户的站写自称，因为会来点这个切换器的人正是看不懂当前界面的人。面向运营的后台配置界面写英文名，因为使用者脑子里的地图就是英文名。列表超过十几项的时候，两个都写是最稳的方案：主行自称，后面小字跟一个当前界面语言的叫法。 ## 按语言代码排序有什么问题？ 它不中立。实测下来按代码排出来的顺序跟按英文名排只差5位，跟按自称排差28位，因为大多数语言代码本身就是从英文名缩来的。列表短的时候没关系，长的时候等于把定位成本转嫁给所有非英语用户。技术上必须按代码存的话，渲染时重排一次就行。 ## 非拉丁字母的语言名在列表里怎么排？ 按书写系统分组，每组一个小标题，拉丁一组、西里尔一组、天城文一组、东亚一组、其余合并。分组之后组内一般不超过十几条，排序压力就小了。不分组的话这批语言会按码位排出一个跟任何人的直觉都无关的顺序，而它们占到整份清单的近三成。 ## 为什么很多非洲语言的名字都以ki开头？ 因为班图语族的名词按类分组，每类有自己的前缀，而表示某某语的那一类恰好用ki- 打头。这不是巧合，是一条语法规则。后果是十几门互不相干的语言在字母表里挤成一堆，而它们的英文名散落在各处。做字段的时候别把前缀砍掉统一格式，那个前缀是词的一部分。 ## 语言列表加了搜索框还需要管排序吗？ 需要，但优先级降低。用搜索框的人通常会先扫一眼列表，扫不到才开始打字。更要紧的是搜索框本身要能同时匹配自称、英文名和语言代码，并且对变音符号做归一化——超过一半的语言，自称在英文键盘上打不出来，只按显示名匹配等于对这批用户没有搜索框。 ## 用国旗代替语言名可以吗？ 不建议。国旗标的是国家，语言不是国家，西班牙语、阿拉伯语、英语该挂哪面旗都没有正确答案。而且同一门语言在不同市场往往是两套词表，一面旗会把这个差别整个抹平。国旗只适合真正按国家分站的场景，而那时候它标的也不是语言。 ## 安卓能选181门系统语言，Chrome桌面版只有53门，差的那批人设不成自己的母语 - URL：https://zhangwenbao.com/minor-language-ui-locale-list-coverage.html - 分类：小语种SEO - 发布：2020-06-26 | 更新：2020-06-26 - 摘要：三家界面语言清单实测：安卓181门、Firefox 88门、Chrome桌面53门，差3.4倍；进出清单的判据写在工单里，是社区还在不在，不是使用人数。 - 关键词：多语言SEO,小语种SEO,出海建站,网站本地化 > **TLDR**：摘要：把安卓、Firefox、Chrome三家的界面语言清单下下来逐条对了一遍。安卓系统能选181门语言，Firefox出货88门，Chrome桌面版只有53门，同一门语言在三家的待遇差出3.4倍。更要紧的是进出这份清单的判据：翻开工单，写的是这个社区还在不在，不是这门语言有多少人说。用户设不成这门语言，你的报表里就没有这门语言的用户。 > 摘要：把安卓、Firefox、Chrome三家的界面语言清单下下来逐条对了一遍。安卓系统能选181门语言，Firefox出货88门，Chrome桌面版只有53门，同一门语言在三家的待遇差出3.4倍。更要紧的是进出这份清单的判据：翻开工单，写的是这个社区还在不在，不是这门语言有多少人说。用户设不成这门语言，你的报表里就没有这门语言的用户。 有个动作很多人做过一次就再没做过：拿起手机，进设置，翻到语言那一页，看看目标市场那门语言在不在里面。 这个动作之所以做一次就不做了，是因为看到目标语言在里面之后，事情就结束了。看不到的时候呢？多数人的反应是换一部机器再看看，然后把这件事当成个例放过去。 保哥上个月把这个动作做成了一件正经事——不是翻手机，是把安卓系统、Firefox、Chrome三家的界面语言清单从源码仓库里下下来，逐条对齐。三份清单都是公开的文本文件，加起来不到200KB，一个下午能对完。 对完之后有两件事跟原来的印象不一样。 第一件是量级。安卓的清单有181门语言，Chrome桌面版只有53门。中间差的那128门语言，它们的使用者拿着安卓手机可以把系统调成母语，打开电脑上的Chrome却只能在53个选项里挑一个不是自己的。 第二件更意外。翻开这些清单的改动记录，一门语言进来或者出去，理由从来不写“这门语言使用者太少”。写的是另一句话，而那句话跟语言本身没关系。 下面这些数字是为了把这两件事说清楚。口径全部锁在2020年年中：安卓10、Firefox那时候的出货版本、Chrome 83。三份文件都能按版本号翻回去，谁都可以自己核一遍。 ## 为什么要先查一遍这份清单？ 先说这件事跟做小语种到底有什么关系，因为它看起来像是操作系统厂商的家务事。 ## 用户设不成，请求里就没有这门语言 浏览器每发一个请求，都会在头部带上一行语言偏好，服务器靠它判断该给哪个版本。这一行的值不是用户手打的，是从系统设置和浏览器设置里读出来的。MDN关于这个请求头的说明 (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Language)写得很直白：它反映的是用户在客户端配置的偏好，不是用户会说什么语言。 这一行长什么样值得看一眼。它是一串带权重的语言标签，比如先写用户的第一偏好，再跟上几个备选，每个后面挂一个零到一之间的数字表示优先级。服务器拿到之后按顺序挑一个自己有的版本。 于是就有了一条很别扭的因果链。用户会说老挝语，但他的笔记本上装的Chrome里没有老挝语这个选项，他只能把界面留在英语。他打开你的站，请求头里写的是英语。 这条链上的每一环单独看都没错。系统按用户设置报语言，浏览器按系统设置报语言，服务器按报上来的语言发版本，统计工具按报上来的语言归类。四步全对，结论是错的。 你的服务器照着这一行给他发英语版，你的统计后台把他记成英语用户，你的语言维度报表里老挝语那一格是零。 更麻烦的是这个错误不会报警。它不产生任何异常，不进错误日志，页面照常打开，转化照常发生。你唯一能看到的症状是那门语言的用户占比小得不像话，而这个症状太容易被解释成市场本来就小。 ## 这不是理论上的可能，是一个可以数出来的比例 本站这几年写过的小语种里，有27门是真正被当成市场认真讨论过的。把这27门丢进三份清单查一遍：能在Chrome桌面版里被选中的只有5门，泰米尔语、孟加拉语、阿姆哈拉语、斯瓦希里语、波斯语。 这个查法本身很粗暴：把语言代码丢进三个文本文件搜一遍，能搜到就算有。没有加权，没有折算，就是有和没有两种状态。粗暴有粗暴的好处，它不需要任何假设。 剩下22门里，老挝语、蒙古语、豪萨语、约鲁巴语、伊博语、祖鲁语、普什图语这7门更极端——两家浏览器的正式清单里一门都没有，只有安卓那份系统清单收了它们。 顺带说一句这7门的分布：三门在东南亚和东亚内陆，三门在西非，一门在南亚。它们的共同点不是穷，是各自的技术社区没在这两家浏览器的流程里露过面。 ## 它跟内容量、跟需求是三把不同的尺子 判断一门语言值不值得投入，这几年常用的输入项是内容供给和搜索需求。这两把尺子本站量过，一把在按母语人口排优先级那一篇 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)里，一把在关键词工具返回零的那一篇 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)里。 这两把尺子有个共同的毛病：它们量的都是内容侧，而内容侧的数据本身就依赖这门语言在网上的存量。存量少的语言，两把尺子都会给出偏低的读数，而且是同向偏低，叠加起来会把结论推得比事实更悲观。 界面语言清单量的是第三件事：这门语言在软件世界里有没有落脚点。它跟前两把尺子给出的排序不一样，而且它便宜到不用申请预算——三个公开文件，半小时。 它还有一个别的尺子没有的性质：它是离散的。有就是有，没有就是没有，不需要抽样，不需要置信区间，不会因为你换一个时间跑就得出不同的数。这类硬边界在小语种这一层很少见，遇到了就该用上。 ## 这一篇能回答和不能回答的 能回答的是清单本身：有多长、谁在里面、什么时候进的、什么时候被拿掉的、判据是什么。 另外这三份清单都是公开源码里的文件，任何人都能翻回任意一个历史版本重新数一遍。本文里的每个数字都能被独立复核，这一点在小语种这一层同样不常见。 不能回答的是清单里的那些语言翻得好不好。一门语言在清单里，只说明有一份语言包存在，不说明这份语言包是完整的。那是另一层的问题，本文不碰。 ## 三份清单分别有多长？ 先把三个数摆出来，因为它们的差距比多数人预估的大。 ## 安卓：514个区域组合，181门语言 安卓系统支持的语言写在一个叫区域配置的资源文件里，安卓10那一版的这份文件 (https://android.googlesource.com/platform/frameworks/base/+/refs/tags/android-10.0.0_r1/core/res/res/values/locale_config.xml)公开可查，一行一个条目。数出来是514条。 这份文件的格式很朴素，就是一长串条目，每条写一个语言加地区的组合，比如英语加美国、法语加加拿大。它决定的是系统设置里那个语言列表能列出什么，也决定了应用能拿到哪些区域参数。 有一点容易被忽略：这份清单同时也是应用能拿到的区域参数的上限。你的应用想按某个地区格式化价格和日期，前提是这个地区组合在清单里。清单没有的，运行时会往上一级回落，这跟本站在区域数据那一篇 (https://zhangwenbao.com/minor-language-locale-data-inheritance.html)里量过的回落是同一条链。 但514是区域组合数，不是语言数。把地区后缀去掉、按语言去重之后，剩181门。 这一步不能省。后面几乎所有关于清单长度的误读，根子都在把这两个数混着用。 这181这个数字，是三家里最大的一个，也是本文后面所有对照的基准线。 ## Firefox：97个出货版本，88门语言 Firefox把正式出货的语言版本写在一份叫出货清单的纯文本文件里，一行一个。2020年年中这份文件里有97行。 这份文件旁边还有一份更长的，叫全部语言清单，里面记着所有正在被翻译的语言。两份的差别就是“在翻”和“已经能下载到”的差别。做判断要看出货那一份，看在翻那一份会系统性高估。 同样去掉地区后缀，88门语言。比安卓少了将近一半。 Firefox的地区变体比安卓少得多，97比88，只多9个。这跟安卓的514比181形成鲜明对照，也说明两边的清单是按完全不同的粒度在维护的。 ## Chrome：桌面53门，全部算上78门 Chrome这边有意思。它把界面语言清单写在构建配置里 (https://chromium.googlesource.com/chromium/src/+/refs/tags/83.0.4103.61/build/config/locales.gni)，而且不是一份，是好几份变量。 这个设计本身透露了信息：一份清单要拆成好几个变量，说明不同平台拿到的东西真的不一样，而且这种差别是有意做出来的，不是历史遗留。 总清单87条，里面有27条标着只给安卓。也就是说，你在Windows或者macOS上装Chrome，能在设置里选到的界面语言是60个区域组合、53门语言。 顺便说，那87条里还混着四对历史遗留的旧代码——菲律宾语、希伯来语、印尼语、挪威语，每一门都有一个上古写法和一个现行写法同时在列。数语言的时候要把它们合并，不然会凭空多出四门。 53门。这个数字跟安卓那份181门比，差3.4倍。 ## 三家都有的只有62门 把三份清单按语言层求交集，结果是62门。 62这个数比想象中小。三家加起来涉及的语言有两百多门，能同时被三家都收下的只有不到三分之一。 换个说法：安卓收的181门语言里，有95门是安卓独有的，两家浏览器一家都没收。而按“Chrome桌面能不能选”这个最严的口径算，安卓有而Chrome桌面没有的是132门。 ## 这三个数不该被拉到同一张表里直接比 先把口径说清楚，免得后面越说越乱。安卓那份是系统级清单，装机就在里面；Firefox那份是官方出货的语言包，要下载对应版本或者装语言包；Chrome那份是打进安装包的资源。三者的门槛不一样，安卓最松是正常的。 还有一个口径要提前说：本文数的是“能不能把界面设成这门语言”，不是“能不能显示这门语言”。显示是字体和渲染的事，本站在网页字体那一篇 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)里量过，两者经常被混为一谈。 所以本文的用法不是给三家排名，是拿它们互相当参照。一门语言三家全有，跟三家只有安卓有，是两种完全不同的处境。 ## Chrome桌面版那份清单，五年一个字没动过？ 把Chrome的清单按版本拉成一条时间线，看到的东西挺出人意料。 能这么拉，是因为这份构建配置从2014年9月就在仓库里了，每次改动都留着记录。整个十年里它一共只被改过三十几次，其中一多半还是重构和改名，真正动到语言名单的没几次。 ## 2014到2019，只减不增 Chrome 40（2014年11月）那份文件里，界面语言53门。Chrome 45、Chrome 50，还是53门。 到了Chrome 55（2016年12月），数字变成51门——不是加了两门，是少了两门。此后Chrome 60、65、70、75、79，一路到2019年12月，全都是51门，一个字没改。 减掉的那两门不是被删除，是被并进了别的写法。但净效果一样：用户在设置里能看到的选项少了两个。 整整五年，全球份额六成以上的桌面浏览器，界面语言清单是净减少的。 ## 2020年初那次，一口气加了27门 转折出现在Chrome 80，2020年2月。那份构建配置突然多出一批新变量，总清单从51跳到86。 这次改动的记录留在2019年11月到12月之间，几次提交连着来，其中一条的说明写得很直接：给安卓的应用包新增25门语言。之后又零星补了几门，凑成27。 新进来的27门是这些：南非荷兰语、阿萨姆语、阿塞拜疆语、白俄罗斯语、波斯尼亚语、巴斯克语、加拿大法语、加利西亚语、亚美尼亚语、冰岛语、格鲁吉亚语、哈萨克语、高棉语、吉尔吉斯语、老挝语、马其顿语、蒙古语、缅甸语、尼泊尔语、奥里亚语、旁遮普语、僧伽罗语、阿尔巴尼亚语、乌尔都语、乌兹别克语、香港中文、祖鲁语。 这份名单几乎就是一份小语种花名册。南亚、东南亚、中亚、高加索、巴尔干，本站写过的那批语言在里面能找到一大半。 把它跟本站写过的语种篇对一下：老挝语、缅甸语、僧伽罗语、高棉语、蒙古语、格鲁吉亚语、亚美尼亚语、哈萨克语、乌兹别克语、乌尔都语、阿尔巴尼亚语、马其顿语、冰岛语——十几篇文章的主角一次性全在这份名单里。这不是巧合，是同一批语言在同一个时间点被同一套流程处理了。 ## 但这27门只给了安卓 然后就是那个转折。这27门在构建配置里带着一个明确的标记：只给安卓。桌面版的清单一条都没多。 “只给安卓”这个限定在构建配置里是一行代码，在用户那里是一个存在与不存在的差别。它不会出现在任何一份宣传材料里，也不会出现在任何一份支持语言列表的文档里。 所以2020年上半年的实际状况是：同一个Chrome，装在安卓手机上能选老挝语，装在电脑上不能。一门语言在你的手机和你的电脑上待遇不同，而这两台设备装的是同一个牌子的同一个浏览器。 ## 这次改动还把两个平台的关系整个反转了 这里有一条我事先猜错的。改动之前，Chrome的安卓版是比桌面版少的——构建配置里有一个变量专门列着安卓版拿不到的9门语言，孟加拉语、爱沙尼亚语、古吉拉特语、卡纳达语、马拉雅拉姆语、马拉地语、马来语、泰米尔语、泰卢固语。 那9门里有7门是印度的语言。也就是说2020年之前，Chrome的安卓版在印度市场上反而比桌面版少支持一批印度语言，这听起来很荒唐但确实如此。这跟本站在印度多语言那一篇 (https://zhangwenbao.com/india-multilingual-seo-eleven-languages-nine-scripts-priority.html)里说的那种复杂度是一脉相承的。 改完之后，那个变量没了，换成了“只给安卓”的27门。一次构建配置的重写，让同一个浏览器在两个平台上的语言支持关系从“安卓少9门”变成了“安卓多27门”。 ## 而iOS版一直是最少的那一个 顺带说一句iOS。Chrome的构建配置里另有一份清单，列着iOS版拿不到的13门语言：阿姆哈拉语、孟加拉语、爱沙尼亚语、菲律宾语、古吉拉特语、卡纳达语、拉脱维亚语、马拉雅拉姆语、马拉地语、斯洛文尼亚语、斯瓦希里语、泰米尔语、泰卢固语。 把这13门跟安卓版少的那9门逐条对，重合的有8门：孟加拉语、爱沙尼亚语、古吉拉特语、卡纳达语、马拉雅拉姆语、马拉地语、泰米尔语、泰卢固语。只有安卓缺的仅马来语一门，iOS额外缺的是阿姆哈拉语、菲律宾语、拉脱维亚语、斯洛文尼亚语、斯瓦希里语这5门。 顺带一提，这三份缺失清单里的语言几乎没有重叠的例外——泰米尔语和泰卢固语在两个移动平台上都被砍，而它们各自的使用者都在七千万以上。使用人数在这套流程里显然不是第一顺位的判据。 这8门重合项里有6门是印度的语言。两个移动平台各自砍掉的，基本是同一批印度语言，而这件事在任何一份面向用户的支持语言说明里都看不到。所以“Chrome支持这门语言”这句话本身没有信息量，必须问是哪个平台上的哪一版Chrome。 ## 两家浏览器收的是不是同一批语言？ 本来以为是包含关系，大的那份把小的那份包住。实测完全不是。 验的方法很简单：两个集合互相做差。如果是包含关系，其中一个方向的差集应该是空的。结果两个方向都不空，而且都不小。 ## Firefox有而Chrome完全没有的22门 这份名单很有特点：阿乔利语、阿拉贡语、阿斯图里亚斯语、布列塔尼语、卡克奇克尔语、威尔士语、下索布语、世界语、富拉语、弗里西亚语、爱尔兰语、苏格兰盖尔语、瓜拉尼语、上索布语、国际语、卡拜尔语、利古里亚语、新挪威语、奥克语、罗曼什语、桑海语、特里基语、科萨语。 另外这份名单里有两门是人造语——世界语和国际语。它们没有任何一个国家的市场，却在清单里稳稳待着，因为它们各自有一群极其稳定的爱好者在翻。这是社区驱动这套机制最纯粹的样本。 再看一眼使用人数：威尔士语约五十万常用者，罗曼什语不到五万，上索布语和下索布语加起来两三万，利古里亚语和阿斯图里亚斯语都是几十万量级。按人口排，这些语言没有一门能进世界前三百。 一眼看过去：欧洲的区域语言占了一大半，加上几门美洲原住民语言，再加两门人造语。 ## Chrome有而Firefox没有的那些 反方向的名单短一些，去掉三个历史遗留代码之后是10门：阿姆哈拉语、阿萨姆语、菲律宾语、吉尔吉斯语、老挝语、马拉雅拉姆语、蒙古语、奥里亚语、斯瓦希里语、祖鲁语。 斯瓦希里语的使用者以亿计，马拉雅拉姆语三千多万，阿姆哈拉语三千多万，祖鲁语一千多万。按人口排，这一批全部远远排在前面那一批之上。 把两份名单的人口加总更夸张：Firefox独有那22门加起来大概几百万人，Chrome独有那10门加起来接近三亿。两份清单量的东西差了两个数量级，而它们在产品界面上长得一模一样，都叫“选择语言”。 这一批的画风完全不同：亚洲和非洲，而且几乎都是使用人口以千万计的语言。 ## 一边按社区收，一边按市场收 两份名单摆在一起，机制就露出来了。 这两套机制的产出物看起来是同一种东西——都是一份语言清单——但它们回答的完全不是一个问题。一份回答“谁愿意做”，一份回答“做了值不值”。 Firefox的语言包靠志愿者社区做，谁组织起来了、谁翻完了、谁跟得住，谁就进清单。所以它收了威尔士语、奥克语、上下索布语这种使用者只有几万到几十万、但有一批人几十年如一日在维护的语言。 这套机制的好处是它对小语种极其友好，坏处是它完全依赖具体的人。人在，清单就在；人散了，清单里的条目就会被拿掉，本文后面那两张工单讲的就是这件事。 Chrome的清单是公司排的，判据是市场规模。所以它收了斯瓦希里语和马拉雅拉姆语，没收罗曼什语。 这套机制的好处是稳定，一旦进了就不太会掉出去；坏处是没有申请通道。一门语言的社区再热情，只要市场规模不到线，就一直在门外。 同一门语言的命运，取决于它掉进了哪一套决策机制里，跟它自己是什么样子关系不大。这一条对做市场判断的人特别实用：你查到一门语言在Firefox里有、在Chrome里没有，得出的结论不该是“做的人少”，而是“这门语言有社区、没市场规模”，那是两句意思相反的话。 ## 这条分野还能反过来用 如果一门语言两家都收了，说明它同时通过了社区那道关和市场那道关。这在做优先级时是个不错的加分项，而且不用花钱查。 反过来，一门语言两家都没有但安卓有，说明它是被系统级的清单顺手带进来的，既没有社区也没有市场投入，这是最需要警惕的一档。 本站写过的27门语言里，两家都收的有十几门，包括僧伽罗语、缅甸语、高棉语、尼泊尔语、格鲁吉亚语、亚美尼亚语、乌兹别克语、哈萨克语、阿塞拜疆语、阿尔巴尼亚语、马其顿语、冰岛语、巴斯克语、乌尔都语、波斯语、泰米尔语、孟加拉语。 ## 一门语言凭什么进这份清单，又凭什么被拿掉？ 这一节是全篇最值钱的部分，因为答案写在公开的工单里，有名有姓有日期。 能查到这些，是因为浏览器厂商把这类决定放在公开的工单系统里讨论。这一点跟很多闭源产品不同，也是本文能做出来的前提。 ## 缅甸语进清单那天的工单是怎么写的 2017年4月，缅甸语加进Firefox的正式出货清单。那张工单里的原话 (https://bugzilla.mozilla.org/show_bug.cgi?id=1355070)是：缅甸语已经连续几个版本周期跟上了翻译，测试也没发现什么特别的问题，可以随54版进入测试版和正式版了。 注意这句话里没有的东西：没有提缅甸有多少人口，没有提缅甸的手机保有量，没有提市场潜力。 整张工单从头到尾也没有提缅甸语在网上有多少内容，没有提搜索量，没有提竞争对手做没做。这些在做市场判断的人眼里最重要的指标，在这套流程里一个都不出现。 写的是“连续几个版本周期跟上了翻译”。入场判据是有没有一个人在持续跟，不是这门语言有多少人说。 ## 出场的判据写在另一张工单里 2014年1月，Firefox一次关掉了好几门语言的桌面版构建。那张工单的第一句话 (https://bugzilla.mozilla.org/show_bug.cgi?id=958703)是：下面这几个本地化工作组早就解散了，Firefox桌面版上他们的用户就算有也非常少，我们打算把这些构建关掉，直到有新的一拨人接手。 工单里那句“就算有也非常少”值得注意：用户量是被写进来了，但它是第二个理由，跟在“工作组解散了”后面，而且用的是一种明显不确定的说法。真正确定的那件事是前半句。 后面跟着一份名单：斯里兰卡泰米尔语、阿肯语、卢干达语、北索托语、萨哈语、沃洛夫语。 ## 解散这个词的分量 “早就解散了”这五个字值得停一下。它说的不是翻译质量不行，不是版本落后，是那个组织本身没有了。 放到做市场判断的语境里，这句话的信息量比任何一份市场报告都大：它等于说这门语言在那个时间点上，找不到一支能把一份软件翻完并且持续跟下去的队伍。你要在当地找本地化供应商，面对的是同一个人才池。 还有一个细节：这张工单没有说永久移除，说的是关掉，直到有新的一拨人接手。也就是说门是留着的，只是没人推。 这跟本站量过的另一件事严丝合缝：一门语言的软件本地化不是一个项目，是一条订阅——软件在长，字符串在增，你停手不是原地不动，是往回退。 本站在机器翻译直接上线那一篇 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)里说过一个相近的账：省下的那道人工，最后要分期还。软件本地化这一层的还款方式更直白，就是清单里少你一行。 2019年3月还有第二次，工单标题直接写着“把陈旧的语言从Firefox桌面构建里移除”，那次拿掉的是阿萨姆语、南非英语、迈蒂利语、马拉雅拉姆语、奥里亚语。 ## 安卓这边也掉过 别以为系统级清单就只进不出。安卓8.0有477个条目、182门语言，到8.1变成474个条目、180门语言。掉出去的两门是恩甘贝语和提格里尼亚语。 安卓的清单在这十年里整体是涨的，7.0是476条181门，10是514条181门，12跳到583条197门。但涨的过程里穿插着这种局部的减少，而减少从来不带解释。 提格里尼亚语是厄立特里亚的官方语言之一，也是埃塞俄比亚提格雷州的主要语言，使用者数百万。它就这么从系统清单里消失了，而且到安卓10还没回来。 这跟本站在非公历纪年那一篇 (https://zhangwenbao.com/minor-language-non-gregorian-calendar-data.html)里遇到的情况是同一个方向：提格里尼亚语在那份数据里同样是整段不存在，用户看到的纪年名是程序里的占位符。同一门语言在两套完全无关的数据里同时缺席，这种巧合通常不是巧合。 ## 所以这份清单量的到底是什么 把三条线索并起来：进来靠有人持续跟，出去靠那批人不在了，跟语言的人口规模没有直接关系。 这一条推翻了一个很常见的默认假设：以为这类清单是按使用人数排的。按人数排的话，豪萨语、约鲁巴语、伊博语这三门加起来两亿多使用者的语言，不该一门都进不了浏览器的正式清单。 这份清单量的不是一门语言有多少人说，是这门语言有没有一个还活着的技术社区。对做市场判断的人来说，后面这件事其实更有用——它预测的是你能不能在当地找到会做本地化的人。 ## 清单长度是被谁撑起来的？ 回到那个514。它比181大得多，多出来的部分值得单独看一眼。 ## 英语一门语言占了103个条目 安卓那份清单里，条目数排前面的语言是这样的：英语103个地区版本、阿拉伯语55个、法语46个、西班牙语27个、葡萄牙语9个、塞尔维亚语8个、德语和荷兰语各7个。 这个分布本身就说明清单是怎么长出来的：它不是按语言一条一条加的，是按市场一个一个加的。每开一个新市场，主流语言就多一个地区条目。 光英语一门就占掉了整份清单的两成。这103个里有美国英语、英国英语，也有加拿大、澳大利亚、印度、南非、爱尔兰、新西兰、尼日利亚、肯尼亚，一路排到一些人口只有几十万的岛国。 阿拉伯语那55个也是一样的道理，从摩洛哥一路排到阿曼。这跟本站在阿拉伯语那一篇 (https://zhangwenbao.com/arabic-seo-rtl-layout-msa-dialect-keyword.html)里讲的方言分布对得上——系统愿意分55个地区，说明这些地区之间的差别是被承认的。 ## 130门语言只有一个地区版本 另一头是这样的：181门语言里，有130门在清单里只有一个条目，没有任何地区变体。 更值得看的是这130门里绝大多数连语言加国家的写法都没有，只有一个孤零零的两位或三位代码。在很多系统里，这种没有地区的写法会走到一套默认参数上，而那套默认参数不一定适合任何一个具体市场。 这130门里，有61.5%在两家浏览器的清单里一条都找不到。只有一个地区版本，往往意味着这门语言在这套系统里只是被登记了一下，不是被认真分市场对待。 ## 地区版本数量本身是一个商业信号 反过来看更明显：有5个以上地区版本的语言只有10门，阿拉伯语、德语、英语、西班牙语、法语、荷兰语、葡萄牙语、俄语、塞尔维亚语、中文。 塞尔维亚语出现在这个名单里有点意外，它的使用者不到一千万。原因是它有两套书写系统，西里尔和拉丁各要一份，再乘上几个国家，条目数就上去了。这跟本站在双字母体系那一篇 (https://zhangwenbao.com/bulgarian-serbian-seo-cyrillic-latin-dual-script.html)里说的是同一件事。 这10门全部出现在浏览器清单里，一门不落，命中率100%。地区变体这件事要花人力去分，谁愿意分谁就是真在做这个市场。 这跟本站在西班牙语两个市场那一篇 (https://zhangwenbao.com/spanish-seo-es-es-latam-keyword-divergence.html)和葡萄牙语那一篇 (https://zhangwenbao.com/portuguese-seo-brazil-portugal-two-markets-keyword.html)里说的是同一件事的两个面：肯拆地区，说明拆了有收益。 ## 别拿区域组合数当语言数用 这一节最实用的一句话是个提醒。你在任何地方看到“支持超过五百种语言”这类说法，先问一句数的是不是区域组合。 这类说法在采购和立项材料里出现的频率相当高，而且往往被当成一个正面指标写进去。 514和181之间差着一个英语的103和阿拉伯语的55。报数的时候不说清口径，同一份文件能报出差2.8倍的两个数。这跟本站在区域数据自有率那一篇 (https://zhangwenbao.com/minor-language-locale-data-inheritance.html)里踩过的坑是同一类：数格子之前要先问格子里装的是什么。 ## 这件事怎么落到你的报表和你的站上？ 数据讲完了，说落地。这一层的坑几乎全部长在同一个地方：你以为你在观察用户，其实你在观察用户的设备。 下面这几条按能落地的顺序排，从改口径开始，因为那是唯一一件当天就能做完的事。 ## 语言维度报表会系统性低估小语种 最直接的一条：统计工具里那个“浏览器语言”或者“用户语言”维度，读的是设备设置，不是用户会说什么。 这个维度在做多语言站的人那里通常权重很高，因为它看起来比地理位置更贴近“用户是谁”。实际上正好相反，地理位置至少是从网络层测出来的，语言维度是从一个用户可能从来没碰过的设置项里读出来的。 目标语言不在设备清单里的市场，这个维度在报表上会稳定地偏向英语或者当地的第二语言。你看到老挝语用户占比0.3%，不代表老挝人不来，代表他们的机器发不出老挝语这个信号。 怎么验这个猜测？找一批已知来自该国的会话，看它们报上来的语言分布。如果本地语言的比例远低于当地的语言使用比例，而英语或者前殖民语言异常高，基本可以确认。 可操作的替代口径是：拿地理位置维度当主口径，语言维度只当辅助。两个数打架的时候，信地理位置那个。 ## 自动跳转与语言协商会一起失效 按语言偏好自动跳转这套做法，在清单外的语言市场上是空转的——那批用户的请求头里根本没有你要匹配的那门语言。 更糟的一种情况是自动跳转做成了强制的：用户报英语，站点直接把他甩到英文版，还不给回头路。这批用户可能正是最需要本地语言的那批人，而他们连选一次的机会都没有。 语言标签匹配的那份规范 (https://www.rfc-editor.org/rfc/rfc4647)定义了两种查找方式，一种要求前缀逐级回落，一种允许通配。两种算法都只能在用户实际发出的那几个标签里挑，用户没发出来的，任何算法都变不出来。 所以这类市场上，页面里那个明显的语言切换入口不是可选项，是唯一可用的通道。这一层的架构做法归国际SEO那一侧，本站在多语言站的标注与切换那一篇 (https://zhangwenbao.com/international-seo-hreflang-complete-guide.html)里写过，这里不重复。 入口的位置也有讲究：这批用户第一次落地大概率是在一个内容页而不是首页，所以切换入口不能只放在首页顶部。 ## 桌面和手机会给你两套语言信号 还有一条更细的：同一个人在两台设备上给你的语言信号可能不一样。 这件事在做归因的时候会造成一个隐蔽的后果：同一个人的两次会话被判成两种语言，跨设备的路径就断在这里了。 他的安卓手机出厂就是本地语言，他的公司电脑装的Chrome只能选英语。这不是假设，是三份清单的差值直接推出来的结果——差的那128门语言，全都会产生这种分裂。 本站在阿拉伯语手机端那一篇 (https://zhangwenbao.com/arabic-rtl-mobile-first-narrow-screen-pitfalls.html)里讲过一个相近的现象：中东有相当比例的用户系统界面是英文的，页面内容却是本地语言，所以判断页面方向绝不能去读系统语言。这两件事的根子是同一个——设备设置和用户身份不是一回事。 ## 报表按设备拆开之后才对得上 落地动作很简单：把语言维度和设备类型交叉着看。 具体做法是拉一张两维表，行是语言、列是设备类型，看每一门语言在移动和桌面之间的比例。正常情况下这个比例在各语言之间应该大致接近，出现明显离群的那几门就是被清单卡住的。 如果一门语言在移动端的占比明显高于桌面端，而且高得不合常理，多半就是这个机制在起作用，不是移动端用户真的更爱说母语。 ## 写内容那一侧要跟着调 最后一条落到内容上。清单外的语言市场，用户看到的界面是英语，看到的输入法可能也是拉丁字母的，他打进搜索框的东西会更像本站在希腊语拉丁转写那一篇 (https://zhangwenbao.com/greek-seo-greeklish-latin-transliteration-coverage.html)里描述的那种混合形态。 还有一层影响在输入法上：桌面端如果系统语言是英语，用户装本地输入法的动力也会低一些，打出来的东西更容易是拉丁转写。本站在品牌名由输入法决定那一篇 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)里说过，可输入性从来不是语言的属性。 做词表的时候把拉丁转写那一栏留出来，比纠结本地字母的十几种变形更划算。 ## 这份清单能不能当语言优先级的一个输入项？ 能，但要限定它回答什么。 ## 半小时能查完的三个地方 第一，安卓的区域配置文件，搜你的语言代码，看在不在。第二，Firefox的出货清单，同样搜一遍。第三，Chrome的构建配置，注意区分总清单和只给安卓的那一份。 要查历史版本也简单：把网址里的版本标签换掉就行，安卓换成别的系统版本号，Chrome换成别的版本号。想知道一门语言是哪一年进的，二分几次就能定到具体版本。 搜的时候注意两位和三位代码可能都要试。有些语言在不同清单里用的位数不一样，只搜一种会漏。 三个文件都在公开仓库里，纯文本，浏览器直接打开就能搜。整个过程不需要任何账号和工具。 ## 三档判读 三家都有：这门语言的软件基础设施是完整的，语言协商能正常工作，报表里的语言维度可信，可以按常规做。 这一档还有一个附带的好处：这门语言大概率有可用的拼写检查、断行规则和排序规则，做站的时候不用为这些底层能力单独想办法。 只有安卓有：移动端能用，桌面端的用户会被记错语言，切换入口必须显眼，报表要按设备拆。 这一档是本文最想提醒的一档，因为它最容易被误判成第一档。查的人只查了安卓，看到有就放心了，而实际的坑全在桌面端。 三家都没有：这门语言在软件世界里几乎没有落脚点，别指望任何自动机制帮你识别用户，页面上一切都要写死并显式提供。 这一档还有一个连带后果值得提前想到：这门语言大概率也没有可用的排序规则和断行规则，本站在大小写转换那一篇 (https://zhangwenbao.com/minor-language-case-folding-lowercase-turkish-dotless-i.html)里写过这类底层能力缺失的具体样子。 落到这一档也不等于不能做，只是所有靠自动机制省下来的活都得自己干一遍，成本要按这个前提重新估。 ## 它回答什么，不回答什么 它回答的是“有没有落脚点”，不回答“这门语言有没有需求”，也不回答“翻得完不完整”。 它也不回答用户实际把设备设成了什么。清单里有，不代表用户就选了；很多人拿到手机就没动过语言设置。所以这把尺子给的是上限，不是现状。 本站量过的其他几把尺子——内容存量、译入比例、页面阅读中位数——各自回答另一个问题。这几把尺子给出的排序不一致是常态，比如阅读中位数那一篇 (https://zhangwenbao.com/minor-language-page-reader-median.html)里排在前面的老挝语，在本文这份清单里两家浏览器都没有。尺子给出矛盾结论的时候，不要挑一个信，要去问它们各自在量什么。 ## 什么时候可以不查 做的是三家都有的那62门语言之一，可以跳过。做纯移动端的产品，只查安卓那一份就够。 不过就算跳过，也建议在立项文档里留一句说明为什么跳过，免得后面接手的人重新纠结一遍。 需要查的是这几种情况：目标语言不在常见清单里、报表的语言维度看着不对劲、准备上语言自动识别、或者要给一门没做过的语言写立项材料。 ## 写进立项材料的时候怎么说 建议写成一句带数字的话，别写成结论。比如“这门语言在安卓系统清单里有、在两家主流浏览器里都没有，因此桌面端流量的语言归属不可信，切换入口需要显式设计”。 顺便一提，这类查得出来、复核得了的一手事实，在评审里的分量比任何第三方报告都重，因为它不需要对方相信你，只需要对方愿意点开链接。 这句话既给了事实也给了动作，评审的人不用去查也能判断你是不是编的。 ## 我一开始猜错了哪几条？ 开工前写了八条预期，跑完发现错了七条。 把预期先写下来这个习惯，本站这几批一直在坚持。它的价值不在于证明自己聪明，恰恰相反，在于逼出那些“听起来完全说得通但事实不是这样”的判断。 ## 以为Chrome桌面清单在稳步增长 这是错得最没道理的一条。默认印象是这类清单每年都会加几门，实测2014到2019五年是净减少，从53到51。 为什么会有这种默认印象？大概是因为软件的其他方面确实一直在长——功能在加，平台在加，支持的格式在加。语言这一项被顺手放进了同一个心理模型里。 顺着这条错误往下想会得出“再等两年就有了”的判断，而真实情况是等了五年什么都没等到，然后在2020年一次性给了安卓。 ## 以为两家浏览器是包含关系 以为大的清单会把小的包住，实测两边各有各的独家：Firefox独有22门、Chrome独有10门，而且方向完全相反，一边是欧洲区域语言，一边是亚非大人口语言。 这条错误还有一个副产品：它说明拿一家的清单当代表是不行的。你查了Chrome没有就下结论，会漏掉整整22门在Firefox里活得好好的语言。 这条错得有价值——它逼出了那个机制解释，也就是社区驱动和市场驱动的分野。 ## 以为安卓少的和iOS少的是同一批，这条猜对了 这条猜对了，9门里重合8门。但它差点被自己的统计脚本毁掉：第一版脚本拿Chrome 83去比两份缺失清单，算出交集为零，而零这个结果看起来比八更像一个发现，差一点就写进结论里了。 回头查才发现问题出在版本上：安卓那份缺失清单在80版重构时就被删掉了，83版里它根本不存在，两个空集合当然交集为零。跨版本比两份清单之前，要先确认这两份在同一个版本里都还活着，否则算出来的不是差异，是其中一份的消失。 这条错误也留下一条判据：同一个产品在不同平台上的语言支持可以完全不同步，而这种不同步在任何面向用户的文案里都不会被写出来。 ## 猜对的那一条 唯一猜对的是量级：预估三家清单差2到3倍，实测3.4倍。方向和数量级都对，只是低估了一点。 低估的那一点也有解释：预估的时候心里想的是两家浏览器之间的差距，忘了系统级清单跟应用级清单本来就不是一个量级。 另有一条不在预期里的意外收获：那10门有5个以上地区版本的语言，命中浏览器清单的比例是100%，一个例外都没有。这种干净的100%在这类数据里很少见。 ## 哪些相邻的问题不归这一层管？ 最后划一下边界，免得把不属于这一格的东西塞进来。 划边界的原因不只是为了不越界。这几件事的负责人不一样，混在一起写进一份文档，最后谁也不会认领。 还有一类问题也不在这里：这门语言的内容该怎么写、该找谁审。那属于交付质量，本站在母语审校验收那一篇 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)里单独讲过。 ## 翻译完成度不在这里 清单里有这门语言，只说明有一份语言包在。这份语言包翻了多少、哪些位置先翻、哪些位置留在最后，是另一件事，本文一个字都没量。 本站在别的批次里量过这一层，结论是完成度会随着软件长大而往回掉，跟本文这份清单是两条独立的线。一门语言可以在清单里待着，同时语言包完成度一路下滑。 ## 内容的语言不在这里 界面语言和内容语言是两条线。用户把系统设成英语，不代表他不看本地语言的内容；反过来，系统是本地语言也不代表他只搜本地语言的词。查询语言的切换行为归关键词调研那一侧管。 本站在两个市场关键词表一样落地页不一样那一篇 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)里讲过相近的分层：同一份输入在不同层上会导出不同的动作，把层混了，动作就会互相打架。 ## hreflang与站点结构不在这里 多语言站怎么标注、用什么域名结构、切换器怎么放，全部归国际SEO那一层，跟具体是哪门语言无关。本文只管“这门语言在不在清单里”，这是语言层的事。 一个简单的分界法：把语种换成英语之后这个问题还成立的，归架构层；不成立的，才归语言层。本文这份清单显然属于后者，因为英语从来不会不在清单里。 ## 交给谁 查清单这件事归做市场判断的人，二十分钟。报表口径的调整归数据那一侧。语言切换入口的设计归前端和产品。最容易掉在缝里的是第一步——因为它看起来不像任何一个岗位的活，但不做它后面三件事全都建在错的前提上。 最后给个时间账：三份清单查完二十分钟，报表口径改完半天，切换入口重做一到两天。这三件事的成本差一个数量级，而第一件的成本最低、决定性最强。 ## 常见问题解答 ## 怎么快速查一门语言在不在这三份清单里？ 三份文件都是公开的纯文本。安卓的叫区域配置资源文件，在系统框架仓库里；Firefox的叫出货清单，在浏览器的本地化目录下；Chrome的写在构建配置里，文件名带locales字样。用浏览器打开原始文件，直接搜两位或三位语言代码就行。要注意Chrome那份得分清总清单和只给安卓的那一份，前者会让你高估。 ## 安卓清单里有这门语言，是不是就等于用户能设？ 基本等于，但有两个例外。一是厂商定制系统可能会裁剪清单，中低端机型尤其常见。二是清单里有条目不代表这门语言的字体一定在机器上，字形缺失的时候会显示成方框。所以查完清单之后，最好还是在目标市场找一台真机看一眼。 ## 浏览器清单里没有，用户是不是就完全用不了这门语言？ 不是。用不了的是浏览器自己那套界面，网页内容照样能正常显示和输入。影响主要在两处：一是这个用户发出的语言偏好里没有这门语言，你的自动匹配接不住他；二是浏览器自带的翻译提示可能会误判，把本地语言页面当成需要翻译的外语页面。 ## 这份清单跟一门语言的搜索需求有关系吗？ 相关性很弱，别当同一件事用。清单反映的是有没有技术社区和市场投入，需求反映的是有没有人在搜。两者可以严重背离，最典型的是一门语言有健全的软件支持但商业搜索几乎为零，也有反过来的。判断投入优先级至少要两把尺子一起看。 ## 只有安卓有的那批语言，站该怎么做？ 三件事。第一，语言切换入口做得足够显眼，不能藏在页脚，因为自动识别对这批用户是失效的。第二，报表按设备拆开看，桌面端的语言维度直接放弃，只用地理位置。第三，词表里把拉丁转写那一栏补上，这批用户在桌面端很可能是用拉丁字母输入的。 ## 这个数字过一两年会不会变？ 会变，但变得很慢，而且方向不一定是增加。从公开记录看，主流浏览器每年新增的语言是个位数，同时还会有移除。所以这份清单可以一年查一次，不用盯着。真正要盯的是你自己那门语言有没有出现在移除名单里，那通常意味着当地的技术社区出了状况。 ## 印度的十一门语言分摊在九套书写系统上，做小语种SEO的预算得按后面那个数字算 - URL：https://zhangwenbao.com/india-multilingual-seo-eleven-languages-nine-scripts-priority.html - 分类：小语种SEO - 发布：2020-06-24 | 更新：2026-07-27 - 摘要：印度十一门语言只对应九套书写系统，工程成本按后面这个数算。讲清候选池怎么筛、同簇第二门语言为什么只要三成成本、乌尔都语进名单要多付什么，以及拉丁字母打出来的印地语查询怎么接。 - 关键词：国际化SEO,出海SEO,多语言SEO,小语种SEO > **TLDR**：摘要：印度的语言优先级不能按母语人口从大到小排。十一门有商业价值的语言分摊在九套书写系统上，而字体子集、输入法映射、排序规则、分词这些一次性工程成本按书写系统算，不按语言算。天城文那一簇装着印地语和马拉地语，孟加拉文那一簇装着孟加拉语和阿萨姆语，同簇的第二门语言边际成本只有第一门的三成上下；第十一个席位如果给了乌尔都语，书写系统数从九跳到十，还会多出全站唯一一条从右往左的前端分支。另一半麻烦在输入端：用户搜印地语时大量用拉丁字母硬拼，一个词能拼出五到八种写法，官方那套罗马化方案没人照着打。 > 摘要：印度的语言优先级不能按母语人口从大到小排。十一门有商业价值的语言分摊在九套书写系统上，而字体子集、输入法映射、排序规则、分词这些一次性工程成本按书写系统算，不按语言算。天城文那一簇装着印地语和马拉地语，孟加拉文那一簇装着孟加拉语和阿萨姆语，同簇的第二门语言边际成本只有第一门的三成上下；第十一个席位如果给了乌尔都语，书写系统数从九跳到十，还会多出全站唯一一条从右往左的前端分支。另一半麻烦在输入端：用户搜印地语时大量用拉丁字母硬拼，一个词能拼出五到八种写法，官方那套罗马化方案没人照着打。 ## 为什么按母语人口从大到小排，第一步就排错了？ ## 人口这个数字本身没错，错在它被当成了唯一输入 做印度市场的语言排期，几乎所有人的第一个动作都一样：拉一张母语人口表，从大到小排下去。 这张表本身是可靠的，来源是普查数据，粒度到具体语言，没什么可挑的。 问题出在它只回答了一个问题——有多少人说这门语言，而排期需要回答的是另一个问题：下一笔钱花在哪门语言上，回报除以成本最高。 人口只是分子。分母那一半，人口表里一个字都没写。 分母是什么？是把一门语言从零做到能上线要付的钱和工时。 而这笔钱在印度有一个反常识的结构：它不按语言的门数增长。 把十一门语言的人口数抄进排期表，看上去像是一份数据驱动的决策，实际上只是把一列数字重新排了个序。真正需要算的那一列——每门语言的一次性工程成本——不在人口表上，也不在任何现成报告里，得自己按书写系统数出来。保哥接过一个卖二手教辅书的客户，第一版排期就是照人口表排的，做到第三门语言才发现前两门的字体和输入法资产完全没用上，因为第二门挑错了。 ## 排在第一位的那门语言恰好是成本最低的，容易掩盖后面的账 印地语的母语人口在普查里是5.28亿，远远甩开第二名。 它同时也是印度诸语言里资料最全、工具支持最好、可招人最容易的一门。 所以第一门做印地语，无论按哪套算法都是对的，这一步不会出错。 正因为不会出错，它掩盖了一件事：第一门语言的成本里有一大块是一次性的。 字体子集怎么切、输入法怎么处理、排序规则怎么配、URL怎么编码——这些在第一门语言身上全部要从零解决。 解决完了，它们对某几门语言完全可复用，对另外几门一点用都没有。 于是第二门语言的成本会出现两个截然不同的数字，差距能到三倍。挑对了，前面攒的资产直接接上；挑错了，等于把第一门的路重走一遍。这一步的判据不在人口表上，在书写系统的归组表上，而绝大多数排期表根本没有这一列。 ## 真正决定顺序的是三个乘数 把人口当成起点是对的，把它当成终点就错了。 可用的算法是三个乘数相乘：市场规模的粗估、书写系统的成本档、语料存量的可用档。 第一个乘数是人口乘以线上购买力，粗到只分三档就够用。 第二个乘数是这门语言的书写系统是不是已经做过——做过就是0.3，没做过就是1.0。 第三个乘数是这门语言的网页语料存量，它决定关键词工具能不能给出数字、机器翻译能不能当草稿。 三个乘数里，只有第一个跟人口有关，另外两个都跟语言的技术属性有关。 这套算法的好处不是它精确，而是它把两个隐藏成本显式地写进了表里。做完之后你会看到一些反直觉的排序：某门人口只有印地语七分之一的语言，因为跟印地语共用书写系统，综合得分排到了第二位；而另一门人口更多的语言，因为要新开一套书写系统加一条独立前端分支，被排到了第六位之后。按语言人口排优先级的那笔账 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)在欧洲市场也是这个结论，只是印度把差距放大到了极端。 ## 十一门语言到底是哪十一门，这个数字怎么算出来的？ ## 宪法名单上有二十二门，能进候选池的没那么多 印度宪法附表列了二十二门官方语言，这是最常被引用的数字。 但二十二这个数字对做站的人没有直接用处，它是行政意义上的名单。 里面包含梵语这样几乎没有日常使用者的语言，也包含母语人口只有几十万的语言，粒度对不对得先查印地语在ISO 639-3里的条目 (https://iso639-3.sil.org/code/hin)那种个体语言与宏语言的区分。 做电商站要的是另一个名单：有独立商业市场、有足够网页语料、有可招到的本地人。 按这三条筛下来，稳定进入候选池的是十一门左右。 再往下的语言不是不能做，是要等前面十一门都跑通、并且有具体订单数据支撑之后再说。 需要说清楚的是，十一这个数字不是权威结论，它是筛出来的结果，筛子换了数字就变。如果把标准放到有一千万以上母语者，名单会长到十四门；如果收紧到必须有成熟的分词工具和词典资源，名单会缩到七门。重要的不是记住十一，是记住那三道筛子分别在筛什么。 ## 从二十二砍到十一的三道筛子 第一道筛的是母语人口下限，一般取三千万。 低于这个量级，单独一门语言的销售额通常撑不起本地化的固定成本。 第二道筛的是这门语言的使用者是否集中在一个有独立消费特征的地区。 语言分散在多个邦、且当地用户习惯用另一门语言上网的，先跳过，判断依据可以取印度各语言的使用人口与地域分布 (https://www.ethnologue.com/country/IN/)。 第三道筛的是网页语料存量，判据是这门语言的维基百科条目数与公开语料库覆盖情况。 语料太薄的语言，机器翻译输出质量不可控，关键词工具也基本是零数据。 三道筛子的顺序不能颠倒。先筛人口是因为它最便宜，一张表就能过；先筛语料会把一批人口大但资源少的语言过早排除，而这些语言恰恰是竞争最稀薄、最值得后期做的。关键词工具返回零数据的那些补数办法 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)就是为这批语言准备的。 ## 第十一位的席位一直在两门语言之间摇摆 过了前三道筛子，前十位基本没有争议。 第十一位的竞争者有两个：一门用天城文之外的另一套字母，一门用已经做过的字母。 按人口排，用另一套字母的那门略占优势。 按成本排，用已做过字母的那门优势明显。 这个席位怎么给，直接决定你的书写系统总数是九还是十。 九和十之间不是加一门语言的差别，是加一整条前端分支的差别。 把这个选择留到最后而不是最先做，是本文后面反复出现的一个动作：先把书写系统这一列填满，再回头看语言名单，才能看清哪个席位是便宜的、哪个是昂贵的。名单和成本是同一张表的两列，分开填就会出现批准了预算才发现少算一条分支的情况。 ## 名单定下来之后先别排序，先做书写系统归组 名单确定的下一步不是排序，是归组。 把十一门语言按它们实际使用的书写系统分堆，同一套字母的放一起。 这一步只需要查语言子标签注册表 (https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry)，半小时能做完。 做完之后你手上会有一张簇表，每簇一到两门语言。 簇的数量就是你要付的一次性工程成本的份数。 语言的数量决定内容成本，簇的数量决定工程成本，这两个数字在印度差得很远。 做完归组再排序，排出来的顺序会跟按人口排的顺序有几处明显不同，而这几处不同就是这套方法真正省下的钱。归组这一步的输出物只有一张表，成本几乎为零，却能改掉排期表里最贵的那几个决定，性价比高到有点不像话。 ## 九套书写系统怎么把十一门语言分成簇？ ## 天城文这一簇装着两门语言 天城文的Unicode区块是U+0900，这个区块的逐字符码表 (https://www.unicode.org/charts/PDF/U0900.pdf)里能看到它同时服务印地语和马拉地语。 两门语言共用同一套字母、同一套数字、同一套标点，字体文件可以完全共用。 输入法的键位映射也基本一致，音译输入的引擎不需要重做。 排序规则同源，能用同一份配置带一点参数差异搞定。 差异集中在字母表的边缘：马拉地语常用的一个辅音在印地语里几乎不出现。 还有一处排版差异出在某个辅音的连写形态上，字体里必须带对应的字形才不出错。 所以天城文这一簇的正确说法是共用九成，不是完全一致。字体子集切的时候要把两门语言的常用字符集取并集，而不是切完印地语再拿去装马拉地语——后者会在上线一个月后以某个商品名显示成空框的形式暴露出来，而这个空框只在马拉地语站上出现，印地语站怎么测都是正常的。 ## 孟加拉文这一簇也装着两门，但差异比天城文那簇大 孟加拉文区块是U+0980，孟加拉语和阿萨姆语共用它。 Unicode把它们编在同一个区块里，字体文件同样可以共用。 但阿萨姆语有两个字母的字形跟孟加拉语不同，是实打实的字形差异，不是编码差异。 用孟加拉语字体渲染阿萨姆语文本，字能显示出来，本地读者会觉得别扭。 这种别扭不影响机器抓取，影响的是页面的可信度。 排序规则和分词可以共用，词表完全不能共用。 这一簇给出的经验是：同一个Unicode区块不等于同一套字形要求。判断能不能共用字体，得看这门语言有没有区域性的字形变体，而这件事Unicode区块表上不写，只能问本地设计师或者拿两门语言的样张放一起对比。共用字体是省钱，省到本地读者一眼看出别扭就不叫省钱了。 ## 南部四门语言各占一套，没有任何合并空间 泰米尔语、泰卢固语、卡纳达语、马拉雅拉姆语各有自己的书写系统。 四套字母的Unicode区块分别是U+0B80、U+0C00、U+0C80、U+0D00。 其中两套的字形有历史亲缘关系，但对做站没有任何实际帮助。 字体不能共用，输入法映射不能共用，排序规则不能共用。 四门语言就是四份完整的一次性成本，没有折扣。 它们唯一共用的是非语言字段：支付、物流、尺寸表、商品图。 南部四语这一块是印度语言排期里最贵也最容易被低估的部分。按人口看它们排在中游，看上去可以放到第二批；按书写系统看它们是四份全价，等于第二批的预算要按四倍准备。东南亚三国那种一处都不能共用的情形 (https://zhangwenbao.com/southeast-asia-seo-vietnam-thailand-indonesia-language-layer.html)在印度南部是同一个道理，只是它发生在一个国家内部。 ## 剩下三套各带一门，成本都是全价 古吉拉特文、果鲁穆奇文、奥里亚文各带一门语言。 三套字母的区块分别是U+0A80、U+0A00、U+0B00。 它们跟天城文有共同的历史来源，字形上能看出亲缘。 但对工程来说亲缘等于零，字体和输入法都要单独准备。 把十一门语言的簇数点一遍：天城文2门、孟加拉文2门、其余七套各1门，合计九套。 九套书写系统，十一门语言。工程成本按九算，内容成本按十一算。 书写系统 | 子标签 | Unicode区块 | 装几门语言 | 字体可共用 | 词表可共用 | 天城文 | Deva | U+0900 | 2 | 取并集后可以 | 不可以 | 孟加拉文 | Beng | U+0980 | 2 | 需补字形变体 | 不可以 | 泰米尔文 | Taml | U+0B80 | 1 | — | — | 泰卢固文 | Telu | U+0C00 | 1 | — | — | 卡纳达文 | Knda | U+0C80 | 1 | — | — | 马拉雅拉姆文 | Mlym | U+0D00 | 1 | — | — | 古吉拉特文 | Gujr | U+0A80 | 1 | — | — | 果鲁穆奇文 | Guru | U+0A00 | 1 | — | — | 奥里亚文 | Orya | U+0B00 | 1 | — | — | 这张表最有用的一列是最右边两列。字体可共用意味着一次性成本能摊薄，词表不可共用意味着内容成本一分钱都摊不薄。所以印度的排期表里，工程预算和内容预算的增长曲线形状完全不同：工程预算是台阶状的，每开一套新字母跳一级；内容预算是线性的，每加一门语言涨一份。两条曲线混在一个总数里看，就永远看不清下一步该往哪走。 ## 同一簇里的第二门语言，成本真的只有三分之一吗？ ## 能复用的是字体子集、输入法映射与排序规则 同簇第二门语言能省下的第一笔是字体。 字体子集的工作量集中在切字符集、测渲染、验回退链这三件事上，做过一次就有现成流程。 第二笔是输入端的处理，音译输入的键位映射和候选词逻辑同源。 第三笔是排序规则，区域数据规范里排序那一部分 (https://www.unicode.org/reports/tr35/tr35-collation.html)写得很细，同一套字母的排序配置改几个参数就能用。 第四笔容易被忘：URL编码的处理方式、日志里的解码脚本、后台搜索框的规范化逻辑。 这几件事都是跟字母绑定的，跟语言无关，所以第二门语言完全免费继承。 字体这一块的省钱幅度最大，因为它不只是文件复用，是整套判断经验的复用。第一次给天城文切子集，光是搞清楚哪些组合字形不能被丢掉就要反复试，还得跟本地人确认几轮；第二门语言只需要把新增字符补进已有的字符集清单，一小时的活。小语种字体在首屏那笔KB账 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)讲的是同一套流程，印度这边只是要跑九遍。 ## 不能复用的是词表、分词与商品文案 共用字母的两门语言，词是两套词。 同一个商品品类在印地语和马拉地语里往往是不同的词，即使拼写相近也不能互相替代。 关键词表要重做，分词词典要重训或者换一份，同义词映射要重配。 商品标题、属性名、类目名、说明文案，一个字都搬不动。 母语审校要重新招人，会印地语的人不一定能审马拉地语。 所以内容侧的成本没有任何折扣，第二门语言的内容账等于第一门。 有一个容易踩的坑是拿印地语的词表机器翻译成马拉地语当草稿。这条路在通用文案上勉强能走，在关键词表上完全不能走，因为关键词的价值恰恰在于它是用户实际输入的字符串，翻译出来的是语义正确但没人搜的词。拿词典逐词换出来的关键词表 (https://zhangwenbao.com/keyword-literal-translation-legacy-cost-non-english.html)那笔长期损失，换成机器翻译只是换了个工具，性质一样。 ## 一份逐项对照的成本清单 把成本拆成十项逐个标注，比拍一个笼统的三成要好用得多。 标注的口径统一成三档：全免、半价、全价。 工程侧六项里有五项全免，一项半价。 内容侧四项全部全价，没有例外。 把两侧的工时按实际比例加权，同簇第二门语言落在三成到四成之间。 这个区间比一个准确的数字更有用，因为它提醒你剩下的六到七成是真金白银。 工序 | 属工程还是内容 | 同簇第二门语言的成本 | 字体子集与渲染验证 | 工程 | 全免（只补新增字符） | 输入法与音译输入处理 | 工程 | 全免 | 排序规则配置 | 工程 | 全免 | URL编码与日志解码 | 工程 | 全免 | 后台搜索规范化 | 工程 | 全免 | 分词词典 | 工程偏内容 | 半价 | 关键词表 | 内容 | 全价 | 商品标题与属性 | 内容 | 全价 | 类目与导航文案 | 内容 | 全价 | 母语审校 | 内容 | 全价 | 这张清单还有一个用法：拿它去核对报价。本地化服务商给印度多语言项目报价时，通常按语言门数乘以单价，不区分是不是同簇。手上有这张表，就能把同簇的第二门语言的工程部分单独砍掉，谈判时有具体依据而不是纯砍价。 ## 第十一门语言选乌尔都语，预算表要重画哪几行？ ## 它用的是另一套字母，而且是全站唯一从右往左的一套 乌尔都语的母语人口在普查里超过五千万，按人口它稳稳进前十一。 但它用的是阿拉伯字母的一个变体，跟前面九套里的任何一套都不沾亲。 更要紧的是它的书写方向是从右往左，而其余十门语言全部从左往右。 方向这件事不是一个CSS属性能解决的，它牵动整套版式的镜像逻辑。 把它算进名单，书写系统总数从九变十，而这第十套的成本不是全价，是一倍半。 多出来的半倍就是方向带来的那部分。 这就是本文标题那个意思的完整版：十一门语言分摊在九套书写系统上，预算按九算；一旦第十一个席位给了乌尔都语，分母变成十，而且最后那一份还要乘一点五。人口表上这门语言只是第七行的一个数字，预算表上它是一整条独立分支。 ## 版式、图片、表单三处会同时开裂 版式层面，导航方向、面包屑顺序、分页箭头、进度条方向全部要镜像。 图片层面，带方向暗示的图要重做，箭头图标要翻转，商品图上的文字如果烧进去了就得重出。 表单层面，输入框的文字起始位置、数字与货币的混排、电话号码的对齐都会出问题。 这三处的共同点是它们在从左往右的语言上从来不需要单独测试。 所以团队没有对应的测试用例，也没有对应的验收清单。 第一次做的时候，问题会以零散的界面小毛病的形式陆续冒出来，修完一轮又冒一轮。 更麻烦的是手机端。窄屏上左右两侧的空间本来就紧，镜像之后原本靠右的元素挤到左边，跟返回按钮抢位置。桌面时代验过的那份从右往左清单在手机上有一半不作数 (https://zhangwenbao.com/arabic-rtl-mobile-first-narrow-screen-pitfalls.html)，这条经验在乌尔都语上一样成立，因为印度的移动端占比比阿拉伯语市场还要高。 ## 要不要做它，取决于你能不能承受一整条独立的前端分支 判断标准不是这门语言值不值得做，而是你的前端架构能不能容纳双向布局。 如果模板里已经用了逻辑属性、方向相关的样式都走变量，那增量是可控的。 如果模板里写满了左右方向的硬编码，那这条分支会长期需要单独维护。 单独维护的代价不在第一次上线，在之后每一次改版都要做两遍。 所以这个决定实际上是架构决定，不是市场决定。 可行的折中是把乌尔都语放到第二年，先用一年时间把模板改成方向无关的。 还有一个现实考虑：这门语言的相当一部分使用者在跨境场景里会切到另一门语言上网，实际的搜索需求分布跟人口数并不成正比。把它排在第十一位而不是第七位，理由不只是成本高，也包括这一层。真正的排期动作是先把它标成待定，等前十门跑完拿到真实数据再定，而不是在第一版排期表上就把它删掉。 ## 语料存量这个乘数怎么查，查到之后怎么用？ ## 三个免费入口能把十一门语言的语料量级排出来 第一个入口是各语言维基百科的条目数排名 (https://meta.wikimedia.org/wiki/List_of_Wikipedias)，一张公开列表就能看到全部语言。 第二个入口是公开语料库的覆盖情况，比如印度诸语言单语语料库那份数据集 (https://arxiv.org/abs/2005.00085)就逐语言列了规模。 第三个入口是全网网页的语言占比统计 (https://w3techs.com/technologies/overview/content_language)，粒度粗但能看出量级差。 三个入口给出的排序高度一致，交叉验证一遍就够了。 查完把十一门语言分成三档：语料充足、语料够用、语料稀薄。 这一档位不是学术分类，是给工具选型用的。 做这件事的时间成本大概两小时，产出是一张三档表。它的价值在于提前告诉你哪几门语言的关键词工具会给出可信数字、哪几门会返回零。多语言模型铺到七十多种语言 (https://zhangwenbao.com/multilingual-bert-seventy-languages-minor-language-seo-watershed.html)之后，语料这个变量的重要性反而更突出了，因为模型在低资源语言上的表现跟它见过多少这门语言的文本直接相关。 ## 语料量级直接决定工具能不能用 语料充足的语言，主流关键词工具能给出搜索量区间，虽然精度不高但方向可信。 语料够用的语言，工具能返回词但数据经常是零或者极小值。 语料稀薄的语言，工具基本只能当拼写检查器用。 机器翻译的可用度也跟着这三档走，第三档的输出不能当草稿，只能当术语提示。 分词工具同理，第一档有成熟实现，第三档往往只有学术项目的代码。 把工具的可用度提前标出来，排期时才能把对应的人力补上。 这里有个反直觉的地方：语料稀薄的语言不一定是最难做的那门，反而经常是搜索竞争最稀薄的那门。工具查不到数据的语言，同行也查不到，于是没人做，页面一上去就能排上第一页。难点从选词转移到了验证——你得自己想办法确认这个词有人搜。 ## 语料薄的语言不是不能做，是要换方法做 换的第一个方法是把选词的依据从工具数据换成站内数据。 站内搜索日志、客服对话记录、商品评论里的用词，都是这门语言的真实输入。 第二个方法是拿自动补全当数据源，逐字符敲进去看引擎给什么建议。 第三个方法是从这门语言的本地论坛和社群里扒真实提问的句式。 这三个方法拿不到搜索量，能拿到的是词的存在性与拼写形态。 对语料薄的语言，存在性比搜索量更值钱，因为它决定你会不会写出一个没人用的词。 三个方法都要先有流量才能跑，所以语料薄的语言天然应该排在后面——不是因为它不重要，是因为它需要前面几门语言带来的流量当种子。这一点在排期表上要写成明确的依赖关系，而不是笼统的优先级低。 ## 印度用户其实在用拉丁字母搜印地语，你的关键词表接得住吗？ ## 输入法切换的成本决定了输入方式 做印地语站的人默认用户会用天城文输入，这个默认在很多场景下不成立。 手机上切换输入法要点两三次，切回英文再点两三次。 大量用户的解法是根本不切，直接用英文键盘把印地语的音拼出来。 输入法能把拼出来的音转成天城文，但用户经常不选候选词，直接把拉丁串发出去。 搜索框里进去的就是一串拉丁字母，而它代表的是一个印地语词。 这类查询在电商类词上占比不低，尤其是短词和口语词。 这件事的后果是：你的关键词表如果只有天城文，那它只覆盖了一半的查询。另一半用拉丁字母写的同义查询，页面上一个字都没有，引擎只能靠语义匹配去猜，而在口语化的短词上它猜得并不好。这跟希腊语市场的情形同源，越把页面写得规范就越接不住拉丁字母打出来的那半边搜索 (https://zhangwenbao.com/greek-seo-greeklish-latin-transliteration-coverage.html)，印度只是把这个现象的规模放大了几十倍。 ## 同一个词的拉丁拼法能有五到八种 希腊语的拉丁化有一套约定俗成的字母对应关系，虽然不统一但收敛。 印度的拉丁化不收敛，因为它拼的是音，而音怎么用英文字母写没有共识。 一个意思是买的动词，能写成kharidna、kharidana、khareedna、kharidne几种形态。 一个意思是鞋的名词，词典里的原形只有一个 (https://hi.wiktionary.org/wiki/%E0%A4%9C%E0%A5%82%E0%A4%A4%E0%A4%BE)，用户却能写成jute、joote、jutte，还有人写juta。 长元音写成一个字母还是两个字母，送气音要不要带h，词尾的元音留不留，每一处都是分歧点。 把这些排列组合起来，常用词的拉丁写法轻松上五种。 词的含义 | 常见拉丁拼法 | 分歧出在哪 | 买 | kharidna / kharidana / khareedna / kharidne | 长元音写法、词尾变形 | 鞋 | jute / joote / jutte / juta | 元音双写、词尾元音 | 便宜 | sasta / sastaa / sasata | 元音长度 | 免费送货 | free delivery / muft delivery | 混入英语词 | 最后一行是印度市场特有的现象：一个短语里一半是英语词一半是本地词，而且这种混合是稳定的、可预测的。像送货、退货、折扣这类电商词，用户经常直接用英语词，反而是商品名和形容词用本地语言。所以关键词表里必须有混合词这一类，纯本地语言的词表会漏掉相当一部分真实查询。 ## 两套写法要不要都做，看的是页面类型 不是所有页面都需要覆盖拉丁写法，判据是这个页面靠哪种查询进来。 商品详情页和类目页的查询里拉丁写法占比高，值得覆盖。 内容页和帮助文档的查询以天城文为主，因为用户在这些场景下更愿意认真打字。 覆盖的方式不是建两套页面，是在同一个页面里让两种写法都出现。 天城文放标题和正文，拉丁写法放在商品别名、常见问法、页内搜索提示这些位置。 这样一个URL能同时接住两种查询，也不会产生重复内容。 需要说清的是别名的写法要挑，不是把五到八种全部堆上去。挑两到三种最主流的，剩下的靠引擎的模糊匹配兜。全部堆上去会让页面读起来像关键词列表，本地用户一看就觉得这站不正经，而且这种堆砌带来的收益远小于它损失的信任。 ## 拉丁变体的收集只能靠三个来源 第一个来源是站内搜索日志，它记录的就是用户实际敲进去的字符串。 把日志里的拉丁串按频次排序，前二十条基本覆盖主流写法。 第二个来源是搜索框的自动补全，逐字符敲拉丁前缀看引擎给什么建议。 第三个来源是商品评论和客服记录里用户自己写的词。 三个来源的共同优点是它们都是真人写的，不是转写规则生成的。 用规则生成的变体清单会包含大量没人用的写法，反而把噪音带进词表。 收集这件事的最佳时机是站点已经有一点自然流量之后，所以印度市场的正确节奏是先用天城文上线一批页面，跑两个月拿到日志，再回头补拉丁别名。反过来先猜变体再上线，猜出来的清单跟真实日志的重合度大概只有一半。 ## 一套官方罗马化系统摆在那儿，为什么没人按它打字？ ## 那套系统是给地名标注设计的 联合国地名标准化机构在1972年批准了一套印地语罗马化方案 (https://www.eki.ee/wgrs/rom1_hi.htm)，至今可查。 它规定了每个天城文字母对应的拉丁字母，包括附加符号的用法。 这套方案的设计目标是地图、护照、地名录的标注一致性。 它要求的是可逆——从拉丁串能唯一还原回原文。 为了可逆，它用了带附加符号的字母，而这些符号在普通键盘上打不出来。 用户不可能为了搜一双鞋去插入一个带点的字母。 所以这套官方系统和用户的实际输入是两个互不相交的世界。它有用，但用处在别处：当你需要给一个词定一个稳定的拉丁形态，比如做URL的slug、做数据库的排序键、做日志里的规范化形态时，照着它做能保证不同人做出来的结果一致。URL用本地字母还是拉丁转写 (https://zhangwenbao.com/minor-language-url-native-script-vs-latin-transliteration.html)那个决定就该照它做，关键词表则完全不该照它做。 ## 用户拼的是自己听到的音，不是字母的对应关系 官方系统做的是字母到字母的映射，用户做的是音到字母的猜测。 同一个音，一个人写成oo，另一个人写成u，第三个人写成ou。 而且用户参照的是英语的拼写习惯，而英语本身的拼写就不规则。 受教育程度、年龄、母语方言都会影响一个人的拼法偏好。 所以拼法分布不是随机噪音，是有结构的，头部几种写法占大多数。 这也是为什么挑两三种主流写法就够，剩下的是长尾。 这里有个实用推论：拼法的头部集中度可以拿来判断一个词值不值得单独覆盖。如果一个词的前两种拼法占了日志里八成以上，那覆盖这两种基本就够；如果前五种加起来才六成，说明这个词的拼法极度分散，与其覆盖变体不如在页面上多写一段自然的本地语言描述，让语义匹配去兜。 ## 离散度这个指标怎么算，算出来干什么 离散度的算法很简单：一个词在日志里出现的不同拉丁拼法数量，除以该词的总查询次数取对数后的档位。 实际用起来不必这么正式，数一下不同拼法的个数就够。 一到二种叫收敛，三到四种叫中等，五种以上叫分散。 收敛的词直接把拼法写进页面别名。 中等的词写前两种，剩下的靠正文里的自然出现。 分散的词不做别名，改成在正文里把这个概念用几种说法都提一遍。 这个指标的真正价值是它把一个看起来无边无际的问题变成了三档动作。印度多语言项目最容易失控的地方就是变体覆盖，一旦开始逐个词收集拼法，工作量能吞掉整个季度。用离散度分档之后，绝大多数词落在收敛和中等两档，需要特殊处理的分散词通常不到一成。 ## 先上英语版兜住印度市场，会漏掉哪些品类词？ ## 印度英语的品类词跟美式英语不是一套 先上英语版这个动作本身是对的，印度的英语搜索量很大。 错的是拿美国站的英语内容直接搬过来当印度英语版。 蔬菜类里茄子叫brinjal不叫eggplant，甜椒叫capsicum不叫bell pepper，秋葵叫ladyfinger不叫okra。 交通工具里两轮车统称two-wheeler，小巴叫tempo traveller。 还有一个动词只有印度英语里有：prepone，意思是把时间往前挪。 这些词不是俚语，是印度英语的标准用法，出现在正规媒体和商品页上。 品类词错了的后果比语法错了严重得多。语法别扭用户还能看懂，品类词不对等于这个词在你的站上不存在，用户搜brinjal你的页面写着eggplant，语义匹配未必接得住，尤其是当本地竞争对手页面上明明白白写着brinjal的时候。这跟西班牙人和墨西哥人搜的不是一个词 (https://zhangwenbao.com/spanish-seo-es-es-latam-keyword-divergence.html)是同一类问题，只是这次分叉发生在英语内部。 ## 数量单位与价格表述也是本地的 印度英语里的大数用lakh和crore，分别是十万和一千万。 价格页面写1,50,000这种分节方式，逗号位置跟国际习惯不同。 重量和尺寸沿用公制，但服装尺码有本地的号型体系。 这些东西写错不会影响收录，会影响用户对价格的第一判断。 一个标着数字的价格如果分节方式不对，本地用户要多看一眼才能确认量级。 多看一眼在移动端就是一次犹豫，犹豫的下一步经常是返回。 数字格式这类字段有个规矩：页面上按本地习惯写，结构化数据里要还原成机器格式。这两个方向正好相反，正文越本地化越好而标记里要反着写回国际格式 (https://zhangwenbao.com/minor-language-structured-data-inlanguage-locale-schema.html)那篇专讲这件事，印度英语版是这条规则最容易被忽略的适用对象，因为它长得像英语，团队根本不会想到它需要本地化处理。 ## 英语版该定位成什么，别当成兜底 英语版的正确定位是十一门语言之外的第十二个市场，不是它们的兜底。 它有自己的用户群：城市、高教育、跨邦流动、多语言切换。 它有自己的品类偏好：高客单、进口商品、专业设备。 它也有自己的关键词表，跟美国站的英语词表重合度大概七成。 把它当成兜底会导致一个具体后果：本地语言版本被无限延后。 因为英语版能拿到流量，看上去印度市场已经在做了。 保哥常跟客户说这句话：英语版拿到的流量是印度市场的天花板下面那一层，不是全部。它的增长会在某个点停住，而停住的原因不是优化没做到位，是剩下的需求根本不用英语表达。这个点通常出现在第二年，届时再从零启动本地语言，前面攒的域名权重能帮上忙，但语言侧的一次性成本一分钱都没省。 ## 十一门语言的落地顺序怎么排成一张可执行的排期表？ ## 第一门语言吃掉的是全部一次性成本 第一门做印地语，这一步没有争议。 它要解决的清单包括字体子集、输入法处理、URL编码策略、日志解码、排序规则、分词方案。 还要解决流程侧的：本地审校怎么找、怎么验收、术语表怎么维护。 这批工作里工程部分对同簇语言可复用，流程部分对全部语言可复用。 所以第一门的实际耗时通常是后面每一门的两到三倍。 排期表上给它留足时间，别按平均值排。 把第一门当成基础设施建设期来排，而不是当成一门语言的上线来排，后面的节奏才对得上。这个阶段最该多花时间的是流程而不是内容：验收清单、术语表格式、审校员的工作说明，这三样东西定得糙，后面十门语言都要跟着糙一遍。母语者说读着自然不能当验收判据 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)那套清单在这一步就该定下来。 ## 第二门按簇挑，不按人口挑 第二门语言的正确选法是从天城文这一簇里挑，也就是马拉地语。 按人口它排第三，按成本它是最便宜的一门。 做完它，天城文这一簇的资产就完全摊开了，而且验证了同簇复用这条路走得通。 如果第二门直接跳到孟加拉语，那等于同时开新字母和验流程，两件不确定的事叠在一起。 先做便宜的那门，是为了在成本可控的情况下把流程跑第二遍。 第二遍跑通了，后面开新字母才有底气。 这里的逻辑跟软件上线灰度是一个道理：第二个用例要挑跟第一个最像的，因为它的作用是验证流程可复制，不是验证方法在极端情形下也成立。挑一门跨字母的语言当第二门，一旦出问题你分不清是流程有毛病还是新字母有毛病。 ## 三到六门进入拼装期，成本曲线开始平 第三到第六门可以按市场规模乘购买力排，这时候成本差异已经不是主要变量。 通常的顺序是孟加拉语、泰米尔语、泰卢固语、古吉拉特语这一带。 每开一门新字母要留出字体和渲染的验证时间，但流程已经是现成的。 这个阶段的瓶颈从工程转到了人：能审这门语言的人好不好找。 人的可得性有时会直接改变顺序，找不到审校员的语言只能往后放。 把这一条写进排期表的假设栏里，别等到要上线才发现招不到人。 拼装期的效率提升是最明显的，第一门可能要三个月，到第五门通常一个月能上线一批核心页面。这个加速不是团队变熟练了那么简单，主要来自资产复用：术语表格式、验收清单、渲染测试用例、日志脚本，全都是现成的，新语言只需要往里填内容。 ## 什么时候该停下来 停下来的判据不是语言做完了，是最近两门语言的投入产出比掉到了阈值以下。 阈值怎么定各家不同，常见的做法是拿英语版的单位流量成本当基准的三倍。 连续两门语言超过这个阈值，就该停下来做深度而不是继续加语言。 做深度的意思是回头把已上线的语言的页面覆盖率、内链、结构化数据补齐。 加语言是横向扩张，补深度是纵向挖掘，后者的边际回报在某个点会反超。 反超的时间点通常出现在六到八门语言之后。 还有一种该停的信号更容易识别：本地审校的排队时间开始变长，翻译稿在队列里积压。这说明产能瓶颈已经从预算转到了人，这时候再加语言只会让每门语言的质量一起下滑，而质量下滑在小语种上的代价格外高，因为你自己看不出来。 ## 常见问题解答 ## 只做英语能不能覆盖印度市场？ 能覆盖一部分，通常是城市高教育人群和高客单品类，但它是一个有天花板的子市场，不是全市场的代理。而且英语版本身也要本地化：品类词要换成印度英语的说法，大数要用当地的计数单位，价格分节要按本地习惯。拿美国站的英语页面直接搬过来，会在品类词这一层大面积失配，用户搜的那个词你的页面上根本没有。正确的定位是把英语当成第十二个语言市场来做，有独立的词表和独立的品类策略。 ## 印地语做完了，第二门该选马拉地语还是孟加拉语？ 先做马拉地语。它跟印地语共用天城文，字体子集、输入法处理、排序规则、URL编码这几项工程成本可以直接继承，综合成本大概是印地语的三到四成；孟加拉语要开一套新字母，成本接近全价。按人口孟加拉语更大，但第二门语言的战略作用是验证同簇复用这条路走得通，挑最便宜的那门跑第二遍流程，风险最低。孟加拉语放到第三门，那时候流程已经稳定，新字母带来的不确定性单独暴露，好排查。 ## 印地语的关键词工具有数据吗，够用吗？ 印地语在印度诸语言里资料最全，主流工具能给出搜索量区间，方向可信但精度一般。真正会返回大量零值的是南部四语之外的那几门和奥里亚语、阿萨姆语这一带。工具给零不代表没需求，只代表工具的语料里没有这门语言的足量样本。这种情况下改用站内搜索日志、自动补全逐字符探测、本地社群的真实提问三个来源补数据，能拿到词的存在性和主流拼写形态，拿不到搜索量。对语料薄的语言，存在性其实比搜索量更值钱。 ## 拉丁字母拼出来的印地语查询，要不要单独建页面？ 不要。同一个商品的两种查询写法背后是同一个需求，拆成两个URL会制造重复内容，也会把外链和内链的权重分散到两处。正确做法是在同一个页面里让两种写法都出现：天城文放标题、H2、正文主体，拉丁写法放在商品别名、常见问法区块、页内搜索提示这些位置。拉丁写法挑两到三种最主流的就够，别把五到八种全堆上去，堆上去会让页面读起来像词表，本地用户对这种页面的信任度很低。 ## 十一门语言要用十一套域名，还是同一个域名下开目录？ 这个问题属于架构层，跟语言本身无关，判据是团队的运维能力、外链资源的集中度、以及各语言市场是否需要独立的品牌形象。多语言站的域名结构与hreflang落地 (https://zhangwenbao.com/international-seo-hreflang-complete-guide.html)那份清单能直接照着走，印度这边没有额外的特殊性。语言层要操心的是另外几件事：每个语言版本的语言标签要带对书写系统子标签、内链的锚文本要用对应语言、以及别让同一门语言的两种书写形态互相当成不同语言声明。 ## 南部那四门语言能不能合成一套内容？ 不能，一个字都不能。四门语言分属同一语系但互不相通，四套书写系统之间没有任何复用空间，字体、输入法、排序、词表全部独立。它们唯一能共用的是非语言字段：支付方式、物流选项、尺寸表、商品图。所以在预算表上，这四门语言应该按四份全价计，而不是按一个南部市场计。把它们打包成一个南部预算是印度项目里最常见的低估来源，也是第二批预算最容易超支的地方。 ## 印度英语页面和美国英语页面会不会互相抢排名？ 会有一点，但这属于同语言多地区的架构问题，用地区定向的语言标签声明清楚就能大幅缓解，判据和落地步骤跟印度无关。语言层上要注意的反而是内容差异化：如果两个版本的品类词、单位、价格表述、货运说明全都不同，那它们实际上是两份内容，抢不起来；如果只改了货币符号，那它们确实是重复内容，声明得再规范也解决不了根本问题。差异化做够了，声明只是收尾动作。 ## 权威参考资料 ## 小语种内容是不是译过来的，正文里量不出来，能认出来的痕迹全长在壳上 - URL：https://zhangwenbao.com/minor-language-translation-trace-shell-not-text.html - 分类：小语种SEO - 发布：2020-05-14 | 更新：2020-06-30 - 摘要：9门语言955个样本标定六个翻译痕迹特征：最高判别力65.9%，方向随语言翻转。真正稳定的痕迹在页面的壳上，56家商业站里语言声明写对的只有35.3%。 - 关键词：技术SEO,竞品分析,多语言SEO,小语种SEO > **TLDR**：摘要：拿一批已经知道答案的样本做标定——9门语言各取译过来的和本地写的两组页面，逐条量六个正文特征，看哪个能把两组分开。结果是没有一个分得开。判别力最好的两个是首版体量和外链条数，各65.9%，跟抛硬币差不了太多；更糟的是方向不稳定：首版体量在缅甸语上译文大11.95倍，在格鲁吉亚语上反过来只有0.68倍；拉丁字母残留在蒙古语上5.58倍，在僧伽罗语上0.43倍；红链率四门语言全部是译文更低，跟直觉正好相反，原因是翻译工具会自动处理链接。换句话说你以为在量“是不是搬来的”，量到的其实是“用什么工具搬的”。稳定的痕迹不在正文里，在页面的壳上：2019年8个市场56家商业站的快照里，确实有本地语言内容的17家中，页面语言声明写对的只有6家。本文给出六个特征的完整标定表、三处壳上的硬信号，以及一套半天能跑完的判定流程。 > 摘要：拿一批已经知道答案的样本做标定——9门语言各取译过来的和本地写的两组页面，逐条量六个正文特征，看哪个能把两组分开。结果是没有一个分得开。判别力最好的两个是首版体量和外链条数，各65.9%，跟抛硬币差不了太多；更糟的是方向不稳定：首版体量在缅甸语上译文大11.95倍，在格鲁吉亚语上反过来只有0.68倍；拉丁字母残留在蒙古语上5.58倍，在僧伽罗语上0.43倍；红链率四门语言全部是译文更低，跟直觉正好相反，原因是翻译工具会自动处理链接。换句话说你以为在量“是不是搬来的”，量到的其实是“用什么工具搬的”。稳定的痕迹不在正文里，在页面的壳上：2019年8个市场56家商业站的快照里，确实有本地语言内容的17家中，页面语言声明写对的只有6家。本文给出六个特征的完整标定表、三处壳上的硬信号，以及一套半天能跑完的判定流程。 上一篇量了一门语言的公共内容里有多少是从别处搬来的，用的是维基媒体那个会自报家门的标记。那套办法有个前提：样本自己承认。 真实市场上没有这个前提。对手的站不会告诉你哪些页面是翻译的，所以只能从页面上找痕迹。 直觉上痕迹应该不难找。译文读着别扭、专有名词没换、链接指向不存在的页面、上线之后就没人管——这几条几乎是共识，我自己也讲过好几年，讲的时候还挺理直气壮。 这次决定把它们一条条量一遍。手上正好有一批带答案的样本，标定完就知道这些直觉值多少钱。 先说结论：值不了多少钱。但量完之后我知道了该去哪儿找，这个收获比原来想要的那个大。 ## 怎么用带答案的样本给一个判断方法打分？ ## 先有正负样本，才谈得上判别力 一个判定方法好不好，不能靠讲道理，得拿已知答案的样本试。试的方式是给它一批确定是译文的、一批确定不是的，看它能分对多少。 这批带答案的样本来自维基媒体。2019年新建的条目里，带官方翻译工具 (https://www.mediawiki.org/wiki/Content_translation)标记的算正样本，不带任何标记的算负样本。这个工具在建条目的时候会自动打标记，编辑者想躲也躲不掉。 正样本的答案很硬——标记是工具自动打的，不可能有假。负样本弱一点，只能说“没用那个工具”，理论上可能是手工翻的。这个瑕疵我后面会单独说。 9门语言各取60条正样本、60条负样本，样本池不够的按实际数量取。合计415条正样本、540条负样本。 ## 选哪9门语言，为什么 选语言有两条考虑。一是要有足够的正样本，译文条数太少的语言标定不出东西；二是书写系统要有对照，全挑非拉丁的会得出一个只在非拉丁语言上成立的结论。 最后定的是缅甸语、高棉语、蒙古语、泰米尔语、尼泊尔语、僧伽罗语、格鲁吉亚语、希腊语，加上越南语。 越南语是故意放进来的。它用拉丁字母，译入率又是全表最高的47.43%，正好用来验证那些依赖“非拉丁书写系统”的特征在拉丁语言上还剩多少。越南语的声调符号那一层 (https://zhangwenbao.com/vietnamese-seo-tone-marks-syllable-spacing-keyword.html)虽然复杂，但字母本身还是拉丁的，字符统计分不出来。 高棉语和蒙古语的正样本只有10条和16条，比别的语言薄得多，因为这两门语言2019年一共才有14条和29条译入条目。这两门的结论我只当参考，不进主要判断。 剩下七门每门都是60对60，够用。东南亚那几个市场 (https://zhangwenbao.com/southeast-asia-seo-vietnam-thailand-indonesia-language-layer.html)在这批语言里占了四个，算是本站写得比较熟的一片，用它们做标定我心里有底。 ## 正样本很硬，负样本有瑕疵 这批样本的可信度不对称，这一点得先摆出来。 正样本是工具自动标的，不存在误标。一条记录带着那个标记，就一定是用那个工具建的，这一侧的答案是确定的。 负样本弱得多。它的定义只是“没带任何标记”，理论上完全可能是有人把英文页面复制到编辑框里手工改改就发了。这种情况在数据上看不出来。 所以严格说，这次标定的是“用工具译的”和“其余全部”之间的差别，不是“译的”和“原创的”之间的差别。负样本里混进译文，只会让两组更像，也就是让判别力被低估。结论是分不开，那么这个瑕疵不会救回这个结论。 ## 量哪六个特征 六个特征都挑了从外面看得见的：首版的字节数、拉丁字母在全部字母里的占比、内链条数、引用标记数、红链率、以及首版之后到截断日为止被改过几次。 选它们的理由是每一个都对应一条常见的直觉。首版字节大对应“一次性粘贴”，拉丁占比高对应“专名没跟着译”，红链率高对应“带着源语言的链接结构”，修订次数少对应“搬进来就没人管”。 另外两个是内链条数和引用标记数，对应的直觉是“译文继承了源语言那套密集的交叉引用”。这一条我信心最低，但既然一起量了就一起报。 六个数全部从首版的原始文本 (https://www.mediawiki.org/wiki/API:Revisions)上量，不看现在的版本。看现在的版本等于把后来所有人的修改也算进来，那就不是在量“它被建出来的时候什么样”了。 字符统计只算字母，数字和标点一律不参与。这一步不做，各语言标点习惯的差异会直接混进拉丁占比里，而那个差异跟内容来源没有半点关系。 ## 怎么算判别力 判别力的算法是给每个特征扫一遍可能的阈值，每个阈值试两个方向，取分对比例最高的那一组。 这个做法对特征相当宽容——阈值是知道答案之后反过来挑的，方向也是。真实使用时你没有这两样，只会比这个数更差。 还要有个基线做参照。正负样本415比540，什么都不做、一律判成“本地写的”，正确率就是56.5%。任何特征都得跟这个数比，不能跟50%比。 ## 红链这个数只能算下限 红链是指内链指向的目标页面不存在。麻烦在于我只能查“今天还不存在”，2019年不存在、后来被人补上的那些查不出来。 所以红链率是个下限。好在正负样本用的是同一把尺子、同一个时点，两边低估的方向一致，比较仍然成立。 这类右侧删失的问题在历史数据上几乎躲不开。能做的是把它写在明处，并且确保它不会单方向地帮某一组说话。 顺便说一句，删失这件事在小语种上比在大语种上轻，因为小语种的红链被补上的概率本来就低——没那么多人在填坑。所以这个下限在本文关心的那几门语言上，离真值反而更近。 ## 六个特征在9门语言上的表现是什么样？ ## 合并起来看，方向都对 先看把9门语言合在一起的中位数。译文首版3237字节，本地写的1660字节，1.95倍。拉丁占比0.426对0.200，2.13倍。截断前编辑者数2人对1人。 光看这几个数，直觉基本被证实了：译文更大、拉丁残留更多、经手的人更多。 我当时挺高兴，觉得可以直接进入“怎么用”的部分了。 然后拆开逐语言看了一眼，前面那份高兴就没了。 这一步本来是可做可不做的。合并中位数已经能撑起一篇文章，方向也漂亮。我拆开纯粹是因为上一批吃过一次亏——那次算出来的方向刚好符合预期，换个变量重算就翻了。 ## 拆开之后，方向开始翻 语言 | 首版字节 | 拉丁占比 | 内链条数 | 截断前修订数 | 缅甸语 | 11.95 | 3.18 | 1.67 | 3.00 | 高棉语 | 3.48 | 3.72 | 6.00 | 1.50 | 蒙古语 | 2.79 | 5.58 | 2.50 | 0.75 | 泰米尔语 | 2.13 | 0.72 | 1.27 | 1.00 | 越南语 | 2.12 | 1.00 | 0.71 | 0.75 | 尼泊尔语 | 1.23 | 1.16 | 1.50 | 1.00 | 希腊语 | 0.81 | 1.54 | 0.83 | 1.00 | 僧伽罗语 | 0.86 | 0.43 | 0.50 | 2.00 | 格鲁吉亚语 | 0.68 | 2.77 | 0.12 | 2.25 | 表里的数是译文中位数除以本地写的中位数。大于1表示译文更大，小于1表示反过来。 首版字节这一列：6门语言译文更大，3门更小。缅甸语11.95倍，格鲁吉亚语0.68倍。同一把尺子，两头都指得出去。 拉丁占比：6门更高，2门更低，1门打平。蒙古语5.58倍，僧伽罗语0.43倍。 内链条数更散：5门更多，4门更少，格鲁吉亚语只有0.12倍——译文的内链条数只有本地写的八分之一。 截断前修订数这一列也不齐：4门译文更多，2门更少，3门打平。这条对应的是“搬进来就没人管”那个直觉，实测它连方向都定不下来。 把四列放一起看，一个规律都排不出来。不是某一门语言特别怪，是每一门都按自己的方式怪。 ## 红链率的方向是齐的，但齐在反方向 六个特征里只有红链率方向一致：能比的4门语言全部是译文的红链率更低。缅甸语0.38倍、越南语0.37倍，希腊语和僧伽罗语的译文中位数直接是0。 这跟直觉正好相反。我原本的预期是译文红链率至少高2倍，因为译文会带着源语言的链接结构过来，落到本地语言里全是空的。 实际发生的事是：翻译工具会自己处理链接。它把源语言里的内链逐个查一遍，能对上本地已有条目的就映射过去，对不上的直接把链接去掉，只留文字。 所以译文的红链更少，不是因为译得好，是因为工具替它把红链清干净了。这跟内容质量没关系，跟谁写的也没关系，纯粹是一段代码的默认行为。 这条发现值一整篇文章的钱，虽然它把我原来想写的那篇否掉了。锚文本在屈折语上的形态问题 (https://zhangwenbao.com/minor-language-internal-link-anchor-inflection-variants.html)我写过，那时候我默认链接的目标是稳定的、变的只是锚文字；这次才发现连目标都会被工具动。 ## 引用标记数是唯一一个没翻车的 六个里有一个表现相对稳定：引用标记数，也就是正文里挂了多少条出处。能比的三门语言里两门是译文更多，一门打平，没有反向。 原因不难猜：源语言的条目本来就带着出处，翻译的时候这些标记会跟着过来，而本地随手写的短条目往往一条出处都不挂。 但它的判别力也只有63.9%，而且能比的语言只有三门——另外六门的负样本中位数是0，除不出比值。一个在多数样本上分母为零的特征，稳定得没有意义。 ## 这意味着你量到的不是你以为的那个东西 把这一条想透，整篇的结论就变了。 红链率这个特征，反映的不是“这段内容是不是从别的语言来的”，而是“搬它的那个工具会不会处理链接”。换一个不处理链接的工具，或者干脆手工复制粘贴，同一个特征就会翻个方向。 你以为在量内容的来源，实际量到的是搬运的手法。这两件事在同一批样本上碰巧相关，换一批样本就不相关了。 其余五个特征多少都有这个毛病。首版字节大，是因为这个工具一次性提交整篇；换成边译边存的做法，首版就小。拉丁占比高，是因为工具会保留没译的模板参数；换个工具可能就清掉了。 推到商业站上，这个道理更狠。同一家公司先后换过三套翻译流程，那么它站上三批页面的“痕迹”长得完全不一样。你按一批标定出来的规则去判另一批，会得到一堆假阴性。 ## 把这六个特征当分类器用，能对多少？ ## 最好的两个也只有65.9% 光看倍数不够，还得算判别力。做法是给每个特征找一条最优阈值，让分对的比例最高，然后看这个最高值有多高。 首版字节65.9%，外链条数65.9%，引用标记数63.9%，截断前编辑者数62.0%，拉丁占比60.8%，红链率60.0%，内链条数58.4%。 正负样本的比例是415比540，全部猜“本地写的”就能拿到56.5%。也就是说，最好的特征比闭着眼睛猜只强了9.4个百分点。 而且这还是在阈值按结果反过来挑的情况下——真实使用时你不知道最优阈值在哪，只会更差。 把这几个数摆在一起看还有个细节：最好的两个特征里，外链条数跟首版字节其实高度相关（内容多的页面外链自然多），所以它们不是两条独立证据，是同一条证据的两种说法。 ## 为什么合起来也救不回来 常见的下一步是把几个特征组合起来投票。但组合的前提是各个特征的方向在样本内一致，否则组合只会把噪声叠加。 这批数据里，首版字节在3门语言上反向、拉丁占比在2门上反向、内链条数在4门上反向。组合的时候，你得先知道当前这门语言上每个特征该往哪边算，而这个恰恰是要靠标定才知道的。 换句话说，只要你能标定，就不需要组合；不能标定，组合也没用。 所以我没有做组合模型。做出来会有个好看的数字，但那个数字来自过拟合，换一门语言就掉下去。 ## 拉丁残留这把尺子在拉丁语言上直接归零 越南语是个干净的演示。它用拉丁字母，所以译文和本地写的拉丁占比都是1.000，比值恰好是1.00。 这条特征在越南语上不是判别力弱，是完全没有信息量，等于一根没有刻度的尺子。 更麻烦的是泰米尔语：译文0.363，本地写的0.504，比值0.72，方向是反的。泰米尔语的本地条目里有大量矿物名和化学名，那些名字本来就带拉丁写法，反而比译文更多。 所以这条尺子有三种状态：好使、不好使、和反着使。你在用之前分不清自己碰上的是哪一种，只有事后拿答案对一遍才知道。 这一点跟编码遗留问题 (https://zhangwenbao.com/cyrillic-encoding-legacy-windows1251-utf8-indexing-cost.html)有点像：都是看起来通用的技术判断，一落到具体语言上就得重新验一遍前提。 ## 换个语言就得重新标定一次 把上面这些合起来，得到的操作结论很朴素：这些特征不是不能用，是不能跨语言用。 在缅甸语上，首版体量11.95倍，拿它当判据相当好使；把同一条判据搬到格鲁吉亚语上，它会把方向指反。这不是精度问题，是符号问题。 而要在一门新语言上知道该往哪边算，你得先在这门语言上拿到一批带答案的样本。能拿到带答案的样本，就已经不需要这些特征了。这是个死结。 所以我的结论不是“这些特征无效”，而是“在你实际会遇到的场景里，它们用不上”。这两句话听着像，做起来差别很大。 ## 负样本不纯，这一层要说清楚 负样本是“没打任何标记的新建页”，理论上可能混进手工翻译的内容。我查了一遍建者的分布，情况比预想的还特别。 缅甸语的60条负样本里有57条出自同一个账号，中位字节515，标题大多是日本铁路车站；僧伽罗语60条里32条出自一个账号，中位字节276。 这不是机器人，是真人在做半自动的批量小条目。所谓“本地写的”，在好几门语言上其实是“本地某一两个人批量建的短条目”。缅甸语那个11.95倍，一大半是这个原因。 但这个瑕疵不改变主结论。方向翻转发生在僧伽罗语、格鲁吉亚语、希腊语三门上，其中后两门的负样本集中度并不高——格鲁吉亚语60条负样本出自31个账号，最高产的只占13%。 而且商业站上的情况也一样：对手站里的“本地写的内容”，本来就混着大量程序化生成的模板页。这批页面有没有人读 (https://zhangwenbao.com/minor-language-page-reader-median.html)是另一个问题，但它们确实会以“本地内容”的身份参与你的每一次比较。 ## 那些从外面看得见的痕迹，到底还剩下什么？ ## 换个地方找：不看正文，看壳 正文这条路走到这儿就断了。但断的只是正文这一层。 回头看红链率那个反转，它给出的其实是一条正面线索：特征之所以不稳定，是因为它反映的是搬运工具的行为。那么反过来，如果一个痕迹反映的是模板的来历，它就应该跨语言稳定——因为模板的来历跟语言无关。 页面的壳正好是这样一层东西：语言声明、语言切换、多语言标注。它们由模板决定，不经过译员的手，也不随书写系统变。 所以我把同一个问题挪到了壳上，换了一批真实的商业站来验。这一步顺带解决了另一个疑虑：前面那批样本毕竟是维基，商业站上到底什么样，总得亲眼看看。 ## 什么样的痕迹才可能跨语言稳定 换地方之前先想清楚一个判据，不然只是换个地方碰运气。 正文层的特征之所以不稳定，是因为它们全都由“谁在搬、用什么搬”决定。搬运的人和工具每门语言都不一样，特征当然跟着变。 那么稳定的痕迹应该满足一个条件：它由模板决定，而不是由内容决定。模板是一套代码，代码不管你写的是哪门语言，它在40个语言版本上的行为是一样的。 按这个判据筛一遍，剩下三样东西：页面开头那行语言声明、页面上的语言切换入口、以及多语言标注。这三样都写在模板里，都不经过译员的手。 ## 抽样框：最有钱做本地化的那批公司 取的是8个市场——斯里兰卡、柬埔寨、缅甸、老挝、蒙古、尼泊尔、格鲁吉亚、亚美尼亚。每个市场取电信运营商、商业银行、国家航空、头部电商与零售各若干家，一共87家。 这是个有意的抽样框，不是随机抽样。这批公司是每个市场里最有预算、最有理由把本地化做完整的，如果连它们都留着痕迹，别的站只会更多。 数据取自2019年12月前后的网页存档快照 (https://archive.org/help/wayback_api.php)，接口会返回离目标时间最近的一份，时间戳落在2019年之外的一律不用。 87家里拿到窗口内快照的56家，其余31家分三种情况：根本没有存档、有存档但时间不在窗口内、以及接口当时取不到。这三种要分开计，不能都算成“没有”。 ## 先把没有本地语言内容的站挑出去 量之前得先分档，因为一个整站都是英文的公司，谈不上有没有翻译痕迹。 按可见文本里本地书写系统字母的数量分：200个以上算确实有本地语言内容，17家；1到49个算只有零星几个字，13家；50到199个之间5家；一个都没有的21家。 接下来那17家才是要看的对象。这一步很关键：把没有本地内容的站混进来算比例，会得出一个虚高的结论——它们的语言声明当然写着英语，因为它们本来就是英文站。 分档还带出一个地理上的分野。斯里兰卡9家、柬埔寨8家，一家有本地语言内容的都没有；而格鲁吉亚7家里有5家、亚美尼亚5家里有3家、蒙古6家里有3家。做语言优先级排序 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)的时候，这个分野比人口数据有用得多。 ## 本地化几乎没有中间状态 把56家站按本地文字占比排一遍，会看到一个很干净的两头堆。 占比超过0.88的一批：亚美尼亚两家银行0.90和0.96、格鲁吉亚一家银行0.955、蒙古两家0.96、老挝一家银行0.905。占比低于0.05的另一批，有39家之多。 落在0.5到0.8这个中间带的，56家里只有5家。本地化在实践中要么整站做，要么只做个入口，中间状态很少见。 这条对预算判断有直接用处：你不用纠结“做到什么程度”，市场已经替你把选项砍成了两个。 ## 英文界面词跟着占比走 再看边角文案。本地文字占比在0.88以上的那几家，首页上能识别出的英文界面词是0到1个；占比0.5到0.8的几家是2到4个；而占比只有0.049的那家尼泊尔银行，英文界面词有11个。 数值上这是个同义反复——本地语言多，英文自然少。有意思的是分布的形状：从0跳到11，中间几乎没有过渡。 换句话说，边角文案不是被一点一点翻完的，是跟着整站一起翻或者一起不翻。这跟前面那条两头堆是同一件事的两个侧面。 ## 页面语言声明：17家里写对6家 第一个硬信号是页面开头那行语言声明，跟正文实际使用的语言对不对得上。 17家里写对的6家，写错的3家，干脆没写的8家。写对率35.3%。 写错的三家很典型。格鲁吉亚一家电信运营商的正文88.4%是格鲁吉亚字母，语言声明写的是俄语；尼泊尔一家银行48.9%是天城文，声明写的是英语；另一家尼泊尔银行的正文里有227个天城文字符，声明写的是美式英语。 这一行是模板里的常量，译员拿不到，测试也不会测它。按页面语言声明的规范说明 (https://www.w3.org/International/questions/qa-html-language-declarations)，它要标的是这一页内容的主要语言，而不是这个站的默认语言——很多站错就错在把它当成了后者。 这条痕迹的好处是它跟书写系统无关。不管正文是天城文、格鲁吉亚字母还是西里尔，判断方法都是同一个：把声明的语言和正文实际用的语言比一下。 ## 那13家“只有零星几个本地字”的站，那几个字是什么？ ## 数量都落在4到49之间，太巧了 分档的时候我注意到一件怪事：13家站的本地字母数量分别是4、6、6、7、8、12、14、16、21、26、26、27、33，全部落在同一个很窄的区间里。 这些站分布在5个国家，用5种不同的书写系统，行业也不一样。数量这么接近，多半不是巧合，而是它们上面的本地文字是同一个东西。 于是把这几个站的快照重新抓了一遍，把每一段非拉丁文字连同上下文抠出来看。 ## 是那个“切换到本地语言”的按钮 答案比我猜的还整齐。 斯里兰卡三家电信运营商和一家银行，页面上全部的僧伽罗文和泰米尔文，就是语言菜单里那两个词本身：僧伽罗语和泰米尔语。链接指向的是本地语言版本，而那个版本大多数是空的或者跳回英文。 两家电商平台上是“切换语言”这四个字，尼泊尔那家是“语言切换”，缅甸那家是“语言”。一家尼泊尔银行是“尼泊尔语”，柬埔寨一家电信是“高棉语”，老挝航空是“老挝语”。 整个站上唯一用本地语言写的字，是那个让你切换到本地语言的按钮。 剩下几家的情况稍微不同：蒙古两家和格鲁吉亚一家，本地文字出现在标题标签里的公司名和标语上，正文一个字都没有——那是因为页面用脚本渲染，静态内容里只剩下一个壳。 ## 这一条本身就是个可用的判据 这个现象可以直接当信号用：如果一个站上的本地语言文字少到能数得清，先去看它们出现在什么位置。 出现在语言切换菜单里，说明本地化只做了入口，没做内容。出现在标题标签里，说明可能是脚本渲染，你的静态抓取拿不到真实情况，得换工具。 还有第三种位置：零星出现在某一条新闻标题或者某个促销活动的文案里。这种通常是市场部临时发的一条本地语言内容，跟整站的本地化程度无关，看看日期就知道了。 这两种情况的判断完全不同，而在字符统计表上它们长得一模一样，都是“本地字母十几个”。前一种是本地化只做了入口，后一种是我的抓取方式不对。 分辨方法很简单：看这几段文字出现在什么标签里。挂在导航或者链接文字上的是入口，挂在标题标签里的是渲染问题。锚文本在小语种上会长出多少种形态 (https://zhangwenbao.com/minor-language-internal-link-anchor-inflection-variants.html)那篇讲的是同一个位置的不同写法，这里看的是同一个词只出现在一个位置。 ## 多语言标注的覆盖率低得离谱 第三处是多语言标注。56家里有这个标注的只有9家，而在17家确实有本地语言内容的站里，只有1家有。 有的那9家里，几家跨国电商平台把5个市场全部标成了英语的地区变体，一个本地语言都没标；一家赌场标了一个不是任何合法语言代码的写法；另一家把地区子标签写成了跟语言码相同的两个字母，指向的是一个完全不相干的国家。 这几个错法的共同点是格式合法、内容错误。语言标签的格式标准 (https://www.rfc-editor.org/rfc/rfc5646)把语法正确和取值有效分成了两件事，校验工具通常只查前一件，所以这些写法一路绿灯。 要抓这类错，只有一个办法：把每个语言代码丢回注册表反查出语言全名，人工扫一眼。格式校验永远抓不到“把柬埔寨写成科摩罗”这种错。 ## 把壳上的信号凑成一个判定流程怎么做？ ## 三处硬信号 第一处，页面语言声明跟正文实际语言是否一致。不一致或者缺失，记一分。 第二处，本地语言文字的数量与位置。少到能数清、且集中在语言切换入口上，记一分。 第三处，多语言标注是否存在、是否指向本地语言。缺失或者只标了英语的几个地区变体，记一分。按多语言站点的官方规范 (https://developers.google.com/search/docs/specialty/international/localized-versions)，这组标注要成对出现且互相指回，实测中大多数站连单向都没写。 三处都中，判为“壳是从别的语言版本复制来的”。这个判断比“这些内容是翻译的”弱一点，但它稳定，而且它蕴含的商业结论是一样的——本地版本不是本地团队从头做的，选题就不会按本地需求排。 三处的成本也不一样：语言声明最好查，看一眼源码开头即可；本地文字的数量与位置要跑个脚本；多语言标注最省事，正则一抓就有。真要偷懒，只查第一处和第三处也能用，准确率会掉一些但方向不会错。 ## 两处软信号 软信号不单独作数，只在存疑的时候用来加权。它们的问题在于跟内容策略纠缠得比较深，有可能是主动选择而不是疏忽。 一是地址结构：本地语言的页面用英文单词拼地址，说明这批页面是从主站复制出来再翻的。地址用本地字母还是拉丁转写 (https://zhangwenbao.com/minor-language-url-native-script-vs-latin-transliteration.html)那篇讲的是主动选择，这里看的是被动留下的痕迹。 二是边角文案：站内搜索提示、错误页、表单校验这类文字通常不在翻译稿范围内。在17家有本地内容的站里，本地文字占比超过0.88的那几家，英文界面词是0到1个；占比在0.5到0.8之间的，是2到4个。 顺带说一个观察：本地文字占比的分布是两头堆的。56家里超过0.88的和低于0.05的各占一大堆，落在0.5到0.8中间的只有5家。本地化这件事在实践中几乎没有中间状态，要么整站做，要么只做个入口。 ## 半天能跑完的最小版本 选20个核心词，每个取搜索结果前10条，去重后大概100到150个页面。 逐个页面看那三处硬信号，各记一分。得3分的判为“壳是复制的”，得0分的判为“本地做的”，1到2分的单列为存疑，不要强行归类。 最后看三档各占多少。这个分布比任何单个数字都有用，因为存疑那一档的大小本身告诉你这个市场的本地化成熟度。 如果连搜索结果都拿不全，小语种上工具没数据时的那几条替代路子 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)可以拿来凑样本，把行业目录、本地媒体的外链页面都算上，凑到100个页面就够跑了。 ## 三档结果分别意味着什么 三分那一档，判为壳是从别的语言版本复制来的。对你的意义是：这个站的本地版本很可能是主站的投影，选题跟着主站走。 零分那一档，判为本地团队自己做的。这种对手最难缠，因为它的选题是按本地需求定的，你占不到结构性便宜。 一到两分的存疑档最有信息量。它通常意味着这个站正在从第一种往第二种过渡，或者不同栏目由不同团队负责。存疑档占比越高，说明这个市场的本地化正在发生变化，值得盯紧。 ## 什么时候该重跑 改版会让所有壳上的信号一次性失效或者一次性修好，所以对手改版之后必须重跑。 另外两种情况也要重跑：对手接入了新的翻译流程，或者你发现存疑那一档突然变大。后一种通常意味着市场里进来了新玩家，用的是跟原来那批不一样的做法。 频率上我的建议是半年一次，比语言层那个数勤一倍。原因很简单：语言层的构成靠一批人的长期习惯撑着，变得慢；单个站的壳一次改版就全变了。 ## 这套判断在实际决策里怎么用？ ## 先说它不能用来干什么 它不能用来判断内容质量。壳是复制的，正文可能翻得很好；壳做得很正，正文也可能是机器直出。这两层没有必然联系。 它也不能用来算精确比例。前面那套标定已经说明，正文层量不准，壳这一层只能给你一个站级别的定性判断，不是页级别的。 还有一点：它判的是“壳的来历”，不是“内容的来历”。两者高度相关但不等价，遇到本地团队用总部模板自己写内容的情况，会误判。 这种误判有个特征：壳三处全中，但内容里全是本地话题、本地人名、本地时间。碰上这种就把壳的结论作废，直接按本地原生对手处理。结构证据被内容证据推翻的时候，听内容的。 ## 能用来干什么 最直接的用途是判断对手的选题清单从哪来。壳是从主站复制的，内容大概率也跟着主站的话题走，那么本地特有的需求就是空位。 第二个用途是估工作量。整个市场的站都只做了入口没做内容，说明这个市场的本地化基础设施还没建起来——没有成熟的译员供给，没有做过这类项目的本地代理，你进去的时候要自己从零搭，预算得往上调。 反过来，如果这个市场上已经有几家把整站本地化做完了，说明供给链是通的，你的执行成本会低不少，但选题上的便宜也没那么好占了。 第三个用途是挑时机。一门语言的公共内容里有多少是搬来的 (https://zhangwenbao.com/minor-language-content-translated-share.html)那篇给的是语言层的构成，壳这一层给的是站层的实际状况，两个数一起看，能判断这个市场是刚起步还是已经卷起来了。 还有一个用途是防守。你自己的多语言站上，那三处大概率也没改——我按同样的标准检查过几个客户的站，三处全中的不在少数。看流量报表里机器占多少 (https://zhangwenbao.com/minor-language-crawler-share-traffic-report.html)的时候顺手把这三处也查一遍，成本几乎为零。 ## 跟母语审校是两回事 要说清楚一件事：本文讲的是从外面判断来源，不是判断质量。母语者审校该验哪几层 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)那篇讲的是你自己的稿子怎么验收，那是内部视角，能看到原文和译文的对照。 外部视角看不到对照，所以只能退而求其次去看结构。两套方法解决的是不同的问题，别混着用。 硬要说有什么联系，那就是：验收清单里那些最容易被漏掉的项，正好也是从外面最容易看出来的项。省掉审校那道工序的代价 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)在两个视角下是同一笔账。 ## 中文市场用得上吗 用得上，而且用法更宽。中文站的多语言版本大量存在同一个问题：主站中文做得很细，英文和其他语言版本的壳直接复制，语言声明和多语言标注常年不改。 反过来，中文市场的站在被别人抄的时候也留下同样的痕迹。抄的人会复制结构，但不会改那三处，所以这三处也可以当成溯源的线索。 只是中文市场的内容搬运更多发生在中文内部，也就是站与站之间的转载，那一层跟语言无关，得换别的办法查。壳这套判据只对跨语言的复制有效。 ## 我在这批数据上犯过的错 ## 用错解码，把结论量反了 抓存档快照的时候，有两家站的网页没有声明字符集。工具库遇到这种情况会默认按西欧编码解，我写的判断分支又恰好永远走不到猜测那一步。 结果是这两家站的西里尔文和格鲁吉亚文被解成了一串乱码，而乱码里每个字符都算“非拉丁字母”，于是被统计成了本地文字。 蒙古一家航空公司的本地文字被算成109个，真值是5268，差48倍；格鲁吉亚一家银行算成12个，真值792，差66倍。按错的数字写出来会是“蒙古航空的官网基本是英文的”，跟事实正相反。 正确的解码顺序是：先看响应头里的字符集声明，再看页面里的声明，然后试通用编码，最后才轮到猜。这个顺序不能倒，倒一次就会把一门语言判成另一门。 更值得记的是错误的方向：乱码里的字符全都不是拉丁字母，所以它污染的永远是“本地文字”那一列，而且永远是往多了污染。一个会朝固定方向出错的故障，比随机出错的故障危险得多。 ## 把两种“没有”混在一起算 87家站里31家没拿到窗口内的快照。第一版我把它们统一算成“没数据”，比例是56除以87。 后来分开数才发现，20家是有存档但时间不在2019年，4家是根本没有存档，7家是接口当时连不上。这三种的含义完全不同：第一种说明站还在只是快照不巧，第二种说明这个站在当时几乎没有影响力，第三种纯粹是我这边的问题。 把第三种算进“没有”，等于让自己的网络故障参与了对市场的判断。这条听着荒唐，但在批量采集里特别容易发生，因为失败和空值在数据表里长得一模一样。 ## 抓不到本地文字，先怀疑自己的工具 还有两家站的静态页面里几乎没有正文，本地文字只出现在标题标签里。第一版我把它们跟“只做了语言开关”的那批归成了一类。 实际上完全不同：那两家用脚本渲染页面，正文是在浏览器里生成的，我抓的静态文件里当然没有。把工具的局限当成对方的问题，是这类测量里最容易犯的错。 判据是看文本总量。整页可见文字只有几十个字符，那多半不是页面真的这么空，是抓法不对。这一条跟编码那条是同一个道理，都是先怀疑自己再怀疑对象。 ## 差点把标定结果讲反 合并9门语言的中位数时，六个特征里有五个方向都符合直觉。如果我在那一步收手，这篇文章会是一份“教你识别翻译内容的五个特征”，读着顺，用起来会坑人。 方向符合预期的时候，最该做的就是再拆一层。拆开逐语言看，才看到三门语言方向是反的。 这条规矩我给自己写死了：任何一个符合预期的结论，至少要在一个更细的维度上重算一遍再采信。这次是按语言拆，下次可能是按时间拆或者按站点拆。 成本很低，通常十几分钟；收益是不用把一篇错的东西发出去，然后再花几个月被人当成常识引用。 ## 常见问题解答 ## 用维基的数据标定，结论能搬到商业站上吗？ 正文层那部分的结论可以搬，因为它是个否定结论：连有官方标记、格式统一的样本上都分不开，商业站上只会更乱。 壳那部分本来就是在商业站上量的，不存在搬不搬的问题。抽样框有偏，偏向大公司，这一点前面说明了。 ## 为什么不干脆用现成的AI检测工具？ 那类工具判的是“像不像机器生成的”，跟“是不是从别的语言翻过来的”不是同一个问题。一篇人工精心翻译的稿子在那类工具上通常是干净的，一篇本地人用生成工具写的原创反而会被标红。 而且那类工具在小语种上的表现本身就没有公开的验证数据，拿一个没标定过的工具去解决一个需要标定的问题，等于把不确定性又叠了一层。 ## 65.9%的判别力，是不是特征选得不好？ 有可能。我选的六个都是从外面看得见、不需要读懂语言的特征。如果允许用语言模型去读正文，判别力肯定更高。 但那样就不是“从外面看”了，成本也完全不同。本文要回答的是不懂这门语言、不进对方后台的情况下能做到什么，答案就是这个数。 ## 负样本里混了半自动批量建的短条目，是不是让结论不成立？ 不成立的是具体倍数，不是方向不一致这个结论。方向翻转发生在僧伽罗语、格鲁吉亚语、希腊语上，而这三门里格鲁吉亚语和希腊语的负样本集中度并不高。 更重要的是，商业站上的情况也一样：对手站上的“本地写的内容”里，本来就混着大量批量生成的模板页。样本不纯这件事本身就是现实的一部分。 ## 壳上那三处，对方改一下不就没了？ 会没，但这恰恰说明它有用。改这三处的成本很低，愿意改的团队通常也会把内容做好；一直不改的团队，多半是因为没人在管这个市场。 所以这三处与其说是技术痕迹，不如说是投入程度的代理指标。 ## 只有一个市场要做，值得跑这一套吗？ 值得，但可以简化。单市场的话不用做标定，直接看那三处硬信号，20个词、100来个页面，半天能完。 标定那一套是给需要在多个语言之间比较的场景准备的。只做一个市场，你要的是绝对判断，不是排序。 ## 权威参考资料 ## 小语种内容存量的中位数：随机翻开一页，瑞典语一年6个人打开，老挝语140个 - URL：https://zhangwenbao.com/minor-language-page-reader-median.html - 分类：小语种SEO - 发布：2020-04-09 | 更新：2026-08-02 - 摘要：16门语言各随机抽120页实测2019年真人阅读中位数：宿务语1次、瑞典语6次、越南语7次，老挝语140次、僧伽罗语131次。垫底四门全是被程序批量建过页面的语言版本。 - 关键词：数据分析,多语言SEO,内容运营,小语种SEO > **TLDR**：摘要：在16门语言里各随机抽120个页面，逐个查它们2019年被真人打开过几次，得到的中位数排出来是这样：宿务语1次、瓦瑞语2次、瑞典语6次、越南语7次，而老挝语140次、蒙古语136次、高棉语132次、僧伽罗语131次。排在最下面的四门没有一门是真正意义上的小语种，全是被程序批量建过页面的语言版本；反倒是页面最少的老挝语，随机翻开一页的读数比瑞典语高23倍。换一个跟读者规模完全无关的变量再验一遍——峰值单月新建量除以中位单月新建量——相关系数是−0.864，结论不变。平均值在这件事上骗得很厉害：越南语的均值是中位数的80倍，前10%的页面拿走了97.9%的阅读量。本文给出16门语言的完整分布、两把中途失效的尺子，以及在自己站上量同一个数的办法。 > 摘要：在16门语言里各随机抽120个页面，逐个查它们2019年被真人打开过几次，得到的中位数排出来是这样：宿务语1次、瓦瑞语2次、瑞典语6次、越南语7次，而老挝语140次、蒙古语136次、高棉语132次、僧伽罗语131次。排在最下面的四门没有一门是真正意义上的小语种，全是被程序批量建过页面的语言版本；反倒是页面最少的老挝语，随机翻开一页的读数比瑞典语高23倍。换一个跟读者规模完全无关的变量再验一遍——峰值单月新建量除以中位单月新建量——相关系数是−0.864，结论不变。平均值在这件事上骗得很厉害：越南语的均值是中位数的80倍，前10%的页面拿走了97.9%的阅读量。本文给出16门语言的完整分布、两把中途失效的尺子，以及在自己站上量同一个数的办法。 做内容排期的时候，很多决定的起点是一个数：这门语言的公共内容有多少。数大就叫竞争激烈，数小就叫机会窗口。 这个数很好拿，各语言版本的页面总数是公开的，一分钟就能抄一张表下来。 麻烦在于它是个总数。总数回答的是“有多少页”，不回答“这些页有没有人打开”。这两件事在英文市场差别不大，在小语种市场差别能有三个数量级。 所以这次换了个做法：不看总数，随机翻开其中的一页，看它一年被多少个真人打开过。 ## 内容存量这个数，按页拆开会看到什么？ ## 总数是个被平均过的东西 一门语言有50万个页面，全年真人访问1.7亿次，平均每页340次。这个平均数看起来挺健康。 但平均数只在分布比较均匀的时候才有意义。如果这50万页里有5000页拿走了绝大部分访问，剩下的49.5万页各自一年被打开三五次，那个340就完全是虚的。 做内容决策的时候，你关心的其实是后面那个分布，因为你新写的那一页大概率落在长尾里，而不是落在头部那5000页里。 换句话说，该问的不是“平均每页多少次”，而是“随便挑一页，它一年被打开几次”。 ## 为什么这个问题在小语种上格外要紧 英文市场的内容存量是几十年一点一点长出来的，长得慢，但每一页背后大体都有个写它的人和读它的人。 小语种不一样。有几门语言的页面总数在某几个月里突然翻了几十倍，那是程序干的，不是人干的。这批页面会把总数撑得很好看，可它们从来没有过读者。 如果你拿总数去判断竞争强度，这几门语言会被判成“内容已经很厚，别进”，而实际情况可能正相反。 判错的代价不是少赚，是把一个几乎无人竞争的入口让出去。给语言排优先级 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)的时候，这类误判往往发生在第一步，后面所有的资源分配都跟着错。 ## 这次的做法 取16门语言，每门用随机抽样接口 (https://www.mediawiki.org/wiki/API:Random)抽120个正文页面，然后逐个去查它们2019年全年被真人打开的次数和被爬虫抓取的次数。 16门里有英语和泰语这样的正常对照，有宿务语、瓦瑞语、瑞典语、越南语这几门被程序建过页面的，也有老挝语、僧伽罗语、高棉语、蒙古语这批真正的小语种。 抽到的页面必须在2019年1月1日之前就存在，否则读到的零不是“没人看”，是“那时候还没有”。这一步的处理比想象中麻烦，后面有一整节讲它怎么差点把结论带偏。 所有数据截到2019年12月，逐页可查、可复核。抽样脚本和查询参数都很简单，任何人拿同样的接口跑一遍都能得到同一批数。 ## 为什么用维基百科的页面 要横着比十几门语言，需要一个各语言口径完全一致、而且能逐页拿到流量的地方。商业站没有这种数据，广告平台的估算不分真人机器，第三方工具的小语种数据基本靠猜。 维基媒体把逐页的月度访问量做成了公开接口 (https://wikimedia.org/api/rest_v1/)，而且区分真人和爬虫。这是目前唯一能做这件事的样本。 它不等于电商站，这一点后面还会说。但它能回答一个电商站回答不了的问题：同样一门语言，页面的构成不同，读数的分布会差多少。 结论落在语言之间的相对关系上，不落在绝对数值上。 ## 这篇不谈的两件事 第一件是整门语言的汇总比例。上一篇已经把访问量里机器占多少 (https://zhangwenbao.com/minor-language-crawler-share-traffic-report.html)量过一遍，那是汇总层，本文只做页面层。 第二件是内容质量本身。一个页面没人读，可能因为它写得不好，也可能因为它讲的东西本来就没人关心，还可能因为它压根不该存在。这三种情况本文不区分。 本文只回答一个事实性的问题：随机翻开一页，一年有多少人打开过它。至于该拿这个数字做什么决定，最后两节会给判据。把事实和判断分开写，是这类数据文章最该守的一条。 先看那16行数。 ## 随机抽120页，一年被真人打开几次？ ## 完整的分布表 下表按中位数升序排。有效样本是剔掉“2019年之前还不存在”的页面之后剩下的数量。 语言 | 有效样本 | 中位数 | 四分位下 | 四分位上 | 零次占比 | 不到10次占比 | 宿务语 | 105 | 1 | 0 | 2 | 47.6% | 100.0% | 瓦瑞语 | 114 | 2 | 1 | 4 | 0.0% | 86.8% | 瑞典语 | 88 | 6 | 3 | 15 | 0.0% | 56.8% | 越南语 | 100 | 7 | 6 | 11 | 0.0% | 69.0% | 约鲁巴语 | 82 | 7 | 1 | 33 | 12.2% | 58.5% | 乌兹别克语 | 36 | 50 | 33 | 117 | 0.0% | 2.8% | 缅甸语 | 51 | 69 | 2 | 390 | 9.8% | 37.3% | 阿姆哈拉语 | 111 | 80 | 22 | 292 | 0.0% | 15.3% | 僧伽罗语 | 69 | 131 | 40 | 306 | 0.0% | 1.4% | 高棉语 | 60 | 132 | 65 | 423 | 0.0% | 0.0% | 蒙古语 | 68 | 136 | 55 | 506 | 0.0% | 1.5% | 老挝语 | 55 | 140 | 37 | 361 | 0.0% | 3.6% | 印尼语 | 62 | 182 | 21 | 633 | 0.0% | 12.9% | 英语 | 95 | 1067 | 370 | 6569 | 0.0% | 1.1% | 泰语 | 79 | 1232 | 427 | 5612 | 0.0% | 0.0% | ## 最上面那几行长什么样 宿务语随机抽一页，2019年全年被真人打开的中位数是1次。有47.6%的页面一整年一次都没有。全部105个有效样本，没有一个超过10次。 瓦瑞语中位数2次，86.8%不到10次。四分位上界是4——也就是说四分之三的页面一年被打开不超过四次。 把这两行翻译成中文：这两门语言的页面，绝大多数从建成那天起就没有被人类打开过，或者只被打开过一两次。 它们的页面总数分别是533万和126万。前者比德语版还多。一个比德语内容还“厚”的语言版本，随机翻开一页的年读数是1次。 ## 最下面那几行才是意外 老挝语中位数140次，蒙古语136，高棉语132，僧伽罗语131。这四门的四分位下界都在37以上，也就是说四分之三的页面一年至少被打开三四十次。 老挝语的页面总数是3311个，全表最少，读者规模也最小——月均只有4万台设备。 可它随机翻开一页的读数，是瑞典语的23倍。 瑞典语有1200万台设备的读者规模，244万个页面。按任何一种直觉，它都该比老挝语好看得多。读者多了三百倍，典型页面的读数却只有人家的二十三分之一。 ## 那句话说反了 开工前我写下的预期是“小语种品类词条目的年真人阅读量中位数低于100”。实测下来这条错了，而且错得很彻底。 老挝语140、僧伽罗语131、高棉语132、蒙古语136、印尼语182，全部高于100。真正低于10的四门是宿务语、瓦瑞语、瑞典语、越南语。 这四门里有一门是北欧的成熟语言，一门是有近亿使用者的东南亚大语种。它们跟“小语种”三个字没有关系。工具在小语种上返回的零 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)常被拿来佐证“这门语言没需求”，这次的数据说明那个零经常指向别的东西。 所以那句流传很广的话——小语种内容没人看——是假的。真的那句是：被程序造出来的页面没人看，而这件事跟语言大小无关。 ## 先排除一个可能：是不是抽样有偏 随机抽样接口取的是正文命名空间里的页面，不做任何加权。但抽到什么，取决于这门语言的页面池子里装的是什么。 宿务语的池子里装着533万个由同一套模板生成的地名和物种条目，抽120个当然全是那类。老挝语的池子里只有3311个页面，几乎都是人写的，抽120个也当然全是那类。 这不是抽样的缺陷，这就是要测的东西。随机翻开一页会翻到什么，本身就是这门语言存量构成的读数。 要小心的是另一件事：拿这个中位数去回答“我新写一篇会有多少人看”，那是不对的。它回答的是“这门语言现存的页面里，典型的一页是什么状况”。两个问题的答案可以差很远，尤其在存量被稀释过的语言上——你新写的那篇有可能比典型页面好十倍，因为典型页面实在太低。 ## 为什么瑞典语和越南语会掉到最下面？ ## 这两门语言的页面是怎么来的 瑞典语版本在2012年到2014年之间被一个程序批量建过页面。建这些页面的那个程序 (https://en.wikipedia.org/wiki/Lsjbot)做的事情是从物种数据库和地理数据库里抽记录，套模板生成条目，一个月能造二十多万个。 宿务语和瓦瑞语用的是同一套东西，只是换了语言参数。宿务语版本的来历 (https://en.wikipedia.org/wiki/Cebuano_Wikipedia)有完整记录，它今天533万个页面里的绝大多数出自那几年。 越南语的情况类似但没那么极端，它在2013年前后也有过一轮大规模导入，峰值单月新建20.8万页。 这四门语言的共同点不是语言小，是页面被一次性造出来过。 ## 造页面不产生读者 一个物种条目写着这个物种的拉丁学名、分类阶元和一句“它是某某属的一个种”，这种页面在任何语言里都不会有人搜。造一百万个，读者数量一个都不会多。 但分母涨了。这门语言的“内容存量”从此看起来很厚，随机翻开一页的读数从此变得很难看。 瑞典语的绝对读者规模一点没受影响——它2019年全年真人访问11.2亿次，比泰语的7.9亿还多。掉下来的只是分布，不是总量。这也是为什么只看总访问量的报表永远发现不了这件事。 总量和分布在这里第一次分家：读者没少，页面多了，于是典型的一页变差了。 ## 老挝语为什么反而好看 老挝语的3311个页面，是十几年里一点一点写出来的。峰值单月新建535页，中位数每月8页。 这种节奏下建出来的页面，选题是人挑的。人挑选题会挑他觉得有人要看的，所以这批页面天然带着一点需求筛选。 加上老挝语的读者虽然少（月均4万台设备），但这4万台设备的注意力只有3311个页面可分。人均能分到的页面很少，每个页面分到的人反而不少。 这就是那个140次的来历。它不代表老挝语市场大，它代表这门语言的供给端还没有被稀释过。稀释是个不可逆的动作，页面造出来容易，把读数抬回去很难。 ## 约鲁巴语是个中间态 约鲁巴语的中位数是7次，跟越南语一样，但它的分布形状完全不同：四分位下界1、上界33，零次占12.2%。 这门语言的页面总数只有29421个，但它的峰值单月新建量是14797页——差不多一半的页面是在一个月里造出来的。 所以它同时具备两个特征：总量很小，可其中一半是灌进去的。分布因此被撕成两半，一半有人读，一半完全没有。 这个中间态比两个极端更常见，也更容易看走眼。只看中位数会以为整门语言都完了，其实还有一半是活的；只看总数会以为一切正常。 ## 先别急着接受这个解释 “页面是不是被灌出来的”听起来很顺，但它不是我一开始算出来的东西。第一版算的是另一个指标：页面数除以读者数。 那个指标算出来的相关系数是−0.893，比后面这个还高。按理说该采信它。 问题出在越南语上：它的页面数除以设备数是0.077，跟老挝语的0.082几乎一样，可两者的中位数差了20倍。一个能解释一切的指标，不该在两个比值相同的语言上给出20倍的差。 相关系数漂亮不等于模型对。所以我换了个变量重算一遍。 ## 换个跟读者规模无关的变量，结论还成立吗？ ## 换成灌注强度 新变量只用页面侧的数据，完全不碰读者：拿这门语言历史上新建页面最多的那个月，除以它的中位月新建量。 这个比值量的是“建页面这件事有多不均匀”。正常长出来的语言，各月新建量差不多，比值就小；被程序灌过的，比值会大到离谱。 它跟读者规模完全无关，所以拿它去解释读数，不存在两边共用一个变量的问题。 算出来的相关系数是−0.864，样本15门语言。跟前一个指标差不多硬，但解释力更干净——它不依赖读者数据，所以不存在因果方向上的含糊。 ## 排出来的次序 宿务语4050倍、瓦瑞语2861倍、约鲁巴语740倍、乌兹别克语402倍、越南语151倍、缅甸语150倍、阿姆哈拉语111倍。 下半段是老挝语67倍、瑞典语65倍、印尼语63倍、僧伽罗语10倍、高棉语10倍、蒙古语5倍、泰语4倍、英语3倍。 这个次序跟读数的中位数几乎完全反着走。宿务语最猛的12个月造出了累计页面数的53%，瓦瑞语91%，乌兹别克语90%，约鲁巴语82%；而英语的最猛12个月只占11%，泰语12%。 越南语在这个口径下从明显的离群点变成了中游偏上，跟它的读数位置对得上了。 ## 瑞典语在这个口径下有点低 瑞典语的灌注强度只有65倍，跟老挝语的67倍几乎一样，可两者的读数差23倍。这一条对不上。 原因是瑞典语的中位月新建量本来就高（3373页），分母大，比值就被压下来了。它的绝对灌注量是每月21.7万页，跟宿务语一个量级。 所以这个指标也不是万能的，它在“本来就写得很勤”的语言上会低估。 两个指标各有各的盲区，能对上的部分才是可信的那部分。这也是为什么最后我把主张压在一句定性的话上，而不是压在某个公式上。两把尺子都指向同一个方向的时候，可信的是方向，不是刻度。 ## 那句定性的话 一个页面有没有人读，跟这门语言有多少读者关系不大，跟这门语言的页面是不是被一次性造出来的关系很大。 单看读者规模，相关系数只有0.397；单看页面总数，只有−0.379。两个单变量都解释不了。 要解释得动，必须引入“这些页面是怎么来的”这个信息。而这个信息在任何一张内容存量对照表上都是没有的。 这是本文最想说的一件事：你抄下来的那个页面总数，不告诉你这些页面是谁建的、为什么建的，而这恰好是决定它有没有人读的那个变量。 ## 平均值和爬虫，各自能把这个数带偏多远？ ## 越南语差了80倍 把每门语言的样本均值和中位数并排放，差距最大的是越南语：均值559，中位数7，差79.9倍。 瑞典语紧随其后，均值246、中位数6，差41倍。英语均值14588、中位数1067，差13.7倍。 宿务语反而最诚实，均值1、中位数1，一点不差——因为它的页面清一色全是零和一，连头部都没有。 一份数据里最“均匀”的那门语言，是唯一一门完全没有读者的语言。这个巧合值得记一下——分布均匀本身不是好消息，得看它是在高位均匀还是在零位均匀。 ## 头部拿走了多少 把每门语言的样本按读数排序，看前10%的页面占了全部阅读量的多少。 越南语97.9%，瑞典语92.2%，英语74.3%，高棉语74.5%，印尼语69.7%，泰语67.0%，僧伽罗语59.0%，蒙古语54.9%，老挝语50.3%，宿务语42.0%。 越南语那个97.9%的意思是：随机抽的100个页面里，读数排前10的那10个页面拿走了98%的阅读量，剩下90个页面分2%。 这跟英文站上讨论了很多年的索引膨胀 (https://zhangwenbao.com/index-bloat-mechanism-sitewide-diagnosis-decision-matrix.html)是同一件事，只是这里能看到它在不同语言之间到底能拉开多大。 ## 宿务语的42%说明了什么 按直觉，被灌得最狠的语言应该集中度最高。实测是反的：宿务语42.0%，全表最低，比老挝语的50.3%还低。 原因不难想。集中度要高，得先有一批热门页面把量吸走。宿务语连热门页面都没有，全表清一色0到3次，自然“均匀”。 灌到极致之后，连集中度这个指标都失效了——因为没有任何一页是热的。 所以看集中度也要配着中位数一起看。单看集中度低，会得出“这门语言的流量分布很健康”这种完全相反的结论。 ## 报表上该放哪个数 结论很简单：中位数必须有，均值可以留着但不能单独出现，集中度要配着中位数读。 三个数一起看，才能分辨出三种完全不同的状况：头部很强长尾很弱（英语）、头部尚可长尾还行（老挝语）、根本没有头部（宿务语）。维基媒体自己也有一个区分页面数量和页面分量的指标 (https://meta.wikimedia.org/wiki/Wikipedia_article_depth)，思路是一样的：光数页面数不够。 只看均值，这三种会混成一团。内容做深还是做广 (https://zhangwenbao.com/content-depth-vs-breadth-single-page-vs-cluster-strategy-decision.html)这个老问题，在这三种状况下的答案完全不同。 这个原则不是小语种特有的，只是小语种上后果更重。英文站上中位数低还有绝对量兜着，小语种站上没有。 ## 换一个角度：同一批样本上的爬虫数 抽样的时候顺手把每个页面的爬虫抓取次数也取了，所以可以在同一批页面上直接比。 取两者的中位数相除：宿务语17.0倍、越南语16.3倍、瑞典语14.5倍、瓦瑞语12.5倍、约鲁巴语9.1倍、乌兹别克语6.7倍。 另一头是泰语0.24倍、英语0.60倍、印尼语0.65倍——这三门是爬虫来得比真人少。 中间是老挝语1.76、蒙古语1.51、僧伽罗语1.36、高棉语1.14、缅甸语1.14，基本打平。 ## 17倍意味着什么 宿务语一个典型页面，2019年被真人打开1次，被爬虫抓了17次。 换成运营的语言：这个页面全年为搜索引擎产生了17次请求的服务器开销、17次的抓取预算消耗，换回1个人的一次访问。 这些开销不是白花的，它换来了收录。可收录之后如果还是没人搜，这笔账就一直是负的。 17倍这个数在自己站上很容易复现，日志按URL分组 (https://zhangwenbao.com/server-log-file-analysis-seo-crawl-budget-bot-verification.html)就能算，不需要任何工具。算之前先把已知爬虫和真人分堆，这一步的判据在日志分析那一层有成熟做法。 ## 跟汇总层的数对得上吗 上一篇算的是整门语言的爬虫占比，宿务语92.07%。用这里的页面级中位数换算，17/(17+1)等于94.4%，两个数很接近。 但泰语对不上：汇总层的爬虫占比12.17%，换算成比值应该是0.14，而页面级中位数给的是0.24。 差在哪儿？差在头部。泰语的头部页面吸走了大量真人访问，把汇总比例压低了，而中位数看不到头部。 这个不一致本身是有用的：汇总比例和页面级中位数差得越远，说明这门语言的流量越集中在少数页面上。 ## 什么时候该担心 页面级的爬虫真人比超过5，基本可以断定长尾那一大片是死的。超过10，说明存量里的大多数页面从未产生过任何价值。 低于1不代表没问题，它只说明典型页面还有人看。头部是不是过度集中，得另外看。 这个判据比汇总层的爬虫占比更直接，因为它不受头部页面干扰。 代价是它需要逐页数据，而汇总比例只要一份日志总量。两个都算，成本差不了多少，反正日志都已经拉出来了。 ## 自己挑出来的那批词，会不会好一点？ ## 换一批不随机的页面 随机抽样测的是“典型的一页”。可做内容的人从来不做典型的一页，他做的是自己挑出来的那几十个词。 所以又取了28个跟做生意有关的概念——咖啡、洗衣机、冰箱、智能手机、电子商务、云计算、二维码、无人机、电动汽车这类——在22门语言里逐个查对应页面的2019年读数。 这批页面的读数确实高得多。老挝语这7个能查到的概念页，读数中位数592次，是随机抽样那个140的四倍多。僧伽罗语1020次，是131的近八倍。 挑过的词就是比随机的强，这一点没有意外。有意外的是这个倍数在各语言之间相当稳定，都在四到八倍之间，没有哪门语言特别高或特别低。 ## 但有意外的是覆盖率 22门语言乘28个概念是616格，实际有页面的只有421格。缺的那195格里，宿务语缺25个（28个概念只有3个有页面），豪萨语缺27个，约鲁巴语缺25个，高棉语缺23个。 宿务语这一条尤其刺眼：它有533万个页面，可这28个最基础的商业概念里，只有3个有对应的条目。 造了533万页，没造洗衣机、冰箱、电子商务这些词。因为造页面的程序照着物种库和地名库跑，那两个库里没有洗衣机。 页面总数和内容覆盖是两件完全独立的事，这一格数据把它们分得干干净净。 ## 爬虫真人比在这批页面上 同样算爬虫除以真人：英语0.11、泰语0.08、印尼语0.18——比随机抽样那批低得多，说明这些页面确实被人读。 但小语种这边：老挝语1.17、豪萨语2.54、约鲁巴语0.90、乌兹别克语0.85、阿姆哈拉语0.79。 也就是说，在这几门语言里，连“洗衣机”“电子商务”这种最该有人看的页面，爬虫来的次数都跟真人差不多，个别语言还更多。 挑过的词能把读数拉高几倍，但拉不过那条线。内容缺口分析 (https://zhangwenbao.com/content-gap-analysis-competitor-coverage-share-of-voice-mechanism.html)在这几门语言上会给出一堆机会，可机会能不能变成流量，取决于这个市场的搜索行为本身。 ## 这对选题的含义 好消息是挑选题确实有用，四到八倍的差距是真的，值得花时间挑。 坏消息是在最薄的那几门语言里，挑得再好也顶不过供给端的结构性问题。这时候该做的不是把选题再挑一遍，而是先确认这门语言值不值得做。 判据可以直接用前面那个数：随机抽样的中位数低于10，说明这门语言的存量已经被稀释；同时概念页覆盖率低于三成，说明基础内容还是空的。 两个条件同时成立的语言（宿务语、约鲁巴语），机会其实很大——空着的都是最基础的位置。这跟“内容已经很厚别进”的判断正好相反，而后者恰恰是抄总数会得到的判断。 ## 这次有两把尺子失效了，是哪两把？ ## 第一把：单月热门榜 最早的计划不是随机抽样，是拿各语言的月度热门页面榜算集中度：前10名占前1000名的比例。数据一分钟就能拿到。 剔掉首页和特殊页之后算出来的排名，第一是约鲁巴语34.3%，第二是意大利语32.8%。 意大利语排第二，这就不对了。翻开它的榜单一看，前几名是几个电视频道的条目——当地人习惯搜频道名找节目表，这批条目的量常年很高。 单月榜会被偶发事件和本地习惯主导，它测的不是内容结构，是那个月发生了什么。这把尺子直接弃用。要救它得取十二个月再做去季节化，那时候成本已经超过随机抽样了。 ## 第二把：用有没有流量记录来判断页面存不存在 随机抽到的是今天的页面，其中很多是2019年之后才建的，必须剔掉。逐个去查建立时间很慢，所以想了个偷懒的办法：看这个页面2018年有没有流量记录，有就说明当时已经存在。 抽37个样本核对了一遍：30个判对，7个判错，误判率18.9%。 而那7个判错的全是宿务语的地名条目，它们2017年就建好了，只是2018年一整年连爬虫都没抓过一次——恰好是信号最强的那一批。 按这个代理剔除，等于把最死的页面从分母里拿掉了，中位数会算得比真相好看。改成对所有代理为负的行逐条补查真实建立时间之后，宿务语的有效样本从63个变成105个，零次占比也是这么冒出来的。 ## 还有一个采集层的坑 并发抓数据的时候有一批请求瞬时失败，返回空值。这些空值混进结果里，看起来跟“这个页面零阅读”一模一样。 发现它靠的是一个巧合：抽查时随手单查了一个英语页面，接口给了2996次，而采集结果里它是空的。如果没有这一下手贱，这批空值会原封不动地变成“零阅读”写进结论。 逐条重查一遍，救回281行。剩下41行确认无记录的，多半是2019年之后改过名、历史挂在旧标题下的页面，这批单独剔除并在上表里体现为有效样本数的减少。 凡是有并发、有重试上限的采集，末端一定要单独复核一遍，不然缺的那部分会被当成零。 ## 为什么要把失效的尺子写出来 因为这两把尺子失效的方向都是让结论更好看。第一把会把集中度排序打乱，第二把会把中位数抬高。 如果不查，这篇文章会得出一个更温和、也更符合常识的结论：小语种的页面读数偏低但没那么夸张。 而且那个结论看起来完全说得通，没人会去质疑它。这才是最危险的地方——错得离谱的结论会被自己发现，错得合理的不会。 这是做这类数据最需要防的一件事：当算出来的方向刚好符合你的预期时，先假设自己错了，再查一遍。 ## 换到你自己的站上，这个数怎么量？ ## 第一步：把页面级的读数拉出来 从搜索控制台导出页面维度的报表，取最近12个月，字段要页面地址、展现量、点击量。从统计工具里另导一份页面维度的独立访客。 两份对不上是正常的，一份是搜索侧、一份是站内侧。先各自算各自的，别急着合并。 算的东西只有一个：中位数。不是总和，不是平均，是把所有页面按数值排序之后取中间那个。 这一步的产出是一个数字，比如“过去12个月，本站页面的点击量中位数是3”。第一次算出来通常会比预期低不少，这很正常。 ## 第二步：把零的那批单独拉出来 12个月内点击量为零的页面有多少个、占比多少。再拉一份展现量也为零的，这批是连搜索结果都没进过的。 两个数分开看。点击零展现不零，说明进了结果页但没人点，问题在标题和摘要；两个都零，说明根本没进结果页。 收录、排名、流量这三层的分层诊断 (https://zhangwenbao.com/indexed-ranked-traffic-three-layer-seo-diagnosis.html)在这里正好用得上，两种零对应的是不同的层。 小语种站上这两批加起来常常超过一半，这个比例本身就是结论。长尾词从发现到退役的生命周期管理 (https://zhangwenbao.com/long-tail-keyword-lifecycle-management-discovery-to-retirement.html)里那套退役判据，可以直接拿来处理这批页面。 ## 第三步：算一下自己的“灌注强度” 把站上所有页面按建立月份分组，看有没有某几个月的新增量比中位数高出一个数量级以上。 有的话，把那几个月建的页面单独拉出来，算它们的读数中位数，跟其余页面比。差距大就说明那一批确实是死的。 批量生成的城市页、组合筛选页、自动翻译页、程序化落地页，都会在这一步现形。 没有批量生成历史的站，这一步会得到一条很平的曲线，那就跳过。曲线平本身就是个好消息，说明存量是一点一点长出来的。 ## 第四步：把这几个数做成定期项 页面读数中位数、零点击页面占比、页面级爬虫真人比。三个数一个季度算一次，看走势。 中位数往下走而页面总数往上走，是最典型的稀释信号。这时候继续加页面只会让它更快往下。 中位数往上走，哪怕页面总数没变，也说明存量在被真正消化。 三个数都不难算，难的是坚持每季度算一次，并且口径不改。口径改一次，前面攒的历史就全废了，这比算错一次严重得多。 ## 一个可以半天跑完的清单 导出搜索控制台的12个月页面报表，算点击中位数和展现中位数。统计一遍零点击、零展现的页面数和占比。 按建立月份给所有页面分组，找出新增量异常的月份，单独算那批页面的读数。 日志按URL分组，算爬虫请求的页面级中位数，跟真人相除。 四件事做完，半天，产出四个数字加两张清单。 ## 量出来之后，该删还是该留？ ## 先分三类，不要一刀切 读数为零的页面分三种：从来没被抓过的、被抓过但没进结果页的、进了结果页但没人点的。三种的处理完全不同。 第一种是技术问题，检查站点地图和内链就行，多半是孤岛页面。第二种要看内容本身是不是太薄。第三种改标题和摘要就有救。 把三种混在一起做“清理低质页面”，会把第一种和第三种一起误伤。 先分类再动手，这一步不能省。分类只需要两列数据（展现量和点击量）加一次内链扫描，半小时的事。 ## 什么样的页面该删 同时满足三个条件的可以删：12个月零点击、内容是模板批量生成的、没有任何站内链接指向它。 缺一个条件就先不删。零点击但有内链的页面，可能在承担结构作用；模板生成但有点击的页面，说明这个模板做对了一件事。 删之前先做一批试删，观察两个月。大规模低质内容的处理经验 (https://zhangwenbao.com/google-panda-algorithm-content-farm-recovery.html)里最常见的教训就是一次删太多，后面分不清是哪一刀起的作用。 删的目的是把抓取预算还给该拿的页面，不是为了让报表好看。这两个动机会导向完全不同的删除清单。 ## 什么样的页面该合并 一批读数都很低、但主题相近的页面，合并成一个厚的往往比删掉好。合并之后的页面能承接原来分散的所有查询。 判据是这批页面的主题是不是真的重合。同站页面互相抢词的诊断办法 (https://zhangwenbao.com/keyword-cannibalization-content-site-diagnosis-consolidation.html)可以直接拿来判，重合的那部分才合并。 小语种上还有一个额外的合并理由：读者规模本来就小，把量分散到十个页面上，每个都到不了能被看见的门槛。 合并之后要做重定向，别让旧地址空着。合并时还要留意正文里的强调和锚文本会不会跟着错位，屈折语上这类错位尤其容易发生 (https://zhangwenbao.com/minor-language-emphasis-markup-anchor-drift.html)。 ## 什么时候该反过来加页面 如果算出来中位数还不错（三位数），零点击占比不高，而基础概念的覆盖还是空的，那这门语言的正确动作是加页面而不是删。 老挝语、僧伽罗语、高棉语这几门就是这个状况：存量没被稀释过，但存量本身很少，基础的位置还空着。 这跟“内容存量已经很厚”给出的判断正好相反，而后者恰恰是抄页面总数会得到的判断。 所以这套数最大的用处，是防止你在一个几乎无人竞争的市场里判自己出局。这种误判的成本很难事后察觉，因为你永远不知道没做的那件事本来能带来什么。 ## 哪些相邻的问题不归这一层管？ ## 内容质量本身不归这一层 本文只数了读数，没看过任何一个页面写得好不好。一个页面没人读，本文默认它是因为选题或者结构，但它也完全可能是写得太差。 质量这一层要看的是别的东西：信息密度、是否解决了具体问题、有没有一手材料。拿一手数据做内容 (https://zhangwenbao.com/original-data-research-content-link-magnet.html)这类做法在小语种上尤其管用，因为竞争者更少。 两层要分开量，因为它们的改法完全不同。 把读数低直接归因成质量差，会让你在一个根本没有读者的话题上反复打磨文案。这是投入产出比最低的一种努力，而且它看起来很勤奋。 ## 翻译和审校不归这一层 页面有没有人读，跟它译得准不准是两件事。译错的页面照样可能有量，译对的页面照样可能是零。 母语审校的验收清单 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)解决的是能不能读的问题，本文解决的是有没有人读的问题。 先确认有人读，再花钱审校，顺序反了会很浪费。 这一条在预算紧的项目上特别值钱。审校是按字数收费的，而读数是免费就能查的。 ## 整门语言的汇总比例不归这一层 页面级中位数看不到头部，汇总比例看不到长尾。两个数各自有盲区，得配着看。 前面那个泰语的例子就是证据：汇总层说爬虫只占12.17%，页面层说典型页面的爬虫是真人的0.24倍，两个数换算不到一起，差额全在头部。 要判断一门语言的整体状况，两层都要量。 只量一层就下结论，是这个话题上最容易犯的错。两层的数据来源其实是同一份，多算一遍的成本几乎为零。 ## 这份数据本身的边界 最后把话说回来。这16门语言的样本全部来自维基百科，它的页面构成跟商业站差别很大——没有商品页、没有筛选页、没有促销页，而这三类恰恰是商业站上最容易堆积死页面的地方。 所以本文的绝对数值不要照搬。可以搬的是三样：那个提问方式（随便挑一页，一年多少人打开）、那个判据（中位数配零占比配集中度）、以及那条结论（页面是怎么来的，决定它有没有人读）。 各语言版本的页面数对照表 (https://meta.wikimedia.org/wiki/List_of_Wikipedias)是公开的，谁都能抄一份下来。这篇想说的是，抄下来那个数之前，先问一句这些页面是怎么长出来的。 问完这一句，同一张表能读出完全不同的结论。同一个533万，可以读成“这门语言竞争激烈”，也可以读成“这门语言的基础位置全空着”，而后者才是对的。 ## 常见问题解答 ## 随机抽120个页面，样本量够吗？ 算中位数和分位数够，算精确的头部集中度不够。本文里前10%份额那一列只用来做定性比较，没有拿它做任何量化判断。 有效样本低于40的语言要格外小心。豪萨语抽了120个只剩3个有效——它2019年累计才4126个页面，今天有10.7万个，96%的页面是这之后建的，数据本身是自洽的，但样本太少，已经从主表里剔掉了。 乌兹别克语36个、缅甸语51个也偏少，读它们的时候要打个折。 ## 用维基百科的数据，能代表商业站吗？ 不能直接代表。维基没有商品页、没有筛选页、没有促销页，而这三类是商业站上死页面的主要来源。绝对数值肯定对不上。 能代表的是机制：页面被批量造出来之后，读数分布会怎么变。这个机制跟站的类型无关，它只跟“页面是怎么来的”有关。 所以本文的用法是：拿这个机制去自己站上验证，而不是拿这些数字去对标。 ## 中位数为什么比平均值重要？ 因为你新建的那一页大概率落在长尾里，而不是落在头部。平均值被头部拉着走，反映不了长尾的真实状况。 越南语那个例子最直观：均值559看着还行，中位数7说明典型页面基本没人看。用均值做决策，你会以为这门语言的存量很健康。 两个数差得越远，说明用均值犯的错越大。 ## 零点击的页面是不是都该删？ 不是。零点击分三种：没被抓过、被抓过没进结果页、进了结果页没人点。第一种是技术问题，第三种改标题就有救，只有第二种里的模板页才值得考虑删。 删之前还要看有没有站内链接指向它。承担结构作用的页面即使自己没量，删了也会影响别的页面。 先分类，再试删一批观察两个月，别一次删完。 ## 宿务语这种极端案例，现实里会碰到吗？ 整门语言那种规模的不会，但同样的机制在单个站上很常见。程序化生成的城市页、颜色尺码组合页、自动翻译的多语言版本，都是同一件事的小型版。 判断方法一样：按建立月份分组，看有没有某几个月的新增量高出一个数量级，然后单独算那批页面的读数。 现实里这类页面通常占存量的三成到七成，比宿务语的九成温和，但足够把中位数拖垮。 ## 这套方法对刚上线的站有用吗？ 有用，而且用法不一样。刚上线的站还没有存量可拆，这套数的价值在于给出一条红线：页面增长速度不该超过读者增长速度太多。 具体做法是从第一天就记录页面数和月度独立访客，每季度算一次比值。这个比值一路往上，说明在造还没人读的页面。 比事后清理便宜得多。 ## 中文市场用得上吗？ 用得上，而且更该用。中文站上程序化生成页面的比例普遍不低，城市页、长尾问答页、聚合页都是常见做法。 方法可以原样搬：页面读数中位数、零点击占比、按建立月份分组找异常。数据源换成搜索控制台和站内日志就行。 差别在于中文市场的采集脚本更多，算页面级爬虫真人比的时候要先把采集流量单列出来，否则会高估。 ## 权威参考资料 ## 德语版页面上加粗的那个词是个介词，而翻译校验一路全绿放行 - URL：https://zhangwenbao.com/minor-language-emphasis-markup-anchor-drift.html - 分类：小语种SEO - 发布：2020-03-24 | 更新：2026-07-28 - 摘要：加粗标签在文件里存的是位置不是词，语序一变罩住的就成了另一个词，而校验只比对标签的数量和名字。讲清这层错位为什么躲开了全部自动检查、斜体和粗体在哪几套书写系统里根本不成立，以及把强调从版面手段换成句法手段的三种改写。 - 关键词：出海SEO,多语言SEO,内容本地化,小语种SEO > **TLDR**：摘要：加粗和斜体在源语言里罩住的是一个词，在文件里存的却是一段位置。语序一变，同一段位置罩住的就是另外一个词，而所有翻译校验查的都是标签的数量和名字，没有一项在问它罩住的意思对不对。本文把这层错位拆开，顺带解释为什么斜体和粗体在好几套书写系统里根本不成立，最后给出一条不依赖版面的替代路线。 > 摘要：加粗和斜体在源语言里罩住的是一个词，在文件里存的却是一段位置。语序一变，同一段位置罩住的就是另外一个词，而所有翻译校验查的都是标签的数量和名字，没有一项在问它罩住的意思对不对。本文把这层错位拆开，顺带解释为什么斜体和粗体在好几套书写系统里根本不成立，最后给出一条不依赖版面的替代路线。 ## 为什么德语版页面上加粗的那个词是个介词？ ## 一次真实的错位长什么样 那是一家做德语市场的户外装备站，主力品类是冲锋衣。 英文原页上有一句话，把最核心的那个卖点词加了粗。 德语页面上同样的位置也有加粗，粗体一个不少。 但被粗体罩住的，是一个只有两个字母的介词。 那个真正的卖点词，就在粗体外面，一个像素都没沾上。 这不是个别页面的手滑。同一批上线的一百多个商品描述里，凡是源文有句内强调的，德语版几乎都有类似的偏移，只是错得没那么显眼——有的罩住了半个词，有的罩住了冠词加名词的前半截，有的干脆把标签闭合在了词的中间。 更要命的是，从上线到被发现，中间隔了七个月，期间没有一个人报错。 这个站后来把三个语言版本各统计了一遍，德语的错位率最高，法语居中，荷兰语最低，顺序正好跟这三门语言相对英语的语序差距一致。这个巧合后来成了排查的第一条线索，也让人第一次意识到根源在语序而不在某个译者。 ## 源句和译句的词序差在哪一步 英语的形容词几乎总是紧贴在名词前面。 德语这句话为了表达同一个意思，用了一个不同的句式。 最高级的那个词被推到了名词前面的另一个位置。 句子长度也不一样，德语比英语长了将近三成。 于是同样从句首数过去的第几个词，两边指的不是一回事。 德语复合词和格变化那篇 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)里讲过一个类似的道理：德语的名词短语内部是有强制配合关系的，冠词、形容词、名词三者要一起变。这意味着译者在处理这句话时，改动的不是一个词，而是一整个短语的构造，词的顺序和数量都会跟着变。 而标记是在这一步之前就已经定好位置的。 值得留意的是，这一步的错位跟译者水平几乎无关，甚至是反着来的。译得越地道、语序调整得越大，标记偏得越远；反倒是那种硬按英语语序直译的译文，标记还能凑巧落对位置。责任归属最容易在这里被误判。 ## 这件事为什么没有人报错 本地读者读到的是一句完全正确的德语。 意思对、语法对、术语对、语气也对。 唯一不对的，是有个词被莫名其妙地加粗了。 这在读者眼里最多算排版有点怪，不构成一个错误。 没有人会为了排版有点怪去提工单。 保哥在几个项目上反复见到同一件事：凡是不构成错误、只构成怪异的问题，反馈链路是彻底断的。用户不报，因为报了也说不清；客服不转，因为这不影响下单；母语审校不提，因为审校单上没有这一项。于是它可以在站上安安静静地待很多年。 还有一个更结构性的原因：反馈渠道本身是有语言的。客服后台、工单表单、评价入口多数只有一两种界面语言，本地用户要跨过一道门槛才能把这件小事说出口。愿意为一个排版怪异跨门槛的人，实际上一个都没有。 ## 内联标签在译文里到底是怎么错位的？ ## 标签在文件里存的是偏移量不是词 把一句带格式的话交给翻译流程，它不会以富文本的样子过去。 格式会被抽成一组标记，插在纯文本的某几个位置上。 行业里通用的交换格式是XLIFF，它把这些标记单独编号。 标记本身不带任何关于它罩住了什么的信息。 它只知道自己该出现在这段文字的哪个地方。 XLIFF 2.0规范里定义的内联标记族 (https://docs.oasis-open.org/xliff/xliff-core/v2.0/os/xliff-core-v2.0-os.html)把成对标记、独立标记、代码片段分成了几类，每一类都有id属性用来跟源文对应。设计上这套东西解决的是“标记不能丢、不能重复、配对不能乱”的问题，它从来就不负责保证标记两端夹着的还是同一个语义单元。 这句话可以再直白一点：标签标的是位置，而你要的是词。 可以拿一个更熟悉的东西类比：这就像给一段录音打时间戳，时间戳记的是第几秒，而不是“那句话”。同一段内容重录一遍，语速一变，原来的时间戳指向的就是另一句话了。标记跟译文之间的关系，正是这么一回事。 ## 译员看到的是占位符不是加粗效果 在多数翻译工具里，译员看到的句子长这样：源文里那对粗体标签显示成两个灰色小方块。 方块上没有“这里是粗体”的提示。 它们看起来跟一个换行符、一个变量占位符没什么区别。 译员的任务是把句子译对，顺手把方块摆回去。 摆哪儿呢？多数人凭直觉摆在差不多的位置上。 这里有个很不直观的地方：译员越是不熟悉这个标记的含义，摆得越保守——保守的意思是尽量贴着原来的相对位置摆，而这恰恰是错得最厉害的摆法。真正摆对的前提是知道那对方块是粗体、而且知道这一句里该加粗的是哪个概念，这两条信息在工作界面上都没有。 做本地化的人管这叫标记盲摆，做站的人根本不知道有这回事。 这里其实有个成本很低的改进：在给译员的句段备注里，把每一对标记原本罩住的源文词单独列一行。多数工具都支持这类附注，配置一次长期有效。做过这件事的项目，标记错位的比例通常能降到原来的三分之一以下。 ## 机器翻译把标签当成一个无意义符号 直接上机器翻译的站，这一层的错位只会更普遍。 模型看到的输入里，标签是一串跟正文混在一起的字符。 它会尽力把这串字符原样搬到输出里去。 搬到哪儿取决于模型学到的对齐关系，不取决于语义。 短句还好，长句和从句一多，位置就开始飘。 机器翻译直接发布那篇 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)讨论的是内容质量的下限在哪里，标记错位是那条线之外的另一类损伤：它不影响句子的可读性，所以任何以可读性为准的质量评估都测不到它。你把译文丢给一个打分模型，它会给出很高的流畅度分，因为流畅度确实很高。 换句话说，这是一类专门躲开质量评估的损伤。 另一个容易被忽略的细节是，不少机器翻译接口对带标记的输入有专门的处理模式，跟纯文本模式的结果并不一样。有的会先剥掉标记再还原，有的整串直接处理。接口文档里通常写了，但接的人一般不看，默认是什么就用什么。 ## 富文本字段直接复制粘贴的那一类 还有一条更土的链路，反而最容易出问题。 运营在后台的富文本编辑器里直接编辑各语言版本。 做法通常是把英文那一版整段复制过来再逐句改写。 改写的时候，粗体是跟着原文的字符一起继承下来的。 你改掉了词，格式还留在原来那几个字符上。 这条链路的隐蔽性在于它连一次机器处理都没有经过，所以任何针对流水线的检查都覆盖不到它。真要查，只能去数据库里把各语言版本的富文本字段拉出来对着看。 顺带说一句，这条链路上的错位比例，在保哥经手的项目里是最高的。 这条链路还有一个特有的坏毛病：编辑器会把粘贴进来的样式一并保留，包括从文档软件带过来的那些行内样式。于是同一个页面上既有语义标签，又有一堆写死颜色和字号的样式，后者在别的语言版本里连该不该存在都没人判断过。 ## 翻译工具的标签校验为什么一路全绿？ ## 校验项检查的是集合相等 主流的本地化平台都带一整套自动校验。 标记这一块的检查项一点都不少。 Weblate的校验项清单 (https://docs.weblate.org/en/latest/user/checks.html)里，XML标记这一项的判据写得很明白：译文里的标签跟源文不一致就报错。这里的不一致指的是标签的集合——少了一个、多了一个、名字对不上、配对没闭合，都会被抓出来。 这些检查确实有用，而且抓到的问题不少。 问题在于，集合相等是个跟顺序无关的条件。 两个粗体标签，源文有、译文也有，集合就相等了。 至于它们在句子里夹住了谁，检查项里没有这一条。 集合相等这个设计其实有它的历史原因：这套校验最初服务的是软件界面文案，那些字符串又短又简单，一句话里通常只有一个占位符，位置也基本不会动。规则搬到长句富文本上就不够用了，但没人回头改，因为在原来的场景里它一直很好用。 ## 连标签周围的字符都有专项检查 这一层最讽刺的地方在这儿。 同一份清单里还有一项，专门检查标签周围的字符对不对齐。 也就是说，标签前面有没有多一个空格，是被检查的。 标签后面紧跟的是不是标点，也是被检查的。 唯独标签之间夹着的那个词是不是同一个意思，没人管。 这不是工具做得不够细，恰恰相反，它已经细到了字符级。能够被自动校验的只有形式，语义锚点这件事天然需要一个懂两门语言的人看一眼，而这一眼恰好是整条流水线上最贵的一步，所以它被省掉了。省掉之后所有指示灯还是绿的，这才是真正麻烦的地方。 类似的另一家平台，Crowdin的质量检查设置页 (https://support.crowdin.com/qa-checks/)列的项目结构几乎一样，标签一致性也是按集合判的。 想验证这一点很容易：随手挑一段带加粗的译文，把那对标签整体往右挪三个词，再跑一遍全套校验。所有指示灯依然是绿的。这个小实验做完，团队里对“校验通过等于没问题”的那点信心通常当场就没了，比讲十遍道理管用。 ## 这跟术语一致性检查不是一回事 有人会说，术语库不是能管住关键词吗。 术语检查管的是“这个概念译成了哪个词”。 它确实能保证卖点词在译文里出现，而且出现的形态正确。 但术语检查完全不关心这个词有没有被格式罩住。 两套检查各管一段，中间那块正好是空的。 更细一点说，术语检查是在纯文本层跑的，跑之前标记通常已经被剥掉了；标签检查是在标记层跑的，跑的时候不认识哪些是术语。两个检查器看的是同一句话的两个投影，而错位只在把两个投影叠回去的时候才看得见。 所以这件事不是靠加一条规则能解决的，得换一个看的角度。 顺着这个思路能养成一个通用的排查习惯：凡是两个检查器分别在不同的抽象层上工作，它们中间就有一条缝，而缺陷最爱藏在缝里。找缝的办法是把每个检查器的输入画出来，看看有没有哪个维度在所有输入里都被丢掉了。 ## 哪几类页面最容易出现标记漂移？ ## 商品描述里那种半句话加粗 风险最高的是句内强调，也就是一句话里只加粗其中几个词。 整段加粗、整个标题加粗，反而不太出事。 原因很简单：整段的边界跟句子的边界重合。 句子怎么改写，边界都还在两头。 句内强调的两个边界都落在句子内部，语序一动就跟着动。 这条判据可以直接拿去排查：先把全站的句内强调找出来，整段强调可以先放一边。在那家户外装备站上，句内强调只占全部加粗的四成，但错位的案例百分之百都出在这四成里面。 找出来之后再按语言排序，语序差别越大的语言排越前面。 还有一类介于两者之间的情况：整句加粗，但这句话在译文里被拆成了两句。这时候标记通常只跟着前半句走，后半句悄悄失去强调。这种错位比句内偏移更隐蔽，因为页面上看着挺正常，只有对着源文才能发现少了半句。 判断一段强调是不是句内强调，有个不用读句子的土办法：看强调片段前后紧挨着的是不是标点。两头都贴着标点的，多半是整段或整句；有一头贴着的是词，那就是句内强调，收进待查清单。 ## 帮助中心与退换货条款 第二类是条款型内容，尤其是退换货和配送说明。 这类内容里加粗用得特别多，因为要突出时限和例外。 而这些内容通常是法务或客服提供的，不走内容团队的流程。 它们进翻译流程的时候往往已经是一堆带格式的富文本。 校对的时候大家看的是意思对不对，没人看粗体在哪儿。 这里的代价不只是搜索层面的，还有一层实际风险：条款里加粗的通常是对用户不利或者需要用户注意的那一条，如果粗体在译文里罩到了别处，你在事实上削弱了一次提示。这一点在有强制披露要求的市场上不是小事。 处理办法是把条款型内容单独拉一条线，不跟营销文案混着走。 条款类内容还有一个特殊之处：它的更新往往由法务单方面推动，改完直接覆盖，不走内容排期。于是即使某次全站排查把格式修好了，下一次条款更新又会把旧格式原样带回来。要根治，得把这条线的更新流程一并纳进来。 ## 从英文模板批量生成的落地页 第三类是模板化生成的页面。 一套模板，几十个变量，铺出成百上千个落地页。 模板里的加粗是写死在模板上的，位置固定。 变量替换进去之后，加粗罩住的可能是变量也可能是变量旁边的词。 不同语言的变量长度和位置一变，罩住的东西就不一样了。 模板类内容的特点是错一次错一片。查这类问题的顺序应该反过来：不查页面，查模板。一套模板抽三个语言各看一条，比抽一百个页面有效得多。 查模板还有个额外好处：模板的数量是有限且可枚举的，而页面数量是无限增长的。把有限集合查干净，无限集合就自动干净了。这个思路在很多本地化排查上都成立，凡是能找到生成源的，就别再去查生成结果。 模板类内容还有个特点：它的强调位置往往是设计稿定下来的，而设计稿只出过一版英文的。也就是说这些位置从来没有针对任何一门目标语言被重新审过，风险是设计阶段就埋进去的，不是翻译阶段产生的。 ## 斜体和粗体在非拉丁书写系统里成立吗？ ## 这两个手段是从哪儿来的 粗体和斜体不是天然存在的排版概念。 斜体来自意大利手写体，最初是一整套独立的活字。 粗体是后来为了在同一页上做出层次才铸出来的。 两者都是围绕拉丁字母这套字形长出来的东西。 它们能表达强调，是因为读者从小就在拉丁字母里见惯了。 把这层历史摊开，一个问题就自然浮出来了：一个从某一套字母的书写传统里长出来的手段，凭什么假设它在别的书写系统里也成立。这个问题在做多语言站的时候几乎没人问，因为编辑器上就摆着那两个按钮，按一下就有效果。 有效果不等于成立，这两件事差得很远。 顺着这条线还能问出第二个问题：既然强调手段是跟着书写传统长出来的，那么强调这个动作本身的强度和使用频率，也未必跟英语一样。有些书写传统里，正文中频繁强调本身就被看作不得体，这一层比选哪种记号更根本。 ## 日语的重点标记是傍点不是斜体 日语正文里几乎不用斜体。 假名倾斜之后可读性下降得很厉害，读者也不习惯。 日语传统的做法是在要强调的字旁边点一串小点。 竖排时点在字的右侧，横排时点在字的上方。 这套记号在中文里也有，叫着重号。 日语排版处理需求这份文档 (https://w3c.github.io/jlreq/)把这类记号的位置、形状和适用场合都写得很细，它是这一层最完整的一份参考。日语的三套文字怎么记关键词那篇 (https://zhangwenbao.com/japanese-seo-hiragana-katakana-kanji-keyword-notation.html)讲的是字符层的选择，这里讲的是同一门语言在版面层的另一套约定。 浏览器这边有对应的属性，叫文字强调，可以直接生成这类点。 实际做的时候有个细节要留意：傍点是逐字标注的，所以它对标注范围的敏感度比加粗高得多。范围多包进一个助词，视觉上立刻看得出来，因为那个助词头上多了一个点。这反过来是件好事，错位在日语版上比在德语版上更容易被肉眼抓到。 ## 中文的着重号与波浪线 中文的情况跟日语接近但不完全一样。 着重号是标准的强调方式，写在字的下方。 书名和篇名另有专门的标记，跟强调不是一回事。 中文正文里加粗是可以的，斜体则很少见。 汉字倾斜之后笔画关系会变形，看着别扭。 中文排版需求这份文档 (https://w3c.github.io/clreq/)里对着重号的位置和样式有明确描述，做中文站的人反而很少去翻它。这里有个挺有意思的现象：越是母语，越容易觉得排版这件事“就那样”，反而不去查规范。 做面向中文读者的页面时，这一层其实值得单独过一遍。 中文这边还有一条实践建议：着重号在移动端小字号下辨识度不高，正文里用加粗其实更稳妥，着重号留给需要精确到字的场合。规范给的是可选项不是必选项，具体选哪一个要看实际的阅读环境，这一点规范本身也没替你决定。 还有一点值得提醒：中文的书名号和引号本身也带一部分强调功能，正文里如果标点已经把重点圈出来了，再叠一层加粗就显得吵。多语言站上尤其要注意，因为源文的英语没有书名号这一层，译文很容易叠加过度。 ## 俄语的字距加宽是一种强调 西里尔字母这边有另一套传统。 把一个词的字母之间拉开距离，就是在强调它。 这种做法在俄语印刷品里有很长的历史。 它在网页上对应的是一个纯样式属性，不动字符串。 但历史上在打字机时代，它是靠在字母之间真敲空格实现的。 这条历史线索值得记一下：同一个强调手段，用样式实现和用字符实现，在检索层面是天壤之别。真敲了空格的那种写法，分词器看到的是若干个单字母，这个词在索引里直接消失。俄语格变化那篇 (https://zhangwenbao.com/russian-seo-cyrillic-cases-declension-wordstat-keyword.html)里讨论的词形问题，在这种情况下连词都拼不出来了。 好在现在没人这么干了，但类似的思路换个形式又回来了，下面会讲到。 这条传统今天还有一个活着的变体：社交媒体和广告里常见把词拆成单个字母、中间加空格的写法，用来抢注意力。这类内容一旦被搬进商品页或者用户评价区，就会在索引里留下一堆单字母词条，而且几乎不可能靠后期清洗还原。 ## 浏览器合成出来的粗体和斜体会带来什么？ ## 字体缺字面的时候浏览器不会告诉你 一套字体不一定包含粗体和斜体的独立字面。 拉丁字母的商业字体通常都带，很多其他字体不带。 缺了怎么办？浏览器会自己算一个出来。 粗体靠给笔画描边加粗，斜体靠把字形整体倾斜。 页面上看着有效果，实际上那不是设计师画的字。 MDN关于字体合成属性的说明 (https://developer.mozilla.org/en-US/docs/Web/CSS/font-synthesis)把这件事讲得很直接：用于中文、日文、韩文以及其他表意文字的字体通常不包含这些变体，合成它们可能损害可读性，甚至改变文本的含义。最后半句值得多读一遍——不是变丑，是改变含义。 这条跟做站的直觉是反的：默认行为不是“没实现”，而是“替你编了一个”。 判断有没有走合成，最直接的办法是把同一段文字用真粗体字面和默认设置各截一张图，放大对比笔画的末端。合成出来的粗体，笔画两端会显得圆钝而且粗细均匀；真字面则保留了原本的粗细变化。看过一次就再也不会认错。 ## 合成倾斜会打断连写 问题最严重的是连写类文字。 阿拉伯字母的字形要根据在词中的位置改变形状。 字母之间还要连成一条连续的基线。 整体倾斜之后，连接处的角度全乱了。 读者看到的是一串接不上的笔画。 阿拉伯语的排版与方言那篇 (https://zhangwenbao.com/arabic-seo-rtl-layout-msa-dialect-keyword.html)处理的是版面方向和语言变体，这里是同一门语言在字形层的另一类损伤。阿拉伯语与波斯语排版需求文档 (https://w3c.github.io/alreq/)专门讨论了这类字形连接规则，它解释了为什么倾斜这个动作在这套文字上根本没有对应物。 MDN那一页给的示例代码，恰好就是给阿拉伯语关掉合成。 需要说明的是，这类文字并非没有强调手段。传统上会换用一套结构不同的字体，或者加大字号、改变颜色。这些手段的共同点是不去动字形本身的几何关系，而倾斜恰恰是唯一一个去动它的操作，所以只有它在这里不成立。 实际排查的时候，这类问题往往不是在浏览器里发现的，而是在生成分享图或者导出文件的时候暴露出来。同一段文字换一个渲染环境，合成的规则就变了，字形错乱得更明显。留一条导出通道当探针，比反复截图有效。 ## 合成加粗会把笔画糊在一起 表意文字这边是另一种坏法。 汉字的笔画本来就密，小字号下间距很紧。 描边加粗一上，密集区域的空隙先被填满。 结果是几个笔画粘成一团，字变成一个黑块。 笔画少的字没事，笔画多的字先糊，同一句话里粗细不均。 网页字体的字形集与首屏成本那篇 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)算的是要加载多少字形的账，这里是同一笔账的另一半：你为了省流量只加载了常规字重，代价不是没有粗体，是浏览器替你造了一个质量不受控的粗体。这笔代价不在流量报表上，只在截图里。 真要用粗体，就得老老实实把粗体那一套字面也加载进来。 这一层还有一个常被忽略的连带影响：糊掉的通常是笔画最多的那批字，而笔画多的字在专业术语和品牌名里出现的比例偏高。也就是说，被糊掉的恰好是页面上最不该糊的那几个词，这跟随机分布完全不是一回事。 ## 强调该换成什么载体才不出事？ ## 载体分三层：字符、标记、样式 强调这件事，落到实现上只有三个位置可选。 第一种是直接改字符串，比如在字母之间插空格。 第二种是加标记，比如那对粗体标签。 第三种是写样式，比如那个文字强调属性。 三种都能在页面上做出效果，代价完全不同。 第一种的代价最容易算清楚：凡是改动了字符串本身的动作，机器都会一起读到，软连字符和零宽空格都算在里面。本篇讲的是第二种——标记不改字符串，所以检索层是干净的，但它带来了一个字符层没有的新问题，就是锚点会漂。 第三种的好处是既不动字符串，也没有锚点可漂。 三层之间还有一个撤销成本的排序：字符层的改动散落在每一条数据里，撤回来要动全部内容；标记层集中在模板和富文本字段里；样式层通常只在一两个文件里。选载体的时候，先想清楚三个月后你想撤的时候要动多少东西。 ## 样式载体的好处是不动字符串 用样式实现强调，本质上是把这件事交给了选择器。 选择器可以按语言选，按位置选，按类名选。 按语言选这一点特别有用。 同一个类名，在日语页面上出成傍点，在德语页面上出成粗体。 内容那边一个字都不用改。 用语言属性做样式选择的那篇问答 (https://w3c.github.io/i18n-drafts/questions/qa-css-lang.en.html)把这套写法的注意事项列得很清楚，核心是别用类名去冒充语言，页面上的语言属性本来就该填对。文字强调属性的文档 (https://developer.mozilla.org/en-US/docs/Web/CSS/text-emphasis)则给出了各种记号形状和位置的取值。 这条路的代价是需要前端配合，而且需要有人真的去填语言属性。 这条路还有一个附带收益：强调的样式一旦集中到样式表里，就有了统一调整的可能。想把全站的强调从加粗改成换色，改一行就行；如果强调是散在内容里的标签，那就得重新过一遍所有内容。集中带来的灵活性会被语言数量放大。 ## 每个字包一个标签是最坏的一种 有一种做法要单独拎出来说，因为它看着很聪明。 为了实现傍点效果，有人给每个字都套一层标签。 然后用背景图或者伪元素在每个标签上点一个点。 页面上的效果跟标准做法一模一样。 但正文提取器看到的是一串各自独立的节点。 很多提取实现会在元素边界断词，于是一个完整的词被切成了若干个单字。泰语分词那篇 (https://zhangwenbao.com/thai-seo-no-spaces-word-segmentation-keyword.html)讲的是一门本来就没有空格的语言怎么建词边界，而这里是反过来，一门本来有边界的语言被人为拆掉了边界。这跟俄语打字机时代真敲空格的做法是同一个错误换了件衣服——一个是在字符层插东西，一个是在文档结构层插东西，落到分词那一步的后果没有区别。 判断办法很简单：把渲染出来的页面复制一段文字，粘到记事本里看看还连不连着。 这种做法通常不是前端主动想出来的，而是从某个还不支持文字强调属性的旧浏览器时代继承下来的兼容代码。麻烦在于兼容代码往往没有退场机制，浏览器早就支持原生属性了，那段代码还在跑。定期清一遍历史兼容层，值得排进技术债清单。 ## 把版面手段换成句法手段的三种改写 ## 把要强调的词挪到句首 最省事的一种改写是调整语序。 要强调哪个概念，就把它放到句子最前面。 多数语言里，句首位置本身就带强调功能。 这个位置不依赖任何标记，也不依赖字体。 翻译过去之后，译者会自然地保住这个位置。 之所以能保住，是因为译者处理的是意思不是位置。你要求的是“这个概念要突出”，这是一条译者能理解、能执行、也能自检的指令；而“这两个标签之间要夹住它”不是，那是一条只有工程才看得懂的指令。凡是能用语言本身表达的要求，都比用标记表达的要求更容易穿过语言边界。 代价是句子要重写，而且不是每句话都能这么改。 这一招在语序自由度高的语言上效果最好，比如俄语、波兰语、芬兰语，把成分挪到句首基本不用改动句子的其他部分。语序刚性的语言麻烦一些，往往要改成分裂句或者强调句式，代价高一点，但仍然是译者熟悉的常规操作。 ## 把它单独拆成一句短句 第二种改写更彻底一点。 把要强调的那部分从长句里拆出来，自己成一句。 短句在长句之间天然显眼，不需要任何格式。 这一招在中文和德语上都特别管用。 德语的长句本来就多，一个短句插进去对比强烈。 这种写法还有个副作用是好事：短句更容易被摘出来当答案。长句里的一个粗体词，在被摘引的时候通常连格式一起丢掉；而一个独立的短句本身就是一个完整的语义单元，摘走了还是完整的。 代价是文风会变，得跟内容团队商量。 拆句子还有一个跨语言的好处：句子越短，翻译时语序重排的空间越小，其他类型的错位也跟着减少。写作时把长句拆开这件事，通常被当成可读性优化，其实它同时是一项本地化风险优化，两笔收益是一起拿的。 还有一个很实际的好处：短句在被机器翻译处理时的错位率明显更低，因为可供重排的成分本来就少。如果你的站有一部分内容注定要走机翻，把这部分内容的句子长度压下来，是一项一次性投入长期见效的改动。 ## 换成一个短列表 第三种是把并列的强调点改成列表。 三个要强调的卖点，与其在一段里各加粗一次，不如列三条。 列表的结构是标记表达的，但它的边界是整条不是句内。 整条的边界不会因为语序变化而漂移。如果站内搜索给强调词加了权，记得连权重配置一起复核，光改内容不改配置等于只修了一半。 这是它比句内加粗稳的根本原因。抽样时一定要跨内容来源，营销文案、条款、模板页各抽几条，只抽一类很容易得出错误结论。 顺带一提，列表在被摘引的时候保留率也更高。内链锚文本的形态变体那篇 (https://zhangwenbao.com/minor-language-internal-link-anchor-inflection-variants.html)讲过一个方向相反的招：句内锚在屈折语里做不到精确匹配，就把精确匹配的需求整体挪到列表、卡片、面包屑这些非句内位置上去，把语法问题变成版面问题。这里是反过来的，把版面问题变成句法问题，两条路的共同点是都不硬碰句子内部。风险最高的是源语言与目标语言语序差别大的组合，英语对德语、英语对日语都属于这一类。 列表要用得对，有一条得注意：每条的措辞结构要一致，否则译文里很容易被译成参差不齐的几句话，看着反而不如原来整齐。在给译者的说明里写一句“这几条请保持相同的句式”，比事后返工便宜得多。 ## 怎么扫一遍全站把罩错词的标记找出来？ ## 先扫强调标签里的文本做词频 排查的第一步不需要任何工具，写十几行脚本就够。 把每个语言版本的页面拉下来，抽出所有强调标签之间的文本。 不做分词，先直接按空格切，统计出现频次。 然后把频次最高的三十个词打印出来。还要确认字体文件里真的有粗体那一套字面，只在样式里写了粗体而字体没带，效果一样是合成的。 一眼就能看出这个站在强调什么。 健康的站上，这份榜单顶部应该是品类词、卖点词、材质词。出了问题的站上，顶部会出现冠词、介词、系动词这类东西。这份榜单是整个排查里性价比最高的一步，因为它不需要跟源语言对照，本语言内部就能看出不对劲。 那家户外装备站的德语榜单，前五名里有三个是冠词。可以先在一个品类上试点两周，对比转化和停留数据再决定要不要铺开，这类改动不必一次到位。 这份榜单还有一个副产品：它能顺便告诉你这个语言版本到底在强调什么概念，跟你的关键词策略对不对得上。经常会发现强调最多的是运营顺手加粗的几个形容词，而真正的品类词一次都没被强调过。这跟错位无关，但同样值得改。 ## 功能词占比是最快的信号 把这个观察量化一下，就是一个可以长期盯的指标。 统计强调标签内文本里功能词所占的比例。两个问题同时出现在同一句话上时优先级要提，那通常说明这条链路上的人工环节整个是空的。 功能词就是冠词、介词、连词、代词这一类。 每门语言的功能词表都是封闭的，几十个词而已。 健康值应该很低，因为没人会故意去加粗一个介词。 这个指标的好处是跨语言可比：英语版本的功能词占比是多少，德语版本就该在同一个量级。差出好几倍，基本可以断定有系统性偏移。要注意功能词占比在不同语言之间本来就有基线差异，所以看的是相对倍数不是绝对值。 把它挂到定期任务上，改版之后自动跑一次。 这个指标还可以再拆一层：把强调片段按长度分桶，一个词的、两到三个词的、更长的各算一份占比。错位通常集中在最短的那一桶里，因为短片段一偏就整个偏掉，长片段偏一点还能罩住一部分正确内容。分桶之后信号会干净很多。 ## 跟源语言的同位置对照 前两步能定位到有问题的页面，第三步才能确认。 把源语言和目标语言的同一段落并排放。 各自把强调标签里的文本抽出来。 然后问一个问题：这两组词是不是同一个概念。 这一步没法自动化，需要人看。 但要看的量已经很小了。经过前两步筛选，一个上千页的站通常只剩几十段需要人看，一个懂两门语言的人半天能看完。母语审校验收清单那篇 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)里讲的分级验收思路在这里正好用得上：不是所有内容都值得逐句核，值得核的是那些自动检查覆盖不到的维度。 人看这一步的时候，判断标准要写得极简单，只留对和不对两个选项，别让人当场写理由。理由留到统计完再补。判断和解释分开，看的速度会快好几倍，而且判断的一致性反而更高，这是做任何人工标注都适用的一条经验。 ## 这套排查该怎么排进本地化流程？ ## 在验收单上加一条标记锚点 长期解法只有一条：把它变成一个验收项。 验收单上加一行，写清楚要核的是什么。 措辞很重要，别写成“检查格式是否正确”。 要写成“确认加粗罩住的是源文强调的那个概念”。 前一种写法谁都会打勾，后一种写法必须真去看。 保哥的经验是，验收单上的条目措辞决定了它会不会被认真执行。凡是可以在不看内容的情况下打勾的条目，最终都会在不看内容的情况下被打勾，这跟执行者是否负责没有关系，是条目设计的问题。 这一条还可以再加一个约束，就是留下证据：要求勾选的人贴一张源文与译文强调部分的对照截图，附在验收记录里。有没有真看过，从拿不拿得出证据就知道了。这个要求不会增加多少工作量，但会明显改变执行的质量。 措辞之外还有一个细节：这一条要放在验收单靠前的位置。放在最后一条的检查项，被草草打勾的概率显著高于前几条，这跟内容无关，是清单本身的行为规律。把最需要动脑的那几项放前面，是清单设计的常识。 ## 这一项该由谁来看 看的人必须同时懂源语言和目标语言。 纯母语审校看不出来，因为他们手上没有源文。 纯工程也看不出来，因为他们读不懂那句话。采购来的内容还要多查一处：对方交付时用的强调规范可能跟你的不一样，合并前先统一一遍。 最合适的是做译审的那个人，或者项目经理。 这一项加进去，每批内容多花不了多少时间。 需要提前把材料准备好：源文和译文的强调部分要抽好、并排放好，别让人自己去页面上找。准备材料这一步可以脚本做，看的人只负责判断。把判断和检索这两件事分开，是让人工环节不失控的通用办法。 如果项目上实在没有同时懂两门语言的人，还有一个折中办法：让母语审校只看目标语言那一侧，判断被强调的词在这句话里算不算一个有意义的强调对象。介词、冠词、系动词被强调，母语者一眼就看得出不合理，不需要看源文。 ## 每次改版之后重新跑一遍 这类问题有个特点，会随改版复发。 模板改一次，加粗的位置可能整体挪一格。 内容批量重灌一次，之前修好的又可能被覆盖回去。 所以一次性排查是不够的，得变成周期动作。 周期不用太密，跟着发版走就行。 前面那个功能词占比指标在这里就体现出价值了：它足够便宜，可以每次发版都跑；跑出来是个数字，可以画成一条线；线一抬头就知道该去查了。真正难的从来不是修，是知道什么时候该去修。 还有一类触发时机容易被漏掉：翻译记忆库的批量更新。库里的旧句段被替换之后，下一批内容会大面积复用新句段，如果新句段里的标记位置本身就是错的，错误会被成倍复制出去。库的更新应该跟发版一样，也触发一次检查。换个角度说，它伤的不是搜索引擎对你的判断，而是你自己系统里那几个依赖强调信号的环节。 发版之外还有第三类触发点：换字体。换了字体之后，原本有粗体字面的语言可能变成没有，页面上的加粗从真字面悄悄退化成合成。这一类退化在功能词占比指标上完全看不出来，只能靠截图对比，换字体时要单独过一遍。 ## 什么情况下这件事可以先放着 最后说一句反方向的话，免得排查变成负担。 如果你的站上根本没有句内强调，这件事跟你无关。 如果所有语言版本都是各写各的原创，也不用管。看的时候顺便记一下错位的方向，是整体右移还是罩到了冠词上，方向一致说明是同一个原因。 只有当格式是跟着内容一起跨语言搬运的，风险才存在。 判断只要一句话：这个页面的格式，是有人在这门语言里重新决定的，还是从别的语言继承来的？另外句子里的从句数量也是个好用的预警，超过两个从句的句子，格式基本别指望能自动摆对。 继承来的就查，重新决定的就不用。这条判据可以推广到很多本地化问题上：凡是从源语言继承而来、在目标语言里没有人重新做过一次决定的东西，都是高风险项，格式只是其中一类，字段结构、图片、数值单位、链接目标都适用同一条判据。 还有一种情况可以先放：站上语言虽多，但强调只出现在标题和小标题这类整段位置。这类位置的边界跟句子边界重合，天然不会漂移。判断只要看一眼富文本字段里强调标签的位置分布，全都落在段首段尾就基本安全。还有一点，中日文页面上少量加粗最有效，满屏加粗等于没加粗，这在哪门语言里都一样成立。 ## 常见问题解答 ## 加粗标签罩错了词，会直接影响排名吗？ 直接的排名影响很小，主流搜索引擎早就不把加粗当成强相关性信号了。真正的影响在两个别的地方。一是被摘引的时候，很多摘要生成会优先取被强调的片段，罩错了词意味着摘要里出现的是个介词。二是站内搜索和内部权重计算，如果你的搜索实现给强调词加了权，那这个权重就加错了对象。所以它不是一个排名问题，是一个表现问题加一个内部数据问题。真要保留句内强调，至少把强调对象在术语库里登记一次，让译审知道这句话该突出哪个概念。 ## 怎么快速判断我的站上有没有这个问题？ 最快的办法是抽三个页面手动看。挑那种商品描述里有句内加粗的页面，把英文版和目标语言版并排打开，各看一眼加粗的是哪个词。三个页面里有一个对不上，就说明存在系统性问题，值得跑全站扫描。三个都对上也别急着放心，换一个内容来源再抽三个，特别是条款类和模板类的页面。这一步花不到二十分钟，比读任何一份报告都直接。如果只能修一个，先修那些出现在商品页首屏和条款页的，这两处的每一次错位都直接对着用户。页面上没有源文的时候，先看目标语言那一侧够不够合理，也能筛掉一大半。 ## 用机器翻译的站，标记错位是不是必然的？ 不是必然，但概率明显更高，而且跟句子长度强相关。短句和标题基本不会出错，长句、带从句、带并列结构的句子出错率高得多。如果一定要用机器翻译，一个可行的折中是把带格式的句子单独挑出来，把格式先剥掉再翻译，翻完人工把格式加回去。剥格式这一步可以自动做，加回去这一步必须人做，但需要人做的量已经很小了。还有一条经验，同一批内容里句子最长的那百分之十，值得单独抽出来人工过一遍。 ## 日语和中文页面上到底能不能用加粗？ 可以用，加粗在这两门语言里都是被接受的强调方式，只是要确认你加载的字体真的带粗体字面。斜体则建议直接避开，效果不好而且读者不习惯。如果想更地道一点，可以用文字强调属性做傍点或者着重号，这是这两门语言的传统做法，浏览器支持已经足够好。需要注意的是傍点会占用行外的空间，行高要留够，否则会跟上一行挤在一起。另外这两门语言里，加粗和着重号不要在同一段里混用，读者会以为它们表示不同的层级。 ## 把强调改成句法手段，会不会影响文案的表现力？ 短期看会有一点，因为写惯了加粗的人会觉得句子平了。但这件事有个补偿：句法手段是所有语言都有的，改完之后各语言版本的表现力是一致的；而版面手段在有些语言里本来就打折扣，改之前的一致性是假的。实际操作中不必一刀切，营销页面可以保留句内强调但单独走一遍核对，条款和模板类内容优先改成句法手段，两条路并行成本最低。实际推进时，先在新写的内容上执行新规范，存量内容随改版顺手改，别单独立一个清理项目。 ## 标记漂移和术语不一致，哪个更值得先修？ 术语不一致优先，因为它同时伤可读性和检索，而且用户看得见。标记漂移排第二，它只在检索和表现层面有影响，用户基本无感。但两者的修复成本不一样：术语不一致要重写句子，标记漂移多数情况下只要移动两个标签的位置。所以实际排期上可以并行——术语交给译审慢慢改，标记交给脚本先把清单拉出来，谁有空谁先动。还有一点，标记漂移修完之后要顺手复核一次，别让修的人凭直觉把标签挪到了另一个错的位置。 ## 只有一种语言版本的站需要担心这件事吗？ 基本不用。这个问题的根源是格式跨语言搬运，单语言站上格式是在同一门语言里决定的，不存在漂移。但有一个例外值得注意：如果你的单语言站用了从别处买来或者翻译过来的内容，哪怕最后只发一种语言，中间也经过了一次跨语言搬运，风险照样存在。判断依据仍然是那一条，看这段内容的格式有没有人在最终语言里重新决定过。还有一种情况要留神，站上如果嵌了第三方评价或者问答插件，那部分内容的格式也不归你决定。另外一种要留意的情况是自动生成的摘要，它可能保留了原文的格式而丢掉了上下文。 ## 权威参考资料 ## 小语种内容里有多少是从别的语言搬来的，越南语近一半，波兰语只有0.22% - URL：https://zhangwenbao.com/minor-language-content-translated-share.html - 分类：小语种SEO - 发布：2020-02-20 | 更新：2020-04-02 - 摘要：40门语言2019年译入率实测：越南语47.43%最高，波兰语0.22%最低；希腊语与爱沙尼亚语条目数只差4%，译入率却差46倍。四个现成指标相关系数全为零。 - 关键词：竞品分析,多语言SEO,内容运营,小语种SEO > **TLDR**：摘要：把40门语言2019年新建的条目逐条翻出来，数其中有多少是用官方翻译工具从别的语言搬进来的，得到一条译入率。排最上面的是越南语47.43%，最下面的是波兰语0.22%，两门语言体量都在百万级，差213倍。更要命的是希腊语和爱沙尼亚语：条目总数只差4%，译入率一个18.33%一个0.40%，差46倍。手上现成的四个指标——条目总量、当年新建量、建页者人数、爬虫流量占比——跟译入率的相关系数分别是0.010、0.045、0.056、0.072，四个零。来源语言也不像想的那样：老挝语的第一来源是泰语占64%，亚美尼亚语是俄语占76%，斯瓦希里语是简明英语占54%。很多语言的译入工作是个位数的人在干，豪萨语4个、老挝语5个。本文给出完整排行、四条相关系数、成对反例，以及在没有标记的商业市场上怎么把同一个数估出来。 > 摘要：把40门语言2019年新建的条目逐条翻出来，数其中有多少是用官方翻译工具从别的语言搬进来的，得到一条译入率。排最上面的是越南语47.43%，最下面的是波兰语0.22%，两门语言体量都在百万级，差213倍。更要命的是希腊语和爱沙尼亚语：条目总数只差4%，译入率一个18.33%一个0.40%，差46倍。手上现成的四个指标——条目总量、当年新建量、建页者人数、爬虫流量占比——跟译入率的相关系数分别是0.010、0.045、0.056、0.072，四个零。来源语言也不像想的那样：老挝语的第一来源是泰语占64%，亚美尼亚语是俄语占76%，斯瓦希里语是简明英语占54%。很多语言的译入工作是个位数的人在干，豪萨语4个、老挝语5个。本文给出完整排行、四条相关系数、成对反例，以及在没有标记的商业市场上怎么把同一个数估出来。 做小语种排期，第一步几乎都是抄一张表：这门语言的公共内容有多少条。数大就写“竞争激烈”，数小就写“机会窗口”，然后往下排预算。 这张表确实好抄，一分钟就能拿到。问题是它只有一列，就是条数。 条数不告诉你这些内容是怎么来的。同样是十万条，可能是几百个当地人花十几年一篇篇写出来的，也可能是十几个人拿翻译工具从英文批量搬过来的，还可能是一段脚本在三个月里灌出来的。这三种情况对你的意义正好相反，而在那张表上它们长得一模一样。 所以这次不数条数，数来路。 ## 内容量这个数，为什么答不了这些内容是从哪来的？ ## 你抄下来的那张表只有一列 公开的各语言版本条目数对照表 (https://meta.wikimedia.org/wiki/List_of_Wikipedias)给的是条目总数，外加编辑次数和用户数。这几列都是规模的度量，没有一列是来源的度量。 规模能回答“这块地被开垦了多少”，回答不了“地里的庄稼是本地种的还是外面运来的”。做市场判断的时候，你真正要的其实是后一个答案。 更麻烦的是，规模这一列会给你一种虚假的确定感。数字精确到个位，看着特别硬，于是很少有人再往后追一步。硬的是格式，不是它回答问题的能力。 这个错我自己犯了好几年，一直用到发现两门条目数几乎一模一样的语言，内容池的性质可以完全相反。那次之后我才意识到，我一直在用一把只有一个刻度的尺子量三样东西。 ## 同样是十万条，来路可以完全不同 把来路粗分一下，大致三种。一种是本地人一点一点写出来的，写的是本地关心的东西，用的是本地的说法。 第二种是从别的语言译过来的，选题跟着源语言走，结构也跟着源语言走，本地特有的话题基本不在里面。 第三种是程序批量造的，从数据库里拼出几百万个条目，内容框架统一，没有人读也没有人改。这一类在几门语言上把总数撑到了离谱的位置。 三种混在一起，总数就成了一个把三件事加在一块儿的数。加法本身没错，错在你后面拿它做减法。 ## 三种来路对你的意义正好相反 如果对手的内容是本地原生长出来的，那说明这个市场有真实的内容生产能力，你进去要跟真人抢，选题上也占不到便宜。 如果对手的内容是从英文译过来的，那它继承的是英文市场的选题清单。本地特有的需求，那批内容多半没覆盖，那就是你的空位。 如果对手的内容是程序灌的，那它连读者都没有，竞争强度实际上接近于零，可你从总数上看到的却是“已经很厚了，别进”。这一档最亏，因为你放弃的是一个几乎不设防的市场。 判错的代价不是少赚一点，是把一个几乎没人守的入口整个让出去。这一层跟语言优先级的成本模型 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)是接在一起的，成本那边算得再细，输入项错了也白算。 ## 这件事在英文市场几乎不用问 英文内容基本都是英文原生的，译进来的比例小到可以忽略，所以英文市场的从业者从来不需要问“这些内容是不是搬来的”。 这套习惯被原封不动带到了多语言市场。表格照抄，判断照做，唯独漏掉了那一问——因为提出这套方法的人从来没有需要问过它，自然也不会在方法里留一个位置给它。 这也是很多英文教程搬到小语种市场上就失灵的原因之一。不是教程写得不好，是教程成立的前提里有一条没写出来的默认值，而这个默认值在小语种上不成立。 ## 怎么在外面量出一门语言的内容有多少是搬来的？ ## 需要一个会自报家门的样本 难点在于，翻译过来的内容不会在页面上贴个标签说“我是译文”。你从外面看，一篇译得还行的稿子和一篇本地写的稿子，长得差不多。想按语言统计，就得先找到一批已经知道答案的样本。 但有一个地方例外。维基媒体给编辑者提供了一个官方的跨语言翻译工具 (https://www.mediawiki.org/wiki/Content_translation)，用这个工具建出来的条目，系统会自动在修订记录上打一个标记，而且这个标记对所有人公开可查。 这就有了一批自报家门的样本。它当然不是商业站，但据我所知，它是目前唯一一个能按语言、按时间、按条拿到“有多少内容是从别处搬来的”这个数的公开来源。别的地方要么没有这个字段，要么不对外。 所以我把它当代理指标用。绝对值不能直接搬到商业市场上，但语言之间的相对关系可以看，因为影响一个语言社群对待外来内容态度的那些因素，在维基和在商业站上是同一批。 ## 分子：带翻译标记的新建条目 具体做法是查页面创建日志 (https://www.mediawiki.org/wiki/API:Logevents)，把时间窗口卡在2019年整年，命名空间限定在正文，再按翻译工具那个标记过滤一遍，翻页一直翻到没有下一页为止。 每一条日志里还带着一句编辑摘要，格式是固定的“由翻译某某页面创建”，源语言的代码就写在方括号里。所以来源语言这一列不用另外查，跟着分子一起就拿到了，这也是我敢在一批数据里同时做两件事的原因。 重定向要单独剔掉。重定向在日志里也算一次新建，但它没有正文，留在里面只会把分母撑大，而且各语言创建重定向的习惯差别很大，不剔的话这个差别会直接污染比例。 翻页这一步有个坑。接口每页最多给500条，条数多的语言要翻几十上百页，中途要是设了页数上限就停，结果会被系统性低估。我在脚本里加了一条到底判定，没翻到底的语言会被单独打上标记，事后能查出来是哪一门。 ## 分母：同一份日志里的新建条目 分母是同一段时间、同一个命名空间、同样剔掉重定向的全部新建条目。也就是说，分子是分母的一个真子集，两者出自同一次查询，只差一个过滤条件。 听起来是句废话，但我第一版就是在这里翻的车。第一版的分母用的是另一个接口给的“新建内容页”月度统计，分子用的是日志，结果两个口径对不上。 对上账才发现，日志口径的新建数比统计接口高出1.27到2.38倍不等，40门语言没有任何两门的比值是一样的。越南语按统计接口算是73.85%，按同源口径算是47.43%。这两个数会写出两篇不同的文章。 26个百分点的差距，足够把一篇文章的结论从“将近四分之三”改成“将近一半”。 ## 为什么分子分母必须来自同一个地方 两个接口的定义几乎不可能完全一样。这个把重定向算进去，那个不算；这个要求页面里至少有一条内链才算内容页，那个不要求。 单看任何一个都没错，凑成分数就错了。而且错的幅度还随语言变，所以你连“统一乘一个系数修正一下”都做不到。 这条不是维基特有的。你在自己站上算“翻译页占比”的时候，分子从翻译系统导出、分母从内容管理系统导出，是同一个坑。 判据很简单：分子分母必须能追到同一张表、同一次查询，追不到就别做除法。实在只能跨源，那就把两个口径的定义逐条列出来比一遍，比不出来的差异就当成误差写进正文，别藏着。 ## 这个数是下限，不是全貌 只有用官方翻译工具建的条目才带标记。有人把英文页面复制到编辑框里手工改改就发出去，这种一条标记都没有。 所以算出来的译入率一律是下限。真实的译入比例只会更高，不会更低。 这一点在解读时很关键：低译入率可以是“这门语言真的很少从外面搬”，也可以是“这门语言的编辑者不习惯用那个工具”。这两种情况我分不开，所以正文里凡是涉及低端的结论，我都留了这个口子；涉及高端的结论则是安全的，因为下限高就说明真值更高。 还有一条时间上的限制。页面创建日志是2018年年中才开始记录的，所以在我的截断点之前，能完整覆盖的整年只有2019一年，没法做同比。 ## 40门语言的译入率排出来是什么样？ ## 排在最上面的五门 越南语47.43%排第一，2019年新建的55433条正文条目里有26291条带着翻译标记。将近一半。 后面依次是马其顿语34.02%、约鲁巴语30.71%、泰米尔语28.37%、希腊语18.33%。马拉雅拉姆语18.21%紧跟着。 这五门里，越南语和泰米尔语的体量在十几万到一百多万条，属于中大型；约鲁巴语只有不到4万条，马耳他语更小，只有7889条。大小混在一起，排不出任何规律。这一点在我看到排行的第一眼就该警觉，可惜当时还在忙着核对数字。 越南语这个数值得单说。越南语市场本身的搜索需求相当健康 (https://zhangwenbao.com/vietnamese-seo-tone-marks-syllable-spacing-keyword.html)，声调符号那一层的复杂度也逼着你做本地化，可它的公共内容池里有将近一半是译进来的。需求旺盛和内容原生，是两件事。 ## 排在最下面的五门 最下面是波兰语0.22%，2019年新建了80561条，其中只有179条带翻译标记。 往上是爱沙尼亚语0.40%、冰岛语0.58%、乌兹别克语0.61%、高棉语0.97%。拉脱维亚语1.08%。 波兰语的建页者有15110人，是个非常活跃的写作社群。波兰语本身的语法复杂度 (https://zhangwenbao.com/polish-seo-seven-cases-diacritics-keyword-research.html)也决定了机器翻译在这门语言上代价不低，这两件事叠起来，社群更倾向于自己写。 爱沙尼亚语和拉脱维亚语挨着，都是两百万人口上下的市场，译入率一个0.40%一个1.08%，都在低位。冰岛语0.58%也在这一带。北欧和波罗的海这一片整体偏低，而这几个市场的英语普及率恰恰是全世界最高的那一档——想搬的人本来可以直接读英文，反而没人去搬。 ## 中位数落在3.4% 40门语言的译入率中位数是3.4%。也就是说一半的语言在3.4%以下。 超过10%的有10门，低于2%的有12门。剩下18门散在中间。 这个分布很宽，从0.22%到47.43%，整整跨了两个数量级。一个跨度这么大的变量，你要是完全不看它，等于在决策里默认它是常数。把一个跨两个数量级的东西当常数，代价迟早要还。 ## 小语种散在中间，没有集中在任何一头 我原以为语言越小越依赖翻译，这个预期错得很彻底。 老挝语3.04%、僧伽罗语3.39%、缅甸语3.42%、阿姆哈拉语3.31%、蒙古语1.95%、高棉语0.97%——本站写过专篇的这几门，全都在中位数附近或者更低。 反过来，条目数超过一百万的越南语排第一，一百七十万的波兰语排最后。语言的大小在这条轴上完全不起作用。 想明白之后其实不难解释：搬运这件事需要有人来搬。最小的那几门语言连搬运工都凑不齐，自然搬不进来多少。内容少和内容是搬来的，是两个独立的事实，我把它们当成一件事了。 ## 完整排行 档位 | 语言与译入率 | 10%以上（10门） | 越南语47.43、马其顿语34.02、约鲁巴语30.71、泰米尔语28.37、希腊语18.33、马拉雅拉姆语18.21、孟加拉语15.11、阿尔巴尼亚语12.45、希伯来语11.65、马耳他语10.91 | 5%到10%（8门） | 土耳其语8.82、波斯语6.43、乌尔都语6.27、宿务语5.85、尼泊尔语5.66、中文5.56、泰语5.13、日语5.05 | 2%到5%（10门） | 豪萨语3.56、缅甸语3.42、僧伽罗语3.39、阿姆哈拉语3.31、老挝语3.04、斯瓦希里语2.83、韩语2.53、印尼语2.29、瑞典语2.18、马拉地语2.12 | 2%以下（12门） | 蒙古语1.95、格鲁吉亚语1.75、阿塞拜疆语1.69、亚美尼亚语1.56、荷兰语1.49、瓦瑞语1.30、拉脱维亚语1.08、高棉语0.97、乌兹别克语0.61、冰岛语0.58、爱沙尼亚语0.40、波兰语0.22 | ## 条目数差不了几个百分点的两门语言，译入率能差多少？ ## 希腊语和爱沙尼亚语 希腊语271533条，爱沙尼亚语261148条，条目总数差4%。这两门语言在任何一张按规模排的表上都会挨着。 译入率一个18.33%，一个0.40%，差46倍。 把它们放在一起看，规模这个变量被控制住了，剩下的差异只能来自别的地方。希腊语这门语言的拉丁转写问题 (https://zhangwenbao.com/greek-seo-greeklish-latin-transliteration-coverage.html)我另外写过，那是文字层的事，跟内容来源不是一回事，两者在数据上也没有交叉。 这一对是我手上最干净的对照组，因为体量差得最小。两门语言的人口规模、经济体量、互联网普及程度都不一样，但那些差异要解释46倍，需要一条我说不清楚的机制；而“有没有一群人在做这件事”能一句话解释完。 ## 泰米尔语和格鲁吉亚语 泰米尔语189089条，格鲁吉亚语197745条，差5%。译入率28.37%对1.75%，差16倍。 两门语言都是非拉丁书写系统，都有独立的字符集，都属于“工具支持一般”的那一档。文字层的条件相近，行为层差了一个数量级。 泰米尔语的2430条译文出自101个人，格鲁吉亚语的188条出自45个人。人数差2.2倍，产出差13倍。所以不只是人多人少的问题，还有人均强度的问题——泰米尔语那边人均24条，格鲁吉亚语人均4条。 ## 越南语和波兰语 越南语1304025条对波兰语1703412条，体量差31%，译入率差213倍。这是全表跨度最大的一对。 两门语言都有几千万使用者，都有完整的现代书面标准，都有活跃的互联网社群。你能想到的宏观变量基本都对得上。 差别在于两个社群怎么干活。越南语那边26291条译文由339个人完成，人均78条，是一年到头都在译的节奏；波兰语那边15110个建页者里只有26个人碰过翻译工具，占比0.17%。同样是百万级的内容池，一个是翻译出来的，一个是写出来的。 ## 成对样本比相关系数更有说服力 相关系数是一个把所有点压成一个数的做法，压完之后你看不见极端案例。成对样本正相反，它把两个几乎相同的样本摆在一起，让差异自己说话。 我这次两个都做了，结论一致。但如果只能留一个给读者看，我会留成对样本。 顺带一提，这也是个写法上的经验：一句“相关系数是0.01”很难让人记住，一句“条目数差4%，译入率差46倍”能记住。汇报的时候两个都放，让相关系数负责严谨，让成对样本负责被记住。 ## 手上现成的那几个指标，有没有一个能推出译入率？ ## 条目总量：0.010 取条目总数的对数，跟译入率算皮尔逊相关，结果是正0.010。秩相关是负0.059。 怕是被极端值压平了，我又切了两刀：剔掉样本量不足的语言之后是负0.170，只看条目数在1万到30万的中间档是正0.201。 怎么切都在零附近来回摆，连符号都不稳定。这不是弱相关，这是没有关系。弱相关至少方向是固定的，能当个粗糙的先验用；符号会翻的东西连先验都当不了。 ## 当年新建量与建页者人数 换成当年新建条目数，相关系数是0.045。换成建页者人数，是0.056。 这两个指标比总量更接近“当下的活跃度”，按理说更有可能跟译入行为挂上钩。实测也没有。 所以不是“总量这个数太陈旧”的问题。我本来的猜测是总量记录的是历史、活跃度记录的是当下，换成当下的量应该能对上。实测两个都不行，说明问题不在时间尺度上，而在这两类指标压根就不测这件事。 ## 爬虫流量占比：0.072 还有一个我本来挺看好的指标。各语言的访问量里机器占多少 (https://zhangwenbao.com/minor-language-crawler-share-traffic-report.html)这个数我另外量过一轮，直觉上它跟“内容是不是人写的”应该沾边。 把两份数据对起来，27门语言，相关系数正0.072。又是零。 回头看这也合理：爬虫是按页数来的，一页内容是译的还是写的，对抓取程序没有任何区别。两条轴各管各的，我把它们联系起来纯粹是因为它们都带着“这些内容不太对劲”的味道。味道相似不等于机制相关。 ## 四个零意味着什么 四个现成指标全部落空，说明译入率是一条独立的轴。它不能从别的数推出来，只能单独去量。 对做决策的人来说这是个坏消息也是个好消息。坏消息是又多了一件要做的事；好消息是既然大家都没量，那么量了的人就多一个别人没有的判断依据。 我给自己定的规矩是：凡是要在某门语言上投超过一个季度的预算，这个数就必须先估一遍。估得糙一点没关系，量级对就行——毕竟这条轴上的差异是几十倍量级的，你就算估错一倍，也比完全不估强得多。 ## 搬进来的内容是从哪门语言来的？ ## 大多数语言的答案是英语 先说符合预期的部分。40门语言里，绝大多数的第一来源是英语，而且占比很高：泰米尔语99.8%、孟加拉语99.6%、越南语99.3%、马拉雅拉姆语99.0%、波斯语97.0%、约鲁巴语97.4%。 豪萨语更极端，55条译文全部来自英语，来源语言只有一种。 英语在这条链路上是事实上的中转站。这意味着这些语言的公共内容里，选题清单基本就是英语市场那一份，连详略比例都跟着走。对手的地图不在本地，在英文那边。 ## 老挝语的第一来源是泰语 不符合预期的开始了。老挝语的11条译文里，7条来自泰语，4条来自英语。第一来源是泰语，占64%。 宿务语更奇怪，19条里12条来自泰语，占63%。这一条我抽出来看了标题，全是泰国政治人物的条目，出自同一个用户。 这两门语言的样本都太小，11条和19条不能拿来下任何统计结论，我把它们从主表里单列出来了。但当个案看还是有意思的：地缘和个人，都会在这条数据上留下印子。 老挝文和泰文本来就是同源的两套文字，字形和码位都挨着，两个市场的内容互通比跟英语互通容易得多。这一点跟泰语那套无空格分词的机制 (https://zhangwenbao.com/thai-seo-no-spaces-word-segmentation-keyword.html)是同一个语族背景。 ## 亚美尼亚语的第一来源是俄语 亚美尼亚语的样本量够：336条译文，其中255条来自俄语，占76%；英语只有77条，占23%。 乌兹别克语也是俄语第一，23条里俄语10条、英语10条，俄语略多。阿塞拜疆语的分布最散：英语47%、土耳其语26%、俄语22%。 这三门语言都在俄语的历史影响范围内，数据把这层关系照得很清楚。做这几个市场的时候，你的竞争对手继承的可能是俄语内容的选题，不是英语的——你拿着英文的话题清单去对，会对不上，然后误以为这个市场很空。 俄语跟这几门语言的关系，我在双语市场的内容拆分 (https://zhangwenbao.com/ukrainian-russian-seo-bilingual-market-content-split.html)那篇里从另一个角度讲过，那边讲的是同一个市场内两门语言怎么分工，这边讲的是跨市场的内容流向。 ## 斯瓦希里语的第一来源是简明英语 这一条是全表最出乎意料的。斯瓦希里语215条译文里，117条来自简明英语那个版本 (https://simple.wikipedia.org/wiki/Wikipedia:About)，占54%；常规英语只有77条，占36%。 简明英语是一个用受限词汇表和短句写成的独立版本，同一个话题它的篇幅通常只有常规版的三分之一到一半，句式也刻意压得简单。选它当源语言，翻译的工作量小一大截。 更有意思的是，这117条出自同一个编辑者。也就是说，一门语言超过一半的译入内容，来自一个人的一个工作习惯。这个人换个源版本，第二年整门语言的来源构成就变了。 这条对实操有个直接提示：如果哪天你在某个小市场上发现对手的内容读着特别浅、句子特别短、专业术语少得反常，别急着判断对方水平不行，先想想是不是源头就不是完整版。 ## 还有几条不那么显眼的支流 除了上面几个大的，还有几条份额不高但方向明确的支流。尼泊尔语112条译文里，英语84条占75%，印地语27条占24%——印地语是尼泊尔的邻国语言，也是很多尼泊尔人的第二阅读语言。 乌尔都语588条里，英语515条，旁遮普语47条占8%。旁遮普语跟乌尔都语在同一个国家，共用一套书写系统的大部分字母，互译的门槛比跟英语低得多。 土耳其语1779条里，英语1431条占80%，德语254条占14%。德语这个14%在整张表上很扎眼，因为德国跟土耳其之间没有语言学上的亲缘关系，有的是几百万人的移民社群。土耳其语本身那套后缀叠加的机制 (https://zhangwenbao.com/turkish-seo-agglutinative-suffix-stacking-keyword.html)跟德语毫不相干，所以这14%只能用人来解释。 马其顿语2149条里，英语1318条占61%，塞尔维亚语455条占21%。这一对是同一个语族里挨得最近的两门语言之一，译起来几乎是改写。 ## 来源语言的种类数是另一个维度 除了第一来源是谁，还有一个数：一共从多少门语言译进来。 希腊语的来源有29种，日语26种，中文26种，波斯语23种，马其顿语21种。这些是“从四面八方吸内容”的类型。 另一头，豪萨语1种、尼泊尔语3种、约鲁巴语4种、泰米尔语6种、马拉雅拉姆语6种。这些是“只有一条管道”的类型。 两种结构对你的意义不一样。管道单一的市场，你只要把那一条管道上的内容看一遍，就大致知道对手手里有什么；来源分散的市场，这招不好使，得换成从需求侧倒推。管道越单一，情报成本越低。 ## 一门语言的内容是几个人搬进来的？ ## 个位数的译者 把每条译文的建者去重，得到译者人数。这个数比我预想的小得多。 豪萨语4人、瓦瑞语4人、老挝语5人、马耳他语6人、阿姆哈拉语8人、宿务语8人、高棉语9人、斯瓦希里语12人。 换句话说，在这些语言上，“把外面的内容搬进来”这件事是一个可以数得过来的小圈子在干。其中任何一个人停手，这门语言的内容来源构成就会变。 这跟内容生产的常识不太一样。我们习惯把一门语言的内容池当成一个大集体的产物，实际上在长尾语言上，它更像几个人的作品集。你以为在跟一个市场竞争，其实是在跟五个人的业余时间竞争。 ## 越南语的339个人 另一头，越南语26291条译文出自339个人，人均78条。这已经是有组织的规模了。 马其顿语2149条出自195人，泰米尔语2430条出自101人，希腊语3342条出自174人。这几门都是几百人量级的翻译群体。 有组织和没组织，才是译入率高低的直接原因。不是语言大小，不是市场规模，不是经济体量，是有没有一批人在持续做这件事，以及这批人有多少。这个变量在任何一张公开的语言对照表上都没有一列对应。 ## 译者占建页者的比例 换个口径看：译者人数占全部建页者的比例。 波兰语26比15110，是0.17%；印尼语253比6654，是3.8%；越南语339比11509，是2.9%；马其顿语195比526，是37%。 马其顿语这个37%很扎眼——建页的人里超过三分之一碰过翻译工具。这门语言的内容池，性质上更接近一个翻译项目而不是一个写作社群。它的总条目数16万，跟拉脱维亚语的14万挨着，但这两个16万和14万完全不是一回事。 顺带说一句，这个比例跟条目总数的相关系数是负0.179，还是接近零。规模这个变量在本文里已经连续第五次不起作用了。 ## 这个结构意味着什么 如果一门语言的内容来源掌握在几个人手里，那么这个市场的内容格局是不稳定的。一次社群活动、一个人的兴趣转移，都能让下一年的构成完全不同。 对你的实际影响是：小语种市场的内容供给不能按线性外推。今年薄不代表明年薄，今年厚也不代表明年还厚。 所以这个数要定期重算，不能测一次用三年。我自己的节奏是一年一次，赶上市场有大动作就随时补测。对比一下，条目总数这种指标测一次能用很久，因为它变得慢——变得慢的指标好用但没信息量，变得快的指标有信息量但得勤快点。 ## 这个数在做小语种决策的时候怎么用？ ## 高译入率市场的机会在哪 译入率高，说明公共内容里很大一部分是跟着源语言的选题走的。源语言那份清单上没有的东西，本地内容池里大概率也没有。 具体到操作上，就是去找“本地特有、源语言不会写”的话题：本地法规、本地节庆、本地支付习惯、本地尺码和度量、本地品牌的对比。这些在译入内容里是天然的空白。 这条跟同一门语言在不同市场的搜索意图分叉 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)是配套的：意图分叉告诉你哪些需求本地独有，译入率告诉你这些需求有没有被覆盖。 越南语是最典型的例子。将近一半的公共内容来自英语，那么越南本地特有的话题，实际竞争强度会明显低于总量给你的印象。总量告诉你这是个130万条的大市场，来源构成告诉你其中有60多万条的选题不是本地定的。 ## 低译入率市场要先问为什么低 译入率低有两种完全不同的原因。一种是本地写作社群强，自己就能产内容，波兰语属于这一类。另一种是根本没人做这门语言，连搬运工都没有。 这两种情况的应对方式正好相反。前者你要跟真人抢，得拿出真本事；后者你几乎没有竞争，但也要先确认有没有读者。 分辨方法是看建页者人数。波兰语15110人和高棉语356人，同样是低译入率，性质完全不同：前者是“有人写所以不用搬”，后者是“没人写也没人搬”。同一个低数值，两种相反的市场。 这一层要跟需求侧的数据一起看，光看供给侧会做出错误判断。关键词工具在小语种上没数据的时候怎么办 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)那篇讲的就是需求侧怎么估。 ## 来源语言告诉你对手继承了谁的选题 知道第一来源是谁，你就知道去哪儿看对手的选题清单。 第一来源是英语，你看英语市场那批内容；第一来源是俄语，你看俄语的；亚美尼亚语这种76%来自俄语的，你去翻英文资料是找不到对应关系的。 这个动作成本很低，收益很直接。翻一遍源语言那边的高频话题，就能大致预测本地内容池里有什么。 反过来，在源语言那边冷门、在本地却是刚需的话题，就是最值得先做的那一批。这类话题的特征通常很好认：跟本地的钱、证件、时间表、气候、宗教节令有关，而这几样恰恰是源语言市场不会花篇幅写的。 ## 别把译入率当成质量指标 要说清楚一件事：译入率高不等于内容差。用官方工具翻译的条目，是有人一段段过过的，不是机器直出。 机器翻译直接发上线的风险 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)是另一回事，那篇讲的是省掉审校那道工序的代价，跟这里说的“内容从别的语言来”不是同一个问题。搬来的内容也可以质量很好。 译入率是来源指标，不是质量指标。把它当质量指标用，会得出“越南语内容质量差”这种既不成立又没用的结论。 它真正回答的问题只有一个：这些内容的选题是谁定的。把这个问题跟质量、跟规模、跟需求分开，这个数才有用；混在一起，它就变成又一个让人点头但不改变任何决定的数字。 ## 三档判读线 我按这次的数据给自己划了三条线，供参考。 译入率在2%以下，把这个市场当成本地原生市场处理，选题上不要指望有系统性空位，重点转到深度和更新频率上。 2%到10%之间，混合市场，本地特有话题上有零散空位，值得挑着做。 10%以上，把源语言的选题清单直接当成对手的地图，重点全部放在这张地图之外。越靠近本地日常生活的话题，空位越大。这三条线是按这批数据的分布划的，不是什么行业标准，你在自己市场上量出来的分布不一样，线也该跟着挪。 ## 这套数怎么在自己的市场上重做一遍？ ## 没有标记的时候怎么办 商业站不会给你标记。所以在真实市场上，你拿不到精确的译入率，只能估。 估的思路是找那些翻译流程覆盖不到的地方。翻译流程通常只处理正文和界面文案，覆盖不到的部分会留在原样。 我常看的有三处：地址栏、页面的语言声明、以及站内那些没人管的边角文案。这三处的共同点是它们不在译员拿到的稿子里。 估出来的是一个粗档，不是精确值。但做决策够用了，因为你要的本来就是量级——你要判断的是“这个市场的内容是不是搬来的”，不是“搬了百分之几点几”。 ## 从对手站上能看的三处 第一处是地址结构。本地语言的页面用的是英文单词拼的地址，还是本地词拼的地址？前者说明这批页面是从英文站复制出来再翻的。地址用本地字母还是拉丁转写 (https://zhangwenbao.com/minor-language-url-native-script-vs-latin-transliteration.html)那篇讲的是主动的选择，这里看的是被动留下的痕迹。 第二处是页面开头那行语言声明，跟正文实际用的语言对不对得上。多语言站点的官方规范 (https://developers.google.com/search/docs/specialty/international/localized-versions)对这一行有明确要求，而它对不上通常只有一个原因：模板是从别的语言版本复制过来的，没人记得改这一行。 第三处是站内搜索框的提示语、错误页的文案、表单的校验提示这类边角文字。这些几乎从来不在交给译员的那份稿子里，留着英文的概率相当高。 三处都中，基本可以判定这个站的本地版本是从主站翻出来的。三处都不中，那多半是本地团队自己做的。中一到两处的算存疑，先放着，等看完搜索结果页那两处再定。 ## 从搜索结果页能看的两处 不进对手的站也能看出一些。第一处是标题的句式：译文的标题往往保留源语言的语序和标点习惯，读着有点别扭但语法没错。 第二处是摘要里的专有名词。本地原生内容会用本地约定的写法，译文经常直接留原文或者用一个不常见的转写。品牌名在小语种里怎么被写出来 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)这篇讲的规律在这里正好反过来用：写法不对，说明不是本地人定的。 这两处都是软证据，单独看不作数，跟站内那三处配合起来用。 另外一个信号是地名用的是本地叫法还是外来叫法 (https://zhangwenbao.com/minor-language-place-name-endonym-exonym-search.html)。译文倾向于沿用源语言里那个外来叫法，本地写的内容用本地叫法。这一条在旅游、物流和本地生活类的站上特别灵，因为这类站上地名出现的密度高，样本量一下就够了。 ## 一个半天能跑完的最小版本 如果你想在自己的目标市场上跑一遍，最小版本是这样的。 先定20个核心词，每个词取搜索结果前10条，去重后大概能拿到100到150个页面。 逐个页面看那三处硬信号，各记一个是或否。三处都中记为“译”，一处都不中记为“原生”，中一到两处记为“存疑”。存疑那一档不要强行归类，直接单列，它的比例本身就是一条信息。 最后算“译”这一档占的比例。这个数跟本文的译入率口径完全不一样，不能拿去跟本文的表格比大小，但它回答的是同一个问题，而且是你自己市场上的真数。自己市场上的粗数，比别人市场上的精确数有用。 ## 多久重算一次 一年一次是底线。前面说过，译入行为集中在少数人手里，构成变得很快。 另外三种情况要随时补测：目标市场出现新的大玩家、你自己准备加大投入、或者你发现对手的内容突然多了一大批。 最后一种最值得警惕。内容突然变多，先别急着判断竞争加剧，先看看是不是有人开了一条翻译流水线。是的话，你的空位不但没缩小，反而被标得更清楚了——对方刚刚把源语言那份清单原样搬了过来，清单之外的部分依然空着，而且现在你知道那份清单长什么样。 ## 哪些地方我算错过，你别再踩？ ## 分子分母不同源 前面说过，第一版把两个接口的数凑成了一个分数，越南语因此被算成73.85%。这条排第一，因为它最隐蔽——两个数单看都是对的。 更麻烦的是错的幅度随语言变，1.27倍到2.38倍，所以你没法用一个系数修回来，只能推倒重来。 自查方法很笨但有效：把分子和分母各自的来源写在纸上，一行一个。如果两行不是同一个接口、同一次查询、同一套过滤条件，就重做。 ## 那年还没有那把尺子 系统里另有一个标记，专门用来标那些“机翻痕迹保留过多”的条目。我看到它的时候相当兴奋，因为它几乎就是我想要的那个质量指标。查完2019年，11门语言全是0条。 差一点就写成“那一年没人把机翻原样发出去”。幸好顺手多问了一句：这个标记最早的一条是什么时候？标记机制的文档 (https://www.mediawiki.org/wiki/Help:Tags)里写着这类标记由扩展在运行时添加，而它最早的一条落在2023年下半年。 那个0的意思是“那年还没有这把尺子”，不是“那年没人这么干”。这是零的第三种伪装，前两种是网络失败和解析失败，这一种最难发现，因为整条链路一切正常，接口返回200，字段齐全，就是数字是0。 自查方法只有一条，但很管用：任何一个量出全零的指标，先别急着解释它，先去查这把尺子是什么时候造出来的，再看它覆盖的时间跟你的窗口对不对得上。 ## 采集失败伪装成零 另外两种伪装也各踩了一次。一次是本地的域名解析把某个语言版本的地址指到了一个完全不相干的地方，证书对不上直接报错——如果外面套了容错，这门语言就会静静地变成“没有数据”。 另一次是编码。抓回来的页面没有声明字符集，工具库默认按西欧编码解，把西里尔字母解成了一串乱码——而乱码里每个字符都算“非拉丁字母”，于是统计出来的本地文字数量是假的，差了几十倍。 这两次的共同点是：失败之后程序照常跑完，没有报错，输出的数字看起来完全正常，甚至比正常还正常——因为它们都偏向“更干净”的方向。零和整数最容易骗过复核，因为它们看起来像结论而不像故障。 自查方法很土但有效：每轮采集之前先跑一遍连通性自检，把不通的名单打印出来；解析文本的时候，编码顺序必须是响应头、页面声明、通用编码，最后才轮到猜。 ## 小样本不能进主表 老挝语11条、瓦瑞语11条、阿姆哈拉语13条、高棉语14条、冰岛语17条、马耳他语18条、宿务语19条——这几门的译文条数都不到20。 比例照样能算，但一条的进出就能让百分比跳好几个点。这种数只能当个案讲，不能进主表，更不能拿去算相关系数。 我把它们从相关性计算里剔掉之后重算了一遍，结论没变，秩相关从负0.059变成负0.170，还是零附近。但如果不剔，读者有理由怀疑整个结论是被几条数据带出来的，而这个怀疑一旦成立，后面所有的话都不用听了。 自查方法：任何一个比例，先看分子的绝对数。分子小于20的，正文里必须写明。 ## 常见问题解答 ## 用维基百科的数据，能代表商业站吗？ 不能直接代表。维基没有商品页、没有促销页，编辑者的动机也跟商业运营完全不同，绝对值肯定对不上。 能借用的是语言之间的相对关系。当希腊语和爱沙尼亚语在同样规模下差46倍的时候，这个差异反映的是两个语言社群对待外来内容的不同习惯，而这个习惯会同时体现在商业内容上。 ## 为什么只取2019年一整年？ 因为页面创建日志是2018年年中才开始记录的，在此之前没有可用的逐条记录。所以能完整覆盖的整年只有2019一年。 这也意味着本文没法做同比。译入行为的年度波动可能很大，这是本文最大的局限，解读时请把它当成一个切片而不是趋势。 ## 译入率算出来是下限，那低估了多少？ 不知道，这正是问题所在。手工复制粘贴的翻译完全不留痕迹，我没有办法估计它的规模。 能确定的只有方向：真实值只会比算出来的高。所以本文所有关于“译入率低”的结论都留了余地，关于“译入率高”的结论则是安全的。 ## 越南语将近一半，这个数是不是太夸张了？ 我也这么怀疑过，所以抽了几条逐一核对：上级版本号为0说明确实是新建，标记确实带着翻译工具那一条，编辑摘要里也写着源页面的地址。都对得上。 换个角度想也说得通：339个人一年做26291条，人均78条，一周一条半。对一个有组织的翻译群体来说，这个工作量并不离谱。 ## 我的市场很小，这套方法值得花时间吗？ 市场越小越值得。大市场上你就算不做这个判断，靠预算也能砸出一条路；小市场上预算本来就少，判断错一次可能一年就过去了。 而且小市场的数据量小，跑一遍反而更快。前面那个最小版本半天能做完。 ## 中文市场用得上吗？ 用得上，方向反过来用。中文内容整体是原生的，但在垂直领域里，很多技术类和医疗类内容是从英文译过来的。 判读方式一样：找那三处翻译流程覆盖不到的地方。差别是中文市场的内容搬运更多发生在中文内部，也就是站与站之间的转载，这一层要用别的办法查。 ## 权威参考资料 ## 小语种SEO的访问量里有一半不是人，48门语言量下来最高的那门到92% - URL：https://zhangwenbao.com/minor-language-crawler-share-traffic-report.html - 分类：小语种SEO - 发布：2020-02-13 | 更新：2026-08-02 - 摘要：48门语言2019年实测爬虫占访问量的比例：西班牙语9.23%到宿务语92.07%，中位数29.36%，39门高于英语。含土耳其封锁期的天然对照实验、三条相关系数与四步自查流程。 - 关键词：技术SEO,日志分析,多语言SEO,小语种SEO > **TLDR**：摘要：拿48门语言的公开流量数据逐月拆开，把访问量分成真人和机器两堆，量出来的机器占比从西班牙语的9.23%一路铺到宿务语的92.07%，中位数29.36%，有39门高过英语的15.25%。最硬的一段证据来自土耳其：维基百科在当地被关掉的第一个整月，真人访问从1.574亿掉到3164万，少了将近八成，而同期的机器访问从3992万变成4049万，几乎没动。分母塌了、分子不动，比例就从20.23%跳到56.13%。反过来看马拉地语，真人四年涨了268%，机器反而少了45%，占比从61.4%落到18.5%。三条相关系数把这件事说透：读者规模决定真人访问（r=0.992），页面数量决定机器访问（r=0.920）。本文给出48门语言的完整对照表、一份可以自己跑的核算流程，以及报表上该加哪几列。 > 摘要：拿48门语言的公开流量数据逐月拆开，把访问量分成真人和机器两堆，量出来的机器占比从西班牙语的9.23%一路铺到宿务语的92.07%，中位数29.36%，有39门高过英语的15.25%。最硬的一段证据来自土耳其：维基百科在当地被关掉的第一个整月，真人访问从1.574亿掉到3164万，少了将近八成，而同期的机器访问从3992万变成4049万，几乎没动。分母塌了、分子不动，比例就从20.23%跳到56.13%。反过来看马拉地语，真人四年涨了268%，机器反而少了45%，占比从61.4%落到18.5%。三条相关系数把这件事说透：读者规模决定真人访问（r=0.992），页面数量决定机器访问（r=0.920）。本文给出48门语言的完整对照表、一份可以自己跑的核算流程，以及报表上该加哪几列。 接手一个中东欧市场的站，第一周先看数据。后台给的月访问量是四万出头，比同期的英文站好看不少——英文站上线更久、内容更多，月访问才十一万。 本地同事看完只说了一句：这四万里有多少是人？ 当时答不上来。后来把服务器日志拉出来按来源过了一遍，能对上已知爬虫特征的请求占到六成多。也就是说那四万里，真正有人打开的不到一万六。 这件事之后我一直想找个能横着比的口径——不是比某一个站，而是比某一门语言。找了很久，最后落在一个谁都能查、而且逐月拆得开的地方。 ## 小语种站的流量数字，为什么要先分成两半？ ## 报表上那个数是两拨完全不同的访客加出来的 一份访问量报表，不管出自日志、统计代码还是CDN，本质上都是把一段时间内的请求数加起来。加进去的既有真人，也有各家搜索引擎的抓取程序、监控探针、翻译代理和数据采集脚本。 在流量足够大的站上，这两拨的比例相对稳定，看总数不太会出事。问题出在流量小的站上——机器那一半有个下限，它跟你有多少人看没关系，只跟你有多少个页面有关系。 页面越多、读者越少，机器占的比重就越高。到了某个程度，报表上那个数字的主体就不再是人了，而你还在拿它做增长判断。 这不是小语种独有的毛病，但小语种最容易撞上，因为它天然处在“页面不算少、读者确实少”这个位置。一个站上线两年，页面攒到几千个，读者却还在三位数徘徊，这在小语种市场是常态而不是意外。 ## 把语种换成英语，这个问题就基本不存在 英文站的读者基数摆在那儿，机器那部分怎么涨也很难占到大头。你看到的访问量涨了，多半真的是有人多来了。 所以这件事归语言这一层管。同样一套技术栈、同样的页面数量，换一门读者规模差两个数量级的语言，报表的可信度就完全变了。 再往深一层，同一门语言在不同时期也会变。读者少了、页面没少，比例会立刻变形——后面那段土耳其的数据就是这么来的。所以这个数不是一门语言的固有属性，它是一个会随时间走的比值。 把语言这个变量单独拎出来看，是这篇要做的事。日志分析和爬虫核验的通用做法 (https://zhangwenbao.com/server-log-file-analysis-seo-crawl-budget-bot-verification.html)不在这里重讲，那是工具层，跟语言无关。 ## 为什么用维基百科的数据来量 要横着比几十门语言，得有一个各语言口径一致、公开、而且能按月拆的数据源。商业站没有，广告平台的数据不分真人机器，第三方流量估算工具本身就是猜的。 维基媒体基金会把各语言版本的访问数据做成了公开的流量接口 (https://wikimedia.org/api/rest_v1/)，逐月、逐语言、还按访客类型分成三档。这三档是全部、真人和爬虫，用的是同一套判定规则。 它当然不等于你的商业站。维基的页面构成、外链结构、更新节奏都跟电商站差得远。但要回答“同样是一门语言，机器和真人的比例会差多少”这个问题，它是目前唯一一个各语言可比的样本。做小语种研究常常要在“完美但拿不到”和“有偏差但能横着比”之间选后者，这次也一样。 本文把它当代理指标用，结论落在语言之间的相对差异上，不落在绝对数值上。这一点后面还会再说一次。 ## 这次量了哪些东西 取48门语言，覆盖三类：读者规模最大的那批大语种作基准、被程序批量建过页面的几门作对照、还有本站这个栏目一直在写的那批小语种。时间窗是2015年7月到2019年12月，逐月。 每门语言取四个数：全部访问量、真人访问量、爬虫访问量，以及唯一设备数。前三个是同一个接口的三档，最后一个来自另一个接口，量的是一个月内有多少台不同的设备来过。 再补一个页面侧的数：截至2019年12月，这门语言累计新建了多少个内容页。用累计新建而不是用今天的条目数，是因为今天的数字对不上2019年的口径，两边混着算会得出假结论——有几门语言的页面数在这之后翻了几十倍，拿今天的数去除2019年的访问量，误差能到两个数量级。 所有数据都能按任意时点截断，所以下面所有的数都只到2019年12月为止。 ## 这篇不谈的两件事 第一件是怎么识别爬虫。用户代理串怎么解析、假冒Googlebot怎么反查、哪些工具的探针要不要算进流量——这些是站点自己的工程活，跟这门语言是什么没关系。 第二件是页面级的分布。这篇给的是整门语言的汇总比例，回答不了“具体哪些页面在被爬虫反复抓、哪些页面一年到头没人打开”。那是另一层的问题，得用另一套抽样办法，而且要先解决一个前置的坑：怎么确定一个页面在观测期内真的存在过。 还有一件事得先说清楚：本文所有的比例都以全部访问量为分母。维基的三档里，全部访问恰好等于真人加爬虫，48门语言无一例外，没有第三类未分类流量需要额外解释。 下面从那张48行的表开始。 ## 48门语言量下来，机器那一半到底有多大？ ## 两头的差距比预想的大得多 2019年全年的数据摆出来，最低的是西班牙语，爬虫占9.23%；最高的是宿务语，92.07%。中间隔着整整十倍。 英语落在15.25%，48门语言里有39门比它高。中位数是29.36%，落在罗马尼亚语那一档。 换句话说，把这48门语言的访问量报表摊开，超过一半的语言，报表上每三次访问里就有一次不是人；最极端的那门，每十二次访问里只有一次是人。 如果你的判断依据是“访问量涨了20%”，那么在爬虫占七成的语言上，这个20%里有十四个点跟你的读者一点关系都没有。更麻烦的是这十四个点还会自己波动，抓取方换一次调度策略就够了。 ## 完整对照表 下表按爬虫占比降序排，只列有代表性的一部分。页面数是截至2019年12月的累计新建内容页，设备数是2019年月均。 语言 | 爬虫占比 | 月均设备 | 页面数 | 真人/页/年 | 爬虫/页/年 | 宿务语 | 92.07% | 215268 | 5331964 | 2.3 | 26.2 | 瓦瑞语 | 85.47% | 87002 | 1263887 | 9.4 | 55.2 | 约鲁巴语 | 75.26% | 37449 | 29421 | 107.8 | 328.1 | 土耳其语 | 66.62% | 2963672 | 329008 | 947.8 | 1891.2 | 乌兹别克语 | 65.75% | 672508 | 130910 | 356.2 | 683.9 | 老挝语 | 59.33% | 40478 | 3311 | 753.5 | 1099.4 | 僧伽罗语 | 49.40% | 224942 | 19126 | 671.8 | 655.8 | 缅甸语 | 37.08% | 252252 | 47715 | 435.7 | 256.7 | 瑞典语 | 35.82% | 12007364 | 2444970 | 459.0 | 256.2 | 高棉语 | 35.22% | 243980 | 9025 | 1185.5 | 644.5 | 泰米尔语 | 27.18% | 2574991 | 125815 | 920.5 | 343.5 | 孟加拉语 | 21.70% | 3341756 | 77299 | 2632.0 | 729.6 | 英语 | 15.25% | 857711498 | 5805691 | 15871.6 | 2857.0 | 印尼语 | 12.44% | 35245248 | 507111 | 3483.7 | 495.1 | 泰语 | 12.17% | 14519162 | 121025 | 6559.6 | 909.2 | 西班牙语 | 9.23% | 180324565 | 1547929 | 8112.2 | 825.2 | ## 宿务语和瓦瑞语为什么会跑到最上面 这两门是菲律宾的地方语言，它们的维基版本在2013年前后被一套程序批量建过页面。宿务语累计有533万个内容页，比德语还多；瓦瑞语126万。 与之对应的读者规模是：宿务语月均21.5万台设备，瓦瑞语8.7万台。拿页面数除以设备数，宿务语是24.77，瓦瑞语14.53。 这个比值意味着什么？平均每来一台设备，站上就有二十四个页面在等着被抓。抓取程序不会因为没人看就不来，它按页面数来。这就像一家开在无人区的仓库，客人一年来不了几个，可盘点的人每个月都得把货架从头走到尾。 结果就是那两个九十几和八十几的数字。这不是“小语种没人看”，是“页面被造得太多”，两件事不一样，后面会专门拆开。 ## 老挝语和僧伽罗语在这张表上的位置很有意思 老挝语的页面数只有3311个，全表最少，读者也最少（月均4万台设备）。它的爬虫占比是59.33%，排第九。 僧伽罗语页面19126个、设备22.5万台，爬虫占比49.40%。高棉语页面9025个、设备24.4万台，占比35.22%。 这三门是真正意义上的小语种——没被程序灌过，页面都是人建的，量也确实少。它们的爬虫占比在35%到60%之间，比英语高，但离宿务语那种九十几差得远。按母语人口给语言排优先级 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)那套老办法在这里也帮不上忙，因为决定这个数的是页面和读者的比，不是读者的绝对量。 所以爬虫占比这个数不能反过来当“这门语言有多小”来读。它读出来的是页面数和读者数的比，不是读者数本身。 ## 这张表里最反直觉的一行 土耳其语。爬虫占比66.62%，排第四，夹在乌兹别克语和格鲁吉亚语中间。 但土耳其语不是小语种。它月均有296万台设备来读，页面数32.9万，页面除设备只有0.11——这个比值跟希腊语、匈牙利语是一档的，而那两门的爬虫占比分别是20.04%和29.10%。 按前面那套解释，土耳其语应该落在20%到30%之间才对。它高出去了三十多个百分点。 第一反应是数据错了。查下来不是数据错，是这门语言在这段时间里发生了一件别的事——而这件事恰好把整篇文章想证明的那个机制，做成了一个可以直接验证的对照实验。 ## 有没有哪个地方能证明爬虫跟读者根本无关？ ## 把土耳其语拆成逐月来看 整年的汇总数看不出名堂，拆成54个月就一目了然。2015年7月到2017年4月，爬虫占比一直在17%到29%之间晃，跟一门正常的中型语言没有区别。 2017年4月是20.23%。2017年5月，56.13%。 一个月之内跳了三十六个百分点，之后再没回来过：2017年下半年在55%到67%之间，2018年全年在56%到70%，2019年前十一个月稳定在64%上下。 中间没有过渡，就是一个月的事。一门语言的流量结构在三十天里换了个样子，而这门语言的页面、内容、技术栈一样都没动过。 ## 那个月发生了什么 2017年4月29日，维基百科在土耳其境内被整体屏蔽。这次封锁的起止时间 (https://en.wikipedia.org/wiki/Block_of_Wikipedia_in_Turkey)有完整记录，一直持续到2019年12月26日当地宪法法院裁定违宪才解除。 屏蔽的是境内用户的访问。土耳其语维基本身一个页面没少，服务器照常在线，站外的抓取程序照常能连上。 换句话说，这是一次有人替我们做完的对照实验：控制变量是页面数量和站点可达性，被动的变量是读者。 而且它的干净程度超出预期——不是缓慢流失，是一夜之间断掉大半。做数据分析很少能碰上这么利落的断点，通常我们只能在一堆缓慢漂移里猜哪个是原因。 ## 分子和分母各自动了多少 把封锁前后的月均值算出来对比。封锁前的21个月（2015年7月到2017年3月），月均真人访问1.574亿次，月均爬虫访问3992万次。 封锁中的31个月（2017年5月到2019年11月），月均真人访问3164万次，月均爬虫访问4049万次。 真人掉了79.9%。爬虫涨了1.4%。 比例从20.23%变成56.13%这件事，全部由分母贡献，分子几乎纹丝不动。抓取程序完全不知道、也完全不在乎这个国家的人还能不能打开这个站。 ## 怎么排除这是口径变了 2017年前后维基媒体如果调过机器流量的判定规则，所有语言都会同时出现跳变，那这个发现就作废了。 拿英语做对照：2016年14.1%、2017年15.9%、2018年14.7%、2019年15.3%。四年之内在一个百分点半的区间里走，没有任何跳变。 再拿同期的德语、法语、西班牙语看，也都是平的。机器流量的判定规则 (https://wikitech.wikimedia.org/wiki/Analytics/Data_Lake/Traffic/BotDetection)本身是公开的，2015年定下来之后没有过影响可比性的大改。 所以那三十六个百分点只发生在土耳其语上，而且只发生在那一个月。这条排除做完，剩下的解释就只有一个了。 ## 解封那个月的数也对得上 2019年12月26日解封。那个月的真人访问是2765万，跟封锁期的月均3164万差不多，没有回升。 这正是应该看到的——12月只有最后五天解封，用户回流需要时间，一个月的尾巴不足以体现。这条不算证据，但它没有反过来打脸，说明数据是自洽的。 真正的回升要看2020年的数，而本文的数据截到2019年12月，所以这一段就到这里。 把结论收窄一点：这个案例证明的是“读者塌了、爬虫不塌”，它没有证明反过来的方向。反方向要另找一个案例。 ## 这件事对做站的人意味着什么 你的小语种站被墙、被限、被某个地区的运营商屏蔽，或者只是本地推广停了一个季度，报表上的总访问量都不会掉到你以为的那个程度。 因为撑着那个数字的另一半根本没走。它会让你晚三个月才发现出了事。 反过来，你上了一批新页面、访问量看着涨了，也可能只是抓取程序发现了新页面在跑一轮。收录、排名、流量这三层要分开诊断 (https://zhangwenbao.com/indexed-ranked-traffic-three-layer-seo-diagnosis.html)的老规矩在这里格外要紧。 唯一的办法是把这两拨分开看，而且从第一天就分开。等到出问题再去补拆，历史数据是拆不回来的——日志过期删掉之后，那几个月到底发生了什么就永远说不清了。 ## 反过来看，读者暴涨的时候爬虫会跟着涨吗？ ## 找一门读者在四年里翻了几倍的语言 土耳其语给的是分母塌掉的一半。要把机制说完整，还需要一个分母暴涨的案例。 这批数据里现成就有：2016年到2019年，印度那几门语言的读者数集体起飞，背景是当地移动数据资费在2016年底的那次崩塌式下降。 马拉地语是里面最典型的。2016年全年真人访问2893万次，2019年1.064亿次，涨了268%。 同期它的爬虫访问从4471万次变成2457万次，少了45%。 ## 占比是怎么走的 马拉地语的爬虫占比：2016年60.7%、2017年44.0%、2018年22.6%、2019年18.8%。四年掉了42个百分点。 逐月看，2017年下半年到2018年上半年是主要的下坡段，跟真人访问的爬升期完全重合。 这跟土耳其语是同一个机制的镜像。那边是分子不动分母掉，这边是分母涨得比分子快。两边算出来的都是同一个比值在变。一升一降都指向同一个解释，这比只有一个方向的证据硬得多。 一升一降两个案例摆在一起，才能说这个比例是被读者规模推着走的，而不是被抓取行为推着走的。 ## 不是所有印度语言都一样 同期的印地语真人涨286%，但爬虫也涨了122%，所以占比只从18.9%落到11.8%。泰米尔语真人涨170%、爬虫涨40%，占比从41.8%落到27.2%。 爬虫那一列为什么各不相同？因为这四年里这几门语言的页面数增长速度也不一样，而爬虫是跟着页面数走的。 马拉地语的爬虫访问之所以绝对值下降，跟它2013年前后那段批量建页的历史有关——早期那批页面被抓过一轮之后，抓取频率会自然衰减。 这一层的细节超出本文范围，但它提醒一件事：爬虫那一列自己也在动，只是它动的原因跟你的读者无关。它跟着页面数、页面的更新频率、以及存量内容的衰减节奏 (https://zhangwenbao.com/content-decay-mechanism-portfolio-roi-tiering.html)走。 ## 四年趋势整体上不是单向的 开工前我写下的预期是“2016到2019年爬虫占比整体上升，因为抓取程序越来越多”。实测下来48门语言里27门升、21门降，这条预期是错的。 降得最多的五门是马拉地语（−42.0个百分点）、乌兹别克语（−18.2）、泰米尔语（−14.6）、高棉语（−13.3）、孟加拉语（−11.7），基本都是读者规模在这四年里快速扩张的市场。 升得最多的除了土耳其语，是格鲁吉亚语（+15.7）、尼泊尔语（+9.3）、俄语（+8.1）。 把升的和降的放在一起看，它们服从同一条规律：占比往哪边走，取决于读者数和页面数谁跑得快。这比“爬虫越来越多”那个说法要具体得多，也更好用——前者能算，后者只能感叹。 ## 那这个比例到底由什么决定？ ## 把两条线分开算 前面靠两个案例说了机制，现在用48门语言的横截面把它量出来。做法很简单，算三组相关系数，全部取以10为底的对数之后再算。 第一组：月均设备数对真人访问量，r等于0.992。 第二组：页面数对爬虫访问量，r等于0.920。 第三组：把页面数除以设备数得到一个比值，拿它对爬虫占比，r等于0.874。 ## 0.992这个数意味着什么 真人访问量几乎完全由读者规模决定，48门语言无一例外。这听起来像废话，但它是整套推理的地基——它说明真人那一列是干净的，没有被别的东西污染。 要是这个数只有0.6，那说明真人那一列里还混着别的东西，后面所有的比值都不能信。先验地基再往上盖，是这类跨来源对比里省不掉的一步。 唯一设备数 (https://wikitech.wikimedia.org/wiki/Analytics/AQS/Unique_Devices)这个口径本身也值得说一句：它数的是一个月内有多少台不同的设备来过，用的是浏览器端的标记，跟访问次数是两个东西。拿它当读者规模的代理，比拿访问量自己当代理要干净。 两个独立来源的数据能对到0.992，说明这两个接口的口径是一致的。 ## 0.920那一组说的是抓取预算 爬虫访问量跟页面数的关系，本质上就是抓取预算 (https://developers.google.com/search/blog/2017/01/what-crawl-budget-means-for-googlebot)这件事在跨语言尺度上的样子。你有多少个地址，抓取程序就得来多少趟，这是它的工作方式决定的。 0.920不是1，差的那部分很关键——它说明抓取量不是页面数的严格倍数，中间还有别的因素在调节。那个因素是什么，下一节专门拆。 先记住这一半的结论：页面数是抓取量的第一驱动，读者数不是。 顺带说一句，这跟站长圈里流传的“内容多了搜索引擎就来得勤”是同一件事，只是这里给出了跨48门语言的量化版本。要注意的是“来得勤”说的是总趟数，不是每个页面被照顾到的次数，这两件事下一节会分开。 ## 两条线一除，就是那个比例 既然真人跟着设备走、爬虫跟着页面走，那么爬虫占比自然就该跟着“页面数除以设备数”走。实测r等于0.874，双对数下0.816。 这个比值可以直接当一个可读的指标用。宿务语24.77，瓦瑞语14.53，约鲁巴语0.786，瑞典语0.204，老挝语0.082，英语0.007。 换成人话：宿务语平均每来一台设备，站上有二十五个页面等着被抓；英语是每来一千四百台设备才摊到一个页面。 差了三千五百倍。爬虫占比从92%到15%这个跨度，就是这三千五百倍算出来的。站点地图里到底放了多少个地址 (https://zhangwenbao.com/xml-sitemap-complete-guide.html)，在小语种站上因此变成一个远比英文站敏感的决定。 ## 但这个模型不该被当成公式用 0.874是个不错的相关系数，可它离1还有距离，而且土耳其语这种被外力干预过的情况会整个跳出模型。 更要紧的是，这套数是在维基上量的。商业站的页面构成、外链密度、更新频率跟维基差别很大，抓取程序的行为也会跟着不同。 所以这个比值该怎么用？拿它做横向排序，判断哪几门语言的报表最不可信，这是稳的。拿它去反推“我的站爬虫应该占多少”，不稳。 要知道自己站上的真实比例，只能自己量，量法在后面那节。好消息是量一遍的成本很低，一份日志加半天时间。 ## 爬虫是照着页数均匀抓的吗？ ## 开工前我以为它是 预期写下来的时候是这么想的：抓取程序会定期重访每一个已知地址，所以“每个页面每年被抓多少次”这个数在各语言之间应该差不多，变异系数大概在0.5以下。 实测的结果是变异系数0.69，最小值和最大值差109倍。这条预期错了，而且错得很有内容。 最低的是宿务语，每个页面每年被抓26.2次；最高的是英语，2857次。 页面最多的那门语言，反而是每个页面被抓得最少的那门。 ## 完整的分档 英语2857次、日语1749.8次、土耳其语1891.2次落在最上面一档；中间是绝大多数语言，在300到900之间；最下面是宿务语26.2、瓦瑞语55.2、豪萨语25.3。 注意这里的排序跟爬虫占比那张表几乎是反的。宿务语的爬虫占比全场最高，可它每个页面分到的抓取次数全场最低。 这两件事同时成立，因为它的页面实在太多——533万个页面，每个只抓26次，加起来还是1.4亿次，而真人只贡献了1201万次。 这个反转把“爬虫按页数来”这句话修正得更准确：爬虫的总量按页数来，但它分给每个页面的份额，会随着页面变多而变薄。前半句决定你的报表长什么样，后半句决定你的新内容多久被发现。 ## 抓取程序也在挑 为什么会变薄？因为抓取本身是有成本的，任何一个抓取方都会给每个站分配一个上限。页面数超过这个上限之后，多出来的页面只能排队等更长的周期。 这正是抓取预算这个概念的本意，只是通常我们在单个站上讨论它，很少有机会看到它在跨语言尺度上的样子。 宿务语那533万个页面里，绝大多数是同一套模板批量生成的地名和物种条目。抓取方显然识别出了这类页面的更新频率极低，把重访周期拉得很长。 所以那个26.2次，不是抓取方不认识这些页面，是它认识了之后决定少来。这个判断是抓取方替你做的，你没有投票权，能改的只有页面本身。 ## 这条对做站的直接含义 你的站上每多一批低价值页面，抓取程序不会给你追加预算，它会把原有的预算摊得更薄。结果是重要页面的重访周期变长，新内容被发现得更慢。 这个道理在英文站上讲了很多年，索引膨胀的诊断和处理 (https://zhangwenbao.com/index-bloat-mechanism-sitewide-diagnosis-decision-matrix.html)是一整套成熟方法。小语种站的特殊之处在于，你的预算本来就更小，摊薄的后果来得更快。 还有一个只在小语种上成立的副作用：页面变多之后，报表上爬虫那一半会跟着变大，于是访问量看起来在涨。这个涨幅会把摊薄的坏消息盖住。 两件坏事凑在一起，看起来像一件好事。这大概是这份数据里最值得记住的一句。抓取程序这些年在渲染和调度上的变化 (https://zhangwenbao.com/mobile-first-indexing-mechanism-googlebot-rendering-evolution-survival.html)只会让这个错觉更难识破，因为它让抓取行为看起来更像真人。 ## 一个不该忽略的边界 上面这段推理用的是维基的数据，而维基的页面几乎都能被抓到、也几乎都在站点地图里。你的站如果有大量页面从来没被发现过，那些页面不在这个模型里。 另外维基的抓取方构成跟商业站不一样。它被学术采集、数据镜像、模型训练管线抓的比例更高，这些抓取方的行为跟搜索引擎不完全一致。 所以“每个页面每年被抓多少次”这个绝对数不要照搬。可以搬的是那个方向：页面变多，单页份额变少。 这一点在自己站上很容易验证，日志里按URL分组数一遍就知道。如果中位数比你以为的低一个数量级，那就是摊薄已经发生了。 ## 换到你自己的站上，这几个数怎么量？ ## 先量一个数：机器占比 取一个月的访问日志，按来源把请求分成两堆，算出机器那一堆占总请求数的比例。这是全部工作里最基础的一步，也是很多站从来没做过的一步。 分堆的判据按可靠度排：反向域名查询能验明正身的搜索引擎爬虫最硬，用户代理串里带明确标识的次之，行为特征（不加载静态资源、不执行脚本、请求节奏均匀）最后。 三档分开统计，别混成一个数。因为后面要看的是趋势，而三档的口径必须逐月一致。 这一步不需要任何工具，一段脚本加一个月的日志就够了。真正难的不是算，是把口径定下来之后别再改——口径一改，前面几个月的数就白存了。 ## 再量一个数：页面数除以读者数 页面数取站点地图里的有效地址数，不是数据库里的记录数——没进站点地图的页面对抓取方来说基本不存在。 读者数取统计工具里的月度独立访客，不是访问次数。这两个数的比值就是前面那个指标在你站上的版本。 算出来之后跟这张表对一下位置。落在0.01那一档的，报表基本可信；落在0.2以上的，每次看数据都得先减掉机器那一半；落在1以上的，你站上的页面数已经超过读者规模能支撑的量了。 这个数每季度重算一次，看它往哪个方向走，比看绝对值有用。它往上走，说明你在造页面的速度超过了拉读者的速度，这件事在做批量落地页的团队里非常常见。 ## 第三个数：单页抓取频次 把一个月的爬虫请求按URL分组，算出每个页面被抓了几次，然后看这个分布的中位数和四分位。 要看的不是平均值。平均值会被首页和几个热门页拉高，掩盖掉长尾那一大堆几个月才被抓一次的页面。 中位数落在个位数，说明预算已经摊得很薄。这时候再上新页面，只会让中位数继续往下走。 同时把没有任何爬虫记录的页面单独拉一张清单，这批页面对搜索引擎而言等于不存在。小语种站上这张清单往往比想象中长，而且长期没人查。 ## 第四个数：真人访问的绝对量 前三个数都是比例和分布，最后要落回一个绝对数：这个月有多少个真人打开过你的小语种站。 把它单独立一列，跟总访问量并排放。做增长汇报的时候只看这一列，别看总数。 这一列可能会很难看。中东欧那个站拆完之后，真人月访问从四万变成一万六，看板上的曲线直接矮了一截。 但矮下去的那一截本来就不是你的读者，早看到早调整。那次拆完之后我们把预算从新增页面挪到了本地渠道投放，三个月后真人那一列涨了六成，总访问量反而只涨了一成——因为爬虫那一半没跟着动。 ## 做完之后先别急着下结论 这四个数只是把现状拍下来，它们不告诉你该做什么。同样是机器占比60%，两种情况的处理完全相反。 一种是页面数正常、读者确实少，那问题在需求侧，该做的是重新看这个市场的搜索意图分布 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)，而不是砍页面。 另一种是读者规模其实不小、页面被造得太多，那问题在供给侧，该做的是清理和合并。 分辨这两种情况，靠的就是第二个数：页面数除以读者数。这也是为什么它比机器占比本身更该被放进报表。关键词工具在小语种上返回的零 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)也要放在一起读，工具没数据不等于需求不存在。 ## 一个可以半天跑完的清单 第一步，拉最近三个月的日志，按上面三档判据分堆，得到逐月的机器占比。 第二步，数站点地图里的有效地址，除以统计工具里的月度独立访客。 第三步，爬虫请求按URL分组，出中位数、四分位，以及零抓取页面清单。 第四步，把真人访问量单独立一列加进现有看板，往前补三个月的历史。四步做完，半天。 ## 报表和日志该怎么改才不骗人？ ## 看板上要加的那一列 现有的访问量那一列不要删，在它旁边加一列真人访问量，再加一列机器占比。三列并排，趋势一眼就能看出来。 加这一列的阻力通常不在技术上，在于它会让历史数据变难看。得先跟看这份报表的人讲清楚，数字变小不是业务掉了，是尺子换准了。 这件事越早做越好。做得越晚，历史曲线的落差越大，越难解释。 如果实在不能改主看板，至少在月度复盘里单独出一张。一张多出来的图，比一次口头解释管用得多。 ## 按语言分开看，别汇总 多语言站最容易犯的错是把所有语言版本的流量加成一个总数。加完之后，英语站那一大坨会把小语种版本的异常完全淹掉。 正确的做法是每个语言版本一行，各自带自己的机器占比。这样某一门语言出问题的时候，你能在第一个月看见。 这跟多语言站的目录与标注结构 (https://zhangwenbao.com/international-seo-hreflang-complete-guide.html)是配套的：结构上分得清，数据上才拆得开。 结构没分清的站，这一步做不了，得先把结构补上。这也是为什么目录结构和数据结构该在同一天定下来。 ## 报警阈值该设在哪儿 机器占比本身不适合当报警指标，因为它在小语种上天然就高。适合报警的是它的变化速度。 一个月之内动超过十个百分点，不管往哪边动，都值得查一遍。土耳其语那次是三十六个点，属于极端情况；正常波动一般在三个点以内。 另一个值得报警的是真人访问量的绝对值。它掉三成的时候，总访问量可能只掉一成，后者不会触发任何告警。 把告警挂在真人那一列上，不要挂在总数上。总数是两拨人加出来的，它的平稳可能只是两边正好互相抵消。 ## 日志保留期限得跟着调 要看趋势就得有历史。很多站的日志只留三十天，那么等你发现要拆分的时候，能拆的只有当月。 建议至少留十三个月，能覆盖一个完整的同比周期。存储成本比想象的低，压缩之后一个中等规模的站一年也就几十G。 如果实在留不了原始日志，至少把逐日的分堆汇总数存下来，字段就四个：日期、总请求、机器请求、真人请求。 这四个字段一天一行，十年也才三千多行。存在一张表里，将来要复盘任何一次波动都够用。 ## 别把机器流量当敌人 拆分不等于要拦截。搜索引擎的抓取程序来得勤是好事，说明你的页面被当回事了。这篇讲的是别把它算进读者，不是让你去封它。 真正该拦的是另一类：那些既不带来收录、也不遵守爬虫排除协议 (https://zhangwenbao.com/robots-exclusion-protocol-mechanism-complete-guide.html)、还把服务器打满的采集脚本。拦它们的判据是服务器成本，不是流量报表。 把这两件事混在一起，很容易做出“为了让报表好看去封爬虫”这种自伤操作。 报表的问题用报表的办法解决，服务器的问题用服务器的办法解决。把它们混成一件事，是这个话题上最常见的自伤操作。 ## 哪几件事这一层管不了？ ## 页面级的分布不归这一层 本文所有的数都是整门语言的汇总。它能告诉你“这门语言有三成访问不是人”，告诉不了你“具体是哪三千个页面在被反复抓、又是哪三万个页面一年没人打开”。 那件事得用另一套办法量——随机抽样加逐页查，而且得先解决“这个页面在观测期内到底存不存在”这个前置问题。 汇总数和分布是两层，混着看会得出很奇怪的结论。比如一门语言的平均每页真人访问是459次，听起来还行，可它的中位数完全可能是个位数。 这一层留给后面单独写。可以先记住一个提示：汇总数看起来还行的语言，分布可能已经很难看了。 ## 抓取程序的识别方法不归这一层 怎么反查一个自称Googlebot的请求是不是真的、怎么处理伪装成浏览器的采集脚本、哪些SEO工具的探针要不要算进来——这些都是站点自己的工程活。 它们跟这门语言是什么完全无关，英文站和老挝语站的做法一模一样。 本文默认你已经能把请求分成两堆，只讨论分完之后怎么读。 分堆本身的方法在日志分析那一层，已经有很成熟的做法，照着做就行，不用为小语种另起一套。 ## 搜索引擎侧的收录判断不归这一层 爬虫来过不等于收录，收录不等于有排名。这三件事在小语种上尤其容易脱节，因为中间还夹着语言识别、编码解析这些额外的环节。 被抓了几次这个数，只能回答链路的第一段。后面两段得看搜索控制台那边的数据，跟日志是两个来源。 抓取、索引、排名这三段的分工 (https://zhangwenbao.com/how-search-engines-work-crawl-index-rank.html)是老话题了，本文不重复。 要提醒的只有一句：小语种站上这三段的衰减比英文站陡，每一段都得单独量。多语言模型铺开之后 (https://zhangwenbao.com/multilingual-bert-seventy-languages-minor-language-seo-watershed.html)，语言识别这一环的失败率降了不少，但它并没有改变抓取和收录之间的脱节。 ## 这份数据本身的边界 最后把话说回来。这48门语言的数据全部来自维基百科，它跟你的商业站有三个明显的差异：页面构成不同、外链结构不同、抓取方构成不同。 所以本文的绝对数值不要照搬，可以搬的是三样东西：那个机制（爬虫按页数、真人按人数）、那个可比指标（页面数除以读者数）、以及那套自查流程。 还有一件事值得单独说：页面浏览的正式定义 (https://meta.wikimedia.org/wiki/Research:Page_view)里明确排除了一些请求类型，跟你的统计工具的口径不完全一致。跨来源比数字的时候要留神。 把这些边界摆清楚之后，剩下的那部分是稳的：一门语言的报表可信度，可以在动手之前就估出来。只要你知道这门语言大概有多少读者、你打算建多少个页面。 ## 常见问题解答 ## 机器占比多少算正常？ 没有一个通用的正常值，它取决于你的页面数和读者规模的比。本文这48门语言从9.23%铺到92.07%，中位数29.36%，跨度太大，拿中位数当标准没有意义。 可以用的判据是自己跟自己比：算出页面数除以月度独立访客这个比值，落在0.01量级的站，机器占比通常在10%到20%；落在0.2以上的，三成起步。 更该关注的是变化速度。一个月之内动超过十个百分点，说明有事发生了。 ## 为什么不直接用统计代码的数据，非要看日志？ 统计代码要靠浏览器执行脚本才会上报，绝大多数抓取程序不执行脚本，所以它统计到的本来就基本是真人。这听起来是好事，其实是坏事——你根本看不到机器那一半有多大。 日志记的是每一个到达服务器的请求，两拨都在里面。要拆分就必须用日志。 正确的用法是两边都用：统计代码看真人的行为，日志看两拨的比例。页面迟迟不被收录的排查 (https://zhangwenbao.com/baidu-index-crawl-mechanism-why-not-indexed.html)也得靠日志起手，统计代码在那个场景里同样是瞎的。 ## 爬虫占比高，是不是说明这门语言不值得做？ 不能这么读。爬虫占比高只说明页面数和读者数的比值高，它可能是读者少，也可能是页面被造多了，两种情况的对策完全相反。 老挝语的爬虫占比59.33%，可它的页面只有3311个，读者少是事实但页面一点不多。宿务语92.07%，页面533万个，问题完全在另一头。 先分辨是哪一种，再决定做不做。 ## 土耳其那个案例，会不会只是巧合？ 时间点对得太准，很难用巧合解释：跳变发生在封锁开始的当月，而且是从20.23%到56.13%这种量级，之后31个月没回来过。 更关键的是分子和分母的表现是分开的——真人掉79.9%、爬虫涨1.4%。如果是统计口径变了，两边应该一起变。 再加上同期英语、德语、法语、西班牙语全部平稳，这个跳变只发生在一门语言上。三条合起来，巧合的概率很低。 ## 页面数除以读者数这个指标，多大算危险？ 按本文这48门语言的分布，可以粗略分三档：0.05以下的报表基本可信，0.05到0.5之间需要每次减掉机器那一半再看，0.5以上说明页面规模已经超过读者能支撑的量。 超过1的只有宿务语和瓦瑞语两门，它们的页面都是程序批量建的。正常经营的站很难走到那一步。 但如果你在做自动生成的城市页、组合页、筛选页，这个数会涨得比想象快。 ## 已经在用现成的分析工具，还需要自己拆日志吗？ 取决于工具给不给你按来源分组的原始数据。大多数商业分析工具给的是清洗过的结果，清洗规则不公开，而且各家不一致。 要横向比较不同月份、不同语言版本，口径必须自己控制。这是自己拆的主要理由，不是因为工具不准。 如果只看一门语言的单月数字，用工具就够了。 ## 这套方法在中文市场用得上吗？ 用得上，而且中文市场有它自己的版本。中文站的抓取方构成跟英文站不一样，除了几家搜索引擎，还有数量可观的内容采集脚本。 页面数除以读者数这个比值照样能算，判读方式也一样。差别在于绝对数会更高一些，因为采集脚本的基数大。 那套四步自查流程可以原样搬过来，不用改。唯一要调的是分堆的判据表，得把本地那几家搜索引擎和常见采集脚本的特征补进去。 ## 权威参考资料 ## 多语言模型铺到七十多种语言那天，受益最多的不是字母最像英语的那几门 - URL：https://zhangwenbao.com/multilingual-bert-seventy-languages-minor-language-seo-watershed.html - 分类：小语种SEO - 发布：2019-12-19 | 更新：2026-07-25 - 摘要：多语言模型的跨语言迁移效果跟语序类型相关，跟字母是否像英语关系不大。讲清哪些语种真受益、语料量怎么决定上限、小语种SEO的六个动作该怎么改，以及哪些事一个字都没变。 - 关键词：语义SEO,多语言SEO,小语种SEO > **TLDR**：摘要：覆盖七十多种语言这个消息一出来，多数人的第一反应是拉丁字母的语种会先受益，因为它们跟英语长得最像。实测结论正好相反：跨语言迁移的效果跟两门语言的词序类型相关性最强，跟字母表重叠度关系不大。语序接近英语的越南语受益明显，谚文和拉丁字母之间的差距反而不是关键变量。 > 摘要：覆盖七十多种语言这个消息一出来，多数人的第一反应是拉丁字母的语种会先受益，因为它们跟英语长得最像。实测结论正好相反：跨语言迁移的效果跟两门语言的词序类型相关性最强，跟字母表重叠度关系不大。语序接近英语的越南语受益明显，谚文和拉丁字母之间的差距反而不是关键变量。 ## 十月和十二月是两件事，哪一次才是小语种的分水岭？ ## 十月那次上线，非英语只吃到了精选摘要 十月底的那次公告说的是英语查询的常规排名。 非英语市场当时拿到的不是同一件东西。 它们只在精选摘要这一块用上了新的语言理解能力。 覆盖的语言数量也有限，是二十多种，不是七十多种。 精选摘要的影响面很窄，只涉及少数查询的少数位置。 所以那次上线对小语种的实际影响，接近于没有。 这个细节在当时被大量报道混在一起说了，很多人记住的是十月上线覆盖多语言。这个语言理解模型本身是怎么工作的 (https://zhangwenbao.com/google-bert-algorithm-nlp-explained.html)那篇讲的是机制，不涉及分市场的铺开节奏，节奏这件事得单独看清楚。 把十月和十二月分开记，是理解这件事对小语种意味着什么的第一步。 精选摘要这个位置本身还有个特点：它只出现在特定类型的查询上，多数是问句型和定义型。小语种市场的这类查询本来就少有人做内容，所以就算那二十多种语言里有你的目标市场，可参与的查询集合也非常有限，实际能感知到的变化基本为零。 ## 十二月这次才铺到七十多种语言的常规排名 十二月上旬的那次才是覆盖面上的跳变。 从二十多种精选摘要，变成七十多种语言的常规排名。 常规排名意味着影响的是每一次查询，不是特定位置。 这个变化对小语种站点的影响量级完全不同。 它意味着这些语言的页面第一次被同一套理解能力处理。 在此之前，非英语市场用的一直是能力较弱的那一套。 数量从二十多跳到七十多，中间多出来的那五十种正是真正的小语种。二十多种里装的还是主要语言，五十种这个增量里才有匈牙利语、越南语、乌克兰语、希伯来语这些真正需要它的语种，所以增量比总量更值得看。 如果要给小语种SEO找一个分水岭日期，是十二月这一次，不是十月那一次。 常规排名和特定位置的区别在量级上大概是这样：特定位置影响的是一小部分查询的一小块展示区域，常规排名影响的是每一次查询的整个候选集排序。前者是加分项，后者是评分方式本身变了，两者的影响面差着不止一个数量级。 ## 记错这个时间点会导致什么误判 误判之一是把十月到十二月之间的排名波动归因错了。 那两个月小语种市场的波动跟这件事无关，另有原因。 误判之二是把受益幅度按英语市场的数据估。 英语市场当时报出的影响面是一成左右的查询。 小语种的实际幅度跟这个数字没有可比性，通常更小。 误判之三是以为覆盖了就等于能力一样，这条最要紧。 覆盖和能力是两件事。七十多种语言都被覆盖了，但每种语言上的理解能力差别很大，这个差别由训练语料的规模决定，后面会专门讲怎么估。搜索从关键词匹配走到意图理解的整条演变线 (https://zhangwenbao.com/semantic-search-understanding-evolution-hummingbird-bert-mum.html)那篇是纵向的时间视角，本篇要补的是横向的语种视角。 先把时间点和覆盖范围这两件事对清楚，再谈自家语种该怎么办。 还有一类误判出现在竞品分析上。看到某个竞品在这段时间排名上来了，就假定它是踩对了新机制的节奏，于是照抄它的写法。实际那两个月里能影响小语种排名的因素有一大堆，把结果归到一个刚上线的能力上，多半是把相关当成了因果。 ## 在这之前小语种页面是怎么被理解的？ ## 关键词匹配加一份有限的同义词表 更早的机制核心是词面匹配加同义词扩展。 查询里的词跟页面上的词对得上，页面就有机会被选中。 同义词表负责处理说法不同但意思相同的情况。 近义词理解的能力在此之前已经有过一轮明显提升。 那套被称为超级同义词的匹配机制 (https://zhangwenbao.com/neural-matching-google-super-synonyms-explained.html)就是这一层的代表。 但它处理的仍然是词与词的对应，不是整句的意思。 词面匹配这套机制对小语种SEO的塑造非常深。铺词形变体、覆盖拼写变体、把所有可能的写法都写进页面，这些做法之所以有效，正是因为引擎在按词面找匹配，你多写一种写法就多接住一批查询。这套方法论存在了十几年，不会因为一次更新就作废。 理解旧机制是判断新机制影响面的前提，因为变化的幅度取决于旧的那套在你的语种上原来做得有多差。 词面匹配这套机制还有一个副产品，就是小语种市场的内容形态被它塑造得很单一。大家都在写关键词密度合适、变体覆盖齐全的页面，读起来都差不多。这个格局在理解能力提升之后会松动，写得更像人话的内容第一次有了结构性的机会。 ## 同义词表是逐语言建的，低资源语言天然被漏 同义词表和词形归并规则需要逐语言建设。 建设需要语料、需要标注、也需要语言学的投入。 投入按市场规模分配，小语种排在后面。 所以低资源语言上的词表覆盖率一直明显偏低。 这就是为什么同一个查询在英语上能被理解，在匈牙利语上不行。 差距的根源不是算法，是逐语言建设的资源分配。 这个结构性差距还有一个可观察的表现：小语种市场的搜索结果里，词面完全匹配的页面排得特别靠前，明显比英语市场更依赖字面。这不是当地竞争者更会做SEO，是引擎在那门语言上只有字面信号可用。 把这一层看清之后，新机制的意义就清楚了：它绕开了逐语言建设这个瓶颈。 这个分配逻辑还能解释一个现象：同一门语言在不同时期的待遇差别很大。某个市场的商业价值上来之后，投入跟着上来，词表覆盖率就明显改善。所以小语种的这类能力不是一直恒定的，它跟市场规模的变化是有滞后的正相关。 ## 一套模型在多种语言上共训改变了什么 新机制的做法是一套参数在上百种语言上一起训练。 不再是每门语言各建一套规则和词表。 高资源语言学到的模式，会通过共享的参数影响低资源语言。 这就是跨语言迁移，也是这件事对小语种最关键的机制。 迁移意味着没人专门给它建词表的语言也能拿到一部分能力。 拿到多少，取决于它跟那些高资源语言有多相似。 这个机制上的转变值得跟更早那一波深度学习的应用区分开。深度学习这十年对搜索的改写 (https://zhangwenbao.com/deep-learning-seo-decade-impact.html)那篇讲的是这类方法整体进入搜索的过程，而这里的重点是共训带来的迁移效应，这一点在单语言模型上是不存在的。 迁移这个词是本篇的核心，后面所有的判断都建立在它的强弱上。 共训还有一个容易被忽略的前提：它要求各语言的语料在同一个训练过程里同时存在。这意味着某门语言的可用语料如果实在太少，它在共享参数里几乎没有分量，能拿到的只是从别的语言迁移过来的通用结构，几乎没有属于自己的东西。这是最低资源那一批语言的真实处境。 ## 跨语言迁移到底靠什么发生？ ## 共享子词词表是第一座桥 模型不是按词处理文本的，是按子词片段。 一个词会被切成几个更小的片段，片段来自一份共享词表。 这份词表由所有语言的语料一起统计出来。 所以不同语言的词可能共用同样的片段。 共用片段的地方，就是模型能把知识搬过去的地方。 这是迁移能发生的技术前提，但不是决定强弱的主要变量。 子词切分这件事对屈折语还有一个附带的影响：一个词的词干和词尾可能被切成不同片段，模型因此有机会自己学到同一个词干的多种形态是相关的。这解释了为什么词形归并的部分工作可以被模型接过去，但也只是部分。 把子词词表理解成一座桥就够了，桥存在不等于车流大，流量由后面几条决定。 ## 同一套参数在多种语言上同时学 训练时所有语言的文本混在一起进入同一套参数。 模型没有语言标签，它不知道这句话是哪门语言。 它学到的是语言的通用结构规律。 规律在语言之间共享，所以能跨语言用。 这跟给每门语言各训一个模型是完全不同的路径。 共享带来迁移，但也带来能力的不均匀，这是同一枚硬币的两面。 不均匀这一面的具体表现是：语料多的语言在参数里占的份额大，它的模式主导了共享的那部分表示。低资源语言拿到的是一份按高资源语言的规律塑造过的能力，合不合身取决于两者有多像。 这一点是理解受益差异的关键，也直接引出下面那个反直觉的结论。 不知道语言标签这件事还有个实际推论：模型不会因为你在页面上标了语言就更懂这门语言。语言标注解决的是给谁看的问题，跟模型能读懂多少完全是两件事，这两者常被混在一起说，后面会专门拆开讲。 ## 迁移效果跟词表重叠度的关系没那么大 直觉上，字母表和词汇重叠越多，迁移应该越强。 拉丁字母的语言看起来更容易从英语那里借到能力。 实测结论跟这个直觉不一致。 把词表重叠度当变量去看，相关性比预期弱得多。 也就是说共用多少字符串，不是决定性因素。 这条推翻了一个很流行的判断，值得单独记住。 这个结论有直接的实务价值：不要因为你的目标语言用的是西里尔字母或者谚文，就假定它拿不到迁移收益；也不要因为它用拉丁字母，就假定它一定受益。字母表这个变量在这件事上的解释力很有限，用它做判断会得出错误的优先级。 那么真正相关的是什么，答案在语法结构那一侧。 这个结论还能反驳一个常见的操作建议：在小语种页面上保留大量英文原词以便借力英语的理解能力。这个做法在词面匹配的时代有它的道理，因为英文词本身能被匹配到；但在迁移这件事上它帮不上忙，迁移走的是结构那条路，不是共用字符串那条路。 ## 语序类型才是相关性最强的那个变量 相关性最强的变量是两门语言的词序类型有多接近。 主谓宾的排列顺序、修饰语放在中心词前还是后，这类结构特征。 结构接近的语言之间，迁移效果明显更好。 结构差异大的语言，即便字母表相同，迁移也吃力。 这个结论解释了很多看起来反常的实测数据。 它也给了一个可操作的判断依据，比字母表靠谱得多。 用这个变量重新排一遍会得到跟直觉很不一样的顺序。语序接近英语的语言里，既有拉丁字母的，也有非拉丁字母的；而语序差异大的语言里，同样两种字母表都有。字母表和语序类型是两个独立的维度，混为一谈就是那个流行误判的来源。 接下来把常见的小语种按这个变量分个组，看谁在这一波里真的拿到了东西。 语序类型这个变量还有个好处是它极其稳定。语料量每年都在变，模型每隔一段时间就换一代，但一门语言的基本语序几十年不会变。所以用它做的分档判断有很长的保质期，值得花时间查准确，查一次能用很多年。 ## 哪些语种受益大，哪些受益小？ ## 语序接近英语的那批受益最明显 越南语的基本语序跟英语一致，都是主谓宾。 它的修饰语位置跟英语相反，但整体结构相近。 印尼语的语序也接近，而且形态简单没有屈折。 这两门语言在这一波里拿到的迁移收益相对明显。 泰语的语序同样接近，但它的分词问题另有一套。 东南亚三国的语言层横向对比 (https://zhangwenbao.com/southeast-asia-seo-vietnam-thailand-indonesia-language-layer.html)那篇拆过三家的结构差异。 结构相近还有一个具体好处：这些语言的长句歧义比自由语序语言小。模型读整句的时候，语序固定的语言给出的结构线索更明确，理解出错的概率更低，所以写长一点的自然表达在这几门语言上是安全的。 这三门语言可以率先调整策略，往完整问句和自然表达的方向走。 这一组还有个共同点值得利用：它们的形态都很简单，词不怎么变形。形态简单意味着词面覆盖的工作量本来就小，所以从词面策略转向自然表达策略的成本也低，几乎不存在推倒重来的问题，这让它们成为最适合先做调整的一组。 ## 语序差异大的那批受益有限 谚文使用的那门语言是主宾谓语序，跟英语差别大。 它还有大量的助词承担语法功能，结构上更不一样。 分写法和助词那篇 (https://zhangwenbao.com/korean-seo-spacing-particles-keyword-research.html)讲的机制，正是这种结构差异的具体形态。 结构差异大意味着从英语那里能借到的模式少。 所以这类语言的迁移收益要打不小的折扣。 它们仍然会受益，但幅度和确定性都不如前一组。 这一组语言的策略调整要更保守。词面信号在它们身上仍然起相当大的作用，铺变体、做完全匹配这些老办法的收益下降得慢，不该急着砍掉。把资源从老办法转向新办法这件事，在不同语种上应该有不同的节奏。 判断自家语种属于哪一组，先查它的基本语序，这个信息在任何语言学资料里都能查到。 这一组的另一个特征是它们往往有本土的搜索生态。谚文那门语言的市场就有份额相当大的本土引擎，而本土引擎的语言理解升级节奏跟国际引擎不同步。所以这一组语种要盯两条线，两条线上的策略可能在一段时间里是不一样的。 ## 自由语序语言处在中间，而且最不稳定 芬兰语和匈牙利语的语序相对自由，靠格尾表达语法关系。 自由语序意味着同一句话有多种合法的排列。 模型见到的结构变化更多，学起来更难收敛。 芬兰语的十五个格 (https://zhangwenbao.com/finnish-seo-fifteen-cases-consonant-gradation-keyword.html)和匈牙利语的十八个格 (https://zhangwenbao.com/hungarian-seo-eighteen-cases-vowel-harmony-keyword.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/single-intent-page-focus-engineering-vs-multi-intent-dilution.html)那篇讲的聚焦原则在这里更重要了，因为模型能读出整句的意思，一个页面里塞多个不相关的问题会让主题信号变模糊，而不是像以前那样单纯多接几个词。 常见问题这块是小语种站里改造成本最低、收益变化最明显的一处。 常见问题模块在小语种上还有个额外的用处，它是收集真实问法最快的反馈渠道。上线之后看哪几条问答带来了展现，就知道哪种问法接近用户的真实说法，这个信号可以反过来指导下一批内容的写法，形成一个闭环，比一次性猜对更可靠。 ## 功能词还能不能当停用词删？ ## 只塞名词的标题习惯要退休 旧习惯是标题里只留实词，把介词助词都省掉。 这么做的理由是节省有限的字符预算给关键词。 在词面匹配的机制下，这个取舍是合理的。 现在功能词承担的语法关系会被读进去。 省掉它们，句子的结构关系就丢了。 标题变成一串名词，模型读到的意思反而变模糊。 这个转变对小语种的影响比对英语大。英语的名词堆叠本身就是常见表达，读起来不算异常；很多小语种的名词堆叠是不合语法的，母语者一眼看出这是机器生成的东西，用户体验和理解两头都吃亏。 标题该恢复成一个能读通的短句，字符预算不够就砍掉次要成分，不要砍掉连接结构的那几个词。 ## 介词和助词承担的意思被读进去了 很多商业意图恰恰藏在功能词里。 用于某种场景、适合某类人群、不含某种成分。 这几类表达的关键信息全在介词和否定词上。 删掉之后，用于和不含变成了同一句话。 模型现在能区分这两者，前提是你把词留着。 否定词是最不能删的那一类，它会把意思反过来。 保哥接过一个做瑜伽与健身器材的客户，越南语站的商品标题按老规矩把介词全省了，结果适合初学者和适合进阶两类产品的标题几乎一样，用户点进来发现不对就走，等到把介词加回去，两类页面的意图才分得开。 做一遍标题体检，专门找那些因为省略功能词而意思变模糊的标题，通常能找出不少。 否定词这一类还有个更隐蔽的形态：表示范围限定的词。仅限、只适用于、除某种情况外，这几类表达删掉之后，页面承诺的范围就从有限变成了无限，用户点进来发现不符会立刻走。这类词在合规敏感的品类里删掉甚至会带来实际风险。 ## 哪些语言的功能词最不能删 孤立语最不能删，因为它没有形态标记。 越南语、泰语的语法关系全靠虚词和语序表达。 虚词删掉，关系就没有任何其他线索能补。 越南语的音节分写 (https://zhangwenbao.com/vietnamese-seo-tone-marks-syllable-spacing-keyword.html)让这个问题更容易被忽略，因为虚词看起来只是又一段字符。 屈折语的容忍度稍高，因为格尾还带着一部分信息。 但格尾也只覆盖名词性成分，动词关系仍然要靠虚词。 黏着语的情况介于两者之间。土耳其语把关系粘在词尾 (https://zhangwenbao.com/turkish-seo-agglutinative-suffix-stacking-keyword.html)的做法，让它对虚词的依赖比孤立语低，但后缀本身也不能随便截断，截断带来的损失跟删虚词是同一类。 按语言类型定一条最小保留清单，写进标题规范里，比每次靠写作者判断可靠。 ## 完全匹配和词形变体的策略该怎么调？ ## 完全匹配的堆叠收益继续下降 把关键词原样重复多次的做法收益一直在降。 模型读整句之后，重复带来的额外信号更少了。 它能识别出这几处说的是同一件事。 所以堆叠的边际收益趋近于零。 而堆叠带来的可读性损失是实实在在的。 这个方向上的判断很明确，堆叠该停。 要注意的是停堆叠不等于不写核心词。核心词该出现的位置仍然要出现，标题、首段、小标题这几处一次都不能少，变化的只是重复次数带来的额外收益消失了。把停堆叠误读成核心词可以不写，是另一个方向的过度反应。 堆叠这件事在小语种站上还有个具体形态：把同一个词的几种形态并排写在标题里，这在以前是变体覆盖的手段，现在读起来只是重复。 堆叠收益下降之后，那部分空出来的字符预算该往哪投也是个问题。比较稳妥的用法是放场景词和限定词，也就是那些能把意图收窄的成分。它们既提升了理解侧的清晰度，也让标题在结果页里对用户更有辨识度，两头都不亏。 ## 但低资源语言下降得比英语慢 这一条是本篇最反直觉的实务判断。 模型在某门语言上的理解能力越弱，词面信号的权重就越高。 因为除了词面，它没有更多可靠的线索。 所以低资源语言上，完全匹配的作用衰减得更慢。 这意味着不同语种的策略调整速度应该不一样。 高资源语种可以快调，低资源语种要慢调。 一刀切地全语种同步改，是这一波里最容易犯的错。英语站的经验拿过来直接执行，会在低资源语种上过早放弃仍然有效的词面覆盖，那部分流量的损失是可以避免的。零搜索量关键词到底有没有用 (https://zhangwenbao.com/zero-volume-keywords-true-value-aio-longtail-engineering.html)那篇的思路在这里也适用：先验证再决定砍不砍。 调整的节奏差异要写进各语种的执行方案，不能靠一份统一的指引。 ## 词形变体覆盖优先级下调但不能取消 模型能归并一部分词形变体，这是真的。 子词切分让它有机会认出同一个词干的不同形态。 所以逐个铺变体页面的必要性下降了。 但归并能力在低资源语言上明显更差。 而低资源语言里正好有一批形态最复杂的。 所以这件事的优先级可以下调，但不能取消。 下调的具体做法是分层：核心品类词的主要形态继续覆盖，长尾词的形态覆盖可以放手交给模型。这样既省下了大部分工作量，又保住了最重要那批词的确定性，比全做或者全不做都合理。 判断哪些词属于核心那一层，用营收贡献排序，前两成的词继续人工覆盖。 还有一个判断哪些形态必须人工覆盖的实用办法：看站内搜索日志里用户实际打了哪些形态。日志里高频出现的形态就是必须覆盖的，从来没出现过的形态可以放手。这比按语法规则穷举所有形态省事得多，也更贴合真实需求分布。 ## 按语种分档的策略表怎么写 第一档是语料充足、语序接近的语种，激进调整。 停堆叠、写完整问句、变体覆盖只留核心词。 第二档是一好一差的语种，分品类试点。 选两三个品类改，跟未改的品类对照看数据。 第三档是语料稀薄、语序差异大的语种，保持现状。 只做一件事：把标题里删掉的功能词加回去。 第三档只改功能词这一条是有讲究的：加回功能词几乎没有成本也没有风险，它同时改善可读性和理解，是任何档位都该做的动作。而停堆叠、砍变体这些动作有明确的机会成本，在能力弱的语种上不该提前做。 三档的划分每年复核一次，因为语料在长、模型在换，档位是会变的。 ## 怎么自己验一遍，而不是听别人说？ ## 三种问法的对照实验怎么设计 取同一个意图，写成三种问法。 第一种是关键词式，几个名词堆在一起。 第二种是口语问句式，一句完整的自然问法。 第三种是带否定或者介词的复杂式。 三种问法在目标语市场各查一遍，记录结果。 看的是自家页面在哪种问法上有位置，哪种没有。 这个设计的关键是三种问法必须指向同一个意图，否则比较就没有意义。写完三条之后自己读一遍，确认如果这三个问题分别来问你，你会给出同一个答案，这样才算对照组成立。每个品类取三到五组，一个语种二十条查询就够跑起来。 这套实验的成本是一个人半天，产出的是自家语种的真实分档依据，比任何外部数据都可靠。 实验设计上还有一个容易忽略的对照项：把竞品也纳入观察。同一组查询里，如果三种问法上的赢家都换成了同一批站点，那说明这类问法上的偏好确实变了；如果赢家各不相同，那更可能是随机波动。加上这一列几乎不增加成本，但结论的可靠性提升明显。 ## 要记录什么，多久看一次 记录四项：查询串、问法类型、自家排名位置、结果页里的赢家类型。 第四项最有价值，它告诉你引擎在这类问法上偏好什么内容形态。 频率是每季度一次，不要更频繁。 因为要观察的是能力层面的变化，那是慢变量。 连续四个季度的记录，才能看出趋势方向。 单次结果只能当快照，不能当结论。 记录的时候把语种也当成一个维度存起来。多语种一起记的好处是能横向对比，比如同一个品类的同一种问法，在越南语上自家页面有位置而在匈牙利语上没有，这个差异本身就是分档判断的证据，比单看一个语种的绝对表现信息量大得多。 这类实验属于第一手数据，攒够几个季度之后，它比任何行业分析都值得信。 ## 三条当年做错的事 第一条是看到覆盖七十多种语言就砍了词表预算。 结果低资源语种那一路的排名在两个季度后掉下来。 原因就是那些语言上词面信号仍然在起主要作用。 第二条是把英语站的写长句打法直接搬到自由语序语言。 长句在那些语言里的歧义更大，效果不如中等长度的清晰句。 第三条是拿覆盖多语言当理由，推迟了语言标注这一层的工作。 第三条错得最离谱。理解能力跟站点架构是两个完全不同的层，模型能读懂页面的意思，不等于它知道这个页面该给哪个市场的用户看。多语言站的语言标注该怎么落地 (https://zhangwenbao.com/international-seo-hreflang-complete-guide.html)那篇讲的是架构层，那部分工作一点都没减少。 三条错误的共同点是把一次理解层的进步当成了对其他层的免除，这是最该防的一类误读。 这三条错误还有个共同的时间特征：它们造成的损失都要滞后一到两个季度才显现。所以纠正的机会窗口很窄，等到数据难看再回头查，中间已经积累了不少沉没成本。防这类错误的最好办法是任何大幅度的策略调整都先在两三个品类上试点，别整站同时改。 ## 哪些事一个字都没变？ ## 抓取、收录、编码、字形集全部原样 抓取和收录的机制跟这件事无关。 编码的规范化问题原样存在，一点没变。 字形集拖首屏的问题原样存在。 从右往左的布局问题原样存在。 本地字符域名和路径的编码问题原样存在。 这些属于技术层，理解层的进步不会碰到它们。 把这一条说清楚有实际意义：技术层的欠账会让理解层的进步用不上。页面进不了索引，理解能力再强也没有对象；首屏太慢用户跑了，被理解得再准也没有转化。理解层的收益要靠技术层的完好来兑现。 技术层的检查清单一条都不能省，这件事对它没有任何减负作用。 技术层这条还有一个具体的提醒：不要因为理解能力提升了就放松对页面渲染的要求。模型读的是抓取到的文本，抓不到的部分它一个字都读不到。渲染依赖脚本、关键内容延迟加载这类问题，在理解能力再强的情况下也只会得到一个空页面。 ## 架构层跟理解层是两件事 架构层管的是哪个版本给哪个市场看。 理解层管的是这个版本的内容说了什么。 两者互不替代，也互不补偿。 架构错了，正确的内容会被送给错误的用户。 理解层帮不上这个忙，它不做市场分配。 所以语言标注、地区定向、域名结构这一套照旧要做。 这两层容易被混淆，是因为它们都带语言这个词。但语言标注解决的是同一门语言的多个地区版本该怎么区分、不同语言版本之间怎么互指，这是关系问题；理解层解决的是一段文本的意思，这是内容问题。同一个词在两个市场问的不是一件事 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)那篇讲的意图分叉，恰恰是理解层无法替架构层解决的那类问题。 把两层的职责在方案文档里写清楚，能挡住不少想拿新技术抵消旧工作量的提议。 再补一个区分两层的判断办法：问一句这个问题换成英语站还存在吗。如果换成英语站也存在，那多半是架构层或技术层的问题，跟语言理解无关；只有在换成英语站就不成立的那些问题上，理解能力的差异才是主要变量。这条判据跟本栏目的选题边界用的是同一个逻辑。 ## 下一代模型的方向已经指出来了 就在这次铺开的前一个月，一项新的研究给出了下一步。 思路是把训练语料从百科换成规模大得多的网页抓取语料。 覆盖一百种语言，而且明确针对低资源语言做优化。 这条路线的存在本身就验证了语料量决定上限这个判断。 如果语料不是瓶颈，就不会有人往这个方向使劲。 所以按语料规模给语种分档这个方法，短期内不会失效。 对小语种SEO来说，这个方向意味着现在受益小的那批语种，未来会补上来。补上来的时候，第三档的策略就该往第二档移，所以那张分档表要留着，每年拿出来重排一次。机器翻译直接发布的质量红线 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)那篇讲的语料量决定质量，跟这里是同一个规律在另一个环节的表现。 能力会随语料增长而提升，这是好消息；但提升的顺序仍然是高资源语言先、低资源语言后，这个顺序短期内不会改。 ## 常见问题解答 ## 覆盖七十多种语言之后，小语种关键词研究还要不要做 要做，而且在低资源语种上比以前更值得做。理由是理解能力的提升在各语言上不均匀，语料稀薄的语言上词面信号仍然占主要权重，关键词表在那里的作用没有下降。真正变化的是关键词研究的产出该怎么用：以前是把所有词形变体都铺成页面或者写进标题，现在核心词的主要形态继续覆盖，长尾形态可以交给模型归并。也就是说工作量在减少，但研究本身的必要性没有减少。判断自家语种能减多少，看语料量级和语序类型这两个变量，估完之后用三种问法的对照实验验一遍。最该避免的做法是看到覆盖多语言的消息就整块砍掉词表预算，这在语料稀薄的语种上会直接损失流量，而损失要等两个季度才显现，那时候已经很难归因了。 ## 为什么用拉丁字母的语言不一定更受益 因为决定跨语言迁移强弱的主要变量不是字母表重叠度，是词序类型的相似度。实测研究把这两个变量分开检验过，结论是语序类型的相关性明显更强，而共用多少字符串的解释力有限。直观的解释是这样：模型学到的是语言的结构规律，比如修饰语放在中心词前还是后、语法关系靠词序还是靠形态标记。这些规律跟用什么字母写完全无关。两门语言即使字母表完全不同，只要结构相似，模型就能把在一门语言上学到的结构知识用到另一门上；反过来，字母表相同但结构差异大的两门语言，能借的东西反而少。所以判断自家语种受益幅度的时候，第一件事是查它的基本语序，而不是看它用什么文字。 ## 标题里的介词和助词到底要不要留 要留，尤其是承载意图差别的那些。判断标准很简单：把这个词删掉，句子的意思会不会变模糊或者变反。适合初学者里的适合、不含某种成分里的不含、用于某种场景里的用于，这几类删掉之后意图就丢了，必须留。纯粹的语法性虚词，删了不影响意思的，可以按字符预算取舍。孤立语的容忍度最低，因为它没有形态标记可以补偿虚词的缺失。屈折语稍好，因为格尾还带着一部分关系信息，但动词相关的关系仍然靠虚词。实际操作上建议做一次标题体检，专门找那些因为省略虚词而意思变模糊的标题，改回来的成本很低，收益是意图分得更清。顺便说一句，加回虚词几乎没有风险，这是所有语种都该做的动作，不分档位。 ## 自由语序的语言该写长句还是短句 写结构清晰的中等长度句子，不要一味写长。英语站流行的写长句自然表达的建议，前提是英语的语序固定，长句的成分关系明确。芬兰语、匈牙利语这类语序相对自由的语言，同一句话有多种合法排列，句子越长，成分之间的关系就有越多种可能的解读，模型确定关系的难度反而上升。实际的做法是控制单句长度，一句只表达一层关系，需要表达多层就拆成两句。这跟站内一直坚持的短段落原则方向一致，只是理由不同：短段落是为了移动端可读性，这里是为了减少结构歧义。另外这类语言的格尾本身就承载了大量关系信息，写作时保持格尾正确比把句子写长重要得多，如果只能顾一头，顾形态那一头。 ## 怎么判断自家语种属于哪一档 查两个数就够。第一个是这门语言的百科条目数，看数量级：几百万是高，几十万是中，几万或者更少是低。第二个是它的基本语序跟英语的距离：主谓宾且修饰语位置接近的算近，主宾谓的算远，语序自由的算中。两个数落在九宫格的哪一格，就是哪一档。两项都好的第一档可以激进调整策略，两项都差的第三档保持现状只加回功能词，一好一差的第二档选两三个品类做试点。这个划分的精度有限，所以务必配上三种问法的对照实验来校准，实验数据跟估算不一致的时候信实验。还有一点：档位是会变的，语料在长、模型在换，建议每年重排一次，别把一次划分当永久结论。 ## 常见问题模块真的值得认真写吗 值得，它是小语种站里改造成本最低而收益变化最明显的一处。原因是这个模块天然就是完整问句加完整答案的结构，正好是模型最擅长处理的形态，而以前它在小语种上的检索价值很低，因为词面匹配处理不了问句。写认真的标准有三条：问题要贴着用户真实的问法写，不要写成书面化的疑问句；每条答案要能独立成立，不依赖上下文，因为它可能被单独取用；一个页面里的问题要围绕同一个意图，别把不相关的问题堆在一起稀释主题。收集问题的来源优先用站内搜索日志和客服记录，那里的问法是真实的；关键词工具在小语种的问句类查询上基本给不出数据，不用指望它。改造顺序建议从营收占比最高的品类开始。 ## 这件事对结构化数据和内链有什么影响 直接影响很小，间接影响有两处。结构化数据这一层的规则没有变化，该标的字段照标，格式要求照旧，理解能力的提升不会替你把缺失的标注补上。内链这一层有一个值得注意的变化：锚文本从堆核心词转向写自然短语，收益结构变了。以前锚文本里塞完全匹配的关键词有明确收益，现在模型能从上下文理解链接指向什么，自然的锚文本不再吃亏，而且可读性更好。不过这个转变的节奏同样要按语种分档，低资源语种上锚文本的词面信号衰减得慢，不必急着全改。另外提醒一点，锚文本在屈折语里会跟着格变形，这跟这次的更新无关，是一直存在的问题，处理方式也没变：优先让锚文本里的核心词保持词典原形，形态实在不通顺就调整句子结构而不是牺牲形态。 ## 权威参考资料 ## 缅甸和斯里兰卡天天在用佛历，这两门语言的日历数据里一条都没有 - URL：https://zhangwenbao.com/minor-language-non-gregorian-calendar-data.html - 分类：小语种SEO - 发布：2019-12-06 | 更新：2019-12-06 - 摘要：十六套非公历历法在五十门语言上的填充实测：佛历圈只有泰语填齐，缅甸语僧伽罗语整段不存在，缺数据时页面上出现BE、AH、ERA1这类缩写。 - 关键词：多语言SEO,小语种SEO,出海建站,网站本地化 > **TLDR**：摘要：把公共区域数据里十六套非公历历法在五十门语言上的填充情况逐格数了一遍。第一，泰国官网写的年份比今年大543，而缅甸语、僧伽罗语、宗卡语的文件里佛历整段不存在，高棉语和老挝语各只有一条还标着未确认。第二，老挝语给日本年号填了236条，给自己的佛历填了1条。第三，缺了这一格不会报错，页面上出现的是BE、AH、ERA1这类英文缩写。 > 摘要：把公共区域数据里十六套非公历历法在五十门语言上的填充情况逐格数了一遍。第一，泰国官网写的年份比今年大543，而缅甸语、僧伽罗语、宗卡语的文件里佛历整段不存在，高棉语和老挝语各只有一条还标着未确认。第二，老挝语给日本年号填了236条，给自己的佛历填了1条。第三，缺了这一格不会报错，页面上出现的是BE、AH、ERA1这类英文缩写。 泰国的政府网站、发票、身份证上写的年份是四位数，比公历大543。今年公历2019年，那上面写的是2562。 这件事在做泰国市场的人里不算冷知识。真正的问题是它不止泰国一家，而绝大多数团队的处理方式是等出事再说。 保哥前阵子把公共区域数据里所有跟历法有关的字段翻了一遍，本来只想确认一下各门语言的历法支持情况，结果发现这一格的分布毫无道理可言：天天在用某套历法的国家，它的语言里那套历法可能一条数据都没有；而一辈子用不上某套历法的国家，它的语言里那套历法填得整整齐齐两百多条。 更麻烦的是，缺了这一格系统不会报错。它会安静地回落到最上层的通用值，而最上层的通用值是几个英文缩写。用户看到的年份前面会出现两三个拉丁字母。 下面这些数字是为了让这件事在上线前而不是上线后被发现。 ## 用另一套历法的地方，到底有多少？ 先把范围划清楚，不然容易把这件事想得太大或者太小。 ## 制度上默认不用公历的地区只有三组 公共区域数据里有一张历法偏好表，逐个地区列出该地区按什么顺序优先使用哪几套历法。全表只有14条记录，其中第一顺位不是公历的只有三组。 泰国排第一的是佛历，伊朗和阿富汗排第一的是波斯历，沙特排第一的是回历中的一个特定算法版本。其余11组的第一顺位都是公历。 所以从制度上说，需要把非公历当默认的市场并不多。如果你的市场清单里没有这三组，这一格的优先级可以往后放。 但第一顺位不是全部。表里还列出了第二、第三顺位——以色列的第二顺位是希伯来历，埃及是科普特历，埃塞俄比亚是埃塞历，印度是印度国历，日本是年号纪年，韩国是檀纪，台湾地区是民国纪年，中国大陆和新加坡是农历。 沙特那一条还有个细节：它的第一顺位是回历里一个叫乌姆库拉的算法版本，而不是通用的回历。回历有好几种推算方式，彼此日期能差一天，选错版本在宗教场合是要出事的。 ## 第二顺位才是真正会出事的地方 第一顺位是公历意味着系统默认渲染不会出错，但它不意味着那套历法在当地不重要。以色列的日历应用、节庆安排、政府文书里希伯来历随处可见。 做希伯来语市场 (https://zhangwenbao.com/hebrew-seo-unvocalized-script-root-letters-keyword.html)的人对这一条会有实感：一周从周日开始这件事已经够折腾了，节庆日期还得按另一套历法算。 第二顺位的典型场景是促销和节庆。斋月、光明节、诺鲁孜节这些日子在公历上每年都在动，而当地用户是按另一套历法记住它们的。 你的活动排期表如果只有公历，那就意味着每年都要有人手工去查一次日期，而这个人多半在总部。 判断一个市场要不要重视第二顺位，有个简单办法：看当地的银行、政府和大型零售商的官网上有没有并列写两套年份。有，说明这件事在当地是日常。 ## 还有一批用法根本不在那张表里 那张偏好表管的是操作系统和浏览器该默认显示哪套历法，它不覆盖所有实际用法。财年、宗教节庆、农事节气这些都不在里面。 比较典型的是农历。表里只给中国大陆、香港、澳门、新加坡和圣诞岛列了农历作为第二顺位，但农历在越南、韩国、马来西亚华人社区同样是活的。 另一个是印度国历。表里给印度列了它，可印度实际在用的地方历法有十几种，国历只是官方那一套。 所以这张表的正确用法是当下限：表里有的一定要处理，表里没有的还得问一句当地同事。 财年是另一个容易漏的。多个中东国家的财政年度不按公历1月起算，报表按月汇总的时候如果直接用公历月，跟当地会计口径对不上，这件事到年底才会暴露。 ## 2019年的几个对照数字 历法 | 2019年对应的年份 | 主要使用地区 | 跟公历的关系 | 佛历 | 2562 | 泰国、缅甸、柬埔寨、老挝、斯里兰卡 | 年份加543，月日相同 | 民国纪年 | 108 | 台湾地区 | 年份减1911，月日相同 | 日本年号 | 令和元年 | 日本 | 年份按在位重置，月日相同 | 波斯历 | 1398 | 伊朗、阿富汗 | 月份与月长完全不同 | 回历 | 1441 | 中东、部分东南亚与非洲 | 纯阴历，一年少11天 | 埃塞历 | 2012 | 埃塞俄比亚、厄立特里亚 | 13个月，年份少7到8年 | 这张表里最容易被忽略的是最后一列。前三行的月和日跟公历完全一样，只有年份数字不同；后三行连月份都是另一套。 这个区别后面会反复用到，因为它决定了缺数据的后果差多远。 还有一个直觉陷阱：回历的年份1441看起来比佛历的2562小很多，容易让人以为它更接近公历。实际正相反，回历是这六套里跟公历差得最远的。 另外要注意年份边界。回历一年354天，它的新年在公历上每年往前挪11天；埃塞历新年固定在公历9月11日前后；波斯历新年是春分。跨年统计的时候这几条各自会造出不同的错位。 ## 一门语言有几套历法，这个数字为什么不能信？ 这是本篇最需要先说清楚的一件事，因为它决定了后面所有数字怎么读。 ## 第一版数出来的结果全是错的 保哥第一版的做法很直接：打开每门语言的文件，数里面出现了几个历法定义段，非公历的算一套。数出来的结果是老挝语10套、马来语11套、越南语12套。 然后打开祖鲁语看了一眼。祖鲁语声称有两套非公历，佛历和农历。南非跟这两套都没关系，但数据在那儿。 把那一段内容打开一看，里面所有的值都是三个向上的箭头——那是继承标记，意思是这一格跟上级一样。祖鲁语的这两套历法数据，一个字都没有。 同样的问题还有哈萨克语。它唯一的一套非公历是科普特历，而科普特历是埃及的。打开一看，月份名写的是1到13的阿拉伯数字，而且每一条都标着未确认。 这已经是这类实测里第九次被同一种事情绊住了：某个指标看着能解释一切，打开原始记录一看是另一回事。能一次性解释所有小语种的漂亮结论，先拿一个大语言或者一个不相干的地区去证伪它。 ## 怎么一眼看出那一段是假的 不用逐格数也能快速判断。第一个信号是段落的字节数：真正填过的历法段通常在几千字节以上，泰语的佛历段有8199字节；只有一两百字节的，里面装不下12个月份名。 第二个信号是月份名的内容。打开看，如果月份名写的是1到12的阿拉伯数字，那就是占位不是翻译。哈萨克语的科普特历就是这个样子。 第三个信号是那些向上的箭头。整段全是箭头的，等于零，祖鲁语的两套历法都属于这种。 三个信号任意命中一个就可以判定这一格不可用，不需要再往下细看。这套判断三十秒能做完。 这三个信号里最可靠的是第二个。数字占位这种写法只可能来自批量导入，没有任何一个真人会把月份名填成1到13。看到它基本可以判定这门语言的这一格从来没有本地人经手过。 ## 重新数，把三种假数据剔掉 正确的数法要剔掉三类：值等于继承标记的、标着未确认的、标着暂定的。这两个概念的正式定义都写在区域数据规范总则 (https://www.unicode.org/reports/tr35/tr35.html)里：后两类在生成发布数据时会被丢弃，第一类本来就是借的。 剔完之后的结果跟第一版差得很远： 语言 | 声称有几套非公历 | 真正有内容的 | 差多少 | 高棉语 | 1 | 0 | 全没了 | 祖鲁语 | 2 | 0 | 全没了 | 哈萨克语 | 1 | 0 | 全没了 | 格鲁吉亚语 | 3 | 0 | 全没了 | 库尔德语 | 1 | 0 | 全没了 | 老挝语 | 10 | 9 | 少1套 | 印尼语 | 8 | 7 | 少1套 | 阿姆哈拉语 | 5 | 3 | 少2套 | 越南语 | 12 | 11 | 少1套 | 五门语言从有变成了零。这五门里，高棉语丢掉的那一套正是柬埔寨在用的佛历。 这件事本身值得记一笔：数一门语言有没有某套历法，不能数段落有没有出现，要数段落里有几个格子真的填了东西。 关于继承标记这个符号本身的来历，以及它为什么2019年才第一次能被数出来，写在上一篇讲区域数据自有率的文章 (https://zhangwenbao.com/minor-language-locale-data-inheritance.html)里，这里不重复。 还有一个副产品：剔完之后再看那些数字大的语言，可信度反而提高了。繁体中文的农历861格、日语的年号521格，这些都是真填的，一格箭头都没有。 ## 佛历圈这五个地方，数据差成什么样？ 佛历是这几套里对照最干净的，因为使用它的五个国家都在东南亚和南亚，宗教背景一致，用法也一致。 ## 五门语言，一个满格四个空 语言 | 国家 | 佛历段字节数 | 真正填了几格 | 纪年名写法 | 泰语 | 泰国 | 8199 | 95 | 全称与缩写都是泰文 | 高棉语 | 柬埔寨 | 109 | 0 | 有一条高棉文缩写，但标着未确认 | 老挝语 | 老挝 | 109 | 0 | 有一条老挝文缩写，同样未确认 | 缅甸语 | 缅甸 | 0 | 0 | 整段不存在 | 僧伽罗语 | 斯里兰卡 | 0 | 0 | 整段不存在 | 宗卡语 | 不丹 | 0 | 0 | 整段不存在 | 泰语那一段有8199字节，里面除了纪年名，还单独定义了佛历的日期格式模板——因为泰语写年份的时候要在数字前面加纪年缩写，语序跟公历不一样。 高棉语和老挝语那两段各只有109字节，里面就一条纪年缩写，而且都带着未确认的标记。前面说过，这个标记意味着它到不了发布数据里。 换句话说，柬埔寨语和老挝语的佛历，有人填过，但那一条至今没有走完确认流程。填的那个人可能已经等了好几年。 要说明的是，这五门语言在整体数据量上并不悬殊：泰语6039格、老挝语5345格、僧伽罗语4653格、缅甸语4054格、高棉语3942格，同一个量级。差距集中在历法这一格上。 ## 泰语那8199字节里写了什么 泰语的佛历段是这份数据里佛历填得最完整的一份，值得拆开看看一份填好的历法数据长什么样。 首先是纪年名，全称和缩写各一条，都是泰文。然后是完整的日期格式模板，从最长的那种带星期几的写法，到最短的纯数字写法，一共几档。 关键在模板这一部分。泰语写日期的时候纪年缩写要放在年份数字前面，而公历的模板里没有这个位置，所以必须单独定义。 这解释了为什么95格就够用：佛历的月和日跟公历一样，可以直接借用公历那一套，真正需要单独写的只有纪年名和几个模板。泰语在别的技术环节上的坑 (https://zhangwenbao.com/thai-seo-no-spaces-word-segmentation-keyword.html)不少，历法这一格倒是这几门语言里做得最好的。 各套历法的字段结构在区域数据规范的日期部分 (https://www.unicode.org/reports/tr35/tr35-dates.html)里有完整说明，包括纪年、月份、格式模板各自该怎么写。要自己补数据的话，那份文档是唯一的依据。 ## 缅甸和斯里兰卡是彻底的空白 缅甸语、僧伽罗语、宗卡语的文件里，佛历这个段落根本不存在。不是空的，是不存在。 这三个地方对佛历的使用强度不比泰国低。缅甸的传统节庆、斯里兰卡的卫塞节、不丹的宗教历法，都是日常。 做东南亚几个市场的语言层规划 (https://zhangwenbao.com/southeast-asia-seo-vietnam-thailand-indonesia-language-layer.html)时，这一条可以直接写进风险清单：这三门语言在历法这一格上，你拿不到任何本地数据。 顺带说一句，缅甸语在别的格上并不弱——它的数字格式679格填了677格，几乎满格。所以这不是这门语言没人维护，是历法这一格没人碰。 不丹的宗卡语情况更特殊一点，它整个文件只有1446格，是这批语言里最薄的，只有英语的四分之一。这门语言在数据层面上基本处于起步阶段。 ## 那一格空了之后，页面上写的是什么 最上层的通用数据里，佛历的纪年缩写是两个拉丁字母：BE。月份则直接借用公历的月份名。 所以缅甸语页面如果启用佛历渲染，年份会写成BE 2562这种形式，月份是缅甸文的，纪年标识是英文的。中间夹一个空格。 用户看到的是一句缅甸文里插了两个拉丁字母。它不影响理解，但它明确地告诉本地用户：这个站不是本地做的。 这类细节对转化的影响没法量化，但它跟地址栏里用本地字母还是拉丁转写 (https://zhangwenbao.com/minor-language-url-native-script-vs-latin-transliteration.html)是同一个性质的东西，属于一眼能看出来但没人会专门反馈的那一类。 补救成本其实很低。佛历的年份换算是加543这么一个固定数，纪年名替换成本地写法就是改一个字符串。真正的成本在没人知道要改。 ## 为什么老挝语的日本年号比它自己的佛历厚两百多倍？ 这是本批实测里最让人意外的一条，也是最能说明这一格是怎么长成现在这样的一条。 ## 236条对1条 老挝语文件里的日本年号那一段，填了236格，全部是真数据。里面是从公元645年的大化开始，历朝历代所有年号的老挝文音译。 同一个文件里，老挝语自己的佛历那一段，只有1条，而且标着未确认。 236比1。老挝人不用日本年号，老挝人天天用佛历。 类似的还有中国农历那一段，老挝语填了160格。老挝人也不用农历。 把这两个数摆在一起的时候保哥愣了一下，先怀疑是自己的脚本数错了段。打开原文一看，那236条确实是老挝文写的日本年号，从大化、白雉一路排下来。 ## 哪些内容能批量灌，哪些不能 把填得满的那几类内容列出来，共同点很清楚：日本年号是一份固定的历史清单，农历干支是六十个循环名，科普特历和埃塞历的月份名是固定的十三个词。 这些都是专有名词，数量有限，音译规则一旦定下来就可以一次生成。一个懂音译规则的人加一个脚本，一晚上能出几百条。 填不满的那几类则相反：本地历法的纪年名要看这门语言的实际书面习惯，日期模板要看这门语言的语序，复数形式要看这门语言的语法。 这些都得问人，而且得问对人。需要一次询问的字段填得满，需要一次判断的字段空着，这条规律在整份数据里到处成立。 这条规律反过来也能用：拿到一份陌生语言的本地化数据，先看哪几块填得满。如果满的全是清单型内容，那这份数据大概率没经过本地人审阅，只是跑过脚本。 ## 这不是有人乱填，是批量导入的结果 把历史版本并排看就明白了。2012年那一版，老挝语总共只有413个字段，非公历历法只有1套。2013年那一版突然变成3734个字段、10套历法。 一年之间涨了九倍，这不是人一格一格填出来的。合理的解释是某次批量导入，把一批可以机械音译的内容一次性灌了进去。 年号名、农历干支名、科普特历月份名这类东西的共同点是：它们是专有名词，音译规则确定，可以批处理。而佛历的纪年名要看这门语言的实际习惯，批不了。 能批量处理的那部分被填满了，需要问一句本地人的那部分空着。这条规律在这一格上表现得比任何地方都极端。 ## 同样的形状在别的语言上也成立 泰语的日本年号274格，比它自己的佛历95格还多。孟加拉语的希伯来历170格，而孟加拉跟希伯来历毫无关系。 最典型的是马来语：希伯来历167格，全部是真数据；而马来西亚在用的回历只有63格，另外还有23格明确写着跟上级一样。 马来西亚是穆斯林占多数的国家，回历是国家历法之一。做马来语和印尼语两个市场 (https://zhangwenbao.com/indonesian-malay-seo-two-markets-vocabulary-split.html)的人可以拿这一条去说服排期：这一格是缺的，而且缺得没道理。 顺带一提，印尼语的回历有110格，比马来语多。同一套历法、同一片区域、两门高度近似的语言，差了将近一倍。 这个现象还有一层含义：某门语言的某套历法数据厚，不能推断这门语言的本地化做得好，只能推断有人跑过一次批量任务。两者的相关性比直觉低得多。 ## 回历那一格，谁填了谁没填？ 回历是使用范围最广的一套非公历历法，横跨中东、南亚、东南亚和非洲，值得单独看。 ## 填了的那一批 阿拉伯语117格、印尼语110格、土耳其语105格、乌尔都语104格、索马里语110格、阿塞拜疆语102格、乌兹别克语102格、马来语86格。 这一批的共同点是它们都定义了完整的12个月份名。回历的月份跟公历完全不同，所以这12个名字是必须的，不填就只能用英文转写。 阿拉伯语那一份还额外定义了完整的日期格式模板，跟泰语在佛历上的做法一样。阿拉伯语页面的方向问题 (https://zhangwenbao.com/arabic-seo-rtl-layout-msa-dialect-keyword.html)本来就多，日期这一格倒是齐的。 要注意几门语言里带继承标记的比例：乌尔都语104格里有53格是借的，阿塞拜疆语102格里54格，乌兹别克语102格里49格。也就是说这几门语言真正自己填的只有一半。 另外值得一提的是索马里语。它的回历有110格，但其中89格是借的，真自有只有21格。光看总数会以为它填得跟阿拉伯语差不多，实际差了五倍。 土耳其语这一行有个值得一提的地方：它的科普特历84格，比自己的回历73格还多。土耳其跟科普特历没有任何关系，这又是一次批量导入留下的痕迹。 ## 没填的那一批更值得注意 哈萨克语、吉尔吉斯语、豪萨语、斯瓦希里语，这四门语言的回历段整段不存在。 哈萨克斯坦和吉尔吉斯斯坦是穆斯林占多数的国家；豪萨语的主要使用区域是尼日利亚北部，那里同样如此；斯瓦希里语的沿海使用区历史上就是伊斯兰贸易圈。 四门语言都跟回历有实际关系，四门语言的数据都是零。 而前面提到过，这四门里哈萨克语唯一那套非公历是科普特历，内容是1到13的数字，全部未确认。这个组合已经不像是有人在维护，更像是某次导入留下的残余。 豪萨语这一行还有个背景：它整份文件里三分之二的格子都是借的，历法只是其中一块。这门语言的格式层整体成色都薄，不只是历法这一格。 ## 印尼语和马来语差了将近一倍 印尼语的回历110格，马来语63格。这两门语言在语言学上高度近似，两国的穆斯林比例都很高，回历的用法也基本一致。 差异不来自语言本身，来自维护这两门语言数据的是两批不同的人，投入不同。 这一条对做这两个市场的人有直接影响：如果你打算用一套内容覆盖两边，格式层这一格是不能共用的，因为其中一边比另一边薄。 更细一点看，马来语那86格里有23格是借的，真自有只有63格；印尼语151格里41格是借的，真自有110格。两边借的比例也不一样。 这一条也说明了为什么不能拿一门语言的数据去推另一门。两门语言再近，维护它们的是两拨人，数据成色就是两回事。 ## 回历缺数据的后果比佛历严重得多 回缺到通用层之后，纪年缩写是AH两个字母，月份则直接借公历的月份名。这就出问题了。 回历的第9个月是斋月，跟公历的9月毫无关系。如果月份名直接借公历，那么回历日期在页面上会显示成一个公历月份名配一个对不上的数字。 这不是难看的问题，是错的问题。前面那张表里最后一列的意义在这里体现出来：佛历缺数据只是纪年名难看，回历缺数据是整个日期读不对。 同一个道理适用于波斯历和埃塞历。做伊朗市场 (https://zhangwenbao.com/persian-seo-iran-market-letters-digits-zwnj.html)的人尤其要留意，因为波斯历是伊朗的第一顺位历法，不是备选。 ## 日本年号那一格为什么是全表最厚的？ 日语文件里的年号段有521格，其中474条是纪年名。这是整份数据里单套历法最厚的一格，比第二名多一倍还不止。 ## 474条纪年名意味着什么 474这个数字来自日本年号制度本身：从公元645年到现在，一共换过两百多个年号，而每个年号还要有全称、缩写、单字母缩写几种写法。 最后几条是M、T、S、H、R，分别对应明治、大正、昭和、平成、令和的首字母。这几个单字母缩写在日本的表格和证件上很常见。 令和是今年5月1日启用的新年号，这一版数据里已经有了。 做日语内容 (https://zhangwenbao.com/japanese-seo-hiragana-katakana-kanji-keyword-notation.html)的人应该知道，年号和公历在日本是并行的，政府文书、合同、证件用年号，商业场合两者都有。 这474条里还包含了一批很早期的年号，公元七世纪的都在。实际业务里用不到，但它们的存在说明这份数据是照着一份完整的历史清单填的，不是按需填的。 ## 今年春天那次改元逼出了一个额外版本 年号跟其他所有历法有一个根本区别：它会因为一个人的更替而在没有任何数学规律的时间点上重置。 新年号是4月1日公布的，5月1日生效，中间只有一个月。这意味着全世界所有处理日语日期的软件，都要在一个月内更新一次数据。 公共区域数据这一侧的反应写在今年春天那一版的发布说明 (https://cldr.unicode.org/index/downloads/cldr-35)里，原话是：预计4月发布一个点版本，包含针对日本历法的进一步改动。 一个专门为了一套历法而加发的版本，这在这份数据的历史上不常见。它也从侧面说明，历法这一格一旦出错，影响面有多大。 值得对照的是，同一时期各家操作系统和办公软件也都发了补丁。一个国家换个年号，全球的软件供应链跟着动一遍，这种事在别的历法上不会发生。 ## 其他语言里的日本年号也不算薄 前面提过老挝语给日本年号填了236格。这不是孤例：泰语274格、繁体中文795格、阿拉伯语237格、俄语237格、瑞典语240格、韩语250格。 把这些数字跟同一门语言自己那套本地历法比一比，很多都是反的。阿拉伯语的回历117格，日本年号237格，多了一倍。 解释还是那一条：年号是一份可以机械音译的固定清单，而回历的月份名要看当地的实际写法。 这也给了一个反向的判断法：如果一门语言的某套历法数据特别厚，先看看那套历法的内容是不是清单型的，别急着当成本地化做得好。 ## 这件事对你的启发不在日本 日本这个案例的价值在于它把一件平时看不见的事放大了：历法数据不是常量，它会变。 年号是最极端的一种，但不是唯一一种。沙特2016年调整过财年基准，泰国的官方年份在不同文件上偶尔并列两套，回历各个算法版本之间的日期能差一天。 所以这一格不能查一次就当查完了。它属于要跟着依赖库版本一起复查的那一类。 顺带说一句，日语这一格填得厚跟日本的技术社群规模有关系。这也解释了为什么其他语言里的日本年号也填得不错——它有一个明确的、可批量音译的清单摆在那儿。 ## 两类非公历必须分开对待 把前面几节的结论收一下，这一格真正可操作的判据只有一条。 ## 只改年份的那一类 佛历、民国纪年、日本年号属于这一类。它们的月和日跟公历完全一致，区别只在年份数字和纪年标识上。 这一类缺数据的后果是可控的：纪年标识会显示成BE、R.O.C.这类英文缩写，月份日期都是对的。用户能看懂，只是觉得别扭。 补救成本也低。你只需要在自己的模板里把那个纪年标识替换成本地写法，几行代码的事，不需要动日期计算逻辑。 甚至可以更简单：这一类历法的年份换算是加减一个固定数，泰国加543，台湾地区减1911，自己算比调库还稳。 这一类还有个好处：即使你完全不处理，页面上显示的公历日期对本地用户来说也是可读的，因为这些地方公历同样通用。风险等级低。 ## 连月份都不一样的那一类 回历、波斯历、埃塞历、希伯来历属于这一类。它们的月份数量、月份长度、年的起点跟公历全都不同。 这一类缺数据的后果是硬伤：月份名会借用公历的，导致一个明确错误的日期显示在页面上。而且没法用简单的加减修复。 补救只有两条路：要么找到一份可靠的本地月份名清单自己填进去，要么干脆不在这些市场上启用非公历显示，全部走公历。 后一条路听起来消极，但它比显示一个错的日期强。在这一格上，不做比做错便宜得多。 这一类里波斯历要额外小心，因为伊朗的第一顺位就是它，不是公历。也就是说在伊朗市场上，公历才是那个需要额外说明的东西，关系反过来了。 ## 希伯来历算第三种情况 希伯来历的月份跟公历完全不同，按前面的分类属于第二类。但它还多一层麻烦：它有闰月，闰年的时候多出一个月，而且月份编号会变。 所以希伯来历的月份名条目数比别的历法多，以色列本地的希伯来语填了154格，其中84条是月份相关的，比回历的72条多。 数据里能看到闰月那个月份被写成两条，一条对应平年一条对应闰年。这种结构如果你自己填是想不到的。 结论是：这一类历法不要试图自己补数据，能找到本地填好的就用，找不到就别启用。希伯来语这门语言 (https://zhangwenbao.com/hebrew-seo-unvocalized-script-root-letters-keyword.html)本身的坑已经够多了，历法这一格好在数据是齐的。 运行时具体挑哪套历法、挑不到的时候怎么退，写在ICU的历法服务文档 (https://unicode-org.github.io/icu/userguide/datetime/calendar/)里。自己实现闰月逻辑之前，先读一遍那份文档能省掉很多返工。 ## 埃塞历那一格有个特别难看的细节 通用层里其他历法的纪年缩写好歹是有意义的字母——佛历是BE，回历是AH，波斯历是AP，印度国历是Saka。 埃塞历的通用值是ERA0和ERA1。这不是缩写，这是占位符，是程序里的变量名漏到了数据里。 阿姆哈拉语自己填了埃塞历的173格，所以埃塞俄比亚市场没事。但厄立特里亚的提格里尼亚语整段不存在，它的用户如果看到埃塞历，纪年名就是ERA1。 这一条可以当成整篇文章的缩影：缺数据的时候系统不会道歉，它会拿出一个内部标识符，然后正常渲染。 ## 页面上哪几个地方会先出事？ 把上面的东西落到实际页面上，出事的顺序是有规律的。 ## 第一个出事的是表单校验 用户按本地习惯填出生日期，填的是佛历年份2530，你的年龄校验拿它减2019，算出一个负数，然后拒单。 这是最早被发现的一类，因为用户下不了单会来投诉。但投诉的措辞通常是网站不让我注册，不会是历法问题。 反过来的情况更隐蔽：用户按公历填，你的系统按佛历解析，算出这个人有五百多岁，某些风控规则会静默拦截。 解决办法不是猜，是在输入框旁边明确标出用哪套历法，并且在提交时做范围校验。这一步的成本远低于事后排查。 还有一种更少见但更贵的：优惠券的有效期。用户按本地历法理解截止日，你按公历判断，中间差出来的那几天全是客诉。 ## 第二个是结构化数据 商品的上架时间、活动的起止时间、文章的发布时间，这些字段在结构化标记里必须是公历的标准格式。 如果你的日期渲染层被配置成按本地历法输出，而结构化数据又复用了同一个渲染函数，那么标记里会出现一个五百多年后的日期。 这类错误的表现是整段标记被判为无效，而不是某一个字段有问题。排查的时候很容易往标记结构上找，找半天。 判据很简单：给用户看的日期和给机器看的日期必须走两条不同的路径，前者可以本地化，后者永远是公历。 这一条跟锚文本报告里那些对不上的数字 (https://zhangwenbao.com/minor-language-internal-link-anchor-inflection-variants.html)是同一类问题：给机器读的那一份有自己的口径，跟页面上给人看的那一份从来不共享，而没有任何一环会提醒你两者已经不一致了。 ## 第四个是导出文件和对账 订单导出、财务对账、发票这些场景里的日期如果被本地化了，接收方多半读不对。尤其是跟本地供应商对接，对方发来的单据上写的可能就是本地历法。 这是双向的：你发出去的可能被对方按公历读，对方发来的可能被你按公历读。两个方向都会把整批数据的时间轴平移几百年。 做泰国供应链的人对这一条会有实感，因为泰国的商业单据上佛历年份很常见，而且不会特别标注。 处理原则跟结构化数据一样：凡是给机器读的日期一律公历，并且在字段名或者文件头上写清楚是公历。 还有一类是定时任务和报表。按自然月跑的任务如果用了本地历法的月边界，回历那种一年354天的历法会让某些月被跑两次、某些月被跳过，而日志里看不出异常。 ## 第三个是排序和筛选 如果日期在数据库里存的是公历，展示的时候转成本地历法，那么按展示值排序会得到一个错误的顺序，尤其是跨年的时候。 回历这类一年只有354天的历法尤其容易出问题，因为它的年份边界跟公历的年份边界每年都在移动。 正确的做法是排序永远用底层的公历值，只在最后渲染那一步做转换。这条规则跟处理工具返回值的思路 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)一致：转换只在最外层做一次。 顺带说一句，促销倒计时也归这一类。后端存公历，前端按本地历法渲染截止日期，用户看到的是五百多年后到期，这个活动的紧迫感就没了。 一个容易漏的地方是分页和归档页。按年月归档的列表如果年份是转换后的值，归档页的地址和标题会跟着变，而这些地址是被收录过的。 ## 上线前这一格怎么查？ 整个检查过程不超过十五分钟，四步。 ## 第一步：确认这个市场用不用非公历 先查历法偏好表里有没有这个地区。有，看它的第一顺位是不是公历。是公历，这一格的优先级可以降低；不是，必须处理。 然后看第二顺位。有第二顺位的地区，虽然默认渲染不会出错，但节庆和活动排期需要单独考虑。 没出现在表里的地区，按纯公历处理。要注意历法也可以作为扩展子标签直接写进语言标签，写法由RFC 5646 (https://www.rfc-editor.org/rfc/rfc5646)规定，别自己发明格式。 这一步只需要打开那张表看一眼，两分钟。 ## 第二步：查这门语言那一套历法填了没有 打开这门语言的文件，搜索那套历法的名字。整段不存在的，直接判定为零。 段落存在的，要接着看两件事：里面有几个格子的值是三个向上的箭头，有几个格子带着未确认或暂定的标记。这两类都要剔掉。 剩下的数字才是真实的填充量。低于10格的，基本等同于没填。 这一步是整个检查里唯一需要动手数的地方，一门语言五分钟。 如果你不方便去翻原始文件，退而求其次的办法是在本地环境里用浏览器自带的日期格式化接口 (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat)渲染一个日期，看输出里的纪年名是不是本地文字。是英文缩写，就说明回落了。 ## 第三步：按两类分开定处理方式 只改年份的那一类，缺数据就在自己的模板里补一个纪年标识，年份换算用固定加减，不依赖库。 连月份都不一样的那一类，缺数据就先关掉非公历显示，走纯公历，并且在页面上明确标注这是公历日期。 两类都要在输入端把历法说清楚，这一条跟数据填不填无关，是产品设计问题。 做完这一步，就可以给这个市场写一句结论了。 还有一条通用做法：无论哪一类，都在页面上显示日期的地方标明用的是哪套历法。多写三个字，能省掉一大半的客诉。 ## 查完写成一句话 最后把结论收成一句：这个市场默认用哪套历法，这门语言那一格填了多少，属于两类里的哪一类，以及页面上哪几个位置需要人工验。 这句话跟着市场进排期表，跟词典能力、字体能力、界面翻译完成度并列。它们分属不同的层，但都是上线前该有答案的。 要提醒的是，这一层的结论不该影响做不做这个市场。泰国市场值不值得做，跟泰语的佛历数据齐不齐是两个问题。 它影响的只是预留多少工时，以及要不要在第一版就上非公历显示。多数情况下第一版走纯公历、把非公历放进第二版，是更稳的排法。 这句话还有一个用处：跟本地化服务商谈的时候可以直接问，你们对这门语言的历法数据是自己补还是用公共数据。答不上来的，说明这一格他们没查过。 ## 第四步：把日期渲染和数据输出分开 最后一步跟数据无关，是工程约定：确保给用户看的日期和写进结构化标记、写进接口返回、写进导出文件的日期，走的不是同一个函数。 这一条做到了，前面所有的坑最多影响显示，不会影响数据正确性。没做到，一个配置项就能让整站的日期数据全错。 值得检查的地方还有邮件模板和短信模板，它们经常是另一套渲染逻辑，配置项也另有一份。 保哥见过一次事故，站上日期全对，确认邮件里全是佛历年，因为邮件服务是另一个团队接的，那边照着文档把区域设置填成了泰语。 ## 哪些相邻的问题不归这一层管？ 这一格容易跟旁边几件事混起来，划一下界。 ## 本地数字系统是另一件事 有些语言默认使用本族数字而不是拉丁数字。缅甸语的默认数字系统是缅甸数字，尼泊尔语是天城文数字，孟加拉语是孟加拉数字，波斯语是波斯扩展数字。 这跟历法完全无关，但它们经常一起出问题，因为都由同一个格式化调用决定。有意思的是高棉语和老挝语的默认数字系统是拉丁数字，虽然它们都有自己的一套数字。 所以同一片佛历圈里，缅甸语页面的价格默认会用缅甸数字，高棉语和老挝语默认用阿拉伯数字。这三门语言在这一格上的行为完全不同。 处理原则也不一样：数字系统影响的是可读性和可搜索性，历法影响的是正确性。两者别一起改，改完分不清是哪一个导致的变化。 这一格还跟收录有关。如果价格用本族数字渲染，那么页面上的价格字符串跟用户在搜索框里打的可能不是同一串字符，这属于关键词覆盖那一类问题 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)而不是显示问题。 ## 字符渲染是再往下一层 纪年名如果是本地文字写的，还得字体里有那些字形才画得出来。泰文的纪年缩写、埃塞俄比亚文的月份名，都不在常见的西文字体子集里。 这就跟网页字体的字形集取舍 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)连上了：为了控制首屏体积裁掉的字符，可能正好是日期里要用的那几个。 排查顺序是先确认数据层输出的是哪几个字符，再确认字体里有没有。反过来查会很绕。 这两层的负责人通常不是同一批人，中间那道缝是问题最容易掉进去的地方。 一个具体的例子：泰文的纪年缩写里有一个点号加两个泰文字母，如果字体子集是按常用字裁的，这三个字符未必都在。 ## 时区和夏令时不在这里 时区是另一套完全独立的数据，跟历法没有交集。一个日期用哪套历法显示，和它属于哪个时区的哪一天，是两个正交的问题。 把它们混在一起排查会得出很奇怪的结论，比如以为某个市场的日期偏了一天是历法问题，其实是时区问题。 分辨方法：偏一天的是时区，偏几百年的是历法，月份对不上的是历法里连月份都不一样的那一类。 这三种偏差的量级完全不同，一眼就能分开。 顺带说一句，伊朗直到2022年前都实行夏令时，而它同时又用波斯历，两件事叠在一起排查会很痛苦。分开查是唯一的办法。 ## 节庆日期不归这一层，也不归任何一层 斋月哪天开始、卫塞节是哪一天、诺鲁孜节今年落在几号，这些不在区域数据里。这份数据管的是怎么把一个日期写出来，不管哪些日子是节日。 节假日数据是另一套东西，而且各国口径不一，很多国家的宗教节日还要等官方或者宗教机构临近才公布确切日期。 所以活动排期这件事没有一个可以查的公共数据源可用，只能靠当地同事或者本地服务商。这一点跟前面所有内容都不同。 把它写在这里是为了避免一种常见的误会：以为把历法数据配好了，节庆排期就自动对了。这两件事完全不搭界。 ## 翻译和审校碰不到这一格 跟上一篇讲的那些格式字段一样，历法数据不出现在任何一份待翻译稿件上，它是系统渲染的产物。 所以再认真的母语审校流程 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)也覆盖不到它，除非你专门让审校人员看渲染后的真实页面。 要覆盖它只有一个办法：在验收清单里单独列一条，让本地同事看真实页面上的日期，而不是看文档。 这一条加上之后，这类问题基本能在上线前一天被发现，而不是上线三个月后被客服转述。 这一条跟上一篇的结论是同一个：所有由系统渲染出来的字符串，都不在任何一份人工审校的覆盖范围里，需要单独建一条验收路径。 ## 常见问题解答 ## 我的市场清单里要不要处理非公历？ 先查历法偏好表。第一顺位不是公历的只有三组：泰国是佛历，伊朗和阿富汗是波斯历，沙特是回历的一个特定算法版本。这三组必须处理。有第二顺位的地区，默认渲染不会出错，但节庆和活动排期要单独考虑，包括以色列、埃及、埃塞俄比亚、印度、日本、韩国、台湾地区，以及中国大陆和新加坡的农历。清单里完全没出现的地区，按纯公历处理就行。 ## 怎么判断一门语言的历法数据到底填没填？ 打开这门语言的原始文件，搜那套历法的名字。整段不存在的直接判零。段落存在的，要剔掉两类假数据：值是三个向上箭头的继承标记，以及带着未确认或暂定标记的格子——后者在生成发布数据时会被丢掉。剔完之后低于10格的基本等同于没填。实测里有五门语言按第一种数法有数据，剔完之后是零，其中包括柬埔寨的高棉语，丢掉的正好是它自己在用的佛历。 ## 缺数据的时候页面上会显示什么？ 会回落到最上层的通用值，而且不报任何错。佛历显示BE，回历显示AH，波斯历显示AP，印度国历显示Saka，民国纪年显示R.O.C.。最难看的是埃塞历，通用值是ERA0和ERA1，那是程序里的占位符不是缩写。月份则一律直接借用公历的月份名——对佛历这类只改年份的历法没关系，对回历这类连月份都不同的历法就是错的。 ## 佛历和回历缺数据的严重程度一样吗？ 差很多。佛历、民国纪年、日本年号的月和日跟公历完全一致，只有年份数字不同，缺数据只是纪年标识变成英文缩写，用户能看懂。回历、波斯历、埃塞历、希伯来历的月份数量和长度跟公历全不一样，缺数据之后月份名会借公历的，页面上出现的是一个明确错误的日期。前一类可以在自己模板里几行代码补上，后一类要么找到可靠的本地月份名清单，要么直接关掉非公历显示走纯公历。 ## 年份换算要不要用现成的库？ 只改年份的那一类不用，自己加减一个固定数更稳：泰国加543，台湾地区减1911。连月份都不一样的那一类必须用库，因为月长和闰规则不是简单算术，尤其回历还有好几个算法版本，彼此的日期能差一天。用库的时候记得锁版本，并且确认它内置的区域数据是哪一年的——日本年号这类会变的东西，旧版本里可能根本没有。 ## 为什么这类问题上线前很少被发现？ 因为它不出现在任何一份待翻译稿件上，是系统渲染的产物，所以翻译和审校流程碰不到它；它也不报错，页面正常、布局正常、状态码正常，所以监控发现不了。唯一能发现它的是让懂那门语言的人看渲染后的真实页面，并且专门盯日期那几个字符。把这一条写进验收清单，成本只有几分钟。 ## 结构化数据里的日期该用哪套历法？ 永远是公历的标准格式，没有例外。给用户看的日期可以本地化，给机器看的不行。这两者必须走两条不同的代码路径，如果复用了同一个渲染函数，一个配置项就能让整站的标记里出现五百多年后的日期，而表现是整段标记被判为无效，不是某个字段报错。同样的规则适用于接口返回值、导出文件和日志。 ## 小语种的本地化数据，看着有的多半是借的，看着空的反而是对的 - URL：https://zhangwenbao.com/minor-language-locale-data-inheritance.html - 分类：小语种SEO - 发布：2019-11-26 | 更新：2019-11-26 - 摘要：759个语言版本原始文件实测：豪萨语三分之二的格子写着跟上级一样，度量单位1117格自有为0；而en_US只有527字节，是因为它本身就是默认值。 - 关键词：多语言SEO,小语种SEO,网站本地化,建站选型 > **TLDR**：摘要：把公共区域数据仓库里759个语言版本的原始文件逐格数了一遍。第一，看着有的多半是借的——豪萨语文件里66.1%的格子明确写着跟上级一样，度量单位那一整块1117格里自己填的是0。第二，看着空的反而常常是对的，en_US、de_DE、fr_FR、pt_BR这些文件都只有527字节，因为老家就是默认值。第三，这两件事以前分不开，2019年这一版第一次给继承加了标记，才第一次数得出来。 > 摘要：把公共区域数据仓库里759个语言版本的原始文件逐格数了一遍。第一，看着有的多半是借的——豪萨语文件里66.1%的格子明确写着跟上级一样，度量单位那一整块1117格里自己填的是0。第二，看着空的反而常常是对的，en_US、de_DE、fr_FR、pt_BR这些文件都只有527字节，因为老家就是默认值。第三，这两件事以前分不开，2019年这一版第一次给继承加了标记，才第一次数得出来。 做多语言站的人都干过这么一件事：想知道某门语言的日期、数字、货币写法有没有人做过，于是去查一眼公共的区域数据。查到了，文件在，几百KB，心里踏实了，转头去忙别的。 保哥今年秋天把这个动作认真做了一遍，把759个语言版本的原始文件全下下来，一格一格数。数完发现，刚才那个踏实来得太早了。 问题不在于数据有没有，而在于“有”这个字在这份数据里至少有三种意思：有人认真填了本地的写法、有人看过之后确认跟上级一样、没人看过所以什么都没有。前两种在文件里长得几乎一样，第三种干脆不出现在文件里。 更拧巴的是另一头。你按市场去查，查到en_US这个文件只有527字节，几乎是空的，很容易得出美式英语没做的结论。事实正好相反，那份文件空是因为它就是默认值，不需要再写一遍。 一头是看着有的其实是借的，一头是看着空的其实是对的。两个方向的直觉都错，而且错的方向相反。下面这些数字是为了把这两头掰回来。 ## 那个向上的箭头是什么意思？ 先说这一批数据里最扎眼的东西。打开豪萨语的文件，会看到大量长这样的行：一个字段名，里面写着三个向上的箭头。 ## 它不是乱码，是一个正式定义的标记 三个向上箭头这个符号，在区域数据标记语言规范 (https://www.unicode.org/reports/tr35/tr35.html)里有正式名字，叫继承标记。规范里的原话是：它用于在数据提交阶段记录“这个继承来的值已经针对当前语言和当前路径被验证过”。 翻成人话就是：有个人坐在那里，看到这一格是空的，系统按规则给他显示了上级语言的值，他看了一眼，觉得对，按了确认。这一按，就在文件里留下一个箭头。 规范里举的例子是德语的瑞士版本。上级德语里“阿布哈兹语”这个词条写作Abchasisch，有人确认瑞士德语也是这么写，于是瑞士德语那一格就记成箭头，而不是把Abchasisch再抄一遍。 所以这个标记本身是个好东西。它把“确认过一样”和“没人看过”这两件事第一次分开了，而在此之前，这两件事在文件里完全无法区分——都表现为该字段不存在。 规范里还强调了一点：这个标记只出现在主仓库里，是数据提交流程的产物，不属于最终数据格式的一部分。这句话对我们的意义是，它记录的是人的动作，不是语言的属性。 ## 这个标记是2019年这一版才大规模出现的 保哥把同一门语言的八个历史版本并排数了一遍，结论很干净：2017年那一版、2018年那一版、乃至2019年春天那一版，箭头数量都是0；到2019年10月这一版，箭头突然大量出现。 这不是语言变了，是记录方式变了。这一版的发布说明 (https://cldr.unicode.org/index/downloads/cldr-36)里写着，仓库开始保留针对继承值的投票记录，并且新增了一个工具在生成发布数据时把这些标记解析掉。 对我们来说，这意味着一件很实际的事：2019年之前你没法数出一门语言有多少格是借来的，因为借来的和没人管的写在一起。2019年之后可以数了。 这也意味着，如果你手上有一份两年前做的语言能力评估表，那张表里“字段数”那一列的口径跟今天不是一回事，不能直接比。 换个角度说，2019年这一版第一次让外人能看见本地化流程里发生了什么。在此之前，这份数据只呈现结果，不呈现过程。 ## 你在实际用的那份数据里看不到这个标记 这个标记只存在于源文件里。生成给程序用的发布数据时，它会被解析成上级语言的实际值，然后消失。 所以如果你是通过某个前端库或者某份JSON包去查这门语言有没有数据，你永远看不到箭头，只会看到一个填好的值——那个值是英语的，但它长得跟本地填的一模一样。 这解释了一个长期现象：很多团队查过区域数据，得出的结论都是齐全的，因为他们查的是解析之后那一层。要看到借来的痕迹，必须去看源文件，而不是看运行时的返回值。 这也是本篇所有数字都基于原始文件的原因。换一个数据源，同一门语言会得出完全不同的结论，而且是更好看的那一种。 ## 顺带解决了一个长期存在的假象 标记出现之后，某些语言的文件字段数会突然暴涨，因为原来不写的格子现在都写出来了。豪萨语从春天那一版的1200格涨到秋天这一版的4348格，涨了262%。 如果只看这个数，会得出豪萨语的本地化在半年里突飞猛进的结论。但把箭头剔掉之后，真正填进去的从1136格涨到1465格，只涨了29%。 一个数据量涨了两倍多，另一个数据量涨了不到三成，说的是同一件事。差别只在于你把那些确认过跟上级一样的格子算不算数。 这就是本篇要讲的第一件事：查这门语言有没有数据的时候，字段总数这个指标已经不能单独用了。 ## 把箭头剔掉之后，各门语言还剩多少？ 下面这张表是2019年10月这一版，五十门语言逐格数出来的结果。真自有率的算法是：把值等于继承标记的格子剔掉，再把标注为未确认和暂定的格子剔掉，剩下的除以总格数。 ## 三门西非语言站在一头，六成以上是借的 语言 | 总格数 | 继承标记 | 真自有 | 真自有率 | 豪萨语 | 4348 | 2876 | 1465 | 33.7% | 伊博语 | 3084 | 2004 | 1068 | 34.6% | 约鲁巴语 | 3131 | 1949 | 1169 | 37.3% | 越南语 | 6566 | 1890 | 4676 | 71.2% | 索马里语 | 4477 | 1019 | 3441 | 76.9% | 祖鲁语 | 5109 | 727 | 4382 | 85.8% | 波兰语 | 6918 | 703 | 6172 | 89.2% | 马来语 | 5477 | 556 | 4921 | 89.8% | 英语 | 5556 | 0 | 5556 | 100.0% | 豪萨语、伊博语、约鲁巴语是尼日利亚的三大语言，加起来覆盖两亿多人口。三门语言的真自有率都在33%到38%之间，三分之二的格子写着跟上级一样。 要说明的是，跟上级一样这件事本身不一定错。有些字段确实全世界通用，比如某些技术性的格式模板。问题在于比例——三分之二这个量级，说明这不是逐格判断的结果，而是整块整块过的。 另一头英语是0，因为英语就是那个上级，它没有可继承的对象。这一行的作用是给整张表提供一个刻度：100%在这里不是优秀，是定义。 需要说清楚的是，这三门语言在语言名称那一块填得都不差，说明维护它们的人是在认真做事的。差距落在格式层，而格式层的门槛比翻译层高得多。 ## 中间那一档是什么形状 索马里语和祖鲁语落在中间。索马里语总格数4477，其中1019格是借的，真自有3441，占76.9%；祖鲁语5109格里727格是借的，真自有4382，占85.8%。 索马里语值得多看一眼，因为它的曲线很陡：2017年那一版总共只有795格，2018年跳到3477格，两年里翻了四倍多。这是典型的有人接手了的形状。 祖鲁语的形状则平缓得多，几年里稳步爬升。陡增说明有组织的一次性投入，缓增说明有个人在持续维护，两者对未来的预期完全不同。 做技术选型的时候，这两种形状的判读方式不一样：陡增的语言要问一句那次投入是不是一次性的，缓增的语言可以按现状线性外推。 ## 越南语这一行要单独解释 越南语看起来还行，71.2%，但它的绝对数字很反常：1890个格子标着继承标记，而它上一版的总格数是4985，这一版真自有4676——真自有反而比上一版的总数还少了三百多格。 这不是数据被删了。合理的解释是，这1890格里有相当一批，在上一版是把父语言的值原样抄了一遍写在里面的，看起来是自己填的；这一版换成了标记，值没变，性质第一次被写明。 换句话说，越南语这一行的变化不是能力变化，是坦白。它以前显示的自有量里，本来就有一块是抄来的，只不过没人知道。 做越南语这门语言的技术评估 (https://zhangwenbao.com/vietnamese-seo-tone-marks-syllable-spacing-keyword.html)时，这一点值得记一笔：它的基础数据成色比总量看起来的要薄一层，但薄得有限，跟西非那三门不是一个量级。 这也提醒了一件事：任何一个跨版本的对比，都要先确认两版的记录规则一样。规则变了，趋势就是假的。 ## 这张表该怎么用，不该怎么用 该用的方式是横向比同一门语言的不同区块，或者比几门候选语言的同一个区块。这两种比较的口径是一致的。 不该用的方式是拿总格数给语言排名，也不该拿这一版的绝对值去跟别的版本比。前面已经说过，2019年这一版的计数口径跟之前不同。 还有一种误用是把真自有率当成本地化质量的分数。它不是分数，它只回答一个问题：这门语言的格式层有多大一块直接等于英语。 至于那一块等于英语要不要紧，取决于这门语言跟英语在格式习惯上差多远。差得远的，比例低就是大问题；差不多的，比例低也没什么。 ## 数字本身有个天花板要注意 这张表里最厚的一门语言总格数接近一万，最薄的不到一千，差了将近十倍。但这个差距不能直接读成能力差十倍。 原因是格数里有一大块是“别的语言叫什么名字”这类词条，一门语言只要有人把两百多种语言的名字都翻一遍，格数立刻上去几百。这一块对你的商品页几乎没有影响。 所以看总量之前，得先知道这些格子分布在哪几块上。下一节把它拆开。 顺带说一句，这也是为什么保哥不建议直接拿字段总数给语言排优先级——它跟排优先级真正该看的那几个量 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)不是一回事。 保哥自己第一版就是按总格数排的，排出来豪萨语在五十门语言里排中游，看着挺正常。剔掉箭头之后它掉到了倒数第几名。一个指标能让结论反过来，那它就不该单独用。 ## 那些借来的格子，具体落在哪几块上？ 把豪萨语的文件按功能区块拆开，继承标记的分布一点都不平均。这一节是本篇对做站的人最直接的一节。 ## 度量单位那一整块，自己填的是零 区块 | 管什么 | 总格数 | 豪萨语真自有 | units | 千克、厘米、天、小时的写法 | 1117 | 0 | delimiters | 引号用哪一对符号 | 4 | 0 | characters | 这门语言用哪些字符 | 28 | 4 | numbers | 小数点、千分位、货币格式 | 824 | 149 | listPatterns | 三个词并列怎么连 | 36 | 14 | dates | 日期时间怎么写 | 1492 | 738 | localeDisplayNames | 各种语言地区叫什么名字 | 680 | 558 | 度量单位1117格，真自有0格，全部是确认跟上级一样。引号那4格也是0。这意味着豪萨语页面上如果按系统默认渲染，引号用的就是英语那一对，单位说法也是英语那一套。 这不是漏了，是有人明确按过确认。整整1117次。 相比之下，语言名称那一块680格填了558格。规律很清楚：翻译者认真做了那些一眼能看出是翻译活的部分，而把格式性质的部分整块放过去了。 把这1117格摊开看，里面是千克、米、秒、天、小时这些日常单位在单数复数各种情形下的说法。对一个卖实物商品的站来说，这一块几乎每张商品页都用得到。 ## 为什么语言名称那一块反而填得最满 豪萨语680格的语言名称填了558格，是它填得最满的一块。其他所有语言的这一块也普遍高于其他区块。 原因不难猜：这一块的内容是“阿拉伯语在豪萨语里叫什么”这类问题，一眼就知道是翻译活，谁都能上手，而且做起来有成就感——一次能填几百格。 度量单位那一块则完全不同。它的内容是模板，长得像代码，里面有占位符，填之前得先搞清楚这门语言的复数规则和词序。 翻译者优先做那些看起来像翻译的部分，而格式层恰好是最不像翻译的那部分。这个规律在别的本地化项目上也成立，不是这份数据独有的。 ## 换一门语言对照，这个形状就不一样了 语言 | units真自有/总 | numbers真自有/总 | 引号 真自有/总 | 豪萨语 | 0 / 1117 | 149 / 824 | 0 / 4 | 伊博语 | 6 / 770 | 96 / 631 | 0 / 4 | 约鲁巴语 | 65 / 770 | 105 / 607 | 4 / 4 | 越南语 | 539 / 853 | 683 / 828 | 4 / 4 | 缅甸语 | 761 / 799 | 677 / 679 | 4 / 4 | 高棉语 | 687 / 799 | 637 / 637 | 4 / 4 | 斯瓦希里语 | 1110 / 1178 | 855 / 855 | 4 / 4 | 泰语 | 760 / 806 | 919 / 919 | 4 / 4 | 英语 | 1564 / 1564 | 1008 / 1008 | 4 / 4 | 缅甸语和高棉语的数字格式是全填的，一格不差。这两门语言在别的维度上通常被归到资源最少的那一档，可在这一格上比尼日利亚那三门语言强得多。 斯瓦希里语的度量单位1178格填了1110格。同样在非洲，同样是志愿者维护，形状完全不同。 所以这不是地区问题也不是资源问题，是维护这门语言的那几个人当时选择从哪一块开始动手的问题。 还有一个细节：伊博语的引号那4格是0，约鲁巴语是4。同一个国家的两门语言，同一个区块，一个整块借着一个自己填了。这种粒度的差异只能实测。 ## 一个反向的例子值得记住 缅甸语的数字格式679格填了677格，高棉语637格一格不差全填了，泰语919格也是全填。这三门语言在很多能力评估里被归到资源最少的那一档。 而豪萨语的数字格式824格只填了149格。豪萨语的使用者人数比高棉语多得多。 这个反差说明，格式数据的成色跟使用人数、跟这门语言在网上的内容量都没有稳定关系。它取决于有没有一个懂技术又懂这门语言的人在某一年坐下来把它填完。 所以这一格必须逐门语言实测，不能从别的指标推断。这是本篇最该记住的一条方法论：这一层没有代理指标。 ## 对你的页面意味着什么 把上面的表倒过来读，就是一张风险清单。数字格式那一块借来的比例高，意味着价格的小数点和千分位可能按英语规则渲染。 度量单位那一块借来的，意味着商品规格里的重量长度单位名称会以英语形式出现在本地语言的句子中间。 引号那一格借来的，意味着你的评论区、商品描述里的引用会用英语的弯引号，而不是这门语言习惯的符号。这一条视觉上最不起眼，但它跟字体那一层的取舍 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)会叠在一起出问题：字体里没有那个符号，就会掉成方框。 这三样的共同点是，它们都不在翻译稿里，所以任何一轮母语审校流程 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)都碰不到它们。审校看的是你给的文案，而这些东西是系统渲染出来的。 这三类的共同点还有一个：它们都不会出现在任何一份翻译交付物里，所以在项目管理上它们没有负责人。没有负责人的东西不会被排进任何一个迭代。 ## 为什么en_US那个文件只有527字节？ 换一头。前面讲的是看着有的其实是借的，这一节讲反过来的那一半：看着空的其实是对的。 ## 空壳文件在这份数据里占了一大半 759个语言版本文件里，327个不到700字节，另有100个在700到1500字节之间。加起来427个，占56.3%。这些文件打开之后除了一个身份声明段，什么都没有。 但空壳的分布极其规律。带地区或书写系统后缀的变体一共551个，其中427个是空壳，占77.5%；而不带后缀的纯语言代码一共208个，空壳数量是0。 一个都没有。这个整齐程度本身就是个信号：空不是随机发生的，是有规则的。 规则就是：如果这个地区的写法跟语言默认值完全一致，就不需要写任何东西。文件存在只是为了声明这个组合是合法的。 反过来讲，如果哪天你看到一个纯语言代码的文件也是空壳，那才是真的出事了——那说明这门语言被登记了，但一个字段都没人填过。这一版里这种情况是0个。 ## 527字节这个数字本身说明了什么 空壳文件的字节数高度集中在527这个值上。打开看，里面是版权声明、文档类型声明，加上一个身份段，写着这个文件对应哪门语言、哪个地区。 数据段一个字节都没有。文件存在的全部意义是声明这个组合合法，并且告诉解析器不用再往下找了。 527这个数字之所以整齐，是因为这些文件是工具生成的，模板一样，只有语言代码和地区代码那两处不同。 顺带说一句，如果你看到某个变体文件在1000到1500字节之间，多半是里面多了一两个字段。这一档最值得打开看，因为那一两个字段就是这个地区的全部特殊性。 ## 哪些是空壳，哪些不是，能反推出默认值是谁 语言 | 空壳的那个 | 有数据的那个 | 说明默认值是谁 | 葡萄牙语 | pt_BR（527字节） | pt_PT（344KB） | 默认是巴西 | 西班牙语 | es_ES（527字节） | es_MX（312KB） | 默认是西班牙 | 英语 | en_US（527字节） | en_GB（392KB） | 默认是美国 | 繁体中文 | zh_Hant_TW（551字节） | zh_Hant_HK（632KB） | 默认是台湾 | 斯瓦希里语 | sw_TZ（527字节） | sw_KE（304KB） | 默认是坦桑尼亚 | 阿拉伯语 | ar_EG（1045字节） | ar_SA（265KB） | 默认接近埃及 | 葡萄牙语这一行值得停一下。做葡语两个市场 (https://zhangwenbao.com/portuguese-seo-brazil-portugal-two-markets-keyword.html)的人，直觉上会把pt理解成葡萄牙，把pt_BR理解成巴西的变体。这份数据里正好反过来：pt本身就是巴西葡语，葡萄牙那一版才是需要单独写出来的那个。 所以如果你的系统里配的是pt，用户在里斯本，他看到的日期和数字格式是巴西的。这个错误不会报任何异常，页面也是葡萄牙语的，只是格式偏了。 西班牙语的默认值则是西班牙，跟西语两侧市场那套词汇分叉 (https://zhangwenbao.com/spanish-seo-es-es-latam-keyword-divergence.html)的处理逻辑正好错开——词汇上通常要按拉美单独做，格式上默认值却站在西班牙那边。 这张表也可以当成一份历史记录来读：默认值站在哪一边，基本反映了这份数据最早成型的那几年，谁在贡献、谁的用例被优先考虑。 ## 有两个地区代码不对应任何一个国家 前面提到的en_001和en_150，这两个代码后面的数字不是国家代码。001代表全世界，150代表欧洲。 它们是为了解决一个实际问题造出来的：英语在几十个国家用，这些国家的写法大多一致但都跟美式不同，如果每个国家写一遍就是几十份重复数据。于是造一个国际英语放公共部分。 en_001有57KB的实际内容，en_150只有2174字节。也就是说欧洲英语跟国际英语的差别很小，只有那么两千多字节。 西班牙语的es_419也是同类，419代表拉丁美洲。看到代码后面跟的是数字而不是字母，就要意识到这不是一个国家，是一组国家的公共层。 ## 不是空壳的那些，反而是要小心的 反过来看，一个地区文件如果有几百KB，说明这个地区跟语言默认值差得远。这些才是需要在配置里显式写清楚的。 荷兰语的比利时版本是5317字节，德语的奥地利版本5126字节，瑞士版本8897字节。数字不大，但不是零，说明确实有一批字段不一样。 做荷兰语两个市场 (https://zhangwenbao.com/dutch-seo-netherlands-belgium-flemish-two-markets.html)的时候，这几KB就是佛兰芒那一侧格式层的全部差异。它不多，但它存在，而且写它的人是为了它不一样才写的。 判据可以固化成一句：文件大不代表做得好，代表跟默认不一样；文件空不代表没做，代表这里就是默认。 顺着这条判据往下推还有一层：某个地区文件从空壳变成有内容，说明有人发现了差异并提交了。所以文件的历史变化本身就是一份差异发现记录。 ## 你以为的父语言，可能不是真的父语言 继承这件事还有第二层坑：往上一级到底是哪一级，不是按代码字面截断的。 ## 有一张显式的父级映射表，覆盖了直觉 按字面直觉，en_AU往上一级应该是en。实际上这份数据里有一张显式的映射表，把八十多个英语地区变体的父级统一指向了en_001，也就是国际英语。 en和en_001的差别不小，日期顺序、部分拼写都不同。所以en_AU拿到的默认值不是美式的，是国际式的。这符合直觉的结果，但走的不是直觉的路径。 更绕的是第二层：en_DE、en_NL、en_SE这一批欧洲国家的英语，父级被指向en_150，也就是欧洲英语，而en_150的父级才是en_001。三级。 西班牙语同理，es_MX、es_AR这一批的父级是es_419拉美西语，不是es。 这张表在数据里是显式写出来的，不是靠代码推导。也就是说它可以随版本变化，而且确实变过。锁死版本再做判断，这一条在这里格外重要。 ## 有一批变体的父级被直接指向了最顶层 更值得注意的是另一批。sr_Latn、uz_Cyrl、az_Cyrl、ms_Arab、ha_Arab、pa_Arab、ug_Cyrl、mn_Mong这些带书写系统后缀的组合，父级被显式指向了最顶层的root。 意思是：塞尔维亚语的拉丁字母版本，不继承塞尔维亚语；乌兹别克语的西里尔版本，不继承乌兹别克语。它们跳过所有中间层，直接掉到最上面那份通用数据。 这个设计有它的道理——换了书写系统之后，排序规则、数字写法、断行规则可能全都不一样，继承过来反而是错的。但对配置的人来说，后果是：你写sr_Latn，实际拿到的是一份非常薄的通用数据。运行时具体按什么顺序往上找，写在ICU的资源回落文档 (https://unicode-org.github.io/icu/userguide/locale/resources.html)里。 做塞尔维亚语双文字站 (https://zhangwenbao.com/bulgarian-serbian-seo-cyrillic-latin-dual-script.html)的人对这条会有实感：两套字母在内容层是两套关键词，在格式数据层则是一套有本地数据、另一套掉到最顶层。 清单里那些组合有个共同点：书写系统换了之后，字符集、排序、断行几乎没有一样能沿用。与其继承一份错的，不如什么都不继承。 ## 葡萄牙语那一支的方向跟别人相反 葡萄牙语的地区变体里，pt_AO安哥拉、pt_MZ莫桑比克、pt_CV佛得角这一批的父级被指向了pt_PT，而不是pt。 连起来看就是：pt本身是巴西葡语，非洲那几个葡语国家跟着葡萄牙走，只有巴西自己跟着默认值走。 这个安排符合语言现实——非洲葡语国家的书面规范历史上跟着里斯本，跟巴西那一套不一样。但它在配置层面很容易配错。 如果你要做安哥拉市场，配pt和配pt_AO拿到的是两套不同的格式数据，而且差别不在两个字母上，在中间隔着的那一级上。 ## 繁体中文是这里面最反直觉的一条 zh_Hant的父级也在那张root清单里。也就是说，繁体中文不继承zh，直接到最顶层。 好在zh_Hant自己的文件有722KB，是全表最厚的之一，掉到root也不影响什么。但如果换成清单里那些薄的组合，后果就完全不同。 判断方法很简单：先看这个带后缀的组合自己的文件有多大。厚，说明它自食其力；薄，而且父级被指向root，那就是真的什么都没有。 这一条跟书写系统在地址层的选择 (https://zhangwenbao.com/minor-language-url-native-script-vs-latin-transliteration.html)是两件事，别混在一起决策：地址那边是可见性问题，这边是有没有数据的问题。 还有一个实用的判断法：看这个组合在不在那张父级映射表里。在表里的，父级不是你截断代码得到的那个；不在表里的，才是按字面往上一级。 ## 标注为未确认的那些格子，最后会被丢掉吗？ 除了继承标记，还有第三类看着有、其实没有的东西：草案状态。 ## 四个等级，只有两级会被发出去 每一格数据都可以带一个草案属性，取值从低到高是未确认、暂定、已贡献，不带这个属性表示已批准。生成发布数据的时候，未确认和暂定这两级会被剔掉。 所以一格数据在源文件里存在，不等于它会出现在你实际用到的那份数据里。这是继承标记之外的第二道过滤。 法语在这一版有1726格标着未确认，占总格数的21.6%。法语。这说明这件事跟语言大小没关系，跟这门语言最近有没有开过一轮大规模数据征集有关。 相比之下英语这一列是0，因为英语的数据是基准，不走投票流程。 这套等级的存在本身说明了一件事：这份数据是靠投票和审核维护的，不是靠一个权威机构发布的。所以它的质量分布必然不均匀，而不均匀的地方需要你自己去量。 ## 未确认的格子在页面上表现成什么样 未确认的格子会在生成发布数据时被剔掉，所以它的表现跟这一格从来没人填过完全一样：回落到上级语言的值。 这就造成一个很坑的现象：你去源文件里查，看到这一格有内容，是本地语言写的，于是判定没问题；上线之后页面上显示的却是英语。 后面那篇讲历法的文章里会有一个极端例子：某门语言的某套历法在源文件里确实有一条本地写法，但它标着未确认，所以实际发布出去的是一个英文缩写。 判据固化：在源文件里看到值，还要看它带不带草案属性，两步缺一不可。 ## 怎么查一门语言的草案状态 方法跟查继承标记一样，在文件里搜索草案属性，统计各个取值的出现次数。四个取值里只有未确认和暂定这两个会被丢掉。 要注意的是，同一个属性可以标在不同层级上：标在一个大区块上，整个区块都受影响；标在单个字段上，只影响那一格。统计的时候要分开数。 法语那1726个未确认里，相当一部分是集中在几个区块上的，不是散落在各处。这种形状说明是一次批量提交还没走完流程，不是长期问题。 散落型才麻烦。它意味着这些格子是不同的人在不同时间提交的，每一格都要单独走一遍流程，而且没有人负责推动。 ## 已贡献这一级容易被误读 已贡献这一级会被发出去，所以它不影响可用性。但它数量很大：繁体中文4687格、越南语2539格、马来语1430格、泰语1379格。 这些是有人提交了、还没走完批准流程的数据。它们能用，只是意味着这门语言正处在一轮数据更新中间，下一版可能会变。 做技术选型的时候，这一列的意义不是能不能用，而是稳不稳定。已贡献占比高的语言，两个版本之间的格式差异会比别的语言大。 把三种状态并排：继承标记是明确不填，未确认是填了不算，已贡献是填了算但还在动。三种都不是你以为的那个“有”。 做一个简单的对照就明白了：英语这一列是0，法语的未确认是1726，繁体中文的已贡献是4687。三个数字代表三种完全不同的状态，而它们在很多统计里会被合并成同一个“有数据”。 ## 这些东西在页面上会表现成什么样？ 到这里为止都是文件层的事。这一节把它翻译成用户实际会看到的东西。 ## 第一类：格式偏了，但页面完全正常 最常见的表现是价格和日期的写法不对。小数点该用逗号的地方用了点，千分位该用空格的地方用了逗号。 这类问题不报错、不影响布局、截图看不出来，除非有人真的懂那门语言并且盯着数字看。它通常是被本地客服转述用户抱怨的形式发现的，而客服往往会转述成“价格显示有点怪”。 更麻烦的一种是数字被理解错。1,234在有些语言里读作一千二百三十四，在有些语言里读作一点二三四。差一千倍。 这一条跟工具返回零数据那件事 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)是同一类毛病：系统正常返回了一个值，而那个值的口径不是你以为的口径。 这类问题最好的发现办法不是检查，是让本地同事在真实页面上下一单。走一遍完整流程，价格出现在购物车、结算页、确认邮件三个地方，只要有一处写法不对就会被注意到。 ## 第二类：单位和连接词以英语形式混在句子里 商品规格里写重量，系统按单位模板渲染，模板是借来的，于是本地语言的句子里出现了英语的单位说法。 并列连接同理。三个属性并排展示，中间的连接词按模板拼，模板是借来的，出来就是英语的逗号加and。 这类问题视觉上很显眼，一眼能看出来，反而不容易漏。真正会漏的是它出现在筛选器、面包屑这些没人逐字检查的地方。 还有一种更隐蔽的：这些拼出来的字符串会进标题和描述，而锚文本和标题的一致性检查 (https://zhangwenbao.com/minor-language-internal-link-anchor-inflection-variants.html)不会把它们当成异常，因为从字符层面看它们没错。 顺带提一句，这类拼接出来的字符串还会进入商品结构化数据。地名那种一名两写的问题 (https://zhangwenbao.com/minor-language-place-name-endonym-exonym-search.html)是内容层的，这个是渲染层的，但它们最后落到同一个字段里。 ## 第四类：搜索结果和列表的顺序不对 排序规则也住在这一层。一门语言的字母顺序、变音符号怎么参与比较、大小写怎么折叠，都是区域数据的一部分。 这一格借来之后，站内搜索的结果顺序、商品列表的字母排序、下拉选项的排列，全部按英语规则来。用户会觉得列表是乱的，但说不出哪里乱。 这类问题的排查成本比前三类都高，因为它没有一个可以指着说错了的点，只有一种整体上不对劲的感觉。 好在排序这一格的借用率通常比单位和引号低，因为它属于覆盖等级 (https://cldr.unicode.org/index/cldr-spec/coverage-levels)评定的必查项，做到基本档就得填。大小写折叠在土耳其语上出的那类事 (https://zhangwenbao.com/minor-language-case-folding-lowercase-turkish-dotless-i.html)，根子也在这一格。 ## 第三类：引号和标点掉成方框 引号那一格借来之后，页面上出现的是英语那对弯引号。如果这门语言的网页字体子集是按本地字符集裁的，这两个符号可能不在里面。 结果是用户看到两个方框。这个现象最容易被误诊成字体加载失败，然后有人花两天去查字体文件，而根子在几千公里外的一格区域数据上。 排查顺序应该反过来：先看那个符号是什么码位，再看它是谁决定的，最后才看字体有没有它。 说句题外话，保哥见过一次这样的排查，三个人查了一周，最后是一个做本地化的实习生随口说了一句“我们的语言不用这种引号”，才把方向掰回来。 这一类还有个变种：并非掉成方框，而是字体里有这个符号但形状不对。西里尔和拉丁共用码位的那些标点尤其容易出这种事，视觉上只差一点点，本地人一眼看得出。 ## 上线前怎么用二十分钟查一遍？ 这一节是可执行的部分。不需要读整份规范，四步就够。 ## 第一步：确认你实际配的是哪个代码 先把配置里那串语言代码找出来，注意它可能出现在三个地方：页面的语言属性、后端的区域设置、以及某些前端库自己的配置项。三处不一致很常见。 然后判断这个代码带不带地区或书写系统后缀。不带的，直接查那门语言；带的，进第二步。 选代码的原则在官方那份选代码指引 (https://cldr.unicode.org/index/cldr-spec/picking-the-right-language-code)里写得很清楚，核心是别写多余的子标签。多写一层不会让数据更准，只会多一层回落。 顺带一提，语言标签本身的合法写法由RFC 5646 (https://www.rfc-editor.org/rfc/rfc5646)规定，这一步别自己发明写法。 三处不一致的时候，以后端那一处为准去查数据，因为格式化通常发生在后端或者服务端渲染阶段。页面属性那一处影响的是别的东西。 ## 第二步：查那个带后缀的文件有多大 去公共仓库里找到对应的文件，看字节数。小于1500字节的，说明它是空壳，你实际拿到的是上一级的数据。 这时候要做的不是换代码，而是确认上一级是不是你想要的。参照前面那张表，默认值经常不是使用人数最多的那个地区。 大于100KB的，说明这个地区确实有一套自己的数据，配上它是对的。 中间那一档，几KB到几十KB，说明只有少数字段不同。这一档最需要打开看一眼具体是哪几个字段，因为差异可能正好落在你用得上的地方，也可能完全无关。 字节数只是个粗筛，准确的做法是数字段数。但对上线前的快速判断来说，字节数够用了，因为空壳和有内容之间差了两个数量级，不存在误判空间。 ## 第三步：数一遍那门语言的继承标记 打开那门语言的主文件，搜索三个向上箭头这个符号，数出现次数，除以总的字段数。 超过三成，说明这门语言的格式层很大一块是英语默认值，价格、单位、引号都要人工验一遍。低于一成，基本可以放心用默认渲染。 更精细一点，可以只看三块：单位、数字、引号。这三块跟商品页直接相关，其他块可以先放着。 这一步花不了五分钟，但它决定了你要不要在排期里加一项人工校验。 如果你要给多门语言做这件事，把这三步写成一个脚本比手工快得多。输入是语言代码清单，输出是三列数字，跑一次十几分钟。 ## 这四步查不出来的两件事 第一件是你的技术栈实际用的是哪一版区域数据。运行时的版本可能比你查的那一版老好几年，中间的补充全都用不上。查依赖树里那个库的版本号，比查数据本身更重要。 第二件是你的框架有没有自己覆盖过这些值。不少前端框架带一份精简的内置数据，只挑常用的几十个语言版本，而且精简的口径不公开。 这两件事都得在自己的项目里查，没有公共答案。查完公共数据只解决了一半，另一半在你的依赖里。 实操上的顺序是：先查公共数据判断这门语言值不值得信默认渲染，再查依赖确认你实际拿到的是不是那一版。 ## 第四步：把结论写成一句话 最后把三步的结果合成一句：这门语言的格式数据里有多少是它自己的，我配的那个代码会落到哪一级，以及哪几类页面元素需要人工验。 这句话应该跟着语言进排期表，跟词典能力、字体能力并列。它们分属不同的层，但都是上线前该有答案的。 需要提醒的是，这一层的结论不该影响选哪门语言的顺序。它影响的是选定之后要预留多少工时。 把两件事混在一起判断，很容易得出因为数据不全就不做这门语言的错误结论，而实际上这里的缺口大多是几十个工时能补的。 这句话还有一个用处：它是跟供应商谈判时的筹码。对方说支持一百多种语言的时候，你可以问其中有多少门的格式数据自有率超过九成。这个问题多数供应商答不上来。 ## 哪些相邻的问题不归这一层管？ 这一层很容易跟旁边几层混起来，划一下界。 ## 词典和分词是另一份资源 站内搜索召回不好、拼写纠错不灵，根子在词典和词法资源上，跟本篇讲的格式数据是两套完全独立的文件，由完全不同的人维护。 两者的成色经常不一致：格式数据完整的语言，词典可能停更十年；反过来也有。查一层的结论不能推另一层。 判断方法也不同。格式数据看字段数和继承标记，词典看最后更新时间和词条数。 这两层唯一的共同点是，它们都不在你的代码库里，都是借来的。 实际操作上建议把两层的查询结果并排放在一张表里，各占一列。不一致的那几行是最值得看的，它们说明这门语言的支持是偏科的，而偏在哪一科决定了你该补什么。 ## 翻译质量不在这一层 页面上的文案读着别扭、语气不对、用词不地道，属于翻译质量问题，跟格式数据无关。哪怕格式数据100%自有，文案照样可能是机器翻译直接发上线 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)的。 反过来，文案由母语者精心打磨过的站，格式层照样可能整块借着英语。这两件事在流程上完全不相交。 区分方法很简单：看这段字符是你的团队写进内容库的，还是系统渲染出来的。前者归翻译，后者归本篇这一层。 大多数验收流程只覆盖前者，这就是后者长期没人管的原因。 有一个简单的分界问题可以帮你判断：如果把这门语言换成英语，这个问题还在不在？在，就是格式层；不在，多半是翻译层。 ## 字体和渲染是再往下一层 这一层决定用哪个符号，字体那一层决定这个符号画不画得出来。两层都对了才有正确的显示。 顺序上先查这一层：确认系统会输出哪个码位，再去看字体子集里有没有它。反过来查会绕远路，因为字体缺字的表现和数据借错的表现在屏幕上是一样的，都是不对劲。 这两层的负责人通常也不是同一批人。数据这一层归本地化或者后端，字体那一层归前端。中间那道缝就是问题最容易掉进去的地方。 把这句话写进排查手册的第一行会省很多时间：先问这个字符是谁决定的，再问它为什么画不出来。 ## 搜索引擎那一侧是另一套账 这一层的数据决定的是浏览器和服务端怎么渲染，不决定搜索引擎怎么理解你的页面。引擎有自己的一套语言识别和格式解析。 所以格式数据不全不会直接导致排名问题。它导致的是转化问题——用户看到一个写法奇怪的价格，会犹豫。 真正跟收录相关的是页面上声明的语言代码有没有写对，而那是另一套规则。 把这两件事分开的好处是，排查的时候不会把一个转化问题当成排名问题来治。 还有一层也不归这里管：内容本身的组织方式，比如同一门语言在两个市场该不该拆成两套落地页。那是意图分叉那一类的问题 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)，跟数据文件无关。 ## 常见问题解答 ## 怎么快速知道一门语言的格式数据是不是借的？ 打开公共仓库里这门语言的主文件，搜索三个向上箭头这个符号，数出现次数，再除以总字段数。这个比值就是借来的比例。超过三成要人工验价格、单位和引号这三样，低于一成可以直接用默认渲染。注意这个数只有2019年10月及之后的版本才有意义，更早的版本里借来的和没人填的写在一起，分不出来。如果你只想花两分钟，就只看单位、数字、引号这三块，它们跟商品页直接相关。 ## 文件是空的，是不是说明这门语言没做本地化？ 正好相反的情况更常见。带地区后缀的文件为空，通常说明这个地区的写法跟语言默认值完全一致，不需要重复写一遍。全部551个带后缀的变体里有427个是空壳，而208个纯语言代码里空壳数量是0。判断的时候不要看那个空文件，要去看它上一级是谁、上一级有没有数据。真正要担心的是另一种情况：带书写系统后缀的组合，自己是空壳，而父级又被显式指向了最顶层。 ## 我该配带地区的代码还是不带的？ 先查那个带地区的文件有没有实际内容。有几百KB的，配上它；只有几百字节的空壳，配不配都一样，那就选短的那个，少一层回落少一个出错的地方。中间那一档要打开看差异落在哪几个字段上。另外记住默认值经常不是你以为的那个地区：葡萄牙语的默认是巴西，繁体中文的默认是台湾，斯瓦希里语的默认是坦桑尼亚。配错了页面不会报错，只是格式站到了另一边。 ## 为什么翻译审校查不出这类问题？ 因为审校看的是你交给他的文案，而这些东西不在文案里，是系统渲染的时候临时拼出来的。引号、单位说法、并列连接词、日期顺序，这四样都不会出现在任何一份待审稿件上。要覆盖它们，得在验收清单里单独加一条：让母语者看渲染后的真实页面，重点看数字、日期和标点，而不是看文档。这一条加上之后，绝大多数这类问题在上线前一小时就能发现。 ## 已贡献状态的数据能用吗？ 能用，它会进发布数据。真正会被剔掉的是未确认和暂定这两级。已贡献这一列的意义不在于能不能用，而在于稳不稳定：这个数字大，说明这门语言正处在一轮数据更新的中途，下一个版本的格式可能会跟这一版不一样。繁体中文、越南语、马来语、泰语这一版的已贡献量都很大。如果你的站有大量缓存好的格式化字符串，升级依赖库的时候要留意这几门语言。 ## 这些问题值得花多少工时？ 查的部分很便宜，一门语言二十分钟，十门语言半天能查完。补的部分要看缺在哪：单位和引号这类是配置层的事，写死在你自己的模板里几个小时就能解决；数字和日期格式要谨慎，因为改错了比借着英语还糟。保哥的建议是先查全，再只补那些直接出现在价格和规格上的，其余的记在文档里，等有人反馈再动。 ## 为什么同一门语言不同工具查出来的字段数不一样？ 大概率是版本不同，或者一个查的是原始文件、另一个查的是解析之后的发布数据。发布数据里继承标记已经被替换成实际值，未确认的格子已经被剔掉，所以两个数不可能一样。做对比的时候必须锁死是哪一版、哪一种形态。这跟看语言能力的其他指标一样，口径比数值重要。 ## 同一座城市在你的两个市场里是两个不同的词，而配送页的标题只能写一个 - URL：https://zhangwenbao.com/minor-language-place-name-endonym-exonym-search.html - 分类：小语种SEO - 发布：2019-11-13 | 更新：2026-07-29 - 摘要：外来地名不是本地名的音译，是各语言独立形成的词，脚本一个也推不出来。讲清联合国推了半个世纪为什么没能削减它、哪些页面会被咬到、结构化数据该填哪一个，以及优先级怎么用日志定。 - 关键词：国际化SEO,多语言SEO,内容本地化,小语种SEO > **TLDR**：摘要：你的配送页上写着慕尼黑，德国用户搜的是München，意大利用户搜的是Monaco di Baviera，捷克用户搜的是Mnichov。这几个词不是彼此的音译，是各自语言独立造出来的名字，谁都不比谁更正确。联合国从1972年起就要求各国编制并削减外来地名清单，五十年过去清单没短反而更长，因为地名标准化管得住地图，管不住用户嘴里那个词。 本文讲清楚本地名与外来名的分界、一个地名会长出几种形态、哪些页面会被它咬到、屈折语里还要再乘一次变格，以及地名字段该怎么在CLDR、结构化数据和自建别名表之间分工。 > 摘要：你的配送页上写着慕尼黑，德国用户搜的是München，意大利用户搜的是Monaco di Baviera，捷克用户搜的是Mnichov。这几个词不是彼此的音译，是各自语言独立造出来的名字，谁都不比谁更正确。联合国从1972年起就要求各国编制并削减外来地名清单，五十年过去清单没短反而更长，因为地名标准化管得住地图，管不住用户嘴里那个词。 本文讲清楚本地名与外来名的分界、一个地名会长出几种形态、哪些页面会被它咬到、屈折语里还要再乘一次变格，以及地名字段该怎么在CLDR、结构化数据和自建别名表之间分工。 ## 你写的那座城市和用户搜的那座城市，不是同一个词 ## 一次配送页的实测 有个做户外家具的客户，德国站做得挺认真，配送说明里逐条列了主要城市的时效。 页面上写的是Munich、Cologne、Nuremberg，一水儿的英文名。原因也不难猜：这套内容是从英文站翻过去的，译者动了正文，没动地名。 德国用户搜的当然是München、Köln、Nürnberg。这三组词之间没有任何一个共同的字符片段能让搜索引擎把它们对上。 更麻烦的是，这个站还做了意大利和捷克两个市场，用的是同一份配送模板，同样一水儿英文名。 意大利人管慕尼黑叫Monaco di Baviera，捷克人叫Mnichov。这两个词跟München之间没有任何拼写上的联系，它们不是从德语音译过去的，是各自语言在几百年里独立形成的名字。于是三个市场的配送页，同时对三批用户都是隐形的。 这件事最让人不舒服的地方在于，它不像那些技术问题会报错。页面正常、翻译正常、结构化数据正常，没有任何一个工具会亮红灯，只有一批本该进来的搜索安安静静地没进来。 后来我们把那份配送表里的城市名换成德语写法，其他一个字没动。这类改动的特点是没有中间态，要么完全对不上，要么一次性对上，所以变化来得比大多数优化动作都干脆。 这个客户后来跟我说了一句挺在理的话：他们花了半年打磨配送时效，把从四天缩到两天，却从来没人问过一句，找得到这个页面的人到底是谁。 ## 这不是翻译没做好 你可能会说，那让译者把地名也翻了不就完了。 问题是地名不走翻译流程。翻译记忆库里通常把专有名词设成不译，这是为了保护品牌名和型号，而地名恰好也被这条规则罩住了。 更根本的是，地名不是翻译出来的，是各语言自己有一套。译者要做的不是翻译，是查表替换，这是两种不同性质的操作。 翻译讲究忠实于原文，查表替换讲究忠实于目标语言的既有说法，后者根本不看原文长什么样。 我在小语种关键词表里那些没人搜的词 (https://zhangwenbao.com/keyword-literal-translation-legacy-cost-non-english.html)里讲过直译遗产，那件事至少还有一个词可以译。地名这件事更彻底：原文里那个词跟目标语言里该用的词之间，没有任何可以推导的关系，只能靠一份对照表。 还有一个结构性原因：地名在多数内容管理系统里根本不是文本，是从一份地区表里读出来的枚举值。译者在稿子里看不到它，他看到的是一个占位符。 还有一种情况更隐蔽：内容管理系统里的地区表是全局共享的，一改会影响所有语言版本。于是负责德语站的人不敢动它，因为他不知道改了之后意大利站会变成什么样。 ## 三个名字可以同时正确 习惯了做规范化的人，第一反应往往是问哪个才是对的。 这个问题在地名上没有答案。慕尼黑这座城市的官方名字只有一个München，这一点毫无争议。 但意大利语里正确的说法就是Monaco di Baviera，它在意大利的教科书、地图、新闻里都是这么写的，它不是一个错误的写法，它是意大利语的正确写法。 所以正确这个词在这里必须带上限定语：在哪门语言里正确。脱离语言谈地名的对错，是无解的。 这跟做品牌名规范的思路正好相反。品牌名是你的私产，你可以规定全世界都写同一串字符；地名是公共财产，每门语言各自持有一份使用权，你只能跟着用，改不动。 顺着这个思路还能推一步：既然正确要看在哪门语言里，那你的地名字段就必须带语言标签。一个不带语言标签的地名字段，本质上是在假设全世界只有一门语言。 所以我一般建议团队在内部把这件事的说法统一成：这座城市有几个名字，分别属于哪门语言。而不是问哪个名字是对的，后面这个问法本身就把讨论引到了没有答案的方向上。 ## 本地名和外来名的分界线在哪儿？ ## 联合国给过一份定义 这套术语不是学界随便起的，联合国地名专家组编过一份术语表，把它们写得很清楚。 本地名指的是这个地方在当地官方语言里的名字，比如München。外来名指的是另一门语言给它起的、跟本地名不同的名字，比如Munich。 判据是差异，不是来源。如果另一门语言原样照抄了本地名，那就不算外来名，只是同一个名字被借用。 所以Berlin在英语里不是外来名，因为它跟德语写法一模一样；而Cologne是外来名，因为它跟Köln明显不同。 这条分界线对我们做搜索的人特别有用，它把地名一分为二：一半是零成本的，照搬就行；另一半必须逐个查表。你的工作量只落在后一半，而这一半通常只占主要城市的两三成，盘点起来并不吓人。 这套术语在联合国地名标准化术语表 (https://unstats.un.org/unsd/ungegn/pubs/Documents/Glossary_of_terms_rev.pdf)里有正式定义，值得花十分钟翻一遍。它给出的判据非常干脆：看名称跟当地官方形式有没有差异，有差异就是外来名，没差异就只是借用。 ## 转写不算外来名 这是最容易混淆的一处。 把Москва写成Moskva是转写，是把一套字母系统机械地映射到另一套；写成Moscow才是外来名，那是英语自己的词。 转写有规则，可以写成代码；外来名没有规则，只能查表。这是两件工程性质完全不同的事。 我在小语种URL用本地字母还是拉丁转写 (https://zhangwenbao.com/minor-language-url-native-script-vs-latin-transliteration.html)里讲的就是前者，那件事的核心是选一套规则并且从头到尾一致。 这篇讲的是后者。把这两件事混在一起处理，最典型的后果是有人写了一个自动转写模块，然后指望它把Köln转成Cologne——它永远转不出来，因为这两个词之间不存在任何字符级的对应关系，那是历史，不是算法。 还有一个实际后果：转写形态在搜索里的量通常很小，因为没有哪一群人的母语里天然就用这套写法。它主要活在护照、机票、快递单这些跨系统传递的场景里。 ## 还有历史名、并行名和少数民族语言名 实际的地名数据比两分法复杂。 历史名是这个地方以前叫过、现在不再是官方名字的说法。它在搜索里仍然活着，尤其在年长用户和历史内容里。 并行名指的是同一个地方在两门官方语言里各有一个名字，比利时和瑞士到处都是这种情况。 爱沙尼亚语言研究所的地名数据库把这些状态做成了字段：主名、并行名、名称变体、历史记录，每条记录还带语言代码。 这个数据结构值得抄。它告诉你一件事：地名不是一个字符串字段，是一张带语言标签和状态标签的关系表。你的商品数据库里如果只给城市留了一个varchar字段，那从一开始就装不下这件事。 历史名还有一个特殊用途：它是判断内容受众年龄的旁证。如果你的日志里历史名的查询占比明显偏高，说明这批用户的年龄结构偏大，这条信息对选品和文案语气都有参考价值。 并行名还有一个容易踩的坑：两个名字在当地是有政治敏感度的，选哪个显示、以什么顺序显示，有时候不只是语言问题。这类地方最好按当地惯例来，别自己发明排序规则。 ## 联合国推了五十年，为什么外来名一个都没少？ ## 1972年那份决议是怎么写的 第二届联合国地名标准化会议通过了一项决议，请各国编制本国常用的外来地名清单，目的是逐步取消其中的一部分。 方向很明确：国际交流里应该尽量使用本地名，外来名越少越好。 这个出发点没错。地图上的一个地方对应两三个名字，对救灾、航运、邮政都是实打实的麻烦。 后续几十年里，专家组还开过专门的外来名工作组，出过好几份使用准则和判据文件。 换句话说，这是一场持续了半个世纪、有国际组织牵头、有各国测绘机构参与、有正式决议背书的标准化努力。以我们做技术的人的直觉，这么大的力气砸下去，问题早该收敛了。 值得注意的是，这份决议诞生的年代还没有搜索引擎。当时地名不统一的代价体现在邮件寄丢、航班标错、救灾队伍找错地方，而不是体现在一个页面能不能被找到。 ## 五十年后清单反而更长 现实是外来名一个都没消失。英国人还在说Munich，意大利人还在说Monaco di Baviera。 甚至后来的工作组文件本身也把口径松了下来，从减少改成了讨论在什么条件下使用外来名是合适的。 原因不复杂：外来名不是行政机构发明的，它是自然语言的一部分，跟这门语言的词汇一起长出来的。 你可以规定官方地图上印什么，规定不了一个人跟朋友说话时用哪个词，更规定不了他在搜索框里打什么。 这件事对我们的启发比对地图学界的更大：存在一个官方标准，不等于用户会按标准输入。半个世纪的国际标准化努力都没能改掉人们嘴里的那个词，你那份内部命名规范凭什么能？ 专家组后来专门设了一个外来名工作组 (https://unstats.un.org/unsd/geoinfo/ungegn/wg8.html)，从工作文件的措辞变化能清楚看到口径的软化：早期讨论的是怎么减少，后来讨论的是在什么场景下使用是合适的。 这条演化线索对我们有个直接用处：既然连专门做这件事的国际组织都放弃了统一，那内部再有人提议全站只用一种写法时，你就有了一个现成的例子可以引。 ## 标准化管得住地图，管不住搜索框 这就把地名分成了两个世界。 一个是行政世界：地图、邮政编码、海关申报、法律文书，这里用本地名或者官方转写，规则清晰。 另一个是用户世界：搜索框、口头交流、社交媒体、客服对话，这里用的是他母语里最顺口的那个词。 你的网站很不幸地同时站在两个世界里。结账地址字段属于前者，配送页标题属于后者。 把两个世界的规则搞混，就会出现这种局面：面向用户的标题用了严谨的本地名，用户搜不到；而地址库里存的是用户随手打的外来名，海关那边对不上。两头都不讨好，而且两个错误的方向正好相反。 这条规律不只适用于地名。凡是标准由机构制定、使用由个人决定的东西，标准都只能约束到机构自己能管到的那一段，剩下的部分你只能观察和适配。 ## 一个地名到底会长出几种形态？ ## 先把清单列全 做这件事之前，得先知道自己要装多少种东西。 第一种是本地名，当地官方语言里的写法，比如München。 第二种是目标市场语言里的外来名，比如英语的Munich、意大利语的Monaco di Baviera。 第三种是转写形态，从非拉丁字母系统机械映射过来的，比如Москва转成Moskva。 第四种是历史名与旧称，比如今天的城市在几十年前叫过另一个名字，这批词在年长用户和历史类查询里还有量。第五种是俗称和缩写，纽约的NYC、慕尼黑的Minga这种，前者进搜索量极大，后者只在本地人之间流通。 这五种形态不必都做，但必须都知道。漏掉哪一种是决策，没意识到还有那一种是事故，两者的区别在于前者你至少知道自己丢了什么。 ## 屈折语里还要再乘一次 如果目标市场说的是波兰语、俄语、芬兰语这类语言，上面每一种形态都还要再乘上变格。 华沙在波兰语里是Warszawa，但用户搜发往华沙的配送时，句子里出现的是do Warszawy；说在华沙有门店时是w Warszawie。 三种形态里，词典形只占一种，而用户的实际查询大量落在另外两种上。 芬兰语更狠，位置格有六个，每一个都能出现在真实查询里。 这一层在如果波兰语SEO只按词典原形选词 (https://zhangwenbao.com/polish-seo-seven-cases-diacritics-keyword-research.html)和芬兰语SEO的十五个格只是开胃菜 (https://zhangwenbao.com/finnish-seo-fifteen-cases-consonant-gradation-keyword.html)两篇里讲的是普通名词，地名的处理完全一样，唯一的区别是地名的变格更没法靠词干还原兜住，因为词干还原器的词典里往往没收全地名。 这里有个反直觉的地方：变格反而让地名比普通名词更难处理。普通名词的词干还原器有词典兜底，而地名往往不在词典里，还原器会把它当作未知词原样输出。 还有一个特殊情况：有些城市名在语法上被当作复数或者带冠词，变格规则跟普通地名不一样。这类词数量不多，但常常正好是首都或者大城市，也就是量最大的那几个。 ## 俗称和缩写要不要收 要收，但要分开放。 缩写型俗称的搜索量常常大得出人意料，尤其是大城市和机场代码。 本地俚语型的俗称则要谨慎，它带着强烈的圈内人色彩，品牌用不好会显得刻意。 我的做法是：俗称收进匹配层和站内搜索的同义词表，但不写进标题和正文。 这条界线其实适用于所有非官方形态：能被搜到就行，不必非要显示出来。匹配层和展示层是两件事，混在一起的结果通常是页面上堆了一串别名，读着像关键词填充，用户看着糊涂，搜索引擎也不见得领情。 机场代码是个例外，值得单独收进展示层。它短、无歧义、在旅行相关品类里的搜索量极大，而且用户就是拿它当城市名在用的。 ## 用户到底会搜哪一个名字？ ## 本国用户：几乎只用本地名 德国人搜德国城市，用的一定是München。这一点没有悬念。 唯一的变数是变音符号打不打，这属于另一个问题，德语SEO最先卡住的不是技术 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)那篇里讲过Muenchen这种替代写法要不要覆盖。 所以做本国市场的地区页，本地名是唯一答案，不用纠结。 要留意的是本国用户里的外来人口，他们可能用自己母语的外来名去搜，尤其是刚落地不久的。 这批人在跨境电商里的价值往往比人数占比高得多，因为他们更习惯网购、更少受本地零售渠道覆盖。判断要不要为他们单独铺一层内容，看你的品类跟这批人群的重合度，而不是看他们在总人口里占几个百分点。 还有一种本国场景要留意：官方名刚刚改过的地方。改名之后的头几年，旧名字的搜索量会明显高于新名字，而你的数据源多半已经更新成新名字了。 ## 外国用户：几乎只用自己语言的外来名 反过来也一样。一个意大利买家搜德国某座城市的时候，脑子里蹦出来的是Monaco di Baviera。 他不会先在心里把它换算成德语。事实上他大概率根本不知道德语原名长什么样。 这就是为什么面向外国市场的页面必须用外来名：那是用户唯一认得的词。 而这恰恰是最容易做反的地方，因为团队里总有人觉得用本地名更专业、更尊重当地。 这里有个很实际的折中：标题和描述里用外来名，正文第一次出现时用外来名加括号带上本地名。既接住了搜索，又给了想核对的用户一个锚点，还顺手把两种写法都放进了页面。 这里有个常见的误判：团队里懂那门语言的人往往就是本地人，他的直觉是本地名，于是他会真诚地建议你用本地名。他没有错，他只是不在目标受众里。 还有一个可以立刻检查的地方：你的多语言站点切换器上写的城市名是哪一套。那个组件通常是最早做、最少改的，很可能还停留在最初那份英文列表上。 ## 侨民与跨境买家：两个词都用 还有一批人处在中间地带。 比如住在德国的意大利人，找意大利食品的时候可能用意大利语搜，但城市名会用德语的。 这种混搭很常见，也很难靠规则预测。 好在它不需要你猜，站内搜索日志里能直接看到。 这批混搭查询是判断一个市场要不要单独铺内容的好信号：如果某个城市的两种写法在你的日志里都有可观的量，说明你的用户结构本身就是混的，那两种写法都得在页面上有落点，而不是二选一。 这类混搭还有个规律：品类词跟着母语走，地名跟着居住地走。因为品类是他从小就会说的词，而这座城市是他搬来之后才学会怎么念的。 ## 怎么用数据判断，而不是靠感觉 最直接的办法是拿两个写法各自去查搜索量，比大小。 但小语种的工具数据往往不可靠，小语种关键词工具返回的那个零是数据缺口 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)里讲过这个坑。 更稳的替代品有三个：站内搜索日志、搜索建议里出现的是哪个写法、以及本地媒体和本地竞品页面上用的是哪个写法。 第三个尤其好用，因为本地媒体没有动机去迁就任何标准，他们只写读者认得的词。 把这三个信号放在一起，结论通常非常清楚，甚至清楚到不需要争论。真正会吵起来的情况只有一种：两个写法量差不多。这时候别选，两个都上，一个进标题一个进正文，成本也就多一行字。 还有一个几乎零成本的信号源：本地的天气预报和交通播报页面。这类内容面向的是最广泛的本地受众，用词保守到接近默认值，拿它当基准非常合适。 另外提醒一句，看竞品的时候要看本土竞品，不要看同样是外来者的那几家。外来者之间常常在互相抄同一份错误的城市列表，你抄他他抄你，最后所有人都写着同一批用户看不懂的名字。 ## 哪些页面会被地名这件事咬到？ ## 配送与运费页 这是重灾区，因为它天然要列一堆城市名。 而且这类页面的查询意图极强：用户搜发往某某城市要几天，是准备下单了。 这类页面还有个特点，它经常是全站唯一提到那些城市名的地方，所以一旦写错形态，整个城市维度的流量就全丢了，没有别的页面能兜住。 做法上建议把城市列表做成结构化的数据，而不是硬编码在一段文案里，这样换形态、加别名都只需要改数据。 顺带一提，配送时效表这种内容天生适合做成表格，而表格里的城市名列如果同时放本地名和目标语言外来名两列，等于免费获得了一份对照表，用户看着也踏实。 配送页还有一个容易忽略的角落：运费计算器里的城市下拉列表。那份列表的取值往往来自物流商接口，用的是官方名或者英文名，跟页面正文用的词经常不是一套。 配送页上还有个隐蔽位置容易被漏掉：结构化标注里的服务区域字段。那里的取值如果跟正文用词不一致，机器读到的服务范围跟用户读到的就不是同一份。 ## 门店、服务范围与本地落地页 有实体网点或者按区域服务的生意，这一层的地名密度最高。 这里要提醒一句边界：门店在地图上的排名、评价管理、本地商户信息那一套，属于本地搜索的活儿，不在语言层这篇的范围里。 语言层要管的只有一件事：你的页面标题和正文里那个城市名，是不是用户会打出来的那个词。 两件事经常被混着讨论，结果是本地SEO顾问在优化地图信息，而页面标题里那个词从头到尾都是错的，谁也没管。 分工可以很简单：地图和商户资料交给本地搜索那条线，页面上出现的每一个地名形态交给语言层这条线，两边共用同一份别名表。 共用一份别名表这件事有个前提：这份表得有明确的归属人。散落在几个部门各自维护的地名表，用不了半年就会各自漂移，到时候连哪份是对的都说不清。 ## 地区落地页的批量生成 很多站会按城市批量生成落地页，模板一套，城市名一换。 这个做法本身没问题，问题在于变量取值。如果你的城市列表是从英文数据源拉的，生成出来的就是一整批带外来名的页面。 更糟的是这类页面往往几百上千个，错了是成批错。 而且模板生成的页面本来就在重复内容的边缘，再加上地名形态不对，双重问题叠在一起，很容易整批表现不佳却查不出原因。 批量生成之前先把城市表校一遍，这个动作花的时间远比事后逐页修改少。校的办法也很土：把列表丢给本地同事，让他标出哪些看着别扭，一般十分钟就能圈出问题项。 批量生成还有一个隐患：模板里的城市名往往同时出现在标题、正文、面包屑和URL里。地名一旦取错，这四处会一起错，而URL错了之后改动的代价最大。 批量生成还有一个补救办法：先只生成流量最大的二十个城市页，跑一个月看数据，再决定要不要铺开。这样即使地名形态选错了，返工范围也只有二十页。 ## 地址表单与结账流程 这里的规则跟前面完全相反：表单要的是能对上物流和海关的那个形态。 用户在城市栏里打什么都可能，你需要的是能把它归一到官方名的能力。 做法是给输入框配自动补全，用一份带别名的地名数据源做后端匹配，用户打外来名也能选中正确的条目。 这一层跟展示层的目标不同：展示层要迎合用户的词，数据层要收敛到唯一值。 把这两件事分清楚，你的地名工作就成功了一半。剩下的一半是别让它们互相污染——展示层的别名不能写进订单数据，数据层的官方名也不该原样搬到面向用户的标题里。 自动补全的数据源建议直接用公开地名库的别名字段，别自己手工维护。公开地名库提供整包下载 (https://download.geonames.org/export/dump/)，里面每个地点都挂着一张多语言别名表，导进来做后端匹配足够用了。 ## 地名进了屈折语，还会再变一次形吗？ ## 波兰语：介词决定用哪个词尾 华沙的词典形是Warszawa，但它几乎不会以这个形态出现在真实句子里。 发往华沙是do Warszawy，在华沙是w Warszawie，从华沙出发是z Warszawy。 用户搜配送信息的时候，打的往往就是带介词的那个片段，因为那是他脑子里那句话的样子。 你的页面上如果只有词典形，字符串就对不上。 处理办法跟普通名词一致：标题里保留词典形当锚，正文里自然地把常见的两三个变格形态用进句子里。不必穷举，波兰语地名的高频组合就是介词加位置格那几种，覆盖它们能接住绝大部分查询。 一个实用的小技巧：把常见介词加地名的组合直接丢进搜索框看补全建议，出现在建议里的那几种就是高频形态，不用去啃语法书。 ## 芬兰语：位置格有六个，地名还带自己的例外 芬兰语的地名要额外小心，因为它有一条外人很难预料的规则：不同城市用的位置格不一样。 有些城市用内部格，有些用外部格，这件事没有规律可循，是约定俗成的。 本地人从来不会搞错，外来的内容团队百分之百会搞错。 而且这个错误特别刺眼，芬兰读者一眼就能看出这段内容不是本地人写的。 这类问题没有技术解，只有流程解：地名相关的句子必须走母语审校，而且审校简报里要专门点出这一项，否则审校也可能把注意力全放在措辞上，顺手就放过了。 这类问题还有个副作用是它会连累品牌观感。用户读到一句语法别扭的本地话，第一反应不是这家公司不懂语法，而是这家公司不在本地，后面的信任成本都要跟着涨。 顺带说一句，这类语法细节最好整理成审校清单里的具体条目，而不是笼统地写一句请注意地名用法。清单越具体，审校漏掉的概率越低。 ## 标题该写哪一个形态 我的建议是标题写词典形，正文承担变格形态。 理由有两条。词典形是这个城市的规范名，放标题里最稳妥，也最容易被各种匹配逻辑对上。 变格形态数量多且分散，硬塞进标题会把标题写得很别扭，而标题的可读性直接影响点击。 正文则没有这个限制，它可以自然地把几种形态铺开，而且读起来更像本地人写的。 这条分工跟我在屈折语站的锚文本报告 (https://zhangwenbao.com/minor-language-internal-link-anchor-inflection-variants.html)里给锚文本定的规则是一致的：锚点位置守规范形，正文位置放自然形态。地名只是把同一条规则又用了一遍。 还有一个细节：面包屑和筛选器里的地名建议一律用词典形。这两处是导航元素，一致性比自然度更重要，读者在这里要的是快速定位而不是流畅阅读。 ## 地名字段在数据源里该按哪一套填？ ## 先看看现成的数据源提供了什么 你不需要自己造这份数据。 Unicode的本地化数据项目为每门语言维护了一份国家和地区名称的翻译，这份数据的存在本身就说明了问题：连国际标准组织都承认，同一个地方在每门语言里要各存一份名字。 更细一级的城市名，可以用公开的地名数据库，它们通常会给每个地点存一张别名表，每条别名带语言代码。 爱沙尼亚语言研究所那套外来地名数据库还额外标了名称状态，能区分主名、并行名、变体和历史记录。 把这几样组合起来，你能拿到一份相当完整的底表，剩下的工作是筛掉不需要的语言、补上自己业务相关的俗称。 这份数据的翻译指南 (https://cldr.unicode.org/translation/displaynames/countryregion-territory-names)里有一条很值得抄的原则：译名要采用目标语言里当地通行的说法，而不是从英文直译过来。这正是外来名的处理逻辑。 ## 结构化数据里填哪个 填官方名，也就是本地名。 结构化数据是给机器读的，它的作用是把你的页面跟一个确定的实体对上号，所以要的是规范值。 这跟正文用外来名并不冲突。正文迎合用户的词，标记指向唯一的实体，两条线各走各的。 这个原则我在国际化SEO最难的不是hreflang (https://zhangwenbao.com/multilingual-entity-seo-cross-lingual-reconciliation.html)里讲跨语言实体对齐时展开过，地名是那件事里最典型的一类实体。 如果你的标记体系支持给地点挂上外部标识符，那就挂上。有了唯一标识符，多语言之间的对齐就不再依赖字符串比对，这是所有跨语言实体问题里最省事的一条路。 如果同一个页面确实要覆盖多个地点，别把它们塞进一个字段里用顿号隔开。那样机器读到的是一个包含多个地名的字符串，等于哪个实体都没对上。 另外要注意标记里的地址字段和正文里的地址展示是两回事。前者服务于机器识别，后者服务于用户核对，两边完全可以写不同的形态，也确实应该写不同的形态。 ## 自建别名表要留哪几列 最少五列：唯一标识符、语言代码、名称写法、名称状态、是否可展示。 唯一标识符把所有写法拴在同一个地点上，这是整张表的骨架。 名称状态区分官方名、外来名、历史名、俗称。是否可展示决定它能不能出现在面向用户的文案里，俗称通常只匹配不展示。 加上变格形态的话，再多一列形态类型即可，不必为每个格单开一列。 这张表建完之后，配送页、落地页模板、站内搜索同义词、表单自动补全全都从它取值。这是它真正的价值所在：地名不再散落在几十个页面的硬编码文案里，而是收敛成了一个可以被审核、被复核、被一次性修正的数据源。 这张表还建议加一列来源，标明每条别名是从公开数据库来的还是团队自己补的。半年后复核时，这一列能让你迅速分清哪些可以跟着上游更新，哪些是自己的私货。 ## 这跟品牌名转写是同一件事吗？ ## 品牌名你能规定，地名规定不了 我在做小语种SEO，品牌名叫什么不由你定 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)里讲过一个结论：品牌名进了小语种市场会长出好几种写法，你要做的是挑一种作为官方写法，然后在站内保持一致、对外部持续纠偏。 那件事的前提是你拥有这个名字。你可以发一份品牌规范，可以要求经销商照着写，可以跟媒体沟通。 地名没有这个前提。你不拥有慕尼黑这个名字，谁都不拥有。 所以两件事的动作方向正好相反：品牌名是收敛，把多种写法收成一种；地名是发散，承认多种写法都对，然后按市场分别落地。 把地名当品牌名处理的团队，通常会做出一个很自洽也很没用的决定：全站统一用本地名，理由是尊重当地。结果是尊重了当地，丢掉了外地的搜索。 这个对比还能推广到别的字段：凡是你拥有的东西就收敛成一种写法，凡是公共的东西就承认多种写法并存。品牌名、型号、专有服务名属于前者，地名、品类通名、法规名称属于后者。 ## 外来名不是音译，这一点必须说清楚 品牌名进日语变成片假名，那是音译，音是能对上的。 Köln变成Cologne不是音译。这两个词的读音差得很远，它们是同一个源头在两门语言里各自演化了几百年的结果。 这个区别的实际后果是：音译可以靠规则批量生成并人工校准，外来名只能查表，一个都推不出来。 凡是有人跟你说写个脚本自动处理一下，你就知道他把这两件事搞混了。 唯一能自动处理的部分是转写，也就是字母系统之间的机械映射。而那部分恰好是最不容易出流量问题的部分，因为转写形态本来就很少有人拿去搜。 顺带一提，同一座城市在不同语言里的外来名之间也没有关系。意大利语的说法推不出捷克语的说法，它们各自是各自语言的历史产物，所以别指望做完一个市场能省下另一个的功夫。 这一点在做多市场排期时特别重要：地名工作量是按目标语言数量线性增长的，不会因为你已经做过几个市场而变便宜，做预算的时候别按经验值往下压。 ## 两件事的交付物完全不同 品牌名那件事的交付物是一份规范加一套监控：规定写法，然后盯着外部世界有没有写错。 地名这件事的交付物是一张多对多的别名表，加上一条按市场取值的规则。 前者的成功标志是外面的世界慢慢向你的写法靠拢，后者永远不会收敛，你只能一直维护那张表。 接受这一点很重要，否则你会不断想去统一它，而每一次统一都会牺牲掉一批市场的可见性。 说得更直白些：品牌名那件事有完成的一天，地名这件事没有。它是一项常设维护，跟商品目录一样，只要你还在开新市场，它就还要接着长。 还有一条实际差别：品牌名写错了会有人来提醒你，因为那是你的名字，同事和经销商都会注意到；地名写错了没有人会提醒，因为对每个市场的用户来说，他只是没搜到你而已。 所以这件事在内部争取资源时的说法要变一变：它不是一次优化，而是补一个从来没建过的字段。把它说成优化，排期上永远排在别的优化后面；说成缺字段，它就变成了一件该补的基础工作。 ## 一份地名字段的落地清单 ## 三步就能起步 第一步盘点：把全站出现过城市名的位置列出来，通常是配送页、地区落地页、门店页、表单、结构化数据这五类。 第二步建表：拿公开地名数据源做底表，筛出你要做的市场语言，补上业务相关的俗称，标好可展示状态。 第三步分层落地：展示层按市场语言取外来名，数据层和标记层取官方名，匹配层把所有形态都收进去。 三步做完，剩下的就是把模板改成从表里取值，而不是硬编码。 如果你的时间只够做一件事，那就做匹配层——把所有别名塞进站内搜索的同义词表。这一步不改任何一个页面，见效却最快，因为它直接把原本搜不到东西的用户接住了。 盘点这一步建议用全站搜索直接找，把主要城市名当关键词在自己的内容库里搜一遍。这个笨办法能翻出很多你根本不知道存在的老页面，那些页面往往就是历史遗留形态的重灾区。 ## 验收看什么 看三个数就够。 第一个是配送页和地区页的进站查询里，有多少条带着地名，其中本地名和外来名各占多少。 第二个是站内搜索里地名类查询的零结果率。 第三个是地址表单的填写失败率或者人工修正率，它能反映数据层的归一做得好不好。 这三个数分别对应展示层、匹配层和数据层，覆盖了这件事的全部三个面。如果只能盯一个，盯第二个，它最灵敏，改动一上线当周就会动。 还可以补一个定性检查：把几个主力城市的页面标题拿给本地同事看，问他这行字读起来像不像本地媒体写的。这个问题比任何指标都更能快速暴露形态选错的情况。 另外还可以看一个软指标：客服有没有再收到找不到某某城市配送信息的咨询。这类咨询数量下降，说明改动真的落到了用户那一侧。 ## 什么情况下可以不做 只做本国市场、且这个国家单一官方语言的，基本可以跳过，你的地名形态只有一种。 纯线上交付、跟地理位置无关的生意也可以跳过，比如软件订阅。 但只要你有实物配送、有服务范围、有线下网点，或者要做多个语言市场，这件事就迟早会找上门。 它的特点是不紧急但持续漏水，每天漏一点，年底一看是个不小的数。 判断优先级的办法很实用：去日志里数一数带地名的查询占比。超过一成就该排进这个季度，低于百分之三可以放到明年，中间的看你有没有正在开的新市场——如果有，那这件事最好在开市场之前就做完，事后补的成本是事前的好几倍。 另外提醒一句，判断的时候别只看当下。如果你的路线图里有跨语言市场的计划，那这件事的优先级要按未来一年的地图算，而不是按今天的流量结构算。 ## 常见问题解答 ## 页面上同时写两个名字，会不会显得啰嗦？ 不会，前提是只在第一次出现时并列。通行的写法是主用目标市场语言的外来名，第一次出现时用括号带上本地名，后面全篇只用一种。这样读者读到括号那一下就完成了对照，之后不再被打断。真正显得啰嗦的是另一种做法：每次提到这座城市都把两个名字都写上，或者在页面底部堆一串别名。后者尤其要避免，它读起来像关键词填充，对用户没有任何帮助。 记住匹配层和展示层是分开的，别名的容身之处在站内搜索的同义词表里，不在页面正文里。另外，如果页面上要列多个城市，用表格比用一串顿号连接的文字好得多，一列本地名一列外来名，读者对照起来一目了然，也顺手把两种写法都放进了页面。 ## 用自动转写脚本能不能把外来名生成出来？ 不能，这是这件事上最常见的误解。转写是字母系统之间的机械映射，有规则、可以写成代码；外来名是另一门语言几百年里自己形成的词，跟本地名之间没有任何字符级的对应关系。Köln和Cologne、München和Monaco di Baviera，你写多少行代码都推不出来。 能自动处理的只有转写那一段，而转写形态在搜索里的量通常很小。外来名唯一的获取途径是查表，用公开地名数据库的别名字段做底表，再按自己的市场筛一遍。真要自动化，能自动的只有一件事：从公开地名库把别名批量拉下来入库，那是数据搬运，不是名称生成。 ## 本地名和外来名的量差不多，该选哪个？ 都上，不用选。标题用其中一个，另一个放在正文第一段和页面描述里，成本只是多一行字，却能同时接住两批查询。真正需要做选择的场景只有一个：标题长度不够放下两个。这时候按目标市场来定，面向本国用户就用本地名，面向外国用户就用外来名。判断依据不要靠感觉，用三个信号交叉验证：站内搜索日志里两种写法各出现多少次、搜索建议里补出来的是哪一个、以及本地媒体和本地竞品页面上写的是哪一个。 第三个信号最可靠，因为本地媒体只写读者认得的词。还有一种偷懒但合理的做法：标题用外来名，页面主图的说明文字里放本地名，两处都占住，视觉上又不显得重复。 ## 屈折语市场的地名，要把所有变格形态都写进页面吗？ 不需要穷举，覆盖高频组合就够。波兰语里真正高频的是介词加位置格那几种，比如发往某地、在某地，把这两三种自然地写进正文句子里，就能接住大部分查询。标题保留词典形当锚点，正文承担变格形态，这个分工跟内链锚文本的处理原则是一致的。芬兰语要额外小心，不同城市习惯用不同的位置格，这件事没有规律可循，本地人从不会错，外来团队几乎必错，所以地名相关的句子一定要走母语审校，并且在审校简报里专门点出这一项。 另外别忘了页面描述里也要出现一次，那段文字虽然不直接决定排名，但它是用户在结果页上读到的第二行字，形态对不上会明显影响点击。 ## 结构化数据里该填本地名还是外来名？ 填本地名，也就是官方名。结构化数据是给机器读的，作用是把页面跟一个确定的实体对上号，需要的是规范值而不是用户习惯用的词。这跟正文用外来名并不矛盾：正文迎合用户的表达，标记指向唯一实体，两条线各走各的，互不干扰。如果你的标记体系支持挂外部标识符，务必挂上，有了唯一标识符之后，多语言之间的实体对齐就不再依赖字符串比对，这是跨语言实体问题里最省事的一条路。如果你的标记里能填多个名称字段，把常用的别名作为替代名称一起填上也无妨，前提是主名字段仍然是官方名。 ## 只做一个国家的市场，还需要管这件事吗？ 如果这个国家只有一门官方语言，且你的用户基本都是本国人，那基本可以跳过，地名形态只有一种。但有两个例外值得留意。一是本国的外来人口，他们可能用母语的外来名去搜，这批人在跨境电商里的价值往往高于人口占比。二是多语言国家，比利时、瑞士、加拿大这类地方，同一个地点在两门官方语言里各有一个名字，那是并行名，两个都是官方的，两个都得管。判断办法还是去站内日志里数，看有没有非本地名写法的查询进来。判断标准可以简化成一句话：只要你的用户里有人的母语不是这个国家的官方语言，这件事就已经开始影响你了。 ## 这件事该排在什么优先级？ 用日志里带地名的查询占比来定。超过一成就排进这个季度，低于百分之三可以往后放，中间地带看有没有正在筹备的新市场。有新市场就在开市场之前做完，因为事后修改要动的是已经生成的成百上千个地区页，成本是事前的好几倍。这件事的典型特征是不紧急但持续漏水，每天漏一点，攒到年底是个不小的数字，而且因为没有任何工具会报错，它可以安安静静漏很多年都没人发现。最后提醒一点：这件事的收益不会体现在某个词的排名上，而是体现在一批长尾查询的整体可见性上，所以别用单词排名去验收它。 ## 屈折语站的锚文本报告，精确匹配那一栏的数字是假的 - URL：https://zhangwenbao.com/minor-language-internal-link-anchor-inflection-variants.html - 分类：小语种SEO - 发布：2019-10-15 | 更新：2026-07-26 - 摘要：屈折语里锚文本必然跟着句子变格，字符串口径统计出来的精确匹配比例毫无意义。讲清怎么换成词干口径重算、六种锚位置各自允不允许变形、划锚边界的三条规则。 - 关键词：技术SEO,内链优化,多语言SEO,小语种SEO > **TLDR**：摘要：在俄语、芬兰语这类要变格的语言里，锚文本嵌进句子就必须跟着变形，这是语法要求不是优化选择。于是所有按字符串统计的锚文本报告在这些站上都会失真：精确匹配比例被系统性低估，锚文本多样性被系统性高估，拿英文站那套配比红线去对照只会得出错误结论。本文讲怎么把审计口径从字符串换成词干、六种锚位置各自允不允许变形、划锚边界该守哪三条规则。 > 摘要：在俄语、芬兰语这类要变格的语言里，锚文本嵌进句子就必须跟着变形，这是语法要求不是优化选择。于是所有按字符串统计的锚文本报告在这些站上都会失真：精确匹配比例被系统性低估，锚文本多样性被系统性高估，拿英文站那套配比红线去对照只会得出错误结论。本文讲怎么把审计口径从字符串换成词干、六种锚位置各自允不允许变形、划锚边界该守哪三条规则。 ## 屈折语里的锚文本为什么留不住原形？ ## 名词进句子就要变格，这不是可选项 先把最基本的机制说清楚。俄语里一个名词单独站着是一种形态，放进句子当宾语是另一种形态，跟在介词后面又是第三种。 比如磨豆机这个词，主格写作кофемолка，属格变成кофемолки，宾格变成кофемолку，工具格再变成кофемолкой。 这些不是同义词，也不是写法变体，是同一个词按语法角色必须呈现的不同面貌。 现在你要在正文里给磨豆机分类页做一条内链，锚文本从句子里划出来，划到的必然是句子里那个形态。 想让它保持主格，唯一的办法是把整个句子改写成主格能站住的结构，而这种改写在自然行文里很快就用完了空间。 换句话说，锚文本的形态不由你决定，由这句话的语法决定。 这一点跟英文站的差别有多大，做过对照才有体感。英文里名词进句子形态基本不变，你想让锚文本精确等于目标关键词，几乎总是能做到，代价最多是句子稍微生硬一点。俄语里这个选项直接不存在，你面对的不是要不要精确匹配，而是接受它必然不精确。 ## 一个核心词能出现多少种锚文本形态 数一下就知道这不是小数目。俄语名词六个格，加上单复数，一个词理论上有十二种形态。 实际写作里常用的大概是四到五种，因为有些格在电商文案里很少出现。 芬兰语更夸张，格的数量是俄语的两倍多，十五个格再叠上词干自身的交替 (https://zhangwenbao.com/finnish-seo-fifteen-cases-consonant-gradation-keyword.html)，形态数量还要往上走。 匈牙利语的格数量还要更多 (https://zhangwenbao.com/hungarian-seo-eighteen-cases-vowel-harmony-keyword.html)，好在它的词尾拼接规律性强，归一化反而不难。 所以在这些语言的站点上，同一个目标页收到的内链，锚文本可能有五六种不同的字符串。 这五六种在人眼里是一个词，在按字符串比对的工具眼里是五六个不同的锚。 形态数量还会因为词性叠加而放大。如果核心词是形容词加名词的组合，形容词也要跟着名词一起变格，两个词各自变形，组合出来的字符串数量是相乘而不是相加。做核心词形态表的时候按短语整体列，比按单词列更贴近实际会出现的锚文本。 语法角色 | 俄语形态 | 典型句子位置 | 会不会被划成锚 | 主格 | кофемолка | 做主语、单独列出 | 列表、标题里常见 | 属格 | кофемолки | 表示所属、否定句 | 正文里高频 | 宾格 | кофемолку | 做直接宾语 | 正文里最高频 | 工具格 | кофемолкой | 表示工具、方式 | 教程类内容里常见 | 前置格 | кофемолке | 跟在关于、在等介词后 | 正文里高频 | ## 咖啡豆站那次内链审计：报告和现实对不上 保哥带过一个做精品咖啡豆和手冲器具的独立站，俄语站上线一年后做内链体检。 工具跑出来的报告说：核心品类页收到的内链里，精确匹配锚只占很小一部分，绝大多数是所谓的其他类。 按英文站的经验，这个分布意味着内链没有传递清晰的主题信号，该补一批精确匹配的锚。 负责俄语内容的同事看完报告愣了一下，说这些锚本来就是同一个词，只是格不一样。 把那批被归进其他类的锚导出来逐条看，果然全是磨豆机这个词的四种格形态。 真实的精确匹配率不是报告上那个数，而是接近满值，问题根本不存在。 差点就按报告去执行了，那意味着往正文里硬塞一批主格形式的锚，句子会变得像机器写的。这类返工最坏的地方在于它看起来很有道理：数据支持、逻辑自洽、执行明确，唯一的问题是数据本身在这门语言上根本不成立。 ## 锚文本报告里的精确匹配比例，为什么在屈折语站上是假的？ ## 字符串口径统计的是什么 几乎所有内链分析工具的分桶逻辑都一样：把锚文本当字符串，跟目标关键词做比对。 完全相等归精确匹配，包含关系归部分匹配，其余归品牌词、通用词或其他。 这套逻辑在英语里工作得很好，因为英语的名词短语在句子里形态稳定。 到了屈折语站，完全相等这个条件几乎只在主格锚上成立，而主格锚在正文里恰恰是最少的。 于是精确匹配桶被系统性低估，其他桶被系统性撑大。 工具没有错，它只是在做字符串比对，而字符串在这里不是合适的比对单位。 这个问题跟锚文本工程化那套变体管理方法 (https://zhangwenbao.com/internal-anchor-text-engineering-semantic-variation-link-equity-flow.html)是两回事，别混。变体管理讲的是主动设计不同说法去覆盖语义空间，是有意为之；这里说的是同一个说法被语法强制改写，你没有选择权。前者是策略，后者是约束，处理方式完全不同。 ## 同一批锚在两个口径下差多少 把咖啡豆站那批数据按两种口径各算一遍，差距大到不像同一批数据。 字符串口径下，精确匹配占比是个位数，看着像内链主题信号严重不足。 词干口径下，同一批锚的精确匹配占比跳到了七成以上。 差了将近一个数量级，而中间没有增删任何一条链接。 这个倍数不是个例，它取决于该语言常用格的数量：格越多，字符串口径失真越厉害。 德语的名词变格少一些，失真幅度小；芬兰语这类多格语言，失真幅度比俄语还大。 值得留意的是差距最大的往往不是最核心的那几个词，而是中等热度的品类词。核心词因为反复出现在标题和列表里，主格形态本来就多，字符串口径下也不算太难看；中等词几乎只出现在正文句子中，全是间接格，字符串口径下能被判成精确匹配的接近于零。 统计口径 | 比对单位 | 精确匹配率 | 结论 | 结论对不对 | 字符串口径 | 完整字符串 | 个位数 | 主题信号不足，需补锚 | 错 | 词干口径 | 归一化后的词干 | 七成以上 | 信号充分，不必动 | 对 | ## 被低估的精确匹配与被高估的多样性 失真是双向的，一头低估，另一头高估，两个错误还会互相掩护。 精确匹配被低估已经说过，另一头是锚文本多样性被高估。 报告会告诉你锚文本很丰富，有十几种不同的说法，主题覆盖很广。 实际上那十几种里可能只有三个真正不同的词，其余全是形态变化。 如果你正好在追求锚文本多样化，看到这个数字会觉得目标已经达成，于是停手。 真实情况是语义覆盖并没有你以为的那么宽，该补的相关词一个都没补。 两个方向的失真凑在一起，会导出一个特别舒服的结论：精确匹配不高，多样性很好，正是理想的健康分布。这个结论在屈折语站上几乎必然出现，而它跟真实情况可能正好相反——真实情况是高度集中于一个词、语义覆盖偏窄。舒服的报告最容易让人不去追问。 ## 英文站的配比红线搬过来会得出什么结论 过度优化的判断标准里，最常被引用的是精确匹配锚占比的上限。 这个上限的来源是英文站的经验数据，讨论的场景多半是外链锚文本被算法盯上 (https://zhangwenbao.com/anchor-text-overoptimization-audit-penguin.html)那一类。 把它原样搬到屈折语站的内链审计上，会同时犯两个方向的错。 一是按字符串口径算，你几乎永远不会触碰上限，于是失去了这条警戒线。 二是万一你为了提高精确匹配率而人为往正文里塞主格锚，那才真的制造出了不自然的模式。 红线本身没问题，问题是它要用词干口径去量，而且阈值要重新定。 还有一层容易被忽略：内链和外链在这件事上的处置逻辑本来就不同。内链的锚是你自己写的，算法对它的容忍度和对外链的容忍度不在一个量级上。把外链场景下的配比经验搬进内链审计，就算在英文站上也已经偏了一步，再叠上屈折语的字符串失真，两步偏差叠在一起，结论基本不可用。 ## 把审计口径从字符串换成词干，具体怎么换？ ## 词干工具的选择与语言支持度 最省事的路子是用现成的词干算法，把锚文本和目标关键词都归一化之后再比对。 Snowball的俄语词干算法 (https://snowballstem.org/algorithms/russian/stemmer.html)对本文说的这些格尾处理得相当干净，磨豆机那五种形态归一化之后落到同一个词干上。 德语、芬兰语、匈牙利语也都有对应的算法，质量参差但基本可用。 词干算法是规则驱动的，不需要词典，跑起来极快，几万条锚几秒钟出结果。 它的弱点是遇到不规则变化会失手，比如词干本身发生交替的芬兰语词。 要求更高的场景可以换成词形还原，代价是要装词典、跑得慢一些。 两条路的取舍点很清楚：如果目的只是把锚分桶、看分布，词干算法的精度绰绰有余；只有当你要精确统计某个特定词的每一次出现，才值得上词形还原。信息检索领域对这两者的取舍 (https://nlp.stanford.edu/IR-book/html/htmledition/stemming-and-lemmatization-1.html)讨论了几十年，结论大体一致：检索场景下词干够用。 ## 归一化之后重新分桶 换口径的操作本身不复杂，难的是把它固化成流程。 第一步，导出全站内链，字段要有锚文本原文、目标URL、所在页面。 第二步，对锚文本分词，逐词取词干，得到一个词干序列。 第三步，对目标页的核心关键词做同样处理，得到另一个词干序列。 第四步，两个序列比对，完全一致归精确匹配，包含关系归部分匹配。 第五步，重新出报告，跟字符串口径的报告并排放。 这一套脚本跑通之后基本不用再改，每季度重跑一次就行。分词这一步在多数欧洲语言里按空格切就够了，真正需要专门分词器的是没有词间空格的语言，那是另一类问题。 这五步里最容易出岔子的是第三步。目标页的核心关键词常常存在关键词表里，而那张表里的词多半是词典原形，跟锚文本走的是两套来源。两边必须用同一个词干工具、同一份参数跑，否则归一化结果对不上，比对出来的差异其实是工具差异不是内容差异。 ## 两套数字都留着，各有各的用处 换了口径不代表旧口径没用，两套数字要一起看。 词干口径回答的是：内链有没有把主题信号送到位。 字符串口径回答的是：页面上呈现的锚文本，读者看到的说法有几种。 后者跟用户体验有关，也跟页面读起来自不自然有关，不该被丢掉。 两个数字的比值本身也是个信号：比值越大，说明这门语言的形态负担越重。 把这个比值记录下来，做多语言站的时候可以横向比较各语种的形态复杂度。 实际用起来会发现比值很稳定，同一门语言在不同站点上算出来的数字差不太多。这意味着它可以当成一个校准系数：新接一个俄语站，先按字符串口径跑一遍，再乘上系数，就能大致估出词干口径的水平，不必每次都跑全套。 ## 复合词语言的麻烦跟变格不是一回事 ## 德语的复合词让锚划不出半个词 德语的名词变格没有俄语复杂，但它有另一个东西挡在路上：复合词。 磨豆机在德语里是Kaffeemühle，咖啡和磨这两个概念被拼成了一个单词。 现在你想给咖啡这个品类页做内链，锚文本要用哪一段？你划不出来。 一个词就是一个词，中间没有空格可以下刀，划一半得到的是一个不存在的词。 要么整词做锚，指向磨豆机页，要么改写句子让咖啡单独出现一次。 这在德语关键词研究 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)里是老问题了，只是很少有人把它跟内链联系起来。 后果是德语站的内链密度天然比英语站低。英语里一句话可以顺手带出两三个可链的短语，德语的同一句话可能被压缩成一个复合词加一个动词，能下刀的位置少了一半。这不是内链没做到位，是构词法决定的上限，拿英语站的内链密度基准去要求德语站并不合理。 ## 芬兰语两头都占：既复合又变格 芬兰语把两件麻烦事叠在了一起，是这个话题里最极端的样本。 磨豆机是kahvimylly，本身就是复合词；进了句子还要变格，属格kahvimyllyn，内格kahvimyllyssä。 所以一个锚同时受两重约束：边界由构词法定死，形态由语法定死。 能自由决定的只剩下要不要在这里放一条链接，以及链接指向哪里。 好在芬兰语的格尾拼接高度规则，词干归一化的成功率反而不低。 真正难的是那些词干本身会交替的词，规则算法在那里会失手。 做芬兰语站的内链时，一个务实的做法是先把常用核心词的全部形态列成表，直接用查表法比对，绕开算法。这张表几十行就够覆盖大部分场景，做一次能用很久，比调试词干算法的边缘情况划算得多。 还有一个芬兰语独有的麻烦：复合词的前半部分有时也要变格，形成属格式的复合写法。同一个概念因此可能有两种合法拼法，一种前半部分带格尾，一种不带。这两种写法在搜索量上往往不平均，做核心词形态表时要把两种都列进去，只列一种会漏掉相当一部分内链锚。 ## 两种机制的共同后果：锚的边界不归你定 变格改的是词的形态，复合改的是词的边界，机制完全不同。 但对内链来说，两者的后果是同一个：你想要的那个精确锚，在这门语言里划不出来。 认清这一点之后，整个操作的重心就变了。 重心不再是想办法凑出精确匹配，而是接受不精确，转去保证指向关系清晰。 指向关系清晰的意思是：读者和爬虫都能看出这条链接通往什么主题。 这个目标用变形后的锚一样能达成，甚至因为句子自然，达成得更好。 放弃精确匹配这件事在心理上比在技术上难。做惯了英文站的人会觉得少了一个可控的抓手，总想找补回来。实际上抓手并没有消失，它只是从锚文本的字面移到了别的地方——目标页的标题、链接周围那句话、以及整个话题簇的结构，这三处能提供的信号一点没少。 ## 六个锚位置，哪几个允许变形？ ## 句内正文锚：必须允许变形 正文里嵌在句子中的锚，是最主要的一类，也是唯一必须放弃精确匹配的一类。 规则很简单：让句子通顺优先，锚文本跟着句子走。 不要为了保住主格去扭曲句子，扭出来的句子读者一眼就能看出不对劲。 屈折语的读者对格错误极其敏感，比英语读者对语法错误敏感得多。 一个格用错的句子给人的观感，接近中文里把量词全用错。 所以这一类锚的验收标准只有一条：这句话读起来像不像本地人写的。 这条标准的执行要靠母语审校那一道验收 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)，而且要在简报里写清楚：锚文本处的词形归审校员判断，不在锁定范围内。不写清楚的话，审校员会以为这些带链接的词也属于不许动的清单，硬留着主格不改，最后拿到一份到处是病句的稿子。 ## 列表与卡片标题：可以保持主格 列表项、商品卡片标题、侧边栏推荐这些位置，语境不是句子，是条目。 条目语境里主格是完全合法的，读者不会觉得别扭。 这就意味着这些位置可以稳定地承载精确匹配的锚文本。 换个说法：想要精确匹配，就把它挪到不需要变格的位置去。 这是整篇里最实用的一条，因为它把一个语法问题转化成了一个版面问题。 相关文章列表、你可能也需要模块、品类导航，全都属于这一类。 把精确匹配的需求集中到这些非句内位置，还有个附带好处：它们通常是模板化输出的，锚文本由数据字段决定，不需要每篇文章单独人工维护。一次配置，全站生效，比在正文里逐处纠结词形省力得多。 要提醒的一点是，模板输出的锚文本同样会出错，出错方式是全站统一错。见过一个站的相关文章模块，标题字段取的是某个带格尾的短标题字段，于是全站几千处推荐位的锚文本整齐划一地带着格尾。这类错误单看每一处都不严重，量一大就成了全站范围的形态噪音。 ## 面包屑与导航：一律主格 面包屑和主导航的文字，在任何语言里都该用主格。 它们是标签不是句子，没有语法角色，也就没有变格的理由。 实际做站的时候这里偶尔会出错，原因是文案直接从某个句子里复制过来的。 复制过来的时候带着格尾，读者看着会觉得这个网站的导航写得很奇怪。 检查方法很简单：把导航文字单独列出来，请母语者扫一眼就能发现。 这一处的修复成本极低，收益却很直接，属于该优先做掉的小事。 多语言站还有个连带问题：面包屑的分类名往往跟分类页的标题共用同一个字段。改成主格之后分类页标题也跟着变了，如果那个标题原本是按某种句式写的，读起来就会别扭。遇到这种情况把两处字段拆开，面包屑用短标签、页面标题用完整写法，各写各的。 ## 目录锚点与页内跳转：跟标题走 文章内的目录、页内跳转链接，锚文本应该跟对应的小标题保持一致。 小标题本身多半是主格或者某种独立形态，目录直接沿用就行。 这一类的关键不是词形，是目录文字和小标题文字必须逐字相同。 不相同会让页内锚点的段落直达 (https://zhangwenbao.com/in-page-navigation-engineering-toc-anchor-fragment-passage.html)失效，读者点过去也会疑惑。 屈折语站上这个错误比英文站常见，因为译者会顺手把目录里的表述改得更顺口。 验收清单里加一条逐字比对就能杜绝，脚本两行的事。 逐字相同这条要求在翻译流程里最容易断在交接处：正文和目录常常分两次交付，译者拿到目录的时候手边未必有正文的最终版。解决办法是干脆不要人工维护目录，让程序从小标题自动生成，这样两边永远一致，还省掉一次校对。 锚位置 | 语境 | 允许变形 | 能不能承载精确匹配 | 句内正文锚 | 句子 | 必须允许 | 不能，别强求 | 列表与卡片标题 | 条目 | 不需要 | 能，首选位置 | 面包屑 | 标签 | 不需要 | 能，一律主格 | 主导航 | 标签 | 不需要 | 能，一律主格 | 目录与页内跳转 | 标题复制 | 跟标题走 | 要求逐字相同 | 按钮与行动号召 | 短语 | 看句式 | 视文案而定 | ## 划锚边界该守哪三条规则？ ## 只划名词短语的核心，别把介词划进来 第一条规则管的是锚从哪里开始、到哪里结束。 屈折语的句子里，名词前面常常有介词，后面可能跟着修饰成分。 贪心一点把介词一起划进锚里，锚文本就多了一个没有信息量的词。 更糟的是这个介词会决定后面名词用哪个格，两者绑在一起，锚看起来更不像关键词。 正确做法是介词留在锚外面，只把名词短语的核心部分划成锚。 形容词修饰语要不要划进来看情况：它是关键词的一部分就划，只是修饰就不划。 这条规则在实际操作里有个简单的自检：把锚文本单独摘出来读一遍，如果它像一个词条，就划对了；如果它像半句话，就划多了。多数划错的情况都是把连接成分带了进去，摘出来一读立刻能发现。 还有一种容易划错的情况是把数量词或者指示词带进锚里。这些词在句子里承担的是指代功能，跟目标页的主题没有关系，划进去只会稀释锚文本。判断方法跟前面一样：摘出来单独读，如果它需要依赖上下文才能理解指的是什么，就说明划进了不该划的成分。 ## 允许带格尾，但格尾不算多余词 第二条规则管的是怎么评价一个带格尾的锚。 做锚文本审计的时候，很多人会把带格尾的锚判成部分匹配，理由是它跟关键词不完全一样。 这个判定在屈折语里是错的，格尾不是多出来的词，是同一个词的必要组成部分。 正确的判定是：词干相同就算命中，格尾不参与比对。 这也是前面说的换口径的核心内容，只是落到了单条锚的层面上。 把这条写进审计脚本的规则表里，人工复核的时候也照这条执行。 顺带说一句，通用依存标注体系对格的定义 (https://universaldependencies.org/u/feat/Case.html)可以拿来当参考，它把各语言的格统一编了码。判断某个词尾到底是格尾还是派生后缀时，查一下这份定义比凭感觉可靠。派生后缀会改变词义，那才是真的换了词。 派生和屈折的界线在有些语言里并不清晰，黏着语尤其如此。土耳其语的后缀能连着挂好几层，其中有的是格标记，有的会改变词义。碰到拿不准的，最实用的判据是问一句：换成这个形式之后，它在词典里还是同一个词条吗？还是同一条就按形态处理，另起一条就按换词处理。 ## 锚长度用词数不用字符数 第三条规则跟长度有关，是个容易被忽略的坑。 很多锚文本规范里会写：锚长度控制在多少个字符以内。 这个规范拿到屈折语和黏着语上直接失效，因为格尾会让词变长。 同一个概念，芬兰语写出来比英语长出三成很常见，匈牙利语更甚。 按字符数卡上限，等于对这些语言的锚做了额外的限制，凭空砍掉合理的锚。 改成按词数计，两到四个词，这个标准在所有语言里都成立。 按词数计还有个隐含前提要说清楚：复合词算一个词。德语里一个复合词可能有二十多个字母，按字符数它早就超标了，按词数它只占一个位置，而后者才符合它在句子里的实际角色。这也是同一条规则能同时通吃复合词语言和屈折语言的原因。 规则 | 怎么做 | 常见错误 | 划边界 | 只取名词短语核心 | 把介词、连接词划进锚 | 看形态 | 词干相同即命中 | 把格尾当成多余词判部分匹配 | 控长度 | 按词数计，两到四个词 | 按字符数卡上限，误伤长词语言 | ## 目标页标题里要不要留一个主格形态？ ## 锚与标题的形态对不上会发生什么 锚文本和目标页标题的关系，是内链信号里比较重要的一环。 正文里的锚多半是间接格，目标页标题多半是主格，两者字面上对不上。 这在词干层面上没有问题，两者归一化之后是同一个词。 但如果你用的分析工具是按字符串比对的，报告会说锚与标题不相关。 这又是一次口径失真，处理方式跟前面一样，换口径重算。 真正值得担心的不是这个，是标题里那个词万一根本不是主格。 有些译者写标题的时候会沿用某种间接格，尤其是标题从正文某句话里提炼出来的时候。这样一来标题和大部分搜索查询的形态就对不上了，因为用户在搜索框里打的绝大多数是词典原形。这时候锚文本反倒不是问题，问题在标题本身。 ## 标题里保留主格的代价与收益 建议是：目标页的标题里至少让核心词以主格出现一次。 代价是标题的写法会受一点限制，某些句式用不了。 收益是标题形态跟用户搜索的形态对齐，这一条比锚文本的匹配重要得多。 用户搜索时打出的绝大多数是词典原形，这一点在俄语的搜索量数据里看得最清楚 (https://zhangwenbao.com/russian-seo-cyrillic-cases-declension-wordstat-keyword.html)。 标题命中原形，等于把最重要的那次匹配拿下了。 锚文本那边的变形因此可以完全放开，让位给行文自然。 这个取舍的逻辑值得说透：标题和锚文本如果只能保一个精确形态，保标题。原因是标题的展示位置和权重都在锚文本之上，而且标题只有一处、可控性强，锚文本分散在几十个页面里、根本控不住。把有限的控制力用在可控的地方，是这类取舍的通则。 ## 用副标题或首段兜底的做法 如果标题因为某种原因必须用别的形态，还有兜底方案。 让核心词的主格形式出现在首段前一两句话里，效果差不了多少。 或者在页面上加一行副标题，用主格把核心词写一遍。 商品页还可以靠规格表里的字段名，那里天然就是主格。 兜底方案的共同点是：找一个不需要变格的位置，把原形放进去。 这套思路跟前面讲锚位置时是一样的，只是应用到了页面内部。 兜底位置的优先级可以排一下：首段最好，因为它离标题近、权重也高；规格表字段名次之，好处是天然主格而且不影响行文；副标题最灵活但要看模板支不支持。三个位置任选其一即可，不必都做，重复堆同一个原形反而显得刻意。 ## 内链权重不会因为锚文本变形而流失，会流失的是别的东西 ## 这个担心大部分是多余的 被问得最多的一个问题是：锚文本变形了，权重是不是就传不过去了。 答案是不会。链接本身传递的权重跟锚文本的字面形态没有关系。 锚文本影响的是主题相关性信号，也就是让搜索引擎知道目标页是关于什么的。 而搜索引擎处理主流语言的形态变化已经很多年了，词干归并是检索系统的基础能力。 所以变形的锚在相关性信号上并不吃亏，至少不会吃到值得担心的程度。 要担心的是别的：内链架构本身有没有搭对 (https://zhangwenbao.com/internal-linking-architecture-link-equity-guide.html)，重要页面有没有拿到足够的入链。 把注意力放在锚文本的字面上，是一种很常见的注意力错配。锚文本能提供的信号在整个内链体系里占比不大，而链接的位置、数量、来源页面的重要程度，这些才是决定性的。屈折语站的运营者尤其容易掉进这个坑，因为形态问题看起来很技术、很具体，让人误以为它很重要。 ## 真正流失的是你的判断力，不是权重 这一批失真数据造成的实际损失，从来不是权重，是决策。 基于错误的报告，你可能补一批不该补的锚，也可能停下该做的事。 补锚的成本是内容质量下降，停手的成本是本该做的语义覆盖没做。 两种损失都不会立刻显现，它们要几个月后才在数据上露头，那时候归因已经很难。 更隐蔽的是，错误报告会持续输出，每季度提醒你同一个不存在的问题。 团队会慢慢习惯这个数字，把它当成这门语言就是这样的常态。 这类错误报告还有一个特点：它每次都指向同一个方向，也就是让你觉得内链做得不够。于是团队的动作永远是加链接，从来不会是删链接或者调结构。半年下来站内链接越堆越多，真正需要调整的结构问题一次都没被提出来，因为报告从来不看结构。 ## 该盯的指标换成哪几个 与其盯着精确匹配比例，不如换四个指标，全都跟形态无关。 第一个是重要页面的入链数量，尤其是那些没人愿意主动链的交易页 (https://zhangwenbao.com/deep-link-money-pages-link-equity-routing.html)。 第二个是入链的来源分布，来自话题相关页面的比例越高越好。 第三个是孤立页面的数量，一条内链都没有的页面必须清零。 第四个是词干口径下的语义覆盖度，也就是真正不同的词有几个。 这四个指标在任何语言里都成立，不需要为屈折语单独解释一遍。 这四个指标还有一个共同的好处：它们全部可以从站内数据直接算出来，不依赖第三方工具的分桶逻辑，也就不会被工具的默认口径带偏。自己算的指标虽然要花一次开发成本，但口径完全掌握在自己手里，跨语种横向比较的时候才有意义。 旧指标 | 在屈折语站上的问题 | 换成 | 精确匹配锚占比 | 字符串口径下系统性低估 | 词干口径下的命中率 | 锚文本多样性 | 把形态变化误计为不同说法 | 词干去重后的真实词数 | 锚文本字符长度 | 误伤长词语言 | 锚文本词数 | 锚与标题字面相似度 | 主格与间接格判为不相关 | 词干层面的相似度 | ## 过度优化的红线在屈折语站上怎么定？ ## 词干口径下的重复度才是真重复 换了口径之后，过度优化这个概念要重新定义一遍。 字符串口径下看起来很分散的锚，词干口径下可能高度集中。 集中到什么程度算过度，没有现成答案，但方向是清楚的。 如果一个目标页收到的内链，词干口径下九成以上都是同一个词，那确实过于单一。 单一不等于危险，它更多是个语义覆盖问题：你只用一种说法在描述这个页面。 补救办法不是减少那个词，是增加相关词的锚，把语义空间铺开。 判断集中度的时候建议按目标页算，不要按全站算。全站维度的锚文本分布必然分散，因为每个页面的主题不同，看不出问题；单个目标页维度上才能看出它是被一种说法反复描述，还是被多种相关说法从不同角度描述。后者对语义覆盖显然更有利。 ## 变体自然分布长什么样 自然写作产生的形态分布是有规律的，认识这个规律能帮你识别人工痕迹。 正文里宾格和属格最多，因为大部分句子里名词充当宾语或者表示所属。 主格锚只在少数句式里出现，占比通常不高。 如果导出来发现主格锚占了大多数，那多半是人为塞进去的。 反过来，如果某个格完全不出现，可能是内容类型太单一，也值得看一眼。 这套分布特征每门语言都不同，跑一次自己站的数据就有基线了。 拿到基线之后，判断新增内容有没有人为痕迹就很快：把新一批锚的格分布跟历史基线比一下，偏离明显的挑出来人工看。这个方法比任何阈值都实用，因为它用的是你自己站的自然写作分布当参照，不依赖外部经验数据。 另外要按内容类型分开统计。教程类内容里工具格和方式类表达明显更多，商品列表页里主格占绝对多数，两类内容混在一起算平均，得到的分布谁也不像。分开统计之后每类内容各有一条基线，识别异常的灵敏度会高很多。 ## 人为制造变体反而更可疑 有人知道了这套失真之后，会走到另一个极端：刻意制造形态变体来让报告好看。 这件事的性价比极低，而且很容易露馅。 刻意制造的变体往往出现在不该出现的位置，比如列表项里冒出一个工具格。 母语读者一眼就能看出这个网站的文字有点怪，信任感是会掉的。 而搜索引擎那边，你换来的只是一个内部报告上的数字变化。 形态多样性从来不是优化目标，句子自然才是，两者顺序不能颠倒。 这里可以直接给一条判据：任何一次锚文本调整，如果理由是让报告的数字好看，就不该做。锚文本调整的合理理由只有两个，一是原来的锚指向不清楚、读者看不出通往哪里，二是这个位置本来就该加或者该去掉一条链接。除此之外的调整都是在优化数字而不是优化站点。 ## 一个可操作的自查顺序 把这一节压成一个能照着做的顺序，四步。 第一步，用词干口径重跑一遍全站内链报告，跟旧报告并排看。 第二步，找出词干口径下集中度最高的那几个目标页，看是不是语义覆盖太窄。 第三步，导出锚文本的格分布，跟自然写作的规律对照，找人工痕迹。 第四步，只对确实有问题的页面动手，其余不动。 四步跑下来，绝大多数屈折语站会发现内链其实没什么问题，问题在报告。 四步里第四步最容易被忽略。发现报告失真之后，人的第一反应往往是把全站的锚重新梳理一遍，其实没有必要。真正需要动手的通常只有几个语义覆盖过窄的目标页，其余页面的锚文本本来就是自然写作的产物，动它们只会引入新的不自然。 ## 这套做法怎么落进日常的内链维护？ ## 什么时候重跑一次词干口径 频率不必高，季度一次足够，因为内链结构变化本来就慢。 例外是内容批量上线之后，比如一次性发了几十篇文章，那要单独跑一次。 换了内容供应商或者译者，也建议跑一次，因为写作习惯会带来分布变化。 网站改版之后必须跑，模板里的链接位置一变，整个分布就重排了。 平时不必盯，把脚本挂进定期任务，出报告的时候看一眼就行。 报告要存档，几个季度之后的趋势比单次快照有价值得多。 存档的时候记得把当时的词干工具版本和参数一起记下来。这类算法偶尔会更新规则，换了版本之后同一批数据算出来的数字会有小幅变动，如果没记参数，几个季度后看到趋势变化会分不清是内容变了还是工具变了。这种记录成本几乎为零，省下的排查时间却很可观。 ## 新增页面的锚怎么定 发新文章的时候，内链是顺手做的事，别搞得太复杂。 做法是：写作时正常写，写完之后找出可以链出去的名词短语，按前面三条规则划锚。 不要为了链接去改句子，也不要为了保住形态去改句子。 需要精确匹配的，交给页面底部的相关文章模块，那里是模板输出的。 把这个流程写进内容规范，译者和编辑都照做，一年下来分布自然健康。 唯一需要人工把关的是链接的指向对不对，形态问题完全不用管。 这一点对话题簇的支柱页与子页结构 (https://zhangwenbao.com/topic-cluster-pillar-content-hub-spoke-architecture-mechanism.html)尤其重要：簇内的链接关系是靠结构定义的，不是靠锚文本字面定义的。结构对了，锚文本怎么变形都不影响簇的完整性；结构错了，锚文本写得再精确也补不回来。 写作时正常写这一条要跟译者讲清楚，否则会出现另一种情况：译者知道了内链的存在，于是刻意往句子里安排适合做锚的名词短语，句式开始变得雷同。内链应该是从自然文本里发现的，不是为它预留位置的。这条边界写进内容规范，比事后挑毛病有效。 ## 六步落地路线 整篇压成六步，可以直接照着排期。 第一步，确认自己站的语言属于哪一类：变格、复合，还是两者都有。 第二步，选一个词干工具跑通归一化，验证核心词的各形态能落到同一个词干。 第三步，用词干口径重跑一次全站内链报告，跟旧报告并排存档。 第四步，按六种锚位置划分职责，把精确匹配的需求集中到非句内位置。 第五步，检查目标页标题里核心词有没有主格形态，没有的补上或者用首段兜底。 第六步，把三条划锚规则写进内容规范，季度重跑一次报告。 六步里最关键的是第三步和第四步。第三步让你知道真实情况，第四步把想要的精确匹配挪到不受语法约束的地方去，两步做完，剩下的都是维护性工作。前面那些关于形态的纠结，本质上是想在一个不能控制的地方争取控制权，换个地方就不用争了。 ## 常见问题解答 ## 没有词干工具支持的小语种，锚文本审计还能做吗？ 能做，退一步用前缀匹配。取每个词的前若干个字符做比对，比如前四到六个字符，绝大多数屈折语的格尾都在词的末尾，前缀部分是稳定的。这个办法会有误判，两个不同的词开头相同就会被并到一起，但用于分桶统计完全够用。另一条路是手工维护一张核心词的形态表，几十行覆盖主要品类词，查表比对，精度反而比算法高。两个办法可以叠着用。 ## 锚文本变形会不会影响搜索引擎理解链接指向？ 基本不会。词形归并是检索系统的基础能力，主流语言上处理得相当成熟，一个带格尾的词和它的原形在索引层面早就被关联起来了。真正影响理解的是别的因素：链接周围那句话在讲什么、目标页标题写的是什么、这两个页面在站内结构上是什么关系。这些信号加起来的分量远超锚文本的字面形态。把精力放在这几处，比纠结格尾划算得多。 ## 面包屑里的分类名到底该用什么形态？ 用主格，也就是词典原形。面包屑是一串标签，不是句子，没有语法角色需要标记，用间接格反而显得奇怪。实践中出错的情况几乎都是文案从某句话里复制过来的，带着格尾就上线了。检查方法很简单：把全站的面包屑分类名导出来列成一列，请母语者扫一遍，几分钟就能挑完，修复成本也极低。这类小事修完的观感提升比想象中明显。 ## 德语站的内链密度比英文站低，这算问题吗？ 不算，这是构词法带来的结构性差异。德语把两三个概念压成一个复合词，一句话里能下刀的位置本来就比英语少；能划的又常常是整个复合词，指向也就被锁定了。拿英文站的内链密度基准去要求德语站，结果多半是硬塞链接，反而让文本变形。合理的做法是给每种语言单独建基线，用自己站的历史数据当参照，横向比不同语言的绝对数字没有意义。 ## 目标页标题非要用间接格，有没有补救办法？ 有，让核心词的主格形式在页面别的位置出现一次就行，优先选首段的前一两句话，其次是副标题、规格表字段名或者面包屑。这些位置都不需要变格，天然承载原形。要注意的是别在标题里硬塞一个主格形式凑数，那会让标题读起来像两句话拼起来的。补救的思路始终是找一个不受语法约束的位置，而不是在受约束的位置上硬来。 ## 词干口径和字符串口径的报告，该给老板看哪一份？ 给词干口径那份，但要把两份的差异用一句话解释清楚，否则下次别人拿工具跑出来的数字跟你的对不上，信任就没了。比较省事的做法是在报告里固定放一个换算说明：本站锚文本按词干归一化统计，与通用工具的默认口径不同，差异来源是这门语言的形态变化。写一次，以后每份报告都带着，比每次口头解释可靠。 ## 这套方法对没有词间空格的语言适用吗？ 部分适用。词干归一化的思路成立，但前置的分词步骤要换成专门的分词器，按空格切完全行不通。而且那类语言的问题重心不在形态变化，而在切分边界本身：同一串字符可能有多种切法，锚文本的起止位置会直接影响它被理解成什么词。所以那边要先解决切分，再谈锚文本审计，顺序不能反。这属于另一类问题，处理框架不同。 ## 权威参考资料 ## 转成小写这一步在英文站上从来不出事，到了土耳其语站它把词改成了另一个词 - URL：https://zhangwenbao.com/minor-language-case-folding-lowercase-turkish-dotless-i.html - 分类：小语种SEO - 发布：2019-08-14 | 更新：2026-07-27 - 摘要：英语的大小写是一一对应且可逆的，土耳其语会反转方向、德语会把一个字符变成两个、希腊语要看词在不在末尾。讲清这三类例外分别在slug、去重、匹配、正则哪一处咬人，以及为什么没有语言参数的函数不是通用而是选了英语。 - 关键词：技术SEO,出海SEO,多语言SEO,小语种SEO > **TLDR**：摘要：把字符串转成小写，在英文站是一个不需要讨论的动作，因为英语的大小写是一对一、无损、可逆的。换到土耳其语、德语、希腊语上，同一个函数会改变词义、改变字符串长度、改变字符个数，而它默认用的语言是英语。本文拆开这条链路上的八个落点，给出一份往返测试式的自检办法，两小时就能跑完。 > 摘要：把字符串转成小写，在英文站是一个不需要讨论的动作，因为英语的大小写是一对一、无损、可逆的。换到土耳其语、德语、希腊语上，同一个函数会改变词义、改变字符串长度、改变字符个数，而它默认用的语言是英语。本文拆开这条链路上的八个落点，给出一份往返测试式的自检办法，两小时就能跑完。 ## 为什么把字母转成小写，在英文站上从来不算一个决策？ ## 英语的大小写是一张一一对应的表 英语字母有二十六个大写、二十六个小写，一个对一个，中间不缺不多。转换过去再转回来，字符串一个字节都不会变。 正因为这个性质太稳，它在工程里被降格成了一个工具函数。没人给它写测试，没人在代码评审里问一句这里是什么语言。 更关键的是，这个动作在英语里是幂等的。转一次和转十次结果一样，所以它可以被放心地塞进任何一层管道。 slug生成器里有它，去重脚本里有它，搜索匹配里有它，重定向表生成里也有它。四个地方各调一次，谁也不会觉得有问题。 于是它悄悄变成了全站调用次数最多、被审查次数最少的一个操作。你在代码里搜一遍，通常能搜出上百处。 这就是问题的起点：一个操作之所以从来不出事，可能不是因为它安全，而是因为它一直只在一种语言上被使用。英语站上的十几年经验，验证的其实是英语这门语言的一个巧合性质——它的正字法碰巧不需要大小写映射表里出现任何例外条目，而世界上绝大多数使用拉丁字母的语言都做不到这一点。 ## 换一门语言，这张表就有了例外 Unicode给大小写映射准备了两份文件。一份是简单映射，一个码位对一个码位；另一份专门收例外。 例外文件的存在本身就说明了问题：如果一一对应到处成立，就不需要单独开一个文件来收特例。 例外分三类。第一类跟语言有关，同一个字符在不同语言里往不同方向变；第二类跟上下文有关，字符在词尾和词中变得不一样。 第三类最麻烦，它改变字符串的长度。一个字符转成大写变成两个字符，字符数从此对不上了。 这三类分别对应土耳其语、希腊语和德语，都不是什么冷门语言，加起来的市场规模不算小。 把这三类例外摆在一起看，会发现一件反直觉的事：大小写转换根本不是字符级操作，它是词级操作，甚至是语言级操作。字符级的直觉之所以能在英语上活下来，是因为英语恰好没有一条规则需要看邻居、看语言、看词的边界，而其他语言至少要看其中一样。 ## 函数签名里那个缺席的参数 大多数语言的标准库提供两个版本：一个不带地区参数，一个带。不带的那个，用的是某个默认地区。 默认地区往往取自运行环境，也可能被硬编码成不区分地区的根地区。无论哪种，都跟你页面上那门语言无关。 这里有一个判据可以直接搬走：一个函数如果没有语言参数，它不是通用的，它是选了默认值的。 而默认值几乎总是英语，或者是一套按英语的假设设计出来的规则。它不会报错，也不会警告，只是安静地按另一门语言处理你的词。 这跟编码问题的手感完全不同。编码错了会出现乱码，人一眼能看见；大小写错了出来的是一个长得很正常的词。 更麻烦的是，出错的那个结果通常也是一个合法的字符串，能存进数据库，能拼进网址，能在页面上正常显示。它唯一的问题是，用户在搜索框里打的不是这一串。这类错误不会触发任何一条告警，只会在半年后表现为某几类词的流量一直起不来，而排查的人根本不会往字符层想。 ## 土耳其语的四个字母，怎么把一个词变成另一个词？ ## 一个点的有无，是两个独立的字母 土耳其语的拉丁字母表里，带点的i和不带点的i是两个字母，各有各的大小写形态，一共四个码位。 带点的小写i，大写是带点的大写；不带点的小写，大写才是我们熟悉的那个光秃秃的大写字母。 换句话说，在土耳其语里，把大写字母转成小写，得到的不是英语里那个i，而是不带点的那一个。方向整个反了过来。 这四个码位是U+0049、U+0069、U+0130、U+0131。前两个是英语也在用的，后两个是土耳其语专有的。 它们在字体里经常缺，在键盘上分两个键，在搜索框里被用户随手替换成ASCII写法。这三件事互相叠加。 需要强调的是，这不是变音符号那种可加可不加的装饰。带点和不带点在土耳其语里区分词义，就像英语里的b和d一样，是两个字母，不是一个字母的两种写法。把它们当成同一个字母折叠掉，等于在英语词表里把bad和dad合并成一条。 ## 一个真实的商品词，转完之后不再是它自己 拿一个卖婴儿浴巾的土耳其语站举例。湿这个形容词写作ıslak，开头是不带点的那个字母。 把它整词大写用作导航标签，得到的第一个字母是光秃秃的大写。到这一步还没问题。 问题出在下一步：把这个大写串按默认规则转回小写，出来的开头变成了带点的i。词形从此变成了另一个串。 这个新串在土耳其语里不是一个词。它进了关键词表，进了slug，也进了站内搜索的索引。 用户当然搜不到。后台看上去一切正常，词有排名有展现，只是点击量长期偏低得不像话。 另一个方向更热闹一点。土耳其语里有一个非常常用的词，意思是频繁、密集，开头也是不带点那个字母。用默认规则把它的大写形态转成小写，会得到一个在英语拼写里完全合法、但在土耳其语语境里绝对不适合出现在婴幼儿商品页上的词。这个例子在软件工程圈里流传了二十年，只是几乎没人把它当成一个搜索问题来讲。 ## 带地区参数的版本，为什么也不是万能开关 标准库确实提供了带地区参数的版本，传入土耳其语的地区码，映射方向就对了。 但这只解决了你自己代码里的那一处。链路上还有数据库、搜索引擎、模板引擎、表格软件、第三方插件。 它们各有各的默认值，各有各的配置位置。有的能配，有的只能整库配，有的压根没有这个概念。 这就回到了一条老经验：支持是链条属性，不是节点属性，能不能用取决于最差的那一环。 所以正确的做法不是到处传参数，而是先画链路，标出每一处发生了大小写转换的位置，再决定哪几处必须传、哪几处应该干脆不做这个转换。 还有一种更省事也更稳的思路：在这门语言上，把大小写转换从关键路径上整个拿掉。索引存原形，匹配用专门的折叠规则，展示层交给样式表去控制视觉上的大写效果。这样做需要改的地方比逐处传参数少，出错的面也小得多。 还有一个容易被忽略的现实：很多团队的多语言站是同一套代码跑十几门语言，转换函数被抽成了公共库。公共库天然倾向于不带参数的那个版本，因为带参数意味着调用方必须提供语言，而调用方常常拿不到。ECMA-402国际化规范 (https://tc39.es/ecma402/)把这类地区敏感行为单列成一份标准，本身就说明它不是可以顺手带过的细节。 ## 点没了之后，字符个数也变了 还有一个更隐蔽的形态。把带点的大写字母按不区分地区的规则转成小写，某些实现会得到一个普通i加上一个单独的组合点，两个码位。 肉眼看它跟一个普通i几乎没有区别，但字符串长度多了一位，字节数多了两位。 这个串跟用户输入的串在字节层面不相等。任何等值比较都会返回否，任何哈希去重都会把它当成新词。 它还会污染统计。关键词表里两行看着一模一样，搜索量一分为二，谁也不够门槛。 做规范化的时候如果没有先做Unicode规范化，这一对就会一直并存下去，越积越多。 这类问题的诊断办法很朴素：把两个看起来相同的字符串各自打印出字符个数和码位序列，一比就知道。真正难的不是诊断，而是意识到要去诊断——因为屏幕上它们长得一模一样，不会有任何人主动怀疑这两行是两个东西。 组合点这一类问题的根子在于同一个视觉结果可以有多种码位写法，而字符串比较看的是码位不是视觉。规范化就是把多种写法统一到一种上去的过程，Unicode字符数据库标准附件 (https://www.unicode.org/reports/tr44/)里把每个字符的分解方式都标了出来，需要的时候可以直接查表核对。 ## 德语的ß换成两个S之后，为什么再也回不去？ ## 一个字符变成两个字符 德语的ß长期没有官方的大写形态。传统规则是遇到全大写就写成两个S。 于是Straße全大写之后是STRASSE，五个字母变成六个，一个码位变成两个。 这是大小写转换里唯一一类会改变长度的操作，也是最容易在字段长度、截断、对齐上出问题的一类。 标题在搜索结果里按像素截断的时候，这多出来的一个字母有时候正好把最后一个词挤出去。 更常见的是列表页的对齐，全大写的德语商品名比原形长出一到两个字符，本来排得整齐的三列就歪了。 2017年之后，德语正字法承认了ß的大写形态，允许在全大写时保留它。但这只是允许，不是强制，两种写法在同一个市场上并存，也就意味着你的关键词表里天然会有两套形态，而不是一套换成另一套。 字段长度也要跟着重算。如果你按英语经验给标题字段留了固定的字符数上限，德语全大写之后可能正好越界，写入时被静默截断，页面上就出现半个词。这类截断不会报错，只会在某一批商品上表现为标题少了一截，而排查的人往往先去怀疑模板。 ## 不可逆的那一步在哪里 关键不在于变长，而在于变完之后信息丢了。看到STRASSE，你无法判断它原来是Straße还是Strasse。 两个不同的词在大写这一步被合并成同一个串。再转回小写，只能得到strasse，另一个词永远回不来了。 这就是有损转换。它跟变音符号折叠很像，区别在于变音符号折叠是你主动选的，你知道自己在做取舍。 大小写转换没人觉得自己在做取舍。它被当成一个格式化动作，跟去掉首尾空格放在同一类。 一旦有损转换发生在存储环节而不是展示环节，原始信息就没了，后面再补救就要重新拿源数据。 这里可以提炼出一条通用判据：凡是会改变字符串长度的转换，一定是有损的，绝对不能发生在存储层。长度不变的转换也可能有损，但长度一变，几乎不用再看第二眼。 判断一步转换是不是该放在存储层，有个很朴素的问法：这一步做完，我还能不能把原来的东西还原回来。答得出来就放心存，答不出来就只能当成派生数据，原形必须另存一份。这条判断标准跟数据库设计里不存冗余的直觉正好相反，很多事故就出在为了少存一列而丢了原形。 ## 关键词表里两行词，其实是一个市场的两拨人 Straße和Strasse在德语区不是错别字关系。瑞士德语正式废除了ß，全部写成两个s。 所以同一个词，德国和奥地利用户打一种，瑞士用户打另一种，两边都是正确拼写。 如果在建表阶段就把它们折叠成一行，你等于把瑞士市场的搜索量并进了德国的桶里。 合并之后总量确实更好看，但你再也算不出瑞士那一侧值不值得单独做落地页。 这跟葡语两个市场、西语两侧的分叉是同一类问题，只是这次的分界线落在了一个字符上。 处理办法跟做德语复合词与变音符号选词 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)时那套一样：两种形态都保留在词表里，各自算量，在页面上二选一做主形态，另一种进内容里自然出现一次。别指望引擎替你把这两拨人合并，也别自己动手合并。 顺带提一句瑞士市场的另一层特殊性：那里同时有德语、法语、意大利语三个语言区，你为德语做的这个决策不会自动适用于另外两个区。把国家当成语言的容器几乎总会出错，正确的做法是先把语言和市场拆成两个字段，再决定哪一层做分叉。 ## 希腊语末尾那个字母，为什么让同一个词在库里存成两份？ ## 位置决定字形，这是上下文相关映射 希腊语的sigma有两个小写形态。词中用一个，词尾用另一个，大写只有一个。 把大写词转成小写的时候，实现必须判断这个字母是不是在词尾，才能选对形态。 这就是上下文相关映射：同一个大写字母，转成小写可能得到两个不同的结果，取决于它旁边是什么。 能正确处理这一条的实现不算少，但简单映射表做不到，正则替换更做不到，Unicode官方问答里关于完整映射与简单映射的区分 (https://www.unicode.org/faq/casemap_charprop.html)把这一点讲得很直白。 做不到的后果是：词尾出现了本该只在词中用的那个形态，希腊语用户一眼就能看出来这页不是本地人写的。 三个形态分别是 Σ、σ、ς，这也是本文里唯一一组能在图上原样画出来的字母——土耳其语和德语的那几个特殊字符在很多字体里干脆缺失，反而是希腊语这一组几乎哪都有。这个细节本身值得记一笔：字形覆盖率和大小写规则复杂度之间没有任何关系，你不能靠字体正常显示来推断这门语言的转换规则简单。 ## 两种形态在检索侧算不算同一个词 好消息是，主流搜索引擎在希腊语上会把这两个形态当成同一个词处理，用户搜哪种都能命中。 坏消息是，你自己的站内搜索大概率不会，除非你显式配了对应的折叠规则。 Unicode的大小写折叠表里专门为这一对准备了条目，把它们都折向同一个目标形态。 这也解释了为什么折叠和转小写不是一回事。折叠是为了比较，转小写是为了显示，两者的目标不同。 混用的结果就是：拿显示用的结果去做比较，或者把比较用的结果直接展示给用户看。 把这两件事分开，是整篇文章里最省事也最值钱的一条改动。存原形用于展示，另存一份折叠形态用于比较和去重，两列并行，谁也不覆盖谁。改动量通常只有一个字段加一次批量回填。 更值得注意的是折叠规则本身也在演进。Unicode每一次大版本都可能新增或调整条目，而你的运行时依赖的库版本未必跟得上。ICU国际化组件库 (https://icu.unicode.org/)是多数系统实际使用的实现，升级时最好把探针词表重跑一遍，看看有没有条目变化影响到已有的比较键。 ## URL里的希腊字母还要多考虑一层 如果slug用的是希腊字母，那么大小写规则会和网址的规范化规则叠在一起发生。 网址的路径段区分大小写，域名不区分，这两半本来就走的是两套机制。 再叠上一个上下文相关的字形选择，同一个词就可能生成两条不同的路径。 两条路径都能打开，都能被抓取，都能被外链指到，收录里就多了一份自我竞争。 这一层的完整拆解在小语种URL用本地字母还是拉丁转写 (https://zhangwenbao.com/minor-language-url-native-script-vs-latin-transliteration.html)里已经写过，本文只补一句：大小写这一步要放在转写之前做，顺序反了会多出一批孤立的旧地址。 另一个常被忽略的细节是外链。别人链接到你的希腊字母地址时，多半是从浏览器地址栏复制的百分号编码形态，粘出来的大小写和你的原始形态未必一致。这批外链会落到一个跟规范地址不完全相同的路径上，权重能不能合过来，取决于你的规范化标签配得对不对。 ## 站内最先出事的四个位置 ## slug生成器 slug生成器是全站最爱调用小写函数的地方，通常还紧跟着一步去掉变音符号。 两个有损操作连着做，出来的字符串跟原标题的关系已经很难反推。 更糟的是这一步的结果会被写死进数据库，成为文章的永久地址。 发现问题的时候，改slug意味着改地址，意味着一批301跳转和一段时间的波动。 所以这一处的正确做法是：上线前用目标语言的真实词跑一遍，别等内容都发完了才发现规则不对。 值得单独检查的是那些以特殊字母开头的词，因为首字母出错的slug在字母序里会整个跑到另一个位置去，人工翻列表的时候特别容易漏看。 slug规则改动还有一个隐性成本：站内已有的内链、站内搜索的历史记录、外部工具里保存的地址列表都指向旧形态。一次规则修正往往要配一张映射表，把旧地址逐条对到新地址上去，而这张表越晚做越难做，因为你会越来越不确定某个旧地址当初是怎么生成出来的。 ## 关键词表去重 做词表的人几乎都会先把所有词转成小写再去重，这一步几乎是肌肉记忆。 在英语上它完全正确，在土耳其语和德语上它会把不该合并的词合并掉。 合并之后的表看起来更干净，行数更少，搜索量更集中，汇报的时候数字也更好看。 但你失去的是分叉信息，而分叉信息恰恰是小语种选词里最贵的那一部分。 建议把去重拆成两步：先按原形去完全重复，再单独看大小写差异那一批，人工过一遍。 人工那一遍通常只有几十行，一个母语者十分钟就能标完哪些是真同词、哪些是两个词。这是整条流水线上性价比最高的一次人工介入，比事后从流量数据里倒推便宜太多。 词表流水线上还有一个更早的环节值得检查：从工具导出的原始数据本身可能已经被规范化过一次了。有些平台在返回查询数据前就做了统一小写，你拿到手的已经是加工过的形态。这种情况下再怎么小心也补不回信息，只能换一个能返回原形的数据源，或者用小语种关键词工具没数据时的替代办法 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)里那几种自采集方式。 ## 站内搜索的匹配层 站内搜索要不区分大小写地匹配，就必然要在索引和查询两侧各做一次转换。 两侧用的必须是同一套规则，而且必须是折叠规则，不是显示用的小写规则。 实践里最常见的故障是：索引侧用了带地区的规则，查询侧用了默认规则，两边对不上。 症状很典型，用户搜完整词能搜到，搜某几个以特殊字母开头的词就一片空白。 排查的入口是把两侧的规范化结果各打印一份出来对照，一比就能看出错在哪一侧。 这类站内搜索的语言层配置，跟土耳其语后缀堆叠的选词处理 (https://zhangwenbao.com/turkish-seo-agglutinative-suffix-stacking-keyword.html)要一起做，否则词干还原对了、大小写又错了，两个问题会互相掩盖对方的症状。 如果站内搜索用的是现成的搜索引擎组件，那么分析器链条通常由若干个过滤器串起来，小写过滤器只是其中一环。把这条链打印出来，你会发现前后顺序也很关键：先做词干还原再折叠，跟先折叠再做词干还原，在屈折语上得到的结果可能完全不同。 ## 正则表达式里的字符类 写正则的时候，一个方括号加a到z，是最常见的写法之一。 这个范围里没有任何一个带变音符号的字母，也没有不带点的那个土耳其字母。 用它做校验，本地语言的正常词会被判成非法；用它做替换，特殊字母会被整个吃掉。 不区分大小写的标志位在某些实现下还会把土耳其字母匹配进英语字母的范围里，方向再一次反了。 正确的写法是用Unicode属性类，而不是手写字母范围。这一条改起来不难，难在全站搜出所有的手写范围。 校验类正则的危害比替换类更大，因为它直接决定用户能不能提交表单。一个只认英语字母的姓名校验，会把大量本地用户挡在注册流程外面，而这些人不会打客服电话解释，他们只会关掉页面。Unicode标识符与语法标准附件 (https://www.unicode.org/reports/tr31/)里给出了按属性构造字符类的推荐做法，可以直接照搬。 ## 关键词表去重时，大小写折叠会错误合并哪些词？ ## 先分清折叠和转小写这两件事 转小写的目标是产出一个给人看的字符串，它要符合这门语言的正字法习惯。 折叠的目标是产出一个给机器比较的键，它不需要好看，只需要稳定且一致。 两者的规则表不同，Unicode分别提供了两份数据文件，用途写得很清楚。 混用最典型的后果，是把折叠后的键当成展示文本写进了页面标题。 用户看到的标题就成了一串既不像大写也不像小写、还缺了几个符号的怪东西。 把这两件事在数据模型上分成两列，是一次性投入、长期收益的改动。展示列存原形，比较列存折叠结果，所有的等值判断、去重、缓存键都走比较列，页面上永远只渲染展示列。 命名上也建议区分开。把比较用的那一列直接叫成小写列，几个月后一定会有人拿它去渲染页面，因为名字听起来就像是一个可以显示的东西。叫成匹配键或者比较键，就不太会有人误用，这是个几乎零成本却能长期生效的小防线。 ## 哪些合并是对的，哪些是错的 同一个词的句首大写和词中小写，合并是对的，这是绝大多数场景的诉求。 整词大写的导航标签和正文里的原形，合并也是对的，它们确实是一个词。 土耳其语带点和不带点的那两个字母，合并是错的，它们是两个字母。 德语的ß和两个s，合并要看市场，德奥和瑞士的用户群不同，量要分开算。 希腊语的两个小写sigma，合并是对的，它们是同一个字母的位置变体。 把这五条列成一张小表贴在词表流水线的文档里，比写十页规范管用。判断依据只有一条：合并之后，你还能不能把这两拨人分开算量；分不开还非要合，就是在给自己的下一次决策制造盲区。 这张表还有一个用途：它能直接变成给开发的验收用例。每一行写成一个断言，输入两个词形，期望输出是相等还是不相等，跑一遍就知道当前实现符不符合语言事实。用例的价值在于它把语言学结论固化成了可执行的东西，人员流动之后规则也不会跟着流失。 ## 合并造成的损失怎么估 不用等半年看流量。直接从现有词表里挑出所有含特殊字母的词，数一下有多少行。 再看这些行的搜索量总和占整张表的百分之几，这个比例就是你的风险敞口。 土耳其语站上这个比例通常不小，因为那两个字母在常用词里出现频率相当高。 德语站上比例小一些，但集中在地址、街道、尺寸这类高意图词上。 希腊语站上比例最低，因为词尾形态的问题主要影响长尾而不影响头部。 算完这三个数字，要不要投入就有了依据，也就不必再靠感觉争论。整个过程用表格软件做一次筛选加求和就够了，不需要开发介入。 如果连词表都还没建好，可以退一步用现有的商品名和分类名来估。把站内所有的商品标题拉出来，统计含特殊字母的比例，这个数字跟词表里的比例通常在同一个量级。数据不完美，但足以支撑一次要不要立项的判断，而这类判断拖着不做的代价往往更高。 ## 数据库的排序规则，到底折叠了什么、没折什么？ ## 排序规则同时管着比较和排序两件事 数据库的排序规则名字里通常带着几个后缀，标明它是否区分重音、是否区分大小写。 不区分大小写意味着查询条件会自动做折叠，你在应用层再折一次就是重复劳动。 不区分重音意味着带变音符号的字母和不带的会被当成相等，这个默认经常出乎意料，PostgreSQL文档里关于排序规则同时影响比较与排序的说明 (https://www.postgresql.org/docs/current/collation.html)值得整节读一遍。 两个不区分叠在一起，土耳其语的两个字母就在数据库层面被当成同一个了。 唯一索引在这种规则下会把两个合法的词判成冲突，插入直接失败，报错信息还看不出原因。 更隐蔽的是，同一张表上不同字段可能挂着不同的排序规则，联表查询时数据库会挑一个来用，结果取决于执行计划。这类问题在测试环境往往复现不出来，因为数据量小的时候执行计划不一样。 字段级的规则设置还有一个实际用途：把需要精确区分的那几列单独挑出来，比如商品编号、优惠码、用户名，给它们挂上区分大小写的规则。这几类值本来就不该被折叠，它们是标识符不是自然语言，混在一起用同一套规则迟早会出现两个不同编码被判成同一个的事故。 ## 排序顺序和字母表顺序是两回事 按默认规则排序，出来的是码位顺序，不是这门语言字母表的顺序。 土耳其语的字母表里，不带点的那个字母排在带点的前面，跟码位顺序正好相反。 结果是品牌列表页、分类字母导航、筛选项列表，全部排得跟当地人的预期不一样。 用户不会去投诉排序，他们只是找不到要找的那一项，然后离开。 解决办法是给排序单独指定这门语言的规则，而不是复用比较用的那一套。 这一条跟北欧三语的字母表排序差异 (https://zhangwenbao.com/nordic-seo-swedish-norwegian-danish-content-sharing-boundary.html)是同一类问题，那边是三门语言把同样三个字母排在三个不同位置，这边是同一门语言里码位顺序和字母表顺序打架。 字母导航这个组件在小语种站上值得单独验一次。它通常按硬编码的英语字母表生成按钮，本地语言多出来的那几个字母要么没有入口，要么被塞在最后。用户找不到以本地字母开头的品牌，就只能退回搜索框，而搜索框那一侧的折叠规则如果也没配对，这条路径就整个断了。 ## 缓存键和去重键最容易被忽略 页面缓存、查询缓存、幂等键，这些地方几乎都会对字符串做一次规范化再算哈希。 规范化规则一旦跟数据库那一层不一致，就会出现命中率异常和偶发的脏数据。 这类问题的表现是间歇性的，只在特定语言、特定词上出现，测试环境很难复现。 排查时先把这条链路上所有做规范化的位置列出来，通常有四到六处。 把它们统一到一个函数上，是治本的做法，也是唯一能保证以后不再复发的做法。 缓存键的另一个风险是跨语言碰撞。如果规范化把不同语言的两个词折成了同一个键，两个页面就会互相覆盖对方的缓存，表现为偶尔刷出另一门语言的内容。这类故障出现频率低、复现困难，通常拖很久才被定位，而根因往往只是缓存键里少带了一个语言标识。 ## 重定向和规范化规则，应该在哪一层加语言参数？ ## 服务器层做小写化，是最危险的一处 很多站在服务器配置里加了一条规则：把所有大写路径301跳到小写路径。 这条规则用的是字节级的转换，只认A到Z，对多字节字符要么不动，要么按错误的方式处理。 对本地字母的路径来说，它要么什么都不做，要么把百分号编码的部分改坏。 改坏之后跳到一个不存在的地址，用户看到的是404，抓取工具看到的是一串死链。 这一处的正确做法是把规则限制在纯ASCII路径上，其余的交给应用层按语言处理。 顺带说一句，如果你的站根本没有大写路径，这条规则就该删掉。为一个不存在的问题保留一条会改坏地址的规则，是典型的负资产。 顺序也很讲究。服务器层的重写规则通常在应用层之前执行，它改坏的地址应用层再也看不到原样。所以这一层的规则要尽量少、尽量保守，能在应用层做的事就别放在这里做，出了问题至少还有日志能还原现场。 ## 应用层做的时候要带上页面语言 应用层知道当前页面是什么语言，这是它相对服务器层唯一的、但也是决定性的优势。 把这个语言值传给转换函数，土耳其语页面就会走土耳其语的规则。 多语言站要注意的是取哪个语言值，页面语言、用户界面语言、内容语言可能是三个不同的东西。 正确的选择是内容语言，也就是这段文本本身是什么语言，跟界面语言无关。 这一点跟页面上语言声明该取哪个值的判断一致，可以参考国际化SEO与hreflang的完整实现清单 (https://zhangwenbao.com/international-seo-hreflang-complete-guide.html)里关于语言值与地区值分开填的那一节。 怎么把内容语言可靠地传下去，本身就是个工程问题。比较稳的做法是让页面语言在渲染入口处解析一次，之后作为上下文往下传，而不是在每一层各自去猜。W3C国际化问答中关于HTML语言声明的说明 (https://www.w3.org/International/questions/qa-html-language-declarations)里讲清了页面级和元素级两种声明的取值优先级，可以当作传参规则的依据。 ## 第三方组件里的那几处，只能绕不能改 表格软件、翻译记忆工具、外链分析工具、词频统计脚本，各自都会做一次规范化。 它们大多不给你选项，也不会告诉你用了什么规则，你只能在输入输出两端做核对。 核对办法是准备一份包含所有特殊字母的探针词表，每次工具换版本就跑一遍。 这份词表二十行足够，覆盖四个土耳其字母、德语两种形态、希腊语两种词尾形态。 跑完对照原表，哪一行变了就知道这个工具在哪一类上不可靠，可以有针对性地绕开。 这份探针表还有一个额外用处：新同事接手流水线时，让他先跑一遍，比看三页文档更快建立起对这类问题的直觉。 拼写检查类工具是另一个容易被忽略的环节。很多内容平台内置的检查器依赖开源词典，而词典对语言变体的支持参差不齐，Hunspell拼写检查引擎 (https://hunspell.github.io/)就是其中被用得最多的一个。它把一个正常词标成错误，编辑手动改掉，你的词形就在编辑环节被改坏了，而这一步根本不在任何技术清单里。 ## 母语审校清单里要加一条 母语审校通常盯的是句子读着自然不自然，很少有人让他们去看字符层。 但字符层的错误恰恰是母语者一眼就能发现、而你自己永远看不出来的那一类。 在验收清单里加一条：导航标签、按钮文案、面包屑这些全大写或首字母大写的位置，逐个看一遍。 这几个位置正好是全站最常触发大小写转换的地方，也是最容易出现怪词的地方。 加这一条几乎不增加审校成本，却能拦住绝大多数会被用户看见的错误，相关的验收方法在小语种内容的母语审校验收清单 (https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html)里有完整的表格。 还可以让审校者顺手记录他们改动的类型。如果某一类改动反复出现，那多半不是译者的问题，而是上游某个自动处理环节在持续制造它。把改动类型统计一下，往往能倒推出流水线上具体是哪一步出了错，这比让技术团队自己去找便宜得多。 ## 两小时能跑完的大小写自检清单 ## 第一步：做一次往返测试 拿这门语言的一百个常用词，各做一次转大写再转小写，跟原串逐字节对比。 回不到原串的，就是有损转换命中了。这一步不需要懂语言学，脚本十行就能写完。 德语站上会有一批词回不去，那是ß的问题，属于预期之内。 土耳其语站上如果有词回不去，那就是地区参数没传对，属于必须修的问题。 把回不去的词列出来，按首字母分组，一看就知道是哪几个字母在作怪。 这个测试的价值在于它不需要任何先验知识：你不必知道这门语言有哪些例外，测试会把它们全部指出来。往返不等，就是有损，这一条判据可以直接搬到任何一类字符串转换上去，包括转写、去变音、全半角统一。 往返测试还能顺便测出另一类问题：某些实现在处理特定字符时会抛异常或者返回空串。这类硬故障比词形改变更容易发现，但如果没人跑过测试，它也可能在生产环境里静静躺着，直到某一天有用户提交了一个含特殊字母的搜索词。把往返测试做成上线前的固定一项，是这套改动里最省力的一半。 ## 第二步：数一遍站内调用点 在代码库里搜所有转小写、转大写、折叠、去变音的调用，统计出现次数和位置。 按发生的层次归类：展示层、存储层、比较层、地址生成层。 存储层出现的每一处都要单独讨论，因为那里的有损转换会永久丢信息。 展示层的问题只影响这一次渲染，改起来便宜，优先级可以往后放。 清单做完通常会发现，真正需要动的只有三到五处，其余的都可以维持原样。 统计的时候把调用点按语言分组也很有用。如果某几门语言的页面根本不经过某条链路，那条链路上的问题就可以直接降级。范围收窄之后，需要人工审的位置常常只剩下个位数，排期的时候也更容易说清楚投入产出。 ## 第三步：核对搜索侧的两端 把站内搜索索引侧和查询侧的规范化结果各导一份，用同一批探针词对照。 两侧一致才算过，不一致的话先改查询侧，因为索引重建成本更高。 改完之后拿真实的零结果查询日志复跑一遍，看看能救回多少条。 这个数字通常比预期高，因为零结果里混着一批本来该有结果的查询。 救回来的那部分，是这次改动最容易拿去汇报的成果，也最能说服人继续投入。 零结果日志是这类改动里最好用的验收材料，因为它是唯一能直接看到用户真实输入的地方。改动上线前后各导一份，按查询词首字母分组对比，救回来的那批词通常集中在几个特殊字母上，图表画出来一目了然，比任何解释都有说服力。 ## 哪些问题不归语言层，该交给谁？ ## 域名那一半不在这里 域名不区分大小写，这是协议层的规定，跟语言无关，所以域名上不存在本文说的这些坑。 真正跟域名有关的是本地字符域名的输入和传递问题，那是另一个层面的事。 路径段区分大小写，所以本文讨论的所有问题只发生在路径、查询串和内容里。 这个边界要在团队内部说清楚，否则讨论会一直在两个层面之间来回跳。 把域名那一半从议题里摘出去，剩下的问题范围会小很多，也更容易排期。 还有一类容易混进来的议题是邮箱地址。本地字符邮箱的支持程度跟域名完全是两回事，它涉及的是另一条协议链路，RFC 8264定义的PRECIS框架 (https://www.rfc-editor.org/rfc/rfc8264)规定了这类标识符该怎么做大小写与规范化处理。放在这篇里只会把讨论拉散，识别出来交出去就好。 ## 引擎怎么处理，是引擎层的事 搜索引擎自己会做大小写归一，而且在主流语言上做得比你好，这一点不必怀疑。 你要保证的是自己产出的字符串是对的，而不是去猜引擎的归一规则。 换句话说，这一层的目标是不制造错误的词，而不是去优化引擎的匹配行为。 两者混淆的表现，是有人开始为了迎合猜测中的引擎行为去改正确的拼写。 那是本末倒置，本地用户会先于引擎发现你的页面写得不像人话。 反过来说，引擎的归一能力也不是无限的。它在有充分语料的语言上做得好，在语料稀薄的语言上未必，而这恰恰是小语种站最需要自己兜底的部分。判断办法很直接：拿两种词形各搜十次，看结果页是不是同一批，是就不用管，不是就得自己在站内补一层。 ## 变音符号那一半单独走 去变音符号和转小写经常写在同一个函数里，但它们是两个决策，应该分开评估。 去变音在有些语言上是必须的用户覆盖手段，在有些语言上是纯粹的信息损失。 这一层的判断依据是用户实际怎么输入，而不是正字法怎么规定。 相关的判断框架在希腊语用户用拉丁字母打字的覆盖问题 (https://zhangwenbao.com/greek-seo-greeklish-latin-transliteration-coverage.html)里讲得比较完整。 本文只强调一点：这两个动作绝不能捆在一个函数里，否则你永远没法单独关掉其中一个。 把这两个动作拆开还有一个附带好处：你可以分语言开关。土耳其语站关掉去变音、开着大小写的地区规则；希腊语站两个都开；德语站只在比较键上折叠、展示层一律保留原形。同一套代码三种配置，这才是多语言站该有的形态，而不是一套写死的规则跑遍全球。 ## 常见问题解答 ## 只做英语和几门西欧语言，还需要管这件事吗？ 要管的部分比想象中多。法语、西班牙语、意大利语的大小写映射确实是一一对应的，不会出现土耳其语那种方向反转，但它们都带变音符号，而去变音这一步经常跟转小写写在同一个函数里。只要那个函数是共用的，你就已经在一条会出问题的链路上了。另外只要站点将来有可能加德语，ß那一条就迟早会碰到，而那时候slug已经生成完了，改起来比现在贵得多。 ## 怎么在半小时内判断自己的站有没有中招？ 最快的办法是往返测试。挑二十个目标语言的常用词，每个词做一次转大写再转回小写，跟原串逐字节比对。回不到原串的词就是命中了有损转换。这一步不需要懂那门语言，也不需要母语者参与，写个十行的脚本就能跑完。如果全部往返成功，再去检查站内搜索的索引侧和查询侧用的是不是同一套规则，这两处覆盖了绝大多数真实故障。 ## 已经生成的那批错误slug，到底要不要改？ 先看这批地址的现状再决定。已经有外链、有收录、有稳定流量的，改动的代价通常大于收益，正确做法是保留地址、修正规则、只让新内容走新规则。完全没有流量也没有外链的，直接改并配上跳转，成本很低。真正必须改的是那些错到用户一眼能看出来的地址，比如词形已经变成另一个词或者干脆不成词的，那种地址挂在导航上会持续损害信任。 ## 数据库排序规则到底该选哪一个？ 没有一个万能选项，但有一条排除法：别为了省事在全库上挂一个不区分大小写、不区分重音的规则。那种配置会把好几类本来不同的词判成相等，唯一索引会莫名其妙地冲突，去重结果也不可信。比较稳的做法是库级用一个中性的规则，需要按语言排序的那几个字段单独指定这门语言的规则，同时把展示用的原形单独存一列，别让排序规则决定你能拿回什么数据。 ## 站内搜索应该用折叠规则还是转小写？ 索引和查询两侧都用折叠规则，展示层用原形。折叠是专门为比较设计的，它会把位置变体、大小写差异统一到同一个键上，而且结果稳定，不受运行环境的地区设置影响。转小写是给人看的，它要照顾正字法，反而不适合当比较键。两侧规则必须一致这一点比选哪一套更重要，一致但不完美的配置，也比两侧各用一套的配置好用得多。 ## 母语审校能不能发现这类问题？ 能发现一部分，但要看你给的验收范围。母语者读正文段落时对怪词非常敏感，一眼就能挑出来；可导航标签、按钮文案、面包屑、筛选项这些位置往往不在审校清单里，而它们恰恰是全大写和首字母大写最集中的地方。解决办法是在清单里单独列一行，让审校者把这几类短文本逐个扫一遍，额外成本几乎为零。 ## 这跟去掉变音符号是不是一回事？ 不是，两者的性质完全不同。去变音是一个你主动选择的覆盖策略，目的是接住那些打不出特殊字母的用户，取舍是明摆着的。大小写转换没人当成策略，它被当成格式化，所以从来没有人评估过它的取舍。真正危险的是把这两个动作写进同一个函数，那样你就再也没法单独关掉其中一个，也没法回答某个词到底是被哪一步改坏的。 ## 权威参考资料 ## 小语种内容找母语者审校，一句读着自然不能当成验收通过的判据 - URL：https://zhangwenbao.com/minor-language-native-review-acceptance-checklist.html - 分类：小语种SEO - 发布：2019-07-04 | 更新：2026-07-26 - 摘要：母语者说读着自然不是验收结论。讲清一份小语种译文要验哪四层、审校员最容易改坏哪几个词、不懂那门语言怎么用三个方法自己先跑一遍，以及抽样比例和放行阈值该怎么定。 - 关键词：内容质量,出海SEO,多语言SEO,小语种SEO > **TLDR**：摘要：母语审校最常见的交付物是一句“读起来很自然”，而这句话在验收单上什么都不是。小语种内容真正要验的是两层：语言正确性由母语者判，检索一致性由数据判，两层的结论经常互相打架。本文给出一张按错误类型分级的验收表、一份写明“哪些词不许动”的审校简报模板、三个不懂那门语言也能自己先跑一遍的自检方法，以及抽样比例与放行阈值的定法。 > 摘要：母语审校最常见的交付物是一句“读起来很自然”，而这句话在验收单上什么都不是。小语种内容真正要验的是两层：语言正确性由母语者判，检索一致性由数据判，两层的结论经常互相打架。本文给出一张按错误类型分级的验收表、一份写明“哪些词不许动”的审校简报模板、三个不懂那门语言也能自己先跑一遍的自检方法，以及抽样比例与放行阈值的定法。 ## 母语者说读着自然，为什么不能算验收通过？ ## 自然度是主观判断，落到验收单上什么都不是 把译文发给一位母语者，隔两天收到回复：读起来很自然，没什么问题。这句话听着让人放心，可它不是验收结论。 验收结论必须能被复述、能被追溯、能被下一个人重跑一遍。自然不自然，换一个人来读可能就换一个说法。 更麻烦的是，这句话没有回答任何一个你真正关心的问题：关键词还在不在标题里，术语前后一致没有，价格写法符不符合当地习惯。 审校员没有回答，是因为你没有问。你交给他的是一段文字，他就按读者的身份读了一遍。 他不知道这个页面是拿来接搜索流量的，也不知道标题里那个词是花了两周才选出来的。 验收清单存在的意义，就是把这些没说出口的期待，变成一条条能打勾的判据。 这里有个容易被忽略的连锁反应：当验收结论只有“自然”两个字时，返工的责任也就没法界定。译文上线三个月后发现某个核心词从来没出现在标题里，你回头去找审校记录，只能找到那句“读起来很自然”，谁也说不清是翻译漏了、审校放行了，还是需求本来就没提。这种账最后多半记在SEO这一侧，因为只有你在盯排名。 ## 审校员最爱改的那几个词，正好是搜索量最高的那几个 母语审校有个稳定的行为模式：他们会把重复出现的词换成同义词。 在写作训练里这是对的，同一个词连着出现五次，读感确实差。但在搜索这一侧，那五次重复往往是刻意留的。 更常见的是术语替换。审校员觉得某个词太口语、太生硬、太像翻译腔，于是换成一个他更喜欢的表达。 换掉的那个词，可能正是当地用户在搜索框里真实打出来的那个。用户的输入习惯和母语者的书面审美，本来就不是一回事。 俄语这类屈折语更容易出事，因为审校员改的常常不是词本身，而是词形。他把主格换成了间接格，读起来更顺，可这个词形和你关键词表里的那一行对不上了。 词形变化在俄语关键词研究 (https://zhangwenbao.com/russian-seo-cyrillic-cases-declension-wordstat-keyword.html)里本来就是个老问题，审校环节又给它加了一层不确定性。 保哥经手过一个卖路亚竿和渔线轮的独立站，德语站上线前请了位在慕尼黑做过多年钓具零售的母语者审稿。他把产品页里反复出现的那个品类词改成了三个不同的说法，理由是原稿读着像目录不像人话。他说得没错，可这三个说法里只有一个有真实搜索量，另外两个加起来每月不到十次。改完之后页面确实好读了，两个月后那个词的排名从第七掉到第二十四。 ## 渔具站那次改稿：读顺了，词也没了 那次事故后来复盘，问题不在审校员，在简报。 发稿的时候只写了一句“请帮忙润色，让它读起来像本地人写的”。审校员完全按这句话执行了，执行得还很好。 没有人告诉他哪些词不能动，也没有人告诉他这个页面是靠搜索进来的。 他甚至不知道有关键词表这回事，在他的认知里，这就是一份写得有点生硬的商品介绍。 返工的成本不算高，把三处改回去、重新提交索引，两周后排名慢慢回来了。真正的成本是那两个月的流量。 从那以后，交给审校员的稿子前面一律加一页说明，写清楚这个页面要接哪些搜索词、哪几个词的哪几种形态不许动。 这件事最值得记住的一点是：审校员改坏的地方，恰恰是他专业能力最强的地方。他对语言的敏感度越高，越会去修那些重复、生硬、不地道的表达，而搜索优化留下的痕迹在他眼里正好全是这三样。你不能指望靠提高审校员的水平来避免这个冲突，只能靠事先划出边界。 ## 一份小语种译文到底要验哪几层？ ## 语言正确性：拼写、语法、术语一致 这一层是母语者的主场，也是唯一一层你没法替代他的。 拼写和语法不用多说，值得单独拎出来的是术语一致性：同一个部件在整站是不是用同一个词。 小语种站最容易在这里出问题，因为不同批次的翻译常常来自不同的人，而跨市场的关键词调研 (https://zhangwenbao.com/multilingual-keyword-research-cross-cultural-localization-query-language.html)本来就会产出好几套并行的说法。 产品页叫一个名字，博客文章叫另一个名字，帮助中心又是第三个，用户和搜索引擎都会被绕晕。 术语一致性的检查不需要通读全文，导出全站的术语出现情况列一张表，肉眼扫一遍就能发现分叉。 这一层的验收判据可以写得很硬：术语表里的每个词，全站只允许一种主形态。 需要提醒的是，术语一致并不等于全文只能出现同一个词。屈折语里同一个术语必然会以多种词形出现，这是语法要求，不是错误。要求一致的是词干和词根那一层，不是字面串那一层——这个区别在后面讲变体集检查时还会再出现一次，它几乎是所有屈折语验收环节的分水岭。 ## 检索一致性：关键词位置、词形、密度 这一层母语者判不了，因为它跟语言好坏无关，跟数据有关。 要查的东西很具体：核心词在不在标题里，在不在H1里，首段前一百个字符里出现没有。 还要查词形。屈折语和黏着语里，同一个词在标题里可能以主格出现，在正文里以其他格出现，这本身没问题，但主格至少要出现一次。 密度不必卡死，只要没有出现“整篇文章里核心词一次都没有”这种极端情况就行。 这些检查全都可以脚本化，不需要懂这门语言，只要有一张关键词表和一份译文。 把它做成上线前的自动检查，比请第二位母语者复审便宜得多，也稳定得多。 检索一致性检查的另一个价值是它能反过来暴露关键词表本身的问题。如果某个词在译文里怎么都塞不进去，读起来总是别扭，多半不是译者的问题，而是这个词根本不是当地人的说法，是从英文逐词换过来的 (https://zhangwenbao.com/keyword-literal-translation-legacy-cost-non-english.html)。这时候该改的是词表不是稿子，回到关键词本地化那几个典型陷阱 (https://zhangwenbao.com/overseas-indie-keyword-localization-translation-traps-native-review.html)里对一遍就知道问题出在哪一步。 ## 本地惯例：数字、日期、货币、地址、称呼 这一层介于两者之间，母语者能判，脚本也能判一部分。 数字的千分位和小数点，德语和英语正好相反；日期的日月顺序，欧洲大陆和美国也不一样。 货币符号放前面还是后面，中间有没有空格，各个市场的习惯都不同。 地址格式的差别更大，邮编在城市名前还是后，门牌号在街名前还是后，写反了当地用户一眼就看出这是外国站。 称呼方式也算这一层：德语要不要用敬称，俄语商品页用第几人称，直接影响信任感。 这些细节单看每一条都不致命，堆在一起就是“这个站不像本地的”，转化率会给出答案。 本地惯例这一层还有个容易被漏掉的分支：页面上给用户看的那些格式要彻底本地化，但结构化数据、表单校验、数据库里存的值必须保持国际标准格式。这两件事的方向正好相反，很多团队把它们混成一件事做，结果要么用户看到一串机器格式，要么标记里的价格和日期解析失败。 ## 页面结构：标题层级、锚文本、alt、meta也审了吗？ 大多数审校流程只审正文，这是最常见的漏洞。 meta描述、图片alt、面包屑文字、按钮文案、表单提示，这些地方的译文往往来自另一个批次，质量最不稳定。 标题层级也要看：有些译者会把H2改写得很长，长到超出一个标题该有的长度。 锚文本更值得单独查一遍，屈折语里锚文本会跟着句子变形，这个问题复杂到需要单开一篇讲。 还有一类容易漏的是图片里的文字。小语种站的横幅图常常直接沿用英文版，上面的促销语一个字都没翻。 把这些位置列成一张清单交给审校员，比让他“通读全文”有效得多。 审校范围这件事最好在报价阶段就谈清楚。按字数计费的审校，默认只算正文字数，meta和alt这些零碎文本加起来可能只有几百字，却分布在几十个位置，工作量远超字数。谈的时候按页面数计费往往更合适，双方都不会在交付的时候扯皮。 ## MQM的错误类型学，搬过来还差一类 ## MQM把错误分成哪几类，SEO要哪几类 翻译质量这件事，语言服务行业已经有了成熟的框架，不必从零发明。 其中流传最广的是MQM的错误类型学 (https://themqm.org/error-types-2/typology/)，它把译文错误分成准确性、流畅性、术语、风格、本地惯例等几个大类，每类下面再细分。 准确性管的是意思有没有传达对，漏译、误译、加译都在这一类。 流畅性管的是译文本身作为一段文字是否通顺，拼写、语法、标点都算。 术语类管的是专有名词和行业词是否符合约定，本地惯例类管的就是前面说的数字日期货币格式。 这套分类的好处是它已经把“读起来不舒服”拆成了可归档的条目，审校员报错误的时候有地方可填。 直接照搬过来做SEO验收表，能覆盖大概八成的需求，剩下两成是这套框架没有考虑的——它的设计目标是评估翻译质量，而不是评估一个页面在搜索里的表现，所以它不关心某个特定的词有没有被保留在特定的位置上。 ## 加一类MQM里没有的：检索项被改动 缺的那一类，可以叫检索项被改动。 它跟准确性无关，也跟流畅性无关：审校员把一个词换成同义词，两个词意思一样，读感更好，语言质量甚至提高了。 可对搜索来说，这是一次实质性的改动，因为词表里那一行没有跟着变。 所以这一类错误的判据不是语言学的，是清单式的：改动的位置在不在锁定表里。 它有三个子类：核心词被替换、核心词的位置被移动、核心词的词形被改成变体集之外的形态。 把它加进错误类型表，审校员回报问题的时候就有了统一口径，你也能统计出这类改动一共发生了几次。 这一类的严重度定级要跟其他类分开考虑。语言类错误的严重度通常按“是否影响理解”来判，而检索项改动完全不影响理解，按传统标准会被判成轻微甚至不算错误。实际影响却可能是整个页面失去排名，所以它在验收表里应该单列一档，判据是二元的：动了就是不通过，没动就是通过，没有中间态。 ## 每类错误配一个严重度，严重度决定放不放行 有了类型还不够，还得有严重度，否则拼写错一个字母和整段漏译会被记成同一件事。 常见的做法是分三档：严重、中等、轻微，各自给一个权重。 严重的定义要写具体：意思反了、价格写错了、法律相关表述有问题，这些都属于必须返工。 中等的是影响体验但不影响交易，比如某处术语不一致、某个句子拗口。 轻微的是不影响任何事的洁癖项，比如两个空格、标点风格不统一。 放行判据由严重度加权后的错误密度决定，而不是由错误总数决定。 严重度的定级最好由两边共同确认一次，而不是检索这一侧单方面写死。审校员对哪类错误在当地读者眼里更刺眼是有直觉的，把这份直觉吸收进权重表，后面他报错误的时候才不会觉得这套标准是外行拍出来的。 错误类型 | 谁来判 | 严重度上限 | 放行判据 | 准确性（漏译误译） | 母语者 | 严重 | 零严重项 | 流畅性（语法拼写） | 母语者 | 中等 | 密度低于阈值 | 术语一致 | 母语者＋脚本 | 中等 | 术语表零分叉 | 本地惯例（数字日期货币） | 母语者＋脚本 | 中等 | 零严重项 | 风格与语气 | 母语者 | 轻微 | 不卡放行 | 检索项被改动 | 脚本 | 单列 | 零改动，二元判定 | ## 不许动的词该怎么在稿子里标出来？ ## 术语锁定表：词形、位置、出现次数 锁定表是整套验收清单里最该先做的一张，它把“哪些词不许动”从口头约定变成文件。 每一行至少要有四个字段：词、允许的词形、必须出现的位置、最少出现次数。 词形这一列在屈折语里不能只填一个词，要填一组，后面会专门讲怎么生成这一组。 位置这一列填的是标题、H1、首段、图片alt这类槽位名，不填具体行号，因为稿子改动之后行号就废了。 次数这一列填最小值就够，不必设上限，上限交给审校员的语感去把握。 这张表同时也是交给翻译的输入，翻译和审校拿到的是同一份，两边不会打架。 锁定表的行数要克制。见过一张锁进去四十多个词的表，审校员看完直接回复说这样没法改，因为句子里几乎每个实词都被锁了。合理的量级是每个页面三到五个词，全站共用的品牌词和品类词另算。锁得越多，审校员越倾向于整体放弃修改，最后拿回来的是一份没人改过的稿子。 ## 标记方式：注释、色块，还是单独一张表 标记方式看着是小事，实际决定了审校员会不会真的照做。 直接在正文里加高亮色块最直观，但会干扰阅读，审校员判断流畅度的时候会受影响。 用文档批注的方式标，好处是不动正文，坏处是批注多了以后视线来回跳。 单独给一张表，正文保持干净，审校员改完之后自己对照一遍，这种方式在实践中返工率最低。 如果内容管线本身就在CMS里跑，还可以在编辑器里做成锁定字段，物理上禁止修改。 不管用哪种，都要在简报第一段写清楚锁定表在哪里，别让人翻半天找不到。 还有一种低成本做法值得一提：把锁定词的清单放在译文文件的最顶端，用一段醒目的说明包起来，审校员打开文件的第一眼就能看见。听着简陋，可它的执行率比藏在共享盘另一个目录里的精美表格高出一大截。工具再好，也敌不过“打开就在眼前”。 ## 屈折语的“不许动”要写成变体集，不是写成一个词 这一条是小语种特有的，英文站根本不会遇到。 你锁定了一个俄语名词的主格形态，审校员在句子里把它改成了间接格，这是语法要求，他没得选。 如果锁定表只写了主格，你会判他违规；如果他为了不违规而保留主格，句子就成了病句。 正确的写法是把这个词的全部合法词形列出来，作为一个集合去锁。 集合可以用词干工具生成，也可以让翻译在交稿时顺手列出来，成本都不高。 锁定的语义因此变成：这个词的任意合法形态都算通过，换成另一个词才算违规。 生成变体集有个偷懒但有效的办法：拿Snowball的词干算法 (https://snowballstem.org/algorithms/)把稿子和词表都跑一遍，比对词干而不是比对原词。词干相同就认为是同一个词的不同形态，词干不同就是被换了词。这个方法对词干本身也会变的芬兰语 (https://zhangwenbao.com/finnish-seo-fifteen-cases-consonant-gradation-keyword.html)不够可靠，但对俄语德语这类词干相对稳定的语言足够用了。 ## 不懂这门语言，怎么自己先验一遍？ ## 关键词位置校验：标题、H1、首段、URL各查一次 这是三个方法里最简单也最该先做的一个，不需要任何语言能力。 把关键词表里的词逐个在译文的指定位置里查一遍，命中就打勾，没命中就标红。 标题和H1必须命中，首段建议命中，URL看情况，正文至少命中一次。 查的时候要注意大小写和变音符号，很多语言的字母有多套码位写法，字符串比对会漏。 做这件事的正确姿势是写个小脚本，把结果输出成一张表，每次交稿跑一遍。 它抓不住的是用词好不好，抓得住的是词有没有丢，而丢词恰恰是审校环节最常见的事故。 这个检查还有个附带好处：它会顺手抓出译者的一类习惯性失误——把标题翻译得太自由。译者写标题的时候容易发挥，尤其是原文标题本身就带修辞的时候。原文那个精心挑过的核心词，翻完之后经常就不见了，取而代之的是一个更漂亮但没人搜的说法。 ## 回译比对怎么用才不被机器翻译带偏 回译就是把译文再翻回中文或英文，看看跟原文差多少。 它的正确用法是找差异，不是判质量。回译读着别扭不代表译文有问题，机器翻译本身就会带来失真。 要看的是意思层面的偏移：数字变了没有，否定词丢了没有，条件从句的范围有没有扩大。 这些是回译能可靠暴露的，因为它们在任何语言里都是硬信息，不依赖语感。 要避免的用法是拿回译的流畅度去质疑审校员，那会迅速毁掉合作关系。 把回译结果和原文并排放，只标出数字与否定词的差异，其余不看，效率最高。 机器翻译的质量本身也是可以量化的，业内用WMT的质量评估任务 (https://aclanthology.org/W18-6451/)这类公开评测来横向比较不同系统的表现。你不需要读懂论文里的方法，但知道有这么一条基线有个实际用处：当你用来做回译的那个引擎在某个语向上表现本来就差，回译出来的偏差有多少是译文的、有多少是引擎的，心里得有数。这也是机器翻译能不能直接发布 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)那条线的判断依据之一。 ## 词形变体集检查：拿词干工具跑一遍 第三个方法专治屈折语和黏着语，是前两个方法都覆盖不到的盲区。 做法是把译文分词后逐个取词干，再跟关键词表的词干比对。 比对结果分三种：词干命中且形态在集合内、词干命中但形态在集合外、词干未命中。 第二种要人工看一眼，多半是语法需要，属于正常；第三种基本可以判定为换词。 词干工具对不同语言的支持度差别很大，俄语德语成熟，芬兰语匈牙利语这类要打折扣。 支持度不够的语言，退而求其次用前缀比对，取词的前若干个字符做粗匹配也能抓到大部分情况。 这里有个反直觉的地方：词干比对的假阳性比假阴性更值得容忍。宁可让脚本多报几个疑似换词、你再人工看一眼，也不要为了减少噪音把阈值调松。审校环节的换词一旦漏过去就直接上线了，而多看几行的成本只是几分钟。 ## 三个方法各能抓住什么、抓不住什么 三个方法互补，谁也替代不了谁，用之前得知道各自的边界。 位置校验抓词有没有丢，抓不住词用得对不对，也抓不住句子通不通。 回译抓意思偏移，抓不住风格和语气，对成语和双关基本无效。 词形检查抓换词，抓不住整句改写，因为改写之后词干可能还在。 三个都通过的稿子，仍然可能是一份读起来很生硬的译文，语言质量还得靠人。 反过来，母语者说好的稿子，这三项也可能全挂，所以两边都要跑。 这三项自检真正的价值不在于替代人，而在于把不确定性收进一个可控的范围。跑完之后你能确定的是词没丢、意思没跑偏、没被换成同义词，剩下的模糊地带就只有语言质量这一块，正好是母语者唯一不可替代的那部分。 自检方法 | 能抓住 | 抓不住 | 要什么工具 | 关键词位置校验 | 核心词丢失、位置缺失 | 用词是否地道 | 关键词表＋文本查找 | 回译比对 | 数字、否定、范围偏移 | 风格语气、修辞 | 任一机器翻译引擎 | 词形变体集检查 | 同义词替换、词干改动 | 整句改写 | 词干算法或前缀匹配 | ## 审校员怎么挑，母语者这三个字够不够？ ## 母语者、目标市场居住者、行业从业者是三件事 招审校员的时候，“母语者”这三个字被当成了唯一门槛，这是个很粗的筛子。 一个在国外生活了十五年的母语者，母语能力没问题，但他对当地当下的说法可能已经脱节。 用词是会变的，尤其是电商品类词和网络用语，五年不在当地就足以掉队。 行业熟悉度是第三个维度。钓具、母婴、工业耗材，每个行业都有一套外人不用的词。 三个维度都满足的人不好找，也不便宜，所以要按页面类型分配：产品页优先给懂行的，博客文章可以放宽。 如果只能满足两个，优先保住“在当地生活”和“懂这个行业”，纯语言能力可以靠工具补一部分。 三个维度的优先级还跟品类有关。标准化程度高的品类，行业词就那么几十个，术语表补得住，权重可以给到在当地生活这一项；参数复杂的工业品或者医疗相关品类反过来，行业熟悉度要往上提，因为一个参数词译错的代价远大于读感生硬。 维度 | 缺了会怎样 | 能不能靠工具补 | 母语能力 | 语法拼写出错、读感生硬 | 部分可补（拼写检查） | 在目标市场生活 | 用词过时、不知当下说法 | 难补 | 熟悉这个行业 | 专业词乱译、参数写错 | 可用术语表部分补 | ## 五道题的试稿：能筛掉大半 面试聊不出什么，发一份试稿最有效，而且不必长，五道题就够。 第一题给一段带明显术语错误的译文，看他能不能挑出来。 第二题给一段读着顺但漏了一个否定词的译文，测的是他会不会对着原文核。 第三题给一句锁定了核心词的句子，看他会不会去改那个词，这一题筛掉的人最多。 第四题给一段数字日期格式全按英文写法的文本，看他有没有本地惯例的敏感度。 第五题直接问：如果你觉得某个不许动的词很别扭，你会怎么处理？答“直接改掉”的直接淘汰，答“改周围的句子让它自然”的就是要找的人。 第五题的答案分布很能说明问题。大部分候选人会说“我会先改了再跟你说”，少数会说“我会在批注里提出来但不动”，极少数会说“我会改周围的句子让这个词嵌得自然一些”。第三种人最难得，因为他已经理解了约束的存在意义，而不只是服从约束。 ## 长期合作比单次外包便宜在哪 审校这件事的边际成本随合作次数下降得很快，比大多数外包环节都快。 第一次要解释产品、解释术语、解释哪些词不能动，沟通成本比审校本身还高。 第三次之后，他自己就知道你的品类词是哪几个，主动会问某个新词该怎么定。 他还会开始反过来提建议，比如某个词当地已经没人用了，该换成什么。 这类信息买不到，只有长期合作的审校员会主动给。 所以哪怕单次报价贵一点，也尽量固定同一个人，这笔账两三次就能算回来。 固定审校员还有个隐性收益：术语表会自己长出来。每次争议、每次他提的建议、每次你解释为什么某个词必须保留，这些都能沉淀成表里的一行。半年之后这张表的价值远超它的制作成本，新来的翻译看一遍就能上手，这本身就是本地化生产线 (https://zhangwenbao.com/multilingual-content-localization-production-pipeline-vs-translation.html)能跑起来的前提。 ## 审校简报写不清楚，返工的账最后记在你头上 ## 目标读者与页面用途要写在最前面 简报第一段回答一个问题：这个页面是给谁看的，看了要干什么。 是给已经知道品牌的人看的，还是给刚开始比价的人看的，语气完全不同。 是要促成下单，还是要建立信任，用词的分寸也不一样。 把这句话写清楚，审校员的很多判断就不用你逐条交代了。 顺带写上这个页面的流量来源以搜索为主，他就知道有些重复不是失误。 这一段不用长，三五句话，但它决定了后面所有细则会不会被正确理解。 页面用途这件事还影响一个具体判断：允不允许审校员调整段落顺序和拆分句子。信息型的长文可以放开，让他按当地读者的阅读习惯重组；而结构固定的产品页最好锁死结构，因为那些位置往往对应着模板字段，改了会导致上线时对不上号。 ## 不许动的清单与可改的边界 清单前面已经说过，这里要补的是另一半：哪些地方欢迎他大改。 只说不许动，审校员会保守到什么都不敢改，那你请他来就没意义了。 明确告诉他：除了锁定表里的词，其余表达全部可以按当地习惯重写。 句子结构、段落顺序、语气分寸，这些都归他，而且改得越多越好。 这样划清边界之后，他的专业能力才有发挥空间，你也拿到了真正本地化的文字。 一份好的简报读完给人的感觉应该是：限制很少，但那几条很硬。 这里有个实际的分寸问题：可改边界给得太宽，收回来的稿子可能面目全非，跟原文结构对不上，上线时要重新排版。所以放开行文的同时，最好把段落数量和小标题位置固定住，让他在每个段落内部自由发挥。结构不变、内容随便改，这个组合最省事。 ## 交付格式：改在哪、怎么标、争议怎么记 交付格式定不清楚，收回来的东西五花八门，合并的时候要人命。 统一要求：直接在原文件上修改，开启修订记录，不要另存新文件。 凡是他觉得该改但被锁定表挡住的地方，用批注写下来，不动正文。 这些批注是最有价值的部分，它们会变成下一版术语表的候选条目。 再要求他在文件末尾写三五句总结：整体感觉、最大的问题、最不确定的地方。 这段总结比任何评分表都能反映稿子的真实状况，也是判断这位审校员靠不靠谱的依据。 批注的价值经常被低估。审校员写下的每一条被锁定表挡住的意见，都是当地读者视角的第一手反馈，而且是免费的。见过一份稿子的批注里提到某个品类词在当地更多指向二手市场，这条信息后来直接改变了那个页面的选词方向，价值远超那次审校的费用。 ## 全部审一遍还是抽样审？抽多少才够？ ## 分层抽样：按页面类型和流量价值分层 全站审一遍最保险，也最烧钱，页面上千之后基本不现实。 分层抽样的思路是：不同页面的出错代价不一样，抽样比例就该不一样。 交易相关的页面出错代价最高，价格写错、退换货条款译反了都是真金白银。 这一层建议全量审，哪怕它只占全站页面的一小部分。 流量最高的那批内容页排第二层，按较高比例抽，因为它们的错误影响面最大。 长尾内容页是第三层，比例可以压得很低，出了问题再补审也来得及。 分层的依据要用真实数据，不要用页面模板类型。有些看起来是长尾内容的页面实际上贡献了相当比例的自然流量，也有些产品页从上线起就没什么访问。按流量和转化数据分层、每个季度重新划一次，比按模板一刀切准确得多。 页面层级 | 典型页面 | 抽样比例 | 不通过怎么办 | 交易层 | 结算、条款、退换货、价格 | 全量 | 逐条返工，不放行 | 核心流量层 | 热门品类页、主力产品页 | 较高比例 | 整批退回重审 | 长尾层 | 长尾内容、旧文章 | 低比例 | 抽中的改，其余排期 | ## 错误密度阈值怎么定 抽样之后要有判据，否则抽了也不知道算不算通过。 常用的判据是错误密度：加权错误分数除以字数，得到一个可比的数字。 阈值不必参考行业标准，用自己的历史数据定更实际。 做法是把前三批审校结果的密度算出来，取中位数当基线，比基线差一截的就是不合格。 第一次没有历史数据的时候，可以先定一个宽松值跑起来，两三批之后再收紧。 重要的是这个数字要写进合同或者协作约定里，让双方事先知道判据。 阈值还要按语言分别设定，不能全站一个数。译入语和源语言的距离越远，同样水平的译者产生的错误密度天然越高。拿德语的基线去卡芬兰语或者土耳其语，会得到一堆假不合格；反过来拿最难那门语言的基线去卡全站，等于对简单语向没有要求。 ## 抽样不过关就退回全量，退回规则要写死 抽样的意义在于它有一条明确的失败路径，否则抽样就成了走过场。 规则很简单：抽中的样本不通过，这一整批全部退回重审。 这条规则要在派活之前就讲明白，让承接方知道糊弄的代价。 它的威慑力比事后扣钱大得多，因为返工的是他自己的时间。 同时也要给一次申诉机会：如果他认为判定有误，可以逐条说明。 争议条目单独拎出来，请第三个人看，这种情况一年不会有几次。 退回规则要写死到什么程度？连“这一批”的边界都得事先定义：是按交付批次算，按页面类型算，还是按提交时间窗算。定义模糊的时候，承接方会自然而然地把不合格样本单独摘出来，说这一个是特例、其余没问题。批次边界写清楚，这条路就堵上了。 ## 第一批全量、后面转抽样的过渡节奏 新合作的第一批不要抽样，全量审，这笔钱省不得。 第一批的作用不只是把稿子改对，更是校准双方对质量的理解。 第二批可以降到较高比例的抽样，同时观察错误密度有没有下降。 连续两批达标之后，转到常规抽样比例，进入稳定状态。 如果中途换人或者换了内容类型，节奏要重新走一遍，别嫌麻烦。 这套节奏跟新供应商的磨合周期是一回事，把它写成流程，谁来接手都不会乱。 过渡节奏里最容易被跳过的是观察错误密度有没有下降这一步。第一批全量审出的问题如果在第二批原样重现，说明反馈没有回流到翻译那一侧，这时候不该继续往抽样走，而该回头看流程：审校意见有没有真的传回给译者，术语表有没有更新。 ## 审校意见跟检索要求打架时听谁的？ ## 三档裁决规则：位置优先于词形，词形优先于行文 冲突一定会发生，事先定好谁优先，比每次现场吵架效率高。 第一档是位置：核心词必须出现在标题和H1里，这一条不让步。 第二档是词形：允许在变体集内变化，超出集合要走申报。 第三档是行文：句子怎么组织、段落怎么排，全部让给审校员。 三档从上到下，上面的赢下面的，规则简单到不需要讨论。 写进简报，双方各留一份，执行起来几乎不产生争议。 三档规则能落地的前提是第一档划得足够窄。如果把核心词必须出现扩大到正文每个小标题、每张图的alt，第一档就变成一张长长的清单，审校员会觉得手脚被绑住。真正不能让步的位置其实只有标题和H1两处，其余全部下放，规则才有人执行。 档位 | 管什么 | 冲突时 | 例外通道 | 第一档 位置 | 核心词在标题、H1的出现 | 检索要求赢 | 无 | 第二档 词形 | 变体集内的形态变化 | 审校员可自主 | 超集合需申报 | 第三档 行文 | 句式、段落、语气 | 审校员赢 | 无 | ## 哪些情况必须让步给审校员 有三种情况，检索这一侧应该主动认输。 第一种是锁定的词在当地已经带有负面含义或者歧义，硬留下去伤的是品牌。 第二种是保留那个词会让句子在语法上无法成立，尤其是格与介词搭配冲突的时候。 第三种是法律或者行业合规要求必须用某个特定表述，这没得商量。 遇到这三种，正确做法是改词表不是改稿子，让搜索这一侧去找替代词。 能识别这三种情况的审校员，本身就值得长期合作。 还有一种边缘情况值得单说：审校员坚持某个说法本地没人用，而工具里那个词确实有搜索量。这时两边可能都对——有量的那个词也许来自邻国市场或者海外侨民，本地人真的不这么说。工具数据在小语种里本来就不可靠 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)，遇到这种分歧，把两个词都保留在不同页面上跑一段时间，让数据说话。 ## 争议记录会变成下一版的术语表 每次冲突都记下来，三个月之后这份记录的价值会超出预期。 记录只要三列：争议的词、双方理由、最终决定。 翻一遍就知道哪些类型的冲突反复出现，那些多半是词表本身的问题。 把结论固化进术语表，同类争议就不会再来第二次。 新审校员入职的时候，这份记录比任何培训文档都管用。 它也是向内部解释“为什么这个词必须这么写”的最好材料。 记录的形式越简单越可能被坚持下来。一张共享表格，每次审校完顺手补三五行，比要求填写结构化的争议报告有效得多。半年后回头看，这张表里最有价值的往往不是结论本身，而是审校员写下的那句理由，它经常指向一个你根本不知道的当地使用习惯。 ## 这套验收清单怎么接进现有的内容管线？ ## 卡在哪个环节：翻译后、上线前，还是上线后 验收环节放的位置不同，成本差好几倍。 放在翻译交付之后、进CMS之前，改动成本最低，只动文本文件。 放在进了CMS之后、上线之前，成本中等，要在后台逐个页面改。 放在上线之后，成本最高，因为还要重新提交索引、等待重新抓取。 所以默认位置是第一个，只有那些必须在真实页面上才能看出的问题才留到第二道。 第三道只做抽查，用来发现流程漏洞，不承担把关职责。 把三道关的职责分清楚有个附带效果：谁都不用做重复劳动。第一道管文本，第二道管页面上的呈现（截断、换行、按钮文字放不下），第三道管上线后的真实表现。见过团队把三道关都做成“通读一遍”，结果同一份稿子被三个人各读了一遍，还是漏掉了按钮文字被截断这种只有在真实页面上才看得见的问题。 ## 谁签字，返工算谁的 流程里最容易含糊的就是签字权，含糊的结果是出了事没人负责。 建议把签字权拆成两个：语言质量由审校员签，检索一致性由SEO这一侧签。 两个签字都齐了才算通过，缺一个就不上线。 返工责任跟着签字走：语言问题算审校，词丢了算SEO没查出来。 这么分看着严格，实际是在保护双方，因为责任边界清楚了就没人背黑锅。 推行的时候阻力主要来自内容团队，觉得多了一道手续，跑两轮之后没人再提。 两个签字权分开还有一个副作用要提前想到：两边意见不一致、稿子卡住的时候，得有人拍板。这个角色不该是签字的任何一方，而应该是对这个市场整体结果负责的那个人。把升级路径写进流程，卡住的稿子才不会在两个人之间来回传三天。 ## 六步落地路线 把前面的东西压成一条可以直接执行的路线，六步。 第一步，把每个页面的核心词整理成锁定表，写清词形集合与必须出现的位置。 第二步，写一页审校简报模板，包含目标读者、锁定表位置、可改边界、交付格式。 第三步，写三个自检脚本：位置校验、词干比对、格式检查，接进交稿流程。 第四步，用五道题的试稿筛审校员，选定后先跑一批全量。 第五步，跑满两批之后定错误密度基线，转入分层抽样。 第六步，把争议记录每季度并进术语表，同时回头修一次关键词表。 六步跑完大概需要一个季度，前两步最费时间也最值得投入。真正的分水岭在第三步：自检脚本一旦跑起来，你对译文质量的判断就从“感觉还行”变成了一组可比的数字，后面所有决策都建立在这组数字上。没有它，剩下三步都只是把主观判断包装得更正式一点而已。 ## 常见问题解答 ## 只有一位母语者可用，语言正确性和检索一致性都靠他行不行？ 可以，但要把两件事分两次做，不要混在一遍里。第一遍请他纯粹按读者身份读，只提语言问题，不给他看关键词表；第二遍再给他锁定表，让他核对指定的词有没有被自己改掉。混在一起做的时候，人会不自觉地被约束带偏，语言判断的独立性就没了。两遍之间隔一天效果更好。 ## 关键词表里的词在译文里怎么放都别扭，是不是必须硬塞进去？ 不必。别扭到审校员反复提意见的词，多半不是当地人的真实说法，而是从英文直译或者工具里抓来的低质量候选。正确的处理是回到关键词研究那一步，找当地人真正会打出来的表达重新验证一次搜索量。硬塞进去的结果通常是两头落空：读者觉得生硬，搜索这边也没换来多少流量。 ## 审校员能不能顺便把meta描述和图片alt也审了？ 应该审，而且要在派活的时候就明确列进范围。这些字段的译文往往来自不同批次，质量最不稳定，却直接影响搜索结果里的呈现。麻烦在于它们零散地分布在几十个位置，按字数计费会让审校员觉得亏，所以这部分建议单独按页面数计价，或者干脆打包进页面单价里，双方都省心。 ## 回译比对用免费的机器翻译够不够？ 够用，因为回译的目标是找数字、否定词、条件范围这类硬信息的偏移，不是判断文笔。免费引擎在这些硬信息上的还原度已经足够。要注意的是别用同一家引擎既做翻译又做回译，那样引擎自己的系统性偏差会被抵消掉，看起来一切正常。换一家引擎做回译，暴露问题的能力明显更强。 ## 词干工具对我要做的那门语言支持很差，还有别的办法吗？ 有两个退路。一是前缀匹配，取词的前若干个字符做粗比对，对大多数屈折语能抓到七八成的换词情况；二是让翻译在交稿时顺手把每个锁定词实际用到的形态列一张表，成本很低，还顺便留下了变体集。两个办法可以叠加用。真正需要精确词干的场景其实不多，绝大多数时候你只是想知道“这个词还在不在”。 ## 抽样比例定多少才算合理？ 没有放之四海的数字，但有个可操作的定法：从一个偏保守的比例起步，连续跑两三批，观察抽中样本的错误密度。如果每批都远低于阈值，说明比例可以往下调；如果时不时踩线，就维持不动。比例本身是结果不是前提，用数据反推比拍脑袋定一个数字可靠得多。交易相关的页面永远是例外，不参与这个计算，一律全量。 ## 这套流程会不会把审校员逼走？ 会不会取决于限制的密度。锁定三五个词、说清楚其余全部放开，绝大多数审校员不会有意见，反而觉得需求清晰好干活。真正会把人逼走的是另一种做法：锁了几十个词，还要求逐条说明修改理由，那等于让他做校对不做审校，专业的人不愿意接这种活。规则要硬，但要少。 ## 权威参考资料 ## 用户搜的那个短词你的词典里查不到，母语审校还会把它改回全称 - URL：https://zhangwenbao.com/minor-language-clipped-short-forms-keyword-coverage.html - 分类：小语种SEO - 发布：2019-06-11 | 更新：2026-07-28 - 摘要：日语把スマートフォン削成スマホ，德语把Universität削成Uni，这些形态词典查不到、术语表不收、审校还会改回去。讲清削短的触发条件、关键词工具为什么归并掉它、内容链路上哪三道关卡把它筛掉，以及标题、面包屑与结构化数据各放哪个形态。 - 关键词：关键词研究,出海SEO,多语言SEO,小语种SEO > **TLDR**：摘要：每门语言都有一批被削短的常用词，日语把スマートフォン削成スマホ，德语把Universität削成Uni。这些形态在词典里查不到，在术语表里没有位置，母语审校还会主动把它们改回全称，可它们恰恰是当地人真正打进搜索框的那一个。本文拆开削短的规律、把它筛掉的三道关卡，以及一份两小时能跑完的盘点流程。 > 摘要：每门语言都有一批被削短的常用词，日语把スマートフォン削成スマホ，德语把Universität削成Uni。这些形态在词典里查不到，在术语表里没有位置，母语审校还会主动把它们改回全称，可它们恰恰是当地人真正打进搜索框的那一个。本文拆开削短的规律、把它筛掉的三道关卡，以及一份两小时能跑完的盘点流程。 ## 为什么用户打进搜索框的词，比你页面上写的短一截？ ## 搜索框里的词比文档里的词短，这不是巧合 把任何一门语言的搜索日志和它的官方文案放在一起看，会发现同一个概念在两边的长度不一样。 日志那边总是更短。短得不是一点点，常常是六七个音节削到三四个。 这件事在英语站上很难被注意到，因为英语的常用名词本来就短，削不削差别有限。 换到德语、日语、俄语、芬兰语这些构词能力强的语言上，落差立刻显形。 输入成本是这条规律背后的机制。用户打字要花力气，越常打的词越会被磨短。 这条磨损过程是持续发生的，而且只朝一个方向。一个词一旦被削短并且被大量使用，短形式就会反过来成为默认，全称退回到正式文书里去，两者的使用场景从此分离。你的页面文案通常写在正式文书那一侧，而搜索发生在另一侧。 一个能立刻感受到落差的做法是，把你的产品文案和一个月的搜索日志各取一百条并排放在两列里，只看长度这一项，两列的差别不需要懂那门语言也能一眼看出来，这比任何解释都直观。 ## 一个真实的落差：全称页面卡在第三页 保哥手上有个卖3C配件的客户，德语站上做移动电源和手机壳。 页面标题写的是完整的产品类目名，商品名、面包屑、分类页三处口径统一得很漂亮。 问题是搜索结果里排在前面的几家，标题写的都是那个短了一截的形态。 这个客户的页面并没有排到很后，但一直卡在第三页，怎么加外链都上不来。 换词之后两周，同一个页面进了第一页。什么都没改，只把标题里的那个词换成了当地人常打的写法。 这件事最容易被误判成排名问题，接着团队就会去查抓取、查内链、查外链，一路查下去什么都查不出来，因为链路的每一环都是好的，坏掉的是最开头那一步——目标词本身选错了，后面所有的优化都在给一个没什么人搜的词加码。 事后复盘的时候团队问得最多的一句是，为什么没有人早点发现。答案是这条链路上从来没有一个环节的职责是回过头去质疑目标词本身，所有人都默认那一步在上游已经做对了。 ## 短形式不是口语，它是另一个词条 很多团队第一反应是把短形式归到口语里，然后按口语的规矩处理，也就是不用。 这个归类是错的。口语指的是语体，短形式指的是词形，两件事没有必然关系。 德语的Akku在技术手册里照样出现，它不是俚语，是这个概念的通用名。 日语的スマホ会印在运营商的官方套餐页上，也会出现在家电卖场的价签上。 把它当口语，等于替语言做了一个它自己没做的判断，代价是整块搜索量。 更准确的说法是，全称和短形式是同一个概念的两个词条，各自有各自的使用场合和搜索量分布。它们的关系更接近同义词而不是正式与非正式的关系，处理办法也应该照同义词的办法来，也就是两个都要覆盖，而不是二选一。 还有一个更实际的理由：短形式的竞争度普遍低于全称。写文案的人偏好完整表达，所以同行的页面也大多用全称，短形式那一侧的标题竞争反而稀疏，这是少见的高搜索量低竞争组合。 ## 保哥的习惯：先翻客服记录，再翻词库 做一门新语言的选词，保哥的第一站不是关键词工具，是客服的聊天记录。 原因很简单，客服记录是唯一一份没有经过任何编辑加工的本地语料。 那里面的写法是用户自己敲出来的，没有人替他改成规范形态。 站内搜索日志是第二好的来源，如果站上有搜索框的话。 广告后台的搜索词报告排第三，它至少是真实查询，只是被系统做过一轮归并。 这三份材料的共同特点是，它们记录的是用户的输入行为而不是编辑的产出行为。而你手上其余全部材料——产品文档、翻译记忆、术语表、竞品页面——记录的都是产出行为。前者才是搜索的真值，可它在多数团队的选词流程里连一个位置都没有。相关的取数办法可以参考小语种关键词工具返回零时的补数据方法 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)。 还有一份材料值得翻，就是退货和差评里的描述。用户在情绪上来的时候写得最口语，也最接近他平时打字的方式，这份语料的规范化程度比客服记录还低，正好补上另一个角度。 ## 哪些词会被削短，能不能提前算出来？ ## 高频乘长音节等于必被削短 削短不是随机发生的，它有一个相当稳的触发条件。 一个词同时满足两个条件就几乎一定会被削：用得足够频繁，读起来足够长。 只满足其中一条不会。冷僻的长词没人削，因为削它省下的力气不值得记一个新形态。 常用的短词也不会，因为已经没有可削的余地了。 所以真正的候选池比你想的小得多，一个品类里通常只有十来个词。 这个判据的好处是它可以在没有任何数据的情况下先跑一遍。拿你的品类词表出来，把使用频率高且音节数在四个以上的词圈出来，这一小批就是需要重点核查的对象，其余的可以先放着。对于工具返回零数据的语言，这几乎是唯一能提前收敛范围的办法。 把这条判据反过来用也成立：如果一个词又长又常用，而你在日志里找不到任何短形式，那多半不是这门语言不削短，是你手上的日志覆盖面不够，该去换一份语料再看一遍。 ## 音节数是最好用的那把筛子 音节数比字母数好用，因为削短是按发音单位切的，不是按字母切的。 德语的Universität是五个音节，削成Uni是两个，正好落在最省力的区间。 日语按拍数算更准，スマートフォン是七拍，スマホ是三拍。 芬兰语的复合词经常十个音节以上，那门语言的削短更多靠拆而不是靠截。 不同语言的落点不同，但四个音节以上开始出现削短压力这条大致通用。 实际操作时不需要精确数音节，用一个粗糙的近似就够——把词读一遍，读起来费劲的就进候选池。这类判断母语同事一秒钟能给答案，而你自己拿工具算半天也未必更准。芬兰语这种构词能力极强的语言可以参考芬兰语十五个格与词干交替的处理办法 (https://zhangwenbao.com/finnish-seo-fifteen-cases-consonant-gradation-keyword.html)。 需要跨语言统一口径的时候，Universal Dependencies的通用词性标签表 (https://universaldependencies.org/u/pos/)可以当分列依据，把名词、专有名词和缩略形分开统计，几门语言的表就能横向对齐。 ## 削完之后的形态不是随机的 同一个词在同一门语言里，几乎只会削出一种被广泛接受的形态。 不会出现三四种短形式并存的局面，语言会自己收敛到一个。 这一点对做词表是好消息，意味着你不需要覆盖一堆变体。 但要小心跨市场的情况，同一门语言在两个国家可能收敛到不同的形态。 这种时候两个形态都得进表，处理逻辑跟地区词汇差异是一样的。 削短的落点通常在词的前半段，因为人是从前往后听的，前半段的辨识度更高。这条规律有例外，但足够你在没有语料的时候先猜一个形态出来去验证，比从零开始盲搜要快得多。市场之间的差异处理可以参考同一门语言两个市场的关键词与落地页拆分 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)。 还有一类容易被忽略的形态是把复合词的后半段整个丢掉。这类削短在德语和芬兰语里很常见，结果是一个原本意思很具体的词变得宽泛，搜索意图也随之变宽，需要单独判断值不值得接。 ## 日语的四拍截短到底是怎么一回事？ ## 四拍是日语外来语最稳的落点 日语从英语借进来的词往往很长，六拍七拍是常态。 这些词进入日常使用之后，绝大多数会被削到四拍或者三拍。 パーソナルコンピュータ削成パソコン，是两个成分各取前两拍。 リモートコントロール削成リモコン，用的是同一套办法。 デジタルカメラ削成デジカメ，エアコンディショナー削成エアコン，规律一眼可见。 这种各取前两拍的做法在日语里是一条相当有生产力的构词规则，新借进来的词会被自动套用。这意味着你今年新上的产品品类词，明年可能就有一个大家都在用的短形式，而这个形态不会出现在任何一本你能买到的词典里。日语三套书写系统之间的选择问题另见日语汉字、平假名与片假名的关键词写法 (https://zhangwenbao.com/japanese-seo-hiragana-katakana-kanji-keyword-notation.html)。 判断一个新词有没有短形式，最快的检验是去当地的电商平台搜一次，看类目名和筛选项写的是哪一个形态。平台的词是被点击数据反复优化过的，它比任何词典都更接近真实使用。 ## 从スマートフォン到スマホ，中间丢掉了什么 スマホ不是各取前两拍削出来的，它取的是前两拍加上后半段的一拍。 这说明规则有弹性，实际落点还要看读起来顺不顺。 对做SEO的人来说，规则的细节不重要，重要的是短形式已经取代了全称。 在这个例子里，全称スマートフォン仍然大量出现在规格页和运营商公告里。 而搜索框那一侧，短形式的占比高到让全称看起来像个书面词。 更值得注意的是复合用法。スマホケース、スマホスタンド、スマホリング这一整族词全部以短形式打头，你如果坚持用全称写商品名，就等于把这一整族长尾全部让出去了，而这一族恰恰是配件类目里搜索量最集中的地方。 这一族复合词的存在，是判断要不要改标题的最强依据。单个词的搜索量差距还可以争论，一整族长尾全部以短形式打头就没有讨论余地了，因为那意味着整个类目的入口都在另一边。 ## 汉语词和固有词为什么削得少 日语里的汉语词本来就短，两个字三个字，没有削的空间。 固有词有时候会削，但生产力远不如外来语那一族。 所以排查的时候可以直接把注意力放在片假名词上，效率最高。 这条经验对韩语也部分适用，韩语的外来语同样会被削短。 只是韩语的削短更多发生在两个词合成的场合，规律不完全一样。 一个可以直接用的操作是，把你的日语关键词表按书写系统分成三堆，片假名那一堆逐个核查有没有短形式，汉字词那一堆基本可以跳过。这样一小时能扫完通常要花一整天的工作量。韩语那一侧的词形问题另见韩语的空格与助词如何改变词形 (https://zhangwenbao.com/korean-seo-spacing-particles-keyword-research.html)。 词边界怎么切这件事本身在不同语言里就有一套通用规则，Unicode标准附件29的词边界一节 (https://www.unicode.org/reports/tr29/#Word_Boundaries)给出了跨语言的判定口径，做日语和韩语的词表拆分时值得先读一遍。 ## 两个形态的搜索量差到什么程度 差距的量级跟词的日常使用频率高度相关，越日常差得越多。 手机这一类天天要说的词，短形式的搜索量能到全称的十倍以上。 空调、遥控器这类家电词，差距也在几倍到十几倍之间。 专业设备类的词差距小得多，因为使用者本来就是内行，习惯用全称。 所以判断优先级的时候，先看这个概念普通人一天会不会提到。 需要提醒的是，工具给出的数字往往已经把两个形态合并了，你看到的是一个总量，看不出内部的分布。要拿到真实分布，最省事的办法是分别投两组广告跑一周，或者去看站内搜索日志里两个形态各自出现多少次，成本都不高但结论完全不同。 还有一个信号值得看：短形式有没有进入平台的类目名。一旦平台把它写进导航，说明它已经通过了一次基于点击数据的验证，这时候你再犹豫要不要用，基本上就是在跟数据较劲。 ## 欧洲语言的削短跟日语是同一种机制吗？ ## 德语的Uni、Abi、Akku走的是另一条路 德语的削短通常只保留第一个成分或者前两个音节，不做拼接。 Universität削成Uni，Abitur削成Abi，Akkumulator削成Akku，都是直接截断。 德语的复合词还有另一种缩短方式，就是把长复合词拆成两个词来说。 这两种方式经常并存，同一个概念可能有全称、截断形和拆分形三种写法。 对关键词表来说，这意味着德语需要覆盖的形态数量比你预期的多一档。 德语的削短还有一个特点是词性会跟着变，截断形往往会固定成一个新的名词并保留原来的语法性，这对内链锚文本和分类页标题的写法有直接影响。复合词本身的处理另见德语复合词、变音符号与关键词研究 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)。 德语这几个截断形的地位可以直接查证，DWDS的Uni词条 (https://www.dwds.de/wb/Uni)给出了它的使用频率曲线和语料例句，杜登词典的Akku词条 (https://www.duden.de/rechtschreibung/Akku)则标明了它的语法性别，两处都说明它们早已不是临时说法。 ## 西语和俄语的短形式带着语体标记 西班牙语的bici、uni、profe这类形态带着明显的随意色彩。 它们在搜索里照样高频，但放到商品页正文里会显得不够正式。 俄语的универ、фотка、комп也是同样的情况，语体标记更明显。 这一类的处理办法跟日语德语不同，不适合直接放进商品标题。 合适的位置是正文、问答区、博客文章，让它跟全称在同一页共现。 判断一个短形式带不带语体标记，最快的办法是问母语同事一句话——这个词能不能印在包装盒上。能印的就可以进标题，不能印的就只放正文。这个判据比任何词典标注都准，因为它问的是实际使用场景而不是词典分类。西语两个市场的差异另见西班牙语在西班牙和拉美的选词分歧 (https://zhangwenbao.com/spanish-seo-es-es-latam-keyword-divergence.html)。 这一类形态还有一个共同特点，就是它们的年龄分布很偏。年轻用户用得多，年长用户几乎不用，所以要不要用它还得看你的目标人群落在哪一段，这个变量在别的削短类型里不明显。 ## 荷兰语和印尼语要放在一起看 荷兰语的削短不算强势，但它跟英语借词混在一起会变得复杂。 印尼语的情况特殊，那门语言的非正式缩写在网络文本里密度极高。 印尼语用户还会把两个词的首音节拼起来造新词，形态更难预测。 这类语言的正确做法不是穷举，是先建一条从日志里自动提取候选的通道。 手工列表在这种语言上永远追不上实际使用的变化速度。 荷兰语和印尼语放在一起讲，是因为它们代表了两种不同的难度：荷兰语的削短量少但边界模糊，印尼语的削短量大但规律相对清楚。两者需要的投入完全不同，前者靠人工核查就够，后者必须上自动化。印尼语与马来语的词汇分裂另见印尼语与马来语能不能合并成一套关键词表 (https://zhangwenbao.com/indonesian-malay-seo-two-markets-vocabulary-split.html)。 判断该走哪条路的办法是数一遍：把一个月的搜索日志导出来，如果非规范写法占比在一成以下，人工核查够用；超过三成就必须上自动提取，否则你的词表永远落后实际使用半年。 ## 这些词为什么一个都进不了你的关键词表？ ## 工具的归并逻辑会把短形式吃掉 关键词工具在返回数据之前会做一轮归一化，目的是把变体合并成主词。 这个动作对英语很友好，对削短严重的语言就变成了信息损失。 短形式和全称如果被判成同一个词，你看到的只有一行数据。 更糟的情况是工具直接把短形式当成拼写错误过滤掉，一行都不给你。 两种情况的表现完全一样，都是你在结果里找不到那个词。 判别办法是拿短形式当作一个独立的种子词单独查一次，而不是从全称的相关词列表里去找。如果单独查能查到而在相关词里找不到，说明归并发生了；如果单独查也是零，才需要考虑是真的没人搜还是工具不支持这门语言。 还有一种更隐蔽的情况是工具支持这门语言，但它的分词模块把短形式切成了两半，于是返回的是两个碎片的数据而不是这个词的数据。这种结果看起来是有数字的，比返回零更容易骗人。 ## 翻译记忆库里根本没有这条记录 翻译记忆库存的是历史译文，而历史译文是从源语言翻过来的。 源语言那一侧写的是全称，译员按对应关系翻出来的自然也是全称。 短形式在源文里没有对应物，所以它从来没有机会进入记忆库。 这不是记忆库的缺陷，是它的工作方式决定的必然结果。 指望从翻译资产里挖出本地高频词，方向从一开始就是反的。 这条对所有翻译驱动的内容体系都成立：翻译产出的是源语言概念在目标语言里的对应形态，而搜索需要的是目标语言使用者自发的表达形态，两者只在一部分词上重合。机器翻译直接上线的风险另见机器翻译直接发布对收录和排名的影响 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)。 翻译资产的价值在一致性，不在覆盖率。它能保证同一个概念在三百个页面上写法统一，但保证不了这个写法是用户在搜的那一个，这两件事需要两套完全不同的输入。 ## 术语表天生只收正式形态 术语表的目的是统一口径，它的编制原则就是每个概念选一个写法。 选哪一个？几乎总是最正式、最完整、最不容易引起歧义的那一个。 这个原则在文档写作里完全正确，在搜索覆盖上正好相反。 于是术语表越规范，它跟真实搜索行为的距离就越远。 这个矛盾没法靠改进术语表来解决，因为两者的目标本来就不同。 可行的做法是让术语表多一列，专门记录这个概念的搜索用形态，并且明确写清楚它只用于标题、面包屑和关键词表，不进正文规范。这样两套口径各管各的，既不破坏文档一致性，也不牺牲搜索覆盖。 芬兰语这类构词能力极强的语言尤其明显，芬兰语现代语言词典 (https://www.kotus.fi/sanakirjat/kielitoimiston_sanakirja)收录的是规范形态，而日常使用里那些被拆开或者被削短的写法，需要另外一套材料才能看到。 顺便说一句，术语表和搜索词表分开维护还有一个好处：两张表的更新节奏本来就不同。术语表几年动一次，搜索词表每季度都要看一眼，硬合成一张表的结果通常是两边都更新不动。 ## 词干还原会把它挂到别的词干上 短形式经过词干还原之后，得到的词干常常跟全称对不上。 因为削短切掉的可能正好是词干的一部分，还原器无从判断。 结果是搜索引擎和你的站内搜索都把它们当成两个不相干的词。 这对站内搜索是硬伤，用户打短形式搜不到用全称写的商品。 对外部搜索引擎影响小一些，因为它们有更多语料可以学习关联。 验证办法很简单，把全称和短形式分别喂给你在用的词干还原器，看输出是不是同一个。不是的话，站内搜索就必须配一张同义词表把它们手工绑起来，这条工作没人替你做。 剥离规则可以直接查，Snowball德语词干提取算法说明 (https://snowballstem.org/algorithms/german/stemmer.html)列出了这套算法会砍掉哪些结尾，对照一遍就知道你的短形式还原之后会落到哪个词干上，不需要靠试。 还有一种更麻烦的情况是短形式经过还原之后，正好落到另一个真实存在的词的词干上。这时候站内搜索不是搜不到，而是搜出一批不相干的商品，用户看到的结果比空结果更让人困惑。 ## 内容生产链路上，是哪几道关卡把它筛掉的？ ## 三道关卡的筛选口径都是正式度 一篇本地化内容从立项到上线，中间要过好几道人工检查。 这些检查的共同目标是让文本更规范、更一致、更像一份正经的商业文案。 每一道关卡都会把偏离规范的写法往回拉一点。 短形式在每一道关卡的眼里都是偏离规范的写法。 三道拉完，它一个字都剩不下来。 这里面藏着一条相当普遍的机制：内容生产链路上的质量关卡是按正式度筛的，而搜索是按使用频度来的，两者在小语种上系统性地不一致。审校越严格，长尾覆盖越差，而这个因果关系在报表上完全看不出来，因为报表只会显示内容质量分在上升。 这条机制不止发生在小语种上，只是在小语种上代价最大。英语站的短形式本来就少，筛掉几个损失有限；构词能力强的语言，被筛掉的往往是整个类目搜索量最集中的那一批词。 ## 母语审校是最积极的那一道 母语审校者对不规范的写法最敏感，这本来是他们的价值所在。 看到一个削短的词，他们的第一反应是这里写得不够正式，顺手改掉。 这个动作是完全善意的，而且从语言质量的角度看无可指摘。 问题出在没有人告诉他们这个词是特意选的，不是写错了。 沟通成本很低，但绝大多数团队从来没做过这一步。 解决办法是在审校简报里加一个不许改的词表，把选定的短形式列进去并注明原因。保哥的做法是在这张表旁边附一句话说明这些词来自搜索日志，母语审校者看到依据之后接受度会高很多，也不会觉得是外行在指挥内行。审校验收的完整清单另见翻译内容上线前的质量线怎么划 (https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html)。 词干算法的开源实现可以直接翻，Snowball词干算法项目仓库 (https://github.com/snowballstem/snowball)里能看到各语言规则的完整源码，把你打算保留的短形式跑一遍，就知道审校改不改它对检索到底有没有影响。 ## 品牌规范文档是第二道 品牌规范通常会规定语气、称呼方式、允许使用的词汇范围。 这份文档大多是从总部的英文版翻过来的，写的时候没考虑过削短问题。 它的默认立场是保持正式、保持一致、避免俚语。 短形式很容易被归到俚语那一栏，然后被整体禁掉。 而做出这个禁令的人，多半没见过当地的搜索日志。 更麻烦的是品牌规范的修改成本很高，改一次要走一圈流程，所以大家宁可绕开也不去改。绕开的结果就是每一个本地团队各自解释一遍，口径散掉，最后谁都没底气在标题里用短形式。 还有一个绕不开的现实是，品牌规范的英文原版根本没有短形式这个概念可写，因为英语没有这么强的削短现象。所以这不是规范写错了，是它压根没有为这件事预留位置。 比较务实的做法是不去改规范文档，而是给它加一份本地补充说明，只覆盖搜索相关的场景。补充说明的审批层级通常低一档，落地速度快得多，效果跟改主文档没有区别。 ## 编辑自己的语感是第三道 就算前两道都放行了，写稿的人还有自己的判断。 受过训练的编辑普遍偏好完整、准确、不省略的表达。 这个偏好在母语内容上是优点，在本地化内容上会放大成过度规范。 尤其是当编辑本人并不是目标语言的日常使用者时，他会更保守。 越不确定，越倾向于选看起来更安全的那个写法。 这一道关卡最难通过制度解决，因为它发生在个人的判断里。可行的办法是把选词结果前置——在写稿之前就把目标词写进简报，并且标明这是要出现在标题里的词。给定了目标，编辑的语感就不会再参与这个决定，它只负责把句子写顺。 越不确定的人越保守，而本地化团队里最不确定的往往是最终落笔的那个人。这条规律解释了为什么很多决定明明在上游做过，到了下游还是会被悄悄改回去。 ## 截短形式该写进页面的哪几个位置？ ## 标题里放全称还是短形式 标题的位置最贵，只能放一个，所以这个选择必须有依据。 依据只有一条：哪个形态的搜索量大，就放哪个。 不要用哪个更正式来判断，也不要用品牌调性来判断。 如果两个形态的搜索量接近，优先选短的，因为它省下的字符可以给别的词。 另一个形态不会被浪费，它可以放在标题之外的位置。 有一种常见的折中写法是在标题里把两个形态都塞进去，结果通常不好——标题会变长、会显得啰嗦、点击率会掉。搜索引擎理解同义关系的能力已经够用，你不需要靠字面并列来教它，把另一个形态放在正文首段效果一样而代价小得多。 还有一个容易被忽略的因素是标题的字符预算。短形式省下来的空间可以多放一个限定词，这在小语种上尤其值钱，因为这些语言的词本来就长，标题位置比英语紧张得多。 ## 正文首段是最安全的共现位置 让两个形态在同一页出现过一次，就足以建立它们之间的关联。 正文第一段是最自然的位置，写起来也不别扭。 常见的写法是主句用一个形态，括号或者从句里带出另一个。 这个动作对读者没有干扰，对搜索引擎是一条明确的信号。 成本几乎为零，是整套办法里性价比最高的一步。 要注意别把这件事做成关键词堆砌。一页里两个形态各出现一到两次就够了，反复交替使用只会让文本读起来很怪，母语用户对这种不自然的重复相当敏感，而这种敏感会直接转化成跳出。 如果页面上有问答区或者规格说明，那里也是很好的共现位置。用户在这两处看到的是解释性文本，出现一次另一种写法完全不突兀，比硬塞进营销文案自然得多。 还有一个位置常被忽略，就是图片的替代文本。那里的文字读者一般看不到，用词自由度高，放另一个形态既不影响阅读体验，也能给这张图在图片搜索里多一条入口。 ## 面包屑和筛选项特别适合放短形式 面包屑和筛选项的空间小，天生偏好短词。 用户在这两个位置扫视的速度很快，短形式的辨识效率更高。 这两处的文本同时也是站内搜索和内部链接的锚文本来源。 把短形式放在这里，等于顺手给它建了一批站内锚。 而这批锚的分布是天然合理的，不需要额外去做内链规划。 顺带说一句，筛选项的取值命名还会进入面板式的导航结构，很多站会把它输出成URL参数或者独立的筛选页。这个位置的用词一旦定下来就很难改，所以值得在建站初期就把短形式的问题解决掉，否则后面改动的成本会高出一个量级。 站内锚文本的分布是很多站长期忽略的一块资产。面包屑和筛选项在全站重复出现，累计的锚文本量往往超过你手工做的所有内链，而它们的用词通常从来没被审过。 如果站上用的是自动生成的筛选项，还要检查一遍生成规则的词源是哪张表。很多站的筛选项直接取自后台的属性字典，而那张字典多半是当年从英文版翻过来的，短形式一个都没有。 ## 结构化数据里的name和alternateName 商品的结构化数据里可以同时表达两个形态，字段是现成的。 主名称用你在标题里选定的那一个，保持全站一致。 另一个形态放进备用名称字段，明确告诉机器它们指同一个东西。 这一步对搜索结果的外观没有影响，它影响的是理解层面。 成本是改一次模板，收益是整站的所有商品都自动带上这条关系。 需要注意的是不要把这个字段当成关键词框来塞，塞五六个形态进去不会有额外收益，反而会让整段数据显得不可信。一个主名称配一到两个真实存在的备用名称是合适的量，超过这个数就该问自己是不是在填数字而不是在描述事实。 填这个字段的时候记得跟着页面上的可见文本走。如果备用名称里写了一个页面上一个字都没出现的形态，那这条数据既没有佐证也没有意义，反而给整段数据的可信度扣分。 ## 母语审校和品牌规范打架的时候，该听谁的？ ## 先把冲突拆成两个可以分别回答的问题 这类争论之所以拖很久，是因为双方在讨论一个混合问题。 拆开之后其实是两个问题：这个词能不能用，以及在哪里能用。 第一个问题是事实问题，看搜索数据和当地实际使用就能回答。 第二个问题才是判断问题，需要品牌方参与。 把它们分开讨论，多数争论会在第一步就消掉一半。 实际操作中最有效的一句话是：我们先不讨论要不要用，先看看当地人是不是真的在这么打。把一份搜索日志的截图放到桌上，讨论的性质立刻从口味之争变成了事实核对，而事实核对通常十分钟就能结束。 这个拆法还能顺手解决另一个问题：把事实问题和判断问题分开之后，责任也跟着分开了，谁该拿数据、谁该拍板变得很清楚，不会再出现所有人都在发表意见但没有人负责的局面。 拆完之后还会发现一件事：两方争的其实经常不是同一个位置。品牌方担心的是包装和广告，本地团队想改的是标题和面包屑，把位置说清楚，八成的分歧当场就消失了。 ## 分场景授权是最省事的解法 不需要一次性拿到全场景的使用许可，那样阻力最大。 先申请标题和面包屑两个位置，理由是搜索覆盖，范围明确可控。 正文、广告文案、包装、客服话术这些位置暂时不动。 范围一小，审批就快，而这两个位置已经能拿到大部分收益。 跑三个月之后拿数据说话，再谈要不要扩大范围。 这套分场景的思路还有一个附带好处，就是它天然形成了一组对照——同一个概念在两类位置上用两个形态，你可以直接观察哪一侧带来的流量和转化更好，而不需要专门设计实验。数据攒够了，扩大范围的讨论就不再需要说服谁。 申请的时候把话说小一点效果更好。与其说要在全站放开这个词，不如说想在两个位置试三个月，前者听起来像要改品牌口径，后者听起来像一次可回滚的试验。 三个月这个期限也不是随便定的。它长到足够让自然搜索的排名变化显形，又短到不会让品牌方觉得是在开一个没有终点的口子，两边都能接受。 ## 把决定权交给日志而不是口味 凡是能被数据回答的问题，都不应该拿到会议室里投票。 短形式该不该用，属于能被数据回答的那一类。 需要的数据也不多：两个形态在搜索日志里的出现次数就够了。 如果站上没有搜索框，广告后台的搜索词报告可以替代。 两周的数据量通常已经足够看出量级差异，不必等到统计意义。 建立这个机制的真正价值不在这一个词，而在于它给后面所有类似的争论定了一个规矩：谁主张，谁拿日志。这条规矩一旦立起来，本地化团队和品牌团队之间的摩擦会显著减少，因为大家争的不再是谁更懂当地人。 能被数据回答的问题拿去投票，是团队协作里最贵的一种浪费。它消耗的不只是会议时间，还有本地团队对流程的信任，而后者一旦掉下去就很难补回来。 这条规矩还有一个副作用值得提前想到：一旦立起来，你自己也要守。哪天你想推的某个形态在日志里查无实据，就得老老实实放弃，不能因为是自己的主张就换一套标准。 ## 一套两小时能跑完的截短词盘点流程 ## 五步盘点法 第一步，从你的品类词表里圈出使用频繁且音节较长的词，通常十到二十个。 第二步，把这批词发给母语同事或者本地供应商，只问一句这个词平时怎么说。 第三步，把拿到的短形式逐个单独查一次搜索量，不要从相关词列表里找。 第四步，去客服记录和站内搜索日志里核对这些形态的真实出现次数。 第五步，把确认下来的形态填进一张表，标明每个词该出现在哪几个位置。 整套流程的耗时主要花在等母语同事回复上，实际工作量不超过两小时。它的产出是一张可以直接交给内容团队执行的表，而不是一份需要再解读一遍的分析报告——这个区别决定了它会不会被真的用起来。 第三步和第四步的顺序不能换。先查搜索量再核对日志，你会带着预期去看数据；先核对日志再查搜索量，日志里出现过的形态才值得花时间去查，省下的正是最容易白费的那部分工夫。 ## 一张能直接交给外包的表 这张表最少要有五列：全称、短形式、搜索量对比、允许使用的位置、来源依据。 来源依据这一列最容易被省掉，但它是整张表能不能被接受的关键。 写清楚是从哪份日志、哪个时间段、多少条记录里得出的结论。 有了这一列，母语审校和品牌方的质疑会少掉大半。 没有这一列，这张表在别人眼里就只是某个人的偏好清单。 另外建议加一列备注，专门记录这个词在什么场合明确不能用。留下这一列，外包和新同事就不需要反复来问，也不会因为不确定而干脆全都不用。一张表如果只写了能做什么而没写不能做什么，执行的人多半会选择最保守的那条路。多语言站点的整体协作可以参考国际化SEO与hreflang的完整落地清单 (https://zhangwenbao.com/international-seo-hreflang-complete-guide.html)。 表的格式越简单越好。见过最有效的一版就是一张五列的表格，没有说明文档、没有决策树、没有流程图，因为执行的人多半只会看第一屏，写得再全也没人往下翻。 ## 哪些场合绝对不能用截短形式？ ## 法务、规格和售后三类文案不能削 法务文案的用词往往有法定含义，换一个形态可能改变解释。 产品规格表里的参数名需要跟行业标准对齐，短形式对不上。 售后条款和退换货说明同样如此，模糊表达会带来实际纠纷。 这三类文案的读者也不是通过搜索找过来的，覆盖收益本来就低。 所以这里不存在取舍，直接用全称，不需要讨论。 把这三类明确排除在外，还有一个额外好处：它让允许使用的范围显得克制，品牌方更容易接受。一份连自己的边界都写清楚的方案，比一份要求全场景放开的方案通过率高得多。 规格表这一类还有个附加理由：参数名往往要跟供应商、认证机构和平台的字段对齐，任何一处改写都可能导致数据对不上，付出的代价远远超过那点搜索覆盖。 这三类文案还有一个共同点，就是它们通常由法务或者产品部门定稿，本地化团队本来就没有改写权限。把它们明确排除，等于顺手避开了一场没有必要的跨部门讨论。 ## 削短会造成歧义的那几种情况 有些短形式在同一门语言里对应两个不同的全称。 这类词进关键词表可以，进商品标题要慎重，容易招来不相关的流量。 另一种情况是短形式跟某个品牌名或者常见人名撞了。 撞名的后果不只是流量不准，还可能让你的页面出现在完全不相干的语境里。 核查办法是拿短形式在当地搜索引擎里搜一次，看结果页的构成。 如果结果页的前十条里有一半以上跟你的品类无关，这个词就不适合放标题。它仍然可以留在正文和备用名称字段里，因为在那些位置它承担的是理解辅助的角色，被误解的成本很低。本地化词表的落地渠道另见小语种外链渠道要去当地人的圈子里找 (https://zhangwenbao.com/minor-language-link-building-local-directories-media-communities.html)。 歧义的成本是不对称的。接到不相关的流量只是浪费展现，而出现在错误的语境里可能直接伤到品牌，所以这一类词的判断标准应该比其他词更严一档。 ## 常见问题解答 ## 怎么快速判断一门语言值不值得做截短词盘点？ 看两件事就够。第一件是这门语言的常用名词平均有多长，构词能力强的语言削短压力大，比如德语、芬兰语、匈牙利语、日语。第二件是它有没有大量外来词，外来词进入日常使用之后被削短的概率远高于本族词。两条都命中的语言优先做，只命中一条的排后面，两条都不命中的可以先跳过。英语、印尼语的常用词本来就短，收益相对有限，投入产出不划算。真正的判断要点是看这门语言的常用词是不是既长又高频，两者同时成立才会持续产生短形式。 ## 母语同事说短形式不够正式，还要不要坚持？ 要，但不要在正式不正式这个问题上跟他争。换一个问法：请他打开手机，用平常的方式搜一下这个东西，然后看他自己打了什么。这个动作比任何数据都有说服力，因为他打出来的往往就是那个被他判为不正式的形态。人对自己的语言使用有一层理想化的认知，问他应该怎么说和看他实际怎么打，答案经常不一样。这个方法保哥用过很多次，几乎每次都能结束争论。这个办法之所以有效，是因为它把讨论从语言学转成了行为观察，而行为是没法争的。 ## 短形式和全称都做一个页面，算不算重复内容？ 不建议为两个形态各建一个页面，那样确实容易被判成重复。正确做法是一个页面同时覆盖两个形态：标题用搜索量大的那个，正文首段带出另一个，结构化数据里用备用名称字段把关系写明。这样一个页面就能同时接住两边的搜索，也不会产生内部竞争。只有当两个形态实际指向不同的产品范围时，才需要考虑拆页面，而这种情况在削短现象里很少见。判断要不要拆页面的标准只有一条：两个形态在用户心里是不是指同一批商品。 ## 关键词工具查不到短形式的数据，怎么估量级？ 有三条不依赖工具的路。第一条是投一组小额搜索广告，两个形态各一组跑一周，看曝光量的比例，成本通常几百块。第二条是看站内搜索日志里两个形态各出现多少次，前提是站上有搜索框且流量够。第三条是去当地搜索引擎搜索框里逐字输入，看联想词里出现的是哪个形态以及排在第几位。三条都不需要工具支持这门语言，得到的也不是精确值而是量级，但量级已经足够做决策。三条路可以并行跑，互相验证，量级对得上就可以直接进决策，不必追求精确。 ## 削短现象会不会随时间变化，需要多久复查一次？ 新品类词会持续产生新的短形式，老词的形态则相当稳定，一旦收敛就很少再变。所以复查的重点不是重跑全表，而是把新增的品类词过一遍。节奏上建议每半年做一次，或者每次上新品类的时候顺手做一次。真正需要警惕的是市场扩张的时候，同一门语言进入一个新国家，那边可能收敛到另一个形态，这时候必须重新盘一遍而不能沿用老表。换句话说，复查的触发条件是新增品类和新增市场，而不是日历上的某个日期。 ## 这套办法对广告和自然搜索的价值一样吗？ 广告那边见效更快，因为出价和匹配都由你控制，词换掉当天就能看到曝光变化。自然搜索那边慢一些，标题改完通常要等两到六周才能看出排名的位置变动。但自然搜索这一侧的价值更持久，因为短形式往往竞争度更低，出价成本和内容竞争都比全称那一侧轻。实际操作上可以先用广告快速验证哪个形态更值钱，验完之后再决定要不要改自然搜索那一侧的标题。所以合理的顺序是广告先行验证，自然搜索跟进落地，两边共用同一份结论。 ## 怎么防止团队换人之后这套结论又丢了？ 把结论写进两个地方就够。一个是术语表里新增的那一列搜索用形态，另一个是内容简报的模板，让每次立项都自动带出目标词。这两处都是流程里必经的文件，不依赖某个人记得。相反，如果结论只存在于某次会议纪要或者某个人的表格里，换一轮人之后必然丢失，然后团队会重新经历一遍从发现问题到说服品牌方的全过程。文档的位置比文档的详细程度更重要。判断一份结论会不会活下来，看它有没有被写进别人非看不可的那份文件里。 ## 权威参考资料 ## 机器翻译发上线省下的那道审校，最后是拿收录和排名分期还的 - URL：https://zhangwenbao.com/machine-translation-direct-publish-search-risk-quality-line.html - 分类：小语种SEO - 发布：2018-12-13 | 更新：2026-07-25 - 摘要：指南禁的不是机器翻译这个工具，是没有人工审校就发布。讲清机翻在小语种上具体坏在哪十个环节、质量红线怎么定量、四档处理策略怎么选，以及审校痕迹该怎么留。 - 关键词：内容质量,出海SEO,多语言SEO,小语种SEO > **TLDR**：摘要：指南里那条被引用了无数次的条款，禁的从来不是机器翻译这个工具，而是没有人工审校或整理就发布。重心在后半句。可这条规则被普遍读成用了就违规，于是团队要么偷偷用、要么彻底不用，两条路都走偏了。真正该做的是搞清楚机翻在小语种上具体坏在哪几个语言学环节，再给每个环节配一道能执行的检查。 > 摘要：指南里那条被引用了无数次的条款，禁的从来不是机器翻译这个工具，而是没有人工审校或整理就发布。重心在后半句。可这条规则被普遍读成用了就违规，于是团队要么偷偷用、要么彻底不用，两条路都走偏了。真正该做的是搞清楚机翻在小语种上具体坏在哪几个语言学环节，再给每个环节配一道能执行的检查。 ## 指南禁的到底是机器翻译，还是少了那道工序？ ## 那句话的重心落在没有人工审校这半句上 条款的原文写的是：未经人工审校或整理就发布的机器翻译文本。 这句话由两部分组成，前半句说的是工具，后半句说的是流程缺失。 被判定为问题的是两者相加，不是前半句单独成立。 换句话说，用不用机翻不是判据，用完之后有没有人管才是判据。 这个区分不是文字游戏，它直接决定了工作流该怎么设计。 读对了这半句，机翻就从一个禁忌变成了一道可管理的工序。 这条区分还能解释一个常见的困惑：为什么有些站明显用了机翻却排得很好。因为它们把机翻放在了初稿位置，后面接了完整的审校和改写，最终发布的文本已经不是机翻输出了，机翻只是把译者从零开始写降级成了改稿，这在流程上完全合规。 所以第一步该做的不是决定用不用机翻，是决定审校这道工序放在哪、由谁做、按什么标准验收。 把审校当工序还有一个管理上的好处：它能被排期、被计价、被验收。禁忌是没法管理的，工序是可以管理的。多语言内容本地化的生产线怎么搭 (https://zhangwenbao.com/multilingual-content-localization-production-pipeline-vs-translation.html)那篇讲的就是把这类环节工程化的整套做法，本篇只补语言层的那部分细节。 ## 读成用了就违规会带来什么后果 最直接的后果是团队开始隐藏这件事。 机翻照用，但不留记录，不进流程，不做验收。 没有记录就没有质量标准，没有标准就没人知道输出好不好。 于是一批质量分布完全未知的页面被发上线。 另一个方向的后果是过度保守，小语种市场干脆不做。 放弃一个市场的代价，比做一个中等质量版本的代价大得多。 保哥接过一个做牙科与实验室耗材的客户，团队因为怕违规，坚持所有小语种页面必须由母语译者从零写，结果两年只铺出三种语言，而竞品用机翻加审校的方式铺了十一种，等到发现差距时，那些语种的头部位置已经被占满了。 合规和产能不是对立的，把审校这道工序标准化之后，两者可以同时成立，卡住的往往是对规则的误读而不是资源。 隐藏这件事还有一个连带损害：数据断了。因为不留记录，你永远不知道哪一批页面是机翻的、哪一批是人工的，等到某个语种的表现出问题想回头查原因，连查的依据都没有。这比机翻本身的质量问题更难补救。 ## 留下审校痕迹为什么是唯一能自证的方式 文本本身看不出它有没有被审校过。 一段机翻输出和一段经过审校的机翻输出，可能只差十几个字。 所以自证不能靠文本，只能靠过程记录。 需要记的有四项：译文版本、审校人、审校日期、改动率。 其中改动率这一项最有说服力，它是可量化的。 改动率长期偏低的语种，说明那里的审校只是走了个流程。 改动率还能当作定价依据。给审校者按改动率的区间结算，而不是按字数结算，能把激励对准质量。低改动率不一定是审校不认真，也可能是机翻本来就好，但这两种情况都需要抽检来区分，而抽检的对象正好可以按改动率排序挑出来。 这套记录一旦跑起来，还有一个附带价值：它能告诉你哪个语种的机翻质量最差，那正是最该优先换成人工翻译的语种。 审校记录还有一个用途是应对人员流动。小语种审校者的更替相当频繁，新人接手时如果能看到前任的改动记录，就知道这个语种历史上反复出错的是哪几类问题，上手速度完全不同。没有记录的项目，每换一个人都要从头踩一遍同样的坑。 ## 机器翻译在屈折语上第一步就会错在哪？ ## 短语在句子里对，摘出来当标题就错 机器翻译处理的单位是句子，它把整句译得通顺。 但页面上很多文本不是句子，是短语。 标题、分类名、属性值、按钮文案，全是脱离句子的片段。 屈折语里，词的形态由它在句子里的角色决定。 译文里那个词带着某个具体的格尾，因为它在原句里当了宾语。 把它摘出来单独用，形态就错了，用户搜的是另一种形态。 这类错误的隐蔽性在于它读起来一点都不别扭。母语者看到带格尾的词也认得，只会觉得措辞有点怪，不会当成错误报回来。真正暴露问题的是搜索表现报告：那个页面的核心词几乎没有展现，因为用户搜的是词典原形，而页面上写的是宾格。 处理办法是把标题、分类名、属性值这几类文本从机翻流程里单独拆出来，用词表映射而不是用翻译，词表里存的就是词典原形。 ## 格与数的形态被译文随机挑了一种 一个名词在屈折语里能变出十几种形态。 机翻输出的是其中一种，具体哪一种取决于上下文。 同一个词在十个页面上可能出现三四种不同形态。 这三四种里只有一种是用户在搜的那个。 芬兰语的十五个格还叠加词干交替 (https://zhangwenbao.com/finnish-seo-fifteen-cases-consonant-gradation-keyword.html)，形态数量比这更多。 匈牙利语十八个格 (https://zhangwenbao.com/hungarian-seo-eighteen-cases-vowel-harmony-keyword.html)的情况类似，机翻的随机性也更明显。 形态选择的随机性不是机翻的缺陷，是它的正常工作方式。翻译系统的目标是让整句读起来对，它没有理由知道你希望标题里出现词典原形。指望调提示词或者换模型解决这件事是走不通的，问题出在把翻译任务和选词任务混成了一件事。 波兰语七个格 (https://zhangwenbao.com/polish-seo-seven-cases-diacritics-keyword-research.html)那篇讲的变体覆盖方法，正好是这个问题的正解：先定原形，再按需要铺变体，两件事分开做。 有个简单的自检办法能立刻看出这个问题的严重程度：把某个核心品类词在全站目标语页面上的所有写法抓出来去重。屈折语的站上这个去重结果常常有五六种形态，而其中只有一种是词典原形。这个数字比任何理论解释都直观。 ## 性数一致会让形容词跟着错一片 很多语言的形容词要跟名词在性和数上保持一致。 名词的形态一变，前后的形容词、冠词、代词全都跟着变。 机翻在句子内部处理这件事没问题。 问题出在替换环节：模板里换掉一个名词，周围的词不会跟着改。 结果是一整批模板生成的页面，形容词全都跟名词不一致。 这类错误对母语用户来说是明显的低质量信号。 模板加机翻这个组合最容易撞上这个坑。翻译的时候模板里放的是占位符或者示例词，译者看到的是一个具体的例子，译出来的搭配只对那一个例子成立，等到批量替换成两千个不同的商品名，一致性全线崩掉。这也是模板类页面必须在替换之后再抽检的原因。 规避办法是让模板的槽位周围避开需要一致的成分，或者干脆按性别分几套模板，后者更笨但更可靠。 ## 屈折语的错误为什么在标题位置最致命 标题是搜索结果里最主要的匹配对象和展示文本。 标题里的词形态错了，等于核心关键词没写上去。 正文里同样的错误影响小得多，因为正文有大量的近似表达。 所以有限的审校资源应该优先投在标题和分类名上。 这两处的字数占全站文本的比例极低，杠杆却最高。 把审校范围按位置的杠杆排序，比按页面重要性排序更有效。 这条判据在东南亚三国的语言层横向对比 (https://zhangwenbao.com/southeast-asia-seo-vietnam-thailand-indonesia-language-layer.html)里也用过一次，那边是因为审校人才稀缺不得不收窄范围，这边是因为机翻的错误集中在特定位置所以主动收窄，出发点不同但落点一致。 先把全站的标题和分类名过一遍，再考虑正文，这个顺序在任何形态复杂的语言上都成立。 标题这一处还有一个附带的好处：它的错误可以被自动发现。把标题里的核心词跟关键词表的原形做字符串比对，不匹配的挑出来人工看，这个检查不需要懂目标语言就能跑。正文里的错误就没有这种便利，只能靠人读。 ## 术语一致性漂移怎么变成关键词蚕食？ ## 同一个属性词能被译出六种说法 机器翻译不保证同一个词每次都译成同一个词。 上下文不同，输出的措辞就可能不同。 一个属性词在两千个商品页上出现，可能有五六种译法。 这几种译法都不算错，只是不一致。 不一致在自然语言里无所谓，在关键词体系里是硬伤。 因为每一种译法都在争抢同一批用户的同一个查询意图。 术语漂移在同一批次的翻译里就会发生，不需要等到跨批次。同一天送出去的一千个商品描述，因为分成了几个文件、上下文各不相同，回来的译文里那个核心属性词就已经有三种说法了，这跟译者是人还是机器无关，跟有没有术语表有关。 所以术语表不是给译者看的参考资料，是给流程用的强制约束，它必须在翻译之前存在，而不是翻译之后拿来核对。 ## 六种说法变成六组互相压的页面 每一种译法都会被写进对应那批页面的标题和正文。 于是同一个意图被分散到六组页面上。 搜索引擎要在这六组里挑一个来展示。 它挑哪个不由你决定，而且可能反复换。 这是标准的关键词蚕食形态，只不过起因是翻译而不是选题。 关键词蚕食的确认和处置 (https://zhangwenbao.com/keyword-cannibalization-content-site-diagnosis-consolidation.html)那套方法可以直接拿来用。 由翻译引起的蚕食比由选题引起的更难诊断。选题重复的时候，两个页面的主题肉眼可见地重合；术语漂移引起的重复，页面看起来各写各的商品，只有把标题里的属性词抽出来做词频统计才能看出来同一个概念有六个名字。 诊断方法是把全站标题里的属性词抽出来聚类，同一个概念对应多个词的，就是漂移点，这个检查一年做一次就够，但必须做。 蚕食的代价还不只是排名不稳。六组页面把内链权重也分散了，每一组拿到的都不够，本来集中在一页上能进前十的主题，分散之后六页全在二三页徘徊。这一层损失在报表上看不出来，因为每一页都有一点流量，加起来的总量也不算难看。 ## 术语表为什么必须在翻译前就建好 翻译之后再统一术语，等于把所有页面重写一遍。 翻译之前建好，成本只是整理一份两百词的表格。 这份表格的内容包括源词、目标语标准译法、禁用的近义译法。 禁用列这一项最容易被省掉，也最有用。 因为漂移往往漂到那几个特定的近义词上，把它们列出来就能挡住。 表格建好之后，机翻输出可以自动检查命中率，不需要人工逐条看。 早年拿词典逐词换关键词留下的长期损失 (https://zhangwenbao.com/keyword-literal-translation-legacy-cost-non-english.html)那篇讲的是同一件事的另一个版本：那时候的问题是译得不像当地说法，现在的问题是译得不一致，两者的根治办法都是先建词表再动手。 术语表的建立成本一次性投入，收益覆盖后面所有批次，这是整条流程里投入产出比最高的一项。 ## 语域和句式失控会损失什么？ ## 祈使句被译成正式书面语 电商页面上有大量祈使句：加入购物车、立即购买、查看详情。 这些短句在英语里语气中性，在很多语言里必须选一个正式度。 机翻默认倾向选较正式的那一种。 结果是按钮文案读起来像公文，跟界面的语气完全不搭。 用户不会因为这个投诉，但会因为这个觉得站不专业。 这类损失落在转化率上，不落在排名上，但两者最终会连起来。 正式度这件事的麻烦在于没有正确答案，只有市场惯例。同一句加入购物车，在德语市场偏正式是对的，在印尼市场偏正式就显得生硬。这只能靠看当地主流电商站的实际写法来定，看三五家就能得出结论，比讨论语法规则有效得多。 把界面文案和商品文案分成两套语域规范，界面那套一次性定好由母语者写死，商品那套才走翻译流程。 语域这件事在小语种上还多一层麻烦：你很难判断母语审校者给的意见代表的是市场惯例还是个人偏好。两个审校者对同一句按钮文案给出相反建议是常见的。破解办法是拿当地主流电商站的实际写法当仲裁依据，讨论就从谁对谁错变成了惯例是什么。 ## 按钮文案不像按钮 按钮文案有长度限制，机翻不管这个。 译出来的短语可能比原文长一倍，界面直接被撑坏。 有些语言表达同一个动作天然更长，这不是翻译质量问题。 处理方式是给界面文案单独设长度上限，超了就重写不重译。 重写的人需要知道这个按钮在界面上占多宽，译者通常不知道。 所以界面文案这一类应该整块交给本地化人员，不走翻译流水线。 被撑坏的界面比语法错误更伤，因为它在每一个页面上都出现，而且用手机的用户看得最清楚。这类问题在验收环节最容易漏掉，因为验收通常看的是文本文件而不是渲染后的页面，而文本文件里看不出长度会不会溢出。 验收环节必须包含真机截图，尤其是窄屏，这一条在任何多语言项目里都值得写进流程。 ## 有些语言的祈使句还分性别形式 希伯来语和阿拉伯语的动词祈使形式区分男女。 你不知道点按钮的人是谁，所以两种形式都不合适。 机翻会挑一种，通常是阳性形式。 结果是一半用户看到的界面文案在语法上不是对他们说的。 希伯来语的无元音书写与词根三辅音 (https://zhangwenbao.com/hebrew-seo-unvocalized-script-root-letters-keyword.html)那篇给过这个问题的解法。 解法是把祈使句改写成动作名词，绕开性别形式的选择。 这个坑说明了机翻的一个根本局限：它只能在语法上做选择，不能在业务上做选择。改写成动作名词是个业务决策，需要知道这个按钮会被两类用户看到，而这个信息不在待译文本里。凡是需要业务上下文才能决定的措辞，都不该交给翻译环节。 把这类需要业务判断的文案清单列出来，通常不超过五十条，一次性处理干净能省掉后面无数次返工。 性别形式这一类还有它的同类：敬语层级、单复数称呼、以及第二人称的正式与非正式形式。这几样都属于必须知道用户是谁才能选对的东西，而这个信息永远不在待译文本里。凡是遇到这种情况，正确的动作都是改写句式绕过选择，而不是替系统猜一个。 ## 数字、单位和日期为什么最容易被漏检？ ## 小数点与千分位的两套习惯 一部分语言用逗号做小数点，用点或空格做千分位。 机翻处理正文里的数字有时会转换，有时不会。 不确定性本身就是问题，因为你没法靠抽检覆盖。 价格数字转换错了，用户读到的是差一千倍的价格。 正文里的规格数字转换错了，用户会买错型号。 这类错误在耗材、器械、零配件这些品类里后果最严重。 正解是数字根本不该进翻译流程。价格、规格、尺寸这些数值应该从结构化字段里取，按目标语的区域设置格式化输出，而不是作为文本的一部分被翻译。这样格式化规则集中在一处，改一次全站生效，也不存在被翻译环节改坏的可能。 检查方法很简单：随机抽二十个页面，把页面上的数字跟数据库里的原始值对一遍，对不上的就是流程里有环节在改数字。 ## 日期顺序与月份名的本地化 日期的顺序、分隔符、月份名的写法各语言都不同。 有些语言的月份名首字母不大写，前端库经常给它大写了。 有些语言的日期里月份要用属格形式。 机翻遇到日期字符串多半原样留下，因为它看起来不像自然语言。 于是页面上留着源语言的日期格式，用户读起来要换算。 促销页、物流时效、保质期这几类内容受影响最直接。 日期这件事还有一层容易漏的：星期名的起点。有些语言里星期名是按序数命名的而且起点是周日，第二天这个词对应的是周一，直接按数字对应会全部错开一天。物流时效的表述里一旦出现星期名，这个错就会传导到用户对到货时间的预期上。 日期和星期一律走区域设置输出，不走文本翻译，这跟数字是同一条原则。 日期本地化还有一处极易漏掉的位置：结构化数据以外的那些人写的日期。促销文案里写的截止日期、物流说明里写的工作日范围、售后条款里写的期限，这些都是文本，不走字段，机翻会照原样搬过去。这几处要单独列进检查清单。 ## 格式错会连带打坏结构化数据 结构化数据里的价格、货币、日期字段有格式要求。 格式不合要求的字段会被校验器判为错误。 严重的错误会让整个结构化数据块失效。 失效的直接后果是富媒体展现拿不到。 这条损失是可见的，也是最容易被归因到别处的。 因为团队通常不会想到是翻译流程改坏了结构化数据。 排查这个问题有个快捷方式：把结构化数据的校验错误按语言分组统计。如果错误集中在某几种语言上，而那几种语言正好是走机翻的，问题基本就定位了。如果各语言均匀分布，那才是模板本身的问题。 结构化数据的生成也应该独立于翻译流程，从字段直接输出，永远别让它经过任何翻译环节。 结构化数据这条线还有个更早的暴露点：那些校验错误其实在上线当天就存在了，只是没人看。把校验器接进发布流程，让它在页面上线前跑一遍，能把这类问题拦在源头。这个改动的成本很低，但它把一类事后排查变成了事前拦截。 ## 编码层的问题机翻会不会带进来？ ## 变音符号的两种规范化形式 带变音符号的字符在编码上有两种表示方式。 预组合的单一码位，或者基字母加上组合记号。 翻译接口返回哪一种不确定，可能跟你库里的不一致。 不一致的后果是同一个词在库里有两套字节序列。 去重去不掉，站内搜索匹配不上，统计口径也不对。 解法是在接口返回值入库前做一道统一规范化。 这个坑跟越南语那一路遇到的是同一个，只是来源不同。越南语的不一致来自用户的输入法，这里的不一致来自翻译接口，但表现完全一样：肉眼看不出差别，程序判定为两个不同的字符串。所以规范化这道工序应该设在所有文本入口上，不只是用户输入那个入口。 接口回来的文本先规范化再入库，这一行代码能省掉后面一整轮的数据清理。 ## 复合词该粘的没粘、该断的断了 德语这类语言把多个词粘成一个长词。 机翻有时粘对了，有时输出两个分开的词。 粘不粘决定了用户能不能搜到这个页面。 德语复合词把关键词拼成一个长单词 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)那篇讲过这个机制。 反方向的问题出在无空格语言上，该连写的地方被插了空格。 两个方向的错误都会直接改变可被检索的字符串。 复合词的对错有个特点：它不影响可读性。分写的德语复合词母语者一眼就能看懂，只是觉得写法不地道，所以审校时很容易被放过。但从检索角度看，分写和合写是两个完全不同的字符串，命中的查询集合几乎不重叠，这是纯粹的技术性损失。 复合词的处理应该靠词表而不是靠译文，把核心品类的复合词形式固定下来写进术语表的强制列。 复合词这件事在无空格语言那一侧的表现更隐蔽。越南语按音节分写 (https://zhangwenbao.com/vietnamese-seo-tone-marks-syllable-spacing-keyword.html)的规则跟机翻的输出习惯不一定一致，同一个概念可能被译成分写两段或者合写一段，两种写法命中的查询完全不同，而母语者看两种都认得。 ## 品牌名和型号被当普通词翻掉 品牌名如果本身是个普通词，机翻会把它当普通词处理。 型号里的字母数字组合有时会被改写或者加空格。 这两类改动都会让页面失去品牌词和型号词的匹配能力。 品牌词的搜索量通常是全站最高的那一批。 品牌名在小语种里到底该写成什么 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)那篇讲的是主动选择写法，这里是被动被改写。 解法是在送翻译之前把品牌名和型号替换成占位符，回来再换回去。 占位符这个办法还有个附带好处：它能顺便统计出品牌名在待译文本里出现了多少次，这个数字本身就是个有用的指标。品牌名出现频次过低的页面，往往也是品牌词覆盖不足的页面，两件事可以一起处理。 不可翻译清单是每个多语言项目都该有的东西，里面至少包括品牌名、型号、专有技术名词、以及法定名称。 ## 质量红线该用什么指标定，不该用什么？ ## 自动评分是给系统比对用的，不是给单页放行用的 机器翻译领域有一套成熟的自动评分指标。 这些指标的设计目的是比较两个翻译系统的整体表现。 它们在语料级别上有意义，在单句级别上噪声很大。 拿一个语料级指标去判断某一页能不能发布，是用错了工具。 而且计算这类指标需要参考译文，而你要发的那页本来就没有参考译文。 所以这条路在生产环境里根本走不通，不只是不准确的问题。 这个误用相当常见，原因是这类指标名字听起来很权威，报告里写一个分数也显得专业。真正在评测机器翻译的会议上，自动指标本身还要拿人工评分去校验相关性，也就是说自动指标的可信度需要人工评分来担保，用它替代人工评分是把担保关系搞反了。 单页放行只能靠抽样人工判断，自动指标的正确用法是选系统和监控整体趋势。 还有一个更实际的理由让这条路走不通：自动指标算出来的分数没有绝对含义。三十几分是好还是坏，只有跟另一个系统在同一批数据上的分数比较才知道。拿一个孤立的分数去定放行门槛，等于拿一个没有刻度的尺子量东西。 ## 形态丰富的语言用字符级指标更敏感 如果确实要算自动分数，指标的选择有讲究。 基于词的指标在形态丰富的语言上失灵得很快。 因为词形一变就算完全不匹配，即使意思完全对。 基于字符片段的指标对这种情况敏感得多。 屈折语和黏着语的评测都该用后者。 这个选择对判断某个语种的机翻能不能用，影响很大。 这里有个实用的推论：如果你用的是词级指标，那么屈折语的分数会系统性偏低，你可能因此错判某个语种的机翻质量太差不能用；反过来，如果分数意外地高，也要怀疑是不是测试集里的句子形态太单一。指标的选择会改变结论，不只是改变小数点后两位。 选指标这件事只需要做一次决定，但做错了会让后面所有语种的比较都失真。 ## 术语命中率是可执行的第一道闸 术语命中率的定义很简单：术语表里的词有多少比例在译文里正确出现。 这个指标可以完全自动计算，不需要参考译文。 它直接对应一个真实的业务风险，也就是术语漂移。 阈值可以按品类定，重点品类要求更高。 低于阈值的批次直接退回，不进人工审校环节。 这道闸能挡掉相当大比例的问题批次，成本几乎为零。 命中率这个指标还能反过来优化术语表。长期命中率极低的那几个词，可能是术语表里定的译法本身不自然，翻译系统怎么都不往那个方向走，这时候该改的是术语表而不是译文。术语表也要迭代，不是定了就不动。 把这道闸做成自动化的，放在译文回来之后、人工审校之前，是整条流程里最划算的一处投入。 这道闸的实现比听起来简单：把术语表读进来，在译文里逐条做字符串查找，统计命中比例。屈折语需要多做一步，把词根形式也算命中，否则带格尾的正确写法会被判成没命中。这个脚本一两百行就够，跑一批译文只需要几秒。 ## 关键词命中率是搜索这一侧独有的那道闸 机器翻译评测圈完全不看这个指标，因为它跟翻译质量无关。 但它对搜索表现是决定性的。 定义是：译文里有没有出现该市场真正在搜的那个词。 一段译文可以完全正确、非常通顺，同时一个关键词都没命中。 因为当地人搜的词跟词典里的标准译法不是一个词。 出海关键词本地化的翻译陷阱与人审步骤 (https://zhangwenbao.com/overseas-indie-keyword-localization-translation-traps-native-review.html)那篇讲的正是这一层。 这道闸的检查方式是拿关键词表去比对译文，看核心词的覆盖情况。跟术语命中率不同的是，这里比对的对象是用户实际在搜的词，而术语表比对的是你希望统一的说法，两份清单可能有相当大的差别，尤其是在口语词流行的市场。 两道闸都要设，术语闸管一致性，关键词闸管可被搜到，缺任何一道都会漏掉一整类问题。 ## 四档处理策略怎么按页面类型分？ ## 两个轴决定档位：要不要排名、错了会不会出事 第一个轴是这一页要不要承接搜索流量。 第二个轴是内容错了会不会造成实际损害。 两个轴各分高低，组合出四种情形。 高风险的一律不走机翻，不管要不要排名。 要排名且低风险的走机翻加关键字段审校。 不要排名且低风险的可以放宽，比如帮助中心的边缘条目。 把这两个轴画成表比在会上争论要不要用机翻有效得多。争论通常卡在立场上，画表之后大家发现分歧其实是对某几类页面的风险判断不一致，而那是可以查证的具体问题，不是原则问题。 表格画出来之后要落成规则写进流程文档，否则每来一批新页面又要重新讨论一遍。 ## 四档各自的操作定义 零档是完全不用机翻，从头人工翻译并审校。 适用于规格页、合规声明、安全说明这类内容。 一档是机翻加全文母语审校，适用于主要的钱页。 二档是机翻加关键字段审校，正文只做轻度顺句。 关键字段指标题、分类名、属性值、页面描述这几项。 三档是机翻但不发布，只用于内部理解竞品和调研。 三档这一项经常被忘掉，但它是机翻最没有争议的用法。用机翻读竞品的目标语页面、读当地论坛的讨论、读用户评论，产出的是团队的理解而不是发布的内容，完全不涉及任何规则问题，而且这类用途的信息价值往往比铺页面更高。 四档的划分要写进内容排产表，让每一批页面在立项时就带着档位标签，而不是等译文回来了再讨论怎么处理。 四档之间还需要一条升降级规则。某个页面从长尾变成了钱页，档位要往上提；某个品类的机翻质量测出来比预期好，档位可以往下降一档。没有升降级规则的分档表用半年就会跟实际脱节，最后变成谁都不看的一份文档。 ## 抽检比例与放行门槛怎么定 零档和一档不需要抽检，因为它们是全审的。 二档需要抽检，比例按品类的营收贡献排。 重点品类抽三成，中间品类抽一成，长尾抽两个点。 抽检的判据是关键字段有没有错，不是正文读起来怎么样。 抽检不合格的批次整批退回，不做局部修补。 整批退回听起来严厉，但它是唯一能让上游认真对待的机制。 抽检结果要记录成时间序列，看的是趋势而不是单次结果。某个语种的合格率连续三个批次下滑，说明上游的什么东西变了，可能是换了译者、换了机翻引擎、也可能是新品类的术语表没跟上，这三种原因的排查方向完全不同，只有连续记录才能分辨。 门槛定得低一点但严格执行，比定得高但经常破例有用，这条在任何质量流程里都成立。 ## 后果链具体是怎么一环扣一环的？ ## 从术语漂移到内部蚕食 术语漂移产生多种说法，多种说法分散到不同页面。 同一个意图对应多个页面，页面之间开始互相压。 搜索引擎在这几个页面之间反复切换展示对象。 排名波动被误读成算法更新的影响。 于是团队去调整跟这件事完全无关的因素。 诊断错了方向，问题会一直存在。 这条链最阴的地方是它的时间差。翻译发生在第一季度，蚕食的表现要等到页面被充分收录之后才显现，可能是第三季度，那时候没人会把排名波动跟半年前的翻译批次联系起来，排查方向自然就跑偏了。 要打断这条链，最经济的办法是在翻译环节就守住术语一致性，而不是在排名波动之后去做页面合并。 ## 从语域错到品牌层信号 语域不对会影响用户对站点专业度的判断。 判断的结果落在停留时间、跳出、加购这些行为上。 行为数据的变化会进一步影响品牌层面的信号。 品牌力作为隐性排名信号 (https://zhangwenbao.com/brand-as-implicit-ranking-signal-navboost-eeat-entity-mechanism.html)那篇讲的机制在这里生效。 这条链比术语漂移那条更慢，也更难量化。 但它的影响面更宽，因为它作用在整个语种版本上。 更麻烦的是这条链有惯性。一旦某个语种版本给用户留下了不专业的印象，后面把文本改好了，行为数据的恢复也要滞后相当长时间，因为回访的用户带着上一次的预期。所以语域这件事的正确处理时点是上线之前，而不是数据难看之后。 钱页的语域必须由母语者定，这笔钱在整个预算里占比很小，但它决定了整个语种版本的印象基线。 语域这条链还有一个可以早期发现的信号：母语审校者的自发反馈。如果审校者在改稿之外主动写了一句这批文案读着不像本地站会写的东西，那就是语域问题的第一手报告，比等行为数据变化要早几个月。这类反馈值得单独收集起来。质量评估员手册怎么读 (https://zhangwenbao.com/search-quality-rater-guidelines-qrg-seo-self-review-checklist.html)那篇里的自查清单也能借来用。 ## 从模板加机翻到目标语内部近重复 模板本身在源语言里是有变化的，因为槽位不同。 翻译之后，模板的固定部分在每个页面上完全一样。 如果槽位内容占比小，整页的相似度会非常高。 目标语版本的近重复程度比源语言版本严重得多。 后果是收录不完整，一部分页面进不了索引。 熊猫算法对批量低质内容的处理 (https://zhangwenbao.com/google-panda-algorithm-content-farm-recovery.html)那篇的逻辑在这里同样适用。 这个问题在源语言里往往看不出来，因为源语言的模板经过了人工打磨，固定部分有几种变体轮换。机翻会把这几种变体译成同一种说法，多样性在翻译环节就被抹平了。检查方式是统计目标语页面之间的文本相似度，跟源语言的相似度对比，差距明显就说明多样性丢在翻译上了。 处理办法是给模板准备多套目标语的固定段落，或者干脆提高槽位内容的占比，两者都比事后合并页面便宜。 ## 最容易被忽略的那一条：差异化被译没了 你的源语言内容跟竞品的源语言内容差别可能很大。 两边都用机翻译成同一种小语种之后，差别会显著缩小。 因为翻译系统倾向输出最常见的表达方式。 最常见的表达方式对所有人都一样。 结果是目标语市场里，你和竞品的页面文本高度相似。 你在源语言上建立的内容优势，在翻译环节被抹平了。 这一条几乎没人检查，但它可能是机翻最大的隐性代价。可以自己验一下：拿你的目标语页面和竞品的目标语页面做文本相似度对比，再拿两边的源语言页面做一次同样的对比，如果目标语那一侧的相似度明显更高，差异化就是在翻译这一步丢的。 保住差异化的唯一办法是让那些真正体现差异的段落走人工改写而不是翻译，通常整页里只有两三段属于这一类，识别出来单独处理成本可控。 ## 神经机器翻译改变了什么，又没改变什么？ ## 流畅度上去了，错得更像话 神经机器翻译在产品级别上线之后，译文的流畅度明显提升。 这是真实的进步，读起来的自然程度跟以前不是一个量级。 但流畅度提升带来了一个反向效果。 以前的机翻一眼能看出是机器译的，审校者会警惕。 现在的机翻读起来通顺，审校者容易一路划过去。 错误还在，只是更难被发现了，这可以叫流畅度陷阱。 这个陷阱对审校流程的设计有直接影响：审校不能只靠通读，必须配清单。通读能发现的是不通顺，而机翻现在最主要的问题恰恰不是不通顺，是形态选错、术语不一致、关键词没命中这几类清单式检查才能发现的问题。 把审校从读一遍改成过一份清单，这个改动看起来很小，实际是应对神经机翻最关键的一处流程调整。 流畅度陷阱还有一个放大器：审校者本身对目标市场的电商语境不熟。译文语法都对、读起来也顺，一个只做语言审校不懂业务的人很难判断这句话在商品页上合不合适。搜索侧的同义词理解能力 (https://zhangwenbao.com/neural-matching-google-super-synonyms-explained.html)虽然在不断变强，但它理解的是查询和内容的对应关系，不会替你把不合语境的文案改对。 ## 形态、术语、语域三类错一个都没解决 流畅度改善的是句子内部的连贯性。 形态选择的问题源于任务边界，不是模型能力。 术语一致性的问题源于缺少约束，不是模型能力。 语域选择的问题源于缺少业务上下文，不是模型能力。 这三件事换任何模型都不会自动变好。 它们只能靠流程和词表解决，这一点值得反复说。 分清哪些问题会随模型进步而缓解、哪些不会，能省下大量等待的时间。可读性、语法正确性、长句处理这几类会随模型改善；而凡是需要外部信息才能做对的决策，也就是需要知道你的术语表、你的关键词表、你的界面宽度、你的用户构成的那些决策，模型再强也无从下手，因为信息不在它手上。 把机翻当成一个流畅度很好但完全不了解你业务的译者来用，预期就对了。 ## 语料越少的语言，风险越集中 翻译质量跟训练语料的规模正相关。 小语种正好是语料最少的那一批。 所以机翻风险最高的地方，恰恰是最需要靠机翻铺量的地方。 这个矛盾没有办法绕开，只能靠分档策略缓解。 语料越少的语种，档位应该定得越严，抽检比例越高。 而不是反过来因为找不到审校者就放宽标准。 低资源语言的机翻还有一个特点：它的错误分布更极端。多数句子译得不错，少数句子错得离谱，中间态很少。这跟高资源语言的均匀小错完全不同，意味着抽检的作用更大——只要抽中一个离谱的，就说明这一批需要全查，而均匀小错的批次抽检结果反而不好判断。 把语种按语料规模排个序，档位和抽检比例都按这个序调整，比按市场大小调整合理得多。 ## 常见问题解答 ## 用机器翻译加人工审校，算不算违规 不算，前提是审校真的做了而且留下了记录。条款禁的是未经人工审校或整理就发布的机器翻译文本，重心在没有人工介入这一点上，不在用了机器翻译这一点上。判断自己合不合规，可以问三个问题：有没有明确的审校环节写进流程、有没有具体的人对每一批译文负责、有没有可以调出来的改动记录。三个都有就没问题。反过来，如果只是让人快速通读一遍不做任何改动就发布，那实质上跟没审校区别不大，改动率长期接近零的记录本身就是个坏信号。还有一点值得说清楚：合规是底线，不是目标。达到合规之后，内容能不能被目标市场的用户搜到、读懂、信任，那是另一套更高的要求，也是真正决定这批页面有没有价值的部分。 ## 只审校标题不审校正文，风险有多大 比想象中小，但不能长期这么做。标题和分类名承担着关键词匹配和展示的主要功能，把审校资源集中在这里，能用最少的成本挡住最大比例的可见损失。正文的错误主要影响可读性和信任度，这两项的损失是渐进的，短期内不会导致排名问题。所以在铺量阶段，先只审校关键字段是个合理的取舍。风险主要在两处：一是正文里可能藏着规格数字、单位、日期这类错了会出事的内容，这些必须单独检查，不能因为不审正文就跳过；二是长期不审正文会让整个语种版本的质量基线一直很低，等到想往上提的时候，要改的页面量已经大到没法处理了。可行的做法是关键字段全审、正文按品类分批补审，把补审排进后续季度的计划里而不是无限推迟。 ## 怎么判断某个语种的机翻质量够不够用 拿自己的真实文本测，别看通用评测的分数。做法是从站内挑三十段代表性文本，覆盖标题、属性描述、正文段落、界面文案四类，送去机翻，再请母语者按四个维度打分：意思对不对、术语一致不一致、语域合不合适、核心关键词有没有出现。四个维度分开打，因为它们的处理方式完全不同。测完之后你会得到一张具体的短板清单，比一个总分有用得多。常见的结果是意思和语域两项还行，术语和关键词两项很差，那说明这个语种可以用机翻打底但必须配术语表和关键词表。如果连意思都经常错，那这个语种就只能走人工翻译。这套测试成本很低，一个语种半天能测完，而它决定的是接下来可能几十万字的处理方式。 ## 术语表该做多大，两百词够不够 起步两百词足够，但要挑对。优先收三类词：核心品类词、高频属性词、以及所有品牌相关的专有名词。这三类加起来通常一两百个，覆盖的是绝大多数页面上反复出现的那批词，也就是漂移代价最高的那批。不必一开始就求全，收得太多反而没人维护。表格结构建议四列：源词、标准译法、禁用译法、备注。禁用译法这一列最容易被省掉但作用很大，因为漂移往往固定漂向那几个近义词，把它们列出来自动检查就能挡住。后续扩充的依据是命中率检查的结果，反复出问题的词加进表里，长期没争议的词可以不管。术语表要按语种分开维护，同一个源词在不同语种的标准译法各有各的争议点，混在一张表里会很难用。 ## 数字和日期真的不该走翻译流程吗 真的不该，而且这是整篇里最容易执行也最容易被忽略的一条。价格、规格、尺寸、日期、时间这些值都应该以结构化字段的形式存在，输出时按目标语的区域设置格式化，而不是作为文本的一部分送去翻译。这样做有三个好处：格式化规则集中在一处，改一次全站生效；不存在被翻译环节改坏的可能；结构化数据可以直接从同一批字段生成，格式天然合规。实际操作中的阻力通常来自历史遗留，早期的商品描述里把规格数字直接写在文本里了，要抽出来做成字段需要一轮数据整理。这轮整理值得做，因为它解决的不只是翻译风险，还包括筛选器能不能用、比较功能能不能做、结构化数据能不能生成这几件事，收益远超一次性成本。 ## 模板生成的页面用机翻，还有别的办法吗 有，而且比逐页处理便宜。模板类页面的文本可以拆成三部分：完全固定的段落、按槽位变化的短语、以及纯数值字段。固定段落的数量有限，通常几十段，值得请母语者直接写而不是翻译，写好之后所有页面复用，单位成本极低。槽位短语走词表映射，把可能出现的取值列出来一次性译好并审校，也是一次性成本。纯数值字段走格式化输出。这样拆完之后，机翻在模板类页面上的用量可以降到接近于零，质量还比逐页机翻高得多。要注意的是固定段落最好准备两三套轮换，否则目标语版本的页面相似度会过高，这一点在源语言版本里通常已经处理过了，翻译时容易忘记同步。 ## 如果预算只够做一件事，该做哪一件 建术语表，并且把它做成自动检查。理由是这一件事的杠杆最高：成本是整理一两百个词，收益覆盖后面所有批次、所有页面、所有语种。它同时解决了三个问题——术语漂移引起的内部蚕食、品牌名和型号被误译、以及复合词该粘不粘。而且它是唯一一件可以完全自动化验证的事，检查脚本写一次能长期跑，不依赖人力。如果预算能再多一点，第二件事是把数字和日期从文本里抽出来做成字段。第三件才是审校资源的投入，因为在没有术语表的情况下投审校，审校者每次都要重新判断一遍术语该用哪个说法，效率低而且结果还不一致。顺序很重要，先建约束再投人力，反过来做会浪费掉相当一部分审校预算。 ## 权威参考资料 ## 越南泰国印尼被放进同一张东南亚预算表，语言这一层三家没有一处能共用 - URL：https://zhangwenbao.com/southeast-asia-seo-vietnam-thailand-indonesia-language-layer.html - 分类：小语种SEO - 发布：2018-11-06 | 更新：2026-07-25 - 摘要：越南语、泰语、印尼语分属三个语系，空格与语义单元的关系、要不要做词形归并、用户会不会用拉丁字母搜三国答案都不同。讲清十道工序哪几道能共用，三国该按什么顺序做。 - 关键词：关键词研究,出海SEO,多语言SEO,小语种SEO > **TLDR**：摘要：越南、泰国、印尼常被放进同一张东南亚预算表，因为客单价、货到付款比例、移动端占比这些数字确实长得像。但语言这一层，三家分属三个不同语系，任意两门之间的距离比欧洲任意两门语言都远。空格与语义单元的关系、要不要做词形归并、用户会不会用拉丁字母搜，三个国家给出的是三个互不相干的答案。 > 摘要：越南、泰国、印尼常被放进同一张东南亚预算表，因为客单价、货到付款比例、移动端占比这些数字确实长得像。但语言这一层，三家分属三个不同语系，任意两门之间的距离比欧洲任意两门语言都远。空格与语义单元的关系、要不要做词形归并、用户会不会用拉丁字母搜，三个国家给出的是三个互不相干的答案。 ## 为什么东南亚这个预算单位在语言层立不住？ ## 三门语言分属三个语系，比欧洲任意两门都远 越南语属南亚语系，泰语属壮侗语系，印尼语属南岛语系。 三个语系之间没有共同祖语，词根、语法结构、构词方式全无对应关系。 拿欧洲做参照会更直观：德语和波兰语听着差别巨大，两者仍同属印欧语系。 捷克语和斯洛伐克语能讨论内容复用，因为它们是同一语族的近亲。 越南语和泰语之间不存在这种关系，连基本词汇的同源对照都找不出几组。 所以任何以共享词根为前提的复用判据，在这三家身上都是空转。 地理上的相邻很容易被读成语言上的相近，这个误读代价不算小。三个国家的首都直线距离都在两千公里以内，签一份区域代理协议、办一场区域发布会都完全合理，唯独内容生产这条线，相邻两国之间可搬运的东西比中国和德国之间还少。 判断一批市场能不能共用内容，别看它们在地图上离多近，看它们的语言在谱系树上离多远，后者才是决定可搬运面的那个变量。 还有一个容易被忽略的连带影响：三门语言的搜索行为研究成果互不通用。在越南市场做出来的用户查询习惯结论，搬到泰国一条都不成立，这跟北欧三国之间至少能互相参考形成鲜明对比。所以三国的用户研究预算也得各算一份，不能靠一份区域报告打天下。 ## 非语言字段的相似度到底骗了谁 三国的电商基础设施确实高度相似，这不是错觉。 货到付款比例都偏高，社交渠道带来的流量占比都远超欧美。 移动端占比都在八成以上，客单价带也落在相近的区间。 物流时效、退货习惯、大促节奏这些运营变量，跨国之间差异不大。 于是做区域预算的人会得出一个很自然的结论：这是一个市场。 这个结论在渠道、支付、客服排班上成立，在关键词表上完全不成立。 保哥接过一个做户外露营装备的客户，团队按东南亚统一立项，把三国内容排成同一条流水线，前两个月产出很漂亮，第三个月开始三国的收录曲线彻底分叉：印尼站正常爬升，越南站有一半标题被搜索结果页截得不成话，泰国站的商品页干脆搜不到自己的核心品类词。 相似度是分层的，越靠近钱的那几层越像，越靠近语言的那几层越不像，预算表却只有一个国家维度，这才是真正的问题所在。 ## 近亲语言的三套框架为什么一套都用不上 站内已经沉淀了三套处理多市场的框架，各有适用前提。 两个市场跨国的用二选一判据，比如捷克语和斯洛伐克语那一对 (https://zhangwenbao.com/czech-slovak-seo-content-reuse-decision.html)。 三个及以上市场的用资产分层，比如瑞典挪威丹麦三家 (https://zhangwenbao.com/nordic-seo-swedish-norwegian-danish-content-sharing-boundary.html)。 两个市场同处一国的用分工模型，比如乌克兰语和俄语那一对 (https://zhangwenbao.com/ukrainian-russian-seo-bilingual-market-content-split.html)。 这三套的共同前提是：语言之间存在一个非零的可复用面。 东南亚三国的这个面接近于零，所以框架不是选错了，是没有可选的东西。 可复用面为零并不意味着无从下手，只是提问方式要换。原来的问题是这些内容能共用多少，现在的问题变成这条生产线上的哪几道工序能共用——工序是流程层的东西，跟语言谱系无关，所以即便文本一个字都搬不动，方法、模板、口径、排期逻辑仍然可以整块共用。 把这三国当成第五种情形来记：零可复用面的多市场，复用判据全部作废，改用工序判据，后面会给一张十道工序的对照表。 还有一个判断方法很省事：拿三国的核心品类词摆在一起看字符长度和结构。可复用面存在的语言对，同一个概念的写法通常长度接近、结构类似；东南亚这三家摆出来是三串毫无相似之处的字符，长度还差着倍数，看一眼就知道复用这个方向不用再讨论了。 ## 空格和语义单元的关系，三国给出三个答案？ ## 越南语的空格数量多于语义单元数量 越南语用拉丁字母书写，词与词之间有空格，看着最像英语。 但那些空格切的是音节，不是词。 一个概念常常由两三个音节组成，写出来就是两三段被空格隔开的字符。 比如运动鞋写成三段，防晒霜、保温杯这类日用品词也大多是两到三段。 用空格数去估词数，会把词的数量高估两三倍。 这种高估会直接传染给关键词表的规模判断和标题长度的规划。 更实际的影响在标题截断上。搜索结果里给标题的展示宽度是按字符算的，越南语表达同一个概念要用掉的字符数明显多于印尼语，同一套标题模板套上去，越南站被截掉尾部的比例会高得多，而被截掉的那一段往往正是品牌名。 所以越南语这一路要做的第一件事不是选词，是先量清楚核心品类词的字符长度分布，再回头定标题模板的槽位顺序，把最不能丢的成分往前放。 ## 泰语的空格数量几乎为零 泰语在句子内部基本不用空格，一句话是一整串连续字符。 空格只在句末或者短语群之间偶尔出现，它不承担切词功能。 切词由搜索引擎的词典和算法完成，切点不在写作者手上。 泰语的分词与词典切分那篇 (https://zhangwenbao.com/thai-seo-no-spaces-word-segmentation-keyword.html)把这套机制讲透了，这里只取它对区域预算的影响。 影响是：泰语这一路必须先建立词边界的判断能力，才能开始选词。 这道前置工序在越南和印尼两路都不存在，工时是凭空多出来的。 词边界这件事还会往下游渗透。标题里插一个空格会改变引擎对边界的判断，商品名和属性词连写还是分写会得到不同的切分结果，同一个页面在不同分词器下能命中的查询集合并不一样，这些都得靠实测而不是靠语感来定。 把泰语这一路的排期往后放，不是因为它不重要，是因为它的第一道工序就要吃掉别人两路加起来的时间。 还有一处影响落在锚文本上。无空格语言里，锚文本的边界跟视觉上的词边界不一定重合，选多长一段做锚会直接改变引擎读到的关键词，这跟拉丁字母语言里画一个词做锚就完事的做法差别不小，越南和印尼两路都没有这道功课。 ## 印尼语是三家里唯一正常的那一个 印尼语的空格数量基本等于语义单元数量。 一个词就是一段字符，词与词之间有空格，切分符合直觉。 纯拉丁字母书写，不带变音符号，也没有额外的组合字符。 关键词工具对它的支持度是三国里最好的，返回的数据也最像样。 如果只看语言层的门槛，印尼语可能是全部小语种里最低的几个之一。 这个低门槛是印尼这一路应该排在最前面的主要理由。 但正常也有代价。门槛低意味着竞争者进得也快，印尼市场的搜索结果页里，国际大平台和本地大平台的占位比另两国更满，语言层省下来的力气，最后多半要花在内容深度和外链上，这两样都比选词贵。 把印尼当成练手市场是个好主意，把它当成容易拿量的市场就危险了，两者差在竞争密度而不是语言难度。 ## 关键词表的行数为什么会差出三倍 同一份品类清单翻成三种语言，产出的关键词行数完全不同。 印尼语最少，一个概念基本对应一到两个写法。 越南语中等，音节切分会带来分写与连写的变体。 泰语最多，词边界的不同判断会派生出好几种可能的查询串。 行数不同意味着建表工时、审校工时、监控成本全都不同。 按国家平均分配这三项预算，等于让最难的那一路系统性欠资源。 行数差异还会让第三方工具的数据可信度分化。词表行数越多、单行搜索量越低，工具返回零和无数据的比例就越高，工具返回零到底是数据缺口还是需求缺口 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)那一篇讲的补数据办法，在泰语这一路的使用频率会明显高于另两路。 做区域预算时把关键词表的预期行数先估出来，用它当权重去分配工时，比按国家平摊靠谱得多。 行数差异还会传导到监控成本上。要盯的关键词行数差三倍，报表的行数、告警的阈值、异常排查的工时也跟着差三倍，如果三国用同一套监控配置，泰语这一路的告警会天天响，响到最后没人看，这比不设告警还糟。 ## 构词法差异怎么决定要不要买词形工具？ ## 越南语靠单音节组合，不做词形变化 越南语是孤立语，词本身不变形。 没有格变化，没有性数一致，动词也不按人称变位。 表达不同意思靠的是把单音节按顺序组合起来。 这对关键词研究是个好消息：一个词只有一种写法。 不需要像波兰语那样为七个格各准备一批变体页面。 省下来的力气应该转到声调符号的两套写法上，那才是越南语真正的分叉点。 带声调和不带声调是两拨搜索行为 (https://zhangwenbao.com/vietnamese-seo-tone-marks-syllable-spacing-keyword.html)这件事，本质上是输入法成本造成的用户分层，跟词形变化完全是两码事。词形变化是语言规则带来的必然分叉，输入习惯带来的分叉则可以靠覆盖策略解决。 越南语这一路的词形工具需求为零，把这笔预算直接划到变体覆盖和标题长度治理上更有价值。 ## 印尼语的前缀、后缀和环缀会把词形撑开 印尼语的构词法在三家里是最活跃的那一个。 一个词根可以带前缀、带后缀，也可以前后同时带，也就是环缀。 发送这个词根能派生出主动态、名词化、被动态、完成态好几种形态。 用户搜的可能是任意一种，页面上写的往往只有一种。 这是印尼语唯一一处需要认真处理的语言层工作。 处理方式是建立词根到形态的映射，而不是逐个形态铺页面。 好在这门语言的词干处理有成熟的开源实现，规则型的词干算法对它的效果相当不错，因为它的词缀规则比屈折语规整得多，属于少数几个能用算法解决大半问题的语种，这一点在印尼语和马来语能不能合并成一套 (https://zhangwenbao.com/indonesian-malay-seo-two-markets-vocabulary-split.html)那篇里也提到过。 所以三国里只有印尼这一路要为词形归并留预算，而且这笔预算数额不大，一次性建好能长期复用。 词缀这件事还有一个正面用途：它能帮你反推用户的搜索阶段。带完成态词缀的查询多半是已下单的用户在查物流，带名词化词缀的查询多半是在了解服务，带主动态词缀的才是有购买动作的。同一个词根的不同形态，恰好对应意图漏斗的不同位置，这是印尼语独有的一份免费信号。 ## 泰语的连写不是词形变化，别混为一谈 泰语也是孤立语，词本身同样不变形。 它的复杂性全在书写和切分上，不在形态上。 连写造成的多种可能切法看起来像变体，实际不是。 词形变体是同一个词的不同形态，多种切法是同一串字符的不同解读。 前者要做的是归并，后者要做的是确认边界。 把泰语的切分问题当词形问题去处理，会买到一堆用不上的工具。 这两件事的检查顺序也不一样。词形归并可以在关键词表建好之后再做，边界确认必须在建表之前完成，否则表里的每一行都可能是个错误的字符串，后面所有基于这张表的判断都跟着错，返工成本比先做一遍高得多。 一句话记住三家的区别：印尼语要归并形态，越南语要覆盖输入变体，泰语要先划边界，三件事互不替代。 ## 书写系统带来的技术工时，为什么差出六倍？ ## 越南语的组合变音与规范化不一致 越南语用拉丁字母加变音符号书写，一个字母上可能叠两个记号。 同一个字符在编码上有两种表示：预组合的单一码位，或者基字母加组合记号。 两种表示肉眼完全一样，字节序列完全不同。 后台粘贴、接口传输、导入导出的环节里，两种形式经常混在一起。 结果是同一个词在数据库里有两种写法，去重去不掉，搜索匹配也对不上。 解法是在入库前做统一规范化，把所有文本收敛到同一种形式。 这道工序的位置很关键，它必须在关键词表入库和商品数据入库两个入口都设一遍，只在前台展示层做规范化是没用的，因为不一致的数据已经在库里了，后面的统计、去重、匹配全部基于脏数据在跑。 越南语的技术账里，规范化是最容易漏且返工最贵的一项，值得在立项时就写进技术方案。 规范化这件事还有一个隐蔽的表现形式：搜索表现报告里同一个查询词出现两行。看上去像是工具出错，实际是用户的两种输入法产出了两种字节序列，两行都是真实数据。发现这种情况说明你的规范化没做到入口层，得从表单和接口开始查。 ## 泰文要同时处理分词和换行两套算法 泰文是独立书写系统，字符集跟拉丁字母毫无重叠。 它需要处理两件独立的事：词从哪里断开，行从哪里折。 词的断开归分词算法管，行的折断归换行算法管。 两者用的规则不一样，任何一边处理不当都会出可见的问题。 分词错了影响的是被搜到的能力，换行错了影响的是读得下去的能力。 移动端窄屏上换行问题格外明显，一个词被折成两半是常态。 字形集的体积也是泰语这一路要单独算的一笔账，泰文的字符集虽然不算大，但它的组合定位规则复杂，字体文件里要带的定位表比纯拉丁语言多不少，这笔首屏成本在字形集怎么拖垮首屏 (https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html)那篇里量过。 把三国的技术工时按四比六比一去排，越南四、泰国六、印尼一，这个比例是按上面这些具体工序估出来的，比按国家平摊准得多。 ## 印尼语的零技术成本换来了什么 印尼语是纯基本拉丁字母，没有变音符号，没有组合字符。 编码、排序、换行、字体全部走英语那套默认配置就行。 技术SEO这一层几乎不需要为语言做任何额外工作。 省下来的时间应该花在内容深度和属性字典上。 因为印尼市场的竞争强度不允许只靠语言层的正确性取胜。 零成本是相对的，它只是把成本从技术层挪到了内容层。 这个挪动其实是有利的。技术层的成本是刚性的，做不完就是有bug；内容层的成本是弹性的，可以按优先级分批投入，还能在过程中不断校准方向。三国里印尼这一路的可控性最好，主要就来自这一点。 立项时把印尼排在最前面，还有一个附带好处：它能在语言层几乎不干扰的条件下，先把整条流水线的流程跑通一遍。 还有一件事印尼语这一路可以省掉：排序和索引导航。纯基本拉丁字母的字母表顺序跟默认排序完全一致，字母导航直接用就行，不像捷克语要处理双字母当一个字母排、也不像匈牙利语要处理多字母组合的顺序，这两处坑在印尼语里根本不存在。 ## 用户会不会用英文搜，三国差多少？ ## 印尼语的外来语已经本土化到分不出来 印尼语吸收外来词的能力很强，吸收之后也改得彻底。 运费、促销、折扣、免费这几个高频电商词都有本土化的说法。 其中有些是缩写形式的口语词，正式词典里未必收，用户天天在用。 同时印尼用户直接打英文搜索的比例也不低。 所以印尼这一路要覆盖三种写法：正式词、口语缩写、英文原词。 三套都得进关键词表，落地页上至少要能被前两套命中。 口语缩写这一类最容易被漏掉，因为它不在任何权威词典里，只能从站内搜索日志、社交平台的评论区、以及当地电商平台的搜索建议里捞。捞出来的词还要判断哪些已经稳定、哪些是短期流行，前者可以做落地页，后者只适合做内容。 把印尼语的关键词表设计成三列结构，正式、口语、英文各一列，一开始就分开管，比后面再拆省事。 ## 越南语处在中间态，两边都要接 越南用户会用英文搜，但比例低于印尼。 越南语自身的词汇体系比较完整，多数商品概念都有本土说法。 英文更多出现在技术产品、品牌名和型号上。 日用品和服饰类的搜索几乎全用越南语。 所以英文变体的覆盖要按品类分，不能一刀切全做。 把预算集中在声调符号的两套写法上，回报明显更高。 判断某个品类要不要做英文覆盖，有个简单办法：看这个品类的商品名里有没有型号和规格。有型号的品类用户大概率直接打英文型号，没有型号的品类用越南语的比例接近百分之百，这条规律在三国都成立，只是分界线的位置不同。 越南语这一路的英文覆盖属于按需投入，不是必做项，把它放在声调覆盖之后再考虑。 型号这条线还带来一个附加动作：越南语页面上要同时保留型号的原始写法和越南语的品类词，两者出现在同一个标题里。这样打型号的用户和打品类词的用户都能被接住，而这两拨人在越南市场的比例大致是三七开，都不能丢。 ## 泰语用户为什么几乎不用拉丁字母搜索 泰语用户打字用泰文键盘，切换到拉丁字母要额外操作。 这个切换成本不高，但在搜索这种高频短行为里足以形成习惯分层。 结果是泰语市场的拉丁字母查询占比明显低于另两国。 这跟希腊语市场的情况正好相反，那边用拉丁转写搜的人相当多。 差别在于希腊语的拉丁转写有长期的社群使用传统，泰语没有。 所以泰语这一路可以基本放弃拉丁转写的覆盖，把资源集中在分词上。 希腊语的拉丁转写覆盖 (https://zhangwenbao.com/greek-seo-greeklish-latin-transliteration-coverage.html)那篇讨论的是转写有传统时该怎么做，泰语这里是转写没传统时该怎么省，两篇的结论方向相反，但用的是同一个判据：看这门语言的用户社群有没有形成稳定的转写习惯。 三国的英文与转写策略可以用一句话总结：印尼三套全做，越南按品类做，泰国基本不做。 ## 一门语言几个市场，这道题只有印尼这一路要答？ ## 宏语言和个体语言在标准里的关系 语言标准里有一个宏语言的概念，用来罩住一组关系极近的个体语言。 马来语就是这样一个宏语言，底下挂着若干个体语言编码。 印尼语和马来西亚的标准马来语在标准里是分开编码的。 这个编码结构本身就说明了问题的性质：它们既不是一门语言，也不是两门无关的语言。 标准给出的是一个中间态，而中间态恰恰是最难决策的形态。 所以印尼这一路多出一道决策：马来西亚要不要单独做一套。 标准里的这个结构还有个实用价值，它能替你回答一个常被争论的问题：这两个市场到底算不算同一个语言市场。答案是标准把它们视为同一个宏语言下的不同个体语言，也就是说共性足够大到能归在一起，差异也足够大到要分别编码，两边的直觉都对了一半。 把这道决策留在印尼这一路的排期里，别让它污染越南和泰国的方案，那两路根本没有这个问题。 ## 马来西亚要不要单独做的判据 先数市场个数，两个市场跨国，套二选一框架。 再看词汇分叉的密度有多高。 电商高频词里，运费、包裹、品牌这几个概念两地用的是不同词。 但商品品类词、属性词的重叠度相当高。 这种分叉分布意味着第一档可复用面比较大：结构可以共用，词表要分开。 结论通常是先做印尼，马来西亚等印尼站跑顺之后再单独出一套词表。 还要考虑马来西亚市场本身的语言构成，那里英语和华语的使用比例都不低，纯马来语内容能覆盖的用户比例并没有想象中那么高。这条会显著影响马来西亚这一路的投入产出比，也是它排在印尼之后的另一个理由。 一句话：马来西亚是印尼这一路的延伸决策，不是第四个独立市场，排期上挂在印尼后面，不占新的坑位。 这道决策还有一个成本项容易被漏：两地的域名和支付配置是分开的，就算内容能复用九成，非语言字段那一套还得重建一遍。这跟捷克斯洛伐克那一对遇到的情况一样，语言层的省钱不等于整体的省钱，评估时要把两笔账分开算。 ## 越南语和泰语为什么不用答这道题 越南语基本只在越南使用，海外社群的搜索行为对生意影响有限。 泰语基本只在泰国使用，情况类似。 两门语言都没有跨国的第二大市场。 所以它们的语言层和国家层是一对一的，不需要做市场拆分。 这在小语种里其实是省事的形态，多数欧洲小语种都没这个待遇。 省下的这道决策成本，可以理解为对它们语言层高门槛的一点补偿。 一对一还有个连带好处：地区定向、货币、物流、法务这些非语言字段可以跟语言绑成一套，不用像西班牙语或者葡萄牙语那样为同一门语言维护多套非语言配置，架构上的复杂度低不少。 做三国横向对比时把这一项也列进表里，它虽然不产生工时，但会影响架构方案的复杂度评估。 ## 十道工序里哪几道能三国共用？ ## 可以整块共用的那四道 品类树和属性字段的定义可以共用，这是概念层的东西。 商品图、尺寸表、参数表可以共用，它们不含自然语言。 关键词种子清单可以共用，前提是这份清单用中文或英文记概念，不记词。 站内搜索日志的挖词方法可以共用，方法是流程，词表不是。 这四道共用能省下的工时相当可观，大概占整条线的三成。 更重要的是它们能保证三国的数据结构一致，后面做对比分析才有基础。 种子清单这一道有个容易踩的坑：一旦有人图省事把英文的关键词直接写进种子清单，后面三国的译者就都会围着那个英文词转，产出的三份词表会带上同一个偏差。种子清单里只放概念描述，不放任何目标语言的候选词，这条要写进规范。 共用不等于随便复制，共用的那部分要有单一来源和版本控制，否则三国各自改一改，半年后就变成三份互不兼容的东西了。 ## 必须一国一套的那四道 分词与切词方案必须一国一套，三国的机制完全不同。 词形归并规则必须一国一套，而且只有印尼这一路真的需要。 关键词量级预期和工具口径必须一国一套，行数差三倍。 正文写作和语域必须一国一套，这是最费钱也最没法省的一道。 这四道加起来大概占整条线的五成工时。 它们的共同点是都直接咬在语言规则上，而三国的语言规则零交集。 语域这一道最容易被低估。三个市场对正式程度、称呼方式、促销语气的接受度都不一样，同一段文案在印尼读着热情、在泰国读着轻浮、在越南读着生硬是完全可能的，而这类问题任何工具都测不出来，只能靠母语审校。 做排期时把这四道单独拉出来按国家开三条并行的线，别塞进同一个任务池，否则最难的那一路永远排在最后。 还有一个执行层的提醒：这四道工序的交付物要各自独立版本化，别放在同一个文档里。三国的分词方案、词形规则、口径定义、写作规范如果混在一份文件里，任何一国的修改都会引起另两国的确认成本，拆开之后各改各的，协作摩擦能少一大半。 ## 骨架共用、槽位分开的那两道 标题模板属于这一类：骨架可以共用，槽位内容按国家填。 页面结构也属于这一类：模块顺序共用，模块内的文本分开。 这两道的处理方式是把模板抽象成带槽位的结构。 槽位的顺序可以按国家覆写，因为字符长度差异会影响截断。 越南语的槽位顺序大概率要跟另两国不一样。 这类工序是共用和分开之间的过渡态，最需要明确的规范。 槽位顺序按国家覆写这件事值得多说一句：它意味着模板系统必须支持按语言覆写排序，而不只是支持按语言替换文本。这个需求如果在立项时不提，多半要等到发现越南站标题大面积被截才被迫返工，那时候模板已经铺开几千个页面了。 模板这一层的技术需求要在立项阶段就提清楚，它是三国方案里唯一需要工程侧配合的共用项。 ## 工序表怎么变成一张能用的排期 先把十道工序按共用、分开、过渡三类标好。 共用的那几道排在最前面，一次做完给三国用。 分开的那几道按国家开并行线，按技术工时比例配人。 过渡类的排在共用之后、分开之前，因为它要给分开的那几道定框。 这个顺序能让三国的启动时间错开，而不是三条线同时抢资源。 实际排下来通常是印尼先跑通，越南跟上，泰国最后但用时最长。 排期里还要留一道回头工序：印尼跑通之后回看共用的那四道有没有需要修的地方。第一个市场跑一遍总会暴露出概念层的疏漏，这时候修的成本最低，等三国都铺开了再改共用层，改动会传导到三处。 这张表是本篇最该带走的东西，它把零可复用面这个坏消息，转化成了一份可以照着排的工序清单。 ## 工具口径把三国合成一个数，会错在哪？ ## 东南亚和亚太这两个假口径 第三方工具经常提供区域维度的数据，东南亚和亚太是最常见的两个。 这两个口径在语言层是没有意义的聚合。 它们把三种互不相干的语言的数据加在一起给出一个总数。 总数会掩盖三国之间的巨大差异，也会掩盖单一市场的机会。 更麻烦的是这个总数看起来很像一个可以汇报的数字。 汇报出去之后，后续的决策就都建立在一个没有语言意义的聚合上了。 这个坑跟北欧三国被合成斯堪的纳维亚一个口径是同一类错误，只是东南亚这个聚合更粗糙——北欧三国至少语言相近，东南亚三国连语系都不同，合并之后的数字连方向性参考价值都很有限。 要用区域数据的话，只在非语言字段上用，涉及关键词、搜索量、竞争度的一律拆到国家维度看。 ## 三国的引擎份额其实并不一样 泰国和印尼的搜索基本集中在一家引擎上。 越南多了一个本土引擎分走一部分份额。 这个差异对关键词工具的数据代表性有直接影响。 工具的数据来源多半只覆盖主流引擎，越南的数据会少一块。 少的这一块正好偏向那些只用本土服务的用户群。 引擎打法本身归引擎层管，这里只提它对数据口径的影响。 本土引擎这一块要怎么做属于另一个话题，语言层这边只需要知道一件事：越南的关键词数据要打一个折扣看，实际需求量比工具显示的更高，这个折扣的具体幅度只能靠站内数据反推。 做三国对比时把引擎份额单独列一行，它是解释数据差异的重要变量之一。 本土引擎这一块还有个数据层面的连带影响：它会让越南站的自然流量归因失真。一部分来自本土引擎的流量在分析工具里可能被归到直接访问或者其他来源，看着像是自然搜索表现不如另两国，实际是统计口径漏了一块，这个差异要在解读报表时先扣掉。 ## 自己建口径需要的最低配置 三国各自的站内搜索日志，这是最真实的一手数据。 三国各自的搜索表现数据，按国家维度拆开导出。 三国各自的关键词工具数据，标注清楚工具和抓取时间。 三份数据放在一张表里，按国家维度对齐，不做区域聚合。 这套最低配置的成本不高，主要是建立习惯的成本。 建好之后，任何区域口径的数字都能被这张表反驳或者验证。 这张表还有个长期价值：它能记录三国的差异是怎么随时间变化的。语言层的差异是稳定的，但用户行为层的差异会变，比如印尼用户打英文的比例、越南用户打声调的比例，这些数字每年都不太一样，只有自己长期记录才能看出趋势。 口径这件事的原则很简单：非语言字段可以合，语言字段必须拆，中间没有折中的余地。 ## 母语审校的人力账，三国差多少？ ## 三国审校人才的可获得性差得明显 印尼语的母语审校人才最容易找，成本也最低。 越南语次之，有一定规模的从业者群体。 泰语最难，同时懂电商和懂搜索的泰语母语者数量有限。 难找不只是价格问题，还包括交付稳定性和替补的可得性。 一个人负责一个市场的安排，在泰语这一路风险最高。 所以泰语这一路要么提前储备两个人，要么把审校范围收窄。 收窄范围是更现实的做法。把审校集中在标题、分类名、属性词这些高杠杆位置，正文允许先用较低标准发布再迭代，这样一个审校者能覆盖的页面数量能翻几倍，代价是正文质量的天花板会低一些。 找人这件事的渠道跟外链渠道有重叠，小语种的本地目录、行业媒体和语言社区 (https://zhangwenbao.com/minor-language-link-building-local-directories-media-communities.html)那篇里挖资源的路径，同样能用来找母语审校者。 ## 审校范围要按语言难度重排 印尼语可以做全文审校，成本能承受。 越南语建议做全文审校加声调变体的专项检查。 泰语建议先做高杠杆位置的审校，正文分批跟进。 这个分配跟按国家平摊完全不同，是按语言难度和人才可得性排的。 三国的审校预算比例大致是二比三比五，泰语最贵。 比例会随着人才储备的改善逐年调整，但方向短期不会反转。 审校的产出不只是改好的文本，还应该包括一份错误类型清单。清单积累到一定量之后，可以反过来变成写作规范，让后面的初稿少犯同类错误，这才是审校投入真正能沉淀下来的资产。 把审校当成一次性的质检环节是最浪费的用法，把它当成规范的来源，同一笔钱能产生两份价值。 审校范围收窄之后要配一道抽检。高杠杆位置全审、正文抽审，抽检比例按品类的营收贡献排，重点品类抽三成、长尾品类抽一成。这套安排的好处是既控住了成本，又能拿到正文质量的真实分布，不至于对自己的内容水平一无所知。 ## 一次性建立的资产能摊多久 属性字典、术语表、写作规范都是一次性资产。 它们建好之后能摊到后面所有的页面上。 三国各需要一套，但每套的建立成本远低于逐页审校。 这三套资产是把审校从持续成本变成阶段成本的关键。 建立顺序跟市场顺序一致：印尼先建，越南跟上，泰国最后。 前面市场的建立过程会产出模板，后面的市场能省下摸索的时间。 估算摊销周期时按页面数而不是按时间算。术语表在一个只有两百个页面的站上作用有限，在两千个页面的站上就是决定一致性的关键设施，所以它的投入时点应该跟页面增长的节奏挂钩，太早建会因为品类还没定型而反复修改。 三国的资产建设可以并行准备但要串行验证，让第一个市场把模板验出来，另两个市场直接抄结构。 ## 三国到底按什么顺序做？ ## 按人口排是最容易犯的那个错 印尼人口两亿多，越南九千多万，泰国六千多万。 按人口排的话顺序是印尼、越南、泰国。 这个顺序碰巧跟正确答案接近，但推理过程是错的。 人口不等于搜索需求，搜索需求不等于可获得的份额。 如果换成另一组国家，按人口排会得出完全错误的顺序。 推理错了而答案对，是最危险的一种正确。 为什么危险？因为下一次遇到不同的国家组合，同一套推理会给出错误答案，而团队会因为上一次成功而更加信任它。小语种按母语人口排优先级会排出什么问题 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)那篇算过这笔账，结论是人口这个变量单独用几乎没有预测力。 排序这件事要用可以复用的判据，而不是碰巧对的直觉，判据的价值在于它下一次还能用。 ## 语言层单位成本乘市场规模才是判据 先算每个市场的语言层单位成本，也就是前面那份工时比例。 再估每个市场可获得的搜索需求规模。 两者相除得到一个投入产出的粗略排序。 印尼语言层成本最低、市场最大，排第一没有争议。 越南语言层成本中等、市场中等，排第二。 泰语语言层成本最高，排第三。 这个判据的好处是它对每个变量都可以单独修正。如果某年泰语的审校人才突然变得容易找了，成本项下降，排序就可能变化；如果越南的本土引擎份额继续上升，可获得规模的估算方式也要调整。同一个词在两个市场问的不是一件事 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)那篇讲的意图分叉，也会影响可获得规模的估算精度。 把这两个变量写成表格，每季度复核一次，比一次性定死排序要稳。 这个判据还有一个用法是反向的：拿它去解释已经发生的结果。如果某个市场投了一年没起来，把两个变量拆开看，是语言层成本估低了，还是可获得规模估高了。两种原因的补救方式完全不同，前者要加资源，后者要减预期，混在一起看就只能得出这个市场不行的结论。 ## 泰国排最后，却可能是最值得等的那个 泰语的语言层门槛最高，这是它排最后的原因。 但门槛高对所有竞争者都成立，包括国际大平台。 所以泰语市场的搜索结果页里，做对了语言层的站点比例明显更低。 这意味着一旦做进去，竞争密度比另两国低得多。 门槛既是成本也是护城河，这两面通常同时出现。 排最后不等于优先级低，它是等资源到位再做的意思。 判断一个高门槛市场值不值得等，看两件事：门槛是不是一次性的，以及门槛过了之后有没有持续优势。泰语的分词能力属于一次性建设，建好之后长期有效，而竞争者稀薄这个优势会持续存在，两条都满足，所以值得等。 把泰国放在第三位的同时，在前两个市场的排期里就开始储备泰语审校人才，等到第三阶段启动时不至于卡在找人上。 ## 一份可以照着排的一年期样本 第一季度做共用的四道工序加印尼站启动。 第二季度印尼站铺量，同时回头修共用层的疏漏。 第三季度越南站启动，重点是规范化和标题长度治理。 第四季度泰国站启动，第一件事是词边界的实测。 马来西亚这一路挂在印尼后面，视印尼的产出情况决定是否开启。 这份排期的核心不是时间点，是让三条线的启动错开。 错开启动最大的价值是让每条线都能吃到前一条线的经验。三国的语言层零交集，但流程层的坑高度重合，第一条线踩过的流程坑，后两条线能省下大半的返工。至于架构层的域名结构、地区定向、语言标注这些问题，跟具体语种无关，国际化SEO和多语言站的hreflang怎么落地 (https://zhangwenbao.com/international-seo-hreflang-complete-guide.html)那篇讲得比这里细。 把这份样本当模板改，别当计划抄，每个团队的资源结构不同，能并行的程度也不同。 ## 常见问题解答 ## 东南亚三国的内容能不能先用一套英文版过渡 不建议，而且这个做法的失败方式很隐蔽。英文版在三国都能被一部分用户读懂，所以上线之后不会立刻出问题，甚至会有一些流量进来，团队容易误判为可行。真实情况是这些流量来自那批本来就会用英文搜的用户，他们通常也已经在用国际平台，转化价值有限，而占绝大多数的本地语言搜索需求完全没有被接住。更糟的是英文版会占住页面位置和内链结构，等到要换成本地语言版本时，涉及URL、重定向、内链重写一整套改动，成本比一开始就分开做要高。如果实在要过渡，可行的折中是只用英文做少量的信息型内容测试市场反应，商品页和分类页从第一天就用本地语言，因为那才是需求最集中也最不可替代的部分。 ## 三国里如果只能选一个先做，应该选哪个 选印尼，理由不是市场最大，是语言层门槛最低所以流程能最快跑通。第一个市场的真实作用是把整条生产线验一遍，包括共用工序有没有疏漏、模板系统的槽位设计够不够灵活、审校流程能不能按时交付、数据口径拆得对不对。这些问题在语言层干扰最小的市场里暴露出来，最容易定位也最容易修。如果第一个选泰国，团队会花大量时间在词边界这类语言层问题上，流程层的疏漏会被这些问题掩盖，等到做第二个市场时同样的坑还得再踩一遍。选印尼还有一个附带好处，它的关键词工具数据质量最好，团队能拿到相对可靠的数据来校准自己的估算方法，这套校准过的方法后面用在数据更差的市场上才有底气。 ## 为什么不能把越南语当成拉丁字母语言来处理 因为它只有字母是拉丁的，其余全都不像。变音符号带来的组合字符问题、一个概念占多个空格段的问题、声调符号的两套输入习惯，这三件事在任何西欧拉丁字母语言里都不存在。实际操作中最常见的误判是把越南语的默认配置抄英语站的，然后发现数据库里同一个词有两套字节序列、标题在搜索结果里被截掉品牌名、关键词表里的行数比预估多出两倍。这三个问题都能修，但都属于返工。判断一门语言能不能套拉丁默认配置，有个简单的检查：看它有没有组合变音、有没有多种规范化形式、空格是不是切词。越南语三项全中，所以它需要一套自己的技术方案，跟印尼语那种真正的纯拉丁语言完全不是一个待遇。 ## 泰语的分词方案是自己建还是用现成的 用现成的做基础，自己补品类词。泰语的分词有多个成熟的开源实现，词典型和统计型都有，直接拿来用能解决通用文本的大部分情况。需要自己补的是商品品类词、品牌名、型号这类专有词汇，通用词典里几乎不会收，而它们恰恰是电商站最重要的那批词。补的方式是维护一份自定义词典，把品类树里的词和品牌名都加进去，让分词器认得它们。还有一件事比选工具更重要：搞清楚目标引擎实际是怎么切的。你本地用的分词器和引擎用的不是同一套，本地切对了不代表引擎也切对了。可行的验证办法是拿几组已知的查询串去实测排名和展现，反推引擎的切分倾向，这比研究工具文档有用得多。 ## 印尼语的词形归并能不能直接用现成的词干工具 大部分情况可以，但要接受它的边界。印尼语的词缀规则比屈折语规整，规则型的词干算法对它的处理效果相当不错，通用文本上的准确率足够支撑关键词归并这类应用。不适用的地方主要是两类：一类是词根本身以词缀形式开头的词，算法会误切；另一类是外来语和缩写，算法根本没见过。处理办法是建一份例外表，把这两类词标出来跳过算法。另外要注意归并的用途，如果只是用来给关键词表分组、判断哪些词属于同一个概念，现成工具完全够用；如果要用它来生成页面上的实际文案，那就不行，因为词干形式往往不是一个自然的词，直接写到页面上会显得很奇怪。归并是分析工具，不是写作工具，这条界要划清。 ## 三国的关键词表能不能共用一套结构 结构可以共用，而且应该共用，但字段数量会不一样。共用的部分包括概念标识、品类归属、意图分类、优先级、对应落地页这几个字段，它们跟语言无关，共用之后三国的数据才能对齐分析。差异出现在语言字段上：印尼语需要正式词、口语缩写、英文原词三列；越南语需要带声调和不带声调两列，加上按品类开启的英文列；泰语需要多种可能切分形式的列，数量不固定。所以设计表结构时把语言相关的字段设计成可扩展的形式，别写死列数。另外强烈建议在表里加一个字段记录这一行的数据来源和采集时间，三国的数据可靠性差异很大，不标来源的话，半年后没人分得清哪些数字是工具给的、哪些是站内日志反推的、哪些是当时拍的。 ## 越南的本土引擎需要单独做一套内容吗 不需要单独做内容，但要单独做验证。内容层面，本土引擎的用户搜的还是越南语，用的还是那批词，所以关键词表和落地页不用分两套。需要分开的是效果验证：本土引擎的排名逻辑跟主流引擎不同，同一个页面在两边的表现可能差别不小，只看一家的数据会误判。实际操作上，把本土引擎的排名监控作为一条独立的观测线，但不为它单独生产内容，除非数据显示两边的差异大到必须区别对待。至于引擎本身的排名机制和收录习惯，那是引擎层的话题，跟本篇讲的语言层是两件事，语言层做对了是在任何引擎上都成立的基础，引擎层的调优则是在这个基础之上的增量。 ## 权威参考资料 ## 做小语种外链，英文手册上那份渠道清单搬过去多半是空的，能用的都在当地人的圈子里 - URL：https://zhangwenbao.com/minor-language-link-building-local-directories-media-communities.html - 分类：小语种SEO - 发布：2018-10-09 | 更新：2026-07-24 - 摘要：小语种市场的外链渠道跟英语市场差得很远：本地目录还活着，行业媒体要用本地语言谈，语言社区几乎没人做。讲清资源池怎么挖、外联邮件用哪种语言、反链工具的盲区怎么补。 - 关键词：外链建设,出海SEO,多语言SEO,小语种SEO > **TLDR**：摘要：资源页、失效链接、摩天楼这些打法之所以在英语世界成立，前提是那里有足够密的内容生态托着。换成波兰语、越南语、捷克语，同样的动作跑下来，回复率低得让人怀疑邮箱坏了。不是方法错了，是方法赖以成立的那张网，在这些市场里长得完全不一样。 > 摘要：资源页、失效链接、摩天楼这些打法之所以在英语世界成立，前提是那里有足够密的内容生态托着。换成波兰语、越南语、捷克语，同样的动作跑下来，回复率低得让人怀疑邮箱坏了。不是方法错了，是方法赖以成立的那张网，在这些市场里长得完全不一样。 ## 英文外链手册搬到小语种市场，为什么会失灵？ ## 手册里的渠道清单根本不覆盖这些语言 翻开任何一份经典的外链指南，里面列的渠道都很具体。 行业资源页、专家询源平台、客座投稿站、失效链接数据库。 这些渠道有个共同特征，它们的内容和用户都是英语的。 你按图索骥去找波兰语的对应物，会发现多数根本不存在。 存在的那几个，规模也只有英语世界同类的百分之一。 清单没错，只是它描述的是另一个市场的地形。 更麻烦的是这份清单在团队内部有权威性，因为它出自公认的权威来源，于是执行的人会先怀疑自己做得不对，而不是怀疑清单不适用。这一轮自我怀疑通常要烧掉两三个月，等到终于有人说出这批渠道在这儿不存在的时候，季度已经过去大半了。 把这份清单拿去做本地化改造时有个省事的起点，逐条问一句这个渠道在目标语言里的对应物叫什么，问不出名字的那些，多半就是不存在的。 ## 资源页和失效链接这类打法的前提不成立 失效链接建链的前提是网上有大量陈年页面挂着死链。 资源页建链的前提是有人整理了成体系的推荐链接列表。 这两个前提都需要一个前置条件：这门语言的网页存量足够大、足够老。 网页存量小的语种，死链的绝对数量本来就少。 而且这些页面往往集中在少数几个大站上，那些站不接受外部建议。 做同样的动作，投入产出比可能差出一个数量级。 判断某个打法在目标语种上有没有前提，可以先做一次量级估算：用这门语言的通用词搜一下，看能翻多少页结果、结果里有多少是本地原创而不是机器翻译的。这个粗略的观察比任何理论推导都管用，十分钟就能知道要不要换打法。 还有一个前提常被忽略，这两种打法都需要对方有维护页面的习惯，而小语种市场里很多行业站是几年不动一次的，你指出的死链可能永远没人去修。 另一个被忽略的前提是行业媒体的数量，摩天楼那套打法需要有足够多的站可以推荐同一个主题，本地市场里可能一共就三五家，推完就没了。 ## 语言本身就是第一道门槛 英语市场的外链工作里，语言是透明的。 找站、读页面、写邮件、谈条件，全程一种语言。 到了小语种市场，每一步都要跨一次语言。 找站要用本地语言的搜索词，读页面要能判断内容质量。 写邮件更是绕不过去，用错语言直接决定了对方会不会回。 这道门槛把很多团队挡在了资源池的入口处。 被挡住的直接后果是资源池的规模严重不足，翻来覆去就是那十几个能用英语沟通的站。资源池小到一定程度，后面的筛选、议价、组合全都失去意义，因为根本没有可选项。所以在这些市场里，第一笔该花的钱不是买链接，是解决语言这道门槛。 语言门槛还有个隐性成本，团队内部的沟通链条会变长，一封本地语言的回信要先翻译再讨论再回复，节奏比英语市场慢一倍，排期时要把这个系数算进去。 ## 本地目录站在小语种市场为什么还活着？ ## 英语市场的目录已死，这里没死透 英语世界的网站目录在十几年前就基本退出了历史舞台。 原因是内容农场化、收录标准崩坏、被搜索引擎大幅贬值。 但在很多小语种市场里，本地目录还在被真实用户使用。 原因很实际：这些市场的垂直平台和聚合站不够多。 用户找本地服务商时，仍然会去几个老牌目录翻。 有真实用户在用，链接的价值就不只是那条链接本身。 判断一个目录是死是活有个很朴素的办法，看它的新增收录是不是还在持续、有没有真实的用户评论、页面上有没有近期更新的内容。三条都满足的目录，在小语种市场里往往还能带来直接的转化流量，那部分收益经常超过链接本身的价值。 还有一个信号能说明目录是不是活的，看它有没有付费推广的位置在被真实购买，愿意花钱买位置的商家，通常比外部访客更清楚这个目录带不带客。 ## 哪些目录值得进，三条判据 第一条判据是收录标准，有没有人工审核。 只要交钱就能上、收录量以万计的目录，直接跳过。 第二条判据是流量来源，它自己有没有品牌搜索。 用当地语言搜这个目录的名字，看有没有稳定的搜索需求。 第三条判据是页面形态，收录条目有没有独立的详情页。 只有一行链接的列表页，价值远低于带介绍的详情页。 三条判据里第二条最难造假，也最能反映真实情况。一个目录如果自己都没人搜，那它挂着的那些链接自然也没人点，剩下的只是一条纯粹的技术意义上的链接，值不了多少钱。一条反向链接到底值不值的七维判断法 (https://zhangwenbao.com/backlink-quality-assessment-multi-dimension-link-worth-framework.html)里那套评估维度，套到本地目录上同样适用。 三条判据之外还可以加一个软性观察，看目录的分类体系是不是符合当地的行业习惯，照搬英文分类树的目录多半是批量建站的产物。 ## 收录页的语言和描述怎么写 提交收录时的描述文字，很多人随手就写了。 这段文字往往是这个页面上唯一的原创内容。 用英文写，或者用机器翻译的本地语言写，两种都会拉低页面质量。 而页面质量直接影响这条链接被搜索引擎怎么看待。 正确做法是让母语者写一段一百五十字左右的自然描述。 顺带把品牌名的本地写法、主要品类词的当地说法都放进去。 描述里的品牌名写法要跟站内保持一致，尤其是在有音译形态的市场里，品牌名在小语种里到底写成什么 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)那篇里的形态清单，正好可以在提交目录时统一套用一遍。 描述写好之后建议存进一个统一的文档里，同一个市场的所有目录复用同一份描述，既省事又能让品牌在不同站点上的表述保持一致。 描述里别堆关键词，本地目录的审核员通常就是站主本人，堆砌的描述在小社区里会直接影响他对这个品牌的第一印象。 ## 行业媒体怎么找，怎么谈？ ## 用本地语言的行业词反查媒体 找媒体不要从媒体列表开始，要从内容开始。 用当地语言的行业词、品类词去搜，看哪些站在持续产出内容。 把结果页前五页的域名全部导出来，去掉电商和百科。 剩下的多数就是这个行业在当地的内容生产者。 再看它们的更新频率和作者署名，判断是媒体还是个人站。 这个方法比找现成的媒体名录靠谱，因为名录往往过期得厉害。 搜索词的选择很关键，用品类词能找到综合媒体，用问题词能找到内容做得深的垂直站，用比较词能找到评测型的站点。三类词各跑一轮，得到的资源池结构会完整很多，而且天然带着内容类型的标签，后面谈合作时就知道该给谁提什么素材。 搜索时把结果页的时间范围收窄到最近一年，能快速筛掉那些已经停更的站，小语种关键词工具没数据时的三条土办法 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)里采到的那批真实查询，正好可以拿来当这一步的搜索词。 ## 编辑部的结构决定了你该找谁 小语种市场的行业媒体，编辑部通常很小。 常见的是三五个人，有的甚至就是一两个人在运营。 这意味着没有内容合作部门，也没有标准的投稿流程。 能拍板的往往就是主编本人，而他同时也在写稿。 好消息是决策链极短，谈成一次就是长期关系。 坏消息是对方时间极其有限，邮件写得太长根本不会看。 找对人的办法很直接，看这个站最近三个月的署名文章，出现频率最高的那个名字通常就是核心。找他比找网站上那个公共邮箱有效得多，公共邮箱在这类小编辑部里经常几个月没人看。 联系人找到之后建议顺手记下他常写的主题，下次给素材时直接对准他的兴趣，这一点在只有一两个人的编辑部里，效果比任何邮件技巧都明显。 ## 供稿的语言和署名怎么处理 供稿必须用本地语言，这一点没有商量余地。 用英语投稿，等于把翻译成本转嫁给了一个只有两个人的编辑部。 翻译要找母语者做，机器翻译的稿子编辑一眼就能看出来。 署名方面，本地媒体通常更愿意署本地作者或者本地负责人。 这时候可以让本地团队的人署名，品牌信息放在作者简介里。 这种安排对双方都体面，链接也更自然。 关于稿子的题材，本地媒体最缺的通常不是观点而是数据和一手经验。海外品牌手里恰好有别人拿不到的东西：跨市场的对比数据、供应链上的一手观察、其他市场已经发生过的趋势。这类素材对小编辑部的吸引力，远大于又一篇泛泛的行业分析。 另外要提前说清楚链接的位置和形式，很多本地媒体愿意给链接，但习惯放在文末的作者简介里，如果你需要正文内的上下文链接，得在约稿时就谈好。 ## 本地媒体最吃哪一类素材 按接受度从高到低，大致有四类。 第一类是本地市场的原创数据，哪怕样本不大。 第二类是国际市场的动向，配上对本地的解读。 第三类是实操类的指南，能直接帮读者解决问题。 第四类才是品牌自己的故事，这类最难被接受。 前三类基本不需要付费，第四类通常要走商业合作。 把素材按这四类归好，投稿时命中率会高很多。 做第一类素材有个成本很低的办法，把自己站上的搜索和交易数据做一次脱敏统计，就能得出这个市场里没人发布过的数字。比如某个品类的本地搜索在一年里的季节曲线，这种数据本地媒体自己拿不到，而对你来说只是导一次数据的事。把数据做成持续吸外链的链接磁铁 (https://zhangwenbao.com/original-data-research-content-link-magnet.html)那套做法，在小语种市场里的边际效果比在英语市场还好，因为竞争者更少。 素材的形态也影响接受度，同一份数据做成可视化图表加一段解读，比一篇纯文字稿子更容易被采用，同一个词在两个市场问的不是一件事 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)那篇里的市场差异，本身就是很好的素材角度。 ## 语言社区是不是最容易被忽略的那一块？ ## 词典站、语言论坛和本地维基 每门语言背后都有一批为这门语言本身服务的站点。 在线词典、正字法查询、语法答疑、术语讨论区。 这类站的共同特点是被大量真实用户长期使用。 它们的权威性通常很高，因为使用者把它们当作裁判。 而做外链的人几乎从来不去看这类站。 不看的原因很简单，英文外链手册里没提过它们。 这类站点的机会不在于直接放一条链接，而在于它们的周边生态：术语讨论区里的问题、词典条目下的例句征集、社区维护的术语库。参与这些地方能带来两样东西，一是真实的引用，二是对这门语言里行业术语实际用法的第一手了解，后者对内容质量的帮助往往更大。 这类站还有一个用法是查行业术语的规范写法，内容团队在写落地页时常常拿不准某个专业词的当地标准说法，词典站和术语库给的答案比翻译工具可靠得多。 ## 社区链接的价值和风险 社区类链接有它自己的风险画像。 好的一面是这些链接来自真实讨论，上下文天然相关。 坏的一面是社区里到处是发广告的人，管理员对商业账号很敏感。 一旦被打上营销标签，之前积累的信任会一次清零。 而且很多社区的外链默认带着不传递权重的标记。 所以指望社区链接直接撬动排名是不现实的。 它真正的价值在别处：这些讨论会被搜索引擎当作品牌被真实使用的证据，而且经常出现在长尾问题的搜索结果里，带来的是意图极强的小股流量。把它当作品牌信号和流量渠道来经营，比当作外链渠道更合适。 另外要留意社区的规则差异，有的社区允许在个人资料页放链接但禁止在正文里放，摸清规则再动手，比事后被删帖并留下不良记录划算得多。 社区里的链接还有一层长期价值，那些讨论帖会持续被搜索到，几年后仍然在给你带来零散但意图明确的访问，衰减速度比多数外链慢。 ## 参与方式：先贡献，再露出 进社区有个几乎万能的顺序。 先花两三周只回答问题，不留任何链接。 回答要具体，最好带上自己市场里的真实观察。 等账号有了可见的历史记录，再在真正相关的问题里给出资源链接。 这时候链接是作为答案的一部分出现的，管理员不会删。 整个过程需要一个能用本地语言自然表达的人，这是硬成本。 值得强调的是，这个人不必是全职。很多团队的做法是找一位当地的自由撰稿人，每周投入三四个小时，负责社区和媒体两条线的日常沟通。这个岗位的性价比在小语种市场里高得惊人，因为它同时解决了语言、时区和文化语境三个问题。 贡献期的内容最好也留个档，那些回答本身就是了解这个市场真实问题的一手资料，很多能直接转化成落地页上的常见问题模块。 ## 外联邮件该用哪种语言写？ ## 用英语发出去的实际回复率 先说结论：能回，但会筛掉一大批人。 能用英语回复你的，多半是行业里国际化程度最高的那一小撮。 他们通常也是最忙、收到最多类似邮件的一批。 而那些内容做得很好、但只在本地语言环境里工作的站主，直接就流失了。 后者恰恰是竞争最少、关系最容易建立的一批。 用英语群发，等于主动放弃了资源池里最好的那部分。 回复率的差距在不同市场里差别很大。北欧和荷兰这类英语普及度高的市场，用英语发问题不大；中东欧、南欧、东南亚的差距就非常明显，同一批素材换成本地语言之后，回复率翻几倍是常见的事。冷邮件外联的工程化打法 (https://zhangwenbao.com/link-building-cold-email-outreach-engineering-pitch-system.html)那套流程本身是通用的，需要本地化的是语言和称呼这两层。 保哥做过一个宠物出行品牌的中东欧项目，同一批素材先用英语发了一轮只回了两封，换成本地语言重发之后回了十一封，收件人名单一个都没换。 ## 本地语言邮件的最小可行做法 不需要养一个本地团队才能做这件事。 最小方案是准备三到四个邮件模板，找母语者翻译好。 模板要覆盖：初次接触、资源推荐、内容合作、跟进催复。 个性化的部分单独留空，用简单的本地语句子填。 对方用本地语言回复时，再找人处理具体沟通。 这样只有实际产生对话的那部分才消耗人力。 模板翻译要避免一个常见错误，就是照着英文原文逐句翻。英文外联邮件的直接程度在很多语言的商务语境里显得唐突，尤其是德语、日语和斯拉夫语族的市场，称呼、敬语和开场白的规范差别很大。翻译时要让母语者按当地习惯重写，而不是翻译。 模板准备好之后建议做一次内部测试，找母语者以收件人的身份读一遍，问他愿不愿意回，这个问题比问语法对不对有用得多。 ## 母语审校在外联里的位置 审校在外联里的作用跟在内容里不一样。 内容里审校管的是自然度和准确性。 外联里审校管的是分寸：称呼够不够礼貌、请求是不是太直接。 这两件事出错的后果不同，前者影响质量，后者直接导致不回复。 所以外联模板的审校最好找有商务沟通经验的人，而不是纯语言背景的人。 一次审校可以用很久，模板不是每次都要重做。 另外有一条在欧洲市场必须留意的规矩，就是数据保护条例生效之后，向企业邮箱发送未经请求的商业邮件，在合规上有明确要求。实务上的做法是只联系网站上公开列出的、明确用于业务往来的邮箱，邮件里说明来源并提供退订方式，把这几条写进模板里，风险基本就控制住了。 审校完成后把定稿版本锁住，别让每个人再各自改写，外联模板一旦被临时改动，那些经过审校的分寸感往往第一个丢掉。 ## 反链工具在小语种市场的盲区有多大？ ## 索引覆盖本身就偏英语 反链工具的数据来自它自己的爬虫索引。 爬虫的抓取优先级跟页面的权重和更新频率相关。 小语种的站点在这套排序里天然靠后。 结果就是很多真实存在的链接，工具里查不到。 你以为竞品的外链只有三十条，实际可能有三百条。 据此做的差距分析，结论会整个跑偏。 验证盲区大小有个办法：找几条自己确定存在的本地外链，看工具收没收。抽查十条，如果只收到三四条，那这个市场的数据可信度就只有这个水平，后面所有基于工具的判断都要按这个折扣去理解。四大主流反链工具的对比与拆解 (https://zhangwenbao.com/backlink-analysis-tools.html)那篇里的选型思路仍然成立，只是在小语种市场里，覆盖率这一项的权重要调到最高。 折扣率测出来之后建议写进团队的共同认知里，否则每次有人拿工具数据做汇报，都会重新引发一轮关于这个数准不准的讨论。 ## 非拉丁锚文本的聚合问题 工具在处理锚文本时会做归并和统计。 非拉丁字符的锚文本，归并逻辑经常出问题。 同一个词的不同形态被当成不同的锚文本分开统计。 带变音符号和不带的两种写法，也常常各算各的。 于是锚文本分布报告看起来极其分散，读不出任何结论。 这不是你的外链结构有问题，是统计口径的问题。 处理办法是把导出的锚文本数据自己再归并一次，按词根或者去掉记号后的形态分组。这一步用几十行脚本就能完成，做完之后锚文本的真实分布才会显现出来，而那个分布往往跟工具报告给出的印象差别很大。 归并锚文本时顺手统计一下品牌词锚和通用词锚的比例，这个比例在小语种市场里通常比英语市场更偏向品牌词，因为编辑更习惯直接写公司名。 ## 本地域名后缀的抓取深度不一样 不同的国家顶级域名，在工具索引里的深度差别很大。 一些国家的域名注册政策严格，站点总量少但质量高。 另一些国家的域名开放注册，垃圾站多，工具的抓取策略也更保守。 这会导致同样质量的两条链接，在工具里显示的价值完全不同。 判断的时候不能只看工具给的评分。 更可靠的是看这个站自己的流量和品牌搜索。 想了解某个国家域名的注册政策和管理机构，最快的路径是查根域数据库里的委托记录，里面有注册局的官方地址。顺着注册局的公开文档往下看，通常能找到域名总量、注册要求这类基础数据，这些数字是判断一个市场资源池规模的起点。 查注册局资料还有个附带收获，很多注册局会公开域名总量和年度增长，这两个数字能帮你判断这个市场的资源池是在扩张还是在萎缩。 不同国家域名的续费和转让规则也不同，有些市场里域名过期后会被专门的抢注方接手，这意味着你今天拿到的链接可能几年后指向一个完全不同的站。 ## 用日志和提及监控补盲区 工具查不到的链接，服务器日志里跑不掉。 有人链了你，就会有人从那条链接点过来。 把来源地址按域名聚合，就是一份真实的外链清单。 这份清单的覆盖面在小语种市场里通常超过任何付费工具。 唯一的缺点是它只记录有点击的链接，没点击的看不到。 两者结合起来，盲区能压到很小。 提及监控是第三条腿，配上品牌名的各种本地写法，能抓到那些提到你但没加链接的页面。这批页面是转化率最高的外链线索，因为对方已经在写你了，补一条链接的沟通成本极低。这也是为什么品牌名的形态清单要同时交给做外链的人一份。 日志分析要注意排除掉自己的抓取工具和监控服务，那些请求的来源地址会混进外链清单里，第一次做的人几乎都会被这批数据误导一次。 ## 本地资源池怎么系统地挖出来？ ## 从国家域名和本地结果页反查 第一条挖掘路径是限定域名后缀去搜。 用本地语言的行业词，加上限定国家域名的搜索语法。 把结果批量导出，得到的就是这个行业的本地站点集合。 再按站点类型分类：媒体、目录、论坛、协会、电商。 分类之后每一类用不同的接触方式。 这一步通常能挖出一两百个域名，够跑一个季度。 要注意的是有些市场的主流站点并不用本地国家域名，很多用国际通用后缀，所以限定后缀只能作为其中一条路径，不能当成全部。补充做法是把限定去掉，只用本地语言词搜，然后手工剔除掉明显不属于这个市场的结果。 导出结果时把地址形态也保留下来，本地字母写的网址在日志里是编码形态，小语种网址用本地字母还是拉丁转写 (https://zhangwenbao.com/minor-language-url-native-script-vs-latin-transliteration.html)那篇里的解码步骤，在这一步同样要跑一遍。 ## 从竞品的本地反链里抄作业 竞品分析在小语种市场里的价值比在英语市场更高。 因为可选资源少，竞品几乎必然踩过同样的几个渠道。 要注意的是本地竞品比国际竞品更有参考价值。 国际品牌在这个市场的外链多半来自集团层面的国际资源。 本地竞品的外链才是这个市场真正能拿到的那些。 所以做反链差距分析时，对标对象要选本地玩家。 挖竞品反链时记得把工具的覆盖率折扣算进去，工具能看到的可能只是一部分。补充办法是直接搜竞品的品牌名，看哪些本地页面在提它，这个动作能捞出一批工具索引里没有的站。反链差距分析怎么挖对手的外链 (https://zhangwenbao.com/competitor-backlink-gap-link-intersect-prospecting.html)那套交集法在这里同样适用，只是数据源要换成手工采集的那份。 抄作业还有一个更省事的入口，去看本地竞品的合作伙伴页和媒体报道页，那些页面上通常列着它这些年谈成的所有关系，等于把资源池直接摆出来了。 ## 从行业协会和展会名录里挖 这是小语种市场里被严重低估的一条路。 欧洲和东南亚的很多行业都有本地的行业协会。 协会网站上通常挂着会员名录，每个会员一个详情页。 加入协会拿到的不只是一条链接，还有名录页面的长期存在。 展会同理，参展商名录页往往权重不低且长期保留。 这两类资源的门槛是会费和参展费，但它们本来就在预算里。 关键在于报名时把网址和描述填对填全。很多公司交了会费，名录里却只有一个公司名连链接都没放，等于把钱花了一半。这件事应该由做搜索的人在报名环节就介入，而不是等名录上线后再去补，那时候修改往往要等到下一年度。 协会名录还有一个容易被忽略的细节，很多协会会在年报或者会员通讯里再列一次会员名单，那些文件页往往也能被检索到，属于额外的一份收录。 ## 从政府和教育域名里挑 这条路在小语种市场里意外地好走。 本地的商务促进机构、外贸服务网站经常有企业名录。 大学和职业院校的合作企业页面、实习基地名单也是同类资源。 这些站的权重高，而且几乎没有商业化的收录门槛。 门槛在于你得真的有对应的关系：注册了本地实体、参与了某个项目。 所以它更适合已经在当地有业务落地的品牌。 这类链接还有一个附带好处，它们对本地用户的信任建设作用很强，尤其是在信任门槛高的品类里。做外链时顺手把这类页面的存在写进落地页的信任模块，链接和转化两头的收益都拿到了。 申请这类收录时材料要备齐，本地实体的注册号、税号、当地地址是常见的门槛，提前准备好能省掉好几轮往返沟通。 ## 哪些链接在小语种市场是负资产？ ## 批量翻译出来的站群目录 小语种市场里有一类站特别容易撞见。 整站内容是从英语站批量机器翻译过来的，域名后缀换成本地的。 这类站往往打包卖链接，价格便宜、下单方便。 它们的问题不只是质量差，而是模式本身已经被识别。 一批站共用同一套模板和同一批内容，关联性一目了然。 买了这类链接，等于给自己的外链档案里放了一个标记。 辨认这类站有几个明显特征：内容读起来像机器翻译、页面上有大量不相关行业的文章、外链指向的域名跨行业跨国家、以及最关键的一条，它自己几乎没有品牌搜索。任何一条命中就该警惕，两条以上直接跳过。 遇到这类站还有个反向用法，把它们整理成一份黑名单存档，因为同一批人往往会换个域名再来一次，有名单在，第二次能一眼认出来。 这类站还有一个变种更隐蔽，域名和内容都是本地的，但整站是由一家公司批量运营的十几个站之一，看外链输出结构能识别出来。 ## 语言不通的通用博客网络 第二类是所谓的多语言博客网络。 它们号称覆盖几十种语言，什么行业都能发。 实际情况是文章由同一批人用翻译工具批量生产。 你在上面发的那篇稿子，本地读者一眼就能看出不是母语者写的。 就算搜索引擎当时没发现，这类网络的生命周期通常也很短。 链接跟着站一起消失，付出的钱一分收不回。 更值得警惕的是这类网络在小语种市场里的比例远高于英语市场，因为本地正规资源少，供给方就用这种方式填补需求。资源池越贫瘠，垃圾供给越活跃，这几乎是个规律。有毒外链审计的八步实战 (https://zhangwenbao.com/backlink-value-evaluation-toxic-link-audit.html)那套筛查动作，在这些市场里更需要定期跑。 判断一个博客网络还有个简单办法，随便挑它两三个站看看服务器地址和页面模板，同一批模板加同一段地址，基本就不用再往下看了。 ## 机器翻译的客座文章 第三类问题出在自己身上。 为了省成本，把英文稿子机器翻译一下就投给本地媒体。 好一点的结果是编辑退稿，坏一点的是发出来砸了品牌。 本地读者对机器翻译的敏感度远高于我们的想象。 一篇明显不自然的稿子，损失的不只是这一次合作。 编辑会记住这个品牌，后面的合作机会一起没了。 这里有一条很实际的成本对比：找母语者重写一篇稿子的费用，通常只相当于买一条中等质量链接的价格。而重写的稿子能同时拿到链接、品牌曝光和长期关系，机器翻译的稿子一样都拿不到。这笔账算清楚，就不会在这里省钱了。 退一步说，如果实在没有预算做母语重写，那就干脆不投这个渠道，把素材留到有条件的时候再用，砸掉的关系是补不回来的。 ## 预算怎么分，一条链值多少钱？ ## 小语种外链的价格区间和议价方式 价格差异比英语市场大得多。 同样质量的媒体，波兰和越南的报价可能差三倍。 而且很多本地站根本没有标准报价，第一次问才现想。 这意味着议价空间比英语市场大，也意味着基准很难建立。 比较靠谱的做法是同时接触五到八家，把报价拉成一个分布。 拿到分布之后，中位数就是这个市场的参考基准。 议价时有个本地化的细节，用当地货币报价、按当地的商务习惯谈，拿到的价格往往比用美元谈更低。这不是玄学，用外币报价会让对方按国际客户的标准来定价，而那个标准通常包含一层额外的溢价。 报价拉出分布之后建议按站点类型分开看，媒体、目录、博客三类的价格逻辑完全不同，混在一起算出来的中位数没有指导意义。 ## 用本地渠道谈和用中介谈的差别 市场上有专门做小语种外链的中介。 它们的优势是省事，缺点是资源池跟你自己能挖到的高度重合。 更实际的问题是中介的资源池通常偏向那些愿意卖链接的站。 而真正有价值的本地媒体，很多根本不做链接买卖。 那些站只能靠内容和关系去谈，中介帮不上忙。 所以合理的分配是中介做量，自己做质。 具体比例可以按二八分，两成预算给中介买基础的行业站和目录，八成投在内容生产和本地关系上。这个比例跟英语市场的常见做法正好相反，原因是小语种市场里能买的东西质量普遍偏低，而能谈的东西竞争者又特别少。 用中介时还有一条要守住，要求对方提供具体域名清单再付款，只给一个权重区间和数量承诺的合作，最后拿到的多半是那批批量翻译的站。 ## 什么时候该用内容资产替代付费链接 有三个信号说明该换打法了。 第一个是报价明显高于同类市场，说明供给被少数几家垄断。 第二个是能买的站质量都不行，买了也没用。 第三个是自己已经有可以做数据内容的素材。 三个信号出现两个，就该把预算转到内容资产上。 在本地语言内容稀缺的市场里，一份像样的原创内容能持续吸链好几年。 内容资产在这些市场的另一个优势是竞争窗口长。英语市场里一份好内容几个月就会被模仿，小语种市场里同类内容可能两三年都没人做第二份，投入产出的时间曲线完全不一样。 内容资产在小市场还有一个隐性收益，它会让本地媒体主动来找你要素材，这条关系一旦建立，后面的合作成本会比冷启动时低一个量级。 判断内容资产该做什么形态时，先看这个市场里已经有的内容缺什么，缺数据就做数据，缺工具就做工具，缺的是系统的入门内容那就做指南。 ## 一份可以照着跑的季度计划 ## 第一个月：资源池和语言准备 第一周，用三类搜索词把本地资源池挖出来并分类。 第二周，按判据筛目录、按署名找媒体联系人。 第三周，准备四个外联邮件模板并做商务向的审校。 第四周，确定这个季度要产出的内容素材，最好含一份原创数据。 这个月不发一封邮件，也不买一条链接。 产出物是一份带分类和联系人的资源表，加一套本地语言的沟通物料。 忍住不动手是这个月最难的部分。多数团队会在第一周就开始群发，结果是把最好的那批联系人在最没准备的时候用掉了。资源池里的优质联系人是一次性资源，第一封邮件的印象决定了后面还有没有机会。 第一个月还有件小事值得做完，就是把目标市场的公共假期、行业展会日期整理成一张表，后面两个月的排期全要参照它。 ## 第二、三个月：投放与跟进 第五周开始批量接触，每周控制在三十封以内。 控制数量是为了保证每封都有真实的个性化内容。 第七周开始第一轮跟进，没回的隔十天发一次，最多两次。 同时把已经谈成的合作稿件排进生产流程。 第九周之后，把回复情况按渠道类型统计一次，调整后面的接触重心。 第十一、十二周集中产出内容并完成上线。 跟进的节奏要按当地的工作习惯来调，欧洲的夏季长假和各国的公共假期会让整条线停摆几周。排期时先把目标市场的假期表贴在计划旁边，能避免把最好的素材发在没人看邮件的那两周。 跟进的记录要落在一个共享的表里而不是各自的邮箱里，人员一变动，那些散在个人邮箱里的沟通历史就全丢了，下一轮又得从陌生人开始。 ## 验收指标和放弃线 季度末看四个数字。 第一个是新增的本地域名数，不是链接数。 第二个是这些域名里有真实流量的比例。 第三个是外联的回复率，它反映的是语言和素材的质量。 第四个是内容资产带来的自然链接数。 四个数字里第三个最能指导下一轮的改进方向。 放弃线也要提前定好：如果一个季度下来本地域名新增不到两位数，且回复率低于百分之五，那说明这个市场的资源池或者语言准备有根本问题，该做的是回头补前置工作，而不是加大投放力度。在贫瘠的资源池里增加发送量，只会更快地把可用联系人消耗完。 四个数字建议按渠道类型分开统计，目录、媒体、社区三条线的效率差别很大，合成一个总数的话，表现最差的那条线会被另外两条掩盖掉。 ## 常见问题解答 ## 小语种外链一定要用本地语言谈吗 分市场看，但默认答案是要。有几个市场例外，北欧国家、荷兰、以及部分东南亚市场的从业者英语水平普遍很高，用英语接触不会有明显障碍。除此之外的多数市场，用英语发出去的邮件会系统性地筛掉那批只在本地语言环境里工作的站主，而他们往往是竞争最少、关系最容易建立的一批。更现实的一点是，用本地语言发的邮件本身就是一个信号，它说明发件人对这个市场是认真的，不是在群发。这个信号在小市场里格外重要，因为那里的从业者收到的国际群发邮件太多了，本地语言几乎自动把你和那些邮件区分开。成本方面不必担心，最小方案就是准备四个翻译好的模板，个性化的部分用简单句子填空，只有真正产生对话的那部分才需要人来处理。真正需要投入的不是翻译费，而是找到一个能在需要时接手对话的人，这个角色可以是兼职的当地自由撰稿人，每周几个小时就够。还有一个判断是否需要本地语言的土办法，去看这个市场里排在前面的几个本地站，它们的联系页上有没有英文版本，一个都没有的话，答案已经很清楚了。 ## 本地目录站现在还有价值吗 在小语种市场里，一部分还有，判断要一个个来。英语市场的目录基本已经失去价值，但那个结论不能直接搬过来，因为很多小语种市场缺少垂直平台，用户找本地服务商时仍然会去几个老牌目录翻。判断标准有三条：有没有人工审核、目录自身有没有品牌搜索、收录条目有没有独立的详情页。三条都满足的目录，除了链接本身，还经常带来直接的转化流量，那部分收益有时比链接更实在。三条里最关键的是第二条，一个目录如果自己都没人搜，它挂的链接自然也没人点。反过来，那些收录量以万计、交钱就上的目录要坚决跳过，它们在任何市场都是负资产。还有一个实操建议，提交收录时的描述文字要找母语者写一段一百五十字左右的自然文本，那段文字往往是页面上唯一的原创内容，直接影响这条链接被怎么看待，随手用机器翻译填上去是很多人白白浪费的一次机会。另外要留意目录的收录时效，有些老牌目录审核要等好几周甚至几个月，排期时把它放在季度最前面提交，别等到最后一周才想起来。 ## 反链工具在小语种市场到底能不能用 能用，但要先测出它在这个市场的折扣率。测法很简单，找十条自己确定存在的本地外链，看工具收录了几条，收录比例就是它在这个市场的覆盖率。如果只收到三四条，那所有基于这个工具的数据都要按这个折扣去理解，尤其是竞品外链数的对比，很可能双方都被低估，但低估的程度不一样。除了覆盖率，还有两个已知的问题要留意：非拉丁字符的锚文本经常被分开统计，导致锚文本分布看起来极度分散，这个可以靠自己导出数据再归并一次解决；不同国家域名后缀的抓取深度差别很大，导致同样质量的两条链接评分不同，这个只能靠看站点自身的流量和品牌搜索来修正。补盲区的正解是服务器日志和品牌提及监控，日志能捞到所有产生过点击的外链，提及监控配上品牌名的各种本地写法，能找到那些提到你但没加链接的页面，后者是转化率最高的一类线索。三个来源合起来，实际覆盖面会远超单靠工具。补一句，工具的折扣率不是固定值，它会随着这个市场的网页存量增长而变化，建议每年重测一次，别拿两年前的结论当依据。 ## 找不到本地母语者怎么起步 可以起步，但要接受前两个月效率偏低。没有母语者的情况下，能做的是资源池挖掘这一整块，因为它主要靠搜索和分类，语言要求不高，配合翻译工具足够判断一个站是做什么的。做不了的是外联沟通和内容生产这两块，硬做的话回复率会很难看，还可能伤到品牌。折中的路径有三条：第一是先只做那些不需要沟通的资源，比如行业协会名录、展会参展商名录、以及自己已有商务关系的合作伙伴页面，这批链接的获取靠的是关系不是语言。第二是找当地的自由撰稿人做兼职，每周三四个小时的投入，费用比想象中低很多，而且这个人同时能帮你做内容审校。第三是从平台型资源入手，很多国际平台有本地语言的商家页，那些页面的填写规则是标准化的，语言要求最低。等前两个月把这三类做完，通常也就积累到足够的预算理由去请一个固定的本地伙伴了。没有母语者的阶段还有一件事可以先做，把已有的英文内容里适合本地化的那几篇挑出来排好序，等人到位就能立刻开工，不用再花时间选题。 ## 行业协会和展会这类线下资源值得投吗 如果预算里本来就有这笔钱，值得，而且要确保把链接这部分收益拿到手。会员名录页和参展商名录页的共同特点是权重高、长期保留、几乎没有商业化收录的痕迹，这类链接在任何市场都是优质资产，在小语种市场里更是因为可替代资源少而显得珍贵。要注意的是这笔收益很容易被漏掉：很多公司交了会费或者参展费，名录里却只有公司名连网址都没填，或者填了个跳转地址。正确的做法是在报名环节就让做搜索的人参与，把网址、公司描述、品类关键词都按规范填好，描述用本地语言写。这件事的时机很关键，名录上线之后再想改，多数协会要等到下一个年度。如果预算里原本没有这笔钱，那要单独算账，会费本身通常不便宜，只为一条链接去交是不划算的，要看协会带来的商务机会和信任背书是否也在你的需求里。还有一个细节，名录页上的公司描述最好跟官网的品牌介绍保持一致的说法，两边表述不同会让核对信息的人产生困惑，也浪费了一次统一品牌表述的机会。 ## 怎么判断一个本地站是不是在卖链接 有几个不需要问对方就能看出来的迹象。第一个是看它的外链输出结构，如果一个本地行业站的外链指向大量不相关的行业和国家，那基本可以确定它在卖。第二个是看内容里链接的位置和上下文，正常的编辑链接会出现在与主题直接相关的段落里，卖的链接常常被硬塞在一段泛泛而谈的文字中间。第三个是看它有没有专门的合作页面，很多站会把广告位和赞助文章的价格挂出来，这本身不是坏事，明码标价的商业合作和暗地里卖权重是两回事。第四个是看内容的更新节奏，如果一个站长期不更新，突然某段时间密集发布多篇带链接的文章，那多半是在集中消化订单。判断出来之后怎么处理要看目的，如果这个站有真实读者和品牌搜索，那么走它的商业合作渠道拿一篇内容合作是可以接受的；如果它没有真实读者，只是一个链接批发站，那就直接跳过，价格再便宜也不要。判断完之后不管结论如何，都建议把这个站的观察记录存档，做外链是长期工作，同一批站会反复出现在候选名单里，有记录就不用每次重新判断。 ## 季度计划跑完没达标，该继续还是换市场 先分清没达标的是哪一项。如果新增域名数不够但回复率正常，说明资源池太小，问题在挖掘环节，解法是扩大搜索路径而不是加大发送量，可以试试去掉国家域名限定、增加问题词和比较词两类搜索、以及从竞品品牌名反查提及。如果回复率很低但资源池不小，那问题在语言和素材上，解法是重做邮件模板和素材包，找有商务经验的母语者重写而不是重译。如果两项都不行，那才需要重新评估这个市场值不值得投，但评估的依据不该只是外链这一条线，还要看这个市场的搜索需求规模和竞争密度，外链难做的市场往往也是竞争者少的市场，这两件事是同一个原因的两面。真正应该考虑撤退的信号是另一种：市场里能拿到的所有链接质量都很低，且内容资产也带不来自然链接，那说明这个市场的内容生态还没有成形，早期投入很难沉淀。这种情况下更稳妥的做法是把资源转到已经有生态的邻近市场，等这边的生态起来再回来。最后提醒一点，评估市场时把时间维度拉长看，内容生态刚起步的市场往往在两三年内变化很大，今天投不划算不等于明年也不划算，定期复查比一次性判死刑更合理。 ## 权威参考资料 ## 小语种SEO最想抢的那族词，在英语里两个后缀就够，在德语里要写五遍 - URL：https://zhangwenbao.com/minor-language-comparative-superlative-keyword-forms.html - 分类：小语种SEO - 发布：2018-04-16 | 更新：2026-07-28 - 摘要：英语的形容词分级只有两套后缀，德语的最高级却要跟名词的性数格全部对上，芬兰语还要再叠一遍格。讲清综合式与分析式在匹配类型上的分野、词干还原为什么只合并一半形态，以及搜索侧必抢的词为什么在合规侧反而是高风险词。 - 关键词：关键词研究,出海SEO,多语言SEO,小语种SEO > **TLDR**：摘要：最便宜、最好、性价比最高这一族词，在英语里只需要两个后缀就能覆盖完，商业意图却是全站最高的。换到德语要写出五个不同的字符串，换到芬兰语还得再乘一遍格的数量，而这族词偏偏又是合规部门盯得最紧的一族。本文把最高级词的形态成本算成一个能在纸上算完的公式，给出词表的五列结构和三个上线后要盯的数。 > 摘要：最便宜、最好、性价比最高这一族词，在英语里只需要两个后缀就能覆盖完，商业意图却是全站最高的。换到德语要写出五个不同的字符串，换到芬兰语还得再乘一遍格的数量，而这族词偏偏又是合规部门盯得最紧的一族。本文把最高级词的形态成本算成一个能在纸上算完的公式，给出词表的五列结构和三个上线后要盯的数。 ## 为什么最便宜这三个字在小语种里不是一个关键词？ ## 商业意图最高的那一族词，长什么样 把任何一个电商站的关键词表按转化率从高到低排，前面挤着的永远是同一批修饰词。 最便宜、最好、最耐用、性价比最高、销量第一，这一族词有个共同点，就是用户打出它的时候已经准备掏钱了。 信息型查询的用户还在了解，导航型查询的用户已经知道要去哪，只有这一族词卡在中间那个最值钱的位置上。 它前面通常还挂着一个品类名，最便宜的猫砂、最好的狗粮、最耐用的宠物笼。 这个组合在英语里写出来是一个短语，在很多语言里写出来不是。 做德语宠物用品那一年，我们把英语站转化率最高的三十组词整理出来准备翻过去，其中有十九组带着这类修饰词。这三十组词贡献了英语站接近四成的自然搜索成交，所以翻译这件事根本不敢交给通用流程，团队专门抽了两个人盯着做。 换个角度看，这一族词的价值不在搜索量而在它所处的决策阶段，用户打出最字的那一刻已经完成了选品类、选价位两步筛选，剩下的只是选哪一家。越靠近决策终点的词，形态错一个字母的代价越大，因为这批用户没有耐心回头再改一次查询。 ## 英语给了我们一个错觉：这族词很好处理 英语的形容词分级只有两套后缀，短词加 -er和 -est，长词前面加more和most。 加完之后这个词就不再变了，放在什么名词前面都是同一串字符。 cheapest shoes、cheapest dress、cheapest cat litter，中间那个词一个字母都不用改。 于是英语站的关键词表里，这一族词一个概念只占一行。 做英语SEO的人对这件事完全没有感觉，因为它从来没有构成过成本。 这个错觉的杀伤力在于它会顺着流程一路传下去。词表模板是按英语站的形状设计的，一个概念一行；翻译工单是按行派的，一行一条；验收清单是按工单核的，核完就算齐。整条链路上没有任何一个环节会主动提出这一行在目标语言里应该裂成五行。 更麻烦的是这个错觉还会被工具确认一遍，英语关键词工具返回的这族词只有寥寥几行，看着确实不像一件需要单独立项的事。等到德语站上线三个月、榜单页始终接不住任何一条最高级查询的时候，回头查根因，往往要花掉比当初做对它更多的时间。 ## 换成德语，第一次点开词表就知道不对 德语的最便宜写成am billigsten，但这个形态只能单独用，放到名词前面就得改。 放到名词前面要写成billigste、billigster、billigsten、billigstem、billigstes里的某一个。 选哪一个不取决于这个形容词本身，取决于它后面那个名词是什么性、什么数、在句子里是什么格。 换句话说，同一个最便宜，在猫砂上和在狗窝上是两串不一样的字符。 这就已经不是翻译问题了，这是词表结构的问题。 德语的形容词变化规则可以在DWDS的billig词条 (https://www.dwds.de/wb/billig)里一眼看完，那张变化表本身不复杂，难的是它跟名词的组合会在关键词层面爆开。跟意大利语那种每个形容词都要跟名词改性数 (https://zhangwenbao.com/italian-seo-gender-agreement-elision-keyword-research.html)的情况相比，德语多了一层格，形态数量还要再翻一倍。 第一次意识到这件事的场景我记得很清楚，是母语审校在验收表里对同一个词写了三条互相矛盾的批注，我们以为她标错了，后来才明白她是在按三个不同的名词各自给意见。矛盾的批注往往不是审校的问题，是你的表结构没有把上下文带过去。 ## 英语的两个后缀，到了德语为什么会长出五个字符串？ ## 最高级形容词的形态由后面那个名词决定 这是理解整件事的那个支点，也是最容易被忽略的一句话。 形容词的形态不是形容词自己的属性，它是形容词和名词那个组合的属性。 所以你不可能先把形容词表做完再去配名词，两者必须一起做。 词表里如果只有一列写着最高级形容词，那一列的值全是错的。 正确的做法是把成品串当成最小单位，形容词和名词在成品串里已经黏在一起了。 这一条听起来像语法课，落到工程上却很硬：它决定了词表的主键是什么。主键如果是形容词，你会得到一张永远对不上号的表；主键如果是形容词加品类名词的组合，行数会涨上去但每一行都是可以直接拿去查搜索量、可以直接写进标题的真实字符串。 这条支点还有一个副产品，它顺手回答了词表该由谁来维护的问题：既然形态由名词决定，那么品类名词表的所有权就必须跟关键词表在同一个人手里，分给两个团队维护的结果是名词表更新了、关键词表还停在旧版，成品串跟着一起过期而没有任何人会收到通知。 ## 五个词尾对应哪几种组合 德语名词有阳性、阴性、中性三种性，还有单数和复数的区别。 加上四个格，理论上的组合数不小，但形容词词尾实际只有五种写法。 五种写法覆盖全部组合，意味着有大量组合共用同一个词尾。 这是好消息，它把爆炸的量级从几十压回到了个位数。 坏消息是共用关系不规则，你没法凭直觉判断某个组合该用哪个。 实际操作里我们没有让运营去背这张表，而是让开发把形容词加名词的组合生成逻辑写成一个函数，输入是品类名词的性数，输出是成品串。这个函数一次写完，之后新增品类只需要往名词表里加一行并标好性数，成品串自动生成，不需要任何人重新学一遍语法。 要看清这五种词尾各自覆盖哪些组合，最直观的材料是德语树库的形态标注 (https://universaldependencies.org/treebanks/de_gsd/index.html)，里面每个形容词都标了性数格三项特征，按特征分组统计一遍就能得到一张实测版的对应表，比语法书上那张表更贴近真实文本里的分布。 ## 冠词还会再叠一层：强变化与弱变化 德语形容词的词尾还要看前面有没有冠词、是什么冠词。 前面有定冠词的时候用一套词尾，没有冠词的时候用另一套。 die billigsten Schuhe和billigste Schuhe，两串都合法，含义有细微差别。 用户在搜索框里两种都会打，而且比例并不悬殊。 所以这两套不是二选一的关系，是都要覆盖的关系。 这一层是最容易在词表里漏掉的一层，因为翻译交回来的通常是带冠词的完整短语，读起来最自然。但用户在搜索框里省略冠词是常态，尤其在手机上打字的时候。我们的做法是每个成品串都强制生成带冠词和不带冠词两个版本，让搜索量数据自己去决定哪个进标题。 带冠词和不带冠词的比例我们实测过一次，桌面端接近对半，手机端不带冠词的占到七成以上。输入成本会直接改写查询的形态分布，这条规律在别的语言上同样成立，凡是要多打几个字符的写法，在手机流量占比高的市场里份额都会系统性偏低。 ## 真实行数怎么算，一个能在纸上算完的公式 把这件事变成一个数，比争论它复不复杂有用得多。 行数等于最高级形容词的个数，乘以品类名词按性数分出来的档数。 德语的品类名词落进三性两数，实际用到的档通常是四到五档。 再乘上带冠词和不带冠词这两种，得到的就是这一族词的真实行数。 宠物用品那次算出来是六个形容词乘五档乘二，六十行左右。 六十行不是一个吓人的数字，一个人半天能做完。真正要紧的是这六十行必须在项目开始的时候就出现在预算表里，而不是等到内容都上线了、发现榜单页一条最高级查询都接不住的时候才补。这一族词的补救成本比它的生产成本高得多，因为补救意味着改标题，改标题意味着已经积累的排名要重新洗一遍。 这个公式还有一个附带用途，它能让你在立项会上把这件事说清楚。六十行这个数字比复杂两个字有说服力得多，对方一听就知道该给多少工时，而说复杂只会换来一句那你看着办。凡是能把成本折成行数的工作，都要在开口之前先折一次。 ## 分析式最高级和综合式最高级，对关键词表的影响差在哪？ ## 西语法语是加词，德语芬兰语是改词 西班牙语的最便宜写成el más barato，字面是那个更便宜的。 法语写成le moins cher，字面是那个较不贵的。 两种写法都是往短语里加功能词，中心那个形容词本身没有变成一个新词。 德语的billigsten和芬兰语的halvin不一样，它们是一个新的词形。 一个是短语层的操作，一个是词层的操作，这个区别会一路影响到匹配类型。 语言学上把这两种叫分析式和综合式，通用依存标注体系里的Degree特征 (https://universaldependencies.org/u/feat/Degree.html)把形容词的级明确定义成了一个词层特征，只有综合式的语言才会在这个特征上产生新的词形。这份定义的用处是它给了你一个跨语言的判据：查一下目标语言的树库有没有大量Degree=Sup的标注，有就说明这门语言走综合式，没有就走分析式。 判断一门语言走哪条路线不必等到做词表的时候，查一次词典就够了：如果最高级在词典里作为独立词条出现，说明它是一个新词形，走综合式；如果词典只在原形词条下面用例句说明，说明它是短语，走分析式。这个判断五分钟能做完，却决定了后面所有的表结构。 ## 加词的那一半落进词组匹配，改词的那一半落进精确匹配 这是那个区别在广告后台里的直接后果。 西语的el más barato是三个词元，投出去落在词组匹配的行为域里。 德语的billigsten是一个词元，它的行为跟精确匹配更接近。 同一笔预算、同一个匹配类型设置，在两门语言上跑出来的覆盖面完全不同。 报表把两者并在一列里做对比，那一列的数字没有可比性。 我们后来在报表里给这一族词单独加了一个字段，标记它在这门语言里是分析式还是综合式。加这个字段之前，西语账户的展现量看起来永远比德语账户高一大截，团队一度以为是西语市场需求更大；加完之后才看清楚那只是词元数量不同导致的匹配宽度差异，跟需求量没关系。 这个区别在站内搜索上同样咬人，多数站内搜索引擎默认按分词器切出来的词元 (https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis-tokenizers.html)做匹配，分析式的三个词元里有两个是高频功能词，会被停用词表直接丢掉，剩下一个中心词导致召回过宽；综合式的单词元则可能因为没进词典而召回为零。 ## 土耳其语反而是最省事的一门 土耳其语的最高级是在形容词前面加一个en，形容词本身一个字母不改。 en ucuz、en iyi，结构干净得像英语，甚至比英语还干净。 这跟大家对土耳其语后缀会叠好几层 (https://zhangwenbao.com/turkish-seo-agglutinative-suffix-stacking-keyword.html)的印象正好相反。 形态复杂度不是一门语言的整体属性，它是按语法范畴分开算的。 同一门语言可以在名词上极复杂、在形容词分级上极简单。 这条经验后来救了我们不少估算：排新语种的优先级时，不要拿这门语言难不难这种整体印象来打分，要按你实际要用到的那几个语法范畴逐项打分。土耳其语在最高级这一项上的成本几乎是零，而德语在这一项上的成本是六十行，两门语言在整体难度榜上的排位跟这个结论完全对不上。 按语法范畴逐项打分这件事，实际做起来只需要一张小表：横轴是你要用到的范畴，名词格、形容词一致、动词形态、复数、冠词，纵轴是候选语种，每格填零到二分。半天能填完十门语言，得到的排序跟凭印象排出来的差别往往大得让人吃惊。 ## 芬兰语的最高级还要再过一遍格，词表要收到什么程度？ ## 从halpa到halvin中间发生了什么 芬兰语的便宜是halpa，比较级是halvempi，最高级是halvin。 注意中间那个字母，原形里是p，两个变化形里都成了v。 这是辅音级差，是芬兰语词形变化里最让工具头疼的一件事。 字符串层面halpa和halvin只有两个字母相同，看着像两个不相干的词。 任何一个基于编辑距离的相似度判断，在这里都会给出错误答案。 这跟芬兰语十五个格背后那个词干自己也会变的问题 (https://zhangwenbao.com/finnish-seo-fifteen-cases-consonant-gradation-keyword.html)是同一个机制，只不过在最高级上叠加得更狠：先做级的变化，再做格的变化，两层各自都可能触发词干改写。Snowball的芬兰语词干算法 (https://snowballstem.org/algorithms/finnish/stemmer.html)把这些规则写得很清楚，读一遍就知道为什么现成工具在这门语言上的召回率会掉得那么厉害。 编辑距离在这里失灵还带来一个连锁后果，很多站的关键词去重脚本是按相似度阈值跑的，halpa和halvin会被判成两个不相干的词而各自保留，而两个只差一个格尾的形态反倒会被合并掉，去重结果跟语言学上的正确答案正好反着来。 ## 十五个格乘上去之后的数量级 芬兰语的最高级形容词还要跟着名词一起变格。 halvin、halvimmat、halvimmassa、halvimman，这只是开头几个。 理论上一个最高级形容词能生成的形态数是两位数。 再乘上品类名词的数量，理论行数会冲到四位数。 这个数字大到没法用人工穷举，但也大到不能不管。 面对这种量级只有一个办法，就是放弃穷举、改用采样。芬兰办公用品那个项目我们的做法是先从芬兰语树库 (https://universaldependencies.org/treebanks/fi_tdt/index.html)里统计最高级形容词在真实文本里的格分布，发现主格和内格两个格占了接近八成，剩下十三个格分摊两成多。词表按这个分布收，只做前四个格，覆盖面和成本一下就平衡了。 格分布这件事在芬兰语言办公室的指南库 (https://www.kielitoimistonohjepankki.fi/)里能查到不少现成的用法说明，尤其是商品名和产品说明这类文体的惯用格，查一遍能省下不少自己统计的工夫，也能避免把书面语里高频、口语里根本不用的那几个格当成重点。 ## 收词的判据不是穷举，是查日志 理论形态数和真实查询里出现的形态数从来不是一回事。 用户不会把一个词的所有格都用来搜索，他们只用其中几个。 用哪几个由查询的句法位置决定，而句法位置是高度集中的。 站内搜索日志是唯一能直接看到这个分布的地方。 没有日志的时候，退而求其次是看自动补全给出的候选。 这条判据在工具在小语种上返回零 (https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html)的时候尤其管用，因为它不依赖任何外部数据源。把站内搜索框接一个月的日志，最高级词的形态分布会自己浮出来，而且这份分布是你的真实用户的分布，比任何第三方的聚合数据都贴合。 把站内搜索框接日志这件事的门槛比想象中低，多数建站系统自带查询记录，没有的话前端埋一个事件半小时就能加上。真正的障碍从来不是技术，是没有人认为这份数据属于自己，所以它经常存在但从没被人打开看过。 ## 关键词工具把这些形态合并了吗，报表上的数字能不能直接用？ ## 工具的合并口径在这一族词上尤其粗 主流关键词工具会把词形接近的查询合并成一行显示。 合并口径是按工具自己的归一化规则来的，各家不一样也不公开。 在英语上这个合并几乎没有副作用，因为形态本来就少。 在德语和芬兰语上，合并会把五个真实查询压成一个数字。 你看到的那个搜索量，是五个形态加在一起的和。 这件事跟俄语工具把十二种词形合成一个数字 (https://zhangwenbao.com/russian-seo-cyrillic-cases-declension-wordstat-keyword.html)是同一类问题，但最高级这一族更麻烦一点：俄语的十二种词形至少还看得出是同一个词，德语的五个形容词词尾在合并之后，你连它们分别是哪五个都不知道，工具不会展开给你看。 判断工具在某门语言上做没做合并，还有一个更省事的信号：看它返回的关键词列表里有没有出现明显不是词典原形的写法。如果整张列表清一色都是原形，基本可以断定归一化很激进；如果混着各种格尾和词尾，说明它保留了真实查询的原貌。 ## 词干还原在最高级上会把褒义和中性并到一起 德语的gut、besser、best是不规则变化，词干完全不一样。 Snowball的德语词干算法 (https://snowballstem.org/algorithms/german/stemmer.html)处理的是规则后缀，不规则形态它管不了。 于是gut和best在索引里是两个不相干的词元。 而billig和billigsten会被还原到同一个词干，被当成一个词。 同一族词里一半被合并、一半没有，这种半合并状态最难排查。 Duden的gut词条 (https://www.duden.de/rechtschreibung/gut)把这套不规则变化列得很完整，可以直接拿来当例外表的种子。实操上我们的处理是把所有不规则的形容词单独拉一张小表，一门语言通常只有五到十个，人工维护完全扛得住，剩下的规则形容词交给函数生成。 不规则形容词还有一个容易被忽略的坑，它们的比较级和最高级往往是这门语言里频率最高的几个词，DWDS的gut词条 (https://www.dwds.de/wb/gut)给出的用例密度能直观说明这一点。频率最高的词恰好是规则最不适用的词，这在所有语言里几乎是通例。 ## 一条十分钟能做完的自检 不必研究工具的归一化文档，直接测一次就知道。 挑一个品类，把这一族词的五个形态分别输进工具查搜索量。 如果五次查询返回同一个数字，说明工具在做合并。 如果返回五个不同的数字，说明工具保留了形态区分。 再把五个数字加起来跟合并口径下的那个数比一比，差多少一目了然。 这个自检要按语言各做一次，不能做完德语就推广到荷兰语，因为工具在不同语言上用的归一化模块不同。我们实测下来同一个工具在德语上做合并、在芬兰语上几乎不合并，原因大概率是芬兰语的词形变化太复杂、工具干脆没做，反而阴差阳错保留了真实分布。 做完这个自检要顺手把结果记在词表的说明页上，写清楚测试日期和用的是哪个工具版本。工具的归一化模块会更新，半年前测出来不合并不代表现在还不合并，而这种变化不会有任何公告，只能靠定期复测发现。 ## 没有数据的语言怎么估这一族词的量 小语种最常见的情况是工具直接返回零或者不显示。 这时候不要去猜绝对量，改成估比例。 用英语站的历史数据算出这一族词占自然搜索成交的比例。 再用目标市场的整体流量规模去乘，得到一个量级估计。 估出来的是量级不是精确值，但足够决定要不要投人力。 这个方法的前提是这一族词的意图结构跨语言是稳定的，也就是用最便宜搜索的人在哪门语言里都是准备买东西的人。这个前提在我们做过的语言上一直成立，唯一要留心的是同一批词在两个市场落地页要拆开 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)的那种情况，意图结构没变，但落地页的形态得跟着当地习惯走。 估比例这个办法还能反过来用一次：如果目标市场的整体流量规模已知，而这一族词估出来的量级小得离谱，那多半不是需求少，是你的品类名词在当地根本不是用这个词说的，问题出在上游的品类词翻译而不是最高级形态本身。 ## 商品标题模板怎么写，才能让最高级跟着品类名词自动对上？ ## 模板里最高级和名词必须绑定成一个字段 常见的模板写法是把修饰词和品类词做成两个变量再拼起来。 这个写法在英语上没问题，在德语上会拼出语法错误的标题。 因为修饰词的形态取决于品类词，两个变量之间存在依赖。 正确的做法是把这一对绑成一个字段，由生成函数统一产出。 模板里只留一个占位符，避免任何人手工拼接的机会。 这条约束要写进模板文档的第一行，因为它违反了大多数人对模板变量的直觉。模板变量默认是互相独立的，谁都不会想到这两个变量之间有依赖关系。我们吃过一次亏，一个新同事为了做A/B测试把两个变量拆开重新拼了一遍，上线三周之后才被母语审校发现有一整个品类的标题读起来是错的。 绑成一个字段之后还要顺手做一件事，就是在模板渲染层加一个断言，检查这个字段是不是来自生成函数而不是手工填写的。约束如果只写在文档里，它的有效期等于团队成员的记忆周期，写进代码才是永久的。 ## 例外表比规则表更值钱 规则能覆盖九成以上的组合，剩下那不到一成是外来词和品牌词。 外来词进德语之后的性别不是靠规则能推的，得查词典。 品牌词更麻烦，它的性别是市场约定俗成的，词典里根本没有。 这些词一旦进了模板，生成函数会给出一个语法上错误的形态。 所以例外表要跟规则一起上线，不能留到二期。 例外表的维护成本远比想象中低，因为例外的产生速度很慢，一个品类一年新增不了几个。真正的成本在第一次盘点，那次要把现有商品名逐个过一遍。宠物用品那次我们花了三天，找出十七个例外，其中十一个是英语借词，六个是品牌名，之后一年半只新增了四个。 例外表的字段要比大家第一反应的多一列，除了词和它的性别之外，还要写清楚这个判断的依据是词典、是本地同行的用法、还是母语者的语感。三种依据的可信度和可复核程度完全不同，半年后有人质疑某一行的时候，这一列能省掉一场没有结论的讨论。 ## 母语审校要看的是哪三行 把整批标题丢给母语者通读是最浪费的做法。 他们读得快、读得顺，但正好会漏掉形态这一层。 更有效的做法是给他们一张只有三列的表。 一列是品类名词，一列是生成出来的最高级形态，一列是勾选框。 去掉上下文，形态错误反而跳得出来。 这跟匈牙利语那种一个名词能接出十八种格尾 (https://zhangwenbao.com/hungarian-seo-eighteen-cases-vowel-harmony-keyword.html)的校对场景是同一个道理。形态错误在有上下文的句子里恰恰最容易被大脑自动纠正过去，读的人根本意识不到自己纠正了，而把同一个词单独拎出来放进表格，同一个人立刻就能看出不对。 三列表这个做法背后是一个更一般的原理：要让人看见某个维度，就得把其余维度全部拿走。上下文完整的段落里同时存在语义、语气、形态、标点四五个维度，注意力会自动流向最显著的那个，形态是其中最不显著的一个，永远排在最后。 ## 最高级词在广告和合规那一侧，为什么口径跟搜索侧正好相反？ ## 德国那条规定要求的是可证明的实质优势 德国的反不正当竞争法对误导性商业行为有明确规定。 广告里用最字打头的断言，属于需要举证的那一类表述。 举证的标准不是你觉得自己最好，是能拿出可核验的比较依据。 做不到举证就不能用，这一条在德语市场执行得相当实在。 类似的要求在欧盟层面也有，各成员国的落地细则略有差别。 德国反不正当竞争法第5条 (https://www.gesetze-im-internet.de/uwg_2004/__5.html)的原文可以直接读，它管的是有误导可能的商业行为，最高级断言只要不能被证实就落在这个范围里。欧盟层面的框架可以看欧盟委员会关于不公平商业行为的说明 (https://commission.europa.eu/live-work-travel-eu/consumer-rights-and-complaints/unfair-treatment_en)，两份材料结合起来看，判据比想象中清楚。 需要留意的是这类规定管的是广告和商业表述，不管用户在搜索框里打什么。限制落在你说的那一侧，需求留在用户搜的那一侧，两者从来不是同一件事——这个分界是后面所有解法的立足点，想不清楚它就会在该覆盖的地方主动放弃覆盖。 ## 同一串字符，两个部门给的分正好相反 这是我在这个项目上遇到过最干净的一次内部矛盾。 搜索团队看这一族词：意图最强、转化最高，必须抢。 合规团队看同一族词：断言风险、举证义务，能不用就不用。 两边说的都对，因为他们评的是同一串字符的不同侧面。 过去我见过的关键词争议都是量的争议，这一次是方向相反的争议。 这件事逼出来的一个通用做法是：凡是发现某一族词在两个部门那里的评分符号相反，就不要试图说服其中一方，而是去找那个能同时满足两边的第三种表述。争论谁对谁错会耗掉几周，找替代表述通常两小时就有结果。 这类符号相反的争议还有一个识别特征：两边引用的都是外部权威，一边引搜索数据，一边引法条，谁也说服不了谁。凡是双方都在引用外部依据的争论，都不是判断问题而是目标冲突，只能靠找第三种方案化解，讨论本身不会产生任何进展。 ## 破法是把断言词换成范围词，但别换掉查询词 关键在于分清楚哪一处字符是用户打的，哪一处是你说的。 标题和H1是你的断言，用户看得见，合规管得着。 结构化数据里的商品属性、筛选项的标签，是可查询的事实。 把最字换成范围表述，比如价格区间内、同类中价格较低。 而查询词的覆盖靠正文里的问答段和筛选组合去接。 宠物用品那次的最终方案是标题写成价格从低到高排的猫砂榜单，正文里用一段问答直接回答哪一款最便宜并列出当天价格和更新时间。断言变成了有出处的事实陈述，合规过了，而那一段问答本身就是最高级查询的最佳落点，搜索侧一分没丢。 完整的条文体系可以从德国反不正当竞争法的目录 (https://www.gesetze-im-internet.de/uwg_2004/)看起，把跟商业表述相关的几条一次读完，之后写文案时心里有数，不必每写一句就去问法务。这份阅读成本一次性投入，收益是后面几百条标题不用再逐条送审。 ## 榜单页、对比页、筛选页，哪一类最适合承接最高级查询？ ## 三类页面的形态承载能力不一样 榜单页天然带排序语义，跟最高级的意图最贴。 对比页承载的是两个具体商品之间的关系，意图更窄。 筛选页承载的是条件组合，形态灵活但语义偏弱。 三类页面能容纳的最高级形态数量差得很远。 榜单页的标题只有一个，只能放一个形态。 这就是这一族词的核心矛盾：意图最集中的页面类型，恰恰是形态容量最小的页面类型。榜单页只有一个标题、一个H1、一段导语，能塞进去的形态最多两三个，而德语这一族词有五个形态要覆盖。剩下的形态必须找别的地方安置，否则就是白做。 这个矛盾还能推广到别的高意图词族上，凡是意图越集中的查询，能承接它的页面类型就越少、越标准化，也就越没有位置放变体。意图强度和承载容量在页面这一层是负相关的，规划落点的时候要把这条当默认前提，而不是当成偶然遇到的困难。 ## 筛选页是唯一能把变体做成组合的地方 筛选页的URL参数天然是可组合的。 价格区间、品类、属性三个维度可以自由交叉。 每一种组合都可以有自己的标题模板和自己的形态。 这让形态覆盖从一个位置变成了几十个位置。 代价是要处理索引控制，不能让组合页无限膨胀。 我们的做法是只放开有真实搜索量的那些组合进索引，其余的做规范化处理指回主榜单页。判断有没有搜索量靠的还是站内日志，一个月的数据足够把值得开放的组合筛出来。这一步跟多语言站的语言版本对应关系 (https://zhangwenbao.com/international-seo-hreflang-complete-guide.html)要一起规划，否则德语站开放的组合和法语站开放的组合对不上，对应关系会缺一大半。 开放组合的时候有一个容易踩的顺序问题：应该先确定标题模板再开放索引，而不是先放开再补模板。反过来做的结果是搜索引擎先抓到一批标题重复的组合页，等模板补上去之后，重新评估这些页面质量所需的时间比一开始就做对要长得多。 ## 面包屑和列表标题是免形态区 页面上有几个位置天然不需要完整的语法形态。 面包屑是一串名词，不需要形容词跟它一致。 列表项的标题、卡片上的短标签，同样可以用词典原形。 这些位置可以放形态最简单的那个版本，不会读起来别扭。 把需要精确形态的需求挪到这些位置，是最省事的一种解法。 这条思路跟URL用本地字母还是拉丁转写 (https://zhangwenbao.com/minor-language-url-native-script-vs-latin-transliteration.html)那篇里的判断方式一致：先问这个位置到底受不受语法约束，不受约束的位置就是免费的容量。整个页面里的免形态区加起来，通常比大家以为的多得多。 免形态区的清点最好在改造之前做一遍，把页面上的每一个文本位置列出来，逐个标记它是完整句子还是独立短语。独立短语的位置就是免形态区，一个典型的商品列表页上这样的位置能有十几个，加起来的容量足够安置那几个次要形态。 ## 词表要留几列，行数怎么估 ## 五列结构：概念、形容词、名词性数、成品串、匹配类型 概念列写的是中性描述，比如价格最低，不写任何目标语言。 形容词列写词典原形，只作参考，不直接使用。 名词性数列写品类名词的语法属性，是生成函数的输入。 成品串列是真正拿去用的那一列，也是唯一允许进标题的一列。 匹配类型列标记这个串在广告里该按哪种匹配投。 五列里最容易被砍掉的是概念列，因为它看起来是冗余的。但它是整张表跨语言对齐的唯一依据，砍掉之后德语表和西语表就没有任何一列能对上，做多语言对照的时候只能靠人肉猜。这一列在波兰语那种一个词有六个格要覆盖 (https://zhangwenbao.com/polish-seo-seven-cases-diacritics-keyword-research.html)的语言上尤其不能省。 这五列还要再加一条使用约定：任何下游系统取值都只能取成品串那一列，不许自己拼。约定写在表头的注释里，并且在导出接口上只暴露这一列。能被误用的字段迟早会被误用，最省心的做法是让它在接口层根本不存在。 ## 行数估算的分母是品类不是词 估这张表有多大的时候，很多人会先数形容词的个数。 形容词的个数是个位数，怎么估都不大。 真正决定行数的是品类名词的数量和它们的性数分布。 所以分母要换成品类，一个品类一个品类地算。 算出来的数才是要交给翻译和运营的真实工作量。 这条跟前面算出来的那个六十行是同一件事的两个角度。先按形容词估会得到六这个数，按品类估会得到六十，两者差一个数量级。项目排期用哪个数，决定了这件事是被当成半天的小任务还是一周的正式工作。 按品类估还有一个附带好处，它天然给出了这件事的拆分方式。六十行没法拆给三个人做，但六个品类各十行可以，而且每个人拿到的都是一个完整的、能独立验收的单元，不会出现三个人都做了一半、合起来却对不上的情况。 ## 用一个品类先跑通再铺开 不要一上来就把所有品类的表都做出来。 挑一个品类做完整流程，从词表到标题到上线到看数。 这个品类会暴露出流程里所有的坑，成本只有全量的几十分之一。 跑通之后剩下的品类基本是复制粘贴加换词。 挑品类的标准是数量适中、性数分布覆盖得全。 宠物用品那次我们挑的是猫砂，理由是它的相关品类名词正好覆盖了阳性、阴性、中性和复数四种情况，一个品类就把五个词尾都用上了。挑一个性数分布单一的品类会让你误以为流程已经跑通，铺开的时候才发现还有三种情况没验证过。 试点品类还要满足一个隐含条件，就是它的数据量足够支撑上线后看数。选一个月只有几十次查询的冷门品类，跑完流程你会发现所有指标都在噪声范围里，什么结论都得不出来，等于白跑一轮完整流程。 ## 交给翻译之前要写清楚哪一列不许动 成品串那一列是函数生成的，翻译不能手工改。 但翻译看到不通顺的地方会本能地想去顺一下。 顺完之后形态就跟名词对不上了，而且没有任何报错。 所以工单上要明确标注这一列只读，改动请提到问题列。 问题列里的反馈拿去改生成函数，改完全表重新生成。 这条规则要用一句话写在工单最上面，别指望写在附件里有人看。我们后来干脆把成品串那一列在协作表格里设成了受保护区域，想改也改不了，反馈只能填到旁边的备注列。工程手段永远比口头约定可靠，尤其是当那个约定违反人的本能的时候。 这一条的更一般形式是：凡是要求人违反本能的规则，都必须用工程手段兜住。译者顺一下不通顺的句子是职业本能，运营看到空格想填满是本能，开发看到重复代码想抽象是本能，靠提醒对抗本能的成功率长期看接近于零。 ## 上线之后盯哪几个数 ## 第一个数：形态覆盖率 分母是词表里的成品串总数，分子是站上实际出现过的串数。 这个数一开始通常只有三到四成，因为大量串还没找到落点。 盯着它往上走，涨不动的时候说明落点位置不够用了。 这时候要么开筛选页组合，要么在正文里增加问答段。 覆盖率到七成以上，这一族词的工程部分基本就做完了。 算这个数不需要爬虫，直接从内容库里取字段做字符串匹配就行，一个脚本几分钟跑完。要注意的是匹配要做完整词匹配而不是包含匹配，否则billigste会被billigsten命中，覆盖率会虚高一大截。 覆盖率这个数在早期会涨得很快、到七成之后突然变慢，这是正常曲线而不是遇到瓶颈。前面涨得快是因为高频形态本来就有天然落点，后面慢是因为剩下的都是低频形态，需要专门造位置。看到曲线变平不必着急加人，先算一下剩下那些串值不值得。 ## 第二个数：同概念多形态的份额分布 把同一个概念下的五个形态在真实查询里的份额拉出来。 正常情况下会呈现明显的头部集中，一两个形态占大头。 如果分布异常平均，多半是采样量还不够。 头部形态确定之后，标题位优先给它，其余的放正文。 这个分布每季度复核一次就够，它变化得很慢。 这个数还有一个隐藏用途：它能反过来验证你的品类名词性数标注对不对。如果某个概念下本该是主流的那个形态份额接近零，通常不是用户不搜，是你把那个品类名词的性数标错了，生成出来的串根本不是一个合法的德语表述。 份额分布还要跟设备维度交叉看一次，桌面端和移动端的形态偏好差异往往比语言之间的差异还大。同一门语言在两种设备上可以是两套查询习惯，如果你的标题只按合并后的总份额来定，那就等于在给两拨人写同一个标题而只讨好了其中一拨。 ## 第三个数：本地同行的对照基线 挑三家本地头部同行，用同一批成品串去查它们的排名。 你的排名除以这三家的均值，得到一个相对分。 相对分比绝对排名稳定，也更能反映真实差距。 更重要的是它能告诉你本地同行做没做这一族词。 如果三家都没做，这一族词就是一片没人抢的空地。 德语宠物用品那次的对照基线给了我们一个意外结论：三家本地同行里有两家的最高级形态也是错的，标题读起来别扭。这意味着形态做对本身就是一个可以拿来竞争的点，而不只是一个不出错的底线。德语市场那些复合词的坑 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)本地商家一样会踩，语言是母语不代表商品页写得对。 对照基线还要每年重测一次，因为同行也在改。头一年他们形态写错是你的机会，第二年如果他们改对了而你还停在原地，这个相对分会掉得比绝对排名快得多，而绝对排名可能一点没变，你会完全看不出发生了什么。 ## 常见问题解答 ## 最高级关键词的形态覆盖，值得投入多少人力？ 按品类算，一个品类的完整流程大约需要一到两天，包括词表生成、例外表盘点、模板改造和母语抽检。铺开到十个品类通常在两周左右，之后进入维护状态，每季度花半天复核形态份额分布即可。判断值不值的依据是这一族词在英语站占自然搜索成交的比例，我们做过的项目里这个比例通常在三到四成之间，按这个量级折算，两周投入的回报周期一般不超过两个月。需要提醒的是这个投入不能摊到日常迭代里做，它必须是一段连续的工作，因为词表、模板和例外表三者互相依赖，拆成三个迭代做完，中间那两次上线的产出都是不可用的。 ## 如果只做一件事，应该先做哪一件？ 先把标题模板里的修饰词和品类词绑成一个字段。这一件事的成本最低、影响面最大，而且它是所有后续工作的前提：字段没绑好，词表做得再准也会在拼接那一步被打散。绑完之后哪怕形态覆盖率还只有三成，至少站上已经出现的那些串全部是合法的，不会出现语法错误的标题被搜索引擎和用户同时看到。剩下的覆盖率可以慢慢往上补。判断这一步做没做完的办法也很简单，随机抽二十条已经上线的标题交给母语者读一遍，如果没有任何一条被指出形态别扭，这一步就算过了，可以开始往覆盖率上使劲。 ## 分析式语言是不是就不用管这件事了？ 不是，只是关注点不同。西班牙语和法语这类分析式语言不会产生新词形，但功能词的搭配同样有固定用法，用错了照样读起来不像本地人写的。而且分析式表述的词元更多，在广告匹配和站内搜索里的行为跟单词元完全不同，报表口径要单独设。真正省下来的只是词形生成那一步，词表结构和落点规划这两件事一样也少不了。还有一个容易忽略的差别，分析式语言的功能词经常是搜索引擎的停用词，写进标题里不增加任何匹配权重却会占掉宝贵的字符数，所以标题的字符预算要按去掉功能词之后的有效长度重新算一遍。 ## 关键词工具给出的搜索量数字到底能不能用？ 可以用来排序，不能用来做绝对量的预算。这一族词在合并口径下的数字是几个形态的和，用它来判断哪个概念比哪个概念热是可靠的，用它来推算某个具体标题能带来多少流量则会高估。想拿到分形态的数字，只能靠站内搜索日志或者自己分别投一小笔广告去测。测的成本不高，一个品类几百块就能跑出可用的分布。另外要留意工具给出的竞争度指标同样受合并口径影响，几个形态合并之后的竞争度会显得比任何单一形态都高，据此判断这一族词太贵而放弃投放，是这一层最常见的一个误判。 ## 合规那一侧的限制，在非德语市场同样严格吗？ 各市场的严格程度不一样，但方向是一致的：断言型表述需要依据。德语市场执行得最实在，法语和北欧市场也不宽松。稳妥的做法是不管在哪个市场都按同一套原则来做，把标题里的断言换成有出处的事实陈述，把最高级查询的承接放到正文的问答段和筛选组合里。这样做一次就能全市场通用，比逐个市场研究细则省事得多。还有一个实际的好处，统一按最严格的市场做能让内容资产在市场之间自由搬运，不必因为某个市场的合规口径更松就多做一套宽松版本，那一套迟早会在别的市场被误用。 ## 词表交给母语译者做，为什么还是会出问题？ 因为译者的工作目标是让句子读起来自然，而形态覆盖的目标是穷举所有合法变体，这两个目标在同一张表上是冲突的。译者本能地会给出最自然的那一个形态，把其余四个当成不必要的重复删掉。解法是把两件事拆开：让译者只负责概念列到形容词原形的翻译和例外表的判断，形态生成交给函数，母语抽检用去掉上下文的三列表来做。这种冲突在验收环节同样会出现，译者验收时看的是通顺度，工程验收时看的是覆盖度，两张验收表如果合并成一张，通顺度那几项一定会把覆盖度那几项挤掉，因为前者更容易被感知。 ## 这套方法能不能直接套到比较级上？ 结构上可以，但优先级低很多。比较级在电商查询里的出现频率远低于最高级，用户很少搜更便宜的猫砂，他们直接搜最便宜的猫砂。比较级更多出现在对比页和评测内容里，那些页面的形态承载能力本来就强。建议的做法是先把最高级做完做透，比较级只在词表里留一列位置，等有真实查询数据支撑的时候再补。还有一个折中办法是把比较级并进对比页的正文而不是单独立项，对比页本来就在做两个商品之间的比较，比较级形态在那里出现是自然的，顺手覆盖掉几条查询，几乎不产生额外成本。 ## 权威参考资料 ## 小语种URL用本地字母还是拉丁转写，地址栏里看不出差别，日志和外链里差得很明显 - URL：https://zhangwenbao.com/minor-language-url-native-script-vs-latin-transliteration.html - 分类：小语种SEO - 发布：2017-11-27 | 更新：2026-07-26 - 摘要：小语种网址该写本地字母还是拉丁转写？讲清域名与路径两套机制的区别、百分号编码的展开长度代价、多套转写标准带来的外链落空，以及变音符号折叠的碰撞检测。 - 关键词：URL优化,技术SEO,多语言SEO,小语种SEO > **TLDR**：摘要：浏览器地址栏会把本地字母的网址解码成好看的样子，可这只是显示层的礼貌。真正流通的那一串是百分号编码，一个西里尔字母展开成九个字符。转写看着安全，但一门语言常常有好几套转写标准，别人写外链时用的不一定是你选的那一套。 > 摘要：浏览器地址栏会把本地字母的网址解码成好看的样子，可这只是显示层的礼貌。真正流通的那一串是百分号编码，一个西里尔字母展开成九个字符。转写看着安全，但一门语言常常有好几套转写标准，别人写外链时用的不一定是你选的那一套。 ## 地址栏里看到的和实际传输的不是一串东西 ## 浏览器替你做了一层解码 把一个带本地字母的网址粘进地址栏，看起来一切正常。 字母清清楚楚，跟你在编辑器里写的一模一样。 但这只是显示层的处理，浏览器为了好看做的解码。 真正发出去的请求里，那些字母全部变成了百分号加十六进制。 服务器日志、抓取记录、数据导出里存的都是编码后的形态。 两者是同一个地址的两种表示，但你能看到的场合完全不同。 这个错觉造成的后果是决策时用的是显示层的直觉，而承担代价的是传输层的现实。判断该用哪种写法之前，先做一件事：把候选网址复制出来粘进纯文本编辑器，你看到的就是真实形态。所有讨论都应该基于这个形态，而不是地址栏里那个已经被美化过的版本。 不同浏览器的解码策略还不完全一样，有的会在地址栏里显示解码形态但复制出来是编码形态，有的两边一致。所以团队内部沟通地址时不要口头描述，直接贴纯文本，否则两个人说的可能是同一个地址的两种形态而彼此不知道。 ## 一个字母展开成几个字符 展开的倍数取决于这个字母在编码里占几个字节。 拉丁字母加变音符号通常占两个字节，展开成六个字符。 西里尔字母、希腊字母占两个字节，同样是六个，西里尔页面被抓回去变成一串认不出的拉丁字母 (https://zhangwenbao.com/cyrillic-encoding-legacy-windows1251-utf8-indexing-cost.html)讲的就是字节这一层。 汉字、假名、天城文这类占三个字节，展开成九个字符。 表情符号和某些扩展字符占四个字节，展开成十二个。 所以一个十二个字母的本地词，能展开成上百个字符。 算一下具体的量级：一个由三个词组成的分类路径，本地字母写出来大概二十来个字符，编码之后能到一百二十个以上。加上域名和目录层级，整条地址轻松超过两百个字符，而这个长度会出现在你所有的报表、导出文件和外链锚里。 长度还有一个隐性上限要留意，某些服务器和代理对请求行的长度有默认限制。正常的分类路径不会碰到，但带多个筛选参数的地址在编码之后可能接近甚至超过限制，表现为个别筛选组合直接报错，而这类错误只在特定组合下出现，很难被测试覆盖到。 ## 长度会在哪些地方咬人 长度本身不影响抓取，引擎处理长地址没有问题。 咬人的地方在人和工具要处理这串字符的那些环节。 表格软件的单元格、日志分析工具的列宽、报表的截断。 邮件和即时消息客户端的自动链接识别也是一个常见断点。 有些客户端遇到非拉丁字符就停止识别，链接被截成两半。 用户复制粘贴分享时，断掉的那半截会变成无效链接。 真正难受的是这类问题不会集中爆发，而是零散地降低每一个分享环节的成功率。你在数据里看到的只是社交渠道的引荐流量偏低，没法归因到具体原因上。相比之下拉丁转写的地址在任何客户端里都能被完整识别，这一条是它最实在的优势。 还有一个受影响的场合是纸质和图片素材，包装、说明书、线下广告上印的地址如果是编码形态，那就完全没法看；要印的话必须准备一个短的拉丁形态作为替代入口，并配好跳转。这件事往营销部门那边一说通常都能理解，但等到素材已经付印才发现就来不及了。 ## 域名和路径为什么走两套不同机制？ ## 域名那一段走的是另一条路 本地字符的域名和本地字符的路径，机制完全不同。 域名部分不能直接放非拉丁字符，要先转成一种特殊编码。 转出来的结果以两个字母加两个连字符打头，后面跟一串字符，算法本身写在RFC 3492的Punycode定义 (https://www.rfc-editor.org/rfc/rfc3492)里。 这个转换是可逆的算法，不是百分号编码，两者不通用。 路径部分才用百分号编码，走的是RFC 3986对保留字符与编码的规定 (https://www.rfc-editor.org/rfc/rfc3986)那一套。 把这两个机制混着说，是这个话题上最普遍的误解。 为什么必须分开：域名要经过域名系统解析，而域名系统历史上只接受有限的字符集合，所以需要一种把任意字符压进这个集合的算法。路径不经过域名系统，它由服务器自己解释，所以可以直接用字节的百分号表示。两套机制解决的是两个不同的约束。 这个算法的另一个特点是转换结果对输入的大小写和规范化形式敏感，所以域名在转换之前要先做统一处理。国际化域名的相关规范专门定义了这套预处理流程，包括哪些字符允许、哪些必须映射、哪些直接禁止，不按流程走可能生成一个语法上合法但解析不到的域名。 ## 混淆之后会犯什么错 最常见的错是以为域名能用本地字母，路径就自动能用。 或者反过来，以为路径要转写，域名也必须转写。 两个决策其实是独立的，可以任意组合。 本地字符域名配拉丁转写路径，这个组合相当常见。 拉丁域名配本地字符路径，也完全成立。 四种组合各有适用场景，不该被绑成两个选项。 混淆的另一个后果是排查问题时找错方向。域名解析层面的问题和路径处理层面的问题症状可能相似，都表现为访问不了或者跳转异常，但排查工具完全不同。先确认是哪一层出问题，再选工具，能省下大量时间。 还有一种混淆出现在配置层面，把域名的国际化设置和服务器上路径的字符编码设置当成同一件事去改。两者由不同的组件负责，改错了地方的典型症状是改动完全没有效果，然后有人开始怀疑缓存，一路查到很晚才发现方向从一开始就错了。 ## 两套机制的规范各自在哪里 路径的百分号编码规则定义在网址的基础规范里。 用非拉丁字符表示网址的那套扩展，另有RFC 3987定义的国际化标识符 (https://www.rfc-editor.org/rfc/rfc3987)这份独立规范。 域名那一段的编码算法有自己的独立文档。 域名系统的国际化处理还有一整套后续规范在管。 做技术决策时，这几份文档要分清楚各自管什么。 引用错了文档，团队内部讨论会一直对不上。 实操上不需要通读这些规范，但要知道遇到分歧时该翻哪一份：路径怎么编码翻网址规范，非拉丁字符怎么表示翻那份扩展规范，域名那一段怎么转翻编码算法文档，国际化域名的合法性规则翻后续那套规范。分清楚这四个入口，讨论就不会绕圈。 除了这几份规范，还有一份把网址处理写成可实现算法的现代标准，浏览器实际是照它实现的。规范之间偶有细节差异，遇到浏览器行为跟规范描述不一致的情况，以那份可实现算法为准，因为它才是真正被执行的那一套。 ## 转写为什么比看起来危险？ ## 一门语言常常有好几套转写标准 转写听起来像个确定的操作，实际上远不是。 同一门语言往往同时存在好几套互不兼容的转写方案。 国际标准一套、地名机构一套、护照系统又一套。 各国的国家标准还会再来一套，媒体有自己的习惯写法。 同一个字母在不同方案里转出来的拉丁形态完全不同。 你选了哪一套，只有你自己知道，外面的人不知道。 问题的严重程度可以这样估：如果某个字母有三套常见转写，一个含两个这类字母的词就有九种可能的拉丁写法。你的地址只占其中一种，剩下八种如果有人写成外链，全部落在不存在的地址上。这不是理论风险，做过俄语和阿拉伯语市场的都遇到过。 方案多还带来一个内部管理问题，就是不同部门可能各自选了不同的方案。技术团队按国际标准生成地址，市场团队按媒体习惯写素材，客服按证件方案回答用户，三套并行且互不知情。上线前把选定的方案写进一份所有人都能看到的规范，比事后统一便宜得多。 ## 那些分歧最大的字母 分歧集中在少数几个音上，而它们恰好都是高频字母。 西里尔字母里发擦音的那几个是重灾区。 同一个字母能被转成一个字母、两个字母或者带记号的形态。 还有的方案用两个字母，另一个方案用四个字母。 做词表时，这几个字母出现在词里的概率相当高。 换句话说，受影响的不是个别词，是相当大一部分词。 应对办法不是选一套最好的，而是先统计自己的词表里含这些高分歧字母的比例。比例低的话随便选一套都行；比例高就必须做多套并存加跳转，因为无论选哪一套都会漏掉大半的外部写法。这个统计用一段简单的字符匹配就能跑出来。 统计的时候要按加权算而不是按词数算，用每个词的搜索量或者页面流量做权重。含高分歧字母的词如果都是长尾，影响面比看着小；如果集中在头部词上，哪怕比例不高也必须做多套并存，因为损失全落在最值钱的那批流量上。 ## 有官方一一对应的语言风险低得多 不是所有语言的转写都这么乱，有几门语言运气很好。 关键的判据是这门语言有没有官方的一一对应拉丁正字法。 塞尔维亚语就有，联合国给它的罗马化方案 (https://www.eki.ee/wgrs/rom1_sr.htm)里两套字母严格一一对应。 每个西里尔字母只对应一个拉丁形态，反过来也一样。 这种情况下转写是确定的，外部写法不会分叉。 俄语没有这种对应，同一机构给俄语的方案 (https://www.eki.ee/wgrs/rom1_ru.htm)跟其他几套并存，阿拉伯语和泰语同理，风险高得多。 这条判据可以直接当决策的第一道闸：有官方一一对应正字法的，转写路线安全，可以放心用；没有的，要么走本地字符路线，要么做多套并存。判断办法是查这门语言的官方语言机构或者地名罗马化系统的现行文件，看它是不是给出了完整的双向对应表。 即使有官方一一对应正字法，也要确认一件事，就是这套对应表里有没有用到带记号的拉丁字母。如果有，那些字母在地址里又要面对折叠的问题，等于把风险从转写层转移到了折叠层。真正低风险的是那些对应表全落在基本拉丁字母上的语言。 ## 外链会落在哪一套上不由你决定 这是转写路线最难受的一点，你控制不了外部写法。 本地媒体写你的品牌名和商品名时，用他们习惯的转写。 论坛用户手打地址时，按自己的键盘习惯来。 国际媒体可能用国际标准，本地媒体用国家标准。 这些写法都不是你的地址，全部落在四百零四上。 你只能事后发现，然后一条条做跳转补救。 正确的做法是提前建一张变体表：把每个高分歧字母的全部常见转写列出来，组合生成主要变体，全部预先配好跳转指向正确地址。这件事在上线前做只要几个小时，上线后再补要一条条从抓取报告里捞，成本完全不同。 变体表的规模是可控的，因为高分歧字母只有几个，而且不是每个词都含它们。实际生成出来通常在几百到几千条量级，用一条带模式匹配的跳转规则就能覆盖，不需要一条条写。规则要放在服务器配置里而不是应用层，这样不占应用的处理开销。 ## 折叠变音符号会撞出什么？ ## 两个不同的词折成同一个 还有一条中间路线，就是保留拉丁字母但去掉变音符号。 这条路线看着最省事，实际上有个致命的碰撞问题。 捷克语和斯洛伐克语分家之后的选词差异 (https://zhangwenbao.com/czech-slovak-seo-content-reuse-decision.html)里提到的两个词，去掉记号之后拼写完全相同。 一个是形容词的阴性形式，另一个是表示序列的名词。 它们折叠之后都变成同一串字母，地址会撞车。 克罗地亚语跟斯洛文尼亚语的字母表差异 (https://zhangwenbao.com/croatian-slovenian-seo-two-small-markets-decision.html)、越南语带调与不带调的两拨人 (https://zhangwenbao.com/vietnamese-seo-tone-marks-syllable-spacing-keyword.html)那边都有大量类似的对子。 碰撞的处理办法有三种：给后来的加后缀、把碰撞的两个词合并到一个页面、或者对这批词保留记号走百分号编码。第三种最干净但会让地址风格不统一，第一种最常用但要保证后缀规则稳定，不能这次加数字下次加单词。选定一种就写进规范，别每次临时决定。 碰撞还有一种更隐蔽的形式，就是折叠之后跟一个已存在的英文单词撞上了。这种撞车在功能上不报错，但会让地址的语义变得莫名其妙，也可能让引擎误判页面的语言。检测时把英文常用词表也加进比对范围，能提前发现这类情况。 ## 折叠规则是按语言定的 更麻烦的是折叠本身没有唯一正确答案。 德语的变音字母正确的折叠是加一个字母，不是去掉记号。 把它简单去掉记号，得到的词在德语里是错的。 土耳其语一个词后面挂五层后缀 (https://zhangwenbao.com/turkish-seo-agglutinative-suffix-stacking-keyword.html)那边还有个陷阱，无点字母不能折成普通的那个字母，那是另一个音。 匈牙利语的长元音字母折成短元音还是加字母，也有分歧。 所以折叠表必须按语言存一份，不能全站共用一个函数。 验证自己的折叠表对不对有个便宜办法：找二十个包含变音字母的当地高频商品词，折叠之后拿去做站外的精确匹配查询，看返回的结果是不是同一个概念。折叠错的词返回的结果会明显跑偏，二十个词跑完不到半小时。 折叠表还要跟站内搜索的处理保持一致。如果地址生成用的是一套折叠规则，站内搜索的模糊匹配用的是另一套，用户从搜索结果点进来可能落到不存在的地址上。两处共用同一份配置是最省事的做法，也是最容易被忽略的一致性要求。 ## 大小写在两个地方会出问题 网址路径是区分大小写的，这一点比想象中重要。 生成地址时统一转小写，是绝大多数系统的默认做法。 但转小写这个操作在某些语言里不是逐字符的简单映射。 土耳其语的大写点字母转小写之后应该带点，普通规则给的是不带点。 希腊语词尾的西格玛转大写再转回来，形态会变。 这两类错误会让同一个词生成出两个不同的地址。 防这类错误的办法是在转小写时显式指定语言，多数运行时都支持带地区参数的大小写转换。这一行代码的差别会决定土耳其语站上一批地址是对的还是错的，而且错了之后症状很隐蔽：地址能访问，只是跟你词表里的那个不是同一串。 除了这两门语言，还有一类风险来自那些大小写映射不是一对一的字符，比如某些连写字母转大写之后会变成两个字母。这类字符在地址里很少见但确实存在，稳妥的做法是在生成地址时限制字符集合，只允许基本拉丁小写字母、数字和连字符，从根上避开整类问题。 ## 规范化形式也要统一 带记号的字符在编码里可能有两种表示方式。 一种是一个独立的码位，另一种是基本字母加一个组合记号，波斯语同一个词两套码位怎么在索引里对齐 (https://zhangwenbao.com/persian-seo-iran-market-letters-digits-zwnj.html)讲的是同一类问题。 两种表示看起来完全一样，字节序列却不同。 字节不同，百分号编码出来的地址就不同。 所以生成地址之前必须先按UAX #15的规范化形式 (https://www.unicode.org/reports/tr15/)做一次统一。 不做这一步，同一个词在不同来源会生成两个地址。 规范化这一步在苹果系统的文件名和某些编辑器里特别容易出问题，因为它们默认用的是分解形式，而多数网页和数据库用的是合成形式。从这类来源导入词表时不做规范化，你会得到一批看起来正确却打不开的地址。 规范化的选择上，网页世界普遍用合成形式，所以地址生成也应该统一到合成形式再做编码。要注意的是有些运行环境的默认行为不是这个，需要显式指定。这一行的默认值差异会导致同一份代码在开发机和服务器上生成出不同的地址，排查起来非常费时间。 ## 排序和去重会在哪里出错？ ## 编码后的串按字节排序 百分号编码之后的地址是纯拉丁字符串。 拿它排序，得到的是按字节顺序的结果。 字节顺序跟这门语言的字母顺序基本没有关系。 报表里按地址排序看数据，顺序会显得毫无逻辑。 要按语言顺序排，得先解码再用语言相关的排序规则。 这一步在多语言站的报表里经常被漏掉。 影响不只是好看不好看。按错误顺序排的报表会让人误判分布，比如以为某一类地址集中在某个区段，实际上那只是字节序造成的错觉。做地址结构审计时，先解码再排序是必须的一步。 排序还有一个实际场景会受影响，就是站点地图和地址清单的人工核对。按字节序排出来的清单，同一个分类下的地址会散落在各处，核对时很容易漏看。做核对用的清单一定要先解码再按语言排序，或者干脆按目录层级分组之后再排。 ## 去重要在解码之后做 去重同样有个顺序问题，容易搞反。 同一个地址可能以编码和未编码两种形态出现在数据里。 直接对字符串去重，两种形态会被算成两条。 正确做法是先统一解码并规范化，再去重。 不这么做，抓取统计和收录统计的数字会虚高。 虚高的比例取决于数据来源的混杂程度，有时相当可观。 还有一层更隐蔽的重复，就是百分号后面的十六进制字母有大小写两种写法。规范建议用大写，但很多工具生成小写，两者指向同一个地址却是不同的字符串。去重之前统一成一种大小写，这一条经常被漏掉。 还有一类重复来自尾部斜杠和默认文件名，这跟字符编码无关但会跟它叠加出现，让重复的形态组合变多。去重的规范化步骤应该把这几项一起处理：统一大小写、统一解码、统一规范化形式、统一尾部斜杠，四项一次做完再比对。 ## 同形字符会伪装成合法地址 还有一类问题跟安全相关，也影响地址设计。 不同文字系统里有一批字符长得几乎一模一样。 拉丁字母和西里尔字母之间就有十几对同形字符。 用它们能构造出视觉上完全一样的假地址。 浏览器为此对本地字符域名的显示做了限制。 混用两种文字的域名，很可能被强制显示成编码形态。 这一条直接影响本地字符域名路线的可行性：如果你的品牌名里同时含拉丁字母和本地字母，浏览器可能拒绝把它显示成好看的形态，那么本地字符域名最大的优势就没了。上线前用主流浏览器各试一遍显示效果，别只在一个浏览器里看。 同形字符的问题在路径部分同样存在，只是不像域名那样有浏览器帮你拦。如果你的地址里允许出现多种文字的字符，理论上可以构造出视觉相同但实际不同的路径，用来做钓鱼或者混淆内部链接。限制地址的字符集合是最简单的防线。 ## 怎么在四种组合里选一个？ ## 先回答四个问题 选择的输入是四个可以直接查的事实，不是偏好。 第一个问题，这门语言有没有官方一一对应的拉丁正字法。 第二个问题，你的外链主要来自本地媒体还是国际来源，这跟两个市场的关键词表一样而落地页要拆成两种 (https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html)是同一类市场判断。 第三个问题，品牌名本身是拉丁字母还是本地字母。 第四个问题，站上有没有已经积累了流量的存量地址。 四个答案凑齐，选项通常只剩一个或者两个。 四个问题的权重不相等，第四个是硬约束，有存量的话讨论空间很小；第一个是决定性输入；第二个和第三个是调节项。按这个顺序问，能避免团队在偏好上争论，因为四个问题的答案都是客观事实，查一下就有。 四个问题之外还有一个软性输入值得记下来，就是团队里有没有人长期负责这门语言。有的话，本地字符路线带来的额外运维成本是可承担的；没有的话，选通用性更好的那条路线更稳妥，因为出问题时没人能快速判断是哪一层的问题。 ## 本地字符路线适合谁 本地字符路线的最大优势是给本地用户的亲和感。 用户在搜索结果里看到自己语言的地址，可信度更高。 地址里的关键词对本地用户是可读的，这点有实际价值。 适合的情形是外链主要来自本地、品牌名本身是本地字母。 不适合的情形是有大量国际来源的外链和分享。 也不适合品牌名混用两种文字的情况。 选这条路线要接受一个长期成本，就是所有涉及地址的运维工作都要多一道解码步骤，包括日志分析、报表制作、外链核对、批量改动。这个成本不高但会一直存在，团队里得有人知道这件事，否则每次换人都要重新踩一遍。 这条路线还有一个容易被高估的好处，就是地址里的关键词。地址里的词对排名的作用本来就有限，加上编码之后在很多场合下不可读，所谓关键词可见的收益主要体现在搜索结果页的加粗上。把这一项当成主要理由去选，通常会失望。 ## 转写路线适合谁 转写路线的优势是通用性，在任何环境里都不出问题。 地址短、可复制、任何客户端都能完整识别。 适合的情形是这门语言有官方一一对应的正字法。 也适合国际来源外链占比高、需要跨市场统一风格的站。 不适合的情形是这门语言的转写方案有多套且分歧大。 选这条路线必须配那张变体跳转表，不然外链会漏掉大半。 转写路线还有一个容易被忽略的好处，就是它让跨市场的地址结构可以保持一致。做多个小语种市场时，一致的结构让模板、日志分析脚本、报表口径全部能共用，这部分节省的工程量在市场数量多的时候相当可观。 转写路线的一个附带要求是转写规则必须写成代码而不是让人手填。手填的地址在几百条以内还能维持一致，到了几千条必然出现同一个字母在不同地址里转法不同的情况，那时候补救比重做还麻烦。上线前就把生成器写好，成本很低。 ## 混合路线怎么划边界 实际做的时候，混合往往是最务实的选择。 常见的划法是目录层用转写，最末一级用本地字符。 目录层是有限的几十个，转写之后稳定又好管。 末级是商品名，数量巨大且本地可读性最有价值。 另一种划法是品类页用本地字符，内容页用转写。 划完之后要写进规范，别让不同的人各自决定。 混合路线的风险在于边界模糊之后会退化成随意混用，那比任何一种纯路线都糟糕。防这个的办法是把规则写成生成器的配置而不是文档里的一段话：地址由程序按规则生成，人不手写，边界就不会漂。 划边界时有个实用建议，让边界跟内容的更新频率对齐。变动少的层级用转写，因为它一旦定下来就长期不动；变动多的层级可以用本地字符，因为反正每次都是新生成的。这样规则的稳定性和可读性的收益各自落在最合适的位置上。 ## 上线前该怎么把这套规则验一遍？ ## 先建一份最难的测试词表 验证的第一步是准备一份专门用来找麻烦的词表。 这份表不用大，三十到五十个词就够，但每个都要有针对性。 把全部高分歧转写字母各找两个真实商品词放进去。 把已知的折叠碰撞对子成对放进去，两个都要有。 把带特殊大小写行为的字母各找一个词放进去。 再放几个含两种表示形式的带记号字符的词。 这份表要跟着代码一起进版本库，每次改动地址生成逻辑都跑一遍，输出结果跟上一次比对。它的价值在于把语言知识固化成了可执行的检查，团队换人之后新人不需要懂那门语言也能验证改动没有破坏什么。 ## 三条必跑的自动检查 光有词表还不够，要配三条能自动跑的断言。 第一条是唯一性，词表里不同的词必须生成不同的地址。 第二条是幂等性，同一个词跑两次必须得到完全相同的结果。 第三条是可逆性，生成的地址解码之后要能还原成预期形态。 三条任何一条不过，都说明生成逻辑里有随机或者有状态。 三条都过，剩下的问题就只是审美和策略问题了。 幂等性这一条最容易被认为是多余的，实际上它挡住了一类很难查的问题：如果生成过程依赖了当前时间、随机数、或者某个可变的全局状态，同一个词在不同时刻会生成不同地址，症状是数据库里悄悄多出一批重复内容而没人知道从哪来的。 ## 真机与真客户端上跑一遍分享 最后一步是模拟用户的实际使用，这步没法自动化。 把几个代表性地址复制出来，往各种客户端里粘一遍。 目标市场常用的即时消息、邮件、社交平台各试一次。 看链接有没有被截断，有没有被识别成两段。 再在手机上点开一次，确认跳转和显示都正常。 这一遍通常半小时能跑完，能发现自动检查发现不了的问题。 测试时要用目标市场真实在用的客户端版本，而不是自己手机上装的国际版。不同地区的客户端在链接识别上的行为可能不一样，尤其是那些本地化程度高的应用。找当地的同事或者用户帮忙点一遍是最靠谱的办法，比在自己这边反复推测有效得多。 ## 已经上线了还能不能改？ ## 先算存量的代价 存量地址的迁移成本是最先要算清楚的一项。 算的方法是把有外链或者有自然流量的地址挑出来数一数。 这批地址每一条都要配跳转，而且要长期保留。 数量不多的话，改动是可行的，几百条跳转不算负担。 数量到了几万条，跳转规则本身会变成一个维护负担。 这时候更划算的做法通常是不改，只对新增内容用新规则。 算存量代价时要注意区分两类地址：有外部链接指向的和只有内部流量的。前者必须永久保留跳转，后者可以在内部链接全部更新完之后逐步下线。两类的比例决定了跳转规则表的长期规模，这个数才是真正的成本。 算代价时别忘了把内部依赖也数进去，包括邮件模板里的链接、广告投放的落地页地址、第三方平台上填的站点链接、以及各种文档和截图。这些地方的地址不会自动更新，改地址之后要一处处去改，数量往往比想象中多，有时比跳转规则本身更费时间。 ## 新旧并存要有明确边界 决定不改存量的话，新旧并存的边界要写清楚。 最省事的边界是按目录切，某个目录下全部用新规则。 按时间切也可以，某个日期之后新建的内容用新规则。 最糟的是没有边界，同一个目录下两种风格混在一起。 混在一起的后果是没人知道该按哪套写，规范形同虚设。 边界写在生成器的配置里，比写在文档里可靠得多。 并存状态下有一件事必须做，就是在内部链接里全部指向新地址，一个旧的都不留。跳转是给外部用的，内部链接还指着旧地址会白白消耗抓取，也让报表里同时出现两套地址，分析时要额外做合并，纯属自找麻烦。 并存期间还要处理站点地图，新旧两套地址不能同时提交。只提交新地址，旧地址靠跳转承接外部流量就够了。同时提交的后果是引擎会把两套都当成有效地址去抓，白白消耗抓取额度，在小语种站上这份额度本来就不多。 ## 什么情况值得下决心改 有三种情况改动的收益明显大于成本。 第一种是当前地址里的转写选错了标准，外链大面积落空。 第二种是折叠碰撞已经造成了地址冲突，功能上有问题。 第三种是大小写处理有错，同一个词有两套地址在跑。 这三种都是功能性缺陷，不改的话问题会持续累积。 纯粹为了风格统一而改，通常不值得。 判断属不属于这三种的办法是看它有没有产生正在流失的流量或者正在增长的重复。有，就是功能缺陷该改；只是看着不顺眼，就留着。改地址的隐性成本在于它会打断你对历史数据的连续观察，这个代价在评估时经常被低估。 如果确实要改，改动的时机也有讲究，避开流量高峰和大促期间，选一个数据平稳的时段。这样迁移期的波动能跟正常波动区分开，你才判断得出改动本身有没有引入新问题。在大促前改地址是最糟糕的选择，出了问题连归因都做不到。 ## 哪些不归语言层，要交出去？ ## 地址结构本身是架构层的事 目录分几层、参数怎么处理、路径怎么组织，都不在这一篇里。 那些决策跟语言无关，换成英语站一样要做。 URL结构与slug命名的七维设计与上线后铁律 (https://zhangwenbao.com/url-structure-slug-naming-seo-design-framework-7-dimensions.html)已经把这部分讲透了。 本篇只处理一件事，就是字符该用哪一套写。 两件事的交集只在生成地址的那一个函数里。 把边界划清楚，讨论才不会互相干扰。 实操上的接口是这样：架构层给出地址的骨架，也就是有几段、每段是什么语义；语言层决定每一段里的字符怎么写。两层的输出拼起来才是完整的地址生成规则，任何一层缺失都会让规则不可执行。 两层的职责分开之后，还要约定一件事，就是谁来维护那个生成函数。放在架构那边容易忽略语言细节，放在内容那边容易改坏结构。比较稳的做法是函数由技术方维护，但语言相关的配置表由懂那门语言的人维护，两者用配置文件解耦。 ## 多语言的地区定位归另一层 一个站怎么向引擎说明哪个页面给哪个市场，是另一套机制。 那套机制跟地址里用什么字符没有关系。 本地字符的地址不会自动让引擎认为这是给本地市场的。 反过来，拉丁转写的地址也不会削弱地区定位。 把地址里的字符当地区定位信号用，是个常见误解。 地区定位有专门的标记方式，跨语言的实体对齐 (https://zhangwenbao.com/multilingual-entity-seo-cross-lingual-reconciliation.html)那一层也各有各的信号，靠地址传信号不可靠。 这个误解会导致一个具体的错误决策，就是为了地区定位而强行用本地字符地址，付了成本却没有收益。真正影响地区定位的是语言标记、地区标记和服务器所在地这几项，地址里的字符至多是一个很弱的辅助信号。 还有一个相关的误解是以为本地字符地址能提升本地搜索引擎的偏好。就已知的公开信息看，各引擎并没有把地址字符当作地区偏好的依据。真正起作用的还是那几项显式信号，与其在地址上做文章，不如把那几项配对配全。 ## 转写在页面内容里是另一个问题 本地字符和拉丁转写并存的问题，在页面内容里也存在。 但内容层的处理跟地址层完全不同，不能套用同一套结论。 内容里两种写法可以同时出现，地址只能选一种。 内容层要做的是覆盖两批用户的查询习惯。 希腊字母与拉丁转写并存时怎么覆盖 (https://zhangwenbao.com/greek-seo-greeklish-latin-transliteration-coverage.html)和用哪套字母写商品名比写了什么更决定谁能搜到 (https://zhangwenbao.com/bulgarian-serbian-seo-cyrillic-latin-dual-script.html)讲的就是内容层的做法。 本篇只管地址，两者的结论不要混用。 混用会犯一个具体的错：因为内容层要覆盖两套写法，就以为地址也要做两套。地址做两套的代价是重复内容和抓取浪费，而收益几乎为零，因为用户不会手打地址。地址只需要一套加上必要的跳转就够了。 内容层和地址层唯一需要联动的地方是站内搜索：用户可能用两种写法搜同一个东西，而站内搜索最终要把他导到唯一的那个地址上。所以内容层的同义词表要包含两种写法，而地址层保持单一形态，联动点就落在这张同义词表上。 ## 常见问题解答 ## 本地字符的网址会不会影响排名 就排名机制本身来说，两种写法没有系统性的高低差别，引擎两种都能正常抓取和索引。真正会产生影响的是间接因素，而且这些因素有正有负。正面的一侧是本地用户在搜索结果里看到自己语言的地址时点击率可能更高，尤其是地址里含有他刚才搜的那个词的时候，加粗显示会更明显。负面的一侧主要是外链，如果这门语言的转写方案有多套，或者本地字符地址在某些客户端里被截断，外链的实际获得量会低于应有水平，这一项的长期影响可能比点击率那点收益更大。所以判断该用哪种写法，正确的问法不是哪种排名好，而是在自己这个市场的具体条件下，哪种写法的外链损耗更小、点击收益更大。两个数都可以粗略估出来：外链损耗看高分歧字母在词表里的占比，点击收益看目标词在地址里出现的比例。还有一个常被忽略的细节，本地字符地址在搜索结果里的显示长度按解码后的字符数算，比编码形态短得多，所以担心地址太长而在结果页被截断这件事其实不用太在意，真正吃亏的地方还是外链和分享。 ## 已经用了本地字符地址，要不要全部换成转写 默认答案是不换，除非属于三种功能性缺陷之一。三种缺陷分别是转写标准选错导致外链大面积落空、折叠碰撞导致地址冲突、大小写处理错误导致同一个词有两套地址在跑。这三种不改的话问题会持续累积，越晚改代价越大。如果不属于这三种，只是觉得地址太长或者风格不统一，那么改动的收益很难覆盖成本。成本包括跳转规则的长期维护、历史数据连续性的中断、内部链接的全量更新，还有迁移期间不可避免的一段流量波动。一个折中做法是不动存量，只对新增内容用新规则，同时把边界写进地址生成器的配置里而不是写在文档里，这样并存状态是受控的而不是失控的。并存期间有一条必须守住，内部链接全部指向新地址一个旧的都不留，否则报表里会一直有两套地址需要人工合并。另外提醒一点，如果决定不改，就把这个决定和理由写进规范存档，否则半年后来的新人会重新提出同样的问题，团队又要把这一轮讨论完整跑一遍，而那份讨论并不会产出新的信息。 ## 怎么知道外链落在了哪一套转写上 三个地方能看到。第一个是四百零四的日志，把这批请求的地址导出来，做一次模式归类，你会看到明显聚集的几种写法，那就是外部实际使用的转写方案。第二个是站长工具里的抓取错误报告，它会列出被引用但不存在的地址，还能看到引用来源，比日志多一层信息。第三个是主动去搜自己的品牌名和主要商品名的各种转写形态，看有没有别人写的链接指向不存在的地址。三个来源合起来能覆盖绝大多数情况。发现之后的处理很直接，给每种常见变体配一条跳转指向正确地址。要注意跳转要用永久跳转而不是临时跳转，这样外链的权重才能传递过去。还有一点，做完跳转别忘了统计一下这批变体带来的流量占比，如果占比高得离谱，说明你选的那套转写跟当地习惯不一致，值得考虑把主地址换成主流的那一套。补跳转之后要在抓取报告里持续盯两三个月，看有没有新的变体形态冒出来。外部写法会随着新媒体报道和新论坛帖子而增加，变体表不是一次性交付物，它需要跟着外链的增长慢慢补全。 ## 折叠碰撞怎么系统性地检测出来 方法很机械，跑一遍就有结果。把全部要生成地址的词导出来，对每个词执行你的折叠函数，把折叠结果作为键做一次分组统计，任何一个键下面有两个以上不同的原词，就是一处碰撞。这个脚本几十行就能写完，跑一次几秒钟。检测出来的碰撞按处理方式分三类：如果两个词其实是同一个概念的不同形态，合并到一个页面；如果是两个不同的概念，给后来的那个加后缀或者对这批词保留记号走编码形态；如果其中一个是低价值的长尾词，直接不给它单独页面。这个检测要放进上新流程里定期跑，因为碰撞是随着词表增长而出现的，上线时没有不代表以后没有。特别提醒一点，检测要用完整的词表包括商品名，而不只是分类名，商品名的数量级大得多，碰撞几乎必然会出现在那里。检测脚本的输出要留档，每次跑完把碰撞对子记下来，因为同一批碰撞可能在不同的上新批次里反复出现。有历史记录的话，第二次遇到直接套用上次的处理方式，不需要重新判断该合并还是该加后缀。 ## 百分号编码的地址在报表里全是乱码怎么处理 那不是乱码，是正常的编码形态，只是不可读。处理办法是在数据进入报表之前加一道解码步骤，把地址还原成可读形态再展示。解码之后要再做一次规范化，把带记号字符的表示形式统一，否则同一个地址可能出现两行。做这一步的时候顺手把百分号后面十六进制字母的大小写也统一掉，很多工具生成小写而规范建议用大写，两种写法指向同一个地址却是不同的字符串，不统一的话去重会失效。这道处理最好做在数据管道里而不是让每个人在自己的表格里手工转，手工转的问题是每个人的转法不一样，做出来的报表口径对不上。还有一个实用建议是在报表里同时保留编码形态和解码形态两列，编码形态用来跟日志和其他系统对接，解码形态给人看，两列都有的话任何场景都不用临时转换。管道里加解码这一步还有一个附带收益，就是解码之后的地址可以直接跟内容管理系统里的标题做匹配，报表里能同时显示地址和页面标题，看数据的人不必再去后台查这个地址是哪个页面，效率提升相当明显。 ## 转写有多套标准的语言，该选哪一套当主地址 选的依据不是哪套标准更权威，而是当地人实际写的时候用哪一套。判断办法是找当地的主流媒体和大型平台，看它们在写这类词的拉丁形态时用什么方案，取占比最高的那一套。这个统计不需要多大样本，看二三十个真实例子就能看出倾向。选定之后，把其余常见方案的变体全部生成出来配好跳转，这一步不能省。有一种特殊情况需要单独考虑，就是护照和身份证件上使用的转写方案，如果你的业务涉及用户填写姓名和地址，那么表单和地址页最好跟证件方案保持一致，因为用户会照着证件抄。这时候可能出现主地址用媒体主流方案而表单提示用证件方案的情况，看起来不一致但各有各的道理，写清楚在规范里就行，别为了表面统一强行合并成一套。选定方案之后建议做一次小规模验证，拿十个用主流方案转写的词去搜一下，看有没有别的站已经在用这套写法做同类内容。如果有，说明这套方案在当地确实通行；如果一个都没有，值得回头再确认一次统计样本是不是取偏了。 ## 本地字符域名值不值得注册 先分清两件事，注册和使用是两个决策。注册通常值得，因为成本低而且能防止别人抢注造成品牌混淆，尤其是那些跟你现有域名视觉上接近的形态。使用就要谨慎得多，因为主域名一旦定下来改动代价极大。使用本地字符域名的前提有三条：品牌名本身是本地字母而不是拉丁字母、外链主要来自本地来源、品牌名里不混用两种文字系统。第三条特别容易踩，混用文字系统的域名很可能被浏览器强制显示成编码形态，那样本地字符域名最大的优势就没了，而且看起来还很可疑。稳妥的做法是主域名用拉丁字母，本地字符域名注册下来做跳转，同时在路径层面决定要不要用本地字符。这样既拿到了品牌保护，又不用承担主域名的风险。真要把本地字符域名作为主域名，上线前务必在目标市场的主流浏览器上各试一遍显示效果，不能只在一个浏览器里看。最后补一条注册层面的实用建议，除了本地字符形态，把常见的几种转写形态也一起注册下来做跳转。这批域名单价不高，但能同时挡住抢注和用户手打时的猜错，属于花小钱省大事的一类支出，值得在预算里单独留一笔。 ## 权威参考资料 ## 小语种SEO两个市场的关键词表可以一字不差，落地页却得拆成两种 - URL：https://zhangwenbao.com/minor-language-search-intent-divergence-across-markets.html - 分类：小语种SEO - 发布：2017-07-13 | 更新：2026-07-26 - 摘要：同一个关键词在两个小语种市场为什么要做两个落地页？讲清意图在词根、词形和搭配上的三处编码，以及英语那套意图分类法在屈折语和小品词语言里失效的位置。 - 关键词：关键词研究,搜索意图,多语言SEO,小语种SEO > **TLDR**：摘要：英语只能靠加词表达意图，买、价格、评测都得另起一个词。屈折语和黏着语不一样，意图有一部分直接编码在词尾上，还有一部分藏在借词和本土词的分工里。所以两个市场的关键词表可以长得一模一样，背后的诉求却分在两头。 > 摘要：英语只能靠加词表达意图，买、价格、评测都得另起一个词。屈折语和黏着语不一样，意图有一部分直接编码在词尾上，还有一部分藏在借词和本土词的分工里。所以两个市场的关键词表可以长得一模一样，背后的诉求却分在两头。 ## 同一个词在两个市场，到底哪里不一样？ ## 先分清是哪一类同词 同一个词跨市场这件事，实际上分成两种完全不同的情形。 第一种是同一门语言在两个国家，比如西班牙和墨西哥，RFC 5646的地区子标签 (https://www.rfc-editor.org/rfc/rfc5646)就是为区分这种情形准备的。 第二种是两门不同语言里恰好有一个拼写相同的词。 两种情形的成因不同，处理办法也完全不同。 第一种是同一个词在两地的语义漂移和阶段错位。 第二种是词源巧合，意思可能完全无关，属于假朋友。 把这两类混在一起处理是最常见的起手错误，因为它们在关键词表里长得一样，都是一行词加一个搜索量。区分办法很简单，问一句这两个市场说的是不是同一门语言：是，走语义漂移那条路；不是，先去撞假朋友清单，撞上了就别再往下分析意图了。 这个判断还有第三种情形容易被忽略，就是同一门语言在两个市场里各自借入了同一个外语词，但借入的时间和途径不同，语义落点也不同。这种情形表面上像语义漂移，实际成因跟假朋友更接近，处理时要按假朋友那条路走。 ## 意图差异不等于搜索量差异 报表上最容易看到的差异是搜索量，那个不重要。 搜索量差异只说明市场大小不同，做法可以一样。 真正要盯的是同一个词背后的诉求分布有没有变。 诉求分布变了，落地页的结构就得跟着变，模板都不一样。 这一层从关键词工具的报表里完全看不出来。 工具给的是量，不是意图，意图要自己去搜索结果里读。 判断诉求分布有没有变，最快的办法是拿同一个词在两个市场各跑一次搜索，把首屏结果按页型分类：商品页、分类页、百科页、论坛帖、新闻。两边的页型比例差出两成以上，就说明诉求分布确实变了，这个动作十分钟能做完，比等三个月看数据快得多。 页型统计要注意用目标市场的地区参数去查，否则拿到的是自己所在地的结果，页型比例完全不作数。这一步没设对是最常见的错误，而且错了之后得出的结论看起来完全合理，很难被发现，所以值得在流程文档里单独写一行提醒。 ## 跟通用的意图诊断不是一层 站内已经写过看SERP之后落地页要改成什么样 (https://zhangwenbao.com/search-intent-mismatch-diagnose-from-serp.html)那一套流程。 那一篇讲的是通用方法，跟语种没有关系。 本篇只处理一件事，就是语言这个变量本身带来的意图偏移。 换句话说，把语种换成英语之后还成立的部分，不在这里讲。 这条边界很重要，不划清楚会把两篇写成一篇。 通用方法是骨架，语言变量是骨架上多出来的那几根刺。 具体的分工是这样：通用方法回答的是这个词该配什么页型，语言变量回答的是为什么同一个词在这两个市场配了不同的页型。前者靠读搜索结果得出，后者要靠拆词才能得出，两个动作的输入不同，不能互相替代。 实操上这两层要分两个人做也可以，但顺序不能倒：先做通用诊断把页型定下来，再做语言变量分析看两个市场要不要分开。倒过来做的话，你会为一个还没确定页型的页面去分析语言差异，得出的结论没有落点。 ## 意图在语言里编码在哪几个位置？ ## 第一个位置：词根的选择 很多小语种里，同一个概念同时存在借词和本土词。 用户挑哪一个，本身就透露了他处在什么阶段。 借词通常更口语、更贴近日常，交易类查询里占比更高。 本土词或者官方词更书面，信息类查询里占比更高，德语词典里Rechner的用例 (https://www.dwds.de/wb/Rechner)能看出这种语域差。 这个规律不是绝对的，在官方为网店专门指定本土说法 (https://bolje.hr/rijec/online-trgovina-gt-mrezna-trgovina/95/)这种纯洁主义强的市场会反转。 所以要先测一遍，不能直接套别的市场的经验。 测的办法是把这一对词各跑一次搜索，看首屏里商品页和百科页的比例。借词那边商品页多、本土词那边百科页多，说明规律成立；两边都是商品页，说明这一对已经在当地合流了，可以当同义词处理，不必分开做。 借词和本土词的分工还会随时间迁移，教材和媒体在推哪一个，年轻用户的用词就会慢慢往那边靠。所以这一对词的比例每年要重新看一次，不能定一次用五年。看的方法就是重跑一次首屏页型统计，十分钟的事。 ## 第二个位置：词的形态 这是英语用户完全体会不到的一层，也是最容易漏的一层。 在有格变化的语言里，名词的词尾会随句子里的角色变。 用户打出的那个形态，携带了他想做什么的信息。 宾格形态往往出现在带动作的查询里，偏交易。 原形或者主格形态更多出现在纯粹查资料的查询里。 英语没有这套机制，只能靠在词前后加修饰词表达。 这一层的实操价值在于它免费给了你一个意图信号：不需要用户额外打字，词尾自己就说明了问题。代价是关键词工具通常会把所有形态合并统计，这个信号在报表里被抹平了，只有从站内搜索日志或者搜索词报告的原始串里才能看到。 这一层还能反过来用在写作上：知道哪个形态偏交易之后，页面标题就用那个形态，正文里再自然带上其他形态。这样标题接住的是意图最明确的那批查询，而正文覆盖了形态变体，两件事在同一个页面里完成。 ## 第三个位置：搭配与词序 第三层在词与词之间，不在单个词里面。 同样两个词，摆放顺序不同，意图可能完全不同。 有些语言词序自由，靠形态标记角色，顺序不承载意图。 有些语言词序固定，顺序本身就是意图的一部分。 做长尾词组合时，这决定了要不要穷举所有排列。 词序自由的语言要穷举，词序固定的语言穷举纯属浪费。 判断自己面对的是哪一类，看这门语言有没有丰富的格系统。格系统丰富的，词序通常自由，因为角色靠词尾标记；格系统贫乏的，词序承担了标记角色的功能，就相对固定。这条判据一句话就能用，比查语法书快得多。 词序自由的语言还有一个附带麻烦，就是同一个意思的多种排列会被工具算成不同的关键词，搜索量被摊薄。看报表时要先把同义排列合并再排序，不然会误判某个组合的量太小不值得做，而它的真实总量其实相当可观。 ## 英语那套意图分类法在哪些地方失效？ ## 靠疑问词筛信息型查询会漏掉一大半 英语里筛信息型查询的标准做法是找疑问词开头的串。 怎么做、是什么、为什么，这几个前缀一抓一大把。 问题是有些语言的疑问句根本不用疑问词。 它们用一个小品词，或者在动词上加一个后缀。 这个小品词可能就一两个字母，还常常粘在别的词上。 拿英语那套前缀去筛，这批查询会被整块归进导航型或者其他。 受影响的语言比想象中多：土耳其语一个词后面能挂五层后缀 (https://zhangwenbao.com/turkish-seo-agglutinative-suffix-stacking-keyword.html)，它用一个独立的疑问小品词，芬兰语的词干自己也会变 (https://zhangwenbao.com/finnish-seo-fifteen-cases-consonant-gradation-keyword.html)，疑问是在词上加后缀，波兰语有一个句首的疑问助词但口语里经常省略。做这三门语言的意图分类时，必须先补一条按小品词和后缀识别的规则，否则信息型查询的统计会系统性偏低。 补规则的时候要小心误伤，疑问小品词往往就一两个字母，跟普通词的词尾长得一样，简单匹配会把大量陈述句也算成问句。稳妥做法是要求小品词出现在特定位置，或者跟已知的动词形态组合出现，宁可少收一些也别把整个分类污染掉。 ## 交易意图词不一定是独立的词 英语里表示购买意图的词是独立的动词，好抓。 在黏着语里，这个意思可能是动词后面的一个后缀。 后缀跟词根粘成一个词，正则规则抓不到。 要抓它得先做形态切分，把后缀从词里剥出来。 形态切分工具在小语种上的质量参差不齐。 质量不够的话，退而求其次用词尾模式匹配也能凑合。 做过一个母婴洗护客户的土耳其语站，团队按英语经验建的意图规则表里交易词只有几个独立动词，跑完发现能归类的查询不到四成。补上按词尾识别的规则之后，覆盖率一下子到了八成，剩下那两成才是真正的杂项。 词尾模式匹配的规则表建好之后要做一次抽样人工核对，随机抽一百条被归为交易意图的查询，看看有多少确实是交易意图。准确率低于八成就得收紧规则，因为这批词后面要用来决定页面结构，误判会直接导致页型选错。 ## 比较型查询的写法完全不同 英语的比较型查询有个极稳定的写法，两个名词中间夹一个词。 这个模式好抓，工具和规则都能直接命中。 很多语言没有这个固定写法，用的是连词或者介词短语。 更麻烦的是有些语言用形容词的比较级形态来表达。 比较级形态是词形变化，不是加词，规则抓不到。 结果是比较型查询在这些市场的统计量被严重低估。 补这一类要先列出这门语言表达比较的全部手段：夹在中间的连词、比较级词尾、表示对比的介词短语、还有单纯把两个品牌名并排打进去这种最简形式。四种手段都写进规则，比较型查询的量通常会翻一到两倍，比较型词的决策意图与常见坑 (https://zhangwenbao.com/comparative-keyword-vs-strategy-decision-stage-intent.html)那一篇里的策略才用得上。 还有一种最容易漏的比较型写法，就是用户只打两个品牌名或者两个型号，中间什么连接词都不加。这种串在规则里几乎不可能被识别成比较意图，只能靠识别出串里含两个已知实体来判断，需要一份品牌与型号的实体表配合。 ## 本地化修饰词跟英语不是一套 英语里表示便宜、最好、正品的修饰词很集中。 换个市场，同一个诉求可能用完全不同的一批词表达。 有些市场用直接的形容词，有些市场习惯用价格区间数字。 有些市场用的是本地特有的商业概念，翻译过来完全不通。 照着英语修饰词表翻译一遍，得到的是一份没人搜的表。 正确做法是从当地的真实查询串里归纳，不是从英语翻译。 归纳的原料有三个来源：站内搜索日志、搜索词报告的原始串、当地大型平台的搜索框补全。三者交叉之后按频次排序，取前面两百个修饰词做人工归类，这份表才是当地的，跟英语那份重合度通常不到三成。这个动作在长尾关键词的十种挖词渠道与意图分类 (https://zhangwenbao.com/seo-long-tail-keywords-expansion-methods-and-ideas.html)里有更细的流程。 归纳出来的修饰词表还要标注它出现的位置，前置还是后置。有些语言的修饰词习惯放在名词后面，如果按英语习惯把它拼在前面生成长尾词，得到的串在当地读起来不自然，搜索量自然接近零，而这类错误在词表里完全看不出来。 ## 同一门语言在两个市场，意图会怎么漂移？ ## 同一个词指的东西不一样 最直接的漂移是词义本身在两地分了叉。 同一个词在一个市场指某类商品，在另一个市场指另一类。 这种情况在西班牙人和墨西哥人搜的不是一个词 (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/croatian-slovenian-seo-two-small-markets-decision.html)讲的就是这件事。 撞清单这一步要放在流程最前面，因为它的成本最低而收益最大。一份几百条的假朋友清单跑一遍全量词表只要几秒钟，能挡掉后面所有基于错误前提的分析。跳过这一步，你会花几周时间去解释一个根本不存在的意图差异。 清单不必从零建，先从数量词、时间词、家居词、身体部位词这四类入手，近亲语言之间的假朋友高度集中在这四类里。四类覆盖完再往外扩，投入产出比比按字母顺序逐条比对高得多。 ## 真同源词的意图错位 排除假朋友之后，还剩一批真正的同源词。 它们词源相同、意思接近，但语域和常用度不一样。 在一门语言里是日常词，在另一门里是书面词。 日常词接的是宽泛的大众查询，书面词接的是专业查询。 用同一套落地页接，语气和深度必然有一边不合适。 判断语域差异要靠母语者，词典的标注往往滞后。 有个不用找人的替代办法：看这个词在当地新闻媒体和论坛里的出现频次比。媒体高论坛低说明它偏书面，论坛高媒体低说明它偏口语，两边都高说明它是通用词。这个比值用站外搜索的站点限定查询就能粗略估出来，虽然不精确但足够分档。 语域差异还有一个实际后果，就是它决定了页面该用什么语气。承接口语词的页面用书面语气写，用户会觉得距离感强；承接书面词的页面用口语语气写，会显得不够专业。语气这件事没法量化，但它对停留时间的影响相当明显。 ## 数字与单位带来的意图差异 还有一类同词现象出在数字和单位上。 同一个规格数字，在两个市场对应的商品档次不同。 比如同一个尺寸在一个市场是主流款，另一个市场是小众款。 用户打这个数字进来，期待看到的商品列表完全不同。 这不是语言问题，但它会伪装成语言问题出现在词表里。 处理办法是按市场分别做规格分档，数量分档的口径可以参照LDML对数量类别的定义 (https://www.unicode.org/reports/tr35/tr35-numbers.html)，别两个市场共用一套。 单位本身也会制造这类问题，同一个品类在两个市场习惯用的计量单位不同，用户打进来的数字就不在同一个量纲上。这类查询如果不做单位换算就直接匹配，会返回完全不相干的结果，而且因为数字看着合理，很难在测试时被发现。 规格分档还要考虑本地主流商品的分布，档位边界应该落在商品密度低的地方而不是整数上。按整数切档看起来整齐，但很可能把同一类主流商品切到两个档里去，用户在任何一个档里都看不到完整的选择。 ## 怎么从原始查询串里把意图拆出来？ ## 先拿到没被合并过的原始串 所有分析的前提是拿到用户实际打进去的那一串字符。 关键词工具给的是归一化之后的结果，形态被合并了。 形态一合并，前面说的第二层信号就全没了。 能拿到原始串的地方有三个，都不经过第三方归一化。 站内搜索日志、搜索词报告的原始串、以及站长工具的查询。 三个来源各有偏差，但都保留了用户打字的真实形态。 三个来源的偏差方向不同，正好可以互补：站内搜索日志只包含已经进站的用户，偏向下游；搜索词报告只包含点了广告的，偏向高商业价值；站长工具的查询覆盖面最广但只有获得过展现的。三份数据交叉之后，覆盖面才算完整。 拿到原始串之后先别急着分析，做一次基础清洗：去掉明显的爬虫串、去掉自己团队测试留下的串、去掉带内部关键词的串。这三类在小语种站里占比可能相当高，因为总量本来就小，一点噪声就能把分布带偏。 ## 按形态而不是按词根归类 拿到原始串之后，第一个动作不是去重，是按形态归类。 把同一个词根的所有形态列出来，各自统计频次。 这张形态频次表是整个分析里最有价值的一张。 它告诉你用户偏好哪个形态，也就间接告诉你意图分布。 如果某个形态的占比明显高于预期，那里通常有故事。 去重要在归类之后做，反过来就把信号洗掉了。 做这张表不需要形态分析工具，按词尾聚类就够用：把词尾相同的串归成一组，人工看一眼组名对不对。切分边界本身的判定可以参照UAX #29的词边界规则 (https://www.unicode.org/reports/tr29/)，屈折语的词尾数量有限，一门语言几十个词尾覆盖绝大多数情况，一次归类完成之后可以长期复用，后面只要往里补新词尾。 后缀表的起点可以直接抄Snowball按语言给出的后缀剥离规则 (https://snowballstem.org/algorithms/)，排的时候要按最长后缀优先，否则短后缀会先命中把长后缀的情况吃掉。这个细节写错的话表面上程序跑得通，结果却是一堆形态被错误归并，而错误的方向很一致，看结果时会误以为某个形态特别高频。 ## 用页型比例反推意图 形态归类给出的是假设，还需要验证。 验证办法是把每一组形态各跑一次搜索，看首屏页型。 商品页占多数的，是交易意图；百科和长文多的，是信息意图。 论坛和问答多的，通常是解决问题类的意图。 把页型比例填进形态频次表，一张意图地图就成型了。 这张图才是拆落地页的依据，比任何工具的意图标签都准。 页型统计不必人工数，把首屏结果的地址抓下来按域名分类就行，几十个词跑完不到一小时。要注意抓的时候要用目标市场的地区参数，不然拿到的是本地结果，页型比例完全不对，这个坑踩过的人不少。 页型分类的粒度不用太细，商品页、分类页、长文、问答、平台页五类就够。分得太细的问题是同一个页面很难归到唯一一类，标注一致率会掉下来，而这个统计要的是趋势不是精度，五类足够看出趋势。 ## 把结论固化成一张表 分析做完，要把结论落成一张能交给别人用的表。 表的列是词根、形态、频次、页型比例、判定意图、目标页型。 每一行都能直接变成一个工单，不需要再解释。 这张表要按市场分别存，不能两个市场共用一份。 共用一份是这类项目里最常见的偷懒方式，代价很大。 表要定期重跑，意图会随市场成熟度慢慢漂移。 重跑的频率按市场阶段定：起步市场半年一次，因为它变得快；成熟市场一年一次就够。判断要不要提前重跑有个信号，如果某一批词的转化率在没做任何改动的情况下持续变化，多半是意图漂了，这时候不该去调页面，该先去重跑这张表。 表里要留一列写判定依据，注明这一行的意图是根据什么判出来的。半年后回看时，有依据的行可以直接复核，没依据的行只能重做。这一列写起来多花不了几分钟，省下的是下一次重跑时的全部返工。 ## 意图信号还能从哪些非查询数据里读出来？ ## 筛选器的点击顺序会说话 查询串不是唯一的意图来源，站内行为也是。 用户进到分类页之后先点哪个筛选器，那就是他最关心的维度。 在小语种市场里这个信号尤其宝贵，因为查询数据太薄。 筛选器的点击顺序在不同市场往往差别明显。 一个市场先点价格，另一个市场先点品牌，诉求就不同。 把这个顺序统计出来，页面上筛选器的排列也该跟着调。 这份数据的另一个用处是补关键词表：用户高频点击的那个筛选维度，对应的修饰词在当地就是高价值修饰词，即使查询数据里量看着不大也值得单独做落地页，因为点击行为证明了这个维度是决策的关键。 ## 零结果的搜索串是需求缺口 站内搜索里返回零结果的那批串，价值被严重低估。 它们代表用户想要但你没提供的东西，是最直接的需求信号。 在小语种站上，零结果串里有很大一部分不是没货。 而是用户用了另一个词，而你的搜索没做同义词映射。 这批串正好就是前面说的形态变体和借词本土词分工。 把它们做成同义词表，站内搜索和关键词表能一起受益。 处理零结果串有个固定顺序：先看是不是形态问题，再看是不是借词与本土词的分叉，最后才考虑是不是真的没有这个商品。前两类占比通常在六七成，都是改配置就能解决的，第三类才需要采购介入，顺序反了会把简单问题当难题上报。 ## 客服问题的分布补上了盲区 还有一个来源是客服记录，特别是售前咨询。 用户来问的问题，说明页面上没把这件事讲清楚。 把咨询问题按主题归类，看哪一类占比最高。 占比高的那一类，往往就是这个市场特有的关注点。 这个关注点在另一个市场可能根本不存在。 它是最便宜的市场差异探测器，成本几乎为零。 客服记录还能给出一个查询数据给不出的东西，就是用户的原话措辞。这些措辞比归一化过的关键词更贴近真实语言习惯，直接拿来当页面文案的用词，比自己想或者从英语翻译过来都更自然，也更容易命中长尾查询。 ## 落地页要拆到什么颗粒度？ ## 能合并的先合并 拆页之前先想清楚哪些可以不拆。 形态不同但意图一致的，全部合并到一个页面。 合并的方式是把各个形态作为同义词接进同一个页面。 页面标题用最高频的那个形态，其余形态在正文里自然出现。 这样既覆盖了全部形态，又不产生一堆薄页面。 能合并的比例通常在七成以上，真要拆的只是少数。 判断能不能合并的标准只有一条：这两批查询的用户，看到同一个页面会不会都满意。会，就合并；有一边明显不满意，才拆。别用形态是否相同、搜索量是否接近这类间接标准，那些跟用户满不满意没有必然关系。 合并之后要验证一件事，就是被合并进来的那些形态还能不能被搜到。做法是拿每个形态在站内搜一遍，再用站外的站点限定查询看这个形态能不能命中这个页面。有形态命中不到，说明它在页面上出现的位置不够显著，要往标题或者小标题里挪。 ## 真要拆的是哪几种情况 第一种是意图确实落在漏斗两端，一个查资料一个要下单。 第二种是同一个词在两地指的东西不一样，商品集不同。 第三种是修饰词带来的诉求足够独立，比如价格区间。 第四种是页型完全不同，一个要商品列表一个要长文。 四种情况之外的差异，大多可以在同一个页面里消化。 拆多了的代价是内容稀释和互相竞争，比不拆更难修。 四种情况里第一种最值得拆，因为漏斗两端对页面的要求是矛盾的：查资料的人要长文和对比，要下单的人要价格和加购按钮。一个页面同时满足两边，结果通常是两边都做得不上不下，这时候拆开的收益最明显。 还有一种边界情况值得单独判断，就是同一个词在两个市场里承接的品类范围宽窄不同。一边指一个大类一边指其中一个小类，这时候拆不拆取决于大类那边的商品数量，数量够就拆成大类页和小类页，不够就只做小类页。 ## 两个市场的页面结构要不要一致 拆完之后会遇到一个新问题，两边的页面数量对不上。 一个市场拆成了五个页，另一个市场只需要三个。 这时候不要为了对称硬造两个页出来。 页面结构本来就该由当地的意图分布决定，不该对称。 硬对称的结果是两个凑数的薄页面，拖累整站质量。 不对称会让后台管理麻烦一点，但那是管理问题不是策略问题。 管理上的麻烦可以用一个办法缓解：给每个页面打上意图标签而不是靠位置对应，这样两个市场的页面就算数量不同也能按标签对齐，做报表和做内链时都能找到对方。位置对应是很多多语言站的默认假设，一旦意图分布不同就会处处别扭。 不对称还会带来一个内链上的问题，某个市场有的页面在另一个市场不存在，跨语言的对应链接就断了一半。处理办法是让这类页面的跨语言链接指向对方市场语义最接近的那一个页面，而不是留空，留空会让整个跨语言链接网看起来残缺。 ## 哪些不属于语言层，要交出去？ ## 引擎的意图判定归引擎那一层 不同搜索引擎对同一个查询的意图判定不完全一样。 这属于引擎的排序机制，跟语言本身没有关系。 各个引擎自己的打法在出海俄语区绕不开的那套搜索生态 (https://zhangwenbao.com/yandex-seo-russia-cis-complete-guide.html)这类内容里讲，这里不重复。 本篇只关心语言给了你什么额外的意图信号。 引擎怎么用这些信号，是引擎那边的事。 划清这条线能省下大量重复讨论。 需要注意的是这条线在实操里会被反复模糊，因为引擎的结果是你读意图的主要材料。正确的态度是把搜索结果当成观察窗口而不是分析对象：你透过它看用户想要什么，而不是研究引擎为什么这样排，后者是另一个课题。 有一个例外情况需要跨过这条线，就是某个引擎在某门语言上的分词或者形态处理明显不同于其他引擎。这时候语言层和引擎层耦合在一起了，必须一起看，但这种情况的数量很少，遇到时单独记录就行，不用改整套方法。 ## 地区定位与架构归架构层 两个市场的内容怎么放，用什么域名和路径，属于架构层。 URL结构与slug优化的那些细节 (https://zhangwenbao.com/url-structure-slug-optimization-onpage-seo-mechanism.html)跟意图分析是并行的，互不干扰。 意图分析告诉你要做几个页面，架构决定它们放在哪。 顺序上先做意图分析，再做架构决策，反过来容易被架构绑住。 常见的错误是先定好了目录结构，再往里塞页面。 结果是意图分布跟目录结构对不上，硬塞出一堆四不像。 正确的顺序还有一个附带好处：意图分析产出的页面清单，本身就是架构决策的输入。你知道要做多少个页、分几类，才能判断目录该怎么分层。倒过来做的话，架构是拍脑袋定的，后面每加一个页都要跟结构打架。 意图分析产出的页面清单交给架构之前，最好先按意图类型分组并给每组估一个页面数量级。架构决策需要的不是精确页数而是量级，知道某一类是十个还是一百个，目录该分几层的答案就出来了。 ## 翻译质量本身是另一件事 最后要交出去的是翻译质量这一块。 翻译准不准是本地化的问题，不是意图分析的问题。 翻译再准，如果意图判断错了，页面照样不解决问题。 反过来意图对了，翻译粗糙一点也能拿到基础流量。 两件事的优先级不一样，意图在前，质量在后。 这个顺序在预算紧张时特别有用，能决定钱先花在哪。 不过这个优先级有个下限，翻译质量低到影响可读性的时候，意图对不对就没意义了。实操上的分界线是：能读懂、术语一致、没有明显错译，达到这个水平之后再加钱提升翻译质量的边际收益，就明显低于花同样的钱做意图分析。 两件事真正会打架的地方在标题上。翻译得最准的标题不一定是用户实际打的那个形态，而承接搜索的标题必须用高频形态。遇到冲突时优先用高频形态，把准确的说法放进正文首段，这个取舍在小语种上出现的频率相当高。 ## 这套方法怎么落地到日常流程里？ ## 新市场开工时的顺序 进入一个新的小语种市场，动作有固定顺序。 第一步是拿到原始查询串，没有它后面全是猜。 第二步撞假朋友清单，把不是同一个词的先剔出去。 第三步做形态归类，产出形态频次表。 第四步跑页型验证，把意图填进表里。 第五步才是拆页面和写内容，前四步都是准备。 前四步加起来通常在两周以内，相对于一个市场半年的内容投入不算什么，但它决定了那半年的内容有没有落在对的页型上。跳过前四步直接写内容，是这类项目里最贵的一种快，返工时连哪些内容该留都判断不了。 前四步里最容易被压缩的是第一步，理由通常是数据要等。正确的做法是把拿数据这件事提前到决定进入这个市场的那一刻就启动，跟其他准备工作并行，这样等到要做分析时数据已经攒了一两个月，不必再等。 ## 已有市场怎么补做 如果市场已经在跑，补做的切入点是转化率异常的页面。 把转化率明显低于同类的页面挑出来，先看它们接的是什么词。 再把这些词按形态归类，跑一遍页型验证。 大概率会发现其中一部分页面接的词意图跟页型对不上。 这批页面就是补做的优先级最高的部分。 改完之后的效果通常在一个月内就能看到。 补做还有个更省事的入口，就是看跳出率高但停留时间也不短的页面。这个组合往往意味着用户读了内容但没找到想要的东西，正是意图错配的典型症状。单看跳出率会把加载慢、版式差的页面也混进来，加上停留时间这个条件之后精确度高很多。 补做时还有一批页面值得优先看，就是有展现但点击率明显偏低的。这类页面通常不是意图错配而是标题里的形态不对，用户在结果列表里没认出这是自己要找的东西。改标题的成本远低于改整个页面，收益却能立刻看到。 ## 要定期回看的三个数 这套分析不是一次性的，要有三个数放在监控里。 第一个是各形态的频次占比，它变了说明用户习惯在变。 第二个是各词的页型比例，它变了说明市场阶段在变。 第三个是两个市场同一批词的意图判定一致率。 第三个数最有意思，它反映两个市场是在趋同还是在分化。 趋同的话可以逐步合并内容，分化的话要继续加投入。 三个数的采集频率可以不同，第一个季度看一次，后两个半年看一次。别把它们塞进日常报表里，那样只会被忽略；正确做法是做成定期的专项复盘，每次半天，看完直接产出下一季度的调整清单。日常报表管的是有没有问题，这三个数管的是方向对不对。 三个数之外还可以留一个定性观察，就是每次复盘时随机读二十条原始查询串。数字告诉你分布变了，读串告诉你为什么变。这个动作看着不严谨，但很多方向性的变化最先是在原始串的措辞里露出来的，报表要滞后一两个月才反映出来。 ## 常见问题解答 ## 没有站内搜索日志，怎么拿到原始查询串 站内搜索日志是最理想的来源，但确实不是每个站都有。没有的话有三个替代路径。第一个是搜索词报告，广告后台里能看到用户实际打的串，这份数据的问题是只覆盖点过广告的用户，商业意图偏高，但对分析交易类查询完全够用，而且它保留完整形态。第二个是站长工具里的查询数据，覆盖面最广，缺点是有采样和截断，长尾部分看不全，不过对做形态频次表来说主流形态能覆盖到就够了。第三个是搜索建议，在搜索框里逐个输入词根前几个字母，把补全出来的串全部记下来，这个办法最笨但对小语种特别有效，因为补全直接反映真实查询且完整保留形态。三个来源建议同时用，交叉之后能互相补上各自的盲区。另外先把站内搜索功能装上，几行代码的事，三个月之后你就有了一份别人都没有的数据。最后提醒一句，无论用哪个来源，都要确认它给的是原始串而不是归一化之后的结果，这一点直接决定了形态信号还在不在。 ## 形态归类需要形态分析工具吗，没有工具能做吗 能做，而且大多数情况下不需要工具。屈折语的词尾数量是有限的，一门语言常用的词尾通常在几十个量级，把它们列出来做后缀匹配就能覆盖绝大部分情况。具体做法是先按最长后缀优先的顺序排一张后缀表，逐个去匹配查询串，剥掉后缀之后剩下的部分当作词根聚类。这个办法的准确率在八成以上，对做频次分布完全够用，而剩下那两成通常是词干本身也会变化的情况，那批词单独挑出来人工看一眼就行。真正需要专业形态分析工具的场景只有两个，一是要做自动化的大规模处理，二是这门语言的词干变化特别复杂，比如词根内部的元音也会变。先用后缀表跑通流程拿到结论，再决定要不要上工具，顺序反过来的话很容易在选工具上耗掉几周还没产出任何结论。还有一个判断要不要上工具的信号：如果后缀表已经改到上百条还在往里加例外，说明这门语言的形态复杂度超过了后缀匹配的能力上限，该换工具了。 ## 怎么判断两个市场的意图差异值不值得单独投入 用一个简单的估算就够了。先算出意图不一致的那批词占总搜索量的比例，再乘以这批词的预估转化价值，得到的就是这个差异每年值多少钱。跟做一套独立内容的成本一比，答案通常很清楚。经验上意图不一致的词占比低于一成的话，不值得单独做，在现有页面里加一段内容消化掉就行；占到三成以上基本必须单独做，因为这部分流量在现有页面上的转化会一直上不去。中间那一段要看品类的客单价，客单价高的门槛低，客单价低的门槛高。还有一个非财务的考量，如果意图不一致的那批词正好是行业里竞争最激烈的头部词，那就算比例不高也值得单独做，因为在头部词上做对意图是拉开差距的少数机会之一。反过来如果不一致的都是长尾杂词，可以放心先放着。算这笔账时记得把返工成本也算进去，如果现在不拆，将来发现必须拆时已经积累的内容和外链都要迁移，那部分成本通常比一开始就拆高一倍以上。 ## 意图分析的结论多久会过时 取决于市场成熟度和品类变化速度，通常起步市场半年、成熟市场一年重跑一次。但比固定周期更可靠的是设几个触发条件。第一个触发条件是某批词的转化率在没做任何页面改动的情况下持续三个月往下走，这往往意味着意图漂了。第二个是搜索结果的页型构成明显变化，比如原来首屏全是商品页现在冒出来一堆长文，说明引擎对这个词的意图判定变了，你的页面也得跟着调整。第三个是品类本身出现了新的产品形态或者新的购买方式，用户的问法会跟着变。三个条件任何一个触发就重跑，不用等到周期。还有一点要提醒，重跑的时候要保留上一次的结论做对比，不要直接覆盖。两次结论之间的差值才是最有信息量的部分，它告诉你市场往哪个方向走，而这个方向判断比某一次的静态结论价值更大。另外别忘了在重跑之前先把上一次的页面改动清单调出来看一遍，有些变化是你自己的改动引起的，误判成市场漂移会让你朝着错误的方向再改一次。 ## 近亲语言的两个市场，意图分析能不能共用一份 不能共用，但可以共用流程和工具，不能共用结论。原因在前面讲过，越是近亲的语言假朋友密度越高，共用结论等于把假朋友当成同一个词来分析，得出的结论从根上就是错的。正确做法是两个市场各跑一遍完整流程，然后把两份结论并排比对，比对本身会产出很有价值的第三份材料，就是那张一致率表。一致率高的部分说明这两个市场在这些词上确实可以共用内容，一致率低的部分就是必须分开做的清单，这份清单比拍脑袋决定分不分开做要可靠得多。至于近亲语言的两个市场整体要不要分两套内容，那是另一个层面的决策，判据包括互通度、非语言字段差异、复用比例等等，意图一致率只是其中一个输入。把这个输入单独拿出来当唯一判据也不对，它只反映查询层面，不反映内容制作层面的成本。共用流程的时候要注意后缀表和修饰词表也得各存一份，这两张表看起来通用，实际上是各自语言的资产，混用会让归类结果互相污染。 ## 小语种没有足够的查询数据，样本太小怎么办 样本小的时候，放弃精确统计，改用结构化的定性判断。具体有三个办法。第一个是把分析单位从单个词提升到词类，不去问某个词的意图分布，而是问这一类词的意图分布，样本量立刻上去了。第二个是借用邻近市场的结构做先验，找一个语言接近、市场结构接近但数据量更大的市场，先假设意图结构类似，再用小样本去验证这个假设成不成立，验证需要的样本量比从零建结论小得多。第三个是直接做用户访谈，小市场的好处是找几个真实用户不难，问他们搜什么、为什么这么搜，十个人的访谈能顶几万条数据的信息量。三个办法可以叠加用。要避免的错误做法是拿大市场的绝对数字按人口比例缩放到小市场，那个数只能用来估量级，不能用来判意图，意图跟市场大小没有比例关系。三个办法用完之后，把得出的结论标上置信度写进表里，低置信度的行别拿去做重投入的决策，等数据攒够了再复核，这比装作有把握要安全。 ## 意图分类的标签体系该用几档 建议从四档起步，交易、比价、信息、导航，先跑通流程再考虑细分。很多团队一上来就设计十几个标签，结果是标注一致率极低，两个人标同一批词能标出两套结果，后面所有分析都建在这堆噪声上。四档的好处是边界清楚，谁来标结果都差不多。跑通之后如果发现某一档里的词明显还能再分，再往下拆，通常最先需要拆的是信息这一档，因为它里面混了搞清楚是什么和搞清楚怎么用两类差别很大的诉求。拆标签的时机判断很简单，某一档下面的落地页开始出现两种明显不同的形态时，就说明该拆了。还有个跟小语种特别相关的提醒，标签体系要按语言各存一份而不是共用一份，因为不同语言能表达的意图区分度不一样，有些语言天然能分出更细的档，有些分不了，强行统一会丢信息。标签体系定下来之后要配一份标注指南，每个标签给两三个正例和一个反例，新人照着标就能和老人保持一致，这份指南比标签本身更决定数据质量。 ## 权威参考资料 ## 克罗地亚语和斯洛文尼亚语SEO挨着做，两门语言的距离比捷克语到斯洛伐克语远出一大截 - URL：https://zhangwenbao.com/croatian-slovenian-seo-two-small-markets-decision.html - 分类：小语种SEO - 发布：2017-04-05 | 更新：2026-07-26 - 摘要：克罗地亚语和斯洛文尼亚语要不要分两套做？讲清真实互通度怎么量、字母表与排序差在哪、斯洛文尼亚语双数带来的工程改造，以及三档复用判据怎么划。 - 关键词：关键词研究,多语言SEO,内容本地化,小语种SEO > **TLDR**：摘要：克罗地亚语和斯洛文尼亚语在地图上挨着，语族标签也都写着南斯拉夫语，可两边的字母表长度不一样，假朋友的密度高得离谱，斯洛文尼亚语还多出一整套双数形态。真实互通度比捷克语到斯洛伐克语低一大截，能整块搬过去的只剩商品图和技术参数表。 > 摘要：克罗地亚语和斯洛文尼亚语在地图上挨着，语族标签也都写着南斯拉夫语，可两边的字母表长度不一样，假朋友的密度高得离谱，斯洛文尼亚语还多出一整套双数形态。真实互通度比捷克语到斯洛伐克语低一大截，能整块搬过去的只剩商品图和技术参数表。 ## 这两门语言到底有多近？ ## 拿捷克语和斯洛伐克语当标尺量一次 做欧洲小市场，第一步不是查人口，是量语言距离。 距离这个东西没法凭感觉，得找一把已知刻度的尺子。 站内写过的捷克语和斯洛伐克语分家之后关键词再没合并回同一套 (https://zhangwenbao.com/czech-slovak-seo-content-reuse-decision.html)就是现成的那把尺子。 那一对在1993年分家之前共用过一套书面语，互通度极高。 把这一对的距离记成一格，再去量克罗地亚语到斯洛文尼亚语。 量完的结果通常会让人愣一下，差不多是三到四格。 量距离的具体办法是拿同一份商品文案交叉盲测：找母语者读另一边的版本，标出看不懂和意思拿不准的句子，算出比例。捷克语读斯洛伐克语文案的看不懂率通常在个位数，克罗地亚语读斯洛文尼亚语文案能到三成往上，这个数字比任何语族分类都可靠。 盲测的样本量不用大，每边二十段商品文案、六个母语者就够出结论了，成本不到一周。真正要控制的是样本的代表性，标题、规格、促销、售后各挑五段，别全用商品描述，不同文本类型的看不懂率能差出一倍。 ## 语族标签不等于互通度 两门语言都归在南斯拉夫语支下面，这是事实。 问题在于语支内部还分西支和东支，两边不在同一支。 克罗地亚语属于中南部那一片连续体，跟塞尔维亚语更近。 斯洛文尼亚语自己单独一支，跟隔壁的距离比想象中远。 翻语言学教材看谱系图，两边确实挨着挂在同一根枝上。 但谱系图画的是历史来源，不是今天两边能不能听懂对方。 拿谱系图当市场判据，跟拿祖籍判断两个人能不能聊到一块儿是一个毛病。真正要看的是三个可测量的指标：词汇重合率、语法形态数量差、书面正字法是否有官方对应表。这三项在克斯这一对上给出的答案都不乐观，尤其是第二项，差了一整套形态。 词汇重合率这一项要用自己站里的词表算，不能用通用语料的数字。通用语料算出来的重合率通常偏高，因为它包含大量功能词和低频书面词，而电商页面上密度最高的是商品名、属性词和动作词，这三类恰好是分叉最严重的部分。 ## 互通的方向是不对称的 互通度还有个容易被忽略的性质，它不是双向对等的。 斯洛文尼亚人接触克罗地亚语媒体的机会明显更多。 历史上共用过的媒体环境、旅游流向、体育转播都在往一个方向推。 反过来，克罗地亚人日常接触斯洛文尼亚语的机会少得多。 落到实操上，就是一边能凑合读懂，另一边基本读不懂。 如果只做一套内容，那套内容该用哪一边的语言就有了答案。 方向不对称这件事在预算紧张时反而是个可以利用的杠杆：先上克罗地亚语版本，斯洛文尼亚那边的用户还能连蒙带猜地读完商品页，转化会掉但不会归零。反过来先上斯洛文尼亚语版本，克罗地亚那边的流量基本接不住，因为对方连商品名都对不上。 验证方向不对称最省事的办法是看两国的搜索行为：统计有多少斯洛文尼亚境内的会话在搜克罗地亚语词串，再反过来统计一次。这个比值通常在三比一到五比一之间，数字本身就是一份决策依据，还能拿去说服不愿意批预算的人。 ## 字母表差在哪里，会带来什么后果？ ## 克罗地亚语多出来的那两个字母 克罗地亚语用的是加伊拉丁字母，一共三十个字母。 斯洛文尼亚语的字母表短一些，只有二十五个。 带钩的那三个两边都有，问题出在另外两个上。 克罗地亚语有一个带撇的软音字母，还有一个带横杠的字母。 这两个字母在斯洛文尼亚语的正字法里根本不存在。 结果是克罗地亚语商品名里的那个带横杠字母，斯洛文尼亚人不会打。 不会打就会用形近的字母替代，替代方式还不止一种，有人打成d加j，有人直接打成d，还有人复制粘贴。三条路径就是三批不同的查询串，你的关键词表里要么全收，要么就得接受其中两条完全接不住，这跟希腊语接不住用户用拉丁字母打出来的那半边搜索 (https://zhangwenbao.com/greek-seo-greeklish-latin-transliteration-coverage.html)是同一类问题。 处理这类字母的通用做法是建一张等价类表：把同一个字母的所有输入变体归成一组，检索时任何一个变体都能命中同一批商品。这张表要放在检索层而不是内容层，内容层保持正确写法，检索层负责宽容匹配，两边职责分开才不会越改越乱。 ## 三个二合字母在排序里算一个 克罗地亚语字母表里有三个由两个符号拼成的字母。 它们在字母表里各占一个独立位置，不是两个字母的组合。 排序时，以lj开头的词整体排在以l开头的词后面。 斯洛文尼亚语没有这条规则，lj就是l后面跟一个j。 同一批商品名在两个市场按字母排序，顺序会不一样。 字母索引导航的分组也不一样，克罗地亚语要多出三个分组。 这个坑跟捷克语把ch当一个字母排是同一类，但克罗地亚语一次中三个，出错面积更大。UTS #10里的多字符排序单位 (https://www.unicode.org/reports/tr10/)就是为这种情况准备的，而默认的字节序排序会把lj开头的词混进l那一堆里，用户按字母翻商品目录时找不到，而这种错在后台看数据永远看不出来，只有真人按字母翻一遍才会发现。 验证排序对不对不用写测试，找一份当地出版的纸质词典翻一遍就知道了。词典的排序是最权威的参照，把你的分类页字母索引和词典的字母顺序并排比对，二十分钟能查完全部三个二合字母的位置，比读一遍排序规范快得多。 ## 折叠成拉丁基本字母时两边规则不同 做技术处理时，很多系统会把带记号的字母折叠掉。 折叠规则听着简单，实际上是按语言定的，不是按字符定的。 带钩的那个字母在两边都折叠成同一个基本字母，这一致。 但克罗地亚语那个带横杠的字母，折叠成d还是折叠成dj有分歧。 正字法传统上认它对应的是dj那个组合，只折成d会丢信息。 斯洛文尼亚语压根没这个字母，它的折叠表里就没有这一行。 拿同一个折叠函数跑两个市场的数据，得到的结果不可比。这跟德语必须把变音字母折成两个字母、土耳其语的无点i不能直接折成i是同一类问题：折叠表是语言资产不是通用工具，写在配置里要按语言分开存，别指望一个全球函数解决所有语言。 折叠表存在配置里还不够，要给每张表配一份回归用例：输入原词，期望输出折叠结果，每次改动跑一遍。折叠逻辑最容易在换框架或者升级依赖时被静默改掉，而这种改动不会报错，只会让一批老页面的地址悄悄换了形状。 ## 斯洛文尼亚语的双数为什么是个工程问题？ ## 名词和动词都有三套形态 大多数欧洲语言的名词分单数和复数两套形态。 斯洛文尼亚语在中间多插了一套，专门用于恰好两个。 这套形态叫双数，名词、形容词、动词全都跟着变。 两把吉他和三把吉他，在斯洛文尼亚语里是两种不同的写法。 这不是可选的文体变化，是语法上必须用的强制形态。 整个欧洲还在日常口语里完整保留双数的语言，屈指可数。 做过一个乐器配件客户的斯洛文尼亚站，团队第一版把配件套装页的数量提示直接从克罗地亚语版换词过来，结果所有写着两件的地方都用了复数形态，母语审校一眼就挑出来了，理由是这种错误跟中文把两个人写成二个人一样刺眼。 双数不只出现在名词上，代词和动词的人称变位也各有一套双数形式。这意味着凡是带主语和谓语的完整句子，只要主体是两个，整句都要跟着改。评价区的统计句、购物车的汇总句、对比页的引导句是三个最常撞上的地方。 ## 界面文案的复数分支要多写一条 前端做多语言时，数量相关的句子靠复数规则分支。 英语只需要两条分支，一条管一，一条管其余。 克罗地亚语要三条，斯拉夫语常见的一、少数、其余那套。 斯洛文尼亚语要四条，在少数那一档前面还要单独插一条。 按CLDR定义的复数分类口径 (https://cldr.unicode.org/index/cldr-spec/plural-rules)，这四类分别叫一、二、少数、其余。 少写一条不会报错，只会在用户看到二这个数字时输出错形态。 这类错误在测试环节最容易漏，因为测试数据通常只填一件和十件。要保证覆盖，测试用例的数量字段至少要跑一、二、三、五、二十一这五个值，斯洛文尼亚语的四条分支和克罗地亚语的三条分支才会全部被触发一次，这个清单值得直接钉在测试文档里。 复数分类的名字在不同框架里写法略有差别，但底层依据是同一份公共区域设置数据。落地时别自己定义分类名，直接采用标准里的那套写法，这样换框架、接第三方组件、跟外包对接时不需要做映射，也不会出现两套命名混用的情况。 ## 双数形态会出现在真实查询里 做关键词研究时，双数容易被当成书面语现象忽略掉。 实际上用户搜配件、搜成对出售的商品时会自然用双数。 耳机、鞋、手套、音箱这类天然成对的品类最明显。 把双数形态漏掉，等于把这批查询整块让给了竞品。 关键词工具对这一档的支持普遍很差，合并进复数里一起报。 只看工具报表，你会以为双数的搜索量是零，实际上不是。 补这批词最省事的办法不是找工具，是拿站内搜索日志过一遍：把用户实际打进搜索框的串导出来，按词尾归类，双数那一档的形态会自己浮出来。这个办法在任何关键词工具支持不好的语言上都成立，站内日志是唯一不经过第三方口径的一手数据。 把双数词条真的做成落地页之前，先看它跟单数页会不会打架。多数情况下双数查询和单数查询的意图是同一个，用户只是顺手打了双数形态，这时候正确做法是把双数形态作为同义词接进现有页面，而不是新建一个薄页面去接。 ## 哪些词看着一样，意思却不一样？ ## 桌子和椅子那一对 假朋友是这两门语言之间最密集的一类坑。 最经典的一对是那个拼作stol的词，两边都有。 在斯洛文尼亚语里，stol是椅子。 在克罗地亚语里，stol是桌子，椅子叫stolica。 更妙的是斯洛文尼亚语的桌子叫miza，跟克罗地亚语完全对不上。 做家具类目的话，这一对足够让整个分类树错位。 这一对之所以危险，不在于它翻错了，而在于它翻错之后页面读起来完全通顺：斯洛文尼亚用户搜椅子进到你的桌子分类页，页面上每个字他都认识，只是商品不对，跳出率会高得离谱而你在报表里只会看到一个转化率偏低的分类页。 这类错位在分类树上会连锁放大：一个错位的分类名会带着它下面所有子类、筛选项和面包屑一起错。所以假朋友检查要从分类树做起，先把树上的每个节点名核对完再往下做商品，顺序反过来的话返工量会翻好几倍。 ## 年和夏天那一对 另一对同样常见的是表示年的那个词。 斯洛文尼亚语的年写作leto，日常用得非常频繁。 克罗地亚语的年是godina，而ljeto在克罗地亚语里是夏天。 两个词拼写上只差一个字母，意思差了一整个季节。 促销文案里写保修若干leto，换到克罗地亚语就成了保修若干夏天。 机器换词工具对这一对基本没有防御能力，照单全换。 时间类词汇是假朋友的重灾区，除了年和夏天，小时那一对也差得很远，斯洛文尼亚语用ura，克罗地亚语用sat，而sat这个词在斯洛文尼亚语里几乎不用。促销倒计时、配送时效、客服工作时间这三类文案全都会撞上，做电商这三类文案的曝光量还特别大。 时间类词汇还有个连带问题，就是它们经常出现在结构化数据的字段值里。保修期、配送时效、有效期这些字段一旦写错，不只是页面上难看，还会让富媒体结果显示出荒唐的信息，而这类错误从后台看数据是完全看不出来的。 ## 孩子那一对最容易翻车 做母婴、玩具、童装的话，还有一对必须提前知道。 斯洛文尼亚语的孩子是otrok，这个词用得极广。 克罗地亚语的孩子是dijete，otrok在克罗地亚语里几乎不用。 更麻烦的是这个词在部分克罗地亚方言里带贬义色彩。 直接换过去不只是不地道，是可能冒犯到用户。 这类带感情色彩的差异，词典对照表通常标不出来。 所以假朋友清单不能只靠词典比对生成，必须有母语审校在上面标注语感等级。实操上分三级：意思不同、意思相同但语域不同、意思相同但带负面色彩。第三级的词无论如何都要重写，前两级可以按页面类型决定要不要处理，这个分级本身就是母语审校交付物的一部分。 带感情色彩的词还有一类值得留意，就是历史时期留下来的政治敏感词。两国近几十年的经历不同，某些在一边是中性的表述在另一边会引发不适。这类词的数量不多，但一旦踩中，代价远不是转化率下降那么简单。 ## 假朋友清单怎么建才不会漏 建清单的起点不是翻词典，是拿自己站内的词表去撞。 把商品标题、分类名、筛选项、按钮文案全部导出来。 切成词，去掉重复，得到一份几千条的候选表。 拿这份表在两边的权威词典里各查一遍，比对释义。 释义对不上的挑出来，交给母语审校做第二轮判断。 这份清单是资产，要进版本库，每次上新商品都要跑一次。 清单的价值随时间递增，因为它同时还是机器换词工具的黑名单：把清单里的词设成禁止自动替换，工具在遇到它们时抛出人工确认，一次投入长期受益。斯洛文尼亚语这边的核对源可以用词典门户里stol给出的释义 (https://www.fran.si/iskanje?Query=stol)这类具体词条，克罗地亚语那边用语言门户和正字法在线版，两边都能查到完整的释义与形态。 清单还要覆盖一个容易漏的场景：用户生成内容。评价、问答、社区帖子里的用词不受你控制，但它们会被搜索引擎抓取并影响页面的语言判定。定期抽样看这批内容里有没有大量另一边的用词，是判断你的地区定位有没有跑偏的一个便宜信号。 ## 系统性对应能不能拿来批量换词？ ## 有规律的那一部分确实存在 好消息是两边确实有一批词是机械对应的。 最明显的一条规律出现在元音上，克罗地亚语常见的ije。 这个组合在斯洛文尼亚语对应的位置上通常就是一个e。 牛奶、天气、时间、地方这几个高频词全部符合这条规律。 周这个词也接近，克罗地亚语的tjedan对斯洛文尼亚语的teden。 这批词能靠规则批量转换，省下的工作量相当可观。 把符合规律的词单独拉出来做成映射表，是这两门语言之间唯一能真正自动化的部分。表的规模通常在几百到一千条之间，覆盖的是日常高频词，正好也是商品描述里出现次数最多的那批，投入产出比在整个本地化流程里排第一。 这条元音规律的适用范围有个更精确的说法：它主要出现在同源的固有词上，对借词和新造词无效。所以建映射表时先按词源分类，固有词那一堆走规则，借词那一堆逐条人工确认，两堆的处理成本相差一个数量级，混在一起做会拖慢整体进度。 ## 规律在哪些位置会失效 坏消息是这条规律的适用面被高估得很厉害。 它主要管词根里的元音，管不到词尾的形态变化。 两边的格尾体系不完全一样，词尾还得单独处理。 专有名词、品牌名、外来词完全不在这条规律的覆盖范围内。 假朋友那一批更是要主动排除，规律套上去只会加速出错。 算下来，能靠规律解决的大概只占词表的三成到四成。 更隐蔽的失效发生在派生词上：词根符合规律，但两边在这个词根上派生出来的常用词不是同一个。比如同一个表示送的词根，克罗地亚语常用的名词形式和斯洛文尼亚语常用的名词形式后缀不同，规则转换给出的词语法上没错，就是没人这么说，搜索量接近零。 派生词的问题可以用一个便宜的检测手段兜住：把规则转换出来的词拿去做站内搜索和站外精确匹配，两边结果都接近零的，标红退回人工。这一步能自动跑，不需要语言知识，却能挡掉规则转换里绝大多数看着对实际没人用的产物。 ## 批量换词之后必须做的验收 跑完规则转换，不能直接发布，要过三道验收。 第一道是撞假朋友清单，命中的全部退回人工。 第二道是抽样搜索量核对，转换后的词有没有人真的在搜。 第三道是母语审校抽读，看整段读起来顺不顺。 三道验收的通过率如果低于八成，说明规律用过头了。 这时候正确的动作是缩小规则的适用范围，不是加规则打补丁。 抽样搜索量核对这一步经常被跳过，理由是没有工具数据，但其实有个土办法：拿转换后的词到搜索引擎里做精确匹配查询，看返回的本地站点数量级。若干量级的差距足以判断这个词在当地是不是活的，至于第三方SEO工具的数据到底准不准 (https://zhangwenbao.com/third-party-seo-tool-data-accuracy-estimation-methodology.html)，那是另一个话题。 三道验收的顺序不能随便调。先撞清单再核搜索量最后审校，是按单位成本从低到高排的。倒过来做的话，审校会把时间花在那些本来就该被前两道拦掉的内容上，人工成本立刻翻倍，而审校恰恰是整个流程里最贵的一环。 ## 克罗地亚语的纯洁主义会怎么影响选词？ ## 官方推荐词和用户实际打的词分叉 克罗地亚语有一个别处少见的现象，叫语言纯洁主义。 官方语言机构会为外来词专门造一个本土替代词。 飞机、计算机、键盘这类词都有官方推荐的克罗地亚语说法。 网店这个词也有，官方推荐的是一个由网加商店构成的组合。 问题是用户在搜索框里打的，往往还是那个外来词。 官方词和实际搜索词分叉，这在斯洛文尼亚语那边弱得多。 克罗地亚语言研究所专门做了一个替代词推荐库，网店这个词的推荐说法 (https://bolje.hr/rijec/online-trgovina-gt-mrezna-trgovina/95/)就收在里面，把每个外来词对应的本土形式列出来，这个库对做内容的人来说是双刃剑：它告诉你正式场合该怎么写，但绝不能拿它当关键词表，因为它记录的是应该说什么，不是人们实际在搜什么。 判断分叉幅度别只看总量，要按查询意图分开看。信息型查询里官方词的占比通常明显更高，因为搜资料的人受教材和媒体的写法影响更深；交易型查询里外来词几乎压倒性领先。这个规律直接决定了哪一类页面该用哪个形态做标题。 ## 哪一类词的分叉最大 分叉幅度跟词的年龄有关，越新的外来词分叉越大。 技术类、互联网类、商业类的新词分叉最严重。 生活类、食品类、传统手工艺类的词基本不分叉。 做数码、软件、在线服务的，要按最大分叉处理。 做食品、家居、服装的，这个问题的影响小得多。 判断自己在哪一档，把主力关键词按词龄排一次就知道了。 有个反直觉的现象值得记住：分叉最大的那批词，往往也是官方推荐词的搜索量增长最快的那批。因为学校教材和政府文书在推它，年轻用户的用词习惯会慢慢迁移。这意味着这批词不能只做一边，得两边都覆盖，并且每年重新看一次比例。 按词龄排序有个可操作的近似办法：看这个概念是哪一年前后进入日常生活的。上世纪就存在的概念基本不分叉，本世纪才普及的概念分叉最大。这条粗略的时间线不需要查任何资料，团队里随便一个当地人花半小时就能把主力词表标完。 ## 标题和正文可以分开用 两边都要覆盖，具体怎么落地有个成熟做法。 标题和面包屑用用户实际搜的那个词，接住搜索流量。 正文首段把官方推荐词自然带进去，一次就够。 这样两个形态都在页面上，覆盖面全，读起来也不别扭。 顺序不能反，反过来会让标题读着像政府公文。 页面标题标签和站内标题保持一致，别一个用外来词一个用本土词。 这个做法的适用面比克罗地亚语大得多，冰岛语、法语在魁北克的用法、土耳其语的部分词汇都能套。判据是同一件事在这门语言里存在官方推荐说法和民间通行说法两套，且两套的搜索量都不为零，满足这个条件就可以用标题接流量、正文补正式说法的分工。 两个形态同时出现在页面上，还有个额外好处是消除歧义。有些外来词在当地存在多个义项，官方推荐词的语义边界通常更窄，把它放在正文首段等于给整个页面加了一个语义锚点，对机器理解这个页面在讲什么有实打实的帮助。 ## 斯洛文尼亚语这边宽松很多 斯洛文尼亚语也有本土造词，但强制力弱得多。 计算机那个词有本土说法，用得也确实广。 但整体上外来词被接受的程度比克罗地亚语高。 做斯洛文尼亚语内容时，这一项的额外工作量小很多。 不用为每个技术词准备两个形态，按用户实际用法写就行。 这也是两边工作量不对称的原因之一，克罗地亚语那边更重。 把这条差异写进排期表很有必要：同样一份技术类商品文案，克罗地亚语版本的选词环节要多留出三到五成的时间，因为每个新词都要查两遍并决定用哪一个在哪个位置。这个时间不是浪费在纠结上，是花在查证上。 不过斯洛文尼亚语在另一个地方要多花时间，就是词序比克罗地亚语更灵活，同一个意思能写出好几种排列。这让标题的写法选择更多，也更容易在不同页型之间写得不一致，所以这边要提前把标题模板固定下来，别让每个人各写各的。 ## 两个市场的非语言字段，差的不只是语言 ## 货币压根不是同一种 斯洛文尼亚在2007年就用上了欧元。 克罗地亚这边到现在还在用自己的货币库纳。 这意味着价格字段、结算流程、比价逻辑全部要分开。 促销价的心理定价点也完全不同，整数点位不在一个刻度上。 把欧元价格按汇率直接换成库纳，会得到一串很难看的数字。 本地定价要重新做，不是换算，是重新挑价格点。 货币不同这一条，比语言差异更早地把这一对市场劈成了两半。它连带影响的还有价格结构化数据的货币代码、货币符号的位置与空格习惯、小数分隔符的写法，以及广告投放里出价单位的换算，任何一处配错都会在前台直接暴露给用户。 货币差异还会渗进关键词本身。带价格区间的查询串在两个市场是不同的数字，用户心里的便宜和贵对应的绝对值完全不同，这类查询你没法靠换词生成，只能拿本地数据重新算一遍价格分档，再按分档去布词。 ## 税率和法务文本各走各的 两国的标准增值税率不一样，含税价的算法就不一样。 发票模板、退换货政策、消费者权益条款全部要各做一份。 这批文本量不小，而且必须由懂当地法务的人写。 它们不是内容营销资产，但会被搜索引擎抓取和评估。 写得潦草的政策页会拖累整站的可信度评分。 好在这批文本一次写好之后很少改，属于一次性投入。 有个容易被忽略的连带影响：含税价不同意味着两边的商品价格在结构化数据里天然不同，如果你的系统是从一个源头生成两边的价格字段，很可能会把不含税价错标成含税价，这种错误在富媒体结果里会直接显示成错误的价格，用户点进来看到的数字对不上。 这批文本还有个常被忽略的作用，它们是站点信任信号的组成部分。政策页写得完整、条款清楚、联系方式落到当地实体，这些都会被评估。在两个都不熟悉你品牌的小市场里，这类信号的边际作用比在成熟市场大得多，值得多花一点时间。 ## 物流与配送时效要分开写 两国的国土形状和人口分布差别很大。 克罗地亚沿海狭长，岛屿多，配送时效方差大。 斯洛文尼亚国土紧凑，全境次日达的可行性高很多。 配送承诺写成同一句，一边会承诺不足，一边会承诺过头。 岛屿配送附加费这类字段，斯洛文尼亚那边根本不需要。 这些字段的差异不在语言层，但会影响落地页的转化。 配送时效还会反过来影响关键词布局：在配送不确定性高的市场，用户搜索时更倾向于带上配送相关的修饰词，这批查询的搜索量在克罗地亚那边明显高于斯洛文尼亚。也就是说市场的物流现实会改变查询习惯，这是非语言字段回头影响语言层的一个例子。 配送信息还要注意展示位置。在配送不确定性高的市场，把时效写在商品页靠上的位置能显著降低跳出，因为这是用户最想确认的事；在配送稳定的市场，同样的信息放在靠下反而更好，把上面的位置留给卖点。同一份信息，两个市场的版式不该一样。 ## 三档复用判据怎么划？ ## 第一档，可以整块搬过去的 能整块复用的东西比想象中少，但也不是没有。 商品图、尺寸表、材质代码、技术参数数值都在这一档。 吉他的品丝数、拾音器型号、木材名称的拉丁学名不用改。 页面模板、结构化数据的骨架、内链结构也能共用。 这一档的共同特征是内容里几乎没有自然语言。 划这一档的时候标准要严，有一个词是自然语言就往下降一档。 把第一档的边界划清楚有个很实际的好处：这批资产可以放在同一个数据源里维护，改一次两边同时生效，不需要同步机制。一旦有内容混进第一档又需要按市场改，同步机制就得建起来，那个成本比多做一份内容还高。 技术参数看着像纯数字，其实也有语言陷阱。单位写法、小数分隔符、千位分隔符在两个市场的习惯可能不同，尺寸表里的数值本身能共用，但渲染出来的字符串不能。正确做法是共用数值，渲染时按地区格式化，别把格式化好的字符串当资产存。 ## 第二档，换词就能用的 第二档是那批符合系统性对应规律的内容。 规格描述、材质说明、通用的使用注意事项多在这一档。 这一档要过换词流程加三道验收，不能直接发。 它占的比例大概是三成到四成，是效率提升的主要来源。 做好这一档的关键是那份映射表的质量，表准了流程就顺。 表要有人维护，每次审校发现新的对应关系就补进去。 第二档还有个隐藏收益：它天然产出一份两语对照语料。做到一定量之后，这份语料能反过来提升机器换词的准确度，也能用来给新加入的译者做培训材料。很多团队做完就扔了，其实它是这个流程里唯一会随时间增值的东西。 这一档要给每条内容打上来源标记，注明它是规则转换来的还是人工写的。有了标记，后面发现某条规则有问题时能一次性定位到所有受影响的内容并批量重跑；没有标记的话，只能全量重新过一遍，成本完全不同。 ## 第三档，必须从头写的 第三档是那批换词换不出来的内容。 标题、页面标题标签、描述、促销文案、品牌故事全在这里。 假朋友命中的段落、双数相关的句子也必须重写。 价格、税率、配送、法务这些非语言字段同样归这一档。 这一档的比例在半数上下，取决于品类和页面类型。 它决定了做两个市场的真实边际成本，账要按这一档算。 划完三档之后要做一件事：把每一档的比例按页面类型分别统计。分类页和商品列表页的第一档比例通常很高，商品详情页居中，内容营销页几乎全是第三档。这张比例表就是排期表的依据，先上第一档比例高的页型，能最快让新市场有个能看的样子。 第三档里有一小块值得单独拎出来，就是那些同时受语言和法规约束的文案，比如商品的成分标注、警示语、能效标识。这批内容既不能自由发挥也不能机器换词，必须由熟悉当地法规的人写，排期上要当成外部依赖来管，别放在内容团队的工作量里估。 ## 这一对跟另外两套近亲语言框架不是一回事 ## 跟捷克语斯洛伐克语那种二选一比 近亲语言的市场决策，站内已经写过三种不同的框架。 捷克语和斯洛伐克语那一对用的是二选一决策框架。 那套框架的前提是两边互通度高，先做一套确实能过渡。 克斯这一对用的是同一套框架，但答案是反的。 互通度不够，一套内容撑不住第二个市场的转化。 框架相同，输入不同，结论就从可以过渡变成必须两套。 这正是二选一框架的价值所在：它不预设答案，只要求你先把互通度量出来。很多团队跳过测量直接套用别人的结论，看到捷克斯洛伐克那边说可以先做一套，就以为南斯拉夫语这边也行，这一步省下的两周测试时间，后面要用半年的转化损失来还。 还有一个容易忽略的差别，捷克斯洛伐克那一对在分家之前共用过一套官方书面标准，很多术语的对应关系是被文件规定过的，可以直接查。克斯这一对没有这样的历史文件，所有对应关系都得自己建，这一项本身就是好几个人天。 ## 跟北欧三个市场的资产分层比 瑞典语顺手带上挪威丹麦能整块共用的只有商品图和尺寸表 (https://zhangwenbao.com/nordic-seo-swedish-norwegian-danish-content-sharing-boundary.html)那一篇，用的是完全不同的第二套框架。 那边有三个市场，两两之间的距离还不相等。 三个市场用二分法不够用，得改成按资产类型分层。 问的不是分不分开做，是每一类资产的共用边界在哪一层。 克斯这边只有两个市场，二分法够用，不需要上分层框架。 用错框架的代价是把简单问题复杂化，决策周期拖长一倍。 判断该用哪一套很简单，数市场个数：两个市场用二选一，三个及以上用资产分层。第二个判据是两两距离是否相等，如果三个市场里有两对距离明显不同，那分层框架就是唯一能表达这种不对称的工具，二分法会把信息压扁。 分层框架也不是完全用不上。如果哪一天要把塞尔维亚或者波斯尼亚一起纳进来，市场数量到了三个以上，就该从二选一切换到资产分层。切换的时机不是市场数量变了才想，而是在做第二个市场时就把资产按类型归好，为将来留出接口。 ## 跟同一个国家里两种语言比 第三套框架是乌克兰语要面对两种语言都看得懂的用户 (https://zhangwenbao.com/ukrainian-russian-seo-bilingual-market-content-split.html)那种情形。 那一对的特点是两种语言在同一个国家里并存。 货币、物流、法务、支付这些非语言字段全部共用。 分叉百分之百落在语言上，做两套的边际成本最低。 克斯这一对正好相反，非语言字段一样都不共用。 同样是两个语言版本，边际成本能差出好几倍。 把三套框架并排放，判据其实只有两个：市场数量和国界位置。两个市场跨国界用二选一，三个及以上跨国界用资产分层，两种语言在同一国界内用分工模型。这张表挂在墙上，下次遇到新的近亲语言对，五分钟就能选对框架。 同国分工那套框架里还有一条独有的约束，两种语言的用户会互相看到对方的页面，所以两套内容要在同一个站内共存并且能互相切换。克斯这边不存在这个问题，两个市场的用户几乎不会跨过去看，页面之间不需要设计切换路径。 ## 框架选错会怎样 框架选错不会立刻报错，会在半年后以转化率的形式反馈。 最常见的错法是把克斯这一对当成乌俄那种情形。 误以为非语言字段能共用，结果价格和配送全部要返工。 第二常见的错法是套北欧的分层框架，把决策拖成会议马拉松。 第三种是干脆不选框架，凭感觉先做一个再说。 凭感觉的成本最高，因为返工时连该改哪里都定位不到，这跟开站前该不该做SEO的自评 (https://zhangwenbao.com/before-seo.html)跳过不做是同一种省法。 选框架这件事花的时间不该超过一天。量互通度两周，数市场个数五分钟，看国界位置一分钟。三项加起来的投入，相对于一个市场半年的内容预算来说微不足道，而它决定了那笔预算是花在正确的方向上还是花在返工上。 有个便宜的止损办法，在正式投入前先做一个最小验证：只翻译二十个页面上线三十天，看第二个市场的转化率跟第一个市场的比值。这个比值如果低于一半，基本可以判定复用假设不成立，此时改方向的成本还是可以承受的。 ## 做还是不做，这笔账该怎么算？ ## 先算能复用的比例 决策的第一个输入是第一档加第二档的比例。 把主力页型各抽二十个页面，按三档标注一遍。 算出来的比例就是复用率，这个数越高越值得做。 克斯这一对的典型复用率在四成到五成之间。 作为对照，捷克语到斯洛伐克语能到七成往上。 差出来的这两三成，就是这一对额外要付的语言账。 标注这二十个页面别派给一个人做，找两个人独立标注再比对。三档的边界在实操中比看起来模糊，两个人标注结果的一致率如果低于八成，说明三档的定义还没写清楚，得先把定义补细再重标，否则后面所有排期都建在一个不靠谱的数上。 复用率还要按时间维度看一眼。首次上线时的复用率和长期运营中的复用率不是一个数，因为促销、季节内容、活动页这些高频更新的内容几乎全是第三档。只看首次上线的复用率会严重高估，长期看要按内容更新频率加权重算一遍。 ## 再算独有的那部分工作量 第二个输入是每个市场独有的工作量。 斯洛文尼亚语这边独有的是双数分支和四条复数规则。 克罗地亚语这边独有的是纯洁主义带来的双形态覆盖。 两边共有的是假朋友清单和母语审校，这笔钱躲不掉。 非语言字段那批各做一份，工作量不小但一次性。 把这几项按人天估出来，加上复用率，账就能算了。 估人天时有个经验值可以参考：假朋友清单的首次构建大约要十到十五个人天，之后每季度维护一到两天；双数与复数分支的改造在前端侧通常是三到五个人天，一次性；纯洁主义的双形态覆盖分摊到每个页面，大约让选词环节的时间增加三到五成。 估工作量时留一条经验缓冲：近亲语言项目的实际耗时普遍比估算高三成，原因是那些看着像小问题的差异会反复冒出来打断流程。把这三成明确写进排期而不是留在心里，能避免后期反复解释为什么又延期。 ## 门槛线画在哪里 最后要有一条门槛线，低于它就不做。 门槛不该只看人口，两国加起来也就六百多万，小语种优先级要算的那三笔语言账 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)在这里同样适用。 要看的是这个品类在当地的线上渗透率和竞争密度。 小市场的好处是竞争稀薄，头部位置的获取成本低。 坏处是天花板矮，做到第一名的流量也就那么多。 常见的做法是先做互通方向上占优的那个市场，跑三个月看数。 如果三个月的数据支持继续，第二个市场的投入会比第一个低得多，因为第一档和第二档的资产已经建好了。这就是先后顺序的价值：不是省钱，是把不确定性分两次消化。第一次赌的是品类在这个区域行不行，第二次赌的是第二个市场值不值，两次决策各自独立。 门槛线还要考虑一个非财务因素，就是团队的运维带宽。多一个语言版本就多一份内容日历、一份审校排期、一份客服话术，这些长期负担不出现在首次投入的账里，却是最常见的放弃原因。做决策时把它折算成每月固定人天写进账里，判断会准很多。 ## 常见问题解答 ## 克罗地亚语和塞尔维亚语可以合并成一套吗，跟这一对是同一个问题吗 不是同一个问题，方向恰好相反。克罗地亚语和塞尔维亚语之间的互通度极高，高到语言学上一直有争议要不要算成一门语言，真正的分叉主要落在书写系统和一部分词汇上，那是保加利亚语和塞尔维亚语用哪套字母写商品名 (https://zhangwenbao.com/bulgarian-serbian-seo-cyrillic-latin-dual-script.html)那一类问题。克斯这一对反过来，书写系统一致，都用拉丁字母，分叉落在词汇和形态上。所以处理手法也是反的：克塞之间的重点是字母系统的覆盖与自动转换，克斯之间的重点是假朋友清单与形态差异。把这两个问题混在一起处理，最常见的后果是做了一堆字母转换工作，却没发现真正在拖转化的是那些看着眼熟的假朋友。判断方法很直接，先问分叉在哪一层，字形层的走转换，词汇层的走清单，形态层的走前端改造，三层的工具完全不一样。 ## 只做一套内容，选克罗地亚语还是斯洛文尼亚语 如果一定要选一套，通常选克罗地亚语，理由是互通方向不对称。斯洛文尼亚用户接触克罗地亚语媒体的机会更多，能连蒙带猜读完一个商品页；反过来克罗地亚用户读斯洛文尼亚语内容的难度大得多。但这个选择有两个前提要确认：一是你的品类不依赖精确的规格描述，读个大概不影响下单；二是斯洛文尼亚那边的支付和配送已经能正常跑通，否则语言能读懂也没用。另外要清楚这只是过渡方案，不是终局。用一套内容接两个市场，斯洛文尼亚那边的转化率通常只有正常水平的六成到七成，这个折扣要提前写进预期里，别到时候拿它跟克罗地亚那边的数据横向对比得出错误结论。真到了要做第二套的时候，前面攒下的第一档和第二档资产会让投入明显低于第一次。 ## 双数形态在关键词工具里查不到，怎么估它的搜索量 工具查不到的原因是它把双数并进复数一起报了，所以直接看工具永远是零。三个办法可以互相印证。第一个是站内搜索日志，把用户实际打进搜索框的串导出来按词尾归类，双数那一档的形态会自己浮出来，这是唯一不经过第三方口径的一手数据。第二个是搜索建议，在搜索框里输入词根，看引擎补全出来的形态里有没有双数，补全能出现说明有真实查询量在支撑。第三个是拿双数形态做精确匹配查询，看返回的本地结果数量级，跟单复数形态的结果数做对比，比例大致能反映相对搜索量。三个办法都有偏差，但三个结论如果一致，基本可以下判断了。特别提醒别用总量去估，要用相对比例：你要回答的问题不是双数有多少搜索量，而是它占这个词全部搜索量的百分之多少，值不值得单独做一批落地页。 ## 假朋友清单要维护到什么颗粒度 颗粒度取决于品类，但有一条基线：所有出现在商品标题、分类名、筛选项、按钮文案里的词都要覆盖，这四类文本的曝光量最大，出错代价也最高。商品描述正文里的词可以放宽，因为上下文能提供纠错线索，用户读到一个奇怪的词往往能从周围的句子里猜出意思。清单本身建议存成三列：词、两边的释义、语感等级。语感等级分三级，意思不同的最高，意思相同但语域不同的中等，意思相同但带负面色彩的必须最高优先级处理，因为这一级不只是不地道，是会冒犯用户。维护节奏跟上新频率挂钩，每次批量上新商品都要拿新增的词跑一遍，日常则每季度全量复查一次。还有一点容易忘：清单要同时作为机器换词工具的黑名单接进流程，否则你建了清单但工具照换不误，等于白建。 ## 两个市场的域名该怎么分 域名和目录结构属于架构层的决策，跟语言本身关系不大，URL结构与slug优化影响抓取与排名的那些细节 (https://zhangwenbao.com/url-structure-slug-optimization-onpage-seo-mechanism.html)里讲得更细，这里只说跟这两门语言相关的那一小部分。相关的部分是两国各自有国家顶级域，而在这两个市场里本地顶级域的信任度确实比通用域高，尤其是克罗地亚那边，用户对本地域名的偏好比较明显。但这不构成必须用本地域名的理由，通用域加正确的地区定位同样能做起来，只是起步阶段的信任建立要慢一些。真正跟语言相关的是另一件事：如果两边共用一个域名，那么两个语言版本的内容必须有清晰的语言标记，否则搜索引擎很容易把互通度高的两种语言内容判成重复。克斯这一对的词汇重合率虽然不算高，但句法结构相近，某些页型的相似度会超出预期，尤其是那些第一档比例高的页型。 ## 母语审校该找什么样的人，两个市场能不能共用一个 不能共用。这一点在近亲语言项目里最容易被砍预算，理由通常是两边差不多，一个人能兼顾，实际上恰恰相反，越是近亲越需要分开。原因在于近亲语言之间的错误特别隐蔽，一个母语者能立刻发现完全陌生的错误，却很容易放过那些看起来眼熟的错误，因为它在另一门语言里是对的。找人的标准有三条：母语者、长期生活在目标市场、有电商或者你所在品类的内容经验。第三条经常被忽略，但它决定了审校能不能发现术语层面的问题，而不只是语法层面的。审校的交付物也别只要一份改好的稿子，要同时要一份问题清单，标出每处改动的类型和原因。这份清单积累起来就是前面说的假朋友清单和语感等级表，是这笔钱里最值钱的部分，比稿子本身的价值大得多。 ## 先上哪个市场，有没有更细的判断标准 除了互通方向这一条，还有三个可以量化的输入。第一个是品类在两国的线上渗透率，某些品类在斯洛文尼亚的线上化程度明显高于克罗地亚，这种情况下先上斯洛文尼亚反而更快见效。第二个是竞争密度，把主力关键词在两边各查一遍搜索结果，看头部有没有强势的本地站，本地站少的那边获取头部位置更容易。第三个是支付与配送的就绪度，语言做得再好，货到不了或者付不了款都是白搭，这一项是硬约束不是加分项。三项都占优的情况很少见，通常要权衡。权衡时的一个经验是把支付配送就绪度当成一票否决项，先排除不满足的，再在剩下的里面按竞争密度排序，渗透率作为参考。互通方向那一条只在你打算用一套内容临时覆盖两边时才起决定作用，如果一开始就打算做两套，它的权重可以调低。 ## 权威参考资料 ## 小语种关键词工具返回的那个零是数据缺口，不是需求缺口，数得自己补出来 - URL：https://zhangwenbao.com/minor-language-keyword-tool-no-data-workarounds.html - 分类：小语种SEO - 发布：2016-11-22 | 更新：2026-07-24 - 摘要：小语种关键词工具查不到数据时，零往往是采样不足而不是没人搜。讲清工具数据从哪来、这些语言为什么难统计，以及站内数据、语料库、搜索建议三条补数据的路怎么合并使用。 - 关键词：关键词研究,SEO工具,多语言SEO,小语种SEO > **TLDR**：摘要：关键词工具在小语种上给出的零，多数时候不是这个词没人搜，而是它手里的样本不够多，或者这门语言的词形把同一个需求摊成了几十份。把零当成结论，等于把一整个市场判了死刑，而判决书是工具的采样精度写的。 > 摘要：关键词工具在小语种上给出的零，多数时候不是这个词没人搜，而是它手里的样本不够多，或者这门语言的词形把同一个需求摊成了几十份。把零当成结论，等于把一整个市场判了死刑，而判决书是工具的采样精度写的。 ## 工具在小语种里返回零，到底意味着什么？ ## 零、无数据、低于阈值是三件事 查一个词，工具返回零，界面上看着是同一个结果。 但背后可能有三种完全不同的情况。 第一种是这个词确实没人搜，真的是零。 第二种是工具在这个语种上没有数据源，它压根没得可算。 第三种是有数据但低于展示阈值，被四舍五入成了零。 三种情况对应三种决策：放弃、换方法、直接做。 分辨它们有个简单的办法，拿同一个语种里明确有大量搜索的通用词去查，比如当地话里的天气或者新闻。如果连这种词都返回零或者数据明显失真，说明是第二种情况，问题在工具不在市场。这个测试三分钟就能做完，却能省掉后面几个月的错误判断。 把这三种情况写进团队的判断口径里很有必要，否则每次讨论都会有人拿零当证据，而另一些人凭直觉反对，双方争的其实是同一个数字的不同解释。 ## 工具手里的数据是从哪儿来的 大部分关键词工具的数据来自三个源头。 一是广告平台公开的规划数据，二是自建的点击流采样，三是各种第三方数据的拼接。 广告平台的数据覆盖最广，但它按广告主的投放需求组织，冷门语种的颗粒度很粗。 点击流采样依赖装了插件的用户样本，样本在小市场里可能只有几千人。 几千人的样本推算一个千万人口市场的搜索量，误差大到没法用。 第三方拼接的数据则往往是同一批源头换了个包装。 这三个源头有个共同点，它们都是围绕英语和几个大语种设计的。到了小语种上不是不能跑，而是每个环节的精度都在下降，几层误差叠起来，输出的那个数字已经跟真实需求没多大关系了。工具本身没错，是我们用超出它设计范围的方式在用它。 挑工具时可以直接问客服一个问题：你们在这个语种上的数据主要来自哪个源头。答得含糊的，基本可以判断它是拼接来的二手数据。 ## 语种越小，采样越稀 这里有个很直观的比例关系。 母语人口两亿的语种，采样样本可能是几十万人。 母语人口五百万的语种，同样比例下只剩下几千人。 而长尾词本身的搜索频次又极低，一个月可能只有几百次。 几千人的样本去捕捉几百次的行为，命中概率接近于零。 于是这个词在工具里就变成了零，尽管它每个月实实在在有几百次搜索。 这个机制解释了一个常见现象：小语种市场里越是具体、越是接近成交的词，在工具里越查不到，而越宽泛、越没有商业价值的词反而有数。这恰好跟你想要的顺序相反，也是很多团队在小语种市场里做完关键词研究后觉得这个市场没需求的直接原因。 这个采样机制还带来一个副作用，同一个词隔几个月再查，数字可能大幅波动，那多半不是需求变了，是样本里恰好多了或少了几个人。 样本稀疏还有个连带后果，工具给出的竞争度和出价区间在小语种上同样不可靠，那两列数字的采样基础跟搜索量是同一份。 ## 为什么这几门语言天生就不好统计？ ## 一个词能摊成几十个形态 屈折语和黏着语里，同一个词根会随着语法角色变形。 芬兰语的名词有十五个格，波兰语有七个，土耳其语则是后缀一层层往上接。 用户搜索时用的是句子里的自然形态，不是词典形态。 工具如果不做词形归并，一个需求就被拆成了几十行数据。 每一行的量都不大，看起来都像可以忽略的长尾。 加起来才是这个需求的真实规模。 这也是为什么在这些语言里，判断一个词值不值得做，不能只看单个形态的数字，必须先把词形归到一起再算总量。芬兰语十五个格加上词干本身也会变 (https://zhangwenbao.com/finnish-seo-fifteen-cases-consonant-gradation-keyword.html)那篇讲的就是归并这一步为什么在有些语言里格外难做。 黏着语的情况更极端，后缀可以层层叠加，理论上的形态数量是组合爆炸的，土耳其语一个词接五个后缀 (https://zhangwenbao.com/turkish-seo-agglutinative-suffix-stacking-keyword.html)那篇里算过这笔账。 ## 变音符号的两套写法各算各的 带记号的字母在搜索框里经常被省略。 捷克语、罗马尼亚语、越南语的用户在手机上打字尤其如此。 于是同一个词有带记号和不带记号两种形态在跑。 工具按字符串统计，两种形态是两行数据。 有些工具会做折叠，有些不会，你很难知道它做没做。 不做折叠时数据被拆散，做了折叠时你又看不到分布。 验证办法是找一个明确常用的带记号词，把两种形态分别查一遍，看返回的数字是不是完全相同。完全相同说明工具做了折叠，两个数字加起来才是总量；数字不同说明它按字符串分开统计，你得自己把两边加起来。这个测试每换一个工具就该重做一次。 元音和谐这类规则还会让同一个后缀有好几种拼法，匈牙利语的十八个格与元音和谐 (https://zhangwenbao.com/hungarian-seo-eighteen-cases-vowel-harmony-keyword.html)那篇里的形态表可以直接当作检查清单来用。 ## 不用空格的语言，切法不一致 泰语、日语这类语言的文本里没有词间空格。 切词全靠算法，不同算法切出来的边界并不一样。 工具的统计口径取决于它用的是哪套切词方案。 同一个短语在两个工具里可能被切成不同的单位。 数字对不上的时候，多半不是谁错了，是切法不同。 这种情况下跨工具比较数字是没有意义的。 能做的是把同一份词表在同一个工具里跑完，只做内部排序，不跟其他来源的绝对值对比。泰语没有空格时搜索引擎怎么切词 (https://zhangwenbao.com/thai-seo-no-spaces-word-segmentation-keyword.html)那篇里讲过判断切法的办法，同一套办法可以用来判断工具的口径。 还有一个现实的麻烦，切词口径不同会让同一份词表在两个工具里排出完全不同的顺序，这时候别去调和，选定一个工具从头到尾用完。 ## 两套字母的市场，词表要乘二 塞尔维亚语这类双书写系统的市场，问题更直接。 同一个词有西里尔和拉丁两种完全不同的字符串。 它们在任何工具里都不可能被自动合并。 查一种形态得到的数只是这个需求的一部分。 如果只查了自己更熟悉的那套字母，漏掉的可能是大头。 做词表时必须两套都跑，最后再合并。 合并的时候要注意保留两边的原始数字，而不是只留一个总和。两套字母的使用者在设备、年龄、场景上都有差异，后面做落地页和广告投放时，这个分布是有用的信息，合并成一个数就丢了。 两套字母的词表还要考虑一件事：同一个用户在两套字母之间切换的比例。西里尔和拉丁两套字母同时存在时怎么办 (https://zhangwenbao.com/bulgarian-serbian-seo-cyrillic-latin-dual-script.html)那篇给了判断这个比例的办法。 ## 第一条路是把站内已有的数据当种子 ## 站内搜索日志里全是原始写法 站内搜索是最被低估的一份数据。 它记录的是用户在你自己的地盘上，用自己的语言打出来的原话。 没有经过任何工具的清洗、归并和四舍五入。 词形、拼错、变音符号的取舍，全都是真实分布。 哪怕站点流量不大，这份数据的质量也远高于工具的推算。 唯一的前提是站内搜索的日志得留着，而且能按语言市场拆开看。 拿到日志之后先做三件事：按频次排序、把明显的同一需求的不同形态归到一起、把无结果的查询单独拉一列。第三列是最有价值的，它是用户想要而你没有的东西，在关键词工具查不到数据的市场里，这一列几乎是唯一的真实需求信号。 导日志的时候记得连带导出结果数和点击位置，有没有点、点了第几条，能帮你判断这个查询到底满足了没有，光有查询词是不够的。 日志里还藏着一批复合查询，用户一次输入两三个概念，这类查询能直接告诉你哪些属性是他们真正在意的，做落地页时用得上。 ## 搜索分析报告里的查询与展现 站长工具里的搜索分析报告是第二份免费的真实数据。 它给的是你的页面在搜索结果里被展现时对应的查询。 这份数据的覆盖面比站内搜索大得多，因为它包含了没点进来的那部分人。 关键是要按国家和语言过滤，只看目标市场的部分。 然后看展现量高但点击率低的查询，那些是有需求但你没接住的。 这批查询直接就是待做词表的候选，而且自带真实的量级信息。 用这份数据有个前提：站上得先有一些内容能被展现出来。所以在全新市场里它派不上用场，得先用另外两条路做出第一批页面，等有了展现数据再回头用它修正词表。这三条路的顺序不是并列的，实际执行时有先后依赖。 用这份数据还有个技巧，把时间维度拉开对比，某些查询的展现量在特定月份突然上升，那通常是季节性需求，值得单独排期做内容。 ## 客服和销售那边的原话最容易被忽略 公司里还有一批语言数据，从来没进过关键词表。 客服工单里客户描述问题时用的词。 销售跟当地经销商沟通时对方用的说法。 本地代理写来的邮件里对产品的称呼。 这些都是母语者在真实场景下的自然表达。 它们的价值不在量，而在于能修正你对说法本身的判断。 保哥在一个园艺工具品牌的项目里干过一件很土的事，把当地客服半年的工单导出来，把里面出现的产品叫法统计了一遍，结果发现团队一直在用的那个品类词，客户几乎不用，他们用的是另一个更口语的说法，而那个说法在关键词工具里查出来是零。 把这类内部渠道的词收集起来之后，最好标明来源部门，因为客服看到的是用问题的人，销售看到的是准备下单的人，两拨人的用词偏好差别不小。 ## 种子词怎么扩成一张能用的表 手里有了几十个真实种子词，下一步是扩展。 扩展的方向有三个：词形、修饰词、上下位概念。 词形扩展就是把这个词在这门语言里的常见变形都列出来。 修饰词扩展是加上价格、评价、哪里买、怎么用这类意图词。 上下位扩展是往品类上走一层、往具体型号下走一层。 三个方向做完，几十个种子能扩成几百到上千行。 扩展的时候要克制，别把所有组合都排列出来。机械排列产生的词表里绝大多数是不存在的组合，后面还得花更多时间清理。比较务实的做法是每个种子词只扩它最自然的那几种组合，宁可少一点，也别让词表里塞满自己造出来的词。 扩展词形的时候可以顺手把品牌名的各种写法也一并处理掉，品牌名在小语种里到底写成什么 (https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html)那篇里的变体表跟这里的词形表是同一套逻辑。 ## 语料库能不能替代搜索量？ ## 词频不是搜索量，但排序是可信的 语料库统计的是这个词在文本里出现的频率。 搜索量统计的是有多少人把它打进搜索框。 两者显然不是一回事，绝对值完全不能互换。 但在同一个语义场里，两者的排序高度相关。 如果甲词在语料库里的频率是乙词的五倍，搜索量通常也是一个量级的差距。 而做决策时你真正需要的往往就是排序，不是精确数字。 这个替代关系有个适用边界：它在日常用语和通用品类词上很准，在品牌词、新产品名、突发热点上完全不准。因为语料库的文本有滞后性，而搜索行为对新事物的反应几乎是即时的。判断某个词能不能用词频代替，先看它是不是一个已经稳定存在了几年的说法。 实际用下来，词频排序在品类词上的可靠度最高，在带修饰的长尾组合上会明显下降，因为组合出现在文本里的频次本来就低，样本噪音变大。 ## 哪些语料库真的覆盖小语种 能用的资源比想象中多。 多语平行语料项目覆盖了上百种语言，数据量差别很大但都能查。 面向语言研究的语料检索平台支持的语种数量更可观，还带搭配分析功能。 大规模网页抓取项目的语言分布数据，可以用来判断某个语种的网页存量。 词干算法项目提供的算法列表，本身就是一份哪些语言有成熟处理工具的清单。 这几类资源多数免费，注册一下就能用。 挑语料库有个实用判据：先看它在你的目标语种上收了多少词次。低于一千万词次的语料，做通用词排序还行，做具体品类词就不够了。这个数字通常在项目的语种列表页上直接标着，花两分钟就能筛掉一半不合用的选项。 另外要看语料的构成，如果某个语种的语料主要来自法律文本或者新闻，那它对消费品类的词频判断会有系统性偏差，这一点在语料的说明页上通常写着。 语料库的更新频率也要看一眼，几年没更新的语料对新兴品类几乎没有参考价值，而这一点在项目页上往往不显眼。 ## 用搭配词找出品类的真实说法 语料库最有用的功能其实不是词频，是搭配分析。 输入一个品类词，它会告诉你母语者习惯拿哪些词跟它连用。 这批搭配词就是最自然的修饰词，比自己翻译出来的可靠得多。 翻译出来的修饰词经常在语法上没错，但母语者从来不那么说。 搭配分析能直接把这类问题挡在词表之外。 顺带还能发现一批你完全没想到的说法。 这一步对小语种尤其重要，因为翻译腔的词表是这些市场里最常见的失败原因，当年逐词换出来的那批关键词 (https://zhangwenbao.com/keyword-literal-translation-legacy-cost-non-english.html)之所以留下长期损失，根子就在于没人验证过母语者到底怎么说。 搭配分析的结果建议留档，因为它反映的是这门语言的稳定用法，几年内基本不变，下次做新品类时能直接复用一大半，不用重新跑。 ## 搜索建议为什么比工具更接近真相？ ## 建议列表来自真实输入 搜索建议的生成依据是用户实际打过的查询。 它不需要经过采样推算，也不需要凑够展示阈值。 只要有足够多的人打过，它就会出现在列表里。 对小语种来说，这个门槛比关键词工具的展示阈值低得多。 所以经常出现的情况是，工具里查不到的词，建议列表里赫然在列。 这本身就证明了那个零是数据缺口而不是需求缺口。 用建议列表还有一个附带收获，它反映的是当下的分布而不是过去几个月的平均。季节性品类在这一点上受益最大，园艺、节庆、开学季这类需求在建议列表里的变化能提前几周看到，而工具给的月均值要等到季节结束才反映出来。 不过建议列表也有它的偏差，它会放大已经流行的说法而压制新出现的说法，所以完全新的品类词在建议里可能迟迟不出现，这时候别急着判它没需求。 ## 按字母逐层展开的采集方法 采集方法很机械，但有效。 拿种子词加一个空格，再依次加上这门语言字母表里的每个字母。 每加一个字母记录一次建议列表，得到的就是这个前缀下的高频后续。 拉丁字母表跑二十六轮，西里尔跑三十多轮，一次能收几百个真实查询。 再把疑问词、介词、价格词分别当前缀跑一遍，覆盖面还能翻倍。 整个过程可以手工做，也可以写个简单脚本。 做这件事要注意两点：把地区和语言设成目标市场，用无痕窗口避免个性化干扰。这两个设置不做的话，采到的建议列表混着你自己的历史行为，得到的是一份关于你自己的报告，而不是关于那个市场的报告。 采集的时候把结果按出现位置记下来，排第一的建议和排第八的建议在实际使用频率上差着数量级，位置信息是免费的量级参考。 ## 相关搜索与结果页上的问题模块 结果页底部的相关搜索是第二个来源。 它给的是同一批用户还搜过什么，属于横向扩展。 结果页中间的问题模块则给出这个主题下的高频疑问句。 疑问句形态的词在小语种里几乎不可能在工具里查到数据。 但它们的意图极其明确，做成内容的转化路径很短。 两个来源各采一轮，词表的意图覆盖会完整很多。 这两个模块还有一个用法是判断意图的分布。如果某个品类词的相关搜索里全是价格和对比，说明这个市场处在比价阶段；如果全是怎么用和是什么，说明还在认知阶段。这个判断会直接影响内容的类型选择，而它不需要任何搜索量数据就能做出来。 问题模块采到的疑问句还有一个用法，直接拿它当内容里的小标题，既对得上真实提问方式，也省掉了自己编标题时那份翻译腔。 相关搜索还能反映竞品的存在感，如果某个品类词的相关搜索里反复出现同一个品牌，那说明这个市场的认知已经被它占住了。 ## 三份清单怎么合并成一张能用的词表？ ## 先对齐写法，再合并 三条路拿到的词，写法上很可能不统一。 站内日志里是用户的原始形态，带着各种拼错和省略。 语料库里是规范书面形态，变音符号一个不少。 搜索建议里则是介于两者之间的实际输入形态。 直接合并会得到大量看起来不同实际同一个需求的行。 所以第一步是定一个规范形态，把所有来源都映射过去。 映射规则要写下来存档，别只存在做这件事的人脑子里。半年后新词进来时，得用同一套规则处理，否则新旧两批词的口径不一致，词表会慢慢变成一笔糊涂账。规则本身不复杂，通常就是变音符号怎么处理、大小写怎么统一、词形归到哪一个形态这三条。 对齐写法时有一个容易漏掉的环节，就是数字和单位的写法，不同语言里小数点、千分位、单位缩写的习惯都不一样，这批词最容易被当成不同的需求。 ## 用相对权重代替绝对搜索量 三份数据的量纲完全不同，没法直接相加。 站内日志是次数，语料库是频率，建议列表连数字都没有。 解决办法是各自转成排名，再合成一个相对权重。 比如每份清单内部按名次给分，前十名十分，十一到五十名五分，其余一分。 三份分数相加，得到一个粗糙但可用的优先级。 这个分数不是搜索量，也别对外称它是搜索量。 它的用途只有一个，就是决定先做哪些词。做决策需要的是顺序，不是数值，把这一点想清楚，缺少绝对搜索量这件事就没那么可怕了。把关键词研究升级成搜索需求建模 (https://zhangwenbao.com/keyword-research-search-demand-modeling-opportunity-allocation.html)那篇讲的也是同一个转变，从要一个数变成要一个排序。 相对权重还有一个好处，它天然是可比的，不同语种之间虽然搜索量不能直接比，但各自内部的排序可以横向对照，看出品类结构的差异。 ## 三份都出现的词优先做 合并之后有一个很好用的信号：交叉出现。 一个词如果在三份清单里都出现了，它几乎肯定是真实需求。 三份数据的来源和偏差方向完全不同，同时出错的概率极低。 只在一份里出现的词则需要警惕，可能是这份数据源特有的噪音。 比如只在语料库里出现的词，可能是书面语里常见但没人搜的说法。 只在站内日志里出现的词，可能是你自己的用户群特有的叫法。 实际操作时可以定一条很简单的规则：三份都有的进第一批，两份有的进第二批，一份有的先放着等验证。第一批的词量通常不多，但它们的确定性最高，先把这批做完，市场会给你更多数据来判断后面两批。 反过来也要留意，三份数据都覆盖不到的领域会出现集体盲区，比如很新的产品概念，这时候交叉验证不但没用，还会让你系统性地低估它。 ## 给每个词标一个置信度 词表交付时最好带一列置信度。 标注依据就是它在几份数据里出现过、来源分别是什么。 高置信度的词可以直接立项做页面。 中等置信度的词先写进已有页面的正文，观察表现。 低置信度的词只留在表里，不投入任何资源。 这样一张表既能指导执行，又能记录不确定性。 带置信度的词表还有个管理上的好处，它让后续的复盘变得可能。三个月后回头看，高置信度的词有没有兑现、低置信度的词有没有冒头，这些反馈能直接用来调整下一轮的判断标准，方法本身会越用越准。 置信度这一列在跟外部供应商合作时特别有用，把低置信度的词单独列出来，明确说明这批词是待验证的，能避免对方按同样的标准报价和交付。 置信度的档位不要分太细，三档就够，分成五档六档之后，判断本身的误差已经大于档位之间的差距，反而制造出虚假的精确感。 ## 怎么验证这些估算不是自己骗自己？ ## 拿一批已知量的词当刻度 校准的思路是找一组两边都有数据的词。 在目标语种里挑二三十个工具确实有数据的常见词。 用你那套土办法给这些词也算一个相对权重。 然后看两列数字的排序是不是大致吻合。 吻合度高，说明这套方法在这个语种上靠谱。 吻合度差，说明某一条数据源有系统性偏差，得回头查。 这个校准做一次就够，但一定要做。它花的时间不超过两小时，换来的是对整套估算的信心，而没有这份信心的话，后面每一次立项讨论都会重新回到这个数准不准的争论上，那个消耗比两小时大得多。 校准时如果发现某一条数据源整体偏离，别急着丢掉它，先看是不是可以加一个修正系数，多数情况下偏差是系统性的，修正之后仍然可用。 ## 上线一组页面做小规模实测 最直接的验证是真做几个页面出来。 挑五到十个高置信度的词，各做一个页面。 不追求完美，能上线、能被抓到、能进索引就行。 四到八周后看展现量，跟当初的估算排序对比。 排序基本对得上，整张词表就可以放心执行。 对不上的地方，往往能看出方法在哪一类词上会失准。 选实验词有个讲究，要覆盖不同的意图类型和不同的置信度档位，别全挑最有把握的那几个。全挑有把握的等于没验证，实验的价值在于暴露方法的边界，而边界只在不确定的地方才看得见。 实验页面还要控制一个变量，就是别在同一时间对站点做其他大改动，否则展现量的变化说不清是词选对了还是别的因素在起作用。 ## 三个月后的回归检查 第三步是把这件事变成常态。 页面上线三个月后，站长工具里已经积累了真实的查询数据。 这时候拿真实查询回头修正当初的词表。 会看到三类结果：估准的、估高的、完全没想到的。 第三类最有价值，它是市场自己给出的新种子词。 把它们喂回第一条路，整个循环就闭上了。 这个循环建议按季度跑，跑三轮之后你对这个语种的判断会比任何工具都准。到那时词表已经不再依赖外部数据源，而是建立在自己站点的真实反馈上，这是小语种市场里唯一可靠的护城河。 回归检查时建议把当初的估算和实际结果放在一张表里存档，几轮下来这张表本身就成了这个市场的知识资产，比任何外部报告都值钱。 ## 广告数据能不能拿来补？ ## 小预算跑一轮广撒的曝光 付费搜索有个副作用是很好的数据来源。 用宽泛匹配把整张候选词表投出去，预算给到最低。 跑两三周，看搜索词报告里实际触发了哪些查询。 这份报告是真实查询，不是推算，也不受展示阈值限制。 它还会带出一批你完全没想到的说法。 花几百块钱买到的这份数据，质量高于任何免费方法。 要注意的是投放设置得放宽，匹配方式、地域、时段都别限制太死，目的不是转化而是采集。这跟正常投放的思路正好相反，所以最好单独开一个广告系列，别跟正在跑效果的系列混在一起，否则两个目标会互相干扰。 广撒采集还有一个隐藏价值，它能顺带测出这个市场的竞争密度，哪些词有大量广告主在抢、哪些词几乎没人投，这个信息在自然搜索的排期上同样有用。 跑广撒的时候记得把否定词表准备好，不然大量无关流量会稀释掉真正有用的那部分查询，采集效率会低很多。 ## 曝光量跟自然搜索量的换算关系 广告的曝光量不等于搜索量，但存在稳定的比例。 这个比例取决于你的出价、质量得分和竞争密度。 做法是在同一个账户里，拿几个已知搜索量的词做参照。 算出它们的曝光量与搜索量之比，得到一个粗略系数。 再用这个系数去推算那些没有数据的词。 误差不小，但比零这个答案有用得多。 用这个系数时要限定在同一个语种、同一个品类、同一段时间内，跨语种套用会错得离谱，因为竞争密度差异极大。系数本身也要定期重算，广告市场的竞争状况变了，比例关系跟着变。 换算系数算出来之后，建议标注它对应的出价档位，因为出价一变比例就变，把系数和出价绑在一起记，下次复用时才不会张冠李戴。 ## 什么时候不值得花这笔钱 广撒采集不是所有情况都划算。 如果这个语种在广告平台上本身就没什么广告主，触发量会低到没有统计意义。 如果品类的单次点击成本很高，即使限制预算也可能烧得很快。 如果这个市场的主流搜索引擎不是你要投的这个，采到的样本代表性存疑。 三种情况下，还是回到前面三条免费的路更实际。 判断只需要一步，先小额跑三天看触发量够不够。 还有一种情况值得单独说，就是团队里没人能读懂搜索词报告里那些查询的意思。采回来一堆看不懂的词，等于没采。这时候要么先解决语言支持，要么把这笔预算留到有母语者能一起看报告的时候再花。 这一步也可以换个思路，如果广告平台在这个语种上确实没数据，那就把预算转到当地最大的电商平台做站内推广，那里的搜索词报告同样是真实查询。 ## 这套方法在哪些语种会失效？ ## 语料极稀的语种 方法的三条腿里，有两条依赖已有文本或已有流量。 如果目标语种的网页存量本身就极少，语料库那条路会直接断掉。 判断办法是看这个语种在大规模网页语言统计里的占比。 占比低于千分之一的语种，语料资源基本处于凑合能用的状态。 这时候能依靠的主要是搜索建议和广告采集。 它们不依赖文本存量，只依赖有没有人在搜。 这类语种还有一个替代思路，去看邻近的大语种。很多小语种市场的用户在找不到本地语言内容时会切换到邻国的大语种去搜，这部分需求在本地语种的数据里完全看不到，但它是真实存在的市场，做内容时可以同时覆盖两种语言。 判断某个语种的网页存量还有个更粗的办法，用当地语言搜几个通用品类词，看结果页有多少是本地语言的原创内容，占比低说明内容供给不足，也意味着机会。 ## 口语和方言主导的市场 有些市场的书面标准语和日常口语差得很远。 阿拉伯语世界是典型，各地方言与标准语在词汇上分歧很大。 语料库收的多半是标准语，而用户搜的是方言说法。 这种错位会让语料库那条路给出完全误导的排序。 补救办法是把社交平台和论坛的文本单独当一份来源。 那里的语言更接近人们真正在打的字。 这类市场里搜索建议的权重要调到最高，因为它是唯一一个天然记录口语形态的来源。标准阿拉伯语和方言之间怎么选词 (https://zhangwenbao.com/arabic-seo-rtl-layout-msa-dialect-keyword.html)那篇里的分层办法，可以直接搬到任何存在双层语体的市场。 双层语体的市场还要注意书面语和口语的比例会随品类变化，专业和高价品类偏书面语，日用和快消偏口语，同一个市场里两种倾向可能同时存在。 口语主导的市场里还要留意书写的随意性，同一个口语词可能有好几种拼法在流通，收词时得把这些拼法都当成同一个需求处理。 ## 搜索份额不在同一个引擎上的市场 方法里有几步默认了用户在某一个搜索引擎上搜。 但有些市场的份额分布完全不同。 在那些市场里，采到的建议列表和广告数据只覆盖了一部分用户。 正确做法是在当地份额最高的引擎上重跑一遍采集。 不同引擎的建议算法不同，采出来的词也会有差异。 这部分属于引擎层的功课，跟语言层是两件事。 本篇讲的是语言本身带来的统计难题，至于某个引擎的关键词工具怎么用、它的数据口径跟别家差在哪儿，站内的多引擎系列里有专门的篇目，这里就不重复了。两边的方法可以叠加使用，互相之间没有冲突。 跨引擎采集时可以做一次对比，看两个引擎的建议列表重合度有多高，重合度低说明用户群体差异明显，那两套词表就不能合并使用。 ## 一份可以照抄的两周执行表 ## 第一周：三条路各自出一份清单 第一天到第二天，导出站内搜索日志和站长工具的查询数据。 第三天，把无结果查询和高展现低点击的查询挑出来当种子。 第四天，在语料检索平台上跑种子词的词频和搭配。 第五天到第六天，做搜索建议的逐字母采集。 第七天，三份清单各自去重，整理成统一格式。 这一周的产出是三份原始清单，不做任何合并。 把合并推迟到第二周是有意的，因为三份清单在整理阶段最容易受先入为主的影响。先各自跑完再合并，能保住三个来源的独立性，而独立性正是后面交叉验证的前提。 第一周还有一件小事值得顺手做完，就是把这个语种的字母表、常见变音符号和词形规则整理成一页速查表，后面每一步都会用到它。 ## 第二周：合并、验证与交付 第八天，定规范形态，把三份清单映射到同一套写法上。 第九天，做相对权重计算和交叉出现标注。 第十天，拿已知量的词做一次刻度校准。 第十一天，给每个词标置信度，分成三批。 第十二天，挑五到十个词做实验页面的选题。 第十三、十四天，写交付文档，把方法和规则一起写进去。 交付文档里最重要的不是词表本身，而是那份写法规范和权重规则。词表会过期，规则不会。半年后换了人来做，有规则在，新一轮的产出跟这一轮就是可比的，没有规则的话又得从头吵一遍。 第二周的最后要留出半天做一次通读，把明显不像人话的词剔掉，这一步靠的是常识而不是数据，但它挡掉的往往是最尴尬的那批错误。 第二周如果时间紧，可以把刻度校准这一步往后放，但写法规范和交叉标注这两件事不能省，它们决定了这份词表能不能被第二个人接手。 ## 谁来做，怎么验收 这套流程不需要资深的人全程投入。 数据导出和采集部分，实习生按文档就能完成。 需要经验的是两处：定规范形态和判断词的意图。 这两处各需要半天，最好由熟悉这个市场的人来做。 母语者的参与集中在最后的词表复核上，两三个小时足够。 整个两周的实际人力投入，大概是一个人周多一点。 验收标准建议定成三条：词表里每个词都能追溯到至少一个数据来源、写法规范文档存在且可执行、实验页面的选题已确定并排期。三条都满足就算交付完成，别把有没有搜索量数字当验收标准，那正是这套方法从一开始就放弃的东西。 交付之后建议约一个月后的回看会，那时候第一批实验页面已经有初步数据，团队对这套方法的信任度会在那次会上真正建立起来。 ## 常见问题解答 ## 关键词工具在小语种上完全不能用吗 不是不能用，是不能单独用。工具在小语种上仍然有三个不可替代的作用。第一是给出大盘的量级参照，虽然具体词的数字不准，但品类之间的相对规模通常还是对的，用来判断整个市场值不值得进是够用的。第二是提供词的形态变体建议，很多工具会列出它见过的拼写变体，这份清单对于变音符号和词形处理很有参考价值。第三是竞争度和出价数据，这两项来自广告侧，跟自然搜索量的采样问题不完全是一回事，可靠度相对高一些。真正不能用的是把某个具体词的搜索量数字当作决策依据，尤其是当那个数字是零的时候。正确的用法是把工具当作三条土办法之外的第四份数据，跟其他三份放在一起做交叉验证，而不是让它一票否决。还有一点要提醒，不同工具在同一个小语种上的数据可能差好几倍，如果条件允许，多查一两个工具，看它们之间的分歧有多大，分歧大本身就说明这个语种的数据不可信。还有一个实用习惯，把每次查询的日期和工具版本记在词表旁边，工具的数据源会悄悄更换，隔半年拿到的数字对不上时，这行备注能省掉很多无谓的追查。 ## 站内搜索日志量太小怎么办 量小的日志依然有用，只是用法要变。量大的时候你可以看分布、算占比、排优先级；量小的时候只能看有没有，也就是把它当成一份存在性证据而不是统计样本。具体做法是把所有出现过的查询都保留下来，哪怕只出现过一次，然后重点看那些用词跟你的预期不一致的条目。哪怕只有一条，只要它用的说法跟你词表里的不同，就值得追查。另一个思路是延长时间窗口，把一年甚至两年的日志合起来看，小站点的日志按季度看可能只有几十条，按年看就有几百条了。还有一个补充来源是竞品站的站内搜索，很多站的搜索结果页地址里带着查询词，而这些页面有时会被搜索引擎收录，用站点搜索的方式去查竞品域名下的搜索结果页，能捞到一批真实查询。最后，如果站点刚上线完全没有日志，那就跳过这条路，先用搜索建议和语料库做出第一版词表，等三个月后有了流量再回来补这一环。这三条路本来就不要求同时可用。另外提醒一句，日志导出要连同语言和地区字段一起导，多市场共用一个站点的时候，不分开看的话几个市场的用词会混成一团，反而误导判断。 ## 没有母语者的情况下能做到什么程度 能做到七成，剩下三成会有系统性风险。可以做的部分包括：数据导出、逐字母采集、语料库查询、相对权重计算，这些都是机械操作，不需要语言能力。做不了的部分是判断一个词的意图和自然度。同一个词在这门语言里是正式用语还是口语、有没有歧义、母语者会不会那么说，这些没有母语者几乎无法判断，而判断错了会让整批内容看起来像机器翻译的。折中办法有三个。第一是用搭配分析代替语感，母语者常用的搭配会在语料库里显示出来，机器能算出这个。第二是拿搜索结果页当验证，把候选词搜一下，看排在前面的本地页面标题里是不是也用这个说法，如果排前面的都不用，那这个词很可能不自然。第三是找当地的自由译者做一次性的词表复核，几百个词的复核通常只要几个小时的费用，这笔钱在整个项目里占比极小却能挡住最大的风险。完全不做复核也不是不行，但要接受一定比例的词是废的，并且在第一轮实测数据回来之后及时清理。退一步讲，即使完全没有母语者参与，把词表里每个词的搜索结果页截图存档，也能让后来接手的人有据可查，判断错了至少能追溯到当初依据的是什么。 ## 逐字母采集搜索建议会不会被限制 会，所以要控制节奏。手工做的时候基本不会触发任何限制，一个下午跑几百次查询在正常使用范围内。写脚本批量跑就要注意了，请求频率过高会被要求验证，严重的会临时封掉出口地址。控制方法有几条：把请求间隔拉到两秒以上、总量控制在每天几百次以内、不要并发。真正需要大规模采集时，正确的做法不是想办法绕过限制，而是重新审视需求，通常几百个真实建议已经足够做出一版词表，追求上万条的完整性对决策没有额外帮助。另外提醒一点，采集到的建议列表要标注采集日期，因为它反映的是当下的分布，几个月后再用就不准了。如果需要长期跟踪某个品类的建议变化，与其一次采很多，不如每月固定采一小批，形成时间序列，那份数据的价值比一次性的大批量采集高得多。还有一个替代方案是用当地大型电商平台的站内搜索建议，那里的建议同样来自真实输入，而且商业意图更强，限制也更宽松。采集脚本还要处理一个细节，建议列表里经常混着拼写纠正后的结果，那些不是用户实际打的字，收进词表前得先跟原始前缀比对一遍。 ## 相对权重能不能拿去跟老板汇报 能，但要换一种表述方式。别说这个词的搜索量是多少，说这批词按需求强度排在前面。汇报的重点从数字转到排序和依据上，具体做法是给出三样东西：词表的优先级分档、每一档的判断依据、以及验证计划。老板真正关心的是钱该往哪儿投、什么时候能看到结果，这两个问题用排序和排期就能回答，不需要绝对数字。如果对方坚持要一个量级的数字，可以给一个带范围的估计，同时明确说明它的来源和误差，比如按已知词的比例推算，这批词的月搜索量大致在某个区间。给范围比给一个假装精确的数字诚实得多，也更经得起后面的检验。还有一个沟通技巧是把对比对象换掉，不要跟英语市场的搜索量比，那个比法会让任何小语种市场都显得不值得做，改成跟这个市场自己的其他品类比，或者跟竞品在这个市场的表现比，决策的语境才是对的。最后，如果公司内部对数据的要求确实很刚性，那就把广告采集那一步做上，它产出的是平台官方的真实查询数据，在汇报场景里的可信度最高。汇报时还有个小技巧，把这套方法的成本一并说清楚，两周一个人的投入换一个市场的词表，这个性价比本身就是支持立项的理由之一。 ## 做出来的词表多久要更新一次 按季度更新是合理的节奏，但更新的内容分两层。第一层是增量更新，把这个季度站长工具里新出现的查询、站内搜索的新词、客服反馈的新说法加进来，这一层每季度做一次，工作量很小，半天就能完成。第二层是方法层面的复核，也就是重新跑一遍三条路的采集，检查各来源的可用性有没有变化，这一层一年做一次就够。有三种情况需要打破节奏立刻更新：上了新品类、市场上出现了新的竞争者或新的品类叫法、以及搜索引擎在这个市场的份额发生明显变化。前两种会带来新词，第三种会让采集来源的代表性失效。还有一个容易忽略的触发点是当地语言本身的变化，比如正字法改革或者某个外来词被正式收进词典，这类事件不常发生，但一发生就会改变一批词的规范写法。判断要不要立刻重跑的标准很简单：这次变化会不会改变词表里超过一成的条目，会就重跑，不会就等下个季度。更新词表时顺手做一次淘汰，把连续两个季度没有任何展现的词标灰，词表只增不减的话，两年后它会膨胀到没人愿意打开的程度。 ## 这套方法能不能用在已经有数据的大语种上 可以，而且往往能挖出工具漏掉的那部分。大语种上工具的数据足够准，所以没人会去做这些额外的功课，但三条路里至少有两条在大语种上同样有效。站内搜索日志反映的是你自己用户的真实说法，这一点跟语种大小无关，任何市场都值得看。搜索建议的时效性优势在大语种上同样成立，尤其是季节性和突发性需求，工具的月均值总是滞后的。相对失效的是语料库那条路，因为大语种上有更精确的搜索量数据可用，用词频排序反而是退步。所以在大语种上的正确用法是把这套方法当作补充而不是替代，重点放在挖掘工具覆盖不到的长尾和新词上。有一个具体场景特别值得用，就是新品类刚出现的时候，那时候工具还没积累到数据，跟小语种的处境完全一样，这套方法能让你比竞争对手早几个月看到需求。反过来说，这也解释了为什么在小语种市场里练熟这套方法是有长期价值的，它的适用范围比想象中宽得多。把这套方法在大语种上练一遍还有个额外好处，那时候有准确数据可以对照，你能清楚地知道自己的估算偏差有多大，这份自知在小语种市场里非常值钱。 ## 权威参考资料 ## 保加利亚语和塞尔维亚语SEO，用哪套字母写商品名比写了什么更决定谁能搜到 - URL：https://zhangwenbao.com/bulgarian-serbian-seo-cyrillic-latin-dual-script.html - 分类：小语种SEO - 发布：2016-07-06 | 更新：2026-07-26 - 摘要：保加利亚语与塞尔维亚语SEO实战：一个是两套官方正字法要做两份内容，一个是西里尔加法定转写只管URL。给出与希腊语、越南语双形态的区别、二合字母回转歧义与同形混淆的处理。 - 关键词：SEO,小语种SEO,书写系统 > **TLDR**：摘要：这两个市场常被打包成一句巴尔干西里尔就完事，实际上它们的字母问题根本不是同一类。塞尔维亚语的西里尔和拉丁都是官方正字法，三十个字母一一对应完全可逆，做内容要真做两份；保加利亚语只有西里尔是正字，拉丁写法由一部法律规定，只管URL和品牌名就够。这篇把两者拆开，再跟希腊语的转写、越南语的带调不带调划清界线。 > 摘要：这两个市场常被打包成一句巴尔干西里尔就完事，实际上它们的字母问题根本不是同一类。塞尔维亚语的西里尔和拉丁都是官方正字法，三十个字母一一对应完全可逆，做内容要真做两份；保加利亚语只有西里尔是正字，拉丁写法由一部法律规定，只管URL和品牌名就够。这篇把两者拆开，再跟希腊语的转写、越南语的带调不带调划清界线。 ## 为什么这两个市场不能打包成一句巴尔干西里尔？ 做区域市场规划时，很容易把巴尔干几个国家放进同一个格子里。 都用西里尔字母、都是斯拉夫语、市场规模都不大，看起来完全可以共用一套方案。 接手一个做运动营养的站时，我也是这么估的，结果两边的工作量差了将近三倍。 差别的根源只有一句话：塞尔维亚语的拉丁写法是官方正字法，保加利亚语的拉丁写法不是。 这一个字的差别，往下推出来的是完全不同的内容策略、URL策略和预算分配。 把它们放在同一篇里讲，不是因为它们像，恰恰是因为它们最容易被误当成一回事。 顺带把另外几个邻国也划清楚：克罗地亚和斯洛文尼亚只用拉丁字母，北马其顿用西里尔但字母表又跟这两家都不同，巴尔干这个地理概念在字符这一层几乎没有任何统一性。 所以区域规划表里最好别写巴尔干这一行，直接按语言逐个列，看着啰嗦但能避免后面所有的连锁误判。 ## 塞尔维亚语的两套字母是什么关系？ 塞尔维亚语有两套官方书写系统，西里尔字母和拉丁字母，两套都写在正字法里。 西里尔那套有三十个字母，拉丁那套也是三十个，一一对应，没有多也没有少。 这个设计不是历史巧合，是十九世纪语言改革时刻意做成的：一个音一个字母，两套系统严格对齐。 所以从一套转到另一套，理论上是纯机械的字符替换，不需要理解语义。 这一点跟世界上大多数双书写系统都不一样，它是塞尔维亚语最独特的地方。 也正因为可逆，很多团队会以为转写脚本一跑就完事，后面会讲这个假设在哪儿破功。 这套一一对应关系还有个副产品：塞尔维亚语的拼写几乎完全表音，你听到一个词就能写出来，这让本地用户对拼写错误的容忍度比英语市场低得多。 ## 保加利亚语的拉丁写法又是什么关系？ 保加利亚语只有西里尔一套正字法，拉丁写法不是另一套书写系统，而是转写。 转写的目的是把西里尔文本表示成拉丁字符，用在护照、地名标牌、域名和URL这些地方。 它不是给保加利亚人读的，是给系统和外国人用的。 所以你不需要为保加利亚语准备两份内容，只需要一套规范的西里尔内容，加一套正确的转写规则。 这个区别在预算上是决定性的：塞尔维亚语的内容成本接近翻倍，保加利亚语几乎不增加。 把两者混为一谈的代价，要么是给保加利亚市场白做了一份没人看的拉丁内容，要么是给塞尔维亚市场少做了一半。 判断一门语言的第二套写法是正字法还是转写，有个简单的问题可以问：本地报纸和教科书会不会用它印刷。会就是正字法，不会就是转写。 ## 这跟希腊语的转写、越南语的带调不带调差在哪？ 同一个概念在小语种里出现过好几次，但每次的性质都不一样，混在一起想必然出错。 希腊语的情况是正字法加一套非正式转写，转写没有标准、一对多，同一个字母能写成好几种拉丁形式。 越南语的情况是完整正字法加剥掉记号的简化写法，剥掉之后是有损的，还会撞到别的词上去。 情形 | 两套形态的关系 | 规范地位 | 处理成本 | 希腊语与拉丁转写 | 无标准转写，一对多 | 只有一套是正字法 | 做变体覆盖 | 越南语带调与不带调 | 有损简化，会撞词 | 只有一套是正字法 | 做双轨覆盖 | 保加利亚语与拉丁转写 | 有法定标准，接近一对一 | 只有一套是正字法 | 只管URL与品牌名 | 塞尔维亚语两套字母 | 三十对三十完全可逆 | 两套都是正字法 | 真做两份内容 | 希腊语那半边的具体做法我在希腊语那篇 (https://zhangwenbao.com/greek-seo-greeklish-latin-transliteration-coverage.html)里拆过，越南语那半边在越南语那篇 (https://zhangwenbao.com/vietnamese-seo-tone-marks-syllable-spacing-keyword.html)里。 四种情形里只有塞尔维亚语需要真做两份内容，这是判断预算的最关键一条。 这张表也可以当成一个通用判据用在别的语言上：先问两套形态是不是都被官方承认，再问它们之间的映射是不是可逆，两个答案就能定出处理成本的档位。 ## 塞语的三十对三十，为什么说完全可逆？ 西里尔的每个字母在拉丁那套里都有唯一对应，反过来也一样。 大部分是一对一的单字符映射，比如西里尔的第一个字母对应拉丁的a。 少数几个西里尔字母对应的是两个拉丁字符组成的二合字母。 正是这几个二合字母，让完全可逆这个说法在实际操作里出了一个缺口。 从西里尔转到拉丁始终是安全的，因为源头每个字母都是单一符号。 从拉丁转回西里尔就不一定了，这是下一节要拆的问题。 值得一提的是，这套对齐关系是十九世纪一次自上而下的语言改革刻意做出来的，改革者的原则就是一个音一个字母，所以这门语言几乎没有历史拼写包袱。 ## 二合字母回转时会产生歧义吗？ 会，而且这是塞尔维亚语字符处理上最硬核的一个坑。 拉丁那套里有三个二合字母，它们各自对应一个西里尔字母。 问题是：这两个拉丁字符也可能是两个独立字母碰巧挨在了一起。 比如一个由前缀加词根构成的词，前缀末尾是d，词根开头是ž，拼在一起就出现了dž这个组合。 自动转写脚本看到dž就会转成对应的那个西里尔字母，而正确答案是两个独立的西里尔字母。 结果是这个词被转错了，而且错得很隐蔽，因为转出来的字符串看着是个合法的词形。 这类问题在语言学上叫词界歧义，它在任何一个用多字符表示单个音位的书写系统里都会出现，只是塞尔维亚语因为两套字母互转的场景太频繁，暴露得格外明显。 ## 哪些词会在自动转写时被转坏？ 受影响的主要是三类词：带某些前缀的派生词、复合词的接合处、以及部分外来词。 这三类词在运动营养这种品类里出现得不少，因为很多成分名和功效描述都是派生词。 解决办法不是改算法，算法本身没法从字符串判断这是不是一个词界。 正确做法是维护一张例外词表，转写时先查表，表里没有的才走通用规则。 例外表通常几百行，公开的语言资源里能找到大部分，剩下的靠本地同事补。 这一步做不做，直接决定你的西里尔版内容是不是有一批词是错的。 实际操作里可以先跑一遍全量转换，把所有含这三个组合的词单独导出来，人工过一遍，这批词的数量通常比想象中少，一次能筛完。 ## 塞语用户到底用哪套字母？分场景看 拉丁字母在日常网络使用中占优势，尤其是在手机和社交媒体上。 西里尔在官方文件、教育、传统媒体和正式场合里占优势。 年龄是个变量但不是决定性的，场景的影响比年龄大。 更实际的观察是：同一个人在同一天里两套都会用，取决于他在哪个应用里打字。 搜索这个场景整体偏向拉丁，因为输入法切换成本低，而且很多设备的默认布局就是拉丁。 但这不代表西里尔可以不做，官方类、健康类、以及年长用户占比高的查询，西里尔的比重明显更高。 还有一个容易被忽略的场景：纸质包装、门店招牌、发票和快递单上的字母选择往往跟线上不一致，做全渠道品牌时这两侧要单独确认，别默认它们一致。 ## 两套字母的内容算不算重复内容？ 不算，但你得让搜索引擎知道它们是同一份内容的两种书写形式。 两个页面的字符串完全不同，机器不会自动判断它们是同一个东西。 处理的核心是页面级的关系声明，把两个版本互相指认清楚。 这属于多语言站的架构层问题，不是塞尔维亚语这门语言特有的，所以这篇不展开讲配置细节。 要注意的是：塞语的两套字母在语言标签上不是两种语言，而是同一种语言的两种文字。 标签写法上要用文字子标签而不是另起一个语言代码，写错了搜索引擎会当成两个不相干的页面。 另外要提醒的是，两个版本的更新必须同步，一版改了另一版没改，时间一长内容就会出现事实性冲突，这类问题排查起来非常费劲。 ## 一个页面两套字母，URL该怎么排？ 最常见的做法是用路径前缀区分，两套内容各占一个目录。 URL里的slug一律用拉丁字符，哪怕是西里尔版的页面也一样。 原因很简单：西里尔URL在复制粘贴、外链引用和分享时会变成一长串百分号编码。 这一点跟其他非拉丁语言市场的结论一致，可读性上的损失大于本地化上的收益。 路径前缀之外别再叠加其他区分方式，多一层就多一批要维护的重定向。 决定用哪套目录做主版本时，看你的品类偏向哪个场景，运动营养这类偏日常消费的，拉丁做主更合理。 还有一个实操细节：西里尔版页面的slug用拉丁字符时，要从西里尔原文按转写规则生成，而不是直接复制拉丁版页面的slug，否则两版的URL语义会对不上。 ## 塞语站的字母切换器该放在哪一层？ 切换器要放在全局导航里，而且要在首屏可见的位置。 切换后要保持在当前页面，不能一律跳回首页，这是最常见的实现错误。 用户的选择要记住，下次访问直接进他上次选的那套。 记住的方式不要用IP判断，塞尔维亚境内两套都在用，按地理位置猜必错。 切换器本身的文案要两套字母各写一遍，让用户一眼看出点过去会变成什么。 这个组件看着简单，但它是塞语站唯一一个所有用户都会注意到的本地化细节。 记住用户选择时建议用长期有效的存储而不是会话级的，因为塞语用户切换字母的行为是一次性的偏好设定，不是每次访问都要重来一遍的操作。 ## 保加利亚语的转写为什么是一部法律规定的？ 2009年保加利亚通过了一部专门规范拉丁转写的法律，这在世界范围内都不多见。 立法的动机很实际：护照、身份证、路牌、地图上的地名拼写必须全国统一。 在这之前，同一个地名在不同文件上能拼出三四种拉丁写法，出国办事经常出问题。 法律颁布之后，转写规则就不再是风格选择，而是一条有明确答案的规范。 对做站的人来说，这意味着URL和品牌名的拉丁写法有唯一正确答案，不需要自己发明。 照着法定规则走，你的地名和商品名的拉丁写法就和政府文件、地图、导航软件全部对齐。 这部法律还有一个附带好处：它让保加利亚语的地名转写在地图服务、导航软件和政府数据之间保持一致，做本地业务时的地址匹配率因此高出不少。 ## 法定转写表里哪几条最容易写错？ 最容易错的是几个复合音字母，它们转写成两三个拉丁字符。 其中一个转成ts，一个转成ch，一个转成sh，还有一个转成四个字符的sht。 另外两个元音转成yu和ya，这两条经常被通用音译库转成别的写法。 最特别的一条在下一节讲：那个被很多人误以为是硬音符号的字母。 通用音译库的默认规则大多是按俄语设计的，直接用在保加利亚语上有好几条对不上。 所以别用现成库的默认配置，按法定表写死一份映射，几十行代码的事。 检验自己的转写模块最快的办法是拿几个知名城市名跑一遍，跟护照上或者路牌上的官方拼写对一下，错了会立刻显出来。 ## ъ 在保加利亚语里是元音，不是硬音符号 这条是同类文章几乎不会讲、但一定会踩的坑。 在俄语里，这个字母是个不发音的符号，只起分隔作用，出现频率极低。 在保加利亚语里，它是一个正儿八经的元音，读出来有音，而且出现频率相当高。 连国名本身都含这个字母，它在词的中间，不是什么边缘符号。 法定转写把它转成a，这一条按俄语规则处理的库全都会转错。 俄语的字母与词形处理我在俄语那篇 (https://zhangwenbao.com/russian-seo-cyrillic-cases-declension-wordstat-keyword.html)里讲过，但这一条恰恰是不能从俄语搬过来的。 这个字母还带来一个连锁影响：按俄语字符集裁剪的字体子集有时候会把它当低频字符剔掉，结果保加利亚语页面上出现一批缺字形的方框。 ## 保语的拉丁写法用在哪些地方？ URL的slug，这是最主要的用途。 品牌名和公司名的拉丁形式，用在国际业务和跨境支付场景。 地址表单里的城市和街道名，用户填英文地址时会用到。 除此之外，页面上的正文、标题、元描述一律用西里尔，不要做拉丁版本。 做了也没人搜，保加利亚用户几乎不会用拉丁字符搜索本国语言的内容。 这跟塞尔维亚语的情况完全相反，两个市场在这一点上正好走到了两个极端。 如果你的站上有用户生成内容，还要考虑一种情况：少数用户会用拉丁字符打保加利亚语，这属于非规范输入，做检索兼容即可，不必为它产出内容。 ## 保加利亚语没有格，但有后置定冠词 斯拉夫语族普遍有复杂的格系统，俄语六个，波兰语七个。 保加利亚语是个例外，名词的格系统几乎完全消失了，这在斯拉夫语里相当罕见。 但它同时长出了另一样东西：定冠词接在名词词尾，跟词根粘成一个词。 这个特征跟罗马尼亚语那篇 (https://zhangwenbao.com/romanian-seo-postposed-definite-article-comma-diacritics.html)里讲的后置定冠词是同一回事，两门语言的亲缘关系其实很远。 它们共享这个特征，是因为长期相邻形成的巴尔干语言联盟，属于接触带来的趋同。 所以处理保加利亚语词形时，可以直接借用罗马尼亚语那套后置冠词的思路，比套俄语的格系统对路得多。 巴尔干语言联盟这个概念在做区域市场时其实挺有用：它能提前告诉你哪些语法特征会跨语言重复出现，处理方案可以在几个市场之间复用。 ## 后置定冠词让前缀匹配失效在哪一步？ 用户打的是带定冠词的形态，而你的索引里存的是不带冠词的原形。 带冠词的形态比原形长，所以原形不是它的前缀，前缀匹配的方向是反的。 结果就是站内搜索命中率莫名其妙地低，而前端和索引配置怎么查都是对的。 补救的办法是接一层词尾归并，把定冠词剥掉再匹配。 没有格系统这一点在这里反而是好消息：要剥的东西比俄语少得多。 所以保加利亚语的站内搜索改造，工作量比俄语站小一大截。 顺带说一句，这个坑在自动补全上表现得比在搜索结果上更明显，因为自动补全几乎全部依赖前缀匹配，一个字都不差地按前缀走。 ## 保加利亚语的定冠词还分几种形式？ 阳性名词的定冠词有两个形式，一个用在主语位置，一个用在其他位置。 这是格系统消失后留下的最后一点残余，只在阳性单数上还看得见。 口语里这个区分正在弱化，很多人两种混用，书面语里仍然要求严格。 对搜索的影响不大，因为商品名很少出现在需要区分的句法位置上。 但正文和文案里写错了，本地读者是能看出来的。 阴性和中性名词没有这个区分，一个形式走天下。 做内容时可以立一条简单规则：标题和商品名一律用不带冠词的原形，需要带冠词的自然表达只出现在正文里，这样既避开了形式选择的问题，也保住了检索形态。 ## 保语的动词形态有多复杂？转述式是怎么回事 名词那边简单了，动词那边补回来了，而且补得很多。 保加利亚语的动词有一套专门用来转述别人说法的形态，语法书叫转述式。 意思是：当你说的事情不是自己亲眼见的，而是听说的，动词要换一套形式。 这在欧洲语言里很少见，它把信息来源直接编码进了动词里。 做内容时的实际影响是：引用第三方数据、转述研究结论、写用户评价摘要时，动词要用转述式。 用错了不影响排名，但读起来像是你在把听来的事情当亲身经历讲，可信度反而降低。 这套形态还有一个衍生用途：产品功效类的表述用转述式来写，语气上会显得更谨慎，在健康类内容上反而更符合本地读者对可信度的预期。 ## 塞语的依格切与埃格切：比字母更深的一层分叉 这是塞尔维亚语里比字母选择更深、也更容易被忽略的一层差别。 同一个词根在两种发音传统里有两种写法，一种写得短，一种中间多两个字母。 牛奶、河流、时间这类基础词全在名单上，覆盖面相当广。 塞尔维亚本土主要用短的那种，波黑、黑山、克罗地亚主要用长的那种。 换句话说，字母只是一层分叉，发音传统是另一层，两层是正交的。 只做字母转换不处理这一层，你给波黑用户看到的内容会读起来像外地人写的。 这层差别在语音上其实来自同一个古音的两种演变结果，所以它的分布是成体系的，不是零散的例外，整理成替换表之后覆盖率很高。 ## 该按哪一档分市场：塞尔维亚、波黑、黑山、克罗地亚？ 先看非语言字段：货币不同、税制不同、物流不同，这四个是四个独立市场。 再看语言字段：字母偏好不同、发音传统不同、部分词汇不同。 预算有限时的正确顺序是先做塞尔维亚，因为它的市场规模最大、两套字母都要用。 第二档是克罗地亚，它只用拉丁字母，但要换发音传统和一批词汇。 波黑和黑山可以先复用，把差异做成词表覆盖，等到量起来了再单独拆。 这个分档逻辑跟三个以上市场的资产分层是同一类问题，只是这里多了一个字母维度。 还有一个非语言维度值得早点确认：这几个市场的支付习惯差别不小，货到付款的比例在其中几个国家高得超出预期，这会影响落地页的设计重点。 ## 塞语和克罗地亚语算不算一门语言？ 语言学上这个问题争了几十年，两边的看法至今不一致。 从互通度看，说这两门话的人之间几乎没有交流障碍。 从社会语言学和政治认同看，两边都坚持这是各自独立的语言。 做站的人不需要在这个问题上站队，只需要知道一件事：内容不能共用。 克罗地亚市场的用户对内容里出现塞尔维亚特有词汇是敏感的，反过来也一样。 所以判断标准不是语言学上算不算一门语言，是用户认不认这份内容是给自己看的。 实操上有个简单的自查：把你的内容拿给两边的本地同事各看一遍，如果有人说这读着像对面写的，那就说明词汇层还没分干净。 ## 西里尔和拉丁的同形混淆会带来什么风险？ 西里尔字母表里有一批字母，跟拉丁字母长得一模一样。 小写的a、e、o、p、c、x、y在两套字母表里视觉上没有区别，大写的更多。 视觉相同但码位不同，机器看到的是两个完全不同的字符。 混排的直接后果是商品名被切成几段、搜索匹配不上、以及复制粘贴之后搜不到。 更严重的场景是域名和账号名，混排字符是钓鱼域名最常用的手法之一。 UTS #39定义的安全机制 (https://www.unicode.org/reports/tr39/)就是专门处理这类问题的规范，做多字母站点值得完整读一遍。 还有一种更隐蔽的情况：从别处复制过来的商品名里混着不可见的零宽字符或者不同的空格字符，它们在同形混淆之外又加了一层，检测脚本最好一起覆盖。 ## confusables表该怎么用在商品名审核上？ Unicode维护了一份视觉混淆字符对照表 (https://www.unicode.org/Public/security/latest/confusables.txt)，把所有长得像的字符成组列了出来。 拿这份表可以写一个很简单的审核脚本：检测一个字符串里有没有同时出现两套字母表的字符。 混排的情况直接拦下来，让录入的人重新输入。 这个检查在商品导入、用户注册、评论提交三个入口上各加一次，成本很低。 不加的代价是几个月后你的商品库里躺着一批永远搜不到的商品。 保哥见过一个站，某个畅销品的名字里混进了一个拉丁o，站内搜索半年查不到，客服一直以为是缺货。 检测脚本除了拦截，最好还能给出提示：告诉录入的人具体是第几个字符属于另一套字母表，否则他盯着屏幕看半天也找不出问题在哪。 ## 两套字母的排序规则要配几套？ 塞尔维亚语要配两套，西里尔版和拉丁版各一套。 两套的排序顺序在概念上是对齐的，但字符不同，比较规则要分开定义。 保加利亚语只配西里尔一套就够，因为拉丁写法不用于内容展示。 LDML的排序规范 (https://www.unicode.org/reports/tr35/tr35-collation.html)里两门语言的定义都有，指定区域设置就能用。 要注意西里尔字母的顺序在不同语言里并不相同，别拿俄语的顺序去排保加利亚语。 字母集合和顺序都不一样，用错了字母导航的顺序会看着差不多但就是不对。 两套排序规则还带来一个测试上的要求：字母导航的自动化测试要跑两遍，一遍在西里尔模式下，一遍在拉丁模式下，只测一套等于只测了一半。 ## 塞语拉丁的dž、lj、nj排序时算一个字母 拉丁版塞尔维亚语的三个二合字母，排序时各算一个字母，占独立位置。 这个特性跟匈牙利语的多字母字母是同构的，我在匈牙利语那篇 (https://zhangwenbao.com/hungarian-seo-eighteen-cases-vowel-harmony-keyword.html)里拆过它对字母导航的影响。 差别在于匈牙利语有八个这样的字母，塞语拉丁只有三个，工作量小得多。 字母导航的按钮列表里要把这三个加进去，用户才找得到对应词条。 切分逻辑同样要按最长匹配走，先试两字符再落到单字符。 西里尔版没有这个问题，因为它们在西里尔里本来就是单个字母。 字母导航的按钮除了要加这三个，还要注意它们的显示顺序：它们各自排在对应单字母的全部词条之后，而不是紧跟着那个单字母。 ## 保语与塞语的字母集合有什么不同？ 两门语言都用西里尔，但字母表不是同一套。 塞尔维亚语的西里尔有三十个字母，其中六个是塞语特有的，别的西里尔语言里没有。 保加利亚语的西里尔也是三十个，但集合不同，它有塞语没有的几个字母。 反过来，塞语特有的那六个字母在保加利亚语里一个都不用。 Unicode的西里尔码表 (https://www.unicode.org/charts/PDF/U0400.pdf)里能看到这些字母各自的码位，做字符白名单时按语言分开取。 把两门语言的字符集合并成一个大集合，是最省事也最容易出问题的做法。 两套字母集合的差异还会影响一件容易忽略的事：文本相似度和去重算法的字符级比较，跨语言用同一套参数会得出没有意义的结果。 ## 键盘布局、字体子集与正则字符类要怎么分开？ 字符集合不同，往下推出来的是三件具体的事。 字体子集要按语言分别裁剪，否则要么缺字形要么白白多加载几十KB。 正则的字符类不能写成一个笼统的西里尔范围，那会放进一大批两门语言都不用的字符。 输入法和键盘布局的引导文案要分开写，两国用户的默认布局不一样。 这三件事在项目初期定下来，成本几乎为零；等内容铺开了再改，要动的地方非常多。 字体子集这一项在移动端的收益最直接，运动营养这类品类的用户里移动端占比通常在七成以上。 字体子集这一步建议把两门语言各自的字符集导出成明确的清单存进版本库，以后换字体或者升级构建工具时，照着清单重新裁剪就行。 ## 保加利亚的西里尔域名今年三月才委派，值不值得抢？ 保加利亚申请西里尔字母的国家域名后缀，前后拖了好几年。 卡住的原因是它跟另一个已存在的拉丁后缀在视觉上被认为过于相似，属于前面讲的同形混淆问题。 IANA的委派记录 (https://www.iana.org/domains/root/db/xn--90ae.html)显示它的注册日期是今年三月，也就是几个月前的事。 刚委派的后缀，注册量和用户认知度都还很低，短期内不会成为主流。 值不值得注册取决于你的品牌保护预算，从流量角度看现在还看不到收益。 务实的做法是主站继续用现有的拉丁后缀，把西里尔后缀作为防御性注册。 另外要留意一点：新委派的后缀在早期常有优先注册和争议解决的时间窗，品牌方错过这个窗口之后再想拿回来，成本会高很多。 ## 塞尔维亚的西里尔域名委派五年了，采用率为什么还是低？ 塞尔维亚的西里尔后缀在2011年就完成了委派 (https://www.iana.org/domains/root/db/xn--90a3ac.html)，比保加利亚早了五年。 五年过去，实际注册量跟拉丁后缀相比仍然差着一个数量级。 原因不复杂：域名要打字、要口头传播、要印在包装上，拉丁字符在这几个场景里都更方便。 注册局的说明页 (https://www.rnids.rs/%D0%BA%D0%B0%D0%BA%D0%BE-%D1%80%D0%B5%D0%B3%D0%B8%D1%81%D1%82%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D0%B8-rs-%D0%B8-%D1%81%D1%80%D0%B1-%D0%B4%D0%BE%D0%BC%D0%B5%D0%BD)把两种后缀的注册流程并排放着，本身就是这个市场的写照。 这段经验对做保加利亚市场有直接参考价值：别指望新委派的西里尔后缀能带来流量。 域名这一层的结论是：两个市场都用拉丁后缀做主站，西里尔后缀只做品牌防御。 这里还有个反面教训：有些团队会把西里尔后缀设成主域名以示本地化诚意，结果外链、口碑传播和线下物料上全是打不出来的字符，得不偿失。 ## 站内搜索该怎么同时接住两套字母？ 核心思路是在索引阶段做规范化，把两套字母统一到其中一套。 统一到哪一套不重要，重要的是查询和索引走同一套转换。 转换要用前面说的例外表版本，别用裸的字符替换，否则二合字母那批词会被转坏。 展示层一律用用户当前选择的那套字母，这跟索引层的统一不冲突。 保加利亚语这边简单得多，只有西里尔一套，需要处理的是定冠词的剥离。 两边配完之后都要拿真实日志跑回归，重点看零结果率。 还要注意查询日志的存储：如果日志表的字符集没配对，西里尔查询存进去会变成问号，那你连诊断的原始数据都没有了。 ## 词干化在这两门语言上能做到什么程度？ Snowball的塞尔维亚语词干算法 (https://snowballstem.org/algorithms/serbian/stemmer.html)覆盖了名词、形容词和动词的常见词尾。 它是按拉丁形态写的，所以西里尔那边要先转成拉丁再送进去。 保加利亚语这边没有同等成熟的现成方案，主要靠自己写定冠词剥离规则。 好在保加利亚语没有格，要剥的形态数量有限，一两百条规则能覆盖大部分。 保加利亚国家语料库 (https://dcl.bas.bg/bulnc/)可以用来验证规则的覆盖面，拿真实语料跑一遍比拍脑袋靠谱。 两门语言都建议给词干化设一个最短词根长度，防止短词被切成没有意义的残根。 词干化的效果验证不要只看零结果率，还要看误合并率，也就是本来不该归到一起的词被切成了同一个词根，这类错误会让搜索结果显得毫不相关。 ## 品牌名该用哪套字母写？ 国际品牌一律保留拉丁原形，两个市场都不要转写。 本地品牌在塞尔维亚要准备两套，因为两套都是正字法，两套都会被搜。 本地品牌在保加利亚只用西里尔，拉丁形式只出现在域名和法务文件里。 商品成分名这类专业词汇，两个市场都倾向于用拉丁原形加西里尔解释。 运动营养品类在这一点上特别明显，成分的国际通用名比本地译名的搜索量高不少。 标题里的处理是拉丁原形在前、本地写法在后，两种形态各占一次。 成分名还有一个细节：国际通用名和本地俗名有时候指向的浓度或者剂型不同，做属性字典时要把这层差别记清楚，不然会出现描述与实物不符的投诉。 ## 价格、日期与数字格式两国差在哪？ 保加利亚的货币代码是BGN，塞尔维亚是RSD，两者不能混。 两国的小数点都用逗号，千分位用空格或者点，具体写法要按本地习惯确认。 日期都是日月年顺序，跟大多数欧陆国家一致。 塞尔维亚第纳尔的面额数字比较大，价格筛选器的档位要按本地价位重设。 两国的增值税率不同，含税价的展示规则也要分开配。 这些字段属于非语言层，但它们的错误比语法错误更容易被用户直接感知到。 另外提醒一句，两国的度量单位习惯一致都用公制，但运动营养品类里常见的英制单位标注要不要保留，取决于你的目标客群是不是健身圈的重度用户。 ## 地址与电话字段该怎么设计？ 保加利亚邮编四位，塞尔维亚五位，表单校验的位数要分开。 地址顺序两国都是从大到小，跟中文习惯一致。 电话号码的国家代码不同，格式化规则也不一样。 地址字段的字符白名单要允许对应语言的西里尔字母，别只放拉丁。 用户在地址里混用两套字母的情况在塞尔维亚很常见，校验规则不能太严。 严了的后果是用户填不进去直接放弃下单，这个损失比脏数据大得多。 表单的输入提示最好用当地语言写，并且给一个填好的示例，示例的作用比任何校验规则都大，能减少一大半的填写错误。 ## 结构化数据的语言标记该怎么写？ 保加利亚语用bg，塞尔维亚语用sr，这是两位语言代码。 塞尔维亚语要区分文字时，在语言代码后面加文字子标签，西里尔和拉丁各一个。 这是文字子标签，不是地区子标签，写成两个国家代码是错的。 页面的lang属性、结构化数据的语言字段、站点地图三处要保持一致。 货币字段用标准代码，不要写本地的货币缩写。 这几项写对了，本地结果里的展现完整度会明显提升。 还要检查一处：站点地图里如果为两套字母各列了一份，那两份的语言标记必须跟页面上的一致，不一致时搜索引擎会以页面上的为准，站点地图那份就白写了。 ## 两套字母的内容该怎么排优先级？ 先做拉丁版，因为搜索场景整体偏向拉丁。 西里尔版第二批做，优先覆盖官方类、健康类和年长用户占比高的品类。 两版的商品数据、价格、库存共用同一个数据源，只有文本层分开。 转换脚本能自动生成的部分不要人工重写，人工只审核例外词表覆盖的那批。 正文里的语气和用词可以两版略有差别，因为使用场景本来就不同。 但事实性内容必须完全一致，不然会出现两版说法不一的尴尬。 排优先级时可以用一个简单的判据：这个品类的用户在什么场景下做决策。偏日常快消的场景拉丁优先，偏正式和健康咨询的场景西里尔的权重要往上调。 ## 预算该怎么分？两个市场差出几倍 塞尔维亚的内容成本大约是单语言市场的一点五到一点八倍。 不到两倍的原因是有相当一部分工作可以自动化，人工只负责审核。 保加利亚的内容成本基本等于单语言市场，只多出转写规则那一次性的几十行代码。 如果两个市场同时做，共用的部分是商品数据、图片、以及非语言字段的本地化框架。 不能共用的是文本内容本身，这两门语言互相不通，别想着靠改几个词凑合。 把预算按一点八比一分给塞尔维亚和保加利亚，通常是接近实际的一个起点。 这个比例不是固定的，它随自动化程度变化：例外表和转写模块做得越扎实，人工审核的比重越低，塞尔维亚那一侧的倍数就越接近一点五。 ## 母语审校在这两门语言上该盯什么？ 塞尔维亚语第一条：转写后的西里尔版里有没有二合字母被转坏的词。 第二条：发音传统是不是统一，别在同一页里两种写法混着来。 第三条：有没有混进克罗地亚特有的词汇。 保加利亚语第一条：定冠词的形式对不对，尤其是阳性单数那两个形式。 第二条：引用第三方内容的地方有没有用转述式动词。 两门语言共同的最后一条：让审校的人念一遍，念着卡壳的地方一定有问题。 审校的成果要沉淀成检查清单和例外表，而不是只改一遍稿子，同一类问题改到第三次还在出现，就说明它该进自动检查而不是继续靠人眼抓。 ## 引擎那一半的功课为什么不在这篇里？ 这篇从头到尾讲的是书写系统、字符、词形和格式。 哪个搜索引擎在这两个市场份额更高、怎么排名，那是引擎层的题。 多语言站按什么维度分目录、页面关系怎么声明，那是架构层的题。 三层混着写，结果通常是每一层都只讲了个开头。 分开写的好处是语言层的结论能长期复用，而引擎层的结论过几年就会过时。 你可以把这篇当成这两个市场的语言侧清单，另外两层另有专篇。 这种分法还有一个好处：字符和词形这一层的结论几乎不会过时，五年之后回头看依然成立，而引擎的排名逻辑早就换了几轮。 ## 一个运动营养站从零开始，推荐什么顺序？ 第一步定市场分档，先确认要做几个国家、每个国家用哪套字母。 第二步写转写模块，塞语走带例外表的双向转换，保语走法定转写表。 第三步加同形混淆检查，挂在商品导入和用户输入两个入口上。 第四步配排序规则和字体子集，按语言分开。 第五步配站内搜索的字母统一与词尾剥离。 第六步才是内容生产，这时候拉丁版和西里尔版的流水线已经能跑通了。 这六步里第一步最容易被跳过，但它决定后面所有工作的范围，市场分档没定就开始写转写模块，很可能会为一个根本不打算做的市场写一堆代码。 ## 做完之后最先看到哪个指标动？ 同形混淆检查上线后，商品搜不到的客诉会立刻少一批。 站内搜索的字母统一配完，零结果率通常一两周内明显下降。 字母切换器改对之后，塞尔维亚市场的跳出率会有可见改善。 内容侧的自然流量增长最慢，要等两版内容都铺开才有。 转写例外表这一项的收益不在报表里，它防的是一批永远搜不到的错词。 把这几项排在一起看，会发现前四步全是工程活，真正花钱的内容生产反而在最后。 如果只能先做一件事，那就做同形混淆检查，它的实现成本最低，拦住的却是最难被发现、也最难被事后修复的一类数据污染。 ## 常见问题解答 ## 塞尔维亚语的两套字母，能不能只做一套？ 不建议。两套都是官方正字法，两套都有真实的搜索量，只做一套等于主动放弃一部分市场。拉丁在日常网络使用和搜索场景里占优势，西里尔在官方、教育、健康类内容和年长用户里占比更高。预算实在紧张时的折中办法是：拉丁做全站，西里尔只做核心品类页和高价值内容，同时把两个版本的关系声明配对，让搜索引擎知道它们是同一份内容的两种文字。等数据出来再决定要不要补齐，比一开始就砍掉一半稳妥。折中期间也别把西里尔版做成低质量的机器转换稿，宁可少做几个页面，做出来的每一页都要过例外表和人工审核。 ## 转写脚本一跑就能把拉丁版变成西里尔版，为什么还要人工审核？ 因为拉丁转西里尔这个方向不是无损的。拉丁那套里有三个二合字母，它们各自对应一个西里尔字母，但这两个字符也可能是两个独立字母碰巧挨在一起，比如某些前缀加词根的组合。脚本无法从字符串本身判断这是不是一个词界，遇到这种词就会转错，而且转出来的字符串看着是合法词形，肉眼极难发现。正确做法是维护一张例外词表，转写时先查表，人工只审核这批词。西里尔转拉丁的方向是安全的，不需要例外表。另外建议把这批例外词单独存成一份带版本的资源文件，因为它会随着商品线扩张不断新增，散落在代码里迟早会丢。 ## 保加利亚语要不要也做一份拉丁版内容？ 不要。保加利亚语只有西里尔一套正字法，拉丁写法是转写，用途只有三处：URL的slug、品牌与公司名的国际形式、以及地址表单里填英文地址的场景。保加利亚用户几乎不会用拉丁字符搜索本国语言的内容，做了拉丁版正文既没有流量也白白增加维护成本。真正要做对的是转写规则本身：2009年有一部法律规定了标准转写表，照着走能保证你的地名和品牌拼写跟护照、路牌、地图全部对齐。唯一值得额外做的是品牌名的拉丁形式落地页，它服务的是跨境搜索和国际合作方，跟本地用户的搜索行为无关。 ## 这跟希腊语的Greeklish、越南语的带调不带调有什么本质区别？ 区别在于两套形态的规范地位。希腊语的拉丁转写是非正式的，没有标准，一个字母能写成好几种拉丁形式，处理办法是做变体覆盖。越南语的不带调写法是把正字法的记号剥掉，有损而且会撞到别的词上，处理办法是做双轨覆盖。保加利亚语的拉丁转写有法律规定，接近一对一，但它不用于内容展示。只有塞尔维亚语是两套都属于正字法，两套都会被用户拿来阅读和搜索，所以只有它需要真做两份内容。四种情形的处理成本从低到高排，塞尔维亚语在最高的那一档。把这个判据抽象出来就是两个问题：两套形态是不是都被官方承认，它们之间的映射是不是可逆，答案组合直接对应处理成本的档位。 ## 西里尔和拉丁混排为什么危险，怎么发现？ 西里尔字母表里有一批字母跟拉丁字母长得完全一样，小写的a、e、o、p、c、x、y都在其中，大写的更多。视觉相同但码位不同，机器看到的是两个不同字符，结果是商品名被切成几段、站内搜索匹配不上、用户复制粘贴之后也搜不到。发现的办法是拿Unicode的视觉混淆字符对照表写一个检查脚本，检测一个字符串里有没有同时出现两套字母表的字符，混排的直接拦下来。这个检查建议挂在商品导入、用户注册、评论提交三个入口上，成本很低。检测脚本最好把出问题的字符位置一起报出来，只说这条有问题而不指明位置，录入的人对着屏幕根本看不出差别在哪。 ## 依格切和埃格切这层差别，做电商真的需要处理吗？ 如果你只做塞尔维亚一个国家，不需要，本土基本统一用一种。如果你要覆盖波黑、黑山或者克罗地亚，就必须处理，因为受影响的是牛奶、河流、时间这类基础词，覆盖面很广，用错了本地用户一眼就能看出内容是给别处写的。实操上不用重写整站，把受影响的高频词整理成一张替换表，按目标市场跑一遍即可。要注意这层差别跟字母选择是正交的两件事：字母是文字层，发音传统是词汇层，只做字母转换解决不了这一层。整理替换表时顺手记录每个词对的使用地区，这一列在以后拆分市场、投放广告和做内容本地化时会反复用到。 ## 刚委派的西里尔域名后缀值得注册吗？ 从流量角度看短期内看不到收益。保加利亚的西里尔后缀今年三月才完成委派，注册量和用户认知度都还很低；塞尔维亚的西里尔后缀早在五年前就委派了，到今天实际注册量跟拉丁后缀相比仍然差着一个数量级。原因很实际：域名要打字、要口头传播、要印在包装上，拉丁字符在这几个场景里都更方便。务实的做法是主站继续用现有的拉丁后缀，把西里尔后缀作为品牌防御性注册，成本不高但能避免被抢注。如果决定注册，记得把它做成跳转到主域名而不是独立站点，两个域名各自承载一份内容会直接制造重复内容问题。 ## 权威参考资料 ## 做小语种SEO，品牌名叫什么不由你定，由当地用户的输入法定 - URL：https://zhangwenbao.com/brand-name-transliteration-loanword-minor-language-search.html - 分类：小语种SEO - 发布：2016-04-28 | 更新：2026-07-24 - 摘要：品牌名进小语种市场会分裂成照搬、音译、意译三种写法，用户按键盘习惯各打各的。讲清写法由谁决定、搜索量为什么被切碎、站内与结构化数据怎么覆盖多种形态。 - 关键词：关键词研究,品牌SEO,多语言SEO,小语种SEO > **TLDR**：摘要：一个拉丁字母的品牌名进了俄语、日语、希腊语市场，不会安安静静地保持原样。它会分裂成照搬、音译、意译三种写法，用户按自己的键盘习惯挑一种打出来。工具只统计其中一种，于是品牌词的搜索量看起来永远小得可疑。 > 摘要：一个拉丁字母的品牌名进了俄语、日语、希腊语市场，不会安安静静地保持原样。它会分裂成照搬、音译、意译三种写法，用户按自己的键盘习惯挑一种打出来。工具只统计其中一种，于是品牌词的搜索量看起来永远小得可疑。 ## 品牌名进了小语种市场，一个名字会长出三个 ## 照搬、音译、意译从第一天就分叉 拉丁字母写的品牌名，进入一个不用拉丁字母的市场，第一件要面对的事就是怎么落地。 第一条路是照搬，原样保留拉丁拼写，一个字母都不动。 第二条路是音译，按发音换成本地字母，比如可口可乐在俄语里写成Кока-Кола。 第三条路是意译，把名字的含义翻过去，这条路在品牌名有实义的时候才走得通。 三条路不是三选一，现实里它们经常同时存在，各占一部分人群。 更麻烦的是，同一批用户在不同场合会用不同的写法，正式文件里照搬，聊天和搜索里用音译。 这三条路的分叉点不在你的品牌手册里，而在当地媒体第一次报道你的那一天。记者当时随手写下的那个形态，往往会被后来的所有报道沿用，等你几年后想统一写法，已经有几百篇文章在用另一种拼法了，改的成本比当初商量的成本高出两个数量级。 把三条路摆在一起看还有个用处，它能提醒你别把资源全押在自己最喜欢的那一种上，市场的偏好和品牌方的审美经常是两回事。 ## 谁在决定这个名字，公司说了不算 公司当然可以在官网上宣布一个官方写法。 问题是搜索框里打字的那个人没看过你的官网。 他记住的是电视广告里念的音，或者朋友在聊天里打出来的那串字母。 本地媒体、电商平台的商品标题、论坛帖子，三者的合力远大于品牌方的声明。 保哥经手过一个智能家居品牌进俄语市场的项目，官方定的是照搬拉丁写法。 结果三个月后拉搜索词报告，超过一半的品牌相关查询用的是西里尔音译，而那个音译形态官网上一次都没出现过。 这里的机制其实和关键词研究是一回事：你要找的不是正确答案，是多数人的实际行为。品牌名比普通关键词更容易让人产生错觉，因为它是你自己的资产，你会下意识觉得自己有定义权。当年拿词典逐词换出来的那批关键词 (https://zhangwenbao.com/keyword-literal-translation-legacy-cost-non-english.html)之所以没人搜，也是同一个错觉的产物。 实际操作里可以定一条很简单的纪律：凡是要对外发布的写法，先去搜一遍看当地已经有多少页面在用它，再决定要不要坚持。 ## 一个名字变成三个之后，搜索量就被切开了 假设某个市场每月有三万次跟你品牌相关的搜索。 照搬形态占一万二，音译形态占一万四，剩下四千散在各种拼错和混写上。 关键词工具查照搬形态，返回一万二，看着不算多。 做决策的人拿着这个数去跟其他市场对比，得出的结论是这个市场品牌认知度低。 真实情况是认知度不低，只是被三种写法分掉了。 这种统计口径的错误会一路传导到预算分配，本该加码的市场反而被砍了钱。 要修正它并不难，麻烦的是你得先知道有几种写法在流通。查询三个形态各自的搜索量、把它们加起来再做对比，这个动作只花二十分钟，但前提是有人意识到该做。绝大多数团队从来没做过这一步，因为品牌名在他们的认知里天然是一个单数名词。 被切开的还不只是搜索量，付费广告的质量得分、竞品对比报告里的市占估算，全都建立在单一字符串上，一处失真会连着错好几处。 ## 用户到底会打哪一种写法？ ## 键盘布局决定了第一反应 俄语用户的物理键盘上同时印着西里尔和拉丁两套字母。 切换只要按一下组合键，成本低到可以忽略。 希腊用户、保加利亚用户的情况类似，双布局是常态。 日语用户的输入法则完全是另一种逻辑，敲拉丁字母，出来的是假名或汉字。 要打出纯拉丁形态，反而要多一步切换到半角英数模式。 所以日语市场里片假名形态的占比通常比俄语市场里西里尔形态的占比更高。 判断某个市场照搬形态能占多大比例，最快的近似方法就是看当地主流输入方式跟拉丁字母的距离有多远。日语的三套文字表记问题 (https://zhangwenbao.com/japanese-seo-hiragana-katakana-kanji-keyword-notation.html)本质上是同一道题的另一个变体，只不过那里分叉的是普通词，这里分叉的是专有名词。 另一个容易忽略的因素是年龄结构，年轻用户切换键盘更熟练，年长用户更依赖默认布局，俄语那批被合并统计的词形 (https://zhangwenbao.com/russian-seo-cyrillic-cases-declension-wordstat-keyword.html)里也能看到类似的分层。 ## 移动端的自动补全会把人推向某一边 手机上的输入体验跟桌面完全不同。 切换键盘语言在触屏上要多点两下，还容易点错。 更重要的是自动补全，它会主动推荐用户曾经打过的形态。 第一次打出音译形态的人，第二次会被补全直接推到同一个形态上。 这条路径有很强的自我强化效应，早期的分布会被放大并固化下来。 这也意味着新品牌进入市场的头半年，写法之争基本就定型了。 移动端还有一个容易被忽略的细节，搜索框里的语音输入。用语音搜品牌名的时候，识别结果是按本地语言的拼写规则生成的，几乎必然落在音译形态上。这部分流量在报表里跟手打完全混在一起，但它的写法分布跟手打差得很远。 想验证这条路径也不难，找两台干净的设备，一台从没搜过你的品牌，另一台搜过十次，对比它们的补全列表就看得出强化效应有多强。 ## 品牌词和品类词的搭配顺序也会跟着变 英语里习惯把品牌词放前面，品类词放后面。 斯拉夫语族的用户经常反过来，先打品类再打品牌。 这不是随机的，跟这些语言里修饰关系的表达方式有关。 顺序一变，你原本准备好的那批长尾词全部对不上。 更细的一层是，品牌名用音译形态时更容易被当成普通名词跟着变格。 照搬形态则通常保持原形不动，或者用一个隔断符号跟词尾分开。 土耳其语的正字法就明确规定了这一点，专有名词后面接后缀要用撇号隔开，写成品牌名加撇号加后缀的形态。芬兰语里遇到拼写和发音对不上的外来名，则用冒号来接格尾。这两种符号在搜索框里的输入率极低，于是用户干脆把它们省掉，又制造出一批新的变体。 词序这件事最好在建词表之前就问清楚当地同事，等词表做完再返工，等于把品类词和品牌词的组合全部重排一遍，工作量翻倍。 ## 拉丁原名照搬在哪些市场是安全的？ ## 拉丁字母国家：照搬没问题，但变音符号要盯 波兰、捷克、匈牙利、越南这些市场用的都是拉丁字母。 品牌名照搬进去，视觉上完全不违和。 但这些语言的键盘上还有一批带记号的字母。 用户在打你的品牌名时，可能会顺手把某个字母写成带记号的形态。 反过来也成立，如果你的品牌名本身带记号，用户多半会打成不带记号的。 这两个方向的变体都得收进词表，否则会漏掉相当一部分流量。 这一层的风险跟品牌名的长度和字母组合有关。三到五个字母的短名字风险最低，带有本地语言中不存在的字母组合的名字风险最高。波兰语的变音字母与七个格 (https://zhangwenbao.com/polish-seo-seven-cases-diacritics-keyword-research.html)那篇讲的是普通词的变体覆盖，品牌名的处理逻辑完全可以照搬过来。 记号的有无还会影响到广告后台的匹配逻辑，两种形态在某些匹配模式下不会互相触发，法语重音符号带不带的两套写法 (https://zhangwenbao.com/french-seo-accents-quebec-keyword-variants.html)那篇里算过这笔账。 ## 双文字市场：两套字母同时在跑 塞尔维亚语、乌克兰语这类市场情况更复杂一层。 塞尔维亚语本身就有西里尔和拉丁两套官方书写系统。 同一个用户可能上午用一套、下午用另一套。 品牌名在这种市场里至少有三种形态：拉丁原名、拉丁转写、西里尔音译。 三种形态的使用者不是三批人，而是同一批人在不同场合的不同选择。 这意味着不能按人群划分覆盖策略，只能三种全做。 这类市场的好消息是，用户对多种写法并存这件事本身习以为常，看到品牌名以不熟悉的形态出现不会觉得可疑。希腊字母与拉丁转写并存时的覆盖办法 (https://zhangwenbao.com/greek-seo-greeklish-latin-transliteration-coverage.html)里那套变体分档的思路，在品牌名上同样成立。 还有一个细节，双文字市场的用户在正式场合和随意场合切换书写系统的习惯不同，商务品类和消费品类的形态分布因此会差得很远。 ## 非拉丁市场里照搬那部分人到底有多大 这个比例不能拍脑袋，得实测。 最简单的办法是拿三个形态分别去搜，看结果页里本地站点的密度。 某个形态如果搜出来全是本地电商和本地媒体，说明这个形态在当地是活的。 如果搜出来全是国际站和英文页面，说明用它的主要是找官网的那批人。 第二个办法是看搜索建议，输入前几个字母时补全推荐的顺序就是使用频率的排序。 第三个办法是去当地最大的电商平台搜，看商品标题用的是哪种写法。 三个办法都不需要工具，也不需要预算，一个下午能跑完十几个市场。判断标准可以定得很粗：某个形态如果在这三个来源里出现了两次以上，就进词表；只出现一次的先记着但不建页面。粗一点没关系，反正后面还有搜索词报告的实际数据可以回来修。 实测的时候记得把搜索地区和界面语言都设成目标市场，不然拿到的结果页混着自己所在地区的偏好，密度判断会整体偏向拉丁形态。 ## 本地字母的音译该按谁的规则来？ ## 官方转写系统能不能反过来用 联合国地名机构给俄语、希腊语这些语言都发布过罗马化方案。 那套方案是把本地字母转成拉丁字母，方向跟你需要的正好相反。 反着用可以当参考，但不能当答案。 原因是罗马化追求可逆，一个字母对一个字母，不考虑读音自然与否。 而品牌名的音译追求的是当地人念出来像原名，这是两个目标。 按罗马化表倒推出来的形态，经常是本地人从来不会那么写的怪东西。 正确的用法是把官方表当作检验工具而不是生成工具：先收集当地实际在用的几种写法，再用转写表看它们各自对应回拉丁字母是什么样子，能一眼看出哪些形态是从原名来的、哪些是从另一种语言的读法转手过来的。中间转过手的那些形态往往有意想不到的搜索量。 把转写表当检验工具还有个附带好处，它能帮你识别出那些看起来很像但其实来自另一个品牌的形态，避免把别人的流量算进自己的报表。 ## 媒体先叫开的那个写法权重最高 本地媒体是品牌名写法的实际立法者。 财经媒体和行业媒体写下的形态，会被搜索引擎当作实体的常用别名收下来。 这个别名一旦被搜索引擎接受，它会影响搜索建议、相关搜索和知识面板。 所以第一步不是决定自己用哪个写法，是先查媒体已经在用哪个。 查法很直接，搜品牌名加上当地几家大媒体的域名，看正文里的形态。 如果媒体之间也不统一，说明写法还没定型，这时候品牌方还有介入的机会。 介入的方式不是发声明，是在给媒体的新闻稿里把首选写法用固定格式写死，第一次出现时给出本地形态并在括号里放拉丁原名。记者写稿时最省事的做法就是照抄新闻稿，你把选择成本降到零，写法就会跟着走。这个窗口期通常只有品牌进入市场的头一年。 除了主流媒体，行业垂直媒体的写法同样重要，尤其在专业品类里，垂直媒体的用词往往比大众媒体更早定型，也更被从业者沿用。 ## 同一个品牌名在西里尔里能有几种拼法 答案往往比想象的多。 原名里如果有本地语言没有的音，比如某些擦音和双元音，就会出现分歧。 不同的人会选不同的近似字母来对付它，于是变体就产生了。 名字末尾的处理是另一个分歧点，加不加软音符号、加不加元音。 还有一批变体来自转手，先经过另一种语言的读法再转过来。 把这些变体列全，通常能凑出四到六个形态。 列全之后要做一件很多人不做的事：给每个变体估一个量级，然后只给前两个建独立页面，其余的做同义词处理。变体全做页面会把品牌页拆成一堆低质量的重复页，这个坑在词表膨胀的时候特别容易踩。 变体收集完之后建议标注来源，某个形态是媒体在用还是论坛在用，决定了它的稳定性，同一个国家两套内容怎么排 (https://zhangwenbao.com/ukrainian-russian-seo-bilingual-market-content-split.html)那篇里的来源分层可以直接借用。 ## 日语片假名的长音、促音和中黑点 日语的音译规则比西里尔细致得多，也更容易出分歧。 长音符号加不加，是最常见的一处摇摆。 由两个词组成的品牌名，中间要不要加中黑点分隔，也没有统一答案。 促音的有无同样会分出两派写法。 官方文件里有一份外来语表记的指导规则，但它给的是范围而不是唯一解。 实际结果是同一个品牌，商品页写一种，广告写另一种。 处理办法是把长音、中黑点、促音这三个维度各自的两种取值组合起来，得到一张小的变体表，再按实际搜索热度排序。这张表通常只有四到八行，做一次能用很多年，因为日语的外来语表记规则变化极慢，而这几个维度覆盖了绝大部分实际分歧。 日语市场还有一个特殊情况，同一个品牌在不同品类下可能各有习惯写法，家电和服饰的表记倾向未必一致，跨品类的品牌要分别确认。 ## 意译过来的名字会不会更好？ ## 意译能被理解，但搜不出来 意译的优势是当地人一看就懂含义。 劣势是这个词多半已经是一个普通名词，早就有别的意思。 用户搜这个词的时候，想找的九成不是你。 你要跟一整个词义的通用需求去抢排名，成本极高。 更麻烦的是转化，进来的人多数不是找你的，跳出率会很难看。 所以意译形态可以作为辅助说明存在，但不适合当主品牌词。 有一类例外值得注意，就是品牌名本身在原语言里也是生造词的情况。这类名字没有既有词义可占，意译反而能创造一个干净的新词，不跟任何通用需求打架。判断标准很简单：把意译后的词丢进搜索框，看结果页有没有跟你完全无关的成熟内容。 退一步说，意译形态即使不做主品牌词，也值得在页面里留一句解释性的说明，让第一次接触品牌的本地用户知道这个名字是什么意思。 ## 品类词被意译吃掉的风险 有一种更隐蔽的情况，意译出来的名字跟品类词高度重合。 比如一个做净化设备的品牌，意译过来正好是当地话里净化器三个字。 短期看这是好事，用户搜品类就能看到你。 长期看这是灾难，你的品牌资产没法跟品类需求分开计量。 报表里再也分不清哪些流量是冲你来的，哪些只是来买东西的。 品牌词的排名波动也没法归因，因为它跟品类词的竞争完全绑在一起。 真遇到这种情况，务实的做法是在意译名前面固定加一个限定成分，让它成为一个可识别的组合，而不是一个通用短语。加限定的代价是名字变长，收益是从此有了一个可以单独计量的品牌资产，这笔账通常划算。 品牌名和品类词粘在一起的问题在复合词语言里更严重，德语把关键词拼成一个长单词 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)那篇讲的切分难题，换成品牌名照样成立。 ## 什么时候意译值得单独做一个页面 意译形态即使不当主品牌词，也可能有独立的搜索量。 典型场景是当地用户不知道原名，只听说过意译的说法。 这种情况在口碑传播主导的品类里很常见。 判断依据是意译形态的搜索结果里，有没有人在问这是什么牌子。 有人在问，说明这个说法在民间流通但没有官方承接。 这时候做一个页面把它跟正式品牌名连起来，收益相当直接。 这个页面的写法有讲究，标题里两种写法都要出现，正文第一段要明确说明它们指同一个东西。这样做的目的不只是给用户看，也是给搜索引擎的实体识别提供一条明确的对应关系，让它把这两个字符串挂到同一个实体上。 这类页面上线之后要盯的指标不是排名，而是它有没有把搜索这个民间说法的人真正引到正式品牌页去，跳转率比排名更能说明问题。 ## 品牌词的搜索量在工具里为什么看着这么小？ ## 工具默认只统计你输进去的那一种写法 关键词工具是按字符串工作的，不是按实体工作的。 你输进去拉丁形态，它返回的就是拉丁形态的数据。 它不会主动告诉你还有一个西里尔形态的量比这个大。 有些工具的相关词建议里会带出音译形态，但排得很靠后。 更常见的情况是它给你一堆拼写变体，你以为都是噪音就过滤掉了。 被过滤掉的那批词里，往往就藏着当地真正在用的主形态。 用工具查品牌词时，正确的做法是先手工列出三到六个候选形态再逐个查，而不是查一个然后看它推荐什么。工具的推荐逻辑基于共现和字符串相似度，跨书写系统的两个形态在字符层面毫无相似之处，它天然就不容易把它们关联起来。 手工列候选形态这件事听起来很土，但在小语种市场里，土办法往往比工具更接近真相，把关键词研究升级成搜索需求建模 (https://zhangwenbao.com/keyword-research-search-demand-modeling-opportunity-allocation.html)讲的就是这种思路的一般化。 ## 品牌词加品类词的长尾被拆得更碎 单纯的品牌词只有几种形态，长尾组合的形态数是乘出来的。 品牌名三种写法，乘上品类词的两种说法，就是六个组合。 再乘上词序的两种可能，变成十二个。 每个组合的量都不大，单看都像是可以忽略的长尾。 加起来却经常超过主品牌词本身。 这也是小语种市场品牌词报表最容易失真的一层。 处理这层的办法不是把十二个组合全部建页面，而是在品牌页里把这些说法自然地写进正文和小标题，让一个页面能接住整组变体。搜索意图在这一组里是高度一致的，用一个页面承接不会有任何稀释问题，反而集中了信号。 组合数在黏着语市场还要再乘一层，因为品牌名后面会直接粘上格尾，土耳其语一个词接五个后缀 (https://zhangwenbao.com/turkish-seo-agglutinative-suffix-stacking-keyword.html)那篇里的词形爆炸在专有名词上同样发生。 ## 拼错的形态占比常常被整个忽略 非本地语言的品牌名，拼错率天生就高。 字母组合越不符合当地语言的拼写直觉，错得越花样繁多。 这批查询在工具里通常被归到低量长尾里，看着不值得管。 但它们的转化意图极强，打错字的人是明确在找你。 覆盖成本又极低，站内搜索加一组同义词映射就能接住大部分。 唯一需要注意的是不要把拼错形态写进页面标题，那样很难看。 拼错形态的收集有个省事的来源，就是站内搜索的无结果查询清单。那份清单里除了真的缺货的商品，剩下的大半是各种拼错，按频次排序取前二十条，基本就覆盖了这个市场的主要错法。这份清单每季度更新一次就够了。 拼错形态还有一个来源常被漏掉，就是语音输入的识别结果，它产生的错法跟手打完全不同，通常是整段音节的偏差而不是单个字母。 ## 站内要为这些写法准备什么？ ## 标题里要不要同时出现两种写法 首页和品牌页的标题是最稀缺的位置，不能什么都往里塞。 判断标准是两种写法的量级差距。 如果次要形态的量不到主形态的三成，标题里不放，正文里出现就够。 如果两者接近，标题里并列出现是划算的。 并列的写法建议用括号，主形态在前，次形态在括号里。 这样既保证了标题的可读性，又让两个字符串都出现在最重要的位置上。 还有一种情况需要单独处理，就是两种形态的用户意图有差别。照搬拉丁形态的人更多是在找官网和正品，音译形态的人更多是在比价和看评价。这时候与其在一个标题里塞两种写法，不如让两个页面分别承接，各自的标题各写各的形态，反而更干净。 标题里塞两种写法之前先看一眼移动端的显示长度，很多小语种的音译形态比原名长出一半，两个形态并列很容易被截断在最难看的位置。 ## 正文第一次出现时的括号写法 正文里的处理有一套很稳的模式。 第一次提到品牌名时，用主形态，后面括号里给出另一种形态。 之后全文统一用主形态，不再来回切换。 这个模式的好处是既完成了字符串覆盖，又不影响阅读。 要避免的做法是全文两种形态交替使用。 那会让读者以为是两个不同的东西，也会稀释掉页面的主题集中度。 括号里的形态还有一个用处，它是给母语审校的锚点。审校的人看到括号里的形态，会顺手告诉你这个写法在当地是不是自然。这种反馈在需求文档里问是问不出来的，只有在具体文本上才会冒出来。 如果页面上有商品参数表或者规格表，括号写法也要同步过去，那些表格经常是从系统里导出来的，最容易保留着最初那一版写法。 ## 结构化数据里的别名字段 组织和产品的结构化标记里都有别名字段可用。 把音译形态、常见变体填进去，是成本最低的一步。 它的作用不是直接提升排名，而是帮搜索引擎把几个字符串归到同一个实体上。 同一个实体成立之后，知识面板和搜索建议才有可能收下这些别名。 填的时候按实际使用频率排序，不要把生僻变体也堆进去。 三到五个别名是合理的规模，再多就显得可疑了。 还有一个配套字段是官方页面的引用关系，把当地媒体报道、当地平台的品牌页、社交账号一起标出来。这些页面上用的写法本身就构成了旁证，实体识别不是只看你自己怎么说的，它更看外部世界怎么写你。 填别名字段时顺手做一次核对，看看这些形态在自己站里是不是至少出现过一次，只在标记里出现而正文里从来没有的别名，说服力会打折扣。 ## 站内搜索的同义词表要跟着一起改 站内搜索是最容易被漏掉的一环。 用户在你的站里搜品牌名，用的写法跟在搜索引擎里一模一样。 如果站内搜索只认一种写法，另外那些人搜出来是零结果。 零结果页面的跳出率接近百分之百，这是白白送走的转化。 修法就是把变体表配成同义词，几十行配置就能解决。 顺手把常见拼错也配上，收益立刻可见。 配完之后要看的指标不是搜索次数，是无结果率。这个数字从两位数掉到个位数，说明同义词表生效了。反过来，如果无结果率没变，说明用户搜的还是别的东西，那份变体表需要重新收集，问题不在配置上。 同义词表还需要一条维护纪律：每次上新品类或者进入新市场时重看一遍，因为新品类会带来新的品类词组合，旧的映射未必接得住。 ## 外部世界怎么写你的名字，你管得了吗？ ## 媒体和目录里的写法会回流到搜索建议 搜索建议不是凭空生成的，它来自真实查询和网页上的实际用词。 当地媒体、行业目录、电商平台上的写法，会一层层喂给这个系统。 某个形态在网页上出现得足够多，它就会开始出现在建议列表里。 建议列表又会引导更多用户去打这个形态，形成闭环。 这个闭环启动之后，品牌方基本只剩下顺应的份。 所以真正能起作用的窗口在闭环形成之前，也就是进入市场的头一两年。 已经错过窗口期也不是没得做，只是打法要换成承接而不是纠正。承接的意思是把当地已经在用的形态全部纳入自己的资产体系，官网、商品页、结构化数据里都给它位置，让搜索引擎确认这个形态属于你，而不是让它一直挂在别人的页面上。 这个闭环也解释了为什么早期投放本地媒体的性价比这么高，那时候你的一篇报道对形态分布的影响力，抵得上后来的十篇。 ## 品牌被提到了，但工具搜不到 品牌提及监控的原理是按字符串匹配。 监控词只配了拉丁形态，音译形态的提及一条都抓不到。 这意味着报表上显示的提及量可能只有实际的一半。 更实际的损失是漏掉了本可以转成外链的那批提及。 某家本地媒体写了你三段，用的是西里尔形态，没加链接，你完全不知道。 而这类未加链接的提及，恰恰是转化率最高的一类外链来源。 修正它只需要在监控工具里把全部形态都配成关键词，包括常见拼错。配置成本是十分钟，收益是一整条被忽略的外链渠道。这也是为什么品牌名的形态清单不只是内容团队的事，做外链的人同样需要它。 监控词配全之后还要把结果按形态分开看，不同形态的提及往往来自完全不同的媒体圈层，合并成一个数字会把这层信息抹掉。 ## 商标注册和本地写法是两码事 商标层面的品牌保护和搜索层面的品牌覆盖，遵循的是两套逻辑。 国际商标体系里注册的通常是原名和图形标识。 音译形态如果没有单独注册，法律上的保护会弱一些。 这在有人抢注音译形态的时候会变成很实际的麻烦。 反过来，注册了商标不等于搜索结果里就是你的。 两件事各做各的，但清单可以共用，都基于同一张形态表。 建议的做法是形态表定稿之后，把它同时抄送给法务和做搜索的人。法务看的是要不要注册，做搜索的看的是要不要建页面，两边的判断标准不同但输入相同。这份表在公司里能同时服务两个部门，它的价值比看起来大。 另外提醒一句，如果计划注册音译形态，注册之前先确认这个形态在当地已经有实际使用，注册一个没人用的写法是纯粹的成本。 ## 这几种写法怎么排优先级？ ## 用三层判据排序：人群、竞争、可控性 第一层是人群规模，哪个形态的实际使用者最多。 第二层是竞争密度，这个形态的搜索结果里有没有强势的占位者。 第三层是可控性，你能不能通过自己的内容影响这个形态的结果页。 三层里第一层权重最高，但第三层最容易被忽略。 有些形态量很大，但结果页被本地大平台完全占满，你挤不进去。 这种形态的正确做法是通过平台的品牌店铺去承接，而不是硬做自己的页面。 三层判据排完之后会得到一个顺序，这个顺序决定的不是做不做，是先做哪个。全部形态最终都要覆盖，只是投入的资源不同：排第一的做独立页面加持续内容，排第二的做页面不做持续内容，排后面的只做同义词和结构化数据里的别名。 排序做完之后建议记一份决策依据，半年后市场变了要重排时，能看出当初是哪个输入变了，按人口和竞争密度算的那笔优先级账 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)用的也是同一种记账方式。 ## 一个主写法加两个别名的最小方案 预算有限时，有一个可以立刻落地的最小方案。 选一个主写法，做完整的品牌页和内容。 另外两个高频形态做别名处理，不建独立页面。 别名处理包括：正文里出现、结构化数据里标注、站内搜索配同义词。 这三步加起来大概是半天的工作量。 能覆盖到的搜索量，通常在总量的八成以上。 这个方案的关键在于选对主写法。选错了的话，后面所有工作都建立在一个占比不到三成的形态上，怎么努力都事倍功半。所以前面那个下午的实测，值得认真做一遍，它决定了后面几个月的投入落在哪里。 最小方案跑满一个季度之后，回头看搜索词报告，通常会发现当初排第三的形态涨得最快，那就是该追加投入的信号。 ## 别名页面会不会被判成重复内容 这是很多人不敢做多形态覆盖的顾虑。 如果两个页面只是把品牌名替换了一下，其余内容完全相同，确实有风险。 但正确的做法本来就不是复制页面。 不同形态的用户意图往往有差别，页面内容应该跟着意图走。 一个页面讲正品和官方渠道，另一个页面讲价格和评价，天然就不重复。 实在没有内容差异的形态，就别建页面，做别名就好。 判断有没有内容差异的方法很朴素：拿两种形态各自去搜，看结果页排在前面的都是什么类型的页面。类型一致说明意图一致，那就合并成一个页面；类型明显不同，说明这两批人想要的东西不一样，分开做才对得上。 还有一种折中做法，把次形态做成品牌页下的一个锚点小节而不是独立页面，既有独立的内容承接，又不产生新的页面竞争。 ## 什么时候该换主写法 主写法定了之后不宜频繁改，但也不是永远不能动。 需要考虑更换的信号有三个。 第一个是搜索词报告里次形态的占比连续两个季度超过主形态。 第二个是当地主流媒体统一改用了另一个形态。 第三个是搜索建议里主形态掉到了第二位以后。 三个信号同时出现时，换是划算的；只出现一个，先观察。 真要换的时候，不需要把旧形态的页面删掉或跳转，两个页面并存反而更安全。要换的只是资源投放的重心：新内容围绕新主形态做，旧页面保持更新但不再加码。这样即使判断错了，回头的成本也接近于零。 换主写法这件事最好挑在有新品发布或者大促之前做，那段时间本来就要产出大量新内容，重心转移可以顺势完成，不用额外投入。 ## 验收只看三个数字 ## 各写法在搜索词报告里的展现占比 第一个数字是每种形态各自带来的展现量占比。 这个数据在站长工具的搜索分析报告里直接能拿到。 把品牌相关的查询导出来，按形态归类求和。 第一次跑这个统计通常会有意外，因为实际分布跟预设经常不一致。 做完覆盖之后每季度重跑一次，看分布有没有漂移。 漂移本身就是市场认知变化的信号，比任何调研都直接。 归类这一步建议写成脚本而不是手工做，因为形态变体加上拼错会有几十上百行，手工分类既慢又不一致。脚本的规则也很简单，按几个关键字符串做匹配，剩下的归到其他，其他那一类如果超过一成，说明还有没被发现的形态。 跑这个统计还有个副产品，你会看到一批从没进过词表的查询形态，那些通常是当地用户自己创造的说法，价值往往高于工具给的建议词。 ## 搜索建议里的形态排序 第二个数字来自搜索建议，它不需要任何工具。 在目标市场的搜索框里输入品牌名的前几个字母，看补全推荐的顺序。 主形态排在第一，说明覆盖工作是有效的。 如果一个你从没做过的形态排在第一，说明市场跟你的判断不一致。 这个检查每个月做一次，一分钟就能完成。 它是所有指标里反应最快的一个，往往领先于报表两三个月。 检查的时候要注意隔离个性化的影响，用无痕窗口并把地区设成目标市场。同一个品牌名在不同地区的建议列表可能完全不同，这本身也是有用的信息，能看出哪些形态是跨市场通用的、哪些只在单个市场里流行。 建议列表还能看出竞争态势，如果输入品牌名的前几个字母出现的是竞品名称，说明这个市场里你的品牌信号还不够强，需要先补品牌内容。 ## 拼错形态的兜底覆盖率 第三个数字是站内搜索的无结果率。 它衡量的是同义词表和拼错兜底做得够不够。 健康的水平是个位数，超过两位数说明有明显缺口。 这个数字的好处是它不依赖外部数据，完全在自己手里。 而且它的改善动作非常具体，就是往同义词表里加条目。 三个数字合起来，基本能判断品牌名的多形态覆盖处于什么状态。 如果只能盯一个数字，盯第一个。展现占比同时反映了覆盖的广度和用户的实际行为，另外两个更像是它的先行指标和补充。三个数字的共同点是都能在半小时内拿到，不需要额外采购任何数据，这在小语种市场里尤其重要，因为那里可买的数据本来就少。 无结果率降下来之后可以再看一层，就是搜索之后的转化率，如果搜得到但不下单，说明问题从写法覆盖转移到了商品和落地页本身。 ## 常见问题解答 ## 品牌名到底要不要做本地音译 先分清两个决策：要不要在营销物料上正式启用一个音译名，和要不要在搜索层面覆盖已经存在的音译形态。第二件事几乎没有讨论余地，只要当地已经有人那样写、那样搜，你就该覆盖，不覆盖等于把这部分流量送人。第一件事才需要权衡，正式启用意味着要在广告、包装、法务多个环节同步，成本高得多，而且一旦启用很难回头。判断依据是当地市场里非拉丁形态的使用比例，如果超过一半且还在上升，正式启用是值得的；如果只有两三成且稳定，覆盖就够了，不必大动干戈。还有一个常被忽略的因素是品类，高端品类的用户对拉丁原名的接受度普遍更高，因为原名本身带有进口和正品的暗示，这类品类里贸然全面本地化反而会削弱定位。综合起来的建议是：搜索层面全覆盖，品牌层面看比例和品类再定，两件事不要混为一谈。补一个判断时机的土办法：如果当地销售在口头介绍产品时已经自然地说着音译名，那说明市场早就替你做完了决定，剩下的只是承认它。 ## 怎么快速查清一个市场有几种写法在流通 有一套一个下午能跑完的流程。第一步在目标市场的搜索框里输入品牌名的拉丁形态和你能想到的音译形态，把搜索建议里出现的所有变体记下来。第二步搜品牌名加品类词，翻前三页结果，把标题和摘要里出现的写法都记下来，特别注意本地电商和本地媒体用的形态。第三步去当地最大的两个电商平台，搜品牌名，看商品标题的写法，平台上的卖家最贴近真实用户，他们写什么就说明用户搜什么。第四步去当地的问答站和论坛，搜品牌名，看用户自己打字的时候用哪种。四个来源汇总起来去重，得到的清单基本覆盖了这个市场的主要形态。最后一步给每个形态标一个粗略的量级，靠的是它在这四个来源里各自出现的频次，不需要精确数字，能排出顺序就够用了。这套流程的价值在于它不依赖任何付费工具，在关键词数据本来就稀缺的小语种市场里，这一点尤其关键。这套流程建议固定成一份检查表存档，进新市场时直接照着跑，第二次做的时候通常两个小时就能收工，比第一次快得多。 ## 结构化数据里的别名字段填多少个合适 三到五个是合理区间。这个字段的作用是帮搜索引擎把不同的字符串归到同一个实体上，它需要的是准确而不是全面。填进去的每一个别名都应该是当地真实在用的形态，能在媒体报道或者平台商品标题里找到实例。把自己编出来的变体、几乎没人用的生僻拼法也堆进去，不会带来额外收益，反而会让这组信号显得不那么可信。具体填哪几个，按前面那份形态清单的量级排序取前几名就行。除了别名字段，还有两个配套字段值得一起填：一个是指向官方页面和权威第三方页面的引用关系，另一个是品牌所属组织的标识。三者合起来构成一个比较完整的实体描述。要提醒的是结构化数据本身不会直接改变排名，它的价值在于让实体识别更容易发生，而实体识别成立之后带来的好处，比如搜索建议收下你的别名、知识面板显示正确信息，才是真正有价值的部分。这个链条比较长，所以不要指望填完字段第二周就能看到变化。填完之后隔一两个月用富媒体测试工具复查一次，确认这些字段被正确解析，格式写错导致整块标记失效是很常见的低级失误。 ## 已经用错了主写法，改起来代价大吗 比想象中小，前提是操作方式对。很多人以为改主写法意味着要把旧形态的页面删掉或者做跳转，其实不需要。正确的做法是保留旧页面，只把新增内容和资源投放的重心移到新形态上。旧页面继续保持基本更新，不加码也不废弃，它承接的那部分流量一分钱没损失。三到六个月之后，新形态的内容量和外链量自然会超过旧的，重心的转移就完成了，全程没有任何一次风险动作。真正代价大的是另一种情况：把两个形态强行合并成一个页面，或者做大规模跳转。那会同时丢掉两边的历史信号，而且一旦判断有误几乎无法回滚。所以处理写法调整的原则是加法优先，不做减法。还有一点，改主写法要同步改的是对外发的新闻稿和给平台的商品标题模板，这两处是外部世界抄写法的源头，改了它们，外部的形态分布会慢慢跟着变，这比在自己站里改要有效得多。最后提醒一句，重心转移期间要给两套形态分别建报表视图，混在一起看的话，新形态的增长会被旧形态的自然波动淹没，看不出进展。 ## 拼错的形态需要做单独页面吗 不需要，也不建议。拼错形态的正确处理位置有三个，都不是独立页面。第一个是站内搜索的同义词表，把常见拼错映射到正确的品牌词上，用户在你站里搜错了也能出结果。第二个是站内搜索的无结果查询清单，定期导出来看有没有新的错法冒出来，这是最好的拼错来源。第三个是付费搜索的关键词列表，拼错形态在付费渠道里的成本极低而意图明确，是性价比很高的一组词。至于自然搜索结果，搜索引擎本身有很强的纠错能力，用户打错字通常会被自动纠正到正确形态上，你的正常页面就能接住，不需要为此单独建页。硬要给拼错形态建页面还有一个副作用，那些页面上必须反复出现错误拼写才能匹配，页面读起来会很奇怪，对品牌形象是负分。唯一的例外是某个拼错形态的量大到接近正确形态，且搜索引擎没有做纠正，这时候可以考虑在品牌页正文里以自然的方式提一句，但仍然不建议做独立页面。还有一个副作用值得一提，拼错形态如果被写进页面标题，站内搜索和商品数据源之间的对账会变得很麻烦，维护成本远超那点流量收益。 ## 多形态覆盖会不会稀释品牌页的权重 会不会稀释，取决于你是怎么覆盖的。如果做法是复制一批内容雷同的页面，每个页面换一个品牌名形态，那确实会稀释，因为几个页面在争同一批信号。如果做法是用一个页面承接多个形态，把不同写法自然地写进正文、小标题和结构化数据，那不但不稀释，反而是集中。判断的标准很清楚：这些形态背后的搜索意图是不是同一件事。同一件事就用一个页面，不同的事才分页面。品牌名的各种写法，绝大多数情况下背后是同一个意图，也就是找这个品牌，所以默认答案是集中到一个页面上。需要分开的情形不是因为形态不同，而是因为意图不同，比如一部分人找官网另一部分人比价，这时候分的依据是意图，不是写法。还有一个实操细节，一个页面承接多形态时，各形态在页面上的出现位置要有层次：主形态进标题和首段，次形态进正文和小标题，其余进结构化数据。全部堆在标题里既难看又没必要。实在拿不准的时候有个笨办法，把两种形态的搜索结果页并排截图存起来，过一个月再截一次对比，意图是不是同一件事看两轮就清楚了。 ## 母语审校能帮上多少忙 在品牌名这件事上，母语审校的作用比在普通文案上还大，但要问对问题。直接问这个音译名好不好，得到的多半是个人偏好，参考价值有限。要问的是三个具体问题：当地媒体一般怎么写这个牌子、你自己在搜索框里会打哪一种、有没有哪种写法看起来像是机器转出来的。第三个问题尤其有用，因为不自然的音译在本地人眼里非常刺眼，而这种刺眼感是任何工具都测不出来的。除了写法本身，审校还能帮你判断另一件重要的事：这个音译名在当地语言里有没有不好的谐音或者已有含义。这个问题在品牌进入市场之前必须问，事后发现的代价极高。最后一点，找审校的时候尽量找目标市场的普通消费者而不是语言学者，因为你要的是市场里的实际用法，不是规范里的正确用法，这两者在品牌名这个领域经常不一致，而搜索行为跟着的是前者。找审校还有个实用技巧，同一个问题问三个人，三个人答案一致的地方可以放心采用，答案分歧的地方就是这个市场里真实存在的写法分叉。 ## 权威参考资料 ## 网页字体在英文站只占几十KB，到了小语种站就变成拖慢首屏的最大一块 - URL：https://zhangwenbao.com/minor-language-web-font-glyph-set-first-screen-cost.html - 分类：小语种SEO - 发布：2015-12-08 | 更新：2026-07-26 - 摘要：小语种页面为什么加载更慢？讲清非拉丁字形集为何比拉丁大好几倍、子集化在哪些语言不能照搬、字体不加载在两类文字里的后果差别与按语言拆开的度量口径。 - 关键词：前端性能,多语言SEO,小语种SEO > **TLDR**：摘要：字体文件的体积不是一个固定值，它跟着语言走。一份拉丁字体装的是几百个字形，换成阿拉伯语要装上千个，换成印度诸语要装几千个，换成汉字要装上万个。字形数量之外还有排版表，连写、叠加记号、合体字各自需要一套规则数据。于是同一个设计、同一种格式，做英文站几十KB的文件，到小语种站变成几百KB甚至几MB。这篇把这笔账拆开算。 > 摘要：字体文件的体积不是一个固定值，它跟着语言走。一份拉丁字体装的是几百个字形，换成阿拉伯语要装上千个，换成印度诸语要装几千个，换成汉字要装上万个。字形数量之外还有排版表，连写、叠加记号、合体字各自需要一套规则数据。于是同一个设计、同一种格式，做英文站几十KB的文件，到小语种站变成几百KB甚至几MB。这篇把这笔账拆开算。 ## 同一个字体文件，换一种语言为什么会重好几倍？ ## 一份拉丁字体里到底有多少个字形 一个只支持英文的字重，大约需要两百到三百个字形。 大小写字母五十二个，数字十个，常用标点几十个。 再加上一批符号和几组常用的连写形式，就差不多了。 做成现代格式压缩之后，一个字重通常落在二十到四十KB。 要覆盖西欧语言的变音字母，字形数涨到五百上下。 体积跟着涨一半左右，仍在可以接受的范围。 这个数量级是很多性能建议的隐含前提。市面上大部分关于字体优化的经验值、预算建议和取舍结论，背后假设的都是这种规模的文件，直接搬到小语种站会得出完全错误的判断，因为分母根本不是一个量级。 这个数字还有个用处：它是判断一份字体是不是被人偷偷塞了多余内容的基准。有些商用字体为了通用性把多种文字打包在一份文件里，只做英文站的团队完全不知道自己下发了一堆用不上的字形。 ## 换成非拉丁文字之后这个数怎么涨 西里尔字母加上去，再多两百多个字形。 希腊字母加上去，又是几百个，带重音的形态还要另算。 阿拉伯字母系统一旦加进来，数量直接跳到上千。 泰文、天城文这类文字，字形数在一千到两千之间。 汉字就完全是另一个量级，常用集就有几千个。 日文还要再叠上两套假名和大量专用符号。 把这几档排成一个梯度看会更直观：英文两三百、欧洲全覆盖五百、阿拉伯语一千五、泰文两千、韩文一万一千多个音节、汉字常用集六千起。每上一档，文件体积大致跟着翻一倍到几倍，这个梯度决定了各语言版本的性能预算不可能是同一个数。 要拿到自己这份字体的确切字形数不难，任何字体编辑工具打开都能看到。花五分钟把在用的每一份都数一遍，写进一张表，比引用任何外部经验值都可靠，因为设计繁简与覆盖范围各家差别很大。 这个梯度还解释了一个常见的困惑：为什么同一套设计规范落到不同市场，前端给出的排期差别那么大。字形集大的语言不只是文件重，配套的测试、子集验证和回退方案也全都更费工，工作量不是按语言数线性叠加的。 ## 体积不是线性关系，还要加上排版表 字形数据只是文件的一部分，另一部分是排版规则表。 这些表告诉渲染引擎哪些字符要替换成哪个形态、位置怎么调。 拉丁文字用到的规则很少，表基本可以忽略不计。 阿拉伯文字要靠这些表决定每个字母用哪个形态。 泰文和天城文要靠它们把元音记号放到正确的位置。 所以这些表在非拉丁字体里占的比例相当可观。 这一点直接推翻了一个常见的直觉：以为只要把用不到的字形删掉，文件就会瘦得跟拉丁字体差不多。规则表跟字形不是一一对应的，删掉一半字形并不会让表也小一半，某些情况下表根本不能动。 还有一类数据也常被忽略：字距调整表。它记录成对字符之间的间距微调，对数量的规模是字符数的平方级别，覆盖多种文字的字体里这张表可以大到跟字形数据同一个量级。 ## 非拉丁文字的字形集大在哪几处？ ## 一个字母四种呈现形态 阿拉伯字母系统里，字母的形状取决于它在词里的位置。 独立时一种，词首一种，词中一种，词尾又是一种。 二十八个基础字母，光形态就要几十上百个字形。 再算上波斯语等语言追加的字母，数量继续往上走。 这些形态在编码里有专门的呈现形式区做过映射。 现代做法是只存基础字符，形态由排版表在渲染时决定。 为什么会有那个呈现形式区，原因在早期：那时的渲染系统不具备实时替换的能力，只能把每一种形态都当成独立字符编进去。呈现形式区的码表 (https://www.unicode.org/charts/PDF/UFB50.pdf)今天主要用于兼容老数据，字体里通常不再需要为它们单独造字形。 形态替换是渲染时实时完成的，这意味着渲染引擎的实现质量直接影响结果。同一份字体在不同浏览器上的连写表现可能有细微差别，验收时至少要覆盖目标市场占比最高的两个浏览器内核。 ## 连字与必需连写 有些字母组合在书写传统里必须连成一个整体。 这类组合不是可选的美化，是正字法的要求。 每一个必需连写都要在字体里造一个独立的字形。 常见的必需连写有几十组，讲究一点的字体会做上百组。 如果字体里没有，渲染出来的文字本地人一眼就看出不对。 这部分字形没有任何删减空间。 拉丁字体里也有连写，但那些几乎全是可选的排版效果，删掉只是少了点精致感，读起来完全没问题。两者的性质完全不同，做取舍时不能用同一个标准去衡量，这是子集化最容易出事的地方之一。 判断某个连写是必需还是可选，最可靠的依据是这门语言的正字法文献，其次是本地主流出版物的排版惯例。凭感觉判断很容易把必需的当成可选的删掉，而这类错误在本地用户眼里相当刺眼。 ## 上下叠加的记号需要定位表 泰文的元音和声调符号写在辅音的上方和下方。 叠加的层数最多可以到两层，位置要精确。 不同辅音的高度不同，记号的落点要跟着调整。 这套调整规则全部写在定位表里。 定位表被裁掉的话，记号会重叠或者飘到错误的位置。 越南语的双记号叠加也依赖同一类规则。 这跟带声调符号的文字里记号写在哪个元音上 (https://zhangwenbao.com/vietnamese-seo-tone-marks-syllable-spacing-keyword.html)是一体两面：正字法规定记号该在哪，定位表负责把它画在哪，两者对不上时页面上呈现的就不是用户预期的那个词。 定位表出问题时有个特征可以帮助识别：错误是系统性的而不是随机的，所有相同结构的字符都错在同一个方向上。看到整页的记号都偏高或者偏左，基本可以确定是表的问题而不是个别字形缺失。 ## 合体字与音节组合 印度诸语里，辅音连缀会合成一个新的字形。 两个辅音合一个，三个辅音再合一个，组合数量很大。 做得完整的字体要造上千个合体字形。 韩文的情况不同，它是把字母拼成方块音节。 理论上的音节组合有一万多个，实际常用的也有两千多。 字体可以选择存组件动态拼，也可以存现成的音节。 两种做法的取舍很有意思：存组件文件小但对渲染引擎要求高，存音节文件大但兼容性好。低端设备上后者更稳，而低端设备恰恰是这些市场的主力机型，于是体积和稳定性之间的矛盾在这里格外尖锐。 选哪种做法还要看内容的实际用字范围。如果站上的内容只涉及商品名和常规文案，实际用到的音节数远小于理论组合数，存现成音节的方案配上子集化，体积可以压到比想象中小得多。 合体字数量还会影响一件容易被忽略的事：字体加载失败时的降级表现。缺了合体字形的渲染结果不是方框而是拆开的单个辅音，本地用户读起来像是把词拼错了，比直接显示方框更容易被误解成内容质量问题。 ## 子集化在小语种上为什么不能照搬拉丁语的做法？ ## 拉丁语可以按字符频率裁，非拉丁不行 拉丁文字的做法是统计页面上实际用到的字符再裁。 因为字符和字形基本一一对应，裁掉就是省掉。 非拉丁文字里，一个字符可能对应四五个字形。 裁字符不等于裁字形，还要判断哪些形态会被用到。 而形态会不会被用到，取决于这个字符出现在词的什么位置。 词的位置又是内容决定的，静态分析算不准。 稳妥的做法是保留某个字符的全部形态，只在字符层面做裁剪。这样省下来的空间比拉丁文字少得多，但至少不会渲染错。想再往下压就必须实测，拿真实内容渲染一遍比对结果，光靠工具的默认设置不够。 动态生成子集是另一条路：服务端按页面实际内容实时生成对应的子集文件。它的省流量效果最好，代价是缓存基本失效，每个页面都要下一份新文件，对多页面浏览的电商站通常得不偿失。 ## 删掉排版表会渲染错 子集化工具默认会保留用到的排版规则。 但工具的判断依据是输入的字符集合，不是真实内容。 字符集合里少一个字符，相关的连写规则可能被整条删掉。 结果是大部分文字正常，个别词的连写没了。 这类错误极难被发现，因为页面整体看起来是好的。 只有懂这门语言的人才会注意到某个词写得不对。 防这类错误有个实用办法：准备一段专门用来测试的文本，把已知需要连写的组合都塞进去，每次子集化之后渲染这段文本截图比对。这段文本一次准备好可以长期复用，成本极低。 子集化工具的选项里通常有一个保留全部排版规则的开关。在弄清楚具体影响之前，先把这个开关打开是明智的，省下的那点体积远远抵不上渲染出错的代价，等测试体系建起来之后再考虑收紧。 ## 数字属于另一个码位区间，最容易漏 不少语言有自己的一套数字符号。 它们在编码里位于跟字母不同的区间。 子集化时如果只按字母范围取，数字就整组丢了。 丢了之后价格和规格全变成方框，后果非常明显。 好在这类错误一眼就能看见，不会静悄悄地留在线上。 把数字区间显式写进子集配置，一劳永逸。 波斯语和阿拉伯语各有各的数字区间，两套都要收进去，这跟波斯语与阿拉伯语在数字形态上的分叉 (https://zhangwenbao.com/persian-seo-iran-market-letters-digits-zwnj.html)是同一件事的两个侧面：内容层要处理查询归一，字体层要保证两套都画得出来。 同样容易漏的还有标点。不少语言有自己的逗号、问号和引号形态，它们跟拉丁标点是不同的码位。漏掉之后正文里会零星出现方框，比整段乱掉更难被发现，因为量少且分散。 ## 组合记号被裁掉的后果 有些字符在存储时是基字母加一个独立的记号。 渲染时靠定位表把记号叠到基字母上。 如果记号字形被裁掉，屏幕上会出现基字母加一个方框。 如果定位表被裁掉，记号会画在错误的位置。 两种情况用户看到的都是错的，但表现完全不同。 排查时先看是缺字形还是缺规则，两者的修法不一样。 这里还要注意存储形式的问题：同一个带记号的字符可能以预组合形式存，也可能以基字母加记号的分解形式存。子集配置里只写了预组合形式的话，分解形式的内容照样会缺字形，两种形式都要覆盖到。 要覆盖两种存储形式，最简单的办法是把内容先做一次统一的规范化处理再统计字符集。这样统计出来的集合是确定的，子集配置也就跟着确定了，而不是依赖内容当时恰好用了哪一种写法。 ## 字体不加载的后果，在两类文字里不是一回事 ## 拉丁文字回退到系统字体仍然可读 拉丁文字的系统字体覆盖是完整的，任何设备都有。 自定义字体没加载出来，用户看到的只是另一种字体。 字形不同、字宽不同，但每个字都认得出来。 所以拉丁文字站点在这件事上的容错空间很大。 很多性能建议默认了这个前提，才敢让文字先用系统字体显示。 换到非拉丁文字，这个前提要重新验证。 通用的加载策略本身跟语言无关，那部分不在这里展开；这一篇只回答一个问题：把这个策略换到非拉丁文字上，回退时的可读性还能不能得到保证。答案在不同语言里差别很大。 不过拉丁文字也不是完全没有陷阱：如果站点用到了较少见的变音字母，某些系统字体的覆盖也未必完整。中东欧语言的一些字母就属于这一类，回退时会出现个别方框，比整体回退更容易被忽略。 ## 非拉丁文字可能直接回退成方框 如果系统里没有覆盖这套文字的字体，回退就是方框。 方框不是难看的问题，是完全不可读。 用户看到的是一整页整齐排列的空盒子。 这种情况在老设备和某些精简系统上确实会出现。 此时先显示文字反而不如先什么都不显示。 因为一页方框给人的印象是页面坏了，用户会直接离开。 判断自己的市场属于哪种情况，靠的是实测而不是推断。找几台目标市场的主流低端机，把自定义字体禁掉打开页面看一眼，五分钟就能得出结论，而这个结论直接决定了加载策略该怎么选。 方框的出现还有个次生影响：它们的宽度跟真实字形不同，整段文字的排版会跟着变，等字体加载完成之后页面会有一次大幅度的重排，用户正在读的位置直接跑掉，体验比单纯的延迟糟糕得多。 还有一种中间状态更麻烦：系统里有覆盖这套文字的字体，但缺少某些扩展字符。此时页面上大部分正常、个别字是方框，运营看一眼觉得没问题就上线了，实际影响的往往正是那些带专有字母的品类词。 ## 闪烁与遮挡两种策略在这里的取舍 先显示回退字体再换过来，好处是内容立刻可读。 代价是字体换过来的瞬间版面会跳一下。 先不显示等字体到位，好处是没有跳动。 代价是这段时间里用户什么也看不到。 拉丁文字通常选前者，因为回退可读。 非拉丁文字要看回退能不能读，读不了就只能选后者。 还有一层是字宽差异带来的跳动幅度。非拉丁文字的回退字体跟自定义字体在字宽上的差距，往往比拉丁文字大得多，切换时整段文字重新排版，跳动幅度可能是好几行，观感比拉丁文字站上的同类跳动糟糕得多。 还有一条中间路线：给回退字体设置跟自定义字体接近的字宽调整参数，让两者占的空间尽量一致，切换时的跳动就能明显减小。这条路在拉丁文字上很成熟，在非拉丁文字上调起来更费劲但同样有效。 ## 系统自带字体能不能省掉这个文件？ ## 各平台对非拉丁文字的覆盖差别 主流移动系统对常见文字的覆盖已经不错。 阿拉伯语、泰语、天城文这几种基本都有内置字体。 但覆盖到不等于好看，内置字体的设计质量参差不齐。 更麻烦的是同一种文字在不同平台上的内置字体差别很大。 同一个页面在两个平台上的观感可能完全不同。 如果品牌对视觉一致性有要求，就绕不开自带字体文件。 这里可以做一个成本对照：视觉一致性的收益是可感知但难量化的，而字体文件带来的加载代价是可以精确测出来的。把两边摆在一起谈，比单纯讨论要不要用自定义字体容易达成共识得多。 做判断之前值得先问一句品牌方到底在意到什么程度。有些品类的用户根本不会注意字体差别，此时用系统字体是完全合理的选择，把省下的加载时间换成更快的首屏，收益比视觉一致性大得多。 ## 低端设备上的覆盖更差 低价机型为了节省存储，内置字体常被裁减。 裁减的方式通常是删掉不常用的文字系统。 某些区域定制的机型只保留本地语言和英文。 这对本地市场是好事，对跨语言的站点是坏事。 用户设备的语言覆盖跟你的页面语言未必对得上。 这类问题在真机测试里能发现，在模拟器上发现不了。 低端设备还有一个连带影响：字体文件下载完还要解析，解析要占内存和处理时间。几百KB的文件在旗舰机上解析不到十毫秒，在低端机上可能要几十甚至上百毫秒，这段时间同样卡着首屏。 测试机的选择要按目标市场的实际机型分布来，而不是按团队手里现有的设备。这两个分布通常差得很远，用国内常见的中高端机测东南亚或者中东市场，得出的结论基本没有参考价值。 还有一类设备容易被漏掉：车机、电视盒子和部分平板的定制系统，它们的字体覆盖比手机更窄，而这类设备在某些市场的访问占比并不低。抽查时把它们纳入进来，成本只是多借两台机器。 ## 回退链要写几层、按什么顺序 回退链的第一位写自定义字体。 第二位写目标平台上质量最好的那款内置字体。 第三位写另一个平台的对应内置字体。 最后写一个通用的族名兜底。 写四层通常够用，写太多反而增加匹配成本。 每一层都要在真机上验过确实存在。 还有个容易忽略的细节：回退链里的字体如果不支持页面上的某些字符，浏览器会逐个字符去链里找，结果是同一段文字里不同的字用了不同的字体，观感非常混乱。所以回退链里的每一款都应该覆盖完整的字符集。 不同语言版本的回退链应该分别定义，不要写一条通用的塞给所有语言。一条通用回退链要么长得离谱，要么对某些语言完全无效，按语言各写一条虽然多花点功夫但每一条都能真正生效。 ## 首屏上真正被字体拖住的是哪几个元素？ ## 标题、价格、导航三处的先后 标题是首屏上最先被看到的文字，优先级最高。 价格是决定用户去留的关键信息，优先级同样高。 导航文字虽然在顶部，但用户不会立刻去读。 正文在首屏下方，可以最后加载。 按这个顺序安排，能明显改善感知速度。 感知速度跟实际加载时间不是一回事，前者才影响判断。 具体做法是把标题和价格用到的字符单独做一个极小的子集先加载，正文字体延后。这个小子集在拉丁文字上省不了多少，因为本来就小；在非拉丁文字上省下的比例非常可观，这是少数几个语言差异带来正向收益的地方。 判断哪些元素属于首屏，要按目标市场的主流屏幕尺寸算，不要按设计稿的画布尺寸算。这两个数在低端机占比高的市场差别很大，按设计稿判断会把实际上在首屏之外的元素也算成高优先级。 ## 图标字体是另一个被忽略的来源 不少站点用字体的方式来实现图标。 图标字体本身的体积不大，但它是一个额外的请求。 而且它通常在样式表里被引用，会阻塞渲染。 小语种站的字体请求本来就更重，再加一个更雪上加霜。 把图标改成矢量图形内联，能省掉一整个请求。 这一改跟语言无关，但在小语种站上收益更明显。 还有个连带好处：图标字体在回退时会显示成随机的字符，因为那些码位在普通字体里对应的是别的东西。非拉丁文字的页面上出现几个莫名其妙的字母，比拉丁文字页面上更突兀。 如果暂时改不动图标方案，至少可以把图标字体的加载改成不阻塞渲染的方式。图标晚出现几百毫秒对用户几乎没有影响，而文字晚出现同样的时间影响就很大，两者的优先级不该相同。 ## 正文字体可以延后，标题不行 正文在首屏可见区域之外，延后加载没有代价。 标题在首屏正中，延后就是让用户盯着空白。 所以两者应该拆成两个文件分别处理。 拆开之后标题文件可以做得非常小。 因为标题用到的字符是有限且可以预知的。 这个思路在字形集庞大的语言里效果最好。 不过要注意标题字符的可预知程度跟内容类型有关。分类页的标题来自固定的类目名，可以预知；商品详情页的标题来自商品名，几乎不可预知。前者能做极致的小子集，后者只能退回到常用字集。 商品名不可预知这件事还有个折中解法：统计站上全部商品名用到的字符集合，通常会发现它比语言全集小很多，用这个集合做子集既覆盖了所有商品又比全集小得多，代价只是新增商品时要定期重新生成。 ## 格式与压缩能省下多少？ ## 三种格式的体积差 最老的那种格式基本没有压缩，体积最大。 上一代的网页字体格式做了一层压缩，能省三成左右。 新一代格式换了压缩算法，比上一代再省三到四成。 字形数越多，新格式的相对优势越明显。 对小语种站来说，换格式是投入产出比最高的一步。 新一代网页字体格式的规范 (https://www.w3.org/TR/WOFF2/)里给出了压缩方式的细节。 值得注意的是这个格式在2015年还不是所有浏览器都支持，需要同时提供上一代格式作为备选。备选文件不会被支持新格式的浏览器下载，所以不必担心重复传输，代价只是多准备一份文件。 换格式这一步几乎没有副作用，是少数可以放心先做的动作。唯一要注意的是服务端要正确声明文件类型，声明错了浏览器可能拒绝加载，而这个错误在开发环境里往往不会暴露。 另外记得把老格式的文件也做同样的子集处理。有些团队只对新格式做了子集化，备选文件仍是完整版，结果不支持新格式的那批用户下载的反而是最大的那个文件，优化对他们完全没有生效。 ## 压缩对不同文字的效果不一样 压缩算法擅长处理重复的模式。 拉丁字母的轮廓数据里重复模式较多，压缩率高。 汉字的轮廓复杂且相似度低，压缩率明显更低。 阿拉伯语的四形态之间有大量相似结构，压缩率反而不错。 所以不能拿一个统一的压缩比去估算各语言的体积。 各语言各测一次，把真实数字写进文档。 测的时候要用同一款字体的不同语言版本做对比，不要拿不同设计的字体互相比。设计的繁简程度对体积的影响不小，混在一起比会得出误导性的结论，把设计差异算到语言头上。 还有一层是传输时的二次压缩。字体的新格式内部已经压过一轮，服务器再压一次收益很小甚至可能是负的，配置里应该把字体文件排除在通用压缩之外，省下服务器的处理时间。 把各语言的压缩率测出来之后，可以顺手推算一个更有用的数：每增加一门语言，字体这一项要多花多少预算。这个数字拿去做市场扩张的决策讨论非常有说服力，比笼统地说小语种站更慢有效得多。 ## 传输之外还有解析成本 文件下载完之后要解析成内存里的结构。 解析时间跟字形数和排版表的规模都有关系。 字形上万的字体，解析本身就要花掉可观的时间。 这段时间在网络监控里看不到，容易被漏掉。 要量它只能在真机上测渲染时间线。 低端设备上这部分占比会更高。 这也是子集化除了省流量之外的第二个理由：字形少了解析也快。在弱网环境里流量是主要矛盾，在低端设备加良好网络的环境里解析反而成了主要矛盾，两种情况都指向同一个动作。 解析成本还跟字体的内部结构有关。同样的字形数，组织方式不同解析速度可以差出不少，这一点用户无从选择，只能在选型时把候选字体各自在低端机上测一遍实际渲染时间。 ## 分片在小语种上的边界怎么划？ ## 按码位区间分片的原理 分片的做法是把一个大字体切成若干个小文件。 每个小文件声明自己覆盖哪个码位区间。 浏览器只下载页面上实际用到的那几片。 字体模块的规范 (https://www.w3.org/TR/css-fonts-3/)里定义了声明覆盖范围的描述符。 这个能力在2015年的浏览器里支持程度不一致。 不支持的浏览器会把所有分片都下载下来，反而更慢。 所以在这个阶段用分片要先确认目标市场的浏览器分布。如果主流浏览器的支持率不够，分片带来的收益会被不支持的那部分用户的额外下载抵消掉，整体反而是负的。 分片方案的另一个好处是缓存效率。用户访问站内多个页面时，已经下载过的分片会被复用，只有遇到新字符才下载新片。这个收益在多页面浏览的场景里会随访问深度累积，单看首屏数据体现不出来。 ## 一个词跨两个分片会怎样 分片的边界是按码位划的，不是按语言划的。 一个词里的字符如果分属两个码位区间，就要下载两片。 混排的内容天然会跨片，比如本地文字加拉丁型号。 跨片本身不影响正确性，只是多一个请求。 但如果两片的加载时间差很大，会出现半段文字先显示的现象。 这种半段渲染在视觉上比整段延迟更难看。 可以通过把常一起出现的码位区间合并成一片来缓解。比如把本地文字和基本拉丁字母放在同一片里，代价是这一片变大，但避免了混排内容的跨片问题，对电商站通常是划算的。 半段渲染在从右往左的页面上更难看，因为先出来的那半段位置会随着后半段的到达而整体移动。这类问题跟窄屏上混排内容的折行错位 (https://zhangwenbao.com/arabic-rtl-mobile-first-narrow-screen-pitfalls.html)叠加之后，观感会成倍变差。 ## 哪些语言适合分片、哪些不适合 字形集极大的语言最适合分片，比如汉字和日文。 因为任何一个页面用到的字符都只是全集的很小一部分。 字形集中等的语言分片收益有限。 阿拉伯语这类必须保留完整形态表的语言，分片会带来麻烦。 因为形态表是跨字符的，切开之后规则可能失效。 这类语言更适合做一次性的整体子集。 判断依据可以简化成一句话：字符之间彼此独立的语言适合分片，字符之间有渲染依赖的语言不适合。同时使用三套文字的语言 (https://zhangwenbao.com/japanese-seo-hiragana-katakana-kanji-keyword-notation.html)属于前者，可以按三套文字分开分片，收益很大。 还有一类需要单独判断的是没有空格分词的文字。这类内容的用字范围通常比预想的分散，因为词与词之间没有边界提示，内容里出现生僻字的概率更高，不用空格分词的语言 (https://zhangwenbao.com/thai-seo-no-spaces-word-segmentation-keyword.html)做分片时要把分片划得宽一些。 ## 分片带来的请求数问题 分片越细，请求数越多。 请求数多了之后，连接建立的开销开始变得可观。 在高延迟的移动网络上，这个开销尤其明显。 所以分片的粒度要在文件大小和请求数之间取平衡。 经验上一个页面触发的字体请求不宜超过三四个。 超过这个数就该考虑合并。 这个平衡点跟目标市场的网络质量直接相关。网络条件好的市场可以分得细一点，网络条件差、延迟高的市场应该合并成更少的大文件，宁可多传一点数据也要少建几次连接。 请求数还要跟页面上其他资源的请求合并起来看。字体请求跟脚本、样式表争抢的是同一批连接，单独优化字体请求数而不看全局，很可能只是把瓶颈从一处挪到了另一处。 ## 怎么量：一套按语言拆开的度量口径 ## 全站平均值会骗人 大部分站点的流量集中在主语言上。 全站的平均加载时间基本反映的是主语言的表现。 小语种版本再慢，也拉不动这个平均值。 所以看全站数字的结论永远是一切正常。 只有把数据按语言拆开，问题才会显形。 拆开之后往往会发现差距大得出乎意料。 这跟按设备拆分的道理一样，只是维度不同。按语言分面做灰度与观测 (https://zhangwenbao.com/arabic-rtl-mobile-first-narrow-screen-pitfalls.html)那套方法在这里同样适用，指标换成加载相关的即可。 更隐蔽的是采样偏差。性能数据的采集往往依赖前端上报，而加载失败或者用户提前离开的会话根本不会上报，小语种版本恰恰是这类会话比例更高的，于是数据不但被平均掉，剩下的样本还是偏好的那一批。 ## 按语言分面的四个指标 第一个是字体文件的总字节数。 第二个是字体请求的数量。 第三个是首屏主要文字可读的时间点。 第四个是字体切换造成的版面跳动幅度。 四个指标各语言各测一份，做成一张对照表。 表里差距最大的那一行就是下一步该动的地方。 第四个指标最容易被漏掉，因为它不在常规的性能面板里。测它的办法是录屏之后逐帧看文字位置的变化，虽然笨但可靠，而且这个指标在非拉丁文字上的数值通常远高于拉丁文字。 四个指标之外可以再记一个辅助数字：字体请求的失败率。跨境访问时字体文件来自哪个节点、有没有被中间环节干扰，各市场差别很大，失败率高的市场再怎么优化体积也没用，得先解决可达性。 指标要跟版本一起记录，也就是每次字体文件更新都留一行。字体是那种一旦上线就没人再动的资源，几年后回头看根本说不清中间经历过哪些调整，有了这份记录，排查历史问题时能省下大量猜测。 ## 给每个语言版本单独定预算 统一的性能预算对小语种版本是不公平的。 因为字体这一项的下限本来就不一样。 正确做法是按语言分别定预算，字体那一项各算各的。 预算定得太紧会逼团队做出伤害可读性的取舍。 定得太松则失去了约束作用。 合理的做法是先测出各语言的实际值，再按此设定收紧目标。 预算文档里要写清楚这个数为什么是这个数，把字形数量的差别写进去。否则半年后换了人接手，看到小语种版本的预算比主语言宽松，第一反应会是有人在偷懒，然后又要把整件事重新解释一遍。 预算的执行要落到具体的检查点上，比如构建时自动比对字体文件大小、超过阈值就报警。写在文档里而没有自动检查的预算，半年内一定会失效，这跟任何依赖自觉的流程是一样的下场。 ## 哪些不归语言层，要交出去 ## 通用的性能优化归技术层 图片压缩、脚本拆分、缓存策略这些跟语言无关。 它们该怎么做，换成任何语言的站点都一样。 这一篇只讲字形集这个语言变量带来的额外部分。 把两者混在一起讲，结论会变得含糊。 分开之后，语言层要做的事其实很集中。 就是字形集、子集边界、回退链这三件。 判断某个动作归不归这里，用同一条判据：把语种换成英语还成不成立。图片压缩换成英语照样要做，不归这里；子集化时要不要保留连写规则，换成英语这个问题根本不存在，归这里。 这条判据还能反过来用来排优先级：通用优化的收益在所有语言版本上是共享的，语言层优化的收益只落在单个市场。所以当两类工作抢资源时，先做通用的那一批通常更划算，除非某个小语种市场的问题已经严重到影响可用。 ## 移动端的判定与架构 页面在窄屏上快不快，是通用的技术议题。 它的判定方式与权重变化有专门的讨论。 可以参考移动友好判定的来龙去脉 (https://zhangwenbao.com/google-mobilegeddon-mobile-friendly-update-explained.html)与首屏内容的版面机制 (https://zhangwenbao.com/above-the-fold-content-seo-page-layout-mechanism.html)。 多语言站的目录结构与语言地区标注同样是架构问题。 按多语言站的架构与标注 (https://zhangwenbao.com/international-seo-hreflang-complete-guide.html)那套走即可。 本篇涉及架构的只有一处：不同语言版本要能加载各自的字体。 这属于资源分配，跟目录结构无关。 实现上有个常见的疏漏：字体的引用写在全站共用的样式表里，于是每个语言版本都下载了所有语言的字体。检查这一条只需要看一眼网络面板里的请求列表，出现了当前页面用不到的字体就是中了。 还有一个跟架构相关的疏漏是缓存策略。字体文件适合设很长的缓存有效期并用文件名带指纹的方式更新，但不少站点把它跟页面资源用同一套缓存规则，导致用户每隔几天就要重新下载一次几百KB的文件。 ## 字体授权与设计选型 非拉丁文字的字体选择本来就比拉丁文字少得多。 可用的字重、字宽和风格变体都更有限。 商业授权按字形数计价的情况也存在。 这些属于采购与设计的决策，不在这里展开。 需要提醒的只有一点：选型时把体积作为一个硬指标。 设计上稍作让步换来的加载收益，在这些市场往往更值。 选型时还可以关注一下字体项目本身的维护状态。覆盖多种文字的开源字体项目通常会持续补充字符和修正排版表，选一个在维护的项目，意味着以后遇到缺字形的情况还有解决途径，而不是只能自己改。 另外要确认授权是否覆盖网页嵌入这种用法。不少字体的桌面授权不包含网页嵌入，而这两类授权的价格差别不小，采购时如果没说清楚，等到上线后才发现就只能临时换字体，整套子集化和测试都要重做。 ## 常见问题解答 ## 小语种站的字体文件到底比英文站大多少？ 按字形数量大致可以排出一个梯度：只支持英文的字重两百到三百个字形、覆盖西欧语言五百上下、阿拉伯字母系统上千、泰文与天城文一千到两千、韩文如果存现成音节有两千多、汉字常用集六千起。每上一档，文件体积大致跟着翻一倍到几倍。但体积的增长不完全来自字形数，还要加上排版规则表，这些表告诉渲染引擎哪个字符该换成哪个形态、记号该放在什么位置，在阿拉伯文字和泰文这类语言里占的比例相当可观，而拉丁文字里基本可以忽略。所以那些流传很广的字体优化经验值背后假设的都是几十KB的拉丁字体，直接搬到小语种站会得出完全错误的判断。正确做法是各语言各测一次，把真实数字写进文档，用同一款字体的不同语言版本做对比，别拿不同设计的字体互相比。数自己那份文件的字形数只要五分钟，任何字体编辑工具打开都能看到，比引用任何外部经验值都可靠。 ## 子集化能不能像英文站那样激进地裁？ 不能，非拉丁文字的子集化有三条硬边界。第一条是一个字符可能对应四五个字形，裁字符不等于裁字形，而某个形态会不会被用到取决于这个字符出现在词的什么位置，静态分析算不准，稳妥做法是保留某个字符的全部形态只在字符层面裁剪。第二条是排版规则表不能随便删，工具的判断依据是输入的字符集合而不是真实内容，字符集合里少一个字符可能让整条连写规则被删掉，结果是大部分文字正常、个别词的连写没了，这类错误只有懂这门语言的人才看得出来。第三条是很多语言的数字在跟字母不同的码位区间，只按字母范围取会把数字整组丢掉。防这些错误的实用办法是准备一段专门的测试文本，把已知需要连写的组合和各类数字都塞进去，每次子集化之后渲染这段文本截图比对。在弄清楚具体影响之前，先把工具里保留全部排版规则的开关打开，省下的那点体积远抵不上渲染出错的代价。 ## 让文字先用系统字体显示，这个建议在小语种站成立吗？ 要看这门文字在目标设备上有没有可用的回退字体，答案在不同语言里差别很大。拉丁文字的系统覆盖是完整的，字体没加载出来用户看到的只是另一种字体，每个字都认得出来，容错空间很大，那些性能建议默认的就是这个前提。非拉丁文字如果系统里没有覆盖这套文字的字体，回退就是一整页方框，不是难看而是完全不可读，用户的第一反应是页面坏了然后直接离开，这种情况下先什么都不显示反而更好。判断自己的市场属于哪种情况靠实测不靠推断：找几台目标市场的主流低端机，把自定义字体禁掉打开页面看一眼，五分钟就能得出结论。还要额外考虑字宽差异，非拉丁文字回退字体与自定义字体的字宽差距往往更大，切换时整段重排的跳动幅度可能是好几行。还有一条中间路线是给回退字体设置接近的字宽调整参数，让两者占的空间尽量一致，切换时的跳动能明显减小。 ## 首屏字体该怎么拆才能既快又不难看？ 把标题和价格用到的字符单独做一个极小的子集优先加载，正文字体延后。理由是标题在首屏正中，延后就是让用户盯着空白；正文在可见区域之外，延后没有代价。这个拆分在拉丁文字上省不了多少因为本来就小，在非拉丁文字上省下的比例非常可观，是少数几个语言差异带来正向收益的地方。要注意标题字符的可预知程度跟内容类型有关：分类页的标题来自固定的类目名可以完全预知，能做极致的小子集；商品详情页的标题来自商品名几乎不可预知，只能退回到常用字集。另外别忘了图标字体，它体积不大但是一个额外的阻塞请求，改成矢量图形内联能省掉一整个请求，而且避免了回退时显示成莫名其妙字符的问题。商品名的字符集合通常比语言全集小很多，用这个集合做子集既覆盖了所有商品又比全集小，代价只是新增商品时要定期重新生成。 ## 按码位分片这个做法值不值得用？ 要看语言和浏览器分布两个条件。语言这边的判据可以简化成一句话：字符之间彼此独立的语言适合分片，字符之间有渲染依赖的语言不适合。汉字、日文这类字形集极大且字符独立的最适合，任何一个页面用到的都只是全集的很小一部分；阿拉伯语这类必须保留完整形态表的不适合，切开之后跨字符的规则可能失效。浏览器这边要确认目标市场的支持率，不支持的浏览器会把所有分片都下载下来反而更慢，收益会被抵消。还有两个实操细节：混排内容天然跨片，把本地文字和基本拉丁字母合并到同一片能避免半段渲染；分片粒度要看网络质量，高延迟市场应该合并成更少的大文件，宁可多传数据也要少建连接，一个页面的字体请求不宜超过三四个。分片的另一个收益在缓存上，用户访问站内多个页面时已下载的分片会被复用，这部分好处单看首屏数据体现不出来。 ## 为什么全站的性能数据看起来都正常？ 因为流量集中在主语言上，全站平均值基本反映的是主语言的表现，小语种版本再慢也拉不动这个平均值，所以看全站数字的结论永远是一切正常。必须按语言把数据拆开，拆开之后往往会发现差距大得出乎意料。建议固定看四个分语言指标：字体文件的总字节数、字体请求的数量、首屏主要文字可读的时间点、字体切换造成的版面跳动幅度。第四个最容易被漏掉因为它不在常规的性能面板里，测它要录屏之后逐帧看文字位置的变化，虽然笨但可靠，而且这个数值在非拉丁文字上通常远高于拉丁文字。四个指标做成一张按语言排的对照表，差距最大的那一行就是下一步该动的地方。性能预算也要按语言分别定，字体那一项各算各的，并在文档里写清楚这个数为什么是这个数。还要留意采样偏差，加载失败或提前离开的会话根本不会上报，而小语种版本恰恰是这类会话比例更高的那一批。 ## 预算有限时，这几件事该按什么顺序做？ 第一步换格式，这是投入产出比最高的一步，改一次配置就能省掉三到四成，字形数越多相对优势越明显，同时保留上一代格式作为备选，不支持新格式的浏览器才会去下载它。第二步做保守的子集化，只在字符层面裁剪、保留全部形态和排版表，配上那段测试文本做验证。第三步拆分首屏字体，把标题和价格的小子集单独提出来优先加载。第四步整理回退链，四层结构写清楚并在真机上逐层验过存在。第五步才是考虑分片，因为它的收益依赖语言特性和浏览器支持率，前面四步在任何语言上都稳定有效。整个过程中把按语言分面的四个指标测下来，每做完一步更新一次，这样每一步的收益都能单独看到，而不是做完一大堆改动之后说不清是哪一项起了作用。每一步做完都把四个分语言指标更新一次，这样收益能逐步归因，而不是做完一大堆改动之后说不清是哪一项起了作用。 ## 权威参考资料 ## 波斯语和阿拉伯语共用一套字母，伊朗人常打的那四个字母阿拉伯语里没有 - URL：https://zhangwenbao.com/persian-seo-iran-market-letters-digits-zwnj.html - 分类：小语种SEO - 发布：2015-09-29 | 更新：2026-07-26 - 摘要：波斯语SEO跟阿拉伯语差在哪？讲清多出的四个字母、两套码位怎么在索引里对齐、波斯数字与阿拉伯数字的分叉、半连接符的处理与借词的意思漂移。 - 关键词：关键词研究,多语言SEO,小语种SEO > **TLDR**：摘要：波斯语借用了阿拉伯字母，但它是印欧语系的语言，语法、构词和词汇跟阿拉伯语都不是一回事。字母表里多出四个阿拉伯语没有的字母，两个常用字母各有两套码位，数字还是另一组符号，词里又夹着一个既不是空格也不是连写的半连接符。这四件事决定了阿拉伯语的词表在伊朗市场用不了。这篇把它们逐条讲清楚。 > 摘要：波斯语借用了阿拉伯字母，但它是印欧语系的语言，语法、构词和词汇跟阿拉伯语都不是一回事。字母表里多出四个阿拉伯语没有的字母，两个常用字母各有两套码位，数字还是另一组符号，词里又夹着一个既不是空格也不是连写的半连接符。这四件事决定了阿拉伯语的词表在伊朗市场用不了。这篇把它们逐条讲清楚。 ## 共用一套字母，为什么关键词表不能共用？ ## 同一批字形背后是两个不同的语系 波斯语属于印欧语系，跟英语、德语、俄语是远亲。 阿拉伯语属于闪含语系，构词方式建立在三辅音词根上。 两者的亲缘距离，大约相当于英语和汉语之间的距离。 共用字母这件事，性质上跟越南语用拉丁字母写是一样的。 没有人会因为越南语用拉丁字母就拿英语词表去做越南语。 可换成阿拉伯字母，这个错误几乎每个团队都会犯一次。 犯错的根源在于视觉判断走在了语言判断前面。两段文字长得像，人的第一反应就是它们是一回事，而拉丁字母的世界里大家早就习惯了同一套字母写几十种语言，唯独换到这套字母就忘了。做阿拉伯语的选词与布局 (https://zhangwenbao.com/arabic-seo-rtl-layout-msa-dialect-keyword.html)攒下的经验，能带过来的只有书写方向那一部分。 有个反向的例子能帮着记住这件事：土耳其语在近百年前用的也是这套字母，改用拉丁字母之后没有人再把它和阿拉伯语混为一谈。可见让人产生错觉的从来是字形，不是语言本身。 ## 借来的是文字，不是词汇和语法 波斯语确实从阿拉伯语借了大量词汇，比例相当高。 但借词进来之后按波斯语的规则活着，不再遵守原来的构词法。 语法上更是两回事：波斯语的动词在句末，名词没有性。 阿拉伯语的动词变位、双数、破碎复数，波斯语一概没有。 所以哪怕两边写着同一个词，它在句子里的形态也可能完全不同。 关键词是短语不是单词，短语的形态由语法决定。 举个具体的：一个品类词加一个修饰词，在阿拉伯语里要处理定冠词与格的配合，在波斯语里只需要在两个词之间加一个连接音，而这个连接音在书面上根本不写出来。同一个概念，两种语言的词表条目长得完全不一样。 借词比例高这件事还有个反直觉的后果：它让机器翻译在这两门语言之间的表现看起来不错，因为大量实词能对上。可实词对上不等于短语对上，真正决定搜索能不能命中的恰恰是短语的组织方式。 ## 拿阿拉伯语词表当起点会错在哪几处 第一处是那四个多出来的字母，阿拉伯语词表里根本不会出现。 第二处是两个常用字母的码位不同，字符串比对直接失效。 第三处是数字形态，两边用的是不同的一组符号。 第四处是半连接符，波斯语大量使用，阿拉伯语基本不用。 第五处是借词的意思漂移，同形词未必同义。 五处叠加下来，能直接复用的条目通常不到两成。 更划算的做法是把阿拉伯语词表只当作品类结构的参考，也就是用它来确认要做哪些类目、类目之间是什么关系，具体的词一个都不抄。结构这一层跨语言是稳定的，词那一层跨语言几乎全要重来。 这五处里前三处是字符层的、后两处是语义层的，排查顺序必须是先字符后语义。字符层没理干净的时候去讨论词选得对不对，会被一堆看起来重复实际不同的条目干扰，判断全乱。这个顺序在早年编码遗留的排查 (https://zhangwenbao.com/cyrillic-encoding-legacy-windows1251-utf8-indexing-cost.html)里也是同一条。 ## 那四个多出来的字母会在哪些环节出事？ ## 四个字母各自对应什么音 波斯语里有四个音，阿拉伯语的音系中不存在。 它们分别是清双唇塞音、清塞擦音、浊擦音和浊软腭塞音。 用拉丁转写大致写作p、ch、zh、g这四组。 为了写出这四个音，波斯语在原有字母上加点造了四个新字母。 造字的方式很朴素：在最接近的那个字母下面或上面加三个点。 这四个字母在阿拉伯字母的码表 (https://www.unicode.org/charts/PDF/U0600.pdf)里有各自独立的码位。 加点造字这件事本身值得记一笔：它意味着这四个字母跟它们的原型字母在字形上极其接近，只差点的数量和位置。手写体、低分辨率屏幕和粗字重下，人眼分辨都有困难，机器如果做了过度宽松的模糊匹配，也会把它们混起来。 知道它们是加点造出来的还有个实用价值：做模糊搜索或者拼写纠错时，绝对不能把点的差异当成可忽略的噪声。有些通用的纠错库会做这种简化，用在波斯语上会把四对完全不同的词混成一对。 ## 品类词里带这四个字母的比例 这四个音在波斯语的常用词里出现频率很高。 随便挑一批日常品类词，带这四个字母的能占到三到四成。 自行车相关的词里尤其密集，因为不少是近代外来词。 外来词进入波斯语时，这四个音正好是最常需要的。 换句话说，越是现代品类，踩中这四个字母的概率越高。 做电商的类目词，基本躲不开。 这条可以直接拿来做一次快速自查：把现有的波斯语词表导出来，统计带这四个字母的条目占比。如果这个比例明显低于三成，那多半说明词表是从阿拉伯语那边翻过来的，或者是机器转换时把这四个字母替换成了原型字母。 顺带说一句，这四个字母在人名和地名里出现得更密集。如果站上有本地作者署名、门店地址或者配送区域列表，这些字段同样要纳入检查范围，它们常常是从别处导入的，最容易保留错误的替代写法。 ## 输入法与老系统里的替代写法 早期的编码方案和键盘布局不一定包含这四个字母。 那个年代的通行做法是用最接近的原型字母代替。 清双唇塞音写成浊双唇塞音，浊软腭塞音写成小舌音。 这些替代写法留在老内容、老数据库和老用户的习惯里。 今天仍然有一部分查询是用替代写法打出来的。 比例不高，但在长尾词上足以影响判断。 处理的原则跟处理任何一种历史写法一样：在匹配层做等价折叠，在展示层只用规范写法。千万不要为替代写法单独建页面，那等于把一个本来就小的量再切一刀，两边都做不起来。 要摸清替代写法在自己市场的实际占比，最可靠的来源仍是站内搜索日志。把规范写法和替代写法各数一遍，比例通常在几个百分点，看着不多，但换算成绝对量在大类目上并不小。 ## 排序与索引里这四个字母排在哪 按码位排序，这四个字母会落在字母表的末尾附近。 按波斯语的正字法排序，它们各自紧跟在原型字母后面。 两种排序给出的结果完全不同。 字母索引导航、按名称排序的商品列表，都会受影响。 解决办法是排序时用本地化的比较规则，不要用字节比较。 这跟任何一门有扩展字母的语言遇到的问题是同一类。 验证方法很直接：造一组只在这四个字母上有差别的词，按你的系统排一遍，看它们是紧挨着原型字母还是被甩到最后。这个测试三分钟能做完，却能拦住一整类用户找不到商品的投诉。 排序规则的差异还会影响分页。按名称排序的类目页如果排序规则前后不一致，同一件商品可能在两页里都出现或者两页里都不出现，这类问题在抓取时表现为页面内容不稳定，比排错顺序本身更麻烦。 ## 同一个词两套码位，怎么在索引里对齐？ ## 两个常用字母各有两个合法码位 波斯语里有两个字母，跟阿拉伯语的对应字母长得几乎一样。 但它们在编码里是两个不同的字符，各占各的码位。 一个是词尾形态有没有两个点的差别，一个是字母末端笔画的差别。 视觉上，在很多字体里这两对根本看不出区别。 编码上，它们是彻底不同的字符，比对时不相等。 这就是波斯语内容里最隐蔽也最普遍的一个坑。 为什么会有两套并存，原因在历史：早期的编码方案里波斯语被当作阿拉伯语的一个变体处理，直接沿用了阿拉伯语的码位；后来标准里补上了波斯语专用的码位，可老内容和老输入法并没有跟着改，两套就这样一直共存到现在。 这个坑之所以特别难缠，是因为它同时满足三个条件：视觉上不可分辨、编码上完全不等、出现频率极高。三个条件里去掉任何一个，问题都会容易得多，而波斯语这两对字母恰好三个都占齐了。 ## 用户实际打出来的是哪一套 取决于他用的键盘布局，而键盘布局的分布相当分散。 系统自带的波斯语键盘通常输出波斯语码位。 某些第三方输入法和老设备输出的是阿拉伯语码位。 从网页上复制粘贴过来的文字，带的是原页面用的那一套。 所以同一个用户在不同场景下打出来的可能不是同一个字符串。 这件事他自己完全无法察觉，因为看起来一模一样。 拿自行车这个词做例子：它的常见写法里正好含有其中一个有争议的字母，于是站内搜索日志里会出现两条看着完全相同的记录，各自带着一部分搜索量。把它们分开统计，任何一条都显得没什么需求。 后台编辑同样是污染源。运营从供应商文件里粘贴商品标题，粘进来的是文件里那一套码位；自己手打的又是键盘那一套，同一个类目下的商品标题因此可能带着两种字节形态，页面上看起来完全一致。 有个办法能量出污染的程度：把商品标题字段整体导出，按两套码位分别统计出现次数。两边都有相当数量，就说明数据已经混了，此时先做一次全量清洗再上线映射层，比只做映射层干净得多。 ## 归一化要放在哪一层 标准里的归一化处理不解决这个问题，因为这两对不是等价字符。 标准归一化管的是同一个字符的不同表示方式，比如组合与预组合。 波斯语这两对属于不同的字符，归一化的适用范围 (https://www.unicode.org/faq/normalization.html)覆盖不到。 所以必须自己写一层映射，把阿拉伯语码位映射到波斯语码位。 这一层要放在最靠近入口的位置，请求进来立刻处理。 入库、检索、比对全都用映射之后的形式。 顺便把常见的兼容字符一起处理掉：某些老内容里会出现呈现形式区的字符，也就是把字母的连写形态当成独立字符存起来的那种写法，这类字符看起来正常但完全无法匹配，映射表里加两行就能一并解决。 映射的方向要定下来并写进文档：统一往波斯语码位映射，而不是反过来。方向不一致会造成两个模块各映射各的，最后又对不上。选波斯语码位作为规范形态的理由是它才是这门语言的正式编码。 ## 地址、文件名与数据库的连带影响 如果地址里用了本地字符，两套码位会生成两个不同的地址。 两个地址内容相同，等于自己给自己造了重复。 文件名同理，图片路径里带波斯语字母时容易出这个问题。 数据库的排序规则如果不区分，查询结果又会不一致。 最稳妥的做法是地址与文件名一律用转写，不用本地字符。 本地字符只出现在页面内容和标题里，那里的归一化由应用层负责。 已经上线的老地址不要为这个理由去改，收益远小于风险。正确做法是把新增的路径规则改掉，老地址维持原样并确保两套码位的版本之间做了明确的指向，让系统知道哪一个是主版本，这比批量改地址安全得多。 数据库这一侧还要确认排序规则的设置。有些默认的排序规则会把这两对字母视为等价，这在检索时是好事，但会掩盖数据里的不一致，等到换了一套规则或者迁移到别的存储时，隐藏的问题会一次性爆出来。 ## 波斯语的数字为什么跟阿拉伯语长得不一样？ ## 三套数字形态与它们的码位区间 第一套是通行世界的那组符号，用在拉丁文字里。 第二套是阿拉伯语区常用的那组，有自己的码位区间。 第三套是波斯语用的，又是另一个码位区间。 第二套和第三套里，有几个数字的字形明显不同。 四、五、六这三个数字，两套写法差别最大。 其余几个字形相同，但码位仍然不同。 字形相同码位不同这一点特别坑：肉眼校对完全发现不了问题，只有把字符串按码位打印出来才能看见。所以数字相关的排查必须用工具做，靠人眼看两遍不解决任何问题。 另一个容易忽略的细节是这两套数字的排列方向。数字本身在双向文本里属于弱方向字符，一串数字在从右往左的段落里仍然按从左往右读，但它跟相邻符号的相对位置会变，价格加货币符号的组合最容易在这里出问题。 ## 价格、尺码与年份三类字段的分布 价格通常用波斯语数字展示，因为它出现在正文语境里。 技术规格里的尺码往往用通行数字，因为规格表是从供应商那里来的。 年份最乱，两套都有，还要叠加历法的差别。 伊朗使用的历法跟公历不是同一套，年份数值差了六百多。 用户搜某一年的车型时，心里想的可能是本地历法的年份。 这一条在选词时经常被整个忽略掉。 处理办法是在页面上把两种历法的年份都写出来，正文里用本地历法、规格表里注明公历对应，两边都能被搜到。这个做法的额外好处是它顺手解决了促销排期的沟通问题，因为本地团队和总部说的年份根本不是同一个数。 促销活动的时间表是第四类容易出事的字段。本地的节庆按本地历法走，日期每年在公历上的位置都不一样，拿去年的公历日期推算今年的活动周期一定会错开，这个错误在跨时区协作的团队里几乎每年都会犯一次。 ## 展示与查询要分开定规则 展示端按本地习惯，正文和价格用波斯语数字。 查询端全部归一到通行数字再做比对。 筛选器的数值输入两套都要接受。 排序一律按数值排，不要按字符排。 结构化数据里的数值用通行数字，那是机器读的。 两条规则分开定，一条服务人一条服务机器。 还有一处容易漏：小数点和千分位。波斯语区常用的小数分隔符跟通行写法不是同一个字符，用户从别处粘贴过来的价格带着这个符号，直接送进数值解析会静默失败，表现为搜索无结果而不是报错，日志里很难定位。 把这条原则写进模板层最省事：输出数值时统一走一个格式化函数，接收数值时统一走一个解析函数，两个函数各自处理本地化与归一。散在各处手写的话，总会有某个新页面的开发者忘掉其中一半。 ## 半连接符到底是不是空格？ ## 它做什么用、写在哪些位置 波斯语的字母在词内是连写的，前后字母会连成一体。 有些情况下，两部分在语法上是一个词，书写上却不该连起来。 这时就要插入一个零宽度的符号，让连写在这里断开。 它不占宽度，不是空格，但会阻断字母的连笔。 最常见的用法是复数后缀，以及某些动词的前缀。 一个词里出现一到两次是很正常的。 这个字符位于通用标点区，跟其他几个零宽度控制字符放在一起，通用标点的码表 (https://www.unicode.org/charts/PDF/U2000.pdf)里能查到它的确切位置和用途说明。它的存在感为零，删掉之后页面看起来只是字母连到了一起。 需要它的位置是有限且可以穷举的：几个常用的复数后缀、几个动词前缀、少数几类固定构词。把这份清单整理出来大约几十条，是后面所有自动化检查的基础，值得花半天时间做扎实。 ## 三种输入情形的比例 第一种是打对了，插入了这个符号。 第二种是打成了普通空格，视觉上很接近。 第三种是干脆不打，两部分连成一个词。 手机键盘上这个符号通常要长按或者切层才能打出来。 所以移动端第二种和第三种的比例明显更高。 三种写法在搜索日志里是三条不同的记录。 把三种写法的量加起来才是真实需求，这跟移动端输入成本抬高省略率 (https://zhangwenbao.com/arabic-rtl-mobile-first-narrow-screen-pitfalls.html)是同一个机制在起作用：只要打出规范形态需要多按一次键，相当比例的用户就会选择不打。 桌面端的比例分布也不是打对占绝对多数。相当一部分用户从来没意识到有这个符号存在，他们的习惯是打空格，因为视觉效果最接近正确形态。所以这不是移动端独有的问题，只是移动端更严重。 ## 分词与匹配层怎么处理这三种 匹配层要把三种写法折叠成同一个键。 折叠的方式是把这个符号和它位置上的空格都去掉。 去掉之后三种输入得到同一个字符串。 但正文和标题里必须用规范写法，不能因为好匹配就不写。 因为不写会影响可读性，也会影响本地用户对页面质量的判断。 匹配宽松、输出规范，这条原则在很多语言里都适用。 要注意折叠不能一刀切：有些位置上的空格是真正的词间空格，去掉会把两个词粘成一个。安全的做法是只对已知会带这个符号的后缀和前缀做定向折叠，维护一份几十条的规则表，比写一条通用规则可靠得多。 规则表的维护有个省事的做法：按后缀而不是按词来写规则，几十条后缀能覆盖成千上万个词。按词写规则的方案看起来更精确，但维护量会随品类扩张线性增长，几个月后就没人愿意更新了。 ## 复制粘贴与后台编辑里的丢失 这个符号在复制粘贴时经常丢失。 某些编辑器会把它当成不可见字符清理掉。 某些表单会在提交时把它过滤成空。 数据库如果按字节截断，也可能把它切掉一半。 丢失之后页面看起来只是连笔多了一点，很难被发现。 写一个检查脚本定期扫一遍，成本很低。 扫描规则也简单：把已知需要这个符号的后缀列成清单，检查这些后缀前面有没有它。发现缺失就报出来人工确认。这类脚本一次写好可以用很多年，比指望编辑手动核对靠谱得多。 富文本编辑器是重灾区，很多编辑器会在保存时做一次内容清洗，把不可见字符当成垃圾清掉。选型时把这一条列进测试用例，粘一段带这个符号的文字保存再读出来，看它还在不在，两分钟能测完。 ## 伊朗用户实际怎么打字、怎么搜？ ## 键盘布局的分裂带来的输入差异 这个市场的键盘布局不止一种，且没有绝对主流。 不同布局对那两个有争议字母的输出不一样。 对那四个专有字母的按键位置也不一样。 对数字形态的默认输出更是各有各的做法。 这三个变量组合起来，同一个词有好几种字节形态。 这是波斯语市场比大多数语言更麻烦的地方。 面对这种分裂，唯一稳妥的策略是把宽容度做在匹配层而不是做在词表上。词表只收规范写法保持干净，匹配层负责把各种变体折叠过来。反过来做的话，词表会膨胀成几倍大且永远维护不完。 这种分裂也解释了为什么这个市场的关键词工具数据格外不可信：工具通常只按一种形态查询，返回的量只是真实需求的一部分。判断需求大小时应该把各种变体的量加起来看，而不是直接采信工具给的单一数字。 ## 拉丁转写在什么场合还会出现 本地用户之间的日常交流里，转写用得不多。 但在品牌名、型号和技术术语上，拉丁写法很常见。 自行车的变速套件型号，几乎没人会去转写成本地文字。 所以商品标题里本地文字和拉丁字母混排是常态。 混排就要处理方向问题，这跟阿拉伯语那边是同一套机制。 混排的坑在窄屏上尤其明显。 这一点跟另一门文字并存拉丁转写的语言 (https://zhangwenbao.com/greek-seo-greeklish-latin-transliteration-coverage.html)不一样：那边是整句都可能被转写，用户会用拉丁字母打整个查询；波斯语这边只有专名和型号用拉丁字母，正文查询仍然是本地文字。覆盖策略因此完全不同。 型号这类拉丁字符串还带来一个连带问题：它们在从右往左的段落里属于强方向字符，会形成一个方向岛，前后的标点跟着走位。商品标题里如果型号后面紧跟着一个句号或者括号，位置很可能跑到你不期望的一端。 ## 移动端的输入成本与查询长度 这门语言在手机上打字，成本比拉丁字母高。 字母形态随位置变化，输入法的候选逻辑更复杂。 加上那个半连接符要额外操作，成本又高一截。 结果是移动端查询更短、更依赖建议列表。 短查询意味着更少的修饰词、更多的品类词直接搜索。 词表要相应地把短词的权重提上来。 可以拿站内搜索日志按设备切开量一次：比较两端查询的平均词数。如果移动端明显更少，说明这个偏移在你的市场成立，值得给高频短词单独准备落地页而不是只做长尾。 建议列表的质量因此格外重要。用户既然更倾向于选而不是打，那么列表里出现什么词就直接决定了最终的查询分布，站内搜索的建议逻辑如果只按历史热度排，会形成一个自我强化的循环，把长尾彻底压住。 ## 从阿拉伯语借来的词，意思真的一样吗？ ## 同形不同义的几类典型 第一类是意思缩小：借来之后只保留了原义中的一个分支。 第二类是意思转移：借来之后用在完全不同的领域。 第三类是语体升降：在一边是日常词，在另一边是书面词。 第三类最难发现，因为词典上两边的释义看起来是一样的。 而语体决定了它会不会出现在搜索框里。 书面词写进标题，搜索量就会低得莫名其妙。 判断语体有个不需要语言能力的办法：把候选词搜一遍，看返回结果里本地零售站和论坛占多少、词典与新闻占多少。后者占多数的基本是书面词，可以放进正文但不该拿去写标题。波斯语词典的词条页 (https://www.vajehyab.com/dehkhoda/%D9%82%DB%8C%D9%85%D8%AA)能确认释义，但确认不了今天的使用频率。 还有一类更隐蔽的是搭配差异：词本身两边同义，但能跟它组合的词不一样。直译过来的短语单看每个词都对，合在一起本地人不这么说，这类问题词典完全查不出来，只能靠抓真实语料里的相邻组合来发现。 ## 复数形式借来之后被当成单数 阿拉伯语的复数形式在波斯语里经常被整体借用。 借过来之后，说话人未必知道它原本是复数。 于是它被当成单数用，再加上波斯语的复数后缀。 结果是一个词身上带了两层复数标记。 这种写法在正式文体里被认为不规范，在口语里非常普遍。 而搜索框里出现的通常是口语那一种。 这就构成一个典型的取舍：写规范形态显得专业但接不住搜索，写口语形态能接住搜索但可能被本地用户认为不够正式。折中做法是标题用规范形态、正文里自然带出口语形态，两边都覆盖到。 这个现象在其他借用了外来复数的语言里也有，处理思路可以互相借鉴：判断标准不是语法正确与否，而是这个形态在搜索框里出现的频率。语法洁癖在选词这件事上通常会付出流量代价。 ## 品类词里最容易踩的那几个 凡是涉及价格、质量、保证这类抽象概念的词，都要单独验。 这几类词借用比例最高，语体差异也最大。 具体的实物名词反而安全，因为多半是本土词或者近代外来词。 动作类词要小心，购买、配送、退换的常用说法两边不同。 形容词最不稳定，同一个词在两边的褒贬色彩可能不一样。 验的成本不高，一个母语用户两小时能过完一份词表。 验完记得把结论写进一份表里长期保存，标明每个词的语体、频率和适用位置。下一次新增品类时这份表就是起点，不必从头再验一遍，几轮之后它会变成团队最有价值的本地化资产。 还有一类要单独拎出来的是尺寸与规格的单位词。这类词在两门语言里常常写法相同但习惯用法不同，比如用不用缩写、缩写后加不加点，写法差一点就匹配不上，而它们在筛选器里出现的频率非常高。 ## 波斯语的构词与复数怎么影响关键词覆盖？ ## 两套复数后缀，哪一套进词表 波斯语有两个常用的复数后缀，用法有分工。 一个用于有生命的名词，一个通用性更强。 通用的那个用在商品名上更自然。 但两个后缀在实际使用中有交叉，不是严格互斥。 词表里应该以单数为主条目，复数作为变体收录。 因为搜索时用单数还是复数，取决于查询意图而不是语法。 值得单独说的是通用复数后缀要用半连接符跟词干分开写，这就把前面那个坑又叠了一层：一个复数形式可能有打对、打成空格、不打三种写法，再乘上码位的两套，一个词能裂出六种字节形态。这也是为什么匹配层的折叠必须做扎实。 六种字节形态听起来吓人，实际处理起来并不复杂，因为它们经过折叠之后都会收敛到同一个键。真正麻烦的是统计口径：如果报表按原始字符串聚合，一个词的量会被拆成六份，每一份都小到看不出价值。 ## 复合词与连接结构 波斯语用一个连接音把两个名词串起来表示所属或修饰。 这个连接音在标准书写里通常不写出来。 不写出来意味着两个词之间只有一个空格。 所以从字面上看不出来这是一个短语还是两个独立的词。 分词器只能靠词典和统计来判断边界。 这跟复合词粘成一个长词的语言正好相反。 对做词表的人来说，这意味着不能靠形态来判断哪些是固定搭配。只能反过来做：从真实的查询日志和本地站的标题里抓高频的相邻组合，把它们当成固定短语收进词表，这是唯一可靠的来源。 这个特点还影响标题的长度控制。因为短语之间只有空格没有形态标记，标题在视觉上很容易显得松散冗长，本地站的常见做法是把最核心的两三个词放在最前面，后面的修饰成分能省则省。 ## 形容词与名词的顺序 波斯语的形容词放在名词后面，跟英语相反。 山地自行车这个概念，词序是自行车在前山地在后。 直接按英语词序翻译，得到的短语本地人不会那么搜。 这个错误在机器翻译产出的词表里非常常见。 检查办法是看主品类词在短语里的位置。 主品类词应该在前面，修饰词跟在后面。 这条规则还能顺手用来做批量筛查：把词表里所有短语按主品类词的位置分两堆，主品类词在后的那一堆几乎全是有问题的条目，一次能挑出大部分翻译痕迹，比逐条人工看快得多。 词序这件事还会影响标题被截断时的信息保留。主品类词在前意味着窄屏截断时最重要的词能留下来，如果按英语词序写，截断之后留在屏幕上的可能只剩修饰词，用户完全看不出这是什么商品。 ## 本地字符域名与转写并存，地址栏里写哪一套 ## 本地字符域名的实际使用情况 伊朗有自己的本地字符顶级域，早已完成委派。 但它的实际使用率并不高，多数商业站仍用拉丁后缀。 本地字符域名在输入时要切换键盘，成本不低。 用户更多是通过搜索和链接进入，很少手打域名。 所以本地字符域名的价值主要在品牌展示而不是流量。 做不做取决于品牌策略，不影响自然搜索表现。 本地字符域名在技术上是用编码转换成拉丁字符再解析的，这套编码方案的规范 (https://www.rfc-editor.org/rfc/rfc3492)规定了转换规则；实际影响是链接被分享出去时可能显示成一串看不懂的字符，社交场景里观感不好。 还有一个现实考量是外部工具的兼容性。不少分析工具、广告平台和第三方服务对本地字符域名的支持并不完整，会把它显示成编码后的形态甚至直接报错，这些摩擦成本累加起来往往超过品牌展示带来的收益。 ## 地址里的路径段怎么写 路径段用转写，理由前面说过：避开两套码位的分裂。 转写方案要在全站统一，写成一份规则文档。 规则要覆盖那四个专有字母怎么转、长短元音怎么处理。 不统一的后果是同一个词在不同页面转写成不同的路径。 路径不一致会让站内结构显得混乱，也不利于人读。 这属于架构层的决策，多语言站的地址结构与语言地区标注 (https://zhangwenbao.com/international-seo-hreflang-complete-guide.html)那套照做就行。 转写规则里最容易吵起来的是元音。波斯语的短元音在书写里通常不标出来，转写时到底补不补、补哪一个，没有唯一答案。实用的处理是选一套公开的转写方案照抄，别自己发明，这样至少保证一致且可解释。 路径里还要处理那个阻断连写的符号。它是零宽度的，转写时应该当成词的分界处理成连字符，而不是直接删掉。删掉会把两部分粘成一个看不懂的长串，处理成连字符则既可读又跟本地写法对得上。 ## 转写不统一带来的分裂 品牌名的转写不统一，会让外部引用分散到几个写法上。 用户搜品牌名时打的是哪一种，取决于他在哪里见过。 所以要选定一种官方写法并在所有对外场合坚持使用。 其余写法在页面里提一次，让系统知道它们指同一个东西。 这跟任何一门非拉丁文字语言的品牌名处理是同一个问题。 早定早省事，改起来的成本随时间线性增长。 选写法时有一条经验：优先选本地用户自己已经在用的那一种，而不是语言学上最准确的那一种。准确的转写如果没人用，坚持它等于自己给自己制造一个没人搜的词。 选定之后要把这个写法固化到几个地方：站内的品牌名字段、对外的社交账号名、给媒体的资料包、以及商品标题模板。这四处覆盖了外部引用的绝大部分来源，锁住它们基本就锁住了转写的一致性。 ## 一套波斯语词表怎么建、怎么验收？ ## 起点不是翻译，是抓本地站的真实用词 第一步是找出这个市场里排在前面的几个本地零售站。 把它们的类目名称、商品标题、筛选项全部抓下来。 统计高频词和高频组合，这就是词表的原始素材。 这一步完全不需要懂这门语言。 抓下来的词是本地人真实在用的，比任何翻译都可靠。 翻译只在最后一步用来确认这个词是什么意思。 抓的时候顺手记下每个词出现在什么位置：类目名里的偏正式，筛选项里的偏简短，商品标题里的最接近用户说法。三个位置的词性质不同，后面分配用途时直接按这个分类走，省掉再判断一遍。 抓取的对象里别漏掉本地的分类信息站和论坛交易板块。这两类站点的用词比正式零售站更口语化，正好补上零售站偏正式的那一半，两边的词合起来才能覆盖用户的实际说法。这跟另一门书写系统里靠语料反推词形 (https://zhangwenbao.com/hebrew-seo-unvocalized-script-root-letters-keyword.html)的做法是同一个路子。 ## 六个必查项 第一查那四个专有字母有没有被替换成原型字母。 第二查两个争议字母用的是哪一套码位。 第三查数字形态是否统一。 第四查半连接符该有的地方有没有。 第五查借词的语体是否适合放在标题里。 第六查短语的词序是不是主品类词在前。 六项里前四项可以完全用脚本自动查，写一次能反复用；后两项需要人判断，但有了前四项的自动过滤，人要看的条目会少很多。把这六项做成词表交付前的固定关卡，新语言上线时这类问题基本可以清零。 六项之外还可以加一条软性检查：把词表里每个词丢进搜索引擎看返回结果的类型。返回的多是本地零售站说明这个词在商业场景里活跃，多是词典百科说明它偏书面，这一条不需要语言能力，五分钟能验十个词。 六项检查最好做成提交前自动运行的形式，而不是靠人记得去跑。词表这类资产的特点是改动频繁且改动的人不固定，任何依赖自觉的流程半年内一定会失效，只有卡在流程里的检查能长期生效。 ## 交给谁验、验什么 脚本验编码层，母语用户验语言层，两边分工不重叠。 母语用户要验的只有三件事：这个词本地人说不说、语体对不对、词序自然不自然。 不要让母语用户去查编码问题，他看不出来也不该看。 也不要让脚本去判断语体，它做不到。 两轮验收加起来，一份三百条的词表大约需要半天。 验完的词表要标注验收日期，半年后复验一次。 复验的重点是新增品类和外来词。这两类的说法变化最快，尤其是新进入市场的品类，用户的叫法可能在一年内换一次。老品类的词非常稳定，复验时抽查即可，不必全量重来。 找母语用户时优先找在这个行业里工作过的人，而不是单纯的语言人才。品类词的判断需要行业语感，一个不熟悉自行车的母语者对变速套件的叫法未必比抓来的语料更可靠，这一点在专业品类上尤其明显。 ## 常见问题解答 ## 已经做了阿拉伯语市场，波斯语能不能直接复用词表？ 不能，能直接复用的条目通常不到两成。波斯语属于印欧语系，阿拉伯语属于闪含语系，两者共用字母的关系类似于越南语和英语共用拉丁字母，亲缘距离非常远。具体的阻碍有五处：波斯语多出四个阿拉伯语没有的字母，两个常用字母各有两套不同的码位，数字用的是另一组符号，词内大量使用一个阻断连写的零宽度符号，以及借词的意思和语体在两边发生了漂移。这五处叠加下来，字符串层面就已经对不上了，更别说语法和词序的差别。正确的复用方式是把阿拉伯语词表当作品类结构的参考，用它来确认要做哪些类目、类目之间是什么关系，具体的词一个都不抄。结构这一层跨语言是稳定的，词那一层几乎全要重来。判断复用价值时可以先做个小测试：随机挑二十个阿拉伯语词表里的条目丢进波斯语的搜索里，看有多少条能返回本地零售站的结果，命中率通常低得让人意外。 ## 两套码位的问题该怎么彻底解决？ 写一层字符映射，把阿拉伯语码位映射到波斯语码位，放在请求进来后的第一时间处理，入库、检索、比对全部用映射之后的形式。注意标准的归一化处理解决不了这个问题，因为这两对字母是不同的字符而不是同一个字符的不同表示，归一化的适用范围覆盖不到。映射表里顺便把呈现形式区的兼容字符也一起处理掉，那类字符看起来正常但完全无法匹配，加两行规则就能解决。放置的位置很关键，越靠后每个经过的模块都要各自处理一遍，漏掉任何一个整条链路就前功尽弃。已经上线的老地址不要为这个理由批量改写，把新增路径的规则改掉、并让系统知道两个版本里哪个是主版本，比大规模改地址安全得多。映射的方向要在文档里写死，统一往波斯语码位靠，否则不同模块各映射各的，绕一圈之后又对不上了。 ## 那个阻断连写的符号，用户不打怎么办？ 在匹配层做折叠，同时在页面输出上坚持规范写法。用户的输入有三种情形：打对了、打成普通空格、干脆不打，移动端后两种的比例明显更高，因为这个符号通常要长按或者切换键盘层级才能输入。折叠的做法是把这个符号和相应位置的空格都去掉，三种输入就得到同一个键。但折叠不能一刀切，有些位置的空格是真正的词间空格，去掉会把两个词粘成一个，安全做法是维护一份几十条的规则表只对已知会带这个符号的前后缀做定向折叠。页面上必须用规范写法，因为不写会影响可读性和本地用户对页面质量的判断，匹配宽松、输出规范这条原则在很多语言里都适用。需要这个符号的位置是可以穷举的，整理出来大约几十条后缀和前缀，这份清单是所有自动化检查的基础，值得一次做扎实。 ## 价格和年份该用哪一套数字？ 展示端按本地习惯用波斯语数字，查询端全部归一到通行数字再比对，两条规则分开定，一条服务人一条服务机器。筛选器的数值输入要两套都接受，排序一律按数值排不要按字符排，结构化数据里的数值用通行数字因为那是给机器读的。年份要额外注意历法问题：伊朗使用的历法跟公历不是同一套，年份数值差了六百多，用户搜某一年的车型时心里想的可能是本地历法的年份。处理办法是页面上把两种历法都写出来，正文里用本地历法、规格表里注明公历对应。还有一处容易漏的是小数分隔符和千分位，本地常用的符号跟通行写法不是同一个字符，粘贴过来的数字直接送进解析会静默失败，表现为搜索无结果而不是报错。促销活动的时间表也要按本地历法排，拿去年的公历日期推算今年的活动周期一定会错开，跨时区协作的团队几乎每年都会在这里栽一次。 ## 怎么判断现有词表是不是从阿拉伯语翻过来的？ 做两个统计就能看出来。第一个是统计带那四个波斯语专有字母的条目占比，正常情况下日常品类词里这个比例能到三到四成，尤其是近代外来词密集的品类更高，如果明显低于三成，多半说明词表来自阿拉伯语那边或者机器转换时把这四个字母替换成了原型字母。第二个是看短语里主品类词的位置，波斯语的形容词放在名词后面，主品类词应该在前修饰词跟在后，如果词表里有一大堆修饰词在前的短语，那基本就是按英语或者阿拉伯语词序直译的。这两个统计都能用脚本做，几分钟出结果，比逐条人工审阅快得多，而且结论很硬，不会有争议。第三个可选的信号是看词表里有没有出现阿拉伯语特有的定冠词前缀，波斯语不用这个前缀，出现了基本就能确认来源。 ## 没有母语同事，词表能不能自己先做出来？ 能做出很像样的初稿，最后一步仍然需要人。做法是先找出这个市场排在前面的几个本地零售站，把它们的类目名称、商品标题和筛选项全部抓下来，统计高频词和高频组合，这就是词表的原始素材，整个过程不需要懂这门语言。抓的时候记下每个词出现的位置，类目名里的偏正式、筛选项里的偏简短、商品标题里的最接近用户说法，后面分配用途时直接按这个分类走。编码层的六项检查里前四项完全可以脚本自动完成。真正需要母语能力的只有三件事：这个词本地人说不说、语体对不对、词序自然不自然，一份三百条的词表大约需要母语用户半天时间。初稿做完先跑一遍前四项自动检查再交给母语用户，这样他看到的条目已经在编码层是干净的，注意力能全放在语言判断上，效率明显更高。 ## 波斯语市场的搜索入口跟别的市场一样吗？ 入口的分布确实有自己的特点，但那属于引擎层而不是语言层，这一篇讲的是语言本身带来的功课。需要判断在这个市场投哪个入口、各入口的排序规则有什么差别时，那是另一类专门的讨论。放在这里只强调一件事：无论从哪个入口进来，前面讲的字母、码位、数字、半连接符四类问题都同样成立，因为它们是文字系统本身的属性，跟谁来抓取无关。所以正确的顺序是先把语言层的地基打好，再去讨论入口分配。反过来做的话，入口选对了页面却因为字符串对不上而接不住搜索，投入会被浪费掉，而且这类损失在报表里看起来像是入口选错了，很容易得出错误结论。换个角度说，语言层的功课做扎实之后，换任何一个入口这批工作都不用重做，这是它优先级更高的根本原因。 ## 权威参考资料 ## 阿拉伯语网站搬进手机之后，桌面时代验过的那份RTL清单有一半不作数 - URL：https://zhangwenbao.com/arabic-rtl-mobile-first-narrow-screen-pitfalls.html - 分类：小语种SEO - 发布：2015-08-04 | 更新：2026-07-26 - 摘要：阿拉伯语页面到了移动端会出哪些新问题？讲清窄屏折行拆断价格串、标题截断落在左端、手势方向该不该翻、两套数字形态的查询分叉与可用性判定的系统性踩中项。 - 关键词：移动端SEO,多语言SEO,小语种SEO > **TLDR**：摘要：从右往左这件事在宽屏上基本被解决过一轮，换到窄屏之后又冒出一批新的。区别在于坏掉的东西变了：桌面时代出问题的是版面与模板，窄屏上出问题的是折行、截断、手势与键盘。价格串会在折行时被拆成两截，标题的省略号落在左端，手机键盘决定用户打的是哪一套数字。这篇把这批只在窄屏上成立的坑逐条拆开。 > 摘要：从右往左这件事在宽屏上基本被解决过一轮，换到窄屏之后又冒出一批新的。区别在于坏掉的东西变了：桌面时代出问题的是版面与模板，窄屏上出问题的是折行、截断、手势与键盘。价格串会在折行时被拆成两截，标题的省略号落在左端，手机键盘决定用户打的是哪一套数字。这篇把这批只在窄屏上成立的坑逐条拆开。 ## 移动优先之后重新出问题的不是版面，是交互 ## 桌面时代那份清单为什么不能直接搬过来 大部分团队手上都有一份从右往左的检查清单，是做桌面站时攒下来的。 那份清单的核心是模板层：方向属性有没有写对，栅格有没有镜像，表格列序对不对。 这些条目今天依然有效，但它们只覆盖了窄屏问题里的一小半。 原因很直接：桌面上有足够的宽度，很多冲突被空间吃掉了，根本没机会显形。 屏幕一窄，被空间掩盖的那些冲突就一次性全都跑出来了。 所以这不是原来的结论错了，是原来的测试条件太宽松。 更麻烦的是这批新问题很难在评审里被发现。模板层的错误看一眼截图就知道，而折行、截断、手势这三类只有在真机上用真实内容滑一遍才会暴露，评审用的示意图往往用的是英文假数据，方向一翻转就把问题藏住了。做桌面时代那套阿拉伯语布局检查 (https://zhangwenbao.com/arabic-seo-rtl-layout-msa-dialect-keyword.html)时积累的经验在这里只能当起点。 有个判断哪些条目要重验的土办法：把清单里每一条问一句它在多宽的屏幕上会失效，答案是任何宽度的留着，答案是屏幕窄到某个值以下的挑出来单独放一组，这一组就是这轮要重做的全部。 ## 出问题的位置从版面移到了交互 窄屏上用户的动作变多了：滑、拖、展开、收起、切换键盘。 每一个动作都隐含一个方向假设，而这些假设写代码的人通常没意识到自己做过。 轮播往左滑是下一张还是上一张，抽屉从哪一侧推出来，返回手势从哪条边起。 这些在从左往右的世界里是默认值，没人会写进需求文档。 换到从右往左之后，默认值有的该翻转、有的绝对不能翻转。 判断哪个该翻哪个不该翻，恰恰是这门语言带来的额外功课。 还有一层更隐蔽：交互的方向错了不会报错，也不会让页面看起来坏掉，它只是让用户多花两三秒才明白该往哪边划。这种损耗在数据里表现为跳出率略高、页面停留略短，很难被归因到方向上，团队通常会先去怀疑文案和图片。 把交互层的方向假设显式写进需求文档，是唯一能长期生效的办法。文档里给每个可滑动可展开的元素标一个方向属性，值只有三种：跟随文字、跟随设备、不适用。三种一标完，实现和验收都有了依据。 ## 把两个年代的坑摆在一张表里 下面这张表把桌面时代和窄屏时代的问题分开，避免混着查。 左列是宽屏就能发现的，右列是只有窄屏才会显形的。 维度 | 宽屏时代的表现 | 窄屏时代的表现 | 出问题的层 | 模板与栅格：方向属性、列序、浮动 | 交互与折行：手势、截断、键盘 | 双向混排 | 长句里的西文片段断在错的位置 | 折行把价格与型号拆成上下两截 | 标题截断 | 宽度充裕，很少截断 | 省略号落在左端，砍掉的是句尾 | 数字输入 | 桌面键盘布局相对固定 | 移动键盘决定用户打哪一套数字 | 检测方式 | 浏览器里目检截图 | 真机滑动加可用性判定项 | 字号行高 | 默认值基本够用 | 字形的上下延伸让同样字号显得更挤 | 这张表最实用的地方是它能省掉重复劳动。 左列那些如果当年验过并且模板没大改，这一轮可以直接跳过。 右列这些则一条都不能跳，因为它们在桌面测试里根本没有对应的动作。 用这张表还能顺手解决排期争议。右列六条里有四条属于前端改动、两条属于内容与词表改动，责任方不同，可以并行开工；如果不做这个拆分，整件事很容易被打包成一个模糊的适配任务扔给前端，而词表那半边永远排不上。 ## 窄屏折行为什么会把价格拆成两截？ ## 断点落在数字与符号之间 阿拉伯语正文里嵌一段西文数字，是电商页面的常态。 价格、型号、容量、滤芯规格，这些几乎全是西文数字或者字母数字混排。 混排段落的显示顺序由双向算法决定，它按逻辑顺序存储、按视觉顺序呈现。 宽屏上一行放得下，看不出问题。 窄屏上这一段要折行，折行点是按可用宽度算的，跟逻辑顺序没有关系。 结果就是一个完整的数值被切在两行里，上一行的末尾和下一行的开头各留一半。 这类错误的典型形态是这样的：一台净水器的型号写成八位字母数字，折行之后前四位留在上一行的左端、后四位跑到下一行的右端，两截之间隔着整整一行的空白，用户根本拼不回来。双向算法把重排规则写得很清楚 (https://www.unicode.org/reports/tr9/)，但它管的是顺序，不管折行。 这里还藏着一个反直觉的点：折行位置由换行算法按字符类别 (https://www.unicode.org/reports/tr14/)决定，而顺序由双向算法决定，两套规则各管各的、互不通气，所以顺序正确的字符串照样会被折在最不该折的地方。 ## 三类混排串的实际表现不一样 价格串通常带货币符号，符号在哪一端由本地习惯决定。 型号串是纯粹的字母数字，方向上完全中性，最容易被算法归到相邻文字的方向里。 尺码与规格串常带斜杠和乘号，这些符号本身也是中性字符。 中性字符的方向取决于两边邻居，两边方向不同时按段落方向兜底。 所以同一串数字放在不同上下文里，呈现出来的顺序可能不一样。 测试时如果只造一条数据，很可能刚好躲开出问题的那种组合。 造测试数据有个偷懒办法：把型号写成一半数字一半字母、价格写成带小数点和货币符号、规格写成带斜杠的三段式，这三条覆盖了中性字符的大部分情形，比造二十条随机数据管用。滤芯规格这类字段最容易出事，因为它同时带数字、字母、斜杠和汉字以外的单位缩写。 顺带记一条经验值：如果一个字段的内容里同时出现方向强字符、方向弱字符和中性字符三类，它出问题的概率接近百分之百，商品标题和规格描述通常都属于这一类，可以直接列入必查名单不用再逐个判断。 ## 把混排段钉住的两个办法 第一个办法是不让它折：给整串加上不折行的包裹。 代价是宽度不够时会撑破容器，需要配合缩小或者换行策略。 第二个办法是给这段加方向隔离，明确告诉渲染引擎它是一个独立的方向单元。 隔离之后这一段不再受邻居影响，顺序稳定，折行也只在它自己内部发生。 两个办法可以叠加，先隔离再禁止折行，稳定性最好。 模板层面把这两条固化到价格与型号的输出函数里，比逐个页面改省事得多。 还有一个常被忽略的位置是结构化数据与元描述。这两处的字符串不参与页面渲染，团队默认它们没有方向问题，可实际上搜索结果里的摘要一样会折行、一样会重排，价格在摘要里被拆开的观感比页面里更糟，因为用户还没进站就先看到一串对不上的数字。 处理时要区分方向隔离和方向覆盖两件事，行内双向标记的规范说明 (https://www.w3.org/International/articles/inline-bidi-markup/)里讲得很细：隔离是让这一段自成一体不影响邻居，覆盖是强行指定顺序，后者用错会把本来正确的显示改坏。 ## 同一段文字在三个位置会有三种折断 页面正文里折行按容器宽度算。 页面标题在窄屏上按可显示的行数截断，多出来的直接不显示。 按钮和标签里的文字通常单行，超出部分被省略号吃掉。 三个位置的规则不同，同一串内容会呈现出三种断法。 验收时要三个位置分别看，不能拿正文的结果推断按钮里的表现。 这也是为什么截图评审容易漏：截图往往只截了正文那一屏。 更细一层是筛选标签。这类标签既短又多，容器宽度是按内容自适应的，一旦某个标签里带了西文数字，它的实际宽度会跟设计稿差出一截，一行放三个变成放两个，整个筛选区的高度跟着变，把下面的商品列表推出首屏。 把这三处的可用宽度写进设计规范，比每次改版都重新试一遍省事。规范里要写的是渲染宽度不是字符数，因为这门语言里不同字母的宽度差别很大，同样十个字符占的像素可能差出四成。 ## 手机上的手势方向要不要跟着文字方向翻转？ ## 轮播、抽屉与返回各有各的判断 轮播要翻。内容序列跟阅读顺序绑定，第一张在右边，往左滑看下一张。 抽屉要翻。它的位置对应导航区的位置，导航在右边抽屉就从右边推出。 返回手势要看系统。系统级的边缘返回由操作系统定义，页面不该去改它。 页面内部的返回按钮箭头要翻，指向的是阅读的来路。 这三条合起来就是一个判据：它表达的是文字顺序还是设备约定。 文字顺序的翻，设备约定的不动。 这个判据能解决绝大部分争议，剩下的少数情形靠一条补充规则：如果这个动作在用户心里对应的是物理世界的运动方向，比如下拉刷新、上滑加载，那它跟文字方向无关，一律不翻。判断时问一句这个动作横着还是竖着，竖着的基本都不用管。 这条判据还能反过来用：如果团队为某个交互该不该翻转吵起来了，说明它同时带着文字属性和设备属性，这种情形下最稳妥的处理是跟随系统的本地化行为，而不是自己拍一个方向，因为用户的预期本来就是分裂的。 ## 系统习惯与用户习惯不重合的那一部分 装了阿拉伯语系统界面的用户，系统的方向假设已经翻转过了。 但相当一部分用户的系统界面是英文的，页面却是阿拉伯语的。 这批用户的手上同时存在两套方向习惯。 他们对系统级手势用英文习惯，对页面内容用阿拉伯语习惯。 所以页面内的方向要跟内容走，不要去猜系统语言。 拿系统语言当判断依据，会让这批用户遇到两套互相打架的方向。 这个分裂在中东市场比想象中普遍，尤其在高端机型和年轻用户里，系统界面是英文的比例相当高。产品讨论里如果有人主张按系统语言自动决定页面方向，把这条摆出来通常就能结束争论：真正稳定的信号是页面内容的语言，不是设备设置。 还有一批用户的设备是二手或者水货，系统语言是出厂地的语言，跟他自己和内容都不一致。这批人的比例不高但在部分市场确实存在，是又一条不该依赖系统设置的理由，页面自己把方向说清楚才是稳的。 ## 进度条、步骤条与滑块的方向 结算流程的步骤条要翻，第一步在右边。 已完成的部分从右侧开始填充，这跟阅读顺序一致。 价格区间滑块要翻，最小值在右端。 视频播放进度条不翻，时间轴是设备约定不是文字顺序。 音量条也不翻，理由相同。 这几个例子放在一起，前面那条判据就变得很好记了。 实操里最容易出错的是步骤条上的数字。步骤序号本身是西文数字，在从右往左的容器里它们的排列顺序会被双向算法重排，如果序号是逐个渲染的独立元素就没事，如果是拼成一个字符串再渲染的就会乱序，这个细节在设计稿上完全看不出来。 星级评分是个容易被忽略的例子。评分本身表达的是数量不是文字顺序，按理不必翻转，但它左侧的说明文字和右侧的数值会跟着翻，星星如果不动就会跟标签错位，实际做法是整组一起翻、星星本身的填充方向保持不变。 ## 翻错了会怎样 方向翻错不会让页面崩，只会让用户慢半拍。 慢半拍的代价在漏斗深处会累加成实实在在的流失。 轮播方向反了，用户以为到头了就不再滑，后面的商品等于没上架。 步骤条反了，用户会误判自己还剩几步。 滑块反了，筛出来的价格区间跟预期相反，看到的商品全不对。 这些都不会有人来投诉，只会安静地掉转化。 有个成本极低的自查办法：让一个完全不懂阿拉伯语的同事拿真机走一遍结算流程，只看图形和数字不看文字。如果他在某一步犹豫了，那一步的方向多半有问题，因为图形和数字本身应该已经把方向讲明白了。 要把这类损耗量出来，可以在轮播上加一个滑动次数的埋点，对比两个方向版本的平均滑动次数。方向错的那一版通常会明显偏低，因为用户滑一下发现不对就停了，这个数字比任何主观判断都直接。 ## 标题在窄屏被截断时，被砍掉的是哪一端？ ## 省略号落在左端会吃掉什么 阅读方向从右往左，句子的开头在右边、结尾在左边。 截断从结尾开始，所以省略号出现在左端。 这一点跟从左往右完全对称，本身不难理解。 麻烦在于团队看惯了省略号在右边，第一次看到在左边会以为是渲染错了。 更实际的麻烦是：被砍掉的永远是句子后半段的信息。 如果把品牌名、型号、卖点放在句尾，窄屏上它们就是最先消失的那批。 这条规则对面包屑尤其不友好。面包屑的最后一级通常是当前页面的名称，也就是信息量最大的那一节，在窄屏上恰好落在最左端最先被吃掉，用户看到的是一串上级分类加一个省略号，等于什么也没告诉他。 还有一个连带影响是链接的可点区域。截断之后按钮和链接的实际宽度变了，如果热区是按文字宽度算的，热区会跟着缩到只剩一半，用户点在看得见的文字上却没有反应，这类问题在方向翻转之后出现的频率明显更高。 ## 关键词前置在这门语言里等于放在右边 关键词靠前这条通用建议在这里要重新翻译一次。 靠前指的是逻辑顺序上的开头，视觉上落在右端。 写标题的人如果按视觉直觉把重点放在左边，其实是放在了句尾。 这个错误在中文团队里出现的频率不低，因为大家默认左边就是开头。 检查办法很简单：把标题里的文字按朗读顺序念一遍，第一个念到的词就是最靠前的。 不要用眼睛在屏幕上从左往右扫，那个顺序是反的。 顺带说一句，这条也适用于标题的长度控制。标题与页面主标题之间的分工 (https://zhangwenbao.com/h1-page-title-relationship-multiple-h1-seo-design.html)不变，但阿拉伯字形的平均宽度跟拉丁字母不同，同样字符数占的像素宽度差别很大，按字符数控制长度会失准，得按渲染宽度量。 写作时有个笨办法能彻底避开这个错误：先把标题写成纯文字草稿在文本编辑器里排一遍，编辑器会按逻辑顺序显示，看到的第一个词就是真正靠前的那个，等确认无误再放进设计稿里看视觉效果。 ## 搜索结果里的截断点跟页面里不是一套 页面里的截断按容器宽度算，容器宽度由样式决定。 搜索结果里的截断按结果页自己的宽度算，跟你的样式无关。 两者的可用宽度不同，截断点自然不同。 所以页面里显示完整的标题，在结果页里可能已经被砍了一截。 反过来也成立，结果页显示得下的，在你的移动模板里可能反而放不下。 两边都要量，不能只量一边。 量的时候有个取巧的做法：把候选标题渲染成图片按像素量宽度，比在浏览器里逐个试快得多。移动结果页的可用宽度是个经验值，会随时间调整，所以真正稳妥的是把最关键的那几个词压进前面一小段，而不是去卡某个具体的字符数。 还有第三个位置常被忘掉：社交平台分享出去的卡片。卡片的标题宽度又是另一套，而且多数平台不支持方向属性，长标题在那里的表现基本不可控，稳妥的做法是给分享卡片单独写一条更短的标题。 ## 移动键盘把哪一套数字打进了搜索框？ ## 两套数字形态造成的查询分叉 这门语言的书写传统里存在两套数字形态。 一套是通行世界的那组符号，另一套是阿拉伯语区自己的那组。 两套在编码上完全不同，是两批各自独立的字符。 用户打哪一套，取决于他手上键盘的布局。 同一个人在手机上和电脑上可能打出不同的形态。 于是同一个查询在数据里裂成两条，量都不高，合起来才是真实需求。 这件事在选词工具里几乎不可见，因为多数工具的输入框会做一次静默转换，把两套形态归成一套再去查询，返回的数字看起来干干净净，实际上已经把分叉抹掉了。要看真实分布只能查自己的站内搜索日志。 还有一层影响在广告和分析工具的报表里：两套形态被当成两个不同的关键词分别计费和统计，预算分配会因此失真，出价高的那一套拿走了大部分曝光，另一套明明有需求却因为量小被判为不值得投。 ## 规范化要放在哪一层 站内搜索必须做数字形态的归一，这是底线。 归一放在查询解析层，把两套形态映射到同一个内部表示。 筛选器的数值输入同样要归一，不然筛不出结果。 页面上展示用哪一套是另一个问题，可以按市场习惯决定。 输入端归一、展示端本地化，两件事分开做。 混在一起处理的结果通常是两头都不对。 归一的时候还要顺手处理小数点和千分位。阿拉伯语区常用的小数分隔符与千分位符号跟通行写法不是同一个字符，用户从别处复制粘贴过来的数字里带着这些符号，直接送进数值解析会报错或者被截断，这类报错在日志里通常表现为一堆没有结果的搜索。 归一的具体位置建议放在最靠近入口的那一层，也就是请求进来之后第一时间处理，而不是等到数据库查询前才做。放得越靠后，中间经过的每一个模块都要各自处理一遍，漏掉任何一个都会让整条链路前功尽弃。 ## 三个字段的实际后果 电话号码字段如果只接受一套形态，另一套的用户直接注册不了。 订单号查询同理，用户从短信里复制过来的形态可能跟你库里的不一样。 验证码输入框最要命，六位数字打进去提示错误，用户根本猜不到原因。 这三个场景的共同点是失败了没有任何提示能帮到用户。 解决办法是在输入端做静默归一，不要弹错误提示。 用户不需要知道这背后有两套字符，他只需要它能用。 这类问题在客服记录里的表述通常是我输入没反应，非常难定位。有个快速验证法：拿一台把键盘切成本地布局的真机，在每个数字输入框里各打一遍，五分钟能扫完整个站的表单，比读代码找漏网的字段快得多。 短信和邮件模板同样要检查一遍。系统发出去的验证码如果用了一套形态，而用户的键盘只能打另一套，他就得手工换算，很多人到这一步直接放弃了，而这个流失在站内数据里完全看不见。 ## 移动可用性判定里，哪几条会被这类页面系统性踩中？ ## 点击目标在镜像栅格里的塌陷 很多组件库的间距是靠单侧外边距实现的。 方向翻转之后，单侧外边距如果没跟着翻，相邻元素的间隙就消失了。 间隙消失的直接后果是两个可点区域挨在一起。 可用性检测会把这一条报成点击目标过于接近。 这类问题在从左往右的版本里完全不存在，所以初版测试全绿。 排查时优先看所有硬编码了左右的间距值。 成体系的解法是把间距写成跟随方向的形式，让它自己在两个方向下取正确的一侧。这轮改动的收益不止于间距，图标与文字的相对位置、卡片里的角标位置也会一并修好，因为它们踩的是同一个坑。 这类问题有个特征能帮着快速定位：它总是成对出现，一侧间隙消失的同时另一侧间隙翻倍。看到某处元素挤在一起，往它的反方向看一眼，多出来的那段空白就是原本该在这一侧的间距，两处一起改才对。 ## 横向溢出最常见的四个来源 第一是固定宽度的元素，翻转后超出可视区。 第二是负外边距，方向翻转让它往错的一侧顶。 第三是绝对定位里写死的坐标值。 第四是嵌入的第三方内容，它自己不认方向。 四类里前三类改代码能解决，第四类只能用容器包起来限制。 横向溢出的表现是页面能左右晃动，用户体感很差且很容易发现。 诊断有个笨但有效的办法：给所有元素临时加一圈描边，页面滑到最右侧看哪个框超出去了。比起逐个查样式，这个办法一次能找出全部四类来源，代价是要在测试环境里跑一次。 表格是第五个来源，只是它太常见反而容易被当成理所当然。窄屏上的宽表格无论方向如何都会溢出，区别在于从右往左时用户要往哪一边滑才能看到剩下的列，而滚动条的初始位置默认在左端，正好是反的。 ## 字号与行高要另设一档 阿拉伯字形有相当一部分带有基线以下的延伸笔画。 同样的字号，实际占据的垂直空间比拉丁字母大。 行高按拉丁字母的比例设置，字形之间会显得拥挤甚至相碰。 再加上连写的特性，笔画之间的辨识依赖足够的字号。 实践中通常要把正文字号提一档、行高提高一到两成。 这不是审美偏好，是可读性的下限要求。 提字号会带回一个副作用：同样的容器里能放的字数变少，标题和按钮更容易被截断。所以字号、行高、截断这三件事要一起调，单独调其中一个多半会把另一个搞坏，这也是为什么方向适配的排期不能按单点估算。 低配机上这个问题会被放大。字体渲染的质量在低端设备上明显更差，笔画连写处容易糊成一团，同样的字号在旗舰机上清晰可读、在低配机上勉强能认，所以字号的下限要按低配机定，不能按测试用的那台好机器定。 ## 固定条与弹层的遮挡方向 底部固定条本身没有方向问题，里面的按钮排列有。 主要动作按钮在从右往左时应该落在右侧。 侧边弹出的购物车面板要从右侧滑出。 浮动的返回顶部按钮位置要跟着翻，不然会挡住内容的起始端。 吸顶的筛选条里，标签的排列顺序也要翻。 这些都属于翻转清单里的常规项，容易被漏在于它们通常写在不同的文件里。 最后还有一层是动画方向。面板滑入滑出的位移方向如果没翻，会出现面板从右侧出现却往左侧收起的怪异感，用户说不出哪里不对但会觉得别扭，这类细节在验收清单里基本不会被单列，只能靠真机滑一遍发现。 ## 一套模板同时服务两个方向，代码该怎么组织？ ## 两份样式表还是一份加方向选择器 两份样式表的做法是维护一份主样式，再用工具生成镜像版本。 优点是运行时零成本，缺点是每次改动都要重新生成、两份容易漂移。 一份样式加方向选择器的做法是在同一份文件里写两套规则。 优点是改动只有一处，缺点是文件变大、选择器嵌套变深。 站点规模不大时用后者，方向相关的规则通常不超过全部规则的一成。 站点规模很大或者主题多时，生成两份更好管理。 还有第三条路是把方向敏感的属性统一抽成变量，方向切换时只换变量值。这条路的代价是要先梳理出完整的方向敏感属性清单，前期投入大，但一旦建成，后面新增页面几乎不用再考虑方向问题，长期看是最省的一种。 无论选哪条路，都要把方向相关的规则集中在可以被单独检索的位置，别散落在各个组件文件里。这件事的价值在下一次换主题或者升级组件库时才会显现，能不能在半小时内说清楚全站有哪些方向敏感规则，差别就在这里。 ## 图标与图片里哪些该镜像 指示方向的箭头要镜像。 表示前进后退、上一页下一页的图标要镜像。 带文字的图片要重做，不能靠翻转。 产品实拍图绝对不能翻转，翻了商品本身就错了。 时钟、播放、音量这类图标不镜像。 logo不镜像，除非品牌方另有一套本地版本。 手写体或者书法风格的装饰图形要单独判断。这类图形常常本身就带方向感，翻转后会变得很奇怪，但不翻转又跟整体版式冲突，通常的解法是给这个市场单独出一版，成本不高而且是一次性的。 还有一类要单独处理的是带箭头的流程图和示意图。这类图既有方向语义又常常内嵌文字，翻转会让文字倒过来，不翻转又跟阅读顺序冲突，正确做法是把图重新画一版，顺手把图里的文字也换成本地语言。 ## 第三方组件的方向支持怎么验 不要看文档说支持就信，要拿真实内容跑一遍。 测试串固定成一段纯本地语言文字加一串西文数字。 看三件事：顺序对不对、折行对不对、输入光标从哪一端起。 三件事里有一件不对，这个组件就要么改要么换。 评论、日期选择器、富文本编辑器是出问题最多的三类。 地图与图表组件通常问题较少，因为它们本来就不依赖文字方向。 验组件时顺手记下版本号和验的日期，写进一份内部清单。组件升级后方向支持退化的情况并不罕见，有清单在，下次升级时能定向复验，不用整套重来。这份清单的维护成本极低，但能省掉的返工次数很可观。 有一类组件要格外小心：把文字画进画布或者转成图形的那些，比如某些图表库的坐标轴标签。它们绕过了浏览器的文字排版，方向和折行全靠自己实现，多数库在这一块做得很粗糙，遇到就直接换掉比修划算。 ## 移动端的查询，跟桌面上是同一批词吗？ ## 输入成本让查询变短变口语 在手机上打这门语言，比打拉丁字母慢。 字母形态随位置变化，输入法的候选逻辑也更复杂。 输入成本一高，用户就倾向于打更短的词。 短词更接近口语，而口语跟书面语在这门语言里差得不小。 结果是移动端的查询整体更口语化、更短、更依赖上下文。 按桌面数据做的词表，覆盖不住这半边。 这个偏移的幅度可以自己量：把站内搜索日志按设备切开，比较两边查询的平均长度和词数。如果移动端明显更短，说明这个偏移在你的市场是成立的，值得单独给移动端补一批短词落地页；差别不大就不用折腾。 这个成本差异还解释了另一个现象：移动端用户更依赖搜索建议和历史记录，因为选比打省力。这意味着建议列表里出现什么词，会实实在在地反向塑造用户的查询习惯，站内搜索的建议逻辑值得单独调一轮。 ## 语音输入把方言送进了搜索框 手机上按住说话比打字快得多，使用率明显更高。 说出来的是日常口语，也就是方言，不是书面标准语。 识别结果会被转写成文字送进搜索框。 于是方言词以书面形式出现在查询日志里。 这批词在传统选词工具里基本查不到。 它们只在自己站的搜索日志和实际落地词里露面。 方言与标准语的分工在这门语言的选词方法 (https://zhangwenbao.com/arabic-seo-rtl-layout-msa-dialect-keyword.html)里已经讲过，这里要补的是移动端把这条分界线往方言那边推了一截。同一个品类的落地页，标题用标准语、正文里带上两三个高频方言说法，是成本最低的兼顾办法。 语音识别本身也会引入固定的偏差：识别引擎的训练数据以标准语为主，遇到方言时会把某些音归到最接近的标准语词上，于是日志里会出现一批看着像错别字实际是识别产物的词，这类词不必做覆盖但要能识别出来排除掉。 ## 移动端的字母省略率更高 有几个字母存在带记号与不带记号的两种写法。 词首那个带上加符号的字母，很多人直接打成不带的。 词尾那个圆形字母，常被打成另一个形近的字母。 还有一个字母的带点与不带点两种形态，在不同地区习惯不同。 这三类省略在手机上比在电脑上更常见，因为切换键盘层级要多按一次。 词表里如果只收规范写法，这部分流量接不住。 处理办法不是给每种写法都做页面，而是在站内搜索和内部匹配层做等价折叠，同时在正文里自然地把两种写法都写到。这跟另一门从右往左的语言里省略元音标记 (https://zhangwenbao.com/hebrew-seo-unvocalized-script-root-letters-keyword.html)造成的匹配问题是同一类，只是省略的对象不同。 要摸清自己市场的省略程度，可以拿站内搜索日志做一次统计：把同一个词的规范写法和各种省略写法都数一遍，算出省略写法的占比。这个比例在不同国家差别很大，别拿别人的经验值套自己的数据。 ## 上线顺序错了，两类改动会互相盖掉对方的效果 ## 先钉字符串，再动布局 字符串层的改动指的是隔离、不折行、数字归一这些。 布局层的改动指的是镜像、间距、字号行高这些。 先做字符串层，因为它的效果最容易被单独观测。 布局改动一上，页面的观感整体变了，字符串层的收益就混进去说不清了。 顺序反过来做，两批改动的效果会互相掩盖。 两批之间留两到三周的观察窗口。 这个顺序还有个现实理由：字符串层的改动风险低、回滚容易、不需要设计参与，可以在等设计稿的间隙先做掉，等于把排期利用起来了。布局层的改动通常要等设计确认，中间的空档正好够跑完第一批的观察。 ## 灰度的分面要按方向切 常规的灰度按流量比例切，这里不够用。 因为从右往左的页面只占全站的一小部分，随机切样本量太小。 正确做法是先按语言分面，再在这个面内做灰度。 这样才能在合理时间内拿到有统计意义的结果。 不这么切的话，方向相关的改动会被主流量的波动淹没。 指标也要分面看，不能只看全站汇总。 分面之后还要注意一件事：这个市场的流量周期跟欧美不同，周末的起止日不一样，按自然周对比会错位。做同比时先确认这个市场的一周从哪天开始，否则得出的结论会系统性偏移一天。 还要留意样本里的设备构成。这个市场的低配安卓占比通常高于欧美，如果灰度桶随机分配时设备构成失衡，观测到的差异可能来自设备而不是改动本身，分桶时把设备档次也纳入平衡条件会稳得多。 ## 三级验收 第一级是模拟器，快，用来筛明显错误。 第二级是真机，必须有真机，手势和键盘只有真机上是真的。 第三级是本地用户实测，找几个真正用这门语言的人走一遍。 三级各能发现不同层次的问题，缺一层就会漏一类。 真机要覆盖高低两档配置，低配机上字体渲染差别很大。 本地用户实测的价值在于他们会说出你根本想不到的别扭之处。 做真机测试时把系统语言分成两种情况各测一遍：系统是本地语言的，和系统是英文的。前面说过这两批用户的方向习惯不同，只测其中一种会漏掉另一批人遇到的问题，而这两批人在这个市场里都不是小数。 ## 哪些问题不归语言层，要一句话交出去 ## 移动友好本身是算法与技术议题 页面在窄屏上能不能用，是一个跟语言无关的通用问题。 它的判定标准、权重变化、检测工具都属于技术层。 这一篇只讲这门语言额外带来的那部分。 通用的那半边有专门的讨论，不在这里重复。 把两者混在一起讲，结果是两边都讲不透。 分开之后，语言层的清单反而变得很短很具体。 通用那一半可以直接看移动友好更新的来龙去脉 (https://zhangwenbao.com/google-mobilegeddon-mobile-friendly-update-explained.html)，以及首屏内容的版面机制 (https://zhangwenbao.com/above-the-fold-content-seo-page-layout-mechanism.html)；本篇的判据是把语种换成英语还成不成立，不成立的才留在这里。 ## 多语言站的架构与地区定向 一个站要不要为这个市场单开目录、用哪种域名结构、地区定向怎么设，都是架构问题。 架构问题跟具体是哪门语言无关，换成任何语言都一样要面对。 这部分有成体系的做法，按多语言站的架构与语言地区标注 (https://zhangwenbao.com/international-seo-hreflang-complete-guide.html)那套走就行。 本篇涉及架构的地方只有一处：方向属性要写在页面根元素上。 这条属于标记层，跟目录结构无关。 其余架构决策都交出去。 顺带提醒一句常见的混淆：语言标注和方向标注是两件事，前者说这是什么语言，后者说文字从哪边开始。有的模板只写了语言没写方向，浏览器会按默认值处理，一整页的方向就错了，而这个错误在语言标注的检查里查不出来。 ## 引擎差异与本地平台 这个市场里用户从哪个入口开始搜，属于引擎层的问题。 不同引擎对方向、对本地字符的处理确实有差别。 但那属于各引擎自己的排序与呈现规则，不是这门语言的属性。 需要了解某个引擎的具体打法时，看第二大搜索引擎的完整打法 (https://zhangwenbao.com/bing-seo-complete-guide-organic-ranking.html)那类专门讨论。 本篇只保证一件事：无论从哪个入口进来，页面本身在窄屏上不出方向错误。 入口的选择和分配是另一个层面的决策。 把边界划清楚有个额外好处：跨部门讨论时不容易扯皮。方向问题归前端和内容，入口问题归渠道，架构问题归技术，三方各自有清单，比开一个大会把所有问题堆在一起有效率得多。 ## 常见问题解答 ## 桌面站已经做过从右往左适配，移动端还需要重新做一遍吗？ 模板层不用重做，交互层必须重做。桌面时代验过的方向属性、栅格镜像、表格列序这些结论继续有效，只要模板没有大改就可以直接跳过。真正要重新验的是四类只在窄屏上成立的问题：混排字符串的折行、标题与标签的截断、手势方向、移动键盘带来的数字形态分叉。这四类在桌面测试里没有对应的动作，所以再完整的桌面清单也覆盖不到。实操上建议把两份清单物理分开，一份标注为宽屏结论、一份标注为窄屏专属，每次改版时前者抽查后者全验，这样既不会重复劳动，也不会漏掉新增的窄屏问题。判断某一条属于哪一份的办法也很简单：问它在宽屏上会不会发生，不会的就属于窄屏那份。一个常见的判断失误是以为改版幅度小就不用重验，实际上只要容器宽度或者字号变过，折行与截断的结果就全变了，这两项跟改动大小无关只跟宽度有关。 ## 价格在手机上被折成两行，最快的修法是什么？ 最快的修法是在输出价格的模板函数里给整串加上方向隔离并禁止折行，两条一起加，改一处全站生效。方向隔离让这一段成为独立的方向单元，不再受左右邻居影响；禁止折行保证它不会被切开。加完之后要检查容器宽度是否足够，宽度不够时价格会撑破容器，需要配合缩小字号或者把价格单独占一行的布局。同样的处理要覆盖型号、规格、尺码这些混排字段，它们踩的是同一个坑。别忘了结构化数据和元描述里的价格串也走同一套处理，那两处不参与页面渲染，但会出现在搜索结果的摘要里，同样会折行、同样会被拆开，而且用户是在进站之前就看到的。改完记得回头看一眼列表页的卡片，卡片里的价格容器通常比详情页窄得多，详情页上验通过的宽度设置搬到卡片里往往还是会撑破。 ## 页面方向该按用户的系统语言判断还是按页面内容判断？ 按页面内容判断，不要看系统语言。这个市场里有相当比例的用户把系统界面设成英文，页面内容却是本地语言，他们手上同时存在两套方向习惯：对系统级手势用英文习惯，对页面内容用本地习惯。如果页面方向跟着系统语言走，这批用户会遇到两套互相打架的方向，体验比统一按内容走差得多。正确做法是在页面根元素上明确写死方向属性，跟着内容语言走，同时不去改系统级的边缘返回手势，那属于操作系统的地盘。还有一个常被混淆的点：语言标注和方向标注是两个独立的属性，只写了语言没写方向的模板会走浏览器默认值，整页方向就错了，而这个错误在语言标注的检查里完全查不出来。如果站点同时提供多个语言版本，方向属性要跟着当前页面的语言走而不是跟着用户的偏好设置走，否则切换语言时会出现方向没跟着变的半截状态。 ## 两套数字形态要不要都做关键词覆盖？ 查询端要都接住，展示端选一套就够。用户打哪一套取决于他手上的键盘布局，同一个人在手机和电脑上可能打出不同形态，这会让同一个需求在数据里裂成两条，单看每一条量都不高。处理办法是在站内搜索的查询解析层做归一，把两套形态映射到同一个内部表示，筛选器的数值输入同样处理；页面上展示用哪一套则按当地习惯决定，两件事分开做。特别要检查电话号码、订单号、验证码这三个输入框，只接受一套形态会让另一套的用户直接卡住而且看不到任何有用的提示。顺手把小数分隔符和千分位符号也纳入归一范围，用户粘贴过来的数字里常带着这两个本地符号，直接送进数值解析会静默失败。排序也要一并处理，两套形态在按字节比较时的次序跟数值大小完全对不上，价格排序、评分排序这类功能如果直接按字符串排会给出乱七八糟的结果。 ## 轮播和进度条的方向，到底哪个该翻哪个不该翻？ 判据是这个元素表达的是文字顺序还是设备约定。表达文字顺序的要翻：轮播、结算步骤条、价格区间滑块、导航抽屉、页面内的返回箭头。属于设备约定的不翻：视频播放进度条、音量条、系统级边缘返回手势、时钟与播放类图标。还有一条补充规则处理竖向动作：下拉刷新、上滑加载这类跟物理运动方向绑定的交互一律不翻，判断时先问这个动作是横着还是竖着，竖着的基本都不用管。实操中最容易漏的是步骤条上的序号，如果序号是拼成一个字符串再渲染的，会被双向算法重排成乱序，改成逐个渲染的独立元素就好了，这个细节在设计稿上完全看不出来。拿不准的时候还有个兜底判断：看这个元素在纸质媒介上会不会跟着排版方向变，会变的就翻，不会变的就不翻，这个类比对绝大多数争议都成立。 ## 方向适配的改动应该按什么顺序上线？ 先做字符串层，再做布局层，中间留两到三周观察窗口。字符串层指的是方向隔离、禁止折行、数字归一这些，它们风险低、回滚容易、不需要设计参与，可以在等设计稿的间隙先做掉。布局层指的是镜像、间距、字号行高这些，一旦上线页面观感整体改变，之前那批改动的收益就混进去说不清了。灰度也要调整：常规的按流量比例切在这里样本量不够，因为这类页面只占全站一小部分，正确做法是先按语言分面再在面内灰度，指标也分面看。做同比时先确认这个市场的一周从哪天开始，按欧美的自然周对比会系统性错位一天。两批改动之间的观察窗口里不要同时上线内容或者词表的调整，否则三件事的效果搅在一起，前面费劲做的分面灰度就白做了。 ## 没有懂这门语言的同事，怎么自己先验一轮？ 可以验掉大部分问题，因为窄屏上的方向问题多数是图形和数字层面的，不依赖读懂文字。具体做法是拿一台真机，把系统键盘装上本地布局，然后走三条路径：商品列表滑到底、走完整个结算流程、在每个数字输入框里各打一遍。过程中只看图形、数字和排版，不看文字。轮播往哪边滑能到下一张、步骤条从哪端开始填、价格串有没有被折断、省略号出现在哪一端、输入框接不接受打进去的数字，这五件事全是不懂语言也能判断的。剩下真正需要语言能力的只有文案本身和词表，那部分再找本地用户过一遍，两小时足够。这套自查最好在提测之前做，能挡掉大半返工。自查时把整个过程录屏，发给本地用户看比让他们自己重新走一遍效率高得多，他们能在录屏里直接指出哪一步不对劲，省掉来回沟通的时间。 ## 权威参考资料