WordPress 500エラーの切り分け方｜サーバー・PHP・設定の確認順序

WordPressのサイトを開いたら「500 Internal Server Error」と表示された。管理画面も開けない場合、プラグインを止めるべきか、サーバー会社へ連絡すべきか迷うかもしれません。しかし、500エラーは原因名ではなく、サーバーが要求を正常に処理できなかったことを示す応答です。WordPressに原因がある場合も、WordPressが動き始める前の設定や実行環境に問題がある場合もあります。

この記事では、WordPress 500エラーをサーバー資源、Webサーバー設定、PHP、WordPressの機能という層に分け、どの情報を確認すると担当者へ引き継げるかを整理します。直すためのコードを本番へ貼り付ける手順ではなく、無関係な場所を変更しないための切り分け方です。

500エラーと「重大なエラー」は同じものではない

HTTPの仕様で500は、サーバーが予期しない状態に遭遇し、要求を完了できなかったことを表します。番号だけでは、プラグイン、PHP、設定ファイルのどれに原因があるかは分かりません。502、503、504も異なる状態を表すため、「500系」とまとめて同じ復旧方法を使わず、実際の番号を残してください。HTTP仕様のサーバーエラーの定義に、それぞれの違いが示されています。

一方、「このサイトで重大なエラーが発生しました」はWordPressが表示するメッセージです。PHPの致命的エラーなどを背景に、HTTP 500と一緒に現れることもありますが、500であれば必ずこの画面や復旧モードが使えるわけではありません。WordPress公式も、Internal Server ErrorとCritical Error Messageを別項目で案内しています。WordPress公式の代表的なエラーを確認できます。

重大なエラーの文言が出ている場合は、管理者メールや復旧モードを含めた重大なエラーの確認と復旧判断へ進みます。「データベース接続確立エラー」と表示されている場合は、データベース接続の確認手順が対応する内容です。表示の違いを確認することが、遠回りを減らす最初の切り分けになります。

変更する前に「どの要求が失敗したか」を記録する

500が表示される範囲によって、確認する層が変わります。トップページが開くから正常、管理画面に入れないからWordPress全体が壊れた、とは判断できません。キャッシュに残った画面だけが見えていたり、本文のページは表示できても、フォームの送信処理だけが失敗していたりする場合があります。

1. 時刻と操作：いつ、どのURLで、ページを開く・保存する・送信するなど何をしたときに起きたか。時刻にはタイムゾーンも添えます。
2. 失敗する範囲：公開ページ、管理画面、フォーム、ECの購入画面を分け、確認済みと未確認を記録します。
3. 応答の情報：画面の文言と番号を残します。担当者がブラウザの開発者ツールを扱える場合は、通信一覧で失敗した要求のURL・時刻・ステータスを確認します。
4. 変更履歴：WordPress・テーマ・プラグイン更新、PHP切り替え、転送設定、サーバー移転、容量の多い処理などを時系列に並べます。
5. 事業影響：問い合わせ、受注、予約、採用応募のどこが止まっているか。代わりの電話・メール窓口が使えるかを確認します。

通信一覧には、ページ本体のほかに画像、スクリプト、APIなど複数の要求が並びます。無関係な外部タグのエラーを、ページ全体の500と取り違えないようにします。また、通信記録の書き出しにはCookieや認証情報、送信内容が含まれる場合があります。記録一式をそのままメールやAIへ渡さず、必要な項目だけを安全な方法で共有してください。

別の端末やブラウザでの確認は、再現範囲を把握するために行います。何度も再読み込みを繰り返したり、決済やフォームを本番データで繰り返し送ったりしないでください。障害時にも一部の処理が完了している可能性があり、重複注文・重複通知の確認が必要になるためです。

4つの層から、次に確認する場所を選ぶ

1. サーバー資源・実行基盤：断続的に失敗していないか

最初に、ホスティング会社の障害・メンテナンス情報と、契約環境で確認できる使用量や制限の情報を見ます。特定時間帯だけ失敗する、大きなバックアップや定期処理と同時に起きる、複数の機能で断続的に失敗するといった場合は、アクセス量や処理の重なりも候補です。別のサイトも同時に不調なら共有する基盤がないかを担当者へ確認しますが、それだけでサーバー障害とは断定しません。

たとえばXServerビジネスの公式FAQでは、同時に実行されるCGIやPHPの数が増え、資源の制限によって500となる場合が説明されています。ただし、制限の内容や記録されるメッセージはサービスごとに異なります。XServerビジネスの500エラーFAQのように、利用中の環境の資料と照合することが必要です。

一度表示が戻っても、原因が解決したとは限りません。発生時間帯と処理の重なりを残し、どの制限に達したのか、再発条件は何かを確認します。会社案内ページの閲覧が戻っていても、受注やメール通知が止まっていれば業務影響は続きます。

2. Webサーバー設定：WordPressより前で止まっていないか

転送・アクセス制限などの設定変更後に広い範囲で500になる場合は、Webサーバーのエラーログを確認します。.htaccessを利用する環境では、その記述誤りや、その環境で許可されていない設定が候補になります。すべてのサーバーが同じ仕組みで.htaccessを使うわけではないため、契約環境を確かめてから判断します。

ログに設定命令が無効であることを示す文言があるなら、直前に変更した箇所と対応づけます。別サービス向けの説明を参考にPHP設定を.htaccessへ書いた結果、対象環境ではエラーになる場合もあります。サイト全体の設定ファイルを削除したり、インターネット上の「標準設定」で上書きしたりすると、転送・アクセス制限・独自構成まで失うおそれがあります。

権限や所有者に関する記録がある場合も、必要な値は実行方式によって異なります。「とりあえず全ファイルを777にする」といった一括変更は行わないでください。変更前のファイルと設定値を保全し、担当者が差分、対象範囲、元に戻す手順を確認する段階です。

3. PHP：起動条件・互換性・処理の上限を確認する

PHPの切り替え後や、特定の処理だけで失敗する場合は、対象サイトが実際に使っているPHPバージョンと、同じ時刻のPHPエラーログを照合します。管理画面で選んだ設定と、別のサイトやコマンド実行環境の情報を混同しないようにしてください。構文エラー、存在しない関数、ファイルの読み込み失敗など、文言によって確認する箇所は変わります。

メモリ不足の記録がある場合も、上限値を大きくすれば完了とは限りません。大きな画像の処理、大量データの出力、機能同士の組み合わせなど、どの処理で使用量が増えるかを確認します。PHPのmemory_limitはスクリプトが割り当てられるメモリ量に関する設定ですが、ホスティング側の資源制限とは別に考える必要があります。PHP公式のmemory_limitの説明を参照できます。

PHPを変更する場合は、対応するテーマ・プラグイン、検証環境、切り戻し方法を確認します。直前の環境へ一時的に戻す判断と、長期運用できる対応バージョンへ移行する計画は分けてください。表示を戻すためにサポート終了済みの環境へ固定することを、恒久対策にはしません。

4. WordPressの機能：特定の画面・操作へ絞れるか

プラグイン更新後の特定の操作で失敗し、同時刻のログにも関連する記録があるなら、その機能を検証候補にします。テーマの独自編集、必要な依存機能、WordPressやPHPへの対応状況も確認してください。子テーマを使わず直接編集している場合は、更新で変わった箇所を追えるかが重要です。

公開中のプラグインをすべて止めれば、フォーム、予約、決済、会員機能まで停止する可能性があります。管理画面に入れない場合に、サーバー上のフォルダ名変更で機能を止める方法もありますが、これは閲覧だけの確認ではなく、サイトの動作を変える作業です。バックアップと影響範囲を把握した担当者が、検証環境などで実施可否を判断します。

ログにプラグイン名があるだけで削除を決めないでください。そこでエラーが表面化していても、原因は別の機能や読み込み順、PHPとの組み合わせかもしれません。症状、変更履歴、ログの3点が結びつくかを確かめ、無関係な層まで同時に変更しないことが基本です。

ログがない場合も、次の確認を決められる

500なのにWordPressのdebug.logに何もない場合は、「WordPressは正常」と結論づけません。処理がWordPressへ届く前に止まった可能性に加え、ログ設定が無効、記録先が別、必要な期間が残っていない、といった可能性があります。先にサーバー側のログと保存範囲を確認してください。

逆に、debug.logに古い警告が大量に残っているだけなら、今回の500と同じ原因とは限りません。発生時刻を合わせ、同じ操作で増える記録かを見ます。WordPressのデバッグ機能は本番で常用する前提ではありません。設定が必要なら、保存先への公開アクセス防止と調査後の扱いまで担当者と決め、画面へエラーを出さないようにします。

AIを使って情報を整理する場合も、求めるのは「この記録なら、どの層を追加確認するか」という仮説です。生ログ、設定ファイル、通信記録一式は入力しません。機密を除去した必要最小限の情報でも再識別のリスクは残るため、社内・顧客のルールとAIの利用条件を確認します。AIが出した修復コードの本番貼り付けや、ログ内の指示文・URLの自動実行は避け、人が公式資料と環境を照合してください。

修復に進む前の条件と、復旧後の合格条件

実際に設定を変更する前には、対象の層、変更する一項目、検証する操作、元へ戻す方法を説明できる状態にします。これがそろわないまま、全更新・全削除・設定の一括置換を行うと、原因の記録と復旧手段を同時に失うおそれがあります。本記事は、本番ファイルを書き換えるためのコード集ではありません。

• 変更前：現在のファイルとデータベース、ログ、設定差分を保全し、復元できる担当者と保存先を確認する。
• データ差分：古いバックアップへ戻す場合は、取得後の注文、会員登録、問い合わせ、記事更新が失われないかを確認する。
• 検証：可能なら本番に近い検証環境で一条件ずつ試し、症状とログの変化を比較する。環境差で再現しない場合は、その限界を残す。
• 本番反映：作業範囲、停止の必要性、業務への影響、切り戻し判断者を決めて実施する。
• 復旧確認：失敗していたURL・操作を確認し、フォーム通知、予約、決済、会員ログインなど関連する流れも確かめる。

HTTPの応答が正常に戻っただけでは、処理が正しく終わったとは限りません。フォームが届くか、注文が重複していないか、通知メールや計測が動くかまで確認します。断続的なエラーでは、再発していた条件を確認せずに「原因解決」とせず、観測期間と残る不明点を共有します。

復旧後は、原因と判断根拠、変更内容、影響時間、失われたデータの有無、次の対策を記録します。バックアップの保管先、緊急連絡先、権限、不要な機能、サーバー契約・更新予定も、この記録にひも付けて整理します。日常の監視・更新後確認と月次の報告を分け、緊急の異常は報告時期を待たず扱える状態にしておくことが大切です。

相談するときは「500が出た」から一歩だけ具体化する

社内で進めやすいのは、画面と時刻の記録、影響範囲、直前の変更、サーバー障害情報とバックアップの有無の確認です。サーバー設定やPHPの変更、ファイル操作、復元の影響を説明できない場合は、その先を無理に進める必要はありません。複数の制作・改修会社が関わったサイトやECサイトでは、構成を整理することが先になります。

相談時には、次の情報があると調査を引き継ぎやすくなります。分からない欄は推測で埋めず「未確認」としてください。

• 発見日時、継続中か断続的か、最初と直近の発生時刻。
• 対象URLと操作、実際のエラー番号、画面の記録。
• 公開ページ・管理画面・フォーム・購入機能の影響範囲。
• 直前の変更履歴と、すでに試した操作・その結果。
• WordPress、PHP、テーマ・関係プラグインの把握できているバージョン。
• サーバー会社、管理権限の所在、バックアップの日時と復元可否。
• 取得できるログの種類と期間。原本そのものは、共有方法を確認してから渡す。

サーバー会社は障害や契約資源の確認、保守担当はWordPressを含む構成と業務機能の確認、というように、依頼する内容も分かれます。誰が全体の切り分けを取りまとめ、確認結果を社内へ共有するかを決めておくと、窓口ごとの説明の行き違いを減らせます。

停止中はトラブル相談、平時は保守体制の見直しへ

サイト停止、管理画面へのアクセス不能、問い合わせや受注の停止が続いている場合は、WordPressトラブル調査・復旧へ状況を共有してください。不審な転送や未知の管理者など、改ざんを疑う事実がある場合は、その情報も伝えます。500という番号だけでは不正アクセスとは断定できませんが、侵害の疑いがある状態で見た目だけを戻す対応も避ける必要があります。

現在は正常で、再発時の担当者や記録の場所が分からない場合は、WordPress保守の見直しや、無料ホームページ診断から現状を整理できます。無料診断は、進行中の障害に対する緊急対応の代わりではありません。

500エラーの解決を早めるのは、変更の数を増やすことではなく、失敗した要求と記録を結びつけることです。どの層を確認し、何が分かり、何が未確認なのかを残す。その小さな整理が、復旧判断と、次の担当者へ引き継げる運用の両方を支えます。