WordPress
What is headless WordPress? Definition, trade-offs, and when to use it
Headless WordPress is a setup in which WordPress runs only as a content backend — editors write in wp-admin and posts live in the WordPress database — while a separate front end, usually a JavaScript framework such as Next.js or Astro, fetches that content through the REST API or GraphQL and renders the pages visitors actually see.
Last reviewed August 29, 2026 · 6 min read
On this page
The word headless is literal: the "head" is the theme layer that turns stored content into HTML, and a headless install has removed it. WordPress still does everything it did before the theme was involved — users, roles, the editor, media, revisions, taxonomies — and stops doing everything after it.
How headless WordPress works
A conventional WordPress site is one deployment. A headless one is two.
The first is WordPress itself, typically on a subdomain like cms.example.com. It exposes its content through the REST API, which has shipped in core since version 4.7 — /wp-json/wp/v2/posts returns a JSON list of posts, /wp-json/wp/v2/posts/{id} a single one, and the same shape exists for pages, media, categories, tags and users. Most headless teams add WPGraphQL for a typed query layer, but the REST API is enough for a blog.
The second deployment is the front end on the public domain. It fetches from the first and renders HTML. When it fetches is the main architectural decision:
- At build time (static generation) — every post becomes a static file when the site deploys. Fastest to serve, but a new post needs a redeploy.
- At request time (server rendering) — the front end asks WordPress on every visit. Always fresh, always slower, and WordPress is now on the hot path.
- In between (incremental regeneration) — the page is static, but after a set window the next visitor triggers a background rebuild. Next.js calls this ISR; it is what most headless blogs settle on, because it gives static speed with a bounded staleness window.
Everything the theme used to provide for free is now the front end's job: routing, archive pages, pagination, search, comments, forms, redirects, the <head> — and preview, which is the feature editors miss first and developers underestimate most.
What you gain — and what you pay for
| You gain | You pay for |
|---|---|
| Full control of the front end: your framework, your design system, your build pipeline | Two systems to host, deploy, monitor and upgrade instead of one |
| wp-admin off the public domain, which shrinks the attack surface visitors can reach | Plugins that render on the front end — SEO output, shortcodes, block styles, forms — stop working unless you rebuild them |
| One content source feeding a website, an app, a newsletter, a kiosk | Editorial preview, scheduled publishing and "view post" links become engineering work |
| A developer workflow that fits git and CI rather than FTP and a theme editor | Every feature a WordPress blog gets from a theme for free costs a sprint |
The honest summary: headless trades operational simplicity for front-end control. That is a good trade for a team that already has developers and a design system, and a bad one for a business whose blog is run by the marketing manager on Thursday afternoons.
Headless WordPress and SEO
Nothing about headless is bad for SEO, but three things that WordPress used to handle now have to be handled deliberately.
Rendering. Google renders JavaScript, but a page that only exists after client-side JavaScript runs is indexed later and less reliably than one that arrives as HTML. The safe pattern for content sites is to produce HTML at build or request time — static generation, server rendering, or ISR — and leave client-side rendering to interactive widgets. This is the recommendation in Google's own rendering guidance, and it is the default in every major framework, so the risk is mostly a team choosing a client-only architecture for a blog.
Metadata. SEO plugins write titles, descriptions, canonicals and structured data into a theme's <head>. With no theme, that output goes nowhere. Some plugins expose their generated head through the REST API so the front end can re-emit it; otherwise the front end builds every tag itself from the post fields. Either way, "install an SEO plugin" stops being a complete answer.
Links and media. WordPress stores absolute URLs. Links inside post content point at the CMS host — cms.example.com/some-post — unless something rewrites them to the public domain, and images are served from the CMS host unless you put a CDN or an image pipeline in front of them. Both are small; both bite every headless blog once.
When to use it — and when not to
Use headless WordPress when the front end is the point: you have a Next.js or Astro site already, a design system to keep, performance targets the theme cannot meet, or more than one surface to feed from the same content. Editors keep the WordPress editing experience they know, and developers get a front end they own.
Do not use it because it sounds modern. A business blog with one editor, a good theme and a caching plugin is faster to run, cheaper to host, and gets features — preview, SEO, forms, comments — for free that a headless build has to earn. The question is not whether headless WordPress is good; it is whether your team will maintain two systems better than one.
How Structura handles this
Structura supports both halves of the decision.
If you keep WordPress as the backend, the plugin runs in headless mode: you tell it that the public website lives on another domain, and from then on internal links in new posts, channel shares and the AI's grounding all use the public URL rather than the CMS host — the exact links-and-media problem above, solved at the source. Posts are still native Gutenberg blocks in your WordPress database, served to your front end through the REST API it already reads.
If you would rather not run WordPress at all, a headless space replaces it. Structura stores the posts itself and serves them from a public read API — sanitized HTML or structured blocks, meta fields, images with dimensions, and JSON-LD delivered out of band — that a Next.js, Astro or custom front end fetches. Three endpoints, no authentication, nothing to host. The API-first CMS page walks through the contract.
Either way the part most headless projects never staff — somebody actually writing the posts — is what Structura automates.
FAQ
Is headless WordPress good for SEO?
It is neutral. Rankings depend on the HTML Google receives, and a headless front end that renders on the server or at build time sends the same HTML a theme would. It becomes bad for SEO only when a team renders on the client alone, forgets the metadata that the SEO plugin used to write, or ships links that point at the CMS subdomain.
Do I still need a WordPress theme?
Technically yes — WordPress refuses to run without an active theme — but it can be an empty one that renders nothing. Some teams keep a minimal theme so that wp-admin's preview and "view post" links have somewhere to go, then redirect visitors from the CMS domain to the public site.
Does headless WordPress make a site faster?
It can, because the front end serves static or cached HTML and never waits for PHP on the public path. But a well-cached conventional WordPress site is also fast, and a badly built headless front end that fetches on every request is slower than both. Speed comes from the rendering strategy, not from the word headless.