WordPressのテーマは、脆弱性への対応や新しいWordPressへの追従を理由に更新されます。表示崩れが心配だからと更新を止め続けると、時間が経つほど新しい環境との差が広がり、かえって一度の作業が大きくなります。

安全に進める要点は、更新ボタンを押す前に「どこを変更しているか」を確認することです。ファイルとデータベースを同じ時点でバックアップし、検証環境でテーマだけを更新します。問題が起きたときに元へ戻せるところまで準備してから、本番へ進むのが現実的です。

最初にカスタマイズの保存場所を確認する

まず、現在有効なテーマと、そのテーマが親テーマか子テーマかを確認します。親テーマのPHPやCSSを直接編集している場合、その変更は更新時に上書きされる可能性があります。制作会社へ依頼したサイトで編集方法が分からなければ、更新前にファイルの差分を調べてもらう方が安全です。

継続して使う独自変更は、原則として子テーマへ分けます。子テーマであれば親テーマを更新しても独自ファイルを残せますが、古いテンプレートを子テーマ側で上書きしていると、親テーマの更新内容が反映されない場合があります。「子テーマだから崩れない」とは考えず、上書きしているファイルまで確認します。

外観の追加CSSやブロックテーマのサイトエディターで行った変更は、テーマファイルではなくデータベースへ保存されることがあります。ファイルだけを複製しても同じ表示を再現できないため、カスタマイズの場所を調べる作業とバックアップの範囲は分けて考えます。

更新前の状態を比較できる形で残す

更新前にはWordPress本体・有効テーマ・主要プラグイン・PHPのバージョンを記録します。テーマの配布元に更新履歴や動作要件があれば読み、現在のWordPressとPHPが対象に含まれているかを確認します。対応条件を満たしていない場合は、テーマだけを先に更新しない方がよいこともあります。

バックアップはテーマファイルだけでなく、プラグインやアップロード画像を含むWordPressのファイルとデータベースを同じ時点で取得します。復元方法が分からないバックアップは、事故時の判断材料として不十分です。管理画面の自動バックアップを使う場合も、保存世代と復元対象を事前に確認しておきます。

トップページや記事ページなど、普段見られる代表的な画面はスクリーンショットに残します。ヘッダー・メニュー・問い合わせ導線・フッターまで一枚に収める必要はありません。画面幅とURLが分かる形にすると、更新後の違いを担当者間で共有しやすくなります。

検証環境ではテーマだけを更新する

本番サイトの複製を用意できるなら、最初の更新先は検証環境にします。WordPressやPHPの条件が本番と大きく違う環境では結果を比較できないため、可能な範囲で構成をそろえます。複製した環境には検索エンジンや外部の利用者が入らないように、認証やアクセス制限も設定します。

検証時にWordPress本体・テーマ・プラグインをまとめて更新すると、崩れたときに原因を切り分けられません。最初は対象テーマだけを更新し、キャッシュを削除してから表示を確認します。問題がなければ、ほかの更新は別の作業として順番に進めます。

更新後に管理画面が開けるだけでは確認を終えられません。公開ページのHTMLやCSSは表示できても、フォームのJavaScriptやメール送信だけが止まることがあります。会社サイトでは見た目と業務機能の両方を確認対象にします。

表示確認はページの種類と画面幅を変える

確認するのはトップページだけではありません。記事・固定ページ・一覧・検索結果・404ページのように、異なるテンプレートを使う画面を選びます。キャンペーン用の固定ページや独自の投稿タイプがある場合は、売上や問い合わせへの影響が大きいページから確認します。

同じURLをパソコンとスマートフォンの幅で開き、メニューの開閉や画像のはみ出しを見ます。ヘッダーとフッターは多くのページに共通するため、ロゴ・電話番号・ボタンの位置も確認します。ログイン中だけ正常に見える場合があるので、別のブラウザーかシークレットウィンドウでも開きます。

問い合わせフォームは入力画面を見るだけでなく、テスト送信まで行います。確認画面・完了画面・自動返信・担当者への通知が一連で動くことを確かめます。ECや予約機能があるサイトでは、決済直前までの導線と管理側の受付記録も確認が必要です。

本番更新は戻す判断を先に決める

本番作業では、担当者と作業時間を決め、更新中の投稿や設定変更を止めます。直前のバックアップが完了したらテーマだけを更新し、サーバー側とWordPress側のキャッシュを削除します。その後は検証環境で使ったURLと操作を同じ順番で確認します。

一部の表示に違いが出たときは、その場で修正を重ねる前に影響範囲を判断します。主要な導線やフォームが使えない場合は、予定時間内に直せる根拠がなければ元へ戻します。軽微な余白の違いを後日直すのか、公開を取りやめるのかも、作業前に基準を決めておくと迷いません。

元へ戻すときは、古いテーマファイルだけを部分的に上書きしないようにします。ファイルとデータベースの状態がずれると、別の不具合を増やすことがあります。取得したバックアップの単位に合わせて復元し、復元後も代表ページとフォームを再確認します。

自動更新は確認担当まで決めて運用する

独自変更が少なく、検証と復元の仕組みが整ったサイトでは、テーマの自動更新が保守の助けになります。親テーマを直接編集したサイトでは、自動化だけを先に有効にしても安全とはいえません。更新後に担当者が確認できない体制も同様です。更新通知が届くことと、サイトが正常に動くことは別の確認です。

自動更新を使う場合も、通知を読む担当者と確認するページを決めます。異常があったときの連絡先と復元手順を運用資料に残せば、担当者が不在でも初動をそろえられます。テーマ更新は一度の作業ではなく、更新後の確認までを繰り返せる仕組みにしておくことが大切です。