你在后台改了三遍的那行标题,引擎一次都没用过,它拿去顶替的是页脚上那个英文站名

你在后台改了三遍的那行标题,引擎一次都没用过,它拿去顶替的是页脚上那个英文站名
张文保 36 分钟阅读 4,920 阅读
本文目录
  1. 波兰语页面在结果页上顶着两个英文词,而模板里那行字一个英文都没有
  2. 一家户外露营装备站的波兰市场,展现涨了点击没动
  3. 后台里那行标题是干净的波兰语
  4. 换一台电脑从结果页看,那行字变了
  5. 一句话判据:把两行字并排抄下来
  6. 搜索结果里那行标题,到底是从哪几处文本里挑出来的?
  7. 官方把取材范围写成了一张清单
  8. 为什么会有替换这件事,它解决的是别的问题
  9. 替换不是翻译,它只是换了一段现成的字
  10. 候选之间有优先级,但优先级不看语言
  11. 为什么替换在多语言站上会变成换了一门语言?
  12. 取材源里最容易漏翻的是哪几处
  13. 站点名只有一份,而它是全站唯一一处跨语言共用的名字
  14. 导航与面包屑走的是另一条链路
  15. 外部锚文本天生是别人写的
  16. 这条连锁只在多语言站上成立
  17. 这件事为什么在你自己的后台里一次都不会报错?
  18. 你的检查工具读的是源码里那行字
  19. 站长工具给的是查询与点击,不给展示出来的标题
  20. 抓取诊断显示的也是你写的那一版
  21. 唯一能看到真相的地方是结果页本身
  22. 怎么用二十分钟测出自己有没有中招?
  23. 第一步:按语言各取二十条查询
  24. 第二步:并排抄两列
  25. 第三步:给差异分四类
  26. 这个动作该多久跑一次
  27. 四类差异各自对应哪一处该修的地方?
  28. 第一类:整行被换成品类词加站点名
  29. 第二类:品牌后缀被换成另一种写法
  30. 第三类:前半截来自导航或面包屑
  31. 第四类:被换成页面主标题
  32. 站点名这一格该怎么按语言填?
  33. 声明位置有优先级,最重的那张牌是结构化数据
  34. 一个站点名只有一份,这条约束意味着什么
  35. 别名字段能装下第二种写法
  36. 改完之后多久生效,怎么确认
  37. 屈折语和非拉丁文字的站,还要多担心哪一层?
  38. 换进来的那个词形态往往不对
  39. 非拉丁站上的拉丁字母残留最显眼
  40. 没有空格的语言,替换会撞上分词
  41. 混语言标题在语言判定那一侧还要再扣一次
  42. 把哪几件事做扎实,替换就换不出别的语言?
  43. 第一周:只清点,一行代码都别改
  44. 第二周:把站点名和两个标题字段处理掉
  45. 第三周:补翻界面文案那一层
  46. 第四周:让标题本身好用到没有替换的理由
  47. 什么时候该接受被换掉
  48. 这件事的边界,哪几件不归它管
  49. 截断不是替换
  50. 引擎自己翻译展示的那一版是另一回事
  51. 排名和替换是两条线
  52. 归架构层和引擎层的那部分
  53. 常见问题解答
  54. 标题被引擎换掉,是不是说明我的标题写得不好?
  55. 为什么我在站长工具里看不到实际展示的标题?
  56. 站点名能不能按语言各设一个?
  57. 把没翻译的导航和面包屑补翻了,替换就不会发生了吗?
  58. 我们用的建站系统改不了导航文案,怎么办?
  59. 这件事对小语种市场的影响,真的比英语市场大吗?
  60. 多久检查一次比较合适?
  61. 改完之后怎么知道有没有效果?
  62. 权威参考资料

摘要:你写在模板里的那行标题,和用户在结果页上看到的那行,是两个字符串。引擎替换时不会自己造句,它从页面上另挑一段现成的文本顶上去,而取材范围里排在前面的几处,恰好是多语言站上最不容易被翻译到的:全站共用一份的站点名、走另一条链路的导航与面包屑、由别人写的外部锚文本。于是替换在单语言站上只是换了句话,在多语言站上是换了一门语言。

波兰语页面在结果页上顶着两个英文词,而模板里那行字一个英文都没有

一家户外露营装备站的波兰市场,展现涨了点击没动

有个客户做户外露营装备,帐篷、睡袋、营地灯、便携炉具这几条线。

德国、波兰、捷克三个市场,页面都做了本地语言,商品结构也基本一致。

那一季他们把三个市场的标题模板统一重写过一轮,德国和捷克的点击率都往上走了一截,波兰这边只有展现在涨,点击几乎原地不动。

团队先怀疑是季节因素,波兰的露营旺季比德国晚半个月,等了三周,曲线还是那个形状。

接着怀疑是价格,把三个市场的同款商品价格拉出来比,波兰这边并不吃亏。

再往下就开始怀疑内容质量了,追加了一批波兰语的选购指南,指标依然没有反应。展现在涨说明引擎认为这些页面配得上这些查询,点击不涨说明用户在结果页上看到你之后选择了别人,中间隔着的只有那一行标题和那一段摘要,可这两样在后台里看着都没问题。

后台里那行标题是干净的波兰语

他们的标题模板写得相当规矩:品类词在前,属性词在中间,品牌名放最后。

三个市场共用一套模板结构,词槽各填各的,波兰语那一份是找母语译者做的。

抓取诊断工具跑过,返回的源码里那行标题完整、正确、全是波兰语。

站长工具里的页面报告也没有任何提示,收录正常,索引状态正常。

所有能在自己这一侧检查的地方都检查过了,结论是标题没问题。

问题在于,这些工具读的都是同一样东西,也就是你自己发出去的那份源码。它们回答的是你写对了没有,而不是用户看到了什么。这两个问题在单语言站上答案通常一致,在多语言站上未必。

换一台电脑从结果页看,那行字变了

保哥让他们换一台没登录过的机器,开无痕窗口,把地区参数设成波兰,直接搜商品词。

结果页上那一行标题的前半截还是波兰语的品类词,后半截接了两个英文单词,中间用一条竖线隔开。

那两个英文单词是他们的英文站点名,也是全站页脚里一直挂着的那个名字。

再翻十几条,同样的形状反复出现,有几条更彻底,整行标题被换成了英文品类词加英文站点名。

德国和捷克的结果页上也有替换,但换进去的是德语和捷克语,读起来毫无违和感,所以这两个市场的点击率不但没掉,还因为标题变短而涨了一点。

同一个机制,在三个市场里给出了三种结果:两个市场受益,一个市场受损。受损的那个市场之所以受损,不是因为引擎对它有偏见,而是因为它是三个市场里唯一一个替换源和页面主体语言不一致的。

一句话判据:把两行字并排抄下来

这件事的排查成本极低,低到不值得先做假设。

打开无痕窗口,搜一条你确定自己排在首页的查询,把结果页上显示的那行标题原样抄进一张表的左列。

再打开你自己的页面,把源码里那行标题抄进右列。

两列不一样就说明发生了替换,两列语言不一样就说明发生了这一篇要讲的那种替换。

抄二十条,你就知道自己站上有没有这个问题,以及有多严重。

这个动作的价值在于它绕开了所有工具。工具能告诉你标题写得合不合规、有没有超长、有没有重复,唯独不能告诉你它最终有没有被用。而这件事只能靠肉眼在结果页上确认,没有第二条路。

搜索结果里那行标题,到底是从哪几处文本里挑出来的?

官方把取材范围写成了一张清单

这不是需要靠猜的事,引擎自己把范围写在文档里了。

用来生成结果页标题的候选文本包括:页面的标题元素、页面上的主标题与其它显著文字、页面上的其它内容、指向这个页面的锚文本,以及站点名。

换句话说,标题元素只是候选之一,不是唯一来源,更不是默认来源。

这张清单最值得注意的地方不是它列了几项,而是它把范围划到了页面之外:锚文本来自别的站,站点名来自域名级别的判断。

页面级别的内容你能改,域名级别的东西全站共用,站外的东西你根本改不了。

把这张清单按归属重新排一遍,五项里只有两项完全归内容团队管,剩下三项分别归前端、归品牌、归别人。这个归属结构才是后面所有麻烦的根源,而它跟语言这件事天然不兼容,因为语言恰恰是按页面分的。

为什么会有替换这件事,它解决的是别的问题

替换机制不是针对多语言站设计的,它解决的是一批很实在的老问题。

有的页面根本没写标题,有的写了但整站几万页一模一样,有的塞满了关键词读不成句,有的写着首页两个字却是个商品页。

对这几类页面来说,从正文里挑一段更贴切的文字顶上去,用户体验确实更好。

行业里有过一次规模不小的实测,抽了两千多个站的八万条标题,结果页上显示的标题里大约有六成跟源码里那行不一样。

六成这个数字第一次公布的时候引起过不小的骚动,但它本身并不说明标题不重要,它说明的是标题这个字段从独占变成了候选。

这套机制在英语世界里被讨论了很多年,讨论的焦点始终是改写率、是怎么把标题写到不被改。这些讨论有一个共同的默认前提:改写之后那行字仍然是这门语言。这个前提在英语站上成立得太好,好到没人想过它是一条假设。改写这件事本身的机制、触发条件和应对策略,保哥在用AI重写标题的机制与应对里已经拆过一遍,这一篇不重复那部分,只讲那条假设在多语言站上不成立之后会发生什么。

替换不是翻译,它只是换了一段现成的字

这里要先把两件容易混的事分开。

引擎确实有把整页翻译过来展示的能力,那是另一套机制,触发条件、展示形态和归属都不一样。

本篇讲的替换不涉及翻译:它只是从你的页面上或者站外的锚文本里,原样取一段现成的字符串顶到标题位上。

原样这两个字是关键。它不会把英文站点名翻成波兰语再放上去,它就是把那两个英文单词直接摆在波兰语品类词后面。

所以替换的结果是不是本地语言,完全取决于被取走的那段字本身是什么语言。

这也解释了为什么单语言站永远遇不到这个问题。英语站上所有候选源都是英语,随便取哪一段,出来的都是英语。多语言站不一样,它的候选源里混着几种语言,而混进去的那几处恰好是最不容易被翻译到的。

候选之间有优先级,但优先级不看语言

引擎在几个候选里怎么选,大致有个偏好顺序:标题元素写得准确、长度合适、跟正文一致时,优先用它。

标题元素被判定为不好用时,才会往下找。往下找的时候,页面主标题的分量最重,其次是页面上位置显著的文本,再往后是锚文本。

站点名比较特殊,它不参与竞争,而是作为后缀被拼接上去,替换掉你原本写在标题里的品牌部分。

整个选择过程里没有任何一步在检查语言一致性。

它检查的是描述得准不准、长度合不合适、是不是重复、跟正文对不对得上,这几条全部是语义和结构层面的判据。

语言一致这件事在单语言世界里是自动满足的,所以没有人需要把它写成一条判据。这是本篇最核心的那条机制:不是引擎判错了,是这套判据里压根没有语言这一维,而它在多语言站上恰恰是最先出问题的那一维。

为什么替换在多语言站上会变成换了一门语言?

取材源里最容易漏翻的是哪几处

把五个候选源按翻译覆盖率排一遍,结论会很刺眼。

标题元素和正文这两处覆盖率接近百分之百,因为它们就是翻译交付清单上的主体。

页面主标题通常也翻了,但它跟标题元素常常是两个字段、两条链路,后面单说。

导航条、面包屑、页脚这几处属于界面文案,走的是资源文件或者主题模板,跟内容库不是一套东西。

站点名是全站一份,锚文本是别人写的,这两处根本不在翻译这件事的讨论范围里。

所以覆盖率越低的那几处,越靠近替换发生时被取用的位置。这个巧合不是巧合:引擎挑的是稳定的、位置显著的、能概括页面身份的文本,而这类文本天然是模板级的、全站共用的,也正是本地化流程最容易跳过的那一类。界面文案这一层为什么会被系统性跳过,硬编码字符串与伪本地化那一篇把成因写得很细,这里只借它的结论。

站点名只有一份,而它是全站唯一一处跨语言共用的名字

站点名这一格值得单独说,因为它的约束最硬。

它是域名级别的判断,引擎给一个站定一个名字,不是给一个页面定一个名字。

你的站有九门语言,站点名仍然只有一个。

这意味着不管用户看的是哪门语言的页面,被拼到标题后面的那个后缀都是同一串字符。

如果这串字符是英文品牌名,那问题不大,品牌名本来就常常保留原文。

如果这串字符是英文品牌名加一个英文品类词,比如某某牌加上户外装备这两个英文单词,那就是每一门语言的每一条结果都被塞进两个外语词。这一格没有按语言拆开的机制,只能选一个全语言都能接受的写法,这是本篇给出的第一条硬约束。

导航与面包屑走的是另一条链路

导航项、面包屑、分类名这几样东西在系统里通常不住在文章表里。

它们要么在分类表里,要么在菜单配置里,要么直接写在模板文件里。

翻译交付清单是按页面模板列的,这几样东西不在页面模板里,于是它们经常整批留在源语言状态。

更隐蔽的是半翻状态:一级导航翻了,二级没翻;面包屑的中间层翻了,最前面那个首页两个字没翻。

而面包屑最前面那一节恰恰是替换时最爱取用的位置之一,因为它稳定、简短、能表达页面在站内的位置。

排查这一层有个笨但可靠的办法:把页面另存为纯文本,然后用一个只包含本地语言字母的字符集去扫,扫出来的每一个落在字符集之外的词都标出来。二十个页面扫完,哪几处没翻一目了然,比逐个模板去读源码快得多。

外部锚文本天生是别人写的

第四处候选是指向这个页面的锚文本,它的语言由链接方决定。

本地媒体链你,锚文本多半是本地语言;行业目录链你,多半是分类名;而你自己在英文站或者英文新闻稿里链过去的那些,锚文本就是英文。

出海站有个很常见的结构:英文主站是最早建的,权重最高,内链最密,而它指向各语言子目录的那些链接,锚文本一律是英文。

于是你自己的站,成了给自己的波兰语页面提供英文锚文本的最大来源。

这一处你改不了别人的,但能改自己的。把英文主站指向各语言版本的锚文本按目标语言写一遍,成本很低,收益是把一整类替换源清干净。

屈折语这边还要多想一层:锚文本在这类语言里天然会变形,报表里那个精确匹配的数字本身就是假的,这件事锚文本在屈折语里变形那一篇讲过。它跟本篇的交叉点在于:被取去当标题的那个锚文本形态,未必是你希望出现在标题里的那个形态。

这条连锁只在多语言站上成立

把前面几节合起来看,会得到一个结构上很整齐的结论。

替换的取材源里,语言覆盖率最低的三处,恰好是被取用概率最高的三处。

单语言站上这三处的语言跟正文一致,所以替换发生了也没人察觉,甚至是好事。

多语言站上这三处经常留在源语言,于是替换一发生就是跨语言的。

损失的方向也很明确:用户在结果页上看到一行半生不熟的字,第一反应不是这家店英语好,而是这家店不是本地的。

这跟同意横幅那件事的结构一模一样,都是一段不归你的翻译流程管的文本,出现在了用户最先看到的位置。区别在于横幅至少还在你的页面上,改一改总能改到;而结果页上那行字连改的入口都没有,你只能去改它的原料。

这件事为什么在你自己的后台里一次都不会报错?

你的检查工具读的是源码里那行字

先说最常用的那一类工具:爬虫式的站点体检工具。

它们抓你的页面,解析标题元素,然后按长度、重复、缺失这几条规则打分。

这套检查的输入是你发出去的源码,输出是你写得合不合格。

而替换发生在展示这一侧,跟你发出去什么没有直接关系。

所以哪怕全站每一条标题都被换掉了,这类工具依然会给你一片绿。

像素级预览类的工具也是同理,它按显示宽度模拟截断位置,模拟的对象仍然是你写的那一版。这类工具在控制长度上很有用,用模拟器做像素级预览那一篇讲过怎么用它,但它按定义就看不见替换。

站长工具给的是查询与点击,不给展示出来的标题

第二类是引擎自己的站长工具。

它给的是查询、展现、点击、位置这四个维度,没有一个字段叫做实际展示的标题。

这不是疏漏,而是因为展示出来的标题是按查询变化的:同一个页面在不同查询下可能被换成不同的字。

一个页面对应一行标题这个模型,在展示这一侧本来就不成立。

于是这份数据里,点击率异常是唯一的信号,而点击率异常有一百个可能的原因。

本篇这个原因还特别不容易被想到,因为它的表现是展现正常、排名正常、只有点击率低,而这套症状最容易被解释成竞争对手的标题写得更好,然后团队就去改标题了,改的还是那个根本没被用上的字段。

抓取诊断显示的也是你写的那一版

第三类是抓取诊断和实时测试工具。

它们返回的是引擎抓到的原始响应或者渲染后的文档。

你在里面能看到标题元素、能看到结构化数据、能看到渲染后的正文。

看不到的是展示决策,因为展示决策发生在索引之后、结果页生成之时。

抓取跟展示中间隔着索引和排序两层,工具停在第一层。

所以这三类工具加起来能覆盖标题这件事的九成检查项,唯独覆盖不了最后一步。而最后一步恰恰是用户唯一能看到的那一步,这有点像把菜谱、食材、火候全检查了一遍,就是没人尝一口。

唯一能看到真相的地方是结果页本身

结论很朴素:想知道用户看到什么,只能去用户看的那个地方看。

这件事没有工具可以代劳,因为没有任何接口把展示出来的标题吐出来给你。

好在它足够便宜,二十条查询、二十分钟,一个不懂技术的人也能做。

难的不是做,是想到要做,以及把它固定成一个动作而不是一次性排查。

把它挂在改版发布和新语言上线这两个节点上,是成本最低的挂法。

还有一条容易被忽略的触发时机:更换主题模板或者升级建站系统的时候。这一类改动经常会重置导航与面包屑的文案来源,把原本翻好的那一份换回默认值,而默认值是英文。这跟错误页那件事的成因是同一类,请求一旦离开你自己维护的那部分,兜底出来的那一版就不认你的语言设置了

怎么用二十分钟测出自己有没有中招?

第一步:按语言各取二十条查询

从站长工具里导出最近三个月的查询报表,按语言版本的地址前缀拆开。

每门语言取二十条,取法是展现量前十条加点击率最低的十条。

前十条代表你最重要的门面,点击率最低的十条最可能是出事的那一批。

把这二十条查询和它们各自对应的落地页地址列成两列。

这一步的意义在于抽样有偏是对的:你不是在做统计,是在找病灶。

顺手记一件事:这二十条里有几条落在列表页和筛选页上。这两类页面的正文短,标题在整页文本里的占比高,被替换之后受到的连带影响也最大,后面讲语言判定那一节会再回到这一点。

第二步:并排抄两列

开无痕窗口,把地区和界面语言参数都设成目标市场,逐条搜过去。

结果页上显示的标题原样抄进左列,页面源码里的标题元素抄进右列。

不要凭印象记,一定要抄,因为差异常常只有两三个词,凭印象会漏。

抄的时候把分隔符也抄上,竖线、短横、破折号这几种符号本身就是替换留下的指纹。

二十条抄完,差异率和差异形态一眼就能看出来。

有两个操作细节值得说明。一是必须用无痕窗口,否则个性化和搜索历史会干扰结果;二是要指定地区参数,因为你人在国内看到的波兰结果页和波兰用户看到的未必完全一样,这一点跟同意横幅那件事一样,唯一能复现新访客视角的办法就是无痕窗口

第三步:给差异分四类

抄完之后不要急着下结论,先给每一条差异贴一个标签。

第一类是整行被换掉,换上来的是品类词加站点名的组合。

第二类是只有后缀变了,你写的品牌部分被换成了另一种写法。

第三类是前半截被换掉,换上来的字能在导航或者面包屑里找到原文。

第四类是被换成了页面主标题,也就是正文里那个最大的标题。

四类各自对应不同的修复位置,混在一起看只会得出标题被改了这个没用的结论。分类这一步花不了五分钟,但它决定了后面动手的地方对不对。

这个动作该多久跑一次

常规频率是一季度一次,二十分钟的事,挂在季度复盘里就行。

四个时机必须额外跑一次:改版发布之后、新语言上线之后、换主题模板或者建站系统之后、以及品牌名或者站点名做过调整之后。

前三个时机的共同点是模板层的文案来源可能被重置。

第四个时机则是因为站点名的判断有延迟,你改了声明,引擎不会当天就跟着改。

把这四个时机写进上线检查表,这件事就不需要靠谁记得了。

还有一个反过来的用法:把左列那些被换掉的标题当成免费的诊断反馈来读。引擎选中的那段字,代表它认为这个页面最该被概括成什么样。如果它换上来的那个词你的标题里压根没有,那多半不是它挑错了,是你写漏了。

四类差异各自对应哪一处该修的地方?

第一类:整行被换成品类词加站点名

这一类最常见,也最容易修。

它通常发生在标题写得过长、或者模板化程度太高的页面上。

引擎认为你的标题不好用,于是自己拼了一个:主体从正文里取,后缀用站点名。

修的方向有两个:一是把标题本身压短、写具体,让它没有被弃用的理由;二是把站点名那一格按后面那一节的做法处理好。

两件事都做完之后,这一类差异通常会明显下降。

要提醒的是,被换掉不等于要慌。改标题这件事本身不会招来惩罚,改动本身不被罚,改错了内容才掉,所以发现替换之后完全可以放手去改,只是别把它当成一次紧急事故来处理。

第二类:品牌后缀被换成另一种写法

你写的是本地字母的品牌音译,结果页上显示的是拉丁原名,或者反过来。

这一类的根子不在标题,在品牌名这件事本身有几种写法并存,而各处声明得不一致。

页脚写一种、结构化数据写一种、外部媒体写第三种,引擎拿不准就自己挑一个。

修法是先把品牌名的主写法定下来,再让所有声明位置口径一致。

至于主写法该选哪一种,那是另一道题,答案不由品牌部决定。

品牌名在小语种市场会长出几种写法、该收哪一种,品牌名由当地用户的输入法决定那一篇已经给过完整的判据,这一篇只需要接受它的结论:定下一种,然后处处一致。

第三类:前半截来自导航或面包屑

这一类最能说明问题,因为它把没翻译的那几处直接摆到了台面上。

你在结果页上看到的那个英文词,去页面上搜一遍,通常能在面包屑的第一节或者一级导航里找到。

修法很直接:把那几处补翻。

补翻的时候要连带处理形态问题,导航和面包屑上的词一般用主格或者词典形,这一点跟站内其它位置的用词规范未必一致。

补完之后再跑一次抄写动作,验证那个英文词是不是不再出现。

这一类还有一个变种值得留意:页面上某个位置显著的英文技术标识,比如型号前缀、认证名称、行业缩写,也可能被取去顶到标题前面。这类词本来就是不该翻的,处理办法不是翻它,是让标题元素本身足够好用,让引擎没有理由去取别的东西。

第四类:被换成页面主标题

这一类要单独讲,因为它暴露的是一个字段结构问题。

标题元素和页面主标题在多数建站系统里是两个字段,可以填不一样的内容。

正因为可以不一样,它们在多语言站上就常常走两条翻译链路:一条走内容编辑,一条走搜索设置面板。

结果是主标题翻了、搜索设置里那一栏还留着源语言,或者反过来。

引擎发现两者不一致时,倾向于用主标题,因为它跟正文的关系更紧。

排查办法是导出全站这两个字段做对照,凡是两栏语言不一致的行都拎出来。这份对照表通常还能顺手发现另一批问题:有一批页面的搜索设置栏是空的,系统自动拿主标题填了上去,那一批其实从来没被翻译流程碰过。

站点名这一格该怎么按语言填?

声明位置有优先级,最重的那张牌是结构化数据

站点名不是你想显示什么就显示什么,它是引擎综合判断出来的。

但官方给了明确的影响手段,而且标了轻重:首页上的网站类结构化数据最重,其次是社交协议里的站点名字段、标题元素、首页的主标题,以及首页上的其它文本。

很多站只填了后面几项,最重的那张牌没打。

把想要的名字用首页结构化数据声明一遍,再确保其余几处口径一致,这件事配置成本极低。

来源行这一整块的显示逻辑和三个要素怎么配,来源行被越改越重那一篇讲得比这里细,本篇只补语言这一维。

补的这一维是:以上所有声明位置,在多语言站上都指向同一个域名级别的判断。你在波兰语首页上声明一个波兰语站点名,在德语首页上声明一个德语站点名,最终生效的仍然只会是一个。

一个站点名只有一份,这条约束意味着什么

接受这条约束之后,选择空间一下就清楚了。

要么选一个不承载语义的纯品牌名,让它在每门语言里都只是一个专名。

要么选一个带品类词的组合名,然后接受它在所有非该语言的市场上都是外语。

绝大多数出海站应该选前者,理由不是美学,是这条约束本身。

品牌名后面挂一个英文品类词,看起来能多蹭一点关键词,实际代价是每一门语言的每一条结果都被塞进一个外语词。

这笔账很好算:那个品类词在标题后缀里带来的匹配收益,远小于它在八门语言的结果页上造成的观感损失。真要蹭那个词,正确的位置是标题本体和正文,不是全站共用的那一格。

别名字段能装下第二种写法

结构化数据里除了名称,还有一个别名字段,它能容纳同一个实体的其它写法。

拉丁原名和本地字母音译并存的品牌,可以主名称放一种、别名放另一种。

这不能让站点名按语言变,但它能降低引擎在几种写法之间拿不准的概率。

拿不准正是很多站点名显示成裸域名的原因。

显示成裸域名比显示成外语词更糟,因为域名连品牌都不算。

标记这一层能做的事到此为止:它只是把已经确定的答案写下来,答案本身不由它决定。小语种站的标记该怎么在本地化和国际格式之间取舍,结构化数据要反着写回国际格式那一篇给过一套分类办法,站点名属于其中最不该本地化的那一类。

改完之后多久生效,怎么确认

站点名的判断有明显的滞后,改完当天不会有变化。

通常要等下一次首页被重新抓取和处理,实际观察多在一到几周之间。

确认的办法还是抄写动作,看后缀那一段有没有变成你声明的那个。

这期间不要反复改,反复改只会让引擎更拿不准,然后退回去显示域名。

改一次,等一轮,再看。

如果等了几周仍然没变,先检查三件事:首页的结构化数据是不是真的输出了并且能通过校验、几处声明的口径是不是真的一致、以及首页本身是不是能被正常抓取。这三件事里最常出问题的是第一件,尾逗号之类的语法错误会让整段标记失效,而页面上看不出任何异常。

屈折语和非拉丁文字的站,还要多担心哪一层?

换进来的那个词形态往往不对

屈折语站上有一层额外的麻烦:被取去顶替的那段字,形态未必是你想要的那一种。

面包屑和导航项通常用主格,而你的标题模板可能刻意选了另一种更接近检索形态的写法。

替换一发生,那份形态选择就被抹掉了。

波兰语这类七个格的语言尤其明显,同一个品类词的主格和其它格在字符串上差得不小。

用户在搜索框里打的多半不是主格,而结果页上给他看的偏偏是主格。

这不算致命,因为匹配发生在索引侧不在展示侧,但它会让标题读起来像是从目录里抠出来的一截,而不是一句给人看的话。波兰语的格变化怎么影响选词,只按词典原形选词会漏掉六个格那一篇讲过,这里只是它在展示侧的一个尾巴。

非拉丁站上的拉丁字母残留最显眼

使用非拉丁文字的市场,这个问题的观感代价要高一档。

希腊语、俄语、泰语、日语的结果页上突然出现两个拉丁单词,视觉上是直接跳出来的。

拉丁字母混在西里尔或者天城文里,用户不需要读就能看见异物。

而在德语波兰语这类同样用拉丁字母的市场,英文词混进去反而更隐蔽,要读一遍才发现。

隐蔽不代表无害,它只是延长了被发现的时间。

所以排查优先级建议倒过来排:先查同为拉丁字母的那几门语言,因为非拉丁市场的问题多半早就被本地同事嚷嚷出来了,而拉丁字母市场的问题可能已经安静地存在了两年。

没有空格的语言,替换会撞上分词

泰语、日语这类不用空格分词的语言,还要多担心一层。

替换进来的那段字跟原有的本地文字直接相邻,中间没有任何分隔。

用户读到的是一串本地文字后面紧跟着一串拉丁字母,视觉上粘在一起。

更麻烦的是标题里的分隔符本身,竖线和短横在这类语言的排版习惯里出现频率本来就低。

结果是那一行字既不像本地写法,也不像外语写法。

泰语标题该怎么写才切得开、空格在这门语言里到底什么时候用,泰语标题里找不到一个空格那一篇讲得很细,本篇的补充是:那套写法在被替换之后不成立,因为替换不遵守你的排版规则。

混语言标题在语言判定那一侧还要再扣一次

最后一层代价发生在展示之外。

标题是页面上位置最靠前、权重最高的一段短文本。

页面正文短的时候,标题在整页文本里的占比很可观。

而语言判定这件事本质上是在数字符和词,短文本判错的概率天生更高。

一个波兰语页面的标题里塞进两个英文词,对判定的影响远大于正文里塞进两个英文词。

受影响最大的还是列表页和筛选页这类字最少的页面,而它们往往是最赚钱的那一批。机器不完全相信你写在页面上的语言声明那一篇讲过判定到底在数什么,把它跟本篇合起来看会得到一条不太舒服的推论:替换这件事不只损失点击率,它还可能反过来影响这个页面被归到哪门语言。

把哪几件事做扎实,替换就换不出别的语言?

第一周:只清点,一行代码都别改

第一周做三件事,全部是清点。

第一件是把抄写动作跑一遍,每门语言二十条,得到差异率和四类分布。

第二件是列一张取材源清单:标题元素、页面主标题、导航、面包屑、页脚、站点名、外部锚文本,逐项标注这一门语言下它是不是本地语言。

第三件是导出标题元素和页面主标题两个字段,找出语言不一致和空值的行。

三件事加起来一个人一天能做完,产出是一张能拿去开会的表。

先清点后动手这条顺序不是客套。这件事的修复成本分布极不均匀,站点名改一次全站受益,外部锚文本改起来慢且收效有限,不先看清楚就动手,多半会从最费力的那一头开始。

第二周:把站点名和两个标题字段处理掉

第二周动最重的那两件。

站点名按前面那一节的做法声明一遍,选一个不承载语义的写法。

标题元素和页面主标题的空值行补齐,语言不一致的行统一。

这两件做完,四类差异里的第一类和第四类通常就消掉大半。

这一周不要碰导航和面包屑,因为那一层改动会牵连模板,需要单独排期。

顺带把一件很容易被忘的事一起做了:检查各语言首页的标题元素。首页是站点名判断的主要输入,如果连首页标题都还是英文,后面怎么声明都是白搭。

第三周:补翻界面文案那一层

第三周处理导航、面包屑、页脚这几处。

先用前面说的字符集扫描法定位,再按语言逐条补。

补的时候把用词跟站内其它位置对齐,别造出第三种说法。

这一层补完之后,第三类差异会明显下降。

如果建站系统把这些文案锁在模板里改不了,那就退一步,至少把面包屑第一节那个词换掉,它是被取用频率最高的一个。

这一层还有个附带收益:这些词补翻之后,页面上的本地语言字符占比会上升,语言判定那一侧也跟着受益。改一处收两份钱的事不多,这算一件。

第四周:让标题本身好用到没有替换的理由

最后一周回到标题本身。

目标不是把标题写得漂亮,是把它写到引擎没有理由去找别的字。

三条判据:长度别超、别跟正文脱节、别整站雷同。

长度这一条在小语种上要按语言重算,同一句话翻成德语可能长出三成,翻成韩语则要按显示宽度而不是字符数算。

雷同这一条在模板站上最容易踩,几万个页面共用一套词槽,填出来的标题彼此差别太小。

这三条的机制和批量治理办法,标题被改写的六种典型情形那一篇讲过,语言这一维上要补的只有两句:长度阈值按语言各定一份,雷同判定按本地语言的词去看而不是按模板结构去看。

什么时候该接受被换掉

不是所有替换都要修。

换进来的那段字如果是本地语言、读着顺、还比你写的更贴切,那就是一次免费的编辑服务。

真正要修的只有两种:换进来的不是这门语言,以及换进来之后核心品类词消失了。

其余情况可以记录但不必处理。

把这条写进检查表,能省掉大量无谓的返工。

说句实在的,这套机制在多数时候是站在用户那一边的。它只是在多语言站这个场景下缺了一维判据,而这一维恰好是我们最在意的那一维。知道它缺在哪儿,比抱怨它改了你的标题有用得多。

这件事的边界,哪几件不归它管

截断不是替换

标题在结果页上显示不全,多数时候是截断不是替换。

截断按显示宽度算,跟你写了什么语言没关系。

非拉丁文字的字符占宽更大,同样的字符数在韩语日语上更早被切掉,这是另一条线上的事。

区分办法很简单:截断之后剩下的那段字一定是你写的那行的前缀,替换则不是。

抄写的时候把这两类分开记,别混成一类。

韩语标题能安稳显示的音节数大约只有英文字符数的一半,这类按语言重算显示预算的事,韩语标题挪一个空格就变词形那一篇里有具体的口径。

引擎自己翻译展示的那一版是另一回事

结果页上还有一种形态:整条结果被翻译成用户的语言展示。

那是一套独立的机制,触发条件、展示形态和你的应对都不一样。

本篇讲的替换不涉及翻译,它只搬运现成的字符串。

两者在症状上有一点像,区分办法是看换进来的那段字能不能在你的页面上原样找到。

能找到就是替换,找不到、而且读起来像翻译腔,那多半是另一回事。

把这两件事分开很重要,因为它们的处理方向正好相反:替换要修的是原料,翻译展示要考虑的是要不要参与、以及怎么让自己的本地版本被优先选中。

排名和替换是两条线

最后澄清一件容易被误会的事。

标题被替换不代表排名有问题,也不会因为被替换而掉排名。

展现量说明排序这一侧认可你,点击率说明展示这一侧没打动人。

本篇从头到尾讨论的是后一件事。

把两件事混在一起,最典型的表现就是发现替换之后跑去大改内容,结果排名动了、点击率还是没动。

先看展现,再看点击,中间那一行字才是本篇的辖区。这条分工写清楚了,后面的排期才不会被带偏。

归架构层和引擎层的那部分

还有几件事跟本篇相邻但不属于它。

各语言版本用什么域名结构承载、地区定向怎么配、语言标注怎么写,那是架构层的题目,跟语种本身无关。

不同引擎的替换力度差多少、各家的偏好如何,那是引擎层的题目。

本篇只管一件事:替换发生时,被搬上去的那段字是不是这门语言。

这条边界划清楚之后,这件事的排期就落在内容和前端两个角色身上,不需要拉上架构和投放。

需要跨出去的只有一处:外部锚文本那一项,它归外链和公关,不归这两个角色。把它单独列一行,交出去,然后别指望它很快有结果。

常见问题解答

标题被引擎换掉,是不是说明我的标题写得不好?

不一定。替换的触发条件包括过长、堆砌、整站雷同、跟正文对不上、以及页面上存在更贴切的表述,最后这一条跟你写得好不好没有直接关系。判断办法是看换进来的那段字:如果它读起来比你写的更准确,那是一次免费诊断,说明你的标题漏了页面真正的主题;如果它只是把你的品牌部分换成了站点名、其余照旧,那多半只是后缀策略在起作用。真正需要警惕的只有两种情况,一是换进来的不是这门语言,二是换进来之后核心品类词消失了。除此之外记录下来即可,不必每一条都追着改。

为什么我在站长工具里看不到实际展示的标题?

因为展示出来的标题是按查询变化的,同一个页面在不同查询下可能被换成不同的字符串,一个页面对应一行标题这个数据模型在展示这一侧本来就不成立。站长工具给的是查询、展现、点击、位置四个维度,没有实际标题这个字段;抓取诊断类工具返回的是抓到的原始文档,也就是你自己写的那一版;第三方体检工具解析的同样是源码。三类工具能覆盖标题这件事九成的检查项,唯独覆盖不了最后一步。想知道用户看到什么,只能开无痕窗口去结果页上抄,这件事目前没有替代方案。

站点名能不能按语言各设一个?

不能。站点名是域名级别的判断,一个站对应一个名字,你在各语言首页上分别声明,最终生效的仍然只有一个。接受这条约束之后,选择就只剩两种:选一个不承载语义的纯品牌名,让它在每门语言里都只是一个专名;或者选一个带品类词的组合名,然后接受它在所有其它语言市场上都是外语。绝大多数出海站应该选前者。品牌名后面挂一个英文品类词,看上去能多蹭点匹配,实际代价是每门语言的每一条结果里都被塞进一个外语词,这笔账是明显不划算的。

把没翻译的导航和面包屑补翻了,替换就不会发生了吗?

替换照样会发生,但换进来的会是本地语言,这就已经解决了本篇讨论的问题。补翻界面文案不是为了阻止替换,是为了让所有候选源都落在同一门语言里。这跟单语言站的处境是一样的:英语站上替换天天发生,没人觉得是事故,因为换进去的还是英语。补翻之后还有一个附带收益,页面上本地语言字符的占比会上升,语言判定那一侧也跟着变稳,属于改一处收两份钱。

我们用的建站系统改不了导航文案,怎么办?

先退一步,只处理被取用频率最高的那一处,也就是面包屑最前面那个通常写着首页的词。多数系统即使锁死了菜单结构,这一处也有单独的配置项或者语言包条目可以覆盖。其次是把标题元素本身写扎实,让引擎没有理由去别处取字,这条对所有被锁死的场景都有效。再次是检查页脚,页脚往往比导航好改,而它同样是位置显著的模板文本。三条都做不到的话,把站点名那一格处理好,它的收益覆盖全站,且完全不依赖模板改动。

这件事对小语种市场的影响,真的比英语市场大吗?

结构上确实更大,原因不在于引擎区别对待,而在于候选源的语言一致性。英语站的所有候选源都是英语,随便取哪一段结果都自洽;多语言站的候选源里混着几种语言,而混进去的那几处恰好是翻译覆盖率最低的。用户看到半生不熟的一行字,第一反应通常不是这家店英语好,而是这家店不是本地的,这个判断发生在点击之前,代价直接落在点击率上。非拉丁文字的市场受损更明显,因为拉丁字母混在里面不用读就能看见。

多久检查一次比较合适?

常规一季度一次,二十分钟的事,挂在季度复盘里就行。另外有四个时机必须额外跑一次:改版发布之后、新语言上线之后、更换主题模板或者建站系统之后、以及品牌名或者站点名调整之后。前三个时机的共同点是模板层的文案来源可能被重置回默认值,而默认值一般是英文;第四个时机是因为站点名的判断有滞后,改完通常要等下一次首页被重新处理才会生效,实际观察多在一到几周之间。把这四条写进上线检查表,就不用靠谁记得了。

改完之后怎么知道有没有效果?

直接的验证是重跑抄写动作,看那几个外语词是不是不再出现,差异率有没有下降。间接的验证看点击率,但要注意点击率受排名位置影响很大,比较的时候要按位置分组看,别拿整体均值下结论。建议保留改动前的那份抄写表当基线,改完一个月后再抄一次同样的二十条查询,两张表并排放,变化一目了然。这个基线还有一个用处:下次改版之后如果问题复发,你能立刻判断是新引入的还是一直没修干净。

权威参考资料

分享到
标签
版权声明

本文标题:《你在后台改了三遍的那行标题,引擎一次都没用过,它拿去顶替的是页脚上那个英文站名》

本文链接:https://zhangwenbao.com/minor-language-serp-title-rewrite-source-language.html

版权声明:本文原创,转载与引用请注明作者与原文链接。许可协议: CC BY 4.0

继续阅读
发表评论
分享到微信 或在下方手动填写
支持 Ctrl + Enter 提交