1. When Next.js is the default yes

SEO and shareability matter on day one. If landing pages, service areas, case studies, or blog posts need stable titles, meta, and fast first paint without bolting on prerender services or a separate CMS renderer, Next.js (App Router with static or server rendering) keeps HTML honest. Social previews and search snippets degrade quickly when the meaningful text only appears after JavaScript runs.

You want one codebase for marketing and light product. Same auth patterns, same design system, same deployment—contact forms, gated downloads, and a small logged-in area sit naturally beside public routes without inventing a second app.

Performance is a contract, not a wish. Image optimization, route-level loading boundaries, and streaming-friendly patterns are first-class. That matters when the business measures Core Web Vitals and conversion, not just “it loads fine on Wi‑Fi.”

2. When traditional React still wins

The site is behind login or is a pure dashboard. Crawlers do not care; first meaningful paint is dominated by data fetching after auth. A focused SPA with a known API is often simpler to reason about than carrying server rendering you never use.

You already own static hosting and a headless CMS pipeline. If content is built to static HTML at publish time (SSG elsewhere) and the React layer is thin, adding Next.js may duplicate that pipeline instead of clarifying it.

The team is small and only comfortable in client-only React. For a brochure site with five pages, a static export or a simple Vite build plus careful meta tags can ship faster than onboarding App Router, caching semantics, and deployment edge cases—if SEO risk is explicitly accepted.

3. Business questions that decide the stack

  • Who updates copy and structure? If marketing needs previews, drafts, and scheduled publishes, align the framework with the CMS (often Next + headless) rather than fighting a SPA.
  • Where will this run in three years? Vercel-style or Node hosting fits Next.js; pure S3 + CDN fits static SPAs. Mismatch creates hidden migration cost.
  • Forms and compliance: Server actions or API routes can keep secrets off the client; SPAs push more logic to a separate backend you must secure and monitor.

4. A simple rule of thumb

If the URL is meant to be discovered, ranked, or shared, bias toward Next.js (or another server-capable React framework) unless you have a deliberate static or edge pipeline. If the URL is mostly for authenticated users and SEO is irrelevant, a traditional React app remains a rational, maintainable choice.

Pick for distribution and operations, not for framework fashion—then invest in clear boundaries either way so the business can swap hosting or CMS without rewriting the whole front end.