多语言网站SEO：hreflang、URL结构、常见错误, 多语言网站SEO最佳实践, 如何正确构建多语言网站

为什么单独的语言版本对SEO很重要

搜索引擎不会索引“网站”或“语言”——它们索引的是 URL。如果您的俄语、英语和乌克兰语内容位于同一地址并通过脚本进行切换，谷歌看到的是一页带有一组内容的页面：服务器返回的内容。单个 URL 不能在三种语言的查询中排名——它只有一个标题、一个摘要和一种内容语言。

单独的语言版本可以同时解决多个问题：

独立索引。每个版本都是一个独立的文档，具有自己的标题、描述和正文文本，这些内容在其语言中累积相关性。
正确的片段。来自英语搜索结果的用户看到的是英语标题和描述，而不是俄语的。
新的关键词宇宙。每种语言都是一个您网站之前从未出现过的查询层。

这就是为什么多语言SEO的第一步不是翻译，而是架构：每个语言版本都有自己的URL。

URL结构：子目录、子域名、国家代码顶级域名或?lang=

有四种常见的方法可以通过地址来区分语言，它们并不等同。

子目录 (site.com/en/, site.com/uk/)。所有版本都在一个域名下，并继承其权威性：反向链接、年龄、历史。对于大多数项目来说，这是最佳选择。
子域名 (en.site.com)。搜索引擎往往将子域名视为部分独立的网站，因此链接权重会被分割。当版本在技术上是不同产品时，这种做法是合理的。
国家代码顶级域名 (site.de, site.fr)。最强的地理信号和来自当地受众的最大信任，但每个域名都是从零开始：它自己的链接配置文件、预算和风险。
GET参数 (?lang=en)。最糟糕的选择：参数常常因规范化而被合并，重复内容容易增加，地址对用户和爬虫都没有任何语言信息。

我们的默认推荐是子目录：SEO影响和维护成本的最佳平衡。您可以在以下位置查看实际实现我们的作品集.

客户端JS翻译与预渲染HTML

一个常见的捷径是通过 JavaScript 字典“实现多语言”：页面以主要语言加载，脚本在选择语言后交换字符串。从 SEO 的角度来看，这样的网站仍然是单语言的。

有几个原因。首先，如果所有语言共享一个 URL，按定义无法进行单独索引。其次，仅在 JS 执行后出现的内容的索引速度较慢且可靠性较低：渲染是 Google 以及许多其他爬虫（社交网络机器人、LLM 爬虫）的延迟、资源密集型阶段——它们根本不执行 JavaScript。

正确的解决方案是预渲染，或“烘焙”翻译：翻译在构建时或在服务器上注入到模板中，每个语言 URL 返回以正确语言呈现的现成 HTML——带有翻译的标题、描述和适当的 lang 属性。

这正是我们构建我们自己工作室网站和多语言自由职业市场 24freelance：三种语言，独立的 /en/ 和 /uk/ 路径，以及每个服务器响应中完全翻译的标记。

hreflang 正确使用：互惠、自我引用、x-default

hreflang 属性告诉搜索引擎一组 URL 是不同语言的同一页面，并帮助它们在结果中提供正确的版本。注释可以存在于三个地方：<link rel="alternate" hreflang="…"> 标签中的 <head>、HTTP 头或网站地图。

关键规则：

互惠性。如果俄文页面指向英文页面，则英文页面必须指回。单向注释将被忽略。
自我引用。每个页面都包含一个指向自身的 hreflang —— 如果没有它，集群将被视为不完整。
x-default。专门用于显示给不匹配您任何语言的受众的“后备”版本的注释。通常是网站的主要版本或语言选择页面。
有效代码。根据 ISO 639-1 的语言，按 ISO 3166-1 Alpha-2 的地区（可选）：ru、en、uk 或 en-GB、pt-BR。乌克兰语言的代码是 uk，而不是 ua — UA 是国家代码，在语言槽中无效。
绝对网址 — 带有协议和域名。

请记住：注释应出现在每个翻译页面上，而不仅仅是主页。

常见的 hreflang 错误

根据我们的审核经验，hreflang 是多语言 SEO 中最脆弱的部分。这些错误最常出现：

缺少返回链接。页面 A 指向 B，但 B 不指回 A — 注释对根本不起作用。
无效代码。 en-UK 而不是 en-GB，ua 而不是 uk，虚构的地区。无效代码会被忽略的注释。
hreflang 指向重定向或 404。集群中的每个 URL 必须返回 200；指向重定向或错误页面的链接会破坏集群。
与 noindex 和 canonical 冲突。被阻止索引或规范化到其他 URL 的页面无法参与集群。
所有版本指向主页。英文文章的替代版本是其他语言中的同一篇文章，而不是网站根目录。
具有不同内容的“替代版本”。hreflang 连接同一页面的翻译；链接具有不同含义的页面是不允许的。

使用工具验证注释：搜索控制台报告和任何 SEO 爬虫在几分钟内显示损坏的配对。

语言版本上的规范标签

Canonical 和 hreflang 解决不同的问题：canonical 合并同一页面的重复项，hreflang 连接彼此翻译的不同页面。翻译不是重复项，因此规则很简单：每个语言版本的规范链接指向自身.

多语言网站上最具破坏性的错误是将每种语言的规范链接指向“主”版本——例如，从 /en/services.html 和 /uk/services.html 指向俄语的 /services.html。该标签明确告诉搜索引擎“不要索引翻译”，无论你添加多少 hreflang，它们都会从结果中消失。当信号冲突时，谷歌通常会信任规范链接。

实用规则：每个语言版本的规范链接是绝对的和自我引用的；hreflang 仅引用规范 URL（没有参数，没有多余的变体）。

带有 xhtml:link 的网站地图：所有替代项集中在一个地方

而不是 <head>，hreflang 可以通过 xhtml:link 扩展直接存在于网站地图中。对于每个 <url> 条目，你列出所有语言替代，包括 URL 本身：

<url><loc>https://site.com/en/page.html</loc> <xhtml:link rel="alternate" hreflang="en" href="https://site.com/en/page.html"/> <xhtml:link rel="alternate" hreflang="ru" href="https://site.com/page.html"/> <xhtml:link rel="alternate" hreflang="x-default" href="https://site.com/page.html"/></url>

优点：标记不会增加每个页面的 HTML 负担；所有关系都位于一个易于在构建时生成的单一文件中；页面不同步的风险较小。

要求与头部标签相同：互惠、自我引用、绝对 URL、状态 200。并记得在根 <urlset> 标签上声明 xhtml 命名空间，否则文件将无法通过验证。

翻译元标签、开放图谱和标记

翻译可见内容只是工作的一半。小细节往往暴露了语言版本，而这些细节最常被遗漏翻译：

标题和描述。它们构成了摘要并推动点击率。不要逐字翻译——根据每种语言的查询重写它们。
<html>上的lang属性。帮助搜索引擎、屏幕阅读器和浏览器翻译器正确识别文档语言。
Open Graph和Twitter卡片。og:title、og:description和og:locale必须与页面语言匹配，否则社交分享将以错误语言显示标题。使用og:locale:alternate来表示其他版本。
结构化数据。JSON-LD中的文本——组织名称、描述、常见问题——也必须翻译：丰富的摘要是从中组装而成的。
替代文本、按钮、错误页面、表单邮件。它们不会直接影响排名，但半翻译的网站会失去用户信任。

默认语言和按地理位置或接受语言的自动重定向

网站根目录应该使用哪种语言？通常是您主要受众的语言，其他版本移至/en/和/uk/。声明根版本为x-default也是有意义的。

一个危险的诱惑是根据IP地理位置或Accept-Language头自动重定向访问者到“他们”的版本。以下是我们反对这样做的原因：

Googlebot主要从美国IP地址进行爬取。一个有地理重定向的网站会固执地将其发送到英文版本，而其他语言可能会被爬取不足。
重定向会破坏直接链接：有人分享了一个乌克兰页面，而在另一个国家的接收者却进入了英文页面。

友好的替代方案是一个不显眼的横幅——“看起来您可能更喜欢……版本”——它会记住选择。而且至关重要的是：语言切换器必须是普通可爬取的<a href>链接，指向其他版本的同一页面——而不是仅限于JS的菜单，也不是指向外部主页的链接。

翻译质量：机器、人工、混合

技术上完美的多语言架构无法拯救弱翻译。搜索引擎明确警告，未经编辑或增加价值的机器翻译内容可能被视为规模内容滥用。

大多数项目的可行方案是混合模式：机器或LLM翻译作为草稿，然后由懂语言和理解领域的人进行校对。特别关注：

术语。所有页面统一的术语表：如果在用户界面、文章和电子邮件中“订单”被翻译成三种不同的方式，信任就会下降。
密切相关的语言对。接近性是具有误导性的：对于俄语和乌克兰语，原始机器输出看起来似乎合理，但充满了翻译腔和混合形式。一个经典的假朋友：乌克兰语“nedilia”意为星期天，而近似的俄语单词意为一周。
关键词研究，而不是关键词翻译。查询不被翻译——它们是为每种语言从头研究的：相同的需求在不同语言中表达方式不同。

多语言实施检查清单

启动或审核多语言网站的整合列表：

选择的URL结构；每种语言版本都有自己的地址。
内容由服务器作为现成的HTML提供：预渲染或SSR，没有客户端字符串交换。
每个版本的 <html> 标签都带有正确的 lang 属性。
hreflang：每个页面上的完整集群 — 自我引用、互惠、x-default、有效代码（uk，而不是 ua）。
每个版本的规范链接都是自我引用的；没有指向“主”语言的规范链接。
网站地图列出了所有版本 — 如有需要，带有 xhtml:link 替代。
标题、描述、OG 标签、JSON-LD 和替代文本已翻译和调整。
语言切换器链接到等效页面，而不是主页。
没有地理/接受语言的自动重定向；而是一个建议横幅。
翻译由母语者校对；每种语言的关键词研究已完成。

如果您需要从头到尾构建多语言网站 — 从 URL 架构到已完成的翻译，如我们的 24freelance 案例研究 — 看一下我们的服务和联系：我们将讨论您的项目并为您的语言和市场提出设置建议。

常见问题

我们应该从多少种语言开始？

从您实际拥有受众和需求的语言开始 — 通常是两种或三种。每个版本都需要翻译、校对和维护，因此推出两种完美的语言比六种半成品的语言要好。

我们可以只使用像 Google Translate 这样的自动翻译小部件吗？

为了偶尔访问者的方便 — 可以；为了 SEO — 不可以。小部件在用户的浏览器中翻译页面：翻译没有自己的 URL，不被索引，也不会带来搜索流量。只有由服务器作为准备好的 HTML 提供的独立语言版本才能产生 SEO 效果。

hreflang 应该放在哪里 — 在头部还是在网站地图中？

这两种方法对 Google 来说是等效的；选择一种并坚持使用。对于大型网站，网站地图更方便 — 注释在中央生成和验证；对于小型网站，头部标签在特定页面上更容易检查。

什么是 x-default，它是强制的吗？

x-default 指定了对于语言与可用语言都不匹配的用户的版本。正式来说，这个注释是可选的，但我们建议始终添加它，并指向主要版本或语言选择页面——这使得网站在国际搜索结果中的行为可预测。

在我们推出翻译后，主版本会失去排名吗？

如果实施正确，就不会。翻译不会与原版竞争：它们在各自语言的查询中排名，而 hreflang 明确告诉搜索引擎这些是同一页面的关联版本。风险只在于错误——例如，规范指向从翻译到原版。

URL（slug）也应该翻译吗？

最好是，但这不是关键。翻译后的 slug 在结果中更易读，并且可以稍微提高点击率，但在所有版本中保持拉丁文或英文的 slug 也是一种有效的做法，可以简化维护。