Why we never test changes on your live site
Every developer knows a story about a “quick change” made straight on a live website. A plugin update that turned the homepage white. A small style tweak that hid the checkout button on phones. A search-and-replace that rewrote every link on the site. Visitors saw it before anyone else did.
A staging site is how you avoid becoming one of those stories. It’s a private copy of your website where changes are made and tested first, so the live site only ever receives changes that are known to work.
What a staging site is
Staging is a second copy of your site, usually at an address like staging.yoursite.com. It runs on the same kind of server, with the same versions of WordPress, PHP and plugins, and a copy of your content and settings, so it behaves like the real thing.
Many managed WordPress hosts create one in a click. On other hosting, a developer can set one up on a subdomain or a separate server.
What gets tested there
- Updates to plugins, the theme and WordPress itself
- PHP upgrades, the riskiest routine change most sites face
- New features and design changes, which you can review before they go live
- Bug fixes, to confirm the fix works and hasn’t broken something else
- Anything with “just” in the request: “just change the menu”, “just add a plugin”
Set it up so it can’t do damage
A copy of your live site is a copy of everything, including the parts that talk to the outside world. Before anyone uses staging, make sure it can’t:
Email your customers. A copied shop still has your real customers’ email addresses. A test order, a password reset or a scheduled newsletter on staging sends real emails to real people. Route all staging email to a catch-all inbox or a mail-catching tool instead.
Take real payments. Switch payment gateways to test or sandbox mode, remove the live API keys, and turn off webhooks that notify other systems about orders.
Change other systems. Stock feeds, CRMs, accounting software and delivery integrations should be switched off or pointed at test accounts. Otherwise staging can change real stock levels or raise real invoices.
Appear in Google. Put the whole staging site behind a password. WordPress’s “Discourage search engines” setting is a request, not a lock, and it’s easy to copy it to the live site by mistake, which quietly removes the real site from search results.
Run scheduled jobs twice. Copied scheduled tasks, like imports or reminder emails, can run alongside the live site’s. Disable the ones that act on real data.
It also helps to set WP_ENVIRONMENT_TYPE to staging in staging’s wp-config.php. WordPress and some plugins read it and adjust their behaviour for a non-live site.
The rule: code goes up, content comes down
This is the part that catches people out. While you’re testing on staging, the live site keeps changing: new orders, form entries, posts and customer accounts.
Copy the whole staging site over the live one, database included, and all of that is overwritten. A week of orders can vanish in one click.
So changes move in two directions, and never mix:
- Code goes up. Themes, plugins and configuration move from staging to live, ideally through version control such as Git, so every change is recorded and can be undone.
- Content comes down. When staging gets out of date, refresh it with a fresh copy of the live database. Content never travels from staging to live.
When a change needs settings changed in the database, like a new menu structure, make those changes again on the live site from written steps, or script them so they run the same way twice. If your host’s “push to live” button offers a choice, push files only unless you’re certain.
A typical update, start to finish
- Refresh staging from the live site.
- Back up the live site.
- Apply the updates on staging.
- Check the pages and journeys that matter: forms, search, logins, the checkout in test mode, and the layout on a phone.
- If something breaks, fix it or hold that update back. The live site hasn’t noticed a thing.
- Apply the same updates to the live site, and check the same pages again.
It takes longer than clicking “Update all” on the live site. It’s also the difference between you finding a problem and your customers finding it.
Isn’t this overkill for a small site?
For a five-page brochure site with no forms, a backup before updating may be enough. But most business sites have at least one thing that would hurt to break: an enquiry form, a booking system or a shop. The more a broken site would cost you, the more staging is worth.
Every WordPress rebuild we do comes with a staging site you can log into during the build and keep afterwards, and updates on our care plans are always applied on staging first.