英文版跑通之后加语种，对做外贸站和内容站的人来说都是迟早要做的事。AI 把这件事的门槛压得很低：一篇英文稿，半小时能出德语、法语、日语三个版本，术语表都不用翻。但不少站上线三个月之后回头看，谷歌里能搜到的还是只有英文页面，新语种像是石沉大海，抓取记录里有，索引里没有。
多语言 SEO 的上限不在翻译质量，而在两样东西：URL 结构决定谷歌能不能把每个语言版本分开认，hreflang 决定它愿不愿意把对应语言的词分给谁。
翻译做得再顺，这两处没弄对，新语种就是一堆躺在服务器上的页面。反过来，结构和标记弄对了，翻译质量只要过合格线，收录和展现就能正常跑起来。所以多语言 SEO 的第一笔工作量，应该花在动手翻译之前。
一、先定 URL 结构，再谈翻译
多语言站点怎么放语言版本，字面上看只是网址写法的区别，实际上是给谷歌递了一份声明：这些页面是一家人的不同语言版本，还是一个独立站点。常见的四种放法各有脾气。
| 放法 | 权重与收录表现 | 适合什么情况 |
|---|---|---|
| 独立域名（.de / .fr） | 地域信号最明确，但权重互不相通，每个域名要从零养 | 目标市场少而精、预算充足、当地有实体运营 |
| 子域名（de.example.com） | 谷歌当独立站点看待，各语种权重分开积累，需要单独推广 | 语种之间内容差异大，或想单独统计各语种表现 |
| 子目录（example.com/de/） | 共享主域名权重，收录集中、管理省事，也是谷歌明确推荐的写法 | 大多数团队的第一选择，主站有权重加持时效果最直接 |
| 参数式（?lang=de） | 容易被当成动态变体，收录效率低，历史上问题也最多 | 临时过渡可以，不适合当长期结构 |
做内容站或站群的人还要多想一层：语种是加在同一个站里，还是干脆每个语种一个独立站。加在同一个站里，权重集中、互相带得动；拆成独立站，各站可以独立部署、独立备案、按市场单独运营，但每个站都要从头把收录养起来。这两种选择没有对错，取决于团队是想集中兵力打一个域名的权重，还是想按市场分线管理。
结构一旦定下来，改动成本很高：改结构意味着所有语言版本的网址、内链、站点地图、已建索引全部要同步迁移一遍。开工之前把两三年后的语种规划想清楚，比上线之后再改省太多事。
二、hreflang 是语言路由，写错等于没写
同一个页面有多个语言版本时，谷歌需要知道哪个版本该给哪类用户看。hreflang 就是这套语言路由：在页面头部用几行 link 标签声明"法语版在这里、德语版在那里、都没匹配上的走默认版"。它是多语言 SEO 里性价比最高的标记，也是最容易被写错的一处。
语言代码的写法有固定格式，语言在前、地区在后，地区可以省略：
写的时候有几条硬规则，少任何一条谷歌都可能整组忽略：
- 自引用：每个语言版本的页面上，必须包含一条指向自己的 hreflang，漏了自引用是最常见的低错；
- 成组双向：德语页指向法语页，法语页也必须指回德语页；单向引用等于没引用，谷歌会丢掉整组关系；
- x-default 兜底：没有匹配到具体语言时把用户送到哪一版，通常指语言选择页或英文版；
- 代码规范：语言用两位小写、地区用两位大写，别自创写法，zh-cn 这种不规范格式会影响识别；
- 只留一处输出：页面头部、站点地图、插件三处同时输出且内容不一致时，排错会非常痛苦，统一在一处生成。
比 hreflang 写错更致命的是它和 canonical 打架。德语页里如果写着 canonical 指向英文页，等于告诉谷歌"我这页的正式版是英文版"，德语页会被判重、从索引里消失，hreflang 写得再全也救不回来。每个语言版本的 canonical 都应该指向自己。
三、翻译只是原料，本地化才是内容
AI 翻译的语法水平已经够看，但直译稿放到目标市场，常常是"每个字都对，读起来就是不像本地人写的东西"。多语言内容的差距不在语言是否正确，在搜索习惯是否对上：德语用户搜的词、法语用户关注的卖点、日语用户需要的敬语程度，和英文原稿里的关键词往往对不上。
机翻直出的三个通病
关键词直译，目标语言的真实搜法没做调研；
行业术语按字典翻，当地从业者根本不这么叫；
单位、货币、法规、案例全是原语言背景，本地读者无感，转化自然差。
本地化改写要做的事
用目标语言重做一轮关键词与标题调研；
把术语表提前交给 AI，人名品牌名分类词统一口径；
替换本地化元素：货币、尺寸、案例、背书的说法，让内容站得住。
谷歌对 AI 内容的态度这两年说得很清楚：它打击的是规模化生产、对用户没有价值的低质页面，不是 AI 本身。同一条内容机翻成二十种语言、不做本地化、不解决任何一个市场的需求，正好落在"规模化低质"的判定标准里。稳妥的做法是按语种分线推进：先做两三个高价值市场，每个语种的内容都当独立选题对待，跑出效果再扩下一个。
一个实用的分工：AI 负责初稿翻译、结构重排和批量标记生成，人负责目标语言的关键词调研、术语表、标题与摘要的最终定稿。人管策略、AI 管执行，这个比例大概是二比八，成本可控，质量也守得住。
四、几个默认设置，最容易把语言版本堵在索引外
结构和标记都弄对之后，真正让新语种"抓到了但收不进"的，往往是一堆搭站时随手留下的默认设置。它们藏在配置里不显眼，排查时又特别费时间，开工前逐条关掉最省事。
- 按浏览器语言自动跳转：给所有用户和爬虫做自动重定向，看着贴心，实则是收录杀手，细节见后面的提醒；
- 纯 JS 语言切换器：切换按钮只靠脚本生成链接，爬虫顺着抓不到其他版本，语言入口要用真实的 HTML 链接；
- robots 屏蔽残留：新语种上线前常先屏蔽测试，上线后忘了解除，爬虫在门外被挡得干干净净；
- noindex 残留：模板从测试环境复制过来的，页面头部还带着 noindex 标记，收录数永远是零；
- 站点地图漏版本：新语种的 URL 没进 sitemap，或者所有语种挤在一个文件里没有区分，发现异常无从查起。
按浏览器语言自动跳转之所以危险：谷歌爬虫的抓取环境通常默认英文，它访问 example.com/de/ 被脚本跳到英文版，就永远看不到德语页面的内容，索引里自然没有德语版。谷歌官方的建议是避免用自动重定向切换语言，想让用户选，就把语言入口做成可点击、可抓取的链接；真要按语言分流，交给 hreflang 和对方自己的搜索设置去判断。
五、收录上不去，按这个顺序排查
新语种上线之后收录没动静，不要急着改内容，按从便宜到贵的顺序走一遍，多数问题在前三步就能定位。每一轮排查都留个记录，几个语种对比着看，规律会自己浮出来。
两分钟能看完的设置，先排除；被屏蔽或标了 noindex 的页面，后面所有工作都是白做。
逐个语言版本确认 canonical 指向自己，没有被模板统一指到默认语言页。
抽查两三个语种，看自引用、双向引用、x-default 是否齐全，代码格式是否规范。
看爬虫有没有来、抓的是哪些目录、返回什么状态码；来得多却收得少，重点转回页面质量。
按语种分文件提交，站点地图里带 hreflang 注解也可以，让爬虫一次看清所有语言版本的关系。
页面头部该有的 hreflang 输出（以英德法三语种为例）：
<link rel="alternate" hreflang="en" href="https://example.com/" /><link rel="alternate" hreflang="de-DE" href="https://example.com/de/" /><link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/" /><link rel="alternate" hreflang="x-default" href="https://example.com/" />这段代码要出现在每个语言版本的页面里，并且每个版本都包含全部四条。站点规模小的时候手写还能维护，语种和页面一多，靠人肉检查必然出错，用脚本定期抽查自引用和双向引用有没有缺失，是更实际的维护方式。
六、每个语言版本单独盯着看
多语言站最容易犯的管理错误，是看总量。整站的收录和流量在涨，可能只是英文版在涨，德语版一直在原地；整站看着平稳，某个语种可能已经掉了半个月。拆到语种维度看，问题藏不住。
| 盯什么 | 从哪里看 | 异常信号 |
|---|---|---|
| 抓取频次 | 服务器日志按语种目录统计 | 上线两周还没有爬虫到访，先回查屏蔽类设置 |
| 索引量 | 分语种做收录查询，定期记录数字 | 长期接近零或者突然腰斩，都是要立刻排查的信号 |
| 展现与点击 | 搜索表现按国家或语言拆分看 | 有展现没点击，问题在标题摘要的本地化表达 |
| 核心词排名 | 每个语种挑十来个核心词做追踪 | 排名长期不动或反复跳，检查是否与同语种页面互相挤占 |
给一个直观的参照：多语种站点上线三个月，各语种索引覆盖通常不会同步，跑得快的语种和慢的之间差一半以上很常见。这里放一个外贸站的示意分布，看的时候把注意力放在差距上：
（示意数据，用于说明语种间的收录差距，不代表行业均值。）
七、多语言矩阵里，AI 该管到哪一步
把语种从三个扩到十个、再从十个扩到几十个，靠单站手工维护必然会乱。这个阶段真正需要的是把流程系统化：内容按语种分发、标记批量生成、各语种表现在一处看。
一句话结论：多语言 SEO 的功夫花在翻译之前和收录之后，中间的翻译环节，恰好是 AI 最擅长、也最不必心疼的部分。
用 UC 建站系统做多语种站点或多语种矩阵时，几件事可以交给系统统一处理：内容中台按语种做差异化重组，同一个主题在不同语言版本里换角度、换结构，避免多语种内容长成一个模子；每个语言版本生成独立的 URL 和站点地图，收录情况进同一个看板，哪个语种掉了一目了然；地址新增之后通过双通道把 URL 推给搜索引擎，语种多了不用逐个手工提交。多个语种拆成独立站运营的，各站独立部署、独立备案，模板和日志互不干扰，排查时互不牵连。
听说谷歌要弃用 hreflang，还有必要认真做吗？
没有弃用。hreflang 仍是谷歌识别多语言页面关系的主要声明方式，官方文档对格式和用法的说明一直在维护。需要留意的是另一件事：新兴的 AI 搜索工具对 hreflang 的读取有限，它们更多按内容本身匹配语言。所以语言路由要做扎实，内容本身也要能直接回答目标语言用户的问题，两条腿走路。
AI 参与翻译和写作，会不会被谷歌当成低质内容处罚？
谷歌公开表态过，标准落在内容对用户有没有价值上，不是生产工具本身。批量机翻、不做本地化、一个模板铺几十个语种，这类做法落在规模化低质内容的判定范围内；有调研、有本地化改写、有审核环节的内容，AI 只是效率工具。判断标准很简单：这个语言版本解决了当地用户的一个具体问题吗，解决了就不算低质。
多语言这件事，很多团队做反了顺序：先花大力气翻译，发现不收录，再回头补结构和标记，中间浪费的时间和内容成本远比想象中高。把顺序倒过来，先定结构、再把 hreflang 和 canonical 这些地基打牢、再让 AI 按本地化的要求生产内容、上线后按语种单独盯，多语言的增长模型就顺了。语种数量不是目标，每个语种都能被搜到、有转化，才是。
（文中 URL 结构、hreflang 规范、重定向与内容质量口径，参考谷歌搜索中心公开文档与 2026 年公开行业分析文章的通用结论；索引覆盖率数值为示意，实际因站点与市场而异。）
