Website staging for clients who want to see it first
Website staging for clients who want to see it first: give them a private preview address, review changes there, then promote to live when they say yes.
Some clients want to approve everything. Not just the launch, but every new page, every changed paragraph, every swapped photo. The usual way of handling this is screenshots: you make the change somewhere, capture it, paste it into an email, wait for a reply, and then make the change again on the live site, hoping it matches what they saw.
It doesn't scale and it isn't accurate. A screenshot shows one width on one screen. It can't be clicked. It shows the page you chose, not the three other pages the change affected. And the reply, when it comes, is approval of a picture rather than of the site.
Website staging for clients replaces the screenshot with the real thing: a private copy of the site where changes land first, which the client can browse exactly as a visitor would, and which only goes live when they say yes.
What you need
Three things, whatever platform you're on.
A standing staging address. A real URL for the staging copy, that stays the same from one change to the next. The client bookmarks it once. You don't send a new link for every review.
Private access. The staging copy must not be public, and must not be indexed. The cleanest way is a preview link: a signed link that grants access for a limited time. A shared password works too, but passwords get forwarded and rarely change.
An obvious label. Every page on staging should say, unmissably, that it isn't the live site. Without it, someone at the client will review the staging site, forget which tab is which, and report a "bug" on the live site that's actually an unreleased change. Or worse, send a staging link to a customer.
The review loop
Once those exist, the loop is short.
Change. You, or the client's own editor, make the change. It lands on staging, not live.
Share. Send the staging address, or a fresh preview link, with one sentence about what changed and which pages to look at.
Approve. The client browses the real pages, on their own devices, and replies with a yes or a list.
Promote. Someone puts the approved version live.
Decide up front who does step four. If it's you, you're in the loop for every change forever. If it's the client, they need the access and the confidence to do it, and a clear rule about what they're promoting. Often the right answer is a named person at the client, the one who approves, so approval and going live are the same act.
Staging drift
The awkward part of staging isn't the review. It's keeping staging and live in step.
Drift happens two ways. Someone makes an urgent fix directly on the live site, the phone number was wrong, and staging still has the old one. The next promote quietly puts the wrong number back. Or a change sits on staging for weeks, never approved, while live moves on around it, and nobody remembers what's waiting.
Whatever your tools, have a rule for each. Urgent fixes on live must be repeated on staging the same day. Anything on staging older than a fortnight gets either approved or thrown away. And before any promote, someone looks at what's actually about to change, not just at the page they were asked to check.
How this works in Contentive
Staging is how Contentive works by default, so most of the above comes built in. Every site has a standing staging address next to the live one, and every page there carries a "Staging preview — not the live site" bar with a Promote link. Staging is private: a visitor without a preview link, which is signed and expires, sees a gate page instead. Publishing lands on staging, and going live is a separate promote step. The Studio works on a phone for this, so if the person who approves also has permission to promote, they can approve on the train and put it live from the train.
The drift problems are handled too. A fix made directly on the live site also writes to its staging copy, so staging doesn't quietly fall behind. If a live page was edited after its staging copy, promotion stops, names the pages, and won't go ahead until someone acknowledges it. And if staging has wandered somewhere nobody wants, you can reset it from production: it discards staging and copies the live content back, as a dry run first until you confirm.
What it costs
A slower loop for small edits. If every typo fix needs a share, a reply and a promote, a two-minute change takes a day, and both sides get irritated. The client who insisted on reviewing everything starts approving without looking, which defeats the point.
So decide which kinds of change skip review. A reasonable split:
Skip review: typo and spelling fixes, a replaced photo of the same thing, opening hours, a price change the client asked for in writing, a news post the client wrote themselves.
Review first: a new page, a new section on an existing page, anything on the home page, anything legal, anything that changes what the business offers.
Always review: a theme or design change, a navigation change, a bulk change across many pages.
The exact split matters less than having one, written down, that both sides agreed to.
When the client breaks it anyway
Staging catches most mistakes before they're public, but not all of them, especially when someone with access edits live directly. What to do when a client breaks their own website covers the hour after. And for the concepts underneath all of this, staging vs production explains what a deployment is in plain terms.
Write it into the contract
The review rule belongs in the contract or the support agreement, not in an email thread. One paragraph: which changes go to staging for approval, which go straight live, who approves, who promotes, and how quickly you'll turn a review round. Add it to your handover checklist so it's agreed at launch, before the first change request arrives and makes it urgent.