Block Groups

Most non-trivial websites are hammered around the clock by bots probing for /wp-admin/, /phpmyadmin/, /.git/HEAD, /wp-config.php, /shell.php, and a long tail of similar paths. If your site doesn't run that stack, serving even a 404 is wasted bandwidth, wasted origin CPU, and pollution in your analytics and firewall dashboards.

Block Groups give you curated, opt-in lists of these path patterns. Enable a group on a domain and matching requests get a bodyless 404 at the edge — before any upstream fetch.

Free on every plan. Disabled by default per domain; you opt in to the groups that fit your stack.

How it works

Visitor → Serpwise edge → ┐
                          ├─ path matches an enabled block group?
                          │     yes → return 404, never reach origin
                          │     no  → continue normal request flow
                          ▼
                       Origin

Matching happens after AI Access decisions and before the redirect/cache/ rules pipeline. Per-domain matchers are compiled once at config load — the hot path is a single regex automaton scan over your enabled groups, sub-microsecond in practice. Adding more groups doesn't slow real traffic.

Available groups

We curate these lists from CrowdSec community blocklists, OWASP CRS, and the 404 patterns we see hitting actual Serpwise customer domains. Lists update with every gateway release — no config change needed on your end.

Block mode vs monitor mode

Each subscription has a mode you control per group:

• Block — matching requests get a bodyless 404 immediately. This is the default when you enable a group.
• Monitor — matching requests are logged but pass through to origin unchanged. Use this if you want to see what would be blocked before committing to active blocking.

You can switch a group between modes any time. Changes take effect within a few seconds on every edge node.

Bot filter

Each block group also has a bot filter controlling who the block applies to:

• All traffic (default) — block every matched request, regardless of who sent it. This is the right mode for groups that match paths no human ever legitimately requests (/xmlrpc.php, /.git/*, /phpinfo.php).
• Known bots only — block only requests classified as bots by the gateway or matching one of your custom User-Agent substrings. Humans hitting the same path pass through to origin.

The bot filter is the right tool for protecting paths that real humans also hit — like WordPress admin login. With the filter set to Known bots only, the gateway lets you log in normally from any browser, but 404s scripted brute-force traffic that announces itself with python-requests/2.x or a known bot User-Agent.

Custom bot patterns

Under the bot filter you can add your own User-Agent substrings to the "bad bot" list. The match is case-insensitive substring — no regex. Common picks the dashboard offers as one-click chips:

AhrefsBot   SemrushBot   MJ12bot   DotBot   PetalBot
python-requests   curl/   wget/

Avoid short generic substrings like bot — they'll match real bots you want to allow (Googlebot) and incidental browser strings too. The dashboard enforces a 2-character minimum and rejects regex metacharacters.

IP allowlist

Every block group also accepts an IP allowlist. Requests coming from an allowlisted IP bypass the block group entirely — they're recorded as allowlisted in the request log but otherwise treated as normal traffic.

• IPv4 (203.0.113.42, 203.0.113.0/24) and IPv6 (2001:db8::1, 2001:db8::/32) are both accepted.
• Bare IPs without a prefix are promoted to /32 (v4) or /128 (v6) on load — 203.0.113.42 and 203.0.113.42/32 are equivalent.

Find your current IP at ipinfo.io. For office networks behind a stable egress IP, the /24 form covers the whole block in one entry.

Evaluation order

When a request matches a block group's path patterns, the gateway runs these checks in order:

1. IP allowlist — if the client IP is allowlisted, pass through.
2. Bot filter — if set to "Known bots only" and the request doesn't look like a bot, pass through.
3. Safe-default fallback — for groups that require an allowlist (wordpress-admin), if no allowlist is configured the group drops to monitor-only so admins never get locked out by an empty config.
4. Verified search bots — Googlebot and Bingbot are always exempt.
5. Block — return 404.

Enable for a domain

1. Open the domain → Settings → Security, then click the Block Groups tab.
2. Toggle the groups that fit your stack.
3. Each group defaults to block mode. Switch to monitor mode for a few days first if you want to be cautious.

That's it. No origin code, no firewall config, no waiting on engineering.

The Block Groups tab is bookmarkable: ?securityTab=block-groups opens it directly.

See what's been blocked

The org dashboard surfaces a Blocked bot requests this week widget with the weekly total, a daily sparkline, and the top three groups by hit count. The Block Groups sub-tab also shows a per-group seven-day count so you can see which lists are pulling their weight.

Everything is logged in the standard request log too — block_group_key, block_mode, and fp_signal columns are populated for any request that matched a group.

False positives

When a request that matched a block group looks like it might be a real visitor — for example, the Referer comes from a legitimate page on your own domain — Serpwise records a false-positive signal alongside the block event. In monitor mode this is logged and the request continues normally. In block mode the 404 is still returned (the curated lists are tight enough that real users hitting these paths are extremely rare), but the signal is captured so we can review and tune the curated lists across all customers.

If you ever see a legitimate path being blocked, disable the relevant group or flip it to monitor mode while you sort it out, and let us know — we review false-positive candidates regularly and prune patterns that cause real-world friction.

What is never blocked

• Verified search engine crawlers (Googlebot, Bingbot) — even in block mode, block groups never deny these. Real search bots probing odd paths is rare but possible, and staying invisible to them is cheap insurance.
• Allowlisted IPs — anything you put on a group's IP allowlist bypasses it entirely.
• Humans on "Known bots only" groups — when the bot filter is set to "Known bots only", requests that don't look like bots pass through regardless of the path match.
• Anything outside the enabled groups. Paths you haven't subscribed to are forwarded to origin exactly as before.

Legacy wordpress group

The original combined WordPress group was retired in favor of wordpress-probes + wordpress-admin. Existing subscriptions were migrated automatically to wordpress-probes — you keep the safe blocking behavior for the always-illegitimate paths. To protect /wp-admin and /wp-login.php, subscribe to wordpress-admin and add your admin IP to the allowlist (or enable the bot filter).

Limitations

• Custom block groups aren't editable from the dashboard. The curated catalog is maintained by Serpwise. If you want to block a path pattern not covered by an existing group, use a Rule instead.
• Bot filter is User-Agent based. A determined attacker can spoof a browser User-Agent and slip past "Known bots only". For high-value paths, combine the bot filter with the IP allowlist — the allowlist is the stronger control.
• Not a WAF. Block Groups handle one specific, high-leverage class of noise: known hacking-attempt path patterns. For application-layer attacks inside legitimate routes (SQL injection in a query string, request smuggling, etc.), see Shield and your origin's WAF.