多言語サイトを簡単に：英語とスペイン語を追加する方法

何を作るのか（まず何を翻訳すべきか）

スペイン語（あるいは英語）を追加するのは、次のような明確なサインが出たときに理にかないます：訪問者の増加する割合がその言語だったり、特定市場から繰り返し販売リクエストが来たり、言語によるやり取りでサポート対応が長引いたりする場合です。適切に実装すれば、顧客が母語でセルフサービスできるため、サポート負荷も減ります。

「多言語サイト」と「翻訳されたサイト」の実務的な違い

多言語サイトは単にページを翻訳するだけではありません。含むべきもの：

• ナビゲーションとUI：メニュー、ボタン、ヘッダー／フッター、クッキーバナー
• メタデータ：ページタイトル、メタディスクリプション、Open Graphのテキスト
• システム文言：フォームエラー、確認メッセージ、取引メール
• 見つけやすさ：各言語に共有・ブックマークできるクローラブルなページがあること

本文だけ翻訳すると、ユーザーは英語のままのメニューや壊れた検索、信頼できないフォームに遭遇します。それでは未完成に感じられます。

現実的な「バージョン1」の範囲を決める

収益とサポートに直接影響するページから始めます。堅実な最初のリリースにはしばしば以下が含まれます：

1. ホームページ（何をしているか、誰向けか）
2. 製品／サービスページ（機能、利点、価格に関する手がかり）
3. 料金ページまたは「見積もり依頼」ページ
4. 主要なコンバージョンページ：/contact、/demo、/signup
5. 信頼獲得ページ：お客様の声、ケーススタディ、会社情報
6. サポートの必須項目：重要なヘルプ記事や短いFAQ

ブログのアーカイブや古いプレスページなどの嬉しいおまけは、基盤が整ってから追加できます。

翻訳の前に誰が更新を担当するか決める

片方の言語だけ更新されなくなると失敗します。担当を明確に割り当てましょう：

• マーケティング：コアページ、キャンペーン、SEOメタデータ
• プロダクト：サイトに掲載するアプリ内用語やリリースノート
• サポート：ヘルプコンテンツと定型文

簡単なルールを決めてください：英語が変わったらスペイン語は決められた期間内に更新する（例：3–5営業日）。この決定ひとつで「二つのサイトが乖離する」問題を防げます。

英語とスペイン語のためのシンプルなURL構造を選ぶ

URL構造は2言語の住所体系です。早めに決めて守ってください——後で変更するとリダイレクトやランキング喪失、壊れた共有リンクが発生します。

一般的な3つの選択肢

1) サブフォルダ（ほとんどのサイトに推奨）：

• 英語: / または /en/
• スペイン語: /es/

2) サブドメイン：

• 英語: ルートドメインのルート（例：英語をホストするサブドメイン）
• スペイン語: es サブドメイン（例：es. を付けたサブドメイン）

3) 別ドメイン：

• 英語: 独立したドメイン（英語用）
• スペイン語: 国別または言語別の別ドメイン（例：スペイン向けの独自ドメイン）

なぜサブフォルダが通常いちばん簡単か

SEOと運用面で、サブフォルダは最も扱いやすい傾向があります：

• SEOシグナルがまとまる：リンクや評価が一つのドメインに集まる（分散されない）
• コンテンツ管理が簡単：1つのCMS、1つのデプロイ、1つのセキュリティ設定
• 解析がクリーン：/es/対非/es/のトラフィック比較がしやすい

サブドメインや別ドメインが間違っているわけではありませんが、追加の手間が発生します。英語／スペイン語の翻訳が目的なら、サブフォルダが実用的です。

共有、インデックス、トラッキングへの影響

• リンクの共有：ユーザーは現在のURLを貼り付けます。サブフォルダなら/es/...でスペイン語であることが一目で分かります。
• 検索インデックス：検索エンジンはどの構造でもインデックスできますが、一貫性が役立ちます。クローラーが重複を混同しないように言語を明確に分けてください。
• 解析とレポート：言語トラフィックをどうセグメントするかを決めてください（例：/es/で始まるパス）。URL構造がこれを簡単にするかを左右します。

URL命名を一貫させる（方針を決めて適用する）

スペイン語のURLを翻訳するかどうかを決めて、全体で統一してください：

• 翻訳されたスラッグ：/es/precios、/es/contacto
• 英語と同じスラッグ：/es/pricing、/es/contact

いずれでも良いですが、一貫性が重要です。混在させるとユーザー、編集者、レポートが混乱し、保守が難しくなります。

ユーザーにわかる言語スイッチャーを追加する

訪問者が考えずに言語を切り替えられることが、バイリンガルサイトを「使いやすい」と感じさせる鍵です。言語スイッチャーは小さなUI要素ですが、信頼、コンバージョン、サポートに大きく影響します。

目立つが邪魔にならないようにする

見つけやすい場所に一貫して配置してください——通常はヘッダー（発見性が高い）かフッター（ヘッダーが混雑している場合に許容）。メニューを使うならナビ付近に置き、ユーザーが探し回らないようにします。

ラベルはわかりやすく：English と Español を使ってください。スペースが本当に厳しい場合以外は EN/ES の略称は避けます。

国旗の使い方に注意

国旗は魅力的ですが、言語＝国ではありません。スペイン語話者は米国にいることもあれば、英語は多くの国で使われます。国旗を使う場合は必ずテキスト（「English」「Español」）と併用して意味を明確にしてください。

ユーザーの選択を記憶する

一度「Español」に切り替えたら、毎ページで再設定させないでください。

• 匿名ユーザーにはクッキーで保存する
• アカウントがある場合はプロフィールに保存する

広告・メール・ソーシャルから両言語に飛ばすことがある場合、この配慮が重要です。

ユーザーを閉じ込める強制リダイレクトは避ける

ブラウザ言語やIPで自動リダイレクトすると失敗することがあります：バイリンガルのユーザー、旅行者、VPN利用者は間違った言語に飛ばされがちです。

言語を提案するなら軽めに（閉じられるバナー）して、必ずワンクリックで戻せる方法を用意してください。

最後に、スイッチャーはキーボード操作に対応し、モバイルで読みやすく、「Language」など明確にラベル付けしてください。

多言語SEOの基本：hreflang、カノニカル、メタデータ

本文だけ翻訳すると、検索エンジンがどのバージョンを優先表示すべきか混乱することがあります。いくつかのSEOの基本を押さえれば大きな差が出ます。多くは「一度設定して継続的に維持する」だけで済みます。

1) ペアを結びつけるために hreflang を使う

hreflang を追加して、Google にどの英語ページがどのスペイン語ページに対応するかを理解させます（言語と地域ごとに正しいものを表示するため）。

最低限、各ペアは相互参照するべきです：

• /en/pricing は /es/precios を参照する
• /es/precios は /en/pricing を参照する

一般的な言語バージョンなら en と es を使います。国をターゲットにする場合は en-US、es-ES、es-MX などを使えます。多くのサイトは言語選択ページや不明なユーザー向けに x-default（多くは英語）を追加します。

2) カノニカルタグを正しく設定する

カノニカルは重複コンテンツを防ぎますが、多言語サイトでは誤設定しやすいです。

基本ルール：各言語ページは自分自身にカノニカルを張る。

• 英語ページ：英語URLをカノニカルにする
• スペイン語ページ：スペイン語URLをカノニカルにする

スペイン語ページを「元は英語だから」と英語のカノニカルに向けないでください。そうするとGoogleはスペイン語ページを優先版ではないと見なし、スペイン語の表示性に悪影響が出ます。

3) メタデータを翻訳する（ページだけでなく）

検索スニペットやソーシャルプレビューはしばしばメタデータから引かれます。

次を翻訳・ローカライズしてください：

• タイトルタグ（逐語訳ではなく自然な表現で）
• メタディスクリプション（その言語でクリックを促す文面）
• Open Graph（og:title、og:description）やTwitterカードのフィールド

ヒント：ブランド名は一貫して保ちつつ、スペイン語話者が実際に検索するフレーズに合わせて調整してください。

4) 両言語をサイトマップに含める

検索エンジンにすべてのバージョンを発見させます：

• /en/ と /es/ の両方のURLを同じサイトマップに含める、または
• 言語ごとに別のサイトマップを公開する

どちらでも構いませんが、新しいページが両言語で時間をかけて出現するようにしてください。欠けているか古いスペイン語URLが原因で多言語SEOのパフォーマンスが振るわないことがよくあります。

ページ本文だけでなく体験全体をローカライズする

段落を翻訳するのは分かりやすい部分です。「体験」はテキストの周りにあるすべて—ナビ、ボタン、エラー表示、フォーマット、さらにはアセット—です。それらが一言語のままだとサイトは未完成に感じられ、ユーザーの信頼が失われます。

UI文言：ユーザーがクリックする小さな文言

まずナビゲーションラベル、CTA、繰り返し出るインターフェース要素（ヘッダー、フッター、クッキーバナー、検索、アカウントメニュー）から始め、次にシステムメッセージ（バリデーションエラー、空状態、成功確認、読み込み中の文言）に進みます。

特にフォームで重要です。スペイン語ページで英語のフィールドエラー（「Please enter a valid email」など）が表示されると信頼が崩れ、離脱につながります。プレースホルダ、補助テキスト、自動送信メール（「お問い合わせありがとうございます」等）もページの言語に合わせてください。

文字を含む画像

スクリーンショット、バナー、インフォグラフィック、画像内テキストは翻訳が抜けやすい部分です。選択肢は2つ：

• 画像をスペイン語版に差し替える（明確さのためにベスト）
• テキストをHTMLにして再設計する（アクセシビリティとSEOの観点でベスト）

すぐに画像を作り直せない場合は、重要情報（価格、期限、手順）を画像に埋め込まないようにしてください。

スペイン語の句読点、アクセント、フォント

スペイン語にはアクセント（á, é, í, ó, ú）、ñ、逆さ読みの句読点（¿ ¡）が必要です。使用するフォントがこれらをすべてきれいにレンダリングするか確認してください。特にボタンやメニューのような狭いスペースでは文字が切れることがあります。

日付、時刻、通貨、数値

対象ユーザーに合った形式を選び、一貫して使ってください。例：

• 日付：「12/03/2025」は3月12日か12月3日かあいまいなので、月名を使うと安全
• 数字：英語は 1,234.56、スペイン語圏では 1.234,56 を使う傾向がある
• 通貨：シンボルと通貨コード（USD、MXN、EURなど）を示す

これらが揃うと、サイトは単なる翻訳ではなく真のバイリンガルに感じられます。

後で壊れない翻訳ワークフローを作る

サイトが「シンプル」であり続けるには、混乱なく更新できることが必要です。目標は完璧なプロセスではなく、新しい文言から公開までの再現可能な流れを作ることです。

1) 共有用の用語集を最初に作る

ライター、翻訳者、レビュー担当者が使う生きた用語集を作成します。含めるべき項目：

• 製品名や機能名（翻訳しないもの）
• 重要なマーケティングフレーズと望ましい訳し方
• トーンの決定（「tú」か「usted」か、または中立的なラテンアメリカスペイン語にするか等）

同じボタンがサイト内で「Empezar」「Comenzar」「Iniciar」とバラバラになる問題を避けられます。

2) リスクに合った翻訳方法を選ぶ

アプローチを選び文書化して一貫させます：

• 人力翻訳：ブランドページ、料金、法的に近い内容に最適
• 機械翻訳＋レビュー：ヘルプ記事やロングテールのコンテンツを素早く処理するのに有効（レビュー担当が品質を担保すること）
• エージェンシー：キャパシティや納期、スタイルの統一が必要な場合に有効

ルール：コンバージョンや信頼に関わるものは人の手を優先してください。

3) 明確な承認フローを定める

「全員がすべてをレビューする」状態は避けます。小さなパイプラインを使ってください：

下書き → レビュー → 公開

次の点について誰が承認するか決めておきます：

• 正確性（意味が合っているか）
• トーンと礼儀（tú/usted）
• 最終フォーマット（見出し、ボタン、短いラベル）

4) 変更を追跡して言語差が広がるのを防ぐ

多くのバイリンガルサイトは静かに失敗します：英語だけが更新され、スペイン語は放置されるケースです。これを防ぐには変更を追跡します：

• 各ページに「翻訳が必要」ステータスを追加する
• 言語ごとの最終更新日を記録する
• 何がなぜ変わったかの短いチェンジログを残す

これを最初からやっておくと、新しいページを追加するたびに大慌てになりません。

実装オプション：CMS、コード、プラグイン（簡単比較）

英語／スペイン語サイトを出す一般的な方法は、CMS、コードベース（静的サイトジェネレータ）、既存に重ねるプラグインの3つです。最良の選択肢は、翻訳を整理して更新しやすく保てる方法です。

オプション1：ロケール対応のCMS

定期的にコンテンツを公開する（ブログ、ランディング、ヘルプ記事）なら、多言語をネイティブにサポートするCMSが最もスムーズです。言語ごとのURL、言語ごとのSEOフィールド（タイトル／説明）、クリーンな編集ワークフローなどの機能を探してください。

注意点：ページ本文だけでなく、ナビゲーションラベル、ボタン、再利用コンポーネントまで扱えるか確認してください。

オプション2：コード／静的サイトジェネレータ（SSG）

サイトが主にマーケティングページで、速度とコントロールを重視するなら、i18nサポートが一流のSSGやフレームワークが良い選択です。

重要ルール：テンプレートに英語文字列をハードコードしないでください。翻訳ファイル（JSON/YAML等）に文言を集中させ、同じコンポーネントがスペイン語でもレンダリングできるようにします。

オプション3：プラグイン（最速だがトレードオフあり）

既存サイトに素早くスペイン語を追加するにはプラグインが便利です。人気のサイトビルダーやCMSで短期間に動かせます。

評価すべきトレードオフ：クリーンなURLを作るか、手動で翻訳を編集できるか（機械翻訳だけに依存しないか）、SEO（メタデータや言語シグナル）をサポートするか。

翻訳の保管場所（安全に保つ）

どの方法でも翻訳は構造化された場所に保管してください：

• ファイル（JSON/YAML）：コード／SSGに最適、バージョン管理が容易
• データベースフィールド：CMSで一般的。編集者向けだがエクスポートやバックアップに注意
• 翻訳プラットフォーム：複数人で翻訳／レビューする際に履歴と承認を管理できる

実装の実用的な近道：まず多言語構造を生成する

サイトを新規構築または再構築するなら、翻訳を始める前に言語対応ルーティング、再利用可能なUI文字列、SEOフィールドをスキャフォールドしておくと便利です。ツール（例：Koder.ai）のようなものを使えば、/en/と/es/のURL構造、言語スイッチャーの挙動、i18nファイルのレイアウトなどをチャットで設計し、スナップショットやロールバックで素早く検証できます。

2言語以上を見越した設計をする

今は英語とスペイン語だけでも、en、esのようなロケールコード、再利用可能なURLルール、共通UI文言の単一ソースを決めておくと、後でフランス語を追加しても拡張に留まります。

サポートコンテンツとフォームを忘れないで

バイリンガルサイトはホームや料金だけではありません。誰かがサインアップしたり、パスワードを忘れたり、エラーに遭遇した瞬間に問題解決を試みます。これらのタッチポイントが英語のみだとスペイン語ユーザーは離脱しがちです。

困ったときに頼るコンテンツを翻訳する

まずはサポートチケットを減らし、顧客の問題をすばやく解決するコンテンツを優先します：

• ヘルプセンター記事やFAQ（特に「はじめに」や課金関連）
• オンボーディングメールや重要なライフサイクルメール（確認、パスワードリセット、領収書）
• アプリ内マイクロコピー：空状態、ツールチップ、確認、警告

既にヘルプエリアがあるなら、両言語から相対パス（例：/help）でリンクしてください。/contactも同様です。

フォームは末端までローカライズする

フォームは多言語サイトが破綻しやすい箇所です。「名前」「メール」だけ翻訳しても不十分です。次をローカライズしてください：

• バリデーションエラー（「有効なメールアドレスを入力してください」など）やインラインヒント
• 送信後の成功メッセージと次の手順
• 日付、電話、住所のフォーマットとプレースホルダ例

両言語でフルフローをテストしてください：各フォームを送信し、一般的なエラーを発生させ、確認画面でユーザーが見る内容をスペイン語で確認します。

スペイン語サポートを用意するか期待値を明確にする

スペイン語でのサポートが可能なら明示的に伝え、スペイン語用の連絡先（スペイン語の受信トレイ、チャットルーティング、対応時間）を用意してください。まだ対応できない場合は隠さず、/contactや自動返信で期待値を設定します。

シンプルなアプローチ：まずセルフサービスのスペイン語コンテンツを提供し、ボリュームが増えたら人的サポートを追加する。