Why We Don't Recommend WordPress

Last year a client asked us to "fix" their WordPress site. It was slow, they said. A few seconds too many.

When we opened it, we found 47 active plugins. Forty-seven. One for cookies, one for SEO, one for forms, one for cache, one to optimize images, one for backup, three for security that were probably stepping on each other's toes, and at least a dozen whose purpose nobody remembered anymore. The theme was a premium with 200 included templates of which they used one, with a page builder generating markup worthy of a Lovecraftian nightmare.

Load time? Eight seconds. On fiber.

We spent three days cleaning up, optimizing, disabling useless plugins, replacing essential ones with lighter alternatives. In the end we got it down to three seconds, which is still mediocre but at least doesn't scare everyone away. The client was thrilled. We were less so, because we knew in six months we'd be back doing the same thing.

This isn't an isolated case. It's the norm.

WordPress was born in 2003 as a blogging platform. Simple, elegant, it did one thing and did it well. Then it became "the CMS that does everything" and that's where the problems started. Because when a tool tries to do everything, it ends up doing everything poorly, and the gap is filled by an ecosystem of plugins that nobody really controls.

The result is that today 43% of the web runs on WordPress, but a good portion of that 43% are overloaded, slow, vulnerable, and expensive-to-maintain sites. Not because WordPress is inherently bad—the core is reasonable—but because the way it's used in practice is almost always wrong.

The security problem is what concerns us most. WordPress is the most attacked CMS in the world, and not by accident: it's a huge and predictable target. Malicious actors know exactly where to look, which plugins have known vulnerabilities, which default configurations are weak. Sucuri reports that in 2024 over 96% of compromised CMS sites were WordPress. Sure, it's also the most widespread, so the statistic is partly obvious. But the point remains: if you don't update everything constantly, if you don't monitor, if you don't have someone who knows what they're doing, you're exposed.

And here's the paradox. WordPress is sold as "easy," the solution for those who don't want to think about technology. But a WordPress site left to itself becomes a sieve within a few months. The initial ease is paid for with operational complexity over time.

Then there's the performance question, which for us is almost an obsession. A slow site loses users, loses conversions, loses Google ranking. These aren't opinions, they're data: every extra second of load time corresponds to a measurable percentage of abandonment.

The problem is that WordPress, in its typical configuration, is structurally slow. The average premium theme includes thousands of lines of CSS and JavaScript you'll never use. The page builder generates infinitely nested DOMs. Every plugin adds its queries to the database, its scripts, its styles. And in the end you have an 8 MB site that needs to make 200 HTTP requests to show a homepage with three paragraphs of text and an image.

Yes, caching plugins exist. CDNs exist. Optimizations exist. But it's like putting a turbo on a car with square wheels: it improves, but the fundamental problem remains.

We're not dogmatic. WordPress makes sense in some specific cases: very limited budget with internal skills for maintenance, pure blogs without performance pretensions, quick prototypes to validate ideas, situations where you need specific plugins that don't exist elsewhere. In these cases, fine, use it.

But for the average business site, for e-commerce that needs to convert, for a web app that needs to scale? There are better alternatives. Static sites generated with Astro or Hugo for those with content that rarely changes: fast, secure, practically free to host. Headless CMS like Payload or Strapi coupled with modern frontends for those who want flexibility without WordPress's baggage. Custom development for those with specific needs that no CMS can really satisfy.

Do they cost more initially? Sometimes yes. But the total cost over time—maintenance, security, performance, and frustration—is almost always lower.

When a client asks us for a WordPress site, the first thing we do is ask why. The most common answers are "because everyone uses it" and "because then I can edit it myself." The first isn't a reason. The second is often an illusion: how many clients actually edit their own site after launch? And those who do usually create disasters that need to be fixed.

We prefer to propose the right solution for the specific problem. Sometimes it's WordPress. More often not.

If you're evaluating a web project and want to understand which technology makes sense for your case, let's talk. No prejudice, just an honest analysis of what you really need.

HAVE A PROJECT?