JavaScript Rendering and Indexing

Written by Backbone Tutorials Team

Last updated: June 2026 · 9 min read

Rendering and indexing are two different events, and the gap between them is where rankings leak away. Google renders your page, then decides what to index from the result. So the real question is not "does Google run my JavaScript" but "what exactly survives the render, and does it carry the signals a page needs to rank?"

This guide picks up where how Google crawls JavaScript left off and focuses on the output: the rendered DOM, the metadata inside it, the content that quietly goes missing, and which rendering strategy makes indexing reliable.

Rendered HTML is what gets indexed

Google does not index the bytes your server sent; it indexes the DOM that exists once the page has rendered. Everything your JavaScript adds, the headings, the product details, the links, becomes indexable only because the render put it there.

Source HTML versus the rendered DOM

The source HTML still has a job: it is the only thing Google holds during the wait before rendering, and it is what other tools and link previews often read. But for ranking, the rendered DOM is the source of truth. The practical takeaway is to inspect the rendered output, not the view-source, when you ask what Google indexed.

Metadata must survive the render

Content is not the only thing that has to be present after rendering. The signals in the head, the ones that tell Google how to treat the page, have to be there too, and correct.

Title, canonical, and meta robots

<title>Product 42 - Acme</title>
<link rel="canonical" href="https://example.com/products/42">
<meta name="robots" content="index, follow">

If JavaScript sets these late, two problems appear: Google may read the source value before your script changes it, and a script that injects a second canonical can conflict with one already in the source. The safe pattern is to render the title, canonical, and robots directives on the server so they are right from the first byte, rather than patching them client-side.

Lazy-loaded and interaction-gated content

A lot of content hides behind behaviour: it loads when you scroll, when you click a tab, or when you open an accordion. Googlebot does none of those things, so that content can be invisible to the index even though users see it fine.

Why infinite scroll loses content

<!-- Native lazy-load: still in the DOM, fine to index -->
<img src="hero.webp" loading="lazy" width="1200" height="630" alt="...">

<!-- Infinite scroll: items only fetched on scroll are not rendered -->

Native image lazy-loading is safe because the element is in the markup from the start; only the bytes defer. Infinite scroll is different: if more items arrive only after a scroll that never happens, they never enter the rendered DOM. Back endless lists with real, crawlable paginated URLs so each item lives at an address Googlebot can reach.

Empty shells become soft 404s

When a render fails, times out, or simply produces an empty container, Google does not see an error; it sees a thin or blank page. That can be treated as a soft 404 or filed as low-value, and either way the page does not rank.

Avoiding the thin-content trap

Make sure each route renders meaningful content, not just a spinner, and that genuine "not found" states return a real 404 status rather than a 200 with empty markup. A page that looks empty to the renderer is, for ranking purposes, an empty page, no matter how rich it becomes a moment later in a real browser.

Rendering strategies and their trade-offs

How you produce the HTML decides how much you are trusting Google's renderer. The four common approaches sit on a spectrum from most to least render-dependent.

CSR, SSR, prerendering, and dynamic rendering

Client-side rendering ships an empty shell and builds everything in the browser, which puts the most weight on Google rendering your scripts well and soon. Server-side rendering returns the full HTML on the first request, so content is indexable immediately. Prerendering, or static generation, bakes pages into static HTML snapshots ahead of time, with the same upfront benefit. Dynamic rendering, serving a prerendered version to bots, is a legacy workaround Google now discourages as a long-term solution. For content that must rank, lean toward server rendering or prerendering.

Timing: freshness and re-indexing

Indexing is not a single pass. Pages are re-crawled and re-rendered over time, so a change you ship today may take a while to surface, especially on a large site where the render queue is busy.

When updates actually re-index

You can nudge the process: keep an accurate lastmod in your sitemap, link to new and updated pages from places that get crawled often, and use URL Inspection to request indexing for a priority page. None of these force instant results, but together they shorten the gap between publishing and ranking. With what gets indexed now clear, the next guide looks at choosing a rendering strategy in depth.

Read next: back to the JavaScript SEO hub, or revisit how Google crawls JavaScript for the stage before this one.