XServer for WordPressのステージング｜同期されるもの・されないもの

本記事はアフィリエイト広告を含みます。

ステージングは、本番のコピーで変更を試し、反映するファイルとデータベースを選び分けるための環境です。XServer for WordPressでは同期時にWordPress本体とPHPは更新されないため、版をそろえてから反映します。

作成→変更前の動作記録→更新テスト→同期範囲の決定→本番確認の順で使えば、検証だけで終わりません。この記事は公式仕様をもとにした操作ガイドで、独自の処理時間や成功率は示していません。

ステージングを作り、変更前の状態を記録する

WPパネルの「サイト」で対象サイトの設定画面を開き、「ステージング環境作成」へ進みます。URLだけでなく、パスワード保護と割り当てるリソースも決めてから作成します。

各サイトに作成できるステージングは一つです。本番とは別のサーバーアカウントとURLが使われ、ステージング側へ独自ドメインを設定することはできません。公式の作成手順

作成時には本番のファイル・DB・PHP版などが複製されます。コピー直後は外部連携の設定も引き継ぐ可能性があるため、実顧客への通知や決済などを伴う処理は、検証用の条件へ分けます。

検証環境からのメール送信は不可です。フォームの入力や保存の確認と、通知メールの到達確認は分けて扱います。

検証サイトを公開しない設定も用意する

ステージング作成時にはBASIC認証によるパスワード保護を設定できます。公式は検索インデックスを抑える環境設定も案内していますが、アクセスの制限と検索エンジンへの指定は役割が異なります。顧客情報や未公開原稿を含むコピーは、閲覧できる担当者を限定しましょう。公式：作成時の保護と環境設定

検証用URLは後から変えられず、独自ドメインも設定できません。担当者が本番と取り違えない名前にし、作成後すぐ表示されない場合は、作成処理とWebサーバー設定の反映が終わったかを確かめます。

更新して確かめる項目

まず変更前のコピーで代表記事・検索・ログインを一度通します。コピー時点の不具合と更新後の不具合を分けて記録できれば、何を戻すべきかを判断しやすくなります。

テスト項目はサイトの役割から決めます。企業サイトなら問い合わせ、会員サイトならログイン、記事サイトなら検索とメニュー移動を確認し、本番反映後にも同じ順番で試しましょう。

更新するプラグイン名、変更前後の版、確認したURLも記録しておきましょう。問題が出た際、どの変更まで正常だったかを遡れます。

試用は本番とステージングを合わせて最大4サイトです。専門家サポートや設定代行などは対象外なので、検証計画へ含めないようにします。14日試用の制限

検証環境を作った後は、更新対象と確認する機能をそろえて本番との違いを記録できます。 検証環境で行うプラグイン更新前後の確認表

XServer for WordPressPR

更新前のテストを一つのパネルで管理する

検証環境を毎回作る負担があるなら、XServer for WordPressの料金と試用対象を比べられます。利用中の方は、本番へ反映するファイルとデータベースの範囲を先に決めてください。

公式サイトで料金・利用条件を確認

ステージングを使える契約・試用条件へ

利用前に試用とステージングではメール送信に制限があります。同期は本番データを上書きする範囲を決めて実行します。

同期されるもの・されないもの

「本番・ステージングの同期」で扱うのは、wp-content内のファイルとデータベースです。WordPress本体とPHPのバージョンは更新されません。同期の公式マニュアル

検証中も本番に投稿・注文・問い合わせが増えるサイトでは、全データベースの反映を急がないでください。コピー後に増えたデータと、変更した設定がどのテーブルにあるかを照合します。

メールアカウントやWordPress外の設定まで、まとめて移るとは考えないでください。

ステージングを契約判断に使う場合は、通常サーバーとの違いで通常サーバーとの運用差も確認できます。

対象	同期での扱い	作業前の確認
wp-content内	全体・対象パス指定・同期なしを選ぶ	テーマ、プラグイン、画像の必要範囲
データベース	全テーブル・対象指定・同期なしを選ぶ	投稿、設定、受付データへの影響
WP本体・PHP	同期対象外	両環境のバージョンをそろえる
キャッシュ等の一部	同期対象外	再生成・表示確認を行う

ステージングでPHPを変えて動作を確かめても、同期だけで本番のPHPが同じになるわけではありません。ファイルだけ反映し、違うPHPで動かすことがないようにします。

「対象パスを指定」は必要なフォルダだけを選ぶ場合に使います。空欄ならwp-content以下の全ファイルが対象になるので、絞ったつもりの空欄にしないことが重要です。DBに保存される設定は、ファイル同期だけでは移りません。

ファイルとDBを別々に選ぶ具体例

ファイル側は全ファイル・対象パス・同期なし、DB側は全テーブル・対象テーブル・同期なしを選べます。画像だけ差し替えた場合でも、同時に記事を編集したならDBの差分があるため、「画像だけだからDB不要」と決めないでください。公式：同期対象の指定

cacheフォルダとdebug.logは同期対象外です。また、管理者向けにはAPIとCLIによるステージング作成も案内されています。自動化する場合も、APIの応答だけで公開反映が完了したとせず、処理状況と対象サイトを確認する運用が必要です。公式：APIの処理状況とステージング

本番反映前にデータの差を確認する

本番反映の直前には、複製日時からの変更一覧を作ります。追加された投稿、注文、フォームの保存データがあれば、古い検証データで置き換えない方法を先に決めます。

月曜に複製して水曜にテーマ設定を反映する例なら、火曜の問い合わせや投稿は本番だけに残る可能性があります。「見た目の変更」でもDB保存の設定なら、その新規データと同居していないかを調べてから反映します。

WPパネルの「本番・ステージングの同期」で、「本番環境へのリリース」か「ステージング環境への反映」かを選びます。向きを取り違えないよう、元と先の環境名を確認してから実行します。

反映する範囲と向きが決まったら、直前の本番バックアップと受付方針を確認します。影響範囲を説明できない場合は、変更したファイル・設定・データを保守担当へ渡して判断してください。

自動バックアップから戻す流れ

XServer for WordPressは、自動バックアップを14日分保持する仕様です。復元する際は、先に対象バックアップをサーバー側へ取得します。自動バックアップの公式手順

復元するときの操作は次の順番です。

14日分あるのは自動バックアップの履歴です。復元用にサーバーへ取得したデータは24時間で削除されるため、取得後に作業できる時間と空き容量を確保してから進めます。

「WordPressリカバリー」は別の復旧・リセット機能で、完全復旧を保証するものではないと公式に明記されています。バックアップを復元する操作とは、目的と対象を分けて使います。リカバリー機能

一度の更新なら、同期範囲を決めて戻せる状態を用意するところまでが準備です。毎回の環境作成が負担なら専用サービスの比較へ、すでに利用中なら本番と同じ操作による最終確認へ進みましょう。

• 通常エックスサーバーとの比較
• 移転前の確認表