Most WordPress hosting control panels let you spin up a staging site with one click. You make changes, test them, then push to production. The promise is simple: clone, edit, deploy.
The reality is messier. Staging sync isn’t a mirror—it’s selective. Files, database tables, and user-generated content follow different rules depending on your host and how the sync is configured. Push the wrong way and you’ll lose form submissions, overwrite live orders, or leave half your images behind.
Here’s what actually happens when you sync from staging to live, and how to avoid the gaps.
What staging sync transfers by default
Most hosting providers—BigScoots, Kinsta, WP Engine, SiteGround—sync the same core elements when you push from staging to production:
- Theme files and templates. Any changes to your active theme’s PHP, CSS, or JavaScript files move over.
- Plugin files and updates. New plugins, deleted plugins, and updated plugin code all transfer.
- WordPress core files. If you upgraded WordPress in staging, the live site gets the same version.
- Database schema changes. New tables, altered columns, and modified indexes sync as part of the database push.
- Posts, pages, and taxonomy changes. Any content you edited, published, or trashed in staging replaces the live version.
That’s the happy path. The problems show up in what doesn’t sync automatically.
What gets skipped or orphaned
Staging environments are clones at the moment you create them. Once live users start interacting with your production site—submitting forms, uploading files, placing orders—those changes don’t exist in staging. When you push from staging to live, you’re overwriting the live database with a snapshot that’s hours or days old.
User uploads. Files added to /wp-content/uploads/ on your live site after you cloned staging won’t exist in staging. When you push, most hosts sync the staging uploads folder to production, which means newer live uploads vanish unless you manually merge them. Some hosts offer a files-only sync option; use it if you’ve added media in both environments.
Form submissions and user-generated content. If you’re running Gravity Forms, WPForms, or any contact plugin that stores entries in the database, those entries live in custom tables. Pushing staging to live replaces those tables with the staging versions—which don’t include submissions that arrived while you were editing. Same for comments, user registrations, and forum posts.
WooCommerce or EDD orders. E-commerce data is the highest-risk category. Orders, customer accounts, and transaction logs written to the live database after staging was cloned will be overwritten. If you push staging to live without exporting and re-importing order data, you lose sales records. Most operators avoid this by never syncing the database for active stores, or by excluding specific tables in the sync settings.
Plugin settings that reference URLs. Staging sites usually run on a subdomain like staging.yoursite.com. Plugins that store absolute URLs—like page builders, SEO tools, or caching plugins—may carry over staging URLs when you push. You’ll need to run a search-and-replace on the database post-sync to fix internal links.
How to sync safely
The safest workflow treats staging as a code and structure environment, not a content sandbox. Here’s the pattern that avoids data loss:
1. Sync files and database separately. Most staging tools let you choose what to push: files only, database only, or both. If your live site has active users, push files first, then manually migrate only the database tables you’ve actually changed—typically wp_options for settings, and any custom tables your plugin added. Skip wp_posts, wp_comments, and wp_users unless you’re certain no one has added content on live.
2. Exclude tables in your sync config. Kinsta and WP Engine both let you specify tables to exclude during a database push. Add your order tables, form entries, and user-generated content tables to the exclusion list. You can find the exact table names in phpMyAdmin or your hosting control panel’s database manager.
3. Export and re-import critical data. If you must overwrite the live database, export the tables you care about first using WP-CLI, phpMyAdmin, or a plugin like WP Migrate DB. After the push, re-import them. It’s manual, but it’s the only way to preserve order history or form data when you’re replacing the entire database.
4. Test on a disposable clone. Some hosts let you create multiple staging environments. If you’re making risky changes—switching page builders, restructuring taxonomy, or migrating to a new plugin—spin up a second staging site, push to it first, and confirm nothing breaks before touching production.
What to check after every push
Even a clean sync can leave edge cases. After pushing staging to live, check:
- Search and replace: confirm
staging.yoursite.comdidn’t leak into post content, image URLs, or plugin settings. - Uploads folder: verify recent images and PDFs still exist. If they’re missing, copy them from a live backup or manually upload.
- Form entries: if you run contact forms, check the entries table. If it’s empty post-sync, restore from backup.
- Cache: flush object cache, page cache, and CDN cache. Stale cache can serve staging content or broken URLs for hours after a push.
Staging sync is a code deployment tool, not a content management system. Treat it that way and you won’t lose data when you ship.
Got a sync horror story or a host that handles this better? Hit reply—we’re tracking which platforms make this easier and which ones still make you export tables manually.