What's the difference?
Build-time (static) rendering generates the full HTML ahead of time and serves it complete — the words are in the file before any request. Client-side rendering (CSR), the default of a single-page app, sends a near-empty shell plus a JavaScript bundle, and the browser builds the page after executing it. Server-side rendering (SSR) sits between: the server renders the HTML per request.
For a human on a fast device the difference can be invisible. For a crawler — and for an AI retriever — it is the difference between reading the page and having to run your application to discover what it says.
Why does it matter for SEO?
Crawlers ingest HTML cheaply and execute JavaScript expensively. When content only appears after JS runs, indexing it becomes a second, deferred pass against a render budget — it can be delayed, and any script error or blocked resource can leave the content simply invisible. Pre-rendered HTML removes that entire failure class: the content is present on the first fetch, no execution required.
The same property is what makes a page reliably retrievable for AI answers — the text is there to be read — which is why retrieval and crawlability are the same problem (see how AI engines choose citations).
How a static generator does it
Our generator reads a canonical dataset, splices the relevant fragments into HTML templates at build time, and writes finished pages to disk. There is no client framework involved in delivering content: the page a crawler fetches, the page a person sees, and the page an AI retriever reads are byte-for-byte the same.
That identity is the point. It also composes with doing programmatic SEO defensibly — generating at scale from real data — because the build step is where the data becomes HTML once, correctly, for every audience.
How can you tell what a page actually ships?
You don't have to guess which rendering a site uses — you can check in seconds. View source (the raw HTML the server sent, not the inspected DOM) and search for your headline or body text: if it's there, the content is in the HTML; if the source is a near-empty shell wrapped around a large script bundle, it's client-rendered. Second test: disable JavaScript and reload — build-time and server-rendered pages still show their content; a pure SPA goes blank.
That blank page is roughly what a crawler sees on its cheap first pass. If your content vanishes with JS off, it's the content a crawler may miss too — a free diagnostic worth running on anything you need found.
When is client-side fine — and when isn't it?
Client-side rendering is the right tool for genuinely interactive surfaces — dashboards, editors, app UIs behind a login — where there is nothing to index and the interactivity is the product. The mistake is using it for content you need found: marketing pages, articles, docs, listings.
The reliable pattern is hybrid — render the content at build or server time so it exists without JavaScript, then hydrate interactivity on top. The rule reduces to one line: anything you want crawled or cited must exist in the HTML before any script runs. Keeping that HTML lean also protects your crawl budget and Core Web Vitals.