Revision History for Pages and Posts

Websites change constantly. A paragraph is rewritten, a section is rearranged, an image is swapped, a pricing note is updated. Most changes are improvements. Some are mistakes: a section deleted by accident, a layout broken by an experiment, a paragraph overwritten by a teammate who did not know someone else was editing.

Revision history is how we make those mistakes reversible. Every meaningful save of a page or blog post creates a record of what the content looked like, so an earlier version can be reviewed and restored.

What a revision captures

When content is saved through our content system, the save records the full content of the page or post along with who saved it, when and why. For visual builder pages, that includes the components and styles that make up the layout. For blog posts, it includes every content block in order.

Revisions are not just a list of timestamps. They hold enough to bring the content back exactly as it was.

A second copy outside the database

For blog posts, each save also writes a copy of the post's content to a backup file stored under that account and website. If something unusual ever happened to the database row, the latest content would still exist as a readable file. It is a small redundancy that costs almost nothing and protects work people care about.

Every path records revisions

A revision system only works if every way of saving goes through it. In our platform, the visual builder, the blog editor, imports and the scripts we use to publish content for customers all save through the same content store, so they all leave revisions behind.

That consistency matters more than it sounds. If an import or a publishing script wrote directly to the database, there would be no record of the content before it changed. When we rebuilt this website, every page was saved through the same store an editor uses, with a recorded reason, so the history shows exactly what arrived and when.

Guards against accidental loss

Some saves deserve extra suspicion. A save that would remove most of a page's images, or drop its styles entirely, is more likely to be a bug than an intention. Our page store includes guards that notice those patterns and stop the save, protecting the current version until a person confirms the change is real. Automated publishing can deliberately skip a specific guard when it is replacing content on purpose, and it records that it did.

Restoring is a new save, not a rewrite of history

When an owner restores an earlier revision, the platform saves that older content as a new revision rather than deleting the ones in between. History only moves forward. If the restore turns out to be the wrong choice, the version it replaced is still in the list.

Reasons make history readable

A list of saves is only useful if you can tell them apart. Each revision records a short reason for the save: an editor's manual save, an import, a restore, an automated publishing run. When something looks wrong on a page, the history shows not just when it changed but how. A change that arrived through an import reads differently from one an editor made by hand, and that context usually points straight at the cause.

Revisions are not a substitute for backups

Revision history protects individual pages and posts. It does not protect an entire account against a larger problem, such as a bad import touching hundreds of records at once. That is the job of account backups, which we hold to their own strict standard. The two work at different scales, and we keep both. You can read about that standard in a backup is not a backup until it is verified.

Revisions and the trash work together

Revisions recover earlier versions of content that still exists. The trash recovers content that was deleted. Between the two, most of the everyday ways people lose work are covered. You can read about the trash in soft deletes and a 30-day trash.

What this means for teams

Revision history changes how teams feel about editing. When people know a mistake can be undone, they are more willing to improve things, experiment with layouts and fix small problems as they see them. Fear of breaking the website is one of the biggest reasons sites go stale. Removing that fear is a quiet but real benefit of building on VoVo.

Frequently asked questions

Can I undo changes to a page in VoVo?

Yes. Saving a page or post records a revision, and earlier revisions can be reviewed and restored.

Does restoring an old version delete newer ones?

No. Restoring saves the older content as a new revision, so the version you replaced remains in the history.

Are imported pages included in revision history?

Yes. Imports and automated publishing save through the same content store as the editors, so they leave revisions too.