WordPress security check

1. Type your site’s address. example.com is enough; a path after the domain is ignored, because only the homepage and a few standard WordPress addresses get checked.
2. Tick the box: it has to be your site, or one you have written permission to test.
3. Press Scan. It takes a few seconds and sends at most 32 requests, all of them plain GET or HEAD.
4. Fix the red rows first. Each says what was found and what to change, with a link to the part of the checklist that explains why.
5. Then go through What a scan can’t see: backups, passwords, updates. That list is most of the real work.

Most WordPress break-ins are not clever. A bot takes a list of known weak spots and tries it on thousands of sites. This tool asks the questions that bot asks, so you see your site the way it does: are your usernames listed at /wp-json/wp/v2/users, does xmlrpc.php answer, does the page announce which WordPress version it runs, and is that version (or any plugin or theme the page loads) on a list of known vulnerabilities, are backups or a .env lying in the web root, is the uploads folder browsable, is the site on HTTPS with a valid certificate, are the basic security headers set.

It is passive on purpose. It only reads what the site shows any visitor: no logging in, no password guessing, no exploit payloads, no POST to XML-RPC, no downloading of wp-config.php or backups: leftover files are asked about with HEAD, which returns only the headers. A site that passes is not “secure”. It just has no obvious door open to the street.

Why it needs a server when the other tools here don’t: a browser is not allowed to read another site’s response headers, and headers are half of what gets checked. So the address goes to a small scanner on this site. It refuses private and internal addresses, checks every redirect again before following it, stops each scan at 32 requests or 30 seconds, and allows a few scans a minute per visitor, a few per site every ten minutes, and a small number per day in total. Asking about the same site again within five minutes shows the same report instead of scanning it again. Each scan leaves one log line (time, your IP address, the site and the score) so abuse can be spotted; it sits with the server’s other logs, which rotate away. For the vulnerability rows it reads each plugin’s public readme.txt for the installed version, then asks the free WPVulnerability database about that plugin and version; your address is not part of that question.

The score starts at 100 and loses points for what is found: 25 for public usernames or a downloadable backup, .env or config copy, up to 20 for each vulnerable plugin and 15 for a vulnerable core, 10 each for XML-RPC, a browsable uploads folder, a visible version, no HTTPS or a bad certificate, and a few for missing headers and chatty server banners. 85 and up is a good baseline, 65 to 84 needs attention, below that fix the open doors first. The reasoning behind every row, and everything a scan can’t see, is in the WordPress security checklist.