Reactウェブサイトの翻訳：i18nライブラリだけでは実現できない、クロール可能な多言語対応

Reactのi18nライブラリは文字列の読み込みを担いますが、多言語SEOには、ロケールごとに異なるURLでインデックス可能なHTMLを提供する必要があります。単一のSPAルートでクライアント側のみの言語切り替えを行うと、Googleが別言語版を認識できず、ハイドレーション時に別の言語が一瞬表示されることもよくあります。

結論：ロケール別URLでインデックス可能なHTMLを配信する

Reactサイトを検索エンジンに対応させて翻訳するには、ロケールごとに固有のURLで完全なHTMLを配信します。Googleは、Cookieやブラウザの言語設定だけに依存せず、言語ごとにクロール可能な異なるURLを用意することを推奨しています。react-i18nextなどのライブラリは必要ですが、それだけでは不十分です。ルーティングとレンダリングの戦略も欠かせません。

JavaScriptによる言語判定後にしか主要コンテンツが表示されない場合、クローラーは完全な言語版を取得できない可能性があります。SSR、SSG、プリレンダリング、またはメタフレームワーク（Next.js、Remix）で、この問題を解消できます。

SPAの言語切り替えがSEOでうまく機能しない理由

従来のcreate-react-app製SPAは、最小限のindex.htmlを配信し、クライアント側で翻訳済み文字列をハイドレーションします。クローラーは1つのURLを取得するだけで、すべての言語分岐を確実に実行するわけではありません。各言語版には、それぞれクロール可能なURLが必要です。単一URLでのクライアント側のみの切り替えは、Googleの多言語サイト向けガイダンスに沿いません。

公開マーケティングページでも、/app/dashboardでURLを変えずにCookieやlocalStorageでロケールを管理すると、同じ問題が起こります。JavaScriptによる言語判定の後に主要コンテンツが挿入されると、インデックス登録に支障が出ます。

推定した言語に基づく自動リダイレクトは避けましょう。代わりに、/en/pricingと/de/preiseにリンクする、目に見える言語セレクターを用意します。戦略の背景については、国際SEOと多言語SEOの違いをご覧ください。

Reactのロケール別ルーティングパターン

React Router（またはフレームワークのルーター）を使い、ロケールのプレフィックスを付けます。

• /en/products, /fr/produits
• 同じルートツリーに対応付けるサブドメインルーティング
• 静的サイトではロケールごとに個別にビルド

Googleは表示されるコンテンツからページの言語を判定します。ナビゲーションやフッターも含め、各ルートのコンテンツは基本的に1つの言語に統一しましょう。わかりやすさのため、可能であればURLスラッグもロケールに合わせます。

SSR・SSG・プリレンダリングの選択肢

公開ページでは、ハイドレーション前のHTMLレスポンスに翻訳済みテキストが含まれている必要があります。インタラクティブな部分にはクライアントコンポーネントを使えますが、価値提案や見出しはサーバー側、またはプリレンダリング時に描画すべきです。

メタデータと構造化データのローカライズ

ロケール別ルートごとに、<title>、メタディスクリプション、canonical、Open Graph、Twitterタグを設定します。SSRでReact Helmetを使う場合は、サーバー側でタグを出力します。Next.jsではgenerateMetadataを使います。ローカライズしたタイトルとメタディスクリプションを、クライアント側の差し替えに依存させてはいけません。

構造化データ（WebSite、Product、FAQ）では、各フィールドの翻訳と正しいinLanguageが必要です。JSON-LDは表示されるテキストと一致させましょう。不一致はクローラーとユーザーの混乱を招きます。

hreflangとcanonical

各ルートのドキュメントのhead内にhreflangのlink要素を追加し、自分自身も含めたすべての言語・地域別URLを列挙します。同じグループ内のページでは、hreflangで相互に参照する必要があります。重複ページが存在する場合、canonicalタグは同じ言語内の優先URLを指すようにします。

SPAのルート数が多い場合は、ビルドスクリプトやサイトマップのxhtml:linkエントリでhreflangを生成します。SEOに最適化された多言語サイトのガイドでは、監査用チェックリストを紹介しています。XMLサイトマップはページの発見を助け、hreflangの注釈も含められます。

i18nライブラリを補完するコンテンツワークフロー

ライブラリはキーを管理しますが、用語集や翻訳メモリ（TM）の適用、レビューまでは担いません。翻訳プラットフォームやCATツールのワークフローを組み合わせましょう。

• JSON／POファイルを定期的にエクスポート
• 用語集で製品用語の表記を固定
• ロケール別のステージングURLでレビュー
• 英語の原文が変わったら再エクスポート

Googleの有用なコンテンツに関するガイダンスは、ユーザーを第一に考えたページを重視しています。ルーティングが正しくても、中身の乏しいロケール別ページでは、この基準を満たせません。

実装チェックリスト

• すべての公開ルートにロケール別の固有URLを用意
• マーケティングページのHTMLにSSR・SSG・プリレンダリングを使用
• 初期レスポンスにローカライズ済みメタデータを含める（ページのソース表示で確認）
• 相互参照するhreflangとロケール別のcanonicalを設定
• ロケール別URLを含むサイトマップをSearch Consoleに送信
• 目に見える言語セレクターを設置（IPによる自動リダイレクトは行わない）
• ハイドレーション時に英語が一瞬表示されないことをテスト
• 主要ページに用語集を適用し、レビューを実施

Bingのウェブマスター向けガイドラインも、クロール可能で役立つコンテンツと明確な構造を重視しています。

よくある間違い

ロケール別ルートのないi18n — URLが1つだけでは、別言語版が認識されません。

Helmetをクライアント側でのみ実行 — ページのソースではタイトルが空のまま。

翻訳版のルートで英語版をcanonicalに指定 — 誤ったシグナルを送ってしまう。

Accept-Languageによる自動リダイレクト — クローラーの巡回やユーザーの利用を妨げる。

ナビゲーションなどの共通部分が未翻訳 — 複数の言語が混在するシグナルに。

ホームページだけをプリレンダリング — 下層ページは依然としてボットには空白に見える。

機械翻訳をレビューせずに公開 — 各言語版のコンテンツの質が不十分に。

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

クライアント側だけの言語切り替えではなく、SSR／SSGを用いてReactサイトの言語別URLを提供するための共通の基盤は、Google、Bing、回答エンジンのいずれにおいても重要です。クローラーが巡回できる各言語版、明確なエンティティ、根拠のある主張、内容を正確に反映する構造化データ、そして英語だけの共通部分を残さない、本格的なローカライズが求められます。以下のガイドは、この共通の多言語配信基準をプラットフォームごとの視点から解説するものとしてご活用ください。

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

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

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

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

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

ChatGPTは、各言語版が明確で、回答に活用しやすい公開ページを引用または要約することがあります。情報の発見は従来のクロールに基づく順位付けとは異なり、可視性は情報源として選ばれたり、回答内で参照されたりする形で現れます。技術的な基盤は、やはりアクセス可能なHTMLのURLです。テキストを隠してしまうウィジェット型のオーバーレイではありません。コンテンツ面では、直接的な回答、FAQ、用語集に基づく一貫した用語が役立ちます。権威性は、根拠と、ロケールをまたいだエンティティの一貫性から生まれます。多言語対応では、各ロケールのページが単独で読んで理解できる必要があります。測定は完全ではないため、引用状況の確認は仮説の検証として扱ってください。確かな点と不確かな点：MTPEや特定のCMS連携によって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が担う役割

JSONファイルの差し替えにとどまらず、多言語対応を拡大するReactチームには、用語集の管理、レビュー、SEOの検証が必要です。GlotEOはモダンな技術スタックと連携しながら、言語別ルーティングの管理はエンジニアの手元に残します。Reactサイトの多言語展開を計画する際は、AIによるウェブサイト翻訳・ローカライズとウェブサイト翻訳の料金をご覧ください。