一方で、公開中のサイトへ入れて表示が崩れたら困る。問い合わせや商品リンクが止まれば、新機能を早く触れたことより損失の方が大きくなります。

WordPress 7.1 Beta 1は、2026年7月15日に公開されました。最終版の予定日は8月19日です。

公式案内が最初に強調しているのは、新機能の便利さではありません。この版はテストと開発専用であり、本番サイトや重要なサイトへ入れないことです。

だから、今やるのは本番の更新ではありません。自分のサイトで影響が出そうな場所を先に選び、安全な場所で試す準備です。

AIやまらぼも、本番は現在のWordPress 7.0.2で維持します。7.1 Beta 1を本番へ入れた、あるいは動作確認が済んだとは扱いません。

今回見るのは、ベータ版の機能一覧ではなく、ひとりでWordPressを運営する人が8月の正式版までに何を確かめておくかです。

更新ボタンより先に、ベータ版という札を見る

ベータ版は、正式版を少し早く配ったものではありません。

開発途中の機能を実際の環境で試し、不具合や使いにくさを見つけるための版です。予定されている機能が変わることもあれば、テーマやプラグインとの組み合わせで問題が出ることもあります。

公開サイトで試すと、問題を見つける作業と、読者がいつも通り使える状態へ戻す作業が同時に発生します。原因がWordPress本体なのか、テーマなのか、プラグインなのかも切り分けにくくなります。

今回の公式案内には、WordPress Beta Tester、ZIPの直接ダウンロード、WP-CLI、WordPress Playgroundという四つの試し方が掲載されています。選択肢が複数あるのは、本番へ直接入れる必要がないということでもあります。

運営中のサイトで更新通知を見ても、7.1 Beta 1を入れる理由にはしません。まず、どの試験場を使うかを決めます。

最初の試験場は、捨てて戻せる場所

新機能を見るだけなら、WordPress Playgroundから始めるのが軽い方法です。

ブラウザー上の分離環境なので、公開サイトのデータベースやファイルを変更せずに7.1 Beta 1を開けます。画面を触り、管理画面の移動やエディターの変化を見る最初の確認には向いています。

ただし、まっさらなWordPressで動いたことと、自分のサイトで動くことは別です。

次の段階では、現在のテーマと必要なプラグインだけを入れた分離環境を用意します。記事、画像、メニュー、検索、404、問い合わせなど、普段の運営で止まると困る部分を少数の代表データで確認します。

本番の複製を使う場合も、ログイン制限とnoindexを確認し、メール、Cron、外部HTTP送信を止めます。テスト記事が配信されたり、問い合わせの試験メールが読者へ届いたりしないようにするためです。

試験環境は保存することより、問題が出たら作り直せることを優先します。戻し方を考えなくてよい場所ほど、ベータ版を落ち着いて試せます。

AIやまらぼで先に見る五つの入口

AIやまらぼで確認するなら、トップページだけを開いて終わりにはしません。

一つ目はテーマです。ヘッダー、記事一覧、記事本文、検索、404をPCと390px幅で開き、横にはみ出さないか、メニューや画像が消えていないかを見ます。

二つ目は記事編集です。既存記事を直接書き換えず、新しい下書きを作り、見出し、段落、箇条書き、HTML、画像を保存します。保存後にもう一度開き、意図しない変換がないかを確かめます。

三つ目は画像です。アイキャッチと本文画像をアップロードし、WebP、代替テキスト、添付タイトル、トリミング後の寸法を確認します。

四つ目は問い合わせです。フォームの表示、入力、送信結果、メール受信は別々に見ます。画面上で成功していても、メールが届くとは限りません。

五つ目は運用プラグインです。バックアップ、キャッシュ、AI下書きガード、旧URLの410、商品リンクを代表URLで確認します。

全部の旧記事を読み直す必要はありません。収益や問い合わせ、公開作業につながる入口から選ぶと、短い時間でも判断材料を残せます。

画像まわりの変更は、記事制作の手間に直結する

WordPress 7.1 Beta 1では、メディア処理の変更が大きく案内されています。

クライアント側の処理でHEIC、UltraHDR、AVIF、WebPなどの対応を広げ、通信が切れた場合の自動再試行や進捗表示を加える予定です。メディア編集をまとめる新しい画面、投稿へ添付した画像を見つけやすくする表示も含まれます。

これは、画像を多く使うAIやまらぼに関係します。ただし、対応形式が増えたからといって、公開用画像のルールをすぐ変える必要はありません。

現在は1200×800pxのWebP、内容を説明するファイル名、具体的な代替テキストという形で揃えています。新しいアップロード処理を試す場合も、この公開結果が崩れないかを見ます。

iPhoneのHEIC画像が入るかだけでなく、変換後の容量、縦横、色、メタデータ、サムネイルを確認します。新しい編集画面で切り抜いた後、元画像へ戻せるかも試験項目です。

便利な機能を探すより、いまの画像制作工程が短くなるか、確認作業が増えるかを測ります。

AI下書きは、HTML機能より公開権限を見る

公式発表では、HTMLブロックが編集可能な入れ子ブロックを扱う変更に触れ、AI生成コンテンツとの関係も説明しています。

AIが作ったHTMLをWordPress上で編集しやすくなるなら、下書き作業には役立つ可能性があります。

ただし、AI記事の安全性を決めるのは、HTMLブロックの便利さではありません。

AIやまらぼでは、自動投稿ユーザーに公開権限を与えず、APIから受け取った記事を必ず下書きへ固定します。出典、AIが担当した範囲、人間確認の状態が揃わなければ公開へ進めません。

7.1 Beta 1を試すときも、この境界が残るかを見ます。下書き保存、再編集、危険なHTMLの除去、重複投稿の拒否、緊急停止中の拒否が確認対象です。

新しいエディターで文章を直しやすくなっても、公開できる人まで増やしません。編集の便利さと公開権限は別の設定として扱います。

8月19日までに残すのは、更新予定ではなく確認表

WordPress 7.1の最終版は、2026年8月19日に予定されています。

予定日は変更される可能性がありますし、ベータ版の機能が同じ形で最終版へ入るとも限りません。公開直前には、公式発表と実際のリリース内容をもう一度確認します。

今から本番更新の日を決める必要はありません。先に、試験環境、代表ページ、必要プラグイン、画像、問い合わせ、戻し方を一枚へまとめます。

AIやまらぼでは、正式版が出た後もすぐ本番へ入れず、分離環境で現在のテーマと8プラグインを確認します。問題がなければ新しい完全バックアップを取り、一度に複数の大きな変更を重ねずに本番へ反映します。

• Beta 1は本番へ入れず、最初はPlaygroundまたは作り直せる環境で見る
• テーマ、記事編集、画像、問い合わせ、運用プラグインの代表動作を確認する
• 正式版公開時に公式情報を再確認し、バックアップ後に一つずつ変更する

ベータ版を早く入れることが準備ではありません。正式版が来たとき、何を見れば公開サイトを止めずに判断できるか。その確認表を先に作ることが、今できる準備です。

サイトは普通に表示されているし、記事も書ける。急ぎの作業があるから、更新は週末でいいか。そう思いたくなりますが、今回は早めに済ませた方がよさそうです。

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は早めに更新する。ただし、バックアップと確認は省かない。この順番で進めます。