Glossary Static site generation (SSG)
With static site generation the HTML for each page is produced once, when the project is built, and stored as a file. When someone requests it the server just hands over that file: nothing is computed at request time.
The fastest and most robust thing you can serve, with one condition: the content only changes when something rebuilds.
At build time a program walks the content — files, a CMS, a database — and writes a finished HTML file for every address. What comes out is a folder full of files.
Those files need no application server. They can sit on a plain web server or straight in a CDN, distributed geographically, close to the visitors.
The crawler gets the complete content in the first response. There is no render queue, no JavaScript that can fail, and no data request that comes up empty at the wrong moment.
Response time helps too. A finished file from a CDN arrives in a few milliseconds — which helps LCP and makes crawling cheaper, because every fetch costs less.
What has been built stays that way until something rebuilds. If a price, a stock level or an opening time changes, the page does not see it — until a build runs.
With a few hundred pages that is irrelevant; a build takes seconds. With tens of thousands it becomes an arithmetic problem: a full build can take minutes to hours, and that for a change to a single page.
There are two answers. Incremental builds refresh only what changed. Revalidation after the fact serves the old version and rebuilds the affected page in the background — the next request gets the fresh one.
For search engines the two are equivalent — the content is in the first response. The choice comes down to two other questions.
How often does the content change? A glossary entry rarely, a stock level constantly. Does the page depend on the viewer? Country-specific prices, a basket, a signed-in state — a file cannot express that.
A reference work, a blog, documentation are the clear SSG cases. A shopping basket is the clear SSR case. In between you mix, page by page.
Three situations argue against it. Very many pages with frequent changes — build time becomes the bottleneck, and without incremental builds every correction waits for the next full run.
Content that differs per person cannot be produced in advance. Very short update cycles, live pricing for instance, need a different route.
Here too: not a decision for the whole project. The catalogue can be static and the basket server-rendered, within the same application.
A technical audit covers this and everything else in one pass.
Request an auditFor the crawler they are equivalent: in both the content is in the first response. SSG's advantage is speed and robustness, not indexing. Choosing between them is a decision about freshness and cost, not about SEO.
For part of one, yes. Product pages, categories and editorial content suit it well; the basket, live pricing and a signed-in state do not. A mixed site is the usual outcome, and that mix is the norm rather than an exception.
The practical limit is not the page count but the build time. Thousands are no problem; from tens of thousands it is worth checking whether the tool builds incrementally, because otherwise every small change drags a full run with it.
In the result, little: both have finished HTML ready before the request. The difference is in purpose. SSG is how the whole site is built; prerendering is usually an addition to an application that otherwise renders in the browser.
Yes. The HTML arrives finished and JavaScript adds what is needed afterwards — a search, a filter, a form. What matters for the crawler is only that the content does not depend on that code running.