Headless WordPress is a setup where WordPress is used only as the editing and storage system, and the public site is rendered by a separate front-end application. The WordPress admin still works the way authors expect — the dashboard, the editor, custom post types, the media library — but visitors never see a WordPress-rendered page. They see a Next.js, Astro, Nuxt, or similar app that pulls content from WordPress through the REST API or WPGraphQL.
The appeal is real. Front-end developers can use modern JavaScript frameworks without fighting the theme system. Pages can be pre-rendered at build time and served from a CDN, which is hard to beat on speed. The same WordPress instance can feed a website, a mobile app, and a digital-signage screen from one editorial workflow.
The complexity is also real. Live preview stops working until you wire it back together. Plugins that hook into the front-end (Yoast's sitemap output, contact-form rendering, comment systems) need replacements or shims. Image handling moves from "WordPress does it" to "you decide which image CDN and how". Editorial workflows that depend on "view post" links become small engineering jobs.
I use headless when a project genuinely benefits from it — heavy editorial sites, multi-channel publishing, or front-ends with design requirements that traditional themes can't meet cleanly. For brochure sites, service businesses, and most marketing sites, a well-built traditional WordPress setup with edge caching and a fast theme is faster to build, cheaper to maintain, and easier to hand off. Headless is a tool for specific problems, not a universal upgrade.