小语种页面的正文越本地化越好，结构化数据里却要反着写回国际格式

摘要：页面上的价格、日期、地址要按当地习惯写，越像本地站越好；而结构化数据里的同一批值必须反过来写成机器格式，价格用小数点、日期用国际标准写法、货币用三字母代码。两个方向正好相反，混成一件事做，要么用户看到一串机器格式，要么标记整批解析失败。另一半麻烦出在语言字段上：inLanguage不是hreflang的副本，把带地区的语言标签整块抄过去，等于声明同一份德语内容是两种不同的语言。

结构化数据为什么是全站唯一写错了没人会投诉的地方？

正文错了有人说，标记错了只有机器知道

小语种站上线之后，正文里的错误迟早会被人发现。用户会在客服对话里提一句，母语审校会圈出来，同行也可能顺手指出。

结构化数据没有这条反馈路径。它藏在页面源码里，普通用户一辈子不会看一眼。

把语言标签写成英语、把价格写成本地格式、把国名写成本地文字，页面看上去完全正常。

唯一知道出错的是搜索引擎，而它的反馈方式是不给你富媒体结果，不会告诉你为什么。

于是这类错误可以在站上待很久，久到没人记得它是什么时候写进去的。

发现它们的契机往往是某次改版排查，或者某天突然想起来对比一下各语种的展现差异。

这个反馈缺失有个更麻烦的后果：它让结构化数据成了整个多语言站里最容易被复制粘贴的部分。没有人会因为它写错而被追责，也就没有人有动力去逐个语种核对，模板一复制，错误就同步到了所有语种。

这条差别还带来一个管理上的后果：结构化数据的质量完全依赖流程，不依赖人的责任心。正文写得好不好，写的人自己心里有数；标记写得对不对，写的人从页面上看不出任何反馈。没有反馈的环节只能靠断言和检查来兜，指望自觉是没用的。

小语种站的标记通常是从英文站复制来的

多语言站的常见搭建顺序是先做英文站，跑通之后再复制出各语种站点。

结构化数据作为模板的一部分被整块带过去，这一步几乎没人会停下来检查。

带过去的东西里，有些字段是模板变量会自动替换，有些是写死的常量。

写死的那些就是问题所在：语言标签、国家代码、货币代码，全是英文站的值。

更隐蔽的是那些看起来被替换了的字段，比如价格。价格确实换成了当地数字，但格式跟着前端的本地化函数一起变了。

结果是标记里躺着一个当地格式的价格字符串，机器读不出数值。

要判断自家站有没有这个问题，最快的办法是随便打开一个小语种页面看源码里的标记块，逐个字段问一句：这个值是英文站带过来的，还是为这个语种单独产生的。答不上来的字段就是嫌疑对象，通常一看一个准。

安全座椅站那次：富媒体结果整批消失

保哥去年经手过一个卖儿童安全座椅的独立站，欧洲三个语种，德语、波兰语、俄语。

产品页的富媒体结果在德语市场展现得好好的，另外两个语种一直没出来。

最初怀疑是页面质量问题，后来把三个语种的标记块导出来并排比对，问题一眼就看见了。

波兰语和俄语页面的价格字段写着当地格式的数字，千分位用空格分隔，小数点用逗号。

德语页面之所以正常，纯属运气：那批商品的价格都是整数，没有小数部分，所以没触发解析失败。

改成纯数字加小数点之后，两个语种的富媒体结果在下一轮抓取里就回来了。

这件事最值得记住的一点是排查顺序。当时先花了两周去查内容质量、页面速度、内链结构，全都没问题；标记块是最后才看的，因为它在德语站上工作正常，潜意识里就把它排除了。同一份模板在不同语种下表现不同的时候，第一个该怀疑的就是那些跟语言相关的值，而不是最后一个。

inLanguage和hreflang到底是不是一回事？

一个是页面间关系，一个是内容属性

这两个东西经常被当成同一件事的两种写法，其实它们回答的是不同的问题。

hreflang回答的是：这个页面还有哪些其他语言或者地区的版本，它们分别在哪里。

它描述的是一组页面之间的关系，天然需要地区信息，因为同一门语言可能面向不同市场做了不同的版本。

inLanguage这个属性回答的是另一个问题：这一份内容本身，是用什么语言写的。

它描述的是内容的固有属性，跟其他页面存不存在没有关系。

一份德语内容就是德语，不管它是给德国用户看的还是给奥地利用户看的。

把两者的职责分清楚之后，很多写法上的困惑会自己消失。hreflang那一套落地规则管的是站点架构层的事，而结构化数据这一层根本不参与架构，它只是在描述这个页面上有什么。两者的值恰好长得像，但作用域完全不重叠。

把地区子标签写进inLanguage会声明出什么

最常见的做法是把hreflang的值直接抄进inLanguage，看起来省事又统一。

抄过去之后，德国站的页面写着一个带德国地区码的标签，奥地利站的页面写着带奥地利地区码的标签。

从机器的角度读这两份标记，得到的信息是：这是两种不同的内容语言。

而实际上它们是同一门语言的同一份内容，只是面向不同市场。

这个声明本身不会立刻造成可见的损失，但它把一个本可以合并的信号拆散了。

在实体关联和跨语言对齐这类处理里，语言维度被拆得越碎，越不利于系统把它们认成一回事。

这跟跨语言实体对齐里那些对不上的根因是同一类问题：每一层各自写了一点点不一致的信息，单独看每层都说得过去，叠起来就让系统无法确认这几个页面讲的是同一个东西。

这个错误的传播路径也很典型：某些建站插件的默认实现就是把hreflang的值直接复用，于是装了这类插件的站全都带上了地区码。抄来抄去之后它甚至显得像是行业惯例，很少有人回头看属性定义里到底怎么说的。遇到看起来大家都这么写的做法，回原始定义核一遍通常是值得的。

什么时候inLanguage该带地区

也不是一概不能带，有两种情况带地区子标签是合理的。

第一种是这份内容确实针对某个地区做了实质性的语言调整，用词、拼写、术语都不同。

典型的例子是巴西葡萄牙语和欧洲葡萄牙语，两者的差异大到读者能立刻分辨。

第二种是这份内容里包含只在某个地区有效的信息，比如当地的法规编号或者服务范围。

除此之外，仅仅因为面向不同市场投放就带上地区码，属于过度声明。

判断方法很朴素：把两个版本的正文并排放，如果一个母语者看不出它们的语言差异，就别带地区。

这条判断标准跟两个葡语市场到底算不算两套内容那个问题用的是同一把尺子。语言层面上真的分叉了，标记里就该体现出来；只是投放对象不同，标记里就不该体现。

还有一种情况介于两者之间：语言基本相同，但价格、法规、配送信息按地区不同。这时候差异全部落在格式字段和事实内容上，不在语言上，所以语言标签仍然不该带地区。差异该体现在别的字段里，比如适用区域、配送范围、价格与货币，这些字段本来就是为区域差异准备的。

两者不一致时哪个说了算

如果hreflang写的是带地区的标签，inLanguage写的是纯语言码，算不算冲突？

不算。两者描述的维度不同，纯语言码是带地区标签的语言部分，逻辑上完全一致。

真正的冲突是另一种：hreflang说这个页面是波兰语，inLanguage说是英语。

这种情况多半出现在模板变量没配对上的站点上，而且往往整个语种目录都错。

处理方式没有讨论余地，改到一致为止，以页面实际内容的语言为准。

加一条自动检查最省心：抓取每个页面，对比这两处的语言部分，不一致的报警。

这条检查还能顺手抓出另一类问题：页面上的语言属性、hreflang、inLanguage三处两两比对，往往能发现某个语种目录的模板配置从来就没配对过。三处一致才算干净，其中任何一处跟另外两处不同，都值得停下来查一遍模板变量的取值来源。

小语种站的Schema字段要分成三类处理

语言字段：说明内容是什么语言

第一类字段管的是语言本身，数量不多但最容易被忽略。

inLanguage是最常用的一个，文章、视频、商品描述都可以带。

availableLanguage这个属性用在客服和联系方式上，说明你的支持团队能用哪几种语言接待。

做小语种市场的时候这个字段有实际价值：用户想知道打电话过去有没有人说他的语言。

还有一个描述人物语言能力的属性，用在作者信息上，多语言内容站可以考虑。

这一类字段的值统一用标准语言标签，别用语言的名字，更别用中文或者本地文字写的语言名。

值的写法有个硬要求：必须是标准语言标签规范定义的那种格式，也就是两三个字母的语言码，需要时后面接书写系统和地区子标签。写成德语、Deutsch或者German这类人类可读的名字都是无效的，解析方拿到之后只能丢弃。

格式字段：机器要读的数值

第二类字段的共同点是它们的值是给机器算的，不是给人看的。

价格、评分、库存数量、日期、时长、电话号码，全在这一类。

这些字段有各自的格式规范，规范里定义的格式跟任何一门语言的书写习惯都不一样。

换句话说，它们不需要本地化，也不允许本地化。

页面上呈现给用户的那一份要本地化，标记里的这一份保持机器格式，两份值同源但形态不同。

实现上最干净的做法是从数据源直接取原始值写进标记，不要走前端的格式化函数。

这条实现建议值得单独强调，因为绝大多数格式错误都是同一个原因造成的：模板里用了同一个变量渲染页面和标记，而那个变量早就被本地化过一遍了。把两条路径分开，一条走格式化，一条走原始值，这类错误一次性根治。

判断一个字段属不属于这一类有个简单办法：想象把这个值交给一段程序去做计算或者比较，如果这件事说得通，它就是格式字段。价格要比大小，日期要排先后，评分要求平均，电话要拨号，全都说得通；而品牌名、描述、分类名这些拿去计算毫无意义，自然就不在这一类里。

书写系统敏感字段：名字怎么写

第三类是名称类字段，它们既不是纯语言标签也不是纯数值，处理方式最微妙。

品牌名、产品名、机构名、人名，在非拉丁字母市场都面临一个选择：用本地文字写还是用拉丁字母写。至于这些名字进了正文之后还会跟着语法变形，那是锚文本层面的另一个问题，标记这一层不受它影响。

这一类字段的答案不是二选一，而是两个都要，只是放在不同的属性上。

主名称字段填当地用户实际看到、实际会搜的那个写法。

alternateName这个属性就是为这种情况准备的，把另一种写法放进去。

这样一来两种写法都进了标记，而且主次分明，不必在两者之间做取舍。

价格和日期在标记里为什么必须去本地化？

千分位和小数点写反了会发生什么

价格字段的规范要求很直接：纯数字，小数点用点号，不带千分位分隔符，不带货币符号。

德语、波兰语、俄语的习惯写法正好相反：千分位用点号或空格，小数点用逗号。

把当地写法直接塞进价格字段，解析器读到一个逗号，多半会在那里截断。

截断的结果是一个数量级完全不对的数字，或者干脆解析失败整个标记块作废。

更坏的情况是解析成功但值错了，比如把一千两百三十四点五六读成一点二三。

这种错误比解析失败更难发现，因为标记语法上完全合法，校验工具不会报错。

各语言的数字书写习惯差异有多大，区域数据规范里的数字格式部分列得很清楚，同一个数值在不同地区能有五六种合法写法。正因为差异这么大，规范才干脆规定标记里只用一种写法，避免解析方去猜。

这类错误还有个特别不友好的地方：它跟商品价格本身有关，也就是说同一个站上有的商品会触发、有的不会。整数价格的商品一切正常，带小数的商品解析失败，于是你在后台看到的现象是富媒体结果时有时无，很容易被误判成抓取频率问题或者页面质量波动。

货币代码用ISO三字母不用货币符号

货币这一项单独说，因为它错得特别频繁。

页面上显示的是货币符号，标记里要求的是三个字母的货币代码。

符号和代码不是一一对应的关系，好几个市场共用同一个符号，代码却不同。

还有一类符号在不同国家指向完全不同的货币，只写符号机器分不清是哪一种。

所以这个字段没有本地化的空间，只有一种正确写法。

顺便说一句，页面上显示符号还是代码是另一个问题，那个归本地惯例管。

日期一律用国际标准写法，别用本地格式

日期字段的规范同样明确：年月日的顺序，用连字符分隔，需要时间的话按标准格式接上时区。

页面上给用户看的日期该怎么写就怎么写，日月顺序按当地习惯来。

标记里的那一份必须是互联网时间戳标准定义的格式，没有例外。

发布时间、修改时间、活动时间、优惠有效期，全都适用。

有效期这类字段写错的代价最直接：促销标记可能因为时间解析错误而完全不展现。

时区部分容易被漏掉，尤其是跨市场的促销活动，没有时区的时间戳会被按默认时区解释。

做多市场促销的时候还有个连带的坑：促销的开始和结束时间在标记里必须写成带时区的绝对时间，而页面上给用户看的应该是他所在时区的本地时间。两者又是一次分离，跟价格那次一模一样，只是很多团队做完价格就以为万事大吉，忘了时间字段是同一类问题。

还有一类日期字段容易被漏掉：文章的发布与修改时间。这两个字段在内容站上直接关系到时效性判断，而它们通常由内容管理系统自动输出，格式取决于主题模板怎么写。换主题的时候是重灾区，新主题按自己的习惯输出了本地化日期，标记里的时间就全废了。

电话号码用国际格式

电话字段的要求是带国家码的国际格式，前面加加号，中间不加括号和本地前缀。

各国的本地写法千差万别，有的习惯加括号，有的用点分隔，有的带一个拨号前缀。

这些写法在本地打得通，但机器无法判断这是哪个国家的号码。

页面上依然可以按当地习惯排版，标记里换成国际格式。

做本地商户标记的时候这一项直接影响能不能被正确关联到地图和拨号功能。

检查方法也简单：所有电话字段的值必须以加号开头，不满足的一律标出来。

地址字段在小语种市场怎么填才不出错？

国家字段要填代码不是国名

地址结构里的国家字段，规范建议填两个字母的国家代码。

常见错误是填了国名，而且是用当地语言写的国名。

德语站填德国的德语写法，俄语站填俄语写法，同一个国家出现了几种值。

机器没法把这几个字符串认成同一个国家，地理关联就断了。

改成两个字母的代码，所有语种共用同一个值，问题消失。

这是三类字段里最容易改的一处，全站替换一次就完事。

顺带提醒一句，地区和城市字段没有这样的标准代码可用，只能填名字。这时候用当地语言写是合理的，因为它本来就是给人看的文本。国家字段有代码可用是个例外，别把这个例外推广到整个地址结构上。

这个字段还有个变体错误：填了国家代码，但填的是三个字母的那一套。地址结构里要的是两个字母的那套，三字母代码属于另一个标准，用在这里同样无效。两套代码长得像、名字也像，混用相当常见，写规范表的时候要把位数明确写出来。

街道与邮编的顺序归页面管，不归标记管

地址的书写顺序在各国差别很大，邮编在前在后、门牌在前在后都不一样。

这件事完全归页面呈现管，标记里不存在顺序问题。

因为地址在标记里是结构化的，每一部分放进各自的字段，顺序由消费方决定。

所以不要把整个地址塞进一个字段里了事，那样接收方只能拿到一串没法拆的文本。

逐字段填写虽然啰嗦，但它让地址在任何市场都能被正确重组。

这一点跟价格日期的思路一致：把值和呈现分开，值保持结构，呈现随地区变。

逐字段填还有个附带收益：地址一旦结构化，就能被复用到别的地方去，比如地图标注、配送范围计算、门店列表。塞成一整串文本的地址，每次要用都得先拆一遍，而拆的规则在每个国家都不同，最后不得不为每个市场写一套拆分逻辑。

一个地址两种书写系统怎么办

在西里尔字母市场，同一个地址常常存在两种写法：本地文字的和拉丁转写的。

标记里该填哪一种？答案是填当地用户和当地邮政实际使用的那一种，也就是本地文字。

拉丁转写的作用是给国际用户看，属于页面呈现层的事，不必进标记。

如果确实需要两套，可以在页面上做切换，标记保持单一权威版本。

这跟URL用本地字母还是拉丁转写那个决策的思路是一样的：选一个权威形式，另一个作为辅助存在。

两套都当成权威往标记里塞，只会让机器无法确定哪个是真的。

品牌名在非拉丁市场该写本地写法还是拉丁写法？

主名称填本地写法，别名补拉丁

这个问题在西里尔、希腊、阿拉伯字母市场都会遇到，答案其实是固定的。

主名称字段填当地用户实际会搜、实际会看到的那个写法。

如果你的品牌在当地市场做了音译并且已经被用户接受，那就填音译形式。

如果当地用户直接用拉丁原名，那就填拉丁原名，不必强行音译。

判断依据是搜索数据和用户实际的输入习惯，不是内部的品牌规范。

另一种写法放进别名字段，两者都在，不冲突。

决定主名称用哪一种，本质上是品牌名在小语种里写成什么那个问题的延伸，而那个问题的答案从来不由品牌部决定，由当地用户的输入法决定。标记这一层只是把已经确定的答案如实写下来而已。

还有一种情况要单独处理：品牌在当地注册的法定名称与日常使用的名称不一致。标记里的机构名该填哪个，取决于这个标记块的用途——用于本地商户信息就填跟营业执照一致的那个，用于品牌实体识别则填用户实际认得的那个，两者可以分别出现在不同的标记块里。

为什么这个组合对实体消歧最有利

把两种写法都放进标记，最大的收益在实体识别这一层。

搜索系统需要确认：这个用西里尔字母写的品牌，和那个用拉丁字母写的品牌，是同一个实体。

你自己的页面上同时给出两种写法，就是在提供最直接的一条对应证据。

没有这条证据，系统只能靠其他信号去猜。跨语言理解能力这几年确实在涨，但它补的是语义那一层，补不了你没声明的对应关系，猜错的后果就是品牌信号被分成两份。

被分成两份的表现是：搜其中一种写法能出品牌信息面板，搜另一种什么都没有。

这类问题在实体消歧的信号管控里很典型，而标记是成本最低的一处发力点。

这条证据的可信度还跟它出现在哪里有关。放在自己官网的标记里，是品牌方的第一人称声明，分量高于任何第三方页面上的对应关系。所以这件事别指望靠外部提及慢慢积累，自己标一次的效果比等半年更直接，成本也只是改一个字段。

三种书写系统并存的市场怎么排

有些市场的情况更复杂，同一门语言存在两套官方字母，用户两套都在用。

塞尔维亚语是最典型的例子，西里尔和拉丁两套字母并行，同一个词有两种合法写法。

这时候主名称填哪一套，取决于目标用户群体的实际使用偏好，通常拉丁那一套在电商场景里更常见。

另一套放进别名，再把品牌的原文名也放进去，一个字段可以放多个值。

这类双字母市场的处理逻辑在标记层比在内容层简单得多，因为标记允许并列，内容必须选一个。

别名字段不要滥用，只放真实存在的其他写法，别把关键词变体往里塞。

要避免的一个做法是主名称和别名两边都填拉丁原名，只是大小写或者空格不同。别名字段的意义在于提供一个真正不同的写法，让系统有机会把两个字符串关联起来；填两个几乎相同的值，等于什么信号都没提供，还让标记看起来像是被应付了一下。

语言标签里的书写系统子标签什么时候必须写？

同一门语言两套字母的市场

标准语言标签允许在语言码后面加一个书写系统子标签，四个字母那种。

绝大多数语言用不上它，因为一门语言通常只有一套通行的书写系统。

需要它的场景很具体：同一门语言确实有两套并行的书写系统，而且都在正式使用。

塞尔维亚语是标准案例，两套字母各有对应的子标签写法。

中文的简繁也属于这一类，这也是站内做简繁两套内容时会遇到的同一个问题。

除了这几个明确的场景，其他语言写上书写系统子标签属于多余，规范本身也建议省略。

省略这条规则的依据是标签规范里的一个原则：能从语言码推断出来的信息就不要重复写。既然某门语言只有一套通行文字，写出来不增加任何信息，反而让标签变得不标准、更难跟其他系统的值对齐。

要注意的是，这个子标签描述的是内容实际用了哪套文字，不是网站支持哪几套。如果你的站为两套字母各做了一份内容，那是两个页面各自声明各自的文字；如果只做了一份，就只声明那一份用的文字，别把支持能力写进内容属性里。

书写系统子标签跟地区子标签不是一回事

这两个子标签经常被混淆，它们在标签里的位置和含义都不同。

书写系统子标签说的是用什么文字写，地区子标签说的是面向哪个地区。

一门语言可以在同一个地区有两套文字，也可以在两个地区用同一套文字。

所以两者是独立的维度，需要的时候可以同时出现在一个标签里。

顺序是固定的：语言码在前，书写系统在中间，地区在后。

写反了整个标签就不合法，解析方会当成未知标签处理。

实际维护里，这三段的取值都可以在语言子标签注册表里查到。这份注册表是所有合法子标签的唯一来源，拿不准某个写法存不存在的时候查它，比在网上搜到的示例可靠得多。

实际会同时用到两个子标签的场景并不多，最典型的是同一门语言在两个国家分别用两套文字的情况。绝大多数站点只需要语言码，少数需要语言码加书写系统，再少数才需要三段齐全。写标签的原则始终是能省则省，多写的每一段都是一次可能出错的机会。

写错了会怎样，不写会怎样

先说不写：在只有一套文字的语言里不写，完全正确，没有任何损失。

在两套文字并行的语言里不写，损失是系统无法从标签判断这份内容用的是哪套字母。

它仍然可以从内容本身推断出来，所以损失有限，但你放弃了一次明确声明的机会。

再说写错：把地区子标签写在书写系统的位置上，标签直接不合法。

用了注册表里不存在的四字母组合，同样不合法。

两种情况的后果一样，解析方丢弃这个值，等于什么都没写。

两相比较，不写的风险远小于写错的风险：不写只是少了一个明确信号，写错则是整个值被丢弃，连语言码那部分也一起没了。所以拿不准的时候默认少写，等确认了注册表里的正确写法再补上，这个顺序在标签这件事上几乎总是对的。

多语言站的Schema结构可以共用，值必须分开

结构共用，值分开

做多语言站的时候，最省事也最正确的思路是：标记的结构在所有语种之间共用一套。

用哪些类型、有哪些字段、字段之间怎么嵌套，这些跟语言无关。

需要按语种分开的只有值，而值里面又只有一部分需要真正分开。

语言标签必须分开，名称类字段需要分开，格式字段其实不需要分开。

价格数值在所有语种下都是同一个格式，货币代码按市场定，跟语言无关。

把这层关系理清之后，模板的设计就很清楚了：一套结构，若干个按语种取值的变量。

模板化输出的三个必须参数化的字段

如果只能改三个字段，优先把这三个做成参数。

第一个是语言标签，它必须跟当前页面的实际语言一致，绝不能写死。

第二个是名称类字段，非拉丁市场的主名称与别名要按语种取值。

第三个是货币代码，多市场站点上它跟着市场走，不能沿用英文站的值。

这三个改完，绝大多数跨语种的标记问题就解决了七八成。

剩下的格式字段问题，靠前面说的从数据源取原始值这条实现原则来兜。

这三个字段有个共同点：它们都是那种写死之后不会报错、也不会有任何可见异常的值。模板里的其他常量写错了，页面上多半会露馅，这三个不会。所以它们既是最容易出错的，也是最不容易被发现的，优先级自然排在最前面。

补充一句，参数化不等于自动化。语言标签可以从页面配置自动推导，货币代码可以从市场配置推导，但名称类字段推导不出来，它必须由懂当地市场的人填一次。把它做成配置项交给本地化团队维护，比让开发去猜靠谱得多。

一个语种一份还是一个模板多份

实现方式上有两条路，各有各的适用场景。

一条是每个语种维护一份独立的标记模板，好处是灵活，坏处是改一处要改好几遍。

另一条是共用一个模板，所有语言相关的值走变量，好处是一致性有保障。

语种数量少于五个的时候两种都行，超过五个之后共用模板的优势会迅速拉大。

判断标准是：你有没有信心保证十份模板在下一次改版之后仍然完全一致。

多数团队没有这个信心，所以默认选共用模板那条路。

标记写完怎么验，验哪几项？

语法层的校验只能发现一半问题

写完之后第一步当然是跑校验工具，看语法有没有错、必填字段有没有缺。

这一步能发现的问题是：括号没闭合、字段名拼错、类型用错、必填项缺失。

发现不了的是：语言标签写的是英语而内容是波兰语，价格数值被本地化过，国家字段填了国名。

这些在语法上全部合法，工具挑不出毛病。

换句话说，校验工具管的是格式对不对，管不了内容对不对。

而小语种站上出问题的恰恰全是内容对不对那一类。

官方的测试工具这两年也在换代，早年那个通用的结构化数据测试工具已经宣布要退场，取而代之的是按富媒体类型来验的新工具。工具换了，能力边界没变：它们查的仍然是语法和资格，不是值的正确性。

还有一类问题两边都查不出来：字段填了，值也合法，但值是错的。比如库存状态永远写着有货，或者评分数量是个写死的常量。这类值在语法上无懈可击，只有拿它跟真实业务数据比对才能发现，属于第三层检查，需要接进数据源才做得了。

语言与格式这一层要自己写检查

既然工具管不了，就得自己补一套检查，而且这套检查很容易写。

抓取页面，把标记块解析出来，逐条断言。

语言标签的语言部分必须等于该页面所属语种，不等就报警。

价格字段必须匹配纯数字加可选小数点的模式，出现逗号或空格就报警。

日期字段必须匹配标准时间格式，国家字段必须是两个大写字母。

电话字段必须以加号开头，货币代码必须是三个大写字母。

这套断言加起来不到二十行，一次写好可以用很多年，而且它抓到的问题正好是校验工具漏掉的那一半。JSON-LD这种格式本身就是结构化的，解析出来是标准的数据对象，写断言比写正则容易得多。

这套断言最好跟内容发布流程绑在一起，而不是当成独立的巡检任务。绑进流程的检查会在问题产生的那一刻拦下来，独立巡检则是在问题存在了一段时间之后才发现，而这段时间里搜索引擎已经按错误的标记抓过好几轮了。

逐字段过一遍的清单

上线前的人工检查也需要一张清单，按前面的三分法排就行。

语言类：语言标签跟内容语言一致，客服语言字段填了标准标签而不是语言名。

格式类：价格纯数字，货币三字母代码，日期标准格式带时区，电话加号开头。

名称类：主名称是当地实际写法，别名补上另一种书写系统。

地址类：国家字段填代码，其余字段按结构逐项填，不要塞成一整串。

最后再看一眼：这些值是这个语种自己产生的，还是从英文站带过来的。名称类字段的取值对不对，最终还得靠母语审校那一道验收确认，脚本只能查形态查不了地道不地道。

这张清单最好按语种各走一遍，不要抽一个语种代表全部。跨语种的标记问题有个特征：它往往只出现在部分语种上，因为不同语种的模板是在不同时间、由不同的人复制出去的。抽查一个语种全绿，另外几个语种可能各有各的错法。

上线后的抽查怎么做

上线之后还要抽查，因为标记有一个特点：它会在你不知道的时候被改掉。

改动来源包括模板更新、插件升级、前端重构，任何一次都可能覆盖掉之前的修正。

抽查的频率按改版节奏定，稳定期一个季度一次，改版期每次上线后都跑。

抽查的对象不必是全站，每个语种抽几个代表性页面就够，问题通常是全站性的。

把断言脚本挂进定期任务，出问题自动报警，比人工抽查可靠。

报警要带上是哪个语种哪个字段，否则收到通知还得再排查一遍。

抽查还有个容易被忘掉的对象：那些不常更新的页面，比如关于我们、联系方式、配送政策。这些页面上的标记往往是最早写的，也是改版时最容易被漏掉的，而它们承载的恰恰是客服语言、地址、电话这几个跟本地化关系最紧的字段。

这套做法怎么落进现有的开发流程？

谁负责：前端、内容还是检索这一侧

职责不清是这类问题反复出现的根源，所以先把分工定下来。

前端负责实现：把值从数据源取出来写进标记，保证不走本地化函数。

内容或本地化团队负责名称类字段的取值，因为只有他们知道当地实际写法。

检索这一侧负责定义规则、写断言脚本、验收。

三方各管一段，中间的交接物是一份字段规范表，写清每个字段的格式要求。

规范表要具体到能直接照着写代码，不要写成原则性的描述。

这份表跟结构化数据本身的设计是两份文档，前者管值怎么填，后者管结构怎么搭，别混在一起写。

分工里最容易漏掉的一环是谁来复核。三方各管一段之后，需要有一个人在上线前把三段拼起来看一遍，确认字段规范表上的每一条都落地了。这个角色通常落在检索这一侧，因为只有这边同时关心值的正确性和它在搜索里的后果。

什么时候会悄悄回退

修好的标记会回退，这几乎是必然的，值得提前防。

最常见的回退场景是换主题或者换插件，新模板带着一套自己的默认标记覆盖上来。

第二常见的是加了新语种，新语种的模板是从某个老语种复制的，把老问题一起复制了。

第三是前端做本地化改造时，顺手把标记里的值也接进了格式化函数。

三种场景的共同点是改动方并不知道这些字段有特殊要求。

防回退的办法只有一个：把断言脚本挂进上线流程，让它自动拦。

六步落地路线

整篇压成六步，照着排期就行。

第一步，导出各语种页面的标记块并排比对，找出所有从英文站带过来的写死值。

第二步，把语言标签改对，去掉不必要的地区子标签，跟页面实际语言对齐。

第三步，把价格、日期、电话、货币这几个格式字段改成机器格式，实现上走原始值。

第四步，地址结构逐字段填，国家字段换成两字母代码。

第五步，非拉丁市场配好主名称与别名，两种书写系统都进标记。

第六步，写二十行断言脚本挂进上线流程，季度抽查一次。

六步里第三步的收益最直接，因为它修的是真正会导致富媒体结果消失的错误；第六步的收益最长久，因为它防的是同一批错误再回来。前面五步是一次性工程，第六步是长期保险，两者缺一不可——只做前五步的团队，通常在下一次换主题之后就回到了起点。

常见问题解答

inLanguage到底该不该带地区子标签？

默认不带，只写语言码。带地区的前提是这份内容在语言层面真的做了地区化调整，用词、拼写、术语都跟另一个地区的版本不同，比如巴西葡萄牙语和欧洲葡萄牙语那种程度的差异。仅仅因为投放给不同市场就带地区码属于过度声明，它会把本可以合并的语言信号拆成好几份。一个朴素的判断法：把两个版本的正文并排给母语者看，他看不出语言差异就别带。

价格字段能不能带货币符号？

不能，价格字段只接受纯数值，货币信息放在专门的货币字段里，用三个字母的国际代码。这是最常见的错误之一，因为页面上显示的价格天然带着符号，模板直接取用就出问题了。更隐蔽的版本是数值本身被本地化过，千分位和小数点按当地习惯写，解析器读到逗号会截断或者失败。根治办法是标记里的值直接从数据源取原始数字，绕开前端的格式化函数。

品牌名在西里尔市场，主名称该填哪一种写法？

填当地用户实际会搜、实际会看到的那一种。如果品牌在当地已经有被接受的音译写法，就填音译；如果当地用户习惯直接打拉丁原名，就填原名。判断依据是搜索数据和用户输入习惯，不是内部品牌规范。另一种写法放进别名字段，两者都进标记，这个组合对实体识别最有利，能避免同一个品牌被拆成两个不相关的实体。

校验工具报告全绿，是不是就没问题了？

不是。校验工具查的是语法和必填项，也就是格式对不对；它查不出内容对不对。语言标签写成英语而内容是波兰语、价格被本地化过、国家字段填了本地语言的国名，这些在语法上全部合法，工具一个都挑不出来。而小语种站上出问题的几乎全是这一类。补救办法是自己写一套断言，逐字段检查值的形态，二十行代码的事，抓到的正好是工具漏掉的那一半。

多语言站是每个语种一份标记模板，还是共用一份？

语种少于五个的时候两种都行，超过五个就该共用一份模板，所有语言相关的值走变量。判断标准很实际：你有没有信心保证十份独立模板在下一次改版之后仍然完全一致。多数团队没有，所以共用模板加参数化是更安全的默认选择。必须参数化的字段优先级排序是语言标签、名称类字段、货币代码，这三个改完能解决大部分跨语种的标记问题。

地址里的城市和街道要不要也换成代码？

不用，也没有通用代码可换。只有国家字段有两个字母的标准代码，那是个例外。城市、地区、街道这些字段本来就是给人看的文本，用当地语言写完全正确，也应该这么写。要注意的只有一点：别把整个地址塞进一个字段里，逐字段填写虽然啰嗦，但它让地址能在任何市场被正确重组，塞成一整串的话接收方只能拿到一段没法拆的文本。

标记修好之后会不会又变回去？

大概率会，而且回退的场景相当固定：换主题或换插件时新模板带着默认标记覆盖上来；新增语种时从某个老语种复制模板，把老问题一起复制过去；前端做本地化改造时顺手把标记里的值也接进了格式化函数。三种场景的共同点是改动的人并不知道这些字段有特殊要求。唯一有效的防线是把断言脚本挂进上线流程自动拦截，靠文档和口头交代拦不住。

权威参考资料