This post is based on a talk I gave at the WordPress Meetup. Some of the parts of this article reference demo websites which were hosted on my computer for the presentation and aren’t linked here. While the demo sites may not be available to see, the tools used to make them are linked here, and each have plenty of demo sites.

---

How WordPress Serves a Page

When someone visits your WordPress site, a lot happens behind the scenes. The browser hits your web server, which hands the request to PHP, which queries the MySQL database, gets the content back, assembles the HTML, and sends it to the browser. This happens for every visitor, every page, every time. Even if the content hasn’t changed in six months.

Browser → Web Server → PHP → Database → PHP → HTML → Browser

That’s a dynamic site. The page is built on every request.

How a Static Site Works

A static site flips this completely. The HTML files are already built. They’re just sitting there, ready to go. When someone visits, a CDN server near them geographically hands them the file. No PHP, no database, no computation.

Browser → CDN → HTML → Browser

Think of it as the difference between a restaurant cooking your meal to order versus handing you a pre-packed lunch.

What Is a Static Site Generator?

A static site generator (SSG) is the tool that does the building. You write your content (usually in Markdown files, sometimes through a CMS) and the generator takes that content, applies a template, and produces plain HTML files. You upload those files to a host, and you’re done.

Content → Build → HTML/CSS/JS → CDN

That’s the whole workflow. Every static site generator we’ll look at follows this same pattern.

Why Go Static?

Speed. Your site is just files on a CDN edge node near the visitor. No computation per request.

Security. This is the big one for WordPress people. No PHP means no plugin vulnerabilities, no brute force attacks on wp-login, no XML-RPC exploits. There’s almost nothing to hack.

Cost. Cloudflare Pages, GitHub Pages, and Netlify all have generous free tiers that handle most sites easily.

Simplicity. No server to manage, no PHP version upgrades, no database optimization.

What Do You Give Up?

Dynamic features. Every dynamic thing you take for granted in WordPress (search, forms, comments, e-commerce) doesn’t exist out of the box. You have to bolt these on with third-party services or clever workarounds.

Editing UX. There’s no wp-admin by default, though CMS tools like Decap CMS help a lot.

Build step. Changes aren’t instant like hitting “Publish” in WordPress. You make a change, and it takes anywhere from 10 seconds to a couple minutes to go live.

We’ll talk about solutions to all of these.

Who Is This For?

Static sites are great for content that doesn’t change per-visitor: blogs, portfolios, documentation, marketing pages, small business brochure sites.

They’re a tough fit for membership sites, full e-commerce, or complex web apps.

And here’s the interesting part: you can use WordPress as your authoring tool and publish a static site. Best of both worlds. That’s actually our first demo.

A Quick Markdown Primer

Every static site generator we’re looking at (except WordPress) uses Markdown as its content format. Markdown is a plain text format that converts to HTML. If you’ve ever formatted a message in Slack or Discord, you’ve basically used Markdown.

# Hello World

This is **bold** and this is *italic*.

Here's a [link](https://example.com) and an image:

![Alt text](photo.jpg)

- Item one
- Item two
- Item three

The one thing unique to static site generators is front matter: a YAML block at the top of your Markdown file that sets metadata like the title, date, and tags. Think of it like the settings you fill in on the right sidebar when you’re editing a WordPress post, except it’s just text in the file.

---
title: "My First Post"
date: 2026-02-15
tags: ["static", "wordpress", "meetup"]
draft: false
---

Your Markdown content starts here...

The Landscape

Here’s a quick overview of the four generators we’re covering:

Generator	Language	Vibe
Hugo	Go	Fastest builds. Great for blogs & docs.
Jekyll	Ruby	The OG. Powers GitHub Pages natively.
11ty (Eleventy)	JavaScript	Flexible, minimal, developer-friendly.
WP + Simply Static	PHP	Use the CMS you know, output static files.

There are plenty of others out there (Gatsby, Next.js, Astro, Zola), but these four cover the range well and each has a live demo site you can go poke around.

WordPress + Simply Static

This one starts with what you already know if you’re familiar with WordPress, because it is a regular WordPress install. You’d recognize it: wp-admin, posts, pages, plugins, the works. The difference is we only use this version of the site for writing content. We can lock it down to only certain IPs or even just host it locally on a computer not on the internet.

But the production site (what visitors actually see) is at a public URL, which is just flat HTML files on Cloudflare Pages. Simply Static Pro takes the WordPress output and exports it as static files, then pushes them to GitHub, which triggers a deploy on Cloudflare Pages.

The key idea: WordPress is your authoring environment. The static site is production.

Right-click and View Source on the static site and you’ll see plain HTML. No PHP, no database calls, nothing dynamic happening server-side.

Simply Static Pro Features

Simply Static Pro has built-in toggles for the dynamic features you’d normally get from WordPress:

• Search uses something like Fuse.js, which builds a search index at export time and ships it as a JSON file. JavaScript searches it right in the browser.
• Forms submit to a third-party service instead of your server.
• Comments get stored somewhere else entirely (more on this in a minute).

Every dynamic thing you take for granted in WordPress has to be solved differently on a static site. The rest of this post is about how.

Comments with Utterances

One of my favorite solutions for static site comments is Utterances. It turns GitHub Issues into a comment system. You add one script tag to your site, approve the GitHub app, and you’re done. When someone leaves a comment, it creates a GitHub Issue.

<script src="https://utteranc.es/client.js"
        repo="your/repo"
        issue-term="pathname"
        theme="github-light"
        crossorigin="anonymous"
        async>
</script>

Free, open source, no database, no account system to manage. I have this running live on the Jekyll demo site.

Demo 2: 11ty + Decap CMS

This one swaps out WordPress entirely. This demo is built with 11ty (the static site generator) and Decap CMS (which gives you a friendly content editor that looks a lot like WordPress).

Under the hood, when you save a post in Decap, it creates a git commit on GitHub. Cloudflare Pages detects the commit, runs 11ty to rebuild the HTML, and deploys it. Same workflow as Simply Static, different tools.

The Markdown files live right in the GitHub repo. That’s what your content actually looks like: Markdown files in a folder. Decap CMS just gives you a nice interface for editing them.

Demo 3: Hugo

This next demo is built with Hugo using the PaperMod theme (the most popular Hugo theme, with over 13,000 stars on GitHub). Same pattern: Markdown files in a GitHub repo, push a change, Cloudflare Pages rebuilds and deploys.

Hugo is famous for build speed. Thousands of pages in under a second. For a blog, the build is basically instant.

Headers and Redirects Without a Server

On a traditional server you’d configure headers in Apache or Nginx. On a static site, you just drop a _headers file in your repo:

/*
  X-Frame-Options: DENY
  X-Content-Type-Options: nosniff
  Cache-Control: public, max-age=3600

Same with redirects:

/old-page    /new-page    301
/wp-admin    https://youtu.be/dQw4w9WgXcQ    302

The hosting platform reads these at deploy time. Flat files, no server config needed. (And yes, that wp-admin redirect is real.)

Demo 4: Jekyll + GitHub Pages

Jekyll on GitHub Pages is the simplest setup of everything covered here. You push Markdown to a GitHub repo, and GitHub builds and hosts the site automatically. No Cloudflare Pages, no build config, nothing extra.

This is also the site where Utterances is running live. Comments appear as GitHub Issues. The lowest-friction static site setup that exists, and you still get comments without a database.

Deployment and Hosting

You’ve seen these platforms throughout the demos, so here’s a quick summary:

• Cloudflare Pages hosted three of the four demo sites. Free tier, global CDN, custom domains with free SSL.
• GitHub Pages hosted the Jekyll site with zero configuration. Free for public repos with native Jekyll support.
• Netlify is a strong alternative to Cloudflare Pages with a similar workflow. Its built-in form handling is a nice perk since forms are one of the things static sites struggle with.
• Vercel is more oriented toward Next.js and React but supports static deploys too.

The pattern is the same everywhere: git push → platform builds → deploy to CDN.

Dynamic Problems, Static Solutions

The big question from WordPress users is always “but what about ___?” Here’s the rundown:

Search. Client-side search with tools like Fuse.js, Lunr.js, or Pagefind. The search index is generated at build time and shipped as a JSON file. JavaScript searches it in the browser.

Forms. Formspree, Netlify Forms, Google Forms embeds, or Cloudflare Workers for custom handling. The form submits to a third-party service instead of your own server.

Comments. Utterances (GitHub Issues), Giscus (GitHub Discussions), or Disqus. Comments get stored on someone else’s infrastructure instead of your WordPress database.

E-commerce. Snipcart, Shopify Buy Button, Stripe Payment Links. If you need a full store, static probably isn’t the right tool. But for a few buy buttons on an otherwise content-focused site, it works fine.

The honest take: if you need most of these things working together on one site, WordPress is probably still the better choice. Static sites shine when your content is mostly… content.

When to Go Static

Go static when you have a content-focused site: blogs, portfolios, docs, marketing pages. Security is a priority. Budget is tight.

Stick with WordPress when you need memberships, e-commerce, complex forms, real-time features, or your editors need wp-admin and aren’t going to learn Markdown.

Use both when WordPress + Simply Static makes sense for you. Author in the CMS you know, publish as static files.

Static sites are another tool in the toolbox. WordPress is amazing for what it does. Static sites are amazing for what they do. Sometimes the answer is both, which is exactly what Simply Static gives you.

Resources

• Hugo — gohugo.io
• Jekyll — jekyllrb.com
• 11ty — 11ty.dev
• Simply Static — simplystatic.com
• Decap CMS — decapcms.org
• Utterances — utteranc.es
• Cloudflare Pages — pages.cloudflare.com
• GitHub Pages — pages.github.com

If you want to try one, I’d say start with Jekyll on GitHub Pages. You can have a site live in 10 minutes.