マルチサイトは強力ですが、向いていない使い方をすると運用が苦しくなります。結論から——「同じ構成のサイトを、同じ運用ルールで、同じ担当が管理する」ならマルチサイト。ひとつでも違うなら分けるのが基本の判断です。
メリット
1. 更新が1回で済む
WordPress本体・テーマ・プラグインの更新がネットワーク全体で1回。サイトが10個あっても作業は1回です。管理サイト数が増えるほど効果が大きくなります。
2. ユーザーをまとめて管理できる
1つのアカウントで複数サイトに参加でき、サイトごとに権限（編集者・投稿者など）を割り当てられます。人の出入りが多い組織では、これだけで導入する価値があります。
3. デザインと構成をそろえられる
テーマを共有するので、サイト間の見た目のばらつきが起きません。「支店ごとにデザインが崩れていく」問題を構造的に防げます。
4. サーバー費用と管理コストが1つに集約
契約・SSL・バックアップの対象が1つになります。小さなサイトを10個抱えるようなケースでは、費用も手間も大きく下がります。
5. サイト間のデータを扱える
「全サイトの新着を1か所に集める」「本部サイトのお知らせを支店に出す」といった横断表示が、コードで実現できます。
べんりワザマルチサイトで他サイトの投稿を取得する（switch_to_blog）他サイトの投稿を取得する書き方（switch_to_blog）はこちらデメリット
1. 障害の影響が全サイトに及ぶ
これが最大のリスクです。共有しているぶん、こうなります。
- プラグインの更新で不具合→全サイトが同時に影響
- 1サイトのアクセス集中→全サイトが重くなる
- 深刻な障害→全サイトが同時に落ちる
「1つのサイトが止まっても他は動いてほしい」要件があるなら、マルチサイトは不向きです。
2. あとから1サイトだけ引っ越すのが大変
「支店サイトを別会社に譲渡する」「1サイトだけ別サーバーへ」というとき、投稿だけでなくユーザー・画像・設定を切り出す作業が必要になります。単独サイトのコピーとは比べものにならない手間です。
3. 使えないプラグインがある
マルチサイト対応をうたっていないプラグインは動作しない・想定外の挙動をすることがあります。特にキャッシュ系・バックアップ系・SEO系は事前確認が必要です。
4. 権限設計が複雑になる
各サイトの管理者はテーマやプラグインを入れられません（ネットワーク管理者のみ）。「サイトごとに自由にプラグインを入れたい」運用とは相性が悪いです。
5. サーバーとホスティングの制約
- レンタルサーバーのプランによってはマルチサイト非対応
- Nginx環境では
.htaccessが効かないためサーバー設定が必要 - サブドメイン型はワイルドカードのDNS設定が必要
契約前に「マルチサイト対応」を確認しておきます。
べんりワザおすすめレンタルサーバー比較サーバー選びの考え方はこちら判断のチェックリスト
次の項目に「はい」が多いほどマルチサイトが向いています。
- サイトの見た目と機能構成が共通している
- 同じ担当（または同じ組織）が全サイトを管理する
- サイトごとにプラグインを自由に入れる必要がない
- 1サイトだけを別サーバーへ移す予定がない
- サイト数が今後も増える見込みがある
- サイト間でユーザーや情報を共有したい
逆に、次のどれかに当てはまるなら分けるほうが安全です。
- クライアントが別（納品先ごとに独立させたい）
- サイトごとに必要なプラグインが大きく違う
- 片方が大量アクセスを受ける可能性がある
- 将来の売却・譲渡・移管が見えている
- 担当者にプラグイン導入まで任せたい
具体例で見る向き・不向き
| ケース | 判断 | 理由 |
|---|---|---|
| 全国の支店ページ（同じデザイン） | ◎ 向いている | 構成共通・管理者同じ・数が増える |
| 学校の学部・学科サイト | ◎ 向いている | 更新担当が分かれるがルール共通 |
| 日本語・英語の言語別サイト | ○ 有力 | 多言語プラグインとの比較で決める |
| 社内の部署サイト・イントラ | ◎ 向いている | ユーザー管理をまとめられる |
| 制作会社が受注した別会社のサイト | ✕ 分ける | クライアントが別＝独立性が必要 |
| 個人ブログ＋物販サイト | △ 慎重に | 必要なプラグインが大きく違いがち |
| アクセスの多いメディア＋小さな会社サイト | ✕ 分ける | 影響範囲を分離したい |
代替案
案1：サイトは分けて、テーマを共通管理する
テーマをGitで管理し、各サイトへ配布する方法です。更新の手間は残りますが独立性は完全。制作会社が複数クライアントを扱う場合はこちらが基本です。
案2：1サイト内でカスタム投稿タイプで分ける
「商品」「実績」「お知らせ」のように種類で分けるだけなら、マルチサイトは不要です。URLも/products/のように分けられます。
案3：多言語はプラグインで
言語別サイトが目的なら、多言語プラグインとマルチサイトの両方が選択肢になります。翻訳の紐づけや言語切り替えの導線を自動で作ってくれるプラグインのほうが、実装は楽になることが多いです。
導入する場合の実務メモ
- テスト環境を用意する——本番だけで更新するのは、影響範囲が全サイトなので危険
- プラグインの数を絞る——共有ゆえに、1つの不具合の影響が大きい
- バックアップを自動化——サイト単位の復元ができる仕組みかを確認する
- キャッシュ設定を統一——サイトごとに違う設定にすると原因追跡が難しくなる
まとめ
- メリットは更新1回・ユーザー一括管理・デザイン統一・費用集約・サイト横断表示
- デメリットは障害の影響が全サイトに及ぶこと、1サイトだけの引っ越しが難しいこと
- 判断は「構成が共通・管理者が同じ・独立させる予定がない」の3点で決まる
- サイト数が少ない・クライアントが別なら、分けてテーマを共通管理するほうが安全
「使えるかどうか」ではなく「戻れない選択に耐えられるか」で考えると、判断を誤りません。