Server-side vs. client-side rendering (SSR vs. CSR)

Server-side rendering (SSR) means the HTML is fully built on the server before it is sent to the browser. Client-side rendering (CSR) means the server sends a mostly empty shell, and the body content only appears after the browser runs JavaScript.

Static site generation (SSG) is a variant of SSR: the HTML is built once at deploy time, and each request simply returns the finished file.

	What the server sends	When the content exists
SSR	Complete HTML	On every request
SSG	Complete, prebuilt HTML	At build time
CSR	An HTML shell plus JavaScript	Only after scripts run in the browser

Why this matters for AI visibility

Most crawlers read the raw HTML in the HTTP response. Search engines such as Google can execute JavaScript, but rendering is queued and resource-limited, so there is no guarantee it happens promptly. Many crawlers used by AI assistants do not execute scripts at all.

For those crawlers, a page whose content only exists after JavaScript runs is an empty page. It cannot be indexed properly, and it cannot become a citation source in an AI answer. A company can have a polished, content-rich website and still be invisible to an assistant, simply because of how the site is rendered.

This is one of the most common technical findings in generative engine optimization (GEO) work, and one of the easiest to miss, because the site looks perfectly normal to a human visitor.

How to check your site

Two quick tests:

1. Fetch the raw source. Run curl https://yoursite.com/page and look for your headline, body text and structured data in the output.
2. Disable JavaScript. Turn off JavaScript in your browser’s developer tools and reload the page.

If the text, title or JSON-LD is missing in either test, the page depends on client-side rendering. This is the fastest single check in the technical layer of an AI visibility audit.

Check more than the homepage. Service pages, case studies and FAQ pages are the ones AI assistants are most likely to cite, and they are often built from different templates.

The usual compromise

You do not have to choose one mode for the whole site. The common pattern is:

• Content pages such as service descriptions, articles, glossary entries and case studies use SSR or SSG, so the body text is in the initial HTML.
• Interactive parts such as configurators, dashboards, search filters and logged-in areas keep client-side rendering.

Most modern frameworks support both modes in one codebase, often per page or per component. Making content crawlable does not mean giving up interactivity.

Related pitfalls

• Content behind clicks. Text that only loads when a tab is clicked or an accordion is opened may not be in the initial HTML even on an SSR site.
• Metadata set by scripts. Titles, meta descriptions and canonical tags injected by JavaScript may not be seen by crawlers that do not render.
• Blocked script files. If robots.txt blocks the JavaScript a page needs, even crawlers that can render will see a broken page.
• Infinite scroll. Content loaded only as the user scrolls is usually invisible to crawlers unless it is also reachable through regular paginated links.

Limits

Being crawlable is only the minimum. A page that can be fetched but says little of substance still will not be cited. Once the content is in the HTML, what earns citations is the content itself: a clear answer up front (see answer-first writing), specific facts and consistency with what other sources say about you.

To find out whether AI crawlers can actually read your key pages, request a free GEO audit.