Static content generators: what they build, which one to pick, and the indexing checklist

A static content generator, more commonly called a static site generator, is a tool that takes your content and templates and builds plain HTML files once, at build time, so the server can hand a finished page straight to the visitor with no database query and no application code running per request. You write in Markdown or pull content from an API, run a build, and get a folder of HTML, CSS, images and JavaScript that any host can serve. The result is fast, cheap to host, hard to break, and easy for search engines and AI crawlers to read, because the words are already in the HTML rather than being assembled in the browser afterwards.

This page covers what these tools do, how static output compares with server rendering and browser rendering, the main generators and what each one suits, and the technical checklist that keeps a statically generated site fully indexable.

What the build step actually does

• Content comes in. Markdown files in a repository, or data fetched from a headless content system, a spreadsheet, a product feed or a database.
• Templates are applied. Layouts and components turn each content item into a full page.
• Files come out. One HTML file per URL, plus compiled CSS and JavaScript, plus a sitemap and feeds if you configure them.
• The output is deployed. Usually to a content delivery network, so the file is served from a location near the visitor.

The important consequence is that the page a crawler receives is the finished page. Nothing has to execute for the content to exist.

Static, server rendered and browser rendered, compared

Approach	When the HTML is built	Strengths	Best fit
Static generation	Once, at build time	Fastest delivery, cheapest hosting, smallest attack surface, content present in the first response	Marketing sites, documentation, blogs, catalogues that change on a schedule
Server side rendering	On each request, on the server	Always current, personalised, content still present in the first response	Dashboards, logged in areas, stock and price sensitive pages
Browser rendering	In the visitor's browser, after JavaScript runs	Rich interaction after the first load	Application interfaces behind a login
Incremental or on demand static	At build time, then regenerated per page when data changes	Static speed with fresher data and no full rebuild	Large catalogues and sites with frequent small updates

Google's own guidance on JavaScript SEO basics, checked on 10 October 2026, explains that its crawler processes JavaScript in a separate rendering step. Static output removes that step from the equation entirely, which is why it is the most predictable choice for pages whose job is to be found.

The main generators, and what each one suits

Tool	Built with	Suits
Jekyll	Ruby	Simple blogs and documentation, and anything published through GitHub Pages, where it is the long established default
Hugo	Go	Large content sites where build speed matters. Its own documentation leads on speed, and a single binary install keeps the setup simple
Eleventy	JavaScript	Teams that want minimal shipped JavaScript and freedom over templating languages
Astro	JavaScript	Content sites that need occasional interactive components, using an islands approach that ships JavaScript only where a component needs it
Next.js	React	Sites that mix statically generated marketing pages with an application, including static export and per page regeneration
Gatsby	React	React sites that pull content from several sources through a single data layer

Each project's own documentation is the right place to confirm current versions and features, and all six links above were checked on 10 October 2026. Tool choice matters far less than the content model behind it: a clean set of content types with consistent fields will outlive whichever generator you pick.

Choosing one: five questions that settle it

• What language does your team already maintain? The generator you can debug on a Friday afternoon beats the faster one you cannot.
• How many pages, and how often do they change? Tens of thousands of pages rebuilt hourly is a build performance question. Two hundred pages updated weekly is not.
• Who edits the content? Developers can work in Markdown in a repository. Non technical editors need a headless content system with a preview, which the generator must be able to read from.
• Do you need interactivity, and where? A search box, a configurator or a booking widget can sit as an island on an otherwise static page, or run as a separate service called from the page.
• What does the hosting look like? Static output runs on any content delivery network. Per page regeneration and server rendering need a host that supports them.

The parts people assume you lose, and how they are handled

• Forms. Posted to a hosted form service, a serverless function or your own API. The page stays static; the submission goes elsewhere.
• Search. A prebuilt index shipped with the site for small sites, or a hosted search service for large ones.
• Comments and reviews. Loaded from a third party service after the page renders, so the core content is still in the HTML.
• Prices and stock. Either regenerate the affected pages when the data changes, or render the page statically and fetch the live value for the one element that must be current.
• Editor previews. Build a preview deployment per change. Most hosts do this automatically on a pull request, which also gives reviewers a real URL.

The checklist that keeps a static site fully indexable

• One canonical URL per page, generated consistently, with a decision made once about trailing slashes and applied everywhere.
• A generated sitemap, written at build time so it can never drift from the pages that exist, and referenced from robots.txt.
• Real publication and modification dates, taken from the content rather than from the build timestamp, so every page does not claim to have changed on every deploy.
• Structured data generated from the same fields as the visible page, so the markup and the text can never disagree. Our guide to schema markup covers the types worth adding first.
• Redirects held in configuration, version controlled, and tested after each build. Static sites lose old URLs silently when a slug changes, so make slug changes generate a redirect automatically.
• Pagination and archive pages that are crawlable links, not buttons that load content with JavaScript.
• A build time link check, failing the build on internal links that point nowhere. This is one of the biggest practical advantages of a build step and most teams never switch it on.
• A publish time ping. Tell engines about new and changed URLs as part of the deploy, which is covered in our guide to indexing a site on Bing.

A note on the other meaning of the phrase

Some people arrive at this phrase looking for a tool that writes content automatically rather than one that builds pages. Those are different products: a static site generator assembles pages from content you supply, and a text generation tool drafts the content itself. The two are often used together, with the drafting tool producing Markdown that the generator then builds, reviewed by a person before it is committed.

This page covers static site generators and the technical practices around them. For how structured data is validated after a build, see our guide on what schema markup changes.

The static content generators questions worth an answer

What is a static site generator in one sentence?

A tool that turns content and templates into plain HTML files during a build, so the server only has to hand over finished files.

Are static sites better for SEO?

They remove a whole class of problems: the content is in the first response, pages load quickly, and the sitemap and markup are generated from the same source as the page. Ranking still depends on the content and the links, and static generation makes sure nothing technical stands in the way of either.

Can a static site handle thousands of pages?

Yes. Build time becomes the constraint rather than serving capacity, which is why fast generators and per page regeneration exist. Sites with hundreds of thousands of pages run this way.

Is WordPress a static site generator?

No. WordPress builds pages per request from a database, although plugins and hosts can export or cache a static copy and serve that. If you want the static benefits while keeping the WordPress editor, that export route is the usual approach.

Do I need a developer to run one?

To set one up and deploy it, yes in most cases. To edit content afterwards, no, provided you connect a content system with an editing interface and a preview at the start rather than as an afterthought.

How do I handle content that changes hourly?

Use per page regeneration for the pages that change, keep the rest fully static, and fetch genuinely live values such as stock counts in the browser for that single element.

Generated pages meet a reader that does not run your build

The indexing checklist ensures that crawlers can reach the HTML your generator wrote. The last reader in the chain is an assistant that has taken the text and now answers questions with it.

Whether your generated pages are used is a thing you can look up. Ask the question each page answers, and read the reply for your name or your wording. AI Knows Us sends it to ChatGPT, Gemini, Perplexity and Claude, and reports which sites are cited.