Client-side rendering: when people see everything and machines see an empty page

What does client-side rendering mean?

With classically server-rendered websites, the server already delivers an HTML page that contains the essential content.

With client-side rendering, or CSR, the server may initially deliver mainly a technical shell. Only then does JavaScript load content and build the visible page from it.

For a person in a modern browser this can work excellently.

For crawlers the situation is less clear-cut.

Why websites use CSR

Client-side rendering has legitimate advantages.

Complex applications can respond very interactively. Parts of the page can be updated without loading a complete new page from the server. Frontend teams can build sophisticated interfaces and app-like experiences.

For logged-in applications and software dashboards this can be an excellent architecture.

Client-side rendering and machine readability need not be a contradiction. The central architectural question is how an interactive user interface is connected to content that remains reliably available to crawlers and AI systems.

What matters is therefore less the framework in use than the actual output: which information does the server already deliver with the first HTML, and which only comes into being after JavaScript has executed?

Google can execute JavaScript. That does not solve every problem.

Google processes JavaScript and renders modern websites. A client-side rendered page is therefore not automatically invisible to Google.

Processing, however, happens in several phases. The page is crawled first, then it may be rendered and then indexed.

Not every crawler has the same rendering capabilities. And even at Google, JavaScript can introduce additional sources of error.

For AI recommendation measurement this difference is particularly relevant: the ecosystem does not consist of a single crawler with a single rendering engine.

The typical problem

A product shop shows in the browser:

• product name
• price
• availability
• variants
• shipping information
• product description

The initial HTML response, however, may contain only navigation, empty containers and JavaScript bundles.

The product information appears only after JavaScript has loaded and executed.

For the user, everything is there.

For a client that does not execute JavaScript, or does not complete the rendering process, the product effectively does not exist.

CSR is not a binary SEO criterion

A website should not be judged solely on whether it uses React, Salesforce LWR or another JavaScript framework.

What matters is the actual output.

We therefore examine two states separately:

Initial HTML

What does a client receive directly from the server?

Rendered DOM

What exists after the page has fully executed?

The difference between the two states is often more informative than the technology stack in use.

How can the problem be solved properly?

1. Deliver critical content server-side

Product name, price, availability, service description or central purchase conditions should, where possible, already be present in the delivered HTML.

2. Use server-side rendering, prerendering or hybrid approaches

Three routes lead to the same goal. Server-side rendering generates the HTML on the server for every request. Prerendering, also called static rendering, generates it at build time; for catalogue and information pages that rarely change, that is often enough. Hybrid approaches combine both: the server delivers the content, and the browser hydrates only the interactive parts.

Modern frameworks support these hybrid forms. Content is generated on the server or statically and then hydrated and made interactive in the browser. That means you do not have to choose between machine readability and modern UX.

3. Progressive enhancement

The basic information works without JavaScript. JavaScript then improves interaction and presentation.

This principle is also meant to be upheld on the Aions website itself.

4. Structure content in the HTML so machines can read it

Content in the initial HTML is the precondition, but not yet a guarantee that machines understand it correctly. Central information should exist as real text, not as an image or canvas, and be marked up semantically: headings for structure, lists and tables for prices, variants and delivery terms, unambiguous labels instead of icons alone.

What people can recognise in the layout has to be recognisable to machines in the markup.

5. Do not make structured data depend on a fragile rendering chain

Structured data can also be generated via JavaScript. For central information, however, every additional rendering dependency increases the number of possible points of failure.

Visible and structured information should come from the same underlying data source.

6. Re-check rendering after releases

Even a site that reads well today can go back to delivering important content client-side after a theme, framework, app or template update. Initial HTML and rendered DOM should therefore be re-checked after relevant releases.

Product data, prices, availability, structured data and central information pages are the most critical.

At a minimum, the following are relevant:

• raw HTML response
• rendered DOM
• Google URL inspection or suitable rendering tests
• structured data
• actual responses from relevant bots, where available

And what about prerendering for bots only?

Prerendering at build time, where every client receives the same finished page, has to be distinguished from so-called dynamic rendering. Dynamic rendering was often used as a workaround in the past: users receive the JavaScript version, certain bots a pre-rendered HTML version.

Google describes dynamic rendering today as a workaround, not as the preferred long-term solution.

Server-side rendering, static rendering or hydration are fundamentally more robust approaches.

If different versions are delivered, they must remain equivalent in content.

The pragmatic answer

Not every CSR website needs an architectural rebuild.

If an existing page is read completely by the relevant systems, there is no reason to rebuild everything just because of the technology label.

But if decisive content is missing from the initial HTML and relevant crawlers do not capture it reliably, rendering becomes a business problem.

The decision should therefore not turn on the technology but on the state of the information: which content has to be reliably available to people and machines, and in which state is it actually present?

That is exactly what can be measured.

Which AI crawlers do not execute JavaScript, and what that means for how AI systems search: What do AI systems search for before they answer, and what does that mean for SEO?