WordPressをPHP 8 環境へ移行する前に：エラーを防ぐ準備と不具合への対処チェックリスト

昨今話題になっている「PHPの脆弱性問題」をきっかけに、サーバーのPHPを5系・7系から8系へ切り替えようと考えている方もいるでしょう。

ただ、古いWordPressやテーマ、プラグインを使っていると、PHPを変更した直後に「重大なエラー」が表示されたり、管理画面に入れなくなったりすることがあります。

大切なのは、移行先の安全性を確認し、バックアップと復旧手段を用意したうえで、実際のサイト構成で動作を確かめることです。

この記事では、WordPress利用者向けに、更新前の準備からエラー発生時の対応までをチェックリスト形式で整理します。コードの編集が必要な作業は補足に分けているので、まずは基本の確認から進めてください。

参考資料

PHP公式資料（英語）

• PHP公式：2026年のセキュリティ告知・追加の注意喚起
• PHP公式：サポート対象バージョン
• PHP公式：PHP 8.0で互換性がなくなった変更

関連記事

脆弱性そのものにフォーカスした記事は以下になります。

騒動が広がった経緯については以下をご確認ください。

最初に確認したい「安全性」と「互換性」

PHPは、WordPressや多くのテーマ・プラグインをサーバー上で動かすための仕組みです。WordPressの更新と、サーバーのPHPの更新は別の作業になります。

移行時には、次の二つを確認します。

画面が正常に表示されるだけでは、安全性の確認にはなりません。 反対に、PHPが修正済みでも、古いプラグインが正常に動くとは限りません。

「PHP 8系にしたから対応完了」と判断しない

2026年10月21日に公表された二つの重大な脆弱性について、PHP公式は8.2.35・8.3.36・8.4.27・8.5.12での修正を案内しています。

さらに10月23日には、特定の設定とアプリケーションの動作が重なる場合に関する追加の注意喚起が公開されました。PHP公式は、次の通常の修正リリースまでの対策として、session.upload_progress.enabledの無効化を案内しています。この追加問題は条件付きであり、すべてのWordPressサイトが該当するという意味ではありません。

レンタルサーバー利用者は、修正版の適用状況と追加の注意喚起への対応状況を、サーバー会社のお知らせやサポートで確認しましょう。この設定をwp-config.phpへ書き足すだけで対応できるとは考えないでください。

また、サーバー会社などが、元のバージョン番号を維持したまま修正を適用する場合もあります。番号だけでなく、修正済みであるという提供元の説明も確認します。

移行先はサポート期限も確認する

2026年10月24日時点で、PHP公式のサポート対象は8.2〜8.5です。8.0・8.1はすでに対象外で、8.2のセキュリティサポートも2026年12月31日に終了します。上述のとおり、業者によってはサポート期限切れのバージョンについても脆弱性を対応いただいている場合がありますが、原則はサポート対象のPHPをご利用いただくようにしてください。

移行先は、サーバー会社が提供するサポート期間内の正式版から、サイト全体で動作確認できるものを選びます。

テストに時間がかかる場合も、公開サイトを未対策のまま放置しないことが重要です。移行をすぐに完了できないときは、修正済み環境の提供や公開の一時停止など、当面の対応をサーバー会社と相談してください。

変更前の状態と「元に戻す方法」を残す

トラブル時に困りやすいのは、「変更前のバージョンが分からない」「バックアップはあるが復元できない」という状態です。

まずは、現在の構成を記録しましょう。バージョン5.2以降のWordPressでは、管理画面の「ツール → サイトヘルス → 情報 → サーバー」からPHPのバージョンを確認できます。

サイトヘルスがない古いバージョンのWordPressをご利用の場合は、サーバー管理画面やサポートでご確認ください。

記録しておきたいもの

• PHP・WordPress・テーマ・プラグインの名前とバージョン
• 子テーマや自作プラグイン、追加したPHPコードの有無
• .htaccess・.user.ini・php.iniなど、独自設定の内容
• サーバー管理画面と、SFTPまたはファイルマネージャーへの接続方法
• サーバーのエラーログの確認場所と、管理者メールの受信状況

SFTPやファイルマネージャーは、WordPressの管理画面に入れなくなっても、サーバー上のファイルを操作するための手段です。利用可能な方法はサーバー会社によって異なります。

バックアップは「ファイル」と「データベース」の両方

WordPressでは、画像やテーマなどがファイルに、記事や多くの設定がデータベースに保存されています。サイト全体を戻せるよう、両方をバックアップします。

記事をエクスポートしただけでは、サイト全体のバックアップにはなりません。

通販・予約・会員サイトでは、古いデータベースを復元すると、その後に入った注文や登録が失われる点にも注意が必要です。必要に応じて作業中の受付を止め、復元時に新しいデータをどう扱うか決めておきます。

テーマ・プラグインと「昔追加したコード」を確認する

PHP 8では、古い関数の削除や、プログラムに渡す値の扱いの変更が行われています。以前は警告だけで動いていたコードが、処理を止めるエラーになる場合もあります。

そのため、確認対象はWordPress本体だけではありません。

対象	確認すること
WordPress本体	使っているバージョンと、移行先のPHPの互換性
親テーマ・プラグイン	対応情報、更新履歴、既知の不具合、更新版の入手可否
子テーマ	functions.phpや独自テンプレートに古いPHPコードが残っていないか
スニペット	コード追加用プラグインに登録したPHPコードが動くか
独自機能	制作会社や自分で作成したプラグイン、外部連携などが動くか

特に見落としやすいのが、子テーマに追記したコードです。親テーマを最新版にしても、子テーマの独自コードは自動で修正されません。 過去の記事からコピーしたコードも、点検の対象に含めてください。

プラグインなどの「必要なPHPバージョン」は、基本的には利用できる下限を表します。「PHP 7.4以上」という表示だけで、PHP 8.4や8.5での動作まで確認済みとは判断できません。

更新が止まっている製品が必ず動かないわけではありません。ただし、移行後に不具合が見つかっても修正されない可能性があります。サイトに欠かせない機能ほど、継続して保守できるかも含めて判断しましょう。

互換性チェックツールは補助として使えますが、見落としや誤検出もあります。最終的には、実際に移行するPHPでの動作確認が必要です。

テスト環境で更新の順番と動作を確かめる

テスト環境とは、公開中のサイトを複製して、更新や設定変更を試すための場所です。「ステージング環境」と呼ばれることもあります。

本番と同じテーマ・プラグイン・データを使い、サーバーのPHP設定もできるだけ近づけて検証します。

検索エンジンに登録しない設定だけでは、アクセス制限になりません。また、複製したサイトから本物の注文通知や会員向けメールが送られないよう注意してください。

「必ずWordPressから先に更新する」とは限らない

現在のPHPで更新版が動く場合は、WordPress・テーマ・プラグインを更新して確認し、その後PHPを切り替える流れを検討できます。

一方、PHP 5系などの古い環境では、更新版そのものが動かないことがあります。この場合は、WordPressとPHPの両方を見ながら、途中で利用するバージョンを組み合わせる必要があります。

WordPress本体の組み合わせは、公式のPHP互換性表（下記）で確認できます。ただし、この表が示すのは本体の互換性であり、テーマやプラグインまで保証するものではありません。

PHP 5→7→8と、すべての世代を順番に経由する必要はありません。 各段階で動作する組み合わせを選び、変更するたびに確認することが大切です。移行の途中で古いPHPが必要になる場合は、外部公開しない隔離環境で扱う方針を専門家と相談してください。

長年更新していないサイトや独自開発の多いサイトは、この段階で制作会社・保守担当者に相談すると、作業範囲を決めやすくなります。

トップページ以外も、実際に操作する

トップページが表示されても、フォームや投稿保存だけが失敗する場合があります。保存済みのページを表示する「キャッシュ」の影響もあるため、必要に応じてキャッシュを削除し、ログイン中とログアウト後の両方で確認しましょう。

確認対象	試したい操作
公開ページ	トップ、記事、固定ページ、カテゴリー、検索、ページ送りを開く
投稿編集	エディターを開き、下書き保存・プレビュー・公開を試す
画像	アップロードし、縮小画像が生成されるか確認する
フォーム	テスト送信し、管理者通知・自動返信の到着まで確認する
会員機能	登録、ログイン、パスワード再設定を試す
通販・予約	テストモードで注文・決済・予約と、その後の反映を確認する
自動処理	予約投稿、定期バックアップ、通知、外部サービスとの同期を確認する

すべてのサイトで全項目を試す必要はありません。自分のサイトが使っている機能を一覧にして確認します。

エラーが出たら、変更を重ねる前に記録する

エラーが発生すると、設定を次々に変更したくなるかもしれません。しかし、変更が増えるほど原因を追いにくくなります。

まずは、その時点の情報を残してください。

• 発生日時と、エラーが出たページ・操作
• 変更前後のPHPのバージョン
• エラーメッセージの全文、ファイル名、行番号
• 直前に更新・変更したもの

「重大なエラーが発生しました」という画面だけでは、原因を特定できません。WordPressからの通知メールや、サーバーのエラーログを確認します。

よくあるエラーの読み方

表示・症状	意味の目安と確認先
Fatal error、Uncaught TypeError	処理が止まるエラー。該当コードと、渡されている値などを確認
Call to undefined function	必要な関数が見つからない。古い関数の削除、PHP拡張機能不足、読み込み不良などを確認
Parse error	プログラムの書き方を解釈できない。構文や編集ミスなどを確認
Deprecated	古い書き方への非推奨の通知。通常は単独で処理を止めないが、更新・修正を検討
Allowed memory size exhausted	設定されたメモリ上限に到達。設定値と処理内容を確認
HTTP 500、真っ白な画面	これだけでは原因不明。サーバー側のログで確認

Deprecatedなどの通知が画面に混ざり、結果として通信や表示を乱す場合もあります。画面から通知を隠すことと、原因となるコードを修正することは分けて考えましょう。

また、ログにWordPress本体のファイル名が出ても、本体が原因とは限りません。 プラグインから渡された値が不適切で、本体側の処理で止まっている場合もあります。表示された行を削除するなどの修正は避け、処理の流れを確認します。

原因を絞り込む基本手順

テスト環境では、次のように一つずつ確認します。

• ログや通知メールが示すプラグイン・テーマ・追加コードを確認する
• 原因と思われるプラグインや追加コードを一時停止する
• 解決しなければ、通常のプラグインをまとめて停止して確認する
• 移行先PHPに対応するWordPress標準テーマへ切り替えて確認する
• 正常に動く状態から、一つずつ有効に戻して再現条件を調べる

この方法で分かるのは、「どの構成で問題が起きるか」です。特定のプラグインを有効にしたときだけエラーが出ても、別のプラグインとの組み合わせが原因のこともあります。

本番でフォーム・決済・会員機能などを停止すると、利用者にも影響します。本番での切り分けが必要な場合は、受付停止や案内も含めて実施してください。

管理画面に入れないときの復旧方法

リカバリーモードのメールを確認する

WordPress 5.2以降には、致命的なエラーが起きた際に復旧作業を助ける「リカバリーモード」があります。管理者宛てのメールに専用リンクが届いていれば、そこからログインできる場合があります。

ただし、メールが届かない場合や、この機能では対応できないエラーもあります。

リカバリーモードで管理画面に入れたことと、一般の訪問者が正常に閲覧できることは別です。 問題のある機能を正式に停止・修正し、リカバリーモードを終了してから公開側も確認します。

ファイルマネージャーなどでプラグインを一時停止する

原因のプラグインが分かっている場合は、そのフォルダー名を変更して、通常の場所から読み込まれないようにする方法があります。

例えば、対象がexample-pluginなら、サーバーのファイルマネージャーやSFTPで、wp-content/plugins/example-pluginをexample-plugin-disabledという名前に変更します。

これは架空の名前を使った例です。実際の対象を確認し、元の名前を記録してから操作してください。最初から削除する必要はありません。

フォルダー名を元に戻すと、状態によっては再び読み込まれる可能性があります。管理画面に入れたらプラグイン一覧を開き、停止状態を確認してください。修正前の再有効化は、同じエラーを起こす可能性があります。

原因が分からない場合は、pluginsフォルダー全体を一時的に変更する方法もあります。ただし、多くの機能がまとめて停止するため、個別の停止で済むかを先に検討します。

通常のプラグインを止めても直らない場合

次のようなものも確認対象です。

• 子テーマや、独自に追加したPHPコード
• mu-pluginsにある、常時読み込まれるプラグイン
• object-cache.phpやadvanced-cache.phpなどの特別な読み込みファイル
• .user.iniなどに残った、古いPHP設定やファイルの読み込み指定
• PHPの拡張機能不足、メモリ上限、サーバー側の設定

これらにはキャッシュやセキュリティ機能に関わるものもあります。役割を確認せず削除せず、サーバー会社や開発元へ相談してください。

古いPHPに戻しても、安全性の問題は残る

障害の切り分けやデータ救出のために、以前のPHPへ一時的に戻す必要が生じることはあります。しかし、未修正のPHPに戻して公開を続けることは、脆弱性への対応になりません。

すぐに移行できない場合は、サーバー会社と相談し、外部から脆弱なPHPを実行されない状態にしたうえで作業します。静的な案内ページを使う場合も、既存のPHPへの直接アクセスが残らない設定が必要です。

WordPressのメンテナンスプラグインで画面を隠すだけでは、PHP自体の脆弱性対策にはなりません。

本番切り替え後も「保存・送信・自動処理」を確認する

テストで正常に動いたら、本番切り替え直前のバックアップを取得し、確認済みの手順で作業します。

テスト環境のデータベースをそのまま本番へ上書きすると、テスト開始後に本番で増えた記事・注文・会員情報などが失われるおそれがあります。反映する内容と方法は、サイトの運用に合わせて決めてください。

PHPの切り替えに伴って、メモリ上限やアップロード上限、利用できるPHP拡張機能が変わることもあります。「画像だけアップロードできない」「大きいファイルだけ失敗する」といった場合は、テーマ・プラグインに加えて、サーバー側の設定も確認しましょう。

サーバーの定期実行機能や、コマンド操作用のWP-CLIを使っている場合は、そちらが利用するPHPも確認します。Webサイト用のPHPを変更しても、別の実行環境まで同時に切り替わるとは限りません。

補足：詳細なエラーログが必要な場合

ここからは、ファイル編集に慣れた方向けの補足です。通常は、サーバー会社が提供するエラーログや、WordPressの通知メールの確認から始めてください。

WordPressのデバッグ機能を使うと、詳しい情報をログへ記録できます。原則として、アクセスを制限したテスト環境で使用します。

wp-config.phpをバックアップし、既存の設定を確認してから、次のように設定します。同じ項目を重複して定義せず、すでにある場合はその値を編集してください。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Code language: PHP (php)

記載位置は、通常は「編集が必要なのはここまでです」などのコメントより前です。繰り返しになりますが、functions.phpではなく、wp-config.phpへ設定します。

通常、ログはwp-content/debug.logに保存されます。問題の操作を再現し、その時刻に記録された内容を確認してください。WordPressの起動前に発生するエラーなどは、このログに残らないため、サーバー側のログも確認します。

画面へのエラー表示を止めても、ログファイルへの外部アクセスまで防げるわけではありません。 ログの閲覧制限を確認し、調査後はデバッグを無効にして、不要なログを削除または保護します。

公開のフォーラムなどに相談する際は、PHP・WordPress・テーマ・プラグインのバージョン、再現する操作、関係するエラーを伝えると状況が分かりやすくなります。一方で、パスワード、APIキー、個人情報、リカバリーモードの専用URLなどは公開しないでください。