A headless CMS is a content management system that stores and organises your content but does not decide how it looks on the page. Instead of producing finished web pages itself, it hands the raw content (text, images, prices, metadata) to a separate front end through an API, and that front end builds what visitors see.
How a headless CMS works
A traditional content management system such as standard WordPress does two jobs at once: your team edits pages in the admin area, and the same software turns those pages into HTML using a theme. A headless set-up splits the two. The CMS becomes a content store with an editing screen, and a separate application, often built in a JavaScript framework such as Next.js, Nuxt or Astro, requests the content and assembles the pages.
The request usually travels through a REST API or a GraphQL endpoint. Products built to be headless from the start include Contentful, Sanity, Storyblok and Strapi. WordPress can also run headless, keeping its familiar editor while a separate front end draws content from it.
The front end can produce pages in three broad ways: render them on the server for each request, build them in advance as static files, or send a nearly empty page and let the browser fetch and draw everything. The first two give search engines finished HTML. The third is where most SEO trouble starts.
Why it matters
Headless suits some businesses well. A retailer feeding the same product content to a website, an app and in-store screens gains a lot from keeping one content source. A large publisher may want a front end its developers fully control, with strict performance budgets.
For most UK small and medium businesses the trade-off is less attractive. Everything a traditional CMS and its plugins did quietly now has to be built and maintained by a developer: title tags, meta descriptions, canonical tags, XML sitemaps, redirects, structured data, image resizing, preview of unpublished pages and form handling. You also run and pay for two systems instead of one, and editing small things can mean waiting for a developer.
Search visibility depends on how the front end renders. Google can process JavaScript, but rendering happens in a queue and can fail on timeouts or blocked resources, and many AI crawlers do not run JavaScript at all. A page whose content and links only exist after scripts run is a risk you can avoid. Server-side rendering or static generation removes most of it.
Common mistakes
- Choosing headless for speed when the real problem was a heavy theme or slow hosting that could be fixed for far less.
- Rendering in the browser only, so crawlers see an empty shell with no headings, text or internal links.
- Losing the SEO plugin’s output in the move: no canonicals, no sitemap, every page sharing one title.
- Forgetting redirects from the old URLs when the new front end changes the URL pattern.
- Leaving the CMS’s own domain or preview URLs open to crawling, creating duplicate copies of every page.
- Building a front end that only one freelance developer understands, so every small change waits on them.
How to act on it
Start with the problem you want to solve. If it is speed, editing comfort or design freedom, compare the cost of a headless rebuild with a lighter theme, better hosting or a cleaner template. If you do go headless, write the SEO requirements into the specification before development starts, and check a staging build page by page: view the raw source, run URL Inspection in Search Console, and crawl with JavaScript rendering both on and off to see what changes.
Whether a rebuild is worth it at all is a judgement I make with clients as part of a website redesign, where the existing content, URLs and rankings are mapped before anyone picks a technology.