I get some version of this question from prospective clients more often than you’d expect, usually phrased carefully, like they’re worried they’ll offend me by asking it: “Is WordPress even still relevant, or should we be building this in something like Next.js instead?” It’s a fair question, and it deserves a proper answer instead of a defensive one, so I want to actually walk through it in detail rather than give the usual one-line agency pitch.
Where the critics genuinely have a point
If you’re building a product — a SaaS dashboard, anything with real-time collaborative features, an application with complex client-side state that needs to feel like a native app rather than a document you’re reading — WordPress is the wrong tool, and honestly it always has been. That’s not a new criticism, and it’s not one I’d argue against. Meta-frameworks like Next.js and Nuxt handle that category of problem meaningfully better, with proper server actions, edge-ready rendering strategies, and a component model that fits how modern interactive applications actually get built.
I use these frameworks myself. RenameSEO, the image SEO tool I’m building right now, runs on Next.js with Supabase and Cloudflare R2, kept entirely within free-tier limits. Slotu, the salon booking and queue management platform I scoped out, is built the same way — Next.js, Supabase, WhatsApp Business API integration for automated reminders, deployed on Vercel. It would be genuinely silly to try to force either of those into WordPress. The admin-ajax bottleneck alone, where every single AJAX request on a WordPress site routes through one PHP file regardless of what it’s actually doing, becomes a real performance ceiling the moment you’re handling any meaningful amount of interactive, logged-in user activity. WordPress was never designed around that pattern and it shows under load.
Where WordPress still wins, and it isn’t close
Content-driven business sites are a different category of problem entirely, and this is where I think a lot of the “WordPress is dying” commentary loses the plot. A home builder who wants to add a completed project to their portfolio without calling their developer. A law firm’s receptionist updating office hours around a holiday. A restaurant changing a seasonal menu every few weeks without needing anyone technical involved. That’s the overwhelming majority of what small and mid-sized businesses actually need from a website, and WordPress’s content editing experience — even with all its long-documented rough edges — is still genuinely unmatched at handing real editorial control back to a non-technical client.
Take the DK Total Homes site I built, which has a scroll-hijacking portfolio slider, a curtain reveal intro animation, and a fairly involved ACF flexible content setup behind the scenes. The client’s team updates their own project gallery every month without touching a line of code or calling me. Try replicating that hand-off experience with a custom Next.js build sitting on top of a headless CMS, for a client who has never heard the word “headless” in their life and has no interest in learning what it means. The technical elegance of a headless architecture means nothing if the person who actually needs to update the site every week finds it more intimidating than the old system it replaced.
The part that’s actually changing isn’t the platform, it’s the craft around it
Nobody serious is hand-building WordPress sites the way we did five or six years ago, dropping in three different page builder plugins and hoping they don’t conflict. The stack I use now leans on ACF flexible content or native meta boxes depending on what’s already established in a given project, AI-assisted development for the repetitive scaffolding work, proper child themes instead of duct-taped visual builders, and a genuine performance discipline around Core Web Vitals that simply wasn’t standard practice a few years ago. The platform underneath is the same one it’s always been. The craft applied to it has gotten considerably sharper, partly because the tools available to build with it have gotten better, and partly because client expectations around site speed and mobile experience have gone up.
A framework for actually deciding, instead of a platform war
When a prospective client asks me this question now, I don’t default to defending WordPress. I ask what the site actually needs to do. If the answer is “represent our business, let our team publish content, generate leads, rank in local search,” WordPress remains the pragmatic, cost-effective choice, and building something custom in a meta-framework for that use case is usually solving a problem the client doesn’t have. If the answer involves complex application logic, real-time data, or a product experience rather than a content experience, that’s a different conversation entirely, and I’ll say so plainly even if it means recommending a stack I don’t personally build agency sites in.
So no, WordPress isn’t dying, and the data backing up claims that it is usually conflates two very different categories of website that never should have been competing for the same use case in the first place. It’s just no longer the reflexive default answer to every kind of website, which honestly it never should have been to begin with.
