WordPressのステージング環境を作る方法（プラグイン・WP-CLI・本番への反映手順）

ステージング環境は、本番サイトの複製を別の URL に作り、テーマの変更やプラグインの更新を先に試すための場所です。本番で直接試して表示が崩れたり、サイトが止まったりするのを避けられます。

この記事の WP-CLI の手順と PHP のコードは、2026年11月時点の WordPress 7.1、WP-CLI 2.12、PHP 8.3 で動作を確かめています。

作り方の選び方

まずは使っているレンタルサーバーのマニュアルで、ステージング機能やサイトのコピー機能があるかを確認してください。たとえばエックスサーバーには、サーバーパネルの「WordPress簡単インストール」からサイトをコピーする機能があります（公式マニュアル「WordPressのサイトコピー」）。コピーでは一部のファイルの URL が置き換わらない場合があると案内されているので、コピー後に表示を確かめます。

WP Stagingプラグインで作る

WP Staging は、本番サイトを同じサーバーのサブディレクトリ（例: example.com/staging-site）に複製するプラグインです。2026年11月時点で有効インストール数は10万以上です。

1. 「プラグイン」→「プラグインを追加」で「WP Staging」を検索し、インストールして有効化します。
2. 管理画面に追加された「WP Staging」メニューを開き、ステージングサイトを作成します。
3. 作成が終わると、サブディレクトリの URL でステージングサイトの管理画面にログインできます。

無料版でできるのは複製の作成までです。ステージングで変えた内容を本番に書き戻す機能や、サブドメインへの複製は有料の Pro 版の機能です。無料版で作ったステージングで確認した変更は、後の章の手順で本番に反映します。

WP-CLIで手作業で作る

VPS などで、ステージング用のサブドメイン（ここでは staging.example.com）とそのドキュメントルート（/var/www/staging）を Web サーバーに設定済みとします。本番は /var/www/html、データベースは MariaDB（MySQL でも同じ）です。

1. ファイルを複製する

rsync -a --exclude='wp-content/cache/' /var/www/html/ /var/www/staging/

2. ステージング用のデータベースを作り、本番のデータを入れる

# 本番のデータベースを書き出す（ドキュメントルートの外に置く）
wp db export ~/production.sql --path=/var/www/html

# ステージング用のデータベースとユーザーを作る
sudo mysql -e "CREATE DATABASE wp_staging DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wp_staging'@'localhost' IDENTIFIED BY '長く推測されにくいパスワード';
GRANT ALL PRIVILEGES ON wp_staging.* TO 'wp_staging'@'localhost';"

3. ステージングの wp-config.php を書き換え、データを読み込む

cd /var/www/staging
wp config set DB_NAME wp_staging
wp config set DB_USER wp_staging
wp config set DB_PASSWORD '長く推測されにくいパスワード'
wp config set WP_ENVIRONMENT_TYPE staging

wp db import ~/production.sql
rm ~/production.sql

wp config set で設定を変えてから wp db import を実行するので、データは本番ではなくステージングのデータベースに入ります。wp config get DB_NAME で先に確かめると安心です。

4. URLを置き換える

データベースの中の URL を、本番からステージングのものに置き換えます。wp search-replace はシリアライズされたデータも正しく書き換えます。まず --dry-run で件数を確かめてから実行します。

wp search-replace 'https://example.com' 'https://staging.example.com' \
  --all-tables-with-prefix --skip-columns=guid --dry-run --report-changed-only

wp search-replace 'https://example.com' 'https://staging.example.com' \
  --all-tables-with-prefix --skip-columns=guid --report-changed-only

wp option get siteurl

• --all-tables-with-prefix は、WordPress の接頭辞（wp_ など）が付いたテーブルだけを対象にします。プラグインが作ったテーブルも含まれます。
• --skip-columns=guid は、投稿の識別子（GUID）を書き換えないための指定です。

5. 検索エンジンに載らないようにする

wp option update blog_public 0
wp cache flush

blog_public を 0 にすると、管理画面の「設定」→「表示設定」の「検索エンジンでの表示」で「検索エンジンがサイトをインデックスしないようにする」にチェックを入れたのと同じ状態になり、各ページに noindex, nofollow の robots メタタグが出ます。試したところ、この設定では robots.txt に「Disallow: /」は追加されませんでした。検索エンジンへの指示はメタタグだけなので、次の章のアクセス制限もあわせて行います。

アクセスを制限する

ステージングは本番と同じ内容なので、外部から見えると重複コンテンツになったり、未公開の変更が見られたりします。Basic 認証で、知っている人だけが開けるようにします。

レンタルサーバーでは、コントロールパネルの「アクセス制限」などの機能を使うのが手軽です。Apache 2.4 を自分で管理している場合は、パスワードファイルを作り、ステージングのドキュメントルートの .htaccess の先頭（# BEGIN WordPress より前）に書きます。

# パスワードファイルはドキュメントルートの外に作る
sudo htpasswd -c /etc/apache2/.htpasswd-staging staginguser

AuthType Basic
AuthName "Staging"
AuthUserFile /etc/apache2/.htpasswd-staging
Require valid-user

Basic 認証は通信を暗号化しないので、ステージングも HTTPS で開くようにします。ログイン画面の保護については ステージング環境のログイン設定 も参考にしてください。

WP_ENVIRONMENT_TYPEで環境を区別する

WP_ENVIRONMENT_TYPE は、そのサイトがどの環境かを WordPress に伝える定数です。値は local・development・staging・production のどれかで、それ以外の値や未設定のときは production として扱われます。プラグインやテーマは wp_get_environment_type() で値を読めます。

<?php
// wp-config.php（require_once ABSPATH . 'wp-settings.php'; より前に書く）
define( 'WP_ENVIRONMENT_TYPE', 'staging' );

// 本番以外ではエラーをログに記録し、画面には出さない
if ( 'production' !== WP_ENVIRONMENT_TYPE ) {
	define( 'WP_DEBUG', true );
	define( 'WP_DEBUG_LOG', true );
	define( 'WP_DEBUG_DISPLAY', false );
}

wp_get_environment_type() は wp-settings.php が読み込まれた後で使える関数です。wp-config.php の中では呼べないので、上のように定数を直接比べます。

WP_DEBUG を定義しない場合、WordPress は WP_ENVIRONMENT_TYPE が development のときだけ WP_DEBUG を true にします。staging では false のままです（試した環境でも同じでした）。

本番以外でnoindexと環境名を出す

次のファイルを wp-content/mu-plugins/env-helpers.php として置くと、本番以外の環境で全ページに noindex が付き、管理バーに環境名が表示されます。mu-plugins に置いたファイルは有効化の操作なしで読み込まれます。

<?php
/**
 * Plugin Name: Environment helpers
 * Description: 本番以外の環境で noindex を出し、管理バーに環境名を表示する。
 */

// 本番以外では、すべてのページの robots メタタグに noindex を付ける
add_filter( 'wp_robots', function ( $robots ) {
	if ( 'production' !== wp_get_environment_type() ) {
		$robots = wp_robots_no_robots( $robots );
	}
	return $robots;
} );

// 本番以外では、管理バーに環境名（STAGING など）を表示する
add_action( 'admin_bar_menu', function ( $wp_admin_bar ) {
	$env = wp_get_environment_type();
	if ( 'production' === $env ) {
		return;
	}
	$wp_admin_bar->add_node(
		array(
			'id'    => 'myprefix-environment',
			'title' => esc_html( strtoupper( $env ) ),
		)
	);
}, 100 );

試したところ、WP_ENVIRONMENT_TYPE を staging にすると robots メタタグに noindex, follow が付き（「検索エンジンでの表示」のチェックを入れた状態では noindex, nofollow）、未設定に戻すと付かなくなりました。本番に同じファイルを置いても、本番では何もしません。

ステージングから本番へ反映する

ステージングの作成後も、本番では投稿・コメント・注文などが増え続けます。ステージングのデータベースで本番を上書きすると、その間の本番の変更が消えます。反映はファイル（テーマ・プラグイン）を中心にし、データベースは書き戻さないのが基本です。

1. 本番をバックアップする

mkdir -p ~/backup
cd /var/www/html
wp db export ~/backup/pre-deploy-$(date +%Y%m%d%H%M).sql
tar -czf ~/backup/wp-content-$(date +%Y%m%d%H%M).tar.gz wp-content/themes wp-content/plugins

バックアップはドキュメントルートの外に置きます。ドキュメントルートの中に置くと、URL を知られたときにダウンロードされるおそれがあります。

2. 変更したテーマだけを同期する

# まず --dry-run で、追加・削除されるファイルを確かめる
rsync -av --delete --dry-run \
  /var/www/staging/wp-content/themes/my-theme/ \
  /var/www/html/wp-content/themes/my-theme/

# 問題がなければ実行する
rsync -av --delete \
  /var/www/staging/wp-content/themes/my-theme/ \
  /var/www/html/wp-content/themes/my-theme/

cd /var/www/html
wp cache flush

--delete は、コピー元にないファイルをコピー先から消す指定です。パスの末尾の / を付け忘れると、ディレクトリの中にもう1階層できてしまうので、--dry-run の出力で確かめてから実行します。

3. プラグインの更新は本番でも同じ操作をする

ステージングでプラグインやテーマの更新を試して問題がなければ、本番でも同じ更新を実行します。ファイルをコピーするより、更新時のデータベースの変換処理なども本番で同じように動きます。

cd /var/www/html
wp plugin update akismet   # ステージングで試したものだけを更新する

4. 設定の変更は本番で同じ操作をやり直す

ウィジェットやメニュー、プラグインの設定など、データベースに保存される変更は、ステージングで確かめた手順を本番で同じように操作して反映します。

ローカルに開発環境を作る（wp-env）

テーマやプラグインを開発するなら、自分のパソコンに環境を作る方法もあります。@wordpress/env（wp-env）は WordPress 公式の開発用ツールで、Docker と Node.js が必要です。

npm -g i @wordpress/env

# プラグインやテーマのディレクトリで起動する
wp-env start

起動すると http://localhost:8888 で WordPress が開き、ユーザー名 admin・パスワード password でログインできます。テスト用のサイトは http://localhost:8889 で起動します。設定はディレクトリに置いた .wp-env.json で変えます。

{
  "core": null,
  "phpVersion": "8.3",
  "plugins": [ "." ],
  "themes": [],
  "port": 8888,
  "config": {
    "WP_DEBUG": true
  }
}

core を null にすると最新の WordPress が使われます。plugins の "." は、今のディレクトリをプラグインとして読み込む指定です。

GUI で操作したい場合は、Local（localwp.com）のようなデスクトップアプリもあります。ローカル環境の作り方は WordPressのローカル開発環境の作り方 にまとめています。

ステージングで気をつけること

• メールの送信: ステージングは本番と同じユーザーや注文のデータを持っています。予約投稿や定期処理（WP-Cron）、問い合わせフォームのテストなどで、実在の利用者にメールが送られることがあります。メールを送らない設定にしてから操作します。
• 外部サービスとの連携: 決済や外部 API のキーが本番のままだと、ステージングでの操作が本番の取引になることがあります。テスト用のキーに切り替えます。
• 個人情報: ステージングにも利用者の個人情報が入っています。不要になったステージングはファイルとデータベースを削除します。

関連記事

• WordPressのステージング環境の作り方
• ステージングから本番環境へ反映する方法
• .htaccessでパスワード保護をかける方法