WordPress Security Checker
Enter a WordPress site you own and get a security grade from A to F. The scan checks updates, exposed config backups and logs, public usernames, XML-RPC, open registration, headers and cookies, then gives a fix for each finding.
- Passive, read-only checks
- Graded A to F with fixes
- No file contents ever shown
Check one layer in depth with the WordPress Version Checker or the Security Headers Checker.
The weaknesses a passive scan can see
Each check is a request any visitor's browser could make. Nothing is attacked, and no password is ever tried.
Updates
WordPress core, plugins and themes, judged against WordPress.org: outdated, insecure or not updated in two years.
Exposed files
wp-config backups, .env, .git, database dumps, debug.log and open directory listings, the leaks behind many real hacks.
Users and login
Usernames visible through the REST API, author pages and sitemaps, plus XML-RPC and open registration.
HTTPS and headers
HTTPS and redirect, HSTS, CSP, framing and nosniff headers, and Secure, HttpOnly and SameSite cookie flags.
What it gives away
A public WordPress version, PHP errors printed on the page and mixed content.
What stands in front
A firewall or security plugin, detected from headers and plugin files where they are visible.
How findings are rated
Ratings follow how easily a problem is abused and how much it exposes.
| Severity | Meaning | Example |
|---|---|---|
| Critical | Secrets or full control are exposed right now. | A downloadable wp-config.php.bak, a .env file, an open installer. |
| High | A serious gap that attackers actively use. | Several outdated plugins, a public debug.log. |
| Medium | A real weakness that helps an attacker. | Public usernames, XML-RPC on, open registration. |
| Low and Note | Hardening and housekeeping. | A public version number, a missing Permissions-Policy. |
How to scan and fix a WordPress site
From a URL to a to-do list.
Confirm it's your site
Tick the box to confirm you own the site or have permission to test it, then enter the address.
Read the findings
Critical items come first. Each one explains the risk in plain words and how to fix it.
Apply the fixes and re-scan
Copy the snippet for your server, deploy, and run the check again to see the grade rise.
What a passive scan cannot do
A clean result is good news, not a guarantee.
Not a malware scan
It does not read your files or database, so it can't tell you whether a site is already infected.
Passwords are out of scope
Weak or reused passwords are a top cause of hacks and can't be seen from outside. Use strong passwords and two-factor sign-in.
Plugin code flaws
Without a public version, a flaw inside a plugin can't be matched. Keep every plugin updated.
Server-side settings
File permissions, PHP settings and database rules live on the server and stay invisible from outside.
Firewalls can hide things
A web application firewall may block the probe, which is good, but it also means some checks can't be confirmed.
Only scan what you own
Run it on your own sites or with written permission. The checks are gentle, but permission still matters.
What a WordPress security checker does and what it cannot do
WordPress is built to be extended, and every theme and plugin is extra code that someone has to keep updated. Most weaknesses on a WordPress site are ordinary ones: an out-of-date plugin, a backup file left in the web root, a debug log anyone can open, or a login that can be tried over and over. They are not exotic, and many can be seen from outside without any special access.
A WordPress security checker looks for exactly those outside-visible weaknesses. This one runs passive, read-only checks: about thirty well-known addresses requested once each, the way a browser or search engine could. It checks core, plugin and theme versions against WordPress.org, files that should never be public, exposed usernames, XML-RPC, open registration, directory listings, security headers, cookies and HTTPS. Each finding has a severity and a fix, and the result is graded from A to F.
It is important to be clear about the limits. The tool does not read your files or database, does not try passwords and does not send exploits, so it cannot tell you whether a site is already infected, and it cannot see weak passwords, server settings or flaws inside plugin code. A good grade means the passive checks found nothing, not that the site is secure. WordPress's own hardening guide covers the wider practice. Only scan sites you own or have permission to test.
When to run a WordPress security check
Run it on your own sites, or with written permission, after any change that could bring back an old file or setting.
When you take over a site
Get a first list of visible problems on a WordPress site you have just inherited: old backups, outdated plugins, open registration and public usernames, before you change anything.
After a migration or new host
A move can restore a file you had deleted, turn directory listing back on or change which headers are sent. Re-scan the new environment, not just the old one.
Before launching a new site
Check that debug output is off, no config backups are public and the version is not needlessly exposed. A staging copy that went live by accident often still has these.
After a big plugin or theme change
New plugins can add exposed endpoints and old ones can stop receiving updates. Check which items are flagged as outdated or abandoned.
As a monthly routine
Passive checks are quick, so they suit a regular schedule. Compare each grade with the last one to see whether a change quietly weakened the site.
As a first step in a security review
Use the findings as a to-do list for the easy wins, and then follow up with checks the tool cannot do: malware scanning, password policy and server hardening.
WordPress security mistakes and how to fix them
Most of these are leftovers: files, plugins and settings nobody went back to remove.
Leaving backups and config copies in the web root
What goes wrong: Files such as wp-config.php.bak, .env, a .git folder or a backup.zip can be downloaded by anyone who guesses the name. They often hold database passwords and keys.
The fix: Delete them, keep backups outside the public folder, and block these file patterns in the server config. If a config file was exposed, change the database password and the secret keys.
Debug mode left on
What goes wrong: With WP_DEBUG display on, PHP errors and file paths print on the page, and a public debug.log can list errors and sometimes personal data.
The fix: Turn off WP_DEBUG_DISPLAY and WP_DEBUG_LOG on live sites, delete any existing debug.log, and block access to it. Use a staging site for debugging.
Unused and abandoned plugins
What goes wrong: A deactivated plugin still sits on the server, and a plugin that is no longer maintained gets no security fixes. Either can leave a known weakness in place.
The fix: Delete plugins you do not use, as the WordPress documentation advises, remove unused themes too, and replace any that have not been updated for a long time with maintained alternatives.
Public usernames and a default login
What goes wrong: When author pages, the REST API or sitemaps reveal login names, an attacker only needs to guess the password. The default login address is a common target for automated bots.
The fix: Hide the user endpoints from visitors who are not logged in, use strong unique passwords, enable two-factor sign-in and limit login attempts or filter bots at the firewall.
XML-RPC and open registration left on
What goes wrong: XML-RPC lets many password guesses be tried in one request, and open registration invites spam and fake accounts on sites that do not need members.
The fix: Disable XML-RPC unless an app you use needs it, and restrict it with a firewall rule if you do. Turn off Anyone can register under Settings, General when you do not run a membership site.
Hiding the version instead of updating
What goes wrong: Removing the version number can make a site slightly harder to fingerprint, but it does not close a hole. WordPress says security through obscurity is generally an unsound primary strategy.
The fix: Update core, plugins and themes first, with a backup. Treat hiding the version as an optional extra that comes after you are current.
WordPress security terms explained
- Passive scan
- A check that only requests public addresses and reads the responses, the way any visitor's browser could. It does not log in, try passwords, send exploits or change anything on the site.
- wp-config.php
- The WordPress configuration file. It holds the database name, user and password and the secret keys, so no copy of it should ever be downloadable from the web.
- XML-RPC
- An older WordPress remote-access interface at
xmlrpc.php, used by some apps and plugins. It can be abused to try many passwords in one request, so disable it if you do not use it. - REST API
- WordPress's JSON interface, available under
/wp-json/. Depending on settings, its users route can list author names, which is why the checker looks at it. - User enumeration
- Finding valid usernames through author archives, the REST API, sitemaps or login error messages. It does not break in on its own, but it removes half of the guesswork in a password attack.
- Directory listing
- A server setting that shows a browsable list of files when a folder has no index file. It can expose uploads, plugin files and backups that were never meant to be listed.
- Web application firewall (WAF)
- A filter in front of a site that blocks suspicious requests, such as repeated login attempts. It can be a plugin, a host feature or a CDN service, and it may stop some checks from completing.
- Brute-force attack
- Repeated automated guessing of passwords against a login. Strong unique passwords, two-factor sign-in and rate limiting are the standard defences.
Related tools, guides and services
Security works in layers. These tools check the other ones.
WordPress Version Checker
Find the WordPress version from six signals and see whether WordPress.org marks it outdated or insecure.
ToolWordPress Theme & Plugin Detector
List visible themes and plugins and check each against WordPress.org for updates and abandonment.
ToolSecurity Headers Checker
Grade HSTS, CSP and framing headers, with config you can copy for your server.
ToolSSL Certificate Checker
Check certificate expiry, names covered and the https redirect for the same site.
ToolWebsite Health Check
Add speed, crawlability and on-page basics to the picture in one scored report.
ServiceSEO audit service
Get a prioritised audit of the technical issues that affect how your site performs in search.
Built by
Madhav Kushwaha
Most WordPress hacks start with something simple: an outdated plugin, a forgotten backup file, or a login that anyone can try. I built this checker around those real causes, kept it passive and honest about its limits, and wrote a fix for every finding so the report is a to-do list rather than a scare.
WordPress Security Checker: Frequently Asked Questions
More free SEO tools
Security is layered. These tools check each layer.