Deutsch
Rendering methods

Client-side rendering

Also known as: CSR

Client-side rendering (CSR) is a technique in which JavaScript builds the HTML of a page in the browser. The abbreviation CSR has other meanings. This entry covers the web technique. CSR is opposed to server-side rendering (SSR), where the server generates the HTML, and both can be combined in one application (MDN).

How does client-side rendering work?

A pure CSR app returns a minimal HTML document with an empty root element and a script, and the script creates the content through DOM manipulation. After the first load, route changes usually fetch only data. Single-page apps built with React, Vue or Svelte can also render on the server (MDN).

Where the HTML is created: CSR, SSR, SSG and dynamic renderingFour rows show where the content of a page is created. With CSR the server sends an empty HTML shell and JavaScript in the browser builds the content. With SSR the server renders the HTML on every request and hydration makes it interactive in the browser. With SSG the HTML is created at build time. Dynamic rendering serves finished HTML to crawlers and the JavaScript version to users; Google calls this a workaround.SERVERFIRST HTML RESPONSEBROWSERCSRClient-siderenderingsends HTML shelland JavaScript<div id="app">no contentJavaScript buildsthe contentSSRServer-siderenderingrenders HTMLon every requestcontent isin the HTMLhydration makesthe page interactiveSSGstatic renderingprerenderingHTML is builtahead of timecontent isin the HTMLshows HTML at once,hydration optionalDynamicrenderingworkarounddetects crawlers,renders for themcrawlers: HTMLusers: empty shellfor users, JavaScriptbuilds the contentSchematic. Google renders JavaScript in a separate step after crawling.Not all bots run JavaScript.
What matters for crawlers is whether the content is already in the first HTML response. Google recommends server-side rendering or prerendering and calls dynamic rendering a workaround, not a long-term solution. Sources: web.dev: Rendering on the Web; Google Search Central: Understand the JavaScript SEO basics; Google Search Central: Dynamic rendering as a workaround.

What does it mean for SEO?

Google processes JavaScript sites in three phases: crawling, rendering and indexing. Pages with a 200 status code are queued for rendering unless a robots meta tag or header says not to index them. A headless Chromium then renders the page, and Google uses the rendered HTML for indexing. Google does not render JavaScript on pages or from files blocked by robots.txt. Google also writes that server-side or pre-rendering is still a great idea, since not all bots can run JavaScript. Some third-party articles claim that Google ranks CSR pages lower, a claim Google’s documentation does not make.

To avoid soft 404 errors in client-side routing, Google suggests a JavaScript redirect to a URL that returns a 404, or noindex on error pages.

Rendering approaches compared
ApproachWhere and when is the HTML built?Content in the delivered HTML?Google's position
Client-side rendering (CSR) (this term)in the browser with JavaScript; data fetching, templating and routing run on the clientno, only after JavaScript has runGoogle renders pages with a 200 status in a separate step after crawling and still recommends server-side or pre-rendering because not all bots can run JavaScript
Server-side rendering (SSR)on the server, for each requestyesrecommended by Google as a solution (instead of dynamic rendering)
Static site generation (SSG, static rendering)at build time; usually one HTML file per URL ahead of timeyesrecommended by Google as a solution (instead of dynamic rendering)
Incremental static regeneration (ISR)prerendered at build time; once the revalidation time has passed, the server regenerates the page in the background (framework feature, e.g. Next.js)yes, from the cache; the older version is served until regeneration finishesno specific statement from Google
Prerenderingat build time; the client-side app is run and its initial state saved as static HTMLyes (initial state)Google says server-side or pre-rendering is “still a great idea” because it makes sites faster for users and crawlers
Dynamic renderinga rendering server builds HTML only for detected crawlers; users get the client-side rendered versiononly in the version served to crawlersGoogle calls it a workaround and not a long-term solution; not cloaking as long as users and crawlers see similar content

Google names server-side rendering, static rendering and hydration as replacements for dynamic rendering. The older web.dev article “Rendering on the Web” still calls dynamic rendering an option worth considering; this table follows the current Google Search Central documentation. ISR is not a web standard; the description comes from the Next.js documentation. Prerendering has other meanings too; this row uses the web.dev definition. Sources: web.dev: Rendering on the Web; Google Search Central: Understand JavaScript SEO basics (last updated 2026-03-04); Google Search Central: Dynamic rendering as a workaround (last updated 2025-12-10); Next.js Docs: How to implement Incremental Static Regeneration (ISR). Last checked: .

Example

HTML
<body>
  <div id="root"></div>
  <script src="bundle.js"></script>
</body>

The raw HTML has no headings, text or links. They exist only in the rendered HTML, which the URL Inspection tool in Search Console can show.

FAQ

Is Next.js server-side or client-side rendered? It supports both. Its documentation describes fetching data on the client for CSR next to its server rendering methods.

Sources

  1. Client-side rendering (CSR) – MDN Glossarydeveloper.mozilla.org
  2. Understand JavaScript SEO basics – Google Search Centraldevelopers.google.com
  3. Client-side rendering of HTML and interactivity – web.devweb.dev
  4. Client-side Rendering (CSR) – Next.js Docsnextjs.org

Last updated: