ccTLD vs 子目录 vs 子域名：域名策略对比
核心问题：多语言/多地区网站应该用
example.de、example.com/de/还是de.example.com？各方案的 SEO 影响和运维成本如何？
真实场景
你的 SaaS 产品要扩展到德国、日本和巴西市场，需要决定 URL 结构。这个决策影响 SEO 表现、CDN 配置、证书管理、开发成本，一旦确定很难更改（更改会损失 SEO 权重）。
三种方案概览
graph LR
subgraph "ccTLD（国家顶级域名）"
A["example.de\nexample.jp\nexample.com.br"]
end
subgraph "子目录"
B["example.com/de/\nexample.com/ja/\nexample.com/pt-br/"]
end
subgraph "子域名"
C["de.example.com\nja.example.com\npt-br.example.com"]
end
方案一：ccTLD（国家顶级域名）
每个目标国家/地区使用独立的顶级域名。
例子：amazon.de、amazon.co.jp、mercadolibre.com.br
优点
| 优点 | 说明 |
|---|---|
| 最强的地理定向信号 | Google 明确知道 .de 是德国网站 |
| 用户信任度高 | 当地用户更信任本地域名 |
| 独立 CDN/服务器 | 可以完全独立部署 |
| 合规隔离 | GDPR 数据在 EU 内部处理 |
缺点
| 缺点 | 影响 |
|---|---|
| 域名注册和续费 | 每个国家的域名有不同规则，部分需要当地联系人 |
| SEO 权重分散 | 每个域名从零积累反链，无法复用 .com 的权重 |
| SSL 证书管理 | 每个域名独立证书（通配符 *.example.com 无效） |
| 开发运维成本 | N 套部署、监控、DNS 配置 |
| 内容重复风险 | 多域名相同内容，需要 canonical + hreflang |
适用场景
- 大型成熟品牌（Amazon、Google、Microsoft）
- 有当地法律合规要求的行业（金融、医疗）
- 有足够预算和团队维护多套基础设施
- 当地用户对本地域名有强烈偏好
方案二：子目录（推荐大多数情况）
在同一域名下用路径前缀区分语言/地区。
例子：github.com/en/、airbnb.com/zh/（实际大多数网站采用此方案）
URL 结构选择
按语言：
example.com/zh-CN/products # 按完整 BCP 47 标签
example.com/zh/products # 按语言代码（更短）
按地区：
example.com/cn/products # 按国家代码
example.com/us/products
按语言+地区（最准确）：
example.com/zh-CN/products
example.com/en-US/products
example.com/pt-BR/products
默认语言不加前缀：
example.com/products # 默认语言（如 en）
example.com/zh/products # 中文
example.com/de/products # 德语
优点
| 优点 | 说明 |
|---|---|
| SEO 权重集中 | 所有语言版本共享 example.com 的域名权重 |
| 简单的 SSL | 一个证书覆盖所有语言 |
| 单一部署 | 一套代码库、一套基础设施 |
| 最推荐的 Google 方案 | Google 官方文档首推此方案 |
| 切换成本低 | 新增语言只需加一个路径前缀 |
缺点
| 缺点 | 说明 |
|---|---|
| 地理定向信号弱于 ccTLD | Google 主要通过 hreflang 判断，不如 ccTLD 强 |
| 无法独立 CDN 拓扑 | 所有语言使用同一 CDN 配置（通常不是问题） |
Next.js 实现
// next.config.ts：配置子目录路由
import { NextConfig } from 'next';
const nextConfig: NextConfig = {
// i18n 子目录路由（Pages Router）
i18n: {
locales: ['zh-CN', 'en-US', 'de-DE', 'ja-JP', 'pt-BR'],
defaultLocale: 'zh-CN',
// 'as-needed'：默认语言不加前缀，其他语言加前缀
// 'always'：所有语言都加前缀
// 'never'：不使用 URL 前缀（用 header/cookie 判断）
},
};
export default nextConfig;
// 生成的 URL：
// zh-CN（默认）: example.com/products
// en-US: example.com/en-US/products
// de-DE: example.com/de-DE/products
// App Router + next-intl：使用 [locale] 动态路由段
// src/app/[locale]/layout.tsx
// 生成的 URL：example.com/zh-CN/products
Nginx 配置
server {
server_name example.com www.example.com;
# 根路径重定向到默认语言
location = / {
# 根据 Accept-Language 重定向
set $lang zh-CN;
if ($http_accept_language ~* "^en") { set $lang en-US; }
if ($http_accept_language ~* "^de") { set $lang de-DE; }
if ($http_accept_language ~* "^ja") { set $lang ja-JP; }
return 302 /$lang/;
}
# 语言前缀路由
location ~ ^/(zh-CN|en-US|de-DE|ja-JP|pt-BR)/(.*)$ {
proxy_pass http://app_backend;
proxy_set_header X-Locale $1;
}
}
方案三：子域名
例子：de.example.com、ja.example.com
与子目录的关键区别
graph TD
A[子域名 de.example.com] --> B[Google 视为独立站点]
B --> C[SEO 权重不与 example.com 共享]
D[子目录 example.com/de/] --> E[Google 视为同一站点的一部分]
E --> F[SEO 权重与 example.com 共享]
子域名 vs 子目录 SEO 对比
| SEO 维度 | 子域名 | 子目录 |
|---|---|---|
| 域名权重传递 | ❌ 不传递（独立站点） | ✅ 完全传递 |
| 反链共享 | ❌ 不共享 | ✅ 共享 |
| 地理定向 | 中等（需 Search Console 设置） | 中等（需 hreflang） |
| Google 官方推荐 | 第三位 | 第一位 |
子域名的合理使用场景
- 语言完全不同的独立业务：
app.example.com（应用）vsblog.example.com（博客） - 不同产品线：
shop.example.com（商城）vsdocs.example.com（文档） - 独立运营需求：
cn.example.com（中国大陆，需要 ICP 备案）
三方案决策矩阵
| 决策因素 | ccTLD | 子目录 | 子域名 |
|---|---|---|---|
| SEO 最优 | ✅（最强地理信号） | ✅（权重集中） | ❌ |
| 运维成本 | 高 | 低 | 中 |
| 实施速度 | 慢 | 快 | 中 |
| 品牌信任（当地用户） | ✅ | ❌ | 中 |
| 合规隔离 | ✅ | ❌ | 中 |
| 初创/中小企业 | ❌ 成本过高 | ✅ 最佳 | ✅ |
| 大型企业 | ✅ | ✅ | ❌ |
结论：大多数情况下选择子目录方案。
迁移注意事项
如果要从一种方案迁移到另一种（如子域名 → 子目录），需要：
# 1. 设置 301 永久重定向（通知 Google URL 永久迁移）
server {
server_name de.example.com;
return 301 https://example.com/de/$request_uri;
}
# 2. 在新旧 URL 都保留 canonical 标签，指向新 URL
# 3. 在 Google Search Console 提交新的 sitemap
# 4. 使用 Change of Address 工具（如适用）
# 5. 监控 6 个月，确认权重正常传递
下一节：域名策略确定后，需要通过 hreflang 标签告诉搜索引擎各语言版本的关系，避免内容重复被惩罚。