クライアントから「メンテナンス時のHTTPステータスコードはSEOを考慮して503か？」「キャッシュが残らないようCache-Controlは設定されているか？」と問われた際、実際に検証してみると「200 OK」が返ってくるケースがある。
本記事では、各種プラグインが機能しないサーバー環境において、.htaccessを用いて確実に503ステータスとキャッシュ制御ヘッダーを返す手順と、検証時の躓きポイントをまとめる。
発生した事象と根本原因
発生した事象
- WordPressのメンテナンス用プラグイン（LightStart, CMPなど）を有効化し、シークレットモードでアクセスしてもステータスコードが
200 OKになる。 - プラグインの設定画面で「503を出力する」オプションをオンにして保存しても、画面をリロードするとチェックが外れてしまう。
- シンレンタルサーバーのパネルで、WAF、Xアクセラレータ、サーバーキャッシュ等をすべてOFFにしても状況が変わらない。
根本原因
サーバー側（Nginxのリバースプロキシ構成やキャッシュ機構など）の仕様により、PHP（WordPressやプラグイン）が出力したHTTPステータスヘッダーが強制的に 200 OK に上書きされている。
この環境下では、どのプラグインを使用しても503ステータスを正しく出力することはできない。
解決法：.htaccessによるサーバーレベルでの制御
プラグインによる制御を諦め、Apacheの.htaccessを用いてサーバーレベルで強制的に503エラーとキャッシュ無効化ヘッダーを返す。
1. メンテナンス用HTMLの作成
WordPressのインストールディレクトリ（.htaccessと同じ階層）に maintenance.html を作成し、文字コード「UTF-8（BOMなし）」で保存する。
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<meta name="robots" content="noindex, nofollow">
<title>メンテナンス中</title>
<style>body{text-align:center;padding:50px;font-family:sans-serif;}</style>
</head>
<body>
<h1>現在メンテナンス中です</h1>
<p>しばらくしてから再度アクセスしてください。</p>
</body>
</html>2. .htaccessの記述
サーバーから .htaccess を編集し、既存の記述の一番上（先頭）に以下のコードを追記する。
# 503エラー時に表示するファイルを指定
ErrorDocument 503 /maintenance.html
<IfModule mod_rewrite.c>
RewriteEngine On
# maintenance.htmlへの直接アクセスによる無限ループを防止
RewriteCond %{REQUEST_URI} !=/maintenance.html
# 管理者のIPアドレス（自身のIP）を除外（例: 123.45.67.89 を自身のIPに変更）
RewriteCond %{REMOTE_ADDR} !=123.45.67.89
# すべてのアクセスに対し強制的に503を返す
RewriteRule ^.*$ - [R=503,L]
</IfModule>
# maintenance.htmlにキャッシュ無効化ヘッダーを付与
<Files "maintenance.html">
<IfModule mod_headers.c>
Header always set Cache-Control "no-cache, must-revalidate, max-age=0, no-store, private"
</IfModule>
</Files>実装・検証時のよくある躓きポイント（罠）
本対応を行う上で陥りやすい罠と対処法を記載する。
罠1：プラグインの「503設定」が保存されない
LightStart等のプラグインで503を有効化しようとしても、保存後にオフへ戻ってしまうことがある。
これはWAFやREST API制限等のセキュリティ機能がDBへの保存処理を弾いているか、オブジェクトキャッシュが干渉しているため。
ただし、本環境では保存できたとしてもサーバー側で 200 OK に上書きされるため、プラグインでの設定自体を諦める（無効化する）のが正解となる。
罠2：.htaccessへの直接記述による文字化け
.htaccess の ErrorDocument 503 "<html>...日本語...</html>" のように直接日本語を記述すると、サーバーの文字コード設定等の影響で画面が文字化けする。
これを回避するため、上記手順のように外部ファイル（maintenance.html）を作成して読み込ませる方式をとる。
罠3：なぜ「自身のIPアドレス」を除外するのか？
.htaccess に RewriteCond %{REMOTE_ADDR} !=自身のIPアドレス を記述しないと、管理者自身のアクセスもすべて503エラーとなり、WordPress管理画面へのログインやサイトのプレビュー確認が一切できなくなってしまうため。
必ず自身のIPを除外して作業導線を確保する。
罠4：自身のIPを除外した状態での「503」確認方法
自身のIPを除外すると、自分のPCブラウザからは通常通り 200 OK が返るため、メンテナンス設定が成功しているか確認できない。
一般ユーザー視点での503を確認するには、Wi-Fiを切ったスマートフォン（4G/5G通信）からアクセスするか、httpstatus.io などの外部ステータス確認ツールを使用する。
罠5：デベロッパーツールで Cache-Control が見つからない
ブラウザの検証（F12） > 「ネットワーク」タブでヘッダーを確認する際、一番上にある「一般（General）」セクションを見て「設定したはずの Cache-Control が無い」と勘違いしやすい。
キャッシュ制御ヘッダーは、そこから下にスクロールした「レスポンスヘッダー（Response Headers）」セクションの中に表示される。
まとめ
WordPressのメンテナンスモードでSEOを考慮した「503ステータス」と「キャッシュ無効化」を確実に実装する場合、プラグインに依存するのは危険です。
シンレンタルサーバーのような強力なキャッシュ機構やリバースプロキシを持つ環境では、PHPからのヘッダー出力が強制的に上書きされるケースが多発します。
クライアントから正確なステータスコードやキャッシュ制御を求められた際は、ブラウザのシークレットモード（デベロッパーツールのレスポンスヘッダー）や外部ツールでの検証を徹底してください。
プラグインやPHPレベルで解決できない場合は、本記事のように .htaccess と静的HTMLを用いたサーバーレベルでの制御へ速やかに切り替えることが、最も確実で安全な対応となります。