WordPressマルチサイトのバージョンアップ手順と注意点

WordPressマルチサイトのバージョンアップは、管理画面の「更新」ボタンを押すだけでは終わりません。本体のファイルを更新したあとに「ネットワークのアップグレード」で全子サイトのデータベースを更新し、PHPの切り替えは全サイトに同時に効きます。

そのため、1つのテーマやプラグインの不具合が、十数サイトをまとめて停めることもあります。

この記事では、多言語サイトや同窓会サイトなどマルチサイトのバージョンアップを実際に担当してきた経験をもとに、マルチサイトだからこそ必要になる手順と、つまずきやすい注意点を解説していきます。

マルチサイトのバージョンアップが通常のWordPressと違う3つの点

マルチサイトは、1つのWordPressを複数の子サイトで共有する仕組みです。そのため更新の「権限」「手順」「影響範囲」の3つが、サイトごとにWordPressを入れている場合と大きく異なります。

まずはこの違いを押さえておくと、この後の手順の意味がわかりやすくなります。

更新できるのは「特権管理者」だけ（サイトネットワーク管理画面）

マルチサイトでは、WordPress本体・プラグイン・テーマの更新やインストールは、管理画面左上の「参加サイト」→「サイトネットワーク管理」に入れる特権管理者しか行えません。

子サイトの「管理者」でログインしても、更新ボタンや「新規追加」は表示されないのが通常です。

弊社にも「管理者アカウントで入っているのにプラグインを追加できない」というご相談が届きますが、原因はこの仕様であることがほとんどです。

制作会社が特権管理者を持ったまま契約が終わっていると、更新そのものができずに放置される原因にもなります。バージョンアップの前に、特権管理者でログインできるかを必ず確認してください。

本体の更新後に「ネットワークのアップグレード」が必要

本体のファイルを更新しただけでは、各子サイトのデータベースは旧い形式のままです。

マルチサイトでは子サイトごとに投稿や設定のテーブルが分かれているため、サイトネットワーク管理の「更新」画面にある「サイトネットワークをアップグレード」（英語版ではUpgrade Network）を実行して、全子サイトのデータベースを新しい形式に揃える必要があります。

WordPress公式の管理者向けドキュメントでは、この機能は「各サイトを5つずつ順に処理してデータベースの変更を適用する」ものと説明されています（Network Admin｜WordPress Developer Resources）。

無効化されたサイトは対象外で、本体のバージョンが変わっていなければボタンを押しても何も起きません。子サイトが多いほど処理に時間がかかり、途中で止まることもあります（後述）。

PHP・プラグイン・テーマの変更が全サイトに同時に効く

マルチサイトの子サイトは、サーバー上では1つのWordPressです。そのためPHPのバージョンを切り替えると、すべての子サイトに同時に反映され、「英語サイトだけ先に上げる」といった分け方はできません。

プラグインとテーマも、ファイルは全サイトで1つを共有しています。プラグインの更新は、それを使っている全子サイトに一度に効きます。便利な反面、不具合も全サイトに同時に広がるということです。通常のWordPressなら1サイトで済むトラブルが、マルチサイトでは全子サイトの停止につながります。

バージョンアップで起こる不具合の種類は「WordPressバージョンアップで起こる5つの不具合と対処法」でまとめています。

マルチサイトのバージョンアップ手順

マルチサイトのバージョンアップは、「棚卸し→バックアップとテスト環境→段階的な更新→全サイトのデータベース更新→子サイトごとの確認」の5段階で進めます。

通常のWordPressと共通する操作は「WordPress手動バージョンアップの方法と注意点」や「メジャーアップデートの安全な手順」に譲り、ここではマルチサイトで追加で必要になる作業を中心に解説します。

手順① 子サイト・テーマ・プラグインの構成を棚卸しする

最初に「何を上げると、どの子サイトに影響するか」を一覧にします。最低限、次の5つを洗い出してください。

1. 子サイトの数（非公開・アーカイブ済みも含む）
2. 子サイトごとに使っているテーマと、そのテーマが共通か個別か
3. ネットワーク有効化されているプラグインと、サイト単位で有効化されているプラグイン
4. mu-plugins（必須プラグイン）やCode Snippetsなど、テーマ外にある独自コード
5. 現在のWordPress・PHP・データベースのバージョン

WP-CLIが使える場合は、

wp site list --fields=blog_id,url,public,archived

で子サイト一覧を、

wp plugin list --status=active-network

でネットワーク有効化中のプラグインを出せます。

サイト単位のプラグインは

wp plugin list --status=active --url=<子サイトのURL>

のように子サイトごとに確認します。

弊社が過去に見積もりをご依頼いただいた統合型マルチサイトでは、子サイトが数十存在し、自作テーマも何本もあり、有効プラグイン約30本以上という構成でした。ここまで洗い出して初めて、作業量と確認範囲が決められます。

手順② 全サイト分のバックアップとテスト環境を用意する

マルチサイトのデータベースは、子サイトごとにwp_2_postsやwp_3_optionsのようなテーブルが作られ、子サイトが多いほどテーブル数が増えます。バックアップは特定の子サイトだけでなく、データベース全体とwp-content/uploads/sites/ 配下を含むファイル一式を取得してください。

一部のバックアッププラグインはマルチサイトに対応していないため、サーバーのバックアップ機能やデータベースのエクスポートで取る方が確実です。

そのうえで、本番と同じ構成のテスト環境を用意します。マルチサイトのテスト環境はシングルサイトより複製が難しく、ドメインの置換や画像の扱いでつまずきやすいため、詳しくは後述します。テスト環境の考え方は「テーマ更新は子テーマ＆テスト環境で」でも解説しています。

手順③ 本体→プラグイン→PHPの順に1段ずつ上げる

テスト環境では、一度にすべてを最新にせず、1段ずつ上げて各段で確認します。弊社では「WordPress本体→プラグイン→テーマ・独自コードの修正→PHP」の順を基本にしています。古いプラグインのまま新しいPHPに切り替えると、全子サイトが同時にエラーになるためです。

PHPは「最新版に必ず上げる」より、「全サイトが安定して動くバージョンまで上げる」と考えると安全です。WordPress公式の推奨環境はPHP 8.3以上（動作環境｜WordPress.org 日本語、2026年10月時点）ですが、子サイトのどれか1つが使うプラグインが未対応なら、そこで止める判断も必要です。

個別の手順は「PHPを安全にバージョンアップさせる方法」「WordPressプラグイン更新時の注意点」をご覧ください。

手順④ 全子サイトのデータベースを更新する（管理画面／WP-CLI）

本体を更新したら、サイトネットワーク管理の「更新」→「サイトネットワークをアップグレード」を実行します。画面には処理中の子サイトURLが5件ずつ表示され、自動で次の5件へ進みます。完了するまでブラウザを閉じないようにしてください。

SSHとWP-CLIが使える環境なら、次のコマンドの方が確実です。

# 更新が必要な子サイトを確認だけする（変更はしない）
wp core update-db --network --dry-run

# 全子サイトのデータベースを更新する
wp core update-db --network

--network は公式ドキュメントで「ネットワーク上のすべてのサイトのデータベースを更新する」オプションとされています（wp core update-db｜WP-CLI Command）。結果は「WordPress database upgraded on 36/36 sites.」のように件数で表示されるので、子サイト数と一致するか確認します。

手順⑤ 子サイトごとに動作確認する

最後に子サイトごとの表示と機能を確認します。ただし、30サイトを超えるネットワークで全ページを人力で確認するのは現実的ではありません。弊社では次のように確認範囲を決めています。

• 全子サイト：トップページの表示、管理画面へのログイン
• テーマ毎の代表サイト：投稿・固定ページ・一覧・検索などテンプレートごとに1ページ
• 子サイト固有の機能：お問い合わせフォーム、カスタムフィールド、会員機能など

多言語サイトのように本体サイトを複製した子サイトが並ぶ場合は、テーマの系統ごとに代表を決めると確認漏れを抑えつつ工数を削れます。

マルチサイトのバージョンアップでつまずきやすい5つの注意点

ここからは、弊社がマルチサイトのバージョンアップや移転を担当するなかで、実際に問題になったポイントを紹介します。どれもシングルサイトでは起きないか、起きても影響が1サイトで済むものです。

「ネットワークのアップグレード」が途中で止まる・通知が消えない

「サイトネットワークをアップグレード」は、サーバーから各子サイトの更新用URLに自分自身でアクセスして処理します。

WordPress本体のコード（wp-admin/network/upgrade.php）では1サイトあたりの待ち時間が120秒で、どれか1サイトで通信に失敗すると「Warning! Problem updating …」という警告を出してそこで止まります。

そのため、次のような環境では失敗しやすくなります。

• テスト環境にBasic認証をかけている
• WAFやCDN（Cloudflareなど）がサーバー自身からのアクセスをブロックする
• テスト用ドメインを自分のPCのhostsだけで向けていて、サーバーからは名前解決できない
• 子サイトが多く、各サイトの処理が重い

こうした環境では、HTTP通信を使わずにサーバー内で処理する wp core update-db --network の方が安定します。

WP-CLIは子サイトごとに更新を実行し、失敗したサイトがあっても「Database failed to upgrade on （URL）」と警告を出して次のサイトへ進むため、どの子サイトが残ったかも一目でわかります。

なお、管理画面でもWP-CLIでも、全サイトの更新が成功したときに初めて「更新済み」の記録が残る仕組みのため、途中で止まるとアップグレードを促すメッセージが消えません。

弊社が担当した3サイト構成のマルチサイトでも、テスト環境でボタンを押すと「完了しました」と表示されたのに、アップグレードを促すメッセージが残り続けたことがありました。このときは表示や動作に問題がないことを確認してから本番に反映しています。

メッセージが残ったときは、まず wp core update-db --network --dry-run で未更新の子サイトがあるかを確かめるのが確実です。

テスト環境の複製がシングルサイトより難しい

マルチサイトでは、ドメインとパスが wp-config.php の DOMAIN_CURRENT_SITE・PATH_CURRENT_SITE と、データベースの wp_blogs・wp_site・wp_sitemeta、各子サイトの wp_N_options に分かれて保存されています。

一箇所でも書き換え忘れると、テスト環境が本番にリダイレクトしたり、「データベース接続確立エラー」が表示されたりします。

WP-CLIなら wp search-replace に --network を付けると、マルチサイトの全テーブルを対象に置換できます（wp search-replace｜WP-CLI Command）。先に --dry-run で件数を確認してから実行してください。

このほか、マルチサイトだからこその判断が必要になります。

• サブドメイン型は、テスト用にもワイルドカードのサブドメインとSSL証明書が必要になる。サブディレクトリ型は「test.本番ドメイン」のような1つのサブドメインにまとめて複製できる
• 画像が数十GBある場合は、テスト環境に複製せず、無い画像だけ本番を参照させる方法も検討する
• お問い合わせの保存データなど個人情報は、テスト環境に持ち込まないよう削除する
• テスト環境にはBasic認証とnoindexをかける（その分、前の項目のアップグレードが失敗しやすくなる点に注意）

低価格帯の共用サーバーでは、容量や機能の制限からテスト環境を用意するだけで数日かかることもあります。スケジュールにはこの準備期間も含めておきましょう。

PHPは子サイトごとに分けられない

先述のとおり、マルチサイトのPHPは全子サイト共通です。一部の子サイトだけ古いプラグインや独自コードを使っていると、その1サイトのためにネットワーク全体のPHPを上げられない、という状態になります。

さらにレンタルサーバーによっては、同じ契約内の全サイトでPHPを統一する仕様のものもあります。

弊社が担当したサーバー移転では、移転先がサイトごとにPHPを設定できないため、他のサイトに合わせてマルチサイト側もPHP 8.3へ上げる必要があり、子サイトのWordPressが古かったため本体のバージョンアップも合わせて行いました。

マルチサイトを移転するときは、移転先のPHPの設定単位を先に確認してください。

ネットワーク有効化プラグインの不具合が全サイトを止める

プラグインを「ネットワークで有効化」すると、そのプラグインは全子サイトで動きます（マルチサイトのネットワーク管理｜WordPress.org 日本語）。更新後に致命的なエラーを出すと、全子サイトがまとめて「重大なエラー」になります。

一方、サイト単位で有効化したプラグインなら、影響はそのプラグインを使う子サイトに限られます。

更新前には、全サイトで本当に必要なプラグインだけがネットワーク有効化されているかを見直すと、万一の影響範囲を狭められます。

特に、カスタムフィールド、SEO、権限管理など、メジャーバージョンをまたぐプラグインは要注意です。弊社の事例でも、カスタムフィールドを使った詳細ページだけがエラーになっていたケースがありました。

管理画面に入れなくなった場合は、FTPで該当プラグインのフォルダ名を変えると、全サイトでそのプラグインが読み込まれなくなります。

子サイトごとに別テーマ・独自コードがあると確認量が増える

マルチサイトでも、子サイトごとに異なるテーマを使っていることは珍しくありません。たとえば、各言語サイトに本体テーマを丸ごとコピーしたテーマを当てていると、functions.php の修正をテーマの数だけ繰り返すことになります。

そのため事前調査では、「テーマが何本あるか」より「中身が何系統に分かれているか」を確かめます。

仮に10本以上のテーマが存在していても functions.php が3系統なら、修正と確認は実質3パターンで済みます。

反対に、5サイトしかなくてもそれぞれ独自テーマなら、PHP更新でエラーが出る可能性は5サイト分あると考えて作業を見積もります。

自分で上げるか、専門家に任せるかの判断基準

マルチサイトのバージョンアップを自分で進めてよいかは、子サイトの数よりも「テーマ・独自コードの系統数」と「どれだけ更新を止めていたか」で決まります。弊社が事前調査で見ている項目を、そのままチェックリストにしました。

右の列に1つでも当てはまる場合は、本番でいきなり更新するのは避けてください。弊社にご相談いただいた方の中にも、自分でPHPを上げようとして失敗し、「自分で対処するのが怖くなってしまった」と、そのままになっていた方がいました。

また、代行費用は子サイト数に比例するとは限りません。本体サイトを横展開した多言語サイトのように構成がそろっていれば、確認を系統ごとにまとめられるため工数を大きく減らせます。

相場感は「WordPressバージョンアップ作業代行の費用相場」をご覧ください。更新できない原因の切り分けは「WordPressが更新できない原因」も参考になります。

サイト引越し屋さんの対応事例

マルチサイトのバージョンアップのご相談は、「自分で上げようとして失敗した」「子サイトが多すぎて見積もりの妥当性を判断したい」「サーバー移転に合わせて上げる必要が出た」の3つに分かれます。それぞれの代表的な事例を紹介します。

事例① 自力のPHP更新に失敗した同窓会サイト（3サイト）

弊社の保守管理をご利用中の同窓会サイトのWeb担当の方から、「PHPのバージョンアップに失敗してそのままになっている。自分で対処するのが怖くなった」とご相談いただきました。本体サイトとサブディレクトリの子サイト2つのマルチサイトで、それぞれに異なる独自テーマが使われていました。

調査の結果、PHPだけを上げるとエラーが出る可能性が高いと判断し、WordPress本体・プラグインの調整とエラー修正を含めてお見積りしました。テスト環境をサブドメインに用意し、3サイトとも更新したうえでお客様に表示を確認していただき、ご依頼から約1週間で本番に反映しています。

その際、先述の「サイトネットワークをアップグレード」のメッセージが消えない事象にも遭遇しました。また、以前からエラーになっていたカスタムフィールドを使う詳細ページも、あわせて修正しました。

事例② 36サイトの多言語マルチサイトの事前調査

日本語の本体サイトを複製した多言語サイトなど、合計10サイトをマルチサイトで運用する企業様から、WordPressとPHPを更新したいとご相談いただきました。

サイト引越し屋さんからは「全サイト・全ページを人力で完全に確認するのは現実的ではない」とお伝えし、主要ページ・主要機能・代表サイトの確認を軸にした対応範囲をご提案しました。

PHPは最新版へ必ず更新ではなく「定して動くバージョンまでを推奨し、データベースは契約中のサーバーで対応できない場合に移転が必要になる点も先にお伝えしています。

お客様側からは、「テスト環境の制限仕様」や「個人情報データの取り扱い」、「バージョンアップ手順」などの要件をいただき、それを踏まえてお見積りを更新しました。

事例③ サーバー移転でPHPを統一する必要が出たマルチサイト

専用サーバーからレンタルサーバーへ複数サイトを移転した企業の事例です。移転対象のうち2サイトがマルチサイトで、内部調査で子サイトのWordPressが古いバージョンのままだとわかりました。

移転先はサイトごとにPHPを設定できない仕様だったため、他のサイトと合わせてPHP 8.3に統一し、マルチサイト側のバージョンアップも移転とあわせて行いました。

「PHPのバージョンの違いでテーマが表示されなくなる可能性があるのか」というご質問にも、事前に理由を説明したうえで進めています。切り替え後は、お客様から「問題なく動いている」とご報告いただきました。

まとめ

WordPressマルチサイトのバージョンアップは、特権管理者で本体を更新したあと「サイトネットワークをアップグレード」または wp core update-db --network で全子サイトのデータベースを更新して初めて完了します。

PHPやネットワーク有効化プラグインの変更は全子サイトに同時に効くため、構成の棚卸し、テスト環境での段階的な更新、テーマ系統ごとの動作確認が欠かせません。

更新を長く止めていたり、子サイトごとに自作テーマがあったりする場合は、本番でいきなり上げずに専門家への相談も検討してください。

サイト引越し屋さんでは、マルチサイトの事前調査からテスト環境での検証、本番反映、その後の定期更新（保守管理）までご対応しています。