Static site generation (SSG) means a site’s HTML files are created once when the site is built, not when a visitor requests a page. A tool called a static site generator takes templates and content, such as Markdown files, and writes one HTML file per URL. MDN describes the result as a site with no server-side logic, so every visitor gets the same content for a URL.
How does SSG work?
During the build, the code runs once per page and saves the output. Next.js, for example, creates an HTML file for each route when next build runs, and the result can be hosted on any web server that serves static files. Typical generators are Jekyll, Astro, Eleventy and Hugo. The files are often delivered through a CDN.
web.dev lists the effects. Static rendering gives consistently fast time to first byte and first contentful paint, because the server computes nothing per request.
Where are the limits?
- Changes need a new build. If content changes, the affected pages must be generated and published again. Incremental static regeneration (ISR) updates single pages without a full build, but Next.js lists it as unsupported in a pure static export.
- Per-request logic is missing. The Next.js documentation lists cookies, redirects, rewrites and custom headers among the features a static export does not support.
- Personalized or live content. Pages that depend on the logged-in user or on live data need client-side requests or a server.
What does SSG mean for SEO?
The finished HTML already contains text and links, so crawlers do not need to execute JavaScript to see them. Google recommends server-side rendering, static rendering or hydration instead of dynamic rendering, which it calls a workaround.
| Approach | Where and when is the HTML built? | Content in the delivered HTML? | Google's position |
|---|---|---|---|
| Client-side rendering (CSR) | in the browser with JavaScript; data fetching, templating and routing run on the client | no, only after JavaScript has run | Google renders pages with a 200 status in a separate step after crawling and still recommends server-side or pre-rendering because not all bots can run JavaScript |
| Server-side rendering (SSR) | on the server, for each request | yes | recommended by Google as a solution (instead of dynamic rendering) |
| Static site generation (SSG, static rendering) (this term) | at build time; usually one HTML file per URL ahead of time | yes | recommended by Google as a solution (instead of dynamic rendering) |
| Incremental static regeneration (ISR) | prerendered at build time; once the revalidation time has passed, the server regenerates the page in the background (framework feature, e.g. Next.js) | yes, from the cache; the older version is served until regeneration finishes | no specific statement from Google |
| Prerendering | at build time; the client-side app is run and its initial state saved as static HTML | yes (initial state) | Google says server-side or pre-rendering is “still a great idea” because it makes sites faster for users and crawlers |
| Dynamic rendering | a rendering server builds HTML only for detected crawlers; users get the client-side rendered version | only in the version served to crawlers | Google calls it a workaround and not a long-term solution; not cloaking as long as users and crawlers see similar content |
Google names server-side rendering, static rendering and hydration as replacements for dynamic rendering. The older web.dev article “Rendering on the Web” still calls dynamic rendering an option worth considering; this table follows the current Google Search Central documentation. ISR is not a web standard; the description comes from the Next.js documentation. Prerendering has other meanings too; this row uses the web.dev definition. Sources: web.dev: Rendering on the Web; Google Search Central: Understand JavaScript SEO basics (last updated 2026-03-04); Google Search Central: Dynamic rendering as a workaround (last updated 2025-12-10); Next.js Docs: How to implement Incremental Static Regeneration (ISR). Last checked: .
Example
npm run build
# creates e.g. out/index.html, out/blog/post-1.html
The files in out/ go to a web server or CDN. Each URL maps to a finished HTML file.
Common mistakes
- Dynamic routes without known parameters. A Next.js static export does not support dynamic routes without
generateStaticParams(). The framework reports this as an error during development. - Forgetting the server configuration for 404. For a static host such as Nginx, the Next.js documentation shows a configuration with
try_files $uri $uri.html $uri/ =404anderror_page 404 /404.html, so that unknown URLs answer with status 404. - Treating static rendering and prerendering as the same. According to web.dev, statically rendered pages stay interactive without much client-side JavaScript. Prerendering only improves the first paint of a single-page application that still has to boot in the browser. A test with JavaScript disabled shows the difference.
FAQ
What is static site generation? Building HTML pages ahead of time, at build, instead of per request.
Is SSG the same as prerendering? The terms overlap. Some frameworks call build-time HTML creation prerendering.
Sources
- Static site generator (SSG) – MDN Glossarydeveloper.mozilla.org
- Rendering on the Web – web.devweb.dev
- Static exports – Next.js Docs (last updated Aug 9, 2026)nextjs.org
- Dynamic rendering as a workaround – Google Search Central (updated Dec 10, 2025)developers.google.com
Last updated: