Staging is a separate copy of your WordPress site where you can test changes before applying them to the live site.
It helps you update plugins, change themes, edit pages, test custom code, or check new settings without affecting real visitors.
Good to know
Staging is used for testing. Your live site is the version users actually visit.
What staging means
Staging is a test copy of your site
A staging site is a separate environment based on your WordPress site.
You can use it to test changes before publishing them.
For example, instead of updating plugins directly on the live site, you can update them on staging first and check whether anything breaks.
Live site vs staging site
Your live site is the public version of your website.
Your staging site is a private or separate test version used for safe changes.
Simple explanation
Live site = what your visitors see.
Staging site = where you test before changing what visitors see.
When to use staging
Use staging before risky changes
Use staging when a change may affect how the site works, looks, or converts visitors.
You should use staging before:
- updating WordPress core;
- updating multiple plugins;
- changing the active theme;
- editing important pages;
- testing new plugins;
- changing checkout settings;
- changing forms;
- testing custom code;
- changing caching or performance settings;
- preparing a redesign;
- making WooCommerce changes.
Recommended
If a change can break layout, forms, checkout, user login, or important pages, test it on staging first.
Use staging for business-critical pages
Staging is especially important for sites that depend on:
- payments;
- lead forms;
- bookings;
- user accounts;
- memberships;
- WooCommerce;
- campaigns;
- paid traffic landing pages.
If these pages break on the live site, it can affect revenue, leads, or customer trust.
Important
Do not test critical changes directly on a live site if users, orders, forms, or payments can be affected.
How to create a staging site
Open your WordPress instance
To create a staging site, open your Antihost panel and select the WordPress instance you want to work with.
Make sure you choose the correct site if you manage more than one WordPress instance.
Go to the staging section
Inside the selected WordPress instance, open the staging section.
If staging is available on your plan, you should see an option to create a staging environment.
Create staging
Start the staging creation process.
Antihost will create a separate copy of your WordPress site for testing.
This may take some time depending on the size of the site.
Important
Do not make major live-site changes while staging is being created. Wait until the staging environment is ready.
Open the staging site
After staging is created, open it and check that it loads correctly.
You may also need to log in to the staging WordPress admin area to start testing changes.
Good to know
Staging may use a different URL from your live domain. This helps separate the test environment from the public site.
What “push to live” means
Push to live publishes staging changes
“Push to live” means applying changes from the staging site to the live site.
This is the step that takes tested changes and moves them to the public website.
Use it only after you have checked that the staging version works correctly.
Important
Push to live affects the real website. Do not use it until the staging site has been tested.
Push to live may replace live data
Depending on how the platform handles staging, push to live may transfer files, database changes, or both.
This matters because the live site may have changed after staging was created.
For example, the live site may have received:
- new orders;
- new form submissions;
- new comments;
- new user registrations;
- new content updates;
- new media uploads.
If database changes are pushed from staging to live, some recent live data may be overwritten.
Critical note
If your site has WooCommerce, bookings, memberships, user accounts, or active forms, confirm what will be transferred before using push to live.
What gets transferred
Files may be transferred
A staging-to-live push may include files such as:
- theme files;
- plugin files;
- uploaded media;
- custom code;
- WordPress files changed during testing.
This is useful when you tested a new theme, plugin update, or code change.
Database changes may be transferred
A push may also include database changes.
The database can include:
- page content;
- posts;
- plugin settings;
- theme settings;
- menus;
- widgets;
- users;
- WooCommerce orders;
- form submissions;
- site options.
Important
Database transfer is the risky part. If live users created data after staging was created, a database push may overwrite newer live data.
Transfer options may depend on the platform
Some systems allow different push options, such as:
- files only;
- database only;
- full push;
- selected tables;
- selected changes.
If Antihost provides these options, choose the safest one for your change.
Best practice
For design or code changes, a files-only push may be safer. For content or settings changes, database changes may be required. Always check what the push action includes.
What not to do on the live site
Do not test risky updates directly on live
Avoid making risky changes directly on the live site.
This includes:
- bulk plugin updates;
- theme switching;
- major WordPress updates;
- checkout configuration changes;
- custom code testing;
- database changes;
- new caching rules;
- large layout changes.
Do not experiment during active traffic
Avoid major live-site changes during peak traffic, paid campaigns, launches, or sales periods.
If something breaks during active traffic, users may see errors immediately.
Simple rule
If users can notice the mistake, test it on staging first.
Do not push staging to live without checking recent live data
Before pushing staging to live, check whether the live site received important new data after staging was created.
This is especially important for:
- WooCommerce stores;
- booking websites;
- membership websites;
- LMS platforms;
- lead generation sites;
- sites with user accounts.
Before push to live
Check whether new orders, leads, users, or content were created on the live site after staging was created.
How to check changes before publishing
Check the staging site as a visitor
Open the staging site and test it like a real visitor.
Check:
- homepage;
- key landing pages;
- navigation;
- forms;
- buttons;
- images;
- mobile layout;
- page speed behavior;
- checkout flow, if used;
- login or account pages, if used.
Check WordPress admin
Log in to the staging WordPress admin and confirm that the admin area works correctly.
Check:
- plugins;
- theme settings;
- pages;
- menus;
- widgets;
- site settings;
- custom plugin settings.
Test critical flows
Before pushing changes to live, test the flows that matter most for your website.
Examples:
- submit a contact form;
- add a product to cart;
- complete a test checkout, if possible;
- log in as a user;
- check booking flow;
- test newsletter signup;
- check payment-related pages;
- check campaign landing pages.
Recommended
Test the site on desktop and mobile. Many layout issues only appear on smaller screens.
Create a backup before push to live
Before applying staging changes to the live site, create a fresh backup of the live site.
This gives you a restore point if something goes wrong.
Important
Always create or confirm a recent live backup before using push to live.
When to contact support
Contact support before risky staging actions
Contact Antihost support if:
- you are not sure what push to live will transfer;
- the live site has recent orders, leads, or user registrations;
- staging creation fails;
- the staging site does not load;
- WordPress admin does not work on staging;
- push to live fails;
- the live site breaks after pushing changes;
- you need help choosing between files-only, database-only, or full push, if available.
What to include in your support request
When contacting support, include:
- your domain name;
- your WordPress hosting plan;
- whether the issue is on staging or live;
- what change you tested;
- whether the site uses WooCommerce, forms, bookings, memberships, or user accounts;
- whether you already pushed changes to live;
- any error message shown in the panel.
Why this matters
Staging issues can affect live data if the wrong push option is used. These details help support understand the risk before making changes.
Summary
Staging helps you test safely before changing the live site
Use staging to test updates, plugins, themes, code, content, and configuration changes before applying them to your public website.
Before using push to live, check what will be transferred and whether the live site has received new data.
For business-critical sites, create a backup before publishing staging changes.