The problem with giving clients a full CMS: they break things

The accidental redesign problem

A client opens their WordPress dashboard to update a page. They want to change a paragraph. While they're in there, they notice a button to change the font size. They make it larger. Then they notice a colour picker. The heading is now teal. They add a new section using a page builder block they haven't used before. An image gets uploaded from a phone - it's 6,000 pixels wide and 8MB. The layout breaks on mobile. None of this was intentional.

This isn't a hypothetical. Variations of it happen on almost every WordPress site with more than one editor. The platform's design philosophy is that more flexibility is better. The assumption is that clients have both the skill and the restraint to use that flexibility within the bounds of the original design. That assumption is usually wrong, not because clients are careless, but because the interface presents every option as equally valid.

When a heading size selector shows options from 10px to 100px, nothing in the interface signals which values are appropriate for the design. When a colour picker shows the full spectrum, there's no way to know which values are part of the brand palette. The CMS doesn't distinguish between "design decisions made by the person who built this site" and "settings you should probably leave alone."

How page builders make it worse

WordPress page builders - Elementor, Divi, WPBakery, and their competitors - extend the problem significantly. They give editors the ability to add, remove, and reorder page sections, change column layouts, and modify the visual structure of individual components.

The result is that the design of a page stops being a fixed thing and becomes a variable. Each time an editor opens a page, the layout is available for modification. Over time, pages drift from the original design. Different pages use different spacing, different font sizes, different colour combinations. The site begins to look like it was built by several different people with incompatible aesthetic preferences - because in effect, it was.

Page builders also generate unstable HTML. The code output of Elementor or Divi is heavily nested, JavaScript-dependent, and often changes between plugin versions. A site that looked fine after the last update might have layout issues after the next one, with no predictable trigger.

The headless CMS partial solution

Platforms like Contentful, Sanity, and Storyblok respond to these problems by separating content from presentation. The CMS stores raw content - text, images, relationships between content types - and a separate front-end layer decides how to display it.

This is a significant architectural improvement. Editors can no longer directly modify the layout, because the layout lives in code, not in the CMS. The design is stable regardless of what the editor does.

The limitation is that most headless platforms still allow rich text fields with formatting options, and those formatting options are frequently misused. A long-form text field with bold, italic, heading levels, and link insertion gives an editor many ways to produce output that looks wrong on the front end. Pasted content from Word brings its own formatting. Inline styles that work in one context break in another.

The other problem is complexity. Headless CMS platforms are designed primarily for developers. The editorial interface for non-technical users varies significantly in quality, and setting up a headless platform in a way that is genuinely usable for a non-developer team requires considerable configuration and training investment that most projects don't budget for.

What structured fields actually solve

The alternative is a CMS that doesn't give editors layout control in the first place - not because it's been locked down, but because the fields it exposes don't correspond to layout properties. Structured content means the CMS knows what each piece of content is, not just where it should appear on the page.

Instead of a text area where an editor types the hero section, there are separate fields: a headline field, a subheadline field, a body copy field, and a CTA button field. Each has specific constraints. The headline has a character limit. The CTA field has a link target and a button label, but no colour picker. The editor cannot accidentally make the hero section look different because the design decisions are embedded in the field structure, not accessible through the interface.

An image upload field can enforce dimensions, file size limits, and aspect ratio requirements. A team member field can have a name, a role, and a photo - but not a biography formatted as a three-column layout with a pull quote. The content type defines the structure; the editor fills in the values.

This is how Kernset works. Every content type is defined as a set of typed fields with explicit constraints. Editors see a clear, simple interface for the content they're responsible for. The design stays consistent across every update because it's controlled by code, not by the CMS interface. Upload and text fields can enforce sensible limits before content reaches the live site.

The practical argument for structured content

The business case for structured content doesn't depend on a philosophical commitment to separation of concerns. It's straightforwardly about support costs and design stability.

When a CMS gives editors full layout control, the ongoing cost of maintaining design consistency is high. Someone has to review content updates for layout issues. Someone has to rebuild pages that editors have modified in ways that broke the design. Someone has to respond to "the site looks broken" messages that turn out to be the result of a well-intentioned but poorly-executed content update.

Structured content eliminates most of these costs. Not because editors are prevented from doing anything, but because the CMS itself enforces the constraints that would otherwise require manual review. Editors have genuine freedom within the bounds of what they should actually control. Developers spend time building features, not fixing accidental redesigns.

The result is a site that looks the same in year three as it did in year one - not because no one has touched it, but because every update happened through a system that maintained the structure the design depends on.