React SEO: Why Your JavaScript Site May Be Invisible to Google

React SEO refers to the set of technical practices required to make React-built websites crawlable, indexable, and rankable by search engines. The core problem is straightforward: Google’s crawler does not always execute JavaScript the way a browser does, which means a React application that looks fully rendered to a human visitor may appear as a near-empty HTML shell to Googlebot. If your content lives inside JavaScript that never gets properly rendered during crawl, it does not rank.

This is not a theoretical concern. It is a practical, commercially significant problem that affects a meaningful share of modern web builds, and it is one that marketing teams often discover far too late, usually after a site migration has already gone live.

Why React Creates a Specific Problem for Search Engines

Traditional websites serve HTML directly. When Googlebot requests a page, it receives a document full of readable content. React applications work differently. By default, a React app serves a minimal HTML file that contains almost nothing except a root div element and a reference to a JavaScript bundle. The actual content, the headings, the body copy, the internal links, all of it, is generated by JavaScript running in the browser.

Google has stated publicly that it can render JavaScript. That is true, but the process is more complicated than it sounds. Googlebot operates what is known as a two-wave indexing process. In the first wave, it fetches and indexes the raw HTML. In the second wave, it returns to render the JavaScript. The gap between those two waves can range from a few hours to several days. During that window, your content may not be indexed at all. And if Googlebot encounters resource constraints, timeouts, or errors during rendering, the second wave may not happen as expected.

The practical consequence is that React sites built on pure client-side rendering carry real SEO risk, not because Google cannot theoretically handle JavaScript, but because the process is slower, less reliable, and more dependent on technical conditions that you do not fully control.

I have seen this play out more than once on the agency side. A development team builds a technically impressive React application, the marketing team signs off on the design, and six months after launch someone notices that organic traffic has flatlined or declined against the previous site. The diagnosis is usually the same: the new build is rendering content client-side, and Google’s index has a fraction of the pages the old site had. Fixing it at that point is a significant rebuild, not a configuration change.

If you want to understand how this fits into a broader SEO framework, the Complete SEO Strategy hub covers the full range of technical and strategic considerations that determine how sites perform in search.

What Are the Rendering Options and Which One Should You Choose?

There are four main rendering approaches for React applications, and the SEO implications of each are meaningfully different.

Client-Side Rendering (CSR) is the default React behaviour. The server sends a bare HTML shell and the browser runs JavaScript to build the page. This is the worst option for SEO because it maximises Googlebot’s dependency on JavaScript rendering. It works fine for applications that sit behind a login and do not need to rank, but for any public-facing content that needs organic visibility, it is a liability.

Server-Side Rendering (SSR) generates the full HTML on the server for each request before sending it to the browser. Googlebot receives a complete HTML document with all content present. This is the most reliable approach for SEO on dynamic content. The tradeoff is server load and response time: every page request requires server processing, which adds infrastructure complexity and cost at scale.

Static Site Generation (SSG) pre-renders pages at build time and serves them as static HTML files. From a crawlability standpoint, this is the cleanest possible option. Pages load fast, there is no server processing on request, and Googlebot gets complete HTML every time. The limitation is that content is only as fresh as the last build, which makes it unsuitable for highly dynamic content like real-time pricing or personalised feeds.

Incremental Static Regeneration (ISR), available in frameworks like Next.js, is a hybrid: pages are statically generated but can be revalidated and regenerated in the background on a schedule. It gives you most of the performance and crawlability benefits of SSG while allowing content to stay reasonably current. For most marketing sites and content-heavy React builds, ISR is worth serious consideration.

The choice between these approaches should be made before a single line of code is written. I have sat in enough project kick-off meetings to know that SEO requirements rarely make it into the technical brief unless someone in the room specifically raises them. If you are working with a development team on a React build and nobody has asked how Googlebot will receive the rendered HTML, that is the question you need to ask before the architecture is decided.

How Does Dynamic Rendering Work and When Does It Make Sense?

Dynamic rendering is a workaround for teams that cannot change their rendering architecture but need to improve crawlability. The approach uses a middleware layer, typically a headless browser service like Rendertron or Prerender.io, to detect when a request comes from a bot rather than a human user. Bot requests receive a pre-rendered, fully rendered HTML version of the page. Human users receive the standard JavaScript application.

Google has acknowledged dynamic rendering as an acceptable interim solution. It is not cloaking in the traditional sense, because the content served to bots and users is substantively the same, just in different formats. But Google has also indicated that dynamic rendering is a workaround, not a best practice, and that the preferred long-term approach is server-side rendering or static generation.

There are legitimate scenarios where dynamic rendering makes sense. If you have an existing React application with a significant organic traffic base and you cannot justify a full architectural rebuild in the short term, dynamic rendering can stabilise your SEO while a longer-term solution is planned. It is also useful during migrations, as a bridge between an old architecture and a new one.

The risks are worth understanding, though. Dynamic rendering adds infrastructure complexity. If your pre-rendering service goes down or returns errors, bots may receive broken or empty responses. It also requires ongoing maintenance to ensure the rendered output stays consistent with what users see. Treat it as a tactical solution with a defined lifespan, not a permanent fix.

What Technical SEO Elements Need Specific Attention in React?

Beyond rendering architecture, there are several technical SEO elements that require specific handling in React applications.

Meta tags and title management. In a standard HTML site, title tags and meta descriptions are static elements in the document head. In a React application, the document head is typically managed by JavaScript, which means meta tags may not be present in the initial HTML response. Libraries like React Helmet or the built-in head management in Next.js solve this by injecting the correct meta tags server-side, but they need to be implemented correctly and consistently across all page types.

Routing and URL structure. React applications often use client-side routing via React Router or similar libraries. This means that when a user navigates between pages, the URL changes and the view updates, but no actual HTTP request is made to the server. From a user experience perspective, this feels fast and smooth. From a crawling perspective, it means that if Googlebot cannot execute the JavaScript, it may only ever see a single URL. Ensuring that each route corresponds to a real, crawlable URL with its own HTML response is essential.

Structured data and schema markup. Schema markup injected via JavaScript may not be present in the initial HTML that Googlebot indexes in its first wave. For structured data to be reliably parsed, it should be included in the server-rendered HTML rather than added dynamically after page load. This is particularly important for product pages, article schema, and FAQ schema where structured data directly influences how pages appear in search results.

Lazy loading and infinite scroll. Both are common patterns in React applications and both create crawlability problems if implemented without consideration for bots. Content that only loads when a user scrolls down, or when a component enters the viewport, may never be seen by Googlebot. Pagination with discrete, crawlable URLs is generally more reliable for SEO than infinite scroll, even if it is less fashionable from a UX perspective.

Internal links. React applications sometimes render navigation and internal links as JavaScript-driven elements rather than standard anchor tags with href attributes. Googlebot follows href-based links. It does not reliably follow JavaScript onclick handlers or programmatic navigation calls. Every internal link that matters for crawl coverage needs to be a real anchor tag with a valid href.

When I was running iProspect and we were scaling the technical SEO practice, the internal link audit on JavaScript-heavy sites was one of the first things we would run. The number of navigation elements that looked like links to users but were functionally invisible to crawlers was consistently higher than clients expected. It is a quiet problem that compounds over time.

How Do You Audit a React Site for SEO Problems?

Auditing a React site for SEO issues requires a different approach than auditing a traditional HTML site, because the problems are not always visible in a standard crawl.

The first step is to compare what Googlebot sees against what a browser sees. Google Search Console’s URL Inspection tool will show you the rendered version of a page as Googlebot last saw it, including the rendered HTML. Compare that against the source HTML of the same page. If there is a significant difference, particularly if the rendered version is missing large sections of content, you have a rendering problem.

The second step is to check your index coverage. In Search Console, look at the ratio of submitted URLs to indexed URLs. A large gap between the two, particularly on a site that was recently migrated to React, is a signal that pages are not being indexed as expected. Cross-reference this with your server logs to understand how frequently Googlebot is visiting and whether it is successfully rendering pages.

The third step is to crawl the site using a tool that can render JavaScript, such as Screaming Frog with JavaScript rendering enabled, or Sitebulb. Compare the output against a non-rendered crawl. Pages that appear in the rendered crawl but not the non-rendered crawl are dependent on JavaScript execution. Whether that is a problem depends on your rendering architecture, but it is information you need.

The fourth step is to check your Core Web Vitals. React applications, particularly those with large JavaScript bundles, are prone to poor Largest Contentful Paint and Cumulative Layout Shift scores. These are ranking signals, and they are also user experience signals. A slow-loading React site is losing on both fronts. Google’s PageSpeed Insights and the Core Web Vitals report in Search Console will show you where you stand.

There is a broader point worth making here. Auditing a React site for SEO is genuinely technical work. It requires someone who understands both the JavaScript rendering pipeline and how search engines crawl and index content. Handing it to a generalist SEO who has never worked on a JavaScript-heavy site, or to a developer who has never thought about crawl behaviour, tends to produce incomplete diagnoses. The intersection of those two skill sets is where the useful answers live.

What Role Does Page Speed Play in React SEO?

Page speed is relevant to React SEO in two distinct ways. The first is as a direct ranking signal through Core Web Vitals. The second is as an indirect factor that affects crawl budget: slow pages take longer to crawl, which means Googlebot crawls fewer of them in a given session.

React applications are particularly susceptible to performance problems because of JavaScript bundle size. A large, unoptimised JavaScript bundle delays the time to first meaningful paint, inflates Largest Contentful Paint scores, and increases the time before the page becomes interactive. For users on slower connections or lower-end devices, this is a significant problem. For Googlebot, which simulates a mid-tier mobile device, it can mean that pages time out before they fully render.

Code splitting is the primary technique for managing bundle size in React. Instead of sending the entire application JavaScript to the browser on first load, code splitting allows you to load only the JavaScript required for the current page, with additional chunks loaded on demand. React’s built-in lazy loading and Suspense API support this pattern, as does automatic code splitting in Next.js.

Tree shaking, which removes unused code from bundles during the build process, is another important optimisation. Third-party libraries are a common source of bundle bloat. Importing an entire library when you only need one function from it adds unnecessary weight. Tools like Webpack Bundle Analyzer will show you exactly where your bundle size is coming from.

Caching strategy also matters. Static assets, including JavaScript bundles, should be served with long cache lifetimes and content-addressed filenames so that returning visitors and crawlers do not need to re-download unchanged files. A CDN with edge caching will further reduce latency for both users and crawlers.

What Are the Most Common React SEO Mistakes and How Do You Avoid Them?

The most common mistake is choosing client-side rendering by default without considering the SEO implications. React’s default behaviour is CSR. Developers building React applications are often focused on functionality and user experience, not crawlability. Unless someone in the project explicitly raises the SEO requirements before the architecture is decided, CSR tends to be what gets built. The fix is to make rendering architecture a defined requirement in the technical brief, not an afterthought.

The second most common mistake is assuming that because Google can render JavaScript, there is no problem. This is a misreading of Google’s guidance. The ability to render JavaScript is not the same as rendering it reliably, at scale, at the speed required for competitive indexing. The gap between “Google can render this” and “Google is rendering this correctly and indexing the content promptly” is where most React SEO problems live.

The third mistake is neglecting the technical SEO basics in the context of a new technology. Title tags, canonical tags, hreflang, structured data, XML sitemaps: none of these become less important because a site is built in React. They just require more deliberate implementation. I have reviewed React sites where the entire site shared a single title tag because the meta management library was misconfigured and nobody had checked. That is not a React problem, it is an attention problem, but React makes it easier to miss.

The fourth mistake is treating a React migration as a like-for-like replacement. If you are moving from a traditional CMS to a React application, the SEO implications of the new architecture need to be mapped against the old site’s performance before launch. URL structure changes, rendering changes, and navigation changes all carry migration risk. A proper pre-launch SEO review, including a crawl comparison and a rendering audit, should be a standard part of any React migration project.

There is a broader observation worth making. The gap between what development teams build and what marketing teams need is often widest on technical SEO. Developers are not trained to think about crawl behaviour. Marketers are often not equipped to ask the right technical questions. Bridging that gap requires either someone who can operate in both domains or a structured handoff process that forces the right questions to be asked at the right time. Neither is particularly common, which is why React SEO problems remain so widespread.

For context on how technical SEO fits within a complete search strategy, the Complete SEO Strategy guide covers everything from site architecture to content strategy to link building in one place.

Frameworks and Tools That Make React SEO More Manageable

Next.js has become the de facto standard for SEO-conscious React development. It supports SSR, SSG, and ISR out of the box, with sensible defaults and a large ecosystem of plugins and documentation. Its built-in head management, automatic code splitting, and image optimisation make it significantly easier to build React applications that perform well in search. If you are starting a new React project that needs to rank, Next.js is the obvious starting point.

Gatsby is another option, oriented toward static site generation. It is well-suited to content-heavy sites where content does not change frequently, such as marketing sites, documentation, and blogs. Its build times can become significant on very large sites, which is a practical constraint worth understanding before committing to it.

Remix is a newer framework that takes a different architectural approach, with a strong emphasis on server-side rendering and web standards. It is worth watching, particularly for applications that need real-time data alongside strong SEO performance.

For teams that need to add SSR to an existing React application without migrating to a new framework, tools like Rendertron and Prerender.io provide dynamic rendering capabilities. They are not substitutes for proper architecture, but they can be a practical bridge.

On the auditing side, Google Search Console remains the most important tool for understanding how Google is actually seeing your React site. Screaming Frog with JavaScript rendering enabled is useful for crawl analysis. Chrome DevTools’ Network tab and Lighthouse will show you performance characteristics and rendering behaviour. These tools together give you a reasonable picture of where problems exist, even if they do not always make the fixes straightforward.

The SEO community has produced good technical writing on JavaScript SEO over the past few years. Moz’s analysis of failed SEO tests is worth reading for a grounded perspective on where technical assumptions go wrong. Similarly, thinking about how SEO and paid channels interact is relevant when you are assessing the full cost of a React SEO problem, because lost organic visibility often gets partially masked by increased paid spend.

One final point. React SEO is a technical discipline, but the decisions that determine whether a React site performs well in search are often made in project scoping meetings, not in code reviews. The most effective intervention is usually not a post-launch audit, it is being in the room when the architecture is decided and knowing which questions to ask. That is a skill set that sits at the intersection of marketing strategy and technical understanding, and it is one that most agencies and most in-house teams are still developing.

When I was first handed the whiteboard pen in a client brainstorm early in my career, the instinct was to defer to someone more senior. That instinct is understandable, but it is also how problems get built into projects that should have been caught at the start. React SEO is one of those areas where the cost of deferring the conversation is almost always higher than the cost of having it early.

About the Author

Keith Lacy is a marketing strategist and former agency CEO with 20+ years of experience across agency leadership, performance marketing, and commercial strategy. He writes The Marketing Juice to cut through the noise and share what works.

Frequently Asked Questions