Ongoing support

Maintain and support the website

A website continues to require attention after launch. Updates, backups, monitoring and corrections protect the technical foundation, while editorial reviews keep services, contact details, prices, locations and legal information accurate. We define what is covered, how often checks take place, which response times apply and how additional improvements are estimated. Maintenance is proportionate to the website: a connected shop or portal usually requires more oversight than a stable presentation website. The client should retain control of essential accounts and understand where the domain, hosting, data and backups are held. This creates continuity and allows improvements to be planned before a collection of small problems turns into another urgent redesign.

The goal is to make the website clearer for visitors, easier to maintain and better organised for search engines, local discovery and AI-assisted answers.

Discuss this need

Photo illustrating the service Maintain and support the website

Your situation

Make ongoing responsibility visible before launch.

Maintenance and hosting support is relevant when a site must remain available, safe to update and understandable to its owner after publication. The precise tasks depend on the platform, provider and agreement. A good plan identifies who watches what, who can act and how a problem is reported.

Separate hosting from maintenance duties

Record who owns the domain, hosting contract, email service, certificates, backups, application updates and editorial access. Hosting availability alone does not ensure software updates or content accuracy. Document responsibilities without moving accounts or changing credentials simply to simplify the project.

Agree on backup and recovery expectations

State what is saved, how often, where copies are held, how long they remain and who may restore them. A backup is useful only if restoration has been tested in a safe context. The required recovery time depends on the business process and must be agreed rather than assumed.

Review the journeys that keep the site useful

Check key pages, forms, navigation, redirects and external integrations after updates. Keep a short change log with the action, result and next review. Revisit content ownership as well: an available site can still become misleading when services, prices or contact details are left outdated. Maintenance tracks renewal dates for the domain, hosting and licences actually used. Before a significant update, identify the backup, rollback procedure and functions to retest. Restoring files alone is insufficient: login, search and enquiry delivery also need checking where the website provides them.

What to prepare

Components, hosting provider, suppliers and critical account owners.
Deadlines, available backups and the outcome of the last known restoration trial.
Essential journeys, observed incidents and person authorised to decide on an interruption.
Contact path for incidents and approval

How to verify the result

An authorised substitute receives the alert, finds the affected scope and knows the next action.
Restoration recovers expected content and media in an appropriate test environment.
After work, the affected journey is repeated and remaining issues receive an owner.

Continue with the practical guide: Plan maintenance after launch.

Decision points

Match maintenance to site risks

Situation to examine

A brochure site, a store and an account-based tool have different outage consequences. Separate infrastructure availability, application updates, backups, editorial corrections and user support. The agreement should assign each responsibility.

Choice to make

List critical journeys and external dependencies. Set check frequency and an alert route that reflect their impact, then agree backup, recovery and supplier handover arrangements. Personal credentials should not circulate in a shared report.

Evidence of success

Test restoration safely and verify essential journeys after changes. The intervention log should say what happened, what remains to decide and when to check next; “site monitored” is not enough detail.

Prepare a response to a website incident →

Steps

A simple, readable and followed progression.

Listen

Understand your need, audience and current difficulties.

Clarify

Choose the pages, messages and priorities that are truly useful.

Build

Produce the required elements and validate progressively.

Support

Help you follow, correct and enrich the website over time.

Read the evidence

A successful backup notice still needs a restore check

Fictional teaching example · no client result or live site measurement

In this fictional check, a copy is restored in an isolated environment. The aim is to verify a useful function without changing the public site.

Identified copy
Isolated restoration
Functional checks

On a small screen, scroll the table horizontally to read all three columns.

Fictional observations to interpret
Stage	Fictional observation	Check status
Backup log	Task completed with no reported error	Copy reported; contents still to check
File restoration	Home page and images appear	Display partly verified
Business data access	Database connection fails	Functional recovery not verified

What can we conclude?

The log and a visible home page do not prove complete recovery. The database remains a blocker. Distinguish having a copy, restoring it and being able to complete important tasks.

What should be checked next?

Identify the database copy, compatibility with the files and required access. Repeat the isolated restoration and test the agreed functions, with external messaging and payments disabled in that environment.

What makes this check reusable?

Context to specify : IDs and dates for file and database copies, configuration and required versions.

Evidence to retain : Isolated restore log and replayed tasks, with external services disabled.

Decision to prepare : Validate functional recovery separately from recovery-time and data-loss objectives.

Explore the check further : Test website restoration before an incident

Scope and limits : This scenario is invented. It measures neither recovery time nor acceptable data loss; those objectives need separate definition.

Method reference : Cybermalveillance.gouv.fr · Sauvegardes. Source consulted 2026-10-22. This reference explains the method; the observations presented are invented.

Frequently asked questions

Detailed answers about scope, decisions and delivery.

No. Hosting provides infrastructure; maintenance can include application updates, backups, restoration checks, monitoring, correction of faults and content changes. The agreement should say which of these tasks are actually included and who handles the others.

Frequency depends on its technology, changes and business impact. Security updates and failures need prompt attention, while editorial reviews can follow a planned schedule and specific triggers. A documented routine is more reliable than an undefined promise of continuous monitoring.

Check its scope, then restore a copy in a separate environment. Verify expected files, data, media and functions with their dependencies. Measure actual recovery; a successful copy log does not prove restoration.

Affected service, impact, owner, attempted actions and next review. Distinguish monitoring, intervention and website evolution in the contract. Hosting scope alone does not define a recovery commitment.

Only when that journey is explicitly included. A page can respond successfully while messages fail to reach the recipient. Specify monitored functions, alerts, owners and authorised tests that verify operations without creating unnecessary real enquiries.

Let us be concrete

Where is the main blockage today?

Present the project

Practical checks to prepare

Prioritise website repairs using evidence
Separate failures, journey barriers and editorial improvements. Order repairs, assign an owner and verify the result with a practical work plan.
Verify that website emails actually arrive
Forms, confirmations and newsletters: check senders, authentication, bounces and delivery follow-up.
Change DNS without breaking your website or email
Prepare DNS changes: distinguish domain registration, hosting and email, retain useful records and plan recovery.

Related topics

Documented reference points for this topic

Documented reference points for this topic
Reference	Value or syntax	Scope
HTTP · 503	`503 · Retry-After`	Temporary unavailability; a delay may be indicated without guaranteeing recovery.
HTTP · 304	`If-None-Match → 304`	For a GET or HEAD request, an unchanged representation can be reused without resending its body.
MDN · Vary	`Vary: Accept-Language`	When one URL produces different responses according to Accept-Language, Vary identifies that cache selection criterion. Keep the value consistent on 200 and 304 responses. Separate language URLs do not require this header merely because the website is multilingual.
GitHub Docs · Repository backup	`git clone --mirror`	A mirror clone backs up the Git repository and its history. Git LFS objects require an additional fetch, and a wiki has its own repository. For a handover, also inventory data and services that do not reside in Git.

Sources consulted on 22 October 2026. These points are neither a website audit nor an overall conformance statement.