Block abusive IPs

In short. The Blacklist is a single admin page at /sg-admin/blacklist/ where you block source IP addresses, CIDR ranges, and wildcards. Saved rules take effect on the next request — no cache flush needed. One pattern (*.*.*.*, 0.0.0.0/0, or ::/0) blocks every visitor including you; avoid it entirely.

On this page: What this is for · What not to use it for · Steps to add a block · Test IP tool · Edit or remove · Troubleshooting · Scope

The Blacklist is a single admin page where you add IP addresses you want blocked from your site. Once a rule is saved, the next time someone from that IP tries to reach your site, they are redirected away automatically. This walkthrough covers the everyday cases — blocking a spam source, blocking a range of bad actors, and checking whether a specific IP is currently blocked — and one pattern that will lock you out of your own site if you are not careful.

Before you do anything, read the first anti-pattern below. There is one specific input that will block every visitor including yourself, with no way to recover from the admin UI. Know what it looks like before you start typing.

What is this for?

The Blacklist is a response tool, not a prevention tool — use it after identifying a source of abuse (a bot hammering your contact form, a scraper that keeps returning, a botnet range you noticed in your server logs). It blocks by source IP address only — there is no filter by email, user agent, country, referrer, or keyword.

Good use cases

Example 1: A bot is hammering your contact form with spam. You check your server logs or Discussions spam queue and notice 200+ submissions over the last hour from 198.51.100.42. Open /sg-admin/blacklist/ and add that IP as a new entry. Note the ticket number in the Reason field so you remember why later:

The next time a request arrives from that IP, the Hits counter increments and the visitor is bounced away before your contact form ever loads.

Example 2: Several bad actors are coming from the same range. Rather than entering 50 individual IPs, use CIDR notation to block the whole range in one entry. 198.51.100.0/24 covers 256 addresses (198.51.100.0 through 198.51.100.255). You can also use IPv4 wildcards like 198.51.100.* for the same effect. After a few matches the list looks like this:

Each row shows a live Hits counter that increments every time a visitor from that IP is blocked. That tells you which rules are doing real work and which are stale.

Example 3: A known attacker is coming from IPv6. The Entry field accepts IPv6 single addresses (2001:db8::1) and IPv6 CIDR (2001:db8::/32) the same way it accepts IPv4. The validator recognizes both families.

What NOT to use this for

1. Never enter ..., 0.0.0.0/0, or ::/0.

These three patterns match every IP address. Saving any of them will block every visitor to your site, including you, starting on the next page load — there is no admin bypass, no whitelist, no safe mode. Your admin session becomes irrelevant because the block runs before the session check. Recovery requires direct database access (which most customers do not have without opening a support ticket).

If you are tempted to "test the validator by entering a wildcard," stop. The validator currently accepts all three of these patterns. The wildcard help text under the Entry field lists 192.168.*.* as a legitimate example — and that is fine — but the four-star wildcard pattern is not. This is behavior to know, not a bug to experiment with.

If you are migrating a blacklist from another platform, audit every row before pasting. A single overly-broad CIDR is enough to take you offline.

2. Do not blacklist your own current IP.

You and your visitors often share an IP, especially in offices behind a single firewall or on mobile carrier networks. Blocking a visitor's IP blocks anyone else on the same network — including you if you are sitting there. Before you add any entry, confirm what you are blocking. Open a second browser tab, visit https://api.ipify.org, and make sure your own public IP does not match the rule you are about to save.

3. Do not rely on IP blocking as long-term anti-abuse.

Attackers rotate IPs constantly — VPNs, proxies, residential botnets, Tor exit nodes. A small handful of entries will stop lazy or one-off abuse. If your list is growing past 100 active entries and abuse is still ongoing, you need a WAF (Cloudflare, AWS WAF), rate limiting at the edge, or captcha on your forms. The Blacklist is a scalpel, not a shield.

4. Do not block an entire residential ISP range.

Home ISPs recycle IPs every few days. A residential /16 can include tens of thousands of legitimate users. Use /24 or narrower when the abuser is on residential, and prefer exact IPs for fewer than a dozen bad addresses.

5. Do not assume blocked visitors see a friendly "you are blocked" page.

Blocked visitors are currently redirected to https://www.google.com/. That means the visitor lands on Google, not on a page that explains what happened. Some people will think your site is down or their DNS is misconfigured. They will not see an error, they will not understand that they have been intentionally blocked, and they have no way to appeal. If a visitor complains that your site is sending them to Google, check the Blacklist first.

Before you start

• You are signed in as an admin with access to the Blacklist.
• You know the exact IP address, CIDR range, or wildcard you intend to block.
• You have confirmed that IP is not your own and is not shared with any legitimate visitor you care about.

Where to go

1. Open the left navigation.
2. Select Blacklist. You land on /sg-admin/blacklist/.

That is it — the whole feature is a single page. The left card is the add/edit form; the right card is the list of existing entries with the bulk-action toolbar, search, and Test IP tool above it.

Steps to add a block

1. Enter the IP, CIDR, or wildcard

Type the source you want to block into the Entry field. The validator accepts:

2. Fill in the reason

The Reason field is optional but use it. Include the ticket number, the log line that flagged the IP, and the date — you will need the context when cleaning up stale rules later.

3. Click Blacklist item

You land back on the list view with a green success banner. Your new entry appears in the table with a Hits column at 0.

Check whether a specific IP is currently blocked

Above the list there is a Test IP tool. Paste any IP and click Test — the admin page tells you whether any rule currently matches, and if so which rule.

This handles the most common support question: "a visitor says they cannot reach my site — is it me blocking them?" Paste their IP, hit Test, and you have your answer without opening the database.

Edit or remove an entry

Click Edit on any row to update the Entry or Reason. The left card switches to update mode with the entry prefilled:

Edits preserve the Hits counter, created date, and author attribution. Changing the Entry field is effectively a new rule — traffic matching the new value is blocked on the next request.

To remove entries, either click Delete on a single row (with confirmation) or tick the checkboxes for multiple rows and use the bulk dropdown. Single-row delete shows a confirmation dialog before removing the entry:

The only bulk action is Delete — there is no pause or disable state. An entry either exists (blocks) or it does not (allows). To stop blocking, delete the entry.

What success looks like

• Your new entry appears at the top of the list with a Hits counter at 0.
• The next time a visitor matches, the Hits counter increments and Last Matched updates.
• The Test IP tool, with the blocked IP pasted in, returns a green "is blacklisted by .." banner.

What to do if it does not work

• Hits stays at 0 for days. Either no real traffic matches your rule (abuse has moved elsewhere — consider deleting), or your rule is too narrow (paste a specific IP you know should match into Test IP; if Test says "not blacklisted", the rule is not what you think it is).
• A legitimate visitor is complaining they cannot reach the site. Paste their IP into Test IP. If it matches a rule, you have a false positive — delete or narrow that rule.
• You locked yourself out. If you entered a match-all wildcard or a CIDR that includes your own IP, the admin page is unreachable. Contact support with your account details and the time of the change. Recovery is database-level; there is no self-service path.

How this connects to other features

• Redirects — Redirects match URLs and send visitors elsewhere; the Blacklist matches source IPs and blocks entirely. URL-pattern blocking belongs in Redirects. Visitor IP blocking belongs in the Blacklist.
• Forms and Discussions — Most abuse surfaces here first. Check source IPs in Forms or Discussions, then add the worst offenders to the Blacklist. The Blacklist is reactive; use it after you have identified the source, not speculatively.

Scope

This reference covers the Blacklist feature — the admin tool for blocking IP addresses, CIDR ranges, and wildcard patterns from accessing your SGEN site. It applies to all SGEN plans. It does not cover:

• Blocking by URL pattern — use the Redirects feature for that.
• Rate limiting or DDoS mitigation — those require infrastructure-level controls outside SGEN.
• Blocking specific users or accounts — that is handled via the Users area.
• Geographic blocking — SGEN does not support country-level blocking.

Examples

Example 1: Blocking a brute-force login IP. The site owner sees repeated failed login attempts in the admin activity log from 192.0.2.14. They open the Blacklist, enter 192.0.2.14, add reason "brute-force login, 2026-04-22", and save. The IP is blocked on the next request.

Example 2: Blocking a CIDR range from a spam hosting provider. The site owner identifies that all form spam is coming from the 203.0.113.0/24 range (a known spam hosting block). They enter 203.0.113.0/24 into the Blacklist. All 256 addresses in the range are now blocked with a single rule.

Example 3: Blocking a wildcard pattern. The site owner notices scraping attempts from multiple IPs in the 203.0.113. range but they rotate unpredictably within the range. They add 203.0.113. as a wildcard rule to catch the full range regardless of which specific IP is used.

Fields

Next steps

• Audit monthly. Delete entries with Hits at 0 for more than 30 days — abusers have moved on.
• Use the Reason field consistently. A note like "ticket #1289, form spam, 2026-04-21" takes ten seconds and saves hours of archaeology.
• If your list grows past a few dozen active entries, escalate to your ops or platform team. Large lists indicate a problem this tool is not designed to solve.