WordPressのプラグインを更新したら画面が真っ白に!その原因と復旧手順を徹底解説

SOSブログ
この記事の監修者・著者

Web制作歴29年。Webプロデューサー、Webマーケター、Webディレクター、Webデザイナー、Webエンジニアなど、様々なポジションでWeb制作に携わってきました。

主宰するホームページ作成教室には全国から受講生が集まっています。

このたび、Webトラブル何でも相談窓口を開設しました。
Webサイトのトラブル解決をサポートします!

コナン先生(小南邦雄)をフォローする

はじめに

WordPressのプラグインを「更新」ボタン一つでアップデートした直後、画面が真っ白になり、管理画面にもアクセスできなくなる現象。これは通称「死の真っ白画面(White Screen of Death:WSOD)」と呼ばれ、多くのWebサイト管理者が恐れるトラブルの一つです。

「壊してしまったかもしれない」「データが消えたのではないか」とパニックになるお気持ちは痛いほどよく分かります。でも、安心してください。画面が白くなったとしても、WordPress内(データベース内)の記事や画像データは無事であることがほとんどです。

この記事では、Web制作歴29年の「コナン先生」が、なぜこのような現象が起きるのかという技術的な背景から、最新のトラブル事例、そして初心者が安全にサイトを復旧させるための具体的な手順までを、丁寧に解説します。

コナン
コナン

一人でトラブルに向き合うのは不安…これ以上触ると取り返しがつかなくなりそうで怖い…一緒にトラブルを解決してほしい!プロに任せたい!という方は、下記よりご連絡ください。
コナン先生のWebトラブル何でも相談窓口

なぜ「更新しただけ」で画面が真っ白になるのか?

エラーメッセージすら表示されず、ただ白い画面だけが表示されるこの現象には、主に3つの技術的な原因が隠れています。

PHPメモリリソースの枯渇(メモリ不足)

WordPressは、サーバー上の「PHP」というプログラムで動いています。ページを表示したり、プラグインを動かしたりする際、サーバーのメモリ(作業領域)を使用します。

通常時のメモリ消費量は30MB〜60MB程度ですが、プラグインの更新処理は、ファイルのダウンロード、解凍、書き換え、データベースの更新といった重い処理を一気に行うため、一時的にメモリ消費量が跳ね上がります。

特に、以下のプラグインを使用している場合、負荷が大きくなりがちです。

  • Elementor などのページビルダー系
  • WooCommerce などのECカート系
  • 多機能なセキュリティ系プラグイン

サーバー側で設定されているメモリ上限(例:128MBなど)を超えた瞬間、処理が強制終了され、結果としてHTMLが生成されず「真っ白な画面」が表示されます。

プラグインやテーマとの「競合(コンフリクト)」

WordPressは、本体(コア)、テーマ、プラグインという3つの要素が連携して動いています。

プラグインを更新した際、その新しいプログラムコードが、現在使っているテーマや、他のプラグインのコードと相性が悪く、お互いに干渉し合ってしまうことがあります。

例えば、「Aというプラグイン」が新しい命令を出しているのに、「Bというテーマ」がその命令を理解できず、処理が止まってしまうような状態です。これを「コンフリクト(競合)」と呼びます。

特に、長期間更新されていない古いテーマを使っている場合や、有料テーマのライセンスが切れている場合に発生しやすくなります。

更新プロセスの失敗(ファイル破損)

自動更新や手動更新の最中に、通信が途切れたりサーバーがタイムアウトしたりすると、新しいファイルが中途半端に保存されてしまうことがあります。

古いファイルと新しいファイルが混在する「不完全な状態」になると、WordPressはプログラムを正しく読み込めず、エラーを起こして停止します。

ケーススタディ:2025年12月「WordPress 6.9」大規模不具合の教訓

トラブルの原因をより深く理解するために、つい最近発生した大規模なトラブル事例をご紹介します。

発生時期と状況

2025年12月2日、WordPressのメジャーアップデート「バージョン6.9」が公開されました。この直後、世界中のサイトで「画面が真っ白になる」「サーバーのCPU負荷が異常に高まる」という報告が相次ぎました。

主な原因

調査の結果、人気テーマである「WoodMart」およびページビルダー「Elementor」と、WordPress 6.9の新しい機能(ブロックエディタ関連のAPI)との間で深刻な競合が発生していたことが判明しました。

具体的には、サイトを表示しようとするたびにプログラムが無限ループ(堂々巡り)に陥り、サーバーのCPUリソースを100%使い切ってしまっていたのです。

この事例からの学び

「有名なプラグインやテーマを使っているから大丈夫」とは限りません。むしろ、機能が豊富で複雑なプラグインほど、WordPress本体の大きな更新(メジャーアップデート)の影響を受けやすいというリスクがあります。

特にビジネスで利用しているサイトでは、「メジャーアップデート(例:6.8 → 6.9)が出ても、すぐに更新ボタンを押さない」という慎重さが求められます。

初心者でもできる!真っ白画面からの復旧手順

ここからは、実際にトラブルに遭遇してしまった方のために、復旧手順をステップ・バイ・ステップで解説します。

管理画面に入れない状態を想定し、最も確実な方法をご紹介します。

ステップ1:WordPressからの「救済メール」を確認する

WordPress 5.2以降には「リカバリーモード」という機能が搭載されています。致命的なエラーが発生すると、管理者として登録しているメールアドレス宛に、システムから自動的にメールが届きます。

  • メールを確認する
    件名は「サイトで技術的な問題が発生しています」となっていることが多いです 9。
  • リカバリーモードでログイン
    メール本文にあるリンクをクリックすると、エラーの原因となっているプラグインを一時的に停止した状態で管理画面にログインできます。
  • プラグインの停止
    ダッシュボードに「プラグイン〇〇がエラーの原因です」と表示されるので、そのプラグインを「無効化」または「削除」してください。

※メールが届かない場合や、メールのリンクが開けない場合は、次のステップに進んでください。

ステップ2:ファイルマネージャーでプラグインを強制停止する

管理画面に入れない場合、サーバーの「ファイルマネージャー」機能を使って、外側から強制的にプラグインを停止させます。これは非常に強力で確実な方法です。

準備

お使いのレンタルサーバー(ConoHa WING、エックスサーバー、ロリポップ!など)の管理画面(コントロールパネル)にログインしてください。

手順

  1. サーバーの管理画面(コントロールパネル)のメニューから「ファイルマネージャー」(または「ファイル管理」)を開きます。
  2. 以下の順番でフォルダをクリックして開いていきます。public_html(またはドメイン名のフォルダ) > wp-contentplugins
  3. plugins フォルダの中に、インストールされているプラグイン名のフォルダが並んでいます。
    • 直前に更新したプラグインが分かっている場合、そのフォルダを探します(例: elementor)。
    • そのフォルダ名を「名前変更(リネーム)」機能を使って変更します。
    • 変更例: elementorelementor_STOP
  4. この状態で自分のサイトにアクセスしてみてください。
    • サイトが表示された場合
      そのプラグインが原因でした。管理画面にログインできるようになっているはずです。
    • まだ真っ白な場合
      名前を元に戻し、別の怪しいプラグインで同じことを試します。
  5. 原因が特定できない場合:plugins フォルダ自体の名前を plugins_ALL_STOP などに変更すると、すべてのプラグインが一括で無効化されます。これでログインできれば、プラグインのいずれかが原因であることは確定です。その後、フォルダ名を戻し、一つずつプラグインを有効化して犯人を探します。

ステップ3:デバッグモードでエラーの原因を特定する

プラグインを停止しても直らない場合、何が起きているのか詳細なエラーメッセージを表示させる設定(デバッグモード)を行います。

  • ファイルマネージャーで、一番上の階層にある wp-config.php というファイルを探します。
  • 必ずこのファイルをコピーしてバックアップを取ってから、編集機能で開きます。
  • ファイル内の以下の記述を探してください。
    define( ‘WP_DEBUG’, false );
  • この部分を以下のように書き換えます。
    define( 'WP_DEBUG', true );
    define( 'WP_DEBUG_LOG', true );
    define( 'WP_DEBUG_DISPLAY', false );
  • これを保存すると、wp-content フォルダの中に debug.log というファイルが生成されます。このファイルを開くと、「どのファイルの何行目でエラーが起きているか」が英語で記録されています。

ステップ4:メモリ上限を緩和する

メモリ不足が疑われる場合、同じく wp-config.php に以下のコードを追記することで、メモリの上限を増やすことができます。

define( ‘WP_MEMORY_LIMIT’, ‘256M’ );

これを追記して保存し、サイトが表示されるか確認してください。

真っ白画面を解決する、もっと詳しい完全ガイドができました。よろしければ、こちらの記事もご覧ください。

プロに任せるという選択肢:「コナン先生」の相談窓口

「直し方は分かったけれど、一人で作業するのは不安」「これ以上触ると取り返しがつかなくなりそうで怖い」と感じた場合は、無理をせず専門家にご相談ください。

コナン先生のWebトラブル何でも相談窓口」では、状況に応じて選べる3つのプランをご用意しています。

  • 今すぐ解決!Webサイトの突発トラブル緊急対応
    「今すぐ直したい!」という緊急時に。365日24時間対応。Zoom等で画面を共有しながら、その場で診断・復旧を行います。
  • これでスッキリ!Webサイトの急性・慢性トラブル解消
    緊急ではないが、自分では直せないバグ修正や機能改善を依頼したい場合に。
  • これで改善!成果が出ない原因と解決策を伝授
    トラブル対応ではなく、サイトの表示速度改善やSEO対策など、サイト診断と改善提案レポートを作成します。

二度と真っ白にしないための「予防策」

無事に復旧できた後は、同じトラブルを繰り返さないための予防策を講じておきましょう。

テスト環境(ステージング)の活用

本番公開されているサイトで直接アップデートを行うのは、非常にリスクが高い行為です。

現在、エックスサーバーやConoHa WINGなどの主要なレンタルサーバーでは、無料で「ステージング環境(テストサイト)」を作成できる機能が提供されています。

  • 本番サイトをステージングにコピーする。
  • ステージング環境でプラグインやWordPressを更新する。
  • 表示崩れやエラーがないか確認する。
  • 問題なければ本番環境で更新する。この手順を踏むだけで、トラブルの99%は未然に防ぐことができます。

自動更新設定の見直し

便利に見える「自動更新」ですが、重要なビジネスサイトではリスクとなります。

  • マイナーアップデート(セキュリティ修正など)
    自動更新ONでも比較的安全です。
  • メジャーアップデート(機能追加)
    必ず手動で行うように設定しましょう。
  • 重要プラグイン(WooCommerce/Elementor)
    これらは他のプラグインとの依存関係が強いため、自動更新はOFFにし、バックアップを取った上で手動更新することを強く推奨します。

自動バックアップの導入

「All-in-One WP Migration」「UpdraftPlus」「WPvivid Backup Plugin」などのバックアッププラグインを導入し、定期的に、そして更新作業の前には必ず手動でバックアップを取る癖をつけましょう。バックアップさえあれば、どんなトラブルが起きても、ボタン一つで元の状態に戻すことができます。