A global block is a section built once and used on many pages: a site header, a footer, a CTA band, a disclaimer. Edit it in one place and every page that uses it changes.

The mechanism is worth knowing, because it explains every rule that follows. A global block is two objects, not one:

1. The global block itself - a page, of a page type that has no slug. It has a block tree, a draft version, a published version, and its own revisions, exactly like any other page. It is just not routable: no visitor can navigate to it.
2. A reference on each consuming page - a placeholder block that points at the global block by id. It holds no content of its own.

Once you see it as "a page you can't visit, plus pointers to it", the rest of this page is consequences.

Some of the product's internals and older material call these partials. Same feature - the user-facing name is global block.

How one comes into existence

Two routes, both in the builder:

• From a selection. Pick a section, choose to make it global, and give it a name. The section is moved out of the page into a new global block, and a reference takes its exact place in the tree. The builder then opens the new global block for editing. Nothing is duplicated; the original page now points at what used to be inline.
• From scratch. Create a global block from the pages manager and build it empty. Because it has no slug, the creation form asks for a name and nothing else.

Either way you can attach a description and tags. Neither is decoration: the description is what the AI reads to decide whether a global block is relevant, and tags are how the add-block panel filters the list once a site has thirty of them.

What happens at render time

The reference is not a wrapper that fetches something at runtime. When a page is loaded, the server inlines the global block's tree in place of the reference before rendering begins:

Stored page                  What renders
├── Reference → header  ──►  ├── Section (from the global block)
├── Section                  │   └── Nav
└── Reference → footer       ├── Section
                             └── Section (from the global block)

Three details follow from inlining:

• Fresh ids. The inlined blocks get new ids, so the same global block can appear twice on a page without collisions.
• Position is inherited. The inlined tree takes the reference's place in the parent, so surrounding layout behaves as if the content had always been there.
• Visibility propagates. A condition set on the reference is applied to the inlined blocks. Hide the reference and the whole global block is absent from the HTML. See Conditional Visibility.

Draft renders inline the global block's draft; live renders inline its published version. That single sentence explains most global-block confusion in practice.

They are static by design

One global block renders identically on every page that uses it. There are no per-page variants, no overrides, and no props to pass in from the consuming page.

This is a deliberate constraint, not a missing feature: a variant would be a different tree, and a different tree is a different global block. If two pages need different wording of the same band, you have two global blocks - or the content belongs inline on each page.

A useful test before creating one: is this used on two or more pages, with identical content? If not, keep it inline. A single-use global block is indirection with no payoff, and it makes the page harder to edit for the next person.

Publishing is separate, and this is the classic trap

A global block has its own draft and published versions, so publishing a page does not publish the global blocks it uses, and vice versa.

• Publishing a global block invalidates the cache of every published page that uses it, so the change rolls out without touching those pages.
• A global block that has never been published renders as nothing on live pages - while looking perfectly fine in the builder and in preview, which read draft content. The publish flow warns about unpublished global blocks for exactly this reason. Take the warning seriously.
• Taking a global block offline likewise affects every page using it.

So the failure looks like this: you build a beautiful footer, publish the page, and the live site has no footer. The page was published; the footer was not.

To make invalidation possible, each page records which global blocks it uses, transitively. That record is also what answers "where is this used?" before you change something.

Nesting is capped at two levels

A page can use a global block, and that global block can use one more. The second level must not contain further global blocks. Two levels, hard limit.

Cycles are prevented in two places. In the builder, a global block that would create a loop or exceed the depth limit is shown but disabled in the add panel, with the reason, so the constraint is visible rather than mysterious. At render time the same rules are enforced again defensively - a reference that would loop is simply left unexpanded, which matters for pages authored outside the builder where no add-time check ever ran.

What a global block is not

• Not a template. It has no parameters and produces no variants.
• Not a component you can code against. It is editor-authored content stored as page JSON. If you want something configurable per placement, write a block with props.
• Not routable. No slug, no URL, not in the sitemap.
• Not per-language. A global block does not get its own language pages, though its translatable text still translates. See Multilingual.

Failure modes worth knowing

Symptom	Usual cause
Edited the global block, live pages unchanged	The global block itself was never published
Renders in the builder, missing on the live site	Same cause: draft exists, published version does not
A section disappeared from many pages at once	A global block was unpublished, taken offline, or deleted
The outline flags a reference as missing	The global block it points at was deleted. The reference stays in the page JSON on purpose, so removing it is deliberate
Content vanished only in preview	The global block is in the trash; soft-deleted global blocks are excluded from draft renders
Cannot add one from the panel	It would create a cycle or exceed two levels of nesting. The disabled entry states which
Two pages need slightly different versions	Working as designed. Make a second global block, or keep it inline

Related

• Blocks - the unit a global block is made of.
• Page Types - why a global block is modelled as a page.
• Pages vs CMS - choosing between a global block, a page, and a collection.
• Preview & Publish - the publish warnings, including unpublished global blocks.
• Rendering Model - draft versus published reads.
• Caching & Revalidation - what invalidates when a global block is published.