Block-based content modeling: typed vs free-form schemas
Why block-based content models are popular in modern CMSes and how typed block schemas keep agency designs intact through years of client edits.
This is how we think about content modeling for small-to-mid-sized agencies.
TL;DR. Block-based content models replace one big HTML blob with typed units (hero, FAQ, pricing, gallery), each exposing only the fields the agency defined. Designs survive years of client edits because the structure lives in code, not the database. Versioning, localisation, and structured-data emission come almost for free. The cost is up-front schema work, which pays off across a portfolio of similar sites.
TL;DR (skim view)
- Free-form editors often lead to broken designs over time as clients paste raw HTML.
- Block-based editors enforce structure, ensuring designs survive years of client edits.
- The initial setup cost of defining block schemas pays off for agencies managing multiple similar sites.
The shift from free-form WYSIWYG editors to block-based content models is one of the most consequential moves modern CMSes have made. It is not a UI fashion. It changes what kinds of mistakes are possible and what kinds of designs survive years of client edits.
Free-form vs block-based
Free-form editors output unstructured HTML blobs that are prone to layout breaks, while block-based editors enforce typed data structures that separate content from presentation.
A free-form editor (think classic WordPress, classic CKEditor) gives the editor a single big text area with formatting tools. They can paste in HTML, drop images anywhere, set heading sizes, add inline styles. The output is one large blob of HTML in the database.
A block-based editor breaks content into discrete units. Each block has a type (hero, FAQ, gallery, contact info), a defined set of editable fields, and a known way to render. The editor sees a list of blocks, not a blob of HTML.
The difference matters at every layer.
What block models get right
Block models lock the design in code, making structured data emission automatic and ensuring content survives design overhauls.
Designs survive years of client edits. A free-form editor is a permission slip to break the design. Clients paste in colored text, mismatched headings, full-width images that should be half-width. Six months later the page looks nothing like the original design. A block model exposes only the fields the agency defined. The design holds.
Content is structured by definition. A FAQ block has a list of question and answer pairs. A pricing block has tiers with a name, price, feature list, CTA. The frontend can render that structure however the design demands - and re-render it later if the design changes - without rewriting the content.
SEO and AIO output is automatic. Structured content is what every SEO best practice (such as those outlined by Schema.org) has been asking for. A FAQ block can emit FAQPage JSON-LD without any client effort. A pricing block can emit Product schema. AI search prefers structured data and weights it heavily; block models hand it over on a plate.
Localization is straightforward. A block field marked localized gets a per-language version of just that field. The block structure is shared; the localized text varies. A free-form HTML body has to be translated as a whole, every time, with no tooling support for “this section did not change, do not re-translate.”
Versioning and rollback work cleanly. A block document is a structured object. Diffing two versions is meaningful: “block X had its title changed from A to B.” A free-form HTML diff is a tag-soup hunt for what actually changed.
What block models cost
Less expressive freedom for the editor. The trade is real. An editor used to “type some text, add an image where I want it” feels constrained when they can only edit defined fields. For technical content, a richer text block (markdown or limited rich text) often handles the gap.
Up-front design work. Defining the block library is real work. Each block needs a schema, a renderer, an admin form, and ideally a help text. For a one-off small site, this overhead is overkill. For a multi-site agency that uses the same block types across many client websites, the overhead amortises fast.
Block-type drift across clients. A small agency can resist this. A growing one struggles. If every client gets a slightly different “hero variant” or “feature grid variant,” the block library balloons. Most agencies that do block-based content well end up with a relatively small core library (15 to 30 blocks) plus a handful of per-client custom blocks for specific needs.
Designing a good block library
A few patterns hold up well. One block per content shape - a hero block is a hero block, not a generic “section.” Required fields are required at the schema level. Inline help text on every non-obvious field. Localization only where it matters - mark text fields localized, do not mark structural fields like alignment localized. Allow images at one aspect ratio per block. Provide a flexible content zone for one-off layouts where the agency wants the client to add a list of blocks.
Where Kernset sits
In our experience, Kernset is built around block-based content from the ground up. Block schemas live in TypeScript next to the agency’s other source. The editor renders against the schema. Clients edit the fields the agency exposed - and only those fields. Localization, versioning, and structured-data emission are first-class.
The block library that ships with Kernset has 30 plus standard blocks plus a custom-block factory for per-client one-offs. The flexible content zone pattern handles the cases where the client needs to add and reorder blocks within a region. We’ve seen that it is the right tool for SMB managed sites where the design must survive years of client edits.
Frequently asked questions
Do block-based editors mean the client cannot create new layouts?
Generally, yes. By design, block-based CMSes restrict editors to pre-defined layouts (blocks) that the agency has built. While this removes layout flexibility for the client, it prevents them from breaking the site’s design system.
See it against your block library
If you have been weighing whether typed block schemas are worth the up-front design work, the fastest way to decide is to look at Kernset’s block library against two of your trickiest client websites. Get early access - a real person reads every message.