We moved our own site off WordPress

Up front, so the direction is clear: WordPress is a good piece of software. According to W3Techs it runs 40.7 percent of all websites and 58.9 percent of all sites with a known content system (as of 7 September 2026). That does not happen by accident. We still build WordPress sites for clients where it fits.

Our own site has not run on it since July 2026. Here is why, and what it bought us. Including the uncomfortable parts.

What was actually wrong with our old site

Before moving, we took inventory. The result was sobering, and the interesting part is this: almost none of it was WordPress's fault.

Eight findings, and six of them we could have fixed in WordPress exactly as well as anywhere else. Anyone buying new software to solve a maintenance problem ends up with a maintenance problem and new software.

That is the most honest sentence in this post, and it applies to most switches we hear about.

What tipped it anyway

Two things, and both are about daily operation rather than building.

The number of moving parts

Our old site ran on a purchased theme with its own page builder, a child theme, an add-on for the builder and several further plugins. Each of those gets updates, each can break, each can carry a hole.

The numbers here are unambiguous. Patchstack counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, up 42 percent on the year before. They broke down as:

So the core is not the problem. The problem is the toolkit around it, and it grows with every wish you grant yourself quickly. One more number explains the time pressure: 46 percent of the vulnerabilities had no patch at the moment of disclosure, and for the heavily targeted ones the median time to first exploit is five hours.

That is manageable. It needs automatic updates, backups you can actually restore, and somebody who looks. For a client site with a maintenance budget that is the normal path. For our own site we would rather not have the job at all.

Building instead of operating

The second reason is taste, and we will label it as such. With a builder theme the design lives in an interface and in a database. Changing something means clicking. Understanding why something looks a certain way means clicking through layers.

We wanted the design in plain text, versioned, with a history. That is not a universal requirement, it is ours. For somebody who wants to click their own site together it is exactly the wrong road.

What the move bought us

We moved to a flat file system that stores content as text files instead of in a database. Measured on the home page today:

The last two rows are the actual change. Not one JavaScript file, everything the page does behaviourally sits in three short blocks in the source. And no database means no database backup, no database server, no restore procedure, no database user with the wrong permissions.

The font file is a good example of what changes as a side effect. The old site loaded four typefaces: the brand face, two strays left over from plugins, and two icon fonts. Today it is one, subset to the characters three languages need.

Day to day it now looks like this: changes go to the server through git, there are no plugin updates, and the backup is a copy of a folder.

What got worse

This is the section other accounts like to leave out.

The market of ready made solutions is tiny. WordPress has over 60,000 plugins. What we needed, we had to build: the search engine integration, the handling of form submissions. That was work which would have been two clicks on WordPress.

The pool of people is smaller. Anyone with a WordPress site can find somebody to take it over anywhere. With a rarer system that circle is much narrower. That is a real risk, and anyone deciding on behalf of a client has to say so out loud.

There is no visual builder. New sections happen in code. Text, images and all content are still editable in the admin area, the layout itself is not.

A migration costs roughly what a rebuild costs. Every page gets touched once, every address needs a redirect. What that involves is in our post on the website relaunch.

When WordPress stays the right call

The row about the missing maintenance budget is the one we care about most. A WordPress site without upkeep is the most expensive option of all over time, because the work accumulates and comes back as an outage.

The four questions that decide it

After this move we would frame the question differently. Instead of "which content system", rather:

1. How many parts does the site have that receive their own updates? Every part is a deadline and a risk.
2. Who looks, and how often? If the answer is nobody, the architecture has to make up for it.
3. What happens when one part fails? Does the site go down, or is one detail missing?
4. Who can take it over in three years? The rarer the system, the more the documentation matters.

Answer those four and you land on WordPress or somewhere else, and either way it is a decision rather than a habit.

If you are wondering whether a switch would pay off for you, drop us a line with your address. We will look at how many moving parts are in there and tell you honestly whether the numbers work. Often the answer is no.

Sources

• W3Techs: usage statistics of WordPress
• Patchstack: State of WordPress Security 2026
• WordPress.org: plugin directory
• Grav, the flat file system we use