Website maintenance, on a written care plan.

• Choose a care plan when updates keep getting postponed.

  If platform, plugin and dependency updates wait because nobody can test them safely, a care plan puts testing and release on a routine instead of on good intentions.

• Keep maintenance in house when your developer already runs the routine.

  Where an in-house developer already tests and releases updates, a plan may only need periodic reviews and checks, or may not be needed at all.

• Choose a redesign when maintenance keeps working around the platform.

  When most changes fight an unsupported platform or a structure that no longer fits, website redesign and modernization is the better investment, and a care plan can follow it.

A website care plan can include platform and dependency updates, security patching, bug fixes, content and small feature changes, and routine checks of performance, search health and backups. Which of these a plan includes, and how much of each, is written into its scope, because a brochure site and an online store need different plans.

Plans are scoped to each site rather than published as fixed tiers. The site is assessed first, covering its platform, hosting, integrations, how often its content changes and what state its updates and backups are in, and the plan is written from that assessment. Two sites with the same number of pages can need very different work: a store with payment and shipping integrations carries more update risk than a site that changes twice a year.

The scope also says what is not included, so nothing is assumed. Redesigns, large new features and new integrations are scoped and agreed as separate projects, then maintained under the plan once they are live. Where hosting sits in an account the business owns, the provider is paid directly, and the plan covers the work on the site rather than the provider service. Native mobile apps are not covered, because native app development is not offered.

• Platform, plugin and dependency updates, tested before release.
• Security updates, and a review of certificates and security settings.
• Bug fixes, traced to a root cause and checked after release.
• Content updates to text, images, pages and metadata.
• Small feature enhancements within the agreed scope.
• Performance checks against Core Web Vitals and page weight.
• Search checks for indexing, sitemaps, metadata and broken links.
• Backup checks and restore tests, where the plan covers backups.

Bugs on a live website are fixed through a set sequence: the problem is reported and reproduced, its root cause is traced, a fix is made and tested on a copy of the site, and the fix is released with a way back and verified on the live site before the issue is closed.

Problems are prioritized by their effect on the business, not by the order they arrive. A checkout, form or login that fails comes before a layout fault on one page, which comes before a wording change. The plan states how urgent problems are reported, so a critical fault does not wait in the same queue as a content request.

Not every problem can be fixed at once. Some causes sit in a third-party service, a hosting provider or a platform update outside the site, and the fix then depends on that provider. In those cases the problem is contained where possible, the provider is contacted with the evidence, and the business is told what is known and what happens next.

1. The issue is reported through the agreed route, with what happened and where.
2. It is reproduced, so the fix can be confirmed later.
3. The root cause is traced in the code, the configuration, the content or a third-party service.
4. A fix is made on a copy of the site.
5. The fix is tested, along with the features around it.
6. The fix is released with a way back.
7. The result is checked on the live site, and the issue is closed and recorded.

A care plan improves a website through a repeating loop: measure how the site performs, learn what the data and feedback show, choose and make a small number of improvements, test them, and measure again. Each review decides the next improvements from evidence, so the site changes steadily instead of waiting for a rebuild.

The evidence comes from the disciplines covered elsewhere on this site. Analytics implementation records what visitors do, conversion rate optimization tests changes to what they are asked to do, technical SEO and Core Web Vitals work show where search and speed problems sit, and UI/UX design turns what people struggle with into better screens. A care plan applies those findings in small, tested steps rather than as a separate project each time.

No improvement is promised in advance. Some changes move a measure and some do not, and a change that does not help is reversed or replaced at the next review. What the plan commits to is the routine itself: measuring, choosing, testing and measuring again.

1. Measure: analytics, search data, performance checks and feedback from the people who use the site.
2. Learn: find where visitors struggle, which pages lose search visibility and what slows the site down.
3. Improve: agree a short list of changes with the business, then make them.
4. Test: check each change on a copy of the site, and compare versions where traffic allows it.
5. Measure again: confirm what changed before choosing the next improvements.

Website maintenance needs access to the systems the site runs on: usually the hosting or platform account, the code repository, the content management system and, for some changes, the DNS settings. Each person gets an individual account with only the permissions the work needs, in accounts the business owns, and access is removed when the work ends.

Shared passwords are replaced with individual logins wherever the service allows them, and two-factor authentication is turned on for maintenance logins that support it. Credentials, keys and backup files are never sent by email or chat and never stored in the code repository. Read-only access is used where it is enough, for analytics and search reporting for example.

Access is documented: which accounts exist, who holds them and why. When a plan ends, the business receives that record along with the code, the configuration and the change log, and the maintenance accounts are removed, so control of the site never depends on the people who maintained it.

A care plan review goes through what changed since the last review, what the routine checks found, which problems are still open and which improvements are recommended next. It ends with an agreed list of priorities, so the business decides where the next period of work goes rather than learning about it afterwards.

Findings are reported in plain language with the evidence behind them, such as a page that dropped out of the index, a dependency with a published security advisory or a form that failed a check. Each finding carries a recommendation and an honest view of how much it matters. The review does not produce a single score, because one number hides which problems matter.

How often reviews happen is set in the plan. A site that changes every week needs them more often than one that changes every few months.

• Updates applied, and anything that could not be updated safely.
• Problems reported and fixed, and any still open.
• Findings from performance, security and search checks.
• Backup checks and restore tests, where the plan covers them.
• Recommended improvements, with the evidence for each.

• Website maintenance
• Website care plans
• Technical maintenance
• Continuous improvement
• Scheduled review cycles

Every reported problem follows the same path, and it is not closed until the fix has been checked on the live site.

• Updates without guesswork

  Testing updates before release removes a common reason they get postponed: the worry that they will break the site.

• One route for every request

  Requests and problem reports arrive in one place, are prioritized in the open and are recorded when they are done.

• Problems found by checks

  Routine checks look for broken links, expiring certificates and pages dropping out of search, so a problem can be found by a check rather than by a visitor.

• A site that keeps improving

  Reviews turn what the checks and analytics show into a short list of improvements, instead of saving everything for a rebuild.

• A lead-generation business website

  Updates, form checks, content changes and a periodic review keep the site that brings in inquiries working and current.

• An online store

  Platform and extension updates are tested against checkout before release, and product and page changes follow the same route.

• A web application after launch

  Dependency updates, bug fixes and small enhancements run through the existing release process, and larger features are scoped separately.

• Every update and change is tested on a copy of the site before release, and each release is planned with a way back.
• Access is individual, uses accounts the business owns, and is removed when the work ends.
• Credentials, keys and backup files are never sent by email or chat, and never stored in the code repository.
• Requests are prioritized by their effect on the business: a broken checkout or form comes before a wording change.
• Findings from performance, security and search checks are reported with a recommendation, and larger work is scoped before it starts.
• Hosting providers run their own infrastructure, so hosting support covers configuration, diagnosis and working with the provider, not control of its servers.