Skip to main content
Web・SEO

多言語サイトのSEO対策:hreflang・URL設計・翻訳フローの正しい進め方

多言語サイトを検索で正しく評価してもらうためのURL設計、Google公式ドキュメントに基づくhreflangとcanonicalのルール、よくあるミス、翻訳フローを解説します。

著者:Jayson Hao8 分で読めます
多言語サイトのSEO対策:hreflang・URL設計・翻訳フローの正しい進め方をテーマにした紙と金属のエディトリアル作品
エディトリアル・フィールドノートITL / № 35

この記事のポイント

  • Googleは、ページの言語判定にhreflang、HTMLのlang属性、URLを使わず、表示されている本文を読むと明言しています。
  • hreflangは2つのページが互いを指していなければ無視されます。各言語版は他の言語版に加えて自分自身も列挙する必要があります。
  • canonicalは同じ言語のページに向けます。すべての翻訳ページを英語版に向けると、翻訳ページを検索から外すよう伝えることになります。
  • 2025年版Web Almanacの調査では、hreflangを使っているページはデスクトップで20.3%、モバイルで19.7%で、前年からほぼ倍増しました。

Googleはどの言語版を表示するかをどう決めているか

多言語サイトが検索でうまく機能するかどうかは、2つの別々の問いで決まります。1つ目は「そのページが何語か」です。これはGoogle自身が判断します。Googleの多地域・多言語サイト向けガイドによると、判定には表示されている本文を使い、lang属性やURLといったコード上の情報は使いません。本文が英語のままなら、URLやマークアップが何であれ英語のページとして扱われます。

2つ目は「内容が同じ複数のページのうち、どれをその検索ユーザーに見せるか」です。これを伝えるのがhreflangです。Googleのローカライズ版に関するドキュメントは、hreflangを、ページ同士が同じコンテンツの言語・地域別バリエーションであることを伝える手段と説明しています。これにより検索結果で利用者の言語や地域に合った版が表示されます。指定しなくてもGoogleが他言語版を見つけることはありますが、明示的に指定することが推奨されています。

導入は急速に進んでいます。HTTP Archiveのクロールデータを分析した2025年版Web AlmanacのSEO章によると、hreflangを使っているページはデスクトップで20.3%、モバイルで19.7%で、前年のほぼ倍になったと報告されています。言語版を宣言するサイトが増えた分、細部を誤っているサイトも増えています。

多言語サイトに最適なURL構造は?

言語版ごとに専用のURLが必要です。Googleのガイドは4つの方式を比較しており、非推奨としているのはURLパラメータだけです。どれを選ぶかはSEOよりも、対象市場の数とサイトを運用する体制で決まります。

  • サブディレクトリ(example.com/fr/、example.com/ja/):設定が簡単で、同じホストのため保守の手間も少ない方式です。当サイトもこの構成で、2〜5言語を扱う多くの企業にはこれを推奨しています。
  • サブドメイン(fr.example.com):設定が簡単でサーバーの設置場所を分けられますが、URLだけでは対象市場が利用者に伝わりにくい方式です。
  • 国別ドメイン(example.fr、example.jp):地域ターゲティングが最も明確ですが、1ドメインで1か国しか対象にできず、費用がかかり、登録要件が厳しい場合もあります。市場ごとに事業を独立して運営する場合に向いています。
  • URLパラメータ(example.com?lang=fr):Googleは非推奨としています。

言語の切り替え:自動リダイレクトとIP判定は避ける

訪問者のIPアドレスやブラウザ設定から言語を自動で振り分けるサイトは少なくありません。しかしGoogleはこれを推奨していません。言語版間で利用者を自動的にリダイレクトしないこと、IP分析でコンテンツを切り替えないことを求めており、IPによる位置判定は難しく一般に信頼できないとしています。モントリオールのバイリンガルの住民、トロントに滞在中の日本人、そしてクローラーは、いずれもその前提に当てはまりません。

うまくいく方法はシンプルです。すべての言語版に固定のURLでアクセスでき、各ページから他言語の対応ページへリンクし、対応していない言語の訪問者向けにトップページや言語選択ページにx-defaultを設定します。言語を提案したい場合は、リダイレクトではなく閉じられるバナーで表示します。

本当に重要なhreflangのルール

GoogleはhreflangをHTMLのlinkタグ、HTTPヘッダー、XMLサイトマップのいずれでも受け付け、3つは同等だとしています。1つを選んでください。3つを併用しても検索上の利点はなく、整合性の維持が難しくなるだけです。多くのサイトにはHTMLタグ、大規模サイトにはサイトマップ、PDFなどのファイルにはHTTPヘッダーが向いています。どの方法でも、Googleのドキュメントにある次のルールが適用されます。

  • 各言語版は他の言語版に加えて自分自身も列挙します。そのため、グループ内のすべてのページで同じ注釈のセットになります。
  • リンクは相互でなければなりません。2つのページが互いを指していない場合、Googleはそのタグを無視します。
  • URLはhttps://を含む完全な形式で記述します。/ja/pageのような相対パスは無効です。
  • コードはISO 639-1の言語コードで、必要に応じてISO 3166-1 Alpha-2の地域コードを続けます(ja、fr、fr-CA、en-GBなど)。地域コードだけの指定は無効で、es-419のようにこれらの規格にないコードもサポートされていません。
  • どの言語版にも一致しない訪問者向けにx-defaultを追加します。Googleによると、x-defaultは言語選択ページ向けに設計されたもので、そこで最も効果を発揮します。

hreflangとcanonicalタグの組み合わせ方

バイリンガルサイトで特に深刻な影響が出るミスの1つは、フランス語版や日本語版のcanonicalタグが英語版を指しているケースです。canonicalはどのURLをインデックスすべきかを伝えるものなので、翻訳ページを英語版に向けると、それらを重複として扱い英語版だけを残すよう求めることになります。Googleの正規化ガイドは、hreflangを使う場合は同じ言語の正規ページを指定し、同じ言語のページがなければ最も近い代替言語のページを指定するよう求めています。

実務では、各言語版に自分自身を指すcanonicalと、hreflangの完全なセットを設定します。同じガイドには関連する注意点が2つあります。hreflang属性を付けたcanonicalリンクは正規化に使われないこと、そして正規URLを選ぶ際には相互参照のhreflangクラスターに含まれるURLが優先されることです。またGoogleは、ローカライズ版が重複とみなされるのはメインコンテンツが翻訳されていない場合だけだとしています。

よくあるhreflangのミス:公開前チェックリスト

多くはGoogleが挙げている典型的なミスで、残りは当社がバイリンガルサイトを構築・診断する際に確認している項目です。公開前と、ルーティング、CMS、翻訳プラグインを変更した後に確認してください。

  • 日本語はjaであり、jpではありません。jpは国コードで、Googleは国コードから言語を推定しません。同様に、seはスウェーデン語(sv)ではなく北サーミ語を表し、dkは言語コードですらありません(デンマーク語はda)。
  • 英国はen-GBです。UK、EU、UNのような予約コードはGoogle検索では効果がありません。
  • hreflangに記載したすべてのURLが200を返し、インデックス可能であること。リダイレクト先、404、noindexのページを指していると、クラスターが機能しません。
  • 各ページのcanonicalが既定言語ではなく自分自身を指していること。
  • タグがレンダリング後のHTMLで正しい形式のhead内にあること。head内の不正な要素によってheadが途中で閉じられることがあるため、不安な場合はGoogleが勧めるとおりHTMLバリデーターで確認します。
  • メニューだけ翻訳され本文は英語のままのページを、別言語版としてhreflangに登録していないこと。

検索で評価される翻訳フロー

Googleは、各ページの本文とナビゲーションを1つの言語にそろえ、複数言語を並べて表示しないよう推奨しています。メニューやフッターなどのテンプレートだけを翻訳し本文が1言語のままの状態は、利用者の体験を損なうとも注意しています。さらにスパムポリシーでは、他サイトのコンテンツを取得して翻訳などの自動変換を施したページを「大量生成コンテンツの不正使用」の例に挙げています。機械翻訳は下書きとして有用ですが、レビューせずに数百ページ公開することがリスクになります。

当サイトを含む英日バイリンガルサイトで当社が採用している流れは次のとおりです。

  • キーワード調査は言語ごとに別々に行います。英語のキーワードリストを直訳するのではなく、日本語やフランス語で実際にどんな語句が検索されているかを確認します。
  • すべての言語を同じコンテンツレコード(または紐づいたレコード)で管理し、対応する言語版がhreflangの生成処理に認識されないまま片方だけ公開されることを防ぎます。
  • 本文だけでなく、タイトル、メタディスクリプション、画像のalt、構造化データ、必要に応じてURLスラッグも翻訳します。
  • 製品名や規制関連の用語は用語集で統一し、公開前にその言語に堪能なレビュアーが各ページを承認します。
  • hreflang、canonical、サイトマップのエントリーは、ページごとの手作業ではなく、同じデータからコードで生成します。

アクセシビリティのためのlang属性と、公開後の検証

GoogleはHTMLのlang属性を使いませんが、利用者にとっては重要です。WCAG 2.2の達成基準3.1.1「ページの言語」はレベルAで、スクリーンリーダーが正しい発音ルールを読み込めるよう、各ページの既定の言語をプログラムで判定できる必要があります。3.1.2「一部分の言語」はレベルAAで、英語ページ内の日本語の社名のような別言語の箇所が対象です。順位には影響しなくても、日本語ページにはlang="ja"、カナダのフランス語ページにはlang="fr-CA"を設定します。

公開後は、Search ConsoleのURL検査で各言語のページを抽出してレンダリング後のHTMLを確認し、hreflangに対応したクローラーでサイト全体を巡回して戻りリンクの欠落を見つけ、検索パフォーマンスで国別・言語別の表示回数を比較します。問題は多くの場合、ある市場で別の言語版が表示されるという形で現れます。公開1週目に直すほうが、1年間ちぐはぐなシグナルを送った後よりはるかに簡単です。

著者

Jayson Hao

Innovation Trigger Lab創業者。トロント大学コンピュータサイエンス(AI/ML)出身。RAG、AIチャットボット、Web・モバイルプロダクトの設計と本番導入に携わっています。

プロフィールを見る

よくある質問

hreflangを設定すると順位は上がりますか?

直接的には上がりません。hreflangは、言語や地域に応じて同等のページのどれを表示するかをGoogleに伝えるものです。適切な言語版が表示されるのを助けるもので、競合より上位にするものではありません。

hreflangはenとen-CAのどちらを使うべきですか?

価格や配送条件など内容が地域で実際に異なる場合を除き、言語コードのみ(en、fr、ja)を使います。英語の地域別ページが複数ある場合、Googleは汎用のenページもあわせて用意することを推奨しています。

機械翻訳はSEOに悪影響がありますか?

問題は、レビューされていない翻訳を大量に公開することです。Googleのスパムポリシーは、取得したコンテンツに翻訳などの自動変換を施したものを大量生成コンテンツの不正使用として扱います。機械翻訳は下書きとして使い、その言語に堪能な人が各ページをレビューしてください。

lang属性を設定していればhreflangは不要ですか?

両方必要です。Googleはlang属性を使わないため、検索に言語版を伝えるにはhreflangが必要です。一方、lang属性はスクリーンリーダーやブラウザが利用します。

出典・参考資料

  1. 1.
  2. 2.
    多地域・多言語サイトの管理Google Search Central, 2025年12月10日
  3. 3.
    rel="canonical"などで正規URLを指定する方法Google Search Central, 2026年7月10日
  4. 4.
    Googleウェブ検索のスパムに関するポリシーGoogle Search Central, 2026年8月28日
  5. 5.
    Web Almanac 2025:SEOHTTP Archive, 2026年1月15日
  6. 6.