How to check if your website is secure

1. HTTPS everywhere, not just the homepage

Every page on your site should load over https://, and every http:// version of every address should redirect straight to its https:// equivalent, not just happen to resolve on its own. HTTPS works by encrypting the traffic between a visitor's browser and your server, so nobody sitting in between - a shared cafe wifi network, a compromised router, an ISP doing traffic shaping - can read or alter what's being sent. The catch is that HTTPS rollout is rarely all-or-nothing in practice. A site migration can leave an old subdomain unmigrated, a plugin can hardcode an http:// image URL, or a CMS template might force https on the homepage while quietly forgetting the checkout or contact form. A padlock on the homepage tells a visitor nothing about what happens two clicks later. Mixed content - where a secure https:// page still loads an image, script, or stylesheet over plain http:// - has the same effect: modern browsers either block the insecure resource outright or strip the padlock and warn the visitor, which looks exactly like a security failure even when the core site is fine.

2. Security headers

HTTP security headers are instructions your server sends to every visiting browser about how to defend that visitor, and each one closes a specific, well-understood attack rather than adding vague protection. HSTS (HTTP Strict Transport Security) tells the browser to remember that your domain should only ever be reached over https, so even if a visitor types the http:// version or clicks an old link, the browser upgrades the connection itself before a downgrade attack can intercept it. A Content Security Policy sets an allowlist of where scripts and styles are permitted to load from - so if an attacker ever manages to inject a malicious script through a compromised third-party widget or a vulnerable form field, a CSP can stop that script executing even though it's sitting right there in the page. X-Frame-Options (or its modern replacement, the frame-ancestors CSP directive) stops your pages being loaded inside an invisible iframe on someone else's site, which is how clickjacking tricks visitors into clicking a button they can't actually see. Most sites ship with none of this configured, simply because leaving it out doesn't visibly break anything - until the day it does.

3. Email authentication: SPF, DKIM, DMARC

These three DNS records work together to prove that an email claiming to come from your domain actually did, and each closes a different gap. SPF lists which mail servers are allowed to send email on your domain's behalf, so a receiving server can check whether a message came from an authorised source. DKIM attaches a cryptographic signature to outgoing mail, letting the receiving server confirm the message wasn't altered in transit and genuinely originated where it claims. DMARC ties the other two together: it tells receiving mail servers what to do when a message fails SPF or DKIM - quarantine it, reject it, or just monitor and report - and without a DMARC policy in place, anyone can send email that appears to come from your domain. That's exactly how invoice fraud against small businesses works: a customer receives what looks like a legitimate email from your finance team with updated bank details, and because the sending address matches your domain, they pay it. These records also decide whether your own legitimate email lands in the inbox or in spam. This is one of the highest-value fixes on this list, and it costs nothing beyond editing DNS.

4. Exposed software versions

Software version numbers leak out in more places than people expect: a WordPress meta generator tag in the page source, a plugin's changelog or readme file left publicly accessible, or the theme name sitting in a stylesheet path. None of this looks dangerous on its own, but it doesn't need to - most of the scanning that finds it isn't a person manually poking at your site, it's automated. Bots crawl the web continuously, harvesting version strings and matching them against public vulnerability databases in seconds, which means an unremarkable small-business site gets probed just as often as a high-profile one, because the process costs the attacker nothing to run at scale. Once a bot matches your exposed version against a known, unpatched vulnerability, exploiting it is often a matter of running an existing, publicly documented script rather than any custom effort on the attacker's part. The fix is straightforward, if ongoing: keep the CMS, theme, and every plugin updated, remove or restrict access to readme and changelog files, and suppress version strings in headers and meta tags wherever the platform allows it.

5. Malware and blocklist status

Google Safe Browsing, and the equivalent lists other browsers use, maintains a constantly updated database of sites known to serve malware, run phishing pages, or host unwanted software, and if your domain lands on it, the consequences are immediate and visible: visitors hit a full-page red warning before they can even reach your site, and search engines will typically demote or remove flagged pages. What makes this check worth doing even when you're confident nothing is wrong is that a compromise often doesn't look like anything from the owner's own browser. Attackers frequently use cloaking - serving the malicious content only to certain visitors, such as search crawlers or users from specific countries - while the owner logging in normally sees nothing unusual at all. You can check any site directly at transparencyreport.google.com, and it's worth doing periodically rather than only when something already feels wrong, since the first sign of a real infection is often the blocklist flag itself, not anything visible on the site.

6. Or check all of it at once

Running through the checks above manually - an SSL checker, a header scanner, a DNS lookup for each email record, a version audit, a Safe Browsing lookup - is realistic to do once, but keeping it current across every page and every DNS change is a lot to track by hand. The AuditHQ security suite runs all of it in a single pass: SSL/TLS configuration, the full header set, SPF/DKIM/DMARC verified through live DNS lookups rather than a cached scan, CMS and plugin version exposure, Safe Browsing status, and known CVEs cross-referenced against the NIST vulnerability database. Rather than handing back a raw list of technical findings, it explains what each one actually means in plain English and what to change to fix it, ranked so you know what to act on first. The free quick scan samples across this in about 60 seconds if you want a sense of where you stand before committing to anything further.

Frequently asked questions