A static site generator takes templates and content — often Markdown files, sometimes data pulled from a headless CMS or API — and combines them into plain HTML files during a build step, before anyone visits the site. There is no database query or template rendering happening when a visitor loads a page; the file already exists, sitting on a server or CDN, ready to be sent as is. That shift, from building the page per visit to building it once ahead of time, is the entire value proposition.
What changed in 2026
- Islands and partial hydration became standard output, not an add-on, in most major generators, so static-first sites ship far less JavaScript than earlier generations of tooling.
- Incremental builds got fast enough for large sites. Generators now rebuild only the pages affected by a content change instead of the entire site, cutting deploy times on content-heavy projects substantially.
- The line between SSG and server rendering blurred, with several generators offering per-route rendering modes so a single project can mix static pages with server-rendered or incrementally regenerated ones.
- Content source flexibility widened, with most generators treating local files, headless CMS APIs, and databases as interchangeable content sources through a common data-fetching layer.
How the build step works
- The generator reads your content — Markdown files, CMS API responses, or local data files.
- It reads your templates or components and figures out which template applies to which piece of content.
- It renders every page to a static HTML file, resolving data, running any templating logic, and writing the output to a folder.
- You deploy that output folder to a CDN or static host. Nothing about serving it requires running your framework's code again.
Because the heavy lifting happens once, at build time, the runtime cost of serving a page is close to zero: a file transfer, not a computation.
Where the content comes from
Static site generators are not tied to any one content source. Common setups include:
- Local Markdown or MDX files committed alongside the code, common for documentation and blogs.
- A headless CMS queried at build time through its API, common for marketing sites with non-technical editors.
- A database or third-party API, fetched during the build and baked into the output.
Static generation compared with other rendering models
| Model |
When HTML is produced |
Good fit |
| Static site generation |
Once, at build time |
Blogs, docs, marketing pages, content that changes occasionally |
| Server-side rendering |
Per request, live |
Personalized or frequently changing pages |
| Incremental static regeneration |
At build, then refreshed on a schedule or demand |
Content that changes but not on every request |
| Client-side rendering |
In the browser, after a blank shell loads |
App-like interfaces where search visibility matters less |
When a static site generator is the wrong tool
If most pages are different for every visitor — a logged-in dashboard, a search results page with heavy filtering, real-time data — static generation fights the workload. You would either rebuild constantly or bolt on so much client-side fetching that the static output stops mattering. That is a sign to reach for server rendering or a hybrid approach instead, layered on top of the same build pipeline you would use anyway.
FAQ
Do static site generators support dynamic features at all?
Yes, through client-side JavaScript calling APIs after the static page loads — a contact form, a comment widget, or a shopping cart, for instance. The page itself is static; the interactive pieces are added on top.
How is a static site generator different from a JAMstack site?
An SSG is a tool; JAMstack is an architectural approach. Most JAMstack sites use a static site generator, but JAMstack is the broader philosophy of pre-building what you can and calling APIs for the rest.
Does content need a full rebuild every time it changes?
Not necessarily. Incremental static regeneration and incremental builds let generators rebuild only the affected pages, which is much closer to instant than rebuilding an entire large site.
Is a static site generator good for search visibility?
Generally yes — pages are fast, fully formed HTML is available immediately for crawlers, and there is no hydration or server delay standing between the crawler and the content.
Where to go next