サイトの一時停止では503 Service UnavailableとRetry-Afterで再訪時期を伝える
公開日: 執筆:佐藤
保守作業でサイトを一時停止するなら、メンテナンス画面を表示するだけでなく、HTTPステータス503 Service Unavailableを返します。再開時刻を見込める場合は、Retry-Afterヘッダーで待ち時間または日時を伝えます。
メンテナンス画面を200 OKで返すと、サーバーは通常ページを正常に返したように見えます。404 Not Foundでは、URLが存在しないという別の意味になります。一時停止という状態は、画面の文章ではなくHTTP応答でも示します。
200と404と503はサーバーが伝える意味が違う
Googleの計画停止に関する案内は、停止中のURLへ404 Not Foundを返したり、エラー画面を200 OKで返したりせず、503 Service Unavailableを使う方法を示しています。
| 応答 | サーバーが伝える内容 | 計画停止での扱い |
|---|---|---|
200 OK |
要求を正常に処理した | メンテナンス画面を通常ページとして返すため使わない |
404 Not Found |
要求されたURLが見つからない | 一時停止ではなくURL不存在を示すため使わない |
503 Service Unavailable |
一時的に要求を処理できない | 保守や一時的な過負荷を示すため使う |
HTMLに「メンテナンス中」と書いてあっても、応答が200ならHTTP上は成功です。反対に、簡素な画面でも応答が503なら、一時的に処理できないことをクローラーへ伝えられます。
503とRetry-AfterをHTTPヘッダーで返す
HTTP/1.1を定めたRFC 2616は、503 Service Unavailableを、一時的な過負荷または保守によって要求を処理できない状態と定義しています。サーバーはRetry-Afterを使い、停止が続く見込みを示せます。
一時間後の再試行を伝える説明例は、次の形です。
HTTP/1.1 503 Service Unavailable
Retry-After: 3600
Content-Type: text/html; charset=UTF-8
これは説明用の仮例です。Retry-After: 3600は、応答から3600秒後を示します。Retry-Afterの定義では、秒数のほか、HTTP-date形式の日時も使えます。
再開時刻を決められない場合、根拠のない時刻を入れません。Retry-Afterは任意のヘッダーです。Googlebotが再クロール時期の判断へ使う場合はありますが、指定した時刻ちょうどの再訪を保証するものではありません。
メンテナンス画面にも状況と再開見込みを書く
HTTP応答はクローラーとブラウザーへ状態を伝え、HTML本文は利用者へ状況を説明します。どちらか一方だけで済ませません。
メンテナンス画面には、確認できる範囲で次の内容を書きます。
- 一時停止していること
- 利用できない機能または範囲
- 再開予定時刻、または次の案内時刻
- 問い合わせ先が必要な場合の連絡方法
「すぐ戻ります」とだけ書くより、再開予定を出せるなら時刻を示します。ただし、確定していない復旧時刻を約束しません。作業が延びた場合は、HTMLの案内とRetry-Afterを同じ判断で更新します。
デザインしたメンテナンスページをWordPressやアプリケーションへ追加しても、処理の途中で200へ戻していないかを確認します。見た目とステータスは別の設定です。
サーバーを止める前に503を返す場所を用意する
ハードウェア保守などで本番サーバー自体を停止すると、停止したサーバーから503は返せません。Googleの案内は、計画停止では別のサーバーから503を返せるようにする方法を挙げています。
作業前に、次の役割を決めます。
- どの装置または設定が
503を返すか。 - どのURLを一時停止の対象にするか。
- メンテナンス画面のHTMLをどこから返すか。
Retry-Afterを誰が決め、延長時に誰が直すか。- 復旧後に通常応答へ戻す担当者は誰か。
制作会社やサーバー会社へ停止作業を委託しても、「メンテナンス画面を出す」という依頼だけで終わらせません。対象URLで返すステータス、ヘッダー、本文、開始と解除の確認結果を受け取ります。
503を長期の閉鎖手段として残さない
503は、一時的に利用できない状態を表します。Googleは、長く続く503をサーバーが恒久的に利用できない兆候と見なし、URLをインデックスから外す場合があると説明しています。
何日まで安全かという固定日数は示されていません。停止が延びれば、503を返しているから問題ないとは判断できません。作業範囲を縮める、公開中の静的ページを残す、復旧手順を見直すなど、停止時間そのものを減らします。
サービスを終了してページを削除する場合や、別URLへ移転する場合は、503を使い続けません。削除なら404または410、移転なら対応するURLへの転送など、URLの今後に合う応答を選びます。
開始前と解除後にヘッダーを確認する
ブラウザーでメンテナンス画面が見えることだけでは、503を確認できません。HTTPヘッダーを表示できるツールで、対象URLを調べます。
curl -I http://www.example.jp/
これは確認方法を示す仮のURLです。トップページだけでなく、検索結果へ出ている代表的な下層URLも確認します。対象URLが503を返し、設定した場合はRetry-Afterがあり、本文を取得するとメンテナンス案内が読めることを見ます。
復旧後は、同じURLが通常の200または本来の応答へ戻り、Retry-Afterが残っていないことを確かめます。開始確認と解除確認を同じURL一覧で行えば、一部だけメンテナンス設定が残る事故を見つけやすくなります。
まず、停止対象の代表URLを三つ選んでください。通常時のステータスを記録し、メンテナンス環境で503、必要に応じたRetry-After、案内本文が同時に返ることを確認してから、本番の停止作業へ進みます。
関連記事

