Your content site has outgrown WordPress, or somebody says it has

What each one was built to be good at

WordPress is a publishing system, and everything in it points at one outcome: somebody who doesn't write code can create a page, schedule it, take it down, and see what changed. W3Techs has had it above 40% of all websites for years, and that figure drifts, so check it rather than trusting a slide.

Next.js is a framework for building an interface. Its unit is a component, not a page. It's good at what a publishing system handles badly: a screen that changes depending on who's signed in, a filter that narrows results as somebody types. Content is data the code reads.

Neither is the better tool. They answer different questions, and a content site usually asks the first one.

The honest case for staying

Most content sites weighing this move should stay, because what they're unhappy with is rarely WordPress. It's a theme bought years ago and customised by three different people, eleven plugins nobody has audited, and a shared hosting plan. All three are replaceable without touching the platform.

The second reason surfaces two years later. There's an enormous supply of people who can work on WordPress, and a plugin directory covering the dull things nobody wants to build: forms, redirects, sitemaps, a membership wall. On a custom build each is a small project with a queue in front of it.

Third, content is where migrations die. Years of posts with inconsistent markup, shortcodes that only render because a plugin is installed, image URLs resolving through a rewrite rule nobody remembers. That work is invisible in a proposal about page speed.

The burden of proof sits on the move. Staying doesn't have to argue for itself.

What actually makes a WordPress site slow

Speed is the stated reason for most of these moves, and it's usually the wrong one: it treats the platform as the cause when the causes sit elsewhere.

Know what you're graded against. Google's Core Web Vitals thresholds are 2.5 seconds for Largest Contentful Paint, 200 milliseconds for Interaction to Next Paint and 0.1 for Cumulative Layout Shift, each read at the 75th percentile of real visits. One lab score isn't that.

Four causes, in order.

1. 1. The plugin stack

   Every active plugin can add its own stylesheet and script to every page, whether that page uses it or not. A slider on the homepage loads its library on the contact page too. Cutting what's dead is the largest single gain.

2. 2. Images nobody resized

   A content team uploads what the camera produced. WordPress generates smaller versions, but a theme that asks for the full-size file serves the original anyway, and six of those make a page heavy.

3. 3. Hosting and the first byte

   On a shared plan, PHP assembles every page from the database on every request while other tenants use the same machine. A page cache, or a host that runs one, turns most requests into a file being handed over.

4. 4. The scripts you didn't write

   Tag manager, analytics, a chat widget, a heatmap, two advertising pixels. They load identically on any platform, they're often the heaviest thing on the page, and a rebuild changes nothing.

A badly built Next.js site is slow too

This is the half nobody selling a rebuild volunteers. A Next.js site can ship a large bundle of JavaScript to render text that never changes, and fetch its data in the browser after load, so content arrives in a second wave and the layout jumps. Add the same tag manager and you're back at the same number.

The framework gives an attentive team better defaults. It doesn't give an inattentive one a fast site.

So the test worth running before anyone prices a rebuild: spend a quarter fixing the site you have. If the field numbers move, you didn't need it. If they don't, you know what the platform owns.

Who publishes a page on a Tuesday afternoon

This is where teams regret the move, and it rarely comes up in the meeting where the decision gets made. It's Tuesday, a marketer needs a landing page live by Thursday: a headline, three paragraphs, two images and a form. On WordPress she opens the editor, builds it from blocks and publishes. Nothing was deployed.

On a Next.js build, Tuesday holds exactly what somebody decided in advance to build for her. If the content lives in the repository, that page is a ticket, a branch, a review and a deploy. If a CMS was wired in, she can edit the fields that exist, but she can't invent a two-column section with a video.

That constraint is defensible for a product interface, where consistency beats freedom. It's expensive for a content site, where publishing volume is the point. And it gets settled in the last fortnight of a build by whoever is closest to the deadline.

The hybrid you'll meet in a proposal

Keep WordPress as the place people write, and put a Next.js front end in front of it reading the content over an API. WordPress has shipped a REST API in core since version 4.7, and WPGraphQL is the common alternative. Editors keep the admin they know.

What it solves: the theme layer is where a lot of WordPress performance goes to die, and this removes it while keeping the editorial workflow. One codebase then serves the marketing pages and the application.

The cost arrives later. You run and secure two systems, and the WordPress install still needs updating though no visitor touches it. Every plugin that rendered something on the front end stops working: contact forms, popups, sliders, the built-in search, most of what a page builder produced. Preview breaks until somebody rebuilds it, and the draft mode Next.js documents for that is work rather than a switch to flip.

It suits a team that publishes constantly and also has an application. It's a poor trade at twice a month, where you've doubled the maintenance to fix something better hosting was already handling.

Who each one suits

WordPress, if content is the product. A team publishing weekly or more, pages rather than screens, nobody in-house who writes code, and a budget better spent on hosting, images and a plugin cull. That's most content sites.

Next.js, if the site has stopped being a set of pages. Signed-in state, an application beside the marketing pages, content that changes rarely, and a named person who'll own the codebase in year two. That last condition isn't optional, and it's the one most often waved through.

The hybrid, if both are true at once: a publishing operation you can't slow down and a product surface a theme can't deliver. It costs more to run than either half.

If you're stuck between the first two, stay. Moving is easy to justify later on a fast, maintained site, and very hard to justify twice.