理由は 2 つに絞れる─年末年始に WordPress サイトが壊れたとき、まずやるべきこと
休暇明けに
「サイトが表示されない」
「動作がおかしい」
年末年始などの長期休暇期間はトラブルが起きても気がつきにくい時期です。
そのため、不具合に気づいた時点では、「いつ・なにが原因で起きたのか分からない」という状態になりがちです。
このような状況で WordPress サイトに不具合が発生した場合、原因は大きく次の 2 つに絞られます。
- 更新による不具合
- 不正アクセスや改ざん
このうち、休暇中・休暇明けに突然起きた不具合の多くは「自動更新」が原因です。更新トラブルはとくに長期休暇と相性が悪いのです。
まず確認：バックアップはありますか？
もちろん、直近のバックアップデータがあれば、それを復元（リストア）するのがもっとも確実で簡単な解決策です。また、今から解説する操作を行う前にサーバーの機能で「現状のバックアップ（壊れている今の状態）」をボタンひとつで取れるなら、念のため取っておきましょう。
「バックアップを取っていなかった」「バックアップ自体が古すぎて使えない」という状況でも諦める必要はありません。この記事では、バックアップがない絶望的な状況から、いかにしてサイトを正常な状態へ戻すか、その具体的な対処法を整理します。
【初動】何が更新されたかの証拠を揃える
WordPress で更新されるのは以下の 3 つです。
まずは「何が動いたのか」のアタリをつけます。
- WordPress 本体（コア）
- プラグイン
- テーマ
方法 1：メール通知を確認する
WordPress からの「更新完了メール」や「技術的な問題メール」を探してください。これがもっとも確実な証拠です。
キャプチャ画像
方法 2：WordPress.org の更新履歴を確認する
メールが見られない場合、公式の WordPress.org で本体や利用中の主要プラグインやテーマの最終更新日を確認します。休暇中に更新されていれば、それが不具合のトリガーの可能性が高いです。
管理画面にログインできる場合は 特定した後の「正しい処置」に進みます。
「 WordPress の自動更新に失敗しました～」だけが表示されている
これは更新処理が中断し、未完で表示が止まっています。 FTP やサービスのファイルマネージャーなどを使い下記を実行します。
WordPress 配下ルートの .maintenanceを削除wp-content/upgrade/に残った中途ファイルがあれば、念のために削除
これはあくまで表示を戻すための処置であり、原因修正ではありません。表示が戻ったら改めて更新を行い、再度失敗するなら、その時点で原因を特定します。途中まで進行してエラーが発生することから、ネットワークや容量不足、書き込み権限など環境側の問題の可能性が高くなります。
管理画面に入れない場合の「強制介入」
ログイン画面すら出ない場合は FTP やサーバーのファイルマネージャーなどでフォルダ名を変更し、機能を無効化します。
プラグインの停止
調査でプラグインの「犯人」に目星がついているのなら、その対象だけをリネームしてピンポイントで止めます。
例：Contact Form 7
/wp-content/plugins/contact-form-7
↓
/wp-content/plugins/contact-form-7_stop
※他の正常なプラグインを生かしたまま、最小限の影響で復旧できます。
プラグインの一括停止
何が原因か一切不明な場合は一度すべてを停止して原因を切り分けます。
/wp-content/plugins → /wp-content/plugins_off
これで直るなら原因は「いずれかのプラグイン」です。
テーマの停止
直らなければ次はテーマです。
ただし、テーマフォルダごとリネームすると表示が完全に消えてしまうため、「現在使っているテーマのフォルダ」だけをリネームして強制停止させます。
例：Twenty Twenty-Three
/wp-content/themes/twentytwentythree
↓
/wp-content/themes/twentytwentythree_stop
これにより、 WordPress は強制的に初期テーマ（Twenty Twenty-Four など）へ自動的に切り替えて表示を試みます。これでサイトが表示されるなら、原因は「使っていたテーマ」にあると特定できます。
特定した後の「正しい処置」
「何が更新されたか」によって、取るべき処置が正反対になります。
パターン 1：プラグインやテーマ「自体」の更新が原因
そのパーツの最新版にバグがある、もしくは該当サイトにおいて、致命的な相性問題がある状態です。最短の復旧方法は不具合がなかった「ひとつ前のバージョン」に戻すことです。（ダウングレード）
【詳細】公式サイトから旧バージョンのプラグインを入手する手順
WordPress.org のプラグインページから旧バージョンを取得します。
プラグインページの右サイドバーにある「詳細を表示（Advanced View）」リンクをクリックします。
移動したページの最下部に「以前のバージョン（PREVIOUS VERSIONS）」というセクションがあります。バージョンを選択してダウンロード： プルダウンメニューから、現在より一つ前のバージョン番号を選択し「ダウンロード」ボタンを押すと、古いバージョンの ZIP ファイルが入手できます。
キャプチャ画像
プロの視点：グラフで「犯行時刻」を特定する 「詳細を表示」ページにある「 1 日あたりのダウンロード数」のグラフを確認してください。急激なスパイク（突出した頭）があれば大規模なアップデートが配信された日です。サイトが壊れた日とこのスパイクが重なっていれば、そのプラグインが原因であることは間違いありません。
キャプチャ画像
復旧作業：上書きインストール
入手した ZIP ファイルを WordPress 管理画面の「プラグイン ＞ 新規追加 ＞ プラグインのアップロード」からアップロードします。
注意：絶対に現在のプラグインを削除してはいけません。
プラグインを削除すると、既存設定が削除される可能性が高いです。アップロードすると「現在のバージョンをアップロードしたものに置き換えますか？」と聞かれるので、そのまま上書き（移管）を実行してください。これで設定を保持したまま復旧できます。
テーマのアップデートが原因の場合
テーマは純正の Twenty シリーズなどが使われるケースは少なく、それぞれのベンダーなどで旧バージョンを探すことになると思います。旧バージョンの入手が簡単でなければ、暫定的な回避策として、修正版が出るまで一時的に別のテーマへ切り替えるなどの対処が必要でしょう。
ただし、テーマを切り替えるとウィジェットの設定がリセットされたり、見た目が大きく変わります。これはあくまで「サイトを表示させて管理画面を操作できるようにするため」の応急処置と割り切りが必要です。
パターン 2：WordPress 「本体」の更新が原因
本体のダウングレードはセキュリティ面などのリスクが高いため、「最新の本体を正解とし、まわりを合わせる」対応をとります。なかでも多いのが、 WordPress 本体（コア）が更新されたことで、レンタルサーバー側の PHP バージョンが要件を満たさなくなり、不具合が発生するケースです。
PHP < WordPress
この場合はサーバーのコントロールパネルなどで、新しい WordPress が求める PHP バージョン（推奨 8.x 以上など）に変更します。ただし、古いテーマやプラグインが逆に新しい PHP で動かなくなる可能性もあるため、そちらの更新が必要になる可能性もあります。
それ以外の場合は本体更新によって既存の環境（プラグインやテーマ）と「衝突（コンフリクト）」している可能性が高く、対処の技術的なハードルが上がります。専門家への相談を含め、「自力でプログラムを修正する」「代替品を探す」「作者の修正版を待つ」の 3 択から判断することになります。
「改ざん」の可能性
フォルダ名変更による「一括停止」をしても全く状況が改善しない、あるいはつぎのような状況の場合は更新トラブルではありません。
- 身に覚えのないファイルが増えている
- 海外へ転送される
- 動作が異常に緩慢
これ以上自力で操作すると、復旧に必要なログを消したり被害を広げたりする恐れがあります。速やかに専門家へ相談してください。
まとめ
年末年始に WordPress サイトが壊れた場合、「何が起きたのか分からない」という状態がもっとも対応を難しくします。
- なにがいつ更新されたのか
- 自動更新だったのか、手動だったのか
これらが事前に分かっていれば、原因切り分けは格段に楽になります。
長期休暇前には、下記を意識することで、結果的にトラブル対応の負担を減らします。
- 更新履歴を把握できる状態にしておく
- 更新の通知や記録が残る仕組みを用意しておく
再発防止のために意識しておきたいこと
今回のようなトラブルを体験したあとで、「そもそも WordPress の更新はどう扱うべきだったのか」と考える方も多いと思います。
自動更新は便利な一方で本体・テーマ・プラグインでは性質が異なります。
更新を安全に運用するための考え方については、以下の記事で整理しています。