グローバルウェブサイトのHeadless CMSは、多言語コンテンツの関連付けをどのように管理するのか？

グローバルサイトを多言語で公開した後によく起きる問題は、「翻訳があるかどうか」ではありません。英語の商品ページを更新しても、ドイツ語ページでは何を同期すべきかわからない、ユーザーが言語を切り替えるとトップページに戻ってしまう、公開終了した翻訳が言語ナビゲーションに残っている、といった問題です。こうした関連を管理するには、安定したコンテンツグループ識別子で各言語版を紐付けたうえで、言語、地域、公開ステータス、元となるバージョンをそれぞれ記録します。タイトルやURLから対応関係を推測してはいけません。

Headless CMS for global websites solutionを評価する際は、コンテンツモデル、翻訳ワークフロー、フロントエンドへの出力を同時に検証する必要があります。CMSに関連情報を保存していても、ウェブサイトが正しく言語を切り替えたり、hreflangを生成したりするとは限りません。APIは、「同一コンテンツのどの言語版が公開アクセス可能か」をフロントエンドが判別できるだけの情報を提供する必要があります。

「同一コンテンツ」の定義を先に決めてから、翻訳の保存方法を決める

同じ製品の英語版とドイツ語版の紹介文は、通常ひとつのコンテンツグループに属します。一方、市場ごとに対象が異なり、特典条件も異なるプロモーションページは、単なる翻訳版とは限りません。モデリングの前に、どのページが共通のビジネス上のアイデンティティを持ち、どのページが独立した市場向けコンテンツなのかを明確にします。そうしないと、無理に対応付けた結果、ユーザーが同等ではないページに誘導される可能性があります。

言語タイトルやパスが変わっても関連付けが無効にならないよう、ビジネス上のアイデンティティと言語版のアイデンティティを分けることを推奨します。

• contentGroupId：言語をまたいで同一コンテンツを識別します。翻訳や名称変更によって変わることはありません。
• variantId と locale：de-DEなど、特定のバージョンとその言語・地域を識別します。同一グループ内では、同じlocaleが一意になるよう制約を設けます。
• sourceVariantId と sourceRevision：翻訳がどのバージョンのどの改訂に基づいて作成されたかを記録し、翻訳が古くなっていないかを判断できるようにします。
• slug、ステータス、公開日時：言語版ごとに個別に管理し、元の言語の公開状況をデフォルトで引き継がないようにします。

言語コードにはBCP 47形式を使用するのが適切です。en-USとen-GBのように細分化するかどうかは、コンテンツの違いに基づいて決めます。対象国が異なるというだけで、バージョンを増やすべきではありません。業務システムの市場番号は個別に保存し、言語フィールドと混在させないでください。

フィールドのローカライズと、言語ごとの独立したエントリーをどう使い分けるか？

どちらのモデルでも関連付けはできますが、編集と公開の単位が異なります。

製品型番や技術仕様は共有し、タイトル、説明、SEOコピーは言語ごとに管理できます。価格、認証に関する説明、配送条件は、市場ごとに上書きが必要な場合があります。すべてのフィールドを一律に翻訳したり、「共有フィールド」によって実際の地域差を覆い隠したりしないでください。

関連付けは参照コンテンツにも適用する必要があります。ドイツ語の商品ページが英語のダウンロード資料を参照している場合、それが共有可能なアセットなのか、ドイツ語版が不足しているのかをシステム上で明確にする必要があります。ページの主要テキストだけを確認していてはいけません。

翻訳の関連付けを編集画面だけでなく公開ワークフローにも組み込む

翻訳が存在していても、常に有効とは限りません。原文が変更されたら、翻訳に記録された元の改訂と現在の改訂を比較し、影響を受けるバージョンに「要確認」のフラグを付けます。レビュー済みの文案をそのまま上書きしてはいけません。古い翻訳を公開停止にするかどうかは、変更のリスクに応じて決めます。表現の調整と安全性に関する仕様変更に、同じ方針を適用するべきではありません。

1. 原文が翻訳可能な状態になったら、コンテンツグループ、言語、フィールドパス、元の改訂を含むタスクを作成します。
2. 翻訳が返されたら、元の改訂を確認します。原文がすでに変更されている場合は、翻訳案を保持して競合を通知し、黙って上書きしません。
3. レビュー段階では、用語、参照リソース、地域制限、ローカライズされたSEOフィールドを確認し、適切な権限を持つユーザーが公開します。
4. 公開または公開停止後は、Webhookでページの再構築、キャッシュの無効化、言語ナビゲーションの更新を実行し、失敗したイベントは再試行します。

タスクのコールバックは冪等に処理し、再試行によって重複エントリーが作成されないようにする必要があります。また、プレビューAPIと公開用APIを分離し、言語関連リストを通じて下書きが本番環境に漏れないようにしてください。

APIのフォールバック結果を識別可能にする

フランス語ページをリクエストしたのに英語のコンテンツが返された場合、フロントエンドがそれをフランス語として表示すると、言語宣言とページ本文が一致しなくなります。APIは、リクエストされた言語、実際に返された言語、フォールバックが発生したかどうかを返す必要があります。本文だけを返してはいけません。

本文、メニュー、共有アセットには、それぞれ異なるフォールバックルールを設定することを推奨します。メニューに翻訳がない場合は、製品方針に従ってフォールバックできます。一方、ページ全体の翻訳がまだ公開されていない場合は、その言語の入口を非表示にする、利用できないことを通知する、元の言語のURLに移動するなど、明確な対応を選択してください。対象言語のURLのまま、何の説明もなく原文を複製して表示してはいけません。

キャッシュキーでは、少なくともコンテンツ、言語、配信環境を区別する必要があります。そうしないと、データベース上の関連付けが正しくても、キャッシュの混在によって異なる言語のリクエストに同じページが返される可能性があります。

SEOの関連付けでは、実際にアクセス可能なバージョンだけを参照する

言語切り替えとhreflangには、同じ公開済み関連データを使用します。言語を切り替える際は、パス内の言語プレフィックスだけを置き換えるのではなく、コンテンツグループを維持します。対象のバージョンが存在しない場合は、有効に見えるリンクを生成しないでください。

• hreflangには、現在のページ自身と実際に存在する対応バージョンを含め、相互参照を維持する必要があります。言語・地域コードは、検索エンジンがサポートする形式に準拠させます。
• インデックス可能な独立した言語ページでは、通常、自ページを指すcanonicalを使用します。すべてのページを元の言語のページに統一して向けると、canonicalに関する相反するシグナルが送られます。
• 未公開、リダイレクト、エラーを返す、またはnoindexに設定されたバージョンを、インデックス対象の言語別ページとして出力し続けないでください。

受け入れテストでは、ひとつのコンテンツグループを使って「原文の変更」「翻訳未公開」「言語版の公開停止」「slugの名称変更」の4つの状態をテストし、API、言語ナビゲーション、キャッシュ、hreflangが連動して変化するかを確認します。管理画面で関連付けが正常に見えるのに、本番環境で無効なURLが残っている場合は、翻訳関係を再作成するのではなく、公開イベントとフロントエンドのビルド経路を優先して調査してください。