多言語ページの言語・地域指定を確認｜相互参照・正規URLをチェック

多言語サイトのURL一覧を確認しながらhreflangをURLクラスタ単位で監査している様子

多言語サイトでhreflang（ページの言語・地域別バージョンをGoogleに伝える指定）を設定していても、日本の検索結果に英語ページが表示されたり、米国向けと英国向けのURLが入れ替わったりすることがあります。こうしたときは、タグが入っているかどうかだけでなく、URL同士の関係も確認する必要があります。

hreflang監査で重要なのは、タグが「あるか」だけを見るのではなく、同じコンテンツに対応する言語・地域別URLを1つのまとまり（この記事では「URLクラスタ」と呼びます）として確認することです。具体的には、対象URL、HTTPステータス、自己参照、相互参照、言語・地域コード、canonical、noindexを順番に照合します。

自己参照は各URLが自分自身を指定していること、相互参照は対応するURL同士が互いを指定していることです。

この記事では、多言語・多地域サイトを担当するマーケティング担当者が、自社サイトのhreflangエラーをURLクラスタ単位で発見し、修正の優先順位まで決められるように、監査の方法を順を追って解説します。

関連する全体像や前提は「テクニカルSEOとは？クロールからセキュリティまで、企業担当者が押さえるべき7領域の実務チェックリスト」で整理しています。

hreflang監査では、タグ1本ではなくURLクラスタ全体を確認する

hreflangは、同じ内容の言語・地域別ページ同士の関係をGoogleへ伝えるための指定です。そのため、各URLを単独で見るのではなく、対応する言語・地域のURLをまとめて確認します。

日本語・米国英語・英国英語の3URLを相互参照するhreflang URLクラスタの概念図

指定の方法として、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	なし	なし	なし

表の列が1つのURL、行が確認項目です。1つの行の中でURL同士を見比べ、意図しない食い違いがないかを確認します。ただし、言語・地域コードの行は、URLごとに違う値が正しい形なので、各URLの言語・地域に合ったコードになっているかを見ます。意図しない食い違いが見つかれば、そのクラスタは修正の対象になります。1URLだけを見て「hreflangタグが入っているから問題なし」と判断しないことが、監査の出発点です。

hreflang監査で最初に確認する7項目と、その順番

実務では、次の7項目を上から順番に確認すると、エラーを切り分けやすくなります。

優先	監査項目	確認する内容
1	対象URL	本当に同じ内容の言語・地域版か
2	HTTP状態	200で直接アクセスできるか
3	自己参照	各URLが自分自身を指定しているか
4	相互参照	A→BだけでなくB→Aも存在するか
5	コード	言語・地域コードが正しいか
6	canonical	hreflangと矛盾していないか
7	indexability	noindexなどで検索対象外になっていないか

hreflang監査で対象URLからindexabilityまで順番に確認する7STEPフロー

表の「HTTP状態」は各URLが返すHTTPステータス、「コード」は言語・地域コード、「indexability」は検索の対象になれる状態を指します。

この順番にする理由は、URLそのものの状態を先に確認し、その後にhreflang・canonical・indexabilityの整合性を確認すると、原因を切り分けやすいからです。後半のタグ構造だけを修正しても、リンク先URLがリダイレクトやnoindexになっていれば、検索結果に適切な地域版を出すという目的を達成できません。

次の節からは、この7項目を作業のまとまりごとに整理し、最後にx-defaultの確認を加えたSTEP1〜7で進めます。表の番号は確認の優先順位の目安で、STEPは作業のまとまりごとの手順です。たとえば表で2番目のHTTPステータスは、STEP1の対応表に項目として入れておき、STEP4でリンク先まで含めて取得します。

STEP1：言語・地域別URLの対応表を作る

最初に、多言語サイト内のURLをページ単位ではなく「対応関係」で整理します。

たとえば商品Aについて、日本語、英語、ドイツ語が存在するなら、3URLを1行または1グループにまとめます。

重要なのは、URL構造だけで機械的に対応付けないことです。/ja/service-a/と/en/service-a/というURLがあっても、内容や目的が異なれば同じクラスタに含めるべきとは限りません。Googleも、hreflangをローカライズされた「ページの別バージョン」を知らせる仕組みとして説明しています。

そのため、URL一覧には次の項目を持たせると監査しやすくなります（x-defaultはSTEP7で説明します）。

クラスタ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を使う場合の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が存在しない場合には最も近い代替言語を指定するよう案内しています。

たとえば、次の設定は注意が必要です。

英語版のURL：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は、特に言語選択ページなどへの利用を推奨しています。

たとえば、サイトに次のページがあるとします。

日本語
米国英語
ドイツ語
グローバル言語選択ページ

この場合、言語選択ページをx-defaultとして指定する設計が考えられます。

ただし、x-defaultの有無だけを合否基準にするのではなく、「一致しないユーザーをどのURLへ案内するか」というサイト設計から判断します。

hreflang監査のエラーは影響度で優先順位を付ける

大規模サイトでは、エラーを発見した順に直すのではなく、検索結果に表示させたいURLへ直接影響するものから修正します。次の表は、その判断の目安です。

優先度	エラー例	理由
高	404・5xxを参照	対象URLそのものを利用できない
高	noindex URLを参照	検索結果へ表示させる目的と矛盾する
高	canonicalが別言語URL	正規URLのシグナルと競合する
高	相互参照欠落	言語版同士の関係が成立しにくい
中	自己参照欠落	クラスタの完全性を損なう
中	無効な言語・地域コード	対象地域を正しく伝えられない
中	リダイレクトURLを参照	最終URLとの整合性が崩れる
低〜中	x-default設計不足	対象外言語のユーザー体験に影響

「高」に並ぶのは、リンク先が使えない、検索対象から外れる、canonicalと競合する、相互参照が欠けるといった、検索結果への表示に直接響くものです。

hreflang監査で発見したエラーを検索表示への影響度で高・中・低に分類した優先順位図

重要ページ、売上につながる商品ページ、主要な国・言語から優先して直すと、担当者が修正範囲を管理しやすくなります。

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クラスタ単位でまとめる

1〜3でデータを集め、4〜9でエラーを抽出・照合し、10でまとめる流れです。特に最後の「クラスタ単位でまとめる」工程が重要です。同じテンプレートから100ページに同じエラーが発生している場合、100件の個別修正ではなく、CMSテンプレート1か所の修正で解消できる可能性があるからです。

修正後はGoogle Search Consoleで重要URLを確認する

クローラー上でエラーが消えた後も、重要URLはGoogle Search ConsoleのURL検査で確認します。URL検査では、そのURLがインデックス可能か、ユーザーが指定したcanonicalとGoogleが選択したcanonicalが何かなどを確認できます。

特に次のページを優先します。

各国のトップページ
主要サービスページ
売上の大きい商品ページ
地域別ページで順位が入れ替わっていたURL
canonical修正を行ったURL
新しく追加した言語版

Googleはcanonicalをサイト側の指定だけで機械的に決定するわけではなく、複数のシグナルから代表URLを選択します。そのため、Googleが選択したcanonicalが想定外の場合は、hreflangだけでなく、canonical、リダイレクト、サイトマップ、内部リンク、ページ内容まで戻って確認します。

公開前・移行時に使える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同士の関係が崩れていれば、意図どおりに処理されない可能性があります。

多言語・多地域サイトでは、同じページの言語・地域別URLを1つのクラスタとしてまとめ、対象URL、HTTPステータス、自己参照、相互参照、言語・地域コード、canonical、noindexを順番に確認してください。

修正の優先度が高いのは、検索結果へ表示できないURL、canonicalとの競合、相互参照の欠落です。大規模サイトではクローラーでエラーを抽出し、個別URLではなくテンプレートやURLクラスタ単位で原因をまとめると、修正範囲を効率よく絞り込めます。

修正後はGoogle Search ConsoleのURL検査も使い、重要な言語・地域別ページについて、インデックス状態とGoogleが選択したcanonicalまで確認するとよいでしょう。

最初の一歩としては、主要な国・言語の重要ページから、STEP1の対応表を作ることをおすすめします。対応表ができれば、自己参照と相互参照が成立しているかを、クラスタ単位で確認できます。

参考文献・データ元

この記事で参照した情報を確認できます。

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領域の実務チェックリスト

多言語ページの言語・地域指定を確認｜相互参照・正規URLをチェック

hreflang監査では、タグ1本ではなくURLクラスタ全体を確認する

hreflang監査で最初に確認する7項目と、その順番

STEP1：言語・地域別URLの対応表を作る