Methodology Specification

HRI™ METHODOLOGY

HostList Ranking Index

Formerly published as HostScore™.

A reproducible 0–100 algorithmic rating for active web hosting companies. The base score is a deterministic function of public profile data; a signal-augmentation layer adds verifiable, evidence-backed micro-signals with continuous time decay. No editorial weighting. No paid placements.

Version 2.2Revised 2 July 2026Range [0, 100] ∩ ℤTerms apply
Interactive

Drag the sliders to see how profile fields move a score in real time. The full specification follows below.

WHAT WOULD YOUR SCORE BE?

Live calculation against the production HRI algorithm. Base components only; signal-augmentation bonuses require verified evidence rows and are not included here.

Reviews

Google Rating4.4
Google Reviews240
Trustpilot Score0
Trustpilot Reviews0
G2 Rating0
G2 Reviews0

Vintage & Freshness

Founded Year2014
Days Since Update20

Performance Tier

Tier maps to a representative URL the real lookup recognises.

Profile Completeness

Estimated HRI
91
/ 100
Trust
25
Complete
23
Fresh
25
Perf
18

PERFORMANCE MEASUREMENT LADDER

The Performance component (0–25 points) uses the strongest available signal for each host. We prefer controlled benchmarks that isolate server performance from site design; weaker fallbacks apply only when no benchmark exists.

Benchmarked

An identical test site load-tested on the host's real plan (e.g. ReviewSignal). Measures response time under load, uptime during the test window, and error rate. The most rigorous signal: it reflects hosting infrastructure, not marketing-site polish.

Measured

Real-user Core Web Vitals (LCP, INP, CLS, TTFB) from Google CrUX field data on the provider's public website. Useful when no benchmark exists, but reflects the host's own marketing site, not how fast your site would run on their platform. We are manually deploying identical test website instances across the top 200 hosts by HRI rank. Benchmark data is published host by host as each deployment is validated and load-tested on the host's real plan. Profiles move from Measured or Estimated to Benchmarked as results go live.

Estimated

Editorial infrastructure tier based on known platform stack (CDN, caching layer, data-centre footprint). Replaced automatically when benchmark or CrUX data arrives.

Baseline

Neutral starting score (11/25) until any performance signal is collected. Not a penalty; hosts rise as data is gathered or signals are verified.

For a buyer-friendly explainer, including hosting speed vs site speed and how to test your own host, see How we measure hosting performance.

ABSTRACT

HRI is a composite measure of public-signal quality for web hosting companies. The base score decomposes additively into four equally-weighted components, T (Trust),C (Completeness), F (Freshness), andP (Performance), each constrained to the integer interval [0, 25]. The total score S(h) = T(h) + C(h) + F(h) + P(h) therefore lies in [0, 100].

Version 2.2 introduces a signal-augmentation layer. Each verified signalσ ∈ Σ(h) carries a value, an evidence_url, a captured_at timestamp, and a per-signal decay_horizon_days. A signal contributes b(σ) · D(σ) to its mapped component, whereD(σ) = max(0, 1 − age_days(σ) / horizon) is a linear time-decay factor in [0, 1]. Components are clamped to [0, 25] after augmentation; the score remains in [0, 100].

The system is append-only: every signal that ever entered the score remains in thehost_signals table with its full provenance, even after it has been superseded by a newer measurement. Claimed host owners may dispute any signal through the dashboard, freezing it out of the active score until adjudication against the recorded evidence.

87
/ 100
Example S(h)
T=20 · C=18 · F=25 · P=24

NOTATION

The remainder of this document uses the following symbols. Each appears in at least one formula below.

hA single hosting company record in the directory.
S(h)The HRI of h. An integer in [0, 100].
T, C, F, PThe four base components: Trust, Completeness, Freshness, Performance. Each is an integer in [0, 25].
σA verified signal, one row of host_signals. Has signal_key, value, captured_at, decay_horizon_days, evidence_url.
Σ(h)The current signal set for h: latest non-superseded, non-disputed σ per signal_key.
D(σ)Linear decay factor of σ. D(σ) = max(0, 1 − age_days(σ) / horizon_days(σ)).
b(σ)The fractional bonus a signal contributes to its mapped component (defined per signal_key).
clamp(a, b, x)min(b, max(a, x)). Used to enforce the [0, 25] ceiling on every component.
𝟙(p)Indicator function. 1 if predicate p holds, 0 otherwise.

FORMAL DEFINITION

For any host h in the directory:

S(h) = T'(h) + C'(h) + F'(h) + P'(h) where X'(h) = clamp(0, 25, X_base(h) + Σ_{σ ∈ Σ(h) : map(σ) = X} b(σ) · D(σ)) D(σ) = max(0, 1 − (now − captured_at(σ)) / (1 day · horizon(σ))) Σ(h) = { latest non-superseded, non-disputed signal per signal_key, for h } S(h) ∈ {0, 1, 2, ..., 100} after componentwise rounding.

The map(σ) function routes each signal_key to one of the four base components; mappings are defined in src/lib/host-signals.ts. The signal setΣ(h) is materialised by the host_signals_currentPostgreSQL view, which filters the append-only host_signals table to the currently-effective row per (host_id, signal_key).

BASE COMPONENTS

Each component is a deterministic function of fields on the hosts table. Formulas below describe the published methodology; the production implementation includes additional proprietary signal mappings and editorial safeguards not fully enumerated here.

Trust 25/100
Completeness 25/100
Freshness 25/100
Performance 25/100
Trust (T)[0, 25]

Multi-platform review signal, profile vintage, and verified ownership.

T(h) = clamp(0, 25, round( rating_term(h) // [0, 8] 8 · google_rating / 5, or Trustpilot fallback [0, 6] + volume_term(h) // [0, 7] log-banded google_review_count, or Trustpilot fallback [0, 4] + vintage_term(h) // [0, 5] age-banded founded_year + verified_term(h) // {0, 5} 5 · 𝟙(claimed_at ≠ null) + tier_bonus(h) // {0, 5} 5 · 𝟙(P(h) ≥ 18) + tp_term(h) // [0, 2] Trustpilot corroboration (only alongside Google) + g2_term(h) // [0, 2] G2 corroboration ))
Sub-terms
  • rating_term= 8 · google_rating / 5 if google_rating ≠ null; else 6 · trustpilot_score / 5 if trustpilot_score ≠ null ∧ tp_reviews ≥ 10; else 0. v2.2: Trustpilot substitutes at a discounted ceiling when Google data is absent, Google dominates whenever present.
  • volume_term= { 7 if google_review_count ≥ 1000; 5 if ≥ 100; 3 if ≥ 10 }. When google_rating is null: { 4 if tp_reviews ≥ 1000; 3 if ≥ 100; 1 if ≥ 10 }; else 0.
  • vintage_term= { 5 if founded < 2005; 4 if < 2010; 3 if < 2015; 2 if < 2020; else 1 } if founded_year ≠ null else 0
  • verified_term= 5 if claimed_at ≠ null else 0
  • tier_bonus= 5 if Performance ≥ 18 else 0. Couples Trust to verified infrastructure quality.
  • tp_term= { 2 if trustpilot_score ≥ 4.0 ∧ tp_reviews ≥ 100; 1 if score ≥ 4.0 ∧ reviews ≥ 10; 1 if score ≥ 3.5 ∧ reviews ≥ 100; else 0 }, awarded only when google_rating ≠ null (when Google is absent, Trustpilot already fills the review terms, corroboration on top would double-count). Asymmetric, bad Trustpilot does NOT subtract from Trust.
  • g2_term= { 2 if g2_rating ≥ 4.0 ∧ g2_reviews ≥ 50; 1 if rating ≥ 4.0 ∧ reviews ≥ 10; 1 if rating ≥ 3.5 ∧ reviews ≥ 50; else 0 }. G2 thresholds halved vs Trustpilot because G2 is B2B/SaaS-leaning with smaller per-host volumes.
Inputs
hosts.google_ratinghosts.google_review_counthosts.founded_yearhosts.claimed_athosts.trustpilot_scorehosts.trustpilot_review_counthosts.g2_ratinghosts.g2_review_count
Completeness (C)[0, 25]

Disclosure of public profile data.

C(h) = clamp(0, 25, 5 · 𝟙(url ≠ null) + 3 · 𝟙(description ≠ null) + 3 · 𝟙(logo_url ≠ null) + 3 · 𝟙(claimed_at ≠ null) // proxy: has verified contact channel + 2 · 𝟙(city ≠ null ∨ country ≠ null) + 5 · 𝟙(segment ≠ null) + 2 · 𝟙(founded_year ≠ null) + 2 · 𝟙(affiliate_url ≠ null ∨ affiliate_network ≠ null) )
Sub-terms
  • Maximum unaugmented total= 25. The 0-1 indicator structure means C is integer-valued before clamping.
  • SaturationAny subset of 25-pts worth of fields saturates. Adding more fields beyond that does not lift C.
Inputs
hosts.urlhosts.descriptionhosts.logo_urlhosts.claimed_athosts.cityhosts.countryhosts.segmenthosts.founded_yearhosts.affiliate_urlhosts.affiliate_network
Freshness (F)[0, 25]

Recency of profile and signal updates.

Δd = floor((now − updated_at) / 1 day) F_base(h) = { 25 if Δd ≤ 30; 20 if 30 < Δd ≤ 90; 15 if 90 < Δd ≤ 180; 10 if 180 < Δd ≤ 365; 5 otherwise } F(h) = clamp(0, 25, F_base(h) + 0.5 · Σ_{σ ∈ Σ(h)} D(σ))
Sub-terms
  • Base curveStep function on profile updated_at. Banded for backward compatibility, the augmentation term provides continuous resolution.
  • Signal contributionEvery verified σ contributes 0.5 · D(σ) to Freshness on top of its component-specific bonus. Encourages re-verification.
Inputs
hosts.updated_athost_signals_current.captured_at
Performance (P)[0, 25]

Independent benchmark first, then measured field data, then infrastructure tier.

P_base(h) = benchmark(h) if fresh controlled-benchmark (≤ 400d) else cwv(h) if fresh CrUX field data (≤ 120d) else tier_lookup(domain(h.url) || h.slug) ∈ {22 tier-1, 18 tier-2, 14 tier-3, 11 default} benchmark(h): response-under-load 0-14, uptime 0-7, Top Tier +4, minus error-rate penalty; a Top Tier award floors P_base at 18. cwv(h) = 25 · Σ wᵢ·fᵢ(mᵢ) / Σ wᵢ weights LCP 10, INP 6, CLS 5, TTFB 4 good thresholds: LCP 2.5s, INP 200ms, CLS 0.10, TTFB 800ms (Google 2026) P(h) = clamp(0, 25, P_base(h) + 1.0 · D(σ_status_page) + 0.5 · D(σ_ipv6) + 0.5 · D(σ_http3) + ...)
Sub-terms
  • Benchmarked (authoritative)When an independent controlled benchmark exists (an identical test site load-tested on the host's real plan, e.g. ReviewSignal), Performance is derived from response time under load, uptime, and the Top Tier award. Shown on the profile as "Benchmarked". This measures the customer experience, not the provider's own marketing site.
  • Measured (CrUX)Absent a benchmark, aggregated p75 Core Web Vitals from real-user CrUX field data on the provider's public website origin (LCP, INP, CLS, TTFB) score Performance directly. Shown as "Measured". This reflects the host's marketing site, not customer sites on their platform. Field data older than 120 days is discarded. Identical test-site benchmarks for the top 200 hosts are in deployment (see FAQ).
  • Estimated (tier)Hosts with neither signal fall back to an editorial infrastructure tier (see src/lib/known-host-tiers.ts), shown as "Estimated". Matched by URL domain or brand token so regional TLDs and descriptive slugs resolve correctly.
  • BaselineA host with no benchmark, no field data, and no known tier receives P_base = 11, a mid-scale starting point rather than a penalty. It rises as data is collected or via signal augmentation.
Inputs
hosts.bench_top_tierhosts.bench_uptime_pcthosts.bench_response_mshosts.cwv_lcp_mshosts.cwv_inp_mshosts.cwv_clshosts.cwv_ttfb_mshosts.urlhosts.slughost_signals_current.signal_key in {status_page_present, ...}

SIGNAL AUGMENTATION LAYER

The base 4×25 formula uses banded inputs and therefore moves in step-function jumps. The augmentation layer introduces continuous fractional bonuses on top of each component, giving the total score genuine single-point resolution. Each enabled signal is extracted from public sources by an autonomous runner (scripts/enrich/run.ts) and written tohost_signals with full provenance.

B_X(h) = Σ_{σ ∈ Σ(h) : map(σ) = X} b(σ) · D(σ) augmented X'(h) = clamp(0, 25, X_base(h) + B_X(h)) every σ also contributes +0.5 · D(σ) to F (component-agnostic freshness bump)
Enabled signal extractors
signal_keyextractor + notesbonus mappinghorizonmin confidence
status_page_presentHTTP probe of status.{domain}, /status, /uptimeCounts only when the response contains operational-status vocabulary (operational, incident, uptime, degraded, maintenance, monitoring). Prevents a 200-status marketing page from passing as a status page.P += 1.0 · D(σ)180d50
free_ssl_documentedLexicon match on /pricing, /plans, or root with plan-context windowSearches for "free SSL" / "Let's Encrypt" and variants. /pricing match passes at 90 confidence; root-page match requires a plan-context word (price, "/mo", "features", "included", etc.) within ±200 chars of the phrase. Tag-stripped, whitespace-collapsed surrounding-sentence stored as evidence.C += 1.0 · D(σ)365d70
renewal_price_delta_pctPricing-page DOM extraction (pending)Computes (renewal − intro) / intro × 100. Lower deltas indicate pricing transparency. Implementation in progress.C += 1.0 · D(σ) if delta < 50; +0.5 if delta < 10090d60
support_response_minutesMeasured form submission at 14:00 UTC (pending)Real measurement against the host's public support channel. Only counts first-touch human reply (auto-responders filtered).T += 2.0 · D(σ) if < 60min; +1.0 if < 240min90d100

Signals listed as pending are in active development. Bonus mappings and horizons are declared in source before deployment, so the algorithm version increments when these come online and the public spec updates in the same commit.

DATA PROVENANCE & AUDIT TRAIL

Every signal that contributes to a score is durably recorded. The table below summarises the per-row fields.

table host_signals (append-only; primary store) id uuid host_id uuid → hosts(id) signal_key text // e.g. "status_page_present" signal_value jsonb // payload, schema per signal_key evidence_url text // where the agent found it evidence_excerpt text // ~200 char raw snippet evidence_hash sha256(excerpt) // dedup; idempotent insert captured_at timestamptz captured_by text // "agent:v1" or "user:..." confidence smallint ∈ [0, 100] decay_horizon_days int superseded_at timestamptz? // set when newer σ arrives superseded_by uuid? // → host_signals(id) disputed_at timestamptz? resolution text? // 'upheld' | 'overturned' | 'pending' view host_signals_current (read by scoring layer) = SELECT DISTINCT ON (host_id, signal_key) ... WHERE superseded_at IS NULL AND (disputed_at IS NULL OR resolution = 'upheld') ORDER BY host_id, signal_key, captured_at DESC
  • Append-only. The scoring layer never issues UPDATE on host_signals. A new measurement is a fresh INSERT that supersedes any prior row for the same (host, signal_key) via the supersede_prior_signal RPC.
  • Idempotent. The (host_id, signal_key, evidence_hash) UNIQUE index makes re-discovery of the same evidence a no-op. The runner can re-process any host without disturbing the score.
  • Disputable. A claimed host owner files a dispute via the host dashboard with a counter_evidence_url. The signal is excluded from host_signals_current until a reviewer adjudicates upheld or overturned. Resolution times are bounded by the disclaimer SLA.
  • Inspectable. Every active signal on a host profile links back to its evidence_url. There are no opaque inputs.

PUBLISHED METHODOLOGY & VERSIONING

We publish this specification so buyers and host owners understand how scores are derived. The methodology, weightings, signal extractors, tier classifications, and enrichment pipeline are proprietary intellectual property of HOSTLIST.IO. Publishing the formula does not grant a licence to reverse-engineer, reproduce, or create derivative ranking systems. See our Terms of Service.

Current version2.2 · revised 2 July 2026ChangeTrustpilot now substitutes for the Google review terms at a discounted ceiling (rating 0-6, volume 0-4) when a host has no Google Places data, Google coverage is a fraction of the directory and well-reviewed hosts were scoring as if they had no review signal. Google remains dominant whenever present; the Trustpilot corroboration bonus now applies only alongside Google to avoid double-counting. v2.1 added Trustpilot/G2 corroboration; v2.0 introduced the signal-augmentation layer.SpecificationThis page (updated with each version increment)LegalTerms of Service · HRI™ is a registered methodology

Buyers can verify any score by inspecting the host's public profile fields and active signal evidence. Host owners may dispute individual signals through the dashboard. Automated bulk extraction of scores for competitive cloning or reverse-engineering is prohibited.

STATISTICAL PROPERTIES & LIMITATIONS

HRI measures public-signal quality, which correlates with but is not identical to subjective service quality. The following constraints apply.

  • Sample bias. Hosts that have claimed their listing, run a status page, and maintain public review profiles score higher. Excellent service operators with no public footprint are systematically under-rated; this is a measurement limitation, not a service judgement.
  • Granularity. Without signal augmentation, the base score moves in discrete jumps of 5+ points. The augmentation layer is the source of fine-grained resolution; hosts with no verified signals have lower differentiation around the same base value.
  • Volume vs quality coupling in Trust. The log-banded volume_term means a host with rating 4.9 and 50 reviews can score below a host with rating 4.4 and 5,000 reviews. This favours established operators by design, review volume is itself a trust signal.
  • Geographic coverage. Google Places coverage and Trustpilot adoption vary by region. Hosts headquartered in regions with low review-platform penetration carry a structural Trust handicap.
  • Temporal sensitivity. Recent claim activity moves Trust by 5 points immediately; a host that claims its listing today will see this reflected on the next score recompute. Other signals require successful extraction by the runner.
  • Not a recommendation. HRI is one data point. Buyers should additionally read third-party reviews, test with trial / money-back terms, and verify provider claims directly.

IMPROVING A SCORE (FOR HOSTS)

Every action below corresponds to a deterministic point movement, recalculated on the next score cycle.

01
Claim the listing

Sets claimed_at. Adds 5pt to Trust (verified_term) and 3pt to Completeness (contact channel). Free.

Claim Listing →
02
Complete the profile

Description, logo, founded_year, segment, location fields each contribute deterministic points to Completeness. Saturates at 25.

Reference fields above →
03
Publish a status page

A status.{domain} or /status URL with operational vocabulary contributes +1pt to Performance via the status_page_present extractor on next enrichment pass.

Read methodology →

FREQUENTLY ASKED

Can I pay to improve my HRI?

HRI is entirely algorithmic and derived from publicly verifiable inputs. Every signal that enters the score carries an evidence_url, evidence_excerpt, captured_at timestamp, and confidence score. Payment does not affect any of these fields.

How often is HRI recalculated?

Base components recalculate on every signal write via the enrichment runner. The Freshness curve is continuous-time, so even reads compute the current decay factor for each signal. A full directory recompute also runs monthly on the 1st of each calendar month.

Why is my HRI lower than I expected?

Common reasons, in order of frequency: missing profile fields (description, logo, segment, founding year), no third-party review signal (Google/Trustpilot/G2), profile updated_at older than 30 days, no public status page, no documented free SSL. Each of these is independently fixable by a host owner.

What constitutes a "good" HRI?

Score ≥ 70 earns the Top Ranked badge (top quintile of the directory). Scores in [50, 70) indicate solid performance. Scores below 40 indicate either a thin profile, stale data, or a small operator with limited public footprint, not necessarily a poor service.

Is HRI independently auditable?

We publish the methodology specification on this page so buyers understand how scores are derived. The full implementation, including signal extractors, tier mappings, weighting constants, and editorial adjustments, is proprietary to HOSTLIST.IO. Every signal that contributes to a score is publicly inspectable via the host profile (evidence_url, captured_at). Disputes are filed via the host dashboard and adjudicated against recorded evidence, not subjective ranking. Use of the methodology to reverse-engineer, clone, or create derivative ranking systems is prohibited under our Terms of Service.

Do internal HostList reviews count?

Not in the current version. The Trust component relies exclusively on third-party platforms (Google Places, Trustpilot, G2) where review provenance is independently auditable. Internal reviews are tracked separately on host profile pages and may be incorporated in a future algorithm version.

Are you deploying identical test sites on hosts?

Yes, in progress. We are manually deploying identical test website instances across the top 200 hosts by HRI rank. Benchmark data is published host by host as each deployment is validated and load-tested on the host's real plan. Profiles move from Measured or Estimated to Benchmarked as results go live. Until benchmark data exists for a host, Performance falls back to CrUX field data on the provider's public website (Measured) or an infrastructure tier estimate (Estimated).

View Rankings →Browse Directory →
Gautam Khorana
About the author

Founder, HostList.io · Co-founder, Seahawk Media · Host of the WP Legends podcast.

Data reports
Most Reliable Web Hosting Companies, Ranked by HRI
View report →
Largest Web Hosting Companies, Ranked by Public Footprint
View report →
Web Hosting Companies by Country
View report →