Website Maintenance: Who Checks What After Launch?

After a website launches, agree who confirms business information, handles the technical work, keeps supporting services renewed and checks that customers can still complete the important tasks. Give each responsibility a trigger and a record of what was checked. That makes “looking after the website” specific enough for the owner and maintainer to act on.

A useful maintenance record can be short. It needs to show who receives a change or problem, who can resolve it and what evidence is still missing. Start with the arrangement established at your website handover, then keep the record current as staff, services and the website change.

Start with the arrangement you actually have

Ask the person responsible for the website to separate work handled by the platform from work assigned to your team or a technical maintainer. Hosting, page editing, connected tools and support may have different owners. One person can cover several roles, but each part still needs an agreed scope.

The software work depends on the setup. Webflow describes managed hosting with automatic security updates. The WordPress update guide recommends making a backup before updating. Those are examples of different platform arrangements, not a maintenance checklist that applies unchanged to every website. Confirm who handles the components your site actually uses, including any custom code or separate services.

Even where a provider manages the hosting infrastructure, your business still needs someone to approve a new service description or notice that an enquiry is reaching the wrong team. Ask what the support agreement covers, who receives relevant provider notices and how a problem gets to the person who can investigate it.

Give each kind of work a trigger and an owner

The following matrix is for a fictional local service business. It illustrates a possible division of responsibility, not a ZXP care plan or a completed audit. Replace the role names with the people and providers who have agreed to do the work for your site.

Keep service and responsibility information in the record, not passwords, recovery codes or payment details. For renewals, use the actual account or agreement to confirm the arrangement. A reminder assigned to someone who no longer receives the provider’s notices leaves a gap even if the calendar entry still exists.

Agree a recurring review rhythm around how often the site changes, which customer tasks matter and what the provider handles. Add checks when relevant changes occur. A service change or urgent provider notice needs assessment when it arrives; it should not sit untouched simply because the next routine review is later. There is no single monthly-hours allowance that this matrix can establish for every business.

Keep a check open until the evidence is there

Imagine the fictional business changes its opening hours. The owner approves the new hours, and the editor updates the contact page. During the check, the owner finds that the footer still shows the old hours. This is an invented example, not an observed customer website.

The edit request has moved forward, but the conflicting information remains unresolved. The record should name the affected page and footer, show the approved hours and assign the correction. Once the editor fixes it, someone reopens the affected public pages and records what they actually see. If the old hours are already wrong, arrange an accurate correction through the authorised process rather than waiting for the next routine review.

Use the same discipline for other work. Record “change made, receiving check pending” if a form destination has been changed but nobody has confirmed a test request. When a check fails, keep the observation and next action beside its owner. A completion date without the result gives the next person little to work with.

Ask what a backup can actually restore

A saved backup shows that a copy was created. A recovery test provides evidence about whether the chosen copy can restore the material and functions being tested. Ask what is included, what is outside that backup and who is responsible for recovery. A website copy may not include records held by a separate booking or enquiry service; have the maintainer confirm the actual boundary.

The Canadian Centre for Cyber Security recommends clear restoration procedures and regular verification that recovery mechanisms work. Ask for the latest relevant test record: the backup used, the environment, what was restored, the observed result and anything left untested. A successful limited test should not be presented as proof that every service can be recovered.

Plan that work with the responsible maintainer. The Cyber Centre’s IT recovery guidance recommends a test environment to avoid business interruptions. Do not restore over the live website as a casual maintenance check. The test environment also needs appropriate protection for any data it contains.

Recovery can affect more than page text. Webflow’s backup documentation identifies effects on scheduled CMS items and form-protection settings, among other data and settings. The maintainer should account for the platform’s current behaviour and verify the affected functions. An owner-level review should establish the plan and evidence, not improvise restore steps.

Check the customer path after relevant changes

Choose the task that matters to your business, such as sending a service enquiry. After a relevant change, follow the agreed route from its starting page through to the outcome. W3C’s form-notification guidance calls for understandable success and error feedback. Check that wording, then have the receiving team confirm the labelled test in its expected destination. Record these as separate observations.

Agree the test scope first. Use fictional details and a controlled destination, and confirm that connected tools cannot create unwanted live messages, bookings or charges. A preview address alone does not establish that separation. If a safe route is unavailable, record the check as untested and ask the maintainer how to demonstrate it. Live tests or other actions affecting real services need separate agreement.

Keep customer information out of shared evidence. Record the page, conditions, actual result and follow-up owner. One successful check supports that route under those conditions; it does not guarantee every device, future enquiry or connected service.

Agree what support includes

Finish the responsibility record with the support contact, agreed scope and escalation route. Clarify who assesses an urgent issue, who authorises paid work and what happens when the usual contact is unavailable. A new booking integration or a redesigned service flow may need a separate project discussion rather than being assumed to fit routine care.

If you are planning a new site or redesign with ZXP, bring this record and one unresolved example to the scope discussion. Explain what your team can manage and where you need help. Confirm the ongoing responsibilities as part of that discussion instead of assuming that a website package includes every maintenance task.