What is prerendering?

Prerendering means running a page's JavaScript before the request arrives and storing the finished HTML. When a crawler or browser asks for the page, it gets that stored HTML, sometimes called a static snapshot, rather than an empty shell that still needs scripts to fill it in.

It sits between two neighbours. Static site generation builds every page as HTML at deploy time by design. Server-side rendering builds the HTML on each request. Prerendering usually retrofits an existing client-side app so its key pages ship as HTML. For a side-by-side view, see SSR vs prerendering vs static generation.

A typical setup follows four steps:

1. Pick the routes that carry load-bearing content: pricing, product pages, the homepage, documentation.
2. Render each route in a headless browser, which executes the JavaScript the way a user's browser would.
3. Save the resulting HTML as a snapshot and serve it from your server or CDN.
4. Regenerate the snapshot when the underlying content changes.

Some teams prerender every route at build time. Others use a service that renders on first request and caches the result. Both are fine as long as every visitor, human or bot, receives the same content. If you are planning the change, the SSR and prerendering rollout plan covers sequencing and testing.

Many AI crawlers read only the raw HTML. Vercel's study (published December 2024) found that ChatGPT and Claude crawlers do fetch JavaScript files (11.50% and 23.84% of their requests) but don't execute them. The evidence base we work from records that, as of June 2026, independent testing found the same for GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, PerplexityBot, Meta-ExternalAgent and Bytespider. Googlebot is the main exception: Google documents that it renders JavaScript.

What that means: if your price or product description appears only after hydration, those crawlers may store a page without it. Prerendering puts that content in the first HTML response.

Be clear about the limit. This is access hygiene. It decides whether your content exists in the candidate pool at all, not whether an engine picks it. Rendering is one gate among several: robots.txt permission per bot and firewall reachability matter too. Whether the fix changes citations is open, and this question on SSR and citations walks through what is and isn't known.

"Prerendering is cloaking"

No. Cloaking is showing search engines or bots different content from what users see. A faithful snapshot of the user-facing page is not cloaking.

"The bot snapshot can be tuned for AI"

This is where prerendering turns into cloaking. Adding hidden text, extra keywords or instructions only to the version served to AI crawlers is manipulation. Google's spam policies prohibit cloaking, and adversarial content aimed at AI systems is a reputational and policy risk. Never do it.

"Prerendering gets you cited"

No published study shows that. It removes a block; it does not add a ranking or citation signal.

"Set it up once and forget it"

Snapshots go stale. If your pricing changes and the snapshot doesn't, crawlers keep storing the old number, and AI answers can repeat a wrong fact. Tie regeneration to content publishing.

• Static site generation (SSG): building all pages as HTML at deploy time.
• Server-side rendering (SSR): building HTML on each request. Compared in SSR vs prerendering vs static generation.
• AI visibility tracking: measuring how AI platforms mention and describe a brand over time.
• Cloaking: serving different content to bots than to users. Prohibited, and the main risk to avoid when prerendering.

How do I tell if my site needs prerendering? Compare the raw HTML with the rendered page. Open view-source (not the browser inspector) and search for your price, product names and main headings. If they are missing from the source but visible on screen, they load through JavaScript, and crawlers that don't execute it may never see them. Those pages are candidates for prerendering or server-side rendering.

Does Google need prerendered pages? Generally no. Google documents that Googlebot renders JavaScript, so client-side content can still be indexed for Google Search and its AI features. Prerendering mainly helps crawlers that read raw HTML only, which per the Vercel study and later testing includes the main OpenAI, Anthropic and Perplexity crawlers. Serving HTML up front does no harm on Google either.

Is it allowed to serve snapshots only to bots? Serving a snapshot to bots and the live app to users is acceptable only if the content is the same. The risk is drift: the bot version gets edited, cached longer or stuffed with extra text. Once the two differ, it is cloaking. The safer setup serves the same prerendered HTML to everyone, which removes the question.

Is prerendering the same as server-side rendering? No. Server-side rendering builds HTML on each request, so it is always current. Prerendering builds HTML in advance and serves the stored copy, which is fast but can go stale. Both give crawlers finished HTML. The right choice depends on how often content changes and how your app is built.