WordPress Staging Site: What It Is and How to Set One Up

Most WordPress disasters share a backstory: someone clicked Update on the live site, and then watched it go white. A WordPress staging site is the cheap insurance against that. It is a private copy of your site where you can break things for free.

This guide covers what staging is, the three realistic ways to create one, the rules that keep it from emailing your customers or showing up in Google, and the part most tutorials gloss over: moving changes back to the live site without losing orders.

What a WordPress Staging Site Is

A staging site is a duplicate of your live site. It has the same theme, the same plugins, the same pages and a copy of the database, but it lives at a different address and it is hidden from the public.

Think of it as a rehearsal room. The live site is the stage with an audience watching. In the rehearsal room you try the new lighting, move the furniture and drop things on the floor, and nobody pays for the mistakes.

Developers often talk about several environments: local (on your own computer), development, staging and production. WordPress itself understands these names. The developer documentation for wp_get_environment_type() says the function returns local, development, staging or production, and that it falls back to production when the value is unset or invalid. You set it with the WP_ENVIRONMENT_TYPE constant, and plugins and themes can read it to behave differently on a test copy.

Why Use a Staging Site

You do not need one for a five-page brochure site that rarely changes. You do need one when downtime costs you something. These are the good reasons:

• Updates. Major WordPress, theme and plugin updates can clash with each other. Trying them on staging tells you which one breaks the checkout before a customer does. Staying current matters, as we explain in WordPress plugin vulnerabilities, so staging helps you update with confidence rather than delay.
• Redesigns. A new theme or page builder layout can be built over weeks without visitors seeing half a page.
• New plugins. Try a plugin, read what it does to page speed and settings, and delete it if you dislike it.
• Testing security settings. Some protections can lock people out or block good traffic if set too tightly: a custom login address, country blocking, firewall rules or strict browser security headers. Try them on a copy first.
• Debugging. If something is wrong on the live site, you can switch on error logging and poke around on staging without exposing errors to visitors.

If your site crashes anyway, our guide to the WordPress white screen of death shows how to recover in a calm order.

Three Ways to Create a WordPress Staging Site

Your Host's One-Click Staging

Many managed WordPress hosts have a staging button in their control panel. It copies files and database to a hidden address in a minute or two and often has a "push to live" button as well. This is the easiest route, and the host usually handles the details, such as a different database and a private address.

Check what the tool does with the database when you push to live. We cover why that matters below.

A Subdomain Copy

If your host has no staging tool, you can do it by hand:

1. Create a subdomain such as staging.yourdomain.com and a new empty database for it.
2. Copy your site's files into the subdomain's folder.
3. Export the live database and import it into the new one.
4. Edit wp-config.php on the copy to use the new database name, user and password.
5. Replace the old address with the new one throughout the database. Use a search-and-replace tool that understands serialized data, such as WP-CLI's search-replace command, because a plain text replace corrupts it.
6. Lock the copy down (see the next section) before you do anything else.

This is more work, but you control everything. A verified backup of the live site first means the copy starts from a known good state.

A Local Copy on Your Computer

Local tools run WordPress on your own machine, with no hosting involved. They suit developers and designers who want fast, private experiments, and nothing can leak because the site never goes online. The downsides are that your computer's setup differs from your server's, and there is no easy way for a client to review it.

Set Staging Up Safely

A copied site carries the habits of the original. It will happily try to do everything the live site does, and that causes the strange stories of staging sites sending hundreds of real emails. Set these protections up on day one.

Stop It Emailing Your Customers

A copy of a shop sends order confirmations. A copy of a membership site sends renewal reminders. A copy of a booking site sends appointment emails to real people about things that are not real.

The simplest fix is a plugin that disables or redirects outgoing mail on non-live sites. If you prefer code, WordPress has had a filter called pre_wp_mail since version 5.7. The developer reference explains that returning a non-null value stops the send and hands your value back instead. A small must-use plugin on staging does the job:

<?php
// Staging only: never send real email.
add_filter( 'pre_wp_mail', function () {
    return false;
} );

Also turn off anything else that talks to the outside world: payment gateways in live mode, SMS services, newsletter connections and scheduled webhooks. Switch the gateway to its test mode, and use test card numbers for any order you place.

Keep It Out of Google

Two layers, and you want both.

1. Discourage search engines. In Settings, then Reading, tick the option to discourage search engines from indexing the site. It adds a noindex signal. This is a polite request, and it is not a lock.
2. Password protect the whole thing. Use your host's password protection for the folder or subdomain, so a visitor gets a login prompt before WordPress even loads. Search engines and strangers cannot read what they cannot reach.

Be careful when you push to live. The "discourage search engines" setting lives in the database, so a careless push can carry it onto the real site and quietly hide your pages from Google. Check Settings, then Reading, after every push.

Mark It Clearly

Add an obvious label to the admin bar or the site title, such as "STAGING", and set WP_ENVIRONMENT_TYPE to staging in wp-config.php. The wp-config reference documents that constant. It stops the moment where you type a change into the wrong tab. Everyone has done it once.

Pushing Changes Back to Live

This is where staging goes wrong most often.

Files are easy. If you changed a theme or updated a plugin on staging, you can copy those files to live. The database is the hard part, because both sites kept living after you made the copy.

Picture a store. You copied it on Monday. On Tuesday and Wednesday, real customers placed orders, registered accounts and left reviews on the live site. Meanwhile you tested a new theme on staging. If you now overwrite the live database with the staging database, those Tuesday and Wednesday orders disappear. The files are fine, the money was taken, and the records are gone.

Key takeaway: Never replace a live database with a staging one unless the live site has been frozen since you made the copy. Push files, then redo database changes on live, or use a tool that merges selected tables.

Safer ways to handle it:

1. Redo settings changes by hand. If the change was a handful of options, apply them again on live. It is slow but safe.
2. Push files only for theme and plugin updates, and let the live database stay as it is.
3. Freeze the live site during a big redesign. A maintenance page for an hour is better than a lost day of orders.
4. Back up first, every time. A fresh backup of the live site just before the push is your way back if something is wrong.
5. Check after the push: forms, checkout, sign-in, the Reading setting and any cache.

Plugin and theme updates deserve a note. WordPress stores some version information in the database, so updating files alone can leave things out of step. Where possible, apply the same updates on live that you tested on staging, rather than copying their files across.

A Forgotten WordPress Staging Site Is a Security Risk

Here is the part nobody mentions. A WordPress staging site is often forgotten, and forgotten sites are bad news.

The copy holds your real data: user accounts, customer details, perhaps order history. It runs the same plugins as the live site, but nobody updates it. A year later it still runs the plugin version that had a known flaw. Attackers do not care that it is "just staging". It is a way into the same data, and sometimes into the same hosting account.

Treat it like any other site:

• Password protect it at the server level, as above.
• Keep it updated while it exists, or delete it. A stale copy is worse than none.
• Delete it when you are done. Make a new one next time. They are cheap.
• Use different admin passwords from the live site, and remove user accounts that do not need staging access.
• Do not leave live API keys in it. Use test keys or remove them.

The same attention helps on the live site, and our guide to the best WordPress security plugin shows what to look for in a tool that watches all your sites.

Where Stack Guard Fits

Stack Guard does not make a staging site for you. A backup made by Stack Guard can only be restored onto the same site address it came from, and moving a site to a new address is not supported yet. That makes it a poor tool for cloning a site to a staging address, so use your host's staging tool or a local development tool for that job.

What it does well is protect the work around staging. Make a verified backup of the live site before you push anything. Each backup is read back and checked before it counts, and a one-click restore is staged, with 7 days to keep or roll back. If a push goes wrong, you have a clean way back.

It is also useful for testing. Security settings that can lock people out carry a "Test after changing" marker, and the pages in compatibility show how Stack Guard behaves alongside caching plugins, page builders and shop plugins. Try a custom login address, a firewall rule or a stricter browser security policy on your copy first. Change one setting at a time, so you know what caused any problem. Then repeat the successful change on the live site.

Backups are manual in Free. Scheduled backups are coming soon.

A Short WordPress Staging Site Checklist

Before you start a round of changes on staging:

1. Create the copy and confirm it has its own database.
2. Password protect it and tick the setting that discourages search engines.
3. Block outgoing email and put payment gateways in test mode.
4. Set WP_ENVIRONMENT_TYPE to staging and label the admin bar.
5. Make your changes and test the things that earn money: forms, checkout and sign-in.
6. Back up the live site.
7. Apply the changes to live, files first.
8. Check live, then delete the staging copy or put it on a schedule to be updated.

That routine takes minutes, and it is far kinder than learning from a broken live site. If you want the bigger picture on keeping copies of your site, read our backup strategy guide.