This blog is edited and published via the Stelae (https://stelae.eu) private WordPress editor and its static HTML deployment feature. Using Stelae to power the blog is an example of what I mean by manageable but capable software while simultaneously being a product demo and a way to test Stelae and make sure everything is in working order.
WordPress is good at many things. One of them is writing and editing content. The editor is familiar to many people, there are themes and plugins, built in media handling and lots of both free and paid knowledge and support available.
But everything related to public WordPress hosting is just a chore. There are lots of different hosters in different price ranges with different features, support tiers, server performance, … . Then you either need to make sure to keep WordPress and PHP up to date or pay someone to do it. You’ll probably want to vet the plugins you want to install for security issues as well, or live with the risk of getting your website defaced or even losing data that wasn’t backed up properly.
This blog does not have user accounts, comments, checkout, memberships, or anything that requires WordPress to run on every page view. Most of the time, the public site only has to do one thing: serve finished pages to readers.
So the setup is simple:
- I write in WordPress.
- Stelae exports the site as static HTML.
- The public blog serves static files.
There is no public WordPress login page, no public PHP, and no database involved when someone reads a post.
That is the trade-off I like. WordPress stays where it is useful: editing. The live site becomes much simpler.
Something that made me smile while setting up the blog
I used Kadence Site Assist to get started with the blog. It has a useful checklist for getting a WordPress site ready: design, pages, navigation, content, and the usual launch tasks.
Near the end of that checklist, there are these two sections:
- Site Security Setup
- Website Performance Setup
For a normal public WordPress site, those are important. You have to think about login protection, plugin exposure, updates, caching, database performance, optimization plugins, and all the other things that come with running WordPress on the public web.
For this blog, those sections don’t matter nearly as much, which felt like a validation of the trade-offs I deliberately made for Stelae.
Not because security and performance are unimportant. They are still important. But the problem changes when the public site is static.
The live blog has no WordPress backend exposed to visitors. It does not execute PHP to render posts. It does not query a database for every page view. It is just static files.
That means a lot of what people usually have to fix in WordPress becomes the default.
Performance is mostly the natural result of serving static files. You can’t get much faster than just serving static files.
Security is mostly the natural result of not exposing WordPress as the live site. It is not publicly reachable by design. Of course, that does not mean nothing can ever go wrong. The hosting provider could have an issue, DNS could be misconfigured, or the deployment process could break. But the usual public WordPress attack surface is simply not there.
This is one of the biggest benefits of Stelae, and I want to write about it separately. Once you notice it, you start seeing it everywhere: many articles about “doing WordPress right” spend a huge amount of time on security and performance.
With Stelae, a lot of that comes from the architecture itself. It is not an optimization strategy you add later. It is just the architecture.
Intentionally ordinary
I also want this blog to be a fairly ordinary WordPress blog.
It is not supposed to be a custom showcase that only works because I built special things around it. I use a normal theme, a normal editor, a normal set of pages, and currently just Kadence Blocks and Starter Templates by Kadence WP as plugins.
That’s important to me.
If the blog used a heavily customized setup, it would be a worse example for Stelae. I do not want to show what I can build with enough custom code. I want to show what a normal small site can look like when WordPress is used as the editor and static HTML is served for the public site.
The blog should be readable, boring, and easy to move around in. That is the point.
A real test
Running this blog on Stelae is also useful for me.
If accessing the editor feels awkward, I will notice. If exporting breaks something, I will notice. If the theme does something that does not work well as static HTML, I will notice. If the workflow becomes annoying, I will notice.
That makes the blog a real test case (while also serving the purpose of a demo to some extent).
It also keeps the product honest. Stelae is not meant for every WordPress site. It is not the right tool for shops, membership sites, native comments, dashboards, or anything that needs WordPress to react dynamically to each visitor.
But for a blog like this, the shape fits well.
- Mostly static content.
- Occasional updates.
- A familiar editor.
- A simple public site.
That is exactly the kind of website I build Stelae for.
