We've been building on WordPress since 2004. It's our core practice, and for a significant majority of the organizations we work with, it's the right platform. But 2026 has been a year that makes the platform security question harder to dismiss than it used to be.
Three significant events in the span of a few months: the wp2shell core RCE disclosed in July, a 9.8 Critical vulnerability requiring no authentication and no plugins to exploit. The Essential Plugin supply chain attack in April, which compromised thirty-plus plugins through a single Flippa acquisition and sat dormant for eight months before activating. And Patchstack's data showing a median of five hours between vulnerability disclosure and active exploitation attempts across the WordPress ecosystem.
None of these are failures of individual sites. They're the inherent risk profile of a dynamic application platform at scale. And they've pushed the question of whether dynamic WordPress is the right architecture for every organization from theoretical to operational.
This isn't a case for abandoning WordPress. It's a case for understanding what static deployment actually offers, when it's the right answer, and when it isn't.
We'll Tell You When WordPress Isn't the Answer
One of the things we've learned over twenty years of building and maintaining web infrastructure is that recommending the wrong platform because it's the one you know best creates problems that outlast the initial engagement.
When Rubicon Project, now Magnite, came to us needing a series of approximately twenty microsites, the initial assumption was that we'd build them in WordPress. We knew WordPress. They knew WordPress. It seemed like the obvious path. After a deeper assessment of what they actually needed, we recommended against it. The microsites were simple, content-consistent, and didn't require dynamic server-side rendering. A headless CMS paired with a static site generator was the right architecture. We built it that way, and what would have been twenty sites requiring manual individual updates became a single centrally managed process.
That case study is on our website because it illustrates something we believe matters: the best development partner tells you what your project actually needs, even when that answer doesn't favor their core offering.
If you're thinking about moving away from WordPress, that same honesty applies. The answer might be static. It might be headless. It might be a different platform entirely. And in some cases, it might be that WordPress is actually fine and the problems you're experiencing are solvable without a platform change. We'll tell you which is which.
The Security Case for Static
A dynamically rendered WordPress site processes server-side PHP on every request. That means a running application, a database connection, an authentication layer, and a plugin stack, all of which represent an attack surface that has to be maintained, monitored, and defended continuously.
The wp2shell vulnerability illustrates exactly why this matters. CVE-2026-63030, rated 9.8 Critical by Wordfence, allowed an anonymous attacker to chain a SQL injection with a REST API route confusion vulnerability to achieve remote code execution on a stock WordPress installation. No plugins. No authentication. No special configuration. Every WordPress site in the affected version range was exposed until patched, and Patchstack's data puts the median exploitation window at five hours after disclosure.
The Essential Plugin attack is a different dimension of the same problem. The attack surface isn't just WordPress core and its plugins as they exist today. Its WordPress core and its plugins as they might exist after an ownership transfer nobody reviewed, an update changelog that lied, and eight months of dormant malicious code waiting for activation. A static site at the delivery layer has none of that exposure. There is no server-side application to compromise, no database to inject, no authentication bypass to exploit. Static HTML files deployed to a CDN respond to requests without executing anything. The attack surface at request time is essentially zero.
This doesn't mean static sites have no security considerations. The build pipeline, the CMS used to author content, and any API integrations all have their own security requirements. But those components are discrete, manageable, and not exposed to the public internet the way a dynamic application is. The threat model is fundamentally different, and in many cases, fundamentally better.
Looking ahead, the risk profile for dynamic WordPress is likely to expand rather than stabilize. WordPress 7.0 introduced a native AI framework built on the REST API layer, the same layer CVE-2026-63030 exploited. As more plugins build on that framework, more AI provider connections run through WordPress, and more third-party integrations depend on REST API endpoints, the attack surface grows with the platform's capability. That's not a flaw in the design. It's the nature of an open, extensible system. For organizations evaluating platform architecture in 2026, it's part of the honest calculation.
When WordPress Is and Isn't the Right Tool
WordPress makes sense when multiple people or teams need to manage content without developer involvement, when the site needs to grow and change over time without a platform rebuild, when long-term platform ownership matters, and when the system needs to integrate with other tools. A well-built WordPress implementation is maintainable by any competent WordPress developer, not locked to the agency that built it. That portability has real value.
WordPress isn't the right choice when application logic goes well beyond content management. Complex business logic, custom data models, and multi-step workflows are better served by a purpose-built application framework. WordPress extended far beyond its CMS roots tends to become fragile over time and expensive to maintain. It's also not the right choice when performance requirements exceed what dynamic server-side rendering can reliably deliver at scale, or when the organization's security posture makes a dynamically rendered application's attack surface a genuine operational concern.
The security posture point is the one that's changed most in 2026. For organizations where downtime, data exposure, or reputational damage from a breach carries real business consequences, the question of whether dynamic WordPress is the right architecture deserves a direct answer rather than a default assumption.
What Static Actually Looks Like in 2026
The static site ecosystem has matured significantly. The choice of tools is now genuinely good, and the right one depends on the project's specific requirements.
Astro has emerged as one of the most compelling options for content-focused sites. It ships zero JavaScript by default, produces extremely fast static output, and supports a component model that lets teams bring their preferred framework without committing to a full single-page application architecture. For sites where content is the primary deliverable and performance and security are priorities, Astro is worth evaluating seriously.
Next.js remains the strongest choice for applications that need a mix of static generation and server-side rendering, or where the site includes dynamic features alongside largely static content. Its incremental static regeneration capability means content can be updated without a full site rebuild, which closes the gap between static performance and dynamic flexibility.
Gatsby is well-suited to content-heavy sites that benefit from its data layer and plugin ecosystem. It pulls content from multiple sources at build time, generates static HTML, and handles image optimization well. For organizations with complex content structures coming from multiple systems, Gatsby's approach to data handling is a meaningful advantage.
The headless CMS layer is what makes these tools practical at editorial scale. Content authors work in a familiar interface, Contentful and similar platforms, while the front-end is built on whichever static framework best fits the project's requirements. The CMS and the delivery layer are separate concerns, which means each can be optimized independently.
WordPress itself can function as a headless CMS, feeding content through its REST API or WPGraphQL to a static front-end. For organizations with significant existing WordPress content and editorial teams comfortable with the WordPress interface, this is often the lowest-disruption path to static delivery. The editorial experience stays the same. The attack surface at delivery changes entirely.
It's also worth being direct about static's own limitations. Build pipelines have security requirements of their own. CDN configurations can be misconfigured. API integrations with third-party services introduce dependencies that require ongoing monitoring. Static isn't a security silver bullet. It's a different threat model, and in most cases a more manageable one. The organizations that benefit most from it are the ones that understand both what they're gaining and what they're taking on.
What a Platform Transition Actually Involves
Moving from a dynamic CMS to a static architecture is a real project, not a configuration change. The content model has to be mapped and migrated. The editorial workflow has to be rebuilt in a new system. The deployment pipeline has to be built and tested. Redirects have to be managed carefully to protect search equity. Any dynamic features such as forms, search, personalization, and e-commerce, have to be handled through APIs and third-party services rather than server-side logic.
None of that is insurmountable. But it requires honest scoping and a clear-eyed view of what the organization is actually gaining against what it's investing. The sites that benefit most from a move to static are the ones where the content model is relatively stable, the editorial team can adapt to a new interface, and the performance and security gains justify the transition cost.
The sites that shouldn't move are the ones where dynamic functionality is genuinely central to what the site does. A complex WooCommerce implementation with custom product logic, conditional pricing, and membership tiers isn't a static site. Neither is a platform with real-time content personalization at the application layer, or a site where editors are constantly changing the content model itself.
We're direct about this because a platform migration that wasn't necessary is one of the more expensive mistakes a development engagement can produce.
How We Help With This Decision
Our technical audit and discovery process is designed to answer the platform question honestly before any development work begins. That means evaluating the current architecture, understanding what the organization actually needs the site to do, and mapping that to the available options without defaulting to the platform we're most comfortable with.
If the answer is static, we scope and build the migration. If the answer is headless WordPress, we build the headless layer. If the answer is that the current WordPress implementation is sound and the problems are solvable within it, we say that too. And if the right answer is something else entirely, like Laravel for a complex application or Shopify for a retail implementation that fits standard patterns, we'll tell you that.
The security events of 2026 have made the platform architecture question more urgent for some organizations than it was a year ago. The goal isn't a platform recommendation. It's an honest assessment of whether the infrastructure you're running matches the risk environment you're operating in.
