Method · version 3, October 2026

How we test web hosting

This is the complete method behind every review on The Hosting Mill: what we buy, what we build, what we measure and how the final score is calculated. When the method changes, the version number above changes too, and older reviews are labelled with the version they were tested under.

§01 — The 30-day cycle

Seven stages, same order, every host

Running the same steps in the same order is what makes two reviews comparable. If a host cannot complete a stage — for example, it offers no self-service restore — that gap is scored, not skipped.

Day 0

Purchase

We buy the plan anonymously at the public price, through the normal checkout. We note every upsell, pre-ticked box and the stated renewal price.

Day 1

Build

We install our standard test site: WordPress, a common theme, twelve plugins, sixty posts with images, a contact form and a small shop with ten products.

Days 1–30

Monitor

External checks run every minute from several regions. Speed tests run on a schedule morning, afternoon and night so busy hours are included.

Day 10

Load test

We send a gradual rise in simulated visitors to see where response times start to climb and whether the site recovers once traffic drops.

Day 15

Break and restore

We deliberately break the test site, then time how long it takes to restore it from the host’s own backup tools.

Days 1–30

Support

We open at least three support conversations of rising difficulty at different times of day, and grade the correctness of the answers, not just the speed.

Day 31+

Score and publish

Results are scored with the published weights, reviewed by a second editor, and published with the test dates and raw figures.

§02 — Metrics

Exactly what we measure, and how

Every figure in a review links back to one of these rows.

What we measure	How	Why it matters
Uptime	1-minute external checks from several regions; an outage counts when two locations agree	Reliability over a full month, including the longest single outage
Time to first byte	Scheduled uncached requests, median of all runs	Shows server and database speed without caching hiding it
Full page load	Real-browser tests of the home page and a product page	What a visitor actually experiences
Load behaviour	Gradual increase in simulated concurrent visitors	Reveals how the plan copes with a busy day
Restore time	Timed restore of a deliberately broken site from host backups	Backups only matter if they can be restored quickly
Support quality	Three graded conversations at different hours	A fast wrong answer is worse than a slow correct one
Value	Total cost over the first three years including renewals	The introductory price is rarely the real price

§03 — Scoring

How the final score is weighted

Each category is scored out of ten, then combined using fixed weights. Weights are the same for every host in a category so scores stay comparable. Category-specific adjustments — for example, scaling speed for cloud plans — are described in that category’s reviews.

Performance

35%

Reliability & uptime

25%

Support quality

15%

Value over three years

15%

Ease of use

10%

A host that fails a stage entirely — no working restore, or a support conversation that leads to data loss — receives a capped score regardless of other results.

§04 — Ground rules

The rules we do not bend

These rules exist so the method above cannot be quietly bought or shortcut.

No free accounts

We do not accept complimentary plans, sponsored tests or early-access accounts for reviews.

Anonymous purchase

Accounts are opened without telling the host we are reviewers, so support treats us like anyone else.

Six-month re-tests

Each reviewed plan is re-tested at least every six months, or sooner after major changes.

Public change log

Every score change is recorded with the date and the reason, at the bottom of the review.

Second-editor check

A second editor checks the figures against the raw data before anything is published.

Corrections welcome

If a host or reader shows us an error, we re-check and correct it publicly.

Spotted a problem with our method?

Method changes often start with reader feedback. Tell us what we are missing.