If the only website tooling you've used is something like WordPress, Wix, or Squarespace — log in, click into an editor, hit publish — the idea of a "static site generator" can sound like a step backward. No login screen, no dashboard, no database. This site runs on one (Zola), and the tradeoffs are real in both directions, so here's the honest version rather than the sales pitch.
What a static site generator actually does
WordPress and similar tools work by storing your content in a database and building each page on the fly, every time someone visits, by combining that data with a template. That's powerful, but it also means there's a running application (a web server, a database, a plugin ecosystem) that has to be kept online, updated, and secured indefinitely.
A static site generator does the opposite: it builds every page once, ahead of time, into plain HTML/CSS/JS files, and then those files just sit there, served exactly as-is. There's no database to query per visit, no server-side application running your templates live. Writing a post means writing a text file; publishing means running a build command that turns your text files into a folder of static pages.
The real tradeoffs
What you give up:
- No web-based editor. You write in a plain text file (usually Markdown), not a browser dashboard. If you want a "log in anywhere and type" experience, this isn't it out of the box.
- No plugin ecosystem. Want a contact form, a comment system, a shopping cart? WordPress has a plugin for that, often installable in two clicks. A static site generator gives you none of that by default — you either find a static-friendly equivalent (many comment/analytics/search tools now offer this) or build it yourself.
- No live database means no live anything server-side. Anything that genuinely needs to happen at request time — user accounts, real-time data, personalized content — isn't a static site's job. You'd bolt on a separate service for that specifically, not ask the site generator to do it.
What you get instead:
- Nothing to hack. There's no database to inject into, no admin login to brute-force, no outdated plugin with a known vulnerability. The attack surface of "a folder of HTML files" is about as close to zero as a website gets.
- Nothing to keep updated. No WordPress core updates, no plugin compatibility breakage, no "your PHP version is no longer supported" emails.
- Version control for free. Since your content is plain text files, your entire site's history — every edit, every post, ever — is just... git history. You get real, meaningful diffs of what changed in a post, for free, using tools that already exist.
- It's fast, unconditionally. Serving a pre-built file is about as fast as serving a web page gets. There's no database query to optimize, because there isn't one.
Who this is actually for
If you want to hand editing access to five non-technical people who'll never touch a terminal, a static site generator is the wrong tool — that's WordPress's home turf, and it's good at it. But if you're comfortable writing in plain text (or willing to get comfortable), and what you actually want is something that publishes fast, costs nothing to host reliably (GitHub Pages, for one, serves static sites free), and doesn't need ongoing maintenance to stay secure, "just files plus git" is a legitimate, unglamorous, genuinely lower-effort way to run a site long-term.