多语言网站结构怎么选：子目录、子域名与独立域名对比

你刚把第一批英文文章翻译完，下一步却卡住了：放到 /en/，还是新开 en.example.com，或者干脆买一个英文域名？这个选择看起来只差一段网址，半年后却可能变成三套部署、三份数据和一长串重定向。

多语言网站最容易被低估的，不是翻译工作量，而是长期维护成本。URL 一旦进入索引、获得外链并被用户收藏，后续迁移就要处理重定向、Canonical、hreflang 和数据归因。因此，结构选择应该先看团队能力、市场目标和内容规模，而不是先看哪个方案显得“更国际化”。

读完后的交付物： 一张结构决策表、一套 Astro 路由方案，以及可以逐项核对的上线清单。

先给结论

对刚开始验证海外流量的中文团队，同一主域名下的语言子目录通常是更稳妥的默认方案，例如 example.com/en/。如果不同语言站由独立团队、独立系统维护，可以考虑子域名；如果每个国家都是独立品牌、产品与合规主体，才值得评估国家域名或独立域名。

这不是排名承诺。Google 官方支持多种地区 URL 结构，并明确要求每个语言版本使用独立 URL、正确声明本地化版本。真正影响结果的是页面是否可抓取、翻译是否完整、用户体验是否一致，以及团队能否长期维护。

三种结构的核心差异

方案	示例	维护成本	数据与内容管理	地区信号	更适合谁
子目录	example.com/en/	低	集中在一个站点	中等	新站、小团队、统一品牌
子域名	en.example.com	中	可相对独立	中等	技术栈或团队需要隔离
独立域名	example.de	高	完全独立	较强	深耕单一国家的成熟业务

子目录：默认但不等于随便

子目录的优势是一个域名、一套部署、一套分析体系。站点地图、导航、设计系统和内容组件更容易复用，适合先用英文市场验证需求，再逐步增加日语、德语等版本。

它的限制也很明确：所有语言内容共享同一套发布纪律。如果某个版本只是机器翻译、导航仍是中文、页面缺少本地价格与案例，低质量内容会影响整个站点的体验。子目录降低了技术成本，但不会降低内容本地化标准。

子域名：适合有明确隔离需求的团队

子域名适合不同语言版本采用不同技术系统、部署节奏或运营团队的情况。例如主站使用 Astro，帮助中心由另一个 SaaS 系统托管。代价是监控、发布、权限和分析配置都会变多，内部链接也要更有意识地维护。

不要仅仅因为“看起来更专业”就选择子域名。若团队没有独立运营需求，它往往只是增加工作量。

独立域名：把一个网站变成多个业务

国家域名能给用户清晰的地区信号，但每个域名都需要单独配置、运营和建立信任。它更适合当地商品、价格、客服、支付与合规要求明显不同的业务，而不是简单复制一份翻译内容。

决策时先回答 5 个问题

1. 不同语言是否使用同一品牌、产品和定价？
2. 是否有独立团队长期维护当地内容？
3. 页面只是翻译，还是包含当地案例、货币和法规？
4. 是否能持续维护每组页面之间的 hreflang 关系？
5. 如果半年后停止某个语言版本，迁移和重定向成本能否承受？

若前四个问题大多回答“否”，先用子目录完成最小验证，不要过早拆分系统。

Astro 项目的落地方式

Astro 项目可以在路由中显式增加语言层级，例如：

src/pages/zh/articles/[slug].astro
src/pages/en/articles/[slug].astro

每个页面至少要完成以下配置：

• 页面正文和导航尽量保持单一语言。
• 为每个语言版本设置独立 Title、Description 与 Canonical。
• 在页面 <head> 中声明互相对应的 hreflang。
• 提供可点击的语言切换，不依赖自动识别。
• Sitemap 中只放可公开访问、希望收录的规范 URL。

一个常见的 hreflang 组合如下：

<link rel="alternate" hreflang="zh-CN" href="https://example.com/zh/guide/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/guide/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/guide/" />

每个语言页面都要包含完整的互相引用，不能只在中文页指向英文页。

上线检查清单

• 不同语言页面使用不同 URL，并能直接访问。
• 页面没有因为 IP 或浏览器语言被强制跳转。
• hreflang 语言代码有效，链接返回 200。
• Canonical 指向当前语言页面，而不是全部指向中文页。
• 翻译覆盖正文、导航、按钮、表单与错误提示。
• 图片 Alt、结构化数据和 Open Graph 信息已本地化。
• Search Console 能分别检查重点语言 URL。

最容易踩的坑

第一，只有页面框架被翻译，正文仍是中文。Google 会根据可见内容判断语言，不能依赖 lang 属性掩盖混合页面。

第二，把所有语言都 Canonical 到中文版本。这相当于告诉搜索引擎其他版本不是规范页面，会削弱它们独立参与搜索的机会。

第三，批量生成低质量翻译。国际 SEO 不是“页面数量翻倍”，而是为另一类用户提供完整、可理解、可执行的内容。

结论

多语言结构没有绝对最优解，只有与当前阶段匹配的方案。小团队先用子目录集中资源，验证有稳定搜索需求后，再决定是否为重点国家拆分品牌和系统。先把一个语言版本做深，比同时维护多个空壳站更有价值。