WordPress to Next.js migration: a real client case study

The brief was unusual. "We love WordPress. Don't take it away from our editors. But the site is slow and our ads are losing revenue."

Translation: keep the back-end, swap the front-end. Headless WordPress with Next.js. Here is how it went.

The starting point

• WordPress 6.5 with a custom theme built in 2019
• ~1,200 posts, growing by 8/week
• LCP on mobile: 3.6s
• Ad RPM: $4.20
• Editorial team of 4 people who had used WordPress for years

The plan

1. Stand up a Next.js 15 front-end on Vercel
2. Keep WordPress as the editor (no migration of posts)
3. Use WPGraphQL to read content
4. ISR for article pages (1 hour revalidate)
5. On-demand revalidation triggered by WordPress on publish
6. Migrate ad slots one by one

The architecture

WordPress (CMS)  ──WPGraphQL──>  Next.js (Vercel)  ──CDN──>  Reader
        │
        └──webhook──> /api/revalidate?slug=X

The webhook took 30 minutes to set up. Free, native, fast.

What I'd warn you about

1. Image optimization is a trap

WordPress's wp-content/uploads folder is 12GB. You do not want to proxy those through next/image on every request. Solution: stream them to Bunny CDN at build time, store the new URL in the post meta, serve via <Image src={bunnyUrl} />.

2. Comments

If the site has comments, you have a choice: disable, move to Disqus, or build a thin Next.js comment UI that POSTs to the WP REST API. We picked Disqus. Editorial breathed easier.

3. Search

The WordPress search is gone (you are not querying WP for every keystroke). We added Algolia, indexed via a webhook. $25/month, 200ms search across 1,200 posts, perfect.

4. Redirects

The old theme had quirky URL structures. We exported them to a Next.js redirects() array and deployed in a single commit. Zero 404s.

The numbers after 30 days

• Mobile LCP: 3.6s → 0.9s
• Lighthouse perf: 62 → 98
• Ad RPM: $4.20 → $5.92 (+41%)
• Editorial team: unchanged workflow, zero re-training
• Hosting cost: $220/mo → $80/mo (smaller WordPress server, Vercel free tier worked for traffic)

When NOT to do this

Headless WordPress is wrong for:

• Sites under 100 pages — overhead is not worth it.
• Plugin-heavy sites — anything that injects HTML into the page (popups, exit intents, related posts) needs to be rebuilt in Next.js. Budget for it.
• Sites planning to leave WordPress entirely — go full Next.js + Sanity/Payload, do not bridge.

Want one done for your site?

I have shipped 14 of these. The architecture is repeatable. If your WordPress site is slow but your editors love it, drop me a message — I will give you an honest yes/no in a 15-minute call.