Website Maintenance in Kenya: 12 Terms Your Support Plan Needs

A website maintenance plan should tell you what happens after launch, before something breaks. It should name the assets being supported, the checks performed, the response path when a problem appears, and the evidence you will receive that routine work actually happened.

That clarity matters whether the website is a small company site, an ecommerce storefront, a membership platform or the public entry point to a larger application. Hosting alone does not maintain the software, content, integrations and search visibility that sit on top of the server.

Maintenance is an operating agreement, not a vague promise

A useful plan separates routine prevention, planned improvements and incident response. Routine prevention covers checks such as software updates, backups, monitoring and link reviews. Planned improvements cover agreed content or feature work. Incident response defines what the support team does when the site is unavailable, compromised or failing an important customer journey.

Without that separation, every request becomes a debate about whether the work is included. The following terms give a Kenyan business a practical way to compare proposals on scope rather than on a single monthly figure.

The 12 terms to put in the plan

1. Supported asset inventory. Name the production domain, hosting account, content management system, code repository, database, forms, payment or messaging connections, analytics, DNS and email dependencies that are in scope. Record the owner of each account. A supplier cannot protect an asset it cannot identify or access.
2. Monitoring and alert ownership. Define which pages and journeys are checked, how often checks run, who receives alerts and what counts as a confirmed incident. A homepage-only uptime check can miss a broken contact form, checkout, login or quote request.
3. Backup and restore procedure. State what is backed up, where copies are stored, how long they are retained and how restoration is tested. A backup is only useful when the team can restore the code, database and uploaded files to a known point without exposing the copies through the public web root.
4. Software and dependency updates. List the platform, plugins, libraries, server runtime and third-party components that will be reviewed. Define how updates are tested, approved and rolled back. Updating blindly in production is not maintenance; neither is leaving known vulnerable components untouched.
5. Security checks and incident escalation. Cover access reviews, least-privilege accounts, authentication controls, certificates, logs, exposed files, suspicious changes and the process for containing and reporting an incident. The plan should identify the business decision-maker who can authorize urgent action.
6. Content and routine change allowance. Specify whether the plan includes text edits, new staff profiles, offer updates, landing pages, product changes or image optimization. Give the allowance a measurable unit such as requests, hours or a clearly bounded backlog.
7. Performance checks. Name the pages, devices and connection conditions used for review. Track image weight, caching, page response, layout stability and user-facing speed over time. A single fast homepage does not prove that article, product and form pages are healthy.
8. Accessibility and responsive regression checks. Include keyboard access, focus visibility, form labels, contrast, text resizing, alternative text and mobile touch targets when templates or content change. Accessibility is not a one-off certificate; regressions can enter with ordinary edits.
9. Search and crawl health. Define checks for indexable pages, canonical URLs, redirects, sitemap output, robots rules, metadata, structured data and broken internal links. Search platforms provide monitoring data, but someone still needs to review the signals and decide what to fix.
10. Change control and release method. State where changes are tested, who approves deployment, what files or data are backed up first, how releases are recorded and how a failed change is reversed. Direct untracked edits on the live server make later recovery and ownership harder.
11. Response targets and maintenance windows. Define severity levels, acknowledgement targets, support hours, planned maintenance windows and communication channels. A response target is not the same as a resolution guarantee: difficult failures may depend on hosting providers, payment services or another vendor.
12. Reporting, ownership and exit. Require a concise record of checks, updates, incidents, unresolved risks and recommended work. Confirm ownership of the domain, hosting, code, content, analytics and credentials, plus the handover format if the support relationship ends.

Hosting, maintenance and development are different scopes

Hosting supplies infrastructure such as server resources, storage and network access. Maintenance keeps the existing website dependable. Development changes what the website can do. One provider may supply all three, but the proposal should still separate them so you can see dependencies, responsibilities and approval points.

If the current site no longer fits the business workflow, routine support may not be enough. Compare the role of a public website and an operational application in the website versus web app guide, or review website and mobile application development when the requirement is a new customer journey rather than maintenance of the current one.

What a useful first month should produce

The first support cycle should create a baseline, not just a list of promises. Ask for:

• a confirmed asset and access register with unnecessary accounts removed or flagged;
• a successful backup plus evidence that the restore path was tested appropriately;
• a list of software components, pending updates and material compatibility risks;
• a review of the most important mobile and desktop customer journeys;
• a crawl, metadata, sitemap, robots and broken-link check for public pages;
• a prioritized backlog separating urgent risks, routine work and optional improvements.

This baseline gives both sides a shared picture of the website. It also prevents an old defect from being mistaken for a failure introduced by the new support provider.

Red flags in a maintenance proposal

• "Unlimited changes" without a defined request size, queue or fair-use rule.
• "Daily backups" without retention, storage location or restore testing.
• "Security included" without access, update, monitoring and incident responsibilities.
• A guaranteed search ranking or a promise that routine maintenance will automatically increase traffic.
• No staging, approval, change record or rollback process for production work.
• The supplier controls the domain or hosting account and offers no documented exit path.
• Every third-party outage is treated as the maintainer's fault, or every integration problem is excluded without investigation.

Questions to ask before signing

1. Which exact pages, forms, integrations and environments are covered?
2. What evidence will we receive each month?
3. How are urgent incidents classified and communicated?
4. Which work needs a separate estimate?
5. Who owns and can export every account, file and dataset?
6. How will you hand over the website if either party ends the arrangement?

A good answer should be specific enough to test but flexible enough to accommodate the website's actual stack and business importance. A brochure site and a transactional platform should not inherit the same checklist, response path or change budget.

Frequently asked questions