SSR vs CSR: what Google gets

Almost nobody arrives at these acronyms out of curiosity. You arrive because somebody drops them: the developer says the site "is an SPA", an audit report marks CSR in red, an agency explains that the ranking problem "comes from the rendering". And from there you have to decide something, usually with money attached, without being sure what you are deciding.

The decision carries more weight than it looks, for a reason that did not exist until recently: Google has stopped being the only thing reading your website. Search engines have spent years executing the JavaScript on the pages they crawl, but the bots feeding ChatGPT, Claude and Perplexity do not. So the same site can be well indexed in Google and invisible to everything else, and which side you land on comes down to a technical decision almost nobody made on purpose.

What server-side rendering (SSR) is#

Think of your website as a letter. Someone asks for it, your server writes the whole thing and puts it in the envelope. Whoever opens it finds the text already written: the headline, the paragraphs, the links, the prices.

That is server-side rendering. The HTML leaving your server already contains the content. The browser still runs code afterwards, so menus open and forms work, but the content does not depend on that happening. If the code never runs, the words are still there.

It is how the entire web worked before 2010, and it is where nearly every modern framework has landed after a decade of trying the opposite.

What client-side rendering (CSR) is#

Same envelope, except inside there is a blank sheet and a page of instructions for writing the letter. Whoever opens it has to do the work: read the instructions, follow them, end up holding the letter.

That is client-side rendering. The server hands over a nearly empty document, typically a <div id="root"></div> and some JavaScript files, and the visitor's browser builds the page. To a person with an ordinary browser the difference is invisible: the work takes milliseconds and the site appears.

It stops being invisible the moment whoever opens the envelope cannot follow instructions, or will not.

The differences that change something#

Most SSR-versus-CSR comparisons lay out six or seven attributes as though these were two products on a menu. In practice you do not pick a rendering mode: you pick a framework and a platform, and the mode comes bundled with them. The table below is for understanding what you ended up with, more than for choosing.

	SSR	CSR
What the server sends	The page, content included	An empty shell and code
Who does the work	Your server, once per visit	Each visitor's device
First useful paint	Fast	Depends on the visitor's phone and network
Content visible without JavaScript	Yes	No
Server cost	Higher	Lower
Best for	Content that has to be found	Apps behind a login

There is a third option that drops out of almost every article: static rendering (SSG), where pages are built once at publish time and served ready-made. For a blog or a company site it is usually the right answer, because it has the full content of SSR at the cost of a plain file. Most real projects mix all three anyway: a static home page, a client-side customer dashboard, and a page or two generated per request because the data moves.

What Google gets, and when#

Google's own documentation describes three separate phases: crawling, rendering and indexing. Googlebot requests the page, and to run its JavaScript it puts the page in a queue:

Googlebot queues all pages with a 200 HTTP status code for rendering […] The page may stay on this queue for a few seconds, but it can take longer than that.

Google does execute JavaScript, so a CSR site can absolutely end up indexed. What differs is the route. With SSR the content is indexed on the first visit. With CSR your content depends on a second pass Google makes when it has spare resources, over which you have no control and no visibility, and which is not guaranteed for pages Google does not prioritise. When that second pass never comes, your page is indexed exactly as the server delivered it, which is blank.

AI crawlers do not run JavaScript#

In December 2024, Vercel published an analysis of real crawler traffic across its network: 4.5 billion Googlebot requests in a month, 569 million from GPTBot, 370 million from ClaudeBot. The finding on rendering leaves little room, and later analyses have held it up: none of the major AI crawlers execute JavaScript. Not GPTBot, not ClaudeBot, not PerplexityBot, not Meta's or ByteDance's.

They also download the JavaScript without running it: JavaScript files were 11.50% of ChatGPT's requests and 23.84% of Claude's. They take the code and never execute it.

The exceptions are Googlebot, AppleBot and Gemini, which rides on Googlebot's infrastructure and therefore does render.

So the familiar comparison has aged badly. For years, "Google will render your JavaScript eventually" was a reasonable argument for not worrying much about CSR. Today that argument covers exactly one search engine, while a growing share of traffic arrives recommended by a model that will never see your content.

How to tell which one your site is#

There is a manual check that works: turn JavaScript off in your browser and reload. Whatever survives is roughly what a non-rendering bot receives.

If you would rather not touch your browser settings, there are tools that run the check for you and hand back both screenshots side by side; I keep a free one, the SSR/SEO auditor. And if the no-JavaScript screenshot comes back empty and your site was built by an AI tool, the whole case is written up in why your AI-built site isn't on Google.

Whichever tool you use, distrust the binary verdict. A tiny static page can come out flagged as CSR purely for being short, and the middle band is real: sites that deliver half their content from the server and assemble the rest in the browser. What matters is how much of the final content was already in the HTML, not the label.

There is also a middle case that explains verdicts which look contradictory: dynamic rendering. The server assembles the whole page if the requester is a crawler it recognises, and hands the empty shell to everyone else. It is what Lovable's older projects do, the React and Vite ones; apps created from 13 May 2026 onwards use TanStack Start with real server-side rendering. On paper it sounds like the best of both, and Google advises against it in plain terms, calling it "a workaround and not a recommended solution". The reason shows up the moment you think it through: it only works for bots on the list. Googlebot is fine, and the AI crawlers, which rarely are on it, still get the blank page.

And that is the part I do think is fair to criticise, which is not the technique but where it is written down. It lives in the platform's developer documentation, on a page you only read if you already know the problem exists. Nobody hitting the publish button is told their site will behave one way for Google and another way for everything else.

So which one should you pick?#

If the content has to be found, it has to come from the server. A blog, a company site, a catalogue, a landing page: static or SSR, and choosing between those two is about cost and how often the data changes, not about SEO.

If it is an application behind a login, CSR is fine and there is nothing to argue about: Google has no interest in your customers' dashboard.

What no longer holds up is the middle, which is where nearly all the real damage sits: a business's public website, served client-side, because that is what the tool it was built with produced by default. That is not an architecture decision. It is a decision nobody made, and it gets paid for in the one channel that brings people who do not know you yet.

If you are not sure which of the three you are in, run your URL through the auditor. And if the diagnosis is bad and the fix is out of reach, that is what I do for a living: technical consulting explains how I work.