What Is Client-Side Rendering (CSR)?

In one sentence

Client-side rendering means the server sends a near-empty shell and JavaScript builds the page in the browser — which leaves non-JavaScript crawlers with nothing.

What Client-Side Rendering means

In a client-side rendered app the initial HTML response contains a root element and script tags. Everything a user sees is constructed afterwards by JavaScript running in their browser.

This is the default for many single-page application setups. It's excellent for app-like interactivity and poor for anything that needs to be read by a machine that doesn't run JavaScript.

Why it matters for AI search

CSR is the most common AI visibility blocker we find. The page looks perfect to everyone on the team and is effectively blank to several major AI crawlers.

It's also the most expensive problem to leave in place, because every other investment — content, entity work, citations — assumes the page can be read.

See it in action

What each visitor actually receives from a client-side rendered page.

Who can read a CSR page

Response inspection
$ ron crawl --agents all
Human in a browserwaiting
Googlebotwaiting
GPTBotwaiting
PerplexityBotwaiting
ClaudeBotwaiting
Bingbotwaiting

Two of six can read it.

Nothing is blocked and every response is a 200. The content simply isn't in the HTML, which is why status-code checks give false confidence.

How to get it right

Fixing a client-side rendered site

  • Test what a non-JavaScript fetch returns for each template
  • Switch content-bearing routes to server-side rendering or static generation
  • Keep CSR for genuinely app-like, logged-in areas where crawling doesn't matter
  • Avoid dynamic rendering as a long-term fix; it's fragile and adds infrastructure
  • Re-verify after every framework upgrade

Common questions

Can we keep CSR and still be visible?

Only partially. Googlebot will render eventually, but crawlers that don't execute JavaScript won't see anything regardless of how long they wait.

For AI visibility, content-bearing pages need to be server-rendered.

What about dynamic rendering?

Serving pre-rendered HTML to bots and CSR to users works, but it's fragile, adds infrastructure, and can drift out of sync with the user-facing version.

Treat it as a stopgap rather than an architecture.

How do I test this quickly?

Fetch the page with curl and no JavaScript execution, then look at whether your headline and body copy appear in the response.

If you only see script tags and an empty div, that's CSR.

These come up alongside Client-Side Rendering constantly.

Free 12-point check

Send Ron your site

Two fields. We’ll crawl your site as GPTBot, ClaudeBot and PerplexityBot, benchmark a sample of your category’s prompts, and send you what we find.

  • What each AI crawler actually receives from your site
  • Whether models resolve your brand as a real entity
  • A sample of category prompts and who gets cited
  • The three fixes we’d prioritise first

No commitment, no sales sequence. If we’re not a fit, we’ll say so.

We’ll pull your favicon so you know we found the right site.

We reply from a real address. No sequence, no newsletter.