WordPressの管理画面に更新通知が表示されると、ついそのまま「更新」を押したくなります。しかし、更新作業はWordPress本体、テーマ、プラグイン、データベースなど、サイトを動かす複数の要素に影響します。多くの場合は問題なく完了しますが、相性の問題や通信の中断、容量不足、独自カスタマイズなどが重なると、表示崩れやエラーが起きることがあります。
更新前のバックアップは、単にファイルを一つ作ることではありません。必要なデータがそろっているか、更新直前の状態か、別の場所に保存されているか、必要なときに復元できるかまで確認して、初めて安全網として機能します。「バックアップ完了」と表示されたことだけで安心せず、更新後に困らない条件を整えることが大切です。
この記事では、WordPress本体・テーマ・プラグインの更新前に確認したい項目を、初心者にも分かりやすい順番で解説します。自分で更新してよいケースと、制作会社や保守担当者へ依頼した方がよいケースも整理します。更新作業の前に一つずつ確認し、戻せる状態を作ってから進めましょう。
更新前のバックアップが必要な理由
WordPressの更新は、古いプログラムを新しいプログラムへ置き換える作業です。セキュリティ修正、不具合修正、新機能への対応など重要な意味があるため、更新を避け続けるのは適切ではありません。一方で、サイトごとに使っているテーマ、プラグイン、PHP、サーバー設定、独自コードが違うため、同じ更新でも結果が同じになるとは限りません。
公式ドキュメントでも、更新前にサイトをバックアップし、問題が起きた場合に復元できるようにする考え方が案内されています。特にデータベースは、投稿、固定ページ、設定、ユーザー情報、プラグインが保存する情報などを含む重要な領域です。ファイルだけ、またはデータベースだけでは、元の状態を完全に再現できない場合があります。
更新によって変わる可能性があるもの
WordPress本体の更新では、管理画面やサイトを動かすコアファイルが置き換わり、必要に応じてデータベースの更新も行われます。テーマ更新ではテーマのファイルが置き換わり、親テーマを直接編集している場合は変更内容が失われる可能性があります。プラグイン更新では、機能のプログラムやデータベース構造が変わることがあります。
更新後の不具合は、更新対象そのものだけが原因とは限りません。あるプラグインと別のプラグインの組み合わせ、テーマとの相性、PHPのバージョン、キャッシュ、サーバーのメモリや空き容量が関係することもあります。そのため、更新前には対象だけでなく、サイト全体の状態を戻せる準備が必要です。
バックアップがあっても戻せないことがある
バックアップファイルが存在していても、中身が不足している、途中で作成に失敗している、保存先へアクセスできない、復元方法が分からないといった状態では役に立ちません。自動バックアップの設定日が古く、更新直前の記事や問い合わせ情報が入っていないケースもあります。
また、バックアップを本番サーバー内だけに保存していると、サーバー障害や契約上の問題が起きたときに、サイトと一緒に失う可能性があります。更新前には「あるか」だけでなく、「新しいか」「完全か」「取り出せるか」「戻し方が分かるか」を確認することが重要です。
最初に確認したい更新対象と影響範囲
バックアップを始める前に、何を更新するのかを明確にします。WordPress本体、テーマ、プラグイン、PHP、データベース、サーバー設定では、影響範囲と戻し方が異なります。管理画面に表示された更新を一括で実行すると、問題が起きたときに原因を切り分けにくくなります。
更新対象の名称と現在のバージョンを記録する
更新予定のWordPress本体、テーマ、プラグインの名称と現在のバージョン、更新先のバージョンをメモします。管理画面の更新画面をスクリーンショットで残してもよいでしょう。独自に追加したコード、子テーマ、必須プラグイン、サーバー側のキャッシュ機能がある場合も記録します。
更新内容を記録しておくと、不具合発生時に「どの変更から起きたのか」を判断しやすくなります。制作会社やサーバー会社へ相談するときも、更新時刻、対象、表示されたエラー、実行した操作を伝えられるため、調査が進みやすくなります。
サイトの役割と停止できる時間を考える
個人ブログと、予約・問い合わせ・会員・注文を受け付ける事業サイトでは、更新失敗の影響が異なります。売上や顧客対応に直結するサイトでは、数分の停止でも連絡や注文の取りこぼしにつながる可能性があります。更新する時間帯、作業担当者、連絡先、問題が起きた場合に作業を中止する基準を決めておきます。
更新中も注文やフォーム送信が発生するサイトでは、バックアップ取得後に新しいデータが追加されます。古いバックアップへ戻すと、その間の注文や問い合わせが消えるおそれがあります。必要に応じてメンテナンス時間を設定し、利用者への案内や受付停止の方法を検討してください。
更新前にそろえるバックアップの中身
WordPressを元の状態へ戻すには、基本的にファイルとデータベースの両方が必要です。さらに、サーバー固有の設定や外部サービスの設定が関係するサイトでは、それらも別に記録しておくと復旧しやすくなります。
データベースをバックアップする
データベースには、投稿、固定ページ、コメント、ユーザー、サイトURL、各種設定、テーマ設定、プラグインが保存する情報などが入っています。EC、予約、会員、フォーム履歴を扱うサイトでは、注文や顧客に関係する情報も含まれることがあります。
データベースのバックアップでは、WordPressが使用するテーブルがすべて対象になっているかを確認します。複数のWordPressを一つのデータベースで管理している場合や、テーブル接頭辞を変更している場合は、対象を取り違えないようにします。ファイル名にサイト名と取得日時を入れ、どの環境のデータか分かるようにしておくと安全です。
アップロード画像を含むファイルをバックアップする
WordPressのファイルには、テーマ、プラグイン、アップロード画像、WordPress本体、設定ファイルなどがあります。特に画像やPDFなどのメディアは、通常データベースだけを戻しても実体が復元されません。データベースには添付情報が残っていても、画像ファイルがなければ表示できないためです。
最低でも、利用中のテーマ、子テーマ、プラグイン、uploadsフォルダ、wp-config.php、必要なサーバー設定ファイルを確認します。サイト全体のファイルを取得できる仕組みがあるなら、更新前の一式を保存する方が復元時の判断が簡単です。
独自カスタマイズと設定内容を別に残す
テーマのfunctions.phpやテンプレートファイルを直接編集している場合、テーマ更新で上書きされる可能性があります。子テーマを使っていても、独自コード、追加CSS、アクセス解析タグ、広告コード、リダイレクト、フォーム通知先などは、どこに設定したかを記録しておきます。
管理画面の設定はデータベースに保存されるものが多いものの、バックアップを開いただけでは内容を確認しにくいことがあります。重要な設定画面はスクリーンショットやテキストでも残すと、部分的な再設定が必要になったときに役立ちます。パスワードやAPIキーを記録する場合は、記事や共有フォルダへ平文で置かず、安全な管理方法を使ってください。
サーバー側の設定も確認する
PHPのバージョン、データベースのバージョン、メモリ上限、SSL、DNS、キャッシュ、WAF、Basic認証、定期実行などは、WordPressのバックアップだけでは戻せないことがあります。今回の作業でサーバー設定も変更するなら、変更前の値を記録し、戻し方を確認します。
レンタルサーバーの管理画面にバックアップ機能がある場合は、対象範囲、保存期間、復元単位、復元料金、反映までの時間を確認してください。「自動バックアップあり」と書かれていても、希望する日時を選べるとは限らず、データベースとファイルを別々に復元する仕様もあります。
バックアップの品質を確認するチェックポイント
更新前に重要なのは、バックアップの作成方法よりも、必要なときに使える状態かどうかです。次の観点で確認すると、見た目だけのバックアップを避けやすくなります。
取得日時が更新直前か
直近の投稿、画像、商品、注文、予約、問い合わせ、ユーザー情報が入っている時刻かを確認します。毎日自動で取得していても、更新直前までに重要な変更があった場合は、手動で追加取得する方が安全です。
バックアップ取得後にサイトが更新され続ける場合は、取得時刻と更新作業の開始時刻を記録します。問題発生後に復元する際、どの時間帯のデータが失われる可能性があるかを説明できる状態にします。
成功表示とファイルの実体が一致しているか
管理画面に成功と表示されても、保存先の容量不足、通信エラー、外部ストレージの認証切れなどで、実際のファイルが不足していることがあります。保存先を開き、ファイル名、更新日時、容量、分割ファイルの数を確認します。以前の正常なバックアップと比べて極端に小さい場合は、対象漏れや失敗を疑います。
圧縮ファイルの場合は、開けるか、一覧を表示できるかも確認します。バックアップツールのログに警告や除外項目がないかを見ます。完了メールだけで判断せず、保存先の実体まで確かめることが大切です。
ファイルとデータベースの時刻がそろっているか
ファイルとデータベースを別々に取得した場合、時間が大きくずれると整合性の問題が起きることがあります。特に注文、会員、予約などが継続的に変化するサイトでは、取得中にデータが更新される可能性があります。可能ならアクセスや受付が少ない時間を選び、取得開始と完了の時刻を残します。
バックアップサービスがファイルとデータベースを一つの復元ポイントとして扱うのか、それぞれ別の時刻で管理するのかも確認します。復元時に同じ時点を選べない仕様なら、どの組み合わせを使うか事前に考えておきましょう。
本番サーバーとは別の場所に保存されているか
同じサーバーの同じ契約領域だけに保存すると、サーバー障害、容量超過、誤削除、契約停止、侵害などの影響を一緒に受ける可能性があります。更新前の重要なバックアップは、外部ストレージや手元の安全な保存先にも複製します。
外部へ保存するときは、個人情報や認証情報が含まれる可能性を考え、アクセス権、共有範囲、暗号化、保存期間、削除方法を確認します。誰でも開ける共有リンクを作らず、作業に必要な担当者だけがアクセスできるようにします。
復元方法と必要な権限が分かるか
復元にレンタルサーバーの管理画面、FTPまたはSFTP、データベース管理画面、WordPress管理者権限などが必要になることがあります。障害が起きてからログイン情報を探すと、復旧が遅れます。使う可能性のある管理画面へログインできること、二段階認証を受け取れること、契約者情報が分かることを確認します。
バックアッププラグインだけに頼る場合、WordPressへログインできない障害では復元操作を始められないことがあります。サーバー側から戻せる方法があるか、プラグイン外でファイルを取得できるかを確認しておくと、選択肢が増えます。
更新前に残しておきたいサイトの現状
バックアップのほかに、正常な状態の記録を残しておくと、更新後の確認がしやすくなります。正常時の基準がないと、もともとあった表示差や警告を更新の影響と誤認することがあります。
主要ページと重要機能を記録する
トップページ、代表的な投稿、固定ページ、問い合わせフォーム、検索、ログイン、メニュー、スマートフォン表示などを確認します。ECや予約サイトでは、商品一覧、カート、決済直前までの動線、会員ページ、通知メールの条件も整理します。個人情報や実決済を使わずに確認できるテスト手順を用意してください。
表示状態はスクリーンショットで残し、確認したURLと日時をメモします。すべてのページを見る必要はありません。サイトの共通部分と、売上・問い合わせ・信用に影響する機能を優先します。
エラーと警告を更新前に確認する
更新前から管理画面に警告が出ている、フォームメールが届かない、特定ページが崩れている状態では、更新後の原因切り分けが難しくなります。既知の問題を一覧にし、今回の更新で解決を狙うのか、別作業として扱うのかを決めます。
サーバーやWordPressのログを利用できる場合は、更新前のエラーを確認します。ログにはIPアドレス、パス、メールアドレスなどが含まれる場合があるため、外部へ相談するときは必要部分だけを共有し、認証情報や個人情報を含めないようにします。
キャッシュの種類を把握する
更新後に古い表示が残ると、実際には直っているのに不具合と判断したり、逆に問題を見落としたりします。WordPressのキャッシュプラグイン、サーバーキャッシュ、CDN、ブラウザキャッシュの利用状況を確認します。更新後にどのキャッシュを、どの順番で削除するかを決めておきます。
バックアップと一緒に互換性も確認する
バックアップは問題発生後の被害を小さくする手段ですが、問題そのものを防ぐ確認も欠かせません。更新対象の配布元が公開している変更履歴、対応するWordPressやPHPのバージョン、既知の不具合、必要な設定変更を確認します。長期間更新されていないテーマやプラグイン、配布元が不明な製品、ライセンスが切れて更新情報を見られない製品は、通常より慎重に扱います。
現在の動作環境を書き出す
WordPress、PHP、データベース、利用中テーマ、主要プラグインのバージョンを一覧にします。更新後にサポート対象外となる組み合わせがないかを確認してください。PHPの変更とWordPress本体の更新を同じ時間にまとめると、問題が起きたときに原因が分かりにくくなります。大きな変更は分けて実施し、それぞれの間に動作確認を入れます。
独自機能と外部連携を優先して確認する
一般的なページ表示だけでなく、サイト固有の機能に注目します。フォームから顧客管理へ送る連携、決済、予約、会員認証、在庫同期、アクセス解析、メール配信などは、画面が正常でも裏側で止まることがあります。更新前にテスト方法と正常な結果を決め、更新後に同じ条件で比較できるようにします。
更新を保留する理由を明確にする
更新通知が出たからといって、準備不足のまま本番環境で実行する必要はありません。ただし、保留を無期限に続けるのも安全ではありません。バックアップが取れない、互換性情報がない、復元権限がない、業務時間中で停止できないなど、保留理由を具体化し、確認担当者と再実施日を決めます。セキュリティ修正を含む場合は優先度が高いため、早めにサーバー会社や保守担当者へ相談します。
安全に更新する順番
バックアップがそろったら、更新作業をまとめて実行せず、一つずつ進めます。問題が起きたときに直前の変更を特定できるようにするためです。
利用者が少ない時間を選ぶ
アクセス、注文、予約、問い合わせが少ない時間帯を選びます。作業中に新しいデータが入るサイトでは、更新直前に受付状況を確認し、必要に応じて一時的な案内を出します。作業時間だけでなく、確認と復旧に使える余裕も確保してください。
更新前にもう一度バックアップを確定する
更新ボタンを押す直前に、取得日時、保存先、ファイルとデータベース、成功ログ、復元方法を確認します。バックアップ後に記事編集や注文があった場合は、必要に応じて取り直します。作業担当者が複数いる場合は、誰が確認したかを残します。
一つずつ更新して確認する
テーマと多数のプラグインを同時に更新せず、影響の小さいものから一つずつ進め、主要ページと管理画面を確認します。更新ごとに時刻と結果を記録します。複数更新が必要でも、原因を追える単位を保つことが重要です。
更新中に画面を閉じる、再読み込みする、同じ更新を重ねて実行する行為は避けます。処理が長い場合はサーバーの状態やログを確認し、むやみに別操作を増やさないようにします。
更新後の動作確認を行う
トップページ、主要ページ、スマートフォン表示、管理画面、フォーム、検索、ログイン、画像、メニュー、外部連携を確認します。ECや予約では、テスト注文や通知メールなど、業務に直結する機能を優先します。キャッシュを整理し、ログアウト状態や別ブラウザでも確認すると、管理者だけ正常に見える状態を避けられます。
問題がなければ、更新後の状態でも新しいバックアップを取得します。これにより、次回は正常な最新版を復元ポイントとして利用できます。更新前のバックアップはすぐに削除せず、サイトの運用サイクルに合わせて一定期間保管します。
更新を中止して原因確認へ切り替える基準
更新後に少し違和感があっても、作業を続けてしまうと原因が増えます。次のような状態では、追加更新を止め、直前の変更とログを確認します。
- 管理画面またはサイトへアクセスできない
- 白い画面、重大なエラー、500エラーが出る
- レイアウトが大きく崩れ、キャッシュ削除でも直らない
- 問い合わせ、注文、予約、ログインなど重要機能が動かない
- データベース更新やメンテナンス表示が終わらない
- サーバー容量やメモリに関する警告が出る
- 身に覚えのないファイル変更や不審なユーザーが見つかる
復元を急ぐ前に、現在の状態を別に保存し、エラー内容、更新対象、時刻、操作履歴を記録します。古いバックアップへ戻すと新しい注文や問い合わせが失われる可能性があるため、事業サイトではデータ差分を考えずに全面復元しないことが重要です。
自分で更新するか専門家へ依頼するかの判断
更新作業は、管理画面の操作自体が簡単でも、問題が起きた後の判断まで含めると難易度が変わります。費用だけでなく、停止時間、失う可能性のあるデータ、復旧に必要な権限と知識を基準に考えます。
自分で進めやすいケース
一般的なブログで、独自カスタマイズが少なく、問い合わせや注文が頻繁に発生せず、レンタルサーバーの復元機能が使え、ファイルとデータベースのバックアップを確認できる場合は、自分で一つずつ更新しやすいでしょう。問題が起きたときにサイトを一時停止できることも重要です。
ただし、初めての作業では本番環境だけで試さず、可能ならステージング環境や複製環境で先に確認します。復元方法を一度も確認したことがない場合は、更新より先にサーバー会社の手順を読んでください。
依頼を検討したいケース
- 注文、予約、決済、会員、顧客情報を扱っている
- サイト停止が売上や業務に直結する
- 親テーマやプラグイン本体を直接編集している
- 独自テーマ、独自プラグイン、外部システム連携がある
- WordPressとPHPを複数世代まとめて更新する
- バックアップ範囲や復元方法を説明できない
- 管理画面、サーバー、ドメインの契約者が分からない
- すでにエラー、改ざん、容量不足、メール不達が起きている
依頼時は「更新だけ」の見積もりか、「事前調査、バックアップ、検証環境、更新、動作確認、問題時の復旧」まで含むかを確認します。安い料金でも、バックアップと復旧が対象外なら、失敗時に別費用や長い停止が発生する可能性があります。
依頼先へ確認したい内容
依頼先には、作業範囲、対象バージョン、バックアップの保存先と保管期間、テスト環境の有無、確認項目、作業時間、停止の可能性、問題時の復旧方法、追加費用の条件を確認します。注文や問い合わせがあるサイトでは、作業中の新規データをどう扱うかも重要です。
納品後は、更新した項目、更新前後のバージョン、確認結果、残った課題、バックアップの場所、次回の推奨時期を受け取ります。パスワードをメール本文で送るなど安全でない共有方法を避け、必要最小限の権限を一時的に発行する方法も検討してください。
更新前バックアップの実践チェックリスト
作業直前は、次の項目を上から確認します。すべてを形式的に埋めるのではなく、自分のサイトに関係する項目を、復旧できる根拠とともに確認してください。
- 更新対象、現在のバージョン、更新先のバージョンを記録した
- 更新による影響が大きい機能とページを決めた
- 更新作業の時間、担当者、連絡方法、中止基準を決めた
- 更新直前のデータベースを取得した
- テーマ、プラグイン、uploads、設定ファイルを含むファイルを取得した
- 独自コード、追加CSS、フォーム通知先、外部連携設定を記録した
- バックアップの取得日時と対象サイトを確認した
- 保存先でファイルの実体、容量、成功ログを確認した
- ファイルとデータベースの時刻が大きくずれていない
- 本番サーバーとは別の安全な場所にも保存した
- バックアップを開ける、または一覧を確認できる
- 復元手順、必要な権限、ログイン方法を確認した
- 正常時の主要ページと重要機能を記録した
- 更新前からあるエラーや警告を記録した
- キャッシュの種類と削除方法を確認した
- 更新後に確認するページ、フォーム、外部連携を決めた
- 問題が起きた場合に自分で戻すか依頼するか決めた
よくある疑問
レンタルサーバーの自動バックアップだけで十分ですか
対象範囲、取得頻度、保存期間、復元方法、料金、復元にかかる時間がサイトの条件に合っていれば有力な手段です。ただし、更新直前の状態があるとは限らず、サーバー契約へアクセスできないと使えないこともあります。重要な更新では、手元または別の安全な保存先にも取得し、複数の復旧経路を用意すると安心です。
プラグイン更新だけでもバックアップは必要ですか
必要です。プラグインはファイルだけでなくデータベースを変更する場合があり、テーマや他のプラグインとの相性問題も起こり得ます。小さな更新でも、サイトの重要度と更新対象の役割に応じて、復元できる状態を確認してから実行してください。
バックアッププラグインの完了表示を信じてよいですか
完了表示は参考になりますが、それだけでは不十分です。保存先に実体があるか、容量が不自然でないか、警告や除外がないか、データベースとファイルが含まれるかを確認します。可能なら検証環境で復元テストを行い、実際に使えることを確かめます。
更新前と更新後のどちらでバックアップすべきですか
両方に役割があります。更新前のバックアップは元の状態へ戻すため、更新後のバックアップは正常に動く最新版を次回の復元ポイントにするために使います。更新後の動作確認が終わってから新しいバックアップを取得し、更新前のものも一定期間残します。
復元テストができない場合はどうすればよいですか
最低限、バックアップの対象、日時、容量、保存先、ログ、復元手順、必要権限を確認します。事業への影響が大きいサイトでテスト環境を用意できない場合は、更新作業と復旧対応をまとめて専門家へ依頼することも検討してください。
まとめ
WordPress更新前のバックアップでは、ファイルが一つ存在することではなく、更新直前のファイルとデータベースがそろい、安全な別の場所に保存され、必要な権限と手順で復元できることが重要です。さらに、正常時の表示、重要機能、更新対象、作業時刻を記録すると、更新後の確認と原因切り分けがしやすくなります。
更新はセキュリティと安定運用のために必要ですが、急いで一括実行する必要はありません。影響範囲を確認し、バックアップを検証し、一つずつ更新し、重要機能を確認する流れを守りましょう。注文や予約、会員、独自開発、複数世代の更新など影響が大きい場合は、更新操作の費用だけでなく、事前検証と復旧まで含めて依頼先を選ぶことが失敗回避につながります。
