Headless CMS – What It Is, How It Works and How It Affects SEO

A headless CMS is a content management system that only stores content and serves it through an API (REST or GraphQL). It has no theme or templates of its own, so the look of the site is built by a separate front end, e.g. in Next.js, Nuxt or Astro. For SEO the CMS itself is neutral, because Google only sees what the front end generates – and the outcome depends on rendering, meta tags, HTTP status codes, sitemaps and Core Web Vitals.

Below I explain how headless differs from classic WordPress, how Google processes JavaScript-based pages and what I check before a headless CMS goes live, so you don’t lose visibility.

Headless CMS – what is it?

The idea of a headless CMS started appearing more widely on tech blogs around 2015 – you can see it in Google Trends too. Today it’s a standard choice for larger websites, online shops and projects where the same content goes to a website, a mobile app and other channels.

The name comes from separating the ‘head’ (the front end, i.e. the presentation layer) from the ‘body’ (the back end, where editors create and store content).

How is headless different from a traditional CMS?

Traditional platforms such as WordPress, Drupal or Joomla combine managing content with displaying it. Content added in the admin panel is rendered straight away by a theme, template or skin installed in the same system.

With a traditional CMS, building a site isn’t just about content and site structure – it also means choosing and customising a theme (paid or free).

With a headless CMS, the system is used only to create and store content. Displaying it is the job of any front-end application that can fetch data from the CMS API and turn it into HTML.

What does ‘headless’ mean in practice?

In a traditional CMS, the back end and front end are tightly integrated in one system. In headless that link doesn’t exist, so the site is served by two independent parts: the content management system and an application that sends requests to the API and shows the content to the user (and to Googlebot).

This gives you flexibility: you store content in one place and use it across many channels – on the website, in a mobile app, in a shop or on digital signage screens – without setting up more CMS instances. Developers aren’t limited by ready-made themes, and the front end decides which data goes to a given channel and in what form.

The same architecture can also serve Googlebot ready-made, static HTML documents. Whether it does depends on how you build the front end – and from an SEO point of view, that’s the most important decision.

A simple comparison: headless CMS vs a traditional content management system

The differences can seem convoluted, so I’ve put them in one table.

Aspect	Headless CMS	Traditional CMS
Content presentation	Content is separated from the front end.	Content and presentation are tightly linked.
Front end	Built separately, in any technology.	Themes and templates within the CMS.
API	The main way to access content (REST, GraphQL).	Usually available (e.g. the REST API in WordPress), but optional.
Multichannel	The same content goes to the website, apps and other channels.	Designed mainly with the website in mind.
Barrier to entry	Needs developers to build and maintain the front end.	You can launch a site without coding.
Content preview	Preview has to be set up on the front-end side.	Preview works out of the box.
Workflow	Front end and back end can be developed independently.	Theme and content changes are tied together.
Performance	Depends on the front end, rendering and cache – can be very good or poor.	Depends on the theme, plugins, hosting and cache.
SEO	Meta tags, sitemaps, redirects and structured data have to be designed by you.	Most of it comes from ready-made SEO plugins.

The technology and idea behind a headless CMS

A headless CMS serves data through an API – most often REST or GraphQL, in JSON format. That doesn’t mean the whole site has to be a JavaScript app rendered in the browser. The front end can generate ready-made HTML on the server or at build time.

In practice most implementations use JavaScript frameworks such as Next.js (React), Nuxt (Vue), Astro or SvelteKit, and CMS vendors provide ready-made integrations and starters. For example, in 2023 Strapi listed its framework integrations in the footer of its website:

The headless CMS itself can be written in almost any language – PHP, Python, JavaScript. The only requirement is that it serves data through an API the front end can read.

Headless CMS vs WordPress

The ‘headless vs WordPress’ comparison is a bit misleading, because WordPress can also work as a headless CMS. The real choice looks like this: classic WordPress with a theme, WordPress as the back end for a separate front end, or a CMS designed as headless from the start (e.g. Strapi, Sanity, Contentful).

WordPress as a headless CMS (REST API and WPGraphQL)

WordPress has a built-in REST API through which a front end can fetch posts, pages, taxonomies and media. The alternative is the WPGraphQL plugin, which adds a GraphQL API. According to its page in the WordPress.org directory, it’s in the process of becoming a so-called Canonical Plugin, with support from Automattic.

The upside of this approach: editors stay in a familiar admin panel and developers get freedom on the front end. The downside that’s easy to forget: SEO plugins (Yoast, Rank Math) save titles, descriptions and redirects in the database, but in headless mode they don’t automatically insert them into the front end’s HTML. You have to fetch them through the API and render them yourself – a common reason for meta tags and canonical URLs disappearing after a migration.

Advantages of a headless CMS

1. Control over the front end and performance: with static generation or server-side rendering (e.g. in Next.js or Astro) you can get very fast pages. That’s a possibility, not a guarantee – it all depends on the implementation.
2. Modern tooling: developers work in their own frameworks, with version control, tests and CI/CD.
3. Multilingual content: in many headless systems localisation is built into the content model, and language routing is handled by the front end.
4. Fits the team: the content model and editorial panel can be shaped around specific processes.
5. Multichannel: one piece of content, many channels and devices.
6. Easier to swap parts: you can change the front end without migrating content, or the CMS without rewriting the whole front end.
7. Smaller attack surface: with statically generated sites, the CMS panel doesn’t have to be publicly tied to the site’s domain.

Disadvantages of a headless CMS

1. Cost of building and maintaining it: you need front-end developers, hosting for two layers and often third-party services (search, forms, images).
2. Content preview: an editor won’t see a post on the site until someone sets up preview. Some systems (e.g. Storyblok, Sanity) have visual editors, but they also need integrating with the front end.
3. No off-the-shelf features: SEO, sitemaps, redirects, forms or site search don’t work ‘out of the box’ – they have to be designed.
4. SEO risk during migration: changed URLs, lost meta tags, content rendered only in the browser and wrong status codes are typical reasons for drops after moving to headless.

Advantages of WordPress

1. Editor-friendly: a block editor with preview, easy creation and editing of content without a developer.
2. Customisable: a huge library of themes and plugins.
3. SEO without coding: friendly permalinks, a built-in XML sitemap (since version 5.5) and SEO plugins for meta tags, redirects and structured data.
4. Responsive design: modern themes are responsive, although quality and performance vary between them.
5. Multiple users: roles and permissions for an editorial team.

Disadvantages of WordPress

1. Security: its popularity makes WordPress a frequent target of attacks, and plugins that aren’t updated are the main source of problems.
2. Limited flexibility: delivering content in unusual ways (e.g. to an app) requires theme changes or extra plugins.
3. Plugin conflicts: some plugins clash with each other, with the theme or with core.
4. Performance: heavy themes and plugins can slow a site down a lot.

Summary – headless CMS vs WordPress

For most company websites, blogs and small shops, classic WordPress is simpler, cheaper and good enough for SEO. Headless starts to make sense with many channels, a complex content model, high traffic or a team of developers who are building the front end anyway. The hybrid approach – WordPress as the back end plus a separate front end – combines a familiar admin panel with flexibility, but shifts responsibility for SEO onto the developers.

Is a headless CMS faster and better on mobile than a traditional CMS?

In the previous version of this article I wrote that headless ‘by nature’ gives you a faster, more responsive site. Today I’d put it more carefully: responsiveness, speed and how easy the front end is to manage are features of the front end, not the CMS.

• Responsiveness – comes from the front-end code (CSS, components), regardless of where the content comes from.
• Speed – statically generated HTML from a CDN can be very fast, but an app that sends a lot of JavaScript to the browser can have worse LCP and INP than a well-optimised WordPress site with cache.
• Management – headless is more convenient for developers, but often harder for editors (no preview, fewer ready-made tools).

If performance is the reason you’re looking at headless, measure your current site first. It’s often faster and cheaper to improve it through technical optimisation than by rewriting the whole site.

Headless CMS and SEO – what Google says

Googlebot doesn’t connect to your CMS API. It fetches a URL, gets a response from the front-end server and evaluates that. So for SEO, the only thing that counts is what the front end returns: the HTTP status code, the HTML, links, meta tags and whatever appears after JavaScript runs.

What does Google think of headless CMS?

Google doesn’t judge the CMS, only the page. Its JavaScript SEO basics documentation describes three stages of processing JavaScript pages: crawling (fetching the URL and the links from the HTML), rendering (pages with a 200 status go into a rendering queue in headless Chromium) and indexing of the rendered HTML.

Google can execute JavaScript, but it also says that server-side rendering or pre-rendering is still a good idea, because it makes the site faster for users and crawlers, and not all bots run JavaScript. That matters beyond Google too – many crawlers, including some AI tool bots, read mainly the raw HTML (that’s my own observation, not a statement from Google).

Rendering: SSR, SSG, ISR or CSR?

This is the most important decision with headless. It determines whether the content is in the HTML straight away or only after JavaScript has run.

Method	How it works	SEO assessment
SSG (static site generation)	HTML is created when the site is built and served from a server or CDN.	Very good – full HTML, fast response. Needs a rebuild after content changes.
SSR (server-side rendering)	HTML is generated on the server for every request (often with cache).	Very good – full HTML, up-to-date content. Needs a capable server and cache.
ISR (Incremental Static Regeneration)	A Next.js concept: static pages are refreshed in the background at set intervals or on demand.	Very good – a compromise between SSG and SSR for large sites.
CSR (client-side rendering)	The server sends an empty HTML shell and JavaScript pulls in the content.	The riskiest – content and links depend on rendering, soft 404s and meta tag problems are easy to get.

Google explicitly calls dynamic rendering (serving bots a different, pre-rendered version) a workaround and not a long-term solution, and recommends server-side rendering, static rendering or hydration instead. For a new headless build I choose SSG, SSR or ISR, and leave CSR for the parts behind a login.

JavaScript SEO according to Google – headless pitfalls

Google’s documentation gives a few specific rules that headless projects break most often:

• noindex in the original HTML – when Google sees noindex, it may skip rendering, so removing that tag with JavaScript may not work.
• Canonical – you can set it with JavaScript, but you shouldn’t change it to a different URL from the one in the original HTML.
• URLs – instead of fragments (#/page) use the History API and normal <a href> links, because Googlebot doesn’t resolve fragments as separate pages.
• Status codes – a page that doesn’t exist should return a 404. For SPAs, Google recommends redirecting to a URL that returns a 404 from the server, or adding noindex, to avoid soft 404s.
• Title and meta description – can be set with JavaScript, but it’s safer to have them in the HTML from the server, unique for every page.
• Structured data – JSON-LD can be injected with JavaScript, but you need to test it (e.g. with the Rich Results Test and the URL Inspection tool in Search Console).

SEO checklist for a headless front end

When a headless CMS goes live, these are the things I check first:

1. Content and links in the HTML from the server – SSG/SSR/ISR, navigation based on <a href>.
2. Meta tags – unique title and meta description, canonical, meta robots and, on multilingual sites, hreflang. The values come from SEO fields in the CMS, with sensible defaults.
3. XML sitemap – generated automatically from the CMS content (with lastmod dates), without noindexed URLs, redirects or errors, and submitted in Search Console.
4. Redirects – managed by editors in the CMS, executed on the server or CDN as 301/308, not with JavaScript. I write more about status codes in my post on 301, 302, 307 and 308 redirects.
5. Status codes – real 404/410 for removed content, no soft 404s.
6. Structured data – JSON-LD (e.g. Article, Product, BreadcrumbList, Organization) generated from CMS fields.
7. Heading structure and alt text – one H1, logical H2/H3, a mandatory alt field for images in the CMS.
8. Friendly URLs – an editable slug, consistent structure, no duplicates (e.g. with and without a trailing slash).
9. Internal linking – menus, breadcrumbs and in-content links as normal HTML links.
10. Test environments – staging and preview blocked from indexing (password or noindex), and production without an accidental noindex.

Core Web Vitals in headless

Core Web Vitals are three metrics: LCP (loading, good up to 2.5 s), INP (responsiveness to interactions, up to 200 ms) and CLS (layout stability, up to 0.1) – according to web.dev. I describe them in detail in my article Core Web Vitals – what are they.

In headless builds I most often see two problems: a large JavaScript bundle and expensive hydration, which hurt INP, and images from the CMS without dimensions or optimisation, which hurt LCP and CLS. Static generation, less client-side JavaScript and image components with dimensions usually fix most of them.

What must your new headless CMS have?

First – how you run it. Self-hosted versions usually need Node.js, a database, sometimes Docker and environment variables to configure. That’s one of the reasons WordPress, with its simple installation, is so popular.

Installing Raytha on localhost

It’s also why many companies pay for the cloud version, even if the same product has a free version you can host yourself.

Installation is only half the job. Then you need to design the content model (content types, fields, relations) and build the front end. You design the content model once, but it’s worth spending time on, because it later feeds every channel – the website, the app or the newsletter.

The second issue is content migration. If your current CMS has a REST API (like WordPress), exporting the data is usually simple. Look for ready-made importers from WordPress, Joomla or Drupal to a specific headless CMS in its marketplace or on GitHub. It won’t always be easy, but it’s doable. For SEO, the key thing during migration is keeping the URLs or having a complete redirect map.

The third thing is getting the CMS ready for SEO. In my view, a new headless CMS must have:

• Fields for the meta title and meta description
• Support for Schema.org structured data (fields the front end can build JSON-LD from)
• Editable slugs and URL routing
• A field for the canonical URL and a noindex setting
• A way to manage redirects
• Data for generating the XML sitemap automatically

Which headless CMS gives you the most control over SEO? Pretty much any of them lets you add these fields, but not the way you know it from WordPress. There’s no Rank Math or Yoast plugin to create them for you – you have to design the fields, the default values and the logic for displaying them yourself.

For example, in Strapi you can create a component that holds all the SEO fields and attach it to every content type.

You’ll find similar solutions in every popular headless CMS. Well-designed fields and defaults make the editors’ work much easier.

Finally – integrations (search, forms, DAM, translations, analytics). Popular systems have a marketplace of plugins or apps for this:

• Strapi: https://community.strapi.io/marketplace
• Sanity: https://www.sanity.io/plugins
• Contentful: https://www.contentful.com/marketplace/

Almost every headless CMS has some kind of extension directory. Some are simpler, others harder to use, but for a team that has set up a CMS on a server, installing a plugin shouldn’t be a problem.

Popular headless CMS platforms in 2026

There’s no single best headless CMS. The choice depends on whether you want something that runs in the cloud straight away, full control with self-hosting, a visual editor for marketing, or a CMS built into a Next.js app.

It’s best to pick 2–3 candidates and test them on your own content model. It takes time, but you rarely change a CMS, so this decision will stay with you for years.

G2 Grid® for headless CMS (screenshot from 2023, the current ranking is on g2.com)

Below I describe the systems I come across most often in projects. I don’t test all of them day to day – as a freelance SEO I mainly optimise existing sites rather than build them from scratch – so I only give verified facts about the licence and hosting model.

Strapi

URL: https://strapi.io/

Strapi is a headless CMS written in JavaScript (Node.js), with REST and GraphQL APIs and a content-type builder. The Community Edition is available under the MIT licence, while the features in the ‘ee/’ (Enterprise Edition) directory have a commercial licence. The vendor also offers Strapi Cloud hosting. It’s a good choice when a team wants self-hosting and full control over the code.

Contentful

URL: https://www.contentful.com/

Contentful is a commercial SaaS platform – it runs only in the vendor’s cloud, with no self-hosted version. It serves content through APIs (REST and GraphQL). It’s popular with large organisations and multilingual projects, and has an extensive app marketplace. The vendor offers a free plan with limits, while the full feature set is in the paid plans.

Sanity

URL: https://www.sanity.io/

Sanity combines two parts. The Sanity Studio editorial panel is open source (MIT licence) and is configured in code. The content itself, however, is stored in the vendor’s hosted service (Content Lake), so Sanity as a whole isn’t a self-hosted solution. Pricing includes a Free plan and paid plans.

Storyblok

URL: https://www.storyblok.com/

Storyblok is a commercial SaaS headless CMS that stands out for its visual editor, where editors see a preview of the page while editing (once it’s integrated with the front end). It works well when marketing wants to assemble pages from components on its own. It has a free Starter plan for testing and small projects, as well as paid plans.

Payload

URL: https://payloadcms.com/

Payload is a headless CMS in TypeScript that you can install directly inside a Next.js app. The code is under the MIT licence and can be self-hosted. In 2025 the Payload team joined Figma, stating that the project remains open source.

Directus

URL: https://directus.com/

Directus puts an admin panel and an API (REST and GraphQL) on top of an existing SQL database. The code is publicly available, but it’s a source-available licence, not open source in the classic sense. Since version 12 (2026) Directus has used the Monospace Sustainable Core License, before that the Business Source License. Free production use depends on revenue and headcount thresholds set out in the so-called Innovation Grant, and each version switches to GPLv3 after four years.

Hygraph

URL: https://hygraph.com/

Hygraph (formerly GraphCMS) is a commercial SaaS headless CMS built around a GraphQL API. It lets you combine content with external data sources. It has a free Hobby plan and paid plans.

ButterCMS

URL: https://buttercms.com/

ButterCMS is a commercial, API-based SaaS headless CMS, aimed mainly at companies that want to quickly add a blog or marketing pages to an existing application.

Paid vs free headless CMS

‘Free’ in headless usually means one of two things: code you host yourself (so you pay for the server and maintenance) or a free cloud plan with limits. Paid plan prices change often, so I don’t list them – check them directly with the vendors.

System	Licence model	Self-hosting	Free option
Strapi	Open source (MIT) in the Community Edition, Enterprise features under a commercial licence	Yes	Community Edition
Payload	Open source (MIT)	Yes	All of the code
Directus	Source-available (MSCL), GPLv3 after 4 years	Yes	For organisations that meet the Innovation Grant conditions
Sanity	Studio open source (MIT), content in a SaaS service	Studio only	Free plan
Contentful	Commercial SaaS	No	Free plan with limits
Storyblok	Commercial SaaS	No	Starter plan
Hygraph	Commercial SaaS	No	Hobby plan

Correct as of October 2026, based on the vendors’ websites, pricing pages and repositories – check the current terms before you choose.

Who should use a headless CMS?

A headless CMS is most useful in a few specific situations:

Developers and technical teams

The team can use its preferred languages and frameworks, work with version control and build exactly the front end the project needs.

Content creators and marketers

Editors focus on content, and the front end takes care of distributing it to many channels. The condition: someone has to design the panel, fields and preview well, otherwise the work will be harder than in WordPress.

Multichannel publishing

Companies that publish the same content on a website, in mobile apps, on IoT devices or in kiosks use a single data source instead of copying content between systems.

Scalability and performance

The front end and the CMS scale independently. With statically generated or heavily cached pages, traffic is handled mainly by the CDN, not the CMS server.

Internationalisation and localisation

Multilingual sites manage translations within one content model. Just remember that hreflang and the structure of language URLs are the front end’s job.

Internet of Things (IoT) and smart devices

Content from one CMS can go to digital signage screens, smart devices and other channels that aren’t websites.

Do I need a headless CMS? When it’s worth it and when it isn’t

Imagine you run a small business, a blog or a local service website. Is it worth building it on a headless CMS? In my opinion, in most such cases it isn’t. The answer does, however, depend on your needs, your team and your budget.

Headless makes sense when:

• the same content goes to several channels (website, app, shop, screens),
• you have a team of developers who will maintain the front end and take care of technical SEO,
• the site is large, multilingual or has a complex content model,
• the app is being built in Next.js or another framework anyway, and the marketing content is meant to be part of it.

Headless usually doesn’t make sense when:

• you have a company website, a blog or a local business page and no developer to hand,
• the editorial team needs a simple preview and independence without technical support,
• the only reason for the change is a ‘faster site’ – it’s usually cheaper to improve the current one,
• the budget doesn’t cover maintaining two layers and building SEO features.

If, after reading this, you decide headless doesn’t fit your needs, a proven traditional CMS will still be a good choice.

FAQ – common questions about headless CMS

What is a headless CMS in one sentence?

It’s a content management system without its own presentation layer that serves content through an API, while a separate front end builds the website or app.

Is a headless CMS better for SEO?

Not in itself. Google evaluates the page the front end generates, not the CMS. A well-implemented headless setup (SSG/SSR, complete meta tags, sitemaps, redirects, good Core Web Vitals) can be very good for SEO. A badly implemented one – with content rendered only in the browser – can lose visibility.

Does Google index sites built with React or Next.js?

Yes – Google renders JavaScript in a Chromium browser. Even so, Google itself recommends server-side rendering or pre-rendering, because it’s faster and also works for bots that don’t run JavaScript.

Can WordPress be a headless CMS?

Yes. WordPress has a built-in REST API, and the WPGraphQL plugin adds a GraphQL API. Remember that you then have to carry the meta tags and redirects from your SEO plugins over to the front end yourself.

What should I watch out for when moving to a headless CMS, SEO-wise?

Keeping the URLs or having a complete 301 redirect map, meta tags and canonicals in the HTML from the server, real 404 status codes, the XML sitemap and a noindex left over from the test environment. Before switching the domain, it’s worth comparing a crawl of the old and the new version.

Is a headless CMS free?

Some are: Strapi (Community Edition) and Payload are open source under the MIT licence, and Sanity, Contentful, Storyblok and Hygraph have free plans with limits. On top of that come hosting costs and – above all – developer time for the front end.