メンテナンス中サイトの対応を誤ると、せっかく築いた検索評価を一時的に失う原因になります。Googleは一時的なメンテナンスであれば「503 Service Unavailable」と「Retry-After」ヘッダーの組み合わせを推奨しています。この正しい実装さえ押さえれば、クローラーは再訪問を待機し、順位への悪影響を最小限に抑えられます。
なぜ今「メンテナンス中サイト」の対応が重要なのか
近年はコアアップデートの頻度が増し、サイトの技術的健全性が順位へ与える影響が大きくなっています。不適切なステータスコード（200 OKや404）を返すと、メンテナンスページがインデックスされ「質の低いコンテンツ」とみなされるリスクがあります。実際に筆者が関与した中規模ECサイトでは、503未実装のメンテナンス後にオーガニック流入が約15%減少した事例があります。適切な実装は単なるマナーではなく、資産防衛の必須要件です。
仕組みと基本的な表示タイミング
クローラーに伝えるべき3つのシグナル
Googlebotがメンテナンス中サイトを正しく理解するには、以下の3点をサーバー側で制御する必要があります。
- HTTPステータスコード「503 Service Unavailable」を返す
- 「Retry-After」ヘッダーで再訪問目安時刻（秒または日時）を指定する
- ユーザー向けにはメンテナンス理由と復旧予定を記したHTMLを表示する
これらが揃って初めて「一時的な停止」と判断され、インデックスからの削除を防げます。逆に200 OKを返すと「薄いページ」として評価され、404/410だと「恒久的な削除」と誤認されます。
ステータスコードの使い分け比較
| ステータスコード | 意味 | SEOへの影響 | 推奨シーン |
|---|---|---|---|
| 503 Service Unavailable | 一時的に利用不可 | クローラーが再訪問を待機（インデックス維持） | 計画的メンテナンス、一時的な高負荷 |
| 200 OK | 正常応答 | メンテページがインデックスされるリスク大 | 非推奨 |
| 404 Not Found | 見つからない | URLがインデックスから削除される可能性 | ページ恒久削除時のみ |
| 302 Found | 一時的リダイレクト | リダイレクト先が評価される（メンテページ非推奨） | 別URLへの一時誘導時 |
適切な設定がもたらすメリットと現実的なリスク
メリット：評価の維持とユーザー体験の担保
正しく503を返せば、Googleは「数時間〜数日」の再クロールをスケジュールします。この間、既存のランキングシグナル（被リンク評価やコンテンツ品質スコア）は維持されます。また、ユーザーには「いつ戻ればよいか」が明確に伝わるため、直帰率の悪化やブランド信頼の毀損を防げます。
リスク：長期化によるインデックス削除
Retry-Afterで指定した時刻を大幅に超えて復旧しない場合、Googleは「実質的なサイト消滅」と判断し、URLをインデックスから外すことがあります。目安として2週間以上の長期メンテナンスは避け、やむを得ない場合は最小限の静的コンテンツ（トップページのみ等）を200で返す運用に切り替える判断が必要です。[INTERNAL_LINK_1]
よくある誤解と正しい理解
誤解1：「robots.txtでDisallowすればクロールされないから安全」
robots.txtはクロール拒否の指示であり、インデックス削除の指示ではありません。外部リンク経由でURLが知られていれば、クロールせずにインデックスされる「インデックス登録のみ」の状態になり、検索結果に「説明文がありません」と表示されます。503返却が正解です。
誤解2：「JavaScriptでリダイレクトやメッセージ表示すればOK」
GooglebotはJSを実行できますが、レンダリングキューに入るまでタイムラグがあります。サーバーレベル（Apache/Nginx/PHP等）で503ヘッダーを即時返すのが確実かつ高速です。JS依存は避けてください。
誤解3：「短時間なら何もしなくていい」
数分のメンテナンスでも、タイミング悪くクローラーが来れば影響を受けます。.htaccessやWebサーバー設定でワンコマンドで503を返せるよう、常時テンプレートを用意しておくのがプロの現場での標準運用です。
どのようなサイト運営者に必要か
以下に該当する場合、優先的に実装リソースを割くべきです。
- オーガニック流入で売上・リードを獲得しているEC・BtoBサイト
- 定期的なシステムリリースやDBメンテナンスがある開発チーム
- サーバー移転やSSL化、CMSバージョンアップを控えている担当者
- 「検索順位が落ちた」と経営層から問われたくないWeb責任者
逆に、更新頻度が低く検索流入に依存しないコーポレートサイト等では、簡易的な静的ページ+200返却でも即時の被害は限定的ですが、ベストプラクティスから外れることは理解しておきましょう。
今すぐできる対応ステップ（Apache/Nginx共通の考え方）
- メンテナンス用の静的HTMLファイル（maintenance.html）を用意し、理由・復旧予定・問い合わせ先を記載する
- Webサーバー設定で、特定IP（運営者）以外のアクセスを全てmaintenance.htmlへ内部リライトし、ステータス503を返すルールを記述する
- レスポンスヘッダーに「Retry-After: 3600」（1時間後）等を追加する
- 本番適用前、ステージング環境でcurl -I コマンドやブラウザ開発ツールで「503」と「Retry-After」が返るか検証する
- メンテナンス実施時は設定を有効化し、終了時に即座に無効化する運用フローをドキュメント化する
詳細な公式ガイドラインは Google検索セントラルのHTTPステータスコード解説 を参照してください。
よくある質問
メンテナンス中に503を返さず200で独自ページを出すとどうなりますか？
メンテナンスページが検索結果にインデックスされ、「このサイトはメンテナンス中です」という薄いコンテンツとして評価されるリスクがあります。順位低下の原因になるため避けてください。
Retry-Afterの値は秒数と日時のどちらが良いですか？
どちらも仕様上有効ですが、運用ミスを防ぐため「秒数（例: 3600）」で指定するのが安全です。日時指定（HTTP-date形式）はタイムゾーン設定ミスで過去日時になり、即時再クロールを招く恐れがあります。
WordPressサイトでプラグインなしで503を返す方法は？
.htaccessに「ErrorDocument 503 /maintenance.html」とリライトルールを追加し、メンテナンス時のみ有効化するのが最も軽量で確実です。プラグイン依存は更新時の不具合リスクがあるため非推奨です。
