多言語サイト運用でサーバー選び前に確認すること

多言語サイトは、日本語ページへ翻訳機能を追加すれば完成するものではありません。言語ごとに誰が内容を保証し、古くなった情報をどう止めるかまで決めて初めて運用できます。サーバー選びは翻訳方法ではなく、URLと更新責任を整理した後に行います。

対象国が増えるほど高性能なプランが必要だと考えがちですが、配信距離だけが問題ではありません。画像の重さ・言語の切り替え方・キャッシュの単位・フォームの送信先が、体感速度と更新ミスに影響します。

公開する言語と責任者を先に決める

最初から多くの言語を用意すると、会社概要やサービス条件の変更を同時に反映できなくなります。問い合わせが多い地域と事業上必要な言語から始め、翻訳する人と承認する人を決めます。機械翻訳を使う場合も、重要な条件を誰が確認するかは残ります。

すべてを直訳する必要もありません。国内だけで使う採用条件や地域固有の案内は、対象言語から外す判断があります。掲載しないページには不完全な翻訳を置かず、問い合わせ先や基準となる言語を明示します。

各言語の最終確認日を記録し、原文変更から公開までに必要な日数を見積もります。翻訳が滞ったときに優先するページも決めます。

Googleは、言語別ページに異なるURLを使う方法を勧めています。ブラウザー設定やCookieだけで同じURLの内容を切り替えると、検索エンジンや共有相手が別の言語へ到達できないことがあります。サブディレクトリなど一貫した規則を決めます。

自動転送も便利ですが、利用者が別の言語へ移れる選択肢を残します。日本にいる英語話者や海外にいる日本語話者もいます。URLを直接開けば同じ言語が表示され、言語切替後のページにも対応先があるかを確認します。

HTMLのlang属性は、そのページや文章の言語を示します。ページの基本言語をhtml要素へ設定し、途中だけ別言語になる部分にも必要に応じて指定します。右から左へ書く言語では、文字方向の指定も表示確認に含めます。

hreflangは、検索エンジンへ言語や地域の代替ページを伝える仕組みです。各ページから自分自身と対応する全ページを相互に示し、完全なURLを使います。HTML・HTTPヘッダー・サイトマップの全部へ重ねる必要はありません。保守できる一方式を選びます。

キャッシュがURLではなくCookieだけを見ていると、別の利用者へ違う言語を返すことがあります。言語ごとにURLを分ければ整理しやすくなりますが、ヘッダーや地域判定を使う構成ではキャッシュキーの確認が必要です。更新後に古い翻訳だけ残らないかも試します。

海外からの表示速度は、サーバー所在地だけで決まりません。画像とフォントの容量を抑え、必要ならCDNで静的ファイルを近くから配信します。対象地域からトップページ・主要ページ・フォーム完了までを測ります。国内での一回だけでは判断しません。

フォームを翻訳しても、受付メールや担当部署が日本語だけでは対応が止まります。言語ごとの送信先、返信できる時間帯、営業日の基準を示します。氏名や住所の入力順が地域で異なるため、日本語フォームをそのまま置き換えず実際に送信します。

アクセント付き文字や長い氏名が途中で切れないかも確かめます。自動返信には受付言語と問い合わせ番号を残し、社内で引き継げるようにします。

プライバシーや取引条件は、表示言語ごとに内容を確認します。海外向けの個別法令へ適合するかは専門家の判断が必要です。サーバーが海外から見えることと、対象地域で事業要件を満たすことは別の問題として扱います。

日本語だけ更新されたとき、古い翻訳を最新として見せ続けるのが最も危険です。翻訳待ちの日付を管理し、重要な変更は公開停止や注意書きで伝えます。原文・翻訳・承認の状態をページ単位で追える編集環境を選びます。

多言語サイトのサーバー要件は、言語数よりURLと更新工程から決まります。固定URL・正しい言語指定・言語別キャッシュ・問い合わせ対応を先に設計します。その運用を無理なく載せられるプランを選べば、翻訳追加のたびに基盤を作り直さずに済みます。