Pushing a staging site to production

The short answer

Pushing copies your staging site (a private copy of your site for testing) over the live site. It is safe for files such as themes, plugins and code, and risky for the database if the live site collects orders, bookings or form entries, because a full push overwrites them. Back up the live site, decide whether you are pushing files only or files plus database, and do it during a quiet hour.

What it means

From the moment you create a staging copy, the two sites drift apart. While you were testing a new theme on staging, customers kept placing orders, leaving comments and filling in forms on live. All of that lives in the live database.

A full push replaces the live database with the staging database, which is a snapshot from the day you cloned it plus whatever you changed on staging. Anything live gained since then disappears. That is why the safe habit is to push files, and to push the database only when you are sure nothing on live has changed, or only the specific tables you need.

There is a second wrinkle. Staging runs at a different web address, and that address is written into the database thousands of times. The push has to search and replace the URL, or your links and images keep pointing back at the staging site. WP Toolkit does this for you during Copy Data.

Common causes

• Pushing the whole database over a store or booking site, wiping out orders, customers and form entries collected since the clone was made.
• A stale staging copy. Live had plugin updates and content edits since staging was created, and the push quietly rolls them back.
• The URL replacement being skipped because the push was done by hand with a file copy and a database import, leaving staging links in menus and images.
• Caches serving the old site after the push. Page cache, Redis object cache and Cloudflare all hold copies, so the live site looks unchanged.
• No backup taken first, so a bad push has no way back.

How to fix it

1. Back up the live site. In the management console (Plesk with WP Toolkit) go to Websites & Domains, then Backup & Restore, and run a full backup. On any host, the rule is the same: no backup, no push.
2. Check how far staging has drifted. Compare the plugin lists and recent content on both sites. If staging is weeks old, it is often faster to clone a fresh staging copy from live, reapply your changes there, and push that.
3. Decide what to push. New theme, plugin or custom code: files only. A content change such as new pages: files plus specific tables. A brand new site with no live data yet: everything.
4. Push with Copy Data. In WP Toolkit open the staging site card and choose Copy Data (sometimes shown as Sync). Pick the live site as the target. Choose Files only, Database only, or both. For files, Changed files only is the quick option. For the database, you can copy all tables, only tables that already exist on the target, or hand-pick tables.
5. Protect live data if you copy the database. On a store, leave out the tables that hold orders and customers: wp_posts and wp_postmeta if orders are stored there, or the wp_wc_orders family if high performance order storage is on, plus wp_users, wp_usermeta, wp_comments and any form plugin entry tables. If that list makes you nervous, push files only and make the settings changes on live by hand.
6. Confirm the URL was replaced. WP Toolkit does this as part of Copy Data. If you pushed any other way, run wp search-replace 'https://staging.example.com' 'https://www.example.com' over SSH with WP-CLI, which handles the serialized settings a plain find and replace would corrupt.
7. Clear every cache. Purge the page cache and Redis object cache from your caching plugin or WP Toolkit, then purge Cloudflare. Go to Settings, then Permalinks, and click Save Changes to refresh the URL rules.
8. Test live. Homepage, a product or post, a form submission, and a test order if it is a store. Check Tools, then Site Health, for new warnings. Then confirm the most recent real order or form entry is still there.
9. If something is wrong, go back to Backup & Restore and restore the backup from step one. That is the whole point of taking it.

On WP Alpha

Staging sites are created from the management console (Plesk with WP Toolkit), where they are one click on the site card, and the same console handles the Copy Data push back to live. Backups run every two hours and are kept 30 days, so the backup in step one is usually already there, and a restore can be queued for a single file or the whole site.

Because Redis object caching and page caching are on every plan and Cloudflare sits in front of every site, clearing caches after a push matters more here than on a bare server. VERIFY: how to purge the Cloudflare cache from the console, or whether support does this on request. If a push is more than you want to take on, support is available 24/7 by live chat and ticket and will do it with you.