Someone has suggested your next website should run on a headless CMS: faster pages, tighter security, content you can publish “anywhere”. For the right organisation, that’s true.
For a typical business website, it can also be the most expensive way to build something a traditional CMS already does well. Editors can lose live preview and familiar plugins, new layouts need a developer, and you pay to run two systems instead of one.
The short answer
A headless CMS is a content management system that stores and manages content but doesn’t display it. It delivers that content through an API to a separately built front end: a website, a mobile app or a screen in a showroom. The missing “head” is the presentation layer, the theme and templates that turn content into pages.
Most business websites don’t need one. Headless pays off when the same content feeds several channels or an app sits alongside the website, and a capable engineering team will own the front end long term. Without those, a well-built traditional CMS is quicker to launch, easier to edit and cheaper to run.
What “headless” actually means
A traditional CMS does everything in one place: editors write in the admin area, and the same system uses a theme to turn their content into the pages visitors see. WordPress with a theme is the best-known example, and our plain-English guide to how websites are built shows where the CMS sits among the other layers.
A headless CMS keeps the editing and storage and drops the display. It hands content over as data through a REST or GraphQL API, and developers build the website separately, often with a JavaScript framework such as Next.js, Nuxt or Astro. The front end fetches content when the site is built, producing ready-made pages, or each time a page is requested.
You’ll also hear decoupled CMS, used almost interchangeably (the FAQ covers the fine distinction). A hybrid set-up renders a normal website and also offers an API for other channels. WordPress already works this way out of the box.
Picture a manufacturer with 200 products. In a traditional CMS, each product is a page. In a headless CMS, each product is a record with fields (name, specifications, datasheet, images) that the website, a distributor app and a trade-show kiosk each display in their own way. Update a specification once and every channel changes.
Traditional vs headless vs hybrid: how they compare
| Area | Traditional CMS | Headless CMS | Hybrid |
|---|---|---|---|
| Editing and preview | Edit the page, see it as visitors will | Fill in fields; preview must be built | Traditional on the website |
| Speed | Depends on build, hosting and caching | Can be very fast; depends on the front end | As traditional |
| SEO | Handled by plugins and settings | Built into the front end by developers | As traditional |
| Front-end plugins | Work as intended | Mostly stop working | Work on the website only |
| New layouts | Editors, within the design | A developer builds and deploys them | Editors, on the website |
| Running cost | Lowest (one system) | Highest (two systems, often a subscription) | In between |
| Best for | Most business websites | Content shared across many channels | A website now, an app later |
Editing and preview
Marketing teams feel this first. In a traditional CMS, what you edit is what visitors get. In a headless CMS, editors fill in forms, and previewing a draft as visitors will see it depends on developers building that preview. Some platforms offer visual editing, but only as far as the front end supports it.
Speed
Headless sites are often fast, because pages can be pre-built and served from a content delivery network. But speed comes from the build, not the label: a heavy JavaScript front end can be slower than a lean traditional site with good hosting and caching.
Judge any option against Google’s Core Web Vitals “good” thresholds at the 75th percentile of page visits: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint within 200 milliseconds, Cumulative Layout Shift of 0.1 or less. Traditional builds can be fast too: our property developer redesign cut page load time from 9 seconds to 2 on a standard WordPress build, without going headless.
SEO responsibility
Search engines assess the page they receive, not the architecture behind it. What changes is who does the work. On traditional WordPress, core features and an SEO plugin handle titles, meta descriptions, canonical tags, sitemaps and structured data. In a headless build, each becomes front-end code someone must write and maintain, in every language you publish in.
Rendering matters too. Google can render JavaScript, but its own JavaScript SEO basics guide still calls server-side rendering or pre-rendering a great idea: it’s faster for users and crawlers, and not all bots can run JavaScript. A headless front end should deliver complete HTML, not an empty shell; our technical SEO checklist lists what to verify.
Plugins, hosting and running cost
Plugins that change what visitors see, such as form builders, page builders, cookie banners and the front-end parts of SEO and multilingual plugins, generally stop working and need an API-aware alternative or a rebuild. Forms catch people out most: submissions need somewhere to go, plus spam protection and notification emails.
You also host and update two systems, often with a pipeline that rebuilds the site whenever an editor publishes. Hosted platforms such as Contentful, Sanity and Storyblok have free tiers, then subscriptions priced on some mix of users, languages, content volume, traffic and API usage; self-hosting open-source Strapi swaps the subscription for hosting and maintenance. Budget for years of running costs and developer time, not just the build.
Headless lives or dies on structured content
Headless only earns its keep if content is modelled as structured content: content types and fields, not page layouts. A “Project” type might have a name, location, status, completion date, gallery and floor plans. A “Page” with a hero block, three columns and a banner is a layout, and a layout can’t be reused anywhere else.
If the content model mirrors today’s pages (“homepage hero text”, “about page block 3”), the result is a traditional website with extra steps and a bigger bill.
Before anyone mentions architecture, tick what’s already true of your content:
Structured content pays off in a traditional CMS too. WordPress custom post types and custom fields give you the same discipline, feed consistent schema markup and leave content ready for an API later. For most businesses, that is the valuable part of the headless idea, without the second system.
Headless WordPress: a worked example
WordPress is a common starting point for headless, because editors keep the admin they already know. It has a REST API built into core, many headless builds add the free WPGraphQL plugin to query content with GraphQL, and the front end is built separately in a framework such as Next.js or Astro.
What stays the same. The admin screens, users and roles, media library, revision history, custom post types and fields.
What changes. The theme no longer renders the public site, so layouts move out of page builders such as Elementor or Breakdance and into front-end code. The SEO output (fetched from the SEO plugin through the API), forms, previews, site search and the language switcher all become front-end work too.
What a normal Tuesday looks like. A marketing manager needs a landing page for next week’s campaign. On traditional WordPress, they duplicate a template, edit it, preview and publish. On headless WordPress, that works only if a landing-page content type with the right sections already exists; a new section means a developer builds and deploys it first.
Where it fits. A busy WordPress newsroom that now needs the same articles in an app fits well. A marketing team that relies on a page builder to launch pages without a developer doesn’t. For them, a solid traditional build, done to the standards in our WordPress best practices guide, delivers most of the promised speed and security with far less to maintain.
Headless CMS pros and cons: when it pays off
Signs it earns its keep
- Several channels share the same content. A website, an app, in-store screens or a partner portal, all drawing on one source.
- An app sits alongside the website. If you’re planning one, compare progressive web apps and native apps first.
- The front end is closer to an application. Logins and dashboards mean custom code anyway; see website vs web application.
- You have the engineering to own it. An in-house team or long-term partner who will maintain the front end and its SEO for years.
Signs it’s complexity you don’t need
- One website, edited by a non-technical marketing team.
- No in-house developers, so every front-end change depends on an outside supplier.
- The case for it is “faster”, “more modern” or “future-proof”, with no list of channels.
- The budget covers the build, but not two systems’ running costs.
Questions to ask whoever pitched it
- Which channels besides the website will use this content in the next two years?
- How will editors preview a draft exactly as it will appear?
- Can we create a new page without a developer? A new layout?
- Who builds and maintains titles, sitemaps, redirects, hreflang and structured data?
- What are the running costs, including subscriptions, hosting and developer time?
- Why wouldn’t a well-built traditional CMS meet these goals?
Good answers are specific. Vague ones suggest the architecture was chosen before the problem was understood. Our guide on how to choose a CMS gives you a scoring framework for comparing options.
Frequently asked questions
Is a headless CMS better for SEO?
Not in itself. A headless site can rank as well as any other, provided it serves complete HTML and someone builds the titles, sitemaps, redirects and structured data a traditional CMS handles through settings.
What is the difference between a headless and a decoupled CMS?
They’re often used interchangeably. In the stricter sense, a decoupled CMS still has a front end of its own alongside its API, as WordPress does, while a headless CMS has no front end at all and only delivers content through its API.
Is a headless CMS more secure?
It can reduce exposure: visitors needn’t reach the CMS itself, and the admin can sit on a separate, restricted address. But the API needs securing and there are two systems to patch, so it is only as secure as its upkeep.
Can we move to headless later?
Yes, and it’s far easier if your content is already structured. WordPress can keep running your website while its API feeds a new app, one channel at a time. Content locked in page-builder layouts is the hard part to move.
So, does your business need a headless CMS?
If you run one website, kept current by a marketing team in the languages your customers use, a well-built traditional CMS is the better investment: quicker to launch, cheaper to run, easier to hand over. Headless becomes the right answer when your content has somewhere else to go and you have the engineering to support it.
Weighing a headless proposal against a traditional build? Our website design and development page shows how we plan and build WordPress websites your team can edit themselves. If speed raised the question, a free website audit shows what’s actually slowing your current site before you change its architecture. Or talk to us about what your website needs.