国際展開を支えるウェブサイト設計：拡張しやすいURL構造

国際サイトのアーキテクチャは、あらゆる多言語・多地域SEO施策の土台となる設計上の意思決定です。翻訳を発注する前に、hreflangを設定する前に、そしてカタログを国別に分ける前に、検索エンジンがクロールでき、ユーザーがブックマークでき、チームが何年も維持できるURLパターンを決める必要があります。Googleはロケール別URLの選択肢をいくつか公開していますが、どれも検索順位を保証するものではありません。得られるメリットは明確さです。言語・市場ごとの各バージョンに、一貫したアノテーションを備えた、個別の検出可能なURLを割り当てられます。

このガイドでは、Googleが公開しているURL構造を、実際の設計上の選択肢に結び付けて解説します。ccTLD、サブドメイン、サブディレクトリがそれぞれどのような場合に適しているのか、パラメータが地域ターゲティングの主な手段として適さない理由、そしてhreflangやcanonicalがアーキテクチャに基づいて決まるのであって、その逆ではないことを説明します。言語ターゲティングと国別ターゲティングの戦略用語については、国際SEOと多言語SEOの違いをご覧ください。

このガイドでわかること

• Googleは国際サイト・多地域サイト向けにどのようなURL構造を公開していますか？
• ccTLD、サブドメイン、サブディレクトリは、それぞれどのような場合に選ぶべきですか？
• 地域ターゲティングの区分けにURLパラメータが推奨されないのはなぜですか？
• 言語のみを対象にする場合と国別に対象を設定する場合で、アーキテクチャをどう変えるべきですか？
• hreflangやcanonicalは、URLアーキテクチャの選択とどのように関係しますか？
• URLパス以外で重要なロケールのシグナルは何ですか？
• 国際サイトのURL構造を変更する際、移行をどう進めるべきですか？
• 言語別・地域別バージョンのクロールを妨げるアーキテクチャ上のミスには、どのようなものがありますか？

要点：市場マトリクスに基づいてアーキテクチャを決める

フォルダ名ではなく、国×言語のマトリクスから始めましょう。各セルに、その市場のユーザーに必要なものを書き出します。理解できる言語、現地通貨、注文の履行に関するルール、法的条件、あるいはそのすべてです。このマトリクスから、言語のみのパス（/de/）、国のみのパス（/us/）、言語と国を組み合わせたロケールのパス（/en-ca/）、または個別のccTLD（example.de）のどれが必要かを判断できます。

Googleは、単一のURLでCookieやブラウザ設定によって言語を切り替えるのではなく、言語バージョンごとに異なるURLを使用することを推奨しています。GooglebotはAccept-Languageなしでクロールすることが多く、通常は米国のインフラからアクセスするため、動的な切り替えでは各バージョンが検出されなくなります。したがって、アーキテクチャはまずクロールのしやすさを軸に決め、その次にブランディングを考えるべきです。

マトリクスが固まったら、エンジニアリングチームとローカライズチームが今後数年間運用できる構造を選びましょう。単一のgTLD配下にサブディレクトリを設ける方法は、多くの場合、最も保守の負担が少ない基本の選択肢です。法的要件、ブランド、ホスティングの事情から市場を明確に分離する必要がある場合は、ccTLDが適しています。サブドメインはその中間に位置します。URLパラメータも選択肢として公開されていますが、地域ターゲティングの区分けには推奨されていません。

Googleが公開しているURL構造

Googleの多地域・多言語サイトに関するドキュメントには、ロケール別URLのパターンが4つ挙げられています。いずれもバージョンごとに個別のURLを用意するもので、これは言語別・地域別バージョンをクロール可能にするための基本要件です。

いずれのパターンも、それだけで検索順位が決まるわけではありません。Googleはこれらをロケール別バージョンを検出可能にする手段として扱っており、自動的に順位を上げる要因とは見なしていません。

ccTLD、サブドメイン、サブディレクトリの選び方

設計レビューで、組織として選択の根拠を説明できる判断基準を使いましょう。

ccTLDは対象国を強く示しますが、費用が高くなったり、制約があったり、対象が1か国に限られたりする場合があります。Googleは、一部のccTLDを汎用トップレベルドメインとして扱うと説明しています。国別のターゲティングができると判断する前に、選んだTLDの分類を確認してください。

サブドメイン（de.example.com）は柔軟に分離でき、それぞれ異なるバックエンドに紐付けられます。ただしGoogleは、hreflangや一貫したページ上の情報などで対象ユーザーを明示しない限り、サブドメインのコードは対象ユーザーの判定に使用されないと明確に注意喚起しています。

サブディレクトリ（example.com/de/）は、単一ホストで最も簡単に構成できることが多く、継続的な保守の負担も抑えられます。一方で、意味が曖昧になるという欠点があります。/de/は、世界中のドイツ語ユーザー向け、ドイツ向けの英語コンテンツ、あるいはドイツ向けのドイツ語コンテンツのいずれも意味し得ます。フォルダ名を確定する前に、対応表で意図を明確にしてください。

パラメータを地域ターゲティングの主軸にすべきでない理由

Googleは、ロケールを指定する方法の一つとしてURLパラメータを挙げていますが、地域ターゲティングの区分には推奨していません。規模が拡大すると、パラメータには次のような問題が生じます。

1. クロールの重複。同じパスに複数の?loc=の値があると、パラメータの組み合わせによってURLが増えます。パラメータの処理を綿密に設定しない限り、シグナルが分散するおそれがあります。
2. ユーザーにとっての分かりにくさ。ブックマーク、共有、印刷物での利用には、安定したパスが適しています。パラメータでは、アクセス解析やサポートへの問い合わせでロケールを識別しにくくなります。
3. 検出漏れ。内部リンク、サイトマップ、hreflangクラスターには、いずれも絶対URLが必要です。パラメータに大きく依存する構成では、代替ページのセットが不完全なまま公開されがちです。
4. 将来の移行負担。後から?lang=frから/fr/へ移行するには、インデックスに登録されたすべてのURLバリエーションについて、リダイレクトの対応表が必要になります。

パラメータはトラッキングや認証後の表示には引き続き使えますが、区分の主軸には適していません。

言語別と国別のURL設計

言語のみを対象にする施策と国のみを対象にする施策では、基盤となるCMSが共通でも、必要なURL構造は異なります。

言語別ターゲティング（多言語SEO）は、「このユーザーにどの言語で読んでもらうべきか」に答えるものです。代表的な構成は次のとおりです。

• /en/、/es/、/ja/のサブディレクトリ
• en.example.com、es.example.comのサブドメイン
• グローバル向けの英語サイトを一つ用意し、言語別フォルダを順次追加

hreflangの値には通常、言語コードのみを使用します（hreflang="en"、hreflang="es"）。各URLが同じページを忠実に翻訳したものであれば、canonicalの方針はシンプルです。

国別ターゲティング（多地域SEO）は、「このユーザーにどの市場向けの体験を提供すべきか」に答えるものです。代表的な構成は次のとおりです。

• 国ごとのccTLD（example.co.uk、example.com.au）
• 国別のサブドメインまたはフォルダ（uk.example.com、example.com/us/）
• 言語と国の両方が異なる場合は、両者を組み合わせたロケール別フォルダ（/en-us/、/en-gb/、/fr-ca/）

hreflangの値には、言語と地域の組み合わせをよく使用します（hreflang="en-US"、hreflang="en-GB"）。複数の国別URLに、同じ言語でほぼ同一のコンテンツを掲載する場合、Googleは優先するバージョンを選び、rel="canonical"をhreflangと併用することを推奨しています。

多言語SEO施策全体の設計は、このURL層のガイドより上位に位置します。本記事では、そうした施策の基盤となるアーキテクチャの選択を扱います。

URL設計におけるhreflangとcanonical

hreflangとcanonicalはURL設計に代わるものではなく、選んだURLに補足情報を付けるものです。Googleは、HTMLのlinkタグ、HTTPヘッダー、サイトマップによるhreflang指定に対応しており、どの方法も同等です。各ローカライズ版URLには、自分自身と代替版へのリンクを完全修飾URLで記載し、相互に参照する必要があります。2つのページが互いを参照していないと、hreflangタグが無視される場合があります。

URL設計に基づくhreflangのルール：

• クラスター内の各言語版または各ロケール版に、一つのURLを割り当てる
• ユーザーに表示される正規アドレスと一致する絶対URLを使う
• 一致する言語がない場合はx-defaultを使い、通常は言語選択ページやグローバル向けの既定ページを指定する
• 対応表に合わせて、言語コードのみ（de）または言語と地域の組み合わせ（de-AT）を使う

canonicalとの関係：hreflangを使用する場合は、同じ言語の正規URLを指定します。同じ言語の正規URLがない場合は、利用可能な中で最適な代替言語を指定してください。複数地域向けのURLに同じ言語の類似コンテンツがある場合、たとえばexample.deとexample.com/de/の両方にドイツ語のコンテンツがある場合は、優先するURLを選び、canonicalとhreflangを併用します。これにより、検索エンジンは各重複ページを管理されていない重複とみなさずに、適切な地域のURLを表示できます。

ローカライズ版が問題のある重複とみなされるのは、メインコンテンツが未翻訳のままの場合だけです。同じ言語で地域ごとに少しずつ内容を変えることは、代替ページの正当な使い方です。

本記事では、URL設計に関わる範囲でhreflangを概説しています。相互参照リンク、無効な地域コード、サイトマップとHTMLの使い分け、クラスターの品質検証の仕組みについては、関連記事「hreflangクラスターの仕組みを独立した技術作業として扱う」で詳しく解説しています。URL設計から注釈の実装へ進む際にお読みください。

パス以外のロケールシグナル

URL構造は必要ですが、それだけでは十分ではありません。Googleは複数のシグナルを使って対象ロケールを判断します。

Googleは地域ターゲティングにおいて、geo.positionなどの位置情報メタタグを無視します。地域ターゲティングは完全に正確ではないため、ユーザーが意図しないバージョンにアクセスした際に、地域や言語を選べるリンクを用意しましょう。またGoogleは、特定の国をターゲットにすると、その国での検索結果が改善する一方、他の地域では不利になる可能性があると説明しています。これはトレードオフであり、世界全体での検索露出の向上を約束するものではありません。

言語の判定には別のルールが適用されます。GoogleはURL、lang属性、hreflangではなく、画面に表示されるコンテンツから言語を判定します。そのため、コンテンツとナビゲーションの両方が、主に1つの言語で構成されるページを配信できるサイト構造が必要です。

サイトマップと大規模サイトでのURL検出

言語・地域の組み合わせが増えるにつれて、サイトマップは内部リンクと並ぶ主要なURL検出経路になります。Google向けのサイトマップでは、言語・地域別の代替バージョンを指定でき、絞り込みメニューの深い階層に埋もれがちなURLをクローラーが見つけやすくなります。

サイトマップには正規URLのみを含め、対象市場の変更に合わせて最新の状態に保ち、サイトマップ内のhreflang指定をHTMLやヘッダーの指定と一致させましょう。ccTLDごとにアカウントが分かれている場合は、Search Consoleでプロパティごとにサイトマップを送信します。URLとアノテーションの基盤が安定したら、言語・地域ごとの構造化データによって、単純なURLリストにとどまらない形で検出を促進できます。

サイト構造を変更する際の移行パターン

初回公開時から完璧なサイト構造を実現できるチームは、ほとんどありません。よくある移行には、サブディレクトリからccTLDへの移行（法的な分離）、パラメータからフォルダへの移行（クロール可能な状態の回復）、サブドメインの統合、フォルダ名の変更などがあります。いずれの場合も、ホームページだけでなく、インデックス登録されているすべての言語・地域別URLについてリダイレクトの対応表を用意し、同じリリースでhreflangとcanonicalも更新する必要があります。

移行の原則は、まず対応マトリクスを確定し、できるだけ直接の301リダイレクトを使い、言語切り替えリンクの参照先を直ちに新URLに変更し、最初の1か月は毎週、相互参照を検証することです。Googleは回復までの固定的な期間を明示していません。トラフィックの回復を約束するのではなく、技術的な対応が完了していることを記録しましょう。

言語・地域別ページを見つかりにくくするサイト構造のミス

以下の問題は、クロールを妨げたり、言語・地域を示すシグナルを曖昧にしたりします。

最も高くつくミスは、サイト構造を見た目だけの問題と捉えることです。たとえば、本文が単一言語のままのURLで周辺のUIだけを翻訳して公開したり、ページ上の受注・配送対応情報を更新せずに国別に分けたりすることが挙げられます。ユーザーも検索システムも、実際に表示される内容を読み取ります。

実装チェックリスト

• 今後12〜24か月を見据えた「国×言語」のマトリクスを文書化する
• 各セルを「言語のみ」「国のみ」「両方の組み合わせ」に分類する
• ccTLD、サブドメイン、サブディレクトリのいずれかを選び、パラメータ主体の地域ターゲティングは避ける
• 言語別または言語・地域別の各バージョンに、クロール可能なURLを1つ割り当てる
• マトリクスの意図に合ったフォルダ名を付ける（/en-us/と/en/を意識的に使い分ける）
• 相互参照する絶対URLでhreflangクラスターを設計する
• 同じ言語で複数の国を対象とし、内容が重複するページの正規化方針を定める
• ユーザー向けの言語・地域切り替え機能を設け、ロケールに基づく強制リダイレクトを無効にする
• 定型文だけでなく、メインコンテンツとナビゲーションもローカライズする
• 正規URLと代替言語・地域版のアノテーションを含むサイトマップを公開する
• 公開後にインデックス登録状況とhreflangの相互参照を検証する
• ccTLDを使用する場合は、プロパティごとにSearch Consoleでのモニタリングを計画する

検索エンジンのクロールとインデックス登録

GooglebotやBingのクローラーには、ccTLD、サブドメイン、サブディレクトリのいずれを使う場合でも、安定していてリンク可能な言語別・国別URLが必要です。アーキテクチャの選択は、クロールバジェット、正規URLのクラスター、hreflangの対応関係に影響します。各ロケール版は、不透明なクライアント側のみのルーティングに依存せず、ボットが取得できるHTMLで提供しましょう。Google Search ConsoleとBing Webmaster Toolsで、ホスト別またはフォルダ別にインデックスのカバレッジを測定してください。

回答エンジンのアクセス、情報源の選定、多言語の理解

回答エンジンにも通常、人が開けるのと同じ、アクセス可能なURLが必要です。ある言語版が、認証の先やブロックされたスクリプト内にしか存在しない場合、または不安定なパラメータでしかアクセスできない場合、引用や情報源への採用候補としては不利になります。安定したロケール別パス、明確なページの目的、言語間で一貫したエンティティ情報を優先し、フランス語、ドイツ語、日本語のいずれでも、アシスタントが同じ組織だと認識できるようにしましょう。アーキテクチャによって引用が保証されるわけではありません。アクセスや理解を意図せず妨げている障壁を取り除くものです。

今後の公開予定：Google、Bing、ChatGPT、Claude、Gemini、Perplexity、Microsoft Copilotの各プラットフォームに特化した最適化ガイド。

Google検索向けの最適化

Googleがクロールし、hreflangで対応付けできるURLパターンを選びましょう。安定したホストまたはフォルダ、HTMLで提供する各言語版、ロケール間の明確な内部リンクが重要です。既知の制約は明確に文書化してください。根拠のないランキング要因を作り上げず、従来のインデックス関連指標と回答エンジンによる引用の確認を分けて扱いましょう。

Bing向けの最適化

Bingbotにも同様にクロールしやすい構成を用意し、Bing Webmaster Toolsでロケール別のホストやパスを検証しましょう。既知の制約は明確に文書化してください。根拠のないランキング要因を作り上げず、従来のインデックス関連指標と回答エンジンによる引用の確認を分けて扱いましょう。

プラットフォーム別ガイド：ChatGPT

アシスタントには、アクセス可能なロケール別URLが必要です。クライアント側だけで動作し、他言語版のHTMLにアクセスできない言語切り替え機能は、情報源へのアクセスを妨げます。既知の制約は明確に文書化してください。根拠のないランキング要因を作り上げず、従来のインデックス関連指標と回答エンジンによる引用の確認を分けて扱いましょう。

プラットフォーム別ガイド：Claude

信頼できる各ロケールのドキュメントは、サーバー経由でアクセスできる必要があります。コンテンツをアプリ内に閉じ込めるアーキテクチャでは、Claudeが情報源として活用しにくくなります。既知の制約は明確に文書化してください。根拠のないランキング要因を作り上げず、従来のインデックス関連指標と回答エンジンによる引用の確認を分けて扱いましょう。

プラットフォーム別ガイド：Gemini

GoogleエコシステムのAI機能に対応するうえでも、インデックス登録可能なロケール別アーキテクチャが引き続き実務上の基盤となります。既知の制約は明確に文書化してください。根拠のないランキング要因を作り上げず、従来のインデックス関連指標と回答エンジンによる引用の確認を分けて扱いましょう。

プラットフォーム別ガイド：Perplexity

安定した言語別URLは、パラメータだけでロケールを切り替える場当たり的な方法よりも、引用の持続性を高めます。既知の制約は明確に文書化してください。根拠のないランキング要因を作り上げず、従来のインデックス関連指標と回答エンジンによる引用の確認を分けて扱いましょう。

プラットフォーム別ガイド：Microsoft Copilot

Copilotによるコンテンツの発見がBingのインデックス登録と関係する場合は、Copilot独自のランキング要因を作り上げることなく、Bingがインデックス登録できる多言語アーキテクチャを維持しましょう。既知の制約は明確に文書化してください。根拠のないランキング要因を作り上げず、従来のインデックス関連指標と回答エンジンによる引用の確認を分けて扱いましょう。

GlotEOが担う役割

アーキテクチャの意思決定はエンジニアリングとSEOの責任者が担いますが、各ロケールのURLと翻訳済みページ、アノテーション、QAチェックリストの整合性を保つコンテンツ運用フローがなければ、うまく機能しません。GlotEOの多言語SEOソリューションは、多言語対応や国際展開におけるこうした編集・運用面を支援します。上記のマトリクス作成や移行作業を代替するものではなく、選択したURLパターンで、クロール可能な各言語版をチームが公開できるようサポートします。

継続的な測定に向けて、Search Consoleのプロパティ分割、hreflangのレポート作成、各ロケール版のカバレッジ確認を計画しましょう。構造化データの大規模な展開は、基盤が安定してから進められます。

ロケールを横断してコンテンツの編集・管理を行いたいチームは、GlotEOの多言語SEOプラットフォームを活用し、GlotEOの料金とプランを比較検討できます。