Website stewardship guide 02
Your site can look unchanged while software, forms, and outside services change around it. A useful maintenance plan says what gets checked, what happens when something breaks, and how you will know the work was completed.
← All website stewardship guidanceList what needs care
Review alerts
Prepare changes
Test the live site
Report open work
Why this matters
Maintenance includes the visible parts of the site and the systems behind them. A software update can affect a menu. A changed mailbox can stop inquiries arriving. An expired subscription can disable a booking feature. These problems need different checks and different people to resolve them.
Ask your provider to describe the routine in terms you can verify: which customer paths are tested, which updates are handled, who receives alerts, and what happens outside the recurring scope. A short change record should tell you what changed, whether the important tasks still work, and what needs your decision.
Responsible practices
Identify the platform, major integrations, important pages, and customer paths. Record what the provider maintains, what the host handles, and what your staff must report or approve. A static site, a content-management system, and an online store have different needs. The plan should reflect those differences.
Schedule routine checks, but give urgent security notices, outages, and delivery failures their own response path. A risk-based approach considers the affected software, exposure, and business impact. Agree who can approve an emergency change and who is available when an alert arrives.
Ask the provider to check compatibility, create a suitable recovery point, and test significant changes in a separate preview when practical. A rollback is the route back to a known working version. It needs to cover any affected data or configuration as well as the page files.
Install updates, themes, and plugins only from the official source, such as the vendor or the platform's own directory. Never use "free" copies of paid plugins; they can carry hidden malicious code. On WordPress and similar platforms, remove plugins that no longer get updates, even if they still seem to work. Ask who watches security notices for the tools that build and publish the site.
After relevant changes, check the affected pages on a phone and desktop, complete a test form, and follow call or booking links. The provider should also check technical failures such as broken redirects and unexpected indexing settings. A useful report names the work, the checks, and anything still open; you should not need to decode a list of plugin version numbers.
Worked example
Illustrative planning example, not a service commitment. The frequency of each check should suit the site, its risks, and the responsibilities you agree with your provider.
Separate completed work from decisions awaiting the business. The report should make the next action obvious.
Maintenance runbook
Choose the pages and actions your business relies on most.
Ask who receives an outage or form-delivery alert and what response is included.
Agree how your team reports changed hours, services, staff, and links.
Review the provider's change record and assign someone to answer open questions.
Keep a list of the site's software and a maintenance runbook: written steps for routine checks, urgent updates, rollback (returning to the last working version), and escalation.
Test material changes before release where practical, then verify the affected customer paths and technical signals.
Report completed work, unresolved issues, and decisions needed in a form the business can understand.
Avoid these failures
Good website care lowers risk, but no provider can guarantee uninterrupted service.
Questions business owners ask
Use a routine schedule plus event triggers. Urgent security notices, outages, and failed inquiry delivery need prompt assessment. Routine reviews can follow an agreed calendar that reflects the site and the support you have purchased.
That depends on the platform and the update. Ask how compatibility, backups, monitoring, and recovery are handled. Automation can reduce delay, but someone still needs to respond to a failed update.
What changed, what was checked, what failed or remains open, and which decisions need your input. The detail should let you understand the state of the site without interpreting technical version lists.
Check the agreement. Technical updates, approved text edits, new pages, redesigns, and integrations may have different allowances or prices. Ask the provider to identify the scope before work starts.
Primary guidance
Plan the next step