Editor-friendly CMS: why the admin interface decides whether your website succeeds

With every new website, two products are really created. One your visitors see: design, speed, copy. The other your team operates every day — the interface in which content is maintained. At launch, only the first is visible.

This is exactly where a quiet gap lies. The design is signed off, praised and put live. The admin interface, by contrast, is hardly checked by anyone before it lands in everyday use. It is invisible at purchase and yet decides, over years, how alive your website stays.

The effect does not show on day one. It shows in month six, when an address is out of date and no one knows where it can be changed. A website does not age in its design, but in its content — and the content hangs on the interface that maintains it.

An editor-friendly CMS is therefore not a technical nicety. It is the question of whether the team works independently after launch or asks for help with every change. Anyone planning a website should evaluate both products — not only the one the public sees.

Part of modern websites is built on a headless CMS. "Headless" means the system only manages the content and delivers it through an interface — it does not dictate how the page looks. For you that means more design freedom and speed, but also an admin interface that is a blank sheet to begin with.

This blank sheet is both opportunity and risk. The "backend" — the area where content is maintained, as opposed to the public site — can be set up freely. If this freedom is not used, you end up with a technically correct but confusing input mask.

Not every system invests equally in this editing layer. Some providers shine at the interface and treat the admin view as a side issue. Anyone who wants to work in an editor-friendly way therefore asks not only about features, but about what the daily maintenance actually looks like.

A confusing admin interface rarely breaks down loudly. It works gradually. When a field is hard to find, it gets skipped, filled in wrongly or worked around. Each of these small hurdles is a quiet loss of quality — invisible until content noticeably ages.

This is a pattern that recurs in practice, not a documented figure. Reliable statistics on editor behaviour barely exist. But the experience across many projects is clear: friction in daily maintenance leads to stagnant content.

A real example shows what this looks like. For the AIHK social insurance fund Aargau, a website was built on Strapi 5 — a modern content management system. In the global settings, more than twenty fields accumulated: cookie notice, error page text, contact details, all stacked on top of one another.

Strapi 5 ships with no built-in field groups or dividers. A schema — the blueprint that defines which fields exist — fills the mask but does not organise it. For a technical person this is readable. For someone without a technical background it is a wall of input fields.

Such global settings are especially tricky. They are rarely changed, but affect the whole website. Anyone who adjusts the cookie text once a year has no routine — and needs a view that explains itself, showing what belongs where.

The consequence is foreseeable: anyone wanting to change the cookie text scrolls past fields for the error page and is unsure whether they hit the right one. The admin interface does everything formally correct — and still stands in the person's way.

The answer was a custom input building block. In Strapi this is called a Custom Field — a self-built element for the admin interface that slots in like a normal field. Instead of storing data, this field only displays a labelled heading with a divider.

This building block, named section-title, divides the long list into clear sections: cookie, error page, contact. For you that means an editor sees at once where she is and changes precisely the right area. The stored content stays unchanged.

Building it took around half an hour. A wall of fields became an ordered view — without new data fields, without added weight in the system. This very small investment is what decides, in everyday use, whether a team works independently.

Such a building block might seem like a stopgap. The opposite is true. It is registered once in the system and is then available to all content types — one component, many places of use. That is clean practice, not patchwork.

Decisive for the long-term value: the building block creates no data field. It adds no load to the schema, the blueprint of the content, and survives system updates unharmed. Anyone who builds the backend this way builds for the long run, not for the sign-off.

This shifts the perspective. The admin interface is not the agency's internal problem, forgotten after launch. It is part of the architecture — planned, reusable and oriented towards the people who work with it every day.

AI comes into play around the admin interface — honestly assessed, without hype. Practically usable today is AI translation. Once the team saves the main language, the system aligns the remaining languages. For multilingual Swiss websites in German, French, Italian and English, that is a real gain.

This feature is generally available and included in a paid plan. On top of that comes a second helper: the media library can automatically suggest alt texts on upload, that is, image descriptions for search engines and accessibility. Both noticeably reduce daily friction.

It is a different story with generating content models via AI. This feature is still early and aimed at developers, not at the editorial team. The honest assessment: Strapi invests in the editing layer, AI translation is already usable today, the rest is in the making.

From all of this follows a clear stance. The admin interface is part of what you commission — not a detail that sorts itself out later. Anyone who plans a website also buys the tool with which their own team maintains the content over years.

This can be checked at the selection meeting. With a few pointed questions it becomes visible whether an agency builds the backend for people or only for the machine. The following points help to gauge that.