How to Test Your WordPress Site’s Security in 2026 (Free Tools and a Full Audit Checklist)

Attackers weaponize a fresh WordPress flaw in a median of five hours. By the time a plugin vulnerability lands in your inbox, the bots have usually already tried it on your site. That five-hour gap is the whole reason to test your own site instead of waiting for the bad news to find you. This guide shows you how to check a WordPress site for holes, from a 10-minute free scan to a full audit you can repeat every quarter.

Quick answer: Run two free external scans first (Sucuri SiteCheck and WPScan), then grade your encryption and headers with Qualys SSL Labs and securityheaders.com. For anything ongoing, install one scanning plugin (Wordfence for most sites, MalCare if page speed matters). Then switch on two-factor authentication for every admin, and turn off XML-RPC if you don’t use it.

Last reviewed: June 2026. Tools, plugin names, and vulnerability data verified against current sources.

How we researched this guide

We did not run a live penetration test against your site, and no article can. What we did do: open each free scanner listed here and confirm it still works the way this guide describes. We checked current plugin install counts and feature sets on WordPress.org and vendor pages. And we cross-referenced the threat numbers against Patchstack’s State of WordPress Security report for 2025. Where a tool changed name or owner, we say so. Solid Security, for example, is the plugin most older guides still call iThemes Security. We weighted free, no-install tools first (because most readers want to test before they spend), then ongoing plugins, then host-level protection. Anything we couldn’t verify on a current page, we left out.

What a WordPress security test actually checks

A WordPress security test is a check of your site for known weaknesses before someone else finds them. It looks at four layers: your software (core, plugins, themes), your logins, your file permissions, and your encryption. Most of the danger lives in the first one.

Here’s the thing most “audit” posts skip. WordPress racked up 11,334 new vulnerabilities in 2025, up 42% on the year before, and roughly 91% of them were in plugins. Another 9% came from themes. Core itself had six, all low priority. So a real test spends most of its energy on your add-ons, not on WordPress itself. Cross-site scripting alone made up about 41% of everything reported. If your test doesn’t flag outdated plugins, it’s testing the wrong thing.

Two kinds of tests exist, and you want both. External (remote) scans look at your site the way an attacker on the open internet does, with no login. Internal scans run from inside WordPress and can read your files, compare them against known-good copies, and spot changes. Remote tools catch what’s visible; internal tools catch what’s been tampered with.

Free tests you can run in 10 minutes (no plugin needed)

Start here. None of these touch your site’s code, so there’s zero risk of breaking anything, and you don’t need to log in to run them.

• Sucuri SiteCheck (sitecheck.sucuri.net): paste your URL and it checks for visible malware, spam injections, defacement, and whether your domain sits on any blacklist. Fast and honest about its limits. Because it only sees what a browser sees, it can’t catch server-side infections, so treat a clean result as “nothing obvious,” not “all clear.”
• WPScan (wpscan.com): the WordPress-specific scanner. It fingerprints your version, plugins, and themes, then matches them against a vulnerability database tracking tens of thousands of known issues. The free tier needs a quick sign-up for an API token and caps you at a set number of scans per day, which is plenty for one site.
• Qualys SSL Labs (ssllabs.com/ssltest): grades your HTTPS setup from A+ to F. It reads your certificate, protocol versions, and cipher suites. Anything below an A means weak or outdated encryption worth fixing.
• securityheaders.com: a one-click letter grade on your HTTP response headers. Missing a Content-Security-Policy or HSTS header is common and easy to fix, and this tool tells you exactly which ones you’re missing.
• MDN HTTP Observatory (the tool many people still call Mozilla Observatory): a broader best-practices check that overlaps with the two above and adds context on why each header matters.

Run all five, write down the grades, and you’ve got a baseline in under ten minutes. If everything comes back clean, great. Move to the manual checklist anyway, because remote scanners miss the stuff that lives behind your login screen.

The manual audit checklist: what to verify yourself

Remote scanners can’t log in. You can. This is the part that catches the weaknesses attackers actually exploit. Work through it with your dashboard open.

• Outdated software. Check core, every plugin, and every theme for available updates. Running WordPress 7.0 “Armstrong” or later keeps minor security patches automatic, but plugins still need your attention. Delete anything you’re not using. A deactivated plugin still has code on the server.
• Abandoned plugins. Open each plugin’s page and look at “last updated.” A plugin untouched for over a year is a liability, not a feature. Find a maintained replacement.
• User accounts and roles. Remove old admin accounts, downgrade users who don’t need admin rights, and make sure no account uses the username “admin.” Every extra administrator is another full set of keys.
• Two-factor authentication. Confirm 2FA is on for all admin and editor accounts, ideally with an authenticator app (TOTP) rather than SMS. Many security pros call this the single highest-impact change you can make. Want to go further? A passkey (WebAuthn) resists phishing in a way even app codes can’t, though in 2026 it’s still plugin-only, not baked into core. Generate backup codes either way.
• Login hardening. Is there a limit on failed login attempts? A CAPTCHA on the login form? These slow brute-force bots to a crawl.
• XML-RPC. If you don’t use the Jetpack app, remote publishing, or pingbacks, disable xmlrpc.php. Its system.multicall method lets attackers test hundreds of password guesses in one request, which is why it’s a favorite brute-force target.
• File permissions. Directories should be 755 (or 750), files 644 (or 640), and wp-config.php should be 440 or 400, never 644. Leaving wp-config readable hands your database credentials to any process on the server.
• Dashboard file editing. Add DISALLOW_FILE_EDIT to wp-config.php. If an attacker ever gets in, the built-in editor is their fastest path to injecting code. Most production sites never need it.
• SSL and headers. Confirm HTTPS is forced site-wide (no mixed content) and act on the SSL Labs and securityheaders grades from the last step.
• Backups. Verify you have recent, off-site backups and that you’ve actually restored one at least once. A backup you’ve never tested is a guess, not a safety net.
• The hosting layer. Good hosts block a lot before it reaches WordPress. If you’re on shared hosting and serious about this, a move to managed WordPress hosting shifts patching, firewalls, and malware scanning onto the provider.

Run a deeper automated audit with a security plugin (step by step)

External scans and the checklist give you a snapshot. A scanning plugin gives you a tripwire that watches the site all the time. Here’s how to set one up and run a full audit.

• 1. Pick one plugin, not three. Running two firewalls or two scanners at once causes conflicts and false alarms. Choose Wordfence, MalCare, Solid Security, Sucuri, or AIOS, then stick with it.
• 2. Back up first. Take a fresh backup before installing anything that touches security settings, so you can roll back if a firewall rule breaks a page.
• 3. Run the first full scan. Let it install, then compare your core files, plugins, and themes against verified originals. This is where altered or injected files surface.
• 4. Read the results by severity. Critical and high findings first. Modified core files or unknown PHP in your uploads folder are red flags. Low-priority notices can wait.
• 5. Turn on the firewall. Enable the web application firewall and let it learn your traffic for a few days before tightening rules.
• 6. Set up alerts. Email or Slack notifications for file changes, failed logins, and new admin accounts. You want to hear about trouble the day it happens, not next quarter.
• 7. Schedule recurring scans. Daily for a store, weekly for a brochure site. Automate it so you don’t rely on memory.
• 8. Re-run your free external scans. Confirm the plugin didn’t introduce mixed-content or header regressions.

Which plugin? Wordfence runs on your server and gives the deepest WordPress-level visibility, with an endpoint firewall and a malware scanner backed by over 5 million installs. MalCare moves scanning to its own cloud, so deep scans don’t tax your server, and its one-click removal is the fastest cleanup if you’re already infected. Sucuri pairs a free plugin with a cloud firewall that filters traffic before it reaches you. That suits a store behind a CDN, or a site that’s been hit before. Solid Security (yes, the old iThemes Security) focuses on login hardening and walks beginners through each fix in plain language.

How often should you test WordPress security?

Run a full audit at least every six months. That’s the floor, not the goal. Test again after any of these: a major core release, adding or removing a plugin, a host migration, or any sign of trouble like spam redirects or a sudden traffic drop. Speed is the reason. When GutenKit and Hunk Companion were found vulnerable in October 2025, attackers fired about 9 million exploit attempts in two weeks. The sites that scanned the day patches dropped were fine; the ones that waited a month became targets.

The cadence scales with your stakes. A personal blog can run quarterly. A WooCommerce shop taking real payments should scan daily and review logs weekly, because a breach there leaks customer data, not just yours. If you run a store, the security bar is higher across the board, which is its own argument for hosting built for stores rather than a basic shared plan.

What to do when a test finds something

Found a problem? Don’t panic, and don’t start deleting files at random. Triage in this order.

First, figure out whether you’re vulnerable or already breached. A flagged outdated plugin is a risk you can patch. Unknown PHP files, unfamiliar admin users, or content you didn’t write mean you’re likely already compromised, and that’s a different job. For a live infection, take the site into maintenance mode, restore a clean backup from before the breach, then patch the hole that let them in. Otherwise you’ll just get reinfected.

For plain vulnerabilities, the fix is usually boring: update or remove the plugin, tighten the permission, add the missing header, enable 2FA. Re-run the scan that caught it to confirm the finding is gone. Is the weakness constant brute-force or junk traffic hammering your login? That’s a job for the edge. Hosting with built-in DDoS protection stops the flood before it reaches PHP.

How to choose your testing toolkit

You don’t need every tool. You need the right two or three for your situation. A few common cases:

• Hobby blog, tight budget: under 5k visits a month, run free external scans every quarter plus Solid Security’s free tier for 2FA and login limits. Skip the paid firewall; at this traffic, host-level protection is enough.
• Business site, lead forms, no checkout: Wordfence (free or premium) for continuous scanning and an endpoint firewall, with weekly automated scans. The on-server visibility beats a remote-only scanner when you’ve got custom plugins.
• WooCommerce store, real payments, traffic spikes: a cloud firewall like Sucuri at the edge plus MalCare for off-server scanning, so deep daily scans never slow checkout. Pair it with a host that filters DDoS upstream. This is the one case where paying for layered protection earns its keep.
• You manage 10+ client sites: a cloud scanner you can run across all of them from one dashboard (MalCare or Sucuri) beats logging into each site. Per-site plugins don’t scale to an agency.

One rule cuts through all of it: pick a single firewall and a single scanner, then actually act on what they report. Two overlapping plugins fight each other, and a scan you never read is worse than no scan, because it gives you false confidence. Not sure your current host gives you a solid base to build on? The hosting finder tool filters providers by the security features that matter here.

Frequently Asked Questions

Can I test my WordPress site’s security for free?

Yes, and you should start there. Sucuri SiteCheck and WPScan both scan from the outside at no cost, and Qualys SSL Labs plus securityheaders.com grade your encryption and headers for free. For ongoing internal scanning, Wordfence and Solid Security both ship free versions that cover the basics. Paid tiers mostly add firewall depth and faster malware cleanup, not the core scan itself.

Is Wordfence or MalCare better for scanning?

It depends on where you want the work to happen. Wordfence runs its scanner on your server, which gives deeper file-level detail but uses your resources during a scan. MalCare runs scans in its own cloud, so it won’t slow your site, and its one-click malware removal is faster if you’re already hacked. For most self-hosted sites Wordfence is the default; for stores where speed is sacred, MalCare wins.

How do I know if my WordPress site has already been hacked?

Watch for the tells: pages redirecting to spam, unfamiliar admin accounts, content you didn’t publish, a sudden Google blacklist warning, or your host suspending the account. Run Sucuri SiteCheck for a quick external read, then a full Wordfence or MalCare scan to compare core files against the originals. If a scan finds modified core files or unknown PHP in your uploads folder, treat it as a confirmed breach and restore a clean backup.

Will a security plugin slow down my WordPress site?

A little, mostly during scans and only if the scanner runs on your server. Wordfence can add load while a deep scan runs, which is why high-traffic sites often pick MalCare or Sucuri to push that work to the cloud. A well-configured firewall has minimal day-to-day impact. If speed is your worry, choose a cloud-based scanner and schedule scans for off-peak hours.

Do I still need a security plugin if my host has a firewall?

Usually yes. A host firewall blocks network-level attacks, but it can’t see that one of your plugins has a known cross-site scripting flaw, or that someone added an admin account last night. A scanning plugin watches inside WordPress where the host can’t. The exception is fully managed WordPress hosting, where the provider runs both layers and monitoring for you.

Where to go from here

Testing isn’t a one-time event; it’s a habit. Run the free scans this week, work the manual checklist, then put one plugin in place to watch the site between audits. The five-hour exploitation window means one thing: the gap between “patch available” and “patch applied” is where sites die. The real win is auto-updates plus a tripwire that tells you when something moves.

If your audit keeps surfacing problems your current plan can’t fix, the issue might be the foundation rather than the site. It’s worth comparing managed WordPress hosting for hands-off patching, looking at eCommerce-grade hosting if you’re taking payments, or layering DDoS-protected hosting under a site that keeps getting hammered. Strong hosting plus a tested site is the combination that actually keeps you online.