My first WordPress site went live around 17 years ago. It was my own travel blog, built on a generic theme that I half-rebuilt in HTML and CSS because the theme couldn’t quite do what I needed it to. I’d come to WordPress from Dreamweaver via a stretch of hand-coded HTML, and the pitch at the time was simple: WordPress let me update content from a browser instead of opening files in Dreamweaver, editing them locally, and FTPing them over to the server.

That’s a low bar by today’s standards. It didn’t feel like one then.

Seventeen years later, I’m still building on WordPress, and I’ve watched it move from a blogging tool that powered a small fraction of the web to the platform behind 43% of all websites online. A lot has changed. Some of it has been worth the upheaval, some has been hype that’s quietly faded, and the bits that haven’t changed are, oddly, the bits that matter most.

This isn’t a list of WordPress release notes. It’s what I’ve actually noticed from inside the work.

What’s genuinely changed

Themes to page builders, and most of the way back

The first decade of WordPress, for me, was themes. You picked or built a theme, you wrote your CSS, and the site looked the way the theme let it look. If a client wanted a layout the theme didn’t support, you went into the PHP and rebuilt the template. It was slow, but the sites were lean, and what shipped was what you’d designed.

Then came the page builders. Elementor was the loudest of them, around 2016, and it spread fast. Clients liked it because they could edit a page in something close to a Word document. I was less sold. The HTML it produced was bloated, the page weight ballooned, and a site that loaded in 1.5 seconds on a clean theme was suddenly taking 4 seconds because every block had its own inline styles and a stack of vendor scripts.

Beaver Builder was a step in a better direction. Less bloat, cleaner output, and content that clients could genuinely edit without breaking layouts. We used Beaver Builder for a long stretch as the right balance between client-editable and lightweight, before the block editor existed as a serious option.

The block editor (Gutenberg) has now matured into something I’d happily build with. The pendulum swung from custom code (powerful, fragile) to page builders (fragile, bloated) to the block editor (still imperfect, but defaults to clean output and treats content editing as a first-class feature, not a bolted-on afterthought).

If you’re starting a new site in 2026, my view is that a lightweight theme plus the block editor is a better foundation than any of the page builders. Beaver Builder is still respectable. Elementor I won’t put on a build I plan to maintain.

The rise of managed hosting

For most of the 2010s, hosting was hosting. You picked a shared host, you got a cPanel login, and that was that. The cheap end was awful, the mid-tier was usually awful but in a different way, and the only reliable option was a VPS that you had to know how to administer.

The whole category of “managed WordPress hosting” emerged because the existing options weren’t fit for the job. Sites were getting slower as plugins got fatter. Hosts were overcommitting servers. Security was an afterthought on most plans, with the host’s response to a hacked site being “you should install a security plugin” rather than “this shouldn’t have happened on our infrastructure.”

WP Engine launched in 2010, Kinsta in 2013, and the category had filled out by the mid-2010s. By the time we’d settled on a managed approach for client sites that earned real money, the question had stopped being “should we use managed hosting?” and started being “which one’s actually competent?”

The honest answer in 2026 is that managed WordPress hosting now does the job that shared hosting always pretended to. It’s the unglamorous fix to a problem that was costing UK businesses real money for years.

Performance went from polish to baseline

For most of my first decade building WordPress sites, “fast enough” meant the page loaded before the client closed the browser tab. Performance was the thing you tightened up at the end if you had budget left. It almost never had its own line in the brief.

Then Core Web Vitals landed in 2020 and quietly changed the rules. Google started measuring real-world load times as a ranking factor. Suddenly a page that took 6 seconds to become interactive wasn’t just slow, it was costing search visibility and ad spend at the same time.

The hard part isn’t building a fast site. The hard part is making a slow site fast after the fact. As projects get larger, people regret not optimising from the beginning. By the time the homepage has thirty plugins, four sliders, a chat widget, two analytics pixels and a hero video, no amount of caching saves you. The right time to think about performance is before the design is signed off, not when the Core Web Vitals report goes red.

I’d like to say that’s a lesson the industry has fully learned. It hasn’t. We still inherit sites built in 2024 with the same problems we’d inherit on sites built in 2014. Different plugins, same mistake.

Security stopped being opportunistic

The first hacked WordPress site I dealt with was in 2011. A friend of mine had multiple sites on the same shared host, and the lot of them got compromised in one go. The fix was the standard 2011 fix: clean install, restore from a backup that we hoped wasn’t itself infected, change every password twice, and hope for the best.

What’s changed isn’t really the vulnerabilities. The vulnerabilities of 2011 were honestly worse, in many cases. What’s changed is the scale and the professionalisation of the attacks.

In 2011, most WordPress hacks were opportunistic. Someone scanned a range of IPs for outdated installs and threw an exploit at whatever turned up. By 2016 or so, that had given way to industrial bot networks running 24/7, hammering login pages, scraping for known plugin vulnerabilities the day they were disclosed.

Today the threat model is different again. Targeted attacks on hosts with poor segmentation. Supply-chain compromises through abandoned plugins. AI-assisted phishing aimed at admin users. The bar for “secure WordPress site” has risen sharply in the last five years, and most of what passes for security at the cheap end of hosting was already inadequate before the bar moved.

If your site is on shared hosting and the only security you’ve got is a free plugin nobody’s configured properly, you’re running 2011’s defences against 2026’s attacks.

What’s been overhyped

Headless WordPress, mostly

Headless WordPress was the loudest noise of the late 2010s. The pitch: keep WordPress as the editor, build the front-end in React or similar, get a fast modern site that scales like a tech company’s. Conferences full of decks about it. Plenty of agency websites pivoting to sell it.

For specific situations, it does work. A large publisher with an in-house dev team, a global e-commerce operation with a budget for ongoing maintenance, a complex multi-platform content workflow. If that’s you, fine.

For the SMB sites we build, it’s been a headache machine. Two stacks to maintain instead of one. Plugins that work fine in standard WordPress break or behave unexpectedly. Client edits that previously took thirty seconds now require a developer. Hosting costs go up. Maintenance time goes up. The thing the client actually wanted, a fast and editable website, was achievable on standard WordPress with a tenth of the complexity.

I’ve watched headless go from “the future” to “the niche”, and that feels about right. The tooling has improved a lot. The cost-benefit for a UK SMB still doesn’t add up.

AI-generated websites

The current loudest noise. Wix’s AI builder, Hostinger’s AI tool, the “tell us about your business and we’ll build you a site” pitches that have flooded LinkedIn over the last 18 months. The output, to the untrained eye, almost passes. Click through ten of them in a row and the trick gives away. They all look like the same template with the brand colours swapped.

The specific caveats, in no particular order. The copy is generic and doesn’t sound like the business that owns the site. The layouts converge: every hero is the same hero, every “about” section is the same about section, every services grid is three boxes wide. Accessibility is patchy, because the AI doesn’t know which images need alt text or which heading levels matter. SEO patterns repeat across thousands of sites built on the same tool, which Google notices. And the platform lock-in is total: when you outgrow what the AI built, you don’t migrate it, you start over.

There’s a real use case for AI in website work. It’s not “generate me a website.” It’s “help me draft this paragraph faster” or “describe this image so I don’t have to write the alt text manually” or “summarise the analytics report.” The tools that work that way will stick around. The “AI built your whole site in 30 seconds” pitch will go the way of headless: useful for a niche, oversold for a generation.

The WordPress killer parade

Squarespace was going to kill WordPress. Then Wix. Then Webflow. Then Framer. Every two or three years a new platform launches with confident marketing about how it’s the WordPress replacement, the modern way, the future of the web. They build market share, they build noise, and then the noise fades and WordPress is still there.

I don’t have a strong opinion on whether Squarespace or Webflow is the right choice for a five-page brochure site. For some businesses, they probably are. The thing that gets missed in these arguments is that WordPress isn’t popular because it’s hyped or marketed well. It’s popular because it’s open source, because you own your site and your data outright, because the ecosystem of plugins and themes is twenty years deep, and because there are tens of thousands of developers in the UK alone who can pick up an existing WordPress site and continue the work. (Here’s our longer case for why we still build everything on WordPress if you want the agency-side version.)

That last point about developer-replaceability matters more than most of the others. The replaceability of a WordPress developer is a quiet competitive moat. If your Webflow developer disappears, the next developer needs to learn Webflow before they can help you. If your Squarespace developer disappears, you’ve got Squarespace’s support and not a lot else.

Platforms come and go. Standards stick around.

What hasn’t changed

The boring fundamentals still decide everything

Backups, updates, hosting choice, sensible plugin discipline, regular reviews. The boring stuff. The list hasn’t changed in 17 years and probably won’t change in the next 17.

What I’ve noticed is that the things that seem mundane or boring at the start of a project are exactly the things that turn into significant problems three years in, when they matter most. The decision to save £30 a month on hosting becomes the reason a site is unrecoverable when it gets hacked. The decision not to back up monthly becomes the reason eight years of content disappears overnight. The decision to install seventeen plugins because each one looked useful becomes the reason the site is slow, fragile, and impossible to update.

Get the foundations right at the start and most of the difficult problems never arrive. Get them wrong and you spend the next decade working around the consequences. The unglamorous category of where the boring fundamentals get done is roughly half the work we do, for exactly that reason.

Cheap is rarely good value

There’s an old adage in the trade. Cheap, quality, fast: pick two. It applies to website work as cleanly as it applies to anything else.

The cheapest WordPress builds, the cheapest hosting, the cheapest “developers” charging £200 for a five-page site on Fiverr, all read like a good proposition on the day you commission them. They almost never end up being good value. The hidden costs (maintenance you didn’t budget for, performance you can’t fix, security you can’t trust, the rebuild you’ll need in two years) add up to more than the proper job would have cost in the first place.

I’ve inherited dozens of these sites over the years. The conversation always goes the same way. The owner saved a few hundred pounds on the original build. They’ve now spent thousands fixing what came out of it, and they’re still going to need a proper rebuild. The original cheap quote turned out to be the most expensive route they could have taken.

This isn’t a sales pitch for premium pricing. There are good developers at every price point.

The bottom of the market is a different category of work, dressed up to look like the same one.

Owning the site you paid for

The single biggest reason WordPress has lasted is that it’s open source, and you own the site that’s built on it. The hosting is yours. The database is yours. The content is yours. The theme and the plugins are yours. If your developer disappears, you can hand the whole thing to the next one without asking permission from a platform.

Compare that to a Squarespace site, a Wix site, or a Shopify-as-a-CMS site. The platform owns the infrastructure, the platform sets the rules, and if the platform changes terms or pricing or features, you live with it. Most of the time that’s fine. The times when it isn’t are expensive.

For a UK business, this matters in concrete ways. UK GDPR liability sits with you, not the platform. If a platform makes a decision about data handling that creates a compliance problem for you, the platform’s terms aren’t going to absorb the regulatory risk. Owning your stack outright keeps the responsibility, and the control, in the right place.

Two things I’ve changed my mind on

I was wrong about security plugins

For most of the 2010s I’d install Wordfence or a similar security plugin on every client site as a matter of course. It seemed like the obvious answer: a security layer at the WordPress level, scanning for changes, blocking bad logins, alerting me when something looked off. We did this for years.

What I’ve come round to is that a heavyweight security plugin running on the WordPress side is fighting a battle that should already have been won at the host level. The plugin slows the site down. It adds its own attack surface (a security plugin with a vulnerability is a worse problem than no plugin at all). And the protection it offers is mostly redundant on a properly-managed host with a real WAF, brute-force protection, and segmented infrastructure.

I now build sites with no heavyweight security plugin and a competent host. The sites are faster, the maintenance burden is lower, and the security is genuinely better, not worse. Five years ago I’d have argued the opposite. The evidence kept disagreeing with me.

I was wrong to dismiss lightweight themes

For a long stretch, I was the developer who’d insist on building themes from scratch or starting from a barebones starter theme. I thought of off-the-shelf themes, even the lightweight ones, as compromises. They were for people who didn’t know how to build a theme properly.

I was wrong about that. Themes like GeneratePress, Astra, Kadence, and a handful of others have matured into genuinely solid foundations. They’re fast, they’re well-maintained, and they give you 90% of what a custom theme would give you in 10% of the time. The 10% you’d build custom usually isn’t worth the budget for an SMB site.

I still build custom themes for clients who genuinely need them. For most clients, a lightweight off-the-shelf theme plus the block editor plus careful customisation gets to the same place faster, cheaper, and with less long-term maintenance debt. The bit I had to swallow was that “I could build it from scratch” wasn’t a good reason to build it from scratch. Whether the client benefits is the question. Often, they don’t.

What this means for you in 2026

The short version: WordPress in 2026 is a content management system that can be as simple or as complex as you need it to be. A five-page brochure site for a tradesperson and a multi-region e-commerce platform can both run on it, and both can run well, if the foundations are right.

The longer version, which I’ll keep to one paragraph because we’re approaching essay length already: most of what determines whether your WordPress site does the job over the next decade isn’t WordPress itself. It’s the choices you make around it. The hosting that supports it. The theme it’s built on. The plugins you let onto it. The person or team that maintains it. The discipline of keeping it lean. WordPress gives you the platform. The rest is on you and whoever’s helping you.

If I had to leave a single takeaway for a UK business owner reading this, it would be that your website isn’t a fixed asset. It’s a working part of your business that needs the same kind of attention you’d give a vehicle, a piece of equipment, or a member of staff. Get the foundation right at the start, give it ongoing care, and it’ll keep doing its job for years. Skimp on either, and you’ll find yourself starting over within two.

A personal note

Seventeen years is a long time to do anything. WordPress has rewarded the time. It’s a craft that pays off when you stay with it, and the platform has stayed honest enough that the skills I built on that travel blog in 2008 still apply, with adjustments, in 2026. There aren’t many pieces of software I’d say that about.

If you’d like to read more about how we work at DevelopMyWeb, the about page covers it. Or if you’d rather get into the specifics of your own site (whether it’s one you’ve outgrown, one you’ve inherited, or one you’re thinking about commissioning), tell me about it and I’ll have a look. I’ll be honest about what I’d change and what I wouldn’t. Sometimes the right answer is “it’s fine, leave it alone for another year.” That answer’s free.