Google公式によるhreflangとローカライズ版の解説

公開日:13/09/2026
作者:易営宝(Eyingbao)
閲覧数:
  • Google公式によるhreflangとローカライズ版の解説
Google Search Centralが多言語・多地域サイトにおけるhreflangとローカライズ版を公式に解説:言語・地域コード、双方向参照、canonicalとの連携、x-defaultの設定を把握し、重複コンテンツや誤ったリダイレクトを回避して、国際サイトの検索での可視性を向上させます。
今すぐ問い合わせ:4006552477

Google Search Central による多言語・多地域サイトの説明は、次の判断に集約されます。検索システムは、各 URL がどの言語または地域のユーザーを対象としているかを識別し、それらのページが重複コンテンツ、自動リダイレクト、またはパラメータの混乱によって生じた複数のコピーではなく、同等のローカライズ版であることを確認する必要があります。hreflang は検索エンジンに代替バージョン間の関係を宣言するシグナルであり、インデックス登録、ランキング、ページの強制切り替えを決定する指示ではありません。

したがって、導入前にまず「どの言語コードを追加すべきか」を問うのではなく、ページ間の関係を確認する必要があります。英語の商品ページ、ドイツ語の商品ページ、日本語の商品ページがそれぞれ異なる言語での閲覧ニーズに対応し、主要な商品、機能説明、コンバージョン導線が相互に対応している場合は、hreflang 関係を設定するのに適しています。同一言語のページが広告トラッキングパラメータ、絞り込み条件、ページネーション、またはセッション識別子によって複数の URL となっているだけの場合、それらをローカライズ版として相互に指定すべきではありません。

公式がいう「ローカライズ版」とは

ローカライズは機械的な翻訳と同義ではありません。Google の関連ドキュメントでは、言語バージョンと地域バージョンを区別しています。言語バージョンは「ページをどの言語で表現するか」を扱い、地域バージョンは「同じ言語でどの国または地域を対象とするか」を扱います。たとえば、米国向けと英国向けの英語ページはいずれもenを使用できますが、通貨、配送範囲、税金の説明、連絡先、在庫、仕様、または法的注意事項に実質的な違いがある場合は、それぞれ en-USen-GB を使用できます。

反対に、2 つのページでコンテンツ、価格、サービス条件が完全に同じで、ドメインまたはパスだけが異なる場合、無理に国別に分けても必ずしもシグナルが明確になるとは限りません。地域コードは、想定する配信市場だけを基準に多数の類似ページを作成するのではなく、実際のコンテンツまたはサービスの違いを反映すべきです。B2B サイトでは、製品仕様、最小発注数量、問い合わせフォームの項目、提供範囲によって、そのページが真に異なる市場向けバージョンであるかが決まることがよくあります。越境 EC モールでは、通貨、販売可能地域、物流ルールのほうが、識別可能なローカライズの違いを構成しやすくなります。

Google も、ページ上で閲覧可能な本文が宣言した言語と一致している必要があると強調しています。ナビゲーションバー、フッター、または一部のボタン文言だけを置き換え、主要な説明、技術資料、購入情報を別の言語のまま残していては、信頼できる言語バージョンとはなりません。検索結果の対象言語の判定は主にページコンテンツに基づきます。lang 属性はブラウザや支援技術による文書の理解に役立ちますが、読み取り可能な対象言語の本文に代わるものではありません。

hreflang が成立する 3 つの条件

第 1 に、代替関係は双方向で完結していなければなりません。A ページが B をドイツ語版として宣言する場合、B ページも A を英語版として宣言する必要があります。相互リンクが欠けていると、検索システムはこれが管理された対応関係であることを確認しにくくなります。複数の言語バージョンは同一グループ内で相互に参照し、各ページには自身の hreflang エントリも含める必要があります。自己参照は単なる装飾ではなく、各 URL の所属する言語グループの定義を一貫させる役割を果たします。

第 2 に、コードには有効な言語と地域の組み合わせを使用する必要があります。言語部分にはdejazhなどの ISO 639-1 コードを使用し、地域部分には DEJPCNなどの ISO 3166-1 Alpha 2 コードを使用します。言語を前、地域を後に置き、ハイフンで接続します。de-DE はドイツのドイツ語を表し、de は地域を限定しないドイツ語を表します。国コードを単独で言語コードとして使用すること、独自の市場略称を使用すること、または言語と地域の位置を逆にすることは、宣言の意図した意味を失わせます。

第 3 に、対象 URL はユーザーとクローラーがアクセス可能な正規ページでなければなりません。hreflang がリダイレクトする URL、エラーを返す URL、robots ルールによってクロールを阻止される URL、または canonical が別のアドレスを指す URL を参照している場合、シグナル間で競合が生じます。よくある手戻りは公開後に発生します。コンテンツチームが商品ページのパスを変更した一方で、開発チームが古い言語マッピングを残している場合や、モールが地域別に在庫を切り替えた後、在庫切れページをトップページへリダイレクトする場合です。こうした変更はいずれも、元の代替グループを壊します。

Google公式によるhreflangとローカライズ版の解説

3 つの実装方法、安定して維持できるものを選ぶ

Google は、HTML の&lt;head><link rel="alternate" hreflang="..." href="..."> を追加する方法のほか、HTTP レスポンスヘッダーまたは XML Sitemap での送信にも対応しています。3 つの方法はいずれも同じ種類の関係を表すため、通常は公開アーキテクチャに最も適した 1 つを選べば十分です。一般的な HTML ページでは、head タグを使うとページテンプレートに沿って生成しやすくなります。PDF などの非 HTML 文書には HTTP ヘッダーが適しており、言語バージョン数が多く集中管理されたコンテンツシステムで運用している場合は、Sitemap によりページテンプレート内の重複出力を削減できます。

複数のソースを相互補完の仕組みとして扱うことは推奨されません。HTML、Sitemap、レスポンスヘッダー内の URL セットまたはコードが一致しない場合、調査時に明確な根拠が失われます。どの方法を採用する場合も、ページ単位のマッピング表を唯一の信頼できる情報源とすべきです。元の URL、正規 URL、言語コード、地域コード、対応バージョン、公開終了状態を同期して更新する必要があります。商品販売終了、ディレクトリ移行、ドメイン変更の際には、このマッピング表のほうが一時的にコードを一括置換するより信頼性があります。

x-default の位置付けと境界

x-default は、より適切な言語または地域の一致がない場合のデフォルトページを指定するために使用されます。言語選択ページ、グローバル入口ページ、または訪問者が市場を自分で選択できるデフォルトバージョンでよく使用されます。これは「国際サイトのトップページ」の固定ラベルではなく、各具体的な言語ページの hreflang 宣言を置き換えるものでもありません。

自動ジオロケーションページをx-defaultとして指定する際には、特に注意が必要です。Google は、IP アドレスやブラウザ言語に基づいてクローラーとユーザーを異なるページへ強制的にリダイレクトしないよう明確に推奨しています。自動リダイレクトにより、ユーザーは指定 URL にアクセスしにくくなり、クローラーも各バージョンのコンテンツを安定して取得できなくなる可能性があります。より安全な方法は、アクセス可能な各バージョンの URL を維持し、ページ上に見える言語または地域の切り替え入口を提供することです。ユーザーが明確に選択した後にのみ、設定を保存します。

canonical と hreflang は個別に設定できない

canonical は「複数の類似 URL のうち、どれが優先バージョンか」を解決し、hreflang は「異なる言語または地域バージョンをどのように対応付けるか」を解決します。この 2 つはしばしば混同されます。英語ページとフランス語ページは、構造が同一であっても、コンテンツが似ているという理由でフランス語ページの canonical を英語ページに指定すべきではありません。そうすると、検索エンジンに対してフランス語ページは独立した優先ページではないと伝えることになり、フランス語の代替バージョンとしての宣言と矛盾します。

より適切な設定は、各言語または地域ページで自己参照 canonical を使用し、hreflang で他の同等バージョンへ接続することです。同一言語バージョン内に URL パラメータ、大文字・小文字、末尾スラッシュ、印刷用ページ、または重複パスが存在する場合にのみ、その言語内で canonical を選択します。まず正規化を整理し、その後で国際化マッピングを構築することで、URL 整理の問題を言語バージョンの問題と誤認することを防げます。

公開後に確認すべきシグナル

検証では、ソースコード内にタグが存在するかだけを見るべきではありません。まず一組のページを抽出して確認します。各href がインデックス可能な成功レスポンスを返すか、最終的な正規 URL に直接到達するか、ページに相互リンクが含まれているか、言語コードが本文および市場条件と一致しているかを確認します。続いてサイトマップ、テンプレートのレンダリング、キャッシュ層を確認し、異なる地域からアクセスした場合に異なる hreflang セットが出力されないことを確認します。

Search Console における国際ターゲティング関連の異常、検出されたものの正しく処理されていない代替ページ、正規ページの選択結果はいずれも問題の特定に利用できます。ここでは 2 つの現象を区別する必要があります。検索結果に対象地域のページが表示されないことは、必ずしも hreflang の不具合を意味しません。検索クエリの言語、ユーザーの位置、ページの関連性、インデックスの状態はいずれも表示に影響します。一方、代替ページが長期間クロールできない、相互参照が欠けている、または canonical が言語をまたぐページを指している場合は、設定レベルで優先的に修正すべきシグナルです。

hreflang の価値は、検索システムによる言語バージョン間の関係の推測を減らすことにあります。前提となるのはタグ数の多さではなく、URL、コンテンツ言語、正規化戦略、サイトの実際のサービス提供範囲が同一の事実を示していることです。

今すぐ問い合わせ

関連記事

関連製品