Prerendering means rendering a page ahead of time instead of when someone requests it. The word is used in three ways, and a search for it also returns graphics articles about pre-rendered 3D backgrounds, which have nothing to do with web pages.
Which meanings exist?
1. HTML created at build time. web.dev defines prerendering as “running a client-side application at build time to capture its initial state as static HTML.” The output is a plain HTML file per URL. Next.js and similar frameworks produce such files, so this meaning overlaps with static site generation.
2. Snapshots served to bots. Services render JavaScript pages in a headless browser, store the HTML and return it only to crawlers, while visitors still receive the JavaScript app. Netlify’s prerendering works this way and names crawlers, AI agents and preview services as targets. Google calls this pattern dynamic rendering and describes it as “a workaround and not a long-term solution.” Google also says it generally does not count as cloaking as long as both versions show similar content. Serving different content to users and crawlers can be cloaking. Google recommends server-side rendering, static rendering or hydration instead. Its page now describes dynamic rendering in the past tense.
3. Speculative prerendering in the browser. MDN describes this as speculatively fetching and rendering a page the user is likely to open next, in an invisible background tab. The Speculation Rules API controls it. Chrome’s documentation notes that a prerendered page opens in a hidden state, so analytics code may need to wait until the page is activated to avoid distorted measurements.
| Approach | Where and when is the HTML built? | Content in the delivered HTML? | Google's position |
|---|---|---|---|
| Client-side rendering (CSR) | in the browser with JavaScript; data fetching, templating and routing run on the client | no, only after JavaScript has run | Google renders pages with a 200 status in a separate step after crawling and still recommends server-side or pre-rendering because not all bots can run JavaScript |
| Server-side rendering (SSR) | on the server, for each request | yes | recommended by Google as a solution (instead of dynamic rendering) |
| Static site generation (SSG, static rendering) | at build time; usually one HTML file per URL ahead of time | yes | recommended by Google as a solution (instead of dynamic rendering) |
| Incremental static regeneration (ISR) | prerendered at build time; once the revalidation time has passed, the server regenerates the page in the background (framework feature, e.g. Next.js) | yes, from the cache; the older version is served until regeneration finishes | no specific statement from Google |
| Prerendering (this term) | at build time; the client-side app is run and its initial state saved as static HTML | yes (initial state) | Google says server-side or pre-rendering is “still a great idea” because it makes sites faster for users and crawlers |
| Dynamic rendering | a rendering server builds HTML only for detected crawlers; users get the client-side rendered version | only in the version served to crawlers | Google calls it a workaround and not a long-term solution; not cloaking as long as users and crawlers see similar content |
Google names server-side rendering, static rendering and hydration as replacements for dynamic rendering. The older web.dev article “Rendering on the Web” still calls dynamic rendering an option worth considering; this table follows the current Google Search Central documentation. ISR is not a web standard; the description comes from the Next.js documentation. Prerendering has other meanings too; this row uses the web.dev definition. Sources: web.dev: Rendering on the Web; Google Search Central: Understand JavaScript SEO basics (last updated 2026-03-04); Google Search Central: Dynamic rendering as a workaround (last updated 2025-12-10); Next.js Docs: How to implement Incremental Static Regeneration (ISR). Last checked: .
What does it mean for SEO?
Meanings 1 and 2 put the content into the HTML that a crawler fetches. Google renders JavaScript with a headless Chromium, but states that server-side or pre-rendering still helps because not every bot can run JavaScript. To compare both states, view the raw HTML and the rendered HTML of a URL.
Example
// React Router: create three routes as HTML files at build time
export default {
prerender: ["/", "/blog", "/blog/first-post"],
} satisfies Config;
Common mistakes
- Assuming interactivity: According to web.dev, most of a prerendered page is inert without JavaScript, and it generally needs more JavaScript to become interactive.
- Treating a workaround as a long-term solution: Google describes dynamic rendering as a workaround and not a long-term solution.
- Different content for crawlers and users: Google says dynamic rendering is generally not cloaking as long as both versions show similar content. Serving different content can be cloaking.
- Distorted analytics with speculative prerendering: A page prerendered by the browser opens in a hidden state, so analytics code may need to wait until the page is activated.
FAQ
What does prerendering mean? Generating a page’s output in advance, either at build time, for bots or in the browser before a click.
Is prerendering the same as SSR? No. SSR generates HTML for each request. Prerendering produces it before the request.
Sources
- Rendering on the Web – web.devweb.dev
- Prerender – MDN Glossarydeveloper.mozilla.org
- Prerender pages in Chrome – Chrome for Developersdeveloper.chrome.com
- Dynamic rendering as a workaround – Google Search Centraldevelopers.google.com
- Prerendering – Netlify Docsdocs.netlify.com
Last updated: