放置したWordPressを止めずにバージョンアップする手順

WordPressのバージョンアップで、何年も放置したサイトほどやってはいけないのが、本番の管理画面で「今すぐ更新」を押すことです。古いPHPのまま本体を上げれば止まり、PHPを先に上げれば古いプラグインが真っ白になる。どちらが起きるかは、やってみるまで分かりません。本番は触らず、複製したテスト環境で全部を先に通す。本体は1バージョンずつ、プラグインは1件ずつ。これが、公開中のサイトを止めずに6年分の更新を当てる唯一の順番です。

この記事は、その手順を順番どおりに書いたものです。各手順で何を見て、何を基準に次へ進むかまで書いています。根拠として、WordPress 5.4・PHP 7.4・MySQL 5.6で止まっていた5サイトを3週間で最新版まで上げた対応記録を末尾に載せています。本文で「事例では」と書いている数字は、そこから引いたものです。最終更新：2026年10月17日（対応事例 1件・5サイト）

更新していないサイトは、まず「なぜ止まっていたか」を調べる

更新が止まっているサイトには、止まった理由があります。理由を知らずに更新を始めると、同じ理由でまた止まるか、止めていた仕掛けが更新を妨げます。

サイトヘルスでサポート切れを確かめる

管理画面の「ツール」→「サイトヘルス」→「情報」タブを開き、WordPressのバージョン、サーバーのPHPのバージョン、データベースの種類とバージョンを控えます。PHP 7.4は2022年11月、MySQL 5.6は2021年2月にサポートが終わっています。見た目が普通に表示されていても、サポートが切れた土台で動いているサイトは珍しくありません。事例の5サイトは、うち4つがPHP 7.4とMySQL 5.6のままでした。

更新を止めている固定用プラグインが無いか見る

「プラグイン」→「インストール済みプラグイン」で、WordPress本体のバージョンを固定するプラグイン（WP Downgrade など）や、自動更新を止める設定が無いかを見ます。過去に何かの不具合でバージョンを戻し、その固定が残ったままになっていることがあります。固定されている限り、自動更新も手動更新も効きません。放置ではなく、誰かが止めている場合があります。事例のネットショップがこれで、本体が6.1.2に固定されていました。

侵入されたことがあるなら、入口の設定を先に見る

過去に不正アクセスを受けたことがあるサイトは、バージョンアップの前に、そのとき入れた遮断の設定がまだ有効かを確かめます。REST APIへの外部アクセス制限、XML-RPCの遮断、ログイン試行の回数制限。複数サイトを運営していれば、全サイトで同じ設定が入っているかも見ます。1サイトにだけ入っていて、他は開いたまま、ということがあります。事例では5サイト中1サイトにしか設定が無く、不動産サイトはユーザー情報が外部から取得できる状態でした。

本番は触らず、複製したテスト環境で全部やる

全ファイルとDBを取り、元に戻せる状態を先に作る

最初に、サーバー上のファイル一式とデータベースを取得します。これが、テスト環境の元になり、本番で何かあったときに戻す元にもなります。取ったバックアップは、作業が全部終わって本番の動作を確認するまで消しません。更新前のデータベースは、しばらく残しておき、削除する日を担当者に伝えてから消します。

本番と同じ構成を別の場所に立てる

取得したバックアップから、本番と同じWordPressのバージョン、同じプラグイン、同じテーマ、同じPHPのバージョンで、別の場所にサイトを立てます。サーバーのサブドメインでも、手元のパソコン（Local などのローカル環境）でも構いません。更新作業はすべてこちらで先にやり、問題が無いことを確認してから、本番に同じ手順を当てます。

公開中のサイトはメンテナンス表示にしない

テスト環境で先に全部済ませるので、本番でメンテナンス表示を出す必要はありません。本番に反映するときも、更新は数分で終わり、その間も訪問者はサイトを見られます。事例の5サイトは、作業期間の3週間、一度もメンテナンス表示を出していません。

本体は1バージョンずつ上げ、各段階でDBを保存する

一気に上げると、どこで壊れたか追えなくなる

WordPressは、途中のバージョンでデータベースの構造や設定の持ち方が変わっています。何年分も飛ばして最新版へ上げると、飛ばした分の変換処理がまとめて走り、壊れたときにどの段階で何が起きたか追えません。メジャーバージョン（6.0、6.1、6.2…）を1つずつ上げます。事例の本体サイトは6.0.2から7.1.3まで13段階、リノベーションサイトは5.4.22から7.1.2まで段階的に上げました。

各段階で主要ページの表示とエラーの有無を見る

1段階上げるごとに、その直前のデータベースを保存しておきます。上げたら、トップページ、一覧、詳細、固定ページ、お問い合わせフォーム、管理画面の各メニューを開いて、表示とエラーログを見ます。問題が無ければ次の段階へ。問題が出たら、保存したデータベースで直前の段階に戻し、原因を見てから進みます。1段階ずつなら、壊れた時点の直前に必ず戻れます。

プラグインは1件ずつ更新し、そのたびに全ページを巡回する

まとめて更新すると原因の切り分けに同じ時間がかかる

プラグインは1件ずつ更新し、更新するたびに公開ページと管理画面のページを自動で巡回して、エラーの増減を記録します。どのプラグインの更新でエラーが増えたかが1件単位で分かります。まとめて更新してから巡回すると、どれが原因かを切り分けるのに、結局1件ずつ戻して試す時間がかかります。事例の不動産サイトでは、16件を1件ずつ更新し、そのたびに公開128ページと管理画面127ページを巡回しました。

本体と拡張が分かれているプラグインは同時に更新する

バックアップ系やフォーム系のプラグインには、本体と拡張（Extension・アドオン）が別のプラグインとして入っているものがあります。本体だけを更新すると、旧版の拡張との不整合でエラーになることがあります。本体と拡張を同時に更新します。事例では All-in-One WP Migration の本体だけを更新するとエクスポート画面がエラーになり、Unlimited Extension と同時に更新すると解消しました。テスト環境で先に踏んでおいたから、本番では最初から同時に更新できています。

配布終了のものは入れ直さず代替に替える

公式ディレクトリから消えている、最終更新が数年前で止まっている、というプラグインは、更新しても脆弱性が直りません。同じ機能を持つ、更新が続いているプラグインに替えます。制作会社が独自に作ったプラグイン（一般配布なし）は、更新の仕組みが無いので、そのまま残すか、コードを新しいPHPで動くように直すかを判断し、報告書に「更新していないものと理由」として書きます。

PHPは本体とプラグインを上げてから切り替える

古い書き方のテーマは先に直してから上げる

PHP 5や7向けに書かれたテーマは、PHP 8ではそのまま動かないことがあります。省略形の書き方（ショートタグ）、未定義の変数の参照、廃止された関数。PHPを切り替える前に、テスト環境でPHP 8にしてテーマのエラーと警告を全部出し、表示と動作を変えずにエラーだけを消す修正をします。修正前後でページの内容が同じであることを確認してから、本番に当てます。事例の本体サイトでは、テーマ22ファイルを修正しました。

切り替え後は全ページを巡回してエラーログを見る

サーバーの管理画面でPHPのバージョンを切り替えたら、全ページを巡回し、サーバーのエラーログを見ます。致命的なエラーだけでなく、警告（Warning・Deprecated）も0件を目指します。警告は表示には出なくても、ページを開くたびにログに記録され、1日で数十MB〜100MB以上増えることがあります。主な原因のプラグインを更新すれば、増加は大きく減ります。

警告は数日後に見つかることもあるので再巡回する

PHPを切り替えた直後は出なかった警告が、特定のページや操作でだけ出ることがあります。全サイトの作業が終わった数日後に、もう一度全ページを巡回します。事例では、全作業の完了日に巡回し直したところ、1サイトの一部ページにPHPの警告文が表示されていて、同日にテーマ3ファイルを直しています。

MySQLの更新はサーバー移転なしでできる

新しいDBを作ってデータを移し、接続先を切り替える

MySQL 5.6のサイトは、サーバーの管理画面で新しいバージョン（8.x）のデータベースを作成し、旧データベースからデータを移して、wp-config.php の接続先を新しいデータベースに書き換えます。サーバーの移転は要りません。旧データベースは、全作業が終わってから削除します。事例では4サイトをこの方法でMySQL 8.4へ移しました。

文字コードはutf8mb4にする

移すときに、データベースの文字コード設定を utf8mb4 に変えます。古い utf8 設定では、絵文字などの4バイト文字が保存できず、お問い合わせの本文や注文メッセージの一部が化けることがあります。

移行機能を使うなら旧DBと新DBを1行ずつ比べる

サーバー会社の「新サーバーへの移行」機能でデータベースが更新される場合、データのコピーから切り替えまでに1〜2日空きます。その間に旧サーバー側だけで注文やお問い合わせが入っていないか、旧・新のデータベースを1行ずつ比較します。ネットショップなら、注文・商品・顧客・投稿・お問い合わせの件数と内容を突き合わせます。事例では差分は一時データだけで、1件だけ注文メッセージの絵文字が移行時に化けていたので元に戻しました。

更新で設定や表示が変わるプラグインは、先に控えを取る

SEOプラグインの大型更新は個別設定が消える

All in One SEO や Yoast のような SEO プラグインは、メジャーバージョンをまたぐ更新で、ページごとに設定したタイトル・説明文・検索対象外の設定が自動では引き継がれないことがあります。更新前に、全ページの個別設定を一覧にして控え、更新後に手作業で設定し直します。控えが無いと、検索結果に出さないはずのプライバシーポリシーや特定商取引法のページが検索対象になり、全ページのタイトルの区切り記号が変わります。事例では 3.3.5 から 5.0.3 への更新で、この控えを使って移し替えました。

有償プラグインはライセンスの有無を先に確かめる

Advanced Custom Fields PRO のような有償プラグインは、ライセンスキーがサイトに登録されていないと、最新版が提供されていても更新できません。制作会社が自社のライセンスで入れたまま引き渡したサイトでは、キーが無いことがよくあります。先に確かめ、無ければ、ライセンスを用意するか、公式が配布している互換プラグインに乗り換えるかを提案します。事例では、1サイトは2019年版のまま約7年分の更新が入っておらず、WordPress公式の Secure Custom Fields への乗り換えを推奨しました。

本体の画像サイズの扱いが変わる版では表示を比べる

WordPress 6.7以降では、画像の大きさの扱いが変わり、テーマによっては共通パーツの写真が小さく表示されます。目視では「少し小さいかな」程度で、比較しなければ通してしまいます。次の節の画面比較で見つけ、テーマに設定を1行足して元の大きさに戻します。

更新前後の画面を機械的に比較する

PC・スマホで同じページを撮って差分を見る

更新前の本番と、更新後のテスト環境を、同じページ・同じ幅で開いてスクリーンショットを撮り、画像の差分を取ります。PCとスマートフォンの両方、トップページ・一覧・詳細・固定ページを合わせて数十ページ。目で見て回るだけでは、少し小さくなった写真や、1本だけ読み込まれなくなったCSSは見落とします。事例ではPC60ページ・スマートフォン20ページを比較し、フッター写真の縮小をここで見つけました。

表示確認とエラーログだけでは拾えない消失がある

テーマがプラグインの内部ファイルを複製して独自の表示を足している作りだと、プラグインの更新で内部ファイルの名前が変わったとき、複製側が読み込まれなくなります。この仕組みはエラーも警告も出しません。ページは表示され、購入もできる。それでいて、商品説明の開閉部分だけが消えている、ということが起きます。主要ページについては、画面の差分だけでなく、表示されている内容そのものを更新前後で比べます。事例のネットショップでは、商品説明が5日間消えていたことに、この比較を手順に入れていなかったために気づくのが遅れました。

本番に反映したら、テスト環境に無いものを確かめる

WAFとの組み合わせは本番でしか起きない

サーバー会社の攻撃防御機能（WAF）は、テスト環境にはありません。プラグインの更新で新しくなった通信やCookieの書式を、WAFが攻撃と誤判定して遮断することがあります。これは本番でしか再現できません。事例ではWooCommerceの更新で有効になった新機能のCookieをWAFが遮断し、2ページ目以降が約4時間501エラーになりました。

実際のブラウザで複数ページを移動する

本番に反映した直後に、実際のブラウザでトップページを開き、別のページへ移動し、再読み込みし、フォームを送信します。自動巡回は1ページずつ開くので、Cookieを持った状態での2ページ目以降の動きを再現しません。人の手で数ページ移動するだけで、WAFとの組み合わせの問題は見つかります。

ネットショップは注文の流れを最後まで通す

WooCommerceなどのネットショップは、商品ページ→カート→購入手続き→注文完了→注文メールまでを、テスト注文で最後まで通します。注文メールの項目が更新で変わること（住所欄に電話番号が表示されるようになる、など）もあるので、メールの中身まで見て、変わった点を担当者に伝えます。

バージョンアップのついでに、外から入れる入口を閉じる

外から入れる入口を4つ閉じる

更新で機能が増えると、外から入れる入口も増えます。SiteGuard WP Plugin などで、REST APIへの外部アクセス制限、XML-RPCの遮断、ユーザー名の外部漏えい防止、ログイン試行の回数制限、ログイン通知を入れ、それぞれ外部から実際にアクセスして遮断されていることを確かめます。あわせて、バックアップ用プラグインの保存先がURLを直接指定すれば誰でもダウンロードできる状態になっていないかを見ます。事例の本体サイトでは、2020〜2022年のサイト全体のバックアップ7件が公開状態でした。

使っていないテーマ・プラグインは削除する

停止中のプラグインや有効でないテーマも、ファイルはサーバー上に残り、脆弱性の対象になります。使っていないものは削除します。バックアップ用プラグインが3種類入っていて保存データがサーバー容量の大半を占めている、というケースもあります。管理者アカウントのユーザー名がメールアドレスと同じなら、別のユーザー名で作り直すことも勧めます。

ネットショップではログインの画像認証を付けない

SiteGuard の画像認証は、WooCommerce のお客様のログインにもかかります。付けると、マイページや購入画面でお客様がログインできなくなります。ネットショップでは画像認証を外し、回数制限と通知で守ります。セキュリティ設定は「全部ON」が正解とは限りません。

更新後に担当者へ渡すのは、確認事項と更新しなかったもの

作業が終わったら、サイトごとに報告書を出します。必ず入れるのは、更新前後のバージョン、実施した作業、確認した項目、担当者に確認してほしいこと、作業範囲外で気づいたこと、そして更新していないものとその理由です。

• お問い合わせフォームのテスト送信。送信はこちらでできますが、届いたかは担当者の受信箱でしか確かめられません
• 管理画面のログインURLの変更。新しいURLは依頼主が管理するものなので、依頼主自身に設定してもらいます
• 更新前のデータベースの削除日。全サイトの作業完了後まで残し、削除の前に連絡します
• 更新していないもの。独自プラグイン、ライセンスが確認できない有償プラグイン、使われていない機能は、理由をつけて明記します
• 更新で変わる見え方。注文メールの項目の変化など、本体やプラグイン側の変更も書いておくと、問い合わせが減ります

更新に直接関係ない発見も報告書に入れます。Instagram表示が何年も前から止まっていた、アクセス解析が旧版のGoogleアナリティクスで計測が終了していた。どちらも担当者が気づいていないことが多く、次の判断材料になります。

実際の対応事例

本文の手順の根拠になった1件（5サイト）です。症状・原因・対応内容・結果を同じ形式で記録しています。

6年分の更新を5サイトに当てた住宅会社グループ

依頼のきっかけは「前に不正アクセスを受けた」ことでした。バージョンアップそのものより、入口が開いたままになっていた4サイトを閉じられたことのほうが、この案件では大きかったと思っています。5サイトのうち4サイトは何も起きずに終わり、起きた1サイトはWooCommerceのネットショップでした。

よくある質問（FAQ）

何年も更新していないWordPressを、一気に最新版へ上げてはいけませんか？

上げられることもありますが、途中のバージョンでデータベースや設定の持ち方が変わっていると、飛ばした分の変換がまとめて走り、壊れたときにどこで壊れたか追えません。メジャーバージョンを1つずつ上げ、各段階の前にデータベースを保存しておけば、壊れた直前に戻せます。事例では本体サイトを6.0.2から7.1.3へ13段階に分けて上げました。

PHPとWordPressはどちらを先に上げますか？

テスト環境で全部試すなら、WordPress本体→プラグイン→PHP→データベースの順が安全です。本番で直接作業すると、古いPHPのまま本体だけ上げれば「PHPが古すぎて更新できない」と止まり、PHPを先に上げれば古いプラグインやテーマが真っ白になることがあります。どちらも起きうるので、テスト環境で先に踏むのが確実です。

作業中、サイトは止まりますか？

止めません。本番と同じ構成を別環境に複製し、そこで更新作業を終えてから本番に反映します。本番への反映は数分で、その間も訪問者はサイトを見られます。ただし本番でしか起きないトラブル（WAFとの組み合わせなど）はあり、事例ではネットショップで約4時間の表示障害がありました。

MySQL 5.6の更新にサーバーの移転は必要ですか？

多くの場合、不要です。サーバーの管理画面で新しいバージョンのデータベースを作り、データを移して、WordPressの接続先を切り替えます。サーバー会社によっては「新サーバーへの移行」でデータベースが更新されることもあり、その場合は移行の前後でデータの差分を確認します。事例では4サイトを移転なしでMySQL 8.4へ、1サイトを移行機能でMariaDB 10.11へ移しました。

WooCommerceのネットショップも更新できますか？

できますが、通常のサイトより確認項目が増えます。カートから注文完了までの流れ、注文データの一致、マイページのログイン、注文メールの内容。テーマがWooCommerce用の表示ファイルを大量に持っている場合、次の大型更新で作り直しの相談が要ることもあります。事例のネットショップは、テーマのWooCommerce用表示ファイル142本に手を加えずに済みましたが、2020年頃のWooCommerceを前提にした作りだったので、その旨を報告書に書いています。

更新して不具合が出たら、元に戻せますか？

戻せます。作業前にファイル一式とデータベースを取得しているので、その時点に戻せます。段階ごとにデータベースを保存していれば、途中の段階にも戻せます。ただ、実際には「戻す」より「原因を直す」ほうが早いことが多く、事例の2件の本番トラブルも戻さずに直しています。更新前のデータベースは全サイトの完了後まで残し、削除の前に依頼主へ連絡します。

自分でやるか、頼むかの目安は？

テスト環境を立てられ、PHP 8でテーマのエラーを直せ、全ページの自動巡回と画面の差分比較ができるなら、この記事の手順で進められます。サイトヘルスに「重大な問題」が出ていて、PHPが7系以下、本体が2〜3年以上前のバージョンなら、テーマの修正とプラグインの入れ替えが発生する可能性が高いので、見てもらったほうが早いです。何を更新し、何を更新しなかったかを報告書で残してもらってください。

まとめ

• 更新が止まっているサイトは、サイトヘルスでサポート切れを確かめ、固定用プラグインが無いか、過去の侵入の入口が閉じているかを先に見る
• 本番は触らず、全ファイルとDBを取って複製したテスト環境で全部やる。公開中のサイトは止めない
• 本体はメジャーバージョンを1つずつ、各段階の前にDBを保存。プラグインは1件ずつ、そのたびに全ページを巡回。本体と拡張が分かれたものは同時に
• PHPは本体とプラグインを上げてから。古い書き方のテーマは先に直し、切り替え後は警告0件まで巡回。数日後にもう一度
• MySQLは新しいDBを作って移し、接続先を切り替える。サーバー移転は不要。移行機能を使うなら旧・新DBを1行ずつ比べる
• SEOプラグインの大型更新は個別設定の控えを取る。有償プラグインはライセンスの有無を先に確かめる
• 更新前後の画面をPC・スマホで機械的に比較する。エラーの出ない消失は、表示内容そのものを比べないと分からない
• 本番に反映したら、実際のブラウザで複数ページを移動する。WAFとの組み合わせは本番でしか起きない。ネットショップは注文を最後まで通す
• ついでにREST API・XML-RPC・ログイン制限・バックアップの公開状態を閉じる。ネットショップでは画像認証を付けない
• 報告書には、更新しなかったものとその理由、担当者に確認してほしいことまで書く