--- title: Is my website healthy? How to check it with the Smart Website Checker description: Someone asks whether the website is OK, or you inherit one and need to know what will break first. To check website health, look past "does the page load" at the things that fail on a date or fail silently: domain and certificate expiry, DNS, redirects, email authentication and blacklists. Here's how to get all of it in one scan with the free Smart Website Checker, and how to read a result that says A+ and still lists work to do. canonical: https://watchfor.io/blog/how-to-check-website-health --- # Is my website healthy? How to check it with the Smart Website Checker 2026-10-04 · WatchFor Team · Guides · guides, http, security Someone asks whether the website is OK, or you inherit one and need to know what will break first. To check website health, look past "does the page load" at the things that fail on a date or fail silently: domain and certificate expiry, DNS, redirects, email authentication and blacklists. Here's how to get all of it in one scan with the free Smart Website Checker, and how to read a result that says A+ and still lists work to do. To check a website's health, test more than whether the page loads. A site can answer 200 today and still be days away from an expired domain or certificate, have a redirect chain that splits its address in two, or let anyone send email in its name. A useful health check covers the domain, the certificate, DNS, HTTPS and redirects, response headers, email authentication and blacklists, and tells you which of those need work. The free [Smart Website Checker](/smart-website-audit) runs all of those checks in one scan from WatchFor probe locations and returns a letter grade with the reasons and the dates next to it. No signup. ## What this tool answers *Is anything about this website broken, about to break, or quietly unsafe?* Reach for it when a client or your manager asks "is our site OK?", when you take over a site from another team or agency, before a launch, or after a migration. It replaces a dozen separate lookups (whois, an SSL check, `dig`, a header check, an SPF/DMARC check, a blacklist lookup) with one report, and it explains each finding in plain words. ## A real example ### Checking website health on a site you didn't build The situation we wanted to reproduce: you are handed a domain and asked for a health report by the end of the day. You don't know who registered it, which certificate authority it uses or whether anyone set up email authentication. We ran the [Smart Website Checker](/smart-website-audit) on `wikipedia.org` from its default location (Vilnius) and got the report in 4.7 seconds: ![The Smart Website Checker report for wikipedia.org: grade A+ at 100 out of 100, 12 sections healthy and 1 section to review, scanned in 4.7 seconds. Worth improving: no DKIM record at the common selectors. Dates worth keeping: the domain registration runs out in 101 days and the TLS certificate has 30 days left](/blog/how-to-check-website-health-verdict.webp) The headline: **A+, 100 out of 100, nothing deducted**. That answers "is it broken?" with a clear no. But a health report is more than its letter, and the panels under it carry the parts you'd put in front of a client: - **Worth improving.** No DKIM record at any of the common selectors. - **Dates worth keeping.** The domain expires in 101 days; the TLS certificate has 30 days left, issued by Let's Encrypt. - **What to do next.** Add `X-Frame-Options`, `X-Content-Type-Options`, `Referrer-Policy` and `Permissions-Policy`, and start a Content Security Policy in report-only mode. Below the summary, every section has its own line, which you can expand for the details: ![The thirteen sections of the wikipedia.org report: Domain expires in 101 days at MarkMonitor, HTTPS 200 OK in 463 ms, Performance TTFB 463 ms, HTTP Headers 1 of 6 security headers, SSL Certificate 30 days remaining from Let's Encrypt over TLS 1.3, DNS Records A, AAAA, 3 NS, 2 MX and CAA, CDN no fingerprint, Protocols HTTP/1.1 and HTTP/2, Email Policy SPF and DMARC with a DKIM warning, Reputation clean on 4 blacklists, one canonical address with HTTPS enforced, IPv6 not tested from this location, and Reachability from all 3 locations at 463 to 1400 ms](/blog/how-to-check-website-health-sections.webp) We then checked each item before writing it into a report. The command-line section shows the commands: the certificate's `notAfter` is 3 November 2026, RDAP lists the registration's expiry as 13 January 2027, and DMARC is `p=reject`. **The answer:** the site is healthy, with two things to act on. The certificate is at the 30-day mark, which is when a 90-day Let's Encrypt certificate is normally renewed, so it deserves a check in the next few days rather than a panic. The missing security headers cost no points because HSTS is present, but they are cheap to add. DKIM is a "go and look" item, not a failure. The checker tries common selector names, and a domain that signs mail with its own selector looks unsigned to it. ## How to read the results | Part of the report | What it tells you | | --- | --- | | **Letter and score** | Starts at 100; a warning in a section costs half that section's weight, a critical finding all of it. Any critical finding caps the grade at C; an expired certificate, a lapsed domain or a site that doesn't answer is an F. The full rubric is in [how the audit grade works](/docs/reference/audit-grade). | | **Sections healthy / to review** | Counted from the findings, so one warning inside an otherwise green section shows up here. | | **Worth improving / Fix first** | The findings that need action, most serious first. | | **What to do next** | The concrete change for each finding, often the exact header or record to add. | | **Dates worth keeping** | Domain and certificate expiry in days. Put both in a calendar. | | **Green dot** | That part works. | | **Blue dot** | Informational: noted, not a fault. Security headers and email policy are always blue here because a missing header doesn't stop the page rendering; the grade still weighs them. | | **Amber / red dot** | A warning or a critical finding in that section. | | **Reachability** | The page requested from up to three locations in different regions (here Vilnius, Cape Town and Tokyo, 463 to 1,400 ms to first byte). Reported, never scored. | ## More ways to use it - **Agency onboarding.** Run it on every client site in the first week and keep the report; the dates panel is your renewal list. - **Before a launch.** Catch a missing `www` redirect, an HTTP page that doesn't redirect to HTTPS, or a domain that expires next month. - **After a migration.** New hosting or a new CDN often drops headers, breaks the `http://` redirect or changes DNS in ways nobody noticed. - **Email deliverability triage.** The Email Policy and Reputation sections are a quick first pass before you dig into SPF, DKIM and DMARC one by one. - **Vendor due diligence.** See how a supplier's public site is run before you trust them with data. ## Tips and gotchas - **The grade doesn't count DKIM, on purpose.** Selectors are chosen per domain. If the report says "no DKIM", look up the selector in your mail provider's settings and check that name with the [DKIM record checker](/dkim-record-checker). - **A green grade isn't a calendar.** An A+ site can still lapse in 101 days if the card on the registrar account expires. Read the dates panel. - **One run, one moment.** Response times and reachability vary between runs. The probe location is chosen nearest to you; a different region can see a different edge. - **It checks the address you type.** `example.com` and `www.example.com` can behave differently; the Addresses & Redirects section shows how they relate. - **It reads public information only.** Nothing logs in, crawls or tests for vulnerabilities. Run it on sites you own or are allowed to assess. ## Check it from the command line too Each section maps to a standard command. These are the ones we used to confirm the report: ```bash echo | openssl s_client -connect wikipedia.org:443 -servername wikipedia.org 2>/dev/null \ | openssl x509 -noout -issuer -enddate curl -sL https://rdap.org/domain/wikipedia.org | jq -r '.events[] | "\(.eventAction) \(.eventDate)"' dig +short TXT _dmarc.wikipedia.org curl -sI https://www.wikipedia.org/ | grep -iE '^(strict-transport|content-security|x-frame|x-content-type|referrer|permissions)' ``` ```text issuer=C=US, O=Let's Encrypt, CN=YE2 notAfter=Nov 3 19:15:40 2026 GMT transfer 2012-03-09T16:33:50.754Z expiration 2027-01-13T00:12:14Z registration 2001-01-13T00:12:14.754Z last changed 2026-08-12T08:47:19.41Z last update of RDAP database 2026-10-03T22:07:05.66Z "v=DMARC1; p=reject; rua=mailto:dmarc-rua@wikimedia.org;" strict-transport-security: max-age=106384710; includeSubDomains; preload ``` Only HSTS came back from the header check, which matches "1/6 security headers". The certificate ends on 3 November, 30 days after the run; the domain on 13 January 2027, 101 days after. ## Keep watching it A health check tells you about one moment. An [HTTP monitor](/http-monitoring) requests the site from several locations on a schedule, confirms a failure from other locations before it opens an incident, and its **SSL Certificate** rule warns you at 14 days (and optionally 7) before the certificate runs out, so the dates in this report don't depend on someone remembering them. For the domain itself there is a separate [domain expiry monitor](/domain-expiry-monitoring). ## FAQ **How do I check if my website is healthy?** Check that it answers over HTTPS from more than one location, that the certificate and domain are not close to expiry, that `http://` and the `www`/bare host redirect to one HTTPS address, and that SPF and DMARC are published. The Smart Website Checker does all of that in one scan. **What does an A+ website grade mean?** In this checker it means 97 points or more with no critical finding. It doesn't mean nothing is left to do: read the "worth improving" and "dates" panels too. **How often should I check my website's health?** After every migration, launch or DNS change, and on a schedule for the things that expire. Expiry dates are better handled by a monitor than by a monthly manual check; [how to monitor a website](/blog/how-to-monitor-a-website) covers the setup. --- Canonical page: https://watchfor.io/blog/how-to-check-website-health · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt