Website security covers two quite different things, and conflating them is why the subject feels overwhelming. One is whether somebody can break into your site — which depends on your software being up to date and your passwords being decent, and is largely invisible from the outside. The other is whether your site is set up the way a secure site should be, which anybody can check, including anybody hostile.
This is about the second. It is the part a scan can see, and it is the part a visitor's browser judges you on.
The padlock, and what it does not mean
A padlock in the address bar means traffic between the visitor and your server is encrypted. It does not mean the site is safe, well built, or run by honest people — certificates are free and anybody can get one. Treat it as a floor rather than a badge.
What matters more is that it is enforced. A site that works over both http and https, without redirecting one to the other, leaves visitors on the unencrypted version if that is the address they typed. Browsers mark those pages 'Not secure' in the address bar, and anything typed into a form on them can be read in transit.
There is a subtler version: a site that redirects correctly but never tells the browser to remember. The very first request of a visit can still go over an insecure connection before the redirect happens, which is the window somebody on shared Wi-Fi needs. One response header closes it.
Your certificate, and the two ways it goes wrong
A certificate expires, usually after ninety days or a year, and most renew automatically. When one does not, the failure is not gradual. Every visitor gets a full-page browser warning telling them your site is not safe, most leave rather than click through it, and search engines stop crawling. It is the single most abrupt way a working site stops working.
The other failure is a certificate that does not cover the address being used — most often one issued for example.com being served at www.example.com, or the reverse. Browsers treat that exactly like a fake. Worth checking both addresses, since people type both.
Headers, which are free and almost nobody sets
A handful of response headers tell browsers to behave more carefully with your site. They cost nothing, break almost nothing, and are absent from the large majority of small business websites — including, until recently, this one.
They are worth doing in roughly this order.
- X-Content-Type-Options
- Stops a browser second-guessing what kind of file something is. Without it, a file your server says is an image can be treated as something executable.
- X-Frame-Options
- Stops another site loading your pages inside an invisible frame and tricking visitors into clicking your buttons while they think they are clicking something else. Most often aimed at login and payment forms.
- Referrer-Policy
- By default, clicking a link off your site hands the destination the full address of the page they left. If your addresses contain an order number or a customer reference, that goes with it.
- Content-Security-Policy
- The strongest of them and the one that needs care. It tells the browser which scripts may run, so an injected script — from a compromised plugin or a hijacked advert — does nothing. Introduce it in report-only mode first; doing it the other way round takes sites down.
Forms, and the mistake worth checking today
A page can be served perfectly over https and still contain a form that submits to a plain http address. Everything typed into it goes unencrypted. Browsers now warn about this directly on the field when the form collects a password or payment details, which means your visitors may be seeing a warning you are not.
The same applies to images and scripts: a secure page that pulls in an image over http either has the image blocked outright — leaving a visible gap — or loses the padlock, which is the one thing visitors have been taught to look for.
What we check for this
What a scan cannot tell you
Worth being clear about the limits. A scan of this kind reads what your server sends to a browser. It does not attempt to break in, it does not test your passwords, and it cannot see whether your WordPress plugins are three years out of date — which is, in practice, how most small business sites are actually compromised.
So treat a clean security section as evidence that the outside of the building is sound. Keeping software updated, using a password manager, and turning on two-factor authentication for your admin accounts are the things that matter most and the things no external scan can check for you.
What we check for this
Find out where your site stands
Everything described above is something the scanner looks for, with the evidence for each result on your own pages. Free, no account, first findings in about twenty-five seconds.
Scan my siteThe checks behind this guide
- Secure connection is enforcedVisitors who type your address without 'https' stay on an unencrypted connection. Browsers mark those pages 'Not secure' in the address bar, and anything typed into a form on them can be read in transit.
- Security certificate is not close to expiringWhen a certificate expires, every visitor gets a full-page browser warning telling them your site is not safe, and most leave rather than click through it. Search engines stop crawling too. Most certificates renew automatically, so this is worth checking while there is still time rather than discovering it on the day.
- Browsers are told to stay on HTTPSYour site works over HTTPS, but it never tells browsers to remember that. The very first visit of the day can still be sent over an insecure connection before the redirect happens, which is the window an attacker on shared Wi-Fi needs.
- A content security policy is in placeA content security policy tells the browser which scripts it may run. Without one, anything that manages to get injected into a page — through a compromised plugin, a hijacked advert, or a comment field — runs with the same trust as your own code.
- Secure pages load only secure resourcesA page served over HTTPS that pulls in an image or a script over plain HTTP is only as secure as its weakest request. Browsers either block those outright — leaving a visible gap where the image should be — or drop the padlock, which is the one thing visitors have been taught to look for.
- Forms submit over a secure connectionA form that posts to a plain HTTP address sends everything typed into it unencrypted, readable by anything between the visitor and your server. Browsers warn about it directly on the field when the form collects a password or payment details. A page can be served over HTTPS and still have a form that submits insecurely, which is why this is checked separately from the connection itself.