React or Next.js for a marketing site

The question usually arrives already decided. Someone has read that Next.js is better for SEO, or that React is simpler, and wants confirmation. Both framings skip the part that actually determines the answer: what has to be in the HTML before any JavaScript runs.

For a product marketing site — a homepage, a few product pages, case studies, a contact form — that is the whole decision. Everything else is preference.

What the difference actually is

React is a library for building interfaces. It does not decide how your pages are delivered. Next.js is a framework built on React that does: it renders on the server, generates static pages at build time, handles routing from the filesystem, and gives you server-side code in the same project.

So the comparison is not really React against Next.js. A plain React app is almost always a single-page app: the server sends one near-empty HTML file, the browser downloads a JavaScript bundle, and that bundle builds every page. The real comparison is between that model and one where each page already exists as HTML.

The question that decides it

Ask what has to be true of your pages, in this order:

1. 01Does the content change per request? Personalised pricing, a logged-in state, region-specific inventory, anything drawn from a database at view time. If yes, you want server rendering, and Next.js is the shortest path to it.
2. 02Does the content change often, from a CMS, without a deploy? If editors publish on their own schedule, you want a framework with incremental regeneration rather than a build step someone has to trigger.
3. 03Is there server-side work in the same project? Authentication, webhooks, payment callbacks, an API that should not live in a separate service. Next.js gives you those routes in the same repository.
4. 04Is the site a fixed set of pages that change when you deploy? Then the pages can simply be generated at build time — and which tool does that is much less important than whether it happens at all.

For most marketing sites the honest answer is the fourth. Twelve pages, updated when the team updates them, no per-visitor content. That does not need a server rendering on demand. It needs the pages to exist.

The option people forget

A React single-page app can produce real HTML for every route at build time, without adopting a framework. You render each route to a string during the build and write it to a file. The result is a static page per URL that any client can read, with the app still taking over in the browser.

This site works that way. It is React and Vite, and every route is rendered to HTML at build time. The reason to mention it is that it is the option that gets skipped in the framing of the question: the choice is usually presented as staying empty or migrating, when generating the pages is a build-step change rather than an architecture change.

What it costs you is worth stating plainly. There is no server, so anything per-request is off the table. Adding a page means the build has to know about it. And because the app re-renders in the browser rather than resuming from the generated markup, that HTML is for clients which cannot run the app — it does not make the app itself start faster.

When Next.js clearly earns it

• The marketing site and the product are the same codebase. Sharing components, types, and a design system across both is worth more than any individual rendering feature.
• Non-technical people publish. A CMS plus regeneration means an editor hits publish and the page updates. A static build means a deploy.
• There is real server-side work. Auth, sessions, webhooks, anything holding a secret.
• The page count is large, or generated from data. Hundreds of programmatic pages are a routing problem, and filesystem routing plus server rendering solves it directly.

Of the case studies here, Lowkar is the one built with React and Next.js — a marketplace, where listings come from data and the set of pages is not something you write by hand. That is the shape of problem the framework is for.

When it does not

If the site is a fixed set of pages, adopting a framework to solve an HTML problem means taking on its rendering model, its caching rules, its data-fetching conventions, and its upgrade cadence. That is a reasonable trade when you need what it provides. It is a poor trade when what you needed was for the pages to exist, which a build step does.

The failure mode worth naming is the middle position: a Next.js site built entirely from client-side components, which ships the framework and still serves an empty document. It happens often, and it is the worst of both — more machinery, same problem.

How to check what your site actually serves

Before deciding anything, look at what a client that cannot run JavaScript receives. Fetch your own page and read the response:

• Run curl -s https://yoursite.com | wc -c to see the byte size of the document itself.
• Search that response for your headings. If there is no h1 in it, nothing which skips JavaScript can see what the page is about.
• Check for a canonical link tag. In a single-page app this is often set at runtime, which means it is absent for exactly the clients that need it most.
• Paste the URL into a messaging app. The preview it generates is a live test of what non-rendering clients get.

Run that first. If the document already contains your content, the framework question is a preference question, and you can decide it on what your team knows well. If it comes back empty, you have found the thing worth fixing — and it may not require changing frameworks at all.

If you want a second opinion on which of these your site needs, get in touch.