- エラー
「このサイトで重大なエラーが発生しました」6つの原因と対処法
WordPressサイトを開いたら「このサイトで重大なエラーが発生しました。詳細についてはサイト管理者のメール受信箱を確認してください。」とだけ表示され、ページが何も見えなくなった。
PHPのバージョンを上げた直後、functions.phpにコードを貼り付けた直後、プラグインを更新した直後など、何かの操作のすぐあとに起きることが多いエラーです。
実はこの画面は「WordPressがPHPの致命的なエラーを検知して、代わりに出している案内」であり、サイトのデータが消えたわけではありません。原因は数種類に絞られており、順番に確認すれば多くの場合は自力で復旧できます。
この記事では、2017年から累計3,500件以上のWordPressサーバー移転・保守を行ってきたサイト引越し屋さんが、実際に保守クライアントから寄せられた相談をもとに、「重大なエラー」が起きる原因と原因別の対処法、再発を防ぐ運用方法を解説します。
「管理画面にも入れず、どこを修正すれば直るのか分からない」
「下手にファイルを触ってサイトが完全に消えてしまうのが怖い」
そんなときは私たちサイト引越し屋さんにお任せください。
WordPress専門のエンジニアが原因を迅速に特定し、安全に復旧いたします。
「このサイトで重大なエラーが発生しました」とはどんなエラーか
「このサイトで重大なエラーが発生しました」は、WordPressを動かしているPHPプログラムが途中で停止(Fatal error)したときに、WordPress本体が訪問者向けに表示する案内画面です。
サイトのデータや記事が消えたわけではなく、「プログラムのどこかで致命的なエラーが起きている」というサインです。
以前の「真っ白な画面」の代わりに表示される
WordPress 5.1以前は、PHPの致命的エラーが起きると画面が真っ白になるだけで、何が起きたのか全く分かりませんでした。WordPress 5.2(2019年)で「致命的エラーからの保護機能」が追加され、エラーを検知するとこの案内文を表示し、同時に管理者メールへ詳細を送る仕組みになりました。
つまりこのエラー画面は、「真っ白」を分かりやすくしたもので、中身は同じ現象です(真っ白になる原因は「【これで解決!】WordPress真っ白9つの原因と対処法」でも解説しています)。
ログインしている管理者には、「このサイトで重大なエラーが発生しました。WordPressのトラブルシューティングについてはこちらをご覧ください。」という文言で表示されることもあります。案内文が違うだけで、原因と対処は共通です。
参考:WordPress 5.2 “Jaco”|WordPress.org 日本語
「サイトで技術的な問題が発生しています」メールとセットで届く
エラー画面が出たとき、WordPressは管理者メールアドレスに「[サイト名] サイトで技術的な問題が発生しています」という件名のメールを送信します。
このメールには、エラーを起こしたプラグイン名やテーマ名、PHPバージョン、エラー詳細と、「リカバリーモード」で管理画面に入るためのリンクが書かれています。復旧の最大のヒントになるため、まずこのメールを探してください。迷惑メールフォルダに振り分けられていることもあります。
弊社に保守のご相談をいただく場合も、このメールをそのまま転送してくださるクライアントが最も多く、2025年からの約1年半でこのメールをきっかけにした相談は数十件以上に及びます。メール自体の読み方は「「サイトで技術的な問題が発生しています。」の原因と対処法」で詳しく解説しています。
===
突然の表示エラーで管理画面にもアクセスできない場合でも、サーバー側から安全に復旧可能です。業務への影響を最小限に抑えたい方は、プロへご相談ください。
対処の前に確認したい3つのこと
復旧作業を始める前に、次の3点を整理すると原因の当たりがつき、無駄な作業を避けられます。特に「直前に何をしたか」は、弊社に寄せられた相談のほぼ全件で原因と直結していました。
直前に何を操作したかを書き出す
PHPバージョンの変更、functions.phpへのコード追加、プラグインやテーマの更新・有効化、WordPress本体の更新、サーバー移転など。重大なエラーは「何かを変えた直後」に起きるのが典型です。エラー画面に表示された文言は、ページを移動する前にスクリーンショットで残してください。
実際に「エラー文をメモしないままページを移動してしまい、正確な文言が不明」というご相談もあり、調査に時間がかかる原因になります。
管理画面(wp-admin)にログインできるか
公開側だけがエラーで管理画面には入れるのであれば、テーマ側(テンプレートやfunctions.php)の問題である可能性が高く、管理画面からテーマ切り替えやプラグイン停止で対処できます。
管理画面もエラーになる場合は、PHPバージョンやプラグインなど全体に影響する原因であり、FTPやリカバリーモードでの作業が必要になります。
「技術的な問題」メールからリカバリーモードに入る
管理者メールに届いた「サイトで技術的な問題が発生しています」のメールには、「エラー詳細」としてエラーを起こしたファイルパス(例:wp-content/plugins/プラグイン名/…)が書かれています。
ここを見れば、どのプラグイン・テーマが原因かがその場で分かります。メール内のリカバリーモードのリンク(有効期限は1日)からログインすると、原因のプラグイン・テーマだけが一時停止された状態で管理画面を操作できます。
以前にサイト引越し屋さんへご相談をいただいたWebメディア運営会社様は、このメールからリカバリーモードでログインできたものの、「このまま更新してよいか判断できない」という状況でした。
メールにはWordPress 6.9、PHP 7.4.33、原因は2021年から更新の止まったプラグインと記載されており、メールを読むだけで「古いPHPと古いプラグインの組み合わせ」が原因と特定できました。
リカバリーモードは「原因を止めて管理画面に入れるようにする」だけで、エラーそのものを直す機能ではありません。次の章で原因別の対処を辿ってください。
===
PHPファイルの編集やプラグインの強制停止は、手順を誤るとさらなる不具合を招く恐れがあります。自力での修復作業に少しでも不安がある場合は、専門エンジニアにお任せください。
「重大なエラー」が起きる6つの原因
重大なエラーの原因は、ほぼ次の6つに分類できます。弊社が過去にご相談をお受けした案件のなかでもPHPバージョンアップに起因するものが最も多く、次いでテーマ・プラグインのコードに起因するものでした。
原因① PHPバージョンを上げたらテーマ・プラグインが非対応だった
最も多い原因です。レンタルサーバーの管理画面でPHPを7.4から8.xに切り替えた瞬間、古い書き方のコードが動かなくなりエラーになります。
PHP 8では、以前は「警告」で済んでいた書き方(未定義の変数へのアクセス、廃止された関数の利用など)が「致命的エラー」に格上げされたものが多く、数年更新されていないテーマやプラグインがあるとほぼ確実に影響を受けます。
2025年から2026年にかけては、多くのレンタルサーバーがPHP 7.4の提供を終了しています。サーバー会社からの「サポート終了のお知らせ」を受けてご自身でバージョンを上げ、その場でサイトが落ちたというご相談が続いています。
原因② functions.phpに貼り付けたコードのミス
「お問い合わせフォームのスパム対策」「アクセス解析コードの追加」などで、ネットで見つけたコードをテーマのfunctions.phpに貼り付けて保存した直後に起きます。閉じカッコの漏れ、全角スペースの混入、すでに存在する関数名との重複(Cannot redeclare)が典型です。
functions.phpはサイトの全ページで読み込まれるため、1文字のミスでサイト全体が止まります。
原因③ プラグインの更新・有効化・競合
プラグインを更新したら、あるいは新しいプラグインを有効化したらエラーになったケースです。有効化時には「重大なエラーを引き起こしたため、プラグインを有効化できませんでした。」と表示され、WordPressが自動でそのプラグインを停止してくれます。
この場合はサイトは止まりませんが、そのプラグインが現在のPHP・WordPressバージョンに対応していないサインです。
自動更新で夜間にプラグインが更新され、朝にはサイトが落ちていたというケースもあります(「WordPressバージョンアップ後によく起こる不具合と解決法」も参考にしてください)。
原因④ テーマ(テンプレート)のコードが特定の条件でエラーを出す
サイト全体ではなく「サイト内検索の結果ページだけ」「カテゴリを選ばずに投稿をプレビューしたときだけ」といったように、特定のページや操作でだけ重大なエラーが出る場合は、テーマのテンプレートファイルが想定していないデータ(空の値など)を受け取って止まっています。
オリジナルテーマで制作された企業サイトに多く、サーバー移転やPHP更新をきっかけに表面化します。
原因⑤ PHPのメモリ不足(Allowed memory size exhausted)
エラーログに「Allowed memory size of … bytes exhausted」とあれば、PHPに割り当てられたメモリを使い切っています。画像の大量圧縮やバックアッププラグインの実行中、プラグインが多いサイトの管理画面で起きやすく、格安プランのサーバーでは上限が低めに設定されていることもあります。
原因⑥ 改ざん・ファイル破損
何も操作していないのに突然エラーになった場合は、不正アクセスによるファイル改ざんや、サーバー障害によるファイル破損も疑います。改ざんされたサイトでは、不正に埋め込まれたコードが特定のページでFatal errorを起こしていた事例もあります。
この場合はエラーを消すだけではなく、サイト全体のクリーンアップが必要です。
===
バックアップがない状態での復旧作業や複雑な内部エラーの解消は、サイト引越し屋さんが迅速に対応いたします。データを失う前に、まずは現状をお聞かせください。
原因別の対処法
対処の基本は「直前に変えたものを元に戻す」ことです。復旧を急ぐあまりプラグインを次々と削除したり、WordPress本体を再インストールしたりすると、原因の特定が難しくなります。作業前には必ずファイルとデータベースのバックアップを取ってください。
対処① PHPバージョンを元に戻してから段階的に上げる
PHPバージョンを上げた直後のエラーは、サーバーの管理画面(cPanelやサーバーパネル)で元のバージョンに戻すと数分で解消します。ただし古いPHPはセキュリティ更新が終わっているため、戻すのは応急処置です。その後は次の順で進めます。
- WordPress本体・プラグイン・テーマを最新版に更新する(古いままPHPだけ上げるのが失敗の最大要因)
- 数年更新の止まっているプラグインは代替プラグインに置き換えるか停止する
- テスト環境(サブドメインやステージング機能)でPHPを上げて全ページを確認する
- 問題がなければ本番でも切り替える
テーマ側のコードが原因の場合は、該当箇所をPHP 8対応の書き方に修正する必要があります。
弊社が以前に対応した製造業の企業サイトでは、PHP 8.4への切り替えで全ページ共通のフッター部分がFatal errorを起こして公開ページが見られなくなり、テスト環境でその箇所を修正してから本番に反映しました。
本番でいきなり切り替えていたら、修正が終わるまでサイトが止まっていたケースです。詳しい手順は「WordPressのPHPを安全にバージョンアップさせる方法と注意点」をご覧ください。
対処② functions.phpをバックアップから戻す(FTPで上書き)
functions.phpにコードを貼ってエラーになった場合、管理画面のテーマファイルエディターでは修正できないことが多く、FTP(またはサーバーのファイルマネージャー)で wp-content/themes/テーマ名/functions.php を開き、追加したコードを削除して保存します。
編集前のファイルがバックアップにあるなら、それで上書きするのが最も確実です。
注意点として、エラーを起こした状態でテーマエディターを開き直すと、functions.phpが空(真っ白)になって見えることがあります。ここで空のまま保存するとテーマの機能がすべて消えてしまうため、必ずバックアップから元のファイルを戻してください。
対処③ 原因のプラグインを停止する(リカバリーモードまたはFTP)
「技術的な問題」メールのリンクからリカバリーモードでログインし、プラグイン一覧でエラー表示のあるプラグインを停止します。
メールが届いていない場合は、FTPで wp-content/plugins/ 内の該当プラグインのフォルダ名を変更(例:plugin-name → plugin-name_off)すると、そのプラグインだけが無効になります。
どのプラグインか分からなければ plugins フォルダ自体の名前を変えて全停止し、サイトが表示されることを確認してから1つずつ戻して特定します。
停止したプラグインがサイトに必要なものの場合は、更新版が出ていないか、同等機能の別プラグインがないかを確認します。
対処④ テーマの該当テンプレートを修正する
特定のページ・操作でだけ起きるエラーは、エラーログに記載されたテンプレートファイル(search.phpやsingle-xxx.phpなど)の該当行を修正します。応急処置として、エラーを起こす操作を避ける運用も可能です。
弊社が保守している製薬系メーカー様のサイトでは、お知らせ投稿をカテゴリ未選択のままプレビューすると重大なエラーが出ることが判明し、「カテゴリを必ず選択する」という運用ルールで回避しつつ、テンプレート修正は有償オプションとしてご案内しました。
対処⑤ PHPのメモリ上限を引き上げる
wp-config.php に define('WP_MEMORY_LIMIT', '256M'); を追記するか、サーバーのphp.ini設定(memory_limit)を引き上げます。
レンタルサーバーによってはプランの上限があり変更できないこともあり、その場合はメモリを消費しているプラグインの見直しか、上位プラン・別サーバーへの移転を検討します。
対処⑥ バックアップから復元する・改ざんを駆除する
原因が特定できないときは、エラーが起きる前のバックアップからファイルとデータベースを復元するのが最短です。レンタルサーバーの自動バックアップ機能も活用できます。改ざんが疑われる場合は、復元だけでは再発するため、不正ファイルの削除とパスワード変更、侵入経路の封鎖まで行います。
原因が分からないとき:WP_DEBUGでエラー内容を表示する
メールも届かず、直前の操作も思い当たらない場合は、wp-config.php の define('WP_DEBUG', false); を true に変えると、エラー画面の代わりに「どのファイルの何行目で何が起きたか」が表示されます。
画面に直接エラーを出すと訪問者にもサーバー内部の情報が見えてしまうため、以下のように wp-config.php に追記してログファイル(wp-content/debug.log)に出力させる方法が安全です。
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); @ini_set( 'display_errors', 0 );
ファイルパスに plugins とあればプラグイン、themes とあればテーマが原因です。確認後は必ず false に戻してください(訪問者にサーバー内部の情報が見えてしまいます)。
===
日頃の定期バックアップ環境構築やプラグインの安全なアップデート代行も承っております。再発防止の保守・セキュリティ対策もお気軽にご相談ください。
実際に寄せられた重大なエラーの実例
サイト引越し屋さんには、日々多数の重大エラー・致命的エラーに関するご相談が寄せられています。その中から、原因と解決までの流れが分かりやすい代表的な4件を紹介します。ご自身の状況に近いものを探してください。
| 業種・サイト | 直前の操作 | 原因 | 対応 |
|---|---|---|---|
| 小売業(保守クライアント) | スパム対策コードをfunctions.phpに貼り付け | コードの記述ミス。さらにfunctions.phpが空になっていた | バックアップからfunctions.phpを戻して当日復旧 |
| イベント情報サイト(AWS→VPS移転) | サーバー移転後の動作確認 | サイト内検索のテンプレートの記述が新環境でエラー | テーマ内の該当箇所を修正 |
| 企業サイト(スポット依頼) | cPanelでPHPを8.4に変更 | WordPress本体・プラグインが古いままPHPだけ更新 | テスト環境でWP本体・プラグインを更新・検証して本番反映 |
| Webメディア(スポット依頼) | なし(「技術的な問題」メールで発覚) | PHP 7.4と、2021年から更新の止まったプラグインの組み合わせ | リカバリーモードで応急処置→テスト環境でバージョンアップして本番反映 |
実例① functions.phpへのコード追加でサイト全体が表示不能に
お問い合わせフォーム(Contact Form 7)へのスパムが急増し、「ひらがなを含まない送信をブロックする」コードを解説記事からfunctions.phpに貼り付けて保存したところ、「保存に失敗」の表示が出てサイトが「このサイトで重大なエラーが発生しました」に。
貼ったコードを削除して保存しても直らず、改めてfunctions.phpを開くと元のコードも含めて空になっていたというご相談でした。管理画面にはログインできる状態でした。
弊社エンジニアが保守で取得していたバックアップからfunctions.phpを戻し、ご連絡から当日中に復旧しました。スパム対策自体は、コードを貼らずに済むreCAPTCHA v3の導入をご案内しました。
エラー文をメモする前にページを移動してしまい文言が不明だったため、「直前に何をしたか」のご報告が復旧の決め手になったケースです。
実例② PHPを8.4に上げた直後に「重大なエラー」
mixhostのcPanelでPHPバージョンを8.4に上げたところ、その場でサイトが「このサイトで重大なエラーが発生しました」になったという緊急のご相談です。WordPress本体とプラグインがしばらく更新されておらず、PHPだけを最新にしたことで非対応のコードが致命的エラーを起こしていました。
PHPだけを戻してもこのケースは解決しないため、テスト環境を構築してWordPress本体・プラグイン・テーマを更新し、PHP 8系での動作を確認してから本番へ反映しました。ご依頼から本番公開まで約2週間です。
その後、同じご担当者から、別に管理しているマルチサイト(3サイト)についても「データベースとPHPのバージョンアップが必要と警告が出ている」と事前のご相談をいただき、落ちる前に計画的に対応する流れになりました。
実例③ 「技術的な問題」メールからリカバリーモードで応急処置
サイトを開いてもログイン画面が出ず、「サイトで技術的な問題が発生しています」のメールが届いたというご相談です。
メールに記載されたリカバリーモードでログインはできたものの、「このまま更新してよいか判断できない」という状況でした。メールにはWordPress 6.9、PHP 7.4.33、原因は2021年から更新の止まったプラグインと書かれていました。
リカバリーモードで原因プラグインを停止して公開側を復旧したあと、テスト環境でWordPress本体とプラグインのバージョンアップを検証し、ご担当者に記事投稿の動作を確認していただいてから本番に反映しました。
バージョンアップ後に「未分類の記事が一覧に出る」という副作用が見つかり、カスタムコードで従来の表示に揃えて完了しています。
実例④ サーバー移転後、サイト内検索を押すとだけエラー
AWSからVPSへ移転したイベント情報サイトで、移転後の検証中に「ショップリストのサイト内検索で『検索』をクリックすると『このサイトで重大なエラーが発生しました』と表示される」とご指摘をいただきました。サイトの他のページは正常で、検索結果ページだけがエラーになる状況です。
調査すると、テーマ内の検索テンプレートの記述が新サーバーのPHP環境でエラーを起こしていたため、該当箇所を調整して本番切り替え前に解消しました。
サーバー移転では、すべてのページだけでなく「検索」「フォーム送信」「絞り込み」などの操作も必ずテストする必要があることが分かる事例です。
重大なエラーを再発させないための3つの運用
重大なエラーは、起きてから直すよりも「起きないように変更する」方が圧倒的に安上がりです。弊社に寄せられた相談のうち、次の3点が守られていれば防げたものが大半を占めます。
変更前にバックアップを取る(自動バックアップを仕組み化する)
PHP変更、プラグイン更新、functions.php編集の前には、ファイルとデータベースの両方をバックアップします。実例①が当日中に復旧できたのは、保守で毎日の自動バックアップが動いていたからです。BackWPupなどのプラグインで外部ストレージへ自動保存する設定をおすすめします。
詳しくは「BackWPupのバックアップからWordPressを復元する方法」をご覧ください。
PHP・WordPress・プラグインを「セットで」定期的に更新する
エラーの最大要因は何年も更新していないものを、ある日突然一つだけ最新にすることです。
PHP 7.4のサーバーからPHP 8.4に一気に上げるより、WordPress本体・プラグイン・テーマ・PHPを年に数回、セットで少しずつ上げていく方が、一回あたりの差分が小さくてエラーが出にくく、出ても原因を絞りやすくなります。
更新が止まっているプラグインは、動いていても次のPHP更新で止まる候補として早めに代替を探してください。
本番で試さず、テスト環境で先に確認する
レンタルサーバーのステージング機能やサブドメインにサイトを複製し、そちらでPHPを上げて全ページと検索・フォーム送信などの操作を確認してから、本番に同じ変更を適用します。実例②と実例③はどちらもこの手順で本番を止めずに完了しています。
ちなみに弊社のWordPress保守管理サービスでは、このバックアップや定期バージョンアップ作業を月次のメンテナンスとして代行しています。
まとめ
「このサイトで重大なエラーが発生しました」は、WordPressがPHPの致命的エラーを検知して表示する案内画面で、データが消えたわけではありません。
原因は「PHPバージョンアップでテーマ・プラグインが非対応」「functions.phpの記述ミス」「プラグインの更新・競合」「テーマのテンプレート」「メモリ不足」「改ざん」の6つにほぼ絞られ、対処の基本は「直前に変えたものを元に戻す」ことです。
まずは管理者メールに届いている「サイトで技術的な問題が発生しています」のメールで原因のファイルを確認し、リカバリーモードかFTPで原因を停めて公開側を復旧させます。
そのあとで、止めたプラグインの代替やPHP対応の修正をテスト環境で済ませてから本番に反映するのが、サイトを止めない進め方です。
弊社に寄せられた相談の大半は、バックアップと定期的なセット更新があれば防げたものでした。エラーの原因が特定できない、FTPでの作業に自信がない、あるいは復旧後に同じことを繰り返したくないという場合は、累計3,500件以上の対応実績があるサイト引越し屋さんにご相談ください。
「管理画面にも入れず、どこを修正すれば直るのか分からない」
「下手にファイルを触ってサイトが完全に消えてしまうのが怖い」
そんなときは私たちサイト引越し屋さんにお任せください。
WordPress専門のエンジニアが原因を迅速に特定し、安全に復旧いたします。
この記事を書いた人
サイト引越し屋さん編集部
累計対応実績3,500案件以上、日本で最も利用されているサーバー移転&保守代行サービス『サイト引越し屋さん』のマーケティング部です。 サイト引越しに関わる技術情報をはじめ、WordPressやその他のWebサービスに関するノウハウを発信しています。 全日本SEO協会所属。
本サイトにてご提供している情報については、最新かつ正確な情報を提供するよう努力していますが、情報の正確性や完全性を保証するものではございません。また、コンテンツには一部プロモーションが含まれております。本サイトの情報を利用することによって生じたいかなる損害に対しても、当社は責任を負いかねます。情報をご利用される際は、ご自身の判断と責任において行っていただきますようお願い致します。






