# General Translation Knowledge Base: 多言語SEOにおけるサブディレクトリ・サブドメイン・ccTLDの比較
URL: https://generaltranslation.com/ja/kb/multilingual-url-structure.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: 1つのプロダクトでサイトとリリースプロセスを共有するなら、example.com/de/ のようなサブディレクトリを使いましょう。国を示せるのは ccTLD だけで、サブドメインなら個別にホスティングできます。Google は ?lang= パラメータを推奨しておらず、.io や .ai のようなバニティドメインは汎用ドメインとして扱います。
Category: 多言語SEO
Last updated: 2026-10-20
Authors: Kevin Wu, Jackie Chen
Published: 2026-10-20

ここで紹介する構成はいずれも、言語ごとに専用の URL を割り当てます。Google の[多地域・多言語サイトのガイド](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites)では、ターゲティングと運用負荷の観点からこれらを比較していますが、どれが優れているかの順位付けはしていません。つまり、判断の決め手は2つに絞られます。対象とするのは言語か国か、そしていくつのサイトを運用したいかです。

## 4つのURL構造の比較

以下の長所と短所は、Google自身の表を要約したものです。最後の選択肢であるURLパラメータは、Googleが非推奨としています。

| 構造                       | 例                     | Googleが挙げる長所                         | Googleが挙げる短所                                               |
| ------------------------ | --------------------- | ------------------------------------ | ---------------------------------------------------------- |
| 国別コードトップレベルドメイン (ccTLD)  | `example.de`          | 地域ターゲティングが明確、サーバーの所在地は無関係、サイトを分離しやすい | 費用が高く、取得できない場合もある、インフラが増える、一部の国ではccTLDの要件が厳しい、対象は1か国のみ     |
| サブドメイン                   | `de.example.com`      | 設定が簡単、サーバーの所在地を分けられる、サイトを分離しやすい      | `de` が言語と国のどちらを指すのか、ユーザーはURLから判別できない                       |
| サブディレクトリ                 | `example.com/de/`     | 設定が簡単、保守の手間が少ない (同一ホスト)              | ユーザーがURLからターゲティングを認識できない場合がある、サーバーの所在地が1か所に限られる、サイトを分離しにくい |
| URLパラメータ                 | `example.com?lang=de` | 記載なし (非推奨)                           | URLによる区分けが難しい、ユーザーがターゲティングを認識できない場合がある                     |

ただし、Googleのガイダンスにある次の2点を踏まえると、各構造の差はそれほど大きくありません。

* **URLの形式で国を示せるのはccTLDだけです。** Googleの[ローカライズ版に関するガイダンス](https://developers.google.com/search/docs/specialty/international/localized-versions)によると、`en` や `de` のような言語サブドメインはページの対象ユーザーの判定には使われないため、[hreflang](/kb/what-is-hreflang)で明示的に対応付ける必要があります。Googleはフォルダについて特に言及していませんが、`/de/` のパスが別扱いされることを示す記述もないため、こちらもhreflangで対応付けてください。
* **一部のccTLDは汎用ドメインとして扱われます。** Googleは、`.io`、`.ai`、`.co`、`.me`、`.tv` などのいわゆる「バニティ」ccTLDや、`.eu` のような地域ドメインを汎用トップレベルドメインとして扱います。`example.io` を使うスタートアップが、イギリス領インド洋地域をターゲットにしているわけではないからです。

またGoogleは、多くのサイトがCDNを利用していることから、サーバーの所在地は「決定的なシグナルではない」としています。そのため、サブディレクトリの短所である「サーバーの所在地が1か所に限られる」点はそれほど問題になりません。

5つ目の選択肢として、URLは1つのまま、クッキーやブラウザのヘッダーに応じて言語を切り替える方法もあります。ただし、クローラーがすべてのバージョンを検出できない可能性があるため、Googleはこの方法を推奨していません。トレードオフについては[サイトが配信する言語の選び方](/kb/locale-routing-seo)で解説しています。

## 各構成の運用コスト

Google の比較表には「より多くのインフラが必要」としか書かれていません。実際には、構成によって個別に保守しなければならない対象の数が異なります。

* **国別ドメイン:** 国ごとにドメインを購入・更新する必要があり、国によっては現地の登録要件もあります。各ホストに TLS の適用が必要です (1 つの証明書で複数のホスト名をカバーすることもできます) 。これらのドメイン全体について、管理責任、リダイレクト、監視の体制を計画してください。
* **サブドメイン:** ドメインは 1 つで済みますが、サブドメインごとに DNS レコードと証明書の適用が必要です。Google の [正規化に関するガイダンス](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls) では、証明書がホスト名全体に一致するか、ワイルドカード証明書でなければ、Google が HTTP 版を優先する可能性があると警告しています。
* **サブディレクトリ:** 複数の言語でホスト、TLS 設定、アプリケーション、デプロイパイプラインを共有できます。ただし、これらは一般的な運用上の選択肢であり、必須ではありません。リバースプロキシでパスを別々のアプリにルーティングすることもできますし、アナリティクスも URL 構造とは関係なく整理できます。

サブディレクトリだとランキングで有利になる、あるいは新しいサブドメインは有用なシグナルがゼロの状態から始まる、といった思い込みは避けてください。Google の比較は、どちらの主張も裏付けていません。実際のデプロイで必要になるホスティング、管理、リリースの作業量を比較しましょう。

## 言語と国のどちらをターゲットにすべきか

Google は、**多言語**サイト (同じ内容を複数の言語で提供するサイト。例：英語とフランス語で事業を展開するカナダの企業) と、**多地域**サイト (国ごとに異なる内容を提供するサイト。例：カナダと米国に製品を出荷するメーカー) を区別しています。URL 構造は、自社サイトがどちらに当たるかに応じて決めましょう。

* すべての話者に同じコンテンツを提供する場合は、**言語をターゲットにします**。`es` という注釈を付けた `/es/` セクションを 1 つ用意すれば、メキシコ、スペイン、アルゼンチンのスペイン語話者に対応できます。
* 価格や通貨、配送、法的条件、製品カタログなど、国によって異なる要素がある場合は、**国をターゲットにします**。`/es-mx/` と `/es-es/`、または `example.mx` を使用し、それぞれに `es-MX`、`es-ES` という注釈を付けます。

ただし、国ターゲティングにはデメリットもあります。Google によると、地域ターゲティングは対象国での掲載順位を向上させる可能性がある一方で、それは「他のロケールや言語での検索結果を犠牲にして」成り立つものです。また、ccTLD でターゲットにできる国は 1 か国だけです。国ごとに分ける場合でも、それ以外の地域の話者向けに言語のみのページ (`es`) もあわせて用意することを Google は[推奨しています](https://developers.google.com/search/docs/specialty/international/localized-versions)。`es` と `es-MX` のどちらのコードを選ぶべきかについては、[使用すべきロケールコード](/docs/platform/core/guides/locale-codes)を参照してください。

## ローカライズされたスラッグ

ロケールプレフィックスによってURL上でどの言語版かがわかりますが、パスの残りの部分も翻訳できます。たとえば `/de/about-us` ではなく `/de/ueber-uns` とする方法です。Googleによれば、URLにローカライズされた単語を使うことも、国際化ドメイン名を使うことも問題ありません。ただし、URLにはUTF-8を使用し、リンクする際には適切にエスケープする必要があります。`/de/über-uns` のような非ASCIIのスラッグは実際には `/de/%C3%BCber-uns` として送信されるため、hreflangやサイトマップにはこのエンコード済みの形式を記載します。

翻訳されたスラッグは検索結果で自然に読めますが、ロケールごとにスラッグのマッピングが必要になります。また、スラッグの翻訳を変更した場合は、旧URLからのリダイレクトも必要です。スラッグをローカライズしない場合でも、`/de/about-us` をそのまま使えば、言語ごとに個別のインデックス可能なURLを確保できます。

## どの構成を選ぶべきか

1つのプロダクトで共通のサイトとリリースプロセスを使って複数の言語を提供する場合は、まず **サブディレクトリ** を検討してください。ルーティングやホスティングの設定を使い回せることが多いためです。なお、サブディレクトリでも個別にデプロイすることは可能で、CDN を使えば同じホストを複数の拠点から配信することもできます。

国ごとに事実上独立した事業を運営している場合、つまり法人、カタログ、マーケティングチームがそれぞれ別々で、国のシグナルを最大限に強めたく、その維持コストも負担できる場合は、**国別ドメイン** を使用してください。

特定のロケールで異なるホスティングやインフラが必要な場合 (たとえば、ある市場向けにはその国内のサーバーから配信しなければならない場合など) は、**サブドメイン** を使用してください。

**URL パラメータ** は Google が推奨していないため、デフォルトの言語構成として使うのは避けてください。URL パラメータだからといってインデックスされないわけではありませんが、レポートやキャッシュの挙動は、各システムがパラメータをどう扱うかに左右されます。

どの構成を選ぶ場合でも、安定した URL を使用し、公開済みの同等バージョンに hreflang で注釈を付けてください ([hreflang とは](/kb/what-is-hreflang)を参照) 。

## General Translationによる各構造のサポート

General Translationの`gt-next`はサブディレクトリ方式をサポートしています。App Routerでは、[`createNextMiddleware`](/docs/react/nextjs/reference/functions/create-next-middleware)が各ロケールを`/es/about`のようなパスプレフィックス配下にルーティングします。デフォルトロケールにもプレフィックスを付けるかどうかについては、[ロケールルーティングとSEO](/kb/locale-routing-seo)で説明しています。同じミドルウェアの`pathConfig`オプションを使うと、共通のパスをロケールごとにローカライズされたスラッグにマッピングできます (例：`/about`を`/de/ueber-uns`に) 。また、`gt.config.json`の`customMapping`を使えば、翻訳ではカノニカルなコード`zh`を使いながら、ルートでは`/cn`のようなエイリアスを使用できます ([ロケールエイリアスのSEOガイド](/docs/react/nextjs/locale-alias-seo)を参照) 。

`gt-next`のドキュメントが扱うのはパスベースのルーティングで、ホスト名によるルーティングは対象外です。サブドメインや国別ドメインを使う場合は、各ホストとロケールの対応付けを独自のコードで行い、その結果をライブラリに渡してください。方法としては、[`getLocalePath`](/docs/react/nextjs/config#request-function-paths)で設定するカスタムロケール関数や、`gt-node`の[`withGT`](/docs/node/reference/functions/with-gt)などがあります。カノニカルタグ、hreflang、サイトマップについては、[多言語Next.jsアプリのSEOを設定するには？](/kb/multilingual-nextjs-seo)を参照してください。

## 重要なポイント

* Google は ccTLD、サブドメイン、サブディレクトリを、ランキングではなくターゲティングと運用・保守の観点から比較しています。また、言語指定用の URL パラメータは推奨していません。
* ccTLD は国のシグナルになりますが、言語名のように見えるサブドメインやパスだけでは、そのシグナルにはなりません。言語やリージョンを明示的にターゲットにするには hreflang を使用してください。なお、Google は `.io`、`.ai`、`.co` を汎用ドメインとして扱います。
* 各ロケールでサイトとリリースプロセスを共有している場合は、まずサブディレクトリ (`example.com/de/`) を採用しましょう。この URL 構造を選んでも、デプロイや分析プロパティを 1 つにまとめる必要はありません。
* 国別 (`es-MX`) に分けるのは、価格、配送、法的条件、カタログが国ごとに異なる場合に限りましょう。それ以外の場合は言語 (`es`) 単位でターゲットにしてください。
* `gt-next` では、`pathConfig` を使ってパスプレフィックスによるルーティング、デフォルトロケールへのプレフィックス付与 (任意) 、ローカライズされたスラッグを利用できます。

## Related questions

- [hreflang とは？設定方法を解説](https://generaltranslation.com/ja/kb/what-is-hreflang.mdx): hreflang は、どの URL が同じページの言語版または地域版であるかを Google に伝え、検索結果に適切なページを表示させるための仕組みです。HTML の link タグ、HTTP の Link ヘッダー、またはサイトマップで追加し、すべてのリンクを相互に参照させたうえで、en-UK ではなく en-GB のような有効なコードを使用してください。
- [言語リダイレクトと SEO：URL、クッキー、Accept-Language のどれを使うべきか](https://generaltranslation.com/ja/kb/locale-routing-seo.mdx): Googlebot は Accept-Language ヘッダーを送信せず、クロールの大半を米国の IP アドレスから行います。そのため、インデックスさせたいすべてのページの言語は URL で決めましょう。保存済みのクッキーの選択、次いで Accept-Language を使うのは、/ のような中立的なルートのリダイレクト先を決める場合だけにとどめ、その際は一時的な 302 または 307 を使います。
- [多言語対応の Next.js アプリで SEO を設定するには？](https://generaltranslation.com/ja/kb/multilingual-nextjs-seo.mdx): 各言語に /en/about や /es/about のようなプレフィックス付きの URL を割り当て、公開している言語ごとに html lang、自己参照のカノニカル、x-default を含む hreflang の代替リンク、翻訳済みのタイトルと説明文、サイトマップのエントリを出力します。未公開のバージョンには noindex を指定します。General Translation の gt-next は各言語を専用の URL にルーティングし、getGT でタイトルを翻訳します。
- [ウェブサイトを多言語化するにはどうすればよいですか？](https://generaltranslation.com/ja/kb/make-website-multilingual.mdx): 翻訳をどこで管理するか（プロキシ、CMSプラグイン、サイトビルダー、または自前のコード）を選び、Googleの推奨どおり言語ごとに専用のURLを用意します。ページ全体に加えてタイトルとメタディスクリプションも翻訳し、hreflangで各言語版を関連付けます。また、訪問者を自動でリダイレクトするのではなく、言語切り替え機能を設置しましょう。

## Previous and next questions

- Previous question: [国際化とローカライゼーションの違い（i18n vs. l10n）](https://generaltranslation.com/ja/kb/internationalization-vs-localization.mdx)
- Next question: [疑似ローカライゼーションとは？](https://generaltranslation.com/ja/kb/pseudo-localization.mdx)

## Sitemap

See the [Knowledge Base sitemap](https://generaltranslation.com/ja/kb/sitemap.md) for every article.