WordPress or Next.js: how to tell which one your site should be on

Both will serve your pages. Only one of them matches how your site gets used.

Somebody emails me about this most weeks, and almost none of them actually have a problem with WordPress. They have a problem with one page taking four seconds to open on a phone, or with a renewal invoice for plugins nobody remembers approving, or with a developer who left and took the only copy of the theme with them. Those are three different problems and exactly one of them is solved by changing framework.

So this is the comparison I run before I quote anyone, in the order I run it.

What you are actually choosing

WordPress is a content management system with a front end attached. Next.js is a front end with no content management system attached. Everything else in this comparison follows from that one asymmetry.

On WordPress, a single install does three jobs at once: it stores your content, renders your pages, and absorbs your traffic. Someone opening a product page starts a PHP process that loads the theme, runs whatever your active plugins have hooked into that request, queries MySQL a few dozen times, and assembles the HTML while the visitor waits.

On Next.js, most of that already happened. The page was rendered when the content last changed, and the visitor is handed a file that was sitting on a CDN before they arrived. The content itself lives somewhere else: a headless CMS, a database, Markdown in the repository, whatever you point it at.

Which makes the real question something other than speed. It is whether you want the system that stores your content to also be the system that takes the hit when traffic arrives. On a site nobody visits, that coupling costs nothing at all. On a site with a publishing schedule and an audience, it is the thing that eventually gives.

Where WordPress actually stands

Numbers first, because this argument usually runs on feelings.

W3Techs put WordPress at 40.7 percent of all websites on 7 September 2026, and at 58.9 percent of the sites where the content management system is known. Nothing else is close to that. Any pitch that opens with WordPress being dead can be dismissed on that line alone, and you should be a little suspicious of whoever made it.

The direction is more interesting than the level. WordPress sat at 43.2 percent in December 2025 and 41.9 percent by late May 2026: six consecutive months of decline, and the first run like that in years. That is a slow drift, not a collapse.

The plugin bill nobody quotes

This is the part of the comparison that decides most of it, and it is the part that never appears in a quote.

Every WordPress feature past the basics arrives as somebody else's code, running inside your request cycle with full access to your database. That is the deal, and it is a good one. It is why WordPress can do almost anything in an afternoon and why a non-technical owner can add a booking system without hiring anyone.

The invoice for it arrives in three parts.

Security

Patchstack, which maintains a vulnerability database for the WordPress ecosystem, recorded 11,334 new vulnerabilities across 2025. That is 42 percent more than the year before. Of those, 91 percent were found in plugins and 9 percent in themes. WordPress core accounted for six, and all six were low priority.

Of that total, 1,966 were high severity, which the report puts at a 113 percent rise year on year and more high severity findings than the previous two years combined. Roughly half of the high impact ones are exploited within a day of disclosure, and for the heavily targeted ones the weighted median time to first exploit is five hours.

The figure I find hardest to argue with is a quieter one. 46 percent of vulnerabilities were not fixed in time for public disclosure. Nearly half the time, the problem becomes public before the fix exists, and your automatic updates have nothing to install.

None of this makes WordPress insecure. Core is in good shape and the numbers say so. What it makes clear is that your exposure is a list you assembled yourself, that updates itself on your live site, and that nobody on your side has read.

Weight

The second part of the bill is what all that code puts on the page. A plugin providing one shortcode you use on one page will usually load its stylesheet and its script everywhere, because it has no dependable way of knowing which page you used it on. Multiply by twenty and your homepage is carrying the cost of features it does not have.

You can fight this. There are plugins that unload other plugins on a per-URL basis, which is exactly as sturdy an arrangement as it sounds.

Ownership

The third part is the one people notice last. In October 2024, WP Engine was cut off from WordPress.org, and days later Advanced Custom Fields, a plugin a very large number of sites are built on, was forked into Secure Custom Fields and pushed out through the official update channel. Sites running automatic updates changed plugin without anybody on those sites deciding to.

Take whatever position you like on who was in the right. The lesson for an owner is narrow and survives either view: a dependency you do not control can change hands, and change on your production site, without you being asked.

Next.js does not free you from dependencies. It changes what one is. An npm package is pinned in a lockfile, upgraded when somebody decides to upgrade it, and read in a diff before it reaches production. Nothing installs itself into a running site overnight.

The speed ceiling

Google scores three numbers, taken from real visits and read at the 75th percentile. Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, Cumulative Layout Shift under 0.1. All three have to pass for the page to count as good.

A well cached WordPress site can pass all three. Plenty of them do. If yours does, the speed argument for moving has already gone and you should ignore anyone who keeps making it.

The difference is what passing costs and what staying there costs. On WordPress, speed is a maintenance job: a cache plugin, an image plugin, something to defer JavaScript, and a re-check after every update because any one of them can quietly undo the others.

The metric where the gap shows most is INP, which replaced First Input Delay in March 2024 and measures how long a page takes to respond after somebody touches it. Server side caching does nothing for it. INP is about the JavaScript already sitting on the page, and no cache plugin can delete a script another plugin insisted on loading.

On the other side, the mechanism is much less interesting, which is the point:

// Rendered when the content changes, not when a visitor arrives. The work// below runs once an hour at most, whether ten people read the page or// ten thousand do.export const revalidate = 3600; export async function generateStaticParams() {  const posts = await getPosts();  return posts.map((post) => ({ slug: post.slug }));} export default async function Page({ params }: { params: Promise<{ slug: string }> }) {  const { slug } = await params;  const post = await getPost(slug);  return <Article post={post} />;}

There is no cache plugin in that file because there is nothing left to cache. The HTML exists before the request does.

Where WordPress still wins

I quote this work for a living and I still talk people out of it regularly, so take the list seriously rather than as a fairness gesture.

• You sell things. WooCommerce is a mature product with a decade of extensions behind it, and a headless storefront is a bigger and riskier project than almost any store owner expects when they ask about it.
• Nobody maintains it. Managed WordPress hosting with automatic updates asks nothing of anyone. A Next.js site needs a person who can run a build and read a deploy log. If that person does not exist, you have traded a slow site for a stuck one.
• Your team lays out pages by hand every week. If marketing builds bespoke campaign pages in a builder and will not move to a structured editor, a migration proposes taking away the part of the job they like.
• The site is small and already fast. Ten pages, good scores, nothing broken. Migrating that spends money and earns nothing back.

And if your site is slow because of six plugins and a four megabyte hero image, the fix is six plugins and an image. I will say so, and it is a much cheaper afternoon than the one you were budgeting for. You can get most of that answer yourself from the free site check before you talk to anyone.

The option most people miss

The comparison gets posed as a choice between two whole systems, and that framing is what makes it feel hard. You can split it, and for a team that publishes regularly the split is usually the right build.

Keep WordPress. Keep the block editor, the media library, the user roles, the workflow your writers already have in their hands. Stop letting it serve visitors. Next.js reads the content over an API at build time, or when a webhook says something changed, and serves static pages from an edge. Editors notice nothing. Visitors never touch PHP.

Both APIs are dependable now. REST ships with core and needs no plugin at all. WPGraphQL, the route I take on larger sites, became a canonical plugin on WordPress.org after Automattic hired its creator in late 2024, so a critical dependency is no longer one maintainer working evenings.

// One query, one round trip, exactly the fields the template renders.// The REST API would need three calls to assemble the same page.const QUERY = `  query PostBySlug($slug: ID!) {    post(id: $slug, idType: SLUG) {      title      content      date      seo { title metaDesc canonical }      author { node { name } }      featuredImage { node { sourceUrl altText } }    }  }`; export async function getPost(slug: string) {  const res = await fetch(process.env.WP_GRAPHQL_URL!, {    method: 'POST',    headers: { 'Content-Type': 'application/json' },    body: JSON.stringify({ query: QUERY, variables: { slug } }),    // Content is re-fetched when the webhook fires, not on every request    next: { tags: ['posts'] },  });   if (!res.ok) throw new Error(`WordPress returned ${res.status}`);  const { data } = await res.json();  return data.post;}

There is a genuine cost to this. You are running two systems instead of one, and the WordPress install still needs updating even though nobody visits it. What you get back is that the box no longer has to survive your traffic, which changes what it needs to be and what it costs to run.

Deciding in ten minutes

Read down the left column and stop at the first row that describes you.

Two things worth pulling before you speak to anybody, including me. Your active plugin list, because it predicts the cost of the work better than page count does. And your URL count, because that is what the redirect map has to cover and it is the part that protects your traffic.

# The list that decides most of the quotewp plugin list --status=active --fields=name,version # How many URLs Google currently knows about, which is what redirects must covercurl -s https://example.com/wp-sitemap.xml \  | grep -oE '<loc>[^<]+</loc>' | sed 's/<[^>]*>//g' \  | while read -r map; do curl -s "$map" | grep -c '<loc>'; done \  | paste -sd+ - | bc

Take both numbers to whoever quotes you. If they do not ask about redirects, keep looking.

Questions people ask me

If you want a straight answer on your own site, send me the address. You will get either a breakdown of what a migration would involve and what it would cost, or a recommendation to stay where you are and fix three specific things, which is what I say more often than people expect. The migration service page covers how the work runs, and the contact form is the fastest way in.

Resources

• W3Techs: WordPress usage statistics

  The market share figures quoted above, updated daily. Read the sampling note before quoting it at anyone.

• Patchstack: State of WordPress Security in 2026

  Source for the 11,334 vulnerabilities, the plugin and theme split, and the time to first exploit figures.

• web.dev: Core Web Vitals

  The three thresholds, how they are measured, and why the 75th percentile is the number that counts.

• Google: site moves with URL changes

  The official process a migration has to follow if the rankings are going to survive it.

• WPGraphQL

  The GraphQL API for WordPress, now a canonical plugin, and the one I use on larger headless builds.

• WordPress REST API handbook

  Ships with core. Enough for most headless sites without installing anything.

• Next.js App Router documentation

  Rendering strategies, revalidation and the Metadata API, which are the three things a migration actually leans on.