How to Set Up a WordPress Staging Site (and Push It Safely)

A WordPress staging site is a private copy of your live site where you can test updates, new plugins and design changes before visitors see them. Setting one up is the easy part. The part that catches people out is pushing changes back to live without wiping out orders, form entries or new content.

Here’s how to create one, how to keep it private, and what to watch when you push.

What a staging site is

Staging is a full copy of your site’s files and database running at a separate address, such as staging.example.com or a temporary URL from your host. You can break it, fix it and break it again without affecting the live site.

Use it to test plugin, theme, WordPress core and PHP updates, try a new plugin, or build a redesign. It isn’t a backup. If the live site breaks, staging may be out of date or share the same server, so keep real backups as well. See how to back up and restore WordPress.

Option 1: Your host’s one-click staging

This is the simplest route if you have it. Many managed WordPress hosts include staging: look in your hosting dashboard for a Staging tab or button on the site. Creating the copy usually takes a few minutes, and the host takes care of the separate URL, the database copy and the URL replacement.

Good host tools also let you push back to live selectively: files only, database only, or chosen tables. That choice matters, as explained below. If your host doesn’t offer staging at all, it may be time to look at managed WordPress hosting that does.

Option 2: A staging plugin

Plugins such as WP Staging create a copy of your site from inside the dashboard, usually in a subfolder on the same hosting account. Other tools, including several backup and migration plugins, can copy the site to a subdomain you create yourself.

Two things to check before you rely on one. First, pushing changes from staging back to live is often a paid feature, so confirm what the free version does. Second, a copy on the same server shares that server’s resources, so a heavy test won’t tell you much about performance.

Option 3: Set it up manually

If you’re comfortable with SFTP and phpMyAdmin, or WP-CLI, you can build staging yourself:

1. Create a subdomain such as staging.example.com in your hosting panel, with its own folder.
2. Create a new, empty database and database user.
3. Copy all of the live site’s files into the subdomain’s folder.
4. Export the live database and import it into the new one. With WP-CLI: wp db export live.sql on live, then wp db import live.sql on staging.
5. Edit the staging copy of wp-config.php with the new database name, user and password.
6. Replace the live URL with the staging URL throughout the database, using a tool that handles serialized data, as explained in how to change your WordPress URL.

wp search-replace 'https://example.com' 'https://staging.example.com' --all-tables-with-prefix --skip-columns=guid

Log in to staging and confirm the address bar stays on the staging domain as you click around.

Keep staging private and quiet

A staging site is a duplicate of your live site, so you don’t want Google indexing it or customers stumbling onto it.

• Password protect it. Use your host’s directory privacy or password protection feature. This keeps out search engines and people.
• Turn on noindex. Check Settings → Reading → Discourage search engines from indexing this site. It’s a request, not a lock, which is why the password matters more.
• Stop real emails. A copy of a store or membership site can send order, renewal and notification emails to real customers. Many hosts block email from staging. If yours doesn’t, use your SMTP plugin’s option to stop sending, if it has one, or a plugin that logs mail instead of sending it.
• Put payments in test mode. Switch payment gateways to sandbox or test mode, and be careful with anything that runs on a schedule, such as subscription renewals or syncs to other services.

You can also mark the site as staging in wp-config.php. WordPress itself doesn’t change much based on this, but some plugins read it:

define( 'WP_ENVIRONMENT_TYPE', 'staging' );

What to watch when you push to live

The biggest risk with staging is the database. Your staging copy is a snapshot. From the moment you made it, the live site kept collecting orders, form entries, comments, new users and posts. Pushing the full staging database to live replaces all of that with the old snapshot. That data is gone unless you restore it from a backup.

How to avoid it:

• Stores, forms, memberships and courses: never push the whole database. Push files only, then repeat any settings or content changes by hand on live.
• Code changes, such as theme edits or a new plugin version, live in files. A files-only push is usually safe.
• Selective table pushes are possible with some host tools, but WordPress tables are linked. Settings, orders and content can share tables such as wp_options and wp_posts, so only do this if you know exactly what each table holds.
• Content-only sites that nobody else edits can push the database, but freeze edits on live between copying and pushing.

Before any push, take a fresh backup of live. Afterward, clear all caches, re-save Settings → Permalinks, and check one thing people often miss: if you pushed the database, your staging noindex setting came with it. Go to Settings → Reading on live and make sure Discourage search engines is unchecked.

A simple workflow for updates

For routine updates, you often don’t need to push anything. Test on staging, then repeat on live:

1. Refresh staging from live so it matches the current site.
2. Run the updates on staging.
3. Test what matters most: checkout, forms, logins, the homepage and your key landing pages.
4. If everything works, run the same updates on live and test again.
5. If something breaks on staging, you’ve found the problem without any visitor seeing it.

This is also the safest way to handle plugin and theme updates on a busy site.

Want someone to handle it?

Every update on our Care Plans (from $69 a month) is tested on staging before it touches your live site, along with monitoring, backups and developer support. If a staging push has already gone wrong, our $79 one-time fix can help, usually within 24 hours.