WordPress Staging Site: How to Set One Up (and What It Won't Catch)

A staging site is the closest thing WordPress has to an undo button you can use before you make a mistake. You copy your live site, try the risky update or redesign on the copy, and only touch the real site once you know it works.

This guide covers the four ways to create a WordPress staging site, how to set it up so it does not leak into Google or email your customers, how to push changes live without losing orders, and the blind spots staging has that catch even careful teams.

What is a WordPress staging site?#

A staging site (or staging environment) is a full copy of your live WordPress site, files and database, running at a separate address that only you can reach. You use it to:

• Test plugin, theme, WordPress core and PHP updates.
• Try a new plugin before installing it on the live site.
• Build a redesign or new section without visitors seeing it half finished.
• Reproduce and fix a bug safely.

Your live site is called production. Many teams also use a local site on their own computer for development, so the flow is local, then staging, then production.

Method 1: One-click staging from your host (easiest)#

Most managed WordPress hosts include staging. The exact buttons differ, but the steps are similar:

1. Open your hosting dashboard (or the host's menu inside wp-admin).
2. Find Staging and click Create staging site. The host copies files and database to a staging address.
3. Log in to the staging copy with your usual username and password.
4. Test your changes.
5. When you are happy, use Push to live (also called deploy or publish). Good hosts let you choose files only, database only or both.

Hosts that offer staging include SiteGround, Kinsta, WP Engine, Bluehost (on its managed WordPress plans), Hostinger (on higher plans), DreamHost (DreamPress) and WordPress.com on its business plans. Host staging is the best option for most site owners: it is fast, it runs on the same server setup as your live site, and the push tools handle URL replacement for you.

Method 2: Use a staging plugin#

If your host has no staging, a plugin can create one inside your existing hosting account.

WP Staging is the most widely used. The free version clones your site into a subfolder with its own database tables in a few clicks: install it, go to WP Staging > Staging Sites, click Create New Staging Site, then Start Cloning. Pushing changes from staging back to live is a feature of the paid Pro version. Other options include InstaWP Connect and the staging tools built into some backup services such as BlogVault.

Plugin staging runs on the same server as your live site, so a heavy test (a big import, a broken loop) can slow down production too. Keep tests light, or use host or local staging for big work.

Method 3: Run a local copy#

A local site runs on your own computer with a free app such as Local or Studio by WordPress.com. Export a backup of your live site with your backup plugin, import it into the local app, and you have a private copy with no hosting cost.

Local sites are ideal for development and redesigns. They are less good for testing updates, because your computer's PHP version, server software, caching and CDN differ from your host, and differences cause different results.

Method 4: Create staging manually#

On basic hosting with cPanel you can build staging yourself:

1. Create a subdomain such as staging.example.com.
2. Copy all WordPress files to the subdomain's folder.
3. Export your database and import it into a new, empty database.
4. Edit wp-config.php on the copy to point to the new database.
5. Replace the site URL in the copied database (WP-CLI wp search-replace, or a search-and-replace tool that handles serialized data).
6. Protect the copy with a password (HTTP authentication in your hosting panel).

It is free and flexible, but it is the method most likely to go wrong, and pushing changes back is manual. Use it only if you are comfortable with databases.

Set up your staging site safely#

A staging copy is a full clone of your site, which includes things you do not want to clone. Before testing anything:

• Block search engines. Password-protect the staging site and tick Settings > Reading > Discourage search engines from indexing this site. A public, indexable staging site creates duplicate content and can show up in Google.
• Stop outgoing email. Staging has your real customer list. Disable outgoing email (an SMTP plugin setting or a "disable emails" plugin) so a test does not email real customers, send password resets or fire marketing automations.
• Switch payments to test mode. Put Stripe, PayPal and other gateways into sandbox mode so no real card is charged.
• Watch scheduled jobs. Subscription renewals, newsletter sends and sync jobs run on WP-Cron in the copy too. Pause the ones that touch real people or real systems.
• Mark the environment. Set WP_ENVIRONMENT_TYPE to staging in wp-config.php (supported since WordPress 5.5). Some plugins read it and change their behavior, and it reminds everyone where they are.

How to test updates on staging#

1. Refresh staging from live first, so you test against today's content, plugins and settings.
2. Update one thing at a time: one plugin, then check; the next plugin, then check. See how to safely update WordPress plugins.
3. Check what matters, not just the home page: key landing pages, forms, cart and checkout, the login, and the page source for titles, canonicals and robots tags.
4. Watch the logs and the browser console for new errors. If something breaks, see WordPress plugin conflict.
5. Write down what you changed and in what order, so you can repeat it exactly on production.

Pushing staging to live without losing data#

This is where staging causes its own disasters. The database is the problem: while you tested on staging, your live site kept receiving orders, form entries, comments and new users. If you push the whole staging database over live, all of that is overwritten.

Safer options:

• Push files only for plugin, theme and code changes, then repeat any settings changes on live by hand.
• Push selected tables if your host or plugin supports it, leaving orders, users and form entries untouched.
• For WooCommerce and membership sites, never push the full database. Apply updates on live directly (after testing on staging), during a quiet hour, with a backup.
• Take a backup of live right before you push, so you can undo the push itself.

The staging gotcha that deindexes sites#

Remember the "Discourage search engines" box you ticked on staging? That setting is stored in the database. Push the staging database to live and the live site now tells Google not to index it. Nothing visibly breaks: the site looks perfect, and your traffic quietly drains over the following days.

After every push, check Settings > Reading on the live site, and check a key page's source for a robots meta tag with noindex. Our free noindex checker does it in seconds.

What staging won't catch#

Staging is a great habit, but it does not protect you from everything:

• Automatic updates skip staging. WordPress installs minor core releases automatically, and plugins or themes with auto-updates enabled update straight on production, often at night. See WordPress automatic updates.
• Production is different. Live has the CDN, the page cache, real traffic, real API keys, third-party scripts and real payment gateways. Something that works on staging can still break on live.
• Staging drifts. A staging copy from last month does not have this week's plugins, content or settings.
• People edit live. Clients and editors change pages, menus and settings on production, outside any staging process.
• Nobody tests everything. Even with staging, few people check every page, every form and every SEO tag after every update.

That is why careful teams pair staging with monitoring of production: checks of the live site's key pages after every change, compared with how they looked when they were working, with an alert when something important changes.

Pair staging with production checks: the free MyKavo plugin#

The free MyKavo WordPress plugin covers exactly what staging misses, on the live site:

• Every update is recorded and checked, including automatic ones at night. On paid plans, from Starter, MyKavo checks your key pages after each update and names the update behind any change: "Appeared after: Updated WooCommerce 8.1.0 to 8.2.0".
• Silent-disaster alerts (free). A red notice on every wp-admin screen when "Discourage search engines" is switched on, the site address or permalinks change, the admin email changes or a new administrator appears. That is the staging push gotcha, caught the moment it happens. Paid plans also get an instant email or Slack alert.
• "Did it crash?" check (free). Right after each update, the site checks its own home page and up to three monitored pages for server errors, the critical error page and PHP fatal errors, with a Roll back now button.
• Snapshots and one-click rollback (free). Every plugin and theme update leaves a saved copy for seven days, so you can undo an update on production without a full restore.
• Watch the buttons that make money. Choose the checkout button, a signup form or a pricing link, and MyKavo alerts you if it disappears or changes.

Staging tells you an update should be safe. MyKavo tells you it was.

Summary#

Create a staging site with your host's one-click tool, a plugin like WP Staging, a local app or a manual subdomain. Lock it down: password, discourage search engines, no outgoing email, payments in test mode. Test one change at a time against a fresh copy. Push files rather than the full database, never overwrite a live store's orders, and check Settings > Reading after every push. Then watch production, because automatic updates and real-world differences never pass through staging.