Website maintenance: keep your customer journey working

Start with the routes that produce business

Choose a small set of representative journeys: a visitor requests a quote, checks a service, opens a product demonstration or downloads the current release. Write down the starting URL, expected destination and confirmation. Include both languages and a phone-sized screen. A successful home-page check is useful, but it cannot confirm that a deeper contact or purchase route still works.

For a form, use a clearly identified test inquiry and verify its receipt with the destination owner. Check required fields, understandable errors and the confirmation shown to the visitor. For a payment flow, use the supported test environment and verify the public destination separately. Record the date and result so the next review can distinguish a recurring problem from a new one.

Set a review rhythm that matches change

An example starting schedule is to check important journeys after every release, review offers and downloads monthly, and rehearse recovery periodically. Adjust that schedule to the site: a frequently updated store needs different coverage from a small portfolio. Assign a person to renew domains and review provider notices. A task without an owner is easy to miss even when a reminder exists.

Keep a list of account owners, renewal dates and dependencies without putting passwords in the public repository. Distinguish content edits from software updates. A new phone number should be checked across contact pages and structured data; a dependency update needs a build and a test of the affected behavior. Batch routine work where appropriate, while treating a broken customer action as a separate repair.

Make each update recoverable

Before changing the site, identify the current release and what recovery actually covers. Source code, uploaded media, operational data and provider settings may live in different places. A saved code revision does not necessarily restore a database or an external form service. Test the relevant recovery procedure in an appropriate environment and record who can carry it out.

Preview the change, run the checks relevant to it, publish and verify the public result. Keep the original URL when the purpose of a page stays the same. If an address must move, map it to a relevant replacement. On the MAS website, automated checks review canonical addresses and language relationships before publication; a public check then confirms what visitors actually receive.

Turn maintenance into a clear scope of work

A useful maintenance agreement identifies included journeys, content responsibilities, update coverage, response expectations and exclusions. Separate provider charges from the work itself, and agree how larger changes are estimated. Ask for a short record of checks and repairs rather than a report that only says the site is online. Search traffic can vary even when every technical check passes, so compare it separately over a consistent period.

To discuss maintenance with MAS, bring your site address, its main customer action, the systems it connects to and a short list of known problems. We can use that information to define a review and an implementation scope. If the site is unfinished or the original handover is missing, start with project assessment so the maintenance plan reflects the system you actually have.

Before your next step

• Named owners for contact delivery, content and provider accounts.
• A dated record of important customer journeys in both languages.
• A recovery procedure with a tested scope.
• A clear distinction between routine maintenance and new development.