SSR vs Prerendering vs Static Generation: Which Gets Your Content to AI Crawlers

Vercel's crawler study found that ChatGPT and Claude crawlers fetch JavaScript files (11.50% and 23.84% of their requests) but don't execute them, so they can't read client-side rendered content. Independent re-testing in June 2026 found the same for GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, PerplexityBot, Meta-ExternalAgent and Bytespider.

Google is the exception. Googlebot renders JavaScript, so this gap matters far less for AI Overviews and AI Mode (see whether AI Overviews need server-side rendering). Apple's crawler also renders.

So the practical question for a React, Vue or similar site is simple. When a crawler requests the page and reads the response without running scripts, are your product names, prices and core claims in it? If they only appear after hydration, the answer is no.

Be clear about what this fixes. Getting content into the HTML decides whether it exists for the crawler at all. It does not make an engine more likely to select or cite you. That part sits with the retrieval system and the model, and nobody outside them controls it.

Server-side rendering (SSR)

The server builds the full HTML for each request, then sends it. The browser shows content immediately and JavaScript takes over afterwards. Every visitor and every crawler gets a current page.

Static site generation (SSG)

Static site generation builds every page into HTML files at deploy time. A CDN serves those files as they are. Nothing is computed per request, so pages are fast and cheap to serve. The catch is freshness: a page only changes when you rebuild it. Many frameworks offer incremental rebuilds that refresh individual pages on a schedule or on demand.

Prerendering

Prerendering runs your client-side app in a headless browser ahead of time and saves the resulting HTML. A common setup detects crawler user agents and serves them the saved snapshot, while human visitors still get the JavaScript app. It's usually a bolt-on for an existing single-page app that can't be rebuilt quickly.

The table shows the real choice. All three can put the same facts in the HTML. They differ in how they keep those facts current and what that costs you to run.

Prerendering is legitimate when the snapshot a crawler receives matches what a user sees. It turns into cloaking when the two differ. Google's spam policies treat showing search engines different content from users as a violation, and AI crawlers are no different in principle.

The risk comes in two forms:

• Drift. Your pricing page changes, the snapshot doesn't. The bot now reads an old price and an AI answer can repeat it. Nobody intended it, but the mismatch is real.
• Deliberate differences. Some sites serve bots extra copy, keyword blocks or hidden instructions aimed at AI models. That is cloaking, and injecting instructions for AI crawlers is adversarial content. Research on search agents shows manipulated pages can sway answers once retrieved, which is exactly why engines treat it as abuse. Don't do it.

If you prerender, re-render snapshots on every content change, not on a fixed weekly schedule. Then compare the bot version and the user version for the same URL. SSR and static generation avoid this class of problem because everyone gets the same HTML.

Don't assume your framework renders what you think it does. Partial hydration, client-only components and content inside tabs or "load more" buttons often leave key facts out of the first response.

The test is a diff:

1. Fetch the page with JavaScript disabled and save the text.
2. Load the same page in a headless browser and save the rendered text.
3. List every heading, price, product name and claim that appears only in the second version.

The raw HTML vs rendered DOM check walks through this step by step, and the free JavaScript rendering check runs a quick version for one URL. Vercel notes that data embedded in the initial HTML response (for example serialised JSON from React Server Components) may still be indexed, but visible text in the HTML is the safer target.

Rendering is one gate. A crawler also needs robots.txt permission and a firewall that lets it through, so check those alongside.

Pick based on how often the content changes and what your stack already supports.

• Use static generation for marketing pages, documentation, blog posts and pricing that changes a few times a year. It's the cheapest and simplest way to get every fact into the HTML. Rebuild on every content change.
• Use SSR for pages where facts change daily or vary by request: inventory, live pricing, large catalogues. Accept the server cost in exchange for always-current HTML.
• Use prerendering as a stopgap for a client-side app you can't re-architect this quarter. Re-render on change and audit snapshots against the live page.
• Mix them. Most sites don't need one answer. Statically generate the marketing site, server-render the dynamic sections, and leave logged-in app screens client-side, since crawlers never see them anyway.

Start with the pages that carry the facts you'd want an AI answer to get right: pricing, product, about and comparison pages. The SSR and prerendering rollout plan sequences that work page by page.

Will switching to SSR increase my AI citations? Not by itself. Server-side rendering makes content readable to crawlers that don't run JavaScript. That removes a block, but it doesn't make an engine more likely to choose your page over others. Whether a retrieved page gets cited depends on the query, the other candidates and the model. More on this in [whether SSR increases AI citations](/questions/ssr-increase-ai-citations). Treat rendering as hygiene that has to be right before anything else can work.

Does Google need my site to be server-rendered for AI Overviews? Less than other engines do. Googlebot renders JavaScript, and Google says a page needs to be indexed and eligible for a snippet to appear as a supporting link in AI Overviews or AI Mode, with no extra technical requirements. Rendering still helps Google crawl faster and more reliably, but the urgent gap is with ChatGPT, Claude, Perplexity and Meta crawlers, which don't execute JavaScript.

Is prerendering for bots against Google's rules? Not if the crawler gets the same content a user sees. Serving a saved, rendered copy of the same page is a delivery choice. It becomes cloaking when the bot version differs, whether through stale snapshots or deliberate extra content. Keep snapshots in sync with every content change and compare bot and user versions regularly. If you can move to SSR or static generation, the mismatch risk goes away.

What if only some of my content loads with JavaScript? Then only that content is at risk. A common pattern is a server-rendered shell with prices, reviews or feature tables fetched by client-side scripts afterwards. Crawlers that don't execute JavaScript see the shell without those facts. Run a raw HTML versus rendered diff on your key templates and move the missing facts into the initial response, using whichever of the three methods fits that page.