WordPress本体、プラグイン、テーマの更新後に不具合が出ても、最初から本体全体をダウングレードする必要はありません。原因となった1要素だけを戻すか、更新直前の正常なバックアップへ復元する方が安全な場合が多いからです。
この記事では、何を戻すべきかの判断、ダウングレード前の準備、WordPress本体・プラグイン・テーマを戻す方法、作業後の確認と最新版へ再更新するまでの流れを解説します。
WordPressをダウングレードする前に戻す対象を決める
「更新後に壊れた」という情報だけでは、本体、テーマ、プラグイン、PHP、キャッシュのどれが原因か分かりません。直前に変更した対象と症状を整理し、最小範囲を戻します。
| 状況 | 最初に検討する対応 | 本体ダウングレード |
|---|---|---|
| 特定プラグイン更新後だけエラー | そのプラグインを停止・旧版へ戻す | 通常は不要 |
| テーマ更新後に表示崩れ | 子テーマ・キャッシュ確認、テーマ旧版へ戻す | 通常は不要 |
| WordPress本体更新後に複数機能が停止 | 互換性確認、更新直前バックアップ、コア旧版 | 候補になる |
| PHP変更後にエラー | PHP対応状況とエラーログを確認しPHPを戻す | 原因がコアとは限らない |
| 原因不明でサイト全体が不安定 | 正常時点の完全バックアップへ復元 | 部分作業より復元が安全な場合 |
| 脆弱性修正を含む更新を戻したい | 代替修正版・互換版を探す | 長期運用は避ける |
本体・プラグイン・テーマの現在バージョンを確認し、直前更新の日時と変更内容を記録します。バージョン管理の基本で、更新対象と自動更新の設定も確認してください。
ダウングレードが必要になる主なケース
- 更新直後から管理画面または公開画面で致命的エラーが出た
- テーマやプラグインが新しいWordPress本体へ未対応だった
- 外部API・決済・予約等の連携が特定版で動かなくなった
- 新しい版で既知の不具合があり、修正版を待つ必要がある
- 検証環境と本番環境のバージョンを一時的に合わせる必要がある
単に編集画面の場所が変わった、キャッシュで表示が古い、設定が初期化されたように見える場合は、ダウングレードで解決しないことがあります。エラーログ、ブラウザーコンソール、プラグイン停止、デフォルトテーマで原因を切り分けます。
また、古いバージョンへ戻すほど安全になるわけではありません。WordPress公式のリリースアーカイブでも、古い版は安全でない可能性があり、現行系の最新版だけが積極的に保守される旨が案内されています。ダウングレードは修正版または互換版へ進むまでの一時対応と考えます。
ダウングレード前に必ずやること
作業前のバックアップは、現在の壊れた状態を保存するだけでは足りません。可能なら更新直前の正常なバックアップと、現在状態の両方を確保します。
- 事前バックアップでデータベースとWordPressファイルを保存する
- 現在のWordPress本体・テーマ・プラグイン・PHPのバージョンを記録する
- エラーログ、更新履歴、直前の操作、発生時刻を保存する
- 復元または旧版を入手する公式配布元を確認する
- ステージング環境で同じ手順を再現する
- メンテナンス時間、担当者、失敗時の復元判断を決める
EC、予約、会員サイトでは、バックアップ取得後にも注文・予約・会員更新が発生します。古いデータベースへ戻すと、その間の取引が失われる可能性があります。ファイルだけ戻すのか、データベースも戻すのかを業務担当者と決めてください。
復元ファイルがあるだけでなく、管理画面へ入れない状態でもサーバー側から戻せることを確認します。容量、暗号化、パスワード、保管先もチェックしてください。
WordPress本体をダウングレードする方法
安全性の高い順は、更新直前の完全バックアップ復元、対応するロールバックツール、手動でコアファイルを入れ替える方法です。データベースも変更された更新では、ファイルだけ旧版に戻すより、同じ時点のバックアップへ復元する方が整合しやすくなります。
方法1:更新直前のバックアップへ復元する
正常だった時点のデータベースとファイルをセットで戻します。注文・予約など更新後のデータを失う場合があるため、差分を退避し、復元後に戻せるかを確認します。ホスティングのステージング復元機能がある場合は、先に別環境へ戻して検証します。
方法2:Core Rollbackを使う
Core Rollbackは、WordPress.orgのコアパッケージを使い、WordPressの更新処理に近い流れで指定バージョンへ切り替えるためのプラグインです。利用前に公式ページの対応バージョンと更新状況を確認し、メンテナンス時間を確保します。
- バックアップとステージング検証を完了する
- 公式ディレクトリからCore Rollbackをインストール・有効化する
- ツール画面で戻すWordPressバージョンを選ぶ
- 表示された警告と対象版を再確認してロールバックを実行する
- 管理画面へ再ログインし、データベース更新画面が出た場合は内容を確認する
- 公開画面・管理画面・フォーム等を確認する
旧版のまま自動更新が走ると意図せず再更新されます。原因調査中の自動更新設定を確認し、修正版の検証後は速やかに安全な現行版へ戻します。
方法3:コアファイルを手動で入れ替える
管理画面を使えない、ロールバックツールが動かない場合の最終手段です。WordPress公式リリースアーカイブから必要版を取得し、サーバー上のコアファイルを入れ替えます。
wp-contentフォルダーを上書き・削除しないwp-config.php、.htaccess、ユーザー作成ファイルを保護する- 旧版の
wp-adminとwp-includesを正しく配置する - ルートのコアファイルを公式手順に沿って入れ替える
- ファイル権限、所有者、キャッシュ、PHP互換性を確認する
一部ファイルだけ新旧が混在すると、別のエラーを作ります。手動作業に慣れていない場合は、本番で試行錯誤せずバックアップ復元または保守担当者へ切り替えてください。
プラグインをダウングレードする方法
不具合が特定プラグインの更新直後に始まったなら、まずそのプラグインだけを戻します。停止してもサイトが動く機能なら、旧版へ戻す前に無効化して症状が消えるか確認します。
WP Rollbackを使う
WP Rollbackは、WordPress.orgで配布されているプラグイン・テーマの過去版へ切り替えるためのプラグインです。すべての製品や有料版に対応するわけではなく、利用可能な配布パッケージの範囲で動作します。
- 対象プラグインの設定・データをバックアップする
- WP Rollbackを公式ディレクトリから導入する
- プラグイン一覧で対象製品のロールバック画面を開く
- 不具合前に使用していた版を選び、変更内容を確認する
- ロールバック後にキャッシュを消し、主要機能をテストする
- 自動更新を確認し、修正版の公開を監視する
公式配布元の旧ZIPを手動で戻す
有料プラグインやWordPress.org外の製品では、開発元が提供する旧版ZIPまたはバックアップを使います。データベース移行を伴うプラグインでは、ファイルだけ戻しても設定・テーブルが新しいまま残ることがあります。開発元のロールバック手順を優先してください。
決済、予約、フォーム、セキュリティ系プラグインを古いまま使い続けると、機能停止や脆弱性のリスクがあります。互換性修正版、代替プラグイン、設定変更のどれで現行版へ戻すかを同時に決めます。
テーマをダウングレードする方法
テーマ更新後の表示崩れは、親テーマの仕様変更、子テーマの上書き、キャッシュ、テンプレート変更が組み合わさって起きます。旧版へ戻す前に、デフォルトテーマで表示できるか、追加CSS・子テーマ・最適化を確認します。
WP Rollbackまたは公式旧版を使う
WordPress.org配布テーマはWP Rollbackで戻せる場合があります。有料テーマは販売元の旧版・バックアップを使います。現在のテーマフォルダーを直接編集している場合、再インストールで変更が消えるため、差分を先に退避してください。
子テーマとの互換性を確認する
親テーマを旧版にすると、子テーマが新しい関数・テンプレート・CSSクラスを前提にして動かなくなることがあります。親子の組み合わせをステージングで再現し、ヘッダー、メニュー、固定ページ、投稿、フォーム、スマートフォン表示を確認します。
ブロックテーマでは、データベースに保存されたテンプレート・スタイルがテーマファイルより優先される場合があります。テーマファイルを戻しても見た目が戻らないときは、サイトエディター内の変更履歴やユーザーカスタマイズも確認してください。
ダウングレード後に確認すること
管理画面へ入れたことだけで成功と判断せず、サイトの主要機能を確認します。
- トップ、投稿、固定ページ、検索、404ページ
- 管理画面ログイン、投稿編集、メディアアップロード
- フォーム送信、メール通知、スパム対策
- ECのカート・決済、予約の空き枠・通知
- ユーザー登録、ログイン、権限
- キャッシュ、CDN、WAF、バックアップ
- PHPエラー、JavaScriptエラー、サーバーログ
- モバイル表示と主要ブラウザー
データベースの構造が新しい版へ更新済みの場合、旧ファイルとの組み合わせで隠れた不整合が残ることがあります。編集・保存まで試し、エラーが続く場合は同じ時点のデータベースバックアップへ戻すか、開発元へ確認します。
ダウングレードした版、理由、作業者、日時、影響、再更新条件を記録してください。記録がないと、後日別の担当者が通常更新を行い、同じ不具合を再発させます。
安全な最新版へ再更新する
ダウングレードは最終状態ではありません。原因となった互換性問題を解決し、安全な版へ戻す計画を立てます。
- 公式の不具合情報・変更履歴・サポート回答を確認する
- 原因プラグイン・テーマの修正版または代替手段を用意する
- ステージング環境を本番に近い構成へ更新する
- 主要機能とデータ更新をテストする
- 本番の最新バックアップを取得して更新する
- 更新後の監視とロールバック条件を決める
古いWordPress本体をインターネット公開したまま放置せず、不要なログイン経路を制限し、WAFや監視を確認します。修正版がすぐ出ない場合も、影響機能を停止する、代替プラグインへ移す、保守版へ切り替えるなど、旧版依存を終える方法を検討してください。
よくある質問
必ず消えるわけではありませんが、データベース構造やプラグインとの互換性が崩れる可能性があります。ファイルとデータベースをバックアップし、可能なら同じ時点の正常なバックアップへ復元してください。
可能です。WordPress.org配布製品ならWP Rollback、その他は開発元の旧版ZIPやバックアップを使います。データベース更新を伴う製品は、開発元の手順を優先してください。
長期運用は避けます。古い版には既知の脆弱性や互換性問題が残る可能性があります。原因を解消し、ステージングで検証してから安全な現行版へ再更新してください。
まとめ
WordPressの更新後に不具合が出たら、直前に変えた本体・プラグイン・テーマ・PHPを特定し、最小範囲だけを戻します。正常な更新直前バックアップがある場合は、ファイルとデータベースを同じ時点へ復元する方法が最も整合しやすくなります。
本体はバックアップ復元、Core Rollback、手動入れ替えの順に検討し、プラグイン・テーマはWP Rollbackや開発元の旧版を使います。作業後は主要機能とログを確認し、ダウングレードを一時対応として記録したうえで、安全な最新版へ再更新しましょう。
