Skip to content
Menu
Log in Create account

WordPress security check without logging in

See what your WordPress site shows to anyone on the internet: the core version, plugins your pages load, XML-RPC, a public debug log and author pages that give away login names. Nothing to install, no admin password.

How we recognise a WordPress site

WordPress leaves clear marks in public pages: paths with wp-content/ and wp-includes/, links to /wp-json/, a generator meta tag, block classes in the HTML and WordPress cookies. When enough of these signs are present, the WordPress checks below run on top of the general checks every site gets.

If a site hides these marks well, for example behind a separate front end, we may not recognise WordPress, and the checks on this page do not run. The general checks still work as usual: headers, certificate, mail, exposed files and any software versions visible from outside.

What the WordPress security check looks at

Check What we request Why it matters
Core version The generator tag on the homepage and /readme.html An old core may have known flaws; a public readme often shows the version
Plugins Plugin paths and ?ver= numbers in the homepage; readme.txt of five common plugins Outdated plugins are a common way in; a version lets us look up known issues
XML-RPC /xmlrpc.php A frequent target of password guessing; turn it off if you do not use it
Debug log /wp-content/debug.log If it downloads, it shows file paths and error details to anyone
Author pages /?author=1 May reveal a login name, which makes password guessing easier

The five plugin readme files we try belong to Slider Revolution, Elementor, WooCommerce, Contact Form 7 and Wordfence. A public wp-login.php is normal and is not flagged.

Versions and known issues

For WordPress core we show whether the detected version is still the current release. For core and a short list of popular plugins (WooCommerce, Elementor, Yoast SEO, Contact Form 7, WP Super Cache and Jetpack) we also look up public advisories by version. For other plugins the report lists what it found, with a version where one is visible.

A version read from a ?ver= number or a readme file is a hint, not a certainty. That is why a match is worded as “potentially affected”, never as “vulnerable”.

Plus the checks every site gets

A WordPress site also gets the full external check: security headers, the TLS certificate, mail records, outdated software such as PHP, and a search for files that should never be public, such as backups, .env files, a .git folder or database tools like phpMyAdmin and Adminer.

What to do with the results

  • A public debug.log: delete it, block access to it and turn off WP_DEBUG on the live site. The WordPress handbook advises against debug tools on live sites.
  • Old core, plugins or themes: update them, and remove plugins you do not use.
  • xmlrpc.php: if no app or service needs it, disable it. If you need it, rate-limit it at the server or CDN, together with wp-login.php.
  • Author pages that reveal a login: make sure no account uses a guessable name such as admin, and use strong, unique passwords.
  • A version in the generator tag or readme.html: removing it is tidy, but it is not protection. WordPress calls security through obscurity an unsound primary strategy.

What this check does not do

  • It does not log in, install anything or read your admin area. Plugins that leave no trace on the homepage, inactive plugins and theme versions stay invisible.
  • It does not guess passwords, call XML-RPC methods or run exploits. It only requests the addresses listed above.
  • It has no WordPress vulnerability database of its own. Advisories come from public sources and cover core and a short list of plugins.
  • A matched version is a reason to check, not a confirmed vulnerability, and a hidden version is not proof that the site is up to date.
  • It does not scan for malware or check blocklists.

Questions

Do I need to install a plugin or give you admin access?

No. The check works from outside, like a visitor’s browser, and needs only your site address.

Is a public wp-login.php a problem?

No, every WordPress site has one. What matters is how it is protected: strong passwords, no guessable account names and rate limiting on wp-login.php and xmlrpc.php.

We hid the WordPress version. Are we safe now?

Hiding the version makes a scan a little harder, but it changes nothing in the code that runs. Keeping core, plugins and themes updated is what closes known issues.

How is this different from a security plugin inside WordPress?

A plugin in your admin area can see every installed plugin and file. We see only what the public site shows, which is also what an attacker sees first. The two views complement each other.

Sources

  1. WordPress: Hardening WordPress developer.wordpress.org
  2. WordPress: Brute force attacks developer.wordpress.org
  3. WordPress: Debugging in WordPress developer.wordpress.org

Check your WordPress site

Enter your site address. If we recognise WordPress, the report shows the WordPress findings next to the general results. Free, no sign-up, read-only.

Only check sites you own or are allowed to test. How our scanner works