公開前に多言語 WordPress サイトをテストする方法

まず URL とルーティング層から始める

翻訳文を確認する前に、各言語版が意図したパーマリンク構造で解決されることを確認してください。多言語 WordPress 環境では、URL は単なるラベルではなく、訪問者やクローラーがどのテンプレート、コンテンツ関係、canonical シグナルを受け取るかを決めるルーティング契約の一部です。

言語切り替えだけでなく、各言語の入口 URL を直接テストしてください。フロントエンドから辿ると正しく見えても、自身のパーマリンクでアクセスしたとき、末尾スラッシュが欠けているとき、翻訳済みスラッグが別ルートと衝突したときに失敗することがあります。こうした不具合は通常、404、誤った言語へのリダイレクト、canonical の不一致として現れます。

サイトが言語別ディレクトリ、サブドメイン、翻訳済みスラッグを使っている場合は、それぞれのパターンが内部的に一貫しているか確認してください。実務上の目標は、1 つの URL が常に 1 つの言語版と 1 つの主要コンテンツオブジェクトに対応し、ルーティングの曖昧さや重複パスがないことです。

言語切り替えで正しいコンテンツ関係が保たれるか確認する

言語切り替えは、表示インターフェースを入れ替えるだけでは不十分です。訪問者をホームページや大まかに関連するページへ移すのではなく、対象言語の対応するコンテンツオブジェクトへ移動させる必要があります。

投稿、固定ページ、テンプレート、そして多言語体験の一部となるカスタム投稿タイプについて、切り替えがページ単位の関係を維持しているか確認してください。翻訳済みオブジェクトが存在しない場合、切り替えでその選択肢を非表示にするのか、フォールバックへ送るのか、部分翻訳状態を表示するのかを決める必要があります。どの選択もユーザー体験とインデックスに影響するため、偶然ではなく意図して決めるべきです。

これは、ブロック、テンプレート、カスタムフィールドで構成されたコンテンツで特に重要です。ある言語ではページが正しく表示されても、翻訳先ではブロックのバリエーション、テンプレートパーツ、またはプラグイン管理データが欠けていて、切り替え機能が存在すると想定している場合があります。

オブジェクト単位でコンテンツの完全性を確認する

表示上は問題なさそうでも、基盤となるコンテンツオブジェクトが不完全なら、多言語公開は失敗し得ます。翻訳済みのタイトル、本文、抜粋、アイキャッチ画像、カスタムフィールド、そしてレンダリングされたページに影響するプラグイン管理データを確認してください。

QA をメインエディターの本文だけに限定しないでください。WordPress では、翻訳出力が post meta、カスタムフィールド、ブロック属性、テンプレート割り当て、タクソノミー用語、またはコンテンツオブジェクト間の関係に依存することがあります。ある言語版でフィールドが欠けていたり、関係が未翻訳だったりすると、ページは読み込まれても、文脈の破綻、空のモジュール、不一致な内部リンクが表示されることがあります。

構造化データに依存するコンテンツタイプでは、文言が異なっていても、各言語版に同じ機能入力があることを確認してください。目的は、文字数やレイアウトの完全一致ではなく、意味と挙動の一致です。

メタデータ、canonical、hreflang をまとめて監査する

メタデータは相互に影響するため、セットでテストする必要があります。単体では正しく見える翻訳済みタイトルや説明文でも、誤った言語版を指す canonical タグや、欠落した hreflang 関係によって台無しになることがあります。

各言語ページが、自身の言語版に対して正しい canonical を宣言していることを確認してください。ただし、アーキテクチャ上、別の場所にバリアントを集約する設計であればその限りではありません。次に、実際に公開されている言語セット全体で hreflang 関係が相互参照され、完全であることを確認します。1 つでも代替が欠けると関係グラフが弱まり、クローラーにとって言語マッピングの信頼性が下がります。

また、ページ本文では常に見えないメタデータも確認してください。Open Graph フィールド、ソーシャルタイトル、テーマやプラグインが生成する構造化メタデータなどです。これらの値が post meta や翻訳フィールドから派生している場合、翻訳ワークフローに明示的に含めない限り、表示内容とずれることがあります。

各言語でフォームとトランザクションフローをテストする

フォームは、静的ページでは見えない多言語の不具合を露呈しがちです。ラベル、プレースホルダー、検証メッセージ、確認メール、成功状態はそれぞれ別のソースから来ることがあるため、ページは翻訳されて見えても、実際の操作は一部が既定言語のままということがあります。

フォーム送信が、ページ読み込み、検証、送信、確認、そしてフォローアップメールやリダイレクトまで、全体の流れで正しいロケールを維持しているか確認してください。フォームがプラグインで埋め込まれている、または動的に描画される場合は、その言語出力がサイト全体の既定値ではなく、現在のページ言語に連動していることを確認してください。

トランザクション経路では、サイトにとって重要な実際のユーザージャーニーをテストしてください。問い合わせフォーム、見積依頼、アカウント作成、購入手続き、送信後メッセージなどです。ここでの失敗は翻訳の不整合だけではありません。混在言語の案内やエラー状態に遭遇したときのコンバージョン低下も問題です。

動的なプラグイン出力とテンプレート駆動コンテンツを確認する

多言語 QA には、メインエディター外でレンダリングされるものすべてを含める必要があります。動的なプラグイン出力は、オプションページ、カスタムテーブル、ショートコード、ウィジェット、テンプレートパーツ、または投稿や固定ページと同じようには翻訳されないプラグイン管理データを参照することがあります。

動的モジュールが現在の言語コンテキストを尊重しているか、翻訳がない場合にきれいにフォールバックするかを確認してください。よくある失敗は、静的コピーは翻訳されているのに、サイドバー、コールアウト、関連記事ブロック、フッターモジュールがまだ既定言語を参照しているページです。

テンプレート駆動コンテンツも同様に厳しく確認してください。テンプレートやブロックパターンが複数言語で再利用される場合、そのラベル、リンク、コンテンツ関係が言語を意識しており、単一ロケールに固定されていないことを確認してください。

WooCommerce の表示を言語ごとに独立した体験として検証する

EC ページには、翻訳済みの商品説明以上の確認が必要です。商品一覧、単一商品ページ、カート、チェックアウト、アカウントページ、注文確認、購入後に表示されるメールやアカウント向けテキストをテストしてください。

商品関係とバリエーションデータに注意してください。翻訳済みの商品ページでも、関係が言語ごとにマッピングされていないと、誤ったバリエーションラベル、関連商品、カテゴリ用語を指していることがあります。価格、配送文言、税金メッセージ、在庫関連の通知も、メインの商品説明とは別のデータソースから来ることが多いため、文脈の中で確認する必要があります。

重要な運用上の問いは、購入者が翻訳の不一致や未翻訳コンテンツへの依存による破綻に遭遇せず、購入フロー全体を進めることができるかどうかです。

モバイル挙動を 1 言語だけでなく各言語で確認する

モバイル QA が重要なのは、多言語コンテンツではレイアウトへの負荷が変わりやすいからです。翻訳文が長くなると折り返し方が変わり、重要な操作がファーストビュー外に押し出されたり、ナビゲーション、フォーム、商品カードの整列が崩れたりします。

小さな画面で、言語切り替え、メニュー、ヘッダー、フッター、固定要素をテストしてください。デスクトップでは機能しても、翻訳ラベルが長い、または切り替えがホバー動作に依存していると、モバイルでは使えなくなることがあります。

また、言語別ページが一般的なビューポートサイズで読みやすく、使いやすいことも確認してください。目標は見た目の一貫性だけでなく、各言語でナビゲーション、フォーム、EC 操作に機能的にアクセスできることです。

公開前にクロール可能性とインデックス可能性を確認する

多言語サイトは、robots 指示、内部リンク、言語関係が不整合だと、ユーザーには完全に機能していても、クローラーにとっては十分にクロールできないことがあります。公開前に、通常のリンク経由で公開済みの各言語版にクローラーが到達できること、そして重要な言語パスが誤った noindex 設定や disallow ルートでブロックされていないことを確認してください。

言語間の内部リンクを見直し、翻訳済みページが既定言語の URL ではなく、正しいローカライズ先を指していることを確認してください。これはユーザーのナビゲーションとクロール発見の両方に重要で、特にコンテンツ関係がカスタムフィールドやプラグイン生成リンクで構築されている場合に当てはまります。

最後に、公開されている言語セットがインデックスの観点から完全かどうかを確認してください。ある言語版を意図的に未公開にする場合、それを未完成のクロール対象として露出させるべきではありません。公開するのであれば、到達可能で、自己整合的で、すでにテストしたメタデータと canonical シグナルで支えられている必要があります。