WordPressの500エラー原因と対処法｜復旧手順と依頼判断を初心者向けに解説

WordPressサイトを開いたときに「500 Internal Server Error」や「このページは動作していません」と表示されると、サイトのデータがすべて消えたように感じるかもしれません。しかし500エラーは、サーバー側で処理を完了できなかったことを示す大きな分類です。画面だけでは、プラグイン、テーマ、PHP、設定ファイル、サーバー資源など、どこで問題が起きたかまでは分かりません。

大切なのは、思いついた変更を次々に試すことではなく、発生直前の操作と影響範囲を記録し、戻せる状態を確保してから一つずつ切り分けることです。この記事では、WordPress初心者でも状況を悪化させにくい確認順、管理画面に入れる場合と入れない場合の対処、制作会社やサーバー会社へ依頼する判断基準を解説します。

WordPressの500エラーとは

500エラーはHTTPステータスコードの一つで、Webサーバーがリクエストを受け取ったものの、サーバー内部の問題によって正常な応答を返せなかった状態です。ページが存在しないことを示す404エラーとは意味が異なります。404はURLや公開状態、パーマリンクの問題を中心に確認しますが、500ではPHPの致命的エラー、設定ファイルの記述、プラグインやテーマの競合、メモリ不足、サーバー側障害などを疑います。

同じ500表示でも原因は一つではありません。トップページだけで発生する、特定の記事だけで発生する、管理画面を含む全ページで発生する、保存やアップロードの操作時だけ発生するといった違いがあります。この「どこで、いつ、どの操作の後に出たか」が、復旧の最初の手がかりになります。

真っ白画面や重大なエラーとの違い

PHPの致命的エラーは、環境や設定によって500、真っ白な画面、または「このサイトで重大なエラーが発生しました」という案内として現れます。見た目が違っても原因が近いことがあるため、表示文言だけで断定しないでください。WordPressのリカバリーモードに関するメールが管理者宛てに届いていないかも確認します。

一方、サーバー会社の障害ページやメンテナンス画面が表示されている場合は、WordPress内の変更では直らない可能性があります。エラー画面の文言、発生時刻、対象URLを保存し、サーバー会社の障害情報と照合することが先です。

最初にしてはいけないこと

500エラーを見てすぐにWordPress本体を再インストールしたり、データベースを初期化したり、原因が分からないまま複数の設定ファイルを書き換えたりするのは避けます。複数箇所を同時に変えると、何が原因だったのか、どの変更で直ったのかが分からなくなります。

また、バックアップがない状態でプラグインやテーマのフォルダーを削除しないでください。切り分けでは削除よりも無効化や一時的な名前変更を優先します。名前変更なら元に戻しやすく、設定データを残したまま動作を確認できます。

公開サイトでエラーの詳細を画面表示する設定を長時間有効にすることも危険です。パスや構成情報などが訪問者に見える可能性があります。調査用のログは必要ですが、表示と記録を分け、調査後に設定を戻す前提で扱います。

復旧作業を始める前の準備

エラーの範囲を記録する

まず、トップページ、問題のページ、ログイン画面、管理画面を別々に確認します。可能なら別のブラウザーやシークレットウィンドウでも確認し、キャッシュによる見かけ上の問題を除外します。次の項目をメモしておくと、後から自分で比較するときも、専門家へ依頼するときも役立ちます。

• エラーを確認した日時と対象URL
• 画面に表示された文言やエラーコード
• 直前に行った更新、設定変更、コード編集、サーバー変更
• サイト全体か特定ページだけか
• 管理画面へログインできるか
• 同じサーバーの別サイトも影響を受けているか

現状のバックアップを確保する

復旧前に、現在のファイルとデータベースを保存します。壊れている可能性がある状態でも、後で原因を調べたり、作業前へ戻したりするための比較材料になります。サーバー会社の自動バックアップがある場合は、保存日時と保持期間を確認し、復元操作を始める前に対象日時を間違えていないか確かめます。

正常だった時点のバックアップがあるなら、その日時も控えます。ただし、すぐにサイト全体を復元するのではなく、直近の注文、問い合わせ、会員登録、記事更新など、復元で失われるデータがないか確認します。更新の多いサイトでは、ファイルだけを戻すのか、データベースも戻すのかで影響が大きく変わります。

作業できる権限と接続方法を確認する

管理画面に入れない場合は、サーバーのファイルマネージャーまたはFTP/SFTPを使うことがあります。作業前に、WordPressの設置先、接続先、対象ドメインを確認してください。複数サイトを管理している環境では、別サイトのフォルダーを変更しないよう特に注意が必要です。

安全な確認順の全体像

初心者は、原因の可能性が高く、元に戻しやすい項目から確認します。おすすめの順番は次の通りです。

1. サーバー障害と利用制限を確認する
2. 発生直前の変更を特定する
3. エラーログで原因の手がかりを探す
4. プラグインを切り分ける
5. テーマを切り分ける
6. .htaccessなどの設定ファイルを確認する
7. PHPバージョン、メモリ、実行時間を確認する
8. WordPress本体ファイルの破損を確認する

この順番は絶対ではありません。たとえば、プラグイン更新直後に発生したことが明らかなら、そのプラグインを最初に無効化する方が合理的です。重要なのは、一度に一項目だけ変更し、確認結果を残すことです。

サーバー障害と利用制限を確認する

同じサーバー上の複数サイトが同時に開けない、管理画面だけでなくメールやサーバーパネルにも異常がある、何も変更していないのに突然発生した場合は、サーバー側の障害やメンテナンスを疑います。サーバー会社の公式障害情報、メンテナンス情報、契約状態、ディスク使用量を確認してください。

ディスク容量やファイル数の上限に達すると、キャッシュ、ログ、アップロード、更新処理が失敗することがあります。アクセス集中によるCPUやメモリの制限、WAFなどのセキュリティ機能が特定リクエストを遮断している場合もあります。サーバーパネルで資源使用量を確認できないときは、発生時刻とURLを添えてサーバー会社へ問い合わせます。

サーバー会社には、WordPressの操作代行ではなく、サーバー側ログの有無、利用制限、障害、PHP実行環境の状態を確認してもらう意識が大切です。質問の範囲を明確にすると、回答を得やすくなります。

発生直前の変更から原因を絞る

500エラーが出る直前に、プラグインやテーマ、WordPress本体、PHPバージョンを更新していないか確認します。functions.phpやwp-config.php、.htaccessへコードを追加した場合は、記号の欠落や全角文字、コピー時の不要な文字が原因になることがあります。

直前の変更が明確なら、変更前のバックアップと差分を確認します。コード編集は、記憶で書き直すより、正常時のファイルへ戻す方が安全です。更新後に発生した場合も、古いバージョンへ無計画に戻すのではなく、公式の互換情報や変更履歴を確認し、ステージング環境で再現できると理想です。

エラーログを確認する

500という数字だけでは原因を特定できません。サーバーのエラーログ、PHPエラーログ、WordPressのデバッグログを確認すると、問題のファイル名、行番号、メモリ不足、権限エラーなどが見つかる場合があります。サーバーパネルに「エラーログ」「アクセスログ」「PHPログ」などの項目があるか探します。

ログを見るときは、エラーが起きた時刻に近い行を確認します。古い警告が大量に残っていても、今回の500エラーと関係するとは限りません。同じ操作を一度だけ再現し、その直後に追加されたログを比較すると絞り込みやすくなります。

WP_DEBUGは公開画面へ表示しない

WordPressにはデバッグ機能がありますが、公式ドキュメントでは開発用の利用が前提とされています。公開サイトでは、エラーを訪問者へ直接表示するのではなく、必要に応じてログへ記録し、調査後に無効化します。設定ファイルの編集に慣れていない場合は、誤記でサイトをさらに停止させる可能性があるため、制作会社や保守担当者へ依頼してください。

ログにはサーバー内のパスやプラグイン名などが含まれることがあります。問い合わせへ添付するときも、公開の掲示板へそのまま貼らず、ドメイン、ユーザー名、パス、個人情報を確認してから共有します。

プラグインを切り分ける

管理画面に入れる場合

直前に更新または有効化したプラグインが分かるなら、まずその一つを停止して表示を確認します。原因が不明な場合は、バックアップを確保したうえでプラグインをすべて停止し、一つずつ有効化して再現するかを確認します。公開サイトで機能停止の影響が大きい場合は、ステージング環境で行います。

フォーム、決済、会員、予約、キャッシュ、セキュリティ関連のプラグインを停止すると、表示以外の機能へ影響することがあります。単にページが開くかだけでなく、重要機能もテストしてください。

管理画面に入れない場合

ファイルマネージャーやFTP/SFTPでwp-content/pluginsを確認し、疑わしいプラグインのフォルダー名を一時的に変更すると、そのプラグインを読み込ませずに確認できます。原因が不明で全プラグインを止める場合も、pluginsフォルダーを削除せず一時的に名前変更します。

表示が戻ったら、フォルダー名を元へ戻し、管理画面で一つずつ有効化して原因を特定します。すべてを一度に有効化すると再びサイトが停止し、原因が分からなくなります。原因候補が分かったら、更新状況、PHP対応状況、公式サポート情報を確認し、代替プラグインへの置き換えも検討します。

テーマを切り分ける

テーマ更新、functions.php編集、子テーマの変更直後に発生した場合はテーマを疑います。管理画面に入れるなら、標準テーマへ一時的に切り替えて確認します。管理画面に入れない場合は、サーバー上で有効テーマのフォルダー名を一時変更する方法がありますが、標準テーマがインストールされていることを先に確認してください。

テーマを切り替えると、ウィジェット位置やメニュー表示、テーマ固有設定が一時的に変わることがあります。公開サイトで直接試す前にバックアップを取り、可能ならステージング環境を使います。子テーマを利用している場合は、親テーマと子テーマのどちらに変更があるかも確認します。

.htaccessとサーバー設定を確認する

Apache系の環境では、.htaccessの記述ミスや利用できない命令によって500エラーが発生することがあります。セキュリティ設定、リダイレクト、キャッシュ、パーマリンク関連の変更直後なら可能性が高まります。

確認するときは、現在の.htaccessを必ず別名で保存してから一時的に名前変更し、サイトが表示されるかを試します。表示が戻った場合は、管理画面のパーマリンク設定を保存してWordPressの基本ルールを再生成できることがあります。ただし、独自のリダイレクトやセキュリティ設定は自動では戻らないため、元のファイルとの比較が必要です。

Nginx環境では通常.htaccessを使いません。Webサーバーの設定はサーバー会社や管理者の範囲になることが多いため、Apache向けの手順をそのまま試さないでください。契約サーバーの公式手順を優先します。

PHPバージョンとサーバー資源を確認する

PHPバージョンの互換性

PHPバージョンを変更した後に500エラーが出た場合、古いテーマやプラグインが新しいPHPへ対応していない可能性があります。反対に、PHPが古すぎて現在のWordPressやプラグイン要件を満たしていない場合もあります。

むやみに複数のPHPバージョンを切り替えるのではなく、WordPress本体、テーマ、主要プラグインの動作要件を確認します。変更前のPHPバージョンと日時を記録し、検証環境で更新計画を立てるのが安全です。

メモリ不足と実行時間

重い処理を行ったときだけ500エラーになる場合は、PHPメモリや実行時間の上限に達している可能性があります。大量画像の処理、バックアップ、インポート、複雑なページ生成などがきっかけになります。ログに「Allowed memory size exhausted」やタイムアウトに関する記録がないか確認します。

上限を増やせば必ず解決するわけではありません。プラグインの異常処理や肥大化したデータが原因なら、上限変更は一時しのぎです。必要資源の根拠を確認し、サーバープラン変更、プラグイン見直し、処理の分割を比較します。

ファイル権限と所有者を確認する

移行、手動アップロード、復元の後に500エラーが出た場合は、ファイルやディレクトリの権限、所有者が適切でないことがあります。WordPressのファイルへWebサーバーがアクセスできない、または必要以上に厳しい・緩い設定になっている可能性があります。

権限値はサーバー構成によって異なるため、インターネット上の数値をそのまま設定せず、契約サーバーの公式案内に従います。全ファイルへ一括で広い権限を与える方法は、セキュリティ上避けるべきです。所有者の修正が必要な場合は、利用者側で変更できないこともあるためサーバー会社へ相談します。

WordPress本体ファイルの破損を確認する

更新中の通信切断や容量不足、誤った上書きによってWordPress本体のファイルが不足・破損する場合があります。管理画面に入れるなら、更新画面の再インストール機能を検討できます。ただしwp-contentやwp-config.php、データベースを含む全体バックアップを先に確保します。

手動で本体ファイルを入れ替える作業は、対象を間違えると投稿画像や設定を失う危険があります。wp-contentやwp-config.phpを上書きしないなどの知識が必要です。初心者が本番サイトで直接行うより、保守担当者へ依頼する方が安全な場面です。

管理画面に入れる場合の復旧手順

1. エラーのURL、時刻、直前の変更を記録する
2. ファイルとデータベースのバックアップを取る
3. ツールのサイトヘルスで重大な問題とサーバー情報を確認する
4. 直前に変更したプラグインまたはテーマを一つだけ停止する
5. キャッシュを消し、別ブラウザーで再確認する
6. ログで同時刻の致命的エラーを確認する
7. 原因が不明ならステージング環境で全プラグインと標準テーマを切り分ける

表示が戻った時点で作業を終えず、原因となった項目を特定します。停止したままではセキュリティや機能に影響することがあります。更新、置き換え、設定修正、サーバー会社への相談のどれが適切か判断してください。

管理画面に入れない場合の復旧手順

1. サーバー障害情報と契約状態を確認する
2. ファイルマネージャーまたはFTP/SFTPで現状をバックアップする
3. サーバーのエラーログを確認する
4. 直前に更新したプラグインのフォルダー名を一時変更する
5. 必要に応じてプラグイン全体、テーマ、.htaccessの順に一つずつ切り分ける
6. PHPバージョン、容量、メモリ、権限を確認する
7. 自力で原因を特定できなければ、変更を増やさず専門家へ渡す

各手順の前後で、サイトがどう変わったかを記録します。フォルダー名やファイル名は正確に控え、確認後に戻せるようにします。管理画面へ戻れたら、サイトヘルス、主要ページ、フォームなどを再確認します。

直った後に確認すること

トップページが表示されたことだけで復旧完了と判断しないでください。投稿・固定ページ、管理画面、ログイン、画像表示、問い合わせフォーム、検索、決済や予約など、サイトにとって重要な機能を確認します。キャッシュを利用している場合は、未ログイン状態とログイン状態の両方で確認します。

エラーログに新しい致命的エラーが出ていないか、停止したプラグインやテーマが残っていないか、デバッグ表示が無効になっているかも確認します。作業内容、原因、復旧日時、再発防止策を記録しておくと、次回の対応が速くなります。

500エラーの再発を防ぐ方法

更新前に戻せる状態を作る

WordPress本体、テーマ、プラグイン、PHPを更新する前に、ファイルとデータベースのバックアップを取ります。自動バックアップがある場合も、保存先、保持期間、復元方法を確認します。重要なサイトはステージング環境で更新を試してから本番へ反映します。

不要な変更を減らす

目的が重なるプラグインを複数入れる、出所不明のコードをfunctions.phpへ追加する、用途を理解せず.htaccessを書き換えると、競合や記述ミスの可能性が高まります。追加前に目的、管理者、更新方法、削除時の影響を整理します。

監視と保守の担当を決める

エラーは発生そのものだけでなく、発見の遅れが損失を大きくします。定期的な表示確認、バックアップの成否、更新、容量、フォーム送信を誰がいつ確認するか決めます。事業サイトでは、緊急連絡先と復旧権限も共有しておくと安心です。

自分で対応するか依頼するかの判断基準

直前に有効化したプラグインを停止すれば戻るなど、原因が明確で、バックアップと検証環境があり、停止による業務影響も小さい場合は自分で対応しやすいでしょう。一方、次の状況では早めの依頼が安全です。

• バックアップがない、または復元方法が分からない
• 管理画面にもサーバーにも入れない
• 決済、予約、会員、問い合わせなど重要機能が止まっている
• ログにデータベース、権限、マルウェアを疑う内容がある
• 複数人が変更しており直前の操作が分からない
• 復旧しても繰り返し500エラーになる
• 本体ファイルやデータベースを直接操作する必要がある

緊急時は、復旧速度だけでなくデータ保全と再発防止まで含めて依頼先を選びます。サーバー資源や障害の確認はサーバー会社、WordPressの構成やコードの修正は制作会社や保守事業者が主な相談先です。原因の範囲によって窓口を分けると進めやすくなります。

依頼時に伝える情報

「サイトが見られない」だけでは調査に時間がかかります。次の情報を整理して伝えると、初動が速くなります。

• サイトURLとエラーが出る具体的なURL
• 発生を確認した日時
• 画面のスクリーンショットと表示文言
• 直前の更新や設定変更
• 管理画面、サーバーパネル、FTP/SFTPへ入れるか
• バックアップの有無と最新日時
• サーバーログの該当部分
• 停止による業務影響と希望する復旧期限

パスワードや認証情報はメール本文やチャットへそのまま貼らず、依頼先が指定する安全な共有方法を使います。作業範囲、バックアップ取得、復旧後の確認項目、費用の扱いも事前に確認します。

依頼先を選ぶときの比較ポイント

500エラーの相談先は、契約サーバーのサポート、サイトを制作した会社、WordPressの保守事業者、テーマやプラグインの提供元などがあります。それぞれ対応できる範囲が異なるため、「どこでも同じ」と考えず、今回の原因候補に合わせて選びます。

サーバー会社は、障害、資源制限、PHP環境、サーバーログ、ファイル所有者などの確認に向いています。一方で、独自テーマのコード修正や複数プラグインの競合調査は、サポート範囲外になることがあります。制作会社や保守事業者はWordPress内部の調査に向いていますが、サーバー側の設定変更には契約者からの申請が必要な場合があります。

テーマやプラグインの提供元へ相談する場合は、その製品が原因だとある程度絞り込めていること、正規ライセンスとサポート期間が有効であることを確認します。原因不明の状態で複数窓口へ同時に依頼すると、別々の変更が重なって調査しにくくなるため、主担当を一つ決めるのが安全です。

見積もりで確認したい範囲

費用は、原因調査だけか、応急復旧までか、恒久修正と再発防止まで含むかで変わります。金額だけで比較せず、調査前バックアップ、作業環境、復旧後テスト、変更記録、再発時の対応を確認してください。

• 初期調査に含まれる時間と確認対象
• 原因が特定できなかった場合の費用
• バックアップ取得と復元テストの有無
• 本番環境で直接作業するか、複製環境を使うか
• フォームや決済など重要機能の確認範囲
• 作業報告書や変更ファイル一覧の有無
• 再発時の保証期間と追加費用

緊急対応は通常対応より費用が高くなる場合があります。売上や問い合わせへの影響、復旧期限、代替手段を整理し、即時対応が必要か、営業時間内の調査でよいかを判断します。安さを優先してバックアップなしで直接修正すると、原因が増えたり、後から戻せなくなったりするリスクがあります。

保守契約を検討した方がよいケース

更新頻度が高い、決済や予約を扱う、担当者がWordPressに詳しくない、停止時の損失が大きいサイトでは、障害発生後の都度依頼だけでなく保守契約も比較します。保守内容には、定期バックアップ、更新前検証、死活監視、セキュリティ確認、緊急時の一次対応などがあります。

ただし「保守」という名称だけでは範囲は分かりません。500エラー発生時の調査時間、サーバー会社との連携、プラグイン有償ライセンス、改修費、バックアップの保存先と保持期間が契約に含まれるか確認します。自社側の連絡担当と承認手順も決めておくと、緊急時に作業が止まりにくくなります。

原因別に見る失敗しやすい対応

プラグインが原因なのにキャッシュだけを消し続ける

キャッシュ削除で表示が一時的に変わっても、致命的エラーの原因コードは残ります。ログと更新履歴を確認し、対象プラグインを切り分けます。直ったように見える状態と、原因が解消した状態を区別してください。

.htaccessを空にして独自設定を失う

一時的な名前変更は切り分けに有効ですが、元ファイルを保存せずに上書きすると、リダイレクトやアクセス制限が失われます。必ず退避し、基本ルールと独自ルールを分けて戻します。内容を理解できない場合はサーバー会社か制作者へ確認します。

バックアップを戻して直近データを消す

サイト全体の復元は速い反面、バックアップ取得後の注文、問い合わせ、会員情報、記事更新が失われる可能性があります。どのデータを残す必要があるかを確認し、ファイルのみの復元や問題箇所だけの差し戻しが可能か専門家へ相談します。

表示が戻った直後に全更新を行う

原因候補を停止して復旧した直後に、WordPress本体、テーマ、全プラグインをまとめて更新すると、再発時の原因が分からなくなります。バックアップを更新し、重要機能を確認してから、一項目ずつ更新とテストを進めます。

よくある質問

時間を置けば自然に直りますか

一時的なサーバー障害や資源制限なら戻る場合がありますが、プラグインや設定ファイルの問題は待つだけでは直りません。障害情報とログを確認し、自然復旧した場合も発生原因を記録します。

プラグインを全部削除すれば直りますか

削除は推奨しません。まず無効化やフォルダー名の一時変更で切り分けます。削除によって設定や連携データへ影響する可能性があり、原因の証拠も失われます。

メモリ上限を増やせば解決しますか

ログでメモリ不足が確認できた場合には候補になりますが、異常な処理をするプラグインが原因なら再発します。必要量、サーバー上限、処理内容を確認し、根本原因も見直します。

500エラーと404エラーは同じ手順ですか

異なります。404はページが見つからない状態で、URL、公開状態、パーマリンクなどが中心です。500はサーバー内部で処理できない状態のため、ログ、PHP、プラグイン、テーマ、設定ファイル、サーバー資源を確認します。

まとめ

WordPressの500エラーは、原因を一つに決めつけず、影響範囲と直前の変更を記録し、バックアップを確保してから切り分けることが重要です。サーバー障害、ログ、プラグイン、テーマ、設定ファイル、PHPと資源、本体ファイルの順に、戻しやすい作業を一つずつ行います。

管理画面に入れない、重要機能が停止している、バックアップがない、データベースや権限に関わる場合は、変更を増やすほど復旧が難しくなります。発生時刻、対象URL、直前の操作、ログ、バックアップ状況を整理し、サーバー会社またはWordPressの保守担当者へ早めに相談してください。

参考にした公式情報

• WordPress公式：Common WordPress errors
• WordPress公式：Debugging in WordPress
• WordPress公式：FAQ Troubleshooting
• WordPress公式：Site Health screen
• Learn WordPress：Plugin and theme conflicts