多言語サイト公開前チェックリスト30項目｜言語・表示・検索・問い合わせの合格基準

翻訳は終わったのに、公開してよいか判断できない。日本語ページは確認したが、タイ語やベトナム語のボタンの先まで追えていない。そんなときは「全部よさそう」という感想を、ページと操作を指定した確認記録へ置き換えます。

多言語サイトの公開前チェックでは、翻訳の自然さだけでなく、言語を切り替えて同じ情報に戻れるか、スマホで条件を読めるか、検索設定と問い合わせ先が一致するかを確認します。本記事では30項目を、内容・表示・検索・導線の四つに整理します。合否はチェック数の多さで決めず、問い合わせ不能や誤った取引条件など、利用者の判断を変える不具合が残っていないかで決めてください。

この記事で分かることは、確認対象の選び方、30項目それぞれで残す証拠、修正後にどこまで確認し直すか、制作会社から何を受け取るかです。本文の表は社内の確認表へ転記できます。対象URL、確認者、結果の欄を加えると、そのまま制作担当と共有する点検表にできます。

公開可否を決める確認表をどう作るか

ページ数ではなく、代表的な利用経路を決める

最初に「誰が、どの言語で、何を確かめて、どこへ進むか」を一つの文にします。例えば「タイ語を読む購買担当者が、部品の対応範囲と納期の相談方法を確認し、問い合わせを送る」という経路です。これは架空の検討例です。実際の企業で検証済みの成果や顧客行動ではありません。

この文があれば、トップページだけを眺める確認から離れられます。入口、サービス説明、対応条件、問い合わせ、完了表示という順に対象を並べます。そのうえで、別のテンプレートを使う採用ページや商品詳細、資料ページを追加します。全ページに同じ見た目が使われていても、長い見出しや表を持つページは別の表示リスクがあります。

URLの一覧には、ページの役割、日本語の対応ページ、対象言語、確認担当を付けます。「英語版一式」だけでは、どこまで確認したか分かりません。言語ごとに公開範囲が違う場合は、存在しないページを不具合とせず、利用者にどう案内するかを決めます。日本語に戻す設計なら、その理由と戻り先が画面で分かる必要があります。

合格・不合格・対象外・未確認を分ける

チェック欄を一つだけにすると、見ていない項目まで合格に寄りがちです。少なくとも四つの状態を設けます。合格は指定した条件で確認できた状態、不合格は期待と違う状態、対象外はその機能を提供しない状態、未確認は証拠がまだない状態です。対象外の理由も一言残すと、後日の機能追加と混同しません。

表は横にスクロールして比較できます。

確認時点の画面や応答を保存する場合は、氏名、メールアドレス、顧客の問い合わせ本文を不用意に含めないようにします。フォームには許可されたダミーデータを使い、実際の顧客情報で動作を試す必要はありません。送信テストを行う前には受信担当と範囲を決め、営業通知や外部連携へ意図せず流れない経路を使います。

利用者への影響で優先度を決める

公開を止めるべき問題と、公開後の改善候補を分けます。対応していない国への販売を可能に見せる記載、送信できないフォーム、個人情報の露出などは、単なる表記揺れと同じ扱いにできません。一方、意味が変わらない余白の微調整まで、すべて同じ緊急度にすると重要な問題が埋もれます。

判断の基準は「このまま使う人が、取引条件や次の行動を誤るか」です。担当者の好みを優先度の根拠にせず、影響する言語、ページ、操作を記録します。小規模なサイトでも、公開判定の責任者と、事実を確かめる担当は分けて考えてください。翻訳担当だけにフォーム受信や検索設定まで合格の責任を負わせない設計が現実的です。

内容と言語の10項目をどう確認するか

条件を読者が同じ意味で理解できるかを見る

まず確認するのは、文章の上手さより事業条件です。「対応可能」「受付中」「無料」などの短い言葉でも、範囲や条件が抜ければ意味が変わります。原文を確定しないまま複数言語へ翻訳すると、後からどの言語を直すべきか追えなくなります。サービスの対象、対象外、相談後に決まる事項を先に整理しましょう。

以下の10項目は、一文単位の翻訳検品と、ページを通して読む確認を組み合わせて使います。翻訳の自然さを確認できる人がいない場合は、その項目を未確認にします。翻訳ツールを複数回通したことだけで、専門用語や契約上の意味まで確認済みとはいえません。

表は横にスクロールして比較できます。

数字の翻訳は単位と適用範囲まで照合する

例えば「納期は相談後に案内する」という原文が、別言語で固定日数の約束に変わっていれば、自然な文章でも不合格です。価格も同様で、金額の数字だけでなく、何を含むか、どの通貨か、税や送料をどこで説明するかまで見ます。本記事では個別サービスの価格や納期を提示していません。自社の正式な条件と照合してください。

日付は月日だけでは読者が判断しづらいことがあります。イベントや受付期限なら年を付け、受付時間なら何の地域の時刻かを明示します。タイ語ページにしたからタイ時間だろう、日本語ページだから日本時間だろう、という推測に任せないことが大切です。対象国と言語が一対一とは限りません。

表記の統一では、固有名詞をすべて機械的に翻訳する必要はありません。型番や登録された名称は原表記を残し、説明を補うほうが検索や照合に役立つ場合があります。用語集には推奨表記だけでなく、使わない表記と理由を置くと、更新時に同じ判断をやり直す負担を減らせます。

本文の外側に残った言語も確認する

メニュー、検索欄、画像の説明、送信エラー、添付資料、受付メールまで見ます。本文だけが現地語でも、最後のボタンやエラーが理解できなければ、利用者はそこで止まります。画像に文字を焼き込んでいる場合は、差し替える言語版の所在と更新担当を確認します。見た目の翻訳漏れは、本文の全文検索だけでは見つかりません。

Googleは多地域・多言語サイトの案内で、ページの言語をコンテンツから判断することや、言語別URLを使う設計を説明しています。言語設定の記号を付けたことだけで、本文が翻訳済みになるわけではありません。読者が見る内容と、ページの対応関係を別々に確認する必要があります。

言語切替では、サービス詳細から別言語のトップへ戻すだけの挙動に注意します。完全に対応するページがないときは、関連する案内先を分かる形で示します。どこへ飛ぶか分からない国旗だけの操作にせず、言語名を読めるようにすると、国籍と読む言語の違いにも対応しやすくなります。

スマホと表示の8項目をどう確認するか

文章が長くなった画面で確かめる

翻訳後は見出しやボタンの長さが変わります。日本語版に収まっていた文字が、別言語では折り返されることもあります。短い仮テキストの画面で合格にせず、公開する原稿と画像を入れた状態で確認します。文字の長さを揃えるために重要な条件を削るのではなく、余白や折り返しを調整するのが基本です。

スマホ確認では、管理画面のプレビューだけでなく、実際のテーマと公開予定の部品を使う画面を見ます。ログインが必要な下書きなら、許可された確認方法を用意してください。別の簡易HTMLで表示できたことは、実テーマのメニューやフォーム、表の表示を確認した証拠にはなりません。

表は横にスクロールして比較できます。

表と画像は縮めるだけで済ませない

比較表を画面幅へ押し込むと、列が細くなって一文字ずつ折り返されることがあります。表の意味を保つために横スクロールが必要なら、その範囲を表の領域に限定し、スクロールできることを分かるようにします。本文まで横に動いてしまう状態とは分けて判断してください。

W3Cのリフローに関する解説は、利用者が拡大や小さな表示領域で内容を読めることを扱い、二次元の配置が必要な情報には例外があることも説明しています。本記事の表の確認方針は、その考え方を実務へ落とした編集上の提案です。表ならどのような表示でも問題ないという意味ではありません。

画像は幅と高さの比率を保ち、人物や製品を縦横に引き伸ばさないようにします。PC用画像を小さくした結果、肝心の内容が読めなくなるなら、切り取り位置や別の構図を考えます。図に重要な文字を含む場合は、本文にも同じ意味を残しておくと、画像が見づらい環境でも判断材料が失われません。

操作中の画面を確認する

初期画面が整っていても、メニューを開いた状態や入力エラー後に崩れることがあります。固定ヘッダーが見出しを隠さないか、閉じるボタンに届くか、キーボードを表示したときに送信操作へ進めるかを確認します。ボタンが画面に見えていることと、実際に押して使えることは別の検査です。

リンクの色や下線は、本文と操作の区別を助けます。色だけで状態を伝えると、環境や利用者によって区別しにくい場合があります。入力エラーは欄の色だけでなく、何を直せばよいかの文章を伴わせます。外国語で利用している人に、曖昧な「エラーが発生しました」だけを出さない工夫が必要です。

確認端末を無制限に増やす必要はありません。まず代表的なスマホ幅とPC幅を選び、実際のアクセス環境が分かるなら優先順位へ反映します。確認していない端末を対応確認済みとは書かず、不具合が見つかった部品を別幅でも見直します。環境一覧を残せば、後日どの条件を追加すべきか判断できます。

検索設定の7項目をどう確認するか

検索向けの設定と読者向けの内容をそろえる

多言語サイトでは、日本語と外国語のURLが似ているため、別ページを参照する設定が紛れ込みやすくなります。管理画面の入力欄だけを確認せず、実際のページで出力される情報を見ます。制作会社へ依頼する場合も、設定したという報告と、通常URLで確認できたという証拠を分けて受け取りましょう。

以下は検索での順位を保証するための表ではありません。検索エンジンへ伝える基本情報と、公開するページの関係に矛盾がないかを見るための確認です。設定が正しくても、すぐに検索結果へ掲載される、希望する言語版だけが必ず表示される、といった保証はできません。

表は横にスクロールして比較できます。

canonicalと言語の対応を一つの設定にしない

canonicalは、重複または非常によく似たページの正規化に関係する設定です。一方、hreflangは言語や地域に応じた代替ページを知らせるために使われます。どちらもURLを記載しますが、役割が違います。別言語ページを作ったからといって、すべて日本語トップへ正規URLを向ける設計が適切とは限りません。

Googleのローカライズ版に関する案内では、各言語版が自分自身を含めた対応ページを示すこと、相互の対応などが説明されています。確認表には言語コードだけでなく、実際に開けるURLを並べます。存在しないページや、転送先が変わったページを参照していないかを確かめることが大切です。

複雑な記述を担当者がすべて暗記する必要はありません。制作担当へ「このサービスの日本語・英語・タイ語はどのURLで対応するか」「それぞれの出力は何を示すか」を説明してもらいましょう。専門用語を知っていることより、実ページの関係を確認できることが公開判定に役立ちます。

テスト用の制限とURL変更を取り違えない

制作中の検索対象外指定は、公開時に残りやすい確認項目です。ただし、すべてのページを検索対象にするわけではありません。管理用や確認用の画面まで一律に公開対象へ変更せず、どのページを検索してもらいたいかを決めて確認します。Googleの案内にあるように、noindexとクロール制御は同じ働きではありません。

既存サイトの改稿なら、URLを変えないで済むかも検討します。言語追加やデザイン変更を理由に、過去のURLを無計画に変えると、古いリンクから訪れる利用者への対応が必要になります。URLの変更があるときは、旧新の対応と転送を別の移行確認表にし、この記事のチェック済みだけで移行完了にしないでください。

検索結果の表示文は、設定した説明文と常に同じになるとは限りません。確認するのは、自社が出力する情報が内容と一致しているかです。「説明文を入れたから検索で確実にその文章が出る」と受け取られないよう、制作会社の納品説明にも確認の範囲を残しておきます。

問い合わせ導線の5項目をどう確認するか

送信完了と担当者の受信を分けて見る

問い合わせは、ボタンが押せたところで完了ではありません。入力者が完了を理解できること、受信担当が必要な情報を受け取れること、返答に必要な言語や条件を把握できることまで見ます。自動返信がある場合は、問い合わせの受付と取引の確定を混同する文章になっていないかも確認します。

送信テストには副作用があります。実運用の通知先や顧客台帳、外部サービスへ情報が流れる可能性があるため、確認担当が勝手に何度も送る方法は避けます。許可された宛先とダミー情報を決め、送信する内容、時刻、期待する通知を受信担当と共有してから実施してください。

表は横にスクロールして比較できます。

必須項目を増やす前に、返信に必要な情報を決める

最初から住所や詳細な会社情報を必須にすると、相談段階の利用者が入力できない場合があります。反対に、自由記述だけでは、どの国から何語で返信を希望しているか分からないこともあります。項目数の多い少ないだけで判断せず、初回の返答に必要か、後から確認できるかを一つずつ検討します。

架空のB2Bサービスを例にすると、相談したい内容、返信先、希望する言語、対象地域を別に持つと、言語と提供範囲を混同しにくくなります。ただし、どのサイトにも同じ四つの欄が必須という意味ではありません。電話相談を主とする事業や、販売国が限定された商品では必要な情報が異なります。

入力エラーを表示した後も、利用者が書いた本文が残るかを見ます。エラーのたびに長い説明を入力し直さなければならないと、相談を続ける負担が増えます。戻る操作、連続クリック、通信が途切れた場合の案内も、実装が対応する範囲を制作担当へ確認してください。未検証の二重送信防止機能を、存在するものとして扱わないことが大切です。

自動返信で約束を増やさない

受付メールには、受付済みであることと、その後の流れを簡潔に書きます。実際に守れる確認がないまま「必ず当日回答」「担当者が常時対応」といった約束を足さないようにします。土日や現地の休日をどう扱うかも、事業の運営ルールに合わせて決めます。

返信先の確認も必要です。利用者が自動返信へそのまま返事をしたとき、誰が受け取るかを確かめます。送信元の表示が整っていても、返信を受け取れない設定では追加情報が届かないことがあります。通知の到着、差出人の見え方、返信先は同じ検査ではありません。

フォーム以外の電話、メッセージアプリ、予約ページも同じ考え方で確認します。リンクが開くことに加えて、対象アカウントが正しいか、対象言語で相談できるのか、何を受け付ける窓口かを見ます。利用者へ複数の手段を並べるなら、どれを選べばよいか分かる説明を添えましょう。

修正から公開判定までどう進めるか

不具合を一件ずつ再現できる形にする

「スマホで変」「タイ語が不自然」という報告だけでは、制作担当が修正対象を特定できません。対象URL、言語、画面幅、操作、期待する状態、実際の状態を一組で記録します。翻訳の指摘なら、問題の文と原文、どの条件が変わって伝わるかまで示すと、意味を守った修正につながります。

修正の優先順位は、確認表の番号順とは限りません。問い合わせ不能があれば先に直し、次に条件の誤記、次に表示や細部の順に考えるなど、利用者への影響で決めます。公開を止める必須修正と、次回改善の項目を同じ欄に混ぜず、公開判定のときに見落とさない形にします。

修正を受け取ったら、元の一件だけでなく、同じ部品を使うページや言語へ影響が出ていないかを見ます。ボタン幅を直したなら長い言語の別ページも確認し、共通フォームを変えたなら各言語のエラー文や通知を確認します。これは全ページを最初から無条件にやり直すという意味ではなく、変更した範囲に応じた再確認です。

公開直前と公開後の確認を分ける

下書きやテスト環境で合格しても、本番の通常URLに同じ内容が出ているかは別に確かめます。公開直後には、対象の本文、画像、主要なリンク、問い合わせ入口、検索設定を確認します。管理画面で保存に成功したことだけを、一般利用者から見える確認の代わりにしないでください。

表は横にスクロールして比較できます。

公開後の確認では、会員専用などの意図がないページを、一般の利用者として開けるかも見ます。担当者のログイン中だけ見えている画面と、匿名で見える画面が違うことがあるためです。表示が古い場合は、まず対象URLと確認時刻、実際の内容を記録し、原因を決めつけて設定を一括変更しないようにします。

制作会社へ渡す資料を一枚にまとめる

依頼資料は、30項目のすべてを詳しい技術仕様にする必要はありません。対象の言語、代表的な利用経路、正式なサービス条件、確認担当、公開を止める問題をまとめます。すでにサイトがある場合は、URLを保つ必要があるページと、変更を検討するページを分けて伝えましょう。

依頼時には「どこまでテストに含まれるか」「通知の受信確認は誰が行うか」「公開後の通常URL確認は誰が担当するか」を確認します。翻訳、デザイン、検索設定、フォームが別々の担当でも、最後に利用者の経路を通して判断する人が必要です。担当が分かれていることと、確認の空白があることは別です。

自社で点検を始めるなら、まず一つの言語と一つのサービスを選び、この表の30項目に状態を付けてください。未確認が集中する場所が、依頼すべき範囲を示します。相談の際は、対象URLと読者の言語、利用者が最後にしてほしい行動を共有すると、翻訳の修正か、表示の調整か、導線全体の見直しかを切り分けやすくなります。多言語サイトの確認範囲を相談する。

よくある質問

30項目が全部合格なら検索順位も上がりますか？

保証はできません。この表は、内容・表示・設定・問い合わせの矛盾を見つけるためのものです。検索順位には内容の有用性や競合状況など多くの要素が関わります。チェックの合格と、検索への掲載、アクセス、問い合わせの成果は別に確認してください。

日本語版を確認すれば外国語版も合格にできますか？

できません。翻訳後の文字の長さ、画像や資料の翻訳漏れ、言語切替先、フォームの表示や通知が違う可能性があります。共通部分の検査を活用することはできますが、各言語の公開原稿を使った代表経路の確認は残します。

自社に外国語を確認できる担当者がいない場合はどうしますか？

サービス条件を確認する担当と、言語の意味や自然さを確認する担当を分けて依頼します。翻訳ツールだけで専門用語や取引条件の意味を確定せず、未確認の箇所を明確にしましょう。全部のページを同時公開する必要がなければ、確認できた範囲から公開する方法も検討できます。

公開後に小さな修正をした場合も30項目を全部やり直しますか？

変更の影響で範囲を決めます。文言一か所なら意味と表示、共通部品ならそれを使うページ、フォームなら送信から受信までが主な再確認対象です。URLや言語構成を変える場合は影響が広いため、移行確認を別に行います。修正した場所だけを見て周辺への影響を省くことも、毎回無条件に全件をやり直すことも避けます。

関連記事

• 多言語サイト公開後の運用ルール
• 多言語サイトのリニューアルと移行
• 外国語の問い合わせ対応

出典・確認日・運営者

確認日：2026年11月5日。執筆・編集：タゲンゴ編集担当。架空例と確認表は編集上の提案であり、顧客事例や実施済みテストではありません。

• Google検索セントラル：多地域、多言語のサイトの管理
• Google検索セントラル：ローカライズされたページ
• Google検索セントラル：noindexでインデックス登録をブロック
• W3C：Understanding Reflow