WordPress 7.1更新ガイド｜新機能と安全なアップデート手順

WordPress 7.1へ更新すると、スマートフォン向けの見た目を編集画面から調整しやすくなり、大きな画像のアップロードも軽くなります。しかし、新機能を早く使いたいという理由だけで本番サイトの［今すぐ更新］を押すと、テーマやプラグインの相性によって表示崩れ、フォーム停止、管理画面エラーが起きる可能性があります。問い合わせを受ける企業サイトでは、数時間の不具合でも機会損失につながります。

WordPress 7.1は2026年8月19日に公開されました。目立つ変更は、画面幅ごとのレスポンシブスタイル、ブラウザ側での画像圧縮・リサイズ、AVIF・HEIC対応、すべてのエディターでの管理バー、タブやプレイリストの新ブロックです。便利な一方、既存テーマが独自に持つスマホ設定や画像最適化プラグインと役割が重なる部分があります。

安全な更新では、バックアップを取るだけでは足りません。復元できることを確かめ、ステージング環境で表示・フォーム・計測・画像投稿を試し、本番更新後も同じ項目を確認します。この記事では、初心者でも担当者へ依頼内容を伝えられるよう、準備する情報、管理画面の操作、判断基準、不具合時の戻し方まで順番に説明します。

結論から言えば、更新を無期限に止めるのも、確認なしで即時更新するのも適切ではありません。サイトの重要度と変更内容に応じて検証範囲を決め、戻せる状態を作ってから更新します。保守担当がいない、独自テーマや古いプラグインが多い、購入・予約・問い合わせが売上に直結する場合は、制作会社へ事前検証を依頼してください。

WordPress 7.1で変わったこと

WordPress 7.1では、サイトエディターのレスポンシブ設定が強化されました。ブロックやグローバルスタイルについて、デスクトップ、タブレット、モバイルなど異なる画面幅での見た目を編集画面から調整できます。テーマが対応していれば、余白や文字サイズのためにカスタムCSSを書く場面を減らせます。

ただし、すべてのサイトで同じ設定項目が表示されるわけではありません。クラシックテーマ、独自テーマ、ページビルダーを使うサイトでは、テーマ側の機能が優先されたり、新しいコントロールを利用できなかったりします。更新後に新機能が見えなくても、故障とは限りません。テーマの対応状況を確認してください。

画像処理は、対応ブラウザで圧縮、リサイズ、サムネイル生成などをアップロード前に行う方式へ変わりました。サーバーのPHPメモリや実行時間へ負荷が集中しにくくなり、大きな写真でアップロードが止まる問題を減らせます。AVIFやiPhoneで使われるHEIC、HDRゲインマップにも対応範囲が広がっています。

メディア処理の改善は、画像最適化プラグインがすぐ不要になるという意味ではありません。既存画像の一括変換、CDN配信、遅延読み込み、画質設定などは別の役割です。同じ画像を複数回圧縮して画質を落とさないよう、WordPress本体、テーマ、プラグイン、CDNがそれぞれ何を処理しているか整理します。

編集面ではタブブロックやプレイリストブロック、エディター間で共通して表示される管理バー、インラインノートなどが追加・改善されています。社内で複数人が記事を作るサイトでは便利ですが、公開中ページへ新ブロックを使う前に、使用テーマでスマートフォン表示とキーボード操作を確認してください。

WordPress.org日本語：WordPress 7.1「メアリー・ルー」

更新を急ぐサイトと、先に検証するサイトを分ける

更新の優先度は、新機能への興味ではなく、セキュリティ、事業への影響、復旧のしやすさで決めます。WordPress本体のセキュリティ修正を含む場合は長期間放置できません。一方、決済や予約、会員機能、独自開発があるサイトでは、短い検証時間を確保したほうが結果的に安全です。

まずダッシュボードの［ツール］にある［サイトヘルス］を開き、PHPバージョン、HTTPS、バックグラウンド更新、重大な問題を確認します。次に［プラグイン］の一覧で、自動更新の状態、最終更新日、利用していないプラグインを見ます。何年も更新されていないものが主要機能を担っている場合は、7.1更新前に代替や改修を検討します。

問い合わせフォームやECカートは、サイトが表示されるだけでは正常と判断できません。テスト送信後に自動返信が届くか、管理者通知が届くか、管理画面へ保存されるか、GA4や広告の完了イベントが記録されるかまで確認します。個人情報を使わず、テストと分かる専用データを用意してください。

更新時間はアクセスの少ない時間帯を選びます。担当者、開始時刻、確認担当、問題が出た場合の戻し方、復旧判断の期限を決めます。更新した人だけが状況を知る体制では、問い合わせや売上が止まっても発見が遅れます。業務担当者にも確認項目と連絡先を共有しましょう。

更新前にバックアップとステージングを準備する

バックアップは、WordPressのファイルとデータベースの両方が必要です。画像やテーマだけ保存しても、投稿、設定、ユーザー、フォームデータは戻せません。サーバー会社の自動バックアップを使う場合は、対象、保存期間、復元方法、復元にかかる時間を管理画面またはサポートで確認します。

作業直前のバックアップ日時を記録し、可能なら別の場所にも保管します。バックアップファイルを取得しただけで安心せず、テスト環境へ復元できるか確かめてください。特にデータベースの文字コード、ドメイン置換、シリアライズデータ、アップロードフォルダの容量で失敗しやすいためです。

ステージング環境は、本番サイトの複製です。サーバーに複製機能があれば利用し、なければサブドメインやローカル環境を準備します。検索エンジンに登録されない設定、Basic認証などのアクセス制限、メールの誤送信防止を行います。本番の顧客へテストメールを送らないよう、送信先を固定してください。

複製後にWordPress 7.1へ更新し、テーマとプラグインも対応版へそろえます。一度に全部更新して問題が出た場合は原因が分かりにくいため、変更単位と時刻を記録します。WordPress本体、必須プラグイン、テーマ、補助プラグインの順序はサイトによって異なるので、制作時の仕様書や保守会社の指示を優先します。

ブラウザのキャッシュやCDNが古いファイルを返すことがあります。更新後の検証では、管理者ログイン中だけでなくシークレットウィンドウや別端末でも確認します。キャッシュ削除は影響範囲を把握してから行い、本番サイトの全ページを不用意に重くしないよう注意してください。

WordPress.org日本語：WordPressの更新 詳細な手順

ステージングで確認する具体的な操作

最初に管理画面へログインし、［ダッシュボード］の［更新］を開きます。WordPress 7.1と使用中のテーマ・プラグインの更新候補を記録します。更新前後でエラーが出ていないか、［ツール］の［サイトヘルス］とサーバーのPHPエラーログを確認します。画面が白くなる場合は、ログに表示されたファイル名から原因候補を絞ります。

公開側では、トップページ、サービスページ、記事一覧、記事詳細、問い合わせページをパソコンとスマートフォンで開きます。ヘッダー、メニュー、横幅、文字の重なり、画像、固定ボタン、フッターを確認します。レスポンシブ設定が増えたからといって、既存CSSが自動的に最適化されるわけではありません。

フォームは必須項目、エラー表示、確認画面、送信完了、自動返信、管理者通知を一通り試します。ファイル添付がある場合は許可形式と容量も確認します。迷惑メール対策、外部SMTP、CRM連携を利用しているなら、それぞれのログや保存先まで確認してください。

画像の検証では、JPEG、PNG、WebPに加えて、運用で使う場合はHEICやAVIFも投稿します。アップロード直後のプレビューだけでなく、投稿へ挿入し、公開側で原寸・サムネイル・スマートフォン表示を確認します。画質、向き、色、ファイルサイズ、代替テキストが意図どおりかを見ます。

計測はブラウザのデバッグ機能やGTMプレビューモードを使い、ページビュー、フォーム完了、購入など重要イベントを確認します。更新そのものがタグを消さなくても、テンプレートやブロックの出力が変わり、クリック条件が合わなくなる場合があります。公開後の数値低下を待たず、操作時点で発火を確かめます。

本番更新の手順と更新直後の確認

ステージングで問題がないことを確認したら、本番作業日時を決めます。直前に新しいバックアップを取得し、ECや予約サイトでは注文・予約の受付状況も確認します。メンテナンス表示を使う場合は、問い合わせ先や再開予定を表示し、検索エンジンへ恒久的な閉鎖と誤解される設定を避けます。

ダッシュボードの［更新］から実行する場合、ブラウザを閉じず完了表示まで待ちます。途中で再読み込みや戻る操作を繰り返しません。自動更新やサーバー管理機能を使う場合も、実行時刻と対象バージョンを記録します。更新後にデータベース更新を求められたら、バックアップがあることを再確認して案内に従います。

管理画面へ再ログインできるかを確認し、サイトヘルスとエラーログを見ます。その後、ステージングと同じチェックリストを本番で実行します。トップページだけ正常でも、固定ページのテンプレート、検索結果、404ページ、フォーム、決済が壊れている場合があります。売上や問い合わせに近い機能から優先してください。

確認は管理者だけでなく、ログアウト状態と一般ユーザー権限でも行います。キャッシュ、Cookie、権限によって表示が変わるためです。パソコンで問題がなくてもスマートフォンのメニューや固定CTAが重なることがあるので、実機で主要な導線を操作します。

更新完了の記録には、日時、更新前後のバージョン、作業者、バックアップ、確認結果、残課題を残します。不具合がなくても、翌日と一週間後にエラーログ、フォーム件数、購入数、GA4の主要イベントを確認します。日常の変動と更新影響を分けるため、更新前の基準値も保存しておきます。

不具合が出たときの戻し方と判断基準

不具合が出たら、何度も更新ボタンを押したり、原因不明のまま複数プラグインを停止したりしないでください。発生時刻、対象URL、操作、画面メッセージ、端末、ログイン状態を記録します。再現条件が分かれば、キャッシュだけの問題か、テーマ・プラグイン・PHPの問題かを切り分けやすくなります。

問い合わせや決済が停止している、管理画面へ入れない、個人情報が表示されるといった重大障害では、調査を続けるより復元を優先します。表示の一部がずれるだけで主要機能が動く場合は、影響範囲を限定し、修正と復元の所要時間を比較します。判断基準を作業前に決めておくと迷いません。

復元は、バックアップ元の手順に従いファイルとデータベースの整合を取ります。ファイルだけ古くしてデータベースを新しいまま残すと、別の不具合が起きる可能性があります。ECサイトでは復元時点以降の注文を失わないよう、メンテナンス開始時刻と新規データの退避方法を確認してください。

原因が特定できたら、ステージング環境で修正版を試します。テーマやプラグインの提供元へ問い合わせる際は、WordPress、PHP、問題の製品バージョン、エラーログ、再現手順を伝えます。管理者パスワードや秘密鍵をメールへ貼らず、必要なら期間限定の専用アカウントを発行します。

更新後の運用チェックリスト

更新直後だけでなく、翌営業日と一週間後にも確認します。問い合わせ件数、メール到達、購入・予約数、404エラー、PHPエラー、ページ速度を更新前と比較します。件数が少ないサイトでは一日の増減だけで判断せず、実際のテスト操作とログを優先してください。

新しいレスポンシブ機能を使う場合は、既存のCSSをすぐ削除しません。どの画面幅でどの設定が効くかをステージングで確認し、重複する指定を整理してから反映します。編集担当者向けに、変更してよい場所と制作会社へ相談する場所を画面付きで残すと、将来の崩れを防げます。

画像処理も運用ルールを更新します。推奨する元画像サイズ、許可形式、ファイル名、代替テキスト、画質確認、画像最適化プラグインの役割を決めます。iPhone写真を直接投稿できても、位置情報や個人情報が含まれないか、公開に適した色と向きかは人が確認します。

WordPress本体だけでなく、テーマとプラグインの更新を定期的に確認します。セキュリティ更新は優先しつつ、公開直後に全サイトへ一斉適用せず、重要度に応じた段階更新も検討します。WordPress表示速度の改善手順と合わせ、更新後の速度やキャッシュも継続して確認してください。

よくある質問