WP STAGINGを使ってWordPressサイトを作成していると、そのサイトを本番環境へ移行したくなる場面がよくあります。
このステップバイステップガイドでは、無料版を使った手動の移行手順を、順番どおりに、何も省略せずに解説します。
データベースやファイルの扱いに慣れている技術的な知識があることを確認してください。このチュートリアルは分かりやすいですが、PROバージョンならワンクリックで「push changes」機能が使えるので、ステージングサイトを送り出すのははるかに簡単です。
したがって、WP STAGING | PROでWordPressのステージングサイトをワンクリックで自動コピーしたい場合は、代わりにこちらの記事をお読みください。TL;DR: このガイドでは、無料版のWP STAGINGプラグインを使った手動の移行方法を解説します。FTPアクセス、データベース管理ツール（phpMyAdminまたはAdminer）、および wp-config.php の直接編集が必要です。データベース接頭辞の変更を自動で処理し、ステージングサイトをそのまま残せるワンクリック移行を希望する場合は、WP STAGING | PRO のPush Wizardをご利用ください。
このガイドが適しているケース
作業を始める前に、自分の状況にどちらの方法が合うかを確認してください：
| 手動の無料版（このガイド） | WP STAGING | PRO Push Wizard | |
|---|---|---|
| 手間 | 多い — FTP転送、データベースの検索置換、wp-config編集 | 少ない — ボタン1つ |
| 人為的ミスのリスク | 高い — 手順を1つでも飛ばすとサイトが壊れる可能性 | 低い — 自動化 |
| 対応サイト規模 | 制限なし。ただし大規模サイトはFTP転送中にタイムアウトする可能性あり | 制限なし |
| DB接頭辞の変更 | 手動 — 自分で wp-config.php を編集 | 自動 |
| 移行後のステージング | 利用不能になるため、新しく作成する必要あり | そのまま残る |
先にPro版のPush Wizardの動作を確認したい場合は、こちらの動画をご覧ください：
以下の手順を注意深くお読みください。示された手順をひとつも飛ばさないようにしてください。サイトが 利用不能 になる恐れがあります！
開始前の準備
このチュートリアルの前提条件：
- 本番運用中のライブサイト1つ、例：https://host.com
- WP STAGINGまたはWP STAGING | PROで以前に作成したステージングサイトが、https://host.com/staging のようなサブフォルダにあること
- ライブサイトで WP STAGING プラグインが有効化されていること
- ライブサイトで Search And Replace プラグインが有効化されていること
（WP STAGING | PRO では不要） - ライブサイトにバックアッププラグインがインストールされていること。WP STAGING には、最も効率的でモダンなバックアップソリューションのひとつがすでに付属しています — 多くのバックアッププラグインより高速で、CPU負荷も低いのが特長です。
ステップ1 – 両方のサイトをバックアップする
変更を加える前に、本番サイトとステージングサイトの両方のバックアップを取ってください。
バックアッププラグインのファイル選択画面では、ステージングサイトのサブフォルダを含めてください。また、接頭辞 wpstg_ で始まるデータベーステーブルもすべて選択してください。
巨大なサイトでデータベースの行数が数百万件あったり、バックアップ作成中の読み込み時間のスパイクを避けたい場合は、WP STAGING | PRO の利用を検討してください。最も洗練されたバックアップソリューションのひとつが標準搭載されています。
ステップ2 – ステージングのファイルを本番サイトへコピーする
FileZilla のようなFTPプログラムを使ってサーバーに接続します。ステージングサイトのサブフォルダから本番サイトのルートに、以下のフォルダをコピーしてください：
wp-content/uploadswp-content/pluginswp-content/themes
ステップ3 – データベースを移行する
ステージングのデータベースを本番に移行する方法は3つあります：
- オプション1 — とても簡単： WP STAGING | PRO を使い、ステージングサイト全体をワンクリックで自動的にライブへクローンします。
- オプション2 — 簡単： ステージングのデータベーステーブルに対して手動で検索置換を行い、本番ではそのテーブルを使うようWordPressに指示します。ライブサイトの元のデータベーステーブルは上書きされず、いつでも復元できます。下の手順に従ってください。
- オプション3 — 上級： WP Migrate DBなどの専用DB移行プラグイン、あるいはステージングのデータベースをライブへ移行できるその他のツールを使います。
ステージングのURLを検索置換する
この手順では、ステージングデータベース内のすべての内部URLについて、ステージングのサブフォルダパスをライブのドメインに置き換えます。
まだの場合は、Search And Replace プラグインをインストールしてください。ツール > Search & Replace に移動します。
ここではステージングサイトが http://yoursite.com/staging にあると仮定します。
Search for 欄にステージングのパスを入力します：
//mysite.com/stagingReplace with 欄にライブのパスを入力します：
//mysite.com必ず 正確に 作業してください。文字列は寸分違わず入力します！
– URLの末尾にスラッシュを 付けないでください！
– 検索文字列に HTTP:// や https:// を追加しないでください
少しでもスペルミスがあると、ステージングサイトや本番サイトが 壊れます。
ステージングのテーブル接頭辞で始まるデータベーステーブルだけを選択します — 通常は wpstg[0]_ です。正しい接頭辞は、WP STAGINGのステージングサイト一覧で確認できます：
古いバージョンのWP STAGINGを使っている場合は、FTPでステージングサイトの wp-config.php を開いて接頭辞を確認してください：
path_to_wordpress/staging_name/wp-config.php他のすべてのテーブルはライブサイトや他のステージングサイトに属しており、いかなる方法でも変更してはいけません！
実データを変更せずに設定を確認するため、まずドライランを実行してください。ドライランが成功したら、ドライランの選択を外して、本番の置換を実行します。
wpstg_is_staging_site フラグを削除する
WP STAGINGは、ステージング環境を識別して認証画面を表示するために、データベースに wpstg_is_staging_site オプションを設定します。移行後にこの値を残したままにすると、管理ダッシュボードが空白になります。
phpMyAdminや Adminer などのデータベース管理ツールを使い、ステージングデータベースのテーブルから以下を検索します：
wpstg_is_staging_site該当する行を削除するか、値を false に設定します。
wp-config.php のテーブル接頭辞を更新する
最後の手順では、本番サイトの元のテーブルではなく、ステージングのデータベーステーブルを使うようWordPressに指示します。
FTPでライブサイトにログインしてください。設定ファイルは /path/to/wordpress/wp-config.php にあります。FileZilla などお好きなFTPクライアントを利用してください。
ファイルを右クリックして 編集 を選択します。$table_prefix をステージングのテーブル接頭辞に合わせて更新します。例：
$table_prefix = 'wpstg1_';
ファイルを保存します。ライブサイトを開くと、ステージングサイトの内容が表示されるようになります。
きれいなパーマリンクを再度有効にするには、WordPress管理画面の 設定 > パーマリンク に移動し、変更を保存 をクリックします。
FTPで古いステージングのサブフォルダを削除します：
path/to/wordpress/staging-name重要： 本番サイトはステージングのデータベーステーブルを使用するようになりました。新しいステージングサイトはあらためて作成してください — 古いステージングサイトはもう使用できません。
WP STAGINGユーザーのサポート経験から言うと、wp-config.php のデータベース接頭辞の変更がもっとも忘れられがちな手順です。FTPクライアントを閉じる前に必ず確認してください。
おめでとうございます — ステージングサイトをライブへ正常に移行できました。
プロ版は私たちの開発費用を賄うものであり、最高クラスのサポートが付いてきます！😊
よくあるトラブルと解決方法
サポートに寄せられる相談を見ると、移行後の問題の大半は次の3つの失敗パターンに集約されます。
wp-config.php のステージングのテーブル接頭辞が更新されていない
移行後の wp-config.php は、元の wp_ ではなくステージングのテーブル接頭辞（例：wpstg1_）を参照している必要があります。$table_prefix がまだ wp_ を指したままだと、WordPressは移行されたステージングのデータではなく、元のライブデータベースを読み込んでしまい、移行が反映されていないように見えます。
対処法： FTPで wp-config.php を再度開き、$table_prefix がSearch and Replaceの手順で選択した接頭辞と一致していることを確認してください。
wpstg_is_staging_site を削除していない — 管理画面が空白
wpstg_is_staging_site の行が削除されていないと、WordPressはそのサイトをステージング環境として検出し、管理ダッシュボードの代わりに空白の認証画面を表示します。
対処法： phpMyAdminやAdminerを開き、ステージングの接頭辞が付いた options テーブル（例：wpstg1_options）から wpstg_is_staging_site を検索し、該当の行を削除します。
siteurl と home が更新されていない — リダイレクトループや誤ったドメイン
検索置換の手順後も options テーブルの siteurl と home の値がステージングのサブフォルダを指したままだと、WordPressはすべてのリクエストをステージングのURLにリダイレクトしてしまいます。
対処法： phpMyAdminまたはAdminerで wpstg1_options テーブル（実際の接頭辞に置き換え）を開き、siteurl と home の行を探します。両方の値が、末尾スラッシュやサブフォルダなしで本番ドメイン（例：https://yoursite.com）を指していることを確認してください。
関連記事
