hreflang完全解説 多言語サイトのURL設計と正しい設定方法
目次
多言語サイトのhreflangとURL設計を、よくある落とし穴から正しいコード例、実装と検証手順、国別最適化までまとめて解説。self参照やx-default、canonicalとの整合まで押さえ、英語圏で順位が上がらない原因を取り除きます。
多言語サイトを公開したのに、英語版が米国の検索結果に出てこない、日本語版が誤って海外ユーザーに表示される、といった事態は珍しくありません。その多くは、コンテンツの質ではなくURL設計とhreflangの整合性に原因があります。hreflangは、どのページをどの言語・地域のユーザーに見せるかを検索エンジンに伝える仕組みで、URL構造やcanonicalタグと足並みが揃って初めて正しく機能します。
本記事では、hreflangとURL設計でつまずきやすい落とし穴を整理し、正しい設計原則、実装と検証の手順、国別最適化への応用までを一気通貫で解説します。海外SEOの全体像から先に押さえたい場合は英語SEO・海外SEOの完全ガイドを、JavaScriptで言語切り替えを実装している場合はHreflangタグとJavaScriptの落とし穴を回避する方法もあわせて参照してください。
よくあるhreflangの落とし穴
多言語SEOで順位が伸びないとき、原因の多くはhreflangの設定不備に集約されます。検索エンジンはタグの記述をそのまま信頼するため、片方向のリンクや矛盾したコードがあると、評価が分散したり意図しない言語版が表示されたりします。ここでは現場で頻発する4種類の落とし穴を、何が起きるのかまで含めて整理します。
相互参照とx-defaultの欠落
hreflangは、すべての言語版が互いを指し合う双方向の参照が前提です。ある言語ページから他言語ページへのリンクはあるのに逆方向のリンクが欠けている片方向の状態だと、検索エンジンは関係を認識できず、設定そのものが無視されます。あわせて、各ページが自分自身を指すself参照や、どの言語にも合致しないユーザー向けのx-defaultが抜けていると、フォールバック先が定まらず誤った言語版が表示される原因になります。self参照・相互参照・x-defaultの3点セットを欠かさないことが出発点です。
canonicalとの競合
canonicalタグとhreflangが矛盾すると、検索エンジンはどのURLを正規と見なすべきか判断できなくなります。よくあるのは、英語ページが誤って日本語ページをcanonicalに指定しているケースで、これでは英語版がインデックスされません。アメリカ向けとイギリス向けのページが互いを正規URLに指定し合う相互競合も同様に評価を打ち消し合います。各言語・地域版は自分自身をcanonicalに指定し、hreflangと整合させるのが鉄則です。
言語・地域コードの誤用
hreflangの値は、ISOに沿った言語コードと地域コードでなければ機能しません。en-JPのような存在しない組み合わせや、一般的な英語を表すenと地域指定のen-GBが混在して一貫性を欠く状態は、典型的な誤用です。どの国・地域をターゲットにするかの基準が曖昧なまま地域別コードを乱発すると、管理が破綻し設定漏れを誘発します。まず言語だけで分けるのか、地域まで分けるのかを決め、コードの粒度をサイト全体で統一しましょう。
URL一貫性の欠如
URLの設計が一貫していないと、hreflangの相互参照も崩れます。パスで言語を分けず?lang=enのようなクエリパラメータで切り替える方式はクロール上不利で、SEO的に推奨されません。言語ごとに異なるIDを付与して実質的な重複ページを量産したり、末尾スラッシュの有無が混在したりすると、同一ページが複数URLとして扱われ評価が分散します。URLの形式を1つに固定し、正規化を徹底することが前提条件です。
これら4つの落とし穴は、症状の出方こそ違っても「検索エンジンに矛盾したシグナルを送っている」という一点に集約されます。下の表は、それぞれの典型症状と取るべき対処をまとめたものです。
| 落とし穴 | 典型的な症状 | 取るべき対処 |
|---|---|---|
| 相互参照・x-defaultの欠落 | 設定したhreflangが無視される | self参照・相互参照・x-defaultを全ページで揃える |
| canonicalとの競合 | 一部の言語版がインデックスされない | 各言語版のcanonicalを自分自身に向ける |
| 言語・地域コードの誤用 | 対象地域に正しく配信されない | ISO準拠のコードで粒度をサイト全体で統一する |
| URL一貫性の欠如 | 同一ページが重複扱いになる | URL形式を固定し正規化を徹底する |
URL設計とhreflangの設計原則
落とし穴の裏返しとして、守るべき設計原則は明快です。URL構造・hreflang・canonical・XMLサイトマップを矛盾なく組み合わせ、検索エンジンに一貫したシグナルを送ることに尽きます。ここでは4つの観点で、推奨される設計を具体的に示します。
URL構造の選択
多言語サイトのURLは、/en/や/ja/のように言語ごとに分けるサブディレクトリ形式が最も一般的で、運用しやすく評価も集約しやすい方式です。価格・通貨・配送・適用法令などに国ごとの明確な差がある場合は、/en-us/や/en-gb/のように言語コードへ地域コードを付加して一貫化します。ドメイン自体をccTLDやgTLD、サブドメインのどれにするかという選択は別の論点で、それぞれの利点と注意点は海外向けサイトに最適なドメインの選び方で詳しく整理しています。
hreflang設計
各ページには、self参照、関連するすべての言語・地域版への相互リンク、そしてx-defaultを設定します。値の書式やself参照の扱いはGoogleのローカライズページに関する公式ガイドが一次情報なので、迷ったらここを基準にします。正しい記述は次のような形になります。日本語版・米国英語版・英国英語版があるケースの例です。
<!-- 各ページの <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="en-GB" href="https://example.com/en-gb/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en-us/" />ポイントは、この同じブロックを全ページに記述し、各ページが自分自身も含めて相互に参照し合う状態を作ることです。ページ数が多い場合は、HTMLへの記述に加えてXMLサイトマップでの一括管理を併用すると、設定漏れや管理ミスを防げます。
言語のみで分けるか、地域まで分けるかは、hreflang値の粒度に直結します。日本企業が英語圏を狙う際によく使うコードを整理すると、次のとおりです。
| hreflang値 | 対象 | 主な用途 |
|---|---|---|
ja | 日本語ユーザー全般 | 国内向け日本語版 |
en | 英語ユーザー全般 | 地域差を設けない単一英語版 |
en-US | 米国の英語ユーザー | 米ドル・米国表記の米国向け |
en-GB | 英国の英語ユーザー | ポンド・英国表記の英国向け |
x-default | 上記に合致しないユーザー | フォールバック先（主要市場版を指定） |
canonicalの整合
各言語・地域版は、自分自身のURLをcanonicalとして指定します。hreflangで相互参照しているページ同士は、それぞれが独立した正規URLを持つ関係であり、互いをcanonicalにしてはいけません。フィルタリング結果や一時的なパラメータが付いた派生ページは、正規化したURLへcanonicalを向けるか、noindexを付与してインデックス対象から外します。
サイトマップとrobots.txt
XMLサイトマップは、言語・地域ごとに分離して作成し、インデックスさせたいページのみを収録します。サイトマップ内でxhtml:link rel="alternate" hreflang="…"属性を使えば、各言語版の対応関係をまとめて検索エンジンへ伝えられます。あわせてrobots.txtを点検し、重要な言語ページを誤ってブロックしていないかを必ず確認しましょう。
実装と検証の手順
設計が固まったら、実装と検証をセットで進めます。hreflangは記述しただけでは正しく動いているか分からないため、クロールツールとSearch Consoleで相互性と認識状況を確かめる工程が欠かせません。
実装
hreflang情報は、サイトテンプレートのヘッダー部分に<link rel="alternate" hreflang="…" />タグとして静的に埋め込むのが基本です。ページごとに手書きするのではなく、全言語版の対応表をテンプレート側で一元管理し、各ページへ自動展開する形にすると整合性を保ちやすくなります。ページ数が多いサイトでは、XMLサイトマップにxhtml:linkで対応関係を明記する方式を併用し、HTMLとサイトマップの双方からシグナルを送ると堅牢です。なお、hreflangをJavaScriptで動的生成する方法はクローラに読み取られないリスクがあり推奨されません。その理由と回避策はHreflangタグとJavaScriptの落とし穴を回避する方法で詳しく扱っています。
検証
実装後は、Screaming FrogやSitebulbなどのクロールツールで、hreflangの相互性（リンクが双方向になっているか）とcanonicalの整合性を検証します。あわせてGoogle Search Consoleでインデックス状況とカバレッジエラーを確認し、URL検査ツールで特定ページの代替言語URLが正しく認識されているかを個別にチェックします。実際にブラウザでページのソースを表示し、想定どおりのhreflangが出力されているかを目視で確かめる習慣も有効です。
検証でよく見つかる不備は、ある程度パターンが決まっています。相手ページからの戻りリンクがない「リターンタグの欠落」、ISOに存在しないコードを使った「不明な言語コード」、相対パスやドメイン違いによる「リンク先URLの不一致」の3つが代表例です。いずれもクロールツールが警告として検出できるため、公開直後と、サイト構造を変更したタイミングで定期的にクロールをかけ、警告がゼロの状態を保つことが安定運用のコツです。
国別最適化への応用
基本設計が整ったら、市場ごとの最適化に踏み込みます。同じ英語でも米国と英国では表記や通貨が異なるため、ターゲットが分かれる場合は地域別ページを用意するのが望ましい形です。ここでは地域別URLの導入基準と、HTML以外のリソースへのhreflang指定について補足します。
en/ と en-us/・en-gb/ の使い分け
地域別URLは、価格・通貨・配送オプション・適用法令などに明確な差がある場合にのみ導入します。単なる翻訳の違いしかないのに地域別ページを乱立させると、薄い重複ページが増えて管理コストだけが膨らみます。逆に、税表記や決済方法など地域固有のコンテンツ差分が実在するなら、en-USとen-GBを分けてそれぞれに最適化したほうが、現地ユーザーの信頼とコンバージョンの両方を高められます。市場の優先度を見極め、差分が小さいうちは主要市場に振り切る判断も現実的です。
HTTPヘッダでのhreflang
PDFファイルや画像など、HTML以外のリソースに対して言語・地域を指定したい場合は、HTTPレスポンスヘッダでhreflangを返す方法があります。ただしこれは限定的な用途で、通常のHTMLページではテンプレート埋め込みかXMLサイトマップでの管理のほうが堅牢で運用しやすい方式です。HTMLページにまでHTTPヘッダ方式を持ち込む必要はありません。
導入チェックリスト
ここまでの内容を、実際に着手する際の確認項目としてまとめます。新規構築でも既存サイトの改修でも、次の順序で進めると漏れを防げます。
- 英語圏向けサイトのURL構造を決める（サブディレクトリか、国別サブディレクトリか）
- テンプレートにhreflangを埋め込み、self参照・相互参照・x-defaultを揃える
- 各言語版のcanonicalが自分自身を指しているかを確認する
- 言語・地域ごとにXMLサイトマップを分離し、robots.txtのブロック設定を点検する
- 代表的な10程度のURLでhreflangの相互性をクロールツールで検証する
- Search Consoleのインデックス状況とカバレッジエラーを継続的に監視する
検証で問題がなければ、サイト全体のURLへ設定を展開し、対象市場での検索順位とインデックス状況の推移を追いながら改善を重ねていきます。
まとめ
多言語サイトのSEOは、URL構造・hreflang・canonicalタグ・XMLサイトマップの4つを矛盾なく整合させてはじめて安定します。どれか1つでも食い違うと、検索エンジンはどのページをどの市場に出すべきか判断できず、せっかくのコンテンツが評価されません。逆に言えば、この四位一体の整合性を保つことが、英語圏で順位が上がらない原因を取り除く最大の防御になります。本記事のチェックリストを起点に、自社サイトのhreflangとURL設計を一度点検してみてください。
URL設計やhreflangの再設計は、既存サイトの移行を伴うと影響範囲が大きく、自社だけで進めるのが不安なケースも少なくありません。株式会社IGNITEは大阪を拠点に、日本企業の海外進出におけるURL設計・多言語展開・hreflang運用を伴走支援しています。現状の設定がどこでつまずいているかを可視化する無料のGA4診断レポートもご用意していますので、多言語サイトのSEOを本気で立て直したい方はIGNITEの海外マーケティング支援からお気軽にご相談ください。
