Rename a label, add a form, change your site description, edit a menu — and the CMS saves it instantly. Your site does not change. The saved edit waits in one place: the Pending changes card, on the right-hand side of the Deploy screen.
The card says as much itself: “Changes to your site’s settings and configuration — menus, forms, labels, page types, team members, and more — that haven’t been published yet. They won’t take effect on your site until you publish them.” Everything in that list is saved and safe. None of it is on your site.
What actually appears in this list
The list is narrower and more specific than “things I have changed”. Exactly seven kinds of thing can appear in it, and their granularity is not uniform — which is the detail people get wrong.
Labels, page types, team members, forms and menus appear one row per item. Rename two labels and you get two rows, and you can publish one without the other. General settings and autolinks appear as a single row covering everything of that kind — one row, all of it, published together.
| Item | One row per… | Label you will see | Where you changed it |
|---|---|---|---|
| Labels | each changed label | Label: <name> | Settings → Labels |
| Page types | each changed page type | Page type: <name> | Settings → Page Types |
| Team members | each changed person | User: <first last> | Settings → Team Members |
| Forms | each changed form | Form: <form name> | Design → Forms |
| General settings | one row for all of them | Settings (General) | Settings → General |
| Autolinks | one row for all of them | Autolinks | Settings → Automations |
| Menus | each changed menu | Menu: <name> | Design → Menus |
Two details in the label formats. A team member with no name falls back to their email address, and then to their internal id — so a row reading User: someone@example.com is normal, not an error. A form saved without a name shows as Form: (unnamed).
A deleted menu is filtered out, so a menu you removed and had never published does not sit in the list forever waiting to be published.
What never appears here
Several things are absent, for genuinely different reasons. Knowing which is which saves you looking for a row that is never going to exist.
| Thing | Why it is not here | Where it happens instead |
|---|---|---|
| Pages | They have their own editorial lifecycle and their own deployment | The page editor’s Publish, or a scheduled slot |
| Layout and template files | They commit and build the instant you save | Design → Layouts, straight to the preview site |
| Access overrides, editor-formatting toggles, required-field rules, page-type locks | They change the CMS, not the built site — there is nothing to publish | They take effect immediately |
| Logo and favicon | They are part of your general settings | Folded into the Settings (General) row |
| Search indexes | Committed as part of another publish rather than selected on their own | Settings → Search & Autolinks |
| Dynamic CTAs | They are served live to your site on every request and are never built into it | Settings → Dynamic CTAs, effective immediately |
Saving a layout file skips the list entirely and starts a preview build immediately — what saving does in the Layouts workspace explains why template work behaves differently from settings. And editor-formatting toggles and required fields change the CMS rather than the site, which is why they never queue here; what each page type lets you format covers those.
Publishing a selection
Tick the rows you want. A Select all (N) header above the list takes everything at once, and its checkbox shows an indeterminate state while only some rows are ticked.
The button beneath the card relabels itself as you go:
| Button reads | State |
|---|---|
| Select changes to publish | nothing ticked — the button is disabled |
| Publish 2 to live site | two rows ticked, ready |
| Publishing… | the request is in flight |
A Publish started toast confirms it, the ticks clear, and the rows disappear from the list once the commit lands. A new row appears in the Live site history column.
The resulting row is one deployment with several reason badges, which is how to read that row. A menu is a special case worth knowing about: publishing one commits the entire tree, including any folder moves you staged while editing it — what publishing a menu commits.
The amber dot, everywhere else in the CMS
You will meet this list’s contents long before you reach the Deploy screen. Anywhere in the CMS that shows a label, a page type, a form, a team member or a search index with unpublished edits, that row carries a small amber dot. Hover it and it says “Must be published to be active”.
It is one shared marker with one meaning, wherever it appears: this is saved, and it is not on your site. The must-publish model is the mental-model page for it.
At the top of a settings screen with unpublished changes, a matching amber strip appears reading Unpublished changes — Publish, which links straight here.
That strip is rendered only for people who can actually publish. A Content Writer editing a label sees the amber dot beside the row but no reminder strip — that is by design, not a partial page load.
When the list is empty
The card reads:
Nothing pending — everything you’ve edited is published.
That statement is precise, and narrower than it sounds. It means nothing of those seven kinds is waiting. It says nothing about:
- pages scheduled for a future slot — those are listed separately, under Scheduled for publishing on the Live site card;
- whether your preview site is ahead of live — file changes never appear here, so preview can be several template edits ahead with this list empty;
- whether the last deployment succeeded — check the history columns for that.
If you cannot tick anything
Publishing needs the deployment:publish privilege, which comes with the Content Publisher role and above. Without it, the card renders the list — every row, fully readable — with no checkboxes, no select-all header and no button.
Changing a team member’s role is itself a pending change, because author details are published to your site — see managing team members. The same is true of labels, page types, forms and your general site settings: edit freely, publish deliberately.