What a Website Safety Checker Actually Does
A website safety checker looks at a site's own technical setup - its HTTPS configuration, TLS certificate, response headers, cookies, and whether an HTTPS page quietly loads any insecure content - and tells you what's solid and what needs fixing. This one works exactly like that: paste a URL into the box above, and it fetches the live page, checks whether plain HTTP actually redirects to HTTPS, opens a real TLS handshake to inspect the certificate, and reads every relevant response header and cookie. What comes back is a 0-100 safety score, a letter grade, and eleven individually scored signals, each with a plain-language note on what was found and why it matters.
It's built for people who need a fast, honest read on a site's technical safety without installing anything: developers running a pre-launch checklist, agencies adding a safety pass to client QA, site owners who inherited a server someone else configured, and SEO practitioners who know HTTPS and trust signals matter to both rankings and AI answer engines. This is one of AudEsto's free SEO utilities - no account is needed to run a check.
One thing worth being upfront about: this is a technical configuration checker, not a malware or phishing blacklist lookup. If you're trying to answer "is this website safe to buy from" or "has this site been flagged for malware," you also want a reputation tool like Google's Safe Browsing site status page - see the Limitations section below for more on that distinction.
How to Use This Website Safety Checker
- Enter the URL. Paste the full address of the site you want to check, with or without the protocol.
- Verify you're human. Click Check Safety and complete the quick reCAPTCHA check - this keeps the tool from being scripted and abused, so it stays free for everyone.
- Read the score. The score ring shows the overall 0-100 result and letter grade, with pass/warning/fail counts summarized right beside it.
- Work through the checklist and details. Each of the eleven scored signals, plus the TLS certificate, cookie audit, and mixed-content list, is broken out individually - fix what's flagged, then run the check again to confirm it worked.
Each browser or IP gets a set number of free checks per day. That's enough to cover the properties that matter most in one sitting: the main domain, the www subdomain if it's served separately, and any login or checkout subdomain, since those carry the highest risk if headers or cookie flags are missing.
How It Works, and What Each Result Means
Under the hood, the tool makes three separate live connections - not one, which is where most free website safety checker tools stop. First, it fetches the requested URL directly, following redirects, and reads every response header plus every individual Set-Cookie line on its own (a joined cookie header can't be reliably split back apart to check each cookie's flags). Second, it makes an independent request to the plain-http:// version of the same host to see whether the server itself redirects insecure traffic, rather than assuming it does just because the HTTPS version works. Third, it opens a raw TLS socket to port 443 and performs a real certificate handshake with the same trust store a browser uses, so a self-signed, expired, or hostname-mismatched certificate gets caught - not just assumed valid because the port answered.
The 0-100 score is a weighted sum across eleven components, each tied to a real response or a real handshake:
| Signal | Max Points | What It Checks |
|---|---|---|
| HTTPS Enforcement | 15 | Whether the site loads over HTTPS, and whether plain HTTP actually redirects to it |
| Content-Security-Policy | 15 | Presence of a CSP header, and whether it avoids unsafe-inline/unsafe-eval/wildcard sources |
| HSTS | 10 | Strict-Transport-Security header, its max-age, and includeSubDomains |
| Clickjacking Protection | 10 | X-Frame-Options or a CSP frame-ancestors directive |
| Cookie Security | 10 | Secure, HttpOnly, and SameSite flags on every Set-Cookie header found |
| Mixed Content | 10 | Insecure http:// scripts, styles, images, iframes, or form actions on an HTTPS page |
| X-Content-Type-Options | 8 | The "nosniff" directive, which blocks MIME-type sniffing attacks |
| Referrer-Policy | 7 | Whether the referrer sent to other sites is restricted rather than fully exposed |
| TLS Certificate | 5 | A real handshake against port 443: chain validity, issuer, expiry, and TLS protocol version |
| Permissions-Policy | 5 | Whether powerful browser APIs (camera, microphone, geolocation) are explicitly restricted |
| Information Disclosure | 5 | Server/X-Powered-By headers revealing exact software versions |
Grades map to the total: A (90-100), B (75-89), C (60-74), D (45-59), and F (below 45). Below the checklist, three more panels break results down further: the TLS certificate card shows the issuer, protocol version, and days left before expiry (or the exact validation error, if the handshake failed); the cookie audit table lists every cookie the response set with a clear yes/no for each flag; and the mixed-content list names any insecure http:// resource found on an otherwise-HTTPS page.
Why This Matters for SEO - and What Doesn't
It's worth being precise here instead of treating every item on the checklist as a Google ranking factor, because it isn't one. HTTPS itself is a confirmed, if lightweight, direct ranking signal - Google said so outright back in 2014, and Chrome has labeled plain-HTTP pages "Not Secure" since 2018, which measurably hurts conversion on forms and checkout pages even where rankings aren't affected. Everything else on this checklist - HSTS, CSP, clickjacking protection, cookie flags, mixed content - is not a ranking factor Google scores directly. Their effect on SEO is indirect: a missing CSP doesn't cost you a ranking position by itself, but it raises the odds of an XSS incident, and a compromised site getting blocklisted by Safe Browsing or deindexed is a far bigger SEO hit than any single header. Treat the rest of the checklist as security best practice and a diagnostic signal, not a Google scorecard.
- HTTPS is table stakes, not a bonus. A site without it - or one where HTTP quietly stays reachable alongside HTTPS - fails a baseline check for browsers, users, and search engines alike.
- Headers are cheap insurance. Unlike a redesign or a CDN migration, adding HSTS, CSP, and X-Frame-Options is usually a small server-config change with an outsized reduction in attack surface.
- Cookies and mixed content are the parts people forget. A site can have a clean HTTPS setup and a strong CSP, then still leak a session cookie because SameSite was never set, or trip a mixed-content warning from one old hardcoded image URL.
A Practical Example
Score of 54/100 (D): HTTPS loads fine but plain HTTP doesn't redirect to it (9/15), no CSP or HSTS header at all (0/15, 0/10), and the session cookie was missing both HttpOnly and SameSite (4/10).
The site technically supports HTTPS but doesn't force it, and its default framework cookie settings were never hardened - both are common on shared hosting where the platform's defaults are left untouched.
Add a server-level 301 redirect from HTTP to HTTPS first (highest points for the least effort), set the session cookie's HttpOnly and SameSite flags in the application config next, then add HSTS once the redirect is confirmed working everywhere.
Real-World Use Cases
- Pre-launch checklists. Confirm HTTPS, headers, and cookie flags are all correctly configured before a new site or redesign goes live.
- Agency safety QA. Add a safety check alongside meta tag, speed, and broken-link checks in a client site audit.
- Certificate expiry monitoring. Spot-check a certificate's remaining days without a dedicated uptime service.
- Post-migration verification. Confirm a server or CDN migration didn't quietly drop a header or reintroduce an insecure cookie default.
- Comparing hosting or CDN providers. Check the same page's default header and TLS setup before and after switching providers.
Common Mistakes to Avoid
- Adding headers without testing first. A strict CSP can break legitimate inline scripts or third-party widgets - test in staging before enforcing it in production.
- Turning on HSTS before HTTPS is fully stable. Once a browser caches a long-max-age HSTS policy, it refuses to load the site over HTTP at all, even temporarily - confirm HTTPS works everywhere first.
- Treating a clean score as a full audit. This checks configuration-level signals, not application logic - it's a strong baseline, not a substitute for a real penetration test on anything handling sensitive data.
- Fixing headers but ignoring cookies. A page can score well on every header and still leak session state through an unflagged cookie - check both.
Expert Recommendations
Fix in the order the score weights things: HTTPS enforcement and CSP first (15 points each), then HSTS and clickjacking protection (10 each), then cookies and mixed content (10 each), then the smaller header signals. A site that fully enforces HTTPS with a real CSP and correctly-flagged cookies covers most of what a baseline safety review looks for - the remaining points help, but they're a smaller marginal gain than the first few fixes.
Re-run the check after every meaningful change instead of batching several fixes and testing once. A CSP typo or an over-eager HSTS setting is hard to unwind once a browser has cached it, so confirming each change on its own is worth the extra few seconds. If you're weighing which of the several website safety checker tools out there to use for that, the real difference is whether it opens an actual connection and validates the certificate, or just parses headers and calls it done.
Limitations and Important Considerations
- This is not a malware or blacklist scanner. It doesn't query Google Safe Browsing, PhishTank, or any reputation database. A technically well-configured site can still be compromised, and a site with a mediocre score here isn't necessarily hosting anything malicious - for reputation/blacklist status, pair this with a dedicated tool like Safe Browsing's site status page.
- It's not a penetration test. It checks configuration signals visible from an unauthenticated request and a TLS handshake - it doesn't attempt to exploit anything or scan for application-level vulnerabilities like SQL injection.
- The TLS certificate check connects to port 443 specifically; a site running HTTPS on a non-standard port still gets header/cookie/mixed-content scoring, but the certificate sub-check may not apply.
- Mixed-content scanning covers what's visible in the fetched HTML (script/link/img/iframe/source/form tags) - content injected dynamically by JavaScript after page load isn't inspected, since this tool doesn't render a browser engine.
- A single check reflects the site's configuration at that moment - certificates expire and headers change with deployments, so re-check periodically rather than treating one result as permanent.
Run the website safety checker above against any live URL to see its full safety score in a few seconds - it's free, and no account is required.