Why agency clients struggle with WordPress as an editor
A look at why SMB clients run into walls in the WordPress editor and what to look for in a CMS that fits a small-agency portfolio.
This is our perspective on why the standard WordPress editor often frustrates SMB clients.
TL;DR. SMB clients typically need to change a photo, edit opening hours, or push a blog post - a small editing surface. WordPress hands them Gutenberg plus whatever plugin matrix shipped, exposing dozens of unused block types, theme options, and update prompts. The mismatch is structural, not a training problem. A field-first editor that only shows the agency-defined fields turns Friday support emails into a finished change in two minutes.
TL;DR (skim view)
- WordPress’s block editor (Gutenberg) and plugin ecosystem overwhelm clients with unnecessary options.
- Giving clients too much layout freedom usually results in broken designs.
- A constrained, field-first editor reduces support requests and keeps the site looking professional.
Most small web agencies have done this dance. You hand a client a WordPress site, walk them through the editor for ninety minutes, and then spend the next quarter answering “I tried to change the photo and it disappeared” emails. The client is not wrong. The editor is not broken. They are just not a good fit for each other.
This post is a calm look at why that mismatch happens and what to look for in a CMS that fits a small-agency portfolio.
What clients actually need to do
The typical agency-built site for an SMB client has a small editing surface. Change a photo. Update opening hours during a holiday. Add an entry to a list of services. Push a new blog post. Edit the contact page when the address changes. That is it. A capable editor for that workload is a small UI with the relevant fields visible, sensible defaults, a Save button, and immediate visual feedback.
What WordPress actually shows them
The default WordPress experience exposes a complex, unconstrained workspace full of plugin settings, theme options, and layout blocks that most SMB clients will never need.
WordPress’ editor is a generic block editor (Gutenberg) plus whatever the theme and plugin matrix decided to expose. As widely noted by agency professionals and WordPress UX discussions, the result includes dozens of block types the client will never use, a media library with every image ever uploaded, plugin-injected meta-boxes scattered through the side panel, theme options buried two levels under “Appearance”, and update prompts for plugins, themes, the core, and PHP versions. A new editor is dropped into a workspace built for power users and asked to find the one button they need.
The four root causes
The editor is whatever the plugins shipped. WordPress is open-platform by design. Every plugin author makes their own decisions about admin UI. A client site running ten plugins has ten different design languages in the same admin.
The block editor exposes everything. Gutenberg lets clients add new blocks anywhere on the page. This sounds like flexibility but is, in practice, design erosion.
Image handling does not match what they expect. Clients upload portrait phone photos into landscape carousels. They drag a 4 MB JPEG into a thumbnail slot.
The save / publish / draft model leaks. Many clients accidentally publish drafts. Some publish updates that break a layout because they did not see the rendered result first.
What an editor should do instead
Field-first, not block-first. The client sees only the editable fields the agency exposed. Consistent UI across the whole admin. Constrained input by default - photo slots accept photos, heading slots accept text up to a length. Drafts and rollback are first-class. Live preview, side-by-side. No plugin updates the client has to think about.
The cost is real. Less expressive freedom for the editor. The client cannot move the hero block to the bottom. They cannot add a third column where the design has two. For most SMB clients, they do not need that flexibility - they need to update content. The constraint is the feature.
Where Kernset sits
In our experience, Kernset is built around the constrained-editor pattern. Block schemas live in TypeScript, in the agency’s repo. The editor renders against the schemas. Clients edit the fields the agency exposed. They cannot reorder sections or break the design. Drafts and one-click rollback are first-class. Live preview runs in a side panel.
It is not for clients who want full design freedom. We’ve found it is for clients whose actual job is updating content - and for the agency that wants to stop fielding “I broke the photo” calls every Friday.
Frequently asked questions
Can’t I just use user roles to simplify the WordPress admin?
You can restrict access, but role-scoping doesn’t solve the core issue: the Gutenberg editor itself still exposes layout controls (padding, margins, block reordering) that make it easy for an editor to accidentally break the page design.
See it against your portfolio
If you are tired of fielding “I broke the photo” emails every Friday, the fastest way to know whether a field-first editor would help your clients is to look at Kernset against your current WordPress site that gets the most support tickets. Get early access - a real person reads every message.