CMS Development Modelled Around How You Publish

What is the difference between headless and traditional CMS?

A traditional CMS manages content and renders the website. A headless CMS manages content and serves it through an API, leaving presentation entirely to whatever consumes it.

Headless is genuinely better when the same content feeds multiple channels — website, app, kiosk, partner feed — or when the front end needs a framework the CMS does not natively support. It gives content teams one place to publish and developers freedom on delivery.

It costs you the built-in things. Preview, page-level layout control and "what will this look like" all have to be built rather than assumed. For a team whose only channel is one website, that is usually a poor trade, and a well-modelled traditional CMS serves them better.

Why does our team fight the CMS?

Nearly always because the content model does not match how they think about content. If editors have to disassemble what they want to publish in order to fit the fields available, every publish is friction.

The other frequent cause is the opposite extreme: a single rich-text field where everything goes. That feels flexible on day one and produces inconsistent pages, unreusable content and a design that degrades with every edit.

Good modeling sits between those. Enough structure that content is data rather than a blob, enough flexibility that editors are not blocked by a field nobody anticipated. Getting there requires talking to editors before building, which is the step that most often gets skipped.

When is a custom CMS justified?

Rarely, and less often than agencies propose it. Existing platforms cover most requirements, and a custom system is expensive to build and expensive forever after, because you own every line of it.

It becomes reasonable when the content model is genuinely unusual — complex relationships, domain-specific workflow, or integration so deep that a general-purpose CMS would be fought at every turn. It also makes sense where content management is itself part of the product rather than support for it.

For most businesses the honest recommendation is a well-configured existing platform with custom fields and components. That is not a lesser answer; it is the same outcome at a fraction of the lifetime cost.

How does a CMS affect SEO?

Mostly through what it lets editors control and how it renders. A CMS that hides title tags, meta descriptions, headings or URL structure from editors makes routine SEO work a developer ticket, which means it does not happen.

Rendering matters more with headless. Content delivered by API and assembled client-side can be invisible to crawlers unless the front end is server-rendered or prerendered. That is an architecture decision made early, and expensive to reverse — the same technical SEO problem that catches JavaScript-heavy sites generally.

The other lever is publishing velocity. A model that lets a content team publish consistently without developer involvement compounds over years, and that is worth more than most individual technical optimizations.

What does headless actually cost?

More than the comparison articles suggest, and it buys things that are genuinely valuable to some organizations and irrelevant to others.

The gains are real: content becomes reusable across several front ends, the presentation layer can be rebuilt without touching the content, and the editing interface is independent of the site. For an organization publishing to a website, an app and a partner feed, that is transformative.

The costs are also real. Preview becomes something you have to build rather than something you have. Two systems have to be deployed and maintained instead of one. And the simple act of adding a page can require work in both.

The question we ask is whether content genuinely serves more than one destination today, or whether it might one day. "Might one day" is usually not enough to justify the ongoing cost, and traditional systems can be moved later with far less pain than the architecture diagrams imply.

How should editorial workflow be modeled?

By writing down what actually happens now, including the informal steps, before deciding what the system should enforce. The workflow on the org chart and the workflow in practice are rarely the same document.

Most content passes through fewer real states than people assume — usually draft, review and published, with an occasional scheduled state. Systems that model eleven states end up with everything sitting in one of them because the rest are too much effort.

Permissions follow states. Who can move something from review to published is the decision that matters; everything else is detail. Getting it wrong in either direction is costly: too loose and unreviewed content goes live, too tight and one person becomes a bottleneck for the whole team.

Notifications are the part most often skipped and most often missed once it is working. A review state nobody is told about is just a place work goes to wait.

How do you handle content migration?

With a reconciliation count, not a spot check. The question is not whether the import ran, it is whether every item that existed before exists afterwards, with its relationships intact.

Migrations expose how the old content was really structured, which is almost never how anyone believed it was structured. Fields used for two different purposes, categories applied inconsistently, and a decade of formatting decisions embedded in the body text are normal findings.

That is why the mapping happens before the import rather than during it. Every field in the old system gets a decision: mapped, transformed, split, or deliberately dropped. The dropped list is reviewed by someone who owns the content, because that is where the arguments live.

URLs come last and matter most. A content migration that changes paths without a complete, tested redirect map is the most reliable way to lose accumulated search visibility — which is why we treat it as technical SEO work rather than a development detail.

What makes an editor stop fighting the CMS?

Fields that match the way they think about the content, and constraints that prevent mistakes rather than rules that ask them not to make any.

A good sign is that the editing screen looks like the thing being edited. An event has a date field, a location field and a capacity field, not a rich-text box with a convention about where to put the date. The convention is always broken eventually, usually by whoever joined most recently.

The second sign is that impossible states are impossible. If an item cannot be published without an image, the system should say so at the point of publishing, not produce a broken layout for visitors to find.

The third is that the interface does not offer options that do not apply. Every field an editor has to skip is a small tax paid on every item forever, and the total across a year is larger than anyone estimates.

How do you model content that appears in several places?

By storing it once and referencing it, rather than copying it and hoping the copies stay in step. They do not.

The pattern that works is a reference field. A case study exists as one item; a service page points at it. Change the case study and every page showing it updates, because they are all reading the same source rather than holding their own version.

The complication is context. The same item may need a short summary on a listing page, a longer one on a related-content block and its full form on its own page. That is solved by storing all three as fields on the item, not by writing three copies in three places.

What to avoid is embedding content inside other content. Once a testimonial exists as pasted text inside five different pages, there is no way to update it, no way to count where it appears, and no way to remove it reliably when the client asks you to.

What should preview and scheduling do?

Preview should show exactly what a visitor will get, including the surrounding page. Anything less and editors publish to check, which turns the live site into the staging environment.

This is the single most common complaint about headless setups, and it is a solvable problem rather than an inherent one — but it is work that has to be planned and budgeted rather than assumed to come with the system.

Scheduling needs to cover unpublishing as well as publishing. Campaign pages, seasonal offers and time-limited content all need an end date, and without one they stay live until somebody notices, which can be a long time.

The related case is content that should stop being promoted without disappearing. An expired offer that returns a 404 loses whatever links it accumulated; one that stays reachable with a clear notice and a route onward keeps them, and treats the visitor better.