When WordPress is the right answer (and when it really isn't)

Quick answer: WordPress is the right call for content-led blog and editorial sites where multiple non-technical authors publish frequently, for some ecommerce sites running WooCommerce at modest scale, and for sites where a specific WordPress plugin is genuinely irreplaceable. For most premium marketing sites, web apps, and high-performance use cases, modern frameworks like Astro are a better fit.

We’re not anti-WordPress. We work on WordPress sites regularly — ours and other people’s — and we know its strengths well. We also build a meaningful portion of new client sites on non-WordPress stacks, and we want the reasoning here to be honest in both directions.

What WordPress genuinely does well

It’s worth being clear about WordPress’s real strengths before getting into where it doesn’t fit.

• The editing experience for non-technical authors. Twenty years of UX iteration. The block editor (Gutenberg) is now competent for content-led sites. Newsroom-style operations with multiple authors publishing daily are still hard to beat with WordPress.
• Plugin ecosystem. Tens of thousands of plugins for niche use cases. If your project has a specific requirement that one of them solves out of the box, the time saved is real.
• Talent availability. Easy to hire for, in most markets. Replacement risk is genuinely lower than on a niche stack.
• Familiarity for clients. Many clients have used WordPress before and feel comfortable with it. That’s a real advantage for adoption.
• Cost at small scale. Hosting and licences for a small WordPress site can be very low. For a brochure site that doesn’t need to do anything sophisticated, the total cost is hard to undercut.

These are real advantages and they’re why WordPress runs about 43% of the web.

Where WordPress is genuinely the right pick

Concretely, the projects where we’d default to WordPress include:

1. Content-led editorial sites with multiple non-technical authors. A site where 5+ authors are publishing daily or weekly, and the editing experience is the central operational concern. Block editor + custom blocks is genuinely strong for this.

2. Membership / community sites running on a mature WordPress plugin. Plugins like MemberPress, WooCommerce Memberships, BuddyBoss, or LearnDash represent thousands of person-hours of development. Replicating their functionality from scratch is rarely the right call.

3. Modest-scale ecommerce running on WooCommerce. Up to a few thousand products and meaningful but not large transaction volume. WooCommerce’s plugin ecosystem (subscriptions, product bundles, variable pricing) is broad in ways that more modern ecommerce frameworks haven’t fully matched.

4. Sites where a specific WordPress plugin is genuinely irreplaceable. The Events Calendar Pro for events. WP All Import for complex data feeds. Gravity Forms for sophisticated form logic. If the plugin solves your problem and replicating it would cost more than maintaining a WordPress site, the answer is WordPress.

5. Brochure sites where total cost is the dominant concern. A small business site with eight pages and no aspirations beyond “exists, looks reasonable, can be edited by the owner”. WordPress at $20–$50/month hosting plus a competent theme is hard to beat on raw cost.

Where WordPress is the wrong pick

The projects where we’d push hard against WordPress as the default:

1. Premium marketing sites where Core Web Vitals matter. Even well-tuned WordPress struggles to consistently match modern static-output frameworks for LCP and INP. If your competitors are on Astro, Next.js, or similar, the performance gap is visible to both users and Google.

2. Web applications. WordPress is a content management system. Once you’re building something with users who log in, multi-step workflows, complex business logic, or non-content data models, you’re fighting against the platform’s assumptions. We’ve rescued more than one project that started as “WordPress with a few custom plugins” and ended up as an unmaintainable mess.

3. Sites with high security requirements. WordPress is the most-attacked CMS on the web because it’s the most-used. The ecosystem of plugins is also a security surface. For sites handling sensitive data or operating in regulated industries, the attack surface is genuinely a concern.

4. High-traffic content sites with strong performance budgets. Achievable on WordPress with serious work (full-page caching, edge CDN, ruthless plugin discipline, custom themes), but the engineering investment to make WordPress fast at scale is comparable to building on a modern framework that’s fast by default.

5. Sites built around custom data models. WordPress fundamentally assumes “posts” with a few extension mechanisms. When your data is “projects, with team members, with deliverables, with stakeholders, with timelines”, the WordPress data layer becomes a constraint that fights you for years.

The plugin sprawl problem

The single most common WordPress failure mode we audit isn’t the platform itself — it’s the plugin stack on top.

A typical mid-life WordPress site:

• 25–40 active plugins
• 3–5 of which are page builders, theme frameworks, or visual editors
• 5–8 of which are SEO / analytics / performance plugins doing overlapping work
• A handful added for one specific need years ago and never removed
• One or two that are abandoned by their original developer

Each plugin is a security surface, a performance cost, a maintenance burden, and a potential conflict with the next plugin or the next WordPress core update. Sites in this state cost two to three times more to maintain than they should, run slower than they should, and break in ways that’d be impossible on a leaner architecture.

The fix isn’t to switch off WordPress — it’s to enforce plugin discipline ruthlessly. Most sites can run on 6–12 well-chosen plugins, with custom code replacing the rest.

The page builder trap

Elementor, Divi, WPBakery, Beaver Builder — the visual page builders.

They solve a real problem: enabling non-technical editors to create and adjust pages without involving a developer. That’s genuinely valuable.

What they cost:

• Bloated markup that hurts Core Web Vitals
• Lock-in to the builder — switching builders later is effectively a rebuild
• A learning curve that’s often steeper than just having a developer maintain a custom theme
• Performance overhead that no amount of caching fully removes
• Plugin compatibility issues when the builder updates

If editing flexibility is the genuine requirement, the modern alternative is a small set of well-designed custom blocks (using the native Gutenberg block editor, which is now competent enough) rather than a third-party page builder.

The honest decision criteria

A short version of the test we use:

• Is the site primarily about publishing content frequently, with multiple non-technical authors? WordPress.
• Is the site a brochure / marketing site for a premium brand where performance and design polish matter? Probably not WordPress.
• Is the site an application with users, workflows, and business logic? Definitely not WordPress.
• Is there a specific WordPress plugin doing something genuinely irreplaceable? Probably WordPress (with strict discipline).
• Is the dominant constraint cost? Probably WordPress — for a small enough scope.
• Does the site need to integrate deeply with a custom data model? Probably not WordPress.

The platform is genuinely good for the projects it’s good for. It’s not the universal default it’s often assumed to be.

Common questions

Is WordPress good for SEO? On its own, neutral. Out-of-the-box WordPress is fine for SEO; what makes or breaks ranking is content quality, technical performance, and link profile — none of which is platform-determined. Where WordPress hurts SEO is in performance: heavy themes, page builders, and plugin sprawl all compound to slower Core Web Vitals than a well-built modern alternative.

Is WordPress secure? Core WordPress is reasonably secure when kept current. Most WordPress security incidents come from outdated plugins, weak passwords, and abandoned plugins. Sites that maintain plugin discipline and update promptly have very few security issues. Sites that don’t are routinely compromised.

When should I move off WordPress? When the editing experience isn’t serving you anyway (you have one technical editor who could work in any system), when performance is a competitive disadvantage, when the plugin stack has become unmaintainable, or when the site is functionally an app rather than a content site. We’ve migrated several clients off WordPress to modern stacks for these reasons.

Is WordPress free? The software is open-source and free. Running it isn’t. Realistic costs include hosting ($20–$500/month), premium plugins ($200–$1,500/year typically), a theme or builder ($60–$500), and ongoing maintenance time or fees. Total cost over five years for a meaningful WordPress site is rarely under $10,000 and often substantially more.

Should I build my new business website on WordPress? If you’ll be publishing content frequently, have non-technical authors, and don’t need premium-brand performance — possibly yes. If you want a fast, polished marketing site you’ll edit infrequently — probably not. We default new builds to Astro for marketing sites and reach for WordPress when the editing requirement specifically demands it.

If you’re weighing the right platform for a specific project, start a project and we’ll give you a straight answer based on the use case — including “use WordPress” when that’s genuinely what fits.