Static Site Generators: What They Are and How to Choose One

A static site generator (SSG) turns content and templates into web pages before a visitor requests them. The build produces files—often HTML, CSS, JavaScript, and assets—that can be deployed to a static host or content delivery network. An SSG is a good fit when pages can be prepared ahead of time, such as blog posts, documentation, portfolios, marketing pages, and product listings. If a page must reflect data that changes for every request, consider server rendering or client-side data fetching for that part of the experience.

What is a static site generator?

An SSG is a build tool for websites. You provide source material—such as Markdown files, structured data, templates, styles, and code—and run a build. The generator combines those inputs into deployable pages. For example, Jekyll converts Markdown pages to HTML and writes generated output to _site. Next.js also supports static generation, producing pages ahead of a request so they can be served from a CDN. [Jekyll pages] [Next.js static site generation]

“Static” describes how a page is delivered; it does not mean the site can never be interactive. A generated page can run client-side JavaScript, load data in the browser, or link to server-backed features. Some frameworks also support server rendering for routes where the response needs current, request-specific data.

How static site generation works

Author source content. Write pages or records in the formats the tool supports, such as Markdown or structured data.
Define templates and components. These describe how content becomes a page and how pages share navigation, layout, and styling.
Run a build. The generator reads the source and produces the site output. Data fetched during the build becomes part of the generated result.
Deploy the output. Publish the generated files to a host that can serve them. Jekyll documents copying its generated directory to a host and gives Amazon S3 as an example. [Jekyll deployment]
Update by rebuilding. When source content or build-time data changes, run a new build and deploy the refreshed output.

The visitor receives prepared files rather than requiring the site to assemble every page on the server for each request. That can simplify delivery, but it does not by itself settle how fresh data is, how client-side features behave, or which deployment setup a project needs.

When should you use static generation?

Use static generation when the same prepared page can serve visitors until the next build or content update. Next.js lists marketing pages, blog posts, portfolios, product listings, help pages, and documentation as examples. [Next.js static site generation]

Build-time collections are also a natural fit for relatively stable content. Astro’s content documentation describes local content loaders for Markdown, MDX, Markdoc, YAML, TOML, and JSON. [Astro content collections]

Static generation may not be sufficient on its own when a page must show values current at the moment of each request, such as live stock prices. Depending on the feature, fetch the changing data in the browser or render the affected route on a server. Next.js documents these approaches as alternatives when pre-rendering does not fit. [Next.js rendering options]

How to choose a static site generator

Start with the content and runtime requirements, then compare tools against the way your team will build and maintain the site. There is no universally best generator established by the sources here; tools expose different content workflows and rendering capabilities.

Decide whether each page can be prepared ahead of time. Mark routes that need per-request information or behavior. A project can use static output for many pages while reserving server or client fetching for the ones that need it.
Set a freshness requirement. Ask how quickly a content change must appear. If a rebuild and deployment after edits are acceptable, build-time content may fit. If the answer must reflect data that changes on every request, plan a request-time or client-side mechanism.
List the formats and content organization you need. Check support for your actual authoring formats, collections, front matter or schemas, and content sources. Astro documents several local formats; Jekyll documents Markdown pages and configurable collections. Verify the current documentation for a candidate before choosing a version-specific workflow. [Astro content collections] [Jekyll collections]
Match the project to team skills. Compare the language, framework conventions, templates, integrations, and content editing process your team can support. A familiar workflow can matter more than a feature list if the site will be maintained for years.
Estimate the behavior the site needs. Decide how much client-side JavaScript, server rendering, forms, personalization, or live data the project requires. Check that the candidate supports the needed mix without making important routes hard to reason about.
Review the output and deployment path. Confirm what the build creates, where build commands run, how generated files are published, and how preview and production deployments fit your process. Static files can be deployed to ordinary hosting; confirm the chosen host and framework’s current instructions.
Try a representative slice. Build one page that uses the real content format, layout, data needs, and deployment process. This exposes workflow gaps without assuming framework benchmarks are comparable.

Static site generator or full framework?

The category includes purpose-built content tools and broader web frameworks that offer static generation as one rendering mode. The label alone is not a reliable selection rule. Compare what each candidate can do for your pages: how it accepts content, how it renders routes, what client-side or server-side behavior it supports, and how its output is deployed. Next.js presents static generation as one rendering mode; Gatsby’s comparison discusses frameworks and generators across static-content capabilities. Vendor comparisons describe the vendors’ own framing, not neutral performance benchmarks. [Next.js rendering modes] [Gatsby framework comparison]

Static generation, server rendering, and client-side fetching

Approach	When the page or data is prepared	Useful when	Trade-off to consider
Static generation	During a build, before the visitor request	Content can be shared as prepared output until the next update	Changes generally need a new build and deployment; do not assume the output is current per request
Server rendering	On the server in response to a request	The response needs request-time data or behavior	Requires a request-time server rendering path
Client-side fetching	In the browser after the page loads	A prepared page can load changing or user-specific data separately	Plan for the loading and failure states of that browser request

These approaches can coexist in a project. Choose per route or per data need rather than assuming one rendering model must handle every page. See the framework’s rendering documentation for the exact capabilities of a candidate and version. [Next.js rendering documentation]

Build and inspect a static site

There is no single build command shared by all generators. Follow the chosen tool’s official setup and build instructions. For Jekyll, the documented output directory is _site; inspect the generated files after a build and deploy that output according to the host’s instructions. [Jekyll pages] [Jekyll deployment]

After deployment, inspect the result as a visitor would: check representative routes, images, links, responsive layouts, and any browser-side behavior. A screenshot can make a visual review repeatable. ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. Its screenshot options and API details are documented at the ScreenshotNeo docs; the service is at screenshotneo.com.

Or skip the browser setup

To capture a deployed page as WebP, make one GET request. Replace the target URL with your own page and use your API key. See the API documentation for the available parameters and response details.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo accepts cookie and consent banners like a visitor, then removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status. Its MCP server gives AI agents tools for screenshots, page information, and PDF capture. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000. Create a free ScreenshotNeo account.

Common problems and fixes

Problem	Likely cause	What to check
A content edit does not appear	The deployed output was built before the edit, or the updated build was not deployed	Confirm the source changed, run the project’s documented build, and publish the new output.
A page shows stale data	The data was captured at build time but changes more often than the rebuild schedule	Reassess the freshness requirement. Use a suitable client-side fetch or server-rendered route for data that must be current on request.
A route works locally but is missing after deployment	The route was not included in generated output, or deployment points at the wrong output directory	Inspect the generated files and the framework’s route-generation and deployment instructions.
Some content formats do not load	The tool or configured loader does not support that format or content source	Check the current official docs for supported formats, loaders, and collection configuration; test with a small representative item.
Interactive content is empty or fails to update	The page assumes browser behavior or request-time data that the build did not provide	Identify whether the data should be fetched in the browser or rendered per request; add a clear loading and error state where appropriate.
A screenshot shows a consent layer or popup	The page has a banner or overlay visible to a normal browser capture	Use ScreenshotNeo’s consent and popup cleanup options, or configure a wait or hide rule if the page’s capture needs call for it; see the docs.

Performance, reliability, and cost considerations

Delivery: Prepared pages can be served as files through a CDN. Next.js recommends static generation where possible on the basis that a page can be built once and served by a CDN; this is framework guidance, not a universal benchmark for every site or hosting arrangement. [Next.js guidance]
Builds: A change that affects generated content requires a new output to be built and deployed. Consider how build and publish steps fit the editorial workflow, especially when content changes often.
Freshness: Make the acceptable delay between a source update and a visible page explicit. For per-request freshness, use a rendering or fetching approach that matches that requirement rather than relying on an old build.
Reliability: Serving generated files avoids assembling those pages on the server for each request, but the full site still depends on a successful build, correct deployment, working assets, and any separate APIs used by interactive features.
Cost: The research sources do not establish a comparable cost for SSG tools or hosting. Estimate the services your project actually uses—build infrastructure, hosting, data APIs, and any request-time runtime—and verify current provider terms before choosing.

Frequently asked questions

Is a static site generator the same as a static website?

No. The generator is the tool that transforms source content and templates into output. A static website is one possible deployed result; it can still include client-side interactive features.

Do visitors need the generator installed?

No. The build tool is used to create the site output. Visitors request the deployed pages and assets.

Can an SSG use a CMS?

It depends on the generator and content workflow. Check how a candidate connects to the content source and when that content is loaded into the generated output.

Which static site generator should I choose?

Choose by the freshness of your content, required formats and collections, team skills, rendering needs, and deployment workflow. Build a small representative page with the candidates that meet those requirements before committing.