A typical SPA runs in the browser — JavaScript builds every page on the fly. That works perfectly for people who visit, but not everything on the internet runs JavaScript.
When you paste a URL into Discord, Twitter, or Slack, those services fetch your page and look at the HTML to build a preview card. They don't run JavaScript. For an SPA, every page serves the same empty HTML file — so every preview is blank.
Search engines hit a similar snag — Google can run JavaScript, but it's slower and less reliable than reading plain HTML.
Prerendering runs your site's code once at build time — when you deploy, not when someone visits. It generates a real HTML file for each page with all the content baked in. The result is the same page your visitors see, but it's ready before anyone asks for it. (You might also hear this called static site generation or SSG — same idea.)
| Without prerendering | With prerendering |
|---|---|
| One empty HTML file for all | One HTML file per page |
| Link previews see nothing | Link previews show real content |
| Search engines need extra work | Search engines see content immediately |
Prerendering works for pages where the content is the same for every visitor. Your homepage, about page, projects page — those are all fixed. The content doesn't change between visits.
But what about a page that depends on data someone created after you deployed? Like a form someone built, or a dashboard with live numbers? You can't prerender a page for data that doesn't exist yet. For that, you need the server to build the HTML on demand, every time someone visits. That's server-side rendering (SSR).