Preview deployments: how we show you changes before they go live
Every change gets its own live link before it touches the real site. What a preview deployment is, how approval works, and why it beats screenshots.
The short answer
A preview deployment is a live, complete copy of your website with one proposed change applied, published automatically to its own private address the moment the change is proposed. You open it like any website, on your phone and on your laptop, click through the affected pages, and approve or comment. Nothing reaches the real site until you have seen it working.
It is the single biggest improvement to how changes are approved that we know of, and it costs nothing extra on a modern platform.
How a change flows
- A change is proposed. New text, a new section, a fix, a new page. The developer submits it to the repository.
- A preview is built automatically. Within a minute or two, a link exists with the whole site plus that change.
- You review on the link. Real pages, real behaviour, on your own devices. Forms can be tested, menus opened, the mobile view checked.
- You approve or comment. A comment triggers a fix and a new preview. An approval merges the change.
- The live site updates. The same build that you approved is deployed, so what you saw is what goes live.
Why it beats the alternatives
| Method | What you actually see | What goes wrong |
|---|---|---|
| Screenshot | One frozen state at one screen size | Behaviour, other screen sizes and interactions are invisible; “not what I meant” after launch |
| Shared staging server | Everyone’s half-finished changes mixed together | Never matches live or any single change; someone else is always testing on it |
| ”Trust us, it is fine” | Nothing | Everything |
| Preview deployment | The live site plus exactly this change, on any device | Rarely anything; problems are found before launch |
The side effect: a record
Every preview link is a record of what was proposed, when, and who approved it. Six months later, “when did we change the pricing page and who signed off” is answered by a list rather than by memory. That record also makes rollbacks trivial: the previous approved build is still there and can be made live again in a minute.
What this means for you
If your website changes are approved from screenshots, or by hoping, ask for preview deployments. On a modern platform they come for free with every change, they let you approve the real thing on your own devices, and they leave a record. If your current hosting cannot do it, that is one of the clearest signs the platform is due for a move.
Frequently asked questions
Is a preview the same as a staging site?
A staging site is one shared copy that everyone's changes pile into, so it rarely matches either the live site or any single change. A preview is one copy per change, built from the live site plus that change only, and thrown away after. You always see exactly what will go live, nothing more.
Can customers or search engines find preview links?
They are not linked from anywhere, they tell search engines not to index them, and they can be protected with a login when the content is sensitive. Treat them as private links to share with the people who need to approve.
What if I find a problem in the preview?
You comment, we fix, a new preview is built automatically, you check again. Nothing has touched the live site. That loop is the whole point: problems are found on a copy nobody else can see.
Does this slow things down?
It speeds them up. Approval on a real link takes minutes; approval on a screenshot leads to 'that is not what I meant' after launch. And because the build is automatic, there is no waiting for someone to upload files to a server.
Sources
- Vercel documentation: Preview deployments (accessed 2026-09-11)