You need to change a block on the home page, update a plugin, or add a new form. The easiest way is to do it right on the live site: log in, edit, save. Usually it goes smoothly, but one day such an edit breaks the mobile layout, the form stops sending requests, or the site does not open at all.
To avoid that, changes go to a staging copy first. Below is what it is and how a safe update routine works.
What a staging copy is
It is a second instance of the site at a separate address that only you and the developer can see. It is set up like the live one: the same code, similar settings, similar content. Every change appears there first, where it can be checked calmly on different devices before moving to the live site.
Why editing the live site is risky
- Visitors see the mistake while it is being fixed
- A plugin or library update can break something connected to it, and that is not always visible at once
- Going back is hard if the previous version was not saved
- A broken form can quietly lose requests until someone notices
Updating the engine and plugins is especially risky; why updates are needed at all is covered in small site security.
A safe update routine
A normal process looks like this: changes are made on the staging copy, where the home page, key pages, forms, and the mobile view are checked. Then the changes move to the live site, ideally automatically rather than by copying files by hand. A backup is saved before the move, so you can roll back in minutes if something goes wrong.
After the move, send a test request again and open a couple of pages. It takes a few minutes and removes most of the risk.
Data and search
A staging copy must not end up in search engines, or duplicate pages will show up in results. It is closed with a password or a no-index rule. A password is more reliable, since search engines do not always obey the rule.
If the site holds client data, it is not copied to staging as is: it gets replaced with made-up data, or only the needed part is used. Forms on staging send requests to the developer, not to managers, so test messages confuse nobody.
Does a small site need it
For a landing page that changes twice a year, a permanent separate copy may be overkill. But the "check first, then publish" rule still applies: changes can be built and reviewed on the developer's computer. For a store, a site with client accounts, or forms that bring in requests, a staging copy pays off with the first failed update.
Setting it up is usually part of support after launch.
A staging copy, safe updates, and backups are part of the support service. If you want to bring order to your site updates, get in touch.