多语言网站结构与 hreflang：不要把英文站做成中文站的翻译件

多语言网站结构与 hreflang：不要把英文站做成中文站的翻译件

Author
Pete S
Published
2026年4月29日
Reading Time
15 min read
On this page17

多语言网站结构与 hreflang：不要把英文站做成中文站的翻译件

先讲结论

多语言官网先决定 URL 结构。example.com/en/、example.com/de/ 这种子目录是大多数中小出海团队的最优解，不要轻易上子域名或独立国别域名。每个语言版本之间用 hreflang 互相声明，包括 x-default，并且 canonical 要指回自己。语言切换是用户决定的，不是浏览器自动跳的。自动重定向常常把 Googlebot 的英文版本重定向到中文版本，索引就混了。最关键的一条：英文版本不是中文版本的翻译，是另一份内容。案例选不同的客户，FAQ 回答不同的问题，CTA 落到不同的渠道。WordPress 上做多语言，Polylang 或 WPML 选一个固定下来，中途别换。上线后用 Search Console 的"国际化目标"和 site: 查询逐语言验证，确认 Google 给德国用户展示的是德语页面，而不是英文页面。

最常见的失败：一家做工业耗材的公司把 200 多页中文官网用插件机翻成英语和德语，子目录上线 /en/ 和 /de/。三个月后德国客户搜公司名只能搜到 /cn/ 的繁体页面。问题不是 hreflang 没写，是写错了。每个 URL 自指 canonical，但 hreflang 把 /en/ 指向了 /（默认中文）。Google 干脆把整组语言当成同一份内容的不同版本，而不是独立页面。

这篇面向第一次做多语言官网的中国团队。不写技术规范，写取舍。URL 怎么选、内容怎么分、上线后怎么验证。

1. URL 结构

三个选项摆在桌上：

  • 子目录：example.com/en/、example.com/de/、example.com/es/。一个域名、一个证书、一份 DNS、一份权重。
  • 子域名：en.example.com、de.example.com。Google 会把它们当成相对独立的站点，权重需要分别建。
  • 独立国别域名：example.de、example.fr、example.co.uk。最强的本地化信号，但每一个域名都要单独做权重、单独做内容、单独做证书。

90% 的中小出海团队选子目录就够了。理由很直接：你刚开始做海外，没有时间和预算去维护三个独立站点的内容、外链和分析报表。子目录把所有语言版本汇总在一个域名下，权重集中，运营成本最低。Google Search Central 在本地化版本指南里也说三种结构都支持，建议挑最容易维护的那个。

什么时候选子域名？当某个语言版本背后是独立的本地团队，运营节奏和内容来源都和总部脱钩。总部在杭州、德国分公司有自己的销售和市场，de.example.com 让分公司团队独立运营会更顺。

什么时候选独立国别域名？当目标市场有强烈的本地信任偏好（德国 .de、法国 .fr、英国 .co.uk），并且你已经有人力维护多套站点。终局形态，不是起步形态。

2. hreflang 怎么写

hreflang 的作用是告诉 Google "这一组 URL 是同一份内容的不同语言/地区版本"。写错了，搜索引擎会把它们当成重复内容或者完全独立的页面。

每个语言版本的页面 <head> 里都要列出全组：

<link rel="alternate" hreflang="en" href="https://example.com/en/products/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/produkte/" />
<link rel="alternate" hreflang="zh-CN" href="https://example.com/cn/products/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/products/" />
<link rel="canonical" href="https://example.com/en/products/" />

四条规则：

  • 互相声明：A 列了 B，B 也必须列 A。单向声明 Google 会忽略。
  • 每个页面自指：/en/products/ 的 hreflang 列表里要包含 hreflang="en" 指向自己。
  • canonical 指回自己：不要把 /de/produkte/ 的 canonical 指向 /en/products/，否则 Google 会认为德语版本是英语版本的副本。
  • 加一个 x-default：当用户的语言/地区不在你支持的清单里，Google 会展示 x-default 指向的页面。通常指向英语主版本。

语言代码用 ISO 639-1（en、de、zh）；细分地区用 language-region（en-US、en-GB、zh-CN、zh-TW）。不要写 en_US——下划线不符合 BCP 47 语言标签规范，Google 解析时会忽略整条声明。

WordPress 上 Polylang 和 WPML 都会自动生成 hreflang，但生成的不一定对。常见错误：插件 URL 和实际站点 URL 不一致（带不带斜杠、带不带 www）、x-default 缺失、翻译没发布的页面就被声明了。上线前用 Screaming Frog 或 Ahrefs 的 hreflang 检查器跑一遍，每个语言版本都看一眼。

3. 自动跳转

第一反应往往是：用户从德国 IP 访问，自动跳转到 /de/。看起来贴心，实际经常出问题。

两个原因：

  • Googlebot 通常从美国 IP 抓取。按 IP 跳转，Google 抓 /de/ 时被重定向到 /en/，结果 Google 永远不知道你有德语版本。
  • 用户 IP 不等于用户语言。住在柏林的中国客户可能更想看中文版本。强制跳转剥夺了他选择的权利。

更好的做法：默认展示 x-default 指向的版本（通常是英语），右上角放一个明显的语言切换器让用户自选，第一次切换后用 cookie 记住偏好。不要用 meta http-equiv="refresh" 或 window.location 做 IP 跳转。

Google 在多区域站点指南里也明确说过：不要根据用户感知的位置自动重定向，否则 Google 和用户都没法访问所有版本。

4. 内容不是翻译

技术做对了只是不丢分。真正决定海外询盘的是内容。把中文一字一句翻成英文，海外读者立刻能感觉到。句子结构、案例语境、行业说法都不对。

英文版本要重写的部分：

  • 案例选择：中文站可能堆了 20 个国内大客户，英文站不需要。挑 3-5 个海外客户或可对标的国际项目，把国家、行业、规模写清楚。
  • FAQ：中国客户问"能不能开发票"、"支持微信对接吗"。海外客户问付款条件、Incoterms、最小起订量。这两组问题不能互相翻译。
  • CTA：中文的"立即咨询"对应到英文不一定是"Contact us"，可能是"Request a quote"、"Book a demo"、"Get a sample"，看业务模型。
  • 行业术语：用目标市场的说法。"环保设备"在德语里是 Umwelttechnik。这一步必须找母语写手，机翻配 LLM 也救不回来。

本地化 SEO 和直接翻译有什么区别里有更细的清单。简单说：翻译是换字，本地化是重写。

5. WordPress 选型

WordPress 做多语言主要两条路：

  • Polylang：免费版功能足够，UI 干净，性能影响小。Polylang Pro 加上 String Translation 能处理大部分场景。适合预算紧、技术团队自己能处理边角问题的项目。
  • WPML：付费（年许可证约 99-199 美元），功能最全，对 WooCommerce、Yoast、ACF 兼容性最好。适合内容量大、电商功能复杂、需要一站式供应商支持的项目。

两个都自动生成 hreflang，都支持三种 URL 结构。选定一个就别中途换。切换插件意味着重新导入翻译、重建语言关系、URL 可能变化、hreflang 全部重写。

不要用 Google Translate Widget 或类似的"一键翻译"插件。它们生成的不是独立页面，而是 JavaScript 注入的临时翻译，搜索引擎抓不到，hreflang 也写不上。SEO 层面等于零。

更细的架构对比看WordPress 出海官网架构。

6. 语言切换

看着像前端细节。实际影响转化。

  • 位置：右上角导航栏。中国习惯放右下角或 footer，海外用户找不到。
  • 形式：下拉菜单 + 国旗图标 + 语言名（"English"、"Deutsch"），不要只放国旗。一个国旗无法对应多个国家说同一种语言，德语在德国、奥地利、瑞士都用。
  • 跳转规则：用户在 /en/products/page-a 切换到德语，跳到 /de/produkte/seite-a，不要跳回 /de/ 首页。Polylang 和 WPML 都支持逐页对应，但内容编辑要手动连接。
  • 标记语言代码：<html lang="de">、<html lang="en">，每个版本都要写对。无障碍读屏器、机器翻译、SEO 的基础信号。

7. 上线后验证

hreflang 写完不等于生效。上线后至少验证四件事：

  • GSC 国际化目标报告：Legacy tools and reports > International Targeting。列出 hreflang 错误：声明不一致、缺反向声明、代码格式错。
  • site: 查询：site:example.com/de/ 看德语索引数；site:example.com/en/ 看英语。两边数量级不应该差太多（除非确实只翻译了部分内容）。
  • 模拟地区搜索：用 VPN 从德国 IP 搜公司名，确认排第一的是 /de/ 而不是 /cn/ 或 /en/。
  • CTA 入口：每个语言版本的 WhatsApp、X、邮件按钮跳到对应语言的预填消息。德语客户点 WhatsApp 不应该收到英文模板。

详细清单看海外官网上线后的前 30 天该做什么。

8. 内容迁移

从单语言站升级到多语言站，老 URL 不能直接换。example.com/products/page-a 变成 example.com/en/products/page-a，每个老 URL 必须 301 到新 URL，否则原来的 SEO 权重和外链全部失效。

迁移检查项：

  • URL 映射表：每个老 URL 对应到哪个新 URL，写成一张表，技术团队照着配 301。
  • canonical 修正：老站的 canonical 全部更新，不要让 Google 看到混乱信号。
  • sitemap 重新提交：新 sitemap 包含所有语言版本，提交到 Search Console。
  • 外链通知：高价值外链（合作伙伴官网、行业目录、新闻稿）手动改链接，不要全靠 301。

完整流程看企业网站内容迁移清单。

9. 常见误区

最常被问到的几个错误判断：

  • "先上线英文，等有需要再加德语"：可以，但 URL 结构一开始就要按多语言规划。三个月后再加 /de/，英文版本所有 URL 都要调整一次，又是一轮 301 和权重稀释。
  • "hreflang 写在 sitemap 里就行"：选一种方式。不要既写 sitemap 又写 <head>，两边不一致 Google 会报错。我们建议写在页面里，更容易调试。
  • "AI 翻译现在很好"：LLM 或 DeepL 翻产品参数还可以，翻 FAQ 和案例就开始变味，翻法律条款和报价单就出错。决策成本高的内容必须有母语校对。
  • "多语言会拖慢网站"：Polylang 和 WPML 增加一些数据库查询，但配上页面缓存（WP Rocket、LiteSpeed Cache），实际加载和单语言站差不多。

上线总表

板块必检项负责人
URL 结构子目录路径确定，每个语言版本 URL 列出技术 + SEO
hreflang每页双向声明、自指、canonical 正确、含 x-default技术
自动跳转关闭 IP 跳转，用语言切换器技术
语言切换器右上角，文字 + 国旗，跳到对应页面技术 + 内容
内容本地化案例、FAQ、CTA、术语都重写内容
WordPress 插件Polylang 或 WPML 选定，hreflang 自动生成验证通过技术
字符标记<html lang="..."> 每个版本正确技术
验证GSC 国际化目标、site: 查询、模拟地区搜索SEO
迁移老 URL 301 映射表，sitemap 提交技术 + SEO

常见问题

多语言站要不要分开域名？

绝大多数情况不要。一个 .com 主域加上 /en/、/de/ 这样的语言路径，配正确的 hreflang，是 Google 在本地化指南里推荐的做法，也是中小出海团队最容易维护的形态。独立国别域名（.de、.fr）要等你有完整本地团队、目标市场对本地域名有强信任偏好时再做。

hreflang 写错最常见的几种情况？

四种：单向声明（A 列了 B，B 没列 A）；语言代码格式错（en_US 而不是 en-US）；canonical 指向别的语言；缺 x-default。上线前用 Search Console 的 International Targeting 报告或 Screaming Frog、Ahrefs Site Audit 跑一遍能避开 90% 的问题。

AI 翻译能直接用吗？

产品规格、技术参数这类客观内容，用 DeepL 或 LLM 翻完做轻校对可以。营销文案、FAQ、案例、法律条款必须有母语写手把关。最容易踩的坑是把"专业一站式服务"原样翻成英文，海外读者看到这种空泛表述会直接关页面。详见本地化 SEO 和直接翻译有什么区别。

多语言站上线大概要多久？

中文站已经稳定的话，加一个英文版本大约 4-6 周。1 周 URL 结构和插件选型，2 周内容重写和母语校对，1 周技术实现和 hreflang 配置，1-2 周 QA 和上线后验证。每多加一个语言再加 3-4 周，主要消耗在内容重写，不是技术。

预约诊断

如果你正在准备多语言官网，或者已经上线但发现 Google 没有按预期展示对应语言，欢迎带着现有域名、目标市场和当前 URL 结构，跟我们做一次免费的出海官网搭建支持初步诊断。我们会过一遍 hreflang、内容本地化和验证清单，告诉你哪些是 P0 修复、哪些可以放到下个迭代。