匈牙利语SEO难住人的不是变音符号，也不是词序，是一个名词能接出十八种格尾

摘要：匈牙利语被夹在一圈印欧语中间，自己却不属于印欧语系。很多团队顺手把它归到土耳其语那一类，理由是两门都叫黏着语，结果后缀链长度、元音和谐的维度、动词跟着冠词换词尾这三件事全部估错。这篇先给出它跟土耳其语、芬兰语的三方差异表，再往下拆十八个格里真正要覆盖的是哪几个、字母索引为什么会排乱、姓名与日期格式该改哪几处。

匈牙利语在欧洲腹地是个什么样的存在？

打开地图看一眼，匈牙利被斯洛伐克、乌克兰、罗马尼亚、塞尔维亚、克罗地亚、斯洛文尼亚、奥地利围了一圈。

这七个邻国说的全是印欧语系的语言，斯拉夫语族、罗曼语族、日耳曼语族凑齐了三家。

匈牙利语一家都不沾。它属于乌拉尔语系，最近的亲戚在两千公里外的芬兰和爱沙尼亚，而且这个亲戚也远得听不懂彼此说话。

这个位置带来一个很实际的后果：你在邻国市场攒下的语言侧经验，到了匈牙利几乎全部作废。

词汇不通、语法不通、连语序的默认预期都不一样，能复用的只剩下货币格式和物流那些非语言字段。

我接过一个做箱包的站，团队在波兰和罗马尼亚都跑顺了，到匈牙利第一版关键词表被本地同事退回来重做，理由是一半的词形根本不会出现在真实查询里。

语言孤立还带来一个副作用：匈牙利语的对外借词比例低于周边任何一门语言，很多国际通行的技术词在这里都有一个自造的本地词，而用户搜的往往就是那个本地词。

所以做匈牙利市场时，最先要建的其实不是关键词表，是一张国际词与本地词的对照表，这张表建不好后面所有工作都建在沙子上。

它跟土耳其语同为黏着语，为什么不能照搬？

黏着语这个标签只说明一件事：语法信息靠往词尾接后缀来表达，而不是靠改词根或者加介词。

这个共性是真的，但共性之外的差别足以让两套处理方案完全不通用。

土耳其语的选词方法我在土耳其语那篇里按后缀链拆过一遍，那套方法的核心是算链的长度。

匈牙利语的链要短得多，格尾几乎总是挂在最外层，真正的麻烦不在链长，在于格的数量和元音和谐的维度。

表里最后两行是实际工程量差别最大的地方，字母表那一行直接决定了排序和索引要不要重写。

还有一个容易被忽略的差别：土耳其语的后缀几乎全是加在词尾的，而匈牙利语在动词那一侧有可分离前缀，处理逻辑要多考虑一个方向。

跟芬兰语才是一家，但差别在哪？

匈牙利语和芬兰语同属乌拉尔语系，这层亲缘关系比跟土耳其语的关系近得多。

但两门语言分家的时间早到什么程度呢，早到今天的匈牙利人和芬兰人互相听不懂一个词。

芬兰语的十五个格与词干交替，我在芬兰语那篇里讲过它为什么是欧洲最难做关键词研究的语言之一。

做过芬兰语再做匈牙利语，最容易犯的错是以为词干稳定，于是只处理词尾。

匈牙利语的词干确实不像芬兰语那样辅音成级交替，但它有另外两条自己的变法，后面会单独拆。

另外一条实用的判断：芬兰语的高频格分布比较分散，选词表要铺得宽；匈牙利语的高频格相对集中，可以铺得窄而深，预算分配的方式不一样。

十八个格到底是哪十八个，做SEO要关心几个？

十八这个数字本身就有争议，不同语法体系数出来的结果从十七到二十七都有。

争议的点在于某些后缀到底算格尾还是算已经固化的后置词，这属于语言学内部的划界问题。

做搜索这一侧不需要卷进这个争论，你需要的是另一个数字：真正会出现在查询里的格有几个。

答案通常是四到六个，其余十来个格要么只出现在完整句子里，要么语义太具体，用户不会拿它搜商品。

把有限的力气放在这几个格上，比背下全部十八个的词尾有用得多。

这也是匈牙利语跟芬兰语的一个实操差别：芬兰语的高频格更分散，匈牙利语相对集中。

顺带说一句，格的数量本身也是个营销话术，网上不少介绍匈牙利语难度的文章会把数字往大了说，实际做起来要处理的形态数量远没有那么吓人。

哪几个格会真的出现在搜索框里？

主格是词典形，商品列表页和分类名用它，这个没有悬念。

宾格要在词尾加一个t，出现在带动词的查询里，比如想买什么、在哪买什么这类句式。

位置类的三个格最值得关注：表示在里面的、表示到里面去的、表示从里面出来的，它们对应的是场景类查询。

还有一个表示为了什么用途的格，在挑选类查询里出现频率很高。

剩下的比如表示变成什么、表示作为什么身份，商品查询里基本见不到。

选词表就按这五六个格铺，每个核心词五六行，一个品类三五十个核心词，表的规模是可控的。

确认高频格最可靠的办法还是看站内搜索日志，把查询按词尾归类统计一遍，通常前五个格就能覆盖八成以上的查询量。

元音和谐是两维的，后缀该选哪个变体？

元音和谐的意思是后缀里的元音要跟着词根里的元音走，不能随便配。

匈牙利语的第一维是前后：词根里是前元音，后缀就用前元音的变体；是后元音，就用后元音的变体。

第二维是圆唇：某些后缀在前元音这一侧还要再分圆唇和不圆唇，于是同一个后缀有三种形态。

结果是同一个语法意义的后缀，在不同的词后面长得完全不一样，机械替换必错。

土耳其语也有这两维，但它的后缀普遍是二型或四型，规则更整齐一些。

匈牙利语的不整齐在于：哪些后缀是二型、哪些是三型，得逐个记，没有一条能覆盖全部的规则。

还有一类混合词根会让和谐规则失效：外来词和某些复合词的前后两半分属不同的元音类别，这时候按哪一半走要逐词确认，没有通用规则。

圆唇和谐这一维为什么工具经常算错？

通用的多语言处理库在实现元音和谐时，大多只做了前后这一维。

原因很实际：前后这一维覆盖了大部分情况，做完就能交差，圆唇那一维的收益不明显。

但对搜索来说，算错的那部分恰恰集中在高频词上，因为高频词里前元音词根的占比不低。

检验办法很简单：拿十个已知的前元音词根，让工具生成带某个三型后缀的形态，看它是不是全部只给了一种。

只给一种就说明圆唇那一维没实现，这时候要么换库，要么自己补一张例外表。

例外表通常两三百行就够，覆盖你品类里的核心词，比换整套技术栈现实。

补例外表的时候顺手记录每个词的元音类别，这一列后面在生成变体、配同义词、写标题模板时都会反复用到，一次录入长期收益。

什么是低元音词干，为什么规则推不出来？

正常情况下，后元音词根接复数后缀时用的元音是一种，接完读起来顺。

但有一批词偏偏要用另一个更开口的元音，语法书管这类叫低元音词干。

房子这个词就是典型：按常规规则推出来应该是一种形态，实际的复数用的是另一个元音。

这类词没有形式上的标记，你看着这个词根本判断不出它属不属于这一类。

唯一的办法是查词典逐个确认，然后把结果存进属性字典的一个布尔字段里。

匈牙利语的这个坑跟罗马尼亚语那篇里的中性名词是同一类问题：规则给你百分之八十，剩下百分之二十只能靠数据。

这类词在日常高频词里的占比其实不低，房子、道路、桥这类基础名词很多都在名单上，所以品类词表里撞上的概率比想象中大。

消失元音词干会怎么把词根切坏？

另一类词干变化更麻烦：词干里倒数第二个位置上的元音，在接后缀时会整个消失。

灌木这个词的复数就是这样，词根中间那个元音在复数形态里没有了。

后果是词根本身的字符串变了，不再是原形的一个前缀。

这一下把前缀匹配、自动补全、以及所有假设词根稳定的逻辑全部打穿。

处理办法只有一条：把这类词的所有形态都写进索引，别指望算法能还原。

好消息是这类词的数量有限，通常在两三百个量级，其中跟你品类相关的可能只有十几个。

识别这类词有个粗糙的线索：词干倒数第二个音节的元音如果是短的、且这个词是两音节的，那它属于这一类的概率明显偏高，可以拿来做初筛。

定冠词决定动词用哪套词尾，这条印欧语里没有

这是匈牙利语最反直觉的一条，也是同类文章几乎不会提的一条。

匈牙利语的及物动词有两套人称词尾：一套用在宾语是确定的时候，一套用在宾语不确定的时候。

说我买一个包和我买那个包，这两句里的动词形态是不同的，变的不是宾语而是动词。

换句话说，定冠词的出现会往回改动词的词尾，这个联动在印欧语里完全没有对应物。

做搜索时的直接影响是：同一个意图的问句型查询，会以两种不同的动词形态出现在日志里。

你如果只按其中一种形态铺内容，另一半查询就接不住，而且从中文一侧完全看不出这里少了什么。

再补一层：不是所有确定性都靠定冠词表达，专有名词、带领属后缀的名词、指示代词修饰的名词，天然就是确定的，动词照样要走确定那一套。

问句型查询里会同时出现哪两种动词形态？

拿箱包站最常见的一类查询举例：想知道在哪儿买行李箱。

如果句子里说的是买行李箱这个泛指，动词走不确定那一套。

如果说的是买这个行李箱，动词走确定那一套，词尾不一样。

用户搜商品时两种都用，比例大致跟查询里带不带指示词有关。

内容侧的处理办法是在FAQ和正文里让两种句式都自然出现一次，不必刻意堆砌。

站内搜索这一侧则要在同义词表里把两种动词形态映射到一起，否则零结果率会莫名其妙地高。

做查询分类时可以把动词形态当成一个意图信号：走确定形态的查询往往指向具体某件商品，走不确定形态的更偏向品类浏览，两者该落到的页面类型不一样。

领属后缀叠加之后，一个词能长到什么程度？

匈牙利语表示所属关系不用介词，也不用单独的物主代词，靠往名词上接后缀。

我的包、你的包、他的包，变的都是那个名词的词尾。

领属后缀还能跟复数、跟格尾继续叠加，一个词接三层后缀是常事。

这些形态在搜索里出现得不算多，因为用户搜商品时很少说这是谁的。

但它们在评论、问答和用户生成内容里到处都是，做内容分析时得能识别出来。

比起土耳其语能挂五层的长链，匈牙利语这三层已经算克制的了。

领属后缀还有单复数之分，也就是说要区分是一个人拥有还是多个人拥有，这一层在客服话术和评价展示里出现得比在商品页多。

领属结构有两种写法，选词表要收哪一种？

表示甲的乙这种关系时，匈牙利语有两种句法结构。

一种是所属者不带任何标记，直接放在前面，被拥有物带领属后缀。

另一种是所属者带一个后缀，语义上更强调所属者本身。

商品名里的复合概念大多走第一种，比如旅行用的包、笔记本电脑的内胆包。

所以选词表只收第一种结构就够，第二种留给正文表达。

这个判断的依据是：第一种结构在书面语里更接近固定搭配，第二种更接近临时组合。

两种结构的检索表现也不同：第一种更容易被当成一个固定短语整体匹配，第二种在分词后会散成两个独立词，做短语匹配时要留意这个差别。

多字母字母是怎么回事？cs、gy、sz各算一个

匈牙利语字母表里有八个由两三个字符组成的字母：cs、dz、dzs、gy、ly、ny、sz、ty、zs。

它们不是两个字母的组合，而是各自独立的一个字母，在字母表里占独立位置。

这意味着sz排序时不排在s和t之间的某个位置，而是排在s全部词条之后。

dzs更极端，三个字符算一个字母，是匈牙利语字母表里最长的那个。

匈牙利科学院的字母排序工具可以直接验证任意两个词的先后关系，配排序规则时拿它对答案最省事。

顺带说一句，土耳其语和芬兰语都没有这个特性，这是匈牙利语在字符处理上最独特的一条。

实际写代码时最稳的做法是维护一张多字母字母表并按最长匹配切分，先试三字符的dzs，再试两字符的，最后才落到单字符。

双写时为什么写成ccs而不是cscs？

当一个多字母字母需要双写时，匈牙利语的正字法规定只重复第一个字符。

所以是ccs而不是cscs，是ggy而不是gygy。

这条规则叫简化写法，写在匈牙利科学院的正字法规则里，当时通行的是第十一版。

做字符串处理时这条会带来一个陷阱：把ccs按字母切分，正确结果是一个cs的双写，不是c加cs。

切错的直接后果是排序位置错、断词位置错、以及词干化时切掉了不该切的部分。

写切分逻辑时要先做一次还原：把双写形态展开回两个完整的多字母字母，再往下处理。

这条简化规则在断词换行时会被还原：一个双写的多字母字母在行末断开时要写回完整形态，前端的断词逻辑如果没实现这一层，渲染出来的换行是错的。

A-Z字母索引在匈牙利语站上会错在哪？

品牌墙、品类字母导航、城市列表这三类页面把排序结果直接印在页面上，错了一眼能看出来。

匈牙利语站上最典型的错误是把sz开头的品牌排到了s开头的品牌中间。

第二典型的是带变音的元音全部跑到了z之后，因为默认排序按字节码走。

第三种更隐蔽：字母导航的按钮只列了二十六个拉丁字母，多字母字母压根没有入口。

正确的按钮列表应该包含cs、gy、ny、sz、zs这些，用户才找得到对应的词条。

做到这一步的匈牙利语站不多，做到了就是一个能被本地用户明确感知到的细节。

还有一个细节值得做：字母导航的按钮上最好把多字母字母用不同的样式标出来，本地用户一眼就能认出这个站是按匈牙利语字母表排的。

排序规则该怎么配才不出错？

排序不能用默认的字节序，要用支持区域设置的排序规则并明确指定匈牙利语。

指定之后多字母字母和变音元音的位置会自动正确，不需要自己写比较函数。

LDML的排序规范里有匈牙利语的完整定义，包括多字母字母和双写形态的处理。

数据库层面也要跟着配，否则应用层排对了、数据库分页取出来的顺序又是错的。

这类前后端排序规则不一致的问题，表现出来是翻页时有的词条重复出现、有的消失。

排查这类问题的第一步永远是确认两侧用的是不是同一套排序规则。

配好之后写一个小测试用例，把几个s和sz开头的词、几个带变音的词打乱丢进去排一遍，升级依赖时跑一次就能发现规则有没有被改掉。

复合词要不要加连字符？六音节规则怎么用

匈牙利语和德语一样喜欢把词粘成复合词，但它多了一条长度上的硬规则。

规则大意是：由三个以上词根组成、且总音节数超过六个的复合词，要在合适的位置加连字符。

三个以下词根的复合词无论多长都不加，六音节以内的也不加。

德语复合词的处理办法我在德语那篇里拆过，那边的问题是怎么切，这边多了一个要不要加符号的问题。

结果是同一个商品概念在页面上可能有加连字符和不加两种写法，取决于写的人有没有数音节。

科学院的断词工具能直接给出某个复合词的正确断法，写商品名时值得随手查一下。

这条规则还有一个例外分支：由两个词根组成但其中一个本身已经是复合词的情况，数法跟直觉不一样，遇到超长词最好还是查工具确认。

连字符加不加，会不会变成两个关键词？

会，而且这个影响比看起来大。

带连字符的形态和不带的形态，在大多数分词器眼里是不同的词串。

用户在搜索框里打字时基本不会打连字符，因为手机键盘上要多一步。

所以真实查询里不带连字符的形态占绝对多数，而你的商品标题按正字法写了连字符。

处理办法是标题按正字法写，同时在商品别名字段里存一份不带连字符的形态供站内搜索使用。

这个做法跟罗马尼亚语处理变音符号是同一个思路：给人看的地方守规范，给机器匹配的地方留变体。

另外提醒一句，连字符在不同输入法下打出来的字符未必是同一个，短横线、连接号、减号在码位上是三个不同的字符，入库前要统一。

变音符号有哪几个，缺哪个最要命？

匈牙利语的元音带变音的有七个：á、é、í、ó、ö、ő、ú、ü、ű。

其中ő和ű是双尖音符，表示长的ö和ü，这两个字符是匈牙利语最独特的标志。

它们在字体支持上是重灾区，很多字体只画了德语那套变音，这两个直接缺字形。

页面上缺字形的表现是显示成方框或者退化成没有符号的形态，两种都很难看。

选网页字体时一定要实测这两个字符，别看厂商标注的语言支持列表。

做封面图、做商品图上的文字、做视频字幕时同理，这两个字符是最先暴露字体问题的地方。

检查字体覆盖时别只看这两个小写字母，大写的对应形态同样要测，全大写标题和导航栏里用得上，而字体缺大写形态的情况一点都不罕见。

长短元音区分意义，打错一个符号会变成另一个词

匈牙利语里长元音和短元音是区别意义的，不是可有可无的装饰。

ö和ő是两个不同的音，换一个词的意思就变了，有些词对差别还挺尴尬。

这一点跟法语的重音符号不太一样，法语里很多重音符号丢了也不影响理解。

匈牙利语丢了长音符号，有一部分词会直接变成另一个存在的词，读者会真的读错。

所以正文一律要打全，这不是规范问题而是语义问题。

用户在搜索框里打不打是另一回事，那属于输入成本，两件事要分开处理。

这也解释了为什么匈牙利语的内容审校不能只交给拼写检查器：拼写检查器只判断这个词存不存在，判断不了你写的是不是你想写的那个词。

用户打不打长音符号？分场景看

桌面端配了匈牙利语键盘布局的用户，长音符号有独立按键，打起来没有额外成本。

移动端的匈牙利语输入法通常也把这几个字符放在长按菜单里，成本是多按一下。

所以匈牙利语的带变音比例比罗马尼亚语要高，这是键盘布局差异带来的。

但输入法的自动纠正会引入另一类噪音：它有时候会把用户打的短元音自动改成长的。

结果是日志里出现一批用户本来没打算搜的词形，做词频统计时要留意这类异常峰值。

判断办法是看这些词形的会话深度，纠错产生的查询通常伴随着立刻的二次搜索。

做日志分析时建议把输入法纠错产生的查询单独打标，它们的转化率通常明显偏低，混在一起统计会把整个品类的转化数据往下拉。

站内搜索该怎么折叠变音符号？

折叠的意思是把带变音和不带变音的形态映射到同一个索引项上。

匈牙利语要折叠的不只是有无变音，还包括长短：ö和ő要折到一起，ü和ű也是。

只折有无变音、不折长短，那用户打了短的却搜不到长的，覆盖还是不完整。

折叠只做在检索层，展示层一律用规范形态，这个分工不能混。

做完之后拿真实日志跑一遍回归，重点看零结果率有没有下降。

这一步在匈牙利语上的收益通常很明显，因为长短元音的组合数量比一般语言多一倍。

折叠规则要跟排序规则分开配，这两件事看着都跟变音符号有关，但目标相反：折叠是为了让不同形态命中同一条，排序是为了让它们各归各位。

词干化在匈牙利语上能做到什么程度？

Snowball的匈牙利语词干算法处理了格尾、复数和常见的领属后缀，这是最容易接上的一层。

它处理不了的是词干本身的变化，也就是前面说的低元音词干和消失元音词干。

所以词干化的合理预期是：解决词尾那一半问题，词干那一半靠数据补。

补的方式是维护一张形态映射表，把不规则词的所有形态都指向同一个词根。

这张表跟同义词表可以合并管理，反正在检索层它们的作用是一样的。

规模上，一个电商品类通常一两百行就够用，别一上来就想覆盖整门语言。

还有一个容易忽略的地方：词干化会把某些短词切得只剩两三个字符，这类残根在匹配时会引入大量噪音，最好设一个最短词根长度的下限。

Hunspell为什么是匈牙利人写出来的？

这件事说起来有点像因果报应：正因为匈牙利语的形态太复杂，才逼出了一个好用的拼写检查方案。

早期的拼写检查器靠穷举词表工作，对匈牙利语这种一个词能派生出几千个形态的语言完全不适用。

于是有人把词根和词缀规则拆开存，用规则去生成和校验形态，这就是Hunspell的词缀压缩思路。

这个方案后来被大量浏览器和办公软件采用，成了开源世界里事实上的拼写检查标准。

对做SEO的人来说，这段历史的实用价值在于：Hunspell的匈牙利语词典文件本身就是一份现成的形态规则库。

它比任何二手教程都完整，而且是机器可读的，直接拿来生成形态变体比手工整理快得多。

从这个词典文件里能直接读出哪些词根属于低元音词干、哪些属于消失元音词干，因为这些信息本来就要编码进词缀规则里才能生成正确形态。

姓名顺序是姓在前，表单和结构化数据要改哪几处？

匈牙利语是欧洲唯一一门日常把姓写在名前面的语言。

这个顺序跟中文一致，跟所有邻国相反，本地人对写反了相当敏感。

要改的地方有四处：注册表单的字段顺序、订单确认页的姓名展示、邮件称呼、以及结构化数据里的姓名字段。

结构化数据那一处最容易漏，因为姓和名是分成两个字段填的，顺序错了机器读出来就是错的。

客服话术也要跟着调，用姓加先生女士的组合称呼，别照搬英文的名加姓。

这一条不影响排名，但它是本地用户判断一个站是不是认真做本地化的第一个信号。

还有一个细节：匈牙利语的女性婚后姓氏有几种传统写法，注册表单如果强制拆成姓和名两个字段，有一部分用户会填不进去，字段设计要留出余地。

日期格式为什么末尾还有一个点？

匈牙利语的日期是年月日顺序，这一点跟中文一样，跟大多数欧洲国家相反。

更特别的是每一段后面都有一个点，包括最后那个日期数字后面。

写成2013. 07. 23. 才是规范写法，末尾那个点不是打字错误。

原因在语法里：这个点标记的是序数词，日期在匈牙利语里读作第几日。

日历组件、发货时效、促销倒计时这些地方按默认格式渲染，出来的都是不地道的写法。

星期从周一开始，这一点跟大多数欧洲市场一致，不用额外调。

序数词后面加点这条规则不只用在日期上，排行榜、楼层、章节编号这些地方同样适用，页面上凡是出现第几的地方都该检查一遍。

地址与邮编字段该怎么排？

匈牙利地址的顺序是邮编、城市、街道、门牌，跟中文的从大到小一致。

邮编是四位数字，比很多欧洲国家短，表单校验的位数别照抄邻国。

门牌号写在街道名之后，这一点跟德语区一致，跟英语区相反。

街道类型的词是写在街道名后面的，比如某某街的街字在后面。

地址表单如果只提供一个自由文本框，用户会按本地习惯填，问题不大。

拆成结构化字段的时候才要小心，字段顺序和标签措辞都要按本地习惯排。

邮编四位这一条还有个衍生影响：如果你的地址库是从欧洲通用数据源导入的，很可能会被补成五位，导入时要专门校验位数。

数字、货币与小数点该怎么写？

货币是福林，代码HUF，日常写作Ft，符号写在数字后面。

福林的面额数字很大，日常商品价格动辄五位数，这会影响价格筛选器的区间设计。

小数点用逗号，千分位用空格而不是点，这一点跟不少欧洲国家不同。

而且福林在日常交易里基本不用小数，标价通常是整数。

把英文站的价格格式直接搬过来，会同时错在分隔符和小数位两个地方。

价格区间筛选器的默认档位也要按本地价位重设，照搬欧元区的档位会让所有商品挤在同一档。

千分位用空格这条要注意用哪种空格，普通空格会在换行时把数字拆成两半，正确做法是用不换行空格，否则价格显示会莫名其妙地断行。

后置词跟格是什么关系，关键词里算几个词？

十八个格之外，匈牙利语还有一大批后置词，语义上相当于其他语言的介词。

区别在于它们写成独立的词，放在名词后面，而格尾是粘在名词上的。

所以同一个语义关系，有的用格表达算一个词，有的用后置词表达算两个词。

做关键词长度统计和竞价词匹配时，这个差别会直接改变词的分组结果。

选词表建议把带后置词的短语单独列一类，别跟格形态混在一张表里。

它们的检索行为也不一样：后置词短语更接近自然语言问句，格形态更接近商品名。

后置词还有一个特点：它们大多要求前面的名词带某个特定的格，所以后置词短语其实是格加词的组合，统计词长时按两个词算但语义上是一个单元。

动词前缀会被拆开，长尾查询里怎么找？

匈牙利语的动词有一批可分离前缀，平时粘在动词前面，某些句式里会被拆到动词后面去。

拆开之后中间还能插进别的词，一个动词的两半可能隔着两三个词。

这对长尾查询的匹配是个不小的麻烦，因为字符串上看不出这两半是一个词。

问句型查询里这种拆分特别常见，尤其是带否定和带疑问词的句子。

处理办法是在做查询意图分类时把前缀单独识别出来，别当成独立的词处理。

德语的可分离动词有类似的现象，但匈牙利语的拆分频率更高，规则也更依赖语序。

内容侧可以主动利用这一点：把带前缀的完整形态和拆开的形态各写进一段自然的句子里，长尾覆盖会比只写一种明显宽一些。

标题模板在匈牙利语上要留几个变量？

商品标题一律用主格形态，这是最接近检索形态的写法。

形容词在匈牙利语里放在名词前面，而且做定语时不跟着名词变数和格。

这一点比罗马尼亚语和意大利语省事太多，形容词字典只需要存一个形态。

真正要留变量的是复合词的连字符：模板要能根据词根数和音节数判断加不加。

音节数的计算按元音个数来，匈牙利语的音节结构规整，这个判断可以自动做。

加上主格形态和变音符号写全这两条，四条规则就能覆盖标题模板的绝大部分需求。

形容词不变形这条省下来的力气，建议花到连字符判断上去，那才是匈牙利语标题模板里唯一需要真逻辑的部分。

面包屑与筛选器该用哪个格？

面包屑里的分类名用主格复数，这是列表页的自然形态。

筛选器的选项标签也用主格，因为它们要跟后台的属性值对齐。

页面H1可以用带格尾的自然句式，读起来更像人写的。

筛选结果的提示语里会出现位置格，比如在某个分类里找到多少件商品。

这句提示语的模板要按格来拼，直接把主格塞进去语法上是错的。

这类小文案的语法质量，是本地用户判断站点是不是机器翻译的重要依据。

这类提示语的模板最好按格拆成几个变体存起来，别在代码里做字符串拼接，因为格尾的选择还要受元音和谐影响，拼接逻辑很快会失控。

URL该保留变音字符还是脱掉？

匈牙利语的主流做法是脱到基本拉丁字母。

á变a，é变e，ö和ő都变o，ü和ű都变u。

注意ő和ö脱完是同一个字符，所以两个不同的词可能脱出同一个slug。

这种撞车在匈牙利语上比在其他语言里常见得多，因为长短元音的对立太普遍。

slug生成器要加一层撞车检测，撞了就加品类前缀或者数字后缀消歧。

域名后缀用hu，这个后缀1990年就完成了委派，是本地信任度最高的选项。

撞车检测最好在建站初期就加上，等到几万条URL都生成完再去处理，改动就会牵扯到重定向和已经积累的外部链接。

锚文本要准备几个变体？

内链的锚文本嵌在句子里，句子要求什么格，锚就得用什么格。

每个目标页准备三到四个变体，覆盖主格、宾格和一两个位置格就够。

变体之间的词根保持一致，变的只是词尾，这样主题信号不会被稀释。

匈牙利语在这里有个优势：形容词做定语不变形，所以带形容词的锚文本变体比屈折语少一半。

检查锚文本质量可以导出所有指向同一页面的锚，看词根是不是一致、词尾是不是有变化。

词尾全都一样反而是个坏信号，说明有人在硬塞固定锚文本。

顺带一提，匈牙利语的锚文本写起来比屈折语舒服的地方还在于语序灵活，同一个词根可以放在句子的不同位置，读起来不会僵硬。

元描述的字符预算怎么算？

匈牙利语的词平均比英语长，因为语法信息全靠往词尾接。

同样一句话的匈牙利语版本，字符数经常比英语多出两三成。

所以按英语稿的长度翻译，出来的元描述十有八九会被截断。

正确做法是按目标语言的字符数控制，把核心信息压在前面。

标题同理，复合词在匈牙利语里很长，写完先量一遍再决定要不要拆。

移动端商品卡片的两行截断更要拿真机看，模拟器的字体度量跟真机对不上。

还有一个跟长度有关的地方是面包屑：匈牙利语的分类名普遍偏长，多级面包屑在移动端很容易折行，层级设计时要比英文站保守一档。

机器翻译在匈牙利语上最常犯哪几类错？

第一类是元音和谐选错后缀变体，尤其是圆唇那一维。

第二类是定动词和不定动词用反，宾语明明是确定的却用了不定形态。

第三类是复合词该加连字符的地方不加，或者不该加的地方乱加。

第四类是姓名顺序，翻译引擎会把匈牙利语的姓名按英语顺序重排。

前三类是语法问题，本地用户读得出来但不一定说得清哪里怪。

第四类是最容易被投诉的，因为它把人的名字写错了，这在任何文化里都不礼貌。

第五类不算语法错但同样致命：机器翻译会把国际通行的技术词直接音译过来，而匈牙利语在这类概念上往往有一个大家都在用的本地词。

母语审校清单该列哪几条？

后缀的元音和谐是不是对，尤其检查前元音词根后面的三型后缀。

动词形态跟宾语的确定性是不是匹配。

复合词的连字符是不是按音节数规则加的。

长音符号是不是全部打全，尤其是ő和ű。

姓名顺序、日期格式、价格分隔符是不是本地写法。

最后一条老规矩：让审校的人念一遍，念着卡壳的地方一定有问题。

审校人选上建议避开纯语言学背景，找有电商或者广告文案经验的，前者容易把口语词全改成书面词，改完语法完美但没人这么搜。

引擎那一半的功课为什么不在这篇里？

这篇从头到尾讲的是语言本身：格、后缀、字母、字符、格式。

某个搜索引擎在匈牙利市场怎么排名，那是引擎层的题，跟这门语言的语法没有关系。

多语言站要按国家还是按语言分域名，那是架构层的题，同样不在这里。

把三层混在一篇里写，结果通常是每一层都只讲了个开头。

分开的好处是排查问题时路径清晰：流量掉了先判断是词形没覆盖，还是地区定向出了问题。

这两条路的排查动作完全不同，混在一起只会互相干扰。

这种分层还有一个好处：语言层的结论能跨引擎复用，而引擎层的结论过几年就会过时，两者放在一起写会让整篇文章的保鲜期跟着短的那一半走。

一个箱包站从零开始，推荐什么顺序？

第一步测字体，确认ő和ű在你的字体栈里有字形。

第二步建属性字典，标注低元音词干和消失元音词干这两个布尔字段。

第三步查词典补齐核心词在五六个高频格上的形态。

第四步配排序规则，把多字母字母和变音元音排对。

第五步改标题模板，加上连字符判断和主格约束。

第六步配站内搜索的变音折叠与词干化，最后才是内容规划。

这六步里唯一能并行的是第一步和第二步，其余必须串行，尤其排序规则要在字典建好之后配，否则没有足够的真实词条去验证配得对不对。

做完之后最先看到哪个指标动？

字母索引和排序改完，最先动的是这几类页面的跳出率。

站内搜索配完，零结果率通常一两周内就有明显下降。

标题模板改完，商品页的展现量会跟着起来，因为终于用对了检索形态。

长尾流量要等内容规划落地，周期最长。

字体那一步的收益不在报表里，它防的是用户看到方框之后直接关掉页面。

保哥见过一个站因为字体缺ő，整个品类名在移动端全是方框，跳出率高得像被攻击了。

如果只能做一件事，那就做字体测试加变音折叠这两项的组合，它们加起来不到一天工时，却挡住了匈牙利语上最容易发生的两类流失。

常见问题解答

匈牙利语的十八个格，做SEO是不是全都要覆盖？

不需要。十八这个数字本身在语言学上就有争议，不同体系数出来从十七到二十七都有，而真正会出现在商品类查询里的通常只有四到六个：主格、宾格、表示在里面的、到里面去的、从里面出来的，再加一个表示用途的。其余的格要么只出现在完整句子里，要么语义太具体，用户不会拿它搜商品。选词表按这五六个格铺，每个核心词五六行就够，一个品类三五十个核心词，规模完全可控。把力气花在这里，比背下全部词尾有用得多。还有一个现实考虑：格的形态越冷僻，搜索量越低，为它们单独准备内容的边际收益迅速趋近于零，把这份预算挪去做本地词对照表回报明显更高。

既然都是黏着语，土耳其语那套后缀处理方法能不能直接搬到匈牙利语上？

不能。共性只有一条：语法信息靠往词尾接后缀。差别有四条，每一条都会让方案失效。格的数量从六个变成十八个；土耳其语的难点是后缀链能挂五层，匈牙利语的链要短得多，格尾几乎总在最外层；匈牙利语有定冠词而土耳其语没有，而且这个冠词还会往回改动词的词尾；最后是字母表，匈牙利语有八个多字母字母，排序和切分逻辑必须重写。搬过来的顶多是黏着语这个思维方式，具体规则一条都不能复用。如果一定要找一条能复用的，那就是选词表按形态铺开这个结构本身，但表里每一列的定义都得按匈牙利语重写一遍。

匈牙利语跟芬兰语是亲戚，能不能共用一套处理方案？

能共用的只有思路，不是方案。两门语言分家太早，词汇上几乎没有可辨认的对应关系。技术上的主要差别有三处：芬兰语的词干靠辅音级差变化，匈牙利语没有级差但有末元音延长和消失元音；芬兰语的元音和谐只有前后一维，匈牙利语多一维圆唇；芬兰语没有冠词，匈牙利语有而且影响动词变位。共用的部分是方法论层面的：都要按格铺选词表，都要接词干化，都要处理词干本身的不规则变化。还有一处实操差别：芬兰语的高频格分布分散，选词表要铺得宽；匈牙利语相对集中，可以铺得窄而深，两者的预算分配方式并不一样。

ő和ű这两个字符经常显示成方框，怎么办？

先测字体，别信厂商标注的语言支持列表。做法是把这两个字符跟对应的ö和ü排在一起渲染一张图，肉眼看有没有缺字形。网页字体、商品图上的文字、视频字幕、封面图这几处都要单独测，它们用的字体往往不是同一套。如果主字体缺，可以配一个覆盖完整的备选字体放在字体栈后面。这一步的成本是十分钟，不做的代价是本地用户看到一片方框直接关掉页面。顺带提醒，大写形态同样要测，全大写的标题和导航栏用得上，而字体只画了小写变音形态的情况一点都不罕见。

复合词的连字符到底加还是不加，有没有简单判断法？

有一条能覆盖大部分情况的判断：数词根个数和音节数。三个以上词根组成、且总音节数超过六个的复合词才加连字符，其余不加。音节数按元音个数算，匈牙利语的音节结构规整，这个判断可以自动化。拿不准的词可以用科学院的断词工具查一下，它会直接给出正确断法。实操上建议标题按正字法写连字符，同时在商品别名字段里存一份不带连字符的形态给站内搜索用，因为用户在手机上基本不会打连字符。还有一个跟连字符有关的坑：不同输入法打出来的横线在码位上可能是三个不同字符，入库前要统一，否则同一个词会分裂成好几条。

定冠词影响动词变位这件事，对关键词研究的实际影响有多大？

影响集中在问句型和长尾查询上，商品名类的短查询几乎不受影响。因为动词只在完整句式里出现，而商品名查询大多是名词短语。所以处理优先级不算最高，但也不能不做：同一个意图的问句会以两种动词形态出现在日志里，只铺一种就漏掉一半。落地做法有两条，一是在正文和FAQ里让两种句式各自然出现一次，二是在站内搜索的同义词表里把两种动词形态映射到一起。做完之后长尾查询的零结果率会有可见的下降。另外这个形态还能当意图信号用：走确定形态的查询往往指向具体某件商品，走不确定形态的更偏品类浏览，两者该落到的页面类型不一样。

匈牙利语的姓名顺序真的需要专门处理吗？

需要，而且要改的地方比想象中多。匈牙利语是欧洲唯一日常把姓写在名前面的语言，跟中文一致、跟所有邻国相反。要改四处：注册表单的字段顺序、订单页的姓名展示、邮件与客服的称呼、结构化数据里的姓名字段。最容易漏的是最后一处，因为姓名是分成两个字段填的，顺序错了机器读出来就是错的。这条不影响排名，但它是本地用户判断你有没有认真做本地化的第一个信号，而且把人名字写错在哪个文化里都不礼貌。实现上有个小建议：数据库里存姓和名两个独立字段，展示顺序交给模板控制，这样以后要支持其他市场时不用改数据结构。

权威参考资料