複数サイトを「まとめて管理する」といっても、管理画面を一つにすることだけが正解ではありません。契約を一つにまとめても、WordPressはサイトごとに分けられます。反対にWordPressを一つにまとめれば、更新は楽になる一方で障害や権限の影響範囲が広がります。先に決めたいのは、何を共通化し、何を分離して守るかです。

サイト数ではなく運営主体から構成を決める

最初に確認するのはサイトの数ではなく、所有者・更新担当・停止時の影響が同じかどうかです。同じ会社が管理し、同じ制作会社が保守するコーポレートサイトと採用サイトなら、一つのサーバー契約へ置きやすいでしょう。一方でグループ会社ごとに決裁者が異なる場合は、請求や解約の判断まで一つにすると引き継ぎが難しくなります。

また、一つのサイトへのアクセス集中が他サイトへ波及してよいかも考えます。共有する範囲が広いほど、契約管理と日常作業は減らせます。その代わり、認証情報の漏えいや容量不足が複数サイトへ及ぶ可能性は高まります。管理の手間だけで決めず、同時に止まっても受け入れられるサイトを同じ単位にするのが出発点です。

一つの契約に個別のWordPressを置く方法を基準にする

多くのレンタルサーバーでは、一つの契約へ複数のドメインを登録し、ドメインごとに公開先を分けられます。この構成でWordPressを個別にインストールすれば、テーマ・プラグイン・利用者をサイト単位で管理できます。一方の更新で不具合が起きても、別のWordPressへ直接影響しにくい点が実務上の利点です。

ただし、契約アカウントやサーバー資源まで分離されるわけではありません。ディスク容量や処理能力は同じ契約内で使い、契約者の管理画面からは全サイトへ到達できる場合があります。追加時はドメインごとの公開ディレクトリを明示し、SSLとバックアップ対象を確認します。さらに、どのWordPressがどのデータベースを使うかを台帳へ残しておくと、削除や移転時の取り違えを防げます。

WordPressマルチサイトは共同運営の条件が揃うときに使う

WordPressマルチサイトは、一つのWordPressコアから複数サイトを運営する仕組みです。テーマとプラグインをネットワークで共有できるため、同じ方針で運営する支店サイトや教室サイトでは更新を揃えやすくなります。サイトごとにメディア領域やデータベースの表は分かれますが、基盤となるWordPressは共通です。

導入判断では、共通化できることより共通化から外れたくなったときを想像します。マルチサイトではネットワーク全体を扱う特別な管理権限があり、通常のサイト管理者とは役割が異なります。特定サイトだけ別の保守会社へ渡す予定がある場合や、サイトごとにプラグイン構成を大きく変えたい場合は個別構成の方が扱いやすいでしょう。有効化前にはファイルとデータベースを退避し、サブドメイン型かサブディレクトリ型かも将来のURL設計から決めます。

契約そのものを分ける判断も残しておく

売上を支える予約サイトと、更新頻度の低い会社案内サイトを同じ契約へ置くと、障害時の優先順位が曖昧になります。重要度が大きく違うサイトは契約を分けることで、保守時間や復旧判断を別々にできます。会社や事業の譲渡が想定されるサイトも、最初から契約名義を分けた方が後の権利移転は明快です。

契約分離には料金と管理画面が増える負担がありますが、それは無駄とは限りません。異なる請求主体・異なる保守会社・異なる停止許容時間のうち、二つ以上が当てはまるなら分離を検討する価値があります。反対に運営主体も復旧優先度も同じなら、一つの契約に個別インストールを置く構成から始めると、管理効率と影響範囲の折り合いをつけやすくなります。

権限はサーバーとWordPressの二段で分ける

WordPressの編集者権限だけを渡しても、制作作業でサーバーへの接続が必要になることがあります。ここで契約者の共通IDを共有すると、担当外サイトのファイルやメール設定まで触れられる状態になりかねません。サーバー側でサイト別の接続先を作れるなら、作業対象のディレクトリだけへ到達するアカウントを用意します。WordPress側でも、記事編集と設定変更を同じ権限にしないことが大切です。

権限の設計は追加時より終了時に差が出ます。外部会社との契約が終わったとき、専用アカウントならその一つを停止できます。共有IDでは、パスワード変更と利用者全員への再配布が必要です。サイト台帳には契約名義だけでなく、サーバー接続・WordPress管理・ドメイン管理の担当を分けて記録し、半年ごとに不要な権限が残っていないか確認します。

新しいサイトは終了方法まで決めてから加える

サイト追加時には、ドメイン・公開先・SSL・WordPress・バックアップ・担当者の対応関係を一行で記録します。公開できたことだけで完了にせず、そのサイトだけを復元できるかも確かめます。サーバー全体のバックアップしかない場合は、一サイトの事故に対して全体を巻き戻さずに済む手順を別途用意する必要があります。

さらに、閉鎖や譲渡のときにデータをどの単位で取り出せるかを確認します。個別インストールなら対象ファイルとデータベースを特定できる状態が必要です。

マルチサイトなら単独サイトの移出方法を事前に検証します。複数サイト管理の完成形は、管理画面が一つであることではありません。追加したサイトを他へ影響させずに更新し、止め、引き渡せるところまで設計されている状態です。