A website care plan is an ownership agreement—not a bundle of vague hours.
The useful outcome of monthly website management is not that someone appears busy. It is that a named owner watches the parts of the website that can affect discovery, trust, inquiries and day-to-day operations, then records what changed and what still needs a decision.
That agreement should identify the production website, hosting account, domain and DNS boundary, content system, forms, analytics, connected services and responsible contacts. If an item is not covered, say so. A short explicit scope is safer than an unlimited promise that nobody can verify.
Start with a baseline before accepting monthly responsibility.
Run the free Website Growth Scan on one important public page to establish a reproducible outside-in snapshot. The result can surface discovery, clarity, confidence, action and browser-performance questions, but it cannot inspect private accounts, backup integrity, inbox delivery or internal ownership. Those require an owner-authorized review.
- Record the canonical domain, critical pages, primary conversion paths and current technology owners.
- Confirm who controls the domain, DNS, hosting, source code, CMS, analytics and lead destinations.
- Save current uptime, performance, search and verified inquiry-delivery evidence.
- List known faults, unsupported components and inherited risks separately from routine care.
Define the recurring core in observable terms.
Frequency should follow risk. A high-value booking flow may justify more frequent checks than a stable brochure page. The plan should distinguish automatic detection, human verification and actual remediation instead of calling all three ‘monitoring.’
| Care area | Recurring responsibility | Evidence to report |
|---|---|---|
| Availability | Monitor the agreed public routes and escalate confirmed failures | Incident time, affected route, response and resolution |
| Backups and recovery | Run the agreed backup schedule and test restoration at a defined interval | Last successful backup, retention and recovery-test result |
| Updates and security | Review supported CMS, plugin, dependency and platform updates through change control | Updates applied, deferred risks and verification result |
| Lead delivery | Test critical forms and reconcile browser success with controlled delivery | Test date, destination, delivery result and corrective action |
| Measurement | Check analytics and search instrumentation for obvious loss or configuration drift | Coverage status, anomalies and decisions needed |
| Content and SEO hygiene | Maintain agreed pages, metadata, links and indexable technical signals | Pages changed, reason and post-change verification |
| Performance and accessibility | Watch critical templates for regressions after changes | Comparable checks, confirmed regression and remediation |
Backups only matter when recovery is owned and tested.
A backup checkbox does not prove that the website can be restored. Document what is copied, where it is retained, how long it is kept, who can authorize a restore and which domain, secrets, uploads or external services are not included. Test recovery on a safe schedule and record the outcome.
Australian Cyber Security Centre guidance treats backups and updates as practical small-business protections. The care plan should translate that principle into the website's actual stack without claiming that routine maintenance removes every security risk.
Lead monitoring must follow the inquiry beyond the button.
Use controlled test data, label it clearly and exclude it from commercial reporting. Never create fake inquiries merely to inflate scanner or lead metrics. The useful monthly report separates test evidence from real customer activity.
| Stage | Question | Failure a visual check misses |
|---|---|---|
| Form | Can a visitor submit valid data on mobile and desktop? | Validation or scripts block completion |
| Confirmation | Does the visitor see what happens next? | A silent or misleading success state |
| Delivery | Does the controlled test reach the intended inbox or CRM? | The website reports success while the message is filtered or rejected |
| Ownership | Is a responsible person alerted and able to act? | The lead exists but nobody owns the response |
| Measurement | Can the team distinguish accepted, delivered and qualified inquiries? | A click or browser event is mistaken for revenue |
Keep routine care separate from projects and unlimited requests.
This separation protects both sides. The client knows what the monthly fee buys, and the responsible team can reserve enough capacity to keep the operational promise instead of spending it on an undefined feature queue.
- Usually included: bounded updates, monitoring, controlled maintenance, small agreed content changes and incident triage.
- Usually estimated separately: new templates, integrations, migrations, major redesign, custom application features and large content production.
- Always clarify: third-party fees, after-hours response, emergency work, legal review, security incident response and unsupported legacy systems.
- Use a change request when an item alters scope, risk, delivery time or recurring infrastructure cost.
Make response targets specific enough to verify.
A remote team can support Australian and New Zealand clients without pretending to be locally staffed. The proposal should state the exact coverage window, holiday basis and escalation channel rather than imply a local office or 24/7 staffing.
| Term | Define it as |
|---|---|
| Acknowledgement | When a named person confirms receipt and begins triage |
| Response | The first evidence-based assessment and next action |
| Workaround | A temporary safe path that restores the critical business function |
| Resolution | The confirmed fix, verification and incident record |
| Coverage window | The time zone, business hours and channels in which targets apply |
Use a monthly report that supports decisions and a clean handover.
The client should retain appropriate ownership of domains, hosting, analytics and business accounts. Keep an access register, use named collaborator accounts and document a fair exit process for credentials, source, backups and operational notes. A durable care relationship should come from accountable value—not from making departure technically difficult.
- Availability incidents and confirmed resolutions.
- Backup status and the latest recovery-test evidence.
- Updates, changes, verification and deferred risks.
- Controlled lead-path tests and delivery outcomes.
- Search, analytics, performance or accessibility anomalies worth a decision.
- Next priorities, owner and proposed scope outside the care plan.
Website care plan FAQ.
What is the difference between website hosting and a website care plan?
Hosting provides the infrastructure that serves the website. A care plan defines human and automated responsibility around monitoring, recovery, updates, lead delivery, measurement, content hygiene and incidents. Some providers combine them, but the responsibilities and account ownership should still be explicit.
How much website maintenance should be included each month?
Define recurring tasks and bounded change capacity from the website's actual risk and update frequency. Avoid an unlimited promise. New features, major design work and migrations should normally use a separate estimate and approval.
Can a website scanner replace monthly maintenance?
No. A public scan is a useful baseline and regression signal, but it cannot own private accounts, test backup recovery, verify every lead destination or respond to incidents. Use it to prioritize the owner-authorized operational review.
Should the agency own the client's domain and hosting accounts?
The client should normally retain appropriate ownership and grant named, minimum-necessary collaborator access. The agreement should document responsibilities, billing, recovery access and a clean handover process.
Can North Growth Lab support Australia and New Zealand?
Yes. North Growth Lab agrees explicit coverage windows for Australian and New Zealand business hours. It does not claim a local AU or NZ office; response scope and time zones are documented in the proposal.