Static site generator (SSG)
A program that builds a static website from source files (templates, content, data, configuration) at build time, producing a folder of HTML, CSS, and JavaScript ready to deploy.
Also known as: SSG, static generator
A static site generator (SSG) is a program that builds a complete static website from source files, templates, content (often Markdown), data files, and configuration, at build time. The output is a folder of HTML, CSS, JavaScript, and assets that can be deployed to any web host or CDN.
SSGs are central to the JAMstack approach and are used to build many marketing sites, blogs, documentation sites, and small-to-medium ecommerce sites.
How a static site generator works
A typical SSG build process:
- The SSG reads source files (templates, content, configuration, data)
- It applies templates to content, producing complete HTML pages
- It processes assets (compiles CSS from Sass, bundles JavaScript, optimizes images)
- It writes the output to a folder (commonly
dist/,public/, or_site/) - The output folder is uploaded to a host or pushed to a CDN
The build typically runs:
- On a developer’s machine during development
- Automatically on a CI/CD platform (Netlify, Vercel, Cloudflare Pages, GitHub Actions) when source changes are pushed
- On a schedule, when triggered by a webhook from a headless CMS, or on demand
Common static site generators
| SSG | Language | Notable strengths |
|---|---|---|
| Hugo | Go | Very fast builds, large theme ecosystem |
| Jekyll | Ruby | Original SSG; powers GitHub Pages |
| Eleventy (11ty) | JavaScript | Flexible, low-config |
| Astro | JavaScript / TypeScript | Component-based, partial hydration, multi-framework |
| Next.js (static export) | JavaScript / React | Hybrid SSG + SSR; large ecosystem |
| Nuxt (generate) | JavaScript / Vue | Vue equivalent of Next.js |
| Gatsby | JavaScript / React | GraphQL data layer, plugin ecosystem |
| Hexo | JavaScript | Popular for blogs, especially in Asia |
| Zola | Rust | Single binary, fast |
| MkDocs | Python | Documentation-focused |
| Docusaurus | JavaScript / React | Documentation + blog |
| VitePress | JavaScript / Vue | Documentation, Vue ecosystem |
What an SSG typically provides
- Template engine for layouts and components
- Content processing for Markdown, MDX, or other formats
- Routing based on file structure or configuration
- Asset pipeline for CSS, JavaScript, and images
- Build optimization (minification, code splitting, image optimization)
- Live reload during development
- Plugin or integration system for extending functionality
Strengths
- Performance. Pre-built HTML loads quickly; no per-request server work
- Hosting cost. Static files can be hosted free or very inexpensively
- Scalability. Static files served from a CDN scale to high traffic without infrastructure changes
- Security. No database or server-side execution on the request path reduces attack surface
- Version control. Source files in Git enable preview deployments, rollbacks, and code review
Limitations
- Build times. Large sites can have slow builds (mitigated by incremental builds in some SSGs)
- Dynamic content. Personalization, real-time data, and per-user content require additional architecture (APIs, edge functions)
- Editor experience. Without a layered CMS, content editing requires Git or specialized tools
- Initial setup. More involved than installing a hosted CMS
SSG vs traditional CMS
| Aspect | Static site generator | Traditional CMS |
|---|---|---|
| Content storage | Files in a repository (or fetched from CMS at build) | Database |
| Page generation | At build time | Per request |
| Hosting | Static host or CDN | Application server + database |
| Content editing | Markdown, headless CMS, or Git-based editor | Built-in admin interface |
| Setup complexity | Higher | Lower |
| Performance ceiling | High | Variable; caching helps |
SSG vs SSR framework
The line is blurring. Many modern frameworks (Next.js, Nuxt, Astro, SvelteKit) support both static generation and server-side rendering, often per-route. The choice between them within a project depends on whether content needs to be fresh per request.
Common workflows
- Blog or marketing site with Markdown content. Astro, Hugo, Eleventy, or Jekyll, with content in
.mdfiles - Site with content in a CMS. Astro or Next.js fetching from Sanity, Contentful, or WordPress (headless mode)
- Documentation site. Docusaurus, VitePress, MkDocs
- Multi-language site. Hugo or Astro, with locale-specific content directories
Common misconceptions
- “Static site generators are only for blogs.” They are used for marketing sites, documentation, ecommerce, and many other site types.
- “All SSGs require coding.” Most do require some configuration, but many sites can be built and updated with mostly Markdown editing.
- “SSGs can’t have a CMS.” They can pair with headless CMS platforms or Git-based editors that provide a familiar editing experience.