# General Translation Knowledge Base: ウェブサイトを多言語化するにはどうすればよいですか？
URL: https://generaltranslation.com/ja/kb/make-website-multilingual.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: 翻訳をどこで管理するか（プロキシ、CMSプラグイン、サイトビルダー、または自前のコード）を選び、Googleの推奨どおり言語ごとに専用のURLを用意します。ページ全体に加えてタイトルとメタディスクリプションも翻訳し、hreflangで各言語版を関連付けます。また、訪問者を自動でリダイレクトするのではなく、言語切り替え機能を設置しましょう。
Category: 国際化
Last updated: 2026-10-20
Authors: Kevin Wu, Jackie Chen
Published: 2026-10-20

多言語ウェブサイトでは、各ページを複数の言語で提供し、言語版ごとに専用のURLで公開したうえで、それらの関係を検索エンジンに伝えます。各アプローチの主な違いは翻訳済みテキストをどこで管理するかにあり、それによってSEO、品質、更新をどこまで自分でコントロールできるかが決まります。そのため、翻訳に着手する前に、まずアプローチを決めましょう。

## Video

The video is narrated in English, with English captions.

[How do I make a website multilingual?](https://caxecubb9c64cezv.public.blob.vercel-storage.com/films/kb-make-website-multilingual.mp4) (50 秒)

Pick where translations live, in a proxy, CMS plugin, site builder, or your own code, then give each language its own URL, as Google recommends. Translate full pages plus titles and meta descriptions, link the versions with hreflang, and offer a language switcher instead of auto-redirecting visitors. For sites built in code, wrap markup in `<T>` and run `npx gt translate` before the build.

## どのアプローチを選ぶべきか

最も手軽な選択肢は、こちら側の作業が一切不要なものです。訪問者のブラウザ自体がページを翻訳できます。たとえば [Chrome](https://support.google.com/chrome/answer/173424) は、読者の言語設定に応じて Google Translate でページを翻訳します。これは個々の読者には役立ちますが、サイトが多言語化されるわけではありません。インデックス対象となる言語別 URL は存在せず、翻訳結果をレビューすることもできません。できる調整は、ブランド名などのテキストに [`translate="no"`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/translate) 属性を付けることくらいです。

翻訳プロキシや JavaScript オーバーレイは、完成済みのサイトの前段に配置されます。[Weglot のリバースプロキシ](https://weglot.com/technical-presentation/)はページを取得し、Weglot の API でコンテンツを翻訳したうえで、hreflang を付加して言語別のサブドメインまたはサブディレクトリで配信します。一方、JavaScript インテグレーションでは、ページの読み込み後にブラウザ内で翻訳を挿入します。Weglot によれば、この方法で挿入された翻訳は検索エンジンに検出されないため、このモードはテストや非公開コンテンツ向けとされています。いずれの場合も、翻訳はベンダーのダッシュボードで管理されます。

CMS プラグインやサイトビルダーは、翻訳をプラットフォーム内に保持します。WordPress の場合、[WPML](https://wpml.org/documentation/getting-started-guide/language-setup/language-url-options/) は言語をディレクトリ、言語ごとのドメインまたはサブドメイン、あるいは `?lang=` パラメータで切り分けます。[Polylang](https://wordpress.org/plugins/polylang/) は URL 内の言語コード、または言語ごとのサブドメインやドメインから言語を判定します。[Webflow Localize](https://webflow.com/localization) は `/es/` のようなサブディレクトリでロケールを配信し、メタタイトルとディスクリプションを翻訳するほか、hreflang タグ付きのサイトマップも生成します。Squarespace の多言語設定は、バージョン 7.1 のサイトで [Weglot を接続](https://support.squarespace.com/hc/en-us/articles/205809778-Creating-a-multilingual-site-with-Weglot)する仕組みです。Squarespace 上では翻訳を直接編集できないため、編集は Weglot で行います。

静的サイトジェネレーターや i18nライブラリは、翻訳をリポジトリ内に保持します。[Docusaurus](https://docusaurus.io/docs/i18n/introduction) は翻訳済みファイルを `i18n/[locale]/` 配下に保存し、hreflang ヘッダーを自動で設定します。[Hugo](https://gohugo.io/content-management/multilingual/) は `about.fr.md` のようなファイル名の接尾辞やコンテンツディレクトリからページの言語を判定し、`/fr/` のようなプレフィックス配下で配信します。React、Next.js、Vue で構築したアプリでは、i18next や next-intl などのライブラリが、自分で管理するファイルから翻訳をレンダリングします。ただし、いずれも翻訳そのものは生成しません。翻訳は自分で書くか、外部に発注するか、翻訳ツールを接続して用意する必要があります。

| アプローチ                                   | 翻訳の保存場所                          | SEO の制御                                                   | 品質管理                                | エンジニアリング工数                                           | 最適な用途                            |
| --------------------------------------- | -------------------------------- | --------------------------------------------------------- | ----------------------------------- | ---------------------------------------------------- | -------------------------------- |
| ブラウザ翻訳                                  | 各訪問者のブラウザで生成                     | なし (言語別 URL なし)                                           | `translate="no"` 以外なし               | なし                                                   | ローカライズされていないサイトの読者               |
| プロキシまたはオーバーレイ (Weglot)                  | ベンダーのダッシュボード                     | プロキシモードでは言語別 URL と hreflang を追加。JavaScript モードはインデックスされない | 機械翻訳のうえ、ベンダーのエディターで編集するか人手による翻訳を発注  | DNS の変更またはスクリプトタグの追加                                 | 作り直したくない完成済みサイト                  |
| CMS プラグイン (WPML, Polylang)              | WordPress のデータベース                | URL 形式と言語切り替え機能をプラグインで設定                                  | WordPress 内での手動翻訳、機械翻訳、または翻訳会社による翻訳 | プラグインのセットアップと、ページごとの作業                               | WordPress サイト                    |
| サイトビルダー (Webflow Localize, Squarespace) | ビルダー内 (Squarespace の場合は Weglot)  | ビルダーが管理                                                   | 機械翻訳と手動編集                           | 少ない                                                  | そのビルダーで構築・ホストされたサイト              |
| 静的サイトジェネレーターの i18n (Docusaurus, Hugo)   | リポジトリ内のファイル                      | 完全に制御可能 (URL とテンプレートを自分で管理)                               | ファイルの作成プロセス次第                       | 中程度 (翻訳は別作業)                                         | Markdown から構築するドキュメントやコンテンツサイト   |
| General Translation                     | ビルドに含まれる生成ファイル、または GT の CDN      | ルーティングとメタデータを自分で管理。`gt-next` がロケールルーティング用のヘルパーを提供         | コードから導出される文脈、共有用語、組み込みのレビュー機能       | 原文へのマーク付けまたは既存カタログの接続、ビルド前の生成、ロケールのテスト               | レンダリングだけでなく翻訳の生成も必要な、開発者が管理するサイト |
| i18nライブラリ単体 (i18next, next-intl)        | リポジトリ内の翻訳ファイル                    | 完全に制御可能                                                   | ファイルの作成プロセス次第                       | 文字列の抽出、ルーティング、翻訳の配信、QA (既存のインテグレーションで一部を自動化できる場合あり)  | 翻訳ワークフローが既にあるアプリ                 |

マーケティングチームがサイトを再ビルドせずに翻訳済みページを用意したい場合は、プロキシまたはサイトビルダーの機能を使用してください。WordPressの場合はCMSプラグインを使用します。開発者がサイトを管理しており、翻訳もすでに用意されている場合は、静的サイトジェネレーターのi18n機能またはi18nライブラリを使用してください。リリースの一環として翻訳の更新を生成し、レビューまで行いたい場合は、General Translationを選択してください。General TranslationのCLIなら、既存のライブラリを置き換えることなく既存のファイルを翻訳できます。必要な作業量は、既存のルーティング、コンテンツ、レビュープロセスによって異なります。表に記載しているのは作業内容であり、実測したセットアップ時間ではありません。

## どのアプローチでも避けて通れないステップ

どのアプローチを選ぶにしても、次の7つの点を、おおむねこの順序で決めていく必要があります。

### 1. 言語とロケールを選ぶ

まずは、すでにトラフィックや顧客が集まっている地域から始めましょう。ロケールを1つ追加するたびに、翻訳・レビューを行い、最新の状態に保たなければならないページが増えます。そのため、リージョン別バリアントは、その読者層に向けて言い回しや書式を変える必要がある場合にのみ追加してください。たとえば、ブラジルポルトガル語とヨーロッパポルトガル語 (`pt-BR`、`pt-PT`) では語彙が異なりますが、フランス語なら単一の `fr` で複数の国の読者をカバーできます。これらのタグの書き方と選び方については、[ロケールコードガイド](/docs/platform/core/guides/locale-codes)を参照してください。

### 2. URL 構造を選ぶ

Google は、クッキーやブラウザの設定によって言語が切り替わる単一の URL ではなく、[言語版ごとに個別の URL を用意することを推奨しています](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites)。サブディレクトリ (`example.com/fr/`) 、サブドメイン、国別ドメインのいずれでも構いません。各方式の比較は [URL 構造ガイド](/kb/multilingual-url-structure)を参照してください。

### 3. コンテンツとメタデータを翻訳する

Google は [ページの言語を `lang` 属性や URL ではなく、表示されているコンテンツから判断します](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites)。また、本文が単一の言語のままナビゲーションだけを翻訳することは推奨していません。ページ全体に加え、タイトル、メタディスクリプション、画像の alt テキスト、フォームのエラーメッセージ、ページから送信されるメールも翻訳してください。ただし、`<html lang>` もすべてのバージョンで設定しておきましょう。[ブラウザやスクリーンリーダーはこの値を](https://www.w3.org/International/questions/qa-lang-why)フォントの選択、ハイフネーション、音声読み上げに使用します。

### 4. hreflang を追加する

hreflang アノテーションは、どの URL が同じページの言語別バージョンなのかを検索エンジンに伝えます。これにより、検索エンジンはユーザーの言語に合ったバージョンを検索結果に表示できます。ルールや `x-default`、よくある間違いについては [hreflang とは](/kb/what-is-hreflang) を参照してください。

### 5. 言語切り替え機能を追加する

訪問者が同じページの別言語版へ移動できるよう、画面上にわかりやすい切り替え用のコントロールを用意しましょう。推定した言語に基づいて[自動的にリダイレクトする](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites)のは、Google も推奨していないため避けてください。詳しくは[言語切り替え機能のガイド](/kb/language-switcher)を、最初に表示する言語の適切な決め方については[ユーザーの言語の検出](/kb/detect-user-language)を参照してください。

### 6. フォーマットをローカライズする

日付、数値、通貨、複数形のルールはロケールごとに異なります。たとえば英語の `1,234.5` は、ドイツ語では `1.234,5` と表記されます。こうした書式設定は、JavaScript の `Intl` API や大半のi18nライブラリが自動で処理してくれます。アラビア語やヘブライ語を追加する場合は、レイアウトも左右反転させる必要があります。詳しくは [右から左のCSS](/kb/right-to-left-css) を参照してください。

### 7. 翻訳を最新の状態に保つ

誰かが翻訳元のテキストを編集したのに翻訳を再実行しなければ、その時点で他言語版のサイトは古くなってしまいます。変更を誰が (あるいは何が) 、いつ翻訳するのかを決めておきましょう。タイミングとしては、公開のたび、デプロイのたび、または定期的なレビューに合わせて、といった選択肢があります。リリース前には、すべてのロケールで[多言語リリースチェックリスト](/kb/multilingual-app-launch-checklist)を確認してください。

## General Translation がサイトを多言語化する仕組み

コードで構築するサイトやアプリの場合は、Next.js または React プロジェクトで `npx gt@latest` を実行します。[セットアップウィザード](/docs/cli/quickstart)がフレームワークを検出し、設定を書き込みます。次に、既存のマークアップを [`<T>`](/docs/react/reference/components/t) でラップします (`gt-vue` にも同じコンポーネントがあります) 。これにより、メッセージごとに翻訳元キーを個別に管理しなくても、文言を記述した場所にそのまま置いておけます。最後に、ビルド前に [`npx gt translate`](/docs/cli/reference/commands/translate) を実行して、すべてのロケールの翻訳を生成します。各セットアップの手順は、[Next.js](/docs/react/nextjs-quickstart)、[React](/docs/react/react-quickstart)、[Vue](/docs/vue/quickstart) の各クイックスタートで解説しています。

`gt-next` の [`createNextMiddleware`](/docs/react/nextjs/reference/functions/create-next-middleware) は、`/es/about` のようなロケールプレフィックス付きのパスを提供します。ただしデフォルトでは、デフォルト言語の URL にはプレフィックスを付けず、訪問者のロケールクッキーまたは `Accept-Language` ヘッダーに基づいてリダイレクトします。各コンテンツ URL が常に単一の言語に対応するようにするには、`prefixDefaultLocale: true` を設定してください (トレードオフについては[ロケールルーティングと SEO](/kb/locale-routing-seo) を参照してください) 。

マークされた JSX からは、テキストの要素構造と明示的なコンテキスト注記が翻訳サービスに渡されます。生成された文言は、公開前に[ダッシュボードエディター](/docs/platform/dashboard/guides/reviewing-translations)でレビューしてください。一致する翻訳は以降の実行で再利用されるため、翻訳元を編集してもサイト全体を再生成する必要はありません。

アプリのコード以外にも、CLI は [HTML](/docs/cli/reference/formats/html-files) ファイルや [Markdown および MDX](/docs/cli/reference/formats/mdx-md-files) ファイルを翻訳でき、[Locadex](/docs/platform/locadex/quickstart) は Mintlify、Fern、Docusaurus のドキュメントを翻訳します。さらに、インテグレーションを使えば [Sanity](/docs/integrations/sanity/quickstart)、[Payload CMS](/docs/integrations/payload/quickstart)、[Storyblok](/docs/integrations/storyblok/quickstart) と接続できます。いずれも[コンテキストグループ](/docs/platform/dashboard/guides/defining-context-for-translations)を共有し、用語とスタイルを統一できます。

## 重要なポイント

* まず、翻訳をどこで管理するかを決めましょう。ブラウザ翻訳や JavaScript オーバーレイでは、インデックス可能な言語別ページは作成されません。プロキシ、サイトビルダー、プラグインでは翻訳はベンダーやプラットフォーム側で保持され、コードベースのアプローチでは翻訳はリポジトリ内で管理されます。
* どのアプローチを選んでも、決めるべきことは同じ 7 つです。ロケール、URL、翻訳済みコンテンツとメタデータ、hreflang、言語切り替え機能、フォーマット、そして更新です。
* Google は言語ごとに個別の URL を用意することを推奨しており、言語は表示されているコンテンツから判定します。また、訪問者を自動的にリダイレクトしないよう求めています。
* コードで構築されたサイトでは、UI には [`<T>`](/docs/react/reference/components/t) を、翻訳の生成には [`npx gt translate`](/docs/cli/reference/commands/translate) を使用します。そのうえでルーティングを設定し、公開前にすべてのロケールをテストしてください。

## Related questions

- [多言語SEOにおけるサブディレクトリ・サブドメイン・ccTLDの比較](https://generaltranslation.com/ja/kb/multilingual-url-structure.mdx): 1つのプロダクトでサイトとリリースプロセスを共有するなら、example.com/de/ のようなサブディレクトリを使いましょう。国を示せるのは ccTLD だけで、サブドメインなら個別にホスティングできます。Google は ?lang= パラメータを推奨しておらず、.io や .ai のようなバニティドメインは汎用ドメインとして扱います。
- [hreflang とは？設定方法を解説](https://generaltranslation.com/ja/kb/what-is-hreflang.mdx): hreflang は、どの URL が同じページの言語版または地域版であるかを Google に伝え、検索結果に適切なページを表示させるための仕組みです。HTML の link タグ、HTTP の Link ヘッダー、またはサイトマップで追加し、すべてのリンクを相互に参照させたうえで、en-UK ではなく en-GB のような有効なコードを使用してください。
- [言語切り替え機能のベストプラクティス：UX、SEO、アクセシビリティ](https://generaltranslation.com/ja/kb/language-switcher.mdx): 各言語は Deutsch や 日本語 のようにその言語自身の名称で表記し、国を表す国旗は使わないでください。各選択肢からは、クロール可能なリンクで同じページの該当言語版へ遷移させ、選択内容はクッキーに保存します。ローカライズされた URL は決して自動リダイレクトしないでください。
- [多言語アプリのローカライゼーションテスト チェックリスト](https://generaltranslation.com/ja/kb/multilingual-app-launch-checklist.mdx): 本番環境のビルドで、サポート対象のすべてのロケールについて次の9項目をテストしてください：エラー状態やメールを含むジャーニー全体、言語の切り替え、複数形、通貨とタイムゾーン、テキストの伸長、右から左のレイアウト、アクセシビリティ、翻訳の配信、クロール可能な言語別URL。各項目には明確な合格条件を設けてください。
- [開発者にとって最適なローカライゼーションソフトウェアとは？](https://generaltranslation.com/ja/kb/best-localization-software.mdx): 開発者にとって最適なローカライゼーションソフトウェアは、コード内の記述箇所でそのままコンテンツを翻訳し、プロダクトの文脈を活かしながら、すべての言語を常に最新の状態に保ちます。General Translation は、オープンソースのライブラリ、コンテキストグループ、そしてプルリクエストを作成する AI エージェント Locadex によってこれを実現します。

## Previous and next questions

- Previous question: [String Catalog を使って iOS アプリをローカライズするには？](https://generaltranslation.com/ja/kb/localize-ios-app.mdx)
- Next question: [ユーザーのブラウザ言語を検出するには？](https://generaltranslation.com/ja/kb/detect-user-language.mdx)

## Sitemap

See the [Knowledge Base sitemap](https://generaltranslation.com/ja/kb/sitemap.md) for every article.