How to create a WordPress staging site

A staging site is a private copy of your live WordPress site that you use to test changes before visitors ever see them. Plugin updates, theme edits, core upgrades, a new checkout flow, a risky database migration – all of it happens on the copy first. If something breaks, it breaks somewhere nobody is looking, and your production site keeps serving traffic.

This guide covers what a staging site actually is, the three practical ways to set one up, how to push changes from staging to live without corrupting either, and how to keep the staging copy from showing up in Google.

What a staging site is (and what it is not)#

A staging site is a functional duplicate of your production site – same WordPress version, same plugins, same theme, same database content – running at a different URL that only you and your team can reach. It is not a backup (a backup sits in cold storage; a staging site is live and you interact with it), and it is not a local development environment (those run on your laptop and usually cannot reproduce server-level quirks like PHP version, MySQL settings, or the nginx config your host uses).

The three properties that define a real staging site:

1. It runs the same code and the same data as production, or close enough that tests on staging predict behaviour on production.
2. It is isolated. Changes on staging cannot corrupt the live database or overwrite live files.
3. It is reachable by you but hidden from the public and from search engines.

If any of those three is missing, you have something else – a sandbox, a dev site, a copy on your laptop – and the conclusions you draw from testing on it may not hold once you deploy.

Why you actually need one#

The short version: every change to a WordPress site is a migration risk in miniature. A plugin update can deactivate a payment gateway. A theme switch can wipe the widget config. A PHP version bump can break a function that has not been touched in five years. A database change can leave orphaned rows that slow everything down.

Testing on production means your customers are the ones who find these problems. Testing on staging means you find them first.

Specific scenarios where staging pays for itself within one use:

• Plugin updates. Especially WooCommerce, page builders, SEO plugins, caching plugins – anything that touches the database schema or the frontend rendering.
• Theme changes. Switching themes rewrites widget areas, menu locations, and theme-specific options. Doing this on production leaves visitors staring at a half-configured site while you re-place every widget.
• PHP version upgrades. Old plugins call old functions. A staging site running the target PHP version surfaces fatal errors before they hit production. See end-of-life PHP and the risks of running an unsupported version for why this matters beyond just staging.
• Database-heavy changes. Bulk post edits, custom field migrations, user role restructures – all safer on a copy you can throw away.
• Pre-migration dry runs. Before migrating WordPress to another hosting provider, clone to staging on the new host first, confirm everything works, then cut over DNS.

The three ways to set up staging#

There are three realistic approaches, in order of how much control they give you and how much manual work is involved.

1. Subdomain approach (manual clone)

You create a subdomain like staging.yourdomain.com , copy the WordPress files there, clone the database, update wp-config.php and a handful of database options, and you are done. This is the most flexible approach and the one that works on any host, including hosts that do not have a staging feature.

Step-by-step:

1. Create the subdomain. In your hosting panel, add staging.yourdomain.com and point it at a new directory (for example /staging/ ). On most managed hosts this provisions the directory, an SSL certificate, and an nginx or Apache config for you.
2. Copy the files. SSH or SFTP into the server and copy the entire WordPress root from your live site into the staging directory. rsync -a /path/to/live/ /path/to/staging/ is the cleanest way if you have shell access. If not, a plugin like All-in-One WP Migration or UpdraftPlus can export and re-import, but rsync is faster and preserves file permissions.
3. Clone the database. Create a new empty database for staging (for example yoursite_staging ). Export the live database with mysqldump , then import it into the staging database. mysqldump -u user -p live_db > dump.sql && mysql -u user -p staging_db < dump.sql . If you do not have SSH, phpMyAdmin can do the same thing through a browser.
4. Update wp-config.php in the staging directory. Change DB_NAME to your staging database. Update DB_USER and DB_PASSWORD if you created separate credentials. Change the authentication keys and salts to new values (generate them at https://api.wordpress.org/secret-key/1.1/salt/ ) so sessions do not bleed between live and staging. For more on what each of these settings does, see wp-config.php explained: what every setting does.
5. Rewrite the site URL in the database. WordPress stores siteurl and home in the wp_options table. It also stores the domain in serialised option values, post content, and meta fields. Do not run a blind UPDATE wp_options SET option_value = REPLACE(...) – that corrupts serialised data. Use WP-CLI from the staging directory: wp search-replace 'https://yourdomain.com' 'https://staging.yourdomain.com' --all-tables --precise . The --precise flag handles serialised data correctly. This is the same technique used when changing a WordPress domain name – a staging clone is effectively a domain change against a copy of the database.
6. Block indexing. In the staging WordPress admin, go to Settings > Reading and tick “Discourage search engines from indexing this site.” Also add HTTP basic auth in front of the whole subdomain (covered below).
7. Test. Load https://staging.yourdomain.com in a browser. Log in. Walk the site. If pages render but images are missing, the URL replacement missed a table – rerun wp search-replace against the specific table.

The subdomain approach gives you full control. It is also the one that teaches you the most about how WordPress stores its URLs, which pays off later when you have to debug a broken migration.

2. Plugin approach

Plugins like WP Staging, WP STAGING Pro, BlogVault, and Duplicator automate most of the above. You click a button, the plugin clones files and database into a subdirectory (typically yoursite.com/staging/ instead of a real subdomain), rewrites the URLs, and gives you a separate login.

What the plugin approach does well:

• No SSH needed.
• URL rewriting is handled correctly (these tools know about serialised data).
• Push-to-live features in paid versions can sync specific tables or files back to production.

What to watch for:

• Staging in a subdirectory ( yoursite.com/staging/ ) shares nginx config, PHP-FPM pool, and sometimes cache headers with your live site. A misconfigured staging can cause odd caching issues on the live domain.
• Free versions usually clone files and database but leave out the “push to live” feature. You can test, but you cannot easily deploy changes back.
• The plugin has to stay installed on both sides. If you deactivate it, you lose the connection between staging and live.

Plugins are the right call when you do not have shell access or when you want a one-click workflow. They are the wrong call when you care about isolation – a subdirectory staging is not as separated from production as a real subdomain or a separate hosting account.

3. Hosting panel approach

Some hosts provide a one-click staging feature in their control panel. You pick your site, click “create staging,” and the platform clones files and database into an isolated environment, usually at a random subdomain like staging-123.hostname.com . You get a separate login, the subdomain is automatically noindexed, and a “push to live” button handles the reverse sync.

This is the fastest approach when your host offers it. The quality varies a lot between providers – some clone properly and isolate cleanly, others just copy files into a subdirectory and call it staging. Ask specifically:

• Does staging run in an isolated environment (separate database, separate PHP process) or share with production?
• How does push-to-live handle the database – full overwrite, table selection, or differential merge?
• Is staging accessible only to logged-in panel users, or is it a public URL?
• Does the staging site consume your hosting plan’s disk and CPU quota, or is it separate?

If your host does not yet offer staging, fall back to the subdomain approach. It takes an hour the first time and fifteen minutes every time after.

Push-to-live: what to sync and what to leave alone#

The hardest part of staging is not creating it. It is deciding what to sync back to production when your testing is done.

A WordPress site has two kinds of state: code (themes, plugins, custom files in wp-content ) and data (everything in the database). These change at different rates, and they have different owners.

• Code changes come from developers. On staging, you update a plugin, edit a theme file, add a custom post type in code. These changes should go to production.
• Data changes come from editors and visitors. On production, an editor publishes three new blog posts, a customer places four orders, a comment is posted. These changes are happening while you test on staging. If you push staging’s database back to live, you overwrite those changes.

The safe sync workflow:

1. On staging, only change code and configuration. Avoid creating test posts that you then want to keep, and avoid editing settings that also got changed on production in the meantime.
2. When testing is done, push files only: sync wp-content/themes/ and wp-content/plugins/ from staging to production. Leave wp-content/uploads/ alone – uploads are owned by production. rsync -a --exclude=uploads /staging/wp-content/ /live/wp-content/ works.
3. For database changes that must reach production (custom field schema changes, new settings), apply them manually on production after the file sync, not by overwriting the database.
4. Run wp cache flush on production afterwards. If you use a page cache like Hostney Cache, purge it too. Plugin and theme changes invalidate rendered HTML.

The reverse – pulling production down to refresh staging – is easier: you can overwrite staging’s database and files from a fresh production backup any time you want, because staging has no data you care about keeping. Make this your routine. Refresh staging from production before every round of testing so you are not testing against stale data.

Keeping staging private#

A staging site that Google can crawl is worse than useless. Duplicate content, leaked pre-release features, broken test pages in search results. Belt-and-braces is the right posture here – apply all three of these, not just one.

1. robots.txt and noindex. In the staging WordPress admin, Settings > Reading > Discourage search engines. This adds a meta noindex tag to the pages and generates a robots.txt that asks crawlers to skip the site. Well-behaved crawlers obey it. Ill-behaved ones do not.

2. HTTP basic auth. Add a username and password requirement in front of the entire subdomain. In nginx:

location / {
    auth_basic "Staging";
    auth_basic_user_file /etc/nginx/staging.htpasswd;
    # ... rest of the location block
}

Create the htpasswd file with htpasswd -c /etc/nginx/staging.htpasswd yourname . Now nothing – browsers, crawlers, curious visitors – reaches the site without a password. This is the strongest layer.

3. IP allowlist. If you and your team always work from a static IP or a VPN, restrict the subdomain to those IPs at the firewall or server level. Everything else gets a 403.

Do not rely on “security through obscurity” – just picking a random subdomain like stg-7x2.yourdomain.com and hoping nobody finds it. Subdomains leak through certificate transparency logs, and anyone searching CT logs sees them within minutes of the SSL certificate being issued.

Common mistakes that make staging useless#

• Testing with stale data. Staging was cloned three months ago and does not have the 200 products the merchandising team added since. A plugin update works on staging and breaks on production because the data shape is different. Refresh staging from production before testing.
• Different PHP version on staging. A plugin update passes on staging running PHP 8.1 and fatals on production running PHP 7.4. Match the PHP version.
• Different plugin set on staging. Someone deactivated a plugin on staging six weeks ago to test something. That plugin is what conflicts with the update on production. Keep the active plugin list identical.
• Not testing the admin. The frontend loads on staging, so you call it good. But the admin edit screen for WooCommerce products throws a JavaScript error. Walk the admin too, especially the screens for any plugin you updated.
• Forgetting to disable emails. Staging inherits the email settings from production. Now it fires order confirmation emails to real customers when you test a checkout. Set WP_ENVIRONMENT_TYPE to staging in wp-config.php and install a plugin like WP Mail Log or use a catch-all mail plugin to intercept outbound mail. Or just change the SMTP credentials on staging to a test mailbox.

How Hostney handles staging#

Hostney’s WordPress manager has a dedicated staging tab in development – it will let you clone a live site to an isolated staging environment, test changes, and push selected changes back to production from the control panel. Until it ships, the subdomain approach described above is the right path on Hostney: create a subdomain through the control panel, clone the files and database from the live install, and use WP-CLI or wp search-replace to rewrite the URLs.

Hostney’s container isolation per account means you can create a second subdomain that runs in the same isolated environment as your live site – same PHP version, same nginx config, same MySQL instance – which is exactly what you want for staging. Tests on that staging copy predict production behaviour closely because the underlying stack is identical.

If you are evaluating hosting partly because you want a real staging workflow, the question to ask any provider is not “do you offer staging” but “how does your staging work” – the three-property checklist at the top of this article (same stack, isolated, private) is the filter that separates real staging from a directory copy sitting next to your live site.

Summary#

Set up staging before you need it, not after. The first time you use it to catch a plugin update that would have taken your site down on a Friday afternoon, the fifteen minutes of setup pays itself back many times over. Use a real subdomain when you can, a plugin when you cannot, and a hosting panel feature when your host offers one that meets the isolation and privacy requirements. Keep staging refreshed from production, keep production updates flowing from staging as code only, and keep Google’s crawlers out with both robots rules and a password.