Interconnekt
Free Tool

What does your WordPress site give away?

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.

Beyond the audit

We'll harden your WordPress site and keep it that way.

We fetch a handful of public URLs from our server and read only what any visitor could see. We never log in, submit anything, run an exploit, or store the result.

Your results will appear here

Enter a site and run the audit to see its grade and a card-by-card breakdown of every WordPress exposure check.

What we check

The exposure a WordPress site leaks by default.

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.

Enumeration & endpoints

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.

Transport & headers

HTTPS enforcement (does plain HTTP redirect up?) and the core security headers WordPress ships without: CSP, HSTS, nosniff and clickjacking protection.

How to read it

Your grade, in plain English.

A - B

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.

C - D

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.

F

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.

How it works

Read-only, from our server.

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.

FAQ

Questions about the WordPress audit.

Is this safe to run on my site?

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.

Do you store my site or the results?

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.

It says my site isn't WordPress, but it is. Why?

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.

Are these findings proof my site is vulnerable?

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.

How is the grade calculated?

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.

My WordPress site scored badly. What do I do?

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.

Stay in the loop

Want more like this?

A monthly digest on WordPress hardening, the Essential Eight, and practical security for Australian SMBs. No spam, unsubscribe anytime.

Monthly digest and post summaries. We use Resend (United States) to deliver email. See our Privacy Policy.

Free tools
Jump to a tool