TL;DR: WP STAGING の Push ウィザードは、Staging で行った変更 — ファイル、データベーステーブル、またはその両方 — を本番サイトにコピーします。まず本番サイトを Backup し (ステップ 1)、ステップ 2〜3 で Push する内容を選択して、Push を開始してください。Push が失敗した場合は、下のトラブルシューティングセクションをご覧ください。
この記事では、Staging サイトを本番に Push する方法と、WP STAGING | PRO を使って Staging サイトから変更を移行する方法を説明します。まだ Staging サイトを作成していない場合は、このガイドに従う前に WordPress の Staging サイトを作成する方法をご覧ください。
WP STAGING の無料版で Staging サイトを本番サイトに移行したい場合は、Push ウィザードが利用できないときの代替の移行方法についてこの記事をお読みください。
何を Push する必要がありますか
Push ウィザードを開く前に、本番に何を移すか決めてください。これによって必要なステップが変わります。
| 目的 | データベースを Push? | ファイルを Push? | 移動先 |
|---|---|---|---|
| 新しい投稿・メニュー・Plugin 設定をデプロイする | はい | 任意 | データベースの変更のみを Push する |
| Theme または Plugin の更新をデプロイする | いいえ | はい | ファイルのみを Push する |
| サイト全体: ファイル + データベースをまとめて | はい | はい | Staging サイト全体を本番に Push する |
| 特定のテーブルのみ (例: WooCommerce の注文を除外) | はい (選択的) | 任意 | ステップ 2: データベーステーブルを選択する |
動画: WordPress の Staging サイトを本番サイトに移行する
下の動画では、WP STAGING | PRO が Staging サイトから本番サイトへどのようにデータを Push するかを紹介しています。
WP STAGING | PRO は、すべてのメディアファイル、Theme、 Plugin、そして データベースのデータを WordPress の Staging サイトから本番サイトへ Push できます。
豆知識: WP STAGING が Staging サイトを本番サイトへどのように移動するかの基本的な技術的理解と、ファイルとデータベースデータの違いについては、以下の記事をお読みください:
Contents
Push 前のプリフライトチェックリスト
Push ウィザードを実行する前に、以下のすべてを確認してください:
- 本番サイトが公開されていて、その URL (例:
https://example.com) でアクセスできること。 - Staging サイトが WP STAGING で作成されており、デプロイしたい変更が含まれていること。
- WP STAGING | PRO が本番サイトにインストール・有効化されていること。
- Staging と本番の WordPress コアのバージョンが同一であること。
Push を開始する前に、必ず本番サイトを Backup してください。Backup があれば、Push 中に何か問題が起きても数分以内に本番を復元できます。
Staging サイト全体を本番に Push する
ファイルとデータベーステーブルの両方を 1 回の操作で Push したい場合は、この方法を使ってください。
ステップ 1: 本番サイトと Staging サイトを Backup する
WP STAGING | PRO に組み込まれた Backup ツールを使って、Push を開始する前に本番サイトを Backup してください。
WP STAGING > Backup & Migration > Create New Backup に移動し、名前を入力して Start Backup をクリックします。Backup が完了したら、Actions > Download からローカルにコピーを保存しておきます。
ステップ 2: データベーステーブルを選択する
本番サイト > WP STAGING > Start / STAGING に移動します。
複数の Staging サイトがある場合は、移行したいものを選択してPush Changes ボタンをクリックしてください。
Database Tables をクリックして、Staging から本番に Push したいテーブルをすべて選択します。選択されたテーブルは、本番サイト上の対応するテーブルを完全に上書きします。
Push する前に含めるべきデータベーステーブルを把握するには、WordPress データベース構造リファレンスを参照してください。すべてのコアテーブルと、それぞれが保存している内容が一覧になっています。
特定のテーブルを Push から除外するには、選択を解除します。
WooCommerce のようなショップシステムをお使いの場合、本番サイトの注文や顧客データを上書きしたくはないはずです。以下のリンクには、WooCommerce のデータベーステーブルの説明、ショップの取引データを上書きしないために除外する必要があるテーブル、そして WooCommerce の注文やユーザーデータを Staging サイトにエクスポート・インポートする方法が記載されています。
注: Plugin や Theme のファイル更新だけを Push する場合は、データベーステーブルを Push する必要はありません。ただし、Staging で設定を変更したり、投稿を作成したり、メニューを割り当てたり、新しい Plugin をインストールした場合、これらの操作はデータベースに記録されているため、該当するテーブルを Push する必要があります。
ステップ 3: Plugin・Theme・メディアファイルを選択する
Select Files をクリックし、本番にコピーしたいすべての Plugin・メディア・Theme フォルダを選択してください。
テキストエリアに完全な絶対パスを入力して、追加のフォルダを指定することもできます。
ステップ 4: テーブルまたはファイルを Push から除外する
Push 中に本番サイトから削除される内容は、2 つのオプションで制御します:
- 本番サイト上のすべての Plugin をアンインストール — Staging にもう存在しない Plugin を本番から削除します。
- wp-content/uploads フォルダを削除 — Staging の uploads フォルダをコピーする前に、本番の uploads をクリアします。
両方のオプションを無効にしている場合、本番からは何も削除されません。Staging で削除された Plugin は本番では無効化されますが、インストール済みのまま残り、手動で再有効化できます。
ステップ 5: Push を開始する
Push Staging Site to Live site をクリックして Push を開始します。
Push が完了したら、サイトを再読み込みしてください。Staging での変更がすべて本番サイトに反映されます。
注: WordPress は、フル Push の後に再度ログインを要求することがあります。これは Staging データベースのセッションデータが本番のセッションを置き換えたときに発生するもので、正常な動作です。
データベースの変更のみを Push する
変更がコンテンツ・設定・Plugin の設定に限られていて、Theme や Plugin のファイルを一切変更していない場合は、データベーステーブルだけを Push してください。
Push ウィザードで Database Tables を開き、変更を含むテーブルだけを選択します。Select Files ではすべてのフォルダの選択を解除したままにしておきます。この方法は速く、リスクも少なく、本番ファイルには手をつけません。
Push する前に含めるべきデータベーステーブルを把握するには、データベース構造リファレンスを参照してください。すべての WordPress コアテーブルと、それぞれが保存している内容が一覧になっています。
WooCommerce ユーザーへ: ショップの Staging サイトを Push するときは、WooCommerce の注文と顧客テーブルを除外してください。これらのテーブルを Push すると、本番の取引データが上書きされてしまいます。除外すべき具体的なテーブルは、ステップ 2 の WooCommerce のコールアウトに記載されています。
ファイルのみ (Theme・Plugin・メディア) を Push する
Staging で Theme や Plugin を更新・テストして動作確認が取れた場合は、変更したファイルだけを Push してください。データベースの Push は不要です。
Push ウィザードで Database Tables をすべて選択解除のままにします。Select Files では、変更したフォルダだけを選びます。例えば、Theme 更新の場合は wp-content/themes/your-theme、特定の Plugin の場合は wp-content/plugins/plugin-name です。
Push が終わったら、本番で動作させたくない開発専用のツールを Staging にインストールしていた場合は、本番へ Push した後に Staging 専用の Plugin を手動で削除してください。
Push が失敗した場合の対応
当社のサポートキューでは、Push が停止したりエラーが発生する原因の大半は、次の 4 つのカテゴリに収まります。
大きなデータベースで Push が停止する
データベーステーブルのコピー中に Push が固まったりタイムアウトしたりする場合、最もよくある原因は MySQL の max_allowed_packet 設定が小さすぎることです。この上限は単一のデータベースクエリの最大サイズを制御し、テーブルの 1 行がこれを超える (シリアライズされたオプション値や base64 画像が埋め込まれた投稿が典型的な原因) と、Push は処理の途中で停止します。
対処: MySQL 設定で max_allowed_packet を上げるか、ホスティング業者に上げてもらうよう依頼してください。あわせてPush を中断させる可能性のある PHP 設定の上限もご覧ください。memory_limit や max_input_vars といったディレクティブも、大きなメディアライブラリを Push する際にタイムアウトを引き起こすことがあります。
Push 後に Mixed Content や壊れた URL が発生する
Push 後にライブサイトで画像が壊れていたり Mixed Content の警告が表示される場合、データベースの一部の行に Staging ドメインがまだ残っています。WP STAGING は Push 中に URL を置換しますが、カスタム Plugin のテーブル内のシリアライズされた値は見落とされることがあります。
対処: データベースの検索・置換を実行して、Staging ドメインを本番ドメインに置き換えてください。本番への Push 後に発生する REST API エラーも、同じ URL 不一致が原因であることが多く、ドメイン置換を修正すれば両方の問題が解決します。
Push 後に管理者がログインできない
データベース全体を Push した後で本番の管理画面にログインできない場合、Staging のユーザーテーブルが本番のものを置き換えており、元の管理者の認証情報がもう一致しなくなっています。
対処: ホスティング業者のデータベース管理ツール (例えば phpMyAdmin) を使って、MySQL で直接管理者パスワードをリセットしてください。あるいは、まず Staging サイト側のログイン問題を解決してから、もう一度 Push してください。
Push 後にホワイトスクリーンや致命的エラーが発生する
Push 直後のホワイトスクリーンは、通常、Staging で動いていた Plugin が本番のサーバー環境と互換性がないことを意味します。多くの場合、PHP バージョンの違いやサーバー設定の不一致が原因です。
WordPress のデバッグログを有効にして Plugin を特定してください。wp-config.php に define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); を追加します。エラーログは wp-content/debug.log に出力されます。互換性のない Plugin を特定して修正したら、デバッグ定数は削除してください。
Push 後の検証チェックリスト
Push を完了とみなす前に、以下のチェックをひととおり行ってください:
- [ ] 本番のトップページを訪問 — 新しいコンテンツやデザインが表示されることを確認します。
- [ ] 本番の管理画面にログイン — 認証情報が機能することを確認します。
- [ ]
https://your-domain.com/wp-json/を確認 — JSON レスポンスが返れば REST API は正常です。 - [ ] ブラウザの開発者ツール → コンソールを開く — Mixed Content の警告が出ていないこと。
- [ ] フォーム・チェックアウトフロー・重要な機能をテストします。
- [ ] 本番で動作させてはいけないものがある場合は、本番への Push 後に Staging 専用の Plugin を手動で削除します。
- [ ] コンテンツに大きな変更があった場合は、Google Search Console で再インデックスを依頼してください。
