Cloaking Malware: The Storefront Only Google Ever Sees

You check again. You still see your real site. So does everyone you ask to check for you. This isn't a glitch on your end, and it isn't the customer misremembering a URL. It's a specific category of WordPress malware called cloaking, built entirely around one idea: show a clean site to the person looking, and a different one to the crawler indexing it.

This post walks through how cloaking malware pulls that off, why a normal file scan and a normal visit both come back clean, and what you can actually check yourself, no PHP reading required.

The trick is the audience, not the payload

Most WordPress malware doesn't care who's looking. A defacement shows the same message to everyone. A drive-by redirect sends every visitor to the same scam page. Cloaking malware is different: it inspects who's asking before deciding what to serve.

When the request looks like it's coming from Googlebot, it serves a fake storefront, complete with product pages, prices, and the metadata search engines expect (a page type tag identifying it as a product, a canonical link pointing back at your own domain). When the request looks like an ordinary browser, it quietly steps aside and lets your real site load. The two versions never meet, because the two audiences never see the same version.

That split is what makes it so effective. Google indexes the fake catalog under your domain's authority. Anyone who searches your business name can be served one of those indexed product pages instead of your homepage, and land on a lookalike store. Meanwhile every human who checks the site directly, including you, sees exactly what should be there.

Why the file scan comes back clean

Cloaking malware built this way usually leans on three separate tricks, and each one defeats a different kind of check.

The first is location. The actual malicious code, the templates for the fake store, the fabricated product list, all of it, doesn't live in your WordPress files at all. It sits in your server's temporary storage area, in a folder named after your site's internal ID, completely outside the folder your file scanner is pointed at. No malware scan that only looks inside your website's own directory will ever reach it.

The second is disguise. The one file inside your WordPress files that actually loads all of this lives inside a legitimate plugin's own subfolder, often one meant for a specific theme integration you may not even use, and it doesn't end in .php. A scanner (or a person) searching for suspicious PHP files by extension walks right past it, because by every filename convention it isn't one.

The third is patience. The single line of code that ties everything together isn't one obvious block. It's three unrelated-looking lines, planted hundreds of lines apart inside a real plugin file: one that builds a folder path, one that prefixes it with a special way of telling PHP "treat this as compressed data," and one, much later, that actually includes it. Read any one line on its own and it looks like unremarkable plugin code. That's the point.

The tells you can actually check

You don't need to read PHP to catch signs of this. A few checks are within reach with nothing more than your hosting file manager and Google Search Console:

1. Search Console shows pages you never made. If your indexed page count includes URLs like /products/something-you-dont-sell, and clicking through from search actually resolves (rather than 404ing), that's the clearest signal something outside your control is generating pages under your domain.
2. Your sitemap looks different depending on how you view it. Most WordPress sites generate a sitemap index, a short file that just lists other sitemap files. If the version Google has crawled contains a long list of individual URLs instead of that short index, something is replacing it before Google sees it, even if the sitemap looks normal when you open it yourself.
3. A plugin folder has a file with no file extension. Browsing a plugin's own integration or config subfolders in your file manager and finding a file with a name but no .php, .js, or .css after it is worth asking your host or a security provider to look at directly. Legitimate plugin files almost always have one.
4. "I checked and it looks fine" isn't evidence here. If a customer or Search Console is telling you something your own browser isn't, believe the outside signal. That mismatch is the entire mechanism of this malware, not a contradiction to explain away.

How this actually gets confirmed

If you suspect cloaking but can't find hard proof, the fix isn't looking harder from your own browser. It's making a request that identifies itself as Googlebot and comparing what comes back to what an ordinary visit returns. When the two responses genuinely match, in size, in title, in every link, you're clean. When they don't, the difference between them is the malware. This is also how the file that loads the hidden code eventually gets identified: whatever loaded right before the fake content appeared is almost always the culprit. It's not something you need to do yourself, but it's worth knowing this is a real, mechanical test, not guesswork, so you can ask whoever is checking your site whether they actually ran it.

The catch: a clean look isn't a clean site

Here's the part that's easy to miss even for people who clean sites for a living. Cloaking malware's core promise, that it looks fine to you, means every manual check that relies on looking is exactly the wrong test. It's entirely possible to load the homepage, click through a few pages, run a quick scan, and reasonably conclude the site is fine, while the crawler-facing side keeps generating and indexing fake product pages the whole time.

Kornet scans your WordPress site the way Google actually sees it, not just the way a human visitor does, specifically to catch cloaking and other audience-aware malware that hides from ordinary checks. The scan is free; you only pay if we actually find malware.

Kornet Labs publishes field notes from real WordPress malware cleanups.