Generating page HTML ahead of requests, commonly during a build process.
Static site generation creates page HTML before visitors request it, commonly during a build process. The generated output can then be reused for many requests rather than assembling the same page from scratch each time.
This approach can suit content whose published version does not need to change for every visitor. It does not mean the site can never be updated or contain interactive features. It means the workflow needs a way to generate and publish new output when the underlying content changes.
The distinction matters for content operations. Saving a change in a source system may not update the public page until the relevant build or regeneration step completes. Check the live output rather than assume that an updated source record proves the site now shows the new information.
Takeaway: Make the publication path clear on a statically generated site. Know which action rebuilds or regenerates affected pages and how someone verifies that the new version is actually live.
Example
A consultancy changes a service description in its content system, but the public page still shows yesterday’s generated HTML because the publishing build has not completed. The editor should check the build and deployment result before making repeated copy changes or claiming that search engines are seeing the new version.
What to check
Test a representative content update through the full workflow. Confirm the public page, metadata and links after generation, and understand how errors are reported. SSG can deliver complete HTML, but outdated or inaccurate generated content remains outdated or inaccurate; the strategy does not guarantee search performance.
For more detail, see Next.js static site generation.