If you have a single-page React, Vue, or Angular site, AI tools and crawlers probably see a near-empty HTML shell when they fetch your pages. The two real fixes are server-side rendering (SSR) and static prerendering. Both make crawlers see the same content humans see. They are not the same shape of solution, and one is usually a much smaller commitment than the other.

The two options in plain English

SSR runs your app on a Node server for every visitor: the server builds fresh HTML each time someone shows up. Prerendering runs your app once when you deploy, captures the HTML for every page, and saves it as static files. Production then serves those files directly.

  • SSR: built per request, can be different for each visitor. Needs a render server you have to run, monitor, and pay for.
  • Prerender: built once at deploy time, same HTML for everyone until you deploy again. No extra server to run.

When prerendering is enough

If most of your indexable pages show the same content to every visitor (a typical marketing site, blog, or documentation site), prerendering is almost certainly enough. You get the same crawler benefit as SSR with a fraction of the operational cost. This is the path Stackra picked for stackra.app.

  • Read the full case study →

    How Stackra shipped a prerender pipeline in 1-2 days instead of migrating to Next.js. Numbers, pain points, and verification.

When SSR is genuinely the right call

SSR earns its weight when one of these is true:

  • Pages need to look different per visitor in the HTML itself (regional pricing, A/B variants, logged-in views that should still rank).
  • Content updates several times per hour. A deploy per change is not realistic.
  • You have tens of thousands of pages that all need to be indexable. Building every variant at deploy time is impractical.
  • You are already on Next.js, Remix, or Nuxt. SSR is one config flag and the migration cost is zero.

The decision in one minute

Ask yourself four questions:

  • Does the same HTML work for every visitor on every indexable page? If yes, prerender is enough.
  • Does your content change between deploys often enough that a deploy-per-change cadence is painful? If yes, lean toward SSR.
  • Is your indexable page count small enough to render every variant at deploy time? Hundreds is fine. Hundreds of thousands probably is not.
  • Are you already on a framework that does SSR by default? If so, the choice is mostly operational preference.

The honest summary

Prerender is not better than SSR. They are answers to different shapes of problem. SSR shines when the HTML legitimately needs to be different per request. Prerender shines when it does not, and you would rather not run a render server to prove the point. Pick the shape that matches your site, not the framework with the loudest fan club.