The Website Health Check turns technical signals into a structured report you can act on without a networking degree. This guide explains what each section means, how severity levels work, and what to do when a finding looks alarming but is actually expected for your setup.
When you submit a domain, the report opens with a summary of overall health and a short list of priority issues — problems that affect security, availability, or email delivery right now. Below that, individual modules break down SSL, DNS, email authentication, security headers, robots.txt, and page performance.
Each module uses plain-language explanations alongside technical evidence. You do not need to parse raw certificate dumps or DNS zone files; the report highlights what passed, what failed, and why it matters. An action checklist at the end collects concrete next steps you can hand to a developer or tackle yourself in the DNS panel.
Results reflect a point-in-time snapshot from our servers. Re-run the check after you make changes — DNS propagation and CDN cache updates can take minutes to hours before the public view matches your edits.
Priority issues deserve attention before you ignore anything else. Examples include an expired SSL certificate, MX records that do not resolve, or a complete absence of SPF when you send business email from the domain. These directly break trust, mail delivery, or visitor access.
Other findings are improvements worth scheduling but not emergencies. A missing Permissions-Policy header or a slightly slow time-to-first-byte will not take your site offline today, but fixing them hardens security and improves experience over time.
Do not treat every yellow indicator as a crisis. A brochure site on a managed platform may deliberately omit advanced headers your host controls at the edge. Read the explanation text — it often notes whether a gap is a hard failure or a best-practice recommendation.
When sharing the report with a contractor, forward the priority section first. It sets scope: fix what is broken, then discuss enhancements.
The SSL module inspects the certificate presented on port 443 for the hostname you entered. It reports validity dates, issuer, hostname coverage (Subject Alternative Names), and whether the connection negotiates modern TLS versions.
What to look for:
www.example.com will fail on the bare apex unless you redirect consistently.If SSL fails but the site loads in your browser, you may be hitting a CDN edge certificate while the origin is misconfigured, or testing a different hostname than you entered. Re-run the check with the exact URL customers use.
The DNS module queries public resolvers for A, AAAA, CNAME, NS, and relevant TXT records. It surfaces mismatches that cause downtime after migrations — for example, an A record still pointing at a decommissioned server IP.
Key interpretations:
DNS changes are not instant. If you just updated a record, wait for TTL expiry and run the health check again before assuming the fix failed.
This module covers MX records plus SPF, DKIM, and DMARC — the combination that routes inbound mail and authenticates outbound messages. It is often the most valuable part of the report for small businesses who verified SSL but never touched email DNS.
How to read common results:
include: mechanisms, or no SPF at all, hurts deliverability. The report explains whether a record exists and if syntax looks valid.Email auth is cumulative. Passing SPF alone is not enough; align SPF, DKIM, and DMARC for strong protection and inbox placement.
The security headers module lists HTTP response headers that harden browsers against common attacks: HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and others. Missing headers are flagged with context — some are critical for high-risk applications, others are incremental hardening for marketing sites.
The robots.txt module fetches your live crawl rules file. It shows whether you block all crawlers (Disallow: /), allow indexing, and reference a sitemap. A leftover staging robots.txt is a silent SEO killer; this section catches it quickly.
If you use a CDN or managed host, headers may be set at the edge rather than origin. A missing header in the report might mean you need to enable it in Cloudflare, Vercel, or your server config — not that your application code is wrong.
The performance section measures how quickly your homepage responds from our test location — typically time to first byte and total load indicators. Slow results often trace to unoptimized hosting, missing compression, or heavy third-party scripts rather than DNS or SSL problems.
Full check mode (when available) adds network-level visibility such as traceroute and common-port scans. Treat this as infrastructure reconnaissance, not a penetration test. Open ports may be intentional (SSH for admin, 587 for submission) or worth questioning if you expect a static marketing site with only 443 exposed.
Performance and port findings help you prioritize hosting upgrades or firewall rules. They rarely block launch the way a broken certificate does.
The closing checklist distills findings into tasks: renew a certificate, add a DMARC record, enable HSTS, fix an A record. Use it as a work ticket list — each item maps to a specific layer you or your developer can fix independently.
After completing changes, re-run the Website Health Check to confirm priority issues cleared. Keep a copy of reports before and after major migrations; they are useful evidence when disputing whether a hosting transfer was completed correctly.
If a finding persists but you believe it is a false positive, check whether you tested the right hostname, whether a CDN masks origin behavior, and whether your DNS panel matches public resolvers. When in doubt, share the technical evidence block from the relevant module with your host's support team.
The best way to learn the report format is to generate one for your own domain. Enter a URL below and refer back to this guide section by section.
Run Website Health Check →