WordPressのテーマを変えずにデザインを今風にする方法｜停止すれば全て戻せる「上書きしない改修」の実例
WordPressのテーマを変えずにデザインを今風にする方法｜停止すれば全て戻せる「上書きしない改修」の実例
「ホームページが古く見えるのでデザインを変えたい。でもテーマを変えると壊れそうで怖い」。長年WordPressを運用してきたサイトほど、この悩みは切実です。
先に結論を書きます。テーマは変えなくてよいです。そして、変えない改修には正しいやり方があります。既存のデータを一切上書きせず、変更を「被せる」形で実装し、いつでも一手で元に戻せる状態を保つことです。
この記事では、長年運用されてきたテーマ＋ページビルダーのサイトを、この方式で本番改修した実例をもとに、具体的な手順と判断基準を解説します。
結論：デザイン改修は「上書き」ではなく「被せる」
WordPressのデザイン改修には、大きく3つのやり方があります。
- テーマを新しいものに入れ替える
- 既存ページの本文やテーマファイルを直接書き換える
- 既存データに触れず、独立したプラグイン（またはCSS層）として変更を被せる
正解は3です。理由はひとつで、3だけが「即座に、確実に、元へ戻せる」からです。
テーマの入れ替えは、ページビルダーで組んだレイアウト、ウィジェット、カスタム投稿の表示など、テーマに依存していたものが広範囲に崩れます。本文の直接書き換えは、書き換えた瞬間に「変更前」が消えます。どちらも、公開してから「イメージと違う」となったときに、戻す作業自体が第二の工事になります。
被せる方式なら、プラグインを停止するだけで改修前の表示に戻ります。データベース上の元データは最初から無傷だからです。
なぜ「戻せること」を最優先にするのか
デザインの改修が通常の機能追加と決定的に違うのは、成否を決めるのが技術ではなく「好み」だという点です。
実際にあった例を挙げます。都内の保育施設のサイトで、既存テーマ＋ページビルダーの構成を維持したまま、新デザイン一式をプラグイン方式で本番反映しました。事前にプロトタイプを重ね、表示検証も通した上での公開です。それでも、最終的な決裁者の好みには合いませんでした。
ここで効いたのが可逆設計です。プラグインを管理画面で停止しただけで、その場で改修前の表示に完全復元できました。既存ページの削除も本文の上書きもしていなかったため、復旧作業も、データの修復も、一切発生していません。その後は方針を「デザインの骨格は元のまま、内容を段階的に直す」に切り替え、同じ被せる方式で10回以上の本番反映を重ねました。どの版も停止・差し戻しが可能な状態を保っています。
デザインの好みは、制作側がどれだけ検証しても、最後は相手が見て初めて確定します。「気に入られなかったら戻せばいい」を仕組みで保証しておくことは、制作側と発注側の双方を守る保険です。
実例：改修前のサイトはどんな状態だったか
対象サイトの改修前の実測値です。長期運用サイトの典型的な状態だと思います。
- トップページの本文データ約83KB、ページビルダーの要素109個、画像ウィジェット22個
- ページ固有のCSSが約70KB
- ページビルダーの旧形式レイアウトと新形式が混在
- PC用・スマホ用に同じ内容の要素が複製され、片方ずつ非表示にする作りが多数
- トップページにH1見出しがなく、H2が15個
この状態でテーマを入れ替えれば、確実に広範囲が壊れます。逆に、この状態でも「被せる」方式なら、既存の構造には触れずに見た目と情報設計を段階的に改善できます。
手順：上書きしない改修の5ステップ
実際の改修は、次の順番で進めます。
1. 現状を数字で読み取る
管理画面を触る前に、REST APIやソース確認で「本文サイズ・要素数・見出し構造・CSS量」を記録します。改修の範囲を決める根拠になり、後で効果を比較する基準にもなります。
2. サイト全体のバックアップを取る
被せる方式でも、公開前のフルバックアップは省略しません。実例ではAll-in-One WP Migrationでサイト全体（約1GB)を取得してから作業しています。可逆設計は保険の1枚目、フルバックアップは2枚目です。保険は重ねて掛けます。
3. 変更は独立したプラグインとして実装する
デザイン変更・文言変更・ページ追加を、ひとつの自作プラグインにまとめます。守るルールは3つです。
- 既存ページの本文・テーマファイル・ページビルダーのデータを書き換えない
- 表示の差し替えは、出力段階でのフィルタやCSS・テンプレートの追加で行う
- 新しい固定ページが必要な場合も、既存ページの改変ではなく追加で対応する
4. 版ごとに番号を付け、変更前バックアップを残す
プラグインにはv1.0、v1.1とバージョン番号を付け、本番反映のたびに「変更前の状態」を別に保管します。これで「ひとつ前に戻す」「最初まで戻す」の両方が選べます。CSSの読み込みURLにバージョンを含めておくと、公開側からどの版が動いているか一目で確認できます。
5. 反映のたびに実測で検証する
反映後は毎回、次を機械的に確認します。
- 主要URLがすべてHTTP 200を返すか
- スマホ幅（例えば390px）で横はみ出しがないか
- ログインしていない状態（匿名アクセス）で新しい版のCSSが配信されているか
特に3点目は重要です。ログイン中の画面はキャッシュや権限の影響で、訪問者が見ている画面と違うことがあります。
想定しておくべき落とし穴
被せる方式で実際に起こりうるトラブルと、予防策です。
文言の変更で、置き換え処理が静かに外れる。 出力を条件判定で差し替える実装は、判定に使った文字列やページ名が後から変わると、エラーも出さずに機能しなくなります。バージョン番号の露出と反映後の実測検証をセットにしておけば、「効いていない」ことにその場で気づけます。
固定ページよりカスタム投稿の表示が優先されるURLがある。 ページIDだけで対象を判定していると、アーカイブページなどで旧表示が残ります。IDとURLの両方で判定するのが安全です。
ページビルダーのページは「本文」を見ていない。 WordPressの投稿本文を書き換えても表示が変わらないのは、ページビルダーが別の場所にデータを持っているためです。だからこそ、その場所ごと書き換えるのではなく、出力に被せる方式が安全に働きます。
全面リニューアルとの使い分け
被せる方式が万能というわけではありません。判断基準を整理します。
| 被せる改修 | 全面リニューアル | |
|---|---|---|
| 向くケース | 構造は活きている・段階的に直したい・運用を止められない | 構造自体が破綻・CMS移行を伴う・ブランドを刷新する |
| リスク | 低い（停止で全戻し） | 高い（戻すのも工事） |
| 費用感 | 小〜中。範囲を区切って積み上げ | 大。一括 |
| 公開後の方向転換 | 版単位で戻せる | 実質的に作り直し |
目安として、「いまのサイトに、活かしたい資産（写真・コピー・検索順位・更新運用）が残っているか」で判断するとよいです。残っているなら被せる改修、資産ごと作り直すべき状態なら全面リニューアルです。
よくある質問（FAQ）
Q. テーマを変えずに、どこまでデザインは変えられますか？
見た目に関わる部分は、配色・見出し・カードや枠の造形・写真・レイアウトまで、ほぼ全域を変えられます。実例では、ページの新設、ヘッダーのメニュー構成の変更、写真20枚以上の差し替え、装飾の刷新までを、すべて元データに触れずに反映しました。逆に、URL構造やCMS自体を変えるような変更は、この方式の守備範囲を超えるため、全面リニューアルとして計画すべきです。
Q. 「被せる改修」は普通の改修より高くつきませんか？
つきません。むしろ範囲を区切って段階的に発注できるため、初期費用は全面リニューアルより小さく始められます。注意すべきは金額よりも発注時の確認事項で、「元に戻せる作りになっていますか」「変更前のバックアップは版ごとに残りますか」の2点を制作会社に確認してください。ここが曖昧な見積もりは、上書き方式で作られる可能性があります。
Q. 本当に元へ戻せるのですか？
戻せます。実例では、全面的な新デザイン版を本番公開したあと、決裁者の好みに合わないと分かった時点で、プラグインの停止操作だけで改修前の表示へ復元しました。復旧のための追加作業はゼロです。ただしこれは「元データを上書きしない」実装を最初から守っていた場合の話です。上書きしてしまった後から戻せる仕組みは作れないため、方式の選択は着手前に決める必要があります。
まとめ
- テーマを変えずにデザインは今風にできる。正解は「上書きせず被せる」プラグイン方式
- デザインの成否は最後は好みで決まる。だから停止ひとつで全て戻せる状態を仕組みで保証する
- フルバックアップ・版番号・変更前保管・反映後の実測検証をワンセットで運用する
- 活かせる資産が残っているなら被せる改修、構造ごと破綻しているなら全面リニューアル
graciautoでは、長期運用中のWordPressサイトの「壊さない改修」を、現状の読み取りから可逆設計・本番検証まで一貫して行っています。テーマ変更やリニューアルを迷っているサイトがあれば、まず現状の資産がどれだけ活きるかの診断からご相談ください。