How we test changes before they go live
What a staging site is, why we use one, and how it protects your live website from being accidentally broken.
Before any significant change reaches your live website, we test it in a safe, private copy called a staging site. This guide explains what that means and why it matters.
Quick summary
A staging site is an exact private copy of your website. We make changes and test them there first. Only when everything looks correct do we push the changes to your real, live site. This means your visitors never see broken or incomplete work.
What is a staging site?
A staging site (sometimes called a test site or development site) is a hidden copy of your website. It lives on a private URL that visitors can't stumble across. It looks identical to your real site, with the same content, design, and settings.
We use it as a safe space to:
- Test software updates before applying them to the live site
- Preview and review design changes
- Build new features or pages before revealing them
- Test fixes to make sure they actually work
Your live site stays untouched
While we work on the staging site, your live website continues running normally. Visitors, customers, and search engines are not affected. We only change the live site once everything has passed testing.
Why staging matters
Without a staging site, any change — even a small one — is made directly to your live website. That means if an update breaks something, your visitors see it immediately.
With a staging site:
- We catch problems before they reach real visitors
- We can test edge cases and unusual scenarios safely
- We can take our time getting something right without rushing
- You can review changes and give feedback before they go live
What the process looks like
We create or refresh the staging site. For most care plan clients, we have a staging environment already set up. Before significant work, we refresh it to match the current live site.
We make changes on staging. All updates, new features, or fixes are applied to the staging copy first.
We test thoroughly. We check key pages, navigation, forms, and whatever functionality is relevant to the change we made.
We may invite you to review. For visual changes or new content, we'll often share the staging URL with you so you can review and approve before it goes live.
We push to live. Once everything passes, we apply the changes to the real site using the same tested approach.
We verify the live site. A quick check on the live site confirms everything transferred correctly.
When we use staging
We use a staging site for:
- Software updates (WordPress core, plugins, themes) — see Software updates explained
- Significant design or layout changes
- Adding new features or integrations
- Major content restructuring
- Any change that could potentially break something
For small content changes — like fixing a typo or updating a phone number — we may make these directly on the live site without staging, since the risk is very low.
What staging does NOT do
Staging is very useful, but it's not perfect. A few things to know:
- Staging databases may not sync in real time. If you update content on your live site while we're working on staging, we'll need to be careful not to overwrite your live content when pushing the staging changes.
- Some integrations behave differently on staging. Payment gateways, some APIs, and certain email tools are designed to work differently (or not at all) on non-live sites.
- Staging tests can't predict every real-world scenario. We test what we can, but occasional issues still arise on the live site. That's why we always have a backup ready before any push.
Common questions
Related guides
- Software updates explained
- How backups work
- What our care plan covers
- Pre-launch checklist for a big update
- What is a staging site
Need a hand?