What Is a Static Site Generator and How Does It Work?

Updated

A static site generator (SSG) turns your content files and templates into plain HTML files at build time, so the finished site needs no database and no server-side logic to run. Pelican, for example, describes itself as "a static site generator that requires no database or server-side logic." That single design choice explains most of the differences you'll notice against a dynamic CMS like WordPress: faster page loads, a smaller attack surface, and hosting that can be as simple as serving files. The trade-off is that anything requiring per-request computation — user accounts, live comments, personalized pages — has to be added through external services or client-side code.

How a static site generator works

The pipeline is the same in most tools, including Pelican:

  1. You write content in a markup format. Pelican accepts reStructuredText or Markdown.
  2. You define templates that control layout. Pelican themes are built with Jinja2 templates.
  3. The generator runs a build, combining content and templates into finished HTML, plus feeds and other output.
  4. You deploy the output — a folder of static files — to any host that serves files.

Because the work happens once at build time rather than on every visitor request, the runtime is just file delivery. Pelican notes that rebuilds are fast "due to content caching and selective output writing," which matters once a site grows past a few dozen pages.

Static site generator vs. dynamic CMS

Dimension Static site generator (e.g., Pelican) Dynamic CMS (e.g., WordPress)
Runtime requirement No database, no server-side logic Database plus a server-side application
Content storage Files in your project (Markdown/reStructuredText) Database rows, edited through an admin UI
Editing workflow Text editor, version control, rebuild Browser-based admin panel
Hosting Any static file host Hosting that runs the CMS stack
Adding dynamic features External services or client-side code Often built in or available as plugins

The practical question isn't which is "better" but where you want the complexity. If your site is mostly published content that changes on your schedule, a static generator removes an entire layer of infrastructure. If non-technical editors need a browser UI, or you need server-side logic on every request, a CMS is the more direct fit.

Common use cases

  • Blogs and chronological content — Pelican explicitly supports "chronological content (e.g., articles, blog posts) as well as static pages," so a blog plus fixed pages like About or Contact works out of the box.
  • Documentation and project sites — content lives in version control alongside code, and publishing is a build step.
  • Portfolios and small marketing sites — few pages, infrequent updates, and a strong preference for cheap, fast hosting.

What to evaluate when choosing one

  • Markup support — does it accept the format you already write in? Pelican supports both Markdown and reStructuredText.
  • Templating — how much control do you get over layout? Pelican uses Jinja2 themes.
  • Plugins and extensibility — Pelican is "extensible via a rich plugin ecosystem."
  • Build speed — relevant for large sites; caching and selective output writing keep rebuilds quick.
  • Feeds and metadata — Pelican generates Atom and RSS feeds and supports publishing articles in multiple languages.
  • Migration path — Pelican can import existing content from WordPress, Dotclear, or RSS feeds, which lowers the cost of switching.
  • Syntax highlighting — handled via Pygments in Pelican's case.

Trying Pelican: a minimal walkthrough

Pelican's own quickstart gives a concrete path from nothing to a running preview.

Prerequisites: Python and pip installed.

1. Install Pelican and Markdown:

python -m pip install "pelican[markdown]"

2. Create a project skeleton:

mkdir -p ~/projects/yoursite
cd ~/projects/yoursite
pelican-quickstart

When prompted for your URL prefix, enter your domain (for example, https://example.com).

3. Create an article at ~/projects/yoursite/content/keyboard-review.md:

Title: My First Review
Date: 2010-12-03 10:20
Category: Review

Following is a review of my favorite mechanical keyboard.

4. Preview locally:

pelican -r -l

Then open http://localhost:8000/ in your browser. The -r flag rebuilds on content changes and -l serves the local preview.

Expected result: your article appears at the site root, rendered through the default theme, with the metadata (title, date, category) applied.

Common sticking points:

  • The Markdown extra must be installed, or .md files won't be processed — hence the pelican[markdown] install rather than plain pelican.
  • The metadata block at the top of the file is required; without a title and date, the article may not render as expected.
  • If the preview shows a stale page, confirm the -r flag is active so rebuilds happen automatically.

Bottom line

Choose a static site generator when your content is file-based, your publishing cadence is your own, and you'd rather not operate a database-backed application. Pelican is a reasonable starting point if you already work in Python: it takes Markdown or reStructuredText, themes in Jinja2, generates feeds, imports from WordPress or RSS, and runs with a two-command install and preview. If your site needs per-request logic or a browser-based editor for non-technical contributors, plan for external services or reconsider a dynamic CMS.