WordPressのテーマ変更前チェック｜表示崩れ・機能・SEOを守る進め方

WordPressのテーマ変更は、ボタン一つで有効化できても、確認まで同じ速さで終わる作業ではありません。投稿や固定ページ、画像などのデータは通常そのまま残りますが、それらをどのテンプレートで、どの機能を使って表示するかはテーマに左右されます。見た目だけを変えたつもりでも、メニュー、フォーム、ショートコード、構造化データ、アクセス計測まで影響することがあります。

安全に進める基本は、本番サイトで直接テーマを切り替えてから不具合を探すのではなく、先に「現在のテーマへ何が依存しているか」を記録し、戻せるバックアップを用意し、テスト環境で新旧を比較してから本番へ反映することです。比較の合格条件は「すべて同じ見た目」ではなく、重要な情報へ迷わず到達できる、問い合わせが完了する、検索エンジン向けの出力と計測が意図どおり残る、といった事業上の要件で決めます。

なお、見た目の変更だけでなく、ページ構成や掲載内容、問い合わせまでの導線も変えたい場合は、テーマ交換だけでは範囲が足りないことがあります。古いホームページを残す・直す・作り直す範囲の分け方も先に整理すると、今回の作業を「テーマ変更」で収めるか、リニューアルとして計画するかを判断しやすくなります。

テーマ変更は「見た目の交換」だけではない

テーマは、色や文字サイズを決めるだけの着せ替えではありません。ヘッダーとフッター、記事一覧、固定ページ、検索結果、404ページなどのテンプレートを持ち、メニュー位置、ウィジェット領域、画像サイズ、独自ブロック、ショートコード、構造化データなどを提供している場合があります。さらに、テーマ内の functions.php や子テーマへ機能を追加しているサイトでは、テーマを変えることが機能の実行元を変えることにもなります。

まず確認したいのは、現在のサイトがクラシックテーマ、ブロックテーマ、または両方の仕組みを組み合わせた構成のどれに近いかです。クラシックテーマではPHPテンプレート、カスタマイザー、ウィジェット、テーマごとのメニュー位置が中心です。ブロックテーマでは「外観→エディター」のサイトエディターで、テンプレート、テンプレートパーツ、パターン、スタイル、ナビゲーションを管理します。管理画面の同じ「外観」に見えても、変更後に使う編集場所と引き継ぎ方が異なります。

そのため、最初の確認は新しいテーマのデモを見ることではなく、今のサイトがどこで出来上がっているかを特定することです。テーマ名だけでなく、親テーマと子テーマの組み合わせ、直接編集したファイル、カスタムCSS、サイトエディターで保存したテンプレート、ページビルダーやプラグインの役割まで追います。設定の保存場所が分かれば、「新テーマへ移す」「プラグイン側へ移す」「不要なので廃止する」を分けられます。

最初にテーマ依存の棚卸し表を作る

テーマ変更前の棚卸しは、機能名を並べるだけでは足りません。「現在どこで設定しているか」「変更後も必要か」「何をもって合格とするか」を一つの表にします。設定画面のスクリーンショットだけでなく、ファイル名、プラグイン名、管理画面の場所、外部サービスのアカウント、確認用URLを残すと、変更後に担当者が変わっても追跡できます。

テーマと子テーマ、独自コードの所在

「子テーマを使っているか」は、外観のテーマ一覧だけで判断しません。子テーマの style.css、functions.php、上書きテンプレート、追加したJavaScriptやCSSを確認します。親テーマを直接編集している場合は、更新で消える可能性があるため、テーマ変更とは別にコードの移設方法を決めます。スニペット管理プラグインやサーバー側の設定ファイルに処理が分散していることもあるため、制作会社や保守担当者の作業記録も照合します。

画面を構成する設定とコンテンツ依存

ヘッダー、フッター、メインメニュー、フッターメニュー、サイドバー、トップページ、記事一覧、パンくず、検索、404ページを確認します。記事本文では、テーマ独自のブロック、ショートコード、装飾クラス、ページビルダー、カスタム投稿タイプ、カスタムフィールドが使われていないかを見ます。テーマを止めた瞬間に管理画面から項目が消える構成では、本文データが残っていても表示や編集ができなくなるため、先に代替方法が必要です。

外部サービス、SEO、計測の実装場所

アクセス解析、タグ管理、広告計測、同意管理、チャット、予約、地図、会員機能、問い合わせ通知などが、テーマのヘッダーやフッターへ直接貼られていることがあります。SEOも、SEOプラグインだけで完結しているとは限りません。テーマがタイトル、OGP、パンくず、構造化データを出力していると、新テーマやプラグインの出力と重複する場合があります。現在のHTMLソースを保存し、どの仕組みが何を出しているかを対応させます。

棚卸し表は、すべての技術要素を理解するための資料ではありません。変更後に「どこを見れば、残ったかどうか判断できるか」を共有するための資料です。項目が分からない場合も空欄にせず、「実装場所不明」「要調査」と記録します。不明点が多いこと自体が、テーマ変更の作業量とリスクを見積もる材料になります。

バックアップは「取った」ではなく「戻せる」まで確認する

テーマ変更前のバックアップは、データベースだけ、またはテーマフォルダーだけでは不十分です。少なくとも、投稿や設定を含むデータベース、テーマ、プラグイン、アップロード画像などのサイトファイル、必要に応じてサーバー設定を対象にします。レンタルサーバーの自動バックアップがある場合も、保存期間、復元できる単位、復元を申請する権限、復元にかかる操作を確認します。外部のフォーム、予約、会員、決済などはWordPressのバックアップに含まれないことがあるため、別の復旧方法が必要です。

重要なのは、バックアップファイルが存在することではなく、その時点へ戻せることです。可能ならテスト環境へ復元し、管理画面へ入れるか、画像が表示されるか、フォームや主要ページが動くかを確認します。復元まで実施できない場合でも、保存日時、保存場所、対象範囲、実行者、復元手順、必要な認証情報の管理者を一枚にまとめます。障害時に「バックアップはあるが、誰も戻せない」という状態を避けるためです。

本番切替の直前には、テスト開始時とは別に最新のバックアップを取得します。テスト中に更新された記事や問い合わせ、注文などがあれば、古いスナップショットへ戻すだけでは失われる可能性があります。また、新テーマの初期設定や関連プラグインがデータベースを書き換える場合、旧テーマを再有効化するだけで完全に元へ戻るとは限りません。戻し方は「旧テーマへ切り替える」と「バックアップから復元する」を分け、どちらを使うか条件を決めます。

テスト環境を本番に近づけ、四段階を通す

テスト環境は、新テーマの見た目を眺める場所ではなく、本番切替を再現する場所です。WordPress本体、PHP、プラグイン、主要な設定、コンテンツをできるだけ本番へ合わせます。キャッシュやCDN、ライセンス、外部APIなど、本番と同じにできない項目は差分として記録し、切替後に追加確認します。テスト用URLは、認証やアクセス制限を使い、検索エンジンへ公開しない設定にします。noindex を使う場合も、最終的に本番へ設定を移す際に残さない確認が必要です。

進め方は、依存を棚卸しする、復元を準備する、新旧を比較する、条件を満たして本番へ反映する、の四段階です。各段階で作る記録が次の段階の確認表になります。特に、テスト環境で直した内容をどの方法で本番へ反映するかは早めに決めます。テスト環境を丸ごと上書きすると、本番側で後から追加された投稿や問い合わせデータを失うことがあるためです。テーマファイル、設定、テンプレート、コンテンツを分け、移す対象を選びます。

テスト期間中も本番サイトを更新する場合は、「更新を止める時間」と「差分を移す担当」を決めます。記事や固定ページの更新だけなら一覧で差分を管理できますが、注文、予約、会員登録など時系列で増えるデータを持つサイトでは、単純な上書きはできません。切替当日の作業時間を短くするためにも、事前に本番へ反映できる作業と、切替時にしかできない作業を分けておきます。

フォームや計測をテストする際は、本番の担当者へテスト通知が大量に届かないよう、送信先や件名を分けます。アクセス解析にもテスト環境の閲覧が混ざらないようにします。一方で、外部サービスとの接続をすべて止めると本番と同じ確認ができないため、テスト用プロジェクトや検証モードがあるかを確認し、使えない場合は本番切替後の確認項目へ残します。

新旧比較は「代表ページ×合格条件」で行う

全URLを一枚ずつ目視するだけでは、ページ数が多いサイトほど確認が散漫になります。まずテンプレートの種類を分け、各種類から代表ページを選びます。トップページ、主要なサービスページ、一般的な固定ページ、記事詳細、記事一覧、検索結果、404ページ、カスタム投稿、問い合わせフォーム、プライバシーポリシーなどです。売上や問い合わせに直結するページは、テンプレートの代表とは別に個別確認します。

比較するのは、画面の見た目だけではありません。ナビゲーション、リンク、絞り込み、検索、フォーム、動画、地図、PDF、追従ボタン、会員・予約・購入など、利用者が操作する経路を通します。ログイン状態では管理バーやキャッシュの影響が異なるため、ログアウトした画面やシークレットウィンドウでも確認します。スマートフォンは幅を狭めるだけでなく、実機でタップ、入力、スクロール、固定要素の重なりを見ます。

合格条件は「旧テーマと完全に同じ」ではなく、新テーマで守るべき結果を記述します。余白や装飾が変わること自体はテーマ変更の目的に含まれます。一方、問い合わせボタンが画面外へ隠れる、見出し階層が崩れる、表が横にはみ出して内容を読めない、といった変化は事業上の問題です。見た目の差と機能停止を同じ優先度で扱わず、公開を止める問題、公開後に直せる問題、意図した変更を分類します。

確認結果には、URL、端末、操作、期待結果、実際の結果、担当、修正状況を残します。スクリーンショットは有効ですが、画像だけでは「何を確認したのか」が分からないため、合格条件とセットにします。同じテンプレートで一件の問題が見つかったら、そのテンプレートを使う他ページへ範囲を広げます。逆に、一件の正常表示だけで同じ種類の全ページを合格にはしません。長いタイトル、画像なし、表あり、動画ありなど、崩れやすい内容を代表に選びます。

SEOと計測は画面ではなく出力まで比べる

SEOの確認では、順位がすぐに変わったかではなく、検索エンジンへ渡す情報が変更前後で意図どおりかを比べます。まずURLとHTTPステータス、canonical、robots、noindex、XMLサイトマップ、内部リンクを確認します。テーマ変更だけなら通常URLを変える必要はありませんが、テーマが登録していたカスタム投稿タイプやアーカイブ、パンくずの構造が変わるとURLやリンク先へ影響することがあります。変える必要があるURLは、旧URLと新URLの対応表を作り、転送とリンク更新を別々に確認します。

次に、title 要素、画面上のH1、メタディスクリプション、OGP、サイト名、パンくず、構造化データを確認します。SEOプラグインとテーマが同じ情報を出すと、構造化データやOGPが重複することがあります。反対に、旧テーマが出していた情報を新テーマが出さず、欠落する場合もあります。代表URLのHTMLソースを新旧で保存し、構造化データは検証ツールへ通します。画面上に同じタイトルが見えていても、title やH1が別の文言になっていないかまで見ます。

計測では、アクセス解析やタグ管理の設置有無だけでなく、主要行動のイベントが一回だけ記録されるかを確認します。旧テーマへ直接入れた計測コードを残したまま、プラグインや新テーマでも同じタグを追加すると二重計測になります。反対に、テーマ変更でヘッダー内のコードが消えると、ページ表示は正常でもデータだけ途切れます。ページ表示、フォーム送信、電話リンク、資料ダウンロードなど、サイトで判断に使っている行動をリスト化し、テスト操作とリアルタイムの受信結果を対応させます。

本番反映後は、検索エンジンの再クロールを待つ必要があります。公開直後の順位だけで成否を決めず、URL検査でGoogleが取得したHTMLを確認し、インデックス状況、構造化データのエラー、検索流入の変化を継続して見ます。テーマ変更そのものが検索順位を保証することはありません。比較すべきなのは、変更で失ってはいけない出力が保たれ、改善した表示速度や使いやすさが実際の利用に悪影響を出していないかです。

本番切替は戻す条件まで決めてから行う

本番切替の手順書には、作業順だけでなく、担当者、開始条件、確認担当、連絡方法、戻す条件を入れます。アクセスや問い合わせが比較的少ない時間帯を選び、更新を一時停止し、最新バックアップを取得してから反映します。テーマを有効化した後は、キャッシュやCDNを更新し、トップページだけでなく、フォームと重要ページを優先して確認します。作業者が「直したつもり」で進めず、別の確認者が合格条件に沿って見る形が安全です。

1. 記事更新や受注データの扱いを確認し、必要な範囲で更新を止める
2. データベースとサイトファイルの最新バックアップを取得する
3. テスト済みのテーマ、子テーマ、設定、テンプレートを本番へ反映する
4. サーバー、WordPress、プラグイン、CDNなどのキャッシュを更新する
5. トップ、主要ページ、フォーム、SEO出力、計測を優先順に確認する
6. 公開継続または復元を判断し、更新停止を解除する

すぐ戻す条件には、白画面やサーバーエラー、管理画面へ入れない、問い合わせや購入が完了しない、主要メニューが使えない、本番へ noindex が残った、canonicalが別URLを指す、計測が欠落または二重になった、といった重大な問題を置きます。軽微な余白や装飾の差は、影響範囲と修正時間が分かれば公開後に直す判断もできます。すべての不具合で復元するのではなく、事業継続と検索・計測への影響で線を引きます。

切替直後に問題がなくても、翌営業日以降に、問い合わせ通知、予約・注文、定期処理、検索エンジンの取得結果を確認します。旧テーマは、戻す可能性がある期間は更新状態を保って一時的に残し、安定確認後に不要なテーマやテスト用設定を整理します。使わないテーマを長期間放置するのではなく、復元用バックアップと作業記録を保管したうえで、運用環境を単純にします。

自社で進める範囲と専門家へ任せる範囲を分ける

自社で進めやすいのは、独自コードがなく、標準ブロックを中心に作られ、ステージング環境と復元手段があり、フォームなどの重要機能が少ないサイトです。新テーマの設定方法を理解し、代表ページの合格条件を作れる担当者がいることも条件になります。テーマのプレビューだけで「問題なさそう」と判断するのではなく、棚卸し、復元、比較、本番確認を一続きで実行できるかで判断します。

専門家へ確認したほうがよいのは、子テーマや親テーマを直接編集している、functions.php に業務機能がある、テーマ独自のショートコードやカスタム投稿を多用している、ページビルダーを全面的に使っている、EC・予約・会員・多言語など止めにくい機能がある、計測や広告タグが複数ある、といった場合です。バックアップの場所や復元方法が分からない、サーバーやドメインの管理者が不明、制作会社からコードや資料を引き継げていない場合も、切替前の調査を分けて依頼するほうが安全です。

依頼時に必要なのは、すべての技術仕様を自社で解明することではありません。テーマを変えたい理由、残したいページと機能、困っている表示、更新を止められる時間、現在分かっている管理情報を共有すれば、調査範囲を決められます。準備が未完成でも、「何が不明か」が記録されていれば、調査と実装を混同せずに見積もりや進行を整理できます。

まとめ｜安全性は作業前の記録と戻し方で決まる

WordPressのテーマ変更で守るべきものは、旧テーマの見た目そのものではなく、必要な情報、主要な操作、検索エンジン向けの出力、計測、そして日々の更新を続けられる状態です。テーマを選んだ後ではなく、選ぶ前に依存関係と合格条件を整理し、バックアップを復元できる形にし、テスト環境で新旧を比較します。本番切替は、重大な問題の戻し条件と確認担当まで決めて初めて実行可能になります。この順序なら、表示崩れを見つけるだけでなく、機能やSEOの抜けを公開前に判断できます。