WordPressのテーマ移行は、見た目だけを差し替える作業とは限りません。テーマに紐づく設定や表示部品があるため、現在の構成を把握し、復元できる状態を作ってからテストします。本番サイトの変更を急がず、作業内容と確認結果を記録することが出発点です。
最初にテーマ依存の機能を洗い出す
カスタム投稿タイプ、ショートコード、ウィジェット、カスタムフィールド、追加したCSSやPHPなど、現行テーマに依存している機能を一覧にします。依存関係の有無や移行後の扱いは、テーマとプラグインの公式ドキュメント、現在の設定を照合して判断します。データ自体と、そのデータを表示する仕組みを分けて確認するのがポイントです。
作業前のチェックリスト
チェックリストは、バックアップを取ったかだけでなく、戻す条件と確認する担当をそろえるために使います。ファイルとデータベースの復元方法、テーマ固有の設定、プラグインの互換性、テスト環境、本番切り替えの時間帯を順番に記録し、未確認の項目は作業開始前に明示します。
- ファイルとデータベースを含むフルバックアップを取得し、復元手順を確認する
- 現行テーマの依存機能、子テーマ、追加コード、外部サービスを一覧にする
- 利用中のプラグインと新テーマの互換性・既知の問題を公式情報で確認する
- 本番と同じ構成を試せるステージングまたはローカル環境を用意する
- 作業担当者、切り戻しの判断者、作業時間帯を決める
ステージングで移行を試す
本番データを複製したテスト環境で新しいテーマを有効化し、表示と機能を確認します。複製方法や環境の制約はサーバーの仕様に左右されるため、利用中のホスティングサービスの手順を確認してから進めます。複製できないデータや外部連携がある場合は、代替のテスト方法と確認できない範囲を記録します。
ページと導線を比較する
トップページだけで判断せず、主要な固定ページ、記事、一覧、フォーム、ログインが必要な画面などを移行前後で比較します。スクリーンショットやチェック表を使う場合も、対象ページと確認日を残しておくと差分を追いやすくなります。
- ヘッダー・フッター・ナビゲーションが意図した順序で表示されるか
- 問い合わせ・予約フォームの入力、送信、受信確認ができるか
- スマートフォンなど異なる画面幅で文字や画像が崩れていないか
- カスタム投稿や一覧ページのリンク、画像、添付ファイルが機能するか
本番切り替えと切り戻し
テスト結果と未解決の項目を確認し、切り替え前のバックアップを固定します。作業中に変更が入るサイトでは、複製したデータとの差分を確認してから本番へ反映します。切り替え直後は主要ページ、フォーム、ログイン、決済など事業に直結する動線を優先して再確認し、異常があれば決めておいた手順で旧テーマへ戻します。
移行後の記録と保守
テーマ、プラグイン、PHPなどの構成、変更日時、確認者、残課題を記録します。表示だけでなく、フォームの通知、権限、メタ情報、キャッシュなど運用に関係する設定も確認対象に含めます。互換性やサポート範囲は環境や製品の更新で変わるため、公式情報を参照して定期的に見直します。
テーマ移行を自社で行う場合も、作業範囲と復元条件を先に文書化しておくと、判断を引き継げます。複数の担当者が関わるときは、テスト結果と承認記録を共有し、次の更新で同じ確認を繰り返せるようにします。運用範囲はサービスの案内、個別の確認事項はお問い合わせページで整理できます。 バックアップは公式のファイル手順、子テーマは公式の子テーマ説明、更新前の確認は公式の更新手順と照合します。
