ステージング環境で直した内容を本番へ反映するとき、丸ごと上書きすると本番側で増えていたデータが消えます。
記事、コメント、注文、会員、問い合わせの記録は、ステージングを作ったあとも本番側で増え続けています。
ここでは、何を反映して何を触らないかを先に決めるための考え方を整理します。
この記事は通常のWordPress単一サイトを対象にした反映計画の整理です。
2026年10月20日に公式の移行・URL置換資料を再照合しました。
マルチサイトや各ホスティングの自動反映機能は、対応範囲を別に確認してください。
本番とステージングで、変わるものが違う
反映の事故は、両方で同じものが変わっていると思い込むところから起きます。
実際には、変わっている場所が分かれています。
| 中身 | ステージングで変わる | 本番で変わる |
|---|---|---|
| テーマやプラグインのファイル | 変わる | 自動更新や本番での修正により変わる場合がある |
| テーマの設定やカスタマイザー | 変わる | 変わる場合がある |
| 記事・固定ページ | 変わる場合がある | 変わる |
| コメント・問い合わせ | 変わらない | 増え続ける |
| 注文・会員などの記録 | 変わらない | 増え続ける |
| メディア（画像） | 増える場合がある | 増える |
この表は変更箇所を洗い出すための目安です。
テーマやプラグインも本番側で更新されるため、上の行を無条件に上書きしてよいわけではありません。
反映直前に両環境の版と変更内容を照合します。
この線引きをしないまま、データベースを丸ごと入れ替えると、下の行が消えます。
反映の方法は2通りある
| 方法 | 何を持っていくか | 向いている変更 |
|---|---|---|
| ファイルだけ反映 | テーマやプラグインのファイル | CSSファイルやテンプレートファイルの修正 |
| データベースも反映 | 設定や記事も含む | 設定の変更を伴うもの |
ファイルだけの変更は、対象ファイルを限定して反映します。
「追加CSS」やカスタマイザーなどデータベースに保存される設定は、CSSという名前でもファイル転送だけでは反映されません。
データベースまで反映が必要な場合は、何が入っているテーブルなのかを先に確かめます。
プラグインによっては、設定が投稿のテーブルに入っていることもあります。
同じテーブルに、反映したい設定と本番で増えた記事などが混在することがあります。
テーブルを選んで転送できても、変更箇所だけを自動で統合できるとは限りません。
本番の最新データを基準に、必要な設定や記事だけを反映し、共有テーブルを丸ごと上書きしない方法を選びます。
画像を反映するときも、本番のアップロードフォルダーを丸ごと削除・置換しないようにします。
追加するファイルと、添付ファイル情報など関連するデータの反映範囲を決め、本番で増えた画像を残します。
URLの置き換えで起きること
ステージングと本番ではURLが違うため、データベースを移すとURLの置き換えが要ります。
WordPressの公開ドキュメントでは、設定の一般にある2つの項目が説明されています。
| 項目 | 意味 |
|---|---|
| サイトアドレス（URL） | 読者がブラウザーに入れて到達するアドレス |
| WordPressアドレス（URL） | WordPressの本体ファイルが置かれているアドレス |
どちらも https:// を含め、末尾にスラッシュを付けないと書かれています。
この2つを変えたあとにサイトが正しく動かなくなり、直す入り口が分からなくなることがある、とも説明されています。
wp-config.php で固定する方法の副作用
公式ドキュメントには、wp-config.php に書いて固定する方法が挙げられています。
define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );この方法は、WordPressが使うURLを定数で固定します。
データベースに保存された値は更新されず、定数を削除するとデータベースの値に戻ります。
常に最適な修復方法とは限りません。
この書き方をすると、設定画面の一般からは変更できなくなる、という副作用も説明されています。
ステージング側でこの記述を入れたまま本番へファイルを移すと、本番のURLがステージングのものに固定されます。
ファイルを反映する前に、URL定数の値が本番の構成に合っているかを確かめます。
2つのURLが異なる構成もあるため、同じ値に揃えるとは限りません。
wp-config.php は本番の接続先など環境ごとの設定を保ち、ステージングのファイルで丸ごと上書きしないようにします。
functions.php に書く方法は残さない
公式ドキュメントには、テーマの functions.php に一時的に書いて直す方法も載っています。
update_option( 'siteurl', 'https://example.com' );
update_option( 'home', 'https://example.com' );同じ箇所に、このコードを functions.php に残さないよう注意が書かれています。
直ったあとに消す前提の記述なので、反映の対象に紛れ込ませないでください。
置き換えで壊れるもの
データベースの中の文字列を置き換えるとき、単純な検索と置換では壊れる場所があります。
WordPressは一部の値をシリアライズという形式で保存しており、文字列にはバイト数などの情報が一緒に記録されています。
単純な置換でURLだけを変えると、記録された長さと合わなくなり、設定が読めなくなる場合があります。
そのため、置換にはシリアライズを理解する道具を使います。
- WP-CLIの search-replace を使う
- シリアライズに対応した置換プラグインを使う
- 対応する道具を使えない場合は、単純な文字列置換を実行せず、対応できる作業環境を用意する
置換するテーブルと列も限定します。
本番で既に公開している投稿のGUIDは識別子なので、古いURLが含まれていてもURL置換の対象から外します。
WP-CLIでは、対象範囲と除外列を指定したうえで、--dry-run により保存せずに結果を確認できます。
指定方法はWP-CLI公式のsearch-replaceで確認してください。
壊れたことに気づきにくいのは、テーマのカスタマイザーやウィジェットの設定です。
URLの置換が必要な場合でも、--dry-runは置換範囲と件数を保存せず確認する機能であり、移行後の動作やデータ統合の正しさまで保証しません。
作業ディレクトリ・接続DB・対象テーブルを確認し、まず隔離した複製環境で結果を確認します。
反映の前に決めておくこと
- 本番のバックアップを取り、戻せることを確かめる
- ステージングで変えたものを一覧にする（ファイルか、設定か、記事か）
- 本番側で増えているデータがどれかを書き出す
- ファイルだけで済むかどうかを決める
- URLの置き換えが要るなら、使う道具を決める
- 反映する時間帯を決める（投稿や注文が少ない時間）
本番で更新されるデータを反映対象に含める場合、投稿・注文が少ない時間帯を選ぶだけでは更新の競合を防げません。
ステージングを作ったあとに本番で増えたデータを残す方法を決め、作業中の投稿・注文・外部連携などの書き込みを止める必要があるかも確認します。
停止しても過去の増分はステージングに入らないため、古いデータベースでの上書きを避ける判断は別に必要です。
2番と3番を紙に書けないうちは、反映を始めないほうがよいです。
変更一覧には「対象ファイル/設定」「反映方法」「本番で保持するデータ」「確認方法」「失敗時に戻す範囲」を1行ずつ記入します。
保存先や関連データが分からない項目は、反映対象に含める前に調べます。
戻す判断も先に決めます。
たとえば主要ページが表示できない、注文や会員データの欠落がある、フォームの送信先が違う場合は、そのまま運用再開せず差分とログを保存して担当者に確認します。
バックアップを丸ごと復元すると、取得後に増えた注文や投稿まで巻き戻ります。
ファイルだけを戻せるか、DBの復元が必要か、復元までの増分をどう保全するかを分けて決めてください。
バックアップが存在するだけでなく、隔離環境で復元できるかを確認します。
反映したあとに確かめること
| 確かめる場所 | 見るもの |
|---|---|
| トップページ | 崩れていないか、404になっていないか |
| 記事の個別ページ | 本文と画像が出ているか |
| 設定の一般 | 2つのURLが本番のものになっているか |
| カスタマイザー | 設定が消えていないか |
| ウィジェット | 並びが残っているか |
| 問い合わせフォーム | 担当者が許可したテスト宛先で、画面の完了表示と実際の受信を確認。二重送信や誤通知がないかも確認 |
| 最近の投稿・コメント | 反映の前に増えた分が残っているか |
最後の行は、上書きで消えていないかを見るためのものです。
件数だけでは、同じ件数のまま内容が置き換わったことを見落とします。
直前の代表的な投稿・コメント・注文のID、更新日時、状態を控え、反映後の同じデータと比較します。
個人情報は公開メモやスクリーンショットに残さないようにします。
画像はファイルが存在するだけでなく、本文から正しい画像を参照しているかも確認します。
ECや会員サイトでは注文・決済・権限など、そのサイト固有の主要機能を検証項目へ追加してください。
実注文や課金を発生させるテストは、事前に確認した方法で行います。
ステージング用のnoindex、メール停止、テスト用APIキーなどが本番へ混入していないかも確認します。
設定を一律に解除せず、本番で意図した設定と照合します。
最終的に、反映した変更・保持できたデータ・確認結果・残課題を記録して作業を閉じます。
まとめ
- ステージングで変わるものと本番で増えるものは別なので、先に線を引く
- ファイルだけで済むなら、データベースは触らない
- wp-config.php にURLを書くと、設定画面から変更できなくなる
- functions.php に書く直し方は、残さずに消す
- URLの置換は、シリアライズに対応した道具を使う
- 反映のあとは、増えていたデータが残っているかまで見る
2026年9月30日にWordPress公式の移行ドキュメントを再確認し、置換時の注意を見直しました。
この記事では本番データの移行操作は行っていません。
2026年10月20日の確認は、公開本文とWordPress・WP-CLIの公式資料の照合、掲載コードの静的確認までです。
WordPress・SWELL・移行プラグインの実環境とバージョン、データ移行・復元の結果、PC・スマートフォンの表示は未確認です。
サイトURLの扱いはWordPress公式のMigrating WordPressにまとまっています。
WordPressの運用はWAZAのまとめにも置いています。
