Every check reads publicly available information — nothing here logs in, guesses passwords, or probes for vulnerabilities. This page explains exactly what's checked, how the score is calculated, and where the real limitations are.
A scan runs nine categories of checks in parallel and combines them into a single 0–100 score. Each category has a fixed weight:
SPF, DMARC, and DKIM records — whether mail claiming to be from your domain can be forged.
Certificate validity and expiry, obsolete protocol support, whether HTTP redirects to HTTPS.
Whether common role addresses on your domain appear in known data breaches.
Security headers (HSTS, CSP, X-Frame-Options, and similar) and cookie flags.
Open ports and known vulnerabilities on the server's public IP address.
Whether files like .git/, .env, or database backups are directly downloadable from the webroot.
Whether the domain's registration is current, expiring soon, or has already lapsed.
Whether server software or CMS version is publicly disclosed, and whether a detected WordPress install is a major release behind current.
Whether the domain publishes a security contact file (RFC 9116) so researchers know how to report a vulnerability.
When a category can't be assessed (an API is down, a check times out), its weight is removed from the total and the score is rescaled across whatever did complete, so a partial scan is still comparable to a full one rather than being unfairly penalised for something outside your control.
Every check reads DNS records, the TLS certificate the server presents, HTTP response headers, and public breach records — checked by common role-based email address, not by proving domain ownership. Nothing probes for vulnerabilities, submits input, guesses credentials, or authenticates against anything. That's what makes it possible to scan any domain instantly, without needing the owner's permission first — the same boundary that separates "reading what's already public" from "testing a system," which is a meaningfully different (and more legally sensitive) activity.
A few categories involve a lookup against a third party, and it's worth being precise about what's actually sent:
Checks two constructed addresses — info@ and admin@ your domain — against Have I Been Pwned's public breach database. These are guessed role addresses, not real mailboxes we've discovered; if either happens to exist and has appeared in a breach, that's what gets flagged.
Resolves your domain to its public IP address and checks that IP against Shodan's InternetDB, a free lookup of previously observed open ports and known vulnerabilities.
Only when a WordPress install is detected, checks the version found against WordPress.org's own public update-check API (the same one WordPress uses to know when to prompt site owners to update) to see if it's a major release behind.
Looks up your domain's registration record via RDAP (the modern, structured replacement for WHOIS), using a public bootstrap lookup that finds the right registry to ask — the same kind of record any registrar or WHOIS tool would return.
Everything else — email authentication, TLS, headers, exposed sensitive files, security.txt, and software/CMS version disclosure itself — is read directly from your own DNS records and web server's response, the same way any browser or mail server reading your site already does.
Worth understanding before treating a result as complete:
Many modern sites set cookies via client-side JavaScript after page load (consent banners, analytics tools), which a single passive HTTP request can't observe.
A flagged port may have since been closed; a newly opened one may not show up yet.
A domain behind a CDN or load balancer shows that edge's open ports, not necessarily every backend server behind it.
A handful of common selector names are probed; a miss proves nothing; an uncommon selector can be correctly configured and still not show up here.
Other CMS/platforms only get checked for whether a version is disclosed at all, not whether it's current — and any site can hide the signal entirely by removing its generator meta tag.
A small number of TLDs or privacy-proxied registrations don't expose an expiration date at all — when that happens, this check is marked as unavailable rather than guessed at, and its weight is excluded from your score rather than counted against you.
It confirms a real find by checking the file's contents look right (not just that the URL returns 200), but it can't discover a sensitive file at a path outside that list.
Two more reports are available from the dashboard once a domain is added and its ownership verified (a DNS TXT record you publish yourself). Neither feeds into the 0–100 score above — they're separate, standalone reports.
Reframes the same findings the scan above already produces against the UK NCSC/IASME Cyber Essentials scheme's five technical control themes — Firewalls, Secure configuration, Security update management, User access control, and Malware protection — so each maps to exactly one theme. Malware protection always reads "can't assess externally," never clean or needs-attention: it's the one control that's genuinely about what's installed on individual devices, not anything a domain exposes publicly, so there's no honest external signal for it either way.
This is a readiness indicator, not a certification. Passing every control CBWatch can check from the outside isn't equivalent to actually holding Cyber Essentials or Cyber Essentials Plus, which require an independent assessor and on-device/internal-network testing no passive external scanner can replicate.
Checks how a domain presents itself to AI crawlers and agents specifically, separate from how it presents itself to search engines:
Accept-Signature response header defined by the emerging Web Bot Auth standard. Too new to penalise for absence; presence is noted as a positive signal.The three signals above always return a result; full detail on either report (the specific findings, not just a count) requires the domain to have completed CBWatch's ownership verification first — the same "you actually control this domain" precondition both reports reasonably assume before showing what needs fixing.
This is a point-in-time, automated, passive check — not a penetration test, not a compliance audit, and not a substitute for professional security advice. See the Terms for the full disclaimer.
Three DNS records that determine whether someone else can send email that looks like it came from your domain.
Certificate validity and expiry, obsolete protocol support, and whether HTTP redirects to HTTPS — and why each matters.
What headers like HSTS, Content-Security-Policy, and X-Frame-Options actually do, and what a site risks without them.
How breach exposure checks work — checking common role addresses like info@ and admin@ against known breaches.
What an open-ports check on your server's public IP actually shows, and the limits of this kind of scan.
Why running an outdated WordPress version matters, and how to check if your site is behind a major release.
How files like .git/, .env, and database backups end up publicly downloadable, and why it's one of the most damaging mistakes a site can make.
What happens when a domain registration lapses, why it's worse than a certificate expiring, and how to make sure it never happens by accident.
A standardised file that tells security researchers exactly how to report a vulnerability — and how CBWatch can generate one for you.