hreflangには「言語のみ」「言語＋地域」「言語＋文字体系」「x-default」という4系統の種類があり、対象ページの内容が地域でどこまで変わるかによって使い分けます。言語コードはISO 639-1、地域コードはISO 3166-1 Alpha 2、文字体系コードはISO 15924という国際規格に準拠して指定するのが正しい書き方です（Google公式ヘルプ）。本記事では種類ごとの違いを一覧表で整理し、実装方法・よくある設定ミス・検証方法まで解説します。
- hreflangには4種類の指定パターンがある
言語のみ／言語＋地域／言語＋文字体系／x-defaultの4系統に分類でき、サイト構成に応じて必要な種類だけを選んで使います。
- コード指定には国際規格のルールがある
言語はISO 639-1、地域はISO 3166-1 Alpha 2、文字体系はISO 15924に準拠しないと無効になります。
- 実装方法とミス回避の型を知れば運用できる
HTMLタグ・HTTPヘッダー・サイトマップの3方式から1つを選び、相互リンクと絶対URLというルールを守れば正しく機能します。
hreflangの種類とは？まず結論
hreflangの種類は大きく「言語のみ」「言語＋地域」「言語＋文字体系」「x-default」の4系統に分類できます。どの種類を使うべきかは、地域によってコンテンツの内容がどれだけ変わるか、そして同一言語で文字体系が分かれるかどうかで判断します。
hreflangの役割を30秒で理解するには？
hreflangとは、同じ内容を異なる言語・地域向けに複数バージョン用意している場合に、検索エンジンへ「どのページがどの言語・地域向けか」を伝えるアノテーションです。これにより検索エンジンはユーザーの言語や地域に最も適したバージョンを検索結果に表示できます。
hreflangを設定しないと、複数言語のページが重複コンテンツとみなされたり、ユーザーの言語と合わないページが検索結果に表示されたりするおそれがあります。多言語・多地域サイトを運用するなら、事実上必須の技術要素だといえます。
種類の全体像を一覧表で見るとどうなる？
4種類の違いを俯瞰すると、どのケースにどの種類を使うべきかが見えてきます。まずは全体像を一覧表で整理します。
| 種類 | 指定例 | 準拠規格 | 使う場面 |
|---|---|---|---|
| 言語のみ | en, de, ja | ISO 639-1 | 地域が違っても内容が変わらない場合 |
| 言語＋地域 | en-US, en-GB, zh-CN | ISO 639-1＋ISO 3166-1 | 通貨・表現・法規制などが地域で異なる場合 |
| 言語＋文字体系 | zh-Hant, zh-Hans | ISO 639-1＋ISO 15924 | 同一言語で繁体字・簡体字が分かれる場合 |
| x-default | x-default | 予約値（規格外） | どの言語・地域にも一致しないユーザー向け |
TechSuite株式会社の「AI検索パートナーズ」は、構造化データやエンティティ認識といった生成AIが参照する仕組みを技術的に捉えた上で、hreflangのような多言語・多地域向けの技術要素も一次情報設計の一部として位置づけて支援しています。
自サイトに必要な種類の見分け方は？
自社サイトに必要な種類は、地域展開の有無と文字体系の分岐有無という2つの観点で見分けられます。判断のチェックポイントを整理します。
自サイトに必要なhreflangの種類を見分けるチェックリストです。
- 地域が違っても内容が同じなら言語のみで十分
- 価格・法規制・表現が地域で変わるなら言語＋地域を使う
- 中国語のように繁体字・簡体字がある言語は文字体系コードを検討
- 言語選択ページやトップページがあるならx-defaultも設定する
hreflangの種類は4つだけ。まずは一覧表で自サイトに必要な種類を見極めましょう。
言語コードと地域コードはどう違う？
言語コードはコンテンツの「言葉」を示し、地域コードはその言葉が使われる「地域」を示します。両者は組み合わせて使うことができますが、それぞれ準拠する規格が異なる点に注意が必要です。
ISO 639-1とは？言語のみを指定する規格
ISO 639-1とは、世界の主要言語に2文字のアルファベットコードを割り当てた国際規格です。ISO 639-1では約180種類の言語に言語コードが割り当てられており、日本語なら「ja」、英語なら「en」、ドイツ語なら「de」と指定します（leadfactory）。
ISO 639-1でカバーできない少数言語については、ISO 639-2やISO 639-3で定義された3文字のコードを使います。例えばハワイ語は「haw」、チベット語は「bod」といった具合です。地域展開が少なく、言語単位でコンテンツが分かれていないサイトであれば、この言語コードのみの指定で十分機能します。
ISO 3166-1 Alpha 2とは？言語＋地域を指定する規格
ISO 3166-1 Alpha 2とは、国や地域を2文字のコードで表す国際規格で、hreflangでは言語コードの後にハイフンで連結して使います。地域コードはISO 3166-1で定義される2〜3文字コードで、en-USなら米国の英語、en-GBなら英国の英語、zh-CNなら中国語（簡体）、zh-TWなら台湾の中国語（繁体）を意味します（leadfactory）。
Googleの公式ヘルプでも、hreflang値は「1つの値、または必要に応じてダッシュで区切る2つの値」で指定するとされ、言語はISO 639-1形式、地域はISO 3166-1 Alpha 2形式で指定する必要があり、この2規格に載っていないコード（例：es-419）はサポートされないと明記されています（Google公式ヘルプ）。代表的な言語×地域の組み合わせとしては、fr-FR／fr-CA、es-ES／es-MX、pt-BR／pt-PTなどが挙げられます（Linguise）。
国コードだけの指定はなぜNGなのか？
国コードを単独でhreflangに指定することは正しい書き方ではありません。最初のコードは必ず言語を示すものであり、Googleは国コードから自動で言語を判別しないためです。
典型的な誤解が「be」の例です。ベルギー向けページを指定したいつもりで「be」と書いても、beはベラルーシ語を示すコードとして解釈されます。ベルギー向けにはde-be／nl-be／fr-beのように言語コードを先頭に置いて指定する必要があります（Google公式ヘルプ）。この違いを表で整理します。
| 誤った指定 | 意味してしまう内容 | 正しい指定 | 正しい意味 |
|---|---|---|---|
| be | ベラルーシ語 | fr-be | ベルギーのフランス語 |
| be | ベラルーシ語 | nl-be | ベルギーのオランダ語 |
| uk | 予約コードで無視される | en-gb | 英国の英語 |
TechSuite株式会社の「AI検索パートナーズ」は、業種・規模・展開地域が異なる各サイトの構造やコンテンツ構成を個別に読み解き、どの言語コードとどの地域コードを組み合わせるべきかをサイトごとに設計して実行まで伴走しています。
言語コードと地域コードは別の規格。国コードだけの指定は誤解のもとなので避けましょう。
AI検索パートナーズでは、
AIに”選ばれる”ための戦略設計から実行まで支援！
文字体系コードとx-defaultはどう使い分ける？
文字体系コードは同一言語で表記体系が分かれる場合に使い、x-defaultはどの言語・地域指定にも一致しないユーザーへの受け皿として使います。両者は役割が全く異なるため、混同せずに使い分けることが重要です。
zh-Hant／zh-Hansはどう書き分ける？
1つの言語に複数の文字体系がある場合、通常は国コードから文字体系が自動的に取得されます。例えばzh-TWと指定すれば繁体字と解釈されますが、ISO 15924という文字体系の国際規格を使えば、地域に依存せず明示的に指定することも可能です（Google公式ヘルプ）。
ISO 15924ではzh-Hantが繁体字、zh-Hansが簡体字を意味します。地域まで併記することも可能で、米国向けに簡体字コンテンツを提供する場合はzh-Hans-USのように書きます。表記の対応関係を以下にまとめます。
| コード | 言語 | 文字体系 | 備考 |
|---|---|---|---|
| zh-CN | 中国語 | 簡体字（地域から推測） | 中国本土向け |
| zh-TW | 中国語 | 繁体字（地域から推測） | 台湾向け |
| zh-Hant | 中国語 | 繁体字（明示指定） | 地域を問わず繁体字 |
| zh-Hans-US | 中国語 | 簡体字（明示指定＋地域） | 米国在住の簡体字ユーザー向け |
x-defaultとは？役割と定義
x-defaultとは、ユーザーのブラウザ設定がhreflangで指定したどの言語・地域とも一致しない場合に表示されるページを指定するための予約値です。x-defaultに言語コードを指定する必要はなく、あくまで「その他」を受け止める役割を持ちます（Google公式ヘルプ）。
x-defaultはどのページでも使うことができますが、公式ヘルプでは言語選択ページ用に設計されており、その種のページで最も効果的に機能するとされています。多言語サイトのトップページや、自動で言語をリダイレクトする前のランディングページに設定するのが典型的な使い方です。
下層ページでx-defaultを避けたほうがよいのはなぜ？
下層ページでは基本的にx-defaultを設定しないことが推奨されています。下層ページは通常トップページからのリンクを経由して訪問されるため、ユーザーはすでに言語・地域を選択済みであることが多く、x-defaultの受け皿としての役割が薄いためです（leadfactory）。
x-defaultを設置すべきかどうかを判断するチェックリストを整理します。
x-defaultの設置場所を判断するためのチェックリストです。
- 言語・地域を自動選択するトップページやリダイレクト前のページがある
- ユーザーが手動で言語を選ぶ言語選択ページがある
- 下層ページには既に言語・地域が確定した状態で流入する
- 特定の言語・地域だけをターゲットにしたキャンペーンページではない
TechSuite株式会社の「AI検索パートナーズ」は、技術的な仕様理解を担うメンバーとコンテンツ制作を担うメンバーが同じチームで連携し、文字体系コードやx-defaultの設計から多言語コンテンツの企画・制作までを一気通貫で伴走しています。
文字体系は明示指定、x-defaultは受け皿。役割を分けて考えると迷いません。
AI検索パートナーズでは、AIに”選ばれる”ための戦略設計から実行まで一気通貫で支援！
AI検索パートナーズでは、AI検索の専門知識と支援実績を持つ専任コンサルタントが、AIに“引用される・選ばれる”ための戦略設計からコンテンツ最適化、効果測定・改善まで一気通貫でご支援いたします。
ご興味のある方は、ぜひ資料をダウンロードして詳細をご確認ください。
hreflangの実装方法は何種類ある？
hreflangをGoogleに伝える方法は、HTMLのタグ、HTTPレスポンスヘッダー、XMLサイトマップの3種類です。いずれの方法でも同様に認識されるため、サイトの規模やコンテンツ形式に合わせて1つを選ぶのが基本です。
HTMLタグでの実装はどう書く？
HTMLタグでの実装は、対象ページの
内にrel=”alternate” hreflang属性を持つタグを記述する方法で、最も一般的でコピペしやすい実装方法です。各言語・地域バージョンのページ全てを相互に記述します。例えば日本語版・英語版・x-default用のトップページがある場合、それぞれのページのheadに次のような3つのタグを記載します。
| 対象ページ | hreflang値 | 記述例（イメージ） |
|---|---|---|
| 日本語版 | ja | link rel=”alternate” hreflang=”ja” href=”https://example.com/ja/” |
| 英語版 | en | link rel=”alternate” hreflang=”en” href=”https://example.com/en/” |
| デフォルト | x-default | link rel=”alternate” hreflang=”x-default” href=”https://example.com/” |
HTTPヘッダーとXMLサイトマップはいつ使う？
HTTPヘッダーでの実装は、PDFや画像などHTMLの
を持たない非HTMLコンテンツに多言語版が存在する場合に用います。非HTMLコンテンツを多言語提供する場合は、HTMLのではなくサーバー応答のLinkヘッダーでhreflangを実装します（Linguise）。例えばbrochure-en.pdfとbrochure-fr.pdfのように多言語のPDF資料を配布する場合に有効です。一方、XMLサイトマップでの実装は、ページ数が非常に多い大規模サイトで、各ページのheadに個別にタグを記載する手間を省きたい場合に向いています。サイトマップ1ファイルに全ての言語・地域バージョンの対応関係をまとめて記述できるため、更新や管理を一元化しやすいという利点があります。
3つを同時実装したほうがよい？
3つの実装方法を同時に使う必要はありません。Google公式ヘルプでも、代替ページをGoogleに知らせる方法は3種類あり、どれでも同様に認識されるため、3つ同時に実装するメリットはなく、むしろ管理が困難になるだけだと説明されています（Google公式ヘルプ）。
サイトの状況に応じて1つの方法に統一することが望ましいといえます。判断基準を整理します。
実装方法を選ぶ際のチェックリストです。
- ページ数が少なく手作業で管理できるならHTMLタグ
- PDFや画像など非HTMLコンテンツがあるならHTTPヘッダー
- ページ数が非常に多く一元管理したいならXMLサイトマップ
- 3方式を同時に併用しない
TechSuite株式会社の「AI検索パートナーズ」は、自社サイトでのAI Share of Voiceが高水準にある実績を持ち、hreflangのような技術的な正確性を含めた多言語ページの設計を通じて、AI Overviewなど生成AIからの引用率改善にも取り組んでいます。
実装方法は3種類あるものの、選ぶのは1つで十分です。
よくある設定ミスとcanonicalとの違いは？
hreflangのよくある設定ミスは、相互リンクの欠落、相対URLの使用、地域コードの誤りの3つに集約されます。またcanonicalとhreflangは目的が異なるタグであり、多言語サイトでは両方を正しく併用する必要があります。
相互リンクの欠落やコードの誤りとは？
Googleが公式に挙げるよくある誤りは、相互リンクになっていないこと、言語コードが正しくないこと、地域コードが正しくないことの3つです。ページXからYへのhreflangがあってもYからXへの記述がなければ、そのアノテーションは無視される可能性があります（Google公式ヘルプ）。
また地域コードについては、EU・UN・UKといった予約コードや存在しないコードを指定すると無視されます。代表的な誤りを一覧化します。
| 誤りの種類 | 具体例 | 結果 | 回避策 |
|---|---|---|---|
| 相互リンク欠落 | XはYを指定するがYはXを指定しない | アノテーションが無視される | 全ページで相互に記述する |
| 相対URL | href=”/en/” | 正しく認識されない場合がある | 完全修飾（絶対）URLで記述する |
| 地域コード単独 | hreflang=”be” | 意図と異なる言語と解釈される | 言語コードを先頭に付ける |
| 予約コードの使用 | hreflang=”EU” “UK” | 無視される | ISO 3166-1準拠のコードに直す |
下層ページで各地域TOPを指定してしまうミスとは？
下層記事ページに対して、対応する地域の下層ページではなく各地域のトップページをhreflangで指定してしまうミスもよく見られます。これでは検索エンジンに正確な代替関係が伝わらず、意図した効果が得られません。
共通ガイドラインとして、自分自身の言語バージョンも含めてリスト化すること、代替URLは転送プロトコルを含む完全修飾（絶対）URLで指定すること、代替URLは同一ドメインでなくてもよいことが挙げられます（Google公式ヘルプ）。同一言語で地域違いの複数URLがある場合は、地域を特定できないユーザー向けに汎用URLも用意することが推奨されています。
hreflangとcanonicalはどう併用する？
hreflangとcanonicalは目的が異なり補完関係にあります。hreflangは異なる言語・地域向けの同一コンテンツの別バージョンを示すタグであり、canonicalは重複コンテンツの中で優先すべきURLを指定するタグです（leadfactory）。
多言語サイトでは、各言語・地域ページが自分自身をcanonicalとして指定しつつ、それぞれのページからhreflangで他言語・地域版へのリンクを張るのが正しい併用パターンです。TechSuite株式会社の「AI検索パートナーズ」は、AI検索経由での受注率が従来のSEO経由の約3倍という実績を持ち、露出や順位ではなく受注という成果に直結させる観点から、こうした基礎的な技術設定の正確性を重視して支援しています。
相互リンクと絶対URL、この2点を守るだけでミスの多くは防げます。
設定の検証方法とAI検索時代の注意点は？
hreflangの設定はGoogle Search Consoleや複数のサードパーティツールで検証できます。またAI検索（LLMO/GEO）が普及する現在では、生成AIに多言語・多地域ページを正しく認識させる観点からも、hreflangの正確な実装がより重要になっています。
Google Search Consoleで確認する方法は？
Google Search Consoleでは、国際ターゲティングに関するレポートやカバレッジレポートから、hreflangに関するエラーの一部を確認できます。設定後は必ずこうした公式ツールでエラーが出ていないかを確認する習慣が有効です。
Google公式ヘルプでも、hreflangエラーのデバッグにはサードパーティツールが役立つとされ、具体例としてAleyda Solisのhreflangタグ生成ツールと、Merkle（technicalseo.com）のhreflangテストツールが挙げられています（Google公式ヘルプ）。
他にどんな検証ツールがある？
検証・生成ツールとしては、Hreflang.orgのジェネレータ、Ahrefs Site Audit、Screaming Frog SEO Spider、Google Search Consoleが利用できます（Linguise）。用途に応じて組み合わせて使うことで、設定ミスの早期発見につながります。
| ツール | 主な用途 | 特徴 |
|---|---|---|
| Google Search Console | 公式のエラー確認 | 無料で自社サイトの状況を確認できる |
| Aleyda Solisのツール | hreflangタグの生成 | Google公式ヘルプでも紹介される生成ツール |
| Merkle（technicalseo.com） | hreflangのテスト | 相互リンクの整合性チェックに強い |
| Screaming Frog／Ahrefs | サイト全体のクロール診断 | 大規模サイトの一括検証に向く |
AI検索時代にhreflangが重要な理由は？
AI検索（LLMO/GEO）が普及する中でも、生成AIが参照する情報の多くは検索エンジンのインデックスを経由しています。hreflangが正しく設定されていることで、AIが多言語・多地域それぞれに適したページを正確に認識しやすくなると考えられます。
多言語サイトでAI検索への対応を検討する際は、GEO（生成エンジン最適化）とは何かという基礎から理解し、LLMOとは何かを踏まえた上で、hreflangのような技術要素と一次情報の充実を両立させることが望ましいといえます。TechSuite株式会社の「AI検索パートナーズ」は、バクヤスAI記事代行事業で培った高品質なコンテンツ制作エンジンをLLMO対策に転用しており、多言語展開時の想定質問分解や一次情報設計にもそのノウハウを活かしています。自社のAI検索対応度を確認したい場合はLLMO診断から現状を把握するのも一つの方法です。
検証ツールで定期的に確認し、AI検索時代にも通用する多言語設計にしましょう。
よくある質問
- hreflangは何種類まで設定できますか？
数の上限は決まっていません。1つのページに対して、対応する言語・地域バージョンの数だけhreflangを記述でき、そこにx-defaultを1つ加えるのが一般的な構成です。ただし種類が増えるほど相互リンクの管理が複雑になるため、サイトマップでの一元管理を検討する価値があります。
- x-defaultは必ず設定する必要がありますか？
x-defaultは必須ではありません。ただし、どの言語・地域にも一致しないユーザーへの受け皿として、言語選択ページやトップページがある場合には設定しておくことが推奨されています。下層ページでは基本的に不要です。
- hreflangを設定しても順位が変わらないのはなぜですか？
hreflangはあくまで「どの言語・地域向けのページか」を伝えるタグであり、順位を直接上げるものではありません。相互リンクの欠落や地域コードの誤りがあると機能しないため、まずはGoogle Search Consoleやサードパーティツールで正しく認識されているかを確認することが優先です。
- 言語コードと地域コードを逆に書いても問題ありませんか？
順序を逆にすると正しく認識されません。hreflangの記述は必ず言語コードを先頭に、必要であれば地域コードをハイフンで続ける順序で書きます。地域コードを単独で、あるいは言語コードより先に書くことはできません。
まとめ
hreflangの種類は「言語のみ」「言語＋地域」「言語＋文字体系」「x-default」の4系統であり、サイトの地域展開や文字体系の分岐に応じて必要な種類だけを選ぶことが基本です。コードはISO 639-1・ISO 3166-1・ISO 15924という国際規格に準拠し、相互リンクと絶対URLというルールを守ることで無効化を防げます。
実装方法はHTMLタグ・HTTPヘッダー・XMLサイトマップの3種類があり、サイト規模やコンテンツ形式に応じて1つを選べば十分です。設定後はGoogle Search Consoleや各種検証ツールで確認し、AI検索時代にも通用する正確な多言語設計を維持していくことが求められます。
参考にした情報源
