How to Create a WordPress Staging Site in cPanel

You want to test a plugin update, a theme change, or a PHP version bump — but not on the site your customers are actually using. That's what a staging site is for: a private copy of your live WordPress install where you can break things safely. Here's how to build one in cPanel, step by step, without any guesswork on the database or URLs.

What a staging site actually is

A staging site is a full copy of your WordPress files and database, running on a separate subdomain (or subfolder), that isn't indexed by search engines and isn't linked from your live site. You make changes there first — update a plugin, switch a theme, test a PHP version — and only push to production once you've confirmed nothing broke.

Some managed WordPress hosts bundle a one-click staging tool. On standard cPanel shared hosting or a VPS with cPanel/WHM, you usually don't get that button, so you build the copy manually. It takes about 15 minutes once you've done it twice.

Step 1: Create a subdomain for staging

In cPanel, go to Domains → Create A New Domain (or Subdomains on older cPanel themes) and add something like:

staging.yourdomain.com

Point its document root to a new folder, for example public_html/staging, separate from your live site's root. cPanel will provision the subdomain and issue a free AutoSSL certificate for it within a few minutes — check SSL/TLS Status if it doesn't show as secure right away.

Step 2: Copy the WordPress files

You have two practical options depending on site size:

• File Manager (small-to-medium sites): select your live public_html contents, right-click → Copy, and paste them into public_html/staging. For sites under a few hundred MB this is fine; anything larger will time out in the browser.
• SSH (faster, works for any size): use rsync or cp -r so file ownership and permissions come across cleanly:

  rsync -av --exclude 'wp-content/cache' /home/USER/public_html/ /home/USER/public_html/staging/

Excluding the cache folder saves time and avoids copying stale cached HTML into the new environment.

Step 3: Clone the database

In phpMyAdmin, export your live database (Export → Quick → SQL). Then create a new, separate database and user in cPanel's MySQL Databases tool — don't reuse the live one, staging needs its own copy so test data never touches production.

1. Create database, e.g. user_staging_wp
2. Create a database user and add it to the new database with All Privileges
3. In phpMyAdmin, select the new database and Import the SQL file you exported

Step 4: Point staging at the new database

Open public_html/staging/wp-config.php and update the three database constants to match the new credentials:

define( 'DB_NAME', 'user_staging_wp' );
define( 'DB_USER', 'user_staging_user' );
define( 'DB_PASSWORD', 'new-strong-password' );

Leave DB_HOST as localhost unless your original site used something different.

Step 5: Fix the URLs (the step people skip)

WordPress stores its site URL inside the database, not just in config files. If you skip this, staging will keep redirecting you back to the live domain. The reliable way is a proper search-replace, not a manual edit of wp_options.

If you have SSH access, WP-CLI is the fastest and safest route:

cd public_html/staging
wp search-replace 'https://yourdomain.com' 'https://staging.yourdomain.com' --all-tables

No SSH? Install a plugin like Better Search Replace on the staging copy only, and run the same replacement through its dashboard UI. Either way, always keep a backup of the export before running search-replace — it rewrites data across every table.

Step 6: Keep it out of Google

A staging site with your real content is exactly what you don't want indexed. Two things, both required:

• In Settings → Reading on the staging site, check Discourage search engines from indexing this site.
• Add HTTP Basic Auth or a cPanel password-protected directory on /staging so random visitors and bots can't browse it either — the WordPress setting alone only asks bots nicely, it doesn't block them.

Step 7: Test, then push changes back to live

Once staging is working, this is where you actually update plugins, switch themes, or test a PHP version change (via MultiPHP Manager) without any risk to visitors. When you're happy with the result, push the specific change back to production — usually that means updating the same plugin/theme on the live site directly, since syncing an entire staging copy back to production risks overwriting live orders, comments, or form submissions that happened while you were testing.

Common problems and fixes

Staging keeps redirecting to the live domain

The search-replace in Step 5 didn't cover every table, or a caching plugin cached the old URL. Clear any object/page cache on staging and re-run wp search-replace with --all-tables, not just the default WordPress tables — some plugins store URLs in custom tables that the default scope misses.

Mixed content warning on staging only

AutoSSL for the new subdomain hadn't finished issuing when you first loaded the site, or a plugin has the old http:// URL hardcoded. Check SSL/TLS Status in cPanel, and re-run the search-replace step scoped to http://staging if needed.

"Error establishing a database connection" on staging

Almost always a typo in the three DB constants from Step 4, or the new database user wasn't actually granted privileges on the new database. Re-check both in cPanel's MySQL Databases tool.

Prevention: make this routine, not a one-off

Keep the staging subdomain around permanently instead of rebuilding it every time. Refresh its files and database from live every few weeks (or before any risky update) using the same rsync and search-replace commands above. A staging site that's a year out of date is barely better than no staging site at all.