Evaluate a web hosting provider by matching your requirements to dated evidence: the service specification, responsibility boundaries, contract, support process and a representative trial where available. Keep a comparison record for each candidate, including unresolved questions. A list of features or a headline uptime percentage is not enough to choose a provider.
This framework works across shared hosting, VPS, dedicated and managed services. Its output is a provider-evaluation record, not a ranking or a plan-sizing recommendation. WebCare360 publishes this guide and sells hosting; we have not independently benchmarked or scored the providers you may compare.
1. Establish workload fit before comparing providers
Write down what must run: application, runtime and database versions, background tasks, extensions, administrator access, storage and external dependencies. Separate essential requirements from preferences. Give the same brief to each candidate so that answers are comparable.
Ask how resources are allocated and limited. Record CPU policy, memory, storage capacity and I/O limits, network port and transfer allowance separately. A VPS label does not prove exclusive physical hardware: AWS, for example, documents Dedicated Hosts as a specific physical-host allocation option. Ask each provider what its own resource model means rather than assuming every virtual service is unshared.
2. Record the service boundary
For each task, name the provider or your team as the responsible party: provisioning, operating-system updates, application maintenance, monitoring, access changes and incident recovery. Mark optional work and its price. Ask who acts when a task crosses that boundary.
The AWS shared responsibility model illustrates why this depends on the selected service; it does not define another host's contract. Use the actual candidate agreement. If a managed label is unclear, first review managed and unmanaged hosting responsibilities, then request written scope for your order.
3. Read reliability evidence in context
Save the availability commitment and identify the measured service, measurement window, exclusions, scheduled maintenance, claim procedure and remedy. Decide whether those terms match the business impact of an outage. There is no single uptime threshold in this guide that qualifies every workload.
Request an incident-communication example or public status history where available. Note its period and coverage: a short, quiet history is not proof that incidents cannot occur. Separate a contractual credit from the application's ability to continue operating. AWS's availability guidance emphasizes measuring workload resilience, rather than relying only on an intended design.
4. Ask for workload-relevant performance evidence
Record the proposed region, hardware or resource class, allocation policy and relevant limits. Ask which parts are guaranteed and which are examples subject to availability. Test from the intended users and important dependencies if an authorized trial is available.
Define the trial before running it: application version, dataset, concurrency, duration, cache state, measurement points and acceptable result. Compare equivalent conditions and keep the limitations with the result. A vendor demonstration is not an independent measurement of your workload. Use the same conditions when testing each candidate.
Also ask how resizing works, what changes require a migration or restart, and how rollback is handled. Do not turn an upgrade option into a promise of zero downtime.
5. Separate security controls and responsibilities
A security bundle needs a scope record. Ask what is included, which endpoints it covers, who configures it and what happens when it detects a problem.
- DDoS mitigation: covered protocols and addresses, mitigation conditions, exclusions and escalation. Protection scope must fit the service.
- WAF: web-request inspection and rules, with ownership of tuning and false-positive review. It is not a substitute for every network control.
- Firewall: network access rules and responsibility for safe changes.
- Patching and malware: covered software, update ownership, detection versus cleanup and any extra work or fees.
- Authentication: administrative account controls, access revocation and account-recovery process.
- Backup and recovery: recoverable data and a restore process, assessed separately from traffic filtering.
Cloudflare documents DDoS protection and its web application firewall as distinct controls. Those documents explain examples of the technologies; they do not establish that either is included in any WebCare360 or competing plan.
6. Check backup and recovery evidence
Ask whether backups exist for the files, databases and configuration you need. Record the schedule, retention, storage separation, access protection, failure alerts, restore owner and cost. Ask whether offsite copies are included and what failure that separation is intended to address.
Request the scope and date of a relevant restore test, or agree how you will test your own recovery safely after provisioning. A backup job reporting success is different evidence from an application restored and checked. Record the tolerable data loss and recovery time for your workload, then identify whether the proposed process can be tested against them. A one-click interface alone does not settle those questions. AWS’s recovery-testing guidance describes checking restored data and recovery objectives; apply the principle to your own agreed process.
7. Evaluate support as an operating process
Record channels, staffed hours, severity definitions and escalation contacts. Distinguish a first-response target from a resolution commitment, and ask which application problems are outside support scope. Check how updates reach you during an incident and what information the team needs to investigate.
If you send a pre-sales question, keep the actual answer and date. One interaction can clarify a process; do not treat it as a measured long-term response guarantee. Match after-hours responsibilities to the staff your organization can actually provide.
8. Review contract and policy before purchase
Read the current acceptable-use rules, content restrictions, service limitations, suspension process, cancellation notice, refund conditions, renewal terms and data-export provisions. Record the version and any written clarification. Ask how the chosen location and data-handling arrangement meet your organization's requirements; obtain specialist advice where necessary.
This is a general provider review. If overseas placement is a separate decision, use the offshore location-suitability guide. Once that choice is made, offshore plan selection turns a workload brief into plan-level requirements. Neither step replaces evaluating the supplier's evidence.
9. Compare the recurring total
Use the same period and assumptions for each quotation. Include the base service, licences, management, backup storage and restores, transfer or overage, IP resources, setup or migration work, renewal price and applicable taxes. Mark usage-dependent amounts as assumptions, not fixed prices.
Record what happens when a limit is exceeded and which options are required to satisfy your brief. Do not compare a promotional first payment with a competitor's recurring total. Current prices, specifications and availability belong on the relevant product quotation, not in this guide.
10. Complete a provider-evaluation record
Create one record per candidate using the fields below. This is a suggested evidence framework, not a certification scheme or a weighted scoring system.
- Requirement: the capability or operating condition, and why it is essential or optional.
- Evidence: the exact specification, agreement clause, dated written answer or trial result, with its limitations.
- Scope: the service, location, account and time period to which that evidence applies.
- Responsibility and cost: who delivers it, who checks it and whether it is included.
- Finding: supported, contradicted or unresolved. Record conflicting sources rather than choosing the most favorable wording.
- Next action: the question, test or contractual clarification needed, with an owner and deadline.
- Decision: accept, reject or defer, with the person accepting any remaining limitation.
For example, if a quotation says backups are included but provides no retention or restore scope, record the requirement as unresolved. Request those details before treating recovery as a supported capability. Keep the backup requirement open until those details are confirmed.
Resolve essential gaps before choosing. Keep the evidence with the purchase decision so that the delivered service can later be checked against it. To compare WebCare360 service types, use the infrastructure comparison and the applicable current offer; confirm each required feature on the selected plan before ordering.
