Fstyle Honeypot Bot Blocker

No. When a request hits a trap and says it is Googlebot or Bingbot, the plugin checks it with reverse and forward DNS (IPv4 and IPv6). A verified crawler gets a 404 instead of being blocked. Logged-in administrators are never blocked either.

Blocks expire after 7 days (change this with the fstyle_honeypot_block_days filter). To unblock sooner, click "Unblock" in Recent Blocked Logs (only the latest 50 blocks are listed; older ones expire on their own), or add the address to the whitelist (one IP address or CIDR range per line). If you cannot reach the login screen, log in from another network, or rename the plugin folder in wp-content/plugins over FTP to turn the plugin off, log in, and unblock the address.

The plugin blocks the address in REMOTE_ADDR. Proxy headers such as X-Forwarded-For are not trusted, because anyone can send them. Behind Cloudflare, a load balancer or another reverse proxy, make sure your server puts the visitor's real address into REMOTE_ADDR (for example mod_remoteip on Apache or the real_ip module on nginx, set up for your proxy's IP ranges), or return it from the fstyle_honeypot_client_ip filter. Otherwise one bot could get the proxy, and every visitor behind it, blocked. The settings screen shows a warning when the site seems to be behind a proxy.

Each site gets its own random trap path (for example /private-k3x9q2m7wa/), shown on the settings screen and added to robots.txt as Disallow. Well-behaved crawlers never visit a disallowed path, so a client that requests it is ignoring robots.txt and is blocked. Because the name differs from site to site, bots cannot learn it once and skip it everywhere. The name used before 1.5.0, /super-secret-admin-area/, is still a trap. Your own trap paths (Trap Settings) are blocked when requested, but are not listed in robots.txt.

Then WordPress does not generate robots.txt, and the trap line is not added automatically. Add the Disallow line shown on the settings screen under User-agent: * in your file. The settings screen reminds you when a robots.txt file exists. Requests to the trap paths are blocked either way.

In most cases, no. If a page on another site makes a visitor's browser load a trap path (with an image, a script or a link), the browser says so in the Sec-Fetch-Site header, and the plugin answers 404 without blocking. Bots and scanners normally do not send this header, so they are still blocked. A trap word in the query string does not count either.

It checks the requests that reach WordPress. If your server already refuses .env or .git (for example with a deny rule), or a cache in front of WordPress answers the request, the plugin does not see it.

Yes, from version 1.4.0, but the Contact Form 7 protection is off by default. Turn it on in "Fstyle Blocker" > "Contact Form 7 Protection". It adds a hidden field (people never see it, bots often fill it in) and records the time from opening the page to sending the form. A submission that fills in the hidden field, is sent faster than the shortest time (3 seconds by default), or is sent without JavaScript is treated as spam by Contact Form 7, and the visitor sees Contact Form 7's spam message.

The messages are still sent, and the plugin only counts the submissions it would have blocked. Use it for a while to compare with your current spam protection (for example reCAPTCHA) before switching to "Block".

No. The check runs on your server. Only daily counts and the latest detections (time, form ID and reason, no personal data) are kept in your site's options.

Clear the page cache after turning the protection on, so that cached pages include the new fields. Forms on pages cached before that are not judged (they are counted as "Not judged"). The timer is written by JavaScript in the browser, so cached pages keep working.