Where does the content live?
Imagine a farm shop whose weekly availability list has to show on its website, on a screen above the till and in a phone app. If three people update three copies, one will be wrong by Thursday. A headless CMS solves that by keeping the list in one place and letting every screen ask for it.
In a traditional CMS, such as a standard WordPress site, the editing tools and the public pages come as one package. The software that stores your content also draws the pages. Headless removes the head, which is the part that draws the pages. What remains is a back end for storing and organizing content.
How the pieces fit together
Three parts do the work. Editors write in the CMS, where content is organized into types such as article, product or event. An API, a standard way for software to request data, hands that content over on demand. A separate front end, built with a web framework, receives it and turns it into pages or app screens.
When an editor publishes, the front end can rebuild the affected pages or fetch fresh content as visitors arrive. Because the parts are separate, a developer can redesign the front end without touching the content, and add a new screen later without moving anything. That separation is the whole point.
- Editors: write and organize content in the CMS
- API: delivers content to anything that asks for it
- Front end: the site or app that visitors actually see
- Hosting: where the front end runs, separate from the CMS
What you gain, and what you take on
The gains are real. Content can serve many places. Developers are free to use modern tools. Pages prepared ahead of time can load quickly when the build is done well. Security can be easier to reason about because the public site is separate from the editing system, though no set-up is free of risk.
The costs are real too. You now run at least two systems and pay for both. Editors may lose the click-and-see preview they are used to unless someone builds it. Features a traditional CMS provides through a plugin, such as forms or search, must be assembled. Your developer becomes a bigger part of the picture.
- Gain: one source of content for many screens
- Gain: a front end designed without the limits of a theme
- Take on: two or more systems to host, update and pay for
- Take on: previews, forms and search that may need building
- Take on: more reliance on a developer for changes
Does a smaller business need one?
Often not. A brochure site for a trades business, a clinic or a restaurant usually runs well on a traditional CMS, and the extra complexity of going headless would cost money without helping a single customer. Speed and design come from careful building, not only from architecture.
Headless becomes worth discussing when content must reach several places, when a web app needs structured content, when a design cannot be done within a theme, or when a growing organization wants separate teams to work independently. A headless WordPress build is also possible, using WordPress purely as the content back end.
Questions to ask before choosing one
If the idea still sounds right, ask the practical questions. Which products suit your editors? Who will build and maintain the front end, and what do updates cost over time? How does a draft get previewed? Where does each part run, and what happens to your content if you leave a supplier?
Our web development and performance teams can compare the options with you, starting from what you need to publish and who does the publishing. We can begin with a free consultation by phone or video, or in person at the Abbotsford studio.
- Can editors preview a page before publishing it?
- Who builds and looks after the front end?
- What are the running costs of each separate system?
- Can I export my content in a usable form?
- What simpler option did you consider first?
Content that machines can read directly
Structured content suits the way assistants and search tools read the web. When a CMS stores hours, prices, services and answers in clearly labelled fields, the same data can feed web pages, structured markup and tools that answer questions. That advantage comes from structure itself, and a well-organized traditional CMS can offer it too. The habit matters more than the product.
- 01Name each content field for what it contains
- 02Keep one source for facts such as hours and service areas
- 03Test how the content reads when it is separated from its page design
Questions & answers
It means the system stores and manages content but does not draw the public website. Content is delivered through an API to a separate front end, such as a website or an app. The head is the presentation layer, removed from the content system and built on its own.
Not automatically. Headless set-ups can load quickly because pages are prepared ahead of time, yet a poorly built one can be slow, and a well-built WordPress site can be quick too. Speed comes from the build, hosting and images, so ask a developer to show real measurements.
Yes. WordPress offers an API that other front ends can read, so it can serve as the content back end while a separate site displays the pages. You keep a familiar editing screen, and you take on the extra work of building and hosting the front end.
The editing screen can be as friendly as any other. The difference lies in previews and extras, which need deliberate set-up. Ask to try the editor with your own content before you commit, and agree who is responsible when something on the public site looks wrong.
