WordPress runs a vast share of the web, and for good reasons. It is also, for a lot of personal blogs, more machine than the job needs. A static site – plain HTML files generated once and served as they are – sits at the other end of the scale.
This is a comparison for one use case only: a personal blog, written mostly by one person. For a newsroom, a shop or a membership site the answer is different, and usually it is WordPress or something like it.
The fundamental difference
A self-hosted WordPress site is an application. Every page view can run PHP code, query a MySQL or MariaDB database and assemble the page on the fly (caching softens this, but the application is always there). Your writing lives in that database.
A static site is a folder of files. Something – a generator on your computer, a build service, an app – turns your posts into finished HTML, CSS and images once, and a web server hands those files out unchanged. Your writing lives wherever the generator keeps its source.
Almost every trade-off below follows from that one difference.
Security and patching
WordPress is well maintained and its core team takes security seriously. Since WordPress 3.7, minor releases – which carry most security fixes – install themselves automatically, and new installs since 5.6 auto-update major releases too. Since 5.5 you can switch on automatic updates for plugins and themes, one by one.
The exposure comes from what you add. Each plugin and theme is code from a different author, running on your server with access to your database. Most are fine. Some are abandoned. The login page is a permanent target for password-guessing bots. Running WordPress safely means staying on top of updates, pruning plugins you don’t use and keeping good backups, indefinitely.
A static site has almost nothing to attack. There is no login page on the public server, no database, no code running per request. The remaining risk is the server or host itself, and the credentials you use to upload. For a site you might not touch for months, that difference is the main argument.
Verdict: static, clearly, for a solo blog.
Plugins and features
This is where WordPress wins, and it is not close. The plugin directory covers almost anything you can imagine: SEO tools, galleries, events, bookings, shops, memberships, translations. You can add a feature to a live site in a few clicks without writing code.
A static site can only do what its generator, its theme and client-side scripts can do. That covers the essentials of a blog – posts, pages, tags, feeds, sitemaps – very well. It does not cover “add a booking calendar this afternoon”.
Verdict: WordPress.
Comments
WordPress has comments built in, with moderation, threading and email notifications, plus Akismet for spam. It works on day one.
A static site has no server-side code, so comments have to come from somewhere else. The honest options:
- A third-party embed. giscus, for example, is free, open source and stores comments in GitHub Discussions – which means commenters need a GitHub account. Fine for a developer blog, a barrier for most others.
- A self-hosted comment server such as Remark42. Good, private, and one more service for you to run and patch – which gives back part of the security advantage.
- No comments. Many personal blogs now link to an email address or a social post instead. Replies arrive in private, the spam problem disappears and the page stays static.
Verdict: WordPress, if comments matter to you. If they don’t, this stops being a factor.
Forms
WordPress has several mature form plugins, and form submissions go straight into your database or inbox.
A static site needs a form backend. Some hosts provide one: Netlify Forms detects a form marked with data-netlify="true" at deploy time and collects submissions for you. Otherwise a service such as Formspree receives the submission and emails it on. Both work well for a contact form. Both mean someone else handles your readers’ messages, and free tiers have limits, so check them.
The simplest contact form is still a mailto: link.
Verdict: WordPress is more flexible; a static site is fine for a single contact form.
Search
WordPress has search out of the box, querying the database.
Static sites used to be weak here. Not any more: Pagefind builds a search index from your finished HTML and runs entirely in the reader’s browser, with no server. For a blog of a few hundred posts it is fast and good. Some generators do not include it by default, though, and adding it may mean a build step.
Verdict: roughly even, with a little more setup on the static side.
Cost
WordPress needs hosting that runs PHP and a database. Cheap shared hosting can do it; decent managed WordPress hosting, which handles updates and caching for you, costs more, and you will want backups on top. Premium themes and plugins often carry yearly licences.
A static site can be hosted on almost anything: a basic web server you reach over SFTP, object storage such as S3 or Cloudflare R2, or the free tiers of Netlify, Cloudflare Pages and GitHub Pages. For a personal blog the hosting bill is frequently zero, and the domain name is the only fixed cost.
Verdict: static.
Speed
A well-configured WordPress site with page caching and a CDN can be very fast. Many are not well configured, and a heavy theme with a dozen plugins can load a lot of scripts on every page.
A static page is already finished when the request arrives. It is trivially cacheable and, with a light theme, small. It is hard to make a static blog slow.
Verdict: static by default; WordPress can match it with effort.
Backups and portability
Backing up WordPress means backing up two things – the database and the wp-content folder – and testing that you can restore them. Plugins such as UpdraftPlus automate this. It is not difficult, but it has to be done.
A static site’s output is a folder of files. Copy it anywhere and you have a working backup of the published site. The source of your posts needs backing up too, wherever your generator keeps it, but there is no database to dump and nothing to reassemble. Moving host means uploading the same files somewhere else.
Verdict: static.
Editing and multiple authors
WordPress has a proper browser-based editor, user accounts and roles (administrator, editor, author, contributor), drafts, revisions and scheduling. A non-technical co-writer can log in from any computer and contribute. That is a real strength.
Most static generators assume one person with a text editor and a command line, and “multi-author” usually means “everyone uses Git”. Tools exist to put a friendlier editor on top, but they add moving parts.
Verdict: WordPress, especially for teams or non-technical writers.
Summary
| WordPress | Static site | |
|---|---|---|
| Security upkeep | Ongoing | Minimal |
| Plugins and features | Vast | What the generator provides |
| Comments | Built in | Third-party or none |
| Forms | Plugins | Host feature or third-party service |
| Search | Built in | Client-side (e.g. Pagefind) |
| Hosting cost | PHP hosting | Often free |
| Speed | Good with tuning | Fast by default |
| Backups | Database + files | Copy a folder |
| Multi-author editing | Excellent | Limited |
Choose WordPress if you need plugins, built-in comments or several non-technical authors. Choose a static site if it is your own writing, you want it fast and cheap, and you would rather not be on call for security updates. For more on the hosting side, see how to host a static blog on your own server.
Where Selfish fits
The usual catch with static sites is the command line. Selfish is a native app for iPhone, iPad and Mac – £3.99 once, no subscription – that writes, builds and publishes a static site – over SFTP or to S3-compatible storage, Netlify, Cloudflare Pages or GitHub Pages – with no terminal involved. It does not do comments or forms. It is out now on the App Store, at a £3.99 introductory price, rising to £9.99 in December; the publishing setup guide and Selfish vs WordPress.com have the detail.