JavaScript and SEO: a technical rendering guide

When a site built with React, Vue or any modern JavaScript framework loads in a user's browser, the HTML that arrives initially is often close to empty: a <div id="root"></div> that JavaScript itself fills in afterward, in the browser, with the real content. That pattern (Client-Side Rendering, CSR) works perfectly for the user because their browser executes the JavaScript in milliseconds, but it introduces a real SEO problem many development teams underestimate: crawlers don't always see the same thing, or see it at the same time.

How Google actually renders JavaScript: the two real phases

Google doesn't ignore JavaScript (that stopped being true years ago), but it doesn't process it immediately the way a browser does either. The internal process has two phases separated in time. In the first, Googlebot crawls the URL and gets the initial HTML exactly as the server serves it, without executing a single line of JavaScript; that HTML is what gets provisionally indexed first and what determines, among other things, the links Google discovers immediately. In the second phase, which can happen minutes, hours or (on sites with low crawl priority) days later, Google queues the page for rendering with a version of Chromium, executes the JavaScript the way a real browser would, and updates the index with the content that appears after that execution.

The practical consequence of this gap is that any content or link that only exists after JavaScript executes lives in a temporary limbo: it exists for Google, but not immediately. On sites that publish content very frequently (news, short-lived offers), that delay can mean the relevant content is no longer relevant by the time it's finally rendered.

SSR, SSG and hydration: what to choose depending on the project

The most reliable way to avoid depending on that second phase is for the server to already deliver the complete HTML, with the real content present, before a single line of JavaScript reaches the browser. There are two main strategies to achieve this. Server-Side Rendering (SSR) generates the complete HTML on the server on every request, always combining fresh data with the markup; it's the right choice for content that changes per user or very frequently (internal search results, dynamic pricing, personalized content). Static Site Generation (SSG) generates that same complete HTML, but in advance, at build time, and then serves it as static files; it's the fastest and cheapest to serve, ideal for content that doesn't change constantly (blog pages, landing pages, catalogs updated in batches).

Both strategies are usually combined with hydration: the HTML arrives already complete and visible, and JavaScript runs afterward only to "attach" to that HTML and add interactivity (clicks, forms, animations), without having to regenerate the content from scratch. For SEO, what matters isn't which framework is used but that the relevant text content is present in the HTML served before any JavaScript execution.

How to check what Google actually sees, not what you assume it sees

The most reliable check isn't opening the browser's "view source" (which shows the initial HTML, useful but incomplete) nor trusting that "it looks fine in the browser" (that only confirms it works for users, not for crawlers). The correct tool is Search Console's URL Inspection, which shows the rendered HTML exactly as Googlebot processed it on its last visit, including a screenshot of how the page looked after executing the JavaScript. If the content you want to rank for doesn't show up there, it isn't reaching Google regardless of how perfectly it looks in your own browser.

// Quick check from the browser console:
// disable JavaScript and reload to see the "raw" HTML
// (approximates, doesn't replace, what the first crawl phase sees)
document.querySelector('html').outerHTML.length

JavaScript-generated internal links: the most common trap

A widespread mistake on sites with menus or pagination built from interactive components: using <div> or <span> elements with an onClick in JavaScript to simulate navigation, instead of a real <a href="...">. A browser executes that onClick without issue, but a link with no href attribute isn't a crawlable link: Google doesn't follow it in the first crawl phase (raw HTML) and, even though it does execute the JavaScript in the rendering phase, extracting links to keep discovering new pages is far more reliable from real hrefs than from simulated click events.

<!-- Bad: not a crawlable link -->
<div onclick="navigate('/products/chair')">View chair</div>

<!-- Good: real href, still works with JS for the SPA transition -->
<a href="/products/chair" onclick="navigate(event, '/products/chair')">View chair</a>

Content that only loads after a scroll or an interaction

Infinite scroll and content that only loads on a "load more" click raise the same problem from another angle: Googlebot doesn't scroll or click the way a curious user would, so content that only appears after those actions may never get crawled at all. The most robust technical solution is real pagination with its own URL for each content block (even if, visually, for the user, it loads as infinite scroll via JavaScript), so there's always a path based purely on href links that lets Google reach each content chunk independently.

Rendering budget: why it's limited too

Executing JavaScript is computationally far more expensive for Google than reading static HTML, so rendering doesn't just carry the time gap already explained but also a resource limit that's allocated, just like crawl budget, according to the priority Google assigns the site. On large domains with thousands of pages dependent on rendering, it's common to find URLs in Search Console marked "crawled, currently not indexed" for weeks, precisely because they're in the rendering queue and never get processed with enough priority.

Frequently asked questions