PleskやcPanelで複数のWordPressサイトを運用するなら、まず「サイトをどの単位で分けるか（契約・アカウントの分け方）」を決め、そのうえでWP Toolkitによる一括管理、ドメインごとのPHP設定、バックアップとcronの統一、WP-CLIでの定型作業を組み合わせると、作業量と事故のリスクを両方減らせます。この記事では、コントロールパネルの機能を使った管理の組み立て方を、つまずきやすい点とあわせて説明します。
ここで扱うのは「独立した複数のWordPress」をサーバー上で管理する方法です。1つのWordPressで複数サイトを動かすマルチサイト機能や、MainWPのような外部ダッシュボードから複数サイトを管理する方法とは別の話なので、混同しないように注意してください。
サイトの分け方を最初に決める
管理の手間とセキュリティに最も影響するのは、サイトをどの単位で分けるかです。
- cPanel：1つのcPanelアカウントの中にアドオンドメイン（新しい画面では「ドメイン」機能）として複数サイトを追加すると、すべてのサイトが同じOSユーザーで動きます。1つのサイトが改ざんされると、同じアカウント内の他のサイトのファイルも書き換えられるおそれがあります。WHMを使える立場なら、顧客ごと・重要度ごとにcPanelアカウントを分けるのが基本です。
- Plesk：サブスクリプション単位でシステムユーザーが分かれます。同じサブスクリプションに追加したドメイン同士は同じユーザーで動くため、分離したいサイトは別のサブスクリプションにします。
自分の複数ブログを1か所にまとめる程度なら同じアカウントでも運用できますが、顧客のサイトを預かる場合や、更新頻度の低い古いサイトが混ざる場合は、分けておくと被害の広がりを抑えられます。
WP Toolkitで一覧・更新・セキュリティを一元化する
PleskとcPanelには、WordPressを管理するための「WP Toolkit」が用意されています（cPanelでは以前の WordPress Manager に代わって提供されています）。提供される機能は、エディション（無償版と有償のDeluxeなど）やホスティング会社の契約によって異なり、画面の表記も更新で変わることがあります（2026年10月現在）。目的別に見ると、主に次のことができます。
- 既存サイトの検出と一覧化：手動でインストールしたWordPressもスキャンで取り込み、バージョンや更新の有無を一覧で確認できます。最初にこのスキャンを行い、管理対象の漏れをなくします。
- 更新の管理：コア・プラグイン・テーマの更新状況の確認と適用、自動更新の方針設定。複数サイトへの一括更新は有償エディションの機能になっていることが多いです。
- セキュリティの確認：ファイルのパーミッションや設定に関するチェックを行い、推奨される対策（ハードニング）を適用できます。
- クローンと同期：本番サイトをステージングに複製し、検証後にファイルやデータベースを本番へ戻す機能です。
- 更新前の自動検証：有償の機能として、クローン上で更新を試して表示の差分を確認してから本番に適用する仕組み（Smart Updates）が提供されています。
WP Toolkitのハードニングには、wp-config.php の権限変更やXML-RPCの無効化のように、プラグインや外部連携に影響しうる項目も含まれます。まとめて適用せず、内容を読んでから項目ごとに有効にしてください。
更新の方針をサイトの重要度で分ける
複数サイトを同じ方針で自動更新すると、1つのプラグインの不具合で全サイトが同時に壊れることがあります。次のように重要度で分けると安全です。
- 小規模なブログや更新頻度の低いサイト：マイナーアップデート（セキュリティ修正）は自動、メジャーアップデートは手動。
- 売上や問い合わせに直結するサイト：ステージング（WP Toolkitのクローンなど）で更新を確認してから本番に適用。
- すべてのサイト共通：更新の前日までにバックアップが取れていることを確認。
WordPress本体にもプラグイン・テーマの自動更新機能がありますが、WP Toolkit側でも自動更新を設定すると、どちらが更新したのか分かりにくくなります。どちらで管理するかを決めて一本化してください。
PHPのバージョンと設定をドメインごとに管理する
古いプラグインを使っているサイトが1つあるために、サーバー全体のPHPを上げられない、という状況はよくあります。cPanelでは「MultiPHP Manager」、Pleskではドメインごとの「PHP設定」で、サイト単位にPHPのバージョンを選べます。
進め方の目安は次のとおりです。
- 全サイトのPHPバージョンを一覧にする（WP Toolkitの一覧や、各サイトの「サイトヘルス」で確認できます）。
- サポートが終了したバージョンで動いているサイトから、ステージングで新しいバージョンを試す。
- 問題がなければ本番のバージョンを切り替え、エラーログを数日確認する。
PHPのメモリ上限などの値もドメインごとに変えられます。値を上げる前に、遅い原因が本当にPHPの設定なのかを確認してください。
バックアップとcronを統一する
サイトごとにバックアップ用のプラグインを入れていると、保存先や世代数がバラバラになり、障害時にどこから戻せばよいか分からなくなります。コントロールパネルのバックアップ機能（PleskのBackup Manager、cPanelのバックアップ機能、ホスティング会社が提供するバックアップツールなど）でアカウント単位の定期バックアップを取り、サーバーの外にも保存しておくと管理が楽になります。年に数回は、実際にステージングへ復元できるかを試すことも大切です。
WP-Cronはアクセスがあったときに実行されるため、アクセスの少ないサイトでは予約投稿が遅れ、多いサイトでは負荷の原因になります。各サイトの wp-config.php に define( 'DISABLE_WP_CRON', true ); を追加し、コントロールパネルのcron（cPanelの「Cron Jobs」、Pleskの「スケジュールされたタスク」）から定期実行すると、全サイトの動きをそろえられます。
# cron に登録するコマンドの例（WP-CLIが使える場合、パスは環境に合わせて変更）
cd /home/username/public_html && wp cron event run --due-now --quietWP-CLIで定型作業をまとめる
SSHとWP-CLIが使える環境なら、複数サイトの確認作業をスクリプトにまとめられます。次は、同じcPanelアカウント内の複数サイトについて、WordPressのバージョンと更新可能なプラグインを一覧にする例です（ディレクトリは例です）。
#!/bin/bash
# 管理対象のWordPressのディレクトリ一覧
sites=(
"$HOME/public_html"
"$HOME/example2.com"
"$HOME/example3.com"
)
for dir in "${sites[@]}"; do
echo "=== $dir"
wp --path="$dir" core version
wp --path="$dir" plugin list --update=available --fields=name,version,update_version
done一覧を見るだけのコマンドから始め、更新などの変更を伴う操作をスクリプト化するのは、バックアップと復元の手順が整ってからにします。サイトによってはWP-CLIの実行ユーザーとファイルの所有者が異なり、権限エラーになることがあるので、そのサイトの所有ユーザーで実行してください。
つまずきやすい点
- ステージングが検索エンジンに登録される：クローンを作ったら、検索エンジンにインデックスさせない設定やBasic認証を付けます。
- クローンから本番へ戻したら、最新の注文やコメントが消えた：データベース全体を上書きすると、検証中に本番で増えたデータが失われます。同期する範囲（ファイルのみ、特定のテーブルのみ）を確認してから実行します。
- 自動更新とキャッシュの組み合わせ：更新後に表示が崩れたように見える場合、キャッシュが古いままのことがあります。まずキャッシュを削除して確認します。
まとめ
- 複数サイトの管理は、まずcPanelアカウントやPleskのサブスクリプションでサイトをどう分けるかを決めるところから始めます。
- WP Toolkitで全サイトを検出・一覧化し、更新とセキュリティの状況を一か所で確認します。エディションによって使える機能は異なります。
- 更新の方針は重要度で分け、重要なサイトはステージングで確認してから適用します。
- PHPのバージョンはドメインごとに管理し、バックアップとcronはコントロールパネル側で統一します。
- WP-CLIは一覧の確認から使い始め、変更系の操作はバックアップ体制が整ってから自動化します。