よこやま良平
WordPressの公開ページは見えるのに、管理画面だけ503エラーになる時は、
公開側と管理側で異なる処理に原因がある可能性が高いです。
最初に行うべきことは、プラグインの一括停止やサーバー再起動ではありません。
エラーが出るURL・操作・時刻を記録し、同じ時刻のログと資源使用量を照合します。
20年以上ITエンジニアとしてWordPressの制作・保守・復旧に携わっている、よこやま良平です。
管理画面だけの503は、表側が動く安心感から対応が遅れやすいため、確認順が重要です。
- 管理画面だけ503になる範囲をURLと操作で切り分けられる
- PHPワーカー、データベース、WAFなど原因の層を判断できる
- 公開ページを不用意に止めず、安全な順番で復旧できる
- サーバー会社へ渡すログと情報を整理できる
- 復旧後の再発防止と監視項目を決められる
503 Service Unavailableは、サーバーが一時的に処理を受け付けられない時のHTTP応答です。
原因は一つではなく、Webサーバー、PHP、データベース、WAF、外部サービスのどこでも発生します。
この記事では「トップページや記事は開くが、wp-adminや保存操作だけ503になる」状態へ絞ります。
一般的な500番台エラーの違いから確認したい場合は、次の記事も参考にしてください。
こんなお悩みはありませんか？
- ある朝、サイトを開いたら真っ白画面になっていた
- 管理画面にログインできなくなって手が止まった
- 身に覚えのない記事やページが勝手に増えていた
- プラグインを更新したらサイト全体が崩れてしまった
- 以前バックアップを取ったか自分でも覚えていない
累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。
セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。
WordPress管理画面だけ503エラーになる状態を切り分ける
WordPress管理画面だけ503になる時は、まず「どこまで正常か」をURL単位で分けます。
症状の範囲が決まれば、WordPress全体を止めずに調べる対象を絞れます。
公開ページ・ログイン画面・管理画面を別々に確認する
トップページ、個別記事、画像URL、wp-login.php、wp-adminの順で一度ずつ開き、
HTTPステータス、表示時刻、読み込み時間、エラー文を記録してください。
wp-login.phpは開くのにログイン後だけ503なら、認証済みユーザー向けの処理が候補です。
ログイン前から503なら、管理URLへのWAF制限、IP制限、Webサーバー設定も疑います。
ダッシュボードは開くが、投稿保存、メディア追加、プラグイン一覧だけ失敗することもあります。
その場合は「管理画面全体」ではなく、失敗操作が呼ぶPHP処理やREST APIを調べます。
503が出る操作・ユーザー・時間帯を記録する
同じURLでも、管理者だけ、特定ユーザーだけ、特定ブラウザだけで503になる場合があります。
ユーザー権限、Cookie、拡張機能、接続元IPの違いを一度に変えず比較してください。
毎時同じ分に発生するなら、バックアップ、画像最適化、セキュリティ確認、wp-cronが重なっている可能性があります。
保存時だけなら、リビジョン、キャッシュ削除、検索インデックス更新、外部API通知を確認します。
- 503になった正確な日時とタイムゾーン
- 対象URL、画面名、押したボタン、投稿ID
- ログイン中のユーザー権限と接続元
- HTTPステータス、画面の全文、Retry-Afterの有無
- 直前の更新、設定変更、一括処理、障害情報
HTTP応答とサーバー障害情報を確認する
ブラウザの開発者ツールでNetworkを開き、Document、admin-ajax.php、REST APIのどれが503か確認します。
画面本体が200でも、保存通信だけ503なら調査対象はそのリクエストです。
レンタルサーバーの障害・メンテナンス情報、資源グラフ、利用制限通知も同じ時刻で確認します。
共有サーバーでは、CPUだけでなくPHP同時実行数やプロセス数が上限になることがあります。
curl -I https://example.com/
curl -I https://example.com/wp-login.php
curl -I https://example.com/wp-admin/コマンド例は認証前の応答比較に使います。
管理画面のCookieや認証情報を第三者の速度測定サイトへ入力してはいけません。
WordPress管理画面だけ503になる主な原因
WordPress管理画面だけ503になる主な理由は、管理側がキャッシュされにくく、
ログイン中の利用者ごとにPHP・DB・外部通信を実行するためです。
管理画面はPHPワーカーと同時実行枠を使う
公開ページがページキャッシュから返っている間も、wp-adminはPHPを毎回実行するのが一般的です。
そのためPHP-FPMワーカーや共有サーバーの同時実行枠が埋まると、管理側だけ503になります。
アクセス数が少なくても、バックアップ圧縮、大量インポート、画像再生成、マルウェアスキャンが長時間動けば枠を消費します。
失敗した処理を連打すると同じ処理が重なり、回復をさらに遅らせます。
管理画面プラグイン・admin-ajax・外部APIが詰まる
ダッシュボードウィジェット、SEO解析、統計、ライセンス確認、更新確認は、
管理画面を開くたびにDB集計や外部API通信を行うことがあります。
admin-ajax.phpやREST APIを短い間隔で呼ぶ機能が複数あると、画面を閉じても処理が残る場合があります。
ブラウザのNetworkで同じ通信が繰り返されていないか、応答時間が伸びていないかを見ます。
管理画面が503になる前に数十秒待たされるなら、速度低下が上限到達へ進んだ可能性があります。
画面別の遅延を詳しく分ける方法は、管理画面が重い時の切り分け手順も参考になります。
WAFやセキュリティ機能は、ログインURL、管理画面、POST通信を公開ページより厳しく検査します。
サーバーやCDNの設計によっては、遮断を403ではなく503で返すことがあります。
特定の投稿内容を保存した時だけ失敗するなら、本文内の文字列やURLをWAFが誤検知した可能性があります。
WAFを全面停止せず、検知ID、対象ルール、時刻、接続元IPをサーバー会社へ確認してください。
特定ユーザーだけなら、古いCookie、二段階認証、ログイン制限、権限確認の競合も候補です。
別ブラウザでの比較は有効ですが、原因確認前に全端末のCookieを消すと証拠を失うため注意します。
データベース・autoload・オブジェクトキャッシュが遅延する
投稿一覧、メニュー、プラグイン設定は、多くのデータベース問い合わせを実行します。
DB接続数の上限、ロック、肥大化したメタデータ、遅いクエリがあると管理処理が待たされます。
autoload対象の設定が増えすぎると、WordPressの多くの管理リクエストで余分なデータを読み込みます。
ただし、容量が大きいという理由だけでwp_optionsの行を直接削除してはいけません。
RedisやMemcachedなどのオブジェクトキャッシュが停止・遅延している場合も、管理画面の応答が不安定になります。
キャッシュ全削除を繰り返す前に、接続エラー、ヒット率、メモリ上限、再生成負荷を確認します。
503という番号だけでは、PHPメモリ不足、CPU不足、ワーカー枯渇、DB遅延、WAF遮断を区別できません。
画面の症状ではなく、発生時刻とログに残った事実で判断してください。
WordPress管理画面503エラーの安全な復旧手順
WordPress管理画面503エラーは、証拠を保全し、重い処理を止め、原因候補を一つずつ検証する順で復旧します。
公開ページが動く時ほど、不要な全停止や一括変更を避けるべきです。
証拠とバックアップを確保して追加操作を止める
エラー画面、Networkの対象通信、発生時刻、直前の変更、サーバーグラフを保存します。
アクセスログ、PHPログ、WAFログは保存期間が短いことがあるため、先に取得してください。
ファイルとデータベースのバックアップを取り、作成日時、容量、保存先を確認します。
サーバー内だけでなく外部へコピーし、管理画面へ入れなくても戻せる経路を用意します。
- 保存ボタンや一括処理を何度も押す
- 本番で全プラグインを同時に停止する
- 根拠なしにPHPメモリやタイムアウトを大幅に増やす
- アクセスログやWAFログを確認前に削除する
- 公開側が見えるという理由でバックアップを省略する
サーバー資源と実行中処理を確認する
CPU、メモリ、PHPプロセス、同時実行数、DB接続、ディスク空き容量を、503の発生時刻で確認します。
現在値が正常でも、障害時のピークが上限へ達していれば重要な証拠です。
バックアップ、インポート、画像処理、検索索引、メール配信など、終了していない一括処理を探します。
安全に停止できる機能だけ止め、停止時刻と改善までの時間を記録してください。
VPSでPHP-FPMを管理している場合も、原因確認なしに再起動だけで終えないことが大切です。
再起動で一時復旧すると、停止前のワーカー状態やエラーを失い、再発原因が残ります。
原因候補を一つずつ停止・隔離する
直前に更新したプラグイン、エラーログに名前が出た機能、負荷の高い処理から一つずつ検証します。
管理画面へ入れない場合は、SFTPやファイルマネージャーから対象フォルダだけを一時変更します。
決済、予約、会員、セキュリティ、キャッシュを止める時は、公開機能への影響を先に確認してください。
可能ならステージングで再現し、本番では最小の変更だけ行います。
- 疑う対象と、その根拠になるログ・直前変更を決める
- 現在の設定・ファイル名・実行状態を保存する
- 対象を一つだけ停止または隔離する
- 同じURL・同じユーザー・同じ操作で再確認する
- 改善の有無と確認時刻を記録し、次の候補へ進む
キャッシュ・セッションを整理して同じ条件で再確認する
原因候補を変更した後だけ、関係するキャッシュを必要な範囲で削除します。
ブラウザ、ページ、オブジェクト、CDNを一度に消すと、どの層が影響したか分からなくなります。
Cookieやログインセッションが疑わしい場合は、現在の状態を記録してから別ブラウザで比較します。
新しいセッションだけ成功するなら、認証Cookie、権限、セキュリティ機能の記録を確認します。
一度開けただけでは完了にしません。
ログイン、一覧、編集、保存、メディア、更新確認を同じ条件で行い、503が再発せず公開側も正常なら復旧と判断します。
WordPress管理画面503エラーをログから特定する
WordPress管理画面503エラーの原因は、複数のログを同じ時刻で並べると特定しやすくなります。
エラー文の一行だけでなく、直前から復旧までの流れを確認してください。
アクセスログで503の発行元と対象URLを見る
アクセスログでは、時刻、URL、HTTPステータス、応答時間、接続元IP、User-Agentを確認します。
wp-admin本体か、admin-ajax.phpか、wp-jsonかで、次に見る機能が変わります。
同じ時刻に公開ページが200、管理側だけ503なら、サーバー全停止ではありません。
一方、画像も含め全URLが503なら、WordPressより前のWebサーバーやホスティング障害を優先します。
grep ' 503 ' access.log | tail -50
grep 'wp-admin\|admin-ajax.php\|wp-json' access.log | tail -100ログ形式と保存場所はサーバーごとに異なります。
共用サーバーでは管理画面のアクセスログ機能を使い、権限のない場所を無理に操作しないでください。
PHP・PHP-FPMログで上限と停止を確認する
PHPログではFatal error、Allowed memory size exhausted、Maximum execution time exceededを探します。
PHP-FPMログではmax_children到達、worker停止、slow request、再起動記録を確認します。
メモリ不足の行があれば、上限値と不足量だけでなく、最後に出たファイルパスと実行操作を対応させます。
最後に停止したファイルが、最初にメモリを増やした原因とは限らないためです。
max_children到達が続く場合は、単純に上限を増やす前に一つの処理が長時間占有する理由を調べます。
DB待ちや外部API待ちを残したまま枠だけ増やすと、メモリやDB接続をさらに消費します。
DB・WAF・プロキシのログを同じ時刻で照合する
DBでは接続数、ロック待ち、遅いクエリ、ディスク使用量を確認します。
特定の投稿一覧や検索だけ失敗するなら、その画面が実行したクエリとデータ量を調べます。
WAFログでは、遮断ルールID、対象URL、POST内容の分類、接続元IPを確認します。
除外が必要でも、管理画面全体や全IPを無期限に許可せず、対象ルールと期間を限定します。
CDN、ロードバランサー、リバースプロキシがある構成では、どの層が503を生成したかを応答ヘッダーとログで見ます。
上流へ接続できない503と、WordPress処理後の503では復旧対象が異なります。
- 対象ドメイン、管理画面URL、発生日時
- 公開ページは200で管理側だけ503になる比較結果
- 再現操作、ユーザー権限、接続元IP
- 応答ヘッダー、アクセスログ、PHP・WAFログの該当時刻
- 直前の変更と、既に試した操作、その結果
WordPress管理画面503復旧後の確認と再発防止
WordPress管理画面503から復旧した後は、原因を取り除けたか、重要機能を止めていないかを確認します。
エラーが消えただけで作業を終えると、次の定期処理やアクセス増加で再発します。
管理操作と公開機能をPC・スマホで確認する
PCでログイン、ダッシュボード、投稿一覧、新規編集、下書き保存、画像追加、プラグイン一覧を確認します。
権限が異なるユーザーを使うサイトでは、編集者など実運用の権限でも必要な操作を試します。
公開側はトップ、記事、固定ページ、フォーム、検索、画像、主要なスマホ表示を確認します。
原因切り分けで停止した機能を戻すたびに、管理側と公開側の両方を再確認してください。
重い定期処理と外部通信を分散する
バックアップ、画像最適化、セキュリティ確認、集計、メール配信を同じ時刻へ集中させないようにします。
一つの処理が終わる前に次が始まらない間隔を取り、失敗時の再実行回数も制限します。
外部APIの応答が遅い機能には、適切なタイムアウト、再試行間隔、失敗時の処理を設定します。
管理画面を開くたびに不要な通信をする機能は、更新または代替を検討してください。
正常値・変更履歴・監視条件を残す
正常時のPHP上限、ワーカー数、DB接続数、主な管理操作の応答時間を基準として保存します。
障害時だけ数値を見るより、普段との差を比べた方が異常を早く判断できます。
変更した設定、停止した機能、復旧確認、元へ戻した項目、担当者、時刻を作業記録へ残します。
503件数、PHP-FPM待ち、資源上限を監視し、利用者の申告前に気づける通知を設定してください。
- 原因となったURL・処理・設定を記録した
- 一時的に増やした上限や許可設定を見直した
- 定期処理を分散し、重複実行を防いだ
- 管理側と公開側の主要機能を再確認した
- 503とサーバー資源を監視する条件を決めた
WordPress管理画面503エラーでよくある質問
WordPress管理画面だけ503になる時に、よくある判断の迷いをまとめます。
応急処置を原因確認の代わりにしないことが共通のポイントです。
壊れたオブジェクトキャッシュや古いセッションが原因なら改善する場合があります。
ただしPHPワーカー枯渇、DB待ち、WAF遮断には効かないため、関係する層を確認してから必要な範囲だけ削除します。
ログにメモリ不足があり、ホスティングが変更を許可する場合だけ一時的な調整を検討します。
CPU、ワーカー、DB、外部通信が原因なら改善せず、極端な増加は別の資源を圧迫します。
本番での一括停止は、決済、予約、フォーム、セキュリティ、キャッシュまで止めるため避けます。
ログと直前変更から候補を絞り、バックアップ後に一つずつ、またはステージングで検証してください。
対象URL、発生時刻、再現操作、公開側は正常という比較、接続元IP、応答ヘッダーを伝えます。
PHP同時実行上限、WAF検知、DB接続、ホスティング制限の該当記録があるか確認を依頼します。
WordPress管理画面503エラーは範囲と時刻をそろえて復旧する
WordPress管理画面だけ503になる時は、公開側が正常でも放置せず、
URL、操作、ユーザー、発生時刻を分けて記録することが最初の結論です。
次に、サーバー資源、アクセスログ、PHP・PHP-FPM、DB、WAFを同じ時刻で照合します。
証拠を残したうえで重い処理や原因候補を一つずつ止め、同じ条件で改善を確認してください。
よこやま良平が復旧対応で重視しているのは、直ったように見える操作ではなく、
原因を説明でき、元へ戻せ、公開機能を壊していないことまで確認する手順です。
- 公開側と管理側の正常・異常URLを分けた
- 発生時刻とサーバー資源・各ログを照合した
- 変更前にバックアップと戻し方を確保した
- 原因候補は一つずつ検証した
- 復旧後に管理操作・公開機能・再発監視を確認した
管理画面へまったく入れない、503が短時間で再発する、決済や予約にも影響がある場合は、
追加操作を止め、ログと変更履歴を保全して専門家へ引き継ぐのが安全です。
WordPressトラブルが自分で直せない時は
ワードプレスのWordPressエラートラブル解決をしたいなら
クイックレスキューが解決します。
・WordPressが真っ白画面
・WordPressがログインできない
・ホームページのマルウェアや乗っ取り
・サイトの表示くずれ
・エラーが表示されている
これらでお悩みなら最短30分ですぐに解決します！
いまなら期間限定で
・万一改善されない場合は全額返金保証で安心!
・30日間動作保証で安心!
・初期費・調査料 0円で安心!