What makes a CMS website editors love and developers trust

A CMS website is only a success if two groups of people can use it without frustration: the editors who update it daily, and the developers who maintain it over time. Most projects get one right and fumble the other. This post is about what the good ones have in common — and what red flags to watch for before you sign off on a build.

The editor experience is a product decision, not an afterthought

The most common complaint I hear from clients six months after launch: "We have to ask the developer to change things we thought we could change ourselves." That is almost always a content model problem, not a permissions problem.

A well-built CMS website gives editors a workspace that maps to how they think about content — not how the database is structured. That means page sections with obvious labels, fields with sensible defaults, character count hints next to meta description inputs, and image fields that show the crop as it will appear on the live page, not a raw file upload box.

It also means editors are never blocked by a deploy. On a traditional setup, even a typo fix requires either a developer or a rebuild pipeline. On a headless setup built correctly, an editor saves, sees the change reflected in preview within seconds, and publishes — no ticket, no Slack message, no waiting.

If a CMS website requires a developer to push a button every time content changes, that is a cost you will keep paying forever, silently, in time and goodwill.

Preview that actually works

Preview is the feature most agencies promise and most teams deliver badly. "Real-time preview" should mean: the editor sees their unpublished draft exactly as it will appear to a visitor, on the real frontend, before they hit publish.

What it often means in practice: a separate staging URL with a two-minute cache, a preview that only works for one document type, or a preview button that opens the live site and shows the already-published version.

A properly implemented preview on a Next.js + Sanity stack uses draft-mode cookies to serve unpublished content through the same rendering path as production — same layout, same components, same image transforms. Editors click a "Preview" button inside the CMS, the page opens in an authenticated state, and what they see is exactly what will go live. No guessing.

Before you accept a handover, ask for a demo. Open a draft document, change a heading, and check whether the preview updates without refreshing. If it does not, the preview is decorative.

Sane content models protect everyone

Content models are the schema decisions that determine what editors can and cannot do. Badly designed content models create two kinds of pain.

The first is editor pain: too many fields, unclear labels, required fields that block publishing for no reason, image fields with no guidance on dimensions. Editors stop trusting the CMS and work around it — copy-pasting into fields they were not meant to use, uploading images at the wrong aspect ratio.

The second is developer pain: a content model that was designed for the first use case and then stretched to cover twenty others. References that point in circles. Fields that mean different things depending on which page type they appear on. Schemas that were never cleaned up, so every query has to account for five possible shapes of the same data.

A good content model is opinionated. It says "this is a blog post, this is a landing page, these are the sections a landing page can contain." It uses references rather than duplicating content. It validates fields before publish, not after. It has been designed with the actual editorial workflow in mind — who creates what, who approves it, how often it changes.

Ask to see the schema structure before a project ends. If the developer cannot explain why each document type exists and what problem it solves, that is a warning sign.

Performance does not have to degrade after handover

A common pattern: the site scores 90+ on Core Web Vitals at launch, then creeps down to 60 eighteen months later. Not because anything in the code changed — because editors started uploading uncompressed images, embedding third-party iframes in body copy, and adding rich text that the frontend was never designed to handle gracefully.

A well-built CMS website defends against this at the content layer. Images should be run through a CDN that handles format conversion automatically — editors upload a JPEG, visitors get a WebP or AVIF served at the right size for their viewport. The CMS should enforce maximum image dimensions at upload, not just suggest them. Rich text renderers should sanitise unknown embed codes rather than injecting them raw.

Largest Contentful Paint and Cumulative Layout Shift are the two metrics most vulnerable to editorial decisions. LCP is hurt by hero images that are not pre-loaded or served at the right size. CLS is hurt by images without declared dimensions. Both of these should be handled by the implementation, not by asking editors to follow a style guide they will inevitably forget.

When you review a handover, ask what happens when an editor uploads a 4MB PNG. If the answer is "it gets served as a 4MB PNG," the performance you paid for will erode.

What a good handover actually looks like

At the end of a CMS website project you should receive: a working staging environment with credentials, a short written guide covering the editorial workflows your team will actually use (not a feature dump of every CMS capability), a content model document that explains what each document type is for, and a record of what triggers revalidation and how long caches last.

You should also be able to answer yes to these questions without calling the developer:

• Can an editor publish a new blog post without touching any code?
• Can an editor update the homepage hero without a deploy?
• Does the preview show the actual draft before it goes live?
• Are images automatically optimised regardless of what the editor uploads?

If any of those is a no, the project is not done — it is just launched.