Why Your React Site Is Not Ranking, and How Server Rendering Fixes It
A client-side React app can look perfect to you and be nearly invisible to a crawler. Here is what search engines actually see, and the change that closes the gap.
· Couve Stack
The empty div problem
Open a typical single-page React app, right-click, and choose View Source. You will not see your headline, your service copy or your case studies. You will see a nearly empty HTML document containing one element, usually a div with an id of root, and a script tag.
That document is what a crawler receives on its first request. Everything a visitor sees is assembled afterwards, in the browser, by JavaScript. For a human on a fast connection this is invisible. For a search engine it is the entire problem.
You can test your own site in about fifteen seconds. Load it with JavaScript disabled in your browser settings. Whatever remains on screen is the reliable floor of what search engines and AI answer engines can index.
What Google actually does with JavaScript
Google does render JavaScript, which is why this problem is widely dismissed. But rendering happens in a second pass, after the initial crawl, and that pass is queued against a finite rendering budget shared across the entire web.
For a large, authoritative site the delay is often short enough not to matter. For a new or mid-sized site it can mean days between a page being discovered and its content being seen, and during that window the page is competing on an empty document. Publish frequently and you can stay permanently behind the queue.
The situation is worse outside Google. Many crawlers, including several that feed AI answer engines and most social preview fetchers, do not execute JavaScript at all. To those systems, a client-rendered page has no content. That is why a link to an SPA so often previews as a bare title with no description.
Prerendering meta tags is not the same as rendering content
A common half-measure is a build script that injects unique title and meta description tags into the built index.html for each route. This is worth doing, and it is frequently mistaken for a complete fix.
It is not one. Injecting head tags gives each URL correct metadata while leaving the body empty. Search engines get a good title for a page whose content they still cannot read on first pass, so you rank for your own brand name and almost nothing else.
The distinction is easy to verify. Fetch your page with curl and read the response. If your h1 and body copy are not in that response, no amount of head-tag injection has solved the underlying problem.
The actual fix
Render the HTML before it reaches the browser. In practice that means static generation at build time for pages whose content changes on a deploy cadence, or server-side rendering per request for pages that must be personalised.
For a marketing site, case studies, service pages and articles, static generation is almost always right. Each route is built once into a complete HTML file containing every heading, paragraph and image tag. React still hydrates afterwards for interactivity, but indexing no longer depends on it.
The hosting requirement gets simpler rather than harder: static HTML files can be served from any host or CDN, with no Node process to keep alive. You gain crawlability and lose operational complexity at the same time.
What to verify after the change
Fetch each important route with curl and confirm your h1 and body copy appear in the raw response. This is the single check that matters most, and it takes a minute.
Then use the URL Inspection tool in Google Search Console on a live URL. The rendered HTML it reports is what Google sees. Compare it against your source and confirm nothing important is missing.
Finally, confirm each route emits exactly one canonical tag pointing at itself in the form you actually serve, matching on protocol, on www, and on trailing slash. Getting the rendering right and then splitting the signal across four URL variants of the same page wastes most of what you just gained.