WordPressの管理画面に、7.0.2の更新通知が出ている。
サイトは普通に表示されているし、記事も書ける。急ぎの作業があるから、更新は週末でいいか。そう思いたくなりますが、今回は早めに済ませた方がよさそうです。
WordPress.orgは2026年7月17日、WordPress 7.0.2を公開しました。Criticalが1件、Highが1件のセキュリティ問題を修正した更新です。影響を受けるサイトには、すぐに更新するよう案内しています。
今週のAI・サイト運営ニュースをまとめて確認したい人は、今週やることを4つに絞った記事から読んでも構いません。WordPress更新を最初に扱っている理由も、そこで整理しています。
ただし、急いでいるからといって、何も確認せず本番サイトの更新ボタンを押すのは危険です。
更新後に画面が真っ白になれば、記事も問い合わせフォームも止まります。セキュリティ更新は早く入れる。それと同時に、問題が起きたら元へ戻せるようにしておきます。
WordPress 7.0.2は早めに更新する
WordPress 7.0.2で修正されたのは、表示上の小さな不具合ではありません。
公式発表には、SQLインジェクションに関係する問題と、REST APIのbatch routeを悪用してリモートコード実行につながる問題が挙げられています。
攻撃の痕跡が見つかるまで、更新を待つ必要はありません。影響を受けるバージョンを使っているなら、公式の修正版へ移します。
7.0系を使っている場合は7.0.2です。6.9系には6.9.5、6.8系には6.8.6が公開されています。今回の二つの問題については、6.8より前のバージョンは影響を受けないと発表されています。
この発表だけを見て、6.7以前なら更新しなくてよいと判断しないでください。今回の二つの問題に該当しないことと、古いバージョンを安全に使い続けられることは別です。
深刻度を理由に、WordPress.orgは影響を受けるサイトで自動更新も有効にしました。自動更新を使っていても、管理画面を開いて現在のバージョンを確認してください。サーバーの設定や通信状況によっては、更新が終わっていないことがあります。
更新する前に、戻し方を確認
バックアップがあるかどうかだけでなく、何が入っているかを確認します。
データベースには記事本文や設定が入っています。画像、テーマ、プラグインなどのファイルは別です。データベースだけ戻しても、更新前と同じ状態にならないことがあります。
最低でも、データベースとWordPressのファイル一式を戻せるかを見ておきます。いつ取ったバックアップなのか、何日前まで残るのか、復元は自分で行うのか、サーバー会社へ依頼するのかも確認します。
問い合わせや注文を受けるサイトでは、復元によって更新後のデータが消える可能性もあります。どこまで巻き戻るのかが分からないまま、本番で復元操作を始めるのは避けたいところです。
更新前には、WordPress本体、PHP、使用中のテーマ、主要プラグインのバージョンを残します。管理画面のスクリーンショットでも構いません。不具合が起きたときに、更新前後で何が変わったのかを確認できます。
自動投稿、予約処理、バックアップなど、同じ時間に動く処理があるなら一時停止します。更新中に別の処理が動くと、エラーの原因を探しにくくなります。
ステージングでは、記事・検索・フォームまで確認する
本番に近いステージングがあるなら、先に7.0.2を適用します。
トップページが表示されたら終わり、ではありません。
普段読まれている記事を開く。カテゴリー、検索、404ページを見る。管理画面で既存記事を開き、新しい下書きを保存する。画像も1枚アップロードします。
REST APIやApplication Passwordを使っている場合は、APIから下書きを1件作ります。今回の更新にはREST APIに関係する修正が含まれています。管理画面が動いていても、REST APIまで動くとは限らないため、別に試します。
問い合わせフォームは、送信完了の表示だけでなく、実際にメールが届くところまで確認します。商品やサービスを紹介している記事では、外部リンクが正しいページへ進むかも見ておきます。
PHPのエラーログと、ブラウザの開発者ツールに出るエラーも確認します。ページは表示されていても、同じ警告が何度も出ていることがあります。
問題が見つかったら、テーマ、プラグイン、PHPのどこで起きているかを切り分けます。7.0.2の適用を諦めるのではなく、修正版を使える組み合わせを探します。
本番環境では、WordPress本体とほかの更新を分ける
ステージングで問題がなくても、本番にはキャッシュや外部サービスとの連携があります。
アクセスが比較的少ない時間を選び、バックアップの時刻をもう一度確認します。ひとりで作業するなら、復元手順を別の画面で開いておくと、エラーが出たときに探し直さずに済みます。
WordPress本体を更新するのと同時に、テーマ、すべてのプラグイン、PHPまで変えると、問題が起きたときに原因を絞れません。
7.0.2を使うためにテーマやプラグインの更新も必要な場合は、ステージングで確認した組み合わせと順番に合わせます。それ以外の変更は、別の作業に分けます。
更新が終わったら、管理画面でWordPressのバージョンを確認します。そのあと、ログアウトしたブラウザでトップページと代表的な記事を開きます。ログイン中だけ正常に見えていないか、古いキャッシュが表示されていないかを分けて確認するためです。
投稿の保存、サイト内検索、問い合わせ、REST APIも試します。問題が出たら、そのまま別の更新を重ねず、いったん原因を確認します。サイトが表示されない、投稿を保存できないなど、事前に決めた問題が出たらバックアップから戻します。
更新後30分はエラーを監視する
更新直後にページが表示されても、少し時間を置いてもう一度確認します。
予約投稿、Cron、キャッシュの再生成、バックアップ、外部APIは、更新ボタンを押した瞬間に全部動くわけではありません。
最初の30分は、主要ページとエラーログを見ます。500エラーや404が急に増えていないか、画像やCSSが読み込めているかを確認します。
問い合わせフォームから実際に1通送ります。広告やアフィリエイトを使っているなら、表示が崩れていないか、代表的なリンクが開くかも見ておきます。
問題がなければ、更新した時刻、更新前後のバージョン、確認したページを記録します。不具合が後から見つかったときに、いつまでは動いていたのかを確認しやすくなります。
自動更新だった場合も、通知メールを読んで終わりにはしません。更新後に確認するページと機能を決めておけば、毎回同じ項目を短時間で確認できます。
更新内容と確認結果をメモに残す
今回使った手順は、簡単なメモにして残します。
バックアップを確認する場所。ステージングのURL。更新後に開く記事。フォームの送信先。REST APIのテスト方法。復元が必要になったときの連絡先や操作方法。
これだけ分かれば、次のセキュリティ更新で最初から調べ直さずに済みます。
使っていないテーマやプラグインも、別の日に確認します。サーバーへ置いたままなら、更新や脆弱性の確認が必要です。削除する場合は、データやほかの機能が依存していないかを調べ、バックアップを取ってから行います。
サイトを止めないための作業は、記事を書くほど目立ちません。でも、問い合わせや広告収益は、サイトが表示されて初めて発生します。
WordPress 7.0.2は早めに更新する。ただし、バックアップと確認は省かない。この順番で進めます。
更新前と更新後にやること
- 影響を受けるWordPressを使っているなら、対応する修正版へ早めに更新する。
- 更新前に、データベースとファイルのバックアップ、復元方法を確認する。
- ステージングと本番で、記事、検索、404、投稿保存、フォーム、REST APIを試す。
更新後は主要ページとログを30分ほど確認し、作業日時と結果をメモしておきます。