多语言方案分析：基于目录还是基于子域名？

做多语言网站，第一个要决定的问题就是：URL 结构怎么选。目前主流的有两种方案：子目录（Subdirectory） 和 子域名（Subdomain）。

子目录就是在主域名下面加语言路径，比如 example.com/zh/、example.com/en/。子域名就是每个语言一个独立的子域名，比如 zh.example.com、en.example.com。

选哪个好？这个问题没有标准答案，要看你的具体情况。下面从多个维度来分析。

多语言的一般做法

在对比两种方案之前，先了解一下多语言网站常见的几种 URL 结构：

1. 子目录（Subdirectory / Subfolder）

example.com/zh/
example.com/en/
example.com/ja/

所有语言版本都在同一个主域名下，通过路径区分语言。这是最常见的做法。

2. 子域名（Subdomain）

zh.example.com
en.example.com
ja.example.com

每个语言一个独立的子域名，技术上是不同的站点。

3. 独立域名（ccTLD）

example.cn
example.com
example.jp

每个国家/地区一个独立的顶级域名。这种方案成本最高，适合大型跨国公司。

4. 参数方式

example.com/?lang=zh
example.com/?lang=en

用 URL 参数区分语言。这种方式最简单，但 SEO 效果最差，一般不推荐。

5. 其他方式

还有一些不太常见的方式，比如不同语言放在不同端口、或者基于内容协商（同一 URL 根据 Accept-Language 返回不同语言）。这些都不适合 SEO，就不展开了。

总的来说，子目录和子域名是目前最主流、SEO 友好度最高的两种方案，也是本文重点讨论的对象。

子目录方案（Subdirectory）

实现方式

子目录方案的核心是：所有语言共享同一个域名，通过 URL 路径的第一层区分语言。

技术上的实现方式：

1. 服务端路由

在服务器端根据路径前缀渲染不同语言的内容。比如用 Node.js + Express：

app.get('/zh/about', (req, res) => {
  res.render('about', { lang: 'zh' });
});

app.get('/en/about', (req, res) => {
  res.render('about', { lang: 'en' });
});

2. 前端框架国际化

Nuxt、Next.js 等框架都有成熟的 i18n 模块，配置一下就能自动生成带语言前缀的路由。比如 Nuxt 的 @nuxtjs/i18n：

// nuxt.config.js
i18n: {
  locales: ['zh', 'en', 'ja'],
  defaultLocale: 'zh',
  strategy: 'prefix_except_default',
}

生成的 URL 就是：

默认语言：example.com/about
英文：example.com/en/about
日文：example.com/ja/about

3. 静态站点生成

如果是纯静态站点，可以每个语言一个目录，生成静态 HTML 文件。比如：

/
  index.html
  about.html
  en/
    index.html
    about.html
  ja/
    index.html
    about.html

优点

1. 域名权重集中

这是子目录方案最大的优势。所有语言版本都在同一个域名下，外链、权重、信任度都集中在一起。一个语言积累的权重，其他语言也能间接受益。

2. 更容易被搜索引擎理解

搜索引擎把子目录视为同一个网站的不同部分，理解起来更直接。内部链接的权重传递也更顺畅。

3. 建站成本低

只需要一个域名、一个服务器、一套代码（大多数情况下），维护成本低。

4. 管理方便

所有语言在同一个后台管理，内容、用户、订单等数据天然在一起，不需要做跨子域名的数据同步。

缺点

1. 地区针对性弱

子域名或独立域名更容易让搜索引擎和用户一眼看出"这是针对某个国家/地区的版本"。子目录在这方面弱一些，需要配合 hreflang 标签来明确。

2. 大型站点可能结构混乱

如果语言很多（比如十几个），加上每个语言下又有很多分类和页面，URL 结构可能会变得很深很复杂。

3. 服务器压力集中

所有语言的流量都打在同一个服务器上，峰值压力会比较大。当然这个可以通过 CDN 和负载均衡解决。

子域名方案（Subdomain）

实现方式

子域名方案的核心是：每个语言一个独立的子域名，技术上是独立的站点。

技术上的实现方式：

1. 通配符子域名 + 服务端判断

DNS 配置 *.example.com 都指向同一个服务器，服务端根据请求的子域名判断语言，返回对应内容。

app.get('/', (req, res) => {
  const subdomain = req.subdomains[0]; // 'zh', 'en', etc.
  res.render('home', { lang: subdomain });
});

2. 多应用部署

每个子域名对应一个独立的应用，部署在不同的服务器或不同的进程中。这种方式隔离性好，但维护成本高。

3. WordPress 多站点

WordPress 的多站点（Multisite）功能可以很方便地实现子域名方案，每个子站一个语言版本。

优点

1. 地区/语言定位清晰

用户和搜索引擎一看域名就知道这是哪个语言的版本。比如 fr.example.com 明显是法语版，对法国用户来说也更有亲切感。

2. 站点隔离，风险分散

每个子域名在搜索引擎眼中是相对独立的站点。如果某个语言版本出了问题（比如被惩罚、被黑），对其他版本的影响相对较小。

3. 适合差异化运营

不同地区的业务可能差异很大——产品线不同、定价不同、活动不同。子域名方案下每个站点可以独立运营，互不干扰。

4. 技术架构灵活

不同语言版本可以用不同的技术栈、部署在不同的服务器上，团队也可以独立维护。

缺点

1. 域名权重分散

这是子域名方案最大的劣势。每个子域名在搜索引擎看来是不同的站点，外链、权重都是分开计算的。中文站积累的权重不会自动传递给英文站。

虽然子域名之间会有一些关联（毕竟在同一个主域名下），但权重传递的效果远不如子目录方案。

2. SEO 成本高

每个子域名都需要单独做 SEO —— 单独建外链、单独积累权重、单独提交 Search Console。对于资源有限的团队来说，压力很大。

3. 维护成本高

多个子域名意味着多个站点，代码部署、内容管理、数据同步都更复杂。

4. 起步慢

新增加一个语言版本，相当于从零开始做一个新站，排名见效慢。而子目录方案下，新语言可以借助主站已有的权重更快起步。

什么场景选什么方案

优先选择子目录的场景

中小型网站：语言数量不多（2-5 种），团队规模小，资源有限
内容为主的网站：博客、资讯站、知识库等，内容是核心，权重集中更重要
初创期/成长期：还在积累权重的阶段，子目录能更快见效
多语言版本内容高度相似：只是翻译一下，业务逻辑相同
SEO 资源有限：没有足够的精力给每个语言单独做外链和推广

优先选择子域名的场景

大型跨国企业：每个地区有独立的团队和业务，需要独立运营
地区差异大：不同语言/地区的产品、定价、服务差异很大
合规要求：某些国家要求数据存放在当地，或者有特定的合规要求
品牌本地化需求强：希望给当地用户"这是我们本地站"的感觉
有充足的 SEO 资源：每个语言都有专门的人做推广和外链

什么时候用独立域名（ccTLD）

如果你的业务在某个国家非常重要，需要最强的本地化信号，而且预算充足，可以考虑用独立的国家顶级域名，比如 .cn、.co.jp、.co.uk 等。

独立域名在本地化搜索中的表现最好，但成本也最高，适合大型跨国公司。

两种方案的对比总结

维度	子目录	子域名
域名权重	✅ 集中，共享	❌ 分散，各自独立
SEO 见效速度	✅ 快，借主站权重	❌ 慢，相当于新站
地区针对性	❌ 一般，需配合 hreflang	✅ 强，一目了然
建站成本	✅ 低，一套代码	❌ 高，多套系统
维护成本	✅ 低	❌ 高
风险隔离	❌ 一损俱损	✅ 互不影响
运营灵活性	❌ 统一管理	✅ 独立运营
技术复杂度	✅ 简单	❌ 复杂