Why Most React Apps Fail at SEO (and How Static Rendering Fixes It)

A huge number of React marketing sites and product sites are built as pure client-side-rendered (CSR) single-page applications: the server sends a nearly empty HTML file with a <div id="root"></div>, and JavaScript builds the entire page after it loads in the browser. This is a completely reasonable way to build an interactive application — and a real liability for anything that needs to be found, indexed, and cited by search engines and AI answer systems.

What actually breaks with pure CSR

Search engines that execute JavaScript (Google, Bing) still process rendering in a separate, delayed pass after the initial crawl, which can push indexing of new or changed content out by days or weeks. More importantly, a growing share of AI-driven discovery — answer engines, retrieval systems, and crawlers that power tools like ChatGPT's browsing mode or Perplexity — fetch pages with lightweight HTTP clients that don't execute JavaScript at all. To those systems, every route on a pure-CSR site can look identical: the same empty shell, regardless of which URL was requested. Titles, meta descriptions, structured data, and body content that only exist after JavaScript runs are simply invisible.

The fix isn't "add more meta tags" — it's rendering strategy

No amount of clever client-side document.title manipulation solves this, because the problem is what's in the initial HTML response, not whether the tags are eventually correct once JavaScript executes. There are three real fixes:

1. Full SSR (server-side rendering) — a Node.js server renders each page to HTML on every request. Powerful (supports fully dynamic, personalized content) but requires a persistent server process, which not every hosting environment supports.
2. SSG (static site generation) — every page is rendered to real HTML at build time, then deployed as plain static files. No server process needed at request time; the content is just... there, in the file, for any crawler that asks.
3. Prerendering an existing SPA — for teams that don't want to rewrite their app in a different framework, a build step can boot the already-built single-page app in a headless browser, visit every route, wait for it to fully render (including any client-side-injected meta tags and JSON-LD), and save the resulting HTML as static files per route.

What we actually did on this site

This site itself was originally a pure client-side-rendered Vite + React single-page application — the exact pattern described above, including page-specific metadata and schema.org markup that were injected after JavaScript ran, invisible to any crawler that didn't execute it. Rather than rewrite the entire application in a different framework, we added a build-time prerendering step: after the normal production build, a script boots the compiled app in headless Chromium, visits every route (including this blog), waits for the page to fully render, and writes the resulting HTML to disk as a real static file per URL. The same JavaScript bundle still loads afterward and takes over for client-side navigation — so the interactive experience is unchanged for visitors — but the first HTML response any crawler or AI system receives now contains real, page-specific titles, descriptions, structured data, and content.

When to reach for full Next.js SSR/ISR instead

If a site needs genuinely dynamic, per-request content — personalization, live pricing, authenticated dashboards — static generation isn't enough, and a framework with real server-side rendering (Next.js, Remix) running on infrastructure that supports a persistent Node.js process is the right call. For a primarily content-driven marketing site or blog, though, build-time static generation gets the same crawlability and AI-visibility benefits with a simpler deployment model: the output is just static files, deployable anywhere, including standard shared hosting.

The takeaway

If your React app's raw HTML (view source, not the rendered DOM) doesn't contain your actual page title, description, and content, no search or AI system that fetches without executing JavaScript can see it — full stop. Fixing that is a rendering-strategy decision, not a copywriting one.