Website and SEO
Security checkup
What the security checkup reads from your live site: headers, cookies, exposed files, technology, subdomains, blocklists and registration, with every check.
Updated · 3 min read
The security checkup fetches your site the way a browser would and reads what comes back. It runs as part of every domain scan and on its own from the app's Website module. Every check is listed, pass or fail, so a clean report can be told apart from a report that stopped early.
Where
- Web: Security, Overview, the Security headers table for every domain; Run security scan re-reads them.
- iOS: Website, Security checkup opens on the last results with Run it again. The header count on the Website module reads the checkup's Security Headers category.
- API/MCP:
GET /api/checkup?domain=…(signed in),GET /api/domains/:id/checkup-history; toolsrun_domain_checkup,get_checkup_history.
Categories
| Category | Checks |
|---|---|
| SSL/TLS & Website | The site answers over HTTPS, redirects HTTP, HSTS is sent, and (for monitored domains) the certificate our scanner read from each host: expiry, trust, complete chain, name match, key, TLS versions, plus the domain's CAA record. See Certificate monitoring |
| Security Headers | Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Content-Security-Policy, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, and X-XSS-Protection (where absent is the current recommendation) |
| Cookie Security | Secure, HttpOnly and SameSite on the cookies the site sets |
| Page security | Content-Security-Policy quality, subresource integrity on third-party scripts, and third-party script inventory |
| Sensitive paths | Exposed files and configs: .env, .git, backups, admin panels, phpinfo and similar |
| Technology | The software and versions the site advertises, feeding the software inventory |
| Email Authentication | SPF, DKIM, DMARC, MX, MTA-STS, TLS-RPT, SPF lookup count and policy strength (the same reads as the Email module) |
| DNS Health | Nameservers and nameserver redundancy |
| Attack surface | Subdomains found in certificate transparency |
| Reputation | The site's IP against DNS blocklists (DNSBL) |
| Domain Registration | Registrar, creation date, expiry, status locks |
The score out of 100 weights failing checks by severity. Under 60 by default raises the Security issues notification; the threshold is security_threshold in Settings.
Clearance
The checkup runs on any domain. Its exposed-file probe is a deep check and runs only on a domain you have verified; on any other domain the checkup says it was not checked. See Verifying a domain for deep scans.
Blocklists
"Check blocklists" on the Website module re-reads the DNSBL result; the blocklist row otherwise shows what the last checkup found. A listing shows as a failed check in the Reputation category; there is no separate blocklist alert or switch.
Fix guidance
Each failing check names the header or setting, why it matters, and what to set. POST /api/ai/checkup-suggestions turns the failing checks into plain-language steps for the platform the site runs on; in the app that is the finding's page. See Fix suggestions.
Common questions
X-XSS-Protection is missing and the check passes. Why? The header is obsolete and browsers ignore it; the current recommendation is not to send it.
My CDN sets the headers, but the check says missing. The checkup reads the response the apex returns. If a redirect to www. happens first, the headers on the final page are what count; make sure both hosts send them.
Scans read their own egress. A fetch from Cloudflare's network to a site behind Cloudflare picks up Cloudflare's own headers (cf-ray, server: cloudflare). The technology detector knows to discount those.
Keep reading
Related articles
- The site check: speed, mobile, SEO and security in a real browserHow the site check loads your pages as a phone on 4G, what the six sections measure, how each finding tells you the cause and the fix, and when checks run on their own.Website and SEO ·Updated
- Verifying a domain for deep scansBasic scans run on any domain. Deep scans (open ports, known vulnerabilities, exposed files) run on domains you verify: an email link, a DNS record or a file, about a minute, and we finish the check for you.Vulnerabilities and exposure ·Updated
- IndexNow: tell search engines a page changedTurning IndexNow on for a domain, the key file your site has to serve, which engines get notified, sending pages by hand or from the sitemap, and the record of every URL sent and what each engine answered.Website and SEO ·Updated