Securing a website: the checklist
Securing a website sounds like one task, but it is four: the address a visitor types, the connection that then sets up, the headers the answer carries, and the mail layer revolving around your domain. Whoever sets "HTTPS on" has at most done one of the four.
The checklist below is no opinion: beside every item stands the measurement that can prove it, and the tool in this article that does that measuring. A secured website is not a feeling — it is a series of observable answers at addresses that others see.
Start at the website scan: one request, four layers in one report, and a grade that counts only where it actually measured. Afterward this article points, per layer, to the tool that digs deeper.
1. The address: what happens when someone types
Security begins where the visitor begins: they type example.com — what do they then see? A redirect chain taking three corners, a www variant landing on a different certificate, or a domain not answering on IPv6 at all — those are not style questions, they are answers a scanner notes. Check the chain and both addresses with Domain hygiene.
The measurement question is simple: how does my domain look to someone who knows nothing about it beforehand? That is exactly the question Domain hygiene asks — nameservers, IPv4 and IPv6, MX, SPF and CAA in one report, fetched via our resolver, judged in your browser.
2. The connection: certificate and open versions
"HTTPS works" is a result, not a policy. What still stands open next to TLS 1.3 — 1.2 is fine, 1.0 and 1.1 are retired — and whether the certificate on this address is still valid, who issued it and which names the SAN coverage carries, comes out of the handshake itself. Certificate check reads the certificate, SSL test probes every version separately. More on that in TLS: what is still open.
3. The answer: headers that carry policy
HSTS without includeSubDomains, a CSP that does nothing, a cookie without the Secure flag: response headers are where security policy becomes visible to the outside world. HTTP headers exposes, hop by hop, what your origin sets and what a proxy tinkers on — and the security headers checklist says what ought to stand.
4. Measure before and measure after
One scan is a snapshot; security is a course. Keep the report from before the change and the one after it and lay them side by side with the report comparator: "did it get better?" then gets an answer with two dates instead of a feeling. The mail layer of your domain — SPF, DKIM, DMARC — belongs to the same picture; SPF, DKIM and DMARC explained is the entry there.