ホームページのメンテナンス中表示が戻らない｜原因5つ

朝、自社のホームページを開いたら「ただいまメンテナンス中です」。更新作業をした覚えはないし、制作会社に聞いても要領を得ない。数時間経っても戻らない——。この状態で一番危ないのは、原因が分からないまま、サーバーのファイルをあれこれ触ってしまうことです。消してはいけないものを1つ消すと、メンテナンス画面がエラー画面に変わるだけです。

先に結論です。やるべきことは「直す」より前に「誰がその画面を出しているのか」を特定することです。出どころは大きく5つ（WordPress自身／メンテナンスモード系プラグイン／レンタルサーバー／CDNなどの前段／制作会社が置いた工事中ページ）で、どれなのかは、画面の見た目とHTTPステータスコードを見れば数分で絞り込めます。一番多いのはWordPressの自動更新が途中で止まって .maintenance というファイルが残っているケースですが、実はそれ以外も珍しくありません。

そしてもう1つ、経営上たいせつな話があります。メンテナンス画面を「200 OK」で返し続けると、Googleにその画面の中身がインデックスされうるということです。正しくは 503（Service Unavailable） を返します。この記事では、WordPress本体のソースコードとGoogle検索セントラルの公式ドキュメントで確認できる仕様だけを使って、切り分け→対処→再発防止の順に整理します。ファイルを触る手順には、必ずバックアップの注意を添えています。

まず切り分ける：その画面は誰が出しているのか

同じ「メンテナンス中」でも、出している主体によって、触る場所も直し方もまったく違います。最初にこの表で当たりを付けてください。

見分けの決め手は2つです。「WordPressの管理画面（/wp-admin）には入れるか」と、「返ってきているHTTPステータスコードは何番か」。この2つを先に確認するだけで、5つのうち3つは消えます。

HTTPステータスコードの見方（専門知識は不要）

ステータスコードは、サーバーが「この画面は何の画面か」をブラウザとGoogleに伝える番号です。200は「正常なページです」、503は「一時的に止まっています」を意味します。見た目は同じメンテナンス画面でも、この番号が違えば意味はまるで別物です。

• Chromeで見る：ページ上で右クリック →「検証」→「ネットワーク」タブを開き、画面を再読み込み。一覧の一番上（自分のURLの行）の「ステータス」列に番号が出ます。
• コマンドで見る：Macのターミナルなどで curl -I https://あなたのドメイン/ と打つと、1行目に HTTP/2 503 のように出ます。
• Search Consoleで見る：URL検査でライブテストを実行すると、Googleから見た取得結果が分かります。

手元では見えているのに、他の人からは見えない（あるいはその逆）というときは、ブラウザのキャッシュを疑ってください。シークレットウィンドウやスマホの回線（Wi-Fiを切ってモバイル回線）で開き直すと、本当の状態が分かります。

①WordPress自身が出している場合（.maintenance）

もっとも件数が多いのがこれです。まずは仕様を正確に押さえてください。「消せばいい」と書いてある解説は多いのですが、その前に知っておくべき重要な仕様があります。

仕様：10分で自動的に解除される

WordPressは本体・プラグイン・テーマを更新するとき、サイトのルートフォルダに .maintenance というファイルを自動で作ります（WP_Upgrader::maintenance_mode()）。中身は $upgrading という変数に「ファイルを作った時刻」を入れただけの、ごく短いファイルです。更新が正常に終われば自動的に削除されます。

訪問者側では、WordPressの起動処理の冒頭（wp-settings.php）で wp_maintenance() が呼ばれ、メンテナンス中と判定されると次の応答を返して処理を打ち切ります。WordPress開発者向けリファレンスで公開されているソースコードのとおりです。

• HTTPステータス 503
• ヘッダー Retry-After: 600（＝600秒後に再訪してください）
• 本文「Briefly unavailable for scheduled maintenance. Check back in a minute.」（日本語環境では「現在メンテナンス中のため、しばらくの間ご利用いただけません。」）
• wp-content/maintenance.php が置いてあれば、代わりにそちらが表示される

ここからが本題です。判定を行う wp_is_maintenance_mode() には、次の1行が入っています。

ファイル作成から10分（10 * MINUTE_IN_SECONDS）以上経っていれば、メンテナンスは終わったものとみなす

つまりWordPressの仕様上、.maintenance がサーバーに残っていても、作られてから10分経てばメンテナンス画面は自動で解除されます。だから、更新ボタンを押した直後に出ているだけなら、何もせず10分待つのが最も安全で確実な対処です。慌ててファイルを消しに行く必要はありません。

10分以上経っても戻らないときに疑う4つ

逆に言うと、10分を大きく超えて戻らないなら、単に「消し忘れ」では説明がつきません。上のコードの条件から、可能性は次の4つに絞られます。ここを飛ばして闇雲にファイルを消すと、原因が残ったまま同じことが再発します。

1. 更新処理がまだ繰り返し走っていて、.maintenance が作り直され続けている。自動更新やバックアップ系の処理がタイムアウトと再実行を繰り返していると、時刻が更新され続けて10分ルールに到達しません。
2. キャッシュがメンテナンス画面を保存して配り続けている。キャッシュ系プラグイン、サーバーのコンテンツキャッシュ、CDN、ブラウザのいずれかです。WordPress本体はもう正常に戻っているのに、画面だけ古い、という状態です。
3. $upgrading の時刻が「未来」になっている。手動でメンテナンスモードにする目的で .maintenance を置く手法があり、この場合は10分ルールが働きません。誰か（あるいはプラグイン）が意図的に置いた可能性があります。
4. そもそもWordPressが出している画面ではない。②〜⑤の可能性です。/wp-admin に入れるなら、WordPress本体はメンテナンスモードではありません（メンテナンスモード中は管理画面も同じ503になります）。

2番目のキャッシュは本当によくあります。ファイルを触る前に、シークレットウィンドウで開き直す・キャッシュ系プラグインのキャッシュを削除するだけで直ることがあるので、先に試してください。リスクゼロで1分です。

対処：.maintenance を削除する手順

WordPress公式のよくあるエラー一覧にも、更新後にこのメッセージが出続ける場合は「maintenanceファイルが正しく削除されなかった」可能性があるとして、FTPで接続し、サイトのルートにある .maintenance を削除する手順が案内されています。

作業の前に必ずバックアップを取ってください。サーバーの自動バックアップがある契約なら、その保持期間と復元方法を先に確認します。無い場合は、少なくとも .maintenance ファイル自体をダウンロードしてから削除してください（削除ではなく _maintenance のようにリネームするほうが、より安全です）。

FTPソフトが手元になくても、主要なレンタルサーバーはブラウザから使えるファイル管理機能を用意しています。2026年9月時点の各社公式マニュアルでは次のとおりです（画面名は変わることがあります）。

• エックスサーバー：ファイルマネージャ。FTPのIDとパスワード、またはXserverアカウントの「ファイル管理」から入り、ファイルの作成・編集・削除・リネームができます。
• さくらのレンタルサーバ：ファイルマネージャー。サーバーコントロールパネルにログインして使います。1ファイル25MBまでのアップロード、125KBを超えるファイルは編集不可といった制限が明記されています。
• ロリポップ!：ロリポップ!FTP。ブラウザからフォルダ・ファイルの作成、編集、アップロード、削除、パーミッション変更ができます。

探す場所はWordPressをインストールしたフォルダの直下です。wp-config.php、wp-content、wp-admin が並んでいる階層が目印で、.maintenance はその同じ階層にあります。先頭がドットのファイルは「隠しファイル」として一覧に出ない設定になっていることがあるので、見当たらない場合は隠しファイルの表示設定を確認してください。

なお、wp-config.php と .htaccess は絶対に触らないでください。この2つはサイトの生死に直結します。削除してよいのは .maintenance だけです。

ファイルを消しても管理画面に入れない場合は、メンテナンスモードとは別の問題が重なっています。その切り分けはWordPress管理画面にログインできない｜原因8つと確認手順にリスクの低い順でまとめてあります。

②メンテナンスモード系プラグインがONのまま

ロゴ入りで作り込まれた「Coming Soon」「ただいまメンテナンス中」の画面が出ているなら、まずこれを疑ってください。WordPressの管理画面には普通に入れるのに、一般の訪問者にだけメンテナンス画面が出る、というのがこのタイプの特徴です（ログイン中の管理者には通常のサイトが見える設計になっているため）。

ありがちな経緯は決まっています。

• リニューアル公開前に制作会社がONにして、公開後に戻し忘れた
• テーマの入れ替え作業でONにして、そのまま引き継ぎが終わった
• プラグインの更新後に設定が再度有効になった

対処は、WordPress管理画面にログインし、プラグイン一覧で「maintenance」「coming soon」といった名前のものを探して設定をOFFにするだけです。いきなり削除せず、まず無効化で様子を見てください。削除すると設定ごと消えるため、公開前の状態に戻せなくなります。

このタイプで確認しておきたいのが返しているステータスコードです。プラグインによっては200を返す設定と503を返す設定が選べます。200のまま長く放置すると、Googleに「メンテナンス中です」という内容のページとして扱われかねません。この実害は後半で詳しく書きます。

③レンタルサーバー側のメンテナンス・障害

次の条件に当てはまるなら、自社サイトの問題ではなくサーバー会社側です。

• 同じサーバーに置いている別のサイトも同時におかしい
• 画面にサーバー会社の社名やロゴが入っている
• 自社では何も更新していないのに突然起きた
• サーバーの管理画面（サーバーパネル）にもログインできない、または動作が極端に遅い

この場合、触っていいものは何もありません。各社が公開している障害・メンテナンス情報のページを確認します（例：エックスサーバーの障害・メンテナンス情報）。計画メンテナンスなら事前にメールで告知が届いているはずなので、迷惑メールフォルダも含めて受信箱を検索してください。

ここで詰まりやすいのが、そもそも自社のサーバーがどこなのか分からないというケースです。前任者が辞めた、制作会社と連絡が取れない、という会社は珍しくありません。調べ方はホームページのドメインとサーバーの管理会社がわからない時の調べ方3手順にまとめています。あわせて、サイトがまるごと表示されない場合はドメイン更新忘れでサイトが消えた｜復旧の期限と3つの原因のほうが該当するかもしれません。こちらは期限があるので急ぎます。

④CDN・前段のサービスが返している

近年増えているのがこれです。CloudflareなどのCDNをサイトの前に置いている場合、サーバー（オリジン）は正常なのに、前段の設定だけでメンテナンス画面が出ることがあります。制作会社が「サーバーは問題ありません」と言うのに直らない、という状況はここを疑ってください。

Cloudflareを通っているかどうかは、レスポンスヘッダーで判別できます。Cloudflare公式ドキュメントのとおり、Cloudflare経由のレスポンスには cf-ray や cf-cache-status といった独自ヘッダーが付きます。先ほどの curl -I の出力にこれらが並んでいれば、前段にCloudflareがいます。

疑う順番は、CDNの管理画面にある「メンテナンスモード」「カスタムエラーページ」「Workers／ルール」の設定です。ここは触ると全ページの挙動が変わる場所なので、設定変更の前に現在の設定内容をスクリーンショットで残してください。戻せる状態を作ってから触る、が鉄則です。

⑤制作会社が置いた「工事中」ページ

最後に、意外と多いのが「そもそもWordPressに到達していない」パターンです。サーバーのルートに index.html が置かれていると、多くの環境では index.php（＝WordPressの入口）より先にそちらが表示されます。制作会社がリニューアル中の目隠しとして置いたものが、そのまま残っているわけです。

見分け方は簡単で、https://あなたのドメイン/wp-admin/ を直接開いてみることです。ログイン画面が普通に出るなら、WordPressは生きています。トップだけが別のファイルに乗っ取られている状態です。

同じことが .htaccess のリダイレクト設定でも起こります。ただし.htaccess は記述を1文字間違えるとサイト全体が500エラーになるファイルです。中身を編集する前に必ず元のファイルをダウンロードして保管し、戻せるようにしてから作業してください。自信がなければ、ここは触らずに専門家へ渡すほうが安上がりです。

このタイプはほぼ確実に200を返している点が厄介です。Googleから見れば「工事中と書かれた正常なページ」であり、次に説明する実害がそのまま当てはまります。

ホームページの引き取りや立て直しは、Mihataでも日常的にお引き受けしています。記事の途中で恐縮ですが、「誰も中身を触れなくなったサイト」をそのまま預かって整えるところから対応していますので、よろしければ制作サービスのページもご覧いただけたら嬉しいです。

SEOの実害：200で返し続けると何が起きるか

ここが、技術記事ではあまり触れられないのに、経営上はいちばん効いてくる部分です。

Google検索セントラルの公式ガイダンスは、サイトを一時的に止めるときの考え方をはっきり示しています。要点は3つです。

1. まずは「サイト全体を落とす」のではなく「機能を制限する」ことを検討する。たとえば購入機能だけ止めて、情報は見られるようにしておく。検索での立ち位置を守れるのはこちらです。
2. やむを得ず全体を止めるのは1〜2日程度の短期に限り、その間は503を返す。公式には、コンテンツの代わりに情報を載せたエラーページを503で返すよう書かれています。ただし503を返している間は、Googleはタイトル・説明文・構造化データを更新できませんという注意も併記されています。
3. それより長く止めるなら、503ではなく200を返すインデックス可能なプレースホルダーのトップページを用意する。短期と長期で正解が逆になる、という点がこのガイダンスの肝です。

加えて、HTTPステータスコードの扱いに関する公式ドキュメントには、5xxを返すとGoogleのクローラーは一時的にクロール速度を落とし、サーバーエラーを返し続けるURLはインデックスから削除されると明記されています。一方で200を返しながらエラー内容を表示していると、ソフト404として扱われうるとも書かれています。

実務上の結論はこうなります。

この観点で見ると、WordPress本体のメンテナンス画面は、503に Retry-After: 600 を添えて返すという、教科書どおりの正しい実装になっています。危ないのはむしろ、良かれと思って置かれた自作の「工事中」ページや、200設定のままのプラグインのほうです。「メンテナンス中です」という文言のページがインデックスされ、検索結果にそのまま出てしまった、という事故は実際に起こります。

復旧後、検索結果への出方が戻らないと感じたときの確認手順はホームページが検索に出ない｜公開後の原因切り分け6手順にまとめています。あわせてSearch Consoleでインデックス状況を見ておくと、被害の有無がはっきりします。

同じことを繰り返さないための4つ

今回の件が片付いたら、次の4つだけ決めておいてください。どれも費用はかかりません。

• 更新の前にバックアップを取る。メンテナンス画面のまま戻らない事故のほとんどは、更新の途中で止まったことが原因です。バックアップがあれば、最悪でも戻せます。
• 自動更新の範囲を把握しておく。WordPress公式ドキュメントによれば、自動バックグラウンド更新はWordPress 3.7で導入され、5.6以降の新規インストールではメジャー・マイナー両方の自動更新が既定で有効です。プラグインとテーマは既定では自動更新されず、重大な脆弱性への対応など特別な場合に限られます。「更新した覚えがないのに」の正体は、たいていこの自動更新です。
• 公開前の目隠しは、外す担当と期限をセットで決める。プラグインのメンテナンスモードも index.html も、置いた時点で「いつ・誰が外すか」を決めておかないと必ず残ります。
• サーバー・ドメイン・CDNの管理情報を1枚にまとめる。WordPressのIDだけ知っていても、サーバーに入れなければ打てる手は半分になります。CDNを使っているなら、それも含めて書いておきます。

ついでに、SSLの警告など他の「見た目でお客様に伝わってしまう不具合」も、この機会に点検しておくと安心です。「保護されていない通信」が出ている場合の直し方は「保護されていない通信」と表示される原因と直し方にまとめています。

まとめ：触る前に、出どころを決める

最後に、行動の順番だけ並べておきます。

1. 10分待つ。更新直後ならWordPressの仕様で自動的に解除されます（リスクゼロ）。
2. シークレットウィンドウで開き直す。キャッシュが原因のことがあります（リスクゼロ）。
3. /wp-admin/ に入れるか確認する。入れるならWordPress本体のメンテナンスモードではありません。
4. ステータスコードを見る。200なら工事中ページかプラグイン、503ならWordPress本体かサーバー・CDNです。
5. 出どころを1つに決めてから、そこだけ触る。バックアップを取り、削除ではなくリネームで戻せるようにする。
6. 復旧後、Search Consoleでインデックスへの影響を確認する。

Mihataでは、こうした「誰も触れなくなったホームページ」の原因特定と引き取りも行っています。サーバーの情報が手元に無い、制作会社と連絡が取れない、という状態からのご相談も多いので、今の状況をそのまま書いてお送りください。原因の切り分けだけのご依頼でも問題ございません。