React SEO: What Google Actually Indexes and Where Client Rendering Costs You

Google renders JavaScript and does index client-rendered React applications. The claim that React is bad for SEO has been outdated for years. What remains true is narrower and still matters: rendering is deferred, every other crawler is far less capable, and social platforms do not execute JavaScript at all.

So the useful question is not whether React can rank. It is which of those three specific costs apply to your site, because the answer determines whether you need server rendering or whether client rendering is genuinely fine.

Table of contents

• How Google actually processes a JavaScript page
• Where client rendering genuinely costs you
• Choosing a rendering strategy
• What to get right regardless
• The Open Graph fix
• Measuring rather than guessing
• How this fits the rest of the stack
• FAQ

How Google actually processes a JavaScript page

Indexing happens in two passes, and the gap between them is the whole issue.

1. Crawl. Googlebot fetches the HTML. For a client-rendered app that is a near-empty div and a script tag. Links in the initial HTML are discovered here; links that only exist after rendering are not.
2. Render. The page is queued for rendering, executed in a headless browser, and the resulting DOM is indexed.

The render queue is where the delay lives. Google has said the median wait is short — often seconds — but the distribution has a long tail, and the wait is longer for sites with less crawl budget. A new or low-authority site can wait considerably longer than a well-established one.

For most content that delay is irrelevant. For anything time-sensitive — news, listings, events, stock — it is the difference between being indexed while the content matters and after it does not.

The other consequence is link discovery. Links that appear only after JavaScript runs are found in the second pass, so discovering a deep page requires rendering its parent first. On a large site this compounds into slow, incomplete crawling.

Where client rendering genuinely costs you

Four specific problems, in order of how often they matter:

• Social previews are broken. Facebook, LinkedIn, Slack, WhatsApp, and X read Open Graph tags from the initial HTML and do not execute JavaScript. A client-rendered page has whatever the index.html template contains — usually the same generic title and description on every URL. Every shared link looks identical.
• Other search engines lag. Google’s rendering is genuinely good. Others range from limited to none, which matters where they hold real market share.
• Metadata is set too late. Titles and descriptions set with a client-side effect exist only after hydration. Google usually catches them; anything that reads raw HTML does not.
• Largest Contentful Paint suffers. The user waits for HTML, then JavaScript, then data fetching, then render. Core Web Vitals are a ranking signal and LCP is the one client rendering hurts most.

The social preview problem is the one that costs measurable traffic and gets noticed last, because nothing reports it. Someone shares a link, the preview is wrong, and the click-through is a fraction of what it would have been.

Choosing a rendering strategy

The options, and which problem each solves:

• Static generation (SSG). Pages built at deploy time into real HTML files. Fastest possible delivery, perfect for crawlers, and content changes require a rebuild. Right for marketing pages, documentation, and blogs.
• Server rendering (SSR). HTML generated per request. Handles personalised or frequently changing content, and needs a running server rather than a static host.
• Incremental regeneration. Static pages regenerated on a schedule or on demand. A middle ground for large catalogues that change occasionally.
• Client rendering (CSR). Everything in the browser. Correct for anything behind a login, which search engines cannot see anyway.

The decision is usually per route rather than per application, and that is the part people miss. A product listing wants SSG or SSR; the account dashboard behind it should be client rendered because indexing it is meaningless.

The rule of thumb: if a page should appear in search results or be shared as a link, it needs HTML from the server. If it only exists after login, client rendering costs nothing.

What to get right regardless

Several things matter no matter which strategy you pick, and they are the most commonly missed:

1. Real anchor tags. A div with an onClick handler is not a link. Crawlers follow href attributes on anchor elements. Client-side routing is fine as long as the underlying element is an anchor with a real href.
2. Unique titles and meta descriptions per route. The single highest-value on-page item and the easiest to leave as a template default.
3. Canonical URLs, especially where query parameters produce multiple URLs for the same content.
4. A sitemap listing real URLs, which helps discovery enormously on a client-rendered site where link discovery is otherwise slow.
5. Correct status codes. A client-rendered 404 that returns HTTP 200 is a soft 404, and search engines handle those badly. The server must return the real status.

That last one is a genuine trap for single-page applications. A route the client treats as not-found still returns 200 from a static host with SPA fallback, so search engines see a valid page with error content and index it.

The Open Graph fix

If the only real problem is social previews — which is common for otherwise well-performing apps — the fix does not require rewriting the application.

Social crawlers identify themselves in the user agent and read only the initial HTML. Two workable approaches:

• Prerender the shareable routes. Generate static HTML with correct Open Graph tags for the pages people share, and let the rest stay client rendered. This is the smaller change and it works.
• Serve metadata at the edge. Inject the correct tags into the HTML template based on the requested path before it reaches the client.

What to avoid is user-agent sniffing that serves different content to crawlers than to users. Serving prerendered HTML to everyone is fine and is what static generation does. Serving crawlers something users do not see is cloaking, and it is penalised.

The distinction is whether the content differs, not whether the delivery mechanism does.

Measuring rather than guessing

Most React SEO discussion is theoretical when it does not need to be. The checks that give real answers:

1. View source, not the inspector. The inspector shows the rendered DOM; view-source shows what the server sent, which is what crawlers get on the first pass. If your content is not in view-source, it depends on rendering.
2. Use the URL inspection tool in Google Search Console to see the rendered HTML Google actually produced for a specific URL. This is authoritative and it is the only way to know for certain.
3. Check the Coverage report for pages that are crawled and not indexed, which is where rendering problems surface as a pattern.
4. Test a social preview with a platform’s own debugging tool before assuming it works.
5. Measure LCP with field data, not lab data. Real users on real connections produce numbers that differ substantially from a fast local machine.

The view-source check takes five seconds and settles most arguments. Everything visible there is indexed immediately; everything else waits for rendering.

How this fits the rest of the stack

The practical shape of this is that different routes want different rendering, which means a site is often a static build and a running service side by side rather than one or the other. Static sites on RunxBuild build from the repository with headers, redirects, and SPA fallback as declared rules, and 120GB of bandwidth is included before it becomes $0.10 per GB — worth knowing when prerendering multiplies the page count. Static sites on RunxBuild covers the build side, and the RunxBuild hosting calculator itemises the static site, the API, and the database so you can see them separately.

Useful related references:

• Domain Migration: DNS Plan, 301 Redirects, and SEO Preservation
• Render SEO: Static Metadata, Server Responses, and the Crawl Budget Nobody Sees
• Generate a PDF from a React App: A Practical Walkthrough
• Services on RunxBuild

FAQ

Can Google index a client-rendered React site?

Yes. Google executes JavaScript and indexes the rendered result. The costs are that rendering happens in a second pass with a delay, and that link discovery is slower because links appearing only after rendering are not found in the first crawl.

Why do my shared links show the wrong preview?

Social platforms read Open Graph tags from the initial HTML and do not run JavaScript. A client-rendered page serves whatever is in the index.html template, so every URL shows the same generic preview.

Do I need server-side rendering for SEO?

For pages that should rank or be shared, yes — they need real HTML from the server. Anything behind a login can stay client rendered, since search engines cannot see it either way. The decision is per route, not per application.

What is a soft 404 in a React app?

A page the client treats as not found while the server returns HTTP 200, which happens with SPA fallback routing. Search engines handle these badly and may index the error page. The server must return the real status code.

How do I check what Google sees on my page?

Use view-source rather than the browser inspector — the inspector shows the rendered DOM, view-source shows what the server sent. For an authoritative answer, use the URL inspection tool in Google Search Console.