サイトを一時停止するとSEOに影響する？ php2shell対応で止めるときの正しい方法（503とRetry-After）｜Googleの助言

PHP本体の重大な脆弱性（通称「php2shell」）を直した修正版が、2026年10月21日に公開されました［php.net］。脆弱性の中身は「php2shellとは」で解説しています。修正版を入れるまでの間、21日の午後から22日にかけて、国内でも多くの会社がサイトやサービスを止めました。

サイトを止めると、気になるのが検索への影響です。「検索順位が下がるのでは」「Googleから消えるのでは」という心配に、Googleの担当者と公式ドキュメントが何と言っているかをまとめました。この記事では、Googleが書いていることだけを書き、Googleが書いていない影響の大きさは推測で書きません。

GoogleのMueller氏が投稿した内容

GoogleでSearch Advocate（検索についての情報発信の担当）を務めるJohn Mueller氏は、日本時間2026年10月22日 0:26（UTC 21日 15:26）に、Blueskyで次のように投稿しました。

If you're taking PHP sites down to schedule time to deal with "unplanned updates", use HTTP 503 instead of letting responses time out / 404 / 500. You can do this outside of PHP / point DNS elsewhere / CDN.

日本語にすると、次のような内容です（編集部訳）。

「予定外の更新」に対応する時間をつくるためにPHPのサイトを止めるなら、応答をタイムアウトさせたり、404や500を返したりせず、HTTP 503を使ってください。これはPHPの外でできます。DNSの向け先をほかに変える、CDNを使う、といった方法です。

投稿には、Googleの2本の資料へのリンクが付いています。2011年のブログ記事「How to deal with planned site downtime」と、ドキュメント「ウェブサイトを一時停止または無効化する」です。この投稿は、米国のSEO情報サイトSearch Engine Roundtableも取り上げています［Search Engine Roundtable］。

「PHPの外で」という点が大事です。今回の脆弱性はPHP本体にあるので、メンテナンス画面をPHPで出すと、止めたつもりでもPHPは動き続けます。503は、PHPより手前のWebサーバーやCDNで返すのが安全です。

Googleの公式ドキュメントに書かれていること

Google検索セントラルのドキュメント「ウェブサイトを一時停止または無効化する」は、主にネットショップの一時休業を想定した資料です。サイト全体を止めることは「推奨されない方法」としたうえで、どうしても止める場合の選択肢を挙げています。

サイトを 1～2 日間緊急に無効にする必要がある場合は、コンテンツの代わりに 503 HTTP レスポンス ステータス コードを含む情報エラーページを返します。

同じドキュメントは、サイト全体の無効化を「非常に短い期間（長くても 2～3 日）のみに適用できる最終手段」と書いています（英語版は「a few days at most」）。それより長く止める場合は、200（正常）を返すホームページを置いて、検索で見つけられるようにする方法を案内しています。

503を返すときの注意として、ドキュメントは次の点を挙げています。

• robots.txtのクロールは許可したままにする。robots.txtに503を返すと、すべてのクロールがブロックされる
• Retry-After（再開の目安を伝えるHTTPヘッダー）で、再開の日時か期間を、分かる範囲で指定する
• 503のページは静的HTMLにし、CSSや画像は外部ファイルにせず、ページの中に埋め込む
• ページには、詳しい情報へのリンク、再開の予定日、問い合わせ先を書く
• curlなどで、実際に503が返っているかを確かめる

また、503を返している間は、Googleはページのタイトルや説明、構造化データを更新できないとも書いています。

クロール頻度について説明したドキュメント「Google のクロール頻度を下げる」も、503を数時間から1〜2日返す使い方を説明しています。そのうえで、次のように注意しています。

対象期間が長い（1 ～ 2 日では済まない）場合は、この方法はおすすめしません。（中略）Googlebot が同じ URL で上記ステータス コードを数日にわたり検出すると、その URL が Google のインデックスから削除される場合があります。

なぜ503なのか（404・500・タイムアウトとの違い）

HTTPステータスコードは、サーバーがページを返すときに付ける3桁の番号です。ブラウザで見ている人には同じ「表示されない」状態でも、Googleのクローラー（サイトを巡回するプログラム）は、この番号で扱いを変えます。

500や502も「一時的なエラー」の仲間ですが、Googleが止めるときに案内しているのは503です。Mueller氏の投稿も、500ではなく503を使うよう書いています。

タイムアウトは、サーバーが応答しないまま時間切れになる状態です。サーバーの電源を落とす、ファイアウォールで全部遮断する、といった止め方をするとこうなります。Googleのドキュメントは、届かないURLは「数日以内に」インデックスから削除されるとしています。

「メンテナンス中」とだけ書いたページを200で返すのもよくある失敗です。ページそのものが「メンテナンス中」という中身に置き換わったと受け取られるおそれがあるため、止めている間も503を返します。

PHPを使わずに503を返す方法

ここからは、503を返す具体的な方法です。どの方法でも、終わったら次のコマンドで確かめます。1行目に「503」が出ていれば、503が返っています。

curl -I https://www.example.com/
# HTTP/1.1 503 Service Unavailable
# Retry-After: 3600

ブラウザでメンテナンス画面が見えても、番号が200のことがあります。見た目では判断できないので、必ずcurlなどで番号を確かめてください。

1. レンタルサーバーのメンテナンス機能を使う

レンタルサーバーによっては、管理画面にメンテナンス表示の機能があります。使う前に、その機能が503を返すかどうかをマニュアルで確かめ、設定したあとにcurlで確かめます。WordPressのメンテナンス用プラグインはPHPで動くので、今回の目的には合いません。

2. Apacheの.htaccessで503を返す

Apache（またはApache互換のWebサーバー）で、.htaccessが使えるサーバー向けの例です。PHPのファイルを読み込む前に、Webサーバーが503を返します。公開フォルダの.htaccessの、既存の記述（WordPressの設定など）より上に追加します。

# ---- メンテナンス中だけ有効にする（再開したら削除） ----
ErrorDocument 503 /maintenance.html
<IfModule mod_headers.c>
Header always set Retry-After "3600"
</IfModule>
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/maintenance\.html$
RewriteCond %{REQUEST_URI} !^/robots\.txt$
RewriteRule ^ - [R=503,L]
# ---- ここまで ----

• R=503：Apacheの公式ドキュメントでは、Rフラグに300番台以外の番号を指定すると、書き換え先は使われず、その番号を返して処理が止まります。
• Header always set Retry-After：エラーのときにもヘッダーを付けるため、「always」を付けます。「3600」は秒数（1時間）です。「Thu, 22 Oct 2026 03:00:00 GMT」のように、再開予定の日時をUTCで書くこともできます。
• maintenance.html：お知らせを書いた静的なHTMLを、同じフォルダに置きます。CSSや画像は外部ファイルにせず、ページの中に埋め込みます。
• robots.txt：503の対象から外しています。WordPressではrobots.txtをPHPが自動で作っていることがあるので、その場合は中身を書いたrobots.txtのファイルを置いてください。

サーバーによっては.htaccessで使えない設定があり、書き方を間違えるとサイト全体が500エラーになります。編集する前に元の.htaccessをコピーしておき、追加したらすぐにcurlで確かめてください。

3. nginxで503を返す

VPSや自社のサーバーでnginxを使っている場合の例です。メンテナンス用の静的ファイルを置くフォルダを作り、そこにmaintenance.htmlとrobots.txtを置きます。

server {
    listen 443 ssl;
    server_name www.example.com;
    # （証明書などの既存の設定はそのまま）

    root /var/www/maintenance;
    add_header Retry-After 3600 always;
    error_page 503 /maintenance.html;

    location = /maintenance.html { internal; }
    location = /robots.txt { }
    location / { return 503; }
}

nginxのreturnは、指定した番号を返して処理を止めます。PHP-FPMへ渡す設定（fastcgi_pass）を通らないので、PHPは動きません。設定を変えたらnginx -tで書き方を確かめてから再読み込みします。

4. Cloudflareで503を返す

サイトの前にCloudflareを置いている場合は、Cloudflare Workers（Cloudflare上で動く小さなプログラム）で、すべてのリクエストに503を返せます。

export default {
  async fetch(request) {
    const url = new URL(request.url);
    if (url.pathname === "/robots.txt") {
      return fetch(request); // robots.txt だけは元のサーバーから返す
    }
    const html = "<!doctype html><meta charset=utf-8><title>メンテナンス中</title>"
      + "<p>ただいまメンテナンス中です。再開は○時ごろの予定です。</p>";
    return new Response(html, {
      status: 503,
      headers: { "Content-Type": "text/html; charset=utf-8", "Retry-After": "3600" },
    });
  },
};

このWorkerを、サイトのホスト名のルートに割り当てます。注意点が2つあります。

• 無料プランのWorkersは、1日10万リクエストまでです。上限を超えたときに「Fail open」の設定だと、Workerを通らずに元のサーバーへリクエストが届きます。止める目的なら「Fail closed」にしておきます。
• WAF（不正な通信を止める機能）のカスタムルールの「ブロック」で独自の応答を返す機能は、番号を400番台から選ぶ仕様です。503は返せないので、Workersを使います。

上の例では、robots.txtだけ元のサーバーに取りに行きます。元のサーバーでrobots.txtをPHPが作っている場合は、Workerの中でrobots.txtの中身を直接返してください。

5. DNSの向け先を変える

Mueller氏が挙げた「DNSの向け先をほかに変える」方法は、503を返すように設定した別のサーバーへ、ドメインの向け先を切り替えるやり方です。PHPが動いているサーバーには、アクセスが届かなくなります。

ただし、DNSの変更は反映に時間がかかり、元に戻すときも同じです。メール（MXレコード）の設定を巻き込むと、メールが届かなくなることもあります。DNSの設定に慣れていない場合は、ほかの方法を選ぶほうが安全です。また、静的なファイルを置くだけのホスティングに向けると、メンテナンス画面が200で返ることが多いので、503を返せるかを先に確かめてください。

サーバー会社に止められたとき

今回は、サーバー会社が利用者のサイトをまとめて止めたケースもあります。どの会社が止めたかと、表示されないときの見分け方は「サイトが表示されない・502エラーが出たときの確認と対処」にまとめています。

この場合、止めている間に502や403などのどの番号が返るかは、サーバー会社の作業しだいで、利用者には選べません。停止中に自分でDNSを書き換えたり、別のサーバーへ引っ越したりすると、再開後に手間が増えることがあります。止まっている間は、サーバー会社の告知を待ちます。各社の対応状況は「レンタルサーバー各社のPHP脆弱性対応状況」で追っています。

Googleのドキュメントには、Googleのシステムは一時的な問題から回復できるよう作られている、とも書かれています。再開したら、次の手順で状態を確かめます。

再開したあとにやること

1. 503の設定を外して、200に戻ったことを確かめる：自分で設定した.htaccessやnginx、Workersの設定を元に戻し、curlで主要なページが「200」を返すことを確かめます。robots.txtも開けるか確かめます。外し忘れると、503が何日も続くことになります。
2. Search Consoleの「URL 検査」で主要なページを調べる：トップページや問い合わせページなどのURLを入力し、インデックスに登録されているかを確かめます。必要なら［インデックス登録をリクエスト］を押します。リクエストできる数には1日あたりの上限があります。ページが多い場合は、サイトマップを送信します。
3. 「ページのインデックス登録」レポートを見る：「サーバーエラー（5xx）」などの理由で、登録されていないページが増えていないかを確かめます。
4. 「クロールの統計情報」を見る：［設定］の中にあるレポートです。「ホストのステータス」で、robots.txtの取得、DNSの解決、サーバー接続に問題が出ていないかを確かめます。Googleのヘルプは、ページ数が1,000未満のサイトならこのレポートを使う必要はないとしています。
5. しばらく様子を見る：検索からの訪問数と、上のレポートを何日か続けて見ます。

PHPの修正版が入ったかの確認や、乗っ取られていないかの確認も忘れずに行ってください。手順は「php2shell対策チェックリスト」にまとめています。

よくある質問

数時間〜1日止めただけで、検索順位は下がりますか？

Googleは、順位への影響の大きさを具体的には示していません。ドキュメントが案内しているのは、1〜2日の緊急停止なら503を返すこと、503でも数日続くとURLがインデックスから削除される場合があることです。2011年のブログ記事は、503などで計画的な停止を扱えば、検索結果での見え方に悪い影響は通常出ない、という趣旨で書かれています。ただし、クロールやインデックス、順位を保証するものではないとも書いています。

すでに404や500のまま止めてしまいました。どうすればいいですか？

まずはサイトを再開し、200を返す状態に戻します。そのうえで、Search Consoleの「URL 検査」で主要なページの登録状態を確かめ、必要ならインデックス登録をリクエストします。ページが多い場合はサイトマップを送信します。

robots.txtで「Disallow: /」にしてクロールを止めてもいいですか？

Googleのドキュメントは、勧めていません。有効なrobots.txtですべてのクロールを禁止すると、コンテンツや、場合によってはURLまでGoogle検索から削除される可能性があるとしています。

Search Consoleの削除ツールで、一時的に検索から消しておくのはどうですか？

ドキュメントは、サイトの停止に一時的ウェブサイト削除ツールを使わないよう書いています。利用者がサイトを見つけられず、状況を知ることもできなくなるためです。

WordPressのメンテナンスモードのプラグインでもいいですか？

プラグインによっては503を返しますが、PHPの上で動きます。今回のようにPHP本体の脆弱性が理由で止める場合は、PHPより手前のWebサーバーやCDNで503を返してください。

参考にした情報

• John Mueller氏のBluesky投稿（2026年10月22日 0:26 日本時間）
• Search Engine Roundtable「Google On Taking Sites Down When Fixing The Emergency PHP Exploit - PHP2Shell」（二次情報）
• Google 検索セントラル「ウェブサイトを一時停止または無効化する」
• Google「Google のクロール頻度を下げる」
• Google「HTTP ステータス コードが Google のクローラーに及ぼす影響」 / 「ネットワーク エラーと DNS エラーをデバッグする」
• Google Search Central Blog「How to deal with planned site downtime」（2011年1月）
• Search Console ヘルプ「URL 検査ツール」 / 「ページ インデックス登録レポート」 / 「クロールの統計情報レポート」
• Apache HTTP Server「RewriteRule Flags」 / 「mod_headers」 / nginx「ngx_http_rewrite_module（return）」
• Cloudflare Workers「Limits」 / Cloudflare WAF「Create a custom rule in the dashboard」
• php.net（PHP公式のセキュリティアドバイザリ）

あわせて読みたい

緊急情報2026.10.21

【10/22最新】PHP脆弱性「php2shell」とは？修正版公開・影響を受けるバージョンと今すぐやる対策（CVE-2026-109618/109619）

対策・手順2026.10.22

WordPressプラグインの脆弱性の調べ方｜使っているプラグインが危ないか確かめる方法と更新の運用

対策・手順2026.10.22

WAFとは？ Cloudflareの無料プランでWordPressを守る設定と限界｜php2shellで注目