PHPが古いまま放置されたWordPressを更新した話｜プラグイン→テーマ→本体→PHPの順番を守る理由

2026年8月5日

あなたのサイト、こんなことになっていませんか？

まめすけ

「更新しませんか？」の通知が管理画面にずっと出ているけど、押すのが怖くて何年も見て見ぬふり……

私はフリーランスでWordPressサイトの制作と保守を請け負っています。先日、まったく別の依頼で入ったクライアントのサイトを開いたところ、プラグインの更新が1つも当たっていない状態でした。

さらに調べると、PHPのバージョンも数世代前のまま。ここで「とりあえず全部更新」を押していたら、サイトは止まっていたと思います。

この記事では、放置されたWordPressをどの順番で立て直したかを実際の流れに沿ってまとめます。

更新が止まったサイトは、なぜ気づかれないのか？

サイトが普通に表示されているからです。

今回のクライアントは、以前ご自身の判断でサーバー会社を変更されていました。移行そのものは完了していて、サイトも問題なく表示されていました。

ただ、そこで止まってしまったのです。

サーバーは変わったが、PHPのバージョンは移行時のまま
管理画面の更新通知は出ていたが、押していない
表示は正常なので、誰も異常だと思わない

表示が正常であることと、安全であることは別の話です。プラグインの更新には脆弱性の修正が含まれています。更新が止まっているということは、公開されている穴がそのまま残っているということです。

私が気づいたのも、別件の作業でダッシュボードを開いたときでした。依頼された作業とは無関係の場所です。

未更新は「リスク」

WordPressは簡単にサイトに反映できる一方、セキュリティー管理を怠るとサイトが表示されなくなるリスクを常に伴っています。

先日対応したマルウエア感染したサイトもトップページは正常に見えてもリンク、検索結果は全く別のサイトが表示されていました。

原因は更新管理が徹底されていなかったことでした。セキュリティホールから侵入されたんです。

以下のポイントは覚えておいてほしいです。

更新が止まっている＝公開済みの脆弱性が残っている状態であること
乗っ取られた場合、復旧費用は更新作業より確実に高くつくこと
放置期間が長いほど、更新作業自体の難易度も上がっていくこと

作業前に何を確認するのか？

環境の現状把握です。ここを飛ばすと事故ります。

受託後、真っ先に見たのがPHPのバージョンでした。管理画面 → ツール → サイトヘルス → 情報 → サーバー で確認できます。

結果は7.4。すでにサポートが終了しているバージョンでした。

ここで手が止まりました。単純にプラグインを最新版へ更新すると、古いPHPが対応できずエラーになる可能性があるからです。かといってPHPを先に上げれば、古いプラグインが即座に止まります。

確認したのは以下です。

確認項目	見る場所
PHPバージョン	サイトヘルス → 情報 → サーバー
WordPress本体のバージョン	ダッシュボード → 更新
プラグインの数と更新の有無	プラグイン一覧
テーマが親テーマか子テーマか	外観 → テーマ
`functions.php` の独自記述	子テーマ内
バックアップの有無	サーバー・プラグイン両方

特に子テーマのカスタマイズ内容は必ず控えます。ここを把握せずに進めると、更新後に「何が原因で崩れたのか」が分からなくなります。

どの順番で更新すればいいのか？

バックアップ → プラグイン → テーマ → WordPress本体 → PHP の順です。

この順番には理由があります。

順番	作業	理由
0	バックアップ取得	戻せる状態を作るのが最優先
1	プラグイン更新	古いPHPでも動く範囲でコードを新しくする
2	テーマ更新	子テーマのカスタマイズ箇所を確認しながら
3	WordPress本体更新	プラグイン・テーマが追いついてから
4	PHPバージョン変更	最後。ここで環境を上げる

考え方はシンプルで、「中身のコードを新しくしてから、器を新しくする」ということです。

逆順が危険な理由も明確です。PHPを先に上げると、古いコードが新しい厳格な判定に耐えられず致命的エラーを起こします。そうなると管理画面に入れなくなり、更新しようにも更新できないという詰み方をします。

なお「更新前に全プラグインを停止したほうが安全では」という考え方もあります。理屈としては正しいのですが、稼働中のサイトではフォームや予約機能まで止まるため、私は基本的に取りません。1つずつ更新して都度表示を確認する方が、現場では現実的です。

こちらもぜひ参考に

PHP7.4サポート終了！バージョンアップの手順と注意点 | ウェブlog PHP 7.4はすでにサポート終了済み。このままWordPressを使い続けるリスクと、PHP 8.3へのバージョンアップ手順・注意点を実際の案件をもとに解説。プラグイン互換性の確認…

更新は一気にやっていいのか？

いいえ。1つずつ、確認しながら進めます。

まとめて更新すると、壊れたときに原因が特定できません。放置期間が長いサイトほど、この差が出ます。

実際に踏んだ手順です。

STEP

完全バックアップを取得（ファイル＋データベース）

STEP

プラグインを1つ更新 → サイト表示を確認

STEP

問題なければ次のプラグインへ。これを繰り返す

STEP

全プラグイン完了後、テーマを更新 → 表示確認

STEP

WordPress本体を更新 → 管理画面と表示を確認

STEP

PHPバージョンを変更 → サイトヘルスで反映を確認

STEP

フォーム送信など動的な機能を実際に動かして確認

7番目を忘れがちですが、トップページの見た目だけでは分かりません。壊れるのは動く部分です。問い合わせフォーム、検索、カート、会員機能があれば必ず実際に操作してください。

二度と同じ状態にしないためには？

更新のタイミングを「誰かの気合い」に依存させないことです。

作業完了後、再発防止として以下を設定しました。

セキュリティプラグインの自動更新を有効化（優先度が高いため）
バックアップの自動取得を設定
クライアントに更新通知の意味を1枚にまとめて共有

テーマと本体の自動更新については、あえてオフのままにしています。マイナーアップデートでも不具合が入ることがあるためです。ここは手動で、検証してから当てる方針を取っています。

そして根本的な話をすると、保守契約があればこの状況にはなりません。月1回でも誰かがダッシュボードを開いていれば、更新が数年止まることはないからです。

まとめ

項目	内容
起きていたこと	サーバー変更後、PHPもプラグインも更新されず放置
気づきにくい理由	サイトは正常に表示されていた
更新の順番	バックアップ → プラグイン → テーマ → 本体 → PHP
進め方	1つずつ更新し、都度表示と機能を確認
再発防止	セキュリティ系のみ自動更新、バックアップ自動化、保守契約

もし更新が止まったまま環境だけが新しくなると、実際にどうなるのか。セキュリティプラグインが停止したまま、サイトは正常に表示され続けるという事例をこちらにまとめています。