メンテナンス中の表示は503で返す？一時停止と再開の確認手順
「メンテナンス中」と表示するだけで終わらせないために。停止範囲、HTTP 503、Retry-After、案内文、再開後のキャッシュと受付確認をまとめます。
この記事でわかること
先に答え：本当に利用できない期間は、案内文と応答をそろえる
サイトの処理を一時的に受け付けられないとき、HTTPの503 Service Unavailableが使われます。MDNは、過負荷やメンテナンスのような一時的な状態に使うコードと説明しています。トップに「メンテナンス中」と書くことと、サーバーが503を返すことは別の設定です。
この記事は、計画した作業でWebサイトを一時停止する担当者向けの確認表です。突然503が発生した場合は、作業中と決めつけず、障害の時刻・対象URL・直前の変更・運用ログを確認してください。ここにある文例は、架空の運用例であり、特定サービスの実画面や実績ではありません。
全体を止める前に、利用できなくなる範囲を決める
情報ページは読めるまま、問い合わせ受付だけ止めるケースと、すべてのページを利用できなくするケースでは対応が異なります。停止対象を表にして、案内文と実際の受付状態を一致させます。
| 対象 | 読めるか・使えるか | 停止中の案内 |
|---|---|---|
| トップ・サービス説明 | 継続して表示できるか | 必要なら一時停止のお知らせ |
| 問い合わせフォーム | 送信と保存を受け付けるか | 受付停止なら入力前に伝える |
| 会員・予約等の機能 | ログインや確定ができるか | 利用できない操作を具体的に示す |
| 状況確認ページ | 別の場所で表示できるか | 更新時刻と再開見込み |
Googleの一時停止に関する案内でも、特定機能だけ停止する方法とサイト全体を利用できなくする方法を分けています。停止する必要のないページまで一括で変更せず、何を止める作業なのかを先に決めます。
見た目が同じでも、応答が違えば意味が変わる
| 返す状態 | 表す内容 | 一時メンテナンスでの注意 |
|---|---|---|
| 200 | リクエストが成功 | 案内文が通常の本文として扱われ得る |
| 404・410 | 見つからない・終了した | 再開するページの一時停止と区別する |
| 503 | 一時的にサービスを利用できない | 復旧後まで残さない |
長期間503を返し続けても検索上の状態が保たれる、という保証はありません。GoogleのHTTP応答の資料では、サーバーエラーが続くURLは最終的にインデックスから削除されると説明しています。「何日までは絶対安全」と決めず、停止を必要な時間に限り、再開後の確認まで作業に含めます。
Retry-Afterは、待ち時間の目安を伝えるヘッダー
復旧見込みを示せる場合は、503と合わせてRetry-Afterを返す方法があります。MDNによると、値はHTTP形式の日付か、応答を受け取ってから待つ秒数です。たとえば Retry-After: 600 は、10分待つ目安を示す設定例です。
これは、必ず10分後に復旧する約束や、すべてのブラウザーを自動更新する仕組みではありません。対応状況はクライアントによって異なります。見込みが分からないのに適当な時間を入れるのではなく、運用担当者が判断できる範囲で設定します。
| 項目 | 説明用の例 | 注意点 |
|---|---|---|
| ステータス | 503 Service Unavailable | 実際の応答を確認する |
| 再試行の目安 | Retry-After: 600 | 600秒＝10分。保証時間ではない |
| 画面の文字 | ただいまメンテナンス中です | 停止範囲も具体的に示す |
| 更新情報 | 最終更新時刻・次回の案内予定 | 再開時刻と混同しない |
そのまま調整できる案内文
これはフォームだけを止める場合の文例です。全体停止ならその旨に書き換えます。時間未定の場合は「再開時刻は未定です。次回の状況案内は［時刻］を予定しています」のように、分かっていることだけを記載します。対応できない窓口を代替連絡先として案内しないでください。
フォームの送信ボタンだけを見えなくしても、サーバー側の受付が止まるとは限りません。作業中に書き込みを停止する必要がある場合は、フォーム画面と受付処理の両方を担当者へ確認します。すでに送信済みの問い合わせがどこに保存されているかも、停止前に把握しておきます。
停止前・停止中・再開後の作業表
- 対象URLと停止する機能を一覧にします。
- 必要なバックアップと、復元できる状態を確認します。
- 案内文、復旧判断をする人、予定を延ばすときの更新方法を決めます。
- メンテナンスを有効にし、実際のURLで画面とHTTP応答を確認します。
- 作業と確認結果を時刻付きで記録します。
- 復旧確認を行い、メンテナンス設定を解除します。
- 正常な本文、画像、フォーム、必要な機能が戻ったことを別々に確認します。
- 停止案内や古い503がキャッシュに残っていないか確かめます。
MDNは503のキャッシュ用ヘッダーに注意を促しています。復旧したのに古いエラーページが表示されることを避けるためです。キャッシュ設定は公開環境によって異なるので、復旧後に「管理画面の表示」だけを見て完了とせず、実際の公開URLでも確認します。
応答は、ページ本体のリクエストで確認する
ChromeのデベロッパーツールでNetworkを開いてから対象ページを読み込み、ページ本体のStatusを確認します。停止中に503、再開後にそのページで期待する正常な応答へ戻っているかを見ます。画像のリクエストや、転送の途中の応答と混同しないでください。
| 観測した状態 | 次に確認するところ |
|---|---|
| 案内は出るが200を返す | 公開先の応答設定・ルーティング |
| 再開したはずなのに503 | メンテナンス設定の解除・公開先 |
| 一部の環境だけ案内が残る | キャッシュと、実際の接続先 |
| ページは読めるが送信できない | フォーム受付・保存・通知の各処理 |
| 送信完了は出るが記録がない | 受付データを確認し、成功と断定しない |
担当者に渡す記録のひな形
「対象URL／停止する機能／開始時刻／再開見込み／案内文／期待する応答／実際の応答／再開確認の結果／未完了の作業」を一つの記録にまとめます。時刻にはタイムゾーンを付けてください。操作に迷う設定があるなら、一度に何項目も変更せず、担当者へ現状と期待する状態を渡して確認します。
SITE PORTを検討するときの確認ポイント
公開後のお知らせや文言を自分で更新したい場合は、SITE PORTの編集デモで更新の流れを確認できます。通常のお知らせ編集と、サーバーのメンテナンス設定や503の制御は作業が異なるため、停止時の連絡先・対応範囲・復旧確認を事前に整理して検討してください。
SITE PORTの完成例と編集デモを見ながら、普段の更新を自分で進められるか確認できます。契約前には、この記事で扱う設定を誰が担当するか、どの範囲まで対応するかを確認してください。
次に確認したいこと
[500・502エラーの確認](/articles/server-500-502-troubleshooting)・[バックアップと復元の準備](/articles/wordpress-backup-restore-plan)・[問い合わせフォームの確認](/articles/contact-form-delivery-test)
出典・確認情報
確認日：2026-10-12 ／ 公式情報の要点と編集部の提案を整理しています。価格・機能・条件は変更される場合があります。
MDN：503 Service UnavailableMDN：Retry-AfterGoogle：サイトを一時停止する場合Google：HTTPとネットワークエラーの扱いChrome：Networkパネルのリファレンス