hreflangは「入れただけ」では機能しない ── 自己参照・相互参照・言語コードを確認する14項目（2026年9月時点）

01 何が起きたか — hreflangは「書いただけ」では機能しない

Google公式ドキュメントは何度も改訂されている

複数の言語や地域向けにページを用意しているサイトで、検索結果に表示されるURLを言語・地域に合わせて出し分けるための仕組みがhreflang（rel="alternate" hreflang="x"）です。この仕組み自体は2011年12月にGoogleが公式ブログで導入を発表した古くからある仕組みですが、実装のガイドラインは現在も改訂が続いています。Google Search Centralの「ページのローカライズ版」ドキュメントは2025年12月22日（UTC）に最終更新されており、多地域・多言語サイトの構成方法をまとめたドキュメントも2025年12月10日（UTC）に更新されています。

この記事では、hreflangを実装する際に最も間違えられやすい4点を、公式ドキュメントの記述に沿って確認します。

公式ドキュメントの説明そのもの

公式ドキュメントは、hreflangの目的を次のように説明しています。

"If you have multiple versions of a page for different languages or regions, tell Google about these different variations. Doing so helps Google Search point users to the most appropriate version of your page by language or region."

（訳: 言語や地域ごとに複数バージョンのページを持っている場合は、それらのバリエーションをGoogleに伝えてください。そうすることで、Google検索がユーザーを言語や地域に応じた最も適切なバージョンのページへ案内しやすくなります。）

ここで重要なのは、hreflangが「入れておけば自動的に効く」タグではないという点です。公式ドキュメントの「よくある間違い」セクションには、条件を満たさない場合にアノテーションが「無視される可能性がある」という表現が繰り返し出てきます。次の章から、その条件を1つずつ確認していきます。

02 なぜ・背景 — hreflangが解決しようとしている問題

検索結果での競合と、サイト構成の関係

多言語・多地域サイトでは、同じ商品やサービスのページが、言語や地域ごとに別々のURLで存在することが珍しくありません。例えば日本語版・英語版・米国向け英語版が別URLで存在する場合、Googleにとっては見た目が非常に近い3つのページということになります。hreflangを設定しないと、Googleが独自の判断でどのURLをどの言語のユーザーに見せるかを決めることになり、日本語で検索しているユーザーに英語版のURLが表示される、といったミスマッチが起こりえます。

この問題は、サイトの構成方法を変えても解消しません。多地域サイトの構成方法として、公式ドキュメントは国別ドメイン（例: example.de）、サブドメイン（例: de.example.com）、サブディレクトリ（例: example.com/de/）の3つを挙げています。それぞれ費用やインフラの手間、ユーザーから見た地域の分かりやすさに違いはありますが、どの構成を選んでも、複数URLで似た内容を提供する以上、hreflangとcanonicalタグの併用が推奨される点は共通しています。公式ドキュメントは、同じ言語で類似した内容を複数URLで提供する場合について、次のように述べています。

"If you provide similar or duplicate content on different URLs in the same language as part of a multi-regional site (for instance, if both example.de/ and example.com/de/ show similar German language content), pick a preferred version and use the rel="canonical" element and hreflang tags to make sure that the correct language or regional URL is served to searchers."

（訳: 同じ言語の類似・重複コンテンツを、多地域サイトの一部として異なるURLで提供している場合（例えば example.de/ と example.com/de/ の両方が似たようなドイツ語コンテンツを表示している場合）、優先バージョンを1つ選び、rel="canonical"要素とhreflangタグを使って、正しい言語または地域のURLが検索ユーザーに提供されるようにしてください。）

実務でよく見られるのは、最初は1言語だけで構築したサイトに、後から別の言語バージョンを追加した際、既存ページのhead内に新しいバージョンへのhreflangを追記し忘れるケースです。新しく作ったページ側だけにタグを書いても、既存ページ側が更新されていなければ、相互参照は成立しません。

03 この記事で出てくる用語

hreflang属性の構成

hreflang属性の値は、ハイフンで区切られた1つまたは2つの値で構成されます。前半が言語コード（ISO 639-1形式、必須）、後半が地域コード（ISO 3166-1 Alpha-2形式、省略可能）です。例えば「en-GB」はイギリス向け英語、「de-CH」はスイス向けドイツ語を表します。

自己参照・相互参照・x-default

自己参照（self-referencing）とは、あるページのhreflangタグの一覧に、そのページ自身のURLも含めることです。公式ドキュメントは「各言語バージョンは、自分自身と、他のすべての言語バージョンを一覧化する必要がある」と明記しています。

相互参照（return links）とは、ページAがページBをhreflangで指しているなら、ページBもページAをhreflangで指し返している状態のことです。片方向だけのリンクは、公式の言葉を借りれば「無視される」対象になります。

具体例で確認します。日本語版（https://example.com/ja/）と英語版（https://example.com/en/）の2バージョンがある場合、日本語版のhead内には次の2行を書きます。<link rel="alternate" hreflang="ja" href="https://example.com/ja/" />（自己参照）と<link rel="alternate" hreflang="en" href="https://example.com/en/" />（相互参照）です。英語版のhead内には、URLの順番を入れ替えず、この2行をそのまま書き写します。どちらか一方のページにしか書かれていない状態が、そのまま「相互参照の欠落」になります。

04 型別 — 適用範囲・確認できないこと・実装手順

🅰 適用範囲 — この記事が関係するサイト

この記事が関係するのは、同じ内容、または近い内容のページを、2つ以上の言語・地域向けに別URLで公開しているサイトです。日本語だけの単一言語サイトで、他言語版のページを用意していない場合、hreflangを設定する必要そのものがありません。逆に、言語は日本語1つでも、日本向けページと海外の日本語話者向けページのように地域だけを分けて提供している場合は、hreflangの対象になります。

🅱 この記事が確認していないこと

この記事が確認していないことも明確にしておきます。第一に、hreflangが検索順位そのものに与える影響は、確認した公式ドキュメントの範囲では明言されていません。hreflangは「適切なユーザーに適切なURLを届ける」ための仕組みであり、順位を上げる仕組みとしては説明されていません。第二に、個別のCMSやフレームワークでの実装方法は製品ごとに異なるため、この記事では扱いません。第三に、実装後に実際の検索結果でどう表示されるかは、言語や地域、検索者の設定によって変わるため、公開後に自分のサイトで確認する必要があります。

また、hreflangタグの数が多いページで、クロール処理全体にどの程度の負荷がかかるかという点も、確認した公式ドキュメントの範囲では扱われていません。ページ数・言語数が非常に多いサイトでは、実装方法を決める際にこの点もあわせて検討する余地があります。

🅲 手順 — 実装から確認までの4段階

実装作業は、次の順番で進めます。第一に、自社が持つ言語・地域バージョンのURLを、すべて洗い出します。第二に、実装方法を1つ選びます（HTMLタグ・HTTPヘッダー・サイトマップのいずれか。詳しくは06章で比較します）。第三に、各バージョンのページに、自分自身を含む全バージョンへのhreflangタグを、正しい言語・地域コードで書きます。第四に、すべてのページが相互に参照し合っているかを、実際にページを開いて確認します。この4段階のうち、第三と第四が最も間違えられやすいところです。

書き方	状態	理由
ja	正しい	言語コードのみ。地域を問わず日本語話者全体を指す
en-GB	正しい	言語コード+地域コード。イギリス向け英語
x-default	正しい	予約語。どの言語・地域にも一致しない場合のページ
GB	誤り	地域コードのみの単独指定は無効。言語コードが必須
en-UK	誤り	「UK」は正式なISO 3166-1 Alpha-2コードではない（正しくは「GB」）
en-EU	誤り	「EU」は国・地域コードではない。Googleに無視される

05 自分のサイトで確認するチェックリスト

4つの観点に分けて確認する

ここまでの内容を、今日から手を動かせる作業に翻訳しました。観点は、自己参照の確認、相互参照の確認、コード形式の確認、実装方法の確認の4つに分かれます。チェックの状態はブラウザ内にのみ保存され、サーバーには送信されません。

• 自社サイトが持つ言語・地域バージョンのURLを、すべて書き出す
• hreflangを使っているページを1つ選び、ページのソースを開いてhreflangを検索する
• そのページ自身のURLが、hreflangの一覧に含まれているか確認する（自己参照）
• 一覧にある他の言語バージョンのURLを、それぞれ実際に開く
• 開いた各ページのhreflang一覧に、元のページのURLが含まれているか確認する（相互参照）
• 言語コードの部分が、2文字のアルファベットになっているか確認する
• 地域コードを使っている箇所が、言語コードなしの単独指定になっていないか確認する
• 地域コードの部分に「EU」「UN」「UK」のような非公式な値が使われていないか確認する
• x-defaultを使っている場合、そのページが言語選択画面かトップページになっているか確認する
• 実装方法がHTMLタグ・HTTPヘッダー・サイトマップのどれか、1つに特定する
• 同じページに複数の実装方法を重ねて使っていないか、ページのソースとレスポンスヘッダーの両方を確認する
• canonicalタグを併用している場合、hreflangが指す先とcanonicalが指す先で矛盾がないか確認する
• Search ConsoleのURL検査ツールで、対象URLの登録状況とレンダリング結果を確認する
• 今回確認した内容（確認日・対象URL・不備の有無）を記録に残す

14項目の内訳と、かかる時間の目安

最初の2項目はURLの洗い出し、3番目から5番目は自己参照と相互参照の確認、6番目から9番目は言語・地域コードの形式確認、10番目から12番目は実装方法の確認、13番目と14番目はSearch Consoleでの確認と記録です。すべてに目を通す時間の目安は言語バージョンが2〜3種類のサイトで20分程度です。言語・地域バージョンを持たないサイトでは、この確認自体が不要です。

06 実装方法を比較する — HTMLタグ・HTTPヘッダー・サイトマップ

3つの実装方法は、同時に使うものではない

どの方法を選ぶかの明確な基準は、確認した公式ドキュメントには数値として示されていません。それでも、実装のしやすさという観点では、ページ数が少ないうちはHTMLタグで書き始め、言語・地域バージョンが増えて<head>内の記述量が管理しにくくなった段階で、サイトマップへの一本化を検討する、という進め方が現実的です。

公式ドキュメントは、hreflangの実装方法としてHTMLタグ・HTTPヘッダー・サイトマップの3つを説明しています。3つとも同じ情報をGoogleに伝えるための手段であり、どれか1つを選んで使うのが基本です。複数の方法を同じページに重ねて使うと、内容が食い違ったときにどちらを信頼してよいか分からなくなるため、公式ドキュメントも方法を混在させないことを前提に説明を進めています。

方法	向いているケース	注意点
HTMLタグ (<head>内)	サイトマップを持たない場合や、レスポンスヘッダーを個別に設定できない場合	ページ数が多いと、head内の記述量が増えてページサイズが大きくなる
HTTPヘッダー	PDFなど、HTML以外のファイル形式に多言語版がある場合	HTMLタグを埋め込めないファイル形式向け。サーバー設定の変更が必要
サイトマップ (xhtml:link)	ページ数が多く、head内にタグを大量に書き込みたくない場合	1つのファイルで全URLの関係をまとめて管理できる。サイトマップの更新運用が前提になる

ページ数が少ないサイトではHTMLタグが分かりやすく、ページ数が多いサイトではサイトマップにまとめたほうが管理しやすい傾向があります。当サイトでサイトマップの作り方と運用を扱った回で触れたxhtml:link要素を使う実装は、まさにこのサイトマップ経由のhreflang実装と同じ仕組みです。

サイトマップでの実装は、通常のURL一覧に<xhtml:link rel="alternate" hreflang="..." href="..." />という要素を、対応するURLごとに追加していく形になります。1つの<url>ブロックの中に、そのURL自身を含む全バージョン分の<xhtml:link>を書く点は、HTMLタグ方式で各ページのhead内に書く内容と、実質的に同じです。

07 当サイトで確認したこと

確認結果 — hreflangは未使用

この記事を書くにあたり、当サイトの実装状況も確認しました。トップページのHTTPレスポンスを直接取得し、hreflangという文字列を検索したところ、該当箇所は0件でした。<html>タグのlang属性はjaのみが設定されており、日本語以外の言語バージョンのURLも用意していません。つまり、当サイトの場合はhreflangを設定する必要そのものがない、という結果です。

この確認方法自体は、多言語版を持つサイトでも同じように使えます。ページを取得してhreflangという文字列があるかを検索するだけで、実装の有無はすぐに分かります。ただし、「タグが存在する」ことと「正しく機能している」ことは別です。存在を確認したら、次は05章のチェックリストに沿って、自己参照・相互参照・コード形式まで確認する必要があります。

今後、日本語以外の言語バージョンを追加する場合は、04章の4段階の手順どおり、まず言語・地域バージョンのURLを洗い出し、実装方法を1つに決めてから着手することになります。単一言語のうちに確認方法だけ把握しておけば、追加時に迷う工程を減らせます。

08 このテーマの、これまで

2011年の導入から、確認手段が変わり続けている

hreflangは、2011年12月にGoogle Webmaster Central Blogで「New markup for multilingual content（訳: 多言語コンテンツ向けの新しいマークアップ）」として発表された、比較的古くからある仕組みです。導入当初から、複数言語版のURLの関係をGoogleに伝えるという目的は変わっていません。

大きく変わったのは、実装後の確認手段です。かつてSearch Consoleには「International Targeting（インターナショナルターゲティング）」という専用レポートがあり、hreflangのエラーを一覧で確認できました。しかしこのレポートは2022年9月22日に廃止され、Search Console上でhreflangのエラーだけをまとめて見る専用画面は無くなりました。現在は、個別ページのURL検査ツールで確認するか、サードパーティのクロールツールで一括確認するのが一般的な方法です。

報道によれば、このレポートには言語別のタブがあり、hreflangタグの構文エラーや、相互参照の欠落を含む不備を、サイト単位でまとめて確認できていたとされています。専用レポートが無くなった今、同じ範囲の確認を自分で担う必要がある、という点は覚えておく価値があります。

公式ドキュメント自体も更新が続いており、ページのローカライズ版に関するドキュメントは2025年12月22日（UTC）、多地域サイトの構成に関するドキュメントは2025年12月10日（UTC）に、それぞれ最終更新されています。仕組みの目的は変わらなくても、確認の手段と公式の説明は、確認するたびに最新のものを見直す必要があります。

当サイトが繰り返し確認している「書いてあることと、動いていることは別」という論点は、hreflangにもそのまま当てはまります。自社のサイトで実際に確認したところ、目次の自動生成やチェックリストの動作といった仕組みが、記述どおりに機能しているかを確かめる作業と、hreflangが相互参照込みで機能しているかを確かめる作業は、確認の型として同じ形をしています（archives/128）。

「0件だから安心」とは限らない

Search Consoleの専用レポートが廃止された今、hreflangに関する警告や不備を、Googleが自動的に一覧で見せてくれる場面は少なくなりました。エラーが表示されないことは、安心材料の1つにはなりますが、それだけで実装全体が正しいと判断するのは早計です。同じサイトを別の観点から調べ直すと違う結果が出る、という経験は、当サイトの内部リンク調査でも実際に起きています（archives/130）。相互参照の欠落は、片方のページだけを見ていては気づけません。

重複コンテンツの見つけ方は、記事にも応用できる

hreflangが解決しようとしているのは、複数URLに同じ・近い内容が存在するときの混乱です。同じ内容の記事が複数存在していないかを、タイトルの一致だけでなく別の観点からも確かめる方法を扱った回もあります（archives/129）。言語・地域が異なるだけで内容が同じページの管理と、同一言語内での重複記事の管理は、根本にある考え方が近いテーマです。当サイトのURLパラメータと重複コンテンツを扱った回も、この文脈と地続きです。

相互のリンクは、片方向だけでは終わらない

相互参照が欠けていると注釈が無視される、という仕様は、内部リンクの点検にも通じる論点です。自社ブログのリンク切れを確認して安心しかけたら、実際には別の問題が残っていた、という回もあります（archives/134）。片方向だけを見て「大丈夫そうだ」と判断せず、双方向を確認する姿勢は、hreflangの相互参照チェックにもそのまま当てはまります。

そして、1つのサイトだけで確認した結果を、それだけで結論にしないという姿勢も重要です。8言語のサイトで実際に確認した回では、想定と異なる結果が出たことも記録されています（archives/116）。多言語サイトの実装は、言語版の数だけ確認対象が増えるという前提を、忘れないようにしたいところです。

相互参照の確認は、ページ数が多いサイトほど手間がかかります。バージョンが2つなら1往復の確認で済みますが、5つのバージョンがあれば、1ページにつき4本の相互参照を確認することになります。05章のチェックリストは1ページ分の確認を想定した項目数なので、バージョン数が多いサイトでは、対象URLを絞り込んでから着手するか、確認作業自体を自動化する道具を検討したほうが現実的です。