Rules

Blocking vs Warning

Understand how Blocking and Warning severity affect publish, update, and audit behavior.

Severity controls the outcome

When a ContentGuard rule fails, severity decides what happens next.

Blocking

ContentGuard · Blocking

A blocking finding prevents publication and prevents updates to already published or private content on the supported save paths until the issue is resolved.

Warning

ContentGuard · Warning

A warning surfaces the finding in the editor but does not block the save. Publication is allowed.

Blocking in practice

Use Blocking when non-compliant content must not go live.

Applies to publish and private update flows in V1
Drafts, autosaves, and revisions are not blocked
Editor chrome uses the label ContentGuard · Blocking plus the field finding

Editors can keep working on drafts even when Blocking rules would fail on publish.

Block editor: ContentGuard · Blocking when a required Content field is empty.

Warning in practice

Use Warning when the team should notice an issue without stopping publication.

The editor shows ContentGuard · Warning and the related field message
Saving and publishing remain possible
Warnings are not merely cosmetic—they appear on validation surfaces and in audits as content that needs review

Classic Editor: ContentGuard · Warning surfaces the finding without blocking publication.

Workflow difference

Severity	Intended workflow
Blocking	Must resolve before the relevant publish/update can proceed
Warning	Should review, but publication is allowed

Audit evaluates active rules against published and private content. Blocking failures surface as content that needs attention; warnings surface as content that needs review. Audit reports findings—it does not modify content.