Next.js or Plain React for a Business Website: SEO and Speed

Say your company relaunched its website six months ago as a React single-page app. It looks sharp, but new service pages take a long time to show up in Google, link previews in some chat apps show a generic title, and the speed report keeps flagging a large JavaScript bundle. Someone suggests moving to Next.js. Is that the fix, or an expensive detour? The Next.js vs React question comes down to one thing: whether your pages reach the browser as finished HTML or as an empty shell that JavaScript fills in afterward.

What the comparison really is

Next.js is not an alternative to React. It is a framework built on React, so a Next.js site is a React site. The real choice is between React on its own, usually set up with a build tool such as Vite and rendered entirely in the visitor's browser, and React inside a framework that can render pages on the server or at build time.

React's own documentation now recommends starting a new app or website with a framework, and names Next.js, React Router and Expo. Building from scratch with a tool like Vite, Parcel or Rsbuild remains an option for projects the frameworks don't suit. In February 2025 the React team also deprecated Create React App for new apps, the tool many older React sites were built with. So "plain React" today usually means a client-rendered app built with Vite.

What changes for SEO

Google handles JavaScript sites in three steps: it crawls the page, renders it by running the JavaScript, then indexes what it finds. Rendering waits in a queue. Google's guide to JavaScript SEO basics says a page may sit there for a few seconds, but it can take longer than that. The same guide says server-side or pre-rendering is still a great idea, because it makes a site faster for users and crawlers, and not all bots can run JavaScript.

With a client-rendered React app, the first HTML a crawler receives is mostly empty. The headings, text, internal links and often the page title and meta description only appear after the JavaScript runs. Google can usually get there, but you are relying on that second step, and link previews and other crawlers may never see anything beyond the shell. You also have to manage titles and meta tags for every route yourself.

With Next.js, each page can be rendered on the server or ahead of time at build, so the very first response already contains the content, the links and the meta tags. That removes a whole class of indexing problems.

Be clear about what it does not fix. Thin content, a slow server, weak internal linking and missing metadata stay broken after a migration. Next.js removes one technical obstacle. It doesn't write your pages.

What changes for speed

Google's Core Web Vitals give you the yardstick. According to web.dev, a good page has Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less, measured at the 75th percentile of page loads. Our explainer on why websites are slow covers what each metric means for your visitors.

A client-rendered app loads in a chain: download an almost empty HTML file, download the JavaScript bundle, run it, fetch the data, then draw the content. The React team describes these network waterfalls in the same post that deprecated Create React App, and notes that server rendering generally sends less JavaScript to the browser and gives a faster first paint, which can also improve Interaction to Next Paint.

With Next.js, the HTML arrives with the content already in it, and the browser can show the main text and images before all the JavaScript has loaded.

A Next.js site can still be slow, though. Uncompressed hero images, a heavy chat widget, several tracking scripts and components that all run in the browser will undo most of the gain, whichever framework renders the page.

When plain React is the right call

This is the part of the Next.js vs React debate that often gets skipped: plenty of projects don't need server rendering at all.

• Everything is behind a login. Dashboards, admin panels, internal tools and customer portals don't need to rank in search. Users load them once and stay for a while, so a client-rendered app is simpler and perfectly fine.
• You are embedding a widget in another site, such as a calculator, a booking form or a product configurator.
• You want the simplest possible hosting. A Vite build is a folder of static files that any web server or CDN can serve.

Next.js also has real costs. There are more concepts to learn, including server and client components, caching and revalidation. Server features need a Node.js server or a hosting platform that runs one; the official self-hosting guide recommends putting a reverse proxy such as nginx in front, and running several instances means configuring a shared cache. Releases come quickly too: Next.js 16 arrived in October 2025 and three minor versions followed by August 2026. Budget time for upgrades.

The middle option: a static export

If your public site is mostly content that changes a few times a month, Next.js can export it as plain static files. One line in the config does it:

// next.config.js
const nextConfig = { output: 'export' }
module.exports = nextConfig

Running the build then produces an HTML file for each route, which you can host on any web server that serves HTML, CSS and JavaScript. You give up the features that need a server: incremental regeneration, Server Actions, cookies, redirects and rewrites defined in the config, and image optimization with the default loader. For a 30-page company site with a blog, that trade is often worth it: search-friendly HTML with the hosting simplicity of a plain React build.

A worked example: a supplier with a site and a portal

Imagine an industrial supplier that needs four things: 40 marketing pages covering services, industries and locations; a blog with two posts a month; a quote-request form; and a portal where logged-in buyers see their orders and download invoices.

• Marketing pages and blog: these must rank and must load fast on phones. Build them in Next.js and generate them ahead of time. If no server features are needed, a static export works, rebuilt whenever content is published.
• Quote form: it needs a server endpoint somewhere. With a running Next.js server it can live in the same project; with a static export, it posts to your existing backend API.
• Buyer portal: it sits behind a login, so search engines don't matter. It can be a Vite React app at portal.yourdomain.com talking to the same API, or client-side pages inside the Next.js project. Choose whichever your team will maintain more comfortably.

The mistake to avoid is building everything as one client-rendered app because the portal happens to need interactivity. The marketing pages would then carry the SEO cost for no benefit.

Next.js vs React: the rule

1. If pages need to be found in search or shared as links (marketing pages, blog posts, product or listing pages), use Next.js or another framework that renders HTML on the server or at build time.
2. If everything sits behind a login, plain React with Vite is simpler and fine.
3. If you have both, split them: a framework for the public pages, and a client-rendered app or client-side pages for the logged-in part.
4. If you already have a React single-page app that ranks poorly, check content and metadata first. If rendering really is the problem, move the public pages to Next.js first, not the entire app.

A quick first check you can do today: open one of your key pages, view the page source (not the inspector) and search for a sentence from the page. If it isn't there, search engines and link previews are relying on JavaScript to see your content.

If that check turns up an empty shell and you'd like a plan for fixing it, our React and Next.js developers can review your site and tell you whether a full migration, a static export or a smaller fix makes sense. Get in touch through our contact page.