In 2024, the WordPress ecosystem logged 7,966 new security vulnerabilities. Only 7 were in WordPress core. The other 96% came from plugins (Patchstack, State of WordPress Security 2025). That is not a scare number. It is a number that shapes the static-vs-WordPress decision.
A static website is a set of HTML, CSS, and JavaScript files the server sends directly to the browser. No database, no PHP, no CMS running in the background. WordPress is a content management system: a database and PHP layer that assembles pages the moment someone visits your site. Two fundamentally different architectures. Two different cost structures. Two different maintenance stories.
I build and host both. By the end of this guide you will have a five-question schema that points you, or the freelancer you hire for a new website, straight to the right answer.
The question is not which technology is better, but which fits your situation
Read two articles on this topic and you get two opposing recommendations. Leavewp.com argues static is always cheaper and safer. WPBeginner argues WordPress is always more flexible and convenient. Both have a product to sell.
I do not. I build static sites for clients where that fits, and WordPress sites where that fits. Sometimes both in the same week. What I have that they do not: concrete maintenance numbers from projects currently running.
One example. Weeringo is a static client site I host and maintain. Maintenance per year: 0 hours. No plugin updates, no security patches, no late-night alerts. What the client pays is hosting, plus changes on request. Small text edits run about 12 minutes each; a structural change takes around 90 minutes. That is on-demand work, not a maintenance contract.
On the other side: Houworst is my own shop on WordPress and WooCommerce. Total time investment: 160 hours per year. Six product updates, six orders per week, continuous inventory work. Not because WordPress is poor. Because an active shop is work.
The TCO table on leavewp.com shows $15–$855 per year for static hosting versus $2,000–$6,000+ for WordPress. The direction is right. The top of that WordPress range only applies to enterprise sites; for a small business the real maintenance cost sits much lower. But it is never zero.
What actually matters when choosing
Who manages the content?
If you or a staff member needs to add pages or edit text without calling a developer, WordPress is almost always the right answer. The CMS exists for exactly that: log in, type, save, done.
If content changes quarterly or annually and a developer handles it, static is simpler. No WordPress update that broke the visual editor after a plugin conflict, no logged-in users with unclear permissions.
Do you need a shop or user registrations?
Databases are required for dynamic content: shopping carts, inventory, member registrations, comment sections. Static sites cannot do this natively. Kinsta puts it plainly: “However, any website that requires a database is out of the question. That means that you can’t use static website generators to create online shops, blog posts with comments sections, websites with user registration, and so on.”
If you run (or plan to run) a WooCommerce shop, you can stop reading here. WordPress is the logical choice.
How much ongoing maintenance are you willing to pay?
WordPress maintenance at a baseline plan runs €35–€75 per month through a freelancer or maintenance service (WP Umbrella 2025). That covers updates, backups, and security monitoring. A static site has no equivalent recurring line: no plugins needing updates, no plugin vulnerabilities to watch.
Those costs are real and predictable. They are not an argument against WordPress, but they need to be in your budget before you sign. My own WordPress maintenance plan at €45 per month sits in that range.
The decision schema: 5 questions
Work through these five questions in order. Stop at the first question you answer yes to.
-
Does someone without technical knowledge need to add or update content regularly — monthly or more often?
Yes → WordPress. Stop here. -
Do you need a shop, member registration, or any other feature that requires a database?
Yes → WordPress. Stop here. -
Is your structured maintenance budget under €25 per month?
Yes → Static. Stop here. -
Do you have no developer available to handle periodic small updates?
Yes → WordPress, with a maintenance plan. Someone else manages the updates for you. -
Is the site primarily informational — services, portfolio, landing pages — and does the content change at most a few times per year?
Yes → Static.
If the answers conflict — low budget but you want to self-manage, or you need a database but have no maintenance budget — the choice is situation-dependent. That is exactly where a personal conversation starts, and why the form on the order page runs ten steps instead of one.
Weeringo: why static was the only sensible answer
Weeringo is an informational site. Services, contact details, a few explanation pages. Content changes a few times a year, always at the client’s request.
Question 1 from the schema: nobody at the client needs to log in and make changes themselves. Question 2: no shop, no registrations. Question 5: yes, primarily informational. Answer: static.
The result in numbers: 0 hours maintenance per year. No WordPress updates, no plugin patches, no security alerts. The HTML files sit on the same Hetzner server as ramonhorst.nl, behind Caddy. What the client pays is hosting, plus the changes she requests. Five small edits per hour, a larger structural change around 90 minutes. She pays only for work that actually happens — not for maintenance a static site does not need.
This is not an argument that static always wins. It is evidence that the schema works: at Weeringo the answers pointed in one direction immediately, and the annual maintenance load confirms it. Similar informational projects are in the portfolio.
Houworst: why WordPress was the only logical choice
Houworst is my own shop. I am naming it explicitly: this is not an anonymous client case, it is my project. That makes the numbers more honest, not less relevant.
The setup: physical products, inventory, payments via Mollie, shipping labels, weekly order processing. Six orders per week on average, six product updates per year.
Question 1 from the schema: yes, content needs to be manageable without a developer. Question 2: yes, a database is mandatory: cart, inventory, orders. The schema stops at question 1 or 2. WordPress and WooCommerce.
Why not build everything custom? I could, but it would be pointless. WooCommerce delivers a working order flow out of the box: inventory management, shipping labels, payment integrations, email confirmations. Building the same thing from scratch takes weeks of development time for a result no better. More importantly: a non-technical person can add products themselves, and fulfillment can be handed off to a third party without them needing to understand any code.
The time investment in numbers: 160 hours per year total. That covers everything: order processing, product updates, plugin updates, backups, inventory. For an active shop that is normal and predictable. WP Umbrella cites $750–$5,000 per month for full WooCommerce maintenance on larger platforms; my shop sits well below that because I handle it myself, but it illustrates that an active shop demands consistent work. For clients who have a WooCommerce shop built, I factor that in honestly.
The grey zone: when the schema gives no clear answer
Not every situation fits neatly into one path. Three common edge cases.
Small business wants to self-manage content, but has no budget for monthly maintenance. Question 1 points to WordPress, question 3 points to static. Two ways out: WordPress with a lightweight maintenance plan covering only critical updates, or static with a form integration such as Netlify Forms or Formspark that keeps dynamic needs minimal.
Static site where a non-technical editor still needs to make occasional changes. Connecting a headless CMS like Decap CMS to a static generator solves this, but adds complexity that partially offsets the maintenance advantage. Often the honest conversation is more useful: how often does that editor actually want to change things, and could a short guide and a Git workflow handle it instead?
Existing WordPress site you want to migrate to static. Migration risks are real: plugin-dependent content, embeds, redirects, custom fields. That is a separate project, not something done in passing. For hosting options that work in both scenarios and what WordPress maintenance actually costs, I have separate service pages.
Run through the schema. If you are still unsure after multiple questions, the choice is situation-dependent. That is exactly the conversation we have when you submit a project brief.