Can you have a website that never goes down and never needs updating?

Somebody typed almost exactly that into Google and ended up on our site. I know because it turned up in our Search Console, spelled out as a full sentence rather than the clipped phrases people usually type.

It is a good question asked by someone who is plainly fed up. So here is a proper answer rather than a sales one, including the part where the answer is no.

The short version

It is two questions wearing one coat.

“Never goes down” is very nearly achievable, and the way you get there is by removing moving parts rather than by buying better hosting.

“Never needs updating” splits in half. The maintenance half — security patches, plugin updates, version bumps — can be reduced to almost nothing. The content half cannot be, and if it ever is, something has gone wrong.

What actually takes a small business website offline

Almost never the internet. In practice it is one of five things:

• A database that stops answering, usually under load or after a hosting change.
• An update that broke a page — a plugin conflict, a theme that no longer matches the software under it.
• An expired TLS certificate, which turns your site into a red warning screen.
• An expired domain, which is worse and takes longer to undo.
• An unpaid hosting bill, often on a card belonging to somebody who left.

Only the first two are technical. The other three are diary problems, and they are the ones that catch established businesses, because nobody is watching a thing that has worked for six years.

Which tells you where the real answer lies. A site built as plain files and served from a content delivery network has no database to fail and no software to conflict with itself. There is very little left that can break, because there is very little there. That is not a clever trick; it is just fewer parts.

It does not make you immune. It moves your risk from the technical column to the administrative one — and the administrative one you can fix with a calendar reminder, which is a much better class of problem to have.

Now the updating half, with the actual numbers

This is where the honest answer gets useful, because the received wisdom is roughly backwards.

Patchstack — a WordPress security company, which matters and I will come back to it — publishes an annual count of vulnerabilities across the WordPress ecosystem. For 2025 they recorded 11,334 new vulnerabilities, which they describe as “a 42% increase compared to 2024”. Of those, they say 1,966 (17%) “had a high severity score”.

Now the line that changes what you do about it:

“91% of new vulnerabilities were found in plugins, and 9% were found in themes. There were only 6 vulnerabilities reported in the WordPress core, but these were low priority issues.”

Six. In the core. All low priority.

So when people say WordPress is a security burden, the data says WordPress mostly is not. The burden is what got bolted on to it. Every plugin is another supplier you have quietly taken on, and you are relying on each of them to keep patching indefinitely. Patchstack's own figure on that is uncomfortable: they report 46% of vulnerabilities “did not receive a fix from the developer in time for public disclosure”, and draw the conclusion themselves: “This again shows why website owners can’t rely on plugin updates as a security measure.”

The practical version for a small business: deleting a plugin you do not use is a free security improvement, and it is the single most effective thing most people reading this could do this week.

The scary number and the real one

I checked the other half of this myself rather than repeating a figure.

The official WordPress release archive lists 106 separate version releases in the twelve months to 30 August 2026. That sounds relentless, and it is the sort of number that gets quoted to sell you a maintenance retainer.

It falls on 15 distinct dates.

The reason is that one security fix gets backported across every supported branch at once. On 6 August 2026, twenty-five versions were published in a single go, from 4.7.34 up to 7.0.3 — that is one event, not twenty-five. If you stay on the current branch, you would have been asked to update roughly ten times in that period. About once a month.

That is a real maintenance load, but it is not the horror story the raw count implies. And it is core alone, before plugins — which, per the numbers above, is where the actual work and the actual risk both live.

The half that will never go away

Your opening hours change. Your prices change. Somebody joins, somebody leaves, you stop offering the thing on the third card down.

No architecture fixes that, and a website that has genuinely needed no changes in two years is not low-maintenance — it is unattended. The cost does not show up as downtime. It shows up as a customer ringing to ask something the page should have answered, or not ringing at all.

So the goal worth having is not a site that never needs touching. It is a site where the only reason to touch it is that something about your business actually changed — and where doing that takes a minute rather than an email to somebody who might reply on Thursday.

What argues the other way

Three things, in fairness.

Plain files cannot do everything. If you need real bookings, logins, memberships or a proper shop, you need software that runs, and that software will need maintaining. Choosing fewer moving parts is a choice with a cost, and pretending otherwise would be dishonest. The honest position is: have as few as the job genuinely requires, not as few as possible.

The 42% rise deserves a caveat that did not travel. It is a rise in vulnerabilities found and reported, not necessarily in vulnerable code. In the same report Patchstack note “a significant increase of AI generated ‘slop’ vulnerability reports in 2025”, and AI tooling genuinely is finding more real bugs too. Both push the count up. Treat it as evidence that the ecosystem is being looked at harder, which is not the same as it having got 42% more dangerous.

And consider who is counting. Patchstack sells WordPress security. A company whose product is protection publishing a large number about the need for protection is not disqualifying — their database is the most complete public source there is, and the report is unusually clear about its own methods — but you should know it, and now you do. By the same token: we build websites, including a static one, so read my enthusiasm for fewer moving parts with that in mind.

If you want to actually do something about it

In rough order of how much they pay back:

• Delete every plugin you do not use. Free, immediate, and aimed squarely at the 91%.
• Put your domain and certificate renewals in a calendar, on a company card, not a personal one. This is the failure that takes businesses off the internet for days.
• Find out who can change a price on your website in under five minutes. If the answer is nobody, that is the problem to solve, not uptime — and it is worth knowing who actually controls your website before you need to find out in a hurry.
• Only then ask whether the site needs to be built on something that runs software at all.

Most people arrive at this question wanting the last item and needing the first three.

Sources and disclosures. Vulnerability figures are from Patchstack's State of WordPress Security In 2026 whitepaper covering calendar year 2025, page dated “Data updated 25.02.2026”, read directly at patchstack.com rather than from coverage of it; every quoted fragment above was checked against the raw page. Patchstack is a WordPress security vendor and the data is drawn from its own vulnerability database and disclosure programme. The release counts are ours: we parsed the official WordPress release archive on 30 August 2026 and counted version numbers and distinct release dates in the twelve months to that date — 106 releases across 15 dates. Our own interest: Lola Squared builds websites and beam.page, the static site tool referred to obliquely above, is our own product. The advice to delete unused plugins and diarise your renewals costs you nothing and involves us not at all.