What is a static site generator? How SSGs work and when to use one

Hand-written HTML sites were static too; generators make the approach practical for sites with hundreds of pages and shared layouts. Google's web.dev guide to rendering describes the output: "Generally, static rendering means producing a separate HTML file for each URL ahead of time," which you can then deploy "to multiple CDNs to take advantage of edge caching." A default WordPress install works the opposite way, assembling each page on request; static vs dynamic websites compares the two.

How a static site generator works

A build runs in four steps.

1. Content goes in. Posts and pages as Markdown files with front matter (title, date, description), data files in JSON or YAML, or entries fetched from a headless CMS or API during the build.
2. Templates set the layout. A base layout holds the head, header and footer; page templates decide how a post, an archive or the home page looks.
3. The build renders every URL. The generator merges each piece of content into its template and writes one HTML file per route, plus images, CSS and any feeds or sitemaps it is configured to produce. Jekyll's homepage sums it up: "Markdown, Liquid, HTML & CSS go in. Static sites come out ready for deployment."
4. The output is deployed. The folder of files goes to a static host or CDN. Nothing runs on the server afterwards.

Changing any content means running the build again, which explains most of the trade-offs below.

Static site generator examples

Generator	Written in	Known for
Jekyll	Ruby	Blog-aware from the start; powers GitHub Pages
Hugo	Go	Build speed, multilingual sites, taxonomies
Eleventy (11ty)	JavaScript	Template-driven; mixes Markdown, Liquid, Nunjucks and HTML
Astro	JavaScript	Content sites built from components, with little client JavaScript
Next.js static export	JavaScript (React)	React sites exported as one HTML file per route
Gatsby	JavaScript (React)	React sites fed through a GraphQL data layer

Each project describes itself in its own terms. Hugo calls itself "a static site generator written in Go, optimized for speed and designed for flexibility," and says it "renders a complete site in seconds, often less." Jekyll leads with blogging: "Permalinks, categories, pages, posts, and custom layouts are all first-class citizens here," and since "GitHub Pages is powered by Jekyll," a Jekyll blog can be hosted there for free. Astro calls itself "the web framework for building content-driven websites like blogs, marketing, and e-commerce," with pages either prerendered or rendered on demand.

The JavaScript frameworks blur the category. web.dev notes that tools like Gatsby "are designed to make developers feel like their application is being rendered dynamically, not generated as a build step," while 11ty and Jekyll "embrace their static nature." Next.js can export a fully static site: "When running next build, Next.js generates an HTML file per route." The price is that a static export gives up the features that need a server, including redirects, incremental static regeneration and image optimization with the default loader.

Where the content comes from

A static site generator is not a content management system. It builds pages; it does not store, edit or schedule content. That content lives in one of two places.

Markdown in the repository. Posts are files committed next to the code, with version history and review through pull requests. That suits developer blogs and documentation, and suits non-technical editors poorly unless a Git-based CMS gives them a form to write in.

A headless CMS or API. The build fetches entries from a content API and renders them. Editors keep a familiar interface, and the same content can feed other channels. The cost is a second system and a build that has to rerun when content changes. Headless vs traditional CMS covers that architecture, and the Next.js CMS comparison the main content sources for one popular front end.

Pros and cons

What a static site generator gives you:

• Speed. Static rendering achieves "a consistently fast TTFB, because the HTML for a page doesn't have to be dynamically generated on the server."
• Security. No server code or database answers each request, so there is little to attack.
• Cost and portability. Static hosting is cheap or free, a CDN absorbs traffic spikes, and any host can serve plain files.

What it costs you:

• A build for every change. web.dev names the scaling limit: static rendering "must generate individual HTML files for every possible URL," which "can be challenging or even infeasible when you need to predict those URLs ahead of time and for sites with a large number of unique pages."
• Outside services for dynamic features. Search, comments, forms and logins need a third-party service or a small API.
• A CMS for non-developers. Editors who do not use Git need an editing layer on top.

Static site generators for a blog

A blog is mostly the same page for every reader, so static output fits it well. Three things need planning.

Scheduled posts. A post dated for next Tuesday appears only when a build runs after that time. Scheduling on a static blog therefore means scheduling builds, with a nightly job or a hook your CMS calls on publish.

Build times. A few hundred posts build quickly. Thousands of posts, or a set of programmatic SEO pages, push toward frameworks that regenerate one page at a time instead of the whole site, such as incremental static regeneration in Next.js.

Previews. Seeing a draft before it goes live needs a preview build or a framework's preview mode.

Static site generators and SEO

Search engines index the HTML they receive, and a static page arrives complete, so a generated site is easy to crawl and quick to load. The SEO risks are about what the build leaves out. Titles, meta descriptions and canonicals come from templates and front matter, so one missing field means a missing tag on every post. A sitemap, feeds or an llms.txt file exist only if the build produces them. Redirects and 404 status codes are the host's job, and a stale build keeps serving an old title or a deleted page until it reruns. Headless CMS SEO lists everything a front end has to output once no CMS does it for you.

How Structura handles this

Structura can be the content source for a statically built blog. A headless space serves published posts from a public Content API that any generator able to fetch JSON at build time can read. Page through the list endpoint, up to 50 posts per page with a cursor to the next, then fetch each post for its sanitized HTML, meta title and description, Open Graph fields, images with dimensions and alt text, and a schema array of JSON-LD. Links inside the HTML already point at your public domain, and publishedAt and updatedAt on every post tell the build what changed. The developer docs show a Next.js example; the same JSON works in Astro, Eleventy or a custom build script.

Structura does not trigger your build. Publishing a post in the portal makes it available on the API, and it reaches your site with the next build. Schedule builds to match the campaign's cadence or, on paid plans, use article delivery to send each published post to an HTTPS endpoint of yours that starts a rebuild. The API-first CMS page shows the endpoints.

FAQ