What the check measures, and what it doesn’t
The check looks at what an attacker sees from the outside in the first minute. It doesn’t break in, try passwords or hunt for hidden files. So the score reflects your site’s external security hygiene, not whether it can definitely be hacked.
The checks
| What we look at | How | Weight |
|---|---|---|
| HTTPS redirect | Whether http:// sends visitors to the https:// version. | serious |
| Certificate | Present, valid, and not expiring within 14 days. | critical / medium |
| HSTS, Content-Security-Policy, clickjacking protection | Protective headers for the browser. | medium |
| X-Content-Type-Options, Referrer-Policy, Permissions-Policy | Lower-weight protective headers. | minor |
| Server version | Whether the server or PHP advertises its exact version. | medium |
| WordPress version | We match the visible version against the official wordpress.org list: known security flaws, outdated, or current. | serious / medium / minor |
| WordPress plugins | We compare plugin versions referenced in the source with the latest wordpress.org release. We only flag a plugin when the major or minor version is behind. | medium |
| Known vulnerabilities | We look up the visible versions of WordPress core, plugins and theme in the Wordfence Intelligence database (updated daily). Every finding links to its record. | serious |
| jQuery | We look up the visible version in the public OSV.dev vulnerability database. | serious |
| Login page and XML-RPC | One plain request, as a browser would make. We never try a password. | medium |
| Mixed content, cookies, exposed email addresses | What the home page source gives away. | medium / minor |
| SPF and DMARC | Public DNS records that stop spoofed email. | medium |
| security.txt | Whether people who find a flaw have someone to contact. | minor |
How the score works
We start from 100 and deduct for each issue: critical 30, serious 14, medium 7, minor 2. The lowest possible score is 3. We set the weights based on the likely impact of each issue and calibrated them on 151 real websites.
What the check can’t see
- Weak or leaked passwords, and whether two-factor login is on.
- Bugs in server-side code (such as SQL injection), because that needs active testing.
- Plugins that leave no trace in the home page source.
- The state of hosting, backups and update routines.
We only look at these in a deeper review, with the verified owner’s permission.
When a firewall sits in front of the site
If Cloudflare, Sucuri or another firewall blocks us, we mark the affected checks “not measurable” and don’t deduct for them. The result is then partial: we don’t give a score, only show what we could actually see.
Same site, same result
We keep each domain’s result for 24 hours, so anyone who checks again sees the same score, with the time it was measured. Anything that still doesn’t answer after one retry is marked “not measurable”, not as an issue. When a site runs on several servers, we always ask the same one. We test repeatability by measuring the whole sample twice in a row and comparing the two runs.
Data sources
- The official wordpress.org version list (WordPress core and plugins)
- The Wordfence Intelligence vulnerability database (WordPress core, plugins, themes; records used under the Defiant Inc. and MITRE copyright terms, credited on every finding)
- The public OSV.dev vulnerability database (JavaScript libraries)
- Public DNS records and the website’s own response
What we compare against
The “better than X%” line is based on real results from 151 Hungarian and British websites, measured with this same check (2026-10-22). The sample includes small businesses, online shops, restaurants, banks, news sites and public bodies; big brands are over-represented, so the small-business average is probably lower. Partial results from behind firewalls are left out. We don’t show the line until at least 100 sites have been measured.
Legal basis
The check only reads public data, the same as a browser. We never run active tests (password guessing, attack patterns, hunting for hidden files), because doing so without permission would be unlawful (Computer Misuse Act 1990, Hungarian Criminal Code s. 423).