Versions
Don’t like it? Put it back the way it was. In seconds.
Every change to your website, whether your team makes it or the AI does, is a version with its author, its date, what was asked for and what it cost. You see it in a preview before publishing, you compare file by file what changed, and if you regret it you go back to the previous one with one click. The history is never rewritten and nothing is overwritten in silence.
change «the button in yellow»
change «a dark background»
change «the title on the left»
change «a bigger title»
change «a rounded button»
Step by step
The path of a change, from the moment it’s asked for to the moment it can be undone
The same four steps for everyone: for the change you ask the AI for on a Tuesday and for the one our team writes on a Thursday. There’s no fast lane that skips the history, not even for us.
-
The change is saved as a version
With its number, its author, which version it started from and a note. If it came from the AI, also with the prompt, the model and the credits it cost.
v19 · you with AI · “change colors”
-
It’s built somewhere else
In an isolated container, with no network and no access to your database. Out comes a sealed package that’s never touched again, and that’s what your domain will serve the day you publish it.
one package per version · immutable
-
You review it in its preview
Its own address, outside your domain, never in Google, behind a signed link that expires. It’s the same mechanism as your real site: a preview built differently proves nothing.
yourname-v19.preview.wixy.app
-
You publish, and you can undo it
Publishing changes which version your domain serves. If Monday’s meeting doesn’t like it, you go back to v18 without rebuilding anything, because v18 is still whole and right where it was.
publish · roll back · seconds
None of these steps erases the one before it. When you publish v19, v18 is still complete; that’s why going back isn’t redoing the work, it’s pointing at something that already exists.
What every version stores
A version is a complete snapshot, not a patch
It stores the whole set of your customizations at that moment, along with who made it and why. That’s why restoring is exact and rolling back is cheap.
-
Who, when and from where
v18, team, “New hero”. v19, you with AI, “Change colors”. Every line says who made it, which version it started from and with what note. A change of ours never shows up as if you’d made it, or the other way around.
-
The prompt and what it cost
If the version came from the AI, it stores the prompt, the scope, the model and the credits spent. At the end of the month you know where the balance went without opening an invoice or asking anyone.
-
A preview on a separate address
It’s served on its own address, never on your domain, not indexed and behind a signed link that expires. Send it to your business partner and they can weigh in before any customer sees it.
-
Publishing moves a pointer
That version’s package is already built. Publishing compiles nothing: it changes which version your domain serves and takes as long as one database query. Rolling back is the same move with the previous number.
-
Compare, file by file
A diff between any two versions, and against the base theme. If your team changed the footer and the AI changed the hero, you see exactly what each one touched before deciding which one stays.
-
A failed build doesn’t touch your site
If a version doesn’t compile, it’s marked as failed with its error log and the published one stays intact. And if the new package fails on startup, the platform goes back to the previous one on its own, writes it down in your history and alerts us.
The proof
Restoring deletes nothing: it creates a new version
A version is never edited. Keep editing and you create a child; restore v18 and you get a v22 with the exact contents of v18, while the v21 nobody liked stays in the history so the story still makes sense. The history always explains what you see on your site, and it isn’t rewritten even when the change was ours.
-
v18 is still v18
Going back to it doesn’t move it or overwrite it. You can restore the same version three times in a month and all three are written down, with the date and who did it.
-
Publishing an old version is the same as rolling back
There aren’t two mechanisms, one to move forward and another to change your mind: it’s the same pointer aimed at a different number. That’s why going to v14 costs the same as going to v21.
-
The published one and the one before it are never archived
Whatever your plan’s retention says. Being able to undo the last change isn’t a paid extra, and for an archived version we still keep its description to rebuild it from.
Every version can be previewed, compared and restored.
- v21 You · AI You added testimonials published2 hours ago
- v20 Team Mobile responsiveyesterday
- v19 You · AI You changed the hero3 days ago
- v18 Team Initial design2 weeks ago
You and your team, at the same time
Nothing is overwritten in silence. Ever.
Your designer changes the hero from their editor. At the same hour, you ask the AI for another change to the hero. Every version knows which one it started from, and publishing requires that the published one still be what it was. If it isn’t, the panel tells you plainly: “v21 was published while you were preparing this change.” You compare, merge if the two touched different files, regenerate on top of the new one, or discard. Inside the same file nothing is merged: asking is cheaper than losing work.
- While your team has the site open, the panel warns you before you generate.
- Merge only when it’s safe: when the two changes touch different files.
- Everything goes into the audit log: who, what, when, with which prompt and at what cost.
Publish and roll back
Publishing moves a pointer. Undoing it is the same move.
Each version’s package is already built and stored, so publishing compiles nothing and never takes your site down for a while: it changes which version your domain serves and takes as long as one database query. Going back to the previous one is exactly the same thing with a different number. A visual builder can’t offer you this, because it has no versions: it has a canvas with an undo button.
Questions
What people ask about versions
Can I see the change before I publish it?
Always. Every version is built and served on its own preview address, outside your domain, not indexed and behind a signed link that expires. By default it shows your published content; drafts are only visible with a content preview link, which is requested separately.
Who can publish?
It depends on the plan and on each user’s permission. With direct publishing, the user with publish permission does it from the panel and it’s audited. With an approval workflow, they request publication and the team compares, approves or rejects with a comment. The team can change the workflow for one client without changing their plan, after a scare, for instance.
What if my team and I change the same thing?
Nobody loses their work. Your version is created anyway (it’s already done) and the panel warns you that another one was published in the meantime. You compare the two, merge them if they touch different files, regenerate on top of the new one, or discard. Nothing is ever merged automatically inside the same file: two hands rewriting the same component have no sensible merge, and pretending otherwise is how work gets lost.
How long does a published change take to show up?
As long as one database query, because that version’s package was already built before you pressed publish. And there’s no cache to clear by hand: every page’s address carries the version number inside it, so the new one is requested on its own and the old one expires without anyone deleting it.
How many versions are kept?
It depends on the plan. Old ones are archived by retention, but the published version and the one before it are never archived: being able to go back isn’t a paid extra. And even if an old version’s package no longer exists, its description is still there and it’s rebuilt from that.
What about when you improve the base theme?
If we improve a file in the base theme, clients who didn’t customize it receive it on their own, as a version of system origin in their history that rolls back like any other. Whoever customized it keeps their own: a customization is never overwritten. If the base has changed a lot since then, the team sees it flagged, compares the two changes and decides with you.
What happens to my website if I leave?
You take it with you. Your theme is code files and its history is a list of versions: your team opens any of them on their own machine with the platform’s command line, today and the day you leave, and your content comes out through the API as JSON. If you want it all in one package, we put it together for you. Managed, not held hostage.
Your history starts with your first change
The Free plan already gives you versions, previews and rolling back: a site at yourname.wixy.app and 50 credits a month, no card needed.