How to Set Up a WordPress Staging Environment (Without Breaking Your Live Site)

Overview

A WordPress staging environment is a private copy of your live site where you can test updates, theme changes, plugin installs, or custom code without any risk to your production site. If something breaks on staging, only you see it. If it breaks on live, your visitors do.

Most hosting accounts support staging in some form — but the setup process varies depending on whether you’re on shared hosting, a VPS, or a managed WordPress plan. This article covers the main approaches so you can pick what fits your situation.

You’ll want this guide before updating WordPress core, switching themes, installing an unfamiliar plugin, or making any significant change to a site that you can’t afford to have down.

Prerequisites

• Active WordPress site on a Host & Tech hosting account (shared, VPS, or managed WordPress)
• cPanel access or SSH access to your server
• A domain or subdomain to host the staging site (e.g. staging.yourdomain.com)
• WP-CLI installed if you’re using the command-line method (pre-installed on most Host & Tech VPS plans)
• Enough disk space to hold a second copy of your site — check your quota in cPanel under Disk Usage

Method 1: Manual Setup via cPanel (Recommended for Shared Hosting)

This method works on any cPanel-based shared hosting plan. It gives you full control and doesn’t rely on third-party plugins.

1. Create a subdomain for staging.

   Log into cPanel, go to Domains > Subdomains, and create staging.yourdomain.com. Set the document root to something like /public_html/staging. cPanel will create the directory automatically.

2. Copy your WordPress files.

   In cPanel, open File Manager, navigate to /public_html, select all WordPress files, and copy them into /public_html/staging. If your site is large, SSH is faster:

   Copied to clipboard

   cp -r /home/yourusername/public_html/. /home/yourusername/public_html/staging/

3. Create a new database for staging.

   In cPanel, go to MySQL Databases and create a new database — name it something obvious like yourusername_staging. Create a database user and assign it full privileges to that database. Write down the credentials; you’ll need them in a moment.

4. Export and import your live database.

   Go to phpMyAdmin, select your live database, click Export, and download the .sql file. Then select your new staging database, click Import, and upload that file.

   📝 Note: If your database is over 50MB, phpMyAdmin may time out. Use SSH instead:

   Copied to clipboard

   mysqldump -u yourusername -p live_db_name > /tmp/live_backup.sql
   mysql -u yourusername -p staging_db_name < /tmp/live_backup.sql

5. Update wp-config.php in the staging directory.

   Open /public_html/staging/wp-config.php in File Manager or via SSH. Update these three lines to point to your staging database:

   Copied to clipboard

   define( 'DB_NAME', 'yourusername_staging' );
   define( 'DB_USER', 'staging_db_user' );
   define( 'DB_PASSWORD', 'your_staging_password' );

6. Update the site URL in the staging database.

   Your staging database still has your live domain in it. You need to update it or WordPress will redirect every page back to your live site. The cleanest way is WP-CLI:

   Copied to clipboard

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

   If you don’t have WP-CLI, use phpMyAdmin to manually update the siteurl and home values in the wp_options table.

   ⚠ Warning: Don’t skip this step. If the URLs still point to your live domain, any changes you save on staging will actually affect your live database if both sites share the same database — which they won’t in this setup, but URL mismatches will cause redirect loops regardless.

7. Restrict access to the staging site.

   You don’t want Google indexing your staging site or visitors stumbling onto it. Add password protection via cPanel under Security > Directory Privacy, or add this to /public_html/staging/.htaccess:

   Copied to clipboard

   AuthType Basic
   AuthName "Staging"
   AuthUserFile /home/yourusername/public_html/staging/.htpasswd
   Require valid-user

   Also go into WordPress Admin > Settings > Reading on the staging site and check Discourage search engines from indexing this site.

Method 2: Using WP-CLI on a VPS (Faster for Developers)

If you’re on a Host & Tech VPS with SSH access, this is quicker. WP-CLI handles the database URL replacements and config updates in one pass.

1. Copy files and create the staging database as described in Method 1, steps 1–4.
2. Run the full staging setup from the command line:
   Copied to clipboard

   cd /home/yourusername/public_html/staging
   
   # Update wp-config.php database settings
   wp config set DB_NAME yourusername_staging
   wp config set DB_USER staging_db_user
   wp config set DB_PASSWORD your_staging_password
   
   # Replace live URL with staging URL across all tables
   wp search-replace 'https://yourdomain.com' 'https://staging.yourdomain.com' --all-tables
   
   # Flush rewrite rules
   wp rewrite flush

3. Verify the site loads correctly by visiting https://staging.yourdomain.com in your browser.

Method 3: Plugin-Based Staging (Easiest for Non-Technical Users)

If you’d rather not touch the command line, plugins like WP Staging (free tier available) or Duplicator Pro can clone your site to a subdirectory with minimal configuration. The free version of WP Staging creates a staging copy at yourdomain.com/stagingsite-[randomstring].

📝 Note: Plugin-based staging is convenient, but I’d recommend the manual method for anything mission-critical. Plugins abstract away a lot of the URL replacement and database handling — which is fine until something goes wrong and you’re not sure what the plugin actually did.

If you’re on our Managed WordPress Hosting plan, one-click staging is built into the control panel. You can push and pull between staging and production without touching a config file. That’s genuinely the easiest path if you’re managing multiple WordPress sites.

Common Issues & Troubleshooting

Staging site redirects back to the live site

This almost always means the siteurl and home values in wp_options still point to your live domain. Run the wp search-replace command again, or manually update those two rows in phpMyAdmin. Also check wp-config.php — if you have hardcoded WP_HOME or WP_SITEURL constants defined there, they’ll override the database values.

White screen of death on the staging site

Usually a PHP error that WordPress is suppressing. Enable debug mode by adding these lines to wp-config.php on staging:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Then check /public_html/staging/wp-content/debug.log. Nine times out of ten it’s a plugin or theme trying to call an absolute file path from the live site.

Images and media not loading on staging

The database was copied but the wp-content/uploads folder may not have been included in your file copy. Check that /public_html/staging/wp-content/uploads/ exists and contains your media files. If the folder is there but images still 404, the issue is likely an incorrect uploads URL — run wp search-replace again and confirm all instances were replaced.

Database import fails in phpMyAdmin with a timeout error

phpMyAdmin has a default execution time limit that kicks in on larger databases (usually anything over 30–50MB). Use the SSH mysqldump / mysql method from Method 1, Step 4. Alternatively, upload the .sql file via File Manager and import it from the server’s local filesystem — that bypasses the browser upload limit entirely.

Staging site is being indexed by Google

This error is annoying because you might not notice until you see duplicate content warnings in Search Console. Make sure the Discourage search engines checkbox is enabled in WordPress reading settings, and add a noindex rule at the server level just to be sure. Add this to the staging .htaccess:

Header set X-Robots-Tag "noindex, nofollow"

Password-protecting the directory (as in Step 7 above) is the most reliable method since bots can’t get past HTTP authentication at all.

FAQ