# 保哥笔记 — 小语种SEO

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

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

---

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

- URL：https://zhangwenbao.com/ukrainian-russian-seo-bilingual-market-content-split.html
- 分类：小语种SEO
- 发布：2014-10-15  |  更新：2026-07-26
- 摘要：讲乌克兰语与俄语的SEO分工：内容按查询语言而非用户国籍分配、三档资产复用判据、呼格在称呼模板里的落地、八个互斥字母做语言识别、键盘布局错位产生的系统性错拼、月份名静默回落与转写规则分叉。
- 关键词：关键词研究,内容本地化,小语种SEO

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

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

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

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

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

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

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

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

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

俄语那一篇讲的是俄语这门语言本身 (https://zhangwenbao.com/russian-seo-cyrillic-cases-declension-wordstat-keyword.html)：六个格怎么变、一个名词能变出多少种搜索写法、工具口径为什么会把它们合并成一个数字。那是单一语言的词法问题。

本篇一个词形都不重讲。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

处理这件事的手段在架构层——语言与地区标注、规范化、内部链接的指向。国际化SEO那一篇讲了这套标注怎么落地 (https://zhangwenbao.com/international-seo-hreflang-complete-guide.html)，这里不重复。

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

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

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

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

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

在称呼里。

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

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

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

乌克兰语在线词典给出的词条会列出各个格的形态 (https://slovnyk.ua/index.php?swrd=%D0%BD%D0%B5%D0%B4%D1%96%D0%BB%D1%8F)，这个格是明确单列的，做模板时可以对着查。

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

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

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

最省事的办法是绕开它。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

四个地方我都用过。

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

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

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

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

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

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

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

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

会，这是它唯一的短板。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

不要，一个都不要。

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

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

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

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

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

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

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

是表示星期日的那个词。

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

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

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

另一个高频假朋友是表示时间的那个词 (https://slovnyk.ua/index.php?swrd=%D1%87%D0%B0%D1%81)，在两门语言里指的分别是时间和小时，配送时效的文案里天天要用到它。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## 用哪个字母的域名后缀？

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

西里尔那个已经进了根区，IANA根区数据库里能查到它的委派记录 (https://www.iana.org/domains/root/db/xn--j1amh.html)，写进浏览器时用的是Punycode形式。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

用俄语的词干算法去处理乌克兰语文本，大部分词能对，剩下那部分错得没有规律，很难排查。波兰语那篇讲过屈折语的词形覆盖该怎么估工作量 (https://zhangwenbao.com/polish-seo-seven-cases-diacritics-keyword-research.html)，这里的量级跟它是一个档次的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

捷克语与斯洛伐克语那一对是两个国家 (https://zhangwenbao.com/czech-slovak-seo-content-reuse-decision.html)，货币、法律、物流、域名全都分开，语言只是分叉里的一项。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## 站内搜索该怎么设计？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## 验收看哪几个数字？

四个。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## 常见问题解答

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## 权威参考资料



## 印尼语SEO和马来语能不能合并成一套，语言学界至今没有定论，你的关键词表里必须有

- URL：https://zhangwenbao.com/indonesian-malay-seo-two-markets-vocabulary-split.html
- 分类：小语种SEO
- 发布：2014-07-09  |  更新：2026-07-25
- 摘要：讲印尼语与马来语的SEO分工：三档内容复用判据怎么划、正字法统一为何掩盖了词汇分叉、前缀同化让词干还原失效、重叠式复数的归一处理、两地英语渗透率差异、为何这里用二选一而非资产分层框架。
- 关键词：SEO,内容本地化,小语种SEO

> **TLDR**：摘要：拼写在1972年被两国同步统一了，词汇却因为荷兰和英国分治永远统一不了。这篇给出两个市场的三档复用判据，讲清前缀吃掉词干首字母的还原坑、几个能出事故的假朋友，以及为什么省下的词形变体预算该全砸在词汇分叉上。

> 摘要：拼写在1972年被两国同步统一了，词汇却因为荷兰和英国分治永远统一不了。这篇给出两个市场的三档复用判据，讲清前缀吃掉词干首字母的还原坑、几个能出事故的假朋友，以及为什么省下的词形变体预算该全砸在词汇分叉上。

做五金建材的客户问过我一个问题，问得很实在。

他们已经有一套印尼语的商品库，现在要开马来西亚，想知道能不能直接复制过去改个价格就上线。

我的回答是：拼写基本不用改，词得挑着改，标题和描述得重写。

这三句话不是敷衍，它对应着三档完全不同的成本，而分界线的位置跟很多人的直觉相反——最像的那一层是拼写，最不像的那一层是日常用词。

这篇就来把这条线画清楚。

## 印尼语和马来语到底算不算一门语言？

语言学界至今没有一个统一的答案。

有人把它们看成同一门马来语的两个标准变体，有人坚持它们已经是两门独立的语言。两边都能拿出一堆证据。

好在做SEO的人不需要卷进这场争论。

我们的问题小得多也具体得多：同一批商品页，要不要做两套？答案在关键词表里，不在语言学论文里。

而关键词表给出的答案很明确——要做两套，但不是从零做两套。哪一层能共用、哪一层必须分开，是可以逐层算清楚的。

换个说法：这个问题在学术上悬着，在预算表上必须落地。你不能因为学界没结论就跳过这道决策，钱要今天花出去。

而且落地之后你会发现，判定标准跟语言学的标准根本不是一套。语言学关心的是系统性差异，你关心的是买家会不会看着别扭。

## 为什么这两门语言的拼写反而是最像的一层？

因为拼写被人为统一过一次。

1972年，印尼和马来西亚同步推行了一次正字法改革，把原先按荷兰和英国两套习惯写出来的形态统一到一起。

改革之前，同一个音在印尼写作一种形态、在马来西亚写作另一种；改革之后，两边写法一致。

这次改革的结果是：今天你拿一段印尼语和一段马来语并排放着，字母层面看起来几乎一样。

这份表面的相似性，正是所有误判的起点。老板看一眼说这不都一样吗，然后砍掉一半预算。

这次改革的规模比多数人想象的大，改动覆盖了好几组常用的辅音组合，两国是协商之后同步执行的。

在语言政策史上这算是一次少见的成功——两个刚独立不久的国家，在一件纯技术的事情上达成了一致，并且真的都执行了。

## 那词汇为什么统一不了？

因为拼写可以靠一纸公文统一，词汇不行。

印尼在独立前是荷兰的殖民地，马来亚是英国的。三百多年里，两边各自从宗主国的语言里借进了大量日常词。

办公室、账户、药店、发票、火车站，这些天天要用的词，两边借的来源不一样，借来的词自然也不一样。

正字法改革改的是怎么写，改不了写的是哪个词。

所以这两门语言的关系是：越正式的书面语越像，越日常的口语越不像。而电商的关键词，绝大多数落在日常这一端。

还有一层原因是使用场景不同。同一件东西，两国的行业发展路径不一样，进入市场的时间不一样，起名字的时候参照的对象自然也不一样。

建材类是重灾区。同一种板材、同一种五金件，两国的行业内叫法可能一个来自荷兰语一个来自英语，字面上毫无关系。

## 三档复用判据怎么划？

我给这类近亲市场的判据一直是三档，印尼与马来这一对也适用。

第一档，可以整块照搬：商品图、尺寸表、参数数值、结构化数据里的数字字段、视觉设计。这些跟语言无关。

第二档，只换词不动结构：商品属性名、筛选器标签、规格单位、行业术语表。句子骨架不变，把词换掉。

第三档，必须重写：标题、元描述、正文、促销文案、常见问题、客服话术。这一档没有捷径。

关键是第二档和第三档之间那条线画在哪儿。画错了，要么白花钱，要么上线之后满页都是本地人看着别扭的词。

这三档的成本比大概是一比三比十。也就是说第三档虽然只占内容量的三成，却要吃掉一大半预算。

知道这个比例之后，你就不会在第一档上纠结太久，也不会拿第三档的东西去跟老板说这个可以复用。

## 第一档真的能整块照搬吗？

基本能，但有两个例外要拎出来。

一个是尺寸和规格的表述习惯。数值本身通用，但两边在标注方式上有细微差别，尤其是建材类的长度和厚度。

另一个是货币和数字格式。两国货币不同，币值量级差得远，价格显示的位数、千位分隔的写法都要分别处理。

除了这两处，图片、图表、视频、结构化数据里的数值型字段，确实可以一份资产两地用。

这一档能省下的钱不少，别因为整体上要做两套就连这一档也重做一遍。

还有一个容易忽略的细节：图片里如果有文字，那张图就不属于第一档了。产品图上的标签、示意图上的注释，都得分开做。

解决办法是在设计阶段就把文字从图里剥出来，用叠加的方式呈现。这样图还是一份，文字按市场切换。

## 第二档换词的时候最容易漏什么？

最容易漏的是属性字典里的值，不是键。

大家都会记得把材质这个字段名翻译好，但字段下面那几十个可选值——不锈钢、镀锌、哑光、磨砂——往往是一次性导入的，没人回头逐条核。

这批值会出现在筛选器上、面包屑里、商品标题的自动拼接里，覆盖面比字段名大得多。

我的做法是把属性值单独拉一张表，两列并排，母语者逐条判定：相同、不同、需要确认。荷兰语与佛兰芒语那一对也是靠这张表把词分成三类 (https://zhangwenbao.com/dutch-seo-netherlands-belgium-flemish-two-markets.html)，方法可以直接搬过来。

这张表做一次，能用很多年，是这类项目里投入产出比最高的一件活。

第二容易漏的是单位。长度、重量、容积的单位两边基本一致，但口语里的习惯说法可能不同，尤其在传统品类上。

第三容易漏的是颜色词。颜色是筛选器里的高频维度，而某些颜色的通行叫法两边确实不一样，这类词还特别容易被当成不需要核的常识。

## 那几个能真出事故的假朋友是哪些？

假朋友是这一对语言里最危险的东西，因为它不报错，只是意思变了。

有一个词在印尼语里是白费、没用的意思，在马来语里是免费的意思。你在马来西亚的落地页上写这个词想说免费送货，印尼用户读到的是送货白搭。

还有一个表示交通工具的词，在印尼指火车，在马来西亚指汽车。汽车配件的品类页要是照搬，整个品类就跑到另一个行业去了。

再有一个词，印尼语里指官员，马来语里指办公室。企业介绍页上一句我们的办公室，能被读成我们的官员。

最要命的是有个印尼语里表示需要的常用词，在马来语里是个粗俗词。这个词在印尼的商品描述里随处可见，照搬到马来西亚站上就是事故。

再举一个方向相反的：有个词在马来语里指普通的小孩，在印尼语里却带着旧时代的负面含义。儿童品类的文案要是照搬，性质就变了。

这几个例子的共同点是：它们都不是生僻词，全是高频日常词。假朋友最危险的地方就在于它们太常用，常用到没人想起要核。

核这批词的时候有个省时的顺序：先核出现在按钮、价格区、配送说明这三处的词，这三处的错误代价最高。

## 假朋友清单该怎么建？

不要指望翻译软件给你标出来，它给不出。

可行的办法是从你自己的高频词表出发。把两边站点的高频词各拉一份，取交集，这批词是两边都在用的。

然后把交集里的每个词，分别丢进两国的权威词典查释义。印尼语大词典的在线版按词根收录词条 (https://kbbi.web.id/pukul)，马来西亚那边也有官方的在线查询入口。

两边释义对不上的，就是嫌疑词，标记出来交给母语者确认。

一个中等规模的电商站，这套流程通常能筛出二三十个真假朋友。数量不多，但每一个都在关键位置上。

这张表建好之后要进流程，不能只存在某个人的电脑里。最好的位置是内容管理系统的校验环节，写作时命中就弹提示。

我见过团队把清单做得很漂亮，然后放在共享盘里，半年之后新来的文案根本不知道有这东西。工具化这一步不能省。

## 为什么前缀会把词干的第一个字母吃掉？

这是印尼马来语系独有的构词坑，也是词干还原最容易出错的地方。

这两门语言用前缀来改变词性和语态。加前缀的时候，如果词干以某些辅音开头，这个辅音会被前缀同化掉，变成前缀鼻音的一部分。

结果是：加了前缀之后的形态，看起来跟原词干的开头完全不一样。你想按前缀匹配把两者关联起来，匹配不上。

更麻烦的是这个规则不是一刀切的，不同的起始辅音走不同的路径，有的被吃掉，有的保留，有的还要加个过渡音。

所以词干还原在这两门语言上不是砍前缀那么简单，得按规则表反推。

举个不需要懂这门语言也能理解的类比：相当于英语的某个前缀加上去之后，把后面那个词的首字母也一起改掉了。

这种现象在语言学上有专门的名称，但对做SEO的人来说，只需要知道两件事——它会发生，而且有规则可循。

## 词干还原错了会有什么后果？

后果是同一个概念在你的数据里裂成好几份。

动词形态、名词形态、被动形态，本来都指向同一个词根，还原不到位就成了三个互不相干的词。

搜索量被分摊，竞争度算不准，内链的锚文本聚不到一起，站内搜索也匹配不上。

好在这个问题有成熟的解法。Snowball的印尼语词干算法完整描述了前缀同化的规则 (https://snowballstem.org/algorithms/indonesian/stemmer.html)，实现是公开的，直接用就行。

要注意的是这套算法是给印尼语设计的，马来语的部分规则有出入，不能无差别套用。

判断有没有出问题的方法很简单：拉一份站内搜索的高频查询，看看同一个词根的不同形态是不是各自独立地出现在榜单上。

如果是，说明还原没做，或者做得不彻底。合并之后你会发现有些词的真实量级比原来看到的高出一大截。

顺带提醒：还原之后别把原始形态丢掉。展示层要用用户实际会写的形态，还原只发生在匹配和统计这一层。

## 自动补全为什么在这两门语言上特别难做？

因为词典按词根收录，用户按实际形态输入，两者对不上。

用户在搜索框里打的是带前缀的完整形态，而你的候选词表如果是从词典导出来的，里面全是光秃秃的词根。

前缀匹配这时候就废了：用户打的头几个字符是前缀，词根表里没有一个词以它开头。

解法是把候选词表按构词规则展开，每个词根生成它常见的几种带前缀形态，都进补全索引。

展开之后索引会变大不少，但对这两个市场来说值得——用户几乎不用词根形态搜东西。

展开的时候要控制范围，只展开高频的几种前缀形态，不要把所有理论上合法的组合全生成出来。

全展开会让索引膨胀好几倍，而且补全结果里会混进大量没人用的生造形态，看着比不给建议还糟。

## 重叠式复数会不会影响关键词匹配？

会，而且这是个很容易被欧洲语言的经验带偏的地方。

这两门语言表示复数不靠词尾变化，靠把词整个重复一遍，中间用连字符连起来。

所以复数形态的字符数是单数的两倍多，长得完全不像同一个词的变体。

你的去重逻辑如果基于编辑距离或者前缀相似度，会把单复数判成两个毫不相干的词。

处理办法很简单：识别连字符两侧是否相同，相同就归一到单数。这条规则五行代码，能救一大批数据。

还有一种情况是部分重叠，只重复词的前半段，这类形态更难识别，规则也更零散。

好在部分重叠在现代日常语言里用得不多，商品相关的词里几乎碰不到。先把完全重叠处理好，够用了。

## 没有时态没有性没有复数变化，这算好消息吗？

算，而且是个大好消息，只是很少有人把它当成预算变量来用。

在德语、波兰语、芬兰语那些语言上，词形变体覆盖是关键词工作里最烧钱的一块——一个名词能有十几种形态，每一种都可能被搜。

印尼语和马来语几乎没有这一块。名词不变格，动词不变时态，形容词不跟着名词改性数。

省下来的这笔预算，应该整块挪到词汇分叉的核对上去。这是这两个市场最反直觉的一条资源配置结论。

可惜大多数团队的做法是：因为没有词形变体，干脆判定这门语言很简单，连词汇核对也一起省了。

这个判断上的偏差有个很具体的表现：团队会把这两个市场的排期压得很短，因为看起来简单。

然后在上线前一周发现假朋友没核、口语词没采、品类词叫法不对，只能带着问题上线，后面再慢慢补。

## 那省下的预算具体该花在哪儿？

三个地方，按优先级排。

第一是假朋友与借词分叉的逐条核对，也就是前面那张两列表。这一项直接防事故。

第二是两个市场的口语查询采集。印尼的非正式缩写极多，这批查询在任何关键词工具里都没有数据。

第三是品类词的实际叫法调研。同一件商品，两国的行业里叫法可能完全不同，尤其在建材、汽配、家电这几个品类。

这三项加起来的成本，还不到给一门屈折语做词形覆盖的一半。

这三项还有个共同点：都需要本地人参与，都不能靠工具跑出来。所以要提前排期，不能等到最后一周才找人。

本地母语者的档期通常比你想的紧张，尤其是懂电商语境的那批人，好的审校是要提前约的。

## 印尼用户的非正式缩写有多严重？

严重到你的关键词工具基本失明。

印尼人在手机上打字时会大量使用辅音缩写，把常用词的元音全部去掉，只留几个辅音字母。

这类写法在社交媒体、聊天、评论区占绝对主流，也会大量出现在搜索框里。

但它们不进任何官方词表，关键词工具的数据源里也几乎没有，你在工具里看到的搜索量是被严重低估的。

唯一可靠的采集渠道是你自己的站内搜索日志和客服记录。这批数据在印尼市场的价值，比在多数市场都高。

要不要在页面上使用这类缩写？我的建议是正文不用，但常见问题区和站内搜索的同义词表里要收。

正文用了会显得不专业，不收进同义词表又接不住真实查询。分层处理，各取所长。

## 马来西亚的英语渗透率怎么处理？

这是两个市场最大的行为差异之一。

马来西亚是多语社会，城市用户在搜索时大量直接使用英文，尤其是技术类、专业类的品类词。

印尼的英语渗透率明显低一档，同样的品类，印尼用户更倾向用本地词。

这意味着马来西亚站的关键词表里必须给英文词留出真实的份额，不是象征性地放几个。

而印尼站如果照抄这份英文比重，会把预算浪费在一批本地几乎没人搜的词上。

判断比例的方法不是拍脑袋，是去看站内搜索日志里英文查询占多少，再跟本地竞品的页面用词对照。

两个数据源都指向同一个方向时，那个比例就可以拿来做规划。只有一个数据源支持的结论，先存疑。

## 两个市场的搜索意图会不会也不一样？

会，而且差别体现在查询的长度和形态上。

印尼用户的查询更口语、更长、更常带疑问词；马来西亚用户的查询更短、更接近关键词堆叠，混着英文。

这直接影响你的内容形态：印尼站的问答型内容能吃到更多长尾，马来西亚站的品类页和对比页更吃香。

同一套内容模板铺两边，总有一边是错配的。

这一条不需要重写全部内容，但需要在内容规划的比重上做区分——问答做多少、清单做多少、对比做多少。

这个差异还会影响你写标题的方式。面对更长更口语的查询，标题里带一个自然的问法能明显提升点击。

面对更短更关键词化的查询，标题前置核心词、后面挂修饰更管用。同一批商品，两边的标题模板可以完全不同。

规划比重的时候可以先按七三开试：印尼侧问答型占七成，马来西亚侧品类与对比型占七成，跑一个季度再按数据调。

## 印尼语页面会不会在马来西亚被展示出来？

会，而且这是这一对市场独有的、别处很少遇到的麻烦。

因为两门语言在字母层面太像，检索侧对它们的区分并不总是干净。一个写得很正式、用词又恰好两边通用的印尼语页面，完全可能出现在马来西亚的结果里。

听起来像白捡流量，实际是两头不讨好。

马来西亚用户点进来，看到的是一批用词陌生的文案、一个不能配送的地址、一套不对的货币。跳出率会很难看，而这个信号又会反过来影响你在本地市场的表现。

反方向同样成立，只是频率低一些，因为马来西亚站的英文混用比例高，语言特征更明显。

处理办法在架构层，不在语言层：把地区与语言标注做对、把配送区域写清、把货币锁死。语言层能做的是让两边的用词分叉足够明显，帮检索侧把它们分开。

自查方法是在两个市场分别抽查十个核心词的结果页，看有没有对面市场的页面混进来，混进来几条就说明区分度不够。

## 用户评价能不能跨市场共用？

数值可以，文字不行。

评分、评价数量、好评率这些数字反映的是商品本身的质量，跟语言无关，两边共用没有问题，还能帮新市场快速建立信任。

但评价正文必须分开展示。印尼买家写的评价里满是本地口语和缩写，马来西亚买家读起来能懂大概，却一眼知道这不是本地人写的。

更实际的顾虑是：评价里经常提到配送时效、客服响应、包装状态，这些体验在两个市场根本不一样。

我的做法是数字全站共用、文字按市场分区展示，同时在页面上说明这个评分汇总了多个市场。透明比藏着强。

## 品牌标语和口号要不要两边分开写？

要，而且这是最不该省的一处。

标语是全站出现频率最高的一句话，出现在页头、页脚、每一封邮件、每一张图上。它读起来别扭，整个品牌就跟着别扭。

而标语恰恰是最依赖语感的文本类型——押韵、节奏、双关，这些东西在两门近亲语言之间几乎不可能同时成立。

一句在印尼语里朗朗上口的标语，用马来语读出来可能既不押韵也没有那层双关，只剩下字面意思。

正确做法是把品牌要传达的那个概念写下来，让两边的母语创意各自写一版，而不是翻译。这笔钱花一次，用很多年。

## 关键词工具在这两个市场为什么普遍偏低？

三个原因叠在一起。

第一是非正式缩写不进词表，前面已经说过，这一块在印尼尤其严重。

第二是词干还原不到位，同一个词根的几种形态各自算量，每一个看起来都不大，加起来才是真实规模。

第三是英文混用查询的归属问题——一个半英文半本地语的查询，工具可能把它归到英文那一侧，本地词的量就少算了。

三个因素合起来，工具给出的数字通常明显低于实际。所以在这两个市场做机会评估时，别拿绝对值下结论，看相对排序更靠谱。

相对排序也有前提：同一批词用同一个工具、同一个时间窗口拉，跨工具比较在这两个市场的误差比别处更大。

## 为什么这里是二选一的框架，不是分层框架？

因为这一对市场的距离关系是对称的，只有两个点。

如果是三个以上的市场，而且两两之间的距离不相等，那就不能问要不要分开做，得改问每一类资产的共用边界落在哪一层。

北欧三语那一篇用的就是资产分层的框架 (https://zhangwenbao.com/nordic-seo-swedish-norwegian-danish-content-sharing-boundary.html)，因为瑞典挪威丹麦三者的两两距离明显不等。

印尼与马来只有两个点，距离只有一个值，二选一加三档判据就够用了。

框架选错的代价是实实在在的：拿分层框架套两个市场，会把简单的问题做复杂；拿二选一套三个市场，会漏掉最关键的那条不对称。

还有一个识别方法：数一下市场的数量，再问两两之间的距离是不是差不多。两个市场只有一个距离值，必然对称。

三个市场有三个距离值，只要其中有一个明显小于另外两个，分层框架就成立了，二分框架会漏掉那条不对称。

## 新加坡和文莱算不算第三第四个市场？

从语言资产的角度，不算。

新加坡的马来语与马来西亚的差别很小，而且马来语在新加坡的搜索份额远小于英语和中文，撑不起一套独立的内容资产。

文莱的情况类似，人口盘子太小。

所以这两个市场的正确做法是复用马来西亚那一套，只在货币、配送、法务条款这几个非语言字段上做区分。

这正是判断要不要新增一层资产的标准：不看有没有这个国家，看它能不能撑起一套独立维护的内容。

实际操作上，这两个市场更值得投入的是配送时效、税费说明和支付方式，这些跟语言无关但直接决定转化。

把本该花在第四套内容上的钱挪到这几处，回报率高得多。资产层数不是越多越显得专业。

要提醒一句：不做独立资产不等于不做本地化检查，法务条款和消费者保护条款该按当地写还是得按当地写。

## 两国的域名策略该怎么定？

两国都有各自的国别顶级域，都有二级结构，注册规则和资质要求不同。

做本地市场，用本地国别域名的信任加成是实打实的，尤其在建材、家电这类需要售后的品类。

但域名结构属于架构层的决策，跟语言层是两件事。国际化SEO那一篇讲了域名结构与语言标注怎么落地 (https://zhangwenbao.com/international-seo-hreflang-complete-guide.html)，这里不重复。

语言层要提醒的只有一条：域名和内容语言必须对得上，别出现马来西亚域名下挂着印尼语文案的情况。

这种错配用户一眼能看出来，而且看出来之后信任就没了。

如果预算只够一个本地域名，优先给盘子更大或者竞争更松的那一边，另一边先用子目录跑数据。

这是个可以分阶段的决策，不必一次到位。域名换起来麻烦，但从子目录升级到独立域名是有成熟路径的。

## 语言标注该写哪一个代码？

印尼语和马来语有各自独立的语言代码，不是同一门语言的两个地区变体。

这一点很多人搞错，会给马来西亚站标一个印尼语加地区的组合，那是错的。

语言标签的规范文档里定义了主语言子标签与地区子标签的组合规则 (https://www.rfc-editor.org/rfc/rfc5646)，两门语言各有各的主标签。

标错的直接后果是浏览器和搜索引擎对语言的判断出错，间接后果是断词、拼写检查、语音合成全跟着错。

这是个五分钟能改完、错了却要付出很久代价的字段。

还有一个连带的细节：页面上如果有语言切换器，切换项的名称要用目标语言自己的说法写，不要用英文写。

这一条看着是文案问题，实际影响的是用户能不能一眼找到自己那一项。两门语言的自称写法是不一样的。

## 商品标题的自动拼接会踩什么坑？

踩在词序和量词上。

这两门语言的修饰语位置跟英语相反，形容词在名词后面。你的标题模板如果是从英文站抄的，拼出来的顺序全是拧的。

更细一点的问题是量词。数量词和名词之间需要一个分类词，用哪一个取决于物体的形状和类别。

模板里写死一个通用分类词，大多数情况能读，遇到特定品类就会显得外行。

建材类尤其明显——板材、管材、颗粒状物料，各有各的习惯说法。

还有一处是所属关系的表达。这两门语言里表示某某的某某，语序和连接词跟中文英文都不同，模板里写反了会很别扭。

解法是别用通用模板拼长标题，按品类各写几套，让母语者过一遍。品类数量有限，这个活是一次性的。

## 价格和数字格式两国一样吗？

不一样，而且差得不小。

两国的货币符号、币值量级、小数位习惯都不同。印尼盾的数字位数长，价格显示要考虑折行和截断。

千位分隔符和小数点的用法两边也有差异，照搬会让价格看起来少一个数量级或者多一个数量级。

这类错误的严重程度取决于方向：显示得比实际便宜，客服要挨骂；显示得比实际贵，转化直接归零。

把价格格式化单独抽成一个按市场配置的模块，别散落在模板里。

还有一个跟价格挂钩的坑：优惠的表述方式。折扣用百分比还是用减多少钱，两边的习惯不完全一致。

这属于文案层面的问题，但它出现在最影响转化的位置上，值得单独拉出来跟本地运营确认一次。

## 日期和节庆两边能共用一套排期吗？

不能。

两国的公共假日不完全重合，重合的那些日期也不一样。跟着伊斯兰历走的节庆每年在公历上移动，两国的判定还可能差一天。

促销排期直接跟着假日走，排错了就是整场活动打空。

更麻烦的是这类节庆的日期不能提前很久固定下来，得按年确认。把它写死在代码里的团队，第二年一定出事。

正确做法是维护一张按市场按年的节庆表，运营和技术共用同一份。

还有一层是营业节奏的差异。促销活动的起止时间、客服的响应窗口，都要按当地的作息来排。

照着自己习惯的时区和作息排活动，最直接的表现就是活动开场的那几个小时没有流量。

## 马来语的另一套书写系统还需要考虑吗？

这是马来西亚一侧独有的东西，印尼没有。

马来语历史上曾用一套阿拉伯字母改造的文字书写，今天在部分官方场合、宗教场景和一些州的路牌上仍然能见到。

对绝大多数电商站来说，这一套不需要做——网络搜索几乎全部使用拉丁字母。

但如果你的品类涉及宗教用品、传统服饰、清真认证相关，那么在品牌名和认证标识上遇到它的概率不低。

知道它存在就够了，不必投入。这条写出来是为了让你在遇到时不至于当成乱码处理掉。

真要用到的时候要注意一点：它是从右往左书写的，跟拉丁字母混排会带来一整套布局问题。

这类问题在其他从右往左的语言里已经有成熟解法，需要的时候去找那套经验，不必从头摸索。

## 清真认证的相关表述该怎么写？

这是两国都绕不开、但认证体系不互通的一块。

两国各有各的认证机构和标识，标准细节和适用范围不完全一致。在商品页上写认证信息，必须写清楚是哪一国的认证。

笼统地写一句本品已认证，在两个市场都不够用，还可能引来合规问题。

从搜索的角度，认证相关的查询量在食品、日化、化妆品这几个品类里相当可观，属于必须覆盖的意图。

建材类看似无关，但涉及施工现场用的粘合剂、密封材料时，也会有人问。

写法上有个细节：认证标识是图片，图片里的文字不会被检索到，所以文字版的认证说明必须另外写一遍。

这既是给搜索引擎看的，也是给用不了图片的场景看的。一句话的事，很多站漏了。

## 地址表单两国能共用一个结构吗？

不能，两国的行政层级和邮编规则都不同。

印尼的层级更多，从省一路到村一级，邮编五位；马来西亚层级较少，邮编也是五位但编码规则不同。

把印尼的表单直接搬到马来西亚，用户会看到几个填不了的字段，或者被迫在错误的层级里找自己的地址。

物流侧的影响更直接：地址结构对不上，运费计算和时效承诺都会错。

这类字段属于第三档，必须分开做，没有商量余地。

实现上建议把地址结构做成按市场加载的配置，而不是在一个大表单里用条件判断藏字段。

条件判断的方案在字段少的时候没问题，市场一多就变成没人敢改的一团。配置化的成本前期高一点，后面省很多。

## 两个市场的移动端行为差别大吗？

差别体现在网络条件和页面预算上，不体现在语言上。

但它会反过来影响语言层的决策：网络条件更受限的一侧，页面上能承载的文字量更少，标题和摘要要写得更短更直接。

这时候两边的元描述不但词不同，长度策略也该不同。

我见过团队把两边的元描述都按同一个字符上限来写，结果一边刚好，一边在结果页上被截掉一半。

元描述本来就在第三档里，顺手把长度策略也分开定，成本几乎为零。

还有一个跟语言相关的点：网络条件差的一侧，用户更依赖搜索结果页上的信息做判断，不太愿意点进来再看。

这意味着标题和描述要承担更多的信息量，把关键参数直接写进去，比留悬念更有效。

## 内链的锚文本要不要两边分别写？

要，而且这是最容易被忽略的一块。

锚文本用的是品类词和属性词，而这两类词正是两个市场分叉最厉害的地方。

很多站把内链规则做成全站统一的模板，扫到某个词就自动加链接。这套规则如果只写了一份，另一个市场的页面上会大面积漏链。

更糟的情况是词表里那个词在另一边是假朋友，于是链接加上了，但锚的意思是错的。

内链词表跟关键词表一样，得按市场各存一份。

维护上有个省事的做法：把两份词表放在同一张表的两列里，改的时候同时看得见，不容易改了一边忘了另一边。

分成两个文件维护的团队，半年后两份表的结构都会长歪，合都合不回去。

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

语言字段、货币字段、地区可用性字段，这三个必须分开。

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

数值型的字段——尺寸、重量、型号、编码——可以共用，这是第一档里最干净的一部分。

评价和问答类的标记要注意来源：印尼站的用户评价不能标到马来西亚站的商品上，哪怕是同一个商品。

这既是准确性问题，也是合规问题，两边的消费者保护规则不完全一致。

还有一条：如果两个站的商品指向的是同一个实体，标识类的字段可以共用，这有助于把两边的信息关联起来。

但要注意可用性和价格必须各写各的，否则会出现一个市场展示了另一个市场的价格，这类错误的投诉率极高。

## 本地词典该怎么用才不白查？

用法上有个技巧：查词的时候同时看例句，别只看释义。

释义能告诉你这个词是什么意思，例句才能告诉你这个词在什么场合用、跟哪些词搭配。

电商文案要的是后者。一个释义完全正确但只用在正式书面语里的词，写进按钮文案就是灾难。

马来西亚官方词库的查询结果会同时给出多部词典的释义与用例，可以横向比较。

印尼那边的在线词典同样按词根组织，查一个带前缀的词时要先想清楚它的词根是什么，否则查不到。

还有一个反向用法：拿你已经写好的文案，抽出里面的关键词逐个反查，看释义跟你想表达的是不是一回事。

这一步经常能捞出翻译时选错的词。写的时候觉得对，查完才发现这个词在当地专指另一种东西。

## 母语审校该分别找哪一边的人？

各找各的，不能让一个人审两边。

这两门语言的母语者互相能读懂，但对另一边的用词直觉是不准的。让印尼审校去看马来西亚的文案，他会觉得都对，因为他确实看得懂。

能看懂和写得地道，中间隔着的正是你要花钱买的那部分。

审校清单也要分开写：印尼那边重点查非正式缩写和口语自然度，马来西亚那边重点查英文混用的比例是否符合当地习惯。

两份清单只有三成重合，剩下七成各管各的。

预算紧张时可以这样折中：第三档的内容两边各找人审，第二档的词表找一个人做初筛、另一边的人只复核标记项。

这样能省下三到四成的审校成本，风险主要落在第二档，而第二档出错的后果比第三档轻。

## 验收的时候看哪几个指标？

我一般看四个。

第一，两边的高频词表交集里，假朋友是否已全部标记并处理。第二，属性值字典是否逐条过完。

第三，两边的元描述和标题是否确实是分别写的，而不是一份改几个词。第四，站内搜索的零结果率，这个数字能反映词干还原有没有做到位。

第四条最容易被跳过，但它是唯一一个能量化的指标。

零结果率在这两门语言上偏高，八成是前缀形态没展开，去查一下补全索引就知道了。

再加一个可选项：抽十个核心词，分别在两个市场搜一下，看排在前面的页面用的是哪个词。

如果对手用的词跟你的不一样，而且不止一个页面如此，那多半是你选错了，不是他们错了。

这四个指标最好做成上线前的检查单，谁签字谁负责。口头确认过的事，三个月后没人记得。

## 什么情况下可以真的只做一套？

有，而且比很多人以为的更常见。

如果你的品类高度专业、买家是行业内的采购、术语基本沿用英文，那么两边的分叉会小很多，做一套加少量替换就够。

B2B的工业耗材、专业仪器、部分建材品类都属于这一类。

判断方法是抽二十个核心词，看两边的实际叫法有几个不同。差三个以内可以合并，差八个以上必须分开。

中间那一段就是要花时间想清楚的地带，别拿一句差不多蒙过去。

还有一种情况是新市场试水期。预算有限、还没验证需求的时候，先用一套加替换跑三个月，拿到数据再决定要不要拆。

这是合理的分阶段决策，前提是心里清楚现在这套是过渡方案，而不是自我说服说这样就够了。

还有一个信号值得留意：如果你的客服记录里几乎没有因为用词看不懂而来的咨询，说明分叉确实不严重。

## 引擎那半边的事，这里交出去

两国用哪个搜索引擎、本地平台怎么分流量、投放侧怎么配比，这些属于引擎层，不在语言层的讨论范围。

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

本篇只回答一件事：印尼语和马来语这一对语言本身，给内容资产的划分带来了哪些别的语言对没有的约束。

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

按这条标准，借词分叉、前缀同化、假朋友、重叠式复数全部合格；两国的物流成本差异就不合格，那是另一篇的事。

这样划分还有个好处：读者知道要找引擎侧的打法该去哪一篇，不用在一篇文章里翻半天找不到重点。

把边界说清楚，本身就是一种交付质量。

## 近亲语言的通用判据能不能再抽象一层？

能，抽出来是三个问题。

第一，两边的书写系统是否被统一过？统一过，第一档的可复用面就大。

第二，两边的日常高频词是否来自不同的外部语言？来自不同源头，第三档的重写量就大。

捷克语与斯洛伐克语那一对是历史断点造成的分离 (https://zhangwenbao.com/czech-slovak-seo-content-reuse-decision.html)，印尼与马来是殖民遗产造成的分离，成因不同，但落到判据上是同一个问法。

第三，有没有一侧独有的规则或字母？有，就得单独列一节，不能靠共性内容覆盖过去。

这三问的顺序不能颠倒。先问书写系统，再问词汇来源，最后问独有规则，是按可复用面从大到小排的。

照这个顺序问一遍，一门没做过的近亲语言对，半小时就能得出一个够用的资源分配方案。

## 常见问题解答

## 印尼语和马来语的内容到底能不能共用一套？

分三档看。商品图、尺寸表、参数数值、结构化数据里的数字字段可以整块照搬；商品属性名、筛选器标签、行业术语只换词不动结构；标题、元描述、正文、促销文案、客服话术必须重写。判断某个品类偏向哪一档，可以抽二十个核心词看两边实际叫法差几个，差三个以内可以合并，差八个以上必须分开，中间地带需要逐条讨论。三档的成本比大概是一比三比十，第三档虽然只占内容量的三成，却要吃掉一大半预算，所以别在第一档上纠结太久。

## 1972年那次拼写改革既然统一了，为什么还要做两套？

因为改革统一的是怎么写，不是写的是哪个词。印尼在独立前是荷兰殖民地，马来亚是英国的，三百多年里两边从各自宗主国借进了大量日常词，办公室、账户、药店、发票这类天天要用的词两边完全不同。正字法可以靠一纸公文统一，词汇不行。结果就是越正式的书面语越像，越日常的口语越不像，而电商关键词绝大多数落在日常这一端。建材、汽配这类行业发展路径不同的品类分叉最严重，同一种五金件两国的行业内叫法可能一个来自荷兰语一个来自英语，字面上毫无关系。

## 前缀吃掉词干首字母这件事，具体会造成什么损失？

会让同一个概念在你的数据里裂成好几份：动词形态、名词形态、被动形态本来指向同一个词根，还原不到位就成了三个互不相干的词，搜索量被分摊、竞争度算不准、内链锚文本聚不到一起、站内搜索匹配不上。解法是用现成的词干算法而不是自己砍前缀，但要注意针对印尼语的规则不能无差别套用到马来语上，两边有出入。自查方法是拉一份站内搜索的高频查询，看同一个词根的不同形态是不是各自独立出现在榜单上，是的话说明还原没做到位。

## 假朋友清单要怎么建才不漏？

从自己站点的高频词表出发，两边各拉一份取交集，这批是两边都在用的词。把交集里每个词分别丢进两国的权威词典查释义，看例句而不是只看释义，对不上的标为嫌疑词交母语者确认。一个中等规模的电商站通常能筛出二三十个真假朋友，数量不多但每一个都在关键位置上，其中至少有一个会是从正常词变成粗俗词的那种。清单建好之后要进流程而不是存在共享盘里，最好的位置是内容管理系统的校验环节，写作时命中就弹提示，否则新来的文案根本不知道有这东西。

## 既然没有词形变体，是不是这两门语言比欧洲语言好做？

工作量确实小一块，但省下的预算不该真的省掉。名词不变格、动词不变时态、形容词不跟着改性数，这确实把欧洲语言里最烧钱的词形覆盖整块拿掉了，可换来的是词汇分叉的核对工作。正确做法是把这笔钱挪到假朋友核对、口语查询采集、品类词实际叫法调研这三件事上，三项加起来还不到给一门屈折语做词形覆盖的一半。这个误判有个很具体的表现：团队会把排期压得很短，然后在上线前一周发现假朋友没核、口语词没采、品类词叫法不对，只能带着问题上线。

## 新加坡和文莱要不要单独做一套？

不用。新加坡的马来语与马来西亚差别很小，而且马来语在当地的搜索份额远小于英语和中文，撑不起一套独立维护的内容资产；文莱的人口盘子太小。正确做法是复用马来西亚那一套，只在货币、配送、法务条款这几个非语言字段上做区分。判断要不要新增一层资产的标准不是有没有这个国家，是它能不能撑起一套独立维护的内容。把本该花在第四套内容上的钱挪到配送时效、税费说明和支付方式上，回报率高得多，资产层数不是越多越显得专业。

## 两边的语言标注代码该怎么写？

印尼语和马来语有各自独立的主语言子标签，不是同一门语言的两个地区变体，给马来西亚站标一个印尼语加地区的组合是错的。标错的直接后果是浏览器和搜索引擎对语言的判断出错，间接后果是断词、拼写检查、语音合成全跟着错。这是个五分钟能改完、错了却要付出很久代价的字段，上线前值得单独核一遍。还有一个连带细节：语言切换器的选项名称要用目标语言自己的说法写，不要用英文写，这两门语言的自称写法是不一样的。

## 权威参考资料



## 泰语SEO的标题里找不到一个空格，切在哪儿由引擎的词典说了算

- URL：https://zhangwenbao.com/thai-seo-no-spaces-word-segmentation-keyword.html
- 分类：小语种SEO
- 发布：2014-03-05  |  更新：2026-07-25
- 摘要：讲泰语SEO实战：无空格文本的词典分词怎么切、关键词横跨切点为何静默丢流量、标题与品牌名的可切分写法、前置元音导致的排序重排、零宽字符对匹配的破坏、佛历年份与三级行政区划的处理。
- 关键词：关键词研究,SEO,小语种SEO

> **TLDR**：摘要：泰语句子里不放空格，词的边界不写在页面上，由引擎手里那本词典临时判定。这篇讲词典分词怎么切、切错会丢哪一类流量、标题怎么排才切得开，以及前置元音让排序倒着比、零宽字符污染关键词表、佛历年份把校验算成负数这些没人提的坑。

> 摘要：泰语句子里不放空格，词的边界不写在页面上，由引擎手里那本词典临时判定。这篇讲词典分词怎么切、切错会丢哪一类流量、标题怎么排才切得开，以及前置元音让排序倒着比、零宽字符污染关键词表、佛历年份把校验算成负数这些没人提的坑。

去年有个做厨房小家电的团队找我看泰语站。他们的数据很奇怪。

收录正常，抓取没有报错，页面加载速度比英文站还快。可是主推的那条空气炸锅产品线，上线三个月，核心词的展示量几乎是零。

我把标题复制出来，扔进一个泰语分词器跑了一遍。切出来的结果里，他们那个自己造的复合品类词，被拦腰切成了三段，每一段单独看都是别的意思。

问题不在技术，也不在内容质量。问题在于泰语这门语言不把词的边界写在页面上，而团队默认它写了。

这是欧洲语言训练出来的人做泰语时最容易掉进去的坑：你以为空格是标配，其实它是一个可选项，而泰语没选。

## 泰语的句子里为什么一个空格都没有？

第一次拿到泰语商品标题的人，通常会盯着屏幕看好一会儿。

整行字母连成一条，从头到尾找不到一处断点。这不是排版坏了，泰语的正字法本来就不用空格分词。

一句话写完，才可能出现一个空格。词与词之间，什么都没有。

这件事对做SEO的人意味着一个很不舒服的事实：你在页面上没有办法告诉搜索引擎，我这个关键词是从这里到这里。

词的边界不在你手上，它在引擎那本分词词典里。你能做的只有一件事——让你想要的那个词，恰好是词典切得出来的那一段。

换个角度说，泰语把分词这件事外包给了读者的大脑。母语者读到一串字符，会凭语感自动断句，这个过程快到他们自己都意识不到。

机器没有这份语感，只有一本词典和一个概率模型。你的关键词能不能被认出来，取决于它在这本词典里是不是一个条目。

## 泰语的空格到底在什么时候用？

泰语不是完全不用空格，只是用法跟英语完全不重叠。

它大致出现在四个位置：句子结束的地方、并列成分之间、数字与单位之间、外来语和专名的前后。

可以粗略理解成，泰语的空格干的是英语里句号和逗号的活，不干分词的活。

这条规则带来一个很直接的后果。你要是按英语习惯在词与词之间插空格，泰国读者读起来的感觉，接近于中文写成“厨 房 电 器 促 销”。

可读性掉一大截，而且不会给你换来任何分词上的好处。引擎该怎么切，还是怎么切。

还有一类空格是排版性的，出现在长句中间用来喘口气，位置比较随意，不同的编辑习惯不一样。

这类随意空格对分词是有影响的，因为它会在文本里造出一个硬边界。你从供应商那儿拿来的商品描述如果带着这种空格，同一个品类词在不同商品上可能被切成不同的形态。

## 搜索引擎切不开词，会发生什么？

切不开的表现不是报错，是安静地少了一批流量。

引擎把一长串泰文按自己的词典切成若干段。你的目标词如果横跨两段之间，这个页面在这个词上就基本不参与竞争了。

没有任何工具会提示你这件事。收录正常、索引正常、抓取正常，只有排名不正常。

前面那个厨房小家电的团队，后来把标题里那个自造复合写法拆成两个词典里都有的常用词，两周内展示量才开始有数字。

页面一个字没多写，只是切开了。这是那种改动量最小、效果最直接的修法，前提是你得先知道要改哪儿。

还有一种更难查的表现：词被切开了，但切法跟你想的不一样，页面反而在一批你从没打算做的词上有了展示。

这类流量看着是白捡的，实际上意图完全不对，跳出率高得吓人，还会拉低整个目录的平均表现。碰到这种情况别急着高兴，先去核一下切分结果。

## 词典分词到底是怎么工作的？

主流做法是最大匹配加统计打分。

程序从句首开始，尽量往后找词典里存在的最长的那一段，找不到就退回来换更短的。碰到几种切法都合法的位置，再用一个概率模型挑一种最像自然语言的。

这一路的泰语开源实现里，最经典的是libthai提供的泰语分词与断行支持库 (https://linux.thai.net/projects/libthai)，另一支是命令行工具SWATH。

两者的词典规模、未登录词处理策略都不一样，切出来的结果因此也不完全一致。

记住这一点：分词不是一个有标准答案的操作，是一次基于词典的猜测。词典不同，猜测就不同。

未登录词是另一个变量。词典里没有的字符串，程序只能拆成已知的短词硬拼，拼出来的东西经常荒诞。

所以做泰语站有一条很实用的原则：凡是你自己造的词，无论听起来多顺，都要假设引擎不认识它，然后想办法在页面上给它一个已知词构成的解释。

## 泰语分词的歧义最容易出在哪里？

出在短音节堆叠的地方。

泰语有大量两到三个字符的单音节词。几个连在一起时，程序既可以把它们当成一个复合词，也可以拆成三个独立词，两种切法在词典里都说得通。

商品名尤其危险。品类词加材质词加规格词连写在一起，中间那一刀落在哪儿，全看词典里哪种组合被收录过。

你的运营同事觉得写得紧凑专业，引擎看到的可能是三个毫不相干的碎片。

更麻烦的是，这种切错不会稳定复现。同一串字符放在不同的上下文里，统计模型给出的最优切法可能不一样。

另一个高发区是数字和单位的接缝处。泰语里数字通常用阿拉伯数字写，单位用泰文写，两者中间加不加空格，各家写法不一。

不加空格时，单位词有可能跟后面的词粘成一个新词；加了空格，规格这个信息又和商品名断开了。我一般选择加空格，宁可让规格独立，也不要制造一个不存在的词。

## 标题该怎么写才切得开？

有一条很朴素的判据。

标题里出现的每一个你想拿排名的词，都必须是泰语里独立成立、词典里查得到的常用词。

自造复合词、把两个品类硬拼在一起、把英文品牌名直接嵌进泰文中间不做分隔，这三种写法风险最高。

操作上更稳的做法是，在两个语义单元之间用泰语允许空格的位置断一下——品类与规格之间、正文与外来语之间都可以。

这既符合泰语的书写习惯，又给了引擎一个明确的硬边界。等于你替它做了一半的活。

还有一条容易被忽略的：标题里同一个概念不要连着出现两次不同的写法。泰语没有大小写做区分，两种写法挨在一起，分词器很容易把它们黏成一个长串。

真要给两种写法都留位置，让它们分别落在标题和描述里，中间隔开，比挤在一行安全得多。

## 品牌名在泰语正文里会被切成什么？

如果品牌是拉丁字母写的，它天然带着两侧的空格，切分不出问题。

麻烦的是做了泰文音译的品牌名。音译结果往往不在任何词典里，属于未登录词，程序只能按最大匹配硬拆。

拆出来的碎片有时会撞上真实存在的普通词，于是品牌名被切成两个含义完全不搭的东西。

我见过一个音译品牌名被切完之后，前半段是一个日常用的动词，后半段是一种鱼。整个品牌在引擎眼里就消失了。

稳妥的做法是泰文音译和拉丁原名同时出现一次，让两套写法都有机会被抓到，也顺手教育了用户这两个是同一个东西。

判断方法很简单：把你的泰文品牌名单独丢进分词器，看它输出的是一段还是几段。输出一段就没事，输出两段以上就要处理。

处理办法除了双写，还可以在品牌名两侧各留一个空格。泰语允许专名前后加空格，这既符合正字法，又给了分词器一对明确的括号。

## 泰语没有大小写也没有句号，标题还怎么做层次？

英语标题靠首字母大写和标点做视觉分层，泰语这两样都没有。

它没有大小写的概念。句子结束也不写句号，只留一个空格。

所以泰语标题的层次感，只能靠空格的疏密，以及竖线、破折号这类引入的符号来做。

顺带说一句，这也让全大写这种在欧洲语言里常见的强调手法在泰语里彻底失效。

想强调只能换词、加符号，或者靠前端样式。别指望字形本身能帮忙——泰语的字形从头到尾只有一种。

这也解释了为什么泰语的搜索结果页看起来比英语拥挤——每条标题都是一整块，没有大小写的起伏帮眼睛找落点。

实用的补偿手段是在标题里放一个符号做锚，比如竖线或者中点，让用户的视线有个停靠的地方。符号别用太多，一条标题一个就够。

## 复合词该连写还是拆开写？

泰语的复合词有一批已经固化进词典，连写是标准写法；另一批还处在半固化状态，连写拆写都能见到。

判断方法不复杂：去泰语的权威词典或者主流媒体的正文里查一下，能查到连写形态的就连写，查不到的一律拆。

拆写还有个附带好处。

拆开之后，构成这个复合概念的每个成分词都变成了独立的可匹配单元，页面能接住的长尾组合反而更多。

连写是把鸡蛋全放进一个篮子，拆写是分开放。在一门没有空格的语言里，多留几个可匹配的落点，比追求书面上的紧凑划算。

有个折中的做法值得一试：标题里拆写，正文里两种形态各出现一次。这样既保住了标题的可切分性，又让固化写法有机会被抓到。

要注意的是别在同一句话里紧挨着写两种形态，读起来像结巴，泰国读者对这个很敏感。

## 泰语的关键词研究该从哪一步开始？

不是从工具开始，是从分词器开始。

拿到一批候选词之后，第一件事是把它们丢进泰语分词器跑一遍，看看每个候选词在切分之后还是不是一个完整的单元。

切完还完整的，才有资格进入下一轮评估；切碎了的，直接淘汰或者换写法。

这一步在欧洲语言的流程里是不存在的，因为空格已经替你做完了。

泰语必须把它补上。否则你后面所有的搜索量数据、竞争度评估，评估的都是一个引擎眼里并不存在的字符串。

第二步才是量的评估。这时候你手里的候选词已经都是分词器认可的完整单元，拿到的搜索量数据才有意义。

第三步是把这批词按能不能自然写进泰语句子里再筛一轮。有些词在词典里成立，但书面上极少用，写进正文会很生硬，这种词做了也接不住转化。

## 泰语的没有空格，跟韩语的分写法不是一回事

韩语是有空格的。

它的问题出在空格该落在哪儿这件事上规则复杂、母语者自己也常写错，加上助词还会粘在词节后面变形。

所以韩语要处理的是空格数量对但位置错，重点在覆盖各种错写变体和剥离助词。

泰语根本没有这一层。它不存在写错空格的问题，因为压根没有空格可写。

韩语分写法与助词那一套打法 (https://zhangwenbao.com/korean-seo-spacing-particles-keyword-research.html)在泰语上一条都用不上，反过来也一样。这两门语言经常被放在同一张东亚清单里，实际上一个字都不通用。

两者唯一相通的地方在验收环节：都必须让母语者读一遍，都不能只靠工具下结论。

但要验收的东西不同。韩语验的是空格位置和助词形态，泰语验的是这一串字符能不能被切成你想要的那几个词。

## 泰语的没有空格，跟越南语的按音节分写更不是一回事

越南语看起来空格很多，多到有点欺骗性。

它的空格切的是音节而不是词。一个双音节词会被空格拆成两段，结果是空格比真实的词还多。

做越南语要干的活，是把被拆开的音节重新合并成词。

泰语的方向正好相反：空格远远少于词，要干的活是把粘在一起的词切开。

越南语那边的音节分写与声调双轨问题 (https://zhangwenbao.com/vietnamese-seo-tone-marks-syllable-spacing-keyword.html)和泰语这边是两道相反的题，一个做加法一个做减法。同在东南亚、同是声调语言，在这一维上却是两端。

这个差别在关键词工具上表现得最明显。越南语的词表里全是带空格的多词短语，泰语的词表里全是不带空格的长串。

两边的去重逻辑、模糊匹配阈值、甚至表格列宽都得分开设。拿同一套模板处理这两个市场，第一天就会乱。

## 泰语的没有空格，跟芬兰语的复合词粘连也不是一回事

芬兰语有空格，但它的复合词会把好几个概念粘成一个超长单词，这个词顶得上英语的一整个词组。

所以芬兰语的空格数量少于语义单元数，需要复合词分解器把长词拆开。

听上去跟泰语很像，其实差别很大。

芬兰语粘连的边界发生在词的内部，是构词法层面的，词与词之间的空格照旧存在。芬兰语那种词干自己还会变形的麻烦 (https://zhangwenbao.com/finnish-seo-fifteen-cases-consonant-gradation-keyword.html)更是泰语完全没有的——泰语的词根本不变形。

泰语缺的是词与词之间那一层分隔。缺的层次不同，补的办法自然也不同。

还有一个实际差别：芬兰语的长词是可以被拆解还原的，因为构词有规律；泰语的长串没有规律可循，只能靠词典比对。

所以芬兰语可以写规则，泰语只能查表。这决定了两边的工程投入完全不同——一个是算法问题，一个是数据问题。

## 这四种空格错位，能推出一条通用判据吗？

能。先问一句：这门语言里空格的数量，跟语义单元的数量是什么关系？

越南语是多于，芬兰语是少于，韩语是相等但位置有争议，泰语是几乎为零。

答完这一问，你就知道该往哪个方向补功课了。多于就合并，少于就分解，位置错就做变体覆盖，为零就得先建边界。

这条判据比按语系分类有用得多。

泰语和越南语都在东南亚、都是声调语言，在这一维上却是完全相反的两端；芬兰语和泰语一个在北欧一个在东南亚，八竿子打不着，在这一维上反而离得更近。

这个问法还有个好处：它能帮你判断一个新市场要不要单独立项。同一类错位的语言可以共用一套工具链和验收清单，不同类的必须分开。

拿到一门没做过的语言，先花十分钟回答这一问，比读三篇泛泛的本地化指南有用。

## URL里能不能直接写泰文？

技术上可以，泰文会被百分号编码。

但一个泰文字符编码之后要占九个字符的位置。一段十个字的泰文标题，进URL就是九十个字符起步。

复制粘贴到聊天软件里，就是一长串谁也看不懂的编码。

更麻烦的是泰语没有词边界，转成URL之后也没有连字符可放，得到的是一整条毫无停顿的编码串。

所以泰语站的URL，我一般建议走拉丁转写或者干脆用英文。路径可读性上的那点损失，比不上编码串带来的麻烦。

有一种折中方案是路径用拉丁转写，同时把泰文标题完整放进页面的标题标签和描述里。搜索结果上用户看到的仍然是泰文，链接却是干净的。

这套做法在其他非拉丁字母市场也成立，泰语只是因为没有连字符可放，收益比别处更明显。

## 泰文域名后缀值不值得注册？

泰文的国别顶级域早已进了根区。

IANA根区数据库里能查到泰文后缀的委派记录 (https://www.iana.org/domains/root/db/xn--o3cw4h.html)，实际写进浏览器的是它的Punycode形式。注册和解析都没有问题。

值不值得是另一回事。

泰国用户的键盘切换成本、跨平台的显示一致性、以及从社交媒体复制链接时的还原率，这三项决定了它更适合当品牌保护性注册，不适合当主站入口。

这个判断跟其他非拉丁字母市场是一致的。本地字符域名的价值在防守，不在获客。

如果一定要用，记得把两种形式都在服务器上配好跳转，并且统一到一个规范形态上，别让同一个页面在两套域名下都能打开。

这一步漏了，等于给自己造了一份完整的重复内容，而且是跨域的那种，处理起来比站内重复麻烦得多。

## 泰文的换行会把词从中间劈开吗？

会，而且这是泰语网页上最常见的排版事故。

浏览器的默认换行策略在没有空格的文本里无处下刀。早期的处理是碰到容器边界直接切，切在词中间是家常便饭。

正确的解法是让排版引擎知道泰语的断行也要查词典。Unicode的换行算法规范把泰语这类语言单列为需要词典辅助的情况，现代浏览器在样式层给了对应的控制手段。

这件事影响的是可读性和跳出率，不直接影响收录。

但它值得修——一个词被劈成两半，读者要多花半秒钟才能拼回去，而移动端一屏里可能出现七八次。

判断有没有这个问题很快：把浏览器窗口拉窄到手机宽度，找一段长泰文，看看断行的位置是不是落在合理的地方。

落在音节中间就说明排版引擎没走词典路径。这时候前端要么显式指定语言，要么在样式层换一种断行策略。

## 泰文的组合字符会让字符串长度算错吗？

会，而且错得很隐蔽。

泰文的元音符号和声调符号是独立码位，会叠加在辅音的上方或下方。一个视觉上只有一格宽的音节，在程序看来可能是三个字符。

后果是所有按字符数做的限制全部失真：标题字数校验、摘要截断、数据库字段长度、后台的字数统计。

按字符数截断还会把声调符号从它依附的辅音上切下来，渲染出一个孤零零的浮空记号。

凡是要截断泰文的地方，都得按字素簇来算，不能按码位。这条规则同样适用于所有带组合记号的书写系统，泰语只是踩得最狠的一个。

一个快速的自查方法：拿一段泰文，用你系统里的长度函数量一遍，再让母语者数一遍视觉上的音节数，两个数字差得越远，问题越大。

差三成以内还能忍，差一倍以上说明所有跟长度相关的逻辑都要重写。

## 标题在搜索结果里被截断，泰语为什么更容易出事？

因为搜索结果的标题截断是按像素宽度算的，而泰文的字符平均宽度比拉丁字母窄，同样的像素能塞下更多字符。

听起来是好事，但泰文的行高需求比拉丁字母高，上下两层记号都要地方。

更要紧的是没有空格这一点又回来了。

英文标题被截断，最多断在一个单词的边界上；泰文标题被截断，大概率断在某个音节中间，尾巴上留一个残缺的字符。

写泰语标题时，把最重要的信息塞进前半段，比在英语里更要紧。后半段能不能活下来，你说了不算。

还有一个连带影响：截断位置不可预测，意味着你没法靠数字符来控制标题长度，只能靠实际渲染去看。

我的做法是把候选标题渲染成图，按目标设备的宽度截一刀，直接看断在哪儿。比在表格里数字符可靠得多。

## 泰文的排序规则为什么要倒着比？

这是泰语最反直觉的一处，也是极少有人提的。

泰语有五个前置元音，它们写在辅音的左边，读的时候却在辅音之后。书写顺序和读音顺序在这五个元音上是颠倒的。

排序算法必须把这个顺序倒回来再比较，否则所有以前置元音开头的词都会排到错误的位置。

Unicode排序规范里专门处理了泰语这种前置元音重排的情形 (https://www.unicode.org/reports/tr35/tr35-collation.html)，规则写得很细。

你自己写的那个按码位比较的排序函数，在泰语上一定是错的。品牌列表、品类导航、字母索引，只要按字母序排，全都会错。

这个问题的隐蔽之处在于，错误的排序看上去也是一种排序。列表整整齐齐，只是顺序对泰国用户来说毫无道理。

验收方法是找母语者看一眼品牌首字母索引，他会立刻指出哪几个位置不对。这种错误肉眼可辨，前提是那双眼睛得是泰国人的。

## 为什么站内搜索在泰语上会完全失灵？

因为大多数站内搜索的默认实现是按空格切词的。

泰语文本进去，切出来只有一个巨大的字符串。用户输入任何一个词都匹配不上，或者退化成全文的模糊匹配，返回一堆不相关的东西。

解决办法是在索引阶段接一个泰语分词器，把文本切成词再建索引。

这件事在英语站上不需要做，所以很容易被整个跳过。

直到某天有人发现，泰语站的站内搜索转化率只有其他语言站的零头，而站内搜索通常是全站转化率最高的入口之一。

接分词器之后还要处理一件事：查询词也得走同一套切分，否则索引侧切好了，查询侧还是整串，照样匹配不上。

索引和查询用不同的切分策略，是这类改造里最常见的半吊子做法，改完看着接了分词器，效果一点没变。

## 筛选器和面包屑在泰语里怎么写才不粘连？

筛选器的标签往往是一个个短词，前端拼接时习惯用逗号或者斜杠连接。

在泰语里这些符号可以保留，但符号两侧要不要留空格，得统一。混着来的话，同一个筛选值在不同页面上会有两种形态。

面包屑更要小心。

层级之间的分隔符如果贴着泰文写，视觉上会和泰文字符粘成一片；两侧都留空格，又可能被解析成泰语的句子分隔。

我的做法是分隔符两侧统一留一个空格，并在结构化数据里另外给一份不含分隔符的干净名称。展示归展示，数据归数据，两边不要混。

还有一个细节：筛选值里如果混着英文和泰文，两种文字之间要不要留空格也得定死。

泰语的正字法允许在外来语两侧加空格，所以我倾向于留。但要全站统一，不能这页留那页不留，否则同一个筛选值会分裂成两个。

## 图片文件名和替代文本，用泰文还是拉丁转写？

文件名用拉丁转写，替代文本用泰文。

理由跟URL那条一样：文件名进了路径就要被编码，泰文文件名在服务器迁移、打包下载、CDN回源这几个环节都容易出问题。

替代文本则相反。它是给用户和图片检索用的，必须是泰文，而且要写成一句自然的泰语描述，不要堆关键词。

泰语的图片搜索在本地市场的使用率不低，这块的流量比很多人以为的值钱。

还有一条容易漏：替代文本里的泰文同样要过一遍分词器，确认关键的品类词没被写成一个切不开的怪串。

转写方案本身也要统一。泰语转拉丁有好几套体系，不同的转写规则会把同一个词写成不同的样子。

选定一套之后写进规范文档，让所有人照着执行。半年后回头看，你会庆幸当初花了这十分钟。

## 泰语的自动补全为什么给不出建议？

站内的自动补全通常是按前缀匹配的。

泰语用户在输入框里打了三个字符，这三个字符可能只是某个词的前半个音节，前缀匹配当然找不到东西。

等他打完整个词，补全也就没意义了。

可用的做法是把候选词表先用分词器切好，按词而不是按整串建前缀索引，同时允许从词的中间开始匹配。

这会让候选集变大，需要配一层打分来控制噪声。但比给不出建议强——补全给不出东西，用户就会直接放弃搜索。

还有一个提升手段是把历史查询日志接进来。真实用户打过的字符串，哪怕不是完整的词，也是有效的补全起点。

这套数据在泰语上格外值钱，因为它绕过了分词这一层，直接反映了用户真实的输入行为。

## 表单验证会误伤哪些泰文输入？

最常见的是姓名字段。

泰国人的名字通常很长，加上前缀敬称之后超过很多系统的默认字符上限，而这个上限往往是按拉丁字母的经验设的。用户被迫截断名字，订单信息就跟证件对不上了。

第二常见的是不允许特殊字符这类正则。泰文的声调符号和元音符号在一些粗糙的正则里会被当成非字母字符拦下来。

第三是搜索框的最小长度限制。泰语一个有意义的词可能只有两个字符，设成三个字符起搜，就把它挡在外面了。

这三条都不是泰语独有的问题，但泰语是最容易同时踩满的那一个。

第四条是密码强度校验。有些实现要求必须包含大写字母，泰国用户如果用泰文当密码的一部分，永远满足不了这个条件。

这类规则在设计时都默认了拉丁字母的世界观。做泰语站时把所有校验规则拉出来过一遍，通常能找出三四条这样的。

## 泰国用户实际打进搜索框的是什么？

是很口语的短句，而且经常不写完整。

泰语的疑问词、语气词在口语里用得极频繁。这些词会大量出现在真实查询里，却几乎不会出现在你的商品文案里。

这两套语料的差距，是泰语站长尾流量的主要缺口。

补的办法是把这些口语说法收进常见问题区和商品描述的自然句子里。不是塞关键词，是真的用泰国人说话的方式写一段。

这件事必须交给母语者。翻译出来的泰语在这个维度上永远是假的——它语法全对，但没有一个泰国人会这么说话。

还有一个特征是查询里经常带着场景词，比如放在哪个房间用、给谁买、什么时候用。这类修饰在英语查询里出现得少得多。

把这些场景词织进商品描述的自然句子里，能接住一大批中长尾。前提是你得先知道泰国人是按场景而不是按参数在找东西。

## 泰式英语混写在关键词里占多大比重？

比想象中大。

泰国的城市用户在打字时会大量混用英文，尤其是品类词、品牌词、技术参数。一个查询里前半段泰文后半段英文是很常见的形态，反过来也有。

这带来一个实际的排布问题。

你的页面上必须同时有泰文和英文两种写法，而且要挨得足够近，让引擎能把它们关联起来。

全泰文的页面会漏掉混写查询，全英文的页面在本地市场没有竞争力。两边都得有，而且不能靠一个孤零零的英文标签硬凑。

混写还有一层要注意：英文部分的拼写经常是简写或者本地习惯写法，跟标准英文不一样。

照搬国际站的英文术语，可能一条都对不上。这块最好从本地的客服记录和站内搜索日志里捞，捞出来的才是真的。

## 泰语的数字要用泰数字还是阿拉伯数字？

泰语有自己的一套数字符号，但在商业场景里几乎已经不用了。

价格、规格、日期，泰国人日常看到的都是阿拉伯数字。泰数字现在主要出现在正式公文、寺庙题字、纪念性场合。

所以商品页一律用阿拉伯数字，这一点没有争议。

但你的搜索和筛选逻辑最好能同时接受泰数字输入，成本很低。遇到从公文场景复制过来的输入时能救一次。

顺带一提，泰数字和阿拉伯数字在排序时也要归一化，否则同一批数据会分成两堆各排各的。

价格的千位分隔和小数点也要按泰国习惯来，跟大多数西方市场一致，但跟一些东南亚邻国不同。

这类细节单看无关紧要，凑在一起决定了页面读起来像不像本地做的。用户说不出哪儿别扭，但他会走。

## 泰国的日期和佛历年份该怎么处理？

这条是泰语本地化里最容易翻车的地方，而且翻车之后不容易被发现。

泰国官方使用佛历，佛历年份比公历大五百四十三年。同一个年份，在泰国的政府网站、发票、身份证件上写的是四位数的佛历年。

如果你的日期本地化库按泰语区域设置渲染年份，它可能会自动转成佛历，页面上就出现一个比今年大五百多的年份。

反过来，如果用户按佛历填写生日，你的年龄校验会算出一个负数，然后拒绝这笔订单。

两个方向都要显式指定用哪套历法，不要依赖库的默认行为。这是那种测试环境永远发现不了、上线第一天就爆的问题。

还有一个衍生场景：促销活动的倒计时和有效期。如果后端存的是公历，前端按泰语区域渲染成佛历，用户看到的截止日期就在五百多年后。

这种页面用户不会来投诉，他只会觉得这个站不太靠谱然后关掉。属于典型的静默流失。

## 泰语的敬语层级会影响转化吗？

会影响转化，不影响排名。

泰语的礼貌语尾分男女，句末那个词男性说和女性说是不一样的。品牌文案该用哪一个，取决于品牌人格设定，不是随便挑。

更常见的问题是通篇不用礼貌语尾。

机器翻译出来的泰语几乎都是这样，读起来像命令句，泰国用户会觉得这个牌子很没礼貌。

在按钮文案和客服自动回复上尤其明显。一句立即购买不带礼貌语尾，语气大概相当于中文的“买”字后面跟一个感叹号。

还有一处常被忽略：错误提示的语气。表单填错时弹出的那句话如果是命令句，用户的挫败感会明显放大。

把错误提示改成带礼貌语尾的说法，成本几乎为零，对表单完成率的影响却能量出来。

## 泰国的三级行政区划表单怎么设计？

泰国的地址是府、县、区三级，加上邮编共四个字段。

这三级之间有严格的从属关系，不能让用户自由填写，得做成联动下拉。曼谷的行政区划名称和外府还不一样，是另一套叫法。

邮编是五位数字，前两位对应府。

可以做成填邮编自动带出前两级，能显著减少填错。

这类字段的正确性直接影响物流成本，属于那种做好了没人夸、做错了每单都亏钱的活。泰国的偏远配送加价规则又跟府一级绑定，填错一次就是真金白银。

还有一件事：行政区划的名称会变。合并、改名、新设都发生过，你的对照表如果是三年前拉的，现在一定有对不上的。

解决办法是把这张表当成需要定期更新的数据，而不是写死在代码里的常量。写死的那一刻，它就开始过期了。

## 泰语的声调符号会不会被用户漏打？

不会，这一点跟越南语正好相反。

越南语的声调符号在键盘上要额外按键，所以有大量用户干脆不打；泰语的声调符号在泰文键盘上是独立按键，打字时跟辅音元音一样是必须按的，漏掉就拼不出这个词。

所以泰语不需要做带调不带调的双轨覆盖。

这一块预算可以整个省掉，挪到分词验证上去。

同样是东南亚的声调语言，两门语言在这件事上的结论完全相反。谁要是拿越南语的经验直接套泰语，会白花一笔钱去覆盖一批根本不存在的查询变体。

要注意的是泰语有另一类输入变体：某些元音符号在不同输入法下的码位顺序可能不同，视觉上一模一样，字节上不一样。

这个问题的形态跟越南语的编码统一有点像，但成因完全不同，一个是输入法差异，一个是正字法本身有两套。处理手段是入库前统一做一次规范化。

## 零宽字符正在污染你的泰语关键词表

这是泰语网页上一个非常隐蔽的问题，我很少见到有人提。

因为浏览器的泰语断行支持长期不完善，泰国的前端开发者形成了一个习惯：在词与词之间手工插入零宽空格，给浏览器一个可以断行的提示。

零宽空格是不可见字符，但它实实在在存在于文本里。

它会破坏引擎的分词、破坏你的关键词匹配、让两个看起来一模一样的字符串比较结果为假。从泰语页面复制文本进关键词表时，这些字符会跟着进来。

做泰语站的第一件事，是在所有数据入口处把零宽字符清掉。商品导入、内容发布、关键词表导入，三处各加一道。

还有一个隐蔽的来源：从设计稿或者办公文档里复制文案。这些工具为了排版也会插入不可见字符，而且种类比零宽空格更多。

我的习惯是所有从外部进来的泰文，先过一遍字符白名单，不在名单里的一律剔除。宁可误删一个奇怪的符号，也不要放一个隐形字符进关键词表。

## 泰文的字体行高会把上下两层记号压掉吗？

会。

泰文的一个音节最多可以有四层：基线上的辅音、下方的元音、上方的元音、再上方的声调符号。

行高设得跟拉丁字母一样，最上面那层声调符号就会被裁掉，或者跟上一行的下标元音撞在一起。

经验值是泰文的行高要比同字号的拉丁字母多给两成到三成。

这件事不影响任何SEO指标，但影响的是用户能不能看清那个决定词义的声调符号——泰语的声调一变词义就变，看不清等于看错。

字体选择上也有讲究。不是所有支持泰文的字体都把四层记号处理得一样好，有些在小字号下会把上标挤成一坨。

定字体之前，用最小的正文字号渲染一段带满记号的泰文看看。这一步只要五分钟，能避开一整年的可读性投诉。

## 分词器版本不同，切法就不同吗？

是的，而且这件事会让你的监控数据出现无法解释的波动。

词典是会更新的。新词收进去之后，原来被切成两段的字符串可能突然变成了一个词，反过来也有。

实际影响是：你自己用来做关键词校验的那个分词器，和搜索引擎线上用的那一套，词典大概率不同步。

所以本地跑出来的切分结果只能当参考，不能当判决。

真正的判决只有一个——去搜那个词，看看你的页面在不在结果里。这句话听着像废话，但在泰语上它是唯一可靠的验收手段。

实际操作上可以留一份切分基线：把核心词表的切分结果存下来，每次升级分词器之后重跑一遍做对比。

差异清单出来之后，只看那几条变了的，比每次全量重验省事得多。这也是发现词典更新的最快信号。

## 泰语内容的长度该按什么算？

不能按字符数算，也不能按词数算——你都数不出有多少个词。

相对可靠的做法是按音节数，或者干脆按渲染出来的视觉行数估。

更实用的一条是别拿英文站的字数标准往泰语上套。

泰语表达同一个意思，字符数通常比英语少，因为一个音节就是一个信息单元，不需要那么多字母。

硬凑字数只会逼出一堆废话，泰国读者一眼就能看出来这是翻译腔。按信息点的数量定长度，比按字符数定靠谱得多。

还有一个反向的问题：泰语写太短也不行。信息点不够，页面在竞争激烈的品类词上撑不住。

判断够不够的方法不是数字数，是把页面上回答了的问题列出来，跟排在前面的几个页面比一比。少了哪几个，补哪几个。

## 泰文编码的历史遗留还会影响你吗？

还会，主要出现在跟本地供应商对接数据的时候。

泰语在统一编码普及之前用的是一套单字节编码，至今还登记在国际的字符集注册表里。老系统导出的商品表格很可能还是这个编码。

转码不彻底的典型症状是：泰文能显示，但声调符号全丢了，或者位置错乱。

这种数据进了商品库，页面看着有内容，实际上每个词都是错的，而且错得很像正常文本，肉眼扫过去不一定能发现。

导入前先抽查十条丢给母语者看，比上线后回滚省事得多。

除了商品数据，另一个高发区是历史内容迁移。老站的数据库如果是那套单字节编码存的，导出时不指定编码就会全乱。

迁移前先在测试库上跑一遍，抽几条带声调符号的记录对照原页面看。声调符号是最好的检测器，它一错就全错。

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

泰国市场的搜索格局、本地平台的流量分配、投放侧的打法，这些属于引擎层，不在语言层的讨论范围里。

多语言站的目录结构、语言标注该怎么落地，同样是架构问题。国际化SEO与hreflang那一篇 (https://zhangwenbao.com/international-seo-hreflang-complete-guide.html)已经写完了，这里不再展开。

本篇只回答一件事：泰语这门语言本身，给关键词研究和页面撰写带来了哪些别的语言没有的约束。

判据很简单——把语种换成英语就不成立的，才是这里该写的。

按这个标准，前面那些关于词典、前置元音、零宽字符、佛历的段落全部合格，而“泰国人爱用手机”这种话就不合格，它在任何市场都成立。

把边界划清楚也是一种交付质量。读者知道这篇管什么、不管什么，才知道剩下那半边该去哪儿找。

这比在一篇文章里什么都提一句、什么都不讲透要有用。

## 泰语的母语审校该验收哪几件事？

验收清单我一般给五条。

第一，把标题和主要关键词丢进分词器，确认每个目标词都是独立单元。第二，检查零宽字符是否已清干净。

第三，确认礼貌语尾的使用一致且符合品牌人格。第四，抽查日期和年份有没有被转成佛历。第五，让母语者念一遍按钮和表单提示，听着别扭的全部重写。

这五条里只有第三和第五需要母语者，前两条是脚本能跑的，第四条是测试用例能覆盖的。

把能自动化的先自动化掉，母语者的时间要花在机器判断不了的地方。母语审校的单价不低，让他们去数零宽字符是最贵的一种浪费。

再补一条流程上的建议：审校要在内容定稿之后、上线之前做，不要放在上线之后当作优化项。

泰语的这些坑一旦上线，改起来牵扯的是URL、结构化数据、外部引用一整串。前置一天的成本，抵得上后面一周的返工。

## 常见问题解答

## 泰语站的标题里到底能不能加空格？

能，但要加在泰语允许的位置上，也就是语义单元之间、外来语两侧、数字与单位之间，不能加在一个词的内部。加对了位置，等于给引擎一个明确的硬边界，比让它自己猜要可靠；加错了位置，泰国读者读起来会很别扭，而且不会带来任何分词收益。判断标准是找母语者读一遍，读着卡壳的地方就是加错了。另外要提醒的是，加空格不等于可以随便加：同一批商品的标题必须用同一种断法，否则同一个品类词在不同页面上会呈现出不同的切分形态，站内的聚合和去重都会跟着乱。

## 我用本地分词器验过的关键词，为什么线上还是排不上？

因为你手里那个分词器的词典和搜索引擎线上用的不是同一份。词典会更新，收录范围也不一样，本地切得开不代表线上切得开。本地验证的价值在于筛掉明显有问题的候选词，把自造复合词和未登录串挡在提纲之外，最终判决只能靠实际去搜、看页面在不在结果里。别把本地结果当成保证，它只是一道成本极低的初筛。还有一种可能是词切对了，但这个词本身在泰语里太冷僻，真实搜索量几乎为零。分词器只管切得开不开，管不了有没有人搜，这两件事要分开验。

## 泰语需不需要像越南语那样做带调和不带调两套？

不需要。越南语的声调符号在键盘上要额外操作，所以有大量用户不打；泰语的声调符号是泰文键盘上的独立按键，属于必按项，漏了就拼不出词。这块预算在泰语上可以整个省掉，挪到分词验证和口语化长尾上更划算。同为东南亚的声调语言，这两门语言在这件事上的结论是相反的，拿一边的经验套另一边会白花钱。真正需要在泰语上做变体覆盖的，是外来语的泰文音译写法。同一个英文词经常有两三种通行的音译形态，这一块才是泰语的变体重灾区。

## 零宽字符到底怎么检测和清理？

检测靠正则扫描不可见字符的码位，清理放在数据入口处，也就是商品导入、内容发布、关键词表导入这三个环节各加一道。要注意的是不能无差别删除所有不可见字符，泰文本身的元音和声调符号是有宽度的正常字符，别误伤。写一条只针对零宽字符的规则，跑一遍全站文本，通常能扫出一批，尤其是从本地供应商那儿拿来的商品描述。清理之后最好加一道监控，定期扫全站泰文页面，一旦又出现就报警。这类字符是随着人和流程进来的，清一次不能一劳永逸。

## 泰文URL和拉丁转写URL，哪个更好？

拉丁转写。泰文进URL之后每个字符要占九个字符位置，而且泰语没有空格也就没有连字符可放，得到的是一条不可读的编码串。分享链接时用户看到的是乱码，复制粘贴环节也更容易出问题。路径可读性上的那点损失，换来的是整条链路的省心。泰文域名后缀同理，适合做品牌保护性注册，不适合当主站入口。如果站点已经上线并且用了泰文路径，别急着全站改。先评估这批URL的现有权重和外部引用，分批迁移并做好跳转，比一次性推倒重来稳妥。

## 佛历年份这件事具体会在哪些地方出问题？

三个地方。一是日期本地化库按泰语区域设置自动转成佛历，页面上出现一个大五百多的年份；二是用户按佛历填生日，你的年龄校验算出负数并拒单；三是跟本地供应商对接的单据上写的是佛历年，导入时被当成公历，整批数据的时间轴全部偏移五百多年。三处都要显式指定用哪套历法，不要依赖库的默认行为。还有第四处：结构化数据里的日期字段。那里必须是公历的标准格式，被本地化库改成佛历的话，整段标记会被判为无效。

## 泰语内容的字数标准该怎么定？

别从英文站的标准换算过来。泰语的一个音节就是一个信息单元，表达同样的意思字符数通常更少，按英文字数硬凑只会凑出翻译腔的废话。比较实用的做法是按信息点数量定：这个页面要回答几个问题、给出几组参数、覆盖几种使用场景，把这些数清楚，长度自然就合理了。真要量化，按音节数或者渲染行数估，比按字符数靠谱。有一条经验值可以参考：泰语页面的信息点密度要比英语高一些，因为泰语读者对铺陈式的过渡句容忍度更低，废话一多他们翻页比谁都快。

## 权威参考资料



## 匈牙利语SEO难住人的不是变音符号，也不是词序，是一个名词能接出十八种格尾

- URL：https://zhangwenbao.com/hungarian-seo-eighteen-cases-vowel-harmony-keyword.html
- 分类：小语种SEO
- 发布：2013-07-23  |  更新：2026-07-26
- 摘要：匈牙利语SEO实战：十八个格加两维元音和谐，定冠词还决定动词用哪套词尾。给出与土耳其语、芬兰语的三方差异表，以及选词表结构、多字母字母排序与表单格式的处理办法。
- 关键词：关键词研究,SEO,小语种SEO

> **TLDR**：摘要：匈牙利语被夹在一圈印欧语中间，自己却不属于印欧语系。很多团队顺手把它归到土耳其语那一类，理由是两门都叫黏着语，结果后缀链长度、元音和谐的维度、动词跟着冠词换词尾这三件事全部估错。这篇先给出它跟土耳其语、芬兰语的三方差异表，再往下拆十八个格里真正要覆盖的是哪几个、字母索引为什么会排乱、姓名与日期格式该改哪几处。

> 摘要：匈牙利语被夹在一圈印欧语中间，自己却不属于印欧语系。很多团队顺手把它归到土耳其语那一类，理由是两门都叫黏着语，结果后缀链长度、元音和谐的维度、动词跟着冠词换词尾这三件事全部估错。这篇先给出它跟土耳其语、芬兰语的三方差异表，再往下拆十八个格里真正要覆盖的是哪几个、字母索引为什么会排乱、姓名与日期格式该改哪几处。

## 匈牙利语在欧洲腹地是个什么样的存在？

打开地图看一眼，匈牙利被斯洛伐克、乌克兰、罗马尼亚、塞尔维亚、克罗地亚、斯洛文尼亚、奥地利围了一圈。

这七个邻国说的全是印欧语系的语言，斯拉夫语族、罗曼语族、日耳曼语族凑齐了三家。

匈牙利语一家都不沾。它属于乌拉尔语系，最近的亲戚在两千公里外的芬兰和爱沙尼亚，而且这个亲戚也远得听不懂彼此说话。

这个位置带来一个很实际的后果：你在邻国市场攒下的语言侧经验，到了匈牙利几乎全部作废。

词汇不通、语法不通、连语序的默认预期都不一样，能复用的只剩下货币格式和物流那些非语言字段。

我接过一个做箱包的站，团队在波兰和罗马尼亚都跑顺了，到匈牙利第一版关键词表被本地同事退回来重做，理由是一半的词形根本不会出现在真实查询里。

语言孤立还带来一个副作用：匈牙利语的对外借词比例低于周边任何一门语言，很多国际通行的技术词在这里都有一个自造的本地词，而用户搜的往往就是那个本地词。

所以做匈牙利市场时，最先要建的其实不是关键词表，是一张国际词与本地词的对照表，这张表建不好后面所有工作都建在沙子上。

## 它跟土耳其语同为黏着语，为什么不能照搬？

黏着语这个标签只说明一件事：语法信息靠往词尾接后缀来表达，而不是靠改词根或者加介词。

这个共性是真的，但共性之外的差别足以让两套处理方案完全不通用。

土耳其语的选词方法我在土耳其语那篇 (https://zhangwenbao.com/turkish-seo-agglutinative-suffix-stacking-keyword.html)里按后缀链拆过一遍，那套方法的核心是算链的长度。

匈牙利语的链要短得多，格尾几乎总是挂在最外层，真正的麻烦不在链长，在于格的数量和元音和谐的维度。

维度 | 土耳其语 | 匈牙利语 | 

语系 | 突厥语族 | 乌拉尔语系乌戈尔语支 | 

格的数量 | 六个 | 通行教学语法列十八个 | 

后缀链 | 能挂五层，链长是主要难点 | 链较短，格尾几乎总在最外层 | 

定冠词 | 没有定冠词 | 有，而且它决定动词用哪套词尾 | 

词干变化 | 元音省略、辅音清浊交替 | 词干末元音延长、消失元音 | 

字母表 | 基本拉丁加六个特殊字母 | 含八个多字母字母，各算一个字母 | 

表里最后两行是实际工程量差别最大的地方，字母表那一行直接决定了排序和索引要不要重写。

还有一个容易被忽略的差别：土耳其语的后缀几乎全是加在词尾的，而匈牙利语在动词那一侧有可分离前缀，处理逻辑要多考虑一个方向。

## 跟芬兰语才是一家，但差别在哪？

匈牙利语和芬兰语同属乌拉尔语系，这层亲缘关系比跟土耳其语的关系近得多。

但两门语言分家的时间早到什么程度呢，早到今天的匈牙利人和芬兰人互相听不懂一个词。

芬兰语的十五个格与词干交替，我在芬兰语那篇 (https://zhangwenbao.com/finnish-seo-fifteen-cases-consonant-gradation-keyword.html)里讲过它为什么是欧洲最难做关键词研究的语言之一。

维度 | 芬兰语 | 匈牙利语 | 

格的数量 | 十五个 | 十八个 | 

词干怎么变 | 辅音级差，词干里的辅音会换 | 没有级差，但末元音会延长、词干里的元音会消失 | 

元音和谐 | 前后一维 | 前后加圆唇两维 | 

冠词 | 没有 | 有定冠词和不定冠词 | 

复合词 | 粘连很长，没有长度上的硬规则 | 粘连但受音节数规则约束，超过阈值要加连字符 | 

做过芬兰语再做匈牙利语，最容易犯的错是以为词干稳定，于是只处理词尾。

匈牙利语的词干确实不像芬兰语那样辅音成级交替，但它有另外两条自己的变法，后面会单独拆。

另外一条实用的判断：芬兰语的高频格分布比较分散，选词表要铺得宽；匈牙利语的高频格相对集中，可以铺得窄而深，预算分配的方式不一样。

## 十八个格到底是哪十八个，做SEO要关心几个？

十八这个数字本身就有争议，不同语法体系数出来的结果从十七到二十七都有。

争议的点在于某些后缀到底算格尾还是算已经固化的后置词，这属于语言学内部的划界问题。

做搜索这一侧不需要卷进这个争论，你需要的是另一个数字：真正会出现在查询里的格有几个。

答案通常是四到六个，其余十来个格要么只出现在完整句子里，要么语义太具体，用户不会拿它搜商品。

把有限的力气放在这几个格上，比背下全部十八个的词尾有用得多。

这也是匈牙利语跟芬兰语的一个实操差别：芬兰语的高频格更分散，匈牙利语相对集中。

顺带说一句，格的数量本身也是个营销话术，网上不少介绍匈牙利语难度的文章会把数字往大了说，实际做起来要处理的形态数量远没有那么吓人。

## 哪几个格会真的出现在搜索框里？

主格是词典形，商品列表页和分类名用它，这个没有悬念。

宾格要在词尾加一个t，出现在带动词的查询里，比如想买什么、在哪买什么这类句式。

位置类的三个格最值得关注：表示在里面的、表示到里面去的、表示从里面出来的，它们对应的是场景类查询。

还有一个表示为了什么用途的格，在挑选类查询里出现频率很高。

剩下的比如表示变成什么、表示作为什么身份，商品查询里基本见不到。

选词表就按这五六个格铺，每个核心词五六行，一个品类三五十个核心词，表的规模是可控的。

确认高频格最可靠的办法还是看站内搜索日志，把查询按词尾归类统计一遍，通常前五个格就能覆盖八成以上的查询量。

## 元音和谐是两维的，后缀该选哪个变体？

元音和谐的意思是后缀里的元音要跟着词根里的元音走，不能随便配。

匈牙利语的第一维是前后：词根里是前元音，后缀就用前元音的变体；是后元音，就用后元音的变体。

第二维是圆唇：某些后缀在前元音这一侧还要再分圆唇和不圆唇，于是同一个后缀有三种形态。

结果是同一个语法意义的后缀，在不同的词后面长得完全不一样，机械替换必错。

土耳其语也有这两维，但它的后缀普遍是二型或四型，规则更整齐一些。

匈牙利语的不整齐在于：哪些后缀是二型、哪些是三型，得逐个记，没有一条能覆盖全部的规则。

还有一类混合词根会让和谐规则失效：外来词和某些复合词的前后两半分属不同的元音类别，这时候按哪一半走要逐词确认，没有通用规则。

## 圆唇和谐这一维为什么工具经常算错？

通用的多语言处理库在实现元音和谐时，大多只做了前后这一维。

原因很实际：前后这一维覆盖了大部分情况，做完就能交差，圆唇那一维的收益不明显。

但对搜索来说，算错的那部分恰恰集中在高频词上，因为高频词里前元音词根的占比不低。

检验办法很简单：拿十个已知的前元音词根，让工具生成带某个三型后缀的形态，看它是不是全部只给了一种。

只给一种就说明圆唇那一维没实现，这时候要么换库，要么自己补一张例外表。

例外表通常两三百行就够，覆盖你品类里的核心词，比换整套技术栈现实。

补例外表的时候顺手记录每个词的元音类别，这一列后面在生成变体、配同义词、写标题模板时都会反复用到，一次录入长期收益。

## 什么是低元音词干，为什么规则推不出来？

正常情况下，后元音词根接复数后缀时用的元音是一种，接完读起来顺。

但有一批词偏偏要用另一个更开口的元音，语法书管这类叫低元音词干。

房子这个词就是典型：按常规规则推出来应该是一种形态，实际的复数用的是另一个元音。

这类词没有形式上的标记，你看着这个词根本判断不出它属不属于这一类。

唯一的办法是查词典逐个确认，然后把结果存进属性字典的一个布尔字段里。

匈牙利语的这个坑跟罗马尼亚语那篇 (https://zhangwenbao.com/romanian-seo-postposed-definite-article-comma-diacritics.html)里的中性名词是同一类问题：规则给你百分之八十，剩下百分之二十只能靠数据。

这类词在日常高频词里的占比其实不低，房子、道路、桥这类基础名词很多都在名单上，所以品类词表里撞上的概率比想象中大。

## 消失元音词干会怎么把词根切坏？

另一类词干变化更麻烦：词干里倒数第二个位置上的元音，在接后缀时会整个消失。

灌木这个词的复数就是这样，词根中间那个元音在复数形态里没有了。

后果是词根本身的字符串变了，不再是原形的一个前缀。

这一下把前缀匹配、自动补全、以及所有假设词根稳定的逻辑全部打穿。

处理办法只有一条：把这类词的所有形态都写进索引，别指望算法能还原。

好消息是这类词的数量有限，通常在两三百个量级，其中跟你品类相关的可能只有十几个。

识别这类词有个粗糙的线索：词干倒数第二个音节的元音如果是短的、且这个词是两音节的，那它属于这一类的概率明显偏高，可以拿来做初筛。

## 定冠词决定动词用哪套词尾，这条印欧语里没有

这是匈牙利语最反直觉的一条，也是同类文章几乎不会提的一条。

匈牙利语的及物动词有两套人称词尾：一套用在宾语是确定的时候，一套用在宾语不确定的时候。

说我买一个包和我买那个包，这两句里的动词形态是不同的，变的不是宾语而是动词。

换句话说，定冠词的出现会往回改动词的词尾，这个联动在印欧语里完全没有对应物。

做搜索时的直接影响是：同一个意图的问句型查询，会以两种不同的动词形态出现在日志里。

你如果只按其中一种形态铺内容，另一半查询就接不住，而且从中文一侧完全看不出这里少了什么。

再补一层：不是所有确定性都靠定冠词表达，专有名词、带领属后缀的名词、指示代词修饰的名词，天然就是确定的，动词照样要走确定那一套。

## 问句型查询里会同时出现哪两种动词形态？

拿箱包站最常见的一类查询举例：想知道在哪儿买行李箱。

如果句子里说的是买行李箱这个泛指，动词走不确定那一套。

如果说的是买这个行李箱，动词走确定那一套，词尾不一样。

用户搜商品时两种都用，比例大致跟查询里带不带指示词有关。

内容侧的处理办法是在FAQ和正文里让两种句式都自然出现一次，不必刻意堆砌。

站内搜索这一侧则要在同义词表里把两种动词形态映射到一起，否则零结果率会莫名其妙地高。

做查询分类时可以把动词形态当成一个意图信号：走确定形态的查询往往指向具体某件商品，走不确定形态的更偏向品类浏览，两者该落到的页面类型不一样。

## 领属后缀叠加之后，一个词能长到什么程度？

匈牙利语表示所属关系不用介词，也不用单独的物主代词，靠往名词上接后缀。

我的包、你的包、他的包，变的都是那个名词的词尾。

领属后缀还能跟复数、跟格尾继续叠加，一个词接三层后缀是常事。

这些形态在搜索里出现得不算多，因为用户搜商品时很少说这是谁的。

但它们在评论、问答和用户生成内容里到处都是，做内容分析时得能识别出来。

比起土耳其语能挂五层的长链，匈牙利语这三层已经算克制的了。

领属后缀还有单复数之分，也就是说要区分是一个人拥有还是多个人拥有，这一层在客服话术和评价展示里出现得比在商品页多。

## 领属结构有两种写法，选词表要收哪一种？

表示甲的乙这种关系时，匈牙利语有两种句法结构。

一种是所属者不带任何标记，直接放在前面，被拥有物带领属后缀。

另一种是所属者带一个后缀，语义上更强调所属者本身。

商品名里的复合概念大多走第一种，比如旅行用的包、笔记本电脑的内胆包。

所以选词表只收第一种结构就够，第二种留给正文表达。

这个判断的依据是：第一种结构在书面语里更接近固定搭配，第二种更接近临时组合。

两种结构的检索表现也不同：第一种更容易被当成一个固定短语整体匹配，第二种在分词后会散成两个独立词，做短语匹配时要留意这个差别。

## 多字母字母是怎么回事？cs、gy、sz各算一个

匈牙利语字母表里有八个由两三个字符组成的字母：cs、dz、dzs、gy、ly、ny、sz、ty、zs。

它们不是两个字母的组合，而是各自独立的一个字母，在字母表里占独立位置。

这意味着sz排序时不排在s和t之间的某个位置，而是排在s全部词条之后。

dzs更极端，三个字符算一个字母，是匈牙利语字母表里最长的那个。

匈牙利科学院的字母排序工具 (https://helyesiras.mta.hu/helyesiras/default/akhsort)可以直接验证任意两个词的先后关系，配排序规则时拿它对答案最省事。

顺带说一句，土耳其语和芬兰语都没有这个特性，这是匈牙利语在字符处理上最独特的一条。

实际写代码时最稳的做法是维护一张多字母字母表并按最长匹配切分，先试三字符的dzs，再试两字符的，最后才落到单字符。

## 双写时为什么写成ccs而不是cscs？

当一个多字母字母需要双写时，匈牙利语的正字法规定只重复第一个字符。

所以是ccs而不是cscs，是ggy而不是gygy。

这条规则叫简化写法，写在匈牙利科学院的正字法规则 (https://helyesiras.mta.hu/helyesiras/default/akh11)里，当时通行的是第十一版。

做字符串处理时这条会带来一个陷阱：把ccs按字母切分，正确结果是一个cs的双写，不是c加cs。

切错的直接后果是排序位置错、断词位置错、以及词干化时切掉了不该切的部分。

写切分逻辑时要先做一次还原：把双写形态展开回两个完整的多字母字母，再往下处理。

这条简化规则在断词换行时会被还原：一个双写的多字母字母在行末断开时要写回完整形态，前端的断词逻辑如果没实现这一层，渲染出来的换行是错的。

## A-Z字母索引在匈牙利语站上会错在哪？

品牌墙、品类字母导航、城市列表这三类页面把排序结果直接印在页面上，错了一眼能看出来。

匈牙利语站上最典型的错误是把sz开头的品牌排到了s开头的品牌中间。

第二典型的是带变音的元音全部跑到了z之后，因为默认排序按字节码走。

第三种更隐蔽：字母导航的按钮只列了二十六个拉丁字母，多字母字母压根没有入口。

正确的按钮列表应该包含cs、gy、ny、sz、zs这些，用户才找得到对应的词条。

做到这一步的匈牙利语站不多，做到了就是一个能被本地用户明确感知到的细节。

还有一个细节值得做：字母导航的按钮上最好把多字母字母用不同的样式标出来，本地用户一眼就能认出这个站是按匈牙利语字母表排的。

## 排序规则该怎么配才不出错？

排序不能用默认的字节序，要用支持区域设置的排序规则并明确指定匈牙利语。

指定之后多字母字母和变音元音的位置会自动正确，不需要自己写比较函数。

LDML的排序规范 (https://www.unicode.org/reports/tr35/tr35-collation.html)里有匈牙利语的完整定义，包括多字母字母和双写形态的处理。

数据库层面也要跟着配，否则应用层排对了、数据库分页取出来的顺序又是错的。

这类前后端排序规则不一致的问题，表现出来是翻页时有的词条重复出现、有的消失。

排查这类问题的第一步永远是确认两侧用的是不是同一套排序规则。

配好之后写一个小测试用例，把几个s和sz开头的词、几个带变音的词打乱丢进去排一遍，升级依赖时跑一次就能发现规则有没有被改掉。

## 复合词要不要加连字符？六音节规则怎么用

匈牙利语和德语一样喜欢把词粘成复合词，但它多了一条长度上的硬规则。

规则大意是：由三个以上词根组成、且总音节数超过六个的复合词，要在合适的位置加连字符。

三个以下词根的复合词无论多长都不加，六音节以内的也不加。

德语复合词的处理办法我在德语那篇 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)里拆过，那边的问题是怎么切，这边多了一个要不要加符号的问题。

结果是同一个商品概念在页面上可能有加连字符和不加两种写法，取决于写的人有没有数音节。

科学院的断词工具 (https://helyesiras.mta.hu/helyesiras/default/hyph)能直接给出某个复合词的正确断法，写商品名时值得随手查一下。

这条规则还有一个例外分支：由两个词根组成但其中一个本身已经是复合词的情况，数法跟直觉不一样，遇到超长词最好还是查工具确认。

## 连字符加不加，会不会变成两个关键词？

会，而且这个影响比看起来大。

带连字符的形态和不带的形态，在大多数分词器眼里是不同的词串。

用户在搜索框里打字时基本不会打连字符，因为手机键盘上要多一步。

所以真实查询里不带连字符的形态占绝对多数，而你的商品标题按正字法写了连字符。

处理办法是标题按正字法写，同时在商品别名字段里存一份不带连字符的形态供站内搜索使用。

这个做法跟罗马尼亚语处理变音符号是同一个思路：给人看的地方守规范，给机器匹配的地方留变体。

另外提醒一句，连字符在不同输入法下打出来的字符未必是同一个，短横线、连接号、减号在码位上是三个不同的字符，入库前要统一。

## 变音符号有哪几个，缺哪个最要命？

匈牙利语的元音带变音的有七个：á、é、í、ó、ö、ő、ú、ü、ű。

其中ő和ű是双尖音符，表示长的ö和ü，这两个字符是匈牙利语最独特的标志。

它们在字体支持上是重灾区，很多字体只画了德语那套变音，这两个直接缺字形。

页面上缺字形的表现是显示成方框或者退化成没有符号的形态，两种都很难看。

选网页字体时一定要实测这两个字符，别看厂商标注的语言支持列表。

做封面图、做商品图上的文字、做视频字幕时同理，这两个字符是最先暴露字体问题的地方。

检查字体覆盖时别只看这两个小写字母，大写的对应形态同样要测，全大写标题和导航栏里用得上，而字体缺大写形态的情况一点都不罕见。

## 长短元音区分意义，打错一个符号会变成另一个词

匈牙利语里长元音和短元音是区别意义的，不是可有可无的装饰。

ö和ő是两个不同的音，换一个词的意思就变了，有些词对差别还挺尴尬。

这一点跟法语的重音符号不太一样，法语里很多重音符号丢了也不影响理解。

匈牙利语丢了长音符号，有一部分词会直接变成另一个存在的词，读者会真的读错。

所以正文一律要打全，这不是规范问题而是语义问题。

用户在搜索框里打不打是另一回事，那属于输入成本，两件事要分开处理。

这也解释了为什么匈牙利语的内容审校不能只交给拼写检查器：拼写检查器只判断这个词存不存在，判断不了你写的是不是你想写的那个词。

## 用户打不打长音符号？分场景看

桌面端配了匈牙利语键盘布局的用户，长音符号有独立按键，打起来没有额外成本。

移动端的匈牙利语输入法通常也把这几个字符放在长按菜单里，成本是多按一下。

所以匈牙利语的带变音比例比罗马尼亚语要高，这是键盘布局差异带来的。

但输入法的自动纠正会引入另一类噪音：它有时候会把用户打的短元音自动改成长的。

结果是日志里出现一批用户本来没打算搜的词形，做词频统计时要留意这类异常峰值。

判断办法是看这些词形的会话深度，纠错产生的查询通常伴随着立刻的二次搜索。

做日志分析时建议把输入法纠错产生的查询单独打标，它们的转化率通常明显偏低，混在一起统计会把整个品类的转化数据往下拉。

## 站内搜索该怎么折叠变音符号？

折叠的意思是把带变音和不带变音的形态映射到同一个索引项上。

匈牙利语要折叠的不只是有无变音，还包括长短：ö和ő要折到一起，ü和ű也是。

只折有无变音、不折长短，那用户打了短的却搜不到长的，覆盖还是不完整。

折叠只做在检索层，展示层一律用规范形态，这个分工不能混。

做完之后拿真实日志跑一遍回归，重点看零结果率有没有下降。

这一步在匈牙利语上的收益通常很明显，因为长短元音的组合数量比一般语言多一倍。

折叠规则要跟排序规则分开配，这两件事看着都跟变音符号有关，但目标相反：折叠是为了让不同形态命中同一条，排序是为了让它们各归各位。

## 词干化在匈牙利语上能做到什么程度？

Snowball的匈牙利语词干算法 (https://snowballstem.org/algorithms/hungarian/stemmer.html)处理了格尾、复数和常见的领属后缀，这是最容易接上的一层。

它处理不了的是词干本身的变化，也就是前面说的低元音词干和消失元音词干。

所以词干化的合理预期是：解决词尾那一半问题，词干那一半靠数据补。

补的方式是维护一张形态映射表，把不规则词的所有形态都指向同一个词根。

这张表跟同义词表可以合并管理，反正在检索层它们的作用是一样的。

规模上，一个电商品类通常一两百行就够用，别一上来就想覆盖整门语言。

还有一个容易忽略的地方：词干化会把某些短词切得只剩两三个字符，这类残根在匹配时会引入大量噪音，最好设一个最短词根长度的下限。

## Hunspell为什么是匈牙利人写出来的？

这件事说起来有点像因果报应：正因为匈牙利语的形态太复杂，才逼出了一个好用的拼写检查方案。

早期的拼写检查器靠穷举词表工作，对匈牙利语这种一个词能派生出几千个形态的语言完全不适用。

于是有人把词根和词缀规则拆开存，用规则去生成和校验形态，这就是Hunspell的词缀压缩思路 (https://github.com/hunspell/hunspell)。

这个方案后来被大量浏览器和办公软件采用，成了开源世界里事实上的拼写检查标准。

对做SEO的人来说，这段历史的实用价值在于：Hunspell的匈牙利语词典文件本身就是一份现成的形态规则库。

它比任何二手教程都完整，而且是机器可读的，直接拿来生成形态变体比手工整理快得多。

从这个词典文件里能直接读出哪些词根属于低元音词干、哪些属于消失元音词干，因为这些信息本来就要编码进词缀规则里才能生成正确形态。

## 姓名顺序是姓在前，表单和结构化数据要改哪几处？

匈牙利语是欧洲唯一一门日常把姓写在名前面的语言。

这个顺序跟中文一致，跟所有邻国相反，本地人对写反了相当敏感。

要改的地方有四处：注册表单的字段顺序、订单确认页的姓名展示、邮件称呼、以及结构化数据里的姓名字段。

结构化数据那一处最容易漏，因为姓和名是分成两个字段填的，顺序错了机器读出来就是错的。

客服话术也要跟着调，用姓加先生女士的组合称呼，别照搬英文的名加姓。

这一条不影响排名，但它是本地用户判断一个站是不是认真做本地化的第一个信号。

还有一个细节：匈牙利语的女性婚后姓氏有几种传统写法，注册表单如果强制拆成姓和名两个字段，有一部分用户会填不进去，字段设计要留出余地。

## 日期格式为什么末尾还有一个点？

匈牙利语的日期是年月日顺序，这一点跟中文一样，跟大多数欧洲国家相反。

更特别的是每一段后面都有一个点，包括最后那个日期数字后面。

写成2013. 07. 23. 才是规范写法，末尾那个点不是打字错误。

原因在语法里：这个点标记的是序数词，日期在匈牙利语里读作第几日。

日历组件、发货时效、促销倒计时这些地方按默认格式渲染，出来的都是不地道的写法。

星期从周一开始，这一点跟大多数欧洲市场一致，不用额外调。

序数词后面加点这条规则不只用在日期上，排行榜、楼层、章节编号这些地方同样适用，页面上凡是出现第几的地方都该检查一遍。

## 地址与邮编字段该怎么排？

匈牙利地址的顺序是邮编、城市、街道、门牌，跟中文的从大到小一致。

邮编是四位数字，比很多欧洲国家短，表单校验的位数别照抄邻国。

门牌号写在街道名之后，这一点跟德语区一致，跟英语区相反。

街道类型的词是写在街道名后面的，比如某某街的街字在后面。

地址表单如果只提供一个自由文本框，用户会按本地习惯填，问题不大。

拆成结构化字段的时候才要小心，字段顺序和标签措辞都要按本地习惯排。

邮编四位这一条还有个衍生影响：如果你的地址库是从欧洲通用数据源导入的，很可能会被补成五位，导入时要专门校验位数。

## 数字、货币与小数点该怎么写？

货币是福林，代码HUF，日常写作Ft，符号写在数字后面。

福林的面额数字很大，日常商品价格动辄五位数，这会影响价格筛选器的区间设计。

小数点用逗号，千分位用空格而不是点，这一点跟不少欧洲国家不同。

而且福林在日常交易里基本不用小数，标价通常是整数。

把英文站的价格格式直接搬过来，会同时错在分隔符和小数位两个地方。

价格区间筛选器的默认档位也要按本地价位重设，照搬欧元区的档位会让所有商品挤在同一档。

千分位用空格这条要注意用哪种空格，普通空格会在换行时把数字拆成两半，正确做法是用不换行空格，否则价格显示会莫名其妙地断行。

## 后置词跟格是什么关系，关键词里算几个词？

十八个格之外，匈牙利语还有一大批后置词，语义上相当于其他语言的介词。

区别在于它们写成独立的词，放在名词后面，而格尾是粘在名词上的。

所以同一个语义关系，有的用格表达算一个词，有的用后置词表达算两个词。

做关键词长度统计和竞价词匹配时，这个差别会直接改变词的分组结果。

选词表建议把带后置词的短语单独列一类，别跟格形态混在一张表里。

它们的检索行为也不一样：后置词短语更接近自然语言问句，格形态更接近商品名。

后置词还有一个特点：它们大多要求前面的名词带某个特定的格，所以后置词短语其实是格加词的组合，统计词长时按两个词算但语义上是一个单元。

## 动词前缀会被拆开，长尾查询里怎么找？

匈牙利语的动词有一批可分离前缀，平时粘在动词前面，某些句式里会被拆到动词后面去。

拆开之后中间还能插进别的词，一个动词的两半可能隔着两三个词。

这对长尾查询的匹配是个不小的麻烦，因为字符串上看不出这两半是一个词。

问句型查询里这种拆分特别常见，尤其是带否定和带疑问词的句子。

处理办法是在做查询意图分类时把前缀单独识别出来，别当成独立的词处理。

德语的可分离动词有类似的现象，但匈牙利语的拆分频率更高，规则也更依赖语序。

内容侧可以主动利用这一点：把带前缀的完整形态和拆开的形态各写进一段自然的句子里，长尾覆盖会比只写一种明显宽一些。

## 标题模板在匈牙利语上要留几个变量？

商品标题一律用主格形态，这是最接近检索形态的写法。

形容词在匈牙利语里放在名词前面，而且做定语时不跟着名词变数和格。

这一点比罗马尼亚语和意大利语省事太多，形容词字典只需要存一个形态。

真正要留变量的是复合词的连字符：模板要能根据词根数和音节数判断加不加。

音节数的计算按元音个数来，匈牙利语的音节结构规整，这个判断可以自动做。

加上主格形态和变音符号写全这两条，四条规则就能覆盖标题模板的绝大部分需求。

形容词不变形这条省下来的力气，建议花到连字符判断上去，那才是匈牙利语标题模板里唯一需要真逻辑的部分。

## 面包屑与筛选器该用哪个格？

面包屑里的分类名用主格复数，这是列表页的自然形态。

筛选器的选项标签也用主格，因为它们要跟后台的属性值对齐。

页面H1可以用带格尾的自然句式，读起来更像人写的。

筛选结果的提示语里会出现位置格，比如在某个分类里找到多少件商品。

这句提示语的模板要按格来拼，直接把主格塞进去语法上是错的。

这类小文案的语法质量，是本地用户判断站点是不是机器翻译的重要依据。

这类提示语的模板最好按格拆成几个变体存起来，别在代码里做字符串拼接，因为格尾的选择还要受元音和谐影响，拼接逻辑很快会失控。

## URL该保留变音字符还是脱掉？

匈牙利语的主流做法是脱到基本拉丁字母。

á变a，é变e，ö和ő都变o，ü和ű都变u。

注意ő和ö脱完是同一个字符，所以两个不同的词可能脱出同一个slug。

这种撞车在匈牙利语上比在其他语言里常见得多，因为长短元音的对立太普遍。

slug生成器要加一层撞车检测，撞了就加品类前缀或者数字后缀消歧。

域名后缀用hu，这个后缀1990年就完成了委派 (https://www.iana.org/domains/root/db/hu.html)，是本地信任度最高的选项。

撞车检测最好在建站初期就加上，等到几万条URL都生成完再去处理，改动就会牵扯到重定向和已经积累的外部链接。

## 锚文本要准备几个变体？

内链的锚文本嵌在句子里，句子要求什么格，锚就得用什么格。

每个目标页准备三到四个变体，覆盖主格、宾格和一两个位置格就够。

变体之间的词根保持一致，变的只是词尾，这样主题信号不会被稀释。

匈牙利语在这里有个优势：形容词做定语不变形，所以带形容词的锚文本变体比屈折语少一半。

检查锚文本质量可以导出所有指向同一页面的锚，看词根是不是一致、词尾是不是有变化。

词尾全都一样反而是个坏信号，说明有人在硬塞固定锚文本。

顺带一提，匈牙利语的锚文本写起来比屈折语舒服的地方还在于语序灵活，同一个词根可以放在句子的不同位置，读起来不会僵硬。

## 元描述的字符预算怎么算？

匈牙利语的词平均比英语长，因为语法信息全靠往词尾接。

同样一句话的匈牙利语版本，字符数经常比英语多出两三成。

所以按英语稿的长度翻译，出来的元描述十有八九会被截断。

正确做法是按目标语言的字符数控制，把核心信息压在前面。

标题同理，复合词在匈牙利语里很长，写完先量一遍再决定要不要拆。

移动端商品卡片的两行截断更要拿真机看，模拟器的字体度量跟真机对不上。

还有一个跟长度有关的地方是面包屑：匈牙利语的分类名普遍偏长，多级面包屑在移动端很容易折行，层级设计时要比英文站保守一档。

## 机器翻译在匈牙利语上最常犯哪几类错？

第一类是元音和谐选错后缀变体，尤其是圆唇那一维。

第二类是定动词和不定动词用反，宾语明明是确定的却用了不定形态。

第三类是复合词该加连字符的地方不加，或者不该加的地方乱加。

第四类是姓名顺序，翻译引擎会把匈牙利语的姓名按英语顺序重排。

前三类是语法问题，本地用户读得出来但不一定说得清哪里怪。

第四类是最容易被投诉的，因为它把人的名字写错了，这在任何文化里都不礼貌。

第五类不算语法错但同样致命：机器翻译会把国际通行的技术词直接音译过来，而匈牙利语在这类概念上往往有一个大家都在用的本地词。

## 母语审校清单该列哪几条？

后缀的元音和谐是不是对，尤其检查前元音词根后面的三型后缀。

动词形态跟宾语的确定性是不是匹配。

复合词的连字符是不是按音节数规则加的。

长音符号是不是全部打全，尤其是ő和ű。

姓名顺序、日期格式、价格分隔符是不是本地写法。

最后一条老规矩：让审校的人念一遍，念着卡壳的地方一定有问题。

审校人选上建议避开纯语言学背景，找有电商或者广告文案经验的，前者容易把口语词全改成书面词，改完语法完美但没人这么搜。

## 引擎那一半的功课为什么不在这篇里？

这篇从头到尾讲的是语言本身：格、后缀、字母、字符、格式。

某个搜索引擎在匈牙利市场怎么排名，那是引擎层的题，跟这门语言的语法没有关系。

多语言站要按国家还是按语言分域名，那是架构层的题，同样不在这里。

把三层混在一篇里写，结果通常是每一层都只讲了个开头。

分开的好处是排查问题时路径清晰：流量掉了先判断是词形没覆盖，还是地区定向出了问题。

这两条路的排查动作完全不同，混在一起只会互相干扰。

这种分层还有一个好处：语言层的结论能跨引擎复用，而引擎层的结论过几年就会过时，两者放在一起写会让整篇文章的保鲜期跟着短的那一半走。

## 一个箱包站从零开始，推荐什么顺序？

第一步测字体，确认ő和ű在你的字体栈里有字形。

第二步建属性字典，标注低元音词干和消失元音词干这两个布尔字段。

第三步查词典补齐核心词在五六个高频格上的形态。

第四步配排序规则，把多字母字母和变音元音排对。

第五步改标题模板，加上连字符判断和主格约束。

第六步配站内搜索的变音折叠与词干化，最后才是内容规划。

这六步里唯一能并行的是第一步和第二步，其余必须串行，尤其排序规则要在字典建好之后配，否则没有足够的真实词条去验证配得对不对。

## 做完之后最先看到哪个指标动？

字母索引和排序改完，最先动的是这几类页面的跳出率。

站内搜索配完，零结果率通常一两周内就有明显下降。

标题模板改完，商品页的展现量会跟着起来，因为终于用对了检索形态。

长尾流量要等内容规划落地，周期最长。

字体那一步的收益不在报表里，它防的是用户看到方框之后直接关掉页面。

保哥见过一个站因为字体缺ő，整个品类名在移动端全是方框，跳出率高得像被攻击了。

如果只能做一件事，那就做字体测试加变音折叠这两项的组合，它们加起来不到一天工时，却挡住了匈牙利语上最容易发生的两类流失。

## 常见问题解答

## 匈牙利语的十八个格，做SEO是不是全都要覆盖？

不需要。十八这个数字本身在语言学上就有争议，不同体系数出来从十七到二十七都有，而真正会出现在商品类查询里的通常只有四到六个：主格、宾格、表示在里面的、到里面去的、从里面出来的，再加一个表示用途的。其余的格要么只出现在完整句子里，要么语义太具体，用户不会拿它搜商品。选词表按这五六个格铺，每个核心词五六行就够，一个品类三五十个核心词，规模完全可控。把力气花在这里，比背下全部词尾有用得多。还有一个现实考虑：格的形态越冷僻，搜索量越低，为它们单独准备内容的边际收益迅速趋近于零，把这份预算挪去做本地词对照表回报明显更高。

## 既然都是黏着语，土耳其语那套后缀处理方法能不能直接搬到匈牙利语上？

不能。共性只有一条：语法信息靠往词尾接后缀。差别有四条，每一条都会让方案失效。格的数量从六个变成十八个；土耳其语的难点是后缀链能挂五层，匈牙利语的链要短得多，格尾几乎总在最外层；匈牙利语有定冠词而土耳其语没有，而且这个冠词还会往回改动词的词尾；最后是字母表，匈牙利语有八个多字母字母，排序和切分逻辑必须重写。搬过来的顶多是黏着语这个思维方式，具体规则一条都不能复用。如果一定要找一条能复用的，那就是选词表按形态铺开这个结构本身，但表里每一列的定义都得按匈牙利语重写一遍。

## 匈牙利语跟芬兰语是亲戚，能不能共用一套处理方案？

能共用的只有思路，不是方案。两门语言分家太早，词汇上几乎没有可辨认的对应关系。技术上的主要差别有三处：芬兰语的词干靠辅音级差变化，匈牙利语没有级差但有末元音延长和消失元音；芬兰语的元音和谐只有前后一维，匈牙利语多一维圆唇；芬兰语没有冠词，匈牙利语有而且影响动词变位。共用的部分是方法论层面的：都要按格铺选词表，都要接词干化，都要处理词干本身的不规则变化。还有一处实操差别：芬兰语的高频格分布分散，选词表要铺得宽；匈牙利语相对集中，可以铺得窄而深，两者的预算分配方式并不一样。

## ő和ű这两个字符经常显示成方框，怎么办？

先测字体，别信厂商标注的语言支持列表。做法是把这两个字符跟对应的ö和ü排在一起渲染一张图，肉眼看有没有缺字形。网页字体、商品图上的文字、视频字幕、封面图这几处都要单独测，它们用的字体往往不是同一套。如果主字体缺，可以配一个覆盖完整的备选字体放在字体栈后面。这一步的成本是十分钟，不做的代价是本地用户看到一片方框直接关掉页面。顺带提醒，大写形态同样要测，全大写的标题和导航栏用得上，而字体只画了小写变音形态的情况一点都不罕见。

## 复合词的连字符到底加还是不加，有没有简单判断法？

有一条能覆盖大部分情况的判断：数词根个数和音节数。三个以上词根组成、且总音节数超过六个的复合词才加连字符，其余不加。音节数按元音个数算，匈牙利语的音节结构规整，这个判断可以自动化。拿不准的词可以用科学院的断词工具查一下，它会直接给出正确断法。实操上建议标题按正字法写连字符，同时在商品别名字段里存一份不带连字符的形态给站内搜索用，因为用户在手机上基本不会打连字符。还有一个跟连字符有关的坑：不同输入法打出来的横线在码位上可能是三个不同字符，入库前要统一，否则同一个词会分裂成好几条。

## 定冠词影响动词变位这件事，对关键词研究的实际影响有多大？

影响集中在问句型和长尾查询上，商品名类的短查询几乎不受影响。因为动词只在完整句式里出现，而商品名查询大多是名词短语。所以处理优先级不算最高，但也不能不做：同一个意图的问句会以两种动词形态出现在日志里，只铺一种就漏掉一半。落地做法有两条，一是在正文和FAQ里让两种句式各自然出现一次，二是在站内搜索的同义词表里把两种动词形态映射到一起。做完之后长尾查询的零结果率会有可见的下降。另外这个形态还能当意图信号用：走确定形态的查询往往指向具体某件商品，走不确定形态的更偏品类浏览，两者该落到的页面类型不一样。

## 匈牙利语的姓名顺序真的需要专门处理吗？

需要，而且要改的地方比想象中多。匈牙利语是欧洲唯一日常把姓写在名前面的语言，跟中文一致、跟所有邻国相反。要改四处：注册表单的字段顺序、订单页的姓名展示、邮件与客服的称呼、结构化数据里的姓名字段。最容易漏的是最后一处，因为姓名是分成两个字段填的，顺序错了机器读出来就是错的。这条不影响排名，但它是本地用户判断你有没有认真做本地化的第一个信号，而且把人名字写错在哪个文化里都不礼貌。实现上有个小建议：数据库里存姓和名两个独立字段，展示顺序交给模板控制，这样以后要支持其他市场时不用改数据结构。

## 权威参考资料



## 罗马尼亚语SEO和别的拉丁语族反着来，定冠词是接在词尾上的

- URL：https://zhangwenbao.com/romanian-seo-postposed-definite-article-comma-diacritics.html
- 分类：小语种SEO
- 发布：2013-06-11  |  更新：2026-07-26
- 摘要：罗马尼亚语SEO实战：定冠词接在词尾让一个名词有四种写法，中性名词单复数换性别，两套变音码位能存出四种字节序列。给出选词表结构、标题模板规则与六步落地顺序。
- 关键词：关键词研究,SEO,小语种SEO

> **TLDR**：摘要：罗马尼亚语用拉丁字母，属于罗曼语族，看着应该和西班牙语、意大利语一个路数。真做起来第一批选词就会错：这门语言的定冠词不写在名词前面，而是粘在词尾上，一个名词至少四种写法；它还留着格的残余、留着一类单复数换性别的中性名词；更麻烦的是ș和ț在Unicode里有两套码位，同一个词能存出四种字节序列。这篇把这些坑逐个拆开，给出选词表、模板规则和审校清单。

> 摘要：罗马尼亚语用拉丁字母，属于罗曼语族，看着应该和西班牙语、意大利语一个路数。真做起来第一批选词就会错：这门语言的定冠词不写在名词前面，而是粘在词尾上，一个名词至少四种写法；它还留着格的残余、留着一类单复数换性别的中性名词；更麻烦的是ș和ț在Unicode里有两套码位，同一个词能存出四种字节序列。这篇把这些坑逐个拆开，给出选词表、模板规则和审校清单。

## 罗马尼亚语在拉丁语族里到底特殊在哪？

接手一个准备进罗马尼亚市场的灯具站时，最省事的判断是把西班牙语那套流程复制一遍。

字母表是拉丁的，词汇里有大量能一眼认出来的拉丁词根，连语法术语听着都熟。

然后你把第一版关键词表交给本地同事，对方圈出来的问题会集中在同一个位置：词尾。

罗曼语族里，法语、西班牙语、葡萄牙语、意大利语的定冠词都写在名词前面，是独立的一个词。

罗马尼亚语不是。它把定冠词接到名词后面，跟词根粘成一个词。

这一条不是语法课上的冷知识，它直接决定了你的关键词表要多准备几行，也决定了自动补全在这门语言上会怎么失灵。

除此之外还有格的残余、中性名词、两套码位的变音字符、一段反复过两次的正字法改革。这门语言在罗曼语族里像个走岔了路的亲戚。

语言学上把这一组特征叫巴尔干语言联盟，指的是几门亲缘关系不近的语言因为长期相邻而共享了同一批语法特征，后置定冠词就是其中最显眼的一条。

这条线索的实用价值在于：等你以后做保加利亚语或者阿尔巴尼亚语时，会发现词尾接冠词这套麻烦事又原封不动地回来了，处理方案可以直接搬。

## 为什么定冠词粘在词尾会改变整张选词表？

拿灯具站最常见的一个词举例：pantof是鞋，我们换成本行的bec，灯泡。

不带冠词的单数是bec，加了定冠词是becul；复数是becuri，带定冠词的复数是becurile。

四个形态里，词根bec只在前三个字符稳定，后面全在变。

用户在搜索框里打什么，取决于他脑子里那句话的语法位置，而不是取决于词典原形。

问“哪种灯泡好”，他打ce becuri；问“这个灯泡多少钱”，他打becul acesta。

这意味着单靠词典原形建的关键词表，天然接不住一大半真实查询。

更实际的影响是：同一个商品，标题里该用bec还是becul，取决于标题的句式，而不是取决于你的模板变量。

更彻底一点说，罗马尼亚语的名词根本没有一个可以脱离语境使用的中立形态，词典给的那个原形在真实句子里出现的频率其实并不算高。

所以选词表的第一列不该叫关键词，该叫词根，后面四列才是形态；这个改名不是文字游戏，它决定了下游的人会不会误以为第一列可以直接拿去写标题。

## 一个名词四种写法，前缀匹配会失效在哪一步？

搜索框的自动补全、站内搜索的前缀索引、商品筛选器的模糊匹配，绝大多数默认按前缀工作。

对英语这类词形稳定的语言，前缀匹配够用：打lam能带出lamp、lamps、lampshade。

罗马尼亚语的变化全在词尾，前缀匹配理论上应该更好使才对。

问题出在反方向：用户打的是带定冠词的形态，而你的索引里存的是原形。

打becuri匹配不到bec，因为bec比becuri短，前缀关系是反的。

补救办法有两条：给索引额外写入常见的带冠词形态，或者上一层轻量的词尾归并规则。

Snowball的罗马尼亚语词干算法 (https://snowballstem.org/algorithms/romanian/stemmer.html)专门处理了后置冠词与复数词尾，站内搜索接上它，能一次解决大部分匹配漏空。

顺带一提，这也是罗马尼亚语站的站内搜索零结果率普遍偏高的根本原因，很多团队查了半年前端和索引配置，问题其实全在词尾那两三个字符上。

## 不定冠词在前、定冠词在后，标题模板怎么拆？

罗马尼亚语的不定冠词是独立的词，写在名词前面：un bec，一个灯泡。

定冠词却在后面：becul，那个灯泡。

同一个名词，两种冠词跑到了句子的两头。

后果是标题模板不能只留一个占位符。你要么固定用无冠词形态，要么按句式分成两套模板。

实践里最稳的做法是：商品标题一律用无冠词形态，把冠词留给正文与元描述。

这样标题保持了关键词的检索形态，正文又能读得像人写的。

还有一种折中写法：标题主体用无冠词形态，句末补一个带定冠词的短语作为自然收尾，两种形态在同一个标题里各占一次，检索和可读性都不吃亏。

## 形容词要跟着名词改几次？

罗马尼亚语的形容词要和名词的性、数一致，这一点和意大利语同源，我在意大利语那篇 (https://zhangwenbao.com/italian-seo-gender-agreement-elision-keyword-research.html)里已经拆过一遍。

罗马尼亚语多了一层：形容词还会受定冠词位置影响。

bec economic是节能灯泡，becul economic是那个节能灯泡，形容词本身没变。

但当形容词提到名词前面时，定冠词会跑到形容词尾巴上：economicul bec。

这种语序在广告语和口号里很常见，在商品标题里很少见。

你需要知道它存在，是因为竞品的广告文案会用，而你的关键词工具会把它当成另一个词统计。

这类前置语序在罗马尼亚语里带有明显的文学腔和强调意味，商品页硬用会显得用力过猛，但在品牌slogan和促销活动名里反而是加分项。

## 中性名词是怎么回事？单数算阳性，复数算阴性

罗曼语族大多只有阳性和阴性两个性。

罗马尼亚语有第三类，语法书叫中性，也叫两可性名词。

它的规则很直白：单数时按阳性搭配形容词，复数时按阴性搭配。

bec就是一个中性名词。un bec economic，单数按阳性；două becuri economice，复数按阴性，形容词词尾跟着换。

这类词在商品名里的占比不低，桌子、灯、窗户、盒子、包装，全是中性。

如果你的标题模板只按“性别”字段拼形容词，中性名词一定会拼错一半。

这类词在语法书里的正式名称是两可性名词，意思是它并不真的存在第三种性，只是在单数和复数两个数上分别倒向了两边，这个理解方式比死记中性两个字有用。

## 商品属性字典要按几个维度建？

被中性名词坑过一次之后，正确的做法是把名词的性拆成两个字段。

一个字段记单数搭配用什么性，另一个记复数搭配用什么性。

阳性名词两个字段都是阳性，阴性名词两个都是阴性，中性名词是阳性加阴性。

形容词字典则要存四个形态：阳性单数、阴性单数、阳性复数、阴性复数。

拼装规则变成：按当前是单数还是复数，取对应字段的性，再去形容词字典里取词。

这个结构一开始看着啰嗦，但它是唯一能自动跑对中性名词的写法。

字典建好之后还要加一条校验：任何名词如果单数字段和复数字段的值不同，就必须被标记为两可性名词，这样新词入库时不会因为录入的人不了解语法而漏标。

再往前一步，这套字典还能顺手解决单位与量词的搭配问题，罗马尼亚语在计数时对某些名词有固定的搭配写法，一并存进去比事后打补丁划算。

## 复数有三条路线，选词表要覆盖到哪一档？

罗马尼亚语名词的复数词尾主要是三种：i、e、uri。

阳性名词大多走i，阴性名词大多走e，中性名词大多走uri。

“大多”这两个字里藏着全部的麻烦，例外多到不能靠规则推。

更麻烦的是复数化经常伴随词干内部的音变：mână到mâini，词根里的元音也变了。

选词表的处理办法只有一条：高频商品词逐个查词典确认复数，别让脚本猜。

dexonline的bec词条 (https://dexonline.ro/definitie/bec)直接给出完整的变格表，包含四个形态，逐词核对比任何自动化都快。

另一个容易被忽略的细节是，同一个词在不同义项上可能走不同的复数路线，一个词既指实物又指抽象概念时，两个义项的复数形式经常分道扬镳。

## uri这个词尾从哪来，为什么工具经常切错？

uri这个词尾来自拉丁语中性名词的复数形式，这条线在其他罗曼语族语言里基本断了。

它是罗马尼亚语独有的一条形态遗产，也是最容易被通用工具误判的一个词尾。

很多多语言分词器会把uri当成一个独立的后缀切掉，切完剩下的词根有时候不成词。

更常见的错误是把它和土耳其语借词的词尾搞混，罗马尼亚语里确实有一批土耳其语借词。

判断办法很土但有效：拿站内搜索日志里出现频次前两百的词，人工看一遍切分结果。

切错的那些通常集中在同一类词尾上，改一条规则能修一片。

从检索的角度看，uri结尾的词还有一个副作用：它让复数形式比单数长出三到四个字符，商品标题的字符预算要按复数形态来算，不能按单数估。

## 名词的格还剩多少？

拉丁语的格系统在罗曼语族里几乎全部消失，只有罗马尼亚语留下了残余。

今天的罗马尼亚语名词有主格宾格合一的形态，和属格与格合一的形态，语法书叫斜格。

阴性名词的斜格形式经常和复数形式长得一样：casă的属格是casei，复数是case。

这一点会让基于词形的统计工具把两类完全不同的用法合并成一条数据。

做俄语那种六格语言时，这个问题我在俄语那篇 (https://zhangwenbao.com/russian-seo-cyrillic-cases-declension-wordstat-keyword.html)里讲过得更细。

罗马尼亚语的量级小得多，但方向一样：工具给你的数字是若干种形态加起来的和。

实际操作里最省事的判断是：只要你的文案里出现了表示所属关系的结构，那个名词八成就得换成斜格形态，而这类结构在商品描述里出现得相当频繁。

顺便说一句，罗马尼亚语的斜格在带定冠词时形态又不一样，所以真正要记的是格与冠词交叉出来的那张小表，而不是单独的格表。

## 呼格还活着吗？它出现在什么文案里

罗马尼亚语还保留着一个呼格，用来直接称呼人或物。

domnule是先生的呼格形式，比domn多了一个词尾。

商品词几乎用不到呼格，但客服话术、邮件开头、弹窗文案会用。

忽略它不会掉排名，但会让本地用户一眼看出这段文案是机器翻的。

把常用称呼词的呼格形态整理成一张十来行的小表，交给写文案的人，成本几乎是零。

呼格在现代罗马尼亚语里正在退化，年轻一代口语中经常直接用主格代替，所以文案里用不用它其实也是一个语气选择，正式场合用，轻松场合可以不用。

## ș和ț有两套码位，你的站可能同时存着两种

这是罗马尼亚语技术侧最贵的一个坑，也是同类文章几乎不提的一个坑。

罗马尼亚语正确的字母是s和t底下加一个逗号，码位是U+0219与U+021B。

但Unicode早期版本里没有这两个字符，只有底下带下加符的U+015F与U+0163，那本来是土耳其语用的。

于是从九十年代到两千年代中期，绝大多数罗马尼亚语文本用的是土耳其语那两个字符。

带逗号的版本要到Unicode 3.0才补进去，Latin Extended-B码表 (https://www.unicode.org/charts/PDF/U0180.pdf)里能直接查到这两组码位并排列着。

字体厂商跟进又晚了几年，早期Windows上带逗号的字符经常渲染成空白方框。

这段历史留下的直接后果是：今天罗马尼亚互联网上的存量内容，大约有相当一部分仍然用着土耳其语那两个码位，而它们看起来和正确写法几乎无法用肉眼区分。

## 同一个词能存出几种字节序列？

把两套码位再乘上组合字符的可能性，数量就上来了。

s加下加符可以是预组合的U+015F，也可以是基础字母s加组合下加符U+0327。

s加逗号可以是预组合的U+0219，也可以是s加组合逗号U+0326。

四种字节序列，屏幕上看着几乎一模一样。

结果是你的商品库里可能同时存在四份“同一个”商品名，去重脚本一条都发现不了。

URL里出现不同的字节序列时，问题会升级成两个不同的页面。

检验自己站上有没有这个问题的最快办法，是拿一段包含ș的商品名做十六进制转储，看看落在磁盘上的到底是哪一串字节，屏幕上是看不出来的。

## 规范化该选NFC还是NFD？

解决办法是在入库前做一次规范化，把所有形态统一到一种。

UAX #15定义的四种规范化形式 (https://www.unicode.org/reports/tr15/)里，做网页内容一般选NFC，把组合序列合成预组合字符。

但NFC只解决组合与预组合的差别，它不会把带下加符的U+015F变成带逗号的U+0219。

那两个是不同的字符，规范化管不着，得额外写一条映射。

顺序是：先做字符映射把下加符版换成逗号版，再做NFC。

数据库、搜索索引、URL生成器三处都要跑同一套流程，少一处就等于没做。

还有一个容易漏的地方是用户输入：搜索框、评论区、地址表单收到的内容同样要走这套流程，否则用户提交的数据会成为新的污染源，几个月后又是一片混乱。

## 用î还是â？这门语言改过两次主意

罗马尼亚语里有两个字母发同一个音：î和â。

1953年的改革规定除少数例外一律写î，于是有了cuvînt、român这种混合局面。

1993年罗马尼亚学院又改回来，规定词中一律写â，词首词尾写î。

今天的正式文本写cuvânt，而1993年之前受教育的人手打时经常还是cuvînt。

两个拼法在搜索日志里会同时出现，比例随人群年龄变化。

正文一律按现行规范写，选词表里把旧拼法当同义词收进来，这是成本最低的处理。

这场改动的背景是政治的：1953年那次改革要弱化罗马尼亚语与拉丁语的视觉联系，1993年恢复â则是要把这条联系重新亮出来，字母在这里承担了身份表达的功能。

## 用户到底打不打变音符号？

这个问题在带变音符号的语言里反复出现，越南语那篇 (https://zhangwenbao.com/vietnamese-seo-tone-marks-syllable-spacing-keyword.html)里我按两拨人来分，罗马尼亚语的分法不太一样。

罗马尼亚语的变音字符有五个：ă、â、î、ș、ț。

前三个在标准键盘上相对好打，后两个要切布局或者长按。

所以现实中的分布不是二分的，而是部分打、部分不打：写mărime但写sosete而不是șosete。

这种半带半不带的形态，是罗马尼亚语搜索日志里占比最高的一类。

关键词表如果只做全带和全不带两版，中间那一大片就漏了。

更细一层的规律是：越靠近词根开头的变音符号越容易被打出来，越靠近词尾的越容易被省略，因为用户在打字过程中对后半段的注意力本来就在下降。

## 为什么移动端输入法决定了长尾的形态？

桌面端用户切一次键盘布局能一直用下去，移动端不是。

手机输入法默认的罗马尼亚语布局里，ș和ț要长按s和t才出得来。

打商品名时多按两次不算什么，打一整句长尾问题时没人愿意长按五次。

所以查询越长，带变音符号的比例越低，这个规律相当稳定。

反推到内容规划上：短的商品词按规范写，长尾问答的标题要额外准备不带变音的版本。

做法是在FAQ的问句里自然带上两种形态，别硬塞成关键词堆砌。

这也解释了一个反直觉的现象：商品短词的带变音比例反而比长尾问题高，很多团队按整站平均值做决策，结果给最该做变体的那批长尾页面配错了形态。

## 哪把尺子能量准变音符号的真实比例？

外部关键词工具在罗马尼亚语上给的数据经常已经做过归一化，带不带变音看不出来。

能看到真实分布的地方只有两个：站内搜索日志，和搜索引擎给站长的查询报表。

站内搜索日志最准，因为它记录的是用户一个字符一个字符打进去的原始串。

做法是把日志按是否含变音字符分桶，再按查询长度分段统计。

跑出来的表通常长这样：三个词以内带变音的占三成，五个词以上不到一成。

拿到这张表，你才知道该给哪些页面准备不带变音的变体。

这张表还有一个附带用途：它能反过来验证你的变音折叠层有没有真正生效，折叠正常时，两种形态的零结果率应该几乎一样，差得多就说明某一侧没接上。

## 斯拉夫借词层怎么影响选词？

罗马尼亚语被斯拉夫语言包围了一千多年，词汇里有一层厚厚的斯拉夫借词。

十九世纪的语言现代化运动又从法语和意大利语大量引进了拉丁词。

结果是很多概念有两个词：一个斯拉夫来的，一个拉丁来的。

两个词往往语域不同，斯拉夫来的偏日常口语，拉丁来的偏正式书面。

用户在搜索框里打的是口语那个，你的产品文案写的是书面那个。

这是罗马尼亚语站最常见的一类词不对路，而且从中文一侧完全看不出来。

这一层借词还带来一个隐蔽影响：斯拉夫来的词往往在构词能力上更强，能派生出更多复合表达，所以长尾词族的根节点经常落在口语那个词上而不是书面词上。

判断一个词是哪一层来的其实有个粗糙但好用的线索：读起来像意大利语的多半是拉丁层，辅音连缀比较密的多半是斯拉夫层。

## 同义词里该选口语词还是书面词？

判断标准是这个词出现在页面的哪个位置。

标题和H2用用户会打的那个词，也就是口语那个。

正文里两个都出现，让页面在两种表达上都有覆盖。

规格表和技术参数用书面词，因为那部分内容本来就偏正式。

这个分工不是罗马尼亚语特有的，但罗马尼亚语的两套词汇分层特别整齐，做起来收益也特别明显。

整理这类词对的最快办法，是让本地同事看一遍你的品类词表，逐个标注“这词我平时不会说”。

如果两个词的搜索量差距在三倍以内，通常值得各做一个页面并用内链区分意图；差距超过一个数量级时，弱的那个只做同义词覆盖就够了，别浪费页面预算。

## 摩尔多瓦那一半市场要不要单独做？

摩尔多瓦的官方语言和罗马尼亚语是同一门语言，宪法上的名称有过争议，语言本身没有分歧。

但两边的市场差别很大：货币不同，物流不同，购买力差一截。

从语言层看，两边的书面语几乎可以完全共用。

从市场层看，值不值得单开一套内容，取决于你的客单价和配送能力。

近亲语言要不要拆成两套内容，这个判断框架我在捷克语和斯洛伐克语那篇 (https://zhangwenbao.com/czech-slovak-seo-content-reuse-decision.html)里给过三档判据，摩尔多瓦这一对属于最容易的那一档。

绝大多数情况下的正确答案是：内容共用一套，只把价格、货币和配送信息做成变量。

要注意的是，摩尔多瓦本地日常语言环境里俄语的占比不低，做付费投放和社媒时的语言选择跟做自然搜索并不是同一个答案，这两件事要分开评估。

## 西里尔时期留下的搜索长尾还剩多少？

摩尔多瓦在苏联时期用西里尔字母书写罗马尼亚语，1989年才改回拉丁字母。

三十多年过去，日常搜索里已经基本看不到西里尔形态的罗马尼亚语。

还能看到的地方是历史文献、地名的旧写法、以及德涅斯特河沿岸地区的部分内容。

对做电商的站来说，这块长尾的商业价值接近零。

提这一段是因为做市场调研时容易被历史资料带偏，以为要覆盖两套字母。

真正需要处理两套字母的是塞尔维亚语那种情况，那是另一门语言的另一个问题。

如果你的品类和历史、旅游、地名相关，那就是另一回事了，旧地名的西里尔写法在这类查询里还有真实体量，值得单独拉一份数据看看再决定。

## 字母排序该怎么排，A-Z导航会错在哪？

罗马尼亚语字母表在基本拉丁字母之外多了五个：ă、â、î、ș、ț。

排序时它们不合并到基础字母里，而是各自排在对应基础字母之后。

a、ă、â是三个位置，i、î是两个位置，s、ș和t、ț同理。

用默认的字节序排序，这五个字母会全部跑到z后面去。

品牌墙、品类字母导航、地区列表这三类页面最容易踩，因为它们直接把排序结果印在页面上。

解决办法是用支持区域设置的排序规则，LDML的排序规范 (https://www.unicode.org/reports/tr35/tr35-collation.html)里有罗马尼亚语的完整定义。

还有一个更细的坑：罗马尼亚语的排序把ă和â当成两个不同的字母分别排，而某些通用排序库会把它们都归到a下面，结果是导航顺序看着差不多但就是不对。

## 价格该怎么写才像本地人写的？

罗马尼亚的货币是列伊，代码RON，日常写作lei。

数字格式和大多数欧陆国家一样：小数点用逗号，千分位用点。

1.299,90 lei是一千二百九十九列伊九十巴尼，不是一点二九九。

货币符号写在数字后面，中间有一个空格。

这几条如果照搬英文格式，价格会显示成用户读不懂的样子，转化直接掉。

更隐蔽的是价格筛选器：前端解析用户输入时如果按英文规则读逗号，1,5会被读成15。

辅币叫巴尼，一百巴尼等于一列伊，标价时小数位一般都写满两位，写成整数不写小数会让价格显得像是估价而不是实价。

促销价的写法也有讲究，原价加删除线再写现价是通行做法，但折扣百分比的写法本地更常见的是写省了多少钱而不是打几折。

## 日期与尺寸格式还有哪些要改？

日期用日月年顺序，分隔符是点：11.06.2013。

星期从周一开始，日历组件要跟着调。

长度单位用厘米和米，重量用千克，这几项和国内一致。

灯具站要特别注意色温和光通量的写法：3000K和800 lm，单位前有空格。

电压是220V到230V，插座标准是欧标C和F型，这类信息写在商品页上能减少一大批售前咨询。

这些不属于关键词，但它们是页面本地化程度的直接信号，用户扫一眼就能判断这站是不是给他们做的。

灯具还有一个本地特有的信息点：欧盟的能效标签等级要标出来，这一项在罗马尼亚市场的商品页上属于用户会主动找的信息，缺了会明显影响信任。

## 标题模板的一致性规则要写成什么样？

把前面几节的结论合起来，罗马尼亚语的标题模板需要满足四条。

名词一律用无冠词形态，避免定冠词把检索形态改掉。

形容词按名词的性数字段取形态，中性名词按单复数分别取。

变音符号一律按现行规范写全，不在标题里做不带变音的版本。

数字与单位按本地格式，货币符号在后。

四条写成校验规则挂到发布流程上，比靠人记住可靠得多。

这四条最好写成发布前的自动校验而不是文档里的规范，因为规范只能约束读过它的人，而真正往库里塞商品的往往是脚本或者第三方数据源。

## 面包屑与分类名要不要带定冠词？

面包屑里的分类名建议用不带冠词的复数形态。

becuri而不是becurile，这是最接近用户检索形态的写法。

页面H1可以带定冠词，读起来更自然。

筛选器的选项标签一律用无冠词形态，因为它们要和后台的属性值对齐。

这套分工的原则是：给机器看的地方用检索形态，给人读的地方用自然形态。

混着用不会出致命问题，但会让站内搜索的匹配率低一截。

顺带说一句，导航里的分类名一旦定下来就别轻易改形态，这类文本会被大量内链的锚文本引用，改一次要连带更新的地方比想象中多得多。

## URL里的变音字符该保留还是脱掉？

罗马尼亚语的URL主流做法是脱到基本拉丁字母。

ș变s，ț变t，ă和â变a，î变i。

这条转换要写死在slug生成器里，别指望通用的音译库，它们经常把ț转成ts。

ts这种转法是保加利亚语转写的规则，用在罗马尼亚语上是错的。

域名后缀用ro，这个后缀1993年就完成了委派 (https://www.iana.org/domains/root/db/ro.html)，本地信任度很高。

多语言站要不要按国家分域名，那是架构层的题，这篇不展开。

脱变音的映射表还要处理一个特例：ș和ț在词尾时脱成s和t会让某些词的slug撞上另一个真实存在的词，遇到这种情况宁可加一个品类前缀来消歧。

## 锚文本会跟着格变形吗？

会，而且比你想的更频繁。

内链的锚文本嵌在句子里，句子的语法要求它用什么形态，它就得用什么形态。

硬把原形塞进句子里，读起来像外国人写的中文。

处理办法是给每个目标页准备三到四个锚文本变体，覆盖常见的语法位置。

变体之间的核心词根保持一致，变的只是词尾。

这样锚文本既读得通顺，主题信号也不会散掉。

检查锚文本质量的一个土办法：把站内所有指向同一页面的锚文本导出来，如果它们的前四个字符高度一致而词尾各不相同，那就说明变体做对了。

## 元描述被截断的位置和词长有什么关系？

罗马尼亚语的平均词长比英语长，比德语短。

加上定冠词之后，名词还会再长两到三个字符。

同样字数的元描述，罗马尼亚语版本的实际字符数会明显超过中文版本的译文长度估算。

实操上的经验是：按目标语言的字符数控制，别按源语言的字数控制。

把关键信息压到前面，让截断发生在补充说明那一段。

标题同理，长复合结构在罗马尼亚语里很常见，写之前先量一遍字符数。

另一个和词长相关的地方是移动端的商品卡片，罗马尼亚语商品名普遍偏长，两行截断的位置经常正好切在关键属性词上，这个要拿真机看，模拟器上看不出来。

## 机器翻译在罗马尼亚语上最常犯哪三类错？

第一类是定冠词处理不当，该带的时候不带，不该带的时候乱带。

第二类是中性名词的形容词一致性，单数对了复数错，或者反过来。

第三类是变音符号漏打，尤其是ș和ț，翻译引擎经常输出土耳其语那两个码位。

第三类最隐蔽，因为屏幕上看起来是对的，只有做字符审计时才发现。

解决办法是在发布前跑一遍字符白名单检查，把U+015F和U+0163列进告警。

这个检查五行代码，能挡掉一整类几年都发现不了的问题。

还有一类不算错但很致命的问题：机器翻译倾向于选择书面语域的那个同义词，于是整站文案读起来像政府公文，词也全落在用户不会搜的那一侧。

检验翻译质量有个便宜办法：把译文里所有带定冠词的名词挑出来，看比例是不是明显高于本地原生文本，机器翻译在这一项上几乎总是超标。

## 母语审校该盯哪几处？

审校清单不用长，六条就够。

定冠词该不该出现在这个位置，形容词的性数是不是跟着名词走。

斯拉夫词与拉丁词的选择，是不是符合这段文字的语域。

变音字符是不是全部用了带逗号的码位。

价格、日期、单位的格式是不是本地写法。

标题和H2里的名词是不是用了无冠词形态。

最后一条：让审校的人念一遍，念着别扭的地方一定有问题，这条比前五条加起来都管用。

审校的人最好找有电商或者营销背景的，纯语言学背景的审校经常会把口语词全改成书面词，改完语法完美，搜索覆盖反而变差了。

审校结果最好回流成规则而不是只改一遍稿子，同一类错误改到第三次还在出现，就说明它该进模板校验而不是继续靠人眼抓。

## 词典该怎么用才不浪费时间？

罗马尼亚语最实用的在线词典给的不只是释义，还给完整的变格表。

拿商品词逐个查，把四个形态一次抄进选词表，比事后补要快得多。

阴性名词要额外看斜格形式，那一栏经常和复数长得一样。

lampă的词条 (https://dexonline.ro/definitie/lampa)就是个标准例子，阴性名词的四个形态加斜格都在一张表里。

整个品类的核心词大概三五十个，一个下午能查完。

这三五十个词决定了你站上百分之八十的标题质量，这笔时间花得值。

查词时顺手把每个词的语域标注也记下来，哪个是口语哪个是书面，这一列在后面写标题和正文时的价值不比形态那几列低。

## 站内搜索该怎么配才接得住词尾变化？

最低配置是接一个罗马尼亚语词干器，把词尾归并掉。

中配是词干器加同义词表，把口语词和书面词、新旧拼法映射到一起。

高配再加一层变音符号折叠，让带不带变音的查询都能命中。

三层里最划算的是变音折叠，代码最少，覆盖的查询最多。

词干器要注意别过度归并，罗马尼亚语有些短词被词干器切完只剩两个字母。

配完之后拿真实日志跑一遍回归，看零结果率有没有降下来。

配完之后还要留一个人工干预的口子，罗马尼亚语里总有一小撮词是任何算法都处理不好的，直接写死映射比反复调参数省心。

还有一件容易忘的事：搜索结果页的高亮逻辑也要跟着折叠规则走，否则用户搜不带变音的词，命中了却看不到高亮，会以为搜错了。

## 字符集遗留问题在老站上会怎么冒出来？

罗马尼亚语在UTF-8普及之前用过好几种字符集。

ISO 8859-2是中欧通用的那一套，但它里面只有带下加符的ș ț。

后来专门为罗马尼亚语等语言做了ISO 8859-16，才把带逗号的版本收进去。

Windows平台上更常见的是windows-1250，同样只有下加符版本。

这些字符集都登记在IANA的字符集清单 (https://www.iana.org/assignments/character-sets/character-sets.xhtml)里，接手老站时先查页面声明的是哪一种。

声明和实际编码不一致，是老罗马尼亚语站上乱码的头号原因。

判断老站真实编码有一个不太优雅但很可靠的办法：找一个已知含ș的页面，直接看原始字节，单字节说明是老字符集，双字节才是UTF-8。

## 迁移老内容时怎么把编码问题一次清干净？

顺序很重要，走错顺序会把问题固化下来。

第一步是确认原始文件的真实编码，别信页面上声明的那个。

第二步转成UTF-8，转的时候记下有多少字符转换失败。

第三步做码位映射，把下加符版本换成逗号版本。

第四步做NFC规范化，第五步重新生成URL与索引。

每一步之后都存一份快照，出问题能回退到具体哪一步，这个习惯救过我不止一次。

转换失败的那批字符千万别直接丢掉或者替换成问号，要单独导出来人工看，里面经常混着引号、破折号和货币符号这类同样有历史包袱的字符。

## 结构化数据里的语言标记该怎么写？

语言代码用ro，这是ISO 639-1的两字母代码。

需要区分地区时用ro-RO和ro-MD，格式遵循RFC 5646的语言标签规则 (https://www.rfc-editor.org/rfc/rfc5646)。

页面上的lang属性、结构化数据里的语言字段、以及站点地图，三处要一致。

价格字段的货币代码用RON，不要写lei，那是显示用的写法。

地址字段里国家代码用RO，邮编是六位数字。

这几项写对了，本地搜索结果里的展现会明显完整一些。

顺带提醒一句，罗马尼亚使用的时区在夏令时期间会切换，商品的配送时效和限时促销的截止时间如果写死了偏移量，一年里有半年是错的。

## 灯具站的罗马尼亚语选词表长什么样？

核心品类词先列无冠词单数和无冠词复数两列。

再加两列带定冠词的形态，供正文和元描述取用。

然后是变音符号列：全带、部分带、全不带，三种。

接着是同义词列，斯拉夫词和拉丁词各占一格。

最后是旧拼法列，î和â那一对差异只影响少数词，但那些词往往是高频词。

一个品类的完整表大概二百到三百行，这是罗马尼亚语站的地基。

这张表建议用版本管理存起来而不是放在共享表格里，因为它会被标题模板、站内搜索同义词表和内链锚文本三处同时引用，改动需要能追溯。

## 这张表该怎么排优先级？

不是每一行都值得单独做页面。

无冠词复数形态优先级最高，它是商品列表页的主关键词形态。

无冠词单数次之，用在商品详情页。

带定冠词的形态不单独做页面，只作为正文里的自然表达。

变音符号的变体也不单独做页面，靠站内搜索的折叠层接住。

真正需要单独规划的，是同义词那一列里语义差别较大的那些词。

排完优先级之后再做一次交叉检查：把高优先级的形态拿到搜索框里实际打一遍，看自动补全给出的建议词是不是你预期的那一批，不是就说明形态选错了。

## 竞品分析在罗马尼亚语上要多看一层什么？

常规的竞品分析看对方做了哪些词、页面结构怎么排。

罗马尼亚语要多看一层：对方用的是哪一套变音码位。

方法很简单，把对方页面的HTML抓下来，统计U+015F和U+0219各出现多少次。

用下加符版本的站，通常是多年前建的老站，内容更新频率低。

全部用逗号版本的站，一般是近几年重做过的，技术侧更值得警惕。

这个指标不写在任何工具的报表里，但它能帮你判断对手的技术底子。

同样值得看的还有对方的slug生成规则，把几十个商品页的URL排在一起，很容易看出对方用的是哪种脱变音映射，以及有没有处理撞词的问题。

把这两项加进竞品清单之后，你对一个罗马尼亚语站的技术判断通常比看外链数据准得多，因为字符处理骗不了人。

## 引擎那一半的功课为什么不在这篇里？

这篇从头到尾讲的是语言本身：词形、字符、编码、格式。

某个搜索引擎在罗马尼亚市场怎么排名，那是引擎层的题，和这门语言的语法没有关系。

把语言层和引擎层混在一篇里写，结果通常是两边都讲不透。

多语言站要按国家还是按语言分域名，那是架构层的题，同样不在这里。

你可以把这篇当成罗马尼亚语市场的语言侧清单，引擎侧和架构侧另有专篇。

分开做的好处是每一层的结论都能独立复用到下一个市场。

分层的另一个好处是排查问题时不容易误判：流量掉了先看是语言层的词形没覆盖，还是架构层的地区定向出了问题，两条路的排查动作完全不同。

## 从零开始做罗马尼亚语，推荐什么顺序？

第一步跑字符审计，确认站上用的是哪套码位，统一到带逗号的版本。

第二步建商品属性字典，把名词的性拆成单数搭配和复数搭配两个字段。

第三步查词典补齐核心品类词的四个形态。

第四步改标题模板，按前面那四条规则重写。

第五步配站内搜索的变音折叠和词干器。

第六步才是内容规划，这时候你手里的选词表已经能用了。

这六步的顺序不能随便调，尤其是字符审计必须在最前面，否则后面几步产出的所有数据都会带着两套码位的污染，到时候要重做的不是一步而是全部。

## 做完这六步，能看到什么变化？

最先动的是站内搜索的零结果率，通常一周内就能看到明显下降。

其次是商品页的展现量，因为标题终于用对了检索形态。

再往后是长尾流量，这一块要等内容规划落地才有。

字符审计那一步的收益不会直接体现在报表上，它防的是几年后的一次大清理。

保哥见过一个站因为两套码位混存，三年后做商品去重时发现两万条重复数据。

那次清理花掉的时间，够把前面六步全做完两遍。

如果你的站还在筹备期，那这六步的顺序可以直接当成排期表用，前三步是数据准备，第四五步是工程改造，第六步才需要内容团队入场。

## 常见问题解答

## 罗马尼亚语用拉丁字母，能不能直接套西班牙语的SEO流程？

字母表相同不代表词法相同。罗马尼亚语的定冠词接在词尾，一个名词至少四种写法，而西班牙语的冠词是独立的词，名词形态稳定得多。直接套流程，你的关键词表会漏掉带定冠词的那一大批查询，标题模板也会在中性名词上拼错形容词。语族相近能省的是词汇理解的成本，省不了形态处理的成本。建议把西班牙语流程里的选词和标题模板两步单独重做，其他环节可以复用。另外提醒一点，罗马尼亚语里有大量看起来像西班牙语但意思不同的词，直接凭语感理解词义在这门语言上翻车的概率相当高。

## ș和ț的两套码位到底该怎么统一？

目标形态是带逗号的U+0219和U+021B，这是罗马尼亚语的正确字符。处理顺序是先做字符映射把带下加符的U+015F和U+0163换掉，再做NFC规范化把组合序列合成预组合字符。两步顺序不能反，因为规范化不会跨字符做转换。数据库、搜索索引、URL生成器三个地方都要跑同一套流程。做完之后加一条发布前检查，把下加符版本列进告警，防止新内容再混进来。如果站上已经积累了大量混存数据，转换前务必先做一次全量快照，因为字符映射是不可逆的，转错了没有原始数据就只能重新采集。

## 选词表要不要把带定冠词的形态也做成独立页面？

不要。带定冠词的形态是自然语言里的语法变体，不是独立的搜索意图，为它单独建页面会造成内部竞争。正确做法是让这些形态自然出现在正文、元描述和内链锚文本里，同时在站内搜索层面接一个词干器把它们归并到原形上。商品列表页用无冠词复数，详情页用无冠词单数，这两个形态才值得单独规划。唯一的例外是那些已经固化成专有名词的带冠词形态，比如某些品牌名或者行政区名，这类词本身就带着冠词，按普通词处理反而会出错。

## 用户不打变音符号，我是不是该把标题也写成不带变音的？

不该。标题按现行正字法写全，这是页面专业度的直接信号，本地用户对拼写错误相当敏感。不带变音的查询靠两条路接住：站内搜索加一层变音折叠，让两种输入都能命中；内容侧在FAQ的问句里自然使用较口语的写法。真实的输入分布不是全带和全不带的二分，而是短查询带得多、长查询带得少，所以变体覆盖要按查询长度分层考虑。还有一个折中做法是在页面上同时提供两种写法：标题按规范写，而商品的别名字段里存不带变音的版本，让站内搜索和结构化数据都能用上。

## î和â的旧拼法还需要覆盖吗？

需要，但只覆盖高频词。1993年之前受教育的用户手打时仍会用旧拼法，这批人的购买力通常还不低。做法是把受影响的高频词整理成同义词表，接到站内搜索里，不必为旧拼法单独建页面。正文和标题一律按现行规范写词中用â、词首词尾用î。受影响的词其实不多，整个品类里通常也就十几个，一次整理长期有效。整理这张表时可以顺手把两种拼法在你的站内搜索日志里的实际比例记下来，几年之后再看这个比例，能直观看出用户结构有没有变化。

## 摩尔多瓦市场值得单独做一套内容吗？

绝大多数情况下不值得。两边是同一门语言，书面语几乎可以完全共用，真正的差别在货币、物流和购买力这些非语言字段上。正确做法是内容共用一套，把价格、货币代码、配送时效和支付方式做成变量。只有当你在摩尔多瓦有独立仓储或者本地化服务时，才值得考虑做独立的地区版本。语言层面的重写成本在这一对上几乎为零，这是相当省事的一种情况。如果决定共用，记得把两个地区的语言标签分开写，这样搜索引擎至少知道你在服务两个市场，而内容维护成本几乎没有增加。

## 罗马尼亚语的字母排序为什么会让A-Z导航出错？

因为ă、â、î、ș、ț在字母表里各占独立位置，排在对应基础字母之后，而不是合并进去。用默认的字节顺序排序，这五个字母会全部跑到z之后，品牌墙和字母导航就会出现一个诡异的尾巴。解决办法是使用支持区域设置的排序规则，指定罗马尼亚语的排序定义。受影响的主要是三类页面：品牌列表、品类字母索引、地区或城市列表，这几类页面把排序结果直接印在页面上，错了一眼就能看出来。排序库选定之后还要写一个小测试用例，把五个变音字母和它们的基础字母打乱顺序丢进去排一遍，升级依赖时跑一次就能发现排序规则有没有被改掉。

## 权威参考资料



## 越南语SEO要接的是两拨人，一半打声调符号，另一半从来不打

- URL：https://zhangwenbao.com/vietnamese-seo-tone-marks-syllable-spacing-keyword.html
- 分类：小语种SEO
- 发布：2013-05-21  |  更新：2026-07-25
- 摘要：讲越南语SEO实战：带调与不带调两拨搜索行为怎么同时接住、声调标在哪个元音上的两套规范、三种输入方案带来的错误模式差异、音节分写为何不同于韩语分写法、组合与合成两种编码形式的统一、字母排序的三层比较。
- 关键词：关键词研究,内容本地化,小语种SEO

> **TLDR**：摘要：越南语的每个音节最多能带一个元音变体和一个声调符号，写全了信息密度极高。但真实的搜索行为里，有相当一批用户从来不打这些符号——手机输入法要多按几下，图省事就不打了。于是同一个词在搜索框里分成两拨字符串：带调的和不带调的，两拨都是真实需求。这篇讲清两拨人各占多少、词表该怎么双轨收、音节分写为什么会让复合概念散架、编码上那个能让匹配率归零的隐形坑，以及标题里该写哪一种。

> 摘要：越南语的每个音节最多能带一个元音变体和一个声调符号，写全了信息密度极高。但真实的搜索行为里，有相当一批用户从来不打这些符号——手机输入法要多按几下，图省事就不打了。于是同一个词在搜索框里分成两拨字符串：带调的和不带调的，两拨都是真实需求。这篇讲清两拨人各占多少、词表该怎么双轨收、音节分写为什么会让复合概念散架、编码上那个能让匹配率归零的隐形坑，以及标题里该写哪一种。

做户外运动装备的一个客户，主力是骑行头盔和公路车配件，东南亚第一站选了越南。理由很直接：骑行人口在涨，客单价扛得住，本地供给以低端为主，中高端有空档。

越南语内容外包给了本地团队，交付很规范，声调符号一个不落，读起来专业。上线三个月，产品页收录正常，站内搜索的匹配率却低得不像话。

日志一翻就明白了。用户搜进来的字符串，绝大多数一个声调符号都没有。而页面上写的每一个都带着符号。两边在语义上是同一个词，在字节层面完全对不上。

更麻烦的是，这不是用户偷懒的个别现象。日志里不带符号的查询占了将近一半，而且集中在移动端。

越南语这门语言的搜索侧，天然被劈成了两拨人。你的页面只服务了其中一拨。

## 越南语的声调符号到底有几层？

要分开数，因为它们是两套不同的东西，经常被混为一谈。

第一层是元音字母本身的变体。有几个元音字母带着固定的附加记号，这些记号不表示声调，它们参与构成一个独立的字母——去掉记号就是另一个字母，读音完全不同。

第二层才是声调符号，加在音节的主元音上，标记这个音节的调值。越南语有六个声调，其中一个不标符号，剩下五个各有一个记号。

所以一个音节最多能同时带两个记号：一个属于字母本身，一个属于声调。写全了字符很密，去掉之后就变成一个光秃秃的拉丁音节。

## 声调符号该标在哪个元音上，为什么同一个词会出现两种标法？

这是越南语里一个真实存在、却几乎没人跟外国团队讲清楚的分歧点，而它会直接产出两个不同的字符串。

当一个音节里有两个元音字母时，声调记号标在前一个还是后一个，有两套并行的规范。一套是较早的传统标法，倾向标在靠前的那个元音上；另一套是后来的标法，按音节结构规则决定落点，结果往往落在靠后的元音上。

两套都在用。教科书和一部分出版机构用其中一套，另一批媒体和大量民间写作用另一套，而输入法的默认设置也分两派。

后果是：一个完全规范书写的词，仍然可能有两种合法的字节序列。这跟打不打记号是两个独立的问题，叠加起来，同一个概念在搜索侧最多能分出四种形态。

## 这两套标法在实操上怎么处理？

展示层选定一套，全站统一，别混着来。选哪一套取决于你的目标人群偏正式还是偏日常，拿不准就跟着本地主流媒体走。

匹配层要把两套都收。做法跟处理不打记号一样：给索引再加一个归一字段，把两种标法折叠到同一个键上。

关键词表也要按这个逻辑扩一列。查量时两种标法都查，量相加。这一步经常被漏掉，因为两种写法在肉眼看来差别极小，很容易被当成同一个词。

顺带说一句，这类分歧只影响一部分音节结构，不是所有词都有两种标法。实际会受影响的词大概占品类表的一到两成，但它们往往正好是那些高频的双元音品类词。

## 为什么会有那么多人不打声调符号？

三个原因叠在一起。

输入成本。越南语的输入法通常要在字母后面追加一到两个按键来生成带记号的字符。搜一个三音节的词，可能要多按四五下。在手机上，这就是明显的摩擦。

习惯迁移。即时通讯和社交平台上不打符号早就是常态，年轻人打字快、上下文足，不打也读得懂。这个习惯直接带进了搜索框。

容错预期。用户知道搜索引擎大概率能懂，那就更没有动力去打全了。

这三条合起来，造成的结果是：不带符号的查询不是错误输入，是一种稳定的、成规模的、和带符号并行存在的搜索行为。你不能把它当成拼写错误来处理。

这个现象在带变音符号的语言里普遍存在，法语的重音符号打不打 (https://zhangwenbao.com/french-seo-accents-quebec-keyword-variants.html)那篇讲的是同一件事的温和版本。但两边的量级完全不同：法语的重音符号只出现在一部分词上，去掉之后大多数词还是原样；越南语这边，几乎每一个音节都可能带记号，全部去掉之后整篇文本的面貌都变了。

更关键的差别是规模。法语市场不打重音的查询是少数派，越南语这边接近一半，你没法把它当成边缘情况处理掉。

## 不带符号的查询占比大概是多少？

没有一个放之四海的数字，但可以给几条实测出来的规律。

移动端明显高于桌面端。桌面有实体键盘，输入摩擦小，打全的比例更高。

年轻用户高于年长用户。年长用户的输入习惯更接近书面规范。

短查询高于长查询。搜两个音节的词大家还愿意打全，搜一整句话时符号往往就全省了。

品类上也有分化：越接近日常口语的品类，不带符号的比例越高；越专业、越书面的品类，比例越低。骑行装备属于中间偏口语一侧。

## 那我的页面该写带符号还是不带符号的？

页面正文必须写带符号的完整形态，这一条没有商量余地。

理由不是SEO，是专业度。不打符号在聊天窗口里是随意，出现在一个卖东西的商业页面上就是不专业，越南用户对这一点的判断非常快。

而且不带符号的文本存在真正的歧义。同一串裸拉丁字母去掉记号之后，可能对应好几个完全不同的词，读一句话没问题，读一整页会很累。

所以答案是：展示层写全，匹配层双轨。这是这篇文章最核心的一条结论，后面所有技术动作都是围绕它展开的。

## 匹配层双轨具体怎么做？

核心动作是在索引时给每条记录额外生成一份去记号的形态，和原形态一起存进索引。

查询进来时同样做一次去记号处理，然后两个字段都查：带符号的查带符号字段，去了符号的查去记号字段。

这样带符号的用户和不带符号的用户都能命中，而且带符号的匹配精度更高，可以给它更高的权重，让精确输入的用户拿到更准的结果。

去记号的处理不要自己写字符映射表，用标准的字符分解形式来做——先把组合形态拆开，再把记号类的字符滤掉，剩下的就是基本拉丁字母。字符规范化的标准文档 (https://www.unicode.org/reports/tr15/)里定义了这几种分解与合成形式，照着用比手写映射稳。

## 越南语的输入法有几套，这会影响你拿到的数据吗？

会，而且影响的方式很隐蔽。

越南语常用的输入方案有三套，各自的按键约定完全不同：一套用普通字母做修饰键追加在后面，一套用数字键指定声调，还有一套用标点符号做记号。三套的键位逻辑互不相通。

对做SEO的实际影响主要在两处。

第一处是你的本地团队交付的文本。不同输入法在少数边缘字符上的产出可能落在不同的编码形式上，几个人协作时文本里就混进了两种字节序列，而肉眼完全看不出来。

第二处是用户的输入错误模式。用数字键指定声调那一套，误触数字会产出一个带错误声调的合法词；用字母做修饰键那一套，误触会产出一个多了字母的非词。两类错误在站内搜索里要用不同的容错策略处理——前者要靠同义词和相似度，后者靠编辑距离就够。

## 越南语字母表里没有的那几个拉丁字母怎么办？

越南语的字母表里没有四个常见的拉丁字母，它们不出现在本族词里。但你的页面上一定会有它们——品牌名、型号、单位、技术缩写，全靠这几个字母。

这会在三个地方产生摩擦。

字符白名单如果按越南语字母表配置，这四个字母会被当成异常字符过滤掉，型号直接被吃。这个坑很常见，因为按语言字母表配白名单听起来很合理。

排序和索引里，这几个字母的位置在越南语的排序规则下没有明确定义，不同实现的处理不一致，品牌索引页可能出现莫名其妙的排列。

用户输入端，越南语键盘布局下打这几个字母没有障碍，但在某些输入方案里它们本身就是修饰键，用户想打字母却触发了记号。这类查询在日志里表现为一批看不懂的字符串，别急着当成垃圾流量丢掉。

## 全大写的标题里，记号该怎么处理？

照常保留，一个都不能省，这一点跟希腊语正好相反。

越南语的大写形态里，元音的附加记号和声调记号都保留，只是字母本身变成大写。整套大写形态在字体里是完整存在的，不需要做任何降级。

会出问题的是排版。大写字母本身更高，上面还要叠一到两层记号，行高不够的话记号会被上一行压住或者被容器裁掉。这个在导航栏、按钮、促销条幅这些行高卡得紧的位置最容易翻车。

还有一个技术细节：大小写转换函数要确认它对带记号的字符处理正确。有些实现只处理基本拉丁字母，带记号的字符原样返回，产出一个大小写混杂的标题。转换之后抽样看一眼，成本很低。

## 字母排序规则跟英语差在哪？

差在两处，都会让直接套用默认排序的品牌索引页出错。

第一处是带附加记号的元音字母。它们在越南语的字母表里是独立字母，有自己的排序位置，紧跟在对应的基本字母之后，而不是被当成基本字母的变体。

第二处是声调。同一个字母的不同声调形态之间也有固定的先后顺序，这一层排序在基本字母比较完之后才生效。

结果是越南语的排序是一个多层比较：先比基本字母，再比字母变体，最后比声调。默认的通用排序规则只做第一层，排出来的顺序在越南用户看来是乱的。

解决办法跟其他语言一样，在数据库或查询层指定越南语的排序规则。语言环境排序规则的规范文档 (https://www.unicode.org/reports/tr35/tr35-collation.html)里有越南语的排序表定义，配置之前对着确认一遍比试错快。

## 搜索引擎的拼写纠错能不能替你兜底？

能兜一部分，但不能当成方案，理由有三条。

第一，纠错发生在引擎那一侧，它决定给不带记号的查询匹配哪些结果，这个过程你无法干预也无法预测。押注在一个黑盒上不是策略。

第二，纠错在竞争激烈的词上帮不了你。当同一个查询有一批页面都能匹配时，排序看的是其他因素，而你的页面如果只有一种形态，在相关性上就是弱势的一方。

第三也是最实际的：站内搜索没有人替你兜底。用户在你自己的搜索框里敲不带记号的词，如果你没做双轨，就是实打实的零结果，跟外部引擎的能力毫无关系。而站内搜索的零结果直接对应流失。

所以正确的心态是：外部引擎的容错当成额外收益，自己该做的一样不能少。

## 关键词表要不要也做两份？

不做两份表，做一份表两列。

结构上和处理其他一词多形语言的思路一致：一行一个概念，第一列是带符号的规范形态，第二列是去记号形态，第三列可以放这两种形态各自的搜索量。

查量的时候两列都要查。工具通常把它们当成两个不同的词，各给一个数字，你要做的是把两个数字加起来看真实需求。

这个动作会明显改变品类的优先级排序。有些词单看带符号的量平平无奇，加上不带符号的那一半之后会跳好几位。

## 这跟希腊语那种拉丁转写是同一回事吗？

不是，区别很重要，混淆了会用错方法。

希腊语用拉丁字母打本族词 (https://zhangwenbao.com/greek-seo-greeklish-latin-transliteration-coverage.html)那种情况，是换了一套字母系统——用户拿拉丁字母去近似希腊字母的读音，映射关系不唯一，同一个希腊词能转出好几种拉丁写法，得靠转写规则去穷举。

越南语这边不换字母系统。越南语本来就用拉丁字母，不打符号只是把附加记号删掉，字母序列一个不变。去记号的结果是唯一的、可计算的、可逆推的。

这个差别决定了技术方案完全不同：希腊语那边需要一张转写映射表加人工筛选，越南语这边一个标准的字符分解函数就够了。越南语的问题比它看起来简单。

## 那越南语的难点在哪里？

在音节分写，以及由它带来的边界模糊。

越南语的书写单位是音节，音节之间一律用空格分开。一个双音节的词，写出来是两个被空格隔开的部分。

所以从字符串的角度看，越南语的词和词组之间没有形式上的分界——都是若干个空格分隔的音节，你看不出哪两个音节属于同一个词。

这跟中文读者的直觉正好相反。中文是不分词但字紧挨着，越南语是分音节而且音节之间必须有空格。结果是同一个概念在越南语里看起来像好几个独立的词。

## 音节分写会造成什么实际问题？

四个，按严重程度排。

词组匹配失准。搜索引擎按空格切分之后，一个双音节词变成两个token，跟另一个词的某个音节碰巧组合起来也能匹配，产出不相关的结果。

标题截断难看。截断按字符数走，很容易正好切在一个词的两个音节之间，剩下半个词——而半个音节在越南语里往往是另一个有意义的词，读起来很怪。

URL转写变长。每个音节转写出来都要一个连字符，一个四音节的品类词在URL里就是四段，路径迅速变长。

关键词工具误判。工具按空格算词数，一个越南语的双音节词被算成两个词的短语，长尾判定和竞争度估算都会偏。

## 跟韩语的分写法是同一个问题吗？

形式相似，性质不同，这一点值得说清楚。

韩语的分写法 (https://zhangwenbao.com/korean-seo-spacing-particles-keyword-research.html)是按词分的：空格落在词与词之间，规则复杂但目标明确——把词分开。分写规则出错会改变句子的意思，所以它是一个正确性问题。

越南语的空格是按音节分的：不管两个音节属不属于同一个词，中间都有空格。这不是规则复杂，这是根本没有词级的形式边界。

后果的方向也不同。韩语的坑是空格打错等于换了词；越南语的坑是空格永远是对的，但它不告诉你词到哪儿结束。

前者要解决的是准确率，后者要解决的是切分。两套问题两套办法，别把韩语那套分写规则搬过来。

## 词的边界怎么在技术上处理？

靠词典，不靠规则。

越南语的分词组件本质上是在做词典匹配加消歧：拿一张多音节词的词典去扫描音节序列，把能组成词的相邻音节合并起来，遇到多种切法时按频率或上下文选一种。

对做电商内容的团队来说，不需要自己实现这套东西。需要做的是把自己的品类词典喂进去——你的商品名、品类名、属性值里有大量通用词典没有的多音节词，不喂进去就会被切碎。

这份自定义词典的价值远超它的制作成本。两三百个词条，一天能整理完，站内搜索的准确率能上一个台阶。

## 短语查询要不要加引号约束？

在站内搜索的实现层要加等价的约束，在面向用户的界面上不要教用户加引号。

原因是越南语用户搜多音节词时不会加任何标记，就是几个音节直接敲进去。你的搜索实现要能理解“这几个相邻音节很可能是一个词”，而不是要求用户来标注。

实现上的常见做法是给相邻token的组合加一个位置约束，让顺序相邻的匹配得分显著高于分散匹配。这样即便切分不完美，排序也能把正确结果推上来。

这个调整对越南语站的站内搜索体验提升是所有优化里最明显的一个，而且不需要引入额外的组件。

## 编码上有哪个坑会让匹配率直接归零？

有，而且它很隐蔽：同一个带记号的字符，在编码上可能是一个码位，也可能是基本字母加一个组合记号，共两三个码位。

屏幕上看起来完全一样，字节层面完全不同。字符串比较、索引匹配、数据库唯一约束，全都会把它们当成两个不同的东西。

越南语是这个问题的重灾区，因为它的字符大量落在需要组合的那一类上，而不同来源的数据用的形式往往不一样——本地团队用的输入法产出一种，你从供应商拿的数据表是另一种，用户浏览器提交上来的可能是第三种。

症状很典型：肉眼核对一模一样的两个词，程序判定不相等，然后你开始怀疑人生。

## 这个编码坑具体怎么解决？

一句话：在所有入口做统一的规范化，选定一种形式，全站只用这一种。

入口包括：数据导入、表单提交、接口接收、爬取的外部数据、以及内容编辑器的保存动作。任何一个入口漏掉，都会往库里放进另一种形式的数据。

选哪一种形式取决于你的技术栈，两种都能工作，关键是别混。合成形式的字符串更短，比较更快，是更常见的选择。

已经有历史数据的话，先跑一遍全量扫描统计混杂比例。这个数字通常比预期的高，因为它从来不会在页面上表现出来，只会表现为一个说不清原因的低匹配率。

## 越南语用过哪些旧编码，会不会遇到历史数据？

会，尤其是接手老站或者从本地合作方拿存量数据的时候。

在统一编码普及之前，越南语有过好几套互不兼容的本地编码方案，各自用不同的方式把带记号的字符塞进有限的码位空间里。当年为越南语制定的编码约定 (https://www.rfc-editor.org/rfc/rfc1456)就是其中一套的正式文档，从里面能看出这些方案是怎么处理记号叠加的。

这些旧编码的数据如果不做转换直接入库，页面上会是一片乱码，这个反而好发现。

难发现的是转换做了但做得不完整——大部分字符对了，某几个记号组合错了。这类数据在抽查时很容易漏，建议转换后跑一次字符白名单扫描，把不在预期集合里的码位全部列出来人工过一遍。

这套排查动作跟希伯来语那边处理元音标记 (https://zhangwenbao.com/hebrew-seo-unvocalized-script-root-letters-keyword.html)的思路是一样的：非拉丁或带组合记号的语言，数据入库前必须先扫一遍字符构成，不能等页面出问题了再回头查。

区别在于扫描的目标。希伯来语那边是要把不该有的标记剥掉，因为用户搜的是不带标记的形态；越南语这边是要把记号统一成同一种编码形式保留下来，因为记号本身是词的一部分，剥掉就变成另一个词了。方向相反，动作相似。

## 标题里该写带符号还是不带符号的形态？

写带符号的，一个都不能省。

标题是最能体现专业度的位置，也是用户判断这个站靠不靠谱的第一眼。不带符号的标题在越南用户看来就是随手打的。

至于怎么接住不带符号的查询，靠的是匹配层的双轨，不是靠在标题里写不规范的形态。这两件事必须分开。

更不要在标题里同时写两种形态。那既不通顺又像在堆词，属于两头不讨好的做法。

## 标题长度上要注意什么？

音节分写会让越南语标题的字符数比中文长很多，一个概念动辄四五个音节加空格。

再加上记号占的字符位置，同样信息量的越南语标题在字符数上是相当膨胀的。

实际做法是把截断位置控制在音节边界上，也就是空格处，别按固定字符数硬切。切在音节中间产出的残片，在越南语里可能恰好是另一个词，效果比截断本身更糟。

还有一个小细节：越南语的品类词经常以一个通用音节开头，几个不同品类的标题前几个字符完全一样。排在搜索结果里会显得雷同，把区分度高的词往前挪一挪很有必要。

## URL用带符号的形态还是转写？

用去掉记号的拉丁转写，这个基本没有争议。

越南语的URL如果保留记号，编码之后是一长串转义序列，分享到即时通讯里非常难看，而越南市场的分享行为高度集中在即时通讯上。

去记号之后是干净的基本拉丁字母，音节之间用连字符连接，可读性好，也和用户不打符号的输入习惯天然一致。

要注意的是路径长度。四五个音节加连字符，再加上品牌和型号，URL很容易过长。建议在品类词层面就做取舍，只保留区分度最高的那几个音节，别把完整商品名塞进路径。

## 内链锚文本要用哪种形态？

用带符号的规范形态，跟正文保持一致。

锚文本是给人读的，也是给搜索引擎理解目标页主题用的，两个用途都要求规范书写。

不带符号的形态只活在两个地方：URL路径和匹配层的索引字段。这两个地方用户都不直接阅读，所以不影响观感。

把这条界线画清楚，团队里就不会再有人纠结哪里该打哪里不该打——凡是给人看的地方全打，凡是给机器匹配的地方双轨。

## 越南语有没有格变化或者复杂词形？

没有，这是这门语言最省心的地方。

越南语是分析型语言，词本身不变形，没有格、没有性、没有数的屈折，动词也不按时态变位。语法关系靠语序和虚词表达。

所以做过俄语、波兰语、芬兰语那种一个名词几十种形态的市场之后，来做越南语会觉得词表工作轻松得不真实——因为它确实轻松，一个词就是一个形态。

省下来的力气正好用在别的地方：符号双轨、音节切分、编码统一，这三件事才是越南语的成本所在。

## 那越南语的词表规模会不会很小？

词形数量小，但概念数量不小，而且有一个别的语言没有的膨胀源：同一个概念常常有一个本族说法和一个外来说法并存。

越南语历史上从汉语借入了大量词汇，近代又从法语和英语借入了一批，很多概念因此有两三个可用的词。

这几个词的语体色彩不同：借自汉语的往往更书面、更正式，本族词更口语，近代外来词多用于技术和时尚领域。

而用户在搜索时选哪一个，取决于场景。查规格参数时倾向用正式词，描述使用需求时倾向用口语词。两个都要收，而且要判断哪个放标题、哪个放正文。

## 本族词和借词该怎么分工？

一条经验规则：标题和分类名用识别度最高的那一个，正文里两个都自然出现。

识别度最高的通常不是最正式的那个，而是市场上流通最广的那个。判断方法还是看本地大型电商的分类树——它们的命名是被流量反复验证过的。

还有一个信号是本地内容社区。用户在论坛和问答里自发使用哪个词，那就是需求侧的真实表达，做长尾内容时优先用它。

两个词都收进站内搜索的同义词表，这个成本极低，但能挡掉一批零结果。

## 南北方言差异需要单独处理吗？

需要留意，但优先级低于符号和切分这两件事。

越南南北在发音上差异明显，在书写上差异小得多，标准书面语是统一的。所以对文字内容的影响远不如口语层面大。

真正有影响的是一小批日常词汇的地区偏好，比如某些食物、容器、日常用品的叫法南北不同。这类词如果正好落在你的品类里，需要单独处理。

骑行装备这类现代品类受影响很小，大部分词是全国通用的技术词或外来词。但如果做的是食品、家居、母婴这类高度生活化的品类，就要认真做一遍地区词表。

## 数字、日期和货币格式怎么写？

数字用点做千位分隔符、逗号做小数点，跟中文习惯正好相反，这是最容易被前端配置错的一处。

日期是日月年顺序。

货币的写法有个特点：单位数值很大，价格数字通常有六到七位，展示时几乎一定要加千位分隔符，否则完全没法读。而分隔符用错了会让价格看起来差一千倍。

这一条我建议单独列进上线检查清单。价格显示错误是所有本地化事故里后果最直接的一类，用户不会给你解释的机会。

## 字符集与字体上要注意什么？

越南语的字符分布在几个不同的码位区块里，基本拉丁字母之外，带记号的组合字符集中在两个扩展区。其中一个扩展区专门收双记号叠加的形态，做字符白名单时要把这几个区块都覆盖到，只放基本拉丁字母进白名单是最常见的漏配。

字体上要实测。不是所有字体都完整覆盖越南语的字符集，尤其是那些同时带元音记号和声调记号的字符，缺字形的话页面上会出现空白方框。

测试方法很简单：造一个包含所有六个声调乘以所有带记号元音的样例串，在目标字体下渲染一遍，肉眼过一遍有没有方框。这个动作十分钟，能避免上线后的尴尬。

还有一个细节：有些字体虽然有字形，但双记号叠加时的排版很挤，记号会碰在一起。这个在小字号下尤其明显，正文字号定下来之后要在真机上看一眼。

## 关键词工具在越南语上能用到什么程度？

比大多数小语种好用，因为越南的互联网人口基数大，长尾词返回零的情况没有欧洲小语种那么普遍。

但要注意两件事。第一是前面说的双形态问题，工具不会替你合并带符号和不带符号的量，得自己加。

第二是音节分写导致的词数误判。工具按空格数判断这是一个词还是一个短语，越南语的双音节词会被算成两个词，于是本来是核心词的东西被归到长尾里，竞争度估算也偏低。

用法上的调整是：别看工具给的词数分类，自己按概念数来判断长尾深度。一个概念就是一个词，不管它写出来占几个音节。

## 本地引擎和平台生态要单独做吗？

搜索引擎层面不需要。越南的搜索市场集中度高，不存在需要单独适配的体量级本土引擎，引擎层的打法差异属于另一个话题范畴，这篇不展开。

但有一件事必须提：越南的商业流量高度集中在几个本地电商平台和社交平台上，站外的存在感比欧洲市场重要得多。

这属于渠道策略，不影响语言层的结论，但它会影响你的资源分配——在越南做独立站，语言层做对了只是拿到入场券，流量结构和欧洲市场很不一样。

语言层的工作在这些渠道上同样有用：平台上的商品标题一样面临符号双轨和音节切分的问题，一份词表可以两边共用。

## 越南语的星期表达为什么容易差一位？

因为越南语的星期名是按序数命名的，而起点不是星期一。

星期日是一周的第一天，星期一因此是“第二天”，星期二是“第三天”，依此类推到星期六。也就是说，星期名里的那个数字，永远比中文习惯的星期数大一。

这个偏移会在几个地方咬人：配送时效的说明、营业时间表、活动倒计时、订单状态的预计送达日。翻译时如果译者按数字对应，或者你用了机翻，很容易整体错开一天。

更麻烦的是它错得很自然——译文语法完全正确，读起来也通顺，只有懂的人才看得出日期错了。建议把所有含星期的文案单独抽出来做一轮专项校对，别指望在通读全文时能发现。

顺带说一句，星期六和星期日的叫法不走这个序数规律，它们各有专名，所以自动化处理时更容易出错，因为规律在末尾断了。

## 人名和称呼会影响哪些字段？

影响三处：表单字段、客服文案、以及邮件与推送的称呼。

越南人名的书写顺序是姓在前、名在后，中间常有一个中间名。而日常称呼用的是最后那个字，也就是名，不是姓——这跟中文的习惯正好相反。

后果是，如果你的邮件模板按国际惯例取姓来称呼，越南用户收到的是一个相当疏远甚至有点怪的叫法。正确做法是取名字的最后一段。

表单这边，把姓名拆成姓和名两个字段在越南是可行的，但中间名的处理要留余地，字段长度别卡太紧。更省事的做法是给一个完整姓名字段，另外单独存一个用于称呼的短字段，让用户自己填。

还有一层：越南语的称呼词按辈分和年龄区分，用错了会显得失礼。这一层交给本地文案处理，别自己发挥，也别用机翻。

## 地址字段和行政区划该怎么设计？

越南的行政层级和邮编体系跟欧洲市场差异明显，套用通用模板会在结账页丢单。

地址由省级、区级、坊级三层加街道门牌组成，用户填写时的习惯顺序是从小到大——先门牌街道，再往上走，跟中文习惯一致，跟欧美表单的常见顺序相反。

所以省市区的下拉选择器要按本地顺序排布，而且三级要联动。用户在一个乱序的地址表单前的耐心非常有限。

邮编在越南的使用率不如欧洲高，很多用户不记得自己的邮编，所以别把它设成必填，或者提供按行政区自动带出的能力。

还有一条实际经验：地址字段里必然出现带记号的地名，字符白名单和后端存储的字符集都要覆盖到，否则地址存进去是乱码，配送标签打出来就是废纸。

## 南北口音会不会影响语音搜索？

会，而且这是南北差异真正有杀伤力的地方——比文字层面大得多。

前面说过南北的书写差异小，但发音差异明显，某些声调在南方口音里合并了，某些辅音的读法完全不同。

对语音识别的后果是：同一句话，南方用户说出来和北方用户说出来，识别结果可能落到不同的文字上。而识别错的那部分，你的页面再怎么优化也接不住。

这件事在内容层没法解决，但它会影响你的判断——如果你的品类里语音搜索占比高，就该在同义词表里把因口音混淆而产生的近似形态也收进去，站内搜索至少能接住一部分。

另外，做视频和音频内容时要选口音。选哪一种取决于你的主要市场在南还是在北，两地用户对对方口音的接受度不错，但对配音里出现的口音是有感知的。

## 越南语内容的语气和信任元素有什么讲究？

语气上比欧洲市场热络一些，但比想象的克制。夸张的绝对化表述在这个市场同样会降低可信度，尤其在客单价偏高的品类上。

信任元素这边有几条本地特征。用户对“能不能货到付款”的关注度很高，即便最终选了线上支付，页面上有没有这个选项也会影响信任判断。

其次是真人可联系的程度。本地用户习惯在下单前跟卖家确认，客服入口的可见度和响应速度对转化的影响比欧洲市场大。

第三是社会证明。评价、实拍图、使用视频在越南市场的权重高于欧洲，产品页上有没有这些内容，直接决定用户停留还是离开。

这几条都不是语言问题，但它们决定了你的越南语内容该写什么。把力气全花在词形和切分上、却不管内容里说了什么，是本地化最常见的一种走偏。

## 越南语的搜索长尾能做到多深？

比大多数小语种深，因为互联网人口基数大，但深度分布跟欧洲市场不一样。

需求侧的长尾主要集中在两类：使用场景与适配问题（这个装备配我这辆车行不行、这个尺寸适合我这个身高吗），以及真伪与质量（怎么辨别正品、这个价格合不合理）。

第二类在越南市场的量特别大，原因是市场上仿品流通较多，用户在下单前的验证需求比欧洲市场强烈得多。

这对内容策略是个明确的机会：做正品辨别、参数解读、避坑指南这类内容，在越南能拿到相当可观的自然流量，而且这批流量的转化意图很强——会花时间查真伪的人是准备买的人。

操作上把这类内容放在品类页的下游，用内链把流量导向具体产品页，转化路径比直接堆产品页短。

## 母语审校要盯哪几件事？

五条，前三条是越南语特有的。

符号完整性：所有展示文本的记号有没有打全，有没有漏掉某个音节的声调。这一条用程序辅助更高效——扫描全站文本，找出完全不带任何记号的越南语句子。

音节切分：品类词有没有被换行或截断切在音节中间。

词的选择：本族词、汉语借词、近代外来词有没有用在合适的语体位置上。

后两条是通用的：价格与数字格式是否正确、整体读起来像不像机器翻译。

## 上线之后先看哪几个指标？

三个，都能在两个月内给出明确信号。

站内搜索的零结果率，并且要按“查询是否带记号”分组看。如果不带记号那一组的零结果率明显更高，说明双轨匹配没配好，这是最优先要修的。

移动端与桌面端的搜索行为差异。移动端不带记号的比例应该显著更高，如果两边差不多，多半是你的日志采集把记号吃掉了，数据本身不可信。

价格页与规格页的跳出。这个指标暴露的是格式配置错误，尤其是千位分隔符。

保哥的经验是，越南语项目八成的问题都能被第一个指标照出来，而且修复动作明确——补索引字段，不需要改内容。

## 一份可以照着走的越南语启动清单

准备阶段做三件事：词表按概念组织，每行同时记带记号形态与去记号形态；整理一份两三百条的自定义品类词典准备喂给分词；把本族词与借词的语体分工标注清楚。

技术阶段做四件事：全部入口做统一的字符规范化并选定一种形式；索引层给每条记录额外存一份去记号形态；查询时双字段匹配并给带记号形态更高权重；字符白名单覆盖全部相关码位区块，字体缺字形先实测。

内容阶段守两条：所有给人看的地方一律写全记号，URL和索引字段用去记号形态；截断一律落在音节边界上。

格式阶段单独核一遍价格显示，千位分隔符和小数点跟中文习惯相反，这是最容易出大事故的一处。

最后一句提醒。越南语的词形几乎不变，这让它在小语种里显得格外友好，但省下来的力气必须投到符号双轨和音节切分上去。把这两件事做扎实，剩下的部分确实比大多数小语种轻松。

## 常见问题解答

## 用户不打声调符号，是不是可以把页面也写成不带符号的？

绝对不行，这是最常见也最致命的误解。页面正文必须写带符号的完整形态，理由不是SEO而是专业度——不打符号在聊天窗口里是随意，出现在商业页面上就是不专业，越南用户对这一点的判断非常快，而且不带符号的长文本存在真正的歧义，同一串裸拉丁字母可能对应好几个不同的词，读一句话没问题读一整页会很累。正确的结构是展示层写全、匹配层双轨：索引时给每条记录额外生成一份去记号的形态和原形态一起存进索引，查询进来时同样做一次去记号处理，然后两个字段都查，带符号的匹配给更高权重，让精确输入的用户拿到更准的结果。这样两拨用户都能命中，而页面本身保持规范。去记号的处理不要自己写字符映射表，用标准的字符分解形式做——先把组合形态拆开再滤掉记号类字符，剩下的就是基本拉丁字母，照标准来比手写映射稳得多。

## 同一个词为什么会有两种合法的声调标法？

因为当一个音节里有两个元音字母时，声调记号标在前一个还是后一个存在两套并行的规范。一套是较早的传统标法，倾向标在靠前的元音上；另一套按音节结构规则决定落点，往往落在靠后的元音上。两套都在用，教科书和一部分出版机构用其中一套，另一批媒体和大量民间写作用另一套，输入法的默认设置也分两派。后果是一个完全规范书写的词仍然可能有两种合法的字节序列，这跟打不打记号是两个独立的问题，叠加起来同一个概念在搜索侧最多能分出四种形态。实操上展示层选定一套全站统一，拿不准就跟本地主流媒体走；匹配层把两套都收，给索引加一个归一字段折叠到同一个键上；关键词表扩一列，两种标法都查量并相加。这一步经常被漏掉，因为两种写法肉眼差别极小很容易被当成同一个词。实际受影响的词大概占品类表的一到两成，但往往正好是高频的双元音品类词。

## 越南语的音节分写跟韩语的分写法是同一个问题吗？

形式相似性质完全不同。韩语的分写法是按词分的，空格落在词与词之间，规则复杂但目标明确就是把词分开，分写规则出错会改变句子意思，所以那是一个正确性问题。越南语的空格是按音节分的，不管两个音节属不属于同一个词中间都有空格，这不是规则复杂，是根本没有词级的形式边界。后果的方向也不同：韩语的坑是空格打错等于换了词，越南语的坑是空格永远是对的但它不告诉你词到哪儿结束。前者要解决准确率，后者要解决切分，两套问题两套办法，别把韩语那套分写规则搬过来。越南语的实际影响有四个：词组匹配失准、标题截断切在音节中间产出半个词、URL转写变长、关键词工具按空格算词数导致长尾判定和竞争度估算全偏。解决靠词典而不是规则，而且不用自己实现分词，只要把自己的品类词典喂进现成组件里就够，两三百个词条一天能整理完。

## 那个能让匹配率归零的编码坑到底是什么？

同一个带记号的字符，在编码上可能是一个码位，也可能是基本字母加一个组合记号共两三个码位。屏幕上看起来完全一样，字节层面完全不同，字符串比较、索引匹配、数据库唯一约束全都会把它们当成两个不同的东西。越南语是这个问题的重灾区，因为它的字符大量落在需要组合的那一类上，而不同来源的数据用的形式往往不一样：本地团队的输入法产出一种，供应商数据表是另一种，用户浏览器提交的可能是第三种。症状很典型，肉眼核对一模一样的两个词程序判定不相等。解决办法只有一句话：在所有入口做统一的规范化，选定一种形式全站只用这一种。入口包括数据导入、表单提交、接口接收、外部抓取和编辑器保存，漏掉任何一个都会往库里放进另一种形式。已有历史数据的先跑全量扫描统计混杂比例，这个数字通常比预期高，因为它从来不在页面上表现出来，只表现为一个说不清原因的低匹配率。

## 搜索引擎自己的拼写纠错能不能替我兜底？

能兜一部分但不能当成方案，理由有三条。第一，纠错发生在引擎那一侧，它决定给不带记号的查询匹配哪些结果，这个过程你无法干预也无法预测，押注在一个黑盒上不是策略。第二，纠错在竞争激烈的词上帮不了你，当同一个查询有一批页面都能匹配时排序看的是其他因素，而你的页面如果只有一种形态，在相关性上就是弱势的一方。第三也是最实际的：站内搜索没有人替你兜底，用户在你自己的搜索框里敲不带记号的词，如果没做双轨就是实打实的零结果，跟外部引擎的能力毫无关系，而站内搜索的零结果直接对应流失。所以正确的心态是把外部引擎的容错当成额外收益，自己该做的一样不能少。还要补一句：三种输入方案带来的用户错误模式不同，用数字键指定声调那一套误触会产出带错误声调的合法词，用字母做修饰键那一套误触会产出多了字母的非词，前者要靠同义词和相似度处理，后者靠编辑距离就够。

## 越南语没有词形变化，是不是词表工作会很轻松？

词形数量确实小，越南语是分析型语言，词本身不变形，没有格、没有性、没有数的屈折，动词也不按时态变位，语法关系靠语序和虚词表达，所以做过俄语波兰语芬兰语那种一个名词几十种形态的市场之后来做越南语会觉得轻松得不真实。但概念数量不小，而且有一个别的语言没有的膨胀源：同一个概念常常有一个本族说法和一个外来说法并存。越南语历史上从汉语借入了大量词汇，近代又从法语和英语借入一批，很多概念因此有两三个可用的词，语体色彩不同——借自汉语的往往更书面正式，本族词更口语，近代外来词多用于技术和时尚领域。用户搜索时选哪一个取决于场景，查规格参数时倾向正式词，描述使用需求时倾向口语词。分工规则是标题和分类名用识别度最高的那一个，正文里两个都自然出现，全部收进站内搜索同义词表。识别度最高的通常不是最正式的，判断方法是看本地大型电商的分类树。

## 价格和数字格式为什么要单独列进检查清单？

因为它是所有本地化事故里后果最直接的一类，而且越南语这边特别容易出事。数字格式用点做千位分隔符、逗号做小数点，跟中文习惯正好相反，这是前端配置最容易搞错的一处。更要命的是越南的货币单位数值很大，价格数字通常有六到七位，展示时几乎一定要加千位分隔符否则完全没法读，而分隔符用错了会让价格看起来差一千倍——用户看到一个离谱的价格不会给你解释的机会，直接关页面。日期是日月年顺序这一条相对不容易出事，但也要核。建议的做法是把价格显示单独列一条上线检查项，在真机上用真实商品数据看一遍，尤其是那些价格位数不同的商品，六位数和七位数的显示都要看到。另外促销页上的折扣计算、满额门槛这类衍生数字也要一起核，它们经常走的是另一套格式化逻辑。

## 权威参考资料



## 芬兰语SEO的十五个格只是开胃菜，真正难住关键词工具的是词干自己也会变

- URL：https://zhangwenbao.com/finnish-seo-fifteen-cases-consonant-gradation-keyword.html
- 分类：小语种SEO
- 发布：2012-11-13  |  更新：2026-07-25
- 摘要：讲芬兰语SEO实战：十五个格该处理哪十个、部分格为什么高频、词干交替怎么让词干还原失效、形态分析器与词干还原的分工、元音和谐的两套后缀、复合词前段的主格与属格之分、变音字母排在字母表最后的排序坑、变体收录到八个封顶。
- 关键词：关键词研究,内容本地化,小语种SEO

> **TLDR**：摘要：芬兰语的十五个格常被拿来吓人，但它其实是可数、可穷举、可以写进字典的。真正让关键词工作失控的是另一件事：变格的时候词干里的辅音会跟着改，k、p、t这三个音在强弱两级之间来回跳，同一个词能给出两个不同的词根。词根一分裂，词干还原就接不住，工具报的数字也就不能信。这篇讲清楚哪些格要处理、词干交替怎么判、变体收录到什么程度够用，以及标题模板怎么彻底绕开变格计算。

> 摘要：芬兰语的十五个格常被拿来吓人，但它其实是可数、可穷举、可以写进字典的。真正让关键词工作失控的是另一件事：变格的时候词干里的辅音会跟着改，k、p、t这三个音在强弱两级之间来回跳，同一个词能给出两个不同的词根。词根一分裂，词干还原就接不住，工具报的数字也就不能信。这篇讲清楚哪些格要处理、词干交替怎么判、变体收录到什么程度够用，以及标题模板怎么彻底绕开变格计算。

一家做宠物智能硬件的品牌，两条主线：自动喂食器和带定位功能的项圈。北欧几个市场里瑞典先跑起来了，接着看芬兰——人口不多，但养宠比例高、客单价扛得住、线上支付习惯成熟，看起来是个干净的市场。

词表交给了一位芬兰母语的自由译者。交付很快，两百多个词，形态标注得整整齐齐。问题出在把词表接进系统之后。

站内搜索的匹配率低得离谱。用户搜ruokinta-automaatin，库里存的是ruokinta-automaatti，两者只差最后两个字母，可搜索组件把它们判成了两个词。同样的事在panta和pannan之间又发生了一次。

不是格的问题——格只改词尾，改词尾的语言到处都是。问题是这门语言在改词尾的同时，把词干中间的辅音也改了。tt变成了t，nt变成了nn，而所有按词尾做归一的逻辑，对词干中间的变化一律无感。

## 十五个格听着吓人，实际要处理几个？

十五这个数字是真的，但它包含了几个基本只出现在书面语和固定短语里的格。做电商内容，需要认真对待的大约是十个。

主格是词典形态，属格表示所属，部分格表示不定量，这三个占了绝大部分出现频率。加上六个表示位置关系的格，九个就覆盖了日常表达的绝大多数场景。

剩下几个用得很少。缺格表示没有某物，共格表示带着某物，工具格几乎只活在固定搭配里，做词表时可以直接跳过。

所以第一件要做的事就是给自己减负：把十五个格砍成十个，其中真正会出现在搜索查询里的通常只有三四个。恐惧感一半来自那个数字本身。

## 芬兰语为什么没有介词？

因为介词的活全被格接管了。英语里要用介词表达的在里面、从里面出来、到上面去这些关系，芬兰语直接改词尾。

房子是talo，在房子里是talossa，从房子里出来是talosta，进到房子里是taloon。三个概念，三个词尾，没有任何独立的介词。

这对关键词研究的直接影响是词数变少而词变长。英语里三个词的查询，芬兰语可能是一个词。你的最小匹配单元、你的标题长度预算、你的分词逻辑，全都要按这个前提重新算。

顺便说，芬兰语确实有后置词，跟在名词后面表达更精细的关系，但它们不承担基础的位置关系，也不改变上面这个结论。

## 六个位置格是怎么分工的？

分成内部和外部两个系列，每个系列三个，各管进入、停留、离开三种状态。

内部系列表达在某物内部的关系，词尾分别是表示在里面、从里面、到里面的三套。外部系列表达在某物表面或者附近的关系，另外三套词尾。

这个区分不只是空间上的。芬兰语用外部系列表达拥有关系，狗有一个项圈这句话，用的是狗加上外部系列的在上面那个格，字面上像是项圈在狗身上。

外部系列还兼任工具的意思。用手机看位置这个表达里，手机要用外部系列的词尾。这对写产品说明和使用场景的文案是高频需求，模板里得留好位置。

## 部分格为什么出现频率最高？

因为它管的事最多：不定量、部分、未完成、否定、数量表达之后的名词，还有一大批动词强制要求的宾语形态。

买猫粮这个动作里，猫粮通常用部分格，因为你买的是一些猫粮而不是全世界的猫粮。这个逻辑在商品搜索里出现得极其频繁。

结果是部分格在真实查询里的出现率高于很多人的直觉。如果你的词表只收录了主格，那些以部分格形态打进来的查询会全部落空。

更麻烦的是部分格的词尾有好几种，取决于词的结构和长度。这不是可以靠一条规则推出来的东西，还是得逐词查。

## 词干交替是什么，为什么它比格更麻烦？

词干交替指的是k、p、t这三个辅音在词形变化时会在两种形式之间切换，语法上叫强级和弱级。

举几个本案例里的实例。自动喂食器这个词以双t收尾，变成属格时双t变成单t。项圈那个词的词干里有nt，变属格时nt变成nn。食物那个词的词干里有k，变属格时k直接消失。

价格这个词也一样，主格里是nt，属格里变成nn。便宜这个形容词更夸张，主格里是p，属格里变成v。

为什么它比格更麻烦？因为格只动词尾，而所有的搜索匹配逻辑、模糊匹配、前缀匹配都是围绕着词的开头相同这个假设建的。词干交替破坏的正是这个假设——两个形态的开头几个字符相同，中间那个辅音不同，这是最难处理的一类差异。

## 强级和弱级到底怎么判？

基本规则跟音节结构有关：后面接的音节是闭音节时用弱级，开音节时用强级。听起来清楚，实际操作起来处处是例外。

而且交替不只有强变弱一个方向。有一批词是反过来的，词典形态是弱级，变格之后反而变成强级。

交替的具体形式也不止一种。双辅音变单辅音是最常见的一类，除此之外还有单辅音消失、辅音变成另一个辅音、辅音组合整体改变好几种情况，每一种都有自己的适用条件。

结论很直接：别自己写规则。把头部词表拿去做形态分析，把每个词的强级和弱级两个词干都存进字典，之后所有环节直接取字典，谁都不用再算。

## 词干变了以后，词干还原为什么会失效？

词干还原算法的工作方式是按规则切掉词尾，留下的部分当作词根。这套逻辑的前提是词根稳定。

芬兰语的公开词干提取算法 (https://snowballstem.org/algorithms/finnish/stemmer.html)在处理规则词尾时表现不差，但遇到词干交替就无能为力——它切掉词尾之后拿到的是两个不同的字符串，没有任何办法知道它们是同一个词。

真正能处理这件事的是形态分析器，它不是切词尾而是查形态词典，能把任意一个变格形态还原到词典形态。芬兰语有成熟的开源形态分析组件 (https://voikko.puimula.org/architecture.html)，这类工具在芬兰语上的必要性远高于在别的语言上。

所以芬兰语站的技术选型有一条不同于其他语言的建议：站内搜索别只上词干还原，直接上形态分析。多出来的部署成本，比后期修匹配率的成本低得多。

## 元音和谐怎么决定后缀用哪一套？

芬兰语的元音分成两组，一个词里通常只能出现同一组的元音，后缀也要跟着词根挑对应的那套。

所以同一个格有两种词尾形态，词根里是后元音就用后元音那套，前元音就用前元音那套。猫在里面和桌子在里面，用的是同一个格但两种拼写。

复合词是例外，各段各按各的元音和谐走，所以一个复合词里可以同时出现两组元音，但决定后缀的只有最后一段。

这条规则对做词表的人来说其实是好消息：它是少数几条真正没有例外的规则，可以放心写进程序。真正需要人工的还是词干交替那一层。

## ä和ö在芬兰语字母表里排在哪？

排在最后，在z之后。顺序是z、å、ä、ö，三个都是独立字母，不是a和o的变体。

这一点跟德语正好相反。德语的变音字母在排序时基本等同于对应的基本字母，而芬兰语的ä和ö是完全独立的字母，跟a和o没有排序上的亲缘关系。

做多语言站时这个差异会咬人：同一套排序配置，在德语站上是对的，搬到芬兰语站上就全错。以ä开头的品牌会跑到a开头那一堆里去，芬兰用户看着就是乱的。

å这个字母在芬兰语本族词里基本不出现，它主要服务于瑞典语来源的人名和地名。芬兰是双语国家，这类词在地址和品牌名里出现得不少，字符集白名单别把它漏掉。

## 复数词干和单数词干是两个东西吗？

基本上是。芬兰语的复数在斜格里要插入一个复数标记，而这个标记还会跟词干末尾的元音发生反应，把元音也改掉。

结果是同一个名词的复数斜格形态，跟单数斜格形态相比，词干末尾和词尾两个位置同时不一样。再叠上词干交替，一个词能给出的形态数量相当可观。

好消息是电商场景里真正高频的复数形态就那么几个：复数主格用在列表页和分类名上，复数部分格用在数量表达里，复数内部系列的几个格用在描述里。

所以不用穷举，按高频形态收录就够。把主格、属格、部分格的单复数六个形态存进字典，覆盖率已经很高了。

## 所有格后缀又叠了一层，形态数会到多少？

理论上很吓人。十五个格乘以单复数两个数，再乘以六个人称的所有格后缀，理论组合数接近两百。

但这个数字没有实操意义。所有格后缀在商品搜索里几乎不出现——没有人搜我的自动喂食器，大家搜的是自动喂食器。

所有格后缀真正会出现的地方是产品说明和帮助中心的正文，比如把项圈戴到你的狗身上这样的句子。这属于写作范畴，不属于词表范畴。

划清这条界线很重要，否则一开始就被理论组合数吓退，或者更糟，真的去穷举了，做出一张几万条的词表，维护不动还没人看。

## 复合词的前段用什么形态？

两种都有：有的用主格，有的用属格，而选哪一种没有一条能覆盖全部情况的规则。

狗粮这个词用的是狗的属格加上食物；而喂食碗用的是食物的主格加上碗。两个词结构类似，前段形态却不同。

这跟德语的复合词是两种机制。德语靠连接音把两段粘起来，芬兰语靠格形态，而格形态本身可能触发词干交替，于是复合词的前段跟它单独出现时长得不一样。

德语那边的复合词切分策略在德语复合词与变音符号的选词方法 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)那篇里讲过，思路可以借鉴，但具体的切分点判断在芬兰语上要重做，因为连接方式根本不同。

## 复合词该在哪里切？

按语义边界切，不按字符长度切。芬兰语的复合词可以叠三四段，字符数轻松过二十，靠长度阈值切一定切在奇怪的地方。

实用做法是维护一张词素表，把常见的构词成分列进去，遇到长词先尝试用词素表分解，分解不了的整词保留。

切分的目的是让用户搜其中一段时也能命中。用户搜项圈，你的页面上写的是定位项圈，不切分就匹配不上。

但切分不能进标题。标题上必须是完整的复合词，把复合词拆开写在标题里，在芬兰人看来跟把中文词拆成单字排列差不多。切分只发生在索引层。

## 关键词工具在芬兰语上的数据能信吗？

能看大盘，不能看词级。芬兰人口五百多万，长尾词在工具里大量返回零，这是规模决定的，怪不到工具头上。

更要命的是形态拆分。同一个概念因为格和词干交替被拆成十几条记录，每条都是一个小数字，加起来才是真实需求，而工具不会替你加。

正确用法是先按概念合并再排序。把一个概念下的主格、属格、部分格、几个位置格的形态全列出来，量相加，再跟别的概念比。这么算完，芬兰市场的体量通常比第一眼看上去大出一截。

做捷克语和斯洛伐克语时也是同一个毛病，只不过那边是被两门语言切开，这边是被形态切开。捷克语与斯洛伐克语的内容复用判据 (https://zhangwenbao.com/czech-slovak-seo-content-reuse-decision.html)那篇里讲的先合并再排序的思路，在这里换个合并维度就能用。

## 站内搜索日志为什么在芬兰语上格外值钱？

因为它是唯一能直接告诉你用户打的是哪个形态的数据源。工具给不了这个信息，母语译者凭直觉给的答案也未必准。

重点看三样。第一是空结果查询，那里面藏着你没收录的形态和没想到的说法。第二是同一概念各形态的出现次数分布，这张分布表比任何理论推导都可靠。第三是查询长度，芬兰语的查询词数少但字符长，按词数设的阈值全都要重调。

这份数据攒一个月就有用，攒三个月就能当词表的主要依据。对小语种市场来说，它的性价比高到没有理由不做。

还有一个附带好处：从空结果里能筛出用户用英语搜的那部分查询。芬兰这个市场里这部分比例不低，值得单独看。

## 一个产品词到底要收录多少个变体？

六到八个，不要更多。主格单复数、属格单复数、部分格单复数，这六个覆盖绝大多数真实查询。

如果这个词在使用场景描述里高频出现，再加上内部系列的在里面和到里面两个形态，八个封顶。

超过八个之后收益陡降，而维护成本线性上升。词表的价值在于准，不在于全，一张两百条准确的词表比一张两千条掺水的表有用得多。

每个变体记录三件事：形态本身、它属于哪个概念、它对应哪个词干等级。第三项是芬兰语特有的，别的语言的词表模板里没有这一栏，得自己加。

## 标题该用主格还是带格的形态？

主格，几乎没有例外。商品标题和分类标题的语法角色就是命名，命名用的是主格。

会犹豫是因为看到真实查询里带格的形态占比不低，于是想把标题也改成那个形态。这个想法要打住：查询里出现带格形态是因为用户在句子里思考，而标题不是句子。

让页面接住带格查询的正确位置是正文和站内搜索的索引层，不是标题。标题保持主格，正文里自然带出几个常见形态，两边分工清楚。

唯一值得考虑的例外是那种整个查询就是一个固定短语的情况，短语里的格已经凝固成词的一部分，那时候照抄短语没问题。

## 商品标题模板怎么彻底绕开变格计算？

最省事的办法是模板里所有从字典取的字段一律取主格，字段之间用符号或者空格分隔，不构造句子。

品牌加型号加品类加规格，四个字段拼起来，中间不放需要变格的连接成分。这样的标题在芬兰人看来是标准的商品标题格式，读起来完全正常，而模板一次变格计算都不用做。

如果一定要有连接成分，用那种形态凝固的表达。有一批表示用途和适配对象的固定说法，接在品类词后面形态不变，可以安全地放进模板。

绝对不要在模板里做变格。芬兰语的变格牵扯词干交替、元音和谐、复数词干三层，程序算出来的结果每一百条里总有几条是错的，而错的那几条通常正好在高流量词上。

## 分类页和筛选器的命名选哪个形态？

分类名用复数主格。分类页描述的是一类商品，复数最自然，也跟用户浏览时的心理预期一致。

筛选项用主格，不管它挂在哪个分类下。芬兰语的筛选项通常是名词或者形容词的独立形式，不需要跟分类名保持一致，这一点比屈折程度高的其他语言省心。

面包屑跟着分类名走，直接复用分类名的形态即可，不要为了句子通顺临时改形态。面包屑是导航不是句子。

需要注意的是排序：分类列表和筛选项列表按字母排时，一定要用芬兰语的排序规则，否则以变音字母开头的项会跑错位置。

## 网址里的变音字母该转写还是保留？

转成对应的基本拉丁字母，这是芬兰站点的通行做法，用户也习惯。转写规则简单到不用查表，去掉字母上那两个点即可。

要注意的是转写会造成碰撞：两个只差一个变音符号的词，转写后路径相同。碰上了就在路径里加一个区分词，别靠加数字后缀，那样的路径没人愿意点。

保留本地字符在技术上可行，但收益有限。地址栏里显示得好看，复制粘贴之后就变成一长串编码，客服在电话里也没法念，得不偿失。

芬兰语的地名和人名里带变音字母的比例很高，这一层转写规则要一次定死写进规范，交给不同的人写路径会出现两种转写方式并存的局面。

## 本地域名后缀有什么特别的门槛？

芬兰的国家顶级域名当时由通信主管部门直接管理，注册资格有本地主体要求，不是随便谁都能注。做这个市场之前先确认自己的主体资格，或者找本地代理。

另一件值得知道的事：这个后缀早就支持带变音字母的域名，注册本地字符版本在技术上没有障碍。

但要不要真的用本地字符做主域名，答案通常是不用。主域名用转写版本，本地字符版本注下来做防御性持有并跳转过去，这是成本最低的组合。

本地后缀在芬兰市场的信任加成是实打实的，尤其是需要退换货和售后的品类。如果主体资格能满足，值得注。

## 锚文本在芬兰语里会变成什么样？

会变格，因为锚文本要嵌进句子里，一嵌进去就得跟着句子的语法环境走。

同一个链接目标，出现在不同句子里可能是主格、属格或者某个位置格的形态，而这几个形态之间因为词干交替，字符串差异可能不小。

做法是给每个链接目标准备一个锚文本变体池，写作时按语境挑，别硬凑字面一致。硬把主格塞进需要属格的位置，句子会立刻显出机器味。

这也意味着芬兰语站的锚文本天然分散，那种一模一样的锚文本反复出现的模式在这门语言里根本写不出来。锚文本配比与过度优化的判断 (https://zhangwenbao.com/anchor-text-overoptimization-audit-penguin.html)那篇里的比例算法，用在屈折语上要先做形态归并再算，否则分母全错。

## 芬兰人英语这么好，还需要做芬兰语吗？

需要，但要接受一个现实：这个市场的英语查询占比确实高于欧洲平均水平，尤其在科技类、专业类品类上。

分界线大致在这里：品牌名、型号、专业术语，芬兰用户经常直接用英语搜；而描述需求、比较、找本地服务和售后时，几乎全用芬兰语。

所以合理的策略是双轨。产品页保证型号和品牌名以原样出现，能接住英语查询；内容页和分类页用芬兰语做深，接住需求侧的查询。

完全不做芬兰语的代价不在流量而在转化。芬兰用户看得懂英语页面，但掏钱之前会本能地找母语的退换货条款和客服入口，找不到就走了。这笔账在客单价高的品类上尤其明显。

## 意图词在芬兰市场怎么说？

高频的一批是价格、便宜、最好、评测、体验、比较、优惠、配送、免运费、网店。这些词构成了绝大多数商业意图查询的后半段。

其中两个词本身就带词干交替：价格那个词从主格到属格中间的辅音组合要变，便宜那个形容词从主格到属格辅音直接换成另一个。这两个词出现频率极高，形态一定要收全。

还有一个本地特色值得注意：芬兰用户很爱在查询里加上表示体验和使用感受的词，这类查询的搜索意图偏向调研而非购买，适合用内容页承接，不适合直接怼产品页。

获取这批词的最快方式还是抄本地竞品的导航和帮助中心。芬兰的电商站点结构普遍规整，一个下午能整理出两三百个准确的意图词。

## 数字、日期和地址格式要注意什么？

小数点用逗号，千位分隔用空格，货币符号放在数字后面。写成英语的格式在芬兰读者眼里就是外国网站，这个印象在支付环节代价最大。

日期用日在前的点分格式，三段之间不留空格。月份名全小写，不像英语那样首字母大写。

邮编五位数字。地址结构是街道名在前门牌号在后，跟英语相反。芬兰语的地名变格规则有专门的官方指南 (https://kielitoimistonohjepankki.fi/ohje/nimien-taivutus-paikannimet/)，写配送范围说明和门店地址时值得对着核一遍。

还有一件小事：芬兰是双语国家，部分地区的地名有芬兰语和瑞典语两个版本，做地域覆盖时两个版本最好都收，否则会漏掉一部分本地查询。

## 机器翻译在芬兰语上会犯什么错？

第一类是词干交替错。机器把词尾变对了，词干里的辅音没跟着变，输出一个形态上半对半错的词，芬兰读者一眼看出不对。

第二类是格选错。哪个动词要求哪个格，这在芬兰语里是词汇属性不是语法规则，机器只能靠统计，碰上低频动词就会翻车。

第三类是复合词乱切或者乱拼。该合的分开写了，该分的粘一起了，两种错都会让词看起来很陌生。

验收时把这三类单独列成检查项。给审校人的清单越具体，回收质量越稳，列三行有效，列三十行没人认真看。

## 母语审校要额外看哪几点？

第一，词干交替对不对，尤其是那批高频商业词。第二，元音和谐有没有破，后缀挑错组的情况机器翻译里不少见。

第三，格用得合不合适，重点看动词后面跟的宾语形态。第四，复合词的写法对不对，该合写的有没有被拆开。

第五，数字、日期、货币格式。第六，语气。芬兰语的商业文案偏克制，直白陈述比热情推销更容易建立信任，从英语直译过来的营销腔在这里会显得夸张。

保哥的经验是把这六条做成一张表发过去，比说一句请检查语言质量管用得多。审校人拿到的越具体，回收的质量越稳定。

## 跟土耳其语那种黏着语比，难在哪？

两门语言都靠后缀承载语法信息，都能把好几层意思叠进一个词里，从这个角度看是同一类。

差别在词干。土耳其语的后缀叠得再多，词干本身纹丝不动，只有元音和谐决定后缀用哪个变体，所以按前缀匹配的逻辑在土耳其语上基本是管用的。

芬兰语的词干会变。同一个词的两个形态，前几个字符相同、中间的辅音不同，前缀匹配这条路直接堵死。这是两门语言在技术处理上最大的分野。

土耳其语后缀叠加的选词方法 (https://zhangwenbao.com/turkish-seo-agglutinative-suffix-stacking-keyword.html)那篇里的后缀分层思路在芬兰语上仍然成立，但那边可以靠规则解决的部分，在这边必须换成形态词典。

## 芬兰市场的投入产出账怎么算？

人口五百多万，绝对量不大。但有三个因素让它比数字看起来好：线上支付习惯成熟、物流基础设施好、竞争密度低。

竞争密度低的原因正是本文讲的这些麻烦。词干交替和形态爆炸足以劝退所有只做机器翻译的对手，门槛高的市场里，认真做的人拿到的份额比例反而更高。

预算上给个粗略分配：翻译三成，词表和形态字典建设三成，搜索与排序的技术改造两成，剩下两成留给审校和上线后迭代。形态字典这块最容易被砍，也最容易砍出返工。

判断要不要做的标准很实在：如果你的品类在瑞典或者德国已经跑通，客单价能覆盖跨境物流，本地母语人才找得到，那就值得做。这三条不满足两条，先放一放。

## 关键词表要留几个字段？

九个。概念标识、形态本身、格、单复数、词干等级、词性、所属产品线、搜索量、来源。

词干等级那一栏是芬兰语专属的，别的语言的模板里没有。它记录这个形态用的是强级还是弱级词干，站内搜索做归一时直接取用，不用现算。

概念标识把同一概念的所有形态串起来，是整张表的骨架，缺了它这张表就只是一堆散词。

来源那一栏建议保留，标明这条词是工具来的、站内日志来的还是抄竞品来的。三种来源的可信度不同，复盘时能省很多推理。

## 标题在搜索结果里被截断，芬兰语吃亏更多吗？

吃亏更多，而且是双重的。第一重是复合词本身长，一个词二十几个字符是常态，两三个词就把可用宽度占满了。

第二重是格把介词吃掉之后，芬兰语没法像英语那样靠短介词调节节奏，句子结构更紧，能砍的冗余更少。

应对办法是把最重要的信息放在最前面，品牌名如果不是决策要素就往后放甚至去掉。截断发生时用户看到的是前半段，前半段必须自成信息。

另外别用连字符硬拆复合词来省宽度。省下来的那几个字符换不回被拆坏的可读性，芬兰读者对复合词被拆开非常敏感。

## 芬兰市场的季节性节奏是什么样的？

四季分明，而且分得比多数欧洲市场更彻底。冬季漫长、光照短，室内相关的品类在十一月到二月有明显的需求抬升。

夏季则集中在七月，那是全国性的休假月，商业活动明显放缓，B2B询盘几乎停摆，消费端则转向户外和度假屋相关的品类。

圣诞前的采购期比南欧市场开始得更早，十一月中旬就已经启动。围绕这个节点的内容要在十月上旬准备好，等十一月再上就来不及爬排名了。

这些节奏不需要靠语言知识判断，看两年的搜索趋势曲线就一目了然，但很多团队直接套用了南欧或者中欧的排期表，白白错过半个旺季。

## 上线后头三个月该盯哪几个数？

第一个月盯收录和抓取，确认页面进得了索引、变音字母的路径转写没有出岔子。这一层跟语言关系不大，按常规做法查就行。

第二个月盯站内搜索的空结果率和匹配率。这两个数直接反映词干交替处理得对不对，匹配率上不去，说明形态归一那一层还有洞。

第三个月开始分形态看排名。把同一概念的几个形态分开看，你会发现搜索引擎认定的主形态未必是你想要的那个。

如果主形态跟预期不符，调标题和正文里的形态权重，别推翻重写。这一条在所有屈折程度高的语言上都成立，芬兰语只是幅度更大。

## 正文里要不要故意把多种形态都铺一遍？

不要刻意铺，但也别刻意避。芬兰语的自然写作本来就会带出好几个形态，因为句子结构强制要求变格，你正常写就已经覆盖了主流形态。

真正要避免的是那种硬凑：把同一个词的六个形态塞进相邻几句话里，读起来像语法练习题，本地读者一眼就看出这段是写给机器看的。

如果确实有某个高频形态自然写不出来，正确的做法是造一个真实的使用场景把它带出来，而不是把它孤零零地列进一个词条。

顺带说一句判断标准：写完之后请母语者朗读一遍，凡是他念到某处会停顿、皱眉或者下意识改词的地方，就是硬凑的痕迹，删掉即可。

## 常见问题解答

## 芬兰语的十五个格是不是意味着关键词量要乘以十五？

不是，实际要收录的变体六到八个就够。十五这个数字包含了几个基本只出现在书面语和固定搭配里的格，做电商内容真正需要认真对待的大约十个，而真正会出现在搜索查询里的通常只有三四个。建议的收录范围是主格单复数、属格单复数、部分格单复数这六个，如果这个词在使用场景描述里高频出现，再加上表示在里面和到里面的两个形态，八个封顶。超过八个之后收益陡降而维护成本线性上升，词表的价值在准不在全，一张两百条准确的表比两千条掺水的表有用得多。要提醒的是，真正让形态数量膨胀的不是格本身，而是格叠上复数词干再叠上词干交替之后的组合，所以正确的做法不是穷举组合，而是按真实查询里出现的高频形态来收，这份数据从站内搜索日志里拿最准。

## 词干交替具体会造成什么技术后果？

它会让所有按词尾做归一的逻辑失效。格只改词尾，而词干交替改的是词中间的辅音，比如双辅音收尾的词变属格时双辅音变单辅音，有的词中间的辅音直接消失。后果是同一个词的两个形态开头几个字符相同、中间的辅音不同，而搜索匹配、模糊匹配、前缀匹配这些机制全都建立在词的开头相同这个假设上，这类差异正是它们最难处理的。所以芬兰语站的技术选型有一条不同于其他语言的建议：站内搜索别只上词干还原，直接上形态分析器。词干还原按规则切词尾，切完拿到的是两个不同的字符串，它没有任何办法知道这是同一个词；形态分析器查的是形态词典，能把任意变格形态还原到词典形态。多出来的部署成本，远低于后期修匹配率的成本。另外把每个词的强级和弱级两个词干都存进字典，之后所有环节直接取，谁都不用再算。

## 商品标题模板要不要做变格计算？

不要，一次都不要做。芬兰语的变格牵扯词干交替、元音和谐、复数词干三层，程序算出来的结果每一百条里总有几条错，而错的那几条通常正好落在高流量词上。正确做法是模板里所有从字典取的字段一律取主格，字段之间用符号或空格分隔，不构造句子。品牌加型号加品类加规格这样四个字段拼起来，在芬兰人看来是标准的商品标题格式，读起来完全正常，而模板一次变格都不用算。如果一定需要连接成分，选那些形态已经凝固的固定表达，有一批表示用途和适配对象的说法接在品类词后面形态不变，可以安全放进模板。至于那些带格的查询怎么接住，答案是靠正文和站内搜索的索引层，不是靠标题。标题保持主格，正文里自然带出几个常见形态，两边分工清楚，谁也不用为难谁。

## 芬兰用户英语很好，是不是可以只做英语页面？

不建议，代价主要不在流量而在转化。这个市场的英语查询占比确实高于欧洲平均水平，分界线大致在这里：品牌名、型号、专业术语，芬兰用户经常直接用英语搜；而描述需求、做比较、找本地服务和售后信息时，几乎全用芬兰语。所以合理的策略是双轨——产品页保证型号和品牌名以原样出现，能接住英语查询；内容页和分类页用芬兰语做深，接住需求侧的查询。完全不做芬兰语，你会发现流量看起来还行，但转化率上不去，因为芬兰用户看得懂英语页面，掏钱之前却会本能地去找母语写的退换货条款和客服入口，找不到就默默离开了，这个动作不会留下任何可归因的数据。客单价越高的品类这笔账越明显。判断方法也简单：看有多少芬兰来源的会话最后停在了政策页。

## 关键词工具在芬兰语上的数据到底能不能用？

能看大盘，不能看词级。芬兰人口五百多万，长尾词在工具里大量返回零，这是市场规模决定的。更要命的是形态拆分，同一个概念被格和词干交替拆成十几条记录，每条都是一个小数字，加起来才是真实需求，而工具不会替你加。所以正确用法是先按概念合并再排序：把一个概念下的主格、属格、部分格以及几个常用位置格的形态全部列出来，量相加，再跟别的概念比较。这么算完，芬兰市场的体量通常比第一眼看上去大出一截，很多本来被判定为不值得做的品类会重新回到候选名单里。如果工具在你的品类上数据稀疏到给不出有意义的数字，就换三个土办法：抄本地竞品的分类树和筛选项、看本地比价渠道的属性命名、以及最准的那个——自己站内搜索的日志。前两个立刻能用，第三个要等一个月，但等到了就是最可靠的依据。

## 变音字母在排序时该怎么处理？

当独立字母处理，位置排在字母表最后。这一点跟德语正好相反，德语的变音字母在排序时基本等同于对应的基本字母，而芬兰语这几个变音字母跟对应的基本字母没有任何排序上的亲缘关系。做多语言站时这个差异会咬人：同一套排序配置在德语站上是对的，搬到芬兰语站上就全错，带变音符号开头的品牌会跑到基本字母那一堆里去，芬兰用户看着就是一个乱序列表。会受影响的地方有三处：按字母排列的品牌索引页和术语表页、筛选器里的下拉选项、站内搜索的自动补全建议。解决办法在数据库层，给相关字段指定芬兰语的排序规则而不是用默认的通用规则，一次性配置全站受益。顺带提醒，其中一个变音字母在芬兰语本族词里基本不出现，它主要来自瑞典语的人名和地名，但芬兰是双语国家，这类词在地址和品牌名里出现得不少，字符集白名单别把它漏掉。

## 复合词在标题里要不要拆开写？

绝对不要。芬兰语的复合词可以叠三四段，字符数轻松过二十，看着确实长，但它在芬兰语里就是一个词，拆开写在标题里，在芬兰人看来跟把中文词拆成单字排列差不多。切分只应该发生在索引层，目的是让用户搜其中一段时也能命中，比如用户搜项圈而你的页面上写的是定位项圈，不切分就匹配不上。切分的方法是按语义边界切，不是按字符长度切，实用做法是维护一张词素表把常见构词成分列进去，遇到长词先尝试分解，分解不了的整词保留。还要注意芬兰语复合词的前段形态有两种，有的用主格有的用属格，而没有一条规则能覆盖全部情况，加上属格本身可能触发词干交替，所以前段在复合词里的样子跟它单独出现时可能不一样。这一点跟德语靠连接音粘合是完全不同的机制，德语那套切分策略不能照搬。

## 权威参考资料



## 希伯来语SEO的一个词根写出来只有三个辅音，能对上的搜索词有七八个

- URL：https://zhangwenbao.com/hebrew-seo-unvocalized-script-root-letters-keyword.html
- 分类：小语种SEO
- 发布：2012-09-27  |  更新：2026-07-25
- 摘要：讲希伯来语SEO实战：不标元音带来的一词多形怎么收进词表、词根三辅音如何一次找出一族词、国际词转写选哪一种、五个词尾变体字母在索引层怎么归一、元音标记混进导入数据的排查、品牌名转写的定死流程。
- 关键词：关键词研究,内容本地化,小语种SEO

> **TLDR**：摘要：希伯来语日常书写不标元音，页面上落下的只是一串辅音骨架，读者靠上下文把音补回去。这件事对人不难，对搜索匹配是灾难：同一串辅音可能对应好几个不同的词，而同一个词又可能带元音写、不带元音写、拼进一个额外字母写。做以色列市场的选词，第一步不是找长尾，是先搞清楚你的核心词到底会以几种字符串形态被敲进搜索框。这篇讲清词根三辅音的规律、变体收到几个够用、右到左布局跟语言层怎么分工，以及品牌名转写该怎么定。

> 摘要：希伯来语日常书写不标元音，页面上落下的只是一串辅音骨架，读者靠上下文把音补回去。这件事对人不难，对搜索匹配是灾难：同一串辅音可能对应好几个不同的词，而同一个词又可能带元音写、不带元音写、拼进一个额外字母写。做以色列市场的选词，第一步不是找长尾，是先搞清楚你的核心词到底会以几种字符串形态被敲进搜索框。这篇讲清词根三辅音的规律、变体收到几个够用、右到左布局跟语言层怎么分工，以及品牌名转写该怎么定。

一家做家用医疗器械的客户，主力是电子血压计和便携制氧机，欧洲几个市场做熟之后想开以色列。人口不到一千万，但人均医疗支出高、线上支付成熟、物流半径小，是个漂亮的切口。

词表和文案都请了以色列本地的自由译者，交付质量没问题。上线两个月，产品页收录正常，排名却卡在一个很奇怪的位置：品牌词第一，品类词连前三页都进不去。

翻站内搜索日志才发现问题。用户搜进来的字符串和页面上写的字符串，肉眼看差不多，逐字节比对却对不上——差的是一两个字符。

不是错别字。是同一个词的两种合法写法：一种把某个元音用一个辅音字母顶上去，一种不顶。两种都对，两种都有人用，而搜索引擎把它们当成两个不同的字符串。

这就是希伯来语选词的起点：这门语言在书写层面天然存在一词多形，而且多出来的那几形不是错的。

## 希伯来语为什么不写元音？

因为它的书写系统本来就是辅音音素文字。字母表里的字母绝大多数表示辅音，元音在系统设计上不占字母位置。

元音不是没有办法标。有一整套点和短线组成的标注系统，加在字母的上下左右，能把发音标得非常精确。但它主要用在宗教文本、诗歌、儿童读物和字典里。

日常书写——报纸、网页、聊天、商品页——一律不标。成年读者靠词形和上下文直接读出来，跟中文读者看到一个多音字能自动选对读音是一个道理。

所以你的以色列站页面上，落下的是一串辅音骨架。这是正常的、地道的、必须的写法。麻烦在于骨架比完整的词更容易撞车。

顺带破除一个常见误解：不写元音不等于这门语言把元音丢了。元音在口语里完整存在，只是书写系统选择不把它编码进字母序列，交给读者去还原。这是设计取舍，不是缺陷。

理解这一点很重要，因为它决定了你不该试图在页面上补全元音符号来帮助搜索引擎。加了符号的文本对以色列读者来说像儿童读物，而对匹配没有任何帮助——用户敲的还是不带符号的形态。

## 不标元音到底会造成多少歧义？

对人来说几乎没有。母语者的消歧能力极强，因为词形规律、语法位置和上下文一起工作，三重约束下能剩下的候选通常只有一个。

对机器来说就是另一回事。同一串辅音在词典里可能对应三四个不同的词，词性都可能不同。

但这件事对做SEO的实际影响，比听起来小。原因是商业查询几乎不是孤立的单个词，用户搜的是词组，词组本身就提供了消歧上下文。

真正咬人的不是歧义，是同一个词的多种合法拼写。这是完全不同的一个问题，下面单独讲。

## 什么是不标元音时的补字母写法？

既然日常不标元音符号，那遇到必须区分的情况怎么办？答案是用几个特定的辅音字母来兼职表示元音。

这套做法有正式规范，规则大致是：不带元音符号书写时，某些元音要用对应的字母写出来，某些位置的字母要双写。

于是同一个词就有了两套写法：一套是带元音符号的完整形态，一套是不带符号但补了字母的形态。后者比前者多出一到两个字符。

这两套写法在互联网上同时存在，而且用户敲搜索框时既可能敲补了字母的，也可能敲没补的。这就是我说的一词多形。

## 这种拼写差异在关键词表上意味着什么？

意味着你的每一个核心词，至少要按两种形态去查量、去布局、去做站内搜索的同义词映射。

实测下来，一份两百词的品类表里，大约六到七成的词存在两种及以上的常见写法。剩下三成是短词或外来词，形态唯一。

两种形态的搜索量分布不均衡，通常有一个明显占优，但劣势的那一个往往也有可观的量——足够让你在漏掉它的时候少接一批流量。

所以关键词表的第一列不该是词，该是概念；词形是第二列，一个概念下挂两到三个词形。这个结构一旦定好，后面所有环节都受益。

这个思路本身不新。日语的三套文字那篇 (https://zhangwenbao.com/japanese-seo-hiragana-katakana-kanji-keyword-notation.html)处理的是同一类问题——同一个词有几种合法的书写形态，各自有各自的搜索人群。区别在于，日语那边的选择是文字系统级的，读者能明确感知；希伯来语这边的差异只有一两个字符，很多用户自己都说不清刚才敲的是哪一种。

差异越小越危险，因为它逃得过人眼审校。日语那种一眼可辨的差异反而不容易漏。

## 词根三辅音是什么，为什么它比格变化更重要？

希伯来语的词汇大量建立在三个辅音组成的词根上。词根本身不是一个能读的词，它是一个语义种子。

把这三个辅音套进不同的模板——在固定位置加元音、加前缀、加后缀——就长出一整族词：动作、施事者、场所、工具、结果，全是同一个词根的变形。

这跟屈折语的格变化完全不是一回事。格变化改的是同一个词的语法形式，词还是那个词；词根派生长出来的是一整族不同的词，词性都可能不同。

对选词的意义在于：找到一个词根，等于同时找到了一批相关词。这是希伯来语选词里最省力的一个杠杆，也是这门语言给你的唯一一处红利。

## 词根怎么变成实际可用的选词方法？

三步。

第一步，让母语顾问把你的核心品类词的词根标出来。这个动作对他们来说是本能，成本极低。

第二步，围绕这个词根列出同族的常用派生词——名词形式、动词形式、表示工具的形式、表示场所的形式。

第三步，把这批词丢进关键词工具查量，同时按上一节说的规则展开拼写变体。

做完你会发现，同一个词根族里往往有一两个词的搜索量远高于你原本选的那个，而它们在直译词表里根本不会出现——因为直译只会给你一个词。

## 词根这条路会在哪里失效？

在外来词上。

现代希伯来语吸收了大量国际词汇，尤其在科技、医疗、消费电子领域。这批词没有闪语系的三辅音词根，它们是音译进来的。

医疗器械品类里这类词特别多，很多设备名、参数名、功能名都是国际词的希伯来字母转写。

而音译进来的词，转写方式往往不止一种——这又回到了一词多形，只不过这次的原因不是元音书写规范，是转写习惯不统一。

判断一个词属于哪一类，最快的办法是问母语顾问它有没有词根。有词根的走词根派生这条路，没有的走转写变体那条路。两条路的选词方法完全不同，混着做只会两头都不到位。

医疗器械这类品类的词表通常是混合的：设备大类名往往有本族词根，具体功能和参数名大量是国际词。所以一份词表里两条路都要走一遍，别指望一种方法通吃。

## 国际词的希伯来字母转写有几种写法？

常见的是两到三种，分歧点集中在几个音上：原词里的某些元音用哪个字母顶、某些辅音用哪个字母对应、词尾要不要补一个字母。

判断哪一种是主流，别靠猜也别靠词典。词典给的是规范形态，市场上流行的可能是另一种。

可靠的方法有两个：一是看本地大型电商和比价平台的商品标题用哪一种，二是看本地媒体的科技版面用哪一种。这两处代表的是实际流通的写法。

定下主流形态之后，把其他形态全部收进站内搜索的同义词表和页面正文的自然提及里。页面主标题只用一种，别在标题里堆变体，那看起来就像关键词填充。

还有一类特殊情况值得留意：有些国际词在以色列市场已经有了完全本地化的替代说法，用户日常用本地词而不是音译词。这时候你的词表如果只收音译形态，等于把主流查询整块漏掉。

识别方法还是看本地零售站的分类树。分类树用的是本地词还是音译词，就是市场投票的结果，比任何词典判断都准确。

## 自己的品牌名该怎么转写成希伯来字母？

先问一个前置问题：要不要转写。

以色列市场对拉丁字母的接受度很高，国际品牌名在本地网站上大量以原样的拉丁字母出现，用户也习惯直接用拉丁字母搜品牌。

所以品牌名的默认策略是保留拉丁字母原样，同时在页面上给出一个希伯来字母的转写形态作为补充，两者都能被搜到。

这个双轨结构在非拉丁字母的市场里是通例。希腊语与拉丁转写并存那篇 (https://zhangwenbao.com/greek-seo-greeklish-latin-transliteration-coverage.html)讲的是同一件事的另一个方向——那边是用户拿拉丁字母去打本族语的词，这边是用户拿本族字母去写外来的品牌名，两个方向都要覆盖，覆盖方法也差不多。

差别在于紧迫度。希腊语市场的拉丁转写主要出现在用户输入端，你的页面上不需要写；希伯来语市场的品牌转写会出现在别人的页面上——经销商、媒体、论坛，你不定，他们替你定。

但转写形态必须自己定，而且要定死。如果你不定，市场会替你定出好几个版本——本地经销商一个版本、媒体一个版本、用户论坛又一个版本，然后你的品牌搜索量被切成三份，每一份看起来都不值得投入。

## 品牌转写形态定下来之后要做什么？

三件事，一件都不能少。

第一，把它写进页面。产品页、关于页、页脚的品牌信息里，让转写形态和拉丁原样同时出现，建立两者的关联。

第二，把它交给合作方。经销商、代理、媒体投放、KOL，统一用这一个形态，别让每家自己发挥。

第三，把所有已经在市场上流通的其他版本收进站内搜索的同义词表。用户用错版本搜进来，你的搜索框也得给结果。

这三件事的总成本大概是半天，而不做的代价会持续好几年——品牌词一旦被切碎，合并回来比一开始就定死难十倍。

## 从右往左这件事，跟语言层的关系是什么？

这里要把边界划清楚，否则这篇会变成一篇布局文章。

右到左的排版、双向文本的混排规则、界面镜像、表单方向、面包屑方向——这一整套是渲染与布局层的问题，跟具体是哪一门右到左语言无关。阿拉伯语站会遇到，希伯来语站也会遇到，遇到的是同一批坑。

这套坑我在阿拉伯语从右往左那篇 (https://zhangwenbao.com/arabic-seo-rtl-layout-msa-dialect-keyword.html)里已经完整拆过，包括哪几个位置最容易翻车、文本方向属性该怎么用、数字和拉丁片段混进右到左句子时的排列规则，这里不重复。

希伯来语这篇要讲的，是布局之外那一半：字符串本身的形态问题。元音写不写、字母补不补、词根怎么派生、转写选哪一种——这些跟从哪个方向排版没有任何关系，换成从左往右排，问题一个不少。

两篇的分工就是这样：一篇管方向，一篇管字符串。你的以色列项目两边都要读。

## 那希伯来语有没有阿拉伯语没有的方向问题？

有一个，而且很实际：拉丁字母的混入密度。

以色列市场的希伯来语文本里夹拉丁字母的比例相当高——品牌名、型号、单位、技术缩写，很多直接用拉丁原样写。

这意味着双向文本的混排在希伯来语页面上不是偶发情况，是常态。一个商品标题里可能同时有希伯来字母、拉丁字母和阿拉伯数字三种方向属性不同的片段。

后果是标点符号的位置容易乱跑。句末的句号、括号、引号在混排边界上的落点，是最常见的显示事故，而它在开发环境里往往不复现。

## 字符和编码上要注意什么？

希伯来字母的码位集中在一个连续的区块里，字母本身没什么坑。有坑的是那些元音符号和辅助标记。

这些标记是组合字符，附着在前一个字母上。它们在字符串里占位置，但在屏幕上不单独占宽度。

所以按字符数做截断的逻辑会出错：你以为截了三十个字符，实际显示出来只有二十几个字母宽，而且可能把一个字母和它的标记截开，产出一个孤立的悬空标记。

做法是：面向用户展示的文本，日常内容本来就不带这些标记，问题不大；但你的内容库如果从字典或宗教文本类来源导入过数据，一定要先扫一遍，把标记剥掉再入库。

扫描的时候顺便统计一下比例。如果带标记的记录占比很高，说明你的数据源整批都是标注版本，那就不是修补几条的事，得整批重新处理。这个数字五分钟就能跑出来，值得在入库前先看一眼。

## 为什么导入的数据里会混进元音标记？

因为来源。字典数据、教材数据、部分官方术语表都是带标记的，而这些恰恰是做多语言站时最容易拿来当种子数据的来源。

带标记的字符串和不带标记的字符串，在字节层面完全不同。用户搜的永远是不带标记的形态，你库里存的是带标记的，匹配率直接归零。

更隐蔽的是部分带标记——有的词带，有的词不带，同一个字段里混着两种。这种数据在抽查时很容易蒙混过关。

处理方法是入库前统一做一次规范化，把组合标记全部剥离，同时保留一份原始数据备查。这个动作在字符规范化的标准文档 (https://www.unicode.org/reports/tr15/)里有对应的处理形式，按标准做比自己写正则可靠。

## 希伯来字母有几个字母有词尾变体？

五个。这几个字母出现在词的末尾时换一个写法，字形不同，码位也不同。

这是纯粹的位置规则，不带任何语义或语法含义，跟希腊语词尾那个字母的情况类似。

坑出在两个地方。第一是复合词和连字符：一个字母本来在词尾，因为构词变成了词中，写法要跟着改，而批量处理脚本经常不改。

第二是搜索匹配：用户在搜索框里敲一个词的前半段做前缀搜索时，可能会习惯性地把最后那个字母敲成词尾形态，而你库里存的是词中形态。这两个是不同的码位，直接失配。

## 词尾变体在技术上怎么处理？

在索引层做归一。建立词尾形态和普通形态的映射，索引时和查询时都把词尾形态折叠到普通形态上。

这个动作只影响匹配，不影响展示。展示层严格按正字法走，该用词尾形态就用词尾形态，写错了以色列用户一眼就看出来。

开源的希伯来语搜索处理项目 (https://github.com/synhershko/HebMorph)就是围绕这类问题做的，词尾归一、拼写变体折叠、形态分析都在它的处理范围里。自己从零写这套逻辑之前，先看看已有方案覆盖了多少。

还有一个细节：URL和文件名里如果出现希伯来字母，词尾形态的处理必须和索引层保持一致，否则会生成两条指向同一内容的不同路径。

## 关键词工具在希伯来语上给的数据能不能信？

能看趋势，不能看绝对值，理由跟其他小语种一样，但这里多一层。

多出来的那一层是拼写变体。同一个概念被切成两三条记录，每条都是一个中等数字，而工具不会替你合并。你看到的每一个数字都比真实需求小。

所以正确的用法是先按概念合并再排序：把一个概念下的所有拼写形态列全，量相加，再跟别的概念比。

这么算完，以色列市场的体量通常比第一眼看上去大出一截。很多本来被判定为不值得做的品类，合并之后会重新回到候选名单里。这是个反复出现的现象，值得在立项阶段就做一遍。

还有一个工具层面的实际问题：有些关键词工具对希伯来语的输入处理不干净，粘贴进去的词在双向文本环境下可能被截断或重排，查出来的是一个你没输入过的词。查完之后把工具回显的词复制出来跟原词逐字节比一遍，这个动作能避免一整批白做的查询。

## 工具没数据的时候怎么补？

三个土办法，按可靠性从低到高排。

抄本地竞品。以色列本地的大型零售站和比价平台，它们的分类树和筛选项名称就是经过流量验证的词。这个立刻能用。

看本地内容社区。医疗、育儿、消费电子这几个领域的本地论坛和问答，用户在那里怎么描述需求，就是长尾词的原始形态。

最可靠的是自己的站内搜索日志。上线一个月就有数据，而且它天然带着拼写变体的真实分布——用户到底更爱敲哪一种写法，日志会直接告诉你，比任何推测都准。

## 站内搜索的同义词表具体该怎么配？

这是希伯来语项目里性价比最高的一项技术工作，配好了能一次性挡掉大半的零结果。

表的结构按概念组织：一行一个概念，行内列出这个概念的全部形态——主流拼写、补字母拼写、词尾变体折叠后的形态、国际词的几种转写、品牌名的拉丁原样与希伯来转写。

配置方式选双向等价，不要选单向扩展。单向扩展意味着只有从A能搜到B，反过来不行，而用户从哪一端敲进来是不可预测的。

维护节奏是每月看一次站内搜索日志的零结果词，把新出现的形态补进表里。这个动作两个月之后基本就稳定了，之后只需要在上新品类时补一批。

## URL里用希伯来字母还是拉丁转写？

两条路都能走通，但要一次选定，别混着来。

用希伯来字母的路径在技术上没有问题，编码之后是一串百分号转义，浏览器地址栏会显示回原字符。以色列本地站点这么做的不少。

用拉丁转写的路径可读性更好，分享到即时通讯和社交平台时不会变成一长串乱码，运维排查日志时也省心。

我的建议偏向拉丁转写，理由是希伯来语的链接会大量出现在即时通讯里，而转义后的长串在预览卡片和日志里都很难认。选定之后把转写规则写死，包括词尾字母怎么处理——这一条必须和索引层的归一规则保持一致，否则同一个词会生成两条路径。

## 内链锚文本在希伯来语里会不会变形？

会，而且变形的方式跟屈折语不同。

屈折语里锚文本变形是因为格；希伯来语这边，主要是因为定冠词和介词都是前缀，直接粘在词的前面。把一个品类词自然地嵌进句子，它前面往往会多出一两个字母。

后果是锚文本和目标页的核心词形态对不上。人读起来完全正常，做锚文本一致性审计时却会大面积报警。

处理办法有两个方向。一是审计规则放宽，允许前缀差异，别按精确匹配算；二是在每个页面上保证核心词的裸形态至少在正文里出现一次不带前缀的版本，让匹配有落点。两个一起做最稳。

## 图片文件名和替代文本要用希伯来字母吗？

替代文本必须用希伯来语，这没有商量余地——它是给用户和辅助技术读的，用英语等于没写。

文件名建议用拉丁转写，理由跟URL一样：可读性、可排查性、跨系统兼容性。图片搜索对文件名的依赖没有大多数人以为的那么高，替代文本和周边文字的权重更实在。

替代文本的写法有一条希伯来语特有的注意事项：里面如果夹了拉丁字母的型号，双向混排的规则同样生效，标点位置可能跑偏。替代文本一般不显示所以不容易被发现，但辅助技术读出来的顺序会受影响。

还有一点，替代文本里的核心词用主流拼写形态，别在这里塞变体。变体的覆盖有专门的地方，不需要在每个字段里重复一遍。

## 日期与数字格式在结构化数据里怎么填？

结构化数据里的日期一律用国际标准格式，不用本地显示格式，这是通用规则不分语言。

本地显示层才按日月年顺序走。两层分开，别为了省事把显示格式塞进结构化字段。

语言标记要填希伯来语的语言代码，别只填国家代码。以色列境内还有其他语言的使用群体，光标国家不足以说明页面语言。

各语言环境的格式数据对照表 (https://cldr.unicode.org/index/charts)里能查到希伯来语环境下日期、数字、货币的标准写法，配置模板前对着核一遍，比让前端自己拍脑袋决定可靠。

## 标题和元描述在希伯来语里有什么特殊要求？

长度要重新估。希伯来字母的平均字符宽度比拉丁字母窄，同样的像素宽度能放下更多字母，所以按拉丁字母的字符数上限来卡会浪费空间。

但如果标题里夹了拉丁字母的品牌名和型号，混排会让实际占宽变得难以预估，保守一点更安全。

内容上有一条硬要求：核心词用市场主流的那一种拼写形态，别为了覆盖变体在标题里塞两种。塞两种在希伯来语读者眼里非常刺眼，因为两种写法并列出现在同一句话里，本身就是不通顺的。

变体的覆盖靠正文的自然提及和站内搜索的同义词表，不靠标题。

## 商品标题模板要不要做形态计算？

不要。理由和其他形态复杂的语言一样，但希伯来语这里还多一条。

希伯来语的名词有性和数，形容词要跟着名词一致，而且定冠词是一个前缀，直接粘在词前面。模板里只要出现需要一致的成分，就有算错的风险。

多出来的那一条是：算错的结果在希伯来语里不会看起来像轻微的语法瑕疵，会看起来像机器翻译。以色列用户对这个非常敏感，因为本地市场充斥着质量粗糙的机翻页面，他们已经练出了识别能力。

所以模板里的字段一律取词典基本形态，字段之间用符号或空格分隔，不构造句子。品牌、型号、品类、关键规格四段拼起来，读起来完全正常。

## 日期、数字和度量单位怎么写？

数字用阿拉伯数字，从左往右写，这一点跟阿拉伯语市场的部分地区不同，希伯来语这边没有另一套数字形。

日期格式是日月年顺序，跟欧洲大陆一致。

度量单位用公制，单位缩写通常直接用拉丁字母原样写，不转写。这意味着规格表里会大量出现拉丁字母片段，又回到了混排问题。

还有一个容易忽略的：以色列有自己的历法，节庆日期每年在公历上的位置都不一样。做季节性营销日历时，别拿欧洲的节庆表直接换算，那会错得很离谱。

## 节庆与季节词为什么值得单独做一遍？

因为它是这个市场少有的、竞争密度低而意图强的流量池。

以色列的主要购物高峰跟欧美的节庆日历基本不重叠，本地节庆前后有明确的送礼和采购习惯。

对医疗器械这类品类，节庆送礼的关联度看起来不高，但实际上有——给父母长辈买健康类礼物是一个真实存在的场景，而且客单价不低。

操作上就是提前六到八周布局对应的内容页，用节庆名加品类词的组合。这批词全年只热几周，但那几周的转化率能到平时的好几倍。

## 以色列用户的英语水平很高，能不能只做英文站？

不能，理由跟北欧市场那套逻辑相似但更强烈。

以色列的英语普及率确实高，专业人群读英文技术文档毫无障碍。但搜索行为的分野很清楚：型号、技术参数、国际品牌名会用英语搜；需求描述、本地服务、保修条款、能不能寄到自己那个地址，一律用希伯来语。

更关键的是信任。这个市场对本地存在感的要求高于欧洲平均水平，一个没有希伯来语页面的站，在用户眼里就是一个不打算长期经营这个市场的站。

医疗器械品类还多一层监管敏感度，用户会主动找本地语言写的合规和售后信息。找不到，转化就停在最后一步。

这笔账的算法跟北欧三国那套资产分层 (https://zhangwenbao.com/nordic-seo-swedish-norwegian-danish-content-sharing-boundary.html)是一样的：把内容拆成资产类型，看哪一类必须用本地语言。结论也相似——政策页、售后页、需求侧内容页三类不能省，技术规格和数值参数可以放宽。

不同的是希伯来语这边多一个变量：字符串本身还有形态问题。北欧那边确定了用哪国语言就等于确定了写法，这边确定了用希伯来语，还得再确定用哪一种拼写。

## 以色列的一周从周日开始，这件事会怎么影响你？

这是做以色列市场最容易被整个漏掉的一条，而它影响的不是内容，是整套运营节奏。

以色列的标准工作周是周日到周四。周五是半天或休息，周六是安息日，商业活动大面积停摆，很多本地站点的客服和发货在这两天完全停止。

直接后果有四个。促销活动的开始日不该定在周一，本地用户的采购决策高峰在周日；客服排班要按当地作息排，欧洲团队的周一到周五覆盖不了周日这个最忙的一天；发货与配送时效的承诺必须扣掉周五周六；报表的周环比如果按周一到周日切，跟本地的业务周完全错位，看出来的波动全是假的。

内容侧也有一条：涉及营业时间、配送时效、客服响应的页面，写法要按本地作息写，别照搬欧洲模板里的工作日表述。用户看到不匹配自己生活节奏的承诺，信任感直接下降。

## 节庆日历为什么不能拿欧洲那套换算？

因为以色列的节庆跟着自己的历法走，每年在公历上的位置都会移动，而且移动幅度不小。

这意味着你不能像做欧洲市场那样，把去年的营销日历日期加一年就用。每年都要重新对一次表。

更重要的是，几个主要节庆前后有明确的采购高峰，而这些高峰跟欧美的购物季完全不重叠。你在欧洲市场熟悉的那套节奏在这里派不上用场，反过来说，这也意味着这批节庆词的竞争密度低得多。

操作上就是提前六到八周布局节庆名加品类词的组合内容。医疗器械这类品类看起来跟送礼关联不大，但给父母长辈买健康类礼物是真实存在的场景，客单价还不低。

## 定冠词和介词都是前缀，这会带来什么麻烦？

这是希伯来语在字符串层面最系统性的一个麻烦，比词尾字母那个影响面大得多。

希伯来语的定冠词、几个常用介词、连词，全部是单字母前缀，直接粘在词的前面，不加空格也不加符号。

后果是同一个名词在真实句子里会以好几种带前缀的形态出现：裸形态、带定冠词、带介词、带连词、以及介词加定冠词的合并形态。每一种都是一个不同的字符串，而且差异全在词的开头。

差异在开头这一点特别要命，因为前缀匹配、自动补全、按首字母排序这几套机制全都依赖词的开头相同。词尾变化它们还能靠词干还原处理，词头变化直接把它们废掉。

## 前缀问题在技术上怎么处理？

三个动作，按投入产出排。

第一，索引层做前缀剥离。建一张常用前缀表，索引和查询时都尝试剥掉可能的前缀，把带前缀和不带前缀的形态折叠到同一个键上。要注意的是剥离必须是尝试性的——有些词本身就以这几个字母开头，剥错了会变成另一个词，所以剥完要拿词典验一下，验不过就保留原形。

第二，自动补全的输入处理要单独做。用户在搜索框里敲的第一个字符很可能是个前缀，如果你的补全逻辑严格按首字符匹配，会一条都补不出来。做法是补全时同时尝试原串和剥了前缀的串。

第三，字母索引页要按剥离后的形态归组。否则你的品牌索引里会有一大堆词莫名其妙地聚在同一个字母下面——那个字母就是定冠词。

## 两个名词连在一起时前一个为什么会变形？

因为希伯来语有一套专门的名词连缀结构，用来表达类似“某某的某某”这种从属关系，而在这个结构里，前一个名词要换成一个特殊形态。

这个结构在商品命名里出现得极其频繁。品类加用途、品类加材质、品类加适用对象，几乎都是这个结构。

坑在于：变形的是前一个词，也就是你的核心品类词。用户单独搜这个品类词时用的是裸形态，而你的商品标题里它是连缀形态，两个字符串不同。

处理办法是词表里把裸形态和连缀形态都收进去，并且标题的主位置放裸形态——把品类词单独放在前面，用符号跟后面的修饰成分隔开，绕开连缀结构。这跟其他语言里模板不做形态计算是同一个思路。

## 按钮文案和祈使句要分男女形吗？

要，这是希伯来语在转化文案上最实际的一个问题，而大多数团队根本没意识到它存在。

希伯来语的动词、形容词都带性，第二人称的祈使形态男女不同。也就是说“立即购买”“填写地址”“联系我们”这类按钮和引导文案，语法上必须选一个性别。

本地实践有几种解法：默认用阳性形态（传统做法，但对女性用户不够友好）、改用不带人称的名词化表达（比如把“立即购买”改成“购买”这个动作名词，性别中立）、或者在用户注册后按其资料切换形态。

最省事又最稳妥的是第二种：把祈使句改写成动作名词。这在希伯来语里完全自然，很多本地大站就是这么做的，一次改完全站受益，也不需要维护两套文案。

顺带说，这条也适用于邮件营销和推送文案，那些地方的人称感更强，用错了性别的违和感也更明显。

## 希伯来字母兼作数字，这会不会撞上什么？

会撞上一个很窄但很尴尬的场景：字符白名单和内容校验。

希伯来字母有一套传统的数值用法，字母本身可以表示数字，这套用法今天仍然活跃在日期、条款编号、章节序号、部分产品版本号里。

它在页面上表现为一串看起来像单词但其实是数字的字母序列，中间可能夹着一个特殊的标记符号。

影响主要有两处：一是自动摘要或截断逻辑可能把这串东西当成一个普通词处理，截断位置很难看；二是内容质量检测如果按词典校验拼写，这类序列会被大面积标红。

处理上不需要做什么复杂的事，把那个标记符号加进字符白名单、把这类序列加进拼写检查的忽略规则就够了。知道它存在，比处理它更重要。

## 希伯来语内容的篇幅习惯跟中文差在哪？

差在信息密度和展开方式，这会直接影响你的内容页该写多长。

因为不写元音，希伯来语的字符效率很高，同样的信息量占用的字符数明显少于欧洲语言。所以照着中文或英文的字数去要求译稿，会得到一篇被硬撑长的文章。

本地的商业写作风格偏直接，铺垫少，结论前置。冗长的引导段落在这个市场不受欢迎，读者会直接往下滚。

实用的做法是按信息点数量而不是字数来定内容规格。一个分类页要覆盖几个用户问题、一个产品页要回答几个决策疑虑，把这些定下来交给译者，让他们用自己觉得合适的篇幅写。

这条对预算也有好处：按信息点计费比按字数计费更能约束质量，也避免译者为了凑字数注水。

## 本地引擎生态需要单独考虑吗？

不需要。以色列的搜索市场集中度高，不存在体量相当的本土引擎，所以没有为第二个引擎单独做一套的问题。

引擎层的打法差异属于另一个话题范畴，这篇不展开。语言层要解决的是拼写形态、词根派生、字符处理和内容形态，这几件事跟哪个引擎在收录没关系。

唯一需要额外看一眼的是本地比价与团购渠道，它们在以色列的流量占比不低。但那属于渠道层，对语言层的结论没有影响。

## 母语审校要盯哪几件事？

五条，按优先级排。

拼写形态是否统一：同一个词在全站是不是用同一种写法，这是最容易出问题也最容易检查的一条。

词尾字母是否正确：位置规则有没有被批量处理脚本破坏。

混排是否干净：标点、括号、数字在方向边界上的落点有没有跑偏。

品牌转写是否一致：全站是不是同一个形态。

最后一条也最主观：整体读起来像不像机器翻译。这一条只有母语者能判断，也最值钱。

审校的形式建议用样本页而不是全量。先送一个分类页、一个产品页、一个内容页，把系统性问题在这三页上抓完再放量。拼写形态不统一、词尾字母错、混排跑偏这三类问题都是系统性的，一旦出现就是全站出现，在三页上修完等于在全站修完。

## 上线之后先看哪几个指标？

三个，都能在头两个月给出明确信号。

站内搜索的零结果率。它直接暴露拼写变体覆盖不足，而且日志会告诉你缺的是哪一种形态。

品类词与品牌词的排名落差。如果品牌词很好而品类词很差，八成是核心词选了非主流的拼写形态。

政策页与售后页的流失。这个指标暴露的是信任信息不足，在医疗类品类上尤其灵敏。

保哥的经验是，这三个指标能在两个月内把八成的本地化问题照出来，而且每一个都指向明确的修复动作，不需要再做额外的诊断。

## 一份可以照着走的希伯来语启动清单

准备阶段做四件事：让母语顾问标出核心词的词根并展开同族派生词、给每个核心概念列出全部常见拼写形态、定死品牌名的希伯来转写形态、把导入数据里的元音标记扫一遍剥干净。

技术阶段做三件事：索引层建立词尾字母归一与拼写变体折叠、按标准做字符规范化、把双向混排的显示在真机上验一遍。

内容阶段守两条：标题只用主流拼写形态，变体靠正文自然提及和站内搜索同义词表覆盖；模板不做形态计算，字段取基本形态。

渠道阶段加一件：把品牌转写形态同步给所有经销商和媒体合作方，别让市场替你定。

最后留一句提醒。希伯来语这门语言给你的红利和给你的麻烦是同一个东西——词根系统让你一次找到一批词，不标元音让同一批词长出好几副面孔。红利先拿，麻烦别躲。

## 常见问题解答

## 希伯来语不标元音，会不会导致搜索时大量歧义？

对母语者来说几乎不会，对搜索匹配来说也不是主要矛盾。母语者靠词形规律、语法位置和上下文三重约束消歧，能力极强；而商业查询几乎都是词组不是孤立单词，词组本身就提供了消歧上下文，所以真正因为一词多义而失配的情况远比想象的少。真正咬人的是另一个问题：同一个词的多种合法拼写。因为日常不标元音，规范允许用几个特定的辅音字母来顶替某些元音位置，于是同一个词有了带元音符号的完整形态和补了字母的形态两套写法，后者比前者多出一到两个字符，两种都对，两种都有人敲。实测一份两百词的品类表里，六到七成的词存在两种及以上的常见写法，搜索量分布通常有一个占优但另一个也有可观的量。所以关键词表的结构要改：第一列放概念，第二列才放词形，一个概念下挂两到三种形态，站内搜索的同义词表按这张表配置。

## 词根三辅音对选词到底有什么实际用处？

它是这门语言给你的唯一一处红利，用好了能省掉大量选词工作。希伯来语的词汇大量建立在三个辅音组成的词根上，词根本身不是能读的词，是一个语义种子，套进不同的构词模板就长出一整族词：动作、施事者、场所、工具、结果，词性都可能不同。这跟屈折语的格变化完全不是一回事，格变化改的是同一个词的语法形式，词还是那个词，而词根派生长出来的是一批不同的词。实际做法分三步：先让母语顾问把核心品类词的词根标出来，这对他们是本能，成本极低；再围绕词根列出同族常用派生词；最后把这批词丢进工具查量并按拼写规则展开变体。做完常常会发现同族里有一两个词的搜索量远高于你原本选的那个，而它们在直译词表里根本不会出现，因为直译只给你一个词。但这条路在外来词上失效——科技和医疗领域大量国际词是音译进来的，没有三辅音词根，得走转写那条线。

## 品牌名要不要转写成希伯来字母，怎么定？

建议保留拉丁字母原样作为主形态，同时定一个希伯来转写形态作为补充，两者都能被搜到。以色列市场对拉丁字母接受度很高，国际品牌名在本地网站上大量以原样出现，用户也习惯直接用拉丁字母搜品牌，所以没必要放弃原样形态。但转写形态必须自己定并且定死，因为你不定，市场会替你定出好几个版本——经销商一个、媒体一个、用户论坛又一个，然后品牌搜索量被切成三份，每一份看起来都不值得投入，合并回来比一开始定死难十倍。定下来之后要做三件事：写进页面让两种形态同时出现建立关联；同步给所有经销商、代理、媒体和内容合作方统一使用；把已经在市场上流通的其他版本全部收进站内搜索的同义词表，用户用错版本搜进来也能有结果。总成本大概半天，不做的代价会持续好几年。

## 右到左布局的那些坑，这篇为什么不细讲？

因为那是渲染与布局层的问题，跟具体是哪一门右到左语言无关，阿拉伯语站和希伯来语站遇到的是同一批坑，我在阿拉伯语那篇里已经完整拆过，包括哪几个位置最容易翻车、文本方向属性怎么用、数字和拉丁片段混进右到左句子时的排列规则。这篇要讲的是布局之外那一半：字符串本身的形态问题——元音写不写、字母补不补、词根怎么派生、转写选哪一种，这些跟从哪个方向排版没有任何关系，换成从左往右排问题一个不少。不过希伯来语确实有一个阿拉伯语没有的方向问题值得单说：拉丁字母的混入密度高得多。以色列市场的希伯来语文本里，品牌名、型号、单位、技术缩写很多直接用拉丁原样写，一个商品标题里可能同时有三种方向属性不同的片段，双向混排在这里不是偶发情况而是常态，标点和括号在混排边界上的落点是最常见的显示事故，而且它在开发环境里往往不复现，必须在真机上验。

## 从字典或术语表导入的数据为什么会出问题？

因为这类来源带着元音标记，而用户搜的永远是不带标记的形态。字典数据、教材数据、部分官方术语表都是标注完整的，恰恰又是做多语言站时最容易拿来当种子数据的来源。带标记的字符串和不带标记的字符串在字节层面完全不同，你库里存带标记的，用户敲不带标记的，匹配率直接归零。更隐蔽的是部分带标记的情况——有的词带有的词不带，同一个字段里混着两种，这种数据在抽查时很容易蒙混过关，等到看站内搜索零结果率异常时才发现。处理方法是入库前统一做一次字符规范化把组合标记剥离，同时保留原始数据备查，按标准的规范化形式处理比自己写正则可靠得多。另外还要注意这些标记是组合字符，在字符串里占位置但在屏幕上不单独占宽度，所以按字符数截断的逻辑会出错，可能把一个字母和它的标记截开，产出一个孤立的悬空标记。

## 五个词尾字母变体在技术上怎么处理？

在索引层做归一，展示层严格按正字法。希伯来字母里有五个字母出现在词末尾时换一个写法，字形不同码位也不同，这是纯粹的位置规则，不带语义或语法含义。坑出在两处：一是复合构词时，本来在词尾的字母变成了词中，写法要跟着改而批量脚本经常不改；二是用户做前缀搜索时可能习惯性地把最后那个字母敲成词尾形态，而库里存的是词中形态，两个不同码位直接失配。处理办法是建立词尾形态和普通形态的映射，索引时和查询时都折叠到普通形态上，这个动作只影响匹配不影响展示。展示层该用词尾形态就必须用，写错了以色列用户一眼看出来。开源的希伯来语搜索处理项目就是围绕这类问题做的，词尾归一、拼写变体折叠、形态分析都在覆盖范围内，自己从零写之前先看看已有方案能省掉多少。还有一条：URL和文件名里出现希伯来字母时，词尾处理必须和索引层一致，否则会生成两条指向同一内容的路径。

## 以色列用户英语水平很高，只做英文站行不行？

不行，而且这个市场比北欧更不允许。以色列的英语普及率确实高，专业人群读英文技术文档毫无障碍，所以阻力不在阅读端。但搜索行为的分野很清楚：型号、技术参数、国际品牌名会用英语搜；需求描述、本地服务、保修条款、能不能寄到自己那个地址，一律用希伯来语，而后面这批查询才是靠近转化的那一批。更关键的是信任层面——这个市场对本地存在感的要求高于欧洲平均水平，一个没有希伯来语页面的站，在用户眼里就是一个不打算长期经营这个市场的站，这个判断会直接影响下单意愿。医疗器械这类品类还多一层监管敏感度，用户会主动去找本地语言写的合规说明和售后信息，找不到就停在最后一步，而这个流失不会留下任何可归因的数据。合理的做法是双轨：产品页保证型号和品牌名以拉丁原样出现接住英语查询，分类页、内容页和政策页用希伯来语做深。

## 权威参考资料



## 瑞典语SEO顺手带上挪威丹麦，最后能整块共用的只有商品图和尺寸表

- URL：https://zhangwenbao.com/nordic-seo-swedish-norwegian-danish-content-sharing-boundary.html
- 分类：小语种SEO
- 发布：2012-06-05  |  更新：2026-07-25
- 摘要：讲北欧三语SEO实战：挪威两套官方书面语怎么取舍、丹麦语二十进制数字词会在哪几类页面翻车、后置定冠词让一个商品词分出几种形态、三国字母表排序为何不同、URL转写表怎么分站配置、哪些资产可以整块共用。
- 关键词：关键词研究,内容本地化,小语种SEO

> **TLDR**：摘要：瑞典语、挪威语、丹麦语彼此近到丹麦人和挪威人能对着读同一份说明书，于是预算表上很容易写成一行。但真正能整块搬过去的资产其实很少：商品图、尺寸表、结构化参数这几样，剩下的每一样都要在某个环节动手。挪威一国有两套官方书面语，丹麦语的数字按二十进制念，三国的定冠词粘在名词屁股后面而且尾巴各不相同，连字母表的排序都不是同一套。这篇按资产类型逐层划边界，告诉你哪一层可以照搬、哪一层只换词、哪一层必须重做。

> 摘要：瑞典语、挪威语、丹麦语彼此近到丹麦人和挪威人能对着读同一份说明书，于是预算表上很容易写成一行。但真正能整块搬过去的资产其实很少：商品图、尺寸表、结构化参数这几样，剩下的每一样都要在某个环节动手。挪威一国有两套官方书面语，丹麦语的数字按二十进制念，三国的定冠词粘在名词屁股后面而且尾巴各不相同，连字母表的排序都不是同一套。这篇按资产类型逐层划边界，告诉你哪一层可以照搬、哪一层只换词、哪一层必须重做。

做家用安防的一个客户，主力是指纹门锁和室内摄像头。瑞典站跑了半年，数据漂亮，团队士气高涨，会上有人提议：挪威和丹麦顺手一起上吧，反正语言差不多。

这句话前半段是对的，后半段是灾难的开始。

三个月后复盘，挪威站的自然流量只有瑞典站的三成——而挪威的人均电商支出比瑞典还高。丹麦站更奇怪，产品页排名不错，促销落地页几乎颗粒无收。

问题不在翻译质量。三份文案都是母语译者交付的，读起来都很自然。问题在于，团队默认这三门语言的差异只发生在词汇层，于是只换了词，没换结构、没换数字、没换排序、也没意识到挪威一个国家里存在两套并行的书面标准。

北欧三语这件事的特殊之处，不是它难，而是它看起来太不难了。

## 北欧三国到底算三个市场还是一个？

从语言学的角度，瑞典语、挪威语、丹麦语属于同一个分支，词汇重合度高，语法框架几乎平行。把三份文案摊在桌上，不懂北欧语的人会以为是同一篇的三个排版版本。

从商业的角度，它们是三个独立国家、三种货币、三套税制、三个物流网络，其中一个还在欧盟之外。

这两件事同时成立，才造成了最容易踩的那个坑：语言的近似度诱导你按一个市场做预算，而市场的分离度决定了你必须按三个市场收流量。

所以这篇的问题不是“要不要三套内容”，而是把内容拆成资产类型之后，每一类的共用边界分别落在哪一层。答案对每一类都不一样，笼统地问“能不能共用”，只会得到一个笼统的错答案。

## 为什么“斯堪的纳维亚一次做完”在预算表上成立、在关键词表上不成立？

预算表看的是投入：三个市场共用一套视觉、一套产品数据、一套物流谈判，边际成本确实低。这也是为什么北欧常被当成一个区域包打包卖。

关键词表看的是产出：搜索词是用户敲进去的，用户敲的是自己国家的说法，不是“斯堪的纳维亚语”——世界上没有这么一门语言。

把这两张表混在一起看，就会得出“投入省了七成，产出也该有七成”的错觉。实际情况是投入确实省了，产出却按国家线被切开了。

更隐蔽的是，这个错觉在早期数据上不会暴露。品牌词和型号词在三国是一样的，前两个月的流量看起来相当健康，等到需要靠品类词和长尾词撑量的时候，缺口才一次性显形。

## 三种语言的近似度到底有多高，能不能量化？

拿一份常见的家居品类词表做过手工比对，粗略的分布是这样的：约三成的词三国拼写完全一致，约四成差一到两个字母，剩下约三成是不同的词。

三成完全一致，听起来很鼓舞人。但要注意，这三成里绝大多数是外来词和技术词——摄像头、传感器、电池这类。这些词恰恰是竞争最激烈、转化最差的那批。

差一两个字母的那四成，才是真正的陷阱区。它们看着像同一个词，搜索引擎却当两个词处理，而人眼审校时最容易一扫而过。

完全不同的那三成里，很多是高频生活词——门、锁、警报、邻居。这些词落在你的分类页标题和面包屑上，也就是权重最高的位置。

这个比对不需要多复杂的工具，一张三列表格就够：核心词一列，三国写法各一列，末尾加一列标注差异等级。两百词的表，两个人半天能核完，而它决定的是后面三个市场几个月的流量结构。

唯一的要求是三列必须由三个不同国家的母语者填，不能一个人填三列——原因下面讲审校时会展开，这里先记一句：读得懂，恰恰是判断力下降的开始。

## 书面互读和口语互听为什么会反向？

这是北欧三语最有意思的一件事。丹麦语和挪威语的书面形态高度接近，一个挪威人读丹麦语文本几乎无障碍；但丹麦语的口语发音大幅弱化，同样这个挪威人听丹麦人说话，可能得请对方重复两遍。

反过来，瑞典语和挪威语的口语互通度比书面还高一些，两国人各说各的话也能聊下去。

这件事对内容资产有直接后果：文字资产的跨国复用上限，高于音视频与客服脚本的复用上限。

所以如果你要做产品视频、语音客服、播客形式的内容营销，别指望“录一版北欧通用”。文字层面还能商量，声音层面商量不了。

## 挪威语为什么有两套官方书面语？

因为历史。挪威长期与丹麦共主，官方书面语基本就是丹麦语；独立进程中，一支主张在丹麦语基础上逐步挪威化，另一支主张回到各地方言重新构建。两条路线最后都获得了法律承认。

结果就是今天这个局面：一个国家，两套官方书面标准，都合法，都能用于公文，公共机构还要保证两者都有一定比例的使用。

使用人口是严重不均衡的，绝大多数挪威人日常写的是其中一套，另一套主要集中在西部一些地区。

但“少数”不等于“可以忽略”。挪威总人口五百多万，另一套书面语的核心使用群体是几十万人量级——放在小语种市场的语境下，这个数字不算小。

## 两套书面语在关键词表上差多少，要不要做两份？

差多少要看词。功能词和高频动词差得明显，很多具体名词差得很小甚至一样。一份两百词的家居品类表，实测大概会有三到五成的词形不同。

做不做两份，我的建议是分层：先做主流那一套，把另一套当作变体收录进关键词表，而不是当作第二个站点来建。

理由是投入产出。建第二套完整内容意味着页面翻倍、维护翻倍、内链结构复杂化，而收益只覆盖一部分区域用户，而且这部分用户对主流书面语的阅读完全没有障碍。

但站内搜索和词表必须双向覆盖。用户用哪一套书面语敲进来，你的搜索框都得给出结果，这个成本很低，漏掉的代价却很直接。

## 挪威一国内部的书面语选择怎么定优先级？

三条判据，按顺序用。

第一条看品类的地域分布。如果你的产品在西部沿海地区有明显的使用场景优势，比如户外、渔业、船艇相关，另一套书面语的权重要往上调。家用安防属于城市化品类，主流那一套就够。

第二条看搜索日志。上线三个月后，日志里另一套书面语的词形占比如果超过一成，说明值得单独做几个落地页。

第三条看竞争。主流书面语的词竞争密度高，另一套的词往往几乎没人做。如果你的品类在主流那一侧已经打不动了，这里反而是个便宜的切口。

## 丹麦语的数字为什么按二十进制数？

丹麦语里五十以上的整十数不是按十进制构造的，而是以二十为基数。六十字面上是“三个二十”，八十是“四个二十”，五十更绕，字面意思接近“第三个二十的一半处”。

这不是方言土话，是标准语的规范写法，学校教的、报纸印的、合同上写的都是这一套。

瑞典语和挪威语在这件事上完全正常，整十数就是数字词根加上表示“十”的后缀，跟英语、德语的构造逻辑一致。

所以在三国之间，凡是把数字写成单词的地方，丹麦语那一版都是彻底另一套，不是“差一两个字母”，是从构词法上就不一样。

顺带说一句，丹麦人自己对这套数字系统也没什么感情。跨北欧的会议上报数字时，丹麦人经常主动切成十进制说法，免得对面算半天。但这是口语场景的妥协，写进正式文案的还是标准那一套。

指望机器翻译绕过去也不现实。机翻处理阿拉伯数字没问题，处理写成单词的数字时，经常会把瑞典语的构造原样搬过来，产出一个语法上说得通、丹麦人却从来不这么写的形式。

## 二十进制数字词会在哪些页面上真正咬到你？

四个地方，都不是边缘页面。

促销页首当其冲。折扣写成阿拉伯数字加百分号当然没问题，但北欧的促销文案很爱把数字写成单词，尤其是标题和短句里。丹麦版照搬瑞典版的写法，读起来就是外国人写的。

其次是满额门槛。免运费门槛、赠品门槛这类信息在丹麦文案里写成单词的比例很高，而这类短句正是用户会原样搜进去的。

第三是规格描述。尺寸、时长、容量的口语化表达。

第四是站内搜索的容错。用户敲的是丹麦式的数字词，你的索引里存的是从瑞典版机翻过来的形态，直接零结果。

## 三国的价格与货币写法差在哪？

三国用三种不同的克朗，代码不同，符号在实际书写中常常直接省略成“kr”，于是页面上三国看起来一模一样，实际是三个数值体系。

这件事最容易出的事故是跨境比价：用户在挪威站看到的数字和在瑞典站看到的数字，如果没有明确的货币标识，会被当成同一个币种直接比较。

小数点与千位分隔符的写法在三国基本一致，都用逗号做小数点，这一点反倒省心。

但增值税率三国不同，含税与不含税的展示习惯也不同。价格模块是那种“逻辑共用、数据分离、文案还要各写一份”的典型资产。

## 后置定冠词是什么，为什么比“the”难对付？

英语的定冠词是一个独立的词，摆在名词前面。北欧三语的定冠词是一个后缀，直接粘在名词末尾。

用瑞典语的“椅子”举例：不带冠词是stol，带上定冠词变成stolen，复数是stolar，复数带定冠词是stolarna。四个形态，四个不同的字符串。

这就是它比英语难对付的地方：英语里the和chair是两个token，分词一切就分开了，chair本身的形态没变；北欧语这里，冠词的信息被编码进了词的末尾，词本身变了。

后果是，任何基于精确匹配的机制——站内搜索、筛选器、商品映射、URL生成——都会把这四个形态当成四个东西。

## 一个商品名词在北欧语里到底有几种搜索形态？

基础是四种：单数不定、单数定、复数不定、复数定。

再叠上属格。北欧三语的属格通常是加一个s，于是四种各自再生一个带s的形态，理论上到八种。

实际做词表不用收八种。用户搜索时用单数不定和复数不定的比例最高，这两个先收满；单数定形态在具体指代的语境下会出现，值得收；剩下的靠索引层处理。

这个规模比斯拉夫语系温和得多——如果你做过波兰语或俄语那种一个名词七八个格再乘单复数的市场，会觉得北欧这边简直是度假。相关的收录判断可以参考波兰语七个格的变体收录方法 (https://zhangwenbao.com/polish-seo-seven-cases-diacritics-keyword-research.html)，思路是通用的，只是规模缩小了一个量级。

## 三国的定冠词尾巴一样吗？

不一样，而且不一样的地方正好在复数上。

单数定冠词形态在三国比较接近，都是加一个类似en的后缀，看着几乎一致。

复数定冠词就分开了：瑞典语一套，挪威语和丹麦语另一套，而挪威语和丹麦语之间还有细微差别。也就是说，你不能靠“改单数就顺带改了复数”的假设来批量转换。

更麻烦的是名词的性。瑞典语和丹麦语的名词分两性，挪威语的主流书面语可以按两性也可以按三性处理，而定冠词后缀是跟着性走的。同一个词在三国可能挂不同的尾巴。

这就是我说“差一到两个字母的那四成才是陷阱区”的原因——差异小到人眼会自动脑补，机器却完全不会。

## 词干提取器能不能替你消化后置定冠词？

能消化一部分，不能全消化，而且三国要用三个不同的规则集。

开源的瑞典语词干算法 (https://snowballstem.org/algorithms/swedish/stemmer.html)把常见的定冠词后缀和属格s列进了后缀表，切掉之后能把大部分形态归一到同一个词干上。丹麦语的规则集 (https://snowballstem.org/algorithms/danish/stemmer.html)是另一份，后缀表和处理顺序都不同。

它们的共同局限是：按字符规则切后缀，不查词典。所以碰到词根末尾恰好长得像后缀的词，会切过头，把不该切的部分也切掉。

实用做法是把词干还原只用在站内搜索的召回层，别用它去生成面向用户展示的文字。召回多一点没关系，展示错了很难看。

还有一件事要提前决定：词干还原是在索引时做还是在查询时做。两边都做是标准配置，只做一边会出现“库里存的是原形、用户搜的是变形”这类单向失配，排查起来相当费时间。

另外别指望一个词干规则集通吃三国。三份规则的后缀表和处理顺序都不一样，混用会在复数定式那一批词上系统性出错，而那正好是分类页最常用的形态。

## 瑞典和挪威丹麦的特殊字母根本不是同一组，怎么办？

瑞典语的三个特殊字母是ä、ö、å；挪威语和丹麦语是æ、ø、å。前两个位置上，同一类音在瑞典和挪威丹麦之间用的是完全不同的字母。

这意味着一个在三国拼写“几乎相同”的词，可能恰恰在这个字母上分家。你的批量替换脚本如果只处理了词尾，这里就会漏。

做法上有两条硬要求。第一，字符集白名单必须把六个字母全放进去，别按国家分别配置，因为品牌名和人名会跨国出现。

第二，数据库和索引的字符集别在这里省事。这几个字母的码位都在拉丁字母扩展区，任何一处编码配置不当，都会在页面上变成问号或方框，而这类问题往往先在客服工单里被发现，而不是在监控里。

## 三国的字母表排序顺序为什么不一样？

因为这几个特殊字母在三国的字母表里被放在了不同的位置。瑞典语把å排在z之后，接着是ä和ö；挪威语和丹麦语则是æ、ø、å这个顺序排在最后。

所以同一批品牌名，用瑞典语排序规则排出来的顺序，和用丹麦语规则排出来的顺序，在这几个字母上是错开的。

语言环境排序规则的规范文档 (https://www.unicode.org/reports/tr35/tr35-collation.html)里，这三种语言各有自己的排序表，不是同一份。这件事在代码层的表现是：你得给三个站点分别指定排序规则，而不是用一个通用规则打天下。

顺带提醒一句，用默认的通用规则排出来的结果，在北欧用户眼里不是“稍微有点乱”，而是“这个列表根本没排序”。

## A-Z索引和字母导航在三国要不要各做一套？

要，但成本比想象的低，因为这是配置问题不是内容问题。

受影响的地方主要三处：品牌索引页、术语表或帮助中心的字母导航、筛选器下拉里的选项排序。

三处都指向同一个技术动作——在数据库排序规则或查询层指定对应语言的规则，一次配置全站受益。

还有一个容易漏的地方：分页锚点。如果你的品牌索引页按首字母分页，瑞典站的最后三个锚点和丹麦站的最后三个锚点是不同的字母，模板里写死就会出现空页面。

## URL里的特殊字母该怎么转写？

三国的习惯转写方式并不统一，这是个真实存在的分歧点。

瑞典语的ä和ö在URL里通常转成a和o，å也转成a。挪威语和丹麦语这边，æ传统上转成ae，ø转成oe，å转成aa——这几个双字母组合本来就是这些字母的历史写法。

问题来了：如果你用一套通用的转写规则，把æ也转成a，挪威用户看到的URL会有点怪；反过来把瑞典语的ä转成ae，也不地道。

建议按站点分别配置转写表，并且一旦上线就冻结。转写规则改一次就是全站URL变更，代价远高于一开始多花半小时讨论。

还要留意一个副作用：不同的转写规则会让同一个词生成不同长度的URL段。æ转成两个字母，路径就比转成一个字母长，批量生成时如果有长度上限的截断逻辑，两国的截断位置会不一样，产出一批看起来很像但其实对不上的路径。

另外别忘了历史URL。如果瑞典站先上线并且用了一套转写规则，后面加挪威站时保持规则族一致会让运维省心很多——三套规则可以不同，但三套规则的实现方式最好是同一个函数加不同的映射表。

## 复合词在北欧三语里也粘成一个词吗？

粘，而且粘得挺厉害。洗衣机、咖啡研磨机、门锁这类概念在三国都是两三段词根直接拼成一个长词，中间不留空格也不加连字符。

这带来的第一个后果是标题长度。同样一个商品概念，北欧语版本的字符数常常比英语版多出三到五成，标题截断的压力更大。

第二个后果是切分。用户搜复合词的其中一段时，如果索引层没做切分，就匹配不上整词。

复合词这套问题的完整处理方法，德语复合词那一篇 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)已经讲透了，这里不重复，只说北欧和德语不一样的地方。

## 北欧三语的复合词和德语复合词差在哪？

差在连接成分的规则密度。

德语的复合词经常需要在两段之间加一个连接音，加什么、加不加，规则相当复杂，是切分算法的主要难点。

北欧三语这边，连接成分也存在，但形式更少、规律更强，很多复合词就是两个词根直接拼接。这让切分算法的准确率高一截。

但北欧这边有个德语没有的麻烦：复合词的最后一段决定整词的性，而性又决定定冠词后缀。所以切分和形态处理是耦合的，不能像德语那样先切完再说。

还有一件让人哭笑不得的事——北欧语的复合词写错了空格，句子往往还能读通，但意思完全变了。当地媒体每年都要拿这类例子做一轮语言普及，可见踩的人不少。

## 挪威在欧盟之外，这件事怎么变成关键词？

挪威不是欧盟成员，跨境购物要过关税和进口增值税这一关，有免税额度，超额就要交钱。瑞典和丹麦是欧盟成员，欧盟内部购物没有这个问题。

于是挪威用户在决策链条上多了一个动作：查这单会不会被收税。

这个动作会变成搜索词。围绕免税额度、关税计算、清关时长的查询，在挪威是实打实的高频长尾，在瑞典和丹麦几乎不存在对应需求。

这就是一整批挪威独有的内容机会，而且转化意图极强——会搜这个的人已经在准备下单了。你要做的就是一个说清楚规则的页面，配上一个能算的工具。

这类页面还有个额外好处：它天然吸引外链。本地论坛和消费类社区讨论跨境购物时，需要一个能引用的规则说明，而大多数品牌站不提供这个，只给一句“可能产生额外费用”就打发了。

反过来，这也是判断挪威值不值得单独投入的一个信号——如果你的品类客单价正好卡在免税门槛附近，挪威市场的转化会对这个页面异常敏感，做与不做的差距能到肉眼可见的程度。

## 三国的配送与退货词汇差在哪？

差在两个层面。

词汇层面，配送、退货、包裹、取件点这几个高频词在三国有不同说法，其中取件点这个概念最本地化——三国的主流物流网络不同，用户搜的是具体的网络名称，不是通用词。

结构层面，挪威因为在欧盟外，退货流程涉及跨境退税，页面要多讲一段。瑞典和丹麦可以共用一套流程说明的骨架。

这就是典型的“骨架共用、内容分叉”资产。模板一套，文案三份，其中挪威那份多一个区块。

## 商品属性字典能不能三国共用？

字典的结构能共用，值不能。

属性名和枚举值都要三份，因为它们直接出现在筛选器界面上，也直接出现在用户的搜索词里。颜色、材质、安装方式这类枚举值，恰恰是那三成“完全不同的词”的重灾区。

但结构——哪些属性、哪些属性可筛选、枚举值的取值范围、层级关系——这一层完全能共用，而且必须共用，否则后期做跨市场分析会自己给自己挖坑。

实操上建议维护一份语言无关的属性键，三份语言相关的显示值，映射关系写死。这样加一个新市场只是加一列，不是重做一张表。

枚举值这一列还要额外做一件事：把每个值的常见搜索变体一并登记。用户在筛选器里点的是你给的那个词，但在搜索框里敲的可能是另一个说法，两者对不上就是零结果，而筛选器和搜索框在大多数站上是两套逻辑。

见过一个真实的翻车现场：属性值三国填的都是同一个词，因为负责的人查了词典确认三国都有这个词、意思也一样。问题是其中一国日常根本不用它，那是个书面语词，用户从来不会那么搜。词典对，市场不对。

## 商品标题模板能不能三国共用？

模板的字段顺序能共用，拼接逻辑要各写一份。

原因还是定冠词和性。如果模板里有需要跟名词保持一致的成分，三国的规则不同，一套逻辑跑三个市场必然出错。

我的建议跟在其他屈折程度较高的语言里一样：模板里的字段一律取词典基本形态，字段之间用符号或空格隔开，不构造完整句子。品牌、型号、品类、关键规格这四段拼起来，在三国读起来都正常，而且一次形态计算都不用做。

真正需要接住带冠词形态的查询，靠正文和索引层，不靠标题。

## 元描述与正文要不要各写一份？

要，而且这是三类资产里最不能省的一类。

元描述直接出现在搜索结果里，用户是拿它跟本地竞品的描述并排比较的。一份读起来像“隔壁国家翻过来的”描述，点击率的差距会很直接。

正文更不用说。正文承载的是需求侧的长尾词，而需求侧的表达恰恰是三国分歧最大的地方。

可以省的是什么？技术规格段落、安装步骤、包装清单这类信息密度高、表达空间小的内容，翻译加本地词替换就够，不需要重写。

## 三国的英语能力都很强，能不能直接上英文页？

不能，但理由和大多数人想的不一样。

北欧三国的英语水平在全球排名靠前，用户看英文页面确实没有阅读障碍。所以问题不在“看不懂”。

问题在于用户不会用英语搜本地需求。查一个型号参数，他可能用英语；找本地退货政策、比较本地服务、确认能不能寄到自己那个邮编，他一定用母语。而后者才是转化前的最后一步。

结果就是那种最难归因的流失：流量数字看着还行，转化率上不去，因为用户在掏钱前去找母语写的条款，没找到，默默走了。这个动作不留下任何数据。

## 搜索引擎在北欧三国的分布会改变语言层的判断吗？

基本不会。北欧三国的搜索市场集中度很高，不像俄语区或韩语区那样存在体量相当的本土引擎，所以不存在“为另一个引擎单独做一套”的问题。

引擎层面的打法差异，属于另一个话题范畴，这篇不展开。语言层要关心的是词形、排序、字符集和内容形态，这几件事跟哪个引擎在收录没有关系。

唯一值得注意的是本地比价与聚合渠道。北欧的比价平台流量占比不低，而它们对商品数据的字段要求是按国家来的，这属于渠道层的事，也不影响语言层的结论。

## 瑞典语和挪威语有音高重音，这对内容有影响吗？

对文字内容没有直接影响，但它解释了一个常被误判的现象，而且在语音场景里会变成真问题。

瑞典语和挪威语的很多词有两种音高模式，同样的拼写、同样的字母序列，读法不同，意思也不同。丹麦语没有这套，它走的是另一条路——用喉音变化来区分。

文字层面完全看不出差别，所以你的关键词表不受影响。但两件事会受影响。

一是语音搜索与语音助手场景，同形不同音的词在识别端就可能出错，而你无法在内容层修复。二是产品视频和音频广告的配音，找错了口音的配音员，北欧听众的违和感比欧洲其他市场强烈得多——这也印证了前面那条结论：音视频资产的跨国复用上限远低于文字资产。

## 星期和月份名的大小写有什么坑？

坑不在语言，在你的技术栈。

北欧三语的星期名和月份名一律小写，这跟英语的首字母大写习惯正好相反。而大量前端库、日期组件、邮件模板的默认行为是按英语习惯首字母大写。

结果是页面上出现一堆首字母大写的星期和月份，在北欧读者眼里就是明显的外国人写的，尤其集中在配送时效、活动倒计时、订单状态这些高频模块上。

排查方法很直接：把站上所有会渲染日期的组件列一遍，逐个看输出。这类问题不会有人报bug，因为它不影响功能，只影响观感，而观感的损失只会体现在转化率上。

顺带一提，句子开头的首字母当然还是要大写，所以不能简单地全部转小写了事，得让日期库用对语言环境。

## 品牌名加属格时该怎么写？

三国规则相似但不完全一致，而这个位置的错误特别显眼——它出现在页面标题和导航里。

北欧三语的属格通常是直接加一个s，不加撇号，这跟英语不同。所以品牌名加属格时，正常写法是品牌名后面直接跟s。

例外在于品牌名本身以s、z或x结尾的情况。这时候三国的处理有分歧，有的用撇号，有的干脆改写句式绕开。

实用建议是：品牌名尽量别用属格。改用介词结构，或者把品牌名单独放在标题开头用符号隔开。这样三个市场用同一套模板，一次形态计算都不用做，也不会有人写错。

## 地址与表单字段在三国要怎么配？

三国的邮编位数不同、格式不同，城市与邮编的排列顺序也有各自的习惯。

所以表单验证规则必须按国家分别配置，用一套正则打三个市场，一定会在某一国拒绝掉合法地址。而在结账页拒绝一个合法地址，等于直接丢单。

还有一个更隐蔽的：三国都有大量地名和街道名带着那六个特殊字母。如果你的表单字段做了字符限制，或者后端存储的字符集配置不当，用户会发现自己的地址填不进去，或者填进去了但配送标签上是乱码。

建议在上线检查清单里加一条：用三个国家各自的真实地址各下一单，从填表到生成配送标签整条链路走通一遍。这个测试半小时能做完，能挡掉一类最贵的事故。

## 搜索建议和自动补全在北欧语里会怎么表现？

会因为后置定冠词而变得比英语更重要，也更容易出问题。

用户在你的站内搜索框里敲品类词时，敲的往往是不带冠词的裸形态，而你的商品数据里可能存的是带冠词的形态。补全逻辑如果按前缀严格匹配，裸形态能补出带冠词的（因为冠词在词尾，前缀相同），反过来却补不出来。

这个方向性问题在北欧语里正好是好消息——冠词在词尾意味着前缀匹配还能用，这比希伯来语那种前缀粘在词头的语言好处理得多。

但复合词会把这个好消息抵消掉。用户搜复合词的后半段时前缀完全对不上，补全一条都出不来。解决办法是给补全的候选源额外加一份按词素切分后的索引，让后半段也能命中。

## 关键词工具在北欧三语上够不够用？

比大多数小语种好，但有两个必须手工修正的偏差。

第一个偏差是形态拆分。带定冠词的形态和裸形态在工具里是两条记录，各给一个数字。虽然形态数量比斯拉夫语系少得多，但两条相加之后的排序变化足以影响品类优先级。

第二个偏差更隐蔽：三国的数据经常被工具混在一起。因为词形高度相似，有些工具的语言识别会把挪威语的词判成丹麦语，或者把三国的量合并成一个“斯堪的纳维亚”口径。拿到数据先确认它到底是按国家切的还是按语言切的，这两者在北欧不是一回事。

没数据时的补法跟其他小语种一样，按可靠性从低到高：抄本地竞品的分类树与筛选项、看本地比价平台的属性命名、最后是自己站内搜索的日志。第三个要等一个月，但等到了就是最可靠的依据。

## 三国的内容语气和信任元素有什么差别？

语气上三国相当接近，都偏克制、平实、少夸张，跟南欧市场的表达风格差异明显。促销文案里的强烈感叹和绝对化措辞在这里会降低可信度，而不是提升转化。

信任元素上有几处本地化要点。用户对配送时效的承诺敏感度很高，写不清楚就会流失；退货政策的可见度要高，最好在产品页就能看到；本地支付方式的支持情况要在结账前明示。

还有一条是环境与可持续信息。北欧市场对这类信息的关注度高于欧洲平均水平，但同时对空泛的表述容忍度很低。有具体数据就写，没有就别写，写了没数据反而是减分项。

这几条内容上都是各国一份，但结构完全可以共用——又一次印证了资产分层这个框架：结构共用，文案分离。

## 母语审校在三国要不要请三个人？

要三个人，但不需要三个全职。

关键在于别让一个人兼两国。一个丹麦审校看挪威语文案，他能读懂，也能挑出明显错误，但挑不出“这句话丹麦人不会这么说”这类问题——因为在他眼里那句话本来就没错。

近亲语言的审校最怕的就是“读得懂”。读得懂会大幅降低审校的敏感度，这一点在同语族的市场里反复被验证。

验收清单可以三国共用：品类词是否本地说法、定冠词形态是否一致、数字与货币写法是否正确、特殊字母是否显示正常、有没有出现另外两国的词。最后一条最实用，专治机翻串味。

审校的排期也有讲究。别等文案全部写完再一次性送审，先送一批样本页——一个分类页、一个产品页、一个促销页——把系统性问题在这三页上抓完，再放量生产。系统性问题是会复制的，晚发现一周就多改几百页。

还有一个便宜的补充手段：让三位审校互相看另外两国的版本，只标记“这个词我们这边不这么说”。他们能读懂邻国文案这件事在这里终于变成了优势，因为你要的正是“哪里串味了”，不是“哪里写错了”。

## 三个市场的预算怎么切，先做哪一个？

先看两个数：市场规模与竞争密度。

瑞典人口最多，市场最大，竞争也最激烈。丹麦人口最少但人均消费高，物流条件好。挪威人均购买力最强，但欧盟外的关税门槛会过滤掉一部分低客单价品类。

常规顺序是瑞典打头阵，因为它能最快跑出可用的数据，验证品类和文案方向。

但如果你的客单价偏高、品类不吃关税敏感度，挪威优先反而更划算——竞争稀薄，转化率高，同样的投入能拿到更好的数据。这个判断在低竞争小市场里通用，和荷兰与比利时那笔预算账 (https://zhangwenbao.com/dutch-seo-netherlands-belgium-flemish-two-markets.html)是同一套算法，只是这里要算三个国家。

## 这套判断跟“两个近亲市场要不要分开做”是同一个问题吗？

不完全是，这里要把边界说清楚。

“两个近亲市场要不要两套预算”是一个二选一的决策，判据是复用等级——能照搬、只换词、还是必须重写。这个决策框架我在捷克语和斯洛伐克语那篇 (https://zhangwenbao.com/czech-slovak-seo-content-reuse-decision.html)里完整讲过，包括三档判据怎么定、假朋友清单怎么建、历史断点怎么影响市场分离，这里不重复。

北欧这边是三个市场，而且三者两两之间的距离并不相等——挪威语和丹麦语书面接近，挪威语和瑞典语口语接近，瑞典语和丹麦语两头都不太近。二选一的框架在这里不够用。

所以这篇用的是另一套：不问“分不分开做”，问“每一类资产的共用边界在哪一层”。资产分层比市场二分更适合三个以上的近亲市场。

## 哪些资产可以整块照搬？

三类，数量比大多数人预期的少。

第一类是视觉资产：商品图、场景图、图标、视频的画面部分。这些完全不含语言信息，三国共用零风险。

第二类是结构化的数值参数：尺寸、重量、功率、电池容量、防护等级。北欧三国都用公制，数值本身不需要换算，只有单位缩写要核一遍。

第三类是页面结构与模板：字段顺序、模块排布、内链结构、面包屑层级。这一层共用不仅省事，而且必须共用，否则跨市场对比数据会失真。

## 哪些资产只需要换词？

两类。

技术规格段落和安装说明这类信息密度高、表达空间窄的文本，本地化到词汇层就够。这里的要求是准确，不是地道。

还有商品属性的枚举值。前面说过结构共用、值分开，而“分开”的动作就是换词——同一个属性键下换三份显示值，工作量可控。

这两类的共同特征是：句式简单、主观表达少、几乎不承载长尾词。所以翻译加词表校对就够，不需要重写。

## 哪些资产必须各做一份？

四类，一类都不能省。

标题与元描述，因为它们直接进搜索结果，也直接承载核心词的本地形态。

分类页与落地页正文，因为需求侧的长尾表达三国分歧最大。

价格、税费与配送信息，因为这是三套规则，尤其挪威那一套完全独立。

促销文案，因为它是数字词、口语表达和文化梗最密集的地方，也是丹麦语二十进制数字最容易翻车的地方。

这四类有个共同特征：它们都直接暴露在用户的判断面前——要么出现在搜索结果里，要么出现在决定买不买的那一屏上。省这四类的钱，省下来的都会从转化率里扣回去。

反过来也说明预算该往哪儿放。如果三个市场的总预算只够做深一个半，那就把钱全押在这四类上，前面两层该共用共用、该换词换词，别在模板和图片上再花心思。

## 一份可以照着走的北欧三语资产分层清单

启动阶段先做三件事：确认品类词在三国的本地说法（重点核那“差一两个字母”的四成）、给三个站点分别配好排序规则与转写表、把六个特殊字母全部加进字符集白名单。

内容阶段按分层执行：视觉与数值参数共用，模板结构共用，规格与属性值换词，标题元描述与正文各做一份。

挪威站额外加两件：主流书面语之外的词形收进词表与站内搜索，做一组关税与免税额度的内容。

丹麦站额外加一件：把所有写成单词的数字通读一遍，尤其是促销页和门槛类文案。

上线后看三个指标：站内搜索零结果率（暴露词形覆盖不足）、三国的品类词排名差（暴露本地词选错）、政策页停留后的流失（暴露信任信息缺失）。保哥的经验是，前两个月这三个指标能把八成的本地化问题都照出来。

## 常见问题解答

## 瑞典语、挪威语、丹麦语真的能互相看懂吗，那为什么还要做三套内容？

书面上确实能看懂相当一部分，尤其是挪威语和丹麦语之间，读一份说明书基本没障碍。但看得懂和会这么搜是两件完全不同的事。用户敲进搜索框的是自己习惯的说法，不是他能理解的说法，而搜索引擎做的是字符串匹配，不会替你把三国的说法归并成一个概念。更实际的问题在转化端：能看懂邻国的文案，不代表看到邻国的文案时不会犹豫。北欧用户对本地化程度相当敏感，一份读起来像从隔壁翻过来的页面，会在信任层面扣分，而这个扣分不会显示在任何报表里，只会显示在转化率上。所以正确的问法不是要不要三套，而是哪一层要三套——视觉和数值参数一套就够，标题、正文和促销文案必须三套，中间还有一层只需要换词。按资产类型分层，比笼统地决定做几套内容准确得多，成本也低得多。这个分层一旦定下来，后面加第四个北欧市场时可以直接套用，不用重新论证一遍。

## 挪威的两套官方书面语，我到底要不要做两个版本的内容？

不建议做两个版本的完整内容，建议做一个版本加一份变体词表。理由是投入产出比：建第二套完整内容意味着页面数、维护量、内链复杂度全部翻倍，而覆盖的是一部分区域用户，这部分用户读主流书面语毫无障碍。但有两件事必须做。第一是站内搜索和关键词表要双向覆盖，用户用哪一套书面语敲进来都得有结果，这个成本很低，漏掉的代价却是直接的零结果。第二是看日志再决定要不要加码，上线三个月后如果另一套书面语的词形占比超过一成，或者你的品类恰好在西部沿海地区有使用场景优势，就值得针对性地做几个落地页，而不是整站再来一遍。还有一个便宜的切口：主流书面语那一侧的词竞争密度更高，另一侧往往几乎没人做，如果你在主流那边已经打不动了，这里的性价比反而更好。判断依据只看两样：品类的地域分布，和上线后的站内搜索日志。

## 丹麦语的二十进制数字，具体会在哪些地方出问题？

四个地方，都不是边缘页面。促销页最先中招，北欧促销文案很爱把数字写成单词，尤其在标题和短句里，丹麦版照搬瑞典版的构词就是明显的外国人腔。其次是免运费门槛、赠品门槛这类满额信息，用户会原样把这类短句搜进去。第三是规格的口语化表达，比如描述时长和容量时。第四也是最容易被忽略的，是站内搜索的容错——用户敲丹麦式的数字词，你的索引里存的是从瑞典版转过来的形态，直接零结果，而这类零结果在报表里只是一个数字，看不出原因。处理办法很简单：让丹麦母语审校专门通读一遍所有把数字写成单词的地方，同时在站内搜索的同义词表里把三国的数字词形态互相映射。这是一次性的工作，做完就长期有效。也别指望机器翻译能绕过去，它经常把瑞典语的构造原样搬到丹麦语上，产出一个语法说得通、丹麦人却从不这么写的形式。

## 后置定冠词会让关键词量翻几倍，词表要收到什么程度？

理论上一个名词有八种形态：单复数各自的不定式和定式，再各自加属格。实际收录不用收满。优先收单数不定和复数不定这两个，用户搜索时用这两种形态的比例最高；单数定形态在具体指代的语境里会出现，值得补上；剩下的交给索引层的词干还原处理，不必进词表。所以一个核心词收三到四个形态就够，比斯拉夫语系那种一个名词七八个格再乘单复数的规模温和得多。要注意的是，三国的定冠词后缀不一样，尤其在复数上分成两派，你不能靠改了单数就顺带改了复数的批量替换来生成另外两国的词表。还有名词的性会影响挂哪个尾巴，同一个词在三国可能挂不同的后缀。这个差异小到人眼审校会自动脑补过去，机器却完全不会，所以建议用词典逐词核，别用规则批量生成。

## 三国的字母和排序差异，在技术上要改哪几个地方？

主要三处，都是配置层的事，不涉及内容。第一处是数据库或查询层的排序规则，给三个站点分别指定对应语言的规则，别用通用规则打天下——用通用规则排出来的品牌列表，在北欧用户眼里不是稍微有点乱，而是根本没排序。第二处是URL转写表，瑞典语习惯把两个变音字母转成对应的基本字母，挪威语和丹麦语则习惯转成双字母组合，这几个组合本来就是这些字母的历史写法，混用会显得不地道。转写规则一旦上线就要冻结，改一次就是全站URL变更。第三处是字符集白名单，六个特殊字母全部放进去，别按国家分别配置，因为品牌名和人名会跨国出现。另外有个容易漏的细节：按首字母分页的品牌索引页，三国的最后几个锚点字母是不同的，模板里写死会出现空页面。

## 北欧三国英语普及率很高，只做英文站行不行？

不行，但原因不是用户看不懂。北欧三国的英语水平在全球排名靠前，读英文页面确实没有障碍，所以阻力不在阅读端，在搜索端和转化端。搜索端的规律是：查具体型号和技术参数时，用户可能直接用英语；但描述需求、做比较、找本地退货政策、确认能不能寄到自己那个邮编时，几乎全用母语。而后面这批查询才是靠近转化的那一批。转化端的规律更隐蔽：用户能看懂英文商品页，但在付款前会本能地去找母语写的条款和客服入口，找不到就默默离开了，这个动作不产生任何可归因的数据，你只会看到一个偏低的转化率和一个看起来还不错的流量数字。客单价越高的品类，这笔账越明显。合理的做法是双轨：产品页保证型号和品牌名原样出现以接住英语查询，分类页、内容页和政策页用本地语言做深。

## 三个市场先做哪一个，预算怎么切？

常规答案是瑞典优先，因为它人口最多、市场最大，能最快跑出可用的数据来验证品类方向和文案思路。但有两个例外值得考虑。第一个例外是高客单价品类：挪威人均购买力最强，竞争密度明显低于瑞典，同样的投入能拿到更好的排名和转化，前提是你的品类不太受关税门槛影响——低客单价商品在挪威会被免税额度这道坎过滤掉一批冲动消费。第二个例外是物流敏感品类：丹麦人口最少但地理集中、物流条件好，如果你的品类对配送时效敏感，丹麦的体验优势能转化成复购。预算的切法建议是先集中打透一个，跑满三个月拿到可靠数据，再把验证过的结构复制到第二个，第三个可以基于前两个的经验一次到位。三国同时铺开的做法我见过几次，共同问题是每个市场都投得不够深，三个都停在半山腰。

## 权威参考资料



## 捷克语和斯洛伐克语，1993年分家之后关键词就再没合并回同一套

- URL：https://zhangwenbao.com/czech-slovak-seo-content-reuse-decision.html
- 分类：小语种SEO
- 发布：2012-03-14  |  更新：2026-07-25
- 摘要：讲捷克语与斯洛伐克语SEO实战：内容复用的三档判据、系统性对应规律与脚本转换七成的边界、假朋友清单、ch当独立字母的排序坑、两类变音符号的区别、斯洛伐克语节律规则、货币与税务必须分离、按流量价值加权的复用率算法。
- 关键词：站内搜索,内容本地化,小语种SEO

> **TLDR**：摘要：捷克语和斯洛伐克语有九成词汇能互相看懂，于是几乎每个做中欧市场的团队都会先问一句：一套内容能不能喂两个市场。答案是能省一部分，但省错地方要拿订单还。这篇不重讲七个格，只回答复用这件事——哪三档内容可以照搬、哪些词必须换、脚本能覆盖到几成、ch当一个字母排序会毁掉哪几个页面、货币和税率这两样为什么一开始就得分开。

> 摘要：捷克语和斯洛伐克语有九成词汇能互相看懂，于是几乎每个做中欧市场的团队都会先问一句：一套内容能不能喂两个市场。答案是能省一部分，但省错地方要拿订单还。这篇不重讲七个格，只回答复用这件事——哪三档内容可以照搬、哪些词必须换、脚本能覆盖到几成、ch当一个字母排序会毁掉哪几个页面、货币和税率这两样为什么一开始就得分开。

一家做工业耗材的B2B站，主营密封件、滤芯、O形圈这些替换周期明确的东西，客户是机械厂和维修商。德国和波兰两个市场跑通之后，下一步瞄准捷克和斯洛伐克。

调研的同事拿回来一句话：这两门语言差不多，斯洛伐克人看得懂捷克语，做一套就够了。这句话有一半是对的，麻烦的是另一半。

看得懂是真的。1993年之前两国是一个国家，四十多年里电视、广播、教科书两种语言混着来，五十岁以上的斯洛伐克人听捷克语不需要任何过渡。

但看得懂和会去搜是两件事。人在搜索框里打的是自己脑子里那个词，不是自己能读懂的那个词。斯洛伐克人搜滤芯打的是filter，捷克语那边是filtr，一个字母的差别，就是两条完全不相交的查询。

## 两门语言到底像到什么程度？

词汇重合度通常被引述在九成上下，语法结构几乎同源，两语都是七个格、都用拉丁字母加变音符号、都有阳性阴性中性三个性别。

差异集中在三个地方。一是语音层带来的拼写系统性差异，二是一批高频常用词各走各的，三是斯洛伐克语多出几个捷克语没有的字母和一条捷克语没有的规则。

比例上看，差异确实只占一成。但这一成不是随机分布的，它高度集中在日常高频词上，而高频词恰恰是搜索量最大的那批词。

换个说法：如果你按词典条目随机抽一百个词，九十个能通用。如果你按搜索量前一百的词来看，能直接通用的可能只剩六七十个。这两个数字的落差，就是本文要处理的全部问题。

## 听得懂和搜得到，中间差的是哪一层？

差的是主动产出这一层。语言能力分被动理解和主动产出两块，前者宽后者窄，被动能看懂一万个词的人，主动能用出来的可能只有三千。

搜索是主动产出行为。用户敲进搜索框的每一个字符，都来自他脑子里最先蹦出来的那个说法，不会有人先想一遍这个词在邻国怎么说再决定打哪个。

所以你的页面用捷克语写，斯洛伐克用户点进来能读完、能理解、能下单——前提是他得先搜到你。而他搜的那个词，你的页面上可能一次都没出现过。

这个断点决定了复用讨论的边界：内容主体可以复用，入口词不能复用。剩下的工作就是划清楚哪些是入口词。

## 1993年那次分家，把什么东西一起分掉了？

分掉的不只是国界。货币分开了，捷克保留克朗，斯洛伐克后来换成欧元；法律体系分开了，消费者权益、退换货期限、发票要求各立各的；顶级域名分成了两个，各有各的注册机构和规则。

更慢但更彻底的是语言本身的漂移。两国分家之后，媒体、教育、行政各自运转，新词各造各的，尤其是技术词和商业词，这二十年造出来的新词重合度明显低于老词。

年轻一代的互通度也在下降。捷克年轻人接触斯洛伐克语的机会比他们父母少得多，反向的接触还多一些，因为捷克的媒体内容在斯洛伐克流通得更广。

对做内容的人来说，这意味着一个不对称：斯洛伐克用户容忍捷克语内容的程度，高于捷克用户容忍斯洛伐克语内容的程度。如果非要偷懒只做一套，做捷克语那套的损失更小。

## 哪些内容可以原样照搬？

第一档是技术参数和规格表。尺寸、材质代号、耐温范围、螺纹标准、认证编号——这些东西在两门语言里几乎全是数字、单位和国际标准代号，翻译动不了它们。

产品图片、爆炸图、装配示意图也在这一档。图上的标注如果是编号而非文字，两边完全通用。

还有一类经常被漏掉：兼容性对照表。哪个型号能替换哪个原厂件，这种表格的价值不依赖语言，而且它是B2B站上最能拉长停留时间的内容之一。

这一档能占到整站内容体量的三到四成，而且是最费工时做的那部分。能省下来的确实是真金白银。

## 哪些内容只改词就能过？

第二档是产品描述正文、使用场景说明、安装步骤这类叙述性内容。句子结构可以保留，需要替换的只是散落在其中的那批高频词。

这一档的处理方式是建一张替换表，把已知的对应词列进去，翻译人员在替换表的基础上通读一遍。工作量大约是从头翻译的三分之一。

关键是替换表要包含两类词：一类是系统性对应的，比如捷克语的hadice对应斯洛伐克语的hadica，词尾从e变成a，这类有规律；另一类是完全不同的词，比如报价这个概念捷克语说nabídka，斯洛伐克语说ponuka，两个词毫无关系。

第二类词数量不多但都是商业高频词，漏掉一个，整个页面在斯洛伐克用户看来就是外国网站。这类词值得单独列一张不超过三百条的清单，全站强制校验。

## 哪些内容必须从头重写？

第三档没有商量余地：价格、税务、支付、物流、法律条款、退换货政策、发票说明、保修条件。

最硬的一条是货币。捷克用克朗，斯洛伐克用欧元，这不是显示格式的差异，是整条价格链路的差异——定价策略、汇率波动、支付网关、发票金额，每一环都得分开。

增值税的标准税率两国当时接近，但适用降低税率的商品范围不同，B2B站还要处理跨境反向征税的说明，两边的表述要求不一样。

这一档的内容量占比不高，可能只有一成，但它是转化路径上离下单最近的那一段。省这里的钱，等于在收银台前面挖坑。

## 两语之间有没有能写成脚本的对应规律？

有，而且规律比想象中整齐。捷克语的ě在斯洛伐克语里通常是e，rozměr对rozmer；捷克语的ř在斯洛伐克语里通常是r，řetěz对reťaz；捷克语的ů在斯洛伐克语里常见的对应是ô，stůl对stôl。

名词层面也有系统对应。捷克语以-í收尾的动名词，斯洛伐克语常见的是-ie，těsnění对tesnenie，dodání对dodanie。捷克语的一批阴性名词以-e收尾，斯洛伐克语对应-a。

捷克语的在线语言手册的词形查询 (https://prirucka.ujc.cas.cz/?slovo=t%C4%9Bsn%C4%9Bn%C3%AD)可以逐词确认捷克语这一侧的全部形态，斯洛伐克语那一侧再用对应的词典核对一遍，两边对齐之后规律就浮出来了。

看到这里很容易产生一个念头：写个脚本批量转换不就完了。这个念头值得认真对待，也值得认真泼一盆冷水。

## 靠规则批量转换能覆盖多少，剩下的会出什么事？

粗略估算，规则能正确处理七成左右的词。剩下三成里，一部分是规则不适用的例外，一部分是词根就不同的词。

问题在于这三成的分布。它们不是均匀散落在长尾里，而是集中在最常用的那批词上——语言演化的规律就是这样，高频词最容易走各自的路，低频的技术术语反而因为都是从德语拉丁语借来的，两边高度一致。

所以脚本转换的结果会呈现一个很难受的形态：技术性的长尾词全对，商业性的头部词全错。而头部词承担了绝大部分流量。

合理的用法是把脚本当成初稿生成器而不是终稿生成器：脚本跑一遍，人工只审头部三百个高频词，其余长尾接受脚本结果。这样既拿到了效率，又守住了要害位置。

## 拼写一模一样意思却不同的词有多少？

不多，但每一个都能造成事故。这类词在语言学上叫假朋友，两语共有一批。

stávka在捷克语里是罢工，在斯洛伐克语里是打赌。horký在捷克语里是热的，在斯洛伐克语里是苦的。kapusta在两边指的是不同的蔬菜。pivnice在捷克语里是啤酒馆，斯洛伐克语的pivnica是地窖。

B2B工业品的词表里假朋友出现概率不高，但一旦出现在内容页或者广告文案里，效果堪比在正式报价单上写错客户名字。

处理办法很朴素：维护一张假朋友清单，放进审校流程当强制检查项。这张清单全行业通用，建一次能用很多年，不需要每个项目重做。

## 同一个零件在两边叫的名字差在哪？

拿本文这个案例里的几个词做例子。滤芯捷克语是filtr，斯洛伐克语是filter，差一个字母。密封件捷克语těsnění，斯洛伐克语tesnenie。软管捷克语hadice，斯洛伐克语hadica。

轴承两边都是ložisko，泵两边都是čerpadlo，阀两边都是ventil——这几个完全一致，因为都是外来词或者古老的共同词。

规律浮现出来了：越是国际化的技术词越一致，越是本土的日常词越分岔。而搜索行为里，用户描述需求时用的往往是日常词，描述产品时才用技术词。

这条规律可以直接转成词表策略：技术词共用一张表，需求词和意图词各建一张表。前者省下的工作量足够覆盖后者增加的成本。

## 捷克语的ch为什么排在h后面、i前面？

因为在这两门语言的字母表里，ch不是c和h两个字母，而是一个独立的字母，位置在h之后、i之前。

这意味着chladič（散热器）这个词在字母排序里的正确位置不是在ce附近，而是排在所有h开头的词后面。用英语的排序规则处理，它会跑到ca和ci中间去。

斯洛伐克语更进一步，除了ch还有dz和dž两个双字母，各占一个独立位置。

国际化组织维护的区域排序规则规范 (https://www.unicode.org/reports/tr35/tr35-collation.html)里已经收录了这两门语言的排序数据，问题从来不是没有标准可用，而是没人想起来要用。

## 字母排序错了会毁掉哪几个页面？

第一是品牌索引页和术语表页。B2B站几乎都有一个按字母排列的品牌列表或者零件名词表，排错了本地用户会觉得这个列表是乱的。

第二是筛选器里的下拉选项。材质、品牌、系列这类筛选项通常按字母排序展示，选项一多，排序错误就变成用户找不到目标项。

第三是站内搜索的结果排序和自动补全。补全建议按字典序取前几条时，排序规则直接决定了用户看到什么。

解决办法在数据库那一层：给相关字段指定对应语言的排序规则，而不是用默认的通用规则。这是一次性配置，改完全站受益，成本低到不做没有任何理由。

## 哪些变音字母算独立字母，哪些不算？

这两门语言的变音符号有两大类，作用完全不同，混为一谈是排序出错的根源。

一类是háček，就是字母上那个小勾，č、š、ž、ř、ě、ň、ť、ď都属于这一类。带háček的字母在字母表里是独立字母，č排在c后面自成一位。

另一类是长音符号，á、é、í、ó、ú、ý，它只标记元音的长短，不构成独立字母，排序时跟对应的短元音同位。

所以一个正确的排序实现要能区分：遇到č时当作独立字母处理，遇到á时当作a处理。两类符号在拉丁字母扩展区的码表 (https://unicode.org/charts/PDF/U0100.pdf)里码位相邻，长得也像，但排序上必须分开对待。

## 斯洛伐克语多出来的那几个字母意味着什么？

斯洛伐克语有三个捷克语完全没有的字母：ľ、ĺ、ŕ。前者是带háček的l，后两个是带长音符号的l和r——没错，斯洛伐克语里这两个辅音可以是长的。

此外斯洛伐克语还有ô和ä，捷克语用不到。反过来捷克语的ě和ř斯洛伐克语没有。

技术上这带来两个后果。第一，两语的字符集不是包含关系而是交叉关系，你没法用一个字符白名单同时覆盖两边，得各配一份。

第二，输入难度不同。ľ、ĺ、ŕ这几个字母在标准键盘上要用组合键，实际输入频率低于它们在正规文本里的出现频率，也就是说斯洛伐克用户省略变音符号的比例，比捷克用户高一些。

## 斯洛伐克语的节律规则会怎么改变词尾？

这条规则捷克语完全没有，是斯洛伐克语的独家：两个长音节不能连着出现，第二个要缩短。

后果是同一个词尾会因为前面词干的长短而变形。词干里有长元音的词，后面接的词尾要用短的版本；词干是短的，词尾就保持长的。

做SEO的人为什么要在乎这个？因为它意味着你没法用一套统一的规则批量生成斯洛伐克语的变格形态。同一个语法位置上，不同的词会给出不同长度的词尾。

处理办法是别自己生成，去词典里查。斯洛伐克语的规范词典有在线检索，逐词核对头部词表的形态，比写规则靠谱得多，也快得多。

## 七个格要不要在这里从头讲一遍？

不讲。这两门语言的格系统跟波兰语是同一套逻辑，主格属格与格宾格呼格方位格工具格，七个位置各管一摊，名词形容词一起变。

那套逻辑怎么落到词表、标题模板和站内搜索上，波兰语七个格的选词方法 (https://zhangwenbao.com/polish-seo-seven-cases-diacritics-keyword-research.html)那篇已经讲完整了，从概念合并到形态覆盖再到工具数据的口径偏差，换成捷克语和斯洛伐克语几乎可以逐条对应。

俄语那边的六个格也是同一个家族的问题，只是符号体系不同，俄语词形变化与工具数据合并 (https://zhangwenbao.com/russian-seo-cyrillic-cases-declension-wordstat-keyword.html)那篇里关于工具把多种词形合成一个数字的分析，在这里同样成立。

本文要处理的是这两门语言独有的那部分——复用判据、排序规则、字符集差异、市场分离，格变化不在这个清单上，重复讲一遍只会稀释重点。

## 变音符号用户到底打不打？

正式场合打，随手搜索经常不打。这两门语言的变音符号密度很高，一句话里可能有五六个，全打完要按不少组合键。

实际分布大致是这样：桌面端带完整变音符号的比例明显高于移动端；技术类查询高于日常类查询；年长用户高于年轻用户。

所以页面可见文本一律要打全，这是专业度的底线，而站内搜索和筛选器的匹配逻辑要做去变音归一，查询和索引两边都做。

这里有个只有这两门语言才有的坑：去变音归一时不能把č直接折成c就完事，还要考虑用户可能把它打成cz或者ch这类替代拼法。做一张替代拼法的映射表，比单纯的去变音多接住一截查询。

## URL该用本地字符还是拉丁转写？

用去掉变音符号的基本拉丁字母，这是最稳的选择。tesneni-do-cerpadla这样的路径，两门语言的用户都读得懂、复制粘贴不出错、分享到任何平台都不会变成一串编码。

保留变音字母的路径在技术上完全可行，但收益微乎其微，风险却是实打实的：转义后的地址长得像乱码，客服在电话里没法念给客户听，B2B场景里这最后一条比什么都重要。

去变音时注意一件事：ch要保留成ch，不要因为它在字母表里是一个字母就想着转成别的东西。它本来就是两个拉丁字母，原样留着最好。

已经上线的路径不要为了规范去改。改路径要带一串跳转，损耗大于收益，新页面按规范来，老页面留着。

## 域名要不要各注一个？

做B2B长期经营，建议各注一个。本地后缀在这两个市场的信任加成很明显，尤其是采购决策链条长、要开发票要签合同的场景。

但两个后缀的注册规则不一样，注册前先确认主体资格要求。捷克那边规则较宽松，斯洛伐克那边对注册人的要求历史上更严格，找本地代理确认一遍再决定，别等到付款环节才发现走不通。

注册和真正启用是两件事。可以先注下来做防御性持有，内容准备好了再启用，域名成本比后期被人抢注的代价低得多。

至于两套内容具体怎么组织成站点结构、要不要独立域名还是共用一个域名分目录，那是架构层的事，跟语言本身无关，本文不展开。

## 两套内容会不会互相判成重复？

会有风险，而且这个风险在近亲语言之间比在远亲语言之间高得多。技术参数表原样照搬的那部分，两个语言版本可能只差几个词。

先说结论：只要页面的主体内容确实针对不同语言的用户写，参数表相同不构成问题。参数就是参数，谁写都一样。

真正的风险在那种偷懒做法——把捷克语页面复制一份，只改标题和导航，正文一个字不动。这种页面在两个语言目录下几乎完全一致，被判成同一份内容合情合理。

处理方式和同站内的重复页面是同一套思路，指定一个规范版本或者让两个版本各自有足够的差异化内容，规范标签的跨页冲突诊断 (https://zhangwenbao.com/canonical-tag-mechanism-cross-domain-self-conflict-diagnosis.html)那篇里的判断顺序在这里同样适用，先判断该不该合并，再决定用哪种技术手段。

## 关键词工具在这两门语言上有多少数据？

捷克语勉强够用，斯洛伐克语基本靠猜。这是市场规模决定的，捷克人口一千多万，斯洛伐克五百多万，后者的长尾词在工具里大量返回零或者最低档。

更麻烦的是工具的形态合并策略不透明。七个格加单复数，一个概念能拆出十几种形态，工具报的数字到底是哪几种形态的和，你看不出来。

所以对这两个市场，工具数据只能用来做粗排，不能用来做决策。看一眼哪几个品类明显是大头就行，具体到词级别的优先级，得靠别的数据来源。

顺带提醒，捷克市场有本地搜索引擎占着不小的份额，斯洛伐克这边没有对应的角色，两个市场的流量入口结构本身就不一样。这半边属于引擎层的打法，不在语言层的讨论范围内。

## 数据稀疏到没法排序时怎么补？

三个来源，成本从低到高排。第一是本地竞品的站点结构，把当地做得最好的两三家的分类树和筛选项抄下来，那是他们用真金白银试出来的词。

第二是本地比价平台的分类名和属性名。捷克这类平台成熟度很高，分类体系细致，属性命名规范，直接当词库用毫不夸张。

第三是自己站内搜索的日志。这个来源最准但要等，上线三个月才攒得出有意义的量，所以它是第二轮优化的输入，不是第一轮的。

三个来源交叉验证之后，头部两三百个词的准确度就够开工了。长尾等自己的数据攒起来再补，不用一开始就追求完备。

## B2B词表要按哪三层建？

第一层是型号和标准代号层。这一层完全语言无关，两个市场共用一张表，维护成本几乎为零，但它承接的搜索意图最精准——搜型号的人已经知道自己要什么。

第二层是零件名称层。这一层部分共用部分分岔，前面说的filtr和filter就在这一层。做法是一个概念一条记录，下面挂两个语言字段，谁用谁取。

第三层是需求描述层。客户不知道零件叫什么，只知道自己的泵漏了、机器过热了，用日常语言描述症状。这一层两边基本没法共用，各建各的。

三层的流量结构大致是倒过来的：第三层搜索量最大、竞争最松、转化路径最长；第一层量最小但转化最直接。资源有限时先做第一层拿转化，再补第三层拿量。

## 商品标题模板要不要各写一套？

模板结构可以共用，词槽必须各填各的。B2B的标题通常是零件名加型号加规格加品牌，这个结构两边一样。

要各写一套的是词槽里的固定文案部分，比如原厂替换件、现货发货、含增值税这类修饰语，两边的说法和习惯不同。

还有一个容易漏的点：变格。零件名后面接规格时，捷克语和斯洛伐克语都可能要求某个格的形态，而两语在同一个语法位置上给出的词尾未必相同，斯洛伐克语那条节律规则还会再插一脚。

稳妥做法是把每个零件名需要用到的几种形态直接存进字典，模板取用时不做任何变格计算。程序算变格在这两门语言上出错率太高，不值得冒险。

## 数字、日期和邮编格式两边一样吗？

数字和日期基本一样，货币完全不同。两语都用逗号做小数点、空格做千位分隔，日期都用日在前的点分格式，日月年之间还习惯留一个空格。

货币那一栏是分水岭。捷克是克朗，符号写在数字后面；斯洛伐克是欧元，符号同样写在后面但金额量级完全不同，一个数字改个单位就差二十几倍。

邮编两边都是五位，都习惯写成三位加两位、中间空一格的样子。地址结构也一致，街道名在前门牌号在后。

这一节的实际意义是：格式层能共用一套模板，只要把货币抽成变量。真正需要分开的不是格式而是金额本身，那属于定价策略，不属于本地化。

## 节庆和季节词两边错开在哪？

圣诞和复活节两边同步，跟着基督教历法走。围绕这两个节点的采购提前期在B2B场景里体现为年底备货和春季检修两波。

国庆日不同步。两国各有各的建国纪念日，日期差得很远，做促销日历时不能共用一份。

还有一个两国共有但外国人常常不知道的习俗：命名日。每个日期对应一批名字，当天过节的人会收到祝福和小礼物。这个习俗对礼品类目影响巨大，对工业耗材影响不大，但它会影响客户单位的到岗率，进而影响询盘响应时间。

季节词方面，两国气候接近，冬季检修、夏季高温防护这类周期性需求节奏基本一致，这部分内容可以共用排期表。

## 内链的锚文本能不能两边共用？

不能，理由跟标题一样：锚文本要嵌进句子里，一嵌进去就要跟着句子的语法环境变形。

而且两语的变格词尾在同一个语法位置上可能不同，直接复制过去的锚文本会呈现出一种微妙的错——不是完全看不懂，是读起来别扭，本地人一眼能感觉到不对但说不清哪里不对。

做法是给每个链接目标准备一个锚文本变体池，两个语言各一个池子，写作时按语境挑。这件事跟前面讲的形态字典是同一套基础设施，建一次两处用。

意大利语那边处理形容词随名词变形的做法可以参考，意大利语性数一致与省音 (https://zhangwenbao.com/italian-seo-gender-agreement-elision-keyword-research.html)那篇里讲的变体池思路是通用的，屈折程度高的语言都吃这一套。

## 审校该请一个人还是两个人？

两个人，而且必须是两个母语者，不能找一个自称两语都精通的人包干。

理由不是能力问题，是盲区问题。一个捷克母语者在读斯洛伐克语文本时，那些微妙的不地道会被他的理解能力自动补全，他读得懂就不会觉得有问题。反过来也一样。

成本上其实增加有限。第一档内容不需要审，第三档内容量小，真正需要两个人各看一遍的只有第二档，占总量的一半左右。

给审校人的清单要具体到条：假朋友清单过一遍、高频词替换表核一遍、变音符号有没有漏、货币和税务表述对不对、变格形态有没有别扭的地方。五条足够，列三十条反而没人认真看。

## 复用比例的账怎么算才不自欺？

常见的自欺是按字数算。按字数算，参数表和兼容表占了大头，复用率轻松报到七成，看起来省了一大笔。

正确的算法是按流量价值加权。把每一块内容承接的搜索量乘以它的转化贡献，再看这部分能不能复用。这么一算，复用率通常掉到四成左右。

掉下来的那部分正是入口词和转化文案，也就是前面反复强调的两块。它们字数少、工时低，但决定了流量进不进得来、进来了转不转得成。

所以给团队汇报时，字数复用率和价值复用率两个数都要给。只给前一个数，决策层会以为这个市场几乎不用花钱，预算一砍，最后是流量兑现不出来。

## 什么时候该承认这两个市场得分开做？

三个信号出现任意两个，就该分。

第一个信号是斯洛伐克市场的自然流量长期停在捷克市场的一成以下。正常比例应该在三到四成之间，人口比例摆在那里。低到一成，说明入口词根本没接住。

第二个信号是站内搜索的空结果率在斯洛伐克那边显著高于捷克。这个数最诚实，它直接告诉你用户打进来的词你没有。

第三个信号是询盘的语言。如果斯洛伐克客户发来的询盘用的是捷克语或者英语，说明他们已经默认你不是本地供应商了，这在B2B里是很难挽回的印象。

保哥的建议是不要一开始就分，先用一套内容加一张替换表跑三到六个月，让数据告诉你哪些词漏了。等第二档内容的替换表长到七八百条的时候，分开做的边际成本已经很低了，那时候再分，方向也准。

## 两个市场的电商成熟度差在哪，会不会改变打法？

捷克这边的线上采购习惯建立得更早，比价平台成熟、支付方式齐全、企业用户在线下单的接受度高。斯洛伐克起步晚一些，线下渠道和电话询价的比重更大。

这个差异直接改变内容重心。捷克市场值得把产品页做深，参数、库存、交期、替换关系全部前置，让客户自己完成决策。

斯洛伐克市场则要把询价路径做短，电话号码、在线留资、报价单下载这些入口要更显眼，因为相当一部分客户的习惯是先联系人再谈产品。

换句话说，两个市场需要的不只是两套词，还是两种页面重心。这一点比语言差异更容易被忽略，因为它在翻译环节根本不会暴露出来。

## 常见问题解答

## 捷克语和斯洛伐克语能不能只做一套内容？

能省一部分，但不能全省，关键是分清楚省在哪。可以直接照搬的是技术参数、规格表、图纸、型号兼容对照表这一档，它们几乎全是数字、单位和国际标准代号，占内容体量的三到四成，也是最耗工时的那部分，省下来是实打实的。只改词就能过的是产品描述、使用说明、安装步骤这一档，做法是建一张高频词替换表，翻译人员在替换表基础上通读，工作量约为从头翻译的三分之一。绝对不能省的是价格、税务、支付、物流、法律条款和退换货政策，因为捷克用克朗、斯洛伐克用欧元，两国法律体系也各自独立，这一档虽然只占一成内容量，却是离下单最近的一段。真正不能复用的还有一样是入口词——用户搜索时敲进去的那批词，这些词字数极少但决定了流量进不进得来。如果只能选一个方向偷懒，做捷克语那一套的损失更小，因为斯洛伐克用户对捷克语内容的容忍度更高，反向则不成立。

## 写个脚本把捷克语批量转成斯洛伐克语可行吗？

可以当初稿生成器，不能当终稿。两语之间确实有一批整齐的对应规律，捷克语的ě在斯洛伐克语里通常对应e，ř通常对应r，ů常见的对应是ô，以-í收尾的动名词对应-ie，一批阴性名词的-e对应-a。按这些规律写脚本，大约七成的词能转对。问题出在剩下三成的分布上：它们不是均匀散落在长尾里，而是高度集中在最常用的商业词上，因为语言演化的规律就是高频词最容易各走各的路，而那些从德语拉丁语借来的技术术语反而两边高度一致。结果就是脚本跑完，技术性长尾全对、商业性头部全错，而头部词承担了绝大部分流量。合理的用法是脚本先跑一遍，人工只审头部三百个高频词，长尾接受脚本结果。这样效率拿到了，要害位置也守住了。另外别忘了斯洛伐克语有一条捷克语没有的节律规则，长音节不能连着出现，这条规则会让同一个语法位置上不同词的词尾长短不一样，规则脚本处理不了，只能查词典。

## ch当一个字母排序这件事，具体会毁掉什么？

毁掉三个地方，而且都是用户直接看得见的。第一是按字母排列的索引页，B2B站几乎都有品牌列表或零件名词表，捷克语和斯洛伐克语里ch是一个独立字母，位置在h之后、i之前，用通用排序规则处理，chladič这类词会跑到ca和ci中间去，本地用户看到的就是一个乱序列表。第二是筛选器的下拉选项，材质、品牌、系列这些选项按字母排序展示，选项一多，排序错误就等于用户找不到目标项，明明有货却筛不出来。第三是站内搜索的自动补全，补全建议按字典序取前几条，排序规则直接决定用户看到哪几个词。斯洛伐克语情况更复杂，除了ch还有dz和dž两个双字母各占独立位置。解决办法在数据库层，给相关字段指定对应语言的排序规则而不是用默认通用规则，一次性配置，改完全站受益。还要区分清楚两类变音符号：带小勾的那类是独立字母，带长音符号的那类只标长短、排序时跟对应短元音同位，这两类不能一视同仁。

## 域名要不要在两个国家各注一个？

做B2B长期经营建议各注一个，本地后缀在这两个市场的信任加成很明显，尤其是采购链条长、要开发票签合同的场景，客户会拿域名后缀当第一道筛选。但两个后缀的注册规则不一样，注册前必须先确认主体资格要求，捷克那边规则相对宽松，斯洛伐克那边对注册人的要求历史上更严格，找本地代理确认一遍再决定，别等到付款环节才发现流程走不通。注册和启用是两件事，可以先注下来做防御性持有，内容准备好了再启用，域名年费比后期被人抢注的代价低得多。需要提醒的是，域名后缀只解决信任问题，解决不了内容问题，注了本地域名但内容还是另一门语言，反而会加剧不专业的印象。至于两套内容具体怎么组织成站点结构、独立域名还是共用域名分目录，那属于架构层的决策，跟语言本身无关，另有专门的判断框架。

## 两个语言版本的参数表一模一样，会不会被判成重复内容？

参数表相同本身不构成问题，尺寸、耐温范围、螺纹标准这些东西谁写都一样。真正的风险在另一种做法：把捷克语页面整体复制一份，只改标题和导航，正文一个字不动。这种页面在两个语言目录下几乎完全一致，被判成同一份内容合情合理，而且近亲语言之间这个风险更高，因为连词形都很像，差异信号更弱。判断标准是主体内容有没有真正针对不同语言的用户重写，尤其是那些承接搜索意图的描述性段落。如果确实存在大面积重合，处理顺序应该是先判断这两个页面该不该合并成一个，再决定用什么技术手段，而不是上来就贴标签。顺带提醒，斯洛伐克语版本如果只是机器转换的结果，重复内容只是表面症状，根因是这个版本压根没有独立存在的理由。

## 关键词工具在这两门语言上的数据能用吗？

捷克语勉强够做粗排，斯洛伐克语基本靠猜。这是市场规模决定的，捷克一千多万人口、斯洛伐克五百多万，后者的长尾词在工具里大量返回零或者最低档。更麻烦的是工具的形态合并策略不透明，七个格加单复数，一个概念能拆出十几种形态，工具报的数字到底覆盖了哪几种形态，你从界面上看不出来。所以对这两个市场，工具只能用来判断哪几个品类明显是大头，具体到词级别的优先级得靠别的来源。补数据有三个办法，成本从低到高排：第一是抄本地竞品的分类树和筛选项，那是他们花钱试出来的词；第二是本地比价平台的分类名和属性名，捷克这类平台成熟度很高、分类体系细致，直接当词库用毫不夸张；第三是自己站内搜索的日志，这个来源最准但要等三个月才攒得出量，属于第二轮优化的输入。三个来源交叉验证之后，头部两三百个词的准确度就够开工了。

## 什么时候该承认必须分开做两套？

看三个信号，出现任意两个就该分。第一个是斯洛伐克市场的自然流量长期停在捷克市场的一成以下，按人口比例算正常应该在三到四成之间，低到一成说明入口词根本没接住。第二个是站内搜索空结果率在斯洛伐克那边显著高于捷克，这个数最诚实，直接告诉你用户打进来的词你的库里没有。第三个是询盘的语言，如果斯洛伐克客户发来的询盘用的是捷克语或者英语，说明他们已经默认你不是本地供应商，这在B2B里是很难挽回的印象。建议的路径不是一上来就分，而是先用一套内容加一张替换表跑三到六个月，让数据告诉你哪些词漏了。等替换表长到七八百条的时候，你手里已经有了一份高质量的差异清单，那时候分开做的边际成本很低，方向也准。反过来说，如果跑了半年替换表还只有两三百条，那说明这两个市场对你的品类而言差异确实不大，继续共用就是对的选择。

## 权威参考资料



## 希腊语SEO越是把页面写得规范，越接不住用户用拉丁字母打出来的那半边搜索

- URL：https://zhangwenbao.com/greek-seo-greeklish-latin-transliteration-coverage.html
- 分类：小语种SEO
- 发布：2011-11-16  |  更新：2026-07-25
- 摘要：讲希腊语SEO实战：Greeklish按读音与按字形两派转写、官方罗马化标准与民间写法的分工、词表按概念合并而输出按规范形态、重音该打与该忽略的场合、全大写要去重音的规则与样式转换的坑、词尾sigma的条件式大小写、跟拉丁同形的希腊大写字母怎么扫、复数属格在分类页的形态、站内搜索三层归一。
- 关键词：关键词研究,内容本地化,小语种SEO

> **TLDR**：摘要：希腊语站有个别处见不到的分裂：页面上写的是希腊字母，而相当一部分用户在搜索框里打的是拉丁字母拼出来的希腊语。这套民间转写没有统一标准，同一个词能拼出好几种样子，你把页面写得越规范，离那一半查询就越远。更麻烦的是希腊字母里有十几个跟拉丁字母长得一模一样但码位不同，混进数据里几乎看不出来。这篇讲清楚：两派转写各按什么规则、词表怎么建才不会把量切碎、重音该不该打、全大写标题为什么一眼露馅、词尾那个sigma怎么把大小写转换搞坏，以及站内搜索该做哪三层归一。

> 摘要：希腊语站有个别处见不到的分裂：页面上写的是希腊字母，而相当一部分用户在搜索框里打的是拉丁字母拼出来的希腊语。这套民间转写没有统一标准，同一个词能拼出好几种样子，你把页面写得越规范，离那一半查询就越远。更麻烦的是希腊字母里有十几个跟拉丁字母长得一模一样但码位不同，混进数据里几乎看不出来。这篇讲清楚：两派转写各按什么规则、词表怎么建才不会把量切碎、重音该不该打、全大写标题为什么一眼露馅、词尾那个sigma怎么把大小写转换搞坏，以及站内搜索该做哪三层归一。

一家做家纺的独立站，床品四件套、毛巾、羽绒被这几条线，意大利和西班牙跑得不错，看希腊虽然经济正在紧缩期但家纺属于刚需，客单价也还撑得住，就开了希腊语版本。

翻译请的是雅典的母语译者，质量没问题，页面上的希腊语干净规范。上线之后收录正常，品牌词能搜到，品类词的排名也慢慢上来了。

问题出在站内搜索的日志上。运营导数据的时候发现一个奇怪现象：搜索量最大的那批查询，全是用拉丁字母打的，比如petsetes、sentonia、maxilari，而站内一条都匹配不上，返回的全是空白页。

这些词是希腊语，只不过用拉丁字母拼出来的。用户看得懂希腊字母，但他们的键盘、他们的输入习惯、他们在手机上的懒惰，让他们经常懒得切输入法。

## 希腊人到底在搜索框里打哪一套字母？

两套都打，而且比例取决于场景。

正式的、坐在电脑前的、带着明确购买意图的查询，希腊字母占多数。而随手一搜、手机上打的、聊天里顺手复制的，拉丁转写的比例明显更高。

这套用拉丁字母拼希腊语的写法在当地有个通俗叫法，把希腊语和英语两个词拼在一起造出来的。它最早是从早期的电子邮件和短信里长出来的——那会儿系统不支持希腊字母，只能拿拉丁字母硬凑，凑着凑着就凑成了习惯。

关键是这个习惯一直没消失，即使输入法早就完善了。做希腊市场如果只覆盖希腊字母那一半，等于主动放弃了另一半的入口。

## Greeklish为什么没有唯一写法？

因为它压根不是被设计出来的，是自然长出来的，而且长出了两个方向。

希腊字母 | 按读音转 | 按字形转 | 

θ | th | 8或0 | 

ξ | x或ks | 3 | 

η | i | h | 

ω | o | w | 

φ | f | f | 

ψ | ps | ps | 

按读音那一派，写出来的东西读起来像希腊语；按字形那一派，写出来的东西看起来像希腊语。前者更通用，后者在年轻人和早期网络文化里更常见。

现实中绝大多数人是混着来的，一个词里前半截按读音后半截按字形完全正常。所以同一个品类词能拼出三到五种拉丁写法，而且没有哪一种能被称为正确。

## 拿毛巾这个词走一遍

希腊语里毛巾的复数是πετσέτες。按读音转是petsetes，这是最常见的；有人把ε写成e、有人不打重音、有人把τσ写成ts或者tz。几种加起来，一个词能散成四五个字符串。

枕头μαξιλάρι那个ξ更热闹，有人写x，有人写ks，还有人写3。你要覆盖的不是一个词，是一小簇词。

## 官方转写标准跟民间写法是一回事吗？

完全不是，这一点必须分清楚，否则会做出错误的技术决策。

希腊有正式的罗马化标准，1982年就发布了国家标准，后来又对应成了国际标准，护照、身份证、路牌上的拉丁写法走的都是这一套。它的特点是可逆、规则严格、一个希腊字母对一个固定的拉丁写法。

而民间的那套转写是随性的、多对多的、按个人习惯来的。官方标准用来做标识符和地址，民间写法用来做搜索覆盖，两者各管一段，不能互相替代。

最常见的误判是拿官方标准去生成关键词候选，结果生成出来的一堆写法真实用户根本不用。官方标准适合做地址转写，做搜索词得看真实数据。

## 要不要为Greeklish单独做一版页面？

不要。这是本篇最重要的一条判断。

为拉丁写法单独做一批页面，等于凭空造出一堆内容雷同的双胞胎，两边互相稀释，最后哪个都排不上去。而且那些页面上的文字是本地人根本不会用来阅读的形态，用户点进去只会觉得这站很怪。

正确的做法分三层：

位置 | 怎么处理 | 

页面可见文本 | 一律规范希腊字母，不做任何让步 | 

站内搜索 | 把拉丁写法映射到希腊字母的目标词 | 

正文一处 | 让最主流的那种拉丁写法自然出现一次 | 

第三条是个折中，比如在文章里提一句当地人也常把它拼成某某，既让页面能被那种查询理解，又不至于让页面看起来像错别字堆。用一次就够，重复堆砌会适得其反。

至于同一份内容因为技术原因出现在多个地址时该由谁代表，那是规范链接要解决的问题，规范链接在跨页场景下的用法与冲突诊断 (https://zhangwenbao.com/canonical-tag-mechanism-cross-domain-self-conflict-diagnosis.html)那篇讲得比较细。

## 关键词表该怎么建才不会把量切碎？

按概念建表，不按字符串建表。这是希腊语选词跟别的语言最不一样的地方。

一个概念下面挂着的字符串包括：规范希腊字母写法、不打重音的希腊字母写法、三到五种拉丁转写、单复数与各个格的形态。全部归到同一个概念下求和，才能得到这个品类的真实需求量。

如果按字符串逐条排优先级，你会看到一堆量很小的词，每一个都不值得做，结论必然是希腊市场太小不值得投。这个结论是口径造成的幻觉，不是事实。

输出的时候反过来：页面标题只用规范希腊字母的主形态，其余全部沉到站内搜索和同义词表里。建表按合并口径，输出按规范口径，这两件事必须分开。

## 重音符号该不该打？

页面上必须打，搜索匹配时必须忽略。

现代希腊语用的是单调正字法，1982年确立，规则很简单：每个两个音节以上的词有且只有一个重音，标在重读的那个元音上。它不是装饰，是拼写的一部分，不打就是错字。

但用户在搜索框里经常不打，尤其在手机上。所以查询和索引两边都要先把重音去掉再比对，这一步在希腊语站上是必需项，不是优化项。

还有一个细节：分音符是另一回事，它标在两个连写的元音上表示要分开读，不是重音。做符号折叠的时候要把这两类分开考虑，粗暴地全折掉可能会把少数词的区分度弄丢。

## 全大写标题为什么一眼就露馅？

因为希腊语的正字法有一条规则：整个词全大写的时候，重音符号要去掉。

而所有把文字变成大写的自动化手段，都不知道这条规则。用样式把标题变成全大写，浏览器只是把每个字母换成大写形态，重音原封不动地留在上面，输出的就是一个本地人一眼看出不对的标题。

这个坑特别隐蔽，因为在开发和测试环节没有人会注意到，只有希腊人看一眼才会说这个不对。而它出现在标题样式里，意味着全站所有标题一起中招。

## 怎么修

两条路。一是在数据层准备好去重音的大写版本，需要全大写效果时直接取那个字段，不靠样式转换。二是干脆不用全大写的标题样式，希腊语的字形本身辨识度很高，不靠全大写也够醒目。

要注意一个例外：只有首字母大写的情况下，重音是保留的。所以不能一刀切地把所有大写场景都去重音，得区分首字母大写和全词大写这两种。

## 词尾那个sigma，为什么让大小写转换出错？

因为希腊语里这个字母有两个小写形态：词中间用一种，词尾用另一种，而大写只有一个。

问题出在从大写转回小写的时候。程序拿到一个大写的Σ，它该变成词中形态还是词尾形态？答案取决于这个字母在词里的位置，这是一条需要看上下文才能决定的规则，而绝大多数字符串处理函数不看上下文。

后果是：把一段全大写的希腊语文本转成小写，词尾的那些字母全都变成了词中形态，结果是一段拼写错误的希腊语。如果这段文本还被用去做搜索匹配或者生成地址，那错误就传下去了。

国际化标准里对这条规则有专门的条件式定义，实现得好的库会正确处理，实现得糙的不会。上线前一定要造一批以这个字母结尾的测试词跑一遍，几分钟的事，能避免一类很难排查的问题。

## 希腊字母里哪些跟拉丁字母长得一样？

十几个，而且是最常用的那一批。

大写的Α、Β、Ε、Ζ、Η、Ι、Κ、Μ、Ν、Ο、Ρ、Τ、Υ、Χ，跟拉丁字母的A、B、E、Z、H、I、K、M、N、O、P、T、Y、X在屏幕上几乎无法区分，但它们在编码里是完全不同的字符。

这意味着一段看起来完全正常的希腊语文本，里面可能混着拉丁字母，肉眼永远发现不了。混入的来源很多：从设计稿复制、从表格粘贴、输入法切换时打错、翻译工具的输出、老系统的转换。

## 混进去会怎样

三个后果。第一，搜索匹配失败，用户搜的词和你库里存的词字节不同。第二，地址里出现意外字符，或者被转成一串编码。第三，数据比对时同一个商品被当成两个。

## 混进去的同形字母怎么查出来？

写个脚本扫，判据很清楚：一个字段里同时出现了希腊字母区和拉丁字母区的字符，且不属于品牌名或型号这类合法混排，就是可疑对象。

国际化组织维护了一份专门讲同形字符安全问题的技术标准 (https://www.unicode.org/reports/tr39/)，配套还有一张字符混淆对照表，直接拿来当规则来源就行，不用自己整理。

扫描要覆盖四个地方：商品标题、分类名、属性值、地址标识符。发现之后统一替换成希腊字母，同时在录入环节加一道校验，否则修完一轮，下一批数据进来又是老样子。

这类由字符集混排引发的问题不是希腊语独有，阿拉伯语站上也有一批类似的字符陷阱，处理思路可以对照阿拉伯语站在布局与字符处理上最容易翻车的地方 (https://zhangwenbao.com/arabic-seo-rtl-layout-msa-dialect-keyword.html)那一篇。

## 希腊语的名词也有格吗？

有，四个：主格、属格、宾格、呼格，再乘上三个性和单复数。跟俄语波兰语那种六七个格的比起来算温和，但足以让一个词长出七八种形态。

形态 | 毛巾（阴性） | 床单（中性） | 

单数主格 | πετσέτα | σεντόνι | 

单数属格 | πετσέτας | σεντονιού | 

复数主格 | πετσέτες | σεντόνια | 

复数属格 | πετσετών | σεντονιών | 

重音的位置还会跟着格变化移动，属格复数尤其明显。所以词形变化不只是加词尾，连重音都在动，这让简单的字符串前缀匹配基本失效。

屈折语的选词该怎么按词元合并、按真实形态输出，俄语那篇讲得最系统，机制是相通的，可以看俄语的格变化怎么把一个词的搜索量拆成十几份 (https://zhangwenbao.com/russian-seo-cyrillic-cases-declension-wordstat-keyword.html)里的做法。

## 商品标题模板会在哪一步拼错？

在把属性词和品类词拼成短语的那一步。希腊语的形容词要跟名词的性、数、格一致，词尾跟着变。

床品品类里全是这种组合：棉质的、双人的、防水的，每一个形容词碰上阴性名词一个样、碰上中性名词又一个样。模板如果只存一个形容词形态，输出的短语在本地人看来就是没配对的。

解法跟别的屈折语一样：属性字典里按性别存好几个形态，品类词标记好性和数，模板按标记取用。字段填一次，全站所有拼接都受益。

## 复数属格为什么在分类页上特别重要？

因为希腊语表达某某的商品这类结构时用属格，而分类页的标题恰好大量使用这个结构。

举个实际的：毛巾套装这个概念，希腊语里是套装加上毛巾的复数属格，也就是πετσετών那个形态，而不是词典原形。如果你的分类页标题用的是单数主格，那就是一个语法上说不通的组合，用户搜索时打的也不是这个形态。

检验的办法很直接：把品类词打进搜索框，看下拉建议给出的是哪种形态，再看排在前面的本地竞品标题怎么写。两处一致的那个形态，就是你该用的。这一步花不了十分钟，但能救回整个品类页。

## 站内搜索该做哪三层归一？

三层，按投入从小到大排，可以逐层推进。

层级 | 做什么 | 大致投入 | 解决什么 | 

第一层 | 去重音、统一sigma形态、折叠同形字母 | 一天 | 符号与字符混排 | 

第二层 | 拉丁转写映射表，多种写法指向同一目标 | 三到五天 | Greeklish查询完全接不住的问题 | 

第三层 | 接入希腊语词干还原组件 | 一到两周 | 格变化与词形还原 | 

第二层是希腊语站的重头戏，也是别的语言不需要做的一层。做法不必追求完美：先用规则生成候选，再拿站内搜索日志里的空结果查询去补，跑两轮就能覆盖绝大多数。

第三层可以用现成的开源组件，开源检索库里的希腊语词干还原器 (https://lucene.apache.org/core/9_10_0/analysis/common/org/apache/lucene/analysis/el/GreekStemmer.html)的行为文档写得挺清楚，评估的时候可以直接照着它的规则设计测试用例。要提醒的是词干还原会把一些语义不同的词归并到一起，上线后必须抽查高频词的还原结果。

## URL用希腊字母还是拉丁转写？

用拉丁转写，而且用官方标准那一套，别用民间写法。

希腊字母进地址技术上没问题，但要经过百分号编码，一个字符展开成六个，一个五词的品类名在地址栏里就是一长串谁也认不出的东西，复制到聊天窗口里更是灾难。

用官方转写标准的好处是规则确定、可预测、不会因为实现的人不同而产生不同结果。民间写法的多样性在地址上是纯粹的坏处，你不希望同一个品类因为两个开发各按各的习惯转写而生成两个地址。

如果需要批量生成转写，可以借助国际化组件里的文字转换框架 (https://unicode-org.github.io/icu/userguide/transforms/general/)，它内置了希腊字母到拉丁字母的规则集，输出稳定，比自己写映射表可靠。

## 排序和字母导航会排成什么样？

取决于你有没有配语言相关的排序规则，没配的话会很乱。

希腊字母表有二十四个字母，顺序跟拉丁字母不一样。如果数据库用的是按字节排序，带重音的字母会被排到所有不带重音的字母后面去，形成一段莫名其妙的尾巴。词尾形态的sigma也会跟词中形态分开排。

正确的做法是配置按希腊语规则的排序，让带重音和不带重音的同一个字母排在一起，两种sigma也视为同一个字母。品牌索引页和字母导航特别要注意，希腊用户很习惯按字母找品牌，排错了就找不到。

## 编码遗留会在什么地方咬人？

在老数据的导入环节。希腊语在统一码普及之前有两套常用编码，一套是国际标准里的希腊语部分，另一套是桌面系统那套，两者有差异但又高度相似。

典型的翻车场景是从旧系统导出商品表直接喂给新站，程序按统一码解读，出来一堆问号和方块。更阴的是半乱码，一部分字对一部分错，因为码位有重叠。

解决办法只有一条：导入时显式声明源编码，不要让程序猜。凡是靠猜的地方，早晚会猜错一次，而且往往是在数据量最大的那一次。

## 多调正字法的老内容怎么处理？

1982年之前的希腊语用的是多调正字法，一个词上面可能有好几种符号，气息符、重音符各有讲究。教会文本和古典文献现在仍然用这一套。

对大多数电商站来说这不是问题，但有两种情况会碰上：一是引用了老文献或者传统工艺的介绍文案，二是品牌名或者产品线名字用了古典风格的写法。

处理原则是可见文本尊重原样，搜索索引一律折成单调形态。多调字符在编码里有专门的扩展区，折叠规则也有现成的定义，不用自己造。

## 外来语进希腊语会怎么变？

会被改造，但改造程度不如别的语言彻底。英语词进来之后，很多保持不变位、不变格，作为不可变的外来名词使用。

这对选词是好消息也是坏消息。好消息是这类词的形态少，字符串简单；坏消息是它们通常同时存在希腊字母转写和拉丁原形两种写法，两种都有量。

家纺品类里这种情况不少，比如一些面料名和工艺名。处理方式跟同义词一样：选一个当主词，另一个进同义词表并在正文出现一次。选哪个看数据，一般来说越是被大众熟悉的概念，希腊字母写法的占比越高。

## 品牌名要不要转写成希腊字母？

国际品牌保持拉丁原形，本地品牌用希腊字母，这是当地的普遍习惯。

需要注意的是搜索这一侧：用户搜国际品牌时，可能打拉丁原形，也可能打希腊字母转写，两种都要能命中。品牌页上让两种写法各出现一次是最省事的做法。

还有一个细节，品牌名如果被当成形容词或者跟品类词组合，希腊语的处理方式是把品类词变格而品牌名不变。模板拼这类短语时要意识到这一点，别试图给品牌名加词尾。

## 问句型查询在希腊语里长什么样？

有一批固定搭配，收进词表就等于拿到内容选题地图。

词 | 意思 | 用在什么场景 | 

πώς | 怎么 | 教程与保养 | 

καλύτερο | 最好的 | 榜单与推荐 | 

τιμή | 价格 | 比价 | 

προσφορά | 优惠 | 促销季 | 

διαστάσεις | 尺寸 | 选购参数 | 

尺寸那一行对家纺特别重要。床品的尺寸标准各国不同，希腊用的是欧洲那一套，而且当地对单人床双人床的叫法有自己的习惯。尺寸对照表是家纺品类在希腊市场最值钱的一类内容，因为它解决的是真实的购买障碍。

## 表单和地址字段要改哪几处？

四处。邮编是五位数字，通常写成三位加两位中间带空格的形式；国际区号是两位数；地址顺序是街道在前门牌在后，跟英语相反；姓名在正式称呼时要用呼格，词尾会变。

最后那条最容易被忽略。系统给用户发邮件时如果直接把主格的名字塞进问候语，语法上是不通的。要么在数据库里多存一个呼格形态，要么把问候语改成不需要变格的写法，后者更省事。

还有一条实操经验：希腊的地址里街道名很多本身就是人名的属格形态，验证规则不要对字符集做过严的限制，否则合法地址会被拒。

## 数字、价格和日期怎么写？

小数用逗号，千位用点，货币符号跟在数字后面。日期习惯日在前月在后，用斜杠或点隔开。

价格必须显示含税价，这是消费端的硬要求。当时希腊正处在财政紧缩期，税率调整过好几轮，价格模板一定要把税率做成可配置的，别写死在代码里，不然每次调整都要重新发版。

还有一个跟文化有关的细节：促销的表达方式当地更偏好直接标出省了多少钱，而不是只标折扣百分比。经济环境紧张的时候，这个差别对转化的影响比想象中大。

## 界面会被希腊语撑长吗？

会，比英语长两成左右，个别短语更多，主要是因为希腊语的词平均更长，而且不太用缩写。

受影响最明显的是按钮、导航项和表格列头。加入购物车这类短语在希腊语里明显更长，窄屏上容易折行。

处理方式常规：关键按钮准备短版文案，列头允许两行，长词不要在中间硬断。另外一定要用真实的希腊语文案做界面测试，别拿占位文本，占位文本永远长度合适，测不出问题。

## 家纺这类品类的季节词怎么排？

希腊的气候让家纺的季节曲线跟中北欧不一样，夏季长而热，冬季短而温和。

结果是薄款和透气材质的搜索窗口比北欧市场长得多，厚被和保暖类的窗口短而集中。如果你的内容日历是从德国或荷兰站复制过来的，节奏会整体错位。

另外当地有几个跟节庆绑定的家居消费高峰，换季和年末各有一波。把季节词单独建一张表，标明各自的活跃窗口，提前六到八周上内容，这个提前量在家纺上是必要的，用户是先看攻略再买东西的。

## 图片的文件名和替代文本该怎么写？

文件名走官方转写标准，全小写，用连字符分隔，重音和特殊符号一律去掉。希腊字母直接进文件名，在跨系统同步和备份还原时最容易出岔子。

替代文本相反，要写成规范的希腊语，重音标全，形态跟着页面上的品类词一致。而且替代文本也是同形字母的高发区，因为它经常是运营从别处复制过来的短语，扫描脚本别漏掉这个字段。

还有一条容易被忽略：图片上如果有嵌进去的文字，那些文字里的希腊语拼写和重音也得对。设计稿从英文版改过来的时候，这一层最容易漏，而且改起来最麻烦，所以最好在做设计的时候就把希腊语文案定稿。

## 面包屑和筛选器的形态该怎么定？

面包屑用主格，筛选器标签用主格，只有需要表达所属关系的组合短语才用属格。这一条定死之后能省掉大量返工。

为什么要定死？因为这些位置的文本会被模板反复拿去拼页面标题和描述，一旦各处形态不一致，拼出来的就是半通半不通的短语，而且是全站规模的。

属性值那一侧要注意性别。颜色和材质词在做形容词用的时候要跟名词的性数格一致，做独立标签用的时候用中性单数形态。字典里把这两种用法分开存，比让模板临场判断可靠得多。

还有一个小细节：呼格在电商界面上基本用不到，只在给用户的问候语里出现。别把呼格形态混进商品数据里，那是两套不同的用途。

## 机器翻译在希腊语上最容易犯哪三类错？

第一类是形容词和名词的性数格不一致，这在拼接式短语里出现得最多，也最伤搜索，因为它直接改掉了字符串。

第二类是重音位置错。重音在希腊语里能区分词义，位置放错有时候会变成另一个词，机器翻译在长词和复合词上尤其容易出这个错。

第三类是词尾sigma形态错，这个多半不是翻译引擎的锅，是后续的大小写处理造成的，但表现出来是一回事。

这三条可以做成一张卡片发给内容团队，验收时对着扫一眼，比逐句读快得多。机器翻译当初稿工具没问题，问题只出在直接发布上。

## 母语审校该怎么验收？

给一份带判据的清单，每条几秒内能判定对错，比让人通读一遍有效得多。

六条就够：重音是否全部标注且位置正确；全大写的标题是否去掉了重音；词尾sigma形态是否正确；形容词与名词的性数格是否一致；分类页的品类词是否用了复数属格形态；文本里有没有混入拉丁同形字母。

最后一条审校用肉眼看不出来，但可以让他们用脚本扫，或者干脆把这条留给技术侧做。剩下五条是纯语言判断，找一个当地人半天能扫完几百个页面。

## 关键词工具在希腊语上给的数为什么不准？

因为工具几乎不会把拉丁转写和希腊字母写法合并，也不会把格变化的形态合并，更不会把不打重音的写法跟规范写法合并。

三层叠加，工具报出来的单条数字往往只是真实需求的一小块。拿这个数字直接排优先级，是希腊市场评估最常见的系统性错误——它会让整个市场看起来比实际小很多，而这个判断一旦写进预算方案就很难推翻，因为数字看起来非常客观。

## 三个补数据的土办法

一是拿自己的站内搜索日志当第一手数据，尤其是空结果查询，那份名单直接就是你的拉丁转写词表。二是看本地竞品的标题形态，排在前面的用的是什么写法，那大概率就是对的。三是找几个当地人，让他们对同一件商品各写一遍名字，重合度最高的那个就是主写法。

这三招合起来不到一天，能把头部几十个品类词定死。长尾等站内数据攒起来再补，不用一开始就追求完备。

## 上线前的语言层检查清单

把这一篇压成可执行的动作，大概是十条：

检查项 | 怎么判定 | 

词表口径 | 是否按概念合并了希腊字母、拉丁转写、格变化三类形态 | 

页面文本 | 是否一律规范希腊字母，没有为转写单开页面 | 

重音 | 可见文本是否标注完整，索引是否去重音 | 

全大写 | 大写标题是否去掉了重音，首字母大写是否保留 | 

sigma | 大小写转换是否按位置正确输出两种形态 | 

同形字母 | 是否扫过一遍混入的拉丁字符，录入端是否有校验 | 

模板一致 | 形容词是否按名词的性数格取形态 | 

分类页形态 | 品类词是否用了真实查询里的那个形态 | 

站内搜索 | 三层归一是否上线，转写映射表是否在迭代 | 

排序 | 是否按希腊语规则排序而不是按字节 | 

十条里回报最快的是第九条和第六条。前者直接把接不住的那一半查询接回来，后者消除一类几乎无法靠肉眼发现的脏数据，两件事加起来一周内能做完。

## 希腊市场值不值得单独做？

看你的品类和进场时机。

坦率说，当时的宏观环境不算好，紧缩政策连着推了几轮，消费信心是弱的，客单价高的品类会比较吃力。但这也意味着竞争密度低，本地电商的成熟度不高，内容做得像样一点就能拉开差距。

家纺这类刚需、耐用、替换周期明确的品类，在这种环境里反而相对稳，因为它不是可以无限期推迟的消费。真正要谨慎的是高客单价的可选消费。保哥的判断是：这种市场适合用小成本先把语言层做扎实，等大环境回暖时，前面攒下的那批常青内容会一次性兑现。

还有一个判断依据：希腊语是一个人口不到千万的市场，但它的语言层门槛高到足以劝退大多数只做机器翻译的对手。门槛高的地方，认真做的人拿到的份额比例反而更高。荷兰和比利时那种共用一门语言的双市场是另一种玩法，可以对照荷兰语在荷兰与比利时两个市场怎么拆词表 (https://zhangwenbao.com/dutch-seo-netherlands-belgium-flemish-two-markets.html)那一篇，两种局面的应对逻辑正好相反。

## 常见问题解答

## Greeklish到底要不要做进页面里？

不要做进可见文本，只做进站内搜索和一处自然提及。页面上的正文、标题、分类名一律用规范的希腊字母，这是不能让步的底线，因为用拉丁字母拼希腊语在正式场合看起来就是不专业，信任损失远大于那点搜索收益。真正该做的是三件事：第一，站内搜索建一张拉丁转写映射表，把多种写法都指向同一个希腊字母的目标词，这一步直接把接不住的那部分查询接回来；第二，在文章正文里让最主流的那一种拉丁写法自然出现一次，比如提一句当地人也常这么拼，让页面能被那种查询理解；第三，绝对不要为拉丁写法单独做一批页面，那等于凭空造出一堆内容雷同的双胞胎互相稀释。判断哪种拉丁写法最主流，最可靠的数据来源是自己站内搜索的空结果查询日志，那份名单就是现成的答案。

## 重音符号在页面上能不能省掉，反正用户也不打？

不能省。用户不打重音是输入习惯，跟拼写规范是两回事，页面上省掉重音在受过教育的读者眼里就是错别字连篇，尤其在商品页和政策页这种需要信任感的地方，损失是实打实的。正确的分工是：可见文本一律标注完整的重音；站内搜索的查询和索引两边都先去重音再比对，这样用户打不打都能搜到；地址和标识符走官方转写标准，重音自然消失。这三条各管一段，互不冲突。需要额外注意的是全大写的场景：希腊语的规则是整个词全大写时要去掉重音，而只有首字母大写时保留，所以不能用一条规则处理所有大写情况。最稳妥的做法是在数据层准备好去重音的大写版本，需要的时候直接取，而不是靠前端样式临场转换，因为样式转换只换字母形态、不动重音，输出的结果本地人一眼就看出不对。

## 怎么快速判断自己的站有没有混入拉丁同形字母？

写一个几十行的脚本扫一遍就知道了，判据很简单：一个文本字段里同时出现了希腊字母区和拉丁字母区的字符，且不属于品牌名、型号、尺寸标记这类合法混排的情况，就是可疑对象。国际化组织维护着一份字符混淆对照表，可以直接拿来当规则来源，不用自己整理。扫描范围要覆盖商品标题、分类名、属性值和地址标识符四个地方，其中属性值最容易中招，因为它经常是从表格里粘贴进来的。发现问题后统一替换成希腊字母，同时必须在录入环节加一道校验，否则修完一轮，下一批数据进来又是老样子。这件事之所以重要，是因为混入的字符肉眼永远发现不了——大写的希腊字母里有十几个跟拉丁字母长得一模一样，而它会同时导致搜索匹配失败、地址异常和数据去重出错三类问题。

## 希腊语的站内搜索一定要上词干还原吗？

不一定，但前两层归一是必需的，第三层可以缓一缓。第一层是符号与字符归一：去重音、把两种sigma形态统一、把混入的拉丁同形字母折叠掉，查询和索引都做，一天工作量。第二层是拉丁转写映射，把几种常见的拉丁写法都指向对应的希腊字母目标词，三到五天工作量，这一层是希腊语站特有的，别的语言都不用做，但它带来的匹配率提升最大。第三层才是词干还原，用来处理四个格加单复数带来的词形变化，用现成的开源组件即可，配置和调优大概一到两周。要注意希腊语的重音位置会随着格变化移动，词干还原组件对这一点的处理质量参差不齐，上线后必须抽查一批高频品类词的还原结果，不能直接信默认配置。另外改搜索时顺手把筛选器一起改，两者通常共用同一套比对逻辑，只改一半用户照样会遇到明明有货却筛不出来的情况。

## 分类页标题该用词典原形还是变格后的形态？

用真实查询里的那个形态，而希腊语里这个形态经常是复数属格，不是词典原形。原因是希腊语表达某某类商品这种结构时要用属格，而分类页标题恰好大量使用这个结构。如果你的标题用的是单数主格，那是一个语法上说不通的组合，用户搜索时打的也不是这个形态，页面主题跟真实查询对不上，排名自然起不来。检验方法只要十分钟：把品类词打进搜索框看下拉建议给出的是哪种形态，再看排在前面的本地竞品标题用的是什么写法，两处一致的那个就是答案。落地时建议把这个形态直接存进品类字典，模板取用时不再做变格计算，因为变格规则有例外，程序算容易出错。还要注意重音位置会跟着格变化移动，属格复数尤其明显，存字典的时候连重音一起存对。

## 希腊语的关键词工具数据能信吗？

能看趋势，不能直接拿来排优先级。工具在希腊语上会低估需求，原因是三层合并它都不做：拉丁转写的查询跟希腊字母写法各算各的；四个格加单复数的形态各算各的；不打重音的写法跟规范写法也各算各的。三层叠起来，工具报出来的单条数字往往只是真实需求的一小块，会让整个市场看起来比实际小很多。正确的用法是先按概念合并再看总量：把一个概念下的所有形态列出来，包括规范写法、去重音写法、三到五种拉丁转写、各个格的形态，全部求和之后再跟别的品类比较。如果工具在你的品类上数据太稀疏给不出有意义的数字，就回到三个土办法：站内搜索日志、本地竞品的标题形态、找几个当地人对同一件商品各写一遍名字。这三招覆盖头部几十个词足够了，长尾等自己的数据攒起来再补。

## 全大写的标题样式为什么不能直接用？

因为希腊语的正字法规定整个词全大写时要去掉重音，而所有靠样式做的大写转换都只换字母形态、不动重音，输出的是一个带着重音的全大写标题，本地人一眼就看出不对。这个坑特别隐蔽，因为开发和测试环节没人会注意到，而它出现在标题样式里意味着全站所有标题一起中招。修的办法有两条：一是在数据层准备好去重音的大写版本，需要全大写效果时直接取那个字段；二是干脆放弃全大写的标题样式，希腊语字形本身辨识度就很高，不靠全大写也够醒目。要特别注意一个例外：只有首字母大写的情况下重音是保留的，所以不能一刀切地把所有大写场景都去重音，得区分首字母大写和全词大写这两种情形。顺带提醒，同样的问题也会出现在导航项、按钮和面包屑上，凡是用了大写样式的地方都要检查一遍。

## 希腊市场规模不大，值得投入吗？

看品类，也看你打算做到什么程度。客观地说这是一个人口不到千万的市场，宏观环境在那几年也不宽松，客单价高的可选消费会比较吃力。但有两个因素让它比数字看起来更有吸引力：一是竞争密度低，本地电商的成熟度不高，内容认真做一点就能拉开差距；二是语言层的门槛高，Greeklish、格变化、重音、同形字母这几道坎足以劝退绝大多数只做机器翻译的对手，门槛高的地方认真做的人拿到的份额比例反而更高。适合早做的是刚需、耐用、替换周期明确的品类，这类需求不会因为经济环境无限期推迟。判断方法可以务实一点：先用一小批内容试水，重点观察站内搜索日志里用户实际打进来的词形，那份数据既能验证你的词写得对不对，也能反映真实的需求密度，比任何市场报告都直接。

## 权威参考资料



## 土耳其语SEO选词，一个词后面挂上五层后缀，出来的就不再是你选的那个词

- URL：https://zhangwenbao.com/turkish-seo-agglutinative-suffix-stacking-keyword.html
- 分类：小语种SEO
- 发布：2011-10-19  |  更新：2026-07-25
- 摘要：讲土耳其语SEO实战：黏着语的后缀叠加与固定顺序、元音和谐让同一后缀有二到四种写法、辅音软化改变词根、名词组合为什么改写了品类核心词、以词根为单位建表并把后缀当意图信号、点i与无点ı的大小写陷阱、专属字符在老通道里的变形、地址拉丁化、站内搜索的三级解法、品牌名撇号规则与本地格式。
- 关键词：关键词研究,内容本地化,小语种SEO

> **TLDR**：摘要：土耳其语把语法信息全塞进后缀里，一个词根后面能接上五六层，每接一层意思就变一次，而每一层后缀本身还有两到四种写法，得看前面的元音是哪一类。结果是同一个概念在搜索框里能长出几十种形态，词表按传统方法根本做不完。更凶的是那个点i和无点ı的问题，一次不带地区设定的大小写转换，就能把地址、去重、登录、排序一起搞坏。这篇按语言机制拆：后缀怎么叠、元音和谐怎么分叉、名词组合为什么改写了核心词、词根该怎么当选词单位，还有那套只有土耳其语才会踩的技术雷。

> 摘要：土耳其语把语法信息全塞进后缀里，一个词根后面能接上五六层，每接一层意思就变一次，而每一层后缀本身还有两到四种写法，得看前面的元音是哪一类。结果是同一个概念在搜索框里能长出几十种形态，词表按传统方法根本做不完。更凶的是那个点i和无点ı的问题，一次不带地区设定的大小写转换，就能把地址、去重、登录、排序一起搞坏。这篇按语言机制拆：后缀怎么叠、元音和谐怎么分叉、名词组合为什么改写了核心词、词根该怎么当选词单位，还有那套只有土耳其语才会踩的技术雷。

先说一个让人哭笑不得的开局。一家做汽车配件的独立站，雨刷、机油滤清器、刹车片这一类，欧洲几个市场跑得不错，看土耳其汽车保有量大、后市场活跃，决定开一个土耳其语版本。

上线之后收录很快，但有个现象很怪：品牌词的排名没问题，品类词几乎全军覆没。团队第一反应是竞争太激烈，加了一批内容，还是没动静。

真正的原因是词写错了。站上分类页写的是silecek，词典里雨刷就是这个词。但土耳其人搜的是cam sileceği——挡风玻璃雨刷，两个名词组合在一起时，后面那个词必须带上一个后缀，词尾也跟着变了形。

silecek和sileceği，在人眼里是同一个东西，在搜索里是两个词。而站上那个写法，恰好是没人用的那一个。

## 黏着语到底把一个词变得多长？

黏着的意思是：语法信息不靠变词根，也不靠单独的虚词，全靠往后面粘后缀，一层接一层，每层管一件事。

拿ev（房子）走一遍：

形态 | 加了什么 | 意思 | 

ev | 词根 | 房子 | 

evler | 复数 | 房子们 | 

evlerim | 复数加我的 | 我的那些房子 | 

evlerimde | 再加在里面 | 在我的那些房子里 | 

evlerimden | 换成从里面 | 从我的那些房子里 | 

evlerimdeki | 再加属于那里的 | 在我那些房子里的那个 | 

六个形态，英语得用六个词组才能表达。土耳其语里它们是六个单词，而且在搜索框里就是六个不同的字符串。

土耳其人自己拿这个特点开玩笑，编过一个几十个字母长的单词，意思大概是像你们这些没能被我们捷克斯洛伐克化的人当中的一员似的。那个词当然没人真用，但它说明了一件事：这门语言的构词没有硬性长度上限。

## 后缀的顺序是固定的

好消息是后缀不能乱排。名词后面的顺序基本是固定的：先复数，再领属，最后是格。动词那边更复杂，但同样有严格顺序。

这意味着你可以用程序穷举组合，不必逐个手工列。做词表时按这个顺序生成候选，再拿真实数据筛一遍，效率比人工高得多。

## 元音和谐：同一个后缀有两种或四种写法

坏消息在这里。土耳其语的元音分成两组，后缀里的元音必须跟词根最后一个元音同组，于是同一个后缀会有两种或四种拼法。

- 复数后缀有两种：一种配后元音的词，一种配前元音的词

- 领属和很多格后缀有四种，因为除了前后还要分圆唇不圆唇

- 选哪一种完全由前面的元音决定，规则明确，但机器要是不实现这套规则，拼出来就是错的

举个直观的例子：房子的复数是evler，路的复数是yollar，同一个复数后缀，因为词根元音不同，写法就不同。

把这一条和后缀叠加放在一起看，组合爆炸就来了：五层后缀，每层两到四种写法，理论组合数是三位数起步。当然实际用到的是其中很小一部分，但足以让你按传统方法穷举词表的想法破产。

## 辅音交替：词根本身也会变

还没完。土耳其语里有几个辅音，词根末尾碰上以元音开头的后缀时会软化：p变b、ç变c、t变d、k变ğ。

书是kitap，加宾格后缀之后变成kitabı，词根最后那个字母变了。颜色是renk，加上后缀变成rengi。这类变化意味着你不能靠简单的字符串前缀匹配去归并词形——词根的最后一个字母都不一样了。

反方向也有：某些后缀跟在清辅音后面时，自己的第一个字母要变清音。在书里面写成kitapta而不是kitapda。

## 名词组合，为什么改写了你的核心词？

这是本文最值钱的一节，也是开头那家配件站栽的那个坑。

土耳其语里两个名词组成一个复合概念时，后面那个名词必须带一个后缀，表示前后是从属关系。这不是可选的修饰，是这门语言的基本构词方式。

组合概念 | 拆开的两个词 | 合起来的正确写法 | 

挡风玻璃雨刷 | cam（玻璃）＋ silecek（雨刷） | cam sileceği | 

机油滤清器 | yağ（油）＋ filtre（滤清器） | yağ filtresi | 

刹车片 | fren（刹车）＋ balata（片） | fren balatası | 

车用轮胎 | araç（车辆）＋ lastik（轮胎） | araç lastiği | 

看第一行和第四行，后面那个词不只是加了后缀，词根末尾的字母也软化了：silecek变sileceği，lastik变lastiği。两条规则叠在一起生效。

这对选词的影响是决定性的：你的分类页标题如果写的是光秃秃的词根，那就是一个本地人不会用来搜的写法。土耳其语的品类词，绝大多数在真实查询里是以组合形态出现的。

实操上有个简单的检验法：把你的品类词逐个丢进搜索框，看下拉建议给出的是哪种形态。如果建议里全是带后缀的组合形式，那你的页面标题就该跟着改。这一步十分钟能做完，能救回整个品类。

## 关键词研究该以什么为单位？

答案是以词根为单位建词表，把后缀当成意图标记。这个思路跟屈折语那边有相通之处，但土耳其语要更彻底一些。

屈折语里，格变化主要影响词的语法角色。土耳其语里，后缀承载的信息更丰富，很多后缀直接就是用户意图的信号。

## 哪些后缀是意图信号？

- 复数后缀：用户在找一批东西，多半是列表意图，该配分类页

- 位格（在里面）：出现场景或地点，常见于本地化查询和使用场景类内容

- 从格（从里面）：常出现在材质、来源、比较类查询里

- 带有的后缀：表示具备某个特性，是筛选属性的天然对应，比如带某种功能的产品

- 不带的后缀：表示不含某成分，在食品、化妆品、配件类目里量很大

- 转成名词的后缀：把动词或形容词变成名词，往往对应一个独立的品类概念

把这些后缀跟词根交叉，就能推出一整片有明确意图的长尾，而且每一条都能对应到具体的页面类型。这比拿词根去凑修饰词高效得多，因为后缀是这门语言里意图的原生表达。

俄语那边用格来承载类似信息，方法论可以互相参考。俄语六个格与词形合并的处理办法 (https://zhangwenbao.com/russian-seo-cyrillic-cases-declension-wordstat-keyword.html)那篇讲的合并思路在这里同样成立，区别在于土耳其语的后缀可以叠加，组合数量比俄语大一个量级，更依赖程序生成加真实数据筛选。

## 点i和无点ı，为什么能把整个站搞崩？

这是土耳其语独有的、也是杀伤力最大的一个技术雷。它跟内容质量、跟翻译水平都没关系，纯粹是代码写法的问题。

土耳其语字母表里有两个i：一个带点，一个不带点。它们是两个不同的字母，读音不同，意思也不同。带点的小写是i，大写是İ；不带点的小写是ı，大写是I。

字母 | 小写 | 大写 | 通用规则会怎么转 | 

带点的i | i | İ | 错转成I，点丢了 | 

不带点的ı | ı | I | 错转成I，看起来对，反向就错 | 

问题出在反向转换上。按通用规则，大写I的小写是i；按土耳其语规则，大写I的小写是ı。同一段代码，在不同的地区设定下会给出不同的结果。

按语言区域做小写转换的接口说明 (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/toLocaleLowerCase)里专门把土耳其语列为需要特殊处理的例子，这不是边缘情况，是被标准明确记录过的已知差异。

## 会在哪些位置出事？

- 地址生成。标题转成地址时通常要先小写，如果服务器的地区设定是土耳其语，标题里的I会变成ı，生成出来的地址跟你预期的不一样，而且同一个标题在不同环境下生成的地址还可能不同。

- 登录与去重。邮箱地址做小写归一时，带I的邮箱在土耳其语设定下会被转成带ı的形态，跟注册时存的对不上，用户直接登不进去。

- 字符串比较。做不区分大小写的比较时，两个本该相等的字符串被判成不等，或者反过来。

- 站内搜索。查询和索引如果在不同环节用了不同的地区设定，匹配率会莫名其妙地下降，而且极难排查。

- 配置与标识符。程序里的配置项名称、模板标签、类名如果走了小写处理，在土耳其语环境下会变成另一个字符串，直接报找不到。

处理原则很简单，但必须写进规范：面向用户展示的文本，按土耳其语规则转；程序内部的标识符、地址、邮箱、配置项，一律用不带地区设定的固定规则转。两条路分开走，别混用。

大小写映射里的语言相关规则说明 (https://unicode-org.github.io/icu/userguide/transforms/casemappings.html)把这类差异整理得很清楚，做技术方案时值得让工程团队完整读一遍，比出事之后再排查便宜太多。

## 土耳其字符在老系统里会怎么变形？

土耳其语的专属字母有六个：ç、ğ、ı、ö、ş、ü，加上大写的İ。在统一编码普及之前，本地系统用的是专门的单字节编码方案。

这段历史留下的痕迹，今天做站还会撞上：

- 批量导入：表格文件按老编码存，导进来ş和ğ全变问号

- 短信通知：短信通道对非基础拉丁字符的支持参差不齐，土耳其字符经常被替换成近似字母，或者让单条短信的字数上限直接砍半

- 物流面单：收件人姓名里的ğ被吃掉，快递员看到的是个残缺的名字

- 发票系统：财务系统往往最老，也最容易在这里出问题

- 字体子集：网页字体按拉丁基本字符集裁剪，ğ和ş掉回系统默认字体，一行字里几个字母长得不一样

老规矩，端到端测一遍。造一条姓名和地址里塞满六个土耳其字符的测试数据，从下单一路走到短信通知、物流面单、发票，看它在哪一环变了形。一小时的事，能省掉后面无数次客服工单。

## 地址里的ş和ğ该怎么处理？

建议路径部分做拉丁化，映射规则写死：ç变c、ğ变g、ı变i、ö变o、ş变s、ü变u，大写的İ按小写的i处理。

注意最后这一条正是前面那个雷的延伸——拉丁化必须用固定规则，不能依赖运行环境的地区设定。同一个标题在不同机器上生成出不同的地址，是这门语言里最容易发生也最难查的事故之一。

另外，带土耳其字符的地址在传输时会被编码成一串百分号，这个机制本身没问题，但会让地址变得没法看也没法口述。地址里的百分号编码到底是怎么回事 (https://zhangwenbao.com/uri-codec-percent-encoding-encode-decode-guide.html)那篇把编码与还原的过程讲得比较细，理解了机制，就不会写出互相打架的两套规则。

还有一条铁律照旧：地址一旦发布就不要再改。土耳其语的形态那么多，很容易让人产生换个写法更贴合搜索的冲动，忍住，改地址的损失远大于形态优化的收益。

## 站内搜索为什么在土耳其语站上匹配率特别低？

三个原因叠在一起：后缀让用户输入的形态跟你库里存的不一样；元音和谐让同一个后缀有多种拼法；辅音交替让词根本身都变了形。

结果就是按字符串匹配的搜索几乎不可用。用户搜cam sileceği，库里存的是silecek，前缀都对不上。

解法从便宜到贵排三层：

方案 | 做法 | 能解决什么 | 

字符归一 | 查询与索引都把六个专属字符映射成基础字母再比对 | 用户不打专属字符的情况 | 

同义词表 | 高频查询的组合形态手工映射到商品词 | 名词组合与常见后缀形态 | 

词干还原 | 接入土耳其语的词干还原组件 | 后缀叠加与词根软化 | 

土耳其语词干还原算法的完整说明 (https://snowballstem.org/algorithms/turkish/stemmer.html)把它处理的后缀类型和边界条件列得很细，选型时先读一遍，能判断出你的品类词会不会被它误伤。

顺带提醒一句：土耳其语的词干还原比大多数语言难，因为后缀能叠加，剥离的层数不好把握，剥多了会把不同的词归并到一起。上线后一定要抽查一批高频词的还原结果，别直接信默认配置。

## 用户不打专属字符怎么办？

跟波兰语那边一样，相当一部分用户在搜索时会用基础拉丁字母代替，把ş打成s、ğ打成g、ı和i不分。手机上尤其明显。

处理原则也一样：可见文本一律用规范写法，容错留给自己的系统。页面上把ş写成s，本地人看起来就是错别字，信任成本远高于那点搜索收益。

需要做的是三件事：站内搜索做字符归一；筛选器跟着一起改，别只改搜索；地址走固定规则的拉丁化。搜索引擎那一侧对土耳其语的字符容错已经不错，不需要你为它单独造无变音版本的页面。

这套判断在波兰语的九个变音字母该怎么处理 (https://zhangwenbao.com/polish-seo-seven-cases-diacritics-keyword-research.html)那篇里也是同一个结论。变音字母多的语言，坑的形状高度相似，方法可以直接搬。

## 字母顺序跟你想的不一样

土耳其语字母表二十九个字母，没有q、w、x，多了六个专属字母，而且它们在字母表里有固定位置：ç紧跟在c后面，ğ紧跟在g后面，ı排在i前面，ö跟在o后面，ş跟在s后面，ü跟在u后面。

注意ı排在i前面，这跟按码位排序的结果正好相反。用通用排序规则排出来的品牌列表、属性列表、字母索引，在本地人眼里就是乱的。

解决办法是建库时把排序规则定成支持土耳其语的那一套。至于字母索引导航，建议跟波兰语一样，不给专属字母单开格子，用户找ş开头的词习惯去s那一格。

## 语序是主宾谓，标题该怎么写？

土耳其语的基本语序是主语、宾语、谓语，动词在最后。修饰成分也一律放在被修饰词前面。

这对标题的影响是实打实的：如果你的标题模板是照着英语的语序拼的，土耳其语版本读起来会非常别扭，本地人一眼看出是翻译腔。

几条实用建议：

- 核心品类词尽量靠前，但要用它在真实查询里的组合形态，不是词根

- 不要在标题里硬拼动词，土耳其语的动词在句末，硬塞到中间会很怪

- 属性作为独立标签甩在后面，用分隔符隔开，既避开语序问题也避开一致问题

- 注意长度，土耳其语的词因为后缀而更长，搜索结果里能显示的字符有限，后半截被切掉的概率高

日语那边也是动词在最后的语序，处理标题时的思路可以互相印证。日语的三套文字与表记选择 (https://zhangwenbao.com/japanese-seo-hiragana-katakana-kanji-keyword-notation.html)那篇里讲的标题结构原则，在土耳其语这边同样适用，尤其是把核心词前置、把修饰甩到后面这一条。

## 土耳其语的意图词，哪些必须收进词表？

意图 | 常见词 | 该配什么内容 | 

购买 | satın al、fiyat、fiyatları | 产品页与分类页 | 

比价 | ucuz、indirim、kaç para | 促销页与价格说明 | 

口碑 | yorum、yorumları、şikayet | 评价与售后说明 | 

选购 | en iyi、hangisi、tavsiye | 选购指南与榜单 | 

用法 | nasıl、nedir、ne işe yarar | 教程与术语解释 | 

交付 | kargo bedava、taksit | 运费与支付说明 | 

注意fiyat和fiyatları这一对。前者是价格，后者是带复数和领属后缀的形态，意思接近某某的价格们。后者在真实查询里的量往往更大，因为用户搜的是某个具体品类的价格，那个组合天然要带后缀。

还要留意yorum。土耳其用户对评价内容的依赖程度很高，几乎每个品类都有可观的评价类查询。如果你的商品页上没有真实评价，这部分流量接不住也留不下。

## 分期付款为什么是绕不过去的一项？

这一节不属于语言层，但不讲会误事。土耳其的线上消费里，信用卡分期是极其普遍的付款方式，普遍到用户会把分期能力当成筛选条件之一。

体现在搜索上，就是分期这个词经常直接出现在查询里。体现在页面上，就是产品页必须把可分几期、每期多少写清楚，写在价格旁边而不是藏在结算页。

这件事对跨境卖家不太友好，因为分期通常依赖本地收单机构。但至少有两件事可以做：一是把当前支持的支付方式在页面上说清楚，别让用户到最后一步才发现；二是如果确实提供不了分期，就在价格策略和运费上找补，把总价的确定性做足。

## 域名那道门槛怎么绕？

土耳其的国家域名后缀有个出了名的特点：商业二级域的注册需要提交商标或者营业执照之类的证明材料，不是填个表就能拿到的。

对大多数跨境卖家来说，这意味着走本地后缀的成本比别的市场高不少。现实的选择是用国际通用后缀，把本地信号放在别的地方补：本地地址、本地客服电话、本地支付方式、本地物流合作方。

这些信号加起来的效果，未必比一个本地后缀差。至于用什么域名结构承载多语言站点，那是架构层的题目，跟语种本身无关，不在这里展开。

倒是有一件跟语言直接相关的事要提醒：域名里能不能用土耳其语的专属字符。技术上可以，但强烈建议别用。原因跟前面地址那一节一样——那六个字符里有几个在传输和显示环节的处理链路很长，任何一环出岔子都会让域名变得没法复制、没法口述、没法印在包装上。国际市场上通行的做法是域名只用基础拉丁字母，本地特色留给内容去表达。

还有一个容易被忽视的细节：域名如果包含无点的那个字母，跟带点的那个在视觉上极易混淆，这既是用户体验问题，也可能被人拿去做仿冒。选域名的时候把这两个字母的组合直接排除掉，省心。

## 机器翻译在土耳其语上最容易犯什么错？

三类错误有明显模式，认出来就能快速筛查。

第一类是后缀接错。元音和谐选错组、辅音交替没处理、后缀顺序颠倒，这三种在长句里出现频率很高。本地人读起来是一种说不上哪里不对但就是别扭的感觉。

第二类是名词组合没加后缀。也就是开头那家配件站踩的坑，翻译引擎经常把两个名词直接并排放，缺了那个表示从属关系的后缀。这是最影响搜索的一类错误。

第三类是语序照搬。把动词放在句子中间，或者把修饰成分放到被修饰词后面。整段读下来节奏是错的。

筛查方法：让审校专门盯这三类，不要求逐句润色。审校成本能降一大截，抓住的问题反而更集中。

## 品牌名后面那个撇号，到底要不要写？

土耳其语里专有名词加后缀时，习惯用一个撇号把词干和后缀隔开。品牌名、地名、型号在句子里当名词用，就会遇到这个规则。

对做搜索的人来说，这条规则带来三个实际问题。

第一，同一个查询有带撇号和不带撇号两种写法。用户打字时经常省掉撇号，尤其在手机上。两种写法在字符串层面完全不同，站内搜索如果不做归一，就会漏掉一半。

第二，撇号本身有好几个长得几乎一样的字符。直排的那个、弯的那个、还有输入法自动替换出来的那个，视觉上难分辨，字节上是不同的字符。用户从别处复制粘贴过来的查询，用的可能是任意一种。

第三，后缀的形态取决于品牌名怎么读，而不是怎么拼。外来品牌名尤其麻烦，本地人按发音选后缀的元音，可同一个名字不同的人读法可能不一样，于是市面上会同时流传两种写法。

处理建议是这样的：

- 页面上的正式写法带撇号，用直排的那一个，全站统一，这是规范用法

- 站内搜索做撇号归一，把所有变体和缺失的情况都映射到同一个目标

- 地址里一律去掉撇号，跟着拉丁化规则一起处理

- 后缀形态官方定一种，用在所有正式场合，同时确保页面上最流行的那种民间写法也自然出现过一次

- 型号不加后缀，带数字和字母的组合一律保持原样，加后缀会切断跟国际数据源的匹配

第四条的道理跟品牌名转写是一样的：你不主动定一个标准写法，市场会自己叫出一个来，等叫开了再改就是跟用户习惯作对。

## 内链的锚文本，后缀该怎么带？

跟屈折语一样，土耳其语的锚文本在句子里必须跟着语法环境带后缀，硬塞词根会造出病句。

但土耳其语这边多一层麻烦：品类词在真实查询里本来就是带从属后缀的组合形态，而在句子里它还要再加格后缀。两层叠加之后，锚文本跟你想强调的那个核心形态可能已经差得比较远了。

保哥的处理办法是分工：锚文本服从句子，周围的文字负责精确。锚用自然的形态，紧挨着的那句话里把标准组合形态自然地提一次。这样读起来通顺，语义也完整。

还有两个细节值得注意。一是别把整句话做成锚，锚应该落在具体的名词短语上；二是同一个目标页在全站的锚文本不必强求一致，随上下文自然变化反而更像人写的。

## 问句型查询在土耳其语里长什么样？

问句型查询在土耳其语里的比例很高，而且它有一个别的语言没有的特点：疑问本身也可以后缀化。

是非问句靠一个疑问小品词构成，那个小品词跟着元音和谐变形，写成四种形态之一，位置在被问的成分后面。这意味着一个是非问句在搜索里可能有好几种拼法，而它们表达的是同一个问题。

常用的疑问词值得单独整理成一张表，它们直接对应内容形态：

- nasıl：怎么做，对应操作教程与安装步骤，量最大的一类

- nedir：是什么，对应术语解释与品类科普

- ne kadar与kaç para：多少钱，对应价格与报价内容

- hangisi：哪一个，对应对比与选购指南

- neden：为什么，对应原理与故障排查

- ne işe yarar：有什么用，对应功能说明，在配件类目里量很大

把这几个词跟你的品类词交叉，能一次性铺出几十条真实存在的长尾。注意一点：交叉时品类词要用组合形态，不是词根，否则拼出来的查询本地人不会那么打。

做常见问题模块时还有个小技巧：问题标题直接用用户的问法，答案第一句给一个干脆的判断。土耳其语的问句结构比较固定，照着用户的问法写，命中率明显更高。

## 称呼用sen还是siz，影响转化吗？

影响，而且比想象中大。土耳其语的第二人称有两个：一个用于熟人和平辈，一个既是复数也是敬称。

商业内容的默认选择是敬称那一个，几乎所有正规的本地零售站都这么写。用熟人称呼的站不是没有，但集中在面向年轻人的时尚、潮流类品牌，而且是有意为之的品牌调性选择，不是随便定的。

问题在于翻译环节很容易混用。同一个站里，商品页用敬称，弹窗提示用熟人称呼，邮件模板又换回敬称，读者会觉得这个品牌人格分裂。

建议在本地化开始之前就把这一条定死写进文档，并且明确告诉所有译者和审校。这是个零成本的决定，但事后统一的代价很高——因为称呼变了，跟在后面的动词形态也要跟着变，不是全局替换一个词就能改完的。

## 后缀让词变长，界面会被撑成什么样？

土耳其语的单词因为后缀叠加而偏长，同一句话的字符数通常比英语多出两成上下，个别短标签能翻倍。这在界面上会集中爆发。

位置 | 典型症状 | 处理方向 | 

按钮 | 文字撑破固定宽度或被截断 | 宽度自适应，别写死 | 

导航 | 一级菜单掉到第二行 | 允许折行或缩减层级 | 

筛选器 | 属性名换行成三行，整块被撑高 | 属性名缩写，长名给悬停提示 | 

表格表头 | 列宽被最长的表头绑架 | 表头换行，或用图标加提示 | 

搜索结果标题 | 后半截被切掉 | 核心词前置 | 

短信通知 | 字数上限被专属字符砍半 | 模板按最短情况设计 | 

最后一行值得展开一句。短信通道对非基础拉丁字符的支持方式，会直接影响单条短信能装多少字。土耳其语的文案里必然带专属字符，如果模板是按英语字数设计的，实际发出去会变成多条，成本翻倍不说，断句位置也可能很难看。

处理办法不是逼译者压字数，压出来的文案通常很生硬。更好的路径是让模板本身有弹性，同时把关键信息前置——反正后半截随时可能被切掉，那就别把重要的东西放在后面。

## 数字、日期和价格该怎么写？

这类格式写错不影响功能，但会持续消耗信任，本地人扫一眼就知道这站不是本地做的。

- 小数用逗号，千位用点，一千二百三十四点五写成1.234,5

- 货币符号后置，写在数字后面

- 日期是日在前，用点分隔

- 电话号码有固定的分组习惯，占位符要按本地格式写，别照搬英语模板

- 尺寸与单位用公制，数字与单位之间的写法要全站统一

价格这一项在土耳其市场还有个额外要求：把分期后的每期金额也显示出来。前面讲过分期是这个市场的基本预期，只写总价的产品页，在转化上会明显吃亏。

## 母语审校该怎么验收？

- 先给词表。核心品类词、品牌名、型号列成一张表随稿交付，并且注明哪些词不许改

- 明确组合形态。告诉审校品类词在标题里要用真实查询里的组合形态，不是词典原形

- 专项检查后缀。让审校单独扫一遍元音和谐与辅音交替，这两类母语者最敏感

- 检查语序。整段读一遍，凡是读着像翻译的地方标出来

- 回搜验证。改动过的核心词丢回搜索框，确认改后的写法确实有人用

保哥的经验是第五条永远是最后一道闸。语法完美但没人搜的词，对搜索来说是负资产，这条在每门语言里都成立。

## 上线前的语言层检查清单

- 品类词是否用了真实查询里的组合形态，而不是词典原形

- 词表是否以词根为单位聚类，后缀是否被当成意图信号分类

- 大小写转换是否区分了展示文本与内部标识符两条路径

- 地址生成是否使用不依赖地区设定的固定规则

- 登录、去重、比较这几处是否排查过大小写归一的隐患

- 六个专属字符在标题、正文、地址、数据库里是否一致存活

- 拉丁化映射表是否写死并全站统一

- 站内搜索是否做了字符归一，筛选器是否一起改了

- 词干还原的结果是否抽查过，有没有把不同的词归并到一起

- 排序规则是否设成支持土耳其语的那一套

- 标题语序是否符合本地习惯，没有硬拼动词

- 短信、面单、发票这些老通道是否做过端到端字符测试

- 支付方式与分期信息是否写在价格旁边

十三条里只有四五条需要工程介入。剩下的全是有人认真过一遍就能解决的事——而经验里翻车的项目，缺的从来不是能力，是没人把这张表认领下来。

## 常见问题解答

## 土耳其语的关键词表，到底该以词根还是以完整形态为单位？

以词根为单位建表，以完整形态做输出。这两件事必须分开。建表阶段按词根聚类，把所有带后缀的形态归到同一个概念下求和，这样才能正确判断一个品类值不值得做；如果按形态逐条排优先级，同一个概念的量会被切成几十份，每一份看起来都不值得投入，结论必然是错的。输出阶段则要看真实查询用的是哪个形态，尤其是名词组合类的品类词，绝大多数在真实查询里是带后缀的组合形式，标题里必须用那个形态。判断方法很简单：把词丢进搜索框看下拉建议，建议里出现的形态就是用户在打的形态。另外提醒一点，土耳其语的后缀可以叠加，穷举组合数量很大，建议先用程序按固定的后缀顺序生成候选，再拿搜索建议和站内搜索日志筛一遍，纯手工列是列不完的。

## 点i和无点ı的问题，具体该怎么防？

把大小写转换分成两条路径，写进开发规范里。面向用户展示的文本，比如标题的美化显示、界面文案，用带土耳其语地区设定的转换，这样İstanbul这类词才不会显示错。程序内部的一切标识符，包括地址生成、邮箱归一、配置项名称、模板标签、字符串比较，一律用不依赖地区设定的固定规则转换。混用这两条路是绝大多数事故的根源，因为同一段代码在不同服务器的地区设定下会给出不同结果，而这种问题在测试环境往往复现不出来。落地时还有两个检查点：一是审一遍代码里所有的小写转换调用，看有没有漏掉地区参数的；二是造一批包含大写I和带点大写İ的测试数据，跑一遍注册、登录、下单、搜索的完整链路。这个雷排一次就能一劳永逸，但没排过的站几乎必然会中。

## 名词组合的后缀，为什么会让整个品类页失效？

因为土耳其语里两个名词组成复合概念时，后面那个名词必须带上表示从属关系的后缀，而且词根末尾的辅音还可能跟着软化。这不是可选的修饰，是构词的基本规则。用户在搜一个具体品类时，脑子里的词就是那个组合形态，打出来的也是它。如果你的分类页标题写的是光秃秃的词根，那就等于用了一个本地人不会用来搜的写法，页面主题跟真实查询对不上，排名自然起不来。检验方法只要十分钟：把你的所有品类词逐个丢进搜索框，看下拉建议给出的是哪种形态；再看排在前面的本地竞品，它们的标题用的是什么写法。两处一致的那个形态，就是你该用的。这一步能救回整个品类，是投入产出比最高的一次检查。

## 土耳其语的站内搜索一定要上词干还原吗？

不一定，但优先级比大多数语言高，因为后缀叠加让字符串匹配几乎完全失效。建议按三层推进：第一层做字符归一，把六个专属字符映射成基础字母，查询和索引都做，半天工作量，能解决用户不打专属字符的那部分；第二层做同义词表，把高频品类词的组合形态、常见后缀形态手工映射到商品词，两三天工作量，能解决名词组合这个最大的痛点；第三层才是接入词干还原组件。特别要注意的是，土耳其语的词干还原比大多数语言难，因为后缀能叠加，剥离层数不好把握，剥多了会把语义不同的词归并到一起。上线后必须抽查一批高频词的还原结果，不能直接信默认配置。另外改搜索时一定要顺手改筛选器，两者用的是同一套比对逻辑，只改一半的话用户照样会遇到明明有货却筛不出来的情况。

## 页面上的土耳其字符要不要为了搜索而简化？

不要。可见文本一律用规范写法，把ş写成s、ğ写成g的页面在本地人眼里就是错别字连篇，信任损失远大于那点搜索收益。用户不打专属字符这件事应该在别的层面消化：站内搜索做字符归一，筛选器跟着一起改，地址走固定规则的拉丁化。搜索引擎那一侧对土耳其语的字符容错已经相当成熟，你不需要为它单独造一批无变音版本的页面，那样只会造出一堆内容雷同、互相稀释的页面，得不偿失。唯一可以适度让步的地方是站内搜索的联想提示，可以同时接受两种输入并给出相同的结果，但展示出来的候选词仍然要用规范写法。这样既照顾了输入习惯，又没有牺牲页面的专业度。

## 土耳其语的标题模板能不能自动生成？

可以，但要绕开两个陷阱。第一个是名词组合的后缀，模板如果直接把品类词和属性词并排拼，缺了那个从属后缀，输出的就是本地人不会用的写法。第二个是语序，土耳其语的修饰成分放在被修饰词前面、动词放在句末，照着英语语序拼的模板读起来是明显的翻译腔。比较现实的做法是：把品类词在属性字典里直接存成组合形态，模板取用时不再拼接；属性值作为独立标签用分隔符甩在标题后面，避开语序和一致性问题；带来主要流量的那几十个品类的标题全部人工写定，长尾走模板。还有一条容易被忽略的：标题长度。土耳其语的词因为后缀而更长，搜索结果里能显示的字符有限，核心词一定要放在最前面，否则后半截被切掉的概率很高。

## 品牌名加后缀时的撇号，页面上要不要写？

正式写法要写，但要配一整套容错。土耳其语里专有名词加后缀习惯用撇号隔开，页面上的规范写法应该带上，并且全站统一用同一个撇号字符。麻烦在于三点：一是用户打字时经常省略撇号，尤其在手机上；二是撇号有好几个长得几乎一样的字符，用户从别处复制粘贴过来的可能是任意一种；三是后缀的形态取决于品牌名怎么读而不是怎么拼，外来品牌名容易出现两种流传写法。对应的处理是：页面正式写法带撇号并统一字符；站内搜索把所有撇号变体和缺失情况归一到同一个目标；地址里一律去掉撇号，跟拉丁化规则一起处理；官方定一种后缀形态用在所有正式场合，同时确保最流行的民间写法在页面上自然出现过一次。型号除外，带数字和字母的组合一律保持原样不加后缀。

## 土耳其市场适合什么阶段进入？

看你的品类结构和本地化能力。土耳其的吸引力在于人口年轻、线上消费活跃、本土供给在部分品类上并不强，跨境卖家有明确的切入空间；难点在于本地化的门槛比欧洲市场高一截，语言层的坑多，支付习惯特殊，物流和清关的确定性也不如西欧。经验上的判断方法是：如果你的品类客单价中等偏上、不高度依赖分期、并且能提供确定的到货时效，那土耳其是值得早做的市场，因为竞争密度相对低；如果你的品类价格敏感、成交高度依赖分期能力，那在解决本地支付之前进场会很吃力，内容做得再好也换不来订单。还有一条建议：先用一小批内容试水，重点观察站内搜索日志里用户实际打的词形，那份数据比任何工具都准，也能快速验证你的品类词写法对不对。

## 怎么快速判断一段土耳其语文案是不是机器翻译的？

盯三个特征，不需要精通土耳其语也能看出大概。第一个是名词组合，两个名词并排出现而后面那个没有带从属后缀，这是翻译引擎最常犯的错，也是最伤搜索的一类。第二个是动词位置，土耳其语的动词在句末，如果整段里动词频繁出现在句子中间，那多半是照着英语语序直译的。第三个是后缀的一致性，同一个词在同一段里出现了两种不同的后缀写法，或者后缀的元音跟词根明显不同组，那就是元音和谐没处理对。这三条可以做成一张小卡片发给内容团队，验收时对着扫一眼，比逐句读快得多。要强调的是，机器翻译当初稿工具完全没问题，问题只出在直接发布上，配一轮针对这三类问题的定向审校，成本不高但效果立竿见影。

## 权威参考资料



## 如果波兰语SEO只按词典原形选词，七个格里有六个格的搜索你都接不住

- URL：https://zhangwenbao.com/polish-seo-seven-cases-diacritics-keyword-research.html
- 分类：小语种SEO
- 发布：2010-12-22  |  更新：2026-07-25
- 摘要：讲波兰语SEO实战：七个格与单复数把一个词撑成十种形态、哪几个格在搜索里真正高频、九个变音字母与不打变音的写法怎么处理、老编码残骸在导入与接口环节的爆点、地址拉丁化的映射规则、站内搜索空结果的三级解法、锚文本变格、界面文案的三种复数形态、商品标题模板的性数格一致问题，以及表单与地址字段的本地化。
- 关键词：关键词研究,站内搜索,小语种SEO

> **TLDR**：摘要：波兰语把名词、形容词、数词、连品牌缩写都拉进了变格系统，一个普通名词能变出十种不同写法，而用户搜索时用的往往不是词典里那个原形。再叠上九个变音字母、一半用户懒得打变音、老系统里留下的编码残骸，还有界面文案里那套一少多三分的复数规则，做波兰语站的难点就全齐了。这篇按语言本身的机制来拆：变格怎么把词表撑爆、变音符号在哪几环丢失、地址该不该用波兰字母、站内搜索为什么几乎不可用、锚文本变形怎么处理，以及一份能直接照着打勾的上线清单。

> 摘要：波兰语把名词、形容词、数词、连品牌缩写都拉进了变格系统，一个普通名词能变出十种不同写法，而用户搜索时用的往往不是词典里那个原形。再叠上九个变音字母、一半用户懒得打变音、老系统里留下的编码残骸，还有界面文案里那套一少多三分的复数规则，做波兰语站的难点就全齐了。这篇按语言本身的机制来拆：变格怎么把词表撑爆、变音符号在哪几环丢失、地址该不该用波兰字母、站内搜索为什么几乎不可用、锚文本变形怎么处理，以及一份能直接照着打勾的上线清单。

先讲一个不太光彩的开局。一家卖电动工具配件的独立站，钻头、锯片、砂纸盘那一类，德国市场跑得挺稳，团队想顺势往东边推，第一站选了波兰。

波兰的理由很硬：中欧人口最多的市场，制造业和家装消费都活跃，工具类目天然有需求，而且竞争密度比德国低一大截。翻译外包给了华沙的一家小工作室，质量没得挑。

三个月过去，收录正常，排名却始终卡在第二页往后。分析日志的时候发现一件怪事：站内搜索的空结果率高得离谱，接近四成。用户明明搜的就是站上有的商品，系统却告诉他们什么都没找到。

顺着这条线拉下去，问题才露出来。用户搜的是wiertarki，站上写的是wiertarka。同一个词，一个是复数或者属格形式，一个是词典原形。人眼看是一回事，程序看是两个毫不相干的字符串。

这不是某个工程师偷懒，这是波兰语这门语言的结构，跟按英语习惯搭出来的系统天生不兼容。

## 七个格到底把一个词变成多少种写法？

波兰语有七个格，名词单复数各一套，理论上十四个格位。实际会有一些形式重合，最后落到不同拼写上通常是八到十种。

还是拿wiertarka（电钻）举例，这是个阴性名词，工具类目里最典型的一个词：

格 | 大致相当于 | 单数 | 复数 | 

主格 | 谁、什么（做主语） | wiertarka | wiertarki | 

属格 | 谁的、没有什么 | wiertarki | wiertarek | 

与格 | 给谁 | wiertarce | wiertarkom | 

宾格 | 把什么（做宾语） | wiertarkę | wiertarki | 

工具格 | 用什么、和什么一起 | wiertarką | wiertarkami | 

方位格 | 在什么里面、关于什么 | wiertarce | wiertarkach | 

呼格 | 直接称呼 | wiertarko | wiertarki | 

数一下不重复的写法：wiertarka、wiertarki、wiertarce、wiertarkę、wiertarką、wiertarko、wiertarek、wiertarkom、wiertarkami、wiertarkach，整整十种。

更要命的是形容词也跟着变。冲击钻是wiertarka udarowa，属格变成wiertarki udarowej，复数主格是wiertarki udarowe。一个两词短语，两个词一起变形，组合数量直接翻番。

wiertarka这个词在波兰语词典里的词条 (https://sjp.pl/wiertarka)可以直接查到它的全部变格形式，做词表时这类词条页是最省事的起点，比自己套规则可靠得多——因为波兰语的变格规则有大量例外，靠背规则一定会翻车。

## 哪几个格在搜索里真的高频？

七个格在搜索里的分布极不均匀，做词表时不必平均用力。按实际出现频率排：

- 主格：单纯查这个东西，也是标题里最该用的形态

- 属格：出现在数量、否定和大量固定搭配里，是复合查询里最常见的一个

- 宾格：跟在买、找、要这类动词后面，商业意图查询的主力

- 方位格：跟在关于、在里面这类介词后面，信息型查询常见

- 工具格：跟在用什么、带什么后面，配件类查询里不少

- 与格与呼格：搜索里几乎不出现，可以直接忽略

换句话说，真正要覆盖的是前五个，其中前三个吃掉了绝大部分量。这个判断能把工作量砍掉三成，而且几乎不损失覆盖。

## 关键词工具给的数字，为什么在波兰语里不能直接用？

因为工具对词形的处理方式，跟波兰语的实际情况对不上，而且对不上的方向还不止一种。

有的工具把不同词形当成完全独立的查询分别计数，于是同一个概念的量被切成七八份，每一份看起来都小得不值得做。有的工具做了一定程度的合并，但合并规则是按通用语言写的，对波兰语的变格覆盖不全，结果是一部分合了、一部分没合。

这两种情况都会让你做出错误决策。前一种让你低估整个品类，后一种让你在两个其实是同一个词的条目上重复投入。

## 三步把词形合起来看

- 先按词根分组。把导出的词表按去掉词尾之后的公共部分聚类，wiertark开头的全归一组。这一步用最土的字符串前缀匹配就行，不需要真正的语言学处理。

- 组内求和，但保留明细。求和后的数字用来判断这个概念值不值得做，明细用来判断页面上该主打哪个形态。

- 把形态和位置对应起来。量最大的那个形态放标题，其余高频形态放在正文和小标题里自然出现。不要把七个格硬塞进同一个标题，那读起来像机器写的。

这套做法跟处理俄语时的思路是同一条：俄语六个格把一个词撑成十几种写法 (https://zhangwenbao.com/russian-seo-cyrillic-cases-declension-wordstat-keyword.html)那篇里讲的合并逻辑，在波兰语这边照样成立，只是波兰语多一个格、变音字母更多、例外也更密。两门语言的差别不在方法，在工作量。

## 九个变音字母，用户到底打不打？

波兰语的专属字母有九个：ą、ć、ę、ł、ń、ó、ś、ź、ż。它们不是装饰，改一个字母就是另一个词，甚至是另一个意思。

但现实是，相当一部分用户在搜索时不打这些字母。原因很朴素：波兰语键盘上打变音要按住组合键，手机上更麻烦，而搜索引擎大多数时候能猜对，用户就懒得费那个劲。

结果就是同一个概念有两套查询：带变音的规范写法，和全部换成基础拉丁字母的偷懒写法。śrubokręt和srubokret，żarówka和zarowka，都是活的查询。

## 不带变音的写法要不要单独做页面？

不要。这是保哥见过最常见的一种过度反应——为了覆盖无变音写法，硬造一批只改了拼写的页面，结果是一堆内容雷同的页面互相打架。

正确的处理分三层：

- 可见文本一律用规范写法。标题、正文、导航全部带变音，这是专业度的底线，写错了本地人一眼看出来

- 站内搜索必须两种都认。搜索时先把查询做一次变音归一，再去匹配同样归一过的索引，这是投入最小、收益最大的一步

- 地址走归一后的形态，理由下一节细说

至于搜索引擎那一侧，它对变音的容错在波兰语上已经相当成熟，你不需要为它专门做什么。真正会因为变音丢流量的，是你自己站里的搜索框和筛选器。

这个结论跟德语市场是一致的。德语的变音符号和那个特殊字母怎么处理 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)那篇里得出的也是同一条：可见文本守规范，容错留给自己的系统。区别在于波兰语的变音字母有九个而不是四个，撞车概率高出一截，映射表得写得更细。

## ó与u、ż与rz：同音不同写

波兰语里有几组字母发音相同但拼法不同：ó和u、ż和rz、ch和h。哪个词用哪个写法靠记，本地人小学阶段专门练这个，成年人照样会写错。

这意味着拼写错误型查询在波兰语里的比例明显高于西欧语言。用户把ó打成u、把ż打成rz，是很常见的事。

处理方式跟无变音写法一样：不为错误拼写单独建页面，但站内搜索要能容错，常见错拼要收进同义词配置。另外在做内容规划时，如果发现某个错拼形态的量大到离谱，那通常说明这个词本身对本地人就是个难点，可以在内容里顺手解释一句，反而是个加分项。

## 编码遗留会在哪一环咬你一口？

波兰语在计算机里的历史比大多数语言都乱。在统一编码普及之前，波兰字符至少有过好几套互不兼容的方案，早年本土系统里还流行过一套自成一派的编码。

这段历史留下的后果，今天做站还会撞上：

环节 | 典型症状 | 触发条件 | 

批量导入商品 | ł、ą全变成问号或方块 | 表格文件按老编码存的 | 

老系统对接 | 字符看起来对，比对却不相等 | 两侧编码声明不一致 | 

邮件通知 | 标题乱码，正文正常 | 标题编码没按规范声明 | 

导出报表 | 打开是乱码，换个软件又正常 | 导出时没写编码标记 | 

第三方物流接口 | 收件人姓名被吃掉字符 | 对方只收基础拉丁字符 | 

这几类问题的共同点是不会立刻暴露。页面照常打开，订单照常生成，只有某个带变音字母的姓名或地址走到某个环节时才出事，而那时候订单已经发出去了。

唯一靠谱的办法是端到端测一遍。造一条测试数据，姓名里塞满九个变音字母，从下单一直走到发货通知和物流面单，看它在哪一环变了形。这件事一小时就能做完，能省掉后面无数次客服工单。这类字节层面的排查思路，可以顺着字符在字节层面到底长什么样 (https://zhangwenbao.com/hex-codec-utf8-byte-encoding-charset-debug-guide.html)那篇再过一遍，看懂了字节就不会被表象骗。

## 地址里该用波兰字母还是拉丁化？

技术上两条路都通。域名层面，带波兰字母的地址早就可以注册，.pl下带本地字母域名的注册说明 (https://www.dns.pl/en/idn)把可用字符和注册规则写得很清楚。路径层面，带变音的字符也能正常工作，只是传输时会被编码成一串百分号。

但保哥的建议依然是路径部分做拉丁化，理由有四条：

- 可复制可口述。带百分号编码的地址复制出来是一长串乱码，发在聊天里、印在包装上都不体面

- 外部链接更稳。别人引用你的地址时，编码形态容易在中间环节被改写，导致链接失效或者分裂成多条

- 日志好读。分析访问日志时，一屏的百分号编码会让人当场放弃

- 规则容易统一。拉丁化只有一套映射表，全站照着走就行

拉丁化的映射要定死并且写进文档：ą变a、ć变c、ę变e、ł变l、ń变n、ó变o、ś变s、ź和ż都变z。注意最后这一条会让两个不同的字母映射到同一个拉丁字母，极小概率下会撞车，遇到了手工加个后缀就行。

还有一条铁律：地址一旦发布就不要再改。波兰语的词形那么多，很容易让人产生换个形态更好的冲动，忍住。地址里的形态好不好，对排名的影响远小于改地址造成的信号损失。

## 站内搜索为什么在波兰语站上几乎不可用？

因为默认的搜索实现是按字符串匹配做的，而波兰语用户输入的形态和你库里存的形态几乎不可能对上。

开头那家工具站四成的空结果率，就是这么来的。用户搜复数、搜属格、搜不带变音的写法，库里存的是单数主格带变音的规范写法，三个维度全错开。

解决路径有三条，成本递增：

方案 | 做法 | 成本 | 能解决多少 | 

变音归一 | 查询和索引都去掉变音再比对 | 半天 | 约三成空结果 | 

同义词表 | 高频查询的各种形态手工映射 | 两三天 | 约七成 | 

词形还原 | 接入波兰语形态分析组件 | 一到两周 | 九成以上 | 

中小站从上往下做，做到第二层通常就够了。真正商品数上万、站内搜索承担主要导航职责的站，才值得上第三层。波兰语词干还原组件的文档 (https://lucene.apache.org/core/10_0_0/analysis/stempel/index.html)说明了它的工作方式和适用边界，选型时先读一遍能少走弯路。

顺带说一句，第一层那个变音归一，很多团队做完只用在搜索上，忘了筛选器。侧边栏的品牌筛选、属性筛选同样是字符串比对，同样会因为变音不一致而漏掉商品。改的时候顺手一起改，别分两次。

## 内链锚文本在变格里会变形，怎么办？

这是波兰语站特有的一个别扭处。你想给某个分类页做内链，锚文本自然要用那个分类的名字，但在一句通顺的波兰语里，那个名字必须跟着句子的语法变格。

于是你面临两难：要么锚文本用主格，句子读起来是病句；要么句子通顺，锚文本变成了另一个形态。

保哥的处理原则是句子通顺优先。理由有两条：一是搜索引擎对波兰语的词形关联已经处理得不错，变格形态的锚文本照样能传递语义；二是硬塞主格造出的病句，读者一眼就知道这是为搜索引擎写的，对信任是净损失。

但可以做一个折中：让链接周围的文字承担精确匹配的任务。锚文本用自然变格的形态，紧挨着的那句话里再把主格形态自然地提一次。这样既通顺又完整，成本只是多写半句。

还有一个常见错误值得单独提：把整句话做成锚。锚文本要落在具体的名词短语上，不要一整句都变成蓝色，那既不好看，也让锚指向的主题变得模糊。

## 标题该写哪一个格？

标题、面包屑、分类名一律用主格，这是波兰语网站的通行惯例，本地用户看着最自然。

正文里则完全放开，该怎么变就怎么变。刻意在正文里维持主格，会让整段文字散发出一种奇怪的机器味，本地人形容这种感觉是像在读说明书翻译。

唯一需要斟酌的是标题的后半段。如果标题里带介词短语，那么介词后面的名词必须跟着变格，这时候标题里就会同时出现主格和别的格。这没问题，读起来通顺就对了。

另外提醒一句关于长度：波兰语文案通常比英语长两成左右，加上变格后缀，词本身也更长。搜索结果里能显示的字符有限，把核心词放在标题最前面在波兰语里比在英语里更重要，因为后半截被切掉的概率高得多。

## 品牌名和型号，会不会也被变格？

会，而且这一点经常让品牌方措手不及。波兰语的变格系统对外来词并不客气，只要它在句子里当名词用，本地人就会给它加词尾。

连缩写词都逃不掉。一个全大写的缩写，在波兰语句子里照样会被加上小写的格尾巴，写出来是大写字母后面挂着几个小写字母，看着别扭但完全合乎规范。

对品牌方来说，处理原则是这样的：

- 官方场合用原形。标题、页脚、结构化信息、法律条款里一律写原形，不加词尾

- 正文允许自然变格。用户本来就这么说，硬拗只会显得生硬

- 型号一律不变。型号里带数字和字母的组合，加上词尾会切断跟国际数据源的匹配，损失远大于收益

- 站内搜索要认变格形态。用户搜品牌名的变格形式是常态，搜不到就是你的问题

还有个隐蔽的坑：品牌名如果碰巧跟某个波兰语单词的某个格形态撞车，会闹笑话。上线前让本地人念一遍所有品牌相关的组合词，这一步成本极低，能挡掉小概率但代价很高的事故。

## 界面上的复数，为什么不是两种而是三种？

这是波兰语让工程师最头疼的一条，也是最容易被漏掉的一条。

英语的复数只有两种形态：一个和多个。波兰语有三种，而且选哪一种要看数字的末位和末两位：

数量 | 用哪种形态 | 示例 | 

1 | 单数 | 1 produkt | 

2、3、4 | 少数形态 | 3 produkty | 

5到21 | 多数形态 | 7 produktów | 

22、23、24 | 回到少数形态 | 23 produkty | 

25到31 | 又回到多数形态 | 28 produktów | 

看懂了吗？末位是2、3、4的时候用少数形态，但末两位是12、13、14的时候例外，仍然用多数形态。这套规则不是玄学，它有明确的定义，只是照着英语写的模板一定处理不了。

会出事的位置很集中：搜索结果数、购物车商品数、库存提示、评价条数、筛选器上的计数、倒计时里的天数小时数。这些地方在英语站里都是拿数字拼个复数s就完事的，在波兰语站里会拼出一大堆语法错误。

解决办法不难，把复数规则交给专门处理这类问题的机制，别自己写判断。真正的难点在于你得先知道有这回事——绝大多数团队是等本地用户来投诉才发现的，而本地用户通常不投诉，他们只是觉得这站有点糙，然后走了。

## 数字、日期和价格该怎么写？

跟界面复数是同一类问题：写错了不影响功能，但会持续消耗信任。

- 小数用逗号，千位用空格或者点，一千二百三十四点五写成1 234,5

- 货币符号后置，写在数字后面并且带一个空格

- 日期是日在前，用点分隔，写成22.12.2010这种形式

- 月份名要变格，写成文字形式的日期时，月份用属格

- 星期和月份首字母小写，跟英语习惯相反

最后那条最容易露馅。英语习惯把月份和星期大写，照搬到波兰语页面上，本地人扫一眼就知道这是从英语站改过来的。

这类本地格式的账，每进一个市场都要重算一遍。葡萄牙语那边巴西和葡萄牙的格式差异 (https://zhangwenbao.com/portuguese-seo-brazil-portugal-two-markets-keyword.html)那篇里也讲了同一件事——甚至同一门语言的两个市场，货币符号该放前面还是后面都能不一样。把这几项做成模板层的配置项，比每次上线手工改省心得多。

## 表单和地址字段，为什么在波兰语站上老是提交失败？

结账页是转化路径的最后一米，也是波兰语站最容易无声流失的地方。原因不在技术难度，在于表单是照着别的语言设计的。

最典型的是姓氏。波兰的姓氏很多带性别形态，男性一种词尾，女性另一种词尾，同一个家族的两个人姓氏拼写不同。如果你的系统在某处做了姓氏比对或者去重，这两条会被判成不同的人——它们本来就是不同的写法，只是指向同一个家庭。

然后是地址结构。波兰地址的写法是街道名在前、门牌号在后，楼栋和单元用斜杠连接，邮编是两位数加连字符加三位数。照搬英语表单的字段顺序和校验规则，用户填不进去，或者填进去被判成格式错误。

字段 | 常见错误设计 | 正确做法 | 

姓氏 | 按固定形态做去重或比对 | 允许同族不同词尾，不做强去重 | 

街道 | 只留一个地址行，长度限制太短 | 街道与门牌分开，长度留足 | 

门牌 | 只接受纯数字 | 必须接受带斜杠与字母的组合 | 

邮编 | 按五位纯数字校验 | 两位加连字符加三位的格式 | 

字符集 | 只允许基础拉丁字母 | 必须放行九个变音字母 | 

最后一行是最狠的一条。如果表单的姓名字段做了只允许基础拉丁字母的校验，那么姓氏里带ł或者ą的用户根本无法完成下单，而他们不会给你发邮件解释，只会关掉页面。

还有一个容易漏的位置：发票信息。波兰的商业客户下单时需要填税号，这个字段在很多国际模板里根本不存在，缺了它，那部分订单直接流失。加一个字段的成本极低，收益却实打实。

## 波兰语的意图词，哪些必须收进词表？

品类词决定被谁看见，意图词决定看见你的人处在哪一步。波兰市场的意图词有几个自己的特点：

意图 | 常见修饰词 | 该配什么内容 | 

购买 | kup、sklep、cena、ceny | 产品页与分类页 | 

比价 | tanio、tani、promocja、najtaniej | 促销页与价格说明 | 

口碑 | opinie、recenzja、test | 评测与用户评价 | 

选购 | ranking、najlepszy、jaki wybrać | 选购指南与榜单 | 

用法 | jak、do czego、instrukcja | 教程与常见问题 | 

规格 | wymiary、parametry、zastosowanie | 参数表与对比页 | 

特别留意ranking这个词。波兰用户对榜单型内容的偏好明显高于西欧，同一个品类，带ranking的查询往往比带najlepszy的量还大。这是个便宜的切口：做一篇扎实的榜单，比硬拼产品词容易得多。

还有opinie。这个词的量大到几乎每个品类都有，而且意图非常明确——用户在决策临门一脚。如果你的商品页上没有真实评价，这部分流量接不住也留不下。

## 商品标题的自动模板，为什么在波兰语里必然拼错？

这一条是电商站的重灾区，而且几乎没有例外。

大多数站的商品标题、分类页标题、自动生成的描述，都是拿模板拼出来的，形如品牌加品类加属性。英语里这套完全没问题，因为形容词不变形。波兰语里，形容词必须跟名词的性、数、格三重一致，模板一拼就错。

拿颜色举例。红色这个形容词，配阴性名词是一种词尾，配阳性名词是另一种，配中性名词又是第三种。电钻是阴性，扳手是阳性，钻头是中性——同一个红色，在三个品类下要写成三种样子。

品类词的性 | 示例名词 | 红色该写成 | 模板硬拼的后果 | 

阴性 | wiertarka（电钻） | czerwona | 拼成阳性形式，本地人一眼看出 | 

阳性 | klucz（扳手） | czerwony | 拼成阴性形式，读起来像外国人写的 | 

中性 | wiertło（钻头） | czerwone | 三种里最容易被漏掉的一种 | 

更麻烦的是，如果标题里还带介词短语，那名词还要跟着变格，形容词又要跟着名词再变一次。两层变形叠加，模板输出的正确率基本可以忽略。

有三种解决路径，按现实程度排：

- 把属性值按性别存三套。属性字典里每个形容词存阴阳中三种形态，模板按品类词的性取对应的那一个。工作量集中在一次性录入，之后自动生成就是对的。

- 改写模板结构，绕开形容词。把红色电钻改成电钻，红色，用逗号把属性甩到后面当独立标签。这样形容词不需要跟名词一致，语法压力归零，代价是标题读起来略生硬。

- 高价值品类走人工。把带来主要流量的那几十个品类的标题全部人工写定，剩下的长尾走第二种方案。这是投入产出比最高的组合。

保哥的经验是第三种加第二种搭着用最实际。纯靠第一种的团队，通常在录入第三个属性维度的时候就放弃了——因为除了颜色，还有材质、规格、用途，每一个都要三套。

## 字母排序为什么让列表页看起来是乱的？

波兰语字母表有三十二个字母，那九个变音字母在字母表里是独立的字母，不是a加个符号。ą排在a后面，ć排在c后面，ł排在l后面，ż排在ź后面。

问题是数据库的默认排序规则通常不知道这件事。用通用的排序规则去排波兰语，可能出现两种结果：一种是把变音字母当成完全不同的字符，排到字母表最后去；另一种是把它们和基础字母视为等同，排在一起。

会受影响的位置比想象中多：品牌列表页的字母索引、分类页的商品排序、筛选器里的属性值列表、后台的搜索结果、导出的报表。这些地方排乱了不会报错，只会让本地人觉得这站有点糙。

处理原则是建库时就把排序规则定成支持波兰语的那一套，别指望上线后再改——排序规则一改，索引要重建，数据量大的时候是个不小的动作。

至于字母索引导航，实操上有个反直觉的建议：不给变音字母单独开格子。用户找一个以ą开头的词时，习惯是去a那一格找，你真给ą单开一格，反而会让人找不到。索引按基础字母分组，排序按波兰语规则来，这个组合最符合本地习惯。

## 波兰语的问句型查询长什么样？

问句型查询在波兰语里的比例不低，而且结构跟英语差别明显，值得单独整理一张表。

- jak：怎么做，对应教程与操作步骤类内容，量最大的一类

- czy：是不是，波兰语的是非问句几乎都用它起头，对应判断型内容

- ile：多少，对应价格、数量、规格类内容

- jaki与który：哪一个，对应选购对比类内容，注意这两个词自己也要跟着变格

- dlaczego：为什么，对应原理解释类内容

- co to jest：这是什么，对应术语解释

做常见问题模块的时候，把这几个词跟你的核心品类词交叉相乘，能一次性铺出几十条真实存在的长尾。注意问句里的名词同样要变格，直接拿主格拼出来的问句是病句。

还有一个小发现值得分享：czy开头的是非问句，在波兰语里的搜索量比英语市场里对应的问法高不少。这类查询的意图非常明确，用户就是在找一个确定的答案，内容里给一个干脆的判断句开头，比铺垫三段再回答有效得多。

## 母语审校该怎么验收？

波兰语的审校比西欧语言更需要明确边界，因为可改的地方太多，不设边界的话审校会顺手把你的关键词全改成他更喜欢的说法。

- 先给词表。核心品类词、品牌名、型号、不许动的术语列成一张表随稿交付

- 明确标题用主格。告诉审校标题和面包屑不必迁就句子语法，正文才需要

- 要求标注理由。硬性语法错误和个人偏好要分开标，你才能判断该不该接受

- 专项检查变音。让审校专门扫一遍变音字母有没有漏打或者打错，这类错误母语者最敏感

- 回搜验证。改动过的核心词丢回搜索框看看，确认改后的词确实有人用

第五条永远是最后一道闸。语言正确和市场正确是两码事，一个语法完美但没人搜的词，对搜索来说是负资产。

## 引擎那半边怎么办？

本文通篇在讲语言本身，没讲某个搜索引擎的排名机制，这是有意为之。

波兰的搜索格局相当集中，引擎层面要做的功课跟做英语站没有本质差别：能抓、能收、结构清楚、内容有价值。这些不因语种改变。

倒是有一件事值得单独提一句：波兰用户找商品时，除了搜索引擎，还有很大一部分直接从本地综合电商平台起步。那既是流量入口也是竞争对手，它在搜索结果里的排名往往压着独立站。这一层属于渠道策略，不是语言层的题目，得另外算账。

真正只有做波兰语才会遇到的，是本文讲的这些：七个格、九个变音字母、三种复数形态、编码残骸、锚文本变形。把语种换成英语就不成立的，才是这门语言独有的功课。

## 上线前的语言层检查清单

- 核心词是否按主格定稿，并覆盖了属格与宾格的高频形态

- 关键词表是否按词根做过合并，而不是把词形当成独立机会

- 标题、面包屑、分类名是否统一用主格

- 正文是否允许自然变格，没有被硬拗成主格

- 九个变音字母在标题、正文、地址、数据库里是否一致存活

- 拉丁化映射表是否写死并全站统一

- 站内搜索是否做了变音归一，筛选器是否一起改了

- 高频查询的词形是否收进了同义词表

- 界面上所有带数字的文案是否处理了三种复数形态

- 数字、日期、货币格式是否按本地习惯，月份星期是否小写

- 品牌名在正文里允许变格，在官方位置是否保持原形

- 端到端编码测试是否跑过一遍，包括物流面单和邮件通知

十二条里只有三四条需要工程介入，其余全是有人认真过一遍就能解决的事。经验里翻车的项目，缺的从来不是技术能力，是没人把这张表认领下来。

## 常见问题解答

## 波兰语关键词要不要把七个格全都做一遍？

不需要，做前三个就够了。七个格在搜索里的分布极不均匀，主格、属格、宾格加起来吃掉绝大部分查询量，方位格和工具格有一部分，与格和呼格在搜索里几乎不出现。具体操作上，标题和面包屑用主格，正文里让属格和宾格随句子自然出现，这样既覆盖了高频形态，读起来又通顺。千万不要把多个格的形态硬塞进同一个标题，那种标题本地人一眼就看出是给机器写的，点击率反而低。另外要提醒的是，形容词会跟着名词一起变，所以两词以上的短语实际组合数比你数的还多，做词表时按词根聚类再求和，比逐个形态排优先级现实得多。真正需要为某个非主格形态单独做页面的情况极少，通常只发生在那个形态本身已经固化成一个独立说法的时候。

## 用户不打变音字母，页面上要不要也去掉变音？

绝对不要。可见文本一律用规范写法，这是专业度的底线，去掉变音的波兰语在本地人眼里跟错别字连篇没有区别，信任成本远高于那点搜索收益。用户不打变音这件事，应该在别的层面消化：一是站内搜索，查询和索引都做一次变音归一再比对，这一步半天就能做完，通常能解决三成左右的空结果；二是筛选器，它同样是字符串比对，要跟搜索一起改，很多团队只改了搜索忘了筛选器；三是地址，路径部分走拉丁化，映射规则写死并全站统一。至于搜索引擎那一侧，它对波兰语变音的容错已经相当成熟，你不需要为它专门做无变音版本的页面，那样只会造出一堆内容雷同、互相稀释的页面。

## 站内搜索空结果率高，最快能怎么降下来？

按投入产出比排，第一步做变音归一，把查询和索引都去掉变音再比对，半天工作量，通常能砍掉三成左右的空结果。第二步做同义词表，统计站内搜索日志里最高频的两三百个查询，把它们的单复数、主格属格宾格形态、以及带不带变音的写法全部映射到同一个目标，两三天工作量，累计能解决七成左右。第三步才是接入波兰语的形态分析组件做真正的词形还原，一到两周工作量，能解决九成以上，但只有商品数上万、站内搜索承担主要导航职责的站才值得投。绝大多数中小站做到第二步就够用了。还有一个容易被忽略的细节：改完搜索一定要顺手改筛选器，两者用的是同一套字符串比对逻辑，只改一半的话，用户在筛选时照样会遇到明明有货却筛不出来的情况。

## 波兰语的内链锚文本必须用主格吗？

不必须，而且强行用主格通常是错的。在波兰语的句子里，名词必须跟着语法环境变格，硬塞主格会造出病句，读者一眼就知道这是为搜索引擎写的，对信任是净损失。搜索引擎对波兰语的词形关联已经处理得不错，变格形态的锚文本照样能传递语义。推荐的折中做法是让锚文本用自然变格的形态，同时在紧挨着的那句话里把主格形态自然地提一次，这样既通顺又完整，成本只是多写半句话。另外还有两个常见错误值得避开：一是把整句话都做成锚，锚应该落在具体的名词短语上，一整句变蓝既不好看也让主题变模糊；二是同一个目标页在全站的锚文本形态完全一致，那种机械的重复本身就不自然，让它随上下文变化反而更好。

## 界面文案里的复数，波兰语为什么要处理三种形态？

因为波兰语的数词搭配规则跟英语完全不同。数量为1时用一种形态，末位是2、3、4时用第二种形态，其余情况用第三种形态，而且末两位是12、13、14时是例外，要回到第三种。这套规则有明确定义，不是玄学，但照着英语写的模板绝对处理不了，因为英语只需要区分一个和多个。会出问题的位置很集中：搜索结果数、购物车商品数、库存提示、评价条数、筛选器上的计数、倒计时里的天数和小时数，这些地方在英语站里都是拿数字拼一个复数词尾就完事。正确做法是把复数选择交给专门处理这类规则的机制，不要自己写判断分支。真正的难点在于意识到有这回事，很多团队是上线很久之后才发现，而本地用户通常不会专门来投诉，他们只是觉得这个站有点糙然后离开。

## 波兰语的地址该用本地字母还是拉丁化？

技术上两条路都能走，域名层面带波兰字母的地址早就可以注册，路径部分带变音字符也能正常工作。但更推荐路径做拉丁化，理由有四条：一是可复制可口述，带百分号编码的地址复制出来是一长串乱码，发在聊天里或印在包装上都不体面；二是外部链接更稳，编码形态在中间环节容易被改写，导致链接失效或分裂成多条；三是日志可读，满屏的百分号编码会让分析工作变得很痛苦；四是规则容易统一，拉丁化只有一张映射表，全站照着走就行。映射规则要写进文档并且写死，注意ź和ż都会映射到同一个拉丁字母，极小概率会撞车，遇到手工加后缀即可。最后强调一条铁律：地址一旦发布就不要再改，波兰语词形多容易让人产生换个形态的冲动，但改地址造成的信号损失远大于形态优化的收益。

## 商品标题用模板自动生成，在波兰语里能不能救？

能救，但不能靠纯模板。问题的根源是波兰语的形容词必须跟名词的性、数、格三重一致，而模板拼接不知道品类词是阴性阳性还是中性，拼出来的组合有很大概率语法错误。三条可行路径：第一条是把属性字典里的每个形容词按三种性别各存一套形态，模板按品类词的性取对应的那个，正确率最高但录入工作量随属性维度线性增长；第二条是改写模板结构绕开一致问题，把红色电钻改成电钻加逗号加红色，让属性作为独立标签出现，语法压力归零，代价是标题略生硬；第三条是把带来主要流量的几十个品类的标题全部人工写定，长尾部分走第二条。实际项目里第三条加第二条的组合最现实，纯靠第一条的团队通常在录入第三个属性维度时就放弃了，因为除了颜色还有材质、规格、用途，每一个都要三套。

## 波兰市场值得先做还是放在西欧之后？

看你的品类和资源结构。波兰的吸引力在于人口规模在中欧最大、消费能力持续上行、而竞争密度明显低于德国法国这类成熟市场，同样的内容投入能换到更靠前的位置。它的门槛在于语言本身的工作量，也就是本文讲的这些：变格、变音、复数规则、编码遗留，这些是一次性投入但绕不过去。经验上有个判断方法：如果你的品类在德国已经跑通、内容资产可以复用骨架，那么波兰是性价比很高的下一站，因为省掉的是选题和结构，付出的只是语言层适配；如果你还在摸索品类和内容形态，那波兰不是好的试验田，因为语言成本会掩盖掉你对品类判断的反馈。另外提醒一句，波兰用户找商品时有很大一部分直接从本地综合电商平台起步，那既是入口也是对手，做市场评估时要把这部分算进去。

## 权威参考资料



## 阿拉伯语SEO最容易翻车的六个地方，全出在从右往左

- URL：https://zhangwenbao.com/arabic-seo-rtl-layout-msa-dialect-keyword.html
- 分类：小语种SEO
- 发布：2010-12-08  |  更新：2026-07-25
- 摘要：讲阿拉伯语SEO实战：双向文本导致的标题错位、成对符号镜像、版式与表单适配、字体连写与子集化、标准语与埃及海湾黎凡特方言的取舍、词根与不规则复数的归并、定冠词前缀对匹配的影响，以及正品和货到付款这类高转化意图词。
- 关键词：关键词研究,内容本地化,小语种SEO

> **TLDR**：摘要：做阿拉伯语市场，最先把人绊倒的不是选词，是方向。文字从右往左走，页面却是照着从左往右的模板搭的，于是数字跑错位置、括号方向反了、标题在结果页里被从错误的一端切断、表单里的占位符贴在错误的一侧。这六类问题单独看都是小事，凑在一起就足以让一个内容完全正确的站显得像半成品。方向问题理顺之后，才轮到语言本身的功课：标准阿拉伯语和各地方言该做哪一套、同一个字母的几种写法会把词表拆成几份、用拉丁字母加数字拼出来的那套写法要不要覆盖。下面逐条拆。

> 摘要：做阿拉伯语市场，最先把人绊倒的不是选词，是方向。文字从右往左走，页面却是照着从左往右的模板搭的，于是数字跑错位置、括号方向反了、标题在结果页里被从错误的一端切断、表单里的占位符贴在错误的一侧。这六类问题单独看都是小事，凑在一起就足以让一个内容完全正确的站显得像半成品。方向问题理顺之后，才轮到语言本身的功课：标准阿拉伯语和各地方言该做哪一套、同一个字母的几种写法会把词表拆成几份、用拉丁字母加数字拼出来的那套写法要不要覆盖。下面逐条拆。

先说一个开局。一家做手机配件的独立站要进海湾市场，团队很认真，找了母语译者，内容质量没问题。上线之后排名慢慢起来了，可转化率低得离谱，比同一批上线的其他语言版本低了一大截。

问题最后是在一张截图里找到的。产品页上写着容量和型号的那一行，数字和拉丁字母在阿拉伯语句子中间的排列顺序乱了，本该写成某个数值加单位的地方，显示出来是单位在前、数字被甩到句子另一端。语法没错，翻译没错，但那一行读起来是一句谁也看不懂的话。

更麻烦的是这类问题不会报错。页面能打开，抓取正常，收录也正常，只有真正读阿拉伯语的人打开页面时，会在心里说一句这站有点怪，然后关掉。从右往左的世界里，最贵的错误都是不报错的那种。

## 从右往左，到底改变了哪几件事？

很多人以为把页面方向翻过来就完事了，实际上要处理的东西分散在六个层面，而且它们分属不同的团队负责，很容易谁都以为是别人的活。

层面 | 典型症状 | 谁最容易漏 | 

混合文本方向 | 数字、型号、英文品牌名在句中位置错乱 | 翻译和前端互相以为对方处理了 | 

标点与成对符号 | 括号、引号方向反了，问号形状不对 | 内容录入环节 | 

版式镜像 | 导航、面包屑、箭头、进度条方向没翻 | 视觉稿只出了一套 | 

表单与交互 | 输入框对齐、占位符位置、校验提示位置 | 表单是通用组件，没做方向适配 | 

字体与连写 | 缺字形、连写断开、行高被撑爆 | 字体子集按拉丁字符集裁的 | 

截断与省略 | 标题在错误的一端被切断 | 没人用阿拉伯语测过截断 | 

这张表就是标题里说的六个地方。下面挑影响最大的几个展开。

## 混合文本方向：最贵也最隐蔽的一个

阿拉伯语文本从右往左排，但里面夹的数字和拉丁字母仍然从左往右。一段话里两个方向并存，浏览器要靠一套算法决定每一小段的走向和拼接顺序，这套算法就是双向算法，规则写在Unicode的双向算法标准附件 (https://www.unicode.org/reports/tr9/)里。

算法本身很可靠，出问题的往往是我们喂给它的东西。最常见的两种情况：一是段落的基准方向没声明，浏览器只能靠猜；二是内容里混了不可见的方向控制字符，来源可能是复制粘贴，也可能是某个编辑器自动插进去的。

基准方向该怎么声明，属于最基础的一步，W3C关于文本方向标注的问答 (https://www.w3.org/International/questions/qa-html-dir)把该标在哪一层、内嵌的相反方向片段该怎么处理讲得很细。样式层的对应属性在开发者文档里的方向属性说明 (https://developer.mozilla.org/en-US/docs/Web/CSS/direction)也有完整用法。

## 为什么标题最容易出事？

因为标题恰恰是混合文本密度最高的地方。一个典型的阿拉伯语产品标题里，往往同时有阿拉伯语的品类词、拉丁字母的品牌名、阿拉伯数字的型号或容量，三种成分挤在几十个字符里。

更糟的是标题会被截断。搜索结果里的标题按显示宽度截断，截断发生在哪一端、截掉之后剩下的片段方向会不会重排，这些行为在混合文本上比纯文本复杂得多。实测里经常出现的情况是：截断之后剩下的那截读起来意思变了，或者品牌名被劈成两半分别挂在两端。

务实的应对有三条：把最重要的阿拉伯语词放在最前面，也就是最右边；品牌名和型号尽量集中放在一处，别在标题中间来回穿插；上线前用真实的阿拉伯语标题在窄屏上看一遍截断效果，别只在设计稿里看。

## 成对符号的方向问题

括号、方括号、大于小于号这类成对符号，在从右往左的上下文里显示时会自动镜像，视觉上的开口方向跟你在代码里写的相反。这是正确行为不是错误，但它经常吓到第一次做阿拉伯语站的人，于是有人手动改字符去凑视觉效果，结果把真正的逻辑顺序搞坏了。

记住一条原则就够了：存的是逻辑顺序，显示交给渲染层，永远不要手动调整字符顺序去凑视觉。手动凑出来的字符串在换一个环境显示时必然崩掉，而且这种坏法极难排查。

## 标准阿拉伯语和方言，关键词该做哪一套？

这是阿拉伯语市场最核心的语言层决策，比方向问题更影响天花板。

阿拉伯语世界存在一个很特别的格局：书面语高度统一，口语差异极大。正式的书面语在从摩洛哥到海湾的整个区域通用，新闻、教育、政府文书、商业合同都用它；而各地的日常口语差异大到不同地区的人用方言交流时会有困难。

## 那用户搜索时用哪一种？

答案是两种都用，但分布很有规律。信息型和正式的查询偏向书面语，因为用户在打字时会自然切换到书面模式；生活化、口语化、带情绪的查询更容易出现方言词，尤其是移动端和年轻用户。

商业查询处在中间地带，而且分品类。标准化程度高的品类，比如数码产品、家电、汽车配件，品类词基本用书面语；贴近日常生活的品类，比如食品、服装、家居杂物，方言词的比例明显更高。

省事的判断是：越接近产品参数的词越统一，越接近生活场景的词越分叉。这条规律和其他多语种市场是相通的，差别只在阿拉伯语的分叉幅度更大。

## 主要方言区该怎么切？

做市场规划时不需要按国家一个个来，按方言区分成几大块就够用了：埃及及周边、海湾地区、黎凡特地区、马格里布地区。埃及人口最多、内容产出量最大，它的方言在整个阿拉伯语世界的辨识度最高；海湾地区购买力最强，是跨境电商最看重的一块；黎凡特地区的方言在媒体内容里出现频率高；马格里布地区受法语影响深，语言环境最特殊。

务实的路径是：内容主体用书面语写，保证全区可读；在标题和正文里自然覆盖目标市场最常用的那几个方言词；如果只做一个市场，就把那个市场的口语词表单独做一份。

## 同一个字母的几种写法，会把词表拆散吗？

会，而且拆得比大多数人预想的严重。阿拉伯语有几组字符在实际书写中经常被混用，它们在字符层面是不同的码位，但在用户心里是同一个字。

字符组 | 混用情况 | 对选词的影响 | 

带各种符号的元音起始字母 | 用户经常省略上下的符号只打基础形式 | 同一个词出现两三种拼写 | 

词尾的两种他形字母 | 阴性词尾经常被写成另一种形式 | 阴性名词几乎必然分裂成两条 | 

词尾的长元音与半元音 | 两个字形相近，输入时经常互换 | 动词和部分名词受影响 | 

元音符号 | 正式文本才标，日常几乎不标 | 带符号的写法搜索量极低 | 

处理原则分两头。做需求统计时，把这些变体归并成同一个词根再看总量，否则你会低估这个词的真实体量，甚至误判成没需求。做页面时反过来，只用最规范、最主流的那种写法，别为每种变体开页面，那是老式的堆词打法，只会制造内耗。

## 元音符号要不要标？

正文一律不标。那套标注元音的符号只出现在宗教文本、儿童读物、诗歌和需要消除歧义的专业场合，日常内容里出现它们会显得很奇怪。更重要的是，用户搜索时几乎从不输入这些符号，你标了反而增加匹配的不确定性。

唯一值得标的场景是一个词不标就会产生实质歧义、而这个歧义会影响理解的时候，这种情况在商业内容里非常少见。

## 这套归并逻辑跟别的语言比怎么样？

本质上和屈折语的词形归并是一回事，只是触发点不同：屈折语是语法变化制造变体，阿拉伯语这几组是书写习惯制造变体。保哥在俄语词形变化与搜索量口径那篇 (https://zhangwenbao.com/russian-seo-cyrillic-cases-declension-wordstat-keyword.html)里讲过词形合并的处理方法，思路可以直接搬过来，只是要把归并规则换成字符层面的等价映射。

## 词根和破碎复数，会把词表拆成什么样？

这是阿拉伯语最独特、也最容易让人低估工作量的一层。前面讲的字母变体只是书写习惯造成的分裂，词根系统造成的分裂要深得多。

阿拉伯语的绝大部分词汇建立在一个由几个辅音构成的词根之上，同一个词根按不同的模板填入元音，就派生出一整族相关的词：动作本身、做这件事的人、做这件事的地方、做这件事用的工具、被做过的东西。这些词在语义上高度相关，在字符层面却各不相同。

对选词的影响是双向的。好的一面是，你可以从一个核心词根出发，系统性地推导出一整族相关词，这比在英语里靠联想扩词高效得多。坏的一面是，工具很难把这一族词识别成同一个主题，它们在报表里是彼此无关的几十条记录。

## 复数的问题更麻烦

阿拉伯语的复数分两种。一种是规则复数，在词尾加固定的后缀，这类好处理，跟大多数语言一样。另一种是不规则复数，构成方式不是加后缀，而是把词内部的元音结构整个换掉，单复数两个形式在字符层面可能只剩一两个字母相同。

后果是：常规的词干处理办法在这类复数上基本失效，单数和复数会被当成两个毫不相干的词。而在真实搜索里，用户搜品类词时用复数的比例相当高，这两条记录的量必须合并看才有意义。

处理办法有两条。做词表时，把已知的单复数对手工建成映射关系，核心品类词的数量通常不超过几十个，一次投入就能长期复用。做页面时，标题用搜索量更高的那个形态，正文里自然覆盖另一个，别为两个形态分别开页面。

## 这套结构还有一个隐藏好处

词根系统让阿拉伯语的语义相关性非常密集。围绕一个词根构建的内容集群，在主题一致性上天然就比拼凑出来的关键词组强。做内容规划时，与其按关键词一条条排，不如按词根族划分主题簇，一个族做一组页面，彼此互链。这个做法在别的语言里要靠人为归类，在阿拉伯语里语言本身就把归类做好了。

## 定冠词那两个字母，会不会影响关键词匹配？

会，而且它出现的频率高到几乎每个名词都会遇到。

阿拉伯语表示特指时，要在名词前面加一个由两个字母组成的定冠词前缀，它和名词连写成一个词，不加空格。这意味着同一个名词有带前缀和不带前缀两种形态，而它们在字符层面是两个不同的字符串。

用户在搜索时两种都会打。搜一个泛泛的品类时倾向不带前缀，搜某个具体确定的东西时更可能带上。所以你的词表里，同一个品类词几乎必然会出现两条记录，量要合并看。

## 还有一个发音同化带来的小麻烦

这个前缀在遇到某一批辅音开头的词时会发生发音上的同化，写法不变但读法变了。这本身不影响搜索，但它会影响另一件事：语音输入和语音搜索的转写结果，以及用拉丁字母转写品牌名时的拼法选择。做品牌名转写方案时，这一层要让母语者过一遍，别按字母表机械对应。

## 实操上怎么处理？

页面标题按最自然的语法写，该带前缀就带，别为了塞关键词写出不带前缀的病句。正文里两种形态自然都会出现，不需要刻意安排。真正需要注意的是自动生成的内容，比如从数据库拼接的分类页标题，模板如果不管前缀直接拼，出来的往往是不合语法的短语，成规模出现时对内容质量的观感伤害不小。

## 阿拉伯语市场的搜索行为，有什么不一样？

语言之外，用户行为上也有几个差异值得单独说，它们直接影响内容该怎么排。

第一是移动端占比。这几个市场的移动端使用比例明显高于欧美，很多用户的第一次上网体验就是在手机上完成的，桌面端反而是补充。这意味着你的内容排版、图片体积、表单长度都要按移动优先来设计，而不是把桌面版缩一缩。

第二是视频和图像的权重。阿拉伯语世界的用户对视觉内容的接受度很高，同一个问题，用户更愿意看一段演示而不是读一段说明。做内容规划时，把关键的操作说明配上图示，效果通常好过再写五百字。

第三是社交推荐的分量。熟人推荐和社群讨论对购买决策的影响比欧美市场更重，这意味着可分享性很重要：页面在社交平台上被分享时的呈现效果、能不能被方便地转发给个人，这些细节值得专门优化。

## 周末和作息也不一样

几个主要市场的休息日安排和欧美不同，全年最重要的消费节点也跟西方节日体系不重合。做内容日历和促销节奏时照搬欧美的时间表，会系统性地错开需求高峰。

还有一个更细的点：一天中的活跃时段分布也不一样，尤其是在特定的宗教节期里，作息会有明显变化。这不影响SEO本身，但影响你什么时候发内容、什么时候做推广、客服该排在哪几个小时。把内容做对只是一半，在对的时间出现是另一半。

## 用拉丁字母加数字拼的阿拉伯语，要不要覆盖？

这套写法在阿拉伯语世界相当普遍，起源是早期设备和输入法不支持阿拉伯字母，人们只好用拉丁字母凑，遇上阿拉伯语特有、拉丁字母表示不了的音，就用形状相似的数字代替。

它至今活跃在聊天、社交、短消息里，年轻人尤其习惯。问题是它没有统一的转写规范，同一个词能拼出好几种写法，做SEO覆盖的性价比因此非常低。

## 那到底做不做？

分场景。品牌名值得做，因为品牌名的转写形式是用户最可能打出来的东西，而且相对固定；把最主流的一两种拼法在页面上自然出现一次，成本很低。品类词和长尾词不建议做，写法太发散，覆盖不完，还会让页面显得不正式。

另一个值得注意的是：这套写法在搜索里的占比正在下降，因为设备和输入法早就完整支持阿拉伯字母了，用它更多是习惯而非必需。为一个正在萎缩的写法建整套页面，是把预算押在过去。

## 阿拉伯语里的英语借词，该用哪一个？

阿拉伯语对外来词的处理有个特点：官方语言机构通常会造一个纯阿拉伯语的说法出来，但民间该借还是借，两套说法长期并存。做选词时，你要判断的不是哪个更正确，而是哪个是活的。

典型场景是科技类产品。同一个东西，往往同时存在一个由阿拉伯语词根构成的规范词和一个直接从英语音译过来的词，前者出现在正式文本和教科书里，后者出现在日常对话和商品页面上。

规律大致是这样：越贴近日常使用的物件，音译词越占上风；越正式、越书面的场合，规范词越占上风。而搜索行为大多发生在日常语境里，所以商业查询里音译词的比例往往高于你从词典上得到的印象。

## 那正文该写哪个？

建议做法是标题用搜索量高的那个，正文里两个都自然出现一次。这样既接住了搜索，也照顾了正式感，还顺手覆盖了另一种查询写法。

要避免的是两种极端。一种是通篇音译词，读起来像随手翻译的，专业感不足；另一种是通篇规范词，对着一群从来不这么说的用户说话，搜索量直接减半。

## 不同市场的接受度也不一样

海湾地区因为国际化程度高、英语普及率高，日常语言里夹英语词的接受度明显更高；一些人口大国的语言环境更本土，规范词的使用比例更高；受法语影响深的地区还会出现从法语借来的词，跟英语借词竞争同一个位置。这意味着借词的取舍也是个市场变量，不是语言层的固定答案。

## 站内搜索为什么在阿拉伯语站上总是搜不到？

这是个常见但很少被归因到语言层的问题。用户在你站内搜一个明明存在的商品，结果返回空白，然后离开。

原因通常是前面讲的几件事叠在一起：字母变体没有做等价映射，用户打的是一种写法而商品名用的是另一种；定冠词前缀没有剥离，带前缀的输入匹配不上不带前缀的商品名；不规则复数没有映射，用户搜复数而商品名是单数；再加上元音符号、多余空格、方向控制字符这些干扰。

## 怎么改？

在检索的输入端和索引端各做一次同样的归一化处理：统一字母变体、去掉元音符号、剥离定冠词前缀、清理不可见字符、把两套数字符号做等价映射。规则不复杂，难点在于两端必须用完全相同的一套规则，否则会出现更诡异的结果。

不规则复数那部分没法靠规则解决，只能维护一份映射表，好在核心品类词的数量有限。站内搜索的空结果率，是衡量阿拉伯语站语言处理质量最快的一个指标，它比排名数据更早暴露问题，也更容易定位。

## 阿拉伯语的搜索意图词，哪些是必须覆盖的？

品类词只是一半，前后挂的修饰词才是意图的载体。阿拉伯语的意图词有几个跟英语不对称的地方。

意图 | 说明 | 该落到什么页面 | 

购买 | 购买类动词，常与在线一词连用 | 品类页或产品页 | 

价格 | 价格词的搜索占比高于欧美市场 | 产品页带价格模块 | 

最好的 | 最高级修饰词，长期高频 | 榜单或对比页 | 

怎么做 | 教程型问句结构固定 | 内容页 | 

正品 | 对真伪的关注度显著高于欧美 | 品牌与保障说明页 | 

包邮到货 | 配送与到货时效是强转化词 | 物流政策页 | 

分期 | 分期与货到付款在部分市场是主流 | 支付说明页 | 

最值得单独说的是正品这一类词。中东市场的消费者对商品真伪的敏感度明显高于欧美，相关查询的量很大，而大多数出海站压根没做这类页面。这是一个门槛低、竞争小、转化直接的切口。

另一个是货到付款。这种支付方式在部分阿拉伯语市场的渗透率相当高，页面上写不写、写在哪一屏，对转化的影响远超一个排名位次。搜这类词的人不是在了解产品，是在确认能不能安心下单。

## 数字该用哪一套写法？

阿拉伯语世界同时存在两套数字符号：我们平常用的这套所谓阿拉伯数字，以及在部分地区仍在使用的另一套阿拉伯语原生数字符号。

实用建议是：正文、价格、参数一律用常见的那套数字，它在全区域通用且不会有识别问题；另一套只在特定场景下考虑，比如面向传统受众的内容或者需要文化质感的场合。

要注意的是两套数字在搜索层面通常不互通，用户搜的是哪一套，你页面上就要有哪一套。绝大多数商业查询用的是常见那套，所以这不构成实际问题，但做站内搜索时最好把两套做等价映射，成本很低。

## 还有一个日期和货币的坑

部分阿拉伯语市场同时使用两套历法，日期换算不做好，促销活动的时间说明就会自相矛盾。货币方面，海湾各国各有各的货币，符号写法和小数位数不完全一致，价格模块用一套模板套所有市场很容易出错。

## 阿拉伯语的字体，为什么会拖垮首屏？

这是个被严重低估的技术问题。阿拉伯语是连写文字，同一个字母在词首、词中、词尾、独立四种位置有不同的字形，还有大量连字组合。这意味着一套完整的阿拉伯语字体，字形数量远超拉丁字体。

后果有两个。一是字体文件大，对网络条件一般的用户来说是实打实的首屏成本。二是子集化很难做，拉丁字体可以按字符集裁得很干净，阿拉伯语字体一旦裁错就会出现字形缺失或者连写断开，读起来支离破碎。

## 该怎么处理？

第一，认真评估系统字体。多数目标设备都自带质量不错的阿拉伯语字体，直接用系统字体能省掉一整个网络请求，视觉损失往往比想象中小。

第二，如果一定要用网页字体，字重要少，能用两个绝不用四个。阿拉伯语字体的每一个字重都是完整的一套字形，多一个字重的代价远高于拉丁字体。

第三，字体加载策略要保证文字先可见。字体没到位就让文本一直不显示，在阿拉伯语站上的代价比拉丁语站更大，因为文件更大、加载更慢。这一层的通用做法在网页字体加载优化那篇 (https://zhangwenbao.com/web-font-loading-font-display-foit-fout-optimization.html)里有完整拆解，阿拉伯语只是把里面每一个权衡都放大了。

顺带说一句，中东和北非市场的网络与设备条件跨度很大，同一份页面在不同国家的实际打开体验可能差好几倍。性能这件事在这里不是加分项，是准入条件，相关的排查思路在海外弱网与低端机的性能优化 (https://zhangwenbao.com/overseas-weak-network-low-end-phone-mobile-performance-optimization.html)那篇里讲得更细。

## 阿拉伯语域名值不值得做？

用阿拉伯字母书写的顶级域名已经可以使用了，几个主要市场都有了自己的本地字符后缀。技术上它靠一套编码机制把非拉丁字符转成可传输的形式，抓取和收录都不成问题。

但要不要用是另一回事。几个现实因素：一是复制粘贴和跨平台分享时容易出问题；二是外链建设时，很多站点和平台对非拉丁域名的处理仍然不够成熟；三是品牌一致性，同时维护两套域名意味着两套认知。

比较稳妥的做法是：主域名用拉丁字符，本地字符域名注册下来做防御和跳转，别把主要业务押在上面。如果你的业务高度本地化、目标用户几乎不跨境分享链接，那本地字符域名的亲和力优势才真正能兑现。

## URL路径里要不要用阿拉伯字母？

建议做拉丁转写。技术上放阿拉伯字母是可行的，但地址复制出来是一长串编码，粘到别处容易被截断，后台日志和分析报表里的可读性也很差。正文该怎么写还怎么写，路径停在最安全的字符范围内，是成本最低的组合。已经上线并且收录正常的站，别为这个专门做迁移。

## 引擎那半边该怎么办？

阿拉伯语市场的搜索格局相对简单，主流搜索引擎的占有率很高，没有像俄语市场或者韩语市场那样的强势本土引擎。本地化的门户和内容平台在流量上有分量，但它们更多是内容分发渠道而不是独立的排名生态。

所以做阿拉伯语市场时，引擎层的功课主要还是通用打法，真正的差异化全在语言层，也就是本文讲的这些东西。这一点跟做俄语或者日语市场很不一样，那两个市场必须额外学一套引擎规则。

## 本地内容平台值不值得投入？

值得，但目标要摆正。中东北非地区的社交和内容平台活跃度很高，用户在上面讨论产品、求推荐、晒开箱的密度不低。这些内容的价值主要在两处：一是真实的用词样本，用户在帖子里怎么称呼一个品类，那就是你该用的词；二是需求信号，抱怨帖和求推荐帖里藏着大量还没被内容覆盖的长尾问题。

## 阿拉伯语页面的信任信号，跟英语站差在哪？

语言和方向都做对了，只是及格线。这个市场对信任信号的敏感度比欧美高，有几条是必须的。

第一是商品真伪的说明。前面提过搜索层面的正品类词，页面层面同样要接住：授权来源、保修条款、退换政策要写得具体，别只放一句保证正品。

第二是支付与配送的确定性。货到付款是否支持、配送到具体国家要几天、关税谁承担，这三条写清楚比任何促销文案都管用。含糊其辞在这个市场的代价特别大。

第三是联系方式的本地形态。本地号码、本地时区的服务时段、用阿拉伯语提供客服的明确承诺。一个全阿拉伯语的站在客服环节突然冒出英文表单，前面建立的信任会立刻打折。

## 称谓和口气怎么定？

阿拉伯语的商业内容整体偏正式，比英语电商文案端庄一些，直接照搬英文那种随意亲切的口吻会显得轻浮。同时要注意人称的性别形式，阿拉伯语的动词和代词都要区分对方的性别，面向不特定用户时用哪种形式、要不要同时给出两种，最好在内容规范里统一定下来，别让每个译者自己发挥。

## 上线前该检查哪些语言层的东西？

把前面的判断收成一张能执行的清单。

先查方向：页面基准方向声明了没有、内嵌的拉丁片段方向对不对、成对符号显示是否正常、导航和图标是否做了镜像、表单对齐和占位符位置是否正确。

再查字符：内容里有没有混进不可见的方向控制字符、字母变体在关键字段里是否统一、元音符号有没有被误标进正文。

接着查字体：字体子集是否包含全部所需字形、连写是否完整、行高是否被撑爆、字重数量是否精简。阿拉伯语的字符比拉丁字符高，行高照抄英文版会挤，这一条在移动端最明显。

最后查截断：标题、描述、按钮文案、商品名在窄屏下的截断效果，用真实的阿拉伯语内容测，别用占位文本。做完这一轮，再找一个母语者读一遍首页和三个主要落地页，只问一句读起来像不像本地公司做的站。

## 怎么给译者和审校提要求？

提四条就够。第一，明确目标市场和用书面语还是掺方言词，别笼统说翻译成阿拉伯语。第二，明确称谓与性别形式的统一口径。第三，给出必须命中的核心词表，并注明这些词要出现但不要求原样形态。第四，明确哪些内容原样保留不翻译，主要是品牌名、型号和技术代号。

验收时不懂阿拉伯语也能查几项：数字和拉丁字母在句子里的位置是否合理、括号方向是否正常、页面上有没有中英文混排式的多余空格、标题在窄屏下会不会被切成怪样子。这几项能拦掉大部分低质量交付。跨语种的通用验收思路在法语市场的重音与地区变体那篇 (https://zhangwenbao.com/french-seo-accents-quebec-keyword-variants.html)里也整理过一份，两边可以对照着用。

## 常见问题解答

## 阿拉伯语站到底该做书面语还是方言？

主体用书面语，局部掺目标市场的方言词，这是绝大多数商业站的最优解。理由有三个：一是书面语在整个阿拉伯语区通用，一份内容能覆盖多个市场，成本效率最高；二是正式的书面语在商业场合天然带一层专业感，全篇口语化的商业内容在读者眼里会显得不够可靠；三是搜索行为里信息型和商业型查询大量使用书面语，尤其是打字输入的场景。方言词的用武之地主要在两处：一是标题和小标题里的少量点缀，让内容读起来不像官方公告；二是那些方言表达明显比书面语更常用的生活类品类词，这类词必须收进词表，不然就是漏掉了真实需求。如果你只做单一市场，比如只做埃及或者只做海湾某一国，那可以把方言词的比例提高一些。判断方法很简单：把两种说法分别丢进目标市场的搜索框，看下拉建议里出现哪一个、结果页返回的是不是真实的本地内容。

## 页面镜像是不是把所有元素都翻过来就行？

不是，有几类元素不能翻。第一类是有固定物理含义的图标，比如播放按钮、时钟指针方向、以及表示前进后退的媒体控制，这些在从右往左的界面里通常保持原样，翻过来反而让人困惑。第二类是数字本身和数字组成的序列，比如电话号码、型号、版本号、时间显示，它们的内部顺序永远是从左往右。第三类是图表和数据可视化，坐标轴方向要不要翻取决于数据本身的语义，时间轴通常跟着阅读方向翻，但涉及国际通用惯例的图表往往保持原样。第四类是品牌标识，除非品牌方专门做了适配版本，否则不要自行镜像。实操上比较稳的做法是列一张不翻清单，写进设计规范里，让视觉和前端都照着执行。最容易出事的其实不是翻不翻的问题，而是同一个站里有的翻了有的没翻，用户会觉得这个界面精神不集中。

## 阿拉伯语内容的长度和排版要注意什么？

有三条实用经验。第一是行高，阿拉伯字母有大量高出基线和低于基线的部分，还有点状符号，按拉丁文字的行高排会显得拥挤甚至字形相撞，通常需要在拉丁版本的基础上把行高调大一档。第二是字号，同样的字号下阿拉伯字母的可读性略低于拉丁字母，尤其是区分靠点数的那几组字母，正文字号建议比英文版稍大。第三是文本长度，阿拉伯语译文相对英文原文的长度变化不像德语那样稳定膨胀，有时更短有时更长，取决于文体，所以不能用一个固定系数去估算版式空间，必须用真实内容排一遍。另外提醒一点，两端对齐在阿拉伯语里的效果和拉丁文字不同，因为阿拉伯语靠拉伸连接笔画而不是拉伸词间距来对齐，处理不当会出现很难看的拉伸。做正文时用普通对齐通常更安全。

## 关键词工具查不到阿拉伯语的细分数据怎么办？

换数据源，别硬等工具。第一个来源是搜索建议，把种子词打进目标市场的搜索框，下拉给出的延伸词本身就是真实查询的采样，而且免费、实时、按地区。第二个来源是当地电商平台的类目结构和站内搜索建议，这些类目名是被大量真实搜索验证过的说法，比翻译准确得多。第三个来源是本地社交和论坛里用户的原话，尤其是求推荐和抱怨类内容，里面的表述最接近真实搜索语言，也最容易发现方言词。第四个来源是你自己站内搜索的日志，只要有一点自然流量，用户在你站内搜什么就是最直接的答案。这四类都拿不到绝对搜索量，但它们能回答更重要的问题：这个词是不是活的。有了这个判断，再用相邻大市场的量做粗略比例推算，足够支撑优先级排序。做阿拉伯语还有一个额外好处：字母变体归并之后，同一个词根的总量往往比工具单条记录显示的高不少，这部分被低估的量正是机会所在。

## 同一套内容能不能覆盖整个中东北非市场？

语言上可以，运营上不行。书面语内容在整个区域通用，这是阿拉伯语市场相对西班牙语市场的一个优势，不需要为每个国家重写内容。但需要按国家差异化的东西不少：货币和价格、配送时效与关税、支付方式的可用性、法定节假日与促销节奏、以及部分品类的合规要求。这些信息如果做成一套通用页面，用户看到的就是一堆不适用于自己的内容，转化会很难看。比较务实的架构是内容层共用、信息层分国家，把价格、配送、支付、联系方式这几块做成按市场变化的模块。另外提醒一句，几个主要市场的搜索行为其实有明显差异，海湾市场的客单价和品牌意识更高，人口大国的价格敏感度更高，同一个品类在两边该主推的词可以完全不同，这一层差异比语言差异更值得投入精力去研究。

## 阿拉伯语的品牌名该怎么处理？

拉丁原名和阿拉伯字母转写名都要有，但分工要清楚。拉丁原名承接已经认识你的人，他们会直接打英文；阿拉伯字母转写名承接从本地内容里第一次听说你的人，因为本地媒体和社交讨论里提到外国品牌时习惯用转写形式，这个名字的传播范围往往比品牌方以为的大得多。建议官方定一种转写作为标准写法，用在所有正式场合和结构化数据里，同时确保页面上最流行的那种民间转写也自然出现过一次。转写名最好尽早定下来，因为同一个外文名可能有几种合理的转写方式，你不主动定，市场会自己叫出一个来，等叫开了再改就是跟用户习惯作对。还有一条容易被忽略：产品型号和技术代号不要转写，一律保持原文，转写型号会切断跟国际数据源和比价平台的匹配关系，损失远大于那点搜索收益。

## 怎么判断一个阿拉伯语页面的方向处理有没有做对？

有个不需要懂阿拉伯语的快速自检法。造一段测试内容，把最容易出事的几类元素塞进同一句话里：一段阿拉伯语文字、一个拉丁字母的品牌名、一串数字、一对括号、一个百分比、一个电话号码。然后把这句话放进标题、正文、按钮、表单占位符、面包屑这几个位置各渲染一次，逐个看显示顺序对不对。接着把浏览器窗口拉窄，看每个位置的截断行为。最后把这句话复制出来粘到纯文本编辑器里，看看有没有混进不可见字符。这一整套跑下来不到一小时，能暴露绝大多数方向类问题。做完之后把这段测试内容存进项目里，以后每次改模板都跑一遍，比事后靠用户反馈发现问题便宜得多。

## 权威参考资料



## 做俄语SEO别信Wordstat的默认数字，它把十二种词形合在一起了

- URL：https://zhangwenbao.com/russian-seo-cyrillic-cases-declension-wordstat-keyword.html
- 分类：小语种SEO
- 发布：2010-11-17  |  更新：2026-07-24
- 摘要：讲俄语SEO关键词实战：六格变化与词形还原、Wordstat的感叹号引号加号方括号操作符与区域数据、完成体与未完成体动词对应的意图分层、俄语高频意图修饰词、西里尔拉丁同形字排查、Punycode与URL转写、西里尔字体与文本膨胀。
- 关键词：关键词研究,内容本地化,小语种SEO

> **TLDR**：摘要：俄语一个名词有六个格，配上单复数就是十二种形式，形容词还要跟着变性数格。这意味着你词表里那个漂漂亮亮的主格单数，跟用户真正打进搜索框的字符串常常不是一回事。更要命的是关键词工具默认把所有词形合并统计，不懂那几个符号就会把一个虚高的数字当成真实需求，按它排出来的优先级从第一步就是歪的。这篇只讲语言这一层：词形怎么归并、Wordstat的符号怎么读、西里尔和拉丁那些长得一模一样的字母会怎么坑你，以及俄语站的URL到底该写成什么。

> 摘要：俄语一个名词有六个格，配上单复数就是十二种形式，形容词还要跟着变性数格。这意味着你词表里那个漂漂亮亮的主格单数，跟用户真正打进搜索框的字符串常常不是一回事。更要命的是关键词工具默认把所有词形合并统计，不懂那几个符号就会把一个虚高的数字当成真实需求，按它排出来的优先级从第一步就是歪的。这篇只讲语言这一层：词形怎么归并、Wordstat的符号怎么读、西里尔和拉丁那些长得一模一样的字母会怎么坑你，以及俄语站的URL到底该写成什么。

先讲个具体的翻车。一个做小家电的品牌进俄罗斯市场，主推吸尘器和空气净化器。词表是找翻译按品类整理的，每个词都规规矩矩写成主格单数：пылесос、очиститель воздуха。查了搜索量，数字漂亮，团队信心十足。

上线之后流量对不上预期，拉搜索词报告一看，进站的查询五花八门：有带介词的、有复数的、有把形容词摆在后面的，跟词表里那几个词长得都不太一样。更尴尬的是当初做优先级排序时用的搜索量，其实是把所有这些变形合在一起的总数，团队按一个合计数去投一个具体页面，从一开始就错配了。

## 俄语一个名词能变出十二种形式，词表该按哪一种做？

俄语是典型的屈折语，名词有六个格，每个格在单数和复数里各有一套词尾。以吸尘器这个词为例，主格是 пылесос，属格 пылесоса，与格 пылесосу，宾格跟主格同形，工具格 пылесосом，前置格 пылесосе，复数再来一整套。

形容词还要跟着名词的性、数、格一起变。所以一个两词短语在实际句子里能写出十几种字符串形态，而它们说的完全是同一件事。这跟英语加个复数s完全不是一个量级的问题。

## 搜索引擎会不会自己把词形归并

会，而且做得相当好。处理俄语这类屈折语的搜索系统都要做词形还原，把各种变形折回到词典形式再去匹配，否则索引根本没法用。这也是俄语用户搜索时不太在意词形的原因，他们知道怎么打都能搜到。

但归并是在检索侧做的，不代表你可以不管词形。有三个地方它帮不了你：一是关键词工具报出来的数字是合并后的，你得知道它合了什么；二是页面上的文案要读起来自然，硬把主格单数塞进需要变格的句子里，俄语读者一眼就看出是机翻；三是标题和H标签里用哪种形式，直接影响可读性和点击。

## 词形归并帮不了你的地方，正是决策出错的地方

最典型的误判是这样：工具显示某个词月搜索量很大，你据此立了个项，做了一个页面。上线后发现流量分散在几十个变体查询上，每个变体背后的意图还不完全一样——有人搜的是买，有人搜的是修，有人搜的是配件。合并统计把不同意图的需求捏成了一个数字，而页面只能服务其中一种。

正确的做法是先看合计量判断这个概念值不值得做，再拆开看具体变体判断该做几个页面。这一步在英语市场可以粗糙一点，在俄语市场省不了。

## Wordstat的那几个符号，不会用等于看不懂数据？

俄语关键词研究绕不开Yandex的Wordstat，它的数据覆盖是这个市场里最全的。但它有个对新手极不友好的默认行为：不加任何符号时，你查到的是宽泛匹配的合计量，包含所有词形，也包含所有含这个词的更长查询。

换句话说，你查 пылесос 得到的那个数字，里面混着买吸尘器、修吸尘器、某品牌吸尘器、吸尘器过滤网等等一大堆需求。把这个数当成主词的真实需求量，是俄语市场最常见的入门错误，而且错得很隐蔽——数字看起来特别令人振奋。

## 四个必须掌握的符号

按 Yandex Wordstat的操作符说明 (https://yandex.ru/support2/wordstat/en/content/operators)，工具支持感叹号、加号、引号、方括号、圆括号和竖线这几种符号，各管一件事。

符号 | 作用 | 不用会怎样 | 

感叹号 | 固定词形，锁住格、数、时态 | 所有变形被合并计入 | 

引号 | 固定词数，排除附加词 | 长尾查询全被算进主词 | 

加号 | 强制包含停用词 | 介词被忽略，意图被抹平 | 

方括号 | 固定词序，允许词形变化 | 不同语序的需求混在一起 | 

实操顺序建议是这样：先不带符号查一次拿概念的整体盘子，再用引号查一次拿这个词组本身的量，最后用感叹号确认具体词形的分布。三个数字放在一起，才能看出这个概念的需求结构是集中还是分散。

## 区域数据不看，会把全国的量当成本地的量

Wordstat有个按地区拆分的能力，这在俄语市场是必须用的，不是可选项。俄语覆盖的地理范围极大，同一个词在不同地区的搜索量和竞争强度可能差好几倍，季节性节奏也不一样。

典型的坑是这样：你看到一个全国口径的漂亮数字，实际投放和内容却只覆盖得了其中一两个城市圈。做本地服务、线下门店、有配送半径限制的品类时，这个误差足以让整个项目的预期彻底失真。

更实用的用法是反过来：先看某个词的区域分布，再决定内容和落地页要不要按地区拆。如果需求高度集中在少数几个大城市，那就集中做透；如果分布均匀，那说明这是个全国性通用需求，按品类做就行。

## 加号那个符号，在俄语里比想象中重要

加号用来强制包含停用词，也就是介词、代词这类单独看没什么意义的词。听起来无关紧要，但俄语的介词经常是意图的分水岭。

拿吸尘器举例，带不同介词的查询指向的是完全不同的场景：用于某种地板的、给某类房间的、装在某处的。这些介词一旦被工具忽略，几组意图差别很大的需求就被压成了同一个数字。做产品页和场景页的时候，介词是必须保留的信息，因为它决定了页面该写什么。

## 俄语语序那么自由，标题该按哪种顺序写？

俄语的语法关系靠词尾标记，不靠位置，所以语序相当自由，同一个意思调换顺序仍然成立，只是强调重点不同。再加上俄语没有冠词，句子结构比英语松得多。

这对搜索的影响是：同一个需求会以多种词序出现在查询里，而这些词序未必都被工具当成同一个词。方括号操作符就是为这种情况准备的，用它可以锁住顺序同时允许词形变化，看看某个特定语序到底有多少人在用。

## 标题里的语序，跟着搜索习惯走还是跟着语法走

两者通常不冲突。俄语里最中性的语序仍然是形容词在前名词在后，跟大多数查询习惯一致，按自然语序写就好。真正要避免的是为了拼关键词把语序拗成不自然的样子，那在俄语里比在英语里更刺眼，因为俄语读者对语序承载的语气非常敏感。

有一种情况值得单独处理：品类词加限定词的组合，用户经常把限定词甩到后面。这时候可以让标题用自然语序，正文里自然出现另一种语序即可，不需要刻意在标题里堆两遍。

## 俄语动词分两种体，这会影响意图判断吗？

影响很大，而且这是俄语给SEO送的一份礼物：俄语动词的体，本身就在告诉你用户处在漏斗的哪一段。

俄语动词分完成体和未完成体两套。完成体强调一次性完成的动作，未完成体强调过程、反复或习惯。买这个动作有两个词：купить 是完成体，指这一次要买成；покупать 是未完成体，指买东西这个行为本身。

## 完成体是交易词，未完成体偏浏览

用户打出带完成体动词的查询，意思接近现在就要办成这件事。купить 加品类词，是俄语电商里商业价值最高的查询模式之一，跟英语里buy加品类词的地位相当，但因为俄语的体是强制标记的，这个信号比英语清晰得多。

未完成体则更多出现在信息型查询里，用户在了解、比较、考虑。同一个词根的两种体，应该落到不同的页面上：完成体导向商品页和分类页，未完成体导向导购、评测、指南类内容。

## 动词形态也在暗示查询意图

除了体，动词的形态也带信息。不定式形式常出现在如何做类查询里，命令式偶尔出现在工具类需求中，而带疑问词的组合几乎必然是信息型需求。

做词表时可以直接按这个维度分层：带完成体动词的进交易层、带未完成体或疑问词的进内容层，这比单纯按搜索量排序有用得多。俄语在这一点上比英语和中文都更省事，因为语法把意图明明白白标出来了。

## 俄语的搜索意图修饰词，有哪些是必须覆盖的？

每个语言市场都有一批高频修饰词，它们跟任何品类词组合都能构成大量长尾。俄语这批词有几个跟英语市场不太一样，不知道就会漏掉整块需求。

修饰词 | 含义 | 意图层级 | 该做什么页面 | 

купить | 买 | 交易 | 商品页、分类页 | 

цена / стоимость | 价格 / 费用 | 交易前 | 价格页、报价工具 | 

отзывы | 用户评价 | 决策 | 评价聚合页 | 

рейтинг / лучшие | 排行 / 最好的 | 决策 | 榜单、对比 | 

как выбрать | 怎么选 | 信息 | 选购指南 | 

своими руками | 自己动手 | 信息 | 教程、方案 | 

аналог | 替代品 | 决策 | 替代方案对比 | 

инструкция | 说明书 | 售后 | 文档、支持页 | 

## 评价类查询的权重高得出奇

отзывы 这个词在俄语搜索里的活跃度值得单独说。俄罗斯用户下单前查评价的习惯非常强，几乎任何品类加上这个词都有可观搜索量，而且这类查询的商业价值极高，因为搜的人已经在做最终决策。

问题在于这类流量很容易被聚合平台和论坛全部吃掉。品牌方想接住，靠自己站上的评价页往往不够，还需要在第三方平台上有真实存在。这跟日语市场里口碑类查询的地位很像，不同的是俄语这边的聚合平台集中度更高。

## 自己动手那一类，是被严重低估的入口

своими руками 直译是用自己的双手，对应英语的DIY。俄语内容生态里这类需求异常旺盛，从家装、维修到手工，几乎每个消费品类都有一条自己动手的长尾线。

对品牌方的价值在于它是极便宜的顶部流量入口：做一篇像样的自己动手教程，能带来的自然流量常常超过硬推商品页，而且顺带解决了信任问题。前提是内容得真能用，敷衍的教程在这个人群里毫无机会。

## 西里尔字体和文本长度，会把版式撑坏吗？

会，而且这是俄语站上线时最容易被前端漏掉的一环。语言这层的功课做完了，版式垮掉照样白搭。

## 不是所有字体都带西里尔字形

大量商业字体和网络字体只覆盖拉丁字符集，不含西里尔字形。页面用了这样的字体，浏览器会退回到系统默认字体去渲染俄语文本，结果就是同一个页面上标题一种味道、正文另一种味道，看着说不出哪里怪但就是不专业。

更糟的是字体子集化。为了提速把字体裁剪成只含用到的字符是常规优化，但裁剪规则如果按拉丁范围设定，俄语页面上会直接出现方块或空白。这类问题在测试时容易漏掉，因为开发环境往往加载的是完整字体。

## 俄语文本比英语长，按钮和导航先撑爆

同样的内容翻译成俄语，文本长度通常比英语明显增加，短文本增加得尤其厉害。原因不难理解：俄语没有冠词但词本身长，加上词尾变化，一个英语单词对应的俄语词往往多出好几个字母。

受害最重的是那些宽度固定的地方：导航菜单、按钮文字、表格标题、卡片标签。英文版排得整整齐齐的界面，换成俄语就开始换行、溢出、被省略号截断。稳妥做法是设计阶段就按更长的文本预留空间，别等翻译交付了再回头改样式。

这类因语言特性撑坏版式的问题，在别的非英语市场同样存在，只是表现形式不同——日语那边是宽字符导致标题按像素早早超长 (https://zhangwenbao.com/japanese-seo-hiragana-katakana-kanji-keyword-notation.html)，俄语这边是词长导致横向溢出，根子都是拿英文版的空间假设去装另一种语言。

## 字母 ё 上面那两点，到底要不要覆盖？

俄语字母表里有个 ё，它跟 е 是两个不同的字母，但在日常书写里几乎总是被写成 е。这不是错别字，而是长期形成的习惯：正式规则里 ё 的使用是选择性的，只在容易产生歧义、需要标注读音、或者面向识字初学者的文本里才要求写全。

落到搜索上，结论很干脆：用户几乎不会打 ё，因为俄语键盘上它在一个很偏的位置。所以关键词层面按 е 的写法做就对了，搜索引擎两边也都能归并。

## 页面显示上还是有讲究

虽然搜索不区分，但页面文本用哪个写法会影响观感。稳妥做法是正文按常规习惯写 е，只在会引起歧义的词和专有名词上写 ё。人名和地名尤其如此，把某人姓氏里的 ё 写成 е，在正式场合是不礼貌的。

如果你的品牌名或产品名里含 ё，那就得两手准备：正式场合用带两点的写法保持规范，同时确保搜索里用不带两点的写法能找到你，别在页面上把两种写法当成两个不同的名字来管理。

## 西里尔字母和拉丁字母长得一样，会带来什么麻烦？

这是俄语站最隐蔽、也最容易造成长期损失的技术坑。西里尔字母表里有一批字母跟拉丁字母的外形完全一致：а、о、е、с、р、х、у、к、м、т 这些，肉眼根本分不出来，但它们的编码完全不同。

Unicode关于安全机制的标准附件 (https://www.unicode.org/reports/tr39/)专门定义了这类易混淆字符，并给出了混合书写系统的检测方法，还划分了从仅限ASCII到无限制的多个限制级别。文档里的思路很清楚：一个字符串如果同时来自多个书写系统，就应该被特别对待。

## 产品型号和品牌名是重灾区

想象一个型号写作XC-100的产品。录入的人用俄语键盘打字，中间某个字母顺手打成了西里尔的同形字。屏幕上看起来一切正常，实际这个字符串已经不是用户搜索的那个了。

后果是链条式的：站内搜索找不到、筛选出不来、跟供应商的数据对不上、外部平台同步时匹配失败，而所有排查都会卡在同一句话上——明明看着一模一样。这类问题在俄语电商里出现频率高得惊人，源头往往是运营在两种键盘布局之间来回切换时的手滑。

## 怎么把混进来的同形字揪出来

靠眼睛不行，得靠规则。最简单有效的办法是给字段定书写系统规则：型号、SKU、品牌拉丁写法这类字段只允许拉丁字母和数字，检测到西里尔字符直接报错；纯俄语描述字段则反过来，允许西里尔为主但要注意别混进拉丁同形字。

数据导入环节加一道这样的校验，成本极低，能挡掉后面一大堆莫名其妙的问题。已经上线的站可以做一次全量扫描，把混合书写系统的字段挑出来集中修，通常一次就能清掉绝大部分。

## 俄语站的URL该用西里尔还是转写？

技术上两条路都通。西里尔字符可以直接进URL，也可以注册西里尔域名，俄罗斯自己的西里尔顶级域早就投入使用了。它们底层都要经过一层编码转换。

域名这一层的机制由 RFC 3492定义的Punycode编码 (https://www.rfc-editor.org/rfc/rfc3492.html)承担，它把Unicode字符串转成ASCII形式，让只认ASCII的系统也能处理国际化域名。浏览器地址栏里通常会显示回原文，但底层传输的是编码后的形式。

## 路径部分建议用转写

域名可以考虑用西里尔做品牌防御，路径部分则强烈建议转写成拉丁字母。原因跟别的非拉丁语言一样：编码后的URL复制粘贴容易断、日志和分析工具里不可读、外部平台解析时容易出错，而俄语词转出来的编码串往往很长。

更麻烦的是转写本身没有统一标准，俄语转拉丁存在好几套体系，同一个词能转出不同结果。比如表示 ж、ч、ш、щ 这几个音的写法各家就不一致。关键不是选哪套标准，是选定一套写进规范，之后所有新页面都照着来，最怕的是站里三种转写风格并存。

## 西里尔域名值不值得注册

作为主域名要慎重：用户在没有俄语键盘的环境下打不出来，口头传播时也说不清楚。作为防御性注册then做跳转则很划算，尤其是品牌名本身就是俄语词的情况，避免被别人抢注去做仿冒。这跟保哥在德语变音符号域名的取舍 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)里给的建议是同一套逻辑，非拉丁语言在这件事上的处境相当一致。

## 品牌名用拉丁原文还是西里尔转写？

这是出海品牌进俄罗斯必须早定的一件事，因为两种写法都会被用户搜，而且它们各自对应不同的认知阶段。

已经知道你的人会直接打拉丁原文；从俄语内容、媒体报道、朋友推荐里第一次听说你的人，搜的是西里尔转写。俄语媒体在报道外国品牌时习惯用转写形式，所以转写名往往比你以为的传播得更广。

## 转写不唯一，得自己定一个

同一个外文名转成西里尔可能有几种写法，尤其是含有俄语里没有的音时。如果你不主动定一个，市场会自己叫出一个来，等叫开了再改就是跟用户习惯作对。

务实的做法是：官方定一种转写作为标准写法用于所有正式场合，同时在页面里让最流行的那种民间写法自然出现一次，比如在品牌介绍段落里提及。这样既保持了品牌统一性，也接住了搜索。

## 产品型号不要转写

跟品牌名不同，型号、规格代号、技术参数一律保持拉丁原文，不要转写。转写型号会直接切断跟国际数据源、供应商目录、比价平台的匹配关系，得不偿失。这条跟前面说的字段书写系统规则是配套的。

## 说俄语的不只俄罗斯，其他市场该怎么处理？

这是做俄语内容时最容易被简化掉的一层。俄语在多个国家被广泛使用，一套俄语内容理论上能覆盖好几个市场，但直接一套打天下会在几个地方出问题。

## 语言相通，不代表市场相同

语言这一层的差异确实小，词汇基本通用，读起来没有障碍。真正分叉的是语言之外的东西：货币不同、支付习惯不同、物流时效不同、进口和合规要求不同、节假日和促销节奏也不同。

所以判断标准可以直接借用别的多地区场景：如果核心内容能通用，只是价格、配送、合规信息需要分开，那就共用内容做地区版本；如果连品类需求本身都不一样，才值得考虑独立内容。多数消费品类属于前一种。

## 本地语言和俄语的分工，得看具体国家

这些国家大多有自己的官方语言，同时俄语在商业和日常中仍被广泛使用，但两者的力量对比在不同国家差别很大，而且是随时间变化的。有的市场里本地语言的网络内容生态已经相当成熟，只做俄语版会显得你没把这个市场当回事。

务实的做法是先看数据再决定：查一下目标市场里同类查询用本地语言和用俄语各有多少量，谁大就先做谁，别凭印象拍板。资源充足时两种都做，把俄语版当成覆盖面，把本地语言版当成深度和诚意。

## 地区标签和内容重复，是这里最常见的技术问题

用地区子标签区分同一种语言的不同市场版本，做法本身很成熟，但俄语场景下有个特别容易出的问题：几个地区版本的内容重复度太高，除了价格和配送信息几乎一模一样。

这种情况下最常见的后果不是排名互相分流，而是搜索引擎判定其中某些版本没有独立价值，干脆不给收录。要做地区版本，就得让每个版本真的有本地化的东西——本地货币、本地联系方式、本地案例、本地物流说明，而不是只改一个价格数字。做不到这一步的话，与其拆不如不拆。

## 俄语内容写作有哪些容易翻车的地方？

技术层面理顺了，内容层面还有几处硬伤会暴露翻译痕迹。

## 称谓选错，语气整个跑偏

俄语有 ты 和 вы 两套人称，前者用于熟人和亲近关系，后者用于正式场合和不熟的人。商业内容基本一律用 вы，用错等于跟陌生客户称兄道弟。

还有个更细的点：вы 在正式书面语里有时会大写首字母以示尊重，用不用取决于文体和场合，但同一份文案里必须统一。这类细节翻译外包时要写进需求单，否则不同译者交回来的稿子会各写各的。

## 数字和日期格式，照搬英文就露馅

俄语的数字格式跟英语不同：小数点用逗号，千位分隔用空格而不是点号或逗号。日期是日在前月在后，正式文本里月份常用词而不是数字。货币符号习惯放在数字后面。

这些细节单看都不起眼，凑在一起就是一个页面像不像本地做的判断依据。俄语用户对格式细节的敏感度不低，尤其在价格和规格这类信息上。

## 直译的营销文案，问题出在句子结构

从英文直译俄语，语法可以全对，读起来却处处别扭。最常见的是句子太短太碎——英文营销文案喜欢短句排比，俄语商业写作则习惯较完整的句式，一串短句连着来会显得口气生硬。

另一个是形容词密度。英文里堆形容词是常规操作，俄语里堆多了会显得空洞不可信。整套从翻译升级到本地再创作的流程，保哥在出海独立站关键词本地化的翻译陷阱与人审流程 (https://zhangwenbao.com/overseas-indie-keyword-localization-translation-traps-native-review.html)里拆过，俄语的特殊之处只是在于词形变化会让蹩脚的翻译暴露得更快。

## 俄语站上线前该检查哪些语言层的东西？

把前面的内容压成一份按顺序过的清单：

检查项 | 看什么 | 不合格的表现 | 

搜索量口径 | 宽泛量、引号量、词形量三个数都取过 | 只看不带符号的合计数 | 

介词保留 | 场景类查询保留介词做页面区分 | 把不同意图合成一个页面 | 

词形自然度 | 正文里名词按句子需要变格 | 满篇主格单数硬塞 | 

ё 的写法 | 正文用 е，专有名词写 ё | 品牌名两种写法混用 | 

混合书写系统 | 型号字段只允许拉丁，描述字段查同形字 | 型号里混进西里尔字母 | 

URL转写 | 路径全拉丁，转写规则全站统一 | 三种转写风格并存 | 

品牌转写 | 官方转写名已确定并在页面出现 | 市场自己叫出别的名字 | 

称谓一致 | 全站统一用 вы | 同页混用两套人称 | 

数字格式 | 小数逗号、千位空格、货币在后 | 照搬英文格式 | 

这份清单里前两条是决策质量问题，中间几条是数据质量问题，最后几条是内容质量问题。三类问题的共同点是它们都不会报错，只会让效果慢慢差一截，而你很难从报表里看出原因。

回到开头那个小家电品牌。后来的调整没花多少力气：把主词按引号和感叹号重新量了一遍，发现原来那个大数字里超过七成属于带附加词的长尾；顺着这些长尾把页面拆成了买、比、修三条线，各写各的；再把商品数据里混进西里尔同形字的型号扫了一遍，清掉了一批一直找不到的商品。词表没扩，预算没加。俄语市场大部分的浪费，都发生在把一个合计数字当成一个需求的那一刻。

至于Yandex这个引擎本身怎么排名、它跟Google在俄语市场怎么分工，那是另一条线上的事，跟本文讲的语言层功课基本正交。想补那一半的可以看Yandex SEO与俄罗斯搜索生态实战 (https://zhangwenbao.com/yandex-seo-russia-cis-complete-guide.html)，两边合起来才算把这个市场看全。

## 常见问题解答

## 俄语关键词表到底该按主格单数做，还是把所有词形都列出来？

词表本身按主格单数做就对了，这是词典形式，也是团队内部沟通最不容易乱的形式。但要在词表旁边多留几列：这个概念的宽泛搜索量、加引号后的词组量、以及主要变体的分布情况。这三个数字放在一起才能看出需求结构。把所有词形都列进词表是没必要的，一来搜索引擎会自己做词形还原，二来十几种形式列下来词表会膨胀到没法用，反而看不清重点。真正需要关心具体词形的场合有两个：一是判断某个特定变体是不是承载了独立意图，比如带某个介词的组合可能对应完全不同的使用场景，那就该单独做页面；二是写页面文案的时候，正文里的名词必须按句子语法自然变格，不能为了塞关键词把主格单数硬插进需要变格的位置，那种句子俄语读者一眼就看出是机器翻的。

## Wordstat显示的搜索量，为什么跟实际来的流量差那么多？

最常见的原因是没搞清楚数字的口径。不加任何符号查询时，得到的是宽泛匹配的合计量，它包含这个词的所有词形变化，也包含所有含这个词的更长查询。所以你查一个品类词看到的大数字，实际上是整个品类相关需求的总和，里面混着买、修、配件、品牌、评测等等一大堆不同意图，而你的单个页面只可能服务其中一小部分。正确的读法是分三步：先不带符号查一次，这个数用来判断整个概念值不值得投入；再加引号查一次，得到的是这个词组本身、不含附加词的量，这个数更接近单页面能承接的规模；最后用感叹号锁定具体词形，看主要变体是集中还是分散。三个数字之间的落差本身就是信息，落差特别大说明需求高度长尾化，那就该多做几个页面而不是把宝押在一个主词上。另外别忘了加号，俄语的介词经常是意图分水岭，被工具忽略掉的话几组差别很大的需求会被压成一个数。

## 网站数据里混进了西里尔同形字，怎么批量找出来？

靠肉眼是找不出来的，因为西里尔的 а、о、е、с、р、х 这些字母跟拉丁同形字在屏幕上完全一样，只有编码不同。正确做法是按字段定书写系统规则再做批量检测。具体来说，把字段分成两类：型号、SKU、品牌拉丁写法、技术参数这类只允许拉丁字母和数字，扫描时只要检测到任何西里尔字符就是问题数据；纯俄语的标题和描述字段则相反，以西里尔为主，要留意有没有混进拉丁同形字。检测本身用一个简单的字符范围判断就能做，不需要复杂工具。找出来之后集中修一遍，同时在数据导入环节加一道同样的校验，防止再混进来。这个问题的源头通常是运营在俄语和英语键盘布局之间来回切换时的手滑，所以光修历史数据不够，得把入口堵上。已经上线的站建议做一次全量扫描，通常一次就能清掉绝大部分，之后靠导入校验维持。

## 俄语站的URL用西里尔字符会不会影响收录？

收录本身不受影响，搜索引擎能正常抓取和索引带西里尔字符的URL，底层通过编码转换处理，这套机制是成熟的标准。所以纯从技术可行性说没问题。但实际使用中的麻烦不少：编码后的地址是一长串看不懂的字符，复制粘贴到聊天工具、邮件或者外部平台容易被截断或错误解析；后台日志和分析工具里看到的也是编码形式，排查问题时几乎不可读；俄语词转出来的编码串通常比英语长得多，这个问题被放大得很明显。所以主流建议是域名层可以考虑西里尔做品牌防御并做跳转，路径部分一律用拉丁转写。转写时要注意选定一套规则并全站统一，因为俄语转拉丁存在多套体系，表示某几个辅音的写法各家不一致，同一个词能转出不同结果。站里如果并存三种转写风格，看起来会非常业余。已经用了西里尔URL并且收录正常的站，别为这个专门做迁移，改URL的风险大过收益。

## 外国品牌进俄罗斯，官网上该写拉丁名还是西里尔名？

两个都要有，但分工要清楚。拉丁原名承接已经认识你的人，他们会直接打英文；西里尔转写名承接从俄语内容里第一次听说你的人，因为俄语媒体报道外国品牌时习惯用转写形式，这个名字的传播范围往往比品牌方以为的大得多。实操建议是官方定一种转写作为标准写法，用在所有正式场合和结构化数据里，同时确保页面上最流行的那种民间转写也自然出现过一次，比如在品牌介绍段落里带一句。这样既保持统一又接住了搜索。要注意的是转写名最好尽早定下来并注册，因为同一个外文名可能有几种合理的转写方式，你不主动定，市场会自己叫出一个来，等叫开了再想改就是跟用户习惯作对。还有一条容易被忽略：产品型号和技术代号不要转写，一律保持拉丁原文，转写型号会切断跟国际数据源和比价平台的匹配关系，损失远大于那点搜索收益。

## 俄语内容的母语审校，重点该看什么？

俄语审校跟别的语言相比有几个专属重点。第一是词形是否自然，翻译质量差的稿子最明显的特征就是名词该变格的地方没变，或者变错了格，读起来磕磕绊绊；这一条非母语者基本判断不了，只能交给审校。第二是称谓一致性，商业内容基本一律用 вы，要检查全稿有没有混进 ты，以及首字母大写的处理是否统一。第三是句子节奏，从英文直译过来的稿子往往句子太短太碎，俄语商业写作习惯更完整的句式，一串短句排比会显得生硬；同时要检查形容词密度，堆得太满在俄语里会显得空洞。第四是格式规范，小数点用逗号、千位用空格、日期日在前月在后、货币符号在数字后面，这些照搬英文格式会立刻露馅。给审校提需求时把这四条明确写出来，比笼统说一句请检查语言质量有效得多。另外建议让审校单独读一遍首页和主要落地页，只回答一个问题：读起来像不像本地公司写的。

## 权威参考资料



## 本来以为意大利语SEO选词跟西班牙语差不多，直到每个形容词都要跟着名词改性数

- URL：https://zhangwenbao.com/italian-seo-gender-agreement-elision-keyword-research.html
- 分类：小语种SEO
- 发布：2009-12-15  |  更新：2026-07-25
- 摘要：讲意大利语SEO实战：名词阴阳性与形容词性数一致怎么进商品字典、不规则复数为什么不能靠程序生成、省音撇号的三层归一、截音不加撇号的规则、重音只标词尾可以当校验规则、单复数形态按品类判断、打折季排期与本地意图词。
- 关键词：关键词研究,内容本地化,小语种SEO

> **TLDR**：摘要：意大利语的名词分阴阳两性，形容词、冠词、过去分词全都要跟着它改形态，所以一串关键词里改一个词，后面几个位置一起变。再加上撇号会把两个词粘成一个、好好的形容词到了名词前面要被砍掉半截，直接照搬西班牙语那套做法会连着踩空。这篇把性数一致、复数变化、省音与截音、重音标注在搜索里的真实分布拆开讲，落到词表字段、标题模板、分类页命名和母语审校清单上。

> 摘要：意大利语的名词分阴阳两性，形容词、冠词、过去分词全都要跟着它改形态，所以一串关键词里改一个词，后面几个位置一起变。再加上撇号会把两个词粘成一个、好好的形容词到了名词前面要被砍掉半截，直接照搬西班牙语那套做法会连着踩空。这篇把性数一致、复数变化、省音与截音、重音标注在搜索里的真实分布拆开讲，落到词表字段、标题模板、分类页命名和母语审校清单上。

先说一个把人绊住的场景。一家做户外家具的独立站，主打折叠餐桌椅、遮阳伞和躺椅这几条线，德语区和法语区已经跑了两年，数据稳定。团队看意大利人爱在阳台和露台上折腾，气候也对路，就把意大利语版本排进了当年的计划。

负责这块的是做过西班牙语站的同事。想法很直接：都是拉丁语系，词根一眼能认出来，语法看着差不多，把西班牙语的那套流程复制过来，翻译换一批人就行。

头两个月一切正常，词表建出来了，页面上线了，收录也没问题。转折点出现在意大利本地的合作方发来的一封邮件里，对方很客气地列了一张表格，指出商品列表页上有47处语法错误——不是拼写错，是形容词跟名词对不上号。

问题不在翻译质量，翻译是母语者做的。问题出在模板：标题模板是按西班牙语的结构搭的，把品类词和修饰词拼在一起，而意大利语里这两个词必须在性和数上保持一致，模板不知道这件事。

## 意大利语的名词为什么先要分公母？

意大利语的每一个名词都有性别，阳性或阴性，没有中性。这不是按事物本身的属性分的，桌子是阳性、椅子是阴性，跟桌椅本身没有半点关系，纯粹是词的属性。

大部分时候能从词尾看出来：以o结尾的多半是阳性，以a结尾的多半是阴性。tavolo（桌子）阳性，sedia（椅子）阴性。这条规律覆盖率不低，但漏洞也不少。

以e结尾的名词两种性别都有可能，光看词尾判断不出来。做户外家具会天天碰到的ombrellone（大遮阳伞）是阳性，而同样以e收尾的luce（灯光）是阴性，只能靠记。

还有一批词连意大利人自己都要吵。Treccani百科的名词性别条目 (https://www.treccani.it/enciclopedia/genere_%28Enciclopedia-dell%27Italiano%29/)把这套规则和例外整理得很细，做词表时值得摆在手边当参照。

## 一个词改了性数，整串关键词跟着改几个位置？

这是意大利语跟英语最本质的分歧。英语里folding table和folding tables，folding一动不动。意大利语不是这样。

tavolo pieghevole是可折叠桌，单数阳性。变成复数就是tavoli pieghevoli，两个词的词尾一起改。

换成椅子，sedia pieghevole，单数阴性。复数是sedie pieghevoli。注意这里名词从a变成e，而形容词从e变成i，两个词各按各的规则走，看着完全不像同一套变化。

如果形容词是o结尾那一类，四种形态都不一样。tavolo rotondo（圆桌）、tavoli rotondi、sedia rotonda、sedie rotonde——同一个形容词，四种拼写。你的标题模板要是不认识这件事，输出的就是四分之三的错误率。

## 复数变化到底有几条规则要记？

主干规则只有三条：o结尾变i，a结尾变e，e结尾变i。记住这三条能覆盖大多数常用词。

麻烦的是拼写为了保住读音要额外动手。以ca、ga结尾的阴性名词变复数时中间要塞一个h进去，panca（长凳）的复数是panche，不是pance，因为不塞这个h读音就从硬音变成了软音。

阳性的co、go更没规律，parco（公园）变parchi加了h，而amico（朋友）变amici不加。判断依据跟重音位置有关，但例外多到没法只靠规则推，做词表时老老实实一个一个查。

这件事在SEO上的直接后果是：你没法用程序从单数生成复数。想省这个事的团队，最后都会在分类页标题上留下一批意大利人一眼看出来的错字。

## 外来词进了意大利语为什么不跟着变复数？

意大利语借了大量英语词，而借进来的词一律不变复数。il computer的复数是i computer，词本身一个字母都不动，只有前面的冠词从il变成i。

做户外家具经常遇到的set就是这样，il set da giardino（一套花园家具）的复数是i set da giardino。写成sets是错的，而机器翻译特别爱加这个s。

这条规则反过来给了你一个便利：涉及外来词的关键词，单复数只在冠词上有区别，词本身的形态是唯一的，词表里可以合并成一条。

但要小心那些已经被意大利语消化掉的借词。有些词进来太久，已经长出了意大利语的词尾，反而要按本地规则变复数。判断标准很粗暴：词尾像不像意大利语的词尾，像就变，不像就不变。

## 七种冠词形态，选错一个搜索词就不像人话

意大利语的定冠词有七种形态：il、lo、la、i、gli、le，加上省音后的l'。选哪一种取决于名词的性、数，还有紧跟其后那个词的开头字母。

规则大致是这样：阳性单数默认用il，但后面接s加辅音、z、gn、ps这些组合时改用lo，接元音时用l'。阳性复数对应i和gli。阴性简单些，单数la、复数le，接元音时单数省音成l'。

lo scaffale（架子）不能写成il scaffale，l'ombrellone不能写成lo ombrellone。这类错误在意大利人眼里的刺眼程度，大概相当于中文里把量词全用成个。

关键词本身通常不带冠词，所以这一层不直接影响选词，但它影响标题、描述、导航文案和面包屑——凡是要写成完整短语的地方都躲不掉。

## 撇号是怎么把两个词粘成一个的？

意大利语里前一个词的末尾元音碰上后一个词开头的元音时，前面那个元音要脱落，用撇号顶替。这个现象叫省音，它带来的后果是两个词在字符层面变成了一个连续的字符串。

lo ombrellone写出来是l'ombrellone，中间没有空格。della alluminio写成dell'alluminio。分词器如果不认识撇号，会把l'ombrellone当成一个整词或者切成l和ombrellone两截，两种切法都会让匹配出问题。

更要命的是撇号本身有两种字符。键盘上直接打出来的是直撇号，而排版规范和很多编辑器的自动替换会给你一个弯撇号，两者在编码里是完全不同的字符。用户搜索时打的几乎全是直撇号，你的页面上如果全是弯撇号，字符串比对就对不上。

这件事在站内搜索和筛选器上最容易翻车。处理办法是查询和索引两边都做一次撇号归一，把弯的折成直的，再顺手做一次去撇号的备份索引，两层都留着。

## 好好的buono为什么到了名词前面就变成buon？

这是另一个把词形改短的机制，叫截音。某些形容词放在名词前面时，末尾的音节会被砍掉。

buono（好的）在名词前变成buon，bello（漂亮的）变成bel，grande（大的）变成gran。buon prodotto、bel giardino、gran risparmio，这几个组合在意大利语的营销文案里出现频率高得离谱。

截音跟省音的区别在于截音不加撇号。写成buon' 是错的。唯一一个例外是un poco缩成un po'，那个撇号是合法的，因为它标记的是被砍掉的音节而非脱落的元音。Treccani的截音条目 (https://www.treccani.it/enciclopedia/troncamento_%28Enciclopedia-dell%27Italiano%29/)把哪些词在什么条件下截、截完加不加撇号列得很清楚。

最常见的一个错误是qual è（哪一个是），很多人写成qual'è。这是截音不是省音，不该有撇号。你的常见问题模块里要是批量生成了这类标题，本地读者会觉得整站的语言水平掉了一档。

## 用户在搜索框里到底打单数还是复数？

这个问题没有统一答案，得按品类分。经验规律是：买一件的品类倾向单数，成套或者天然多件的品类倾向复数。

户外家具这个例子里，ombrellone（遮阳伞）单数占优，因为一个院子通常就买一把。而sedie da giardino（花园椅）复数占优，椅子极少单买。

tavolo da giardino（花园桌）单数占优，理由同上。而cuscini per esterni（户外坐垫）复数占优，坐垫按套买。

判断方法很简单：把两种形态都打进搜索框看下拉建议先跳出哪一个，再看排在前面的本地竞品标题用的是哪种形态。两处对上了就按那个来，对不上就以本地竞品为准，它们通常已经用数据验证过一轮了。

## 关键词工具把这些变形词合并了吗？

大部分情况下不合并，而且合并与否你没法直接看出来。工具报的数字往往只是某一个形态的量，把单数、复数、带修饰词的变体分开各算各的。

这带来的直接后果是意大利市场在报表上看起来比实际小。一个概念的需求被切成三四份，每一份单看都不起眼，加起来才是真实体量。

正确的用法是先按概念合并再排序。把一个概念下所有可能的形态列出来——单数、复数、形容词的四种形态组合、加不加介词短语的写法——全部求和后再跟别的品类比。

做西班牙语时踩过同一个坑，只不过那边合并的是地区词汇差异，这边合并的是形态差异。西班牙语两个市场的词汇分叉 (https://zhangwenbao.com/spanish-seo-es-es-latam-keyword-divergence.html)那篇里讲的合并思路可以直接搬过来用，换个合并维度而已。

## 词干还原在意大利语上能做到几分准？

比德语和俄语都容易，但别指望它替你做决定。意大利语的变化集中在词尾，词干本身基本不动，这对算法很友好。

公开的意大利语词干提取算法 (https://snowballstem.org/algorithms/italian/stemmer.html)处理规则形态的准确率相当高，把tavoli还原成tavol、把pieghevoli还原成pieghevol，两者归到一起没问题。

失手的地方在不规则复数和拼写补偿。panca和panche中间那个h会让算法把它们判成两个词根，amico和amici也是常见的失败案例。

所以词干还原可以用来做站内搜索的兜底，不能用来做关键词表的合并依据。词表还是得靠人工按概念归类，算法只负责在用户打错形态时把结果找回来。

## 形容词放名词前面还是后面，搜索量差多少？

意大利语的形容词默认放在名词后面，这跟英语相反。tavolo pieghevole是正常语序，pieghevole tavolo不是。

但有一批高频形容词习惯放在前面，位置一变意思还会跟着变。grande放后面是尺寸大，放前面偏向了不起、伟大。用户搜索时用的是前者，营销文案里写的经常是后者。

搜索行为上，意大利用户输入品类词加修饰词的组合时，几乎清一色遵循名词在前的语序。这意味着你的长尾词表要以名词打头，而不是照搬英语词表的语序直接翻译。

这一条看着琐碎，但它决定了你的长尾词能不能跟真实查询对上。语序错了，词表再全也接不住量。

## 商品标题模板怎么写才不违反性数一致？

这是本篇最有工程意义的一段。模板里只要有形容词跟品类词拼接，就必须知道这个品类词的性和数。

做法是在商品字典里给每个品类词加两个字段：性别和默认数。然后把形容词按变化类型分组，o类形容词准备四种形态，e类准备两种，外来形容词准备一种。模板渲染时按品类词的性数去取形容词的对应形态。

听起来工作量大，实际上头部两三百个品类词覆盖了绝大部分流量，一两天就能标完。真正花时间的是形容词表，但形容词是复用的，标一次全站都能用。

偷懒的替代方案是模板里干脆不放形容词，改用介词短语。tavolo da giardino这种结构里da giardino一动不动，不管品类词是什么性别。这招能救急，代价是标题的表达力变差。

## 分类页命名用单数还是复数？

分类页描述的是一类商品，用复数更自然，也更符合用户搜索时的输入习惯。Sedie da giardino比Sedia da giardino合适。

例外是那些天然单件的品类。Ombrellone做成单数不会让人觉得奇怪，因为大多数人确实只会买一把。这里的判断依据仍然是真实查询里哪种形态量大。

还有一件容易被忽略的事：分类页标题一旦定了形态，面包屑、筛选器标签、导航项最好保持一致。用户在同一个页面上看到sedie和sedia交替出现，观感会很奇怪，虽然不影响排名，但影响信任。

顺带一提，分类页标题在搜索结果里被截断的风险在意大利语上比英语高，因为意大利语的平均词长更长。这件事在标题被改写与截断的机制 (https://zhangwenbao.com/title-meta-description-seo-mechanism-at-scale.html)那篇里讲得比较系统，做多语言站时值得按语言各算一遍安全字数。

## URL里的撇号和重音字母该怎么处理？

一律转成不带符号的拉丁字母，撇号直接换成连字符或者删掉。sedie-da-giardino-pieghevoli这样的路径干净、好读、复制粘贴不出错。

意大利语的重音字母只有六个，à è é ì ò ù，全部落在Latin-1这一段里，转写规则简单到不需要查表：去掉那一撇就是对应的基本字母。

要注意的是别在URL里保留撇号。撇号在地址里会被转义成一串百分号编码，看起来像乱码，分享到社交平台还容易被截断。

已经上线的路径不要为了这个去改。改路径的收益远小于跳转链条带来的损耗，新页面按规范来就行，老页面留着。

## 重音符号打不打，città和citta是不是同一个查询？

在意大利这件事跟法语市场不太一样，值得单独说。意大利语键盘的主键区直接印着à、è、é、ì、ò、ù六个键，不用组合键、不用长按，敲下去就是带重音的字母。

所以意大利用户在电脑上省略重音的比例，明显低于法语用户。这一点跟直觉相反，法语重音符号那篇 (https://zhangwenbao.com/french-seo-accents-quebec-keyword-variants.html)里说的省略习惯不能照搬到意大利。

但手机上情况反过来。手机键盘要长按才能出重音字母，多数人懒得等，于是移动端的无重音写法比例高出一截。

结论是两种写法都要能被接住：页面上的可见文本一律打全重音，这是底线；站内搜索的查询和索引两边都先去重音再比对；关键词表里把两种写法归为一条，量相加。

## 意大利语的重音只标在词尾，这件事有什么用？

意大利语的重音符号和西班牙语最大的区别在于位置：西班牙语的重音符号可以出现在词中间，fácil、teléfono都是；意大利语的重音符号原则上只出现在词的最后一个音节上。

città、qualità、novità、perché、così、più，全部落在词尾。词中间带重音符号的意大利语词几乎不存在。

这条规律给了你一个便宜的校验规则：扫一遍全站文本，凡是重音符号出现在词中间的，基本可以判定是拼写错误或者是别的语言混进来了。写十几行脚本就能跑，一次能扫出一批脏数据。

另外有几个单音节词靠重音符号区分意思，è（是）跟e（和）、sì（是的）跟si（反身代词）、là（那里）跟la（冠词）。这几对在文案里出错频率极高，属于母语审校必查项。

## 意大利人搜产品时习惯带上哪些修饰词？

最高频的一批是prezzo（价格）、prezzi（价格复数）、offerte（优惠）、sconto（折扣）、economico（便宜的）、migliore（最好的）、recensioni（评价）、opinioni（意见）。

还有一个本地味道很重的词是saldi，指的是法定打折季。意大利的打折季开始日期由各大区规定，全国不完全同步，通常在一月上旬和七月上旬各来一轮。围绕这两个时间点的搜索量会陡增。

这件事对内容排期的意义很直接：跟折扣相关的页面要提前三到四周准备好，等打折季开始再上就晚了，那时候排名还在爬。

另外意大利用户很爱在查询里加上材质，in alluminio（铝制）、in legno（木制）、in resina（树脂）、in rattan（藤编）。材质词值得单独建一层词表，跟品类词做笛卡尔组合。

## 意图词在意大利市场跟西班牙语差在哪？

词根像不代表用法像。西班牙语的opiniones和意大利语的opinioni长得几乎一样，但意大利用户查评价时用recensioni的比例更高。

再比如便宜这个概念，西班牙语市场barato用得多，意大利语的对应词barato不存在，得用economico或者a buon prezzo。想当然直译会直接扑空。

怎么送货这类查询也不一样。意大利用户搜spedizione（配送）和consegna（送达）的场景有分工，前者偏物流方式，后者偏送达时间，页面上两个词最好都覆盖到。

处理办法是别信词典的对译，去看当地竞品的导航和帮助中心怎么写。那是最便宜的一手语料，一个下午能抄出两三百个准确的意图词。

## 价格、日期和数字格式在意大利怎么写？

小数点用逗号，千位分隔用点，跟英语正好反过来。一千二百九十九块九毛写成1.299,90，货币符号放在数字后面，中间留一个空格。

写成1,299.90在意大利读者眼里是错的，而且是那种会让人怀疑这家店是不是正规的错。价格显示是转化路径上的东西，错了代价比排名损失更直接。

日期用日在前的顺序，15/12/2009，写成月在前的12/15/2009要么被误读要么读不懂。月份名全小写，dicembre不是Dicembre，这一点跟英语的习惯不同。

邮编叫CAP，五位数字。省份用两个字母的缩写，米兰是MI、罗马是RM、都灵是TO。地址里街道名在前门牌号在后，Via Roma 12，反过来写就露馅了。

## 二十个大区怎么进关键词表？

意大利的行政层级是大区、省、市三级，大区二十个。地域词进关键词表的价值取决于你的业务形态。

纯线上发货的电商，地域词价值有限，用户搜户外家具很少加地名。真正需要地域词的是有线下门店、有安装服务、有区域配送差异的业务。

如果确实要做，优先级按人口和消费力排，伦巴第、拉齐奥、威尼托、艾米利亚-罗马涅这几个大区先做。别一上来铺二十个大区页面，那是典型的用模板批量生产薄内容。

还有一件小事：南北差异在意大利比很多国家都明显，物流时效、配送费用、退换政策如果南北有别，这些差异写进页面比堆一堆地名管用得多。

## 机器翻译在意大利语上最爱犯哪三类错？

第一类是性别错配。源语言里没有性别信息的短语，机器要靠猜，猜错了就是冠词和名词对不上，il sedia这种组合一眼就露馅。

第二类是形容词不跟着变。多个名词并列时形容词该用哪种形态，需要判断整组的性和数，机器经常只看最近的那个词，输出sedie pieghevole这种半对半错的组合。

第三类是撇号。qual'è、po（缺撇号）、l'后面多一个空格，这三种错在机翻结果里出现频率高得惊人，而且拼写检查工具不一定报。

验收时把这三类单独列成检查项，比笼统地说请检查语法有效得多。保哥的经验是给审校人一张只有三行的检查表，回收质量比给一张三十行的清单高。

## 竞争稀薄到底稀薄在哪，怎么量化？

意大利市场在欧洲主要语种里属于搜索量中等、竞争密度偏低的那一档。稀薄不是没人做，是做得认真的人少。

量化方法用三个观察点：搜索结果首页里有几个是真正的本地站，有几个是明显机翻的国际站，有没有大平台把位置占死。三个数字凑起来就能判断这个词值不值得投。

本地站多说明这块竞争已经成熟，进去要拼内容深度；机翻站多说明门槛还没建起来，认真做内容能快速吃下位置；大平台把首页占满的品类，直接跳过。

户外家具在当时属于第二种，首页上一堆结构松散、语法带错的国际站。这类品类的窗口期通常在一到两年，晚进就没这个便宜了。

## 意大利市场值不值得单开一套内容？

看三件事：品类跟当地生活方式对不对路、客单价扛不扛得住物流成本、有没有人能做本地审校。

户外家具三条都过关。意大利人对露台和庭院的投入意愿高，客单价撑得住跨境物流，本地母语人才也不难找。

不太合适的是那些强依赖本地服务的品类，以及需要频繁客服往来的高复杂度产品。语言只解决被搜到的问题，解决不了售后跟不上的问题。

预算上给一个粗略的分配建议：翻译占三成，本地词表建设占三成，模板改造占两成，剩下两成留给审校和上线后的迭代。词表和模板这两块是最容易被砍掉的，也是砍掉后最容易返工的。

## 内链的锚文本在意大利语里会跟着变形吗？

会，而且比你以为的更频繁。锚文本要嵌进句子里读起来才自然，一嵌进去就要跟句子的语法环境保持一致，形态就动了。

举个例子，指向遮阳伞分类页的链接，出现在不同句子里可能是gli ombrelloni、degli ombrelloni、per gli ombrelloni三种样子。介词跟冠词还会缩合成一个词，di加gli变成degli，这在意大利语里是强制的。

处理办法是给每个链接目标准备一个锚文本变体池，池子里放三到五种形态，写作时按语境挑。不要为了统一锚文本硬塞主格形态，那样句子会读起来磕磕绊绊，反而不像人写的。

需要保持一致的不是字面，是概念。搜索引擎理解主题靠的是上下文语义，不是锚文本字符串完全相同。这一点在屈折程度高的语言上尤其重要，硬凑字面一致得不偿失。

## 面包屑和筛选器要不要跟着改性数？

要，但可以偷懒偷得聪明一点。面包屑里的每一级通常是分类名，分类名的形态在建站时就定死了，跟着走就行。

真正麻烦的是筛选器。筛选项是形容词，而形容词要跟当前分类的品类词保持一致。同一个筛选项pieghevole，挂在sedie下面要显示pieghevoli，挂在tavolo下面要显示pieghevole。

省事的做法是筛选项统一用中性表达。把可折叠这个筛选项写成con chiusura pieghevole（带折叠结构），介词短语不受性数影响，挂在哪个分类下都对。

这招在多语言站上很值钱：设计筛选器时优先选那些语法上不随上下文变化的表达方式，能一次性省掉一大堆语言的适配工作。

## 站内搜索日志在意大利语上该怎么读？

先看空结果查询，这是含金量最高的一块。空结果里通常混着三类东西：用了你没收录的同义词、用了不同的形态、拼写带撇号或重音差异。

第二看查询长度分布。意大利用户的查询平均比英语长一点，因为介词短语多，per esterni、da giardino这类结构会让词数上去。搜索框的匹配逻辑如果按整串比对，长查询的命中率会很难看。

第三看形态分布。把同一个概念的各种形态的查询次数拉出来，你会得到一张比任何工具都准的真实形态偏好表。这张表反过来指导分类页命名和标题模板。

这三样数据一个月就能攒够用的量，成本几乎为零，是小语种市场里性价比最高的一手信息来源。

## 母语审校要看的检查清单该列哪几条？

第一条，冠词跟名词的性别配不配。第二条，形容词跟名词的性数一不一致。第三条，撇号该有的有没有、不该有的有没有。

第四条，重音符号在词尾该标的标了没有，词中间有没有多余的重音符号。第五条，价格、日期、地址的格式对不对。第六条，第二人称用的是tu还是敬语形式，全站一不一致。

最后一条容易被忽略。意大利语的商业文案里用敬语形式Lei还是用tu，取决于品牌调性，但必须全站统一。一个页面用Lei一个页面用tu，读起来像两家公司。

把这六条做成一张表发给审校人，比说一句请检查一下语言质量有用得多。审校人拿到的越具体，回收的质量越稳定。

## 意大利语的关键词表要留几个字段？

至少八个。概念标识、词条形态、性别、单复数、词性、形态所属的概念组、搜索量、来源。

概念标识用来把同一概念的所有形态串起来，这是整张表的骨架。性别和单复数两个字段是模板渲染的输入，缺了它们模板就得靠猜。

来源这个字段建议保留，标明这条词是从工具来的、从站内搜索日志来的、还是从本地竞品抄来的。三种来源的可信度不一样，后期复盘时能省很多事。

做西班牙语和葡萄牙语时用的也是同一套结构，只是合并维度不同。葡萄牙语两个市场的词表做法 (https://zhangwenbao.com/portuguese-seo-brazil-portugal-two-markets-keyword.html)那篇里的字段设计可以直接拿来改改就用，罗曼语族这几门语言的表结构是通用的。

## 上线后头三个月该盯哪几个数？

第一个月盯收录和抓取，确认页面进得去索引、路径没问题。这一层跟语言无关，按常规做法查就行。

第二个月盯站内搜索的空结果率。这个数直接反映你的词表跟真实需求对不对得上，空结果率下不来，说明形态覆盖有洞。

第三个月开始盯分形态的排名。把同一概念的几种形态分开看排名，你会发现有些形态排得动、有些排不动，这个差异告诉你搜索引擎认为哪种形态是这个页面的主形态。

如果主形态跟你想要的不一致，改标题里的形态权重，别改整篇内容。保哥见过太多团队因为一个形态排不上去就整站重写，其实调一下标题模板就解决了。

## 常见问题解答

## 做意大利语站，能不能直接拿西班牙语的词表翻译过来用？

不能，最多只能拿来当结构参考。两门语言的词根确实像，但至少有三层差异让直译失效。第一层是性别不一样，同一个概念在两门语言里的性别可能相反，直接翻会把性数一致的规则全带错。第二层是常用词不重合，西班牙语里高频的barato在意大利语里根本不存在，得换成economico或者a buon prezzo。第三层是意图词的偏好不同，查评价这件事西班牙语市场常用opiniones，意大利这边recensioni的占比更高。可以复用的只有词表的结构和合并逻辑，也就是概念标识、形态字段、来源标记这套骨架。具体到每一条词的内容，老老实实重建一遍，用本地竞品的导航、帮助中心和站内搜索日志当语料，一个下午能抄出两三百个准确的意图词，比翻译快也比翻译准。

## 商品标题模板要改到什么程度才算够？

判断标准只有一条：模板输出的任意组合都必须在性和数上自洽。做到这一点要给品类字典加两个字段，性别和默认数，再把形容词按变化类型分组存好各自的形态。渲染时先读品类词的性数，再去取形容词的对应形态，这样组合出来的短语才不会出错。工作量看着吓人，实际上头部两三百个品类词覆盖了绝大部分流量，标注一两天能完成，形容词表是全站复用的，标一次长期有效。如果时间实在紧，有个折中方案：模板里干脆不放形容词，改用介词短语，比如da giardino、per esterni这类结构不随性数变化，挂在任何品类词后面都合法。代价是标题的信息量和差异化会下降一档，适合过渡期用，不适合长期用。

## 页面上的重音符号能不能省掉，反正手机用户都不打？

可见文本一律不能省，这是底线。用户不打重音是输入习惯的问题，跟拼写规范是两回事，页面上省掉重音在意大利读者眼里就是错字，而商品页和政策页恰恰是最需要信任感的地方，这点损失换不来任何搜索收益。正确的分工是三层各管一段：页面可见文本标注完整重音；站内搜索的查询和索引两边都先去重音再比对，用户打不打都能搜到；关键词表里把带重音和不带重音的写法归为一条，量相加后再排优先级。还有一个意大利特有的情况值得知道，意大利语键盘的主键区直接有六个重音字母键，不需要组合键，所以桌面端用户省略重音的比例比法语市场低不少，但手机端因为要长按才出重音，省略比例明显更高。做移动优先的品类，无重音写法的权重要往上调。

## 撇号在技术上到底要处理几层？

三层。第一层是字符归一，把弯撇号和直撇号统一成一种，查询和索引两边都做。这两个字符在编码里完全不同，用户打的几乎都是直撇号，而页面上经过排版处理的经常是弯撇号，不归一就永远对不上。第二层是分词，要让分词逻辑知道撇号是词边界，l后面接撇号再接名词的结构应该切成两个有意义的单元，而不是当成一个整词或者切出一个孤零零的字母。第三层是去撇号的备份索引，把撇号整个删掉再建一份索引，用户如果连撇号都没打也能命中。三层里第一层最便宜也最必须，半天工作量；第二层看你用的搜索组件是否原生支持；第三层是保险，可以放到二期。另外提醒一句，URL里不要保留撇号，转义之后是一串百分号编码，既难看又容易在分享时被截断。

## 意大利市场的搜索量看起来不大，还值得做吗？

值得，但要挑品类，并且要看你打算做到什么深度。这个市场的特点是搜索量中等而竞争密度偏低，稀薄不是因为没人做，是做得认真的人少。判断值不值得投有三个观察点：搜索结果首页有几个是真正的本地站，有几个是明显机翻的国际站，有没有大平台把位置全占死。本地站多说明竞争成熟，进去得拼内容深度；机翻站多说明门槛还没建立，认真做内容能较快拿到位置；大平台占满首页的品类直接跳过。适合早做的是跟当地生活方式贴合、客单价能覆盖跨境物流、又不强依赖本地售后服务的品类。还有一件事别忘了算进去：意大利有法定打折季，通常一月和七月各一轮，各大区开始日期不完全同步，围绕这两个时间点的搜索量会陡增，相关页面要提前三四周准备好。

## 词干还原能不能替代人工建词表？

不能，两者的职责根本不同。词干还原是给站内搜索兜底用的，作用是用户打了某个形态而你的索引里存的是另一个形态时，还能把结果找回来。它处理规则形态的准确率不错，把复数还原回词根、把形容词的几种形态归到一起都没问题。但它有两个明显的失手区域：一是不规则复数，比如那些为了保住读音在中间加了字母的词，算法会判成两个不同的词根；二是那些词根相同但概念不同的词，算法会错误地归并。更根本的问题是词表要解决的是概念层的事——哪些说法指的是同一件商品、哪个说法在当地更常用、哪个形态在搜索里量更大，这些判断词干还原一个都给不了。所以正确的分工是：词表靠人工按概念归类并标注来源，词干还原只在搜索匹配这一环做兜底。

## 模板里的形容词能不能干脆全砍掉？

短期可以，长期不建议。砍掉形容词改用介词短语确实能一次性绕开性数一致的全部麻烦，da giardino、per esterni、in alluminio这类结构不随品类词的性别和数变化，模板怎么拼都合法。这个方案适合上线初期抢时间，也适合那些品类词特别多、标注成本一时消化不了的站。但代价是实实在在的：标题的差异化会下降，同一个分类下的商品标题会长得越来越像，用户在搜索结果里分辨不出区别，点击率会受影响；同时你会丢掉一批带形容词的长尾查询，那部分量通常不小。折中的做法是分阶段：先用介词短语版本上线，同时按流量从高到低给品类词标性数，标完一批就切一批模板过去。三个月左右能把头部品类全部切完，剩下的长尾用介词短语版本长期兜着也不亏。

## 权威参考资料



## 荷兰语SEO省下的那份比利时预算，最后要拿佛兰芒市场的份额还回去

- URL：https://zhangwenbao.com/dutch-seo-netherlands-belgium-flemish-two-markets.html
- 分类：小语种SEO
- 发布：2009-11-05  |  更新：2026-07-25
- 摘要：讲荷兰语SEO实战：佛兰芒语是变体不是独立语言、比利时因法语接触产生的词汇分叉、词表按共用与分叉与独有三类拆、骨架一套与分叉页两套、复合词连写与模板拼接、拼写改革留下的新旧写法、通性中性怎么改形容词词尾、分离动词与问句语序、站内搜索三张同义词表、两国表单支付税率与节庆日历。
- 关键词：关键词研究,内容本地化,小语种SEO

> **TLDR**：摘要：荷兰和比利时说的是同一门语言，正字法也归同一家机构管，于是几乎所有团队都会做出同一个决定：一套荷兰语内容，两个国家共用。这个决定省下的预算，通常会在佛兰芒那一侧以份额的形式还回去。原因不在语法，在词汇——比利时那边因为长期跟法语接触，日常用词换了一大批，而这些词恰好集中在商品和服务上。这篇讲清楚：哪些词会分叉、词表该怎么按共用与分叉与独有三类拆、复合词连写为什么让模板拼出病句、两次拼写改革留下的新旧写法怎么处理、通性与中性怎么改掉标题里的形容词，以及两国的表单、支付、税率该怎么分开做。

> 摘要：荷兰和比利时说的是同一门语言，正字法也归同一家机构管，于是几乎所有团队都会做出同一个决定：一套荷兰语内容，两个国家共用。这个决定省下的预算，通常会在佛兰芒那一侧以份额的形式还回去。原因不在语法，在词汇——比利时那边因为长期跟法语接触，日常用词换了一大批，而这些词恰好集中在商品和服务上。这篇讲清楚：哪些词会分叉、词表该怎么按共用与分叉与独有三类拆、复合词连写为什么让模板拼出病句、两次拼写改革留下的新旧写法怎么处理、通性与中性怎么改掉标题里的形容词，以及两国的表单、支付、税率该怎么分开做。

一家做园艺用品的独立站，割草机、修枝剪、软管卷盘这几条线，德国市场做得不错。看荷兰和比利时加起来两千多万人、园艺渗透率高、客单价也体面，决定开荷兰语版本。

翻译按荷兰的标准荷兰语做，内容一套，两个国家共用，只在结账页按国家切了税率和运费。

半年后的数据很分裂：荷兰这边稳步上来了，比利时那边几乎没动。团队第一反应是比利时市场小、竞争更集中，直到有个安特卫普的合作方随口提了一句——你们网站上的词，读起来像荷兰人写给荷兰人看的。

这句话听着像客套，实际是诊断。比利时的荷兰语使用者能百分之百读懂荷兰的写法，但他们自己不这么打字。读得懂和会去搜，是两件事。

## 荷兰语和佛兰芒语，到底算不算两种语言？

不算。这是做这个市场前必须先摆正的一个认知。

佛兰芒语不是一门独立语言，它是荷兰语在比利时北部的地区变体。两国在1980年成立了共同的语言机构，正字法、词形、官方词表都归它统一发布，也就是说拼写规则两边完全一致。

但语言统一不等于用词统一。规则一样，词不一样——这才是做搜索的人真正要处理的问题。规则统一带来的好处是你不用维护两套语法和两套拼写检查；用词分叉带来的代价是你必须维护两套词表。

## 正字法统一了，为什么词汇还差这么多？

因为比利时那半边跟法语贴得太近。比利时是双语国家，南边说法语，布鲁塞尔双语并行，日常生活里两种语言长期交错，于是大量法语词直接进了当地的荷兰语口语，而且很多都是高频生活词。

概念 | 荷兰通用 | 比利时常用 | 来源 | 

冰箱 | koelkast | frigo | 法语 | 

卡车 | vrachtwagen | camion | 法语 | 

暖气 | verwarming | chauffage | 法语 | 

自行车 | fiets | velo | 法语 | 

果酱 | jam | confituur | 法语 | 

手机 | mobieltje | gsm | 缩写词 | 

还有一类不是从法语来的，纯粹是地区习惯，比如打扫在荷兰说schoonmaken，在比利时常说kuisen；想要或者有胃口，比利时那边有个很地道的词goesting，荷兰人基本不用。

这些词的分布有个规律，对选词非常有指导意义：越是日常、越是跟买卖和家务相关的词，分叉概率越高；越是专业术语和书面词，两边越一致。而电商的品类词，恰好压在分叉最密集的那一段上。

## 关键词表该怎么按三类拆？

把词表拆成三堆，这是整篇最关键的一个动作，也是能立刻改变投入产出的一步。

类别 | 特征 | 处理方式 | 

共用词 | 两地写法与用法一致 | 一套内容覆盖两地，占大头 | 

分叉词 | 同一概念两边说法不同 | 各自的落地页用各自的词，另一方在正文出现一次 | 

独有词 | 只有一边存在的概念 | 只给那一边做，不硬翻 | 

园艺这类品类的实际比例大概是：共用词占绝大多数，分叉词只占一小部分，但那一小部分往往是流量最集中的头部词。所以工作量不大，杠杆很大。

独有词最容易被漏掉。比如两国的垃圾分类制度、园艺废弃物的处理规定、以及跟当地法规绑定的服务，都是只在一边成立的概念，硬翻过去既没人搜也没人信。

## 一套内容两个市场，页面该做一套还是两套？

大多数情况下的答案是：骨架一套，分叉词那几十个页面做两套。全站复制成两份是典型的过度反应，成本翻倍而收益集中在很小一部分页面上。

操作上是这样的：站点结构按国家分成两个目录或两个域名，共用词的页面内容基本一致，分叉词的页面各写各的。共用页面之间会出现内容高度相似的情况，这时候用规范链接把它们指向同一个首选版本，就能避免两边互相争位置。

规范链接这个标记是2009年初刚推出来的，正好赶上，它解决的就是同一份内容出现在多个地址时该由谁代表的问题。至于同一门语言在多个国家该怎么整体排布，那是更上一层的架构话题，可以顺着同一门语言面向多个地区时的页面排布与重复内容处理 (https://zhangwenbao.com/international-seo-same-language-multi-region-en-us-gb-au-duplicate-content-hreflang.html)那条线单独去解。

## 复合词连写，为什么模板最容易拼错？

荷兰语跟德语一样，复合概念要连着写成一个词。园艺工具是tuingereedschap，修枝剪是snoeischaar，软管卷盘是tuinslanghaspel，中间都不留空格。

荷兰人给错误加空格这件事起了个专门的名字，直译过来叫英语病，因为它是被英语写法带偏的。这个词能成为一个流行说法，说明这类错误有多普遍。

而商品标题模板是这种病的头号传染源。模板的逻辑通常是把品类词和属性词用空格拼起来，在英语里天经地义，在荷兰语里就造出了一批本地人一眼看错的写法，而且是全站规模的。

## 怎么让模板不犯这个错

不要在模板层做拼接，要在字典层存成品。也就是说，属性字典里直接存tuinslanghaspel这样的完整复合词，模板取用时不再做二次组合。剩下那些实在需要动态拼的，用连字符而不是空格，虽然不算最规范，但至少不会被当成两个词。

复合词对选词本身的影响，德语那篇讲得更透，机制是一样的，可以对照着看德语复合词怎么把关键词拼成一个长单词 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)里的处理办法。

## 两次拼写改革留下的新旧写法怎么办？

这是荷兰语特有的一个坑，而且现在正处在余波期。

复合词中间要不要加一个字母n，规则被改过两轮。1995年那次调整了主要规则，2005年的新版又动了一批例外。结果是一大批常用词有了新旧两种写法，比如煎饼和蘑菇这类日常词，老一辈写的和现在词表里的不是一个样子。

对做搜索的人来说，这意味着同一个概念在几年内会有两条查询曲线，新写法在爬，旧写法在降但还没归零。园艺品类里的植物名和材料名尤其容易中招，因为它们大多是复合词。

处理办法很简单：页面上的可见文本一律用现行词表的写法，别为了流量去写旧拼法；同时把旧写法收进站内搜索的同义词表，并在正文里让它自然出现一次。等旧写法的量彻底衰减下去，再把这条清理掉。

## de和het，为什么会改掉标题里的形容词？

荷兰语的名词分两类，一类配定冠词de，一类配het。这个分类基本没有规律可循，只能查词表，而它会往外传染。

形容词的词尾要跟着冠词走。在het类名词前面用不定冠词时，形容词不加e；其他情况都加。所以同一个形容词，在两个名词前面写出来不一样。

这件事对内容影响不大，对模板影响很大。凡是要把形容词和名词拼成短语的地方——标题、筛选器标签、分类描述、促销文案——都必须知道名词属于哪一类。

落地方式是在商品分类的数据结构里加一个字段，标记这个品类词是de类还是het类，模板按这个字段选形容词的形态。字段填一次，后面所有拼接都受益，比事后一个个改页面便宜太多。

## 复数和小称词会不会影响选词？

会，而且影响的方向可能和直觉相反。

荷兰语的复数主要有两种词尾，一种加en一种加s，哪个词用哪个也得查词表。园艺品类里的工具词绝大多数用en。

关键的一点是：商品类查询里复数形式往往比单数更常见，因为人买工具时脑子里想的是一类东西不是一件。所以分类页标题用复数通常更贴近真实查询，这跟很多人习惯性用单数的做法是反的。

小称词是另一个特点。荷兰语很爱在名词后面加一个小称词尾，表示小或者亲切，日常口语里用得极多。它会改变字符串，但在商品搜索里出现频率不高，除非你的品类本身就偏可爱路线。收进同义词表即可，不必单独做页面。

## 分离动词，怎么把长尾查询切成两半？

荷兰语有一类动词，前缀在句子里会被甩到句尾去。搭温室这个动作，原形是opzetten，放进一个实际句子里，前缀op就跑到最后面了。

这对信息类长尾查询的影响很直接。用户问怎么搭一个温室，打出来的查询里，动词是被拆开的两截，中间隔着好几个词。如果你的文章标题用的是不带拆分的原形，字面上就跟真实查询对不上。

解法是内容型页面的标题尽量用真实问句的语序，也就是让动词按口语的位置摆放，而不是照着词典原形写。这一条对园艺这种教程需求极旺的品类特别值钱，安装、修剪、越冬、施肥，全是分离动词。

## 变音符号该不该省？

不该省，但要做容错。荷兰语里有两种带点带撇的符号，作用完全不同。

两点的那个叫分音符，作用是告诉读者这两个元音要分开读，比如国家名België、协调coördinatie、聚会reünie。它是拼写的一部分，省掉就是错字。

带撇的那个来自法语借词，或者用来强调，比如表示数字一的één跟不定冠词een写法差一撇，读音和意思都不同。

用户在搜索框里经常不打这些符号，所以站内搜索必须做符号归一，查询和索引都把带符号的字符折成基础字母再比对；页面上的可见文本则一律保留正确写法。这两条不矛盾，是两个不同的层面。

## IJ为什么两个字母一起大写？

因为在荷兰语里它被当成一个整体。地名IJsselmeer开头是两个大写字母，不是打字打错了。人名和句首同理。

历史上它还有个合并成一个字符的写法，在编码表里也确实有独立的码位 (https://www.unicode.org/charts/PDF/U0100.pdf)，但现代文本基本不用了，用两个独立字母写才是常态。

这个特点会在两个地方咬人。一是自动首字母大写的程序，它只会把第一个字母变大写，输出Ijsselmeer，本地人一眼就觉得别扭。二是全大写的标题样式，那倒是碰巧不会错。

## 排序里的ij会排到哪去

看你用哪套规则。传统的荷兰语排序有把它当成y处理的做法，老式电话簿就是那么排的；而现代的默认排序一般把它当成两个普通字母。

两种都不算错，但同一个站里必须只用一种。品牌索引页和分类字母导航尤其要注意，如果数据库排序和前端展示用了不同规则，同一个词在两处会出现在不同位置，用户找不到。语言相关的排序规则在国际化标准里有按语言定义的排序数据 (https://www.unicode.org/reports/tr35/tr35-collation.html)，配置前对照一下能省很多事。

## URL里的变音符号怎么处理？

统一折成基础字母，别让带符号的字符进地址。

技术上它们可以进，只要经过百分号编码就行，但结果是地址变长、复制到聊天窗口里变成乱码串、有些老系统还会二次编码搞出双重转义。收益是可读性稍好一点，代价明显更大。

做法是在生成地址的那一步统一转换，België变belgie，coördinatie变coordinatie。这个转换规则要写死在一个地方，全站共用，不要让每个模块各自实现一遍，那是不一致的开始。

## 站内搜索该配哪几张同义词表？

荷兰语站的站内搜索至少要三张表，而且做完之后效果是立竿见影的。

表 | 内容 | 解决什么 | 

地区变体表 | frigo对koelkast这类两地说法 | 比利时用户搜不到东西 | 

拼写变体表 | 新旧两种复合词写法 | 改革余波期的查询 | 

符号折叠表 | 带分音符与重音的字符 | 用户不打符号 | 

三张表加起来的工作量大概三五天，但它直接决定了比利时用户进站之后能不能找到东西。前面那个园艺站的问题，一半出在词表，另一半就出在这里——用户搜了当地说法，站内返回空白，人就走了。

还有一条建议：把空结果查询单独做一份日报。那份名单基本就是你的分叉词清单，比任何工具给的数据都准，而且完全免费。

## 表单和地址字段两国有什么不同？

差别不小，照搬一套一定出问题。

字段 | 荷兰 | 比利时 | 

邮编 | 四位数字加两个字母 | 四位数字 | 

国际区号 | +31 | +32 | 

门牌 | 常带后缀字母 | 常带箱号 | 

标准税率 | 较低 | 较高 | 

邮编格式是最常翻车的一处：如果验证规则只按荷兰的格式写，比利时用户根本提交不了订单。验证必须按国家分支，不能用一套正则糊弄。

还有一个容易忽略的细节，荷兰的地址里姓氏前缀很常见，比如van、de、van der这一类，它们在排序和称呼上的处理方式跟主姓不同。客服系统按姓氏排序时经常把这批人全排到同一处去。

## 支付方式怎么影响转化和内容？

影响很大，而且两国用的根本不是同一套。

荷兰这边有一套银行间的在线支付方案，普及率高到几乎是默认选项，没有它的结账页会流失掉相当一部分订单。比利时那边主流的是本地的借记卡体系，习惯完全不同。

这跟语言有什么关系？关系在于支付方式的名字本身就是高频搜索词和信任信号。用户会搜某个支付方式加品类，也会在落地页上找那个熟悉的标识。两个市场的信任元素不一样，页面上的支付图标区就不该是同一份。

## 数字、价格和日期该怎么写？

两国基本一致，但跟英语习惯完全相反，这一条是全站规模的细节。

小数点用逗号，千位分隔用点，货币符号在数字前面并且通常跟一个空格。日期习惯写成日在前月在后，用连字符或点隔开。

价格展示还有一条：面向消费者的页面必须显示含税价，两国都是这个规矩，而且两国的标准税率不一样，比利时更高。如果你的价格模板是从德国站复制过来的，务必确认税率是按国家取的，不然利润会被悄悄吃掉一截。数字的具体写法约定，官方语言建议里关于数字与数词写法的条目 (https://taaladvies.net/conventies/cijfers-en-getallen)写得很细，做模板前值得让开发看一遍。

## 荷兰语文案会把界面撑长多少？

大约两成，个别按钮更多。复合词又长又不能断，是主要原因。

典型的受害者是导航栏、筛选器按钮和表格列头。英文写Add to cart刚好，荷兰语对应的短语明显更长，窄屏上很容易折行或者被截断。

处理方式有三条：给关键按钮准备一个短版文案；表格列头允许两行；禁止在复合词中间断行，宁可整体折下去。最后这条最重要，复合词被拦腰截断的观感比多占一行糟糕得多。

## 佛兰芒市场的内容语气要不要单独调？

要，但幅度比想象的小。

荷兰的商业文案风格直接、干脆，甚至有点不留情面，这在当地是效率的体现。比利时那边的表达普遍更委婉一些，直译的荷兰式文案会显得有点冲。

具体到操作层面，需要改的主要是三处：促销文案的语气、称呼的正式程度、客服话术。产品描述和技术参数这类文本几乎不用动，改动量集中在有情绪色彩的部分，占全站文案的一小块。

顺带说一句，别把这件事外包给同一个译者兼做。找一个当地人各审一遍，成本很低，效果比什么都实在。

## 域名该用 .nl还是 .be？

预算够就两个都要，预算紧就先要一个再用目录分市场。

本地国家后缀在两国都有明确的信任加成，尤其在比利时，用户对本地后缀的偏好挺明显。而且这两个后缀的注册门槛都不高，不像某些国家要求本地实体。

但要提醒一句：两个域名意味着两套权重要分别积累。对刚起步的站来说，把力气分成两份未必划算，用一个域名加国家目录起步、跑通之后再拆，通常更稳。这属于架构层的取舍，跟语言无关。

## 比利时还有法语区，那半边怎么办？

不能忽略，比利时说法语的人口占比不小，布鲁塞尔更是双语区。

但要清楚一点：那不是荷兰语项目的延伸，是一个独立的法语市场。比利时法语跟法国法语之间也有自己的词汇差异，数字的说法就是最有名的一处不同。

实操上的建议是先把荷兰语这一侧的两个市场跑通，再评估要不要开法语版本。法语那边的选词和地区变体问题，跟法语重音符号与地区变体的选词处理 (https://zhangwenbao.com/french-seo-accents-quebec-keyword-variants.html)里讲的是同一类问题，方法可以直接迁移。

## 荷兰人英语那么好，还要不要做荷兰语？

要，而且这条反直觉的判断值得单独说。

荷兰是全球非英语母语国家里英语水平最高的之一，很多人下意识觉得英文站就够了。数据上确实能看到不少英文查询，但那些查询集中在信息类和技术类，越靠近成交，母语查询的比例越高。

道理不难理解：了解一个概念时用英语没有障碍，掏钱的时候人会退回到母语的舒适区，因为要看清楚退货条款、保修范围和收货时间。园艺这类需要看清材质和尺寸的品类，尤其明显。

保哥的经验是，英文站在荷兰能接住一部分需求，但接不住转化最好的那一部分。把预算全押在英文上，等于主动放弃了漏斗最底下那一段。

## 关键词工具的数据能不能分开两地看？

能，但要动手设置，而且默认设置几乎肯定是错的。

主流工具的语言维度里，荷兰语通常只有一个选项，不区分国家；而国家维度是单独的。只选语言不选国家，拿到的是两国合并的数字，分叉词的信号会被抹平。

正确做法是按国家分别跑两遍，同一批种子词各出一份数据，然后做差集。差得大的那些词，就是你的分叉词候选，比靠语感猜准得多。

数据量小的品类可能两边都没多少数据，这时候回到那三个土办法：看本地竞品用什么词、看自己的站内搜索日志、找当地人做一轮说法采集。这三招的成本都不高，覆盖头部几十个词绰绰有余。

## 荷兰语的问句型查询长什么样？

荷兰语用户搜信息类内容有一批固定搭配，把它们收进词表，等于拿到了一张内容选题地图。

词 | 意思 | 典型组合 | 

hoe | 怎么 | hoe snoei je een haag | 

beste | 最好的 | beste grasmaaier | 

ervaringen | 使用体验 | ervaringen tuinslang | 

vergelijken | 对比 | grasmaaiers vergelijken | 

prijs | 价格 | snoeischaar prijs | 

kopen | 购买 | tuingereedschap kopen | 

注意hoe那一行的语序：动词跟主语的位置跟英语不一样，而且如果碰上分离动词，前缀还会跑到句尾。照着英语语序拼出来的问句标题，字面上就跟真实查询对不上。

还有一个荷兰语特有的现象值得利用：比较级和最高级用得非常多，beste这个词在商品类查询里的密度高得惊人。做榜单型和对比型内容，在这两个市场的回报比平均水平更高。

## 节庆和季节词，两国是同一套吗？

不是，而且这条差异会直接打乱你的内容日历。

最典型的是冬季那个送礼节日，荷兰过的是12月5日的晚上，比利时过的是12月6日当天，而且两国的礼物习惯和消费高峰也不完全重合。如果你的促销页按一个日期排，另一个市场就会错过窗口。

园艺品类对季节更敏感。播种、修剪、越冬、开园这几个动作的时间点跟纬度和气候绑定，两国差异不大，但说法上有分叉，而且当地人用的是很具体的时令词而不是月份。内容日历按当地时令词排，比按月份排更贴近真实查询。

操作建议是把季节词单独建一张表，标明每个词的活跃窗口，提前六到八周上内容。这个提前量在园艺上尤其关键，用户是先查怎么做，隔一段时间才买工具的。

## 英语借词进了荷兰语会变成什么样？

会被完全本地化改造，而且改造得很彻底，这是荷兰语一个很有意思的特点。

英语动词进来之后会按荷兰语的规则变位，直接长出荷兰语的词尾，过去式和过去分词也照着本地规则拼。名词进来之后复数通常跟着英语加s，但也有跟本地规则的。

对选词的影响是：同一个外来概念可能同时存在英语原形、荷兰语化形态和本地词三种写法，三种都有量。处理方式跟同义词一样，选一个当主词，其余进同义词表和正文。

## 品牌名后面那个撇号

荷兰语的所有格用撇号加s，而且当名词以元音结尾时，加复数s之前也要写撇号。品牌名以元音结尾的情况很常见，页面上写不写这个撇号，本地人一眼能看出来。

站内搜索这一侧要做容错，把带撇号和不带撇号的写法归一到同一个目标，因为用户在手机上打字经常省略。地址里则一律去掉，跟符号折叠规则一起处理。

## 筛选器和面包屑该用单数还是复数？

分类名用复数，属性值用单数，这是最贴近本地习惯的一套约定。

分类页讲的是一类商品，荷兰语里自然用复数；属性值是对单件商品的描述，用单数。混着来虽然不至于看不懂，但会让筛选面板显得没人管过。

更要紧的是这些文本会被模板拿去拼页面标题和描述，一旦单复数和冠词字段没配对，拼出来就是语法不通的短语。所以属性字典里最好把单数形态、复数形态、冠词类别三个字段一起存，模板按用途取。

还有一条实操经验：属性值里的颜色和材质词最容易出问题，因为它们在做形容词用的时候要变词尾，做名词用的时候不变。字典里把这两种用法分开存，比让模板临场判断可靠得多。

## 机器翻译在荷兰语上最容易犯哪三类错？

第一类是复合词加空格，也就是前面说的那个英语病。这一类最伤搜索，因为它直接把字符串改掉了。

第二类是冠词和形容词词尾不匹配，通性中性选错，读起来立刻能感觉出是外国人写的。

第三类是地区词混用，同一页里荷兰说法和比利时说法交替出现，因为训练语料两边的都有。这一类最阴，因为语法完全正确，只有本地人才看得出别扭。

这三条可以做成一张卡片发给内容团队，验收时对着扫一遍。机器翻译当初稿工具没问题，问题只出在直接发布上。

## 母语审校要不要分两地各找一个？

分叉词那部分要，其余部分不用。

具体安排是：主体内容找一个人做通稿审校，保证语法和风格统一；针对分叉词的落地页和促销文案，再找一个当地人过一遍。第二个人的工作量很小，但他能挑出的问题恰恰是最值钱的那一类。

给审校的清单最好带判据，五条就够：复合词是否连写、新旧拼法是否统一到现行写法、地区词是否与目标市场一致、冠词与形容词词尾是否匹配、数字与价格格式是否本地化。每条都能在几秒内判定对错，产出立刻从模糊的读着别扭变成可执行的修改项。

## 两个市场该按什么顺序投？

先荷兰，后比利时，但比利时要在一开始就留好接口。

理由是荷兰的市场规模更大、数据更全、工具支持更好，跑通的速度快。但如果一开始就把站点结构写死成单国模式，后面要加比利时会很难受，表单、税率、支付、域名全要返工。

所以正确的姿势是：结构上按两国设计，内容上先只做一国。国家字段、税率配置、地址验证、支付通道这些都预留成可配置的，内容先集中在荷兰跑，等模型跑通再补比利时的分叉词页面。

这种一门语言横跨两个市场的问题，葡萄牙语那边的表现更极端，两地连正字法都动过刀，处理思路可以对照葡萄牙语在巴西和葡萄牙两个市场的选词分野 (https://zhangwenbao.com/portuguese-seo-brazil-portugal-two-markets-keyword.html)那一篇，同一套方法论在荷兰语上适用度很高。

## 图片的文件名和替代文本该怎么写？

文件名折成基础字母、全小写、用连字符分隔，跟地址的规则保持一致。带分音符的字符和大写的合体字母进文件名，在跨系统同步时最容易出岔子。

替代文本则相反，要写成规范的荷兰语，复合词连写不加空格。这里有个常被忽略的点：分叉词在替代文本里也要跟着页面所属的市场走，比利时那套页面上的图片，替代文本用的应该是当地说法。

如果两地页面共用同一批图片资源，那就把替代文本从图片资产里剥离出来，做成跟着页面语言变量走的字段。图片文件共用没问题，文字必须分开，这个边界划清楚就不会乱。

## 上线前的语言层检查清单

把这篇压成可执行的动作，大概是十条：

检查项 | 怎么判定 | 

词表三分 | 共用、分叉、独有是否已拆开并标记 | 

分叉词页面 | 头部分叉词是否两地各有落地页 | 

复合词 | 字典里是否存成品，模板是否不再拼空格 | 

新旧拼法 | 可见文本是否统一到现行词表写法 | 

冠词字段 | 品类词是否标记了通性还是中性 | 

符号处理 | 页面保留符号、搜索折叠符号、地址去符号 | 

站内搜索 | 三张同义词表是否上线，空结果是否在监控 | 

表单 | 邮编、电话、门牌是否按国家分支验证 | 

支付与税率 | 是否按国家取值，图标区是否分开 | 

排序 | 索引页的ij规则是否全站一致 | 

这十条里回报最快的是第一条和第七条。前者决定你的预算花在了对的词上，后者直接把比利时用户的空手而归率压下去，两件事加起来一周内能做完。

## 常见问题解答

## 荷兰和比利时到底该不该做两套内容？

骨架一套，分叉词那部分做两套，这是性价比最高的方案。全站复制两份是过度反应，成本翻倍而收益只集中在很小一部分页面上；完全共用一套则会在比利时那边持续丢份额，因为头部品类词恰好是分叉最密集的地方。具体做法是先把词表按共用、分叉、独有三类拆开，共用词的页面写一份，通过站点结构分发给两个国家，页面之间用规范链接指明首选版本，避免互相争位置；分叉词各写各的落地页，用各自市场的说法做标题和主标题，另一方的说法在正文里自然出现一次；独有概念只给存在那个概念的市场做，不要硬翻。按这个分法，实际需要单独写的页面通常只占全站的很小一部分，但它们承载的流量比例会高得多。判断哪些词属于分叉，最可靠的数据来源是按国家分别跑一遍关键词工具再做差集，其次是自己的站内搜索日志。

## 比利时用户搜的词，用荷兰的说法能不能被搜到？

能被搜到一部分，但拿不到最好的位置。搜索引擎对同义词有一定理解能力，页面用相近说法仍然可能被召回，但排在最前面的通常是标题和主标题里用了用户那个词的页面。更现实的问题在站内：用户带着当地说法进了你的站，站内搜索按字符串匹配，返回空结果，人就走了，这一段损失是完全由你自己造成的，也完全由你自己能修。所以优先级应该是先修站内搜索的同义词表，再去调页面标题。同义词表只要覆盖头部几十个分叉词就能解决绝大多数情况，工作量很小。另外一个信号常被忽略：把站内搜索里返回空结果的查询做成日报，那份名单基本就是一张现成的分叉词清单，比任何外部工具都准，因为它记录的是你自己的客户在你自己的品类里真实打出来的词。

## 复合词到底怎么防止模板拼错？

在字典层存成品，不要在模板层做拼接。属性字典和品类字典里直接存完整的复合词形态，模板取用的时候不再做二次组合，这样就从根上消除了加空格的机会。实在需要动态组合的场合，比如带尺寸或型号的长标题，用连字符连接而不是空格，虽然不是最规范的写法，但至少不会被当成两个独立的词。这件事的重要性容易被低估，因为单看一个页面只是一处小瑕疵，但模板是全站规模的，一个错误会复制到几千个页面上，而且本地用户对这类错误特别敏感，荷兰语里甚至有个专门的说法来指代它。落地时建议做一次全站扫描，把所有由模板生成的标题导出来，交给母语者扫一遍空格位置，一次能揪出绝大部分问题。

## 新旧两种拼写，页面上该用哪个？

一律用现行官方词表的写法，旧写法只进站内搜索的同义词表。理由是拼写规则被修订过之后，新写法会持续上升、旧写法持续衰减，页面按旧写法写等于把资产押在一条下行曲线上；而且用旧拼法在受过教育的读者眼里就是错别字，信任损失比那点搜索收益大得多。正确的处理是三步：可见文本统一到现行写法；站内搜索把旧写法映射到新写法，两边都能搜到；如果某个旧写法的量还很可观，让它在正文里自然出现一次，这样页面同时能被两种查询理解，又不牺牲规范性。过一两年再回头看数据，等旧写法的量降到可以忽略，就把同义词表里那条清理掉。顺带提醒，做批量替换的时候一定要小心，有些词的新旧差异只有一个字母，正则写宽了会误伤其他词，替换前后都要抽样比对。

## 荷兰人英语这么好，做英文站行不行？

能接住一部分需求，但接不住转化最好的那一部分。荷兰的英语水平在非英语母语国家里排在最前列，信息类和技术类查询确实有相当比例是英文的，所以英文内容不是白做。但越靠近成交，母语查询的占比越高，原因很实际：了解一个概念时用第二语言毫无障碍，掏钱之前人会本能地退回母语，因为要看清退货条款、保修范围、收货时间和材质说明。这个规律在需要看清参数的品类上尤其明显。所以合理的策略不是二选一，而是分工：技术类和概念类的内容可以英荷共存甚至先做英文，商品页、分类页、政策页、客服话术这些靠近决策的部分必须做母语。如果预算只够一边，那就先做母语，因为漏斗底部的价值密度更高。比利时那边这个问题更不用犹豫，英语普及度没有荷兰那么高。

## 两个国家的关键词数据怎么分开拿？

在工具里把语言和国家两个维度分开设置，然后按国家各跑一遍。这是最容易被忽略的一步：主流工具的语言选项里荷兰语通常只有一个，不区分国家，如果你只选了语言没有指定国家，拿到的就是两国合并的数字，分叉词的差异会被完全抹平，你会误以为两边搜的是同一批词。正确做法是同一批种子词按两个国家各导一份数据，然后做差集，差得大的那些就是分叉词候选，再拿给当地人确认一遍。如果你的品类在两边的数据量都很小，工具给不出有意义的数字，那就回到三个土办法：看本地竞品的标题用的是哪个词、看自己站内搜索日志里用户实际打的词、找几个当地人对同一件商品各写一遍名字，重合度最高的那个就是主写法。这三招覆盖头部几十个词足够了，长尾等数据攒起来再补。

## 比利时的法语区要不要一起做？

要做，但要当成一个独立项目排期，不要当成荷兰语项目的附赠品。比利时说法语的人口占比不小，布鲁塞尔还是双语区，从市场规模上讲不能忽略。但那一侧需要的是完整的一套法语内容，包括选词、文案、客服和政策页，而且比利时法语跟法国法语之间也有自己的地区差异，最有名的就是几个数字的说法完全不同，直接拿法国的内容过来同样会有本地感缺失的问题。实操上的建议是先把荷兰语这一侧的两个市场跑通，把结构、表单、支付、税率这些跟国家绑定的东西全部做成可配置的，再评估法语版本的投入产出。这样做的好处是第二个语言版本上线时，基础设施已经就绪，只需要补内容，速度会快很多。反过来如果一开始就三个市场齐头并进，很容易每个都做得半生不熟。

## 没有荷兰语基础，怎么控制内容质量？

用一份带判据的检查表代替语感，每条都要能在几秒内判定对错。建议五到七条：复合词是否连写没有多余空格；拼写是否统一到现行官方词表的写法；地区词是否与目标市场一致，同一页里没有混用；冠词与形容词词尾是否匹配；数字、价格、日期是否按本地格式；表单字段是否按国家分支；页面上的带符号字符是否保留完整。把这份表交给外部审校，产出立刻从模糊的读起来有点怪，变成一份可执行的修改清单。另外强烈建议配一个持续性的动作：每周导一次站内搜索的空结果查询，那份名单不需要懂荷兰语也能看出问题，凡是有量但返回空白的查询，要么是你的词写错了，要么是同义词表没配，逐条修过去，三个月下来站内的匹配率和转化都会有肉眼可见的改善。

## 权威参考资料



## 日语SEO怎么选词？汉字、平假名、片假名不是同一批人在搜

- URL：https://zhangwenbao.com/japanese-seo-hiragana-katakana-kanji-keyword-notation.html
- 分类：小语种SEO
- 发布：2009-09-14  |  更新：2026-07-24
- 摘要：讲日语SEO关键词实战：汉字与平假名及片假名的语感分工、表记摇摆与送假名统一、片假名长音符号取舍、全角半角与半角片假名禁区、日文新字体与中日同形异义、输入法误转换带来的长尾、罗马字slug与价格单位写法。
- 关键词：关键词研究,内容本地化,小语种SEO,日语SEO

> **TLDR**：摘要：日语最麻烦的地方在于，同一个意思往往有三种合法写法：汉字、平假名、片假名，三者在搜索框里是三个不同的字符串，搜索量能差出一个数量级。再加上片假名长音符号写不写、全角半角混用、日文汉字跟中文字形不一样，一份从中文或英文翻过来的日语关键词表，通常有小半是查不到量的死词。这篇不讲搜索引擎怎么排名，只讲语言这一层：三套文字怎么分工、表记摇摆怎么归并、哪些写法碰都不能碰，以及日语选词唯一可靠的验证动作是什么。

> 摘要：日语最麻烦的地方在于，同一个意思往往有三种合法写法：汉字、平假名、片假名，三者在搜索框里是三个不同的字符串，搜索量能差出一个数量级。再加上片假名长音符号写不写、全角半角混用、日文汉字跟中文字形不一样，一份从中文或英文翻过来的日语关键词表，通常有小半是查不到量的死词。这篇不讲搜索引擎怎么排名，只讲语言这一层：三套文字怎么分工、表记摇摆怎么归并、哪些写法碰都不能碰，以及日语选词唯一可靠的验证动作是什么。

先讲个真实的开局。一个做护肤品的品牌要进日本，产品线里有一款卸妆油，中文站叫卸妆油，翻译交回来写的是 クレンジングオイル，页面标题、H标签、商品名全用了这个词。上线三个月，这个词的排名爬得还行，可转化一直上不来。

后来把搜索词报告拉出来看，进站的人有相当一部分搜的是 クレンジング 加上肤质或诉求，而买得最狠的那批人，搜的其实是 メイク落とし。这两个词在中文里都译作卸妆，在日语里却是两个使用场景不同、人群也不同的词。翻译没错，但选词错了，这是日语市场最常见的开局姿势。

## 日语一句话里混着三套文字，关键词该写成哪一套？

日语的书写系统同时用三套文字，一句普通句子里三套全都会出现。汉字承担实词和概念，平假名负责助词、词尾这些语法零件以及和语词，片假名主要装外来语、拟声拟态词和需要突出的部分。有些场合还会混进罗马字，勉强算第四套。

对写文章的人来说这只是常识，对做关键词的人来说这是个大坑：同一个概念常常有两到三种合法写法，而搜索引擎在关键词层面把它们当成不同的字符串统计。卸妆这件事可以写成 メイク落とし，也可以写成 クレンジング，前者是和语加汉字的组合，后者是外来语，两个词都对，用的人却不是同一批。

## 三套文字各自带着什么样的语感

这套分工不是随机的，它带着相当稳定的语感差异，直接对应不同的搜索意图。

文字类型 | 典型用途 | 语感 | 常见搜索意图 | 

汉字 | 概念、专业术语、正式表述 | 硬、正式、信息密度高 | 专业查询、B2B、规格 | 

片假名 | 外来语、品牌、时尚概念 | 新、洋气、商业感强 | 购买、品类浏览 | 

平假名 | 和语词、柔和表述 | 软、亲切、口语 | 入门问题、面向女性的内容 | 

罗马字 | 品牌名、缩写 | 国际感 | 品牌词、直接找官网 | 

护肤品类里这个差异特别明显。写成 保湿 的内容偏成分与功效解释，写成 モイスチャー 的更像广告文案，写成 うるおい 的多出现在面向大众的柔性内容里。三个词说的是同一件事，落地页却不该是同一个。

## 外国品牌名，该让日本人搜罗马字还是片假名

这是出海品牌进日本时第一个要拍板的语言决策，而且拍完很难改。一个外文品牌名进入日本市场，通常会同时存在两种形态：原文罗马字，以及一个片假名转写名。

两者的分工大致是这样：罗马字承接已经知道你的人，片假名承接从日语内容里第一次听说你的人。日本媒体报道外国品牌时习惯用片假名，用户看到之后回头搜的就是片假名；而看过你官网或者海外广告的人，搜的是罗马字。两条路的人都得接住。

麻烦在于片假名转写没有唯一答案，同一个外文名可能被转出好几种写法，而民间会自发形成一种最流行的叫法。这时候硬推自己定的官方写法往往推不动。稳妥策略是官方定一个主写法用于所有正式场合，同时在页面里让流行写法自然出现一次，比如在品牌介绍段落里提一句，既不牺牲统一性也接住了流量。

还有个常被忽略的细节：片假名品牌名最好尽早确定并注册，不然等市场自己叫出个名字来，你再想改就是跟用户习惯作对了。

## 表记摇摆是日语SEO绕不开的第一个概念

日语里管这种同一个词多种写法的现象叫表记摇摆，日文写作 表記ゆれ。它不只是三套文字之间的摇摆，还包括送假名加不加、数字用阿拉伯还是汉字、外来语拼法不统一等等。

为什么它对SEO重要？因为摇摆会同时伤两头。对外，你可能压根没覆盖到用户实际输入的那种写法；对内，同一批内容用了几种不同写法，站内的主题信号会被打散。日本本土的SEO讨论里，表记统一被当成基础功课来讲，不是可选项。

## 送假名写不写全，同一个词能写出三种样子

还有一类摇摆藏得更深，叫送假名，指的是汉字后面跟的那部分假名词尾。同一个动作名词，申込、申込み、申し込み三种写法都合法，公文倾向写全，商业场合倾向省略，网页上三种都能见到。

这类摇摆的杀伤力在于它太不起眼。一个站里表单按钮写 申込、导航写 申し込み、说明文里写 申込み，读者未必察觉，但站内的主题信号确实被打散了。日语内容规范里通常会专门定一份送假名规则表，就是为了收掉这种损耗。

做法上不必纠结哪种更正确，选一种写进内容规范然后全站执行即可。要注意的是核心关键词的写法应该跟着搜索量走，导航和按钮这类功能文案则以简洁为先，两者不一致时以关键词那边为准。

## 片假名的长音符号写不写，会变成两个关键词吗？

这是日语选词里最容易翻车、也最有意思的一个细节。外来语转写成片假名时，词尾那个长音符号有时写有时不写：サーバー 和 サーバ 都指服务器，コンピューター 和 コンピュータ 都指计算机。

两种写法都不算错，来源不同而已。日本文化厅关于外来语表记的留意事项 (https://www.bunka.go.jp/kokugo_nihongo/sisaku/joho/joho/kijun/naikaku/gairai/honbun06.html)里就专门列了长音符号的处理条目，说明这一层本身存在多种被认可的写法，而不是有唯一正确答案。

## 业界惯例和大众习惯，经常是反着的

实操中有个很稳定的规律：技术和工业领域倾向省略词尾长音，一般消费者倾向加上。工程文档里写 サーバ、プリンタ、コンピュータ，普通人搜索时打的却是 サーバー、プリンター、コンピューター。

这意味着面向不同人群的页面，主词的写法可能要反过来选。做面向工程师的B2B内容，用省略长音的写法更贴行业语感；做电商商品页，加长音的写法搜索量通常明显更高。选错了不会被判错，但会持续损失流量，而且很难在报表里被发现，因为你只会看到自己那个词的数据。

## 怎么定夺用哪一种

方法很朴素：两种写法各查一次搜索量，再各搜一次看结果页。如果两边前十名高度重合，说明搜索引擎已经把它们判成同一件事，挑量大的写；如果结果页明显不同，那就是两拨人，得分开做。

确定主写法之后，站内要统一。正文里没必要把两种写法都硬塞一遍，那是老式的堆词做法，日语读者对这种文字很敏感。真要兼顾，让另一种写法自然出现在用户评价、问答这类区块里，比作者自己塞进正文干净得多。

## 全角和半角混着用，搜索引擎会当成一回事吗？

搜索这一侧基本不用担心，全角半角、大小写的差异在查询处理阶段会被归一化，写成 ＳＥＯ 还是SEO，搜出来的结果几乎一样。真正会出事的是别的地方。

这套宽度概念本身是有标准的。Unicode关于东亚字符宽度的标准附件 (https://www.unicode.org/reports/tr11/)把字符分成宽、全角、半角、窄、模糊、中性几类，其中汉字和假名属于宽字符，ASCII属于窄字符，还有一类模糊字符在东亚文本里显示为宽、在其他语境里显示为窄。这一类是最容易埋雷的。

## 半角片假名是唯一必须彻底避开的写法

有一种叫半角片假名的字符，长这样：ｶﾀｶﾅ。它是早年为了省空间留下的兼容产物，在现代网页里没有任何使用理由。它会带来编码转换问题、复制粘贴异常、排版错乱，某些系统处理时还会直接变成乱码。

商品数据、CSV导入、后台字段里最容易混进半角片假名，因为源头往往是某个老旧的ERP或者POS系统导出的文件。做日语站的第一次数据清洗，把半角片假名统一转成全角，是性价比最高的一步。

## 数字和标点的宽度，影响的是可读性和数据质量

数字有三种写法：1年、１年、一年。搜索层面差异不大，但混着用会让商品列表和规格表看起来很脏，也会让基于字符串的筛选和排序出错。日语网页的通行做法是阿拉伯数字用半角，句读点用日文全角，英文单词和数字保持半角。

标点也一样。日语用的句点和逗号跟中文形状接近但编码不同，混排时容易出现宽度不一致的视觉跳动。这类问题在移动端尤其显眼，而日本用户对页面细节的挑剔程度，比多数市场都高一截。

## 日语不用空格分词，搜索引擎怎么切词？

日语句子里词与词之间不加空格，机器要先把连续字符串切成词才能索引，这个环节叫形态素解析。三套文字在这里意外地帮了忙：文字种类切换本身就是很强的边界信号，汉字后面接平假名助词、片假名词串接汉字，这些切换点通常就是词的边界。

所以日语的分词准确率整体比同样不用空格的泰语要高。但也有它专属的麻烦：长串片假名复合词最容易切错，因为中间没有文字种类变化。像 スキンケアアイテム 这种，机器要判断在哪儿断开，靠的是词典而不是形式线索，词典里没有的新造词就容易被切碎。

## 标题里到底要不要加空格

日语标题里可以插半角空格来分隔意群，这在电商商品名里很常见。要不要加，取决于你在优化什么。

加空格能让长标题更好读，也降低了机器切错词的概率；不加空格更接近自然日语书写，正式内容里更得体。折中做法是商品名、列表页标题这类信息密集的地方适当用空格分隔，文章标题保持自然书写。另外要注意加的应该是半角空格，全角空格在部分环境下会被当成普通字符处理，导致匹配意外。

## 为什么日语标题能塞下比英语更多的信息

汉字的信息密度高，同样的显示宽度里，日语能表达的内容比英语多。这带来一个实际差异：日语的标题标签常常写得比英语版本更长、信息更全，把品类、规格、卖点、品牌一路排下来，读者也不觉得堆砌。

不过显示长度是按像素算的，而汉字和假名属于宽字符，一个字占的宽度是ASCII的两倍。所以字符数看着不多，实际早就超了。日语标题最好直接用能预览宽度的工具确认，别靠数字符，这一点跟保哥在德语复合词与变音符号的选词实战 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)里遇到的长复合词截断问题，本质是同一件事的两种表现。

## 用户实际打出来的词，为什么跟你想的不一样？

日语有个别的语言没有的中间环节：绝大多数人打字时先输入罗马字，系统转成假名，再由输入法把假名转换成汉字。用户最终提交给搜索框的那个字符串，是这条转换链的产物，而不是他脑子里想的那个词。

这条链上每一环都会改变结果。输入法的候选词排序、预测补全、以及用户懒得翻页就选了第一个候选，共同决定了实际被搜索的写法。做日语关键词时如果只考虑正确写法，会漏掉相当大一块真实流量。

## 转换出错的写法，也是有搜索量的

日语同音字极多，输入法选错汉字是家常便饭，日语里管这叫误转换。有些误转换出现得太频繁，本身就积累出了可观的搜索量，而且这类词往往竞争极低。

这不意味着你该把错字写进标题——那样会砸掉专业感。合理的用法是把高频误转换写法当成内容线索：它告诉你哪些词用户拿不准、哪些概念需要在页面里顺带解释一句。有些站会在页面里加一个小小的说明区块澄清正确写法，既服务了用户又自然覆盖到了这类查询。

## 预测补全会把长尾拉向特定形状

手机端日语输入依赖预测补全的程度非常高，因为打完整词太费劲。结果是移动端的搜索词分布跟桌面端不一样，更短、更依赖系统推荐的组合。

这带来一个实用推论：做日语移动端流量，要盯的是搜索建议里真实出现的组合，而不是你自己拼出来的长尾。搜索建议本身就是用户行为的沉淀，在日语里它比在英语里更接近真实输入，因为用户几乎不可能一个字一个字打完再搜。

## 假名输入和罗马字输入，会导致不同的错法

用罗马字输入的人和用假名键盘输入的人，打错的方式不一样。前者容易出现拼写层面的错误，后者容易出现相邻键的误触。这个差异对绝大多数站来说没必要深挖，但如果你的品类有大量专有名词或型号，值得把常见错法收集一遍。

做法可以很轻：把核心品牌词和型号在搜索框里分别打几种可能的错法，看有没有搜索建议弹出来。有建议就说明这个错法有真实使用量，可以在页面里做一句自然的兼容表述。这类工作在多语言市场关键词调研 (https://zhangwenbao.com/multilingual-keyword-research-cross-cultural-localization-query-language.html)里属于查询语言切换那一层，日语只是把它的收益放大了。

## 日语站的URL该用日文还是罗马字？

结论先说：用罗马字转写，别用日文原字。日文URL技术上完全可行，但代价大于收益。

日文字符进URL要经过百分号编码，一个三字词转出来能变成三十多个字符的编码串。地址栏里看着还好，复制到聊天工具、邮件、外部平台就经常被截断或者被错误解析；后台日志和数据表里看到的也是编码形式，排查问题时几乎不可读。日语词又普遍比英语词的编码更长，这个问题被放大得很明显。

## 罗马字转写有两套体系，选错会不一致

日语转罗马字有两套并行的规则。一套是黑本式，护照和路牌用的就是它，し写作shi、つ写作tsu、ふ写作fu；另一套是训令式，し写作si、つ写作tu、ふ写作hu。两套都不算错，但混着用会让URL结构看起来毫无章法。

面向国际的商业站建议统一用黑本式，因为它更接近英语母语者的直觉发音，外部引用和口头传播时不容易出错。关键不是选哪套，是选定之后全站不再变。

## 长音在罗马字里怎么处理

这是最容易不统一的地方。東京 可以写成tokyo、toukyou、tōkyō 三种形式，各有各的道理。URL场景下带音调符号的写法要排除，剩下的两种里，省略长音标记的写法可读性最好、外部传播最省事，多数商业站选它。

另外提醒一句：slug里不要出现下划线，用连字符分词；也别把整句话转成罗马字塞进URL，那样长得离谱还没人看得懂。取两三个核心词转写就够了。

## 日文汉字跟中文汉字不一样，直接沿用会出什么问题？

这是中文母语者做日语站最容易大意的地方。看着都是汉字，实际上字形、用法、意思都可能对不上，而且错了非常显眼。

## 字形对不上：新字体不是简体也不是繁体

日本战后做过汉字整理，形成的一套字形叫新字体，跟中文的简体和繁体都不完全重合。経済 的経、駅、広、実、対、圧，这些字中文里都没有对应的相同写法。直接把简体中文页面丢给转换工具转成繁体再当日语用，出来的东西日本人一眼就知道不对。

更麻烦的是有些字看起来一样，实际编码不同，在字体渲染和字符串匹配时会出岔子。日语内容必须用日语输入法或日语语料产出，不能靠中文字形转换，这条没有变通余地。

## 日本自己造的汉字，中文里根本不存在

日语里有一批国字，是日本自造的汉字：峠（山口）、働（劳动）、畑（旱田）、込（进入）。这些字在中文语境里要么不存在要么含义完全不同，但在日语里是常用字，尤其 働 和 込 会大量出现在日常文案里。

## 同形异义词，是最阴险的一类

中日两边都有的词，意思却完全不同，这类词写进页面会造成实实在在的误解。

日语词 | 日语意思 | 中文里的意思 | 误用后果 | 

手紙 | 书信 | 厕纸 | 句子变得莫名其妙 | 

勉強 | 学习 | 不情愿 | 意思整个反过来 | 

愛人 | 情妇 | 配偶 | 严重冒犯 | 

丈夫 | 结实耐用 | 配偶 | 产品描述闹笑话 | 

清楚 | 清纯素雅 | 清晰 | 形容词用歪 | 

这几个还算好认，真正要命的是那些差得不远、看着通顺的词。所以日语内容的母语审校跟别的语言不太一样：它要挡的不只是语法错误，还有那些语法完全正确、意思偏了半米的句子。中文母语者自查这一关基本无效，因为看着都认识。

## 敬语和文体选错，会影响排名还是只影响转化？

直接说结论：不影响排名，但对转化的影响大到不能忽略，而且它决定了你的内容能不能被当成正经内容看。

## 两种文体不能混着用

日语书面文体主要有两套。です・ます体是礼貌体，用在面向读者说话的场合；だ・である体是断定体，用在论述、报告、说明类文本里。选哪个取决于内容类型，但同一篇文章里两种混用，在日本读者眼里是明显的低质量信号。

电商站和面向消费者的内容基本一律用礼貌体；技术白皮书、行业分析用断定体更合适。翻译外包时这一条必须写进需求单，否则不同译者交回来的稿子会各写各的。

## 敬语用过头，比不用还糟

日语敬语分尊敬语、谦让语、礼貌语三层，用错方向是常见错误：把该用谦让语的地方用了尊敬语，等于抬高自己贬低客户，读起来非常不舒服。还有一种是过度敬语，一句话里堆三层敬意，日本人自己都觉得别扭，网上有个专门的说法叫二重敬语。

对做站的人来说，把握一条就够：客服话术、政策页面、邮件模板这类直接对客户说话的文本，必须由母语者写或审，别让翻译工具决定敬意层级。商品描述和文章正文反而宽松些，礼貌体写通顺即可。

## 日语关键词研究该怎么做才不漏掉写法？

日语选词的核心动作，是把同一个概念的所有可能写法先铺开，再决定收敛到哪一个。这跟英语市场先找同义词再扩长尾的路子不太一样。

## 三套文字分别跑一遍搜索建议

拿到一个种子概念，先把汉字、平假名、片假名三种写法都写出来，每种分别去取搜索建议。这一步能暴露出你完全没想到的组合，比如某个概念在口语里其实用的是缩写形式。

全日本SEO协会关于关键词变化形的说明 (https://www.ajsa.or.jp/seo-chishiki/archives/keywordvariation.html)里点出了几类必须覆盖的变化：缩写形式、单复数、汉字与假名的写法差异、外文名称的假名转写。它特别提到搜索引擎虽然能识别一部分对应关系，但并不保证反向也成立，所以页面最好主动覆盖多种变化形。这条对日语尤其重要，因为缩写在日语里极其活跃。

## 缩写词是日语长尾里最活的一块

日语造缩写的能力很强，四个音节以上的外来语几乎都会被砍成两三个音节。这类缩写往往比原词的搜索量高得多，而且它们从来不会出现在翻译稿里，因为翻译的是完整词。

找缩写没有捷径，只能靠搜索建议、社区问答和真实用户评论去捞。日本的问答社区和评价平台是这方面的富矿，用户在那里用的是真实口语，跟商品页上的书面语差着一层。

## 日语搜索量数据，哪里会失真

日语的搜索量数字有个系统性问题：不同工具对表记摇摆的处理口径不一样。有的把汉字写法和假名写法合并统计，有的分开报，同一个概念在两个工具里能差出一倍以上，而工具通常不会告诉你它做了合并。

这带来的后果不是数字不准，而是决策方向会被带偏：如果工具悄悄把三种写法的量合并报给你，你会以为主词的机会很大，实际拆开之后每一种写法都竞争激烈且流量有限；反过来如果它分开报，你又可能低估了这个概念的整体需求，早早放弃。

对付办法跟别的语言一样，但在日语里必须做：拿两个工具的数字对照，差异大的词单独去结果页验证一次，看返回的是不是同一批站。另外别忘了日语有大量长尾藏在缩写和口语写法里，这些词工具报零的概率很高，判断它们值不值得做，看的是需求成不成立而不是数字。

## 把词表收敛成页面的时候，一个页面认一种写法

铺开是为了不漏，落地时要收敛。做法是每个页面认定一种主写法，标题、H标签、正文主线全部统一，其他写法只在自然语境里出现。同一个站里两个页面分别主打同概念的两种写法，是在自己跟自己抢，这种内耗在日语站里比英语站更容易发生，因为写法多。

## 日本市场的内容形态，跟英语市场差在哪？

语言做对了，内容形态不对照样白搭。日本用户对网页内容的期待跟欧美市场差异不小，这直接决定了页面该做多厚。

## 信息密度高的长页面反而受欢迎

欧美这几年流行简洁留白，日本市场的主流商业页面依然信息密集：规格表、对比表、注意事项、使用步骤，一路排下来。这不是审美落后，是用户真的会看，而且看不到会觉得这家不够认真。

落到SEO上的推论很直接：日语版页面通常需要比英文版写得更厚，砍掉的信息不是简洁是缺失。尤其是成分、规格、尺寸、产地、使用注意这类硬信息，在日本是购买决策的必要条件。

## 排行和口碑，是日语搜索里的高频修饰词

日语搜索词里有几个修饰词出现频率极高：おすすめ（推荐）、ランキング（排行）、口コミ（口碑评价）、比較（对比）。它们几乎可以跟任何品类词组合，构成大量高意图长尾。

这背后是一种很强的查证习惯：决定买之前先看别人怎么说，是日本消费者的默认动作。所以做日语站时，评价内容、对比内容、榜单类内容的价值，比在英语市场高一档。这类内容怎么和产品页分工、怎么避免互相蚕食，是日语站信息架构里最值得花时间的部分。

## 直译过来的内容，坏在语气而不是语法

把英文营销文案直译成日语，语法可能全对，读起来却处处别扭：形容词太满、承诺太硬、感叹号太多。日语商业文案的说服方式是克制的、留余地的，把话说死反而降低可信度。这套从翻译升级到本地再创作的流程，保哥在多语言内容本地化生产线 (https://zhangwenbao.com/multilingual-content-localization-production-pipeline-vs-translation.html)里拆过，日语只是把语气这一层的权重调得特别高。

## 价格、单位和日期怎么写，才不会让日本用户起疑？

这些细节看着琐碎，但它们是日本用户判断一个站是不是本地站的第一批线索，而且其中有一条是有法律要求的。

## 价格必须让人一眼看到实付金额

日本对面向消费者的价格标示有总额表示的要求，简单说就是标出来的价格要让消费者一眼看到最终要付多少钱，而不是只标不含税的本体价格再在结账时加一道。这不是行业惯例，是有明确规定的。

页面上常见的三个词要分清：税込是含税，税抜是不含税，本体価格指的是不含税的商品本身价格。稳妥做法是含税价用大字号做主展示，不含税价如果要标就放小字号做辅助，别反过来。用不含税价当主展示去显得便宜，在日本市场既不合规也很掉分。

货币符号也有讲究。日语页面里写 円 最自然，写 ¥ 也常见但更偏国际化语境，JPY一般只出现在跨境结算相关的位置。三种混着用会显得页面不是一个人做的。另外送料無料（免运费）和送料別（运费另计）这两个标识在日本电商里几乎是必备信息，藏起来会直接影响转化。

## 尺码和单位，照搬国际标准会出事

服装尺码是重灾区。日本的S、M、L跟欧美同名尺码不是一回事，普遍要小一到两号，直接把英文站的尺码表翻译过来，退货率会给你上一课。正确做法是提供日本尺码对照，并且把具体的厘米数标出来——日本消费者习惯看实际尺寸而不是字母。

还有一些日本独有的单位会出现在特定品类里：戒指用号、房间面积用帖或坪、纸张用日本自己的尺寸体系。做相关品类时这些单位不能省，因为用户就是按这个搜的。

## 日期和年号，写错就露馅

日期顺序是年月日，跟中文一致，这点不容易错。容易错的是年号：日本同时使用西历和本国年号，正式文件、政府相关内容里年号出现频率很高，商业内容则以西历为主。

另一个容易被忽略的是年度概念。日本的财年和学年都从4月开始，所以做促销日历、行业报告、季节性内容时，日本的年度节奏跟以1月或7月为起点的市场完全对不上。新生活シーズン这类围绕3到4月的需求高峰，在别的市场根本没有对应物，做日语内容日历时必须单独排。

## 日语站上线前该检查哪些语言层的东西？

把上面的东西压成一份按顺序过的清单：

检查项 | 看什么 | 不合格的表现 | 

主写法认定 | 每个核心概念定一种写法并全站统一 | 同站两页主打同概念不同写法 | 

长音符号 | 词尾长音写法与目标人群匹配 | 面向消费者却用工程写法 | 

半角片假名 | 全站零半角片假名 | 商品数据里混入 ｶﾀｶﾅ | 

数字与标点 | 阿拉伯数字半角、句读全角 | 全角半角混排 | 

汉字字形 | 日语新字体，非中文简繁转换 | 页面出现中文特有字形 | 

同形异义词 | 母语者逐条确认 | 用了中文含义的词 | 

文体统一 | 全站礼貌体或断定体二选一 | 同页混用 | 

敬语方向 | 客服与政策文本母语审校 | 尊敬语谦让语用反 | 

标题宽度 | 按像素预览而非数字符 | 结果页里标题被砍半 | 

这份清单里能靠工具跑的只有两三条，其余全是判断题。日语市场对不地道的容忍度是出了名的低，一个用错的敬语、一个中文字形，足以让读者判定这家公司不认真——而他们通常不会告诉你，只是不买。

回到开头那个卸妆油的例子。后来的动作很小：把商品页主词从 クレンジングオイル 换成 メイク落とし，同时保留一个以 クレンジング 为主词的品类页承接浏览型流量，两个页面的内容角度分开写，一个讲怎么选、一个讲这一款怎么用。词表没扩，页面没加，只是把两种写法背后的两拨人分清楚了。日语SEO的大部分收益，就藏在这种分清楚里。

顺带说一句，日本的搜索入口格局和引擎侧的排名机制是另一条线上的事，跟本文讲的语言层功课基本正交。想补那一半的，可以看Yahoo Japan SEO与日本搜索机制 (https://zhangwenbao.com/yahoo-japan-seo-overseas-japan-search-engine-mechanism.html)那篇，两边合起来才算把日本市场看全。

## 常见问题解答

## 同一个概念的汉字、平假名、片假名写法，能不能都写进同一个页面？

可以出现，但不能是硬塞。合理的做法是页面认定一种主写法，标题、H标签和正文主线全部用它，其他写法只在语义自然需要时出现，比如解释这个词的时候顺带提一句、或者出现在用户评价和问答区块里。刻意把三种写法在正文里各铺几遍，是老式堆词做法，日语读者对这种文字的敏感度很高，读起来会觉得这篇是机器生成的，反而伤害信任。判断标准很简单：如果去掉某一种写法，句子依然通顺自然，那它就是硬塞进去的。另外要提醒的是，如果两种写法在搜索结果页上返回的是完全不同的一批站，说明它们背后是两拨人、两种意图，这种情况不该挤在一个页面里解决，应该拆成两个页面各写各的角度，否则两边都做不深，还容易在站内互相抢排名。

## 片假名词尾的长音符号，到底加还是不加？

没有唯一正确答案，得按目标人群定。一个稳定的经验规律是技术和工业领域倾向省略词尾长音，写成 サーバ、プリンタ、コンピュータ；面向普通消费者的场合则倾向加上，写成 サーバー、プリンター、コンピューター。所以做面向工程师的技术内容，用省略写法更贴行业语感；做电商商品页和大众向内容，加长音的写法搜索量通常明显更高。定夺方法还是那两步：两种写法各查一次搜索量，再各搜一次看结果页前十名是否重合。重合度高就挑量大的那个写，不重合就说明是两拨人得分开做。定下主写法之后全站统一，别在同一个站里两个页面各用一种，那是自己跟自己抢排名。这个细节造成的流量损失很隐蔽，因为你的报表里只会显示自己用的那个词的数据，另一种写法的流量根本不会出现在视野里。

## 中文站的内容能不能靠繁简转换工具改成日语用？

不能，这条没有变通空间。日本战后做过汉字字形整理，形成的新字体跟中文的简体和繁体都不完全重合，経、駅、広、実、対、圧这些字都是日语独有的写法，中文的转换工具转不出来。更麻烦的是日语里还有一批日本自造的国字，比如峠、働、畑、込，这些在中文里要么不存在要么含义完全不同，而働和込在日常文案里出现频率非常高。除了字形，还有同形异义的陷阱：手紙在日语里是书信不是厕纸，勉強是学习不是不情愿，丈夫是结实耐用不是配偶。这类词写进商品描述里，轻则闹笑话重则冒犯客户。所以日语内容必须用日语输入法、由掌握日语的人产出，把中文当半成品去转换是行不通的。退一步说，就算字形全对，中文的行文节奏和敬意表达方式跟日语也完全不同，转换出来的东西日本读者一眼就能看出不对劲。

## 日语标题标签应该写多长？

按显示宽度算而不是按字符数算，这是日语站最容易踩的坑。汉字和假名在宽度分类里属于宽字符，一个字占的显示宽度是ASCII字符的两倍，所以字符数看起来不多，实际早就超出了结果页的显示范围。日语内容有个天然优势是信息密度高，同样的宽度里能表达的东西比英语多，所以日语标题往往可以把品类、规格、卖点排得比英文版更全，读者也不觉得堆砌，这个优势值得用足。但用足的前提是知道边界在哪，建议直接用能预览像素宽度的工具确认，别数字符。另外把最重要的词放在最前面，就算尾部被截断核心信息也已经出现了；品牌名放最后，必要时让它被截掉，损失比核心词被砍小得多。电商商品名可以适当用半角空格分隔意群，既好读也降低机器切词出错的概率，但要注意用半角空格，全角空格在某些环境下会被当成普通字符处理。

## 日语里的缩写词该怎么找出来？

日语造缩写的能力非常强，四个音节以上的外来语几乎都会被砍短，而这些缩写的搜索量往往比原词高得多。问题在于它们绝不会出现在翻译稿里，因为翻译交付的是完整规范的词。找它们没有自动化捷径，主要靠三个来源：一是搜索建议，输入词的前半部分看系统补全出什么；二是问答社区和评价平台，用户在那里打字用的是真实口语，跟商品页上的书面语差一层；三是社交平台上的话题标签，缩写在那里流通得最快。找到之后别急着用，先验证它是不是稳定的通用缩写而不是某个圈子的黑话，验证方法是搜一下看返回的结果是不是主流媒体和商业站点。确认之后，缩写词适合用来做内容页和长尾页面，正式的商品页和品类页通常还是用完整写法更稳妥，因为缩写在正式场合会显得不够郑重。

## 敬语和文体选错，搜索引擎会因此降低排名吗？

不会，排名系统不判断敬意层级，文体选择本身不构成排名因素。但它对结果的影响是通过用户行为绕回来的：文体混乱、敬语用反的页面，日本读者的第一反应是这家公司不专业，页面停留和转化都会掉，长期看排名也就跟着走弱。具体要注意两件事。第一是文体统一，です・ます体是礼貌体用于面向读者说话的场合，だ・である体是断定体用于论述说明类文本，选哪个看内容类型，但同一篇文章里混用是明显的低质量信号。第二是敬语方向，日语敬语分尊敬语、谦让语、礼貌语三层，把该用谦让语的地方用成尊敬语，等于抬高自己贬低客户，读起来非常刺耳；还有一种堆叠过度的二重敬语，日本人自己也觉得别扭。实操上抓住一条就够了：客服话术、政策条款、邮件模板这类直接对客户说话的文本，必须由母语者写或审，别交给翻译工具决定敬意层级；商品描述和文章正文相对宽松，礼貌体写通顺即可。

## 权威参考资料



## 葡萄牙语SEO像一件按巴西身材裁的衣服，穿到葡萄牙身上处处都紧

- URL：https://zhangwenbao.com/portuguese-seo-brazil-portugal-two-markets-keyword.html
- 分类：小语种SEO
- 发布：2008-12-16  |  更新：2026-07-25
- 摘要：讲葡萄牙语SEO实战：巴西与葡萄牙的体量和竞争差异、xícara与chávena这类词汇分叉、正字法协定过渡期里的新旧拼写取舍、称呼与语法习惯、变音符号在地址与数据库里的丢失、以ão结尾名词的三种复数形态、两地意图词与数字货币格式的差别，以及母语审校的验收清单。
- 关键词：关键词研究,SEO,小语种SEO

> **TLDR**：摘要：葡萄牙语的坑不在语法难，而在同一门语言被两个体量悬殊的市场各自养了几百年。巴西那边说tela、celular、ônibus，葡萄牙这边说ecrã、telemóvel、autocarro，翻译都对，但只有一边的人会那么搜。更麻烦的是明年起两地要开始换一套拼写规则，过渡期长达好几年，同一个词在网上会同时存在新旧两种写法。这篇把词汇分叉、拼写改革、语法习惯、变音符号在技术环节的丢失、站内搜索的失灵，还有两个市场该先做哪一个，一条条摊开讲。

> 摘要：葡萄牙语的坑不在语法难，而在同一门语言被两个体量悬殊的市场各自养了几百年。巴西那边说tela、celular、ônibus，葡萄牙这边说ecrã、telemóvel、autocarro，翻译都对，但只有一边的人会那么搜。更麻烦的是明年起两地要开始换一套拼写规则，过渡期长达好几年，同一个词在网上会同时存在新旧两种写法。这篇把词汇分叉、拼写改革、语法习惯、变音符号在技术环节的丢失、站内搜索的失灵，还有两个市场该先做哪一个，一条条摊开讲。

先讲一个真事。一家卖手冲咖啡器具的独立站，磨豆机、滤杯、手冲壶那一套，英语站做得不错，老板看巴西咖啡消费量大，决定上葡萄牙语版本。

找的是里斯本的译者，母语，资历漂亮，交付质量也确实没问题。上线三个月，葡萄牙那边零零星星有点单，巴西几乎没有动静，而巴西的流量本来应该是葡萄牙的十几倍。

问题出在一张分类页上。那页的标题写的是chávena，欧洲葡语里的咖啡杯。巴西人管这东西叫xícara，两个词长得完全不像，词源都不同。一个巴西人搜xícara，永远搜不到一个满页写着chávena的站。

这不是翻译错误，这是选错了市场的默认词。保哥这些年见过太多这类事故：内容一个字没写错，就是没人搜。

## 巴西和葡萄牙，到底算不算同一个市场？

语言上算一门，市场上完全不算一个。先把体量摊开看，这个悬殊程度决定了后面所有的取舍。

维度 | 巴西 | 葡萄牙 | 

使用人口量级 | 接近两亿 | 一千万出头 | 

互联网普及阶段 | 基数巨大、增速快 | 普及率高、盘子小 | 

电商成熟度 | 本土平台强势，分期付款文化根深 | 更接近西欧模式，跨境购买习惯成熟 | 

价格敏感度 | 高，分期与运费决定成交 | 中等，更看重交付时效 | 

竞争密度 | 本土玩家多，头部集中 | 竞争稀薄，但天花板低 | 

体量差二十倍，但难度也差二十倍。这就是做葡语市场最典型的两难：奔着巴西去，撞上一群本地强手；退守葡萄牙，做到第一名也就那么点量。

这个结构跟西班牙语那边高度相似，只是分叉的形状不同——西语是一个欧洲市场对二十来个拉美市场，葡语是一个欧洲市场对一个巨型市场。西班牙语两岸的关键词分叉 (https://zhangwenbao.com/spanish-seo-es-es-latam-keyword-divergence.html)那篇里的判断方法在这里几乎可以直接套用，区别只在于葡语不需要处理二十套地区变体，压力小很多。

更现实的做法是先想清楚你的品类归哪一边。客单价高、依赖跨境物流、目标人群是城市中产的品类，葡萄牙往往能更快回本；走量、靠价格取胜、能落地本地仓的品类，巴西才是主战场。咖啡器具这个案例后来选了巴西，因为那边的精品咖啡人群正在起来，而且愿意为器具花钱。

## 同一样东西，两边为什么叫不同的名字？

因为这两支葡语被大西洋隔开了五百年，各自吸收了不同的外来影响。巴西葡语吸收了大量原住民语言、非洲语言和后来的美式英语借词，欧洲葡语则更多受法语和本地传统影响。

结果就是一张相当长的分叉词表。下面这些是日常高频词，随便一个都能让整页内容错过目标市场。

中文 | 巴西这边说 | 葡萄牙这边说 | 

屏幕 | tela | ecrã | 

手机 | celular | telemóvel | 

公交车 | ônibus | autocarro | 

火车 | trem | comboio | 

卫生间 | banheiro | casa de banho | 

果汁 | suco | sumo | 

冰箱 | geladeira | frigorífico | 

文件（电脑里的） | arquivo | ficheiro | 

鼠标 | mouse | rato | 

西装 | terno | fato | 

卡车 | caminhão | camião | 

咖啡杯 | xícara | chávena | 

注意rato这一行。在巴西，rato是老鼠，就是那个动物；在葡萄牙，它同时也是电脑鼠标。一个卖外设的站如果照搬欧洲葡语，巴西读者看到的字面意思是这家店在卖老鼠。

这类词最阴险的地方在于，它们不会被审校抓出来。一个葡萄牙审校看chávena完全正确，一个巴西审校看xícara也完全正确，只有把两个人放到同一张桌子上，问题才会浮出来。

## 咖啡这个品类，分叉尤其密

做本地化的时候有个规律：越是日常、越是跟家庭生活绑得紧的品类，两地叫法分歧越大。咖啡正好踩在这个点上。

杯子是xícara对chávena，浓缩咖啡机在巴西常说máquina de espresso，葡萄牙那边máquina de café更自然；磨豆机巴西说moedor，葡萄牙也用moinho；小杯浓缩在葡萄牙就叫uma bica或者um café，你写espresso curto，本地人会觉得这是外国人在说话。

反过来讲，这也是机会。ecrã这个词在欧洲葡语词典里的释义与用法示例 (https://dicionario.priberam.org/ecr%C3%A3)能帮你判断一个词在哪一边算标准说法，把它当成起手的判据，比拍脑袋靠谱得多。这类词典查询是做葡语选词最便宜的一步。

## 明年开始的拼写改革，会把两套写法合并吗？

不会。这是本文最需要提前打的一针预防针。

1990年在里斯本签署的那份正字法协定，经过十几年的拉扯，终于要落地了。巴西那边已经完成了法定程序，从明年1月1日起正式施行，并且给了一段相当长的过渡期，新旧两套写法在过渡期内都算有效。葡萄牙这边的批准程序也在今年走完，同样留了多年过渡。

协定要改的主要是拼写，尤其是那些不发音的辅音字母。你可以到巴西颁布这份正字法协定的法令原文 (https://www.planalto.gov.br/ccivil_03/_ato2007-2010/2008/decreto/d6583.htm)里看条款和附件，里面把规则和例词列得很细。

## 改革改掉的是哪几类词？

类别 | 旧写法（欧洲葡语一侧） | 新写法 | 

不发音的c | acção、direcção、acto | ação、direção、ato | 

不发音的p | óptimo、baptismo、adopção | ótimo、batismo、adoção | 

分音符 | freqüência、lingüiça（巴西旧写） | frequência、linguiça | 

部分重音符号 | idéia、jibóia（巴西旧写） | ideia、jiboia | 

连字符规则 | anti-religioso等一批 | 规则调整，部分合并或拆开 | 

看出问题了吗？改革让部分词在两地趋同了，比如欧洲葡语的acção变成ação，跟巴西一致；但它一个字都没碰xícara和chávena这类词汇层面的分叉。

换句话说，拼写统一了，词还是两套。指望这次改革帮你省掉本地化工作的人，明年会失望。

## 过渡期里页面上该写哪一套？

保哥的建议是：正文按目标市场的新写法走，同时让旧写法在页面上有迹可循。理由很实际——用户的打字习惯不会因为一纸文件立刻改变，未来好几年里，搜facto的人和搜fato的人会同时存在。

具体做法有三种，从轻到重排：一是在正文里自然地把另一种写法带过一次，比如括号里注明；二是在常见问题里用旧写法提一个问题；三是给那些搜索量确实大的旧写法单独准备落地内容。第三种只在词确实值钱的时候做，不要为了几十个搜索量新开一堆页面。

还有一个提醒：不要为了新写法去动已经有排名的老页面URL。URL里的拼写改掉，等于把积累的信号推倒重来，收益完全不成正比。改正文和标题就够了。

## 语法习惯的差别，会不会影响搜索词？

会，但影响的方式跟词汇不一样。词汇分叉直接决定你有没有被搜到，语法差别更多决定读者信不信你是本地人，进而影响转化和停留。

## 你和您怎么称呼

巴西日常几乎全用você，第二人称复数用vocês，语法上跟第三人称走。葡萄牙这边tu还很常用，动词跟着变位，正式场合用o senhor、a senhora。

对电商文案来说，这一条影响的是所有按钮、提示、邮件模板的口吻。一份为巴西写的文案照搬到葡萄牙，读起来会有种说不上来的随便；反过来，欧洲葡语的客气写法搬到巴西，会显得端着。

## 正在做一件事，两边的说法结构不同

巴西说estou fazendo，动名词结构，跟英语的进行时几乎一一对应。葡萄牙说estou a fazer，介词加不定式。这个差别在产品页上出现的频率比想象中高，凡是描述使用过程的句子都会撞上。

还有代词位置。欧洲葡语更常把代词放在动词后面用连字符连起来，巴西口语则习惯放前面。这类差别单看一句无关紧要，整页看下来就是明显的口音。

## 关键词工具把两个市场合在一起，怎么拆开？

先说清楚问题在哪。绝大多数关键词工具的语言维度只有一个葡萄牙语，你选了它，拿到的是全球葡语查询的合计。这个数字对巴西来说被稀释了一点点，对葡萄牙来说则被放大了十几倍，完全不能直接用。

更糟的是，两地叫法不同的那些词，在合并口径下看起来都很正常：xícara有量，chávena也有量，你分不出哪个量来自哪个市场，很容易得出两个词都要做的错误结论。

## 四种不用花钱的拆法

- 用趋势工具按地区拆。把xícara和chávena放进同一张对比图，再把地区限定到巴西和葡萄牙各跑一次，相对热度的形状会立刻告诉你哪个词属于哪边。绝对值拿不到，但方向足够清楚。

- 看搜索建议的地区差异。同一个种子词，在两个市场的搜索框里得到的下拉建议是不一样的。这些建议本身就是真实查询的采样，免费、实时、按地区。

- 扒本地电商平台的类目名。巴西的大型综合电商和葡萄牙的本地零售站，类目结构里的用词是被海量真实点击验证过的，比任何词典都贴近市场。

- 翻本地论坛和社区里的原话。尤其是求推荐、吐槽、比价这三类帖子，用户的表述最接近他们打进搜索框的样子。

这四种方法拿不到精确搜索量，但它们能回答一个更重要的问题：这个词在这个市场是不是活的。有了这个判断，再拿相邻市场的量做粗略比例推算，排优先级完全够用。这套思路跟从站内搜索日志里挖真实查询词 (https://zhangwenbao.com/site-search-query-mining-keyword-research-first-party-data.html)是一脉相承的，都是在工具给不出数据时回到一手来源。

## 变音符号在哪一环最容易丢？

葡萄牙语要处理的符号不算多，但每一个都常用：鼻化的ã和õ，尖音的á、é、í、ó、ú，抑扬的â、ê、ô，还有软音符的ç，外加欧洲葡语里的à。问题是它们经常在你看不见的地方消失。

## URL里的ã和ç

最常见的处理是转写：ã变a、ç变c、ê变e，生成一串纯拉丁字母的地址。这个做法本身没错，而且对分享、复制、口头传播都友好。真正的坑在于转写规则不统一。

同一个站里，如果一部分链接由后台生成、一部分由前端脚本生成、还有一部分是人工填的，你很可能同时得到三种地址形态：保留原字符的、百分号编码的、转写成拉丁字母的。三条地址指向同一个页面，信号就被劈成了三份。

解决办法很朴素：把转写规则写死在一个地方，全站只走这一条路径，历史上产生的其他形态统一做跳转。规则本身怎么定其实不重要，重要的是全站只有一套，并且新加的模块必须走同一个函数，不许各写各的。

## 数据库排序与去重

这一环坑得更隐蔽。数据库的字符集和排序规则如果配的是拉丁一区的默认值，ã和a在排序上会被当成不同的字符，也可能被当成完全相同的字符，取决于你用的具体规则。

前一种情况的后果是列表页的字母排序看起来是乱的；后一种情况的后果更严重——两个本该不同的词被判成重复，写入时被拒或者被合并。做葡语站，建库那一刻就把字符集和排序规则定成支持完整符号集的那一套，比上线后再改省事一百倍。

## 还有一个更麻烦的：同一个字符的两种存法

屏幕上一模一样的é，在字节层面可以是一个字符，也可以是字母e加一个组合用重音符号，两个码位。字符串比较会判它们不相等，去重、匹配、站内搜索全会出问题。

处理原则是在入口处统一：所有文本进入系统时先做一次规范化，全站只存一种形态。这件事跟法语那边的处理逻辑完全一样，法语重音符号带来的那些麻烦 (https://zhangwenbao.com/french-seo-accents-quebec-keyword-variants.html)里拆得更细，葡语可以直接照搬那套方法。

## 站内搜索为什么在葡语站上返回一片空白？

因为葡语的名词和形容词有性和数的变化，动词变位更是繁复，而默认的站内搜索多半是按字符串精确匹配做的。

用户搜filtros，你的商品名写的是filtro；用户搜cafeteiras italianas，你的标题是cafeteira italiana。人眼看是同一个东西，程序看是两个不同的字符串，于是返回零结果。

## ão变复数的三种走法

葡语里以-ão结尾的名词，复数不止一种形式，这一点常年坑人：

- -ões：最常见的一类，比如颜色的cor不算，典型的是ação变ações、estação变estações

- -ães：数量少但都是高频词，pão变pães、cão变cães

- -ãos：也是少数，mão变mãos、irmão变irmãos

没有一条纯粹的规则能覆盖全部，得靠词典。这意味着你不能指望正则去尾巴那种土办法处理葡语的单复数，必须上真正的词形还原，或者退一步，把高频词的变形手工维护成一张同义词表。

对中小站来说，手工那张表反而更划算。统计站内搜索日志里最高频的两百个查询，把它们的单复数、阴阳性形态都收进同义词配置，返回空结果的比例通常能砍掉一大半。这是投入产出比最高的一次性工作，做完基本不用维护。

## 两个市场的内容，要不要各写一套？

先说结论：内容层可以共用骨架，表述层必须分开。整站复制两份逐句改写，成本高得离谱；一套内容通吃两地，又必然在词汇上得罪一半读者。

比较务实的切法是按页面类型分级：

页面类型 | 处理方式 | 理由 | 

分类页、产品页标题 | 必须分市场写 | 核心词就在这里，写错等于不被搜到 | 

产品描述正文 | 分市场做词汇替换 | 骨架共用，替换掉分叉词与语法习惯 | 

知识型长文 | 可以共用一套 | 信息价值大于口音，读者容忍度高 | 

价格、运费、支付说明 | 必须分市场 | 这几块跟语言无关，跟市场强相关 | 

法律条款、退换货 | 必须分市场 | 合规要求不同，不能凑合 | 

至于这两套内容在站点结构上怎么摆——用不同的域名后缀，还是同一个域名下分目录，怎么让搜索引擎理解它们的关系——那是架构层的题目，跟语种没什么关系，多语言站的域名结构选择 (https://zhangwenbao.com/international-seo-domain-structure-cctld-subdirectory-subdomain.html)那篇专门在讲，这里不重复。

需要在语言层强调的只有一句：别让两套内容变成互相抄的两个空壳。如果替换完只剩几个词不同，那它们本质上就是同一页，不如老老实实做一套，把省下的力气花在选对主市场上。

## 葡语文案比英语长，模板会被撑成什么样？

这一条几乎每个做葡语版本的团队都要吃一次亏。葡语译文相对英语原文，通常会长出两成到三成，个别短标签能翻倍。

举几个真实会出事的位置：

- 加入购物车按钮：英语两个词，葡语常是Adicionar ao carrinho，宽度直接翻倍，固定宽度的按钮会把文字挤出去或者截断

- 导航菜单：一级菜单项变长之后，原本一行排得下的六项会掉到第二行，或者被压得字号极小

- 筛选器标签：侧边栏筛选项通常宽度很窄，葡语的属性名很容易换行成三行，整个筛选区被撑高

- 邮件标题：客户端的显示宽度是固定的，葡语标题被截断的位置往往正好切掉关键信息

- 搜索结果里的标题：可显示的字符数有限，长词一多，你精心写的后半句根本露不出来

处理办法不是让译者硬压字数——压出来的文案通常都很生硬。更好的做法是让模板具备弹性，按钮宽度自适应、菜单允许折行、关键信息前置。前两件事归前端，第三件事归你。

标题前置这件事在葡语里尤其值钱。既然可显示的宽度就那么点，就把核心词和品类词放在最前面，把修饰语往后挪。这条规则听起来像老生常谈，但在字长膨胀的语言里，它的收益比在英语里大得多。

## 价格、支付与配送这几件事，比语言更能决定转化

做了这么多年跨境，保哥有个不太动听的观察：语言做对只是及格线，掉链子的往往在语言之外。葡语双市场尤其明显。

巴西那边，分期付款几乎是文化级的存在。同一个商品，页面上写清楚可以分几期、每期多少钱，跟只写一个总价，转化率不是一个量级。这个信息如果没有出现在产品页上，很多用户根本不会往下走。

还有税费和清关。跨境包裹进巴西的税费规则和时效是消费者心里的一道坎，页面上含糊其辞，用户就默认最坏情况然后离开。把预计到手价、预计时效写在显眼位置，比多写五百字产品描述有用。

葡萄牙那边关注点不同，用户更在意配送时效和退货是否方便，价格敏感度没那么极端。同一套模板放两个市场，重点信息就得换位置。这是内容策略的事，不是翻译的事。

## 葡语的搜索意图词，两地是不是同一批？

品类词决定你被谁看见，意图词决定看见你的人处在哪个阶段。葡语的意图词有个特点：骨架两边一样，但最高频的那几个词不一样。

意图类型 | 巴西高频修饰词 | 葡萄牙高频修饰词 | 该配什么页面 | 

购买 | comprar、preço、barato | comprar、preço、onde comprar | 产品页与分类页 | 

运费 | frete、frete grátis | portes、portes de envio | 运费说明与活动页 | 

比较 | melhor、qual comprar | melhor、qual escolher | 选购指南 | 

评价 | avaliação、vale a pena | opinião、review | 评测与用户口碑 | 

用法 | como usar、como fazer | como usar、como utilizar | 教程与常见问题 | 

优惠 | promoção、desconto、cupom | promoção、desconto、código | 促销落地页 | 

看frete和portes这一行。运费这个概念，两地用的根本不是同一个词根，而运费恰好是电商转化路径上最关键的一个信息点。一个满页写frete的站，在葡萄牙的运费类查询里等于不存在。

再看评价那一行。巴西人写avaliação的比例高，葡萄牙人更常直接借用英语的review。这类借词的接受度差异，恰恰是判断一份文案写给谁的最快线索之一。

实操上有个笨但有效的做法：把意图词单独维护成一张表，跟品类词分开管。品类词决定页面主题，意图词决定标题的后半段和小标题。两张表交叉相乘，能一次性铺出一整片长尾，而且不会因为改了一个品类词就把整套结构推倒。

## 数字、货币和日期格式，为什么也算语言层的事？

因为写错了，用户会当场怀疑这个站不是本地的。这类信号比文案质量更快、更直接。

葡语区的数字写法跟英语相反：小数用逗号，千位用点。一千二百三十四点五，写出来是1.234,5。如果你的模板是照英语站改的，价格就会变成1,234.5，本地用户看到的是一个奇怪的、小了一千倍或者大了一千倍的数字。

货币符号的位置也不同。巴西的写法是符号在前、中间带空格，葡萄牙则习惯把欧元符号放在数字后面。这两条如果混着来，页面上会同时出现两种价格格式，看着就不像一家正经店。

日期是日在前月在后，跟英语站相反。这一条在促销活动页上最容易出事：一个写成03/04的截止日期，英语习惯读成4月3日，葡语读者读成3月4日，差一个月。

- 小数与千位分隔：1.234,5而不是1,234.5

- 日期顺序：日在前，月在后

- 货币符号位置：巴西前置，葡萄牙后置

- 电话号码分组：两地位数与分组习惯不同，别用同一个占位符

- 地址字段：邮编格式与字段顺序不同，表单要分市场配置

这几件事听起来琐碎，但它们全都出现在离成交最近的那几屏上。文案写得再地道，价格显示成一个荒谬的数字，用户照样会走。

## 商品属性和筛选项里的词，为什么比正文更值得抠？

因为它们是被复用次数最多的文本。一个属性值写错，错的不是一句话，是几百上千个页面上的同一个位置。

拿咖啡器具举例。材质里的不锈钢、玻璃、陶瓷，容量单位，滤纸的尺寸标法，手冲和意式的分类名——这些词会同时出现在筛选器、商品标题、面包屑、比价数据里。选错一个，整条线全歪。

而属性值恰恰是本地化流程里最容易被跳过的部分。翻译公司拿到的通常是正文文档，属性值躺在后台的字典表里，没人把它导出来送审。等发现的时候，已经是几千条商品数据了。

正确的顺序应该反过来：先定属性字典，再写内容。属性字典定稿之后，商品标题、筛选器、面包屑全部从字典里取词，人工文案只负责描述性的那部分。这样既保证一致，也让后面换词的成本降到改一张表。

## 机器翻译在葡语上最容易犯哪三类错？

把机器翻译当初稿工具没问题，直接发布就是另一回事。葡语上最常见的三类错误有明显的模式，认出来就能快速筛查。

第一类是性数不一致。葡语的名词有性，形容词、冠词、过去分词都要跟着变。机器在长句里经常把形容词的性数配错，尤其是句子中间插了从句的时候。这类错误母语者一眼就能看出来，读起来像小孩说话。

第二类是市场错配。翻译引擎的语料是混合的，产出的文本经常一半巴西说法、一半欧洲说法。同一段里前一句写celular后一句写telemóvel，这在真人写作里几乎不可能发生，是机器痕迹最明显的指纹。

第三类是假朋友。葡语和西班牙语长得像，但有一批词意思完全不同，机器在语料不足时会串味。比较有名的几个：esquisito在葡语里是奇怪，不是美味；apelido在葡萄牙指姓氏，在巴西指外号；borracha是橡皮，不是醉酒。产品描述里出现这类词，笑话就闹大了。

筛查方法也简单：让审校专门盯这三类，不要求他逐句润色，只要求他把这三类标出来。审校成本能降一大截，抓住的问题反而更多。

## 母语审校该怎么验收？

先纠正一个常见误会：母语审校不等于随便找个说葡语的人看一遍。前面说过，两地的审校员会各自认为自己那套是对的，你要的是针对特定市场的审校。

一份能用的验收清单大概是这样：

- 明确市场。委托时就写死是给巴西还是给葡萄牙，让审校按那一边的习惯改，而不是按他自己的习惯改。

- 给词表。把核心品类词、品牌名、型号、不许改的术语列成一张表随稿交付，避免审校把你精心选的关键词改成他更喜欢的同义词。

- 标出拼写口径。过渡期里新旧两套写法并存，你得告诉审校统一按哪一套走，不然同一批稿子会出现两种拼法。

- 要求标注而不是直接改。让审校把改动理由写在旁边，你才能判断哪些是硬错误，哪些只是个人偏好。

- 抽查搜索表现。审校完成后，把改动过的核心词丢回搜索框看看，确认改后的词在目标市场确实有人用。

第五条最容易被跳过，也最容易翻车。审校改得再地道，如果改成了一个没人搜的词，对搜索来说就是负收益。语言正确和市场正确是两件事。

## 品牌名与产品型号在葡语里怎么写？

品牌名保持原样，别翻译，也别自作主张加变音符号。这一条几乎没有例外。

产品型号更要原样保留。型号一旦被改写，跟国际数据源、比价站、评测内容的匹配关系就断了，损失远大于那点本地化收益。这条在所有小语种市场都成立。

需要处理的是品牌名进入葡语句子后的语法形态。葡语名词有性，品牌名被当成名词用的时候，前面的冠词该用o还是a，本地人有约定俗成的习惯。写错了不至于搜不到，但读起来会有点怪。稳妥做法是让审校确认一次，之后全站统一。

另外提醒一句，语言标签这个东西是有标准写法的，语言标签标准里区分葡语两个地区变体的写法规则 (https://www.rfc-editor.org/rfc/rfc4646)说得很清楚，别自己发明格式。标签写得规范，后面所有依赖它的系统才不会打架。

## 巴西和葡萄牙之间，先做哪一个更划算？

不给标准答案，给一个能自己算的判据。拿这五个问题过一遍，哪边得分高做哪边：

问题 | 倾向巴西 | 倾向葡萄牙 | 

你的客单价 | 中低，走量 | 中高，重品质 | 

物流方案 | 能落本地仓或有靠谱清关方案 | 依赖跨境直邮 | 

支付能力 | 能接本地分期与本地支付方式 | 常规国际卡即可 | 

内容产能 | 充足，扛得住持续更新 | 有限，需要小切口 | 

竞争容忍度 | 愿意打硬仗 | 想找空白地带 | 

三条以上落在同一列，方向就清楚了。资源有限的时候，把一个市场做透，永远好过两个市场各做一半。

## 别忘了非洲那几个葡语市场

安哥拉、莫桑比克这些市场用的是欧洲葡语体系，词汇上更靠近葡萄牙那一侧，但又有各自的本地说法。它们的搜索量目前还小，值不值得单独投入取决于你的品类。

有个便宜的做法：不为它们单独建内容，但在做欧洲葡语版本时，把明显的本地词收进同义词表和站内搜索配置。成本几乎为零，白捡的那部分流量算意外之喜。等哪天某个市场的量真的起来了，你手上已经有一份现成的词表可以拿去扩内容。

## 引擎那半边怎么办？

本文从头到尾在讲语言本身，一个字没提某个搜索引擎的排名机制，这是有意的。

葡语两个市场的搜索格局都相对集中，引擎层面要做的事跟你做英语市场没有本质区别：站点能被抓取、结构清晰、页面能打开、内容有价值。这些通用功课不因语种改变。

真正只有做葡语才会遇到的，是本文讲的这些：词汇分叉、拼写过渡、语法习惯、符号处理、单复数还原。把语种换成英语就不成立的部分，才是这门语言独有的功课。引擎那半边有专门的文章讲，不在这里重复。

## 上线前的语言层检查清单

把前面所有内容压缩成一张可执行的表，上线前逐条打勾：

- 核心品类词是否按目标市场选定，而不是按译者习惯选定

- 分叉词表是否整理成文档，并交给了审校和内容团队

- 拼写口径是否统一，新旧两套没有混用

- 页面上的称呼口吻是否符合目标市场习惯

- 所有变音符号在标题、正文、地址、数据库里是否一致存活

- 字符规范化是否在入口处统一做过一次

- 站内搜索是否处理了单复数和常见变形

- 按钮、菜单、筛选器在葡语文案下有没有被撑破

- 价格、分期、运费、税费信息是否按市场差异化

- 品牌名与型号是否保持原样，冠词用法是否统一

- 核心词改动后是否回到搜索框验证过还有人用

十一条里有八条不需要写一行代码，只需要有人认真过一遍。经验里翻车的项目，缺的往往不是技术，是没人负责这张表。

## 常见问题解答

## 只做一套葡语内容，能同时覆盖巴西和葡萄牙吗？

能被收录，但覆盖效果会打对折。核心问题在于分类页和产品页标题里的品类词，这些位置只能写一个词，写了巴西的说法，葡萄牙那边搜另一个词的人就找不到你，反过来也一样。知识型的长文容忍度高一些，读者看到不熟悉的说法通常能理解，但商业意图强的页面几乎没有回旋余地。比较现实的做法是先确定一个主市场，把主市场的词写在所有关键位置，同时在正文里自然地把另一边的说法带过一次，让搜另一个词的人至少还有机会命中。等主市场跑出成绩、有余力了，再考虑给次要市场单独做一套商业页面。千万别一开始就想两头都要，最后往往是两头的核心词都写得不地道。

## 正字法改革之后，老页面上的旧拼写要不要全部改掉？

不建议全量改，更不建议动地址。过渡期长达数年，这期间新旧两种写法在网上并存，用户的打字习惯改变得比规则慢得多，搜旧写法的人在相当长时间里仍然是多数。合理的节奏是分三步：新写的内容一律用新规则；已有内容里，标题和摘要这类高权重位置逐步换成新写法，正文可以慢慢来；地址一律不动，因为改地址会把已经积累的信号推倒重来，收益完全覆盖不了损失。另外可以做一个小动作，在页面正文里把旧写法自然地提一次，比如在括号里注明另一种拼法，这样两种查询都有机会命中，成本几乎为零。等过渡期结束、市场上旧写法的使用明显衰减了，再统一收口也不迟。

## 关键词工具只有一个葡萄牙语选项，怎么判断哪个词属于哪个市场？

用三层证据交叉验证。第一层是趋势工具的地区对比，把两个候选词放进同一张图，再分别限定到两个市场各跑一次，相对热度的形状差异会非常明显，一个词如果在某个市场几乎是平的，那它在那边就不是常用说法。第二层是搜索建议，同一个种子词在两个市场的搜索框里得到的下拉列表不一样，这些建议是真实查询的采样，可信度很高。第三层是本地电商平台的类目名和商品标题，这些用词经过了海量真实点击的验证，比词典更贴近市场语言。三层证据指向一致，基本可以定案；出现矛盾时以第三层为准，因为它离交易最近。这套方法拿不到绝对搜索量，但排优先级完全够用，而且不花钱。

## 葡语站的变音符号最容易在哪里丢失？

按出事频率排，第一是地址生成环节，转写规则不统一会让同一个页面出现几种地址形态。第二是数据库，字符集或排序规则配错会导致排序混乱甚至误判重复。第三是导入导出环节，从表格文件批量导入商品时，编码不匹配会让所有带符号的字符变成问号或者乱码，而且往往是导完很久才被发现。第四是第三方接口，物流、支付、客服系统对非拉丁基本字符的处理参差不齐，姓名和地址里的符号经常被吃掉。第五是字体，如果用了字符集裁得太窄的网页字体，个别符号会掉回系统默认字体，视觉上会看到一行字里某几个字母长得不一样。逐环节做一次端到端测试是最省事的办法，造一条包含全部符号的测试数据，从录入一直走到前端渲染和邮件通知，看它在哪一环变了形。

## 做巴西市场，内容之外还要准备什么？

三件事，重要性可能都高于文案本身。第一是支付，本地常用的支付方式和分期能力直接决定成交，页面上必须把可分几期、每期多少写清楚，这是那个市场的基本预期。第二是价格透明度，跨境商品的税费和清关时效是消费者心里最大的不确定性，页面含糊其辞，用户就按最坏情况理解然后离开，把预计到手价和预计时效写在显眼位置的收益，通常大于再写五百字产品描述。第三是客服语言和响应时效，售前咨询能不能用葡语实时回应，对客单价高的品类影响很大。这三件事都不属于语言层，但它们和语言一起构成了用户对你是不是一家本地店的判断。语言做对了，这三件事没做，转化依然会很难看。

## 葡语的单复数和词形变化，站内搜索一定要上词形还原吗？

不一定，看站的规模。词形还原是最彻底的方案，但需要引入相应的语言处理组件，对中小站来说未必划算。有个投入产出比更高的替代方案：统计站内搜索日志里最高频的两百到三百个查询，把它们的单复数形态、常见变形、以及带不带变音符号的写法，全部整理成一张同义词表，配置进搜索里。这个做法能解决绝大多数返回空结果的情况，工作量大概是一两天，做完基本不用维护。等站的商品数和搜索量真正上来了，再考虑上完整的词形还原也不迟。要特别注意的是以-ão结尾的名词，它的复数有三种走向，没有统一规则可循，这类词必须手工维护进表里，指望正则去尾巴一定会出错。

## 怎么快速判断一段葡语文案是给哪个市场写的？

有几个特征词一看就知道，不需要精通葡语。看电脑相关词汇，出现ficheiro和rato的是欧洲那边，出现arquivo和mouse的是巴西那边。看日常生活词汇，autocarro、comboio、telemóvel是欧洲，ônibus、trem、celular是巴西。看语法结构，句子里出现estou a加动词原形的是欧洲写法，出现estou加动词的动名词形式的是巴西写法。看称呼，通篇você的偏巴西，出现tu并且动词跟着变位的偏欧洲。看拼写，过渡期里如果还保留着不发音的辅音字母，比如acção这种，那是欧洲的旧写法。把这五组特征做成一张小卡片发给内容团队，验收时对着扫一眼，比逐句读快得多，也能拦住绝大多数错配。

## 权威参考资料



## 法语SEO的重音符号可以不打，但魁北克那一边不能不管

- URL：https://zhangwenbao.com/french-seo-accents-quebec-keyword-variants.html
- 分类：小语种SEO
- 发布：2008-11-25  |  更新：2026-07-25
- 摘要：讲法语SEO选词实战：重音带不带的取舍与归一化边界、Unicode规范化引发的字符串对不上、ç与œ合字处理、法国与魁北克的词汇分叉表、acheter与avis等意图词、标点前不间断空格的断行影响，以及比利时瑞士市场的局部覆写粒度。
- 关键词：关键词研究,内容本地化,小语种SEO

> **TLDR**：摘要：法语站最常被问的一个问题是，用户搜的时候到底打不打重音符号。答案有点扫兴：这件事没你想的那么要紧，搜索侧基本能兜住，页面上老老实实写规范形式就行。真正会让你付出代价的是另一头——法国和魁北克对同一个东西的叫法不同，对英语借词的容忍度差着一整个数量级，魁北克那边还有一部管商业语言的法律。再加上é在编码层存在两种写法、法语标点前面要留不间断空格，这几件事凑在一起，足以让一份看起来完美的法语词表在大西洋另一岸全部落空。下面按语言层逐条拆。

> 摘要：法语站最常被问的一个问题是，用户搜的时候到底打不打重音符号。答案有点扫兴：这件事没你想的那么要紧，搜索侧基本能兜住，页面上老老实实写规范形式就行。真正会让你付出代价的是另一头——法国和魁北克对同一个东西的叫法不同，对英语借词的容忍度差着一整个数量级，魁北克那边还有一部管商业语言的法律。再加上é在编码层存在两种写法、法语标点前面要留不间断空格，这几件事凑在一起，足以让一份看起来完美的法语词表在大西洋另一岸全部落空。下面按语言层逐条拆。

先讲一个开局。一家做成衣的独立站，法国站跑了两年，数据不错，团队决定顺势把内容复制一份进加拿大。翻译不用重做，反正都是法语，改改尺码表和货币就上线了。

半年后魁北克的自然流量依然贴地飞行。查下来发现的第一个问题小得有点荒唐：这家店所有涉及邮件订阅的地方都写着email，而魁北克人搜索和使用的词是courriel。一个词而已，但它出现在订阅模块、结账流程、隐私政策、客服页面，几乎每个页面都在提醒当地读者这不是给他们做的站。

第二个问题更贵：他们的品类页主词用的是法国那边的说法，而魁北克对应的日常用词是另一个。法语市场的分叉不像西班牙语那样铺得广，但它切得更深，因为魁北克对语言的态度不只是习惯问题，还是法律问题。

## 重音符号到底要不要做两套写法？

先给结论，省得你翻到后面：页面内容一律写规范形式，别为不带重音的写法单开页面，也别在正文里故意写错。

用户端的真实情况是这样：法语键盘上打é、è、à很方便，母语者在正式写作里基本都会打；但手机上快速输入、或者用非法语键盘时，省略重音的情况相当普遍。所以同一个查询确实同时存在带重音和不带重音两个版本。

好在搜索引擎对这类变体的归一化处理已经相当成熟，带不带重音一般被当成同一个查询处理。你的页面写规范形式，两种输入都能接住。反过来写不带重音的形式风险明显：法语读者看到会直接判定是错别字，专业感当场打折。

## 大写字母上的重音，是个经典争议

法语里有个老争论：全大写标题上的重音符号该不该保留。很多人以为大写不用加重音，其实这是打字机时代留下的技术妥协，不是语言规范。法兰西学术院在语言问题栏目里的表态 (https://www.academie-francaise.fr/questions-de-langue)很明确，大写字母同样应当带重音符号，省略只是排版习惯造成的将就。

这件事对SEO的实际影响不大，但对页面质感有影响，尤其是导航栏、按钮、全大写的标题这些位置。真正会出事的是另一种情况：省略之后产生了歧义。少了重音，某些词就变成了另一个词，标题读起来就成了病句。

## 重音在法语里是会改变词义的

这不是装饰性问题。ou是或者，où是哪里；a是动词有，à是介词到；sur是在上面，sûr是确定。一个产品标题里少一个重音，语法上就是一句错话。

这类错误在自动生成的页面上最容易批量出现，比如从表格导入的产品标题、从接口拉的属性名、由模板拼接的分类页。一个错误乘以几千个页面，效果相当壮观。

## 同一个é，为什么会在系统里对不上？

这一节属于语言和技术的交叉地带，很多做了几年法语站的人都没意识到它的存在。

带重音的字母在编码层有两种表示方式：一种是把它当成一个独立字符存起来，另一种是把基础字母和重音符号分成两个字符组合起来。两种方式在屏幕上看起来完全一样，但它们在字节层面是不同的字符串。Unicode关于规范化形式的标准附件 (https://www.unicode.org/reports/tr15/)把这两种形式和它们之间的转换规则定义得很清楚。

后果很直接：字符串比较对不上、站内搜索找不到、去重逻辑判定成两个不同的值、数据库里同一个词出现两条记录。这类问题的症状极具迷惑性，因为你肉眼看到的两个字符串一模一样，而程序坚持说它们不同。调试时最费时间的不是难题，是长得一样的两个东西。

## 它在什么场景下会咬人？

第一是数据源合并。产品数据从两个系统汇进来，一个用组合形式一个用独立形式，合并之后同一款商品变成两条，分类页和站内搜索一起出问题。

第二是文件名和URL。某些操作系统在保存文件时默认用组合形式，上传之后的路径和数据库里记的路径对不上，图片或资源就直接失效了。

第三是标签和分类。手工录入和批量导入两条路径产生的同名标签，在后台看起来是同一个，实际上是两个，页面被拆成两份，权重跟着分散。

## 怎么排查？

办法很朴素：写一小段脚本，把关键字段统一转成同一种规范形式再入库，入口处做一次归一化，历史数据跑一次批量修正。做完之后再写一个巡检，定期扫一遍有没有两种形式并存。这个动作一次性投入不到一天，但它拦掉的是那种一年后才爆发、爆发时完全无法定位的问题。

## 法语还有哪些符号会悄悄出事？

除了重音，还有几个符号值得单独列出来。

软音符ç只出现在c下面，用来在a、o、u前面保留清辅音发音。它在品牌名和常用词里出现频率不低，丢了就是错字。

分音符ë、ï、ü用来表示相邻元音要分开读，Noël这类词离了它就不成立。这个符号在导入导出环节的丢失率比重音还高，因为它更少见，测试用例里经常压根没有它。

合字œ是个更特别的存在。它在法语里是一个字符而不是o加e，出现在cœur、œuvre、bœuf这些常用词里。麻烦在于用户输入时经常打成oe，于是同一个词出现两种写法，而这两种写法在检索层面能不能互认，取决于系统的处理逻辑。稳妥做法是页面写规范的合字形式，同时确保站内搜索能把两种写法映射到一起。

## 还有一个字体层的坑

网页字体为了压体积经常做子集化，只保留用得到的字符。子集按英文字符集裁的话，法语的重音元音、ç和œ会缺字形，浏览器只好退回系统字体渲染，同一行字里几个字母突然换了模样。这不影响排名，但一眼就显得不专业，而且这类问题在移动端更明显。

## 法国和魁北克的差别，到底分几层？

把差异拆开看会更好下手。大致有三层：词汇层、借词态度层、法规层。前两层影响关键词命中，第三层影响你能不能这么做。

## 词汇层：同一样东西的两种叫法

概念 | 法国 | 魁北克 | 说明 | 

电子邮件 | email、mail | courriel | 魁北克首创并推广的词 | 

购物 | shopping | magasinage | 法国直接用英语词 | 

周末 | week-end | fin de semaine | 魁北克坚持用法语结构 | 

停车场 | parking | stationnement | 路牌上就是这么写的 | 

笔记本电脑 | portable | portable也用 | 但portable在法国还常指手机 | 

特价 | promo、soldes | rabais、aubaine | 促销词分叉严重 | 

购物车 | panier | panier | 这类基础词通用 | 

看这张表能发现一个规律：凡是从英语借来的词，法国倾向直接用，魁北克倾向造一个法语词替代。courriel这个词就是魁北克的语言机构推出来再反向影响法国的典型例子，法国官方后来也正式采纳了它，但民间使用率始终远低于英语原词。

另外注意表里最后两行的对照。分叉不是普遍的，基础的功能性词汇两岸通用度很高，真正分叉的集中在从英语借词的那一块，以及促销、日常生活、行政事务这几个领域。这意味着大部分内容可以共用，需要重写的其实是那几个高价值的商业词。

## 借词态度层：宽松和严格差着一整个数量级

法国的日常商业语言里英语词密度相当高，尤其是互联网、营销、时尚这几个行业，用英语词甚至带一点时髦感。魁北克正相反，作为北美的法语孤岛，当地对语言纯度的敏感度极高，随手用英语词在商业场合是要被扣分的。

这个差异对选词的意义是：同一个词在两个市场的正确答案可能是完全相反的。在法国用英语原词能拿到更多搜索量，在魁北克用同一个词不仅搜索量低，还会被读者判定为不尊重本地。

魁北克的官方术语库是判断这类词的好工具，它按行业给出推荐的法语说法，术语库里courriel的词条 (https://gdt.oqlf.gouv.qc.ca/ficheOqlf.aspx?Id_Fiche=8367245)就完整记录了这个词的定义、构词来源和使用建议。做魁北克市场时，把核心词表逐条丢进去查一遍是性价比很高的动作。

## 法规层：这是别的语言市场没有的

魁北克有一部管法语使用的法律，对在当地经营的商业活动有明确的语言要求，涉及商业标识、包装、说明书、合同以及面向公众的商业出版物。对线上业务来说，实际影响主要落在两处：面向魁北克消费者的商业内容需要有法语版本，且法语版本的呈现不能弱于其他语言。

这条对SEO的间接影响挺大。它意味着在魁北克，法语内容不是可选项，你不能只做英语版本然后靠搜索引擎自动翻译糊弄过去。同时它也带来一个好处：这个市场的语言门槛天然筛掉了一批不愿意投入的竞争者，认真做法语内容的站点在这里的竞争压力比法国小得多。

## 魁北克的法语和法国的法语，语法上差在哪？

差别比词汇层小，但有几处值得注意。

一是称谓的正式度。法国的电商文案偏向非正式的tu，尤其是面向年轻人的品类；魁北克的商业内容用正式的vous更普遍，即便是消费品。用错了不影响排名，但影响读者对品牌的判断。

二是句子结构的直译痕迹。魁北克长期处在英语环境里，日常口语中存在不少从英语结构直译过来的说法，这些说法在法国人耳朵里是别扭的，但在魁北克是自然的。做本地内容时按当地习惯写，别拿法国的标准去纠正。

三是时间和数字表达。加拿大的日期格式、电话号码格式、地址顺序都跟法国不同，货币也是加元而不是欧元。这些不影响关键词，但影响转化，而且是那种用户说不出哪里不对、就是不想付款的不对。

## 法语的搜索意图词，哪些是必须覆盖的？

品类词只是一半，挂在它前后的修饰词才是意图的载体。法语有一套自己的高频修饰词，跟英语不是一一对应的。

意图 | 常用修饰词 | 该落到什么页面 | 注意 | 

购买 | acheter | 品类页或产品页 | 动词在前，是最标准的商业查询结构 | 

比价 | prix | 产品页带价格模块 | 常与品类词直接相连不加介词 | 

口碑 | avis、test | 评测页 | test在法语里指评测，不是考试 | 

低价 | pas cher | 促销落地页 | 三个词的固定结构，别拆开 | 

物流 | livraison gratuite | 产品页或政策页 | 形容词跟着名词的阴阳性变 | 

教程 | comment | 内容页 | 问句型内容的主力入口 | 

比较 | meilleur、meilleurs | 榜单页 | 复数形态对应清单型内容 | 

选购 | quel、quelle | 选购指南页 | 疑问形容词要跟名词性别配合 | 

这张表里最容易被漏掉的是最后一行。法语的疑问形容词要跟被修饰名词的性别数保持一致，同一个意思会写出四种形态。做词表时只收一种，等于把大半个长尾丢掉了。

还有一个值得注意的是test这个词。它在法语里就是产品评测的意思，搜索量相当可观，而从英语词表翻译过来的人往往会写成évaluation或者critique，两个都是正确的法语，但都不是大家去搜的那个词。

## 法语的促销词，为什么不能照着英文词表翻？

这是个很少被单独讲、但对电商站影响直接的点。法语里表示打折的词不止一个，它们之间不是同义词关系，而是各自对应不同的场景，有一个甚至带着监管属性。

soldes在法国指的是一年里特定时段的清仓季，这个时段和适用规则是有明确制度安排的，商家不能随便挑个月份就宣布进入这个状态。这意味着这个词的搜索量有极强的季节脉冲，平时很低，到点了直线上冲。

promotion和它的口语缩写promo指的是常规促销，全年可用，没有时段限制。réduction和remise偏向具体的减价动作，常出现在价格描述里。而在魁北克，最常用的是rabais，还有一个很地道的词aubaine，意思接近超值好价，法国人基本不这么说。

## 这对内容规划意味着什么？

第一，别把这几个词当成同义词堆在同一个页面上。它们对应的用户状态不一样：搜清仓季那个词的人在等一个特定时间点，搜常规促销词的人是随时在找便宜，两者需要的落地页结构完全不同。

第二，季节脉冲要提前布局。带强季节性的词，内容要在需求起来之前就上线并被收录，等到季节开始才发页面，基本就是在给别人做陪跑。季节词的正确打法是让页面常年存在、按季更新，而不是每年新建一个。

第三，魁北克那一列要单独做。促销词恰好是两岸分叉最严重的一类，法国的促销词表原样搬过去，命中率会低得让人怀疑数据出了错。

## 还有一个合规层的提醒

涉及价格宣称的表述在法语市场普遍受到较严的约束，比如原价怎么标、折扣怎么算、限时的时限如何呈现。这部分不是SEO的活，但它会限制你的标题和描述能怎么写。写文案之前先问一句这个说法当地能不能用，比上线后再改省事得多。

## 法语标点前面那个空格，会不会影响页面？

法语排版有个规矩：冒号、分号、问号、感叹号这些标点前面要留一个空格，而且必须是不会被换行拆开的那种空格。引号里侧也要留。这是排版规范，不是可选项。

对SEO的直接影响很小，但有几个间接影响值得注意。第一是断行，如果用了普通空格，标点有可能被甩到下一行行首，在移动端窄屏上出现的概率相当高，看起来就是排版事故。文本断行的规则由Unicode的换行算法标准定义，不同空格字符的断行行为在里面写得很清楚。

第二是字符串处理。不间断空格和普通空格是两个不同的字符，做关键词匹配、字符串比较、去重的时候如果不做归一化，含标点的短语会出现匹配不上的情况。

第三是复制粘贴。用户从页面复制一段带不间断空格的文本到别处，某些环境下会显示成奇怪的方块。这不是你的错，但读者只会觉得是你的站有问题。

## 法语的写作风格，跟英文内容差在哪？

这一层不影响关键词命中，但直接决定读者读不读得下去，而读不读得下去又反过来决定内容的实际表现。

法语书面语有很强的正式传统，句子结构比英语复杂，从句嵌套更多，段落也更长。一份从英语直译过来的稿子最典型的毛病是句子太短太碎，在法语读者眼里显得幼稚，像是给小学生写的。

另一个差别是名词化倾向。英语习惯用动词推进叙述，法语更习惯把动作变成名词再挂上一个弱动词。同一件事，英语写成一句利落的主谓宾，法语的自然表达往往是一个名词结构。译者如果照着英语的动词节奏走，出来的稿子语法全对但读感很怪。

第三是论证方式。法语的说明文有一套讲究铺垫和展开的传统，喜欢先交代背景再给结论，而英文内容营销的主流是结论先行。这两种结构没有优劣之分，但混在一起就会别扭：开头用了英文式的直给，后面又用法语式的迂回，读者会觉得作者精神分裂。

## 那到底该按哪种写？

务实的做法是分场景。信息型的长内容按法语的习惯写，让它读起来像本地作者写的；商业型的落地页和产品页可以保留结论先行的结构，因为购物场景下用户耐心有限，这一点是跨语言通用的。

还有一个可量化的差别：法语句子的平均长度明显长于英语，同一段内容切成短句会显得急促。这一点在移动端要做取舍，屏幕窄的时候太长的句子也难读，折中的办法是句子保持法语的结构完整，但段落切得比法语传统写作更碎。

关键是别在同一个页面里两种风格混着来。给译者的简报里写清楚这一页属于哪一类、期望什么读感，比笼统说一句请翻译得地道有用得多。

## 品牌名和产品名进法语市场，要不要动？

品牌名本身通常不动，但围绕它的处理有几件事要提前定。

第一是性别。法语的名词都有性别，一个外来品牌名在法语句子里被使用时，读者会本能地给它派一个性别，然后冠词和形容词跟着配合。这件事你不定，市场会自己定，而且不同人可能定得不一样，导致同一个品牌在网上出现两种写法。比较省事的做法是在自己的内容里始终用同一种搭配，让它成为事实标准。

第二是发音可读性。品牌名如果包含法语里不自然的字母组合，当地用户在口口相传时会读出各种版本，进而搜出各种拼写。这类拼写变体值得在内容里自然覆盖一次，别指望搜索引擎全都能纠正过来。

第三是产品型号和技术代号。这些一律保持原文，不要翻译也不要本地化，转写会切断跟国际数据源和比价平台的匹配关系，损失远大于那点搜索收益。

## 产品名里的通用词要不要翻？

要，而且这是最容易被漏掉的一块。品牌名不动，但产品名里那个描述品类的通用词必须用法语，而且要用目标市场的说法。一款商品叫某某品牌加上英文品类词，在法国勉强能过，在魁北克就是明显的减分项。

处理办法是把产品名拆成两段看：品牌与型号保持原样，品类描述部分做本地化，并且这一段要跟你的关键词表对齐。产品名里的品类词，是整个站里最值钱也最常被忽略的一处关键词位置。

## 法语的冠词缩合，会不会影响内链锚文本？

会，而且这是个很少被提起、但做内链时天天遇到的问题。

法语的介词遇上定冠词要缩合成一个词，de加le变成du，à加les变成aux。这意味着同一个名词短语放进不同的句子里，前面挂的那一截会变形。

做内链时的麻烦在于，锚文本要既自然又包含目标页的核心词。如果机械地把关键词原样塞进句子，前面的缩合就会出错，句子读起来是病句；如果为了句子通顺而改写，锚文本又可能偏离核心词。

可行的处理有两种。一种是把锚文本控制在名词短语本身，让缩合发生在锚文本之外，链接只包住核心的那几个词。另一种是接受锚文本里带上变形后的形式，反正锚文本的作用是描述目标页的主题，不是做精确字符串匹配。

要避免的是第三种做法：为了保住关键词的原样形态而写出不合语法的句子。读起来别扭的锚文本，损失的信任比它带来的那点关键词相关性大得多。这条在所有屈折语上都成立，法语只是表现得比较温和。

## 批量生成内链时要注意什么？

如果你用脚本或者规则批量插内链，法语站要额外加一道检查：确认插入位置前面那个词不是需要缩合的介词，否则很容易生成一堆语法错误的句子。这类错误单看每一处都很小，但它们成规模出现时，整个站的语言质量观感会明显下滑，而且几乎没人会写邮件告诉你。

## 比利时和瑞士的法语，要不要单独管？

这两个市场经常被完全忽略，但它们的规模加起来不小，而且竞争密度远低于法国。

语言差异比魁北克温和得多，主要集中在几个日常词上。最有名的是数字：法国说soixante-dix、quatre-vingt-dix，比利时和瑞士说septante、nonante，瑞士部分地区的八十还有huitante这个说法。听起来是小事，但如果你的品类涉及尺寸、规格、数量，这些词是会进关键词的。

除此之外还有一些日常词的分叉，比如一天的三餐叫法在比利时和法国不完全一致，行政和教育相关的术语各有各的体系。做这两个市场的实用建议是：内容主体沿用法国版本，把货币、配送、法务信息本地化，再把几个高频的本地词做局部替换。在小市场做全套独立内容通常不划算，做局部覆写才是对的粒度。

## 那非洲的法语市场呢？

撒哈拉以南的法语区人口基数很大，长期看是增量市场，但现阶段做SEO要接受两个现实：一是搜索数据的采样密度低，工具给出的数字参考价值有限；二是移动网络环境和设备性能差异大，页面性能对可访问性的影响远超内容质量。

语言层面，这些市场的书面法语高度接近标准法语，共用内容不成问题，真正需要本地化的是支付方式、配送方案和联系渠道。换句话说，这里的功课不在语言层，在运营层。

## 法语名词的性数变化，会怎样影响词表？

法语所有名词都有阴阳性，形容词和冠词要跟着变。这件事对词表的影响比很多人以为的大。

同一个意思的短语，因为名词性别不同，形容词会写出不同形态。noir和noire、petit和petite、nouveau和nouvelle，在关键词工具里通常是各自独立的记录。做需求统计时如果只取一种形态，会系统性低估这个词根的真实体量。

另一头是冠词。法语的冠词在口语和搜索中经常被省略，但也经常出现，尤其是长问句型的查询。同一个需求可能以带冠词和不带冠词两种形式出现，两者的量要合并看。

做页面的时候则反过来，别为每一种形态单开页面，那是老式的堆词打法，现在只会制造内耗。一个词根一个页面，标题用最主流的形态，正文自然覆盖其他形态。这套归并逻辑在别的屈折语上同样适用，保哥在德语SEO的复合词与变音符号那篇 (https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html)做过一遍拆解，跨语种共通的那部分也可以对照西班牙语在两岸的词汇分叉 (https://zhangwenbao.com/spanish-seo-es-es-latam-keyword-divergence.html)里按德语的构词法讲过一遍，思路可以直接搬过来。

## 还有一个复数的小陷阱

法语大部分名词加s变复数，但有一批词的复数不规则，还有一批词的单复数写法完全相同。做词表批量处理时如果用简单的加s规则去生成变体，会造出一堆不存在的词，然后在报表上看到一片零搜索量，误以为这个方向没需求。

## 法语页面的信任信号，跟英语站差在哪？

语言做对只是及格线。法语市场对本地感的要求不低，几个信号缺一个就掉一截。

第一是联系方式的本地形态。电话号码按当地格式写，地址顺序按当地习惯排，营业时间标注当地时区。法国和魁北克的格式各不相同，照搬一套等于对其中一个市场不上心。

第二是法务信息的完整度。法国的商业网站有一套关于经营者信息公示的惯例，缺失这类页面在当地读者眼里是明确的减分项。这不是SEO要求，但它影响用户对站点合法性的判断，进而影响转化和口碑。

第三是客服语言的明确承诺。写一句用法语提供客服并标明响应时段，比什么都管用。反过来，一个全法语的站在客服页面突然冒出英文表单，前面积累的本地感会瞬间清零——这一点在魁北克尤其致命。

## 正式度怎么定？

建议在项目开始时就把称谓口径写进内容规范，全站统一，别让每个译者自己发挥。定的方式很简单：看市场、看品类、看客单价。面向年轻人的快消品在法国可以用tu，面向企业客户、高客单价品类、以及整个魁北克市场，用vous更稳。定完写进给译者的简报，验收时把两种形态各搜一遍，混用了就打回。

## 法语内容验收该查哪些东西？

不懂法语也能做一轮结构性检查，足以拦掉大部分低质量交付。

先看重音符号有没有系统性缺失，整篇一个重音都没有，基本可以判定是机翻或者编码环节出了问题。再看标点前的空格在不在，冒号和问号前面紧贴文字的稿子说明排版规范没执行。

接着搜英语借词。做魁北克市场的稿子里如果还留着email、shopping、week-end这类词，说明译者用的是法国语料，没做地区适配。再搜tu和vous，同一个页面上两种称谓都出现就是没统一口径。

然后看数字和日期格式，小数点用逗号、千位用空格、日在前月在后，照搬英文格式的稿子一眼能认出来。货币符号的位置也要看，欧元符号在数字后面。

最后一步没法省：找一个真正在目标市场生活的人读一遍首页和三个主要落地页，不要求他懂SEO，只问一句读起来像不像本地公司写的。这一步花的钱远比返工少，往往还能顺手问出几个工具永远给不出的词。内容用什么流程组织生产、翻译和原生创作怎么分工，属于另一个话题，小语种站的内容本地化落地步骤 (https://zhangwenbao.com/wordpress-minor-language-seo-localization.html)那篇讲得更具体。

## 给译者的简报该写哪几项？

保哥带客户做法语项目时有个习惯：把简报压缩成一页纸，只写译者真正需要决策的东西，别写正确翻译原文这种废话。

这一页上必须有的有六项：目标市场是法国还是魁北克还是两个都要、称谓统一用哪一种、英语借词的处理原则、这一页属于信息型还是商业型内容、必须原样保留的品牌与型号清单、以及必须命中的核心词表。前五项决定语言风格，最后一项决定这份稿子对SEO有没有用。

特别要写清楚的是核心词表那一栏的用法：这些词必须出现，但不要求出现的次数，也不要求原样形态，遇到语法上需要变形的地方就变形。不写这一句，译者要么把词硬塞成病句，要么为了通顺把词全改掉，两种都是灾难。

## 上线前还有几项技术检查

把语言相关的技术项列成清单一次过完：页面的语言声明写对了没有、字符集是否统一、字体子集是否包含全部法语字符、数据库排序规则能不能正确处理带重音的比较、站内搜索对带重音和不带重音的输入是否都能返回结果、URL生成器有没有把重音字母正确转写。

这些项目单看每一条都很小，但它们决定了你的法语内容是以什么状态被读到的。跟法国站相邻的其他欧洲市场也要一起排，尤其是共用一套模板的时候，一个字体子集的问题往往同时影响好几个语种。至于多语言站点的域名怎么组织、各版本之间怎么互相指认，属于架构层的活，出海独立站国际SEO怎么选域名结构 (https://zhangwenbao.com/international-seo-domain-structure-cctld-subdirectory-subdomain.html)里拆得比较细，这里不重复。

## 常见问题解答

## 只做法国不做魁北克，行不行？

完全可以，而且对大多数刚起步的站来说是更理性的选择。法国是法语世界搜索量最集中的市场，做透一个市场的收益通常高于同时做两个半吊子。真正需要考虑魁北克的情况有三类：一是你的产品在北美有物流优势，加拿大的配送成本明显低于跨大西洋；二是你已经在做加拿大英语市场，法语版本的边际成本很低而且当地法规本来就期待你提供；三是你所在的品类在法国竞争极其激烈，而魁北克的竞争密度低得多，同样的内容投入能换来更靠前的位置。反过来说，如果只是想多一个市场试试水，那就别做，半套魁北克内容比没有更糟——当地读者对语言细节的敏感度很高，一份看得出是从法国内容改的稿子，传递出来的信号是不重视，这个印象比排名难修得多。

## 法语站的URL要不要用带重音的字符？

建议转写成不带重音的形式。技术上URL里放带重音的字符是可行的，编码传输、抓取索引都不会出问题，纯从收录角度说是安全的。但实践中麻烦不少：地址栏复制出来是一长串百分号编码，粘到聊天工具、邮件或者外链里容易被截断，后台日志和分析报表里的可读性很差；某些老旧系统在处理这类路径时还会出规范化不一致的问题，导致同一个页面出现两个可访问地址。更麻烦的是前面讲过的编码形式问题，同一个带重音的字母存在两种表示方式，落在URL里就可能产生两条实际不同的路径。所以主流做法是slug层做转写，é写成e、ç写成c、œ写成oe，正文里该怎么写还怎么写。已经上线并且收录正常的站，别为这个专门做迁移，改URL的风险大过收益。

## 法语内容比英文长两成，标题标签老被截断怎么办？

先接受一个前提：截断本身不是灾难，核心词被截掉才是。第一原则是把最重要的词放最前面，尾部被砍也不影响关键信息已经出现。第二是把品牌名放最后，必要时让它被截掉。第三是主动删掉低价值的连接成分，法语的介词结构比英语啰嗦，de、pour、avec这类词在标题里能省则省，语法上松一点不影响可读性。第四是别在标题里塞同义词，两个意思相近的词并排会让标题瞬间超长还显得刻意。另外提醒一点，搜索结果里的标题按显示宽度截断而不是按字符数，后台看到的字符数和实际显示不是一回事。法语还有一个特殊之处：带重音的字符在某些字体下的显示宽度和不带重音的不一样，靠数字符估算会失准，做法语站最好直接用能预览显示宽度的方式确认。

## 法国市场的英语词到底能用到什么程度？

按三类分开处理最省事。第一类是已经完全归化的借词，比如web、marketing、shopping这些，在法国的商业内容里直接用英文形式完全正常，硬翻回法语反而丢搜索量还显得学究气；要注意的是它们在语法上已经被当成法语名词，有性别、要跟冠词配合。第二类是法语有成熟对应词且对应词更常用的，优先用法语，比如téléchargement比download自然得多，尤其是结账流程里的功能性文案，冒出英文标签会让人怀疑网站的可信度。第三类最容易翻车，是那种看着像英语、实际是法语自己造出来的伪英语词，用法和英语原意对不上，这类词做法语关键词时必须用，但没法从英文站的词表里翻译过来，因为英语里压根没这个用法。行业差异也要考虑：互联网、时尚、营销领域英文词密度高，法律、医疗、工业领域则相反。拿不准就把两种写法分别丢进法国版搜索看建议，哪个能拉出真实的行业内容就用哪个。

## 魁北克的语言法规会不会影响到SEO操作？

不会直接影响排名机制，但会影响你的内容策略必须怎么排。核心要求是面向当地公众的商业内容要有法语版本，且法语版本的呈现不能弱于其他语言。落到实操上有几条：站点如果同时提供英法两个版本，别把法语版做成英语版的附属品，比如只翻译首页、内页全是英文，或者法语版入口藏得很深；商业标识、产品名称、说明性文案这些面向消费者的内容要有法语呈现；面向魁北克投放的广告落地页同样适用。反过来看，这套要求也是机会：它抬高了进入门槛，愿意认真做法语内容的竞争者比法国少得多。另外提醒一句，具体的合规细节涉及法律解释，本文只讲它对内容规划的影响，真正要落地时该找当地的法律意见，别拿SEO经验当法律建议用。

## 法语关键词工具报零搜索量的词，还值得做吗？

法语的零搜索量词比例低于德语这类构词能力强的语言，但依然可观，尤其是长问句型的查询和魁北克这类中等规模市场。判断该不该做别只盯数字，看这个词背后是不是一个成立的需求：有没有明确场景、能不能对应一个具体产品或问题、真人会不会这么打。三条都成立就值得做，这类页面的转化率往往高得反常，因为搜的人已经想得很清楚了。反过来，如果这个词是你把几个成分拼出来造的、母语者根本不会这么说，那报零就是真的零。区分办法还是那招：丢进目标市场的搜索框看有没有搜索建议、看结果页返回的是真实的本地内容还是一堆词典和翻译站。返回词典站的，多半是个造出来的词。另外做魁北克市场时多一个招：把词丢进当地的官方术语库查一下，术语库收录了并且给出使用建议的词，通常是活的。

## 法语和西班牙语市场能不能共用一套本地化流程？

流程可以共用，判据不能共用。流程层面，两门语言的工作步骤高度一致：定市场清单、拿本地种子词、按国家显式拉搜索量、词形归并、搜索建议验活、母语者过一遍，这六步照搬没问题，团队学一次能用在两门语言上。不能共用的是每一步里的判断标准。西班牙语的分叉是横向铺开的，二十来个市场各有各的说法，难点在于选一个中立词还是拆多套内容；法语的分叉是纵向切深的，市场数量少但魁北克那一刀切得很硬，还叠加了法规要求。另外两门语言对英语借词的态度完全不同，法国比西班牙宽松，魁北克比任何西班牙语市场都严格，这条判据直接对调都可能出错。实操建议是把流程模板化、把判据做成每门语言各自的一页纸清单，这样既复用了工程能力又不会串味。

## 权威参考资料



## 德语SEO最先卡住的不是技术，是德国人管这东西叫另一个词

- URL：https://zhangwenbao.com/german-seo-compound-words-umlaut-eszett-keyword-research.html
- 分类：小语种SEO
- 发布：2008-10-14  |  更新：2026-07-24
- 摘要：讲德语SEO关键词实战：Komposita复合词的构词逻辑与Fugen-s、搜索引擎的复合词分解机制、München与Muenchen两套写法的取舍、Duden的ß与ss规则、de-DE与de-AT及de-CH的词汇差异、Denglisch外来词分寸与德语站信任信号。
- 关键词：关键词研究,内容本地化,小语种SEO

> **TLDR**：摘要：德语市场的选词之所以难，难在这门语言会把一整串修饰关系压缩进一个词里。英语要写三个词才说清的东西，德语一个Damenschuhe就完事了，于是工具眼里的搜索量全堆在少数几个长单词上，长尾看着像凭空消失。再叠上 ä ö ü 的替代写法、ß 与ss的地区分歧、德奥瑞三国各自的日常用词，一套照着英语思路做出来的德语关键词表，常常上线第一周就露馅。下面按语言层拆开讲：复合词该在哪儿切、两套拼写要不要都做、什么时候必须把瑞士单独拎出来。

> 摘要：德语市场的选词之所以难，难在这门语言会把一整串修饰关系压缩进一个词里。英语要写三个词才说清的东西，德语一个Damenschuhe就完事了，于是工具眼里的搜索量全堆在少数几个长单词上，长尾看着像凭空消失。再叠上 ä ö ü 的替代写法、ß 与ss的地区分歧、德奥瑞三国各自的日常用词，一套照着英语思路做出来的德语关键词表，常常上线第一周就露馅。下面按语言层拆开讲：复合词该在哪儿切、两套拼写要不要都做、什么时候必须把瑞士单独拎出来。

先说个真实场景。一家做户外装备的出海站要开德国市场，英文站的关键词表翻译完交过来，主词是hiking backpack，德语译成了Wanderrucksack。听着没毛病。可上线两个月，这个词的自然流量几乎不动，反倒是页面底部一句没人管的Trekkingrucksack带来了零星点击。

问题不在翻译准不准，Wanderrucksack完全是正确的德语。问题在于德国人买这类包时，脑子里冒出来的词根本不是它。这就是德语市场最典型的开局：你翻译得越准确，可能离真实搜索词越远。

## 德语把一整个短语拼成一个词，关键词表为什么先塌了一半？

德语的构词法允许把名词一个接一个拼下去，拼出来的东西在语法上仍然是一个词。这类词叫Komposita，中文一般译作复合词。搜索引擎优化在德语里就是一个词：Suchmaschinenoptimierung，由Suchmaschine（搜索引擎）加Optimierung（优化）拼成。

拼法有个固定逻辑：最后一个成分决定这个词是什么，前面的成分只负责限定。语言学上前者叫Grundwort（基础词），后者叫Bestimmungswort（限定词）。Handyvertrag是一份合同（Vertrag），手机（Handy）只是限定它是哪一类合同；Vertragshandy就反过来了，那是一部合约机。

这条规则对选词的意义很直接：一个复合词的搜索意图，几乎全部由它的最后一段决定。Damenschuhe落在鞋类目录页上没问题，Schuhpflege（鞋类保养）就得落到内容页去，哪怕两个词长得很像。

## Fugen-s这个连接音，会把同一个概念写成两个词

德语复合词的接缝处经常要加一个连接成分，最常见的是一个s，叫Fugen-s。Arbeitsmarkt（就业市场）中间有s，Arbeitszeit（工作时间）也有，可Arbeitgeber（雇主）偏偏没有。

这套规律并不完全可推导，母语者靠语感，非母语者靠查。麻烦在于加不加s会写出两个不同的字符串，而搜索引擎在关键词层面是按字符串统计的。碰上拿不准的词，最省事的办法是把两种写法都丢进Google搜索框看建议里出现哪一个，出现的那个就是活的。

## 搜索引擎会不会自己把复合词拆开

会，而且这件事对德语市场的影响相当大。搜索引擎处理德语这类复合词密集的语言时，会尝试把长词切成有意义的成分，让搜Rucksack的人也有机会看到一个主打Wanderrucksack的页面。这个动作在检索领域一般叫复合词分解。

但别把它当成免费午餐。分解的把握程度取决于这个复合词有多常见、成分边界有多清晰，越是生僻的自造长词，越可能被当成一个整体的陌生字符串处理。能被稳定分解的是那些已经进入日常语言的复合词，你临时拼出来的那种拆不出来。

这带来两条实操建议。第一，别指望靠一个超长复合词把所有相关查询一网打尽，该做的成分词页面还是得做。第二，反过来也成立：你的页面如果主打一个常见复合词，它天然就在承接成分词的部分流量，这部分流量在关键词报告里可能挂在别的词底下，别因为看不到就以为不存在。

## 为什么工具跑出来的德语长尾会少得离谱

英语的长尾是靠加词堆出来的：backpack、hiking backpack、lightweight hiking backpack for women，每加一个修饰就多一个可统计的短语。德语这些修饰经常被吸进复合词内部，变成一个不常见的长单词，或者干脆没人这么拼。

结果就是德语关键词工具跑出来的列表，头部集中度高得吓人，中长尾稀稀拉拉。这不是市场小，是需求被压缩进了更少的字符串里，同时也说明单个词的竞争会更硬。做德语市场之前先把这个预期调过来，能省掉很多关于流量预测的争吵。

## 同一个意思写成复合词还是写成短语，搜索量差多少？

德语允许两种表达并存：Damenschuhe是复合词，Schuhe für Damen是介词短语，意思一样。但这两条路的搜索量往往差一个数量级，而且哪边赢并没有统一规律。

能总结出来的经验大致是这样：越是日常、成熟、有商品目录属性的概念，越倾向于被压成一个复合词；越是新出现、需要解释、带条件限定的概念，越倾向于拆成短语。所以Winterreifen（冬季轮胎）是一个词，而“适合电动车的冬季轮胎”这种意思，德国人多半会拆着搜。

概念类型 | 倾向写法 | 例子 | 选词动作 | 

成熟品类 | 复合词 | Winterreifen、Damenschuhe | 做成目录页主词 | 

品类加属性 | 复合词为主 | Herrenlaufschuhe | 做筛选页或子类目 | 

带条件的需求 | 短语为主 | Rucksack für Handgepäck | 做内容页或导购页 | 

新概念、外来词 | 两种并存 | Trekkingrucksack与Rucksack zum Trekking | 两条都验，选活的那条 | 

验证方法很土但有效：把两种写法分别在google.de搜一遍，看返回的结果页是不是同一批站。如果两边前十名高度重合，说明搜索引擎已经把它们判成同一件事，你挑搜索量大的那个写就行；如果两边站点完全不一样，那是两种不同的需求，得分开做页面。

这套判断逻辑本身跟按搜索结果重叠度做关键词聚类是同一回事，只不过在德语里，判断对象从两个短语变成了一个长单词和一个短语，而这两者在工具里长得毫不相干，很容易被当成两个独立机会分别投入。

## 变音符号 ä ö ü 该不该做两套写法？

德语有三个变音字母 ä ö ü。碰上没有德语键盘布局的场合，习惯上写成ae oe ue：München写成Muenchen，Größe写成Groesse。还有一种偷懒写法是直接去掉两点写成Munchen，严格说是错的，但在搜索框里天天出现。

Google在处理这类查询时会做归一化，多数情况下这三种写法能拿到相近的结果。但相近不等于相同，尤其在竞争激烈的词上，SERP会有细微差别。更关键的是另外几个地方，那里的差别是硬的。

## URL、文件名和邮箱里的变音符号

页面正文写München完全没问题，浏览器和搜索引擎都认。但URL里的处理要保守得多。技术上URL可以用百分号编码承载变音字母，实际效果是地址栏里变成一长串 %C3%BC之类的编码，复制粘贴到别的地方经常断掉，社交平台抓取时也容易出错。

所以德语站的slug主流做法是转写：ä 写成ae，ö 写成oe，ü 写成ue，ß 写成ss。muenchen-umzug这样的slug干净、可读、不会在任何环节被折断。图片文件名同理，一个带变音符号的文件名在跨系统同步时坏掉的概率，比你想象的高。

域名层面是另一回事。德国的域名注册机构早就开放了带变音符号的域名，müller.de这样的地址是可以注册的，底层通过一套编码转换成ASCII形式存在。品牌名里本来就有变音字母的公司，注册一个对应的变音域名有防御意义，避免被别人抢注。

但把它当主域名要谨慎：用户在没有德语键盘的场合打不出来，电话里也没法口头念清楚。稳妥做法是主域名用转写形式，变音域名注册下来做301跳转，两头都不吃亏。

## 两套写法在页面上怎么分工

不需要在正文里刻意把München和Muenchen都堆一遍，那样读起来像机器写的。合理的分工是：正文一律用规范写法，替代写法只出现在URL、文件名这类技术位置，另外允许它自然出现在用户生成的内容里，比如评论和问答。

如果某个替代写法确实有可观搜索量，正确做法不是往正文里塞，而是看它有没有独立的搜索意图。绝大多数情况下没有，那就交给搜索引擎自己归一化。这跟保哥在出海独立站关键词本地化的翻译陷阱 (https://zhangwenbao.com/overseas-indie-keyword-localization-translation-traps-native-review.html)里说的原则一致：别为了覆盖字符串变体牺牲可读性，母语者一眼就能看出哪句话是为了塞词写的。

## ß 到底该写 ß 还是写ss？

这个字母叫Eszett，也叫scharfes s。它不是装饰，用错了是拼写错误，而且德国读者对拼写错误的容忍度相当低。

规则本身其实清楚。按 Duden关于s、ss与 ß 的正字法规则 (https://www.duden.de/sprachwissen/rechtschreibregeln/doppel-s-und-scharfes-s)：重读短元音后面只有一个s音时，写成双写的ss，比如Fluss、Masse、essen；长元音或双元音后面只有一个清s音时，写 ß，比如Maß、Straße、grüßen、außer。一句话记：短元音配ss，长元音和双元音配 ß。

## 瑞士和列支敦士登根本不用 ß

同一份Duden规则里写得很明白：在瑞士和列支敦士登，ß 一律用ss替代。所以Straße在瑞士写成Strasse，Fussball在瑞士就是两个s。这不是错别字，是当地的规范写法，20世纪中期就已经完成切换。

这条对SEO的影响是实打实的：面向瑞士市场的页面上出现 ß，在当地读者眼里等于告诉他们这个页面不是给他们看的。地址、街道名、产品名里只要带 ß，一眼就穿帮。如果你的德语站同时覆盖德国和瑞士，这是必须做替换的少数几处硬差异之一。

## 全大写的时候写什么

标题、按钮、导航这些地方经常用全大写排版，而 ß 传统上没有大写形式，规范做法是替换成SS：STRASSE、AUSSEN。后来Unicode补了一个大写Eszett（ẞ），Duden也承认它可选，但字体支持参差不齐，按钮上出现豆腐块的风险不值得冒。全大写场合老老实实写SS，这是最稳的选择。

## 德语的名词大写和格变化，会不会影响关键词匹配？

德语所有名词首字母都要大写，这是拼写规则不是强调。搜索引擎对大小写不敏感，所以这一条对匹配没影响，但对文案有影响：把德语句子里的名词写成小写，母语读者的观感相当于中文里满篇错别字。翻译外包回来的稿子，这是最值得先扫一遍的地方。

真正影响匹配的是格变化。德语名词有四个格，冠词和形容词词尾会跟着变：der Rucksack、des Rucksacks、dem Rucksack、den Rucksack。复数还会换形，Buch变Bücher，连元音都带上了两点。

变形类型 | 例子 | 对搜索的影响 | 怎么处理 | 

名词大写 | Rucksack而非rucksack | 无 | 只管文案质量 | 

属格加s | des Rucksacks | 极小 | 正文自然写 | 

复数换形 | Buch变Bücher | 较大，可能是两个词 | 单复数各查搜索量 | 

形容词词尾 | leichter/leichte/leichten | 中等 | 标题用主格形式 | 

实操上抓两条就够。第一，标题和H标签用主格单数或主格复数，别用被格变形拽歪的形式，读起来自然、也贴近用户输入。第二，单复数当成两个候选词分别查搜索量，德语的复数换形有时候会把搜索量整个搬到另一边去。

## 内链锚文本在德语里会跟着句子变形

这是个容易被忽略的细节。中文写内链锚文本，词是什么样就是什么样。德语里锚文本嵌在句子中间，会被格和词尾拽着变，同一个目标页在不同段落可能挂着leichte Rucksäcke和leichten Rucksäcken两种锚。

这不是问题，反而更自然。要避免的是反过来：为了让锚文本保持某个精确形式，硬把句子写歪。德语读者对句子别扭的敏感度很高，为一个锚文本破坏语法，得不偿失。

## 德国、奥地利和瑞士，能不能算一个市场？

语言标签层面，这三个地区分别是de-DE、de-AT和de-CH。W3C关于HTML与XML语言标签的说明 (https://www.w3.org/International/articles/language-tags/)里给出的原则很实用：标签越短越好，只有当地区子标签能提供有用的区分信息时才加上去，而de-CH和de-AT正是文中列举的、确实需要区分的例子。

那什么算有用的区分？看词汇分叉的密度。这三地共用一套书面德语，但日常词汇差得比很多人以为的多。

概念 | 德国 | 奥地利 | 瑞士 | 

一月 | Januar | Jänner | Januar | 

奶油 | Sahne | Obers | Rahm | 

自行车 | Fahrrad | Fahrrad | Velo | 

ß 的使用 | 用 | 用 | 不用 | 

货币 | EUR | EUR | CHF | 

拆不拆的判据可以简单化：如果你的核心品类词在三地不同名，就得拆；如果只是零星词汇差异，共用一套内容加地区版本更划算。卖自行车的必须给瑞士单独做Velo，卖登山包的三地都叫Rucksack，那就没必要拆成三份。

决定拆之后，剩下的就是架构问题了：用什么域名结构承载、hreflang怎么写成对称。这部分保哥在出海独立站国际SEO怎么选域名结构 (https://zhangwenbao.com/international-seo-domain-structure-cctld-subdirectory-subdomain.html)里拆得比较细，这里不重复，只提醒一句：de-DE和de-AT内容高度相似时，最容易出的问题不是排名互相分流，而是搜索引擎判定其中一个版本没有独立价值，干脆不给收录。

## 德国人搜东西的方式，跟英语市场差在哪？

光把词翻对还不够，德国用户的搜索行为本身就跟英美市场不太一样，这直接决定了你该做哪种页面、写多深。

最明显的一条是查询更长、更具体。一部分原因是构词法，一个复合词就能承载三层限定；另一部分是习惯，德国用户倾向于把条件说全了再搜，而不是先搜个大词再慢慢筛。落到内容策略上，这意味着宽泛的品类大词价值被高估，具体到型号、规格、使用场景的页面价值被低估。

## 参数和细节，在德语市场是刚需不是加分项

德国读者对技术参数的耐心远超一般预期。同样一个产品页，英文站放三条卖点加几张图可能就够了，德语站少了材质、尺寸、重量、产地、认证标准这些硬信息，转化会明显掉下来。这不是文化刻板印象，是一个能在跳出率上直接看出来的差异。

做法上有两条推论。一是产品页和对比页要写得比英文版更厚，参数表该列就列，别怕难看；二是那些在英语市场被认为过于技术、没人看的内容，比如标准编号、测试方法、材料成分，在德语站里反而是可以拿来做长尾的东西。

## 夸张的营销话术，在这里是负资产

德语商业写作有个很强的克制传统，加上广告表述本身受到反不正当竞争层面的约束，最好、第一、唯一这类绝对化说法用起来风险不小，而读者对这类词的免疫力也高得多。

英文站上那句the best hiking backpack you will ever own直译成德语，效果基本是负的：不但不增加说服力，还会让人怀疑这家公司不专业。德语市场的说服力来自可验证的具体信息，不来自形容词。写德语落地页时把形容词砍掉一半，换成数字和事实，通常立刻见效。

## 数据保护意识高，会影响你看到的数字

德国在个人数据这件事上的谨慎是有历史传统的，普通用户对追踪、注册、留资的抵触比多数市场强。这带来一个容易被忽视的后果：你在分析工具里看到的德语站数据，往往比真实情况更残缺。

对SEO决策的影响是别把转化数据当唯一裁判。德语站的自然流量看起来转化率偏低，有相当一部分是测量损耗而不是页面不行。判断内容质量时，多看排名分布、页面停留和品牌词增长，少依赖单一漏斗数字。

## 德语关键词研究该怎么做才不踩坑？

德语关键词研究的第一步不是打开工具，是承认自己的语感不够用。中文母语者能靠直觉判断“笔记本电脑”和“手提电脑”哪个更常用，德语里没有这种直觉，只能靠数据补。

## 用搜索建议把候选面铺开

SISTRIX的德语关键词研究教程 (https://www.sistrix.de/tutorials/seo-strategie/keyword-recherche)里描述的采集方法，本质是穷举：拿种子词加上a到z每个字母、加上变音字母、加上数字，逐个去取搜索建议，再把结果汇总去重。对德语这种复合词密集的语言特别管用，因为搜索建议给出的是真实被输入过的完整字符串，能直接告诉你哪种拼法是活的。

教程里还有一句提醒值得抄下来：整理列表时，语义相同、只是措辞不同的词应该合并，取其中搜索量最高的那个。德语里这一步的价值比英语大得多，因为复合词与短语的两套写法天天在打架。

## 工具给的德语搜索量，什么时候会骗你

德语搜索量数据有两个系统性偏差。一是复合词把长尾吸走了，工具报出来的头部词搜索量会显得异常高，你按英语的经验去估转化，容易高估；二是变音符号的归一化处理各家不一致，有的工具把Groesse和Größe合并统计，有的分开报，同一个词在两个工具里差出一倍很常见。

对付办法是别只信一家。拿两个工具的数字对着看，差异大的词单独去SERP里验证一遍，看返回结果是不是同一批站。这个动作在英语市场可以省，在德语市场省不得。

## 零搜索量的复合词要不要做

德语里会遇到大量工具报零、但明显有人在用的复合词，因为它们太长太具体，落进了工具的采样盲区。判断标准不是搜索量数字，而是这个词能不能构成一个完整的购买或求解需求。

能构成的话，哪怕报零也值得做一个页面，逻辑跟零搜索量关键词到底有没有用 (https://zhangwenbao.com/zero-volume-keywords-true-value-aio-longtail-engineering.html)那篇讲的一样。德语市场的特殊之处只是这类词的比例更高，因为构词法本身就在源源不断制造超长具体词。

## 德语内容写出来，为什么母语者一眼看得出是翻译的？

技术做对了，内容还可能全盘垮掉。德语读者识别翻译腔的能力强得惊人，而识别出来的第一反应通常是关掉页面。

## 称谓Sie和du选错，语气就全错了

德语有敬称Sie和亲近称du两套人称。B2B、金融、医疗、工业品一律用Sie，选错等于当面直呼客户的名字；面向年轻消费者的时尚、游戏、部分DTC品牌用du更自然，一直Sie下去会显得又老又远。

要命的是这两套不能混。同一个页面上一段Sie一段du，比全程选错还糟。翻译外包时这一条必须写进需求单，否则不同译者交回来的稿子会自己打架。

## 长句、从句和名词化，德语自己也在减负

德语有能力把一个观点塞进一个五行长的句子，从句套从句，动词甩到句末。传统书面德语确实这么写，但网页阅读场景下这是灾难，移动端尤其。

还有一个是Nominalstil，名词化文体，把动作全部写成名词，读起来像法条。官方文书里常见，商业内容里用多了只会让人觉得端着。动词能表达的就用动词，句子能断开的就断开，这条在德语里的收益比在中文里还大。

## 直译过来的内容，坏在哪几个具体位置

从中文或英文直译德语，翻车最集中的是这几处：标题里的双关和成语，德语里基本对不上，硬翻出来无人能懂；数字和日期格式，德语用逗号做小数点、点号做千位分隔，1.234,56才是对的；地址和电话格式，用国内习惯排版会让人怀疑这家公司到底在不在欧洲。

这些不是语言问题，是信任问题。整套怎么从翻译外包升级成原生生产，保哥在多语言内容本地化生产线 (https://zhangwenbao.com/multilingual-content-localization-production-pipeline-vs-translation.html)那篇里拆过流程，德语只是把每一步的容错率压得更低而已。

## 英语词是直接留着还是翻成德语，Denglisch的分寸在哪？

德语吸收英语词的速度很快，快到有个专门的调侃说法叫Denglisch。做德语站绕不开这个判断：某个词到底留英文还是翻成德语，选错了不只是别扭，是直接错过搜索量。

先破除一个误解：留英文不等于偷懒。很多英语词在德语里已经完成了本地化，成了正儿八经的德语词，硬翻回去反而没人搜。Download就是典型，德语当然有Herunterladen这个词，但日常语境里Download用得更多，还长出了德语动词变位downloaden。

## 三类词的处理方式完全不同

第一类是已经归化的外来词，直接用英文形式，但要按德语规矩写：当名词用的时候首字母必须大写，das Meeting、der Shop、das Update。写成小写的meeting，在德语读者眼里就是错字。

第二类是德语有成熟对应词的，优先用德语。Kundenservice比Customer Service常用得多，Versandkosten比Shipping Costs自然得多。电商站的功能性文案尤其如此，结账流程里冒出英文标签，会让人怀疑这是个不靠谱的转运网站。

第三类最坑，是那种看着像英语、其实德语自己造出来的伪英语词。Handy在德语里指手机，可英语母语者听到handy只会理解成方便的。这类词只在德语世界流通，做德语关键词时必须用它，但千万别以为可以直接从英文站的词表里翻译过来——英文站根本就没有这个词。

类型 | 例子 | 怎么处理 | 常见翻车 | 

已归化外来词 | Download、Shop、Update | 保留英文形式，名词大写 | 硬翻成德语词，搜索量归零 | 

有成熟德语词 | Kundenservice、Versandkosten | 一律用德语 | 功能文案留英文，显得不本地 | 

伪英语词 | Handy、Beamer、Oldtimer | 必须用，且只在德语里用 | 从英文词表翻译，压根找不到 | 

英德混合复合词 | Online-Shop、Marketing-Strategie | 加连字符连接 | 连写或分写，两种都不规范 | 

## 行业不同，容忍度差得很远

互联网、营销、时尚、游戏这几个领域的德语里英文词密度很高，读者习以为常，硬要全部德语化反而显得老气。但工业制造、法律、医疗、保险这些领域正好相反，英文词用多了会被认为不专业，客户看重的是术语精确。

判断方法还是回到搜索：把两种写法丢进搜索框看建议，看哪一个能拉出真实的行业内容。这一步比任何风格指南都可靠，因为它测的是这个行业的德语使用者实际在怎么说。

## 英德混合的复合词，连字符不能省

德语复合词本来是连写的，但当成分里有英语词、缩写或者专有名词时，规范做法是用连字符连接：Online-Shop、E-Mail-Marketing、SEO-Strategie。连写成Onlineshop也能见到，属于可接受但不算最规范；写成分开的两个词就明显是英语思维了。

这个细节对关键词有实际影响，因为连字符位置不同就是不同的字符串。做词表时把带连字符和不带连字符的写法都查一遍搜索量，德语电商里两种写法搜索量接近的情况相当常见，页面标题挑主流那个，正文两种自然出现都不算问题。

## 德语站的信任信号，为什么比文案更能决定转化？

德语市场有一组几乎是硬性的信任元素，缺了不只是转化差，可能直接触发法律麻烦。这部分严格说不算SEO，但它决定了你辛苦做来的自然流量能不能变成生意，做德语站不能不知道。

## Impressum不是可选页面

德国对商业网站有法定的信息披露要求，需要提供一个Impressum页面，列出经营者名称、地址、联系方式、登记信息等。这个页面必须容易找到、点两下之内能到，藏在隐蔽角落也算不合规。

对做站的人来说有两层含义。第一层是必须有，而且导航里得有明确入口，这跟英语站把法务页面塞进页脚深处的习惯不一样。第二层容易被忽略：Impressum页面本身是德语站最强的信任信号之一，德国用户在决定要不要下单前，真的会去点开看这家公司到底在哪、是什么法律形式。

## 撤销权、条款和付款方式，共同构成本地化的下半截

面向消费者的远程销售在德国有法定撤销权，条款页要写清楚；AGB也就是通用交易条款，是德语电商的标配，读者会去看。这些内容页面通常没什么搜索量，但它们在品牌词搜索时会出现在结果里，缺席本身就是一种信号。

付款方式上有个更具体的德国特色：Kauf auf Rechnung，也就是先收货后付款的发票付款方式，在德语区的接受度远高于其他欧洲市场。结账页只有信用卡和PayPal的德语站，流失掉的订单量往往超出预期。这一层的取舍逻辑跟本地支付方式配置是同一件事，只是德国把它推到了更极端的位置。

把这些串起来看，德语站的信任建设有个共同点：它要的是可核查的具体信息，而不是好听的承诺。这跟前面说的文案克制、参数详尽是同一条线上的事，理解了这一点，很多看起来零散的德语市场规矩就串成一件事了。

## 德语站上线前该检查哪些语言层的东西？

把前面的内容压成一份可执行的清单，按上线顺序排：

检查项 | 看什么 | 不合格的表现 | 

核心词写法 | 复合词与短语两条路都验过SERP | 只翻译不验证 | 

slug转写 | ä oe ue ss全部转写，无百分号编码 | URL里出现 %C3 | 

ß 使用 | 德奥用 ß，瑞士版本全换ss | 瑞士页面出现Straße | 

全大写文案 | ß 替换成SS | 按钮上出现豆腐块 | 

名词大写 | 正文所有名词首字母大写 | 译稿里名词小写 | 

称谓一致 | 全站统一Sie或du | 同页混用 | 

数字日期格式 | 小数用逗号、千位用点号 | 照搬英文格式 | 

地区词汇 | 核心品类词在三地是否同名 | 瑞士页面写Fahrrad | 

这份清单里技术项只占一半，另一半全是语言判断，而语言判断没法靠工具跑出来，只能靠一个真的用这门语言生活的人过一遍。母语审校不是走过场，它是德语市场唯一没法省的成本。

回到开头那家户外品牌。后来的解法很朴素：把Wanderrucksack和Trekkingrucksack两个词都丢进google.de看搜索建议和结果页，发现前者的结果里多是德语旅游内容和词典，后者才是清一色的电商站。词换掉，页面标题和面包屑跟着改，其他什么都没动。这大概是德语SEO最典型的样子：真正卡住你的，往往不是技术，是没人告诉你德国人管这东西叫别的名字。

## 常见问题解答

## 德语站的URL里到底能不能直接用 ä ö ü？

技术上能，实践中不建议。现代浏览器和搜索引擎都支持在URL里承载变音字母，底层通过百分号编码传输，Google也能正常抓取和索引，所以纯从收录角度说不会出问题。但真实使用场景里麻烦不少：地址栏复制出来是一长串 %C3%BC这样的编码，粘到聊天工具、邮件或者外链里，容易被截断或者被部分平台错误解析；后台日志、分析工具里看到的也是编码后的形式，排查问题时可读性很差；某些老旧的CMS和CDN在处理这类路径时还会出规范化不一致的问题，导致同一个页面出现两个可访问地址。所以主流做法是在slug层做转写，ä 写ae、ö 写oe、ü 写ue、ß 写ss，正文里该怎么写还怎么写。这样既保证了页面内容的语言规范，又让URL保持在最安全的ASCII范围内。已经上线并且用了变音符号URL的站，如果收录正常就别为这个专门做迁移，改URL的风险比这点收益大得多。

## 德国、奥地利、瑞士到底要不要做三个站？

大多数情况下不需要三个站，但瑞士经常值得单独拿出来。判断可以从三个层面依次过：第一层是核心品类词，如果你卖的东西在三地叫法不同，比如自行车在瑞士叫Velo，那么内容不拆就等于放弃其中一个市场；第二层是货币和支付，瑞士用瑞士法郎、支付习惯和欧盟区不一样，价格页面本来就得分开处理，顺手做成独立地区版本的边际成本很低；第三层是拼写规范，瑞士完全不用 ß，页面上出现Straße这样的写法，当地读者的第一感觉就是这个站不是给自己的。奥地利的情况温和得多，除了Jänner、Obers这类日常词和少量法规差异，绝大部分内容跟德国通用，多数出海站的做法是德奥共用一套内容，只在价格、配送、法务信息上做地区差异。真要拆分，别忘了内容如果高度雷同，搜索引擎有可能判定其中一个版本没有独立价值而不给收录，这比排名分流更常见。

## 翻译公司交回来的德语稿，我不懂德语该怎么验收？

不懂德语也能做一轮结构性检查，能拦掉大部分低质量交付。先看名词首字母是不是全大写，德语所有名词都必须大写，译稿里出现小写名词说明译者要么不是母语者要么是机翻没校；再看全站称谓是不是统一，把Sie和du分别搜一遍，同一个页面两种都出现就是没统一口径；接着看数字和日期格式，德语小数点用逗号、千位分隔用点号，日期是日在前月在后，照搬英文格式的稿子一眼能看出来；然后把关键页面的标题丢进google.de搜一下，看返回的结果跟你的页面主题是不是一回事，如果搜出来全是不相干的内容，说明这个译法在德语里不是常用说法。最后一步没法省：找一个真正在德语区生活的人读一遍首页和三个主要落地页，不要求他懂SEO，只问一句读起来像不像本地公司写的。这一步花的钱远比返工少。

## 复合词太长，标题标签会不会被截断？

会，而且德语比英语更容易撞上这个问题。搜索结果里的标题按像素宽度截断而不是字符数，德语复合词动辄十几二十个字母，一个Suchmaschinenoptimierung就吃掉大半行，再加个品牌名基本就满了。应对办法有几个：一是把最重要的复合词放在标题最前面，就算被截断，核心信息也已经出现了；二是能拆的地方适当拆，比如用Rucksack für Damen代替Damenrucksack有时反而更省空间也更好读，前提是这种写法确实有搜索量；三是品牌名放最后，必要时让它被截掉，比起核心词被砍，损失小得多；四是别在标题里堆同义复合词，德语里两个同义长词并排会让标题瞬间超长，还显得刻意。另外提醒一句，标题在SERP里的显示宽度和你在后台看到的字符数不是一回事，德语站最好直接用能预览像素宽度的工具确认，别靠数字符。

## 德语关键词工具报零搜索量的词，值得做页面吗？

德语市场里这类词的比例明显高于英语，原因是构词法在不停制造超长的具体词，而这些词落在了工具采样的盲区里，报零不代表没人搜。判断该不该做，别看搜索量数字，看这个词背后是不是一个完整成立的需求：它有没有明确的使用场景、能不能对应一个具体的产品或问题、一个真人会不会在这种情境下这么输入。三条都成立的话，哪怕报零也值得做，这类页面通常转化率高得离谱，因为搜这个词的人已经把需求想得很清楚了。反过来，如果这个词只是你把几个名词拼起来造出来的、母语者根本不会这么说，那报零就是真的零，做了也是浪费。区分方法还是那招：丢进google.de看有没有搜索建议、看结果页返回的是真实内容还是一堆词典和翻译站。返回词典站的，多半是个造出来的词。

## 权威参考资料



## 韩语SEO改标题那天只挪了一个空格，后面跟着的助词又把词形变了一次

- URL：https://zhangwenbao.com/korean-seo-spacing-particles-keyword-research.html
- 分类：小语种SEO
- 发布：2007-11-08  |  更新：2026-07-25
- 摘要：讲韩语SEO实战：分写法让品类词长出两种写法、助词随前字收音分叉、谚文音节用取余运算判定收音、词表按合并口径建立、汉字词与固有词与外来语的三层同义、正规化事故与编码遗留、罗马化两套标准、站内搜索空格归一与助词剥离的三级方案、量词与两套数词、表单与地址字段本地化。
- 关键词：关键词研究,内容本地化,小语种SEO

> **TLDR**：摘要：韩语难住外来团队的不是生词，是两件小事：空格打在哪，名词后面粘的那个助词是什么。空格挪一位，一个词被切成两个概念；助词换一个，同一件东西在搜索框里就是另一个字符串，而它写成이还是가，取决于前一个字有没有收音。两条叠起来，词表规模翻好几倍，站内搜索匹配率掉到难看的水平，标题模板拼出本地人一眼看出不对劲的句子。这篇按机制拆：分写法的原则与许可、助词的形态分叉、谚文音节怎么用取余判出收音、三层同义词怎么取舍、正规化差异怎么让同一个词在库里对不上。

> 摘要：韩语难住外来团队的不是生词，是两件小事：空格打在哪，名词后面粘的那个助词是什么。空格挪一位，一个词被切成两个概念；助词换一个，同一件东西在搜索框里就是另一个字符串，而它写成이还是가，取决于前一个字有没有收音。两条叠起来，词表规模翻好几倍，站内搜索匹配率掉到难看的水平，标题模板拼出本地人一眼看出不对劲的句子。这篇按机制拆：分写法的原则与许可、助词的形态分叉、谚文音节怎么用取余判出收音、三层同义词怎么取舍、正规化差异怎么让同一个词在库里对不上。

做母婴用品的一个独立站，主打婴儿车、奶瓶消毒器、背带这几条线，欧美跑通之后想开韩语版本。团队里没有韩语母语的人，翻译外包，页面照着英文版一比一搭出来。

上线三个月，收录正常，品牌词也能搜到，但品类页几乎不进流量。团队怀疑是竞争问题，又加了一批内容，指标没有任何变化。

后来找了个首尔的自由译者做诊断，人家看了不到十分钟就指出来：分类页标题写的是아기 유모차，中间有个空格。而韩国人真正在搜的是유모차，一个词，没空格，前面那个아기（婴儿）纯属多余——婴儿车本来就是给婴儿用的。

更麻烦的是，站内搜索里用户打进来的是유모차를、유모차가、유모차는这一类带尾巴的写法，系统一个都匹配不上，全部返回空结果。用户在页面上找不到东西，转身就走了。

## 韩语的空格到底跟着什么走？

韩语写句子要打空格，这一点跟中文日文都不一样。规则的核心只有一句：词与词之间分开写，但助词要黏在前一个词后面，中间不留空。

举个最简单的：아기가 유모차를 탄다（婴儿坐婴儿车）。三段之间有两个空格，但가和를这两个助词，是紧贴在名词后面的，它们不算独立的词。

对做搜索的人来说，这条规则的后果很直接：空格是词的边界，而助词不是。用户打进搜索框的每一个查询，都可能自带一条助词尾巴，而那条尾巴会把字符串改掉。

## 同一个品类词，为什么会有带空格和不带空格两种写法？

因为正字法在复合名词这件事上留了口子。规范里给的原则是分开写，但同时允许连写，两种都不算错。于是现实中同一个概念普遍存在两副面孔。

概念 | 分开写 | 连着写 | 

奶瓶消毒器 | 젖병 소독기 | 젖병소독기 | 

婴儿背带 | 아기 띠 | 아기띠 | 

婴幼儿用品 | 유아 용품 | 유아용품 | 

安全座椅 | 카 시트 | 카시트 | 

这四组里，右边那一列在真实搜索里的量普遍更大，因为搜索框里的人懒得打空格。但也有反例，词越长越专业，分开写的比例越高。哪一种更常用，只能靠数据判断，不能靠语法推断。

## 两种写法要不要各做一个页面？

不要。这是最容易走错的一步。两种写法讲的是同一件东西，各做一个页面，等于自己造了一对内容雷同的页面互相争位置，两边都上不去。

正确做法是选一个主写法作为页面标题和主标题，另一种写法在正文里自然出现一到两次，让页面同时能被两种查询理解。至于站点结构上怎么防止同一内容出现在多个地址，那是架构层的活，可以顺着同一门语言在多个地区怎么排布页面 (https://zhangwenbao.com/international-seo-same-language-multi-region-en-us-gb-au-duplicate-content-hreflang.html)这条线单独去解。

## 助词是怎么把一个词变出十几个字符串的？

助词是韩语的语法零件，管的是这个名词在句子里担任什么角色。它们不像欧洲语言那样改动词根，而是像挂件一样直接粘在后面。

助词 | 作用 | 接在유모차后 | 

이／가 | 主语 | 유모차가 | 

은／는 | 话题 | 유모차는 | 

을／를 | 宾语 | 유모차를 | 

의 | 所属 | 유모차의 | 

에／에서 | 处所 | 유모차에서 | 

와／과 | 并列 | 유모차와 | 

도／만 | 也／只 | 유모차만 | 

부터／까지 | 从／到 | 유모차까지 | 

八行还没列全。加上复合助词和口语省略形态，一个普通名词能拉出二十种以上的书面串。它们在人眼里是同一个词，在字符串比对里是二十个互不相等的东西。

## 为什么同一个助词有两种写法？

因为要看前面那个字有没有收音。收音是韩语音节结构里的尾辅音，谚文写出来就是音节方块底下那一横或那一撇。

유모차的最后一个字是차，底下什么也没有，属于无收音，配的是가、는、를、와、로。젖병的最后一个字是병，底下有个ㅇ，属于有收音，配的是이、은、을、과、으로。

所以同一句话的骨架，套在两个不同品类词上，输出的字符串是不一样的：유모차가和젖병이，유모차를和젖병을。这就是让所有拼接式文案翻车的地方。

## 商品标题模板为什么会拼出本地人一眼看错的句子？

因为模板是用英语思路写的，它假设助词是个固定字符串，直接往名词后面接。结果就是젖병가、기저귀를这种错配，前者本地人一看就是错的，后者恰好蒙对。

好消息是这件事完全可以程序化，而且判据非常干净。谚文的每一个音节在编码里都不是随便排的，而是按初声、中声、终声三层规律算出来的。

音节区从U+AC00开始，共11172个字，排布公式是：起点加上初声序号乘588，再加中声序号乘28，最后加终声序号。终声序号为0表示没有收音。

反过来推就成了一行判断：把这个字的码位减去起点，除以28取余数，余数为0就是无收音，非0就是有收音。整个逻辑写完不到十行，却能一次性修好全站所有拼接文案。

## 三种例外要单独打补丁

第一种是以ㄹ收尾的字，接方向助词时用로而不是으로。第二种是数字和外语单词结尾，得按读音判断，比如2岁读두 살，尾音跟着读法走。第三种是型号名，字母数字混排的，习惯上直接不接助词或者用括号隔开。

这三类在母婴品类里都会碰上，尤其是型号，安全座椅和婴儿车的产品线编号一大堆。把它们做成例外表，比试图写一个万能规则实际得多。

## 关键词表该以什么为单位建？

以去掉助词、并且把空格归一之后的形态为单位建表，把所有变体的量合并到这个单位上。这是本篇最重要的一条操作。

如果按原始字符串逐条排优先级，同一个概念的搜索量会被切成十几份，每一份看起来都不值得投入，你会系统性低估韩国市场的每一个品类。这个错误在预算评审会上特别致命，因为数字看起来很客观，但口径是错的。

输出阶段则反过来：页面标题用的是真实查询里最常见的那个形态，通常是不带助词的裸名词加上一个修饰词，比如유모차 추천（婴儿车推荐）。建表按合并口径，写标题按真实口径，这两件事必须分开做。

## 汉字词、固有词、外来语，一个概念三层词该做哪个？

韩语的词汇有三个来源，同一个意思常常三层各有一个词，语感和使用场景完全不同。

概念 | 汉字词 | 固有词 | 外来语 | 

价格 | 가격 | 값 | 프라이스 | 

婴儿车 | — | — | 유모차／스트롤러 | 

颜色 | 색상 | 빛깔 | 컬러 | 

尺寸 | 치수 | 크기 | 사이즈 | 

规律大致是：汉字词偏正式和书面，固有词偏日常口语，外来语偏时尚和商品化。电商语境里外来语的存在感明显更强，사이즈的搜索量普遍高过치수，컬러也压过색상。

但这不是绝对的。가격在电商语境里就压过값和프라이스，因为它已经是商品页的标准用词。所以还是那句话，靠数据不靠语感，尤其是当团队里没有母语者的时候。

## 外来语的写法为什么会两派并存？

因为官方的外来语表记规范和民间的实际写法长期对不齐。规范写초콜릿，很多人写초콜렛；规范写메시지，很多人写메세지；规范写리더십，很多人写리더쉽。

这类分歧在商品词里尤其多，因为新品类的名字往往先在市场上流传，规范才追认。做站的时候两边都不能丢：页面上的可见文本用规范写法，站内搜索的同义词表把民间写法映射过去。

如果某个民间写法的量远大于规范写法，那就得权衡了。保哥的做法是让规范写法出现在标题和主标题，让高频民间写法在正文里自然出现一次，两边都能接住，也不显得页面上错别字连篇。

## NFC和NFD，为什么让同一个词在库里对不上？

这是韩语站最隐蔽的一类事故，而且几乎不可能靠肉眼发现。

谚文的一个音节，在编码里有两种合法的存放方式：一种是把整个方块存成一个预组合的码位，另一种是把初声、中声、终声三个字母分开存，那些单独的字母在编码里有自己独立的谚文字母码表 (https://www.unicode.org/charts/PDF/U1100.pdf)。前者叫组合形式，后者叫分解形式，两者显示出来一模一样，字节完全不同。

问题出在不同系统的默认选择不一样。某些桌面系统的文件系统习惯用分解形式，而网页表单和数据库通常拿到的是组合形式。于是同一个商品名，从设计师电脑上传的图片文件名，和运营在后台敲进去的标题，字节层面根本不是一个东西。

## 三个必查的位置

一是文件名和上传路径，图片按商品名命名的站几乎必中；二是从外部导入的商品数据，尤其是经过多次导出导入的表格；三是用户提交的表单内容，输入法和粘贴来源不同，结果也不同。

处理办法是在入口统一：所有进入数据库和索引的文本，一律先做一次正规化转成同一种形式再存。这一步的成本极低，不做的话，你会花几周时间排查一个明明看起来一样却搜不到的鬼故事。

## 编码遗留会在什么地方咬人？

韩语早年通用的编码不是统一码，而是一套本地字符集，它在互联网登记里的名字带着1987年的年份标记。老系统、老导出文件、老邮件模板，很多还是那一套。

典型的翻车场景是：从旧系统导出一份商品表，直接喂给新站的导入程序，程序按统一码解读，出来的全是乱码方块。更阴的是半乱码，一部分字对一部分字错，因为两套编码的码位有重叠区。

唯一可靠的办法是在导入环节显式声明源编码，不要让程序猜。凡是猜编码的地方，早晚都会猜错一次，而且往往是在数据量最大的那一次。

## URL用谚文还是罗马字？

技术上谚文完全可以进地址，但要经过统一资源标识符规范里定义的百分号编码 (https://www.rfc-editor.org/rfc/rfc3986)，一个汉字或谚文字符会展开成九个字符。一个五字的品类名，在地址栏里就是四十五个字符的乱码串，复制粘贴到聊天窗口里没人认得出。

更现实的做法是地址走罗马字，页面上的可见文本用谚文。这样地址短、能读、复制传播不出问题，页面上的语言体验又完全是本地的。

做这件事只要记住一条：地址一旦定下来就别改。为了一点可读性的优化去批量改地址，收益远小于代价，这一条在任何语言上都成立。

## 罗马化按哪一套来才不会自己打架？

问题在于罗马化不止一套。学术界长期通行一套带附加符号的旧体系，而国家层面在2000年公布过一次修订，两套的结果差别很明显。

原词 | 旧体系 | 2000年修订式 | 

부산 | Pusan | Busan | 

김치 | kimch'i | gimchi | 

제주 | Cheju | Jeju | 

대구 | Taegu | Daegu | 

人名更乱，因为姓氏的拉丁写法是各家自己定的，同一个姓能写成好几种，护照上是哪种就是哪种，不跟任何标准走。

建站时的原则是：系统内部一律用同一套转换规则，保证地址和标识符可预测；面向用户展示的人名地名，尊重当事人和当地的既有写法。这两条不冲突，但混在一起做就会乱。

## 站内搜索为什么搜유모차搜不到유모차를？

因为默认的字符串匹配把助词当成了词的一部分。这是韩语站转化率损失最大的一处，而且它不会出现在任何外部工具的报告里，只有站内搜索日志才看得见。

解法按投入从小到大分三层，可以按顺序推进：

层级 | 做什么 | 大致投入 | 能解决什么 | 

第一层 | 空格归一，查询与索引都去掉所有空格再比对 | 半天 | 分写法两种写法的差异 | 

第二层 | 助词剥离表，把常见助词从查询尾部切掉 | 两三天 | 绝大多数带尾巴的查询 | 

第三层 | 接入形态素分析组件 | 一到两周 | 复合词切分与词形还原 | 

大多数电商站做完前两层就够用了。第二层要注意一个坑：剥离必须做得保守，比如의是助词，但모의、주의这些词本身就以의结尾，切掉就毁了。安全做法是维护一份不可剥离的白名单，宁可漏切也别切错。

## 筛选器和分类名里的助词，要不要带？

一律不带。筛选器上的标签、面包屑上的分类名、标签云里的词，全部用裸名词形态，因为它们不是句子成分，加助词反而不自然。

这一条看着琐碎，实际影响不小：这些位置的文本经常被拿去拼页面标题和描述，一旦带了助词，拼出来的就是半截句子。保险做法是在数据层就存裸形态，需要成句的时候再由模板按收音规则补助词。

## 谚文的字母顺序跟你想的一样吗？

不一样，而且这一条会直接影响索引页和字母导航的体验。

韩语按首字母排序，用的是初声的固有顺序，也就是ㄱ、ㄴ、ㄷ、ㄹ、ㅁ、ㅂ、ㅅ、ㅇ、ㅈ这一串，俗称가나다顺序。数据库如果用默认的二进制排序，出来的结果虽然凑巧接近，但在双辅音和外来语开头的词上会错位。

品牌索引页尤其要注意，韩国用户很习惯按가나다找品牌。这类语言相关的排序规则在国际化标准里有专门定义，配置数据库排序方式前值得先对照一遍，别让它按字节排。

## 表单和地址字段该怎么改？

照搬英文表单是韩语站最常见的低级错误，几个点必须改。

姓名合并成一个字段，韩国人的名字是姓在前，姓通常一个字，名通常两个字，拆成名和姓两个框会让人不知道怎么填。地址从大到小写，先道市再区洞再门牌，跟英文顺序完全相反。邮编在当时是六位数字，中间带一个连字符。

手机号有固定的三段格式，前缀是固定的那几个号段。验证规则一定要按本地格式写，别用一套国际正则糊弄过去，母婴品类的客户绝大多数是妈妈群体，注册环节任何一点摩擦，流失都是立竿见影的。

## 韩语的问句型查询长什么样？

韩国用户搜信息类内容有一批高度固定的后缀词，把它们收进词表，就等于拿到了内容选题的地图。

后缀词 | 意思 | 典型组合 | 

추천 | 推荐 | 유모차 추천 | 

후기 | 使用感受 | 아기띠 후기 | 

비교 | 对比 | 카시트 비교 | 

가격 | 价格 | 젖병소독기 가격 | 

순위 | 排行 | 분유 순위 | 

사용법 | 用法 | 유축기 사용법 | 

这几个后缀在韩国的搜索行为里权重很高，尤其是후기。韩国消费者对真实使用体验的依赖程度，比欧美市场高出一截，一篇像样的长评能带来的转化，往往超过三篇参数罗列型的文章。

## 搜索结果里的标题会被截在哪？

比你以为的早。谚文一个音节占的显示宽度接近两个拉丁字母，所以按字符数算标题长度的那套经验，搬到韩语上会严重高估能显示的信息量。

实际观感是：韩语标题能安稳显示的音节数，大约是英文标题字符数的一半。同样一条按英文习惯写的标题，翻成韩语之后，后半截被切掉的概率高得多。

对策只有一条但很有效：核心品类词放最前面，修饰语、品牌名、促销词一律往后排。母婴品类尤其要注意，很多站习惯把品牌名放在标题开头，结果真正的品类词被挤到显示区外面，等于白写。

还有一个细节：标题里的分隔符占位置。竖线、连字符、括号这些符号在韩语标题里出现得越少越好，能用空格解决的就别用符号。

## 文案里的标点要不要跟着改？

要，而且这是最容易露馅的地方之一。韩语的行文标点习惯跟中文不一样，逗号句号用的是半角形式，后面跟一个空格；书名和作品名用尖括号形式；括号里的补充说明前面通常不加空格。

直接把中文文案的全角标点搬过去，或者把英文文案的标点原样保留，都会让页面显得不是本地做的。这一层不影响搜索匹配，但影响信任感，母婴品类的用户对页面专业度的敏感度非常高。

省略号、破折号这类符号在韩语里用得比中文少，如果原文里到处都是，多半是翻译腔没清干净。标点这一项也应该进母语审校的检查清单，因为它可以在几秒内判定对错，性价比很高。

## 敬语层级要不要管？

对选词影响不大，对转化影响很大。

用户在搜索框里打的是最短形式，不带敬语，所以词表这一侧基本不用考虑。但页面上的文案不一样，韩语的语尾分好几个层级，商用文案通常用一种带敬意但不至于生硬的书面体。

用错的后果不是看不懂，而是别扭。语尾太随便，页面显得不专业；太庄重，又像政府公文。母婴这种高度依赖信任感的品类，这一层的分寸值得让母语审校单独过一遍。

## 界面会被韩语撑坏吗？

韩语的文本长度通常比英语短，所以撑爆按钮的情况不多，反倒是另一个问题更常见：断行。

谚文可以在任意音节处断开，浏览器默认也确实会这么断。于是一个完整的词被拦腰截成两行，读起来要停顿一下才反应过来。品类名和按钮文案上出现这种情况，观感是明显掉档的。

处理方式是给关键短语加上不换行的控制，让它整体折行而不是逐字断开。改动很小，但视觉上的提升非常明显，尤其是在窄屏上。

## 数字、日期和价格怎么写才像本地的？

货币是원，符号写在数字后面，千分位用逗号。日期习惯写成年月日用点隔开的形式，也常见带汉字单位的写法。

真正要注意的是大数的读法。韩语跟中文一样按万进位，十万写成십만而不是百个千。所以促销文案里出现的整数，尽量落在万的整数倍上，读起来才顺，看起来也才像是本地人定的价。

还有一条容易漏：韩国的商品价格普遍包含消费税，展示价就是最终价。把不含税价往上摆再在结账时加一笔，会被当成套路。

## 机器翻译在韩语上最容易犯哪三类错？

第一类是助词误用，尤其是主语助词和话题助词的混淆。这两个在语法书上都翻成主语标记，但语感差别很大，一段文字里全用同一个，读起来像机器人在念稿。

第二类是分写法错误，该连的连成一坨，该分的分得七零八落。这一类最伤搜索，因为它直接改掉了字符串。

第三类是敬语层级不统一，同一页里几种语尾混着来，前一句像跟朋友聊天，后一句像在发通告。这三条可以做成一张卡片发给内容团队，验收时对着扫一眼，比逐句读快得多。

机器翻译当初稿工具没有任何问题，问题只出在直接发布。跨语言的内容生产该怎么排流程，可以顺着把多语言内容当生产线而不是翻译任务来管 (https://zhangwenbao.com/multilingual-content-localization-production-pipeline-vs-translation.html)那套方法去搭。

## 母语审校该怎么验收才不流于形式？

给审校一份带判据的清单，比让人家通读一遍有效得多。清单上应该有：分写法是否与主写法一致、助词是否与前字收音匹配、外来语是否用了规范写法、语尾层级是否全页统一、品类词是否是本地人会用来搜的那个形态。

五条，每条都能在几秒内判定对错，审校的产出立刻从模糊的感觉不太对，变成可执行的修改清单。选词这一环怎么防止翻译腔，独立站关键词本地化的常见翻译陷阱与母语审校做法 (https://zhangwenbao.com/overseas-indie-keyword-localization-translation-traps-native-review.html)里那套流程可以直接搬过来用。

## 商品属性字典该怎么建才不会拼出病句？

母婴品类的属性特别多：适用月龄、承重上限、材质、可否折叠、是否可上飞机，一个婴儿车能挂十几条。这些属性值会被模板反复拼进标题、筛选器、面包屑和商品描述里，一处写法不对，全站几千个页面一起错。

字典的正确建法是把属性值直接存成它在句子里该有的完整形态，模板取用时不再做二次加工。比如适用月龄不要存数字6，要存6개월부터这样的完整片段，否则模板拼出来的就是半截话。

另一个容易出事的是属性名本身。韩语里的属性名习惯用汉字词，比如재질（材质）、용도（用途）、규격（规格），而翻译软件常给出更口语的固有词，两套混在一起，筛选器看起来就很不专业。做一份属性名的标准词表钉死，是投入最小回报最快的一件事。

## 属性值的排序也要单独定

月龄、体重这类数值属性要按数值排，不能按字符串排，否则会出现6个月排在12个月后面的荒唐结果。颜色、材质这类文字属性按가나다顺序排。这两条在建字典的时候就该定好，交给前端临时处理，各页面的顺序一定会不一致。

## 韩语的量词多到什么程度？

多到你必须建表。韩语数东西要在数字后面加一个分类词，而分类词跟着物品类别走，跟中文的量词很像但不完全对应。

分类词 | 数什么 | 母婴品类里的例子 | 

개 | 通用的个 | 젖병 3개 | 

장 | 薄片状 | 기저귀 30장 | 

대 | 机器与车辆 | 유모차 1대 | 

벌 | 成套衣物 | 배냇저고리 2벌 | 

켤레 | 成双的鞋袜 | 양말 5켤레 | 

통 | 罐装桶装 | 분유 2통 | 

更绕的是数字本身有两套读法：汉字数词和固有数词，而用哪一套取决于后面跟的是哪个分类词。개用固有数词，개월用汉字数词，所以三个是세 개，三个月是삼 개월。搞混了不影响理解，但一眼就是外国人写的。

落地建议是把分类词绑在商品分类上，一个品类配一个默认分类词，规格文案由模板按这个映射生成。数量在十以内的场合尽量避免把数字拼进句子，改用纯数字加分类词的写法，能绕开两套数词的坑。

## 品牌名转写成谚文有几种写法？

通常至少两种，多的时候三四种，而且往往不是官方那种赢。外来品牌进韩国市场，名字要转成谚文，转写规则和民间习惯经常打架，母婴这种依赖口碑传播的品类尤其明显——妈妈群里怎么打，市场上就流行哪种写法。

处理这件事的思路跟外来语写法完全一样：官方定一种作为正式写法，用在标题、品牌页和一切正式场合；同时确保流行的民间写法在正文里自然出现过一次；站内搜索把所有变体映射到同一个目标。

如果你要批量生成转写候选，可以借助国际化组件里的文字转换框架 (https://unicode-org.github.io/icu/userguide/transforms/general/)，它能按规则把拉丁字母串转成谚文，输出的候选拿去跟搜索量数据比对，比一个一个手工猜快得多。要提醒的是机器转写只能当候选池，最终定哪一个必须看数据。

还有一类特别容易被忽略：品牌名加助词的时候，助词形态取决于品牌名怎么读而不是怎么拼。拉丁字母写的品牌名后面直接接助词，程序按字符判断必然出错，这类必须走例外表。

## 关键词工具给的量为什么跟站内日志对不上？

因为两边的口径差着三层。第一层是助词，工具通常把带助词的变体单独计数，而你在站内看到的是同一批用户；第二层是分写法，带空格和不带空格在工具那里是两条记录；第三层是三层同义词，汉字词、固有词、外来语各算各的。

三层叠起来，工具报出来的单条数字往往只是真实需求的一小块。不做合并就直接拿工具数字排优先级，是韩语市场评估最常见的系统性错误，也是最容易在预算会上说服所有人做出错误决策的那种错误——因为数字看着很客观。

## 没有本地工具数据怎么办

三个土办法一直好用。一是拿自己站内搜索日志当第一手数据，哪怕流量不大，它记录的是真实用户在你品类里的真实打字习惯，比任何外部估算都准。二是看本地竞品的标题写法，排在前面的那批用的是什么形态，那大概率就是对的形态。三是找母语者做一轮小规模的说法采集，把同一件商品让十个人各写一遍，重合度最高的那个写法就是主写法。

这三招合起来的成本不到一天，但能把最关键的几十个品类词定死。至于长尾，等站内数据攒起来再说，不用一开始就追求完备。

## 内链的锚文本该带助词吗？

不带。锚文本用裸名词或者名词加修饰词的短语形态，别把它写成句子的一部分。

原因有两个。一是带助词的锚文本会把目标词的字符串改掉，等于每条内链指向的都是一个略有差异的词，主题信号被摊薄了。二是韩语的句子结构是修饰在前、谓语在后，如果锚文本嵌在句中并带着助词，很容易断在别扭的位置，读起来像被硬塞进去的。

实操上比较顺的写法是把链接短语单独成句或者放在句子的话题位置，比如以유모차 고르는 법这样的短语作锚，前后用逗号隔开。这样既保住了词形，也不至于让句子读起来磕磕绊绊。至于内链本身该怎么织成网，那是站点结构层面的话题，跟语言无关。

## 上线前的语言层检查清单

把这一篇压缩成可执行的动作，大概是十条：

检查项 | 怎么判定 | 

品类词写法 | 分写与连写两种形态哪个量大，主写法选对了吗 | 

助词拼接 | 模板是否按收音判定，例外表是否覆盖型号 | 

词表口径 | 建表是否按合并形态求和，而不是按原始串排序 | 

三层同义 | 汉字词、固有词、外来语是否都进了同义词表 | 

正规化 | 入库文本是否统一到同一种形式 | 

编码 | 导入环节是否显式声明源编码 | 

地址与标识符 | 罗马化规则是否全站一致 | 

站内搜索 | 空格归一与助词剥离是否上线，剥离白名单是否配好 | 

排序 | 索引页是否按가나다顺序而不是字节顺序 | 

表单 | 姓名、地址、邮编、手机号是否按本地格式 | 

这十条里，第二条和第八条的回报最快。前者让页面上的文案不再露怯，后者直接把站内搜索的空结果率压下去，两件事加起来通常一周就能做完。

## 韩国市场值不值得单独投一套内容？

看你的品类和耐心。韩国网购渗透率高、客单价不低、消费者愿意为使用体验付费，这些都是好消息。难点是本地竞争强，内容形态偏重实拍和长评，纯参数型的页面很难被认真对待。

还有一件事必须说清楚：韩国的搜索生态跟欧美不是一回事，本地的门户型搜索在很多品类上占着入口位置，它的内容偏好和评价逻辑自成一套。那一半功课属于引擎层，本篇不展开，出海韩国怎么做Naver的搜索优化 (https://zhangwenbao.com/naver-seo-korea-overseas-complete-guide.html)那篇讲得更细。

本篇讲的这一半是语言层，它的特点是做对了不会自动带来排名，但做错了会让后面所有投入归零。词写错了，内容再多也接不住流量；助词拼错了，页面再漂亮也显得不专业。这一层的性价比，在韩语上尤其高。

## 常见问题解答

## 韩语的关键词表，到底该用带助词的形态还是不带的？

建表用不带助词的形态，输出用真实查询里最常见的形态，这两件事要分开做。建表阶段必须把所有带助词的变体归到同一个单位下求和，否则同一个概念的量会被切成十几份，每一份看起来都不值得投入，你会系统性低估整个韩国市场。归一的时候顺手把空格也去掉，因为分写法的两种写法在语义上是一回事。输出阶段则要看用户真正在打什么，通常是裸名词加一个后缀词的组合，比如推荐、后记、价格这一类，页面标题就该用那个形态。判断方法最可靠的是自己的站内搜索日志，那份数据比任何外部工具都准，因为它记录的是真实用户在你的品类里的真实打字习惯。没有日志的新站，可以先按合并口径建表，上线一个月后再回头校准。

## 分写法的两种写法，页面上到底该用哪一个？

选量大的那个当主写法，另一个在正文里自然出现一到两次，绝对不要为两种写法各做一个页面。判断量的方法是把两种写法分别放进关键词工具查一遍，差距通常很明显。经验规律是词越短、越口语，连着写的量越大；词越长越专业，分开写的比例越高。定下主写法之后要全站统一，页面标题、主标题、面包屑、筛选器标签全部用同一种，不要一个页面一个样。还有一个容易被忽略的位置是商品名，运营在后台录入的时候习惯各写各的，最好在录入环节就做一次归一，或者至少在索引层面把空格去掉再比对。全站统一的收益不只是搜索，还有站内搜索的匹配率和数据统计口径的一致性。

## 助词自动拼接的程序，是不是必须懂韩语才能写？

不需要。判定收音只要一个取余运算，跟懂不懂韩语没有关系。谚文的音节区在编码里是按初声、中声、终声三层规律排布的，把字符的码位减去区块起点，再对28取余，余数为0就是没有收音，非0就是有收音，然后按这个结果在两种助词写法里选一个即可。整个逻辑不到十行代码。要注意三类例外：以流音收尾的字接方向助词时用短形式；数字和外语单词结尾要按读音判断，不能只看字符；产品型号一般不接助词，用括号或空格隔开更自然。把这三类做成一张例外表，比试图写一个万能规则实际得多。做完之后建议造一批测试数据跑一遍，覆盖有收音、无收音、流音收尾、数字结尾、型号这五种情况，一次验完就一劳永逸。

## 站内搜索一定要上形态素分析吗？

不一定，大多数电商站做完前两层就够了。第一层是空格归一，查询和索引都去掉全部空格再比对，半天工作量，直接解决分写法差异这个最大的匹配缺口。第二层是助词剥离，维护一张常见助词表，把查询尾部的助词切掉再比对，两三天工作量，能覆盖绝大多数带尾巴的查询。第三层才是接入形态素分析组件，它能处理复合词切分和更复杂的词形还原，但配置和调优要花一到两周，而且需要有人能判断切分结果对不对。做第二层的时候必须保守：有些词本身就以助词的字形结尾，无脑切掉会毁掉这些词，所以要维护一份不可剥离的白名单，宁可漏切也别切错。上线后拿站内搜索日志里的空结果查询做抽样，看看还剩哪些没接住，再决定要不要往第三层走。

## 正规化的问题，怎么快速判断自己的站有没有中招？

做一个最简单的实验：从后台复制一个商品名，粘贴到站内搜索框里搜一次，如果搜不到自己，那基本就是中招了。更系统的排查方法是写一个脚本，把数据库里的文本字段各取一份，分别转换成两种形式再比较，凡是转换前后字节不同的记录就是可疑对象。重点查三个地方：一是图片文件名和上传路径，按商品名命名图片的站几乎必中；二是从外部导入的商品数据，尤其是经过多轮导出导入的表格；三是用户提交的表单内容，不同输入法和不同粘贴来源的结果可能不一样。修复方式是在入口统一，所有进入数据库和索引的文本先做一次正规化转成同一种形式再存，同时把已有数据跑一遍批量转换。这件事的成本极低，不做的话你会花好几周排查一个明明看起来一样却搜不到的怪现象。

## 页面上的可见文本，要不要为了搜索去掉空格？

不要为了搜索去改可见文本的规范性，但要在数据层做归一。页面上的句子该有空格就有空格，把句子里的空格全删掉会让阅读体验变得很糟，本地人一眼就看出这站不是韩国人做的。真正该动的是三处：一是品类词和标题里的复合名词，按前面说的主写法统一；二是站内搜索的索引与查询，两边都去空格再比对；三是筛选器标签和分类名，用裸名词形态。这三处调整完，既照顾了用户的输入习惯，又没有牺牲页面的可读性。顺带说一句，搜索引擎对韩语分写法差异的容错这些年一直在改善，但它的容错是概率性的，你自己那一侧能控制的部分还是应该控制住，尤其是站内搜索，那是完全由你决定的地方。

## 三层同义词都要做页面吗？

不要。汉字词、固有词、外来语三层同义，只需要选一个当页面主词，其余两层进同义词表和正文，不要各做一个页面。三个页面讲同一个东西，结果是三个页面互相稀释，一个都排不上去。选哪个当主词看数据，电商语境里外来语的胜率通常更高，因为商品化的词更多来自外来语，但也有反例，价格这个概念上汉字词就明显占优。选定之后，另外两层的处理方式是：站内搜索的同义词表把它们映射到主词；正文里让其中一个自然出现一次，让页面能同时被两种查询理解；筛选器和标签统一用主词。还有一个实操建议：把这份三层对照表做成一张全站共用的词汇表，交给内容团队和翻译，能挡掉大量的用词不统一问题。

## 没有韩语母语同事，怎么控制内容质量？

用可判定的清单代替语感。给外部审校一份五到八条的检查表，每条都能在几秒内判断对错：分写法是否与主写法一致、助词是否与前字收音匹配、外来语是否用了规范写法、语尾层级是否全页统一、品类词是否是本地人真会用来搜的形态、数字和价格格式是否本地化、表单字段是否符合本地习惯。这样审校的产出就从模糊的读起来怪怪的，变成一份可执行的修改清单。另外强烈建议做一件事：上线后每周导一次站内搜索日志，看用户实际打进来的词形和你词表里的形态差多少。这份数据不需要懂韩语也能看出问题，凡是搜索量高但返回空结果的查询，就是你的词写错了或者搜索没配好，一条一条修过去，三个月下来质量会有肉眼可见的提升。

## 权威参考资料



## 同样是西班牙语SEO，西班牙人和墨西哥人搜的不是一个词

- URL：https://zhangwenbao.com/spanish-seo-es-es-latam-keyword-divergence.html
- 分类：小语种SEO
- 发布：2007-06-19  |  更新：2026-07-25
- 摘要：讲西班牙语SEO选词实战：es-ES与拉美变体的词汇分叉清单、vosotros与voseo的人称差异、按国家显式拆搜索量的口径、comprar与opiniones等意图词的地区偏好、加泰罗尼亚语等区域语言的取舍，以及特殊字符丢失的排查链路。
- 关键词：关键词研究,内容本地化,小语种SEO,西班牙语SEO

> **TLDR**：摘要：把西班牙语当成一门语言来做SEO，是出海站最贵的一个默认设置。西班牙人管电脑叫ordenador，墨西哥人叫computadora，阿根廷人两个都不常用；同一个动作在西班牙用vosotros，到了拉美全部换成ustedes；连搜索框里打不打重音符号，两边的习惯都不一样。更麻烦的是关键词工具默认按语言汇总数据，把二十来个市场的量堆在一起，看上去很美，落到具体国家全是空。下面按语言层拆：词到底差在哪几层、工具的数字该怎么读、什么时候必须拆成两套内容、拆到什么粒度就该收手。

> 摘要：把西班牙语当成一门语言来做SEO，是出海站最贵的一个默认设置。西班牙人管电脑叫ordenador，墨西哥人叫computadora，阿根廷人两个都不常用；同一个动作在西班牙用vosotros，到了拉美全部换成ustedes；连搜索框里打不打重音符号，两边的习惯都不一样。更麻烦的是关键词工具默认按语言汇总数据，把二十来个市场的量堆在一起，看上去很美，落到具体国家全是空。下面按语言层拆：词到底差在哪几层、工具的数字该怎么读、什么时候必须拆成两套内容、拆到什么粒度就该收手。

先讲一个真实的开局。一家做宠物用品的独立站，欧洲市场跑顺了之后想进拉美，第一步是把西班牙站的关键词表复制一份，改改货币和配送信息就上线了。三个月过去，墨西哥的自然流量停在两位数，团队一度怀疑是域名太新。

后来复盘发现，问题出在一个词上。这家店的主打品类是宠物笼具，西班牙站用的词是transportín，一个在伊比利亚半岛完全正确、也确实有搜索量的词。可墨西哥人找同一样东西时打进搜索框的是transportadora para perro，两个词的重合度接近于零。

换句话说，这家店在墨西哥做了三个月一个当地几乎没人搜的词。西班牙语市场最典型的亏损方式不是词选错了，而是词在另一个国家是对的——它在语法上、词典上、母语者的直觉上全都成立，只是不在那个市场的搜索习惯里。

## 五亿人说的语言，为什么不能当成一个市场做？

西班牙语的使用人口在全球排第二，覆盖二十来个把它当官方语言的国家，从欧洲的西班牙一路延伸到墨西哥、中美洲、加勒比、南美，再加上美国境内规模巨大的西班牙语人群。这个数字很好看，也很容易让人产生一种错觉：做一套内容就能吃下所有人。

问题在于，这些市场之间从来没有一个统一的语言中心在做同步。西班牙的日常用语受欧洲影响，墨西哥受美式英语影响，阿根廷有大量意大利语借词，加勒比地区又是另一套。四百年下来，同一个概念在不同地方长出了不同的默认说法，而搜索恰恰是最能暴露这种差异的地方。

SEO跟一般的本地化不同的地方在这里：翻译只要求读者看得懂，搜索要求你写的那个字符串正好是他打进框里的那一串。看得懂和会去搜，中间隔着整个市场。一个墨西哥人完全看得懂transportín，但他这辈子都不会主动打这个词。

## 差异集中在哪几类词上？

不是所有词都分叉。抽象概念、专业术语、正式书面语的通用程度相当高，一份讲宠物营养学的内容在两岸基本可以共用。真正分叉的是三类：一是日常用品和家居物件，二是食品和农产品，三是从英语借进来的技术词和商业词。

这三类恰好是电商品类词最密集的地方。也就是说，越靠近成交的那一层词，分叉越严重；越靠近科普的那一层词，越可以共用。这条规律对内容规划的意义很直接：博客文章可以跑一套，品类页和产品页必须分开做。

## 西班牙和拉美的差别，到底分几层？

把差异拆开看会更好下手。语言层的分叉大致有四层，从对SEO影响最大的往下排：词汇层、人称与语法层、拼写与标点层、口气与文体层。前两层直接决定关键词能不能命中，后两层决定用户会不会觉得这个站是本地的。

## 词汇层：同一个东西的几种叫法

这是最贵的一层。下面这张表是几个高频例子，看一眼就知道盲复制的代价：

概念 | 西班牙（es-ES） | 墨西哥 | 阿根廷 | 备注 | 

电脑 | ordenador | computadora | computadora | 拉美普遍用后者 | 

手机 | móvil | celular | celular | 差异极稳定 | 

汽车 | coche | carro / auto | auto | auto较中立 | 

果汁 | zumo | jugo | jugo | 食品类高频 | 

公寓 | piso | departamento | departamento | 房产类必分 | 

宠物提篮 | transportín | transportadora | transportadora | 品类词典型分叉 | 

注意最后一栏那个auto。在词汇分叉里经常存在一个相对中立的第三选项，两边都能接受、也都有一定搜索量。资源有限又必须共用一套内容时，选中立词是止损方案，但要清楚它换来的是两边都不是第一顺位。

还有一类更隐蔽的坑：同一个词在两个市场都存在，但意思不一样，甚至其中一边带冒犯意味。这类词没法靠查词典规避，只能靠当地人过一遍。真踩上了，损失的不是排名而是品牌，代价完全不在一个量级。

## 人称层：vosotros在拉美是不存在的

西班牙用vosotros作第二人称复数，整个拉美一律用ustedes。这不只是一个代词的问题，它牵着整套动词变位走。一句面向多人的文案，两边写出来的动词形态完全不同。

再往下还有voseo。阿根廷、乌拉圭、巴拉圭以及中美洲部分地区用vos代替tú，动词也跟着变形，比如tienes在这些地方说成tenés。用户不会拿这个当关键词搜，但页面上用错了，本地读者第一眼就知道这站不是给自己写的。泛西班牙语的规范词典对voseo在各地区的接受程度 (https://www.rae.es/dpd/voseo)有专门的条目，做南锥体市场之前值得先翻一遍。

还有一个称谓选择的问题。西班牙的电商文案普遍偏向非正式的tú，读起来亲切；墨西哥和哥伦比亚的商业内容更常用正式的usted，尤其是B2B和金融类。同一份文案照搬，要么显得没礼貌，要么显得端着。

## 拼写与标点层：那些容易被前端吃掉的符号

西班牙语的疑问句和感叹句要在句首加倒问号和倒感叹号，这是硬规范不是可选项。少了它们，句子在母语者眼里就是残缺的。麻烦在于这两个符号经常在开发环节丢失：编码没设对、模板转义、从表格导入时被清洗掉，都会让它们凭空消失。

元音上的重音符号同样。西班牙语的重音符号不是装饰，它区分词义：sí是是，si是如果；él是他，el是定冠词。产品标题里少一个重音，语法上就是另一个词。

## 文体层：数字、日期和长度

西班牙语的小数点用逗号、千位用点号，这一点和英语相反；日期是日在前月在后。价格显示上西班牙用欧元且符号在数字后面，墨西哥用比索且符号在前面。这些格式问题不影响排名，但影响转化，而且是那种用户说不清哪里不对、就是不想付款的不对。

另外提一句长度。西班牙语译文比英语原文平均长出两成到两成半，标题标签和按钮文案照着英文位置排版，到了西班牙语版本经常撑破。这个问题在移动端最明显，做视觉稿的时候就该按最长的那门语言留余量。

## 关键词工具给的西班牙语数据，为什么会骗人？

这是本篇最想讲清楚的一节。工具本身没问题，问题在于绝大多数人读它的方式。

## 默认口径是语言，不是市场

关键词工具的国家或地区设置如果不显式指定，很多时候给出的是这门语言在全球范围的汇总量，或者是某个默认国家的量。西班牙语因为覆盖国家多，汇总口径和单国口径的差距能到一个数量级。

更容易出事的是那种看起来两边都有量的词。汇总数字一万，你以为进哪个市场都能吃到，拆开看可能是西班牙九千五、墨西哥五百。做西班牙语选词，第一个动作永远是把国家维度显式切出来，一个市场一份表，别在汇总数据上做任何决策。

## 两个国家的搜索量不能相加

就算你已经拆开了国家，还有一个常见的算术错误：把ordenador在西班牙的量和computadora在墨西哥的量加起来，当成这个品类的总盘子，然后按总盘子的大小排优先级。

这个加法没有意义，因为它对应的不是一个页面能吃到的量。你的页面要么排西班牙要么排墨西哥，两边的排名难度、竞争对手、外链环境全都不一样。正确的做法是把每个市场当成独立盘子算投入产出，算完再决定先做哪个，而不是先合并再拆分。

## 词形变化会把量拆散

西班牙语名词分阴阳性、有单复数，形容词还要跟着名词变。zapato和zapatos、rojo和roja在工具里通常是四条独立记录。做词表汇总时如果只取单数阳性形式，会系统性低估这个词根的真实需求。

反过来，做页面时也别为每一种词形单开一个页面，那是老式的堆词打法，现在只会制造内耗。合理的做法是一个词根一个页面，标题用最主流的那种形态，正文里自然覆盖到其他形态。这套逻辑在屈折程度更高的语言里更极端，保哥在多语言市场关键词调研怎么做 (https://zhangwenbao.com/multilingual-keyword-research-cross-cultural-localization-query-language.html)里按语言分类讲过词形归并的处理方式，这里不重复。

## 零搜索量不等于零需求

拉美一些中小市场的采样密度本来就低，工具报零的比例明显高于英语。判断该不该做，别只看那个数字，看这个词背后是不是一个成立的需求：有没有明确场景、能不能对应一个具体产品、真人会不会这么打。三条都成立就值得做，这类页面的转化率往往高得反常，因为搜的人已经想得很清楚了。

## 西班牙语的搜索意图词，哪些是必须覆盖的？

选词只做品类词是不够的。真正决定一个页面能不能接住流量的，是品类词前后挂的那些修饰词，它们才是意图的载体。西班牙语有一套自己的高频修饰词，和英语的对应关系并不是一一对齐的。

意图 | 常用修饰词 | 该落到什么页面 | 注意 | 

购买 | comprar | 品类页或产品页 | 放在词首，comprar+品类是最标准的商业查询结构 | 

比价 | precio、precios | 产品页带价格模块 | 拉美市场对价格词的敏感度高于西班牙 | 

口碑 | opiniones、reseñas | 评测或评论聚合页 | reseñas在拉美更常用，opiniones偏西班牙 | 

低价 | barato、baratas、ofertas | 促销或折扣落地页 | 形容词要跟着名词的阴阳性变形 | 

物流 | envío gratis | 产品页或政策页 | 免运费在拉美是强转化信号 | 

教程 | cómo、para qué sirve | 内容页 | cómo带重音，少了就是另一个词 | 

比较 | mejor、mejores | 榜单页 | 复数形态对应清单型内容 | 

这张表里最容易被忽略的是形容词变形那一行。barato修饰阳性名词，barata修饰阴性名词，复数还要再变一次。做词表的时候如果只收了阳性单数，等于把一半的长尾漏掉了。

另一个值得注意的是para qué sirve这个结构，直译过来是这东西是干什么用的，它在西班牙语世界的搜索量高得出乎意料，尤其是保健品、工具、原材料这几类。英语里对应的问法分散在好几种句式里，西班牙语则高度集中在这一个结构上，做内容页时把它当成一个固定的标题模板用，命中率很高。

## 意图词和地区差异会不会叠加？

会，而且叠加之后的组合数比你想的多。品类词分叉，意图词也分叉，两者相乘就是四种组合，而其中通常只有一种是目标市场的第一顺位。举个例子，同一个查询在西班牙可能是comprar加西班牙那侧的品类词，到墨西哥就变成了另一个动词加另一个品类词，两条查询在字符层面完全不重叠。

处理办法是把词表做成两列结构：一列是意图词，一列是品类词，各自标注适用市场，然后按市场做笛卡尔组合，再用搜索建议逐条验活。这个动作听起来笨，但它是唯一能保证不漏组合的做法，而且做过一次之后可以复用到同一市场的所有品类上。

## 西班牙境内还有别的官方语言，要不要管？

这是个只有做西班牙市场才会遇到、又几乎没人提前想到的问题。西班牙除了西班牙语之外，还有几门在特定自治区享有官方地位的语言：加泰罗尼亚地区的加泰罗尼亚语、加利西亚地区的加利西亚语、巴斯克地区的巴斯克语，以及巴伦西亚地区在语言学上与加泰罗尼亚语高度接近的巴伦西亚语。

这些不是方言，是独立的语言，其中巴斯克语甚至不属于印欧语系，跟西班牙语的亲缘关系比西班牙语和英语还远。当地人口在日常和公共事务里大量使用它们，学校、政府网站、本地媒体都有完整的对应版本。

## 什么情况下值得做区域语言版本？

先说不需要做的情况，也是绝大多数情况：如果你是面向全西班牙销售的电商，做好西班牙语版本就够了，这些地区的居民全部通晓西班牙语，商业搜索也普遍用西班牙语进行，多做一套内容的边际收益很低而维护成本很高。

真正值得考虑的是三类：一是业务本身就集中在某一个自治区，比如本地服务、线下门店、区域性的B2B；二是品类带有强烈的地域文化属性，比如当地特产、地方旅游、传统工艺；三是需要投标或对接当地公共部门，这类场景对本地语言版本近乎是硬要求。

如果决定要做，有个成本很低的中间方案：不做全站翻译，只做几个关键落地页和联系页面的本地语言版本，再把品牌名、门店名、地址这些实体信息用本地语言写对。在区域语言市场，本地语言的一个联系页面，往往比十篇翻译内容更能建立信任。

## 还有一个更容易踩的小坑

就算你完全不做区域语言版本，品牌名和地名的写法也可能要处理。同一个城市在西班牙语和当地语言里拼法不同，用户按哪一种拼法搜索取决于他自己的习惯，而这两种拼法在字符层面是两个不同的字符串。做本地商户信息、门店页、服务覆盖区域列表时，把两种写法都自然覆盖到，是个投入极小的动作。

## 英语借词在西班牙语页面里该留还是该翻？

西班牙语对英语借词的态度比德语克制，比法语宽松。判断标准可以按三类分。

第一类是已经完全归化的借词，比如marketing、software、web这些，直接保留英文形式，硬翻回西班牙语反而丢搜索量，还会显得学究气。要注意的是它们在语法上已经被当成西班牙语名词，要跟着走性数配合。

第二类是西班牙语有成熟对应词、且对应词更常用的，优先用西班牙语。correo electrónico比email更正式也更常见于商业内容，descargar比download自然得多。尤其是结账流程里的功能性文案，冒出英文标签会让人怀疑网站的可信度。

第三类最有意思，是两个说法在两岸的选择正好相反的词。计算机鼠标在西班牙普遍叫ratón，在拉美不少市场直接用英语的mouse；电脑本身在西班牙叫ordenador，在拉美叫computadora，而后者本身就是从英语借来又本地化的产物。借词的接受度本身就是一个地区变量，它跟着市场走，不跟着语言走。

## 怎么快速定一个借词的取舍？

还是那招：把两种写法分别丢进目标市场的搜索框，看下拉建议里哪个能带出一串真实延伸，看结果页返回的是本地电商和本地媒体还是词典站。能带出延伸、且结果页是真实商业内容的那个，就是活的。

另外有个行业维度要考虑。互联网、营销、时尚、金融这几个领域的英文词密度天然高，用英文借词不但没问题还显得内行；而法律、医疗、政务、传统制造这几个领域正好相反，英文词用多了会被认为不专业。同一个客户在不同品类线上的用词策略可以不一致，没必要全站强求统一。

## 重音符号和ñ，到底要不要做两套写法？

先说结论：页面内容一律写规范形式，搜索意图的覆盖交给内容里的自然变体，别为不带重音的写法单开页面。

用户端的现实是这样：西班牙语键盘打重音符号很方便，母语者在正式场合基本都会打；但在手机上快速输入、或者用非西班牙语键盘时，不少人会省掉。所以同一个查询确实存在带重音和不带重音两个版本，两边都有量。

好消息是搜索引擎对这类变体的归一化处理相当成熟，带不带重音一般会被当成同一个查询处理。你的页面写规范形式，两种输入都能接得住。写不带重音的形式反而有风险：母语者看到会觉得是错别字，专业感直接打折。

## URL和文件名怎么处理？

URL建议做转写，ñ写成n、带重音的元音去掉重音。技术上URL里放非ASCII字符是可行的，编码传输、抓取索引都不会出问题，但复制粘贴出来是一长串百分号编码，发到聊天工具或者邮件里容易被截断，后台日志和分析报表里的可读性也很差。

正文该怎么写还怎么写，URL停在最安全的ASCII范围内，这是成本最低的组合。已经上线并且收录正常的站，别为这个专门做迁移，改URL的风险大过收益。这条判断在其他非拉丁语种上同样成立，做俄语市场时的取舍逻辑几乎一样，保哥在出海独立站关键词本地化的翻译陷阱 (https://zhangwenbao.com/overseas-indie-keyword-localization-translation-traps-native-review.html)那篇里有更细的清单。

## ñ这个字母还有一层身份问题

ñ在西班牙语里不是n加一个符号，它是字母表里独立的一个字母，排序上排在n之后。这个细节在做站内搜索、商品排序、A到Z索引这类功能时会露馅：用英语的排序规则处理西班牙语列表，ñ开头的词会被排到奇怪的位置。用户不会写邮件投诉这个，但它就是那种一点一点消耗信任的小事。

## 哪些环节最容易把重音符号和ñ弄丢？

这一节属于语言和技术的交叉地带，也是西班牙语站最常见的隐形失血点。特殊字符丢失往往不是一次性事故，而是某个环节长期在悄悄破坏，等你发现时已经污染了几千个页面。

第一个高发环节是数据库的字符集和排序规则。字符集不对，重音元音和ñ在写入时就会被替换成问号或者乱码；排序规则不对，字符能存进去但比较和排序会出错，站内搜索找不到带重音的词，商品列表的字母索引也会乱掉。这两个设置是两回事，经常只改了一个。

第二个是表格文件的导入导出。产品数据从表格工具导出成逗号分隔文件时，编码默认值经常不是通用编码，导出的文件用别的程序打开就是一堆乱码，再导进系统就把错误固化了。这个环节最坑的地方在于，导出的人和导入的人往往不是同一个人，谁都没看到中间那一步。

第三个是模板层的转义。内容从后台到页面要经过好几次转义和反转义，某一层多做或者少做一次，特殊字符就会变成实体编码直接显示在页面上。这类问题在标题标签和结构化数据里特别常见，因为它们不在正文的视觉焦点上，肉眼扫过去不容易发现。

## 还有一个很少有人查的地方：字体子集

为了压缩体积，网页字体经常做子集化，只保留用得到的字符。子集规则如果按英文字符集裁的，带重音的元音和ñ会缺字形，浏览器只能退回系统字体渲染，视觉上就是同一行字里几个字母突然换了字体。这不影响抓取和排名，但它是那种一眼就显得业余的细节。

## 怎么系统性地查一遍？

有个很省事的自检办法：造一个测试字符串，把西班牙语所有特殊字符塞进去，包括五个带重音的元音、带分音符的ü、ñ，以及倒问号和倒感叹号。然后让这个字符串走完整条链路：从表格导入、进数据库、出接口、进模板、渲染成页面、再被抓取一次。每一站都比对一次，哪一站变形了就锁定在哪一站。

这个动作花不了半天，但能一次性拦掉后面几年的零散问题。顺带提一句，语法层面的一些地区差异同样值得建成检查项，比如代词用法上的地区偏好，泛西班牙语规范词典里关于leísmo的条目 (https://www.rae.es/dpd/le%C3%ADsmo)就把哪些用法在哪些地区被接受讲得很细，做正式文案时可以当成裁判依据。

## 什么时候必须拆成两套内容？

拆分是要花钱的，判断标准要硬。可以按三层依次过，任何一层触发就该拆。

判据层 | 触发条件 | 不拆的后果 | 

核心品类词 | 主打品类在两地叫法不同 | 等于放弃其中一个市场的品类流量 | 

货币与支付 | 欧元与本地货币、支付方式差异大 | 价格页本来就要分，边际成本很低 | 

法务与配送 | 退换货规则、税费、时效完全不同 | 信息错误直接影响转化和纠纷率 | 

第一层最关键。如果你卖的东西恰好落在分叉最严重的那三类词里，不拆就是在两个市场之间选一个放弃。反过来，如果你做的是抽象服务、专业工具、B2B解决方案这类词汇通用度高的品类，一套内容加一份本地化的价格与联系信息，往往就够用了。

## 拆到什么粒度就该收手？

常见的过度拆分是按国家一路拆到底，二十个国家二十套内容，结果是每套都薄、每套都没人维护。比较务实的做法是分两到三档：西班牙一套，拉美通用一套，再视生意体量把最大的那个单一市场单独拎出来。

拉美通用那一套用中立词汇打底，避开各国专有的说法，覆盖大部分中小市场。真正需要独立版本的，通常只有你营收占比最高的那一两个国家。

要提醒的是，拆分之后还有个坑：几个版本内容高度相似时，最常出的问题不是排名互相分流，而是搜索引擎判定其中一个版本缺乏独立价值，干脆不给收录。这比分流更难发现，因为报表上看不出来，只有做收录抽查才会暴露。同语言多地区的这套架构问题，保哥在同一种英语卖到美英澳该怎么办 (https://zhangwenbao.com/international-seo-same-language-multi-region-en-us-gb-au-duplicate-content-hreflang.html)里按英语市场拆过一遍，机制在西班牙语这边完全通用。

## 拉美内部还要不要再往下分？

要，但分的方式和西班牙与拉美那一刀不一样。拉美内部的差异更像是同心圆：核心词汇大面积通用，边缘词汇各有各的说法。

可以按市场规模和词汇独特性两个维度排个序。墨西哥人口最多、搜索量最大，本身就该单独考虑；阿根廷的语言独特性最强，voseo加上大量本地词，共用内容的违和感最明显；哥伦比亚的西班牙语被认为相对中性，常被当成拉美通用版本的基准；智利的口语词最难懂，但书面商业语言接近通用形态。

比较省事的路径是先做墨西哥，把它当成拉美的第一站，然后用它的内容作为基线向外扩，遇到明显不通用的词再做局部替换。这比一上来就规划八个国家版本现实得多。

## 美国境内的西班牙语市场算哪一档？

这是个经常被忽略的大盘子。美国有数千万西班牙语使用者，他们的语言习惯以墨西哥变体为主，但混杂了大量英语借词和英西混用的表达。做这个人群时有两个特点要注意：一是搜索行为经常在两种语言之间切换，同一个人可能先用英语搜品类、再用西班牙语搜具体问题；二是本地化的重点不是词汇而是场景，配送、退货、客服语言这些信息比语言变体更影响转化。

在语言标签上，这个人群通常对应美国境内的西班牙语标注。标签本身怎么写、跟地区码怎么组合，属于标准范畴，W3C关于语言标签的说明文章 (https://www.w3.org/International/articles/language-tags/)把语言、脚本、地区三段的组合规则讲得很清楚，做多市场标注之前值得当成基础读一遍。

## 西班牙语页面的信任信号，跟英语站差在哪？

语言做对了只是及格线。西班牙语市场对本地感的敏感度比英语市场高，几个信号缺一个就掉一截。

第一是联系方式的本地形态。电话号码要按当地格式写，地址顺序按当地习惯排，营业时间标注当地时区。用国际格式写一串数字，读者要在脑子里转换一次，转换的这一秒就是信任流失。

第二是支付方式。拉美的支付习惯和欧洲差别很大，分期付款在墨西哥和巴西的普及度远超欧洲，本地转账和现金支付渠道在部分市场仍然占很大比例。支付方式的图标在页面上出现得早一点，转化率的差别相当明显。

第三是客服语言的明确承诺。写一句用西班牙语提供客服、并且标明响应时段，比什么都管用。反过来，一个全西班牙语的站点在客服页面突然冒出英文表单，前面积累的本地感会瞬间清零。

## 正式度这件事怎么定？

建议在项目开始时就把称谓口径写进内容规范里，全站统一，别让每个译者自己发挥。定的方式很简单：看目标市场、看品类、看客单价。面向年轻人的快消品可以用tú，面向企业客户或者高客单价品类用usted更稳。定完之后写进给译者的简报，验收时把两个词各搜一遍，混用了就打回。

## 一套能复用的西班牙语选词流程长什么样？

把前面的判断串起来，就是一条可以重复跑的流程。

第一步是定市场清单，别做泛西班牙语，明确写出这一轮要做哪一个或哪几个国家。第二步是拿目标市场的种子词，来源优先用当地竞品的页面标题、当地平台的类目名、当地用户在社区里的原话，而不是从英语词表翻译。

第三步是显式设定国家做搜索量拉取，一个市场一份表，不合并。第四步是把词形变体归并到词根，统计需求的时候合并，做页面的时候只用主流形态。

第五步是交叉验证，把拿不准的词分别丢进目标市场的搜索里，看搜索建议里出现哪一个、结果页返回的是真实的本地内容还是一堆词典和翻译站。返回词典站的词，多半是被造出来的，不是活的。

第六步是本地人过一遍。这一步没法省，也没法用工具替代。要求很低：不需要他懂SEO，只要他把词表读一遍，圈出哪些词他自己不会这么说。这一步平均能筛掉一成到两成的词，而且筛掉的往往是你最看重的那几个。

## 怎么验证一个词是不是活的？

有几个不花钱的土办法很好用。一是看搜索建议，把词打进目标市场的搜索框，看下拉里有没有它以及它的延伸；活词一定会带出一串延伸，造出来的词往往一片空白。二是看结果页的构成，返回的是本地电商、本地媒体、本地论坛，说明这个词在当地的内容生态里真实存在；返回的全是翻译网站和词典，基本可以判死。

三是看当地平台的类目名。区域性的电商平台在拉美的渗透率很高，它们的类目结构本身就是一份经过千万次搜索验证的词表，比任何工具都贴近真实叫法。四是看当地媒体的用词，报道同一个品类时用的是哪个词，那通常就是最中性、最安全的选择。

## 交给译者和审校时该提哪些要求？

不懂西班牙语也能做一轮结构性验收，能拦掉大部分低质量交付。

先看倒问号和倒感叹号在不在，疑问句句首缺符号说明译者不规范或者中间环节把它吃掉了。再看重音符号有没有系统性缺失，整篇一个重音都没有，基本可以判定是机翻或者编码出了问题。

接着搜vosotros，做拉美市场的稿子里出现它就是没做地区适配。再搜tú和usted，同一个页面上两种称谓都出现就是没统一口径。然后看数字和日期格式，小数点用逗号、日在前月在后，照搬英文格式的稿子一眼能认出来。

最后一步照例没法省：找一个真正在目标市场生活的人读一遍首页和三个主要落地页，不要求他懂SEO，只问一句读起来像不像本地公司写的。这一步花的钱远比返工少，而且往往能问出几个工具永远给不出的词。至于这些内容用什么流程组织生产、翻译和原生创作怎么分工，属于另一个话题，多语言内容本地化生产线 (https://zhangwenbao.com/multilingual-content-localization-production-pipeline-vs-translation.html)那篇讲得更系统。

## 常见问题解答

## 做西班牙语市场，应该先做西班牙还是先做拉美？

看生意结构，不看人口。西班牙的优势是市场成熟、支付和物流体系接近欧洲标准、客单价高、竞争相对透明，缺点是竞争已经比较充分，做起来慢。拉美的优势是盘子大得多、竞争密度低、内容质量的整体水位不高，一份认真做的本地内容比较容易冒头，缺点是物流成本、支付通过率、客服时区这些运营层面的问题都要额外解决。如果你的产品客单价高、依赖售后服务，西班牙更容易跑通；如果产品标准化程度高、物流不复杂、走量，拉美的增长空间更大。还有一个务实的判断维度是团队所在地和时区，客服能不能覆盖到目标市场的白天，这件事对转化的影响经常超过SEO本身。真要二选一又拿不准，建议先看现有的自然流量里有没有来自西班牙语国家的零星访问，那份数据比任何市场报告都贴近你自己的生意。

## 一套内容加一份地区标注，能不能糊弄过去？

要看品类。词汇通用度高的品类可以，比如软件、专业服务、抽象方法论这类内容，词表的分叉比例往往不到一成，做一套通用版本加上本地化的价格、联系方式和法务信息，性价比很高。但如果你的核心品类词恰好落在日用品、食品、家居这几类分叉最严重的领域，一套内容就等于在两个市场里选了一个放弃。判断方法很简单：把你最重要的二十个词分别在两个市场查一遍，统计有多少个的第一顺位说法不同。分叉比例低于两成，共用；超过四成，必须拆；中间地带就看这些词贡献的营收占比。另外提醒一句，就算决定共用，产品标题和品类页的主词也建议做区域覆写，这是投入产出比最高的一处局部拆分，改动量很小，效果很直接。

## 关键词工具查不到拉美小市场的数据怎么办？

换数据源，别硬等工具。第一个来源是搜索建议，把种子词打进目标市场的搜索框，下拉给出的延伸词本身就是真实查询的采样，而且是免费的、实时的、按地区的。第二个来源是当地电商平台的类目结构和站内搜索建议，这些类目名是被千万次真实搜索验证过的说法，比翻译准确得多。第三个来源是当地社区和问答平台里用户的原话，尤其是抱怨帖和求推荐帖，里面的表述最接近真实搜索语言。第四个来源是你自己站内搜索的日志，只要有一点点自然流量，用户在你站内搜什么就是最直接的答案。这四类数据都拿不到绝对的搜索量，但它们能回答一个更重要的问题：这个词是不是活的。有了这个判断，再用相邻大市场的量做粗略的比例推算，足够支撑优先级排序。

## 西班牙语标题比英文长两成，标题标签老被截断怎么处理？

先接受一个前提：截断本身不是灾难，核心词被截掉才是。所以第一原则是把最重要的那个词放在最前面，就算尾部被砍，关键信息也已经出现了。第二是把品牌名放最后，必要时让它被截掉，这点损失远小于核心词被砍。第三是主动删掉低价值的修饰成分，西班牙语的介词结构比英语啰嗦，de、para、con这类连接词在标题里能省则省，语法上稍微松一点没关系，可读性不受影响。第四是别在标题里塞同义词，两个意思相近的长词并排会让标题瞬间超长，还显得刻意。最后提醒一点，搜索结果里的标题是按显示宽度截断而不是按字符数，后台看到的字符数和实际显示不是一回事，做西班牙语站最好直接用能预览显示宽度的方式确认，别靠数字符。

## 倒问号和倒感叹号会不会影响搜索匹配？

不影响匹配，但影响别的东西。搜索引擎在处理查询和页面文本时会做标点归一化，用户搜索时几乎不会打倒问号，页面上有没有它不改变匹配结果。所以纯从排名角度说，这两个符号可有可无。但它们影响两件事：一是母语者的专业感判断，标题里出现一个没有开头倒问号的疑问句，在西班牙语读者眼里就像英文句子首字母没大写，第一印象直接扣分；二是这两个符号在技术链路上最容易丢失，如果它们不见了，通常说明你的编码设置、模板转义或者数据导入环节有问题，而同一个问题多半也在悄悄破坏重音符号和ñ。所以更实用的用法是把它们当成一个健康度探针：页面上倒问号还在，说明这条链路是干净的。

## 拉美各国的客服和内容团队要不要分开配？

内容可以合，客服很难合。内容层面，拉美通用版本加局部覆写的模式已经被验证可行，一个熟悉区域差异的编辑加上各国的兼职审校，就能覆盖大部分市场，成本可控。客服则是另一回事，难点不在语言而在时区和支付纠纷。拉美横跨好几个时区，加上和欧洲、亚洲总部的时差，人力排班的复杂度远高于内容生产。比较现实的做法是内容集中生产、客服按时区分组，把响应时段明确写在页面上，别承诺做不到的实时响应。另外一个经常被低估的点是退换货政策，各国的消费者保护规则差异不小，这部分内容必须逐国核实，不能共用模板。写错了不只是转化问题，还可能是合规问题，这条比语言层的任何一个坑都贵。

## 西班牙语内容的用户评论和社会证明，能不能跨市场共用？

能共用一部分，但要分清哪部分能共。产品本身的使用体验、材质反馈、尺码建议这类内容跨市场通用度高，一条来自西班牙买家的评价对墨西哥买家依然有参考价值，直接展示没问题。不能共用的是涉及物流时效、关税、退换货体验、客服响应的那部分，这些描述在另一个市场是错的，展示出来反而制造预期落差，售后纠纷会跟着上来。比较稳妥的处理是把评论按市场打标，通用维度的全站展示，涉及本地服务的只在对应市场展示。另外有个容易忽略的细节：评论里的用词本身就是一份免费的地区词表，同一个产品，两个市场的买家自发使用的名词经常不一样，这些原话比任何工具给的数据都真实，值得定期导出来看一遍，往往能捞到几个你词表里根本没有的活词。数量上还有一条经验，本地语言的真实评论哪怕只有十几条，对转化的推动也强过几百条翻译过来的评论，用户对翻译腔的辨识力比想象中高得多。

## 权威参考资料



## 小语种关键词表里那些没人搜的词，多半是当年拿词典逐词换出来的

- URL：https://zhangwenbao.com/keyword-literal-translation-legacy-cost-non-english.html
- 分类：小语种SEO
- 发布：2006-11-09  |  更新：2026-07-26
- 摘要：小语种关键词直译会留下哪些长期损失？讲清直译词为何语法全对却没人搜、损失怎么按三层计算、改与不改的代价对比与新词表的产出流程。
- 关键词：关键词研究,多语言SEO,内容本地化,小语种SEO

> **TLDR**：摘要：一个概念在目标语言里通常有好几个说法，词典把它们并排列出来，却不会告诉你哪一个是当地人真正打进搜索框的那一个。逐词替换出来的词表因此常常语法全对、意思也对，就是没有搜索量。真正的麻烦不在选错了词，而在这批词很快会长进地址、内部锚文本和外部引用里，越往后越难拔。这篇讲清直译词错在哪一层、损失怎么按三层累加，以及历史词表该按什么顺序清理。

> 摘要：一个概念在目标语言里通常有好几个说法，词典把它们并排列出来，却不会告诉你哪一个是当地人真正打进搜索框的那一个。逐词替换出来的词表因此常常语法全对、意思也对，就是没有搜索量。真正的麻烦不在选错了词，而在这批词很快会长进地址、内部锚文本和外部引用里，越往后越难拔。这篇讲清直译词错在哪一层、损失怎么按三层累加，以及历史词表该按什么顺序清理。

## 逐词直译出来的词，为什么语法全对却没人搜？

## 词典给的是概念对应，不是使用频率

翻词典查一个商品名，通常会得到两到四个并列的对应词。

词典的职责是把概念说清楚，它没有义务告诉你哪一个用得最多。

并列的这几个词在语义上确实都对，在使用场景上却分得很开。

有的属于书面语，有的属于口语，有的只在特定行业里用。

搜索框里出现的几乎总是口语那一个，而词表编写者最容易挑中书面语那一个。

挑中的原因也很朴素：书面语那个词通常排在词条的第一位。

词条里义项的排列依据也值得说清楚：多数词典按语义派生关系或历史出现顺序排，而不是按今天的使用频率排。所以排在第一位的往往是最古老或最核心的义项，未必是今天最常用的那个，直接取第一条等于随机取。

还有一类容易误判的是所谓的中性词。词典把它标成通用，实际使用中它可能只在书面语里出现，口语里另有一个说法。词典没有义务标注这种分布，能标出地区和领域已经算详尽了。

## 一个概念在目标语言里有几个候选

候选数量跟这门语言的历史层次有关，层次越多候选越多。

经历过多次语言接触的语言，同一个概念往往有本土词、早期借词和近代借词三层。

三层词在正式程度、年龄分布和地区分布上都不一样。

拿一个西语里表示轻便鞋类的常用词做例子，词典条目里并列的几个义项 (https://dle.rae.es/zapatilla)就跨了运动、家居和地区用法三种情形。

要判断哪一个进词表，光看词条排序完全不够。

需要的是使用频率数据，而这恰恰是词典不提供的那一部分。

这三层词的年龄分布可以反过来用：本土词的使用者偏年长，近代借词的使用者偏年轻。做投放分组和内容语气时，选哪一层词其实就等于选了目标人群，这一点在词表阶段就能规划，不必等到投放才发现。

## 用户实际打进搜索框的是哪一个

搜索框里的用词跟日常口语还不完全一样，它更短、更具体、更接近商品标签。

用户不会打一个完整的句子，他打的是自己在货架上看到的那个词。

所以判断依据应该是这个市场的零售场景，而不是这门语言的书面规范。

货架标签、包装正面、本地店铺的分类导航，这三处的用词最接近搜索用词。

这三处都不需要懂这门语言就能看，拍几张照片就够了。

比起翻词典，这个办法笨，但命中率高出很多。

本地零售站的分类导航是最值得抄的一份骨架。那套层级名是本地商家自己反复调整过的结果，背后已经隐含了一轮真实的用户测试。照着它搭自己的分类结构，比按源市场的分类硬翻要贴合得多。

还有一个几乎零成本的来源：目标市场的比价站和优惠信息站。这类站点的标题是为了让用户一眼看懂而写的，用词比品牌自己的官网更贴近日常，抄它们的说法基本不会错。

## 直译词与本地词的分布差在哪

直译词并不是完全没有搜索量，它通常有一点，只是数量级不同。

常见的比例是本地常用词的搜索量是直译词的几十倍。

更麻烦的是这点搜索量会给人一种词选对了的错觉。

页面上线之后确实有零星流量进来，排名也不错，因为几乎没有竞争。

没有竞争的原因不是你抢到了先机，是这个词本来就没人搜。

在一个没人去的路口立块牌子，牌子做得再好也没用。

零星流量还会污染判断：直译词页面的转化率经常异常地高，因为能搜到这个词的人本来就极少且极精准。团队看到转化率好，反而认定这批词质量高，于是继续按同样的方式扩词，越走越偏。

另一个误判来源是排名指标看着很漂亮。没人搜的词自然也没人竞争，排名稳居前列，做成报表递上去相当好看。这类页面的问题跟内容本身无关，跟当年那批靠堆词冲上去的页面也不是一回事，2003年那次波及面很广的算法调整 (https://zhangwenbao.com/google-florida-update-2003-explained.html)清理掉的是堆词，而这类页面连堆的机会都没有。

## 直译最容易在哪几类词上翻车？

## 品类名

品类名是翻车最多的一类，因为它看起来最简单。

越是基础的概念，在目标语言里的候选词越多，因为它进入这门语言的时间最长。

而且品类名往往有一个正式名称和一个日常名称，正式名称只在法规和说明书里出现。

词典默认给的是正式名称，用户搜的是日常名称，两者可能连词根都不一样。

品类名一旦选错，整个分类页的主题信号就是错的，下面所有商品页跟着受影响。

这是所有词类里最该优先核对的一类，没有之一。

品类名还有一个上位词陷阱：直译很容易选到一个层级更高的词，把具体品类翻成了它所属的大类。页面从此要跟整个大类的页面竞争，而它的内容深度只覆盖一个细分，怎么写都赢不了。

判断有没有掉进这个陷阱有个简单办法：把译出来的词搜一遍，看返回的结果是不是比你的商品范围宽得多。宽得多就说明选到了上位词，要往下再找一层。

还有一个反过来的陷阱：为了避开大类词而选了一个过于细的说法，细到本地用户根本不用它区分。这种词的搜索量同样接近于零，只是失败的方向相反，判断办法仍然是看搜索结果的覆盖范围。

## 属性与规格词

属性词的坑在于它经常有两套体系：技术参数用一套，用户描述用另一套。

技术参数那套通常直接借用国际写法，用户描述那套是本土的。

直译的时候容易把两套混在一起，出来的组合本地人根本不会那么说。

还有一类属性词涉及尺寸与容量的分档习惯，各地的分档方式本身就不一样。

硬把源市场的分档翻译过去，会造出一批目标市场不存在的规格。

这类词造成的损失比品类名小，但数量多，累加起来相当可观。

分档差异还会直接影响筛选器的设计。源市场按三档分的尺寸，目标市场可能习惯按五档分，照搬源市场的档位会造出用户在本地货架上从来没见过的选项，点击率极低还占着界面位置。

属性词还要注意单位与数值的书写习惯。同一个规格在两个市场可能用不同单位表达，用户搜的是自己熟悉的那个单位下的数值，硬把源市场的数值搬过去，等于把这批查询整个让出去了。

## 动作与意图词

购买、配送、退换这类动作词是意图信号的载体，直译错了意图就偏了。

同一个动作在不同语言里的常用说法差别很大，有的用动词，有的用名词短语。

比如表示运送这件事，瑞典语词典里那个偏货运的词条 (https://svenska.se/saol/?sok=frakt)与日常说配送的词并不通用，混用会让页面读起来像物流公司而不是零售店。

更隐蔽的是这类词往往跟介词或格形态绑定，换一个词整个短语结构都要跟着改。

直译只换了中心词、没改结构，出来的短语语法上勉强成立，读着就是不对。

而用户搜的正是那个完整的短语，不是单独的中心词。

意图词译错的后果是页面进错了结果集合。比如把面向批量采购的说法译成了一个偏零售的词，这个页面从此就不再出现在采购类查询里，而那恰恰是它真正的目标人群。这类错误在数据上看不出来，因为它影响的是从未发生过的曝光。

## 品牌名与型号

品牌名理论上不用翻译，实际上经常被翻译，尤其是含有普通名词的品牌。

更常见的问题是品牌名进入目标语言之后会被本地化拼写，或者被接上格尾。

直译词表里通常只有品牌原形，缺了本地拼写和变形形态。

型号则相反，它经常被过度处理：加了空格、改了连字符、把字母换成本地写法。

型号这类字符串必须原样保留，任何改动都会让精确匹配落空。

保哥见过一个做美妆工具的站，把型号里的字母全部换成了本地字母，一年之后才发现型号搜索一条都接不到。

常见错拼形态的收集办法很直接：翻站内搜索日志里那些返回零结果的查询。那里面绝大多数就是用户的真实拼法，只是你的词表里没有。把它们整理一遍加进正文，能接住一批本来白白流失的精准流量。

型号里的分隔符也要单独处理：同一个型号，有的用户打空格，有的连着打，有的照着包装打连字符。这几种形态在匹配时可能被当成不同的字符串，所以型号词要按几种常见的分隔写法各覆盖一遍。

把字母换成本地字母这个错误其实属于字符层面的问题，跟编码与字符层那一套问题 (https://zhangwenbao.com/cyrillic-encoding-legacy-windows1251-utf8-indexing-cost.html)是同一类根源：看起来一样的字符在系统里是不同的东西，人眼检查永远发现不了。

## 直译词和本地词的差距能不能量化？

## 反向验证：把词丢回搜索框看返回什么

最快的验证办法是把候选词直接搜一遍，看返回的是什么类型的结果。

如果返回的全是词典、百科和语言学习网站，说明这个词在商业场景里没人用。

如果返回的是本地零售站和比价站，说明这个词就是用户在用的那个。

返回结果混杂的情况也很常见，那说明这个词一词多义，需要加限定词才能用。

这个方法不需要任何工具，也不需要懂这门语言，看域名和页面类型就够。

五分钟能验十个词，是投入产出比最高的一步。

除了看结果类型，还要留意结果页上有没有出现购物类的展示形式。这类展示通常只在系统判定查询带有商业意图时才触发，它的出现本身就是一个很强的信号，说明这个词确实是买家在用的词。

验证的时候顺手记一下每个词返回结果的首页里有几家是跨国大站、几家是本地小站。本地小站占比高说明这个词是本土市场自己的说法，跨国站占比高则可能说明这个词是被翻译进来的，跟你的处境一样。

## 抓本地零售站的标题做词频

更系统的办法是把十到二十家本地零售站的商品标题抓下来，做一次词频统计。

频次最高的那批词就是这个市场的实际用词，不需要任何语言学判断。

统计时要按品类分开，不同品类的高频词差别很大，混在一起会互相稀释。

把这份词频表和自己的词表并排一放，缺了什么、多了什么一目了然。

还能顺手看出本地标题的写法结构，比如属性词放前面还是后面。

这份表做一次能用很久，值得作为进入一个新语言市场的固定动作。

统计时要连二元组一起数，不能只数单词。很多品类名在目标语言里是两个词的固定搭配，只统计单词会把搭配拆散，两个词各自的频次都不高，结果整个搭配从词表里漏掉了。

抓下来的标题还有一个副产品：属性词在标题里的排列顺序。这个顺序在不同语言里差别很大，照着本地习惯排的标题读起来自然，用户扫一眼就能确认是不是自己要的东西。

## 用词典例句与语料频次粗筛

没有条件抓标题时，退而求其次可以看词典给的例句。

例句反映的是这个词的典型使用场景，商业场景的例句多，说明这个词在市场里活跃。

有些词典还会标注词的使用领域和地区限制，这两个标注比义项排序有用得多。

比如罗马尼亚语词典里表示鞋类的那个总称词条 (https://dexonline.ro/definitie/incaltaminte)不但给义项，还直接把完整的变格形态列了出来。

拿到形态之后可以顺手判断这个词进了词表会展开成几个形式。

展开数量多的词，在做页面时要考虑标题里用哪一个形式最自然。

词典的领域标注比义项排序有用得多。标着技术、正式、旧式或者限定地区的词，基本可以直接从商业词表里排掉。这几个标注是词典编者花了很大力气才给出的判断，恰恰是最容易被使用者跳过的那部分信息。

如果这门语言有公开的国家语料库，那是比词典更好的来源，因为它直接给频次。语料库通常偏书面，用来排除低频词很准，用来确认高频词则要再配合零售标题核对一遍。

## 为什么当年的直译习惯会一直留在站里？

## 词表一旦定了下游全部继承

词表在多语言项目里是最上游的产物，它一定，后面所有环节都照着做。

页面标题从它来，导航分类从它来，商品属性字典从它来。

广告投放的关键词也从它来，于是错误还会被复制到付费渠道。

更彻底的是产品数据库里的分类字段，那可能是几万条商品记录共用的值。

改一个词表条目，要动的地方远比想象的多，这就是它留下来的第一层原因。

越晚发现，继承链越长，拔起来越费劲。

付费渠道往往是最早暴露问题的地方。同一批词投进去，几天内就能拿到点击数据，哪些词有量哪些词是死的一目了然。用很小的预算跑一周，等于给整份词表做了一次快速体检，比等自然结果快几个月。

还有一处继承很容易被忽略：内部搜索的同义词配置。这份配置往往是照着词表一次性生成的，词表错了，站内搜索也会跟着接不住用户输入的正确说法，而这一层的用户已经在站里了，损失更可惜。

## 地址与目录名固化

如果地址里包含品类名，那这个直译词就被写死进了地址。

地址一旦被收录并且有外部链接指向，改动的代价就不再是技术代价。

很多团队因此选择保留错误的地址、只改可见文本，这是个合理的折中。

但要意识到地址里的那个词仍然在向系统传递一个信号，只是权重不高。

更麻烦的是站内的目录结构往往按同一套词命名，涉及面更广。

关于哪些语言值得花这个成本去改、哪些不值得，其实是语言优先级那笔账 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)要回答的问题。

地址里的那个词还有一层间接影响：别人引用你的页面时会看到它，复制地址时也带着它。于是一个错词会顺着引用链继续扩散，即使你的页面正文早就改过来了，外面流传的仍然是旧写法。

如果确实不打算改地址，那就在其它所有位置把新词铺足：标题、正文首段、面包屑的显示文本、图片替代文本。这几处合起来的信号强度，足以盖过地址里那一个旧词的影响。

## 锚文本与外部引用固化

站内的内部链接锚文本用的也是同一批词，数量可能有几千条。

这部分改起来不难，写个脚本批量替换就行，前提是词表本身已经理清。

真正改不了的是外部站点上的锚文本，那是别人写的内容。

这批外部锚文本会长期把一个错误的词和你的页面绑在一起。

好在这层影响随时间衰减，新增的引用会用新词，几年之后比例就翻过来了。

所以外部锚文本这一层不值得为它推迟改词的决定。

批量替换内部锚文本时要小心形态。在形态丰富的语言里直接做字符串替换，会产出一批不合语法的短语，读起来比原来的错词还别扭。正确做法是按出现位置分组，每组用对应的形态替换，脚本里做一张形态映射表。

替换之前先把当前的锚文本分布导出来存一份。这份分布本身是有价值的资料，它记录了这个页面过去几年是以什么词被理解的，将来分析恢复过程时是唯一的对照基准。

## 一个直译词的长期损失该怎么算？

## 直接损失：这个词的搜索量全部落空

最容易算的一层是这个词本身的搜索量，它基本上全部落空。

估算方法是找到本地常用词的搜索量，减去直译词的搜索量，差值就是直接损失。

在小语种上这两个数都不精确，但数量级是可信的，足够支撑决策。

要注意的是这个损失是持续发生的，每个月都在重复一次。

算总账时应该按年计，而不是按一次性损失计。

按年一算，多数团队会发现改词的成本在两三个月内就回本了。

算年度损失时还要乘一个季节系数。很多品类的搜索高度集中在一年中的几个月，改词赶在旺季之前完成和拖到旺季之后完成，同样的工作量拿到的收益能差好几倍，这一点在排期时值得单独提出来。

估算时不要只算这一个词，要把它的长尾一起算进去。一个错误的核心词会连带让几十个包含它的长尾短语全部失效，这批长尾的总量常常比核心词本身还大，只算核心词会严重低估损失。

## 间接损失：整个页面的主题信号被拖偏

第二层损失比第一层大，也更难被察觉。

标题里的核心词错了，整个页面的主题判断就跟着偏。

页面上其他正确的词会因此变得难以生效，因为它们与主题词不一致。

这意味着损失不止是那一个词，而是这个页面能承接的全部长尾。

一个分类页如果主题词错了，它下面上百个商品页的内部链接也在传递错误信号。

所以间接损失要按页面群计算，不是按单个词计算。

主题判断偏了还会影响这个页面在站内获得的传递效率。系统会把它归进一个错误的主题群，来自相关页面的推荐与关联变少，等于这个页面在站内也被边缘化了，而这一层损失几乎不可能从任何报表里看出来。

判断一个页面是不是被拖偏了，可以看它带来的搜索词分布。如果进来的词跟你以为的主题基本不重合，那说明系统对这个页面的理解已经偏了，而不是内容写得不够好。

## 复利损失：内外链都在给错词投票

第三层损失来自链接。

站内每一条指向这个页面的链接，锚文本都在为错误的词投票。

投票累积得越久，这个页面与错误词的关联越牢固。

牢固到一定程度之后，即使改了标题，系统仍然会用一段时间的旧判断。

这就是为什么改词之后不会立刻见效，中间有一段过渡期。

过渡期的长短跟这批链接积累了多少年正相关，这就是复利的意思。

过渡期有多长其实可以事先估个大概：查一下指向这个页面的外部链接里最早的那批是哪年建立的，年头越久说明关联积累得越牢，切换所需的时间也越长。估出来之后写进方案，能避免上线两周就有人跑来问为什么还没效果。

还有一种加速办法是主动制造新的正确信号：在站内新增几篇围绕新词写的内容，并从它们链向目标页面。这批新链接的锚文本全是新词，能明显缩短系统改变判断所需的时间。

## 改词的代价一定比不改高吗？

## 只改可见文本的最小改法

最小的改法是只改标题、描述和正文里的可见文本，地址完全不动。

这个改法的成本很低，风险也很低，通常一两天就能全站完成。

效果会打折扣，因为地址里的旧词还在，但主要信号已经纠正过来了。

经验上这个改法能拿回大部分损失，剩下那一小部分不值得为它冒风险。

对于绝大多数站点来说，这就是正确答案。

把它当作默认方案，只有在特定情况下才升级到完整改法。

改的时候有两处最常被漏：图片的替代文本，以及页面上以属性形式存在的那些值。它们不出现在正文里，肉眼检查看不到，但它们同样在描述这个页面是什么，漏掉这两处等于改了一半。

执行时建议按模板逐个改而不是全站一次性替换。同一个词在不同模板里可能承担不同角色，有的地方是标题有的地方是面包屑，逐模板过一遍才能保证每处用的都是合适的形态。

## 连地址一起改的完整改法

完整改法要改地址，还要处理新旧地址的对应关系。

它适用于两种情况：这个站还很新，或者正好因为别的原因要重做地址结构。

如果两个条件都不满足，为了改词单独去动地址通常不划算。

动地址的风险不在技术，在于遗漏：几千条地址里漏掉几十条就会产生死链。

做完整改法一定要先导出完整的地址清单，改完逐条比对。

另外别把改地址和别的大改动放在同一周，出了问题会分不清原因。

新旧地址的对照表要长期保留，建议至少三年。外部引用的更新周期就是这么长，三年之内随时可能有人拿着旧地址过来。表存在磁盘上不占什么空间，真需要的时候没有它就只能靠考古了。

执行前还要确认站内没有硬编码的地址。很多老站的模板、脚本甚至邮件内容里散落着写死的完整地址，它们不会跟着规则自动更新，改完之后这批地址就成了站内的死链源头。

## 两条路各自的风险

最小改法的风险是改得不彻底，某些模板漏改，站内出现两套用词。

两套用词并存比全用错词更糟，因为信号是矛盾的。

所以最小改法也要做一次全站检索，确认旧词的出现次数降到零。

完整改法的风险主要是死链和跳转链，跳转套跳转会让抓取放弃。

两条路共同的风险是改到一半停下来，那是最坏的状态。

决定改之前先确认有人能把它做完，这比选哪条路更重要。

半途而废的代价比两端都高。站内同时存在两套词的时候，系统收到的是自相矛盾的信号，既不能确认旧词也不能确认新词，最后可能两个词的表现都不如改动之前。所以启动之前必须确认这件事有人负责做完。

两条路都要准备一个观测清单：改前记录一批代表性页面的表现，改后按周记录同一批页面。没有这个清单，四到八周的过渡期里团队会反复怀疑决策，最后往往在最不该动的时候动手。

## 历史直译词该按什么顺序清理？

## 按流量与转化分档

第一个维度是这个词对应的页面目前带来多少流量和订单。

有流量有转化的页面最该先改，因为它们的潜在上升空间最大。

有流量没转化的页面要先查是不是词义偏了，可能吸引来的根本不是买家。

没流量没转化的页面反而不急，它们改了也不会立刻有变化。

这个排序跟直觉相反：很多人想先救最差的页面，实际应该先推最好的。

因为最好的页面已经证明了需求存在，改词的收益是可预期的。

分档时用展现量比用点击量更合适。点击量已经被错词过滤过一遍，反映的是残余需求；展现量更接近这个页面本来能触达的规模。两个指标排出来的顺序常常明显不同，用错了会把最该改的页面排到后面去。

分档还要看这个页面所处的品类是否正在增长。同样的流量水平，增长中的品类值得优先改，因为改动的收益会随品类一起放大；萎缩中的品类即使改对了，收益也会被大盘拖回去。

## 按改动成本分档

第二个维度是改这个词要动多少地方。

只出现在标题和正文里的词，改动成本最低，可以批量处理。

出现在导航和分类结构里的词，改动要连带调整导航，成本中等。

写进地址和数据库分类字段的词，成本最高，要单独排期。

把所有待改的词按这三档标注一遍，工作量分布就清楚了。

标注这一步通常半天就能做完，却能让后面的排期完全不同。

成本评估里别忘了算回归检查的部分。改动一个分类字段可能同时影响筛选器、推荐位和内部报表三个下游，每一处都要验证一遍。很多改词计划卡住不是因为改不动，而是因为没人愿意为这几处下游的验证负责。

标注成本时顺手记下这个词还出现在哪些非网页的地方，比如导出给渠道的数据表、给合作方的接口字段。这些出口一旦漏掉，改过的词又会被外部系统按旧值同步回来。

## 两个维度交叉出的动作矩阵

把两个维度交叉起来，会得到四个格子。

高价值低成本的格子立刻改，这是第一批，通常能覆盖一半的收益。

高价值高成本的格子单独排期，做成一个小项目，配上完整的回归检查。

低价值低成本的格子顺手改，跟着别的改动一起上线就行。

低价值高成本的格子明确写下不改，并注明原因和复审时间。

写下不改比模糊搁置好，否则每次开会都会有人重新提起这批词。

矩阵最好按主力品类分别做。全站只做一张的话，小品类的页面会因为绝对数值低而全部落进低价值格，即使它们在自己那个品类里已经是最好的页面。分开做之后，每个品类都能有自己的第一批。

每个格子最好写上预计工时和负责人，否则矩阵只是一张漂亮的分析图。真正让它落地的是后面那两列，有了它们这张图才能变成排期表直接进入日常工作流。

## 怎么保证新词表不再产生同一批问题？

## 产出流程要改在哪一步

问题的根源不在译者水平，在于流程里少了一个环节。

常见的流程是原始词表进去、翻译出来、直接使用，中间没有验证。

要加的那一步是验证：每个词都要在目标市场的真实场景里核对一次。

核对不需要语言专家，前面说的搜索验证和标题词频两个办法就够。

把这一步写进流程并且指定责任人，问题就不会重复出现。

没有这一步，换十个译者也是同样的结果。

验证环节放的位置也很关键：应该放在翻译之前，而不是之后。先把核心词定下来，再让写手围绕给定的词组织文案，返工率会低一个数量级。反过来先写完再改词，等于整篇要重写一遍。

流程里还要加一条回流机制：上线之后的实际搜索数据要定期回灌到词表里。用户用什么词找到你的页面，是最真实的验证，这份数据每季度过一遍，词表就会越用越准。

## 母语人参与的最小形式

理想情况当然是有专职的母语内容人员，但多数团队没有这个条件。

最小形式是找一个母语用户，一次性看一遍最终词表，只回答一个问题。

这个问题是：这个词你会不会用来搜这个东西。

不要问对不对，因为直译词多半是对的，问对不对得到的答案是肯定的。

问会不会这么搜，答案才有区分度。

一份两百词的表，母语用户过一遍不到两小时，这是整个流程里性价比最高的一步。

提问的方式要具体到场景才有效。不要问这个东西你们怎么说，要给一个完整情境，比如想买一双跑步穿的鞋，你会在搜索框里打什么。抽象提问得到的是词典式回答，情境提问得到的才是搜索式回答。

如果找不到合适的人，退一步可以找目标市场的本地客服或者当地的合作方帮忙看一遍。他们每天面对真实用户，对用词的敏感度往往比语言专业人士更贴近商业场景。

## 词表的版本与责任人

词表要有版本号，每次改动记录改了哪些词、为什么改。

没有版本记录的词表，半年后没人说得清某个词是怎么来的。

责任人要具体到个人，不能是某个部门，否则出问题时没人能拍板。

词表还要有一个明确的生效范围，写清楚哪些系统在消费它。

这份消费清单就是以后改词时要通知的对象列表，能省掉大量沟通。

把词表当成一份有版本的资产来管理，而不是一个一次性的交付物。

每个词最好记一条来源证据：是从本地标题词频统计来的，还是母语用户确认过的，或者是投放数据验证过的。将来任何一次争议都能直接翻这一列，而不是重新讨论一遍。这一列的维护成本很低，价值却随时间递增。

词表还要指定一个明确的存放位置，并且只保留一个权威副本。多语言项目里最常见的混乱不是词表做错了，而是同时存在三四份互相不一致的词表，谁都说不清哪一份是最新的。

## 有没有直译反而正确的情况？

## 技术术语与国际标准名

技术术语通常在各语言里高度一致，因为它们本来就是同一个来源。

接口名称、材料标准、认证代号这类词直接照搬是对的，翻译反而会出错。

判断依据是这个词在本地行业网站上是不是原样出现。

如果本地专业站也用原写法，那就别动它。

这类词还要注意大小写和连字符，它们经常是精确匹配的一部分。

动了格式，跟动了词本身效果差不多。

有一类例外要留意：某些国际标准在当地有法定译名，出现在合规说明、认证标识和法规引用的场合必须用译名，而在用户搜索时又用原写法。这种情况下两个形态都要保留，只是出现的位置不同。

还要留意缩写与全称的选择。很多技术词在本地行业里习惯只用缩写，全称反而没人打；也有相反的情况。这一点同样只能靠看本地行业站的实际用法来判断，凭经验推测的准确率很低。

## 品牌名与型号

品牌名和型号是绝对不能翻译的一类，但要补上它们的本地变形。

本地变形包括接了格尾的形态、本地读音的拼写、以及常见的错拼。

错拼形态值得单独说一句：它在搜索里的占比可能不低，尤其是长品牌名。

这些形态不需要单开页面，写进正文和内部锚里就够。

形态语言里品牌名接格尾之后会变成好几个形式，俄语的词干剥离规则 (https://snowballstem.org/algorithms/russian/stemmer.html)能直观说明词尾会被怎样处理。

了解词尾的处理方式，就能判断哪些形态其实会被归并、哪些需要单独覆盖。

品牌名还有一种被动变形：本地媒体和用户在提到它时会按本地读音重新拼写，久而久之这个拼法自己也有了搜索量。它不在任何官方资料里，只能靠翻本地论坛和评测文章去收集，收集到之后写进正文即可。

处理型号时还有一条底线：不要为了标题好看去掉型号里的空格或者符号。型号是这类查询里唯一的锚点，它一旦被改写，用户即使搜到你的品类页也找不到具体那一款，等于白接了流量。

## 新品类刚进入市场时

还有一种情况直译是唯一选择：这个品类刚进入市场，本地还没有约定俗成的说法。

这时候用户自己也不知道该怎么搜，往往就是照着外文名打。

这种阶段的正确做法是原词和几个候选译法一起铺，看哪个先跑出来。

过半年再看数据，胜出的那个就是这个市场自然形成的说法。

这也是少数几种能靠自己的数据反过来影响市场用词的场景。

抓住这个窗口的品牌，往往能让自己的叫法变成品类名。

这个窗口期通常只有一到两年。一旦某个说法在市场上成为主流，后来者再想推另一个叫法基本没有机会，成本高到不值得尝试。所以新品类进入市场时，词表这件事反而要比成熟品类更早开始做。

铺多个候选说法时要注意别把它们做成互相竞争的页面。正确做法是选一个做主页面，其余候选写进同一个页面的正文里，等数据出来再决定要不要把主词换掉，这样不会浪费已经积累的信号。

## 直译问题和翻译质量不是一回事

## 翻译质量看的是可读性

翻译质量的验收标准是读起来通不通顺、有没有语法错误、语气合不合适。

一份高质量的翻译完全可能全篇都是没人搜的词，因为验收口径里根本没有这一项。

把选词问题反馈给翻译服务方，得到的回复通常是这个词是对的，因为确实对。

双方说的不是同一件事，争论下去没有结果。

所以要在需求里就把两件事分开，明确说明哪些词是给定的、不许改。

给定词表是解决这个矛盾最直接的办法。

要把词表是给定输入这件事写进需求文档甚至合同里。译者按职业习惯一定会把不够规范的说法改成更规范的，这在他们的专业标准里是尽职，只有明确写下不许改，这条边界才立得住。

交付验收时可以加一条很实用的检查：把最终文案里出现的核心词逐个比对给定词表，出现频次为零的词要说明原因。这一条检查两分钟就能做完，却能拦下绝大多数无声的替换。

## 关键词看的是可检索性

关键词的验收标准只有一条：目标用户会不会用这个词来搜这个东西。

可读性在这里是次要的，甚至有时候是相反的。

用户打进搜索框的很多短语，从写作角度看根本不通顺。

标题要在这两者之间取平衡：核心词按用户的写法，其余部分按语言的规范。

这个平衡点在不同语言里不一样，形态复杂的语言里尤其难找。

做法是核心词保持用户常用形态，句子结构靠其他成分来圆。

核心词在标题里的位置也有讲究。在形态丰富的语言里，把核心词放在句首往往能保持它的原形，放到句中就会被句法要求变形。原形通常正是用户打进搜索框的那个形态，位置一挪，匹配度就跟着变。

还有一个常被忽略的取舍：标题长度。形态语言里为了让核心词保持原形，往往要多加一两个虚词，标题会变长。这时候宁可牺牲一点简洁，也要保住核心词的形态，简洁换不来匹配。

## 两个验收口径要分开

实际操作上，建议把词表和文案作为两个独立的交付物分别验收。

词表验收看的是市场验证结果，文案验收看的是语言质量。

两份验收由不同的人负责，标准写在各自的文档里。

这样一来，文案好但词错的情况会在词表那一关就被拦住。

反过来，词对但文案生硬的情况，也不会被误判成选词问题。

把口径分清楚之后，团队内部关于翻译质量的争论会少很多。

两份验收的顺序也不能颠倒：词表先定稿，文案后写。反过来做的话，词表一改文案就要跟着返工，而返工的文案又要重新验收一次语言质量，一来一回时间全耗在流程上了。

两份交付物分开之后还有个附带好处：词表可以复用到广告、商品数据和站内搜索配置上，而文案不能。把它们混成一份交付物时，词表这部分资产就被埋在文案里，别的团队想用也拿不出来。

## 常见问题解答

## 怎么在不懂目标语言的情况下判断一个词该不该用？

用返回结果的类型来判断，不需要读懂内容。把候选词搜一遍，看返回的十条结果里有几条是本地零售站、几条是词典百科、几条是别的语言的页面。零售站占多数说明这个词在商业场景里活跃，词典百科占多数说明它是个书面词或者生僻词。这个判断只看域名和页面版式就能做，不需要任何语言能力。还可以顺手看看返回结果里有没有广告，有人愿意为这个词付费投放，是需求真实存在的强信号。整套动作五分钟能验十个词，是没有母语人时最可靠的替代方案。如果条件允许，还可以拿这几个候选词各投一小笔广告跑一周，点击数据是最直接的答案，花的钱通常还不如请一次翻译多。

## 已经用了好几年的直译词，改了会不会反而掉排名？

短期内会有波动，长期一定是正收益，前提是新词确实是本地常用词。波动的原因是页面与旧词之间已经建立的关联需要时间解除，站内外的链接锚文本还在往旧方向拉。典型的过渡期是四到八周，期间旧词的排名会掉，新词的排名慢慢上来。要缩短这个过渡期，最有效的办法是同时把站内的内部链接锚文本一起改掉，这部分完全在自己控制之内，改完能明显加快切换速度。另外不要一边改一边反复回退，来回摇摆会把过渡期拉得更长。改之前把当前的排名与流量基线完整存一份，包括分词、分页面、分设备的数据，过渡期里才有可比对象，否则波动一来团队心里没底就容易半路回退。

## 词表里同一个概念有两个常用词，要不要都做？

都做，但要分主次。主词用来写标题和地址，副词写进正文和内部锚文本，不单开页面。如果两个词的搜索量接近而且使用人群明显不同，比如一个偏年轻用户一个偏年长用户，那可以考虑做两个页面，但要清楚地区分它们的内容侧重，不能只是换个词把同一篇内容再发一次。判断是否值得做两个页面的标准是：这两个词的搜索结果页返回的是不是同一批站点，如果高度重合说明系统已经把它们当成同义词处理，做两个页面就没有意义了。判断之前顺手看一眼这两个词的搜索结果里有没有互相出现对方，如果结果页里频繁出现另一个词的页面，那基本可以确定系统已经把它们关联起来了。

## 机器翻译出来的词表，问题会比人工直译更严重吗？

问题类型一样，程度不同。机器翻译和人工逐词翻译犯的是同一类错误：都是在做概念对应而不是使用频率匹配。区别在于机器翻译更倾向于选高频的通用词，某些情况下反而更接近口语；但它在多义词和专业词上的错误率明显更高，而且错得没有规律。真正的差别在于人工翻译时译者可能会顺手做一次判断，而机器不会。所以无论用哪种方式产出初稿，后面那道市场验证的环节都不能省，它才是决定词表质量的那一步。有个折中的用法：让机器先给出多个候选而不是一个结果，再用市场验证从候选里挑，这样既保留了机器的覆盖面，又补上了它最缺的那一步判断。

## 没有本地零售站可以抓标题时怎么办？

换成抓本地的分类信息站、论坛的交易板块和比价页面，这几类站点在任何市场都存在，而且用词比正式零售站更口语化。再退一步，可以看本地的社交平台上关于这个品类的帖子，虽然噪声大，但高频词仍然能反映真实说法。还有一个来源常被忽略：本地的进出口报关分类目录和行业协会的品类清单，它们用的是正式名称，正好可以作为对照组——如果某个词只出现在这类正式文件里而不出现在民间讨论里，那它多半就是那个没人搜的书面词。收集来的这些词最好按来源标注清楚，民间讨论里来的词偏口语、行业目录里来的词偏正式，标注之后哪些适合做标题、哪些适合做正文一眼就能分开。

## 清理历史直译词要不要一次做完？

不要。按前面说的四格矩阵分批做，第一批只做高价值低成本的那一格，做完观察四到六周再启动第二批。分批的好处是每一批的效果都能被单独观测，模型可以据此校准；一次全改会让所有变化混在一起，事后完全说不清是哪个动作起了作用。另外分批还有一个现实好处：第一批的效果数据是申请后续资源最有力的材料，比任何论证都管用。唯一需要一次做完的是同一个词在全站的出现，同一个词只改一半会造成站内信号矛盾。每一批做完都要写一份简短的复盘，记录改了哪些词、观测到什么变化、下一批打算怎么调整，三批之后这份记录本身就成了团队最可靠的经验来源。

## 怎么防止新上线的语言重复踩这个坑？

把市场验证做成上线前的必经关卡，而不是可选建议。具体做法是在词表交付物里加两列：一列写这个词的验证方式，一列写验证结果的日期。两列都为空的词表不允许进入下一环节。这个约束看起来很行政，但它是唯一能真正生效的办法，因为直译词在语言上挑不出毛病，靠评审是评不出来的，只能靠流程强制。再配上母语用户过一遍词表的那两小时，新语言上线时这类问题基本可以清零。这套关卡还要覆盖后续新增的词，很多站最初的词表做得很认真，后来陆续加的新品类词却又回到了随手翻译的老路上，问题就是这样一点点长回来的。

## 权威参考资料



## Windows-1251时代的西里尔页面，搜索引擎抓回去的不是俄语，是一串认不出的拉丁字母

- URL：https://zhangwenbao.com/cyrillic-encoding-legacy-windows1251-utf8-indexing-cost.html
- 分类：小语种SEO
- 发布：2006-06-14  |  更新：2026-07-26
- 摘要：西里尔站点从Windows-1251迁到UTF-8要付多少收录代价？讲清五套编码的字节差异、编码声明打架时谁赢、迁移六步顺序与老链接资产的处理办法。
- 关键词：技术SEO,字符编码,小语种SEO,书写系统

> **TLDR**：摘要：西里尔字母在字节这一层从来不止一套写法。同一个字母在几种八位编码里分别是不同的数值，页面没把用的是哪一套说清楚，抓取方只能猜，猜错就把整页读成一串没有意义的拉丁字符。这类站点在结果里的表现不是排名低，而是标题本身就不成词、关键词一个都对不上。这篇讲清五套编码的字节差别、声明打架时谁说了算，以及迁到UTF-8之后收录要重新走一遍的那部分代价。

> 摘要：西里尔字母在字节这一层从来不止一套写法。同一个字母在几种八位编码里分别是不同的数值，页面没把用的是哪一套说清楚，抓取方只能猜，猜错就把整页读成一串没有意义的拉丁字符。这类站点在结果里的表现不是排名低，而是标题本身就不成词、关键词一个都对不上。这篇讲清五套编码的字节差别、声明打架时谁说了算，以及迁到UTF-8之后收录要重新走一遍的那部分代价。

## 同一个西里尔字母，为什么会有五套不同的字节？

## 几套八位编码各自是怎么来的

拉丁字母的运气比较好，基本字母全部落在单字节编码的前一百二十八个位置里，全世界通用。

西里尔字母没赶上这班车，只能挤进单字节编码剩下的那一百二十八个位置。

问题是这一百二十八个位置由谁来分配，从来没有一个各方都接受的答案。

于是不同的系统各自排了一套：操作系统厂商排了一套，早期网络社群排了一套，国际标准组织又排了一套。

每一套都能完整装下西里尔字母，每一套给同一个字母分配的数值都不一样。

这不是谁做错了，是那个年代的技术条件下必然出现的结果。

刻意把西里尔字母排到与读音相近的拉丁字母固定偏移处，背后有个很现实的原因：那个年代不少通信链路只可靠传输七位，最高位会被抹掉。抹掉之后剩下的字节正好落在拉丁字母区，收件人虽然看到的是一串拉丁字母，勉强还能拼出原意。

## 几套编码在字节层的实际差别

拿最常见的那个表示价格的西里尔词做例子，它在几套编码里的字节完全对不上。

操作系统厂商那一套把字母按字母表顺序连续排列，字节值是一段连续区间。

早期网络社群那一套刻意做了另一种安排：把西里尔字母排在与它读音接近的拉丁字母相差固定值的位置上。

这样做的好处是即使高位被通信设备抹掉，剩下的拉丁字母还能勉强读出大意。

国际标准组织那一套又按自己的规则排了第三种顺序，跟前两种都不重合。

三套编码放在一起看，同一个字母有三个不同的数值，任何一方都不知道对方在用哪一套。

判断一份老数据到底属于哪一套，其实不用通读全文：找一个高频小写字母，看它的字节数值落在哪个区间就行。三套编码给同一个字母分配的值互不重合，一个字节就能定案，这比任何自动检测都快也都准。

这套判断还能反过来用：拿到一段乱码，按几套编码逐一还原试一遍，能还原出通顺词句的那一套就是原编码。整个过程可以写成十几行脚本批量跑，比人工一条条猜快得多。

## 为什么当年不能只用一套

技术上当然可以只用一套，实际上做不到，因为存量太大。

操作系统默认用哪一套，用户在本机创建的文档就是哪一套，改不动。

邮件系统、论坛程序、数据库驱动各自有各自的默认值，跨系统传一次就可能被转一道。

更麻烦的是有些环节不做转换只做透传，字节原样传过去，标签上却写着另一套的名字。

于是同一个站里出现两种编码混着跑的情况，而且往往没人知道是从哪一步开始混的。

能统一的时候当然要统一，但绝大多数西里尔站点面对的是已经混了好几年的现状。

还有一层物理原因：当时的终端和打印机把字模表烧在固件里，字节值到字形的对应关系是硬件决定的。换一套编码意味着这批设备全部要换，成本落在实实在在的机器上，不是改一行配置能解决的。

## 用户那一侧的浏览器在怎么应付

浏览器早就见惯了这种局面，所以它们都内置了一套猜测逻辑。

猜错的时候用户会看到满屏乱码，然后手动去菜单里换一个编码，页面就正常了。

这个手动换编码的动作，在西里尔市场的用户里熟练度相当高，属于上网基本技能。

正因为用户能手动补救，站长常常意识不到自己的页面有问题。

但抓取程序不会去点那个菜单，它只会按自己的判断处理一次，然后把结果存下来。

用户能救的那一步，恰恰是搜索侧完全救不了的那一步。

这里有个很坑的细节：浏览器会把用户手动选过的编码记住，同一个站下次打开就直接按上次的选择渲染。于是站长自己每天看到的都是正常页面，而任何一个第一次来的访客看到的是乱码，自查在这一步就已经失效了。

更麻烦的是搜索引擎的抓取程序不但不会手动切换，还可能在不同时间用不同策略处理同一个页面。于是同一个地址在索引里前后存过两个版本，历史数据变得完全不可比。

## 一个字符多套字节、一个字符多个码位、多个字符一个模样，这三件事怎么分？

## 字节层：同一个字符的多套字节序列

这三种问题在症状上有点像，处理办法完全不同，混在一起讨论一定会绕晕。

本篇讲的是第一种：字符是同一个字符，码位也是同一个码位，只是落到字节上有好几种排法。

它出问题的环节在传输与存储，也就是响应头、页面里的声明、数据库连接和文件本身。

典型症状是整页整段地变成一串不成词的字符，人一眼就能看出不对。

因为症状明显，这类问题反而是三种里最容易发现的，只是修起来牵扯的环节最多。

修的办法也很单一：把所有环节统一到同一套编码上，没有别的巧办法。

层 | 一句话定义 | 出问题的环节 | 典型症状 | 

字节层（本篇） | 同一个字符在不同编码方案下是不同的字节 | 响应头、页面声明、数据库、文件 | 整页变成不成词的字符串 | 

码位层 | 同一个字符在字符集里有两个合法码位 | 输入法、内容来源、比对与去重 | 两份内容看着一样却匹配不上 | 

字形层 | 两个不同的字符长得一模一样 | 人眼判断、域名与商品名审核 | 看不出异常，却被判为可疑 | 

字节层的错误有一个很有价值的特征：它是系统性的、可逆的。因为背后是一张固定的映射表，每个字符都被换成了确定的另一个字符，没有信息丢失。这意味着乱码文本能被反推回原文，抢救老数据的可能性就建立在这一点上。

## 码位层与字形层各自是另一回事

第二种问题出在码位上：字符集里给同一个字符收了两个合法码位，两者都不算错。

这种情况在带附加符号的拉丁字母里最常见，一个字母可以用组合形式表示，也可以有一个独立码位。

它的症状很隐蔽，两份内容在屏幕上一模一样，做字符串比对时却对不上。

第三种问题出在字形上：两个完全不同的字符，画出来的样子没有任何区别。

西里尔字母表里有好几个字母跟拉丁字母长得一样，肉眼分不出来，机器却知道它们是不同的字符。

这一类的症状最反常识：页面看起来完全正常，却会被当成刻意混排来处理。

三层的检查顺序不能随意：一定要先查字节层，再查码位层，最后查字形层。顺序反了会被前一层的噪声淹没，比如页面整体乱码的时候去查同形字符混排，检测器会报出成千上万条假阳性，把真正的问题埋掉。

## 三层各自在哪一环出事

字节层的事故发生在页面被读取的那一刻，抓取方拿到字节但不知道该怎么解释。

码位层的事故发生在内容被比对的时候，去重、匹配和索引都可能因此错位。

字形层的事故发生在内容被审核的时候，域名、品牌名和商品标题是重灾区。

三层的检查方法也不同：字节层看声明是否一致，码位层看规范化是否做过，字形层看有没有混排。

本篇只处理第一层，另外两层各有各的判定规则，跟编码迁移不是同一件事。

把三层分清楚之后你会发现，很多所谓的编码问题其实压根不在编码上。

一个跑了多年的老站三层同时中招是很常见的。这时候修复顺序同样不能颠倒：字节层没修干净之前，码位层的规范化和字形层的混排检测跑出来的结果全都不可信，等于白跑一遍还浪费了排查时间。

## 搜索引擎抓到没声明编码的页面，会怎么猜？

## 响应头、页面声明与实际字节三者打架时谁说了算

一个页面里可以在三个地方说明自己用的是哪套编码，三处经常互相矛盾。

第一处是服务器返回的响应头，它在页面内容之前到达，优先级最高。

第二处是页面头部的声明标签，它写在文件里，但要先把文件当成某种编码读出来才能看到。

第三处是字节本身，它是唯一的事实，另外两处都只是说法。

规范里写清楚了响应头优先于页面内声明，HTML 4.01关于文档字符表示的章节 (https://www.w3.org/TR/html401/charset.html)把这个顺序定得很明确。

麻烦在于很多服务器会自作主张地在响应头里加一个默认值，而那个默认值往往是错的。

页面内声明有个先有鸡还是先有蛋的尴尬：要读到这行声明，就得先假定一种编码把文件读开。规范因此要求它必须出现在文件很靠前的位置，超出那个范围写的声明，处理方可以合法地当作没看见。

实际排查时建议把三处的值并排写在一张表里，每种页面类型一行。九成的编码问题在这张表填完的那一刻就已经找到了，剩下一成才需要真正去看字节。

## 自动检测是按什么判断的

三处都没有可靠信息时，处理方只能看字节分布做统计判断。

不同编码下常用字母的字节值落在不同区间，出现频次的模式也不一样。

文本足够长的时候这种判断相当准，短文本就很容易翻车。

所以标题短、正文少的页面是编码检测错误的高发区，恰恰这类页面又是列表页和分类页。

更糟的是同一个站里有的页面猜对有的页面猜错，问题看起来毫无规律。

把这件事交给统计猜测，本身就是不该出现的状态，声明清楚成本极低。

检测失效的临界长度大约在几十个字节这个量级，低于它统计特征就不成立了。这正好解释了为什么分页导航、标签页、筛选结果页这类文字极少的页面，是同一个站里最先出乱码的那一批。

## 猜错之后页面在索引里变成什么

猜错的后果不是页面被丢掉，而是页面以另一种面貌被存了下来。

存下来的是一串按错误编码解释出来的字符，它们在目标语言里毫无意义。

这些字符串照样会被切词、照样会建索引，只是永远没有用户会搜到它们。

从站长这一侧看，页面收录数字看着正常，流量却接近于零。

这种组合最容易被误判成排名问题，然后团队开始改标题、加内容、找外链，全都打不到点上。

保哥接手过一个做户外电源的站，排查两周才发现问题在响应头的一个默认值上。

还有一层连带后果：那串乱码字符在字符分布上很像某种西欧语言，于是这个页面会被判成西欧语言的内容。判错语言之后，它可能被投放到完全不相干的语言市场里，进一步稀释掉本来就不多的曝光。

这种情形跟单纯的排名下滑要分开看：排名问题至少说明系统认得出你的词，而编码问题是系统压根没拿到你的词。2003年那次影响很广的算法调整 (https://zhangwenbao.com/google-florida-update-2003-explained.html)之后，很多站长养成了掉流量先怀疑算法的习惯，遇到这类问题反而绕了远路。

## 一个站里两种编码混用的后果

更常见的情况是站里大部分页面正常，某个模块的页面不正常。

通常是后加的功能模块用了另一套默认值，比如评论、站内搜索结果或者从外部同步来的数据。

这种情况下自动检测会在同一个域名下得出不同结论，站点的整体信号变得混乱。

排查的办法是逐个模板取一段字节出来直接看数值，不要靠浏览器渲染的结果判断。

浏览器已经替你猜过一次了，你看到的是猜测的结果，不是原始事实。

用命令行工具把原始响应抓下来看，是这一步唯一可靠的方法。

混用最常见的入口不是自己写的代码，而是从外部同步进来的数据：供应商的商品表、物流状态回传、支付通知。这些接口的编码约定往往写在很旧的对接文档里，双方谁都没有再确认过，直到某天某个字段开始出现乱码。

## 编码出问题，会以哪几种形式表现在收录上？

## 标题变成一串拉丁字母的那几种形态

最典型的形态是一串带各种附加符号的拉丁字母，看着像某种西欧语言但读不通。

这是把西里尔编码的字节按西欧编码解释出来的结果，每个西里尔字母都被换成了一个西欧字符。

另一种形态是一串问号，这说明中途有一次转换失败，字符被替换成了占位符。

问号这种形态比乱码更糟，因为信息已经彻底丢了，改回来的唯一办法是从源头重新取数据。

还有一种形态是每个字符之间夹着奇怪的符号，那通常是把双字节序列按单字节读的结果。

三种形态对应三种不同的出错环节，看清楚是哪一种，就知道该去查哪一段。

三种形态的可抢救程度完全不同：映射型的能百分之百恢复，问号型的信息已经彻底丢失只能重取，边界错位型的能恢复大部分但接缝处要人工核对。先判形态再定抢救方案，比一上来就写脚本靠谱得多。

## 页面被收了但一个关键词都对不上

编码错误最隐蔽的表现是页面收录正常、快照正常、就是没有任何关键词能匹配上。

原因是索引里存的是错误解释出来的字符串，而用户搜的是正确的西里尔词。

这两串字符在系统里没有任何关系，不会被当成同一个词的不同写法。

诊断这个问题有个很快的办法：把结果页里显示的那串乱码原样复制去搜一下。

如果能搜到自己的页面，说明索引里存的确实是乱码版本，问题就锁定了。

这个办法只要两分钟，比任何猜测都快。

这个反查办法还能顺手量化影响面：把那串乱码限定在自己的域名下搜一遍，返回多少条就大致是有多少页面以乱码形态入了库。有了这个数，跟团队讨论要不要停下来先修编码时，就有了一个具体的量。

## 重复内容判定被意外触发

同一份内容如果在两个地址下分别以两种编码提供，字节完全不同，文字却是同一份。

更常见的是反过来：两份不同的内容因为都被读成了乱码，反而在字符层面变得相似。

大量页面被读成乱码时，这些页面的字符分布会异常接近，因为它们共用同一批错误映射出的字符。

这会让原本各不相同的页面在相似度判断上互相靠拢，最后只保留其中一部分。

所以编码错误在大站上的表现，往往是收录量莫名其妙地掉了一大块。

这一点跟内容质量没有任何关系，改内容改不好。

乱码页面之间的相似度被拉高，是因为它们共用同一批高频错误字符。原本内容毫不相干的两个页面，在字符层的相似度可能高达八成，这个数值足以让相似度判断把它们归成一类，而人看着这两个页面完全想不通哪里像。

真要确认是不是这个原因，可以抽二十个被合并掉的页面，把它们的原始字节取出来做一次字符频次统计。如果这二十个页面的高频字符高度重合而正文主题各不相同，基本就能定案。

## 地址栏里的西里尔字节，是另一笔账吗？

## 路径里的非拉丁字节怎么被转义

地址只允许出现有限的一批字符，西里尔字母不在其中。

所以西里尔词出现在地址里时，会先被转成字节，再把每个字节写成百分号加两位数值的形式。

RFC 3986关于统一资源标识符的规范 (https://www.rfc-editor.org/rfc/rfc3986)把这套转义规则写得很清楚，关键是它没规定字节是按哪套编码产生的。

这就留下了一个口子：同一个西里尔词，按不同编码转义出来是两串完全不同的地址。

两串地址指向同一个页面时，等于凭空多出一份重复。

而它们看起来都是一堆百分号和数字，人眼根本对比不出区别。

这个留白在实际项目里的后果是：两个程序员各自写出的链接生成函数都完全合规，产出的地址却对不上。争论谁写错了没有意义，规范层面确实没规定，团队必须自己定一条约定并写进代码规范里。

## 同一个词两套编码就是两个地址

这类重复的产生方式通常很不起眼：站内不同模块生成链接时用了不同的编码。

比如分类导航用一套，面包屑用另一套，两处指向同一个页面却写出两个地址。

抓取方会把它们当成两个页面分别抓取，然后再去判断是不是重复。

判断为重复固然浪费抓取，判断不为重复更麻烦，权重被分成两半。

排查办法是把站内所有链接抓一遍，按百分号编码后的形式去重，重复的形态会立刻暴露。

这一步跟页面内容编码是两件独立的事，改好了页面不代表地址也好了。

转义序列里的字母大小写也算一处差异，有的系统把两种写法当同一个地址，有的当两个。这样一来同一个西里尔词理论上能产生四种地址形态，全站抓一遍去重时要把大小写也一起归一化，否则数出来的重复量会偏小。

## 查询参数与站内搜索的编码

查询参数这一段的编码规则更松，历史上留下的做法更杂。

表单提交时用什么编码，取决于页面本身声明的编码，这就把两件事又绑在了一起。

页面声明改了，表单提交的字节跟着变，站内搜索的日志格式也会变。

迁移编码时如果没同步处理这一段，站内搜索会在某一天突然全部搜不到东西。

更隐蔽的是历史日志：迁移之后的日志和迁移之前的日志用的是两套字节，直接合并统计会出错。

所以迁移那天要在日志里打一个标记，后面做分析时按这个时间点分段处理。

还有个连带影响：表单提交用的编码继承自页面声明。页面编码一改，站内搜索的日志格式就在那一天断代，前后两段日志不能直接合并统计。做搜索词分析的人如果不知道这个断点，会得出一个完全错误的趋势结论。

迁移当天最好在日志里主动写一行标记，写明切换时间与新旧编码名称。半年后有人来分析历史搜索词时，这一行就是唯一能让他知道该怎么分段处理的线索。

## 迁到UTF-8该按什么顺序动，才不会中途更乱？

## 先盘清现状：哪几处在声明编码

动手之前先做一件事：把站里所有会声明或影响编码的地方列成一张清单。

清单至少要包括服务器全局配置、站点级配置、程序里的响应头设置、模板文件本身的保存编码。

还要加上数据库的字符集、连接时的字符集设置、以及所有对外接口的编码约定。

这张清单通常比想象的长，一个跑了几年的站列出十几处很正常。

列完之后逐项标注当前值，就会看到哪几处对不上，问题往往就藏在那两三行里。

这一步花半天，能省掉后面反复试错的两周。

清单里最容易漏的是三类平时没人访问的模板：错误提示页、发给用户的邮件模板、以及后台导出的数据文件。它们不出现在日常浏览路径上，所以从来不被检查，却常常是全站唯一还留着老编码的地方。

清单做完不要扔，把它固化成一份检查表，以后每次上新模块都过一遍。编码问题的复发率相当高，因为新模块的作者未必知道这个站有过这段历史。

## 数据库、模板、响应头要同时动

编码迁移最忌讳分批做，因为任何一处没跟上，就会产生新的混合状态。

数据库存的是老编码、模板已经按新编码保存、响应头还写着老值，这三种排列组合能产生九种不同的错法。

正确的做法是在一个维护窗口里把所有环节一起切换，中间不接受外部请求。

窗口时间取决于数据量，多数中型站点在两小时以内能完成。

切换前要把整站备份一份原始字节，不是备份显示结果，是备份文件和数据库的原始内容。

备份这一步没做，转换出错之后就真的回不去了。

坚持在一个窗口里做完的原因可以算出来：假设有八个环节，每个环节两种状态，中途可能出现的组合数是两百多种。逐个切换等于逐个制造新的错法，而且每种错法的症状都不太一样，排查成本远超停机两小时。

## 转换本身怎么做才不丢字符

转换的原理是把老编码的字节先解释成字符，再按新编码写回字节。

这一步的前提是必须知道老编码到底是哪一套，猜错就会批量产生问号。

如果数据库里本来就混着两套编码，那就要先按来源把数据分组，分别用不同的老编码转换。

分组的依据可以是创建时间、来源模块或者某个特征字节，具体看这个站的历史。

转换脚本要先在副本上跑一遍，随机抽两百条记录人工核对，确认没有问号再动正式库。

RFC 3629定义的UTF-8编码形式 (https://www.rfc-editor.org/rfc/rfc3629)是转换目标的权威依据，字节长度与合法范围都以它为准。

正式转换之前建议加一道往返测试：把老编码的字节转成新编码再转回去，理论上应该与原始字节完全一致。不一致的那些记录就是含有异常字节的记录，把它们单独捞出来人工处理，剩下的可以放心批量跑。

转换脚本还要处理一类边角数据：那些本来就不是文本的字段，比如存了二进制内容或者序列化结构的列。对它们做编码转换会直接损坏数据，转换前必须按字段类型把这些列排除掉。

## 双写与回滚方案

规模大的站可以做一个过渡方案：数据库先双写，两套编码各存一份。

双写期间对外只提供新编码的那一份，老那一份留作回滚用。

回滚的触发条件要事先写明，比如乱码页面比例超过某个数值就回滚。

没有明确触发条件的回滚方案等于没有方案，真出事的时候没人敢下决定。

双写会带来额外的存储和写入成本，跑一到两周就可以关掉。

关掉之前记得确认新编码那份数据已经完整覆盖了老数据的全部记录。

双写期间可以给新旧两份内容各算一个长度或校验值，逐条比对。比对不上的记录几乎都指向转换脚本的边界情况，比如超长字段被截断、含有控制字符的记录。这是发现脚本隐藏问题最有效的办法，比人工抽样可靠得多。

回滚演练最好在正式窗口之前真跑一次。很多回滚方案纸面上完整，实操时才发现某个环节没有对应的逆操作，等真出事再发现这一点，代价就完全不同了。

## 迁完之后，收录要重新走一遍吗？

## 已收录页面的更新节奏

迁移完成的那一刻，索引里存的还是老的那份内容，无论它是正确的还是乱码的。

更新要等抓取方再来一次，而重新抓取的节奏取决于这个页面平时被抓的频率。

首页和主要分类页通常几天内就会更新，深层页面可能要几周甚至几个月。

这段时间里，站里会同时存在已更新和未更新两种状态的页面。

加速的办法是提交站点地图并把更新时间标注清楚，这是当时唯一有效的加速手段。

除此之外没有捷径，剩下的只能等。

全站铺开的周期可以自己粗略测出来：挑二十个分布在不同层级的页面，从日志里翻出它们最近几次被抓取的时间间隔，取一个分布。首页那一档和最深那一档的间隔差多少倍，全站更新完就大致要几个周期。

这段时间里站点地图的更新时间字段要如实填写，填成迁移当天的日期是合理的，因为内容确实变了。全站统一填一个假的近期日期反而会降低这份文件的可信度。

## 哪类页面掉得最久

掉得最久的是那些本来就抓取频率很低的页面，通常是层级深、内链少的商品页。

这类页面在老编码时代可能就已经收录得很勉强，迁移之后要重新排队。

另一类掉得久的是原本靠乱码字符串意外获得过一点流量的页面，它们本来就是异常状态。

这类页面的数据在迁移后会归零，不要把它当成迁移造成的损失。

要盯的是那些原本正常且有稳定流量的页面，它们如果两个月还没恢复，说明还有环节没改干净。

把这批页面单独列一张表跟踪，比看整站数字有用得多。

跟踪表要按抓取频率分组，不要按目录分组。同一个目录下的页面，抓取频率可以差十倍以上，按目录看会把两类完全不同的页面混在一格里，得出的恢复曲线毫无意义。

跟踪表建议只跟踪两个月，两个月还没恢复的页面要单独排查而不是继续等。经验上这批页面里绝大多数不是抓取慢，而是还残留着某处没改干净的编码声明。

## 迁移窗口期的流量预期

如果原来的编码是正确的，迁移之后流量基本不会掉，只有轻微波动。

如果原来的编码是错的，那迁移之后流量是从接近零开始往上长，谈不上掉。

真正会掉的是中间那种情况：一部分页面原来正确，迁移过程中被改坏了。

所以迁移的风险控制重点不在编码本身，在于转换过程有没有引入新的错误。

迁完之后第一周每天抽查五十个页面的实际字节，是成本最低的保险。

抽查发现的问题在第一周解决，和在第二个月解决，代价差着一个数量级。

预期要按三种基线分别定：原本编码正确的页面、原本全是乱码的页面、原本时对时错的页面。三者的曲线形状完全不同，混在一张整站图里看，最后大概率会得出一个既解释不了也指导不了行动的结论。

## 老编码留下的历史资产要不要保？

## 外链锚文本里的乱码

老站往往积累了不少外部链接，其中一部分的锚文本本身就是乱码。

这些锚文本是别人页面上的内容，你改不了，只能接受。

好消息是锚文本乱码不影响链接本身传递的价值，链接指向的地址才是关键。

所以处理原则是保住地址不变，锚文本乱不乱随它去。

如果链接来源方还在维护，可以发邮件请他们更新，但成功率不要抱太大期望。

把精力放在保住地址上，收益比逐个联系高得多。

乱码锚文本其实是一份免费的历史档案：从锚文本呈现的乱码形态，能反推出链接建立的那个时间点你的页面是什么编码状态。把这些线索排一遍时间线，往往比翻服务器变更记录还快找到编码是哪次改动开始混的。

如果链接方愿意配合，优先联系那几个流量确实带得动的来源，其余的不必逐个去谈。这件事的投入产出比很低，把同样的时间花在修站内地址一致性上收益高得多。

## 旧地址与旧参数的处理

迁移编码时最容易顺手做的一件坏事，是把地址里的转义形态也一起改了。

地址一改，所有外部链接和已收录记录全部失效，这个损失比编码问题本身还大。

正确的做法是地址保持原样，只改内容编码，两件事完全分开。

如果确实要改地址，那就单独做一次，中间隔开至少一个月，并且做好新旧对应关系。

两件事同时做，出了问题根本分不清是哪一件造成的。

选做哪门语言、投多少预算这类判断我在小语种优先级那篇 (https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html)里单独讲过，跟这里的技术迁移不是一个层面的决定。

两件事隔开做的期间，要先把当前的全量地址清单存一份快照。有了这份快照，后面真要改地址时，新旧对应关系可以自动生成而不用人工整理，同时它也是验证编码迁移没有意外改动地址的对照基准。

## 归档页面与静态文件

站里通常还躺着一批静态文件，它们不走程序，直接由服务器发出去。

这类文件的编码由文件本身决定，程序改了它们不会跟着改。

还有一批老的下载文件、说明文档、导出的数据表，它们的编码可能又是另一套。

这些文件不一定要立刻转换，但要在服务器配置里为它们单独声明正确的编码。

声明清楚之后它们至少不会被读错，转换可以排在优先级更低的时间做。

清单里漏掉静态文件这一项，是迁移之后最常见的尾巴。

这里有个反直觉的坑：服务器为静态文件统一加的编码声明，优先级高于文件内部可能存在的声明。配置的时候如果一刀切地给所有文件加上同一个字符集，那些原本就已经是新编码的文件反而会被读坏。

## 迁完UTF-8之后，哪些西里尔问题还在？

## 大小写与排序

统一编码解决的是字节问题，不解决字母本身的行为问题。

西里尔字母的大小写转换在多数环境下没有陷阱，但排序规则要按语言单独设定。

同样一批词，在不同的西里尔语言里正确的排列顺序并不相同。

字母表顺序也不完全一致，有的语言多几个字母，有的语言少几个。

所以站内的字母索引、筛选器和排序功能，要按具体语言配置而不是按字符集配置。

这一层的规则跟编码无关，迁移完还得单独处理一遍。

不同西里尔语言的字母表长度本身就不一样，有的多几个字母，有的少几个，排序位置也不完全一致。所以字母索引这类功能要按语言生成，把整套字符集的字母一股脑排出来，会出现本语言根本不用的字母占着位置。

还有一个跟编码无关但常一起出问题的点：字母的大小写映射在个别西里尔字母上不是一一对应的。做去重和地址归一化时如果统一转小写，个别词会被合并成同一个，要按语言确认一遍。

## 同形字符带来的新问题

统一到一套字符集之后，反而更容易出现西里尔与拉丁字母混排的情况。

因为两套字母现在可以自由地出现在同一个字符串里，而其中好几对长得一模一样。

用户复制粘贴、编辑手动输入、外部数据导入，都可能带进混排的字符串。

混排的商品名在搜索时匹配不上，在人眼看来却完全正常，排查起来相当费劲。

解决办法是在内容入库时做一次字符白名单检查，发现混排就报警。

这属于字形层的问题，跟本篇讲的字节层是两回事，但它确实是迁移之后才凸显出来的。

混排检查要放在内容入库那一刻，不要放在展示层。放在展示层意味着每次渲染都要算一遍，成本高不说，也改不了已经存进数据库的脏数据。入库时拦一次，脏数据根本进不来，后续所有环节都省事。

## 用户实际打出来的形态

还有一层跟编码完全无关但同样影响匹配：用户到底打的是哪种形态。

有的用户手边没有西里尔输入法，就用拉丁字母按读音拼出来。

有的用户会省略某些字母上的附加记号，写出一个不完全规范的形态。

这些形态在字节层完全合法，在词表层却对不上任何一个正式写法。

处理它们要靠关键词覆盖，跟编码迁移是两条并行的工作线。

把编码修好之后，这一层才真正浮出水面，因为在那之前所有问题都被乱码掩盖着。

编码修好还有一个隐形收益：站内搜索日志第一次变得可读。在那之前几年的日志里存的都是按错误编码记下来的字符串，基本没有分析价值。修好之后攒上一两个月，就能拿到这个市场第一份真实的用户用词分布。

这一层的工作可以和编码迁移并行准备：迁移期间先把词表和覆盖方案做出来，等日志一变得可读就能立刻验证，不用再等一轮数据积累。

## 这套编码账在别的书写系统上通用吗

## 希腊、希伯来与阿拉伯的对应情形

凡是不在单字节编码前一百二十八位里的书写系统，都经历过同一段历史。

希腊字母、希伯来字母、阿拉伯字母各自都有过多套互不兼容的八位编码。

它们的症状与排查方法跟西里尔完全一致，只是具体的编码名字不同。

差别在于阿拉伯与希伯来还叠加了书写方向的问题，编码修好之后还有一层要处理。

所以在这几种书写系统上，编码迁移只是第一步，不是全部。

本篇的排查清单可以直接照搬，替换掉编码名称即可。

书写方向的问题有个特点：它只有在编码正确之后才会暴露出来。编码还乱着的时候，页面里全是不成词的字符，方向对不对根本看不出来。两个问题叠在一起时容易被当成一个问题处理，结果修完编码又冒出一批新现象。

## 东亚的多套编码

东亚的情况更复杂一些，因为那里的字符数量远超单字节能表示的范围。

所以东亚用的是多字节编码，同一个字符占两个甚至更多字节。

多字节编码的错误症状跟单字节不同：不是每个字符换成一个乱码，而是字符边界整体错位。

边界错位之后的结果更难看懂，也更难反推原文。

但迁移的方法论是一样的：盘清声明、一次切换、抽样核对、跟踪收录。

只是转换时要格外小心截断，多字节编码在截断处最容易产生无法恢复的损坏。

多字节编码按字节截断时会切出半个字符，而这半个字符有可能恰好是另一个合法字符的前缀，于是后面整段的字符边界全部错位。这也是为什么东亚站点的乱码经常不是从出错那一处开始，而是从那一处之后全篇都不对。

另外多字节编码里有些字节值同时可能是单字节字符，也可能是双字节字符的后半截，这种歧义让自动检测的准确率明显低于单字节场景。所以东亚站点更依赖明确声明，靠猜的成功率不高。

## 拉丁语族的变音字符

用拉丁字母的语言看起来最安全，其实也有自己的编码历史。

带附加符号的字母同样落在单字节编码的后半段，同样存在多套分配方案。

区别在于这类站点即使编码错了，页面里的大部分字母仍然可读，只有带符号的那几个字母变成乱码。

正因为只错几个字母，问题更容易被忽略，一放就是好几年。

而这几个字母往往正是区分词义的关键，错掉之后关键词一样匹配不上。

所以这类站点的编码检查，重点是抽查含附加符号的词而不是整页目检。

这类页面的自动检测反而更容易判对，因为绝大部分字节仍落在通用区间里，统计特征没被破坏。判对了整体，错的只有那几个带符号的字母，问题于是可以潜伏很多年——只有做关键词匹配时才会显出来。

## 常见问题解答

## 怎么快速判断一个站到底用的是哪套编码？

不要看浏览器的显示结果，浏览器已经替你猜过一次了。正确的做法是用命令行工具把原始响应完整取回来，先看响应头里有没有字符集声明，再把返回的字节按十六进制打印出来，找一个已知的西里尔词对照它的字节值。几套常见编码给同一个字母分配的数值差异很大，对照一次就能确定。如果响应头写着一个值、字节实际是另一套，那就已经定位到问题了。这个方法对静态文件同样适用，而且比任何在线检测工具都可靠，因为工具本身也可能在中间做了一次转换。排查时顺手把首页、分类页、详情页、搜索结果页各取一个样本，四类页面往往由不同模板生成，编码状态可能并不一致，一次全取比逐个页面反复确认省事。

## 数据库里混着两套编码，还能安全迁移吗？

能，但要先分组。混合编码的库不能用一条命令统一转换，那样一定会把其中一部分转坏。做法是先找出区分两套数据的特征：多数情况下是按创建时间分界，因为编码通常是在某次升级后才改变的；如果时间分不开，就用字节特征判断，两套编码的合法字节范围不完全重合，写一个判定函数逐条打标。分组打标之后按组分别转换，转换完再抽样核对。这个过程比统一转换慢，但它是唯一不会造成不可逆损坏的做法。整个过程务必先在副本上完整跑一遍。打标之后建议把每组的记录数记下来，如果某一组只有寥寥几十条，那多半是异常数据而不是真的另一套编码，直接人工处理比写规则更快也更稳妥。

## 迁移之后收录多久能恢复？

取决于原来的状态和页面的抓取频率。如果原来编码是正确的，迁移只是格式变化，通常两三周内主要页面就会更新完毕，深层页面一两个月。如果原来是乱码状态，那不是恢复而是从头开始，主要页面几周内能进来，全站铺开要按内容量算，几万页的站三到六个月是常见节奏。加快的办法只有两个：把站点地图整理干净并标注更新时间，以及把重要页面的内部链接理顺让抓取更容易到达。除此之外没有别的加速手段，耐心等待是必要的一部分。这段时间里最该做的不是反复提交，而是把内部链接理顺，让重要页面从首页出发三步之内能到达，抓取路径顺畅带来的加速效果比任何提交动作都明显。

## 地址里的西里尔字符要不要一起换成拉丁转写？

如果地址已经被大量收录并且有外部链接指向，就不要动。地址变更的损失通常大于转写带来的收益，尤其是在编码迁移的同一个窗口里做，出了问题根本分不清原因。如果这个站还很新，或者正好要重做地址结构，那可以考虑用拉丁转写，好处是复制粘贴时不会变成一长串百分号，用户看到的地址也更短。不管选哪种，关键是全站只用一种规则，最忌讳一部分页面用转写、一部分用转义，那样等于自己制造了两套地址体系。如果决定改，一定要先把现有地址的完整清单导出来存档，并且规则要写成可重复执行的脚本，将来任何一次新增页面都走同一套规则，人工命名迟早会出现例外。

## 响应头和页面里的声明不一致，改哪个更保险？

两个都要改成一致，但如果只能先改一个，改响应头。因为响应头的优先级更高，而且它对所有类型的文件都生效，包括那些不走程序的静态文件。页面里的声明只在响应头缺失或者不含字符集信息时才起作用，把它当成后备。改完之后一定要实际请求一次确认，很多服务器配置存在多层覆盖关系，站点级配置可能被目录级配置或者程序里的设置覆盖掉，改了以为生效其实没生效的情况非常常见。改完之后不仅要请求页面本身，还要请求几个静态文件和一个报错页，这三类响应经常由不同层级的配置控制，只验证页面很容易漏掉后两类。

## 用户能手动切换编码看正常，是不是就不算大问题？

对用户体验来说算小问题，对搜索来说是致命问题。用户看到乱码可以点几下菜单换个编码，抓取程序不会这么做，它按自己的判断处理一次就把结果存下来了。这就造成一个很有欺骗性的局面：站长自己打开页面一切正常，因为浏览器记住了他上次手动选的编码；而索引里存的是完全另一份东西。所以判断这类问题绝不能用自己的浏览器，一定要用干净的环境或者直接看原始字节。这个认知差是很多老站几年都没发现问题的根本原因。想验证得更彻底，可以换一个从没访问过这个站的环境打开一次，或者干脆用命令行取原始响应，两分钟就能确认真实状态，不必依赖任何工具的判断。

## 迁移完成后还需要保留对老编码的兼容吗？

页面内容不需要，站内搜索的入口需要保留一段时间。原因是用户的书签、外部站点的搜索表单、以及一些老的聚合工具可能还在按老编码提交查询参数。做法是在接收查询参数时加一层判断，如果按新编码解释不出合法字符，就尝试按老编码再解释一次。这层兼容逻辑保留三到六个月，看日志里老编码请求的比例降到可忽略之后再撤掉。页面内容侧则不建议做双编码提供，那会直接制造重复，得不偿失。兼容逻辑要写日志，记录每次触发的来源和参数，撤掉之前先看这份日志确认来源已经稀少，凭感觉决定什么时候撤，往往会误伤还在正常使用的老入口。

## 权威参考资料



## 小语种SEO按母语人口排优先级，排在最前面的那几门往往最后才该动

- URL：https://zhangwenbao.com/minor-language-seo-priority-language-cost-model.html
- 分类：小语种SEO
- 发布：2006-02-21  |  更新：2026-07-26
- 摘要：小语种SEO优先级怎么排？用可触达面、词表膨胀系数与内容供给密度三个语言层变量相乘打分，附六步手工估算流程与四种常见算错情形。
- 关键词：关键词研究,多语言SEO,小语种SEO

> **TLDR**：摘要：把小语种按母语人口从多到少排一列，再从上往下做，是这几年最常见也最贵的一种排法。真正决定一门语言值不值得做的不是有多少人说它，而是三个语言层的量：能用它在网上搜商品的人占多大比例、它的词形与写法会把关键词表撑成几倍、这门语言里已经有多少人在写同一类内容。这三个量都能手工估出来，估完之后排出的顺序，跟按人口排的那一列常常差着一大截。

> 摘要：把小语种按母语人口从多到少排一列，再从上往下做，是这几年最常见也最贵的一种排法。真正决定一门语言值不值得做的不是有多少人说它，而是三个语言层的量：能用它在网上搜商品的人占多大比例、它的词形与写法会把关键词表撑成几倍、这门语言里已经有多少人在写同一类内容。这三个量都能手工估出来，估完之后排出的顺序，跟按人口排的那一列常常差着一大截。

## 为什么按母语人口排小语种优先级，第一年就会做反？

## 母语人口和会用这门语言搜商品的人不是一个数

拿到一张语言人口表，最直接的用法就是从上往下数，挑几门排名靠前的语言先做。

这张表统计的是把某门语言当母语的人，而不是会在浏览器地址栏里用这门语言打字的人。

两者之间隔着三道过滤：这些人有没有上网、上网时用不用这门语言、买东西时会不会用这门语言搜。

每过一道，人数就掉一截，掉的比例还在不同语言之间差得很远。

有的语言三道过滤下来只剩两成，有的语言能剩八成，而人口表上它们可能只差一名。

按未经过滤的数字排序，等于拿一个跟结果关系很松的量在排优先级。

还有一层过滤常被忽略：同一门语言在手机和电脑上的实际使用比例并不一致，手机出厂时预装的界面语言往往是本地语言，而办公电脑常年停在另一套界面上，同一批用户在两台设备上会打出两种语言的查询。

把这三道过滤画成一个漏斗，再给每一层填上自己市场的实际比例，最后剩下的那个数才是这门语言真正的目标人群。多数团队从来没画过这个漏斗，直接拿漏斗口的数字当结论用了好几年。

## 名义语言人口里，有多大一块根本不用这门语言搜

很多市场存在一门通用的第二语言，它在搜索这个场景里的占比远高于日常口语。

原因不复杂：搜索框里打的多半是商品名和型号，而这类词在当地往往就是外来形态。

受教育程度越高、品类越偏技术，用第二语言搜的比例越高，这一点在任何市场都成立。

所以同一门语言在食品品类里可能覆盖九成搜索，在电子配件品类里只覆盖三成。

这意味着优先级不是语言的属性，而是语言与品类交叉之后才成立的一个量。

不带品类谈某门语言值不值得做，讨论一定会停在各说各话上。

有个不用查任何统计就能判断品类外来度的土办法：看这个品类的商品包装上，规格参数是用哪种语言印的。包装印本地语言的品类，用户多半也用本地语言搜；规格全印英文的品类，用户大概率照着包装打字。

还有一个信号是本地零售商自己的选择：他们的商品标题用哪种语言写品类名。做生意的人对用户怎么搜最敏感，他们的标题写法本身就是一份免费的市场调研结论。

## 一门语言的实际可触达面该怎么估

手上没有现成数字的时候，可以用三个能自己拿到的量拼一个估计值。

第一个量是这个市场的上网人数，各国统计部门每年都会公布，误差不会大到影响排序。

第二个量是用这门语言的网页在该市场网页里的大致占比，靠抽样搜十几个品类词就能看出量级。

第三个量是本站已有流量里来自这个市场的部分，按浏览器语言与访问语言分开数一遍。

三个量相乘得到的不是精确值，但它跟人口表给出的顺序常常完全不同，这就够用了。

估算的目的从来不是算准，是把明显排错的位置挪回去。

第四个可以自己拿到的量藏在服务器日志里：浏览器发过来的语言偏好请求头一直在被记录，只是几乎没人去统计它的分布。把这一栏按国家分组数一遍，得到的语言占比比任何外部报告都贴近你自己的用户。

## 一门语言的关键词表会膨胀几倍，能不能先算出来？

## 词形复杂度决定词表的基数倍数

同一个商品概念，在不同语言里对应的搜索写法数量差得非常悬殊。

词形基本不变的语言，一个概念对应一到两种写法，词表规模跟中文差不多。

名词有格变化的语言，一个概念要展开成六到十几种写法，还要跟形容词的形态配套。

后缀能一层层往上叠的语言更夸张，一个词根接出来的形态在实际语料里能有几十种。

这个倍数不用查论文，翻一眼这门语言有没有公开的词干剥离算法、规则有多少条就能看出量级。

规则条数越多、例外越密，说明形态越复杂，词表膨胀得越厉害。

Snowball公开的词干算法清单 (https://snowballstem.org/algorithms/)是个很省事的参照，能查到算法的语言，形态规律基本都已经被总结清楚。

看词干算法时有个细节要单独盯：规则条数之外还要看它附带的例外词表有多长。例外表越长，说明规则本身覆盖不了的情况越多，这门语言上任何按规则做归并的工具都会漏，人工核对的比例要相应提高。

另外要注意形态复杂度和用户实际打字习惯不完全一致。有些语言虽然名义上有十几种形态，但搜索框里出现的高频形态只有三四种，剩下的形态在书面语里才用。先按语料估一遍高频形态占比，能把词表规模砍掉不少。

估形态倍数时不要只看名词，形容词跟着名词变形的语言，商品标题里的属性词会连带展开一遍，实际组合数是名词形态数乘形容词形态数，这个乘法关系才是词表真正膨胀的地方。

## 书写系统的数量是第二个乘数

有的语言只有一套字母，有的语言在实际使用中同时跑着两套甚至三套。

两套字母意味着同一个词有两条完全不同的字符序列，搜索时不会自动互通。

更麻烦的是第三种形态：用户拿另一套字母把这门语言拼出来，既不属于第一套也不属于第二套。

这三种形态在关键词表里都要占位置，否则总有一批搜索落不到你的页面上。

Unicode已经收录的书写系统列表 (https://www.unicode.org/standard/supported.html)可以用来确认一门语言到底牵涉几套字符集合。

确认完之后，把书写系统数量当成一个直接乘到词表规模上的系数就行。

还有一个容易漏的细节：同一套字母在不同语言里用到的字符子集并不相同，多出来的那几个字母往往正是区分语言的关键。做字符白名单和输入校验时要按语言取子集，整块拿一套字母表进来会放进一堆本语言根本不用的字符。

## 地区变体是第三个乘数

一门语言跨几个国家使用时，同一个商品在各地的常用叫法经常不一样。

这不是方言口音的差别，是名词本身换了一个词，两边的用户互相听得懂但不会那么搜。

变体的数量取决于这门语言覆盖几个有独立零售市场的国家，通常在一到四之间。

把变体数当乘数时要打个折，因为大量通用词在各地是一致的，只有品类名和属性词会分叉。

经验上打到六折比较接近实际，两个市场的变体大约让词表增加六成而不是翻倍。

这一层的成本主要不在写词，在于要有人能判断哪个词属于哪个市场。

实际拆词表时会发现，分叉最密集的从来不是品类主词，而是两类词：容器与包装单位的叫法，以及折扣促销的固定说法。前者影响商品标题，后者影响活动页，两类都直接对着转化，偏偏最容易被当成小事一笔带过。

判断某个词有没有跨市场分叉，最快的办法是把它丢进两个市场各自的本地零售站站内搜索里，一个有结果一个没有，就说明这个词在其中一边不是常用说法。

## 三个乘数连乘之后的实际工作量

形态倍数、书写系统数、地区变体系数三者相乘，得到的是这门语言的词表膨胀系数。

系数落在一到三之间的语言，关键词研究的工作量跟英语市场是一个量级。

系数落在三到八之间的，要多准备一倍的时间，工具给的数据要人工重新归并。

系数超过八的语言，靠工具跑不出可用词表，必须先建一套形态归并规则再谈选词。

把这个系数写在优先级表的第二列，比写搜索量有用得多，因为它直接对应人力预算。

顺带一说，这一列也能帮团队回答一个老问题：为什么同样是做一门语言，有的两周就上线，有的排期三个月还没出词表。

把这三个乘数写清楚以后，排期争论会少一大半。

膨胀系数还有一个不太直观的用处：它同时决定了内部链接的维护成本。在形态丰富的语言里，同一个目标页面在不同上下文里的锚文本要跟着句子变形，写死一种形态的内链读起来会明显不通顺，这部分工作量按页面数线性增长。

## 竞争密度该看工具给的难度分，还是看这门语言里有多少人在写？

## 关键词工具在小语种上给的数字为什么不能直接用

工具给的搜索量和竞争度都建立在样本上，样本量在小语种上往往薄到不可靠。

更常见的问题是它把一个词的所有形态合并成一行，让人以为这个词的搜索集中在一种写法上。

还有一种情况是它把这门语言的查询和邻近语言的查询混在同一个数字里。

数字越小的语言，这几种误差占比越高，最后可能整整差一个数量级。

所以在小语种上，工具数字适合用来判断有没有需求，不适合用来判断需求有多大。

判断竞争强弱要换一个更笨但更可靠的口径。

还有一个结构性偏差：这类工具通常按语言聚合数据，而不是按国家。跨国使用的语言拿到的是几个国家加总的数字，其中大头可能来自你根本不打算做的那个市场。拿到数字后要按国家再拆一次，拆不出来就只当作有无需求的信号。

还要留意一种数据错配：有些工具会把拼写相近的邻近语言词条归到同一行，两门语言在词表层被悄悄合并，你看到的搜索量里混着一部分根本不属于这个市场的查询。

## 本地内容供给密度怎么手工估

挑十个这门语言里的核心品类词，逐个搜一遍，只看首页十条结果。

数三件事：有几条是本地站、有几条是跨国站的翻译版、有几条根本是别的语言的页面。

本地站占八条以上的品类，内容供给已经饱和，进去要拼的是内容质量而不是有没有内容。

本地站不足三条、其余全是翻译版和外语页面的品类，说明这门语言里几乎没人认真写过。

后一种情况是最值得先做的，因为把内容写对本身就是差异化，不需要额外的花招。

这个手工采样十个词只要半小时，比任何一个难度分都更贴近实际情况。

数结果的同时顺手记一件事：这些本地站的页面是什么时候写的。如果前十条里的本地内容大多停留在两三年前，说明这个市场没有人在持续更新，入场之后只要保持更新节奏就能拿到位置，成本比数字显示的低。

这个采样还能顺带回答一个问题：这个品类的结果里，有多少条是标题堆词、正文空洞的老式页面。这类页面在很多小语种市场里仍然占着位置，而它们经不起任何一次针对内容质量的调整，2003年那场影响面很大的算法调整 (https://zhangwenbao.com/google-florida-update-2003-explained.html)已经演示过一次这类页面是怎么整批消失的。

采样时把结果按页面类型记一列，商品列表页、单品页、导购内容页各占多少。三类比例不同，代表这个市场的内容竞争阶段不同，也决定你第一批该铺哪一类页面才最快见效。

## 供给稀薄和需求稀薄要分开看

一门语言里没人写内容，可能是因为没人搜，也可能是因为没人愿意做。

这两种情况看上去一样，处理方式完全相反，判错了就是白扔预算。

区分的办法是看这个市场的广告投放密度，有人肯为这类词付钱，说明需求是真的。

广告位也空、自然结果也空的品类，多半是需求本身就不存在，绕开就好。

广告位满、自然结果空的品类，是最理想的入场点，说明钱在流动但内容还没跟上。

保哥在给一个做宠物食品的站排语言顺序时，就是靠这一条把一门排在第七的语言提到了第二位。

还有第三个信号可以用：本地的问答站和论坛里有没有人问这类问题。广告位空、自然结果空、但论坛里讨论热烈，说明需求真实存在只是还没被商业内容覆盖，这种组合是所有情形里最值得先进的一种。

## 借词多的语言，是不是可以少做一半功课？

## 用户直接搜外来原词的那部分流量

有些品类的词在很多语言里根本没有本地对应，用户直接用原词搜。

这部分查询的写法跟英语几乎一致，理论上现成的英语页面就能接住。

但接住的前提是页面语言与用户预期一致，用户搜的是英文词，想看的是本地语言的页面。

所以借词多不等于工作量减半，只等于关键词表里少了一部分要翻译的词。

内容本身、价格、配送信息、客服语言，一样都不能少。

把借词比例当作省钱理由，通常在上线三个月后被跳出率打脸。

这两类词的意图也不一样：打外来原词的用户更多在查资料和比参数，打本地词的用户更接近下单。所以它们该落到不同类型的页面上，原词接科普与对比内容，本地词接商品列表和详情，混在同一个页面上两边都接不好。

## 借词的本地拼写会分裂成好几种写法

借词进入一门语言之后，往往会长出一套本地拼写，跟原词并存。

有的语言会把它按本地读音重新拼一遍，有的语言原样保留，还有一部分用户两种都打。

更麻烦的是形态语言会给借词也接上格尾，于是原词和本地拼写各自再展开若干形态。

这时候借词不但没让词表变小，反而制造了一批跨形态的重复。

处理这类词的正确做法是原词与本地拼写都做，但只给其中一种做落地页。

另一种放进页面正文和内部锚里，靠语义关联接住，不必单开页面。

分裂通常不是从单数形态开始的。单数写法两边一致，复数或者带格尾的形态却各走各的，这种情况在实际语料里非常普遍，也正是只查词典原形的选词方式最容易漏掉的一块。

## 借词比例高的语言反而更容易漏词

直觉上借词多的语言好做，因为看得懂；实际情况正好相反。

看得懂会让人省掉验证这一步，直接把原词抄进词表，漏掉本地拼写的那一半。

而本地拼写往往是普通用户更常用的形态，专业用户才习惯打原词。

一个站如果只覆盖原词，接到的就是专业用户那一小撮，转化率数据还会显得很好看。

看着转化率不错就不再扩词，这个坑一埋就是好几年。

所以借词多的语言要额外做一件事：把每个借词的本地拼写单独查一遍，不能靠感觉。

有个成本很低的补救办法：抓十家本地零售站的商品标题，做一次粗糙的分词统计，出现频次最高的那批词就是本地用户真实在用的写法。这份表跟你自己的词表一对照，漏了什么一眼就看出来，不需要任何语言学知识。

## 一门语言里有几套写法，就要按几套算预算吗？

## 同一门语言两套字母的情形

有些语言在法律和习惯上同时使用两套字母，两套都算正式写法。

这种情况下两套字母之间通常有严格的一一对应，机器转换可以做到完全可逆。

能可逆意味着内容可以自动生成两份，边际成本主要落在页面数量和索引量上，不在写作上。

但要注意两套写法的用户群不完全重叠，年龄和地区分布都有差异。

先做用户量大的那一套，另一套等第一套跑出数据之后再决定要不要铺。

这类语言的预算不是翻倍，大概是一点三到一点五倍。

技术上有一条要提前定死：两套写法的转换要在服务端一次性生成两份内容，不要做成浏览器里的实时切换。实时切换看着省事，代价是两套写法共用同一个地址，搜索侧永远只能看到其中一套。

## 同一门语言两套正字法的情形

另一种情况是两套写法不能机器互转，因为它们在词汇层就有分歧。

这时候两套写法背后其实是两套词表，甚至是两批不同的写作者。

预算要按接近两倍算，而且要提前想清楚这两份内容之间的关系怎么表述。

如果只做一套，要选的是覆盖用户多的那套，而不是更规范的那套。

规范程度对搜索的影响，通常比不上用户实际打字习惯的影响。

这一条在任何有正字法争议的语言里都成立，没有例外。

分歧的落点也有规律：本土固有词在两套正字法里通常写法一致，真正分叉的是外来词的转写规则。而商品品类名恰恰有很大比例是外来词，所以正字法分歧对做电商的影响，比对做新闻的影响大得多。

## 转写与原字并存的情形

第三种情况最容易被漏掉：用户用另一套字母把这门语言拼出来。

这种拼法没有任何官方地位，拼写也不统一，同一个词能出现四五种拼法。

但它在搜索日志里的占比常常不小，尤其在移动设备和公共电脑上。

处理这类形态不需要单独做页面，只要在页面正文和内部链接里覆盖几种主流拼法即可。

如果这门语言的转写形态占比超过两成，那它就该在预算里单列一行。

把这一行漏掉，等于默认放弃了两成的搜索面。

判断这类形态占比时，站内搜索日志比外部数据更能说明问题。外部搜索会做拼写纠正和同义扩展，把转写形态悄悄纠回原字；站内搜索一般没有这层处理，用户打了什么就记什么，比例是原始的。

## 语言之间的距离，能不能折算成内容复用率？

## 近亲语言之间能共用的是哪一层

两门语言互相听得懂，不代表两个市场的内容可以共用一份。

可以整块共用的通常只有三类东西：图片、尺寸与规格数值、以及不含文字的结构。

需要逐词替换的是品类名、属性词和促销用语，这部分是分叉最密集的地方。

必须完全重写的是标题、页面描述和正文，因为这三处直接决定能不能被搜到。

把资产按这三档分类，复用率就能变成一个可以填进表格的百分比。

百分比出来之后，排期和预算的争论会立刻变成算术题。

数值型属性看起来最安全，其实也有一个坑：数值本身可以共用，写法不行。小数点用逗号还是点、千位分隔怎么写、单位符号放在数字前还是后，这几处在近亲语言之间经常不一致，而它们直接出现在商品标题里。

## 距离近不等于能省钱

两门语言越近，反而越容易出一类隐蔽问题：内容看起来对，读起来别扭。

用户不会写反馈邮件说哪里别扭，他们只是不再往下读。

这种损耗在数据上表现为停留时间短、加购率低，很难归因到语言上。

所以近亲语言的复用要么做到位，要么干脆分开做，卡在中间是最贵的。

做到位的标准很简单：找一个母语用户读一遍，问他这像不像本地人写的。

这一步的成本比返工低得多，但经常被排期挤掉。

近亲语言之间最贵的一类词是形态相同意思不同的那批。人眼扫过去不会停顿，机器比对也发现不了，只有母语用户读到具体句子时才会觉得别扭。把这类词整理成一张对照表，是近亲语言项目里回报最高的一次性投入。

## 用复用率给近亲语言打包排序

把复用率高的几门语言打成一包，整包评估投入产出，比单门语言评估更接近实际。

一包里做第一门语言的成本最高，第二门和第三门的边际成本会明显下降。

所以整包的收益要用总和算，不能用第一门语言单独的收益来判断值不值得开工。

这也解释了一个常见现象：某门语言单看不值得做，放进它所在的语族里就值得。

打包评估的前提是先把三档资产分清楚，否则边际成本下降只是想象。

估完之后按包排序，包内再按市场规模排，顺序就出来了。

包内的顺序还有一条经验：先做语族里形态最复杂的那门语言。从复杂往简单推，形态归并规则可以直接裁剪复用；反过来从简单往复杂推，前面做的规则基本用不上，等于重做一遍。

整包评估还要留一条退出线：如果第一门语言跑完之后实际复用率明显低于预估，就该重新评估整包而不是硬着头皮往下做，复用率是这类打包决策唯一真正的支撑点。

## 三笔账怎么合成一个能拿去开会的分数？

## 三个变量各自的取值区间

第一笔账是可触达面，用上网人数乘语言占比得到，单位是人。

为了方便比较，把它换算成相对值，最大的那门语言记作十分，其余按比例折算。

第二笔账是词表膨胀系数，取值一到十二，直接对应人力成本。

第三笔账是内容供给密度，按首页十条里的本地站数量取值，零到十。

三个数量纲不同，所以要先各自归一化再进入下一步。

归一化的方式不重要，重要的是全程用同一套，中途换算法就没法比了。

归一化的方式虽然可以自选，但有一个选择明显更好：用对数而不是线性。语言人口跨着好几个数量级，线性归一会让除了最大那几门之外的语言全挤在接近零的位置，整张表就失去了区分度。

另一个实操细节是保留原始值。归一化之后的分数便于比较却不便于解释，会上有人质疑某一格时，能立刻翻出原始的人数和采集来源，讨论就不会卡住。表里多两列的成本，远低于当场答不上来的成本。

## 加权还是相乘

三个变量之间不是彼此独立的贡献，而是有明显的相互制约关系。

可触达面再大，如果词表膨胀系数高到做不出来，实际收益就是零。

内容供给密度再低，如果没人搜，空着也没有意义。

所以这三项更适合相乘而不是加权求和，任何一项接近零，总分就该接近零。

具体算法是可触达面分数除以膨胀系数，再乘以供给稀薄度，得到一个综合分。

这个式子不精确，但它至少不会让某一项的短板被另外两项的高分掩盖过去。

相乘式要配一个下限保护。任何一项低于事先约定的阈值，就直接标记为本轮不做，而不是让它乘出一个很小但非零的分数继续排在表里。小分数会给人一种再努努力就能做的错觉，实际上短板是结构性的。

算完之后建议手工验算两三个极端例子：一门人口极大但形态极复杂的语言、一门人口很小但完全没人写的语言，看它们的分数排在哪里。如果排位明显反直觉，多半是某一项的归一化范围没设好。

## 分数出来之后怎么分档

把所有候选语言的综合分排一列，通常会自然分成三段。

头部几门明显高出一截，这几门是要投入完整资源做的。

中间一段分数接近，彼此差异在误差范围内，这时候按团队现有语言能力选。

尾部一段分数很低，明确写进不做的清单，附上原因和复审时间。

写清楚为什么不做，比写清楚为什么做更能减少后面的反复讨论。

半年之后拿出来复审一遍，供给密度这一项变化最快，可能会把某门语言推上来。

复审时只重算变化最快的那一项，另外两项半年内基本稳定，不必每次全算。

分档的边界不要用固定百分位，用分数序列里的自然断层。把分数从高到低排一列，逐个算相邻两项的差值，差值最大的那两个位置就是天然的分界线。这样分出来的档，讨论时基本不会有人觉得某门语言被硬塞进了错误的那一档。

## 分数表要带哪几列才不会被推翻

只给一个总分的表最容易被质疑，因为没人知道分是怎么来的。

把三个原始量、三个归一化值和最终分并排放在一张表里，讨论就有了共同起点。

再加一列写清楚每个数字的来源和采集日期，半年后复审时不用重新考古。

最后加一列写这门语言目前团队里有没有人能读，这一列常常直接决定实际排期。

有了这五类列，这张表就能一直用下去，而不是做完一次就扔。

会上真正争论的其实很少是分数本身，多半是某个数字的来源可不可信。

还可以加一列敏感度标注，写清楚这一格的数字如果错了会有多大影响。三个变量里，词表膨胀系数错一档的后果最严重，因为它直接对应人天；可触达面错三成基本不影响排序结论，标注清楚可以让复审时的精力花在对的地方。

## 分数排完，第一门语言该怎么挑？

## 先挑一门用来校准模型的语言

第一门语言的作用不只是拿流量，更重要的是验证这套估算靠不靠谱。

所以第一门最好选一门形态不太复杂、团队里有人能读、市场规模中等的语言。

形态简单能让上线速度快，有人能读能让问题及时被发现，规模中等能让数据有统计意义。

分数最高的那门语言常常不满足这三条，急着上反而拖慢整个计划。

先用一门好做的语言把流程跑通，再上难的，总时间反而更短。

这个顺序看着不直觉，但做过两轮的人基本都会这么排。

如果本站已经有一门语言在自然获得少量流量，那它就是最好的校准对象。有基线才分得清提升来自内容本身还是来自这个市场本来就在增长，从零开始的语言两个月后拿到的数字，很难判断算好还是算差。

## 第一门语言的验收指标该定什么

不要用收入当第一门语言的验收指标，周期太长，也受太多非语言因素影响。

更合适的指标是关键词覆盖率：词表里有多少词能在结果里找到自己的页面。

第二个指标是形态覆盖率：同一个概念的各种写法有没有都能落到同一个页面上。

第三个指标是本地用户的可读性反馈，找三到五个真人读一遍就够。

这三个指标都能在两个月内拿到结果，足够决定要不要往下推。

收入指标放在第二门语言开始之后再看，那时候才有可比的基线。

形态覆盖率的具体测法值得写死：抽二十个核心商品概念，每个概念把实际可能出现的形态全部列出来，逐个搜一遍，看是不是都能落到同一个页面上。落到不同页面或者落不到，都算未覆盖，这个口径不会有歧义。

这三个指标还有个共同的好处：它们都不受市场大小影响。换一门语言继续用同一套指标，数字可以直接横向比较，几轮下来就积累出了各语言的执行质量对照，比单纯看流量更能反映团队的实际能力。

除了这三个指标，还要记一个过程量：从词表定稿到第一批页面上线花了多少天。这个数字是后面所有语言排期的基准，没有它，第二门语言的时间估算又只能靠拍脑袋。

## 校准完之后往下推的顺序

第一门语言跑完，回头把估算模型里的三个量重新校一遍。

实际的词表膨胀系数几乎总是比估计值大，通常大三成到五成。

把这个偏差系数记下来，后面每门语言的估算都乘上它，排期就准多了。

可触达面这一项通常估得偏保守，因为没算上邻国用同一门语言的用户。

供给密度这一项最准，因为它是手工数出来的，没有中间环节。

校准之后的第二轮排序，跟第一轮相比通常会有一到两门语言换位置。

偏差系数最好按内容类型分别记。商品页的实际膨胀系数通常比预估高得多，因为属性词的组合会成倍展开；而资讯类内容页的形态压力小得多，用同一个系数去估两类内容，一定会有一类排期严重失真。

## 这套账在什么情况下会算错？

## 数据源本身不可靠的情形

上网人数和语言占比这两个数，在部分市场只有口径不一致的几份统计。

遇到几份数据差异超过三成的市场，不要取平均，取最保守的那一份。

取保守值的好处是排序结果偏稳，不会因为一个乐观数字把某门语言硬推上去。

如果连保守值都拿不到，就用邻国同类市场的数字做代理，并在表里标明这是代理值。

标明代理值不是形式主义，半年后复审时它决定了要优先重新采集哪一格。

整张表里代理值超过三分之一时，这轮排序只能当参考，不能当决策依据。

口径本身也要看清楚。官方公布的语言普及率统计的多半是能用这门语言，而搜索关心的是会主动用它打字。这两个数在很多市场差得很远，看到一个高得反常的比例时，先去确认它统计的是哪一个。

## 品类与语言的耦合被忽略

前面说过优先级是语言与品类交叉的量，但实际做表时很容易只按语言排。

同一套语言排序拿去给两个差异很大的品类用，一定有一个会做错。

正确的做法是每个主力品类各做一张表，三个变量里只有可触达面需要重算。

词表膨胀系数和内容供给密度可以在品类之间共用，改动量不大。

做两张表的额外成本大概是半天，比做错一门语言的成本低两个数量级。

如果品类跨度实在太大，那本来也不该用同一个站去覆盖。

差异有多大常被低估：同一门语言在礼品类和工业耗材类上的可触达面，差距可能比两门完全不同的语言之间还大。所以真正需要多做几张表的不是语言维度，而是品类维度，这一点跟直觉正好相反。

## 团队里没有母语人的情形

三个变量里，内容供给密度这一项需要能读懂结果页才能数。

没有母语人时可以靠机器翻译大致判断，但误差会明显变大。

补救办法是把采样量从十个词加到三十个词，用样本量换准确度。

另一个办法是只数结果的域名归属，本地后缀域名的比例是个粗糙但可用的代理指标。

这两个办法都能让这一项勉强可用，但都不能替代真正读懂内容。

所以团队里第一个该招的不是更多写手，是一个能读目标语言的人。

用机器翻译辅助判断时，要把任务限定在它能做好的那一类上。判断一条结果是不是本地站，看域名后缀、地址和货币符号就够，机器翻译只要能读出这几项就行；判断内容质量高不高则完全不可靠，不要让它做这个决定。

## 把语言当成国家来算

最后一类错误是把语言和国家画等号，一门语言配一个国家。

实际上一门语言可能跨五个国家，一个国家也可能有三门通用语言。

按国家排会把跨国语言的可触达面严重低估，按语言排会把多语国家的复杂度低估。

正确的做法是两张表都做：语言表决定内容做几套，国家表决定站点结构和履约。

这两张表本来就该分开，混在一起是很多多语言项目一开始就走偏的原因。

说白了，语言决定你写什么，国家决定你怎么收钱和发货，两件事没必要挤在一个格子里。

跨国语言还要按国家分别数一遍供给密度。同一门语言在两个国家的竞争强度可以差出三倍，因为本地零售生态完全不同。只数一个国家就把这门语言的竞争度定下来，另一个国家的机会要么被高估要么被彻底忽略。

两张表之间还要留一条对照线：语言表里的每一门语言，要标明它对应哪几个国家；国家表里的每个国家，要标明它需要哪几门语言。两边对不上的格子，通常就是项目后期最容易出问题的地方。

## 优先级排完之后，哪些事本来就不归语言层管

## 域名与目录结构不在这笔账里

选独立域名、子域名还是子目录，是站点架构问题，跟语言本身的难度无关。

这个决定影响的是维护成本和权重集中程度，不影响关键词表要写多少词。

把架构决定和语言优先级混在一起讨论，会让两个问题都得不到结论。

正确的顺序是先定做哪几门语言，再定这几门语言的内容放在什么结构下。

顺序反过来的项目，通常会因为架构方案迟迟定不下来而拖住内容排期。

架构那半边的判断标准另有一套，本篇不重复。

语言表最终要交给架构那一侧的其实只有一个数字：内容总份数。这个数不等于语言数，两套字母的语言算两份，需要按地区再分的语言按地区数算。接口只有一个数字，两边的责任边界就非常清楚。

把这个数字定下来还有个附带好处：它同时是内容团队的排期基数和技术团队的工作量基数，两边不用再各自估一遍。以往很多多语言项目的排期分歧，根子上就是两边心里的份数不是同一个数。

## 用哪个搜索引擎也不在这笔账里

有些市场的主流搜索引擎不是同一个，这确实会影响操作细节。

但它影响的是提交方式、收录节奏和排序偏好，不影响这门语言有几种词形。

语言层的功课做完之后，引擎层的差异是可以另外补的，反过来则不行。

先按引擎排语言优先级，会得到一个跟内容工作量完全脱节的顺序。

这两层的关系可以这么理解：语言决定你要准备多少弹药，引擎决定你往哪个方向打。

准备弹药的账，跟选方向的账，本来就该分开算。

引擎差异确实会反过来影响一点语言层的工作量：有的引擎自己会做词形归并，有的基本不做。前者可以少铺一些形态变体，后者必须把主要形态都铺出来。但这只是调整铺词的细度，不改变这门语言本身有多少种形态。

## 支付、物流和法务不在这笔账里

能不能收到钱、能不能发到货，是这门语言值不值得做的前置条件，不是评分项。

把它们当条件，先筛掉不可行的市场，再对剩下的语言算三笔账。

混进评分里会出现一种怪现象：某门语言分数很高但根本发不了货，表却看不出来。

所以这几项应该出现在表的最左边，作为通过或不通过的开关列。

开关列为否的语言直接不进入评分，省得后面反复解释为什么排在前面却不做。

把条件和评分分开，是这张表能长期用下去的关键。

开关列还要写上复审日期。物流覆盖和法务限制都是会变的，今年发不了货的市场明年可能就通了，写了日期才会有人回头去看，否则这几格会一直保持着第一次填写时的状态，把一个已经可做的市场长期挡在门外。

## 常见问题解答

## 手上完全没有目标市场数据时，这套账还能算吗？

能算，但要接受结果只能用来排序不能用来定预算。三个变量里，词表膨胀系数完全不依赖市场数据，翻词干算法和字母表就能估出来；内容供给密度只要能搜到结果页就能手工数，不需要任何工具授权；只有可触达面这一项需要外部统计。所以在完全没数据的情况下，可以先用另外两项排一个初步顺序，把明显做不动和明显没人写的两头先分出来，中间那一段等拿到流量数据再细排。实际操作里，光靠后两项就能把候选语言从二十门砍到六七门，剩下的差异本来也需要真实数据才判断得了。还有一个补充办法是拿邻近市场做代理：语言不同但经济结构和零售形态接近的市场，其供给密度和品类结构往往有参考价值，先借来排个大概，等自己的数据攒够再替换掉。

## 词表膨胀系数具体怎么手工估出一个数？

先确定形态倍数：查这门语言有没有公开的词干剥离规则，规则在二十条以内取二，二十到五十条取六，超过五十条或者以后缀叠加著称的取十。再确定书写系统数，实际在用的字母套数是几就取几，用户自发的转写形态额外加零点五。最后确定地区变体系数，覆盖一个零售市场取一，两个取一点六，三个以上取二。三者相乘就是膨胀系数。这个算法粗糙到会让语言学出身的人皱眉，但它的输出跟实际投入的人天数相关性相当高，而且任何人算出来的结果都差不多，这一点比精确更重要。算完之后建议把这个系数和实际投入的人天记在同一张表里，做过三门语言就能反算出属于自己团队的换算比例，之后的排期估算会比任何通用经验值都准。

## 综合分相同的两门语言，该先做哪一门？

先做团队里有人能读的那门。这不是妥协，是因为分数相同意味着模型已经区分不出优劣，这时候决定实际产出的是执行质量，而执行质量高度依赖有没有人能当场判断内容对不对。如果两门语言团队都没人能读，那就先做能找到本地审校的那门，找人的难度本身就是一个有效的排序依据。还有一个次要判据是这门语言的资料是否公开可查，词典、语料库、正字法规则能在网上找到的语言，做起来的摩擦会小很多，遇到疑问不用每次都等外部回复。还有一条容易被忽略的判据：这两门语言里有没有一门属于某个语族的核心，先做核心那门，后面同语族的几门都能吃到它的形态规则和词表结构，等于顺手买了一份期权。

## 内容供给密度靠手工数十个词，样本会不会太小？

对于排序目的来说够用，对于定预算不够。十个词的采样能可靠区分出饱和、中等和稀薄三档，这正是排序需要的粒度。如果要用这个数字去说服人批预算，那就把样本加到三十个词，并且按品类分层抽样，每个主力品类至少三个词。另外要注意采样时间：同一批词隔三个月再数一遍，如果本地站数量明显上升，说明这个市场正在被别人发现，入场窗口在收窄。这个变化速度本身比绝对值更有决策价值，很多团队只数一次就再也不数了，等于放弃了这个信号。采样时还要记下每条结果是商品页还是内容页，这个比例决定了你该先铺哪一类页面，两个市场供给密度相同但结构不同时，切入点完全不一样。

## 这套优先级模型多久该重算一次？

整体半年一次，其中内容供给密度这一项建议三个月一次。可触达面和词表膨胀系数都是慢变量，上网人口占比一年内变化有限，语言的形态更是几十年不变，重复计算的收益很低。内容供给密度是快变量，竞争对手进场、本地媒体开始做导购、平台方推本地化内容，都会在几个月内把某个品类从稀薄推向饱和。重算时只更新这一列，另外两列沿用上次的值并标注采集日期。整个复审工作量控制在一天以内，才有可能真的坚持下去，做成一天以上的流程通常第二次就没人做了。复审时把上一轮的预测和这一轮的实际结果并排放一次，模型的偏差方向会很快显现出来，通常两三轮之后估算精度就能稳定在一个可用的范围内。

## 如果老板坚持要先做人口最多的那门语言，怎么办？

把三笔账做成一张表给他看，重点不是结论而是中间的数字。多数情况下争议来自双方看的是不同的量：老板看的是市场潜力，执行团队看的是完成所需的人天。把词表膨胀系数这一列摆出来之后，讨论会从要不要做变成需要多少时间和人，这是个能谈的问题。如果最后还是决定先做那门语言，那就把它当成第一门语言来做，但要同步调低第一年的目标，并明确说明原因是形态复杂导致词表工作量翻了几倍。写清楚了，半年后复盘时不会变成执行不力的问题。真到了这一步，可以退一步提个折中方案：那门语言照做，但同时用很小的成本铺一门形态简单的语言当对照组，两个月后拿两组数据说话，比继续争论有效得多。

## 语言优先级和站点架构应该谁先定？

语言优先级先定，架构后定，中间不要交叉讨论。原因是架构方案的选择依赖于最终要做几门语言、每门语言有几套写法、内容是否需要按地区再分，这些都是语言层的输出。反过来先定架构，会导致语言方案被架构限制，比如已经定了每门语言一个子目录，后面才发现某门语言需要两套字母各一份内容，结构就得推倒重来。正确的节奏是语言表出来之后，把最终需要的内容份数交给架构那一侧，由他们去选结构方案，两边的接口就是这个份数，非常清晰。如果时间上实在没法完全串行，可以把架构方案先收敛到两三个候选，等语言表里的内容份数一确定，立刻就能从候选里选定，这样既不阻塞也不会推倒重来。

## 权威参考资料