多言語サイトでhreflangを設定していても、日本の検索結果に英語ページが表示されたり、米国向けと英国向けのURLが入れ替わったりすることがあります。
hreflang監査で重要なのは、タグが「あるか」だけを見るのではなく、同じコンテンツに対応する言語・地域別URLを1つのグループとして確認することです。
具体的には、対象URL、自己参照、相互参照、言語・地域コード、ステータスコード、canonical、noindexを順番に照合します。
この記事では、多言語・多地域サイトを担当するマーケティング担当者が、自社サイトのhreflangエラーをURL群単位で発見し、修正優先順位まで決められる監査方法を解説します。
関連する全体像や前提は「テクニカルSEOとは?クロールからセキュリティまで、企業担当者が押さえるべき」で整理しています。
hreflang監査では「タグ1本」ではなくURLクラスタ全体を確認する
hreflangは、同じ内容の言語・地域別ページ同士の関係をGoogleへ伝えるための指定です。

hreflangは各URLを単独で確認するのではなく、対応する言語・地域URLを1つのクラスタとして監査します。
Googleは、多言語ページを知らせる方法としてHTML、HTTPヘッダー、XMLサイトマップの3方式を案内しています。検索上、この3方式に優劣はなく、管理しやすい方法を選べます。複数方式を同時に使っても検索上の追加メリットはなく、かえって管理が複雑になる場合があります。
たとえば、次の3ページがあるとします。
- 日本語:`/ja/product/`
- 米国英語:`/en-us/product/`
- 英国英語:`/en-gb/product/`
この場合、3URLを別々に確認するのではなく、「同じ商品の3地域版」という1つのURLクラスタとして監査します。
Googleは各言語版について、自分自身を含むすべての対応言語版を指定するよう案内しています。また、2ページが相互に参照していない場合、そのhreflang指定は無視される可能性があります。
したがって監査表も、最低限次のような形にします。
| 確認項目 | ja | en-US | en-GB |
|---|---|---|---|
| 対象URL | あり | あり | あり |
| HTTPステータス | 200 | 200 | 200 |
| 自己参照 | ○ | ○ | ○ |
| 相互参照 | ○ | ○ | ○ |
| 言語・地域コード | ja | en-US | en-GB |
| canonical | 自己URL | 自己URL | 自己URL |
| noindex | なし | なし | なし |
1URLだけを見て「hreflangタグが入っているから問題なし」と判断しないことが、監査の出発点です。
hreflang監査で最初に確認する7項目
実務では、次の7項目を上から順番に確認すると、エラーを切り分けやすくなります。
| 優先 | 監査項目 | 確認する内容 |
|---|---|---|
| 1 | 対象URL | 本当に同じ内容の言語・地域版か |
| 2 | HTTP状態 | 200で直接アクセスできるか |
| 3 | 自己参照 | 各URLが自分自身を指定しているか |
| 4 | 相互参照 | A→BだけでなくB→Aも存在するか |
| 5 | コード | 言語・地域コードが正しいか |
| 6 | canonical | hreflangと矛盾していないか |
| 7 | indexability | noindexなどで検索対象外になっていないか |

URLそのものの状態を先に確認し、その後にhreflang・canonical・indexabilityの整合性を確認すると原因を切り分けやすくなります。
この順番にする理由は、後半のタグ構造だけを修正しても、リンク先URLそのものがリダイレクトやnoindexになっていれば、検索結果に適切な地域版を出すという目的を達成できないからです。
STEP1:言語・地域別URLの対応表を作る
最初に、多言語サイト内のURLをページ単位ではなく「対応関係」で整理します。
たとえば商品Aについて、日本語、英語、ドイツ語が存在するなら、3URLを1行または1グループにまとめます。
重要なのは、URL構造だけで機械的に対応付けないことです。
`/ja/service-a/`と`/en/service-a/`というURLがあっても、内容や目的が異なれば同じhreflangクラスタに含めるべきとは限りません。
Googleも、hreflangをローカライズされた「ページの別バージョン」を知らせる仕組みとして説明しています。
そのため、URL一覧には次の項目を持たせると監査しやすくなります。
- クラスタID
- ページ種別
- 日本語URL
- 英語URL
- 地域別URL
- 想定hreflang
- canonical
- HTTPステータス
- noindex有無
- x-default
- 修正要否
数百〜数万URLあるサイトでは、先にこの対応表を作ることで「どのページとどのページを比較すべきか」が明確になります。
STEP2:自己参照と相互参照を確認する
hreflang監査で特に重要なのが、自己参照と相互参照です。
Googleは、各言語版について自分自身と他の言語版を指定するよう案内しています。また、AページからBページへ指定している場合、Bページ側からAページへの戻りの指定がないと、その関連付けが適切に処理されない可能性があります。
たとえば次の2ページがあるとします。
- `example.com/ja/product/`
- `example.com/en/product/`
日本語ページだけに英語版への指定があり、英語ページに日本語版への指定がなければ相互参照が成立していません。
監査では次の3パターンを分けて確認します。
自己参照欠落
日本語ページに`hreflang=”ja”`として日本語ページ自身が含まれていない状態です。
Return Link欠落
日本語ページから英語ページを指定しているのに、英語ページから日本語ページが指定されていない状態です。
クラスタ欠落
日本語・英語・ドイツ語の3ページが存在するのに、一部ページだけドイツ語URLを含んでいない状態です。

hreflangでは、一方向の指定だけでなく、各言語版から対応URLへ相互に参照されているかを確認します。
大規模サイトでは目視ではなく、クローラーでURLごとのhreflangを抽出し、クラスタ単位で差分を見る方法が現実的です。
Screaming Frog SEO Spiderでも、HTML、HTTPヘッダー、XMLサイトマップに記載されたhreflangをクロールし、エラーを抽出できます。
STEP3:言語コード・地域コードを確認する
hreflangは、コードが見た目として自然でも、仕様上無効なら意図どおりに処理されません。
Googleでは、言語コードにISO 639-1、地域コードにISO 3166-1 Alpha 2を使用すると案内しています。国コードだけを指定することはできません。
たとえば、
- `ja`:日本語
- `en`:英語
- `en-US`:米国向け英語
- `en-GB`:英国向け英語
といった指定ができます。
一方、英国向けだからといって`uk`だけを指定する方法は適切ではありません。
監査では「タグが存在するか」だけでなく、コードを一覧化して許可された形式と照合します。
また、地域を限定する理由がない場合は無理に国まで細分化せず、`en`のような言語単位で設計する選択肢もあります。
STEP4:hreflangのリンク先が200を返すか確認する
hreflangのリンク先には、検索ユーザーへ実際に表示させたいURLを指定します。
そのため、監査ではリンク先URLのHTTPステータスも同時に取得します。
特に確認したいのは次の状態です。
- 301・302リダイレクト
- 404
- 5xx
- HTTP版URL
- 旧URL
- ステージングURL
たとえばhreflangが古いURLを指し、そのURLから新しいURLへ301リダイレクトしている場合、タグの指定先も最終URLへ更新する方が管理しやすくなります。
Googleのcanonicalガイドでも、サイトマップやhreflangにHTTP版ではなくHTTPS版を含めることなど、各URLシグナルの整合性が重要であることが示されています。
STEP5:canonicalとhreflangが競合していないか確認する
多言語SEOで特に注意したいのが、canonicalとhreflangの組み合わせです。
Googleは、hreflangを使用する場合、canonicalには同じ言語のページ、または同じ言語のcanonicalが存在しない場合には最も近い代替言語を指定するよう案内しています。
たとえば次の設定は注意が必要です。
英語版:
`example.com/en/product/`
canonical:
`example.com/ja/product/`
日本語版と英語版を別の言語版として検索結果に出したいにもかかわらず、英語URLが日本語URLをcanonicalとして指定すると、hreflangとは異なる方向のシグナルをGoogleへ送ることになります。
基本形としては、
- 日本語版 → 日本語版をcanonical
- 英語版 → 英語版をcanonical
- ドイツ語版 → ドイツ語版をcanonical
とし、そのうえでhreflangによって言語・地域別ページの関係を伝える設計が分かりやすくなります。
特に米国向け英語と英国向け英語など、本文が非常に似ている地域別URLではcanonicalとhreflangをセットで監査してください。Googleも、同一言語で内容が似ている地域別URLについて、canonicalとhreflangを併用する考え方を示しています。
STEP6:noindexなど検索対象外のURLをクラスタから発見する
hreflangで指定されたURLが検索結果へ出せる状態かも確認します。
Googleの`noindex`は、そのページをGoogle検索結果から除外するための指定です。Googlebotがnoindexを読み取れば、そのページは検索結果から削除されます。
したがって、
- 日本語:index可能
- 英語:noindex
- ドイツ語:index可能
というクラスタで、英語ページも検索結果へ表示させたいのであれば、設定の目的に矛盾があります。
監査ではhreflang対象URLについて、最低限次を取得します。
- meta robots
- X-Robots-Tag
- robots.txtによるクロール可否
- HTTPステータス
- canonical
- Google Search Console上のインデックス状態
なお、robots.txtでクロール自体を禁止すると、Googleがページ上のnoindexを確認できない場合があります。robots.txtとnoindexは役割が異なるため、一括して「検索除外設定」として扱わないことが重要です。
STEP7:x-defaultが必要なサイトではフォールバック先を確認する
`x-default`は、指定した言語・地域のどれにも一致しないユーザー向けのフォールバックURLを示すために使えます。
Googleは、特定言語に一致しないユーザー向けURLとして`x-default`を使用でき、特に言語選択ページなどへの利用を推奨しています。
たとえば、
- 日本語
- 米国英語
- ドイツ語
- グローバル言語選択ページ
があるなら、言語選択ページを`x-default`として指定する設計が考えられます。
ただし、x-defaultの有無だけを合否基準にするのではなく、「一致しないユーザーをどのURLへ案内するか」というサイト設計から判断します。
hreflang監査のエラーは影響度で優先順位を付ける
大規模サイトでは、エラーを発見した順に直すのではなく、検索結果に表示させたいURLへ直接影響するものから修正します。
| 優先度 | エラー例 | 理由 |
|---|---|---|
| 高 | 404・5xxを参照 | 対象URLそのものを利用できない |
| 高 | noindex URLを参照 | 検索結果へ表示させる目的と矛盾する |
| 高 | canonicalが別言語URL | 正規URLのシグナルと競合する |
| 高 | 相互参照欠落 | 言語版同士の関係が成立しにくい |
| 中 | 自己参照欠落 | クラスタの完全性を損なう |
| 中 | 無効な言語・地域コード | 対象地域を正しく伝えられない |
| 中 | リダイレクトURLを参照 | 最終URLとの整合性が崩れる |
| 低〜中 | x-default設計不足 | 対象外言語のユーザー体験に影響 |

すべてのエラーを同時に直すのではなく、検索対象から外れる問題やcanonicalとの競合など、影響の大きいものから修正します。
重要ページ、売上につながる商品ページ、主要な国・言語から優先して直すと、担当者が修正範囲を管理しやすくなります。
Screaming Frogを使う場合のhreflang監査手順
数百URL以上のサイトでは、クローラーを使って一括確認すると効率的です。
Screaming Frog SEO Spiderでは、hreflangのクロール・保存を有効にし、必要に応じてXMLサイトマップもクロールできます。HTML、HTTPヘッダー、XMLサイトマップのhreflangを取得し、問題のあるURLをレポートとして出力できます。
実務では次の順序で確認します。
- hreflangを含む全URLをクロールする
- hreflangのリンク先URLもクロールする
- XMLサイトマップ実装ならサイトマップも読み込む
- 非200 URLを抽出する
- 自己参照欠落を抽出する
- 相互参照欠落を抽出する
- 無効な言語・地域コードを抽出する
- canonicalと照合する
- noindex・robots設定を照合する
- エラーをURLクラスタ単位でまとめる
最後の「クラスタ単位でまとめる」工程が重要です。
同じテンプレートから100ページに同じエラーが発生している場合、100件の個別修正ではなくCMSテンプレート1か所の修正で解消できる可能性があります。
修正後はGoogle Search Consoleでも代表URLを確認する
クローラー上でエラーが消えた後も、重要URLはGoogle Search ConsoleのURL検査で確認します。
URL検査では、そのURLがインデックス可能か、ユーザーが指定したcanonicalとGoogleが選択したcanonicalが何かなどを確認できます。
特に次のページを優先します。
- 各国のトップページ
- 主要サービスページ
- 売上の大きい商品ページ
- 地域別ページで順位が入れ替わっていたURL
- canonical修正を行ったURL
- 新しく追加した言語版
Googleが選択したcanonicalが想定外の場合、hreflangだけでなく、canonical、リダイレクト、サイトマップ、内部リンク、ページ内容まで戻って確認します。
Googleはcanonicalをサイト側の指定だけで機械的に決定するわけではなく、複数のシグナルから代表URLを選択します。
公開前・移行時に使えるhreflang監査チェックリスト
多言語サイトの公開、新しい国への展開、CMS移行、URL変更の際は、次の項目をまとめて確認してください。
- hreflang対象URLの対応関係が正しい
- 各URLが200を返す
- 各URLが自分自身をhreflangで参照している
- 対応URL同士が相互参照している
- クラスタ内で参照URL一覧が一致している
- 言語コードが正しい
- 必要な場合の地域コードが正しい
- hreflang URLが完全修飾URLになっている
- canonicalが同じ言語・地域側の適切なURLを指している
- noindexになっていない
- 旧URLやリダイレクトURLを参照していない
- HTTPとHTTPSが混在していない
- 本番URLとステージングURLが混在していない
- 必要に応じてx-defaultを設計している
- 修正後に重要URLをGoogle Search Consoleで確認した
このチェックをURL単位ではなくクラスタ単位で行うことで、「タグは正しいがURL同士の関係が崩れている」という問題を発見しやすくなります。
まとめ
hreflangのSEO監査では、タグの有無だけを確認しても不十分です。
多言語・多地域サイトでは、同じページの言語・地域別URLを1つのクラスタとしてまとめ、対象URL、HTTPステータス、自己参照、相互参照、言語・地域コード、canonical、noindexを順番に確認してください。
特に優先したいのは、検索結果へ表示できないURL、canonicalとの競合、相互参照の欠落です。
大規模サイトではクローラーでエラーを抽出し、個別URLではなくテンプレートやURLクラスタ単位で原因をまとめると、修正範囲を効率よく絞り込めます。
修正後はGoogle Search ConsoleのURL検査も使い、重要な言語・地域別ページについて、インデックス状態とGoogleが選択したcanonicalまで確認するとよいでしょう。
参考文献・データ元
この記事で参照した情報を確認できます。
- Google Search Central「ページのローカライズ版について Google に知らせる」。hreflangの自己参照、相互参照、言語・地域コード、HTML・HTTPヘッダー・XMLサイトマップによる実装方法の確認に使用。
- Google Search Central「多地域、多言語サイトの管理」。多言語URL、地域別URL、canonicalとの併用方針の確認に使用。
- Google Search Central「How to Specify a Canonical with rel=”canonical” and Other Methods」。hreflangとcanonicalの整合性確認に使用。2026年7月時点の更新内容を確認。
- Google Search Central「What is canonicalization」。多地域URLとcanonical選択の考え方の確認に使用。最終更新2026年8月20日。
- Google Search Central「Block Search indexing with noindex」。noindexとrobots.txtの挙動確認に使用。
- Google Search Console Help「URL Inspection tool」。インデックス状態とcanonical確認方法に使用。
- Screaming Frog「How To Audit Hreflang」。サイト全体のhreflangクロール、エラー抽出、レポート作成手順の確認に使用。
‹ 親記事: テクニカルSEOとは?クロールからセキュリティまで、企業担当者が押さえるべき7領域の実務チェックリスト
関連記事
- › INDEX削除(インデックス削除)とは?検索結果から消える仕組みと対処法
- › Core Web Vitals改善ガイド|LCP・INP・CLSの原因特定と優先順位付け
- › SEO内部リンクの監査方法|孤立ページ・リンク深度・アンカー偏りをどう直すか
- › SEOのインデックス監査方法|Search Consoleで未登録・除外・重複URLを診断する
- › JavaScript SEOの監査方法|レンダリング・内部リンク・インデックス差分を確認する
- › クロールバジェットを監査する方法|ログ・URL群・無駄クロールから改善優先度を決める
- › 構造化データのSEO監査方法|実装後のエラー・内容不一致・重複を検証する手順
- › ファセットナビゲーションのSEO監査方法|絞り込みURL・クロール・重複を制御する
- › SEOのリダイレクト監査方法|チェーン・ループ・誤転送・リンク残存を検出する
- › robots.txt・meta robotsのSEO監査方法|クロール許可とindex制御の矛盾を確認
- › ページネーションのSEO監査方法|一覧分割・canonical・内部リンク・クロールを確認
- › サイト移行後のSEO監査方法|リダイレクト・canonical・サイトマップ・順位変動を確認
- › 404・soft 404のSEO監査方法|リンク切れ・消失URL・誤判定を優先度順に修正
- › SEOリリース前チェックの作り方|noindex・canonical・robots・リダイレクトの事故を防ぐ
- › 画像SEOの監査方法|alt・画像URL・遅延読み込み・画像検索を確認する
- › JobPosting構造化データの監査方法|求人情報・給与・勤務地・期限の不一致を確認
- › サイト内検索結果ページのSEO監査方法|noindex・クロール・重複URL・内部リンクを確認
- › サイトリニューアルでSEO評価を落とさない移行方法|URL・301・計測・公開手順
- › サービス終了ページは削除すべき?301・404/410・残す場合のSEO判断基準



