Website maintenance: the short answer
Website maintenance is the work that keeps a live site secure, working and accurate after launch. It covers software updates, backups someone has actually restored, renewals of the certificate and domain, checks that forms still deliver, and keeping the content true. How much of it there is depends on how the site was built. Who does it should be written down, job by job.
The failures that cost enquiries rarely look like failures. The contact form shows its thank-you message while the enquiry lands in spam. A script the site loads changes owner, or the certificate behind the padlock expires on a Saturday. Each time, the site looks fine to the person who owns it.
This guide is for founders and operations leads at UK and EU companies of 10 to 200 people. You have a live website, and either a maintenance plan on offer or nobody clearly in charge. We build websites for companies across Europe and offer upkeep after launch, so weigh our view with that in mind. The section on when you don't need a plan is there because sometimes you don't.
What website maintenance involves: nine jobs
Maintenance is nine separate jobs, and they fail in different ways. Maintenance plans tend to lead with the first two. The ones that hurt small companies sit lower down.
| Job | What goes wrong if nobody does it | How often | Usually done by |
|---|---|---|---|
| Software updates | Known security holes stay open | Critical fixes within 14 days; the rest monthly | Developer |
| Backups and test restores | The backup is missing, broken or on the same server | Automatic backups daily or weekly; a test restore at least once a year | Developer, checked by you |
| Monitoring | You hear about an outage from a customer | Continuous and automatic | Developer or host |
| Forms and email delivery | Enquiries vanish while the site looks fine | A test enquiry every month | You |
| Certificate renewal | Browsers show a full-page security warning | Automatic, with someone watching the dates | Developer or host |
| Domain renewal | The website and your email stop together | Yearly, or on auto-renew | You, in your company's name |
| Third-party scripts | Code you didn't write changes under you | Twice a year | Developer |
| Speed | Pages slow down as photos and scripts pile up | Every quarter | Developer |
| Content, listings and logins | Old staff, wrong hours, and ex-suppliers who can still log in | Content monthly, logins quarterly | You |
The rows marked "You" stay with you whoever you hire. Nobody outside the company knows that your opening hours changed or who left last month. The rest can go to a developer, the host or the platform, depending on how the site was built.
How the build decides how much maintenance there is
The platform sets the size of the job. A WordPress site with twenty plugins has more than twenty things to update, before you count the server software under them. A static site, where every page is generated in advance as a plain file, has no plugins, no database and no login page on the live server. On a hosted builder, the platform does most of the technical work for you.
| How the site is built | What still needs maintaining | What the platform does | Where it usually slips |
|---|---|---|---|
| WordPress with a theme and plugins | Core WordPress, the theme, every plugin, the PHP version, the database | WordPress installs its own minor security releases by default | Plugins left for a monthly check-in; an old PHP version |
| Custom-built and static | The code libraries used to build it, the hosting account, the scripts it loads | No database or admin login on the live server | Libraries left alone until an urgent change needs a rebuild |
| Custom-built with a CMS or server code | The framework, libraries, CMS, server runtime and database | Depends on the host | The problems of both rows above |
| Hosted builder, such as Wix, Squarespace or Shopify | Content, the domain, apps you add, who has access | Software updates, hosting, security and certificates | Add-on apps, and a domain registered somewhere else |
Our comparison of WordPress and custom-built websites covers the plugin side in detail, including how quickly attackers move once a flaw is public. This site is static: each page is a plain HTML file. That removes most of the updating. The renewals, the scripts it loads and the contact form still need watching.
The failures that don't look like failures
A well-built site fails gracefully, and that hides its failures. Missing photos show their captions. A form can show its thank-you page after the message failed to send. Looking at your site proves only that something loaded, so maintenance has to check what the site does, not how it looks.
Start with email. Since 1 February 2024, Google has required everyone sending to personal Gmail accounts to authenticate their email with SPF or DKIM. These are DNS records that prove a message comes from the domain it claims. Google warns that unauthenticated mail may be marked as spam or rejected.
Google also tells senders not to put Gmail addresses in the From line of mail Gmail didn't send, and many website forms do exactly that. They send each enquiry "from" the visitor's own address so that pressing reply works. To a mail server, that looks like your website impersonating the visitor's email provider.
The form on this site puts the visitor's address in the reply-to field instead. If sending fails, the page says so and shows our email address rather than a thank-you.
Scripts are the second case: more than 100,000 sites loaded a small script from cdn.polyfill.io that helped old browsers run modern code. In February 2024, a company called Funnull bought the domain and the project's GitHub account. By June, Sansec reported that the script was sending some mobile visitors to scam and betting sites.
The site owners hadn't changed anything, and because the code targeted phones, an owner checking on a laptop saw nothing wrong. Google's Security issues report makes the same point: a hacked page can carry a warning in search results or the browser, which you may not see yourself. Register the site in Search Console in your company's name, and read that report.
So the useful check is about behaviour. Send a real enquiry through each form, from your phone, and confirm it reached the person who answers enquiries. Ask your developer for a list of every script and service the site loads from elsewhere, and who runs each one.
Updates: everything under your site has an end date
Every layer under a website runs on software with a published support schedule. When support ends, the security fixes stop, and any flaw found afterwards stays open. The PHP project, which makes the language WordPress runs on, supports each version for four years. PHP 8.2's security support ends on 31 December 2026, so a site still on it has three months to move.
How fast should updates go on? The UK's Cyber Essentials scheme is a sensible bar. It asks certified organisations to install critical and high-risk security updates within 14 days of release, and to remove software once it's no longer supported. A monthly update round can miss that by more than two weeks.
There's a legal angle too. A contact form collects names, email addresses and phone numbers, which makes your site part of how you handle personal data. The ICO's security guidance for UK GDPR lists keeping software in support and patched among the typical measures it expects.
On a static or custom site, the list is shorter but not empty. Its code libraries need updating when fixes come out, and its build tools need to stay on supported versions. Leave them for two years and the next small change turns into a repair job.
Backups: only a restored backup counts
Three things decide whether your backup would work on the day you need it: where it's stored, whether anyone has tested it, and whose job your contract says it is. A fire in Strasbourg tested all three.
On the night of 9 to 10 March 2021, fire destroyed one of OVHcloud's data centre buildings in Strasbourg. France Bati Courtage, a French building-works brokerage, ran its websites on an OVH server and had signed up for OVH's automatic backup option. On 3 April, OVH told it the backups were lost too. All three copies had been stored in the same building as the server.
In January 2023, the commercial court in Lille ruled that the backup contract meant storage physically separate from the server. It found OVH in breach and set aside its force majeure clause. Another OVH customer, Adomos, lost its claim at the same court. It had bought hosting without a backup option, and the Douai court of appeal agreed in 2024 that its contract left backups to the customer.
Same fire, opposite results, decided by what each contract said about backups. If your hosting contract doesn't say who backs up the site, assume it's you.
UK GDPR points the same way. The ICO says your measures must let you restore access to personal data in a timely manner after an incident. Ask for three things in writing: where the backups are stored, how long they're kept, and the date of the last test restore. At least one copy should sit with another provider, or in another region.
Certificates and domains: renewals come round faster now
The certificate behind the padlock is getting shorter-lived by rule. Since 15 March 2026, a publicly trusted certificate can last at most 200 days. The limit falls to 100 days in March 2027 and to 47 days in March 2029. Renewal has to be automatic, and someone has to notice when the automation stops.
The reminder you may be counting on has gone. Let's Encrypt, the free certificate authority many sites use, stopped sending expiry emails on 4 June 2025. Certificate monitoring now has to be set up on purpose. When we run a client's monitoring, expiring certificates are on the list.
Domains fail more quietly still. For .com and other generic domains, ICANN requires registrars to send renewal reminders about a month and a week before expiry to the registrant. If the contact address belongs to someone who left, or to your old agency, nobody reads them. An expired domain stops working before it's deleted, and it takes your website and your email down together.
Put the domain on auto-renew, in your company's name, with a contact address your company controls, such as a shared admin inbox. Our guide to whether you own your website shows how to check whose name is on it.
Who should do website maintenance
Split it by job rather than handing the whole site to one person. Your team owns the content, the monthly behaviour check and the list of who can log in, because only you know what changed in the business. A developer owns the technical work, from updates and restores to monitoring. On a hosted builder, the platform takes most of the developer's share.
The developer can come from several places, and each has a trade-off.
| Who | Suits | Watch for |
|---|---|---|
| The agency that built it | Continuity, because they know the code | Upkeep sold as a condition of owning the site, or accounts in their name |
| A separate maintenance provider | WordPress sites, or when the original builder has gone | They need documentation and full access to do the job |
| Your host's managed plan | WordPress hosting with automatic updates | Covers the server and software, rarely your forms, scripts or restore tests |
| An in-house developer | Companies already running other software | One person, so ask who covers holidays |
| Your own staff alone | Hosted builder sites | Technical jobs stop without anyone noticing when nobody is named |
Say you run a 30-person surveying practice with a WordPress site. Your marketing lead keeps the service pages and team profiles current. Your office manager sends the monthly test enquiry and reviews logins each quarter. The agency applies updates within the agreed window, restores a backup to a test copy once a year, and sends a short report each month.
Whoever you choose, keep one page that lists the site's outside connections. It names where the domain is registered, where DNS is managed and where the site is hosted. It says which service sends the form emails and to whom, which scripts load from elsewhere, where the backups live, and who has admin access. Nobody can see this wiring by looking at the site, and it's what the next person needs first.
Get the arrangement in writing, and make sure it covers five points:
- Which jobs are covered, by name.
- How fast critical fixes go on.
- Where backups live, and when restores are tested.
- What's monitored, and who gets the alert.
- What happens to access and documentation when the arrangement ends.
Ask for upkeep as its own line, separate from the build, as our guide to what sets the price of a website explains. If you've inherited a site nobody documented, start with an audit and a written recommendation before you sign anyone up to maintain it.
How we handle maintenance after launch
Our practice starts from a line on our homepage: unmaintained software rots quietly. Upkeep is optional and agreed at handover. You own the site, its code and every account either way, so you can take the maintenance elsewhere without asking us.
When a client wants us to keep a site running, we monitor errors, slow queries, failed jobs and expiring certificates. A problem then reaches you from us rather than from a customer. A 24/7 assistant connected to the live system acts on what it can, and escalates to a person the moment it shouldn't be guessing. We also build for whoever comes next, with clean architecture, real documentation and current dependencies, so the next developer doesn't need a rewrite.
When you don't need a maintenance plan
You may not need a monthly plan at all. There are three cases.
- Your site runs on a hosted builder. The platform handles the technical layer, certificates included. Your jobs are the content, the domain and the monthly test enquiry.
- Your site is static and rarely changes. There's nothing to update each month. What's left is automatic renewals, library updates at the next change, and your own check. A developer on call can do more for you than a monthly retainer.
- You're about to replace the site. Keep it patched and backed up, and put nothing else into it. If you're not sure it needs replacing, read our guide to whether your website needs a redesign first.
You do need someone named if the site runs WordPress with plugins, takes payments, has customer logins or holds customer data. The same goes for a site that brings in most of your enquiries when nobody in-house can read an error log.
A plan whose monthly report says "all updates applied" on a site with nothing to update is a report, not maintenance.
A monthly website maintenance check you can run yourself
This takes about twenty minutes, and none of it needs a developer.
- Send a test enquiry through every form from your phone, and confirm it reached the person who answers enquiries, not a spam folder.
- Ask a colleague with a Gmail address to fill in the form, and check that any confirmation email reached their inbox, not spam.
- Open Google Search Console and read the Security issues report, then the Pages report for new errors.
- Click the padlock in your browser, note the certificate's expiry date, and ask how it renews.
- Check the domain's renewal date, and that the reminders go to an inbox your company controls.
- Ask for the date of the last backup and the last test restore.
- Every quarter, remove the logins of staff and suppliers who have left.
- Read your three most-visited pages for anything no longer true: people, opening hours, services you've dropped.
This week, send a test enquiry through your own website from your phone, and time how long it takes to reach the right person. If it doesn't arrive, you've found your first maintenance job.
Questions
Is hosting the same as website maintenance?
No. Hosting keeps the server running and the site online. Some hosts also update the server software, and managed WordPress plans often update WordPress and its plugins. Few hosts test your forms, watch the scripts your site loads, or restore a backup to check it works. Ask your host for a written list of what it does, and give the rest to someone by name.
What should a monthly maintenance report show?
It should list what was updated and when, and anything postponed with the reason. It should give the dates of the last backup and the last test restore, any downtime, and when the certificate and domain expire. A report that says only \"all good\" gives you nothing to check.
Does website maintenance include SEO?
The technical basics, yes: fixing the errors Search Console reports, broken links, redirects when a page address changes, and speed. Writing new pages and working on rankings is marketing, and usually a separate arrangement. Ask which one a plan means before you compare plans.
How we wrote this: drafted with AI, then checked and edited by the people who build our projects. Figures come from our own work or from the linked sources.