JavaScript SEO, Explained

A common, outdated claim in SEO discussions is that "Google can't read JavaScript." That's no longer true — Google has been able to render JavaScript for years. The more accurate, more useful version of the conversation is about how that rendering happens, when it happens, and which JavaScript patterns still create real risk. This guide covers the actual mechanics, not the myth.

Crawling, rendering, and indexing are three separate steps

To understand JavaScript SEO, it helps to separate three things that are often talked about as one:

1. Crawling — Googlebot requests a URL and downloads the raw HTML response, exactly as the server sent it, before any JavaScript has run.
2. Rendering — for pages that need it, Google's Web Rendering Service (a headless version of Chrome) executes the page's JavaScript to produce the fully rendered DOM, the way a real browser would.
3. Indexing — Google processes the resulting content (rendered or raw, depending on whether rendering happened) and decides whether and how to store it in the index.

The critical detail is that rendering is not instantaneous or guaranteed to happen in the same pass as crawling. Google has described this historically as a two-wave indexing process: the raw HTML gets crawled and can be indexed first, based on whatever content and links are present in that initial response, and JavaScript-dependent content gets queued for rendering separately — sometimes shortly after, sometimes with a meaningful delay, depending on Google's available rendering resources and how it prioritizes the page.

Rendering strategies, and what each one means for SEO

Client-side rendering (CSR)

The server sends a mostly empty HTML shell, and the browser (or crawler) downloads and executes JavaScript to build the actual page content. This is the highest-risk pattern for SEO: content isn't in the initial response at all, so it depends entirely on the rendering pass succeeding, and it's frequently invisible to crawlers that don't render JavaScript at all.

Server-side rendering (SSR)

The server executes the JavaScript framework's code at request time and sends back fully formed HTML, which the browser then "hydrates" with interactivity. Content is present in the raw HTML from the first request — no rendering pass required for the crawler to see it, which removes the delay and reliability risk entirely.

Static site generation (SSG) and pre-rendering

Pages are rendered to plain HTML at build time, before any request happens, and served as static files. This gets the same benefit as SSR — full content in the initial HTML — with the added advantage of not requiring a server to render on every request, which also tends to help page speed.

Hydration

Hydration is the process where JavaScript "attaches" interactivity to server-rendered or statically generated HTML after it loads — turning static markup into a fully interactive app without re-rendering the content itself. Done well, hydration is invisible to SEO because the content was already there in the HTML; done poorly (for example, content that briefly disappears and re-renders during hydration), it can contribute to layout shift and wasted rendering work.

Specific JavaScript patterns that create real SEO risk

• Links rendered as JavaScript click handlers instead of real anchor tags — a <div onClick> that navigates via JavaScript isn't a link a crawler can follow the way a proper <a href="..."> is. Use real anchor tags with real href attributes for anything that should be crawlable.
• Infinite scroll without paginated URLs — content loaded only as a visitor scrolls, with no equivalent page-by-page URL structure underneath, is effectively invisible to a crawler that doesn't scroll or trigger the load event the way a human does.
• Canonical tags, meta descriptions, or title tags injected client-side only — these need to be reliably present for indexing decisions, and depending on a rendering pass to insert them adds unnecessary risk to signals that are cheap to include directly in the server-rendered HTML.
• Content gated behind user interaction — tabs, accordions, or "load more" buttons that fetch content only after a click can hide that content from indexing if the underlying markup isn't present until the interaction fires.
• Blocking JavaScript or CSS files in robots.txt, which prevents Googlebot from rendering the page correctly even when it wants to — an easy-to-miss mistake left over from older robots.txt configurations.

Why this matters even more for AI crawlers

Most AI crawlers used to gather content for AI-generated answers and citations — for tools like ChatGPT and Perplexity — do not execute JavaScript the way Googlebot does. They typically fetch raw HTML only. A site that relies on client-side rendering for its core content isn't just risking a delayed indexing pass with Google; it may be effectively invisible to an entire category of crawler that never gets a second, rendered chance. See server-side vs. client-side rendering for AI crawlers for the specifics.

How to check your own site

Use the URL Inspection tool in Google Search Console, run the live test, and look at the rendered HTML and screenshot it produces. Compare that against what you see loading the same page in a real browser. If your headline, body copy, and internal links are all present in that rendered output, you're in reasonable shape with Google specifically. To check what a non-rendering crawler sees, view the raw page source (not the browser's inspected DOM) or fetch the URL with a simple command-line request — if your key content is missing from that raw response, it only exists after JavaScript runs.