土耳其语SEO选词，一个词后面挂上五层后缀，出来的就不再是你选的那个词

摘要：土耳其语把语法信息全塞进后缀里，一个词根后面能接上五六层，每接一层意思就变一次，而每一层后缀本身还有两到四种写法，得看前面的元音是哪一类。结果是同一个概念在搜索框里能长出几十种形态，词表按传统方法根本做不完。更凶的是那个点i和无点ı的问题，一次不带地区设定的大小写转换，就能把地址、去重、登录、排序一起搞坏。这篇按语言机制拆：后缀怎么叠、元音和谐怎么分叉、名词组合为什么改写了核心词、词根该怎么当选词单位，还有那套只有土耳其语才会踩的技术雷。

先说一个让人哭笑不得的开局。一家做汽车配件的独立站，雨刷、机油滤清器、刹车片这一类，欧洲几个市场跑得不错，看土耳其汽车保有量大、后市场活跃，决定开一个土耳其语版本。

上线之后收录很快，但有个现象很怪：品牌词的排名没问题，品类词几乎全军覆没。团队第一反应是竞争太激烈，加了一批内容，还是没动静。

真正的原因是词写错了。站上分类页写的是silecek，词典里雨刷就是这个词。但土耳其人搜的是cam sileceği——挡风玻璃雨刷，两个名词组合在一起时，后面那个词必须带上一个后缀，词尾也跟着变了形。

silecek和sileceği，在人眼里是同一个东西，在搜索里是两个词。而站上那个写法，恰好是没人用的那一个。

黏着语到底把一个词变得多长？

黏着的意思是：语法信息不靠变词根，也不靠单独的虚词，全靠往后面粘后缀，一层接一层，每层管一件事。

拿ev（房子）走一遍：

六个形态，英语得用六个词组才能表达。土耳其语里它们是六个单词，而且在搜索框里就是六个不同的字符串。

土耳其人自己拿这个特点开玩笑，编过一个几十个字母长的单词，意思大概是像你们这些没能被我们捷克斯洛伐克化的人当中的一员似的。那个词当然没人真用，但它说明了一件事：这门语言的构词没有硬性长度上限。

后缀的顺序是固定的

好消息是后缀不能乱排。名词后面的顺序基本是固定的：先复数，再领属，最后是格。动词那边更复杂，但同样有严格顺序。

这意味着你可以用程序穷举组合，不必逐个手工列。做词表时按这个顺序生成候选，再拿真实数据筛一遍，效率比人工高得多。

元音和谐：同一个后缀有两种或四种写法

坏消息在这里。土耳其语的元音分成两组，后缀里的元音必须跟词根最后一个元音同组，于是同一个后缀会有两种或四种拼法。

• 复数后缀有两种：一种配后元音的词，一种配前元音的词
• 领属和很多格后缀有四种，因为除了前后还要分圆唇不圆唇
• 选哪一种完全由前面的元音决定，规则明确，但机器要是不实现这套规则，拼出来就是错的

举个直观的例子：房子的复数是evler，路的复数是yollar，同一个复数后缀，因为词根元音不同，写法就不同。

把这一条和后缀叠加放在一起看，组合爆炸就来了：五层后缀，每层两到四种写法，理论组合数是三位数起步。当然实际用到的是其中很小一部分，但足以让你按传统方法穷举词表的想法破产。

辅音交替：词根本身也会变

还没完。土耳其语里有几个辅音，词根末尾碰上以元音开头的后缀时会软化：p变b、ç变c、t变d、k变ğ。

书是kitap，加宾格后缀之后变成kitabı，词根最后那个字母变了。颜色是renk，加上后缀变成rengi。这类变化意味着你不能靠简单的字符串前缀匹配去归并词形——词根的最后一个字母都不一样了。

反方向也有：某些后缀跟在清辅音后面时，自己的第一个字母要变清音。在书里面写成kitapta而不是kitapda。

名词组合，为什么改写了你的核心词？

这是本文最值钱的一节，也是开头那家配件站栽的那个坑。

土耳其语里两个名词组成一个复合概念时，后面那个名词必须带一个后缀，表示前后是从属关系。这不是可选的修饰，是这门语言的基本构词方式。

看第一行和第四行，后面那个词不只是加了后缀，词根末尾的字母也软化了：silecek变sileceği，lastik变lastiği。两条规则叠在一起生效。

这对选词的影响是决定性的：你的分类页标题如果写的是光秃秃的词根，那就是一个本地人不会用来搜的写法。土耳其语的品类词，绝大多数在真实查询里是以组合形态出现的。

实操上有个简单的检验法：把你的品类词逐个丢进搜索框，看下拉建议给出的是哪种形态。如果建议里全是带后缀的组合形式，那你的页面标题就该跟着改。这一步十分钟能做完，能救回整个品类。

关键词研究该以什么为单位？

答案是以词根为单位建词表，把后缀当成意图标记。这个思路跟屈折语那边有相通之处，但土耳其语要更彻底一些。

屈折语里，格变化主要影响词的语法角色。土耳其语里，后缀承载的信息更丰富，很多后缀直接就是用户意图的信号。

哪些后缀是意图信号？

• 复数后缀：用户在找一批东西，多半是列表意图，该配分类页
• 位格（在里面）：出现场景或地点，常见于本地化查询和使用场景类内容
• 从格（从里面）：常出现在材质、来源、比较类查询里
• 带有的后缀：表示具备某个特性，是筛选属性的天然对应，比如带某种功能的产品
• 不带的后缀：表示不含某成分，在食品、化妆品、配件类目里量很大
• 转成名词的后缀：把动词或形容词变成名词，往往对应一个独立的品类概念

把这些后缀跟词根交叉，就能推出一整片有明确意图的长尾，而且每一条都能对应到具体的页面类型。这比拿词根去凑修饰词高效得多，因为后缀是这门语言里意图的原生表达。

俄语那边用格来承载类似信息，方法论可以互相参考。俄语六个格与词形合并的处理办法那篇讲的合并思路在这里同样成立，区别在于土耳其语的后缀可以叠加，组合数量比俄语大一个量级，更依赖程序生成加真实数据筛选。

点i和无点ı，为什么能把整个站搞崩？

这是土耳其语独有的、也是杀伤力最大的一个技术雷。它跟内容质量、跟翻译水平都没关系，纯粹是代码写法的问题。

土耳其语字母表里有两个i：一个带点，一个不带点。它们是两个不同的字母，读音不同，意思也不同。带点的小写是i，大写是İ；不带点的小写是ı，大写是I。

问题出在反向转换上。按通用规则，大写I的小写是i；按土耳其语规则，大写I的小写是ı。同一段代码，在不同的地区设定下会给出不同的结果。

按语言区域做小写转换的接口说明里专门把土耳其语列为需要特殊处理的例子，这不是边缘情况，是被标准明确记录过的已知差异。

会在哪些位置出事？

1. 地址生成。标题转成地址时通常要先小写，如果服务器的地区设定是土耳其语，标题里的I会变成ı，生成出来的地址跟你预期的不一样，而且同一个标题在不同环境下生成的地址还可能不同。
2. 登录与去重。邮箱地址做小写归一时，带I的邮箱在土耳其语设定下会被转成带ı的形态，跟注册时存的对不上，用户直接登不进去。
3. 字符串比较。做不区分大小写的比较时，两个本该相等的字符串被判成不等，或者反过来。
4. 站内搜索。查询和索引如果在不同环节用了不同的地区设定，匹配率会莫名其妙地下降，而且极难排查。
5. 配置与标识符。程序里的配置项名称、模板标签、类名如果走了小写处理，在土耳其语环境下会变成另一个字符串，直接报找不到。

处理原则很简单，但必须写进规范：面向用户展示的文本，按土耳其语规则转；程序内部的标识符、地址、邮箱、配置项，一律用不带地区设定的固定规则转。两条路分开走，别混用。

大小写映射里的语言相关规则说明把这类差异整理得很清楚，做技术方案时值得让工程团队完整读一遍，比出事之后再排查便宜太多。

土耳其字符在老系统里会怎么变形？

土耳其语的专属字母有六个：ç、ğ、ı、ö、ş、ü，加上大写的İ。在统一编码普及之前，本地系统用的是专门的单字节编码方案。

这段历史留下的痕迹，今天做站还会撞上：

• 批量导入：表格文件按老编码存，导进来ş和ğ全变问号
• 短信通知：短信通道对非基础拉丁字符的支持参差不齐，土耳其字符经常被替换成近似字母，或者让单条短信的字数上限直接砍半
• 物流面单：收件人姓名里的ğ被吃掉，快递员看到的是个残缺的名字
• 发票系统：财务系统往往最老，也最容易在这里出问题
• 字体子集：网页字体按拉丁基本字符集裁剪，ğ和ş掉回系统默认字体，一行字里几个字母长得不一样

老规矩，端到端测一遍。造一条姓名和地址里塞满六个土耳其字符的测试数据，从下单一路走到短信通知、物流面单、发票，看它在哪一环变了形。一小时的事，能省掉后面无数次客服工单。

地址里的ş和ğ该怎么处理？

建议路径部分做拉丁化，映射规则写死：ç变c、ğ变g、ı变i、ö变o、ş变s、ü变u，大写的İ按小写的i处理。

注意最后这一条正是前面那个雷的延伸——拉丁化必须用固定规则，不能依赖运行环境的地区设定。同一个标题在不同机器上生成出不同的地址，是这门语言里最容易发生也最难查的事故之一。

另外，带土耳其字符的地址在传输时会被编码成一串百分号，这个机制本身没问题，但会让地址变得没法看也没法口述。地址里的百分号编码到底是怎么回事那篇把编码与还原的过程讲得比较细，理解了机制，就不会写出互相打架的两套规则。

还有一条铁律照旧：地址一旦发布就不要再改。土耳其语的形态那么多，很容易让人产生换个写法更贴合搜索的冲动，忍住，改地址的损失远大于形态优化的收益。

站内搜索为什么在土耳其语站上匹配率特别低？

三个原因叠在一起：后缀让用户输入的形态跟你库里存的不一样；元音和谐让同一个后缀有多种拼法；辅音交替让词根本身都变了形。

结果就是按字符串匹配的搜索几乎不可用。用户搜cam sileceği，库里存的是silecek，前缀都对不上。

解法从便宜到贵排三层：

土耳其语词干还原算法的完整说明把它处理的后缀类型和边界条件列得很细，选型时先读一遍，能判断出你的品类词会不会被它误伤。

顺带提醒一句：土耳其语的词干还原比大多数语言难，因为后缀能叠加，剥离的层数不好把握，剥多了会把不同的词归并到一起。上线后一定要抽查一批高频词的还原结果，别直接信默认配置。

用户不打专属字符怎么办？

跟波兰语那边一样，相当一部分用户在搜索时会用基础拉丁字母代替，把ş打成s、ğ打成g、ı和i不分。手机上尤其明显。

处理原则也一样：可见文本一律用规范写法，容错留给自己的系统。页面上把ş写成s，本地人看起来就是错别字，信任成本远高于那点搜索收益。

需要做的是三件事：站内搜索做字符归一；筛选器跟着一起改，别只改搜索；地址走固定规则的拉丁化。搜索引擎那一侧对土耳其语的字符容错已经不错，不需要你为它单独造无变音版本的页面。

这套判断在波兰语的九个变音字母该怎么处理那篇里也是同一个结论。变音字母多的语言，坑的形状高度相似，方法可以直接搬。

字母顺序跟你想的不一样

土耳其语字母表二十九个字母，没有q、w、x，多了六个专属字母，而且它们在字母表里有固定位置：ç紧跟在c后面，ğ紧跟在g后面，ı排在i前面，ö跟在o后面，ş跟在s后面，ü跟在u后面。

注意ı排在i前面，这跟按码位排序的结果正好相反。用通用排序规则排出来的品牌列表、属性列表、字母索引，在本地人眼里就是乱的。

解决办法是建库时把排序规则定成支持土耳其语的那一套。至于字母索引导航，建议跟波兰语一样，不给专属字母单开格子，用户找ş开头的词习惯去s那一格。

语序是主宾谓，标题该怎么写？

土耳其语的基本语序是主语、宾语、谓语，动词在最后。修饰成分也一律放在被修饰词前面。

这对标题的影响是实打实的：如果你的标题模板是照着英语的语序拼的，土耳其语版本读起来会非常别扭，本地人一眼看出是翻译腔。

几条实用建议：

• 核心品类词尽量靠前，但要用它在真实查询里的组合形态，不是词根
• 不要在标题里硬拼动词，土耳其语的动词在句末，硬塞到中间会很怪
• 属性作为独立标签甩在后面，用分隔符隔开，既避开语序问题也避开一致问题
• 注意长度，土耳其语的词因为后缀而更长，搜索结果里能显示的字符有限，后半截被切掉的概率高

日语那边也是动词在最后的语序，处理标题时的思路可以互相印证。日语的三套文字与表记选择那篇里讲的标题结构原则，在土耳其语这边同样适用，尤其是把核心词前置、把修饰甩到后面这一条。

土耳其语的意图词，哪些必须收进词表？

注意fiyat和fiyatları这一对。前者是价格，后者是带复数和领属后缀的形态，意思接近某某的价格们。后者在真实查询里的量往往更大，因为用户搜的是某个具体品类的价格，那个组合天然要带后缀。

还要留意yorum。土耳其用户对评价内容的依赖程度很高，几乎每个品类都有可观的评价类查询。如果你的商品页上没有真实评价，这部分流量接不住也留不下。

分期付款为什么是绕不过去的一项？

这一节不属于语言层，但不讲会误事。土耳其的线上消费里，信用卡分期是极其普遍的付款方式，普遍到用户会把分期能力当成筛选条件之一。

体现在搜索上，就是分期这个词经常直接出现在查询里。体现在页面上，就是产品页必须把可分几期、每期多少写清楚，写在价格旁边而不是藏在结算页。

这件事对跨境卖家不太友好，因为分期通常依赖本地收单机构。但至少有两件事可以做：一是把当前支持的支付方式在页面上说清楚，别让用户到最后一步才发现；二是如果确实提供不了分期，就在价格策略和运费上找补，把总价的确定性做足。

域名那道门槛怎么绕？

土耳其的国家域名后缀有个出了名的特点：商业二级域的注册需要提交商标或者营业执照之类的证明材料，不是填个表就能拿到的。

对大多数跨境卖家来说，这意味着走本地后缀的成本比别的市场高不少。现实的选择是用国际通用后缀，把本地信号放在别的地方补：本地地址、本地客服电话、本地支付方式、本地物流合作方。

这些信号加起来的效果，未必比一个本地后缀差。至于用什么域名结构承载多语言站点，那是架构层的题目，跟语种本身无关，不在这里展开。

倒是有一件跟语言直接相关的事要提醒：域名里能不能用土耳其语的专属字符。技术上可以，但强烈建议别用。原因跟前面地址那一节一样——那六个字符里有几个在传输和显示环节的处理链路很长，任何一环出岔子都会让域名变得没法复制、没法口述、没法印在包装上。国际市场上通行的做法是域名只用基础拉丁字母，本地特色留给内容去表达。

还有一个容易被忽视的细节：域名如果包含无点的那个字母，跟带点的那个在视觉上极易混淆，这既是用户体验问题，也可能被人拿去做仿冒。选域名的时候把这两个字母的组合直接排除掉，省心。

机器翻译在土耳其语上最容易犯什么错？

三类错误有明显模式，认出来就能快速筛查。

第一类是后缀接错。元音和谐选错组、辅音交替没处理、后缀顺序颠倒，这三种在长句里出现频率很高。本地人读起来是一种说不上哪里不对但就是别扭的感觉。

第二类是名词组合没加后缀。也就是开头那家配件站踩的坑，翻译引擎经常把两个名词直接并排放，缺了那个表示从属关系的后缀。这是最影响搜索的一类错误。

第三类是语序照搬。把动词放在句子中间，或者把修饰成分放到被修饰词后面。整段读下来节奏是错的。

筛查方法：让审校专门盯这三类，不要求逐句润色。审校成本能降一大截，抓住的问题反而更集中。

品牌名后面那个撇号，到底要不要写？

土耳其语里专有名词加后缀时，习惯用一个撇号把词干和后缀隔开。品牌名、地名、型号在句子里当名词用，就会遇到这个规则。

对做搜索的人来说，这条规则带来三个实际问题。

第一，同一个查询有带撇号和不带撇号两种写法。用户打字时经常省掉撇号，尤其在手机上。两种写法在字符串层面完全不同，站内搜索如果不做归一，就会漏掉一半。

第二，撇号本身有好几个长得几乎一样的字符。直排的那个、弯的那个、还有输入法自动替换出来的那个，视觉上难分辨，字节上是不同的字符。用户从别处复制粘贴过来的查询，用的可能是任意一种。

第三，后缀的形态取决于品牌名怎么读，而不是怎么拼。外来品牌名尤其麻烦，本地人按发音选后缀的元音，可同一个名字不同的人读法可能不一样，于是市面上会同时流传两种写法。

处理建议是这样的：

• 页面上的正式写法带撇号，用直排的那一个，全站统一，这是规范用法
• 站内搜索做撇号归一，把所有变体和缺失的情况都映射到同一个目标
• 地址里一律去掉撇号，跟着拉丁化规则一起处理
• 后缀形态官方定一种，用在所有正式场合，同时确保页面上最流行的那种民间写法也自然出现过一次
• 型号不加后缀，带数字和字母的组合一律保持原样，加后缀会切断跟国际数据源的匹配

第四条的道理跟品牌名转写是一样的：你不主动定一个标准写法，市场会自己叫出一个来，等叫开了再改就是跟用户习惯作对。

内链的锚文本，后缀该怎么带？

跟屈折语一样，土耳其语的锚文本在句子里必须跟着语法环境带后缀，硬塞词根会造出病句。

但土耳其语这边多一层麻烦：品类词在真实查询里本来就是带从属后缀的组合形态，而在句子里它还要再加格后缀。两层叠加之后，锚文本跟你想强调的那个核心形态可能已经差得比较远了。

保哥的处理办法是分工：锚文本服从句子，周围的文字负责精确。锚用自然的形态，紧挨着的那句话里把标准组合形态自然地提一次。这样读起来通顺，语义也完整。

还有两个细节值得注意。一是别把整句话做成锚，锚应该落在具体的名词短语上；二是同一个目标页在全站的锚文本不必强求一致，随上下文自然变化反而更像人写的。

问句型查询在土耳其语里长什么样？

问句型查询在土耳其语里的比例很高，而且它有一个别的语言没有的特点：疑问本身也可以后缀化。

是非问句靠一个疑问小品词构成，那个小品词跟着元音和谐变形，写成四种形态之一，位置在被问的成分后面。这意味着一个是非问句在搜索里可能有好几种拼法，而它们表达的是同一个问题。

常用的疑问词值得单独整理成一张表，它们直接对应内容形态：

• nasıl：怎么做，对应操作教程与安装步骤，量最大的一类
• nedir：是什么，对应术语解释与品类科普
• ne kadar与kaç para：多少钱，对应价格与报价内容
• hangisi：哪一个，对应对比与选购指南
• neden：为什么，对应原理与故障排查
• ne işe yarar：有什么用，对应功能说明，在配件类目里量很大

把这几个词跟你的品类词交叉，能一次性铺出几十条真实存在的长尾。注意一点：交叉时品类词要用组合形态，不是词根，否则拼出来的查询本地人不会那么打。

做常见问题模块时还有个小技巧：问题标题直接用用户的问法，答案第一句给一个干脆的判断。土耳其语的问句结构比较固定，照着用户的问法写，命中率明显更高。

称呼用sen还是siz，影响转化吗？

影响，而且比想象中大。土耳其语的第二人称有两个：一个用于熟人和平辈，一个既是复数也是敬称。

商业内容的默认选择是敬称那一个，几乎所有正规的本地零售站都这么写。用熟人称呼的站不是没有，但集中在面向年轻人的时尚、潮流类品牌，而且是有意为之的品牌调性选择，不是随便定的。

问题在于翻译环节很容易混用。同一个站里，商品页用敬称，弹窗提示用熟人称呼，邮件模板又换回敬称，读者会觉得这个品牌人格分裂。

建议在本地化开始之前就把这一条定死写进文档，并且明确告诉所有译者和审校。这是个零成本的决定，但事后统一的代价很高——因为称呼变了，跟在后面的动词形态也要跟着变，不是全局替换一个词就能改完的。

后缀让词变长，界面会被撑成什么样？

土耳其语的单词因为后缀叠加而偏长，同一句话的字符数通常比英语多出两成上下，个别短标签能翻倍。这在界面上会集中爆发。

最后一行值得展开一句。短信通道对非基础拉丁字符的支持方式，会直接影响单条短信能装多少字。土耳其语的文案里必然带专属字符，如果模板是按英语字数设计的，实际发出去会变成多条，成本翻倍不说，断句位置也可能很难看。

处理办法不是逼译者压字数，压出来的文案通常很生硬。更好的路径是让模板本身有弹性，同时把关键信息前置——反正后半截随时可能被切掉，那就别把重要的东西放在后面。

数字、日期和价格该怎么写？

这类格式写错不影响功能，但会持续消耗信任，本地人扫一眼就知道这站不是本地做的。

• 小数用逗号，千位用点，一千二百三十四点五写成1.234,5
• 货币符号后置，写在数字后面
• 日期是日在前，用点分隔
• 电话号码有固定的分组习惯，占位符要按本地格式写，别照搬英语模板
• 尺寸与单位用公制，数字与单位之间的写法要全站统一

价格这一项在土耳其市场还有个额外要求：把分期后的每期金额也显示出来。前面讲过分期是这个市场的基本预期，只写总价的产品页，在转化上会明显吃亏。

母语审校该怎么验收？

1. 先给词表。核心品类词、品牌名、型号列成一张表随稿交付，并且注明哪些词不许改
2. 明确组合形态。告诉审校品类词在标题里要用真实查询里的组合形态，不是词典原形
3. 专项检查后缀。让审校单独扫一遍元音和谐与辅音交替，这两类母语者最敏感
4. 检查语序。整段读一遍，凡是读着像翻译的地方标出来
5. 回搜验证。改动过的核心词丢回搜索框，确认改后的写法确实有人用

保哥的经验是第五条永远是最后一道闸。语法完美但没人搜的词，对搜索来说是负资产，这条在每门语言里都成立。

上线前的语言层检查清单

1. 品类词是否用了真实查询里的组合形态，而不是词典原形
2. 词表是否以词根为单位聚类，后缀是否被当成意图信号分类
3. 大小写转换是否区分了展示文本与内部标识符两条路径
4. 地址生成是否使用不依赖地区设定的固定规则
5. 登录、去重、比较这几处是否排查过大小写归一的隐患
6. 六个专属字符在标题、正文、地址、数据库里是否一致存活
7. 拉丁化映射表是否写死并全站统一
8. 站内搜索是否做了字符归一，筛选器是否一起改了
9. 词干还原的结果是否抽查过，有没有把不同的词归并到一起
10. 排序规则是否设成支持土耳其语的那一套
11. 标题语序是否符合本地习惯，没有硬拼动词
12. 短信、面单、发票这些老通道是否做过端到端字符测试
13. 支付方式与分期信息是否写在价格旁边

十三条里只有四五条需要工程介入。剩下的全是有人认真过一遍就能解决的事——而经验里翻车的项目，缺的从来不是能力，是没人把这张表认领下来。

常见问题解答

土耳其语的关键词表，到底该以词根还是以完整形态为单位？

以词根为单位建表，以完整形态做输出。这两件事必须分开。建表阶段按词根聚类，把所有带后缀的形态归到同一个概念下求和，这样才能正确判断一个品类值不值得做；如果按形态逐条排优先级，同一个概念的量会被切成几十份，每一份看起来都不值得投入，结论必然是错的。输出阶段则要看真实查询用的是哪个形态，尤其是名词组合类的品类词，绝大多数在真实查询里是带后缀的组合形式，标题里必须用那个形态。判断方法很简单：把词丢进搜索框看下拉建议，建议里出现的形态就是用户在打的形态。另外提醒一点，土耳其语的后缀可以叠加，穷举组合数量很大，建议先用程序按固定的后缀顺序生成候选，再拿搜索建议和站内搜索日志筛一遍，纯手工列是列不完的。

点i和无点ı的问题，具体该怎么防？

把大小写转换分成两条路径，写进开发规范里。面向用户展示的文本，比如标题的美化显示、界面文案，用带土耳其语地区设定的转换，这样İstanbul这类词才不会显示错。程序内部的一切标识符，包括地址生成、邮箱归一、配置项名称、模板标签、字符串比较，一律用不依赖地区设定的固定规则转换。混用这两条路是绝大多数事故的根源，因为同一段代码在不同服务器的地区设定下会给出不同结果，而这种问题在测试环境往往复现不出来。落地时还有两个检查点：一是审一遍代码里所有的小写转换调用，看有没有漏掉地区参数的；二是造一批包含大写I和带点大写İ的测试数据，跑一遍注册、登录、下单、搜索的完整链路。这个雷排一次就能一劳永逸，但没排过的站几乎必然会中。

名词组合的后缀，为什么会让整个品类页失效？

因为土耳其语里两个名词组成复合概念时，后面那个名词必须带上表示从属关系的后缀，而且词根末尾的辅音还可能跟着软化。这不是可选的修饰，是构词的基本规则。用户在搜一个具体品类时，脑子里的词就是那个组合形态，打出来的也是它。如果你的分类页标题写的是光秃秃的词根，那就等于用了一个本地人不会用来搜的写法，页面主题跟真实查询对不上，排名自然起不来。检验方法只要十分钟：把你的所有品类词逐个丢进搜索框，看下拉建议给出的是哪种形态；再看排在前面的本地竞品，它们的标题用的是什么写法。两处一致的那个形态，就是你该用的。这一步能救回整个品类，是投入产出比最高的一次检查。

土耳其语的站内搜索一定要上词干还原吗？

不一定，但优先级比大多数语言高，因为后缀叠加让字符串匹配几乎完全失效。建议按三层推进：第一层做字符归一，把六个专属字符映射成基础字母，查询和索引都做，半天工作量，能解决用户不打专属字符的那部分；第二层做同义词表，把高频品类词的组合形态、常见后缀形态手工映射到商品词，两三天工作量，能解决名词组合这个最大的痛点；第三层才是接入词干还原组件。特别要注意的是，土耳其语的词干还原比大多数语言难，因为后缀能叠加，剥离层数不好把握，剥多了会把语义不同的词归并到一起。上线后必须抽查一批高频词的还原结果，不能直接信默认配置。另外改搜索时一定要顺手改筛选器，两者用的是同一套比对逻辑，只改一半的话用户照样会遇到明明有货却筛不出来的情况。

页面上的土耳其字符要不要为了搜索而简化？

不要。可见文本一律用规范写法，把ş写成s、ğ写成g的页面在本地人眼里就是错别字连篇，信任损失远大于那点搜索收益。用户不打专属字符这件事应该在别的层面消化：站内搜索做字符归一，筛选器跟着一起改，地址走固定规则的拉丁化。搜索引擎那一侧对土耳其语的字符容错已经相当成熟，你不需要为它单独造一批无变音版本的页面，那样只会造出一堆内容雷同、互相稀释的页面，得不偿失。唯一可以适度让步的地方是站内搜索的联想提示，可以同时接受两种输入并给出相同的结果，但展示出来的候选词仍然要用规范写法。这样既照顾了输入习惯，又没有牺牲页面的专业度。

土耳其语的标题模板能不能自动生成？

可以，但要绕开两个陷阱。第一个是名词组合的后缀，模板如果直接把品类词和属性词并排拼，缺了那个从属后缀，输出的就是本地人不会用的写法。第二个是语序，土耳其语的修饰成分放在被修饰词前面、动词放在句末，照着英语语序拼的模板读起来是明显的翻译腔。比较现实的做法是：把品类词在属性字典里直接存成组合形态，模板取用时不再拼接；属性值作为独立标签用分隔符甩在标题后面，避开语序和一致性问题；带来主要流量的那几十个品类的标题全部人工写定，长尾走模板。还有一条容易被忽略的：标题长度。土耳其语的词因为后缀而更长，搜索结果里能显示的字符有限，核心词一定要放在最前面，否则后半截被切掉的概率很高。

品牌名加后缀时的撇号，页面上要不要写？

正式写法要写，但要配一整套容错。土耳其语里专有名词加后缀习惯用撇号隔开，页面上的规范写法应该带上，并且全站统一用同一个撇号字符。麻烦在于三点：一是用户打字时经常省略撇号，尤其在手机上；二是撇号有好几个长得几乎一样的字符，用户从别处复制粘贴过来的可能是任意一种；三是后缀的形态取决于品牌名怎么读而不是怎么拼，外来品牌名容易出现两种流传写法。对应的处理是：页面正式写法带撇号并统一字符；站内搜索把所有撇号变体和缺失情况归一到同一个目标；地址里一律去掉撇号，跟拉丁化规则一起处理；官方定一种后缀形态用在所有正式场合，同时确保最流行的民间写法在页面上自然出现过一次。型号除外，带数字和字母的组合一律保持原样不加后缀。

土耳其市场适合什么阶段进入？

看你的品类结构和本地化能力。土耳其的吸引力在于人口年轻、线上消费活跃、本土供给在部分品类上并不强，跨境卖家有明确的切入空间；难点在于本地化的门槛比欧洲市场高一截，语言层的坑多，支付习惯特殊，物流和清关的确定性也不如西欧。经验上的判断方法是：如果你的品类客单价中等偏上、不高度依赖分期、并且能提供确定的到货时效，那土耳其是值得早做的市场，因为竞争密度相对低；如果你的品类价格敏感、成交高度依赖分期能力，那在解决本地支付之前进场会很吃力，内容做得再好也换不来订单。还有一条建议：先用一小批内容试水，重点观察站内搜索日志里用户实际打的词形，那份数据比任何工具都准，也能快速验证你的品类词写法对不对。

怎么快速判断一段土耳其语文案是不是机器翻译的？

盯三个特征，不需要精通土耳其语也能看出大概。第一个是名词组合，两个名词并排出现而后面那个没有带从属后缀，这是翻译引擎最常犯的错，也是最伤搜索的一类。第二个是动词位置，土耳其语的动词在句末，如果整段里动词频繁出现在句子中间，那多半是照着英语语序直译的。第三个是后缀的一致性，同一个词在同一段里出现了两种不同的后缀写法，或者后缀的元音跟词根明显不同组，那就是元音和谐没处理对。这三条可以做成一张小卡片发给内容团队，验收时对着扫一眼，比逐句读快得多。要强调的是，机器翻译当初稿工具完全没问题，问题只出在直接发布上，配一轮针对这三类问题的定向审校，成本不高但效果立竿见影。

权威参考资料