34 checks · 14 categories
Everything we look at, and why it matters.
All of it observed from the public internet, the same way an attacker or a search engine sees you. Every check below runs on the free report.
Domain and registration2 checks
Registration and expiry
We read your registration record: the expiry date, the registrar, whether a transfer lock is on, and which nameservers are authoritative.
An expired domain takes your website and your email down at the same moment, and recovery can take days. Without a transfer lock, anyone who gets into your registrar account can move the domain away.
Lookalike domains
We generate the variants most likely to be used against you, including dropped and doubled letters, 0 for o, rn for m, and your exact name on other extensions, then check which are registered and which can receive email.
A lookalike that can receive email is the standard setup for invoice fraud and for phishing your customers. You would otherwise have no way of knowing one had been registered.
DNS4 checks
DNS records
We read the records that decide where your traffic goes: A and AAAA for the website, MX for mail, NS for delegation, and CAA for who may issue your certificates.
These decide where your visitors and your email actually go. An unexpected change here is exactly what a hijack looks like, so we alert on the value changing, not just on it breaking.
Subdomain takeover
We look for subdomains still pointing at cloud services, hosts or apps that no longer exist.
Anyone can claim the abandoned service and publish their own content on your subdomain, with your name and often your certificate. A favourite trick for convincing phishing pages.
DNSSEC validation
We check whether your DNS answers are cryptographically signed, and whether the chain of trust actually validates.
Without it, someone positioned on the network can answer DNS on your behalf and send your visitors somewhere else entirely, with nothing on your site to give it away.
Zone transfer and open resolver
We ask your nameservers for your entire DNS zone, and test whether they will answer lookups for unrelated domains.
A zone transfer gives an attacker a complete map of your infrastructure in one request. An open resolver gets your server conscripted into attacks on other people, and blocklisted for it.
TLS certificate1 check
TLS certificate
We check your certificate the way a browser would: days left before it expires, whether it is trusted, whether it actually covers your domain name and your www address, whether the full chain is served, key strength, and whether your server still accepts the obsolete TLS versions that modern browsers hide from you.
An expired or mismatched certificate shows every single visitor a full-page browser warning before they reach you. A missing chain is worse, because it looks fine in Chrome while failing on Android, at payment gateways and for anything using an API. Certificate lifetimes are shortening, so the window for noticing by hand keeps narrowing.
Certificate transparency1 check
Certificate transparency
We search the public certificate logs for every certificate ever issued for your domain, list the subdomains they name, pick out the ones that look like staging sites, admin panels or remote access, and record which certificate authorities have issued for you.
A certificate you did not order means someone else has proved control of a name that belongs to you. The same logs are the first place an attacker looks, because a staging site or an admin panel is usually less hardened than the live site and often shares its database. Most owners recognise the first few names on the list and not the rest.
Web security8 checks
HTTPS redirect
We request your site over plain http and check that it forwards to https.
Without it, a visitor’s very first request travels unencrypted, which is the easiest moment to intercept them.
Security headers
We inspect your response headers for HSTS, Content-Security-Policy, frame protection, MIME-sniffing protection, referrer policy and permissions policy.
These are the instructions that tell a browser how to defend your visitors. Missing them is what makes clickjacking and injected-script attacks possible in the first place.
Subresource integrity
We check whether the third-party scripts you load are pinned to a known fingerprint.
Without pinning, if the company hosting that script is compromised, whatever they serve next runs on your site with full access to your pages.
Cross-origin policy
We test whether your site tells browsers that any other website may read responses from it, including authenticated ones.
An over-permissive policy lets a site you have never heard of read your logged-in users’ data straight out of your own responses.
Open redirect
We test whether your URLs can be crafted to bounce a visitor onward to any other website.
It lets an attacker send phishing links that genuinely begin with your domain name, which is exactly what makes people click.
Mixed content and insecure forms
We look for insecure resources loaded into a secure page, forms that submit without encryption, and cookies missing the Secure and HttpOnly flags.
A form that posts unencrypted exposes everything typed into it. Mixed content quietly breaks the padlock your visitors are told to look for.
Redirect chain
We follow the whole redirect chain, counting the hops before a visitor arrives and flagging any that drop out of https.
Every hop adds delay before anything renders, and a single insecure hop in the middle undoes the encryption on the whole journey.
Cookie consentUK PECR / EU GDPR cookie consent
We load your homepage as a first-time visitor, read what it tries to store before anyone has agreed, and look for a consent tool.
Setting tracking cookies before consent is the most commonly enforced cookie breach, and it is visible to a regulator from outside without any need to investigate you.
Software and versions1 check
Software versions
We identify what your site is built on, read the versions it announces in headers, meta tags and asset URLs, and check them against known-vulnerable and end-of-life releases. On WordPress we also inventory the plugins and theme, with their versions, and compare your core version against the current release.
A version banner tells an attacker precisely which exploit to try, turning a broad scan into a targeted one. Outdated plugins, rather than WordPress itself, are how most WordPress sites are broken into, and their version numbers are published in your page source for anyone to check against a list.
Email authentication4 checks
Email authenticationGoogle, Yahoo and Microsoft bulk sender rules
We look up the three records that let the world prove mail claiming to come from you really did: SPF, DKIM and DMARC.
Without them anyone can send email as your domain, and your own genuine email is far likelier to land in spam. The large mailbox providers now require them for bulk senders.
Spoofability
We combine your SPF strictness, your DMARC policy and your DKIM signing into a single verdict.
It answers the question an owner actually has: can a criminal email my customers, or my finance team, as me? Invoice fraud starts here.
Mail server health
We resolve the servers your MX records name, open a connection to each, and check that their reverse DNS matches.
An MX record pointing at a server that no longer exists loses inbound mail silently. Mismatched reverse DNS quietly pushes your outbound mail towards spam folders.
Mail transport security
We check for MTA-STS, TLS reporting and BIMI, and measure the strength of your DKIM signing key.
Without MTA-STS, mail on its way to you can be downgraded to an unencrypted connection and read in transit, and neither side will be told it happened.
Content and SEO3 checks
Crawlability
We fetch robots.txt and your sitemap, then look for accidental noindex tags and for whether AI training crawlers are addressed either way.
A single stray noindex left behind after a redesign can remove you from Google entirely, and nothing on the page looks wrong when it happens.
Link previews
We read the Open Graph, Twitter card and structured-data tags that decide how your links look when shared.
Without them, every link to you shared in a message, a post or an email arrives as a bare URL with no image or description, and gets clicked far less.
Canonical and mobile basics
We check your canonical tags, your mobile viewport declaration, and links that lead nowhere.
Duplicate-content signals split your ranking between URLs, and a missing viewport makes the page unusable on the device most of your visitors are holding.
Performance1 check
Speed and page weight
We measure the time to your first byte, the weight of your homepage document, and how long a full load takes.
Slow first-byte time loses visitors before anything appears, and it is one of the few technical factors search engines act on directly.
Reputation3 checks
Website host blocklists
We query the major blocklists for the addresses your website is served from.
Security tools and mail filters check these lists, so a listing quietly flags your site to visitors and to anyone your server emails. On shared hosting it is often another site on the same address that caused it.
Sending address blocklists
We work out which addresses actually send your email, from your SPF record and your mail servers, and check those against the major blocklists.
This is the one that decides whether your email arrives. A listed sending address means invoices and quotes are being rejected or filed as spam, usually with no bounce message you would ever see.
Domain blocklists
We check your domain name itself against the blocklists that track domains used in spam and phishing.
While your domain is listed, any email that so much as mentions your web address can be blocked, including messages sent by your customers and suppliers rather than by you.
Payment security1 check
Payment page scriptsPCI DSS 4.0 (6.4.3 and 11.6.1)
We follow your own basket, checkout or donate links, inventory every third-party script running there, record them by name so a change is visible, check whether each one loads with an integrity hash, and work out whether card details are typed into your page or into your processor’s.
PCI DSS 4.0 requires you to know exactly which scripts run on a payment page and to notice when one changes. A swapped script is how card details get skimmed without anything looking different. Where the card fields live also decides which self-assessment you have to complete: fields on your own page mean roughly 200 questions and quarterly scanning instead of about 20, and most merchants do not know which side of that line they are on.
Accessibility1 check
Accessibility basicsWCAG 2.2 / European Accessibility Act / ADA
We run 11 automated WCAG checks: heading structure, image alternative text, form labels, whether links and buttons have names a screen reader can read, embedded frame titles, tab order, autoplaying sound, zoom, page title and page language. These catch roughly a third of real issues.
Accessibility complaints are a live and growing litigation risk, and these are the failures most often cited. We report and track them; we deliberately do not sell an overlay, because overlays have become a liability of their own.
Exposed secrets1 check
Exposed secrets
We search the code your site sends to browsers, and any source maps published alongside it, for 21 kinds of credential: cloud keys, payment and email provider tokens, database connection strings and private keys. We also decode any API tokens we find to check none of them carry admin privileges. Anything found is masked in the report.
A live key in public JavaScript can be used by anyone who views the page source. These usually arrive by accident during a rush and then sit there for years, and the damage runs from a surprise cloud bill to somebody reading your whole customer database.
Public exposure3 checks
Public sensitive files
We request 21 paths that should never be reachable: environment and config files, version-control directories, database dumps, editor and deploy credentials, server status pages and debug logs. We also check whether any common folders list their own contents.
A public .env file typically hands over database passwords and API keys in one request, and a folder that lists its contents is how old backups and customer documents get found without anyone linking to them. This is among the most common ways small sites are breached.
Exposed API surfaces
We test for GraphQL introspection left enabled, published Swagger or OpenAPI documentation, and database administration tools reachable from the internet.
Each one hands an attacker a complete map of your API, or in the case of an admin tool, a login page to your database.
Open cloud storage
We check whether the storage buckets your site references allow public listing or public reads.
An open bucket is one of the single most common sources of leaked customer data, and it is usually discovered by someone other than the owner.
See all 34 run against your domain.
Free, no signup, about a minute.