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.

The visitor arrow never crosses into the lower box. Your live site is copied from, and written to exactly once — after the change has already been tested somewhere it could safely have failed.

Read this as text

Your live site keeps serving visitors throughout. Nothing in this process interrupts it until the very last step.

Before significant work, we refresh a staging copy from the live site — an exact copy on a private URL that visitors cannot stumble across. Every change, update and fix is made there.

We then test it: key pages, navigation, forms, and whatever the change actually touched. For visual work or new content we usually share the staging URL so you can review it and say yes before anything moves.

Only once it has passed do we apply the same tested change to the live site. So the live site is read from at the start and written to once at the end, and everything that could go wrong goes wrong somewhere your customers never see.

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

Can I see my staging site?

Yes. We're happy to share the staging URL with you so you can preview changes before they go live. Just ask your project lead.

How long does it take to push from staging to live?

For most sites, pushing from staging to live takes 15–60 minutes. Larger sites with lots of media can take longer.

What if I update content on my live site while you're working on staging?

Let us know before we push staging to live. We'll check what's changed on the live site and make sure your updates aren't accidentally overwritten.

What's the difference between staging and a backup?

A backup is a saved copy of your site used for recovery if something goes wrong. A staging site is an active working copy used for testing changes before they go live. Both are important — staging prevents problems, backups are the safety net if a problem still occurs.

Need a hand?

If you're stuck, email support@chykalophia.com and we'll help. Include your website address and a screenshot if you can.

How we test changes before they go live

On this page