Publishing makes the files in your editor the live site. Every publish is kept as a version, with the source it came from, so you can see what each one changed, look at its pages as visitors got them, and put an earlier one back.

Nothing you type reaches visitors until you publish. The live site keeps serving the version that's live while you edit.

Publish#

Click Publish at the top right of the editor, or press ⌘/Ctrl+Enter. The studio saves your files, then shows the publish plan before anything goes live:

Pages going live: every route the new version has.
Experiments: each experiment in your source or on the live site, with a badge for what publishing does to it.

Badge	What happens
New	The experiment starts running, split by the weights in its source.
Unchanged	Its variants and goal are the same. It keeps the status and weights set in the studio, and its results carry on.
Restarts	Its variants or goal changed, or it's back after being removed. It starts a new revision: visitors are assigned again, and counts start fresh. The plan says what changed.
Archived	It's no longer in your source, so visitors stop seeing it.

See what changed, at the top of the plan, opens History on your unpublished changes, file by file. Click Publish in the plan to confirm. A toast shows the new version's short hash, such as "Published · 3f9a2c1d", with Open site. Visitors get the new version on their next page view.

What stops a publish#

Publish is unavailable while the site has errors, and its tooltip says how many to fix, such as "Fix 2 errors to publish". A publish also stops, leaving the live site as it was, when:

a fetchJson() request fails (MK6002), names a secret that isn't set (MK6003), or would send a secret to an address it may not go to (MK6004)
a file in public/ that the publish uses is deleted while it runs; publish again

Warnings#

Warnings never stop a publish. They stay in the Problems panel, and History shows how many each version had.

One warning comes only from publishing, because only publishing renders every variant of every page: a variant that renders exactly like control everywhere, so it can't win (MK4018). Publishing shows it in a toast, and the experiment's card in the Experiments tab and its results in Analytics carry a note until a publish makes the variant differ.

Unpublished changes#

An amber dot on Publish means your editor differs from the live site: its pages, components, files in public/, or site settings. The comparison is by content, so undoing an edit, or restoring the live version into your editor, clears it. On the sites page, each site shows Live, Unpublished changes, or Not published.

Some changes apply to the live site without a publish, so they never count as unpublished: an experiment's status and weights, and the Data view's refresh schedule, hook URL, and secrets.

History#

Open History from the History button in the top bar, or from See what changed in the publish plan. It fills the screen, with versions on the left and what the selected one changed on the right.

Versions#

The list has every version, newest first. Each entry shows:

what it was: Published, Restored with the hash of the version it brought back, or Fresh data for a data refresh
how long ago, with the full time on hover
its short hash, and how many files and lines it changed
a green Live badge, on the live version

When your editor differs from the live site, Unpublished changes sits at the top with an amber dot. Arrow keys move through the list, and Load older versions fetches more.

Changes#

Select a version to see what it changed, file by file. Source files show as diffs, Unified or Split, with long unchanged stretches folded until you click them. Files in public/ show their size, and images show before and after. Changed site settings, and the experiments the version started, restarted, or archived, are listed too.

Compare picks what the version is compared with. Each choice matches an action:

Compare	Shows	Matches
What it changed	Its changes from the version before it	—
Compared with live	What making it live would change on the live site	Make live
Compared with your draft	What restoring it would change in your editor	Restore to editor

Pages#

Pages, next to Changes, shows the version's pages as visitors got them, with that version's own stylesheet, fonts, images, and files, even ones you've replaced since. Pick a page from the Page menu, and a variant for each experiment on it. Links to the version's other pages open them in place.

Scripts don't run there. Interactive parts show as the server sent them, and embedded players, such as a video, stay blank.

Make live#

Select an earlier version and click Make live to put it back on the live site. The confirmation lists what happens to experiments: one the version has that was removed since, for example, restarts.

The version is copied to the top of the history as a new version, Restored with its hash, so the version it replaced stays in the list and nothing is lost. Visitors get it on their next page view. Your editor doesn't change, so it may now show unpublished changes.

Restore to editor#

Restore to editor makes your pages, components, files in public/, and site settings what they were in that version. The live site doesn't change until you publish. If you have unpublished changes, the confirmation warns that they'll be replaced; publish them first to keep them in the history.

On the Unpublished changes entry, Publish… opens the publish plan, and Discard changes puts the live version back into your editor.

What History keeps#

History keeps your newest 100 versions and your newest 20 data refreshes, counted separately, so a refresh schedule can't push your publishes out. Older ones are deleted as new ones arrive. The live version always stays, and so does any version a kept one was restored from. Deleting old versions never touches analytics.

Data refreshes#

When your pages fetch data with fetchJson(), publishing fetches it. To keep it fresh without publishing your editor's changes, open Data in the editor's sidebar. It republishes the live version with freshly fetched data:

on a schedule: Every 15 minutes, Every hour, Every 6 hours, or Every day
once, with Refresh now
when a CMS sends a POST to the site's CMS hook URL

A refresh never publishes your editor. When the data hasn't changed, nothing is recorded. When it has, the refresh is a new version labeled Fresh data, with what asked for it. Scheduled refreshes run while the studio is running. See Data from APIs.

sitemap.xml and robots.txt#

Every publish writes a sitemap.xml and a robots.txt, served at the root of the site's address. Both follow Site settings, in the editor's sidebar:

Site URL is where visitors reach the site. The sitemap lists every page by its full URL there, except pages marked noindex. Left empty, it's the studio's own address for the site.
Let search engines index this site, when on, lets every crawler in, and robots.txt points to the sitemap. When off, robots.txt turns every crawler away, and every page gets noindex.

Settings save as you change them: a switch at once, a field when you press Enter or leave it. They reach the live site on the next publish, and count as unpublished changes until then. See Pages and routes for a page's own title, description, and noindex.

Publishing and history