WordPressが500エラーになった直後、最初にしてはいけない5つのこと

WordPressサイトを開いたら、突然「500 Internal Server Error」「重大なエラーが発生しました」と表示された。管理画面にも入れない。そんなときは、一刻も早く直したくなるものです。

ただし、500エラーは画面だけで原因を断定できるエラーではありません。プラグイン、テーマ、PHP、サーバー設定、ファイル破損など、複数の要因が考えられます。焦って変更を重ねると、原因の手掛かりや元に戻す道まで失うことがあります。

大切なのは「すぐ直す操作」より先に、「これ以上悪化させない初動」を取ることです。直後に避けたい5つと、安全に整理する順番をまとめます。

1. 原因を決めつけて、設定を次々に変えない

直前にプラグインを更新したからといって、そのプラグインだけが原因とは限りません。同じタイミングでPHPのバージョン、サーバー側の制限、テーマ、キャッシュなどが影響している場合もあります。

設定を変えるたびに状況が上書きされ、どの操作で表示が変わったのか分からなくなります。まずは次を記録してください。

- エラーが出た日時

- 表示された文言の全文とスクリーンショット

- エラーが出るURL

- 直前に行った更新・編集・設定変更

- トップページ、管理画面、特定ページのどこで起きるか

「何もしていない」と感じる場合も、自動更新やサーバー側の変更がなかったか確認する材料になります。

2. バックアップを確認せず、ファイルを削除・上書きしない

原因と思われるプラグインやテーマをいきなり削除したり、WordPress本体をそのまま上書きしたりすると、復旧に必要な元の状態や調査材料を失う可能性があります。

WordPressはファイルとデータベースの両方を使います。変更前に、現在のファイルとデータベースを保全できるか確認します。既存バックアップを使う場合も、取得日時、対象範囲、復元方法を確かめます。

プラグインフォルダ名の変更などが切り分けに使われることはありますが、環境ごとの影響を理解し、戻し方を決めたうえで行う診断操作です。手当たり次第に実行するものではありません。

3. いきなり古いバックアップへ戻さない

バックアップがあることは大切ですが、すぐ復元すればよいとは限りません。古い状態へ戻すと、その後に追加された注文、問い合わせ、会員情報、記事、設定変更などが失われる可能性があります。

復元前には、少なくとも次を確認します。

- バックアップの取得日時

- ファイルとデータベースの両方が含まれるか

- 復元によって失われる更新内容

- 現在の状態を別に保存できるか

- 失敗した場合の切り戻し手順

ECサイトや会員サイトは特に、表示復旧だけでなくデータ差分の扱いが重要です。

4. エラー詳細を公開画面に出しっぱなしにしない

WordPressのデバッグ機能やサーバーログは、原因調査に役立ちます。一方で、公開ページに警告やファイルパスなどを表示したままにすると、訪問者へ不要な内部情報を見せるおそれがあります。

調査時は、エラーを画面へ表示するのではなく、必要な範囲をログへ記録して確認する方法があります。WordPress公式資料でも、変更前のバックアップまたはステージング環境の確認と、画面表示を止めてログへ残す設定が案内されています。

設定ファイルの編集には、文字の抜けや記述位置の誤りで別のエラーを増やす危険もあります。内容が分からない場合は、無理に編集せず、サーバーのエラーログやサポート窓口を確認してください。

5. 出所不明のコードを、そのまま貼り付けない

検索結果や生成AIが示したコードは、似た症状への候補であって、あなたの環境で安全に使える保証はありません。テーマやプラグインの構成、PHPバージョン、サーバー仕様が違えば、結果も変わります。

コードや設定を使う前に、少なくとも次を確認します。

- 何を変更するコードなのか

- 対象ファイルと実行権限は適切か

- 現在の環境やバージョンに合うか

- 元へ戻す方法があるか

- 秘密情報や不審な外部通信を含まないか

意味を説明できず、戻し方も分からない変更は、本番サイトへ入れないのが安全です。

安全な初動は「記録→保全→切り分け」

最初に行うことを3段階にすると、慌てにくくなります。

記録

エラー文、発生日時、URL、直前の操作、影響範囲を残します。管理者メールにWordPressのリカバリーモードに関する案内が届いていないかも確認します。

保全

現在のファイル、データベース、サーバーログ、既存バックアップの状態を確認します。まだ取得できるなら、変更前の状態を保全します。

切り分け

サイト全体か一部ページだけか、管理画面へ入れるか、最近の更新と時間が一致するか、サーバー側にも障害がないかを確認します。一度に一つだけ仮説を試し、結果と戻した操作を記録します。

相談前チェックリスト

自分で安全に切り分けられない場合は、次の情報を用意すると原因調査が進みやすくなります。

- サイトURL

- エラー全文またはスクリーンショット

- 発生日時

- 直前の更新・編集・設定変更

- 管理画面へログインできるか

- 利用サーバーとPHPバージョン

- バックアップの有無と取得日時

- サーバーのエラーログを確認できるか

相談前の段階で、パスワードや秘密鍵を本文へ書く必要はありません。必要性と安全な共有方法を確認してから扱います。

まとめ

WordPressの500エラー直後は、次の5つを避けます。

1. 原因を決めつけて設定を次々に変える

2. バックアップ確認なしでファイルを削除・上書きする

3. 影響確認なしで古いバックアップへ戻す

4. エラー詳細を公開画面に出しっぱなしにする

5. 出所不明のコードをそのまま貼り付ける

安全な順番は「記録→保全→切り分け」

です。原因が分からないまま本番環境を変更するより、現状と手掛かりを残した方が、復旧までの遠回りを減らせます。

500エラーの原因調査・復旧が必要な場合は、この記事に掲載している関連サービスから事前にご相談いただけます。関連サービスが受付休止・非公開の場合や、どのサービスが合うか分からない場合は、私のプロフィールにある「見積り相談」から現在の状況をお知らせください。