The short answer: website maintenance is the routine work that keeps a site secure, fast and working - updates, backups, security, monitoring, content upkeep and testing. Done on a schedule, it's cheap and low-key. Left until something breaks, it's urgent and expensive. Score your own site's posture in two minutes.
The essentials:
- Maintenance is six jobs, most of them small: updates, backups, security, monitoring, content hygiene and testing.
- Automation genuinely covers the daily layer - but it can't test, judge or fix. That gap is where sites actually break.
- Reactive feels free until the Friday evening something goes down. Proactive is low-key on purpose.
Written for UK business owners and marketing managers who own a website - WordPress or otherwise - and want to know what looking after it properly involves, and what they can safely ignore.
Most people don't think about website maintenance until the contact form stops sending, the padlock turns into a security warning or a plugin update takes the checkout down. Then it stops being a vague line on an agency quote and becomes very real - usually at a bad time.
This guide explains what maintenance actually involves: the six jobs behind the word, how often each one needs doing, what the auto-update tick-box genuinely covers and who should do the rest.
We host and maintain business sites for a living - on WordPress and on .NET - so we'll also be specific about the part the marketing glosses over: which of these jobs a machine can do on its own, and which still need a human who tests things.
What website maintenance actually involves
Strip the jargon away and website maintenance is six jobs. Most guides list a baggy 11 or 12; they collapse into these, and the last two are the ones almost everyone skips.
The six jobs
- Updates. Keeping the platform, plugins and themes current. Unpatched software is the single most common way sites get compromised - the overwhelming majority of new WordPress vulnerabilities are in plugins and themes, with the core itself accounting for a handful a year.
- Backups. Taken automatically, stored away from the site itself - and restore-tested. A backup you've never restored is a hope, not a protection.
- Security. Scanning for malware and vulnerabilities, a firewall in front of the site and someone who acts on what the scanners find.
- Monitoring. Knowing the site is up, fast and error-free - and having someone who responds when it isn't, rather than a dashboard nobody reads.
- Content hygiene. Fixing broken links, pruning stale pages and unused plugins, keeping legal pages and the copyright year current. Unglamorous, and it quietly protects both trust and rankings.
- Testing. Checking updates somewhere safe before they touch the live site, and checking the journeys that earn you money - forms, checkout, booking - actually work, on a schedule.
Hosting, support or maintenance?
Worth untangling three words that get sold together: hosting is the server your site runs on (our managed hosting guide covers that layer), support is a human fixing or changing things on request (what good support looks like) and maintenance is the routine care in between. A hosting invoice doesn't mean anyone is maintaining the site.
When an agency sells a "care plan", it's bundling these six jobs plus cover for when things break anyway - our care plans guide breaks down exactly what a good plan includes, so we won't repeat that here.
Who does what: platform, host and you
The commonest maintenance mistake isn't laziness - it's assuming someone else is doing it. Website builders and managed hosts genuinely do automate parts of the job, and their marketing rounds "parts" up to "all of it". Here's the actual split.
| The job | Website builder (Wix, Squarespace) | Managed WordPress hosting | Ordinary hosting + WordPress | Static site |
|---|---|---|---|---|
| Platform updates | Handled for you | Core usually handled; plugins vary | You | Little to update |
| Backups | Platform-level | Included - restore-testing still yours | You | Simple |
| Security scanning | Platform-level | Often included | You | Minimal surface |
| Uptime monitoring | Their platform, their problem | Often included | You | You (cheap to do) |
| Content hygiene | You | You | You | You |
| Testing & verification | You | You | You | You |
Read the bottom two rows. Whatever you pay for, nobody upstream checks that your content is current, your forms deliver enquiries or an update left your checkout working.
Hosting marketing that promises "hands-off maintenance, like a maintenance crew for a building" is describing the building; the shop inside it still needs a keeper. The judgment work always stays with the owner - or with whoever the owner explicitly pays to take it on.
The maintenance calendar: what needs doing, and how often
Here's the whole routine for a typical business site, as a printable schedule. It's deliberately prioritised - a short list done consistently beats a 27-task checklist done never.
| Cadence | Time | The work |
|---|---|---|
| Weekly | 15-30 min | Apply plugin and theme updates with a backup taken immediately first; glance over the site afterwards; check uptime and security alerts actually reached someone. |
| Monthly | 30-60 min | Test the money journeys - submit every form and confirm the enquiry arrives, run a test checkout if you sell. Check for broken links and 404s. Review page speed and Core Web Vitals. Remove anything you installed and stopped using. |
| Quarterly | 1-2 hrs | Restore a backup somewhere safe and prove it works. Review user accounts, passwords and two-factor authentication. Sweep for stale content and out-of-date legal pages. Database and media housekeeping. |
| Annually | 2-4 hrs | Audit domains, certificates and plugin licences before they lapse. Check PHP - the language your site runs on - and the platform are still on supported versions. Step back and review whether the design and content still earn their keep. |
Two of those line items do most of the protective work: the pre-update backup and the quarterly restore test. Security patches are the exception to the weekly rhythm - when a critical vulnerability is disclosed in something you run, the window for applying the fix is measured in hours and days.
The two-minute check below scores your site against this routine - and if the interactive version won't load, this table is the answer sheet.
Proactive vs reactive: the two ways sites are actually run
Every website is maintained in one of two modes, and most owners never consciously chose theirs.
Reactive is the default: nothing happens until something breaks, then everything happens at once - the panicked message to whoever built the site, the emergency invoice, the quiet month afterwards, repeat. It feels free because the quiet months cost nothing.
Proactive is the calendar above: a small, scheduled cost and small, routine fixes - the broken thing found on a Tuesday morning by a monitor, while it's still invisible to customers.
What neglect actually looks like
A reactive site doesn't fail on day one. Updates pile up until applying them becomes a risk in itself. Pages slow down; links rot; the contact form breaks silently, and the leads just stop.
Then the forcing event arrives: a known vulnerability in an outdated plugin gets exploited, or a long-deferred update cascade takes down the layout, or the certificate lapses and every visitor meets a browser warning.
On WordPress the failure even has a name - the white screen of death. Since version 5.2 a fatal error triggers recovery mode and emails the site admin a rescue link, which is genuinely useful and quietly revealing.
The safety net assumes somebody is reading that inbox, knows what to deactivate and has a backup to fall back on. Recovery mode is a parachute, not a pilot.
The cost asymmetry
The economics of the two modes aren't close, because prevention is priced calmly and emergencies aren't. UK maintenance work bills at ordinary rates on a schedule; the same work bought urgently - out of hours, site down, revenue stopped - commonly runs at a multiple of them.
| The job | Proactive (part of a monthly routine) | Reactive (bought as an emergency) |
|---|---|---|
| Security | Scanning, a firewall and patches applied within days - minutes of routine attention | Professional clean-up runs from fixed-fee malware removal at £60-£300 to £500-£5k+ where a rebuild is needed - plus blacklist removal and the trust repair, all at urgent speed |
| Updates | Tested against a staging copy, applied with a backup taken first | Emergency developer time to untangle a broken live site - UK emergency call-outs typically bill £100-£250 an hour, roughly double standard rates |
| Uptime | Monitoring that alerts someone who responds - pounds a month | Unsold orders, missed enquiries and staff fielding "is the website down?" instead of working |
| Backups | Automatic, off-site, restore-tested quarterly - pennies a day in storage | If the data is unrecoverable, there is no price column for this row |
The 9pm Friday test
Picture the reactive version concretely. At 9pm on a Friday, a plugin auto-update fails halfway on a small online shop. Checkout dies quietly - no fatal error, so no recovery mode; just a routine "your site updated" email that nobody reads until Monday.
The owner finds out on Sunday night from a customer who couldn't pay; a weekend of orders never happened. The developer who takes the call books emergency time at the weekend multiple, and the first hour goes on working out what changed.
Set that weekend against a routine that would have caught it: a staged update, a pre-update backup, a monitor checking the checkout journey. One bad rescue tends to cost more than a year of the routine version - which is the entire argument for the routine version.
When reactive is genuinely fine
Fairness demands the other side. If you run a static brochure site - no database, no plugins, no payments - and a day of downtime would cost you little, a quarterly once-over plus automatic certificate renewal is a defensible posture.
Few sites need the full routine at full intensity - what matters is choosing the reactive posture deliberately, with open eyes, rather than drifting into it. (For your company's IT estate the same trade-off has its own name - see our break-fix vs managed IT explainer.)
Rather never have that nightmarish weekend? Our hosting builds the proactive routine in - staging-tested updates, restore-tested backups and monitoring someone actually answers. See the plans and prices, or talk to a UK engineer.
Isn't automation enough? What auto-updates can and can't do
Here's the objection this whole subject turns on: WordPress can auto-update itself, backups can be scheduled, scanners run on their own - so why pay anyone anything?
The strongest case for automation
Let's make the automation case properly, because it's strong. The daily layer - uptime pings, scheduled backups, malware scanning - genuinely runs itself. Minor core security releases auto-apply by default - they have since 2013 - and are deliberately small, backported fixes.
Speed matters more than judgment for patching: with around half of high-impact WordPress flaws exploited within 24 hours of disclosure, no human routine patches faster than a machine. Recent WordPress versions can even detect a failed plugin auto-update and roll it back. And for a site nobody is going to look after at all, auto-updates on is strictly safer than auto-updates off - an updated site with occasional breakage beats an outdated one with known holes.
Where automation stops
All true. And still not the whole job - because automation schedules work; it doesn't verify it. Here's where the line actually sits.
| What automation does well | What still needs a human |
|---|---|
| Uptime monitoring and alerting, around the clock | Responding to the alert - monitoring without response is just a log of your downtime |
| Scheduled, off-site backups | Restore-testing them - proving the backup turns back into a working site |
| Malware and vulnerability scanning | Judging and acting on what the scanners find |
| Minor core patches and security point-releases | Major versions - the ones that change behaviour and raise server requirements |
| Auto-updating low-risk utility plugins | The money-page plugins - builders, checkout, booking - where a silent failure costs revenue |
| Rolling back an update that fails fatally | Noticing non-fatal breakage - the page that loads fine but renders or behaves wrong |
| Cache purges, licence reminders, the copyright year | Content hygiene and journey testing - two of the six jobs, entirely human |
The right-hand column is where the failures live. Auto-updates run on the site's own scheduler, typically twice a day - so an update can land at 2am. WordPress does email the admin that it updated; what no email can say is whether the site still works. A layout quietly breaks, a checkout button vanishes and the first monitor to notice is a customer.
This year's WordPress 7.0 sharpened the point by raising the platform's minimum PHP version: a site left to update itself onto a server that can't run the result is an outage you scheduled for yourself.
None of this is theoretical. In mid-July 2026 WordPress shipped an emergency core security fix on a Friday and force-pushed it through auto-update; exploitation was confirmed in the wild over the weekend - the rare core-side flaw (there were six in the whole of 2025).
The telling detail: the owner's job that weekend wasn't applying the patch, it was checking it had actually landed. A site with auto-updates switched off - or a silently broken scheduler - stayed exposed.
There's a quieter tell in how the market prices this. The cheapest maintenance tier sold anywhere is, almost word for word, "automated updates and basic monitoring" - the market itself prices automation as the entry tier of maintenance.
Even the vendors selling the automation hedge in their own documentation: backups "shouldn't replace" a managed routine, auto-updates "can't be left to chance" and the firmest advice to switch everything on is aimed at sites that would otherwise get no attention at all.
So the answer to "isn't automation enough?" is: automate the floor, absolutely - then make sure someone owns the verification layer on top. Maintenance is automation plus testing plus judgment. Which brings us to the obvious question: how much of that layer does your site have today?
Is your site proactively maintained? A two-minute check
The check below runs 10 yes-or-no signals, straight from the routine above. Tick what's true today and you'll get a plain reading of where your site sits - proactive, partially covered or reactive - and which gap to close first. No email address, no sales call.
Tick what's true of your site today, and your reading appears here.
Close these first:
All 10. Genuinely rare - keep the restore tests and update notes going, and this page has nothing left to teach you.
How this is scored
The five essentials are the signals whose absence causes emergencies - missing two or more of them reads as reactive however much else is ticked, and missing one caps the verdict at partially covered. Proactive needs all five essentials plus most of the quality signals. It's editorial guidance to help you decide what to fix first; the reasoning behind each signal is in the guide above.
The interactive check didn't load, but you don't need it: the maintenance calendar above is the same standard - work down it and note what your site doesn't currently get.
Who should do it: DIY, cheap plan or engineering-led?
There are three workable ways to get the routine done, and the right one depends on what your site is for.
Do it yourself. Entirely viable for a simple site if you'll keep the schedule: roughly half an hour a week plus the monthly and quarterly blocks - call it two to four hours a month. The tooling is cheap; the real cost is consistency, because DIY maintenance is the first casualty of a busy month, and the gaps are invisible until something breaks.
A cheap plan. At the bottom of the market, plans are mostly the automation floor - scheduled updates, a backup job, a dashboard - with a reassuring name on top. Watch for two tells.
Plans priced below what the tooling and any human time could possibly cost are automation-only by necessity, whatever the feature list says. And "unlimited edits" almost always means unlimited small requests - capped per task, scoped to exclude precisely the testing and judgment work this guide is about. Neither tell makes a cheap plan useless; both mean you should know what you're actually buying.
Engineering-led. The version where humans do the verification layer: updates tested against a staging copy before they go live, backups proven by restore, monitoring that pages someone and a report of what was done. It costs more because testing takes time - that's the entire difference, and for a site that takes money or generates your leads, it's the difference that matters.
- Brochure site, no transactions: DIY or a modest plan is a perfectly sound choice - just do the quarterly restore test.
- Lead-generation site: the monthly form test is non-negotiable, whoever does it - a dead form is invisible from the outside.
- Shop, bookings or membership: staging-tested updates and journey monitoring stop being nice-to-haves - a silent checkout failure is unsold stock by the hour.
What each option costs, band by band, is its own subject - our website maintenance cost guide walks the full UK price ladder, and its price checker will place a quote you've been given. For what a packaged care plan should include, see the care plans guide.
How Red Eagle Tech does it
Since we've spent the guide describing what good looks like, here's how we run it - and you can hold us to the standard above.
- Updates are staged, then shipped. Changes go through a staging copy with visual-regression checks - screenshots compared before and after - so we catch a layout break before your visitors ever see it. Rollback is a standard part of the workflow.
- Backups are proven by restore. Off-site, automatic and restore-tested - the quarterly discipline from the calendar above, done for you.
- Monitoring reaches a human. Uptime and journey checks alert engineers who respond, around the clock - monitoring with nobody behind it is just a downtime diary.
- It's engineering-led across platforms. We maintain WordPress estates and .NET applications with the same routine - this isn't a plugin dashboard with a logo on it.
- The prices are published. Every plan and every figure is on the website, monthly rolling, and you can buy online without booking a call.
Want the routine without the routine? Our managed WordPress hosting builds every job in this guide into the plan - staging-tested updates, restore-tested backups, monitored journeys. See the plans and prices, or talk to a UK engineer first.
Frequently asked questions
Website maintenance is the routine work that keeps a site secure, fast and working properly: applying software updates, running and testing backups, security scanning, monitoring uptime and performance, keeping content accurate and testing that key journeys like forms and checkout still work. Done on a schedule it's quick and mostly invisible. Skipped, it resurfaces later as a hack, a broken page or an emergency invoice.
Six jobs. Updates - keeping the platform, plugins and themes current. Backups - taken automatically and, crucially, test-restored. Security - scanning, firewalls and acting on what they find. Monitoring - knowing the site is up and fast, and responding when it isn't. Content hygiene - fixing broken links, pruning stale pages and unused plugins. And testing - checking updates before they go live and key journeys after. Most guides list the first four and quietly skip the last two, which is where sites actually break.
Security patches should go on within days - around half of high-impact WordPress vulnerabilities are exploited within 24 hours of being disclosed, so waiting for a monthly window is too slow for those. Routine plugin and theme updates suit a weekly or fortnightly pass with a backup taken first. Major version upgrades deserve a staging test before they touch the live site. Time-sensitive content deserves a monthly once-over, with a quarterly sweep as the floor - and the design a proper review every two or three years.
Yes, though how much varies by site. Software that never gets patched accumulates known, published vulnerabilities - and around 43% of UK businesses reported a cyber attack or breach in the last year - including 46% of small firms. Beyond security, links rot, forms silently stop sending and slow pages quietly cost rankings and enquiries. A simple brochure site needs less than a shop - but no site needs zero.
Nothing, at first - which is exactly the trap. Over months, updates pile up until applying them becomes risky in itself. Pages slow down, links break and the contact form fails without telling anyone. Then something forces the issue: a plugin vulnerability gets exploited, an update cascade breaks the layout or the SSL certificate lapses and every visitor sees a security warning. At that point the work happens anyway - as an emergency, at emergency prices.
Partly, and the marketing makes it sound like more than it is. Managed hosting typically patches the platform, runs backups and watches uptime - genuinely useful. But it doesn't test whether an update broke your checkout, restore-test your backups against your definition of working, fix your content or check your forms still deliver enquiries. The judgment work stays with you. Hosting looks after the building; maintenance looks after your shop inside it.
For minor core releases and security patches, yes - they're the right default and historically very reliable. For major versions and for plugins that run your money pages - page builders, WooCommerce, membership and booking plugins - be careful: those are the updates that change behaviour, and an unattended failure there costs real revenue. A sensible split is auto-update the low-risk layer, and put anything that could break checkout through a staging test with a human looking at the result.
You've automated the floor of it, which is genuinely worth having - but automation schedules work, it doesn't verify it. Nothing in that setup tests an update before it reaches your live site, notices a page that renders wrong, proves your backup actually restores, judges whether a major upgrade suits your server or fixes anything that breaks. That verification-and-judgment layer is the part of maintenance that prevents the expensive failures, and it still needs a human.
On WordPress, a fatal error puts the site into recovery mode and emails the admin address a special login link so you can disable the offending plugin or theme. That safety net assumes someone reads that inbox and knows what to do next - and it only catches fatal errors - a page that still loads but looks or behaves wrong sails straight past it. The reliable insurance is a backup taken immediately before every update, so the worst case is a restore rather than a rebuild.
Yes, if the site is reasonably simple and you'll actually keep the routine. Budget roughly half an hour a week for updates and checks, plus a longer monthly and quarterly block for testing, housekeeping and a restore test - call it two to four hours a month done properly. The usual failure mode isn't ability, it's consistency: DIY maintenance tends to be the first thing dropped in a busy month, and the gaps are invisible until something breaks.
For a typical small business site, roughly one to three hours a month when it's done on a schedule: a 15-30 minute weekly pass for updates and alerts, a monthly block for link checks, form tests and performance, plus a quarterly deep pass for a restore test, security review and content sweep. On a managed plan your own time drops to close to zero. The same work compressed into an emergency routinely takes longer than a year's worth of the routine.
UK maintenance and care plans mostly sit between about £30 and £240+ a month ex VAT, depending on how much human work is included - the cheap end is largely automation, the upper end includes testing, fixes and support time. DIY costs your hours plus a small tooling spend. Our separate guide to website maintenance costs breaks down every band, what's included at each price and the questions that expose a plan priced below the work it claims to include.
Hosting is the infrastructure your site runs on - the server, its uptime and its security. Maintenance is the routine care of the site itself - updates, backups, monitoring, content and testing. Support is a human fixing or changing things on request, from a broken page to a new feature. They're often sold bundled, which is why they blur - but a hosting bill doesn't mean the site is maintained, and a maintenance plan isn't the same as having someone to call.
Far less - and it's worth being straight about that. A static site with no database, no plugins and no transactions has a fraction of the attack surface, so a quarterly once-over of content, links, forms and certificate renewal can genuinely be enough. The moment a site takes payments, holds customer data or generates your leads, the calculation changes: the cost of it silently breaking outgrows the cost of looking after it.
Sources
- W3Techs, Usage statistics of content management systems - WordPress market share - w3techs.com, accessed July 2026
- Patchstack, State of WordPress Security - critical vulnerability exploitation windows and plugin/theme share - patchstack.com, 2026
- gov.uk, Cyber Security Breaches Survey 2025/2026 - share of UK businesses reporting attacks or breaches - gov.uk, 2026
- wordpress.org, Statistics - PHP and WordPress version distribution across active sites - wordpress.org/about/stats, accessed July 2026
- wordpress.org developer documentation, Recovery mode and fatal error handling (WordPress 5.2+) - developer.wordpress.org, accessed July 2026
- The Repository, coverage of Patchstack's 2026 WordPress security report - exploitation-window data - therepository.email, 2026
- WordPress.org release archive, WordPress 7.0 release notes and server requirements - wordpress.org, 2026
- Cloudways, Should you enable WordPress auto-updates - update scheduling behaviour and exploitation-window data - cloudways.com, 2026
- DreamHost, WordPress automatic updates guidance - backups and rollback behaviour - dreamhost.com, accessed July 2026
- Kinsta, WordPress automatic updates guide - the case for managed oversight - kinsta.com, accessed July 2026
- Wordfence, To auto-update or not - auto-update risk scenarios including supply-chain exposure - wordfence.com, accessed July 2026
- FatLab Web Support, The case for WordPress auto-updates - risk asymmetry of updated vs outdated sites - fatlabwebsupport.com, accessed July 2026
- Tenacity, The real cost of WordPress ownership - proactive vs reactive cost categories and emergency-rate multiples - tenacity.io, January 2026
- WP Umbrella, WordPress maintenance checklist - task cadences for professional maintenance - wp-umbrella.com, 2026
- ALT Agency, WordPress website maintenance guide - prioritised maintenance and restore-testing discipline - altagency.co.uk, accessed July 2026
- Toast Design, Website maintenance services - published UK support-time pricing - toastdesign.co.uk, accessed July 2026
- Dotwise, Website maintenance - rebuild-tested off-site backups practice and published rates - dotwise.uk, accessed July 2026
- Fixed.net and WP Manager, published fixed-fee malware-removal pricing - fixed.net / wpmanager.co.uk, accessed July 2026
- Core Web, published 24/7 emergency WordPress support menu (UK £) - coreweb.co.uk, accessed July 2026
