The StartingUp Summer. We're using this quiet time to map out a dense year and deliver an unvarnished account of it. After showing you how we host our Next.js applications on our own VPS, we're opening the hood of the very site you're reading: a headless WordPress paired with Next.js, with its real advantages and the downsides too often left unsaid.
The site you're reading these lines on isn't a WordPress site like any other. WordPress does exist here, but you'll never see it: it lives on a separate server, serves no page to the public, and has a single mission, managing content. What your browser displays is a Next.js application that fetches this content and stages it. That's the principle of headless: a WordPress "without a head", whose face is rendered by a different technology.
We didn't make this architectural choice on paper: we live with it daily, with its real wins and its real bills. Here's what we'd tell a decision-maker who asked us today whether they should commit to it.
In short: headless WordPress brings stronger security, top-tier performance and total design freedom. In exchange, it demands two applications to maintain, a dev ticket for every new editing block, and a bigger budget than a classic WordPress. The rest of this article breaks down each of these points, as we live them in production.
Headless WordPress, concretely: two applications, two jobs
Concretely, our site is made of two separate applications. On the back end, a WordPress that looks classic enough: editors write their articles in Gutenberg, structured fields are managed with ACF, forms with Gravity Forms. The difference is that it no longer has a public theme: it exposes its content through a GraphQL API (the WPGraphQL plugin). On the front end, a Next.js application (App Router, React, Tailwind CSS) queries this API, renders the pages on the server, and delivers them to the visitor. It all runs in Docker containers in development and deploys reproducibly in production.
Remember the essential point: the content team changes nothing about its habits, it works in the WordPress back office it already knows. It's the visitors who, without knowing it, never touch WordPress again.
The advantages of headless: what you actually gain
Security: WordPress pulled off the front line
Most attacks targeting WordPress go through its public face: a login page scanned in a loop, plugin vulnerabilities exploited through pages served to visitors. In headless, that public face no longer exists. WordPress lives on its own domain, serves only its API, and can be filtered far more strictly than a classic showcase site. To be precise: the attack surface isn't zero, an API stays exposed and updates remain essential. But it's reduced, siloed, and a potential compromise of the back end doesn't take down the site your customers see.
Performance and SEO: server rendering as the foundation
A traditional WordPress builds every page in PHP, often stacking caching plugins to compensate. Here, Next.js generates pages server-side and serves them pre-built, with images automatically resized and converted to modern formats. Search engines receive complete, fast HTML, with no dependence on a stack of optimization plugins. We won't sell you a magic percentage: the gains depend on what you're leaving behind. But server rendering and fine control over every kilobyte delivered form, for a site where SEO traffic is strategic, a foundation no theme setting can match.
Total design freedom, a familiar back office
With the front end being custom code, there's no more theme to work around or builder to coax: animations, layout, interactive components, everything is possible, exactly as on any React application. And because the back end stays a standard WordPress, it keeps its entire ecosystem: that's actually what let us connect it to Claude via MCP to drive content from an AI assistant. The split doesn't close doors on the back-office side, it opens them on the front-end side.
The downsides of headless: what it honestly costs
Two applications to maintain instead of one
This is the entry price, and it doesn't negotiate. Two codebases, two update chains (WordPress core and its extensions on one side, Next.js, React and their dependencies on the other), two deployments, two things to watch at night. A profile able to work on both sides, comfortable in React as much as in the guts of WordPress, is also rarer on the market than a classic WordPress integrator. If your provider disappears, succession is harder to organize.
Every editing block gets paid for twice
Here's the cost that enthusiastic articles about headless systematically leave out. When an editor inserts a block in Gutenberg, WordPress knows how to render it; our front end knows nothing. Every block type has to be re-implemented on the Next.js side. Our content parser works on a whitelist: about fifteen blocks are recognized and carefully rendered (paragraphs, headings, lists, quotes, tables, images, code, YouTube videos), and any block outside that list falls back to a degraded display. Want a gallery, an accordion, a new editing plugin? That's no longer a checkbox, it's a development ticket.
Preview and freshness are no longer a given
In a classic WordPress, "Preview" just works. In headless, previewing a draft, revisions, instantly refreshing an already-cached page: each of these comforts requires dedicated plumbing between the two applications. We had, for instance, to write the mechanism that tells the front end, on every publish, that a given page needs to be regenerated. Nothing insurmountable, but nothing free either: these are days of work to recover what the monolith offered natively.
Who headless is a good fit for, and who it's a bad idea for
| Your situation | Our take |
|---|---|
| A demanding showcase site, a strong brand, custom design | Headless is fully justified: front-end freedom becomes a visible competitive edge |
| Strategic SEO traffic, critical performance | A good candidate: server rendering, optimized images and total control over what's delivered to the browser |
| A small site, a tight budget, a fast launch | A bad idea: a well-run classic WordPress will do better, for a fraction of the cost |
| An editorial team that wants to compose its own layouts independently | A bad idea: every new template or block will go through a developer |
| Content meant to feed several channels (site, app, screens) | Worth studying seriously: a single content API is precisely headless's strength |
The dividing line comes down to one question: who should have control over the form? If the answer is "the editorial team, day to day, with no middleman", headless will frustrate them. If the answer is "the brand, with a level of demand themes can't meet", it will serve them.
Our take: a trade-off, not a trend
Having practiced it under real conditions, our conviction is simple: headless architecture trades operational simplicity for control. We accepted two applications to maintain, a block parser to keep growing, and a preview mechanism to rewire, because the security, performance and design freedom gained in return directly serve what this site needs to accomplish. For other projects, we recommend a classic WordPress without hesitation, and we'll keep doing so.
So be wary of the two symmetrical narratives: the one that presents headless as WordPress's inevitable future, and the one that dismisses it as a developer's whim. It's an architectural trade-off, decided the way all trade-offs are: by looking at what your site needs to do, who will keep it running, and what you're really willing to pay, in euros and in organization, for total control over your showcase.
