多言語サイトを構築する際、最初に決めなければならないのが URL構造 です。この決定はSEO・運用コスト・技術的な複雑さに大きく影響するため、後から変更するのは非常に困難です。
この記事では、3つの主要なURL設計パターンを比較し、サイトの規模や目的に合った最適な選択を解説します。
3つのURL設計パターン
パターン1: サブディレクトリ方式
https://example.com/ (日本語)
https://example.com/en/ (英語)
https://example.com/ko/ (韓国語)
https://example.com/zh-cn/ (中国語簡体)
パターン2: サブドメイン方式
https://example.com/ (日本語)
https://en.example.com/ (英語)
https://ko.example.com/ (韓国語)
https://cn.example.com/ (中国語簡体)
パターン3: ccTLD方式（国別トップレベルドメイン）
https://example.jp/ (日本語)
https://example.com/ (英語)
https://example.co.kr/ (韓国語)
https://example.cn/ (中国語簡体)
3パターンの比較表
| 比較項目 | サブディレクトリ | サブドメイン | ccTLD |
|---|---|---|---|
| SEOドメインパワー | 共有（最強） | 分散 | 完全分離 |
| 地域ターゲティング | Search Consoleで設定 | Search Consoleで設定 | ドメイン自体が地域信号 |
| 初期コスト | 低い | 中程度 | 高い（複数ドメイン） |
| 運用コスト | 低い | 中程度 | 高い |
| 技術的な複雑さ | 低い | 中程度 | 高い |
| サーバー分離 | 同一サーバー | 別サーバー可能 | 別サーバー可能 |
| SSL証明書 | 1つでOK | 各サブドメインに必要 | 各ドメインに必要 |
| Google推奨 | 推奨 | 可 | 可 |
パターン1: サブディレクトリ方式（おすすめ）
メリット
ドメインパワーの集約がサブディレクトリ方式の最大のメリットです。
- 全言語のページが同一ドメインに存在するため、被リンクやドメイン年齢などのSEOシグナルが全言語で共有される
- 新しい言語を追加しても、既存のドメインパワーをすぐに活用できる
- Googleも公式にサブディレクトリ方式を推奨している
運用のシンプルさも大きなメリットです。
- 1つのサーバー、1つのSSL証明書、1つのCMSで管理可能
- デプロイメントが一元化できる
- アクセス解析も1つのプロパティで管理できる
デメリット
- サーバーが1箇所のため、地理的に遠いユーザーにはCDNが必須
- 1つのサーバー障害で全言語に影響
実装のポイント
-
言語コードはISO 639-1に準拠（
/en/,/ko/,/zh-cn/） - デフォルト言語（日本語）はルート直下（
/）でOK - 各言語ディレクトリ内のパス構造は統一する
/about → 日本語の「概要」ページ
/en/about → 英語の「About」ページ
/ko/about → 韓国語の「소개」ページ
パターン2: サブドメイン方式
メリット
- 各言語サイトを独立したサーバーに配置可能（地理的に近いサーバー）
- 技術スタックを言語ごとに変えられる
- 大規模組織で言語ごとにチームが分かれている場合に管理しやすい
デメリット
- ドメインパワーが分散 — Googleはサブドメインを別サイトとして扱う傾向がある
- 各サブドメインにSSL証明書が必要（ワイルドカード証明書で対応可能）
- Search Consoleで各サブドメインを個別に登録・管理する必要がある
- DNS設定が増える
向いているケース
- 各地域に専任チームがある大企業
- 地域ごとに異なるコンテンツを提供する場合
- 技術スタックを地域ごとに分けたい場合
パターン3: ccTLD方式
メリット
-
最も強い地域信号 —
.co.ukは英国、.deはドイツと明確 - ユーザーからの信頼性が高い
- 各国の法的要件に対応しやすい
デメリット
- コストが最も高い — ドメイン取得・維持費が国数分かかる
- ドメインパワーが完全に分離 — 新しいccTLDはゼロからSEOを構築
- 管理が非常に複雑
- 希望するドメインが取得できない可能性
向いているケース
- 各国に現地法人がある多国籍企業
- 地域ごとに全く異なるサービスを提供する場合
- ブランド保護のためにドメインを確保したい場合
URL設計のベストプラクティス
1. 言語コードは一貫性を保つ
✓ /en/, /ko/, /zh-cn/ （ISO準拠、一貫性あり）
✗ /english/, /korean/, /chinese/ （表記が不統一）
2. デフォルト言語の扱い
日本語がデフォルトの場合、以下の2パターンがあります。
パターンA（推奨）:
/ → 日本語
/en/ → 英語
パターンB:
/ja/ → 日本語
/en/ → 英語
パターンAの方が既存のURL構造を変えずに済むため、移行コストが低くおすすめです。
3. URLのパス部分は翻訳しない
✓ /en/about （パスは統一、コンテンツだけ翻訳）
✗ /en/about → /ja/概要 （パスの翻訳はSEOリスクあり）
パスを翻訳すると管理が複雑になり、リダイレクトの設定ミスが起きやすくなります。
4. canonicalタグとhreflangタグの整合性
各言語ページのcanonicalタグは自分自身のURLを指すようにします。
<!-- /en/about のcanonical -->
<link rel="canonical" href="https://example.com/en/about" />
<!-- hreflangタグ（全言語ページに設置） -->
<link rel="alternate" hreflang="en" href="https://example.com/en/about" />
<link rel="alternate" hreflang="ja" href="https://example.com/about" />
既存サイトのURL構造を変更する場合
既にインデックスされているサイトのURL構造を変更する場合は、以下の手順で慎重に進めてください。
- 301リダイレクトの設定 — 旧URLから新URLへの永続的リダイレクト
- サイトマップの更新 — 新しいURL構造を反映
- Search Consoleで再送信 — 新しいサイトマップを送信
- 経過観察 — 数週間〜数ヶ月かけてインデックスが移行
まとめ
多言語サイトのURL設計は、ほとんどの場合 サブディレクトリ方式 がベストです。ドメインパワーの共有、運用のシンプルさ、コストの低さのバランスが最も優れています。
blaidでは、翻訳サービスの導入に際してURL構造を変更する必要はありません。既存のURL構造のまま多言語化を開始でき、SEOエクスポート機能でhreflangタグの生成にも対応しています。多言語SEOの全体像については多言語SEOの基本もご覧ください。