Built in React and invisible on Google? JavaScript SEO basics
Short answer: Google can run JavaScript, but a site that only shows content after scripts run is slower and riskier to index. Pages may wait in a rendering queue, links built without real <a href> elements aren't followed, and a stray noindex in the initial HTML can stop rendering altogether. Check what Google sees with Search Console's URL Inspection tool, then fix links, titles and status codes, and move important pages to server-side or static rendering where you can.
React, Vue and similar frameworks are excellent for apps. The problems start when the marketing site, the product pages or the blog are built the same way as the logged-in dashboard, and nobody checks how a crawler sees them.
Symptoms
You're probably looking at a JavaScript rendering issue if:
- Search Console shows pages as "Discovered" or "Crawled" but not indexed, or indexes them with the wrong title.
- Google's results show the same title or description for many pages.
- "View source" in your browser shows an almost empty
<div id="root"></div>and a script bundle. - Only the homepage is indexed; inner pages aren't found at all.
- Deleted or non-existent URLs show up as indexed pages with "Not found" text.
How Google handles a JavaScript page
Google's JavaScript SEO documentation describes three phases: crawling, rendering and indexing.
- Googlebot fetches the URL, after checking robots.txt.
- Pages with a 200 status code go into a rendering queue. Google says a page may stay there for a few seconds, but it can take longer.
- When resources allow, a headless Chromium renders the page and runs the JavaScript.
- Google parses the rendered HTML for links and uses it for indexing.
Two consequences matter for small sites. First, if your content only exists after rendering, indexing depends on that queue. Second, if the HTTP response isn't 200, Google says rendering might be skipped.
Checks
Check 1: What does the raw HTML contain?
Open the page, view source (not the browser's element inspector, which shows the rendered result). If the main text, title and links aren't there, you're relying on rendering.
Check 2: What does Google render?
In Search Console, run the URL Inspection tool on the page and use the live test. Google's help says you can view a screenshot of how its inspection tool sees the page and open "More info" for loaded resources, JavaScript console output and the page code. Look for:
- the main content in the rendered HTML;
- blocked resources (scripts or APIs disallowed in robots.txt);
- JavaScript errors.
Check 3: Are your links real links?
Google's documentation is explicit: it can only discover links that are <a> elements with an href attribute. Navigation built from <div onClick> or buttons that call a router function is invisible to the crawler. Also check you aren't using URL fragments (#/products) to load different content; Google recommends the History API for client-side routing.
Check 4: Are titles and descriptions unique per page?
Google says you can set or change titles and meta descriptions with JavaScript, but they need to be unique and descriptive. A single-page app that never updates <title> gives every URL the same one.
Check 5: Do missing pages return errors?
In client-side routed apps, a "not found" view often returns 200, which Google treats as a soft 404. Google suggests either redirecting with JavaScript to a URL that returns a real 404, or adding noindex to error views with JavaScript.
Check 6: Is there a noindex in the initial HTML?
Google warns that if it finds noindex in the original page code, it may skip rendering, so removing it with JavaScript later may not work. Remove it from the server response for pages you want indexed.
Fixes
Render important pages on the server or at build time
Google's documentation says server-side or pre-rendering is still a great idea because it makes sites faster for users and crawlers, and not all bots can run JavaScript. web.dev's guide on rendering describes the options: server-side rendering sends HTML from the server; static rendering (prerendering) generates HTML at build time; client-side rendering builds the page in the browser. web.dev broadly encourages server-side or static rendering over full rehydration approaches.
In practice:
| Page type | Sensible rendering |
|---|---|
| Marketing pages, blog, help articles | Static generation at build time |
| Product and category pages that change often | Server-side rendering, cached |
| Logged-in dashboard, account area | Client-side rendering is fine; it shouldn't be indexed anyway |
Frameworks such as Next.js, Nuxt, Remix or Astro make the first two rows straightforward. Moving a client-only React app onto one of them is often less work than it sounds, because components can be reused.
Fix the navigation
Replace click handlers on non-link elements with <a href="/path"> elements (your router's link component usually renders one). Make sure every important page is reachable through links, not only through search boxes or filters.
Set metadata per route
Give each route its own <title>, meta description and canonical, ideally in the server-rendered HTML.
Handle errors properly
Return real 404s for missing items where you can. Otherwise use one of Google's two soft-404 strategies.
Version your assets
Google says its renderer caches aggressively and may ignore caching headers, which can lead to outdated JavaScript or CSS being used. Fingerprinted file names such as main.2bb85551.js avoid that.
Generate structured data reliably
Google supports JSON-LD injected with JavaScript, but test it in the Rich Results Test after deployment.
FAQ
Does Google index React sites at all?
Yes. Google renders JavaScript with an evergreen version of Chromium. The issues are delay, missed links and metadata, not an outright inability.
Do I need to rebuild everything with server-side rendering?
No. Start with the pages that should rank: homepage, services or product pages, and the blog. The app behind the login can stay client-side.
Is dynamic rendering still recommended?
Google's current basics guide recommends server-side or pre-rendering. Treat serving bots a separate version as a stopgap, not a plan.
Will other search engines and AI tools see my content?
Not all bots run JavaScript, as Google itself notes. HTML that contains the content serves all of them.
If your JavaScript site is live but Google only knows about the homepage, send us the URL and we'll check what crawlers actually receive.