A website maintenance plan that proves what still works

Turn a finished handover into a running plan

At launch, you need to know who owns the domain, hosting, content, forms and accounts. A month later, the more useful question is whether those pieces still work and who will act when they do not. The website handover checklist records access and recovery paths; this plan turns that information into repeatable checks with evidence and a response owner.

Start with the website’s real jobs: a visitor can understand an offer, find the right page, send an inquiry, use the site with a keyboard, and receive an honest result. Name each job before listing plugins or dashboards. A technical check that cannot be tied to a visitor or operating risk may not deserve a recurring slot.

Copy this maintenance control register

Create one row per control in a shared business document or issue tracker. The row should be specific enough that a deputy can run the check without guessing, and it should point to evidence without putting passwords or customer details into the register. These are the fields to copy:

• Visitor or business task: the outcome the control protects, such as “an inquiry reaches the team”.
• Asset and dependency: the page, form, account, provider or integration; link to its owner record, not to a secret.
• Failure to detect: describe the observable failure, including silent failures such as a saved form with no owner alert.
• Check and expected result: write the exact journey or measurement and the condition that counts as a pass.
• Owner and deputy: name who runs the check and who can respond when that person is unavailable.
• Cadence and trigger: record the next routine date and events that require an immediate extra check, such as a release or provider change.
• Evidence: record the check date, result and a private link to the relevant screenshot, log, ticket or restore record; avoid customer data in the public document.
• Severity and response target: agree who is contacted and how quickly for a failed lead path, security issue or expired service.
• Repair and retest: assign the fix, record the retest result and date, then close the row only when the protected journey works again.

Set a cadence that follows risk and change

There is no universal weekly checklist for every website. A brochure site with occasional edits and a site that books appointments every hour have different failure costs. Choose a starting frequency based on traffic, change rate, the consequence of a missed inquiry, and how quickly your team can respond. Put the next check on a calendar; “monitor regularly” is not a schedule.

As an adjustable example, a small lead-generation site might check the inquiry path and health alerts each week, review content and broken destinations each month, compare performance and accessibility samples after releases, and rehearse a backup restore on a longer cycle. A new form, content template, analytics tag, plugin or hosting change triggers an extra check immediately. These intervals are planning examples, not a standard or a claim that every business needs the same frequency.

Check the facts visitors and search engines actually see

Review the pages that answer buying questions: offer details, eligibility, service areas, opening hours, contact routes, current examples and linked downloads. Compare them with the business’s authoritative records. If an offer ends or a service changes, correct the page, its linked pages and any structured data describing the same fact. Google’s people-first guidance asks whether content is accurate and useful; it explicitly cautions against changing dates merely to make old content appear fresh.

Use Search Console and your site’s own checks to notice missing pages, crawl errors or a broken internal route, then inspect the affected URL before deciding what to change. Discovery and indexing are separate from business accuracy. The service content map helps decide which pages deserve separate answers; the structured-data planning guide covers fact-to-markup consistency in depth.

Test the critical journey, including its failure states

Open the site as a visitor and follow the path that matters most. For an inquiry form, check its labels, required-field guidance, keyboard order, errors and success message. W3C’s forms guidance covers accessible form design, while its Easy Checks are a quick preliminary screen rather than a full accessibility evaluation. When a form is changed, also check what the business depends on after submission: durable storage, a notification, the reply path and a way to recover a failed handoff.

Use a staging system or a deliberately labelled, approved test entry where a live end-to-end test is necessary. Do not send routine anonymous test leads or marketing messages just to make a dashboard look active. A form that shows “sent” while the record was rejected is a failure; a stored inquiry whose alert is delayed needs an operating response. The lead-form checklist owns field design; this maintenance row owns detecting and closing a regression after launch.

Sample accessibility and performance after change

A new navigation pattern, article template, third-party widget or content edit can change what a visitor experiences. After such a change, repeat a few representative keyboard and small-screen journeys, inspect text and form states, and log any barrier with an owner. W3C recommends treating accessibility as an ongoing organizational activity. A quick automated scan or preliminary check can find some problems but does not establish WCAG 2.2 AA conformance; use the accessibility acceptance plan for a deeper release decision.

Compare the pages and journeys named in your performance budget with the same kind of field and lab evidence over time. Field data reflects real visitors, while lab tests help reproduce a particular change; neither single reading proves the whole site is fast. Record the page, device, date, method and what changed before raising or closing a performance issue. The performance-budget guide owns threshold selection; this row owns repeated measurement and follow-up.

Watch dependencies, recovery and renewals

Keep an inventory of the website’s software and external services. Check relevant advisories, assess whether a change affects the site, test the update, and record who approved release or deferral. OWASP’s vulnerable-dependency guidance describes how to assess and respond when a vulnerable dependency is found. A scanner result alone is not proof that a site is safe, and a fixed patch interval cannot replace risk assessment.

Confirm that backups complete, can be found by the people who need them, and have been restored into a safe test location. NIST’s contingency-planning guidance connects backup planning with recovery and testing; a green scheduled-job indicator proves less than a successful restore. Protect the backup as carefully as the live data. If it contains inquiries, do not place it in a public repository or analytics system.

Put the domain registrar, DNS, hosting, certificate and critical vendor subscriptions in the same register, with their account owners and renewal dates. ICANN describes registrar expiry notices, but an inbox reminder is not a substitute for someone who can access the account and verify payment and renewal. For HTTPS, confirm the actual issuer and renewal automation rather than assuming one certificate lifetime applies forever. Test the public site after a renewal or DNS change.

Hypothetical example: one month of a maintenance register

Imagine a small equipment-repair business. This is a hypothetical planning example, not a Kinetivy client or a measured result. Its website has a repair inquiry form, a guide to preparing equipment for collection, and a seasonal service offer. The owner and a named deputy keep a private register.

The “offer accuracy” row says: compare the offer page with the approved sales sheet on the first working day of each month and whenever the sales sheet changes. The expected result is that scope, dates and inquiry link agree. During one hypothetical check, the owner finds that the offer ended but the page still says it is available. They create a ticket, remove the expired claim, check the linked guide and structured data, then save a dated page capture and close the row only after the live page matches the approved offer.

A separate “inquiry path” row uses a labelled staging submission after each form release. It checks accessible field errors, the stored record, the owner notification and the confirmation state. The backup row records a completed snapshot and a private sample-restore result; the domain row records the registrar owner, expiry date and last successful renewal check. None of those rows is marked complete because a different dashboard happens to be green.

Close failures with a retest, not a note

Give a failed check a severity, repair owner and response target. If an inquiry route is down, identify how a visitor can still reach the business while it is repaired. If a content claim is wrong, correct the source record and all affected pages. If a third-party service fails, use the agreed manual fallback. Capture only the evidence needed to explain the decision and protect personal data.

After a fix, repeat the original visitor journey and record the new result. Review the register periodically: retire checks for services the site no longer uses, add checks when a new dependency appears, and adjust cadence when failures or change frequency justify it. The useful output is a maintained website with accountable owners, not a longer checklist.