はじめに
WordPressを使っていると、管理画面に更新通知が表示されます。
対象は主に、
- WordPress Core
- Theme
- Plugin
- Translation
です。
更新は面倒だから放置する。
反対に、通知が出た瞬間に何も確認せず全部更新する。
どちらも避けたい考え方です。
この章では、
WordPressを壊しにくい手順で更新する
ことを考えます。
バックアップそのものは第32章で扱いました。
なぜ更新するの？
ソフトウェアは公開後も改善されます。
更新には、
- セキュリティ修正
- Bug Fix
- 互換性改善
- 機能追加・改善
などが含まれます。
WordPress公式も、最新バージョンへ更新することを推奨しています。
ただし、
更新が必要
=
何も確認せず押すではありません。
更新前に確認する
基本Flowは、
何を更新する？
↓
変更内容を確認
↓
バックアップを確認
↓
現在のサイト状態を確認
↓
リスクが高ければステージングでテスト
↓
更新 / 本番反映
↓
動作確認です。
第32章で確認したバックアップが使える状態か見ておきます。
変更前の状態を知っておく
更新後に、
「なんか違う気がする」
では判断できません。
更新前に、
- トップページ
- メイン サービスページ
- 問い合わせフォーム
- モバイル表示
- 重要な機能
を簡単に確認します。
必要ならスクリーンショットを残します。
これだけでも、更新後の比較がしやすくなります。
WordPress・Plugin・Themeを更新する
WordPress Coreを更新する
WordPress Coreはダッシュボードの更新画面などから更新できます。
WordPressにはOne-click 更新があります。
自動更新もありますが、現在の設定やインストール時期によってCoreの自動更新範囲が異なる場合があります。
そのため、
「WordPressは必ず自動で全部最新版になる」
とは考えません。
自分のサイトの設定を確認します。
自動更新は便利。でも確認不要ではない
WordPressにはCoreだけでなくPluginやThemeにも自動更新の仕組みがあります。
自動更新は、更新忘れを減らせる便利な機能です。
一方、
- 重要なビジネスサイト
- 独自カスタマイズが多い
- 外部システム連携がある
- 更新で影響が出やすいPlugin
などでは、更新後の確認方法も考えておきます。
大切なのは、
全部自動か、
全部手動かの二択ではありません。
サイトの重要度と構成に合わせます。
Pluginを更新する
Plugin更新では、
- 何のPlugin？
- 今も使っている？
- 大きなバージョン変更？
- 互換性情報は？
- 変更履歴は？
などを確認します。
特に重要な機能を担当するPluginは、更新後にその機能をテストします。
たとえば問い合わせフォームPluginなら、
実際に送信して届くか
まで確認します。
Themeを更新する
Themeも更新対象です。
ここで注意したいのが、Themeファイルへ直接カスタマイズしている場合です。
親Themeを直接編集していると、Theme更新で変更が上書きされる可能性があります。
カスタマイズを行う場合は、子Themeなど適切な方法を使います。
大きな変更ではステージングも考える
大きな変更ではステージングを使う選択肢もある
通常の小さな更新なら、
バックアップを確認して本番環境で更新し、
すぐに動作確認する運用でも進められます。
一方、
- Major バージョン 更新
- Theme変更
- PHPバージョン変更
- 重要Pluginの入れ替え
- 大きなコード変更
- レイアウトの大改修
などでは、
ステージング 環境
を使う方法があります。
ステージング 環境とは？
ステージングは、
本番サイトとは別に、変更を試すための環境
です。
考え方は、
本番サイト
↓ コピー
ステージング
↓
更新 / テスト
↓
問題確認
↓
本番へ反映です。
利用者が見ている本番サイトへ直接大きな変更を加える前に、
問題が起きないか確認できます。
ステージングは毎回必須ではない
文字を一か所直すだけなのに、
毎回ステージングを作る必要はありません。
ステージングが特に役立つのは、
失敗したときの影響が大きい変更
です。
サイト規模や重要度、
変更内容によって使い分けます。
ホスティングによってステージング機能は違う
ステージングの提供方法はホスティングによって異なります。
2026年8月時点では、
XServerのWordPress専用サービスである、
XServer for WordPress
には本番とは別URLのステージング 環境を作成する機能があります。
一方、
「Xserverを使っていれば、どのサービス・Planでも同じステージング ボタンがある」
とは考えません。
このGuideでは、
利用中のホスティングにステージング機能があるか確認する
という一般原則として扱います。
ステージングから本番へ戻すときもバックアップする
ステージングで問題がなかったとしても、
本番反映は別の変更です。
ホスティングの同期機能や移行ツールを使う場合も、
- 何が上書きされる？
- データベースは？
- wp-contentは？
- 本番側で新しく増えたデータは？
を確認します。
予約・注文・問い合わせなど、
本番サイトで更新され続けるデータがあるサイトでは特に注意します。
ステージングがあるからバックアップ不要
ではありません。
一度に大きく変えすぎない
Pluginを10個更新。
Themeも更新。
PHPも変更。
コードも変更。
そしてサイトが壊れた。
これでは原因が分かりにくくなります。
小さな通常更新を必ず一件ずつ行う必要はありません。
ただし、リスクの高い変更を大量にまとめない方が切り分けやすくなります。
更新後に確認する
更新が完了したら、最低限確認します。
□ トップページ
□ 主要な固定ページ
□ モバイル表示
□ メニュー
□ 問い合わせフォーム
□ メイン CTA
□ ログイン
□ 重要機能
□ エラー表示がないキャッシュを利用している場合は、古い表示が残っていないかも確認します。
更新後に問題が出たら
問題が起きたとき、
焦ってさらに別のPluginを更新したり、設定を大量に変えたりしない方が原因を追いやすくなります。
まず、
何を更新した？
↓
いつ？
↓
どこが変？
↓
エラーは出ている？
↓
直前のバックアップは？を確認します。
必要なら第32章のバックアップ / 復元を使います。
原因の切り分けは第47章でも詳しく扱います。
WordPress Recovery Mode
PluginやThemeのPHP エラーなどによってサイトへ重大な問題が起きた場合、WordPressにはRecovery Modeという仕組みがあります。
状況によっては管理者へ復旧用の案内が送られ、問題の原因となったPluginやThemeを調査できる場合があります。
ただし、
「Recovery Modeがあるからバックアップ不要」
ではありません。
復旧手段の一つとして覚えておきます。
メンテナンスをRoutineにする
更新通知を何か月も放置して、ある日まとめて大量更新。
という状態を避けます。
小規模サイトなら、
- 更新通知
- サイト表示
- 問い合わせフォーム
- ホスティング会社からの通知
などを定期的に確認するRoutineを作ります。
セキュリティの継続管理は第42章。
Search / アクセス / コンテンツの改善は第46章。
ここでは、
ソフトウェアを健康な状態に保つ
ことへ集中します。
今回のポイント
- WordPressは公開後も更新が必要
- 更新前に変更内容とバックアップを確認する
- 更新前のサイト状態を簡単に記録する
- Core / Theme / Pluginそれぞれを確認する
- 自動更新は便利だが、確認不要という意味ではない
- 大きな変更を一度にまとめすぎない
- 更新後は実際のページと機能を確認する
- 問題時は追加変更を重ねず、直前の変更を切り分ける
- Recovery Modeも復旧手段の一つ
- ソフトウェア メンテナンスとサイト改善は分けて考える
- リスクの高い変更ではステージング 環境を使う選択肢がある
- ステージングは毎回必須ではなく、変更の影響度で使い分ける
- ホスティングによってステージング機能は異なる
- ステージングから本番へ反映するときもバックアップと上書き範囲を確認する
今回の視点
更新は、
「通知の数字をゼロにする作業」
ではありません。
変更前を知る
↓
戻れる状態を確認する
↓
変更する
↓
結果を見るという、
変更管理
です。
この考え方があると、更新だけでなく、ホームページ改善そのものも安全に進めやすくなります。
Part 7｜公開後に運用・計測・改善する