# Keeping a website current after launch Maintenance includes factual content, working enquiries, dependency review and recoverable backups. Assign each responsibility rather than assuming that hosting covers everything. When a service or opening time changes, update its page and any matching structured data or downloadable version together. A maintenance agreement should specify activities and response expectations instead of promising unlimited changes. ## Divide maintenance into content and operations A business website can be technically available while giving outdated information. An old opening time, discontinued service or expired application deadline can be more disruptive than a minor design imperfection. Assign an owner to factual content: who checks prices, services, team details and contact routes, and what event should trigger an update? This can be a short responsibility list rather than a complicated publishing system. Operational maintenance asks different questions. Can the site still be built, is the form storing submissions, are required accounts accessible and are domains renewed? A person who edits text may not be responsible for any of those tasks. Name the responsible party for each area so “someone maintains the website” does not conceal gaps. Choose a review rhythm that fits the business. A fixed service page may change infrequently, while a course schedule needs checking whenever a cohort opens or closes. The relevant trigger matters more than an arbitrary promise to touch every page each week. Publish a truthful update date only when the content actually changes. ## Make small changes through a repeatable path For a text change, identify the exact page and supply the complete replacement paragraph. Include any other affected language versions. This is clearer than a message such as “update our offer everywhere,” which leaves the implementer to guess the final wording. For a price change, update the central pricing source and inspect all places that display it, including package cards and machine-readable content. Use a preview before publication for changes that affect layout or behaviour. A longer service name may wrap in the navigation; a replacement image may crop badly on mobile; a translated button may no longer fit. Review the relevant page at an ordinary phone width and check links connected to the change. You do not need a full redesign review for every comma, but visible changes deserve a quick contextual check. Keep a clear record of what was published. If the new version introduces a problem, the previous working version should be identifiable. A backup is helpful only if somebody knows what it contains and how to restore it. Public code backups and private enquiry backups also require different access and retention decisions. ## Check the enquiry journey and recurring obligations Periodically submit an authorised test with a recognisable test description and confirm the result in the actual storage or admin view. Do not confuse a confirmation screen with evidence that the record was saved. Remove the test according to the agreed process so it is not mistaken for a real sales lead. Also check a basic failure case, such as a missing required field, to ensure the customer can recover. Maintain a list of renewals and service dependencies. Domain names, business email and optional paid tools do not become free because the website uses a free hosting plan. Track which account receives renewal notices and who can act on them. Avoid a single individual's unavailable inbox becoming the only way to keep the business address active. Finally, distinguish maintenance from expansion. New languages, a customer portal or online payments can change the architecture and responsibilities. Review those requests as projects with their own scope. A stable small website remains manageable when routine updates are simple and larger changes are recognised before they quietly reshape the service. **Create a short change record.** A useful entry contains the date, affected pages, approved wording or asset, person responsible and published version. For multilingual changes, list the equivalents checked. This takes little effort and prevents later uncertainty about whether an old phrase is intentional or was simply missed. Give urgent factual corrections a clear route. A wrong public phone number or an obsolete course deadline should not wait for a large design meeting. Conversely, a request to add a booking workflow deserves scope discussion even if it begins as a short message. Classifying the change by its effect keeps maintenance both responsive and controlled. Review the arrangement when responsibilities change. A departing employee may own an image archive, a renewal inbox or an external account needed by the site. Updating access and documentation is part of keeping the service dependable. The website does not operate independently of the people and accounts that support it, even when its public pages are static and inexpensive to host. ## Practical checklist - Name the content owner - Schedule form checks - Record approved changes **A concrete example:** When a service or opening time changes, update its page and any matching structured data or downloadable version together. **A boundary to keep clear:** A maintenance agreement should specify activities and response expectations instead of promising unlimited changes. ## Your next step [Tell Orvunweb about your project](/en/start-a-project/) ## Related reading - [Signs that an old website needs an update](/en/blog/signs-that-an-old-website-needs-an-update/) - [Protecting contact forms against spam](/en/blog/protecting-contact-forms-against-spam/) - [Files and accounts to collect at website handover](/en/blog/files-and-accounts-to-collect-at-website-handover/) - [Business website service](/en/services/business-website/) - [Compare packages](/en/pricing/) ## Related services - [Business website](/en/services/business-website/) --- Locale: en Canonical: https://orvunweb.com/en/blog/keeping-a-website-current-after-launch/ Updated: 2026-09-16