Menu
541-602-0978

Journal

WordPress or a static site: which should your business use?

By Chris Parsons · Published · Updated

Laptop showing a code editor on a wooden desk beside a coffee mug, a potted plant and a notebook
Photo: Daniil Komov on Unsplash

WordPress vs static site comes down to who edits the site and how often. Choose WordPress if several people publish often or you rely on plugins for a store or memberships. Choose a static site if content changes occasionally and you want speed, a small attack surface and low maintenance.

I build both, and I recently moved my own site off WordPress to a hand-built static site. This isn’t a “WordPress is dead” piece: for plenty of businesses, WordPress is still the right call in 2026 and beyond. Here’s how I decide, including where I’ve pushed back on my own preference for static.

How do WordPress and static sites serve a page differently?

WordPress builds each page on request with PHP and a database, unless a cached copy exists. A static site is built ahead of time and serves the same prebuilt files to everyone.

WordPress: built on request

WordPress is PHP code backed by a MySQL or MariaDB database. On every uncached request, the server loads WordPress along with the active theme and every active plugin, queries the database, and assembles the HTML. That makes it flexible, and it means there’s always running code and a database behind the public site.

Static: built ahead of time

A build step turns content and templates into plain HTML, CSS, JavaScript, and images, which go to a web server or content delivery network (CDN). Every visitor gets the same prebuilt file, with no PHP or database query.

Caching narrows the gap

Page caching, from a plugin, the host, or a CDN, saves the finished HTML and serves that copy until something changes, so for anonymous visitors a well-cached WordPress page behaves a lot like a static file.

The gap opens up when caching is missing, when pages can’t be cached (carts, logged-in areas), or when the page is heavy to begin with.

When is WordPress the better choice?

WordPress wins when several people publish, when owners want to edit everything themselves, or when a mature plugin already does what you need.

Teams and publishing workflows. WordPress ships with five user roles on a standard site (six on Multisite), plus drafts, scheduled posts, and revision history. If several people write, edit, and approve content, it works out of the box.

A huge community and developer pool. According to W3Techs, as of October 18, 2026, WordPress runs 39.6% of all websites and 58.4% of sites whose CMS they can identify. That means plenty of developers, documentation, and hosting options.

Owner control. You can change a headline or publish a post without calling anyone. For many owners, that matters most.

A well-maintained core. WordPress has a dedicated security team of more than 50 experts. They ship fixes in bugfix releases and backport critical fixes to older versions. Minor and security releases update automatically by default, and new installs since WordPress 5.6 get major updates automatically too (existing sites keep their old setting). That doesn’t make it “the most secure CMS,” a claim nobody can honestly make, but core is mature and actively looked after.

Mature features. Stores, memberships, event calendars, and multilingual sites already have established plugins.

Is WordPress less secure than a static site?

WordPress core is rarely the problem: Patchstack found only 6 of 11,334 vulnerabilities in 2025 were in core. The risk is in plugins and themes, while static sites move the risk to forms, build tools and accounts.

Where WordPress vulnerabilities actually come from

The public data is consistent on this. In Patchstack’s State of WordPress Security in 2026, which covers 2025, researchers recorded 11,334 new vulnerabilities in the WordPress ecosystem, a 42% increase over 2024. 91% were in plugins and 9% were in themes. Only 6 were in WordPress core, and Patchstack rated all of those low priority. Wordfence’s 2024 annual report, published April 2025, found the same pattern: plugins accounted for 96% of disclosed vulnerabilities, and only 5 affected core.

Three more findings matter for real sites:

  • Fixes don’t always exist. Patchstack found that 46% of the vulnerabilities it tracked in 2025 had no fix from the developer by the time they were publicly disclosed. Wordfence estimated that about 35% of 2024’s vulnerabilities were still unpatched in 2025.
  • Attackers move fast. For the most heavily exploited vulnerabilities, Patchstack measured a weighted median of 5 hours from disclosure to the first exploitation attempt.
  • Paid doesn’t mean safe. Of the premium plugin and theme vulnerabilities reported to Patchstack, 76% were exploitable in real attacks.

Big counts partly reflect how many researchers now examine WordPress code, and Wordfence rated over 68% of 2024’s vulnerabilities low risk for most site owners. The point is where the risk lives: in the add-ons you choose.

We recently brought back a client’s WordPress site that had been hacked. The attacker didn’t get in through WordPress core; they got in through a third-party plugin vendor’s customer dashboard. That’s a single example, not data, but it’s a big part of why I take the ecosystem seriously.

Common attack types

  • Cross-site scripting (XSS): injected malicious scripts. It’s about 40% of all entries to date in Patchstack’s database and was Wordfence’s top type for 2024.
  • Broken access control: a plugin lets someone do what they shouldn’t. Patchstack named it the most exploited category in 2025.
  • Arbitrary file upload and privilege escalation: the most common high-threat types in Wordfence’s 2024 data.
  • Password attacks: Wordfence blocked over 55 billion in 2024, though it notes password attacks overall are declining.

What to do in practice

Plugins can be managed safely, but someone has to do that work, and often nobody does. The data above explains what matters:

  • Fewer, well-vetted plugins, because nearly all the risk lives there and many flaws go public before a fix exists.
  • Fast updates and vulnerability alerts, because the most-targeted flaws are attacked within hours.
  • Least-privilege accounts and two-factor login, because Contributor-level access was the most common requirement for exploiting 2024’s vulnerabilities (34%, per Wordfence).
  • Monitoring and tested off-site backups, so you can spot trouble and recover from it.

For the step-by-step, see this guide to keeping WordPress patched and backed up.

What static sites still have to protect

Static removes a lot: no public admin login, no database, no per-request server code. That’s a much smaller attack surface, but it isn’t zero, and static sites aren’t unhackable. The risks move:

  • Forms and serverless functions. A form handler needs validation, spam protection, and safely stored keys.
  • The build and npm supply chain. In September 2025, CISA warned that a self-replicating worm called “Shai-Hulud” had compromised over 500 npm packages and stolen developer credentials. Lock dependency versions and protect build credentials.
  • Hosting, Git, and DNS accounts. Whoever controls your repository, host, or registrar controls your site. Use two-factor authentication and limit access.
  • Third-party scripts. Analytics, chat widgets, and embeds are someone else’s code running on your page.

Is a static site faster than WordPress?

Usually, by default. A lean, well-cached WordPress site can come close, and a bloated static site can be slow.

Google’s Core Web Vitals measure loading (Largest Contentful Paint, good at 2.5 seconds or less), responsiveness (Interaction to Next Paint, good at 200 milliseconds or less), and visual stability (Cumulative Layout Shift, good at 0.1 or less). Each one is judged at the 75th percentile of real visits.

What weighs WordPress down

The HTTP Archive’s 2025 Web Almanac CMS chapter, which used July 2025 field data, found that 45% of WordPress sites passed all three Core Web Vitals on mobile. That’s among the lowest of the platforms they compared. The performance chapter puts all mobile websites at 48%. The Almanac says plainly that WordPress performance varies with “configuration and tooling choices” more than with core. It estimates that around 60% of WordPress sites use a page builder, and it links page builders to that variation.

In my experience, the usual weights are page builders, heavy multipurpose themes, plugin assets loaded on every page, and years of accumulated third-party tags. A lean theme, a short plugin list, good caching, and optimized images can get WordPress passing comfortably.

Static is fast by default, not fast automatically

Static starts with an advantage: prebuilt files, often from a CDN. You can still bloat it with oversized images, a heavy JavaScript framework for a simple brochure site, or too many third-party scripts. Static is a better starting point, not a guarantee.

Which costs more to own?

It depends on what you need built. Static is usually cheaper to host and maintain, while WordPress is often cheaper when a mature plugin already handles a feature you’d otherwise build from scratch.

  • Hosting. Static files are cheap and simple to host. WordPress needs PHP and a database. Some managed hosts help with updates, caching, backups, and monitoring, but plans vary, and plugin and theme updates are often still up to you or your developer. WordPress.com versus self-hosted is the next question if you pick WordPress.
  • Maintenance time. WordPress needs ongoing updates and plugin checks. Static needs less, but dependencies still need occasional updates.
  • Backups and rollbacks. A static site in Git has its history built in, and rollback is often one click. WordPress needs tested file and database backups.
  • Developer availability. WordPress developers are everywhere. A static site on a given framework needs someone who knows it.
  • Custom features. On static, search, e-commerce, or member logins mean custom work or an outside service. On WordPress, a mature plugin may already do it for less.
  • Depending on one developer. If only one person understands your site, that’s a liability on any platform. Insist on code in a repository you own, documentation, and access you control.

Can you get static speed with a WordPress-style editor?

Yes. Headless WordPress and Git-based or headless CMS editors give you a dashboard on top of a static or modern front end, with some added complexity.

  • Headless WordPress: editors keep the WordPress dashboard while a separate front end pulls content through its REST API. The cost is two systems and more complexity.
  • Git-based and headless CMS editors: Decap CMS (formerly Netlify CMS) adds an editing screen to a static site and saves changes to your Git repository. Hosted headless CMS services do similar work through an API.
  • Site builders: hosted platforms handle hosting and editing in exchange for less flexibility and some lock-in.

Can AI make a static site easy to update?

Yes, with an expert in the loop. AI can make plain-language edits quickly, but it needs someone who deeply understands the site to review every change.

What AI can realistically do today

AI coding tools can take a request like “add a holiday hours banner to the homepage,” find the right files, make the change, and show the exact difference before it goes live. On a well-organized static site in Git, this works well for routine changes.

Why it needs someone who deeply understands the site

AI can be confidently wrong about which template feeds other pages or which change will quietly break your structured data. With an expert guiding it and reviewing every change, AI makes a static site nearly as quick to update as a CMS. Without that oversight, it can do damage quickly.

The risks of unsupervised edits

Without review, you get fixes that break something elsewhere, quietly removed metadata or accessibility features, unvetted new dependencies, exposed API keys, and mistakes that pile up.

This is how we work at Steelbridge. AI speeds up the edits, and a person who knows the site reviews every one before it ships.

Small updates are turned around the same day, often within two hours, and bigger changes get a clear timeline up front.

Which should you choose?

Neither one is right for every site.

WordPress vs static site: which to choose
If this sounds like you Lean toward
Several people write, edit, and approve content WordPress
You publish often and want to do it yourself WordPress
You need a store, memberships, or another feature a mature plugin already handles well WordPress
You want the option to switch developers easily WordPress
Speed and a small attack surface are top priorities Static
Your content changes occasionally, and you're fine sending changes to a trusted developer Static
You want low maintenance and simple, reliable rollbacks Static
You want static performance but your team needs a dashboard Static with a Git-based CMS, or headless WordPress

With WordPress, keep plugins few and updated, use good hosting, and make sure someone owns maintenance. With static, own your repository and accounts, and send changes to a developer you trust.

FAQ

Is WordPress secure?

WordPress core is well maintained, with a dedicated security team and automatic minor updates. Most vulnerabilities come from third-party add-ons: Patchstack attributed 91% of 2025’s new WordPress vulnerabilities to plugins and 9% to themes. With few, vetted, updated plugins, least-privilege accounts, and two-factor login, WordPress can be run securely.

Can a static site be hacked?

Yes. A static site has a much smaller attack surface, but it can still be compromised through form handlers, compromised build dependencies, stolen hosting, Git, or DNS credentials, and third-party scripts.

Is a static site always faster than WordPress?

No. Static sites are fast by default, a lean, well-cached WordPress site can come close, and a bloated static site can be slow. In HTTP Archive’s 2025 data, 45% of WordPress sites passed Core Web Vitals on mobile, with variation driven more by themes, plugins, and page builders than by core.

Can I edit a static site myself?

Not out of the box. You can add a Git-based editor like Decap CMS or a headless CMS, or send changes to a developer who uses AI tools under expert review.

Should I move my WordPress site to static?

Only if it fits how you work. If your team publishes often or depends on plugins for core features, well-maintained WordPress is usually better. If content changes occasionally and you care most about speed, security, and low maintenance, static is worth a look.

Want a straight answer for your site?

If you’re weighing WordPress against static, or your current site feels slow or fragile, get in touch. We’ll give you a straight answer, even if it’s WordPress.

Sources