Version history
Every draft save snapshots the page. Fifty versions per page are kept, restoring one is itself undoable, and reverting to published is a different operation with a different meaning.
A page keeps its own history. You do not turn it on, and there is nothing to configure - editing a page is what writes it.
What gets snapshotted, and when
A snapshot is taken when the page changes in a way worth being able to undo:
- a draft save from the editor
- a surgical block patch, the kind the MCP server makes
- a dev draft promotion
- a restore - see below, because this one is the interesting case
Each entry records the version number, when it was taken, and who caused it. Restoring reads the blocks out of the snapshot, so a version is a copy of the content, not a diff against its neighbour.
Fifty per page
Fifty snapshots are kept per page. Number fifty-one pushes the oldest out, and the pruning happens inside the write itself rather than in a nightly job, so the cap is enforced the moment it is exceeded rather than the next morning.
The consequence is worth planning around on a page under heavy editing: fifty saves is not a long time. If a specific state matters - a legal review, a launch - publish it or copy it somewhere, because the history will roll past it.
The cap exists because unbounded history is not free. Page history was the largest collection in the database before it had one.
Restoring
Restoring takes an old version and makes it the current draft. Three things about it are worth knowing before you need them:
Restoring is itself undoable. The current state is snapshotted before the old one overwrites it, so a restore you regret is one more restore away from being undone. You cannot lose the present by reaching for the past.
It restores content, not the whole page. Blocks come back. A version that carries no blocks is refused - This version has no restorable content - rather than silently emptying the page.
It is checked against today's block manifest. If a block type changed shape since the snapshot, or was removed from your codebase, the restore reports warnings instead of pretending the old content still fits. Old content, current rules.
A restore lands in the draft. Nothing reaches your site until you publish, which means you can restore, look, and change your mind with no reader ever seeing it.
This is not the same as reverting to published
Two operations sound similar and answer different questions.
- Restore a version - "put back what the page looked like on Tuesday". Reaches into history.
- Revert to published - "throw away my unpublished changes". Reaches for the live version, and touches no history at all. Content and layout can be reverted separately, or together.
If you have been editing all afternoon and want the live page back, revert to published. If you want a state that is not live and not current, restore a version.
Where it lives
The history panel sits in the editor's right pane, listing versions newest first. The same thing is available over GraphQL - page.history to list, page.restoreVersion to restore - which is what you would script against if you wanted, say, a nightly export of every page's last known good state.
Next steps
- Pages - drafts, publishing and what "modified" means.
- MCP server - the patching path that also snapshots.