WordPressのテーマ更新で表示が崩れる主な原因は、親テーマへ直接加えた修正の上書きや、子テーマ・プラグインとの互換性の変化です。更新前にカスタマイズの場所を確認し、ファイルとデータベースのバックアップを用意すると、変更が失われるリスクを抑えられます。

検証環境があるなら、そこでテーマを更新してから本番へ反映します。子テーマを使っていても、必ず表示が保たれるわけではありません。

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

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

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

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

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

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

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

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

検証環境で、変更を一つずつ確認する

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

検証時にWordPress本体・テーマ・プラグインをまとめて更新すると、崩れたときに原因を切り分けられません。更新先が新しいWordPressやPHPを必須とする場合は、要件に合う順番で更新します。一度にまとめず、各変更後にキャッシュを削除して表示を確認します。問題がなければ、ほかの更新は別の作業として順番に進めます。

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

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

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

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

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

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

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

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

戻す対象は、更新で何が変わったかによって異なります。ファイルだけを戻せる場合もありますが、テーマの設定やDBも変わっていれば、その整合が必要です。DBを戻す際は、バックアップ後に増えた記事や問い合わせを失わないよう先に退避し、復元後に代表ページとフォームを確認します。

自動更新は、カスタマイズの方法でも向き不向きがある

独自変更が少なく、更新後の表示を確認できるサイトでは、自動更新が保守の助けになります。反対に、親テーマを直接編集している場合は、自動更新による上書きに注意が必要です。

子テーマへ分ければ独自ファイルを残しやすくなりますが、古いテンプレートと新しい親テーマの組み合わせで不具合が出る場合もあります。更新を止め続けることでも、子テーマへ移すだけでも、すべての問題が解消するわけではありません。

普段から使うページを更新前後で比べられる状態が、表示崩れを見つける助けになります。見た目だけでなく、メニューやフォームの操作も確認すると、気付きにくい不具合を拾いやすくなります。