hreflang（エイチレフラング）とは、Webページが「どの言語で・どの地域向けに書かれているか」を検索エンジンに伝えるためのlink要素の属性です。多言語・多地域サイトで正しいバージョンを適切なユーザーへ届けるための多言語SEOの基盤であり、書き方には言語コードや相互リンクなどの明確なルールがあります。この記事では、hreflangの定義と役割、コピペで使える書き方、3つの実装方法、確認方法、よくある間違いまでを一気通貫で解説します。単一言語の国内サイトでは基本的に不要である点も含め、実装判断の勘所を整理します。
- hreflangの意味と多言語SEOでの役割
- 正しい書き方と3つの実装方法の選び方
- 確認手順とよくあるエラーの回避法
hreflangは言語と地域を検索エンジンに明示する属性で、多言語サイトで意図した版を表示させる役割を担います。実装はHTMLタグ・HTTPヘッダー・XMLサイトマップの3方式から選び、Search Consoleやチェッカーで検証します。相互リンク漏れやコード誤りが最頻出のエラーで、事前チェックで回避できます。
hreflangとは？読み方と意味を1分で理解
hreflangとは、ページのローカライズ版（言語・地域違いの別URL）を検索エンジンに知らせるための、link要素に指定する属性です。読みは「エイチレフラング」で、hreflang属性・hreflangタグとも呼ばれます。ここでは定義・役割・Google公式の位置づけを短く整理します。
hreflangの読み方と正式な位置づけは？
hreflangは「エイチレフラング」と読み、単独のタグではなく<link rel="alternate">に付与する属性です。hreflangは、あるページに対して別言語・別地域向けの代替ページが存在することを検索エンジンへ伝える印です。rel=”alternate”とセットで使い、hrefで代替URLを、hreflangで対象の言語や地域を示します。呼び方はhreflang属性・hreflangタグ・単にhreflangと揺れますが、指すものは同じです（出典）。
hreflangが検索エンジンに伝えることは？
hreflangが伝えるのは「言語」と「言語×地域」の2軸です。日本語版・英語版・アメリカ向け英語版などの対応関係を明示し、ユーザーの言語や所在地に合う版を提示させます。たとえば日本語ユーザーにはja版、アメリカのユーザーにはen-US版というように、最適なバージョンを検索結果に出し分ける手がかりになります。ローカライズ・海外SEOの文脈で頻出する仕組みです（出典）。
Google公式はhreflangをどう位置づけている？
Googleはページの言語をhreflangやHTMLのlang属性では判定せず、独自アルゴリズムで判断すると明言しています。それでもローカライズ版を明示したほうが正確に扱われるとGoogle公式が推奨しています。つまりhreflangは順位を直接上げる要素ではなく、正しい版をユーザーへ届けるための補助的なアノテーションと理解するのが適切です（出典）。
TechSuite株式会社の「AI検索パートナーズ」は、こうしたエンティティ認識や意味的文脈をGoogleや生成AIがどう解釈するかを技術的に捉え、構造化データや一次情報設計まで踏み込んで最適化を支援しています。
hreflangは順位操作ではなく、正しい言語・地域版を届けるための道しるべだと考えるとスッキリしますね。
検索エンジンはhreflangをどんな流れで処理するのか？
hreflangは順位を上げる仕組みではなく、言語版ページ同士の関係を伝えて出し分けるための仕組みです。処理の流れは次の4段階で整理できます。
- クロール・読み取り：各言語版のhead・HTTPヘッダー・XMLサイトマップからアノテーションを取得する（クロールされていないページやnoindexのページは対象外）
- 双方向確認・クラスタ化：AからBへの指定とBからAへの指定が一致したページ群だけを、同じコンテンツの言語版としてまとめる。片方向の指定は無視される
- シグナル判定：ユーザーのブラウザ言語設定や検索地域に合う版を選ぶ。どれにも一致しなければx-defaultのページが使われる
- 出し分け：検索結果に最適な言語版を表示する。変わるのは順位ではなく、どのページが表示されるか
なぜ多言語SEOにhreflangが必要なのか？
hreflangが必要な理由は、意図した国・言語のユーザーに正しい版を表示させ、重複や誤表示による機会損失を防ぐためです。ただし単一言語サイトでは基本的に不要で、適用範囲を見極めることが第一歩になります。
意図した国や言語で表示させる仕組みとは？
hreflangを正しく設定すると、検索エンジンはユーザーの言語設定や所在地に合う版を選んで表示します。同一内容の別言語ページ群を「同じコンテンツの言語違い」として関連づけ、最適な1版を提示できます。これにより、英語ユーザーに日本語ページが出るといったミスマッチを減らせます。多言語SEOやローカライズ運用では中核となる仕組みです。
設定しないとどんな問題が起こる？
hreflang未設定でも表示自体は可能ですが、意図しない国や言語の版がインデックスされやすくなります。似た内容の多言語ページが重複と見なされ、狙った地域で本来の版が表示されにくくなることがあります。結果として直帰の増加やコンバージョン機会の損失につながります。地域ごとの成果を伸ばしたい多地域サイトほど、設定の有無が影響しやすくなります。
hreflangが不要なケースはある？
日本語のみで運営する単一言語サイトでは、hreflangは基本的に不要です。言語や地域の代替版が存在しない場合、指定すべき対応関係がないため設定意義がありません。必要になるのは、複数言語や複数地域の版を持つサイトに限られます。まずは自サイトが多言語・多地域構成かを確認し、該当する場合のみ実装を検討するのが効率的です（出典）。
TechSuite株式会社の「AI検索パートナーズ」は、露出や順位だけでなく受注という成果に直結させることを重視しています。自社でも対策を重ね、ChatGPTでの言及シェアは0.0%から20.0%、引用シェアは3.7%から35.3%に伸びました（調査対象44クエリ・比較19社中の構成比、2026年8月27日時点、自社調べ）。生成AI時代の集客設計はAI検索対策の進め方とあわせて整理すると理解が深まります。
単一言語なら不要、多言語なら重要という線引きを最初に押さえておきましょう。
AI検索パートナーズでは、
AIに”選ばれる”ための戦略設計から実行まで支援！
ChatGPTやPerplexityはhreflangを参照するのか？
PerplexityやGeminiなどのAI検索は、hreflangのように特定言語のURLへ振り分けるのではなく、複数言語のコンテンツを横断して回答を組み立てる挙動をとるとされています（NeuronWriter）。OnCrawlは、AI検索がhreflangや検索言語を必ずしも尊重せず、どの言語版も読んだうえで回答をユーザーの言語に訳し直すことがあると説明しています（OnCrawl）。
一方、GSQiのGlenn Gabe氏の検証では、GoogleやBingの技術を使うAI Overviews・AI Mode・Copilotは、長年の多言語対応の蓄積により精度が高いと報告されています（GSQi）。従来のGoogle検索ではhreflangの正しい実装が前提で、AI検索向けには翻訳の質と本文の構造化を並行して整える、という分担になります。
hreflangのメリットとデメリットは？
hreflangは多言語・多地域サイトでは導入価値が高い一方、設定と運用の負担があります。順位を直接上げる施策ではない点は共通の前提です。
| メリット | デメリット |
|---|---|
| ユーザー体験：自分に合う言語版へ誘導され、離脱が減る | 専門知識：言語・地域コードのルールを正確に理解する必要がある |
| 重複の回避：言語ごとに独立したページと認識される | headの肥大化：言語版が増えるほど記述が増え、手作業ではミスが起きやすい |
| 地域の出し分け：en-US／en-GBのように同一言語でも出し分けできる | 相互リンクの欠如：双方向が成立しないとタグが無視される |
JavaScriptで動的に生成すると検索エンジンが認識できないリスクがあるため、サーバー側で出力します。
自社サイトに導入すべきか？判断チェックリスト
| チェック項目 | 該当する場合 |
|---|---|
| 2言語以上でページを公開している | 導入価値が高い |
| 同一言語で地域差のあるページがある（en-US／en-GBなど） | 導入価値が高い |
| 翻訳がほぼ完成している | 導入価値が高い |
| 継続的に更新・メンテナンスできる体制がある | 導入価値が高い |
| CMSや自動化でhreflangを生成できる | 実装コストを抑えやすい |
| 日本語のみで運営している | 基本的に不要 |
翻訳が一部のページだけの場合や、更新体制が整っていない場合は、導入より先に翻訳の完成度や運用体制を整えるほうが優先です。
hreflangの書き方と正しい記述ルールは？
hreflangの書き方は、言語コードと地域コードの正しい組み合わせ、x-defaultの指定、自ページを含む全版の相互記載という基本ルールで成り立ちます。ここではコピペで使えるコード例まで示します。
言語コードと地域コードはどう書く？
言語コードはISO 639-1、地域（国）コードはISO 3166-1 alpha-2の2文字を使います。書式はhreflang=”言語”またはhreflang=”言語-地域”で、区切りはアンダースコアではなくダッシュを用います。例としてja、en-US、fr-CA、zh-CNなどが有効です。地域コードのみの単独指定は無効で、地域は必ず言語とセットで指定します（出典）。主な例を下表にまとめます。
| 記述例 | 意味 | 用途 |
|---|---|---|
| ja | 日本語（地域指定なし） | 言語だけで十分な場合 |
| en-US | 英語・アメリカ向け | 地域を分けたい場合 |
| en-GB | 英語・イギリス向け | en-UKは誤り |
| x-default | いずれにも一致しない場合 | 言語選択・自動振り分け先 |
hreflangの種類は？言語・地域・文字体系・x-defaultの違い
hreflangの値は「言語のみ」「言語＋地域」「言語＋文字体系」「x-default」の4系統に分けられ、地域によって内容がどこまで変わるかで使い分けます。
| 種類 | 指定例 | 準拠規格 | 使う場面 |
|---|---|---|---|
| 言語のみ | en, de, ja | ISO 639-1 | 地域が違っても内容が変わらない |
| 言語＋地域 | en-US, en-GB, zh-CN | ISO 639-1＋ISO 3166-1 Alpha 2 | 通貨・表現・法規制などが地域で異なる |
| 言語＋文字体系 | zh-Hant, zh-Hans | ISO 639-1＋ISO 15924 | 同じ言語で繁体字・簡体字が分かれる |
| x-default | x-default | 予約値 | どの言語・地域にも一致しないユーザー向け |
中国語は、zh-TWと書けば地域から繁体字と解釈されますが、zh-Hant（繁体字）・zh-Hans（簡体字）なら地域を問わず明示でき、zh-Hans-USのように地域も併記できます。
国コードだけを書くのはなぜNGか？jpやUKは何が誤りか？
hreflangの最初のコードは必ず言語を表すため、Googleは国コードから言語を判断しません。ベルギー向けのつもりで「be」と書くと、ベラルーシ語と解釈されます。よくある誤記は次のとおりです。
| 誤った記述 | 何が起きるか | 正しい記述 |
|---|---|---|
| be | ベラルーシ語と解釈される | fr-be／nl-be／de-be（言語コードを先頭に） |
| jp | jpは国コード。日本語の言語コードはja | ja |
| en-UK | UKは予約コードで無効 | en-GB |
| es-419 | ISO 3166-1にないコードで、Googleは非対応 | es（または国別に分ける） |
こうした誤記はエラーとして表面化しにくいため、設定後はコード表と実際の記述を照らして確認します。
x-defaultとは？役割・書き方・設置する場所は？
x-defaultは、どの言語・地域にも一致しないユーザー向けの受け皿を指定する値です。言語選択ページや自動リダイレクトの起点となるURLをx-defaultに割り当てるのが推奨されています。記述は<link rel="alternate" href="https://example.com/" hreflang="x-default" />の形です。世界中の未対応言語ユーザーに一貫した入口を用意でき、取りこぼしを減らせます（出典）。
x-defaultを下層ページに付けなくてよいのはなぜか？
x-defaultは必須ではありません。Google公式ヘルプでは言語選択ページ向けに設計された値で、その種のページで最も効果的に機能するとされています。設置の目安は次のとおりです。
- 設置する：言語・地域を自動で振り分けるトップページやリダイレクト前のページ、ユーザーが言語を選ぶ言語選択ページ
- 設置しなくてよい：下層ページ（トップから辿って訪問され、すでに言語・地域が確定していることが多いため）、特定の言語・地域だけを対象にしたキャンペーンページ
自ページを含む全版を相互に書く理由は？
hreflangは相互（双方向）リンクが必須で、各ページに自分自身を含む全版のリンク一式を記載します。ページXがYを指すなら、YもXを指していなければタグ自体が無視されます。これは他サイトによる不正な指定を防ぐための仕様です。あわせて代替URLはhttp/httpsを含む完全修飾URLで書き、相対パスやプロトコル省略は避けます。代替URLは同一ドメインである必要はありません（出典）。
コピペで使えるコード例は？
日本語版・アメリカ向け英語版・x-defaultを持つ場合、全ページ共通で以下のリンク一式を<head>に記載します。同じ内容の他言語ページにも、まったく同一のリンクセットをそのまま入れるのが正解です。
- <link rel=”alternate” hreflang=”ja” href=”https://example.com/ja/” />
- <link rel=”alternate” hreflang=”en-US” href=”https://example.com/en-us/” />
- <link rel=”alternate” hreflang=”x-default” href=”https://example.com/” />
TechSuite株式会社の「AI検索パートナーズ」は、戦略設計から技術実装、企画・制作、効果測定・改善までを一つのチームで一気通貫に伴走し、こうした記述ルールの実装を運用に落とし込む支援を行っています。
書き方の基本チェックです。
- 言語はISO 639-1、地域はISO 3166-1 alpha-2
- 区切りはダッシュ（アンダースコア不可）
- 自ページを含む全版を相互に記載
- URLは完全修飾、x-defaultを用意
相互リンクと完全修飾URLを外さなければ、書き方の失敗はぐっと減らせますよ。
AI検索パートナーズでは、AIに”選ばれる”ための戦略設計から実行まで一気通貫で支援！
AI検索パートナーズでは、AI検索の専門知識と支援実績を持つ専任コンサルタントが、AIに“引用される・選ばれる”ための戦略設計からコンテンツ最適化、効果測定・改善まで一気通貫でご支援いたします。
ご興味のある方は、ぜひ資料をダウンロードして詳細をご確認ください。
hreflangの実装方法3つと選び方は？
hreflangの実装方法は、HTMLタグ・HTTPヘッダー・XMLサイトマップの3つです。サイト規模やページ種別によって最適な方式が変わるため、それぞれの特性を理解して選ぶのが近道です。
HTMLタグで実装する方法は？
最も基本的なのが<head>内にlink要素を書く方法です。サイトマップやHTTPヘッダーを使えない環境でも導入でき、小〜中規模サイトに適しています。構文は<link rel="alternate" hreflang="言語コード" href="ページURL" />を全版分並べる形です。ただしページ数や言語数が増えるとheadが肥大化し、ページ表示や管理負荷に影響しやすい点には注意します（出典）。
HTTPヘッダーで実装する方法は？
HTTPレスポンスヘッダーでの指定は、HTML以外のファイルに有効な方法です。PDFなどheadタグを持たないファイルの言語・地域版を伝えたい場合に役立ちます。サーバー設定でLinkヘッダーとして代替版を返す方式で、ドキュメント配布サイトなどで採用されます。設定にはサーバー側の知識が必要になるため、エンジニアと連携して実装するのが一般的です（出典）。
XMLサイトマップやCMSで実装するには？
XMLサイトマップにhreflangを記載する方式は、大規模サイトや集中管理に向いています。HTMLを触らずサイトマップ側で対応関係を一元管理でき、多数のページと言語を効率的に扱えます。WordPressの場合はPolylang等のプラグインでhreflangを自動出力できます。既存の運用体制や技術スタックに合わせて選ぶとよく、CMS環境での手軽な導入手段として広く使われています（出典）。
3方式はどう選び分ける？
選び方の目安は、ページ規模とファイル種別、運用体制です。小規模はHTMLタグ、HTML以外を含むならHTTPヘッダー、大規模はXMLサイトマップが基本の指針になります。下表を参考に、自サイトの構成に合う方式を選びましょう。
| 実装方法 | 向いているケース | 注意点 |
|---|---|---|
| HTMLタグ | 小〜中規模・CMSサイト | head肥大化 |
| HTTPヘッダー | PDF等HTML以外 | サーバー設定が必要 |
| XMLサイトマップ | 大規模・集中管理 | 生成・更新の仕組み化 |
TechSuite株式会社の「AI検索パートナーズ」は、業種・規模・サイト構造に合わせてすべてを顧客ごとに個別設計するコンサルティングを提供しており、テンプレートではなく実装方式の選定から運用フローまでフルカスタムで伴走します。
規模とファイル種別で方式を選べば、無理なく運用に乗せられます。
hreflangの確認方法とよくある間違いは？
hreflangは実装後の検証が欠かせません。Search Consoleやチェッカーツールで相互リンクやコードを確認し、canonicalやlang属性との違いを押さえてエラーを防ぎます。反映までにはクロールとインデックスの時間が必要な点も期待値として理解しておきます。
確認・検証はどのツールで行う？
確認方法は主に、Search Console、無料チェッカー、Screaming Frog、目視の4つです。無料チェッカーはUser AgentをGooglebotに指定して検証すると、実際のクロール時に近い結果を確認できます。technicalseo.comのhreflang Tags Testing Toolなどが代表例で、大規模サイトはScreaming Frog SEO Spiderで一括抽出すると効率的です。最終的にソースコードの目視でも相互リンクを確認します（出典）。
canonicalやlang属性との違いは？
hreflangは言語・地域の代替版を示す属性で、canonicalやlang属性とは役割が異なります。hreflangは代替版の提示、canonicalは正規URLの統一、lang属性はページ本文の言語指定という別々の目的を持ちます。併用時はhreflangが指す先を自己参照canonical付きの正規ページにし、非正規（non-canonical）ページを指さないことが重要です。3者を混同すると設定が競合し、意図しない挙動につながります。
よくある間違いと対処は？
最頻出は相互リンク漏れ、コード誤り、地域コードのみの記載です。英国をen-UKと誤記するのは典型例で、正しくはen-GBを使います。ほかにダッシュではなくアンダースコアを使う、404や非正規ページを指す、同一ページに複数言語を設定するといった誤りも起こりがちです。エラーは対象URLとhreflang値を照合し、双方向で一致しているかを1件ずつ確認してデバッグします（出典）。
TechSuite株式会社の「AI検索パートナーズ」は、自社サイトでAI Share of Voiceが高水準にあり、支援事例でAI Overviewの引用率を改善した実績を踏まえ、多言語ページの品質と一貫性を検証まで含めて高める取り組みを行っています。技術要件の全体像はAI検索最適化の用語整理もあわせて確認すると理解が進みます。
実装前後のチェック観点です。
- 相互（双方向）リンクになっているか
- lang属性・本文言語と一致しているか
- x-defaultを設定しているか
- 404や非正規ページを指していないか
en-GBと相互リンクの確認さえ徹底すれば、代表的なエラーはほぼ防げます。
hreflangのエラーは、どのくらいのサイトで見つかっているのか？
第三者の調査では、実装サイトの6〜7割前後でエラーが見つかっています。
| 調査元 | エラー率 | 主な内容 |
|---|---|---|
| Ahrefs（374,756ドメイン） | 67% | x-default欠落56.3%、自己参照欠落18% |
| hreflang.org | 約75% | 言語コードの誤り・相互参照タグの欠落 |
| Ahrefs「2026 State of SEO」（多国籍サイト） | 72% | 重大なhreflangエラー |
調査方法や対象は異なりますが、一度設定して終わりにせず、定期的に確認する前提で運用することが大切です。公開前の自己診断は次の4点で足ります。
- すべての言語ページが相互にhreflangを参照し合っているか
- 各ページが自分自身へのhreflangを含んでいるか
- URLが絶対URLで、canonicalと一致しているか
- 言語コード・地域コードにISO規格外の値がないか
hreflangとLLMO対策の関係は？多言語サイトでAIに選ばれる設定
hreflangはLLMO対策の前提条件ではありませんが、多言語サイトでは併用が効果的と考えられています。生成AIが参照する情報の多くは検索エンジンのインデックスを経由するため、各言語版が正しく識別されていれば、AIが意図しない言語版を回答に使うリスクを抑えやすくなります。
AI検索向けに、各言語版で何を整えればよいか？
- 構造化データ：各言語ページに、その言語で書いたFAQなどの構造化データを個別に実装する（同一内容を流用しない）
- 結論ファースト：各言語版でも見出し直下に結論を置き、AIが抜き出しやすい構成にする
- メタデータ：title・meta description・OGPを、各言語の検索意図に合わせて最適化する
- 翻訳の質：機械翻訳をそのまま載せず、各言語でローカライズする
hreflangのエラーはGoogle Search Consoleで週1回、AI検索での引用状況は手動で月1〜2回ほど確認すると、問題を早く見つけられます。
よくある質問
- hreflangを設定すればSEO順位は上がりますか？
hreflang自体が順位を直接上げる要素ではありません。役割は意図した言語・地域の版を正しいユーザーに表示させることで、ミスマッチや重複を防ぎ、結果的に各地域での成果改善につながる補助的な仕組みです。
- 単一言語の国内サイトでもhreflangは必要ですか？
日本語のみの単一言語サイトでは基本的に不要です。指定すべき言語・地域の代替版が存在しないためです。必要になるのは複数言語や複数地域の版を持つ多言語サイトに限られます。
- 設定してもすぐに反映されないのはなぜですか？
hreflangはクロールとインデックスを経て評価されるため、反映には時間がかかります。実装後は無料チェッカーやSearch Consoleで記述を検証しつつ、一定期間の再クロールを待つ姿勢が現実的です。
- x-defaultは必ず設定する必要がありますか？
-
必須ではありません。ただし、どの言語・地域にも一致しないユーザーの受け皿として、言語選択ページやトップページがある場合は設定が推奨されます。下層ページでは基本的に不要です。
- 言語コードと地域コードを逆に書いてもよいですか？
-
正しく認識されません。言語コードを先頭に書き、必要な場合だけ地域コードをハイフンで続けます。地域コードを単独で、または言語コードより先に書くことはできません。
- hreflangを設定しないと、LLMO対策はできませんか？
-
hreflangはLLMOの前提条件ではありません。ただ、多言語サイトでは各言語版をAIが識別しやすくなるため、構造化データや結論ファーストの構成と併用すると効果的と考えられています。
- hreflangは今後も必要ですか？
-
多言語サイトでは引き続き必要です。AI検索はhreflangを直接は参照せず、複数言語を横断して回答を組み立てることがありますが、従来のGoogle検索では言語・地域別ページの振り分けにhreflangが使われます。hreflangを維持しつつ、翻訳の質と本文の構造化を並行して整えるのが現実的です。
- 翻訳したサイトはAI検索で引用されやすくなりますか？
-
Weglotが130万件のAI引用（Google AI OverviewsとChatGPT）を分析した調査では、翻訳されたサイトは可視化される量が327%多かったと報告されています（Weglot）。ただし同社の調査であり、hreflangの有無との因果は示されていません。
まとめ
hreflangとは、ページの言語と地域を検索エンジンに伝え、正しい版を適切なユーザーへ届けるためのlink要素の属性です。書き方はISO準拠の言語・地域コード、x-default、自ページを含む相互リンクが基本になります。
実装はHTMLタグ・HTTPヘッダー・XMLサイトマップの3方式から、規模とファイル種別に応じて選びます。実装後はSearch Consoleやチェッカーで相互リンクやコード誤りを検証し、en-GBの誤記や地域コード単独などの頻出エラーを回避しましょう。
canonicalやlang属性との役割の違いを押さえ、反映に時間がかかる点も見込めば、多言語SEOの土台を安定して整えられます。
参考にした情報源
