> ## 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 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](/editing/review-and-undo) 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](/integration/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](/editing/review-and-undo), 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](/editing/review-and-undo#published-snapshots-going-back-after-it-went-live).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.