Why WordPress Is No Longer State of the Art — And What Works Instead

WordPress is not broken. It is twenty years old, and it now carries jobs it was never designed for. A blogging tool from 2003 has become the foundation for company websites, shops, booking systems and customer portals, not because the architecture suits any of that, but because sooner or later a plugin appeared for every one of those problems. This guide explains where that construction hits its limit, why a caching plugin does not fix it, and what a hand-written website does differently in practice. With real measurements, not claims.

First, in fairness: why WordPress got so big

There is a good reason roughly four in ten websites worldwide run on WordPress. In the early 2000s a website of your own cost either a lot of money or a lot of programming knowledge. WordPress broke that open: free, installed in half an hour, and suddenly anyone who could use Word could maintain their own content. That was a small democratisation, and it worked.

On top of that sits an ecosystem without equal. For almost any problem there is a ready-made extension, often dozens. If you need something online quickly and have nobody who writes code, WordPress will still get you further than almost anything else. That is a genuine strength, and it still holds.

Except that this very strength is the root of the problem, because each of those extensions is somebody else's code landing inside your website.

The plugin tower: when a website becomes a structure of foreign parts

Take a look at the extension list of a company website that has been around a few years. What you typically find looks roughly like this:

• a page builder used to construct the layout
• a purchased theme, plus a child theme for custom changes
• a contact form plugin
• a cookie banner plugin
• an SEO plugin
• a caching plugin, because the site got slow
• an image optimiser, for the same reason
• a backup plugin
• a security plugin
• a slider, a gallery, a review widget, a map
• and depending on the business: bookings, a shop, a member area, a newsletter

Twenty-five to forty extensions on a site with a few years behind it is not the exception, it is the norm. They were written by twenty or thirty different people and companies who have never met. Each brings its own code, its own database tables, its own stylesheets and scripts, and each follows its own release schedule.

As long as everything works, nobody notices. It gets interesting on the day something stops working, because then nobody at the table is responsible for the whole. The plugin author says it is the theme. The theme vendor says it is the page builder. The page builder company says the plugin does not follow the rules. All three are a little bit right, and your website is broken regardless.

The page builder deserves its own mention here. It is the most convenient part of the system and simultaneously the most expensive one. What looks like two columns of text in the editing window ships as a dozen nested containers with hundreds of lines of generated styling. And there is no way back out: switch the builder off and instead of your page you get a pile of shortcodes in square brackets. At that point the content effectively belongs to the tool.

Why WordPress sites are slow, and why a caching plugin does not fix it

The slowness is not sloppiness, it is architecture. On every single page request the following happens: the WordPress core boots, then every active extension is loaded — all of them, every time, regardless of whether the requested page needs them at all. The shop plugin starts up on your legal notice page. The slider starts up on a page with no slider. The content is then assembled from a database whose structure was designed for blog posts, with custom fields scattered across a side table, which means another query per field.

Then there is what arrives in the browser. Every extension attaches its own stylesheets and scripts to every page just in case. Sixty to a hundred individual files for a page with three paragraphs of text is a figure you measure regularly in the wild. That three versions of the same script library are among them goes unnoticed, because nobody has the overview.

And then comes the caching plugin. It does what its name says: it remembers the finished page and serves it directly next time. That measurably helps, and it is still a lid on the pot rather than a smaller fire, because three things stay exactly as they were:

• The first visitor always pays. After every content change, every update, every cache purge, the page is rebuilt from scratch, and whoever clicks at that moment waits the full time.
• Nothing changes in the browser. The cache concerns building the page on the server. Those sixty stylesheets and scripts are still downloaded and executed, and on a phone that is where most of the time goes.
• Logged-in users never see the cache. Anyone working in the admin area, with something in a shopping basket, or inside a member area gets the unaccelerated version every time.

There is an irony you see often in practice: the caching plugin fights the host's own cache, the security plugin blocks the image optimiser, and a business ends up paying for three tools that slow each other down.

The maintenance spiral: updates you can neither install nor skip

A WordPress site has three update sources that nobody coordinates: the core, the theme, and every single extension. With forty extensions, a normal month easily brings twenty updates. Each one can change something another one relied on.

That puts you in a bind with no good side. Install the updates and you risk the contact form no longer sending on Monday morning, or a subpage layout falling apart. Skip them and known security holes accumulate. And in practice those almost never sit in the WordPress core itself, which a large team maintains, but in the extensions: in the gallery plugin the author last touched three years ago, or the form tool whose company no longer exists.

This is not grey theory. In August 2026 we cleaned up a customer server where a cryptocurrency miner had been smuggled in through an outdated piece of standard software. The way in was not a sophisticated attack but a known hole in a third-party system that had not seen an update in months. Cleaning up, rotating passwords, re-securing the server, tracing the cause: that costs more than every update you saved yourself.

The real point is not the individual hole. It is that with forty extensions you take on forty foreign maintenance promises, none of which you can enforce.

What the building-block approach costs once you add it up honestly

"WordPress is free" is true of WordPress itself. For a company website it rarely is. What typically hangs off such a site in annual licences:

• the theme, usually as an annual licence
• the page builder in its paid version, otherwise half the blocks are missing
• the SEO plugin in its paid version
• the form plugin, as soon as it needs to do more than "name, email, message"
• backup and security, both usually on subscription
• and as needed: bookings, shop extensions, multilingual support, image optimisation

Depending on the selection you land in the low-to-mid hundreds per year in licences alone, before a single hour of work and before hosting. On top of that, this kind of construction needs more machine: what crawls on a basic plan quickly demands a larger one. And then there is the ongoing upkeep, which somebody has to do, because updates do not review themselves.

This is not an argument against running costs. A website is a piece of business equipment, and equipment costs money. It is an argument against putting that money into foreign licences instead of into your own site.

Load time is not a contest for points, but for enquiries

When people hear "PageSpeed" they think of a number technical people compare among themselves. The actual reason the number matters is different: for years Google has been measuring how a page feels to real visitors, and calls those measurements Core Web Vitals. Three of them decide the outcome:

• LCP — how long until the largest visible content is there. Good is under 2.5 seconds.
• INP — how quickly the page responds to a tap or click. Good is under 200 milliseconds.
• CLS — how much the layout still jumps around while loading. Good is under 0.1.

The performance score in PageSpeed Insights summarises such measurements in a lab. The heaviest weight goes to the time the page cannot respond to input at all, followed by LCP and CLS. And those are precisely the three things a plugin tower reliably ruins: a lot of script code wanting to execute during load, a page builder that loads the main image late, and blocks that only know their height once they have finished loading.

For your business that translates into something concrete. Someone searching for a tradesperson on their phone does not open a page and wait. They tap the first result, and if nothing is there after three seconds they go back and tap the second. That is not a question of patience but of context: the search happens in the car, at the kitchen table, on the building site. And anyone travelling between Hohwacht Bay, Lütjenburg and Panker knows the mobile signal here is not city-grade everywhere. A page that has to load three megabytes goes unnoticed on Kiel wifi and is an imposition on the country road to Schönwalde.

What a hand-built website does differently

The difference is fundamentally simple: only what this one page actually needs gets delivered. No core dragging a blog structure along. No forty extensions booting just in case. One stylesheet instead of sixty files. The page structure is not the output of a builder but written by hand, which is why only what belongs there is in it.

You can measure what that looks like in numbers on this very website. On 27 August 2026 we measured with Lighthouse, on mobile, the way Google does. For our custom development page the result was:

• Performance 97
• Accessibility 100
• Best Practices 100
• SEO 100
• Largest content visible after 1.1 seconds, blocking time 0 milliseconds

That needs an honest reading, otherwise the number is worthless. A hundred performance points is achievable but not a law of nature: as soon as a page shows an embedded video, a real map or a third-party widget, that costs points regardless of how cleanly the rest is built. The value also fluctuates between measurements because it depends on connection and server load. What stays reproducible are the 100s in accessibility, best practices and SEO, because those do not depend on the network but on care during construction. And a performance score consistently in the nineties is simply not available with a plugin tower, no matter how good the host is.

You do not have to take our word for it: put this page and your competitor's page into PageSpeed Insights and compare for yourself. That is the pleasant part about measurable claims.

Interfaces: where the building-block approach finally stops

Load time is the visible argument. The more expensive argument is a different one, and it usually surfaces in year two: your website does not stand alone. Alongside it the business runs inventory management, accounting, perhaps a point-of-sale system, a calendar, time tracking, a CRM. And at some point the question arrives of why data already in the building has to be typed in a second time by hand.

In building-block thinking you look for a connector plugin at this point. Sometimes one exists, and then it does sixty or eighty per cent of what you need. The rest stays manual, and because the plugin simply cannot do the remaining twenty per cent, the business process gets adapted to the tool instead of the other way round. The second option is a chaining service billed per operation: convenient at first, unpleasant once volume appears, and your business data travels across somebody else's server on the way.

When the interface is part of your own application, it looks different. You map exactly the fields that exist in your business, including the special cases no standard product has. The sync runs at night, logs itself, and speaks up when something does not go through. In practice that looks like this:

• An enquiry through the form does not become an email; it creates a case in the CRM directly, with assignment and follow-up date.
• A confirmed online appointment lands in the right employee's calendar, not in a second system somebody reconciles each morning.
• Prices and availability come from inventory management instead of being maintained in two places, one of which is always out of date.
• A completed order produces the accounting entry instead of being entered by hand at month end.

These are not invented examples. Our online appointment booking, our mailbox migration tool and the customer portal behind our server monitoring are all in-house developments hanging off exactly such interfaces. We do not just build this for clients, we run it ourselves.

The surprising part: custom is often finished sooner

The common assumption is: off-the-shelf means fast, custom means drawn-out. In practice that is surprisingly often untrue, and the reason is mundane. With a building-block system a large share of the time goes not into the website but into fighting the tool: you search for a plugin covering that one special case, try two, discard one, bend the theme back into shape with extra styling rules because it will not play along in one spot, and end up building a workaround anyway.

Building it yourself removes exactly that search. The structure is settled on day one because it comes from your requirements rather than from whatever happens to be available. And we do not start from zero: the editing system, form handling, user management, invoicing logic and interface tooling all sit ready as our own, proven components. What looks like "written by hand" is assembled from parts we know — only they are ours, whose behaviour we can guarantee, rather than somebody else's, whose next update we have to wait for.

The second time saving comes later and is the larger one. A change to a hand-written page is a change to one file. The same change in a grown building-block setup starts with working out which of four possible tools actually generates that area.

When WordPress is still the right choice

It would be dishonest to write this up as a pure indictment. There are cases where we recommend WordPress ourselves, and we say so in the first conversation:

• When the website is essentially a magazine. Several authors, new articles daily, editorial workflows with approvals: that is what WordPress was built for, and that is where its strength shows.
• When the budget is genuinely small. If you have to stay under a thousand euros you will not get custom work for the money, and then a cleanly set-up WordPress with few, well-maintained extensions is the more honest recommendation than a half-finished bespoke project.
• When you enjoy tinkering yourself. Some businesses have someone who likes this and is good at it. Taking the toolkit away from that person would not be progress.
• When the existing site works. A well-maintained WordPress with eight extensions, good scores and satisfied users is not replaced because something more modern exists. A relaunch needs a reason.

The inverse describes fairly precisely when it tips over: as soon as the website is supposed to do something rather than merely show something. Book, calculate, connect, administer, log customers in. From there on you are working against the system instead of with it.

For businesses in Lütjenburg, Kiel and the surrounding area

We are based in Behrensdorf on Hohwacht Bay, a few minutes from Lütjenburg, in the Plön district right on the border with Ostholstein. Kiel is a good half hour away, Eckernförde a little further, and Plön, Preetz, Schönberg, Eutin, Malente, Oldenburg and Neustadt all sit within the same radius. This is not a sales territory drawn on a map, it is the area where we fill up the car and do our shopping.

In practice that means two things. First: when an on-site meeting makes sense, we come by, and nobody is counting the drive back to Hamburg. Second, and more importantly: we know the search landscape here. A painting business in Lütjenburg does not compete with the whole of Germany but with the other painting businesses between Selent, Schönberg and Panker. That is a competition you can win, and one where a site that loads fast, is cleanly structured and shows the phone number immediately on a phone genuinely makes the difference. If you want to work that ground, the details are on our pages for web design and search engine optimisation.

Switching without losing your rankings

The most common worry about switching is a fair one: what happens to visibility on Google? A migration is not a risk if you do it properly, and a guaranteed crash if you do not. The old addresses are what matter. Every subpage that gets a new address needs a permanent redirect from the old one, otherwise the signals accumulated over years evaporate. Add to that content that actually moves across rather than being dropped "while we are at it", a clean handover of structured data, and a short follow-up check in Search Console.

How that works in detail is in our relaunch checklist. The short version: visibility usually stays stable, and the faster build tends to pay in during the weeks afterwards.

What it costs

A hand-built website is not a luxury item, but it is not a 500-euro job either. Our entry points:

• Landing page from 1,290 euros one-off: one page that does one thing, properly.
• Starter from 2,500 euros one-off: the classic company website with the key service pages.
• Business from 5,500 euros one-off: more scope, more functionality, editorially maintainable.
• Shop & portal from 9,500 euros one-off, when the site needs to sell or log customers in.

If it is less about a website and more about a tool — an interface, an automation, a portal — the entry point is a free feasibility check. Small projects start at 890 euros, larger ones at 4,900 euros, each with a fixed price per stage rather than an open hourly account. And because it belongs here: if a ready-made tool fits your problem well, we will tell you so in that conversation instead of selling you a bespoke build. The details are on custom development.

Running costs come on top, but leaner than with a building-block setup: hosting from 19 euros a month, website care from 29 euros a month. No plugin licences, because there are no plugins.

Conclusion

WordPress is not bad software. It is a blogging tool from 2003 that has had twenty years of jobs piled onto it that it was not built for, and that solves them with foreign code nobody is answerable for as a whole. From that follow the three things that bother businesses in practice: it loads slowly, it constantly wants maintaining, and at the decisive point, connecting to your other systems, it stops.

A hand-written website does not solve that by magic but by leaving things out. Only the code this page needs. No foreign update cycles. Interfaces that model your processes rather than the other way round. And measurements you can verify yourself instead of having to believe.

If you want to know where your current site stands, send us the address. We will measure it and tell you honestly whether a rebuild is worth it or whether tidying up will do.