「このサイトで重大なエラーが発生しました」は、プラグインやテーマ、書き足したコードの中で、WordPressが動き続けられない種類のエラー（致命的なエラー）が起きたときに出る表示です。真っ白な画面（いわゆるホワイトスクリーン）も、PHPやデータベースのエラーで起きます。サーバーの一時的な不調でなければ、待っていても直りません。来た人には何も見えていないので、その日のうちに直します。
直す順番は次のとおりです。①直前に何を更新・追加したかを思い出す。②サイトの管理者のメールアドレスに、WordPressからの知らせ（件名に「技術的な問題」とあるメール）が届いていないか探す。届いていれば、メールのリンクから「リカバリーモード」でログインし、原因のプラグインを止める。③メールがなければ、FTP（サーバーにファイルを出し入れする方法）かサーバーの管理画面で、プラグインのフォルダの名前を変えて一括で止め、だめならテーマを切り替える。④それでも原因が分からなければ、デバッグ（エラーの中身を記録する設定）を有効にして、エラーの記録を読む。
この記事の手順は、2026年10月時点で WordPress.org の公式ドキュメント（WordPress の一般的なエラー、WordPress でのデバッグ）と、開発者向けの公式の説明で確かめたものです。
この表示が出るとき、サイトで何が起きているか
WordPressは、PHP（WordPressを動かしているプログラムの言語）の致命的なエラーを見つけると、ページを途中で止め、代わりに決まった文を出します。開発者向けの公式の説明によると、出る文は開いた場所によって違います。
| 開いた場所 | 出る表示（日本語の画面） |
|---|---|
| サイトの表側 | 「このサイトで重大なエラーが発生しました。」と、WordPress のトラブルシューティングの説明へのリンク |
| 管理画面やログイン画面 | 上の文に続けて、対応手順はサイト管理者のメールを確認するよう求める文 |
| リカバリーモード中 | エラーでリカバリーモードに入ったこと、テーマとプラグインの画面を確かめるよう求める文 |
日本語の画面では、管理画面側の表示は「このサイトで重大なエラーが発生しました。対応手順については、サイト管理者のメール受信ボックスを確認してください。」のようになります（WordPress.org の日本語フォーラムに寄せられた表示の例による。言い回しは版によって少し違うことがあります）。
真っ白な画面について、WordPress.org のドキュメントは、PHPのエラーやデータベースのエラーが、メッセージのない真っ白な画面として出ることがあると説明しています。原因の候補として挙げられているのは、プラグインどうしやWordPressとの相性、テーマの問題です。現場で心当たりになりやすいのは、次のような変更の直後です。
- プラグインやテーマを更新した、新しく入れた（自動更新も含みます）。
- テーマのファイル（functions.php など）に、どこかで見つけたコードを書き足した。
- サーバーの管理画面で PHP のバージョンを上げた、またはサーバー会社が上げた。
- アクセスや処理が増え、PHPの使えるメモリーが足りなくなった（公式のドキュメントでも、メモリーの上限を上げることが対処の一つに挙げられています）。
なお、更新のあとに「メンテナンス中」の表示（日本語の言い回しは版によって違います）が消えない場合は、別の原因で起きるものです。そちらはWordPressのメンテナンスモードの解除をご覧ください。
最初の5分でやること：変えたものと、出ている場所を確かめる
- 直前に何をしたかを書き出します。誰が、いつ、どのプラグインやテーマを更新したか。社内の別の人や制作会社が作業していないかも聞きます。原因の見当がつけば、止めるのはそのプラグイン一つで済みます。
- どこで出ているかを確かめます。トップページも、ほかのページも、管理画面も全部か。特定のページだけか。スマートフォンの回線など、別の端末からも開いてみます。
- サイトの管理者のメールアドレスの受信箱と、迷惑メールのフォルダを見ます。
- あわてて、ほかのプラグインの更新や削除をしないでください。原因が分かりにくくなり、設定が消えることもあります。
管理者宛のメールから「リカバリーモード」で直す手順
WordPressには、プラグインやテーマが致命的なエラーを起こしたことを見つけて、管理者にメールで知らせる仕組みがあります（WordPress 5.2 から入った「リカバリーモード」）。開発者向けの公式の説明では、メールの送り先は、管理画面の「設定」→「一般」にある管理者のメールアドレスです（wp-config.php に RECOVERY_MODE_EMAIL という設定で別のアドレスを指定していれば、そちら）。
メールの件名は、英語では「Your Site is Experiencing a Technical Issue」、日本語の画面では「[サイト名] サイトで技術的な問題が発生しています」のようになります。本文には、エラーの原因になったプラグインやテーマ、エラーが起きたページ、リカバリーモードに入るためのリンクが書かれています。標準では、このリンクの有効期限は1日で、同じ間隔より短くは次のメールが送られません。期限が切れたあとにまたエラーが起きれば、新しいリンクが届きます。
- メールの中のリカバリーモードのリンクを開きます。
- ログイン画面が出るので、管理者のアカウントでログインします。
- 管理画面の上に、エラーを起こしたプラグインやテーマが一時停止されているという案内が出ます。「プラグイン」の画面（テーマが原因なら「外観」→「テーマ」）を開き、どれが原因かを確かめます。
- 原因のプラグインを「無効化」します。テーマが原因なら、別のテーマに切り替えるか、テーマの問題を直します。
- 画面上部のツールバーにある、リカバリーモードを終えるボタンを押します。
- 別のブラウザかスマートフォンで、サイトの表側が普通に開くかを確かめます。
6番目が大事です。WordPress.org の開発者向けの記事によると、リカバリーモードで原因のプラグインが止まって見えるのは、リカバリーモードに入ったその人のブラウザだけです（ブラウザに保存した Cookie で見分けています）。自分の画面で直ったように見えても、プラグインを無効化するまでは、ほかの人にはエラーが出たままです。リカバリーモードを終えると、止まっていたものは元どおり動きます。まだ壊れていれば、エラーも戻ります。
無効化したプラグインは、そのままでは機能が止まっています。お問い合わせフォームやセキュリティのプラグインだった場合は、そのあいだフォームが受け付けない、守りが外れている、ということです。作者から修正版が出ていないかを確かめ、出ていなければ、メールや画面に出ているエラーの文をそのまま添えて、作者のサポートに問い合わせます（公式の記事でも、エラーの文を添えて問い合わせることが勧められています）。急ぐなら、同じ役目の別のプラグインに替えることも考えます。
メールが届かないとき：FTPでプラグインとテーマを止める
メールが届かないのは、管理者のメールアドレスが前の担当者や制作会社のものになっている、サーバーからのメールが受け取る側で止められている、前のメールから1日たっていない、のどれかを疑います。その場合は、サーバーのファイルを直接触って止めます。WordPress.org の「WordPress の一般的なエラー」で案内されている方法です。
プラグインを一括で止める
- FTP のソフトか、サーバー会社の管理画面にあるファイルの管理の機能で、サイトのファイルを開きます。
- WordPressが入っているフォルダ（wp-config.php があるところ）の中の wp-content を開きます。
- plugins というフォルダの名前を plugins_old に変えます。これですべてのプラグインが止まります。
- サイトを開き直し、直ったかを確かめます。直れば、原因はプラグインのどれかです。
- 管理画面にログインし、「プラグイン」の画面を一度開きます。そのあとでフォルダの名前を plugins に戻すと、プラグインは止まった状態で一覧に並びます。
- 一つずつ「有効化」して、そのたびにサイトを確かめます。エラーが戻ったものが原因です。それを止めたまま、残りを有効に戻します。
直前に更新したプラグインが分かっているなら、plugins フォルダ全体ではなく、その中のそのプラグインのフォルダだけ名前を変える方が早く、ほかの機能も止まりません。
プラグインでなければ、テーマを切り替える
プラグインを全部止めても直らなければ、テーマを疑います。管理画面に入れるなら、「外観」→「テーマ」で WordPress の標準のテーマ（Twenty で始まる名前のもの）を有効にします。管理画面に入れないなら、wp-content/themes の中の、いま使っているテーマのフォルダの名前を変えます。WordPressは標準のテーマに切り替わります（そのためには標準のテーマが入っている必要があります）。
子テーマ（元のテーマの上に、自社用の変更だけを重ねたテーマ）を使っている場合は、子テーマのフォルダから試します。自社用に書き足したコードは、ふつう子テーマの側（子テーマの functions.php など）に入れるからです。直ったら名前を戻し、「外観」→「テーマ」で元のテーマを有効にし直して、メニューやウィジェット（サイドバーなどの部品）の配置が元どおりかを確かめます。
表示が「重大なエラー」ではなく「500 Internal Server Error」の場合は、.htaccess（サーバーの動きを指示する設定ファイル）が壊れている可能性もあります。確かめ方はWordPressにログインできないときの中で書いています。
原因が分からないとき：デバッグを有効にしてエラーの記録を読む
メールも届かず、どのプラグインかの見当もつかないときは、WordPressにエラーの中身をファイルに書き出させます。WordPress.org の「WordPress でのデバッグ」で案内されている設定です。
- FTP などで wp-config.php（WordPressの基本の設定ファイル）をパソコンに保存し、編集前の複製を残します。
- ファイルの中に「define( ‘WP_DEBUG’, false );」という行があるかを探します。あれば、その行を消して、次の4行に置き換えます。なければ、「stop editing」（日本語版では「編集が必要なのはここまで」という趣旨）と書かれた行より上に、次の4行を足します。同じ設定を二度書くと、先に書いた方が使われるので、重ねて書かないでください。
define( ‘WP_DEBUG’, true );
define( ‘WP_DEBUG_LOG’, true );
define( ‘WP_DEBUG_DISPLAY’, false );
@ini_set( ‘display_errors’, 0 ); - 保存して、サーバーの同じ場所に上書きで戻します。
- エラーが出るページを、もう一度開きます。
- wp-content の中に debug.log というファイルができているので、パソコンに保存して開きます。
- 「PHP Fatal error」で始まる行を探します。
足した4行は、上から順に、デバッグの状態にする、エラーを wp-content の debug.log に書き出す、エラーを画面に出さない（4行目も同じ目的）、という指定です。画面に出さないのは、来た人にエラーの中身（サーバーの中のファイルの場所など）を見せないためです。
エラーの行は、たとえば「PHP Fatal error: Uncaught Error: … in /…/wp-content/plugins/（プラグインのフォルダ名）/（ファイル名）.php on line 12」のような形です（形の例です）。読むところは、「in」のあとのファイルの場所だけで足ります。wp-content/plugins/ の次にある名前が原因のプラグイン、wp-content/themes/ の次にある名前が原因のテーマです。それが分かれば、そのフォルダだけ名前を変えて止めます。英語の部分は、作者に問い合わせるときにそのまま貼り付けます。
終わったら、wp-config.php を元の複製に戻し、debug.log を消してください。公式のドキュメントも、WP_DEBUG などのデバッグの道具を本番のサイトで使うことは勧めていません。記録には、サーバーの中のファイルの場所など、外に見せたくない情報が載ります。サーバー会社によっては、管理画面で PHP のエラーの記録（エラーログ）を見られるところもあるので、そちらで足りる場合もあります。
更新の直後に起きたなら：元に戻すという選択
更新の直前のバックアップがあり、原因探しに時間がかかりそうなら、バックアップから戻すのがいちばん早いこともあります。ただし、戻すと更新も取り消されます。その更新が、セキュリティの穴をふさぐためのものだった場合、古いままにしておくことには別の危険があります。戻すのはサイトを開けるようにするための一時の手当てと考え、原因を確かめたうえで、あらためて更新してください。バックアップの取り方と戻し方はWordPressのバックアップ方法に、安全な更新の順番はWordPressのアップデート手順にまとめています。
サーバー側で PHP のバージョンを上げた直後なら、古いプラグインやテーマが新しい PHP に対応していないことが考えられます。サーバーの管理画面でいったん元のバージョンに戻せば表示は戻りますが、それも一時の手当てです。対応していないプラグインやテーマを更新するか、替えてから、あらためてバージョンを上げます。考え方はWordPressのバージョン確認と最新バージョンに書いています。メモリーの不足が原因と分かった場合、共用のサーバーではサーバー会社に上限を上げてもらう必要があることもあります（公式のドキュメントによる）。
急いで直す場合と、落ち着いて確かめてよい場合
| 状態 | 判断 |
|---|---|
| 表側も管理画面も、全部のページで出る | すぐ直す。来た人は何も見られず、問い合わせも届かない |
| 一部のページだけで出る | その日のうちに直す。そのページで使う機能のプラグインを疑う |
| サイトは普通に見えるが、知らせのメールだけ届いた | メールにあるページを開いて確かめる。見えていれば急がないが、原因は確かめる |
| 自分の画面だけ直っている（リカバリーモード中） | ほかの人にはまだ出ている。原因を無効化してから終える |
| 原因のプラグインを止めて直った | 止めた機能（フォーム、守り）の代わりを早めに用意する |
自分で触ってよいのは、リカバリーモードでの無効化と、FTPでのフォルダの名前の変更までです。どちらも、有効化し直す・名前を戻すことで元に戻せます。wp-config.php の書き換えは、一文字の誤りでサイト全体が止まるので、ファイルの編集に慣れていなければ、制作会社や詳しい人に頼んでください。頼む相手がいない、制作会社と連絡がつかない、という場合は、当社に相談することもできます。出ている表示と、直前にした作業をお知らせください。
次に起こさないための準備
- 「設定」→「一般」の管理者のメールアドレスを、会社で確実に受け取れるアドレスにする。リカバリーモードのメールは、ここに届きます。
- 更新の前にバックアップを取り、プラグインは一つずつ更新して、そのたびにサイトを開いて確かめる。
- テーマのファイルを、管理画面から直接書き換えない。コードを足すときは、複製を取り、元に戻せる状態で行う。
- FTP やサーバーの管理画面の入り方を、社内の決まった場所に控えておく。いざというとき、ここに入れないと何もできません。
- 使っていないプラグインは消す。止まっているだけのプラグインも、更新の手間と危険の元になります。
当社のサイトでは、見た目に関わる変更は、AIにブラウザで複数の画面幅（320〜1920px）を撮影させ、表示の崩れやエラーがないかを確かめてから反映しています。小さな会社でそこまでしなくても、変更のあとにトップと主なページ、お問い合わせのページを開いてみるだけで、エラーに気づくのが「お客さまからの連絡」より先になります。日々の点検で何を見るかはWordPressの保守とはにまとめています。
当社は、中小企業や士業のホームページの運営に加わり、問い合わせが来るまでを引き受けています。更新や不具合の対応は、その途中で欠かせない作業の一つです。「更新のたびに何か起きないか不安で、更新を止めている」という状態も含めて、お問い合わせからご相談ください。
参考にした公式の説明
- WordPress.org 日本語：WordPress の一般的なエラー
- WordPress Developer Resources：Common WordPress Errors（英語）
- WordPress.org 日本語：WordPress でのデバッグ
- WordPress Developer Resources：Debugging in WordPress（英語）
- Make WordPress Core：Fatal Error Recovery Mode in 5.2（英語）
- WordPress Developer Resources：WP_Fatal_Error_Handler::display_default_error_template（表示される文、英語）
- WordPress Developer Resources：send_recovery_mode_email（メールの件名と本文、英語）
- WordPress Developer Resources：get_recovery_mode_email_address（メールの送り先、英語）
- WordPress Developer Resources：get_email_rate_limit（メールの間隔、英語）
※手順と表示は、2026年10月8日に上の公式の説明で確かめたものです。WordPressの版や、テーマ・プラグイン、サーバーによって、表示や手順が違うことがあります。