How to Create a WordPress Staging Site (Using Your Host, a Plugin, or Subdomain)

The first time I updated a “simple” plugin on a client site, the header vanished and the checkout stopped working, causing a site crash. This is often the result of updating plugins on a live site without testing. Nothing like watching real sales fall over to teach a lesson fast.

Since then, I don’t touch production without a WordPress staging site. It’s my rehearsal space, where I can break things on purpose, fix them, and only then make the live site match to prevent issues on the live site.

Below are three practical ways I set up staging: with my host’s staging tool, with a WordPress plugin, or manually on a subdomain. Pick the one that fits your hosting and comfort level.

Before I clone anything, I set safety rails (backup, access, noindex)

A staging environment is a copy of your WordPress files plus your database. That means it can also copy sensitive stuff: customer details, order history, and form entries. So I treat it like a private workspace, not a public “second site” like the production site.

Here’s what I do every time:

• Make a restore plan first. A full backup (files + database) is essential before starting the cloning process, and I want to know how I’ll roll back and restore backup. Host snapshots are great, but I still like having my own backup too. If you need a fast way to duplicate a site, this guide on how to clone a WordPress site is a solid foundation.
• Block public access. Password-protect the staging URL (Basic Auth), restrict by IP, or at least keep it behind a login. The goal is simple: no random visitors, no bots.
• Disable search indexing. In the staging environment, I check the WordPress setting to discourage search engine indexing of this site, and I also confirm my SEO plugin sets noindex. If you want a second viewpoint on staging setup basics, Hostinger’s walkthrough is a useful reference: set up a WordPress staging environment.
• Don’t test real payments or emails. I never run live payment gateways on staging since the live site should remain the only place for real transactions, and I avoid sending real customer emails. Use sandbox modes, disable email, or route mail to a safe inbox.

My rule: if the staging environment can be found in Google, it’s not staging. It’s a leak.

To help you choose quickly, here’s the simplest comparison.

Method	Best for	Why I use it	Main watch-out
Hosting provider staging tool	Beginners, busy site owners	One-click clone and often one-click push	Pushing can overwrite live database content
Staging plugin	Shared hosting, no host tool	Works almost anywhere inside wp-admin	Large sites can be slow to copy
Manual subdomain	DIY users, custom setups	Full control over files, database, and config	Most steps, easiest to miss a security setting

Method 1: Create staging with your host’s built-in tool (fast and usually safest)

If your hosting provider offers staging, I start there. As of early 2026, many managed WordPress hosting services include one-click staging on certain plans (you’ll often see this on managed tiers). When it’s available, it’s the cleanest workflow.

Steps (host staging)

1. Log in to your hosting panel and find a Staging section (sometimes under WordPress tools).
2. Click to create staging site and pick your main site as the source.
3. Choose where staging lives, usually something like staging.yoursite.com or a random staging URL.
4. Wait for the copy to finish, then log in to the staging WordPress admin (some hosts create a separate admin URL).
5. Lock staging down with a password or access rules, then confirm noindex.
6. Test your changes (updates, theme edits, new plugins).
7. Push to production using the host’s “Deploy” or “Push” feature, and choose what to push (files only vs files + database) if your host supports it.

The “push to production” step is where people get hurt. If you push the staging database to production, you might overwrite new blog comments, new orders, or new form entries collected since the staging copy was created.

So, for active sites, I prefer pushing files only (theme, plugins, uploads) unless I truly need database changes too. Always maintain a backup before using the host’s push feature.

If you’re still picking a hosting provider and a WordPress staging site is a must-have, I’d compare deployment options that include staging and backups up front. This roundup of best WordPress hosting plans helps narrow that down.

Method 2: Create a staging site with a plugin (best when your host lacks staging)

When a host doesn’t provide staging, I use a WordPress plugin. The basic idea stays the same: copy files, copy database, rewrite URLs, then protect the staging site.

A few well-known options include the WP Staging plugin, Duplicator (often used for cloning), WPvivid, and BlogVault. Exact buttons vary, but the workflow is predictable.

Steps (plugin staging)

1. Take a full backup of the live site (again, because copying is still a “big change”).
2. Install a staging plugin, like the WP Staging plugin, and run its cloning process.
3. Pick a staging location, often a subdirectory like /staging/ or a subdomain if the plugin supports it.
4. Let the plugin copy files and the database. On larger sites, this can take a while.
5. Log in to staging and do your testing there.
6. Handle push-to-live carefully. Some plugins support pushing changes back. If yours does, read what it overwrites before you click confirm.

If you’re evaluating tools, I like skimming documentation to see how they handle URL rewriting, database copying, and push-to-live. For example, the WP Staging plugin’s docs explain their clone workflow here: create a staging site and clone WordPress. For a broader list of plugin options, InMotion’s overview is a decent starting point: best WordPress staging plugins.

One more practical note: staging plugins can bump into server limits (PHP memory, max execution time, file permissions). If a copy fails, I usually fix it by increasing limits via your hosting provider, or I switch to the manual subdomain method below.

Method 3: Create a staging site on a subdomain (manual, flexible, and very “real”)

When I need full control, I use this manual setup approach to build a staging environment on a subdomain like staging.example.com. This feels old-school, but it works on almost any host, and it teaches you how WordPress really fits together (file system plus database).

Steps (subdomain staging)

1. Create the subdomain using cPanel in your hosting control panel and point it to a folder like /public_html/staging/.
2. Copy your WordPress file system from the live site to the staging folder (via File Manager or SFTP). This includes wp-content, plugins, themes, and uploads.
3. Create a separate database and database user for staging. I keep names obvious, like example_staging.
4. Export the live database tables and import them into the staging database (phpMyAdmin is the standard tool on shared hosting).
5. Update wp-config.php in the staging folder to use the staging database name, user, and password.
6. Update URLs inside the staging database from https://example.com to https://staging.example.com. Many people do this with a search-replace tool; just be careful with serialized data.
7. Protect staging and set noindex. I also remove staging from XML sitemaps if an SEO plugin tries to include it.
8. Test everything, especially forms, logins, and any membership or store features. This method keeps the live site completely isolated until testing is complete.

Sometimes you’ll hit a weird issue where staging loads but looks “blank” or points to the wrong place. When that happens, I check the site URL settings in the database, and I confirm the table prefix in wp-config.php matches the imported tables (for example, wp_ vs a custom prefix).

If you like working from the command line, staging also pairs nicely with WP-CLI for database exports and updates. This reference on WP-CLI update commands is handy once you’re comfortable with SSH.

Wrap-up plus a quick push-to-live checklist I actually follow

A WordPress staging site is just insurance you can use. Once you’ve got a WordPress staging site, updates feel boring again, and boring is good.

Here’s my short checklist for before and after you push changes live.

Before you push to live

• Confirm fresh backups exist (files + database), and you can restore them. A solid backup is your safety net.
• Make sure staging is private (password, IP rules) and set to noindex.
• Disable real payments and email sending on staging.
• Test your change paths: homepage, menus, search, forms, checkout, login.
• Decide what you’re deploying: files only vs files + database.

After you push to live

• Re-test the same key pages on the production site and live site.
• Clear caches (plugin cache, host cache, CDN) if you use them.
• Check error logs if something feels off.
• Keep staging around to sync staging and live for the next update cycle, but keep it locked down. This beats relying solely on a local environment for testing.

For those avoiding manual steps, the WP Staging plugin is a recommended alternative.

If you want one mindset shift to stick, it’s this: treat production like a storefront window, and do your work in the back room. That’s what staging is for.