How to Create a WordPress Staging Site

A staging site is a copy of the live site that nobody depends on. It exists so that updates, redesigns and unfamiliar plugins fail somewhere harmless. Any site where downtime costs something — a store, a booking system, anything earning money — should have one before the next update, not after the next outage.

Pick the kind of copy you need

The important property is that staging matches production where it matters: same PHP version, same web server, same database engine. A bug that only appears on the live stack is exactly the bug staging was supposed to catch.

Use the host's staging if it exists

Most managed WordPress hosts create a staging copy in a click, on the same stack, with the correct URLs already rewritten. That is almost always the right choice. Before you rely on it, find out three things from the documentation:

1. Does "push to live" copy files only, or the database as well?
2. Does it exclude uploads, and if so, is media missing on staging?
3. Is the staging site password-protected by default?

Those three answers determine your entire workflow. A host that pushes the whole database to live is safe for a brochure site and dangerous for a store.

Create one manually

Without host tooling, staging is a copy of the files, a copy of the database, and a URL rewrite. On a subdomain such as staging.example.com:

1. Take a full backup of live and keep it aside.
2. Copy the files to the new document root.
3. Export the database and import it into a new, separate database. Never point staging at the live database.
4. Update the credentials in wp-config.php so staging uses its own database and its own table prefix if it shares a server.
5. Rewrite the URLs with a serialisation-aware replace:

wp search-replace 'https://example.com' 'https://staging.example.com' --all-tables --dry-run
wp search-replace 'https://example.com' 'https://staging.example.com' --all-tables

6. Flush permalinks and confirm the front end loads.

If you have no admin access on the source site, the file-and-database route in how to clone a WordPress site without admin access covers the same ground from the server side. The reverse direction — copying to a different host entirely — is migrating a WordPress site.

Lock it down before you use it

This is the step people skip, and every item on the list has bitten a real site.

Block indexing with HTTP authentication. A .htaccess password, an nginx auth_basic, or the host's own protection. Crawlers cannot get past it. Relying on Settings → Reading → Discourage search engines is not enough: it is advisory, and staging URLs end up in search results routinely — the recovery is the tedium described in site not showing in Google, only in reverse.

Stop outgoing email. A staging copy holds real customer addresses and real order data. Install a mail-catching plugin, or short-circuit delivery:

add_filter('pre_wp_mail', '__return_false');

Without this, a test order can send a real customer a real receipt from a site that does not exist.

Neutralise anything that touches the outside world. Put payment gateways in test mode, disconnect analytics, disable live sync with a CRM or fulfilment service, and turn off anything that posts to social accounts.

Turn off backup schedules and cron-heavy plugins so staging does not fill a backup destination with copies of itself. Disabling WP-Cron on staging is usually the cleanest cut.

Label it. An admin colour scheme change or a banner in the footer prevents the classic mistake of editing staging and wondering why live never changes.

What staging is for

Test the things that break sites, in this order:

• Core, theme and plugin updates — the whole batch, then click through the site. The method is in how to update WordPress plugins safely.
• PHP version upgrades, which surface fatal errors no update notice warns you about.
• New plugins, especially any that touch caching, security or the checkout.
• Theme changes, from a child theme tweak to a full replacement.
• Migrations and structural URL changes, where staging is the only honest way to test redirects.

Click the paths that earn money, not the home page: search, add to cart, checkout, contact form, login, account page.

Pushing changes back

Files and database behave completely differently.

Files are easy. Theme and plugin changes can be copied to live directly, or deployed from version control. Nothing on live is generated inside wp-content/themes/, so overwriting is safe.

The database is not. Live has been writing continuously since the copy was made: orders, comments, form submissions, new posts, updated stock. Restoring the staging database over it destroys all of that.

Practical rules:

• Brochure site, no user-generated content → pushing the whole database is acceptable if you back up live first.
• Store, membership site or anything with daily content → push files only, then repeat settings changes by hand on live. It feels primitive. It is also the only method that cannot lose an order.
• Content written on staging → export just those posts with the WordPress exporter and import them into live.
• Whatever the method → back up live immediately before the push, and take the site to maintenance mode if the change is not instant.

Keep it current, or delete it

A staging copy from four months ago tests a site that no longer exists. Refresh it from live before each significant piece of work, and delete copies you have finished with — an unpatched WordPress install on a subdomain, sitting on the same server as production and holding a full copy of your customer data, is a genuine liability rather than a harmless leftover.