Set Up a Staging Site
Test changes safely before they go live.
What this covers: Three approaches to staging environments: one-click hosting-provided staging, manual subdomain setup, and local development with tools like Local by Flywheel, plus the testing workflow and security considerations.
Who it’s for: WordPress site owners who want to test plugin updates, theme changes, or code modifications without risking their live site.
Key outcome: You’ll have a working staging environment where you can safely test changes, with a clear workflow for promoting tested updates to production.
Time to read: 4 minutes
Part of: Website Management series
A staging site is a copy of your production site where you can test updates, plugins, and code changes without breaking anything. Here’s how to set one up.
What Staging Means
A staging site is a copy of your production site where you can test changes safely. Break something on staging? No one sees it. Break something on production? Everyone sees it.
Local (your computer) → Staging (test server) → Production (live site)
Option 1: Hosting-Provided Staging (Easiest)
Many WordPress hosts include staging with one click:
- WP Engine: Sites > [Site] > Add Staging
- Kinsta: Sites > [Site] > Staging Environment
- SiteGround: Site Tools > WordPress > Staging
- Flywheel: Site > Staging
These automatically:
- Copy your site files and database
- Give you a staging URL (usually staging.yoursite.com or yoursite.staging.wpengine.com)
- Let you “push to production” when ready
If your host offers this, use it. It’s the simplest option.
Option 2: Subdomain Staging (Manual)
If your host doesn’t offer staging, create it yourself:
- Create subdomain: staging.yoursite.com
- Install fresh WordPress there
- Copy production database (export/import via phpMyAdmin or WP Migrate DB)
- Copy wp-content folder (or use a migration plugin)
- Update staging database URLs (search-replace yoursite.com → staging.yoursite.com)
Plugins that help: WP Migrate DB Pro, Duplicator, UpdraftPlus
Option 3: Local Development
For developers, a local environment is even better than staging:
- Local by Flywheel (free) – One-click WordPress on your Mac/PC
- MAMP – Traditional local server stack
- Lando or DDEV – Docker-based, more advanced
Local development lets you test before even pushing to staging.
The Staging Workflow
Once you have staging, use it:
- Sync staging from production – Get the latest content and settings
- Make your changes on staging – Plugin updates, theme changes, new features
- Test everything – Forms, checkout, mobile, key pages
- Push to production – Or manually replicate the changes
What to Test Before Going Live
- Homepage loads correctly
- Key landing pages work
- Forms submit successfully
- E-commerce checkout works (if applicable)
- Mobile layout looks right
- No PHP errors in debug log
- No broken images or links
Staging Security
Your staging site has a copy of your production database, which will include:
- User data
- Orders/transactions
- Passwords (hashed)
Protect staging:
- Password-protect the staging URL (.htpasswd or hosting control panel)
- Block search engines (Settings > Reading > Discourage search engines)
- Don’t process real payments on staging (use test mode for payment gateways)
Sources
Staging Site Questions Answered
What is a staging site and why do I need one?
A staging site is an exact copy of your live website where you test changes before deploying them to production. It prevents broken layouts, plugin conflicts, and downtime from reaching visitors. Every WordPress site that gets updated more than monthly should have one.
Does my hosting provider offer built-in staging?
Most managed WordPress hosts (WP Engine, Kinsta, Flywheel, SiteGround, Cloudways) include one-click staging. Shared hosting typically does not. Check your hosting dashboard for a “Staging” or “Clone” option. Built-in staging is simpler and more reliable than manual setups because it handles database and file syncing automatically.
How do I push staging changes to production safely?
Use your host’s built-in push feature if available—it handles database merging and file sync. If pushing manually, deploy files via SFTP and import only the specific database tables you changed. Always take a full backup of production immediately before pushing. Never push the entire staging database if production has received new orders, form submissions, or user registrations since the clone.
Should I use local development instead of staging?
Use both. Local development (Local by Flywheel, DDEV) is faster for code changes and theme development. Staging is better for testing plugin updates, content changes, and client reviews because it runs on your actual server environment. Local catches code bugs; staging catches hosting-specific issues.
✓ Your Staging Environment Is Ready When
- Staging site is a complete copy of production (theme, plugins, database, uploads)
- Staging URL is not indexed by search engines (noindex meta or robots.txt block confirmed)
- Staging is password-protected or IP-restricted so the public cannot access it
- You have a documented, repeatable process to push changes from staging to production
Test it: Make a visible CSS change on staging, verify it does NOT appear on production, then push it to production and confirm it appears within 5 minutes.