On this page
- What website maintenance includes
- Why checking that the site responds is not enough
- Three real failures you only see by monitoring
- The expired certificate that was not a certificate problem
- Certificates for domains that had already left
- The security header that sent conversions to zero
- How we check that a backup works
- What happens if a website is not maintained
- How to tell whether your current maintenance covers what it should
- How we work at Kiwop
Website maintenance is the ongoing work that keeps a site secure, up to date and working: updating the content management system and its extensions, renewing certificates, making backups that can actually be restored, checking that forms deliver and reviewing performance. The part almost nobody talks about is monitoring: most of the failures we see do not take a website down, they leave it looking fine while something important has stopped working.
Want us to do it for you? See our WordPress Development service
Updated September 2026. The cases come from websites we maintain, kiwop.com included; client cases are anonymised.
What website maintenance includes
Every website is different. These are the blocks we work with in monthly maintenance:
- Updates. Of the CMS, the theme, plugins or modules and server dependencies. They are tested first on a staging copy and only then go to production.
- Security. We review vulnerability advisories that affect what each site has installed, and we remove extensions nobody uses any more.
- Certificates. We monitor the certificate the visitor actually receives, not the one stored on disk. Today we track almost 500 certificates across our whole server fleet.
- Backups. Automatic, off the server and with restore tests. If a backup has never been restored, we do not know whether it works.
- Monitors that test what matters. On kiwop.com, a monitor submits the contact form every 15 minutes and alerts us if it does not arrive. That tells you far more than a "the site is up" alert.
- Performance. We review Core Web Vitals and response times, because an update can also make a fast site slow.
- Small changes. Copy, images or a new page, within the agreed hours.
Why checking that the site responds is not enough
The most common monitor checks that the site returns a 200 code, which in HTTP means "everything is fine". The problem is that many failures return 200.
On our own website, the blog listing failed on one or two out of every hundred requests. The server was requesting the articles from its own public address, and that detour through the network failed now and then. The page was served with a 200 and the message "Articles could not be loaded". An uptime monitor considered it fine, and a search engine crawling at that moment saw an empty blog. We fixed it by making the server talk to the content management system over the internal network.
Our chat assistant has a similar trap: when the AI provider fails, the server still answers with a 200 and a fallback message. So the monitor does not settle for the 200: it reads the response and alerts us if it contains an error.
Three real failures you only see by monitoring
The expired certificate that was not a certificate problem
From some Spanish internet providers, kiwop.com showed an invalid certificate warning, and only during football match hours. The certificate was fine. Our website shares an IP address on Cloudflare with other websites, and that IP fell under the blocking order LaLiga obtained from a Barcelona court against piracy in December 2024. The provider cut the connection and answered with its own certificate, and the browser showed it as if ours had expired.
The lesson is that the symptom misleads. Anyone who had "renewed the certificate" would have fixed nothing. Before touching anything, you have to check from outside the provider what the visitor receives and why.
Certificates for domains that had already left
On a server hosting the websites of several public bodies, the automatic renewal system kept trying to renew certificates for 55 domains that had already moved to another infrastructure. Every attempt failed, because those domains no longer pointed to our server. Let's Encrypt limits failed validations, so those failed attempts ended up blocking the renewal of the certificates that were still being served from there.
Our certificate monitoring caught it when one of the active domains had three days left. The lesson applies to any maintenance contract: when a website leaves, everything it had on the server has to be removed, certificates included.
The security header that sent conversions to zero
We hardened the security headers of kiwop.com with a policy that limits which domains the page can connect to. The Google Ads script loaded, but its conversion pings could not reach Google's servers. There was no visible error, only a warning in the browser console. For weeks, the ads account recorded zero conversions.
Since then, every time a third-party tool is added or a header is changed, we check that the data reaches its destination, in this case the Google Ads account. A page that loads proves nothing.
How we check that a backup works
Before each deployment of our internal platform we back up the database and check that the file is neither empty nor corrupted. That proves the backup exists. To know whether it can be restored you have to test it: the backup is restored into a separate database, the content is checked, and live data is never overwritten. When a client asks us to recover something that was deleted, we always work on that separate copy.
What happens if a website is not maintained
A website without maintenance usually keeps working for a while, as it degrades and becomes a little more exposed every week:
- The most widely used free certificates expire after 90 days. If automatic renewal breaks and nobody watches it, one day the browser tells your visitors your site is not secure.
- Plugins and modules pile up known, public vulnerabilities. Automated attacks look for exactly those versions.
- CMS and PHP versions stop receiving patches. The longer you wait, the more the upgrade costs, because you have to jump several versions at once.
- Forms stop delivering without anyone noticing, and a customer who writes to you never gets an answer.
How to tell whether your current maintenance covers what it should
If you already pay for maintenance, these questions tell you in five minutes whether it covers more than an automatic backup:
- When did you last restore a backup, and where?
- What happens if an update breaks something? Is it tested on a copy of the site first?
- Who gets the alert if the contact form stops sending?
- How do you find out about a vulnerability in a plugin I have installed?
- Do you monitor the certificate the visitor sees, or only its expiry date?
If the answers are vague, the maintenance is probably a backup and little else.
How we work at Kiwop
We maintain websites and online stores we built ourselves, and also websites we inherit from other providers. For the latter we start with a technical audit: which versions they run, which extensions are unnecessary, where the backups are and what monitoring exists. From there we agree the tasks and hours for each month. Technical maintenance costs between €150 and €600 a month, excluding VAT, depending on the size of the site and the hours included. For reference, providers in Spain that publish their maintenance fee ask a median of €39 a month, according to our observatory of published prices, and that usually covers updates and automatic backups.
If you want to know how your website is doing or review your current maintenance, tell us what you have. If you are planning a new website, our web design page explains how we work from the start.