多言語サイトのSEO基盤を最初から正しく構築する方法

同じ製品ページを英語、ドイツ語、日本語で公開したにもかかわらず、検索結果にはデフォルト言語しか表示されない、あるいはドイツのユーザーが英語ページにアクセスしてしまう、異なる言語ページ同士でランキングを奪い合うといった問題は、通常、翻訳品質が原因ではありません。サイト構築の初期段階で、言語バージョン間のインデックス関係が明確に設計されていないことが原因です。

多言語サイトのSEO基盤を一度で正しく構築するにはどうすればよいでしょうか。重要なのは、まず拡張可能な言語アーキテクチャを確定し、インデックス対象となる各ページが、固有のURL、正しい言語コンテンツ、相互hreflang宣言、クロール可能なリンク、一貫した正規化ルールをすべて満たすようにすることです。翻訳はコンテンツ層の一部にすぎません。URL、canonical、言語切替、サイトマップのいずれかに競合があれば、検索エンジンは言語シグナルを無視する可能性があります。

「言語バージョン」と「地域バージョン」を明確に区別する

構築前に、まず一つの質問に答える必要があります。ページは言語別に提供するのか、それとも言語と市場別に提供するのか、ということです。英語をグローバルな訪問者向けに提供する場合はenを使用できます。米国版と英国版で、通貨、配送方法、事例、連絡先、または文言が実際に異なる場合にのみ、en-usとen-gbに分けるのが適切です。単にスペルをcolorとcolourに変更するだけでは、通常、2つの独立したページを設ける根拠にはなりません。

過度な分割はコンテンツの重複度を高め、保守コストを増加させるだけでなく、hreflang関係を継続的かつ正確に維持することも難しくします。一方で、実際にはロシア語圏、中東、ラテンアメリカなどの市場向けページがあるにもかかわらず、英語ページのみで対応すると、ローカル検索意図との一致度を弱めてしまいます。判断基準は販売地域の数ではなく、ページに安定して視認でき、ユーザーにとって意味のある差異があるかどうかです。

URLアーキテクチャを確定したら、システムに「言語を推測」させない

サブディレクトリ、サブドメイン、国別ドメインはいずれも検索エンジンで処理できます。重要なのは、長期的に保守可能であることです。コンテンツ、テンプレート、技術コンポーネントを一元管理する必要がある大半のサイトでは、サブディレクトリを使用するほうが明確な対応関係を構築しやすくなります。たとえば/en/products/、/de/produkte/のように設定します。どの形式を選択する場合でも、同一言語における同一ページには、安定したURLを1つだけ設定する必要があります。

以下のような方法には問題が残りやすくなります。パラメータで?lang=deを生成しているにもかかわらず重複ページを制御していない、言語を切り替えてもトップページに留まる、すべての言語を同一URLに置いてブラウザスクリプトで文字を置き換える、リニューアルのたびに言語パスを変更する、といった方法です。サーバーの初期レスポンスで、該当言語の主要本文、タイトル、内部リンクを取得できる必要があり、ユーザーのブラウザがスクリプトを実行した後に初めてコンテンツが表示される状態に完全に依存してはなりません。

言語セレクターも、ドロップダウンイベントやCookieだけに依存するのではなく、通常のクロール可能なリンクを使用する必要があります。ユーザーがドイツ語の製品詳細ページから英語に切り替える場合、理想的には対応する英語の製品ページに移動します。対応するバージョンがない場合は、その言語の上位カテゴリーページに戻すことはできますが、何も表示せずにトップページへ戻してはいけません。

hreflangは「代替ページ」を示すものであり、装飾タグではない

hreflangは、どのURLが同一のコンテンツ意図のもとで、異なる言語または地域のユーザー向けに用意された代替バージョンであるかを検索エンジンに伝えるために使用します。ページの

、HTTPレスポンスヘッダー、またはXMLサイトマップに記述できます。3つの方法のうち、いずれか1つを主要な管理方法として選択すれば十分です。ページレベルでの実装は最も直感的ですが、テンプレートの記載漏れによる不一致も発生しやすくなります。

正しい関係には、少なくとも3つの条件があります。各ページが自身を宣言していること、ページAがページBを宣言する場合はページBもページAを相互に宣言すること、宣言先のURLがアクセス可能かつインデックス可能で、200ステータスコードを返すことです。英語ページがドイツ語ページを指していても、ドイツ語ページが英語ページを参照していなければ、検索エンジンはこのシグナルセットを採用しない可能性があります。

<link rel="alternate" hreflang="en" href="https://example.com/en/product-a/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/produkt-a/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

x-defaultは、言語選択ページ、グローバル入口ページ、または明確な言語一致がない場合のデフォルトランディングページに設定するのに適していますが、実際の言語バージョンの代わりにはなりません。コード、URL、言語コンテンツは一致していなければなりません。ページの主要コンテンツが日本語であるにもかかわらずkoと設定したり、簡体字中国語をzh-twと設定したりすると、シグナルが不正確になります。

canonicalとhreflangが競合する場合、どちらを優先すべきか

これは多言語ページのインデックス登録異常の根本原因であることがよくあります。canonicalは「重複または類似する複数のページのうち、どれが主要バージョンか」を指定するために使用します。hreflangは「これらが異なる言語または地域向けの代替バージョンである」ことを示すために使用します。そのため、ドイツ語ページは通常、英語ページではなく自身にcanonicalを設定し、日本語ページも自身を指すべきです。すべてのバージョンを英語に正規化すると、システムが実際に伝える意味は、他言語ページを個別にインデックス対象にすべきではないということになります。その結果、hreflangは本来の役割を果たしにくくなります。

トラッキングパラメータ付きURL、印刷用ページ、絞り込みページなど、同一言語内に実際に重複するURLがある場合にのみ、canonicalをその言語の標準URLに集約すべきです。翻訳バージョン間の関係を処理するためにcanonicalを使用してはいけません。

コンテンツのローカライズでは、検索とコンバージョンに影響する領域を優先する

機械翻訳後にそのまま公開すると、表現が不自然になるだけでなく、ページtitle、description、パンくずリスト、画像の代替テキスト、フォームの案内、構造化データに元の言語が残ってしまうこともよくあります。検索エンジンは、ページ上で表示される本文や関連シグナルを総合して言語を判断します。一方ユーザーは、仕様の単位、時刻形式、電話番号形式、通貨、問い合わせ項目から、ページが本当に適合しているかを感じ取ります。

まずは主要ページの完全性を確保することを推奨します。トップページ、主要カテゴリーページ、重点製品ページ、サービスページ、問い合わせページ、および必要な信頼性に関する説明です。言語バージョンを公開する前に、少なくともそのバージョンに固有のタイトルと説明があるか、本文が対象市場の用語と一致しているか、内部リンクが同じ言語のパスへ移動するか、サイト内検索、絞り込み、資料ダウンロードが意図せずデフォルト言語に戻らないかを確認してください。

公開後はサンプルチェックを1回実施してブロック要因を確認する

1. 任意の主要ページを1つ選び、各言語のURLに順番にアクセスして、ステータスコードが200であり、他言語へ自動リダイレクトされないことを確認します。
2. ページのソースコードを確認し、canonicalが自身を指し、hreflangに自身とすべての対応バージョンが含まれていることを確認します。
3. 各言語ページからナビゲーション、パンくずリスト、言語切替をクリックし、リンクが正しいバージョンに安定して遷移するかを確認します。
4. XMLサイトマップで、インデックス可能な標準URLのみが送信され、リダイレクトページ、テストページ、noindexのページが混在していないことを確認します。
5. 検索エンジンのウェブマスターツールでクロール、インデックス、代替ページに関する通知を確認します。新しい言語を一括公開した後は、テンプレートが生成する宣言が完全かどうかを優先的に抜き取り確認します。

技術アーキテクチャをいったん確定したら、その後の言語追加をページごとの手作業によるタグ補完に依存すべきではありません。より確実な方法は、コンテンツモデルに「言語バージョングループ」とページの対応関係を保存し、サイト構築システムがルールに基づいてURL、canonical、言語切替リンク、hreflangを生成することです。これにより、新しい製品ページの作成、旧ページの公開終了、パスの変更時にも、各言語間の関係を同期して更新でき、サイト規模の拡大後に大量の孤立ページや無効な宣言が発生することを防げます。