Headless CMS vs traditional CMS: what changes for editors, SEO and cost, with 2026 prices

The short answer

A traditional CMS such as WordPress stores your content and also draws the pages, through a theme. A headless CMS such as Sanity, Contentful, Storyblok, Strapi or Payload only stores and serves content through an API; a separate front end, built and maintained by developers, turns it into pages.

Choose a traditional CMS when a small team edits one website, nobody writes code and you want preview, forms and SEO fields out of the box. Choose headless when the same content feeds more than one site or app, when you already have developers who own the front end, or when you want control over speed and security that a theme and plugins can't give you. Headless is not automatically faster: in HTTP Archive data for September 2026, 38.1% of sites using Contentful passed Core Web Vitals on phones, against 48.3% of WordPress sites. The front end decides.

What each one is

The Web Almanac 2025 puts it in one line: "A headless or composable CMS separates content management from the site or app that displays it."

• Traditional (coupled) CMS. One application holds the database, the editing screens, the templates and the code that renders each page. WordPress, Drupal and Joomla work this way. Editors see the page as visitors will, and plugins add features to both the admin and the public site.
• Headless CMS. The CMS holds structured content (titles, fields, rich text, images, references) and delivers it as JSON. The website is a separate project, often built with Astro or Next.js, that reads the content at build time or on request. The same content can feed a mobile app, a second site or an email.
• The middle ground. WordPress itself can run headless: its REST API returns posts, pages and taxonomies as JSON, and the block editor is built on it. In the other direction, headless CMSs now ship visual editing so editors can click on the live page instead of filling in forms.

dardo.studio is headless: an Astro front end on Cloudflare Workers, with content in EmDash, an open-source CMS that Cloudflare released as 1.0 on 28 September 2026.

How many sites use each, and how fast they are

We queried the HTTP Archive's technology report for September 2026, the latest month, which combines Chrome UX Report field data with its monthly crawl of millions of sites (mobile, all countries):

Sources: HTTP Archive API, adoption, Core Web Vitals and page weight, read 21 October 2026.

Three things stand out:

• Headless is still niche. The five headless CMSs above add up to about 29,800 sites, roughly 1% of WordPress's count. The Web Almanac puts WordPress at 64.3% of all sites that use a CMS. The count understates headless, though: these tools are detected from the image and asset addresses they leave in a page, and self-hosted ones barely show (Strapi appears on 14 sites).
• Headless sites carry more JavaScript, not less. Every headless CMS in the table has a higher median than WordPress, because many headless front ends are React applications. Moving content into an API doesn't remove the weight; choosing a lighter front end does. Across the same data, sites built with Astro pass Core Web Vitals on phones 71.1% of the time; our website platform speed report has the figures by framework and country.
• WordPress's speed problem is mostly its ecosystem. The Web Almanac estimates that around 60% of WordPress sites use a page builder, Elementor the most common. Those builders, not WordPress itself, decide much of the page weight.

Which one fits your team

If most of your answers are in the first column, a traditional CMS (or a hosted builder like Webflow or Framer) will serve you better, and our comparison of Webflow and WordPress is the next read. If they're in the second, the question becomes which headless CMS; Sanity vs Contentful vs Payload compares them in depth.

What each costs to run for three years

Take a 40-page marketing site with a blog, five people who edit and two languages. These are the subscription and hosting costs only, at list prices read on 21 October 2026, in US dollars before tax:

Sources: Hostinger, WordPress.com, Kinsta, Sanity, Cloudflare Workers, Storyblok, Strapi Cloud and Contentful.

What the table doesn't show:

• Promotional prices end. Hostinger's Premium plan costs USD 2.49 a month only if you prepay 48 months; it renews at USD 10.99.
• Free tiers exist, with catches. Sanity's Free plan has 20 seats but only two roles, so everyone who edits is an administrator. Strapi's open-source edition and Payload are free to self-host, but you pay for the server, the database and the hours to patch them; Payload has paused new deployments on its own cloud since joining Figma.
• The front end has its own host. Static pages on Cloudflare Workers are free and unlimited; Vercel and Netlify Pro start at USD 20 a month (Vercel, Netlify).
• Two languages cost something on WordPress. Sanity includes unlimited locales on every plan and Storyblok includes two on Growth, while WordPress usually needs a plugin: WPML's Multilingual CMS plan is EUR 99 for a year of updates.
• Contentful's step is steep. Lite covers 20 users and 3 locales, but its space holds 10,000 records; our Contentful pricing breakdown shows what happens after that.

The subscriptions are rarely what decides the budget. A traditional site starts from a theme; a headless site needs its front end designed and built, which is most of the project's cost. After launch, WordPress needs regular plugin and core updates: Patchstack, a WordPress security vendor, counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, 91% of them in plugins and only 6 in core. A headless site swaps that for framework upgrades and someone who owns the code. Our website cost calculator shows what published prices suggest for the build, and our website maintenance cost guide covers the years after.

What editors gain and lose

On a traditional CMS, editors work on something close to the real page. They can add a section, move a gallery or build a landing page with a page builder, and preview it before publishing. The cost is consistency: when anyone can lay out anything, the site drifts, and every builder adds its own code to the page.

On a headless CMS, editors fill in structured fields: a headline, a summary, a list of features, a related case study. The layout comes from components developers built. That keeps the site consistent and lets the same entry appear in many places, but it feels like filling out a form unless preview is set up well. Most headless CMSs now offer it:

• Sanity's visual editing shows drafts on the real front end, with click-to-edit and drag-and-drop sections; live previews are listed on its free plan.
• Storyblok's Visual Editor puts the site in an editing frame, and its pricing table includes it on every plan, with 2 preview URLs on the free Starter plan and 6 on Growth.
• Payload's Live Preview loads the front end in an iframe and updates it as you type, through postMessage events.
• On the front end, Next.js has Draft Mode and Astro can render one preview route on demand while the rest stays static. On dardo.studio, the CMS's Preview button opens that route with a signed, short-lived token; it's the only page rendered on request.

Preview is developer work, and it's where weak headless projects let editors down. Ask to see it working before you sign off on a build.

What changes for SEO

Search engines don't know or care which CMS you use. They see the HTML your front end sends. Five things change in practice:

1. Rendering is your choice now. A headless front end can pre-render pages, render them on request, or build them in the browser. Google's JavaScript SEO basics say pre-rendering or server rendering "is still a great idea" because "not all bots can run JavaScript." Avoid front ends that only render in the browser for pages you want found.
2. SEO fields have to be modeled. WordPress plugins add a title, description, canonical, noindex and social image to every post. In a headless CMS those fields exist only if someone adds them to the content model, and the front end has to write them into the page. Sitemaps and redirects become front-end code too.
3. Structured content makes structured data easy. When the author, publish date, FAQ answers and prices are separate fields, writing them as JSON-LD (the format Google recommends) is a mapping, not a parsing job.
4. Preview and staging must stay out of the index. A headless setup adds preview URLs and staging deployments; each needs a noindex or authentication.
5. A rebuild is a migration. Moving from a theme to a new front end changes templates and often URLs. Map every old address and redirect it permanently; our migration SEO checklist covers it, and our Astro SEO guide shows how dardo.studio handles canonicals, hreflang, sitemaps and redirects in code.

What moving from traditional to headless involves

• The content model. List every content type and field you have (posts, pages, team members, case studies, custom fields) and decide what becomes structured fields and what stays rich text. This decision shapes everything after it.
• Rich text conversion. WordPress stores post bodies as HTML with block comments; Sanity stores rich text as Portable Text and Contentful as its own JSON. Shortcodes and page-builder markup need cleaning or rebuilding on the way.
• Media. Copy the originals, not the resized copies, and keep the alt text.
• SEO metadata and URLs. Export titles and descriptions from your SEO plugin, keep every URL that earns traffic, and redirect the rest. Our WordPress to Astro guide walks through both.
• Features plugins used to provide. Forms, search, comments and newsletters need their own services or endpoints.
• The cheap first step. Keep WordPress as the CMS and build only a new front end on its REST API. Editors keep their screens; you get the new front end now and can move the content later.

Our website migration cost guide lists published prices for this kind of move.

When headless isn't worth it

• One site, a small team, no developer. You'll pay to build and maintain a front end you don't need. A well-kept WordPress site, or Webflow or Framer, is the better trade.
• Editors who rebuild layouts every week. A headless CMS can do it with visual editing, but a page builder does it with less setup.
• Only developers edit. Markdown files in the repository, read by the framework at build, may be all the CMS you need.
• The real problem is a slow theme. Fixing the theme, images and scripts is cheaper than a new architecture; WordPress or a custom website helps you decide.

What to do next

Write down who edits, where the content goes and who will own the code, then price the build with the website cost calculator. If headless is the answer, compare the systems in Sanity vs Contentful vs Payload. Dardo builds headless sites and their editing setups through its headless CMS development service; for broader builds see web development.