Client-side rendering and SEO
Client-side rendering (CSR) sends a thin HTML shell and builds the page in the browser with JavaScript. Googlebot can render JavaScript, but it does so in a deferred second pass, and content that depends entirely on client-side execution is more fragile to crawl and index than server-rendered HTML. This page explains how Google processes CSR, where it commonly fails, and safer alternatives.
What this means
In client-side rendering, the server returns minimal HTML plus JavaScript bundles. The browser then fetches data and constructs the DOM. Until that JavaScript executes, the page has little visible content.
Googlebot supports JavaScript and renders pages, so CSR can be indexed. But rendering is resource-intensive, so Google does it in a deferred pass after the initial crawl, sometimes meaningfully later. Other crawlers, including many AI and social bots, may not render JavaScript at all and will only ever see the shell.
How Google processes JavaScript pages
Google's pipeline crawls the raw HTML first, queues the URL for rendering, then renders with a current Chromium-based Web Rendering Service, and finally indexes the rendered DOM. Rendering can be deferred because of resource constraints.
This two-phase model means CSR content is indexable but later and more fragile than server-rendered content. If render-critical resources are blocked by robots.txt, error out, or exceed time budgets, the rendered content can be incomplete — and that incomplete version is what gets indexed.
- Phase 1: crawl raw HTML (the shell for CSR)
- Phase 2: queued render with Web Rendering Service
- Render can be deferred; not instantaneous
- Non-rendering crawlers see only the initial HTML
Reducing CSR risk
To make content reliably available to crawlers, prefer server-side rendering (SSR) or static pre-rendering for important content, so the main content is present in the initial HTML. Hybrid approaches (hydration on top of server-rendered HTML) give you the same first-paint content with client interactivity.
If you keep CSR, do not block JS/CSS in robots.txt, ensure critical content does not depend on user interaction to load, provide real crawlable links (not click-only navigation), and test with the URL Inspection tool's rendered output to confirm Google sees the content.
How it appears in analytics and logs
If a page's main content exists only after client-side JavaScript runs, the initial HTML Googlebot fetches may be nearly empty. Indexing then depends on the render pass succeeding. Failures — blocked scripts, errors, timeouts — can leave the page indexed with little or no content.
Diagnostic use case
Diagnose missing or thin indexed content on JavaScript-heavy pages, and decide whether client-side rendering, server-side rendering, or pre-rendering best fits your crawlability needs.
What WebmasterID can help detect
WebmasterID shows which crawlers fetched a URL and what the server returned at fetch time. Because many crawlers (including some AI crawlers) do not render JavaScript at all, this helps you see whether a bot likely saw your CSR content or only the empty shell.
Common mistakes
- Assuming Googlebot renders JavaScript instantly — rendering is deferred to a second pass.
- Blocking JavaScript or CSS in robots.txt so the render pass cannot build the page.
- Expecting non-rendering crawlers (many AI/social bots) to see client-built content.
- Hiding main content behind user interaction that a crawler will not trigger.
Privacy and accuracy notes
Rendering analysis concerns how crawlers process your code, not who visits. WebmasterID records crawler fetches and responses as bot events; it does not execute client code on behalf of, or profile, human visitors.
Frequently asked questions
- Can Google index client-side rendered pages?
- Yes, Googlebot renders JavaScript and can index CSR pages, but it does so in a deferred render pass. Content that only appears after that pass is more fragile and may be indexed later or incompletely.
- Is server-side rendering better for SEO?
- For crawlability of main content, yes — SSR or pre-rendering puts content in the initial HTML, so it is available to all crawlers immediately, including those that do not run JavaScript.
Related pages
- Server-side rendering and SEO
Server-side rendering (SSR) generates a page's HTML on the server for each request, so the main content is present in the initial response before any client JavaScript runs. This makes content immediately available to every crawler, including those that do not execute JavaScript, and avoids reliance on Google's deferred render pass. This page explains SSR's crawl benefits, its costs, and how it relates to static rendering and hydration.
- Hydration and crawling
Hydration is the process of attaching client-side JavaScript behavior to HTML that was already rendered on the server or statically. For crawling, the key point is that the content is in the initial HTML, so it is visible to crawlers regardless of hydration; hydration mainly affects interactivity and responsiveness. This page explains hydration, its crawl implications, and the INP trade-offs of heavy hydration.
- JavaScript rendering and crawling
Content injected by JavaScript is not in the initial HTML, so a crawler must render the page to see it. Rendering is more expensive than fetching HTML, and not all crawlers render. Server-side rendering (SSR) or prerendering puts content in the HTML directly, reducing dependence on the crawler's render step.
- Bot intelligence
See which crawlers reach your pages, including ones that do not render JavaScript.
Sources and verification notes
- Google Search Central — Understand the JavaScript SEO basicsTwo-phase crawl-then-render model and rendering guidance.
- web.dev — Rendering on the web
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.