ステージング環境で直した内容を本番へ反映するとき、丸ごと上書きすると本番側で増えていたデータが消えます。
記事、コメント、注文、会員、問い合わせの記録は、ステージングを作ったあとも本番側で増え続けています。
ここでは、何を反映して何を触らないかを先に決めるための考え方を整理します。
内容は2026年9月20日にWordPressの公開ドキュメントを確認したものです。
本番とステージングで、変わるものが違う
反映の事故は、両方で同じものが変わっていると思い込むところから起きます。
実際には、変わっている場所が分かれています。
| 中身 | ステージングで変わる | 本番で変わる |
|---|---|---|
| テーマやプラグインのファイル | 変わる | ふつうは変わらない |
| テーマの設定やカスタマイザー | 変わる | 変わる場合がある |
| 記事・固定ページ | 変わる場合がある | 変わる |
| コメント・問い合わせ | 変わらない | 増え続ける |
| 注文・会員などの記録 | 変わらない | 増え続ける |
| メディア（画像） | 増える場合がある | 増える |
上の行はステージングから持っていきたいもの、下の行は本番側を残したいものです。
この線引きをしないまま、データベースを丸ごと入れ替えると、下の行が消えます。
反映の方法は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の置き換えが要るなら、使う道具を決める
- 反映する時間帯を決める（投稿や注文が少ない時間）
本番で更新されるデータを反映対象に含める場合、投稿・注文が少ない時間帯を選ぶだけでは更新の競合を防げません。ステージングを作ったあとに本番で増えたデータを残す方法を決め、作業中の投稿・注文・外部連携などの書き込みを止める必要があるかも確認します。停止しても過去の増分はステージングに入らないため、古いデータベースでの上書きを避ける判断は別に必要です。
2番と3番を紙に書けないうちは、反映を始めないほうがよいです。
どちらも言葉にできていれば、上書きしてよい範囲が自然に決まります。
反映したあとに確かめること
| 確かめる場所 | 見るもの |
|---|---|
| トップページ | 崩れていないか、404になっていないか |
| 記事の個別ページ | 本文と画像が出ているか |
| 設定の一般 | 2つのURLが本番のものになっているか |
| カスタマイザー | 設定が消えていないか |
| ウィジェット | 並びが残っているか |
| 問い合わせフォーム | 送信できるか |
| 最近の投稿・コメント | 反映の前に増えた分が残っているか |
最後の行は、上書きで消えていないかを見るためのものです。
反映の直前に最新の投稿とコメントの件数を控えておくと、その場で比べられます。
まとめ
- ステージングで変わるものと本番で増えるものは別なので、先に線を引く
- ファイルだけで済むなら、データベースは触らない
- wp-config.php にURLを書くと、設定画面から変更できなくなる
- functions.php に書く直し方は、残さずに消す
- URLの置換は、シリアライズに対応した道具を使う
- 反映のあとは、増えていたデータが残っているかまで見る
2026年9月30日にWordPress公式の移行ドキュメントを再確認し、置換時の注意を見直しました。この記事では本番データの移行操作は行っていません。
2026年10月11日の確認は、公開本文とWordPress・WP-CLIなどの公式資料の照合、掲載コードの静的確認までです。WordPress・SWELL・移行プラグインの実環境とバージョン、データ移行・復元の結果、PC・スマートフォンの表示は未確認です。
サイトURLの扱いはWordPress公式のMigrating WordPressにまとまっています。
WordPressの運用はWAZAのまとめにも置いています。
