WordPressのテーマを変える前には、旧テーマに依存する機能と重要ページの状態を記録し、問題が起きたときに戻す条件と方法を用意したうえで、新テーマでテストします。切り替えた直後は、公開サイトで表示・操作・検索向けの設定を確かめます。
旧テーマを再び有効にすることと、バックアップからサイトを復元することは別の対応です。過去のデータベースで上書きすると、切り替え後に受け付けた注文や問い合わせを失う可能性もあるため、戻し方まで決めてから変更を進めましょう。
テーマだけを変えるのか、URLも変えるのかを分ける
まず、既存ページのURLを維持するかを決めます。見た目を変えるテーマ変更と、ドメインや記事のURLを変える移行では、必要な準備が異なります。
URLを変える場合は、旧URLと新URLの対応付けや、旧URLへのアクセスを新URLへ転送するリダイレクトの計画が必要です。Search Consoleのアドレス変更ツールはドメイン・サブドメイン間の移転に使うもので、テーマ変更だけを理由に使うものではありません。同じドメイン内でのURLパス変更にも不要です。適用条件はGoogleのサイト移転資料で確認できます。
架空の計画例として、記事のURLを保ったままテーマを変えるなら、以下の確認を中心に準備します。一方、記事のURLも変えるなら、テーマのテストとは別にURL移行の計画を用意してください。
Googleはサイト移転について、変更を一つずつ行う考え方を示しています。原因を切り分けやすくするため、テーマ変更とURL変更も、可能なら作業を分けることをおすすめします。
旧テーマに依存する機能と、比較するページを選ぶ
テーマは見た目だけでなく、コンテンツの表示方法や一部の要素の動作にも関わります。WordPress公式のテーマ解説を踏まえ、変更前には、残したい機能を何が担っているのか調べることをおすすめします。
調査の候補は、旧テーマ独自の装飾、ショートコード、ブロック、ウィジェット、追加CSS、テンプレートへの個別編集、アクセス計測用のタグなどです。ショートコードは本文中の短い記述から部品を表示する仕組み、CSSは見た目を指定するコードです。
これらがテーマ変更ですべて失われるとは限りません。テーマ、プラグイン、個別に追加したコードのどれが担っているかと、使われているページを記録します。分からないものは推測で埋めず、実装した担当者やテーマの資料で確認してください。
比較するページは、次の観点で選ぶと確認漏れを減らしやすくなります。
- 問い合わせや購入など、利用者に完了してほしい操作があるページ
- 検索から訪問されている記事
- トップページ、記事、一覧など、表示形式が異なるページ
- 旧テーマ独自の部品を使っているページ
Search Consoleでは、ページ別の検索表示回数やクリック数の傾向を確認できます。検索流入のあるページを選ぶ際に利用できますが、データを参照できない場合は、その観点での選定は未確認として、ほかの観点から対象を決めます。機能の説明はGoogleのSearch Console案内にあります。
選んだページでは、URL、画面のスクリーンショット、本文と画像、メニュー、重要なリンク、操作後に起きることを残しましょう。画面だけでなく、設定画面や通知の送信先なども記録すると、変更後に比較できます。
架空の記録例なら、次のようにまとめられます。
- 検索流入のある記事：旧テーマの装飾部品を使用。本文・画像・装飾の表示と、問い合わせページへのリンクを記録する。
- 問い合わせページ：フォームを担うプラグインを調べる。送信完了画面、通知先、問い合わせ内容の保存先を記録する。
検索向けの情報も、実装担当者と必要な項目を選んで記録します。例えば、titleはページのタイトル情報、canonicalは正規URLを示す情報、noindexは検索への登録を避ける指定です。誰がどこで設定しているかも残しておくと、変更後に差が見つかったときの調査に役立ちます。
バックアップと、戻す条件を用意する
通常のWordPressサイトを完全に復元するには、ファイルとデータベースの両方のバックアップが必要です。テーマや画像などのファイルを保存しただけでは、別に保存されているデータベースのバックアップにはなりません。WordPress公式のバックアップ解説でも、この二つを区別しています。
復旧に備えるため、バックアップについて次の情報をまとめることをおすすめします。
- 保存日時と、ファイル・データベースそれぞれの対象範囲
- 保存先と、復旧担当者がアクセスする方法
- 使用する機能の復元手順と、上書きされる範囲
- 復元を実行する担当者
取得できたことだけで、復元できるとは判断できません。可能なら、本番を上書きしないテスト環境で復元し、ページが開くことや必要な機能が動くことまで確かめます。具体的な操作は、利用するホスティングやバックアップ機能の資料で確認してください。
旧テーマへの切り戻しと、データ復元を分ける
旧テーマの再有効化は、適用するテーマを戻す操作です。バックアップ復元は、ファイルやデータベースを保存時点の状態へ戻す操作です。
旧テーマを再有効化できるよう残しておき、テスト環境で戻した後の表示や動作も確かめましょう。対象サイトで、旧テーマに戻すだけで設定や機能まで復旧するかは、実際の構成と変更内容を調べないと判断できません。
戻す条件は、先に選んだ重要な利用経路を基に決めます。購入できない、重要ページが開かない、問い合わせ通知が届かない、検索に登録したいページに意図しないnoindexが付く、といった問題が候補です。問題を見つけたときに、誰が調べ、誰が切り戻しを判断するかも決めておきます。
架空の対応例では、問い合わせ通知が届かなければ切り替え作業を中断し、担当者が原因を調べます。新テーマに起因し、旧テーマへ戻すことで解消できると確認できた場合は切り戻しを行い、その後に送信・通知・保存を再試験します。
切り替え後に増えたデータを守る
バックアップ時点のデータベースで本番を上書きすると、その後に追加された注文、問い合わせ、会員登録、記事更新などが復元先から失われる可能性があります。これは、対象データがそのデータベースに保存され、追加分を保全・反映せずに過去の状態へ戻す場合のリスクです。外部サービスに保存されるデータでは条件が異なります。
注文を受け付けるサイトなら、購入機能の復旧と、切り替え後に入った注文の保全を別々に考える必要があります。注文の保存先、復元で上書きされる範囲、追加分を残す方法を確認してください。
受付を一時的に止める必要があるかも含め、利用するサービスの仕様を確認して担当者と決めます。データをどう守るか分からないまま、本番のデータベースを上書きしないようにしましょう。
新テーマで表示と操作をテストする
復旧の準備ができたら、選んだページを新テーマで確認します。プレビューで表示を見たうえで、重要な操作は本番に近いテスト環境で試すことをおすすめします。
WordPress公式資料のブロックテーマの説明には、詳しく確認するためにテストサイトを用意する選択肢があります。また、プレビューが空白の場合は、原因を調べずに有効化しないよう案内されています。詳しくはテーマのプレビューとテストサイトの説明を参照してください。
テストでは、変更前の記録と新テーマでの表示・動作を比較します。例えば、装飾部品を使った記事は、本文や画像が欠けていないか、装飾が読みにくくなっていないか、問い合わせへのリンクが使えるかを見ます。フォームは送信完了画面だけで終えず、通知が届くことと、設定した保存先に内容が残ることまで確かめます。
購入機能がある場合は、決済サービスの資料でテスト方法を確認してください。実際の課金を伴う試験を一律に行う必要はありません。
テスト環境と本番の違いも記録します。WordPress本体やPHPのバージョン、主要プラグイン、コンテンツ、キャッシュの設定などが候補です。キャッシュは表示を速くするために保存されたデータで、比較する画面が最新かを判断する際にも関わります。
本番の通知や決済をテスト環境で再現できない場合は、その部分を未確認として残します。テスト環境を用意できない場合も、プレビューだけで操作まで正常と判断せず、サービスの資料や担当者に確認し、本番で試す方法と問題時の対応を決めてください。
本番へ切り替えたら、利用者の操作を確かめる
切り替え前に、テストで見つかった問題、残っている未確認事項、バックアップ、戻す担当者と判断条件を見直します。問い合わせや購入など重要な機能に未確認事項がある場合は、確認方法と対応を決めてから本番へ進みましょう。
新テーマがインストール済みで変更権限がある場合、管理画面の「外観」→「テーマ」で新テーマを有効化すると、直ちに適用されます。操作はWordPress公式の有効化手順で確認できます。
有効化の通知は、利用者が問題なく使えることの確認とは別です。切り替え直後は、変更前に選んだ重要ページを、ログアウトした状態でも開いてください。スマートフォンとパソコンで、本文、画像、メニュー、リンクを比較します。
その後、利用者がたどる経路を実際に確認します。架空の確認例なら、検索流入のある記事を開き、記事中のリンクから問い合わせページへ進み、テスト送信後に通知が届くところまで試します。保存する設定なら、問い合わせ内容が残ったかも確かめます。
購入サイトではテスト可能な購入経路、会員サイトではログイン後の利用経路など、サイトに必要な操作を選びます。あわせて、記録したtitle・canonical・noindexなどの検索向け情報と、計測タグが意図した状態になっているかを担当者と確認します。
問題が見つかった場合は、事前に決めた条件に沿って作業の中断や切り戻しを判断します。戻した後も、問題が起きた操作を再試験してください。
検索状況は、切り替え直後の動作確認と分けて見る
公開サイトでの操作を確かめた後は、検索から発見・訪問されているかを観察します。Search Consoleではページ別の検索パフォーマンスやインデックス登録状況を確認でき、URL検査では公開URLのテストも利用できます。機能の範囲はGoogleのSearch Console案内で確認できます。
変更前に選んだ検索流入のある記事について、クリック数や表示回数の傾向と、検索への登録状況を見ましょう。意図しない差が見つかった場合は、そのURLを開き、表示や検索向けの設定にも変更がないか調べます。
検索指標の変化だけで、テーマ変更が原因だと決めることはできません。また、Search Consoleで問題が見つからなくても、フォームや購入機能の正常動作を保証するものではありません。検索の確認と、利用者の操作テストはそれぞれ行ってください。
データを参照できない部分は、検索状況を確認済みとは扱わず、未確認として残します。変更前の記録、テスト結果、本番で確認した操作、戻す手順を同じ場所にまとめ、未確認事項には確認方法と担当者を添えておくと、問題が起きたときに次の行動を選びやすくなります。
