How Much Does an Ecommerce Website Cost in the UK?
- Website Design
WordPress website maintenance is the job of keeping core, your theme and every plugin working together, and it exists because that combination is unique to your site and nobody tests it except whoever looks after it. The work is applying updates and then checking the site still does what it did before, watching for plugins whose authors have stopped maintaining them, keeping backups that have actually been restored, and removing what you no longer use. What separates a real WordPress maintenance service from an automated one is the verifying, because applying an update is the part software can do on its own.
This is the whole reason maintaining WordPress is a different job from maintaining a hosted site, and most guides skip straight past it.
A Squarespace or Wix site is one product from one company. They write it, they test it, they update it, and when it breaks it is their problem before it is yours. Your WordPress site is core from the WordPress project, a theme from one author, and anywhere between five and forty plugins from as many authors again. Each ships on its own schedule. Each is tested against WordPress, and none are tested against each other, or against your particular combination.
Nobody is responsible for the whole combination, and everything else here falls out of that. It also explains something owners find strange: the site that breaks is rarely the one updated most recently, it is the one left longest.
For the build-side picture of how the pieces fit together, our complete guide to WordPress websites covers that, and we have written up what website maintenance costs in the UK rather than repeat the pricing question here.
What actually breaks a WordPress site is very rarely core.
Core is the most heavily tested part of your stack by a distance, and a core release taking down a straightforward business site is uncommon. What breaks sites is interaction. A plugin update changes how it hooks into something. A theme was customised in a way its next update did not anticipate. Two plugins both want to control the same part of the checkout, and the update settles the argument in the wrong direction.
When a WordPress site does break, the white screen is the good outcome.
A white screen gets noticed within the hour. Somebody rings you, and it is fixed the same day. The expensive failure is the silent one. The contact form that still submits, still shows the thank-you message, and quietly stops delivering the email. Nothing looks wrong. The pages load, the form behaves exactly as it did last week, and enquiries simply stop arriving.
That runs for months, because there is no alert for “the phone has been a bit quieter lately”.
A form that has stopped delivering is the most common expensive fault we find on WordPress sites left to update themselves. Not a hack.
So an update is finished when somebody has loaded the site, submitted the form, received the email, and, if you sell online, put an order through. That takes a few minutes and it is the part that gets skipped.
Every plugin on your site is a dependency on somebody else’s continued interest.
Most plugins are built by one person or a small team. Interest fades, jobs change, plugins get sold. When an author stops, nothing announces it. The plugin carries on working, sometimes for years, right up until WordPress or PHP changes underneath it. The signals are visible well before that:
What to do is a judgement call, and the honest answer is often “nothing yet, but know about it”. Something small and self-contained can sit there unmaintained for years without troubling anyone. Anything handling forms, payments, logins or writing to your database is a replacement to plan rather than react to, and replacing one is always cheaper before it is urgent. The security half of this is a longer subject, and we have covered protecting a WordPress site from hacks separately.
Twenty-eight plugins is a more expensive website to keep than nine, and usually not a better one.
Each one is another release schedule to track, another author who might stop, another thing that can argue with the next update. Owners almost never add them carelessly. They add one to solve a problem in 2021, one for a campaign that ended, one a previous developer left behind. Nobody removed any of them, because deactivating felt like the safe option.
Deactivating is not removing. A deactivated plugin’s files are still on your server, still on whatever version they were, still not getting updates anybody is watching. It has given up its job and kept its liability.
So the discipline is: if you are not using it, delete it. If deleting makes you nervous, that is a signal to test the removal properly, not to leave it there for another three years.
Testing properly means a staging site, a private duplicate of your website nobody else can see, where you apply the update or remove the plugin and watch what happens before it touches the live one. Most decent hosts include one at no extra cost.
A WordPress backup is two things, and a surprising number of backups are only one of them.
There are the files, meaning WordPress itself plus your theme, plugins and media library. Then the database, which holds every page, post, product, order, setting and form entry you have. Restore the files without the database and you have a working WordPress install with none of your content in it. WordPress’s own backup documentation is clear that a real backup covers both.
The bigger gap is that hardly anybody has ever run a restore.
Until one has been restored, nobody knows whether it works, and the test is not complicated: put last night’s backup onto a staging copy and see whether the site comes up. If it does, you know how long it takes and who does it. If it does not, you have found out on a quiet Tuesday rather than during an incident. While you are there, ask your host where the backups live, because one sitting on the same server as your website solves fewer problems than it appears to.
Most of this work is small, regular and boring, which is exactly why it stops happening. Here is the shape of it.
| How often | What | Why it is on the list |
|---|---|---|
| Weekly | Apply plugin and theme updates, then load the site and send yourself a test enquiry | Applying is the easy half. Testing catches silent failures |
| Weekly | Confirm the backup ran, and glance at its size | A backup that suddenly halves has stopped capturing something |
| Monthly | Read the update log for anything skipped or failed | Skipped updates are how version gaps open |
| Monthly | Delete any plugin no longer in use | Stops the count creeping up |
| Quarterly | Restore a backup onto staging | The only way to know a backup works |
| Quarterly | Check each plugin’s last updated date and compatibility flag | Catches abandonment early enough to plan |
| Annually | Check your PHP version is still supported | PHP publishes an end-of-life date for every version, and WordPress publishes the versions it recommends |
| Each major release | Take core updates on staging first | Major releases are where theme and plugin conflicts surface |
WordPress flags an outdated PHP version on its Site Health screen, which is a place almost nobody looks. That table is broadly the shape our WordPress care plans follow, and the weekly rows matter most.
You can genuinely do the weekly and monthly rows. Applying updates, loading the site afterwards, sending yourself a test enquiry, deleting the plugin you stopped using in 2022. None of it needs a developer, and if somebody in your business will actually do it every week, do it and keep the money.
It stops being sensible when a restore is needed and nobody has rehearsed one, or when a fix means editing files rather than clicking buttons. It also stops once the site takes payments, because a quiet failure now costs money directly rather than costing you an enquiry.
What goes wrong is almost always the calendar rather than the skills. The job slips down the list in a busy week, then slips again, and that is how sites end up years behind with a rebuild waiting at the end.
Some of what gets sold in WordPress care plans adds very little, and it is worth being straight about which bits.
Updating everything the hour it releases. A day or two of lag costs you nothing and lets other people find the bad release first.
Running a second security plugin alongside the one already there. I would not put two on a site. Two of them compete for the same hooks and you get a slower site for the trouble.
Monthly database optimisation as a headline item. On a small business site the database is very rarely the bottleneck, so it is a line on a report more than it is a job.
A monthly PDF of uptime percentages. There is nothing you can do with 99.98%. What you can use is being told the site went down on the 14th, why, and what changed afterwards.
Automated broken link scans presented as SEO. Worth running once a year, but it is neither a monthly deliverable nor SEO work.
None of it is dishonest. It is all cheap to run and easy to describe, which is how it ends up on so many feature lists.
What does WordPress website maintenance include? Applying core, theme and plugin updates and then verifying the site still works, keeping backups that have been tested by restoring them, watching for plugins whose authors have abandoned them, deleting plugins no longer in use, monitoring uptime and security, and keeping PHP on a supported version. The verifying is what separates a real plan from an automated one.
How often should a WordPress site be updated? Check weekly. Apply plugin and theme updates with a day or two of lag after release rather than the same hour, and take major core releases on staging first. Consistency matters more than frequency. A site updated monthly without fail is safer than one updated daily until everybody gets busy.
Do WordPress plugins need updating if the site works fine? Yes. A plugin working today tells you nothing about whether its current version has a publicly known vulnerability. Version gaps also compound: the further behind you fall, the likelier the eventual update breaks something, because you are jumping several releases at once instead of one.
How do I know if a WordPress plugin has been abandoned? Look at its page in the WordPress.org plugin directory. It shows when the plugin last shipped, and flags plugins not tested with recent WordPress releases. Unanswered support threads and a closed listing are the other signals. None is conclusive alone, but together they usually are.
Are too many WordPress plugins a problem? The count matters less than what they do and whether they are maintained, but every plugin is another author who might stop and another thing to check after each update. Ten well-maintained plugins are cheaper to keep than thirty, half of them deactivated leftovers nobody deleted.
What happens if I never maintain my WordPress site? Usually nothing visible for a while, then one of two things. Something breaks quietly, such as a form that stops delivering, and runs that way for months. Or the version gap grows wide enough that updating is a project rather than a click, and you are pricing a rebuild instead of a fix.
Does maintenance stop a WordPress site being hacked? It closes the most common route in, which is running a version with a publicly known vulnerability, but nothing removes the risk completely. The other thing it buys you is that recovery becomes a restore from last night rather than a rebuild from memory. That part is worth as much as the first.
Open your own contact form, send yourself a message, and check the email actually arrives. Then look at when each of your plugins last shipped an update. It takes about ten minutes and it finds more real problems than a monitoring report will.
If you would rather somebody just did that every week without you thinking about it, you know where we are.
© Copyright 2026, All Rights Reserved by Pixelish
