WordPress vs Next.js for a Marketing Site: The Honest Comparison

Choose WordPress when people who do not write code need to change the site every week. Choose Next.js when the site is mostly fixed and the thing you cannot afford is a dependency graph you did not choose. That is the whole decision, and it is a question about your team, not about PHP.

Almost every comparison you will find gets the framing wrong in the same way: it compares a WordPress theme you install in ten minutes against a Next.js site you build from nothing over six weeks. That is not a comparison, it is a rigged race. The honest version compares a WordPress theme plus its plugin stack against a Next.js template plus its package.json — two finished sites, both bought, both needing work before launch.

The decision in one table

Read that table as two different answers to one question: whose dependency graph are you responsible for? WordPress hands you a large one maintained by many strangers, with an admin UI on top. A template hands you a smaller one that you own outright, with no admin UI at all.

The plugin stack is the architecture

A WordPress marketing site is rarely "WordPress". It is WordPress plus a page builder, plus an SEO plugin, plus a forms plugin, plus a caching plugin, plus an image-optimization plugin, plus analytics, plus a consent banner, plus whatever the last agency left behind. That list is the actual architecture. It determines the HTML, the load time, the security surface and the upgrade risk far more than the core CMS does.

This is not an argument that plugins are bad. It is an argument about where the decisions live. On the Next.js side the equivalent list is in one file you can read in a minute, every entry is pinned, and npm audit tells you the truth about it on demand. On the WordPress side the equivalent list is spread across an admin screen, several of the entries are commercial with their own licence keys, and two of them probably do the same job because nobody removed the first one.

The practical consequence shows up at upgrade time. A WordPress update is security-driven and continuous: you take it because not taking it is the risk. A template update is feature-driven and optional: you take it when it contains something you want. Those are genuinely different operating models, and the second one only stays true if you customize the template in a way that keeps it mergeable — which is its own post, and the single most common way teams throw away the advantage.

Performance, with our numbers rather than a claim

Here is where most comparison posts assert that "Next.js is faster" and move on. We can do better than assert, because we measured our own storefront, and the result is more interesting than the claim.

Across eight page types, desktop Lighthouse is 100 for performance, accessibility and SEO. On mobile, accessibility and SEO stay at 100 and performance lands at 89–99 depending on the page. So: very good, not perfect, and the gap is on mobile.

The instructive part is why mobile stops short. We tested the obvious hypothesis — too many bytes — by blocking every image and every prefetch on the home page. Largest Contentful Paint moved from 3786 ms to 3740 ms. Forty-six milliseconds. The remaining cost is not images and it is not our code; it is React hydration, and the largest single chunk is react-dom at 221 KiB raw / 70 KiB gzipped. That is the framework floor for an interactive React page, and no amount of tuning removes it.

Take that as the honest shape of the comparison. A well-cached WordPress page that ships almost no JavaScript can beat a React page on a slow phone, and any comparison that does not admit this is selling you something. What Next.js gives you is a predictable floor you control, versus a plugin stack whose floor moves when someone installs a slider.

Where the Next.js side wins decisively is the work above that floor, because it is build-time work rather than plugin work:

• Cover images went 255 KiB → 33 KiB by generating WebP derivatives at build time, with no request-time optimizer and no per-image hosting bill.
• The whole public/images directory went 117 MB → 93 MB, and one folder of use-case art went 1793 KiB → 550 KiB.
• One real bug the audit caught: the LCP image on a grid page was loading="lazy", which cost 1.67 s of load delay all by itself. A tiny fix, invisible without measurement.

That is the pattern. On a template you own, performance is a thing you fix once in the build pipeline. On a plugin stack, it is a thing you negotiate with continuously. Details of the build-time approach are in the image pipeline post.

Who edits the copy

The strongest argument for WordPress is unchanged in 2026 and it has nothing to do with technology: a marketing team can change the site without a developer. If your homepage headline changes monthly, if three people publish posts, if a campaign needs a landing page on Thursday, WordPress is a serious answer and "just edit the MDX file" is not.

We have written the long version of this trade-off twice from different angles, so rather than repeat it: the authoring question specifically is covered in MDX vs a headless CMS, and the hosted-builder version of the same argument is in Webflow vs Next.js. The short version: if the answer to "who edits this in six months" is a non-developer, either use WordPress or budget for a CMS on the Next.js side. Do not pretend the question away — it is the one that actually decides this, and it decides it more often than performance does.

The middle path exists and is underused: WordPress as a headless content API with a Next.js front end. You keep the editing experience your marketing team already knows and you serve a static front end. It costs you a second system to host and a build hook, and it is a genuinely good answer for a content-heavy site with non-technical editors and performance requirements.

Where WordPress is straightforwardly the better answer

• A real content operation. Multiple authors, editorial workflow, scheduled publishing, revisions, roles. WordPress has spent twenty years on this and it shows.
• Ecommerce you do not want to build. WooCommerce ships inventory, tax, shipping zones, refunds and an order admin. Wiring a payment provider into a template gets you checkout; it does not get you an order back-office.
• You already have the team. An in-house WordPress developer is worth more than an architecture argument.
• Deeply localized or regulated content where an existing plugin already solves the thing you would otherwise write.

Where Next.js pulls decisively ahead

• The site is mostly fixed. A product marketing site, an agency site, a launch page. The content changes quarterly, not daily.
• You want the performance ceiling to be yours. Static output, build-time images, a bundle you can read.
• The site will grow programmatic pages — service pages, locations, category hubs generated from data rather than typed by hand. This is where a typed data source beats an admin UI decisively; see programmatic SEO in Next.js.
• The marketing site is the front door to an app you are already writing in React. One codebase, one deploy, one design system.
• You need the site to still work in three years without weekly maintenance. A static build keeps serving. An unpatched WordPress install becomes someone else's asset.

Migration, if you are moving off WordPress

Two things matter, and neither is the rebuild.

Your URLs are the asset, not the design. Every indexed WordPress URL — including the /?p=123 shapes, the category archives and the attachment pages — needs a decision: 301 to its new home, or a deliberate 410. The full method, including the ninety days afterwards and what "recovery" is supposed to look like on a graph, is in migrating without losing rankings.

Your content model is a second migration. WordPress content is HTML in a database with shortcodes in it. Getting it into MDX or a CMS is a scripted transformation with a manual tail, and the tail is always longer than the estimate. Budget for it separately from the design work.

Mistakes in this decision

Frequently asked questions

Is WordPress bad for SEO? No. WordPress sites rank extremely well, and the CMS is not the limiting factor — the plugin stack and the page speed are. What Next.js gives you is direct control of the things Search Console actually complains about: canonicals, structured data, sitemap dates and internal link structure, all as code you can test in CI rather than settings in a plugin.

Can a Next.js site have a blog non-developers can post to? Yes, with a headless CMS. That is the standard setup and it works well. It costs you a service and a build hook. The version where posts live as MDX in the repo is faster and cheaper and only works if the authors are comfortable with a pull request.

How much of a WordPress site can I keep in a migration? The content and the URLs, which are the valuable parts. The theme, the plugins and the page-builder markup do not come with you, and trying to reproduce page-builder output faithfully in React is the wrong goal — it encodes ten years of workarounds you are trying to leave behind.

Is WooCommerce still the better ecommerce answer? For a real store with inventory, shipping and returns, usually yes. For selling a handful of digital products, no — a hosted checkout plus an entitlement check is far less machinery, which is the setup we run.

What about the hybrid — WordPress backend, Next.js frontend? It is a good answer for content-heavy sites, and underrated. You get the editor your team knows and a static front end. The cost is two systems, two sets of updates, and a build pipeline that has to handle the CMS being down. Choose it deliberately, not as a way of avoiding the editor question.

If the site is mostly fixed, start from a finished one

The Next.js side of this comparison is only fast if you are not building the marketing site by hand. The templates below are the shape this decision usually lands on — agency and services sites where the content changes quarterly, the design has to look current, and the whole thing needs to score well on a phone without a plugin stack to negotiate with.