You've activated a plugin on the live site, the page went white, and now you're looking for a way to have a separate copy of the site before making any changes next time. Or the opposite: you have a staging version, but every time new content is published on the main site, your staging becomes outdated and useless. The main issue with WordPress staging isn't creating a copy; it's managing the flow of data between the two sites.
Where to Build WordPress Staging: Subdomain or Separate Server
You have three real options, and each has a cost that only becomes apparent after a few weeks.
| Method | Real Cost | Where It Works |
|---|---|---|
| Subdomain on the same host | CPU and RAM resources shared with the live site | Small sites, theme and plugin testing |
| Subdomain on a separate host | Second monthly cost + file transfer | High-traffic sites, testing heavy changes |
| Local with wp-env or Local | Your environment isn't the same as the server environment | Theme and code development, not testing cache plugins |
If your site gets several thousand visits per day, don't choose a subdomain on the same host. A bad plugin on staging can lock up MySQL for the live site too with a single heavy query. In practice, I prefer a separate host, unless the site is small and the budget is limited.
To set it up, first create a subdomain and configure its DNS record. If you're doing this for the first time, the complete guide to configuring DNS for a new site explains the order of records and the propagation wait time.
Copying from the Live Site Without Breaking It
Never copy from the live site folder with cp -r; you'll bring along cache files and half-finished uploads too. The correct order is:
wp db export /tmp/live.sql --add-drop-table
rsync -avz --exclude='wp-content/cache' --exclude='wp-content/uploads/*' \
/var/www/live/ stage@host:/var/www/stage/Transfer the uploads folder separately and only when needed. If your site has more than 2 GB of uploads, a full transfer takes about 10 to 20 minutes each time, and this time is repeated with every synchronization. For large sites, send only new files with rsync --ignore-existing.
After the transfer, change these lines in the staging wp-config.php file:
define('DB_NAME', 'stage_db');
define('DB_USER', 'stage_user');
define('DB_HOST', 'localhost');
define('WP_HOME', 'https://stage.example.com');
define('WP_SITEURL', 'https://stage.example.com');If you don't set WP_HOME and WP_SITEURL, WordPress uses the value in the database and redirects you to the live site. This is the most common reason for "my staging doesn't work."
Database Synchronization: Where Everyone Breaks Things
This is where mistakes happen. Someone pushes the staging database to the live site to "transfer the changes," and then finds that the past two weeks of orders, new users, and approved comments have all been wiped. The sign is obvious too: the user count in the dashboard drops overnight, and customers email saying "it doesn't recognize my account."
The live database is the source of truth. Always from live to staging, never the reverse. If you must move a change in settings or table structure from staging to live, do it manually and only for that specific table, not with a full import.
When you import the live database onto staging, be sure to do two things:
- Replace the URLs with
wp search-replace 'https://example.com' 'https://stage.example.com' --all-tables --precise. Without--precise, serialized data gets corrupted and widgets and page-builder settings stop working. - Disable email sending. With
wp config set WP_ENVIRONMENT_TYPE stagingand a plugin like WP Mail SMTP that intercepts outgoing mail, prevent test emails from being sent to real customers.
One practical tip: before every synchronization, back up the staging database. If after an import you realize you had an important change on staging, without a backup you'll have to rebuild from scratch.
Restoring to the Live Site: Pre-Push Checklist
When testing is done and you want to go live with the changes, transfer only the files. Don't touch the live database unless you have a structural change.
- Take a full backup of the live files and database, and make sure the backup file exists on another server too.
- Enable WordPress maintenance mode so users don't see a half-finished page mid-deploy.
- Transfer files with rsync, not by deleting and uploading everything.
- After the transfer, clear the object cache and page cache. If you don't, the old version is shown to users and you'll think the deploy didn't happen.
If your changes include theme code or custom plugins, it's better to work with Git from the start. The Git tutorial for site deployment shows how to manage versions without manually transferring files.
Things That Differ on Staging and Invalidate Your Testing
Staging is never exactly like live. Know these differences so you don't misinterpret test results:
- Data volume: The staging database is usually smaller. A query that's fast on 500 products becomes slow on 50,000 products.
- Traffic: Without real visitors, you won't see cache and concurrency issues.
- CDN and DNS: If staging isn't behind a CDN, you're not measuring real load times.
- Security plugins: Some plugins behave differently on a staging domain or bypass captcha.
To avoid surprises after deployment, measure the live site's speed before and after. Website speed testing; a guide to interpreting results helps you understand which number actually matters and which fluctuation is normal.
If your site is on shared hosting and you don't have enough resources for two versions, get a separate Linux host for staging. This also prevents a faulty plugin on staging from taking down the main site.
Frequently Asked Questions
Can I run staging on the same database as the live site?
No, that's dangerous. If both sites connect to the same database, any change on staging is immediately applied to the live site, and the concept of staging is lost. Even if you change the table prefix, plugins that store settings in wp_options will cause conflicts.
How do I know staging is properly separated from the live site?
Check three things: the WP_HOME value in wp-config.php, the database name, and that search engines don't index it. For the last one, enable the "discourage search engines" option in the reading settings or add the X-Robots-Tag: noindex header. If you don't, the staging version will appear in Google results and create duplicate content.
After database synchronization, why aren't images displaying?
It's usually due to an incomplete search-replace. If the old URL remains in meta tables or serialized files, image paths break. Run wp search-replace again with the --precise flag, then check the wp_options table for keys containing the old domain.
How often should I synchronize staging with the live site?
Before every important change, not on a fixed schedule. If your site's content updates weekly, weekly synchronization makes sense. But if you publish several posts daily, a full synchronization each time becomes expensive; in that case, synchronize only the content tables and don't touch the users and orders tables.
Before every deployment, have a restorable backup and make sure you can revert the site to its previous state in under ten minutes. If you haven't done this test, your staging is just a test environment, not a safety net.
Comments 0
No comments yet — be the first!