Most headless WordPress content assumes the frontend is React or Next.js. 84EM’s production stack pairs headless WordPress with Hugo instead: a static site generator that produces plain HTML at build time, with no client runtime, run for directory sites where content is read far more often than it changes.
What is headless WordPress, and should you use it?
Headless WordPress means using WordPress purely as a content backend, exposed through its REST API, while a separate system builds and serves the actual frontend. It’s worth it when performance, security, or scale matter more than the convenience of WordPress’s own templating and page builders, and not worth it for a standard site where traditional WordPress with good caching already performs fine.
Headless vs traditional WordPress
Decoupling pays off for high-traffic, content-heavy, or multi-channel sites. It costs you the built-in convenience of WordPress themes and page builders, and adds real SEO and GEO work that traditional WordPress handles for free.
See headless vs traditional WordPress for the honest tradeoff.
The WordPress REST API as your backend
WordPress’s REST API has shipped in core since WordPress 4.7, exposing posts, pages, taxonomies, and users as JSON at /wp-json/. Real projects usually need to shape it further: custom fields, custom endpoints, and a real auth strategy for anything beyond public content.
See the WordPress REST API as a headless backend for what that looks like.
Hugo as the frontend
Hugo generates static HTML at build time, with no JavaScript runtime required to render a page. WordPress stays the editor, since Hugo has no CMS UI at all, and a build gets triggered whenever content changes.
See Hugo as a headless WordPress frontend for why that pairing works.
Multi-tenant and directory sites
One WordPress backend can serve multiple niche directories, each with its own static Hugo frontend and its own scoped Meilisearch search index, without multiplying backend infrastructure per site.
See multi-tenant directory sites on headless WordPress for the pattern 84EM runs in production.
The tradeoffs
Headless means maintaining two stacks instead of one: a WordPress backend and a separate frontend build and deploy process, each with its own dependencies and its own things that can break. SEO and GEO work that a WordPress theme and SEO plugin handle automatically (structured data, sitemaps, meta tags) has to be rebuilt on the new frontend. None of that is a reason to avoid headless when the performance and scale case is real, but it’s real cost, not a free upgrade.
How 84EM builds it
84EM runs headless WordPress with Hugo in production, including Directory Sites, a multi-tenant platform running multiple niche directories off one shared backend, and the architecture documented in building a high-performance directory with headless WordPress and Hugo. See custom web development to talk about whether this stack fits your project.
