How to Set Up a WordPress Staging Site

A staging site is a private copy of your live WordPress site where you can test plugin updates, theme changes, and core upgrades without any risk to the site your customers actually see. Every Ultra Web Hosting account has the tools to run one, and this guide covers both the one-click way (WordPress Toolkit or Softaculous in cPanel) and the manual way, plus the single mistake that can wipe out live orders when you push changes back to production.

01. Why You Never Test Updates on a Live Site

WordPress runs on a stack of moving parts: the core software, your active theme, and every plugin you have installed. Any update to any one of them can conflict with the others. A plugin update that works fine on ten thousand sites can still white-screen yours because of the specific combination you run. When that happens on your live site, your visitors see the broken version while you scramble to fix it.

A staging site removes that gamble. You apply the update on a private copy first, click through the site, and only touch production once you know the update is clean. The things most worth testing on staging before they go live:

• Core, theme, and plugin updates - the single most common cause of a site breaking after a routine update.
• New plugins - especially anything that touches checkout, forms, caching, or security.
• Theme changes and redesigns - layout work you do not want half-finished in public.
• PHP version bumps - old plugins sometimes break on a newer PHP; staging tells you before your live site does.

02. Two Ways to Build a Staging Site

There are two paths to a working staging site on your account. The one-click tools do the whole clone in a couple of clicks and, crucially, can push your changes back for you. The manual method is more work but shows you exactly what is happening and works even for setups the automated tools do not recognize.

03. Option A: One-Click Staging in cPanel

Both WordPress Toolkit and Softaculous are available in cPanel. Use whichever manages your site. The flow is the same: clone to staging, work on the copy, push back.

With WordPress Toolkit

1. Log in to cPanel and open WordPress Toolkit.
2. Find your site in the list and click Clone.
3. For the destination, choose Create subdomain and enter something like staging. The toolkit creates staging.yourdomain.com and copies the files and database into it.
4. Click Start and wait for the clone to finish. The toolkit rewrites the site URL to the staging subdomain automatically.
5. Open staging.yourdomain.com/wp-admin and make your changes there.
6. When you are ready, return to the toolkit, select the staging copy, and click Copy Data (the push). You choose whether to push files, database, or both. Read Section 07 before you push the database.

With Softaculous

1. In cPanel, open Softaculous Apps Installer and go to the WordPress management page (the wrench or edit icon on your install).
2. Click Create Staging. Pick or create a subdomain such as staging.yourdomain.com and let Softaculous copy everything across.
3. Work on the staging install at its own admin URL.
4. When finished, use Push to Live from the same panel. Softaculous lets you select exactly which files and database tables to move. Again, read Section 07 first.

04. Option B: Manual Staging, Step by Step

If you would rather do it by hand, or the toolkit does not see your install, here is the full manual process. You will create a subdomain, copy the files, clone the database, and point wp-config at the copy.

1. Create the subdomain. In cPanel, open Domains (or Subdomains) and add staging.yourdomain.com. Note the document root it creates, usually /public_html/staging. See How to Create an Addon Domain or Subdomain if you need the walkthrough.
2. Copy the files. In File Manager, select everything in your live document root (typically /public_html), compress it to a zip, and extract that zip into the staging document root. Or copy the folders across directly. Every file, including wp-config.php, comes with it.
3. Create a new database. Open MySQL Databases, create a fresh database such as user_stg, create a database user, and add that user to the database with all privileges.
4. Clone the data. In phpMyAdmin, select your live database, use Export to download a SQL dump, then select the new staging database and Import that dump. You now have an identical copy of the data.
5. Point wp-config at the copy. Edit wp-config.php in the staging document root and update the database settings so staging uses its own database, not the live one:

define( 'DB_NAME', 'user_stg' );
define( 'DB_USER', 'user_stguser' );
define( 'DB_PASSWORD', 'your-staging-password' );
define( 'DB_HOST', 'localhost' );

1. Fix the site URL. The imported database still holds the live URL everywhere. The clean way to swap it is a search-replace tool that handles serialized data. Upload the free WP-CLI or a search-replace script, or run this from the staging document root if you have shell access:

wp search-replace 'https://yourdomain.com' 'https://staging.yourdomain.com' --skip-columns=guid

If you cannot run WP-CLI, set the two URL rows directly in phpMyAdmin: in the staging database, open the wp_options table and change siteurl and home to https://staging.yourdomain.com. That covers the basics, though a full search-replace is better because it also catches URLs baked into posts and widgets.

05. Keep Staging Private and Out of Google

A staging site is a full working copy of your site sitting on a public subdomain. Left open, search engines will crawl and index it, which creates duplicate content and, worse, exposes an unfinished or test version of your site to anyone who finds the URL. Lock it down.

Password-protect the directory. This is the strongest option. It puts an HTTP login in front of the whole staging site so no visitor and no search bot gets in without the password.

1. In cPanel, open Directory Privacy (also called Password Protect Directories).
2. Navigate to the staging document root, for example public_html/staging, and open it.
3. Tick Password protect this directory, give it a name, and save.
4. Create a user and password under Create User. Now the whole staging subdomain prompts for that login.

The full walkthrough with screenshots is in How to Password Protect a Directory.

Discourage search engines in WordPress. As a second layer, in the staging wp-admin go to Settings > Reading and tick Discourage search engines from indexing this site. That adds a noindex instruction. Treat it as a backup to the password, not a replacement, since it only asks well-behaved bots to stay away.

06. Make and Test Your Changes

With staging cloned and locked down, this is where the value is. Do the risky work here and click through everything before it goes near production.

1. Apply updates. Update WordPress core, then the theme, then plugins, one batch at a time. After each, load the front page and a few inner pages to catch a break early.
2. Try new plugins. Install and configure anything new. Watch for conflicts with your existing plugins, especially caching and security tools.
3. Build the redesign. Theme edits, layout changes, and new templates all belong here where an unfinished state is invisible to visitors.
4. Test the important flows. Submit a contact form, run a test checkout, log in as a member, whatever your site actually does. A page that renders can still have a broken form.
5. Check on a phone. Load staging on mobile. Layout issues that pass on desktop often show up on a small screen.

07. Push Staging Back to Production

Your changes are tested and you are ready to make them live. This is the step to slow down on, because how you push depends entirely on what you changed and whether your live site is collecting new data.

Decide what to push based on what you changed:

• You updated plugins, themes, or core, or edited templates: push files only. Those changes live in files, not the database, so pushing files gets your work live while leaving the live database (and its new orders and comments) untouched.
• You changed settings, menus, or content that lives in the database, on a site with no live data coming in: a full push (files plus database) is fine. Best for brochure sites and low-traffic blogs where nothing new arrives between clone and push.
• You changed database content on an active site: do not push the database. Re-do those specific changes by hand on production instead. It is a little more work, but it does not throw away live data.

Pushing with the one-click tools

1. In WordPress Toolkit, select the staging copy and choose Copy Data. In the dialog, under what to copy, pick Files only for an update, or Files and database only if the live site has no new data. Confirm and run it.
2. In Softaculous, use Push to Live and select the files and, if truly safe, the database tables to move.
3. Both tools take a backup of production before overwriting. Confirm that ran so you have a rollback point.

Pushing manually

1. Back up production first. A full backup of the live files and database, no exceptions. See How to Back Up Your Website.
2. Copy the changed files from the staging document root to the live one in File Manager: the updated plugin, theme, or core folders. Do not overwrite wp-config.php, since live has its own database settings.
3. Leave the live database alone unless you have decided a full replace is safe. If you must move database content, export only the specific tables you changed rather than the whole database.
4. Clear the live cache and load the site. Check the pages and flows you changed.

08. Clean Up and Delete the Staging Copy

Once your changes are live and confirmed working, delete the staging site. A forgotten staging copy is a stale, unpatched, publicly reachable clone of your site, which is exactly the kind of thing that gets exploited.

1. Confirm production is good. Click through the live site and verify the changes you pushed are working before you remove your safety copy.
2. Delete via the tool that made it. In WordPress Toolkit or Softaculous, use the remove or delete option on the staging install. It removes the files and the staging database together.
3. For a manual staging site, delete the staging document root in File Manager, drop the staging database in MySQL Databases, and remove the staging subdomain under Domains.
4. Remove the Directory Privacy entry if you protected the folder and are not reusing the subdomain.

09. A Warning for WooCommerce and Membership Sites

Everything above applies double to sites that collect data continuously. WooCommerce stores, forums, membership sites, and booking systems write new rows to the database around the clock: orders, payments, new members, posts, bookings. This creates what is called data drift, where staging and production diverge the moment you clone.

The practical consequences:

• Never push the staging database to a live store. Every order and every new customer since the clone lives only in production. A database push erases them. This is the number one way people lose real orders.
• Push files only, or re-do the change on production. For plugin and theme updates, push files and let the live database stand. For settings changes, make the same change directly on production during a quiet window.
• Do not process live payments or emails on staging. Put payment gateways in test mode on the staging copy and pause any transactional email so a test order does not charge a card or email a real customer.
• Keep the staging window short. The longer staging lives, the more the live database moves on, and the more dangerous a database push becomes. Clone, test, push files, delete.

Quick Recap: Staging in Six Steps

If you only remember six things from this guide, remember these:

1. Clone to a staging subdomain with WordPress Toolkit or Softaculous, or build it manually with a new subdomain, a copied file set, and a cloned database.
2. Lock staging down with Directory Privacy and the discourage-search-engines setting so it never gets indexed or found.
3. Do the risky work on staging: updates, new plugins, redesigns, and PHP bumps, then test every important flow.
4. Push files only for updates and code changes, so the live database and its new data stay intact.
5. Never push the database over an active store or busy site. Re-do database changes on production by hand instead.
6. Delete the staging copy once production is confirmed, so no stale clone is left exposed.

Last updated July 2026 · Browse all WordPress articles