WordPress or a static site: what to choose in 2026
An honest comparison of WordPress and a static site: speed, security, the total cost over three years, and the one question that actually decides it.
“WordPress or a static site” is a question asked mostly by technical people, and the answers they get are usually partisan. The static camp talks about speed and security; the WordPress camp talks about flexibility and about the enormous share of the web it runs. Both are right, and both are answering the wrong question.
This article asks the right question — which is not a technical one — and gives an honest comparison, including the real figures from migrating our own site off WordPress. For the record: we build both ways, and we have clients on WordPress whose sites we maintain. We have no interest in demolishing anything.
Contents
- The wrong question and the right one
- What WordPress does very well
- What a static site does very well
- Which is faster
- The total cost over three years
- Who edits the content
- A decision table by project type
- The third option: static with a separate CMS
- What you lose on static and what replaces it
- Maintenance, compared honestly
- How to migrate from one to the other
The wrong question and the right one
The wrong question: which technology is better?
There is no answer. They are tools with different profiles, and “better” depends entirely on context.
The right question: who changes the content of this site, how often, and what do they know how to do?
Almost everything follows from that answer. The rest of the comparison — speed, security, cost — are consequences: important, but secondary.
Three situations, three answers
- “Me, weekly, and I am not technical.” → you need an admin panel. WordPress, or static with a CMS.
- “Almost never. Once every few months I ask for a change.” → static. The admin panel is a cost you do not use.
- “We publish daily, we have an editorial team.” → you need a proper editorial workflow, with roles and approvals.
What WordPress does very well
Worth saying properly, because it is a lot.
The ecosystem. There is a plugin for almost anything, and for most ordinary needs no code has to be written.
Editing. An admin panel that millions of people know. A new employee has probably used it before.
Finding a supplier. If the relationship with your agency ends, you can find someone else who works on WordPress in any town. For a niche technology, it is not as simple.
Complex functionality. User accounts, eCommerce, subscriptions, bookings, forums. They all exist and they work.
The starting cost. For a simple site, it is hard to beat.
Why it runs such a large share of the web
Not out of inertia. Because it solves a real problem — publishing content by non-technical people — and solves it well enough for most cases.
What a static site does very well
A static site consists of HTML files generated before a visitor asks for them. There is no code executed on every visit and no database queried on every load.
Speed. The server delivers a file that is already made. It builds nothing.
Security. There is no admin panel to attack, no database to inject into, no plugins with vulnerabilities. The attack surface is all but non-existent.
Hosting cost. Static files can be served from anywhere, cheaply.
Stability. A static site does not “go down” on an update. It has no updates.
Predictability. What you see in the preview is exactly what reaches the server, down to the last byte.
What it does not do
It does not give you an admin panel, unless you add one. It has no user accounts, no shopping basket, and no features that depend on each visitor’s state — not without additional services.
Which is faster
A static site is significantly faster, particularly on server response time. WordPress builds every page on request: it executes code, queries the database, applies the plugins. A static site delivers a file that already exists. The difference in time to first byte is often several hundred milliseconds — and it adds to absolutely every other measurement.
WordPress can be optimised a great deal, with caching at several levels. A well-optimised WordPress beats a badly built static site. But the ceiling is lower, and maintaining the performance requires continuous upkeep.
Figures from our own migration
When we moved digital-art.ro off WordPress, we measured what was actually in the installation:
| Quantity | |
|---|---|
| Total files in the media library | 3,767 |
| Total size | 181 MB |
| Of which original, necessary images | 245 (35 MB) |
Automatically generated derivatives (name-300x200.jpg) |
3,410 (86 MB) |
| JavaScript from the visual editor | 62 files, 40.6 MB |
| CSS from the visual editor | 10 files, 12.2 MB |
| Font cache | 32 files |
| A plugin’s log file | 1 file, 2.6 MB |
Out of 181 MB, 35 were real content. The rest: derivatives, cache and the artefacts of a visual editor.
The effect on performance, after the rebuild:
| WordPress | Static | |
|---|---|---|
| Portfolio grid, 12 cards | ~2.4 MB | ~180–260 KB |
| Bytes for a 400 px card | 206 KB | ~18–28 KB |
A reduction of roughly 90%, with no visible loss of quality. It is not magic and it is not the technology’s doing — it is the absence of code that should never have existed, plus processing the images at build time, when you know exactly what sizes they will be displayed at.
A rigorously configured WordPress could achieve a good part of that. What is different is that on static the result comes by default, not as the outcome of an optimisation somebody has to keep up.
The total cost over three years
| WordPress | Static | |
|---|---|---|
| Build | comparable | comparable |
| Hosting, 3 years | €150–300 | €0–90 |
| Plugin licences, 3 years | €150–450 | €0 |
| Updates and maintenance | €300–900 | €0–150 |
| Risk of a security incident | real | near zero |
| Cost of an incident | €200–1,500 | — |
| A CMS for editing, if needed | included | €0–300 |
The nuances
Building costs much the same. The design, content and structure work is identical. The difference is in the implementation, and it evens out in both directions.
Maintenance is the main difference. A WordPress with plugins needs regular updates. Left undone, it becomes vulnerable. Done badly, something breaks. It is a real recurring cost.
The security risk is not theoretical. An un-updated WordPress site is, statistically, compromised within months. The cost includes the clean-up, any lost rankings, and sometimes a rebuild.
If you need editing on static, you add a CMS and part of the saving disappears. The security and performance advantages remain.
Who edits the content
The question that decides it.
If you edit often and are not technical
You need a panel. The options:
- WordPress. Familiar, complete, with the upkeep cost that goes with it.
- Static with an external CMS. You edit in an interface, and the site rebuilds itself automatically. You get the panel and keep the advantages of static. More complex to set up initially.
If you edit rarely
An admin panel you open three times a year is a permanent cost for an occasional need. Static, with changes made by the supplier, is cheaper and safer.
The typical case: a company’s business website. The copy changes rarely; the portfolio gets added to a few times a year.
If you have an editorial team
You need roles, drafts, scheduling, approvals. WordPress has them out of the box; on static, it is solved with the right CMS, but that is an architectural decision rather than a tick-box.
The question to ask before deciding
“How many times have I changed the content of the site in the last 12 months?”
The answer is almost always lower than the estimate. Check the site’s history, not your memory.
A decision table by project type
| Project | Recommendation | Why |
|---|---|---|
| Business website, 10–20 pages, rarely updated | static | speed, security, low upkeep |
| Business website with a weekly blog | static + CMS or WordPress | depends who writes |
| A portfolio with many projects | static | structured content, updated rarely |
| A blog with several authors | WordPress or static + CMS | editorial workflow |
| A small online store | WordPress with an eCommerce plugin | mature ecosystem |
| A large online store | a dedicated platform | volume and operation |
| A site with user accounts | WordPress or an application | per-user state |
| A site with complex forms and logic | either, with form services | not the deciding criterion |
| A multilingual site with stable content | static | the structures are generated, not maintained by hand |
| An institutional site with strict accessibility requirements | static | complete control over the code emitted |
The last row deserves a note. From 28 June 2025, the accessibility requirements of Romanian Law 232/2022 apply to a range of digital services. On a static site you control exactly what code reaches the visitor; on a platform with plugins, an update can introduce an accessibility problem without anyone finding out. See Web accessibility becoming mandatory.
The third option: static with a separate CMS
The combination more and more projects choose.
How it works: the content is edited in a dedicated web interface. On saving, the site rebuilds automatically and publishes. The visitor gets static files.
What you gain: an editing panel for non-technical people, plus the speed, security and hosting cost of static.
What you pay: a more complex initial set-up, a subscription to the CMS service (often free for a small number of users), and a gap of a few tens of seconds between saving and publishing.
Who it suits: a business website with a blog, where someone in the company wants to publish for themselves but nobody wants to administer a platform.
What you lose on static and what replaces it
The honest part of the comparison. A static site does not execute code on every visit, so a number of features do not exist by default. All of them have replacements — but they are separate decisions, with separate costs.
| Feature | On WordPress | On static |
|---|---|---|
| Contact form | a plugin | an external service, or a small script on the server |
| Internal search | a database query | an index generated at build time, searched in the browser |
| Comments | built in | an external service |
| User accounts | built in | an authentication service |
| eCommerce | a plugin | an external service or another platform |
| Content personalised per visitor | built in | JavaScript in the browser |
| Scheduled publishing | built in | a rebuild triggered at the chosen moment |
The ones that matter in practice
The form. It is the one feature absolutely every business website needs. It is easily solved: a small script on the server that receives the data and sends the email, or an external service. The cost is negligible.
Internal search. For a site with 20 pages it is unnecessary — the navigation is enough. For one with 150 projects, a search index is generated at build time and the search happens in the browser, instantly, with no server involved.
Comments. Rarely used on a company site, and when they are, they bring more spam than conversation.
The decision rule
If the list of features you need includes user accounts or real eCommerce, the “static or WordPress” question is already settled. For anything else, the replacements are simple and often better than the original.
Maintenance, compared honestly
The main difference in cost over time, described concretely.
On WordPress
| Activity | Frequency | Who |
|---|---|---|
| Core updates | every release | administrator |
| Plugin updates | monthly or more often | administrator |
| Theme updates | periodically | administrator |
| Checking after an update | every time | administrator |
| A backup before updating | every time | automatic or manual |
| Security monitoring | continuous | a plugin or a service |
| Database clean-up | periodically | administrator |
Realistic effort: 1–3 hours a month for an ordinary site, plus intervention when an update breaks something.
The specific risk: an updated plugin can conflict with another. That is why updates are done with a backup and a check afterwards — you do not press “update all” and walk away.
On static
| Activity | Frequency |
|---|---|
| Updating build dependencies | 1–2 times a year |
| Checking the forms | quarterly |
| Checking external links | annually |
Realistic effort: a few hours a year.
The specific risk: the build dependencies fall behind if nobody touches them for two years. It does not affect the published site — the files served stay the same — but it makes rebuilding harder when you need a change.
The important nuance
A maintained WordPress is perfectly safe. The problem is not the platform; it is that maintenance is a recurring task which, in small companies, falls between two stools.
The question to ask: who does the monthly updates, and are they paid for it? If the answer is “nobody, we manage”, static removes a category of risk you have nobody to manage.
How to migrate from one to the other
From WordPress to static
Feasible and done often. The stages:
- A complete export — content, images, the address structure.
- An inventory of the addresses. The critical part. Details in How we migrated a site without losing rankings.
- Transforming the content into structured files.
- Rebuilding the design and the components.
- The redirects, checked automatically.
- Launch, with 30 days of monitoring.
Duration for a medium business website: comparable to building a new one, because the content work is the same.
What you lose: the features that depended on code executing on every visit — database-backed internal search, accounts, comments. Each has a replacement, but that is a separate decision.
From static to WordPress
Done more rarely, usually when the needs have changed: a store has appeared, or a team that publishes daily. Structured content imports relatively easily.
The sign that the moment has come: you ask your supplier for content changes more often than once a week.
The conclusion
There is no universal answer, and anyone who gives you one without asking how you work is selling you what they know how to do.
Go back to the question at the start: who changes the content, how often, and what do they know how to do?
- Rarely, and you do not want to deal with upkeep → static.
- Often, and you want to publish yourself → WordPress or static with a CMS.
- You already have a WordPress that works well and is maintained → do not move it because it is fashionable. Migration has a cost and a risk; you do it for a concrete reason, not for a speed score.
We work both ways. We build static sites and we provide WordPress maintenance(opens in a new tab) for clients who stay on the platform — including for sites built by other agencies.
Write to us with your situation and we will tell you honestly what makes sense. Including when the answer is “leave it as it is”.
Read next: Core Web Vitals explained for business owners, Web hosting: what really matters and How we migrated a site without losing rankings.