Home/React SEO

Diagnosis, not a checklist

React SEO: why Google can't see your app

React SEO is not a plugin problem. If your pages are rendered in the browser, Googlebot has to execute your JavaScript before it sees any content, and that step fails quietly more often than anyone admits. This page walks the actual diagnosis: how to prove what Google renders, which of the four rendering strategies fixes it, and what each one costs you.

Start with the diagnosis Send us a URL

curl, no JavaScript

what a crawler sees first

<div id="root"></div>

<!-- 0 words of content -->

<script src="/assets/index.js">

</script>

Server HTML0 words

After JS executes1,840 words

Run this on your own URL before reading further. It is the whole diagnosis in one command.

Prove it before you fix it

Four strategies, real tradeoffs

Costs stated, not hidden

Written by people who fix these

01 / The mechanism

SEO with React: why the two conflict at all

Nothing about React is hostile to search. Everything filed under seo in reactjs comes down to one thing: where rendering happens, and client-side rendering puts your content behind a step the crawler may skip.

React.js SEO has one mechanism behind it. A server-rendered page arrives as HTML with the words already in it. A client-rendered React app arrives as an empty <div id="root"> plus a JavaScript bundle. Googlebot has to download that bundle, execute it, wait for your API calls to resolve, and only then read the result. It does do this — but on its own schedule, with a budget, and any failure in that chain produces an indexed page with no content.

The render queue is not instant

Google crawls HTML immediately and queues JavaScript rendering separately. For a large or low-authority site that gap can be days. Publish a page today, get it indexed with content next week — or not at all.

Your API is now part of SEO

If content arrives via fetch, then a slow endpoint, an auth wall or a rate limit means the crawler renders an empty state. Your search visibility is only as reliable as your slowest request.

Errors fail silently

One uncaught exception during hydration and the crawler keeps whatever HTML existed at that moment. Users never see it because their browser retried; the crawler did not.

Bots that do not render at all

Bing renders inconsistently. Most LLM crawlers, Slack unfurls, LinkedIn previews and Twitter cards read raw HTML only. Client-side rendering makes you invisible to all of them.

So the honest answer to is React good for SEO is: React is neutral, your rendering strategy is what decides it. Everything filed under seo react, react seo optimization or making a react seo friendly build reduces to that one decision. Google's own guidance on JavaScript SEO basics says the same thing in more words.

02 / Diagnosis

Four checks that prove what Google actually sees

Do these before changing any code. Most React SEO advice skips straight to a fix, which is how teams end up migrating to Next.js to solve a problem that was one missing meta tag.

01

Fetch the page with JavaScript disabled

curl -s https://yoursite.com/page | wc -w gives you the word count a crawler reads on first pass. Under 50 words means your content does not exist in the server response. This one command tells you more than any audit tool.
02

Use the URL Inspection tool, then read the rendered HTML

Search Console shows what Googlebot actually rendered, not what your browser renders. Compare it against the live page. Missing sections, empty lists and absent meta tags all show up here, and this is the evidence you take to a stakeholder.
03

Check the crawl stats and the render budget

If Search Console reports pages as Discovered but not indexed at volume, the render queue is your bottleneck. That is a rendering-strategy problem, not a content problem, and no amount of writing will fix it.
04

Test what non-Google bots see

Paste a URL into Slack and see whether the unfurl has a title. Run it through a link preview debugger. If those are empty, so is what every LLM crawler and social platform stores about your page.

What the results mean

Content present in server HTML but ranking badly is a normal SEO problem: titles, internal links, thin pages. Content absent from server HTML is a rendering problem and nothing else you do will matter until it is fixed. Those two diagnoses lead to completely different work, which is why guessing is expensive.

03 / The fix

Four rendering strategies, and what each one costs

No option is best. Pick the one that matches how often your content changes.

null

StrategyRight when, and what it costs you

Static (SSG)

Content changes on a deploy cadence: marketing pages, docs, a blog. Fastest possible response and nothing to run.

CostRebuild to publish. Painful past a few thousand pages unless incremental.

Server rendering (SSR)

Most common fix

Content is per-request or personalised, and must be in the HTML. The default correct answer for most apps with public pages.

CostA server to run and pay for, plus a slower response than static. Caching becomes your problem.

Incremental / ISR

Large catalogues that change often but not per-request — listings, products, user profiles at scale.

CostCache invalidation, which is genuinely hard to reason about and easy to get subtly wrong.

Prerendering / dynamic rendering

A retrofit when rewriting is not viable. A service renders for bots and serves them HTML.

CostTwo code paths to keep in sync, a monthly bill, and a divergence risk Google has warned about.

Two things worth saying plainly. Most teams asking about react seo ssr need server rendering on a handful of routes, not a full migration — the marketing pages and the public catalogue, while the dashboard behind the login stays client-rendered forever because Google should never see it. And dynamic rendering for React SEO is a workaround, not a destination; it buys you time to do the real fix.

If you are choosing between plain React and Next.js for a new build, that decision is set out on the hire React page, and the short version is that search traffic is the single clearest reason to take the framework.

04 / In code

An example of SEO in React, in code

The same page component, client-rendered and then server-rendered. This is the whole difference, and it is smaller than the migration anxiety around it suggests.

Client-rendered — crawler sees an empty shell0 words in HTML

export default function Article({ slug }) {

  const [post, setPost] = useState(null);

  useEffect(() => {

    fetch(`/api/posts/${slug}`)

      .then(r => r.json()).then(setPost);

  }, [slug]);

  if (!post) return <Spinner />;   // <- what the bot indexes

  return <h1>{post.title}</h1>;

}

Server-rendered — content is in the response1,840 words in HTML

export default async function Article({ params }) {

  const post = await getPost(params.slug);

  return <h1>{post.title}</h1>;

}

export async function generateMetadata({ params }) {

  const post = await getPost(params.slug);

  return { title: post.title, description: post.excerpt };

}

The SEO advantages of server-side rendering in React are visible in that diff: the second version has no loading state, no effect, and no spinner for a crawler to index. It also fixes something the first version could never do properly: per-page titles and descriptions, generated on the server, which is the other half of why client-rendered apps underperform in search.

Metadata per route

Titles and descriptions that differ per page, present in the HTML. A single index.html cannot do this, whatever your router does at runtime.

Real status codes

A missing page returns 404, not 200 with a client-side "not found". Soft 404s are one of the most common React SEO findings.

Canonicals and sitemaps

Generated from the same data as the routes, so they cannot drift. Hand-maintained sitemaps are always out of date.

05 / Findings

React website SEO: eight findings from every audit

Ordered by how often they appear. The first three are rendering; the rest are ordinary SEO that client-side apps happen to get wrong more than server-rendered sites do.

One title for every route

The router changes the view but not the document head, so every page shares an identical title and description. Google deduplicates and picks one.

9 in 10

Content behind a fetch

Words arrive after an API call the crawler may not wait for. The page indexes as a shell.

7 in 10

Soft 404s

Missing pages return HTTP 200 with a client-rendered "not found". Google indexes them as real pages and quality signals fall.

6 in 10

No sitemap, or a stale one

Hand-maintained, months out of date, listing routes that no longer exist. Generate it from your route data.

6 in 10

Links that are not links

Navigation built on onClick handlers and divs. Nothing to follow, so nothing gets discovered.

5 in 10

Images with no dimensions

Layout shift on every load. It is a Core Web Vitals failure and it is two attributes.

5 in 10

Paginated lists with no crawlable URLs

Infinite scroll with no page parameter means everything past the first screen is invisible.

4 in 10

No structured data

Nothing to mark up because nothing is in the HTML. Fix rendering first, then this becomes trivial.

4 in 10

The first three are the ones worth your attention, and they are what seo for react apps and seo for react websites actually mean in practice. They are also the three that a lighthouse score will not tell you about, because Lighthouse runs JavaScript and therefore sees the page the way a user does rather than the way a crawler does on first pass.

06 / Migration

What a React SEO rebuild actually involves

Most of these arrive as "we need SSR". Most of them do not need a full rewrite — they need three routes moved and the head fixed.

01 Week 1

Audit and evidence

Run the four checks, document what Google renders per template, and split findings into rendering versus ordinary SEO. You get the document whether you continue or not.

02 Week 2

Route triage

Decide which routes need to be crawlable at all. Dashboards behind auth stay client-rendered. This step usually cuts the migration in half.

03 Weeks 3 to 5

Move the public routes

Server render or statically generate the routes that matter, with metadata generated from the same data. Old routes keep working throughout.

04 Week 6

Redirects and canonicals

Every changed URL gets a 301. Canonicals, sitemap and robots generated from route data so they cannot drift.

05 Weeks 7 to 8

Measure, then hand over

Re-run the four checks, compare indexed pages and impressions against the baseline, hand over a runbook. Numbers before and after, or it did not happen.

Typical shape

8wks

One senior engineer with review. Ranking recovery lags the work by four to twelve weeks, so measure indexing first and traffic later.

Two weeks of that is diagnosis and triage before any code moves, and it is the part that stops you paying for a migration you did not need. Scoped delivery of this shape is priced on the development services page; if you would rather run it with your own team, hire ReactJS developers covers the engineer route.

07 / Honestly

When React SEO work is not the answer

Four situations where the rendering fix will not help, and we would rather say so than bill for it.

Your content is thin

If the page has 200 words that nobody would link to, rendering it server side just means Google can now see that it is thin. Rendering fixes visibility, not merit.

Everything sits behind a login

A dashboard has no organic search surface. Server rendering it costs money and returns nothing. Keep it client-rendered and spend the budget on the marketing site.

You have no domain authority yet

Rendering gets you eligible to rank. It does not get you ranked. If nobody links to you, fix that first — it is slower and less fun and it matters more.

The real problem is a penalty or a migration gone wrong

Lost redirects, duplicate content across locales, a botched replatform. Those look like React problems and are not. Diagnose before rebuilding.

08 / FAQ

Questions we get asked

The ones that come up on every call about React and search, answered without hedging.

+Is React good for SEO?

React is neutral. Your rendering strategy decides it. A statically generated React site outperforms most WordPress installs; a client-rendered one can be invisible. The framework is not the variable.

+Is React JS SEO friendly out of the box?

No, if "out of the box" means Create React App or Vite with client rendering. You get one title for every route and an empty HTML shell. Both are fixable, and neither is fixed by default.

+Does Google actually render JavaScript?

Yes, but on a queue and with a budget. That is the whole problem: it works in a test and fails at scale, or works for your homepage and not for page 40 of a catalogue.

+What are React SEO best practices, briefly?

Get content into the server response, give every route its own title and description, return real status codes, make links anchors, generate the sitemap from route data, and set image dimensions. In that order.

+How to make a React website SEO friendly, in order?

Run the four checks first so you know which problem you have. Then: get content into the server response, give every route its own title and description, return real status codes, make navigation use anchors, generate the sitemap from route data, set image dimensions. Doing them in that order matters, because the last four are wasted effort while the first two are broken.

+Do I need Next.js for React SEO?

Not necessarily. Static generation with Vite plus a prerender step works for a small marketing site. Next.js earns its complexity when you have many routes, per-request content, or both — and that is most apps with a public catalogue.

+What about dynamic rendering for React SEO?

It works and Google tolerates it, but it is a workaround: two code paths, a monthly bill, and a divergence risk. Use it to buy time, not as the destination.

+How long until rankings recover after a fix?

Indexing usually improves within two to four weeks. Rankings and traffic lag by four to twelve. Anyone promising a faster curve is selling something.

+Can you fix this without rewriting our app?

Often, yes. The most common outcome is three to six public routes moved to server rendering while the authenticated app stays exactly as it is. The full rewrite is the rarest answer, not the default.

+How do we know the fix worked?

The same four checks that produced the diagnosis, re-run: server-side word count, rendered HTML in URL Inspection, indexed page count, and bot previews. Same method at both ends or the numbers mean nothing.

+Does SSR hurt performance?

It changes the tradeoff. Time to first byte goes up slightly; time to visible content goes down a lot. For content pages that is the right trade, and it is why LCP usually improves after the move.

Where to go from here

If your app is a single page application specifically, the vocabulary differs but the diagnosis does not — same four checks, same four strategies. If you want this done rather than explained, a scoped rebuild is priced on the development services page, and hire ReactJS developers covers putting an engineer on your team to do it instead. Our case studies carry the before and after numbers from one of these, including the two weeks we spent on the wrong theory. If the framework decision itself is still open, React or Next.js, choosing between them honestly weighs it without the marketing.

Send us one URL. We'll tell you what Google sees.

Free, and you get the four checks run against your own page in writing. If the answer is "your rendering is fine, your content is thin", we will say that.

Get the diagnosis

Two working days, from an engineer.
Pune, India. Four hours overlap with New York.