Rendering and JavaScript SEO

Google runs your JavaScript, but not for free and not always on time. Content that appears only after a script runs is content Google might see late or miss. This chapter is about the gap between the HTML you send and the page Google actually indexes, and how to keep meaning on the safe side of that gap.

What rendering is

Rendering is executing a page's HTML, CSS, and JavaScript to build the final DOM, the version a browser would show a person. Google does this with a headless, evergreen Chromium called the Web Rendering Service. Evergreen means it tracks a recent Chrome, so modern JavaScript features work. The output of rendering, not the raw HTML you shipped, is what Google parses and indexes.

That last sentence is the whole chapter in one line. If a heading, a link, a canonical tag, or a block of body text exists only after JavaScript runs, then it exists for Google only if rendering succeeds and finishes in time. Anything present in the initial HTML is guaranteed to be seen. Anything added by script is conditional. The practical skill in JavaScript SEO is knowing which of your content sits on which side of that line, and moving the parts that matter to the guaranteed side.

How Google processes JavaScript

The flow has four moves. Google crawls the initial HTML. It queues the page for rendering, and that queue can lag behind the crawl. It renders the page with headless Chromium. Then it indexes the rendered HTML and discovers any links that only appeared after rendering, feeding them back into crawling.

You may have read that Google indexes in "two waves," a first pass on raw HTML and a later pass after rendering. Google's own engineers now call that framing outdated. The honest model is a queued rendering step with variable lag: sometimes near-instant, sometimes slower, and the exact timing is not published. Treat rendering delay as real but unpredictable, not as a fixed second wave. The practical takeaway does not change. The longer meaning waits behind JavaScript, the more you gamble on a step you do not control.

Google renders JavaScript, but rendering is queued, variably delayed, and not guaranteed complete. Content that depends on it is content you are betting on a step you cannot schedule.

Rendering strategies

Where the HTML gets built decides how exposed you are. The main options:

• Client-side rendering (CSR). The server sends a near-empty shell and the browser's JavaScript builds the content. If rendering fails or lags, Google may see almost nothing. The riskiest choice for anything that must be indexed.
• Server-side rendering (SSR). The server sends fully formed HTML on each request, so bots get the content immediately, no script execution required.
• Static generation and prerendering (SSG). HTML is built at deploy time and served static. Fast and bot-friendly.
• Hydration. Serve SSR or SSG HTML first, then let JavaScript make it interactive. You get indexable content and a dynamic app.
• Dynamic rendering. Serve prerendered HTML to bots and CSR to users. Google now calls this a workaround, not a long-term solution. Prefer SSR, static, or hydration.

Two cross-effects are worth planting here. Shipping a large JavaScript bundle to build the page costs the user too, because parsing and running it hurts responsiveness. JS and interactivity → And canonical tags injected by JavaScript are exactly the kind of signal that can arrive late or not at all, so keep canonicals in the initial HTML. Canonicalization →

AI crawlers render less

Google is the generous case. Bing and most AI and LLM crawlers render JavaScript far less reliably, and many not at all. Client-only content that Google eventually sees is often simply invisible to them. As AI answer engines become a real source of visibility, that gap matters more, because a passage a model never receives is a passage it can never quote.

This makes the safe default simple: server-render meaningful content. If your headings, body text, and key facts sit in the HTML response, every crawler gets them, from Googlebot to the least capable AI fetcher. Server-rendering is not just a Google tactic; it is the widest-compatibility choice for being read at all. Being readable to AI engines →

Testing what Google renders

Do not guess. In Search Console, run URL Inspection, then Test Live URL, then view the rendered HTML and the screenshot Google produced. That is the DOM Google actually built. Compare it against your raw HTML, the "view source" version, to see the diff. If a heading, link, canonical, or block of text is in the rendered HTML but missing from the raw HTML, it depends on rendering, and you have found your risk. If something is missing from both, Google never got it at all.

Make this a habit for any JavaScript-heavy template before you trust it. The next lever is deciding what crawlers may fetch in the first place, which is the robots chapter. Robots and crawl control →