A WordPress staging site is a private copy of your live site that you use to test plugin updates, theme changes, new code, content migrations, anything that could break production. The change works on staging, you push it live. The change breaks staging, you fix it without anyone seeing.
You have four practical ways to set one up: your host’s built-in staging feature (the easiest if you’re on a managed WP host), a plugin like WP Staging or Duplicator (works on almost any host), a local development environment like Local or DevKinsta (free, runs on your own machine), or a manual copy onto a subdomain (more work, more control). This guide walks through all four with the trade-offs, plus the gotchas that bite most people the first time (cron jobs running on staging, search engines indexing your test site, email being sent from staging accidentally).
What Is a WordPress Staging Site?
A staging site is a full clone of your production WordPress install (same content, same plugins, same theme, same configuration) running at a different URL (usually a subdomain like staging.yoursite.com or a host-provided URL like yoursite.staging.kinsta.cloud). It’s not publicly visible to your visitors, but it’s accessible to you and anyone else with the credentials.
You use it for one thing: testing changes safely. Plugin updates, theme switches, custom code edits, migrations, redesigns. Whatever could break your live site, you do it on staging first. If it works, you push the change to production. If it breaks staging, you fix it (or roll it back) while your live site keeps running like nothing happened.
When Do You Actually Need One?
If you’re running a personal blog with a few plugins and don’t touch the site much, you can probably get by with backups alone. Update on a Tuesday morning, check the site, roll back if anything looks weird.
You want a staging site when:
- Downtime costs real money. Ecommerce, lead-gen, anything where a broken site means lost revenue. Staging pays for itself the first time it catches a bad plugin update before it hits production.
- You’re making structural changes. Switching themes, migrating to a block theme, swapping page builders, doing a major design refresh. These all carry the risk of breaking layouts, navigation, or templates in ways you don’t see until traffic starts complaining.
- You write custom code. Anything you add to functions.php or a custom plugin should run on staging first. PHP errors that take your site down are easy to make and impossible to undo from inside the broken admin.
- You manage client sites. Doing changes on production while a client could be watching is bad form. Push to staging, get sign-off, deploy.
- You’re updating to a major WordPress release. Major versions occasionally break plugins or themes. Testing the update on staging first is a 10-minute check that can save a 4-hour rollback. Especially relevant for the recent WordPress 7.0 upgrade.
If none of those apply, skip the staging setup and rely on solid backups. Every minute you spend maintaining a staging environment you don’t actually use is a minute not spent on the site itself.
Method 1: Use Your Host’s Built-In Staging
This is the path of least resistance and what I’d recommend for almost anyone on a managed WordPress host. Most modern hosts include one-click staging:
- Kinsta: Sites > Environments > Create staging. Available on every plan. Push from staging to live with a button.
- WP Engine: Sites > choose your site > Stage. Includes selective database table push so you don’t overwrite product orders.
- SiteGround: Site Tools > WordPress > Staging. Available on GoGeek and higher.
- Cloudways: Application Management > Staging Management.
- Bluehost: My Sites > Manage Site > Staging.
- WordPress.com (Business plan and up): Tools > Staging Site.
The flow is the same across all of them: click “Create Staging”, wait a minute or two for the clone to spin up, log into the staging URL, test, then push your changes back to production (selective database push if your host supports it). No plugin to install, no manual file copies, no separate database to maintain.
If your host doesn’t include staging on your plan tier (cheap shared hosting often doesn’t), this method is out and you’re picking between the next three.
Method 2: Use a Staging Plugin
If your host doesn’t include staging, a plugin can do it for you. Two solid options:
- WP Staging: creates a staging copy in a subdirectory of your site (
yoursite.com/staging/) with one click. Free version handles staging creation; the paid Pro version adds the “push back to production” feature. Most popular plugin in this category. - Duplicator: built for migrations more than staging, but the workflow works. Create a package (zip of files + SQL dump), upload to your staging URL or another host, run the installer. Free for basic use; Pro adds scheduled backups and direct cloud uploads.
The trade-off versus host-provided staging is that the plugin doesn’t always handle the URL rewrites, search-engine blocking, or database push as cleanly as a host’s purpose-built feature. You’ll do more manual cleanup. The upside: it works on any host, including cheap shared hosting that doesn’t include staging at all.
Method 3: Local Development
For testing major changes (new themes, big code rewrites, migrations) where you want to iterate fast without affecting any live system, run a local copy of your site on your own machine. Three popular tools:
- Local (by WP Engine): free, the most popular option. One-click WordPress installs, PHP/MySQL version control, easy import from a live site, instant live URL via shareable links. Available on Mac, Windows, Linux.
- DevKinsta: free, similar to Local but with deeper Kinsta integration (one-click push to a Kinsta staging environment if you host there).
- XAMPP / MAMP / Laragon: classic LAMP/WAMP stacks. More setup than Local but more control over the underlying environment. Right pick if you’re already comfortable managing Apache/MySQL/PHP versions manually.
Local development is the safest staging option (nothing you do on localhost can affect production) and the fastest iteration loop (no network round-trip for every change). The catch: pushing back to production requires a migration plugin like Duplicator or All-in-One WP Migration, which adds friction to the “test then deploy” workflow.
Best fit: developer-style work where you want to commit to git and deploy with a script anyway. Not great for “just try this plugin update” where the host-provided one-click staging is faster.
Method 4: Manual Setup on a Subdomain
The DIY option. Useful when none of the above fit (no host staging, allergic to plugins, can’t run local for some reason). The high-level flow:
- Create a subdomain in your host control panel:
staging.yoursite.com. - Copy your site files (wp-content, wp-config.php, root files) to the subdomain’s directory via FTP, file manager, or SSH.
- Create a new database, export production’s database, import it into the new database, edit
wp-config.phpon the staging copy to point at the new database. - Run a search-replace on the database to update URLs from
yoursite.comtostaging.yoursite.com. The free Better Search Replace plugin handles this, or do it via WP-CLI:wp search-replace 'yoursite.com' 'staging.yoursite.com'. - Block search engines: Settings > Reading > Discourage search engines from indexing this site. Critical step.
- Test that staging loads, log in, verify the site looks right.
This is the most-control option but the most work. Use it when you specifically need the staging site at a domain that’s different from your host’s default staging URL (sometimes for SSO testing, sometimes for analytics, sometimes for plugin licensing).
Comparing the Four Methods
| Method | Setup time | Cost | Push-to-live | Best for |
|---|---|---|---|---|
| Host-provided | 1-2 min | Included on most managed plans | One click | Almost everyone on managed WP hosting |
| Plugin (WP Staging) | 5-10 min | Free; Pro $89/yr for push-back | One click (Pro) / manual (Free) | Sites on cheap shared hosting |
| Local development | 15-30 min initial | Free | Plugin-assisted, not instant | Developers who want git + scripted deploy |
| Manual subdomain | 30-60 min | Free | Manual database + file sync | Edge cases where the above don’t fit |
The Staging Workflow (Test, Then Push)
Whatever method you pick, the workflow is the same:
- Refresh staging from production. Always start with a fresh copy. A stale staging site (last refreshed three months ago) is worse than no staging at all because it doesn’t reflect what your live site actually has.
- Make the change on staging. Update the plugin, swap the theme, edit the code, run the migration.
- Test thoroughly. Visit the homepage, hit a few posts, log into the admin, try the contact form, check the checkout flow, view it on mobile. If anything’s broken on staging, fix it on staging before touching production.
- Take a production backup. Before pushing staging → live, snapshot production so you can roll back if the push goes wrong.
- Push to production. Use the host’s push feature, or manually copy the relevant files and database tables. Pay attention to which database tables you push: you usually want to push design changes but NOT push staging’s posts or orders over production’s.
- Smoke-test production. The exact same flows you tested on staging, now on live. If anything’s off, roll back to the backup.
- Resave permalinks. Visit Settings > Permalinks and click Save Changes. Belt and suspenders to flush rewrite rules in case the push affected URL handling.
Common Gotchas
Five things that bite people running their first WordPress staging site:
- Search engines indexing staging. Always set Settings > Reading > Discourage search engines on staging. Better yet, use HTTP basic auth so the site isn’t even accessible to crawlers. Without one of these, Google will index your staging site as duplicate content, which is bad for SEO and confusing for visitors who find it.
- Email sent from staging. If your site sends transactional email (order confirmations, password resets, contact-form notifications), staging will too unless you disable it. Worst case: customers get duplicate order emails or password resets that don’t work. Use a plugin like WP Mail Logging to log instead of send, or set
define( 'WP_MAIL_SMTP_DISABLE', true );in staging’s wp-config.php. - Cron jobs running on staging. WP-Cron runs the same on staging as on production. Scheduled imports, backups, or third-party API calls keep firing. Either disable WP-Cron on staging (
define( 'DISABLE_WP_CRON', true );in wp-config.php) or accept that scheduled tasks will run twice. - Payment gateway test mode. If you’re testing checkout flows, every payment gateway has a test mode. Enable it on staging. Otherwise you’re charging real cards with staging orders, and refunding gets messy fast.
- Plugin license keys. Most premium plugins (Yoast Premium, ACF Pro, Gravity Forms) check the site URL against your license. They’ll run on staging but might show “this license is for another site” warnings, or refuse to update. Many plugins have a “development license” option for staging URLs; check your plugin’s license documentation.
Frequently Asked Questions
What’s the difference between staging and a backup?
A backup is a frozen snapshot of your site you can restore from. A staging site is a live copy you can interact with, log into, and test against. You use backups to recover after something goes wrong; you use staging to make sure something doesn’t go wrong in the first place. Most sites should have both: regular backups as the safety net, and a staging environment when you’re about to make a risky change.
How do I push changes from staging back to production?
Host-provided staging includes a “push to live” button that handles file and database sync, usually with options for which database tables to overwrite. The WP Staging Pro plugin has the same feature. For manual setups, you’ll need to copy the changed files (plugins, theme, wp-content) and selectively import database tables. You want to push design and configuration changes but not push staging’s orders or posts over production’s. Always take a production backup before pushing.
Will search engines index my staging site?
Only if you let them. Set Settings > Reading > “Discourage search engines from indexing this site” on staging immediately after setup. For stronger protection, put the staging URL behind HTTP basic auth so it’s not publicly accessible at all. Most managed hosts apply both protections automatically to their built-in staging environments; manual setups need it configured by hand.
Can I use the same plugin license on staging and production?
Depends on the plugin. Most premium plugins allow staging-site usage on a different URL without counting it as a second site. Check the plugin’s licensing terms; most explicitly cover staging environments (look for “development license,” “staging usage,” or “additional URL” language in the license docs). For plugins that don’t, you can usually contact support and get a no-cost development license for testing.
How often should I refresh my staging site from production?
Refresh before every meaningful change. A stale staging site doesn’t reflect what’s actually on production, which defeats the point. For active sites, that often means a fresh staging clone right before testing each plugin update, theme switch, or code change. Host-provided staging makes this a one-click operation, which is why it’s the recommended starting point for most users.
Do I need a staging site if I’m using a child theme?
A child theme isolates your customizations from theme updates, which solves one specific failure mode. It doesn’t help with plugin updates, WordPress core updates, or any other changes that can break your site. If you’re doing more than tweaking your child theme, you still want a staging environment for the rest of the work. See our child theme guide for the design-protection side specifically.
What’s the difference between local development and staging?
Local development runs on your own machine (Mac, Windows, Linux), which means it’s totally disconnected from your production environment. Staging usually runs on the same hosting infrastructure as production, so it matches the server’s PHP version, MySQL version, and environment closely. Local is faster to iterate in but doesn’t catch host-specific bugs. Staging is closer to production but slower to set up changes in. Many teams use both: local for development, staging for pre-production verification.
Can I run a staging site on free hosting?
Possible but rarely worth it. Free WordPress hosts have strict resource limits and slow performance, which means staging tests don’t tell you much about how production will behave. If you’re testing changes to a real site, do it either on the same host as production (built-in staging or a subdomain) or locally on your own machine via Local or DevKinsta. Free hosting for staging is a false economy.
Wrapping Up
For most WordPress sites in 2026, the right answer is: use your host’s built-in staging if you have it, fall back to the WP Staging plugin if you don’t, and run Local on your machine for serious development work. The manual subdomain setup is only worth the effort in specific edge cases.
The workflow is always the same regardless of method: refresh staging from production, make your change, test it, take a production backup, push to live, smoke-test, resave permalinks. And remember the gotchas: block search engines, disable email sending, kill WP-Cron, switch payment gateways to test mode, check plugin licenses.
For more on the surrounding pieces: our wp-config.php guide covers the constants you’ll set differently on staging (DISABLE_WP_CRON, WP_DEBUG, WP_MAIL_SMTP), WP-Cron covers what scheduled tasks do when they run on both environments, and WordPress 7.0 covers the latest major version you’d test on staging before updating production.
