What do you check to judge a website's security?

A security audit sounds like work for a penetration tester, but most of it is visible from outside and within minutes. Not because it is easy, but because the most common faults are configuration, not code.

One distinction up front: this is about hygiene, not vulnerability hunting. Scanning for malware and known exploits is a different job.

1. Certificate and HTTPS

The first and only layer a visitor notices. What to check:

• whether the certificate is valid and when it expires;
• whether http:// redirects to https:// rather than running alongside it;
• whether the www and non-www versions lead to the same address.

Two versions running in parallel is both a security and an SEO problem: content duplicates, and some visitors stay on an unencrypted connection.

2. Security headers

This is where the gap between "works" and "in order" lives. Headers are instructions telling the browser what it may do with your page:

Strict-Transport-Security   the browser stops trying HTTP even once
Content-Security-Policy     where scripts are allowed to load from
X-Content-Type-Options      no guessing a file's type
Referrer-Policy             how much of the address goes to another site
X-Frame-Options             whether your page can be put in someone's frame

They break nothing and cost nothing, and without them the browser behaves in the most permissive way available.

3. Mixed content and third-party scripts

A page served over HTTPS with even one image or script arriving over HTTP is a page with a hole. Browsers block some of that content silently, and the fault shows up as "something is not working".

The other half is how many third-party domains have the right to execute code on your page at all. Each one is trust you do not control.

4. What is reachable that should not be

A quick check worth doing everywhere: whether /.env, /.git/config, /backup.zip or an unrestricted admin panel opens publicly. This is not theory — it is how most leaked credentials get found.

What you cannot see from outside

Library versions, server patching, password policy and backups. That part is only checkable by someone with access — which is why an external audit is never a complete audit, and a good report says so.

Related articles

The same subject from another angle — each answers its own question:

• Security headers: what each one actually does
• Technical SEO audit: what to check and when
• Free SEO scan: what it actually shows you

How this feeds into the score is described under what we check.

Sources

What this text rests on — primary sources, not retellings:

• OWASP — Secure Headers Project
• MDN — Content-Security-Policy
• MDN — Strict-Transport-Security
• MDN — HTTP Observatory