多语言网站最难排查的一类故障，看上去通常都很正常：中文页能打开，英文页也能打开，页头还有语言选项。可一查搜索结果，英文关键词出现的是中文页；从德语商品页切到英语，用户却被送回英文首页；站点地图里有五种语言，hreflang 只写了三种，其中两页还互相没有返回链接。
这不是翻译质量问题，而是页面关系没有建立完整。上线前需要把每一组对应页面当成一个整体来验收，不能只看某个页面的源代码是否“有 hreflang”。
先确定 URL，再谈语言标记
Google 对多语言网站的建议很明确：每种语言版本使用不同 URL，不要只靠 Cookie、浏览器语言或登录状态，在同一个地址上替换内容。原因并不复杂。搜索引擎需要发现、抓取和索引每个版本，而 Googlebot 通常从美国发起抓取，请求中也不一定带有 Accept-Language。如果服务器必须看到特定 IP 或语言请求头才返回法语页，那一部分内容很可能一直没有稳定的抓取入口。
常见的 URL 方案都能做，差别主要在运营和维护成本。
| 方案 | 示例 | 更适合什么情况 | 上线前要想清楚的事 |
|---|---|---|---|
| 国家或地区顶级域名 | example.de | 各市场业务、团队和合规要求相对独立 | 地域信号清楚，但域名、内容和技术维护成本都更高；它表达的是地区，不等于自动表达语言 |
| 子域名 | de.example.com | 需要独立部署或由不同团队维护 | 分区清楚，配置更灵活；监控、权限和发布流程要覆盖每个子域名 |
| 子目录 | example.com/de/ | 共享一个主站、技术栈和内容系统 | 对多数企业更容易统一维护；路由、缓存和权限规则不能把语言目录当成普通栏目 |
| 查询参数 | example.com/page?lang=de | 既有系统暂时无法改造 | Google 不推荐把它作为地域定向 URL 结构，参数规范化、缓存和重复 URL 也更难管理 |
选哪一种没有统一答案。已经在一个主域名上运营、各语言共用产品和发布系统的企业，子目录通常更省事；各国家站有独立价格、库存、法务文本和运营团队时，独立域名或子域名更容易划清边界。真正要避免的是同时混用多套规则，例如英文在 /en/，德语放在子域名，法语又靠 ?lang=fr 切换。这样的结构不是不能抓取，但每增加一套例外，跳转、站点地图、规范页和监控都会更难对齐。
URL 一旦确定，还要逐页确认四件事：地址长期稳定；页面无需特定 Cookie 也能直接访问；返回 200 状态码；内部链接能通过正常的 <a href> 到达。可本地化的路径词可以翻译，中文和其他非 ASCII 字符使用 UTF-8 并正确编码即可。路径是否翻译不是排名捷径，稳定、唯一、可维护更重要。
页面语言也不能只做一半。Google 主要依据页面可见内容判断语言，不靠 URL，也不靠 HTML 的 lang 属性完成识别。正文已经翻成西班牙语，导航、页脚、筛选项和弹窗仍大面积保留中文，搜索引擎和用户看到的都是一张混合语言页面。lang 仍然要正确设置，因为浏览器、翻译工具和读屏软件会用到它；只是不要把它当成 hreflang 的替代品。
语言切换器要把人送到“同一页”
语言切换器最基本的工作，不是让用户换一个网站首页，而是让他在当前内容的对应版本之间移动。人在英文的某款产品页点击“简体中文”，正常预期是到这款产品的中文页，不是中文首页，更不是让他重新搜索一次。
因此，切换关系要以页面为单位保存。产品、分类、文章、帮助中心、活动页各有自己的对应表，前端从这张关系表生成链接。暂时没有译文时，不要伪造一个目标 URL，也不要悄悄跳回首页。可以明确标示该语言暂不可用，或者保留当前版本并提供语言目录入口；hreflang 集合里则只放真实存在、可索引的页面。
切换器本身还有一些很容易被忽略的细节：
- 语言名称用该语言自己的写法，例如“简体中文”“English”“Deutsch”，国旗不适合代替语言。一种语言可能服务多个国家，一个国家也可能使用多种语言。
- 桌面端和移动端保持位置、命名和交互一致，当前语言有明确状态，键盘可以打开、移动和确认，焦点不会在菜单关闭后丢失。
- 链接最好在服务端输出的 HTML 中就能找到。只有执行一段脚本、触发下拉框后才临时拼出的地址，不利于抓取，也增加了前端故障时的使用风险。
- 可以根据浏览器语言给出建议，但不要强制跳转。用户手动选择后应优先尊重并记住这个选择，同时保留随时切回其他版本的入口。
- IP 只适合做很弱的提示，不适合作为唯一判断。出差、代理网络、跨境团队和搜索引擎抓取都会让 IP 与真实语言偏好不一致。
- 阿拉伯语、希伯来语等从右向左书写的页面，除了翻译文字，还要检查
dir="rtl"、组件方向、图标含义和表单阅读顺序。
还有一个经常直到发布后才暴露的问题：切换语言时把购物车、筛选条件、登录状态和跟踪参数全部原样带过去。是否保留状态，要看目标站是否支持相同商品、币种和参数。能对应的状态可以保留，不能对应的状态应有清楚处理，不能因为追求“无感切换”制造错误价格或失效页面。
hreflang 不是语言识别器，它在声明页面对应关系
hreflang 的作用，是告诉 Google：这些 URL 是同一内容的不同语言或地区版本，搜索结果可以据此选择更合适的页面。它不会负责识别页面正文用了什么语言，也不会让本来不能抓取、被 noindex 或被规范化到别处的页面自动进入索引。
一组简体中文、繁体中文和英文页面，可以在每个页面的 <head> 中放入同样一组声明：
<link rel="alternate" hreflang="zh-Hans" href="https://www.example.com/zh-cn/product/" />
<link rel="alternate" hreflang="zh-Hant" href="https://www.example.com/zh-tw/product/" />
<link rel="alternate" hreflang="en" href="https://www.example.com/en/product/" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/language/" />
这里有几条不能省：
- 每个页面都要列出整组版本，也包括它自己。中文页声明英文页，英文页也必须声明中文页；缺少返回链接时，Google 可能忽略这部分标记。
-
href使用包含协议和域名的完整 URL。目标地址应直接返回最终页面，不要先经过重定向，也不要指向 404、软 404 或不可索引页面。 - 语言代码放在前面，使用 Google 支持的 ISO 639-1 代码；确有地区差异时，再加 ISO 3166-1 Alpha 2 地区代码。
en-GB可以，单独写 GB不可以，en-UK也不正确。 - 只有确实需要区分时才增加脚本或地区。简体、繁体内容可以使用
zh-Hans、zh-Hant；如果价格、交付范围或法规内容还按地区变化，再评估是否需要 zh-Hans-CN、zh-Hant-TW等更具体标记。W3C 对语言标签的建议也是能短则短，只添加当前场景真正需要的子标签。 -
x-default用于没有任何语言或地区匹配时的后备页，常见目标是语言选择页或默认落地页。它不能替代某个真实语言版本。
HTML <link>、HTTP Link 响应头和 XML 站点地图都可以承载 hreflang。HTML 适合常规网页，HTTP 头常用于 PDF 等非 HTML 文件，站点地图更适合页面量大且由系统统一生成的站点。选一种作为主实现方式就够了，多套同时维护不会让信号加倍，反而容易出现三处内容不一致。无论采用哪种方式，“包括自身、完整成组、彼此返回、代码有效、URL 可索引”这几项都一样。
canonical 需要单独检查。内容真实不同的语言页面，通常各自指向自己的规范 URL，不要把英语、德语、日语页面全部 canonical 到中文页。那等于一边声明它们是可选版本，一边又告诉搜索引擎这些 URL 不是首选。对于同一种语言、内容高度相近的地区页面，Google 允许先确定同语言的首选版本，再配合 canonical 和 hreflang 处理；此时要按页面组核对，不能套用“所有页面一律自指”或“全部指向全球站”这样的简单规则。
上线验收要从单页查到整组页面
只在浏览器里打开首页，远远不够。红数科技在交付前会先建立一张语言 URL 对照表，至少覆盖首页、栏目页、产品或服务详情页、文章页，以及带分页、筛选或停售状态的特殊模板。每一行是一组等价内容，每一列是一种语言或地区。对应关系、缺失翻译和默认落地页先在表里说清楚，再去验证代码。
逐页检查时，可以按下面的口径验收：
| 检查对象 | 通过标准 | 常见故障 |
|---|---|---|
| 抓取与索引 | 目标 URL 直接返回 200，未被 robots.txt 阻止，没有 noindex，无需 Cookie 或特定 IP 才能看到 | 语言页只在前端切换后出现；正式环境沿用了测试站 noindex |
| 页面语言 | 主体内容、导航、标题、说明和关键交互属于同一目标语言，html lang 与文字一致 | 只翻正文，页头页尾仍是源语言；机器翻译占位未替换 |
| canonical | 指向可索引的最终 URL，且与当前语言版本的处理策略一致 | 所有译文都指向默认语言；canonical 经过重定向 |
| hreflang 集合 | 含自身，目标齐全，双向返回，代码有效，使用完整 URL | A 指向 B，B 没有指回 A；把国家代码当语言代码 |
| 语言切换 | 到达当前内容的对应语言页，移动端、键盘和返回操作正常 | 一律回首页；自动跳转形成循环；用户无法覆盖检测结果 |
| 内部链接与站点地图 | 菜单、正文链接和站点地图使用最终规范 URL，新语言页不会成为孤页 | 站点地图有页面，站内没有任何可点击入口 |
| 内容与业务规则 | 标题、描述、结构化数据中的可见信息、价格、币种、库存、法务文本与目标市场一致 | 文字翻译了，交易和合规信息仍沿用另一市场 |
这张表还应该进入自动化检查。抓取程序可以逐个读取 canonical、hreflang 和语言切换链接，核对目标状态码、返回关系与预期矩阵。页面量一大，人工抽查很难发现“只有日语文章页少了自引用”这类局部错误，而它恰恰是批量模板最常见的发布缺口。
上线当天再做一次真实环境复查。测试域名、临时 canonical、鉴权、缓存规则和重定向在发布时最容易变化；旧 URL 改版时要逐条跳转到相应的新语言页面，不要把所有历史地址都送去新首页。站点地图只提交规范、可索引的最终 URL，语言版本较多时分文件管理，后续更容易看出哪一组生成失败。
哪些现象说明还不能发布
发现下面任何一种情况，都应该先停下来修正对应关系：同一个 URL 会随 IP 返回不同语言；手动选择语言后仍被自动跳回；语言切换总是回首页；译文页 canonical 到另一种语言；hreflang 指向重定向或不可索引页面；同一组页面的标记数量不同；站点地图、HTML 和数据库里的语言映射互相冲突；页面宣称面向某个地区，价格、配送和法规说明却仍属于另一个市场。
多语言 SEO 不是给译文加几行标签。URL 解决的是每个版本在哪里，语言切换解决的是人怎样在版本之间移动，hreflang 解决的是搜索引擎怎样理解这组对应关系。三者用的是同一份页面映射，才不会出现前端一套、站点地图一套、搜索标记又一套的局面。上线前把这份映射查实，比发布后追着错语种排名逐页补救省事得多。
参考资料
- Google Search Central：网页的本地化版本，页面标注最后更新日期为 2026 年 4 月 27 日（UTC）。
- Google Search Central：管理多区域网站和多语言网站，页面标注最后更新日期为 2025 年 12 月 18 日（UTC）。
- W3C Internationalization：Choosing a Language Tag，用于核对 BCP 47 语言标签的选择原则。
- RFC 5646：Tags for Identifying Languages，语言标签语法的规范文件。
