Best Website Scan Tool: Match the Scanner to the Job (2026)

The best website scan tool is the one built for the problem you are trying to find. Vulnerability scanners (DAST) probe for exploitable flaws such as SQL injection. Malware scanners look for injected code and blocklist status. Configuration scanners check HTTPS, TLS and security headers. Website audit scanners find SEO, speed, accessibility and broken-page bugs. No single scanner does all four well.

"Website scan" means very different things to a security engineer, a WordPress site owner and an SEO manager. Search for it and you get lists that mix all three, which is how teams end up running a malware checker and assuming their site is "fine" while its mobile pages fail Core Web Vitals and its CSP allows inline scripts.

This guide sorts website scanners by what they actually detect. It includes passive scan results from eight real production sites, a free Python scanner you can run safely against any site, and a decision framework for choosing a stack.

The 4 Types of Website Scan Tools

Every website scanner falls into one of four categories, defined by how it interacts with your site and what class of problem it finds.

⚠️ Legal note: Only run an active vulnerability scanner against sites you own or have written permission to test. Sending attack payloads to someone else's site can breach computer misuse laws, even if your intent is harmless. Passive configuration and audit scans read only what any browser receives.

Real Data: Passive Security Scans of 8 Production Sites

We ran the passive scanner from the next section against eight public homepages on 1 October 2026: bugviso.com, gov.uk, wordpress.org, and five well-known SaaS companies (anonymised as SaaS 1–5). It makes three ordinary requests per site and sends no attack traffic.

⚠️ = the header is present, so a presence-only scanner passes it, but its value is weak (details below). SaaS 4 also lacked X-Content-Type-Options and sent an X-Powered-By header naming its framework. wordpress.org also lacked X-Content-Type-Options and Referrer-Policy, and SaaS 5 lacked Referrer-Policy.

What the Data Shows

HTTPS and modern TLS are now universal. All eight sites redirected HTTP to HTTPS and negotiated TLS 1.3. A scanner that only checks for a padlock tells you almost nothing in 2026.

Permissions-Policy is the most-skipped header. Six of eight sites did not send it. It restricts which browser features (camera, microphone, geolocation) the page and its embedded iframes may use, which limits the damage a compromised third-party script can do.

A header being present does not mean it is effective. This is the biggest blind spot in simple scanners:

• wordpress.org sends Strict-Transport-Security: max-age=3600. That tells browsers to remember HTTPS-only for one hour. The HSTS preload list requires at least one year (31536000).
• SaaS 2, SaaS 3 and SaaS 4 send a CSP, but each allows 'unsafe-inline' and 'unsafe-eval' in script-src without a nonce or hash. That removes most of the protection CSP offers against cross-site scripting. Half of the six sites that sent a CSP fell into this trap.

💡 Rule of thumb: A website scan tool that reports "CSP: present ✅" without reading the policy is checking a box, not your security. Ask whether it parses directive values.

Run a Passive Website Security Scan (Free Script)

This scanner is passive and safe to run against any public site. It makes one HTTP request, one HTTPS request and one TLS handshake: the same traffic as a single browser visit.

"""
scan_site.py — a passive website security scan (headers, HTTPS, TLS).

Safe to run against any public site: it makes three ordinary requests
(http://, https://, and a TLS handshake) and never probes for exploits.

Usage:
    pip install httpx
    python3 scan_site.py example.com
"""
import socket
import ssl
import sys
from datetime import datetime, timezone

import httpx

HEADERS = {
    "strict-transport-security": "HSTS",
    "content-security-policy": "CSP",
    "x-content-type-options": "X-Content-Type-Options",
    "referrer-policy": "Referrer-Policy",
    "permissions-policy": "Permissions-Policy",
}


def tls_info(host: str) -> tuple[str, int]:
    ctx = ssl.create_default_context()
    with socket.create_connection((host, 443), timeout=10) as sock:
        with ctx.wrap_socket(sock, server_hostname=host) as tls:
            cert = tls.getpeercert()
            expires = datetime.strptime(cert["notAfter"], "%b %d %H:%M:%S %Y %Z")
            days = (expires.replace(tzinfo=timezone.utc) - datetime.now(timezone.utc)).days
            return tls.version(), days


def scan(host: str) -> None:
    ua = {"User-Agent": "Mozilla/5.0 (passive-scan script)"}
    results: list[tuple[str, bool, str]] = []

    http = httpx.get(f"http://{host}", headers=ua, follow_redirects=True, timeout=15)
    results.append(("HTTP redirects to HTTPS", http.url.scheme == "https", str(http.url)))

    r = httpx.get(f"https://{host}", headers=ua, follow_redirects=True, timeout=15)
    h = {k.lower(): v for k, v in r.headers.items()}
    for key, label in HEADERS.items():
        results.append((f"{label} header", key in h, h.get(key, "missing")[:60]))

    framing = "x-frame-options" in h or "frame-ancestors" in h.get("content-security-policy", "")
    results.append(("Clickjacking protection", framing,
                    h.get("x-frame-options", "frame-ancestors" if framing else "missing")))

    leaky = h.get("x-powered-by", "")
    results.append(("No X-Powered-By version leak", not leaky, leaky or "not sent"))

    version, days = tls_info(host)
    results.append(("TLS 1.2 or newer", version in ("TLSv1.2", "TLSv1.3"), version))
    results.append(("Certificate valid > 14 days", days > 14, f"{days} days left"))

    passed = sum(ok for _, ok, _ in results)
    print(f"Passive security scan: {host}\n")
    for name, ok, detail in results:
        print(f"  {'PASS' if ok else 'FAIL'}  {name:30} {detail}")
    print(f"\n  Score: {passed}/{len(results)}")


if __name__ == "__main__":
    if len(sys.argv) != 2:
        sys.exit("Usage: python3 scan_site.py <hostname>")
    scan(sys.argv[1].removeprefix("https://").removeprefix("http://").strip("/"))

Real output for wordpress.org on the test date:

Passive security scan: wordpress.org

  PASS  HTTP redirects to HTTPS        https://wordpress.org/
  PASS  HSTS header                    max-age=3600
  FAIL  CSP header                     missing
  FAIL  X-Content-Type-Options header  missing
  FAIL  Referrer-Policy header         missing
  FAIL  Permissions-Policy header      missing
  PASS  Clickjacking protection        SAMEORIGIN
  PASS  No X-Powered-By version leak   not sent
  PASS  TLS 1.2 or newer               TLSv1.3
  PASS  Certificate valid > 14 days    82 days left

  Score: 6/10

Note that the script passes max-age=3600 as "HSTS present". That is exactly the presence-versus-strength gap described above. Extending the script to parse max-age and flag 'unsafe-inline' in script-src is a good next step.

Fixing the Most Common Gaps (Nginx)

# ❌ Before: HSTS for one hour, no CSP, no feature restrictions
add_header Strict-Transport-Security "max-age=3600";

# ✅ After: one-year HSTS, baseline headers, and a CSP without unsafe-inline scripts
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; frame-ancestors 'none'; base-uri 'self'" always;

Roll out a new CSP as Content-Security-Policy-Report-Only first and watch the reports for a week. A strict policy that blocks your analytics or payment script is a bug of its own. Our guide to security headers: CSP, HSTS and X-Frame-Options walks through a staged rollout.

Website Scan Tools Compared by Job

The scanner categories overlap less than vendor marketing suggests. Use this matrix to see which category covers each problem.

✅ = core capability · ⚠️ = partial or tool-dependent · ❌ = not designed for it

Decision Framework: Which Website Scan Tool Do You Need?

"My site might be hacked or Google shows a warning." Start with a malware and blocklist scanner, and check Google's Safe Browsing site status. If it confirms an infection, you need incident response, not more scanning.

"We handle logins, payments or user data." You need a DAST vulnerability scanner in your release process, run against staging with permission. Pair it with a periodic manual penetration test. OWASP's free ZAP is a reasonable starting point.

"I just want a quick security hygiene check." A passive configuration scanner (the script above, or MDN's HTTP Observatory) takes seconds and catches missing headers and certificate problems.

"Traffic or conversions dropped and I don't know why." That is almost never a security scanner problem. Run a website audit scanner that covers speed, SEO, accessibility and broken pages. See our best website audit tools in 2026 comparison.

"I'm an agency auditing a prospect's site." Use a passive audit scanner only. You do not have permission for active testing, and a white-label report covering speed, SEO and security hygiene is what wins the conversation.

How BugViso Scans a Website

BugViso is a website audit scanner with passive security checks built in. It is not a vulnerability scanner or a malware scanner: it never sends attack payloads, and it does not check malware signatures.

Every scan loads your site in headless Chromium, crawls it via the sitemap and rendered links, and runs these engines:

• Security checklist: tests that HTTP redirects to HTTPS, detects Content-Security-Policy, Strict-Transport-Security and X-Frame-Options, and inspects the live TLS certificate for issuer, days to expiry, negotiated protocol version and Subject Alternative Names.
• Mixed content and network health: flags http:// resources on https:// pages, failed requests, and broken internal and external links.
• Privacy & Compliance (GDPR/CCPA): categorises every cookie and third-party host seen on the un-consented page load and flags trackers that fire before consent, with consent-platform detection.
• Everything a security scanner skips: Core Web Vitals with throttled mobile simulation, a WCAG 2.1 A/AA axe-core audit, SEO and structured data validation, console errors, React hydration mismatches, visual QA and AI search readiness.

Findings are ranked by impact in one prioritised report and a branded PDF that includes AI-written fixes. The security and privacy compliance feature page lists every security check.

Common Misconceptions About Website Scanners

"A clean malware scan means the site is healthy." It means no known malware signature was found. Your site can still be slow, inaccessible, mis-indexed or leaking tracking data before consent.

"An A+ header grade means the site is secure." Headers are one layer. They say nothing about an SQL injection in your search form or a vulnerable plugin.

"More findings means a better scanner." A scanner that reports 300 issues, 200 of them false positives, costs more engineering time than one that reports 40 real issues. Test any website scan tool on a site you know is well built, such as gov.uk, and see how much noise it reports. Our website bug finder guide shows two common false positives we hit in our own testing.

"Free scanners are toys." Several of the most respected scanners (ZAP, Observatory, PageSpeed Insights) are free. Paid tools earn their price on scale, crawling, scheduling and reporting, not on basic detection.

Frequently Asked Questions

What is the best free website scan tool?

It depends on the job. For vulnerabilities, OWASP ZAP is free and open source. For security headers, MDN's HTTP Observatory is free. For a full audit of speed, SEO, accessibility and security hygiene, a BugViso scan is free and includes one full PDF report. Most teams combine two of these.

Is it legal to scan any website?

Passive scans that read public pages and response headers, as a browser does, are generally fine. Active vulnerability scans that send attack payloads should only be run on sites you own or have written authorisation to test. If in doubt, get permission in writing.

How often should I scan my website?

Run a full website audit after every production deploy and on a weekly or monthly schedule. Check certificate expiry continuously, since an expired certificate takes the whole site down. Run vulnerability scans before each major release and after adding new forms, endpoints or plugins.

Can a website scan tool find SEO problems?

Only a website audit scanner can. Security, malware and configuration scanners ignore titles, canonicals, structured data, Core Web Vitals and crawlability. For SEO, choose a scanner that renders JavaScript and crawls beyond the homepage.

What is the difference between a website scan and a website audit?

"Scan" usually describes the automated data collection: loading pages and recording what is found. "Audit" adds interpretation: prioritising findings, explaining impact and recommending fixes. Good website audit tools do both, turning raw scan data into a ranked list of fixes.

Conclusion

Pick the website scanner for the problem in front of you: DAST for exploitable code, a malware scanner for infections, a configuration scanner for headers and TLS, and a website audit scanner for everything that costs you traffic and conversions. For the last two in a single pass, a free BugViso scan covers security hygiene, speed, SEO and accessibility in about two minutes.