Methodology Changelog
Every change to the HostList Ranking Index is versioned, dated, and published here before it takes effect. Registry changes are announced to claimed hosts by email at least 14 days ahead, subtractive changes carry a disclosed transition credit, and no score ever moves silently. Nothing on this page, and nothing in the index, can be bought: sponsorship, partnership, and advertising move no component by any amount. The protocol itself is versioned in the repository as HRI-VERSIONING.
Crawler-verified signals were decaying because we stopped re-checking them
Verified signals (a public status page, documented free SSL, a public pricing page) earn small fractional bonuses that decay to zero over their horizon, 180 days for the status page, unless the signal is captured again. Decay is the right treatment for a claim a host attests from its dashboard, because nobody re-checks it. It was the wrong treatment for a signal our own crawler can verify in seconds, and the crawler had not been scheduled since July. The result: a host with a healthy status page lost half its bonus by day 90 for no reason other than our silence, and at the top of the table that half point was the difference between 97 and 98.
There was a second gap underneath. Re-probing a page whose text had not changed produced identical evidence, which the runner treated as "already on file" and skipped, so even a scheduled re-check would not have reset the clock for a status page that simply kept saying all systems operational. From today, an unchanged page is a re-confirmation: the existing row's capture date moves, its value and evidence do not, and the audit trail is intact. A weekly job now re-probes the top 300 hosts by HRI before the daily snapshot. Dashboard attestations keep decaying exactly as before. Hosts whose signal was re-confirmed today may see a one-point Performance move as the bonus returns to full value; no formula changed.
Score ties: disclosure first, then HostList reviews, then review volume
Not an algorithm change, disclosed anyway: two review keys join the tie chain behind verified disclosure. When hosts hold the same HRI, the order is now verified disclosure count (unchanged since July, and still first: it is the work a host did on its own profile), then approved HostList reviews, then third-party review volume, then Trust, then alphabetical order. No score moved and the published integer is always the first key, so more reviews can never lift a 96 above a 97.
Why the two new keys: the Trust component is capped at 25 while its raw range reaches 34, so at the top of the table a host with 60 reviews and a host with 30,000 both show 25/25. Before today, hosts that also tied on disclosure fell through to Trust (identical at the cap) and then to the alphabet. HostList reviews count first because a host that asks its own customers to review it here is doing the same kind of work as disclosing facts. Third-party volume is the combined Google, Trustpilot and G2 count in half-decade buckets (10, 32, 100, 316, 1,000, 3,162, 10,000 and so on), so 2,000 reviews does not beat 2,500, but 60 does not beat 30,000 either.
Earlier on 5 September a version of this change put review volume ahead of disclosure for a few hours. That order was wrong for an index about to make disclosure its centre in v3.0, and it was reverted the same day before the daily snapshot was kept. The daily rank snapshot that feeds Standings, the Server Room and the movement chips uses this comparator, so every surface reads the same order. Full worked example in themethodology FAQ.
HRI v3.0 takes effect on 3 November 2026
The replacement date promised on 15 August is 3 November 2026. Claimed hosts receive the notice required by the protocol, with their own before and after numbers, at least 14 days before that date. Until then HRI v2.2 remains current and nothing about any score changes.
Nobody drops on the day. On 3 November 2026 every listing scored before that date receives a transition credit equal to the gap between its old Completeness and its verified-fact Completeness, so its total is unchanged. The credit then decays in a straight line to zero on 1 February 2027. Every fact verified before that turns expiring credit into permanent points.
Why the credit window moved with the date. The window runs 90 days from the effective date, so rescheduling the cutover reschedules the expiry. The July notice quoted 11 November 2026 because that was 90 days after the date announced then. The end-state figure each host was quoted has not changed: it is calculated from verified facts, not from the calendar.
The HRI v3.0 cutover is postponed
The v3.0 cutover announced for 13 August 2026 did not ship. HRI v2.2 remains the current methodology, every live score still follows v2.2, and no v3.0 placement change has been applied.
A replacement date will be published here before scores move. The transition credit will begin on that rescheduled date and run for 90 days; it has not started decaying.
Resolved. The replacement date is 3 November 2026, announced in the entry at the top of this page.
Certifications and data-centre model join the registry, unscored
Two more facts join the registry below, both worth zero points, on the same rule as the 29 July additions: a field worth nothing changes neither side of the Completeness fraction, so no score moves and no notice is owed. They appear on host profiles and in the dashboard checklist from today and are priced at a later version boundary, announced here 14 days ahead in the usual way.
Compliance certifications. ISO 27001, SOC 2, PCI DSS and similar. Evidence is the certificate, the audit letter, or an entry in the certifier's public registry; a marketing page that names the standard is not evidence.
Data centre ownership model. Own facilities, colocation, hyperscaler, or a mix, plus the operator names. Buyers read "own data centres" claims sceptically, and the real model is the fact that earns trust. Disclosing colocation can never rank worse than disclosing nothing: content never feeds points, only the count of verified disclosures does.
The security field gains optional DDoS protection and control-panel two-factor inputs. Existing verified answers stay valid and no points change. Both additions were prompted by owner feedback after the claim pushes: certifications and data-centre reality were only visible as marketing copy, never as checkable facts.
An affiliate link has been earning 2 points, and our own policy page said it could not
Until today the affiliate disclosure on this site ended with the sentence "Partner or referral relationships never change HRI, sort order, or ranked list position." That was not true, and it appeared on 17 pages. The v2.2 Completeness component counts a recorded affiliate link as a filled profile field, worth 2 of 100 points. Fourteen listings hold it today (corrected 1 September 2026; this entry originally said thirteen).
Nobody buys those 2 points and no money changes hands for them. It is a fifteen-year-old habit of profile scoring, counting a field because the field is filled, and it long predates anyone thinking about what it implied. That does not matter much: a score is a score, and the sentence claimed a firewall that had a hole in it. The sentence is corrected and the exception is now stated plainly wherever the disclosure appears.
Why the points are still there today. Removing them now would move 12 of the 13 affected listings, which is a subtractive change and owes 14 days notice plus a transition credit under the protocol. HRI v3.0 retires it when the postponed cutover ships by scoring Completeness only from verified disclosures. Shipping a second subtractive change before that cutover would stack two credits and make both unreadable, so the exception remains disclosed until the dated change does the work.
One thing v3.0 does not fix. The MSP Ranking Index keeps the v2.2 profile sum, so the same 2 points survive there after the rescheduled v3.0 cutover. No MSP listing currently holds an affiliate link, so nothing is affected today, but the code path is real and it is recorded here rather than left to be discovered. It is removed at the next MRI version boundary, announced here in the usual way.
Two new questions, shown before they are scored
Two facts join the registry below: a security contact and plan resource limits. Both ship worth zero points. They appear on host profiles and in the dashboard checklist from today, and they score at a later version boundary, announced here 14 days ahead in the usual way.
No score moves today. Completeness divides verified points by applicable points, so a fact worth zero changes neither side of that fraction. The per-segment totals printed under the table are the same numbers as yesterday. This is deliberate: v3.0 carries a transition credit through 1 February 2027, and pricing new fields on top of it would stack two adjustments and make both unreadable. Hosts get the months in between to answer at no cost.
Security contact. An RFC 9116 file at /.well-known/security.txt naming who to tell about a vulnerability. Detected automatically, so it costs a host nothing to disclose, and only that exact path counts: a security contact reachable only by searching the site is not reachable. We honour the expiry date the file declares, so the entry stops counting as current the day the host said it would rather than whenever our own re-check falls due, and a file that has lapsed or gone missing is shown on the profile as lapsed rather than reverting to a blank. Of the 35 highest-scoring independent hosts in the directory, 13 publish a valid one today. The other 22 are the point: the blank is the finding.
Plan resource limits. The inode, CPU, entry process, memory and IO caps a plan actually enforces, what happens when a customer reaches one, and the page where those numbers are published. Nothing in the registry recorded a single comparable capacity number before this, so two plans identical on price could differ several-fold on the limit that decides whether a busy site stays up. Enforcing no hard limits is a complete answer and is recorded as one. A limits page carrying no numbers earns nothing, the same rule the backup field already applies to a restore cost of "contact us".
Neither field can be bought, bundled, or waived, and neither is available to sponsors on any terms. That is the same sentence as every other entry on this page because it is the same rule.
Completeness becomes the Disclosure Engine
The Completeness component (25 of 100 points) is rebuilt. Until now it measured whether a profile was filled in: description, logo, segment, founding year, links. Most claimed hosts reached 25/25 quickly and the component stopped discriminating. When the rescheduled cutover ships, it measures willingness to disclose: verified answers to the questions buyers actually ask, most of which no host in this market publishes in structured form.
Every fact is machine-verified or human-reviewed with evidence before it earns a single point. Self-reported claims earn zero until verified. Every point decays: a fact that is not re-verified or re-attested inside its window stops earning. A declared fact our checks contradict is marked disputed publicly, showing both the declaration and what we observed. Facts a host has not disclosed render as "Not disclosed" on its profile, because the blank is a finding.
Scoring: each host segment has an applicable subset of the registry below. Completeness equals 25 times verified points earned over applicable points, capped at 25. Trust, Freshness, and Performance are untouched by this release. The MSP Ranking Index (MRI) is untouched. The signal-augmentation micro-bonuses that previously fed Completeness retire into the fact registry so nothing earns twice; signal bonuses to other components are unchanged.
The transition credit. Rescoring a directory of 30,000 hosts overnight without warning would be self-harm dressed as rigor. Instead, every host scored before the cutover keeps its number on day one through a transition credit equal to the gap between its previous Completeness and its verified-fact Completeness. The credit decays linearly to zero over 90 days, reaching zero on 1 February 2027. It will never be hidden: from 3 November 2026 it will be shown on the host profile and exposed in the API as transition_credit with its expiry; it is excluded from Most Improved rankings and unavailable to any host claimed after the cutover date. A reader can subtract it. Hiding it would be dishonest; showing it is the point.
Completeness measures how much a host discloses, not how good it is. That distinction is printed next to the component everywhere it appears.
| Fact | Points | Verification | Re-verify window | Applies to |
|---|---|---|---|---|
| Commercial transparency | ||||
| Entry plan pricing | 3 | NUMBER_RANGE + URL_200_SAME_DOMAIN | 180 days | All segments |
| Refund window | 3 | NUMBER_RANGE + URL_200_SAME_DOMAIN | 365 days | All segments |
| Migration policy | 3 | ENUM + URL_200_SAME_DOMAIN | 365 days | PURE_HOST, AGENCY_HOSTING |
| Active verified coupon | 2 | CHECKOUT_VERIFIED | 90 days | All segments |
| Reliability | ||||
| Public status page | 3 | URL_200_SAME_DOMAIN + URL_200_ALLOWLIST | 30 days | All segments |
| Machine-readable incident feed | 2 | AUTO_DETECT | 30 days | All segments |
| Uptime SLA with credit terms | 2 | NUMBER_RANGE + URL_200_SAME_DOMAIN | 365 days | PURE_HOST, HOSTING_TECH |
| Ownership and jurisdiction | ||||
| Parent company or independence | 3 | EVIDENCE_REVIEW | 365 days | All segments |
| Registered legal entity | 2 | EVIDENCE_REVIEW | 365 days | All segments |
| Data residency options | 2 | STRING_LIST | 365 days | All segments |
| GDPR data processing agreement | 1 | URL_200_SAME_DOMAIN | 365 days | All segments |
| Infrastructure | ||||
| Datacenter regions | 2 | STRING_LIST | 365 days | All segments |
| Server stack profile | 2 | STRING_LIST + AUTO_DETECT | 365 days | PURE_HOST, AGENCY_HOSTING |
| Storage type | 1 | ENUM | 365 days | PURE_HOST, HOSTING_TECH |
| Included security features | 1 | STRING_LIST | 365 days | PURE_HOST, AGENCY_HOSTING |
| Security contact (security.txt) | not yet scored | AUTO_DETECT | 90 days | All segments |
| Compliance certifications | not yet scored | STRING_LIST + EVIDENCE_REVIEW | 365 days | PURE_HOST, AGENCY_HOSTING, HOSTING_TECH |
| Data centre ownership model | not yet scored | ENUM | 365 days | PURE_HOST, AGENCY_HOSTING, HOSTING_TECH |
| Backups and support | ||||
| Backup and restore policy | 2 | ENUM + NUMBER_RANGE | 365 days | PURE_HOST, AGENCY_HOSTING |
| Support channels and hours | 2 | STRING_LIST + ENUM | 365 days | All segments |
| Support languages | 1 | STRING_LIST | 365 days | All segments |
| Product data | ||||
| Published plan data | 2 | NUMBER_RANGE + URL_200_SAME_DOMAIN | 180 days | PURE_HOST, AGENCY_HOSTING, HOSTING_TECH |
| Plan resource limits | not yet scored | ENUM + NUMBER_RANGE + URL_200_SAME_DOMAIN | 180 days | PURE_HOST, AGENCY_HOSTING |
| Sustainability | ||||
| Renewable energy evidence | 1 | EVIDENCE_REVIEW | 365 days | All segments |
| Presence | ||||
| Profile description | 1 | EVIDENCE_REVIEW | 365 days | All segments |
| Logo | 0.5 | URL_200_ANY | 365 days | All segments |
| Founded year | 0.5 | NUMBER_RANGE | 365 days | All segments |
| Social profiles | 0.5 | URL_200_ALLOWLIST | 365 days | All segments |
| YouTube channel | 0.5 | URL_200_ALLOWLIST | 365 days | All segments |
| Changelog or engineering blog feed | 0.5 | URL_200_SAME_DOMAIN | 180 days | All segments |
Applicable totals per segment: PURE_HOST 43.5, AGENCY_HOSTING 40.5, HOSTING_TECH 35.5, OTHER 30.5 raw points. A field outside a segment neither earns nor counts against that segment's denominator.
Score ties resolve by verified disclosure
Not an algorithm change, disclosed anyway: when two hosts hold the same HRI, ranking surfaces previously ordered them arbitrarily, so equal hosts could swap places between page builds. Ties now resolve deterministically: the host with more verified disclosures ranks first, then the stronger Trust component, then alphabetical order. No score moved; equal scores became reproducible, and the first tiebreak rewards the same thing the index does, publicly checkable facts.
Hosting leaderboards filtered to pure hosts
Not an algorithm change, disclosed anyway: the Top 50 and Top 100 ranking pages now list PURE_HOST companies only. Agencies, managed service providers, and mis-catalogued listings no longer compete in a web hosting leaderboard. No score changed; the eligible population did.
Trustpilot substitutes when Google review data is absent
Google Places coverage spans roughly 1.5 percent of the directory. A host with thousands of Trustpilot reviews previously scored as if it had no review signal at all when Google data was missing. Under v2.2, Trustpilot substitutes at a discounted ceiling (rating up to 6 of 8 points, volume up to 4 of 7) only when Google is absent. Google remains dominant whenever it exists, and poor secondary-platform ratings still never subtract.
Correction, 1 September 2026. The 1.5 percent figure above was wrong when it was written. Google Places data covers 57.8 percent of active hosts as of today. The substitution rule and its ceilings are unchanged; the number described the size of the gap the rule closes, and that gap is the other 42 percent, not 98.
Secondary review platforms corroborate Trust
Trustpilot (up to 2 points) and G2 (up to 2 points) come online as corroboration bonuses inside the Trust component, with volume thresholds tuned per platform. Deliberately asymmetric: good ratings on secondary platforms add small bonuses, bad ones do not subtract, so a drive-by complaint on one platform cannot outvote thousands of corroborated reviews.
Signal augmentation layer
A layer of verifiable, evidence-backed micro-signals (support response time, renewal price delta, documented free SSL, IPv6 and HTTP/3 support, status page presence) begins adding fractional, continuously time-decaying bonuses on top of the four base components. Every signal carries an evidence URL and a capture date. Each component stays capped at 25.
The original four-component index
HostList Ranking Index: four equally weighted components, Trust, Completeness, Freshness, Performance, each 0 to 25, summing to a 0 to 100 score computed identically for every active host in the directory. The two commitments that have never changed: fully algorithmic, and no paid placement of any kind.