Prerendering

Prerendering is producing a page's HTML before a visitor or crawler asks for it, usually at build time, so the server can send the finished page instead of an empty shell that JavaScript fills in. It is the lightest way to make a single page app readable by crawlers that do not run JavaScript. The same word is also used for rendering on request for crawlers only, which Google calls dynamic rendering and treats as a workaround.

By , founder of Porteur · Updated 23 September 2026 · Markdown

The two meanings of prerendering

  • Static prerendering: at build, each route is rendered once and saved as an HTML file. Every visitor and every crawler gets the same file. The browser then hydrates it into the interactive app.
  • Prerendering for crawlers: at request time, a service detects a bot, renders the page in a headless browser and sends it the result. Human visitors get the client-rendered app. Google documents this as dynamic rendering.

When a hosting platform or a framework says it prerenders, find out which one it means. The first is a normal way to build a site. The second is a patch over a client-rendered one.

Prerendering vs SSR and dynamic rendering

ApproachWhen the HTML is madeWho gets itFits
Static prerenderingOnce, at buildEveryonePages that change with a deploy: marketing, pricing, docs
Server-side renderingOn each requestEveryonePages built from data that changes between deploys
Dynamic renderingOn request, for botsCrawlers onlyA stopgap for a client-rendered app
Client-side renderingIn the browserWhoever runs the JavaScriptPages behind a login

Google recommends server-side rendering, static rendering or hydration, and describes dynamic rendering as a workaround and not a recommended long-term solution. Static prerendering is on the recommended side: it is static rendering by another name.

Why it matters for a single page app

A client-rendered app sends an HTML file with no text in it. Google renders it later, in a second pass; most AI crawlers never do. Prerendering the public routes puts the words, the title and the links in the first response, so every crawler reads the page the moment it fetches it.

You do not have to prerender the whole app. The dashboard behind the login can stay client-rendered; only the pages you want found need it.

How to check prerendering works

# The text should be in the response, with no JavaScript run
curl -s https://yourproduct.com/pricing | grep -c 'a sentence from your pricing page'
curl -s https://yourproduct.com/pricing | grep -o '<title>[^<]*</title>'

If the page is prerendered for crawlers only, curl with an ordinary user agent will show the empty shell, and a faked crawler user agent may too if the service only serves verified crawlers. Use the live test in Search Console's URL Inspection instead: its rendered HTML is what Google received.

When prerendering becomes cloaking

Serving crawlers content that differs materially from what users see is cloaking under Google's spam policies. Prerendering the same content is not. The page a bot receives must carry the same text, links and offers as the page a person sees once the app has loaded.

Questions

Check my site, free

Paste your URL into the free check: in about thirty seconds it reads your site, the searches around it and the rivals on them, and shows three findings whole.

  • Free check, no card
  • Read-only, your own accounts
  • Readable by your agent

Read next