Website updates — what, how often, and what not to touch yourself

You do not update "the website". You update what somebody added to it — and that is where practically all of the risk sits. That one sentence changes the to-do list more than all the advice about being disciplined.

This article is about the routine: what to update, how often, in what order, and what not to touch without a developer. External deadlines that fall regardless of your plans — the end of support for a software version, new browser requirements — are a separate conversation about modernisation.

Where the vulnerabilities really are

In 2025, 11,334 new vulnerabilities were found in the WordPress ecosystem — 42% more than the year before. That is the finding of Patchstack's annual report, which counts every vulnerability report that passed through its database during the year. But the total is not the interesting part; the breakdown is, because it overturns the most common complaint about the system:

91% of the vulnerabilities concerned plugins, 9% themes, and in the core itself six were found — all of them low priority.

The WordPress core is not the problem. The problem is what gets added to it. That has a direct practical consequence: a site with three plugins and a site with thirty are two different levels of risk, however conscientiously both are kept up to date.

This is not an abstraction for companies in Poland. The EU's cyber security agency, ENISA, whose figures we use here as the broadest available data, describes in its Threat Landscape 2025 how, from the second quarter of 2025, attackers planted fake CAPTCHA and "verify you are human" prompts on compromised WordPress sites, persuading visitors to run code that installed password-stealing malware. The site kept displaying normally; it was the site's customers who took the hit. In the same report, exploiting software vulnerabilities accounts for 21.3% of the intrusion vectors ENISA observed — not the largest share, but the share that updates exist to close.

It is worth remembering what Patchstack's number does not say. It does not say how many sites were attacked — it says how many flaws were described. A vulnerability that has been described is not the same as one that has been exploited, and most of those eleven thousand concern plugins that are not on your site. What is useful here is not the total but the proportion: whatever happens, happens in the layer you added yourselves — and that layer is the one you control.

That is why the first task in this article is not to update anything, but to write down what you actually have installed. A list of plugins with the date of each one's last update, on a single page. For a typical company website this takes ten minutes, and it usually ends with two discoveries: there are more plugins than anybody remembered, and several of them have not been developed for years.

The figure that changes the meaning of "regularly"

From the same report: 46% of vulnerabilities had not been fixed by their author in time for public disclosure.

That means that for almost half of all flaws, diligent updating will not help — there is nothing to install. The vulnerability is publicly described, the fix does not exist, and nobody knows when it will.

This shifts the centre of gravity, and it is worth saying plainly, because the whole website maintenance industry sells discipline alone:

• Update discipline protects you against half of the problem. That is a lot, and it costs nothing, so there is no reason to give it up.
• The other half needs something else: knowing that the flaw exists, and deciding what to do about it. Deactivate the plugin, block the vulnerable path on the server, replace the component with a different one.

From this follows the cheapest thing you can do apart from clicking "update": have fewer plugins. Every one you remove is one fewer decision you will have to take on the day its flaw is published.

How many plugins is too many

There is no threshold beyond which something bad happens. There is, however, a question that puts the list in order in a quarter of an hour. For each plugin: what happens if I switch it off?

There are usually three answers, and each means something different.

"The site will stop working." That is an essential plugin — a form, a shop, a booking system. It stays, but it goes on the short list of things to check after every significant update.

"Some element will disappear." A carousel, a gallery, social media icons, a map. It stays if that element has a purpose. Very often it turns out not to — because it dates from a project three years ago.

"I don't know." This is the most common answer and the most telling. A plugin nobody can explain is almost always left over from testing, from a previous developer, or from a feature that was never switched on. Deactivate it for a week and see whether anyone notices.

Two rules follow from the same breakdown of vulnerabilities:

Delete, don't deactivate. A deactivated plugin still sits on the server, still has its code and can still be vulnerable. Deactivation is convenient for you, not for security.

Don't install anything "to try it out" on the live site. This is the most common source of the "I don't know" category — somebody compared three solutions, chose one, and the other two stayed.

Paid does not mean safer

The belief that a premium plugin is more reliable by definition does not survive this data either. Paid and freemium components accounted for 1,983 reports, or 29% of the total — but 76% of the vulnerabilities found in premium components were exploitable, a higher proportion than in free ones.

The price of a licence is not a measure of code quality. It is, however, a fairly good measure of something else, and that is what is worth buying knowingly: you are paying for somebody to keep maintaining the plugin. The question to ask before buying is not "is it paid?" but "when was the last update, and how many versions came out last year?".

The scale of the threat should also be read with care. Of those 11,334 vulnerabilities, 1,966 (17%) had a high severity score, and 4,124 (36%) were judged a real threat, serious enough to require a protection rule. The rest are findings of limited practical significance — quoting the 11,334 without that breakdown would be scaremongering, not information.

Four layers, not one

"Update the website" is in reality four different operations with different levels of risk.

Core security fixes — automatically. They are narrow, tested by the publisher and released rarely. This is the only layer where automation is safer than your memory — because a flaw in the core, while rare, affects every site in the world at once and is exploited on a mass scale within hours of disclosure. A useful distinction: what installs automatically is usually the security releases, not the big feature releases. The latter are worth putting through the same process as plugins.

Plugins — manually and one at a time. This is where 91% of vulnerabilities sit, and where the layout breaks. Updating eight at once means that if something fails, you do not know which one caused it — and that is the difference between fifteen minutes and half a day. One exception worth knowing: if a plugin's changelog mentions the word "security" or a CVE number, do not wait for a convenient moment. The rest can wait for the scheduled quarter of an hour.

Theme and its add-ons — manually, after making a backup. A theme update can overwrite changes made directly in the template. If somebody once "fixed something in the code", this is where it will disappear — without warning or trace, and rebuilding it means remembering what it was. The intended solution is a child theme, where your own changes live separately and survive the update. If you do not know whether you have one, that is a single question for your developer, and it is worth asking before the first theme update, not after.

PHP version — not without a developer. This is not an update but a change to the environment in which the site runs. It can bring everything down at once, and reversing it requires access to the hosting. When it has to be done regardless of your plans is settled in the article on modernisation.

There is a fifth layer that nobody thinks of as an update, and which can break the site just as well: scripts pasted directly into the template. A pixel, a chat, a reviews widget, a counter. They do not appear on the list of plugins, they have no version number and nobody updates them — but when the provider changes the way they are embedded, they stop working or start blocking the page from loading. Review them at the same time as the plugins.

Finally, a word on what is not an update. The campaigns ENISA describes work because a prompt on a web page asks the visitor to run, install or "verify" something — and a request to install an update is one of the most convincing forms that prompt can take. The rule is simple: genuine updates to your site are started from the admin dashboard or at your hosting provider, never from a window that pops up on a web page or from a link that arrived by email.

Who does it, and how long it takes

The honest answer to the question of time: for a typical company website it is a quarter of an hour once a month, if nothing surprises you, plus an hour once a quarter to review the plugin list. That is well within reach of a non-technical person, provided they have access to the dashboard and a backup.

Handing it to somebody outside makes sense in three cases:

Nobody in the company logs into the dashboard. If the only person who ever logged in was the developer, nobody will notice that something is waiting for an update.

The site earns money. For a shop or a booking system, the difference between a failure spotted within the hour and one spotted after the weekend can be put in numbers — and that, not the update itself, is what you are paying for.

You have plugins that cannot safely be touched by yourselves. Usually these are solutions heavily customised for you, or integrations with an external system.

To give an order of magnitude, here are our own prices, as they appear in our website maintenance cost calculator: an update routine once a month for PLN 100 a month, every two weeks for PLN 150, weekly for PLN 250, excluding VAT. These are our list prices, not a survey of the Polish market. What the amount buys is not the quarter of an hour of clicking: it is the backup taken beforehand, the check afterwards, and somebody who knows how to roll back when a plugin breaks the contact form.

What is not worth buying: maintenance packages in which "updates" are the only line item. That is a quarter of an hour of work a month — if the price looks like much more than that, you are paying for something else, and it is worth asking what exactly.

The order that does not break the site

Six steps. For a company website it is a quarter of an hour a month, if nothing surprises you.

1. A backup — before, not after. Not "we have backups", but a fresh one, from today. Why those are two different things, we explain separately.
2. If you have a staging environment — there first. If you don't, go to step three and make up for it with caution.
3. Core first, then everything else. The reverse order sometimes causes conflicts, because plugins are released for the new version of the system, not the old one.
4. Plugins one at a time, with a check after each. The check takes thirty seconds: the home page, one service page, the contact form.
5. Finally, look at the site on a phone. The most common fault after an update is not a server error but a broken layout — and that only shows on a narrow screen.
6. Write down the date and what was done. One sentence, in the same document where you keep the access details. When the next failure comes, it is the first thing anyone looks for.

What exactly to check in step four for it to mean anything: the home page, one service page, the contact form, and the basket if there is one. Four places, thirty seconds. The temptation to check only "whether the site opens" is strong and useless — the site almost always opens; what breaks is whatever has state: the form that stopped sending, the payment that stopped going through.

When to do it: not on Friday afternoon and not before a holiday. It sounds trivial, and it is the most frequently broken rule on the list — a failure discovered on Monday morning has had three days to gather consequences.

When an update takes the site down

Three symptoms cover most cases, and each calls for a different first reaction.

A white page with no message at all. Usually a conflict between a plugin and the new version of the core or of PHP. First step: deactivate the most recently updated plugin. If you have no access to the dashboard, you do it by renaming the plugin's folder from the hosting side.

A 500 error or a "critical error" message. The same origin, but in this case WordPress usually sends an email to the administrator's address with a link to recovery mode. It is worth knowing which address that is — it is sometimes a mailbox from two developers ago.

The site works, but it looks different. Most often an overwritten theme, or a layout plugin that changed how it behaves. This is the case where restoring a backup is sometimes faster than hunting for the cause.

The rule common to all three: undo the last change, not all of them at once. If you updated one thing at a time, you know which one — and that is precisely why you update one thing at a time.

What to do when undoing does not help: restore the backup and leave the problem for later. That is not a defeat, it is the right decision — a site that works on the old version is in a better state than one that does not work on the new. The cause can be found the next day, calmly, preferably on a copy of the environment rather than on the live site.

And one thing that gets forgotten in a panic: check whether others see the problem too. Sometimes the site "doesn't work" only in your browser, because it is holding an old version of the files in its cache. Opening it in a private window or on a phone takes ten seconds and is sometimes the whole solution.

Three things we hear most often

"We don't update, because it works." It works until the day it doesn't — and with 46% of flaws lacking a fix, "it works" does not mean "it is safe". More importantly, the longer you go without updating, the harder the first update becomes. Jumping two years is not the same operation as jumping one month.

"We have automatic updates, so that's taken care of." Automation closes the core layer. It does not close plugins abandoned by their authors, it will not notice that something stopped working after an update, and it will not take the decision about a component with a flaw and no fix.

"That's a job for IT." Within the scope of this article — no. A backup, clicking "update" one item at a time and checking three pages are administrative tasks, not programming. A developer is needed for the PHP version and for plugins customised for you — two situations out of a dozen or so.

A shop is a different category

Everything above concerns a company website. For an online shop, three things change enough to be worth listing separately.

A staging environment stops being a luxury. For a brochure site, a failure costs reputation; for a shop, it costs orders in real time, so updating "live" becomes indefensible.

Payment and shipping integrations need checking separately. These are usually third-party plugins that change independently of your shop — and they are the ones most likely to stop working silently, without any message. The check means placing a test order, not looking at the page.

Timing has a monetary value, not just an organisational one. An hour of downtime on a Friday afternoon and an hour on a Tuesday morning are two different amounts, and for a shop you can calculate both from your own sales figures.

What to check once a year

The monthly routine takes care of the current risk. Once a year it is worth looking at the things that do not announce themselves, because they never appear as a red badge in the dashboard.

• The server software version. One question to your hosting provider or one screen in its control panel. This is the layer that does not update itself and that people only remember when something fails.
• Plugins with no update for more than a year. They are not stable, they are abandoned — and it is precisely in them that the flaw without a fix appears.
• Whether the theme has a child theme, if anybody ever changed anything in the code.
• Whether the backup can actually be restored. Not whether it exists — whether somebody has restored it, and how long it took. That is a separate topic, and the one most often skipped.
• Who has access to the dashboard. After a year, the list of accounts looks different from what you remember; we take this apart in the article on how to secure a website.

The whole review takes an hour once a year. It is the only item in this article that needs to go in a calendar — the monthly routine reminds you by itself, because the dashboard shows the number of pending updates. The annual review will never remind you.

What this article deliberately leaves out

• External deadlines and the end of support for software versions — that is modernisation, a separate decision with its own calendar.
• Backups — separately, with the question of who last restored one.
• Access control and dashboard accounts — how to secure a website, which also covers what the threat data for Poland says about how attackers get in.
• The full cost of website maintenance — that belongs to the maintenance section, not to security.

The shortest summary: update one thing at a time, back up before, and take the rest of the risk off the table by deleting plugins you don't use. Discipline closes half of the problem — no discipline will close the other half, because for 46% of flaws there is nothing to install.

If we had to keep a single sentence from this article, it would be this: the most effective update is deleting something you don't use. It needs no backup, it does not break the layout, it has no version and it will not appear in any vulnerability report — because nobody attacks a component that is not there. On a typical company website, the first clear-out of this kind removes anywhere from a few to a dozen or more items from the list, and it is the only step in this article after which the risk falls for good, not just until the next release.