Quick answer: A static site generator takes your content (usually Markdown files) and templates, and builds a folder of plain HTML, CSS and JavaScript files before anyone visits. There is no database and no code running on each page view, so the site is fast, cheap to host and has very little to attack. Static sites suit brochure sites, documentation, blogs and landing pages that change a few times a week. A CMS such as WordPress is still the better choice when non technical staff edit content daily, or when you need logins, shopping carts or other features that depend on the visitor.
Most business websites today run on a content management system. Every time someone loads a page, the server runs code, queries a database and assembles the HTML. Caching softens the cost, but the moving parts are still there. Static site generators take a different approach, and for the right kind of site they are hard to beat.
How a static site generator works
The process has three parts:
- Content lives in text files, usually written in Markdown, with a small block of settings at the top for the title, date and other details.
- Templates define the layout: header, footer, page structure and how lists of posts are shown.
- A build step runs the generator, which merges content into templates and writes out a complete website as files.
You then upload those files to any web server or file host. When a visitor asks for a page, the server simply sends the file. Nothing is calculated on the fly.
When you change something, you rebuild and upload again. With a good setup, that happens automatically when you save changes to a Git repository.
The main generators
There are hundreds of static site generators. A few are widely used and well supported:
- Jekyll is written in Ruby and is the best known. It powers GitHub Pages, which means you can host a Jekyll site for free straight from a GitHub repository.
- Hugo is written in Go and is known for very fast builds, even on sites with thousands of pages. It ships as a single file, so there is little to install.
- Middleman is another Ruby option, popular with front end developers who want more control over asset handling.
- Hexo is built on Node.js and aimed mainly at blogs.
The choice usually comes down to which language your developers are comfortable with and how large the site will grow.
Where static sites win
Speed
Serving a ready made file is about as fast as a web server gets. There is no PHP to run and no database to query. Put the files behind a content delivery network and pages load quickly for visitors anywhere. Speed helps both visitors and search rankings, as we cover in our WordPress speed guide.
Security
Most attacks on CMS sites target the admin login, outdated plugins or database injection. A static site has none of these. There is no login page on the live server and no database to break into. The attack surface shrinks to the web server itself. Compare that with the steps needed to keep a CMS safe, which we cover in our WordPress security guide.
Hosting cost and reliability
Static files can be hosted almost anywhere, often for little or nothing. GitHub Pages is free for public repositories. Amazon S3 with a CDN costs very little for most small sites. Newer services such as Netlify, which launched last year, build and host the site automatically whenever you push changes. Because there is no server side code, traffic spikes rarely bring a static site down.
Version control
Every change to content and templates lives in Git. You can see who changed what, roll back mistakes and review edits before they go live. For teams that already work this way, it feels natural.
Fewer updates
There are no core, theme or plugin updates to apply every few weeks. The generator itself needs occasional updates, but they do not affect the live site until you rebuild.
Where a CMS is still the better choice
Static sites have real limits, and it is worth being honest about them.
Editing is harder for non technical staff
Writing in Markdown and committing to Git is fine for developers. For a marketing team used to a visual editor, it is a big step back. Hosted editors and tools like Prose.io help, but they are not as friendly as a WordPress dashboard.
Anything dynamic needs a workaround
Static means the same page for everyone. Features that depend on the visitor need extra services:
- Forms go to a third party form handler or a small script on another server.
- Comments come from an embedded service such as Disqus.
- Search uses a JavaScript index built at build time, or an external search service.
- Ecommerce usually means an embedded cart from a hosted provider.
Each of these is another account, another script and sometimes another monthly fee.
Large sites and frequent updates
If you publish dozens of pieces a day, or have tens of thousands of pages, build times and workflow can become a problem. Hugo handles large sites well, but a newsroom is still better served by a CMS.
Scheduling and previews
A CMS lets you schedule a post for next Tuesday or preview a draft with one click. Static setups can do both, but they need extra configuration, such as a scheduled build.
A simple way to decide
A static site generator is a good fit when most of these are true:
- The site is mostly brochure pages, documentation, a blog or campaign landing pages.
- Content changes a few times a week rather than many times a day.
- The people editing are comfortable with text files, or a developer handles changes.
- Speed, security and low hosting costs matter more than editing convenience.
- You do not need user accounts, memberships or a full shop.
A CMS is the better fit when:
- Several non technical people edit content often.
- You need features such as memberships, bookings, a shop or user generated content.
- You rely on plugins for functionality you do not want to build yourself.
If you are weighing up costs more generally, our article on website development cost explains what drives the price of each approach.
A middle path: using a CMS to feed a static site
Some teams want the editing comfort of a CMS and the speed of static files. There are a few ways to get close:
- Full page caching on WordPress serves pre built HTML to most visitors, which delivers much of the speed benefit.
- Static export plugins crawl a WordPress site and save every page as a file for upload elsewhere. The CMS sits on a private server and the public only sees the static copy.
- API driven builds pull content from a CMS through an API at build time and pass it to the generator. This is more work to set up but keeps editing friendly.
Each adds complexity, so it only makes sense when the benefits are clear.
Moving an existing site to static
If you decide to switch, plan it like any migration:
- Export your content. Jekyll and Hugo both have importers for WordPress and other platforms.
- Rebuild templates to match your design.
- Keep the same URLs wherever possible, and set up 301 redirects for any that change.
- Replace dynamic features such as forms and comments.
- Test thoroughly before switching DNS.
FAQ
Are static sites bad for SEO?
No. Search engines see plain HTML, which is easy to crawl. You still need titles, meta descriptions, a sitemap and good content, which most generators support through templates or plugins.
Can a static site have a blog?
Yes. Blogging was one of the first uses for Jekyll, and every major generator supports posts, categories and feeds.
Do I need to know how to code?
To set one up, some technical knowledge helps. Once it is running, writing content in Markdown is quite easy to learn.
Choosing the right build for your site
There is no single right platform. The best choice depends on who edits the site, what it needs to do and how much you want to spend keeping it running. We build both static and CMS sites and can help you pick the one that suits your business. See how we help companies turn visitors into customers with sites built for their real needs.
