Publishing your changes

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 carries a count of how many unpublished changes are waiting — “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 version history says who changed what.

​

The review dialog

Pressing Publish does not publish. It opens a review of exactly what would change, page by page, field by field:

• Each changed page, with its slug, and a checkbox.
• Inside it, 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 in the list at all. That is not a summary — it is the actual diff being sent.

​

Publishing only some of it

Every page in the dialog has its own checkbox, and so does the site configuration — the site name, logo and navigation, which change independently of any page. Uncheck what is not ready. The pages you leave out 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.

​

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. Then, depending on your setup, the site rebuilds. The publish entry in version history 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 version history says Live and reports the page count — “3 of 9 pages changed”.
2. Open live site in the header, 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 version history entry says Deploying… until it is done. 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

Site settings holds a Version history of published snapshots, each with its date, page count and heading, and a Restore button. That puts the live site back to a previous published state — which is the tool for “we published the wrong copy an hour ago”, rather than the in-editor undo.