Content systems
CMS architecture: choosing the right content system
The right content system is decided by how a business actually publishes — who edits, how often, with what approval and into how many channels — not by which platform is currently fashionable.
CMS selection goes wrong in a predictable way. It starts as a platform debate, gets settled by whoever has the strongest preference, and only later collides with how the business actually publishes. Two years on, the editors have built workarounds, the developers maintain exceptions, and everyone blames the platform for a decision that was never really made.
Start with content operations
Content operations is the unglamorous description of how content actually gets made and kept current: the people, the cadence, the review, the assets and the constraints. It is the single most reliable predictor of whether a content system will be used properly or worked around.
- Who creates content — specialists, a marketing team, subject experts across the business?
- How comfortable are they editing, and how much guidance does the interface need to give?
- How often does anything publish: daily, monthly, on campaign cycles?
- Does anything require approval before going live, and by whom?
- How much content repeats across pages — services, locations, people, products?
- Does the same content need to appear anywhere other than the website?
What a CMS actually manages
Content is only part of it. A content system is also a permission model and a workflow engine, and those two parts are where most of the eventual friction lives.
- Pages and posts, with their hierarchy and URLs.
- Structured content types: services, locations, people, case studies, products.
- Media, with alternative text, sizing and reuse across pages.
- Authors and contributors, and what each of them may change.
- Revisions, so a change can be reviewed, compared and reverted.
- Publishing workflow: draft, review, scheduled, live, archived.
Traditional CMS architecture
In a traditional or coupled CMS, the same system stores the content and renders the pages. Editors work in an interface that closely resembles the output, previewing in place, and publishing is immediate.
The advantages are real: fast to stand up, familiar to editors, and a very large ecosystem of themes, plugins and available expertise. The trade-offs are equally real: presentation and content tend to become entangled, performance depends heavily on how the theme and plugins are built, and the same content is difficult to reuse outside the website.
Headless CMS architecture
A headless CMS manages structured content and exposes it over an API. The front end is a separate application that requests content and decides how to render it — as a website, inside a product, on a screen in a branch, or anywhere else.
This buys genuine flexibility, clean separation of concerns, and one content source for several destinations. It costs a more deliberate setup: preview has to be built rather than assumed, the front end is a real application with its own release process, and the editing experience is only as good as the content model designed behind it.
Coupled CMS vs headless CMS
Code-driven and static content
Not every site needs a database behind its content. Content held in the repository — structured data files or markdown reviewed like code — gives version history, review before merge, and a delivery model that is very hard to make slow.
It suits sites where a small technical team owns the content and change is infrequent. It suits a marketing team publishing weekly very badly, and pretending otherwise is how a site quietly stops being updated.
Hybrid approaches
Most substantial sites end up hybrid, and deliberately so. Marketing pages are composed from structured content in a CMS. Documentation lives in the repository. Application content is served through an API into the product. The architecture question is not which single model wins, but where the boundary between them sits and who owns each side of it.
Content editors versus developers
Every content system distributes power between editors and developers. Give editors too little and the site stagnates in a queue of small tickets. Give them unconstrained layout control and the design system erodes within months — inconsistent spacing, invented components, pages nobody can maintain.
Structured content versus page-builder content
A page builder stores a page as an arrangement of visual blocks. A structured model stores a service as a name, a summary, an outcome list and a set of relationships, which templates then render.
The difference shows up the first time you need the same content somewhere else: in a listing, a related block, a regional variant, a feed or an application. Structured content is already reusable. Builder content has to be copied, which means it will eventually be inconsistent.
Page blob vs structured model
Structured content is also the foundation for machine-readable markup: fields already separated in the model can be emitted as schema without a second authoring effort, which is the approach described in structured data architecture.
Permissions and publishing workflow
Once more than two people publish, workflow becomes a requirement rather than a feature. Who may create, who may edit another author's work, who may publish, what happens to scheduled content, and how a mistake is reverted. Systems differ far more here than their marketing pages suggest, and it is worth testing with the real people who will use it.
Localization and regional content
If content varies by language or region, the model must express that from the start: which fields are translated, which are shared, what happens when the source changes, and how each variant is addressed by URL. Retrofitting localisation onto a single-locale model is one of the more expensive corrections there is. The structural side is covered in regional SEO architecture.
Integrations
Ask what else needs the content, and what content needs to come in. A CRM, a booking system, a product catalogue, a mailing platform, an internal source of truth. Integration capability is a legitimate selection criterion, and it is easier to evaluate before the choice than after it.
Preview, drafts and revisions
Editors need to see a change before the public does. In a coupled CMS this is close to free; in a headless setup it is a feature that must be built and maintained. Under-scoping preview is one of the most common reasons a technically sound headless project is disliked by the people who use it every day.
Lock-in and portability
Every system creates some attachment. The question is what happens if you leave: can content be exported with its structure intact, or only as rendered markup with proprietary block wrappers around it? Content stored as fields is portable. Content stored as a builder layout is a rebuild in waiting.
When WordPress still makes sense
WordPress remains a strong, sensible answer for content-led publishing: a mature editing experience, an enormous ecosystem, wide availability of people who know it, and low friction for a marketing team that publishes regularly. Dismissing it as outdated is fashion, not analysis.
Its limits are specific rather than general. Performance depends heavily on theme and plugin discipline. Structured content requires deliberate modelling rather than arriving by default. And when accounts, permissions, transactions and workflows start accumulating in plugins, the platform is being used as an application framework, which is where the problems begin.
When a custom or headless system makes more sense
- The same content must serve a website, an application and other channels.
- Content is genuinely structured — many records, related to each other, filtered and queried.
- Performance and delivery are commercially important and must be controlled precisely.
- The front end is already an application with its own release process.
- Editorial workflow needs to be tailored rather than adapted to.
A decision framework
| Criterion | Traditional CMS | Headless CMS | Code-driven content |
|---|---|---|---|
| Editing experience | Strong, familiar, in-context | Good, depends on the model designed | Developer-oriented |
| Structured content | Possible with deliberate modelling | Native | Native, in files |
| Presentation flexibility | Bounded by theme and blocks | Complete | Complete |
| Developer dependency | Low for routine content | Moderate | High |
| Multi-channel reuse | Limited | Designed for it | Possible with effort |
| Preview and drafts | Built in | Must be implemented | Branch previews |
| Permissions and workflow | Mature | Varies by product | Code review |
| Portability | Depends on how content is stored | Generally good | Complete — you own the files |
| Best fit | Editorial and marketing publishing | Content across site, app and channels | Small, stable, technically owned sites |
Whatever the answer, the content model outlives the platform choice, and it is the part worth spending real time on. How that model keeps a site changeable for years afterwards is the subject of building a website that can evolve.
Platforms are replaced every few years. A well-designed content model gets carried across to the next one intact.
Frequently asked questions
- What is a CMS?
A content management system is the software a business uses to create, structure, review, publish and update content without editing code each time. It manages the content itself, the people allowed to change it, and the process by which changes go live.
- Is WordPress still a good CMS?
For editorial and marketing publishing run by non-technical editors, it is still one of the strongest options available: a mature editing experience, a very large ecosystem and a deep pool of people who know it. Its weaknesses appear when core business logic accumulates in plugins, which is a different problem from publishing. See is WordPress still relevant.
- What is a headless CMS?
A content system that stores and manages structured content but does not render the site itself. The front end requests content over an API and decides how to present it. That separation lets one content source feed a website, an application and other channels, at the cost of a more involved preview and delivery setup.
- Does every website need a CMS?
No. A small site whose content changes a few times a year can be maintained in code with less overhead and fewer moving parts than a CMS introduces. A CMS earns its place when non-developers need to publish, when volume is significant, or when content must be reused across pages and channels.
- What is structured content?
Content stored as meaningful fields — a title, a summary, a date, a location, a price, a set of relationships — rather than as one formatted blob of markup. Structured content can be reordered, filtered, reused in several places and rendered differently per context without being rewritten.
- Can a CMS power an application?
It can supply an application's content, and that is usually the right division of labour. Application state — accounts, records, permissions, transactions — belongs in the application's own data model, not in the CMS. The distinction is set out in when a website should become a web application.
- How do you choose the right CMS?
Describe the real publishing workflow first: who writes, who approves, how often anything is published, what content repeats, what must be previewed, and which other systems need the same content. The shortlist usually narrows to one or two options before a single platform demo is booked.