多言語公式サイト構築：サブディレクトリと独立サイトの選び方—SEOと保守コストの比較

多言語対応の公式サイト構築において、長期的な自然検索を主な顧客獲得源とし、各言語版でブランド、製品体系、コンテンツ資産を共有する場合は、サブディレクトリを優先します。異なる国・地域ごとに独立した運営、コンテンツ戦略、技術スタックが必要な場合、または十分なローカライズリソースをすでに有する場合にのみ、独立サイトを選択する合理性があります。両アーキテクチャに絶対的な優劣はなく、違いは主に評価の蓄積方法、コンテンツ管理の境界、公開フロー、およびその後の保守負荷にあります。

一般的な構成には、example.com/en/、example.com/de/のような言語別サブディレクトリと、example.de、example.frのような国別または言語別の独立ドメインがあります。ほかに、en.example.comのようなサブドメインという中間的な形式もあります。技術的な分離には柔軟性がありますが、検索エンジンによるメインドメインとの関連性の扱いは通常、サブディレクトリほど直接的ではありません。そのため、評価の受け渡しや運用・保守の複雑さは、サブディレクトリよりも独立サイトに近くなることが多いです。

まず、検索資産を集約すべきかを確認する

サブディレクトリの中核的な価値は、コンテンツ、被リンク、ブランドへの言及、技術的最適化を同一のメインドメインに蓄積できる点にあります。メインサイトがすでに安定したインデックス登録と質の高い参照を獲得している場合、新しい言語ディレクトリもより速く発見・クロールされます。ページ間の内部リンクも、完全な情報アーキテクチャを形成しやすくなります。製品型番、仕様パラメータ、適用ソリューションが高度に共通しており、翻訳、単位換算、地域向け表現のみが必要な公式サイトでは、この集約効果が顕著です。

ただし、「評価の共有」を、翻訳ページを公開すればすぐに順位を獲得できるという意味に誤解してはなりません。英語ページが獲得した被リンクによって、日本語ページやドイツ語ページが対応する検索意図を自動的にカバーできるわけではありません。各言語ディレクトリには、インデックス可能なページ、明確な現地言語の文章、検索意図に合致したランディングコンテンツが依然として必要です。すべてのページで言語だけを置き換え、製品説明、タイトル、画像説明が完全に同一である場合も、ページ価値の不足を招き、インデックス効率に影響する可能性があります。

一方、独立サイトでは、市場ごとの検索資産を分けて構築します。その代償として、各ドメインがインデックス登録、コンテンツ蓄積、被リンク獲得、技術的信頼性の構築をそれぞれ経験する必要があります。利点は、現地チームがメインサイトのテンプレート、カテゴリー、公開ペースに制約されず、現地の製品ライン、納品条件、アフターサービス方針、検索習慣に合わせてサイトを再構築できることです。たとえば、標準型番や技術資料を重視する市場もあれば、小売向けセット、決済・配送、販促ページをより重視する市場もあります。独立サイトであれば、1つの情報アーキテクチャで無理に対応することを避けられます。

アーキテクチャを決めるのは、言語数だけではない

言語と市場は必ずしも一対一ではありません。スペイン語ページが複数の国を対象とする場合、1つの/es/ディレクトリを使用するか、複数の国別サイトに分けるかは、ページコンテンツが実際に異なるかどうかによって決まります。通貨、納品条件、製品認証の説明、連絡先、在庫の可視性、広告ランディングページがすべて同じであれば、まず言語ディレクトリを使用するほうが堅実です。逆に、現地のカテゴリ構造、価格設定ロジック、法的主体、配送範囲、マーケティング素材がすべて異なる場合、同じディレクトリ内に置き続けると、後に大量の条件分岐が必要となり、ページとデータレイヤーの保守が困難になります。

地域ターゲティングも、ドメインの末尾だけに依存してはなりません。どのアーキテクチャを採用する場合でも、検索エンジンがページの言語と対象地域を認識できるようにする必要があります。インデックス可能な各ページで正しいlang属性を使用し、言語または地域に対応するバージョン間で双方向のhreflangを設定し、アクセス可能なデフォルトバージョンを残し、ページ自身への参照も漏らしてはなりません。hreflangが解決するのはバージョンの対応付けであり、重複コンテンツ、低品質な翻訳、誤ったリダイレクトを修正するものではありません。

訪問者のIPに基づく自動リダイレクトは、多言語サイトにおいて手戻りが多くなりやすい設計です。検索エンジンのクロールノードの所在地域は実際の訪問者と異なるため、強制リダイレクトによりクローラーが対象ページへアクセスしにくくなる可能性があります。海外の購買担当者も、出張、プロキシネットワーク、言語の好みにより、別のバージョンを閲覧する必要がある場合があります。より安全な方法は、言語切替の入口を残し、初回アクセス時に閉じられる地域提案を表示することであり、訪問者を特定のバージョンに固定することではありません。

保守コストはコンテンツとデータの同期に潜んでいる

多くの評価では、ドメイン数、サーバー費用、初期開発期間だけを比較し、長期的な変更を見落としています。製品仕様の変更、販売終了品の代替、画像更新、資料ダウンロードリンク、フォーム項目、プライバシー文言、サイト内検索インデックスについて、どの言語版を同期し、どの市場では差異を維持するかを判断する必要があります。サブディレクトリで1つのコンテンツモデルを共有する場合、フィールド設計では「グローバル値」と「ローカル値」を確保する必要があります。型番や技術パラメータはグローバルデータで一元管理できますが、タイトル、訴求ポイント、FAQ、事例、行動喚起ボタンは現地で編集できるようにすべきです。

独立サイトの保守上の問題は、より多くの場合、バージョンの乖離として現れます。ある市場で正規化タグ、サイトマップ、構造化データを修正しても、ほかのサイトには同期されないことがあります。ある国別サイトが画像圧縮ルールを更新し、ページパフォーマンスに差が生じることもあります。広告ランディングページが一時的に公開された後、ナビゲーション、インデックス制御、計測タグの基準に組み込まれていない場合もあります。サイト数が増えた後に実際に増えるのはページの複製回数ではなく、テストマトリクスです。デスクトップとモバイル、言語切替、フォーム送信、通貨表示、サイト内リンク、robots設定、分析イベントのすべてを再確認する必要があります。

専門的な調査コンテンツを含むサイトでは、コンテンツの境界もサイト構築前に定める必要があります。たとえば、省エネルギー・環境保護産業における環境保護産業基金の投資研究のような資料を引用する場合、それが特定言語サイトの独立したリソースページなのか、業界コンテンツモジュールなのか、あるいは製品ページの補足資料なのかを明確にすべきです。一部の市場でしか検索価値がない場合は、すべての言語ディレクトリに機械的に複製すべきではありません。また、異なる言語ページで異なるテーマを無理に相互の代替バージョンとして指定すべきでもありません。

SEO上の損失を招きやすいいくつかの設定ポイント

• 言語セレクターがスクリプトでのみ生成され、ページのソースコードに安定したリンクがない。クローラーはほかの言語バージョンを確実に発見できず、サイトマップでもすべての内部的な関連を補うことは困難です。
• 異なる言語ページがすべて同じcanonicalを参照している。正規化タグは検索エンジンに「インデックス登録すべきバージョンは1つだけ」というシグナルを送るため、多言語でのインデックス登録という目的と衝突します。各有効な言語ページは通常、自身を正規URLとして指定すべきです。
• 翻訳後も元の言語のURL、画像代替テキスト、ページタイトルをそのまま使用している。URLを逐語的に翻訳する必要はありませんが、ページの主言語と主要要素が長期間一致しないと、ページの関連性を弱め、確認作業の難易度を高めます。
• すべての少数言語ページをnoindexに設定し、コンテンツが完成してから公開しようとする一方で、明確な復旧フローを構築していない。長期間除外されたページはクロール履歴が不足する可能性があり、その後公開しても、発見と評価をあらためて完了する必要があります。

可逆性から初期方針を判断する

アーキテクチャの選択では、将来の移行コストを考慮すべきです。サブディレクトリを独立サイトに分割するには、旧URLをページごとに対応付け、301リダイレクトを実装し、hreflangを更新し、被リンクを処理し、各ドメインを再検証する必要があります。独立サイトをメインドメインへ統合し直す場合も、同様に大量のリダイレクトとコンテンツの重複排除が伴います。そのため、市場にまだ独立した運営境界が形成されていない場合は、まずサブディレクトリで言語コンテンツ、問い合わせ導線、自然検索の需要を検証するほうが、通常は可逆性が高くなります。

逆に、異なる市場が独立したブランド表現、独立した商品カタログ、独立した取引ルール、継続的なローカルコンテンツ制作能力を持つことが当初から明確であれば、独立サイトを採用することで、後から共有システム内に例外ルールを重ねることを減らせます。評価時には、「独立ドメインが必要か」をより具体的な問いに置き換えるべきです。コンテンツは長期的に異なるのか、公開は独立しているのか、データは分離されているのか、技術的な変更は互いに影響しないのか。これらの問いに安定した答えを出せてこそ、アーキテクチャの選択は単なるドメイン形式にとどまりません。