WordPressサイトが突然「500 Internal Server Error」と表示される現象を、私は何度も現場で経験してきました。

管理画面にも入れず、ただ真っ白な画面かエラー表示だけが出る状態は、慣れていない方にとっては非常に不安だと思います。

私自身も、深夜に保守対応中のサイトで500エラーが発生し、原因の切り分けに想定以上の時間がかかったことがあります。

一見すると「サーバー側の問題」と思い込みがちですが、実際にはプラグイン、テーマ、.htaccess、PHPバージョン、メモリ制限など、複数の要因が絡みます。

この記事では、私が実際の対応現場で行っている判断プロセスと、具体的な修正手順を一次情報ベースで解説します。

「とりあえず再インストール」ではなく、原因を特定しながら確実に復旧させる方法を共有します。

500 Internal Server Errorとは何かを正しく理解する

経験者として最初にお伝えしたいのは、500エラーは「原因が特定されていないサーバー内部エラー」という意味だということです。

「500 Internal Server Error」はHTTPステータスコードの一種で、サーバーがリクエストを処理できなかったことを示します。

重要なのは「エラーの原因はブラウザではなくサーバー側にある」という点です。
そのため、ブラウザキャッシュ削除では解決しません。

確認すべき一次情報は以下です。

• サーバーのエラーログ
• WordPressのdebugログ
• .htaccessの記述
• PHPバージョン情報

多くのレンタルサーバーでは、コントロールパネルからエラーログを確認できます。

例えばエラーログに以下のような記述が出ることがあります。

PHP Fatal error: Allowed memory size exhausted
この一文だけで、メモリ不足が原因だと判断できます。

闇雲に触るのではなく、「ログを見てから動く」という姿勢が最短復旧につながります。

最初に行うべき切り分け手順

私は現場では必ず「触る順番」を決めています。

以前、焦って複数箇所を同時に変更し、原因が分からなくなったことがありました。
変更履歴を残していなかったため、復旧に余計な時間を使いました。

この経験から、今は必ず一つずつ検証します。

① プラグインの停止

最も多い原因はプラグインの不具合です。

管理画面に入れない場合は、FTPで /wp-content/plugins/ フォルダ名を一時的に変更します。

例：plugins → plugins_old

これで全プラグインが無効化されます。
エラーが消えた場合は、フォルダ名を戻し、1つずつ有効化して原因を特定します。

私は過去に、セキュリティ系プラグインのアップデート直後にエラーが出た経験があります。

アップデート直後という事実を軽視していましたが、実際はバージョン不整合が原因でした。
現在は「直前の変更」を必ず確認します。

② テーマの確認

テーマのfunctions.phpの記述ミスも頻出です。

FTPでテーマフォルダ名を変更すると、自動的にデフォルトテーマへ切り替わります。
それで表示されれば、テーマ内に問題があります。

特に独自カスタマイズをしている場合は注意が必要です。

私は一度、記号の打ち忘れ（;）が原因でサイト全体が停止しました。
以降はコード追加時は必ずテスト環境で検証して対策しています。

.htaccessの破損を確認する

経験上、意外と多いのが.htaccessの記述エラーです。

私は当初、.htaccessは自動生成だから壊れないと思い込んでいました。
しかしセキュリティ設定追加時に記述を誤り、500エラーを引き起こしたことがあります。
それ以来、変更前バックアップを徹底しています。

まず現在の.htaccessをリネームします。

.htaccess → .htaccess_old

それで表示される場合、内容に問題があります。

WordPressの基本記述は以下です。

# BEGIN WordPress
RewriteEngine On RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

上記を再作成し、管理画面から「パーマリンク設定」を保存し直します。

私は一度、RewriteRuleを重複記載していたことに気づかず原因解明に時間を使いました。
今度同様なケースが発生した場合は、差分比較ツールを使うと時間短縮ができると考えています。

PHPバージョンとメモリ不足を確認する

私は保守の現場で、テーマやプラグインに問題が見当たらない場合、必ずPHP環境を確認します。

以前、WordPress本体を更新した直後に500エラーが発生し、原因特定に時間がかかりました。
当時はコードの不具合を疑っていましたが、実際はPHPバージョンが古く非対応だったことが原因でした。

現在は、更新前に動作要件を確認しています。

WordPressは公式で推奨PHPバージョンを公開しており、最新の推奨環境が確認できます。
特に注意すべき点は以下です。

• WordPressのバージョンとPHPの互換性
• 利用中テーマの対応PHPバージョン
• プラグインの動作要件

サーバー管理画面からPHPバージョンを切り替え、再表示を確認します。
切り替え後は数分反映に時間がかかる場合があります。
変更後は必ず時間を置いて確認することをおすすめします。

メモリ不足の対処方法

エラーログに「Allowed memory size exhausted」とある場合、メモリ不足が原因です。

wp-config.phpに以下を追記します。

 define('WP_MEMORY_LIMIT', '256M');

それでも改善しない場合、サーバー側の上限が制限されています。
その場合はサーバー設定で変更するか、サポートへ問い合わせます。

サーバー上限を確認せずWordPress側だけ変更した際に、その変更が実際には反映されていない場合があります。
必ずphpinfoで実効値を確認をしておくと安心です。

WordPressデバッグモードで原因を可視化する

 

表示される情報が少ない場合、私は必ずデバッグモードを有効化します。

以前、エラー内容が分からず手探りで修正し、状況を悪化させたことがあります。
原因が見えない状態での修正は、判断を誤りやすく注意が必要です。

wp-config.phpに以下を記述します。

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

これにより /wp-content/debug.log に詳細エラーが出力されます。
表示はされずログだけ取得できるため、本番環境でも比較的安全です。

私は以前、WP_DEBUG_DISPLAYをtrueにしたまま公開し、エラー内容が表示されたことがあります。
現在はログ出力のみ有効にする運用にしています。

サーバー会社への問い合わせは最後の選択肢

私は現場で、安易にサーバー障害と決めつけないようにしています。

過去に、サーバー会社へ連絡したものの、実際は自作コードの構文エラーだったことがありました。

また問い合わせ前に確認すべき事項は以下になります。

• エラーログ取得済みか
• PHPバージョン確認済みか
• プラグイン無効化検証済みか
• .htaccess再生成済みか

問い合わせ内容には、発生日時、直前の変更点、エラーログ内容を明記すると、さらに解決が早まります。

FAQ

Q1. 管理画面にも入れません。どうすればよいですか？

FTP接続でpluginsフォルダをリネームしてください。
それで復旧すれば、原因はプラグインです。それでも改善しない場合はテーマを確認します。

Q2. 何も変更していないのに発生しました。

自動アップデートが原因の可能性があります。
WordPress本体、テーマ、プラグインの更新履歴を確認します。

Q3. 再インストールすれば直りますか？

原因を特定せず再インストールするのは推奨しません。
根本原因が解消されない場合、再発します。まずはログを確認することが最優先です。

まとめ

500 Internal Server Errorは「焦り」が最大の敵です。

私はこれまで多くの復旧対応をしてきましたが、最短で解決したケースは必ず「ログ確認 → 切り分け → 一つずつ検証」という順序を守っています。

重要なのは闇雲に触らないことです。
判断の軸は以下です。

• 直前の変更は何か
• ログに何が書かれているか
• 環境要件に問題はないか
• 再現性はあるか

500エラーは必ず原因があります。
ログを確認し、順番に切り分ければ解決できます。

まずは深呼吸をし、最初の一手としてエラーログを確認することから始めてください。
それが最短復旧への第一歩です。