WordPressサイトへアクセスしたとき、「503 Service Unavailable」と表示されることがあります。管理画面も公開ページも開かないと、WordPressが壊れたように見えますが、503だけで記事やデータベースが失われたとは判断できません。
503は、サーバーが一時的な過負荷や計画メンテナンスなどで、現在は要求を処理できない状態を示します。WordPressの更新中に出る標準メンテナンス表示もHTTP 503を返しますが、CDN、Webサーバー、PHP、WAF、プラグインなど別の場所が503を返す場合もあります。
再読み込み、全プラグイン停止、PHP変更、キャッシュ全削除、`.maintenance`削除、サーバープラン変更を同時に行わないでください。503を返した場所と発生理由を分けないまま操作すると、原因を見失い、負荷や二次障害を増やします。
この記事では、503の画面、応答ヘッダー、発生範囲を記録し、障害情報、メンテナンス、サーバー負荷、直前の変更を安全な順番で確認する方法を解説します。
先に結論：503エラーは7段階で確認する
| 順番 | 確認すること | 目的 |
|---|---|---|
| 1 | 画面・URL・時刻・操作を保存する | 同時刻の障害情報とログへつなぐ |
| 2 | 503の発行元と発生範囲を確認する | CDN・サーバー・WordPressのどこを見るか決める |
| 3 | サーバー会社・CDNの障害情報を見る | 待つべき障害で設定を変えない |
| 4 | WordPress標準メンテナンスかを分ける | `.maintenance`を誤って扱わない |
| 5 | CPU・メモリ・同時処理・接続・アクセスを確認する | 過負荷と上限到達を確認する |
| 6 | 直前変更とログを照合し一つだけ戻す | 原因を追える状態で復旧する |
| 7 | 200応答・重要機能・再発ログを確認する | 一時復旧と部分障害を見逃さない |
サーバーやCDNが`Retry-After`を返している場合は、指定された再試行時刻または待ち時間も記録します。ただし、Retry-Afterがないから長期障害、あるから必ず時間どおりに直る、とまでは判断できません。
503 Service Unavailableとは？
RFC 9110の503 Service Unavailableは、サーバーが一時的な過負荷または計画メンテナンスにより、現在は要求を処理できない状態を示します。サーバーは`Retry-After`ヘッダーを使い、利用者へ再試行の目安を示すことができます。
仕様上は一時的な状態を表しますが、「何もせず待てば必ず直る」という保証ではありません。負荷の原因が止まらない、更新が失敗した、サービスが再起動を繰り返す、設定した制限が常に発動する場合は、原因を直すまで続きます。
また、過負荷時にすべてのサーバーが必ず503を返すわけではありません。接続そのものを拒否する環境もあります。コードだけで障害箇所を決めず、画面、ヘッダー、ログ、リソース履歴を合わせて確認します。
500・502・503の違い
| 表示 | 意味 | 最初に見る場所 |
|---|---|---|
| 500 Internal Server Error | 予期しない状態で要求を完了できない | PHP・WordPress・Webサーバーログ、直前の変更 |
| 502 Bad Gateway | 中継役が上流から正常な応答を受け取れない | CDN・プロキシ・Webサーバー・PHP間の接続 |
| 503 Service Unavailable | 過負荷やメンテナンスで現在は処理できない | 障害情報、発行元、負荷、更新状態、制限 |
502が表示されているなら、上流との通信を切り分けるWordPress 502 Bad Gatewayの直し方を確認してください。500なら、WordPressの500 Internal Server Errorを安全に直す手順が対象です。
最初の10分で行う安全な初動
エラー画面全体のスクリーンショット、完全なURL、発生時刻とタイムゾーン、直前に行った操作を記録します。閲覧、ログイン、記事保存、更新、バックアップ、インポート、フォーム送信など、何をした直後かが重要です。
確認できる場合は、HTTPステータスが本当に503か、`Retry-After`、`Server`、CDNのリクエストIDなども保存します。技術的な操作に慣れていなければ、無理に開発者ツールを使わず、スクリーンショットと時刻をサポートへ渡すだけでも調査材料になります。
トップページ、別の記事、管理画面、既知の静的画像をそれぞれ一度だけ比較します。別端末・別回線も一度だけ確認します。静的ファイルは開くのにWordPress画面だけ503なら、PHPやアプリケーション経路が候補になりますが、あくまで推定です。
注文、問い合わせ、投稿保存などの送信操作は連打しません。503が表示されても、処理の一部が完了している場合があります。復旧後に重複処理がないかを確認してください。
503を返した場所と発生範囲を分ける
| 症状 | 考えられる範囲 | 最初の確認 |
|---|---|---|
| 更新直後にWordPress標準のメンテナンス文 | WordPressの更新処理 | 更新が進行中か、失敗して止まったか |
| CDN名やリクエストIDが表示 | CDNまたは配信元 | CDN障害情報、識別ID、配信元ログ |
| 静的画像を含む全URLが503 | CDN、Webサーバー、ホスト全体 | 公式障害情報とサーバー状態 |
| 静的画像は開き動的ページだけ503 | PHP、WordPress、データベース周辺 | PHP・Web・DBログとリソース |
| アクセスが増える時間だけ503 | 同時処理、接続、レート上限 | 発生時刻の負荷グラフとアクセスログ |
| 特定操作だけ503 | プラグイン、外部API、重い処理 | 失敗URLと同時刻のログ |
画面のデザインだけで発行元を100％確定することはできません。カスタムエラーページやCDNの設定で見た目が変わるためです。サーバー会社へ「この503はCDN、Webサーバー、PHPアプリのどこで生成されたか」を確認すると、次の作業を絞れます。
WordPressのメンテナンス表示と一般的な503を分ける
WordPressは本体・テーマ・プラグインの更新中、ルートにある`.maintenance`を確認して標準のメンテナンス画面を表示します。WordPress公式の`wp_maintenance()`資料では、この標準画面がHTTP 503と`Retry-After: 600`を返すことを確認できます。
つまり、WordPress標準の「メンテナンス中」表示は503と無関係ではなく、503の一種です。ただし、一般的な503、CDNやホスト独自の503、メンテナンスプラグインの画面まで、すべて`.maintenance`を削除すれば直るわけではありません。
更新直後で標準文が表示されている場合は、まず更新が続いていないかを確認して待ちます。更新失敗や停止を確認した場合だけ、公式手順に従って`.maintenance`を扱い、その後にWordPress本体、テーマ、プラグインの更新状態と重要機能を確認します。具体的な手順はWordPressがメンテナンス中のまま戻らないときの直し方にまとめています。
原因別の安全な復旧順
1．サーバー会社・CDNの障害と計画メンテナンス
公式ステータス、契約管理画面の通知、`Retry-After`を確認します。公式障害や計画メンテナンスが原因なら、WordPress設定を変えません。長引く場合は、時刻、URL、エラー画面、識別IDを添えてサポートへ連絡します。
2．CPU・メモリ・PHPワーカー・接続上限
発生時刻のリソースグラフとアクセスログを確認します。バックアップ、cron、画像変換、インポート、検索集計、アクセス急増、ボット巡回などが重なっていないかを照合します。原因と確認できた重い処理は、安全に停止または時間変更します。
メモリや実行時間の上限を根拠なく増やすと、処理が長く居座り、別の要求を圧迫する場合があります。原因処理、キャッシュ、ボット対策、契約上限の順に検討します。負荷の基本はWordPressが重い原因と改善順、キャッシュ変更はWordPressキャッシュ設定の安全な確認手順を参考にしてください。
3．更新中・更新失敗のメンテナンス
標準メンテナンス文、更新開始時刻、管理画面の通知、更新対象を確認します。必要な場合だけ`.maintenance`を扱い、表示が戻った後も更新未完了がないかを確認します。更新前の安全準備はWordPressを安全にアップデートする手順で整えられます。
4．直前のプラグイン・テーマ・独自コード
更新や有効化の直後で、PHPログ、負荷履歴、復旧モード通知が対象を示している場合は、その対象だけを切り分けます。管理画面へ入れるなら、通常の訪問者へ影響しにくいトラブルシューティング機能やテスト環境を優先します。
全プラグイン停止は最後の診断です。実行する場合も、有効だったプラグイン、フォーム、セキュリティ、キャッシュ、決済への影響を記録し、一つずつ戻します。普段から不要プラグインを整理する方法はWordPressプラグインを安全に減らす方法で確認できます。
5．PHP・Webサーバー・データベースの処理経路
PHPサービスの停止、同時処理枠の枯渇、データベース接続プール、Webサーバーの制限などは、同じ時刻のWeb・PHP・DBログとホストの回答で確認します。共有サーバー利用者は、原因を断定して設定ファイルを編集せず、サポートへ証拠を渡してください。
PHPバージョンを変えた直後なら、WordPressのPHPバージョン確認と安全な切り戻しを確認します。「データベース接続確立エラー」という固有表示がある場合は、データベース接続エラーの復旧手順へ進んでください。
6．WAF・CDN・レート制限
WAFのイベント、CDNログ、Webサーバーの制限ログを発生時刻と照合します。防御機能を全面停止せず、誤検知が確認できたルール、URL、IP、時間帯だけを狭く調整します。拒否が403として出る場合は、WordPressの403 Forbiddenを安全に直す確認順が対象です。
公開画面へ詳細を出さずログを確認する
優先するのは、ホスティング側のWebエラーログ、PHPログ、リソース履歴、WAF・CDNログです。503の発行元を知るため、同じ時刻で照合します。WordPressのデバッグが必要な場合は、WordPress公式のデバッグ手順を使います。
`WP_DEBUG`やログは本番で常用せず、エラー詳細を公開画面へ表示しません。ログにはパス、IP、Cookie、認証情報、個人情報が含まれることがあるため、共有前に伏せ字にし、調査後は一時設定を元へ戻します。
やってはいけない対処
- 再読み込みや送信ボタンを連打する
- 全プラグイン停止、テーマ切替、PHP変更、復元を同時に行う
- 一般的な503で`.maintenance`を削除する
- 原因確認前にキャッシュ全削除を繰り返す
- メモリ、タイムアウト、同時処理数を根拠なく増やす
- 負荷が高い最中に重いフルバックアップを新規実行する
- 本番でエラー詳細を表示し、ログ全文を公開する
- 503ページを正常な200応答や404へ置き換える
- 一度の503だけで高額なプランへ変更する
変更が必要な場合も、現在のバックアップ有無と元の設定値を確認し、一つ変更して一つ検証する原則を守ります。
サーバー会社へ伝える情報
- 対象URLと503画面のスクリーンショット
- 発生時刻とタイムゾーン
- HTTP 503、Retry-After、Server、CDN識別ID
- サイト全体・管理画面・特定操作のどこで発生するか
- 直前の更新、バックアップ、インポート、設定変更
- WordPressとPHPのバージョン
- リソースグラフと伏せ字済みログ
- 最後に正常だった時刻
- 実施済みの確認と結果
「この503はCDN、Webサーバー、PHPアプリのどこで生成されましたか」「同時刻に契約上限、サービス停止、メンテナンス、レート制限がありましたか」と質問すると、原因の所在を確認しやすくなります。
復旧後に確認すること
- 代表ページと管理画面が正常なHTTP 200を返す
- 記事閲覧、下書き保存、画像表示を一度ずつ確認する
- 問い合わせ、注文、会員処理の重複がない
- 更新未完了やメンテナンス表示が残っていない
- 一時的に変えた設定を元へ戻した
- 同じエラーやリソース逼迫がログで増えていない
- 数時間後と翌日にも監視を確認する
キャッシュは原因修正後に、必要な層と対象だけを更新します。一時復旧した直後にすべてのキャッシュを消すと、配信元へアクセスが集中して再び503を起こすことがあります。
503が検索へ与える影響と計画メンテナンス
GoogleのHTTPステータスコードに関する公式資料では、5xxが続くとクロールが一時的に遅くなり、長期間継続するとURLが検索結果から除外される可能性が説明されています。短時間の503で直ちに順位が消えると断定せず、まず正常な200応答へ戻します。
計画メンテナンスでは、軽量な503ページと適切な`Retry-After`を用意し、復旧見込みを伝える方法があります。エラーページを200で返したり、復旧のためにnoindexや404へ変えたりしません。メンテナンス終了後は通常ページが200を返すことを確認します。
よくある質問
503は待てば必ず直りますか？
必ずとは限りません。公式障害情報や`Retry-After`があれば案内に従いますが、更新失敗、負荷の継続、サービス停止、制限設定が原因なら対応が必要です。再読み込みを続けず、時刻と状態を記録します。
503は攻撃や改ざんの意味ですか？
503だけでは判断できません。アクセス急増やWAF制限に攻撃が関係する場合もありますが、計画メンテナンスや通常の負荷でも発生します。アクセスログとセキュリティログに別の根拠があるかを確認します。
キャッシュ削除で直りますか？
古い503画面がキャッシュに残っている場合には関係しますが、サーバー負荷やサービス停止の原因は直りません。原因を修正した後、対象のキャッシュ層だけを更新します。
全プラグインを停止すべきですか？
最初の対処にはしません。ログと直前の変更が特定プラグインを示すなら、対象限定で確認します。全停止はフォーム、セキュリティ、キャッシュ、決済などへ影響するため、実施前に状態と戻し方を記録します。
`.maintenance`は削除してよいですか？
更新失敗でWordPress標準メンテナンスが残ったと確認できた場合に限ります。一般的な503、CDNやホストの503、メンテナンスプラグインの画面には効きません。更新中に削除すると処理を妨げるため、進行中か停止したかを先に確認します。
PHPメモリを増やせば直りますか？
メモリ不足がログで確認できた場合の選択肢です。PHPワーカー、接続、CDN、WAF、メンテナンスが原因なら無関係です。消費元を確認せず上限だけ増やすと、サーバー全体をさらに圧迫することがあります。
自然に復旧したら何もしなくてよいですか？
再発しないとは限りません。発生時刻の負荷、cron、バックアップ、アクセス急増、サービス再起動を確認し、原因と修正内容を記録します。繰り返し上限へ達する場合に、最適化やサーバー見直しを検討します。
まとめ
503 Service Unavailableは、サーバーが一時的な過負荷やメンテナンスで現在は処理できない状態です。WordPress標準のメンテナンス表示も503を返しますが、CDN、ホスト、PHP、WAFなど別の層が返す503とは対処が異なります。
最初に発行元、発生範囲、障害情報、更新状態、リソースを分け、根拠がある対象を一つずつ直してください。復旧後は200応答、重要機能、重複処理、ログ、翌日の再発まで確認します。