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エラーは必ず原因があります。
ログを確認し、順番に切り分ければ解決できます。
まずは深呼吸をし、最初の一手としてエラーログを確認することから始めてください。
それが最短復旧への第一歩です。
WordPressのハッキング修復はWPプロサポに
WP.復旧センターは「ハッキングされた」「表示がおかしい」「ログインできない」などのWordPressのトラブルをスピーディに修復します。
この記事を書いた人
Sho Suzuki
フロントエンドエンジニア / SEOプロフェッショナル
建築系の大学卒業後、芸術系の大学院を修了。その後、デジタルマーケティングを専門で行う企業にて約6年間フロントエンドエンジニアとして活躍する。同時期に、SEO対策に興味を持ち専門資格を多数取得する。
現在は、テクニカル記事の専属ライターとして多方面で活動中。
