When a Static Site Generator Is the Wrong Choice

This site exists because static site generators are the right choice for a very large share of the web: documentation, marketing sites, blogs, knowledge bases, changelogs. They are fast, cheap to host, hard to break and easy to roll back. That makes it worth being clear about where they are not the right choice, because teams who pick a generator for the wrong project spend months fighting it — building rebuild pipelines for content that changes every second, or prerendering a million pages that nobody visits — before conceding.

This guide sets out the five signals that a project has outgrown pure static generation, with the measurement that confirms each one, and the hybrid options that usually fit better than moving everything to a server. It belongs to the SSG Framework Selection Matrix, as the step before choosing which generator to use.

What Static Generation Assumes

Every static site generator makes the same bet: that content changes much less often than it is read, and that the set of pages is known at build time. When both hold, rendering once and serving the result from a CDN is unbeatable. When either fails, the cost moves elsewhere — into build time, publish delay, storage or client-side code.

Signal 1: Most Pages Differ Per User

Account pages, dashboards, order histories, admin panels. A static page can hold the shell — layout, navigation, empty states — and fetch data in the browser, but then the page is a client-side application with a static wrapper, and the generator adds little. Measure: the share of a typical page's visible content that depends on who is looking. Above roughly half, the page is an application. The common answer is a split: the marketing site and docs static, the logged-in product a separate application on its own subdomain or path.

Signal 2: Content Must Be Fresher Than a Build

A build publishes changes as fast as the pipeline runs: on a well-tuned site, one to three minutes from commit to live, as in Incremental Builds and Build Caching for SSGs. That is fine for documentation and even for news. It is not fine for stock levels, live prices, sports scores or seat availability. Measure: the business's tolerance for stale data against the 95th percentile commit-to-live time. A retailer measured that showing "in stock" for an item that sold out ten minutes earlier cost more in cancelled orders than the whole hosting bill; their product pages stayed static, but stock and price became a small edge-rendered island.

Signal 3: The Page Set Is Unbounded

One page per search query, per product-and-filter combination, per user profile, per date in a calendar. Prerendering them all is impossible or pointless: a travel site estimated 2.4 million route-and-date pages, of which fewer than 3% received a visit in any month. Measure: pages that would be generated against pages actually visited in 30 days. When the ratio is above about 10:1, render on demand and cache the result at the edge instead. Most generators now support this inside the same project — Astro's on-demand routes, Next.js dynamic routes, Nuxt's hybrid rendering — so the rest of the site stays static.

Signal 4: Editors Need Instant, Self-Service Publishing

Static sites publish through a pipeline. For developer-run docs that is a feature. For a newsroom or a marketing team used to a CMS where "Publish" means live in two seconds, a two-minute build with a separate preview environment is a change in how they work, and some teams will not accept it. Measure: how often editors need to publish urgently and how they react to the preview-and-build flow in a trial. Headless CMS webhooks with fast incremental builds close most of the gap, as in Wiring a Headless CMS to a Static Build; for the rest, on-demand revalidation of the changed page publishes in seconds.

Signal 5: Build Cost Grows Faster Than Traffic

A site whose build takes longer every month while its traffic stays flat is paying for pages that are not earning their keep. Large catalogues and archives hit this: every build re-renders hundreds of thousands of pages, most unchanged and rarely read. Measure: build minutes per month against page views per month, tracked over time. Before abandoning static generation, the usual fixes are incremental builds, segmenting the build (Parallel Hugo Builds Across CI Jobs), or prerendering only the visited head of the catalogue and rendering the long tail on demand.

The Hybrid Options

Server Islands in Astro and Vercel ISR vs Static Generation for SSGs cover two of these in practice.

A Worked Example

A B2B software company planned to rebuild its whole web presence — marketing site, docs, customer portal and a 30,000-product parts catalogue — on one static generator. Scoring each part against the five signals:

The result was three static-first sites and one application, instead of one generator stretched over all four.

Moving Part of a Site Off Static Without Starting Over

When one of the signals fires for part of a site, the change rarely needs a new framework. The parts catalogue in the example above stayed in the same Astro project: product pages remained prerendered, a server island rendered the stock and price box at the edge with a 30-second cache, and filter combinations moved to an on-demand route cached for an hour. The deploy pipeline, the CDN, the URL structure and the content model did not change. What changed was a handful of route files and an adapter.

The order matters. Measuring first keeps the dynamic surface as small as possible, which keeps most of the site's speed, resilience and cost advantages. Teams that start by switching the whole project to server rendering "to be safe" lose those advantages on every page to solve a problem that existed on a few. And keeping the change inside the same project means it can be reversed route by route if the measurements show the dynamic version is not worth its cost.

A practical test before any of this: ask whether a reader would notice if the dynamic part were two minutes stale. If not, a faster build or on-demand revalidation is cheaper than rendering per request. If yes, render only that part per request and leave the rest of the page — and the rest of the site — static.

Key Takeaways

• Static generation assumes rare changes and a known page set; when either fails, costs move elsewhere.
• Five signals mark the limit: per-user pages, freshness tighter than a build, unbounded page sets, editors needing instant publishing, and build cost outgrowing traffic.
• Measure each signal before deciding; most sites hit none of them.
• Hybrid options keep most pages static and render only what must be dynamic.

FAQ

What kinds of sites should not use a static site generator?

Sites where most pages differ per user, such as dashboards and account areas; sites whose content changes faster than a build can publish it, such as live scores or stock levels; catalogues so large that rebuilding them is impractical; and sites where non-technical editors need instant publishing without a build pipeline they can see. Each of these can still use static pages for parts of the site.

Is a slow build a reason to abandon static generation?

Usually not by itself. Builds can be made incremental, cached, split into segments or parallelised. It becomes a reason when the content changes faster than any realistic build can keep up, or when the number of pages grows without bound, such as one page per search query or per user.

What are the alternatives to a fully static site?

Hybrid rendering, where most pages are prebuilt and some routes render on demand at the edge; incremental static regeneration, where pages are rebuilt individually after a time or an event; server islands, where a mostly static page fetches one dynamic region; and a separate dynamic application for logged-in areas next to a static marketing and docs site.

Does adding a few dynamic features mean leaving static generation?

No. Forms, search, comments and personalised banners can all be added to a static site with edge functions, client-side scripts or third-party services. The question is the proportion: when most of a page's value depends on the request, rendering it statically adds work without benefit.

Related

• Parent: SSG Framework Selection Matrix — choosing a generator once static is the right model.
• SSG Selection Checklist for Engineering Teams — the questions to ask next.
• Total Cost of Ownership for Static Site Generators — costs on both sides of the decision.
• Server Islands in Astro — dynamic regions inside static pages.
• Vercel ISR vs Static Generation for SSGs — regeneration as a middle ground.