A static site generator is a tool that builds every page of a website in advance, turning content files and templates into plain HTML files that can be served to visitors instantly. Nothing is assembled when someone visits; the pages already exist.
How a static site generator works
A traditional CMS such as WordPress builds each page on request: a visitor arrives, the server runs code, queries a database, stitches the result into a template and sends it back. Caching softens that work, but the machinery is always running.
A static site generator moves the work to build time. Content is written as Markdown files or pulled from a headless CMS, templates define the layout, and a build command produces a folder of finished HTML, CSS and image files. Common generators include Hugo, Eleventy, Jekyll and Astro, and frameworks such as Next.js can export static pages too.
That folder is uploaded to a host or straight to a content delivery network, which stores copies close to visitors. Changes usually go through version control: an edit is committed, the site rebuilds automatically, and the new files go live in a minute or two. Anything interactive, such as contact forms, search or bookings, is handled by separate services or small pieces of JavaScript.
Why it matters
The advantages are real. Pre-built pages load very quickly because the server has almost nothing to do, which helps Core Web Vitals. There is no database or login page exposed to the internet, so the attack surface is tiny and there are no plugin updates to chase. Hosting on a CDN is cheap and copes easily with sudden traffic, such as a mention on national radio.
The trade-offs land on the people who run the site. Editing usually means working with files and a code repository unless someone adds a headless CMS. Features that WordPress plugins provide in a click, like redirects, XML sitemaps, schema markup and editable meta titles, have to be built into the templates deliberately. For a marketing team that publishes several times a week without a developer, that can be a real obstacle.
A static site suits a technical consultancy, a SaaS company’s documentation or a small professional firm in Edinburgh with a developer on hand. It is a weaker fit for a business whose staff need to edit pages daily or run a large shop.
Common mistakes
- Forgetting SEO basics in the templates. Unique titles, meta descriptions, canonical tags and a sitemap are not automatic in every generator.
- No redirect plan when moving from a CMS. URLs often change format, such as dropping or adding trailing slashes, and every old address needs a redirect rule at the host.
- Relying on client-side rendering. Some setups ship a nearly empty HTML page and build content in the browser. That undoes the main advantage and raises JavaScript SEO problems.
- Leaving editors stranded. If only one developer can publish a change, the site will go stale.
- Ignoring forms and consent. Third-party form handlers still process personal data, so they belong in your privacy notice under UK GDPR.
How to act on it
If someone proposes a static site, ask who will edit content, how they will do it and how long a change takes to appear. Ask how redirects, sitemaps, meta titles and structured data are handled, and view the page source of a sample page to confirm the content is present in the HTML rather than loaded later by scripts.
If you already run one, crawl it as you would any site and check Search Console for indexing gaps. Choosing a platform that your team can actually run is one of the first decisions I work through in a website redesign, because the fastest site in the world does little good if nobody can update it.