トップ > 内部SEO対策 > 多言語SEOで失敗しないためのhreflang設計｜canonical・noindex・x-defaultの落とし穴も解説

多言語SEOで失敗しないためのhreflang設計｜canonical・noindex・x-defaultの落とし穴も解説

内部SEO対策 SEOの基礎知識 その他
にほんブログ村 IT技術ブログ SEO・SEMへ

多言語・多地域サイトを運営していると、「日本語ページなのに英語版が表示される」「せっかく翻訳したのにインデックスされない」といったトラブルに直面することがあります。その原因の多くは、hreflangタグの設定ミスや周辺設定との矛盾です。

本記事では、hreflangで解決できること・できないことを明確にしたうえで、実装パターン（HTML・サイトマップ・HTTPヘッダー）、canonical/noindex/robotsとの整合ルール、GSCでのデバッグ手順、そして運用で崩れないための月次監査テンプレまでを網羅的に解説します。

本記事の内容を理解することで、多言語SEOの事故を未然に防ぎ、Googleに正しく言語版を認識させる設計を、実践できるようになります。

結論

多言語SEOにおいてhreflangタグは重要ですが、「タグを付ければ順位が上がる」わけではありません。
hreflangは、複数の言語版・地域版が存在する場合に、検索ユーザーに対して適切なURLを表示しやすくするための仕組みです。

できること 概要 できないこと
言語版の認識 同一コンテンツの言語版同士を関連付け、Googleに認識させる コンテンツの質が低い場合、認識されても評価されない
地域別表示 検索ユーザーの言語・地域設定に応じて適切なURLを表示しやすくする ユーザーが手動でURL変更した場合は制御不可
評価の分散防止 言語版同士を重複扱いしにくくし、それぞれの言語圏で評価されやすくする 機械翻訳のみの低品質ページは評価されにくい
インデックス最適化 各言語版を正しくインデックス（ただし他のシグナルも影響） 技術的エラー（canonical矛盾など）があると無効化されやすい

注意点：Googleは、主にページ内容（言語としての一貫性や本文テキストなど）と複数のシグナルをもとに、適切な言語版を表示します。hreflangやHTMLのlang属性はあくまで補助シグナルなので、コンテンツ自体が対象言語として明確であることが前提です。

失敗パターンの9割は設定の矛盾（canonical/noindex/URL正規化）

実務で多言語SEOが機能しない原因を調査すると、以下のような設定の矛盾が圧倒的に多いです。

よくある失敗 起きる問題
hreflangは付けたがcanonicalで統合している 言語版が別ページとして扱われず、hreflangが効きにくい
noindexしたページをhreflangに含めた 対象URLがインデックスされず、相互参照が崩れやすい
http/httpsや末尾スラッシュが揺れている 相互参照が別URL扱いになり、エラーが増える
自動リダイレクトでクローラーが言語版に到達できない 言語版の存在を認識されず、hreflangも読まれない

まず設計（URL設計・言語/地域の切り方）

サブディレクトリ/サブドメイン/ccTLDの選び方

方式 例 メリット デメリット hreflang運用
サブディレクトリ example.com/ja/
example.com/en/		 ドメイン評価を集約しやすい
管理が比較的容易		 1ドメイン内で大量URL管理 同一ドメイン内で完結
サブドメイン ja.example.com
en.example.com		 言語ごとに独立運用しやすい 運用次第で評価シグナルが分かれて見えやすく、管理が難しくなる場合がある
GSCプロパティも分けて運用するケースが多い		 異なるサブドメイン間で設定
ccTLD example.jp
example.com		 地域ターゲティングが明確 ドメイン取得・管理コスト大
実質別サイト運用になりやすい		 異なるドメイン間で設定

推奨パターン

  • 中小規模・予算限定：サブディレクトリ（/en/、/ja/）
  • 言語ごとに運用組織が分かれる：サブドメイン
  • 国ごとに完全別事業：ccTLD

サブドメインの運用については、サブドメインで失敗した事例と対策も参考になるかと思います。

自動リダイレクトやcookie出し分けの注意

多言語サイトでは、ユーザーのIPアドレスやブラウザ言語設定で自動的にリダイレクトする実装がありますが、検索エンジンのクローラーが各言語URLへ到達できない形になると、インデックスやhreflangの解釈が崩れる原因になります。

よくある事故例

  • 日本語版（example.com/ja/）にアクセスしたクローラーを、強制的に英語版（/en/）へリダイレクト
  • その結果、Googleが日本語版ページの存在を認識できず、hreflangも読み取れない

安全な対処の考え方

  • 強制リダイレクトは避け、各言語URLに常にアクセス可能にする
  • ユーザー向けには、ページ上部などに言語切り替えUIを提供する

hreflangの仕様（最重要ルール）

hreflangを正しく機能させるには、まず絶対に守るべき4つのルールを押さえる必要があります。

1. 相互参照（return link）必須

hreflangは「AがBを指すなら、BもAを指す」必要があります。
片方向だけだとエラーになり、無視されることがあります。

2. 自己参照も入れる

各言語版ページは、他言語だけでなく自分自身にもhreflangを付けます。

3. 言語/地域コードは正しいものを使う

  • 言語のみ：en、ja
  • 言語＋地域：en-US、en-GB、ja-JP

4. 絶対URL（プロトコル含む）を使用

hreflangのhrefは、相対URLではなく絶対URL（https:// まで含む）を推奨します。

x-defaultの位置づけと使いどころ

x-defaultは、どの言語/地域にも当てはまらないユーザー向けの「デフォルトURL」を示す用途です。
典型例は「言語選択ページ」や「グローバル共通ページ」です。

実装パターン3つ

hreflangの実装方法は3つあります。

仕様上は複数方式を使えますが、運用では1方式に統一するのが安全です（併用すると差分や不整合が起きやすく、検証も難しくなります）。

HTML実装テンプレ（2言語＋x-default）

最も一般的な方法です。各ページの<head>内に記述します。

実装例（日本語・英語の2言語サイト）

<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <title>多言語SEOガイド</title>
  
  <!-- 自己参照canonical -->
  <link rel="canonical" href="https://example.com/ja/guide" />
  
  <!-- hreflang設定 -->
  <link rel="alternate" hreflang="ja" href="https://example.com/ja/guide" />
  <link rel="alternate" hreflang="en" href="https://example.com/en/guide" />
  <link rel="alternate" hreflang="x-default" href="https://example.com/" />
</head>
<body>
  <!-- コンテンツ -->
</body>
</html>

x-defaultの注意
x-default は「どの言語/地域にも当てはまらないユーザー向けのデフォルトURL」を示す用途です。言語選択ページ（/）があるならそこを指定するのが分かりやすく、言語選択がない場合は無理に付けず、設計意図を明記したうえ“デフォルトのURLにする運用もあります。

英語ページも同様に

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Multilingual SEO Guide</title>
  
  <link rel="canonical" href="https://example.com/en/guide" />
  
  <link rel="alternate" hreflang="ja" href="https://example.com/ja/guide" />
  <link rel="alternate" hreflang="en" href="https://example.com/en/guide" />
  <link rel="alternate" hreflang="x-default" href="https://example.com/" />
</head>
<body>
  <!-- Content -->
</body>
</html>

チェックポイント

  • 全ページに同じセットを付ける（自己参照含む）
  • URLは正規URL（https、末尾スラッシュの統一）
  • x-defaultは設計意図に合わせる（無理に付けない判断もあり）

XMLサイトマップで管理（大規模サイト向け）

ページ数が多い場合は、サイトマップでhreflangを管理すると運用が安定します。

<url>
  <loc>https://example.com/ja/guide</loc>
  <xhtml:link rel="alternate" hreflang="ja" href="https://example.com/ja/guide" />
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/guide" />
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/" />
</url>

<url>
  <loc>https://example.com/en/guide</loc>
  <xhtml:link rel="alternate" hreflang="ja" href="https://example.com/ja/guide" />
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/guide" />
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/" />
</url>

サイトマップ運用の基本は、Googleサーチコンソール使い方基本ガイドも参照してください。

HTTPヘッダー（PDFなどHTML以外）

PDFなどHTML以外でも、HTTPヘッダーでhreflangを指定できます（運用はやや上級者向け）。

canonical・noindex・robots・サイトマップの矛盾

canonicalは基本「自己参照」—言語版同士を潰さない

多言語ページ同士は、別URL＝別ターゲットです。
英語ページのcanonicalを日本語に向けるなど、言語版を統合する設定は避けるのが基本です。

canonicalの詳細は、Canonicalタグとは？SEOへの影響と正しい使い方も確認してください。

noindexしたURLをhreflangに入れる事故

noindexが付いたURLはインデックス対象ではないため、相互参照のセットに混ぜると解釈が崩れやすくなります。
特別な理由がない限り、言語版として見せたいURLはnoindexにしないのが基本です。

noindexの使い分けは、noindex設定の注意点と落とし穴も参照してください。

robots.txtでブロックしていると検証不能になりやすい

robots.txtでクロールをブロックすると、URL検査や相互参照の確認が難しくなります。
言語版URLは基本的にクロール可能にしておくのが安全です。

サイトマップは正規URLのみ・hreflangセットと一致させる

サイトマップには正規URLのみを載せ、hreflangで扱うURLセットと矛盾させないようにします。
送信・確認手順はSearch Consoleの基本設定と運用を参考にしてください。

デバッグ手順（効かないを潰すチェックリスト）

hreflangは「設定したのに効かない」が起こりやすい領域です。
まずはGSCでインデックス状況を確認し、エラー原因を潰します。

GSCの見方に不安がある場合は、【2026年版】Google Search Console 完全ガイドも参照してください。

ありがちなエラー → 原因 → 直し方

症状 原因 直し方
Missing return links 相互参照が片方向 全言語ページで同一セットを出す（自己参照含む）
不正なコード 言語/地域コードの誤り 正しいコードに修正（例：en-GB、ja-JP）
http/https・末尾スラッシュ揺れ URL正規化が統一されていない 正規URLを統一し、サイトマップも合わせる
canonical矛盾 別言語URLへcanonicalを向けている 各言語ページは自己参照canonicalを基本にする
noindex混入 hreflangセットにnoindexが混ざる 原則、言語版として扱うURLはindex可能に

公開後に崩れる原因（運用で壊れる）

  • 新規ページを追加したが、他言語版側にhreflangを追加し忘れた
  • URL正規化ルールが変わり、過去URLとの整合が崩れた
  • テンプレ改修でcanonical/noindexが混ざった

運用テンプレ

月次監査チェックリスト

【月次監査：hreflang整合チェック】

  • [ ] 新規公開ページは全言語版に相互参照（return link）が追加されている
  • [ ] 自己参照hreflangが入っている
  • [ ] canonicalが自己参照になっている（言語版同士を潰していない）
  • [ ] hreflang対象URLにnoindex/robotsブロックが混ざっていない
  • [ ] URL正規化（https、末尾スラッシュ、パラメータ）が統一されている
  • [ ] サイトマップのURL集合とhreflangの集合が一致している

クライアント・社内説明のための一文テンプレ

「hreflangは順位を上げる魔法ではなく、言語/地域の誤配信を減らして適切なURLを見せるための仕組みです。canonical/noindex/サイトマップと整合を取ることで、翻訳投資を無駄にしない運用にします。」

クラスター運用で改善ループを回す方法は、トピッククラスター運用後の改善ループ【GSC分析編】も活用してください。

よくある質問（FAQ）

Q1. hreflangを入れたのに言語が入れ替わります

A. hreflangは補助シグナルです。
本文が対象言語として明確か、相互参照が揃っているか、canonical/noindexの矛盾がないかを順に点検してください。

Q2. x-defaultは必須ですか？

A. 必須ではありません。
言語選択ページなど「デフォルトの受け皿」がある場合に有効です。無理に付けるより、設計意図が説明できる形で使うのが安全です。

Q3. canonicalとhreflangは併用できますか？

A. 併用は可能です。
ただし多言語の同一テーマページ同士をcanonicalで統合すると、hreflangが意味を失いやすいので、基本は各言語ページで自己参照canonicalを推奨します。

Q4. noindexページをhreflangに含めるべき？

A. 原則としてnoindexページはhreflangの対象に含めないのが安全です。
インデックスされないURLが混ざるとセットの整合が崩れやすくなります。

Q5. サイトマップ方式とHTML方式はどっちが良い？

A. 小〜中規模はHTMLが導入しやすく、大規模はサイトマップが運用しやすい傾向があります。
重要なのは「1方式に統一して不整合を防ぐ」ことです。

Q6. サブドメインとサブディレクトリ、どっちがSEO有利？

A. 一概に断定はできません。
運用体制・計測・内部リンク・インフラ都合で最適が変わります。一般に、管理負荷を下げたい場合はサブディレクトリが選ばれやすいです。

まとめ

  • hreflangは「付ければOK」ではなく、整合（return link・自己参照・URL正規化・canonical/noindex/サイトマップ）で効き方が決まる
  • x-default は「デフォルトの受け皿」があるときに有効。無理に付けず設計意図を明記する
  • 運用で崩れやすいので、月次監査テンプレで継続点検する

次におすすめの記事はこちら