June 14, 2026

What your hosting provider's free "security scan" actually catches (and what it misses)

Your hosting dashboard has a green checkmark next to "Security Scan." Wordfence emails you a clean report every week. GoDaddy says your site looks fine. So you're safe, right?

Sometimes yes. Sometimes that green checkmark is the most expensive thing on your site. Let's break down what these free tools actually do, where they fall short, and how to tell which category your business is in.

What free scans are genuinely good at

Free scanners — Sucuri SiteCheck, Wordfence's free tier, GoDaddy's built-in scan, Jetpack Protect — aren't useless. They're pattern matchers, and for the patterns they know about, they work fine.

Here's what they reliably catch:

Known-bad file signatures. If your site gets hit by a common malware strain that's been seen 10,000 times before, the scanner has a hash for it. It'll flag the file. This covers a surprising amount of low-effort attacks against WordPress.
Obvious file changes in core WordPress files. Wordfence in particular is good at noticing when /wp-admin/ or /wp-includes/ files don't match what WordPress.org shipped. If an attacker drops a webshell into wp-includes/, this gets caught.
Blacklist status. Sucuri SiteCheck queries Google Safe Browsing, Norton, McAfee, and a handful of others. If your domain is flagged anywhere public, you'll know.
Out-of-date plugins and themes with known CVEs. Helpful as a nag — most breaches start with an unpatched plugin.
Visible defacement and SEO spam. If your homepage suddenly says "Buy Cheap Watches," the scanner sees it on the rendered HTML.

For a brochure site with no logins, no payment processor, no customer data, and low traffic, this is often enough. I'll come back to that.

What they consistently miss

The gap between "scanner says clean" and "site is actually clean" is where the real damage happens. Here's what gets through:

1. Novel or custom backdoors

Signature-based scanners need to have seen the malware before. A custom-written PHP backdoor — even a basic one — won't match any signature. Attackers know this. They obfuscate payloads with base64, gzinflate, str_rot13, and chained eval() calls specifically to dodge pattern matching.

I worked on a WordPress site for a Southern California contractor where a prior contractor had "cleaned" the malware and declared the job done. The free scans were green. The site kept reinfecting itself every few days because there was a self-healing backdoor sitting in a plugin's vendor/ directory that no scanner recognized. It rewrote infected files on a schedule. We only found it by hunting through the file system manually, comparing modification timestamps, and reading the actual PHP.

2. Database-resident persistence

This one's nasty. Most free scanners look at files. They don't deeply inspect your wp_options, wp_posts, or wp_usermeta tables.

Attackers know this too. Common tricks:

Malicious JavaScript stored in wp_options (often in fields like widget_text or custom options) that gets echoed into every page
PHP eval()'d from a serialized option value
Hidden admin users with capabilities granted via direct wp_usermeta inserts
Spam content injected as draft or scheduled posts — like the 115+ spam posts I cleaned out of that contractor's site, all sitting in wp_posts waiting to be indexed

A file scan misses all of this.

3. Hijacked legitimate plugins

When an attacker modifies a legitimate, popular plugin instead of dropping a new file, scanners get confused. The plugin is "supposed" to be there. If Wordfence's integrity check only covers WordPress core and not every plugin file, modifications slip through. Some free tools do check plugin integrity against the WordPress.org repo, but premium plugins (and custom builds) get no comparison at all.

4. Server-level webshells outside the web root

If your hosting account is compromised at the server level, the attacker may drop tools in your home directory, in /tmp, or in cron jobs — places the WordPress-focused scanner never looks. These survive WordPress reinstalls, plugin removals, and even site migrations if you move the same files.

5. Credential theft and exfiltration that's already done

Scanners detect presence, not history. By the time a scan flags anything, your admin credentials, customer emails, or stored card tokens (if your integration is bad) may already be on a forum somewhere. The scanner can't tell you what left the building.

6. Mail abuse

A common goal of WordPress compromise isn't to hurt your site — it's to use your server to send spam or phishing. Scanners rarely flag this. You find out when your IP lands on Spamhaus and your real emails stop reaching customers.

When free really is enough

I'm not here to scare every small business into a monthly retainer. Be honest about your risk:

Free scanning is probably fine if all of these are true:

You run a brochure / informational site (services, hours, contact form, that's it)
No e-commerce, no payment flow, no membership area
You don't store customer PII (no health info, no SSNs, no financial data)
Traffic is modest — you're not a high-value target
You actually act on what the scanner tells you (update plugins, rotate passwords, etc.)

In that scenario, a free Wordfence install plus monthly attention is a reasonable security posture for a 10-person business.

When you need a human looking

You should bring in professional incident response (or at minimum a paid retainer with manual review) if any of these apply:

You take payments on-site — even if Stripe handles the card, attackers can hijack the checkout flow with skimmers (Magecart-style attacks). I've seen these survive multiple free scans.
You store customer data of any sensitivity — emails count, especially with breach notification laws now applying to small businesses in many states.
You've been reinfected once already. Reinfection means the first cleanup missed something. Free tools will miss it again.
You see signs of persistence: unfamiliar admin users, cron jobs you didn't create, files modified at 3 AM, mysterious outbound traffic, sudden mail bounces.
You're in a regulated industry — healthcare, legal, financial services. The standard of care is higher and "the scanner said it was clean" isn't a defense.
Your site is your revenue. If a day of downtime or a Google blacklist costs you real money, the math on professional IR is easy.

The honest middle path: DIY file integrity baseline

Here's something most articles won't tell you because it doesn't sell a product: you can dramatically improve your free-tier security with about 30 minutes of work.

Take a known-good snapshot of your site's files right after a clean install or right after a confirmed clean cleanup. Then compare against that baseline on a schedule. Anything that changed and shouldn't have is suspicious.

A rough approach if you have SSH access:

# Generate baseline (run when site is known clean)
find /path/to/site -type f \( -name "*.php" -o -name "*.js" \) \
  -exec sha256sum {} \; | sort > ~/baseline.txt

# Check current state against baseline (run monthly)
find /path/to/site -type f \( -name "*.php" -o -name "*.js" \) \
  -exec sha256sum {} \; | sort > ~/current.txt

diff ~/baseline.txt ~/current.txt

Any line in the diff that isn't from a plugin/theme/core update you performed is worth investigating. This catches almost everything a signature scanner misses, because it doesn't care what the malicious code looks like — it just notices something changed.

Pair this with:

Lock down wp-config.php: define('DISALLOW_FILE_EDIT', true); and define('DISALLOW_FILE_MODS', true); if you're not actively installing plugins
Disable PHP execution in /wp-content/uploads/ via .htaccess:

<FilesMatch "\.(?i:php|phtml|php3|php4|php5|phar)quot;>
  Require all denied
</FilesMatch>

Real, off-host backups (your hosting provider's backup doesn't count if their account is compromised)
2FA on every admin account, no exceptions

That stack — free scanner + file integrity baseline + basic hardening + 2FA — is the actual answer for a lot of small businesses. It's not glamorous and nobody sells it as a package because it's mostly free.

When it's time to call someone

If you're past the "brochure site" threshold, or you've already been hit, or you've got signs of persistence and the scans keep coming back green — that's the point where free tools become a liability instead of a help. You're getting false reassurance while something sits in your database.

Real incident response means somebody actually opens the files, queries the database for suspicious options and users, audits scheduled tasks, checks mail logs, and confirms persistence is gone before declaring the job done. That's what cleared the self-healing backdoor on the contractor site — not another scan, but someone reading the code.

If your scanner says you're clean but your gut says something's off, the gut is usually right. If you want a real set of eyes on it, my WordPress malware removal and incident response service covers the full hunt — files, database, server, mail, and persistence — and won't declare the job done until it actually is. You can read the full case study of the contractor cleanup if you want to see what that process looks like end to end.