Before buying a website maintenance plan, ask the provider to explain what it will change, what it will check and what happens when something fails. A monthly fee or a long list of tools gives you little basis for comparing the work unless those responsibilities are clear.
For an Australian small business, the website may support a simple but important route: a customer finds the right service, checks whether the business can help and sends an enquiry. A maintenance proposal should account for the actual site and the functions it depends on.
Start with the arrangement you already have. Hosting, software updates, content edits and fault support may be supplied together or by different people. Find out what is covered before adding another subscription or assuming a new provider will take over everything.
Start With the Website and Its Existing Responsibilities
Give the prospective provider the public website address and a description of how the site is used. Identify the platform if you know it, who currently manages it and the important connected services. You do not need to diagnose the technology yourself.
A WordPress site might need a different maintenance arrangement from a hosted website builder or a static site. Ask the provider to confirm that it can support your particular setup, including custom features and software supplied by someone else. A generic WordPress plan should not be accepted as a complete scope for every website.
List existing hosting, domain, email, software and support arrangements. Ask which will continue, which the proposal would replace and which remain outside it. Keep a change of provider or hosting as an explicit decision, with its own dependencies and costs.
If the website has a known fault, describe it before the plan starts. Ask whether investigation and initial repairs are included, separately quoted or required before the provider can accept the site. Our fix, refresh or rebuild guide helps with that wider decision. A recurring plan should not silently become a rebuild commitment.
Separate Routine Work From Faults and New Requests
Have the proposal distinguish the kinds of work you expect. Software maintenance, changing a service paragraph, investigating a broken form and adding a booking feature can require different skills, permissions and approvals.
Use a short comparison record when discussing two plans:
| Work Item | Question for the Provider | Evidence or Limit to Record |
|---|---|---|
| Routine software updates | Which parts of this site are covered, and how are changes scheduled? | Components, exclusions, approval route and checks after a change |
| Backup and recovery arrangements | What is saved, and who handles an agreed recovery? | Available recovery evidence, responsible person and work outside the fee |
| A reported website fault | Who investigates it, when is support available and what costs extra? | Contact route, response commitment, repair scope and escalation |
| Content edits or a new feature | What request is included, and when is another quote needed? | Defined allowance, business approval and treatment of additional work |
Ask what words such as “unlimited”, “monitoring” and “support” mean in the actual agreement. An allowance might cover a small text correction while excluding copywriting, a new layout or a third-party integration. Have the provider explain that boundary with a request your business is likely to make.
If you plan to edit content yourself, include that in the responsibilities. Our website editing handover guide covers practising those tasks and understanding the supplied access. Technical maintenance and everyday content editing need their own agreed owners.
Ask How Updates Will Be Prepared and Checked
For a WordPress proposal, ask which core software, themes and plugins the provider will manage. Clarify how automatic updates, paid licences, custom code and unsupported components are handled. A plan name does not tell you the configuration of your site.
WordPress's updating guidance recommends backing up before an update so the website can be restored if problems occur. Ask the provider to explain its preparation and recovery arrangements for your site. Having a backup scheduled and demonstrating an appropriate recovery path are separate pieces of evidence.
Ask how significant changes are assessed before they reach the public site. A separate test copy may be appropriate, but the provider needs to explain how it handles private information and connected services. Agree how test messages, bookings or other side effects will be controlled before any such copy is used.
Then agree the checks after an update. They should reflect what changed and the customer routes that might be affected. For a service business, that could include the menu, relevant service page, mobile layout and the agreed enquiry path. A report that software was updated does not establish that these functions were checked.
Define Monitoring, Support and Recovery Separately
Ask what each monitor observes, how often it runs and who receives an alert. A page responding to a monitoring request gives different evidence from an agreed check that an enquiry reaches the intended recipient. Find out what remains outside the monitor's coverage.
Clarify the support hours and the route for reporting an urgent issue. Ask what a response commitment means: an acknowledgement, the start of investigation or a resolved fault. Keep any promised time tied to the written agreement and its actual conditions.
If a problem appears after an update, have the provider explain how it will investigate, communicate and decide the next action. Rolling back may be one option, but the provider should consider recent content or business records and connected systems before proposing a live recovery. The owner needs to understand the consequences of that decision.
Ask for the change made, the checks completed and the unresolved items. Keep those observations separate from a general “all healthy” summary.
A maintenance plan can include security work without guaranteeing that an incident will never occur. Ask what detection, investigation and recovery work is covered, what needs another specialist and what may be charged separately. Avoid treating the presence of a scanner or backup badge as a complete explanation.
A Worked Example: A Form After a Plugin Update
An example pest-control business is comparing maintenance plans for a WordPress website with an enquiry form. The owner wants routine software care and a clear process when the contact route has a problem.
One proposal lists plugin updates and uptime monitoring. The owner asks whether checks after updates include the form, who receives any agreed test and whether delivery to that recipient is confirmed. They also ask whether a fault investigation is included or billed separately.
The proposed check uses approved dummy details and a recipient who has agreed to receive it. The record would distinguish the page displaying a confirmation from the intended recipient receiving the message. If delivery has not been checked, it stays unverified.
Suppose the form fails after a plugin change. That timing is a useful observation for investigation; it does not establish the cause by itself. The provider should record the affected page, steps and result, then explain the proposed repair or recovery decision and any additional approval needed.
This example describes questions and an agreed test plan only. No plugin has been updated, message submitted, fault diagnosed or repair verified here. The business has a clearer basis for choosing the service without assuming either plan prevents every problem.
Keep a Record of the Work and Remaining Issues
Ask what the regular report will contain. Useful entries identify the site, work date, affected component or page, action taken and checks completed. An item that was deferred or could not be checked should have a reason, responsible person and next action.
Keep known faults separate from new requests. A customer asking for a booking feature is different from the business reporting that its agreed enquiry form no longer works. Both need a decision, but they should not disappear into one undifferentiated support count.
For changes to important customer routes, adapt the relevant checks in our website launch checklist. Agree a proportionate check for the maintenance work; the launch checklist is a reference, not a requirement to repeat an entire launch review after every edit.
Review commercial results separately. Completed maintenance, a working enquiry route, received enquiries and paid jobs answer different questions. A clean report does not prove that rankings, traffic or sales improved because of the plan.
Compare the Complete Arrangement Before Paying
Have each proposal state the recurring fee, tax treatment, software renewals, initial work, additional charges and how the arrangement ends. Ask what happens to access, licences, reports and recovery copies if you leave. Do not assume changing the maintenance provider also transfers hosting, email or every connected account.
Check who approves public content and material changes. Routine permission to maintain the software should not become an assumption that the provider can publish new prices, change service claims or replace a connected system without the agreed approval.
Bring your current website address, known problems and expected support tasks to a discussion of AWE's website packages and ongoing support. Ask what can be provided for your particular site and have the updates, checks, support limits and fees confirmed in the proposal before committing.