A client rang me in 2021 — property firm, decent budget, had just fired their previous agency. The brief was simple: rebuild their listings portal. Their outgoing dev had spent eight months scaffolding a bespoke Next.js application. Looked brilliant in demos. Couldn't be updated by a single person on their team without a pull request and a deployment pipeline. The estate agent managing the listings was using a Google Sheet as a workaround.
I rebuilt it in WordPress withAdvanced Custom Fields Proin about six weeks. They've been managing it themselves ever since.
That story isn't an argument against Next.js. It's an argument against choosing a tool before you've understood the problem. I've done the reverse too — handed a client a WordPress multisite when they needed a proper React-driven application, and watched it creak under the pressure eighteen months later.
After building 12,000+ sites atSeahawk Media, I've stopped caring about which framework "wins." I care about which one ships, performs, and doesn't come back to haunt you at 11pm on a Sunday.
---
The Honest State of Both Technologies Right Now
WordPress powers somewhere north of 43% of the entire web. That number gets thrown around so often it's lost meaning, but sit with it for a second. Forty-three percent. That's not legacy inertia — that's network effect, plugin ecosystem, hosting infrastructure, and two decades of institutional knowledge baked into every shared server on the planet.
Next.js, meanwhile, has become the dominant React framework for production applications. Vercel's 2023 usage data showed it processing hundreds of billions of requests a month. The App Router introduced in Next.js 13 changed how people think about server components — and yes, it also broke a lot of tutorials published before 2023, which is still causing confusion in Discord servers everywhere.
Here's the thing though: these two technologies aren't really competitors in the way Twitter arguments make them seem. WordPress is a CMS with a theme layer. Next.js is a React framework with optional CMS integration. The Venn diagram of what they're actually good at has very little overlap once you get specific about requirements.
---
Where WordPress Is Genuinely Unbeatable
Content-Heavy Sites Managed by Non-Developers
I'll be blunt. If your client has a marketing team, a content manager, oranyonewho needs to publish without touching code — WordPress is almost always the correct answer. The Gutenberg editor, love it or loathe it (I've had a complicated relationship with it since 2018), gives non-technical users a block-based editing experience that actually works.
Nothing in the React ecosystem comes close to WordPress's editorial experience out of the box. Sanity.io has a beautiful studio, Contentful is solid for structured content — but neither has the plugin ecosystem or the search-engine familiarity that WordPress has. Your average marketing hire has used WordPress before. They haven't used a headless CMS.
Plugin Ecosystem Depth
WooCommerce, Yoast, Gravity Forms, WP Rocket, ACF Pro. These aren't just plugins — they're entire platforms with their own ecosystems. When Seahawk does an e-commerce project for a client with a modest catalogue (say, under 5,000 SKUs), WooCommerce paired with a decent hosting setup onKinstaor WP Engine handles it fine. We're talking sub-2-second load times after caching, full stock management, abandoned cart recovery, Stripe integration — all configured in an afternoon.
Replicating that functionality in a custom Next.js build with Shopify or a headless commerce layer? You're looking at weeks of development time and ongoing maintenance costs that most SME clients cannot justify.
Budget and Timeline Realities
Honestly, most projects don't have the budget for a bespoke React application. A well-built WordPress site with a premium theme like Kadence or Blocksy, ACF for custom data structures, and WP Rocket for performance can be delivered in two to four weeks and maintained by almost anyone. That's not a limitation — that's pragmatism.
---
Where Next.js Actually Earns Its Complexity
Interactivity and Application Logic
Back in 2022, Seahawk had a fintech project — a dashboard for a credit analytics firm. Real-time data feeds, complex filtering, role-based access control, API integrations with three different data providers. I looked at headless WordPress for about two hours before admitting it was the wrong tool entirely. We built it in Next.js with NextAuth.js for authentication and React Query for data fetching. It's still running, still fast, and the codebase is something the client's internal team can actually contribute to.
WordPress can technically do application-like things. But every time I've tried to push it into genuinely dynamic territory — think multi-step forms with conditional logic feeding into external APIs, real-time dashboards, anything requiring fine-grained client-side state — I've ended up fighting against the architecture rather than working with it.
Performance at Scale Without Plugin Dependency
Next.js with Static Site Generation (SSG) or Incremental Static Regeneration (ISR) can produce pages that are almost embarrassingly fast. No caching plugins required. No WP Rocket configuration dials. The pages are just... static HTML with hydration where you need it.
Vercel's documentation on ISRexplains the mechanism well, but the practical implication is this: a Next.js site for a news publication with 50,000 articles can revalidate individual pages on a schedule without rebuilding the entire site. That's genuinely powerful and something WordPress can only approximate through fragment caching.
Developer Experience and Team Composition
If you're an agency with a React-native development team, WordPress development has a real learning curve that often gets underestimated. PHP, the WordPress template hierarchy, hook architecture, thefunctions.phprabbit hole — it's not hard, but itisdifferent. I've hired talented JS developers who looked at a WordPress theme codebase and felt lost for the first two weeks.
Conversely, if your team lives in TypeScript and React, a Next.js project with a headless CMS like Contentful or Sanity is a more comfortable environment. The code is testable, the types are explicit, and the deployment workflow via Vercel or Netlify is genuinely good.
---
The Headless WordPress Middle Ground (And Its Actual Problems)
A lot of agencies have landed on "headless WordPress" as a compromise — WordPress as the CMS backend, Next.js as the frontend. The pitch sounds perfect. Editorial team keeps their familiar interface; developers get a modern frontend stack.
In practice? It's genuinely useful in specific situations and a genuine headache in others.
Thegoodcases:
- Large publishing platforms where editorial workflow is non-negotiable but frontend performance is also a hard requirement
- Organisations already invested in WordPress infrastructure who want to modernise the frontend without retraining content teams
- Sites with complex content relationships that benefit from ACF's data modelling but need React for the display layer
Theactual problems:
- WPGraphQLis excellent, but debugging GraphQL query performance in a WordPress context is painful. You're adding a layer of complexity that can bite you.
- Preview functionality for editors — seeing a draft post on the Next.js frontend — is a constant source of bugs. I've wasted days on this across multiple projects.
- Hosting two separate systems means two separate points of failure, two sets of infrastructure costs, and two deployment pipelines to maintain.
- Real-time features are still awkward. You're not getting WebSockets out of a WordPress REST API without significant additional work.
Headless WordPress isn't a magic middle ground. It's a third option with its own trade-offs, and it only makes sense when the specific requirements genuinely justify the complexity.
---
How I Actually Make the Decision (My Real Checklist)
After enough projects, I've distilled this down to a quick set of questions I ask before the second client call.
Lean toward WordPress when:
- The client or their team needs to manage content independently
- The project is primarily content and marketing pages (even complex ones)
- Budget is under £20K and timeline is under eight weeks
- E-commerce is needed but catalogue is under ~10,000 products
- The client is already on WordPress and migrating serves no real purpose
Lean toward Next.js when:
- The project has significant interactive or application-like requirements
- The team is primarily JS/React developers
- You need fine-grained control over rendering strategy (SSG, SSR, ISR per-route)
- The frontend design system is bespoke and React-component-driven
- There's a genuine reason to integrate with a modern headless CMS like Sanity or Contentful
- Long-term, the client wants to own and extend the frontend themselves with in-house JS developers
And a fewred flagsthat should make you pause regardless of which direction you're leaning:
- A client demanding Next.js because they read it's "more modern" — that's not a requirement
- Choosing WordPress because "it's easier" when the project genuinely needs application logic
- Anyone using the phrase "future-proof" as a justification without articulating what the future actually requires
---
Performance: Let's Use Real Numbers
This is where the conversation often goes wrong. People throw Lighthouse scores around like they're the whole story.
A well-optimised WordPress site — decent hosting, WP Rocket or FlyingPress, WebP images, a properly built theme — routinely scores 90+ on PageSpeed Insights. Seahawk has delivered WordPress sites at 95+ consistently. It's not magic; it's just proper configuration.
A badly configured Next.js app with client-side data fetching everywhere, unoptimised images, and no proper caching strategy will score in the 50s. I've seen it.
The gap between a "fast WordPress site" and a "fast Next.js site" is much narrower than the framework evangelists suggest.Google's own Core Web Vitals researchshows that origin technology matters far less than implementation quality. The bottlenecks in most poorly performing sites are images, render-blocking resources, and server response times — none of which are inherently WordPress or Next.js problems.
What Next.js does offer, genuinely, ismore controlover performance. You can make precise decisions per-route about how data is fetched and when pages are rendered. But control only helps you if you exercise it correctly.
---
SEO: WordPress Has the Ecosystem Advantage, Not the Inherent Advantage
Here's a misconception I have to correct regularly: WordPress is not inherently better for SEO. Next.js apps with proper server-side rendering are fully crawlable by Google. The<Head>component, sitemap generation vianext-sitemap, structured data via JSON-LD — it's all achievable.
What WordPress has is Yoast SEO or Rank Math, which give non-technical users a visual interface for managing meta titles, descriptions, canonical URLs, and schema markup. That's an editorial workflow advantage, not a technical one.
If the site will be managed by developers who understand meta tags and structured data, Next.js SEO is no harder to implement. If the site needs an SEO consultant or marketing manager to adjust page titles without filing a ticket — give them WordPress.
---
FAQ
Isn't WordPress old and getting replaced by modern frameworks?
WordPress has been "getting replaced" since at least 2014, when I first started hearing the argument seriously. It hasn't happened and I don't expect it to. The question isn't whether WordPress is modern — it's whether it solves the problem you have. For a huge percentage of websites, it does. Automattic continues investing heavily in Gutenberg and the Full Site Editing experience. It's evolving, just not in ways that make Twitter feeds excited.
Can you use WordPress as a backend with a React frontend?
Yes, this is headless WordPress, and I covered the trade-offs above. The short version: use WPGraphQL or the REST API to serve content, build your frontend in Next.js. It works. It also adds complexity. Only do it if the requirements actually demand it, not because it sounds architecturally interesting.
How long does a Next.js site take to build compared to WordPress?
Genuinely depends on scope, but for a comparable marketing site, Next.js typically takes 40–60% longer to build for the initial delivery. You're writing components from scratch, setting up a design system, integrating a CMS, configuring deployment. WordPress with a premium theme and ACF gets you much further, faster. Where Next.js pays back the time investment is in long-term scalability and developer ergonomics — provided the team composition justifies it.
What about Astro, Remix, or other frameworks?
Worth knowing about. Astro in particular is interesting for content-heavy static sites and I've been experimenting with it for smaller projects at Seahawk. Remix has a compelling data loading model. But neither has the ecosystem maturity or client familiarity of WordPress, or the enterprise adoption of Next.js. For most agency decisions right now, it's still a WordPress-or-Next.js call with everything else as a niche consideration.
Should I always recommend the "better" technical choice to clients?
No. The best technical choice that a client's team cannot maintain is worse than the second-best technical choice they can actually use. I've learned this the hard way more than once. Ship the thing that works for the humans involved, not just the architecture diagram.
---
The actual skill isn't knowing WordPress or knowing Next.js. It's knowing when to reach for each one — and being honest enough with yourself and your clients to make that call based on their reality, not your preferences.
That property client from 2021? Still on WordPress. Still managing their own listings. No Sunday-night phone calls from me.