WordPress powers 43% of the web. We build WordPress sites. We've built hundreds of them over 25 years. And sometimes the right answer to "Should we use WordPress?" is no.
That's a strange thing for a web development consultancy to say out loud, especially one that lists WordPress as a core competency. But we've watched too many projects struggle because someone chose WordPress by default rather than by analysis. The platform has real limitations, and pretending otherwise wastes time and money.
The Default Choice Problem
WordPress became the default CMS sometime around 2012. It was free, it was everywhere, and every developer knew it. Need a website? WordPress. Need a blog? WordPress. Need an online store? WordPress plus WooCommerce. Need a web application with user accounts, real-time data, and a mobile app pulling from the same content? Still WordPress, somehow, with 40 plugins holding it together.
That default thinking persists. According to W3Techs, WordPress holds roughly 43% of the entire web as of early 2026 and about 60% of the CMS market. Those numbers are staggering, but they obscure something: a significant portion of those installations are abandoned sites, half-finished projects, and blogs that haven't been updated since 2018. Popularity doesn't mean suitability.
We audit sites constantly where WordPress was chosen because the agency only knew WordPress, or the business owner had heard of it, or some article from 2015 said it was the best option. Nobody stopped to ask whether the project actually needed what WordPress offers, or whether it could handle what the project demanded.
Here's where it falls apart.
Where WordPress Genuinely Struggles
Performance Overhead You Can't Fully Escape
WordPress is a PHP application backed by a MySQL database. Every page request triggers PHP execution and at least one database query. On a well-configured managed host like WP Engine or Kinsta, this happens fast enough that most visitors won't notice. But "fast enough" and "fast" are different things.
The median web page in 2025 weighed 2.86 MB on desktop according to HTTP Archive data. A typical WordPress site we audit lands between 3 and 5 MB, and sites running page builders push well past that. We've written extensively about what page builders cost you in terms of DOM bloat and JavaScript overhead. But even a clean, custom-coded WordPress site carries baseline weight: the WordPress core JavaScript, jQuery (still loaded by default), admin bar assets for logged-in users, and database queries for options, menus, widgets, and sidebars that fire on every request.
Caching solves much of this. A properly configured caching plugin or server-level cache serves static HTML to most visitors, bypassing PHP and MySQL entirely. But that caching layer adds complexity, sometimes breaks for logged-in users or dynamic content, and represents a workaround for a problem that static sites and modern frameworks simply don't have.
Sites built with Astro, Next.js, or plain HTML ship exactly what the page needs. Nothing more. No PHP runtime. No database query overhead. No jQuery shim.
Security Is a Full-Time Job
The security numbers are hard to ignore. Patchstack reported nearly 8,000 new WordPress vulnerabilities discovered in 2024 alone, a 34% increase over the previous year. Here's the part that matters: 96% of those came from third-party plugins. WordPress core is reasonably secure. The problem is that nobody runs WordPress core by itself.
A mid-sized business WordPress site typically runs 20 to 30 plugins. Each plugin is a dependency maintained by a different developer or team, with different update schedules, different security practices, and different incentives to keep maintaining the code. Patchstack found that 1,614 plugins were removed from the WordPress repository in 2024 due to security issues. Over half of reported vulnerabilities weren't patched before public disclosure.
Compare that to a static site, a Webflow site, or a headless CMS. The attack surface shrinks dramatically when there's no server-side application layer exposed to the internet. No PHP execution means no PHP exploits. No plugin directory means no abandoned plugin with an unpatched SQL injection flaw.
If you don't have a maintenance plan that includes weekly plugin updates, regular security scanning, and a response plan for when something goes wrong, WordPress becomes a liability. And most businesses we talk to don't have any of that. They launch, forget, and hope for the best.
The Plugin Dependency Spiral
This connects directly to what we see in Core Web Vitals audits. Every plugin adds PHP execution time, JavaScript, CSS, and database queries. Performance degrades gradually, so nobody notices until Google does.
A contact form needs a plugin. SEO metadata needs a plugin. Image compression, caching, backups, security scanning, redirection, schema markup, custom fields, WooCommerce, and whatever add-ons WooCommerce needs. Each one is reasonable on its own. Together they create a tower of dependencies where updating one plugin can break three others.
We regularly see WordPress sites with 30 or more active plugins. The same functionality on a custom build requires maybe eight to twelve, because most of those "features" are just compensating for what WordPress doesn't do natively or what other plugins broke.
Content Modelling Hits a Wall
WordPress was designed for blog posts. Its content model is: a title, a body, a date, and some categories. Advanced Custom Fields (ACF) extends this brilliantly, and we use ACF on nearly every WordPress project. But at a certain level of content complexity, you're building a custom data layer on top of a system that was never designed for one.
Consider a product catalogue with 50 fields per product, variants, relationships to other products, multi-language content, and content that needs to render on a website, a mobile app, and a digital kiosk. WordPress can do this. It will feel like pushing a boulder uphill the entire time.
Headless CMS platforms like Sanity, Strapi, or Contentful were built from scratch for exactly this kind of structured content. They treat content as data, not as "posts," and they deliver it through APIs that any front end can consume. The editing experience is cleaner, the data model is flexible, and the content isn't locked to a single rendering layer.
The best platform for your project is the one that fits your content model, your team's skills, and your growth plans. Not the one with the biggest market share.
Multi-Platform Delivery Is Painful
If your content only lives on a website, WordPress works fine. The moment you need that same content on a mobile app, a smart display, or piped into a third-party system, WordPress becomes the bottleneck.
WordPress does have a REST API, and it works. You can run WordPress as a headless CMS with a React or Next.js front end. We've done it. But the REST API wasn't designed as the primary content delivery mechanism. It was added to WordPress core in version 4.7 as an afterthought, and it shows. Response times are slower than purpose-built content APIs, the data format includes a lot of WordPress-specific overhead, and you still need to maintain the entire WordPress backend just to serve JSON.
If multi-platform content delivery is a core requirement from day one, a headless CMS built for that purpose will save you months of workaround engineering.
What to Use Instead (And When)
We don't recommend alternatives because they're trendier. We recommend them when they genuinely fit the project better. Here's a straightforward breakdown.
Webflow: When Your Team Needs Visual Control
Webflow is a visual web builder with built-in hosting, a CDN, and clean code output. Unlike WordPress page builders that generate bloated HTML, Webflow produces reasonably clean markup and ships with performance features that WordPress requires plugins to match.
Marketing teams that need to launch and update landing pages without a developer on retainer are Webflow's sweet spot. One agency we know reduced their average page load time from 4.3 seconds on WordPress to 1.2 seconds on Webflow by moving a client's marketing site across. That's not a Webflow advertisement; it's what happens when you remove the PHP/MySQL layer and the plugin stack.
Where Webflow falls short: complex e-commerce, heavy custom logic, content with more than a few dozen fields per type, and sites with thousands of pages. Webflow's CMS has a 10,000-item limit per collection. And you're locked into their hosting, their pricing tiers, and their platform roadmap.
Headless CMS + Modern Front End: When Content Needs to Go Everywhere
If you need content on a website, a mobile app, and a third-party integration, a headless CMS paired with a front-end framework like Next.js or Astro is the right architecture.
Sanity offers real-time collaboration and a completely customisable editing experience. Strapi is open-source and self-hosted, giving you full control over your data. Contentful is mature and enterprise-grade with strong multi-language support.
The trade-off is complexity. You need a developer who understands API-driven architecture. You need separate hosting for the front end and the CMS. The cost of development is higher up front, and content editors lose the "what you see is what you get" preview that WordPress provides out of the box.
For businesses with structured content, multiple output channels, or plans to scale well beyond a marketing website, this trade-off pays for itself within the first year.
Static Site Generators: When Speed Is Everything
If your site is mostly content that doesn't change daily, a static site generator like Astro, Hugo, or Eleventy will outperform WordPress by a wide margin on every speed metric. There's no server-side processing. Every page is pre-built HTML. Load times routinely come in under one second.
We build static sites for clients where performance directly affects revenue: landing pages where every millisecond of load time affects conversion rates, and content sites where strong Core Web Vitals scores are essential for search ranking.
The limitation is interactivity. Static sites can include JavaScript for dynamic features, but if you need user accounts, real-time data, or complex forms with server processing, a static site alone won't cover it. Pair it with a headless CMS and serverless functions and the gap closes.
Custom Application: When Nothing Off the Shelf Fits
Sometimes the answer isn't a CMS at all. If you're building a booking system, a client portal, a SaaS product, or anything where the website is the product rather than a brochure for the product, you need a custom application. React, Next.js, Laravel, Django, or whatever fits the team and the requirements.
WordPress in this scenario becomes a liability. We've been hired to rescue projects where someone tried to build a full web application inside WordPress using eight plugins and custom PHP hacked into a theme. The rebuild always costs more than building it properly would have from the start.
When WordPress Is the Wrong Call
- Your content needs to render on more than just a website (mobile apps, kiosks, third-party feeds)
- You have no maintenance plan for weekly plugin updates and security monitoring
- Your site requires complex, structured content with dozens of fields and relationships
- Performance is a primary business requirement, not just a nice-to-have
- You're building a web application, not a content website
- Your team needs to make frequent design changes without touching code (consider Webflow)
- Your plugin count has passed 25 and keeps climbing
- You've already spent thousands trying to make WordPress perform well enough
If three or more of these apply, WordPress is costing you more than it's worth. Talk to us about what the right platform looks like for your project.
When WordPress Is Still the Right Answer
We're not here to bury WordPress. We install it almost every week. It's the right choice more often than it isn't, and writing it off entirely would be as foolish as recommending it for everything.
WordPress wins when you need a content-heavy website with a familiar editing experience, a mature plugin for nearly any feature, thousands of available developers if you ever need to switch teams, and a low barrier for content editors who aren't technical. A 30-page business website with a blog, some custom post types through ACF, and a contact form? WordPress, all day. An online store with under 500 products and straightforward shipping? WooCommerce handles it well, especially on managed hosting.
The critical variable isn't the platform. It's how it's built. A WordPress site with a clean custom theme, minimal plugins, proper caching, and a maintenance plan will outperform a badly configured Webflow site or a neglected Next.js deployment. We've written about how the CMS choice affects long-term costs, and the same principle applies here: the implementation matters more than the label on the box.
The businesses that get burned aren't the ones who chose WordPress. They're the ones who chose WordPress without asking whether it was the right fit, or hired someone who only knew one tool.
We'd rather lose a WordPress project than build something we know will cause problems in two years. That's not altruism. Clients who get the right recommendation the first time come back. Clients who inherit a mess don't.
Sources
- W3Techs — Usage Statistics and Market Share of WordPress, February 2026 — WordPress market share data: 42.8-43% of all websites, ~60% of CMS market
- HTTP Archive — Page Weight, 2025 Web Almanac — Median page weight: 2.86 MB desktop, 2.56 MB mobile across all sites
- HTTP Archive — CMS, 2025 Web Almanac — WordPress median page weight of 2,894 KB and CMS performance comparisons
- Patchstack — State of WordPress Security in 2025 — 7,966 new WordPress vulnerabilities in 2024, 96% from plugins, 34% year-over-year increase, 1,614 plugins removed
- web.dev — Interaction to Next Paint (INP) — Google's Core Web Vital for responsiveness, replacing FID in March 2024, 200ms threshold
- HTTP Archive — Performance, 2025 Web Almanac — Core Web Vitals pass rates: 48% mobile, 56% desktop in 2025
- WordPress REST API Handbook — REST API added to WordPress core in version 4.7, request/response documentation
- Webflow vs WordPress: An Expert's Honest Review — N4 Studio — Performance comparison data, including migration case studies showing load time improvements