If you run one website, publish a few pages a week and have no developer on staff, stay with a traditional CMS. Headless starts paying for itself when the same content has to feed more than one destination, or when a development team is already maintaining a front end. That is the whole decision, and the rest of this article is the arithmetic and the caveats behind it.
What headless actually means
A traditional, or monolithic, CMS stores your content, decides how it looks and serves the page. WordPress, Drupal, Joomla and the hosted builders all work this way. The Web Almanac’s 2025 CMS chapter uses the same split, describing a classic monolithic CMS as one that combines content storage, presentation and delivery in a single system, while a headless or composable CMS separates content management from whatever displays it.
In a headless setup the CMS becomes a content database with an editing interface and an API. Your website is a separate application, usually built with a JavaScript framework, that asks the API for content and renders it. That separation is the whole point: the same content can feed a website, a mobile app, a kiosk and a partner’s system without being copied. It is also the whole cost, because somebody now owns an application that used to be a theme.
Traditional CMS
One system does content, layout and delivery. You buy or build a theme, install plugins, and your editors see the page as they edit it.
- Editors get true visual editing and preview
- Huge plugin and theme market, large hiring pool
- One bill, one vendor, one place to look when something breaks
- A marketing team can change a page without a deployment
- Harder to feed a mobile app or second front end
- Plugin sprawl becomes a performance and security liability
- You inherit the platform’s update cycle
Headless CMS
Content lives behind an API; the front end is your own application, deployed separately. Structured content first, presentation second.
- One content source for many channels
- Front-end framework and hosting entirely your choice
- Smaller attack surface on the public site
- Structured content is easier to reuse and syndicate
- Preview and visual editing need deliberate engineering
- Two or three vendors and two or three bills
- Every layout change is a developer task and a deployment
- Usage-based pricing can surprise you in a traffic spike
Hybrid
Keep the editing experience your team already knows, serve a custom front end from the existing CMS’s API.
- Familiar editorial workflow retained
- Incremental: migrate one section at a time
- No content migration on day one
- You maintain both halves
- Preview fidelity is the usual casualty
- Plugins that output their own markup stop working
What the web actually runs on
Before the architecture argument, some perspective on the market you are hiring and buying in. The Web Almanac’s 2025 CMS chapter found WordPress accounted for 64.3% of all mobile CMS usage, with Shopify second at 7.3%, Wix at 5.2% and Squarespace around 3%. Among the top 10,000 websites the mix changes: WordPress is about 58% of CMS usage there and Drupal around 6 to 7%, far above its roughly 1% overall share.
Two practical consequences. First, WordPress skills are abundant and cheap to hire, and headless front-end skills are neither. Second, the long tail of headless platforms each hold a small share, so you are making a bet on a vendor with less gravity than the incumbent. Neither point says do not go headless. Both say price the dependency honestly.
The monthly bill, with real prices
Here are the actual list prices, taken from each vendor’s own pricing page on 1 October 2026. The comparison is a five-person editorial team running one business website with moderate traffic.
| Setup | Platform cost | Hosting cost | Typical monthly total | What pushes it up |
|---|---|---|---|---|
| Managed WordPress | WordPress itself is free and open source (version 7.1.2 at the time of writing) | Kinsta Business Single: USD 35 per month, or USD 350 per year for one install with 20 GB storage | USD 35 to 60 with a premium theme and a few paid plugins | Extra sites at USD 30 each per month, extra 20 GB disk at USD 20 per month; WP Engine charges USD 20 per month per additional site |
| Headless with Sanity | Sanity Growth: USD 15 per seat per month, up to 50 seats. Five seats is USD 75 | Vercel Pro: USD 20 per month, which includes USD 20 of usage credit | About USD 95 before overages | API and bandwidth overages (USD 1 per 250,000 CDN requests, USD 0.30 per extra GB of bandwidth); quota add-on at USD 299 per month; extra dataset at USD 999 per month |
| Headless with Strapi Cloud | Strapi Cloud Starter: USD 35 per project per month (100,000 API requests, 50 GB asset storage). Pro is USD 90 | Included in Strapi Cloud for the CMS; front end on Vercel Pro at USD 20 | USD 55 on Starter, USD 110 on Pro | Additional environments at USD 60 per month each, extra API requests at USD 1.50 per 25,000, extra bandwidth at USD 30 per 100 GB |
| Self-hosted headless | Strapi’s Community edition is free to run yourself | Your own server or container platform | Server cost only, often USD 20 to 50 | Your time: updates, backups, monitoring and the database are now yours |
The platform bills land within about USD 60 of each other. That is the trap in most headless-versus-traditional comparisons: they stop here and conclude the two are equivalent. They are not, because the subscription is the small number.
Where the effort goes
A traditional build buys presentation off the shelf. A commercial theme, some configuration, a content migration and you have a site. A headless build means somebody writes the front end: routing, layouts, image handling, forms, search, redirects, sitemaps, previews, 404s and the hundred small behaviours a mature theme already has. In our experience that is the difference between a two to four week project and a two to four month one, and the ongoing difference between a plugin update and a dependency upgrade on a JavaScript framework.
| Task | Traditional CMS | Headless CMS |
|---|---|---|
| Launch a new landing page | Editor, 30 minutes, no deployment | Editor if the template exists; otherwise a developer and a deployment |
| Change a page layout | Page builder or theme options | Front-end code change, reviewed and deployed |
| See content as it will look | Built in | Needs a preview integration built deliberately |
| Add a contact form | Plugin, under an hour | Build it, plus a spam and delivery mechanism |
| Keep it secure | Keep core, theme and plugins patched | Keep framework and dependencies patched; smaller public surface |
| Feed a mobile app as well | Awkward; usually a second integration | The reason you chose this |
Headless moves work from a monthly subscription into an engineering budget. That is a fair trade when you have engineers and a terrible one when you do not.
Performance is not automatic either way
Headless is often sold as the fast option. The field data is less flattering to both camps. The Web Almanac’s 2025 CMS chapter found 45% of WordPress mobile sites passing all three Core Web Vitals, against 85% for Duda, 79% for TYPO3 and 74% for Wix. Across the whole web, 48% of mobile sites and 56% of desktop sites passed in 2025. The Almanac’s own reading is that these gaps reflect how much variation a platform allows rather than the quality of its core, which is exactly why a headless build can land anywhere on that scale.
A headless front end gives you control over the JavaScript bundle, which is the usual cause of poor mobile responsiveness, and it also gives you the rope to ship a 2 MB bundle with three analytics tools in it. Control is not the same as a good outcome. If performance is your actual goal, our guides to why website speed matters and web hosting types will take you further than an architecture change.
When headless is the right call
- You have more than one front end. A website plus a mobile app, or several regional sites sharing a product catalogue. This is the strongest case and it is straightforwardly financial.
- Your content is genuinely structured. Products with specifications, courses with modules, properties with attributes. If editors are currently faking structure with headings and tables inside a page builder, a content model will pay back quickly.
- You already employ front-end developers. The marginal cost of one more application is low when the team and the deployment pipeline exist.
- You need strict separation between editing and serving. Common in regulated sectors, where the public site should be static files with no admin interface attached.
- Traffic is spiky and you want to serve static files. Pre-rendered pages on a CDN handle a product launch gracefully.
When it is the wrong call
- You have no developer. Every layout tweak becomes a support ticket with somebody else’s calendar attached.
- Your team publishes visually. If people build pages by dragging blocks around and watching them move, a headless preview will feel like a downgrade however well it is built.
- The site is brochure plus blog. Twenty pages and a news section do not need a content API. They need good hosting and a disciplined theme.
- The motivation is speed alone. Fix images, scripts and hosting first. The pass-rate figures above show platform choice is not destiny in either direction.
- Nobody has priced the second year. Framework major versions, dependency upgrades and the developer who built it moving on are all real costs. Budget them before you commit.
A migration path that does not eat your year
- Write the content model first. On paper. Types, fields, relationships. If this exercise is hard, it is also the main value you are buying, and it is worth doing even if you stay traditional.
- Pick the smallest real front end. One section, usually the part with the most structure: a product catalogue, a documentation area, a resource library.
- Run both for a while. Serve the new section from the headless stack and leave the rest where it is. Path-based routing at the CDN makes this undramatic.
- Build preview on day one. Not in phase two. Editors who cannot see their work will quietly stop using the system, and then you own two platforms and a morale problem.
- Measure before and after. Core Web Vitals field data, publishing time per page, and the number of changes that needed a developer. Those three numbers tell you whether to continue.
- Decide at the review point. If the pilot did not clearly improve something, stopping is a legitimate and cheap outcome.
Our web development and hosting service builds both, remotely, for clients worldwide. We will tell you when the honest recommendation is better hosting and a tidier WordPress install rather than a re-platform, because that is the answer for most businesses that ask us this question. Mobile behaviour should shape whichever route you take, which is the subject of our note on mobile-first web design. Clients who need someone physically on site in Sri Lanka should look at eudora.lk.
Frequently asked questions
Can WordPress be used headlessly?
Yes. WordPress exposes a REST API and a GraphQL plugin ecosystem, and plenty of teams keep the familiar admin while serving a custom front end. You retain the editorial workflow and lose most plugins that render their own markup, including page builders, forms and SEO output. It is a reasonable middle path when the editing experience is the thing you cannot give up.
Is headless better for SEO?
Not inherently. What matters is that pages are server-rendered or pre-rendered, URLs are stable, metadata and structured data are emitted, and sitemaps and redirects work. A traditional CMS gives you those by default; a headless front end gives them to you if whoever builds it remembers. The most common SEO damage we see after a re-platform is redirects that were never mapped.
What does a headless build actually cost to commission?
The platform subscriptions in the table above are tens of dollars a month. The build is the number that matters, and for a business site with a handful of templates, preview, forms and search, it is typically a multi-week engineering project rather than a configuration job. Ask any supplier to quote the second year as well as the first, including framework upgrades.
Will our editors cope?
They will if preview, media handling and scheduling work properly, and they will not if those are left until later. Include two editors in the pilot, give them real work to publish, and treat their complaints as requirements rather than training issues.
Do we have to choose now?
No, and the content model is the part worth doing immediately either way. Structuring your content properly inside your current CMS makes any future move cheaper, improves the site you already have, and costs nothing but a few hours of thinking.
Want an honest recommendation on whether to re-platform, with the costs for both routes? Get in touch with Eudora Technology to talk about your project.
.jpg){kind=link}