本文约 3,073 字，预计阅读 8 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：结构一旦定下，改起来就是一次全站迁移
国际站点最早要做的决定不是翻译，而是 URL 结构。很多人凭直觉选——「美国站用 .com，日本站用 .jp」听起来自然，「/en/ /ja/ 子目录」看起来省事。但这两种选择背后的权重逻辑完全不同：ccTLD 下每个国家站是独立的站点，权重从零积累；子目录则共享主域的权重存量。选错了不是不能改，但改一次等价于一次全站迁移，索引、排名、外链全部要重新转移，代价极高。
原理分析：三种结构的本质差异
| 维度 | ccTLD（example.jp） | 子域（jp.example.com） | 子目录（example.com/jp/） |
|---|---|---|---|
| 权重积累 | 独立域名，从零开始 | 部分共享，弱于子目录 | 完全共享主域权重 |
| 地区信号 | 最强，直接向用户和 Google 明示 | 弱，需靠 hreflang 与 Search Console 定位 | 弱，同上 |
| 运维成本 | 最高，多套站点多套证书 | 中 | 最低，一套站点 |
| 内容同步 | 困难 | 中等 | 容易 |
| 本地信任度 | 最高 | 中 | 中 |
| 风险隔离 | 好，一国被罚不影响他国 | 中等 | 差，全站共担 |
Google 官方明确表示支持三种结构，没有偏好。真正的差异在于两点：
第一，权重复用效率。子目录能让新语种立刻共享主域已有的权威度，这是新进入某市场时最大的优势。ccTLD 则要重新积累，通常需要更长时间才能在当地搜索结果中立足。
第二，地区信号的强度。ccTLD 是最强的国家定位信号，适用于「各国内容完全独立、面向本地用户」的场景。子域和子目录高度依赖 hreflang 与 Search Console 的地理定位设置。
决策的核心判断标准是：你的各语言版本内容是同源还是差异化。同源且资源有限，选子目录；各国内容、价格、库存完全不同且预算充足，选 ccTLD；介于两者之间、或者技术架构需要隔离（比如不同国家用不同 CDN/机房），选子域。
保姆级实操
步骤一：先列出决策输入
写下四个变量：目标国家数、各版本内容差异度、运营团队规模、现有主域权重水平。内容差异度低 + 团队小 + 主域有积累，直接选子目录。
步骤二：子目录方案的落地
单站点 + 多语言插件（WPML、Polylang、TranslatePress）是最省事的组合。固定链接保持 /ja/post-name/ 形式，确保 hreflang 与 canonical 同步（参见 hreflang 部署）。
步骤三：子域方案的落地
可用 WordPress 多站点（Multisite）的子域模式。在 wp-config.php 中启用：
/* 开启多站点（子域模式） */
define( 'WP_ALLOW_MULTISITE', true );
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', true );
define( 'DOMAIN_CURRENT_SITE', 'mimangfei.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );
nginx 侧用通配证书与泛解析：
server {
listen 443 ssl http2;
server_name ~^(?<sub>.+)\.mimangfei\.com$;
ssl_certificate /etc/letsencrypt/live/mimangfei.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mimangfei.com/privkey.pem;
root /var/www/mimangfei;
index index.php;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/run/php/php8.2-fpm.sock;
}
}
步骤四：ccTLD 方案的落地要点
每个 ccTLD 是独立站点，需要各自的 Search Console 属性、各自的站点地图、各自的服务器或 CDN 节点。hreflang 必须跨域名互指，这一点最容易遗漏。
步骤五：无论选哪种，都要做地理定位设置
对于 ccTLD 之外的结构，Google 主要依据 hreflang 判断地区。可以在 Search Console 里用网址检查工具确认各版本的地区识别是否正确。
步骤六：评估迁移代价
如果要从一种结构换成另一种，必须按站点迁移标准执行：全量 301、站点地图更新、内部链接替换、索引监控。可以用这条命令预估需要映射的 URL 数量：
# 从站点地图统计待迁移 URL 总数
curl -s https://mimangfei.com/wp-sitemap-posts-post-1.xml \
| grep -o '<loc>[^<]*</loc>' | wc -l
步骤七：把结构决策写进文档
记录选择理由、约定的代码规范（语言代码、地区代码）、URL 命名规则。多语言项目最怕的是中途风格漂移，最后出现 /en-us/ 与 /en/ 并存。
常见踩坑
- 用子域做多语言，但每个子域部署了完全独立的内容且没做 hreflang，权重完全分散。
- ccTLD 站点之间没有做跨域名 hreflang，各站互相被判定为重复内容。
- 子目录方案下用 cookie 或 IP 跳转改变 URL，Googlebot 抓到的永远是默认语言版本。
- 同一内容同时存在
/en/与en.mimangfei.com两个版本，自我竞争。 - 多站点启用后未配置泛解析证书，子域全部打不开。
- 案例：某外贸企业为「显得国际化」给六个国家各买了一个 ccTLD，但所有站点内容都是机器翻译的同一套产品页。半年后六个域名均无任何排名，而同期用子目录上线的英文版已积累两百多个关键词排名。最终被迫把五个 ccTLD 301 回主域子目录，损失了大半年时间。
- 迁移到子目录时只做了首页跳转，深层页面 404，权重转移失败。
总结
结构选择的判断标准是内容差异度与资源规模：内容同源、团队小、主域有积累，优先子目录；各国内容完全独立且预算充足，才考虑 ccTLD；需要技术隔离时用子域。选定后最重要的是保持 URL 风格统一，并把 hreflang 做全（含自引用与双向互指）。结构一旦上线就不要轻易改，迁移代价等同于重建站点。落地后建议用 hreflang 部署 的规范检查标签，用 抓取预算优化 控制各版本的抓取优先级，并用 服务器日志分析 验证 Googlebot 是否真的抓到了每一个语言版本。
