Client-side rendering (CSR) is a way of building web pages where the server sends the browser a nearly empty HTML file plus a bundle of JavaScript, and that JavaScript then builds the visible content on the visitor’s own device. Many single-page applications built with frameworks such as React, Vue or Angular work this way by default.
How client-side rendering works
With a traditional website, the server sends finished HTML: the headings, text, links and images are all in the first response. With client-side rendering, the first response often contains little more than a container and a script tag. The browser downloads the JavaScript, runs it, fetches the data it needs from an API and then writes the page into the DOM. Moving to another page usually happens inside the app without a full reload.
The alternative is server-side rendering, where the server builds the full HTML before sending it, or static generation, where pages are built in advance. Most modern frameworks support all three, and many sites mix them.
Google can process JavaScript. Googlebot fetches the HTML first, then queues the page for rendering in a recent version of Chrome, and indexes what it finds after the scripts have run. The rendering step adds work, can be delayed, and fails if scripts error, time out or are blocked by robots.txt.
Why it matters
For SEO, CSR adds risk at every step between your content and the index. If the JavaScript fails for Googlebot, Google sees an empty page. Links that only appear after a script runs, or that use click handlers instead of real anchor tags with an href, may not be followed, so whole sections of a site can go undiscovered.
The bigger issue now is that search is no longer only Google. At the time of writing (October 2026), most AI crawlers, including those behind ChatGPT, Claude and Perplexity, appear to read the raw HTML without running JavaScript. A fully client-rendered site can look blank to them, which means it is very unlikely to be cited in their answers, however good its content.
There is also a speed cost. Visitors on mid-range phones or patchy mobile signal wait for scripts to download and run before they see anything, which tends to hurt Largest Contentful Paint and Interaction to Next Paint. UK businesses whose customers mostly browse on phones feel this most.
Common mistakes
- Checking only in a browser. The page looks fine to you because your browser runs the scripts. View the page source to see what crawlers receive first.
- Navigation without real links. Buttons and click handlers that change the view are not links a crawler can follow.
- Titles and canonicals set by JavaScript. If the initial HTML has a generic title or a wrong canonical, crawlers may act on that before the script corrects it.
- Soft 404s. An app that shows “page not found” while the server returns a 200 status leaves error pages indexable.
- Relying on dynamic rendering long term. Serving prerendered HTML only to bots was a workaround that Google no longer recommends.
How to act on it
Open an important page, choose “View page source” and search for a sentence from the main content. If it is not there, the page depends on client-side rendering. Then use the URL Inspection tool in Google Search Console to see the rendered HTML and screenshot Google produced, and check whether your main text and links appear.
For marketing pages, service pages, product pages and articles, the safest fix is to switch to server-side rendering or static generation, which most frameworks support. Keep client-side rendering for logged-in areas and interactive tools where search visibility does not matter. Make sure every navigation link is a real anchor with an href, and that titles, meta descriptions and canonicals are in the initial HTML. Diagnosing and planning this kind of change is part of my technical SEO work, usually alongside the developers who will make it.