JavaScript rendering (SSR vs CSR)

JavaScript rendering is how and where a page’s HTML gets built. With server-side rendering (SSR), the server sends fully-formed HTML that crawlers read on the first pass. With client-side rendering (CSR), the server sends a near-empty shell and the browser builds the content with JavaScript. The difference decides whether search and answer engines reliably see your content or wait, and sometimes fail, to render it.

How it works

Google can render JavaScript, but it does so on a second pass, on its own schedule, and other crawlers and answer engines often do not render at all. Content that only appears after JavaScript executes — or after a click — sits in a gradient of lower indexing confidence than content present in the initial HTML response (what you see in View Source). SSR, static generation, or prerendering put the content in that first response. The practical rule: keep primary content, links, and structured data in the server-rendered HTML; use JavaScript for interactivity, not for loading the content itself.

Where it applies

• Single-page apps — React, Vue, and Angular sites that default to CSR are the classic risk.
• Ecommerce — product data, reviews, and internal links loaded by JavaScript may not be fully credited.
• AEO — answer engines chunk the rendered HTML; content behind interactions is invisible to them.

What matters from each seat

• Engineering — choose SSR, static, or prerendering for content-critical routes; validate against the raw HTML response.
• In-house — test with View Source and a mobile crawler, not just the browser DOM, which hides the gap.
• Agency and consulting — a rendering-parity check (raw HTML vs rendered DOM) is a core technical-audit deliverable.