I think WordPress is a good piece of software. But for most of the small marketing sites I see, it has become more machinery than the job needs. A static site, edited with modern tools and a bit of AI help, is usually simpler to build, cheaper to run and calmer to look after.

This guide sets out how the two compare for a team: who edits what, what breaks, what it costs and what you give up. It tries to be fair to both, because the right answer depends on the site.

Who this guide is for

This is written for small agency teams, in-house marketing teams and designers who build or adjust templates themselves, often with an AI assistant. You know what a website is and roughly what git does. You do not need to be a developer to follow it.

If you run a large publication, a membership site or an online shop with thousands of products, some of this still applies, but your needs are different. The section on when WordPress is still the right choice covers that.

How each one works

WordPress is a dynamic system. When someone visits a page, a server runs PHP code, asks a database for the content, assembles the page and sends it back. Themes control how pages look, plugins add features, and an admin area at /wp-admin is where people log in to edit. Caching layers are usually added on top so the server does not rebuild every page on every visit.

A static site is built ahead of time. A static site generator such as Jekyll, Hugo or Astro takes your templates and content files (usually Markdown and YAML) and turns them into plain HTML, CSS and images. Those files are uploaded to a host, which hands them to visitors as they are. There is no database and no code running per visit. The source files live in a git repository, so every change is recorded.

The difference matters less for what visitors see and more for everything around it: how you edit, what can go wrong and what you have to maintain.

Editing experience for non-technical teams

This is where WordPress has long had the advantage, and it is worth saying plainly. A marketing coordinator can log in, click “Add New”, write a post, upload an image and publish. Nobody has to teach them git.

A plain static site has no such screen. Out of the box, editing means changing files in a repository, which is fine for developers and a barrier for almost everyone else. If nobody solves this, every typo fix becomes a ticket for the developer. That is the most common reason teams give up on static sites, and it is a real cost.

It is also a solvable one. A CMS can sit on top of a static site and give editors a familiar screen with a title, a body, images and a publish button. Git-based CMS tools save each change as a commit in your repository. Headless API CMS tools store content in their own database and feed it to the build. The complete guide to adding a CMS to a static site walks through both.

There is another side to editing that favours static sites: changing the design. On WordPress, layout changes often mean working inside a theme’s options panel or a page builder, where the real structure of the page is hidden behind drag-and-drop widgets and stored as opaque data in the database. On a static site, the templates are ordinary HTML files with a little templating language. A developer, or a designer working with an AI coding assistant, can open the file, describe the change and see exactly what changed. The article on static sites in the agentic age goes into this further.

Speed and performance

A static site serves files that are already built. There is no database query or PHP to run, so pages are fast by default, and they can be served from a content delivery network close to each visitor.

WordPress can be fast too. With good hosting, a lean theme and a caching plugin or server-level cache, a WordPress site can perform well. The difference is that speed on WordPress is something you have to maintain, while on a static site it is the starting point. Heavy themes and page builders tend to add a lot of extra CSS and JavaScript, which undoes much of that work.

Security

WordPress itself has a good security team, and core updates are handled responsibly. Most problems come from around it: plugins and themes with vulnerabilities, outdated installs, weak admin passwords, and a login page at a well-known address that bots try all day.

A static site removes most of that surface. There is no plugin code running on the server, no database to inject into and no public admin login on the site itself. What remains to protect is your git hosting account, your CMS sign-ins, your form handling and your DNS. Git history also gives you a full audit trail of who changed what, and rolling back a bad change is a matter of reverting a commit and rebuilding.

See static site security for a fuller checklist.

Hosting and running costs

WordPress needs a server that runs PHP and a database. That can be cheap shared hosting or a managed WordPress host, and the price rises with traffic and with how much hand-holding you want. Premium themes, page builders and plugins often add yearly licences.

Static sites need somewhere to serve files. Many hosts offer free or low-cost plans that are more than enough for a typical marketing site, and the files can be moved between hosts with little effort. The extra costs on a static site come from the services you add for editing and forms.

The article on hosting costs compares the two in more detail without picking a favourite host.

Maintenance over time

A WordPress site needs ongoing care: core updates, plugin and theme updates, PHP version upgrades on the server, backups and occasional clean-ups when an update clashes with something else. Skip it and the site becomes a security risk. Do it and it takes time every month.

A static site needs much less. The built files do not go out of date in the same way. You will still update your static site generator and its dependencies from time to time, and that is easier to do safely because you can test the build before anything goes live. The maintenance comparison sets the two side by side.

The page builder problem

Many WordPress sites built in the last decade rely on page builders: visual tools that let you drag blocks onto a page. They solved a real problem at the time, which was letting non-developers change layouts without touching code.

They are also pre-AI tools, and it shows. The layout lives in a proprietary format in the database rather than in readable files. They add weight to every page. Moving away from one usually means rebuilding the pages by hand. And when something looks wrong, there is no clean template to open and fix, only nested panels of settings. Today, a designer can describe a layout change to an AI assistant and get a real, readable template back. Page builders were a workaround for a problem that now has better answers.

This is a criticism of page builders, not of WordPress. A WordPress site built with a clean custom theme avoids most of it.

When WordPress is still the right choice

WordPress is a reasonable choice when:

The site depends on features that need a server per visit, such as memberships, user accounts, complex search or an online shop with frequent stock changes.
Many people publish frequently and expect a large, mature editorial system with workflows, scheduling and roles out of the box.
Your team already knows WordPress well, has a maintenance routine that works and has no pain to fix.
You rely on a specific plugin that does something important and has no reasonable static equivalent.

Static sites can handle more of this than people expect, through external services, but at some point you are rebuilding WordPress out of parts. If that is where you are heading, use WordPress.

How to decide

Ask these questions about the site you actually have:

Is most of it pages and posts that change a few times a week or less? That suits static well.
Who edits it, and what do they need? If editors need a friendly screen, plan for a CMS from day one.
What do the forms do? Contact and enquiry forms are easy to solve on a static site. See handling forms on a static site.
Who maintains it? If nobody wants to own monthly updates, static removes most of that work.
Who changes the design? If a developer or designer will iterate on templates, readable files and git make that far easier.

If the answers point to static, the migration guide covers moving an existing site across.

My take

For the brochure sites, campaign sites and small business sites that make up most of what agencies and in-house teams look after, I now start static. The build is simpler, the hosting is cheap, and there is very little to patch. The two gaps that used to stop me, content editing and forms, both have good answers now. Mabel is the tool I build to cover those two for Jekyll sites, but it is one option among several.

I still recommend WordPress when a site truly needs what it does well. What I no longer recommend is reaching for it by default, and I would steer anyone away from building new sites on a page builder.