How it works

How publish checks work

What has to be true before content can go live — the readiness checks your agency chooses, the body checks that are always on, and which of them the database enforces.

Before an item goes live it passes up to four layers of checks. Two live in the editor and exist to help you get the item right. The other two live in the database and decide whether the publish happens at all. By the end of this page you'll know which is which, why a greyed-out Publish button and a refused publish mean different things, and why publishing from the bulk actions behaves differently from publishing in the editor.

Two layers in the editor guide you; two in the database decide.

Layer 1: your agency's readiness checks

Your agency keeps one short list of readiness checks, chosen under Settings → Publish requirements (opens the admin console) by people who hold Manage settings.

Check	Applies to	Out of the box
Summary is filled in	Every content type	Required
Cover image is set	Articles and guides, the only editors with a cover image	Optional
Belongs to at least one guide	Everything except guides, because a top-level guide sits in none	Required
Has at least one tag	Every content type	Optional

Every check that applies is always shown in the editor's Publish card, so authors can see what "ready" means. Only the required ones disable Publish — and Schedule, in the article and guide editors. The rest carry "(optional)" as a reminder. The list is read when an editor opens, so a change reaches an editor that is already open the next time it is opened.

The checklist appears only while an item is not yet published, and it never blocks Save draft, Save changes or Submit for review. An author can hand over an unfinished item; whoever publishes it has to complete it first.

Layer 2: the body checks you can't switch off

Beneath your agency's list, the editor checks the content itself. For articles and guides it reads the body as you write and lists what it finds under the editor:

Blocks publishing: an empty body, a body with no text, or an internal link to content that no longer exists. These make an item wrong — an operator would open a blank page or a dead link.
Warns only: an image without alt text, heading levels that skip a level, and links to content that is not published yet. These make an item worse, not wrong, so they are shown but don't hold the button.

The line is deliberate. Missing alt text used to block, which made a freshly imported document full of images unpublishable until every picture had been described by hand. A guide's intro is its body, so a guide needs some intro text before it can be published from the editor.

Checklists, quizzes, video and audio have no rich-text body, so their editors check completeness instead: every checklist step has text; a quiz has at least one question, each with a prompt, at least two answer options that all have text, and a correct answer marked; video and audio have a file attached or a link. Until then, Publish stays disabled.

Layers 3 and 4: what the database decides

Everything above runs in your browser, and all it decides is whether the button is enabled. The publish itself is a change to the item's status, and a trigger in the database judges that change whichever screen it came from:

Permission. Publishing needs Publish. The database refuses the change from anyone without it.
Two-person sign-off. If the item requires approvals — through its own Required box or an approval policy that matches it — the database counts approvals on the current version from people other than the author and the publisher, and refuses the publish until there are enough. See How two-person sign-off works.

When either refuses, the item stays as it was and the database's reason is shown on screen.

Where each layer runs

Publish in the editor meets all four layers.
Publish in the bulk actions on All content (opens the admin console) skips the editor entirely. Only the database's checks run, item by item; refusals are counted and reported rather than stopping the batch. Nothing checks that a bulk-published article has a body or a summary.
Schedule in the editor runs the editor's checks at the moment you select it. When the time arrives, the publishing job checks sign-off on the item as it stands then, but does not re-run the editor's checks. A schedule set from Scheduled, the calendar or the bulk actions never meets the editor's checks at all. See How scheduled publishing works.

What this means in practice

Greyed out, or refused? A disabled Publish button is the editor talking: read the checklist in the Publish card and the list under the body. A message after you select Publish is the database: a missing permission or missing approvals. Ask for whichever is missing.
Requirements are house style, not a control. They keep everyday publishing tidy, but someone who holds Publish can still publish from the bulk actions without meeting them. If an item must not go live on one person's word, use an approval policy — the database enforces those.
The checks judge the item when you press the button. An item scheduled while it passed goes live at its time as it stands then, even if someone has since emptied its summary.
Changing the list changes nothing that is already live. Published content is not re-checked; the new requirements apply to the next item someone publishes from the editor.