Hosting and maintenance are often sold as one vague line item, even though they solve different problems. Hosting provides the environment that serves the site; maintenance is the ongoing work of observing, protecting, testing, recovering, and improving it. Support is a third responsibility: helping people when an incident or request occurs. A reliable website care plan defines all three layers, names the accounts and systems involved, and makes exclusions as visible as features. This guide gives a small business a practical checklist for comparing plans without expecting impossible guarantees.
The central ideaGood website care is specific and testable: suitable infrastructure, active monitoring, restorable backups, controlled updates, defined support, useful performance checks, clear account ownership, and a workable exit path. Compare plans with realistic incidents and annual commitments, then require evidence that promised work happened. That is more valuable than an undefined “fully managed” label or an uptime claim with no recovery process.
Understand the infrastructure layer
A hosting description should cover the production environment, HTTPS certificate handling, expected capacity, geographic considerations, and how deployments occur. It should identify who controls the account and whether email, domain registration, or DNS management is included or merely adjacent.
No host can promise that incidents never happen. Ask how availability is monitored, who receives alerts, and what escalation occurs when the site cannot serve visitors. The useful commitment is a documented response and recovery process, not an absolute uptime claim without terms.
Clarify the boundary between managed and unmanaged infrastructure. With an unmanaged service, the host may keep the underlying platform available while your team remains responsible for application deployments, configuration, security updates, logs, and failures. A managed plan may take on some of that work, but “managed” has no universal scope. List the operating system or platform, runtime, database, storage, content delivery network, and deployment path, then assign an owner to every layer.
Demand backups that can be restored
A backup policy needs frequency, retention, storage separation, encryption where appropriate, and coverage details. Database, uploaded media, configuration, and code may have different backup paths. A copy on the same failing system is not a complete recovery plan.
Ask when restoration was last tested and who can authorize it. The provider should explain the target recovery point, likely disruption, and whether restoring one file differs from recovering the entire site. Backups have value only when they are accessible and usable during an incident.
Discuss recovery with plain scenarios. If an editor deletes a page at noon, how far back can the provider restore and what newer changes might be lost? If the hosting account becomes unavailable, are copies stored under separate credentials or with another provider? If a database is corrupted, does restoring it also revert recent orders or inquiries? NIST contingency guidance treats backup, recovery, testing, and ongoing maintenance as connected activities; a schedule without a tested process is incomplete.
- Backup frequency, retention, scope, and separate storage
- Restore testing and authorized decision makers
- Monitoring alerts and incident escalation
- Domain, DNS, certificate, and email boundaries
Define maintenance and support separately
Maintenance may include framework or plugin updates, dependency review, security patches, broken-link checks, form testing, performance review, and compatibility testing. The relevant list depends on the technology. Updates should be tested and have a rollback path rather than applied blindly to production.
Support describes how people request help and how quickly the provider acknowledges different levels of urgency. Define business hours, emergency criteria, channels, included time, and what counts as new development. A five-minute text correction and a new booking integration should not share an ambiguous promise.
Security language needs equal precision. OWASP provides verification standards for web application controls and software components, but routine maintenance is not automatically a security audit or compliance certification. Ask which dependencies are inventoried, how vulnerability notices are evaluated, whether privileged accounts use multifactor authentication, and when specialist testing is recommended. The plan should explain risk decisions and escalation rather than promising that an updated site can never be compromised.
Protect continuity and ownership
The business should know where the domain, DNS, hosting, source, analytics, and credentials are held. Use role-based access where possible and avoid sharing one password across teams. Keep a current contact list for technical, billing, and emergency decisions.
A care plan should explain reporting, cancellation, exports, retention, and migration support. Monthly reporting can be concise: incidents, updates, backups, important changes, and recommended next actions. A plan is strongest when another qualified team could understand the site if a handoff becomes necessary.
Keep a lightweight service register with each vendor, account owner, billing contact, renewal date, access method, and recovery contact. Include the registrar as well as the domain name because ICANN treats the registrant and registrar as distinct roles. Review the register when staff or agencies change. This prevents a routine handoff from becoming an emergency search through personal inboxes and gives the business a way to revoke old access without locking out the current team.
- Account ownership and role-based access
- Documented support and emergency contacts
- Monthly work and incident summary
- Cancellation, export, retention, and migration terms
Include performance and search-health checks
Hosting affects response time and availability, but performance also depends on application code, images, fonts, third-party scripts, caching, and visitor devices. A care plan should say whether it only monitors server availability or also reviews user-facing performance. Google’s Core Web Vitals measure loading, responsiveness, and visual stability from user experience data, yet Google also cautions that good scores alone do not guarantee rankings. Treat them as useful diagnostics, not a monthly ranking certificate.
Define a manageable review routine. After a deployment, test the homepage, important service pages, primary forms, navigation, and any booking or payment route on mobile and desktop. On a regular cadence, inspect field performance, crawl or indexing warnings, broken internal links, missing assets, and important pages accidentally blocked from search. A monitoring tool can reveal symptoms; someone still needs enough context and authority to decide whether the cause is infrastructure, code, content, or a third party.
Ask what happens when a metric deteriorates but the site remains technically online. The provider might investigate within the maintenance allowance, recommend an optimization project, or identify an external script outside its control. Any of those responses can be reasonable when agreed in advance. The weak arrangement is one that advertises performance monitoring but neither assigns diagnostic time nor defines how findings become decisions. Reports should connect observations to a named next action and owner.
- Post-deployment checks for key pages and conversions
- Field performance and search-health review cadence
- Ownership for investigating alerts and regressions
- Clear boundary between routine tuning and project work
Compare plans with incidents and evidence
Create three test cases before selecting a plan: the website is unreachable, the website loads but its inquiry form fails, and the marketing team requests a new campaign page. For each case, ask how the issue is detected, which channel to use, when acknowledgment is expected, what diagnosis or work is included, who approves additional cost, and how completion is verified. This exercise separates hosting, maintenance, support, and development more clearly than feature tables do.
Request a sample service report. Useful evidence may include incidents and resolution notes, changes deployed, dependency decisions, backup status and restore tests, support requests, performance findings, account risks, and next recommendations. A long automated dashboard is not necessarily better than a concise human summary. The test is whether a business owner can see what happened, which risk remains, and what decision is needed without translating unexplained technical metrics.
Finally, compare the annual commitment rather than the monthly label. Add required hosting, care fees, premium licenses, usage charges, after-hours coverage, included change allowance, likely overages, onboarding, and exit assistance. Then compare the responsibility assumed at that cost. The right plan is not always the largest; a stable brochure site may need a lean routine, while a revenue-critical booking flow justifies deeper monitoring and recovery. Match coverage to consequence and revisit it as the operation changes.
- Run outage, failed-form, and new-page scenarios
- Review a sample report before accepting the plan
- Calculate fixed and probable annual costs together
- Reassess coverage after major technical or business changes