Website health

One report instead of five tools

Website health runs the checks you would otherwise do one at a time and puts the results on one scorecard, with the problems to fix first at the top. Click any finding to open its detail panel without leaving the report.

• DNS: nameservers, records, CAA and dangling CNAMEs that point at services you no longer use (a common takeover risk).
• Every address on its own: each A and AAAA record is tested separately, so one dead server behind round-robin DNS or a broken IPv6 address can't hide behind a healthy one.
• Redirect matrix: http and https, with and without www, should all end at one canonical URL in a single permanent redirect.
• TLS: certificate expiry, renewal risk and protocol support, plus security headers on the final page.
• Cipher suites: every suite the server accepts on each protocol from SSL 3.0 to TLS 1.3, each marked safe or unsafe with the reason (no forward secrecy, CBC, RC4, 3DES, NULL, export-grade or anonymous).
• Protocol details read from ordinary handshakes: secure renegotiation, downgrade protection, compression, ALPN, session resumption, OCSP stapling, named groups including post-quantum ones, and DH parameters. Known attacks such as POODLE, BEAST, CRIME, Sweet32 and Logjam are inferred from those settings; no attack traffic is ever sent.
• HSTS preload eligibility, the server's clock, page basics such as the title and HTML size, and domain registration expiry from RDAP.

Problems it finds that single tools miss

• IPv6 that is published but not answering: visitors on IPv6 networks see timeouts while the site works for you.
• Entry points that disagree: http://example.com redirects twice, or www serves a different certificate.
• A server clock that is minutes off, which breaks logins, tokens and certificate checks.
• A domain registration about to lapse, which takes down the website and email together.

Getting onto the HSTS preload list

Browsers ship with a list of sites that are only ever loaded over HTTPS. To qualify, redirect HTTP to HTTPS on the same host first, then send Strict-Transport-Security: max-age=31536000; includeSubDomains; preload from the HTTPS site. Only do this once every subdomain works over HTTPS, because removal from the list takes months.

Reading the fix-first list

Each finding is tagged with who it affects: visitors (errors, slow or broken pages), search (duplicate URLs, missing titles, redirect chains), security (TLS, headers, takeover risks) or operations (renewals, clocks, expiring registrations). Failures come first, then warnings, so working down the list fixes the most damaging problems first.

Dangling CNAMEs and subdomain takeover

A subdomain that still points at a cloud service you deleted, such as an old storage bucket, Heroku app or hosted page, can be claimed by anyone who creates a resource with the same name, and they then serve content on your domain. Website health follows CNAMEs to known services and flags targets that no longer exist. Delete the DNS record, or recreate the resource, to close the gap.

Questions

How is this different from the SSL checker or HTTP headers tool?

Those go deep on one thing. Website health checks every address and entry point of a site and cross-checks them, then links to the detailed tool for any finding you want to dig into.

Does it scan for vulnerabilities?

No. Every check is passive: it reads DNS, certificates, redirects and headers that any visitor receives. It doesn't probe for hidden files or attempt exploits.

Why test each IP address separately?

DNS hands out addresses in rotation and browsers fall back silently, so a broken server or IPv6 address affects only some visitors and is easy to miss from your own machine.