I have used Wordpress a lot in the past, and even hosted other people’s Wordpress sites in the past. However, in this iteration of my website I decided to go with the static site generator Hugo instead. In the big 2025, the demands of running Worddpress strike me as excessive for a simple personal site.

Wordpress is a capable content management system, but Wordpress is also a very demanding application. A poorly configured or maintained Wordpress installation is a hazard to the rest of the internet.

The Wordpress Stack

A Wordpress site depends on a number of moving parts which are necessary for Wordpress to serve content to browsers.

Underneath Wordpress you have at a minimum:

• The host operating system. Normally linux, and more specifically a RHEL like distribution with cPanel or hosting control panel.
• The webserver daemon.
• A PHP runtime that interfaces with the webserver daemon.
• A MySQL or MariaDB database that Wordpress will use to store and retrieve site structure and content.

How this stack ends up serving a page to the user (simplified):

1. A browser requests a page from the server
2. The webserver daemon calls on the PHP runtime to execute the code necessary to display the requested page.
3. As Wordpress generates the page it queries the database to get necessary content.
4. The server passes the page to the browser.

Compare to how a static site is served (also simplified):

1. Browser requests page
2. Server passes page to the browser

Now a production Wordpress deployment will often have some sort of caching implementation to make many page serving events more like the static site process.

From this caveat, “a production Wordpress deployment”, we get to the next problem space. Wordpress works best when you start building a stack on top of the core of the software.

You may want themes for the aesthetics or extensions to modify Wordpress’s behavior. The complexity can snowball. Then there’s the xml-rpc interface… and handling spam comments.

Then there’s the problem of caching content because even without a sizable population of human readers, the robots feeding AI and other big data ventures creates a baseline level of traffic that must be handled without generating a page every time a page must be served.

The problems that must be addressed to responsibly keep a Wordpress site online and healthy are sufficient to make administering Wordpress a vocation rather than a hobby.

What, if not Wordpress

I’m test driving Hugo, but there are other tools that work on the same workflow:

1. Have content in Markdown
2. Execute Hugo, or another site generator on the files with your content
3. Receive your content structured into a coherent site that is ready to deploy

Deployment is as simple as rsync’ing to your server. Since the files are complete and sufficient to be the website, your http daemon doesn’t need to mediate access to other runtimes. Configuring the daemon becomes much simpler, and all around you need much less server to handle the same demand.

The one major downside is losing facilities for the public to comment on page.

Historically this has been the killer feature of Wordpress and other content management systems born in the early days of blogging.

Feedback and comments need to be passed out of band, but the defacto state of affairs is that even when running Wordpress, some sort of out of band communication is necessary to address the problem of comment spam. Comment spam was a serious nuissance well before GPT-1 was released. As as LLMs have matured with #vibecoding entering the popular lexicon…

Fending off the hordes of low margin marketers is a problem I prefer opting out of.