Help Centre / Backups And Staging
Create A Staging Site And Push It Live
Staging is a copy of your live website at its own address, where you can break things without anybody seeing. You update plugins there, redesign a page there, test a new checkout there, and only move the result across when it works.
If you have ever updated a plugin on a live site and held your breath, this is the page that stops you doing it again.
Step 1: Create The Copy
Open the website in the members area and go to the Staging tab. Create the staging site.
You get a copy of the live site at its own address, with its own sign-in credentials. It is password protected, so it is never public and never indexed by search engines. Nobody finds it by accident and Google never lists it next to your real pages.
The copy is a snapshot of live at the moment you made it. Live carries on without it, and nothing you do on staging touches live until you push.
What Staging Costs You
| Does it count? | |
|---|---|
| A website slot on your plan | No |
| Your storage allowance | Yes, files and database both |
Staging does not use up one of the websites your plan allows, so a Build plan with one website can still have a staging copy. It does take storage, because it is a real second copy of your files and database. A 4 GB site plus its staging copy is 8 GB of your allowance. See storage explained.
If you are near your storage limit, delete the staging copy when you have finished with it and make a fresh one next time you need it.
Step 2: Sign In And Get Your Bearings
Open the staging address and use the username and the password shown when you created the copy. The password is shown once; if you no longer have it, set a new one on the Staging tab. There are two layers: the password that protects the whole copy from the public, and your WordPress sign-in inside it.
Check the address bar before you start work. More than one person has spent an afternoon carefully editing live.
Step 3: Do The Work
Anything you would be nervous about on live belongs here:
- WordPress, theme and plugin updates, especially major versions.
- Installing or trialling a plugin.
- A new theme or a redesigned template.
- Changes to a checkout, a form or anything that takes money.
- Custom code, in a child theme or a snippet.
Treat anything that sends email with care. A test order or a test form submission on staging can trigger the same notifications WordPress would send from live, so use your own address when you test.
Step 4: Test Properly
Click through the site as a visitor would, not only as an administrator. Load the home page, a few inner pages, a category, a search result. Submit a form. Run a test order end to end if it is a shop. Then check in the dashboard that the settings you changed are still set.
This is the whole point of staging, so spend the time here rather than finding the problem on live.
Step 5: Decide What To Push
A push sends staging back to live, and you choose what goes.
| What you push | What it replaces on live | Use it for |
|---|---|---|
| Files only | Theme, plugins, WordPress core (live’s uploads folder and wp-config.php are kept) | Plugin and theme updates, code and design changes |
| Files and database | Everything except live’s uploads folder and wp-config.php | A redesign where content and code changed together |
A push that includes the database also rewrites addresses: the staging URL is replaced with the live URL across the standard tables, and the site is set back to visible to search engines. A plugin that stores addresses in a table of its own may need a search-replace afterwards.
Pushing the database overwrites live content. Everything written to live since you made the staging copy is replaced, including orders, comments, form entries and new user accounts. On a shop or a busy blog, that is real data gone.
For most work on a live shop, files only is the answer. It carries your updates and your design across and leaves today’s orders alone.
If you genuinely need both, make a fresh staging copy immediately before the push, so the window of lost data is minutes rather than days.
Step 6: Push
Start the push from the Staging tab and pick the scope.
A backup of live is taken before the push begins, automatically, every time. If the result is not what you wanted, that backup is your way back. See restore a backup.
Leave it to finish. Do not edit live, start a restore or push again while it runs.
Step 7: Check Live
Open your live domain in a private window.
- The home page loads and looks right.
- The change you were making is there.
- Images load.
- A form submits and a test order goes through, if that is what you changed.
- Recent orders and comments are still present, if you pushed files only.
If pages look like the old version, that is caching rather than the push. See clear the cache.
Troubleshooting
Live looks unchanged after a push. You pushed files only and the change lived in the database, such as a plugin setting or a page built with a builder that stores layouts in the database. Check where the change actually lives, then push the database as well, accepting what that replaces.
Live is broken after a push. Restore the backup taken before the push, from the website’s backups list. Then work out what differed between staging and live before trying again.
Staging is out of date compared with live. It is a snapshot, so it drifts the moment live changes. Delete it and create a fresh copy before starting new work.
You are running low on storage. Delete the staging copy when the work is done. It is the easiest storage to free, and making a new one takes a minute or two.
A plugin asks for a licence key again on staging. Some plugins tie a licence to one address. That is the plugin’s rule, not ours, so you may need a development licence from its author.
Did this answer it? If not, open a ticket from the members area and someone who runs the platform will pick it up.
Open A Ticket