WordPressステージングをデータ損失なしで本番環境にプッシュする方法

ステージングの変更を本番環境に反映させた回数は数え切れないほどありますが、うまくいかなかったときはすべて同じ根本原因がありました。それは、上書きしようとしているものを確認せずにプッシュを急いだことです。

過去数時間（または数日）をステージングサイトでの変更構築に費やしたなら、おそらくそれらを本番環境に反映させる準備ができたでしょう。新しいテーマ、更新されたプラグイン、再設計されたページなど、何であれ、テストして動作することを確認しました。

それを本番サイトにプッシュするところで、事態は危険になります。

私はこのためにDuplicatorを使用しています。なぜなら、プロセス全体を完全に制御できるからです。ステージングから移行パッケージを構築し、どのデータベーステーブルを含めるかを正確に選択し、単一のボタンを信頼して正しい判断を任せるのではなく、自分の条件で本番環境にインストールできます。

その制御が重要です。不注意なプッシュは、新しい注文を消去したり、すべてのユーザーをログアウトさせたり、訪問者の前で本番サイトを壊したりする可能性があります。その間、あなたはそれを修正するために奔走しなければなりません。

このチュートリアルでは、WordPressのステージングサイトを本番環境にプッシュするために行うこと、そして人々を不意打ちする間違いについて説明します。

主なポイントは次のとおりです：

• ホストによって2つの主な方法があります。ホスティングプロバイダーの組み込みプッシュが利用可能であればそれを使用するか、利用できない場合はDuplicatorのバックアップと移行方法を使用します。これはホストに関係なく機能するためです。
• 完全なデータベースプッシュは、本番環境でのアクティビティを消去する可能性があります。ステージングを作成した後にサイトに追加された注文、コメント、またはサインアップは、プッシュ前にそれらのテーブルを除外しない限り上書きされます。
• タイミングは、人々が予想する以上に重要です。ステージングの作成とプッシュの間のギャップが長ければ長いほど、本番環境のデータはより危険にさらされるため、できるだけ早くプッシュしてください。

目次

ステージングを本番環境にプッシュする必要があるのはいつですか？

ステージングで行ったすべての変更を本番環境に反映させる必要はありません。違いを知ることで、不要なリスクを負うことを避けることができます。

本格的なプッシュが必要なのは次のとおりです。

• メジャーなテーマまたはプラグインのアップデートをテストし、正常に動作することを確認した
• 公開する準備ができた新しいページまたはコンテンツを作成した
• 構造的またはコードの変更を行った
• WordPressコアのアップデートを実行し、何も壊れていないことを確認した

見た目を確認するためだけに行った、どうせやり直す予定の互換性テストを実行した、または保持する予定のない変更を行った場合は、本格的なプッシュは必要ないでしょう。

私はステージングを意図的に壊す場所として扱っています。

本番環境へのプッシュは異なります。それはあなたがコミットする瞬間です。

すべてのプッシュには、データのオーバーライト、数分間のダウンタイム、または特定に時間のかかるURLの不一致など、いくつかのリスクが伴います。まだテストが完了していない変更に対して、それらのどれも価値はありません。

そのため、何かを触る前に、ステージングにあるものが実際に完了していることを確認してください。

開始する前に必要なもの

何かをプッシュする前に、これらを準備してください。このステップをスキップすると、20分のタスクが数時間のスクランブルに変わります。

• プッシュを開始する直前に取得した、本番サイトの新鮮なバックアップ
• 手動でファイルをアップロードしたり、何かを手作業で修正したりする必要がある場合に備えて、FTPまたはSFTPアクセス、またはホスティングアカウントのファイルマネージャー
• 手動での修正が必要な場合のフォールバックとして、phpMyAdminまたはホストのデータベースツールを介したデータベースアクセス
• ステージングで何が変更されたかの明確なリスト。これにより、プッシュしているものを正確に把握し、正しく反映されたかを確認できます。
• ステージングサイトにDuplicator Proがインストールされていること。次のセクションで移行パッケージを作成するために使用するためです。

本番サイトのバックアップは、このリストの中でスキップできない唯一の項目です。「プッシュは常に機能する」という理由でスキップする人がいますが、常に機能するわけではありません。

機能しない場合、そのバックアップは、サイトをゼロから再構築するのとあなたを隔てる唯一のものです。

ステージングを本番環境にプッシュするためのさまざまな方法

すべてのWordPressセットアップで同じツールが利用できるわけではなく、あるサイトで機能することが別のサイトに存在しない場合があります。ステップバイステップに入る前に、ホストやプラグインに応じて、利用可能なものを紹介します。

ホスティング提供のステージングプッシュ

WP Engine、Kinsta、SiteGround、Flywheelなどのホストは、ステージングプッシュツールをダッシュボードに直接組み込んでいます。ホストがこれを提供している場合、サーバーのセットアップに合わせて構築されているため、通常は最も速いオプションです。

トレードオフは、ホストのプランティアに含まれるものに限定され、一部のプランではまったく提供されないことです。

専用ステージングプラグインプッシュ

ステージング専用に構築されたプラグイン（WP Stagingなど）には、ファイルとデータベースの選択機能を備えた独自のプッシュボタンが含まれています。ステージングがすでに主なユースケースであった場合は、これはうまく機能します。

トレードオフは、この1つのタスク専用のプラグインをもう1つ追加することです。

バックアップと移行方法

これは私が使用する方法であり、このチュートリアルで詳細に説明する方法です。

ステージングサイトから移行パッケージをビルドし、含めるものを正確に選択して、本番環境にインストールします。Duplicatorのようなツールはこれをうまく処理します。

シングルプッシュボタンよりもいくつかの手順が必要ですが、ホストに関係なく機能します。また、上書きするものを最も細かく制御できます。

手動方法（FTPとphpMyAdmin）

ファイルとデータベーステーブルを手作業で1つずつコピーします。これは、他のツールが利用できない場合の最後の手段です。機能しますが、遅く、エラーが発生しやすいです。

ホストがステージングプッシュをサポートしているかどうかに依存せず、上書きしても安全なものをテーブルごとに決定できるため、バックアップと移行方法を好みます。

WordPressステージングサイトを本番環境にプッシュする方法

ステップバイステップで実行することを示します。

• Back up your live site first: Create a safety net so you can restore production in minutes if something goes wrong.
• Decide what you’re pushing: Determine whether you do a full site push or a selective push that protects live data like orders and comments.
• Create a migration package from staging: Package your staging site’s files and database into files Duplicator can install on production.
• Transfer the package files to the live server: Get the installer and archive onto your production server so the install can run.
• Run the installer on the live site: Install your staging changes onto production and updates the database to match.
• Verify the live site: Confirm everything works correctly before you walk away.

ステップ1：まず本番サイトをバックアップする

Backups aren’t optional. Before you touch production, you need a way back if anything breaks.

My favorite tool for the job is Duplicator. Since it’s also a migration plugin, it’ll help you protect your site, set up a staging area, and migrate changes back whenever you need them.

On your live site, open Duplicator and go to the Backups screen. Click the Add New button.

Name the backup something you’ll recognize later, like “pre-staging-push-backup.” Choose the Full Site backup preset to back up everything.

Click Next. Once you review any notices from the scan, build the backup.

Download both backup files. Store them somewhere off your server, like cloud storage or your local computer.

I prefer using Duplicator Cloud since it can restore your site even if it’s offline from a serious error.

Step 2: Decide What Data You’re Pushing

A full push replaces everything: files, themes, plugins, and the entire database. Use this when you’ve made major changes like a new theme or significant structural updates.

A selective push only updates specific files or database tables. Use this when you only changed a few things, since it protects live data your staging site doesn’t have, like new orders, comments, or user signups made on production since you started staging.

If you do a full database push, anything that happened on your live site after you created staging gets wiped out and replaced with staging’s older data.

Before you build your migration package in the next step, decide which tables matter.

If you’re not sure what changed on live since you started staging, check now. It’s a lot easier to ask, “Do I need this table?” before the push than to recover it after.

ステップ3：ステージングから移行パッケージを作成する

On your staging site, create a new backup with Duplicator. It’s the same process you used in Step 1, just on staging this time.

In the Backups section, use the backup presets to customize what data is included. You can also use file and database table filters.

Duplicator lets you exclude specific tables, like wp_woocommerce_orders or wp_comments, from the database build.

バックアップの作成を完了し、ダウンロードします。インストーラー（installer.php）とアーカイブ（サイトのファイルとデータベースを含むzip）の2つのファイルが生成されます。

ステップ4：ステージングファイルを本番サーバーに転送する

FTP、SFTP、またはホストのファイルマネージャーを使用して、ライブサーバーに接続します。

installer.phpファイルとアーカイブファイルをライブサイトのルートディレクトリにアップロードします。これは、サイトのメインのwp-config.phpファイルが存在するのと同じフォルダです。

ステージングサイトが同じサーバーのサブフォルダ（例：yoursite.com/staging/）にある場合、この転送は多くの場合、完全なアップロードではなく単なるファイルコピーであり、時間を節約できます。

次に進む前に、両方のファイルがライブサイトのルートディレクトリに表示されていることを確認してください。

より高速な方法として、Duplicator Proを使用して、バックアップアーカイブを新しいサイトに直接ドラッグアンドドロップします。FTPクライアントは不要です。

ステップ5：本番サイトでインストーラーを実行する

ブラウザで yoursite.com/installer.php にアクセスします。「yoursite.com」はライブドメインに置き換えてください。

データベース接続の詳細を再確認してください。ライブサイトのデータベースを指している必要があり、ステージングのデータベースではありません。

インストールを続行します。完了したら、管理ログインボタンで再度ログインします。

ステップ6：本番サイトを確認する

ライブサイトを開き、まずホームページを確認します。

いくつかの重要なページをクリックして確認します。ステージングで変更したページと、変更していないページをいくつか確認して、関係のないものが壊れていないことを確認します。

通常の認証情報でwp-adminにログインしてみてください。サイトにフォームやチェックアウトフローがある場合は、それらをテストします。

キャッシュをクリアします（サーバーレベルのキャッシュと実行中のキャッシュプラグインの両方）。キャッシュされたページは、プッシュが成功した後でも古いコンテンツを表示することがあります。

最後に、ステージングサイトがまだ稼働している場合は、表示設定でnoindexに設定されていることを再確認してください。忘れがちですが、検索エンジンに重複サイトをクロールされたくはありません。

トラブルシューティング：ステージングを本番環境にプッシュする際の一般的なエラー

プッシュ直後のホワイトスクリーン

ライブサイトをロードすると、エラーメッセージなしの空白の白いページが表示されます。

これは通常、ステージングでは正常に機能していたプラグインがライブサーバーの環境（多くの場合PHPバージョンの違い）と互換性がないことを意味します。

ホストのPHPバージョンとステージングで実行されていたバージョンを比較します。一致しない場合は、本番環境のPHPバージョンをステージングのバージョンに合わせるか、ステップ1のバックアップを使用して競合の原因となっているプラグインをロールバックします。

プッシュ後のwp-adminへのログイン不可

通常のログイン認証情報を入力しても、「ユーザー名またはパスワードが正しくありません」と表示されます。正しいことはわかっているのに。

データベース全体をプッシュすると、ライブサイトのユーザーテーブルがステージングのものに置き換えられるため、ライブログインがデータベース内の情報と一致しなくなります。

phpMyAdminまたはホストのデータベースツールを直接使用して管理者パスワードをリセットするか、ステップ1のバックアップを復元し、ユーザーテーブルを除外する選択的プッシュとしてプッシュをやり直します。

REST APIエラーまたはブロックエディターの破損

ブロックエディターがロードされないか、ブラウザコンソールにREST APIエラーが表示されます。

データベース内のシリアライズされたデータが、ライブドメインではなくステージングURLを参照しており、DuplicatorのURL置換ですべてのインスタンスをキャッチできませんでした。

Duplicatorは検索と置換を実行します。ただし、Search & Replace Everythingのようなプラグインを使用して、シリアライズされたフィールドに残っているステージングURLをターゲットにすることができます。

注文、コメント、または新規登録が見つからない

顧客が最近の注文が消えた、またはここ数日のコメントが消えたと報告しています。

これは、ステージングが作成された後に発生した新しいアクティビティを持つライブテーブルをフルデータベースプッシュが上書きした場合に発生します。

すぐに最初のバックアップを復元し、次にwp_woocommerce_orders、wp_comments、およびライブアクティビティを持つその他のテーブルを除外する選択的プッシュとしてプッシュをやり直してください。

転送中にプロセスが停止またはタイムアウトする

インストールが途中でハングするか、ブラウザに明確な失敗メッセージなしでタイムアウトエラーが表示されます。

特に共有ホスティングでは、大きなアーカイブファイルがサーバーのアップロード制限または実行時間制限を超える可能性があります。

ホストの最大アップロードサイズとPHP実行時間設定を確認し、プラグインがサポートしている場合はパッケージをより小さなピースに分割するか、プッシュ中に制限を一時的に引き上げるようにホストに連絡してください。

ホストのプッシュボタンが無効になっているか、表示されない

ホスティングダッシュボードでステージングプッシュオプションを探すと、無効になっているか、まったく存在しません。

これは通常、ステージング作成自体が含まれていても、ホスティングプランのティアにステージングプッシュ機能が含まれていないことを意味します。

代わりにDuplicatorのバックアップと移行方法を使用してください。これはホストのプランがサポートするものに依存しません。

よくある質問（FAQ）

すべてのプッシュを移行として扱う。なぜなら、それは移行だからです。

これで、ステージングの変更をライブサイトに適用するための完全なプロセスができました。何かが壊れるかどうかを推測する必要はありません。

今後もいくつかの点に注意してください。

ステージングで作業している間もライブアクティビティは発生するため、ステージングを作成してから変更をプッシュするまでの時間が長くなるほど、完全なプッシュで上書きするデータのリスクが高まります。最初のプッシュだけでなく、すべてのプッシュの前にライブで変更されたものを確認してください。

他の場所ではカバーされていないヒントを1つ紹介します。サイトが小さい場合でも、トラフィックが最も少ない時間帯にプッシュをスケジュールしてください。アクティブな訪問者が少ないほど、プッシュにかかる数分間に受信した注文やコメントを上書きする可能性が少なくなります。

次のプッシュの前にサイトを保護する

ステージングからライブへのすべてのプッシュには、すべての手順を注意深く実行した場合でもリスクが伴います。開始直前に取得したバックアップは、簡単な修正とサイトの再構築との違いです。

Duplicator Proは、まさにこの目的のために構築されています。フルサイトのバックアップ、選択的なデータベース制御、およびホストがサポートするものを問わず機能する移行プロセスを提供します。すでに150万以上のWordPressの専門家が、これと同様の変更を通じてサイトを保護するために使用しています。

最後のバックアップが1週間前のものであることが判明するまで、プッシュが失敗するのを待たないでください。

このチュートリアルがお役に立った場合は、これらのガイドもブックマークする価値があります。

• ステージングサイトは必要ですか？
• WordPressステージングサイトの作成方法
• WordPressをステージングサイトに変換する方法
• WooCommerceステージングサイトの作成方法（+本番稼働前にテストすること）
• プッシュごとにウェブサイトのステージングサイトをバックアップする方法
• 9つの最高のWordPressステージングプラグイン（専門家レビュー付き）