Next.jsサイトの翻訳：クロール可能な言語別ルートとSEO

Cookieだけに頼る言語切り替えを避け、パスベースの言語別URL、ローカライズしたメタデータ、hreflang、継続的に管理できる用語集のワークフローで、Next.jsサイトを翻訳する方法を解説します。

Grant Davies更新日

Next.jsサイトの翻訳：白いグリッド上に、[locale]ノードからページへとつながるNext.js App Routerのフォルダーツリー

Next.jsサイトの翻訳は、i18nライブラリを導入するだけでは完結しません。検索エンジンには、言語ごとに独立したクロール可能なURLが必要です。また、最初のHTMLレスポンスにメタデータと本文がレンダリングされている必要があります。単一のURLでCookieによるロケール切り替えやクライアント側だけの切り替えを行っても、Googleが言語別にインデックス登録できるページは用意されません。

App Routerのセグメントについて詳しく見る前に、一つだけ押さえるなら、言語ごとに独立したクロール可能なURLを用意することです。Googleは、Cookieやブラウザーの言語設定だけに頼るのではなく、言語や地域ごとに異なるURLを使用することを推奨しています。/en/や/de/のようなパスプレフィックス、専用サブドメイン、別ドメインのいずれでも、インデックス登録可能なアドレスを作れます。単一のURLでCookieだけを使って切り替えても、それは実現できません。

Cookieによるロケール切り替えは、ルートを重複して作らずに済むため、開発中は便利に感じられます。しかし、本番環境のSEOでは、この方式は別言語版をクローラーから見えなくしてしまいます。パスベースのロケールなら、サイトマップへの掲載、hreflangの指定、Search Consoleでの監視に使える安定したURLを公開できます。市場別戦略と言語別戦略の違いについて詳しくは、国際SEOと多言語SEOの違いのガイドをご覧ください。

Next.jsで言語別URLの形式を選ぶ

Next.jsを使うチームは通常、クロール可能な次の3つの形式から1つを選びます。

  1. サブディレクトリ — example.com/en/docs、example.com/fr/docs。単一のホストにデプロイしやすく、hreflangの設定でも階層が明確です。
  2. サブドメイン — en.example.com、fr.example.com。地域ごとのチームがある程度独立して運営する場合に便利ですが、相互のhreflang指定は必要です。
  3. ccTLDまたは専用ドメイン — 実際に別々のサイトを運営する場合、地理的な対象を示すシグナルが最も強くなりますが、運用負荷も最も高くなります。

Googleは、主に画面に表示されるコンテンツからページの言語を判断します。どの形式を選ぶ場合も、ナビゲーション、フッターのリンク、エラーページを含め、各URLのコンテンツは基本的に1つの言語で統一してください。ユーザーにとって明確な理由がない限り、同じテンプレート内で複数の言語を混在させないようにしましょう。

推測した言語や所在地に基づいて、訪問者を自動的にリダイレクトしないでください。クローラーのアクセスを妨げたり、ユーザーに不便を与えたりする可能性があるため、Googleはこの動作を推奨していません。代わりに、別ロケールのURLへリンクする、見つけやすい言語選択メニューを用意してください。

App Routerとロケールセグメントの設計

App Routerでは、動的な[locale]セグメントを使うのが一般的です。app/[locale]/layout.tsxの配下にローカライズされたページを配置します。対応ロケールは1つの設定オブジェクトに定義し、レイアウトまたはミドルウェアでparams.localeを検証してください。無効なロケールでは、同じURLのまま黙って英語にフォールバックするのではなく、404を返すべきです。

ミドルウェアを使えば、ロケール指定のない/から/en/のようなデフォルトロケールのフォルダーへリダイレクトできます。ただし、別ロケールへのリンクは維持してください。マーケティングページを静的生成する場合は、ミドルウェアとgenerateStaticParamsを組み合わせ、各ロケールを事前にビルドします。

Cookieベースとパスベースのロケールの違い：単一のURLでCookieやヘッダーによってロケールを判定すると、アドレスを変えずにコンテンツだけが変わります。クローラーは通常、1つのURLを1回取得するため、すべての言語版を確認できるわけではありません。パスベースのロケール、またはサブドメインやドメインを分ける同等の方式は、異なるURLを使うというGoogleの指針に沿っています。公開URLがそれぞれ独立していれば、ユーザーが言語を選択した後に、その設定をCookieに保存することは可能です。

メッセージの読み込みにはnext-intlやnext-i18nextなどのライブラリを使い、公開URLはCookieだけではなくルーティングで決定してください。

メタデータ、Open Graph、構造化データをローカライズする

各ロケールのルートには、サーバーでレンダリングするHTML内に、そのロケール専用の<title>、メタディスクリプション、canonical、Open Graphタグが必要です。App Routerでは、ページごとにgenerateMetadataを使い、メッセージファイルから翻訳済みの文字列を読み込みます。ローカライズされたタイトルとメタディスクリプションを、ハイドレーション後のクライアント側での言語切り替えに依存させてはいけません。

JSON-LDにも同じ方針を適用してください。WebPage、Organization、FAQの各ブロックでは、翻訳済みの文字列と、ロケールに適したinLanguageの値を使います。hreflangのlink要素を出力する場合は、レイアウトまたはページのメタデータヘルパーで、相互参照を網羅した一式を生成してください。戻りリンクが欠けると、hreflangのクラスターが正しく機能しなくなります。

Next.jsのhreflang、canonical、サイトマップ

hreflangは、別の言語や地域向けのURLをGoogleに伝えます。クラスター内のすべてのURLは、自分自身を含む全メンバーを、整合するコードで参照する必要があります。hreflangは、<head>、HTTPヘッダー、またはxhtml:linkエントリを使ったXMLサイトマップに実装できます。サイトごとに1つの方法を選び、統一してください。

各ロケールのURLには、重複ページが存在する場合に、その言語の優先URLを指すcanonicalも必要です。たとえば、トラッキングパラメーター付きのURLや印刷用ページが該当します。フランス語のページのcanonicalを対応する英語ページに向けないでください。canonicalは、同じ言語内の重複を統合するためのものです。

ロケールごとのサイトマップ、またはすべての言語のURLを網羅する単一のサイトマップインデックスを生成します。サイトマップはページの発見を促し、hreflangの指定も含められます。デプロイ後は、Search ConsoleのURL検査とhreflangのテスト手順を使って、サンプルを確認してください。多言語SEOプラットフォームの概要では、SEOチームがロケールを横断してこれらのシグナルを監査する方法を解説しています。

クライアント側だけで言語を切り替えるHTMLの土台を避ける

Next.jsでよくある落とし穴は、英語のHTMLを土台としてレンダリングし、その後useEffectで文字列を差し替えることです。クローラーがこの差し替えを確実に実行するとは限らず、ユーザーには一瞬、意図しない言語が表示されます。Server Components、静的生成、またはSSRを使い、最初のレスポンスに翻訳済みのテキストを含めてください。Client Componentsでインタラクティブな部分をハイドレーションすることはできますが、マーケティング用の文章や見出しはサーバー側のコンポーネントツリーに配置すべきです。

パスまたはサブドメインに基づくロケール別ルートは、独立したクロール可能なURLを作ります。Cookieだけのロケール切り替えでは、Googleの推奨事項を満たせません。プレビューに翻訳プロキシを使う場合も、本番環境では各ロケールのURLで完全なHTMLが配信されることを確認してください。

コンテンツのワークフロー：用語集、翻訳メモリ、レビュー

翻訳が製品の用語からずれてしまうと、技術的な実装を工夫しても市場では成果につながりません。Next.jsのi18nファイルに加えて、用語集、翻訳メモリ（TM）、人によるレビューを組み込んでください。Googleの有用なコンテンツに関する指針では、ユーザーを第一に考えたページが重視されています。内容が乏しい言語版や定型文だけの言語版は、SEOの面でも、回答の情報源としても弱いものになります。

ワークフローの概要：

  • JSONまたはPOファイルから文字列を抽出し、翻訳支援（CAT）ツールで扱いやすいパイプラインに取り込む。
  • 製品名やUIラベルには、用語集で定めた用語を必ず使う。
  • ソースファイルの差分を確認するだけでなく、ステージング環境のURLで言語面の品質チェックを行う。
  • 英語の原文が変更されたら再同期する。更新されないままの言語版は信頼を損ないます。

実装チェックリスト

公開前に、クロール経路、メタデータ、アノテーションを確認しましょう。

Bing Webmaster Guidelinesでも、クロール可能で有用なコンテンツと明確な構造が重視されています。Googleに有効な実装は、一般にBingのインデックス登録にも役立ちます。

よくある間違い

単一URLでCookieだけを使うロケール切り替え — 別言語版がクローラーから見えなくなります。

hreflangの戻りリンクの欠落 — 相互参照が成立せず、クラスターとしての関連付けが弱まります。

翻訳済みページから英語版を指すcanonical — 統合先について誤ったシグナルを送ります。

クライアント側だけのメタデータ — 最初のHTMLにタイトルやディスクリプションが含まれません。

IPアドレスやAccept-Languageによる自動リダイレクト — クローラーをブロックし、ユーザーの選択を無視します。

未翻訳のUI要素 — ナビゲーションに複数の言語が混在すると、言語の判定に支障が生じます。

レビューを経ていない、質の低い機械翻訳 — 有用なコンテンツとして求められる水準を満たせません。

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

Next.jsのロケール別ルートとサーバーレンダリングされたHTMLの共通基盤は、Google、Bing、回答エンジンのいずれでも引き続き重要です。具体的には、クロール可能な各言語版、明確なエンティティ、根拠のある主張、事実に即した構造化データ、そして英語だけの枠組みにとどまらない本格的なローカライズが求められます。以下のガイドは、同じ多言語配信の要件をプラットフォームごとの視点で捉えるものとして活用してください。

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が担う役割

Next.jsの国際化（i18n）は、小規模サイトなら独自実装でも対応できますが、規模が大きくなると、用語集の管理、レビューキュー、各ロケールのSEO検証が必要になります。GlotEOはモダンな技術スタックと連携し、エンジニアがApp Routerの構造を維持しながら、マーケティング担当者が翻訳を管理できるようにします。

ローカライズを単なる文字列の置き換えではなく、ルーティングとコンテンツ品質の課題として捉えるチームは、クロール経路を壊さずに、より速く改善を重ねられます。翻訳者が作業を始める前に用語集を共有し、ステージング環境で実際のページの文脈に沿ってレビューし、ルートを追加するたびにhreflangを再確認してください。インデックス登録状況は、サイト全体の集計だけに頼らず、Search Consoleでロケール別のフォルダまたはサブドメインごとに測定しましょう。

導入範囲を検討する際は、GlotEOのウェブサイトローカライズでプラットフォームの詳細を確認し、GlotEOの料金とプランを比較してください。

参考文献