Will this affect my SEO?
No. Trap links are hidden from humans using CSS and include rel="nofollow" . Trap pages send X-Robots-Tag: noindex, nofollow headers. The plugin also adds Disallow rules to robots.txt for the trap path.
How does the robots.txt rule work in this plugin?
The plugin adds a Disallow rule for the trap base path so well-behaved crawlers (Googlebot, Bingbot, and similar) stay out of the trap maze instead of wasting crawl budget on it.
It does this through the robots.txt that WordPress generates — the “virtual” robots.txt — using the standard robots_txt filter. It does not write a file to your server. What this means in practice:
- No physical robots.txt file: the rule is added automatically, alongside whatever WordPress and other plugins (e.g. your SEO plugin’s sitemap line) already output.
- A static robots.txt file exists at your site root: your web server serves that file directly and WordPress never runs, so neither this plugin nor any other can modify it. The rule will not appear until you add it to that file.
- An SEO plugin manages robots.txt: the rule is added at a late priority so it survives plugins that replace the generated file (such as Rank Math’s editor). Yoast appends without removing other rules, so it is unaffected. If the rule still doesn’t appear, add it through that plugin’s robots.txt editor.
The Settings page verifies whether the rule is actually being served and, if it isn’t, shows you the exact lines to add:
User-agent: * Disallow: /your-trap-base-path/
(replace your-trap-base-path with your configured Trap Base Path). For safety, the plugin never creates or overwrites a physical robots.txt on its own — creating one would shadow WordPress’s virtual file and drop other plugins’ directives. Where a writable robots.txt already exists, it offers an optional one-click button to append the rule for you; otherwise it shows the lines to paste.
Does it work with caching plugins?
Yes. Trap link injection happens during content rendering, so cached pages will include the trap links. The trap pages themselves are served dynamically and should be excluded from page caching (they use custom query vars that most caching plugins ignore by default).
What happens to legitimate crawlers like Googlebot?
Known search engine crawlers are verified via reverse DNS lookup. Verified crawlers are exempted from bot scoring even if they follow trap links.
Can I customize the trap page content?
Trap pages are generated from a built-in content template engine that produces realistic-looking text. The content varies based on a seed value to ensure each page looks different.
What is the difference between the blocking behaviors?
Block (403) — Returns a 403 Forbidden response. Lowest server cost. Light tarpit — Serves a decoy trap page with more trap links. No delay. Full tarpit — Same as light tarpit but adds a 1-second delay, holding the PHP worker longer.
How do I know it’s working?
Check the Bot Maze analytics dashboard in the WordPress admin. It shows total trap visits, unique bot IPs, score distribution, and top offenders.
Why does a blocked bot show no AbuseIPDB report?
A dash in the Reported column on the Blocked Bots page means no report has been accepted for that address yet. The usual reasons, in the order worth checking:
- 01Reporting is off, or has no API key. Nothing is ever queued until both are set.
- 02The bot was blocked before you switched reporting on. Reporting fires when a score crosses the blocking threshold, and a bot that crossed it earlier will not cross it again. Use the catch-up button on the Blocked Bots page.
- 03It was last seen longer ago than your data retention period (Settings > Bot Maze > Maintenance, 30 days by default). The catch-up only offers addresses inside that window, because past it the plugin deletes the bot’s record anyway. An address that falls outside will not be offered again, since a blocked bot stops accumulating visits.
- 04It was reported in the last 24 hours already , under a different user agent for the same address.
- 05The address is not publicly routable — a private, loopback, reserved, documentation or multicast address. AbuseIPDB only accepts reports about addresses reachable on the public internet. This usually means the site is behind a proxy and the trusted proxy settings need attention, since the recorded address is the proxy’s rather than the visitor’s.
- 06Delivery has not caught up. Reports leave in small batches through WP-Cron, so a large catch-up takes hours. Settings > Bot Maze > AbuseIPDB Reporting shows how many are still pending.
Verified search engine crawlers are never scored, so they never reach the Blocked Bots page at all.
Is the Cloudflare trusted client IP setting safe to enable?
Cloudflare mode trusts the CF-Connecting-IP header only when the request comes from Cloudflare’s published edge IP ranges. Because those edge IPs are shared by every Cloudflare customer , this proves a request came from some Cloudflare edge, not specifically from your zone.
In plain terms: your server must not be reachable directly by its own IP address — only through Cloudflare. Putting your site behind Cloudflare’s proxy (the orange cloud) hides your server’s IP but does not block direct connections to it; if someone discovers the IP, they can still reach the server and bypass Cloudflare. A quick check: if your site still loads when you request it by its raw server IP, the origin is exposed.
To lock the origin down, use any one of: Cloudflare Tunnel (your server has no public inbound port at all), Authenticated Origin Pulls (the origin requires Cloudflare’s client certificate), or a firewall that allows inbound web traffic only from Cloudflare’s IP ranges. If your origin stays reachable directly, visitor IP attribution can be influenced by requests outside your zone, and bots can bypass Cloudflare’s own protections by hitting the origin directly.
