How to Set Up a WordPress Staging Site (Every Method Explained)

A staging site is a private copy of your live WordPress site where you test changes before they go live. Plugin updates, theme modifications, major content restructuring, new page builder work - all of it should be tested on staging first.

The cost of a staging site is a few hours to set up. The cost of not having one is discovering a critical plugin update broke the live site in front of real customers.

Here are all the methods, from easiest to most manual.

Method 1 - Host-provided staging (fastest)

Most managed WordPress hosts offer one-click staging:

Kinsta: Environment tab > Create new environment > Select "Staging". Creates an exact copy at staging.yourdomain.com or a Kinsta subdomain. Push changes from staging to live (or live to staging) with one click. Staging environments on Kinsta are search-engine blocked by default.

WP Engine: Sites > [your site] > Add environment > Staging. Same one-click workflow. WP Engine staging is on a separate domain and is auto-blocked from indexing.

Cloudways: Application > Staging Management > Create staging. Slightly less automated but still a guided process.

SiteGround / Bluehost / most cPanel hosts: Look for "WordPress Staging" in the hosting dashboard. The tool varies by host but is generally based on WP-CLI or a GUI tool.

Pros: No extra plugin needed, backups are managed by the host, push-to-live is simple.

Cons: Costs extra at some hosts, limited to one staging environment at most budget hosts, the push-to-live process may overwrite the entire site (verify what exactly gets pushed before using it on a live site with active traffic).

Method 2 - Plugin-based staging

If your host does not offer staging, several plugins do the job.

WP Staging

WP Staging is the most capable free plugin for creating staging environments. It clones the site to a subdirectory (e.g., yourdomain.com/wp-staging/) or a subdomain.

Setup:

1. Install WP Staging: free version handles most needs
2. WP Staging > Start Staging > Click the staging link in the admin
3. The plugin clones the database and file system
4. Access staging at the subdirectory/subdomain URL

Configuration options::

• Exclude specific tables (to avoid duplicating large log tables)
• Exclude specific directories (large upload folders)
• Set custom staging URL

Push to live (Pro feature): Selectively push database changes, file changes, or both back to the live site. The free version creates staging but does not push back - you would need to handle that manually or upgrade to Pro.

WP Staging Pro is $99/year and adds the push-to-live feature, scheduled backups of staging, and external database support.

WPvivid Staging

WPvivid (covered in the backup plugins guide) also has staging functionality. Create a staging site, make changes, then use the migration tool to push to production. Decent free option if you already use WPvivid for backups.

Method 3 - Manual staging with WP-CLI and a subdomain

For full control, set up staging manually. This method works on any host with SSH access.

Step 1 - Create the subdomain

In your hosting control panel or DNS settings, create a subdomain: staging.yourdomain.com. Point it to a new directory: /var/www/staging.yourdomain.com/.

Step 2 - Export the live database

wp db export /tmp/live-backup.sql --path=/var/www/html

Step 3 - Copy the files

cp -r /var/www/html /var/www/staging.yourdomain.com

For large sites with many media files, copy only what you need. The uploads directory can often stay as a symlink or be shared:

# Copy everything except uploads
rsync -av --exclude='wp-content/uploads' /var/www/html/ /var/www/staging.yourdomain.com/

# Symlink uploads so staging uses live media files (read-only)
ln -s /var/www/html/wp-content/uploads /var/www/staging.yourdomain.com/wp-content/uploads

Step 4 - Create the staging database

mysql -u root -p -e "CREATE DATABASE staging_db;"
mysql -u root -p staging_db < /tmp/live-backup.sql

Step 5 - Update wp-config.php for staging

In /var/www/staging.yourdomain.com/wp-config.php:

define( 'DB_NAME',     'staging_db' );
define( 'DB_USER',     'staging_user' );
define( 'DB_PASSWORD', 'strong-password' );

define( 'WP_HOME',    'https://staging.yourdomain.com' );
define( 'WP_SITEURL', 'https://staging.yourdomain.com' );

Step 6 - Update the database URLs

The database contains the live domain in multiple places. Update them:

wp search-replace 'https://yourdomain.com' 'https://staging.yourdomain.com' --all-tables --path=/var/www/staging.yourdomain.com

Step 7 - Block search engine indexing

In the staging WordPress admin: Settings > Reading > Check "Discourage search engines from indexing this site".

Or add to staging's wp-config.php:

// Force noindex on staging
define( 'WP_ENVIRONMENT_TYPE', 'staging' );

WordPress 5.5+ automatically adds noindex headers when the environment type is set to staging.

Step 8 - Set up Nginx for the staging subdomain

server {
    listen 443 ssl;
    server_name staging.yourdomain.com;
    root /var/www/staging.yourdomain.com;

    # Basic auth to prevent accidental access
    auth_basic "Staging";
    auth_basic_user_file /etc/nginx/.htpasswd;

    include /etc/nginx/snippets/wordpress.conf;
}

Add basic HTTP authentication to prevent anyone from accessing the staging site directly. Create the password file:

htpasswd -c /etc/nginx/.htpasswd staginguser

Method 4 - Local development environment

For development work (rather than pre-launch testing), a local environment is more efficient than a remote staging server.

LocalWP (formerly Local by Flywheel): The industry standard for WordPress local development. Download at localwp.com. One-click WordPress setup on your machine. Supports Nginx or Apache, multiple PHP versions, and push to live site via the host's integration (supported for WP Engine, Kinsta, Flywheel, and others).

DevKinsta: Similar to LocalWP, built by Kinsta. Free, includes database management and email testing.

Local environments are faster to work with than remote staging (no upload/download times) but require a manual push process to get changes to the staging or live server.

Keeping staging in sync

Staging environments drift from the live site over time. Before testing major changes, re-sync:

# Pull fresh database from live
wp db export /tmp/sync-$(date +%Y%m%d).sql --path=/var/www/html

# Import to staging
wp db import /tmp/sync-$(date +%Y%m%d).sql --path=/var/www/staging.yourdomain.com

# Update URLs
wp search-replace 'https://yourdomain.com' 'https://staging.yourdomain.com' --all-tables --path=/var/www/staging.yourdomain.com

Plugin-based staging tools (WP Staging, WPvivid) have "re-sync" buttons that do this automatically.

What to test on staging

Before every major update run:

• Update all plugins and themes on staging first
• Browse the most important pages (homepage, key landing pages, checkout)
• Submit a test order (for WooCommerce sites)
• Check for JavaScript console errors

Before any theme change:

• Test on mobile (use browser devtools or a real device)
• Check all page templates
• Verify custom post types and templates

Before code deployments:

• Full regression test of affected functionality
• Performance test (run PageSpeed Insights on staging URL)

A staging site only adds value if you actually use it. Make it part of the workflow, not an afterthought.

Related reading

• WordPress Client Onboarding Process
• Best WordPress Backup Plugins 2026
• WordPress Child Theme Guide