503エラー(503 Service Unavailable)が表示される原因、訪問者・サイト運営者それぞれの対処法、復旧までの見通し、500・502など他の5xxエラーとの判断基準を解説します。
503エラーとは
503エラー(503 Service Unavailable)は、サーバーが一時的にリクエストを処理できない状態を示すHTTPステータスコードです。サーバーエラー(5xx番台)に分類されますが、500や502と異なり「一時的」である点が特徴で、過負荷や計画メンテナンス等の理由で復旧を前提とした応答です。
「Service Unavailable」表示の意味
ブラウザに「Service Unavailable」「503 Service Temporarily Unavailable」などのメッセージが表示された場合、サーバー本体には到達しているが処理する余力がない、または意図的に処理を止めている状態を意味します。リクエスト経路の中継機器が原因の502とは原因の所在が異なります。
補足:5xxエラーの中での503の位置付け
5xxサーバーエラーの中で、503は他のコードと比較して「短時間で復旧する可能性が高い」点が特徴です。
- 500 Internal Server Error：サーバー内部のアプリケーションエラー(原因解消が必要)
- 502 Bad Gateway：中継サーバーと上流サーバーの通信障害(経路の問題)
- 503 Service Unavailable：サーバーが一時的に利用不可(過負荷・メンテナンス等)
- 504 Gateway Timeout：中継サーバーが応答待ちで時間切れ(応答時間の問題)
503エラーが発生する主な原因
503エラーが発生する代表的な原因は以下の通りです。原因によって復旧までの見通しと対処方針が変わります。
アクセス集中によるサーバー過負荷
キャンペーン・プレスリリース・SNSバズなどで想定以上のアクセスが集中した場合、サーバーが処理能力の上限に達して503を返します。アクセスが落ち着けば自然に復旧します。
計画的なメンテナンス
サーバー側で計画的なメンテナンスを実施している間、運営者が意図的に503を返している状態です。サーバー設定やメンテナンスモードのプラグインで設定されていることが一般的です。
不正アクセスを検知した一時遮断
特定IPアドレスからの短時間の大量アクセス、ブルートフォース攻撃の試行などをWAFやサーバー側のセキュリティ機能が検知すると、一時的に503を返してアクセスを遮断します。エックスサーバー等のレンタルサーバーでは、不正アクセス対策として自動的に発動するケースがあります。
サーバー側のプロセス停止・再起動
PHP-FPM・Apache・Nginxなどのサーバープロセスが落ちている、または再起動中に発生します。プロセスが立ち上がれば復旧します。
CDN・フィルタによる一時遮断
Cloudflare等のCDNが、攻撃トラフィックの可能性を検知して一時的に503を返すことがあります。CDN管理画面でファイアウォールイベントを確認すると遮断理由が分かります。
訪問者として503エラーに遭遇した場合の対処法
他社サイトの閲覧中に503エラーが表示された場合、訪問者として確認できる項目は以下の通りです。
自分だけ表示されているのかを確認する
別のブラウザ・別ネットワーク(モバイル回線等)・別の端末からアクセスして同じく503が出るかを確認します。複数経路で再現する場合はサイト全体で発生中、自分だけ再現する場合はネットワーク経路やセキュリティソフト側の可能性があります。
復旧を待つ目安
503は「一時的」を意味するため、数分〜数時間で復旧することが多いステータスコードです。アクセス集中が原因の場合は時間経過で解消し、計画メンテナンスの場合は事前告知のスケジュール通りに復旧します。
ブラウザ側でできる対処
- 数分待ってからページを再読み込みする
- ブラウザのキャッシュとCookieをクリアして再アクセスする
- X(旧Twitter)等で同じサイトの障害情報・メンテナンス情報を確認する
- サイト運営者の公式アカウントで告知が出ていないか確認する
これらを試しても表示されない場合、サイト運営者側の対応待ちと判断できます。
サイト運営者向けの503エラー対処法
自サイトで503エラーが発生した場合、原因の切り分けから順に進めます。
状況の切り分け手順
- サーバー管理画面・コンソールでサーバープロセスが起動しているか確認する
- サーバーリソース(CPU・メモリ・ディスク使用率)に異常がないか確認する
- アクセスログを直近時刻でgrepし、リクエスト量とレスポンスコードを確認する
- 計画メンテナンスを実施中であれば終了予定時刻を確認する
- CDN・WAF・ファイアウォール側のイベントログを確認する
原因が特定できた段階で、それぞれの対処に移ります。
アクセス集中が原因の場合の対処
短期的には、リソースに余裕があるサーバーへの一時的なスケールアップ、CDNでのキャッシュ強化、不要な処理の停止が有効です。中長期的には、サーバーリソースの増強、データベースクエリの最適化、CDNでのキャッシュ設計の見直しを検討します。
計画メンテナンス時に意図的に503を返す方法
計画メンテナンス時は、503を返したうえで `Retry-After` ヘッダーで再開予定時刻または待機秒数を伝えます。Googlebotにも「メンテナンス中で再アクセスを待つべき」と認識されるため、長時間の場合でもクロール頻度の悪化を抑えられます。
503メンテナンス応答の例(Apache)
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/maintenance.html$
RewriteRule ^(.*)$ /maintenance.html [R=503,L]
ErrorDocument 503 /maintenance.html
Header always set Retry-After "3600"
上記設定で、メンテナンス中の全アクセスに503を返しつつ、1時間後の再開予定を伝えます。
不正アクセス検知による一時遮断の解除
WAFやサーバー側のセキュリティ機能が遮断している場合、ログで遮断理由(攻撃種別・遮断元IP)を確認したうえで、誤検知であれば許可リストへの追加、正当な遮断であれば対象IPからの再アクセスを待つ等の判断をします。エックスサーバーの場合は管理画面の「アクセス制限」「国外アクセス制限」設定を確認します。
503・500・502エラーの判断基準
表示されたエラーが503・500・502のどれにあたるかで、対処の優先順位が変わります。原因の所在で見分ける基準は以下の通りです。
| 判断ポイント | 503の典型 | 500の典型 | 502の典型 |
|---|---|---|---|
| 原因の所在 | サーバーが一時的に処理不可(過負荷・メンテナンス) | サーバー内部のアプリケーション例外 | 中継サーバーと上流サーバーの通信障害 |
| 復旧の見通し | 短時間〜数時間で復旧することが多い | 原因解消が必要(時間ではなく対応次第) | 経路の問題解消が必要(時間ではなく対応次第) |
| 影響範囲 | サイト全体または特定リクエスト群 | 特定機能・ページ単位で発生することが多い | 中継機器配下の全URLで一斉に発生することが多い |
| 初動の確認先 | サーバーのリソース・メンテナンス状況 | サーバーのアプリケーションエラーログ | CDN・リバースプロキシ・上流サーバー間の経路 |
503エラーの復旧見通し(いつまで続くか)
503の復旧見通しは原因によって異なります。原因別の目安を整理します。
自社運営サイトの場合の目安
- アクセス集中：数十分〜数時間。トラフィックが落ち着けば自動復旧することが多い
- 計画メンテナンス：事前に決めた終了予定時刻まで(`Retry-After` で告知済の時間)
- WAF・セキュリティ機能による遮断：遮断対象IPからのアクセスが止まれば数分〜数十分で解除されるケースが多い
- サーバープロセスの停止：プロセス再起動で即時復旧
他社サイト訪問時の対応
他社サイトでの503遭遇時は、復旧を待つ以外の手段がほぼありません。サイト運営者の公式SNSやステータスページで告知が出ていないかを確認し、緊急であれば運営者への問い合わせを検討します。
503エラーとSEOの関係
503エラーがSEOに与える影響を整理します。
一時的な503はクロールに影響しないが長期化は問題
短時間の503はGoogleが「一時的」と認識するため、インデックスから即座に除外されることはありません。長期間503が続く場合は、Googleがサイトを継続的に到達不能と判断し、クロール頻度を下げる可能性があります。
サーバーエラー（5xx）と5xxとして扱われるネットワークエラーとDNSエラーは、Googleのクロールに対してマイナスの影響を及ぼします。Googleはできるだけ多くのページをクロールしますが、サイトの帯域に過度の負担をかけないようにします。
https://developers.google.com/search/docs/crawling-indexing/http-network-errors?hl=ja
メンテナンス時はRetry-Afterで意図を伝える
計画メンテナンスでは `Retry-After` ヘッダーを併用することで、Googlebotがメンテナンスであることを認識しやすくなります。これにより、メンテナンス中の不要なクロール抑制を防ぎ、復旧後のクロール再開もスムーズになります。
長期化した503はインデックスに影響する可能性
数日以上503が続くと、対象URLが最終的にインデックスから除外される可能性があります。長期メンテナンスを実施する場合は、終了見込みの管理と、復旧後のSearch Consoleでの再クロール依頼が運用上のポイントです。
503エラーを確認・監視する方法
自サイトで503エラーが発生しているURLを確認・監視する代表的な方法は以下の通りです。
Google Search Consoleでサーバーエラーを確認する
Google Search Consoleの「ページ」レポートでは、Googlebotがクロール時に検出した5xxエラーを「サーバーエラー(5xx)」として一括で確認できます。
- Google Search Consoleにログインする
- 左メニュー「ページ」を選択する
- 「ページがインデックスに登録されなかった理由」内の「サーバーエラー(5xx)」を選択する
- 表示されたURLの一覧から、対処すべきURLを特定する
レポートでは500・502・503・504が統合表示されるため、具体的なステータスコードはサーバーログで確認します。
kunugi-gsc-controllerでURLをまとめて確認する
弊社のChrome拡張機能「kunugi-gsc-controller」を使うと、Google Search Consoleでの確認作業を効率化できます。複数のURLに対して順次URL検査を実行する操作を支援するため、503を返すURLが多数発生している場合の調査時間を短縮できます。
kunugi-gsc-controllerでの503確認手順例
- Google Search Consoleでサイトを選択する
- kunugi-gsc-controllerを起動する
- 確認対象のURL一覧をkunugi-gsc-controllerに入力する
- URL検査が順次実行され、各URLのステータス(503・200等)が一覧で確認できる
- 復旧後は「インデックス登録をリクエスト」を順次実行して再クロールを依頼する
死活監視ツールで早期検知する
503エラーが頻繁に発生するサイトでは、外部の死活監視ツールでリアルタイムに検知する仕組みが有効です。
- UptimeRobot：無料プランで5分間隔の監視と通知が可能
- Pingdom：レスポンスタイムとステータスコードの統合監視
- Mackerel・Datadog：サーバーリソースとあわせた総合監視
503エラーに関するよくある誤解と注意点
503エラーに関して、運営者・SEO担当者が混同しやすいポイントを整理します。
503と500・502の混同
画面上は同じ「サーバーエラー」と見えても、原因の所在が異なります。Search Consoleでは統合表示されるため、サーバーログまたは死活監視ツールで具体的なステータスコードを把握してから対処します。
500エラーとの違いを理解する
500はアプリケーション内部のエラーで、原因解消が必要なケースが多くあります。一方503は「一時的に処理できない」状態のため、時間経過や設定変更で解消することが多くあります。500を503と判断して放置すると、根本原因が解消されないまま継続するリスクがあります。
計画メンテナンス以外での意図的な503の使い方
攻撃トラフィックの一時遮断、過負荷時の優先処理(VIP以外を503で受け流す等)など、運用上の工夫として503を意図的に返すケースもあります。ただし長期化するとSEO評価に影響するため、運用方針として時間制限を設けます。
関連記事
502 Bad Gatewayとは？500・503との違い・原因・対処法
404 not foundとは？意味・原因・対処法とSEOへの影響
Google Search ConsoleのURL検査ツールの使い方
