Rebuilding WordPress on Next.js — when it is worth it

We build on both. Roughly half the studio’s client work is custom WordPress and the other half is Next.js, which puts us in an unusually neutral position on a question founders ask constantly: should we leave WordPress?

The honest answer is usually no. But there are four situations where the answer is a clear yes, and it is worth being precise about which is which.

First, rule out the cheap fix

Most complaints about WordPress are complaints about how a specific site was built.

Slow? It is almost certainly plugin bloat, unoptimised images, render-blocking scripts and shared hosting. A clean-up sprint — remove what nobody uses, compress and serve modern image formats, defer third-party tags, move to decent hosting, add caching — commonly turns a failing mobile score into a passing one for a fraction of a rebuild.

Insecure? Usually abandoned plugins and missing updates. A hardening pass with a firewall, backups and a maintenance routine fixes it, and we have done that on inherited sites more than once.

Hard to edit? Frequently a theme problem, not a platform problem.

Do this first. It costs ₹40,000 to ₹1.5L, takes a week or two, and often ends the conversation. Rebuilding a site that only needed maintenance is the most expensive way to solve a solvable problem.

Four reasons that justify the rebuild

1. The site is an application, not a site

Once you have logged-in users, roles, dashboards, real-time data or complex state, you are building software. WordPress can be pushed there and we have pushed it, but past a certain complexity you are fighting the tool on every feature.

The tell: your plugin list contains three things extending each other, and every new requirement starts with “is there a plugin for”.

2. Performance is a revenue line and you have already done the clean-up

If you have already removed the bloat and you still cannot hit your targets — particularly interaction responsiveness on mid-range Android, which we cover in fixing INP — a rendering architecture that ships less JavaScript wins structurally rather than incrementally.

This applies most to content-heavy commercial sites where a few points of conversion is worth serious money.

3. Content must feed several surfaces

Website, mobile app, partner sites, a kiosk, a client’s own embed. When the same content has to reach multiple destinations, a content API with a separate front end is the correct shape, and a monolithic theme becomes a bottleneck.

4. Developer velocity is throttling the business

If shipping a change takes days because of theme complexity, staging risk and no test coverage, the cost is not the platform — it is the delay on everything else. Component-based front ends with a deployment pipeline and preview builds simply move faster.

Three reasons that are not good enough

“WordPress is old-fashioned.” It powers a very large share of the web and a well-built custom WordPress site is a perfectly good product. Aesthetics of stack choice do not appear on your P&L.

“Our developer prefers React.” Legitimate for hiring reasons, insufficient on its own. Ask what the business gains.

“We want to be headless.” Headless is a means, not a goal. If your content only ever renders on one website, you are adding a network hop and a build step for nothing.

The migration order that protects rankings

If you are going ahead, sequence matters more than technique.

1. Inventory every URL. Crawl the live site. Export search performance data. You now know which pages earn traffic and which are noise.

2. Decide the URL policy before design. Keeping identical URLs is the safest path by a wide margin. If you must change them, build the redirect map now, one-to-one, no chains, no dumping everything to the home page.

3. Migrate content with metadata intact. Titles, descriptions, headings, image alt text, structured data, canonical tags, publication dates. Most ranking losses come from metadata quietly dropped in the move.

4. Match or beat the old performance. Measure the old site properly first so you have a baseline to defend.

5. Keep the editing experience serious. Preview, drafts, scheduled publishing, image handling. If publishing gets harder, the marketing team stops publishing, and that costs more than the rebuild saved. Our own site schedules posts ahead of time for this exact reason.

6. Launch, then watch daily for a month. Crawl errors, index coverage, redirect hits, ranking movement per page. Fix the first week’s issues in the first week.

7. Keep the old site reachable for a while. Not linked, but restorable. Rollback plans are cheap insurance.

What we actually recommend

For a marketing site with a small team and no application behind it, custom WordPress remains a strong choice, and we build them deliberately rather than apologetically.

For anything with accounts, an app, multiple content surfaces, or performance tied directly to revenue, we build on Next.js — the reasoning generalises through our stack framework.

The mistake to avoid is migrating for a reason a two-week clean-up would have solved. Measure the current site properly, fix what is fixable, and then decide with numbers rather than instinct.

Not sure which side of the line you are on? Send us the URL — we will tell you honestly, including when the answer is to keep what you have.