Secure
Website security check
Check the security a visitor can see: your certificate and how long it has left, whether http visitors are forced onto a secure connection, which browser protections you send, and whether your site is announcing which software it runs.
- Free
- No account
- Usually under a minute
What this checks
Every one of these is measured directly on your page and reported with the evidence attached.
- Secure connection
- Whether the site is served over https at all.
- Insecure address
- Whether the http version still serves the site instead of redirecting, leaving an unencrypted copy live alongside the real one.
- Security certificate
- Whether the certificate is valid, matches the domain, and how many days it has left. Under thirty is worth acting on now.
- Forced secure browsing
- Whether you tell browsers to only ever connect encrypted, so the insecure version can never be reached even once.
- Insecure content
- Whether a secure page is loading images or scripts over an insecure connection, which undermines the padlock it displays.
- Browser protections
- The headers your server sends instructing the browser to refuse to guess file types, refuse to be embedded in another site, and limit what it leaks to sites you link to.
- Software version on show
- Whether your pages announce which platform and version you run — which turns a broad automated scan into a precise match.
These run alongside the rest of the audit — every scan covers all six areas, so you get speed, works on phones, found on google, secure, looks legitimate and easy to contact whichever page you started from.
What this is, and honestly what it is not
This is an external check. It looks at your site the way any visitor's browser does and reports what that view reveals: the state of your certificate, whether the insecure version of your site is still live, which protective headers you send, and whether your pages advertise which software they run.
It is not a vulnerability scan, a malware scan, or a penetration test. It does not log into anything, does not probe for weaknesses, and does not touch your server beyond requesting pages the way a visitor would. Nothing is changed on the site being checked.
We are explicit about that boundary because the distinction matters. A clean result here means the visible layer is configured correctly. It says nothing about an out-of-date plugin, a weak administrator password, or a file somebody uploaded last year — and those are the things that actually get small sites compromised. A tool that let you believe otherwise would be doing you harm.
Why small sites get compromised
Almost never on purpose. Automated scanners crawl the entire internet looking for known, published vulnerabilities — the same hole on every site running the same out-of-date plugin. Nobody chose your business.
Which is why the defences that work are unglamorous: keep software updated, delete what you do not use, take backups you have actually tested restoring, and put two-factor authentication on every administrator account. Those four things close off the overwhelming majority of what happens to sites this size, and none of them are visible from outside — which is why they are in the security checklist rather than in this scan.
The certificate finding people act on
Certificates expire. When one does, visitors do not get a subtle warning — they get a full-page browser interstitial telling them the site may be dangerous, and most of them leave.
Most certificates renew automatically these days, and most of the time that works. The failure mode is silent: automatic renewal breaks after a server change, nobody notices, and thirty days later the site is unreachable in every browser at once.
So we report the exact number of days remaining rather than a pass or a fail. Ninety days left and eleven days left are very different situations, and a green tick would hide the difference.
The one people skip: http still serving
Getting a certificate is the well-known half. The half that gets missed is making sure the insecure address stops working.
If both http://yourdomain.com and https://yourdomain.com serve your site, you have two live copies. Search engines may treat them as separate pages and split your rankings between them, and any visitor who reaches the http one sees a "not secure" warning on a site that has a perfectly good certificate sitting unused.
The fix is a permanent redirect from one to the other, plus a header telling browsers never to try the insecure version again. Both are small server changes and both are checked here.
Version numbers, and why hiding them is worth doing anyway
Many sites announce their platform and its exact version in the page or in the headers the server sends. That turns an internet-wide scan for a known vulnerability into a precise match.
Removing it is not real security, and we will not pretend it is — a determined attacker can fingerprint your software other ways. But the risk to a site this size is not a determined attacker; it is an automated list. Coming off that list is worth the ten minutes it takes.
Common questions
Is this a vulnerability scan?
No. It checks what a visitor's browser can see — certificate, redirects, headers, exposed version numbers. It does not probe for weaknesses, log into anything, or scan for malware, and it makes no changes to the site being checked.
Is an SSL certificate enough to make my site secure?
No. A certificate encrypts traffic between visitor and server, which stops someone on the same wi-fi reading it. It does nothing about out-of-date software, weak passwords, or an abandoned plugin with a published hole.
My certificate expires soon. What should I do?
Find out whether renewal is automatic. On most modern hosting it is, and it usually just works. If yours is manual, or if automatic renewal has failed before, put a calendar reminder two weeks before expiry — the failure mode is silent right up until every browser blocks the site at once.
What are security headers?
Short instructions sent with each page telling the browser to enforce extra protections: refuse to guess file types, refuse to be embedded in someone else's page, insist on an encrypted connection, and limit what is passed to sites you link to. They cost nothing and take minutes to add.
Can I check a website I do not own?
Yes. Everything examined here is information the site publishes to every visitor. No permission is needed and nothing is altered.
Read more about this
The longer explanations, written for someone who wants to understand the problem rather than just fix it.
Website security checklist for small businesses
Twelve security checks a business owner can run without a developer — certificates, updates, backups, logins and the headers your site sends. What each one protects against, and what to do about it.
Read the guideHow to do a website audit: a 10-step checklist
A website audit checklist you can work through yourself: speed, mobile, search visibility, security, trust and contact. What to check, and what good looks like.
Read the guideSEO audit checklist: 23 things to check
A practical SEO audit checklist covering indexing, on-page, technical and content. Each check says how to run it, what good looks like, and whether you need a developer to fix it.
Read the guideWebsite security check
Free, no account, and the report is yours to keep.