ライブサイトの惨事を防ぐための10のWordPressステージングのベストプラクティス

プラグインの更新に30秒しかかからないので、ライブサイトで更新します。すると、ホームページが真っ白になります。

これは、ほとんどすべてのWordPressサイト所有者が一度は経験することです。

ちょっとした更新、小さな変更、「大丈夫だろう」と思った瞬間、それは大丈夫ではありませんでした。そして今、あなたは実際の訪問者があなたのサイトにアクセスしようとしているのに、真っ白な画面を見つめています。

それがステージングサイトが解決する問題です。ステージングサイトは、本番環境に影響を与える前に変更をテストできる、ライブサイトのプライベートコピーです。ステージングで何か問題が発生しても、あなた以外には誰も気づきません。

ほとんどのカジュアルなWordPressユーザーはステージングの存在を知っています。ほとんどの人は、余分な作業のように聞こえるため、スキップします。

わかります。しかし、ステージングで2分で検出できたはずのプラグインの競合により、セール中にWooCommerceのチェックアウトがダウンするのを見て以来、私はそれをオプション扱いするのをやめました。

この記事では、ステージングサイトとは何か、いつ必要か、どのように迅速にセットアップするか、そしてそもそもステージングを行う価値があるようにするプラクティスについて説明します。

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

• ステージングはすべての変更に必要ではありません。タイポ、価格の更新、新しい投稿などの軽微な編集には、ステージングワークフローは必要ありません。
• 1週間前のサイトのコピーに対してテストしても、信頼性の低い結果が得られます。変更の各ラウンドの前にステージングをリフレッシュすることで、これを完全に解決できます。
• ステージングから本番環境にデータベース全体をプッシュすると、ライブコンテンツが破壊されます。ステージングで作業中に本番環境に届いた注文、フォーム送信、ユーザー登録が上書きされます。コードはプッシュしますが、データベースはプッシュしないでください。
• ブロックされていないステージングサイトは、ライブサイトのSEOを損ないます。パスワード保護とnoindex設定は譲れません。
• ステージングのデバッグモードは、本番環境では隠されているエラーを表面化させます。ライブサイトで静かに存在するPHPの通知や警告が、最初にここに表示されます。
• 1つのプラグインを一度に更新することが、競合を追跡する唯一の信頼できる方法です。一括更新では、どの変更が問題を引き起こしたかを特定することは不可能です。
• プッシュ前のバックアップは、デプロイメントの失敗を回復可能にするものです。
• 古いステージング環境はセキュリティ上のリスクとなります。完了したら削除してください。

目次

ステージングはバックアップではありません。ライブサイトがクラッシュした場合、ステージングから復元することはできません。

それぞれ異なる目的を果たします。バックアップは復旧ツールであり、ステージングはテスト環境です。

ステージングはローカル開発環境とも異なります。ローカル環境はコンピューター上でオフラインで動作し、実際のサーバー環境とは切り離されています。

ステージングは実際のURLを持つ実際のサーバーで動作するため、サイトが本番でどのように動作するかを反映します。

サイトの完全な再構築やゼロからの開始を行いたい場合は、XAMPP、WAMP、MAMPなどのローカルツールが適しています。実際のサーバーの動作に対してアップデートや変更をテストするには、ステージングの方が信頼性の高いオプションです。

また、ステージングは永続的な第2のサイトではありません。一時的な作業環境です。変更を加え、テストし、機能するものプッシュし、次のラウンドを開始するときにリセットまたはリフレッシュします。

ステージングサイトを使用するタイミング（およびスキップするタイミング）

ステージングに関するすべての投稿で、すべてに使用するように言われます。それは現実的ではなく、そのアドバイスに従うとプロセス疲労につながり、最終的には本当に必要な変更に対してもステージングの使用を中止することになります。

より正直な見方をご紹介します。

ステージングが必要な変更

これらは、ライブサイトで何か問題が発生した場合に、売上の損失、フォームの破損、ユーザーのロックアウト、または読み込まれないホームページなど、現実的な結果をもたらす状況です。

ステージングの時間コストは、これらのいずれかがうまくいかなかった場合の復旧コストに比べれば何もありません。

• WordPressコアアップデート、特にメジャーバージョンリリース
• プラグインまたはテーマのアップデート、特にWooCommerce、ページビルダー、セキュリティプラグイン
• PHPバージョンまたはサーバー構成へのあらゆる変更
• チェックアウト、フォーム、またはサイト全体の機能に影響を与える新しいプラグインの追加
• テンプレートまたはテーマファイルを変更するカスタムコードまたはCSSの変更
• 完全な再設計または大幅なレイアウト変更

ステージングが不要な変更

ステージングにはオーバーヘッドがあります。クローンを作成し、変更を加え、元に戻す：これは、実際のリスクを伴わない編集には過剰です。

• タイポの修正または価格の更新
• 新しいブログ記事の公開または商品の追加
• メニュー項目の入れ替えまたはウィジェットの調整
• コードの依存関係がないマイナーな画像更新

このリストのいずれかがサイトを壊した場合、修正にかかる時間はステージングのセットアップにかかる時間よりも短くなります。プロセスは、その価値を発揮するときにのみ使用してください。

WordPressステージングサイトのセットアップ方法

ホストが組み込みステージングを提供している場合は、それが妥当な出発点です。WP Engine、Kinsta、SiteGroundはダッシュボードにそれを含んでいます。

ホストが提供していない場合（または、サイトがどこでホストされていても同じように機能するものが必要な場合）は、Duplicator Proを使用しています。

数回のクリックで、任意のフルサイトバックアップをステージングサイトに変換できます。別のホスティングアカウント、FTP、または手動のデータベース作業は必要ありません。

まず、サイトの完全なバックアップを作成します。

次に、Staging » Create Your First Staging Site に移動します。

作成したバックアップをステージングサイトのブループリントとして選択します。ステージングダッシュボードが常に異なる外観になるように、ユニークな管理者カラーテーマも必ず選択してください。

Duplicator は、バックアップを完全に新しいステージングサイトとしてインストールします。ここで行われた変更は、実際のウェブサイトには影響しません。

手動での方法も選択肢としてあります。サブドメインまたはサブディレクトリを設定し、FTP経由でファイルを転送し、phpMyAdminでデータベースを複製し、wp-config.php の認証情報を更新し、wp_options テーブルで URL を同期します。これは機能しますが、間違いやすい手順がたくさんあります。

その他のステージング方法については、WordPressステージングサイトの作成方法に関する投稿をお読みください。

すべてのサイト所有者が従うべきWordPressステージングのベストプラクティス10選

ステージングの設定は簡単な部分です。一般的な間違いを避けるための WordPress ステージングのベストプラクティスをいくつかご紹介します。

• 常に新しいバックアップから開始。ステージングの設定がうまくいかなかった場合や、プッシュした変更がライブサイトを壊した場合の復旧ポイントになります。
• プライベート、インデックスブロック、分離されたデータベース。それぞれ異なる種類の損害を防ぐ 3 つの設定です。
• 本番環境をミラーリング。PHP バージョン、サーバータイプ、キャッシュレイヤー、ファイアウォールルールはすべて本番環境と一致させる必要があります。そうしないと、テスト結果を信頼できません。
• デバッグモードを有効にする。本番サイトではデフォルトで非表示になっている PHP エラーをステージングで表示します。
• 一度に 1 つの更新。競合の原因となった特定の変更にまで問題を追跡する唯一の方法です。
• ステージングを最終的な QA ゲートとして使用。ライブにする前に、ナビゲーション、フォーム、チェックアウト、モバイル、ページ速度をカバーする完全なテストパスを実行します。
• データベースではなく本番環境にコードをプッシュ。データベース全体をプッシュすると、ステージングで作業中に到着したライブコンテンツが上書きされます。
• 各ラウンドの前に更新。古いステージングでは信頼性の低い結果が得られます。新しい変更バッチの前に本番環境からプルしてください。
• プッシュ前に本番環境をバックアップ。デプロイの直前に実行し、前日ではありません。
• 定期的なクリーンアップ。完了した古いステージング環境は、混乱やセキュリティのギャップを避けるために削除してください。

1.常に最新のバックアップから開始する

ステージング環境を作成する前に、本番サイトの完全なバックアップを取得してください。ステージングの設定がうまくいかなかった場合、クリーンな復旧ポイントがあります。

さらに重要なのは、そのバックアップが、ライブサイトで何かを壊す変更をプッシュした場合の復元オプションになることです。

Duplicator でステージングサイトを作成した場合、すでにサイトの最新のバックアップがあります。それがステージングの最初のステップです！

バックアップを作成する際には、少なくとも 1 つのコピーをクラウドに送信することをお勧めします。Duplicator Cloud は、実際のサイトに何かあった場合に備えて、オフサイトの復旧ダッシュボードを提供します。

2.ステージングをプライベートに保ち、インデックスをブロックし、別のデータベースを使用する

パスワード保護から始めましょう。ステージング URL は、決して公開アクセス可能であってはなりません。以上です。

そこにアクセスしたユーザーは、サイトの未完成または破損している可能性のあるバージョンを目にします。ほとんどのホスティングサービスやステージングプラグインはこれを自動的に処理しますが、想定するのではなく、ご自身で確認してください。

検索エンジンのブロックは別の重要なステップです。ステージングWordPressダッシュボードの設定 » 表示設定に移動し、検索エンジンがサイトをインデックスに登録しないようにするにチェックを入れます。

Duplicatorはこれを自動的に行うはずですが、確認しても損はありません。

ブロックされていないステージングサイトはインデックスに登録される可能性があります。URLにアクセス可能であれば、Googleはステージングと本番を常に区別するわけではなく、重複コンテンツによるSEOへのダメージは、ライブサイトのランキングに数ヶ月間影響を与える可能性があります。

データベースのルールは異なりますが、同様に重要です。ライブサイトとステージングでデータベースを共有しないでください。

データベースを共有すると、誤った保存や設定変更などのステージング操作で、実際の運用データが上書きされる可能性があります。注文、フォーム送信、ユーザーアカウント、公開コンテンツなどを失う可能性があります。

データベースは完全に分離してください。ほとんどのステージングセットアップはデフォルトでこれを処理しますが、手動でセットアップする場合は、開始する前にこの点を再確認する価値があります。

3.本番環境を可能な限り正確にミラーリングする

ステージングの目的は、ライブサイトで何が起こるかをテストすることです。ステージングが本番と一致しない場合、テスト結果はあまり意味がありません。

PHPのバージョンが最も一般的な不一致です。ステージング環境でPHP 8.1を実行し、本番環境でPHP 8.3を実行している場合、ステージングでは正常に動作するプラグインがライブサイトでエラーを発生させる可能性があります。

テストを行う前に、両方の環境で同じバージョンが実行されていることを確認してください。一方のサイトのPHPバージョンをアップグレードする必要があるかもしれません。

Duplicatorを使用してステージングサイトを構築している場合は、新しいテストラウンドの前に新しいサイトを作成してください。古い環境はウェブサイトの正確なコピーではありません。

古いステージングサイトを削除し、ウェブサイトのコピーを新しく生成して、新しいステージングサイトの構築に使用してください。

Webサーバーにも同じ論理が適用されます。ApacheとNginxは特定の構成を異なる方法で処理します。環境が異なると、追跡が非常に困難なバグが発生する可能性があります。

キャッシュレイヤーも重要です。特にパフォーマンスのテストではそうです。本番環境でRedisまたはMemcachedを使用し、ステージングで使用しない場合、ステージングで実行するページ速度のベンチマークは実際の条件を反映しません。

ファイアウォールとセキュリティルールだけでなく、キャッシュ設定もミラーリングしてください。本番環境ではアクティブだがステージングではアクティブでないセキュリティプラグインまたはWAFルールは、プッシュ後にのみ発見される競合を引き起こす可能性があります。

一致度が高いほど、ステージングが伝えることをより信頼できます。

4.ステージングでデバッグモードを有効にする

WordPressはデフォルトで本番環境のPHPエラーを非表示にします。訪問者に生の Сообщения об ошибках を見せたくないので、ライブサイトにとっては正しい判断です。しかし、それはまた、目に見える兆候なしにサイトに問題が存在する可能性があることを意味します。

ステージングはそれらを表面化させる場所であり、WordPressのデバッグでそれを行うことができます。

ステージング環境の `wp-config.php` ファイルに `define('WP_DEBUG', true);` を追加してください。これによりエラー報告が有効になり、通常は非表示になっている PHP の通知や警告が表示されるようになります。

プラグインのアップデートで非推奨に関する警告が発生したり、テーマの関数でエラーが発生したりした場合、本番サイトに影響が出る前にステージング環境で確認できます。

これと併せて `WP_DEBUG_LOG` を有効にすることも検討してください。これにより、エラーが `wp-content` フォルダ内の `debug.log` ファイルに書き込まれるため、リアルタイムでエラーをキャッチするのではなく、確認できる記録が残ります。

本番環境ではデバッグモードをオフにしてください。これらの設定はステージング環境専用です。

5.一度に1つのものを更新する

6つのプラグインアップデートが待機している場合、すべてを選択して一度にアップデートしたくなるかもしれません。その方が速いですが、一括アップデート後に何か問題が発生した場合、どのプラグインが原因だったのか分からなくなります。

個別にアップデートしてください。それぞれアップデートした後、簡単なチェックを実行します。

ホームページを読み込み、数ページを閲覧して、明らかに問題が発生していないことを確認します。その後、次のアップデートに進みます。

プロセスに数分追加されますが、問題が発生した場合に何がいつ変更されたのかを明確に把握できます。

これは WordPress のコアアップデートにも当てはまります。同じセッションでコアと複数のプラグインをアップデートする場合、まずコアをアップデートしてテストし、その後プラグインを1つずつ確認してください。

メジャーなコアアップデートと特定のプラグインとの競合は、複数の変更を同時に行っていない場合に診断がはるかに容易になります。

6.プッシュ前の最終的なQAゲートとしてステージングを使用する

ステージングは単に変更を試す場所ではありません。本番サイトに影響を与える前の、必須の最終確認場所です。

変更をプッシュする前に、完全なテストを実行してください。これは、更新したページを確認する以上のことを意味します。

実行すべき主なアクションを以下に示します。

• デスクトップとモバイルの両方で、メインナビゲーションをクリックして確認してください。
• サイトで使用されているすべてのフォームを送信してください。これには、お問い合わせフォーム、ニュースレター登録、サードパーティサービスに連携されるものすべてが含まれます。
• WooCommerce を実行している場合は、カートに追加、チェックアウト、支払いなど、完全なチェックアウトフローを試してください。
• Google PageSpeed Insights でページの読み込み速度を確認し、ベースラインと比較してください。
• 変更が影響を与えるはずだったページと、まったく影響を与えないはずだった数ページを確認してください。

競合は常に予想される場所で発生するとは限りません。チェックアウトに影響するプラグインのアップデートは、チェックアウトページを視覚的に破損させないかもしれませんが、注文確認メールを静かに破損させる可能性があります。

徹底的なクリックを10分間行うことで、5秒の簡単なチェックでは見逃されるものを見つけることができます。

7. データベース全体ではなく、コードをプッシュする

ステージングから本番環境に変更をプッシュする際は、コード（テーマ、プラグイン、カスタムスクリプト、設定変更）を移動してください。特定の理由があり、上書きする内容を完全に理解している場合を除き、データベース全体をプッシュしないでください。

ステージングで作業している間も、本番サイトは稼働し続けていました。新しい注文が入ってきました。お問い合わせフォームが送信されました。ユーザーが登録しました。ブログのコメントが投稿されました。

ステージングから本番環境にデータベース全体をプッシュすると、これらすべてが上書きされます。

ルールは、コードはステージングから本番環境へ、コンテンツは本番環境に残す、です。

ステージングで加えたコンテンツの変更を本番環境に反映させる必要がある場合は、データベース全体をプッシュするのではなく、それらの要素を手動で移行してください。

ホストまたはステージングプラグインが選択的プッシュをサポートしている場合は、それを使用してください。これにより、他のすべてに影響を与えることなく、特定のファイルやテーブルをプッシュできます。ライブサイトにアクティブなユーザーがいる場合や進行中のトランザクションがある場合、そのレベルの制御は非常に価値があります。

Duplicatorの場合、データベースを含まないステージングサイトのカスタムバックアップを作成できます。

それをダウンロードしてから、本番サイトにアップロードしてください。

ただし、災害復旧計画が整っており、トラフィックが多い時間帯の変更のプッシュを避けるようにしてください。本番環境で問題が発生した場合、エラーのデバッグやバックアップのロールバックが必要になる場合があります。

8.変更の各ラウンドの前にステージングをリフレッシュする

数週間または数ヶ月前のステージング環境は、信頼できるテスト環境ではありません。それは、作成した時点でのサイトのスナップショットであり、今日のサイトとはほとんど関係がない可能性があります。

ステージングのプラグインバージョンは、本番環境より古い場合があります。コンテンツ構造が変更されている場合があります。ライブサイトで更新した設定がステージングに存在しない場合があります。

古いコピーに対してテストすると、結果はもはや存在しない条件を反映します。

変更の新しいバッチごとに、本番環境から最新のコピーをプルしてください。これは、ステージングのエラーを最も排除する単一の習慣です。これにより、実行するすべてのテストが、サイトの現在の正確なバージョンに対して行われます。

Duplicator Proを使用している場合、ステージングの更新は元のセットアップと同じくらい高速です。新しいバックアップを実行し、ステージング環境に変換すれば完了です。

9.プッシュする前に本番環境のバックアップを取得する

注意深く徹底的なステージング作業を行った後でも、プッシュが失敗する可能性があります。サーバーのキャッシュ動作、ライブ環境で異なる反応をするプラグイン、ステージングでは機能するが本番環境では競合する設定：これらのことは起こり、常に予測できるとは限りません。

答えは、プッシュする前に常に復旧ポイントを用意しておくことです。

ステージングから何かをデプロイする直前に、本番環境の新しいフルサイトバックアップを取得してください。そうすれば、ライブサイトで問題が発生した場合、そのバックアップを復元するだけで、数分で通常の状態に戻ることができます。

それがないと、壊れたライブサイトをリアルタイムでデバッグするか、手動で復旧しようとするかのどちらかになります。

私はこれを譲れないステップと見なしています。ステージングは完璧に進んでも、プッシュで予期せぬことが起こる可能性があります。バックアップは、それを壊滅的なものではなく回復可能なものにします。

Duplicatorは、WordPressがダウンしていても機能する災害復旧URLを備えた唯一のバックアッププラグインです。フルサイトバックアップを作成したら、それを災害復旧ポイントとして設定してください。

次に、復旧URLをコピーして安全な場所に保存してください。

プッシュがうまくいかなかった場合は、このリンクをブラウザウィンドウに貼り付けて、サイトを瞬時に通常の状態にロールバックしてください。

10.古いステージング環境をクリーンアップする

ステージング環境はすぐに蓄積される可能性があります。再設計のために1つ作成し、プロジェクトを完了して次に進みます。6か月後、サーバーまたはアカウントには3つの古いステージングクローンが残っており、どれも明確にラベル付けされておらず、すべてが最新の状態ではありません。

これにより2つの問題が発生します。まず、混乱：作業を再開するとき、どの環境が最新であるか、またはどの環境がどのような状態にあるかが常に明らかであるとは限りません。

第二に、セキュリティ：積極的に管理されなくなった古いステージングサイトはパッチが適用されないままになり、適切にパスワードで保護されていない場合、それは開いたドアです。

完了したら、ステージング環境を削除する習慣をつけましょう。Duplicatorのダッシュボードで、すべてのステージングサイトを1か所から管理できます。

新しい作業を開始するときは、古いものを掘り起こすのではなく、本番環境から新しいクローンを作成してください。これにより、物事が整理され、常に何に取り組んでいるかを正確に把握できます。

ステージングを正しく行う：本番環境にプッシュする前のチェックリスト

ステージングから本番環境に何かをデプロイする前に、このリストを確認してください。5分かかりますが、経験から言って、これは数回の悪い日を防いでくれたと言えます。

• このテストラウンドの前に、ステージングは本番環境からリフレッシュされました
• すべての変更はステージングで行われ、本番環境では直接行われませんでした
• WP_DEBUGはステージングで有効になっており、エラーは見つかりませんでした
• 各更新は個別に適用され、一度にすべて適用されたわけではありません
• フルサイトテストパス完了：ナビゲーション、フォーム、チェックアウト、モバイルレイアウト、ページ速度
• ステージングはパスワードで保護されており、検索エンジンのインデックス作成からブロックされています
• コードの変更のみがプッシュされており、データベース全体ではありません
• プッシュ直前に、本番環境の新しいフルサイトバックアップが取得されました
• プッシュが何かを壊した場合に、そのバックアップを復元する正確な手順を知っています

最後の項目は、人々がスキップするものです。バックアップを取得することと、それを復元する方法を知っていることは、2つの異なることです。

Duplicator Proから復元を実行したことがない場合は、まずステージング環境でテストしてください。これにより、壊れたライブサイトでプレッシャーの中で解決策を見つける必要がなくなります。

よくある質問（FAQ）

ステージングはあなたを遅くしません。壊れたライブサイトから回復することの方が時間がかかります。

ステージングは、やるべきことだとわかっているのに、なかなか実行できないものという評判があります。それはオーバーヘッドのように感じられます。変更したいこととあなたの間にある余分なレイヤーです。

ほとんどのカジュアルなWordPressユーザーはそれをそのように扱っており、そして彼らのほとんどは、最悪の瞬間にライブサイトが壊れた経験もしています。

ステージングの時間コストはわずかです。リフレッシュに数分、テストに数分、プッシュ前のバックアップ。ライブサイトの破損から復旧する時間コストははるかに大きく、公の場で発生するという追加のストレスが伴います。

ステージングワークフローがあってもリスクが完全になくなるわけではありませんが、本番環境に到達する前にほとんどの問題を検出できます。

150万以上のWordPressのプロフェッショナルがDuplicator Proを使用してサイトのバックアップ、移行、ステージングを行っています。ステージングの設定は数回のクリックで完了し、どのホストでも機能し、実行するために別のホスティングアカウントや技術的な背景は必要ありません。

この投稿を読んで、変更を加える前にサイトを保護することについて考えたなら、これらのガイドを読む価値があります。

• WordPressステージングサイトの作成方法（安全なテストのために）
• ステージングサイトは必要ですか？
• プッシュごとにウェブサイトのステージングサイトをバックアップする方法
• 9つの最高のWordPressステージングプラグイン（専門家レビュー付き）
• WooCommerceステージングサイトの作成方法（+本番稼働前にテストすること）
• WordPressデータベースメンテナンス：毎週、毎月、四半期ごとに行うべきこと