← Headless WordPress with Hugo
How does WordPress work as a headless backend?
The REST API, built into WordPress core and available at /wp-json/ on every install, exposes posts, pages, taxonomies, users, and meta as JSON. A headless frontend queries that API instead of rendering WordPress’s own templates, using WordPress purely as the content store and admin interface.
What /wp-json/ gives you out of the box
WordPress’s REST API content endpoints have shipped in core since WordPress 4.7. Out of the box, that means read access to posts, pages, custom post types (once registered for REST), categories, tags, users, and comments, all as structured JSON, no plugin required. For a straightforward content site, the default endpoints alone can be enough to feed a frontend.
Shaping the API
Real projects usually need more than the defaults. Custom fields (whether stored as post meta or through a framework like ACF) don’t appear in REST responses automatically; they need to be registered with register_rest_field or exposed through the plugin that manages them. Custom endpoints make sense when a frontend needs data shaped differently than WordPress’s default schema, or when several related pieces of data should come back in one request instead of several. Authentication matters too: public content needs no auth, but anything else (draft previews, submission workflows, admin actions) needs a real auth strategy, not just an open endpoint.
REST vs GraphQL for headless
REST is what ships in core, works immediately, and is what most WordPress hosting and caching assumes. GraphQL (via a plugin like WPGraphQL) lets a frontend request exactly the fields it needs in a single query instead of multiple REST round-trips, which can matter for a frontend with complex, deeply nested data needs. For most content-driven sites, REST’s simplicity and zero-additional-plugin footprint wins. GraphQL earns its added complexity when the frontend’s data shape is complex enough that REST would mean stitching together many requests.
Feeding a static build
For a statically-generated frontend (Hugo, for example), the API gets queried at build time, not per visitor request: the build process pulls content, generates pages, and the API isn’t touched again until the next build. That means the API’s performance only matters during builds, not under visitor traffic, which is one of the reasons a static frontend scales so differently than a dynamic one.
See Hugo as a headless WordPress frontend for how that build-time fetch actually works.
Talk to 84EM about a custom WordPress REST API integration if your headless build needs more than the default endpoints.
