Fingerprinting
Whether your exact WordPress version, plugins and themes are advertised through the generator tag, readme.html and asset version strings - the shortlist an attacker starts from.
WordPress runs a huge share of the web, which makes it a huge target. Out of the box it advertises its version, lists your users, and leaves risky endpoints open. Audit yours and get a plain-English grade.
We'll harden your WordPress site and keep it that way.
Enter a site and run the audit to see its grade and a card-by-card breakdown of every WordPress exposure check.
Whether your exact WordPress version, plugins and themes are advertised through the generator tag, readme.html and asset version strings - the shortlist an attacker starts from.
User enumeration via the wp-json REST API, a reachable xmlrpc.php, a browsable uploads directory, and the default login page - the surfaces automated attacks probe first.
HTTPS enforcement (does plain HTTP redirect up?) and the core security headers WordPress ships without: CSP, HSTS, nosniff and clickjacking protection.
Your site gives away little. Versions are hidden, the REST users route is restricted, and the risky endpoints are blocked. Keep plugins patched and you stay here.
The basics work but several details are handed out for free - an exposed version, a reachable xmlrpc, or leaked plugin versions. Each is a quick fix worth making.
The site leaks the information an attacker needs to target it - enumerable users, an open uploads index, or no security headers at all. Worth hardening promptly.
When you run the audit, our server fetches a fixed set of public URLs from your site - the homepage, readme.html, xmlrpc.php, the wp-json users route, the uploads directory and the login page - and reads only what any visitor would see. It never logs in, never submits anything, never runs an exploit, and never changes a thing. Then it grades what it found and shows you the fix for each gap.
Yes. The audit fetches a handful of public URLs from our server and reads only what any visitor could already see - the homepage, readme.html, xmlrpc.php, the wp-json users route, the uploads directory and the login page. It never logs in, submits a form, runs an exploit, or changes anything. It is read-only reconnaissance of your own public surface.
No. The audit runs once, returns the grade to your browser, and keeps nothing. There is no account, no history, and no report saved on our side.
That is usually a good sign. If your site is behind a strong cache or CDN, or has been hardened to strip the generator tag and block readme.html, xmlrpc.php and the REST users route, then the WordPress markers we look for are hidden - which is exactly what hardening does. We would rather report 'not detected' than guess.
Some are signals, not proof. A reachable wp-login.php or xmlrpc.php is a hardening gap that invites automated attacks, but it is not a confirmed vulnerability on its own - plenty of healthy sites leave them open. We label those as signals in the results so you can weigh them, rather than crying wolf.
Each check is weighted by how much it matters, and the weights sum to 100 so the score is the point total. Version and user exposure carry the most weight; the login-page signal the least. The score maps to an A-F grade on the same bands as our security-headers tool, so the two feel consistent.
Each result card has a plain-English 'what it is' and 'why it matters' explainer with the fix - hide the version, restrict the REST users route, block xmlrpc.php, turn off directory listing, and add the missing security headers. If you would rather it was handled and kept that way, that is what our managed IT does.
A monthly digest on WordPress hardening, the Essential Eight, and practical security for Australian SMBs. No spam, unsubscribe anytime.