> ## Documentation Index
> Fetch the complete documentation index at: https://docs.avocadostudio.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Publishing your changes

> The review dialog, publishing only some of your pages, and how to confirm the live site actually changed.

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](/editing/review-and-undo) 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](/integration/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.