hreflangタグの使い方：完全ガイドと無料ツール
サイトが複数の言語や国に向けてコンテンツを提供しているなら、hreflangタグは、どのURLがどの読者向けのものかを検索エンジンに伝える役割を持ちます。正しく機能するクラスターは、Googleが各読者に適切なバージョンを表示する助けになります。壊れたクラスターでは、Googleが重複ページの間を行き来したり、誤ったバージョンをランク付けしたりする事態になりかねません。このガイドでは、構文、リターンタグ（相互参照）、x-default、そしてアノテーションセットを知らぬ間に無効化するミスを解説します。加えて、有効なタグを出力する無料のhreflangタグジェネレーターと、XMLサイトマップによる代替方法も紹介します。
hreflangタグとは何か？
hreflangは、HTMLの<link>要素に指定する属性で、一連のURLが同じコンテンツのローカライズ版であることを示すものです。
<link rel="alternate" hreflang="de-DE" href="https://example.com/de/" />このタグは、すべての言語バージョンの<head>内に記述します。
押さえておくべき事実が2つあります。1つは、hreflangはヒントであって指令（ディレクティブ）ではないということ——有効なセットはGoogleが適切なバージョンを表示する助けにはなりますが、強制はしません。もう1つは、Googleはページの言語の検出にhreflang（やlang属性）を使わないということです。言語の判定はアルゴリズムで行われます。
hreflangの構文：言語・文字・地域コード
値は「言語、任意の文字（スクリプト）、任意の地域」という固定の順序に従い、それぞれISO 639-1、ISO 15924、ISO 3166-1 Alpha 2から採ります。コードの大文字・小文字は区別されませんが、慣例では言語を小文字、地域を大文字で書きます。
有効なコードの例：
en-GB——英国ユーザー向けの英語zh-Hans——中国語（簡体字）
Googleのドキュメントが指摘する落とし穴：
en-UK——無効。UKはISO 3166-1で正式に割り当てられた要素ではないため、Googleはこれを無視します（EUやUNも同様）。en-GBを使いましょう。gb-en——順序の誤り。言語は必ず先に来ます。es-419——数字のUN地域コードには未対応。有効なのはISO 3166-1 Alpha 2だけです。beを「ベルギー」の意味で使うケース——地域だけの指定は無効で、しかもbeはベラルーシ語という言語コードです。nl-BE、fr-BE、de-BEを使いましょう。
1つの言語の複数ロケールに関するGoogleのガイダンスはこうです。1つの言語の複数のロケール（en-IE、en-CA、en-AUなど）をターゲットにするなら、それ以外の全員向けに汎用のenを包括的に用意すること。Googleはこれを「良いアイデア」と呼んでおり、必須要件ではありません。また、この包括用エントリは地域版のいずれかとURLを共有してかまいません——enはen-IEと同じURLを指していても大丈夫です。
リターンタグ：すべてのバージョンが参照し返さなければならない理由
リターンタグとは相互参照のルールです。ページXがページYにリンクしているなら、YはXへリンクし返す必要があります——さらに、各バージョンは自分自身もリストに入れなければなりません。Googleのルールでは、2つのページが互いを指し合っていなければ、そのアノテーションは無視されます。よく挙げられる根拠は、返しのリンクがなければ、誰でも自分のページをあなたのページの代替版だと主張できてしまうというものです。英語版とドイツ語版を持つサイトでは、両ページの<head>に同じタグセットが入ります。
<link rel="alternate" hreflang="en" href="https://example.com/" />
<link rel="alternate" hreflang="de-DE" href="https://example.com/de/" />どちらのページにもこの2行が入ります。どれか1つのバージョンでセットを省くと、クラスターは崩れ始めます。Googleのドキュメントには緩和策も記載されています。完全な双方向セットの維持が難しくなったら、一部のページで一部の言語を省略してよい——その場合も、互いを指し合っているペアは機能し続けます。優先順位に関するGoogleの方針は、新しく追加する言語バージョンは、サイトの起点となった（主要な）言語と双方向にリンクすることです。フランス語の.frページから成長したサイトなら、新しいスペイン語版はまずフランス語ページとリンクを結び、次に互い同士を結びます。
x-defaultとは何か、いつ必要か？
x-defaultは予約値で、リストした言語のどれもユーザーのブラウザ設定と一致しないときに提供するURLを指定します——linkタグを1つ追加するだけで、言語コードは付きません。
<link rel="alternate" hreflang="en-GB" href="https://example.com/uk/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/select-language/" />x-defaultは任意ですが、設定が推奨されます——言語選択ページや自動リダイレクトするホームページ向けに設計されたものです。デフォルト言語版を指すのがもう1つの定番パターンで、ジェネレーターもこちらを想定しています。
hreflangタグを実装する3つの方法
Googleはこの3つの方法をまったく同等に扱います。ドキュメントには、3つすべてを同時に使っても「検索面でのメリットはなく」、1つに絞るより管理が難しくなるだけだと記載されています。
1. head内のHTML linkタグ
小規模サイト向けの方法です。すべてのバージョンの整形式な<head>内に、完全なセットを配置します。Googleのルールが2つあります。1つは、タグが必ずheadの中に実在すること（CMSがマークアップを書き換える場合は、レンダリング後のHTMLを検証してください）。もう1つは、hreflangをmediaなどの属性と1つのタグに併記しないことです。
2. XMLサイトマップによるアノテーション
規模が大きくなったら、hreflangをHTMLの外に出しましょう。各<url>エントリの中に、<loc>と並べて、自分自身を含むすべてのバージョンぶんのxhtml:link子要素を追加します。
<url>
<loc>https://example.com/</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://example.com/" />
<xhtml:link rel="alternate" hreflang="de-DE" href="https://example.com/de/" />
</url>xmlns:xhtml="http://www.w3.org/1999/xhtml"名前空間を宣言し、バージョンごとに<url>ブロックを繰り返します。子要素の順序は問わず、Googleはxhtml:linkの子要素がサイトマップのURL上限に数えられないことも明言しています——プロトコルの50,000 URL上限が数えるのは<url>エントリだけだからです。
3. HTTP Linkヘッダー
PDFなどのHTML以外のファイルには、ファイルを配信する箇所でLinkヘッダーを設定します——nginxなら、対象のロケーションへのadd_headerルールで書きます。
add_header Link '<https://example.com/file.pdf>; rel="alternate"; hreflang="en",
<https://example.com/de/file.pdf>; rel="alternate"; hreflang="de"';ApacheのHeader setやCDNのレスポンスヘッダールールでも同じことができます。
無料ツールでhreflangタグを生成する方法
hreflangタグジェネレーターはセットを組み立て、入力しながら検証を行います——登録不要で、ブラウザ内で動作します。
ステップ1：完全なセットを組み立てる
バージョンごとに1行追加します——左に言語コード、右に絶対URL——注釈を付けるページ自身を指す行も含めます。自己参照は必須で、この同一のセットをすべてのバージョンのheadに貼り付けます（ステップ4）。つまり、一度だけ、完全な形で作ります。コードは「言語 – 文字 – 地域」のパターンに対してリアルタイムに検証され、en、pt-BR、zh-Hansは通り、gb-enにはフラグが立ちます。大文字・小文字は正規化され、en-gbはen-GBに変換されます。
ステップ2：x-defaultのURLを設定する
フォールバックURL（デフォルト言語版または選択ページ）を入力するか、空のままにしてx-defaultを省略します。URLがセットの外を指していると警告が出ます。選択ページであれば、言語クラスターの外に置くのが設計どおりですから、正常かつ正しい警告です。選択ページでないのに警告が出るなら、たいていは入力ミスです。
ステップ3：生成してチェック結果を確認する
Generate hreflang tagsをクリックします。チェックリストは、重複した言語コードをエラーとして指摘し、絶対URLでないURLを拒否し、自己参照と1エントリだけのセットについて警告を出します。1エントリだけというのは、たいてい他のバージョンの入れ忘れです——hreflangは2つ以上のバージョンが互いを参照してはじめて価値が出るので、追加しましょう。対応する版が存在しないページには、そもそもhreflangは不要です。赤い項目を修正したら、再生成します。
ステップ4：必要な形式で出力をコピーする
出力は2つのタブに分かれています。HTML link tagsはそのまま<head>に使えます——同一のブロックをすべてのバージョンに貼り付けてください。XML sitemapは完全なサイトマップではなく<url>ブロックを出力します。完全なサイトマップの<urlset>要素の中（名前空間は上記のとおり）に貼り付けてください。XMLサイトマップジェネレーターで作ったベースファイルなどが使えます。Copy codeとDownload fileで出力を移します。多言語headの残りの部分は、メタタグジェネレーターでまかなえます。
よくあるhreflangのミス（と修正方法）
ミス1：自己参照エントリの入れ忘れ
最も多いエラーです。ページ自身を除くすべてのバージョンがリストされている状態です。Googleのルールは逆で、各バージョンは自分自身と他のすべてをリストしなければなりません。修正方法：現在のページの行を追加します。
ミス2：片方向のアノテーション（リターンタグの欠落）
ドイツ語ページが英語ページをリストしているのに、逆方向は一度も追加されていない——Googleは片方向のペアを無視します。修正方法：すべてのバージョンに同一のセットを置くこと。リリースやURL変更のあとは、両側を再確認します。
ミス3：無効または順序の誤ったコード
en-UK、es-419、gb-en、地域だけの指定——Googleは無効な地域や不正な形式のコードを無視し、クラスターのその部分を静かに無効化します。修正方法：言語を先に（ISO 639-1）、地域を後に（ISO 3166-1 Alpha 2）。ジェネレーターはコードをリアルタイムに検証します。
ミス4：hreflangがcanonicalと衝突する
各バージョンは自己参照のcanonicalを持つべきです。ドイツ語ページが英語ページにcanonicalを向けていると、hreflangがそのページを「対等な代替版」と呼ぶまさにその瞬間に、canonicalが「重複」と宣言することになります——セットの機能を止めかねない、矛盾したシグナルです。修正方法：どこも自己canonicalにして、グループ化はhreflangに任せます。
ミス5：セット内のリダイレクトURL・相対URL
代替URLは完全修飾でなければなりません——https://example.com/de/はOK、/de/や//example.com/de/は不可——そして、リダイレクトチェーンではなく200を返すべきです。de-DEエントリがどこかへ301リダイレクトしていると、Googleはまずそのチェーンを解決するよう強制されます。監査のときにはリダイレクトチェーンチェッカーにURLを通し、レンダリング後のソースでタグが整形式のheadの中に載っていることを確認します。
よくある質問
hreflangタグはランキングを改善しますか？
直接は改善しません——hreflangは、Googleが適切なバージョンを提供するのを助けるルーティングシグナルであって、ランキングの押し上げではありません。効果は間接的ですが本物です。競合する重複バージョンが減り、ユーザーが自分の言語のページにたどり着くようになります。
hreflangタグはheadに入れなければなりませんか？
HTMLメソッドを使う場合だけです。この方法では、タグは整形式のheadの中に置かなければなりません。headのマークアップを制御できない場合は、サイトマップとHTTPヘッダーのメソッドが同等の代替手段になります。
x-defaultは必須ですか？
いいえ。任意の項目で、言語選択ページや自動リダイレクトするホームページで最も効果を発揮します。他の大半のサイトはデフォルト言語版を指しており、これも安全なパターンです。
hreflang URLは異なるドメインに置けますか？
はい。代替URLはドメインを共有する必要がなく、だからこそhreflangはexample.deやexample.co.jpのようなccTLDで標準的な手法です。ccTLDや国サブドメインはGoogleに地理的なヒントを与えますが、どのURL同士が互いの代替版かまでは教えません。すべてのバージョンを明示的にマッピングしましょう。
hreflangタグを確認する方法と、修正の反映までの期間は？
各バージョンのレンダリング後のソースを確認し、自己参照を含む完全なセットがheadの中に載っていることを確かめます。サードパーティのhreflangテスターはライブページを検証します（GoogleはAleyda SolisのジェネレーターとMerkleのhreflangテスターを挙げています）。クローラーを使えば、このチェックをサイト全体に拡大できます。Search Consoleのインターナショナルターゲティングレポートは2022年に廃止されたため、そこに専用のhreflangエラーレポートはもうありません。修正は、クラスター内の各URLが再クロールされるたびに反映されていきます——通常は数日から数週間です。
en-USとen-GBのような同一言語ページにhreflangを使えますか？
はい。1つの言語内の地域差は、Google自身のユースケースに含まれています。米国、英国、アイルランドに向けた英語コンテンツがその例です。翻訳は必須ではなく、タグはGoogleにどの地域バリアントを提供すべきかを伝えます——違いが通貨や配送情報だけということもあります。
セット内の1つのバージョンがnoindexまたはブロックされているとどうなりますか？
クラスター内のすべてのURLは、クロール可能かつインデックス可能であるべきです。noindexまたはブロックされたページは代替版として表示できず、死んだエントリは残りのバージョンのペアリングを弱めます。ブロックを解除するか、すべてのページのセットからそのバージョンを外しましょう。
hreflang URLはcanonical URLと完全に一致しなければなりませんか？
一致させるべきです。各エントリが指すのは、そのバージョンのcanonicalが指すURL——同じプロトコル、ホスト、末尾のスラッシュです。エントリは完全修飾URLでなければならず、非正規のターゲット（トラッキングパラメータ、うっかり混入した末尾のスラッシュ）は、Googleにペアリングの前に重複の解決を強制します。完全一致のURLと自己canonicalの組み合わせが、クラスターをきれいに保ちます。