hreflangとは？書き方・canonical・x-default・エラー確認を完全解説【2026年】

Google検索セントラルの「ページのローカライズ版」「canonical」「ロケール適応ページ」「Search Console」の現行ドキュメントを2026年7月29日に確認し、旧情報と強すぎるSEO表現を見直しました。

hreflangは、入れただけで検索順位を直接押し上げる魔法のタグではありません。同じ内容の言語・地域別URLの関係をGoogleへ伝え、検索ユーザーに合うURLが表示されやすい状態を作る仕組みです。効果を出すには、翻訳品質、URL設計、canonical、インデックス可否、内部リンクまで一貫させる必要があります。

30秒で分かる結論

正しいhreflangは「完全な対応表」を各ページで共有する

日本語・英語・繁体字中国語の3ページがあるなら、3ページすべてに同じ3言語分のリンクを置きます。各ページは自分自身を含め、対応する全ページを完全修飾URLで参照し、相手側からも戻りの参照を設定します。

必須の考え方自己参照・相互参照・完全修飾URL・同じリンクセット

canonical各言語ページは原則として同じ言語の正規URLを指す

実装方法HTML・HTTPヘッダー・XMLサイトマップから管理しやすい1方式を選ぶ

目的	同一内容の言語・地域別URLの関係を検索エンジンへ伝える
主な対象	多言語サイト、同一言語の国別ページ、通貨・配送・商品構成が地域で異なるページ
必須要件	自己参照、相互参照、完全修飾URL、正しい言語／地域コード
実装方式	HTMLの`<link>`、HTTPの`Link`ヘッダー、XMLサイトマップ
canonical	原則として各言語ページが同じ言語内の正規URLを指す
x-default	どの指定言語にも一致しないユーザー向けのフォールバックURL
確認方法	ソース／レスポンス／サイトマップ、URL検査、200応答、index可否、canonical、戻りリンクを確認
最終確認日	2026年7月29日

hreflangとは：言語・地域別URLの関係を伝える指定

hreflangは、同じ内容を別の言語や地域向けに用意したときに、各URLの対応関係を検索エンジンへ知らせるためのアノテーションです。たとえば日本語版と英語版がある場合、両者を「別の記事」ではなく「同じページのローカライズ版」として結び付けます。

Googleは、hreflangがなくても別言語版を見つける場合があります。しかし、運営者が対応関係を明示したほうが、言語や地域に応じたURLをより正確に選びやすくなります。

使う場面

URLが言語・地域ごとに分かれている

/ja/と/en/に翻訳ページがある
en-USとen-GBで価格や配送条件が違う
国別ドメインやサブドメインをまたいで同等ページがある

不要な場面

代替URLが存在しない

日本語ページしか公開していない
同じURLで文章だけを切り替え、別URLがない
内容がまったく異なり、対応ページとは言えない

hreflangとHTMLのlang属性は役割が違う

<html lang="ja">は、文書の主要言語をブラウザや支援技術へ伝えるために重要です。一方、hreflangは別URL同士の関係を示します。Googleはページの言語判定にhreflangやHTMLのlang属性をそのまま使うのではなく、ページ内容をアルゴリズムで判断すると説明しています。

両方設定します。 HTMLのlangはアクセシビリティと文書意味論のため、hreflangはローカライズURLの対応関係のために使います。

hreflangは「直接的な順位向上策」ではない

正しい言語のURLが検索結果に出れば、ユーザーが内容を理解しやすくなり、誤言語ページへの流入や離脱を減らせる可能性があります。ただし、hreflangだけでコンテンツの品質や権威性が上がるわけではありません。検索流入やコンバージョンの改善は、ローカライズ品質、検索意図、速度、内部リンク、商品・サービスの地域適合と組み合わせて評価します。

実装前に決めるURL設計：言語ごとにクロール可能なURLを用意する

hreflangを書く前に、各ローカライズ版が固有のURLで取得できる状態を作ります。同じURLの内容をIPアドレスやAccept-Languageだけで切り替える方式では、Googlebotがすべての言語・地域版をクロールできない場合があります。

サブディレクトリ

example.com/ja/
example.com/en/

管理をまとめやすく、多くのサイトで扱いやすい構成です。

サブドメイン

ja.example.com
en.example.com

運用やインフラを分けやすい一方、計測・管理も分かれやすくなります。

国別ドメイン

example.jp
example.co.uk

地域性は明確ですが、ドメインごとの運用・評価・費用が必要です。

自動リダイレクトだけに頼らない

ユーザーの推定地域やブラウザ言語を使って案内すること自体はできますが、ユーザーとクローラーが各URLへ直接アクセスできるようにします。強制転送で別言語ページを見られなくすると、クロール、共有、言語切替、海外出張中の閲覧などで問題が起きます。

推奨：言語提案のバナーを表示し、ユーザーが選択できるようにします。選択後も言語切替リンクを残し、各URLは200で直接取得できるようにしてください。

正しいURLクラスターの例

日本語/ja/product/自己参照＋全言語への参照

English/en/product/同じ完全セットを出力

繁體中文/zh/product/戻りリンクも必須

x-default/languages/言語選択または既定ページ

ドメインが異なっても構いません。重要なのは、対応する各ページが互いを認識し、同じ意味のページ群として整合していることです。

hreflangの正しい書き方：HTMLで実装する基本形

HTMLページでは、<head>内にrel="alternate"の<link>要素を置きます。次は、日本語、英語、繁体字中国語、言語選択ページの4URLを結び付ける例です。

<link rel="canonical"
      href="https://example.com/ja/product/" />

<link rel="alternate" hreflang="ja"
      href="https://example.com/ja/product/" />
<link rel="alternate" hreflang="en"
      href="https://example.com/en/product/" />
<link rel="alternate" hreflang="zh-Hant"
      href="https://example.com/zh/product/" />
<link rel="alternate" hreflang="x-default"
      href="https://example.com/languages/product/" />

英語ページや中国語ページにも、同じ4本のhreflangを置きます。変えるのは、そのページ自身のcanonicalです。英語ページのcanonicalは英語の正規URL、中国語ページのcanonicalは中国語の正規URLを指します。

自分自身を含める

日本語ページにもhreflang="ja"で日本語ページ自身を記述します。これが自己参照です。

相手側にも戻りリンクを置く

日本語から英語を指定したら、英語から日本語も指定します。片方向だけではアノテーションが無視される可能性があります。

完全修飾URLを使う

/en/product/ではなく、https://example.com/en/product/のようにプロトコルとホストを含めます。

同じ意味のページだけを結ぶ

日本語の商品Aと英語の商品一覧のような不一致は避け、検索意図と主要内容が対応するURLを組み合わせます。

言語・地域コードの選び方

先頭はISO 639-1の言語コード、必要な場合だけハイフンの後ろにISO 3166-1 Alpha 2の地域コードを置きます。地域コードだけの指定はできません。

目的	推奨例	避ける例	理由
日本語全般	`ja`	`jp`	最初は言語コード。国コード単独は無効
日本向け日本語	`ja-JP`	`ja_JP`	区切りはアンダースコアではなくハイフン
英国向け英語	`en-GB`	`en-UK`	Googleは地域コードとしてUKを使用しない
繁体字中国語	`zh-Hant`	`zh-traditional`	文字体系はISO 15924のコードを使う
簡体字中国語	`zh-Hans`	`cn`	cnは国であり、言語ではない
汎用英語	`en`	`en-WORLD`	地域を限定しないなら言語だけでよい

`ja`と`ja-JP`はどちらを使うべきか

世界中の日本語話者に同じページを提供するならjaで十分です。日本の価格、配送、法制度、店舗情報など、明確に日本地域を対象とする場合はja-JPを検討します。細かく分けるほど良いわけではなく、実際に内容や提供条件が違うときだけ地域を追加します。

大文字・小文字は一般に正規化されますが、読みやすさと規格に合わせてja-JP、en-GBのように「言語は小文字、地域は大文字」で統一すると管理しやすくなります。

3つの実装方法：HTML・HTTPヘッダー・XMLサイトマップ

Googleがサポートする方法は3つです。認識上の優劣はないため、サイト構成と運用体制に合う方法を選びます。複数方式を同時に使っても検索上の追加メリットはなく、内容が食い違うリスクが増えます。

方式	向くケース	長所	注意点
HTML	小〜中規模のHTMLサイト	ソースで確認しやすく、ページ単位で理解しやすい	言語数が多いとheadが長くなり、テンプレート管理が必要
HTTPヘッダー	PDFなどHTMLではないファイル	文書本体を変更せず設定できる	サーバー／CDN設定の確認が必要で、ブラウザ上では見えにくい
XMLサイトマップ	URL数・言語数が多いサイト	対応関係を一元管理しやすい	XMLが冗長になり、生成ロジックと更新漏れの管理が必要

対象はPDFなどの非HTMLですかheadを持たない文書にはHTML方式を使えません。

HTTPヘッダー

数万URL・多数言語を一元生成しますかCMSやバッチで対応表を管理できるなら相性が良いです。

XMLサイトマップ

通常のWebページでテンプレート管理できますか実装とデバッグの分かりやすさを優先できます。

HTML

HTTPヘッダーの例

Link: <https://example.com/ja/guide.pdf>; rel="alternate"; hreflang="ja",
      <https://example.com/en/guide.pdf>; rel="alternate"; hreflang="en",
      <https://example.com/guide-selector/>; rel="alternate"; hreflang="x-default"

XMLサイトマップの例

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://example.com/ja/product/</loc>
    <xhtml:link rel="alternate" hreflang="ja"
      href="https://example.com/ja/product/" />
    <xhtml:link rel="alternate" hreflang="en"
      href="https://example.com/en/product/" />
    <xhtml:link rel="alternate" hreflang="x-default"
      href="https://example.com/languages/product/" />
  </url>
  <url>
    <loc>https://example.com/en/product/</loc>
    <xhtml:link rel="alternate" hreflang="ja"
      href="https://example.com/ja/product/" />
    <xhtml:link rel="alternate" hreflang="en"
      href="https://example.com/en/product/" />
    <xhtml:link rel="alternate" hreflang="x-default"
      href="https://example.com/languages/product/" />
  </url>
</urlset>

XMLサイトマップ方式でも、各ローカライズURLの<url>要素に同じ代替URLセットを含めます。サイトマップに載せるURLは200で取得でき、インデックス可能な正規URLにそろえます。

hreflangとcanonicalの正しい関係

hreflangは「言語・地域別の代替URL」を示し、canonicalは「重複・類似URLの中で正規と考えるURL」を示します。目的が違うため、どちらか一方で代用することはできません。

正しい例

各言語が自分の言語の正規URLを指す

日本語ページ → 日本語canonical
英語ページ → 英語canonical
そのうえでhreflang相互参照

避ける例

全言語を日本語URLへcanonical

英語や中国語ページを日本語URLへ正規化すると、代替ページとしての整合性を壊し、他言語URLが検索に残りにくくなる可能性があります。

<!-- 日本語ページ /ja/product/ -->
<link rel="canonical" href="https://example.com/ja/product/" />

<!-- 英語ページ /en/product/ -->
<link rel="canonical" href="https://example.com/en/product/" />

<!-- 両ページには同じhreflangセットを置く -->
<link rel="alternate" hreflang="ja" href="https://example.com/ja/product/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/product/" />

同じ言語内に重複URLがある場合

たとえば英語ページがパラメータ付きURLでも取得できるなら、英語の正規URLへcanonicalを統一し、hreflangにもその正規URLを使います。サイトマップ、内部リンク、canonical、hreflangで別々のURLを指定しないことが重要です。

canonical先がリダイレクト、404、noindex、別言語になっていないか確認してください。 hreflangのリンク先も、最終的な正規URLを直接指定するのが安全です。

x-defaultの使い方：一致しないユーザーのフォールバックを示す

hreflang="x-default"は、ユーザーの言語・地域設定が、指定済みのどのローカライズ版にも一致しない場合のURLを示します。特定の言語コードではなく、フォールバックの役割です。

適したURL

言語・国の選択ページ

訪問者が自分で言語や配送地域を選べるページは、x-defaultの代表的な用途です。

慎重に判断

英語ページを既定にする

実際に「対応外ユーザーへ英語版を見せる」方針なら設定できますが、単に英語があるからという理由だけでは決めません。

<link rel="alternate" hreflang="ja-JP"
      href="https://example.com/jp/" />
<link rel="alternate" hreflang="en-US"
      href="https://example.com/us/" />
<link rel="alternate" hreflang="en-GB"
      href="https://example.com/uk/" />
<link rel="alternate" hreflang="x-default"
      href="https://example.com/country-selector/" />

x-defaultは必須ではありません。 明確なフォールバックURLがない場合に、形だけで追加する必要はありません。

WordPress・CMSでhreflangを実装するときの注意点

WordPressではWPML、Polylangなどの多言語機能を使ってhreflangを自動出力できます。ただし、プラグインを入れただけで正しさが保証されるわけではありません。テーマ、SEOプラグイン、翻訳プラグイン、CDNが別々にタグを出力すると、重複や矛盾が起きます。

翻訳ページ同士の対応をCMSに登録する

URLの文字列ルールだけで推測せず、記事IDや翻訳グループで「同じページ」を明示します。

出力元を一つにする

テーマと複数プラグインが同じhreflangを出さないよう、担当機能を決めます。

未翻訳ページを無理に結ばない

対応する翻訳がないページは、その言語のURLをhreflangセットに含めません。トップページへ一律で結ぶのも避けます。

公開・非公開の状態を同期する

翻訳を非公開にしたりURLを変更したりしたら、他言語ページのタグ、サイトマップ、内部リンクも更新します。

Goや静的サイトジェネレーターでは「翻訳対応表」をデータ化する

テンプレートで現在のパスを単純置換する方法は、言語ごとにURLスラッグが違うページや未翻訳ページで破綻しやすくなります。各ページに翻訳グループIDを持たせ、公開済みの言語と正規URLからhreflangセットを生成する方が安全です。

{
  "translationGroup": "product-123",
  "alternates": [
    {"lang": "ja", "url": "https://example.com/ja/shohin/"},
    {"lang": "en", "url": "https://example.com/en/product/"},
    {"lang": "zh-Hant", "url": "https://example.com/zh/product/"}
  ],
  "xDefault": "https://example.com/languages/product/"
}

hreflangで多い12のエラーと修正方法

エラーはタグの文法だけでなく、URLの応答、canonical、インデックス可否、翻訳ページの対応関係でも起きます。次の順で確認すると原因を切り分けやすくなります。

エラー	起きること	修正
1. 戻りリンクがない	片方向の指定が無視される可能性	相手ページにも同じ完全セットを出す
2. 自己参照がない	クラスターが不完全になる	各ページ自身の言語URLを含める
3. 相対URL	環境やホストの解釈で誤りやすい	httpsから始まる完全修飾URLにする
4. 国コードだけ	`JP`、`US`は言語を示さない	`ja-JP`、`en-US`のように言語を先に置く
5. 無効な地域コード	`en-UK`、`en-EU`などが解釈されない	正式なISO 3166-1 Alpha 2を使う
6. 404・5xx	代替URLを取得できない	200で直接取得できる公開URLへ更新
7. リダイレクトURL	余分な処理とシグナル不一致	最終到達の正規URLを直接指定
8. noindex	検索に出せないURLを代替として指定	index可能にするかセットから外す
9. canonicalが別言語	hreflangと正規化が衝突	同じ言語の正規URLへcanonical
10. ページ内容が対応しない	商品詳細とカテゴリなど意味が不一致	同じ検索意図・主要内容のページだけを結ぶ
11. 方式間の不一致	HTMLとサイトマップでURLセットが違う	実装方式を一つに絞るか同じデータ源から生成
12. 更新漏れ	URL変更・削除後も古い参照が残る	公開フローに自動検査と差分確認を入れる

「全ページを各言語のトップページへ結ぶ」は避ける

翻訳がない記事を、英語トップや中国語トップへ一律に関連付けると、ページの意味が対応しません。翻訳がないなら、その言語のhreflangを省略する方が正確です。ユーザー向けには、サイト共通の言語切替導線や翻訳予定の案内を別に用意します。

少しの表現差は問題ではないが、目的はそろえる

地域ごとに価格、通貨、配送、問い合わせ先、法的表示、商品在庫が異なるのは自然です。一方、片方が商品購入ページ、もう片方が会社概要では対応ページとは言えません。「同じ目的を地域に合わせてローカライズしたページか」を基準にします。

hreflangの確認方法：Search Consoleだけに頼らず検証する

以前のGoogle Search Consoleには国際ターゲティングレポートがありましたが、現在は廃止されています。Search Consoleに専用のhreflangエラー一覧がある前提で運用せず、URL検査と実際の出力確認を組み合わせます。

出力場所を確認する

HTMLならレンダリング後のDOMだけでなく元のhead、HTTPならレスポンスヘッダー、XMLなら送信中のサイトマップを確認します。

全URLの応答を確認する

200で取得できるか、robots.txtでブロックされていないか、noindexがないか、不要なリダイレクトがないかを調べます。

セットの対称性を確認する

各ページの言語コードとURL一覧を比較し、自己参照・戻りリンク・x-defaultが同じかをチェックします。

canonicalとの一致を確認する

宣言したcanonicalとGoogleが選択したcanonical、hreflangに書いたURLが整合しているかURL検査で確認します。

検索結果と流入を観察する

国・言語・ランディングページ別に、意図しない言語URLが表示されていないか、クリックとコンバージョンを継続確認します。

公開前チェックリスト

対応ページが同じ目的・主要内容翻訳の有無だけでなく検索意図を確認

各ページが自分自身を含む自己参照がセットに存在

各ページで同じ完全セット言語追加・削除が全ページへ反映

URLは完全修飾・HTTPS相対URLやHTTP版を混ぜない

すべて200・index可能404、5xx、noindex、ブロックなし

canonicalは同じ言語正規URLをhreflangにも使用

コードが規格どおり言語、必要なら地域・文字体系

x-defaultの役割が明確言語選択または実際のフォールバック

言語切替リンクが使えるユーザーが強制転送を解除できる

更新時の自動検査がある削除・移転・未翻訳による崩れを検知

効果測定で見る指標

hreflang導入前後は、検索順位だけでなく「正しい言語URLへ着地したか」を測ります。Google Search Consoleでは国・検索クエリ・ページを組み合わせ、アクセス解析では言語別ランディングページ、直帰ではなく次の行動、問い合わせ・購入などのコンバージョンを確認します。

因果を断定しない：同時に翻訳、タイトル、内部リンク、速度を改善した場合、変化はhreflangだけの効果ではありません。変更日と対象URLを記録し、可能な範囲で施策を分けて評価します。

大規模サイトで崩れない運用設計

hreflangは初回実装よりも、その後の追加・削除・URL変更で壊れやすい機能です。言語数とページ数が増えるほど、手作業ではなくデータとテストで管理します。

単一の対応データを正とする

CMS、DB、翻訳管理システムのどれを正とするか決め、HTMLとサイトマップを同じデータから生成します。

公開状態を言語ごとに持つ

下書き・レビュー中・公開・廃止を管理し、公開済みの正規URLだけをクラスターへ含めます。

CIで機械検査する

コード形式、自己参照、戻りリンク、重複、HTTPステータス、canonical一致を自動テストします。

移転時は同時に更新する

301リダイレクト、canonical、内部リンク、サイトマップ、hreflangを同じリリースで切り替えます。

最小限の自動テスト項目

for each localized page:
  assert canonical is absolute HTTPS URL
  assert canonical language == page language
  assert hreflang set contains self
  assert all alternate URLs are unique
  assert all alternate URLs return HTTP 200
  assert no alternate URL is noindex
  assert every alternate page links back
  assert all pages in the group expose the same set

hreflangに関するよくある質問

hreflangを設定すると検索順位は上がりますか？

直接的な順位上昇を保証するタグではありません。言語・地域に合うURLをGoogleへ伝えることで、検索結果のURL選択を助けます。結果として誤言語流入が減り、ユーザー体験やコンバージョンに良い影響が出る可能性はあります。

jaとja-JPはどちらが正しいですか？

どちらも用途次第です。地域を限定しない日本語ページはja、日本の価格・配送・法制度など、日本地域に特化したページはja-JPを検討します。

各ページに自己参照のhreflangは必要ですか？

はい。Googleのガイドラインでは、他言語版だけでなく、そのページ自身の言語版も一覧に含めます。各ページが同じ完全なセットを持つ状態にします。

相対URLでも動きますか？

hreflangの代替URLは、https://から始まる完全修飾URLで指定します。ドメインが異なるページ同士を結ぶこともできます。

異なる言語ページを同じcanonicalにできますか？

原則として避けます。各言語ページは同じ言語の正規URLをcanonicalにし、言語間の関係はhreflangで示します。

x-defaultは必ず必要ですか？

必須ではありません。言語選択ページや、どの指定言語にも一致しないユーザーへ見せる明確なフォールバックURLがある場合に設定します。

HTMLとサイトマップの両方に書く方が強いですか？

GoogleはHTML、HTTPヘッダー、XMLサイトマップの3方式を同等に扱い、全部を併用しても追加の検索メリットはないと説明しています。保守しやすい方式を一つ選ぶのが基本です。

Search Consoleでhreflangエラーを確認できますか？

以前の国際ターゲティングレポートは廃止されています。URL検査でインデックスとGoogle選択canonicalを確認し、ソース、レスポンス、サイトマップ、戻りリンクは自分で検証します。

まとめ：タグを書く前に、対応URLと運用ルールを整える

hreflangを成功させる核心は、タグの一行ではなく「どのページとどのページが対応するか」を正確に管理することです。各ローカライズ版を固有URLで公開し、同じ意味のページだけをグループ化し、全ページで自己参照と相互参照をそろえます。

URLは言語・地域ごとに直接クロールできるようにする
各ページで自分自身を含む同じ完全セットを出力する
完全修飾URLと正しい言語・地域コードを使う
canonicalは原則として同じ言語の正規URLへ向ける
x-defaultは実際のフォールバックがある場合だけ使う
HTML・HTTPヘッダー・XMLサイトマップから保守しやすい方式を選ぶ
公開後はステータス、index可否、canonical、戻りリンクを継続検査する

多言語SEOでは、機械的な直訳ではなく、各市場の検索語、表現、価格、信頼情報、問い合わせ導線までローカライズすることが大切です。hreflangは、その整ったページ群を検索エンジンへ正しく伝える仕上げとして使いましょう。

主な確認資料（2026年7月29日確認）
・Google検索セントラル：ページのローカライズ版についてGoogleに知らせる
・Google検索セントラル：canonical URLの指定方法
・Google検索セントラル：ロケール適応ページのクロール
・Search Consoleヘルプ：国際ターゲティングレポートの廃止
・Search Consoleヘルプ：URL検査ツール

執筆・検証：Hikaru OnoWebサイト、WordPress、Go、HTML/CSS、Flutter、Firebaseを使った開発・改善に携わっています。本記事では、実装時に迷いやすいcanonicalと戻りリンクの関係を、公開前に確認できる順序へ整理しました。