Malware on a WordPress site commonly takes the form of a backdoor disguised as a legitimate file, injected code redirecting visitors to spam, or a script quietly sending spam email from your server. Catching it early, before it’s been running for weeks, makes the difference between a quick cleanup and a genuinely serious incident. Here’s how to actually scan for it.
Method 1: a free online scanner (no installation needed)
Sucuri’s SiteCheck checks your site from the outside, entering just your URL, no plugin install or account required. It’s a genuinely useful first check specifically because it sees your site the way an outside visitor or search engine crawler does, which catches certain things (like cloaked malware showing spam only to non-logged-in visitors) that scanning from inside your own admin session might miss. It can’t see everything though, your database contents or anything behind a login stay invisible to an external scan like this.
Method 2: a security plugin’s built-in scanner
An on-server scanner, most WordPress security plugins offer one, reads and hashes your actual files directly, comparing them against known-good checksums. This is more thorough than an external scan since it has direct access to your files and database, at the cost of using your own server’s CPU and memory to do the work, sometimes noticeably during a full scan on a large site. Worth checking specifically whether file integrity scanning sits in a plugin’s free tier or a paid one, on SecondGate it’s part of the Pro tier (£39.99/year) rather than the free tier, which covers 2FA and brute-force protection instead.
Method 3: WP-CLI for a command-line check
If you have server access and WP-CLI installed, wp core verify-checksums compares your WordPress core files directly against the official checksums WordPress.org publishes for every release, flagging anything that doesn’t match. This only covers core files, not plugins, themes, or the database, but it’s a fast, genuinely free way to check the most commonly targeted layer without installing anything additional.
What to actually do with the results
A flagged file doesn’t automatically mean malware, sometimes it’s a host patching core files for legitimate reasons of their own, or a plugin that (unusually, and against WordPress’s own coding standards) modifies a core file directly. Before assuming the worst, check whether the specific change makes sense, does the modified file’s content look like something a legitimate process might have done, or does it contain genuinely unfamiliar code, obfuscated strings, or references to functions like eval() or base64_decode() wrapped around unreadable text, a common pattern in real malicious injections.
If you find something real
Don’t just delete the flagged file immediately, preserve a backup of it first, in case you need it later to understand how the compromise happened or to get professional help. For the full recovery process once you’ve confirmed a genuine infection, what to do if your WordPress site is hacked walks through the complete sequence in the right order, containment, evidence preservation, cleanup, and hardening, rather than just the scanning step covered here.
Scan on a schedule, not just when something feels wrong
Waiting until you notice a symptom means the infection has already had time to do damage. A recurring scheduled scan, weekly at minimum for most sites, catches problems earlier, ideally run during low-traffic hours specifically because scanning is real CPU work and running it during peak traffic is a common, avoidable cause of a security plugin slowing a site down.
Where this fits into a broader security setup
Scanning catches an infection after it’s happened. For the protections that reduce how often you need to, how to secure a WordPress site covers the fundamentals, updates, 2FA, and the rest of what closes off most real-world compromise routes before scanning ever becomes necessary.
