Wordfence vs WP Ghost: a layer-by-layer comparison

I run engineering at Squirrly, where we operate a portfolio of WordPress sites. The "Wordfence or WP Ghost?" question comes up constantly, and it's framed wrong almost every time. They're not alternatives. They guard different layers. Here's the version with config examples instead of a marketing table.

The one-paragraph answer

Wordfence is a scanner plus an in-application firewall. It runs as PHP inside WordPress, inspects requests after they've reached the application, and scans files on disk for known-bad signatures. WP Ghost works one layer earlier: it changes default paths and rejects malicious request patterns at the rewrite layer, before PHP loads. Detection and cleanup on one side, attack-surface reduction on the other. On most production sites you want both.

Where the request actually goes

A request to your WordPress site passes through a stack of layers:

client
  → network layer        (Cloudflare / host firewall: traffic shaping, DDoS)
  → server layer         (.htaccess / nginx rewrite rules: routing decisions)   ← WP Ghost
  → application layer     (WordPress boots, plugins init, endpoint firewall)     ← Wordfence
  → file system          (on-disk files; malware scanner reads here)            ← Wordfence
  → backups              (UpdraftPlus / host snapshots: recovery)

The position is the whole point. Wordfence's endpoint firewall is PHP code, so by the time it inspects a request, WordPress has already loaded. WP Ghost's 7G/8G rules are rewrite directives that execute before the PHP interpreter is invoked at all.

What that difference costs (and saves)

Consider a bot brute-forcing the default login path. With an in-PHP firewall alone:

GET /wp-login.php  →  Apache/nginx hands request to PHP
                   →  WordPress core loads
                   →  plugin stack initializes (including the firewall plugin)
                   →  firewall evaluates, rate-limits, returns 403

Every blocked probe still paid for a full WordPress boot. With a rewrite-layer path change, the default path simply isn't served:

GET /wp-login.php  →  rewrite rule matches  →  404, PHP never invoked

The script gets a 404, doesn't adapt (these bots don't pivot to a renamed path), and moves to the next domain in its queue. On bot-heavy sites the net effect is a measurable load reduction, because the rejected requests never reach PHP.

The fingerprint problem

Attack chains usually start with reconnaissance: confirm it's WordPress, enumerate plugins, match against a CVE list. WordPress advertises itself by default:

<meta name="generator" content="WordPress 6.x" />
<link rel="https://api.w.org/" href="https://example.com/wp-json/" />
<link rel="stylesheet" href="https://example.com/wp-content/plugins/some-plugin/style.css?ver=2.1" />

Each of those is a signal a classifier like Wappalyzer reads. WP Ghost removes them from output (generator tag, RSD header, version strings, /wp-json/ link) and changes the /wp-content/ and plugin paths in asset URLs. The classifier returns "unidentified CMS," and the plugin-enumeration step that feeds CVE targeting comes back empty. This matters in context: Patchstack's 2026 report counted 11,334 WordPress vulnerabilities disclosed in 2025 (a 42% YoY increase), 91% of them in plugins. Most of those exploits start by confirming the plugin is installed.

Wordfence does not do any of this path-changing or fingerprint removal. That's not a knock; it's a different job.

What Wordfence does that WP Ghost doesn't

Be honest or don't write the comparison. Wordfence's malware scanner, file-integrity monitoring, live traffic view, and Premium threat-intel feed are genuinely strong. WP Ghost scans nothing. If a file on disk is already infected, or was planted before you hardened the site, WP Ghost won't find it. The scanner will. With WPMayor's reporting putting the disclosure-to-exploitation window around five hours, the Premium rule feed is a real asset on high-value sites.

Verifying the prevention layer actually works

After changing paths, confirm the default endpoints are gone and the new ones respond:

# default login should now 404
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/wp-login.php
# expect: 404

# fingerprint check: generator tag should be absent
curl -s https://example.com/ | grep -i 'name="generator"'
# expect: no output

# new login path should serve the form (replace with your configured path)
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/your-new-login/
# expect: 200

If you're on nginx, remember the rewrite changes need a config reload (nginx -s reload or your host's equivalent). Apache and LiteSpeed pick up .htaccess changes without a reload.

The honest overlap

Both tools do 2FA, brute-force rate limiting, and basic hardening. Don't double-configure rate limiting; pick one. The one authentication edge worth calling out: WP Ghost ships passkey 2FA (FIDO2 / WebAuthn: Face ID, Touch ID, Windows Hello, hardware keys) in its free tier. Passkeys are phishing-resistant because the WebAuthn challenge is bound to the origin, so a phished credential can't be replayed against your domain.

The stack I'd actually run

Cloudflare (free)         → network noise + DDoS
WP Ghost (free)           → path changes, fingerprint removal, 7G/8G rewrite firewall
Wordfence (free or Prem)  → malware scan, file integrity, live traffic
UpdraftPlus               → backups / recovery

Roughly: WP Ghost lowers what reaches the application, Wordfence catches what gets through and what's already there, backups get you home if both fail.

TL;DR

Wordfence detects and cleans. WP Ghost prevents and relocates. They sit on different layers and the feature rows barely overlap, so "vs" is the wrong framing. Run the scanner for eyes on disk, run the path-changer for a smaller front door.

Question for the comments: if you run both, did you notice a server-load change after moving the login and admin paths off the defaults? I'm curious how consistent the drop is across different hosts.

WP Ghost has a free version on wordpress.org.