Server-side rendering (SSR)
Producing a page's HTML on the server so it is readable before any JavaScript runs.
With client-side rendering the server sends an near-empty document and the browser builds the page. Anything that does not execute JavaScript — many AI crawlers, some search infrastructure, a reader with scripting disabled — sees nothing. SSR produces the markup up front, so the content exists in the response itself.
Key facts
- A client-rendered page can return tens of kilobytes of HTML containing zero readable body text, because the text only exists after hydration.
- Full SSR is not the only remedy: rendering the same data into a server-side surface gives non-JavaScript clients the content without changing the architecture.
- Whatever the server renders must come from the same data the client renders, or the two versions diverge and the page becomes cloaking.
- Internal links are affected too: a link that only exists after hydration cannot be followed by a crawler that never hydrates.
Frequently asked questions
Do I have to adopt SSR to be readable by AI crawlers?
Not necessarily. Rendering the same content server-side — including inside noscript — is enough for the content to be present, and it is far less invasive than converting an application to SSR.
Is a server-rendered noscript block considered cloaking?
Only if it differs from what users see. Render it from the same data the client renders and it is the same content served to a client that cannot run the app. Hand-writing different text into it is what makes it cloaking.
Machine-readable copy of this page:
/glossary/server-side-rendering.md