What is prerendering?

Prerendering means running a JavaScript page in a browser ahead of time and saving the finished HTML, so crawlers and visitors get the full content without having to run the JavaScript themselves. It is done either at build time (static generation) or on request by a prerender service that renders pages for crawlers and serves them from a cache.

<body>
  <div id="root"></div>
  <script src="/app.js">
</body>

Prerendering in short

Why prerendering exists

A client-rendered page (a React, Vue, Angular or Svelte single page app without server rendering) is built in the browser. The server sends a short HTML file with a root element and a script tag. The browser downloads the script, runs it, fetches data and only then writes the headings, text and links into the page.

People do not notice, because their browser runs the JavaScript. Crawlers are different:

• Google renders, later. Google processes JavaScript apps in three phases: crawling, rendering and indexing. "Googlebot queues all pages with a 200 HTTP status code for rendering", and a page "may stay on this queue for a few seconds, but it can take longer than that." Vercel and MERJ measured the delay on nextjs.org in April 2024: median 10 seconds, 99th percentile about 18 hours.
• AI crawlers do not render. Vercel and MERJ found in December 2024 that "none of the major AI crawlers currently render JavaScript". That covers the crawlers from OpenAI, Anthropic, Meta, ByteDance and Perplexity. They read the HTML the server sends, and for a client-rendered page that is close to empty.
• Other bots vary. Social preview bots, SEO tools and smaller search engines often read only the raw HTML. Titles, descriptions and Open Graph tags set by JavaScript are invisible to them.

Prerendering closes the gap: the HTML is already finished when the crawler arrives. More on how AI crawlers see your site and whether ChatGPT can read JavaScript.

How prerendering works

The term covers two different setups. Both produce finished HTML. They differ in when the rendering happens.

Build-time prerendering

When you build the site, a tool opens each known route, waits until the page is ready and writes the HTML to a file. Your host serves those files like any static site.

Frameworks call this static site generation (SSG) or prerendering:

• Angular lists "Prerender (SSG)" as a rendering mode that "prerenders the application at build time, generating static HTML files for each route."
• Vue describes "Static Site Generation (SSG), also referred to as pre-rendering", and suggests it over SSR when you only need a handful of marketing pages to rank.
• Nuxt route rules can set prerender: true, which "prerenders routes at build time and includes them in your build as static assets."
• SvelteKit pages can export const prerender = true to be generated as HTML at build time.

The limit: only routes known at build time are prerendered, and the HTML is as fresh as your last deploy.

On-request prerendering (a prerender service)

A prerender service sits between crawlers and your existing site. This is what Google calls dynamic rendering. The steps:

1. Detect the crawler. A small piece of middleware on your server, CDN or edge (for example an Express middleware, a Cloudflare Worker or an nginx rule) checks the user agent. Visitors go straight to your site as before.
2. Ask the service. For a crawler request, the middleware asks the prerender service for the same URL.
3. Render in a real browser. The service opens the page in headless Chromium, runs the JavaScript and waits until the page is ready.
4. Return the HTML and the status. The crawler gets the rendered HTML with the page's own status code, so a missing page still returns 404.
5. Cache it. The rendered page is stored. The next crawler request for the same URL is served from the cache, and stale pages are re-rendered in the background.
6. Fall back safely. If the service is slow or down, the middleware serves your original page, so crawlers are never worse off than without it.

The advantage over build-time prerendering: every URL can be rendered, including pages created from live data, and you do not change your build or your app.

// Express: the official prerender-node middleware pointed at Prebaked
app.use(
  require("prerender-node")
    .set("prerenderServiceUrl", "https://service.prebaked.io/")
    .set("prerenderToken", process.env.PREBAKED_TOKEN)
);

Full steps, including the recommended fallback, are in the Express integration.

Prerender vs SSR vs SSG vs dynamic rendering vs CSR

Two terms are often mixed up:

• Prerender vs SSR. SSR renders every request on your own server, for people and bots. Prerendering renders before the request: at build time, or once for crawlers and then from a cache. SSR is the more complete long-term setup. Prerendering is the smaller change.
• Prerender vs SSG. Static generation is build-time prerendering. Framework docs use the words for the same thing. A prerender service is the on-request variant.

When prerendering is the right fix

Build-time prerendering fits when:

• the site has a small, fixed set of pages, such as a marketing site or documentation,
• content changes only when you deploy,
• your framework already supports it (Angular, Nuxt, SvelteKit and others do).

A prerender service fits when:

• you have a working client-rendered app and a rewrite to SSR is not worth it now,
• pages come from live data (products, listings, articles) and change between deploys,
• the app was built with a tool or framework that does not offer server rendering, for example many Lovable, Bolt and v0 sites,
• you need AI crawlers to read the content today, not after a migration.

When prerendering is not the right fix

• You are starting a new app. Pick a framework with SSR or static generation from the start. Google recommends "server-side rendering, static rendering, or hydration as a solution."
• Your site already sends finished HTML. If your framework renders on the server, a prerender service adds nothing. Check first with the free checker.
• Content is personal or behind a login. Crawlers cannot index it anyway, and prerendering it would cache content meant for one user.
• The problem is the content itself. Prerendering does not fix thin pages, duplicate titles, wrong canonicals or blocked URLs. See the technical SEO reference, for example robots meta tag, canonical tag and robots.txt.

Is prerendering cloaking?

No, as long as crawlers get the same content as people.

Google defines cloaking as "presenting different content to users and search engines" "with the intent to manipulate search rankings and mislead users". Its examples are showing a different topic to search engines, or inserting text or keywords only when the requester is a search engine.

A prerender service does the opposite: it runs your own page in a real browser and gives crawlers the result. Google's dynamic rendering guidance says "Googlebot generally doesn't consider dynamic rendering as cloaking", and adds that "using dynamic rendering to serve completely different content to users and crawlers can be considered cloaking."

What keeps prerendering safe:

• render the same URL, with the same content, that visitors get,
• do not add keywords, links or text for bots only,
• keep status codes and redirects the same for crawlers and people.

Google also says dynamic rendering "was a workaround and not a long-term solution", and that "not all sites need to use dynamic rendering". It is a supported way to make an existing JavaScript site readable, not a reason to avoid server rendering in a new build.

How to check if your site needs prerendering

1. Free checker. Compare your page without JavaScript and in a real browser: word count, headings and a verdict.

See what ChatGPT sees on your site

2. Raw HTML. See what crawlers that do not run JavaScript receive.

curl -s https://www.<your-domain>/ | grep -c "<h1"
curl -s https://www.<your-domain>/pricing | grep -o "<title>.*</title>"

0 headings, or the same title on every route, means the content and tags are added by JavaScript.

3. Google. The URL Inspection tool in Search Console shows the HTML Google rendered.

Prerendering with Prebaked

Prebaked is a prerender service for existing JavaScript sites.

• One snippet: Express, Cloudflare Worker, nginx, Netlify, Vercel or another integration.
• Real browser: pages render in Chromium. A page can signal that it is ready with window.prerenderReady = true.
• Same page for bots and people: Prebaked does not add or change content.
• Status codes kept: a page that renders as a 404 returns 404, and pages can set their status with the prerender-status-code meta tag.
• Never worse than today: if Prebaked is slow or unavailable, crawlers get your original page.
• Cache hits are free. You pay for fresh renders only. Warm the cache from your sitemap and set freshness per site.
• AI crawlers included: the crawler list covers GPTBot, OAI-SearchBot and ClaudeBot as well as search engines.
• Already using another prerender service? Change the service URL and token. See switching.

Prebaked does not guarantee rankings or mentions in AI answers. It makes sure crawlers receive the page your visitors see.

Guides by framework and topic

• Single page application SEO
• JavaScript SEO
• React SEO
• Angular SEO
• Vue and Nuxt SEO
• Svelte and SvelteKit SEO
• Lovable, Bolt and v0 sites
• Can ChatGPT read JavaScript?
• Technical SEO reference

FAQ