「危険な脆弱性が公表されたので、WordPressを急いで最新版にアップデートした——ところが今度は、【外観→ウィジェット】の編集画面が真っ白になって何も操作できない……」

しかも投稿等ウィジェット以外の編集画面はいつもどおり動くので、「サイト全体が壊れたわけではなさそう」とは思うものの、何から手をつければいいのか分からない。
Webサイトの運用をご担当されている方なら、ひやりとする場面ではないでしょうか。

こんな症状、出ていませんか?

弊社が今回この症状に遭遇したのも、まさにその流れでした。きっかけは、非常に危険な脆弱性「wp2shell(CVE-2026-63030)」への緊急対策として、WordPress本体を6.9.4(危険なバージョン)から 7.0.2(安全なバージョン)へアップデートしたことです。
そもそも wp2shell とは何か、ご自身のサイトが危険なバージョンかどうか気になる方は、脆弱性 wp2shell(CVE-2026-63030)についてはこちらの記事【緊急】WordPressを使っている人は今すぐ確認して! 危険な脆弱性「wp2shell」(CVE-2026-63030)とは)で詳しく解説していますので、あわせてご確認ください。

つまり今回の“真っ白”は、脆弱性対策で急いで更新した方が、まさに次にぶつかりやすいトラブルでもあります。
そして実はこれ、WordPressのアップデート後にわりとよく起きるもので、多くの場合は専門的なファイル修正をしなくても、管理画面の操作だけで元に戻せます。

この記事では、実際に弊社で遭遇した事例(WordPress 6.9.4 → 7.0.2 へのアップデート)をもとに、なぜウィジェット画面ばかりが真っ白になるのかという仕組みと、自分で直せるところまでの手順を順番にご案内します。

まずは症状の確認です。次のような状態になっていれば、この記事のケースに当てはまります。

  • 管理画面の「外観 → ウィジェット」を開くと、画面が真っ白。あるいは読み込みのグルグルが回ったまま止まっている。
  • ブラウザの検証ツール(キーボードの F12 で開く画面)の「Console」タブに、赤い文字のエラーがいくつも並んでいる。
  • それなのに、投稿や固定ページの編集画面はふつうに使える

最後の一点がとても大事な手がかりです。
「サイト全部がダメ」ではなく「ウィジェット画面だけがダメ」。この偏りには、ちゃんとした理由があります。

まず知っておきたい「ブロックエディタ」の話

原因の話に入る前に、ひとつだけ前提をおさらいさせてください。

WordPress 5.0 から、投稿や固定ページの編集画面は「ブロックエディタ」(開発上の呼び名は Gutenberg)に変わりました。見出し・段落・画像などを“ブロック”という箱として積み上げていく、いまの編集画面です。

このブロックエディタは、ひとつの大きなプログラムではありません。
役割ごとに分かれたたくさんのJavaScript部品の集まりで、それらが互いに「あの部品がないと動けない」という依存関係でつながっています。土台の部品が読み込まれ、その上に次の部品が乗り、さらにその上に……という積み木のような構造です。

プラグインが追加するブロック
▲ のせる
ブロックの部品(見出し・画像・リストなど)
▲ のせる
データのやりとり・画面部品
▲ のせる
ブロックエディタ本体(土台)
wp-block-editor

土台の部品がひとつ読み込めないと、その上の部品はすべて動けなくなります。

なぜ“ウィジェット画面ばかり”真っ白になるの?

ここが、この記事でいちばんお伝えしたいところです。

ブロックエディタは、もともと投稿・固定ページを編集するために作られたものです。
ウィジェット画面(外観→ウィジェット)とカスタマイザー画面は、あとからその同じブロックエディタを“間借り”して載せているという成り立ちになっています。

投稿画面は“持ち家”。ウィジェット画面は“間借り”。
土台(ブロックエディタ本体)が少し揺れると、間借り側から先に傾きます。

持ち家は基礎から自分の建物として設計されているので、地面が少し動いてもすぐには倒れません。
いっぽう間借りの部屋は、他人の建物の上に後から乗っているだけ。建物側のわずかな揺れが、そのまま部屋に伝わります。

技術的にいえば、ウィジェット画面やカスタマイザーは依存するJavaScriptの“つながり”が長いということです。
アップデートで部品の読み込み順や登録状態がほんの少し狂うだけで、つながりの先にあるウィジェット画面が真っ先に影響を受け、画面が描かれないまま真っ白になります。

投稿・固定
ページ編集
=持ち家
✓ しっかり建っている
ウィジェット/
カスタマイザー
=間借り
揺れると先に傾く
土台 = ブロックエディタ本体
アップデートで読み込みが少し狂うと、ここが揺れる

真っ白になる“引き金”は主に2つ

では、土台を揺らす引き金は何でしょうか。
実務上は、次の2パターンに分けて考えると切り分けがぐっと楽になります。

パターン 中身 直し方の重さ
① 一時的な状態のズレ アップデート直後に、プラグインの登録情報やキャッシュが古いまま残っている 軽い(再有効化で直る)
② プラグインの非互換 プラグインが新しいバージョンに未対応で、部品が本当に壊れている (プラグインの更新が必要)

今回、弊社が遭遇したケースはでした。
WordPress本体のファイル自体は正常で、壊れていたのは“本体のファイル”ではなく“アップデート直後のプラグインの状態”だったのです。
ローカル環境と本番環境の両方で同じ症状が出ていたことも、環境固有の故障ではないという裏付けになりました。

【実践】ウィジェット画面が真っ白になったときの直し方

ここからは実際の手順です。上から順に進めていただければ、多くのケースは STEP5 までで解決します。

STEP1.まずバックアップを取る

プラグインの停止・有効化を伴う作業です。念のため、作業前にデータベースとファイルのバックアップを取得してください。ふだんバックアップを自動取得している場合は、最新の取得日時を確認しておけば十分です。

⚠️ 本番サイトで作業する場合は、アクセスの少ない時間帯を選び、可能であれば「メンテナンス中」の告知を出しておくと安心です。

STEP2.ブラウザのキャッシュを疑う

いちばん軽い確認から始めます。
古いJavaScriptがブラウザに残っているだけ、というケースが実際にあります。シークレットウィンドウ(プライベートウィンドウ)で管理画面にログインし直す、あるいは CtrlF5(Macは CommandShiftR)でスーパーリロードして、ウィジェット画面を開き直してみてください。これで直れば作業は終わりです。

STEP3.プラグインを“全部いったん停止”する

管理画面の「プラグイン」を開き、一覧のチェックボックスを全選択。上部の一括操作から「無効化」を選んで「適用」します。
ここで大切なのは、1つずつ止めるのではなく、まず全部止めきることです。犯人探しは後回しにして、「プラグインが原因かどうか」だけを先に確定させます。

⚠️ SiteGuard などログインURLを変更するプラグインをお使いの場合、停止すると通常のログインURL(/wp-login.php)に戻ることがあります。作業前に、再ログインの方法とURLを必ず控えておいてください。

STEP4.ウィジェット画面を開いて確認する

全停止した状態で「外観 → ウィジェット」を開きます。
ここで正常に表示されれば、原因はプラグイン側にあると判明します。
今回の事例もこの時点で正常表示に戻り、WordPress本体の故障ではないと切り分けができました。

STEP5.プラグインを“1つずつ”戻す

ここから元の状態に戻していきます。
ポイントは1つ有効化するたびに、ウィジェット画面を開いて確認すること。手間はかかりますが、真っ白に戻った瞬間に有効化したプラグインが“犯人”だと確実に分かります。
数が多い場合は、SEO・フォーム・セキュリティなどブロックエディタに関わりそうなものを先に戻すと、当たりが早くなります。

STEP6.全部戻しても正常なら、それで解決

「1つずつ戻していったのに、最後まで真っ白に戻らなかった」——今回はまさにこのパターンでした。
特定の“悪いプラグイン”がいたわけではなく、アップデート直後の一時的な状態のズレが原因だったためです。
全停止から全有効化を通ることで、各プラグインが新しいバージョンに合わせて登録し直され、ズレが解消されました。拍子抜けするような結末ですが、これがパターン①のいちばん多い直り方です。

補足.仕上げにパーマリンク設定を「保存」する

最後に「設定 → パーマリンク設定」を開き、何も変更せずに「変更を保存」を押します
これはURLのルールを内部で作り直す操作で、プラグインの停止・有効化のあとに残った設定のズレをきれいにしてくれます。押しても表示上のURLは変わりませんので、安心して実行してください。

全プラグインをいったん停止
ウィジェット画面を確認
直った = 原因はプラグイン側
1つずつ有効化して毎回確認
真っ白に戻った
そのプラグインが犯人
→ 最新版へ更新
最後まで正常
一時的な状態のズレ
→ これで解決(今回のケース)

それでも直らないときは

1つずつ戻していく途中で、特定のプラグインを有効化した瞬間に必ず真っ白になる——これは先の表の②、プラグインが新しいWordPressに未対応というケースです。

対処はシンプルで、そのプラグインを最新版に更新すること。
WordPress本体の更新から少し遅れて対応版が公開されることが多く、それを当てるだけで解決するケースがほとんどです。

更新しても直らない、あるいは開発が止まっていて対応版が出ていない場合は、代替プラグインへの乗り換えや部分的な調整が必要になります。

【予防】こうすればトラブルを減らせる

今回のように危険な脆弱性が公表されると、多くの方が急いでアップデートされます。
だからこそ、慌てて更新ボタンを押す前に、次の点を押さえておくと安心です。(なぜ今アップデートが必要なのか — wp2shell 脆弱性の詳細はこちら

  • メジャーアップデートは、できればいきなり本番でやらない。まず検証環境(ステージング)で試し、問題がないことを確認してから本番に反映します。
  • プラグインを先に最新化してから、本体を上げる。順番を守るだけで、非互換に当たる確率がぐっと下がります。
  • アップデート後は投稿画面だけで安心しない。ウィジェット画面とカスタマイザー画面も必ず開いて確認します。“間借り”側は投稿画面より先に壊れるためです。
  • バックアップの取得状況を、平常時に確認しておく。いざというときに「戻せる」と分かっていれば、落ち着いて切り分けができます。
⚠️ ただし wp2shell のように緊急性の高い脆弱性は、更新の遅れがそのまま乗っ取りリスクになります。「検証環境がないから更新しない」ではなく、更新したうえで、直後に各画面を確認する——これが現実的な進め方です。

まとめ

ウィジェット画面が真っ白になるトラブルは、WordPress運用の“あるある”です。原因不明の故障のように見えて、実はブロックエディタを間借りしている構造ゆえに起きやすいという、はっきりした理屈があります。

そして多くの場合は一時的な状態のズレなので、全プラグインの停止 → 再有効化という管理画面の操作だけで元に戻ります。特定のプラグインが原因のときも、1つずつ戻していけば必ず見つかります。

そして、wp2shell のような脆弱性への対策として、アップデートそのものは欠かせません。
更新をためらうのではなく、「更新したら各画面を確認し、真っ白になっても落ち着いて対処する」——これが、セキュリティとサイト運用を両立させるコツです。

仕組みがわかれば、“なんとなく怖い”トラブルも、順番に確かめていける作業に変わります。今回の切り分けの考え方は、ウィジェット画面以外の不調にもそのまま応用できますので、ぜひ手順ごと覚えておいてください。