Headless WordPress, Next.js vs Astro 2026: a senior engineer’s decision matrix
Astro 5+ and Next.js 15 sit in the Adopt ring of our Tech Radar Q3 2026. Both shipped to production. Both stable. Both ours to recommend without caveats. The question that lands in client briefs every week, “should we go Astro or Next.js for our headless WordPress front”, reads like a taste question. It is not.
“Going headless is not a fashion choice; it is the moment your team stops paying for the wrong abstraction.”
Lee Robinson, VP DX at Vercel, Frontier 2025 keynote, 2025-09-10
The right framing of the same decision: are you paying for the wrong abstraction with React on a content site, or paying for the wrong abstraction with islands when your product is interactive. The answer depends on what the page actually does, not on which framework had the better keynote this quarter.
TL;DR
- Astro 5+ default for content-heavy sites where Core Web Vitals are tied to revenue.
- Next.js 15 default for application-heavy product UIs with React Server Components and streaming.
- Both can read the same WordPress REST or GraphQL endpoint; the back end does not care.
- Hire for the workload. React (and Next.js) has a larger talent pool in Poland; Astro is a smaller, more selective pool.
- Mixed stacks are valid. Marketing on Astro, dashboard on Next.js, one WordPress origin underneath.
What sits behind the choice
Astro and Next.js solve different problems even though both can render headless WordPress.
Astro 5+ is a multi-page rendering toolkit that defaults to zero JavaScript on the client. Each page is HTML by default. Interactive components are opted in via “islands”. The build output for content sites is small and fast on cold caches. Astro is in our Adopt ring for that reason.
Next.js 15 is a React-first application toolkit. It now ships React 19 Server Components in production, with streaming and selective hydration. On content-heavy pages it is no longer the bundle-penalty default it was a few years ago. It is in our Adopt ring for application-heavy UIs.
The headless WordPress story is the same on both: WordPress is the editorial back end, the front renders from the REST API or GraphQL. The choice is which renderer you trust with which workload.
Decision matrix
| Question | Astro 5+ | Next.js 15 |
|---|---|---|
| Mostly long-form content, blog, marketing | Default | Possible, no longer wrong |
| Authenticated dashboards, complex forms | Possible, more work | Default |
| Heavy real-time UI, websockets | Avoid | Default |
| WooCommerce catalogue, SSR product pages | Both fine | Both fine |
| Large editorial team using WordPress | Both fine | Both fine |
| Small interactive surface area | Astro wins | Next.js works, less optimal |
| Large interactive surface area | Astro fights you | Next.js wins |
| Edge SSR with low TTFB | Both run on Cloudflare Workers | Both run on Cloudflare Workers |
| Hiring senior in Polish market | Smaller pool | Larger pool |
| TypeScript, Tailwind, design tokens | First-class in both | First-class in both |
What the hiring market is telling us
The argument that “React wins because more people know React” is real but reads stale without numbers.
No Fluff Jobs Rynek pracy IT 2025/2026 reports React in 8.4 percent of all IT offers in Poland in 2025 and TypeScript in 9.2 percent. JavaScript on its own appears in 10.9 percent. Astro is not yet a top-15 hard skill keyword in either Polish report.
Just Join IT, Co z tym Eldorado? 2024/2025 shows JavaScript ahead at 11.24 percent of offers, Java at 10.49 percent, AI/ML still small at 0.85 percent but growing fastest in salary terms. Senior B2B medians on JS roles trend in line with the senior median 24360 PLN net per month.
The polemic version: a senior who knows Astro is rarer than a senior who knows Next.js. That is not a reason to default to Next.js. That is a reason to be explicit when you choose Astro and to scope the engagement so two seniors do not both leave at the same time.
Three real scenarios
Scenario one, content-heavy site that still grows
A publisher running WordPress with 3000 articles and 50000 monthly users. Mobile traffic skews older devices. Editorial team needs the WordPress preview-and-publish loop unchanged. Conversion is reading time and email signups.
Choice: Astro 5+. Zero-JS islands keep cold-cache LCP under one second on Moto-G class devices. WordPress stays as the editorial back end. The front rebuilds on publish. Cloudflare Workers serve from the EU edge.
Scenario two, B2B SaaS with a marketing site and a dashboard
A SaaS company running WordPress for marketing and a separate React app for the product. Marketing pages have to rank in organic search and convert; the product dashboard has authenticated state and real-time updates.
Choice: mixed. Astro for the marketing surface, Next.js 15 for the dashboard. They share the same WordPress origin for content, the same Cloudflare Workers deploy pipeline, and the same TypeScript types. Two builds, one stack of knowledge.
Scenario three, headless WooCommerce store with personalised recommendations
A WooCommerce store with 200 products, personalised recommendations, real-time stock, and a checkout flow that talks to multiple payment gateways. Editorial is still WordPress.
Choice: Next.js 15 with React Server Components. Streaming SSR keeps the perceived load fast. Server Components let the catalogue render server-side without flooding the client with JS. WooCommerce REST or Store API on the back. Cloudflare Workers hosts the front.
The polemic part
Defaulting to one framework for everything is a senior-engineer red flag. The buyer who hears “we always use Next.js” is hearing a shop optimised for one tool, not for their problem. The buyer who hears “we always use Astro” is hearing the inverse. A senior team picks for the workload, says why, and writes the decision down.
We have written ours down twice: once in the Tech Radar ring placement, once in the Headless WordPress pillar. When the workload changes, the radar moves and we update both.
Where this fits in the cluster
This article supports the Headless WordPress service pillar. For broader context, see the AI and LLM visibility playbook on how to make any of these front ends actually findable, and the LLMO strategic summary on how that visibility translates into citations from generative engines.
