Staging vs production: what a deployment is on a client site
Staging vs production, explained for client sites: what a deployment is, why changes land somewhere private first, and what promoting to live actually does.
A client asks you to change the opening hours on their site, and to preview the new services page before it goes live. The first one's urgent, the second one isn't ready, and they're on the same site. If both go live the moment you press save, one of them goes live too early. That's the problem staging solves.
Definitions, without the jargon
Production is the site the public sees. It's the live site, at the client's real address.
Staging is the same site, kept private, for checking. It has the same content, the same design and the same pages, plus whatever changes haven't been approved yet. Nobody outside the project should be able to see it.
A deployment is a recorded version of the site. Each time a set of changes is moved somewhere, to staging or to production, that's a deployment, with a record of what changed, when and who did it.
Promoting is moving what's on staging to production. It's the moment a change goes live.
Why it matters for content, not just code
Developers have used staging for years, for code. The case for content is just as strong, and often more pressing on a client site.
A client's half-finished page. They've started the new services page, saved it, and gone home. Without staging, saved and live are often the same thing.
An agent's bulk edit. An AI agent updating eighty product descriptions will do it in a minute. If it misread the brief, you want to find out before the public does.
A theme change. A new section design or a font change touches every page at once. Checking it on a private copy of the real site, with the real content, catches the problems a design file never shows.
Each of these is a change worth looking at before it's live. Staging is where you look.
How it works on Contentive
Publishing lands in staging. Every site has a standing staging address next to the live one, and every page there shows a "Staging preview — not the live site" bar with a link to promote, so nobody confuses the two. Staging is private by default: to share it, you send a preview link, which is signed and expires. Without one, a visitor sees a gate page.
Going live is a separate, deliberate step. Someone promotes staging to production, from the Studio, or an agent does it with a tool built only for that. Promotion only ever moves staging forward; nothing jumps straight to live by accident.
Rolling back a theme works the same way. You pick an earlier deployment, a new staging version is made from its exact files, and you promote that. Roll back, then promote. Content has its own safety net: every document keeps a version history, and any earlier version can be restored. Every deployment is recorded, so you can always see what went live and when. Website staging for clients covers how to run client sign-off on top of this.
The awkward case: urgent fixes
The opening hours can't wait for a review cycle. So production stays editable for hot fixes, and on Contentive an edit made directly on the live site also writes its staging copy. That way staging never quietly falls behind, and the next promotion doesn't undo the fix.
If a live page was edited after its staging copy, for whatever reason, promotion refuses until someone acknowledges it, and names the pages. You find out about the conflict before it costs anything, not after. And if staging has drifted too far to be useful, it can be reset from production: staging is discarded and the live content copied back, as a dry run until you confirm.
What it costs
One extra click. Every change that should go live needs someone to promote it, and for a client fixing a typo, that click can feel like ceremony.
More importantly, someone has to own the promote. If everyone assumes someone else will press it, changes sit on staging for weeks. If everyone can press it, the review step means nothing. Neither failure is technical. Both are about who's responsible.
There's also the matter of deciding which changes can skip review. A typo fix probably can. A new page probably shouldn't. Write the rule down rather than deciding it fresh each time.
What a deployment record tells you
Because each deployment is recorded, staging and production stop being a mystery. You can see what's on staging that isn't live yet, when production last changed and who promoted it. When a client asks "when did this go up?", there's an answer. When something looks wrong on Monday, you can see what changed on Friday. That history is also what makes rolling back a theme safe: you're not reconstructing an old version from memory, you're picking a recorded one.
When staging is too much
A site with one editor, who edits twice a year, and no agent or theme work in progress, gets little from a review step. Even then, having it costs almost nothing, and the first time a client's half-finished page doesn't go live, it pays for itself. What to do when a client breaks their own website is the story of when it isn't there.
The decision to make on every project
Before launch, decide who is allowed to promote to the live site, and who reviews before they do. It might be you, the client's marketing lead, or both, depending on the kind of change. Then write it into the handover, by name. The website handover checklist has a line for it, and the website pre-launch checklist covers the first promote of all.