Revisions, Versions and Reverting

The small gray chip beside the page title — v1, v2, v3 — is the page’s revision number, and everything else on this page follows from one rule: a published revision is a permanent record of what readers saw, so it is never edited in place. To change a live page you start a new revision, which is what the Revise button does and why the number goes up. Internal pages run the same cycle with Lock in place of Publish — see Locking and Revising Internal Pages.

The cycle

Four steps, and you will run them for the rest of the page’s life:

1. Draft. You write. The page is v1, the status chip reads DRAFT, and nothing is public.
2. Publish. The revision goes live and locks. The chip gains a padlock, the toolbar disappears, and hovering the chip reads Page is locked (read-only).
3. Revise. The version number goes up by one, the status becomes IN REVISION, and the editor unlocks. The version already on your site keeps serving the whole time.
4. Republish. The new revision goes live and locks in turn, and the one it replaced becomes a permanent read-only record.

stateDiagram-v2
    direction LR
    state "Draft — v1" as Draft
    state "In Revision — v2 and up" as InRevision
    state "Scheduled" as Scheduled
    state "Published" as Published

    [*] --> Draft
    Draft --> Scheduled: Publish
    Scheduled --> Draft: Unschedule
    Scheduled --> Published: the slot arrives
    Published --> InRevision: Revise, version + 1
    InRevision --> Scheduled: Publish
    Scheduled --> InRevision: Unschedule
    InRevision --> Published: Revert, version - 1

    note right of Published
      Revising leaves the version it
      supersedes behind as Replaced:
      a permanent, read-only record.
    end note

Draft and In Revision are the two editable states. Scheduled, Published and Replaced are all read-only — a scheduled page is locked because it is already committed, which is a different lock from the one you hit for a few seconds while a publish is actually running.

Why published pages lock

Revising

Revise sits where Publish sits on a page that has never gone live: the right-hand end of the document header’s first row. Clicking it opens a confirmation that says exactly what is about to happen:

This will unlock the page for editing. You will need to republish after making your changes.

Confirm and three things happen at once: the revision you were looking at is marked as replaced, a new revision is created one version higher carrying all of the old one’s settings, and the editor unlocks.

One detail worth knowing before it surprises you on the calendar: a new revision is created with a target date one week out, deliberately, so work in progress lands on the schedule as upcoming rather than sitting in the past next to the date the old version went live.

Two people revising at once

If two people click Revise on the same published page within moments of each other, only one new revision is created. The second person’s request carries the version number they were looking at, Leed notices that version has already been superseded, and instead of making a duplicate it shows Another user already revised this page. Reloading. and drops them into the revision the first person started.

You never end up with two competing revisions of one page, and there is nothing to merge afterwards — the second person simply arrives in the same document as the first, alongside everyone else already editing it.

Reverting

Revert Changes is an amber button at the very bottom of the Page settings panel. It appears only when both conditions hold: the page is past v1, and it is not currently published or locked. On a published or locked page there is nothing to revert; on v1 there is nothing to revert to.

The dialog states the consequence plainly:

This will discard all changes made in this revision and restore the previously published version. This action cannot be undone.

That is literal. Reverting deletes the working revision — the version number goes back down, the previously published version is restored to PUBLISHED, and the page is locked again exactly as it was before you revised it.

Reverting does not touch your live site, because your live site was already serving the older version — the revision you just discarded had never been deployed.

Internal pages lock instead of publishing

A page of an internal page type runs the same cycle with one substitution: it is never published, so Lock revision takes the place of Publish. Locking freezes the current revision exactly as a publish would — the status becomes LOCKED, the toolbar disappears, the version chip gains its padlock — but nothing is committed, deployed or scheduled, and no reader ever sees it. Revise then opens the next version as IN REVISION, and Revert Changes discards it and restores the previous revision as LOCKED (its confirmation still speaks of the previously published version; on an internal page that means the last locked one). Lock, Revise and Revert all need publish permission, as they do on any other page.

stateDiagram-v2
    direction LR
    state "Draft — v1" as Draft
    state "In Revision — v2 and up" as InRevision
    state "Locked" as Locked

    [*] --> Draft
    Draft --> Locked: Lock revision
    Locked --> InRevision: Revise, version + 1
    InRevision --> Locked: Lock revision
    InRevision --> Locked: Revert, version - 1

There is no Publish or schedule control on an internal page, and every route that would publish or schedule one refuses with internal_page_not_publishable. An AI client reopens a locked page the same way the editor does: update_page_metadata with status: "IN_REVISION" performs Revise, and the lock_page MCP tool locks it again. Locking and Revising Internal Pages walks through the cycle, and Internal Content covers internal page types end to end.

What the statuses mean

Seven statuses exist. You will use four of them, you will see a fifth in the page tree’s filter facets, a sixth belongs to internal pages alone, and the seventh is history.

REPLACED never appears as a chip because the page always shows you its latest revision, and the latest revision is never the replaced one. It is worth knowing the word exists: it is what “the old version is kept” means concretely.

What is not here

Say this out loud once so you do not go looking:

• There is no revision browser. You cannot open v2 of a page that is now on v5.
• There is no diff between two versions. Nothing in the CMS shows you what changed between one publish and the next.
• There is no restore-to-an-arbitrary-version. Revert restores the last published version (on an internal page, the last locked one), one step back, and that is the whole of it.

If you need a review trail before a change goes live rather than after, the tool for that is Suggesting mode, which records proposed edits as accept-or-reject cards inside the current revision. The published history is a record, not a workspace.

Republishing is an ordinary publish in every respect — it runs the same pipeline and, because every deployment rebuilds the entire site, it costs the same couple of minutes whether you changed one word or rewrote the page. That is also why the live version can keep serving untouched while you revise for a week: your site only changes when a build runs.