This tool verifies that your site is served securely: a valid SSL/TLS certificate, HTTP automatically redirecting to HTTPS, and the modern security headers browsers rely on — HSTS, Content-Security-Policy, X-Frame-Options and more.
It also flags mixed content (insecure resources on a secure page) and checks that your cookies use the Secure, HttpOnly and SameSite flags.
Installing an SSL certificate is only the first step. If HTTP requests aren't redirected to HTTPS, visitors can still land on an insecure version of your site. If the HSTS header is missing, a single intercepted request can strip the encryption. And if resources on the page load over HTTP, the browser flags 'mixed content' and the padlock breaks.
This checker verifies the whole chain — certificate validity, HTTPS enforcement, HSTS, security headers and cookie flags — not just whether a certificate exists.
HSTS (Strict-Transport-Security) tells browsers to only ever connect over HTTPS. Content-Security-Policy controls which sources scripts, styles and images may load from, blocking most cross-site scripting. X-Frame-Options and frame-ancestors stop your site being embedded in a hostile iframe. X-Content-Type-Options stops browsers guessing file types in unsafe ways. Referrer-Policy controls how much URL information leaks to other sites.
Most WordPress sites ship with few or none of these. The report gives you the exact header lines to add for your server so you can close the gaps in minutes.
Mixed content usually comes from hard-coded HTTP URLs in old posts, theme files or plugins. The fix is to update those URLs to HTTPS (or protocol-relative) and ensure your site URL is set to HTTPS in WordPress settings. For cookies, the Secure and HttpOnly flags keep session cookies from being stolen, and SameSite limits cross-site sending.
Run the check, apply the fixes, then re-scan to confirm the padlock is clean and every header is in place.
HTTP Strict Transport Security tells browsers to always use HTTPS for your site, blocking downgrade and cookie-hijacking attacks.
When a secure HTTPS page loads some resources (images, scripts) over insecure HTTP. It breaks the padlock and can be blocked by browsers.
At minimum HSTS and X-Content-Type-Options are strongly recommended. CSP is powerful but needs tuning — the report explains each.
A valid certificate is step one, but without HTTPS redirects and security headers you still have gaps this checker highlights.
Absolutely. Let's Encrypt certificates are trusted by all browsers and auto-renew. What matters is that HTTPS is enforced everywhere and the right headers are set.
Usually mixed content — the page loads over HTTPS but pulls an image, script or stylesheet over HTTP. This checker lists the insecure resources so you can switch them to HTTPS.