WordPress Staging Sites – Safe Place to Test Changes

A staging site is a copy of your live WordPress site where you can test theme updates, plugin changes, redesigns, and content reorganization without risk. Break it, fix it, throw it away — the live site never sees any of it. For any site that earns revenue or matters professionally, staging is essential. This guide covers creating a staging site on iWebVault, working with it, and pushing changes back to production safely.

Why staging matters

• Plugin updates can break sites. A plugin that worked yesterday can release an update incompatible with your theme today. Test on staging first.
• Theme changes need iteration. Tweaking CSS, trying layouts — visitors don’t need to see your experiments.
• PHP version upgrades. Move staging to PHP 8.2 first; verify everything works before changing production.
• Major content reorganization. Restructure categories, taxonomies, URL patterns on staging; once stable, replicate to production.
• Client review. Show stakeholders changes before they go live.

Sites that learn the staging habit experience dramatically fewer “the site went down after I clicked update” emergencies.

Three approaches to staging

Approach 1: Subdomain staging

Create staging.yourdomain.com as a subdomain pointing to a separate folder. Install WordPress there as a copy of production.

• Pros: simple, accessible from anywhere with a real URL, can use HTTPS.
• Cons: publicly visible (block via .htaccess if needed), separate database/files to keep in sync.

Approach 2: Plugin-managed staging

Plugins like WP Staging create staging copies of your live site within the same account, behind a special URL like yourdomain.com/wp-staging-1234.

• Pros: one-click creation, syncing tools, push changes back to production.
• Cons: shares resources with production, hidden URL may not work for all setups.

Approach 3: Local development

Use Local (by Flywheel), MAMP, XAMPP, or Docker to run a copy of your site on your computer. Push changes to a real staging URL or directly to production when ready.

• Pros: fastest iteration (no upload step), works offline.
• Cons: not accessible to other reviewers, environment may differ from production.

This guide focuses on Approach 1 (subdomain staging) as the most universal and reliable.

Setting up subdomain staging

Step 1: Create the subdomain

1. cPanel → Domains → Create A New Domain.
2. Domain: staging.yourdomain.com.
3. Document Root: public_html/staging/ (default suggested).
4. Create.

AutoSSL issues an SSL cert for the staging subdomain automatically.

Step 2: Copy production files to staging

Via SSH:

cp -r ~/public_html/* ~/public_html/staging/
# Exclude .well-known to avoid AutoSSL confusion
rm -rf ~/public_html/staging/.well-known

Or via File Manager:

1. Select all files in public_html (except the staging folder itself).
2. Copy to public_html/staging/.

For large sites, SSH is much faster.

Step 3: Create separate database for staging

1. cPanel → MySQL Databases.
2. Create database: user_staging.
3. Create user (different from production user): user_staginguser.
4. Add user to database with all privileges.

Step 4: Copy production database to staging

1. phpMyAdmin → production database → Export → Quick → SQL → Go. Saves file.
2. phpMyAdmin → staging database → Import → Choose file → Go.

Now staging database is identical to production.

Step 5: Update staging wp-config.php

Edit public_html/staging/wp-config.php:

define( 'DB_NAME',     'user_staging' );
define( 'DB_USER',     'user_staginguser' );
define( 'DB_PASSWORD', 'staging_password' );
define( 'DB_HOST',     'localhost' );

Step 6: Update siteurl and home in staging database

phpMyAdmin → staging database → wp_options table:

• Find siteurl row → change value to https://staging.yourdomain.com.
• Find home row → same.

For full URL replacement throughout content, use Better Search Replace plugin (install on staging after Step 6):

• Tools → Better Search Replace.
• Search for: https://yourdomain.com
• Replace with: https://staging.yourdomain.com
• Select all tables → Dry run first to see what would change → Live run when satisfied.

Step 7: Verify staging loads

Visit https://staging.yourdomain.com. Should show a copy of your live site. Log in with the same WordPress credentials as production.

Hiding staging from public/search engines

Staging shouldn’t show up in Google. Two layers:

Block search engines (in WP admin)

Settings → Reading → “Discourage search engines from indexing this site” → check the box. Adds noindex header.

HTTP auth (basic password protection)

cPanel → Directory Privacy → public_html/staging → Enable → set username and password.

Now anyone accessing staging.yourdomain.com sees a browser-level login prompt before reaching WordPress. Search bots can’t crawl past this either.

Working in staging

• Test plugin updates here first. Update on staging, browse the site, verify nothing’s broken, then update production.
• Theme development. Make CSS/template changes on staging, iterate, then sync to production.
• Major content changes. Restructure categories, redirect chains, taxonomy — test the URLs and SEO impact on staging.
• Plugin trials. Test new plugins before deploying. Many plugins are great in marketing but break specific themes.

Don’t put real customer data in staging. If your production DB has customer info, search-replace email addresses on staging to fake+1@example.com so you don’t accidentally email real customers from tests.

Pushing changes from staging to production

Once staging changes are tested and ready, you need to push them to production. Several scenarios:

Plugin / theme files only

Easiest case. Copy the changed plugin/theme folder from staging to production:

# Update a specific plugin
cp -r ~/public_html/staging/wp-content/plugins/myplugin ~/public_html/wp-content/plugins/

# Update theme
cp -r ~/public_html/staging/wp-content/themes/mytheme ~/public_html/wp-content/themes/

Production site picks up the changes instantly. Test production immediately.

Database changes

Riskier. If you’ve added posts/pages/products on staging:

• WP-CLI: wp post create commands can recreate them on production. Tedious for many items.
• Export specific posts via WordPress → Tools → Export → import on production.
• Or simply redo the changes on production (often easiest for small amounts).

If you’ve changed widespread DB content (taxonomy, options), more careful approach: export specific tables from staging, import to production. Risk of overwriting production-only changes (new orders, comments) — back up production first.

Full sync (overwrite production with staging)

For big rewrites — completely replace production with staging:

1. Back up production fully (JetBackup or manual).
2. Take production into maintenance mode (.maintenance file or plugin).
3. Export staging DB.
4. Import to production (search-replace URLs back: staging.yourdomain.com → yourdomain.com).
5. Copy staging files over production (excluding wp-config.php).
6. Verify production loads correctly.
7. Disable maintenance mode.

This is the most error-prone scenario. Practice on test sites before doing it for the first time on production.

WP Staging plugin approach

For sites that prefer plugin-managed staging:

1. Install WP Staging on production.
2. WP Staging → Create New Staging Site → click. Plugin clones into a subdirectory with prefixed DB tables.
3. Staging URL: shown in plugin admin, like yourdomain.com/wp-staging-1.
4. Test changes in staging admin.
5. For Pro version: “Push” feature syncs staging back to production with conflict detection. Free version: manual sync.

Convenient but couples production and staging — heavy staging work affects production performance.

Common staging issues

“Staging redirects to production.” Either siteurl/home values still point to production, or .htaccess has a redirect to production. Update DB and check .htaccess.

“Mail from staging goes to real customers.” Disable email plugins on staging, or install a “stop emails” plugin. WP Mail SMTP has a “log only, don’t send” mode.

“Staging works but production doesn’t after sync.” Sync didn’t include something — usually wp-config.php (correctly excluded) or .htaccess (sometimes excluded). Verify what was copied.

“Staging shows old content despite updates.” LiteSpeed Cache caching staging URLs. Purge cache on staging. Or disable cache entirely for staging (plugin set to dev mode).

What’s next

• Subdomain setup details: Subdomains guide.
• Files copying tools: File Manager or FTP/SFTP.
• Backup before sync: JetBackup.

The first time you set up staging takes an hour. Every subsequent time you test a sketchy plugin update there instead of in production, you save yourself an emergency. After a few months, staging becomes muscle memory and the worry of “this update might break my site” disappears.