WordPress Isn’t the Problem. Your WordPress Setup Is.

Open LinkedIn right now and you’ll see it. “WordPress is dead.” “Time to move on.” “It’s a security nightmare.” Every week there’s a new post from someone who’s just discovered that modern frameworks exist and feels the need to announce the death of WordPress.

I build with WordPress. I also build with Astro, Next.js, and other modern frameworks. And here’s what nobody on LinkedIn seems to want to say - WordPress done properly is still a genuinely good platform. WordPress done badly is a liability.

The problem is that most WordPress builds are done badly.

The WordPress Everyone’s Rightfully Criticising

Let’s be honest about what gives WordPress its reputation. Because the criticism isn’t coming from nowhere.

The Elementor problem. A typical Elementor page generates hundreds of unnecessary wrapper divs. Every single widget gets wrapped in two container elements - an outer and inner div - and that multiplies across the entire page. On the frontend, Elementor adds 200-400kb of extra CSS and JavaScript to every page load, regardless of which widgets you’re actually using. Before you’ve added a single line of content, Elementor adds a baseline 40ms drag to every page load.

Elementor sites regularly fail Google’s Core Web Vitals out of the box - mobile LCP well above the 2.5-second “good” threshold is common. You’re fighting an uphill battle before you’ve even started optimising.

And it’s not just Elementor. Divi, WPBakery, Beaver Builder - they all share the same fundamental problem. Page builders generate bloated markup because they have to account for every possible layout combination. A developer writing clean HTML and CSS will always produce leaner output because they’re solving one specific problem, not every possible problem.

The plugin soup problem. I’ve audited WordPress sites running 40+ plugins. Contact form plugin, SEO plugin, security plugin, caching plugin, image optimisation plugin, social sharing plugin, related posts plugin, popup plugin, slider plugin, backup plugin, analytics plugin, cookie consent plugin - and then another 28 that someone installed three years ago and forgot about.

Every plugin is a potential security vulnerability. Every plugin adds database queries, HTTP requests, and JavaScript. Every plugin is maintained by a different developer with different priorities and different update schedules.

In 2025, 11,334 new vulnerabilities were discovered in the WordPress ecosystem. That’s a 42% increase over 2024. And 91% of those vulnerabilities were in plugins - not WordPress core. 46% were unpatched at the time of disclosure. The median time from vulnerability disclosure to first exploitation? Five hours.

Five hours. That’s how long it takes for an attacker to weaponise a plugin vulnerability after it’s publicly known.

The maintenance problem. The worst WordPress sites I’ve inherited aren’t bad because of the platform. They’re bad because nobody’s looked at them since launch. WordPress core hasn’t been updated in two years. Plugins are running versions with known vulnerabilities. The PHP version is end-of-life. There’s no caching. There’s no WAF. WordPress requires maintenance. That’s not a flaw - it’s the reality of running a dynamic application. But most businesses treat their website like a set-and-forget appliance, and WordPress punishes that neglect harder than most platforms.

What a Proper WordPress Build Actually Looks Like

Here’s what I actually use when I build a WordPress site.

Custom theme built on _tw. That’s Underscores with Tailwind CSS. No theme framework. No parent theme with 300 features I don’t need. Just a starter theme that gives me clean markup and a utility-first CSS framework. Every line of HTML is intentional. Every style is written for this specific site.

ACF Pro for content structure. Advanced Custom Fields lets me build structured content models without touching a page builder. Custom field groups, flexible content layouts, repeater fields - all managed through clean PHP templates. The client gets a straightforward editing experience in the dashboard. I get clean, predictable data to work with in my templates.

No drag-and-drop. No visual editors generating wrapper soup. The developer controls the markup. The client controls the content. That’s the right separation.

Minimal, intentional plugins. Here’s what a typical build looks like for me:

• ACF Pro -> structured content fields and custom blocks
• Yoast SEO -> SEO fundamentals, schema markup, sitemaps
• LiteSpeed Cache -> server-level caching and optimisation
• Gravity Forms -> when the project needs proper form handling
• SMTP2Go -> reliable email delivery
• WordPress Performance Lab -> WebP uploads, image prioritisation, speculation rules

That’s typically 6-8 plugins total. Not 40. Each one is there for a specific reason. Each one is actively maintained. Each one is updated regularly.

Performance-first WordPress. With a custom theme and minimal plugins, a WordPress site can genuinely perform well. I’m talking sub-2-second load times, passing Core Web Vitals, clean Lighthouse scores. Not “fast for WordPress” - actually fast.

The difference between a 5-second Elementor site and a 1.5-second custom theme is the same platform. Same database. Same PHP. Same hosting. The difference is the code sitting on top of it.

The Security Reality

WordPress powers 43% of all websites. That makes it the biggest target on the internet. But “WordPress gets hacked” is like saying “cars get into accidents” - it’s true, but it’s not the whole story.

WordPress core accounted for a tiny fraction of those vulnerabilities. The core software is actively maintained by a professional team and gets regular security patches.

The vulnerabilities are in plugins. Specifically, in poorly maintained plugins by small developers who may or may not respond when a vulnerability is found. That’s a real problem, but it’s a solvable one.

How to build secure WordPress:

• Use fewer plugins, and only well-maintained ones
• Keep everything updated - core, plugins, themes, PHP
• Use a WAF (Cloudflare, Wordfence, or your host’s WAF)
• Strong passwords and two-factor authentication
• Limit login attempts
• Regular backups stored offsite
• File permissions locked down
• XML-RPC disabled if you don’t need it

None of this is revolutionary. It’s just due diligence that most WordPress sites don’t get.

When WordPress Is the Right Choice

WordPress still makes sense for a lot of projects. Specifically:

When the client needs to manage content independently. WordPress has the most familiar CMS interface in the world. Clients know it. They’ve used it before. They can log in, edit a page, add a blog post, and update their phone number without calling a developer.

Headless CMS platforms like Sanity and Payload are excellent tools - genuinely great developer experience and content modelling. But they come with a higher upfront build cost because you’re building from scratch. For a small business owner who just wants to change their opening hours, WordPress wins through pure familiarity and a lower initial investment.

When the project needs WooCommerce. For e-commerce on a budget, WooCommerce is still extremely capable. Thousands of payment gateways, shipping integrations, tax calculations. The ecosystem is massive.

When maintenance is accounted for. If the client is on a maintenance plan - monthly updates, security monitoring, backups, performance checks - WordPress is a reliable platform. The problems come when maintenance stops.

When budget is a constraint. A custom WordPress site is typically faster and cheaper to deliver than a custom framework application with a headless CMS. Not because the modern tools are worse - they’re often better - but because the build takes longer when you’re starting from scratch. The WordPress tooling is mature, the developer pool is massive, and the hosting is straightforward.

When Modern Frameworks Are Genuinely Better

Here’s the honest part. For certain projects, WordPress isn’t the right tool anymore.

My own site runs on Astro. Static HTML output. Near-zero JavaScript. Perfect Lighthouse scores without trying. No database, no PHP, no admin panel to secure. The attack surface is essentially zero. It deploys to Cloudflare Pages and loads in under a second globally.

I don’t need WordPress for my portfolio and blog. I manage the content in Markdown files, push to GitHub, and Cloudflare builds and deploys it automatically. There’s nothing to hack because there’s nothing dynamic to exploit.

When to reach for Astro, Next.js, or similar:

• Sites where a developer manages the content (portfolios, blogs, documentation)
• Projects where performance is the primary concern
• Clients with a bigger budget who want best-in-class performance and security
• Marketing sites and landing pages where speed directly impacts conversion

The hybrid approach. Here’s where it gets interesting. You can use WordPress as a headless CMS - keep the familiar editing interface, but use Astro or Next.js to generate the frontend. Best of both worlds. Clients edit in WordPress. The site renders as static HTML. Performance and security of a modern framework with the editing experience of WordPress.

Other headless CMS options like Sanity and Strapi are purpose-built for this workflow and often fit better than headless WordPress, but the concept is the same - separate the content management from the frontend rendering.

The Matt Mullenweg Situation

You can’t write about WordPress in 2026 without mentioning the elephant in the room.

The Mullenweg vs WP Engine drama has genuinely shaken the WordPress community. Blocking WP Engine’s access to WordPress.org, removing contributor accounts, the ongoing lawsuit - it’s exposed real governance concerns about a platform used by nearly half the internet being controlled by one person.

This isn’t a reason to abandon WordPress today. But it is a reason to pay attention. The ecosystem’s long-term stability matters when you’re building on it.

What I Tell Clients

When someone asks me “should we use WordPress?”, my answer depends on four things:

1. Who’s managing the content? If the client needs to update the site regularly without developer involvement, WordPress is usually the right call. If a developer is managing content, modern frameworks are leaner.

2. What’s the maintenance plan? If there’s budget for ongoing maintenance - updates, security, backups - WordPress is fine. If the site is going to be launched and left alone for three years, WordPress will become a liability.

3. What’s the performance target? A well-built WordPress site can hit sub-2-second load times. But if the target is sub-1-second with perfect Core Web Vitals, a static framework will get there with less effort.

4. What’s the budget? A custom WordPress build is typically more cost-effective for content-heavy sites. A modern framework build has lower ongoing costs but higher upfront development investment.

The Bottom Line

WordPress isn’t dying. It’s not dead. It’s not inherently insecure or slow. It’s a mature platform that works extremely well when built properly and maintained consistently.

The WordPress that people are criticising on LinkedIn - the Elementor builds with 40 plugins and no maintenance plan - deserves the criticism. That’s not WordPress. That’s negligence.

A custom theme, ACF Pro, minimal plugins, and a proper maintenance plan produces a site that’s fast, secure, and easy for clients to manage. I build these regularly and they perform well.

But I also build with Astro, Next.js, Vue, and many more modern frameworks - and for the right projects, they’re objectively better. Faster, more secure, simpler to maintain.

The platform isn’t the problem. The approach is. A well-built WordPress site will outperform a badly built React app every time. And vice versa.

Stop arguing about tools. Start asking whether they’re being used properly.