TrustSig Security vs JTZL's Bot Maze

JTZL’s Bot Maze protects your WordPress site from unwanted AI crawlers and scrapers by planting invisible trap links that only bots will follow. When a bot enters the trap maze, it gets lost in an ever-expanding maze of realistic-looking fake pages while it quietly builds a suspicion score based on its behavior. How it works: Trap link injection — Invisible links are added to your real pages. Legitimate visitors never see them, but bots following every link on the page will enter the trap maze. Lazy maze generation — Trap pages link to more trap pages, generated on demand. The deeper a bot goes, the more time it wastes. Bot scoring — Each trap page visit adds suspicion points. Deeper traversal earns bonus points. Once a threshold is reached, the visitor is flagged as a bot. Blocking and tarpitting — Flagged bots can be blocked outright (403), served decoy pages (light tarpit), or slowed down with a deliberate delay (full tarpit). Crawler verification — Known search engine crawlers (Googlebot, Bingbot, etc.) are verified via reverse DNS and exempted from scoring. Features: Zero impact on legitimate visitors — trap links are hidden from humans and search engines Configurable injection method (content, footer, or both) Adjustable scoring thresholds and blocking behavior robots.txt integration to signal trap paths as disallowed Analytics dashboard showing bot activity, top IPs, and score distribution Blocked Bots detail page showing full user agent, score, visit history Optional comprehensive tracking mode to monitor blocked bot persistence Automatic log retention and maintenance via WP-Cron Privacy policy suggestion for GDPR compliance Geographic heat map of bot activity by country with two GeoIP provider options MaxMind GeoLite2 local database — all lookups on your server, GDPR-friendly (recommended) ip-api.com external API — simple setup, no license key required Optional AbuseIPDB reporting for eligible blocked public IP addresses, with a one-press catch-up for blocked bots that carry no report yet Lightweight — minimal footprint, geographic tracking is fully optional Third-Party Services Every external service listed below is optional and off by default. No data is sent to any of them unless a site administrator explicitly enables the corresponding feature. MaxMind GeoLite2 (Recommended) When MaxMind GeoLite2 is selected as the GeoIP provider (Settings > Bot Maze > Geographic Tracking), the plugin downloads the GeoLite2-Country database from MaxMind and performs all IP-to-country lookups locally. No visitor data leaves your server. What is downloaded: The GeoLite2-Country database (~60 MB), downloaded weekly via WP-Cron from download.maxmind.com. What is sent to MaxMind: Only your license key during database downloads. No visitor IP addresses are shared. Requires: A free MaxMind license key from maxmind.com/en/geolite2/signup. Service website: https://www.maxmind.com License: GeoLite2 databases are licensed under CC BY-SA 4.0. Terms of service: https://www.maxmind.com/en/geolite2/eula ip-api.com When ip-api.com is selected as the GeoIP provider, the plugin sends visitor IP addresses to ip-api.com to resolve their country of origin. This data is used to display a geographic heat map of bot activity in the admin dashboard. What is sent: The visitor’s IP address only, over unencrypted HTTP. When it is sent: At the time a trap page visit is recorded, only while this provider is selected. Service website: http://ip-api.com Terms of service: https://ip-api.com/docs/legal Privacy policy: ip-api.com does not log queries from the free API endpoint. Note: The free tier only supports HTTP (not HTTPS). If your site must comply with GDPR, use the MaxMind local database option instead. Geographic tracking is off by default and requires explicit opt-in by a site administrator. AbuseIPDB Reporting AbuseIPDB reporting is off by default. It requires explicit enablement plus an administrator-owned AbuseIPDB account and API key from the API dashboard. Protect the API key like a password. An address is queued for reporting in exactly three situations: A non-verified crawler’s persisted score crosses the configured blocking threshold. An address that is already blocked requests a trap page while reporting is on, which is fresh evidence it is still crawling the maze. An administrator presses the catch-up button on the Blocked Bots page, which covers blocked addresses AbuseIPDB has not accepted a report for, whatever the reason. Every queued address must also be publicly routable. Private, loopback, reserved, documentation and multicast addresses are never reported, because AbuseIPDB only accepts reports about addresses reachable on the public internet. Verified search engine crawlers are never scored in the first place, so they are never candidates. The catch-up in (3) reports each address against the time it was actually last seen, rather than the time the button was pressed, and covers addresses seen within your configured data retention period (Settings > Bot Maze > Maintenance, 30 days by default). That is the period you have declared this evidence meaningful for, and the same period after which the plugin deletes the record, so the catch-up offers exactly the blocked addresses your site still holds evidence for. It reports up to 500 addresses per press. In all three cases the report sends only the public IP address, category 19 (Bad Web Bot), the time of the observation being reported, and a generic explanation for security reporting. It sends these four fields over HTTPS to the AbuseIPDB service. It never sends the user agent, referrer, trap URL, session, score, or traversal depth. The plugin limits reports to once per IP address in any 24-hour period. A queued report that cannot be delivered for seven days is abandoned. Delivery runs in the background through WP-Cron, so reports may wait on low-traffic sites and are not real-time. Disabling reporting or clearing the key stops delivery and deletes queued reports. The current free Individual plan includes 1,000 IP checks and reports per day. See AbuseIPDB pricing; your account limit may differ. Review AbuseIPDB’s terms and privacy policy before enabling reporting. Cloudflare IP Ranges When the Trusted Client IP Header is set to Cloudflare (CF-Connecting-IP) (Settings > Bot Maze > Trusted Proxy), the plugin fetches Cloudflare’s published edge IP range lists from cloudflare.com to keep the trusted-proxy allowlist current without any manual action. What is requested: Two public plain-text files — cloudflare.com/ips-v4 and cloudflare.com/ips-v6 — fetched weekly via WP-Cron. What is sent: No visitor or user data. The HTTP request reveals only your server’s own IP address to Cloudflare. Service website: https://www.cloudflare.com Terms of service: https://www.cloudflare.com/terms/ This fetch only runs while the Cloudflare trusted client IP header is selected. If the fetch fails validation, the previously stored list (or a bundled fallback) is kept — a failed response never narrows or widens the trusted set.

TrustSig Security stops scripted bots and brute-force attacks on WordPress forms and API endpoints. There are no puzzles to solve and no “I am not a robot” checkboxes to tick, and you do not have to sign up for anything before it starts working. What exactly gets checked depends on the protection mode you pick, described below. Why TrustSig Covers the forms that matter out of the box: login, registration, comments, password reset, WooCommerce checkout, BuddyPress signup, Easy Digital Downloads, Elementor Pro forms, WPForms (including the Mesmerize and Materialis contact form), Contact Form 7, SureForms, plus any custom form via a shortcode. Locks out brute-force login attempts after repeated failures. Real visitors never notice it. The browser check runs on its own and finishes in about a second, with no images to click. Three protection modes: Monitor logs and never blocks, Challenge (the default) shows a short interstitial and retries, Enforce blocks outright. Nothing to configure. Activate the plugin and protection is live. The anonymous free tier needs no account. Works with caching plugins, WPML, multisite and most themes, because forms are signed server-side with a per-site secret. A developer API: the PHP helper trustsig_verify(), the REST endpoint /wp-json/trustsig/v1/verify, and filters and actions for custom forms. An optional guard for admin-ajax and the REST API on sites that need it. An optional scan-on-submit mode that runs the browser check only when a visitor actually uses a form, not on every page view. GPLv2, fully open source. How it works TrustSig loads a small browser SDK, signs every rendered form with a per-site secret, and checks submissions against the TrustSig Edge service. A real visitor passes the check in about a second without doing anything. A scripted client that never runs JavaScript produces no token and gets stopped. When a request arrives without a valid token, the plugin does not quietly wave it through. Depending on the mode, it either serves a short “please wait” page that re-verifies the browser and then continues the original request, or blocks it. No account and no API keys are needed; the anonymous free tier is the default. Connecting a TrustSig dashboard account is optional and only adds analytics and higher limits. Protection modes Monitor: verify and log only, never block. Good for a safe rollout. Upgrades also pin existing sites here, so behaviour never changes silently on update. Challenge (default for new installs): a missing or invalid token triggers the interstitial, which then continues or blocks. Enforce: a missing or invalid token is blocked immediately. What it protects Browser forms are covered automatically, no code needed: WordPress core: login, registration, comments, lost and reset password WooCommerce: login, registration, checkout, pay order, lost password BuddyPress: registration Easy Digital Downloads: login, registration Elementor Pro forms WPForms: contact and other forms, on by default (this also covers the Mesmerize and Materialis contact section) Contact Form 7: feedback submissions, on by default, guarded on the REST endpoint CF7 submits to SureForms: form submissions, on by default, guarded on the REST submit-form endpoint Anything else via the site-wide “protect all forms” option, the [trustsig_form] shortcode, or a hidden trustsig-response input On top of that there is an optional brute-force lockout for repeated failed logins, an opt-in guard for admin-ajax and the REST API, and a verification API for developers. For developers PHP: trustsig_verify( array( ‘token’ => $t, ‘action’ => ‘my_form’ ) ) returns pass, fail or challenge. Filters: trustsig_pre_verify, trustsig_result. Action: trustsig_blocked. REST: POST /wp-json/trustsig/v1/verify with { “token”: “…” }. Known limitations XML-RPC (xmlrpc.php) is deliberately out of scope and is not verified. If your site does not use XML-RPC, disable it separately. admin-ajax and the REST API are only guarded when you enable that in Settings. This is on purpose, so third-party integrations do not break the moment you install the plugin. File uploads and AJAX submissions cannot show the interstitial. In Challenge or Enforce mode a missing token on those is blocked. It is never silently allowed. External services This plugin relies on the TrustSig Edge service to decide whether a request comes from a human or an automated client. That verdict cannot be produced locally, so the service is required for the plugin to do its job. Service provider: TrustSig, https://trustsig.eu Remote script loaded in the browser: https://edge.trustsig.eu/trustsig.js loads on pages that contain a protected form, on the login screen, and on the verification interstitial. It runs the non-interactive browser check and produces a verification token. Data sent from the visitor’s browser or your server to https://edge.trustsig.eu/verify: the TrustSig verification token generated by the SDK in the visitor’s browser; your site’s host name (for example example.com) on the anonymous free tier, or the secret key you entered if you connect a dashboard account; as with any HTTPS request, the visitor’s IP address and standard request metadata such as the user agent are visible to the service. When data is sent: when the SDK loads on a protected page, when a protected form is submitted, and once per browser when the optional verified-session cookie is bootstrapped. Data stored locally on your site: TrustSig writes a verification log to your own WordPress database (custom tables) with visitor IP addresses, the action attempted, and the verdict. This log is not sent to TrustSig, and you can clear it at any time under Settings, TrustSig, Tools. By installing and activating this plugin you, the site administrator, consent to this data being sent to TrustSig so that requests can be verified. Inform your own visitors as your local privacy obligations require. Terms of Service: https://trustsig.eu/terms-of-service/ Privacy Policy: https://trustsig.eu/privacy