WordPress更新後にサイトが完全にダウンした時の復旧手順
プラグインやテーマの更新後にサイト全体がダウンし「このサイトで重大なエラーが発生しました」と表示される場合、多くの原因は .htaccess に書き込まれた不適切な指示がサーバー設定と衝突していることにある。FTP / SFTP でサーバーに接続し .htaccess から問題の行を削除するかファイルを一旦削除したあと、WordPress 管理画面でパーマリンク設定を再保存すれば復旧できる。
更新後にサイトが完全にダウンする仕組み
一部のプラグインやテーマは、更新時にパフォーマンス向上や URL の取り回しを目的として .htaccess に独自のルールを自動挿入する。これがサーバーの許容範囲を超えると、Apache が起動時に設定ファイルを解釈できず「500 Internal Server Error」を返し、フロントエンドも管理画面もアクセス不能になる。
典型的なのが Option MultiViews のような指示を勝手に追記するケースだ。この機能は Apache のコンテントネゴシエーション（ファイル名の拡張子を自動補完してリクエストを解決する仕組み）を有効にするが、レンタルサーバーや共用ホスティングではセキュリティとルーティングの競合を防ぐために AllowOverride で無効化されていることが多い。許可されていない場所に書かれた Option MultiViews は「ここでは許可されていません」というサーバーエラーを引き起こし、サイト全体を落とす。
WordPress 本体の更新ではこのような追記はほぼ発生しない。問題が起きるのは、更新と同時に .htaccess を操作する一部のキャッシュ系プラグイン、セキュリティ系プラグイン、多言語プラグインだ。プラグイン開発者のテスト環境と本番サーバーの設定が異なるために発生する「動作確認済み」とされる更新でも、自分の環境では致命的になることがある。
.htaccess のエラーでアクセス不能になった時の復旧手順
FTP 接続と .htaccess の場所を確認する
まずは FTP クライアント（FileZilla など）や契約中のサーバーが提供するファイルマネージャでサーバーに接続する。WordPress をインストールしたディレクトリ（多くの場合は public_html か httpdocs）を開き、直下に .htaccess というファイルがあるかを確認する。ドットで始まるファイルはデフォルトで非表示になっている場合があるので、FTP クライアントの設定で隠しファイルを表示するように切り替える必要がある。
エラーログを確認して原因行を特定する（可能な場合）
サーバーのエラーログを見られれば原因の特定は早い。cPanel やコントロールパネルに「エラーログ」または「Error Log」という項目があるので、直近のエントリを確認する。今回のようなケースでは .htaccess: Option MultiViews not allowed here というエラーメッセージが記録されている。この行がログに残っていれば .htaccess 内の Option MultiViews を含む行やブロックを削除するだけで復旧する可能性が高い。
…
Option MultiViews
…
# END WordPress
…
…
# END WordPress
.htaccess を削除して WordPress に再生成させる方法
エラーログを確認できない場合や問題の行を特定できない場合は .htaccess を一旦削除してしまうのが手っ取り早い。削除する前に必ずファイルをダウンロードして手元にバックアップを取っておく。削除後、サイトが表示されるようになったら WordPress 管理画面の「設定」→「パーマリンク」を開き、何も変更せずに「変更を保存」ボタンを押す。これで WordPress が必要最小限の .htaccess を自動生成する。
パーマリンク設定を保存して再生成された .htaccess には WordPress の標準ルールだけが書かれているため、問題を引き起こしていた余計な指示は含まれない。この状態でサイトが正常動作していれば復旧成功だ。
原因となったプラグインの特定と対処
.htaccess を修正しても、問題のプラグインをそのままにしておくと再度更新が走ったときや設定変更時に同じことが起きる。更新直前にどのプラグインやテーマを更新したかを確認し、該当するものを一時的に無効化しておく。
管理画面に入れるなら「プラグイン」画面から該当プラグインを停止する。管理画面にも入れない場合は、FTP で /wp-content/plugins/ ディレクトリにアクセスし、該当プラグインのフォルダごと名前を変更する（例: plugin-name を plugin-name-disabled にする）。これでプラグインが強制的に無効化され、管理画面にアクセスできるようになる。
.htaccess を修正しても直らない場合の追加対応
ブラウザキャッシュとサーバーキャッシュをすべて削除する
.htaccess を修正してもまだエラー画面が表示される場合、キャッシュが古いエラー状態を保持している可能性がある。ブラウザのキャッシュを削除し、サーバー側で Varnish や OPcache などのキャッシュ機構が動いている場合はそれらもクリアする。コントロールパネルにキャッシュ管理機能があればそこから削除し、WordPress 用のキャッシュプラグインを導入しているなら FTP で /wp-content/cache/ ディレクトリの中身を手動で削除する。
全プラグインを強制無効化して標準テーマに切り替える
.htaccess の問題ではなく、更新されたプラグインやテーマのコードそのものが PHP の致命的エラーを起こしている可能性もある。FTP で /wp-content/plugins/ フォルダ全体を plugins-temp などにリネームし、使用中のテーマ（/wp-content/themes/テーマ名）もリネームする。WordPress はプラグインがなくても動作し、有効なテーマがない場合は標準テーマ（Twenty Twenty-Five など）に自動でフォールバックする。これで管理画面に入れれば、あとは問題のプラグインやテーマを一つずつ戻して原因を絞り込む。
サーバー会社に AllowOverride 設定を確認する
Option MultiViews のような指示がサーバー側でどう扱われるかは Apache の AllowOverride 設定で決まる。自前で httpd.conf やバーチャルホスト設定を編集できない共用サーバーでは、サーバー会社に「.htaccess に Option MultiViews を記述したところサイト全体が停止した。この指示を許可する設定に変更できるか」と問い合わせる手段もある。ただしセキュリティ上の理由で許可されないケースが大半なので、その場合はプラグインの設定を見直すか、代替プラグインを検討する必要がある。
更新による .htaccess 破損を防ぐための対策
更新前にかならずバックアップを取る習慣をつける
WordPress 本体、プラグイン、テーマのいずれを更新する場合でも、更新前にサイト全体とデータベースのバックアップを取ることは最も基本的で強力な防御策だ。.htaccess も設定ファイルの一つとしてバックアップ対象に含めておく。バックアップがあれば、今回のようにサイトが完全にダウンしても数分で元の状態に戻せる。
ステージング環境で事前に検証する
本番環境に直接更新を適用する前に、ステージング環境（本番と同一のサーバー設定を持つテストサイト）で動作確認を行うことで、.htaccess の競合や PHP エラーを事前に検出できる。多くの国内レンタルサーバーはコントロールパネルから簡単にステージングサイトを作成できる機能を提供している。少なくとも重要なプラグインのメジャーアップデートでは、このステップを踏むことで大規模なダウンを回避できる。
プラグインの変更履歴を確認し .htaccess 操作の有無を把握する
更新前にプラグインの変更履歴（Changelog）を確認する習慣も有効だ。特に「Improved .htaccess rules」「Added server-level optimizations」などの記述がある場合は要注意で、更新後に .htaccess が書き換わる可能性が高い。こうした更新は必ずバックアップを取ったうえで適用し、適用直後に .htaccess の内容を確認して想定外の追記がされていないかチェックする。
よくある質問
更新後に管理画面だけでなくフロントエンドも真っ白になるのはなぜか
.htaccess のエラーは PHP の処理に入る手前のサーバーレベルで発生するため、WordPress のエラーハンドリング機構が一切働かない。結果としてフロントエンドも管理画面も同じ「500 Internal Server Error」や真っ白な画面になり、WordPress のデバッグモードでもエラーメッセージが表示されないことが多い。
.htaccess を削除しても問題ないのか
WordPress のパーマリンク設定を保存すれば必要なルールは自動で再生成されるので、.htaccess の削除自体は安全だ。ただし独自に追加したリダイレクトルールや BASIC 認証設定などがある場合はバックアップから手動で戻す必要がある。
FTP でサーバーに接続できない場合はどうすればよいか
サーバー会社が提供するコントロールパネル（cPanel など）のファイルマネージャが使えるかを確認する。多くの場合ブラウザから直接ファイルを編集できる。それも使えない状況であればサーバー会社のサポートに連絡し「.htaccess の特定の行を削除してほしい」と依頼するのが最も早い復旧手段になる。
今回のエラーはプラグインの不具合なのか
厳密にはプラグインのコードに問題があるというより、プラグインが想定するサーバー環境と実際のサーバー設定の不一致によって発生する。プラグイン開発者が Option MultiViews が許可されている環境で開発し、許可されていない共用サーバーでエラーが出るケースが典型だ。したがって「不具合」というより環境依存の問題と呼ぶ方が実態に近い。
同じ問題を起こさないために .htaccess をロックできるか
ファイルのパーミッションを 444（読み取り専用）に設定すれば外部からの書き込みは防げるが、WordPress 本体やプラグインが正当な理由で .htaccess を更新する必要がある場合にエラーの原因となる。現実的な対策は、書き換えが発生する更新の前にバックアップを取り、更新後に diff を取って差分を確認する運用だ。
この記事のポイント
- .htaccess への不適切な追記が更新後のサイトダウンの直接原因になりやすい
- FTP で問題の行を削除するか .htaccess を一旦削除すれば即座に復旧できる
- 削除後は管理画面のパーマリンク設定で必要最小限の .htaccess を再生成する
- 原因プラグインを特定し無効化しないと再発するため忘れずに対処する
- 更新前のバックアップとステージング検証が最も確実な予防策になる
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている