Why You Can’t Control Their Data Breach (But You Can Control Your Source Code)

When unexplained spam starts showing up, the instinct is almost always the same: “I must have been hacked somewhere.” That’s sometimes exactly right — and there’s a genuinely good tool for checking it. But a meaningful share of contact-related spam traces back to a completely different cause, one that has nothing to do with any breach at all, and treating the two as the same problem leads people to the wrong fix every time.

Two Different Questions, Often Confused for One

“Has my email been exposed somewhere” is actually two separate questions wearing one outfit. The first: was your email sitting in a company’s database when that company got breached? The second: is your email currently readable directly off your own website by anything that bothers to look? These have different mechanisms, different points of origin, and — critically — completely different answers to “what can I do about it.”

What a Breach Checker Actually Tells You

Have I Been Pwned, maintained by security researcher Troy Hunt, is the most widely referenced free tool for checking whether your email address appears in a known data breach. It’s a genuinely excellent tool for what it’s built to do: it cross-references your email against a database of breaches that have already happened — companies whose systems were compromised, with user data subsequently exposed or sold. If your email shows up, you’ll see exactly which company was breached, what category of data was included, and when it happened.

What a tool like this fundamentally cannot tell you is whether your own website is currently exposing your contact information to anything that reads its HTML. That’s not a gap in the tool — it’s outside the category of problem it’s designed to solve. A breach checker answers “was I caught up in someone else’s security failure.” It has no visibility into your own site’s source code at all.

Why Scraping Gets Treated as Less Serious Than It Is

Part of why this confusion persists is that scraping doesn’t look like a hack, even when it operates at genuinely massive scale. Security analysis covering the topic makes this point directly: companies “frequently underestimate” the risk of scraping specifically because it’s technically not a hack or a breach — there’s no broken lock, no exploited vulnerability, just a bot reading information that was sitting in plain view the whole time.

The scale involved can rival major breaches, even though the mechanism is entirely different. Documented incidents include LinkedIn, where data from over 1 billion user accounts was scraped and offered for sale on the dark web in 2021, and Facebook, where scrapers extracted information on more than 500 million users that same year. Neither of these started with a broken password, a phishing email, or a system exploit. Both started with information that was technically public, harvested at scale by automated tools.

The One Difference That Actually Matters

Here is the entire point this article exists to make: a breach happens to data you handed to someone else, inside systems you never had access to. There was no version of events where you could have stopped Facebook’s or LinkedIn’s scraping incidents from your own side — your only relationship to that exposure was being a user of a platform whose security wasn’t yours to manage. That’s a real, legitimate source of anxiety, and the correct response is exactly what breach-checking tools are built for: find out if it happened, change any reused passwords, and move on.

Scraping is the opposite case entirely. Email harvesting bots don’t need to break into anything — they read your website’s HTML the same way a browser does, extracting any email address, phone number, or physical address that’s sitting there in plain text. Every single piece of that exposure traces back to something you built, on infrastructure you control, in source code you can read and change at any time. There is no third party whose security failure caused this. The only failure point is whatever’s currently sitting unprotected in your own contact page, footer, or About page.

Why This Distinction Changes What You Actually Do

Once the two are separated cleanly, the right response to each becomes obvious instead of overwhelming. For breach exposure, the playbook is reactive and well-established: check Have I Been Pwned periodically, change any password that’s been reused across the breached account and elsewhere, and enable alerts so you learn about future breaches as they’re indexed. There’s nothing more proactive available, because the exposure already happened somewhere outside your control.

For scraping exposure, the playbook is the opposite — entirely proactive, because the vulnerability is sitting in something you own right now. A WordPress contact page displaying an email address in plain HTML is exposed to exactly the same mass-harvesting bots responsible for incidents at the scale of LinkedIn and Facebook — just at the scope of a single site instead of a billion accounts. The fix doesn’t require waiting for a breach notification or hoping a checker tool catches it. It requires closing the exposure in your own source code before a bot ever reads it.

• 1

  For breach exposure: check, don’t obsess. Run your email through Have I Been Pwned periodically and set up alerts. Beyond changing reused passwords, there’s genuinely nothing more proactive to do — the exposure already happened on infrastructure you never controlled.

• 2

  For scraping exposure: audit your own site directly. View your contact page’s actual page source and look for your email, phone number, or address sitting in plain, unencoded text — exactly what a harvesting bot would find.

• 3

  Don’t wait for a spam flood to confirm it. By the time spam volume makes scraping obvious, the harvest already happened and the data is already circulating. The window for prevention closes the moment a bot successfully reads your page.

• 4

  Treat your own source code as the one exposure point you fully control. Unlike a vendor’s database, you can inspect, encode, and protect your own site’s contact information today — no waiting required.

This is precisely the gap WhoKnew Shield™ is built to close. Rather than offering another after-the-fact checking tool for an exposure you can’t control, Shield automatically detects and protects every email address, phone number, and physical address across your WordPress site — combining dual-layer obfuscation with active bot-blocking that catches scrapers before they ever extract anything from the one part of this entire problem that was always yours to fix.

Who knew the spam you can’t explain might have nothing to do with anyone else’s security failure at all — and everything to do with a contact page you built and never thought to check.