hreflangの仕組みを図解｜多言語SEOで検索エンジンが認識する流れと設定方法

hreflangとは、同じ内容を複数の言語や地域向けに用意したページ同士の関係を検索エンジンに伝えるためのHTML属性です。検索エンジンはこの仕組みを使って、ユーザーの言語・地域シグナルに応じて最適なローカライズ版を検索結果に出し分けます。順位を上げる仕組みではなく「出し分け」の仕組みである点を理解し、正しい構文・実装方法・検証手順まで押さえることで、海外ユーザーに現地語ページが表示されない機会損失を防げます。

hreflangとは？多言語SEOで検索エンジンに関係を伝える仕組み

hreflangとは、同一コンテンツの言語・地域別バージョン同士の関係を検索エンジンに知らせるためのHTML属性です。これによって検索エンジンは、フランスのユーザーにはフランス語版、日本のユーザーには日本語版というように、最適なページを検索結果に出し分けられるようになります。Google検索センターでも、hreflangを使ってページのローカライズ版をGoogleに知らせられると明記されています。

結論：hreflangは順位を上げるタグではなく出し分けの仕組み

hreflangはSEOの評価を高めるための施策ではなく、検索エンジンがどの言語版を検索結果に表示すべきかを判断するための出し分けの仕組みです。順位向上を目的に導入すると期待外れになりやすく、正しくは「同じ内容の複数バージョンがあることを伝え、適切な相手に届ける」ための技術的な設定として位置づける必要があります。

この誤解は非常に多く見られます。hreflangを設定したのに順位が変わらないという相談の多くは、そもそも目的の理解がずれていることが原因です。まずは役割を正しく捉えることが、多言語SEOの土台になります。

hreflangがないと何が起きるか

hreflangを記載しないと、検索エンジンは各言語ページの関係を把握できず、フランスで検索したユーザーにも日本語ページが表示されてしまうといった機会損失が起こり得ます。PIGNUSの解説でも、hreflangの未設定によって他言語ページが見落とされるリスクが指摘されています。

せっかく現地語コンテンツを用意しても、検索エンジンにその存在と関係性が伝わらなければ、ユーザーの目に届く前に埋もれてしまいます。多言語展開の投資対効果を高めるうえで、hreflangは欠かせない技術要件です。

hreflangとlang属性・canonicalの役割の違い

hreflangは「言語版同士の関係」を示すのに対し、lang属性は「そのページ自体の言語」を示し、canonicalは「重複コンテンツの正規URL」を示すという、それぞれ異なる役割を持ちます。この3つを混同すると、多言語版同士にcanonicalを誤って設定してしまうといった事故につながります。

役割の違いを一目で整理すると以下のようになります。

属性/タグ	役割	設定単位	誤用時のリスク
hreflang	言語・地域版の関係を伝える	ページ単位	双方向欠如で無視される
lang属性	ページ自体の言語を示す	ページ単位	読み上げ・翻訳表示の誤動作
canonical	重複コンテンツの正規URLを示す	ページ単位	他言語版が評価対象から除外される

TechSuite株式会社の「AI検索パートナーズ」は、構造化データや意味的文脈、エンティティ認識といった検索エンジンが情報を理解する仕組みを技術的な観点から整理し、hreflangのようなアノテーションが検索エンジンとAIにどう解釈されるかまで踏み込んで施策を設計しています。多言語ページの構造を正しく整えることは、生成AIによる引用・参照の土台づくりにもつながります。

【図解】hreflangを検索エンジンが認識する流れとは？

検索エンジンは、クローラーがhreflangアノテーションを読み取り、双方向リンクを確認したうえで同一コンテンツのローカライズ版としてクラスタ化し、最後にユーザーの言語・地域シグナルに応じて出し分けるという4段階のプロセスでhreflangを処理します。この流れを理解しておくと、なぜ双方向リンクや自己参照が必須なのかが腹落ちします。

ステップ1：クローラーがアノテーションを読み取る

まず検索エンジンのクローラーが各言語版ページを巡回し、head内のlinkタグやHTTPヘッダー、XMLサイトマップに記載されたhreflangアノテーションを読み取ります。この段階ではまだページ同士の関係は確定していません。

クロールされていないページや、noindex設定のページはこの時点で対象から外れてしまいます。まずはすべての言語版が正しくクロール・インデックスされている状態を確認することが前提条件です。

ステップ2：双方向リンクを確認しクラスタ化する

次に検索エンジンは、AページからBページへのhreflangと、BページからAページへのhreflangが互いに一致しているかを確認します。双方向で参照し合っていない場合、そのタグは無視される仕組みになっています。これは第三者が無関係なページを勝手に「別バージョン」と名乗ることを防ぐための仕様です。

この双方向確認が完了したページ群だけが、同一コンテンツのローカライズ版としてひとつのクラスタにまとめられます。ここで初めて「関係性」が検索エンジン側に確定します。

ステップ3：ユーザーの言語・地域シグナルで出し分ける

クラスタ化された後、検索エンジンはユーザーのブラウザ言語設定や検索を行った地域などのシグナルを見て、そのクラスタの中から最も適したページを検索結果に表示します。どの指定言語・地域にも一致しない場合は、後述するx-defaultで指定したページが代替として使われます。

つまり、hreflangの設定が完了しても即座に順位や表示が変わるわけではなく、ユーザーごとの検索条件によって表示結果が変化する仕組みだという点が重要です。

重要：Googleは言語をhreflangで判定しない

ここで多くの人が誤解しやすいポイントがあります。Google検索センターは、Googleがページの言語を判定する際にhreflangやlang属性は使わず、独自のアルゴリズムでコンテンツ本文から言語を判定していると明言しています。hreflangはあくまで「関係性」を伝える役割であり、「言語そのもの」を判定させる仕組みではありません。

この違いを理解していないと、「hreflangにjaと書いたのに日本語と判定されない」といった誤った期待を持ってしまいます。言語判定はコンテンツの中身、出し分けの制御はhreflangという役割分担で捉える必要があります。

ステップ	処理内容	ポイント
1. クロール・読み取り	head/HTTPヘッダー/サイトマップのアノテーション取得	インデックス前提の確認が必要
2. 双方向確認・クラスタ化	相互参照が一致した組だけを関係づける	片方向は無視される
3. シグナル判定	ユーザーの言語・地域を判定	一致しない場合はx-defaultへ
4. 出し分け	検索結果に最適なローカライズ版を表示	順位ではなく表示ページの選択

TechSuite株式会社の「AI検索パートナーズ」は、自社サイトにおいてAI Share of Voiceを高水準で維持しており、支援先ではAI Overviewの引用率が改善した実績があります。検索エンジンがどのようなシグナルで情報を認識し出し分けているかという視点は、生成AIが情報をどのように参照するかという視点とも地続きであり、この理解が多言語展開でのAI検索対策にも活かされます。

hreflangの基本構文と言語コード・地域コードの書き方は？

hreflangの基本構文は「link rel=”alternate” hreflang=”言語コード-地域コード” href=”URL”」という形で、言語コードはISO 639-1、地域コードはISO 3166-1 Alpha 2の規格に従って指定します。この2つのコード体系を正しく組み合わせることが、hreflang設定の出発点になります。

基本形の読み方と各要素の意味

基本構文は次のように記述します。link rel=”alternate” hreflang=”ja” href=”https://example.com/ja/” のように、hreflang属性には言語コード、必要であれば地域コードをハイフンでつないで指定し、href属性には対象ページの完全なURLを指定します。

地域コードは省略可能で、言語だけを指定する場合は「en」のように単体で記述します。逆に、同じ言語でも国・地域向けに内容を分けている場合は「en-US」「en-GB」のように地域コードを付加します。Auncon Columnでも、地域コードは大文字、言語コードは小文字で記述するのが表記規則とされています。

言語コード（ISO 639-1）と地域コード（ISO 3166-1）の指定ルール

言語コードは必ず先頭に置き、単独の国コードだけを指定することはできません。Google検索センターの解説にある通り、たとえば「be」は地域を示すコードではなくベラルーシ語を示す言語コードであるため、地域指定の目的では使えません。

また、1つの言語に複数の文字体系がある場合はISO 15924のスクリプトコードを使い、中国語の繁体字は「zh-Hant」、簡体字は「zh-Hans」のように明示できます。国コードから自動的に文字体系を推測させることも可能で、「zh-TW」であれば繁体字として扱われます。es-419のような国連の地域グループを示す規格外コードはGoogleでは非対応とされているため注意が必要です。

よくある誤記：日本語は「jp」ではなく「ja」

上位記事でも見落とされがちな誤記として、日本語の言語コードを国コードの「jp」と書いてしまうケースが挙げられます。日本語の正しい言語コードはjpではなくjaであり、jpは国・地域コードとして使う値です。同様にイギリスの地域コードも「UK」ではなく「GB」が正式なコードです。

こうした誤記はコード自体としては存在するため、エラーとして表面化しにくいのが厄介な点です。設定後は必ずコード表と実際の記述を照らし合わせる必要があります。

対象	誤った記述例	正しい記述例	備考
日本語	jp	ja	jpは地域コード、jaが言語コード
イギリス（英語）	en-UK	en-GB	UKは他用途の予約コード
中国語（簡体）	zh-CN単独指定の誤解	zh-Hans または zh-CN	スクリプトコードで明示も可
スペイン語（中南米）	es-419	es（または国別に分割）	es-419はGoogle非対応

TechSuite株式会社の「AI検索パートナーズ」は、バクヤスAI記事代行事業で培ってきたAIによるコンテンツ制作の仕組みを、多言語展開時の想定質問分解やコンテンツ設計にも転用しています。言語コードの正確な設計と、各言語版で検索意図に沿った内容を高速かつ高品質に用意する体制を組み合わせることで、多言語SEOの実装スピードを高めることができます。

hreflangの3つの実装方法と選び方は？

hreflangを検索エンジンに伝える方法には、HTMLのhead内に記述する方法、HTTPヘッダーに記述する方法、XMLサイトマップに記述する方法の3種類があり、どれを使ってもGoogleの認識は同じです。3つを同時に使う必要はなく、むしろ管理が煩雑になるためサイトの規模やファイル種別に応じて1つを選ぶのが基本です。

方法1：HTMLのheadに記述する

最も一般的な方法は、各ページのhead内にlinkタグを並べる方式です。日本語ページのhead内には次のように、自分自身を含めた全言語版へのlinkタグを列記します。link rel=”alternate” hreflang=”ja” href=”https://example.com/ja/” 、link rel=”alternate” hreflang=”en” href=”https://example.com/en/” 、link rel=”alternate” hreflang=”x-default” href=”https://example.com/” という形です。

この方式は小〜中規模サイトであれば管理しやすい一方、対応言語が増えるほどheadタグが肥大化し、JavaScriptで動的にlinkタグを生成している場合は検索エンジンに認識されないリスクがあるとAuncon Columnでも指摘されています。

方法2：HTTPヘッダーに記述する

PDFなどHTMLのhead要素を持たないファイルの場合は、HTTPヘッダーにLinkヘッダーとして記述します。Link: https://example.com/en/document.pdf; rel=”alternate”; hreflang=”en” のように、レスポンスヘッダーの中に代替バージョンの情報を含めます。

この方式はサーバー側の設定変更が必要になるため、CMSの管理画面だけで完結させたい場合には扱いにくい一方、非HTMLファイルの多言語対応には欠かせない手段です。

方法3：XMLサイトマップに記述する

大規模サイトでは、各ページのheadを肥大化させずにhreflangを一括管理できるXMLサイトマップ方式が推奨されます。sitemap.xml内のurlタグの中に、xhtml:link rel=”alternate” hreflang=”ja” href=”https://example.com/ja/” のようなタグを、対象言語の数だけ列記します。

Digital Dropでも、サイト規模が大きいほどサイトマップ方式が推奨される旨が解説されています。ページ数が数百〜数千にわたるサイトでは、この方式がコード全体の保守性を大きく左右します。

どれを選ぶ？サイト規模・CMSでの判断フロー

実装方法の選択は、ページ数・CMSの自由度・ファイル種別という3つの軸で判断すると迷いにくくなります。以下のチェックリストを目安に、自社サイトに合う方式を検討してください。

方式	記述場所	メリット	向いているサイト
HTML head	各ページのhead内	実装が直感的でわかりやすい	小〜中規模サイト
HTTPヘッダー	サーバーレスポンス	非HTMLファイルに対応できる	PDFなどを多言語展開するサイト
XMLサイトマップ	sitemap.xml	head肥大化を避け一括管理できる	大規模・多ページサイト

TechSuite株式会社の「AI検索パートナーズ」は、コンサルティングという性質上、業種・規模・CMSごとに実装方式そのものが異なる多言語サイトの構造を個別に捉え、どこにボトルネックがあるのかを特定したうえで最適な実装方式を提案し、実装後の運用まで伴走しています。テンプレート的に1つの方式を押し付けるのではなく、サイトの実情に合わせた設計を行う点が特長です。

x-defaultの役割と必ず守るべきルールは？

x-defaultは、ユーザーのブラウザ設定がどの指定言語・地域にも一致しない場合に表示する代替ページを指定する予約値です。合わせて、自己参照・双方向リンク・絶対URLの使用といった必ず守るべきルールを外すと、hreflang全体が無視されてしまう点に注意が必要です。

x-defaultとは：どの言語にも一致しないユーザーの受け皿

x-defaultは、言語選択ページや、アクセス元の地域に応じて自動でリダイレクトするトップページなど、どの指定バージョンにも当てはまらないユーザー向けの受け皿として使う値です。Google検索センターでも、一致しない言語用にx-default値を使用することが案内されています。

記述例としては、link rel=”alternate” hreflang=”x-default” href=”https://example.com/” のように、他の言語コードと並べて1行追加するだけです。多言語展開の入口として言語選択ページを用意しているサイトでは特に重要な設定になります。

自己参照：各ページに自分自身のhreflangも書く

hreflangはドメイン単位ではなくページ単位で指定するため、日本語ページのhead内にも日本語ページ自身へのhreflangを含める必要があります。PIGNUSの解説でも、自ページ分の記載漏れが頻出ミスとして挙げられています。

他言語版へのリンクだけを並べて自分自身を含め忘れるケースは非常に多く見られます。全言語版のURLをリストする際は、必ず自分自身の1行も含めた状態を確認してください。

双方向リンク：片方向だと無視される

AページからBページへのhreflangがあっても、BページからAページへの参照がなければそのタグ全体が無視される仕組みになっています。これは双方向リンクの一致を必須とする仕様であり、片方向だけの実装は設定していないのと同じ結果になります。

大規模サイトでは、ページを増やすたびにすべての言語版のhead（またはサイトマップ）を更新する必要があり、この更新漏れが最も多いエラー原因になります。

絶対URL・canonicalとの競合を避ける

href属性には必ずhttpまたはhttpsを含む完全修飾の絶対URLを指定し、相対URLやプロトコルを省略したURLは認識されません。加えて、canonicalタグは重複コンテンツの正規版を示すためのタグであり、多言語版同士に使うものではない点も重要です。Digital Dropでも、日本語ページから英語ページへcanonicalを向けると日本語ページが評価対象から外れてしまうと解説されています。

hreflangとcanonicalは併用して問題ありませんが、canonicalは必ず自分自身のURLを指すよう設定し、他言語版を指させないことが基本ルールです。

エラー	原因	影響	対処法
双方向リンク欠如	片方のページにのみhreflangを記載	タグ全体が無視される	全言語版のhead/サイトマップを相互更新
言語コード誤り	jpやUKなど国コードと言語コードの混同	正しく認識されない	ISO 639-1/3166-1に照らして修正
相対URL・プロトコル欠落	href属性の記述ミス	hreflangが無効化される	httpsを含む絶対URLに統一
canonical競合	他言語版へcanonicalを設定	対象言語版が評価対象から除外	canonicalは自己参照に統一

TechSuite株式会社の「AI検索パートナーズ」は、技術実装を担う専門人材とコンテンツ制作人材が同じチームで連携し、hreflangのような技術要件の実装確認から誤り修正、コンテンツ側の整備までを一気通貫で支援しています。実装だけでなく運用フェーズでのエラー再発防止まで見据えた体制が特長です。

設定後の検証方法と多言語SEOの土台とは？

hreflangを設定した後は、Google Search Consoleやサードパーティ製ツールを使って双方向リンクの欠如や言語コードの誤りを検出できます。加えて、URL構造やlang属性、翻訳とローカライズの違いといった多言語SEO全体の土台を理解しておくことで、hreflangの効果を最大限に引き出せます。

Google Search Console（言語と地域／URL検査）で確認

Google Search Consoleの旧「インターナショナル ターゲティング」レポートや、現在の「言語と地域」に関するレポート、URL検査ツールを使うと、Googleが実際にどのhreflangを認識しているかを確認できます。Auncon Columnでも、これらのレポートで双方向リンク欠如や不正URLを検出できることが紹介されています。

設定直後は反映まで一定の時間がかかるため、数日〜数週間の間隔をあけて再確認するのが実務的な進め方です。

サードパーティツールでの検証

Google公式でも紹介されているツールとして、Aleyda Solisのhreflangタグ生成ツールや、Merkle（technicalseo.com）のhreflangテストツールがあります。Google検索センターでもこれらのツールがデバッグ用途で紹介されています。加えてScreaming Frog SEO Spiderを使えば、サイト全体をクロールして双方向リンクの欠如や不正URLをまとめて検出できます。

複数のツールを併用することで、単一ツールでは見落としがちなエラーパターンも洗い出しやすくなります。

ツール	提供元	できること
Search Console（言語と地域／URL検査）	Google	実際に認識されているhreflangの確認
hreflangタグ生成ツール	Aleyda Solis	コード生成・記述ミスの防止
hreflangテストツール	Merkle（technicalseo.com）	双方向リンク・エラーの検出
Screaming Frog SEO Spider	Screaming Frog	サイト全体のクロール検証

URL構造・lang属性など多言語SEOの土台

hreflangは多言語SEOの一部にすぎず、ccTLD・サブドメイン・サブディレクトリといったURL構造の選択や、BCP 47に準拠したlang属性の設定と組み合わせて初めて効果を発揮します。Digital Dropによると、地域ターゲティングの強さを重視するならccTLD、SEO評価の集約とコスト効率を重視するならサブディレクトリが有利とされ、多くのB2B SaaSがサブディレクトリを採用しています。

さらに、単なる翻訳とローカライズは異なるものであり、CSA Researchの調査（29カ国8,709人対象の「Can’t Read, Won’t Buy」）では、消費者が母国語のコンテンツを選ぶ傾向が示されています。生成AIによる検索が広がる中でも、現地語で一次情報として整えられたコンテンツが選ばれやすいという構造は変わらないと考えられます。多言語対応とAI検索対応の関係については、LLMOとは何かやAI検索対策の進め方も参考になります。

TechSuite株式会社の「AI検索パートナーズ」の支援では、AI検索経由での受注率が従来のSEO経由の約3倍という実績があります。多言語対応においても、露出や順位だけでなく実際の受注につながる出し分け設計を重視しており、hreflangの検証から多言語コンテンツの磨き込みまでを成果指標で捉えて支援しています。

よくある質問

hreflangは検索順位に直接影響しますか？

直接的な順位向上要因ではありません。hreflangはユーザーの言語・地域に応じて適切なページを出し分けるための仕組みであり、順位そのものを上げる施策ではないと理解しておく必要があります。

1ページに何言語まで指定できますか？

指定できる言語数に明確な上限は示されていませんが、対応言語が多いほどHTML headへの記述量が増えるため、大規模サイトではXMLサイトマップ方式による一括管理が推奨されます。

hreflangは必ず設定すべきですか？

1つのページに対して1言語のみを提供している場合は必須ではありませんが、同一内容を複数言語・地域向けに展開しているサイトでは、機会損失を防ぐために設定が強く推奨されます。

設定後どれくらいで反映されますか？

反映までの期間は明確に定められていませんが、クロールとインデックスの再処理を経て段階的に反映されるため、設定後は数日から数週間の期間を空けてSearch Consoleで確認することが実務的な進め方です。

まとめ

hreflangは、検索エンジンに言語・地域版ページの関係を伝え、ユーザーに最適なローカライズ版を出し分けるための仕組みです。クロール、双方向確認、シグナル判定、出し分けという流れを理解し、言語コード・地域コード・x-defaultを正確に記述することが第一歩になります。

実装方法はHTML head・HTTPヘッダー・XMLサイトマップの3種類から、サイト規模やファイル種別に応じて選び、自己参照と双方向リンクを必ず守ることでエラーを防げます。設定後はSearch Consoleやサードパーティツールで検証し、URL構造やlang属性と合わせた多言語SEOの土台まで整えることが、海外ユーザーに正しいページを届ける近道です。

参考にした情報源

• ページのローカライズ版についてGoogleに知らせる（Google検索センター）
• hreflangタグの正しい設定方法（Auncon Column）
• 多言語SEOの本質と実装要件（Digital Drop）
• hreflangとは？記載方法と設定方法（PIGNUS）