Why Wordfence Recorded Zero Attacks While WhoKnew Shield™ Caught 491+

We want to be clear upfront: this is not an article attacking Wordfence. Wordfence is a legitimate, well-maintained security plugin that does exactly what it says it does. We use it ourselves. We’re not here to replace it — we’re here to explain why the two tools work on completely different problems, and why the number that surprised us actually makes perfect sense once you understand the attack chain.

We ran WhoKnew Shield™ Pro and Wordfence simultaneously for 30+ days. At the end of that period, Shield had recorded 224 threats blocked directly by Scraper Trap™, plus 267 additional blocks from the WhoKnew Intelligence™ collaborative network — 491 total. Wordfence’s firewall dashboard showed one entry: our own login.

Wordfence recorded zero attacks. Here’s why that’s exactly what should happen — and what it tells you about how automated threats actually work.

Why Automated Attacks Start With Reconnaissance

To understand why this happens, you need to understand how automated attacks actually work. Most WordPress site owners imagine a cyberattack as something dramatic — a sophisticated actor probing for a specific vulnerability, trying SQL injections, hammering the login page. That kind of targeted attack exists. It represents a small fraction of what’s actually hitting WordPress sites every day.

The vast majority of WordPress attacks are automated, distributed, and opportunistic. They follow a predictable three-stage sequence:

Wordfence operates at stage three. Its firewall is designed to intercept known attack signatures, block malicious requests, and monitor file integrity. It’s exceptionally good at what it does — for attacks that reach it.

WhoKnew Shield™ operates at stage one. The moment a bot ignores robots.txt and begins its reconnaissance crawl, it triggers a honeypot. Its IP is blocked from the entire site instantly and automatically. It never reaches stage two. It never reaches stage three.

The Production Data: Same Site, Same 30 Days

Here’s what we actually observed running both tools simultaneously:

30-day Wordfence Results

30-day WhoKnew Shield™ Results

The 491 blocks shown in the dashboard represent the full picture: 224 caught directly by Shield’s Scraper Trap™ honeypot, plus 267 hostile IPs blocked by the WhoKnew Intelligence™ collaborative network before they ever sent a single request — IPs already flagged by other Shield Pro sites worldwide. Every one of those 491 threats was stopped before it ever reached the layer where Wordfence operates.

Wordfence’s live traffic log showed one entry during this period: our own login. Google’s crawlers were present and flowing through freely — as expected, because Googlebot respects robots.txt and never triggers the honeypot. Bad bots were absent — not because they stopped coming, but because Shield had already blocked them before they sent a single request that Wordfence would see.

In a single day, a scraping operation hit our test site from five coordinated subnets simultaneously — 36 IP addresses in total, working together across different network ranges to evade detection:

The 79.1% of these attacks originating from United States IP addresses is consistent with the broader pattern of commercial scraping operations — automated services running on US-based cloud infrastructure, often rented by operators in other countries, specifically because US IPs carry more inherent trust on many security systems.

Why Legitimate Bots Are Never Affected

The obvious question when you hear “blocks anything that ignores robots.txt” is: what about Google? What about Bing? What about legitimate crawlers?

The answer is that legitimate crawlers respect robots.txt by design. Googlebot, Bingbot, and every other reputable crawler reads robots.txt before crawling and follows its instructions. They never trigger the honeypot because they never disrespect the rules that the honeypot is watching for.

Bad bots ignore robots.txt — not because they can’t read it, but because they don’t care. They’re not here to index your content. They’re here to harvest data, map vulnerabilities, or execute attacks. robots.txt compliance would slow them down for no benefit. So they skip it, hit the honeypot, and get blocked.

In fact, robots.txt is often the first thing a bad bot reads deliberately — not to follow the rules, but because site owners commonly list sensitive paths they want search engines to ignore, making it an accidental treasure map straight to the directories and endpoints they most want to hide.

The result is a system with essentially no false positives for the typical WordPress site. Google flows through freely. Bad bots walk into the trap. The distinction between the two is built into the mechanism itself.

What Wordfence Is Actually For — And Why You Still Need It

Shield does not replace Wordfence — and understanding why makes the partnership between them clearer. Think about the bar a threat would have to clear to even reach Wordfence on a site running Shield:

• It would have to not already be in the WhoKnew Intelligence™ shared blocklist of ~15 million verified hostile IPs
• It would have to respect robots.txt — which no automated scraper does
• It would have to avoid triggering the honeypot during reconnaissance
• Only then, having cleared all three filters, would it attempt an actual attack that Wordfence could see

That’s an extremely narrow slice of the threat landscape. In practice it describes one kind of attacker almost exclusively: a targeted human attacker who is specifically coming after your site, behaving like a human rather than a bot, not on any existing blocklist. That attacker is real — and for that attacker, Wordfence is exactly the right tool.

Wordfence is genuinely valuable for what Shield doesn’t cover:

• Targeted human attacks — a specific person manually probing your site won’t behave like an automated scraper. They may respect robots.txt. They may not trigger the honeypot. A human attacker requires the kind of deep inspection that a firewall provides.
• File integrity monitoring — if core WordPress files are modified, Wordfence catches it. Shield doesn’t do file integrity monitoring.
• Known exploit signatures — Wordfence maintains an extensive database of CVE-based firewall rules. If a specific vulnerability in a plugin is being actively exploited, Wordfence’s signature database covers it.
• Brute force login protection — direct wp-login.php attack attempts are Wordfence territory.

Shield handles everything that happens before an attack begins. Wordfence handles the rare attack that makes it through. They’re sequential layers of the same defense, not alternatives to each other.

The Resource Argument Nobody Talks About

There’s a practical cost to running only a firewall that rarely gets discussed: every bot that reaches your firewall still consumed server resources to get there. CPU, memory, bandwidth — all of it spent serving a firewall response to an attacker who was going to get blocked anyway.

A bot that’s IP-banned by Shield before it sends its first request never consumes those resources at all. It doesn’t reach the server. It doesn’t get a response. It costs nothing.

On a low-traffic site this is a minor consideration. On a site that’s being actively targeted by automated scraping operations — which our test site clearly is, given 181 blocks in a single 7-day window — the difference in server load between “firewall blocks at the door” and “honeypot blocks before they arrive” is measurable.

One caught, the rest flow freely — that’s upstream blocking in one image.

What This Means for Your WordPress Site

If you’re running Wordfence and nothing else, the practical implication is this: you have no visibility into the threats that never reach it. Your Wordfence dashboard may look quiet — and if it does, that’s not necessarily reassuring. A quiet Wordfence dashboard on a site without upstream honeypot protection means either your site isn’t being targeted (possible but unlikely) or that the automated attacks are completing their reconnaissance work without triggering anything (more likely).

The bots that scrape your contact information, map your plugin versions, and catalog your admin URLs don’t leave a trace in Wordfence — because Wordfence isn’t watching for them. By the time they’ve finished their reconnaissance and the actual attack attempt begins, you’ve already lost the first round.

The fix is adding an upstream layer that catches threats before they finish their reconnaissance. That’s what Shield does. It doesn’t compete with Wordfence — it operates earlier in the chain, before Wordfence even comes into play.

Install both. Set Shield to block any IP that disrespects robots.txt, with auto-promote to permanent after two or three triggers. Let Wordfence continue doing what it does. Watch your Shield dashboard for a week and see what was coming that your firewall never knew about.

Who knew the most important number in your WordPress security setup was the one your firewall never got to record?