Glossary Client-side rendering (CSR)
With client-side rendering the server sends a nearly empty page and the browser assembles the content with JavaScript. The page a person sees never existed as HTML on the server.
Google can render JavaScript, but as a second step and with no guarantee of when. What only exists after code runs reaches the index later, or not at all.
The server delivers a scaffold: an empty <div> and a script reference. Only in the browser does the JavaScript load, fetch data and write the content into the page. From the server's point of view the response is complete before any text exists.
This is the usual construction of a classic single-page application. Behind a login it is unproblematic — nobody needs to find it. For a public content page the situation changes.
Google processes a page in two passes. First the delivered HTML is read. Whatever is not in it goes into a render queue and is processed later, when resources allow.
The second pass does happen — Google says so explicitly — but not immediately and with no promise about the gap. For a news item, a price change or a new category page that gap is precisely the problem. Add an error during rendering — a blocked script, a timeout, a failed data request — and the content never appears at all.
The three differ in when the HTML comes into being.
For search engines SSR and SSG are equivalent: the content is in the first response. The difference between them is operational — how fresh the data is and what a request costs.
It is not an all-or-nothing choice for a whole site. The common pattern is a mix: visible content from the server, interactive parts in the browser.
The quickest probe: fetch the page without JavaScript and look at what remains. If an empty area is left, the content depends on CSR.
More reliable is comparing two versions of the same page: the raw HTML from the server response against the rendered text in the browser. Whatever appears only in the second version does not exist for the first pass. Add the URL inspection in Search Console, which shows what Google actually rendered.
A common mistake in this measurement: checking with a tool that executes JavaScript and therefore seeing everything. That measures the browser, not the crawler.
CSR is not a wrong decision but a choice with a price. It is fine where content does not need to be found: behind a login, in a configurator, in a shopping basket, in an admin area.
It becomes expensive where discoverability is the job — product, category and content pages. For those the rule is simple: what should rank belongs in the first response.
A technical audit covers this and everything else in one pass.
Request an auditYes, Google executes JavaScript. But in a second pass, with no committed timeframe, and any rendering failure leaves the content out. The useful question is not whether it can, but when and how reliably.
Fetch the page without executing JavaScript and compare that HTML with the rendered text. A plain curl is enough. Checking with a tool that runs scripts measures the browser, not the crawler.
Almost never. The usual move is to bring only what must be found to the server: text, headings, structured data and internal links. Interactive parts can stay in the browser.
Google describes it as a workaround and a transition, not a long-term recommendation. Serving two separate versions adds its own source of error: that the two drift apart without anyone noticing.
Usually LCP: the main element cannot be painted until the JavaScript has loaded and run. It is not an automatic rule, but the path to the first visible content is longer by construction.