Google and your malware scanner are looking at completely different things. Your scanner reads the files sitting on your server and compares them against a list of known bad patterns. Google’s crawler visits your site like a stranger would and reads the page it gets served. When malware behaves differently depending on who’s asking, those two views stop matching.

This is the whole answer, and everything below is just detail.

Here’s the thing that makes it click for most people: Google isn’t guessing. Google’s Safe Browsing crawler actually fetched a page on your domain and got served something spammy. It’s not a heuristic or a maybe. Something got served. The question isn’t whether — it’s to whom.

Reason 1: Cloaking (this is the big one)

Malware built in the last few years is polite to the site owner and hostile to everyone else.

It checks whether you’re logged in. It checks your device. It checks where you came from. If you look like the person who owns the site, it serves a perfectly normal page and goes back to sleep. If you look like a visitor arriving from a Google search on a phone, it does its thing.

Google’s own Search Console documentation says this outright: hackers can hide injected links if they think you’re the site owner, and Google recommends checking sample URLs with the URL Inspection tool or from a different account or computer entirely.

When Google’s documentation tells you to go check from another computer, that’s a strong hint about what you’re dealing with.

Wordfence’s own guidance makes the same point — many hacks detect that you’re the administrator and show you nothing, while showing spam to your visitors and to search crawlers.

So: you look at your site, it’s fine. Googlebot looks at your site, it’s a pharmacy. Both of you are seeing real pages. Only one of you is the target.

Reason 2: Scanners match signatures, and signatures lag

Your scanner works from a list of known malicious code patterns. New or heavily obfuscated malware isn’t on that list yet.

Attackers also encode their payloads specifically to slip past pattern matching — base64, gzinflate, rot13, layered on top of each other until the code looks like alphabet soup. Some variants regenerate themselves with slightly different structure on every site, so no two infections share a signature.

A clean scan means “no known malware found.” It does not mean “nothing bad here.” Those are very different statements, and the scan result screen unfortunately renders both as a green checkmark.

Reason 3: The malware writes itself in only when needed

This one’s genuinely clever, in the way that a burglar with a good plan is clever.

One documented campaign stores its payload as an encrypted blob inside your database and writes a temporary PHP file into the uploads folder only at the moment a request comes in, then deletes it immediately afterward. A scanner running hourly will basically never catch it, because for 3,599 of every 3,600 seconds, the file genuinely does not exist.

Your scanner isn’t lying. It’s just showing up to an empty room.

Reason 4: The infection is in the database, not the files

Most scanners focus on files. Plenty of malware lives in your wp_options table as a long encoded string, or gets injected into wp_posts as spam content, or sits in serialized data mixed in with legitimate settings.

Database injections are genuinely harder to spot, both for automated tools and for humans, because the malicious content is tangled up with data that’s supposed to be there.

Reason 5: The backdoor isn’t in WordPress at all

Here’s the one that ends the most cleanup attempts.

There’s a documented forensic case where a site owner watched malware reappear in wp-config.php every few hours, no matter how many times they cleaned it. A Wordfence analyst ran a complete WordPress-level audit: no rogue files, no database injections, no compromised admin accounts. The WordPress installation was genuinely, verifiably clean.

The attacker had turned a webmail log file into a root-level backdoor. That file lives on the server, entirely outside WordPress. No WordPress security plugin reaches it. No file integrity monitor watches it. No admin-panel scan will ever see it.

The full chain, from initial access to a working webshell, took fourteen seconds.

If your site keeps reinfecting itself and every WordPress-level scan comes back clean, this is a scenario worth taking seriously. Your WordPress install can be spotless while the server underneath it belongs to someone else.

Reason 6: It’s your neighbor

On shared hosting, sites in the same account can contaminate each other. In one well-known campaign, infected sites either used the vulnerable plugin themselves or simply had it installed on another site within the same shared account.

So your site can be clean, your scanner can be honest, and you can still be getting reinfected from the forgotten test install in a subdirectory you set up in 2021 and never thought about again.

Scanner Blind Spots at a Glance