← Headless WordPress with Hugo
Why pair Hugo with WordPress?
Because most headless WordPress content assumes a JavaScript frontend, and for content that’s largely read-only (a directory, a marketing site, a content hub), Hugo generates pure static HTML at build time with no client runtime at all. That means no hydration, no JS framework overhead, and hosting costs close to zero.
Build-time HTML vs client-side rendering
A JavaScript frontend (React, Next, or similar) typically renders in the browser or on a server per request, which means a runtime is involved every time a visitor loads a page. Hugo renders once, at build time: the HTML for every page already exists before a single visitor arrives, and serving it is just handing over a static file. For content that doesn’t change on every request, that’s strictly less work happening at the moment a visitor actually loads the page, which is where the speed comes from.
Getting WordPress content into a Hugo build
The build process queries the WordPress REST API, pulls the content that’s changed (or all of it, for a full rebuild), and generates the corresponding static pages. A build gets triggered on publish, update, or delete, commonly through a webhook fired from a WordPress hook like transition_post_status, so a content change in WordPress kicks off a rebuild without anyone running a command by hand.
WordPress stays the editor
Hugo has no admin UI, no login screen, no content editing interface at all, and that’s a feature in this pairing, not a gap. WordPress keeps doing what it’s already good at: the familiar editing interface, media handling, and content workflow that editors already know. Hugo’s only job is turning that content into fast static pages. Nobody has to learn a new CMS to publish content.
Where this stack fits (and where it does not)
It fits content that’s read far more often than it changes: directories, marketing sites, documentation, content hubs where visitors browse and search rather than submit data on every page load. It fits less well where content needs to update in real time between builds, or where the frontend needs highly interactive, stateful features that a static site isn’t built for. 84EM has run this exact pairing in production for a high-performance directory, where WordPress manages listings and Hugo serves the public-facing pages.
See multi-tenant directory sites on headless WordPress for how this pattern extends to running several directory sites off one shared backend.
Talk to 84EM about a headless WordPress and Hugo build if your content fits this pattern.
