A Website Trust Score Should Explain Every Point

Website trust scores are persuasive because they compress a complicated question into one number.

That is also what makes them dangerous.

A score of 86 can look authoritative while hiding everything that matters: what was measured, what failed, what was unavailable, and whether the number says anything about the decision you are trying to make.

If a domain-reputation product cannot explain every point, it is not a risk signal. It is decoration.

"Can I trust this site?" is not one question

People use "domain reputation" to describe very different systems:

email-sender reputation;
malware and phishing intelligence;
IP abuse and blocklists;
SEO authority;
public reviews;
registration age and technical website posture.

A responsible tool states which problem it covers. The model I use here is narrow: it evaluates publicly observable technical evidence — registration data, DNS, TLS, HTTPS behavior and browser security headers.

It does not prove identity, ownership or benign intent. A technically polished phishing site can have a valid certificate. An old domain can be compromised. A brand-new domain can belong to a legitimate startup.

The value comes from evidence, not certainty.

Five layers make the score auditable

An explainable 100-point model can use five categories:

Registration: age, expiry, registrar, status and DNSSEC. It cannot prove ownership or intent.
DNS: reachability, nameservers and CAA. It cannot prove application security.
TLS: trust chain, hostname, expiry and protocol. It cannot prove business legitimacy.
HTTPS: secure reachability and redirects. It cannot prove an absence of vulnerabilities.
Security headers: HSTS, CSP, clickjacking and MIME controls. They cannot prove correct application logic.

This structure gives the number a reason. A low score caused by a certificate that expires tomorrow deserves different action from a low score caused by an unavailable registration source.

The response should therefore contain:

points and maximum points for each category;
pass, warning, failure or unknown status;
the evidence used;
stable finding codes;
severity and a concrete recommendation;
a provisional flag when an upstream source is missing.

The provisional state is critical. Unknown evidence is not failed evidence.

RDAP is better input than scraped WHOIS text

Developers often search for a WHOIS API when they need registration age or expiry. RDAP is the standards-based successor.

ICANN describes RDAP as the modern replacement for WHOIS. It uses HTTP and structured JSON, with query and response formats defined in IETF standards. That makes it easier to parse than free-form WHOIS output.

Structured does not mean complete. Registry policy, privacy rules and temporary outages can leave fields absent. A useful scorer must represent that absence rather than quietly filling it with a guess.

Domain age is especially easy to misuse. A seven-day-old domain may deserve additional verification in a high-value payout flow. It does not deserve an automatic "malicious" label. Age is one feature in a decision, not the decision itself.

HTTPS is not a character reference

TLS answers an important technical question: can the client authenticate the hostname presented by the server and create an encrypted connection under the public-key infrastructure?

It does not answer whether the business is honest.

Free certificates are normal. Attackers can obtain them. Legitimate organizations can forget to renew them. The useful findings are operational:

the certificate is expired or close to expiry;
the hostname does not match;
the chain is not trusted;
the site is unreachable over HTTPS;
HTTP does not upgrade to HTTPS.

Those facts can inform a review. They should not be marketed as a safety guarantee.

Security headers are controls, not badges

HSTS, Content Security Policy, clickjacking protection and X-Content-Type-Options can reduce specific browser risks. The OWASP guidance is deliberately nuanced: configuration matters.

A detected CSP may be so broad that it offers little protection. A long HSTS policy can cause availability problems if certificate management is poor. Some headers are irrelevant on responses that browsers never render.

The scoring system should recommend a tested control, not celebrate a header-shaped string.

The application needs three decisions

Do not map a score directly to "good" or "bad." Use at least three outcomes:

allow  → technical evidence meets this workflow’s policy
review → evidence is incomplete, mixed or context dependent
block  → strong technical findings cross a defined threshold

allow  → technical evidence meets this workflow’s policy
review → evidence is incomplete, mixed or context dependent
block  → strong technical findings cross a defined threshold

A provisional result belongs in review. A score in the middle belongs in review. A new domain may belong in review for vendor onboarding but remain perfectly acceptable for a low-risk link preview.

Most importantly, allow should never be renamed safe.

What I would measure after launch

The score itself is not the success metric. Track:

how often each evidence source is unavailable;
score distribution by use case;
finding codes that trigger review;
false-positive reports from legitimate domains;
changes in certificates, redirects and headers over time;
downstream outcomes after allow, review and block decisions.

That feedback tells you whether the policy is useful. Without it, a trust score is just a confident-looking input.

I published a full Node.js domain-reputation implementation guide on StadiaSoft, including error handling, score interpretation and a tri-state policy.

Developers who want a hosted endpoint can evaluate the Domain Intelligence & Website Trust Score API on RapidAPI. The Basic plan includes 50 requests per month.

The most credible score is not the one with the brightest badge. It is the one that makes it easy to disagree with it.

Disclosure: I publish the RapidAPI product referenced above. This article describes its limitations as well as its capabilities.