What Does a Website Security Scan Check?

You know your website needs to be secure. But what does that actually mean in practice? And what does a security scan check for?

A website security scan is an automated inspection of your site's publicly visible security configuration. It looks at your SSL certificate, your HTTP headers, your software versions and more. It reports what's properly configured, what's missing and what's actively dangerous.

This guide explains what each check does, why it matters and what the results mean.

What a security scan actually does

A security scan visits your website the same way a regular visitor does. It loads your pages in a browser, reads the HTTP responses and checks the publicly available configuration. That's it.

A reputable scanner does not:

• Log into your site or access admin areas
• Modify any content or inject code
• Test passwords or attempt to break in
• Access private files or databases
• Send traffic that could harm your server

It's read-only. The scan sees exactly what any visitor to your site can see. The difference is that a scanner knows what to look for and checks dozens of things in seconds that would take you hours to verify manually.

This is important to understand because some people confuse a security scan with a penetration test. A penetration test actively tries to break into your system. A security scan just reads what's already visible and tells you where your configuration is weak.

SSL/TLS certificate checks

The first thing any scanner checks is your SSL certificate. This is the foundation of website security. Without it, everything between your visitors and your server is sent as plain text.

A thorough SSL check looks at several things:

Certificate validity. Is your certificate current, or has it expired? An expired certificate triggers a full-page browser warning that sends visitors running. Let's Encrypt certificates expire every 90 days, so auto-renewal is critical.

Certificate chain. Your certificate is part of a chain of trust that leads back to a root certificate authority. If any link in that chain is missing or broken, browsers won't trust your certificate even if it's technically valid.

Protocol versions. TLS has gone through several versions. TLS 1.0 and 1.1 have known vulnerabilities and are deprecated. Your server should support TLS 1.2 and 1.3 only. A scan flags servers still accepting old protocol versions.

Cipher suites. Even with TLS 1.2, some encryption algorithms are weaker than others. A good scan checks that your server uses strong cipher suites and rejects weak ones.

Certificate mismatch. Your certificate must match your domain. A certificate for www.example.com doesn't cover example.com without the www, and vice versa. This is a surprisingly common misconfiguration.

If you want a deeper dive into how SSL works and how to get a free certificate, read our SSL certificate guide.

HTTP security headers

Security headers are instructions your server sends to the browser along with every page. They control what the browser is allowed to do, and they're one of the most commonly missing security features on small business websites.

Here are the headers a scan checks:

Content-Security-Policy (CSP). This tells the browser which sources it's allowed to load scripts, stylesheets, images and other resources from. Without CSP, an attacker who finds a way to inject content into your page can load malicious scripts from anywhere. CSP is the single most effective header against cross-site scripting (XSS) attacks.

Strict-Transport-Security (HSTS). This tells browsers to always use HTTPS when connecting to your site, even if someone types http:// manually. Without HSTS, a first visit over HTTP could be intercepted before the redirect to HTTPS happens.

X-Frame-Options. This prevents other websites from embedding your site in an iframe. Without it, attackers can overlay invisible frames on top of your content to trick visitors into clicking things they didn't intend to. This is called clickjacking.

X-Content-Type-Options. Browsers sometimes try to guess the type of a file by looking at its content. This guessing can be exploited to make a browser execute a file that should be treated as data. The nosniff directive stops this behaviour.

Referrer-Policy. When visitors click a link from your site to another site, the browser sends a referrer header saying where they came from. This can leak sensitive information if your URLs contain tokens or user IDs. A proper referrer policy limits what gets shared.

Permissions-Policy. This controls which browser features your site can use: camera, microphone, geolocation, payment APIs. If you don't use a feature, disabling it through this header prevents any injected script from using it either.

Most small business websites are missing at least three of these headers. The fix is usually a few lines in your server configuration or a plugin. Our free security headers tool shows exactly which headers you're missing.

CMS and plugin vulnerability detection

Outdated software is the number one way small business websites get compromised. Not sophisticated zero-day exploits. Just known vulnerabilities in software that wasn't updated.

A security scan detects your CMS (WordPress, Joomla, Drupal, Shopify, etc.) and checks the version against known vulnerability databases. It does the same for detectable plugins, themes and JavaScript libraries.

What the scan looks for:

• CMS version exposure. WordPress adds a meta tag and feeds that reveal the exact version. Many themes do the same. If you're running WordPress 6.3 and the latest is 6.5, the scan flags that gap.
• Known vulnerable plugins. Public databases like WPScan and the National Vulnerability Database (NVD) track thousands of plugin vulnerabilities. If a scan detects a plugin with a known CVE, it flags it with the specific risk.
• Outdated JavaScript libraries. Many sites load old versions of jQuery, Bootstrap or other front-end libraries with known vulnerabilities. These are visible in the page source and easy to detect.
• Abandoned software. A plugin that hasn't been updated in two years is a risk even without a known vulnerability. It means nobody is watching for security issues.

This matters because attackers automate their work. Bots constantly scan the internet for sites running known vulnerable versions. They don't target you specifically. They target everyone running the same outdated plugin.

For more on this, read our guide on vulnerable WordPress plugins.

Mixed content detection

Mixed content happens when your site loads over HTTPS, but some resources on the page (images, scripts, stylesheets) still load over HTTP. This breaks the security chain.

There are two types:

Passive mixed content is when images, videos or audio load over HTTP. Browsers usually load these but remove the padlock icon or show a warning. The resources themselves could be tampered with in transit.

Active mixed content is when scripts or stylesheets load over HTTP. This is dangerous because a script loaded over an insecure connection could be modified to do anything: steal form data, redirect visitors, inject ads. Browsers block active mixed content by default.

A security scan checks every resource loaded on your pages and flags anything loading over HTTP. The fix is updating the URLs to HTTPS. In WordPress, this usually means running a search-and-replace on your database to change http:// to https:// for your own domain.

Email authentication checks

Your website and your email share a domain. A comprehensive security scan also checks your email authentication records because a compromised email identity can damage your business reputation and violate data protection rules.

The three records a scan checks:

SPF (Sender Policy Framework). A DNS record that lists which mail servers are allowed to send email from your domain. Without it, anyone can send emails that appear to come from your address.

DKIM (DomainKeys Identified Mail). A digital signature on each email that proves it hasn't been tampered with in transit. The receiving server can verify the signature using a public key in your DNS records.

DMARC (Domain-based Message Authentication, Reporting and Conformance). A policy that tells receiving servers what to do when SPF or DKIM checks fail. Without DMARC, failed checks might still result in the email being delivered.

Missing email authentication records mean your domain can be spoofed for phishing attacks. It also means your legitimate emails are more likely to land in spam. Since 2024, Google requires at least SPF or DKIM for all senders and all three for bulk senders.

For a full walkthrough on setting these up, read our SPF, DKIM and DMARC guide.

What the results mean: scoring and severity

A raw list of technical findings isn't very useful if you don't know what to fix first. That's why a good scanner scores and prioritises the results.

Our scanner uses four severity levels:

Critical. Your site has an active security vulnerability that could be exploited right now. Examples: an expired SSL certificate, a plugin with a known remote code execution flaw, or no HTTPS at all. Fix these immediately.

High. A serious gap in your security configuration that makes exploitation significantly easier. Examples: missing HSTS header, TLS 1.0 still enabled, or a DMARC record set to none (monitor only). Fix these within a week.

Medium. A missing safeguard that best practice recommends. Examples: no Content-Security-Policy header, missing X-Frame-Options, or a weak referrer policy. These don't expose you to immediate attack but leave doors open. Fix these within a month.

Low. Minor configuration issues. Examples: missing Permissions-Policy header or an SSL certificate close to expiry with auto-renewal active. Address these when convenient.

The overall score starts at 100 and deductions are weighted by severity. A site with one critical finding and perfect configuration everywhere else will still score poorly, because it should. The critical finding is what matters.

How our scanner differs from generic tools

Generic security scanners (SSL Labs, SecurityHeaders.com, Mozilla Observatory) each check one thing well. They're useful, but they give you fragments. You end up with five different tools, five different reports and no clear picture of where you actually stand.

Our scanner combines these checks into one scan and adds something generic tools miss: compliance context.

For EU small businesses, security isn't just about preventing hacks. It's about legal obligations. The GDPR requires "appropriate technical and organisational measures" to protect personal data. The upcoming NIS2 directive extends security requirements further.

When our scanner flags a missing HSTS header, it doesn't just say "header missing." It explains that browsers may not enforce HTTPS for repeat visitors, that form data could be intercepted on the first visit, and that this matters for GDPR Article 32 compliance.

This compliance focus is the difference between a scan that tells you what's wrong and one that tells you why it matters for your business.

For a broader look at what you should have in place, check our security checklist for small businesses. And if you've already seen the "Not Secure" warning, start with our guide to fixing it.

What a security scan cannot catch

A security scan is powerful, but it has limits. Understanding those limits is important so you don't get a false sense of security from a clean report.

Server-side configuration. A scan can't see your server's firewall rules, file permissions or whether your admin panel is protected. It can only check what's visible from the outside.

Application logic flaws. If your contact form saves data to an insecure database or your checkout process has a race condition, no external scan will find it. These require code review or a penetration test.

Access control issues. A scan can't tell whether your WordPress admin uses a strong password or whether your hosting account has two-factor authentication enabled.

Internal network security. Anything behind your firewall is invisible to an external scan. If your database is accessible from the public internet, a scan might detect it, but most internal misconfigurations won't show up.

Zero-day vulnerabilities. A scan checks against known vulnerability databases. If a vulnerability hasn't been publicly disclosed yet, no automated tool will find it.

A security scan catches the low-hanging fruit. And for most small business websites, the low-hanging fruit is where the actual risk is. You're far more likely to be compromised by an expired certificate or an outdated plugin than by a sophisticated zero-day attack.

Scan your site now

You don't need to check all of this manually. Run a free scan on your website and get a clear report covering SSL, security headers, software versions, mixed content and email authentication. You'll know exactly where you stand in under a minute.

FAQ

What does a website security scan check?

A security scan checks your SSL certificate, HTTP security headers, CMS and plugin versions, known vulnerabilities, mixed content, and exposed sensitive files. Some scanners also check email authentication (SPF, DKIM, DMARC).

Is a website security scan safe to run?

Yes. A reputable scanner only reads publicly available information. It doesn't modify your website, inject code, or access private areas. It's the same information any visitor can see.

How often should I scan my website?

After every change (new plugin, theme update, server migration) and at least monthly. New vulnerabilities are discovered daily, and your site's security posture can change without you doing anything.

Do I need a penetration test or just a security scan?

For most small business websites, a security scan covers the risks that matter. Penetration testing is expensive and targets application-specific vulnerabilities. Get your scan results clean first. If you handle sensitive data at scale (payments, health records, financial data), consider a pentest later.

Can a security scan slow down my website?

No. A scan sends the same requests a normal visitor would. It loads your pages, reads the responses and moves on. There's no noticeable impact on your server performance.