同一座城市在你的两个市场里是两个不同的词，而配送页的标题只能写一个

摘要：你的配送页上写着慕尼黑，德国用户搜的是München，意大利用户搜的是Monaco di Baviera，捷克用户搜的是Mnichov。这几个词不是彼此的音译，是各自语言独立造出来的名字，谁都不比谁更正确。联合国从1972年起就要求各国编制并削减外来地名清单，五十年过去清单没短反而更长，因为地名标准化管得住地图，管不住用户嘴里那个词。

本文讲清楚本地名与外来名的分界、一个地名会长出几种形态、哪些页面会被它咬到、屈折语里还要再乘一次变格，以及地名字段该怎么在CLDR、结构化数据和自建别名表之间分工。

你写的那座城市和用户搜的那座城市，不是同一个词

一次配送页的实测

有个做户外家具的客户，德国站做得挺认真，配送说明里逐条列了主要城市的时效。

页面上写的是Munich、Cologne、Nuremberg，一水儿的英文名。原因也不难猜：这套内容是从英文站翻过去的，译者动了正文，没动地名。

德国用户搜的当然是München、Köln、Nürnberg。这三组词之间没有任何一个共同的字符片段能让搜索引擎把它们对上。

更麻烦的是，这个站还做了意大利和捷克两个市场，用的是同一份配送模板，同样一水儿英文名。

意大利人管慕尼黑叫Monaco di Baviera，捷克人叫Mnichov。这两个词跟München之间没有任何拼写上的联系，它们不是从德语音译过去的，是各自语言在几百年里独立形成的名字。于是三个市场的配送页，同时对三批用户都是隐形的。

这件事最让人不舒服的地方在于，它不像那些技术问题会报错。页面正常、翻译正常、结构化数据正常，没有任何一个工具会亮红灯，只有一批本该进来的搜索安安静静地没进来。

后来我们把那份配送表里的城市名换成德语写法，其他一个字没动。这类改动的特点是没有中间态，要么完全对不上，要么一次性对上，所以变化来得比大多数优化动作都干脆。

这个客户后来跟我说了一句挺在理的话：他们花了半年打磨配送时效，把从四天缩到两天，却从来没人问过一句，找得到这个页面的人到底是谁。

这不是翻译没做好

你可能会说，那让译者把地名也翻了不就完了。

问题是地名不走翻译流程。翻译记忆库里通常把专有名词设成不译，这是为了保护品牌名和型号，而地名恰好也被这条规则罩住了。

更根本的是，地名不是翻译出来的，是各语言自己有一套。译者要做的不是翻译，是查表替换，这是两种不同性质的操作。

翻译讲究忠实于原文，查表替换讲究忠实于目标语言的既有说法，后者根本不看原文长什么样。

我在小语种关键词表里那些没人搜的词里讲过直译遗产，那件事至少还有一个词可以译。地名这件事更彻底：原文里那个词跟目标语言里该用的词之间，没有任何可以推导的关系，只能靠一份对照表。

还有一个结构性原因：地名在多数内容管理系统里根本不是文本，是从一份地区表里读出来的枚举值。译者在稿子里看不到它，他看到的是一个占位符。

还有一种情况更隐蔽：内容管理系统里的地区表是全局共享的，一改会影响所有语言版本。于是负责德语站的人不敢动它，因为他不知道改了之后意大利站会变成什么样。

三个名字可以同时正确

习惯了做规范化的人，第一反应往往是问哪个才是对的。

这个问题在地名上没有答案。慕尼黑这座城市的官方名字只有一个München，这一点毫无争议。

但意大利语里正确的说法就是Monaco di Baviera，它在意大利的教科书、地图、新闻里都是这么写的，它不是一个错误的写法，它是意大利语的正确写法。

所以正确这个词在这里必须带上限定语：在哪门语言里正确。脱离语言谈地名的对错，是无解的。

这跟做品牌名规范的思路正好相反。品牌名是你的私产，你可以规定全世界都写同一串字符；地名是公共财产，每门语言各自持有一份使用权，你只能跟着用，改不动。

顺着这个思路还能推一步：既然正确要看在哪门语言里，那你的地名字段就必须带语言标签。一个不带语言标签的地名字段，本质上是在假设全世界只有一门语言。

所以我一般建议团队在内部把这件事的说法统一成：这座城市有几个名字，分别属于哪门语言。而不是问哪个名字是对的，后面这个问法本身就把讨论引到了没有答案的方向上。

本地名和外来名的分界线在哪儿？

联合国给过一份定义

这套术语不是学界随便起的，联合国地名专家组编过一份术语表，把它们写得很清楚。

本地名指的是这个地方在当地官方语言里的名字，比如München。外来名指的是另一门语言给它起的、跟本地名不同的名字，比如Munich。

判据是差异，不是来源。如果另一门语言原样照抄了本地名，那就不算外来名，只是同一个名字被借用。

所以Berlin在英语里不是外来名，因为它跟德语写法一模一样；而Cologne是外来名，因为它跟Köln明显不同。

这条分界线对我们做搜索的人特别有用，它把地名一分为二：一半是零成本的，照搬就行；另一半必须逐个查表。你的工作量只落在后一半，而这一半通常只占主要城市的两三成，盘点起来并不吓人。

这套术语在联合国地名标准化术语表里有正式定义，值得花十分钟翻一遍。它给出的判据非常干脆：看名称跟当地官方形式有没有差异，有差异就是外来名，没差异就只是借用。

转写不算外来名

这是最容易混淆的一处。

把Москва写成Moskva是转写，是把一套字母系统机械地映射到另一套；写成Moscow才是外来名，那是英语自己的词。

转写有规则，可以写成代码；外来名没有规则，只能查表。这是两件工程性质完全不同的事。

我在小语种URL用本地字母还是拉丁转写里讲的就是前者，那件事的核心是选一套规则并且从头到尾一致。

这篇讲的是后者。把这两件事混在一起处理，最典型的后果是有人写了一个自动转写模块，然后指望它把Köln转成Cologne——它永远转不出来，因为这两个词之间不存在任何字符级的对应关系，那是历史，不是算法。

还有一个实际后果：转写形态在搜索里的量通常很小，因为没有哪一群人的母语里天然就用这套写法。它主要活在护照、机票、快递单这些跨系统传递的场景里。

还有历史名、并行名和少数民族语言名

实际的地名数据比两分法复杂。

历史名是这个地方以前叫过、现在不再是官方名字的说法。它在搜索里仍然活着，尤其在年长用户和历史内容里。

并行名指的是同一个地方在两门官方语言里各有一个名字，比利时和瑞士到处都是这种情况。

爱沙尼亚语言研究所的地名数据库把这些状态做成了字段：主名、并行名、名称变体、历史记录，每条记录还带语言代码。

这个数据结构值得抄。它告诉你一件事：地名不是一个字符串字段，是一张带语言标签和状态标签的关系表。你的商品数据库里如果只给城市留了一个varchar字段，那从一开始就装不下这件事。

历史名还有一个特殊用途：它是判断内容受众年龄的旁证。如果你的日志里历史名的查询占比明显偏高，说明这批用户的年龄结构偏大，这条信息对选品和文案语气都有参考价值。

并行名还有一个容易踩的坑：两个名字在当地是有政治敏感度的，选哪个显示、以什么顺序显示，有时候不只是语言问题。这类地方最好按当地惯例来，别自己发明排序规则。

联合国推了五十年，为什么外来名一个都没少？

1972年那份决议是怎么写的

第二届联合国地名标准化会议通过了一项决议，请各国编制本国常用的外来地名清单，目的是逐步取消其中的一部分。

方向很明确：国际交流里应该尽量使用本地名，外来名越少越好。

这个出发点没错。地图上的一个地方对应两三个名字，对救灾、航运、邮政都是实打实的麻烦。

后续几十年里，专家组还开过专门的外来名工作组，出过好几份使用准则和判据文件。

换句话说，这是一场持续了半个世纪、有国际组织牵头、有各国测绘机构参与、有正式决议背书的标准化努力。以我们做技术的人的直觉，这么大的力气砸下去，问题早该收敛了。

值得注意的是，这份决议诞生的年代还没有搜索引擎。当时地名不统一的代价体现在邮件寄丢、航班标错、救灾队伍找错地方，而不是体现在一个页面能不能被找到。

五十年后清单反而更长

现实是外来名一个都没消失。英国人还在说Munich，意大利人还在说Monaco di Baviera。

甚至后来的工作组文件本身也把口径松了下来，从减少改成了讨论在什么条件下使用外来名是合适的。

原因不复杂：外来名不是行政机构发明的，它是自然语言的一部分，跟这门语言的词汇一起长出来的。

你可以规定官方地图上印什么，规定不了一个人跟朋友说话时用哪个词，更规定不了他在搜索框里打什么。

这件事对我们的启发比对地图学界的更大：存在一个官方标准，不等于用户会按标准输入。半个世纪的国际标准化努力都没能改掉人们嘴里的那个词，你那份内部命名规范凭什么能？

专家组后来专门设了一个外来名工作组，从工作文件的措辞变化能清楚看到口径的软化：早期讨论的是怎么减少，后来讨论的是在什么场景下使用是合适的。

这条演化线索对我们有个直接用处：既然连专门做这件事的国际组织都放弃了统一，那内部再有人提议全站只用一种写法时，你就有了一个现成的例子可以引。

标准化管得住地图，管不住搜索框

这就把地名分成了两个世界。

一个是行政世界：地图、邮政编码、海关申报、法律文书，这里用本地名或者官方转写，规则清晰。

另一个是用户世界：搜索框、口头交流、社交媒体、客服对话，这里用的是他母语里最顺口的那个词。

你的网站很不幸地同时站在两个世界里。结账地址字段属于前者，配送页标题属于后者。

把两个世界的规则搞混，就会出现这种局面：面向用户的标题用了严谨的本地名，用户搜不到；而地址库里存的是用户随手打的外来名，海关那边对不上。两头都不讨好，而且两个错误的方向正好相反。

这条规律不只适用于地名。凡是标准由机构制定、使用由个人决定的东西，标准都只能约束到机构自己能管到的那一段，剩下的部分你只能观察和适配。

一个地名到底会长出几种形态？

先把清单列全

做这件事之前，得先知道自己要装多少种东西。

第一种是本地名，当地官方语言里的写法，比如München。

第二种是目标市场语言里的外来名，比如英语的Munich、意大利语的Monaco di Baviera。

第三种是转写形态，从非拉丁字母系统机械映射过来的，比如Москва转成Moskva。

第四种是历史名与旧称，比如今天的城市在几十年前叫过另一个名字，这批词在年长用户和历史类查询里还有量。第五种是俗称和缩写，纽约的NYC、慕尼黑的Minga这种，前者进搜索量极大，后者只在本地人之间流通。

这五种形态不必都做，但必须都知道。漏掉哪一种是决策，没意识到还有那一种是事故，两者的区别在于前者你至少知道自己丢了什么。

屈折语里还要再乘一次

如果目标市场说的是波兰语、俄语、芬兰语这类语言，上面每一种形态都还要再乘上变格。

华沙在波兰语里是Warszawa，但用户搜发往华沙的配送时，句子里出现的是do Warszawy；说在华沙有门店时是w Warszawie。

三种形态里，词典形只占一种，而用户的实际查询大量落在另外两种上。

芬兰语更狠，位置格有六个，每一个都能出现在真实查询里。

这一层在如果波兰语SEO只按词典原形选词和芬兰语SEO的十五个格只是开胃菜两篇里讲的是普通名词，地名的处理完全一样，唯一的区别是地名的变格更没法靠词干还原兜住，因为词干还原器的词典里往往没收全地名。

这里有个反直觉的地方：变格反而让地名比普通名词更难处理。普通名词的词干还原器有词典兜底，而地名往往不在词典里，还原器会把它当作未知词原样输出。

还有一个特殊情况：有些城市名在语法上被当作复数或者带冠词，变格规则跟普通地名不一样。这类词数量不多，但常常正好是首都或者大城市，也就是量最大的那几个。

俗称和缩写要不要收

要收，但要分开放。

缩写型俗称的搜索量常常大得出人意料，尤其是大城市和机场代码。

本地俚语型的俗称则要谨慎，它带着强烈的圈内人色彩，品牌用不好会显得刻意。

我的做法是：俗称收进匹配层和站内搜索的同义词表，但不写进标题和正文。

这条界线其实适用于所有非官方形态：能被搜到就行，不必非要显示出来。匹配层和展示层是两件事，混在一起的结果通常是页面上堆了一串别名，读着像关键词填充，用户看着糊涂，搜索引擎也不见得领情。

机场代码是个例外，值得单独收进展示层。它短、无歧义、在旅行相关品类里的搜索量极大，而且用户就是拿它当城市名在用的。

用户到底会搜哪一个名字？

本国用户：几乎只用本地名

德国人搜德国城市，用的一定是München。这一点没有悬念。

唯一的变数是变音符号打不打，这属于另一个问题，德语SEO最先卡住的不是技术那篇里讲过Muenchen这种替代写法要不要覆盖。

所以做本国市场的地区页，本地名是唯一答案，不用纠结。

要留意的是本国用户里的外来人口，他们可能用自己母语的外来名去搜，尤其是刚落地不久的。

这批人在跨境电商里的价值往往比人数占比高得多，因为他们更习惯网购、更少受本地零售渠道覆盖。判断要不要为他们单独铺一层内容，看你的品类跟这批人群的重合度，而不是看他们在总人口里占几个百分点。

还有一种本国场景要留意：官方名刚刚改过的地方。改名之后的头几年，旧名字的搜索量会明显高于新名字，而你的数据源多半已经更新成新名字了。

外国用户：几乎只用自己语言的外来名

反过来也一样。一个意大利买家搜德国某座城市的时候，脑子里蹦出来的是Monaco di Baviera。

他不会先在心里把它换算成德语。事实上他大概率根本不知道德语原名长什么样。

这就是为什么面向外国市场的页面必须用外来名：那是用户唯一认得的词。

而这恰恰是最容易做反的地方，因为团队里总有人觉得用本地名更专业、更尊重当地。

这里有个很实际的折中：标题和描述里用外来名，正文第一次出现时用外来名加括号带上本地名。既接住了搜索，又给了想核对的用户一个锚点，还顺手把两种写法都放进了页面。

这里有个常见的误判：团队里懂那门语言的人往往就是本地人，他的直觉是本地名，于是他会真诚地建议你用本地名。他没有错，他只是不在目标受众里。

还有一个可以立刻检查的地方：你的多语言站点切换器上写的城市名是哪一套。那个组件通常是最早做、最少改的，很可能还停留在最初那份英文列表上。

侨民与跨境买家：两个词都用

还有一批人处在中间地带。

比如住在德国的意大利人，找意大利食品的时候可能用意大利语搜，但城市名会用德语的。

这种混搭很常见，也很难靠规则预测。

好在它不需要你猜，站内搜索日志里能直接看到。

这批混搭查询是判断一个市场要不要单独铺内容的好信号：如果某个城市的两种写法在你的日志里都有可观的量，说明你的用户结构本身就是混的，那两种写法都得在页面上有落点，而不是二选一。

这类混搭还有个规律：品类词跟着母语走，地名跟着居住地走。因为品类是他从小就会说的词，而这座城市是他搬来之后才学会怎么念的。

怎么用数据判断，而不是靠感觉

最直接的办法是拿两个写法各自去查搜索量，比大小。

但小语种的工具数据往往不可靠，小语种关键词工具返回的那个零是数据缺口里讲过这个坑。

更稳的替代品有三个：站内搜索日志、搜索建议里出现的是哪个写法、以及本地媒体和本地竞品页面上用的是哪个写法。

第三个尤其好用，因为本地媒体没有动机去迁就任何标准，他们只写读者认得的词。

把这三个信号放在一起，结论通常非常清楚，甚至清楚到不需要争论。真正会吵起来的情况只有一种：两个写法量差不多。这时候别选，两个都上，一个进标题一个进正文，成本也就多一行字。

还有一个几乎零成本的信号源：本地的天气预报和交通播报页面。这类内容面向的是最广泛的本地受众，用词保守到接近默认值，拿它当基准非常合适。

另外提醒一句，看竞品的时候要看本土竞品，不要看同样是外来者的那几家。外来者之间常常在互相抄同一份错误的城市列表，你抄他他抄你，最后所有人都写着同一批用户看不懂的名字。

哪些页面会被地名这件事咬到？

配送与运费页

这是重灾区，因为它天然要列一堆城市名。

而且这类页面的查询意图极强：用户搜发往某某城市要几天，是准备下单了。

这类页面还有个特点，它经常是全站唯一提到那些城市名的地方，所以一旦写错形态，整个城市维度的流量就全丢了，没有别的页面能兜住。

做法上建议把城市列表做成结构化的数据，而不是硬编码在一段文案里，这样换形态、加别名都只需要改数据。

顺带一提，配送时效表这种内容天生适合做成表格，而表格里的城市名列如果同时放本地名和目标语言外来名两列，等于免费获得了一份对照表，用户看着也踏实。

配送页还有一个容易忽略的角落：运费计算器里的城市下拉列表。那份列表的取值往往来自物流商接口，用的是官方名或者英文名，跟页面正文用的词经常不是一套。

配送页上还有个隐蔽位置容易被漏掉：结构化标注里的服务区域字段。那里的取值如果跟正文用词不一致，机器读到的服务范围跟用户读到的就不是同一份。

门店、服务范围与本地落地页

有实体网点或者按区域服务的生意，这一层的地名密度最高。

这里要提醒一句边界：门店在地图上的排名、评价管理、本地商户信息那一套，属于本地搜索的活儿，不在语言层这篇的范围里。

语言层要管的只有一件事：你的页面标题和正文里那个城市名，是不是用户会打出来的那个词。

两件事经常被混着讨论，结果是本地SEO顾问在优化地图信息，而页面标题里那个词从头到尾都是错的，谁也没管。

分工可以很简单：地图和商户资料交给本地搜索那条线，页面上出现的每一个地名形态交给语言层这条线，两边共用同一份别名表。

共用一份别名表这件事有个前提：这份表得有明确的归属人。散落在几个部门各自维护的地名表，用不了半年就会各自漂移，到时候连哪份是对的都说不清。

地区落地页的批量生成

很多站会按城市批量生成落地页，模板一套，城市名一换。

这个做法本身没问题，问题在于变量取值。如果你的城市列表是从英文数据源拉的，生成出来的就是一整批带外来名的页面。

更糟的是这类页面往往几百上千个，错了是成批错。

而且模板生成的页面本来就在重复内容的边缘，再加上地名形态不对，双重问题叠在一起，很容易整批表现不佳却查不出原因。

批量生成之前先把城市表校一遍，这个动作花的时间远比事后逐页修改少。校的办法也很土：把列表丢给本地同事，让他标出哪些看着别扭，一般十分钟就能圈出问题项。

批量生成还有一个隐患：模板里的城市名往往同时出现在标题、正文、面包屑和URL里。地名一旦取错，这四处会一起错，而URL错了之后改动的代价最大。

批量生成还有一个补救办法：先只生成流量最大的二十个城市页，跑一个月看数据，再决定要不要铺开。这样即使地名形态选错了，返工范围也只有二十页。

地址表单与结账流程

这里的规则跟前面完全相反：表单要的是能对上物流和海关的那个形态。

用户在城市栏里打什么都可能，你需要的是能把它归一到官方名的能力。

做法是给输入框配自动补全，用一份带别名的地名数据源做后端匹配，用户打外来名也能选中正确的条目。

这一层跟展示层的目标不同：展示层要迎合用户的词，数据层要收敛到唯一值。

把这两件事分清楚，你的地名工作就成功了一半。剩下的一半是别让它们互相污染——展示层的别名不能写进订单数据，数据层的官方名也不该原样搬到面向用户的标题里。

自动补全的数据源建议直接用公开地名库的别名字段，别自己手工维护。公开地名库提供整包下载，里面每个地点都挂着一张多语言别名表，导进来做后端匹配足够用了。

地名进了屈折语，还会再变一次形吗？

波兰语：介词决定用哪个词尾

华沙的词典形是Warszawa，但它几乎不会以这个形态出现在真实句子里。

发往华沙是do Warszawy，在华沙是w Warszawie，从华沙出发是z Warszawy。

用户搜配送信息的时候，打的往往就是带介词的那个片段，因为那是他脑子里那句话的样子。

你的页面上如果只有词典形，字符串就对不上。

处理办法跟普通名词一致：标题里保留词典形当锚，正文里自然地把常见的两三个变格形态用进句子里。不必穷举，波兰语地名的高频组合就是介词加位置格那几种，覆盖它们能接住绝大部分查询。

一个实用的小技巧：把常见介词加地名的组合直接丢进搜索框看补全建议，出现在建议里的那几种就是高频形态，不用去啃语法书。

芬兰语：位置格有六个，地名还带自己的例外

芬兰语的地名要额外小心，因为它有一条外人很难预料的规则：不同城市用的位置格不一样。

有些城市用内部格，有些用外部格，这件事没有规律可循，是约定俗成的。

本地人从来不会搞错，外来的内容团队百分之百会搞错。

而且这个错误特别刺眼，芬兰读者一眼就能看出这段内容不是本地人写的。

这类问题没有技术解，只有流程解：地名相关的句子必须走母语审校，而且审校简报里要专门点出这一项，否则审校也可能把注意力全放在措辞上，顺手就放过了。

这类问题还有个副作用是它会连累品牌观感。用户读到一句语法别扭的本地话，第一反应不是这家公司不懂语法，而是这家公司不在本地，后面的信任成本都要跟着涨。

顺带说一句，这类语法细节最好整理成审校清单里的具体条目，而不是笼统地写一句请注意地名用法。清单越具体，审校漏掉的概率越低。

标题该写哪一个形态

我的建议是标题写词典形，正文承担变格形态。

理由有两条。词典形是这个城市的规范名，放标题里最稳妥，也最容易被各种匹配逻辑对上。

变格形态数量多且分散，硬塞进标题会把标题写得很别扭，而标题的可读性直接影响点击。

正文则没有这个限制，它可以自然地把几种形态铺开，而且读起来更像本地人写的。

这条分工跟我在屈折语站的锚文本报告里给锚文本定的规则是一致的：锚点位置守规范形，正文位置放自然形态。地名只是把同一条规则又用了一遍。

还有一个细节：面包屑和筛选器里的地名建议一律用词典形。这两处是导航元素，一致性比自然度更重要，读者在这里要的是快速定位而不是流畅阅读。

地名字段在数据源里该按哪一套填？

先看看现成的数据源提供了什么

你不需要自己造这份数据。

Unicode的本地化数据项目为每门语言维护了一份国家和地区名称的翻译，这份数据的存在本身就说明了问题：连国际标准组织都承认，同一个地方在每门语言里要各存一份名字。

更细一级的城市名，可以用公开的地名数据库，它们通常会给每个地点存一张别名表，每条别名带语言代码。

爱沙尼亚语言研究所那套外来地名数据库还额外标了名称状态，能区分主名、并行名、变体和历史记录。

把这几样组合起来，你能拿到一份相当完整的底表，剩下的工作是筛掉不需要的语言、补上自己业务相关的俗称。

这份数据的翻译指南里有一条很值得抄的原则：译名要采用目标语言里当地通行的说法，而不是从英文直译过来。这正是外来名的处理逻辑。

结构化数据里填哪个

填官方名，也就是本地名。

结构化数据是给机器读的，它的作用是把你的页面跟一个确定的实体对上号，所以要的是规范值。

这跟正文用外来名并不冲突。正文迎合用户的词，标记指向唯一的实体，两条线各走各的。

这个原则我在国际化SEO最难的不是hreflang里讲跨语言实体对齐时展开过，地名是那件事里最典型的一类实体。

如果你的标记体系支持给地点挂上外部标识符，那就挂上。有了唯一标识符，多语言之间的对齐就不再依赖字符串比对，这是所有跨语言实体问题里最省事的一条路。

如果同一个页面确实要覆盖多个地点，别把它们塞进一个字段里用顿号隔开。那样机器读到的是一个包含多个地名的字符串，等于哪个实体都没对上。

另外要注意标记里的地址字段和正文里的地址展示是两回事。前者服务于机器识别，后者服务于用户核对，两边完全可以写不同的形态，也确实应该写不同的形态。

自建别名表要留哪几列

最少五列：唯一标识符、语言代码、名称写法、名称状态、是否可展示。

唯一标识符把所有写法拴在同一个地点上，这是整张表的骨架。

名称状态区分官方名、外来名、历史名、俗称。是否可展示决定它能不能出现在面向用户的文案里，俗称通常只匹配不展示。

加上变格形态的话，再多一列形态类型即可，不必为每个格单开一列。

这张表建完之后，配送页、落地页模板、站内搜索同义词、表单自动补全全都从它取值。这是它真正的价值所在：地名不再散落在几十个页面的硬编码文案里，而是收敛成了一个可以被审核、被复核、被一次性修正的数据源。

这张表还建议加一列来源，标明每条别名是从公开数据库来的还是团队自己补的。半年后复核时，这一列能让你迅速分清哪些可以跟着上游更新，哪些是自己的私货。

这跟品牌名转写是同一件事吗？

品牌名你能规定，地名规定不了

我在做小语种SEO，品牌名叫什么不由你定里讲过一个结论：品牌名进了小语种市场会长出好几种写法，你要做的是挑一种作为官方写法，然后在站内保持一致、对外部持续纠偏。

那件事的前提是你拥有这个名字。你可以发一份品牌规范，可以要求经销商照着写，可以跟媒体沟通。

地名没有这个前提。你不拥有慕尼黑这个名字，谁都不拥有。

所以两件事的动作方向正好相反：品牌名是收敛，把多种写法收成一种；地名是发散，承认多种写法都对，然后按市场分别落地。

把地名当品牌名处理的团队，通常会做出一个很自洽也很没用的决定：全站统一用本地名，理由是尊重当地。结果是尊重了当地，丢掉了外地的搜索。

这个对比还能推广到别的字段：凡是你拥有的东西就收敛成一种写法，凡是公共的东西就承认多种写法并存。品牌名、型号、专有服务名属于前者，地名、品类通名、法规名称属于后者。

外来名不是音译，这一点必须说清楚

品牌名进日语变成片假名，那是音译，音是能对上的。

Köln变成Cologne不是音译。这两个词的读音差得很远，它们是同一个源头在两门语言里各自演化了几百年的结果。

这个区别的实际后果是：音译可以靠规则批量生成并人工校准，外来名只能查表，一个都推不出来。

凡是有人跟你说写个脚本自动处理一下，你就知道他把这两件事搞混了。

唯一能自动处理的部分是转写，也就是字母系统之间的机械映射。而那部分恰好是最不容易出流量问题的部分，因为转写形态本来就很少有人拿去搜。

顺带一提，同一座城市在不同语言里的外来名之间也没有关系。意大利语的说法推不出捷克语的说法，它们各自是各自语言的历史产物，所以别指望做完一个市场能省下另一个的功夫。

这一点在做多市场排期时特别重要：地名工作量是按目标语言数量线性增长的，不会因为你已经做过几个市场而变便宜，做预算的时候别按经验值往下压。

两件事的交付物完全不同

品牌名那件事的交付物是一份规范加一套监控：规定写法，然后盯着外部世界有没有写错。

地名这件事的交付物是一张多对多的别名表，加上一条按市场取值的规则。

前者的成功标志是外面的世界慢慢向你的写法靠拢，后者永远不会收敛，你只能一直维护那张表。

接受这一点很重要，否则你会不断想去统一它，而每一次统一都会牺牲掉一批市场的可见性。

说得更直白些：品牌名那件事有完成的一天，地名这件事没有。它是一项常设维护，跟商品目录一样，只要你还在开新市场，它就还要接着长。

还有一条实际差别：品牌名写错了会有人来提醒你，因为那是你的名字，同事和经销商都会注意到；地名写错了没有人会提醒，因为对每个市场的用户来说，他只是没搜到你而已。

所以这件事在内部争取资源时的说法要变一变：它不是一次优化，而是补一个从来没建过的字段。把它说成优化，排期上永远排在别的优化后面；说成缺字段，它就变成了一件该补的基础工作。

一份地名字段的落地清单

三步就能起步

第一步盘点：把全站出现过城市名的位置列出来，通常是配送页、地区落地页、门店页、表单、结构化数据这五类。

第二步建表：拿公开地名数据源做底表，筛出你要做的市场语言，补上业务相关的俗称，标好可展示状态。

第三步分层落地：展示层按市场语言取外来名，数据层和标记层取官方名，匹配层把所有形态都收进去。

三步做完，剩下的就是把模板改成从表里取值，而不是硬编码。

如果你的时间只够做一件事，那就做匹配层——把所有别名塞进站内搜索的同义词表。这一步不改任何一个页面，见效却最快，因为它直接把原本搜不到东西的用户接住了。

盘点这一步建议用全站搜索直接找，把主要城市名当关键词在自己的内容库里搜一遍。这个笨办法能翻出很多你根本不知道存在的老页面，那些页面往往就是历史遗留形态的重灾区。

验收看什么

看三个数就够。

第一个是配送页和地区页的进站查询里，有多少条带着地名，其中本地名和外来名各占多少。

第二个是站内搜索里地名类查询的零结果率。

第三个是地址表单的填写失败率或者人工修正率，它能反映数据层的归一做得好不好。

这三个数分别对应展示层、匹配层和数据层，覆盖了这件事的全部三个面。如果只能盯一个，盯第二个，它最灵敏，改动一上线当周就会动。

还可以补一个定性检查：把几个主力城市的页面标题拿给本地同事看，问他这行字读起来像不像本地媒体写的。这个问题比任何指标都更能快速暴露形态选错的情况。

另外还可以看一个软指标：客服有没有再收到找不到某某城市配送信息的咨询。这类咨询数量下降，说明改动真的落到了用户那一侧。

什么情况下可以不做

只做本国市场、且这个国家单一官方语言的，基本可以跳过，你的地名形态只有一种。

纯线上交付、跟地理位置无关的生意也可以跳过，比如软件订阅。

但只要你有实物配送、有服务范围、有线下网点，或者要做多个语言市场，这件事就迟早会找上门。

它的特点是不紧急但持续漏水，每天漏一点，年底一看是个不小的数。

判断优先级的办法很实用：去日志里数一数带地名的查询占比。超过一成就该排进这个季度，低于百分之三可以放到明年，中间的看你有没有正在开的新市场——如果有，那这件事最好在开市场之前就做完，事后补的成本是事前的好几倍。

另外提醒一句，判断的时候别只看当下。如果你的路线图里有跨语言市场的计划，那这件事的优先级要按未来一年的地图算，而不是按今天的流量结构算。

常见问题解答

页面上同时写两个名字，会不会显得啰嗦？

不会，前提是只在第一次出现时并列。通行的写法是主用目标市场语言的外来名，第一次出现时用括号带上本地名，后面全篇只用一种。这样读者读到括号那一下就完成了对照，之后不再被打断。真正显得啰嗦的是另一种做法：每次提到这座城市都把两个名字都写上，或者在页面底部堆一串别名。后者尤其要避免，它读起来像关键词填充，对用户没有任何帮助。

记住匹配层和展示层是分开的，别名的容身之处在站内搜索的同义词表里，不在页面正文里。另外，如果页面上要列多个城市，用表格比用一串顿号连接的文字好得多，一列本地名一列外来名，读者对照起来一目了然，也顺手把两种写法都放进了页面。

用自动转写脚本能不能把外来名生成出来？

不能，这是这件事上最常见的误解。转写是字母系统之间的机械映射，有规则、可以写成代码；外来名是另一门语言几百年里自己形成的词，跟本地名之间没有任何字符级的对应关系。Köln和Cologne、München和Monaco di Baviera，你写多少行代码都推不出来。

能自动处理的只有转写那一段，而转写形态在搜索里的量通常很小。外来名唯一的获取途径是查表，用公开地名数据库的别名字段做底表，再按自己的市场筛一遍。真要自动化，能自动的只有一件事：从公开地名库把别名批量拉下来入库，那是数据搬运，不是名称生成。

本地名和外来名的量差不多，该选哪个？

都上，不用选。标题用其中一个，另一个放在正文第一段和页面描述里，成本只是多一行字，却能同时接住两批查询。真正需要做选择的场景只有一个：标题长度不够放下两个。这时候按目标市场来定，面向本国用户就用本地名，面向外国用户就用外来名。判断依据不要靠感觉，用三个信号交叉验证：站内搜索日志里两种写法各出现多少次、搜索建议里补出来的是哪一个、以及本地媒体和本地竞品页面上写的是哪一个。

第三个信号最可靠，因为本地媒体只写读者认得的词。还有一种偷懒但合理的做法：标题用外来名，页面主图的说明文字里放本地名，两处都占住，视觉上又不显得重复。

屈折语市场的地名，要把所有变格形态都写进页面吗？

不需要穷举，覆盖高频组合就够。波兰语里真正高频的是介词加位置格那几种，比如发往某地、在某地，把这两三种自然地写进正文句子里，就能接住大部分查询。标题保留词典形当锚点，正文承担变格形态，这个分工跟内链锚文本的处理原则是一致的。芬兰语要额外小心，不同城市习惯用不同的位置格，这件事没有规律可循，本地人从不会错，外来团队几乎必错，所以地名相关的句子一定要走母语审校，并且在审校简报里专门点出这一项。

另外别忘了页面描述里也要出现一次，那段文字虽然不直接决定排名，但它是用户在结果页上读到的第二行字，形态对不上会明显影响点击。

结构化数据里该填本地名还是外来名？

填本地名，也就是官方名。结构化数据是给机器读的，作用是把页面跟一个确定的实体对上号，需要的是规范值而不是用户习惯用的词。这跟正文用外来名并不矛盾：正文迎合用户的表达，标记指向唯一实体，两条线各走各的，互不干扰。如果你的标记体系支持挂外部标识符，务必挂上，有了唯一标识符之后，多语言之间的实体对齐就不再依赖字符串比对，这是跨语言实体问题里最省事的一条路。如果你的标记里能填多个名称字段，把常用的别名作为替代名称一起填上也无妨，前提是主名字段仍然是官方名。

只做一个国家的市场，还需要管这件事吗？

如果这个国家只有一门官方语言，且你的用户基本都是本国人，那基本可以跳过，地名形态只有一种。但有两个例外值得留意。一是本国的外来人口，他们可能用母语的外来名去搜，这批人在跨境电商里的价值往往高于人口占比。二是多语言国家，比利时、瑞士、加拿大这类地方，同一个地点在两门官方语言里各有一个名字，那是并行名，两个都是官方的，两个都得管。判断办法还是去站内日志里数，看有没有非本地名写法的查询进来。判断标准可以简化成一句话：只要你的用户里有人的母语不是这个国家的官方语言，这件事就已经开始影响你了。

这件事该排在什么优先级？

用日志里带地名的查询占比来定。超过一成就排进这个季度，低于百分之三可以往后放，中间地带看有没有正在筹备的新市场。有新市场就在开市场之前做完，因为事后修改要动的是已经生成的成百上千个地区页，成本是事前的好几倍。这件事的典型特征是不紧急但持续漏水，每天漏一点，攒到年底是个不小的数字，而且因为没有任何工具会报错，它可以安安静静漏很多年都没人发现。最后提醒一点：这件事的收益不会体现在某个词的排名上，而是体现在一批长尾查询的整体可见性上，所以别用单词排名去验收它。