hreflang完全ガイド：実装・コード・デバッグ

hreflangは、国際SEOで最も重要なシグナルの一つであると同時に、設定ミスが特に多いものでもあります。Googleが「ユーザーを適切な言語のページに誘導してくれる」ことを期待してアノテーションを追加しても、数か月後になって、戻りリンクの欠落、無効な地域コード、クラスターと矛盾するcanonicalタグなどが見つかることがあります。

このガイドは、実装に役立つ実践的なリファレンスです。hreflangにできること・できないこと、必要になる場面、サポートされている3つの実装方法、重要なクラスターのルール、コードとx-defaultの仕組み、canonicalとの整合性の取り方、アノテーションが無視される原因となるミスの調査方法を解説します。内容はGoogleのドキュメントに基づいており、検索順位を保証するものではありません。

このガイドでわかること

• hreflangとは何ですか？どのような問題を解決しますか？
• サイトにhreflangを実装すべきなのはどのような場合ですか？
• サポートされている3つの実装方法とは何ですか？どのように選べばよいですか？
• すべてのhreflangクラスターが守るべきルールは何ですか？
• x-defaultを含め、言語コードと地域コードはどのように機能しますか？
• hreflangとcanonicalタグはどのように組み合わせるべきですか？
• hreflangでよくあるミスと、その調査・修正方法は？
• hreflangはページの言語を検出したり、翻訳の代わりになったりしますか？

要点：hreflangの役割

hreflangは、ページの言語別・地域別バージョンをGoogleに伝え、検索からユーザーを最適なバージョンに誘導できるようにします。Googleはアノテーションがなくても一部の別言語版を見つけられる場合がありますが、明示的に指定することが推奨されています。

hreflangでは、次のことはできません。

• ページの言語を検出すること（GoogleはhreflangやHTMLのlang属性ではなく、画面に表示されるコンテンツをアルゴリズムで分析して判断します）
• 翻訳やローカライズ作業の代わりになること
• 特定の国や言語での検索順位を保証すること

言語の検出や検索順位を上げる手段ではなく、代替URL同士の関係を示すマップとして捉えてください。

hreflangが必要になる場面

Googleは、次のような場合に代替ページのアノテーションを推奨しています。

• メインコンテンツは単一の言語のまま、テンプレート部分のみを翻訳している場合
• 同じ言語で、地域ごとに小さな違いがある場合（通貨、連絡先、法的文言など）
• コンテンツ全体を複数の言語に翻訳している場合

ローカライズ版が重複として扱われるのは、メインコンテンツが翻訳されていない場合に限られます。この区別は重要です。同じ言語で国ごとに一部だけを調整したページも、有効な代替ページになり得ます。一方、ナビゲーションなどの周辺要素だけを「翻訳」したページを、完全な別言語版として扱うべきではありません。

通常、言語や国が異なるユーザーを、同じ検索意図に対応する別々のクロール可能なURLへ誘導したい場合は、hreflangが必要です。単一言語・単一市場のサイトや、あえて世界共通のURLを1つだけ公開し、すべてのユーザーに同じ体験を提供する場合は、必要ないこともあります。

フォルダ名やサブドメインのラベル（/de/、de.example.com）だけでは不十分です。対象ユーザーを明示的に対応付けない限り、Googleはパスやサブドメイン内のコードを対象ユーザーの判定に使用しません。通常、その対応付けに使うのがhreflangです。

クラスターの基本ルール

正しく設定されたhreflangは、必ずクラスターを形成します。クラスターとは、互いを代替ページとして指定するURLの集合です。Googleのルールは厳格で、不完全なクラスターはエラーが表面化しないまま機能しなくなることがよくあります。

大規模なサイトで完全な双方向の参照関係を維持するのが難しい場合でも、Googleは相互に参照しているペアを処理します。ただし、新しい言語版は、元の言語版または主要な言語版と双方向にリンクさせる必要があります。「一部だけの相互参照」を長期的な戦略にせず、移行時のリスクとして捉えてください。

言語コードと地域コード

hreflangの値には、ISO 639-1の言語コードを使用します。必要に応じて、ISO 3166-1 Alpha 2の地域コードを組み合わせることもできます。

避けるべき無効な指定や効果のない指定：

• 地域のみの指定（US）—無効です
• EU、UN、UKをGoogle検索に影響する地域コードとして扱うこと—これらにその効果はありません
• es-419など、サポートされていない形式

複数の地域別URLで同じ言語を使用する場合（例：en-IE、en-CA、en-AU）、地域を特定できないその言語のユーザー向けに、enのような地域指定のない言語共通のURLも用意してください。

ほかに一致する言語や地域がない場合のフォールバックには、x-defaultを使用します。特に、言語選択ページや自動リダイレクトするホームページで有用です。x-defaultは「英語」ではなく、「より適切な一致先がない」ことを意味します。

実装方法1：HTMLのlinkタグ

alternateのlinkタグは、正しい構造の<head>内に配置してください。同じlinkタグで、hreflangとmediaなどの別の表現形式を示す属性を併用しないでください。

小規模なクラスターの例（en-US、en-GB、fr、x-default）：

<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/pricing" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/pricing" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/pricing" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing" />

クラスター内のすべてのページに、自身のURLも含めた同じ一式のアノテーションが必要です。ページを手作業で編集するより、CMSや静的サイトジェネレーターの共通ロケール対応表からタグを生成する方が安全です。

実装方法2：HTTPヘッダー

HTML以外のファイルを扱う場合や、エッジ／CDN環境でヘッダーの挿入が適している場合、Googleは同じ意味を持つHTTPのLinkヘッダーをサポートしています。

Link: <https://example.com/en-us/pricing>; rel="alternate"; hreflang="en-US",
      <https://example.com/en-gb/pricing>; rel="alternate"; hreflang="en-GB",
      <https://example.com/fr/pricing>; rel="alternate"; hreflang="fr",
      <https://example.com/pricing>; rel="alternate"; hreflang="x-default"

ヘッダーはHTMLの<head>を挿入しにくい場合に便利ですが、コンテンツ担当チームには確認しづらい方法です。ヘッダーを使用する場合は、生成元のサービスを文書化し、QAにヘッダーの確認を含めてください。

実装方法3：XMLサイトマップ

サイトマップでは、xhtml:linkのエントリで別の言語版やロケール版を指定できます。各URLのエントリには、自身も含めてすべての代替URLを記載してください。

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://example.com/en-us/pricing</loc>
    <xhtml:link rel="alternate" hreflang="en-US" href="https://example.com/en-us/pricing"/>
    <xhtml:link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/pricing"/>
    <xhtml:link rel="alternate" hreflang="fr" href="https://example.com/fr/pricing"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/pricing"/>
  </url>
  <!-- Repeat a <url> block for each alternate, each listing the full set -->
</urlset>

サイトマップの生成は大規模なカタログにも対応しやすい方法です。ただし、ロケールの追加や削除時に、相互参照の一式をすべて再生成するパイプラインが必要です。

実装方法を1つに絞る

Googleにとって、HTMLタグ、HTTPヘッダー、サイトマップは同等です。3つすべてを同時に使っても検索の成果は向上せず、不整合が生じるリスクが増すだけです。

正とする情報源を1つに決めましょう。多くの開発チームは、大規模なサイトにはサイトマップを、ロケール数の少ないマーケティングサイトにはHTMLを選びます。相互参照が正しく保たれていれば、どちらでも問題ありません。

hreflangとcanonicalタグ

hreflangとcanonicalは、それぞれ異なる問題を解決します。hreflangは言語や地域ごとの代替ページを関連付けます。canonicalは、ほぼ重複するページの中から優先するURLを指定します。

両者の整合性を保つためのルール：

1. hreflangを使用する際は、同じ言語の正規ページを指定してください。同じ言語の正規ページがない場合は、代替として最も適切な言語のページを指定します。
2. 1つのrel="canonical"リンクに、hreflang、lang、media、typeの属性をまとめて付けないでください。こうしたアノテーションの組み合わせは正規化に使用されません。代替ページのアノテーションは分けて記述してください。
3. URLの正規化では、ほかの条件が同等であれば、Googleはクラスターに含まれないURLよりも、相互参照のあるhreflangクラスターに含まれるURLを優先します。
4. 複数の地域別URLに同じ言語の類似コンテンツや重複コンテンツがある場合は、優先するバージョンを選び、rel="canonical"とhreflangを併用してください。

同じ言語の国別ページでの実践的な構成例：各国のURLをhreflangの代替URL（en-US、en-CA）として指定し、各ページのcanonicalは自身を指すようにします。本当に統合したい場合は、意図的に選んだ優先URLを指すようにしても構いません。各国のURLが引き続き代替ページとして表示されることを期待しながら、すべての国のcanonicalを単一のグローバル向け英語URLに向けないでください。これらのシグナルは互いに矛盾します。

具体例：言語＋地域のクラスター

次のような料金ページを想定してみましょう。

• 米国向け英語：https://example.com/en-us/pricing → en-US
• 英国向け英語：https://example.com/en-gb/pricing → en-GB
• 全世界向けフランス語：https://example.com/fr/pricing → fr
• 言語選択ページ／フォールバック：https://example.com/pricing → x-default
• 任意の地域共通英語ページ：https://example.com/en/pricing → en（地域別の英語版がある場合に推奨）

上記のすべてのURLで、相互参照の完全なセットを出力します。米国向けページのHTMLには、自己参照に加えて、GB、FR、x-default、そして地域共通の英語ページを公開している場合はその参照も含めます。

運用管理のヒント：対応表をデータ（locale → url）として保存し、その対応表からアノテーションを生成します。いずれかのロケールに戻りリンクが欠けている場合は、CIを失敗させます。タグの手動編集では、3つ目の言語を公開する段階で対応しきれなくなります。

よくある間違いとデバッグ

Googleは、戻りリンクの欠落、誤った言語コード、誤った地域コードを、よくある間違いとして明示しています。実際、本番環境での不具合の多くは、次のいずれかに当てはまります。

デバッグの手順：

1. 想定するロケールとURLの対応表をエクスポートします。
2. サンプルURLについて、レンダリング済みHTML、ヘッダー、サイトマップのエントリを取得し、すべてのhreflangの参照先を一覧にします。
3. ページ自体への参照が含まれていることを確認します。
4. 各参照先が同じセットを返すことを確認します（移行中は、少なくとも相互参照が成立していることを確認します）。
5. ISOの一覧と照合してコードを検証し、UK／EU／UNは地域コードとして認めないようにします。
6. canonicalの参照先と言語が一致していることを確認します。
7. 初回公開時だけでなく、次のロケールを公開した後にも再確認します。

サードパーティの検証ツールは役立ちますが、Googleが管理しているものではありません。どれか1つのツールの合格表示に頼るのではなく、Googleのドキュメントと独自の相互参照テストを優先してください。

実装チェックリスト

• 代替ページ（複数言語または複数地域向けのURL）が必要か確認する
• タグを書く前にロケールとURLの対応表を作成する
• 実装方法（HTML、ヘッダー、サイトマップ）を1つ選ぶ
• 絶対URLのみを使う
• すべてのページに自己参照を含める
• 相互参照（戻りリンク）を徹底する
• 有効な言語コードと言語・地域の組み合わせコードを使い、必要な場合にのみ文字体系コードを追加する
• 同じ言語に地域別のバリエーションがある場合は、地域共通の言語ページへの参照を追加する
• 選択ページや、どの条件にも一致しない場合のフォールバックにx-defaultを設定する
• canonicalの指定では同じ言語のページを優先する
• canonicalとhreflangは別々のアノテーションとして指定する
• ロケールを追加・削除するたびに、URLをサンプリングして品質チェックを行う
• ユーザーが利用できる言語・地域切り替えリンクを用意する（UXをアノテーションだけに頼らない）

hreflangとAI回答エンジン

hreflangはGoogle検索向けのアノテーションです（代替ページのシグナルを認識する他の検索エンジンにも関係します）。言語別・地域別のページ間の関係をクローラーに伝えます。ただし、ChatGPT、Claude、Gemini、Perplexity、Copilot、Google AI Overviewsが回答で「正しい」言語版を選ぶことを保証するものではありません。

AI回答エンジンにとって引き続き有効なのは、各言語版がクロール可能かつインデックス登録可能であり、メインコンテンツが十分にローカライズされ、同じエンティティについて一貫した情報を提供していることです。こうした特性は、アシスタントがhreflang自体を無視する場合でも、ページの発見や情報源としての選定に役立ちます。Google向けのhreflangのデバッグ手順を、あらゆるAIのランキングを制御できる方法として適用しないでください。

検索エンジンごとの詳しい実装方法については、引き続きGoogleとBingそれぞれに特化した多言語SEOガイドを参照してください。

Google検索向けの最適化（hreflang）

hreflangアノテーションを主に利用するのはGoogle検索です。相互参照するページ群、有効なコード、整合性の取れたcanonical指定を、Googleのドキュメントに従って正確に実装してください。利用できる場合は、Search Consoleのインターナショナル関連レポートで問題を調査してください。

Bing向けの最適化（代替ページ）

Bingは、代替ページのシグナルをGoogleとは異なる形で扱う場合があります。Googleのhreflangによるページ群の扱いがそのまま当てはまると考えず、各ロケールのURLをクロール可能に保ち、Bing Webmaster Toolsでインデックスの登録状況を確認してください。

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

hreflangによって、ChatGPTに特定の言語版を選ばせることはできません。役立つのは、クロール可能で十分にローカライズされ、グラウンディングが行われる際に引用や情報源として利用できるURLです。回答でどの言語版が選ばれるかは不確実なものとして扱ってください。

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

GeminiやGoogleのAI機能でも、インデックス登録可能な各言語版を用意することは引き続き有効です。hreflangをAI Overviewsの言語切り替え機能と捉えず、ユーザーを第一に考えたローカライズ済みページを、Googleがクロールできる状態に保ってください。

プラットフォーム別ガイド：Google AI Overviews

AI Overviewsには、回答の裏付けとなるページへのリンクが表示される場合があります。hreflangだけで概要の言語が決まるわけではありません。ローカライズされ、インデックス登録可能なページを用意することが、引き続き実務上の前提となりますが、掲載が保証されるわけではありません。

GlotEOが担う役割

hreflangを正しく運用するには、技術面とコンテンツ運用面の両方で取り組む必要があります。対象市場が広がっても、言語・地域の対応表を、調査内容、制作指示書、公開済みの各言語版と常に整合させなければなりません。GlotEOの多言語SEOプラットフォームは、こうした多言語施策の編集ワークフローを支援できます。ただし、上記のアノテーションルールに代わるものではありません。

ロケールをまたいで編集管理を行う必要があるチームは、GlotEOの多言語SEOソリューションを活用し、GlotEOの料金・プランを比較検討できます。

言語ターゲティングと国別ターゲティングの戦略上の違いについては、インターナショナルSEOと多言語SEOの違いをご覧ください。URL構造や、翻訳とローカライズのどちらを選ぶかという判断は、上記のアノテーションルールと整合させる必要があります。