Next.js or WordPress for a small-business website: how to choose

Every couple of years the same question returns: should the website run on WordPress, or be built with a framework like Next.js? Both answers can be right, and both can go expensively wrong. The reason is rarely technical: the platform gets picked before anyone decides who will run the site after launch.

Here is a plain comparison for an owner or a marketing lead, plus a checklist for the afternoon you decide.

What you are really choosing between

The decision is usually presented as two camps. There are three practical options, and the third is the one people miss.

• A managed CMS. WordPress, or a hosted builder in the same family, on managed hosting. Content, design and plugins live in one place and you edit from its dashboard.
• A custom build. A framework such as Next.js renders the pages, with content from a headless CMS or, on a small site, from the code itself. Everything on the page is there because someone put it there.
• Headless WordPress. The editor your team knows, with a custom front end over it. Editing stays familiar and the visitor gets a hand-built site.

When a managed CMS is the right answer

WordPress is the most widely used content management system on the web, and that popularity is a feature: most of what a small business needs has been solved, and help is available almost anywhere. Choose it when these are mostly true.

• Your site is mainly pages and posts: services, about, blog, contact.
• Your team publishes often and wants new pages without calling a developer.
• You need a familiar feature quickly, such as events, a small shop or forms that feed your CRM.
• Nobody on your side will own code, so another team has to be able to pick it up.
• The money is better spent on content and photography than on engineering.

When a custom build pays off

A custom front end earns its place when the site stops being a brochure and starts doing work.

• The site is part of the product. Logged-in areas, dashboards, calculators, booking flows, anything with real logic behind it.
• Content lives somewhere else. A product catalogue, an internal system, a third-party API. A custom build reads them and renders pages from them.
• Design is doing the selling. Motion, layout and detail that no theme will give you without a fight.
• You already run a React app. Sharing components, types and conventions with the marketing site saves real time.
• Structure matters. Hundreds of generated pages, several languages, strict performance budgets.

Pick the platform that fits the people who will run the site, not the one that fits the launch.

Who edits the content, and how

This decides most projects and is usually asked last. With WordPress, editing is included: someone logs in, changes a block, presses update. With a custom build it is a decision. Either you wire up a headless CMS, or every text change becomes a developer task.

For a site that changes weekly, wire up the CMS. For a dozen pages that change twice a year, keeping the words in the code is honest, as long as everyone agrees that is the arrangement. Ask to see the editing screen before sign-off.

Hosting, updates and the upkeep nobody plans for

• WordPress. Core, theme and plugin updates arrive constantly and any of them can break a page. Managed hosting covers backups, staging and much of the patching. Budget time to review updates, not click them through.
• Custom build. Pages are usually served as static files from a CDN, so there is less to attack and less to fall over. Upkeep moves to dependencies, updated on a schedule.

Plugins are the part to watch

Most WordPress trouble arrives through plugins: an abandoned one, a licence that quietly lapsed, ten doing overlapping jobs. Keep the list short, prefer plugins with recent updates and a real team behind them, delete what you do not use, and give one person responsibility for security updates.

Performance and Core Web Vitals

Neither platform is fast or slow by nature. A lean WordPress site on good hosting will outrun a careless custom build every time. What differs is how easy it is to stay fast. A custom build starts with almost nothing on the page. A themed site starts with everything the theme author imagined and asks you to remove it.

Core Web Vitals measure three things a visitor feels: how quickly the main content appears (Largest Contentful Paint), how steady the layout stays as it loads (Cumulative Layout Shift), and how promptly the page answers a tap (Interaction to Next Paint). The same habits move those numbers on either platform. Size and compress images, ship less JavaScript, reserve space for whatever arrives late, and test on a mid-range phone on mobile data.

Three SEO myths worth dropping

• A framework does not outrank a CMS. Search engines index content, links and page experience. No points are awarded for your stack.
• An SEO plugin is not SEO. Plugins manage titles, descriptions, sitemaps and structured data; a custom build handles the same in code. Neither writes the page somebody wanted to read.
• A redesign does not lift rankings by itself. It protects what you have when URLs, content and links survive, and costs you when they do not.

Migration paths that keep your traffic

1. 01Inventory first. List every URL you have, with its traffic and its purpose. That list is the project.
2. 02Keep the addresses. Matching URLs is the safest migration there is. Where one has to change, add a permanent redirect so no working page becomes a 404.
3. 03Move in stages. A new front end can take the marketing pages first and leave the blog where it is.
4. 04Consider headless. WordPress as the editor behind a custom front end: the speed without the retraining.
5. 05Check after launch. Watch search console coverage and analytics for a few weeks. Migrations fail quietly.

A decision checklist

Answer these with the people who will live with the result.

• Who edits the site each month, and how technical are they?
• How often does the content change: weekly, or twice a year?
• Does the site need logic, logins or data from another system?
• Who applies updates and watches for problems after launch?
• How much of the design has to be exactly yours rather than nearly right?
• What do you expect to add in the next two years?

The short version

If the site is mainly content, changes often and will be looked after by a marketing team, a managed CMS is the sensible choice. If it carries logic, pulls data from elsewhere or has to be exactly right, a custom build repays the effort. If you want the familiar editor behind a front end your visitors deserve, go headless and take both.