503 Service Unavailable（サービス利用不可）

TL;DR — 503 Service Unavailableレスポンスは、検索エンジンに「サイトは一時的に停止しています。すぐに戻って確認してください」と伝え、「このページは消えた」とは伝えません。計画メンテナンスでサイトをオフラインにする必要があるなら、返すべき正しいコードは503です。Googlebotがいつ戻るか分かるようRetry-Afterヘッダーを追加し、robots.txtに到達できる状態を保ち、503を1〜2日以上続けないでください。

503が実際に意味すること

HTTP 503は、サーバーが一時的にリクエストを処理できないことを意味し、仕様はRetry-Afterヘッダーを許可しています。 Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 9110: 503 Googleは短時間の停止に503を推奨しますが、利用不能が長引くとインデックス登録に影響する可能性があると警告しています。 Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: Pause an online business

503は5xxファミリーに属するHTTPステータスコードです。つまり「サーバー側で何かが間違っている」グループです。具体的には、サーバーは応答できる程度には稼働していますが、今はリクエストを提供できません。通常は過負荷になっているか、メンテナンスモードに入れているためです。

重要な言葉は一時的です。これが、ページを利用できないときに使いたくなるほかのコードと503を分けます。

• 200 OKは「here’s the content」 (翻訳)「これがコンテンツです」と伝えます。その「コンテンツ」が「we’ll be right back」 (翻訳)「すぐに戻ります」というメッセージでも同じです。検索エンジンは文字どおりに受け取り、エラーページをインデックス登録できます。
• 404 Not Found／410 Goneは「このページは存在しない／恒久的に消えた」と伝えます。メンテナンス中に使うと、Googleにページを削除するよう伝えることになります。
• 503 Service Unavailableは “I exist, I’m just busy — come back later.” (翻訳)「存在しますが、今は忙しいので後で戻ってきてください」と伝えます。計画的な停止で使うべきコードはこれです。

メンテナンスに503が正しい理由

デプロイ、サーバー移行、予定されたメンテナンスでは、検索エンジンにページが消えたと判断させるのではなく、一時停止させたいはずです。503ならその猶予を得られます。Googleも直接そう案内しています。サイトを短時間停止する必要があるなら、404でも200のエラーページでもなく、503を返してください。

店舗のドアに「Back in 10 minutes」 (翻訳)「10分で戻ります」と書くようなものだと考えてください。404は店をブルドーザーで壊すようなもので、200の「近日公開」ページは、在庫全体を1枚の看板に置き換えて、それでも靴を売っていると客が思うことを期待するようなものです。503は、場所を維持する看板です。

Retry-Afterヘッダー

503とともに、クローラーにおおよその再訪時期を伝えるRetry-Afterヘッダーを送れます。秒数または特定の日付／時刻を指定できます。

HTTP/1.1 503 Service Unavailable
Retry-After: 3600

この例は、ボットに約1時間待つよう求めています。Googleは再クロール時期のヒントとして使うことがあります。正確な秒に戻るわけではありませんが、それより前に戻ることもありません。

間違えてはいけない3つのこと

1. 503を長期間返さない。 1〜2日なら問題ありません。はるかに長引くと、Googleは停止が恒久的だと考え始め、ページを削除する可能性があります。
2. robots.txtに503を返さない。 このファイルが503を返すと、Googleは何もクロールできません。オンラインに戻ったことを知らせる確認さえできなくなります。
3. 代わりに404や単純な200の「近日公開」ページを使わない。 それらは間違った信号を送り、503より大きな損失になる可能性があります。

期間の閾値、Googleの正確な引用、プラットフォームごとの実装まで知りたいなら、Advancedタブに切り替えてください。

TL;DR — 503は一時的な利用不能に対する正しいコードであり、Googleは404／410（恒久的）や200のエラーページ（インデックス可能な不要コンテンツ）より明確に優先しています。Retry-Afterと組み合わせてください。サイト全体に503を返す場合のGoogle自身の上限は1〜2日です。「数日」を過ぎると、503を恒久的と扱い、URLを削除します。503はインデックス済みメタデータ（タイトル、説明、構造化データ）も凍結し、提供中は更新されません。robots.txtには決して503を返さないでください。Googleはクロールレートのバックオフについて429と503を同じように扱います。長い停止から回復する可能性は高いものの、1対1の回復は保証されません。1〜2日を超える停止では、代わりにインデックス可能な200のプレースホルダーを提供してください。

503とは何か、何ではないか

503は一時的なサーバー状態を示すもので、恒久的な削除信号ではありません。 Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 9110: 503 検索での扱いは期間とレスポンスの繰り返しに左右され、回復時期は保証されません。 Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: Pause an online business

RFC 9110は意図的に柔らかい表現を使っています。サーバーは現在リクエストを処理できず、回復は確実ではなく可能性が高いと説明され、Retry-Afterヘッダーは必須ではなく、MAY（送ってもよい）です。仕様はクローラーが特定の時刻に戻ることを強制せず、サーバーは503を返さず接続を拒否することさえできます。このページ全体にとって重要なのは、以下のGoogleのクロール挙動と回復時期の説明が、契約上の保証ではなく、起こりやすいことを述べている点です。

503は一時的なサーバー側の利用不能のためのものです。「このページを隠す」ための汎用ツールではなく、周辺のコードと置き換え可能でもありません。

• 404／410 — 恒久的な削除です。メンテナンス中に使うと、ページが消えたとGoogleに伝え、削除を始めさせます（410は404より少し速い）。
• エラーコンテンツ付き200 —200 OKを返す「すぐに戻ります」ページは本物のコンテンツに見えます。Googleはインデックス登録し、すべてのURLが同じページを返すと重複として扱う可能性があります。
• 503 Service Unavailable — 一時的な利用不能を示し、削除を意味しないコードです。

Googleが実際に推奨する順序

Googleの現在も更新されている指針（Temporarily pause or disable a website）は、多くの競合記事が飛ばしている優先順を示しています。まずこれを押さえます。

1. そもそも完全停止せず、機能を制限する。 Googleの最優先の推奨は、サイトを稼働させたまま、リスクのある部分だけを無効にすることです（カートを停止し、バナーを表示し、構造化データ／Merchant Centerフィードを更新するなど）。これは「minimizes any negative effects on your site’s presence in Search.」 (翻訳)「サイトの検索上の存在感への悪影響を最小限にする」ためです。サイト全体の503はデフォルトではなく、フォールバックです。

2. サイト全体を停止する必要があるなら、1〜2日のルール。 Googleはサイト全体の停止を「an extreme measure that should only be taken for a very short period of time (a few days at most),」 (翻訳)「ごく短い期間（長くても数日）だけ実施すべき極端な手段」と呼び、仕組みも具体的に示しています。 “If you need to urgently disable the site for 1-2 days, then return an informational error page with a 503 HTTP response status code instead of all content.” (翻訳)「サイトを緊急に1〜2日停止する必要があるなら、すべてのコンテンツの代わりに、503 HTTPレスポンスステータスコードを付けた情報エラーページを返します。」

3. それより長いなら、インデックス可能な200のプレースホルダーに切り替える。 1〜2日を過ぎたらこの応答の提供を止めます。Googleは「If you need to disable the site for a longer time, then provide an indexable home page as a placeholder for users to find in Search by using the 200 HTTP status code.」 (翻訳)「サイトをより長く停止する必要があるなら、200 HTTPステータスコードを使い、検索ユーザーが見つけられるインデックス可能なホームページをプレースホルダーとして提供してください」と案内しています。

期間のスペクトラム（単一の厳格な境界はない）

Googleの異なる資料は、魔法のような1つの数字ではなく、スペクトラムを示しています。これはコンプライアンス保証ではなく方向性です。Googleの現在の文書から来る唯一の数値は、下記の1〜2日の上限です。分や日単位の数値は、GoogleスタッフのコメントをSearch Engine Journalがオフィスアワーから伝えたものであり、Googleに対して根拠として示せる一次資料の発言ではありません。

• 時々の数分。 Gary Illyes（Search Engine Journal経由）：「Serving a 503 status code for an extended period of time will cause a decrease in crawl rate. Fortunately for you, 10-15 minutes every now and then is not ‘extended’ by any means, so you should be fine.」 (翻訳)「503ステータスコードを長期間返すとクロールレートが低下します。幸い、10〜15分を時々返す程度は決して『長期間』ではないので、問題ないはずです。」
• 1日程度。 John Mueller（Search Engine Journal経由）：「For an outage of maybe a day or so, using a 503 result code is a great way to tell us that we should check back.」 (翻訳)「1日程度の停止なら、503結果コードを使うことは、再確認すべきだと私たちに伝える良い方法です。」
• 1〜2日。 緊急のサイト全体503についてGoogleが文書化した上限です。この一覧でGoogleの現在の一次資料に基づく唯一の数値です。
• 「数日」とそれ以降。 ここで状況が変わります。Mueller（Search Engine Journal経由）：「after a couple of days we think this is a permanent result code, and we think your pages are just gone, and we will drop them from the index.」 (翻訳)「数日後にはこれを恒久的な結果コードと考え、ページは消えたものと考え、インデックスから削除します。」
• 数週間。 インデックス喪失がほぼ確実となり、文書によれば完全削除からの回復には「no fixed time … and there’s no mechanism to speed that up.」 (翻訳)「固定された期間はなく、速める仕組みもない」という状態です。

これらを合計して、安全期間のカウントダウン時計になるわけではありません。起こりやすいことを説明しているのであって、特定の結果を頼れるルールではありません。1〜2日という数字は計画上の外縁として扱い、その範囲内ならリスクがないという保証とは考えないでください。

メタデータ凍結の副作用（誰も話さないリスク）

短く正しい503にも見落とされがちなコストがあります。503を返している間、Googleはすでに保持している情報を更新できません。文書から直接引用すると、「it’s not possible for Google’s systems to refresh titles, descriptions, metadata, or structured data included on a website if a page returns a 503 HTTP response code.」 (翻訳)「ページが503 HTTPレスポンスステータスコードを返す場合、GoogleのシステムはWebサイトに含まれるタイトル、説明、メタデータ、構造化データを更新できません。」

つまり503はインデックス済みメタデータを凍結します。消去するわけでも更新するわけでもありません。メンテナンス直前にタイトルやスキーママークアップを変更したなら、古いSERPスニペットが停止期間中ずっと残る可能性があります。「安全」とは「短時間なら恒久的な害がない」という意味であり、「見えない」という意味ではありません。

robots.txtには決して503を返さない

これは現実に起きる危険な落とし穴です。メンテナンスモードのプラグインやCDNの包括的なルールが、robots.txtを含むすべてに503を返すことがあります。やめてください。Googleは明確に、「Don’t return a 503 HTTP response status code for the robots.txt file because this blocks all crawling.」 (翻訳)「robots.txtファイルに503 HTTPレスポンスステータスコードを返さないでください。すべてのクロールがブロックされます」と述べています。503のrobots.txtはGoogleが何もクロールできない状態にし、復旧を確認する再クロールまで止めます。サイト全体の停止中もrobots.txtは200を返し続けてください。

503と429 — Googleは同じように扱う

レート制限の文脈では「429 or 503」を同じ意味で検索する人がいます。クロールレートに関して、Googleにとって両者は同等です。Mueller（後に自分で古いページだと示したページ上）の言葉では、「we treat them both about the same. We see both as a temporary issue, and tend to slow down crawling if we see a bunch of them.」 (翻訳)「どちらもほぼ同じように扱います。どちらも一時的な問題と見なし、多数見つけるとクロールを遅くする傾向があります。」同じバックオフの仕組みであり、429 Too Many Requestsと503はいずれもGooglebotに速度を落とすよう伝えます。（仲間である502／504、ほかの一時的なゲートウェイ／タイムアウトエラーも同様に扱われます。どの種類でも継続する5xxはクロールを遅くします。）

回復する可能性は高いが、保証はない

このテーマで最も役立つ神話の修正は、長い停止によってページが削除されても、通常は戻るものの、常に同じとは限らないということです。Muellerは「when the pages come back we will crawl them again and we will try to index them again. But it’s essentially during that time we will probably drop a lot of the pages from the website from our index, and there’s a pretty good chance that it’ll come back in a similar way but it’s not always guaranteed.」 (翻訳)「ページが戻れば再びクロールし、再びインデックス登録を試みます。しかしその間に、Webサイトの多くのページをインデックスから外す可能性が高く、同じような形で戻る可能性はかなりありますが、常に保証されるわけではありません」と述べています。回復が不完全になる可能性もあるものとしてメンテナンス期間を計画してください。実際にそうなることがあります。

直接答える価値のあるFAQ

• 503はSEOに悪影響を与えますか？ 短時間かつ正しく使う限りはありません。Retry-After付きの短い503は、計画停止の意図された信号です。害が出るのは長く返し続ける場合、またはrobots.txtにも503を返す場合です。
• メンテナンスには503と404のどちらがよいですか？ 常に503です。404は「消えた」と伝えてインデックス削除を始め、503は「すぐ戻る」と伝えます。
• WordPressは更新中に503を返しますか？ はい。WordPressはコアやプラグインの更新中、自動的に503を提供します。これは正しい動作で、通常は数秒です。
• 代わりに200で「近日公開」ページを表示できますか？ いいえ。200のエラーページはコンテンツとしてインデックス登録され、すべてのURLで同じページを返すと、Googleがそれらを重複として扱う可能性があります。

覚えておくべき1つのルール

**緊急のサイト全体503についてGoogle自身が示す上限は1〜2日です。これは計画上の外縁であり、安全が保証された期間ではありません。**その範囲内でも503はクロールレートを一時停止し、メタデータを凍結します。このページのどこにも、特定のランキング、インデックス登録、回復の結果を約束する記述はありません。**その上限を超える前に、Googleがページは消えたと判断する前に、インデックス可能な200のプレースホルダーに切り替えてください。**このページのほかの内容は、すべてこの注記です。

隣接するコードについては、HTTPステータスコードクラスターのほかのページを参照してください。

AI summary

Advanced版の要約です。

• 503＝一時的な利用不能。 計画メンテナンスに正しいコードであり、Googleは404／410（恒久的）や、コンテンツとしてインデックス登録される200のエラーページより503を優先します（重複として扱われることもあります）。
• Retry-Afterと組み合わせる。 秒数またはHTTP日付を指定します。ただしRFC 9110ではヘッダーは任意（MAY）です。Googlebotは再クロール時期のヒントとして使い、クロールレートを下げることがありますが、正確な時刻の再訪を強制するものはありません。
• 期間は保証ではなくスペクトラムです。 Googleの現在の文書から来る唯一の数値は、緊急のサイト全体503に対する文書化された上限の1〜2日です。Search Engine Journal経由のGoogleスタッフコメントは、短い期間（10〜15分、約1日）は通常問題なく、「数日」以上でGoogleが503を恒久的と扱いページを削除し始めるとしています。これは方向性であり、一次資料に基づく約束ではありません。長期の停止では、代わりにインデックス可能な200のプレースホルダーを提供します。
• メタデータは凍結される。 503を返している間、Googleはタイトル、説明、構造化データを更新できないため、古いスニペットが残ることがあります。
• robots.txtには決して503を返さない。 復旧を確認する再クロールも含め、すべてのクロールをブロックします。
• クロールレートのバックオフでは429と503はほぼ同じ。 Googleは同じように扱います。
• 長い停止後の回復は起こりやすいが「not always guaranteed」 (翻訳)「常に保証されるわけではない」（Mueller）で、完全なインデックス削除からの回復に固定された期間はありません。
• 全体としてのベストプラクティス。 Googleの最優先推奨は完全停止を避け、機能を制限してサイトを稼働させることです。

公式ドキュメント

503と計画停止に関する一次資料の指針です。

Google

• ウェブサイトを一時停止または無効化する — Googleの現在の公式指針です。優先順、1〜2日のルール、Retry-After、robots.txtの例外、メタデータ凍結の注記、curlによる確認方法を扱います。
• 計画停止にどう対処するか（2011年ブログ記事） — 元の解説（現在は「古い内容のためベストプラクティスを参照」バナー付き）です。定番のPHPRetry-After例の出典です。
• In-Depth Guide to How Google Search Works — クロールレートのバックオフの背景を説明します。HTTP 500ファミリーのエラーは「slow down」 (翻訳)「速度を落とす」を意味します。

RFC／技術リファレンス

• MDN — 503 Service Unavailable — ステータスコードの標準ベースの定義です。
• MDN — Retry-After header — 秒数形式とHTTP日付形式の構文です。

Bing／Microsoft

• BingはGoogleと同じ粒度の503メンテナンス指針を公開していません。Retry-AfterはGoogle固有ではない標準RFCヘッダーであり、Bingbotも5xx／429レスポンスが繰り返されるとクロールレートを下げます。ただし、具体的なBingの挙動は、文書化された声明ではなく標準HTTP意味論から推測したものとして扱ってください。

原文からの引用

Googleによる記録に残る発言です。各リンクは出典ページの引用箇所へ直接移動します。

Googleの文書 — 1〜2日のルール

• “If you need to urgently disable the site for 1-2 days, then return an informational error page with a 503 HTTP response status code instead of all content.” (翻訳)「サイトを緊急に1〜2日停止する必要があるなら、すべてのコンテンツの代わりに、503 HTTPレスポンスステータスコードを付けた情報エラーページを返してください。」 Jump to quote
• “If you need to disable the site for a longer time, then provide an indexable home page as a placeholder for users to find in Search by using the 200 HTTP status code.” (翻訳)「サイトをより長く停止する必要があるなら、200 HTTPステータスコードを使い、検索ユーザーが見つけられるインデックス可能なホームページをプレースホルダーとして提供してください。」 Jump to quote

Googleの文書 — robots.txtとメタデータ

• “Don’t return a 503 HTTP response status code for the robots.txt file because this blocks all crawling.” (翻訳)「robots.txtファイルに503 HTTPレスポンスステータスコードを返さないでください。すべてのクロールがブロックされます。」 Jump to quote
• “it’s not possible for Google’s systems to refresh titles, descriptions, metadata, or structured data included on a website if a page returns a 503 HTTP response status code.” (翻訳)「ページが503 HTTPレスポンスステータスコードを返す場合、GoogleのシステムはWebサイトに含まれるタイトル、説明、メタデータ、構造化データを更新できません。」 Jump to quote
• “removing a site completely from Google’s index is a significant change that can take quite some time to recover from.” (翻訳)「サイトをGoogleのインデックスから完全に削除することは大きな変更であり、回復にはかなり時間がかかる可能性があります。」 Jump to quote

Google検索セントラルブログ（2011年）

• “instead of returning an HTTP result code 404 (Not Found) or showing an error page with the status code 200 (OK) when a page is requested, it’s better to return a 503 HTTP result code (Service Unavailable) which tells search engine crawlers that the downtime is temporary.” (翻訳)「ページが要求されたとき、HTTP結果コード404（Not Found）を返したり、ステータスコード200（OK）のエラーページを表示したりするのではなく、停止が一時的だと検索エンジンのクローラーに伝える503 HTTP結果コード（Service Unavailable）を返すほうがよい。」 Jump to quote
• “If known, the length of the downtime in seconds or the estimated date and time when the downtime will be complete can be specified in an optional Retry-After header, which Googlebot may use to determine when to recrawl the URL.” (翻訳)「分かっている場合は、停止期間を秒数で指定するか、停止が終わる予定の日付と時刻を任意のRetry-Afterヘッダーに指定できます。GooglebotはURLの再クロール時期を判断するために使うことがあります。」 Jump to quote

John Mueller、Google

• “please return a ‘503 Service unavailable’ HTTP result code… they’re generally more than happy to give your site some time to catch up again.” (翻訳)「『503 Service unavailable』HTTP結果コードを返してください。通常、サイトが再び追いつくための時間を喜んで与えます。」 Jump to quote johnmu.com/503s/（2013年）からの引用です。MuellerがGoogle+投稿を個人的に再掲載したものです。ライブページは活字のアポストロフィを表示するため、正確なテキストに一致させるためディープリンクは短く保っています。
• “we treat them both about the same. We see both as a temporary issue, and tend to slow down crawling if we see a bunch of them.” (翻訳)「429と503はほぼ同じように扱います。どちらも一時的な問題と見なし、多数見つけるとクロールを遅くする傾向があります。」（429と503について） Jump to quote johnmu.com/429-or-503/（2015年）からの引用です。Mueller自身が「old, probably outdated」 (翻訳)「古く、おそらく時代遅れ」と示しているページです。
• “after a couple of days we think this is a permanent result code, and we think your pages are just gone, and we will drop them from the index.” (翻訳)「数日後にはこれを恒久的な結果コードと考え、ページは消えたものと考え、インデックスから削除します。」 Jump to quote Search Engine JournalがSearch Centralのオフィスアワー／Q&Aから伝えたものです。最終的な引用として扱う前に、元の出典で確認してください。

Gary Illyes、Google

• “Serving a 503 status code for an extended period of time will cause a decrease in crawl rate. Fortunately for you, 10-15 minutes every now and then is not ‘extended’ by any means, so you should be fine.” (翻訳)「503ステータスコードを長期間返すとクロールレートが低下します。幸い、10〜15分を時々返す程度は決して『長期間』ではないので、問題ないはずです。」 Jump to quote Google Search CentralのSEOオフィスアワーのセッションからSearch Engine Journalが伝えたものです。

計画メンテナンス用503チェックリスト

メンテナンス期間の前、最中、後にこれを実行します。

• サイト全体の停止が本当に必要か決めた。代わりに機能を制限して稼働を続けられますか（Googleの推奨オプション）？
• メンテナンスページが本物の**503**ステータスを返す（ブラウザーで目視するだけでなく、curlで確認した）。
• **Retry-After**ヘッダーが設定され、現実的な見積もり（秒数またはHTTP日付）がある。
• robots.txtが200を返し続け、到達できる。決して503にしない。
• 503ページが軽量である。静的HTML、インラインCSS、重いアセットなし（ボットは繰り返しアクセスします）。
• 期間が約1〜2日を超えたら200のインデックス可能なプレースホルダーへ切り替える、厳格な内部期限を設定した。
• 503の代わりに、404／410や200の「近日公開」ページを返すURLがない。
• 期間中と後に、Search ConsoleのPage IndexingとCrawl Statsで5xxの急増を監視している。
• メンテナンス後、ページが200に戻ったこと、主要URLをURL Inspectionで新たにクロール送信したこと、メタデータ／スニペットが更新されたことを確認した。

SOP：サイトを正しく計画メンテナンスモードにする

短く安全なメンテナンス期間のために、繰り返し使える手順です。

期間の前に

1. 範囲を決める。 サイトを稼働させたまま、リスクのある部分（カート、チェックアウト、壊れた機能）だけを無効にできるなら、そうします。Googleの最優先推奨であり、以下のリスクをすべて避けられます。本当にすべてをオフラインにする必要がある場合だけ、サイト全体の503へ進みます。
2. 期間を正直に見積もる。 現実的に1〜2日を超えるなら、サイト全体503を計画せず、代わりにインデックス可能な200のプレースホルダーホームページを計画します。
3. 軽量なメンテナンスページを作る。 静的HTML、インラインCSS、画像はbase64またはなしにします。ボット（とユーザー）が繰り返しアクセスするため、ページ自体がサーバーに負荷をかけてはいけません。

レスポンスを設定する

4. サイトコンテンツに本物の503を返す。 例：
   • Apache（.htaccess）：すべてをメンテナンスページへルーティングし、ステータスを強制します。

     RewriteEngine On
     RewriteCond %{REQUEST_URI} !^/maintenance\.html$
     RewriteCond %{REQUEST_URI} !^/robots\.txt$
     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 { internal; add_header Retry-After 3600; }
     location = /robots.txt { }   # keep robots.txt serving 200

   • PHP（Google自身の例の形式）：

     header('HTTP/1.1 503 Service Unavailable');
     header('Retry-After: 3600');

5. Retry-Afterを設定する。 現実的な見積もり（秒数3600またはHTTP日付）を指定します。
6. robots.txtを除外する。 robots.txtが引き続き200を返すようにします（上の書き換え条件を参照）。多くの人が見落とす手順です。

確認する

7. ブラウザーではなくcurlでステータスを確認する。

   curl -I -X GET "https://www.example.com/"
   # expect: HTTP/1.1 503 Service Unavailable  +  Retry-After: ...
   curl -I "https://www.example.com/robots.txt"
   # expect: HTTP/1.1 200 OK

期間中と後

8. 時間を監視する。 1〜2日の上限に近づいたら、Googleが503を恒久的と扱い始める前に、200のインデックス可能なプレースホルダーへ切り替えます。
9. サイトを戻す。 503のルールを削除し、ページが再び200を返すことを確認します。
10. 再確認する。 主要ページをGSC URL Inspectionで確認し、Crawl Statsで5xxの急増が収まるのを監視し、タイトル／説明／構造化データが更新されることを確認します（503中は凍結されていました）。

してはいけないこと — その背景にある神話

神話：「Retry-Afterを使えば、数日を超える503も完全に安全。」 Retry-Afterは精度を上げますが、Googleの上限を上書きしません。文書は緊急のサイト全体503を1〜2日に制限し、Muellerは「after a couple of days we think this is a permanent result code… and we will drop them from the index.」 (翻訳)「数日後には恒久的な結果コードと考え、インデックスから削除します」と述べています。そこに達する前に200のプレースホルダーへ切り替えてください。

神話：「正しく実装すれば503はSEOへの影響がゼロ。」 短く正しい503でもメタデータの更新を一時停止します。提供中はタイトル、説明、構造化データを更新できず、503はクロールレートも下げます。「安全」とは「短時間なら恒久的な害がない」という意味で、「見えない」という意味ではありません。

神話：「メンテナンス中は404や200の『近日公開』ページでも同じくらいよい。」 違います。404／410は恒久的な削除を示し、ページがより速く削除されます。包括的な200のエラーページはコンテンツとしてインデックス登録され、すべてのURLが同じページを返すとGoogleは重複として扱う可能性があります。

神話：「念のためrobots.txtにも503を返すべき。」 逆です。503のrobots.txtは、サイトが戻ったことを確認する再クロールも含め、すべてのクロールをブロックします。200のままにしてください。

神話：「停止中にGoogleがページを削除しても、まったく同じように戻る。」 可能性は高いですが、Muellerによれば*「not always guaranteed」* (翻訳)「常に保証されるわけではありません」。完全削除からの回復には固定された期間も、速める方法もありません。

神話：「429と503はまったく異なる信号。」 クロールレートのバックオフについて、Googleは「treat[s] them both about the same.」 (翻訳)「どちらもほぼ同じように扱う」としています。

**記憶に刻むべきアンチパターン：**単純な200 OKの「down for maintenance」 (翻訳)「メンテナンス中」ページを返すことです。最も一般的なミスであり、Googleが最も直接的に警告しているものです。

メンテナンス用503 — チートシート

状況ごとのコード

期間のスペクトラム

1〜2日の行は、Googleが現在の文書で示す独自の上限です。分と日の行は、Search Engine Journalが伝えたGoogleスタッフのコメントであり、Googleの一次資料ではありません。このスペクトラムは方向性として読み、保証された安全なコンプライアンス期間とは考えないでください。

Retry-Afterの形式

• 秒数：Retry-After: 3600
• HTTP日付：Retry-After: Sat, 8 Oct 2011 18:27:00 GMT

忘れないルール

• robots.txtは200のままにし、決して503にしない。
• 503ページ＝静的HTML、インラインCSS（ボットが繰り返しアクセスします）。
• 503はインデックス済みのタイトル／説明／スキーマを凍結し、更新されない。
• ブラウザーではなくcurl -Iで確認する。

503が実際に503であることを確認する

ブラウザーはメンテナンスページを表示していても、サーバーはひそかに200を返していることがあります。curlで本当のステータスコードとヘッダーを確認してください。

macOS／Linux

# Site content should return 503 with a Retry-After header
curl -I -X GET "https://www.example.com/"
# expect: HTTP/1.1 503 Service Unavailable
#         Retry-After: 3600

# robots.txt must stay reachable (200), NOT 503
curl -I "https://www.example.com/robots.txt"
# expect: HTTP/1.1 200 OK

Windows（PowerShell）

# -SkipHttpErrorCheck lets PowerShell show the 503 instead of throwing
(Invoke-WebRequest -Uri "https://www.example.com/" -Method Head -SkipHttpErrorCheck).StatusCode
(Invoke-WebRequest -Uri "https://www.example.com/robots.txt" -Method Head).StatusCode

最小限の503レスポンス

PHP（Google自身の例の形式）

<?php
header('HTTP/1.1 503 Service Unavailable');
header('Retry-After: 3600'); // or an HTTP date: 'Sat, 8 Oct 2011 18:27:00 GMT'
?>
<!DOCTYPE html>
<title>We'll be right back</title>
<h1>Down for scheduled maintenance</h1>
<p>We expect to be back within the hour. Thanks for your patience.</p>

Nginx（コンテンツは503、robots.txtは除外）

location / {
    return 503;
}
error_page 503 /maintenance.html;
location = /maintenance.html {
    internal;
    add_header Retry-After 3600;
}
location = /robots.txt { }   # keep serving robots.txt normally (200)

メンテナンスページはインラインCSS付きの静的ページにし、重いアセットを使わないでください。ボットは繰り返しリクエストするため、ページ自体がサーバーに負荷をかけないようにします。

503を扱い、確認するためのツール

• curl -I — ブラウザーが真実を隠す場合でも、本当のステータスコードとRetry-Afterヘッダーを確認する最速の方法です。Scriptsタブを参照してください。
• Google Search Console — URL検査 — 特定URLの最後のクロールステータスを確認し、オンライン復帰後に新しいクロールをリクエストします。
• GSC — クロール統計レポート — 期間中の5xx／503の急増を監視し、その後収まることを確認します。
• GSC — ページのインデックス登録レポート — 停止が長引いた場合に削除されたページを見つけます。
• Screaming Frog SEO Spider — 自サイトをクロールし、どのURLが503と200を返すか（robots.txtが503になっていないことも）確認します。
• Ahrefs監査／Ahrefsウェブマスターツール — サイト全体の5xxレスポンスを示し、期間を過ぎても残る503を検出できます。
• WordPressのメンテナンスモードプラグイン（例：WP Maintenance Mode）— WordPressはコア／プラグイン更新中にすでに自動的に503を返します。プラグインを使えば制御されたメンテナンスページを提供できますが、robots.txtに503を返さないことを確認してください。

時間をかける価値のあるリソース

私の関連する記事

• SEO向けHTTPステータスコード完全一覧 — SEOに重要なステータスコードを5xxの文脈で扱う、私の完全ガイドです。503を含むこのテーマの深掘りは、同ガイドの1行の説明を拡張したものです。
• テクニカルSEO入門ガイド — クロール、ステータスコード、メンテナンスが大きな全体像のどこに位置するかを説明します。

業界からの情報

• ウェブサイトを一時停止または無効化する （Google検索セントラル）— 現在の公式指針です。まずこれを読んでください。
• 計画停止にどう対処するか （Google検索セントラル・ブログ、2011年）— 元の解説と定番のPHPRetry-After例です。
• 503の応答 （John Mueller、johnmu.com）— 停止中に503を使う理由についてMueller自身が平易に説明しています。
• Google検索における503ステータスコードの影響 （検索エンジン・ジャーナル）—「10〜15分なら問題ない」という数値についてGary Illyesが説明します。
• サイト停止が数日続くとGoogleがページをインデックスから外す （検索エンジン・ジャーナル）— Muellerの「数日後には削除する」という閾値です。
• HTTP 503：SEOのためにサイトメンテナンスを正しく扱う （Yoast）—Retry-Afterの仕組みを扱う、実務的でWordPress寄りの解説です。
• 503サービス利用不可 （MDN）— ステータスコード自体の標準リファレンスです。

動画

• Google Search Central（YouTube）— How Google Search WorksシリーズとSEOオフィスアワーのアーカイブです。MuellerとIllyesが、このページ全体で引用した503／メンテナンス／インデックス削除の時期に関する質問に答えています。 Channel

引用する価値のある統計

• 1〜2日 — 緊急停止時にサイト全体で503を使う場合の、Googleが文書化した上限です。それを超える場合は200のプレースホルダーに切り替えます。 Source
• 10〜15分、時々なら問題なし — クロールレートを損なわずに済む503期間の短さについてのGary Illyesの発言です。 Source
• 「数日」 — Googleが503を恒久的と扱い、ページをインデックスから削除し始める時点（John Mueller）。 Source
• 回復期間は固定されていない — 完全削除からの回復についてGoogleが示す文書です。決まった期間も、速める方法もありません。 Source

自分で確認する：503 Service Unavailable

計画メンテナンスで503を使う方法についての簡単な5問です。それぞれ回答を選んでから、答えを確認してください。

変更履歴