Block Specific Bots stops unwanted crawlers from hitting your site by checking the request’s user-agent string. AdminEase ships with a curated list of common bots organised by category and lets you add custom user agents on top, then enforces the block at the server level using .htaccess rules with a PHP fallback for non-Apache hosts.

What this feature does

Some bots are useful (search engines, uptime monitors, accessibility checkers). Others scrape your content, hammer your endpoints, or add noise to analytics. Block Specific Bots reads the User-Agent header on every request, compares it to your block list, and rejects matches with a 403 Forbidden.

The block list comes in two parts:

Common botsA curated multi-select organised into categories (AI scrapers, SEO tools, content miners, etc.) so you can block whole groups in one click.
Custom botsA free-form text field for any user-agent fragment not in the curated list.
User-agent matching is substring-based

Adding BadBot to the list blocks any request whose User-Agent header contains BadBot anywhere. You don’t need to write a full regex or match the whole string. Match is case-insensitive.

How to enable it

  1. Open AdminEase › Security. Click AdminEase in the WordPress admin menu, then switch to the Security tab.
  2. Toggle Enable bots blocking on. The settings panel expands to reveal the two list fields.
  3. Pick from the common-bots list. Search and click to add. The picker is grouped, so you can quickly grab everything in a category like “AI scrapers” without ticking each one.
  4. Add custom user agents (optional). Enter user-agent fragments one per line in the Block specific bots field for anything not in the curated list.
  5. Save settings. AdminEase writes a managed block to .htaccess immediately. Test by sending a request with curl -A "BlockedBotName" https://yoursite.com; you should see a 403.

Settings reference

Setting What it does Default
Enable bots blocking Master switch. Off means no rules are written and no PHP fallback runs. Off
Block common bots Multi-select from a categorised list of well-known bots. Each entry is a vetted user-agent fragment. Empty
Block specific bots Free-form list of user-agent fragments to block, one per line. Empty

What gets written to .htaccess

On Apache servers, AdminEase writes a managed block using mod_rewrite:

# BEGIN AdminEase
<IfModule mod_rewrite.c>
    RewriteEngine On

    RewriteCond %{HTTP_USER_AGENT} (BadBot|AnotherBot|SomeScraper) [NC]
    RewriteRule .* - [F,L]
</IfModule>
# END AdminEase

The F flag returns 403 Forbidden directly from Apache without invoking PHP, which makes the block essentially free in terms of server load.

What if my host isn’t Apache?

Nginx and other web servers don’t read .htaccess. AdminEase still writes the file (in case the rules are ever needed), but at runtime it falls back to a PHP check on the init action. The check reads $_SERVER['HTTP_USER_AGENT'] and short-circuits the request with a 403 when a fragment matches.

PHP fallback runs after WordPress boots

The Apache route blocks before WordPress is loaded; the PHP fallback blocks after it’s loaded. Functionally identical for visitors, but the PHP route uses a small amount of server resources per blocked request. On Nginx hosts with very heavy bot traffic, ask your host to add equivalent rules to your Nginx config for true server-level blocking.

Using it well

Don’t block what you want indexed

The common-bots list deliberately excludes mainstream search-engine crawlers (Googlebot, Bingbot, etc.). If you add “googlebot” manually, your search rankings will drop within days. Always double-check that your custom entries aren’t blocking traffic you actually want.

Audit before blocking

Pair this feature with Network Viewer. Look for repeated, identical user agents hitting noisy paths and add them to your block list. It’s much safer than guessing.

Combine with country blocking for layered defence

Bot networks often originate from a small set of regions. Block Specific Countries can take care of geographic patterns while Block Specific Bots catches user agents that come from anywhere.

Troubleshooting

I added a bot but it’s still hitting my site

Three things to check: confirm the master switch is on; confirm your fragment matches the actual user-agent string the bot uses (check the user-agent column in the Network Viewer log); confirm .htaccess is actually being read by your web server. On Nginx hosts, the PHP fallback handles the block, but it requires that AdminEase be active and not bypassed by a page cache.

Page caching is serving the bot a cached page

Caching layers like Varnish or some CDN edges may serve cached HTML before AdminEase runs. Configure the cache to vary on User-Agent, or move the bot block to your CDN’s WAF where possible.

I accidentally blocked Googlebot

Remove the entry from the list and save. The next time Googlebot visits, it’ll be allowed through. Check Google Search Console for an “indexing dropped” warning and submit a fresh sitemap to speed re-indexing.

The .htaccess block is missing after a hosting migration

Open AdminEase › Security, untick the Enable bots blocking toggle, save, then re-tick it and save again. AdminEase rewrites its managed block on every save.