Web Maintenance Guide for Businesses

Maintenance is not "fixing the site when it breaks". It is a set of periodic tasks that stop it breaking: updating dependencies, applying security patches, verifying that backups can be restored, monitoring availability and checking that the certificate and domain records are still in order.

To that an allowance of hours for minor content changes is usually added. It is worth keeping those two separate in the contract: if technical maintenance and commercial changes come out of the same allowance, business urgency eats the security time.

• Dependency and runtime updates
• Security patches with a committed deadline
• Backup verification with a tested restore
• Uptime monitoring with automatic alerting
• An hours allowance for minor changes, kept separate

Most compromised sites are not hit by a targeted attack but by a bot crawling the internet for a version with a known, published vulnerability. Timing matters: between disclosure and mass exploitation attempts there are usually days, not months.

So the operational criterion is separating what gets applied immediately from what can wait for the monthly window. Critical vulnerabilities go outside the calendar; the rest is batched, tested in a staging environment and deployed with a rollback plan.

• Critical outside the calendar; the rest in a monthly window
• Test in staging before touching production
• A written rollback plan before every deployment
• Watch the certificate and its automatic renewal
• Review who has access and revoke it when someone leaves

Almost everyone has backups and almost nobody has ever restored one. An untested backup is an assumption, and the day it is needed you discover the database was missing, the file is corrupt, or nobody knows the procedure. Restoring once a year, into a separate environment, turns that assumption into a fact.

The other part is where they live. A backup on the same server protects against nothing that matters: not a ransomware wipe, not losing the provider. At least one copy must be elsewhere and out of reach of the server credentials.

• A frequency matching how much data you can afford to lose
• At least one copy off the server and off the provider
• A genuinely tested restore, at least once a year
• The backup includes database and uploads, not only code
• Retention long enough to catch a problem that took time to surface

Finding out the site is down because a customer calls you is the worst way to find out. Minimal monitoring checks every few minutes that the homepage responds, that the certificate has not expired and that the contact form still sends, and alerts through a channel somebody watches.

Response time has to be agreed by severity, not as a single number. A shop down mid-campaign is not the same as a typo on a secondary page, and a contract that does not distinguish between them ends up treating both the same way: badly.

• Periodic checks of availability and the certificate
• Also monitor that the contact form still sends
• Alerts through a channel somebody genuinely watches
• Different response times by severity
• A defined on-call contact for critical incidents

A useful maintenance contract describes concrete tasks and deadlines, not adjectives. It should state what gets updated and how often, how fast you get a response by severity, what report is delivered and how many change hours are included. Without that, the only way to know the work is being done is for something to fail.

The most forgotten and most painful clause is the exit one: that code, domain, hosting and all credentials are in the company's name, and that a handover procedure exists. Maintenance you cannot leave is not a service, it is a dependency.

• Concrete tasks with their frequency, not adjectives
• Response times by severity level
• A periodic report of what was done
• Included change hours and the rate for extra ones
• An exit clause: code, domain and access in your name

In the Spanish market, maintaining a corporate website runs between EUR 50 and 150 a month; an online store, between 150 and 400; and a web application with users and sensitive data, from 300 upwards depending on cover. What moves the price is not the size of the site but the service level: hours covered, response time and whether there is on-call.

Comparing the fee alone is misleading. Cheap maintenance that never verifies backups and never patches outside the calendar is not cheaper: it is insurance that does not cover the event it was bought for.

• Corporate site: EUR 50-150 a month
• Online store: EUR 150-400 a month
• Application with users and sensitive data: from EUR 300
• Price is driven by cover, not by the size of the site
• Compare what each offer includes before comparing the fee