Headless WordPress + Next.js
Six publishing platforms on headless WordPress and Next.js
We build and run six content sites on one architecture. Editors write in WordPress, which sits on its own api. subdomain; readers get a Next.js 16 front end that serves static pages, refreshed every 12 hours, through Cloudflare.
The challenge
Editors wanted to keep writing in WordPress. Readers expect fast pages on a phone. And with six sites, every fix has to be designed once and applied everywhere, or it gets done six times, differently.
WordPress is also the fragile part. When its API is slow or returns an error during a build, a naive front end either fails the deploy or publishes empty pages that stay cached for hours.
Our approach
WordPress as an API only
Content lives in WordPress on its own api. subdomain and is read through the REST API. On five of the sites, media under /wp-content is served through the site's own domain, and post HTML is rewritten to match.
Static pages, refreshed every 12 hours
Pages, sitemaps and WordPress requests are cached for 12 hours with incremental static regeneration. On four of the sites the newest 50 posts and every page are prerendered at build, and a revalidation route refreshes the cache on demand.
Surviving a slow WordPress
On four of the sites, requests to WordPress retry server errors and network failures up to five times with exponential backoff, and fail the build loudly instead of publishing empty pages. The others fall back per request.
Alt text that's never missing
A shared transform fills in missing alt text on images inside posts, from the figure caption or the nearest heading. It never overwrites alt text an editor wrote.
Architecture
- Front end
- Next.js 16 App Router, React 19 and Tailwind CSS 4 on every site. Client-side search talks to WordPress through TanStack Query.
- Content
- WordPress REST API (wp/v2). Meta descriptions come from Rank Math's head API with an 8-second timeout, then post meta, then the excerpt.
- Rendering
- Incremental static regeneration with a 12-hour window, build-time prerendering of recent posts on four sites, and an on-demand revalidation route.
- Edge
- Cloudflare in front of every site, serving cached pages, with www redirected to the bare domain.
- SEO plumbing
- Sitemaps generated from WordPress, robots rules, canonical URLs, Article and breadcrumb structured data, and an ads.txt on every site.
- Pinterest domain verification on five of the sites, article Open Graph metadata, and, on four of them, buttons on post images that lead to the site's Pinterest profile.
Readers
Cloudflare
Cached pages at the edge; www to the bare domain
Front end
Next.js 16 on Vercel
Static pages, refreshed every 12 hours
Content
WordPress REST API
On api.<site>, with retries on four sites
Editors
Write and publish in WordPress admin
Where it stands
Six sites, one pattern
The six sites share one rendering model, the same image handling and the same SEO plumbing, so improvements are designed once and applied to each.
Editors keep WordPress
Nobody had to learn a new CMS. Publishing in WordPress reaches the live site within the 12-hour window, or at once through revalidation.
Failures you can see
Where the retry wrapper runs, a WordPress outage fails the deploy instead of shipping empty pages.
Built with
- Next.js 16
- React 19
- Tailwind CSS 4
- TanStack Query
- WordPress REST API
- Rank Math
- Vercel
- Cloudflare
Services involved
Related guides
Have a problem like this one?
A few lines is enough. We'll ask the right questions on the call.
We reply within one working day
By email or WhatsApp, whichever you prefer.
A short call
To understand the goal, the people who'll use it and any deadline.
A written scope and estimate
Before any work starts, so you know what you're agreeing to.
Prefer to talk first?