503 Service Unavailable
503 Service Unavailableエラーは、サーバーが一時的にリクエストを処理できないことを示すHTTPステータスコードで、通常は過負荷またはメンテナンス中であることが原因です。SEOの観点では、サイトメンテナンス中にRetry-Afterヘッダーとともに503を返すことが、ダウンタイムが一時的なものであるとクローラーに伝える推奨方法です。
503は、サーバーが一時的にリクエストを処理できないことを意味するステータスコードで、通常は過負荷やメンテナンス中に発生します。
サイトメンテナンス中は、404や200ではなく503を返すことで、検索クローラーにダウンタイムが一時的なものであると理解させます。
Retry-Afterヘッダーを併用すると、想定される復旧時刻を伝えられ、Googlebotが再クロールのタイミングを調整できます。
503が数日以上続く場合、Googleはサイトが恒久的に停止していると判断し、影響を受けるURLをインデックスから削除することがあります。
503は一時的なレスポンスであるため、キャッシュしないようにし、状況を説明する親切なページをユーザーに表示してください。
概要
503 Service Unavailableエラーは、サーバーがリクエストを処理できる状態ではないことを示すサーバーエラーのレスポンスステータスコードです。MDNのドキュメントによると、最も一般的な原因は、メンテナンスのために停止しているサーバー、または過負荷のサーバーです。メンテナンス中は、管理者がすべてのトラフィックを一時的に503ページへルーティングすることがあります。負荷が高く、メモリ、CPU、接続プールなどのリソース上限に達した場合には、より深刻な障害を防ぐため、一部のサーバーアプリケーションが503でリクエストを拒否します。
重要なのは、503は一時的な状態のために使うものだという点です。ページが完全に削除されたことを意味する404や、エラースクリーンを通常のレスポンスのように見せてしまう200とは異なり、503は「今は対応できませんが、まもなく復旧します」というシグナルを伝えます。
推奨されるSEOでの使い方
Google Search Centralは、計画メンテナンスのためにサイトを短時間停止する場合は、404(Not Found)や200(OK)ではなく503を返すことを推奨しています。503は検索クローラーに対して、ダウンタイムが一時的であり、後で再確認すべきだと伝えます。404を繰り返し返すとGooglebotの再クロールが遅れ、エラーページを200で配信すると、空のページが正規のコンテンツとしてインデックスされる問題につながります。
併用すべきヘッダーはRetry-Afterです。MDNによると、Retry-Afterは503レスポンスにおいてサービスがどれくらいの時間利用不可であると予想されるかを示し、2つの形式で指定できます。1つはレスポンス受信後に待つ秒数の整数、もう1つはHTTP日付形式で示す再試行時刻です。Googlebotはこのヘッダーを尊重し、それに応じて再クロールのタイミングを調整します。
ただし、503を恒久的な対処として使うべきではありません。Google Search Centralによると、503は一時的なダウンタイムには適切ですが、数日以上続く場合、Googleはサーバーが恒久的に利用不可になった兆候と解釈し、影響を受けるURLをインデックスから削除することがあります。つまり、約1日程度の短いメンテナンス期間であれば安全ですが、1週間以上アクセスを遮断すると、方法にかかわらず検索結果に悪影響を及ぼす可能性があります。
主要ステータスコードの比較
コード | 意味 | クローラーへのシグナル | メンテナンスへの適性 |
|---|---|---|---|
200 OK | 通常のレスポンス | 現在のコンテンツは有効です | 不十分(空のエラーページをインデックスするリスクあり) |
404 Not Found | ページは存在しません | リソースは存在しません | 不十分(再クロールが遅れ、インデックス削除のリスクあり) |
503 Service Unavailable | 一時的に利用できません | ダウンタイムは一時的なものです。後でもう一度お試しください | 良好(Retry-After の併用を推奨) |
正しく処理する方法
メンテナンスページを表示する際に最も重要なのは、レスポンスヘッダーが実際に 503 を返していることを確認することです。Yoast によると、キャッシュプラグインは 503 ステータスを正しく引き継げない場合があるため、本番サイトに適用する前に必ずテストする必要があります。MDN でも、503 は一時的な問題であるため、レスポンスをキャッシュしないよう注意すべきだと述べています。キャッシュすると、修正がデプロイされた後でも、クライアントに古いエラーページが表示され続ける可能性があります。状況を説明するページをユーザーに提供することも、よい方法です。
Apache(.htaccess)の例
RewriteEngine On
RewriteCond %{REQUEST_URI} !=/maintenance.html
RewriteRule ^.*$ /maintenance.html [R=503,L]
ErrorDocument 503 /maintenance.html
Header always set Retry-After "3600"Nginx の例
location / {
return 503;
}
error_page 503 /maintenance.html;
location = /maintenance.html {
add_header Retry-After 3600 always;
internal;
}上記の例にあるRetry-After 3600は、1 時間後(3600 秒後)に再試行することを意味します。想定される復旧時刻が分かっている場合は正確な値を設定し、メンテナンスが終了したらすぐに設定を削除してください。
実装チェックリスト
計画メンテナンスには、404 や 200 ではなく 503 ステータスコードを返します。
503 とあわせて Retry-After ヘッダーで、復旧予想時刻(秒数または日付)を通知します。
ダウンタイムはできるだけ短くし、503 を数日間、または 1 週間を超えて継続させないでください。
レスポンスヘッダーを直接確認し、メンテナンスページが実際に 503 を返していることを検証します(キャッシュプラグインに注意してください)。
キャッシュヘッダーを確認し、503 レスポンスがキャッシュされないようにします。
状況と復旧予定時刻を説明するページをユーザーに提供してください。
メンテナンス終了後は、503 の設定と Retry-After ヘッダーをただちに削除してください。