WordPressのエラーは、画面に出た言葉をそのまま手掛かりにすると、最初に確認する場所を絞れます。 「重大なエラー」と「500 Internal Server Error」では確認順が違い、むやみに設定を変えるほど原因が分からなくなります。
このページは、WordPress公式ドキュメントとサーバー公式マニュアルを2026年7月31日に確認し、代表的なエラーを「意味・よくある原因・最初の確認・直った状態」で引ける辞典にしました。作業前には、表示された全文、発生時刻、直前の操作、影響範囲をメモしてください。
最初の60秒で残す診断メモ
- エラー画面を閉じる前に、表示文を省略せず記録する
- 発生時刻を分単位で控える
- 公開ページだけか、管理画面も開かないかを確認する
- 直前に更新したWordPress本体・テーマ・プラグイン・PHP設定を書く
- 別のページや別端末でも同じかを一度だけ確認する
更新や設定変更をしていないのに突然起きた場合は、サーバー障害、契約状態、リソース制限も候補です。反対に、更新ボタンを押した直後なら、互換性や処理途中のファイルを先に疑います。
WordPressエラー早見表
| 表示 | 意味の目安 | 最初に見る場所 |
|---|---|---|
| 重大なエラーが発生しました | PHPの致命的エラーをWordPressが検知 | 管理者メール、リカバリーモード、直前に更新したプラグイン・テーマ |
| Error establishing a database connection | WordPressがデータベースへ接続できない | wp-config.phpのDB情報、DBサーバー状態、契約状態 |
| 白い画面 | PHPエラーやメモリ不足などで出力が止まった可能性 | サーバーのエラーログ、直前の変更、管理者メール |
| 403 Forbidden | 閲覧権限やセキュリティ設定で拒否 | WAF・海外アクセス制限・アクセス制限・契約凍結 |
| 404 Not Found | 要求URLに該当ページがない | URL、パーマリンク、公開状態、転送設定 |
| 429 Too Many Requests | 短時間の要求が多すぎる | 連打・監視・ボット・プラグインの外部通信 |
| 500 Internal Server Error | サーバー側で処理を完了できない | エラーログ、.htaccess、PHP、権限、リソース |
| 503 Service Temporarily Unavailable | 一時的な負荷や同時接続制限 | 障害情報、アクセス集中、重いPHP処理 |
| Briefly unavailable for scheduled maintenance | 更新用メンテナンス状態が残った | 更新完了状況、WordPress直下の.maintenance |
| 更新に失敗しました。返答が正しいJSONレスポンスではありません | REST APIの応答を正常に受け取れない | サイトURL、SSL、パーマリンク、WAF、REST API |
| Destination folder already exists | 同名のテーマ・プラグインフォルダが残存 | wp-content/pluginsまたはthemes内の同名フォルダ |
| Allowed memory size exhausted | PHPメモリ上限に到達 | エラーログ、重い処理、PHPメモリ設定 |
同じ「サイトが開かない」でも、403は拒否されていて、500は処理が終わらない状態なんですね。
私は全部WordPressの故障だと思っていたので、少し恥ずかしいです。
恥ずかしくないよ。画面だけでは似て見えるから、番号で入口を分けられたら十分なんだ。
重大なエラーは、サーバーの番号とは別にWordPressが知らせてくれているんですね。
まだ怖さはありますが、管理者メールを見るという最初の行動なら私にもできそうです。
その一歩でいいよ。表示文に合う確認場所へ進み、関係のない設定は触らずに残しておこう。
「重大なエラーが発生しました」の確認順
WordPress 5.2以降には、致命的なPHPエラーを検知すると管理者メールへリカバリーモードの案内を送る仕組みがあります。まず迷惑メールを含め、サイト管理者メールを確認します。
- エラー発生時刻と直前の更新対象を控える
- 管理者メールの件名とエラー詳細を見る
- リカバリーモードでログインできたら、原因として示されたプラグインまたはテーマだけを停止する
- 公開ページと管理画面を再読み込みする
成功状態: 原因候補を一つ停止した状態で、公開ページと管理画面の両方が開きます。管理者メールが来ない場合は、サーバーのエラーログへ進みます。
データベース接続エラーの確認順
「Error establishing a database connection」は、記事が消えたという意味ではありません。WordPressがデータベースへ接続できない状態です。
- サーバー会社の障害・メンテナンス情報を見る
- 契約やサーバーアカウントが有効か確認する
- wp-config.phpのDB_NAME、DB_USER、DB_PASSWORD、DB_HOSTを契約画面の情報と照合する
- 自分で変更していない場合は、値を書き換えずサポートへ発生時刻とURLを伝える
成功状態: 公開ページに記事が表示され、管理画面へログインできます。接続情報を推測で作り直すのは避けてください。
403・404・500・503の分岐
403 Forbidden
アクセス権限がない、WAFや海外アクセス制限に該当した、契約が凍結されているなどの候補があります。ConoHa WINGの公式案内では、管理画面の403でWordPressセキュリティ設定が原因となる場合を挙げています。制限を一時解除して確認した場合は、原因を特定後に必要な設定を戻します。
404 Not Found
一つの記事だけ404なら、公開状態とURLスラッグを確認します。個別記事がまとめて404なら、「設定」→「パーマリンク」を開き、現在の設定を記録してから保存し直す方法が候補です。トップページまで開かない場合は、404だけの問題と決めつけません。
500 Internal Server Error
XServer公式マニュアルでは、エラーログを確認したうえで、PHP同時接続、プログラム文法、.htaccess、パーミッション、php.iniなどを候補にしています。最初から全部を変更せず、発生時刻と一致するログ行を探します。
503 Service Temporarily Unavailable
一時的なアクセス集中や負荷の高い処理が候補です。数分後の再確認、サーバー障害情報、同時刻のアクセス・エラーログを見ます。何度も再読み込みすると負荷を増やすため、連打しません。
500を見て、.htaccessを全部消せば直るのかなと思っていました。
でもエラーログの時刻を見ないまま変えると、原因も元の内容も分からなくなりますね。
そうなんだ。まずログの該当時刻を見て、直前に触った一項目だけを戻そう。元のファイル名や内容を残しておけば、違ったときも戻れるよ。
403でセキュリティを一時的に止めた場合、そのまま忘れそうなのも気になります。
確認が終わったら、解除した設定をメモから戻すところまで作業に入れたいです。
いい視点だね。直った瞬間で終わらず、必要な制限を戻してもう一度開けるところまでが安全な確認だよ。
更新後に出やすい3つの表示
メンテナンス表示が消えない
WordPress更新中は直下に「.maintenance」が作られます。処理が中断して表示が残る場合があります。更新処理が動いていないことを確認し、ファイルマネージャーでWordPress直下を表示して対象ファイルを確認します。別のファイルを消さないでください。
正しいJSONレスポンスではありません
投稿保存時のREST API通信が、転送、WAF、パーマリンク、サイトURL設定などで期待した応答にならない場合に出ます。まず「設定」→「一般」のWordPressアドレスとサイトアドレスが意図したURLか確認し、次に「設定」→「パーマリンク」を確認します。
Destination folder already exists
インストール先に同名フォルダが残っています。同じプラグインを二重に入れるのではなく、管理画面のプラグイン一覧に存在するか、ファイルマネージャーのwp-content/pluginsに同名フォルダがあるかを確認します。フォルダ名だけで削除せず、中身と由来を確認します。
ログを確認しやすいサーバーを選ぶ
エラー対応では、性能の宣伝より「エラーログへ迷わず到達できるか」「WordPress管理画面が開かなくてもサーバー側から確認できるか」が重要です。新規契約・移転を検討中の場合だけ、次の3社の管理機能と最新料金を比較してください。現在のサーバーでログ確認と復元ができるなら、エラーを理由に急いで乗り換える必要はありません。
公式資料で確認できる場所
- WordPress公式：Common WordPress errors
- WordPress公式：Debugging in WordPress
- XServer公式：各種エラーメッセージ
- XServer公式：エラーログ
- ConoHa WING公式：WordPress管理画面が表示されない
サポートへ伝える情報
解消しない場合は、エラー全文、対象URL、発生日時、再現手順、直前の変更、公開ページと管理画面の影響範囲、確認したログ行をまとめます。パスワード、秘密鍵、データベースのパスワードは送らないでください。
よくある質問
エラー画面を何度も更新してよいですか？
503や429では負荷や要求回数を増やす可能性があります。一度記録したら連打せず、障害情報やログを確認してください。
WP_DEBUGを本番サイトで常時有効にしてよいですか？
WordPress公式はデバッグ機能をローカルやステージング向けとして案内しています。本番で使う場合も画面へ詳細を表示せず、調査後に設定を戻します。
プラグインを全部停止すれば原因が分かりますか？
切り分けには使えますが、影響が大きい方法です。まず管理者メールやログで候補を絞り、一つずつ状態を記録して確認します。
最初は英語を見ただけで、全部消して入れ直すしかないと思っていました。
今はエラー全文と時刻を残せば、怖くても最初の確認場所までは進めそうです。
慌てず手掛かりを残せたのが一番大事だよ。直す速さより、何を確認して何が変わったかを追えるほうが安全なんだ。
まだログの長い文章は難しそうなので、該当時刻と最後の行から見てみます。
分からないときは秘密の情報を隠して、確認したことをサポートへ伝えたいです。
それで大丈夫だよ。一つだけ変えて結果を確かめ、違ったら戻す。その順番を守れば、エラー画面でも落ち着いて原因へ近づけるよ。
まとめ：エラー全文と時刻を残して一つずつ確認する
WordPressのエラーは、表示文、HTTP番号、発生時刻、影響範囲から最初の確認場所を絞れます。重大なエラーは管理者メール、データベース接続は接続情報とサーバー状態、403は権限・制限、500はエラーログ、503は負荷と障害情報から確認してください。
本記事は2026年7月31日時点の公式公開情報を基にしています。画面名や仕様は変わる場合があります。広告・PRを含みます。