Free WordPress Plugin

WP Honeypot Guard

A free plugin that plants fake attack paths on your WordPress site. Nobody real ever requests them — only automated scanners looking for known compromised plugins and backdoors do. Any IP that touches one gets blocked for an hour.

Send me the download link See how it works →

The decoy-blocking is always on and carries zero lockout risk. There's a separate, optional lock feature that's off by default — see below before you touch it.

How it works

Automated scanners don't guess at your site — they check it against a list. They request the exact URLs of known compromised plugins, old admin-ajax exploits, and backdoor files left behind by previous hacks, and see what answers back.

WP Honeypot Guard sets up decoy versions of those same URLs on your site. There's no link to them anywhere, so a real visitor, a real customer, or Google's crawler will never request one. Only something specifically probing for a known hole would.

The moment any IP address requests one of those decoy paths, that IP is blocked for an hour. Nothing else on the site changes — no plugin files touched, no theme edited, no settings a real visitor would ever notice.

Why this matters more on an older site

A site running an old theme, old plugins, and a PHP version nobody wants to touch isn't being ignored by attackers — it's being targeted more. Automated scanners specifically hunt for that combination, because unpatched, out-of-date software is common and cheap to exploit at scale.

The usual advice is "just update everything." That's not always realistic. Sometimes an update breaks the site. Sometimes nobody maintains it anymore and nobody wants to risk touching it. Either way, the site still needs some protection while it sits there unpatched.

WP Honeypot Guard doesn't patch anything and doesn't need to. It doesn't touch any existing plugin, theme, or core file — it just adds a tripwire around the site that catches the scanners looking for what's unpatched, before they find it.

It still works if something sits in front of your site

A lot of sites run behind Cloudflare or a similar service that sits between the visitor and the server. On a setup like that, blocking an IP address isn't as simple as it sounds — get it wrong and you're blocking the service passing everyone through, while the scanner you thought you'd shut out keeps coming in the front door.

WP Honeypot Guard works out for itself how your site is set up — direct, behind Cloudflare, or behind something else — and blocks whoever actually triggered the trap, not the service relaying their traffic. There's nothing to configure by hand. And it isn't fooled by a scanner faking its own address to dodge the block; try that, and it's your real address that gets shut out instead.

How you know it's working

The settings screen carries a plain checklist, so you're never just trusting that it's doing its job. It shows whether a block can be written, whether that block reads back correctly, whether your server actually enforces it, whether the scheduled clean-up that lifts blocks after an hour is running, and whether your server already turns away hidden files like .env on its own before the honeypot even gets a chance to catch them.

Anything left unchecked tells you exactly what's stopping it working. And if a block can't be written at all, you're told about it — in the dashboard — rather than left assuming you're covered when you're not.

An optional second layer: lock the login page

Beyond the honeypot, the plugin includes an optional "backend lock" you can turn on yourself as an admin. Turn it on, and wp-login.php and /wp-admin stop responding at all — unless the request includes a secret URL you set. A bot trying to brute-force your password never even reaches the login form.

This layer is off by default. Turning it on is a deliberate choice, because it comes with a real trade-off — read the next section before you flip it on.

If you lock yourself out

If you turn on the backend lock and then lose the secret URL — forget it, lose whatever you wrote it down in — there is no built-in bypass. That's not an oversight. If there were a backdoor around the lock, it wouldn't be a lock; it would be a second thing an attacker could find.

Recovery in that situation goes through your hosting company's control panel — File Manager or FTP — not through WordPress itself. Two ways to get back in, either works:

Add the disable constant documented in the plugin's readme to wp-config.php, which switches off the lock only — the honeypot decoy-blocking keeps running.
Rename or deactivate the plugin's folder in wp-content/plugins/ from File Manager or FTP. WordPress deactivates a plugin automatically the moment its folder disappears or is renamed.

To be clear: the honeypot decoy-blocking is always on and carries zero lockout risk — it only ever blocks IPs that request a fake path no real visitor touches. This risk exists only if you switch on the optional backend lock. Leave it off, and none of this applies to you.

Specifications

Everything below is what the plugin actually does. Where something only works on certain hosting, it says so.

Requirements: WordPress 4.0 or newer and PHP 5.6 or newer — deliberately low floors, because the sites this is built for are often the ones nobody has updated in years. Tested up to WordPress 6.6. It needs Apache, or a server that reads Apache's .htaccess files, with URL rewriting available and overrides permitted. It also needs to be able to write to the .htaccess file in your WordPress folder.
If it can't write: It tells you, in the dashboard, and the settings checklist marks the line that failed. It does not carry on quietly pretending to protect the site. If a scanner is caught at a moment when the block can't be written, that too is reported rather than swallowed — you're told the address got through.
Hosting it works on: Verified on plain Apache and on Plesk, HestiaCP and DirectAdmin hosting, with and without Cloudflare in front. A great many control panels — including cPanel-style ones — run Apache underneath and behave the same way, but only those four were measured.
Hosting it doesn't: Blocking is written as Apache instructions. On nginx-only hosting there is no .htaccess file and nothing reads those instructions, so the plugin has nothing to write a block into — it is not a supported setup and never has been. Nginx sitting in front of Apache, which is how several control panels are built, is fine: Apache is still the one enforcing the block. One caveat on that arrangement — some servers turn away requests for hidden files, the kind starting with a dot, before the honeypot ever sees them. Those particular traps are then inert while every other one still works, and the settings checklist tells you it can't settle that question from inside WordPress and gives you the one test that does.
What a block is: The offending address is refused by the web server itself, before WordPress or any plugin runs. It lasts an hour by default; the duration is a setting you can change. It expires on its own — nothing has to be remembered or cleaned up by hand — and a scheduled hourly job lifts anything past its time. You can also release an address early from the settings screen, and see everything currently blocked and since when.
Timing of releases: The hourly job runs on WordPress's own scheduler, which is driven by visitor traffic. On a quiet site a release can lag past the top of the hour. If you want it exact, point a real server cron job at WordPress's scheduler — the readme has the line.
Never blocked: Your server's own address, and any loopback, private or internal network address, are refused at the point a block would be written — under every circumstance, whatever triggered it. You can also list addresses of your own that must never be blocked, and any logged-in administrator is exempt automatically.
Behind Cloudflare or a proxy: It works out your setup for itself — direct, behind Cloudflare, or behind some other proxy — by asking your own site a question and seeing what shape the answer arrives in, and it re-checks if your hosting or CDN changes. Nothing to configure, though you can override it in your site's configuration file if you'd rather be explicit. It works whether or not your server can still be reached directly, and if it genuinely can't read your setup it says so and blocks nothing rather than guessing at an address and shutting out real visitors.
Can't be tricked: A scanner can claim any address it likes in the headers it sends, and plenty try. The plugin only ever reads the part of that information a sender is unable to reach, so a faked address can't get an innocent third party blocked — it gets the faker blocked instead. And the decoy trap itself answers a plain "not found" and reveals nothing at all about your site, the plugin, or whether anything was caught.
The optional lock: Off by default; described in full above. In spec terms: once on, the login page, the admin area and the XML-RPC endpoint are refused at the server unless the request carries what your secret URL sets, while the endpoint your theme's front end uses stays open so the public site keeps working. There is no bypass — that's the design, not an omission — and the documented recovery route is a line added to your site's configuration file via File Manager or FTP, which switches off the lock and leaves the decoy blocking running.
What it stores: Currently blocked addresses, each with the time it was blocked, held in your site's .htaccess file and removed when the block expires. A handful of its own settings in WordPress's usual settings storage. No new database tables, and no log of visitors, requests or traffic.
What it sends: Nothing about you or your visitors goes anywhere. The plugin makes exactly two kinds of outside request: it fetches Cloudflare's own published list of Cloudflare addresses, so it can tell a genuine Cloudflare request from one pretending to be, and it requests pages of your own site to check how requests arrive and that your server is honouring what it wrote. There is no telemetry, no phone-home, no account, and no reporting of blocked addresses to us or anyone else.

What it isn't

This is one narrow layer, and it's worth being blunt about where it stops:

It is not a firewall. It doesn't inspect requests for attacks, and it won't stop an attacker who goes straight for a real weakness without tripping a decoy first.
It is not a malware scanner. It doesn't examine your files and won't tell you whether the site is already compromised.
It is not a login rate-limiter. It doesn't count failed passwords or slow anybody down. The optional lock closes the login page off entirely, which is a different thing.
It doesn't patch anything, and can't. An out-of-date plugin is still out of date with this installed — it just gets probed less.
It doesn't block anything on its own reputation, or by country, or by any list of known-bad addresses. Only requesting a decoy gets an address blocked.

Keep whatever firewall or security plugin you already run. This sits alongside it.

Version history

Current release: 1.4.0. Most of what followed the first release came out of putting the plugin on real, live, awkwardly-configured sites and fixing what didn't hold.

1.4.0 11 September 2026: Blocks now actually bite on sites behind Cloudflare or a proxy. The right visitor was being identified, but the instruction written for the server was one it could never match, so a blocked scanner kept getting through the CDN — and on some setups that instruction could upset the server itself. Both are fixed. The settings screen gained the plain checklist that tells you whether each piece is working, including a live check that your server is honouring what the plugin wrote, and a block that couldn't be written is now reported instead of passing in silence.
1.3.2 11 September 2026: Fixed the record of what's blocked being read back wrongly on modern WordPress. The blocked list could show empty while a block was live, a second block could erase the first, and the hourly clean-up could clear blocks before their hour was up.
1.3.1 11 September 2026: Fixes to automatic setup detection found by running it across four different live hosting stacks. Detection now completes instead of always falling through to "couldn't tell", runs at a point in the WordPress start-up where it's safe, and correctly recognises servers that already sort the visitor's address out themselves. The settings screen stopped reporting a couple of things inaccurately.
1.3.0 11 September 2026: The plugin started working out for itself how your site is reached — direct, behind Cloudflare, or behind another proxy — with nothing to configure, and saying so plainly when it can't tell rather than guessing. Cloudflare's published address ranges are bundled and kept current. You can also add decoy paths of your own.
1.2.1 11 September 2026: Tightened the previous release: the plugin will only take a visitor's address from a proxy when you have explicitly told it which proxy to trust and where it connects from. A private-looking connection was not, on its own, good enough evidence.
1.2.0 11 September 2026: First support for finding the real visitor behind a reverse proxy, written so that a faked address can't be used to get somebody else blocked. Loopback, private and server-own addresses became impossible to block at the point the block is written.
1.1.0 11 September 2026: Added a broad trap around a place scanners routinely go looking for code that shouldn't be executable there. Released as an SEO Engineers product, with a "locked yourself out?" recovery guide added to the settings screen.
1.0.0 1 September 2026: First release. Decoy paths, an hour-long block for anything that requests one, the hourly release of expired blocks, the settings screen, and the optional backend lock.

Get the plugin

Free. Give us your email address and we'll send you the download link.

Frequently asked questions

Does this replace a full security plugin or firewall?

No. It's one lightweight layer that catches automated scanners probing for known compromised-plugin and backdoor URLs. Keep whatever firewall or security plugin you already run alongside it.

Will it work on an old, unmaintained WordPress install?

Yes — that's specifically what it's built for. It doesn't touch any existing plugin, theme, or core file, so there's nothing for it to conflict with.

What happens if I lock myself out of wp-admin?

That can only happen if you turn on the optional backend lock and then lose the secret URL. The honeypot decoy-blocking itself never locks anyone out. If you do lose the URL, recovery goes through your host's control panel, not through WordPress.

Is it really free?

Yes, no catch. Give us an email address and we'll send you the download link.

Need more than a free plugin? Our Vibe Code Security Audits and AppSec Assessments cover a full hands-on review, or see our SEO services.