What Google does and doesn't render
Googlebot does execute JavaScript, but in a two-pass system: it first crawls the raw HTML, then queues the page for a separate rendering pass that can lag by hours or days. For a low-priority site that rendering pass can be infrequent, which means new content appears in the index much more slowly than on a server-rendered site.
Even when rendering succeeds, Google's signals — internal links, structured data, anchor text — are computed from the rendered HTML. If your SPA renders a different navigation structure than the raw HTML, internal-linking and crawl-budget allocation suffer. Across audits we've run, pure-CSR SPAs index 30–60% fewer pages on average than equivalent server-rendered sites.
AI assistants do not render JavaScript
ChatGPT, Perplexity, Claude, and most other LLM crawlers fetch raw HTML and do not execute JavaScript. If your content only exists after JS hydration, those assistants see an empty page and cannot cite you. This is a hard ceiling on AI-search visibility for pure CSR sites.
Server-side rendering or static prerendering solves this completely. Even partial prerendering of the most important pages (homepage, top landing pages, top blog posts) is enough to unlock AI citations for those pages.
Practical patterns that work in 2026
Use a meta-framework that handles SSR or static generation natively: Next.js, Remix, Nuxt, SvelteKit, or Astro. For React-only or Vue-only SPAs, add a prerendering step at build time (we use headless Chromium to render and snapshot a curated URL list) so static HTML is served on first request.
Avoid the 'mostly client-rendered with a Helmet head' pattern. Without server-rendered content in the body, the Helmet-injected title and description help only marginally. The body content has to be present in the initial HTML for both Google's first-pass indexing and AI-retriever crawling.