Pages that hold a single form – a contact page, a quote request, a download gate – get hammered by scanners and spam bots. The first real damage is to your analytics: page views are inflated and you can no longer read what visitors actually do.

Watrix Bot Guard catches the source of that traffic with four kinds of rules and lets you decide how to deal with it:

Path flood – the same IP hitting a specific path (e.g. /contact/) too many times in a short window
404 burst – vulnerability scanners walking through hundreds of non-existent URLs
Trap URL – a hidden link that is disallowed in robots.txt; only bots that ignore it will ever follow it
Bad User-Agent – empty user agents and signatures of scanners, headless browsers and HTTP libraries

Rules can be added, edited and disabled individually, each with its own paths, threshold, action and block duration.

Record first, block later

Right after activation the plugin runs in log-only mode: every rule records what it sees and nobody is blocked. Look at the dashboard after a few days, see whether the traffic comes from a handful of IPs or is spread out, and only then switch to enforce mode – or take the generated .htaccess / nginx snippet and block those IPs in front of PHP.

Reduce what you expose

A separate screen, Bot Guard Hardening, turns down the amount of information your site hands out to anyone who asks. Every switch there is off by default and can be turned on one at a time.

REST user list – out of the box WordPress answers /wp-json/wp/v2/users to anyone, and the slug it returns is usually the login name. Turning this on returns 401/403 to visitors without the list_users capability, while logged-in editors, the block editor and application-password integrations keep working exactly as before. The oEmbed endpoint keeps answering, because other sites rely on it to embed your posts – only the author_name and author_url fields, which carry the same slug, are dropped. The rest of the REST API is untouched – the WooCommerce Store API, contact form plugins and the block editor all keep their endpoints.
Security headers – X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, Strict-Transport-Security and Content-Security-Policy, each with its own switch. A header another plugin has already sent from PHP is never sent twice. Headers added by nginx or Apache are invisible to PHP, so check the real response once after switching something on. HSTS is only ever sent over HTTPS, and includeSubDomains / preload stay off unless you deliberately ask for them. CSP has no default value at all: it ships empty, front-end only, and can be tried as Content-Security-Policy-Report-Only first.
Version disclosure – removes the <meta name="generator"> tags emitted by WordPress core, WooCommerce and Site Kit by Google, in HTML and in the feeds.

Hiding a version number does not make an old version safe. The screen says so, plainly: the real fix is keeping WordPress, themes and plugins updated, and this is the supporting act.

What else is included

Verified crawler exclusion – Googlebot, Bingbot, Applebot and others are let through only after a reverse-then-forward DNS check; a crawler that claims to be Googlebot but fails the check is treated as a fake and blocked
Allow list with CIDR and IPv6 support for your own office and your client’s office
Optional grouping by subnet (/24 for IPv4, /64 for IPv6)
Early blocking – already-blocked IPs are stopped on init, before the main query runs
Dashboard with per-rule, per-IP, per-path and per-user-agent breakdowns of the last 7 days
Access log with filters and CSV export
Manual block list
Server-side snippets: Apache .htaccess, nginx deny, and a plain IP list for your analytics tool’s internal-traffic filter
Settings export / import as JSON to roll the same configuration out to other sites
WP-CLI: wp bot-guard top | blocks | block | unblock | mode | export | settings | cleanup
Optional e-mail / webhook notification when a new IP is auto-blocked (throttled to one per hour)
Daily cleanup of expired blocks and of log rows older than the retention period

What it deliberately does not do

Login protection and two-factor authentication – there are dedicated plugins for that
Country blocking – it would require bundling a GeoIP database

Privacy

The plugin stores the IP address, request path, user agent and referrer of requests that match a rule, in your own database, for the retention period you set (30 days by default). Nothing is sent to WATRIX or to any third party. If you configure a webhook URL, block notifications are sent to that URL and nowhere else. An optional “anonymize IP” setting masks the last octet before storing.

The verified-crawler check performs DNS lookups (reverse and forward) against the visitor’s IP. Results are cached for 12 hours.