多言語ホームページの構成例｜最初に作るページと後回しにするページ

2026/09/09 | 多言語サイトガイド

多言語ホームページを作るとき、最初から日本語サイトの全ページを翻訳しようとすると、公開が遅れ、更新できないページが増えます。反対に、会社概要だけを翻訳しても、海外の見込み客が「自社に対応できるのか」「何を依頼できるのか」「次にどう連絡するのか」を判断できません。

必要なのはページ数の多さではなく、対象顧客が検討に使う情報を、言語ごとに一つの流れとしてそろえることです。この記事では、初回公開で作るページ、後回しにできるページ、URL・言語指定・更新体制まで、実装担当へ渡せる形で整理します。

翻訳を始める前に「誰のための何語か」を決める

英語ページを作れば世界向けになるわけではありません。同じ英語でも、東南アジアの販売代理店候補へ製品を紹介する場合と、欧米の旅行者へ予約を案内する場合では、必要なページ、用語、通貨、問い合わせ方法が変わります。

言語ごとに、次の5項目を1行で書ける状態にします。

対象者：現地企業の購買担当、海外進出を検討する日系企業、訪日旅行者など
対象地域：タイ、ベトナム、日本国内の外国語話者など
主な課題：仕様確認、取引先選定、予約、導入相談など
提供する行動：問い合わせ、見積もり、資料請求、来店予約など
対応体制：返信言語、担当拠点、営業時間、回答目安

この定義が曖昧なままページを増やすと、日本語原稿を置き換えただけのサイトになりやすく、検索語と内容も一致しにくくなります。対象国で使われる製品名や相談表現は、現地担当者、顧客対応記録、Search Consoleなどを使って確認します。

初回公開でそろえる7種類のページ

業種によって増減しますが、BtoBサービスや制作会社であれば、次のページを優先します。大切なのは、各ページを単独で作るのではなく、「理解する、比較する、信頼を確認する、問い合わせる」という順序でつなぐことです。

1. 言語別トップページ

会社の説明を長く並べるより、対象顧客、提供地域、主要サービス、選ばれる根拠、問い合わせへの入口を明確にします。日本語トップページと同じ順番である必要はありません。海外向けでは、対応地域や返信言語を上部で示した方が判断しやすい場合があります。

2. サービスまたは製品ページ

サービス名だけでなく、対象者、解決する課題、対応範囲、納品物、進め方、対象外、問い合わせ前に必要な情報を示します。製造業なら、仕様、材質、用途、設備、品質管理、最小ロット、供給地域など、購買担当が候補を絞るための情報を優先します。掲載できない条件は曖昧にせず、個別確認が必要と明記します。

3. 事例または対応例

実在する顧客名や数値を許可なく掲載してはいけません。公開できる範囲で、相談前の課題、対象地域・言語、対応内容、確認方法、結果の評価条件を説明します。公開実績がない段階では、架空の成功事例を作らず、「対応の流れ」や「想定ケース」と明示した例に置き換えます。

4. 会社・拠点情報

正式な会社名、所在地、連絡先、代表者、事業内容、現地拠点の有無など、取引前の確認に必要な情報を掲載します。日本の登記名と英語表記、現地法人と日本法人の関係など、誤解が生じやすい部分は整理して記載します。存在しない拠点や常駐体制をあるように見せる表現は避けます。

5. 進め方とよくある質問

問い合わせ後の連絡方法、打ち合わせ言語、見積もりに必要な情報、制作や納品のおおよその段階を説明します。費用が案件ごとに変わる場合は、断定的な最低価格を見せるより、価格を決める要素と見積もり範囲を示す方が実務的です。

6. 問い合わせページ

フォームの表示言語だけでなく、自動返信、入力エラー、同意文、送信完了、担当者の返信まで対象言語に合わせます。サイトはタイ語でも返信は英語のみ、という場合は送信前に明記します。電話番号には国番号を含め、営業時間にはタイムゾーンを添えます。

7. プライバシー・法的表示

収集する情報、利用目的、問い合わせ窓口などを、対象市場と事業内容に合わせて確認します。単純な機械翻訳で済ませず、適用される法令や契約条件について必要に応じて専門家へ確認します。この記事は法的助言ではありません。

後回しにできるページを決める基準

初回公開に不要なページを決めるときは、「検索流入があるか」だけでなく、検討と運用への影響を見ます。次の条件に当てはまるページは、第2段階へ回せます。

対象顧客の意思決定に直接使われない社内行事や古いお知らせ
日本国内だけを対象にする制度・採用・店舗情報
内容が重複し、主要サービスページに統合できる短いページ
翻訳後も更新担当者を決められない一覧やデータベース
根拠や掲載許可を確認できていない事例・受賞・取引先一覧

ただし、後回しにしたページへの言語切り替えリンクを、無関係な外国語トップページへ飛ばすのは避けます。対応する翻訳ページがないなら、その言語のナビゲーションにリンクを出さない、または同じ目的を満たす案内ページを用意します。

ページ一覧表で「作る・統合・対象外」を管理する

サイトマップはURLの一覧だけでなく、運用台帳として作ります。最低限、次の列を用意してください。

項目	記入内容	確認者
ページ目的	理解、比較、信頼、問い合わせなど	事業責任者
対象言語・地域	日本語、英語、タイ語、ベトナム語など	営業・現地担当
元ページ	参照する日本語URL。直訳しない場合も記録	制作担当
公開判断	初回、第二段階、統合、対象外	事業責任者
原稿責任者	事実関係を確認できる担当者	各部門
更新期限	料金・仕様・制度などの次回確認日	運用担当
対応URL	各言語の公開URL	技術担当

この表があれば、翻訳は終わったが確認者がいない、英語ページだけ古い、hreflangの対応先がない、といった問題を早めに発見できます。

URL構造は言語ごとに固定する

Googleは、多言語・多地域サイトで言語ごとに異なるURLを使うことを推奨しています。管理しやすい代表例は、example.com/en/、example.com/th/ のようなサブディレクトリです。国別ドメインやサブドメインにも利点はありますが、運用体制、サーバー、Search Console管理、ブランド方針を含めて選びます。

?lang=en のようなパラメーターだけで言語を切り替える方法は、URL管理や共有が複雑になりやすいため、既存システムの制約がなければ優先しません。公開後にURL構造を変えると転送、内部リンク、サイトマップ、解析設定の修正が必要になるため、初期段階で決めます。

hreflangは「対応関係」を正しく伝える

同じ目的のページに日本語、英語、タイ語がある場合、hreflang で言語・地域別URLの対応を示します。HTML、HTTPヘッダー、XMLサイトマップのいずれかで実装できます。Googleは3方式を同等としており、複数方式を重ねても追加効果はなく、管理ミスが増えるため、保守できる一つの方式に統一します。

実装時の基本は次の通りです。

各ページが自分自身と、存在するすべての対応言語ページを列挙する
AページからBページを指定したら、BページからもAページを指定する
相対URLではなく、https:// から始まる完全なURLを使う
言語コードと必要な場合の地域コードを正しい形式で指定する
言語・地域を選ばせる共通ページには必要に応じて x-default を使う

対応しないページ同士を無理に結び付ける必要はありません。たとえば日本語の採用ページと英語のサービス一覧は目的が違うため、相互の翻訳版として指定しません。

HTMLのlang属性とページ内の言語を一致させる

W3Cは、HTML文書の既定言語を html 要素の lang 属性で常に指定するよう案内しています。日本語なら lang="ja"、英語なら lang="en"、タイ語なら lang="th" のように設定します。ページ内に別言語の引用や語句がある場合は、その要素にも適切な lang を付けられます。

lang は読み上げ、文字処理、ユーザーエージェントの扱いに関係します。一方、検索エンジンがページの言語を判断する際には、見える本文も重要です。ナビゲーションだけ翻訳し、本文の大半が日本語のままというページを量産しないでください。

自動転送ではなく、選べる言語切り替えを置く

IPアドレスやブラウザー言語だけで自動的に別URLへ転送すると、利用者や検索エンジンが他言語ページへ到達しにくくなることがあります。Googleも、推測による自動リダイレクトを避け、言語を切り替えられるリンクを用意するよう案内しています。

言語切り替えは、国旗だけで示すより「日本語」「English」「ไทย」のように言語名を読める形で表示します。国と言語は同一ではありません。切り替え先は可能な限り同じ内容のページにし、対応先がない場合の挙動を設計段階で決めます。

翻訳ではなく「現地の判断材料」をそろえる

自然な文章だけでは問い合わせにつながりません。次の項目は市場ごとに確認します。

サービス名・製品名が現地で検索される呼び方か
寸法、通貨、日付、電話番号、住所の表記が理解できるか
配送地域、税、契約主体、支払条件を誤解なく説明しているか
資格、規格、認証の適用範囲と有効性を確認しているか
写真、事例、FAQが対象顧客の疑問に答えているか
問い合わせ後に実際に対応できる言語を示しているか

AI翻訳は下訳や用語候補には使えますが、会社固有の事実、契約条件、専門用語、数値、法的表示は人が確認します。原文にない実績や利点を補ってはいけません。原文自体が曖昧なら、翻訳前に事業担当へ戻して明確にします。

公開は小さく始め、検索データで拡張する

初回公開後は、Search Consoleで言語別ディレクトリの表示回数、検索語句、ページ、国を確認します。問い合わせ計測と合わせ、次に追加するページを決めます。

たとえば、特定製品の表示は増えているのに専用ページがなければ、製品ページを追加します。サービスページは読まれているが問い合わせが少なければ、料金の決まり方、対応範囲、事例、フォーム項目を改善します。検索されていないテーマを記事数だけで埋めるのではなく、顧客の質問と営業上の優先度を組み合わせます。

公開前チェックリスト

言語ごとの対象顧客、地域、成果行動を定義した
初回公開、第二段階、統合、対象外をページ一覧で決めた
トップ、サービス、信頼情報、FAQ、問い合わせが一つの導線になっている
言語別に固有URLがあり、canonicalとhreflangの整合を確認した
html lang と見える本文の言語が一致している
言語切り替えが同等ページへ移動し、利用者が手動で選べる
原文にない実績、拠点、資格、数値を追加していない
問い合わせ、自動返信、エラー、完了画面まで対象言語で確認した
各ページの事実確認者と次回更新日を決めた

よくある質問

日本語サイトの全ページを最初から翻訳すべきですか？

必ずしも必要ではありません。対象顧客がサービスを理解し、信頼性を確認し、問い合わせるまでに必要なページを先にそろえます。更新できない大量の翻訳ページより、目的が明確で維持できる構成を優先します。

英語ページだけでタイやベトナムにも対応できますか？

対象者が業務で英語を使い、英語で問い合わせ対応できるなら有効な場合があります。ただし、検索需要、担当者の理解、商材の複雑さによって現地語ページが必要になります。市場調査と問い合わせ記録を基に判断します。

hreflangをHTMLとXMLサイトマップの両方へ入れる方がよいですか？

Googleは各方式を同等としており、併用自体に追加効果はないと案内しています。両方を常に同期できる特別な理由がなければ、管理しやすい一方式に統一します。

翻訳のないページで言語を切り替えたらトップへ戻してもよいですか？

利用者が文脈を失うため、常にトップへ戻す設計は勧めません。対応ページを用意する、近い目的の案内を示す、または切り替えを表示しないなど、ページごとに扱いを決めます。

参考にした公式情報

どのページから多言語化すべきか迷う場合は、翻訳量の見積もりより先に、対象顧客の検討導線と現在のURL構造を確認すると優先順位を決めやすくなります。

タゲンゴの無料診断を申し込む