德语商品页上那个短横替掉了半个词，分词器切出来的是不存在的词

摘要：德语商品页写“夏季和冬季款”时，正字法要求把前一个词写成一个短横加半截词。于是完整复合词在整页上一次都没出现，而用户搜的正是那个完整词。这个短横删不得，删了就是错别字。芬兰语的列举把形容词和名词拉开两个词，阿拉伯语的连词直接粘掉一个词头，模板里写死的那个逗号在每门语言里规则都不同。本文把列举结构造成的关键词缺口拆成四类，给出不动正字法也能把词补回来的三个位置。

商品页上最常见的那个句法结构，为什么最容易出问题？

从一个德国母婴站的季节配件说起

那是一家做德国市场的母婴用品站，主推婴儿车配件。

其中一类是脚套，分夏季款和冬季款两种。

德语商品标题写的是Sommer- und Winterfußsäcke。

这一行读起来毫无问题，德国同事也确认写法完全规范。

可是搜索表现一直不对劲：冬季款的词有排名，夏季款几乎为零。

后来把整页的源码搜了一遍才发现，Sommerfußsack这个完整词在页面上一次都没有出现过。页面上出现的是Sommer- 加一个短横，然后跳到了und。而用户在搜索框里打的，从来都是那个完整的复合词。整整一个季度，这条产品线在德语搜索里等于不存在。

最讽刺的是，这个写法不仅没错，还是德语正字法明确要求的那一种。

这个站后来把德语站上所有带省略连字符的标题都导了一遍，一共一百四十多条，其中六十几条的省略半截都是有独立搜索量的完整词。也就是说这不是一条产品线的偶发问题，是整个德语站的系统性缺口，只是从来没有人从这个角度数过。

列举在商品页上的密度有多高

先说清楚这件事的量级，不然听着像个边角问题。

把一个典型的商品详情页拆开数一遍，列举结构的密度高得吓人。

标题里有并列的品类，属性区有并列的颜色和尺码。

卖点段落里有并列的材质，适用场景那一段几乎整段都是列举。

配送与保障那一块，也是一串用顿号或者逗号连起来的短语。

粗略数下来，一个商品页上百分之四十以上的名词短语都出现在某种并列结构里。这个比例在分类页和筛选页上还要更高，因为那两类页面的正文本来就少，剩下的几乎全是列表。换句话说，列举不是一种偶尔出现的句式，它是商品页的主要句式。

一种句式如果占了页面上大半的名词，它一旦出问题，问题就不会是局部的。

还有一个容易被忽略的加权因素：列举结构最集中的地方，恰好是页面上权重最高的几个位置。标题、属性区、面包屑这些地方字数少、被引用多，一处缺口的影响远大于正文段落里的同类缺口。密度高再叠上位置好，损失就被放大了两次。

顺便说一句，列举密度还能当成一个粗糙的风险指标用。把各个模板的正文抓下来，数一数并列连词和分隔符的出现频次，频次最高的那几个模板就是这类缺口最集中的地方。排查从它们开始，比按品类逐个翻页面效率高得多。

这不是排版问题也不是翻译质量问题

这类现象很容易被归到两个错误的抽屉里。

第一个抽屉叫排版：有人会说这是前端的显示格式，改样式就行。

可这个短横不在样式表里，它在字符串里，是正文的一部分。

第二个抽屉叫翻译质量：有人会说是译者偷懒省了字。

可事实正相反，写完整反而是不规范的。

把两个抽屉都排除掉之后，剩下的那个位置很不舒服：这是一个人人都做对了、但结果对你不利的情形。母语审校验收清单那篇讲过一句读着自然不能当作验收通过的判据，这里是同一条规律的另一个面：一句写得完全规范，同样不能当作验收通过的判据。

规范和有效，在这一层第一次公开地分了家。

把它归错抽屉的代价不只是修不好，还会把责任推给不该负责的人。归到排版就去找前端，前端查完样式表说没问题；归到翻译就去找译者，译者拿出规则集说写法没错。两轮下来问题还在，团队里却先积了一层互相怀疑。

判据：页面上的字符串和页面表达的概念对不对得上

这类问题需要一把简单的尺子，不然每次都要争论。

这把尺子只有一句话：页面上出现的字符串，和页面想表达的那个概念，是不是同一串字符。

正文里可以模糊，标题里可以简略，这两处从来不要求严格相等。

但用户在搜索框里打出来的那一串，是要跟索引里的字符串对上的。

列举结构是唯一一类会让这两者系统性不相等的句法结构，而且不是偶然不相等。

是规范要求它们不相等。这一点跟别的坑都不一样：别的坑修一修就好了，这个坑修了会变成新的错。颜色范畴与属性值那篇讲过枚举值是全站唯一一处必须严格相等的地方，而列举结构恰好是把严格相等打破得最理直气壮的地方。

两条规律撞在一起，撞点就在商品页上。

这把尺子还有一个附带好处，它能顺手识别出另一批表面无关的问题。凡是页面上用缩写、代称、省略指代来避免重复的地方，都会在同一把尺子下现形。重复本身在写作上是缺点，在检索上却常常是优点，这个矛盾在中文站上一样存在。

德语那个短横为什么不能删？

补充连字符是正字法规定的写法

德语里这个短横有正式名字，叫补充连字符。

它的作用是在并列的复合词里，替掉重复的那一半。

Sommer- und Winterfußsäcke的意思是夏季脚套和冬季脚套。

两个复合词的后半截都是Fußsäcke，重复写一遍在德语里被视为累赘。

于是前一个词只保留自己独有的那半截，剩下的用一个短横顶替。

这个规则写在德语正字法官方规则集里，不是某本风格指南的偏好，而是所有德语出版物共同遵守的硬规则。Duden的补充连字符词条把用法和例子列得很清楚，包括前置省略和后置省略两种方向。

换句话说，这不是一个可以商量的写法。

省略的方向还分两种，前面省和后面省。Sommer- und Winterfußsäcke是省后半截，而Fußsäcke für Sommer und -winter这类写法则是省前半截，短横挂在词的左边。两种方向造成的残片形状不同，写检查脚本时得同时考虑，只匹配一种会漏掉一半。

删掉它是错别字，保留它是缺半个词

知道了这条规则之后，第一反应通常是把它改掉。

把Sommer- und Winterfußsäcke改成两个完整词并列，看起来就解决了。

问题是这么写在德语读者眼里是明显的笨拙，接近于错别字。

一个卖婴儿车配件的品牌，在标题上写出这种句子，信任感是要打折的。

所以这里没有一个两边都赢的改法，只有取舍。

更准确地说，这是一个把语言规范和检索需求摆在同一根轴上的局面：往任何一边挪都要付出另一边的代价。比较级与最高级那篇里出现过一次类似的对立，那次是搜索侧和合规侧在同一串字符上给出相反的评分，这次是搜索侧和语言规范。

凡是双方都在引外部依据的争论，都不是判断问题，只能找第三种做法。

真要衡量这个取舍，可以把它换算成一个能比较的数：改成完整并列之后，读者的观感损失是长期而弥散的，而不改的搜索损失是可以直接用那个词的搜索量估出来的。一边模糊一边清晰的时候，人总倾向于向清晰的那边妥协，这恰恰是最该警惕的地方。

母语审校为什么一次都不会提这件事

这条最容易让人意外。

母语审校的任务是判断这句话对不对、地道不地道。

而补充连字符的写法，既对又地道，属于标准答案。

审校员看到它只会打勾，不会觉得这里有任何需要说明的地方。

他甚至意识不到这是一个可以被提出来的问题。

这跟否定词缀那篇里的情形是同一类：凡是完全合规的写法，都不会触发任何一道质量关卡。质量关卡查的是错误，而这里没有错误，只有一个缺口。缺口和错误在流程上是两种东西，前者需要有人专门去找。

顺便说一句，这也是为什么这类问题往往是做SEO的人先发现的。

想把这件事纳入审校流程，靠加一条规则是没用的，因为审校员没有判断依据。可行的做法是把问题换个问法：不要问这句写得对不对，而是把那个完整词直接列给他，问这个词在这一页上出现过没有。问法一换，他立刻能回答，而且答案是二值的。

页面上没有的那个词，用户为什么在搜？

用户搜的是完整复合词

用户不会在搜索框里打出补充连字符。

他要买夏季脚套，打的就是Sommerfußsack。

没有人会打Sommer- und Winterfußsäcke去搜一个具体的东西。

这个不对称是这类问题的根源：写作端用省略式，检索端用完整式。

德语的复合词构词能力越强，这个不对称就越明显。

德语复合词那篇讲过德国人管这东西叫另一个词，那说的是选词层面的错位。这里的错位更靠后一步：词选对了，形态也对了，但那串字符被一个规范化的省略吃掉了一半。

选词错了还能查出来，这种缺口在词表里是查不出来的。

这个不对称还有一层：写作端的省略是为了避免重复，而检索端的重复恰恰是必要的。写作追求的简洁和检索需要的冗余，在复合词发达的语言上第一次直接冲突。英语站上很少遇到，因为英语的并列多是两个独立单词，省不掉什么东西。

分词器切出来的那个残片是什么

从索引侧看，这件事更清楚。

分词器读到Sommer- und Winterfußsäcke这一串。

短横在多数分词器眼里是词边界，于是它切出Sommer这个片段。

这个片段在德语里是一个真词，意思是夏天。

而Sommerfußsack这个组合，索引里根本没有。

更麻烦的是切出来的东西看起来一点都不可疑。Elasticsearch的分词器参考里，标准分词器对连字符的处理就是按词边界切开，这个行为本身没有任何毛病。首字母缩略语那篇讲过分词器把非字母字符当词边界这条规律，那次这条规律帮了倒忙，这次它同样帮了倒忙，只是方向反了过来。

你得到的不是一个坏词，而是一个正确的、无害的、完全不是你要的词。

这里还有一个更让人无从下手的地方：切出来的那个残片经常是本语言里的高频词。夏天这个词在德语站上到处都是，它在索引里的存在感不但不低，反而很高。于是你既看不到缺失，也看不到异常，只能看到一堆完全正常的高频词。

精确匹配、短语匹配和词干还原都救不了

接下来通常会有人问：加个词干还原是不是就好了。

答案是不行，而且理由值得说清楚。

词干还原处理的是同一个词的不同形态，比如单复数、格尾。

Sommer和Sommerfußsack不是同一个词的两种形态，是两个不同的词。

复合词拆分能帮上一点忙，但它的方向是把长词拆短，不是把短片段拼长。

换句话说，所有归一化手段都是做减法的，而这里需要的是加法。Solr的语言分析文档里德语的复合词处理器也是同一个取向，它能把Fußsäcke从长词里分出来，却没法把Sommer和Fußsack重新拼回去，因为它无从知道该拼哪一个。

工具的默认取向永远来自它诞生时的那个场景，这一条在关键词工具无数据那篇里已经验证过一次。

有人会想到用同义词表把残片映射到完整词，这条路在小范围内可行，但扩展性很差。因为映射关系依赖上下文：同一个Sommer- 在脚套页面上该映射成脚套，在睡袋页面上该映射成睡袋。一旦要按页面维护映射表，成本就超过了直接补一份完整写法。

这里还能引出一条更一般的判断：凡是需要靠上下文才能还原的信息，都不适合放进索引层去解决。索引层能做的是稳定的、与上下文无关的变换，一旦规则开始依赖页面语境，它的维护成本就会随页面数量线性增长，而收益却不会。

报表上看到的是搜索量正常但页面不出现

这类缺口在报表上的样子很有辨识度。

关键词工具会告诉你Sommerfußsack有搜索量，而且不低。

你的站有对应的商品，分类也对，页面也被收录了。

可这个词的展现次数接近于零，排名根本进不了前一百。

如果只看展现和点击，很容易误判成竞争太激烈。

识别办法其实很朴素：把那个词原样丢进站内搜索，如果自己的站都搜不到，那就不是竞争问题。站内搜索用的是同一套分词逻辑，它给出的空结果比任何外部工具都直接。这个动作十秒钟就能做完，却能把一整类误判挡在外面。

保哥后来把这一步固定成了新站上线前的例行检查，代价小到没有理由不做。

这种缺口在报表上还有一个更细的特征，值得记下来：同一个复合词族里，被省略的那一半排名极差，而没被省略的那一半排名正常。冬季款有排名夏季款没有，两个词的商业价值和竞争度却相差无几，这种不对称本身就是最强的信号。

跟看不见的软连字符比，这个坑差在哪儿？

一个能删一个不能删

德语站上还有另一个跟短横有关的坑，两者很容易混。

那个坑是前端为了让长词在手机上不撑破，往词中间塞了一个不可见字符。

两件事都跟连字符有关，都发生在德语长词上，都影响关键词匹配。

但它们在一个最关键的地方正好相反。

软连字符是可以删的，删掉之后页面完全正确，只是排版可能难看一点。

补充连字符不能删，删掉之后页面就有语法瑕疵了。软连字符那篇的结论是把不该出现的字符拿掉，本篇的结论只能是把该出现的字符留着，另外再补一份完整写法。同一类现象，两个相反的解法。

分清楚这一点，能省下很多把两件事混着修的力气。

这两个坑还有一个共同的迷惑点，它们都会让人先怀疑编码或者字体。看到词被切开的第一反应往往是字符集出了问题，于是去查数据库排序规则、查页面编码、查字体是否缺字形，一圈查下来什么都正常，才想到去看那个短横到底是什么东西。

一个在样式层能修一个只能在内容层修

还有一个差别在修补发生的位置。

软连字符那件事，正解是把断行交回给样式表。

换句话说，那个问题可以整体挪到样式层解决，字符串本身恢复干净。

补充连字符没有这条路，因为它承载的是语义不是版面。

它替掉的是半个真实的词，不是一个换行提示。

这就把可选的修补位置压到了内容层：要么改正文，要么在正文之外另找一个能放完整写法的地方。字符层、标记层、样式层这三层的撤销成本依次降低，而本篇这个坑一开始就落在最贵的那一层上。

知道自己在哪一层，比知道怎么修更重要。

这条分层判断可以推广到别的现象上：拿到一个跟字符有关的问题，先问它被删掉之后页面还对不对。删了仍然对的，属于表现层，成本低；删了就错的，属于内容层，只能靠增补。这一个问题就能把绝大多数字符类问题分到正确的处理路径上。

两者共用的判别办法

虽然解法相反，识别这两类问题的办法是同一个。

把页面正文原样复制出来，扔进一个纯文本编辑器。

然后搜索你希望这个页面命中的那个完整词。

搜不到，就说明页面表达了这个概念却没有写出这串字符。

至于原因是不可见字符还是省略连字符，看一眼那个位置就知道了。

这个检查的好处是不需要懂德语。执行的人只要会复制粘贴和按查找键，判据是二值的，没有任何主观空间。审校验收那篇提过一个原则，能交给不懂那门语言的人做的检查，才是能长期跑下去的检查。

凡是需要语感才能执行的规则，最后都会名存实亡。

这个检查还可以顺手做成批量的：把一批页面的正文抓下来存成纯文本，再拿一份必须命中的完整词清单逐行查找，输出没命中的行。二十行脚本就能跑完整站，而且完全不涉及语言判断。人只需要看那份没命中的清单，逐条判断该走哪一类修补。

芬兰语的列举把两个词拉开了多远？

每一项都要带格尾

换一门语言，列举的坑就换一种长相。

芬兰语里说黑色和白色的鞋，形容词要跟着名词一起变格。

写成mustat ja valkoiset kengät，三个词的词尾是一致的。

如果放进内格，整串就变成mustissa ja valkoisissa kengissä。

三个词全都换了词尾，中心词也不例外。

这意味着黑鞋这个组合在页面上从来不是两个相邻的词。芬兰语十五个格那篇讲的是单个词的形态爆炸，这里叠加了一层：形态爆炸之后，列举又把爆炸过的词彼此推远了。

一个词形对不上还能靠词干还原兜，两个词被拉开就没得兜了。

这里要注意一个反直觉的地方：芬兰语的形容词跟着变格并不是可选的修辞，而是强制的语法一致。写成不变格的形式不是风格问题而是语法错误。所以这条跟德语那个短横一样，属于不能靠改写规避的类型，只能在别处补。

邻近度算法假设它们相邻

这一层的损失落在匹配算法上。

短语匹配要求词按顺序相邻，中间隔一个词就不算命中。

邻近度打分宽松一些，但距离越远权重越低。

mustat kengät这个组合被ja valkoiset挤开了两个位置。

用户搜的却正是这两个词紧挨着的形式。

这是个很容易被算成运气不好的损失。锚文本变格那篇说过屈折语站的精确匹配那一栏数字是假的，那里的原因是词形变了，这里的原因是词被隔开了。两个原因加在一起，屈折语的短语匹配基本可以当成不存在。

报表上你只会看到一个偏低的数字，看不到它是被哪一种机制吃掉的。

还有一层损失落在用户自己身上：他在站内搜索里打黑鞋，如果站内搜索也用短语匹配，同样搜不到。于是这类页面在外部搜索和站内搜索上同时失分，而站内搜索的空结果率是个能直接看到的指标，往往比外部排名更早暴露问题。

列举越长，中心词离第一个修饰语越远

这个距离还会随着列举变长而变长。

列两种颜色，中心词离第一项两个位置。

列四种颜色，就变成六个位置。

而商品页上的颜色列举，四五项是很常见的。

芬兰语的官方逗号规则里，并列成分之间用逗号，最后一项前用ja，这跟德语的写法一致。

于是有一条很反直觉的推论：列举写得越完整，第一项跟中心词的匹配就越差。为了信息完整而多列几项，反而在检索侧扣分。这不是让人少写，而是说明这类信息不该只放在一串列举里。

顺带一提，这也解释了为什么筛选器里的属性值单独存一份是有必要的。

把这条推论写成可执行的规则就是：属性类信息不要只靠一串列举承载，同一份信息至少要有一处以中心词加单个修饰语的形式出现。这个要求听起来像是让人写重复的话，但重复的那一份可以放在结构化数据或者筛选值里，不必出现在正文上。

这条推论还解释了一个常见的困惑：为什么内容写得越详尽，某些长尾词的表现反而越差。答案是详尽通常意味着把更多信息压进同一句话，而压得越密，词与词之间的距离就越远。详尽和可匹配在这一层是有张力的，不是同一个方向。

阿拉伯语的连词为什么会吃掉一个词？

连词不加空格粘在下一个词头上

阿拉伯语给出了这一类问题里最极端的一个版本。

阿拉伯语表示和的连词是一个单独的字母，写作 و。

但它不像英语的and那样独立成词，它直接连写在后一个词的前面。

鞋这个词写作 الأحذية，加上连词就变成 والأحذية。

中间没有空格，视觉上就是一个更长的词。

结果是列举里的第二项、第三项，每一项的词头都多了一个字母。阿拉伯语SEO那篇整理过六个最容易翻车的地方，那些都跟方向有关，这一条跟方向无关，纯粹是构词。

用户搜的当然是不带连词的那个形式。

这个连写规则不只作用于连词，阿拉伯语里还有好几个单字母前缀是同样的写法，比如表示介词的那几个。也就是说列举只是暴露它的场合之一，凡是句子里出现这类前缀的位置，都会产生同样的粘连。列举之所以最明显，是因为列举里这类前缀出现得最密集。

分词器把它当成一个新词

分词器面对这一串，没有任何理由把开头那个字母切下来。

它看到的是一串连续的阿拉伯字母，中间没有空格也没有标点。

于是索引里多了一个 والأحذية，而 الأحذية 少了一次出现。

专门为阿拉伯语写的分析器会处理这类前缀，但默认分析器不会。

而多数站点上线时用的正是默认分析器。

这一条的普遍形态是：凡是靠空格判断词边界的机制，在把功能词连写进实词的语言里，都会把功能词算进实词。OpenSearch的文本分析文档里，语言专属分析器和默认分析器的差别在阿拉伯语这类语言上体现得最明显。

差别不在精度高低，而在于有没有那一步。

判断自己的站有没有踩这个坑，办法很直接：把同一个词带前缀和不带前缀的两种形式分别丢进站内搜索，看结果数是不是一样。如果带前缀的那个返回零条，而不带的那个正常，就说明分析器没有做前缀剥离这一步。这个测试三十秒能做完。

跟标点制造词边界正好方向相反

把这条跟前面德语那条并排放，会看到一个漂亮的对称。

德语那个短横，制造了一个不该有的词边界，于是词被切碎了。

阿拉伯语这个连词，消灭了一个该有的词边界，于是词被粘长了。

一个多切一刀，一个少切一刀。

两者的共同点是：分词器都完全按规则执行，没有一步做错。

由此可以提炼一条更一般的判据：在评估一门语言的列举结构之前，先问它是靠什么字符把并列项分开的，以及那个字符在别处还有没有别的身份。德语用的是空格加短横，短横还兼着省略的差事；阿拉伯语用的是一个直接连写的字母，它根本不占一个位置。

把这个问题问清楚，后面所有决定都会跟着变简单。

这对反向的例子还能推出一条更省事的做法：与其逐条排查每门语言的列举写法，不如先把每门语言的并列连接手段列成一张表，写清楚它占不占一个独立的位置。占位置的语言风险在切碎，不占位置的语言风险在粘连，两类的修补方向完全不同。

把这张表建起来还有个额外好处，它能让新语言上线的评估变成半小时的事。要开一门新语言的时候，先填这张表的三列：并列用什么连接、连接词占不占位置、列举项要不要变形。三列填完，这门语言在列举结构上的全部风险就已经摆在桌面上了。

模板里写死的那个逗号，该由谁决定？

德语und前不加逗号是规则

列举还有一个更少人注意的层面，是分隔符本身。

英语世界为了要不要在and前面加逗号吵了几十年。

德语没有这个争论，因为规则很明确：und前面不加逗号。

法语的et前面同样不加。

芬兰语的ja前面也不加。

Duden关于逗号的词条里把并列连词前不加逗号列为基本规则之一。这一条本身不值几个钱，值钱的是它带出来的一个事实：分隔符的规则由语言决定，而模板是全站共用的。

一个由代码写死的标点，撞上了一条按语言变化的规范。

这条规则在页面上的可见后果比想象中大。中文和英文的商品模板习惯在最后一项前加一个连词再加逗号，德语页面照搬之后，多出来的那个逗号在德国读者眼里是一个明确的标点错误。它不影响检索，但会让整页显得不是本地人做的。

日语中黑和中文顿号不是同一个符号

换到东亚语言，分隔符的分歧更大。

中文列举用顿号，写作、这个符号。

日语在外来语并列时习惯用中黑，写作・这个符号。

两者长得不像，码位不同，用法也不完全重叠。

日语里顿号也用，但用在不同的场合。

日语写法那篇讲过同一个概念的三套写法不是同一批人在搜，分隔符也有类似的分层效应。一个中日共用的商品模板如果把分隔符写死成半角逗号，两个市场的页面看起来都会有点怪，而怪的方向还不一样。

这类小事不会有人来投诉，它只是让页面显得不是本地人做的。

这两个符号还有一个技术上的差别值得记：中黑在很多分词器里被当作词内字符处理，而顿号被当作分隔符。也就是说用中黑连起来的两个外来语词有可能被切成一个长词，而用顿号连起来的会被正常切开。选错符号不只是观感问题。

模板变量拼出来的列举串

真正的麻烦出在模板拼串的那一行代码上。

典型写法是把属性数组用一个固定分隔符连起来。

这一行在英文站上跑了很多年，从来没出过事。

它默认了三件事：分隔符是逗号、最后一项前面有个and、各项之间不需要变形。

这三件事在德语上错两件，在芬兰语上三件全错。

更隐蔽的是，这行代码没有语言参数，所以它不是通用的，它是选了默认值的，而默认值来自英语。这条规律在大小写折叠那篇里第一次成立，在拼列举串这件事上第二次成立。

凡是没有语言参数的函数，都值得单独看一眼。

这一行代码还有一个更隐蔽的默认：它假设列举项的顺序是无所谓的。而在不少语言里，最后一项因为紧挨着连词，形态会跟前面几项不同。数组顺序一变，需要变形的那一项就换了人，模板却完全不知道自己漏掉了什么。

分隔符应该跟语言走还是跟模板走

知道有问题之后，还得决定改到什么程度。

把分隔符做成按语言配置，成本不高，一张表就够了。

但列举的整体写法要不要按语言改，是另一回事。

比如最后一项前用连词还是用符号，属于语言习惯。

再比如每一项要不要变格，那已经不是分隔符能解决的了。

保哥的做法是分两档：分隔符和连词进配置表，需要变形的列举一律不用模板拼。前者一次改完永久生效，后者交给内容侧写死在文案里。这条线画在哪里，取决于那门语言的列举项要不要跟着变形。

芬兰语、波兰语这类语言，模板拼列举基本上是走不通的。

这条线还有一个实际的划法，就是看这门语言的列举项要不要变形。不变形的语言可以放心用模板拼，只要把分隔符和连词做成配置；要变形的语言，模板拼出来的每一句都有语法瑕疵，不如一开始就交给文案写死。判断只需要问译者一句话。

拆成列表项之后，每一项就没有上下文了

列表项之间不共享中心词

还有一种常见的改法，是干脆把列举拆成列表。

把黑色白色灰色三项各放一行，看起来清爽多了。

移动端阅读体验确实更好，这一点没有争议。

但拆开之后，每一项都变成了一个独立的文本块。

黑色这一行里，没有鞋这个词。

MDN关于无序列表元素的说明里强调每个列表项是一个独立的内容块，这在结构上是优点，在检索上却意味着上下文被切断在了每一项的边界上。原本一句话里的修饰关系，拆完之后要靠读者自己补。

人补得上，机器不一定。

这个副作用在移动端尤其明显，因为移动端的列表往往还会折叠，只展开前三项。于是被折起来的那几项在页面源码里虽然存在，实际被抓到的上下文更少。可读性优化和可检索性优化在这里第一次分道扬镳，而前者通常有人负责，后者没有。

抽取式摘要拿到的是孤立词

这个副作用在被抽取的时候最明显。

一段被抽出来当答案的内容，往往只包含列表里的几项。

孤立的黑色两个字，脱离了它修饰的那个名词。

如果这一段被单独展示，读者看不出在说什么。

更糟的是这一段有可能根本不会被选中，因为它信息密度太低。

解法不是不用列表，而是让每一项自己带上中心词，或者在列表前那一句里把中心词说全。这个取舍在结构化数据那篇里也出现过，正文越本地化越好，机器读的那一份反而要写得笨一点。

笨一点的写法在这一层是优点。

要判断自己的列表会不会出这个问题，有个很土的办法：把任意一个列表项单独抄出来，念给一个没看过这个页面的人听，问他这在说什么。答不上来的，就说明这一项脱离上下文之后不成立。这个测试不需要任何工具，两分钟能测完一整页。

什么时候该用列表什么时候不该

这就需要一条能当场判断的标准。

如果每一项本身就是完整概念，用列表没问题。

比如配送方式、支付方式，每一项拿出来都能读懂。

如果每一项是修饰语，脱离中心词就没意义，那就不该拆。

颜色、尺码、材质这几类都属于后者。

一句话概括：列表适合并列的实体，不适合并列的属性。属性天生依附于别的词，把它单独立成一行，等于人为制造孤儿。这条判据不需要懂目标语言，看中文原稿就能判。

能在中文稿阶段判掉的问题，永远比翻完再修便宜。

这条判据还能反过来用，帮着决定哪些内容值得单独建页。凡是列表项本身就是完整概念的，它往往有独立的搜索需求，也就有独立成页的价值；凡是必须依附中心词才成立的，单独建页只会得到一批内容单薄且互相重复的页面。

这条判据在中文站上同样成立，只是表现得没那么剧烈。中文的属性词脱离中心词之后仍然勉强能读懂，所以问题被掩盖了。到了变格语言和复合词语言上，同样的写法会把损失放大好几倍，而写法本身是从中文原稿一路继承下来的。

三类修补：补写法、拆句子、绕开列举串

第一类：正文保留规范写法，另补一份完整写法

回到德语那个短横，正解已经很清楚了。

正文里的Sommer- und Winterfußsäcke一个字都不动。

另外找一个位置，把Sommerfußsack完整写一次。

这样规范和检索各拿各的，不需要互相让步。

关键是那个位置要既真实又不别扭。

能用的位置比想象中多：商品的完整名称字段、面包屑的末级、图片的替代文本、结构化数据里的商品名。图片替代文本那篇讲过同一张图的文件名和替代文本要用两套字母写同一个词，这里是同一个思路的另一种用法。

补一份，不是改一份。

补的时候有一个细节要守住：补进去的那个完整词必须是真实自然的用法，不能是把省略号强行还原出来的怪词。德语复合词的拼接有连接音的规则，还原时少一个字母就成了另一个不存在的词。这一步必须由母语者确认，是整套流程里唯一必须找人的环节。

第二类：把并列拆成独立短句

第二类修补适合正文段落里的列举。

如果一句话里塞了三个并列的复合词，读起来也累。

拆成两三个短句，每句只讲一件事。

拆完之后每个复合词都能写全，短横自然就没了。

这个改法的额外好处是段落变短，移动端更好读。

但它有边界：标题和属性区不能这么改，因为那两处本来就要求紧凑。所以第二类只在正文里用，第一类才是标题区的解法。两者分工明确，混用会让标题变得啰嗦。

凡是解法都有适用范围，写清楚适用范围比写解法本身更有用。

拆句子还有一个附带收益：拆开之后每个复合词都能带上自己的形容词和限定语，句子的信息密度反而提高了。原本挤在一串列举里的三个卖点，拆成三句之后各自都有了展开的空间，正文长度增加的同时可读性并没有下降。

第三类：筛选器和结构化数据不走列举串

第三类是从源头上绕开。

筛选器背后的取值，本来就不该来自正文里的那串列举。

它应该来自一份独立的属性表，每个值单独一行。

结构化数据里的字段同理，一个值一个字段。

这样正文怎么写都不会影响到机器读的那一份。

这条其实是在说一件更基本的事：凡是需要严格相等的数据，都不该从自然语言里现场解析。正文是给人读的，解析正文来填结构化字段，等于把语言习惯的所有不确定性引进了数据层。

把两条管道分开，是这一类问题最省事的一劳永逸做法。

这一类修补的真正难点不在技术，而在于说服。把筛选值从正文解析改成独立字段，通常要动数据模型，排期上不好插队。可以先用一个折中办法：保留现有解析逻辑，但给需要严格相等的那几个属性单独建表，先覆盖高价值的品类，再逐步扩大。

怎么在不动正字法的前提下把词补回来？

三个可以放完整写法的位置

把第一类修补说得再具体一点。

第一个位置是商品名称字段，也就是数据库里那个完整品名。

它通常不出现在标题上，但会进结构化数据和站内搜索索引。

第二个位置是详情段落的第一句，那里可以自然地把完整词说一遍。

第三个位置是常见问题区，用户会用完整词提问，答案里自然也带着它。

这三个位置的共同点是：写完整词在那里不显得奇怪。不奇怪很重要，硬塞进标题会让德国读者一眼看出这是给机器看的。前面提过的那家母婴站最后用的是第一和第三个位置，一个季度之后那条产品线的展现量回到了正常区间。

没有做任何违反正字法的事，词就补回来了。

这三个位置还有一个共同的实操优势，就是它们都不在设计稿的管辖范围内。改标题要过设计和品牌两道关，改商品名称字段和常见问题区不用，内容团队自己就能改完。选修补位置时把审批成本一起算进去，落地速度会差出好几倍。

这三个位置里，常见问题区其实是最被低估的一个。用户提问时用的一定是完整词，答案里跟着复述一遍也完全自然，不会有任何生硬感。等于是让用户的提问习惯替你把那个缺失的字符串补回了页面上，成本几乎为零。

一份可以交给非母语者执行的检查表

最后把整篇压成一份能执行的东西。

第一步，列出这一批页面必须命中的完整词，一行一个。

第二步，把页面正文复制成纯文本，逐个查找。

第三步，查不到的词，看它在页面上是以什么形式出现的。

第四步，按四类归档：省略连字符、连词粘连、列举拉开、拆成列表。

第五步，前两类走补写法，后两类走改句式或者绕开列举串。这五步里没有一步需要判断地不地道，全部是查找和归类。搜索意图分歧那篇提过一个原则，能被非母语者执行的检查才有可能长期跑下去，这份表就是照着那个原则写的。

需要母语者的地方只剩最后一步：确认补进去的那个完整词写法没错。

这份表最好固定跑在两个时间点上：一是新品上架时，二是每次批量导入商品数据之后。这两个时刻是缺口被批量制造出来的时刻，事后再排查等于把同样的活干两遍。把它挂进上架流程的检查清单里，比单独安排一次全站排查有用得多。

什么时候该承认这条不值得修

也不是每一处都值得动手。

如果那个被省略的半截词本身没有搜索量，修了也没有收益。

如果那个词已经在页面别处出现过，那就不存在缺口。

如果整个品类在这门语言上都不是重点市场，优先级自然靠后。

判断只需要两个数：那个完整词的搜索量，和它在你站上的出现次数。

两个数都拿到之后，决定就变成了机械动作：有量且为零的先修，有量但已出现的跳过，没量的一律不动。这样一批页面里通常只有一两成需要处理，而那一两成往往贡献了这一类缺口的大部分损失。

把力气花在能算出收益的那部分，比全站排查省事得多。

还有一种情况也该放过，就是那个完整词的搜索意图跟你的页面根本不匹配。有些被省略的半截词搜索量不低，但搜它的人想要的是另一类东西。这时候把词补进去，得到的是一批高展现低点击的曝光，对整页的表现反而是负担。

常见问题解答

补充连字符只在德语里有吗？

不只德语，但德语最典型。荷兰语、瑞典语、丹麦语这些日耳曼语族的语言都有复合词并列时省略共同部分的写法，规则细节各有不同。荷兰语的写法跟德语几乎一致，瑞典语和丹麦语则更倾向于直接写完整词。差别的根源在于各自的复合词长度分布，词越长省略的收益越大，规范也就越倾向于允许省略。判断一门语言要不要做这项检查，可以先看它的商品标题平均有多长。如果标题里经常出现十五个字母以上的名词，多半就有这个问题。判断标准可以再简单一点：只要那门语言的商品标题里经常出现两个复合词并列，就值得查一遍。

把完整词硬塞进标题会不会有风险？

会让本地读者觉得别扭，这本身就是风险。更稳的做法是放在商品名称字段和常见问题区，那两处写完整词是自然的。标题是整页可见度最高的位置，塞进去的每一个词都会被读者读到。硬把完整词加上去，德语读者第一眼看到的就是一个啰嗦的标题，品牌感会往下掉。更划算的做法是把标题交给语言规范，把完整词交给那些用户不太会逐字阅读的位置。这个分工的前提是那些位置真的会被索引，所以配置之前要先确认它们没有被排除在抓取范围之外。另外要留意的是，商品名称字段在有些系统里并不进索引，配置之前先确认它会被抓到。

复合词拆分器能不能解决这个问题？

不能。拆分器的方向是把长词拆短，而这里需要的是把残片补长，两者方向相反。拆分器的训练目标是把复合词切成有意义的成分，它面对Sommer- 这个残片时并不知道后面本该跟着什么。理论上可以从上下文推断，但那已经不是分词的活了。更根本的问题在于，即使推断对了，索引里存的仍然是推断结果而不是页面上的字符串。一旦推断规则改动，整批索引的行为就跟着变，这种不可控性比缺口本身更麻烦。实践中更稳的做法是把拆分器当成诊断工具用，看它把哪些词切成了什么，而不是指望它修复缺口。

芬兰语的列举问题有没有省事的解法？

没有通用解法，只能不用模板拼串，把需要变形的列举写死在文案里。芬兰语的困难在于列举项必须跟着中心词一起变格，这是语法强制而不是风格选择。模板拼串永远拼不对，因为模板不知道整个短语要落在哪个格上。可行的路只有两条：需要变形的列举由文案直接写死，或者干脆改写成每项一句的短句。前者适合标题和属性区，后者适合正文段落，两者可以在同一个页面上并用。还有一个折中办法，是把最常搜的那几个组合单独写成短句放进详情段落，不必处理全部列举。

阿拉伯语的连词粘连要怎么处理？

换成语言专属分析器，它会处理这类前缀。默认分析器不会做这一步。换成语言专属分析器是最省事的办法，主流检索引擎都内置了阿拉伯语分析器，它会把连写的功能词前缀剥掉。要注意的是切换分析器需要重建索引，不能热切。另外还要确认站内搜索和外部检索用的不是同一套逻辑，很多站只改了其中一边。改完之后拿带前缀和不带前缀的两种形式各搜一次，结果数一致才算生效。如果暂时改不了分析器，退而求其次可以在结构化数据里把每个属性值单独存一份，绕开正文解析。

列表和逗号串到底哪个更好？

看每一项是不是完整概念。是实体就用列表，是属性就别拆。判断标准是每一项能不能脱离中心词独立成立。配送方式、支付方式这类本身就是完整概念，用列表更清楚；颜色、尺码、材质这类是属性，拆开就成了孤儿。还有一个折中做法，是在列表前那一句里把中心词说全，让后面的每一项都有依托。这样既保住了移动端的可读性，也不至于让抽取出来的片段没头没尾。实在拿不准的时候，可以两种形式并用：列表前那一句把中心词说全，列表里保持简洁，两边的好处都能拿到。

这类缺口占关键词损失的比例大概是多少？

没有普适数字，要按站测。办法是把必须命中的完整词列一遍，数出其中在页面上根本不出现的比例。这个比例跟语言和品类都相关，没有可以直接搬用的数字。测法是先列出这一批页面必须命中的完整词，再统计其中在页面正文里根本不出现的比例。德语站上这个比例通常在两成到四成之间，芬兰语更高，英语站几乎为零。拿到自己站的数字之后，再乘上这些词的搜索量总和，就能算出这一类缺口值不值得专门排一轮。拿到比例之后还要再看一步，就是这些缺失词的搜索量集中度，如果集中在少数几个词上，修补的性价比会高得多。

权威参考资料