Checker › Guides › Reading a Website Security Scan
How to read a website security scan without being a pentester
A website security test ends with two things: a score and a findings list. The score gets the attention; the findings list is where the value is. This guide teaches you to read the list like an owner, not an engineer — what each severity really means, how the score was built from it, and how to turn it into a fix order. (SiteCredly's own tool is the disclosure checker hub; this guide is about the security-scan reports other tools hand you.)
The four severities, translated
| Severity | Plain meaning | Example findings | Triage weight |
|---|---|---|---|
| Critical | Exploitable now, by a stranger, with public tools | Exposed admin login with default password; component with a known active exploit | 10 |
| High | A real door is open, even if walking through takes skill | No TLS on a login page; outdated CMS with published vulnerabilities; exposed backup file | 5 |
| Medium | Weakens your position; rarely a break-in by itself | Missing security headers; verbose server banners; weak cookie flags | 2 |
| Low | Hygiene. Worth fixing in a batch, never the headline | Directory listing on an empty folder; outdated copyright year next to a version string | 1 |
The weights in the last column are this guide's triage weighting — deliberately simple, shown in the open, and used by the calculator below. Vendors weight differently; the ordering instinct (criticals first, hygiene last) is universal.
Anatomy of a findings list
Every finding in a competent report answers four questions: what is wrong, where (the URL or component), why it matters (the attack it enables), and how to fix it. If your report gives you only the first two, you don't have a report — you have a riddle, and you should ask the scanner for the rest. To see the standard a full report is held to, read what a professional website security assessment actually tests, category by category.
A worked example — one line from a typical small-business report, annotated:
[HIGH] Outdated component — WordPress 5.8 (current: 6.x) at /wp-login.php
What: the CMS version is years behind. Why it matters: every version between yours and current shipped security fixes; the list of known exploits for your exact version is public. Fix: back up, update core + plugins, re-scan. Owner translation: this is not “tech debt.” It is the single most common way small sites get breached, and the fix is an afternoon.
Triage calculator — turn your report into a fix order
Count the findings in your report by severity and enter them here. The weighted total tells you which mode you're in.
Weighted risk points: 0. No findings entered.
Bands: 1–9 low · 10–24 moderate · 25–49 high · 50+ incident territory. Any single critical finding deserves same-week action regardless of the total.
The score is a summary, not a verdict
Two scanners can grade the same site a B and a D, and both be “right” under their own weights. What cannot differ honestly is the findings list itself. So when you compare tools — or argue with one — argue about findings: is this real, is it exploitable, is it fixed now? A scan you re-run after fixes should show the same findings gone, and that before/after list is the only scoreboard worth framing.
Frequently asked questions
What does a critical finding in a website security scan mean?
A critical finding is an issue an attacker can exploit today with little effort — for example an exposed admin panel or a known-vulnerable component. In this guide's triage weighting it counts 10 points, and any single critical puts the site in incident territory until fixed.
How is a scan score usually calculated?
Most scanners start from a perfect score and subtract per finding, weighted by severity. The exact weights vary by vendor, which is why two scanners can grade the same site differently — always compare the findings list, not just the letter grade.
What should I fix first after a scan?
Fix in severity order, but start with anything internet-facing and exploitable: exposed dashboards, outdated components with known exploits, and missing TLS. Cosmetic findings like missing security headers matter, but they come after the doors that are actually open.
How often should a small website be scanned?
After every significant change — a redesign, a new plugin, a new integration — and on a regular cadence in between. Monthly is a sane default for a small business site; the scan is cheap, and the findings list is your patch queue.
Reading reports is step two. Step one is having one — a full scan covers the pages, components and configurations a quick test can't reach.
Get the full website scan Get a full disclosure auditRelated: Is your home network the weak link? — the same severity thinking, applied to the network your business runs on at home.