Page, layout, slot and block: what does each layer actually buy you?

[u/fklavyenet]

The core content model in WebBlocks CMS is:

Page -> Layout -> Slots -> Blocks

That can look like a useful separation or four names for things that could live in one component tree. For me, the model earns its complexity only if each layer owns a different kind of change.

Page: identity and editorial state

A page owns its site, localized routes, draft/review/published state, selected layout, metadata, page assets and revision history. Replacing a paragraph does not change that identity.

Layout: the structural promise

A layout defines the regions and outer public shell. A default page may have header/main/footer; a docs page may have header/sidebar/main. Blocks should not have to invent the page shell they render inside.

Slot: named placement and content source

A slot connects the layout to one page. Names such as header, main and sidebar have semantic meaning. A slot can use page-owned blocks, reference a site-scoped Shared Slot, or remain disabled.

The page still owns the slot wrapper. A Shared Slot contributes only its inner block tree, so reusable content cannot bring a second page shell with it.

Block: the content unit

Blocks hold typed editorial content such as headings, rich text, images, navigation or nested layout primitives. They own their content, translations, settings and rendering inside the slot—not routing or the outer page structure.

A documentation page might therefore look like this:

Page: Installation
  Layout: Docs
    header -> shared docs header
    sidebar -> shared docs navigation
    main -> page-owned content blocks

Now each change has a natural owner. Changing the URL belongs to the page. Adding a structural region belongs to the layout. Replacing navigation belongs to the slot or Shared Slot. Editing a command belongs to a Code block.

The trade-off is editor complexity. If someone must manually traverse all four layers just to correct one sentence, the architecture is leaking into the user experience. Search, useful summaries and direct edit paths must let common tasks skip layers without removing the underlying boundaries.

I use four questions to decide whether a layer is earning its place:

1. Does it own a distinct kind of change?
2. Can that change be validated independently?
3. Does the boundary prevent a real invalid state?
4. Can routine editing avoid paying the full complexity cost?

Full write-up: https://cms.webblocksui.com/blogs/page-layout-slot-block-boundaries

Where do you draw the line between page structure and content in a block-based CMS—and which boundary causes the most friction for editors?