hreflangとは？書き方・3つの実装方法と多言語サイトSEO対策の検証手順

hreflangは、同じ内容を複数の言語や地域向けに用意したページ同士を関連付け、検索結果でどの版を出すかをGoogleに伝えるための属性です。書式そのものは1行で終わりますが、返信リンクの欠落や地域コードの取り違えがあると該当する指定は無視され、しかもGoogleはSearch Consoleのhreflangエラーレポートを既に廃止しています。設定した後も、各言語版の宣言が揃っているかを自分で点検する必要があります。

この記事では、Google検索セントラルの現行ドキュメントの要件を出発点に、HTML・HTTPヘッダー・サイトマップという3つの実装方法の選び分け、多言語サイトのURL構造の判断基準、そして相互参照の欠落を機械的に洗い出す検証スクリプトまでを扱います。スクリプトは実際に動かし、その出力をそのまま掲載しています。

まとめ：hreflang設定で満たすべき5つの要件

先に結論を置きます。次の5点のうち、はじめの4つはGoogleが要件として明記しているもので、最後の1つは運用上の助言です。

• 自己参照を含める：Googleは「Each language version must list itself as well as all other language versions.」と明記しています。各言語版は自分自身も一覧に含めます。
• 相互に指し合う：「If two pages don't both point to each other, the tags will be ignored.」。片方向の指定は無視されます。
• コード規格を守る：言語はISO 639-1、地域はISO 3166-1 alpha-2。地域コード単独の指定は無効です。
• URLは絶対URLで書く：「Alternate URLs must be fully-qualified, including the transport method (http/https).」。相対パスは使えません。
• 実装は1方式に寄せる：3方式の併用は可能ですが、Googleは「there's no benefit in Search」としています。

もう1点、期待値の設定として押さえておきたいのが、hreflangは指示ではなく提案だという点です。Googleの2024年8月のSEO Office Hoursは「you can use hreflang to suggest to show a certain variation in a certain country.」と述べています。対象地域の判定にGoogleは複数のシグナルを使っており、hreflangはそのうちの1つです。設定すれば必ずその国でその版が出る、という保証はありません。

hreflangの役割と、lang属性・canonicalとの分担

別言語版・別地域版の関連付けという役割

hreflangが対象にするのは、同じ内容を別の言語や別の地域向けに用意したページの集合です。日本語版と英語版、あるいは同じ英語でも米国向けと英国向けのように、内容が同等で言語や通貨・表記だけが異なる版を、Googleに1つのまとまりとして認識させます。

これがないと何が起きるか。Googleは各版の対応関係を推測するしかなくなり、英国の利用者に米国向けページを返すことがあります。とくに同じ言語で地域だけが違う版は内容が近く、重複として扱われる可能性があります。Googleはこの場合について、優先するバージョンを選んだうえでrel="canonical"とhreflangを併用するよう案内しています。別言語に翻訳された版まで一律に重複扱いされるわけではありません。

lang属性との違い（通知先と適用範囲）

HTMLのlang属性とhreflangは、通知する相手も適用範囲も違います。lang属性は<html lang="ja">のようにそのページ自体の言語を宣言するもので、スクリーンリーダーの読み上げ言語やブラウザの翻訳提案に影響します。一方hreflangは、そのページと別URLにある他言語版との対応関係を検索エンジンに伝えます。

役割が異なるため、どちらか一方で代用することはできません。多言語サイトでは両方を設定します。lang属性が正しくても、他言語版のURLは伝わりません。hreflangが無くてもGoogleが別言語版を見つけることはありますが、対応関係の判断は推測に委ねられます。

canonicalとの併用ルール

hreflangとrel="canonical"は競合しません。ただし指す先を間違えると、hreflangで束ねた各版がまとめて1つのURLに集約され、出し分けが働かなくなります。

Googleは重複URLの正規化について「Do include a rel="canonical" link on the canonical page itself」とし、正規ページ自身にも自己参照のcanonicalを置くよう求めています。多言語構成では「make sure to specify a canonical page in the same language, or the best possible substitute language」、つまり同じ言語の中でcanonicalを完結させ、同じ言語の正規版が存在しない場合に限って最も近い代替言語を指すのが原則です。日本語版のcanonicalに英語版を指定する、といった言語をまたぐ正規化は避けてください。

言語コードと地域コードの指定規則

ISO 639-1とISO 3166-1 alpha-2の組み合わせ

hreflangの値は、1つまたは2つのコードをハイフンでつないだものです。Googleは「The first code of the hreflang attribute is the language code (in ISO 639-1 format)」とし、続く2つ目に「optionally the region (in ISO 3166-1 Alpha 2 format)」を置くと定めています。サポート範囲は明確で、「Only language codes listed in ISO 639-1 and region codes listed in ISO 3166-1 Alpha 2 are supported; other codes that aren't listed in those standards, such as es-419, aren't supported.」とされています。ラテンアメリカ向けのes-419のようなUN M.49由来のコードは通りません。

地域コード単独指定が無効になる理由

取り違えの典型が、国名の感覚で地域コードだけを書いてしまうケースです。Googleは「You can't specify the country code by itself. The first code stands for the language and Google doesn't automatically derive the language from a country code.」と警告しています。1つ目のコードは常に言語として解釈され、国から言語が自動的に導かれることはありません。

ドキュメントはベルギーを例に挙げています。「Good (German for users in Belgium): de-be」「Good (Dutch for users in Belgium): nl-be」に対し、beだけの指定は「Bad because the first code is for language (be is the Belarusian language code)」です。ベルギー向けのつもりで書いたbeは、ベラルーシ語の指定として読まれます。エラーにはならず、意図と違う解釈のまま静かに動き続けるため、目視では気づきにくい種類の誤りです。

x-defaultの適用条件

x-defaultは予約値で、Googleは「The reserved x-default value is used when no other language/region matches the user's browser setting.」と説明しています。用意したどの版とも一致しない利用者に見せる受け皿です。

設計上の想定も公式に書かれています。「While you can use the x-default value for any page, it was designed for language selector pages」。つまり本来の用途は言語選択ページです。日本語版と英語版しか持たないサイトが、ドイツ語圏の利用者にどちらを見せたいかを決めているなら、その版にx-defaultを付ける運用でも構いません。決めていないなら無理に付ける必要はなく、必須要件でもありません。

実装3方式の選び分け（HTMLタグ・HTTPヘッダー・サイトマップ）

Googleが示す実装方法は3つです。「There are three ways to indicate multiple language/locale versions of a page to Google: HTML HTTP Headers Sitemap」。よく「1ページにつき1方式でなければならない」と書かれますが、公式にはそこまでの制約はありません。「there's no benefit in Search (in fact, it maybe be much harder to manage three implementations instead of just picking one).」というのが実際の記述で、併用は可能・利点は無い・管理が難しくなる、という整理です。要件ではなく運用上の助言として読むのが正確です。

HTMLのlink要素による記述

最も一般的な方法です。各ページの<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/" />

この4行を、/ja/にも/en-us/にも/en-gb/にも同一内容で置きます。x-defaultの指定先にしたトップページも例外ではありません。版が増えるほど各ページの<head>を同時に更新する必要があるため、CMSのテンプレート側で自動生成しないと早晩ずれます。

HTTPレスポンスヘッダーによる記述

PDFなど<head>を持たないファイルの多言語版を指定するときは、HTMLのlink要素が使えないため、この方式かサイトマップ方式を選びます。書式は次のとおりです。

Link: <https://example.com/ja/doc.pdf>; rel="alternate"; hreflang="ja",
      <https://example.com/en-us/doc.pdf>; rel="alternate"; hreflang="en-us"

CDNのエッジで付与する構成を取れば、オリジンのアプリケーションに手を入れずにヘッダーを差し込めます。ただしヘッダーは表示上どこにも現れないため、設定漏れや誤りが目に見えません。後述の検証を自動化しておかないと、事故に気づくのが順位低下の後になります。

XMLサイトマップによる記述

ページ数が多いサイトで管理しやすいのがこの方式です。xhtml名前空間を宣言し、各<url>要素の中にすべての版を並べます。

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://example.com/ja/</loc>
    <xhtml:link rel="alternate" hreflang="ja" href="https://example.com/ja/"/>
    <xhtml:link rel="alternate" hreflang="en-us" href="https://example.com/en-us/"/>
  </url>
</urlset>

この方式でも相互参照の要件は変わりません。/en-us/の<url>要素にも、jaとen-usの両方を書く必要があります。

hreflang実装方式の選択基準

迷ったらHTMLのlink要素を基本にし、非HTMLファイルが混じる範囲だけHTTPヘッダーで補うのが管理しやすい組み合わせです。3方式を並行運用する構成は、更新のたびに3箇所を同期させる負担に見合いません。

相互参照の欠落を検出する検証スクリプト

hreflangでは書式だけでなく、ページ間の参照関係の整合も確認する必要があります。ページを1枚ずつ目で見ても、AがBを指しているのにBがAを指していない、という関係の欠落は追えません。そこで、全ページのhreflang宣言をまとめて読み込み、Googleの要件と突き合わせるスクリプトを用意します。

検査する4項目と実行出力

次のスクリプトは、指定したHTMLファイル群からrel="alternate"のlink要素を抜き出し、自己参照の欠落・相対URL・コード形式の誤り・返信リンクの欠落の4種類を検出します。言語コードそのものがISO 639-1に載っているかまでは照合しないため、実在しないzzのようなコードは通過します。

import re, sys

LINK = re.compile(
    r'<link\b[^>]*rel=["\']alternate["\'][^>]*>', re.I)
ATTR = re.compile(r'(hreflang|href)=["\']([^"\']+)["\']', re.I)
CODE = re.compile(
    r'^([a-z]{2,3})(?:-([A-Z][a-z]{3}))?(?:-([A-Za-z]{2}))?$')
REGIONS = {"US", "GB", "JP", "CN", "TW", "DE", "FR", "KR", "SG"}

def parse(path):
    pairs = []
    for tag in LINK.findall(open(path, encoding="utf-8").read()):
        a = {k.lower(): v for k, v in ATTR.findall(tag)}
        if "hreflang" in a and "href" in a:
            pairs.append((a["hreflang"], a["href"]))
    return pairs

def main(argv):
    pages = dict(p.split("=", 1) for p in argv)
    ann = {url: parse(path) for url, path in pages.items()}
    errors = 0
    for url, pairs in sorted(ann.items()):
        declared = {h: u for h, u in pairs}
        if url not in declared.values():
            print(f"[self ] {url}: 自己参照のhreflangが無い")
            errors += 1
        for code, href in pairs:
            if not href.startswith(("http://", "https://")):
                print(f"[abs  ] {url}: 相対URL {href}")
                errors += 1
            if code != "x-default":
                m = CODE.match(code)
                if not m:
                    print(f"[code ] {url}: 形式が不正なコード {code}")
                    errors += 1
                elif m.group(3) and m.group(3).upper() not in REGIONS:
                    print(f"[code ] {url}: 地域コードが不正 {code}")
                    errors += 1
            if href in ann and url not in dict(ann[href]).values():
                print(f"[return] {url} -> {href}: 返信リンクが無い")
                errors += 1
    print(f"pages={len(ann)} errors={errors}")
    return 1 if errors else 0

if __name__ == "__main__":
    sys.exit(main(sys.argv[1:]))

検証用に、誤りを3種類仕込んだファイルを用意します。en-uk.htmlは地域コードをGBではなくUKと書き、hrefを相対パスにしてあります。ja.htmlにはその誤ったen-ukがそのまま入っています。en-us.htmlからは日本語版への行を削り、返信リンクを欠落させています。

$ cat en-uk.html
<link rel="alternate" hreflang="en-uk" href="/en-uk/" />
<link rel="alternate" hreflang="ja" href="https://example.com/ja/" />

3ファイルを渡して実行した結果が次の出力です。

$ python3 hreflang_check.py \
    https://example.com/ja/=ja.html \
    https://example.com/en-us/=en-us.html \
    https://example.com/en-uk/=en-uk.html
[self ] https://example.com/en-uk/: 自己参照のhreflangが無い
[abs  ] https://example.com/en-uk/: 相対URL /en-uk/
[code ] https://example.com/en-uk/: 地域コードが不正 en-uk
[return] https://example.com/ja/ -> https://example.com/en-us/: 返信リンクが無い
[code ] https://example.com/ja/: 地域コードが不正 en-uk
pages=3 errors=5

注目したいのは最終行のひとつ上、日本語版に出ている[code ]です。誤ったコードを書いたのは英国版ですが、その英国版を参照している日本語版でも同じ誤りが検出されています。hreflangは全版に同じ一覧を書くため、1箇所の誤記が版の数だけ増殖します。手作業での修正が破綻しやすいのはこの構造が理由です。

修正後の再検査と終了コードの読み方

en-ukをen-gbに直し、hrefを絶対URLにし、x-defaultの指定先を含む5ファイルすべてに同じ5行を置いて再実行すると、次のようになります。

$ python3 hreflang_check.py \
    https://example.com/ja/=ja.html \
    https://example.com/en-us/=en-us.html \
    https://example.com/en-gb/=en-gb.html \
    https://example.com/zh-hant/=zh-hant.html \
    https://example.com/=index.html
pages=5 errors=0

終了コードは、この検査で見つかったエラーの有無だけを表します。入力に渡さなかったURLは検査対象外で、ファイルを1つも渡さなくてもerrors=0で正常終了します。CIの合否判定に使うなら、検査対象の件数が想定と一致しているかを確認する処理を先に足してください。実運用ではHTMLファイルではなくビルド成果物やクロール結果を入力にし、REGIONSにはISO 3166-1 alpha-2の全コードを読み込ませます。ここでは説明のため対象地域だけに絞っています。

URL構造とドメイン設計の判断基準

ccTLD・サブドメイン・サブディレクトリの比較

多言語サイトのSEOで、hreflangと並んで最初に決めるのがURL構造です。Googleは地域ターゲティングの判定について「Google relies on a number of signals to determine the best target audience for a page」とし、hreflangの記述、ccTLD、サーバーの所在地、住所や通貨などを列挙しています。URL構造はこのうち最も動かしにくいシグナルです。

ccTLDは「These are tied to a specific country and therefore provide a strong signal to both users and search engines」と評価されており、特定の国を対象としていることが、利用者にも検索エンジンにも伝わります。ただしドメインごとに評価を積み直すコストがかかります。サブドメインとサブディレクトリについて、Googleは地域シグナルの強弱を明示していません。「Users might not recognize geotargeting from the URL alone」という難点は、両方の欄に挙げられています。差がつくのは運用面で、サブドメインはサーバーを地域別に置け、サブディレクトリは同一ホストで低コストに管理できます。

既存サイトが.comなどの汎用ドメインで、海外向けも同じ体制で運用するなら、サブディレクトリを推奨します。同一ホストで運用をまとめられ、hreflangの管理対象も集約できるからです。ただし新しい言語版に既存ページと同じ評価が引き継がれるわけではありません。.co.jpのような国別ドメインを使っている場合は、そのドメイン自体が日本向けのシグナルになるため、汎用ドメインへの移行と比べたうえで決めてください。国別に独立した法人が別々にサイトを運用し、担当も予算も分かれている場合に限り、ccTLDの分割が見合います。URL設計を含めた全体の進め方は多言語サイト制作とは？進め方・費用相場と言語・URL設計の判断基準を解説で扱っています。

IPアドレス判定による自動リダイレクトの回避

URL構造を決めたあとに問題になりやすいのが、アクセス元のIPアドレスから国を判定して自動的に転送する実装です。Googleは「IP アドレス分析に合わせてコンテンツを変更しないでください。IP アドレスの位置分析は困難であり、一般的に信頼できるものではありません。」として、これを避けるよう求めています。

実害は明確です。Googlebotは特定の版だけをクロールすることになり、hreflangで結び付けたはずの他の版に到達できなくなります。相互参照が成立していても、クローラーが片方しか見られなければ意味がありません。言語の切り替えは自動転送ではなく、利用者が選べるリンクとして提供してください。

インターナショナル ターゲティング レポート廃止後の検証手順

hreflangの解説記事の多くが、確認方法としてSearch Consoleの「インターナショナル ターゲティング」レポートを案内しています。この案内は既に使えません。Googleは公式ヘルプで、Search Consoleの国単位のターゲティングについて「the ability to target search results to specific countries using Search Console country targeting was determined to have little value」とし、サポート終了を告知しました。ドキュメントの更新履歴には2022年8月24日付で「Removed references to the deprecated International Targeting report in Search Console.」と記録されています。

誤解のないよう補足すると、廃止されたのはレポートと国別ターゲティング設定であって、hreflangそのものではありません。同じヘルプページは「Google will continue to support and use hreflang tags on your pages.」と明記しています。失われたのは、サイト全体のhreflangエラーをGoogleがまとめて教えてくれる仕組みです。

現在取れる手順は3段階です。第1に、公開前の検証を自前で回すこと。前章のスクリプトのように、相互参照とコード規格をビルド時に機械的に確認する仕組みを持ちます。Google自身もデバッグについてはサードパーティ製ツールを紹介するにとどめ、それらは「not maintained or checked by Google」と断っています。検証責任はサイト側にあると考えたほうが現実的です。

第2に、公開後の実装確認です。Search ConsoleのURL検査ツールでレンダリング後のHTMLを取得すれば、個別URLのhead内にhreflangが出力されているかを確認できます。一括レポートは無くなりましたが、URL単位の確認手段は残っています。HTTPヘッダー方式を採っている場合も、URL検査でクロール済みページの詳細を開けばHTTPレスポンスヘッダーを確認できます。継続的な監視には、レスポンスヘッダーを取得する仕組みを別途用意してください。

第3に、出し分けが実際に効いているかの確認です。Search Consoleの検索パフォーマンスを国別に分解し、各版に想定した国からの表示が付いているかを見ます。英国向けページに米国からの表示が集中していれば、hreflangが効いていない可能性を疑う材料になります。クエリの違いや需要の偏りでも同じ形になるため、これだけで断定はせず、URL検査での実装確認と合わせて判断します。順位ではなく国別の表示分布を見るのが要点です。

hreflangが効かない典型パターン

設定済みでも意図した表示にならないときに、確認する構成とコンテンツの問題を挙げます。

返信リンクが一部だけ欠けている。トップページは全版で揃っているのに、後から追加した下層ページで新しい言語版の行を足し忘れる。Googleは「If page X links to page Y, page Y must link back to page X.」と定め、成立しない接続のタグを無視します。全滅ではなく欠けた接続だけが落ちるため、症状が部分的で気づきにくいのが厄介です。

canonicalが言語をまたいで集約している。英語版のcanonicalが日本語版を指していると、言語版の対応関係と正規化の指定が矛盾します。Googleがその指定を採用すれば、英語版は正規URLとして扱われなくなります。両方を設定していても、この組み合わせでは意図した出し分けになりません。canonicalは同じ言語の正規URLを指し、hreflangと矛盾しない状態にしてください。

価値の乏しい翻訳ページを大量に量産している。hreflangは版同士の関係を伝えるだけで、各版の品質を保証しません。Googleのスパムポリシーは、順位操作を目的として「automated transformations like synonymizing, translating, or other obfuscation techniques), where little value is provided to users」に該当する大量生成を問題視しています。機械翻訳を使ったこと自体がただちにスパムになるわけではありませんが、大量生成・順位目的・価値の欠如が揃うと該当します。翻訳後に現地の表記や商習慣へ合わせる工程が必要で、その範囲はローカライズとは？翻訳・国際化との違いと対象範囲・実施可否の判断基準で整理しています。

言語版の中身が実質同じである。米国版と英国版で通貨も表記も配送条件も同一なら、そもそも分ける必要がありません。Googleは版を分けるだけで市場別に順位が付くわけではないとしており、通貨や価格が異なる場合の出し分けにhreflangを使う例を挙げています。差分が無い版を増やすのは、管理対象を増やすだけで効果がありません。多言語化に踏み切る前に、地域ごとに何を変えるのかを先に決めてください。決済や関税など地域差が大きい領域は越境ECサイト構築の進め方｜多言語・海外決済・関税要件と失敗回避の判断軸が参考になります。

なお、hreflangはGoogle専用の仕組みではありません。Microsoft Bingも2025年12月19日付のWebmaster Blogで「Use hreflang to define language and regional targeting」と案内し、rel="alternate" hreflang="en-gb"の例を掲載しています。Googleに加え、Bingの公式ブログでも推奨されている指定です。

よくある質問

hreflangの書き方は？

<link rel="alternate" hreflang="ja" href="https://example.com/ja/" />の形式で、対応するすべての版を<head>内に列挙します。このとき自分自身の版も含めます。hrefはhttps:から始まる絶対URLで書き、記述した各版のページにも同じ一覧を置いて相互に指し合う状態にします。

HTMLのlang属性とhreflangは両方必要ですか？

両方必要です。lang属性はそのページ自体の言語をブラウザや支援技術に伝えるもので、hreflangは他言語版のURLを検索エンジンに伝えるものです。通知先も役割も異なるため、片方で代用できません。

x-defaultは必須ですか？

必須ではありません。Googleはx-defaultを「no other language/region matches the user's browser setting」の場合に使う予約値と定義し、言語選択ページ向けに設計されたと述べています。用意した版のどれにも当てはまらない利用者にどこを見せるかを決めているなら指定し、決めていないなら省略して構いません。

hreflangを設定すれば指定した国の検索結果に必ず表示されますか？

保証はありません。Googleは対象地域の判定に複数のシグナルを使っており、hreflangはその1つです。公式のSEO Office Hoursでも「use hreflang to suggest to show a certain variation in a certain country」と、提案という語で説明されています。ccTLDやサーバー所在地など他のシグナルと矛盾していれば、hreflangの指定どおりにならないことがあります。

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

サイト全体をまとめて確認するレポートはありません。インターナショナル ターゲティング レポートは廃止され、公式ドキュメントからも2022年8月24日付で参照が削除されました。個別URLについてはURL検査ツールでレンダリング後のHTMLを確認できます。全体の整合性は、自前の検証スクリプトかサードパーティのクローラーで確認してください。

関連記事

• 多言語サイト制作とは？進め方・費用相場と言語・URL設計の判断基準を解説
• ローカライズとは？翻訳・国際化との違いと対象範囲・実施可否の判断基準
• 越境ECサイト構築の進め方｜多言語・海外決済・関税要件と失敗回避の判断軸
• グローカリゼーションとは？意味と語源、グローバル化・ローカライズとの違いを事例で解説