ガイド
UX
翻訳

ウェブサイトに言語スイッチャーを追加する方法（壊さずに）（2026年版）

2026年6月27日読了時間 7分

言語スイッチャーはシンプルに聞こえます — ドロップダウン、旗、言語の一覧。しかし間違って実装すると、ナビゲーションを壊し、SEOを損ない、スイッチャーが無いよりもユーザーを混乱させます。ここでは、正しく実装するための完全ガイドを解説します。

言語スイッチャーが実際に果たすべき役割

言語スイッチャーは単なるUIコントロール以上のものです — ユーザーの好み、URL構造、コンテンツ配信を橋渡しする調整レイヤーです。完全な実装は次を満たす必要があります。

初回訪問時にブラウザの言語を検出する。 Accept-Languageヘッダー（サーバーサイド）やnavigator.language（クライアントサイド）は、ユーザーが好む言語を教えてくれます。初回訪問時に適切なロケールへリダイレクトまたは提供するために使いましょう。
ユーザーが手動で上書きできるようにする。 自動検出は出発点であって最終的な答えではありません。フランスに住むドイツ語話者は、ブラウザのロケールがフランス語であってもドイツ語のコンテンツを望むかもしれません。スイッチャーは常に到達可能でなければなりません。
選択を記憶する。 選択された言語を localStorageやCookieに保存し、再訪問時に再度切り替える必要がないようにします。サーバー側でレンダリング前に言語を把握したい場合はCookieの方が適しています。
URLを言語固有のバージョンに更新する。 フランス語への切り替えは、 URLを/aboutのままにしてコンテンツだけをその場で変更するのではなく、 /fr/aboutへ遷移するべきです。URLベースの言語ルーティングは多言語SEOの基盤です。
ナビゲーションを壊さない。 ユーザーが /fr/products/widget-proにいてドイツ語に切り替えた場合、ドイツ語のホームページではなく /de/products/widget-proに着地するべきです。

デザインパターン：どこに配置するか

実際には主に3つの配置場所が使われています。それぞれ視認性と邪魔になりやすさのトレードオフが異なります。

ウェブサイトに言語スイッチャーを追加する方法（壊さずに）（2026年版）の補足データ
位置	視認性	邪魔になりやすさ	向いている用途
トップナビゲーションバー	高い	低い	グローバル向けオーディエンス、B2Cサイト
フッター	低い	なし	補助的な選択肢、開発者向けドキュメント
フローティングウィジェット	高い	中程度	既存サイトへの後付け導入

横にスクロールしてすべての列を表示できます。

ほとんどのグローバルサイトでは、トップナビゲーションバーが正しいデフォルトです。ユーザーが最初に目を向ける場所であり、ページのコンテンツと競合しません。フローティングウィジェットは、サイトのナビゲーションを変更できない場合（サードパーティの CMSや、テンプレートの変更を最小限にしたいWebflowサイトなど）に良い選択肢です。

言語スイッチャーでやってはいけないこと

国旗アイコンだけを使わない

国旗は国を表すものであり、言語を表すものではありません。ブラジルとポルトガルはどちらもポルトガル語を話します。ベルギーには3つの公用語（フランス語、オランダ語、ドイツ語）があります。スイスには4つあります。カナダは英語とフランス語を使います。現地の言語名（Français、Deutsch、日本語）や言語コード（FR、DE、JA）を使うか、地域の区別が重要な場合は国旗と言語名を併用してください。

確認なしに自動リダイレクトしない

lingvit.com/pricingに訪れたユーザーを黙って lingvit.com/fr/pricingへリダイレクトすることは、そのユーザーが意図的に英語のURLを共有していた場合に戸惑いを招きます。検出した言語を提案する非ブロッキングのバナーを表示し、受け入れるか却下するかをユーザーに委ねましょう。

モバイルで見つけにくいほど小さくしない

モバイルのハンバーガーメニュー内に折りたたまれた14pxの言語ラベルは、実質的に見えていないのと同じです。グローバルに分散したオーディエンスを持つ場合、小さな画面でも少なくとも44×44pxの、見つけやすいタップ領域をスイッチャーに割り当てるべきです。

モバイルでスイッチャーを削除しない

“スペースを節約するため”にモバイルで言語スイッチャーを隠すのはよくある間違いです。英語圏以外の市場のモバイルユーザーは、デスクトップユーザーよりも頻繁に言語コントロールを必要とします — 彼らは第一言語で閲覧している可能性が高いためです。

URL構造への影響

ユーザーが言語を切り替えると、URLは新しいロケールを反映するように更新されるべきです。標準的な2つのパターンは以下の通りです。

/fr/about— サブディレクトリ（ほとんどのサイトに推奨）

fr.example.com/about— サブドメイン（大企業に好まれる）

サブディレクトリの方が実装がシンプルで、ドメインの権威を直接引き継ぎます。サブドメインは別途DNS設定が必要で、検索エンジンから別サイトとして扱われることがあります。

スイッチャーに選ぶURL構造は、hreflangの実装と一致していなければなりません。ページの<head>内にあるhreflangリンクタグは、どのURLがどの言語を提供するかを検索エンジンに伝えます — そしてそれらのURLは、スイッチャーが遷移する先のURLと同じでなければなりません。

SEOの問題

URLを更新せずにJavaScriptだけでコンテンツを変更する言語スイッチャーは、検索エンジンには見えません。Googleはクロールとインデックスの対象をURLとして扱い、JavaScriptの状態としては扱いません。

多言語SEOの要件は次の通りです。

各言語版は、それぞれ独自のクロール可能なURLを持つ必要があります（例：/fr/pricing）。
各ページは、元の言語も含めたすべての言語版を指す hreflangリンクタグを含める必要があります。
言語スイッチャーはそれらの実URLへリンクする必要があります — コンテンツをその場で入れ替えるJavaScript関数を起動するのではありません。

これが、ユーザーが手動で切り替える分には問題なく動作しても、クライアントサイドのみの言語切り替え（URLを更新せずJSでテキストを変更する方式）がSEOでは通用しない理由です。

Lingvitはこれをどう扱うか

Lingvitの組み込みウィジェットには、完全な言語スイッチャー実装が含まれています。

自動言語検出
初回訪問時に、Lingvitはブラウザの優先言語を読み取り、一致する翻訳を提供します。リダイレクトはなく、体感的な読み込みを速くするためページコンテンツがその場で更新されます。
プラットフォームのルーティングとの連携
一般的なLingvitのランタイム翻訳は、公開時点でインデックス可能なロケールURLや hreflangを作成しません。多言語SEOが必要な場合は、プラットフォームが提供するロケールURLとメタデータにスイッチャーを合わせておいてください。
選択の永続化
選択された言語はlocalStorageに保存されます。再訪問時には、再検出することなく優先言語がすぐに提供されます。
位置とスタイルをカスタマイズ可能
Lingvitダッシュボードから、スイッチャーの位置（右上、右下、左下）、表示形式（言語名、コード、または国旗＋名前）、ブランドに合わせた配色を設定できます。

よくある質問

言語スイッチャーのデザインをカスタマイズできますか？

はい。Lingvitダッシュボードから、ウィジェットの位置を設定し、言語名のフルネーム表示、2文字のコード表示、あるいは国旗と名前の併用表示を選べます。ブランドに合わせた色も適用でき、より高度なスタイリングにはカスタムCSSでの上書きにも対応しています。

スイッチャーはhreflangとどう連携しますか？

一般的なLingvitのランタイム翻訳は、公開時点でインデックス可能なロケールURLやhreflangを作成しません。多言語SEOが必要な場合は、プラットフォームが提供するロケールURLにスイッチャーを合わせておいてください。

独自のカスタムスイッチャーを作りたい場合はどうすればいいですか？

カスタムスイッチャーでランタイムのロケールを制御できます。対応するWordPress連携を除き、インデックス可能なURLルーティングとhreflangの責任はお使いのプラットフォーム側にあります。