Skip to main content
Publishing is always a separate, explicit step. Nothing you do in the editor reaches visitors until you press Publish and confirm what goes.

Before you publish

The Publish button in the top bar appears only when there is something to publish, and it carries the count of changes waiting. Hover it and it says “7 unpublished change(s) since the last deploy.” If that number is higher than you expected, someone else has been working on this site too. The History drawer says who changed what.

The review dialog

Pressing Publish does not publish. It opens a dialog titled Publish that reviews exactly what would change:
  • A summary line at the top — “2 pages modified · 5 fields changed”.
  • Each changed page, with its slug, a checkbox, and a count of its changes. The first page starts open; click any other to open it.
  • Inside a page, its Page metadata (title, description, social image) and each changed block, and inside that, each changed field — shown as before → after.
  • Images are shown as thumbnails, old beside new, so you can see a swap rather than compare two URLs.
  • Long text is truncated with a way to expand it.
  • Pages you did not touch are not listed, only counted at the bottom (“6 unchanged pages”). That is not a summary — it is the actual diff being sent.
Two more kinds of entry can appear:
  • Site header — the site name, logo and navigation change independently of any page, so they get their own entry and checkbox.
  • Site-wide content — a block your site shares across pages, such as a footer, is listed once with the pages it affects (“affects 5 pages”), not once per page. If different pages hold different versions of it, the dialog warns you: edit it once, on any page, to bring every page in line before you publish.
Recent AI activity, folded at the bottom, lists the last few changes the chat made, for context.

Publishing only some of it

Every page in the dialog has its own checkbox, and so does the site header. Everything starts ticked; Select all and Select none do what they say. Uncheck what is not ready. The dialog reminds you that unselected pages stay exactly as they are on the live site. They stay in your draft, exactly as they are, and go out whenever you publish next. This is how you ship the pricing fix today and hold the rewritten about page until legal has read it. A site-wide block goes out with any ticked page that carries it. The button names what it will do — Publish 5 changes — and counts only what is ticked.

What actually happens

Your selection goes to the site’s publishing target, whatever your team configured — a CMS, a file in the repository, a deploy hook. The change is sent as a field-level diff, so a page nobody edited writes nothing at all, and a target that records history records one changed sentence rather than the whole page. The chat then reports the result, page by page (“Updated pricing”). If the site could not write part of a change, that part is listed as “Not published: …” — the rest went out, that piece did not. Pass those lines to whoever maintains the integration. Then, depending on your setup, the site rebuilds. The publish entry in the History drawer tracks that: Deploying…, then Live, or Failed, with a View deploy link where your host provides one.

Confirming it worked

Three checks, in increasing order of paranoia:
  1. The publish entry in the History drawer says Live and reports the page count — “3 of 9 pages changed”.
  2. Open live site — the external-link icon that appears beside Publish after a publish — opens the site in a normal tab. Remember that a normal tab shows the published page, which is the whole point: if your change is there, it published.
  3. A publish that reports No content changes · 9 pages live did exactly what it says. Nothing was different, so nothing was written. That is a successful publish, not a failed one.

When something goes wrong

Publish is refused because it would empty the site. A publish that would remove every page is blocked. Removing one page of several is an ordinary edit and goes through; removing the last one is refused, because what usually produces an empty page list is a client that failed to load its own state, not a person deciding to delete a website. Publish reports success but the site looks the same. Check you are looking at a normal browser tab rather than the editor’s preview, and give any rebuild time to finish — the History drawer entry says Deploying… until it is done. The dialog says Couldn’t load the diff. Nothing has been published, and nothing will be until the review loads. Press Try again; if it keeps failing, the site or its orchestrator is unreachable. Publish fails with an error about a token or a 401. That is a configuration problem on the site, not something you did. It goes to whoever set the site up, along with publishing.

Going back after publishing

There is no “unpublish”. To put the live site back, put your draft back and publish again:
  • To undo one page’s changes, use Restore this version in the History drawer, then publish that page.
  • On sites that publish by committing to a Git repository, the Sites page keeps a Version history of published snapshots. Restore loads a whole earlier snapshot into your draft; publishing it puts it live. See published snapshots.