Every year, someone publishes an article declaring WordPress dead. Every year, WordPress powers more of the internet than it did the year before. As of January 2024, WordPress runs 43.1% of all websites, up from 39.5% two years ago. The gap between WordPress and the second-place CMS (Shopify at 4.4%) is not closing. It is widening.

But market share alone does not make WordPress the right choice. Plenty of technologies dominate through inertia rather than merit. The real question is whether WordPress, in its current state in 2024, is the right technical choice for a business building or rebuilding its web presence. At Harbor Software, we build with WordPress every day, and we also build with Next.js, headless CMSes, and custom stacks. We have a clear-eyed view of where WordPress excels and where it does not. Here is our honest assessment.

The Total Cost of Ownership Argument

Total cost of ownership (TCO) is where WordPress wins most decisively, and it is the metric that matters most for businesses that are not venture-funded tech startups. TCO includes not just initial development cost but ongoing hosting, maintenance, content management labor, plugin licensing, and the eventual cost of redesigns and migrations.

Consider a mid-market e-commerce site with 500-2,000 products, a blog, landing pages for marketing campaigns, and integration with an ERP system. Here is what the first-year TCO looks like across three approaches:

WordPress + WooCommerce:

• Hosting (managed WordPress, e.g., Cloudways): $50-150/month ($600-1,800/year)
• Theme + page builder (Elementor Pro or similar): $59-199/year
• Essential plugins (SEO, security, caching, backups): $200-500/year
• WooCommerce extensions (payments, shipping, inventory): $300-800/year
• Custom development (integration, custom features): 200-400 hours at $100/hour
• Content management training: 4-8 hours (WordPress admin is familiar to most marketers)

Custom Next.js + headless CMS:

• Hosting (Vercel Pro + database + CDN): $100-400/month ($1,200-4,800/year)
• Headless CMS (Sanity, Contentful, or similar): $99-499/month ($1,188-5,988/year)
• Custom development: 600-1,200 hours at $100/hour (no prebuilt e-commerce, no plugin ecosystem, everything from scratch)
• Payment integration (Stripe or custom): 80-160 hours
• Content management training: 20-40 hours (custom UI, fewer conventions, steeper learning curve)

Shopify Plus:

• Platform fee: $2,000/month minimum ($24,000/year)
• Theme customization: 100-200 hours
• App subscriptions: $200-800/month ($2,400-9,600/year)
• Transaction fees: 0.15-0.5% per transaction (adds up fast at scale)
• Custom development for non-standard flows: 100-300 hours

For the WordPress path, total first-year cost with a 200-hour custom development budget at $100/hour is roughly $22,000-$26,000. The Next.js path, with 800 hours of development, runs $85,000-$95,000. Shopify Plus starts at $30,000 in platform fees alone before any customization. These are real numbers from real projects, not theoretical estimates.

These numbers shift at different scales. For a 50,000-SKU catalog with complex pricing rules, Shopify or a custom solution might be more cost-effective because WooCommerce’s database architecture struggles at that scale. But for the vast majority of businesses, the 90% of businesses with web presences that have fewer than 5,000 products and fewer than 1,000 orders per day, WordPress’s TCO advantage is substantial and real.

The Plugin Ecosystem Is a Superpower (With Caveats)

WordPress has over 59,000 free plugins in the official repository and thousands more premium plugins sold through marketplaces like CodeCanyon, independent vendor sites, and WooCommerce.com. This ecosystem means that for most business requirements, a tested, maintained solution already exists. You are not building from scratch; you are assembling from proven components.

The practical impact is dramatic. A client says: “We need to add a booking system.” In WordPress, you evaluate three or four booking plugins (Amelia, BookingPress, Simply Schedule Appointments), install the best fit, configure it, and customize the styling. That is 8-16 hours of work. In a custom stack, you are designing a database schema, building a calendar UI from scratch, handling timezone conversions for international users, implementing conflict detection to prevent double-bookings, sending confirmation emails with proper templating, and integrating with payment processing for deposits. That is 200-400 hours of work for a feature the client considers simple and expects to be done quickly.

The caveats are important and often overlooked by WordPress advocates. Not all plugins are created equal. We maintain an internal list of approved plugins that we trust in production environments. The evaluation criteria are strict:

• Active development – Last update within 60 days. A plugin that has not been updated in 6 months is a security risk.
• User base – Minimum 10,000 active installations. Below this threshold, the plugin may not survive its developer losing interest.
• Review quality – Not just star rating; we read the 1-star and 2-star reviews to understand failure modes, compatibility issues, and how the developer responds to problems.
• Code quality – We read the source code for any plugin that handles sensitive data (forms, payments, authentication, user data). We have rejected plugins with 5-star ratings because their code stored passwords in plaintext or made unescaped database queries.
• Performance impact – We profile the site before and after plugin installation using Query Monitor and Chrome DevTools. Any plugin that adds more than 200ms to page load time needs a strong justification for inclusion.
• Conflict potential – We test against our standard plugin stack for JavaScript conflicts, CSS overrides, and database table collisions. Some plugins are excellent in isolation but break when combined with specific other plugins.

About 15% of plugins we evaluate pass all these criteria. The other 85% are rejected for legitimate reasons. The plugin ecosystem is a superpower if you curate it with discipline. If you install everything that looks useful, you end up with a slow, fragile, unmaintainable site that breaks every time you update WordPress core. That is not WordPress’s fault; it is a curation failure that the agency or site owner must take responsibility for.

Performance Is Solvable, Not Automatic

The biggest legitimate criticism of WordPress is performance. A default WordPress installation with a commercial theme and 15 plugins will produce a homepage that scores 35-45 on Google PageSpeed Insights. That is unacceptable for any business that cares about search rankings or user experience, and it is the first thing competitors point to when arguing against WordPress.

But “default WordPress is slow” is like saying “default code is buggy.” The default is not the ceiling; it is the floor. With proper optimization, WordPress sites consistently achieve 85-95+ PageSpeed scores. Here is the optimization stack we deploy on every production WordPress site:

# Performance stack
1. LiteSpeed Cache (page caching + browser caching + CDN integration)
2. ShortPixel or Imagify (image compression + WebP/AVIF conversion)
3. Asset CleanUp (remove unused CSS/JS per page)
4. Cloudflare (CDN + DNS + DDoS protection + Brotli compression)
5. Redis object caching (via hosting provider, reduces database queries by 40-60%)
6. Database optimization (WP-Optimize, scheduled weekly cleanup of revisions, transients, and orphaned metadata)

# Server requirements
- PHP 8.2+ (30-40% faster than PHP 7.4 for WordPress workloads)
- MariaDB 10.6+ or MySQL 8.0+ (improved query optimizer)
- OPcache enabled with 256MB allocation (caches compiled PHP bytecode)
- Gzip/Brotli compression at server level (not plugin level)
- HTTP/2 or HTTP/3 (QUIC) support for multiplexed asset loading

With this stack, our WordPress sites achieve the following benchmarks on a $50/month Cloudways server running on DigitalOcean infrastructure:

• Time to First Byte (TTFB): 180-350ms for cached pages, 500-800ms for uncached dynamic pages
• Largest Contentful Paint (LCP): 1.2-2.1 seconds, well within Google’s “good” threshold of 2.5 seconds
• Cumulative Layout Shift (CLS): under 0.05, effectively zero visual instability
• First Input Delay (FID): under 50ms, imperceptible to users
• Total page weight: 800KB-1.5MB including all images, CSS, JavaScript, and fonts

These numbers compete with static site generators for the pages that matter most: the homepage, product pages, and landing pages that drive conversions. They are not as fast as a pure static HTML site served from a CDN edge (which achieves 20-50ms TTFB), but they are fast enough that users cannot perceive the difference. Research from Google consistently shows that users notice latency above 100ms and experience frustration above 1 second. Our optimized WordPress sites land well within the acceptable range.

The key insight is that performance optimization is a one-time setup cost, not an ongoing burden. You configure the caching stack once, tune the server settings, optimize the image pipeline, and it works for every page on the site from that point forward. New pages and new content inherit the optimization automatically.

Where WordPress genuinely struggles with performance is on highly dynamic pages that cannot be cached. A WooCommerce checkout page with real-time shipping calculations, tax lookups based on customer location, and coupon validation cannot be cached because every user sees different content. These pages must execute PHP on every request. For these pages, server quality matters more than caching configuration. An uncached WooCommerce checkout on a $5/month shared host will be noticeably slow, sometimes 3-5 seconds. On a $50/month VPS with proper PHP-FPM tuning and Redis object caching, the same checkout loads in under a second.

Security Is a Process, Not a Product

WordPress is the most targeted CMS on the internet because it is the most popular CMS on the internet. Roughly 4.7 million WordPress sites were compromised in 2023, according to Sucuri’s annual report. That sounds terrifying until you consider that over 800 million sites run WordPress. The compromise rate is under 0.6%, and the vast majority of compromised sites were running outdated software with weak administrator passwords on shared hosting with no security hardening.

Our security baseline for every WordPress site we manage is straightforward and non-negotiable:

# wp-config.php security constants
define('DISALLOW_FILE_EDIT', true);        // No editing PHP files in admin panel
define('DISALLOW_FILE_MODS', true);        // No plugin/theme installs from admin
define('FORCE_SSL_ADMIN', true);           // HTTPS-only admin access
define('WP_AUTO_UPDATE_CORE', 'minor');    // Auto-update minor security releases

# .htaccess rules (Apache) or nginx configuration
- Block xmlrpc.php entirely (unless using Jetpack or mobile apps)
- Restrict wp-admin access by IP range (for teams with fixed IPs)
- Disable directory listing and server signature
- Add security headers: X-Frame-Options SAMEORIGIN,
  X-Content-Type-Options nosniff, Content-Security-Policy,
  Referrer-Policy strict-origin-when-cross-origin,
  Permissions-Policy with restrictive defaults

# Operational practices enforced on every site
- All admin accounts use 24+ character passwords generated by 1Password
- Two-factor authentication on every admin and editor account (via WP 2FA plugin)
- Weekly automated backups to off-site storage (UpdraftPlus to Amazon S3)
- Monthly plugin/theme audit: remove anything unused, update everything maintained
- Wordfence or Sucuri for web application firewall and malware scanning
- File integrity monitoring that alerts on unauthorized changes to core files

The DISALLOW_FILE_MODS constant is the single most impactful security measure because it eliminates the most common attack vector: uploading malicious code through a compromised admin account. With file modifications disabled at the PHP level, even if an attacker gains full admin access to the WordPress dashboard, they cannot install backdoors, upload malicious plugins, or modify theme files through the WordPress interface. Plugin and theme updates are handled exclusively via WP-CLI on the server or through the hosting provider’s managed update mechanism.

Is WordPress less inherently secure than a static site? Yes, by definition. A static HTML file has no server-side code to exploit, no database to inject into, and no admin panel to brute-force. But a static site also cannot process forms, manage user accounts, handle e-commerce transactions, or provide a CMS for non-technical content editors. Security is always a trade-off between capability and attack surface. WordPress’s attack surface is larger because its capability is larger. The discipline is in minimizing that surface while preserving the capability your business actually needs.

The Content Editor Experience

This is where WordPress has a durable advantage that technical teams often underestimate because they are not the ones using the CMS daily. The people who use the site every day, the marketing team, content writers, store managers, and business owners, are not engineers. They need to publish blog posts, update product descriptions, create landing pages for campaigns, upload images with proper alt text, and manage orders. They need to do all of this without touching code and without calling a developer for routine content changes.

WordPress’s admin interface is familiar to millions of people worldwide. A content editor who has used WordPress at a previous job, at a university, or on their personal blog can start publishing on your site with zero training. That familiarity is not true of Sanity, Contentful, Strapi, or any headless CMS. Those tools require training on custom schemas, field types, content models, and publishing workflows. The training is not prohibitively difficult, but it is a real cost that recurs every time you hire a new content team member or bring on a new marketing intern.

With Elementor or a similar page builder, non-technical users can create sophisticated landing pages with multi-column layouts, embedded videos, product carousels, testimonial sections, and call-to-action buttons. The drag-and-drop interface is genuinely intuitive for people who understand visual layout but do not know HTML or CSS. We have clients whose marketing teams create 10-15 landing pages per month without any developer involvement. Each page would cost $500-$1,500 if built by a developer. That is $60,000-$270,000 in annual development cost savings that the marketing team reinvests in advertising and content creation.

The Gutenberg block editor, now the default WordPress editor since WordPress 5.0, has matured significantly since its rocky 2018 launch. Full Site Editing (FSE) with block themes gives designers and advanced users template-level control without PHP knowledge. It is not as powerful as Elementor for pixel-perfect layouts, but it is built into WordPress core, requires no additional plugins, and produces cleaner HTML output with better performance characteristics. For content-focused sites (blogs, magazines, documentation portals), Gutenberg with a well-designed block theme is now our recommended approach over third-party page builders.

The Developer Ecosystem and Long-Term Viability

One concern we hear from technical decision-makers is whether WordPress will still be relevant in five or ten years. Will the PHP ecosystem decline to the point where hiring WordPress developers becomes difficult or expensive? Will newer platforms overtake it?

The data does not support this concern. PHP powers 77.4% of server-side web applications as of January 2024, a number that has remained remarkably stable for a decade. PHP 8.x has brought genuinely modern language features including JIT compilation for performance-critical code, union types and intersection types for type safety, fibers for concurrent programming, enums for data modeling, named arguments for readable function calls, and readonly properties for immutable data structures. Modern PHP is a different language from the PHP 5.x that earned the language’s poor reputation, and WordPress core is gradually adopting these modern patterns.

The WordPress developer community is the largest CMS developer community in the world, with millions of active developers, thousands of agencies specializing in WordPress development, and a conference circuit (WordCamp) that runs events on every continent. Stack Overflow’s annual survey consistently ranks PHP among the top 10 most used programming languages. The WordPress job market on platforms like Upwork, Toptal, and traditional job boards shows no signs of contraction; if anything, specialization is increasing, with separate markets for WooCommerce experts, Elementor specialists, performance engineers, and security consultants.

From a business continuity perspective, WordPress’s open-source license (GPL) means you are never locked into a vendor. If Automattic (the company behind WordPress.com and major contributor to WordPress core) disappeared tomorrow, the open-source project would continue because thousands of other companies and individuals depend on it and contribute to it. Your site, your themes, your plugins, and your data remain under your control. Compare this to Shopify, Squarespace, or Wix, where you are renting your web presence from a company that can change its pricing, features, or terms of service at any time, and migration away from those platforms is painful by design.

When WordPress Is Not the Right Choice

We turn down WordPress projects regularly. Recommending WordPress for every project would be dishonest, and dishonest recommendations erode client trust faster than any technical failure. Here are the scenarios where we steer clients toward other solutions:

• Web applications with complex state management. If the core product is an interactive application (a project management tool, a data dashboard, a real-time collaboration platform), WordPress is the wrong foundation. These require a JavaScript framework with client-side state management, WebSocket connections for real-time updates, and a backend designed for API-first data delivery. WordPress can serve as the marketing site and blog, but the application itself should be a separate codebase in React, Vue, or similar.
• High-scale e-commerce (10,000+ orders/day). WooCommerce’s database architecture, which stores product data and order data in the WordPress post and postmeta tables, was designed for small-to-medium stores. At enterprise scale, you need purpose-built e-commerce infrastructure with dedicated order management, inventory systems, and horizontally scalable databases.
• Serverless or edge-first architectures. If your infrastructure strategy depends on deploying to edge functions (Cloudflare Workers, Vercel Edge Functions), WordPress does not fit. It requires a persistent PHP runtime and a database connection. You can put a CDN in front of it, but the origin is always a traditional server.
• Teams that hate PHP. This sounds flippant but it is a real consideration. If your entire engineering team is JavaScript-native and has no PHP experience or interest in learning it, forcing WordPress creates maintenance friction that compounds over years. The team will resist working on it, code quality will suffer, and you will spend more money in the long run than if you had chosen a stack the team was excited to build with.

For everything else, which encompasses the vast majority of business websites, WordPress remains the pragmatic choice. It is not the most elegant technology. It carries 20 years of backward-compatibility baggage. Its codebase has architectural decisions that would make a senior engineer wince. But it works. It ships. It scales to the needs of 95% of businesses. And the ecosystem of themes, plugins, developers, and hosting providers means you are never locked in and never alone. In 2024, the question is not whether WordPress is cool. It is whether WordPress solves your business problem at a cost you can sustain. For most businesses, the answer is still yes.