Static site generation renders pages to HTML during a build step, before anyone requests them. The resulting files are served directly from a server or CDN. Because the HTML already contains the full content, links and metadata, static pages are fast to deliver and easy for any crawler to read, which makes the approach a common choice for marketing sites, blogs and documentation.
How it works
A static site generator reads content from Markdown files, a headless CMS or an API, runs it through templates, and writes one HTML file per URL. Frameworks such as Next.js, Astro, Hugo, Eleventy and Docusaurus all support it. When content changes, the site, or the affected pages, are rebuilt and redeployed.
Some frameworks add incremental or on-demand regeneration, which rebuilds individual pages after deploy without a full rebuild. The page is still served as static HTML; only the timing of the build changes.
SEO benefits
The first HTML response holds everything a crawler needs, so there is no rendering step to wait for or fail. Pages served from a CDN usually have a low Time to First Byte. Titles, canonicals, hreflang and structured data are baked into the file, which removes the risk of JavaScript changing them later.
- Readable by crawlers that do not run JavaScript
- Fast responses from edge caches
- Fewer moving parts at request time, so fewer runtime errors
Limits and trade-offs
Build times grow with page count, which matters for large programmatic sites. Content that must be fresh on every request, such as live pricing per region or user-specific data, needs server rendering or client-side fetching on top. Teams also need a reliable rebuild trigger, or published CMS edits will not appear until the next deploy.
Example
Splitting a site by rendering mode
Tidewell, a scheduling SaaS, generates its blog, docs and integration pages statically at build time, renders its pricing page on the server so it can show regional currency, and keeps the logged-in app client-side. Each part of the site uses the mode that fits its content, and every public page ships complete HTML.
Common mistakes
Forgetting to rebuild after CMS edits
Without a webhook or scheduled rebuild, fixes to titles or content sit unpublished. Check that a CMS publish actually triggers a deploy.
Generating pages that should not exist
It is easy to build thousands of thin pages from a dataset. Every generated URL should earn its place in the index.
Questions
Both deliver complete HTML, which is what matters for crawling. SSG is usually faster and simpler to cache; SSR suits content that changes per request. Choose based on how fresh each page type needs to be.
