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. The one editorial input is the known-host infrastructure tier list, which sets the Performance baseline for hosts without measured data and is overridden by measured CrUX or a benchmark. No paid placements.
Status update, 26 August 2026: HRI v3.0 takes effect on 3 November 2026. HRI v2.2 remains current until then and no score moves on the day: a disclosed transition credit holds every existing listing and decays over 90 days. Full details in the changelog.
Drag the sliders to see how profile fields move a score in real time. Expand the technical specification below for every formula and signal.
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
Vintage & Freshness
Performance Tier
Tier maps to a representative URL the real lookup recognises.
Profile Completeness
Segment classification: always present, 5 pts constant until v3.0
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.
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.
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.
Editorial infrastructure tier based on known platform stack (CDN, caching layer, data-centre footprint). Replaced automatically when benchmark or CrUX data arrives.
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
Technical specificationFormulas, notation, component inputs, signal extractors, and provenance
NOTATION
The remainder of this document uses the following symbols. Each appears in at least one formula below.
FORMAL DEFINITION
For any host h in the directory:
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.
Multi-platform review signal, profile vintage, and verified ownership.
Show formula
- 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. founded_year is the company founding year where one is recorded; otherwise the domain registration year from RDAP fills it, so the term measures years since founding or domain registration.
- 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.
Disclosure of public profile data.
Show formula
- 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.
- segmentEvery active host carries a segment, so the 5-point segment term is a constant across the directory until v3.0 retires this component.
How recently the profile record was last updated, by any write including our own enrichment. Currently the weakest component, see the note below.
Show formula
- Base curveStep function on hosts.updated_at, five bands, no continuous resolution.
- Signal contributionEvery verified σ contributes 0.5 · D(σ) on top of its component-specific bonus. In practice this is clamped away for the whole leaderboard, which already sits at the 25 ceiling.
- Known limitationupdated_at is written by our own enrichment as well as by hosts, so it measures when the record was last updated, not whether anything was verified. Most active hosts, and every host in the top 200, score the full 25, which means Freshness contributes almost no separation between providers. We have started recording host-authored updates separately and will re-source this component once that data supports it. It will be announced in advance with a transition credit, the same way Completeness was for v3.0.
Independent benchmark first, then measured field data, then infrastructure tier.
Show formula
- 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, and the result is capped at 22 of 25 because it measures the provider's own site rather than customer sites; the range above the cap is reserved for benchmarked hosts. 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.
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.
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.
- 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.
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.
- Review manipulation. Google and Trustpilot rating and review volumes are taken as published by those platforms and are not screened for inorganic growth. A host that buys or solicits reviews in bulk moves Trust by the same volume bands as one that earned them; detection rests on the platforms.
- 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.
- Informational only. Scores and rankings are expressions of opinion based on public signals and may lag real-world changes. See the ratings disclaimer and Terms. Hosts disputing listing data: email [email protected].
IMPROVING A SCORE (FOR HOSTS)
Every action below corresponds to a deterministic point movement, recalculated on the next score cycle.
Sets claimed_at. Adds 5pt to Trust (verified_term) and 3pt to Completeness (contact channel). Free.
Claim Listing →Description, logo, founded_year, segment, location fields each contribute deterministic points to Completeness. Saturates at 25.
Reference fields above →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
What happens when several hosts have the same HRI?
HRI is a whole number out of 100, so ties are normal: on 5 September 2026 six hosts held 97. Tied hosts are ordered by a fixed, published chain, never by database order or by when a profile was last saved. Key 1 is the published score. Key 2 is the number of verified disclosures on the profile: the Completeness facts a buyer can check against evidence, which is the work the host did on its own listing. Key 3 is approved reviews left on HostList itself. Key 4 is third-party review volume: the combined Google, Trustpilot and G2 count, grouped into half-decade buckets (under 10, 10 to 31, 32 to 99, 100 to 315, 316 to 999, 1,000 to 3,161, 3,162 to 9,999, 10,000 and up), so hosts in the same bucket are treated as equal evidence. Key 5 is the Trust component. Key 6 is alphabetical order, so the sequence is total and reproducible. Worked example from the September 2026 table: HostPapa, hosting.de, DreamHost, SiteGround, Kinsta and cdmon all scored 97. HostPapa has 28 verified disclosures, hosting.de 24, DreamHost 22, so they take the first three places in that order. SiteGround and Kinsta both have 5, neither has HostList reviews yet, so third-party volume separates them: SiteGround sits in the 10,000+ bucket with about 32,400 reviews, Kinsta in 1,000 to 3,161. cdmon, with 2 disclosures, is last of the six. The chain only ever reorders hosts that already share a score. It cannot lift a 96 above a 97, however many reviews or disclosures the 96 has.
Twenty hosts share my score. What actually moves me up?
In order of leverage. First, get out of the tie: every pillar has headroom somewhere, and the profile dashboard shows which Completeness facts are undisclosed and whether Performance is estimated or measured. One extra point beats any tiebreak. Second, disclose: each verified fact you add moves you ahead of every tied host with fewer, and it is the same work that raises Completeness in v3.0. Third, HostList reviews: an approved review from a customer on your profile counts before any third-party number does, and the dashboard has review invitations built in. Fourth, third-party volume: the tiebreak reads the combined Google, Trustpilot and G2 count, so if your Google Business Profile is missing from the listing or your Trustpilot domain is not the one on your profile, that evidence is not being counted. Fix the linkage before asking customers for reviews. Volume is bucketed, so going from 2,000 to 2,400 reviews changes nothing; crossing 3,162 does. Fifth, Trust, which is mostly rating quality, founding year and a claimed profile. Name order is last and is the only key you cannot change. One thing that does not help: ratings above what you already have once Trust is at 25.
Why does the host in first place have fewer reviews than the host in second?
Because they do not share a score. Every tiebreak, disclosure and reviews included, only applies between hosts with the same published HRI. A host at 98 with 200 reviews ranks above a host at 97 with 30,000 reviews, because the 98 reflects a point earned elsewhere (a measured benchmark, a disclosed fact, a fresher profile) that the second host has not earned. Trust is capped at 25, and both hosts may already be at the cap, so the difference between them was never going to be reputation. It is the other three pillars. If that feels wrong, the answer is in the pillar weights, which are published above and revisited in each numbered version, not in the tiebreak.
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 recompute when a host's inputs change: through the enrichment runner, the claim flows, or an edit in the host dashboard. A full directory recompute runs on the 1st of each month via a scheduled job. Scores are read from the stored result, not computed at page load.
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 (the top few percent of the directory). Scores in [50, 70) indicate solid performance. The lowest total in the directory today is 41, not 0: the constant terms (a neutral Performance baseline, a Freshness floor, an always-present segment) put every host in the 40s before any evidence is counted, so a score in the low 40s indicates 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).
Founder, HostList.io · 10,000+ websites launched · Host of the WP Legends podcast · gautamkhorana.com
