What is prerendering?
Prerendering is producing a web page's finished HTML before anyone asks for it, so the page does not have to be assembled at the moment it is viewed. The term has two meanings that are often confused:
- Prerendering for SEO. A site built with client-side JavaScript generates static HTML snapshots of its pages, either at build time or through a prerendering service, so search engine and AI crawlers receive the content as plain HTML.
- Prerendering in the browser. A browser loads and renders a page the user is likely to visit next, in the background, so the page appears instantly when the user clicks. In Chrome this is controlled with the Speculation Rules API.
The first is about what crawlers see. The second is about how fast users get the next page. They share a name and nothing else, and an article that mixes them up will give wrong advice about both.
What is prerendering in SEO?
Prerendering in SEO means giving crawlers a page's content as ready-made HTML so they do not have to run JavaScript to see it. Many modern sites use client-side rendering: the server sends a near-empty HTML shell, and JavaScript in the browser loads and inserts the content [1]. A crawler that does not run JavaScript, or runs it late, sees the empty shell.
Prerendering fixes that by rendering the page ahead of time, in a headless browser or at build time, and saving the result as HTML. There are two ways to use that HTML:
- Serve it to everyone. The prerendered HTML is the page, for users and bots alike. This is static rendering, sometimes called static site generation, and it is one of the approaches Google recommends [1].
- Serve it only to bots. The server checks the user agent, sends prerendered HTML to crawlers, and sends the normal JavaScript app to users. This is dynamic rendering, and it is usually what people mean by "using a prerender service" [1].
Does Google still recommend dynamic rendering?
No. Google calls dynamic rendering "a workaround and not a recommended solution, because it creates additional complexities and resource requirements" [1]. Its documentation now says dynamic rendering was a workaround and not a long-term solution, and recommends server-side rendering, static rendering or hydration instead [1].
Google's reasoning is practical. A bot-only rendering setup is a second system to maintain: it can serve stale snapshots, break silently, or drift from what users see. Google's own rendering has also improved. Googlebot renders pages and runs JavaScript using a recent version of Chrome [3], and Google announced an "evergreen" Googlebot in May 2019 [6]. Pages with a 200 status go into a render queue, where headless Chromium executes the JavaScript [2].
What Google's guidance does not say is that existing dynamic rendering setups are penalized. A working setup that serves similar content is acceptable; Google simply does not want new sites to build one.
Is prerendering cloaking?
Prerendering is not cloaking as long as crawlers and users get similar content. Google says it generally does not consider dynamic rendering to be cloaking, as long as the dynamic rendering produces similar content [1]. Using dynamic rendering to serve completely different content to users and crawlers can be considered cloaking [1]. Google's example: serving a page about cats to users and a page about dogs to crawlers.
Static rendering for everyone raises no cloaking question at all, since every visitor gets the same HTML.
What is prerendering in the browser?
Prerendering in the browser is a speed feature: the browser fetches and fully renders a page the user is expected to open next, in a hidden background tab, then swaps it in instantly when the user navigates there. In Chrome, a site asks for this with the Speculation Rules API, a JSON block in the page:
<script type="speculationrules">
{
"prerender": [
{ "urls": ["/glossary/crawl-budget", "/glossary/canonicalization"] }
]
}
</script>The browser treats these rules as suggestions and may skip them, for example to save memory or data. Browser prerendering has nothing to do with search engine crawling. Crawlers do not act on speculation rules to decide what to index, and a prerendered page is the same page the server would have sent anyway.
Browser prerendering does have side effects that matter to SEO and analytics teams:
- Analytics and ad counts. A prerendered page may run its scripts before the user ever sees it. Analytics should count a view only once the page is actually shown; JavaScript can check
document.prerenderingto tell the difference. - Server load. Every speculative prerender is a real request to the server. Prerendering many links that users never click adds load for no benefit.
- Server logs. Chrome marks speculative requests with a
Sec-Purposerequest header, so they can be separated from normal page views in logs.
What is the difference between prerendering, server-side rendering and dynamic rendering?
Prerendering builds HTML before a request, server-side rendering builds HTML on the server at the moment of each request, and dynamic rendering serves different versions to bots and users. All three aim to deliver content as HTML rather than relying on the visitor to run JavaScript.
| Approach | When HTML is built | Who gets it | Google's position |
|---|---|---|---|
| Static rendering (prerendering for everyone) | At build or publish time | Everyone | Recommended [1] |
| Server-side rendering | On each request | Everyone | Recommended [1] |
| Hydration | Server HTML, then JavaScript adds interactivity | Everyone | Recommended [1] |
| Dynamic rendering (prerendering for bots) | Ahead of time or on demand | Crawlers only | Workaround, not recommended [1] |
| Client-side rendering only | In the visitor's browser | Everyone, as a JavaScript shell | Works for Google if rendering succeeds [2] |
| Browser prerendering (Speculation Rules) | In the user's browser, before the click | That user | Not a search topic |
See server-side rendering for crawlers and JavaScript rendering for those approaches in more depth.
How has Google's view of prerendering changed?
Google moved from asking sites to supply crawlable HTML snapshots, to endorsing dynamic rendering as a stopgap, to rendering JavaScript itself and recommending server or static rendering for everyone. The dates below come from Google's own blog and documentation.
2017: the end of the AJAX crawling scheme
In December 2017, Google published "Rendering AJAX-crawling pages" [4], about pages built for its older AJAX crawling scheme, under which sites supplied HTML snapshots of their JavaScript pages to Google through special URLs.
2019: dynamic rendering with Rendertron
In January 2019, Google published "Dynamic Rendering with Rendertron" [5], describing bot-only prerendering with an open source headless Chrome renderer.
2019: evergreen Googlebot
In May 2019, Google announced the new evergreen Googlebot [6], keeping its rendering engine on a recent version of Chrome and removing many of the reasons sites had prerendered for Google.
Today: a workaround
Google's dynamic rendering page, last updated December 10, 2025, calls dynamic rendering a workaround that was never a long-term solution [1].
Do AI crawlers need prerendered HTML?
Whether an AI crawler runs JavaScript is up to each operator, and most do not publish rendering details. Google documents its rendering in detail [2][3]; Search Insider has not found equivalent documentation from AI companies for their crawlers. The cautious assumption is that content which only appears after JavaScript runs may be invisible to some AI crawlers. Server-side or static rendering covers every crawler at once, which is a stronger reason to use them than Google alone provides.
When should you use prerendering?
Use prerendering for everyone (static rendering) when pages change no more often than you can rebuild them, such as articles, documentation and glossaries. Use server-side rendering when content changes per request. Consider dynamic rendering only as a temporary fix for an existing JavaScript app that cannot be changed soon, and keep the bot version's content in step with what users see [1]. Use browser prerendering separately, on the few links users are most likely to click, to make navigation feel instant; it will not change how the site is crawled or ranked.