Why I Left WordPress for a Static Site

This site began as a WordPress installation, which felt like the obvious choice for a writer who wanted control over every page. From my desk in Dublin, I could publish an essay, update a coffee guide, add an annual reading list and rearrange the archive without asking a developer for help. It also gave me a familiar admin screen and a large ecosystem of themes and plugins.

When I explain why I switched from WordPress to a static site generator, I do not lead with page speed. The real reason was that the machinery around the writing had become more demanding than the writing itself. WordPress was still a capable tool, but for this particular site it created too many dependencies, too many decisions and too many small sources of anxiety. A static approach let me keep the freedom while reducing the operational clutter.

The problem was upkeep, not writing

Every extra feature arrived with a cost. A plugin handled search, another improved sharing, and a third supplied a contact form. Each package needed monitoring, occasional updates and a compatible version of PHP. The database and theme were fine on their own, yet together they formed a system that could change while nobody was editing an article.

That system was attractive because WordPress is one of the common defaults in the Australian small-business market. Many local agencies offer WordPress sites, WooCommerce stores and monthly care plans, so it is easy to find help or replacement plugins. For me, that advantage gradually became a liability. I was maintaining publishing software rather than maintaining a writing practice.

The turning point came after a run of small disruptions: a caching conflict, an expired security certificate and a plugin update that altered an old page template. None was catastrophic, and each was easy to repair. Combined, they made the site feel less dependable. The old workflow also encouraged formulaic content, a trap I have described in copy-and-paste marketing. I wanted fewer layers between an idea and the finished essay.

Measuring what mattered

Before moving anything, I wrote down what actually mattered: readable pages, quick navigation, stable URLs, an archive that could be searched, and a site I could publish from without drama. I stopped treating the WordPress dashboard as the centre of the project. The writing and the links between essays were the product; the backend was supposed to disappear.

This is particularly useful for readers in Australia. A commuter on a Sydney train or Melbourne tram is likely to open an article on a phone, often between other tasks and with an ordinary mobile connection rather than perfect office broadband. The same applies to someone checking a page over café wi-fi in Brisbane or on regional 4G. Smaller transfers and predictable rendering matter more in those moments than the convenience of editing a block from an iPad.

The useful comparison was not vanity analytics. I checked page weight, time to first byte, Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. I also counted the minutes spent each month on updates, backups, plugin compatibility and broken layouts. Those hours were harder to defend than the hosting bill. Static HTML removed the database from the request path and let a CDN serve the same file to readers in Adelaide, Auckland or Dublin.

Choosing a generator with less machinery

I tested Hugo, Astro and Eleventy with the same small set of posts. I looked for a tool that could read Markdown, support templates and collections, preserve plain text files and generate every page during a build. I did not want a framework that required a database or a permanent application server just to show an essay written years ago.

I settled on Eleventy because its defaults suit a writing site and its flexibility did not become another project. Markdown files hold the posts, front matter carries metadata and templates control the recurring pieces such as headers, guides and archive pages. JavaScript remains available for useful build tasks, but the finished site can be delivered as ordinary HTML, CSS and a small amount of client-side code.

Publishing now follows a simple chain. I edit in a text editor, commit the change to Git and let the build service generate and deploy the site. A pull request can produce a preview before anything goes live. The important difference is that each post is a file I own, while the generated pages are disposable output. That separation makes backups straightforward and makes accidental database corruption much less likely.

Moving the archive without breaking its memory

The first job was content, not code. I exported the WordPress XML, converted the posts to Markdown and kept the original titles, dates, categories and URL slugs. Old addresses mattered because some essays had been cited in newsletters, bookmarks and other people’s articles. For any address that had to change, I created a permanent redirect rather than quietly breaking the path.

A useful test was an image-heavy local guide such as my notes on finding good pub coffee. It made it easy to see whether resized images, sensible dimensions and restrained scripts behaved well on a narrow screen. I also built tag pages and client-side search so that older writing did not become a digital storage cupboard. The archive should feel like a reference shelf, not an attic.

The email subscription needed separate care. A static front end does not make the list compliant by itself, and the Australian Spam Act 2003 still applies to commercial electronic messages. The sign-up form records consent, every message identifies the sender and includes a working unsubscribe link. Keeping the audience list outside the site means the posts remain independent of a plug-in, but the operational responsibility for the list remains exactly where it was.

Designing for Australian readers

The visual design became simpler after the rebuild. The site uses a clear reading column, large type, strong contrast and pages that work without a sprawling page builder. Australian readers often move between a phone, a desktop and a tablet across the course of a day, so responsive text and stable navigation matter. A page about Irish history, a pub walk or marketing should load just as cleanly on a crowded train as on a large monitor.

The legal and privacy details also became easier to audit. The site sets no advertising cookies by default and loads little third-party code. Analytics remains optional and identifiable information is limited. If the site’s data practices fall within the Australian Privacy Act 1988, its collection and handling still need to match the Australian Privacy Principles; replacing PHP with HTML does not provide an exemption. This is a better setup for transparency because the list of scripts is short enough to read.

I still think about the site as a portfolio. My piece on portfolio design for hiring makes the same point: presentation cannot rescue weak material, but it can make good work easier to understand. The archive, reading lists and city guides now show range without competing for attention. Each page has a job, and the navigation lets a visitor move from one piece to another without searching.

The trade-offs I still notice

The main loss is convenience for non-technical editing. I can update a post with Git, Markdown and a template, but I no longer open a friendly admin panel and click Publish. That is irrelevant if I am comfortable with the workflow, yet it would be a poor trade for a busy team that needs several people to change the same site at once. WordPress or a managed headless CMS would suit that situation better.

The second trade-off is that static sites are not automatically complete. Search, comments, forms and multi-author workflows need separate tools, each with its own cost. I removed comments and use email for responses, which suits a personal blog but would not suit a publication built around discussion. A CMS can handle structured content and permissions more comfortably, especially when the content changes for reasons other than publication.

Static generation also changes the security conversation. There is no PHP application or database to patch on the live server, so the site avoids many common intrusion routes. It still has dependencies in the build chain, and a compromised repository could publish harmful output. I protect access with strong credentials, review updates and rely on immutable backups. The goal is fewer moving parts, not the fantasy of a site that cannot fail.

The next step for this site

The site now holds essays on technology, politics, Irish culture and history, alongside reading lists, travel notes, web design, coffee and pub guides. Its purpose has not changed; the machinery is simply quieter. Publishing has returned to the rhythm of writing, editing and committing a file, which is the rhythm I wanted when I began.

My rule is now straightforward: use a static site generator when the content is primarily text, the publishing team is small and the finished pages should be durable. Keep a dynamic CMS when people need live editing, complex permissions or tightly integrated application features. The answer depends on the site’s job, and the best platform is the one that creates the least friction between an idea and its reader.

My next concrete step is to run a full link-and-redirect audit at my desk next Sunday morning.