Malware scanning that reads like an attacker thinks.

Signature matching compares what is on your site against a bundled definition set of known malware. It is fast, cheap and produces almost no false positives, and it is completely blind to anything written after the definitions were compiled. Used alone it gives you a scanner that reliably finds last year's problems.

Heuristic analysis widens the net by looking at how code is constructed rather than what it matches: execution of decoded input, long base64 chains, obfuscation, functionality that only triggers when a particular request parameter is present. It catches variants no one has catalogued, and it pays for that with false positives, because a lot of legitimate WordPress code looks alarming, minifiers produce unreadable output, caching layers evaluate generated code, and commercial plugins obfuscate their licence checks on purpose.

File integrity checking asks a different question entirely: is this file still what its authors shipped? WordPress core is hashed against the official WordPress.org checksums, and plugins and themes against their installed-version baselines. It needs no knowledge of malware whatsoever, which is exactly why it survives contact with novel payloads.

The database scanner covers what none of the file-based layers can see, and it is described in full on its own page. On Pro, a fifth layer reasons about intent rather than pattern.

A full-site scan is the default and it is the right thing to run on a schedule. It is rarely the right thing to run when you have a specific question at four in the afternoon.

Scoped modes cover core only, plugins only, themes only and uploads only. After updating a plugin, a plugins-only scan answers the one question you have in a fraction of the time. After restoring a backup, a core-only scan confirms the restore was clean before you go further.

Uploads-only is worth calling out separately, because the uploads directory is where compromises most often land first: it is the one directory a WordPress site is designed to let strangers write to. A PHP file in uploads has no legitimate reason to exist. That scan finishes quickly enough to run frequently, which is the property that actually matters.

Scanning happens on our infrastructure rather than inside your PHP process. The obvious benefit is performance: your visitors never wait behind a scan, and your host never kills a scan for exceeding a resource limit halfway through, which is a real failure mode for in-process scanners on shared hosting, and one that tends to produce a partial scan reported as a complete one.

The less obvious benefit is the important one. Malware that has already compromised a site can disable a security plugin running inside that site. It can deactivate it, filter its output, exclude directories from its scan, or simply return a clean result. A scanner running inside the thing it is inspecting is trusting the thing it is inspecting.

Running externally does not make that impossible, but it raises the bar considerably: the attacker now has to defeat a process they do not control rather than switch off one they do.