A website can look unchanged for months while its contact form stops delivering, a renewal reminder goes to an old employee, or a booking link points to a discontinued service. Maintenance means checking the parts customers depend on, as well as keeping the underlying software in good order.
If you run a business in Cheltenham and need someone to look after an existing site, the useful starting point is an inventory. What is running, who controls it, and what would interrupt the business if it failed? Those answers help distinguish a small repair from an ongoing support arrangement.
First, establish who owns the essentials
Before giving a new developer access, collect the names of your domain registrar, hosting provider, website platform, form service and any connected booking or payment tools. Record the account owner and renewal date for each. Keep passwords in an appropriate password manager; do not put them in an ordinary project brief.
The business should know how to recover its accounts if a supplier or employee becomes unavailable. A working website is difficult to maintain when nobody knows where it lives.
Ask for named user access where the platform supports it, rather than sharing one master login. When the work ends, decide which access should remain for support and which can be removed.
Agree what maintenance actually includes
The word can cover very different jobs. A hosting invoice may pay for server space without including content edits, software updates or recovery work. A developer's support agreement may include a fixed amount of work, a response window, or individually quoted changes.
Make the scope explicit:
- Which software and third-party connections will be checked?
- Who notices and responds when something breaks?
- Are content changes included or separately scoped?
- What happens outside normal working hours?
- Are backup restoration and emergency investigation included?
- Who pays for platform, plugin and service subscriptions?
Separate a response target from a resolution promise. Some faults can be corrected immediately; others depend on a hosting provider or missing account access. Avoid assuming either without discussing it.
Treat recovery as a practical task
A backup is useful only if the right information is included and someone knows how to restore it. Ask where copies are stored, how far back they go, and whether recovery has actually been tried in a safe environment.
For WordPress, the official guidance distinguishes the database from the site's files: a typical full recovery needs both. Downloading the visible files alone is not necessarily a complete backup. WordPress backup guidance.
Other platforms have different export and recovery options. For a static website, source files may be straightforward to preserve, while messages stored in an external form service need separate consideration. Agree how much recent information the business could afford to lose and plan around that.
Check the customer journey after changes
An update that installs successfully has not yet proved the website works. Test the actions people actually take:
- Open the main pages on a phone and a larger screen.
- Send a clearly labelled test enquiry and verify its arrival.
- Check telephone, email, directions and booking links.
- Try a form with a missing required field.
- Confirm the completion message explains what happens next.
Use a provider's test mode for payment checks where available. Do not create real bookings or payments casually on a live business system. Record what was checked so that the next person does not have to guess.
Performance checks can form part of this work. If a page has become noticeably slower, our guide to diagnosing a slow website explains how to separate loading problems from delayed interactions.
Example: a seasonal service change
Imagine a Cheltenham gardening business adding winter maintenance to its existing website. This is a hypothetical example, not a customer case study.
The visible change is one new service page. The maintenance work also includes updating the enquiry options, removing an expired summer offer, checking the confirmation email and confirming that new messages reach the right person. Taking a recovery copy before the changes gives the business a route back if something unexpected happens.
A full redesign would be unnecessary if the current structure still supports these tasks. The priority is keeping the published information and the enquiry process aligned with the real service.
Choose the next piece of work from the evidence
If the site is reliable but dated, content and presentation may be the priority. If enquiries are disappearing, delivery and form handling come first. If the platform cannot be updated safely, investigate that limitation before adding more features.
A useful maintenance handover leaves you with an account inventory, an agreed scope, a record of changes and a recovery plan. For help with an existing business website in Cheltenham, I can review the situation with you and scope the practical next step.
Send James the website address and the problem you want solved. A short description of what has stopped working is more useful than guessing which technology needs replacing.