It’s a familiar situation for a lot of teams: the usual SEO housekeeping is done, PageSpeed scores are strong, the UI is clean, and performance looks solid on paper. But rankings still aren’t matching the scoreboard. When that happens, the culprit is often not the content or the design. It’s the delivery model behind the site.
The problem with a React (Vite) SPA
React is fundamentally a single-page application framework, and that matters more than it’s often given credit for. A site can hit near-perfect PageSpeed numbers and still struggle to climb the rankings, because the metrics that PageSpeed measures aren’t the same thing search engines care about when deciding how well they can read a page.
In a typical Vite-powered React SPA, everything renders inside a single index.html, with navigation and page changes handled by client-side JavaScript. That’s great for developer experience and can produce genuinely fast, well-ranking sites; plenty of SPAs rank well, some even breaking into top positions within weeks.
But for a content-heavy, multi-page website, there’s a ceiling. Search engines and AI crawlers don’t always behave like human visitors. Many would rather not spend extra effort executing JavaScript just to work out what’s on a page; they prefer content that’s visible earlier, cleaner, and easier to parse. That’s where the SPA model starts to show its limits.
Why Next.js often makes sense
Next.js is built on top of React, so a migration is less a personality transplant and more a matter of giving the same engine a more capable chassis.
The easiest part is usually the UI: most existing components can be carried over largely intact, which saves time and keeps risk low.
Routing tends to be the trickier part. A React Vite setup will typically use a client-side router such as react-router-dom, while Next.js routing is file-based. That’s straightforward in principle, but it gets more involved on a multilingual site running separate locale paths (for example, one path per language). Converting code-based routing into file-based routing takes real planning, not just a quick refactor.
How to approach the migration, step by step
Trying to flip an entire site over in one pass is a common way for a migration to quietly blow up. A steadier sequence works better:
- Remove the old build tooling and initialize Next.js, wiring the app so it keeps its existing structure and runs again without breaking the live site.
- Once it’s stable, start adopting the Next.js features that actually move the needle: next/image, next/font, Static Site Generation (SSG), Incremental Static Regeneration (ISR), and Server-Side Rendering (SSR) where it makes sense.
- Only after everything is stable should the project be restructured into the standard Next.js folder layout.
That order matters: build first, stabilize second, restructure last.
Keep the UI, UX, and URLs consistent
A visitor shouldn’t be able to tell that anything changed. Same design, same flow, same content, same behavior. The goal of a migration like this is better performance and rankings, not a visible relaunch.
URLs are worth protecting too, especially on a site that’s been live for a while and has off-page SEO work tied to specific paths. Changing URLs casually during a migration can undo a lot of that equity, so keeping them stable (and setting up proper redirects for anything that must change) is worth the extra care.
SEO is where the shift gets real
Metadata handling is one of the clearest wins. Many React SPAs manage per-page metadata with a library like react-helmet-async; Next.js’s built-in Metadata API tends to make this feel native rather than bolted on, which reduces the chance of pages shipping with missing or stale tags.
It’s also worth optimizing for AI-driven search and crawlers, which is becoming a real consideration alongside traditional SEO. Two practical additions:
- An llms.txt file
- A dedicated HTML sitemap page listing the site’s important URLs
Small additions like these can meaningfully improve how well AI systems and crawlers understand a site, on top of the usual search-engine benefits.
What kind of performance jump to expect
Common pain points before a migration like this include a Largest Contentful Paint (LCP) over three seconds, visible content shift, and navigation that depends too heavily on JavaScript rather than working through direct URL access.
After a well-executed move, it’s realistic to see major PageSpeed metrics (performance, accessibility, SEO, and best practices) land in the low-to-mid 90s or higher. Pages generated statically tend to feel close to instant, since there’s little rendering work left to do at request time.
Which pages benefit most
Deeper, content-heavy pages, such as service pages, project pages, blog posts, and similar “terminal” pages, usually see the biggest gains. These are the pages most likely to start getting indexed more consistently once crawlers no longer need to execute JavaScript to see what’s on them, which translates directly into better visibility, not just better speed.
Don’t forget forms and dynamic functionality
Most business sites aren’t purely static marketing pages; they have contact forms, planners, scheduling tools, and other interactive elements. A good migration needs to preserve that interactivity, not just SEO. Next.js makes this manageable by allowing interactive components to stay client-side while page shells, content, and SEO-sensitive areas are server-rendered or statically generated where appropriate. Getting that balance right is the core of the exercise.
What makes Next.js worth the effort
The built-in tooling is the main draw:
- Static Site Generation (SSG) for content pages
- Server-Side Rendering (SSR) where content needs to be fresh at request time
- Incremental Static Regeneration (ISR) for pages like blogs that should stay current without a full manual rebuild
ISR in particular tends to be the standout: it keeps content current without turning updates into a manual rebuild process every time something changes.
The real lesson
It’s tempting to summarize this kind of migration as “Next.js is better than React,” but that’s an oversimplification. React Vite remains a strong choice for plenty of projects.
The more useful takeaway is that how a site is delivered changes how search engines, crawlers, and AI systems understand it. For any business that depends on discoverability, architecture isn’t just a developer preference. It’s a ranking decision. For a multi-page, SEO-driven business site in particular, the delivery model matters just as much as the design.
Lessons for next time
This pattern shows up often in migration work, including projects handled by the team at StepUp Analytics, where teams say they’d move to the Next.js structure earlier next time, rather than waiting until everything feels “fully ready.” Aligning on the right folder structure and rendering model from the start tends to make everything downstream considerably less painful.
Final thought
A migration like this typically delivers better performance, stronger SEO visibility, and a cleaner foundation to build on. More than anything, it’s a reminder that a site isn’t just what it looks like in the browser. It’s how it’s served, how it’s understood, and how it’s discovered.