WordPressの500エラーの直し方｜原因の調べ方と安全な復旧手順│Webクラス

WordPressで突然「500 Internal Server Error」と表示され、サイトや管理画面が開けなくなることがあります。原因はプラグインの不具合、PHPのエラー、サーバー設定などさまざまで、画面の表示だけでは特定できません。

大切なのは、設定をむやみに変更せず、直前の変更内容とエラーログを確認して原因を絞ることです。この記事では、初心者でも確認しやすい方法から順番に、安全な復旧手順をご説明します。

1 WordPressの500エラーが出たら最初に試すこと
2 500 Internal Server Errorとは？
3 WordPressで500エラーが発生する主な原因
4 エラーログを確認して原因を特定する
- 4.1 サーバーのエラーログを確認する
- 4.2 WordPressのデバッグログを有効にする
5 プラグインが原因の500エラーを直す方法
- 5.1 管理画面にログインできる場合
- 5.2 管理画面にログインできない場合
6 テーマやfunctions.phpが原因の場合
7 PHPのエラーやメモリ不足を確認する
8 .htaccessが原因の場合の確認方法
9 レンタルサーバー側の問題を調べる
10 WordPress本体の更新失敗やファイル破損が疑われる場合
11 500エラーが直った後に確認すること
12 WordPressの500エラーでよくある質問
13 まとめ｜500エラーは原因を特定してから対処する

WordPressの500エラーが出たら最初に試すこと

500エラーが発生した場合、まず次の順番で確認してください。

サイトの表示状態を確認する：トップページ・個別記事・管理画面のどこでエラーが出るか確認します。
直前の変更を思い出す：プラグイン更新、テーマ変更、PHPバージョン変更、ファイル編集などがなかったか確認します。
バックアップを確保する：ファイルとデータベースの両方を保全します。既存のバックアップが正常に復元できるかも確認します。
サーバーのエラーログを確認する：発生時刻と一致するエラーを探します。
原因候補を一つずつ切り分ける：プラグイン、テーマ、PHP設定、サーバー設定の順に、状況に応じて調査します。

バックアップがない状態で、データベースの削除やWordPressの初期化を実行しないでください。

アクセスが集中している、またはサーバー側で障害が発生している場合もあります。複数のサイトで同時に問題が起きているときは、契約サーバーの障害情報も確認してください。

500 Internal Server Errorとは？

500 Internal Server Errorは、HTTPステータスコード（Webサーバーがリクエストの処理結果を知らせる番号）の一つです。サーバー内部で予期しない問題が発生し、要求を正常に処理できなかったことを示します。

ただし、500という番号だけでは具体的な原因は分かりません。 WordPress本体の処理、PHP、プラグイン、テーマ、Webサーバーの設定などを調べる必要があります。

エラーの意味やほかの番号との違いは、HTTPステータスコード一覧と意味も参考になります。

WordPressで500エラーが発生する主な原因

原因候補	確認の手掛かり	主な対処
プラグイン	追加・更新・設定変更の直後に発生	該当プラグインを一時停止
テーマ	テーマ更新やfunctions.php編集後に発生	変更の復元・テーマの切り分け
PHP	Fatal errorやメモリ不足がログに記録	原因コード・PHP設定を確認
.htaccess	サーバー設定変更や移行後に発生	設定をバックアップして検証
サーバー	複数サイトで同時発生、サーバーログに異常	障害情報・リソース・設定を確認
WordPress本体	更新失敗やファイル破損の疑い	更新状態とファイル整合性を確認

この表は原因を断定するものではありません。実際の対処はエラーログと発生状況を組み合わせて判断してください。

500エラーのエラーログ確認からプラグイン・テーマ・PHP・サーバー設定へ原因を切り分ける図

エラーログを確認して原因を特定する

最初に確認したいのが、エラーログ（サーバーやプログラムの異常を記録する情報）です。500エラーの発生時刻に対応する記録が見つかれば、調査対象を大幅に絞れる場合があります。

サーバーのエラーログを確認する

レンタルサーバーの管理画面にログインします。
「エラーログ」「ログ管理」などの項目を探します。名称はサーバーによって異なります。
500エラーが発生した日時付近の記録を確認します。
ファイルパス、エラーの種類、発生時刻を控えます。

例えば、特定のプラグイン配下のPHPファイルで致命的なエラーが発生していれば、そのプラグインが調査候補になります。ただし、ログに登場したファイルが必ず根本原因とは限りません。

WordPressのデバッグログを有効にする

サーバーログだけでは分からない場合は、WordPressのデバッグ機能（プログラムの問題を調査する仕組み）を利用できます。

変更前にルートディレクトリ（WordPressを設置しているフォルダー）のwp-config.phpをバックアップしてください。

既存のWP_DEBUGなどの設定を確認し、重複定義を避けて次の値を設定します。

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

これらはwp-config.php内の「That’s all, stop editing!」というコメントより前の設定領域に記述します。

ログ出力が可能な環境では、通常wp-content/debug.logに記録されます。設定後、必要最小限の操作で問題を再現し、記録を確認してください。

debug.logにはファイルパスなどの内部情報が含まれる場合があります。外部から閲覧できないよう保護し、調査終了後はデバッグ設定を元に戻してください。

なお、PHPが実行される前にエラーが発生している場合や、ファイルへの書き込みができない場合は、WordPressのログが出力されないことがあります。その場合はサーバー側のログを優先してください。

プラグインが原因の500エラーを直す方法

プラグインを更新・追加した直後に500エラーが発生した場合は、直前に変更したプラグインを優先して確認します。

管理画面にログインできる場合

WordPress管理画面の「プラグイン」→「インストール済みプラグイン」を開きます。
直前に更新・追加したプラグインを一時停止します。
別のブラウザー画面でサイトの表示を確認します。
改善した場合は、そのプラグインの互換性、更新履歴、PHP要件などを確認します。

一時停止で改善しても、プラグイン自体の不具合、他プラグインとの競合、PHPとの互換性など、原因が複数考えられます。安全な環境で再現確認してから恒久的な対策を決めてください。

管理画面にログインできない場合

管理画面が開けない場合でも、サーバーのファイルマネージャーやSFTP（暗号化してサーバーへファイルを転送する方式）を利用できれば、プラグインの切り分けが可能です。

ファイルとデータベースをバックアップします。
wp-content/plugins/を開きます。
原因が疑われるプラグインのフォルダー名を一時的に変更します。例えばexample-pluginをexample-plugin-disabledにします。
サイトが表示されるか確認します。
結果を記録し、必要に応じてフォルダー名を元に戻します。

プラグインフォルダーを削除する必要はありません。フォルダー名の変更でも機能停止による影響が生じるため、決済、フォーム、会員機能などの重要な機能があるサイトでは特に注意してください。

複数プラグインの競合が疑われる場合は、検証環境で段階的に切り分けることを推奨します。

ファイルマネージャーを使った操作は、WordPressのプラグインをレンタルサーバーから操作する方法も参考になります。

テーマやfunctions.phpが原因の場合

テーマを更新した直後や、functions.phpを編集した直後に500エラーが発生した場合は、その変更箇所を確認します。

特にfunctions.phpはPHPコードを実行するファイルであり、構文エラーや存在しない関数の呼び出しなどによってサイトの表示に影響する場合があります。

変更前のファイルが残っているか確認します。
サーバーのエラーログで該当ファイルと行番号を確認します。
変更したコードだけをバックアップ済みの正常な内容へ戻します。
サイトと管理画面の表示を確認します。

元のコードが分からない場合は、推測で編集を重ねないでください。functions.php編集後に画面が真っ白になった場合の復旧方法も参考になります。

テーマそのものの不具合が疑われる場合は、検証環境で標準テーマへの切り替えを試す方法もあります。ただし、テーマを変更するとデザインや独自機能に影響するため、本番環境で安易に実施しないでください。

PHPのエラーやメモリ不足を確認する

PHP（WordPressの動作に使用されるプログラミング言語）の致命的なエラーは、500エラーの原因になる場合があります。

PHP Fatal errorを確認する

ログにPHP Fatal errorが記録されている場合は、エラーの種類、対象ファイル、行番号を確認します。

例えば、存在しない関数の呼び出し、型の不整合、互換性のないコードなどが原因候補になります。

エラーに記載されたファイルと直前の変更履歴を照合することが重要です。

PHPのメモリ不足を確認する

ログにAllowed memory size exhaustedと表示されている場合は、PHPが利用可能なメモリの上限に達した可能性があります。

この場合は、原因となっている処理やプラグインを調査したうえで、必要に応じてメモリ設定を見直します。

WordPressのWP_MEMORY_LIMITはメモリ利用量に関係する設定ですが、サーバー側のPHPメモリ上限を必ず超えられるわけではありません。

メモリ上限を引き上げるだけでなく、過剰なメモリ消費の原因を調べることが重要です。

PHPバージョンの変更直後に発生した場合

PHPバージョンを変更した直後に問題が発生した場合は、WordPress本体、テーマ、プラグインが変更後のバージョンに対応しているか確認してください。

一時的な切り分けとして直前の正常なPHPバージョンに戻す方法もありますが、古いバージョンへの恒久的な固定はセキュリティ上推奨できません。

.htaccessが原因の場合の確認方法

.htaccessは、Apacheなど対応するWebサーバーで利用される設定ファイルです。記述内容に問題があると500エラーにつながる場合があります。

ただし、Nginxなどでは通常同じ仕組みを使用しません。契約サーバーの構成を確認してから作業してください。

サーバーのファイルマネージャーなどで.htaccessの有無を確認します。
ファイルを別名でバックアップします。
直前に追加・変更した設定を確認します。
Apache系サーバーで該当ファイルが原因と疑われる場合は、検証環境で一時的な名称変更などを試します。
表示結果を確認し、検証後は必要な設定を復元します。

.htaccessを変更すると、URLの書き換え、アクセス制御、セキュリティ設定などにも影響する場合があります。元の内容を保管せずに削除しないでください。

WordPressの「設定」→「パーマリンク」で保存し直す操作は、環境によってリライトルール（URLの変換規則）の更新に利用できます。ただし、独自のサーバー設定をすべて復元する機能ではありません。

レンタルサーバー側の問題を調べる

プラグインやテーマに明確な原因が見つからない場合は、サーバー側の問題も調査します。

主に確認するのは、サーバー障害情報、ディスク容量、PHP実行環境、アクセス制限、サーバーログなどです。

複数のWordPressサイトで同時に500エラーが発生している場合は、共通のサーバー設定や障害を優先して確認すると効率的です。

サーバー会社へ問い合わせる場合は、以下の情報を伝えると調査が進めやすくなります。

エラーが発生した日時とタイムゾーン
問題が発生するURL
サイト全体か特定ページだけか
直前に実施した更新・設定変更
エラーログの該当部分
すでに試した対処と結果

ログを共有する際は、パスワード、認証情報、個人情報などを含めないよう確認してください。

WordPress本体の更新失敗やファイル破損が疑われる場合

WordPress本体の更新中に問題が発生した場合は、更新処理が正常に完了したか確認してください。

ファイルの欠落や破損が疑われる場合、公式配布ファイルを用いた再配置が必要になることもあります。

ただし、wp-contentやwp-config.phpを含めて無条件に上書きすることは避けてください。 独自設定やアップロード済みファイルが失われる危険があります。

WordPressの公式手順を確認し、バックアップと検証環境を確保したうえで対応してください。自信がない場合はサーバー会社や保守担当者へ相談する方が安全です。

500エラーが直った後に確認すること

トップページが表示されたことだけで、すべての機能が正常に復旧したとは限りません。

次の項目を確認してください。

トップページと個別記事が表示できるか
WordPress管理画面へログインできるか
記事の編集・保存が正常にできるか
お問い合わせフォームなど重要な機能が動作するか
エラーログに同じ異常が繰り返し記録されていないか
停止したプラグインや変更した設定が残っていないか

WordPressのREST API（外部プログラムとWordPressがデータをやり取りする仕組み）でエラーが続く場合は、WordPress REST APIエラーの原因と直し方も確認してください。

復旧後は、問題の発生日時、原因、対処内容、再発防止策を記録しておくと、同様のトラブルが起きた際に役立ちます。

WordPressの500エラーでよくある質問

500エラーが出ても記事やデータは残っていますか？

500エラーが表示されたからといって、記事やデータが削除されたとは限りません。サーバーが正常に処理できない状態でも、データベースに記事が残っている場合があります。ただし、データの状態は別途確認が必要です。

500エラーは放置すれば自然に直りますか？

一時的なサーバー障害などであれば、サーバー側の復旧に伴って解消する場合があります。一方、PHPコードや設定ファイルの問題は、原因を修正しなければ解消しないことがあります。

500エラーと「このサイトで重大なエラーが発生しました」は同じですか？

必ずしも同じではありません。後者はWordPressが致命的なエラーを検出した際に表示するメッセージで、HTTP応答や発生原因は状況によって異なります。詳しくはWordPressで重大なエラーが発生した場合の対処方法をご確認ください。

まとめ｜500エラーは原因を特定してから対処する

WordPressの500エラーは、プラグイン、テーマ、PHP、サーバー設定など複数の原因で発生します。

最初に行うべきことは、バックアップの確保、直前の変更履歴の確認、エラーログの調査です。その結果に応じて、影響範囲の小さい操作から順番に切り分けてください。

原因が分からないまま初期化やファイル削除を行うと、復旧が難しくなる場合があります。ログを確認しても特定できない場合は、契約サーバーのサポートへ状況を伝え、慎重に対応することをおすすめします。

WordPressの500エラーの直し方｜原因の調べ方と安全な復旧手順