Why We Stopped Building Client Websites on WordPress in 2026

Why We Stopped Building Client Websites on WordPress in 2026

Two years ago, roughly 80% of the client websites we shipped were on WordPress. Today, that number is close to zero. Not because WordPress got worse — it didn't. It's because the requirements businesses have for a website in 2026 changed faster than WordPress's architecture can keep up with.

This isn't a "WordPress is bad" post. It's a breakdown of the actual technical reasons we moved our default stack to Next.js, React, and Node.js — with real numbers, not opinions.

The Core Problem: Request-Time Rendering

WordPress renders every page on request. When a visitor hits a page, the server has to:

1. Bootstrap PHP

2. Query the MySQL database (often multiple times per page — once for the post, once for menus, once per widget, once per active plugin hook)

3. Run every active plugin's logic, whether or not it's relevant to that page

4. Assemble the HTML

5. Send it to the browser

A typical WordPress site with 15–20 active plugins (a conservative number for a business site with forms, SEO tools, caching, and a page builder) can run 40+ database queries on a single page load. Every one of those queries adds latency before the browser even starts rendering.

Next.js takes a fundamentally different approach. With Static Site Generation (SSG) or Incremental Static Regeneration (ISR), pages are built once, ahead of time, and served as pre-rendered HTML from the edge. There's no database query at request time for most pages — the work already happened at build time.

javascript

// Next.js — page is generated once, served instantly, 
// revalidated in the background every 60 seconds
export async function getStaticProps() {
  const data = await fetchPageData();
  return {
    props: { data },
    revalidate: 60,
  };
}

No PHP bootstrap. No live database query. No plugin stack executing on every request. Just a static file served from a CDN edge node, geographically close to the visitor.

The Numbers

We ran Google PageSpeed Insights and WebPageTest against a matched pair of sites we've built — same content, same page count, same business type (a services company with a homepage, service pages, a blog, and a contact form) — one on WordPress with a standard plugin stack, one on Next.js.

The TTFB gap alone is the difference between a page that starts rendering while the visitor is still looking at the search results, versus one they've already started to doubt.

Why This Isn't Just a Performance Story

Speed is the most visible difference, but it's not the only one.

Security surface area. Every WordPress plugin is a separate codebase, maintained by a separate team, with its own update cycle. In 2025 alone, WPScan's vulnerability database logged thousands of new plugin vulnerabilities. A Next.js site with no plugin architecture simply doesn't have that attack surface — there's nothing to exploit at that layer because it doesn't exist.

Maintenance cost. WordPress sites need constant babysitting: core updates, plugin updates, PHP version compatibility, and the inevitable "a plugin update broke the site" support call. A statically-generated Next.js site has no plugins to break. It sits there and works.

Hosting cost at scale. WordPress needs a persistent server running PHP and MySQL around the clock. A Next.js site built with SSG can be served almost entirely from a CDN, which is both cheaper and more resilient under traffic spikes — no database connection limit to hit during a launch day surge.

Where WordPress Still Makes Sense

To be fair, WordPress isn't wrong for every use case. If a client needs a non-technical team updating content constantly, with hundreds of contributors, and doesn't care about shaving milliseconds off load time, WordPress's admin UI and plugin ecosystem are genuinely mature.

But for a typical business website — a company that needs speed, security, and a site that converts visitors into leads — the tradeoffs point clearly toward a modern JavaScript stack. We still build admin panels for clients on our custom stack, but they're purpose-built for that specific business, not a general-purpose CMS carrying the weight of every feature every WordPress user might theoretically need.

Frequently Asked Questions

Is Next.js faster than WordPress? Yes, in almost every real-world benchmark. Next.js sites using Static Site Generation typically load in under 1.5 seconds, compared to 3–6 seconds for a typical WordPress site running a standard plugin stack.

Can a Next.js site have a content management system like WordPress? Yes. Next.js sites can be paired with a headless CMS or a custom-built admin panel, giving non-technical users the ability to edit content without touching code — without carrying WordPress's plugin overhead.

Is WordPress insecure? WordPress core itself is reasonably secure. The risk comes from the plugin ecosystem — each additional plugin adds a new potential vulnerability. A site with 20 active plugins has a meaningfully larger attack surface than a statically-generated site with no plugin architecture at all.

Does switching from WordPress to Next.js hurt SEO? No — if migrated correctly, it typically improves SEO, since Core Web Vitals (a confirmed Google ranking factor) are usually dramatically better on a Next.js build. The migration needs proper 301 redirects and sitemap handling to preserve existing rankings.

We're a small team building custom Next.js and Node.js applications for businesses — full-stack, from admin panels to ecommerce systems. If you're evaluating a rebuild and want an honest technical opinion on what your specific site actually needs, reach out: sajlog.com.