Website maintenance is the part most businesses discover only when something breaks: a form that stopped delivering enquiries, a security certificate that expired on a Sunday morning, or a site showing foreign ads after an update postponed for six months. A website is not a product you finish and forget. It is a living system that depends on a server, on code and on third-party services, all of which keep changing.
This guide explains what maintenance covers, which tasks belong to each month, quarter and year, what a backup you can trust looks like and what to write in the agreement. It describes how we at Logicode keep sites running, and it focuses on the factors that drive cost rather than on numbers that cannot be generalised.
What is website maintenance and what exactly does it include?
Website maintenance is the set of recurring actions that keeps a site healthy over time: software updates, backups, protection, monitoring and repair. It differs from development, where new capability is built, and from marketing, where traffic is generated. Its goal is narrow and clear: the site you invested in keeps working the way it was built.
These areas depend on each other. An update without a backup is a gamble, and a backup without monitoring is found too late. That is why website maintenance should be treated as one package, and you should confirm that each of the following is covered, even if some of it is automated rather than done by a person:
- Security and compatibility updates for the core system, plugins and server components, tested on a staging copy rather than directly on the live site.
- Automatic backups to storage separate from the server, together with periodic restore tests.
- Uptime and response monitoring, so a fault is found by us before a customer finds it.
- A firewall, hardening and malware scans.
- Testing of forms, checkout and email notifications, where money and enquiries vanish silently.
- Timely renewal of the domain, SSL certificate and hosting, plus tracking of performance and SEO health.
- Small content changes and support for day-to-day requests.
What happens to a site that is not maintained?
The damage accumulates quietly. The best-known risk is outdated software: vulnerabilities are disclosed in content management cores and plugins all the time, and attackers scan the web for sites that have not applied the fix. A small, unknown site is not protected by being small, because the scans are automated and do not pick targets by name.
Beyond security there are everyday failures: forms that break after a server or plugin update, an expired SSL certificate that shows visitors a red warning, and images and plugins that pile up until every page is heavy. We covered the security side in our website security guide for 2026 and the speed side in the article on edge performance.
The human factor is a risk too: administrator accounts of people who left, old passwords reused across several sites, and supplier access that stays open for years after the project ends. A periodic clean-up of users and two-step verification close a large share of these gaps at no development cost.
The key point is that repairing after an incident almost always costs more than preventing it. A hacked site needs cleaning, restoring, damage assessment and sometimes removal from browser and search-engine blocklists, and during all of that time it is not selling.
What gets done every month, quarter and year? A task checklist
The order of work in website maintenance follows the rate of change of each component. Security and availability need continuous attention, content and performance need a monthly look, and tasks like domain renewals or an accessibility review fit a fixed calendar.
A fixed element of every round is a staging environment: a copy of the site on which updates are run before they reach the live site. If something breaks, it is discovered on the copy, fixed, and only then released. Alongside it, a short change log is kept so it is always possible to tell what changed and when. The list below is a starting point you can adapt to your own site:
- Continuously: uptime monitoring, a firewall, automated security scans and a daily backup.
- Monthly: core and plugin updates on staging, a test of forms and checkout, a review of 404 errors and a speed check.
- Quarterly: a trial restore from backup, a review of users and permissions, removal of unused plugins and content, and a look at Search Console reports.
- Yearly: domain and hosting renewal, a check of PHP and server versions, a full security review, an accessibility check and an update of the privacy and accessibility statements.
What does a backup you can rely on look like?
A reliable backup answers three questions: where is it stored, how long is it kept, and has anyone proven that it can be restored. A backup stored on the same server that was hacked or crashed is not a backup, only a copy that falls together with the original. It must live in separate storage, ideally with a different provider.
A well-known principle here is the 3-2-1 rule: three copies, on two kinds of storage, one of them off-site. Alongside it you set a retention period, because malware planted two weeks ago will also be in yesterday’s backup. And finally, a trial restore once a quarter is the only proof that the files and the database were really saved intact.
Our hosting and security service includes a full daily backup to a separate cloud, so restoring is possible even when the server itself is unavailable.
Which security layers are needed: firewall, hardening and scans?
Good security is layered, because no single layer is enough. A web application firewall (WAF) sits in front of the site and filters malicious traffic, such as code-injection attempts and password guessing. Hardening reduces the attack surface inside the site: minimal permissions, disabling unneeded components, and strong passwords with two-step verification for administrators. Scans detect suspicious file changes.
Weblock, the protection system we developed, supplies the firewall and monitoring layer: a firewall that blocks malicious traffic before it reaches the server, and monitoring that checks the site’s availability every minute. Daily virus scans and routine updates are added in our hosting service. The background to building it is explained in the article about Weblock.
Remember that security does not replace updates. A firewall reduces the risk while a hole is still open, but the real fix is closing it with an update.
Do it yourself, hire a freelancer or use a company: what suits whom?
Doing it yourself suits a small, simple site, when someone is willing to learn the tools and carry out the tasks on time, including checking backups. The drawback is dependence on one person and difficulty noticing problems that are not visible to the eye. A freelancer adds expertise at a flexible price, but availability and cover during holidays and sickness are open questions that must be defined up front.
A company fits when the site is a business asset: a store, a lead-generation site or a system. The advantages are a documented process, several people who know the code and standing monitoring tools. Here too, ask whether the maintainer can also build: when a site is built in clean code, as described in our article on clean-code WordPress, there are fewer plugins to update and fewer points of failure. That is also the idea behind our approach to building websites in clean code.
For sites that rely on a stack of plugins, consider replacing several of them with one plugin written for the specific need. Custom WordPress plugin development reduces the number of external components that must be updated and tracked.
When you change maintenance provider or move hosting, the transition must be planned so rankings are not hurt, which is the subject of our guide to moving a website without losing rankings.
How can you check that maintenance is really being done?
A business site faces customers every day, so maintenance that cannot be demonstrated is a bet that stays quiet until the first failure. The check takes a few minutes and needs no deep technical knowledge, only a willingness to ask for data.
The common failure is maintenance that exists only on the invoice. To check, put five simple questions to whoever looks after the site, and ask for an answer with a date or a screenshot rather than a general assurance:
- When was the last backup made, where is it stored, and when was a restore last tested?
- Which versions of the core, plugins and PHP are running now, and what is scheduled for an update?
- Who holds administrator access to the site, and when was the user list last reviewed?
- Which intrusion attempts were blocked in the past month and which faults were handled?
- When do the domain, the SSL certificate and the hosting expire, and who receives the reminder?
What should a maintenance agreement say?
The cost of maintenance is driven mainly by a few factors: the type of site (brochure or a store with payments), the number of plugins and integrations, traffic volume, the response speed required for a fault, the number of languages and the volume of monthly content changes. A clean-code site with few dependencies needs less work than one built on dozens of plugins. You can estimate the overall range of a project, including monthly costs, in the website development cost calculator, and get an exact quote in a call via the contact page.
A good maintenance agreement describes what is done, how often and who is responsible. The more detailed the wording, the easier it is to compare offers and understand what you are paying for. These are the clauses worth requiring in writing:
- Scope: the list of tasks and their frequency, and what counts as an extra change priced separately.
- Handling times: decide what is acceptable to you for a severe fault and for a routine request, and ask for it to be written in the agreement.
- Reporting: a periodic report listing updates, backup results, security events and uptime.
- Ownership of access: the domain, hosting and admin panel are registered in your name, and credentials are handed to you when the relationship ends.
- Licences: who pays for plugin and external-service licences, and who is responsible for renewing them on time.
- Responsibility: what happens if an update that was applied breaks something, and how quickly the previous state is restored.
- Exit: terms for ending the relationship, including handover of backups and documentation.
More articles worth reading
- Website Security in 2026: Beyond an SSL Certificate
- Weblock: Active Firewall Protection for Websites
- Site Migration Without Losing Rankings