All articles

Website development

React SPA SEO: Diagnose Rendering and Indexing Problems

Diagnose React indexing through direct HTML, rendered content, metadata and route behavior. Compare rendering fixes and verify the deployed result.

By , Founder, Luminous Digital Visions
Published · Updated

Source code displayed on a laptop
Illustrative photograph from the original article, sourced from Unsplash.

Diagnose the response before blaming the framework

A React site can look complete in a browser while a direct URL response contains only an application shell. That difference deserves investigation, but it does not prove that Google cannot index React.

This guide examines initial HTML, rendered content, deferred sections and deployment routing. The earlier version attributed a long indexing delay to rendering alone; that causal claim was not established by the evidence included in the article. Use the checks below to distinguish access, rendering and indexing problems on your own site.

What Google actually sees

What Google sees vs. what you see

Open your React SPA in a browser. You see a polished website with animations, images, blog articles, service pages. Everything looks perfect.

Now right-click, View Page Source.

You see this:

<!doctype html>
<html lang="en">
<head>
  <title>Your Full-Stack Digital Partner for Growth</title>
</head>
<body>
  <div id="root"></div>
  <script type="module" src="/src/main.tsx"></script>
</body>
</html>

An empty div and a JavaScript file. That is the entirety of what your server sends to every visitor, every crawler, every search engine, on every single URL.

When a regular browser loads this, JavaScript executes, React mounts, the router reads the URL, the correct component renders, and react-helmet-async swaps in the right title and meta tags. It all happens in milliseconds. You never notice.

Googlebot works differently.

How Google processes JavaScript pages

Google can render JavaScript, but successful indexing still depends on fetching the URL and its required resources, rendering the relevant content and interpreting the result. A blank initial response is a diagnostic observation, not proof that Google can never index a React application.

Inspect the initial HTML, rendered DOM and Search Console URL Inspection result. Check direct route loading, status codes, robots controls, canonical tags and blocked or failing scripts. Do not assume a browser-only screenshot tells you what a crawler received.

Google’s JavaScript SEO documentation explains its processing model. Pre-rendering or server rendering can make content available more directly, while an application can still use React for interaction.

Make the initial response useful

Serving meaningful HTML and page-specific metadata directly reduces dependence on JavaScript execution. It also helps link-preview services that read the response without running the application.

Keep titles, descriptions, canonical URLs and social images correct for each route. Verify both the response and the browser result. Assistive technologies can work with dynamic content, but accessible semantics, focus management and usable controls still need testing.

Static generation, server rendering and pre-rendering are delivery options. React can still provide interaction. Choose the approach that fits the site’s freshness, personalization and hosting requirements.

Check content that depends on interaction

Content inserted only after scrolling or clicking may be missing from a crawler’s rendered result. Keep essential headings, body copy and links available without those actions, and use lazy loading carefully for nonessential work.

Inspect reveal animations and loading placeholders as well. Test with JavaScript disabled, reduced motion and a failed script request. A brief opacity animation is not proof of an indexing penalty; the useful question is whether content remains available and usable when the enhancement fails.

Compare the browser DOM with URL Inspection and record the exact missing element. Repair the specific dependency rather than hiding all animations or replacing the framework without evidence.

Choose a rendering fix you can maintain

For a mostly static marketing site, generating HTML during the build can make every public route directly accessible. For frequently changing or personalized content, server rendering or a mixed approach may be more appropriate.

If capturing a browser-rendered page, use an explicit readiness signal, verify that essential content has loaded and exclude private or user-specific state. Network idleness alone does not prove that a page is complete.

Ensure that the deployed route serves the generated file and that client-side initialization preserves it correctly. Compare links, metadata and body content before and after hydration. Keep a route inventory so dynamic slugs are not silently omitted.

Test the actual Vercel build and route configuration

A browser-based pre-render step needs a compatible browser binary and dependencies in the build environment. Test the exact package versions and resource limits before relying on a local success. If the build can generate HTML directly, it may avoid that extra dependency.

Configure explicit public routes, permanent redirects for changed addresses and a real 404 response for unknown paths. Avoid a catch-all application rewrite that returns the homepage for missing articles.

Build a preview using production-like settings, inspect direct responses and test deep links with and without JavaScript. Keep private reports, source archives and environment files out of the public output.

Compare rendering behavior, not framework labels

A client-rendered React app relies on JavaScript for its initial content unless another rendering step supplies it. A server-rendered or statically generated React app can send meaningful HTML directly. Next.js and other frameworks provide options, but configuration determines the result.

Astro or a static generator can suit content-heavy sites. Plain HTML can suit a small site with a manageable editing process. Authenticated applications may prioritize interaction over public indexing.

Test the page that will ship: status code, content, metadata, links, performance and accessibility. No framework guarantees indexing, perfect crawlability or the fastest possible page.

Pre-launch SEO checklist for SPAs

If you already have a React SPA in production and cannot migrate to a different framework, run through this checklist:

HTML delivery

  • View Page Source on every key page. Is the content visible without JavaScript?
  • Does each page have a unique <title> and <meta name="description"> in the raw HTML?
  • Is your structured data (JSON-LD) present in the raw HTML?
  • Are Open Graph tags present in the raw HTML (not injected by JavaScript)?

Content visibility

  • Are any sections deferred behind IntersectionObserver? Google does not scroll.
  • Do any elements start with opacity: 0 or display: none and rely on JavaScript to become visible?
  • Do CSS animations use fill-mode: both or fill-mode: backwards with a starting opacity of 0?
  • Are React.lazy() chunks loading fast enough for the renderer to capture them?

Technical SEO

  • Does every page have a <link rel="canonical"> in the raw HTML?
  • Is your sitemap submitted in Search Console and returning a 200 status?
  • Does the www to non-www redirect (or vice versa) work correctly for all paths?
  • Are 404 pages returning actual 404 status codes (not 200 with "not found" text)?

Prerendering (if implementing)

  • Are pre-rendered HTML files being served before the SPA fallback rewrite?
  • Does the prerender script handle all dynamic routes (blog slugs, service areas)?
  • Is IntersectionObserver being patched during prerendering?
  • Are animation-related opacity: 0 styles being stripped during prerendering?
  • Does the Chromium binary work in your CI/CD build environment?

Verify the result after changing rendering

After a rendering change, confirm that important routes return meaningful content and the correct status directly. Compare visible content, canonical tags, internal links and structured data between the initial response and the browser view.

Use URL Inspection and subsequent page-level Search Console reporting to assess what Google fetched and indexed. Keep the release date and affected URL list. A build or Lighthouse score does not prove indexing, and this guide does not assign an unsupported traffic gain to the rendering change.

For a different access problem with dated project evidence, see the Bluehost Googlebot 403 case study. For implementation, explore Luminous website development.

Common React indexing questions

Can Google execute JavaScript?

Yes. Check Google’s JavaScript SEO guidance and inspect the actual fetched and rendered page. Rendering success does not guarantee indexing.

Is client-side metadata enough?

It may appear after rendering, but a fetcher that reads only the initial response can receive fallback tags. Serve page-specific metadata directly when possible and verify social previews.

Will pre-rendering preserve application behavior?

Only if routing, state and initialization work with the generated HTML. Test direct entry, navigation, forms and hydration errors.

Should we rewrite the site?

Diagnose the problem first. A missing route, blocked asset or rendering dependency may have a smaller fix. Evaluate the long-term editing and deployment requirements before changing frameworks.