2026年、WordPress複数サイト用サーバーに何サイト置ける？

2026年10月6日、WordPress 7.1.3のメンテナンス・セキュリティリリースが公開されました。これは更新管理が続くことを示す情報であり、一台に置けるサイト数の基準ではありません。固定の収容数を探すより、サイトごとのピーク負荷、重要度、隔離要件を確認し、小規模な負荷試験をしてから集約範囲を決めてください。低負荷の案内サイトは共用候補ですが、取引サイトや高負荷サイトはプロセスと権限を分け、影響範囲が許容できない場合は分割します。WordPress 7.1.3の公式リリース情報

主な対象は、複数のコンテンツサイトを管理し、根拠のない収容数を避けたい運営者です。
越境ECの技術担当者や、顧客サイトの権限・運用境界を設計する制作チームにも役立ちます。

最終更新：2026年10月22日。WordPress公式のリリース情報、Multisite・権限資料、PHPとNginxの公式文書を確認しました。

最初に「サイト数」の数え方を決める

「一台のサーバーに何サイト置けるか」は、数える対象によって答えが変わります。独自ドメインの数、WordPressの独立したインストール数、ひとつのWordPressネットワーク内に作るサイト数は、同じ意味ではありません。

WordPress Multisiteは、ひとつのインストールで複数サイトを管理する仕組みです。一方、独立インストールは、それぞれ別のWordPress環境として更新や設定を管理します。Multisiteの公式説明を確認し、計画時には「ドメイン数」だけでなく、インストールと管理単位も一覧にしてください。

一台のサーバーに置けるWordPressサイト数は、どのように決めますか。
サイト数ではなく、各サイトが使うCPU、メモリー、ディスク、データベース処理のピークと、共用時に許容できる影響範囲で決めます。機器の容量からサイト数を割り出すだけでは、アクセス集中や定期処理による変動を見落とします。

負荷と運用リスクで、同居させる範囲を変える

企業案内のように更新やアクセスが比較的落ち着いたサイトは、同じサーバー資源を使う構成の候補になります。ただし、画像やメディアの容量、プラグイン、PHP処理、データベースの利用状況はサイトごとに確認が必要です。まとめて更新・バックアップできる利点がある一方、設定ミスや障害が複数サイトに及ぶ可能性もあります。

記事検索や画像処理、予約投稿などを使うコンテンツサイトでは、平均的なアクセスだけで判断できません。WordPressのCronはページアクセスを契機とする方式があるため、定期処理の実行状況も監視項目に含めます。WordPress公式Cron資料を確認し、アクセスログとシステムの記録を照合してください。

複数のWordPressサイトを同じサーバーに置くと、互いに影響しますか。
影響する可能性があります。CPUやメモリー、ディスクI/O、データベースを共有するため、ひとつのサイトの処理が重くなれば、ほかのサイトにも影響し得ます。ページキャッシュやCDN、オブジェクトキャッシュは検討できますが、効果を固定値で見積もらず、対象サイトのアクセスと処理で確認してください。

Multisiteと独立インストールは管理境界で選ぶ

Multisiteは、サイト群をまとめて管理しやすい一方、プラグインやテーマの運用をネットワーク単位で調整する場面があります。ネットワーク管理者と各サイトの管理者では権限が異なり、通常のサイト管理者がネットワーク全体の設定を扱えるわけではありません。ネットワーク管理者の権限説明とユーザー権限の公式資料を確認し、誰に何を許可するかを事前に決めてください。

独立インストールは、サイトごとにプラグインや運用手順を変えやすく、顧客単位の管理にも合わせやすい構成です。ただし、独立したインストールを置いただけで、サーバー上のファイルやプロセスまで安全に分離されたことにはなりません。

異なる顧客のサイトを同じサーバーで運用できますか。
要件と運用体制を満たせば可能ですが、管理者アカウントの使い回しを避け、サイトごとの実行ユーザー、ファイル権限、データベースアカウントを整理してください。Nginxで複数のドメインを振り分ける場合も、server_nameの公式仕様に沿って設定を確認します。

PHP-FPMのプールをサイト別に分けることは、実行プロセスの整理には役立ちますが、完全なセキュリティ境界ではありません。PHP公式文書もプール設定だけで全ての分離が保証されるとはしていないため、機密性や障害分離の要件が高い場合は、より強い分割を検討してください。PHP-FPM設定資料

PHPとデータベースはサイトの重要度に合わせて分ける

複数サイトのPHPとデータベース資源は、どう割り当てますか。
まず、取引サイトやAPIなど、遅延や停止の影響が大きいサイトを特定します。そのサイトには専用のPHP-FPMプール、実行ユーザー、データベースアカウントを割り当てる設計を検討し、プールごとの子プロセス数やメモリー使用量は実測しながら調整します。設定値を一律に配るのではなく、実際のPHP処理とメモリーの記録を根拠にしてください。

同じデータベースを使う場合でも、権限を共有する必要があるとは限りません。サイト単位のアカウントと最小限の権限を用意し、バックアップの復元手順もサイトごとに確認します。バックアップはサーバー内だけに置かず、復元対象と保管先を分けて検証するのが安全です。

移行前の確認から分割判断までを順に進める

以下の項目を埋めてから、集約するサイトと分離するサイトを決めます。

• [ ] 各サイトのドメイン、WordPressの構成、プラグイン、データベース、メディア容量を一覧化する
• [ ] 取引、API、会員情報など、停止や情報漏えいの影響が大きいサイトを特定する
• [ ] 通常時と繁忙時のアクセスログ、CPU、メモリー、ディスク使用量、I/O、HTTPエラーを記録する
• [ ] テスト環境で実際の画面操作やAPI要求を再現し、段階的に負荷を加える
• [ ] PHP-FPMのプール、実行ユーザー、データベースアカウント、ファイル権限を点検する
• [ ] キャッシュ導入後も、ログイン・検索・決済などキャッシュ対象外の処理を確認する
• [ ] バックアップからの復元を試し、障害時にどのサイトまで影響するか記録する

この手順では、単に処理量を増やすだけでなく、ピーク時にエラーが増える箇所や、他サイトの応答に影響が出る境界を確認します。サイトの重要度に見合った成長余地を確保できない場合は、負荷が限界に達する前に分割計画へ移ります。

次の表は、構成を選ぶための比較です。どちらの方式も、収容可能なサイト数を保証するものではありません。

分割の兆候と独立サーバーの検討

ひとつのサイトの高負荷が繰り返し他サイトの処理を妨げる、顧客ごとの権限を保ちにくい、障害時に同居サイトまで停止する影響を許容できない場合は、サイト群の配置を見直してください。容量試験で一時的に動作したことだけを根拠にせず、繁忙期の実測、保守作業、復元手順、担当者の権限まで含めて判断します。

WordPress公式の告知では、7.1.3は2026年10月6日のメンテナンス・セキュリティリリースで、7.2 Beta 1は2026年10月20日に試験用として公開されています。Betaは本番用の導入推奨ではありません。運用中のサイトでは、公式のリリース情報を確認し、本番更新は利用中のプラグインやテーマを含めて検証してください。

共用VPSやクラウド環境は、負荷が小さいサイトや短期の検証には適する場合があります。一方、CPU資源を他利用者と共有する構成、環境ごとの制限、サイト間の隔離設計が判断材料になります。長期稼働する複数サイトで専有資源と運用境界を重視するなら、CloudUDPのAMD物理サーバーも比較対象になります。サイトの種類、ピーク時の記録、必要な隔離条件を整理したうえで、CloudUDPのプランで実際の提供条件を確認し、固定の収容サイト数ではなく、検証可能な構成かどうかで選んでください。移行前に接続手順を確認する場合は、サーバーへのアクセスガイドも参照できます。