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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

这一路的泰语开源实现里，最经典的是libthai提供的泰语分词与断行支持库，另一支是命令行工具SWATH。

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

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

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

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

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

出在短音节堆叠的地方。

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

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

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

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

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

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

标题该怎么写才切得开？

有一条很朴素的判据。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

拆写还有个附带好处。

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

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

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

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

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

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

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

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

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

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

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

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

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

韩语是有空格的。

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

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

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

韩语分写法与助词那一套打法在泰语上一条都用不上，反过来也一样。这两门语言经常被放在同一张东亚清单里，实际上一个字都不通用。

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

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

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

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

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

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

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

越南语那边的音节分写与声调双轨问题和泰语这边是两道相反的题，一个做加法一个做减法。同在东南亚、同是声调语言，在这一维上却是两端。

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

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

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

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

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

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

芬兰语粘连的边界发生在词的内部，是构词法层面的，词与词之间的空格照旧存在。芬兰语那种词干自己还会变形的麻烦更是泰语完全没有的——泰语的词根本不变形。

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

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

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

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

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

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

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

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

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

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

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

URL里能不能直接写泰文？

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

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

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

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

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

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

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

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

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

IANA根区数据库里能查到泰文后缀的委派记录，实际写进浏览器的是它的Punycode形式。注册和解析都没有问题。

值不值得是另一回事。

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

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

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

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

泰文的换行会把词从中间劈开吗？

会，而且这是泰语网页上最常见的排版事故。

浏览器的默认换行策略在没有空格的文本里无处下刀。早期的处理是碰到容器边界直接切，切在词中间是家常便饭。

正确的解法是让排版引擎知道泰语的断行也要查词典。Unicode的换行算法规范把泰语这类语言单列为需要词典辅助的情况，现代浏览器在样式层给了对应的控制手段。

这件事影响的是可读性和跳出率，不直接影响收录。

但它值得修——一个词被劈成两半，读者要多花半秒钟才能拼回去，而移动端一屏里可能出现七八次。

判断有没有这个问题很快：把浏览器窗口拉窄到手机宽度，找一段长泰文，看看断行的位置是不是落在合理的地方。

落在音节中间就说明排版引擎没走词典路径。这时候前端要么显式指定语言，要么在样式层换一种断行策略。

泰文的组合字符会让字符串长度算错吗？

会，而且错得很隐蔽。

泰文的元音符号和声调符号是独立码位，会叠加在辅音的上方或下方。一个视觉上只有一格宽的音节，在程序看来可能是三个字符。

后果是所有按字符数做的限制全部失真：标题字数校验、摘要截断、数据库字段长度、后台的字数统计。

按字符数截断还会把声调符号从它依附的辅音上切下来，渲染出一个孤零零的浮空记号。

凡是要截断泰文的地方，都得按字素簇来算，不能按码位。这条规则同样适用于所有带组合记号的书写系统，泰语只是踩得最狠的一个。

一个快速的自查方法：拿一段泰文，用你系统里的长度函数量一遍，再让母语者数一遍视觉上的音节数，两个数字差得越远，问题越大。

差三成以内还能忍，差一倍以上说明所有跟长度相关的逻辑都要重写。

标题在搜索结果里被截断，泰语为什么更容易出事？

因为搜索结果的标题截断是按像素宽度算的，而泰文的字符平均宽度比拉丁字母窄，同样的像素能塞下更多字符。

听起来是好事，但泰文的行高需求比拉丁字母高，上下两层记号都要地方。

更要紧的是没有空格这一点又回来了。

英文标题被截断，最多断在一个单词的边界上；泰文标题被截断，大概率断在某个音节中间，尾巴上留一个残缺的字符。

写泰语标题时，把最重要的信息塞进前半段，比在英语里更要紧。后半段能不能活下来，你说了不算。

还有一个连带影响：截断位置不可预测，意味着你没法靠数字符来控制标题长度，只能靠实际渲染去看。

我的做法是把候选标题渲染成图，按目标设备的宽度截一刀，直接看断在哪儿。比在表格里数字符可靠得多。

泰文的排序规则为什么要倒着比？

这是泰语最反直觉的一处，也是极少有人提的。

泰语有五个前置元音，它们写在辅音的左边，读的时候却在辅音之后。书写顺序和读音顺序在这五个元音上是颠倒的。

排序算法必须把这个顺序倒回来再比较，否则所有以前置元音开头的词都会排到错误的位置。

Unicode排序规范里专门处理了泰语这种前置元音重排的情形，规则写得很细。

你自己写的那个按码位比较的排序函数，在泰语上一定是错的。品牌列表、品类导航、字母索引，只要按字母序排，全都会错。

这个问题的隐蔽之处在于，错误的排序看上去也是一种排序。列表整整齐齐，只是顺序对泰国用户来说毫无道理。

验收方法是找母语者看一眼品牌首字母索引，他会立刻指出哪几个位置不对。这种错误肉眼可辨，前提是那双眼睛得是泰国人的。

为什么站内搜索在泰语上会完全失灵？

因为大多数站内搜索的默认实现是按空格切词的。

泰语文本进去，切出来只有一个巨大的字符串。用户输入任何一个词都匹配不上，或者退化成全文的模糊匹配，返回一堆不相关的东西。

解决办法是在索引阶段接一个泰语分词器，把文本切成词再建索引。

这件事在英语站上不需要做，所以很容易被整个跳过。

直到某天有人发现，泰语站的站内搜索转化率只有其他语言站的零头，而站内搜索通常是全站转化率最高的入口之一。

接分词器之后还要处理一件事：查询词也得走同一套切分，否则索引侧切好了，查询侧还是整串，照样匹配不上。

索引和查询用不同的切分策略，是这类改造里最常见的半吊子做法，改完看着接了分词器，效果一点没变。

筛选器和面包屑在泰语里怎么写才不粘连？

筛选器的标签往往是一个个短词，前端拼接时习惯用逗号或者斜杠连接。

在泰语里这些符号可以保留，但符号两侧要不要留空格，得统一。混着来的话，同一个筛选值在不同页面上会有两种形态。

面包屑更要小心。

层级之间的分隔符如果贴着泰文写，视觉上会和泰文字符粘成一片；两侧都留空格，又可能被解析成泰语的句子分隔。

我的做法是分隔符两侧统一留一个空格，并在结构化数据里另外给一份不含分隔符的干净名称。展示归展示，数据归数据，两边不要混。

还有一个细节：筛选值里如果混着英文和泰文，两种文字之间要不要留空格也得定死。

泰语的正字法允许在外来语两侧加空格，所以我倾向于留。但要全站统一，不能这页留那页不留，否则同一个筛选值会分裂成两个。

图片文件名和替代文本，用泰文还是拉丁转写？

文件名用拉丁转写，替代文本用泰文。

理由跟URL那条一样：文件名进了路径就要被编码，泰文文件名在服务器迁移、打包下载、CDN回源这几个环节都容易出问题。

替代文本则相反。它是给用户和图片检索用的，必须是泰文，而且要写成一句自然的泰语描述，不要堆关键词。

泰语的图片搜索在本地市场的使用率不低，这块的流量比很多人以为的值钱。

还有一条容易漏：替代文本里的泰文同样要过一遍分词器，确认关键的品类词没被写成一个切不开的怪串。

转写方案本身也要统一。泰语转拉丁有好几套体系，不同的转写规则会把同一个词写成不同的样子。

选定一套之后写进规范文档，让所有人照着执行。半年后回头看，你会庆幸当初花了这十分钟。

泰语的自动补全为什么给不出建议？

站内的自动补全通常是按前缀匹配的。

泰语用户在输入框里打了三个字符，这三个字符可能只是某个词的前半个音节，前缀匹配当然找不到东西。

等他打完整个词，补全也就没意义了。

可用的做法是把候选词表先用分词器切好，按词而不是按整串建前缀索引，同时允许从词的中间开始匹配。

这会让候选集变大，需要配一层打分来控制噪声。但比给不出建议强——补全给不出东西，用户就会直接放弃搜索。

还有一个提升手段是把历史查询日志接进来。真实用户打过的字符串，哪怕不是完整的词，也是有效的补全起点。

这套数据在泰语上格外值钱，因为它绕过了分词这一层，直接反映了用户真实的输入行为。

表单验证会误伤哪些泰文输入？

最常见的是姓名字段。

泰国人的名字通常很长，加上前缀敬称之后超过很多系统的默认字符上限，而这个上限往往是按拉丁字母的经验设的。用户被迫截断名字，订单信息就跟证件对不上了。

第二常见的是不允许特殊字符这类正则。泰文的声调符号和元音符号在一些粗糙的正则里会被当成非字母字符拦下来。

第三是搜索框的最小长度限制。泰语一个有意义的词可能只有两个字符，设成三个字符起搜，就把它挡在外面了。

这三条都不是泰语独有的问题，但泰语是最容易同时踩满的那一个。

第四条是密码强度校验。有些实现要求必须包含大写字母，泰国用户如果用泰文当密码的一部分，永远满足不了这个条件。

这类规则在设计时都默认了拉丁字母的世界观。做泰语站时把所有校验规则拉出来过一遍，通常能找出三四条这样的。

泰国用户实际打进搜索框的是什么？

是很口语的短句，而且经常不写完整。

泰语的疑问词、语气词在口语里用得极频繁。这些词会大量出现在真实查询里，却几乎不会出现在你的商品文案里。

这两套语料的差距，是泰语站长尾流量的主要缺口。

补的办法是把这些口语说法收进常见问题区和商品描述的自然句子里。不是塞关键词，是真的用泰国人说话的方式写一段。

这件事必须交给母语者。翻译出来的泰语在这个维度上永远是假的——它语法全对，但没有一个泰国人会这么说话。

还有一个特征是查询里经常带着场景词，比如放在哪个房间用、给谁买、什么时候用。这类修饰在英语查询里出现得少得多。

把这些场景词织进商品描述的自然句子里，能接住一大批中长尾。前提是你得先知道泰国人是按场景而不是按参数在找东西。

泰式英语混写在关键词里占多大比重？

比想象中大。

泰国的城市用户在打字时会大量混用英文，尤其是品类词、品牌词、技术参数。一个查询里前半段泰文后半段英文是很常见的形态，反过来也有。

这带来一个实际的排布问题。

你的页面上必须同时有泰文和英文两种写法，而且要挨得足够近，让引擎能把它们关联起来。

全泰文的页面会漏掉混写查询，全英文的页面在本地市场没有竞争力。两边都得有，而且不能靠一个孤零零的英文标签硬凑。

混写还有一层要注意：英文部分的拼写经常是简写或者本地习惯写法，跟标准英文不一样。

照搬国际站的英文术语，可能一条都对不上。这块最好从本地的客服记录和站内搜索日志里捞，捞出来的才是真的。

泰语的数字要用泰数字还是阿拉伯数字？

泰语有自己的一套数字符号，但在商业场景里几乎已经不用了。

价格、规格、日期，泰国人日常看到的都是阿拉伯数字。泰数字现在主要出现在正式公文、寺庙题字、纪念性场合。

所以商品页一律用阿拉伯数字，这一点没有争议。

但你的搜索和筛选逻辑最好能同时接受泰数字输入，成本很低。遇到从公文场景复制过来的输入时能救一次。

顺带一提，泰数字和阿拉伯数字在排序时也要归一化，否则同一批数据会分成两堆各排各的。

价格的千位分隔和小数点也要按泰国习惯来，跟大多数西方市场一致，但跟一些东南亚邻国不同。

这类细节单看无关紧要，凑在一起决定了页面读起来像不像本地做的。用户说不出哪儿别扭，但他会走。

泰国的日期和佛历年份该怎么处理？

这条是泰语本地化里最容易翻车的地方，而且翻车之后不容易被发现。

泰国官方使用佛历，佛历年份比公历大五百四十三年。同一个年份，在泰国的政府网站、发票、身份证件上写的是四位数的佛历年。

如果你的日期本地化库按泰语区域设置渲染年份，它可能会自动转成佛历，页面上就出现一个比今年大五百多的年份。

反过来，如果用户按佛历填写生日，你的年龄校验会算出一个负数，然后拒绝这笔订单。

两个方向都要显式指定用哪套历法，不要依赖库的默认行为。这是那种测试环境永远发现不了、上线第一天就爆的问题。

还有一个衍生场景：促销活动的倒计时和有效期。如果后端存的是公历，前端按泰语区域渲染成佛历，用户看到的截止日期就在五百多年后。

这种页面用户不会来投诉，他只会觉得这个站不太靠谱然后关掉。属于典型的静默流失。

泰语的敬语层级会影响转化吗？

会影响转化，不影响排名。

泰语的礼貌语尾分男女，句末那个词男性说和女性说是不一样的。品牌文案该用哪一个，取决于品牌人格设定，不是随便挑。

更常见的问题是通篇不用礼貌语尾。

机器翻译出来的泰语几乎都是这样，读起来像命令句，泰国用户会觉得这个牌子很没礼貌。

在按钮文案和客服自动回复上尤其明显。一句立即购买不带礼貌语尾，语气大概相当于中文的“买”字后面跟一个感叹号。

还有一处常被忽略：错误提示的语气。表单填错时弹出的那句话如果是命令句，用户的挫败感会明显放大。

把错误提示改成带礼貌语尾的说法，成本几乎为零，对表单完成率的影响却能量出来。

泰国的三级行政区划表单怎么设计？

泰国的地址是府、县、区三级，加上邮编共四个字段。

这三级之间有严格的从属关系，不能让用户自由填写，得做成联动下拉。曼谷的行政区划名称和外府还不一样，是另一套叫法。

邮编是五位数字，前两位对应府。

可以做成填邮编自动带出前两级，能显著减少填错。

这类字段的正确性直接影响物流成本，属于那种做好了没人夸、做错了每单都亏钱的活。泰国的偏远配送加价规则又跟府一级绑定，填错一次就是真金白银。

还有一件事：行政区划的名称会变。合并、改名、新设都发生过，你的对照表如果是三年前拉的，现在一定有对不上的。

解决办法是把这张表当成需要定期更新的数据，而不是写死在代码里的常量。写死的那一刻，它就开始过期了。

泰语的声调符号会不会被用户漏打？

不会，这一点跟越南语正好相反。

越南语的声调符号在键盘上要额外按键，所以有大量用户干脆不打；泰语的声调符号在泰文键盘上是独立按键，打字时跟辅音元音一样是必须按的，漏掉就拼不出这个词。

所以泰语不需要做带调不带调的双轨覆盖。

这一块预算可以整个省掉，挪到分词验证上去。

同样是东南亚的声调语言，两门语言在这件事上的结论完全相反。谁要是拿越南语的经验直接套泰语，会白花一笔钱去覆盖一批根本不存在的查询变体。

要注意的是泰语有另一类输入变体：某些元音符号在不同输入法下的码位顺序可能不同，视觉上一模一样，字节上不一样。

这个问题的形态跟越南语的编码统一有点像，但成因完全不同，一个是输入法差异，一个是正字法本身有两套。处理手段是入库前统一做一次规范化。

零宽字符正在污染你的泰语关键词表

这是泰语网页上一个非常隐蔽的问题，我很少见到有人提。

因为浏览器的泰语断行支持长期不完善，泰国的前端开发者形成了一个习惯：在词与词之间手工插入零宽空格，给浏览器一个可以断行的提示。

零宽空格是不可见字符，但它实实在在存在于文本里。

它会破坏引擎的分词、破坏你的关键词匹配、让两个看起来一模一样的字符串比较结果为假。从泰语页面复制文本进关键词表时，这些字符会跟着进来。

做泰语站的第一件事，是在所有数据入口处把零宽字符清掉。商品导入、内容发布、关键词表导入，三处各加一道。

还有一个隐蔽的来源：从设计稿或者办公文档里复制文案。这些工具为了排版也会插入不可见字符，而且种类比零宽空格更多。

我的习惯是所有从外部进来的泰文，先过一遍字符白名单，不在名单里的一律剔除。宁可误删一个奇怪的符号，也不要放一个隐形字符进关键词表。

泰文的字体行高会把上下两层记号压掉吗？

会。

泰文的一个音节最多可以有四层：基线上的辅音、下方的元音、上方的元音、再上方的声调符号。

行高设得跟拉丁字母一样，最上面那层声调符号就会被裁掉，或者跟上一行的下标元音撞在一起。

经验值是泰文的行高要比同字号的拉丁字母多给两成到三成。

这件事不影响任何SEO指标，但影响的是用户能不能看清那个决定词义的声调符号——泰语的声调一变词义就变，看不清等于看错。

字体选择上也有讲究。不是所有支持泰文的字体都把四层记号处理得一样好，有些在小字号下会把上标挤成一坨。

定字体之前，用最小的正文字号渲染一段带满记号的泰文看看。这一步只要五分钟，能避开一整年的可读性投诉。

分词器版本不同，切法就不同吗？

是的，而且这件事会让你的监控数据出现无法解释的波动。

词典是会更新的。新词收进去之后，原来被切成两段的字符串可能突然变成了一个词，反过来也有。

实际影响是：你自己用来做关键词校验的那个分词器，和搜索引擎线上用的那一套，词典大概率不同步。

所以本地跑出来的切分结果只能当参考，不能当判决。

真正的判决只有一个——去搜那个词，看看你的页面在不在结果里。这句话听着像废话，但在泰语上它是唯一可靠的验收手段。

实际操作上可以留一份切分基线：把核心词表的切分结果存下来，每次升级分词器之后重跑一遍做对比。

差异清单出来之后，只看那几条变了的，比每次全量重验省事得多。这也是发现词典更新的最快信号。

泰语内容的长度该按什么算？

不能按字符数算，也不能按词数算——你都数不出有多少个词。

相对可靠的做法是按音节数，或者干脆按渲染出来的视觉行数估。

更实用的一条是别拿英文站的字数标准往泰语上套。

泰语表达同一个意思，字符数通常比英语少，因为一个音节就是一个信息单元，不需要那么多字母。

硬凑字数只会逼出一堆废话，泰国读者一眼就能看出来这是翻译腔。按信息点的数量定长度，比按字符数定靠谱得多。

还有一个反向的问题：泰语写太短也不行。信息点不够，页面在竞争激烈的品类词上撑不住。

判断够不够的方法不是数字数，是把页面上回答了的问题列出来，跟排在前面的几个页面比一比。少了哪几个，补哪几个。

泰文编码的历史遗留还会影响你吗？

还会，主要出现在跟本地供应商对接数据的时候。

泰语在统一编码普及之前用的是一套单字节编码，至今还登记在国际的字符集注册表里。老系统导出的商品表格很可能还是这个编码。

转码不彻底的典型症状是：泰文能显示，但声调符号全丢了，或者位置错乱。

这种数据进了商品库，页面看着有内容，实际上每个词都是错的，而且错得很像正常文本，肉眼扫过去不一定能发现。

导入前先抽查十条丢给母语者看，比上线后回滚省事得多。

除了商品数据，另一个高发区是历史内容迁移。老站的数据库如果是那套单字节编码存的，导出时不指定编码就会全乱。

迁移前先在测试库上跑一遍，抽几条带声调符号的记录对照原页面看。声调符号是最好的检测器，它一错就全错。

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

泰国市场的搜索格局、本地平台的流量分配、投放侧的打法，这些属于引擎层，不在语言层的讨论范围里。

多语言站的目录结构、语言标注该怎么落地，同样是架构问题。国际化SEO与hreflang那一篇已经写完了，这里不再展开。

本篇只回答一件事：泰语这门语言本身，给关键词研究和页面撰写带来了哪些别的语言没有的约束。

判据很简单——把语种换成英语就不成立的，才是这里该写的。

按这个标准，前面那些关于词典、前置元音、零宽字符、佛历的段落全部合格，而“泰国人爱用手机”这种话就不合格，它在任何市场都成立。

把边界划清楚也是一种交付质量。读者知道这篇管什么、不管什么，才知道剩下那半边该去哪儿找。

这比在一篇文章里什么都提一句、什么都不讲透要有用。

泰语的母语审校该验收哪几件事？

验收清单我一般给五条。

第一，把标题和主要关键词丢进分词器，确认每个目标词都是独立单元。第二，检查零宽字符是否已清干净。

第三，确认礼貌语尾的使用一致且符合品牌人格。第四，抽查日期和年份有没有被转成佛历。第五，让母语者念一遍按钮和表单提示，听着别扭的全部重写。

这五条里只有第三和第五需要母语者，前两条是脚本能跑的，第四条是测试用例能覆盖的。

把能自动化的先自动化掉，母语者的时间要花在机器判断不了的地方。母语审校的单价不低，让他们去数零宽字符是最贵的一种浪费。

再补一条流程上的建议：审校要在内容定稿之后、上线之前做，不要放在上线之后当作优化项。

泰语的这些坑一旦上线，改起来牵扯的是URL、结构化数据、外部引用一整串。前置一天的成本，抵得上后面一周的返工。

常见问题解答

泰语站的标题里到底能不能加空格？

能，但要加在泰语允许的位置上，也就是语义单元之间、外来语两侧、数字与单位之间，不能加在一个词的内部。加对了位置，等于给引擎一个明确的硬边界，比让它自己猜要可靠；加错了位置，泰国读者读起来会很别扭，而且不会带来任何分词收益。判断标准是找母语者读一遍，读着卡壳的地方就是加错了。另外要提醒的是，加空格不等于可以随便加：同一批商品的标题必须用同一种断法，否则同一个品类词在不同页面上会呈现出不同的切分形态，站内的聚合和去重都会跟着乱。

我用本地分词器验过的关键词，为什么线上还是排不上？

因为你手里那个分词器的词典和搜索引擎线上用的不是同一份。词典会更新，收录范围也不一样，本地切得开不代表线上切得开。本地验证的价值在于筛掉明显有问题的候选词，把自造复合词和未登录串挡在提纲之外，最终判决只能靠实际去搜、看页面在不在结果里。别把本地结果当成保证，它只是一道成本极低的初筛。还有一种可能是词切对了，但这个词本身在泰语里太冷僻，真实搜索量几乎为零。分词器只管切得开不开，管不了有没有人搜，这两件事要分开验。

泰语需不需要像越南语那样做带调和不带调两套？

不需要。越南语的声调符号在键盘上要额外操作，所以有大量用户不打；泰语的声调符号是泰文键盘上的独立按键，属于必按项，漏了就拼不出词。这块预算在泰语上可以整个省掉，挪到分词验证和口语化长尾上更划算。同为东南亚的声调语言，这两门语言在这件事上的结论是相反的，拿一边的经验套另一边会白花钱。真正需要在泰语上做变体覆盖的，是外来语的泰文音译写法。同一个英文词经常有两三种通行的音译形态，这一块才是泰语的变体重灾区。

零宽字符到底怎么检测和清理？

检测靠正则扫描不可见字符的码位，清理放在数据入口处，也就是商品导入、内容发布、关键词表导入这三个环节各加一道。要注意的是不能无差别删除所有不可见字符，泰文本身的元音和声调符号是有宽度的正常字符，别误伤。写一条只针对零宽字符的规则，跑一遍全站文本，通常能扫出一批，尤其是从本地供应商那儿拿来的商品描述。清理之后最好加一道监控，定期扫全站泰文页面，一旦又出现就报警。这类字符是随着人和流程进来的，清一次不能一劳永逸。

泰文URL和拉丁转写URL，哪个更好？

拉丁转写。泰文进URL之后每个字符要占九个字符位置，而且泰语没有空格也就没有连字符可放，得到的是一条不可读的编码串。分享链接时用户看到的是乱码，复制粘贴环节也更容易出问题。路径可读性上的那点损失，换来的是整条链路的省心。泰文域名后缀同理，适合做品牌保护性注册，不适合当主站入口。如果站点已经上线并且用了泰文路径，别急着全站改。先评估这批URL的现有权重和外部引用，分批迁移并做好跳转，比一次性推倒重来稳妥。

佛历年份这件事具体会在哪些地方出问题？

三个地方。一是日期本地化库按泰语区域设置自动转成佛历，页面上出现一个大五百多的年份；二是用户按佛历填生日，你的年龄校验算出负数并拒单；三是跟本地供应商对接的单据上写的是佛历年，导入时被当成公历，整批数据的时间轴全部偏移五百多年。三处都要显式指定用哪套历法，不要依赖库的默认行为。还有第四处：结构化数据里的日期字段。那里必须是公历的标准格式，被本地化库改成佛历的话，整段标记会被判为无效。

泰语内容的字数标准该怎么定？

别从英文站的标准换算过来。泰语的一个音节就是一个信息单元，表达同样的意思字符数通常更少，按英文字数硬凑只会凑出翻译腔的废话。比较实用的做法是按信息点数量定：这个页面要回答几个问题、给出几组参数、覆盖几种使用场景，把这些数清楚，长度自然就合理了。真要量化，按音节数或者渲染行数估，比按字符数靠谱。有一条经验值可以参考：泰语页面的信息点密度要比英语高一些，因为泰语读者对铺陈式的过渡句容忍度更低，废话一多他们翻页比谁都快。

权威参考资料