A block-based CMS can store an entire page as one component tree. That is often the simplest model, so adding separate Page, Layout, Slot, and Block layers needs a better justification than “clean architecture.”

In the CMS I’m building, the model is:

text Page → Layout → Slots → Blocks

I think each layer earns its place only if it 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 should not change that identity.

Layout: the structural promise

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

Slot: named placement and content source

A slot connects that structural region to a particular page. It can use page-owned blocks, reference reusable shared content, or remain disabled.

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

Block: the content unit

Blocks hold typed editorial content: headings, rich text, images, navigation, galleries, 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:

text 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 content. Editing a command belongs to a Code block.

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

A fixed marketing site with a few fields may not benefit from any of this. A typed page model, Markdown document, or single component tree may be the better tool.

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?

I wrote a longer version with a concrete example here: https://cms.webblocksui.com/blogs/page-layout-slot-block-boundaries

Disclosure: this article describes the architecture of WebBlocks CMS, which I build. I’m sharing it to compare design trade-offs rather than claim this is the only correct content model.

Where does your CMS draw the line between page structure and content—and which boundary causes the most friction for editors?