コーポレート、採用、サービス、施設など複数のサイトを持つとき、すべてを一つのCMSに入れれば運用しやすいとは限りません。一方ですべてを別々に作ると、会社情報やブランド表現、権限管理が揃わなくなります。
私たちが複数サイトの相談で最初に確認するのは、CMSを一つにするかどうかではありません。それぞれを誰が更新し、どの情報を共有し、いつ公開するのか。サイト同士の関係を先に整理し、見た目、情報、仕組みを分けて、共通化する範囲と個別に運用する範囲を決めます。
サイトを増やす前に、関係を図にする
各サイトの目的、対象者、運用部署、公開日、ドメイン、共有する情報を書き出します。親子関係なのか、対等なブランド群なのか、期間限定の特設サイトなのかで、適切な構成は変わります。
画面の似ているサイトを近くに置くのではなく、誰が何を更新し、どの情報を参照し、いつ公開するかで関係を判断します。
共通化は、見た目・情報・仕組みに分ける
- 見た目：ロゴ、書体、色、グリッド、ヘッダー、フッター
- 情報：会社概要、問い合わせ先、規約、共通のお知らせ
- 仕組み：CMS項目、利用者、予約公開、検索、フォーム
同じに見える情報でも、全サイトで正とする情報、サイトごとに持つ情報、別の場所を参照する情報に分けます。共通化の単位を混ぜないことで、一部の変更が意図せず全サイトへ広がることを防ぎます。
最初の一サイトを、完成品ではなく基準として作る
最初のサイト固有の設定を、そのまま二つ目へ複製すると、後から共通部分を直しにくくなります。共通、変更可能、サイト固有の三つに分けてから次のサイトへ展開します。
二つ目、三つ目を作る過程で、共通部品に含める条件を見直します。最初から万能な共通部品を作るのではなく、実際の差を確認しながら境界を整えます。
権限は部署名ではなく作業から決める
同じ部署でも、原稿を書く人、承認する人、公開する人、画像だけを差し替える人がいます。誰が、どのサイトで、どの情報を、どの状態まで扱えるかを表にします。
閲覧、下書き、編集、承認、公開、削除、ファイル管理、設定変更を分けます。部署名だけで一括付与せず、日常の作業と事故時の影響から必要な権限を決めます。
公開日はサイトごとに分けられるようにする
一つのサイトの遅れで全サイトを止めないよう、ナビゲーション、サイト一覧、共通のお知らせ、サイトマップへの掲載状態を分けます。未公開サイトへの入口は公開側へ出しません。
会社情報や規約など共通性の高い内容は、サイトごとの公開前にも差異を確認します。共通ナビゲーションへの追加を後日にするなど、段階公開の順序を決めます。
同じ情報を二重に管理しない
住所、問い合わせ先、重要なお知らせなどは、どこを正として更新するかを決めます。複数画面へ手入力するのではなく、共通データを参照するか、変更時に確認する対象を明示します。
対象者や法的条件によって表現が異なる情報まで無理に一つへまとめる必要はありません。共通の基礎情報と、サイト固有の補足を分けます。
公開後は、サイト追加と担当変更を同じ手順で扱う
サイト追加時は、ドメイン、CMS、権限、共通データ、公開経路、保守範囲を確認します。担当変更時は、操作範囲、承認者、手順書、不要アカウントの停止を確認します。
共通部分を更新するときは、代表的なサイトだけでなく、構成差の大きいサイトも確認します。追加と交代を例外作業にせず、繰り返せる手順にします。
この方法が向いているケース
- コーポレートと採用・サービス・施設サイトがある
- 複数部署が同じCMSを使う
- ブランドの共通性とサイトごとの個性を両立したい
- 公開日や担当者がサイトごとに異なる
- 今後もサイト追加を予定している
別の構成を選ぶべきケース
法的責任、セキュリティ要件、公開基盤が大きく異なるサイトは、同じCMSへ無理に入れません。デザインや外部連携だけを共通にし、認証、データ、インフラを分離する方が、障害や誤操作の影響を限定できます。
複数サイト設計チェック
- 目的、運用者、公開日、ドメインを整理したか
- 見た目、情報、仕組みを分けて共通化したか
- 共通情報の正となる場所を決めたか
- 共通部品へサイト固有設定を埋め込んでいないか
- 部署名ではなく作業から権限を決めたか
- 未公開サイトへの入口を制御しているか
- サイト追加と担当変更の手順があるか
- 共通更新を構成差のあるサイトで確認したか
