多言語SEO FAQ：よくある質問と回答

URL、hreflang、canonical、翻訳品質、効果測定、導入方法など、多言語SEOでよくある疑問にわかりやすく回答。GoogleとBingのドキュメントに基づいて解説します。

Grant Davies更新日

多言語SEOのよくある質問：白いグリッド背景に、ロケール別タブと1つのパネルが展開されたFAQアコーディオン

多言語SEOでは、海外展開のたびに同じ疑問が生じます。言語ごとにURLを分ける必要はあるのか。hreflangを設定すれば検索順位は保証されるのか。翻訳だけで十分なのか。このFAQでは、多言語SEOで特によくある質問に、情報源に基づいて簡潔に回答します。根拠のないランキング要因を持ち出したり、AIによる引用を約束したりはしません。

まず結論：多言語SEOは、各言語版の品質とサイト構造の両立が重要

簡潔に言うと：多言語SEOとは、サイトの各言語版を、検索エンジンやユーザーが見つけやすく、理解しやすく、役立つものにする取り組みです。クロール可能なURL、言語が明確なコンテンツ、代替ページがある場合の相互のhreflang指定、そしてユーザーを第一に考えたローカライズによって実現します。

Googleは、Cookieやブラウザの言語設定だけに頼らず、言語版や地域版ごとに異なるクロール可能なURLを用意することを推奨しています。hreflangは代替ページの存在をGoogleに伝えるものであり、ページの言語を検出する機能でも、翻訳品質を補うものでもありません。内容が乏しい言語版や定型文しか翻訳されていない言語版は、SEOの面でも、回答の情報源としても不十分です。

サイト構造とコンテンツ品質は、両方がそろって初めて効果を発揮します。中身のないページにhreflangを完璧に実装しても、有用なコンテンツに求められる水準は満たせません。優れた翻訳を公開しても、切り替えがCookieだけに依存していれば、クローラーから見えなくなることがあります。成果を上げるには、どちらも欠かせない要件として扱う必要があります。

以下の技術的なFAQに進む前に、戦略の全体像を把握するため、国際SEOと多言語SEOの違いをご覧ください。

基本用語

多言語SEOとは何ですか？

多言語SEOは、検索エンジンがウェブサイトの適切な言語版を発見し、理解し、ユーザーに表示できるようにする取り組みです。国際展開に対応したサイト構造、ローカライズしたコンテンツ、技術的なアノテーションを組み合わせることで、フランス語を使う訪問者も英語を使う訪問者も、それぞれの言語に合ったページにたどり着けるようにします。

多言語SEOと国際SEOはどう違いますか？

多言語SEOは、言語版への対応に重点を置きます。国際SEOや多地域SEOでは、それに加えて国別のターゲティングを行うことが多く、たとえばカナダとフランスで異なる体験を提供します。多くのサイトは、多言語と多地域の両方に対応しています。

Googleはどのような情報から言語を判断しますか？

Googleは、主に画面に表示されるコンテンツからページの言語を判断します。各言語版では、コンテンツとナビゲーションを原則として1つの言語に統一してください。HTMLのlang属性、URLパス、hreflangはユーザーやシステムの助けになりますが、Googleのドキュメントで主な判断材料とされているのは、表示されるテキストです。

言語版とロケールの違いは何ですか？

言語版とは、対象言語（フランス語など）で提供されるコンテンツのことです。ロケールは、多くの場合、言語と地域の組み合わせを表します（カナダ向けフランス語：fr-CA）。hreflangコードではどちらも指定できます。URLとコンテンツの戦略は、実際に各市場へどのようにサービスを提供しているかに合わせる必要があります。

URLとサイト構造に関するFAQ

言語ごとに異なるURLが必要ですか？

はい。Googleは、言語版ごとに異なるクロール可能なURLを用意することを推奨しています。Cookieだけ、またはクライアント側だけでの言語切り替えは、その代わりにはなりません。クローラーが各言語版を個別に取得できるよう、それぞれに安定したURLを用意し、ナビゲーション、サイトマップ、内部リンクに含める必要があります。

どのURL構成を選ぶべきですか？

Googleは、一般的な構成としてサブディレクトリ（/fr/）、サブドメイン（fr.example.com）、ccTLD（example.fr）を挙げています。チームが一貫して維持管理できる構成を選びましょう。公開後の構成変更には大きなコストがかかるため、早い段階で決定内容を文書化してください。

CookieやJavaScriptだけで言語を切り替えてもよいですか？

いいえ。それだけを言語版の提供方法にするべきではありません。Googleは、Cookieやブラウザの言語設定だけに頼らず、異なるクロール可能なURLを用意することを推奨しています。単一のURLでJavaScriptによる切り替えを行うと、そのアドレスを取得するクローラーには代替言語版が見えなくなります。言語ごとのURLを用意したうえで、ユーザー体験を向上させるためにJavaScriptを使うことは問題ありません。

IPアドレスやブラウザの言語設定に基づいて自動リダイレクトするべきですか？

Googleは、推測した言語や所在地に基づいてユーザーを自動リダイレクトしないよう勧めています。代わりに、別の言語版や地域版のURLへリンクする、ユーザーに見える言語・国選択メニューを用意しましょう。強制リダイレクトはクローラーのアクセスを妨げ、ユーザーの選択を無視することになります。

各言語版を個別にサイトマップへ登録する必要がありますか？

XMLサイトマップは各言語版の発見を助けます。また、hreflangの実装方法として利用する場合は、xhtml:linkのhreflangアノテーションを含めることもできます。各ロケールのURLをサイトマップに含め、公開後に再送信してください。

hreflangとcanonicalに関するFAQ

hreflangは言語を検出したり、検索順位を保証したりしますか？

hreflangは代替ページの存在をGoogleに伝えるものであり、ページの言語を検出する機能でも、翻訳品質を補うものでもありません。同等のページ間の関係を示すシグナルであって、検索順位を上げるものではありません。アノテーションは相互に指定する必要があります。クラスター内のすべてのURLで、自分自身を含むすべての代替URLを指定してください。

各言語版のcanonicalはどのように設定すべきですか？

各言語・ロケールのURLには、正規URLを明確に指定するcanonicalを設定してください。重複ページがある場合は、同じ言語の優先URLを指定します。各ページを完全にローカライズしているにもかかわらず、すべてのロケールのcanonicalを英語のホームページに向けてはいけません。誤った正規化のシグナルを送ることになります。

hreflangクラスターが機能しなくなる主な原因は何ですか？

戻りリンクの欠落、誤ったロケールコード、HTTPとHTTPSの不一致、canonicalとの競合です。hreflangアノテーションは、対象となるページ群で相互に指定する必要があります。一方向だけのタグ指定や、一部のテンプレートにしか適用されていない実装では、気づかないうちにクラスターが機能しなくなります。

hreflangはHTMLではなくサイトマップに記述してもよいですか？

はい。hreflangの実装方法として、XMLサイトマップにアノテーションを記述できます。サイトごとに主な実装方法を1つ選び、ロケールを変更した際は、相互指定を含む一式をすべて再生成してください。不完全なHTMLタグと不完全なサイトマップの記述を混在させると、指定漏れが生じます。

翻訳とローカライズに関するFAQ

サイトを翻訳するだけでSEO対策として十分ですか？

いいえ。翻訳は必要ですが、それだけでは十分ではありません。クロール可能なロケール別URL、ローカライズしたメタデータ、相互のhreflang指定、同じ言語のURLを指定したcanonical、そしてユーザーを第一に考えたコンテンツが必要です。定型文だけを翻訳した、中身のない言語版では不十分です。

有用なコンテンツに関するGoogleのガイダンスでは、ユーザーを第一に考えたページが重視されています。内容が乏しい言語版や定型文しか翻訳されていない言語版は、SEOの面でも、回答の情報源としても不十分です。ナビゲーションだけを翻訳し、本文を元の言語のままにしてしまうのは、よくある失敗例です。

機械翻訳は多言語SEOに有効ですか？

機械翻訳は下訳の作成を効率化できますが、人の確認を経ずにそのまま公開すると、内容が乏しいページや複数の言語が混在するページになりがちです。翻訳方法にかかわらず、編集レビュー、用語集の活用、ロケールごとの品質確認をワークフローに組み込む必要があります。

すべての英語ページに翻訳版を用意するべきですか？

実際に同等の内容を公開する場合に限ります。内容がほとんどないページをhreflangで対応付けると、信頼を損ないます。対応するページをきちんと翻訳するか、準備が整うまでその関係の指定を見送ってください。

複数の言語が混在するページはどうすればよいですか？

言語の判定を混乱させるような、2言語を併記するページは避けましょう。各URLでは、コンテンツもナビゲーションも原則として1つの言語に統一してください。

効果測定に関するFAQ

多言語SEOの成果はどのように測定すればよいですか？

サイト全体の集計値だけでなく、ロケールごとに測定しましょう。

  • インデックス登録 — ロケール別のフォルダやサブドメインごとに、Search ConsoleのカバレッジとURL検査を確認します。
  • 検出 — 各言語のURLについて、サイトマップのステータスとクロールの統計情報を確認します。
  • 品質 — ページを抜き取り確認し、言語の混在、内容の薄さ、hreflangの不備をチェックします。
  • エンゲージメント — 利用可能な場合はロケールで絞り込んだアクセス解析を使い、市場の成熟度を考慮して公平に比較します。

Bing Webmaster Guidelinesでも、各市場でのインデックス登録に向けて、クロール可能で有用なコンテンツと明確なサイト構造が重視されています。Bing経由のトラフィックについても、Bing Webmaster Toolsで同様のモニタリングを行いましょう。

各言語版の確認には、Search Consoleのどのレポートが重要ですか？

ページレポート、インデックス登録のカバレッジ、サイトマップのステータスに加え、ロケール別URLを抜き取ってURL検査を行います。サブディレクトリを使う場合は、URLパスのプレフィックスで絞り込みやセグメント分けを行ってください。hreflangのエラーは、検索順位へのペナルティではなく、ページ間の対応関係の不具合として扱います。

hreflangはどのくらいの頻度で監査すべきですか？

新しいロケールの公開、CMSでの一括編集、URL構造の変更を行うたびに監査します。主要なテンプレートを四半期ごとに抜き取り確認すれば、設定のずれが広がる前に発見できます。

回答エンジンとAI検索に関するよくある質問

回答エンジンはhreflangの代わりになりますか？

いいえ。ChatGPT、Gemini、Google AI Overviewsは、インデックス登録可能なページを参照したり要約したりすることがありますが、Google検索に必要な、クロール可能なロケール別URLや相互参照するhreflangの代わりにはなりません。技術的な基盤は、引き続き言語ごとに独立した、アクセス可能なHTMLを用意することから始まります。

AIに引用されやすくするには、FAQをどのように構成すべきですか？

質問を明確な見出しにし、最初に短く端的な回答を示してから、補足の詳細を続けます。用語集に基づいて用語を統一すると、AIアシスタントがロケールをまたいで同じエンティティを認識しやすくなります。統計を捏造したり、引用されることを約束したりしないでください。

FAQを翻訳すれば、AIでの露出は保証されますか？

掲載を保証すると明記しているプラットフォームはありません。ユーザーを第一に考え、回答として使いやすく整えたコンテンツは可能性を高めますが、内容の薄い翻訳ページでは効果は期待できません。AIでの露出は定性的に評価し、従来のインデックス登録指標とは分けて管理してください。

導入に関するよくある質問

すでに1つの言語でサイトを公開している場合、何から始めればよいですか？

  1. 現状を監査する — 既存のURL、言語判定の問題、Cookieのみに依存した言語切り替えを洗い出します。
  2. URL形式を選ぶ — サブディレクトリ、サブドメイン、ccTLDのいずれかを選び、ロケールコードを文書化します。
  3. ロケール対応表を作成する — 大規模な翻訳に着手する前に、元のページと対象ロケールのURLを対応づけます。
  4. まずクロール可能にする — 言語ごとに独立したURLと、見つけやすい言語セレクターを用意し、強制的な自動リダイレクトは行わないようにします。
  5. まず1つのロケールを確実に公開する — 相互参照するhreflang、ローカライズしたメタデータ、サイトマップへの登録、品質保証のチェック工程を整えます。
  6. プロセスを整えて展開する — 翻訳をまとめて進める単位ごとに、用語集の整備、レビュー、Search Consoleでのモニタリングを行います。

導入時には、翻訳量だけでなく、hreflangの管理や編集ワークフローにチームが必要とする多言語SEOプラットフォームの機能も組み合わせてください。

すべてを一度に翻訳すべきですか？

通常はおすすめしません。まずは、ホームページ、製品、料金、サポートなど、利用者の目的が明確なページのテンプレートを優先し、その後でブログやロングテール向けコンテンツへ広げます。市場を「押さえる」ために内容の薄いロケール別ページを公開すると、hreflangやサイトマップ全体に技術的負債が生じます。

多言語SEOは誰が担当すべきですか？

SEO、エンジニアリング、ローカライズの各担当がロケール対応表を共有する必要があります。SEO担当はアノテーションとモニタリング、エンジニアリング担当はURLルーティングとレンダリング、ローカライズ担当はコンテンツ品質と用語集の管理を担います。

実装チェックリスト

各言語版の公開や監査には、次のチェックリストを活用してください。

従来の検索と回答エンジンに共通する基盤

Google、Bing、回答エンジンのいずれでも、共通の基盤は引き続き重要です。クロール可能な各言語版、明確なエンティティ、根拠のある主張、実態に即した構造化データ、そして英語のままの外枠ではなく、実質的なローカライズが求められます。以下のガイドは、同じ多言語配信の基準をプラットフォーム別の視点から捉えたものとして活用してください。

Google検索でページが検出されるには、各言語に適したHTMLを備えたクロール可能なロケール別URL、正確なタイトルと見出し、そして代替ページがある場合は相互参照するhreflangが必要です。技術的な基盤には、Cookieのみに依存した言語切り替えではなくインデックス登録可能なコンテンツ、ローカライズされたメタデータ、サイトマップ、適切なcanonical管理が含まれます。コンテンツ品質とは、各言語でユーザーを第一に考えたメインコンテンツを提供することです。権威性は、組織の明確な身元と裏付けとなる情報源から生まれるものであり、翻訳ツールの宣伝から生まれるものではありません。多言語対応で重要なのは、市場別・言語別の各URLが単独で成立することです。Search ConsoleのカバレッジとURL検査を使い、ロケールごとに測定してください。確かな点と不確かな点を区別しましょう。Googleは多言語対応とhreflangの動作を文書化していますが、特定のCMSや翻訳ワークフローによる検索順位の向上を保証してはいません。

プラットフォーム別ガイド：Bing

Bingは、GoogleがURLやコンテンツの明確さに求めるものと同様に、構造が明確でクロール可能な多言語ページを検出し、インデックスに登録します。技術的な基盤には、取得可能なロケール別URL、有用なコンテンツ、Bing Webmaster Toolsでの監視が含まれます。UI要素だけを翻訳するのではなく、見出し、主張、FAQのローカライズを優先してください。権威性を示す要素としては、引き続き信頼できる情報源と一貫したエンティティが重要です。多言語対応では、クライアント側だけで動作する切り替え機能の背後に各言語版を隠さないでください。Bing Webmaster Toolsでインデックス登録状況とクロール統計を測定しましょう。確かな点と不確かな点：Bingのガイドラインは、クロール可能で有用なコンテンツを重視しています。翻訳ツールに関して、Bing独自のランキング要因を根拠なく想定しないでください。

プラットフォーム別ガイド：ChatGPT

各言語版が明確に区別され、回答として使いやすく整っていれば、ChatGPTは一般公開されたページを引用したり要約したりすることがあります。ページの検出は従来のクロールに基づくランキングとは異なり、情報源として選ばれたり、回答内で参照されたりすることが露出に当たります。技術的な基盤は、引き続きアクセス可能なHTMLのURLです。本文を隠してしまうウィジェットのオーバーレイではありません。役立つコンテンツの特徴として、端的な回答、FAQ、用語集に基づく一貫した用語の使用が挙げられます。権威性は、根拠と、ロケールをまたいだエンティティの一貫性から生まれます。多言語対応では、各ロケールのページが単独で読んで理解できることが重要です。測定は完全ではないため、引用の確認結果は仮説として扱ってください。確かな点と不確かな点を区別しましょう。特定の翻訳ワークフローによってChatGPTに引用されるという、文書化された保証はありません。

プラットフォーム別ガイド：Gemini

Geminiと関連するGoogleのAIサービスでは、一貫したエンティティ、正確な構造化データ、インデックス登録可能なローカライズ済みページが役立ちます。可視性とは、参照・認識されることであり、Gemini独自のランキング要因を根拠なく想定することではありません。技術的な基盤は、Google検索のクロール可能性やメタデータの品質と共通しています。コンテンツでは、各言語で主張や定義を明確に示す必要があります。権威性は、組織情報の一貫性と裏付けに左右されます。多言語対応では、用語集で製品名を統一することで、ロケール間の混乱を減らせます。従来どおりSearch Consoleで測定しつつ、AIの回答を抽出して定性的にも確認してください。確かな点と不確かな点：Geminiの挙動は、hreflangや各言語版に関するGoogle検索の公式ガイダンスの代わりにはなりません。

プラットフォーム別ガイド：Google AI Overviews

Google AI Overviewsは、回答の裏付けとなるページへのリンクを表示することがあります。掲載対象となるための基本は、引き続きユーザーを第一に考えた、インデックス登録可能なコンテンツです。AI Overviewsは言語切り替え機能ではなく、hreflangの代わりにもなりません。技術的な基盤は、クロール可能なロケール別HTMLと、事実に即した構造化データです。コンテンツ面では、各言語での簡潔な回答と明確な見出しが重要です。権威性の評価も、有用なコンテンツに求められる水準に沿ったものです。多言語対応では、翻訳されたページがAI Overviewsに掲載される保証はありません。Search Consoleで生成AI関連のレポートが利用できる場合はそれを使って測定し、従来のインデックス指標とは分けて管理してください。確かな点と不確かな点：どのような翻訳ワークフローでも、AI Overviewsへの掲載を約束することはできません。

GlotEOが担う役割

hreflang、用語集の管理、レビュー待ち案件の処理が日常業務になると、スプレッドシートのロケール対応表だけでは対応しきれなくなります。GlotEOは翻訳ワークフローと多言語SEOプラットフォームのガバナンスを結びつけ、マーケティング担当者やSEO実務者がアノテーションを適切に管理しながら、クロール可能な各言語版を公開できるようにします。

対応ロケールを少数からさらに増やす際は、GlotEOの料金とプランを比較してください。また、FAQの取り組みを拡大する際も、国際SEOと多言語SEOの違いの基本を踏まえた戦略を維持しましょう。

参考文献