非拉丁字母的站点上，同一张商品图的文件名和alt要用两套字母写同一个词

摘要：一张商品图身上有六个能写字的位置，其中两个属于URL层、四个属于文本层。在非拉丁字母的市场里这两层被强行分开：文件名这一层只能用拉丁字母，否则地址栏里变成一长串百分号编码，日志、外链、客服截图全部认不出来；alt和图注这一层只能用本地字母，因为用户搜的就是本地字母。同一个商品词，在同一张图上被迫写成两套字母。英文站永远碰不上这件事，因为它六处填的是同一个字符串。附带两笔账：alt不超过125字符那条经验值不能直接抄，各书写系统同字符数装的信息量差两三倍；图上烧了字，跨语言复用面直接掉到零。

为什么图片这一层是小语种站上最容易捡的那块流量？

本地对手的图片字段多半是空的

做小语种站的人习惯把注意力放在标题和正文上，图片字段往后排。

本地的竞争对手也这么想，而且他们排得更后。

原因很实在：商品图大多是从供应商或者品牌方那儿拿的，连带文件名一起拿过来。

后台上传时alt字段留空，或者由系统自动填成文件名。

于是一个本地电商站上成千张图，alt里写的是一串英文字母加数字。

你只要把这个字段按本地语言认真填一遍，在这个赛道上就没什么对手。

这跟正文的竞争格局差别很大。正文这一层本地站有天然优势，他们的语言比你地道、内容比你贴近本地生活；图片字段这一层不比语言功底，比有没有人愿意把它当成一件正经事来做，而这件事全行业都懒。保哥手上一个做彩妆和防晒的客户，第一批图只是把alt从空白改成了本地语言的商品描述，两个月后图片入口的进站量涨了一截，正文一个字没改。

图片是唯一不需要翻译的资产

做多语言站最贵的是内容，因为每加一门语言就要重写一遍。

图片是个例外：一张口红的产品图，在任何语言的站上都是同一张。

拍摄、修图、压缩、裁切这些成本只付一次。

需要按语言重做的只有围绕它的文字，而文字的成本远低于重拍。

所以图片在多语言项目里的性价比结构跟正文完全不同。

这个优势有一个前提，也是本文后面要专门讲的一节：图上不能烧文字。

把图片理解成一次生产多处复用的资产，会改变你排预算的方式。同样一万元，花在图片上产出的是十一个语言版本共用的东西，花在文案上产出的是一个语言版本的东西。这条账在印度那种十一门语言分摊九套书写系统的市场里格外明显，因为语言门数越多，可复用资产的杠杆就越大。

这块流量的入口不止图片搜索

图片字段填好之后，受益的入口不只有图片搜索这一处。

网页搜索的结果里越来越多带缩略图，能不能被选中跟图片字段有关。

用图找图这类以图为输入的搜索，靠的是图片内容加上下文文字。

社交平台抓取分享卡片时会读图片相关的标记。

站内搜索如果索引了alt，本地用户用本地词搜商品的命中率会提高。

无障碍这一头也顺带解决了，屏幕阅读器读的就是alt。

一个字段同时服务五六个消费方，这在SEO里不算常见。读图能力与视觉搜索那套机制讲的是引擎怎么理解图片本身，本文讲的是同一张图周围那些文字该用哪套字母写——前者是引擎侧的能力，后者是你这边能控制的输入。

这里要提醒一句别把图片入口当成救命稻草。它的量级通常是网页搜索入口的两三成，好处是它便宜、见效快、竞争少，坏处是它撑不起一个市场的主要流量。合理的定位是拿它当第一批可见成果去换团队对小语种项目的耐心，主力仍然要压在正文和类目结构上。

一张图上到底有几个能写字的位置？

六个位置，各自服务不同的读者

先把位置数清楚，不数清楚就没法讨论该用哪套字母。

第一个是图片文件名，出现在URL里。

第二个是alt属性，机器和屏幕阅读器读它。

第三个是title属性，鼠标悬停时显示，实际作用很小。

第四个是图注，figure与图注这一组结构是它的标准写法，人和机器都读。

第五个是图片上下两段正文，它给图片提供语境。

第六个是结构化数据里描述这张图的那组字段。

六个位置里只有第三个可以省略不写，其余五个都值得填。省略title的理由是它在移动端根本不会触发，而且它和alt重复时反而会让屏幕阅读器读两遍。剩下五个位置的关系不是互相替代，是分工：URL层负责可读性和可追踪性，文本层负责检索匹配和无障碍。

文件名和contentUrl属于URL层

文件名和结构化数据里的图片地址字段，本质上是同一个东西的两处出现。

它们的取值都是URL，而URL的字符集受规范约束。

国际化资源标识符那份规范允许非ASCII字符，但要求传输时做百分号编码。

编码之后一个本地字母变成三到九个字符的转义序列。

浏览器地址栏可能会把它显示回原文，日志、报表、外链里通常不会。

所以这一层的约束不是不能用本地字母，是用了之后代价由你自己承担。

把这一层单独拎出来的意义在于：它的读者跟文本层完全不同。文件名的读者是你的运维、你的数据分析师、贴外链的站长、把商品链接发到客服窗口的用户。这些读者要么读的是纯文本日志，要么读的是被截断的URL片段，本地字母在这些场景下的还原率都不高。

alt、图注、周边正文属于文本层

文本层的三个位置有一个共同点：它们的读者是本地用户和搜索引擎的语言模型。

alt是给看不到图的那一方看的，包括屏幕阅读器和抓取程序。

图注是给看得到图的人补充信息的，语气可以更像一句人话。

周边正文提供语境，让引擎判断这张图跟这个页面的关系。

三处都必须用本地字母，因为用户输入的查询就是本地字母。

写成拉丁转写等于把匹配的机会主动扔掉。

三处内容不该完全一样。alt写得简洁准确，图注可以带一点场景和用途，周边正文承担的是解释和延展。三处都写同一句话，等于浪费了两处位置，而且屏幕阅读器用户会连着听到重复内容，体验不好。

还有一个位置上的细节：图注和周边正文都在页面可见区域里，它们要同时服务本地用户的阅读体验和检索匹配，所以不能写成关键词罗列。alt不在可见区域，理论上可以写得更贴近检索口径，但它要过屏幕阅读器这一关，所以也不能罗列。三处都受可读性约束，只是约束来自不同的读者。

一张分治表把六个位置排清楚

把六个位置、该用的字母、读它的人、写错的后果排成一张表，落地时对着填就行。

这张表最有用的地方是它把书写系统这一列显式写出来了。

没有这一列，团队会默认六处用同一套字母，然后在某一处出问题。

出问题的方式通常不是报错，是某个入口的流量一直上不来。

表里还有一列标注这个位置能不能自动生成。

能自动生成的位置放进流水线，不能的留给人工。

这张表的第二列是本文的核心：六个位置里两个必须拉丁、三个必须本地字母、一个建议留空。同一个商品词要在这六处按两套规则分别写一遍，而且不能写反。英文站的同一张表里，第二列六行全是同一个值，所以英文的图片SEO教程从来不讨论这一列，你照着抄就会在这里出错。

文件名和alt为什么必须用两套字母写同一个词？

URL层不接受本地字母，除非你接受百分号编码

把一张口红图命名成本地语言的商品名，看起来是最自然的做法。

存到服务器上没问题，页面显示也没问题，问题出在URL被写成文本的时候。

俄语的靴子这个词做成文件名，编码之后是%D0%B1%D0%BE%D1%82%D0%B8%D0%BD%D0%BA%D0%B8这样一串。

一个词变成三十多个字符，而且完全不可读。

这串东西出现在日志里，排查某张图的抓取情况就得先解码一遍。

出现在别人贴的外链里，多半会被截断或者转义两次。

更麻烦的是二次编码。有些系统会把已经编码过的串再编码一次，百分号本身变成%25，图片直接404。这类问题的排查成本很高，因为出错的地方在传输链路上，页面源码看着完全正常。百分号编码的规则本身不复杂，麻烦的是链路上有几个环节各自编码一次。

文本层不接受拉丁转写，因为用户搜的是本地字母

反过来看alt。把alt写成拉丁转写，页面照样正常，无障碍照样能用。

但用户在搜索框里打的是本地字母，转写形态跟查询串对不上。

引擎有一定的跨书写系统匹配能力，但它对这类匹配的置信度不高。

在商品词这种短查询上，字符串能不能对上仍然很重要。

而且屏幕阅读器读拉丁转写会读成一串怪音，本地用户听不懂。

所以alt这一层的答案是唯一的：本地字母，没有折中。

有个中间做法值得一提：alt写本地字母，另外在页内某处放一份拉丁写法当别名。这不是给alt用的，是给那些习惯用拉丁字母打本地词的用户准备的。拉丁字母打出来的那半边搜索在希腊语和印度诸语言市场占比很高，但它该被放在页内文本里，不该挤进alt。

英文站上这两处是同一个字符串，所以没人想过这个问题

英文站上一张口红图，文件名叫matte-lipstick-red.webp，alt写matte red lipstick。

两处的字符集完全一样，字符串几乎一样，写的人根本不需要做任何决定。

所以英文的图片优化教程里，文件名和alt永远被放在同一节里讲，规则也一样：写清楚、别堆词、用连字符分隔。

把这套规则搬到非拉丁市场，团队会自然地在两处填同一个值。

填成本地字母，URL那头出问题；填成拉丁转写，检索那头出问题。

两个后果都不会立刻暴露，所以这个错误能在站上待很久。

这是英文经验最容易失效的一类地方：不是规则本身错了，是规则背后有一个没写出来的前提。那个前提是文件名和alt用的是同一套字符集。前提在英文里恒成立，所以没人写下来；换到非拉丁语种，前提没了，规则跟着塌一半。文件名、alt与压缩那套通用做法照抄没错，唯独这一列要重新决定。

两套字母之间要靠一份映射表对齐

两套写法各写一遍，接下来要保证它们对得上。

对不上的典型症状是文件名叫botinki，alt里写的却是另一个近义词。

解决办法是一份商品词映射表，一行记录本地写法、拉丁转写、英语对照。

转写规则要固定成一套，别让不同的人各转一版。

规则可以借用官方的罗马化方案，可读性略差但一致性最好。

表建好之后文件名可以按规则自动生成，人工只管alt那一列。

映射表还有一个副作用好处：它天然就是一份图片关键词表的骨架。后面讲图片词表要比正文词表多两列，多的那两列正好是这张映射表里的转写列和英语列。所以这两件事应该一起做，做完一份表两处用。

映射表要不要包含全部商品词，取决于站的规模。几百个SKU的站可以逐个词做，几万个SKU的站只做类目词和属性词，具体商品名靠模板拼接。折中的判据是看这个词会不会重复出现在多张图上：会重复的就进表，只出现一次的交给模板。这样表的规模能控制在几百行以内，一个人半天能维护一遍。

图片文件名在非拉丁语种站上还剩多少价值？

网页排名这一头本来就帮不上

先把一个流行说法摆平：给图片改个含关键词的文件名，能不能帮网页排名。

基本帮不上。网页的排名靠的是页面的文字内容和站外信号，图片文件名的权重低到可以忽略。

这一点在英文站上就已经成立，跟语种无关。

所以那种把商品全部关键词塞进文件名的做法，收益接近零。

它的真实用处在别处：图片检索的匹配、内部管理的可辨识、以及排查问题时的可读性。

三个用处里只有第一个跟排名有关，而且是弱信号。

把这个前提说清楚很重要，因为它决定了后面的取舍。如果文件名是强排名信号，那非拉丁语种站就得纠结要不要为了它承受百分号编码的代价；既然它只是弱信号加管理便利，那取舍就很清楚了——挑对管理更友好的那套字母。

图片检索这一头的弱信号被编码吃掉了

图片检索这边，文件名确实是一个可读的弱信号。

引擎会把文件名里的词切出来，跟alt和周边文字一起参考。

问题是本地字母的文件名在传输时已经变成了百分号序列。

解码回原文对引擎不是难事，但这一步增加了不确定性。

更实际的损失在别处：这串编码贴到任何地方都不像一个词。

本来能顺手带来一点可读性收益的字段，变成了一串谁都不愿意看的乱码。

所以这里的结论不是本地字母的文件名会被惩罚，是它把一个本来微弱的正收益换成了一堆实际的麻烦。用一个弱信号去换日志可读性、外链可辨识、排查便利这三样东西，这笔交易怎么算都不划算。

顺着这条再多说一句：把本地字母的商品词写进文件名，还会让你的图片在被第三方引用时失去可追踪性。别人从你站上拿图，通常是复制URL，而复制过去的那串编码在他们的页面上就是一串乱码，谁也不会去查它原本是什么词。本来能顺手带一点品牌可辨识度的地方，也一起丢了。

所以文件名一律走拉丁，语言信号全压到alt上

结论很干脆：图片文件名统一用拉丁转写，语言信号全交给alt，不做例外。

转写规则固定，全站一致，能自动生成。

语言层面的信号全部交给alt、图注和周边正文承担。

这三处加起来的信号强度远超文件名，所以损失几乎为零。

而收益是整套URL体系保持可读、可追踪、可粘贴。

这条规则简单到可以写进上传流程的校验里：文件名只允许小写拉丁字母、数字和连字符。

需要跟另一件事划清界限：页面URL和图片文件名的答案不一样。页面URL用本地字母还是拉丁转写那篇给出的是权衡，因为页面URL有几条支持本地字母的理由——它会出现在搜索结果里被加粗、它会被当成外链锚文本的一部分、它对本地用户有可读性。图片文件名一条都不成立：它不出现在结果页、不当锚文本、本地用户根本看不到它。同一个技术问题，两个位置的答案相反。

alt写多长才够，英文那个125字符能直接抄吗？

125这个数字是怎么来的

alt不要超过125字符，这条建议流传很广，很多人以为它是规范条文。

它不是。HTML规范里关于alt的那一节只讲这个属性该表达什么，从头到尾没有字数上限。

125这个数字来自无障碍社区的实践经验，跟部分屏幕阅读器的朗读行为有关。

它的本意是提醒你写一句话，不要写一段话。

换算成英文大概是二十个词，正好是一句自然的描述句。

所以它约束的其实是信息量，字符数只是一个方便的代理指标。

把代理指标当成硬规则，是这类经验值最常见的误用方式。判断一条alt写得合不合适，看的是它能不能让听不到图的人在脑子里建立一个准确的印象，而不是它有几个字符。无障碍社区那份alt写法指南讲得很清楚，重点在于表达图片在这个语境里的功能。

同样125个字符，各语言装的信息量差两三倍

代理指标一旦跨语言就失灵了，因为字符的信息密度差得很远。

英文125个字符装二十个词，日语125个字符能装一段完整的商品描述加使用场景。

天城文和泰文的情况类似，一个字符携带的信息量明显高于拉丁字母。

照125这个上限写，非拉丁语种的alt会写得过长，读起来像一段说明书，写alt那几条常见反例里长得离谱是排第一位的。

屏幕阅读器把它一口气念完，用户听到一半就失去耐心了。

所以这些语种的实际上限应该更低，按字符算大概是英文的三分之一到二分之一。

这里有一件容易忽略的事：alt过长的害处不在SEO，在无障碍体验。引擎不会因为alt长就扣分，它会自己截取或者忽略多余部分；被折磨的是那些真正依赖alt的人。所以这条上限该按人的耐受度定，而人的耐受度是按听多久算的，不是按字符数算的。

改成按信息单元数定：主体、属性、场景

可用的替代口径是数信息单元，一个信息单元就是一个能独立回答问题的点。

商品图的alt一般需要三个单元：这是什么、什么规格或颜色、在什么场景下用，怎么写出一条好alt那份说明里的例子也是这个结构。

三个单元写完就停，不管这门语言用了多少字符。

如果图片本身传达了第四个信息，比如包装形态或者对比关系，可以加到四个。

超过四个说明你在写商品描述，那些内容该放到图注或者正文里。

这个口径的好处是它跨语言恒定，不需要为每门语言重新定一个字符上限。

用这张表验收alt比数字符方便得多，因为它可以交给不懂那门语言的人做：把alt机器翻译回中文，数一数有几个单元、有没有缺主体。这是一个不依赖语言能力的检查，跟母语审校验收里那几个自己也能跑的自检是同一类做法。

复合词语言的反方向问题

信息密度这件事在德语这类语言上是反过来的。

德语把修饰关系拼成一个长单词，一个词就能占二十多个字符。

125个字符只装得下五六个词，一句完整的描述句都不一定装得下。

照125这个上限写，德语的alt会被迫写得过于简略。

所以同一条经验值在两个方向上都会出错，只是错的方向相反。

这也是为什么按信息单元数定的口径更稳：它不关心一个概念用了几个字符表达。

顺带一句，复合词在图片这一层还有别的影响。德语复合词把关键词拼成一个长单词之后，alt里到底写整个复合词还是拆开写，答案跟正文关键词的处理一致：写用户实际会搜的那个形态，通常是整词。

再往前推一步，凝集程度高的语言在alt里还有个便利：一个复合词就把主体和属性两个信息单元一起说完了，剩下的字符可以全给场景。芬兰语、匈牙利语这类靠格尾承载关系的语言也类似，一个词形能表达出别的语言要三个词才说清的关系。这类语言的alt往往写得比英文短，但信息量不少。

用户搜图时打的是本地字母还是拉丁字母？

图片搜索是识别型查询，输入更随手

正文查询和图片查询的用户心态不一样。

搜文章的人想找到答案，愿意多花两秒把词打准。

搜图的人往往在辨认、比对、找灵感，输入更随手。

随手的直接后果就是不切输入法，用手边的英文键盘直接拼。

拼出来的可能是本地词的拉丁形态，也可能干脆是英语词。

这个比例在几个非拉丁市场都明显高于正文查询。

这条差异的实用价值在于：它意味着图片这一层的关键词策略不能直接沿用正文那一套。正文词表刚刚花了很大力气把拉丁变体和英语混词剔除干净，图片词表却需要把它们请回来。同一个团队在同一个季度里做两件方向相反的事，不写清楚就会来回改。

拉丁与英语混着打的比例比正文查询高

混着打的形态有三种。

第一种是整串拉丁转写，比如把本地语言的口红那个词按音拼出来。

第二种是本地词加英语词，比如本地的颜色词配英语的商品品类词。

第三种是纯英语，尤其是国际品牌名和品类名。

三种形态在图片查询里都很常见，而在正文查询里第三种占比要低不少。

品牌名这一项尤其明显，因为品牌方自己就用拉丁字母写它。

品牌名的写法有它自己的一套讲究，品牌名叫什么由当地用户的输入法决定那篇专门讲这个。图片这一层的处理更简单一点：品牌名两种写法都可以出现，因为它在alt里占的字符不多，写成本地写法加括号里的拉丁原名是个常见做法，也不会显得堆砌。

这决定了图片关键词表要多两列

把三种输入形态折成两列加进词表：拉丁转写列、英语对照列。

这两列的取值不需要覆盖全部变体，取最主流的一到两种。

它们的用途也不是全部写进alt，而是分配到不同位置。

alt写本地字母，品牌名可以带拉丁原名。

拉丁转写放到页内的商品别名或者常见问法区块。

英语对照放到国际化版本的页面上，不混进本地语言页面。

分配这一步是关键。三种形态如果全塞进alt，alt就变成了关键词列表，既伤无障碍体验又容易被判成堆砌。正确的做法是让不同形态出现在不同位置，同一个页面覆盖三种查询，而每个位置各自读起来都很自然。

图片关键词表凭什么要比正文关键词表多两列？

正文词表要剔除的那两列，图片词表要保留

做正文关键词表时，第一件事往往是把拉丁转写和英语词剔掉。

剔的理由很正当：正文要写得地道，混着拉丁字母的正文读起来不像本地内容。

图片词表的目标不一样，它服务的是一批输入更随手的查询。

所以同一个词在正文词表里只留本地写法，在图片词表里要留三种写法。

两份词表的字段结构不同，是因为它们服务的查询分布不同。

把它们合成一份，必然有一边被将就。

这条差别在项目管理上有个具体后果：图片词表不能由正文词表导出，得单独建。很多团队图省事，直接拿正文词表当图片词表用，结果图片这一层只覆盖了本地字母那一种输入形态，而这一层恰好是拉丁输入占比最高的地方。工具查不到数据时那几个补数办法在图片词表上同样适用，而且更好用，因为图片查询的形态更容易从站内搜索日志里看出来。

五列结构长什么样

一份够用的图片关键词表有五列。

第一列本地写法，用于alt和图注。

第二列拉丁转写，取最主流的一到两种，用于页内别名。

第三列英语对照，用于国际版本和品牌名括注。

第四列文件名形态，按固定转写规则生成，小写加连字符。

第五列标注这个词属于哪个信息单元：主体、属性、场景。

第五列是这张表里最容易被省掉也最值钱的一列。标了信息单元之后，alt可以按模板组装：主体加属性加场景，从表里各取一个词填进去。这样一批图的alt能半自动生成，人工只负责挑词和最后通读，效率比逐条手写高很多，而质量反而更稳定，因为模板保证了每条alt都有主体。

两份词表分开维护，别合成一份

分开维护的成本没那么高，因为两份表共用第一列。

正文词表新增一个词，图片词表只需要补另外几列。

维护的关键是明确谁负责哪一份，别让两个人各自改同一份表。

常见的分工是内容负责正文词表，运营或者电商负责图片词表。

两份表定期对一遍第一列，保证核心词没有一边缺失。

对表这个动作一个季度做一次就够，不需要实时同步。

有一个不该分开的东西是转写规则。两份表里凡是涉及拉丁形态的，必须用同一套规则，否则文件名和页内别名会出现同一个词两种拼法。规则写成一份文档，或者直接写成一个函数挂进后台，比靠人记住可靠得多。

图上烧进去的那行字，把一张图的复用面砍掉了多少？

无字的图复用面是全部，烧了字就变成按语言重做

一张纯商品图，十一个语言版本用同一张，复用面是百分之百。

图上烧了一行促销文字，复用面立刻掉到零，每个语言都要重出一张。

中间没有过渡状态，因为图上的字要么全对要么全不对。

成本从一份变成N份，而N等于你的语言门数。

更麻烦的是维护：促销文案改一次，N张图全部重出。

设计排期在改版季会直接被这件事吃掉。

这条账在语言门数少的时候不明显，两三门语言的站烧点字也就是多做两三张。门数上到八门十门，它就变成了设计团队的主要负担，而且是那种看起来很琐碎、汇报时说不清、但确实占掉大半工时的负担。

还有一种中间状态值得单独说：图上的文字不是文案而是实物本身带的，比如包装上印的成分表、瓶身上的品牌名。这类图不算烧字，因为那些字是商品的一部分，不需要按语言替换。判断标准很简单：这行字是设计师后加的还是拍进去的，后加的按烧字算，拍进去的按商品特征算。

四档处理办法

第一档最省：图上不放任何文字，文字全部走HTML层。

第二档次之：把文字做成叠在图上的HTML或者SVG层，视觉效果接近烧字，但文本可以按语言替换。

第三档是按语言各出一版图，成本最高但视觉控制最好。

第四档是把文字换成图形符号，比如用箭头、对勾、数字代替文字说明。

四档不是优劣排序，是按场景选：商品主图走第一档，营销横幅走第二档，包装展示图不得不走第三档。

第四档适合流程图和对比图，把语言依赖降到最低。

第二档是性价比最高的那一档，也是最容易被设计流程挡住的一档。它要求设计师交付的不是一张成品图，而是一张底图加一份文字位置说明，前端再把文字叠上去。这个交付方式的改变比技术实现难，因为它动的是设计和前端的协作习惯。改成了就一劳永逸，改不成就每季度重出一批图。

烧字还会撞上字库缺字

图上烧非拉丁文字有一个额外的坑：设计软件里的字体不一定有那些字形。

常见的设计字体对天城文、泰文、谚文的覆盖非常有限。

缺字的表现是显示成空框，或者被替换成一个风格完全不搭的回退字体。

设计师如果不懂那门语言，很难发现某个字被替换了。

还有授权问题：覆盖多书写系统的商用字体授权费不便宜。

这笔钱在网页字体的预算里已经算过一遍，图上烧字要再算一遍。

说清一件事：图上烧字不占首屏的KB预算，因为它不加载字体文件。但它把成本换了个地方付——从带宽换成了设计工时和字体授权。小语种字体在首屏那笔KB账算的是前者，这一节算的是后者，两笔账要分开记，不然会得出图上烧字更省这种错误结论。

结构化数据里的图片字段该按哪套书写系统填？

地址字段是拉丁，说明字段是本地字母

结构化数据里描述一张图的那组字段，同样被两套字母切开。

图片地址字段的取值是URL，所以走拉丁，跟文件名一致。

图注字段和名称字段的取值是给人看的文本，所以走本地字母。

这两类字段在同一个对象里紧挨着，最容易填反。

填反了页面不报错，校验工具也不报错，因为两者的取值类型都合法。

暴露方式是这张图始终拿不到应有的展现，而你查不出原因。

这跟正文与标记的方向问题是同一个家族的问题。正文越本地化越好而标记里要反着写回国际格式那篇讲的是价格、日期、语言标签这几类字段；图片这一组字段的分界线更细：同一个对象里，地址类走机器格式，说明类走本地语言，中间没有统一规则可套。

图片相关的几个字段容易整块复制错

多语言站的结构化数据模板通常从主站复制。

图片那一组字段里，地址会被模板变量替换掉，说明类字段经常留着写死的英文。

于是十一个语言版本的图注全是同一句英文，而且是从英文站带过来的那句。

这种错误的隐蔽性很高，因为它出现在页面源码里而不是页面上。

排查的办法只有一个：逐语种抓一遍源码，把说明类字段的语言核对一遍。

核对可以自动化，判断依据是这个字段的字符是不是落在该语言的码位区间里；顺手可以给图注区块补上声明语言的lang属性。

这个判断写成断言只要几行：取字段值，检查里面有没有本该出现的书写系统的字符。天城文站的图注里全是拉丁字母，那就一定有问题。反过来也要查：图片地址字段里出现了非拉丁字符，说明有人把本地字母的文件名写进了标记。两条断言挂进上线流程，这类错误就不会再回来。

校验工具查不出书写系统填错

结构化数据的校验工具查的是语法和必填项。

它会告诉你缺了哪个字段、类型对不对、值能不能解析。

它不会告诉你这个字段的语言写错了，因为语言不是它的检查项。

换句话说，工具能保证你的标记是合法的，不能保证它是对的。

合法和正确之间那道缝，就是本节这类错误长期存在的地方。

补这道缝只能靠自己写断言，指望工具是没用的。

顺带说一下工具本身的变化：老的那个结构化数据测试工具已经宣布弃用，检查富媒体资格的活交给了富媒体测试工具。两者的检查口径略有不同，但对本节讨论的问题都一样无能——它们不关心你的图注是用哪套字母写的。

一批商品图从供应商拿到手，六个位置怎么排成一条流水线？

入库时先做文件名规范化

供应商给的图，文件名通常是型号、批次号或者一串数字。

入库第一步就把文件名换成规范形态，别等上线前再改。

换的依据是商品词映射表里的文件名列，加上型号和颜色代码。

规则固定成小写拉丁字母、数字、连字符三类字符。

这一步完全可以脚本化，人工只负责把商品和图对上。

规范化之后的文件名同时解决了管理和检索两件事。

放在最前面做的理由是文件名一旦上线就不好改了，改动会产生301或者404，还要连带更新缓存和CDN。图片URL的变更成本比页面URL低一些，但也不是零。趁入库时一次做对，比上线后返工便宜得多。

alt的生成分自动与人工两条路

alt不能全自动，也不该全人工。

可自动的部分是模板组装：从词表里取主体、属性、场景三个词填进句式。

需要人工的部分是挑词和通读，尤其是场景那一格。

人工那一步的工作量比逐条手写小很多，因为句式和候选词都是现成的。

句式要准备两三套轮换，避免一批图的alt全是同一个句式。

轮换不是为了骗引擎，是为了让屏幕阅读器连读几张图时不那么单调。

有一件事绝对不能自动化：拿英文alt机器翻译成本地语言。翻译出来的是语义正确但没人搜的词，跟关键词直译犯的是同一个错。拿词典逐词换出来的关键词表那笔损失，在alt上会以图片入口长期没有流量的形式出现，而且很难归因，因为你看不出alt写得有什么不对。

抽样验收查哪四项

一批图上线前抽百分之十，查四项。

第一项文件名合规：只有小写拉丁、数字、连字符。

第二项alt书写系统正确：里面有本该出现的那套字母的字符。

第三项信息单元齐全：主体和属性必须有，场景尽量有。

第四项长度合理：按信息单元数判断，不按字符数判断。

四项里前两项可以脚本查，后两项需要人工看，但不需要懂那门语言。

不懂那门语言也能查后两项，靠的是把alt机器翻译回中文再数单元。翻译回来的中文哪怕生硬，也足够看出缺不缺主体、有没有把三个单元写成一段说明书。这是个粗糙但有效的自检，比什么都不查好太多。

上线后靠断言脚本兜住回退

图片字段的回退场景很固定。

换后台或者换插件时，alt字段的默认填充逻辑变了。

批量导入新商品时，导入模板里没有alt这一列。

前端改版时把图注模板换成了通用文案。

三种场景的共同点是改动的人不知道这些字段有语言要求。

所以防线只能是自动的：定期扫全站图片，查空alt、查拉丁alt、查非拉丁文件名。

脚本每周跑一次，结果丢进一个报表就够。真正的价值不在发现问题，在于让这件事有人负责——有报表就有人看，没报表这些字段会在下一次改版后集体退回原样，而且没人会注意到。

脚本要查的三项之外，还值得加一条对比项：本周的空alt数量跟上周的差值。绝对数量高不一定是问题，可能是新上了一批商品还没配文案；差值突然跳高才是真信号，说明某个环节的默认行为变了。这条差值比绝对值更适合当告警阈值，也更不容易被长期忽略。

常见问题解答

alt里该不该写品牌名和型号？

品牌名该写，型号看情况。品牌名是用户搜图时的高频输入，而且在非拉丁市场它常常以拉丁原名的形态出现，写成本地写法加括号里的拉丁原名是个稳妥做法，占不了几个字符。型号只在用户会拿型号搜的品类里写，比如3C和汽配；彩妆、服装这类品类用户不搜型号，写进去只是占位置。判断办法是看站内搜索日志里有没有型号查询，有就写，没有就省下这几个字符留给场景描述。

图片文件名用本地字母到底会出什么问题？

页面显示不会出问题，出问题的地方在URL被写成文本的时候。本地字母做文件名，传输时要做百分号编码，一个词能变成三十多个字符的转义串。这串东西在服务器日志里不可读，排查抓取要先解码；贴到外部平台常被截断或者二次编码，二次编码会让百分号本身变成%25，图片直接404。收益那一头呢，文件名对网页排名基本没用，对图片检索只是弱信号。用一个弱信号换掉日志可读、外链可辨识、排查便利这三样，怎么算都不划算。

alt能不能用机器翻译批量生成？

不能直接用。机器翻译产出的是语义正确的表述，而alt需要的是用户实际会输入的那个词，两者经常不是同一个。更稳的做法是先建本地词表，再用模板组装：主体加属性加场景，三个词都从词表里取，机器只负责套句式。这样产出的alt既是本地真实用词，又能半自动化。机器翻译在这条流水线里有一个正当用途——把生成好的alt翻译回中文，供不懂那门语言的人做验收自检。

一张图在不同语言版本要不要用不同的URL？

不要，同一张图用同一个URL。同一个文件在多个语言页面上引用，能共享缓存、共享CDN命中、共享外链信号，而且省掉一大堆存储和同步工作。图片URL不需要带语言标识，因为图片本身没有语言。真正需要按语言变化的是围绕它的文字：alt、图注、周边正文，这三处按语言写。唯一的例外是图上烧了文字的图，那种图本质上已经是不同的资产，自然也是不同的URL。

图注和alt写一样的内容算不算重复？

算浪费，不算违规。两处的读者不同：alt是给看不到图的人和抓取程序看的，写得简洁准确；图注是给看得到图的人补充信息的，可以带上场景、用法、注意事项，语气更像一句人话。写成同一句话不会被惩罚，但等于把一处高可见位置白白丢掉了，而且屏幕阅读器用户会连着听到两遍同样的内容。分工写，两处加起来提供的信息量能翻倍。

纯装饰性的图片，alt该怎么处理？

留空，也就是写成一对空引号，不要删掉这个属性。空的alt是一个明确信号，告诉屏幕阅读器跳过这张图；完全没有alt属性会让阅读器去念文件名，那就变成了念一串拉丁字母加数字，体验反而更差。这条规则跟语种无关，但在非拉丁市场后果更严重：文件名是拉丁转写，念出来对本地用户是纯噪音。分割线、背景纹理、纯粹撑版式的图都属于这一类，商品图和信息图不属于。

图片被搜到了，落地页却不对，怎么排？

先确认这张图被引用在几个页面上。同一张图出现在类目页、详情页、专题页时，引擎要挑一个当落地页，挑的依据是哪个页面跟这张图的关联最强，而关联强度主要看图注和周边正文。想让它落到详情页，就在详情页给这张图配完整的图注和上下文，在类目页那边尽量少给它文字。如果落地页错在语言版本上，那多半是结构化数据里的说明类字段整块复制了另一个语种的文案，逐语种抓源码核对一遍就能查出来。

权威参考资料