WordPress Bot Control: Limit Abusive Automation Without Treating Every Crawler the Same
Aegisify WAF 1.20.13 separates ordinary abuse controls from crawler policy and source intelligence. Administrators can apply per-path request limits, route recognized crawler purposes through compatible, standard, or block policies, control bad User-Agent tokens, and add behavioral, IP, country, or ASN restrictions where supporting data is available.
Search crawlers, ad validators, scanners, scraping tools, credential bots, and unknown scripts can all look automated. The useful question is what the traffic is doing and what policy should apply.
How Abuse & Bot Controls Handle Automated Requests
The module does not depend on one User-Agent verdict. It combines path-level frequency, recognized crawler purpose, configured bot tokens, behavioral counters, and optional source intelligence.
Click a stage to expand
01Request ScopeIP + path + surface
02Crawler PurposeRecognized token registry
03PolicyCompatible, standard, block
04BehaviorShared counters
05Source IntelIP, country, ASN
06Evidence24h + 7d views
Set Request Limits Around the WordPress Paths That Cost the Most
A single site-wide request limit is often too blunt for WordPress.
The default abuse limit is 180 requests per minute. Aegisify also supports up to 25 configured path-pattern overrides in the current administration workflow, with each row defining a path pattern and its own per-minute threshold. This makes it possible to treat a high-cost application route differently from an ordinary cached page.
Rate controls are not a substitute for understanding expected integrations. Search, feeds, ecommerce, AJAX-heavy interfaces, monitoring systems, and APIs can legitimately generate bursty traffic. Start with evidence, then narrow thresholds around routes whose normal behavior is understood.
Recognized Crawler Does Not Mean Unlimited Trust
Aegisify separates crawler compatibility from the rest of the WAF instead of creating a universal bypass.
Skip Only Bot-Specific Friction
For eligible public GET/HEAD traffic, Compatible skips this module’s bad-User-Agent and bot-rate controls. It does not turn off the rest of Aegisify WAF, so broader DDoS, reputation, behavioral, adaptive, and application security controls can still apply.
Use Ordinary Abuse Controls
Standard routes the crawler through the same abuse, bot, DDoS, reputation, behavioral, and adaptive controls used for normal traffic. This is appropriate when a crawler does not require special compatibility treatment.
Deny Eligible Public Requests
Block returns HTTP 403 before ordinary bot and DDoS processing for eligible public requests. Because User-Agent identities can be spoofed, administrators should use this setting as policy—not as proof of who operates the request.
Search and Advertising Crawlers Stay Separate From AI Security
Aegisify WAF no longer mixes every form of automated traffic into one administration area.
The Abuse & Bots area exposes crawler routing for supported search, advertising, and other crawler categories, plus a local registry that shows recognized tokens. AI-specific crawler and application-gateway controls live under the separate AI Security area, keeping ordinary bot policy from being confused with prompt, model, provider, or AI-agent security decisions.
The built-in Crawler Policy Test lets an administrator supply a User-Agent and public path to preview the resolved public GET policy without sending or blocking a real request. That makes policy changes easier to verify before production traffic depends on them.
Add Context When Request Frequency Alone Is Not Enough
PRO intelligence adds additional decision inputs, but each one has an operational boundary.
Anonymous Request Scoring
Behavioral scoring can combine request frequency and sensitive-route activity when a persistent object cache or APCu supplies shared counters. If a supported counter backend is unavailable, administrators should not assume this layer is active.
Explicit Source Blocks
Administrators can maintain IPv4 or CIDR entries for sources or networks that should be denied. Narrow entries are preferable to broad ranges when legitimate users may share infrastructure.
Provider-Backed Geo Policy
Country blocking requires a configured provider. Cloudflare headers can supply country context when that trust path is appropriate; MaxMind support uses a local database and PHP capability.
Network-Level Context
ASN blocks can help when abuse is concentrated in a network, but shared hosting, carriers, VPN providers, and cloud platforms can contain legitimate users. Review evidence before applying broad network policy.
Four Views Show Where Automated Pressure Is Coming From
The current interface summarizes bot-specific enforcement and abnormal traffic without replacing detailed event evidence.
Enforcement Signals
See rate limits, blocks, compatibility decisions, and configuration events across the selected local evidence window.
Surface Scope
Review how bot-related enforcement is distributed between front-end and REST activity instead of assuming every automated event targets the same part of WordPress.
Top User-Agents and Sources
Frequently observed automation strings and top offending IPs help prioritize investigation. The values remain evidence to review rather than proof that a request belongs to a specific organization or human actor.
Protect Expensive WordPress Paths Without Blocking Useful Crawlers by Accident
Start with rate evidence, classify the traffic you recognize, and add source or behavioral restrictions only where the site needs them.
Common Questions About Aegisify Bot Defense
Does Aegisify identify every bot accurately?
No. User-Agent strings and many network attributes can be spoofed or shared. Aegisify combines recognized tokens with behavior, frequency, source intelligence, and other WAF controls, but administrators should treat those signals as evidence rather than absolute identity.
Does Compatible crawler policy bypass the WAF?
No. It skips only the Abuse & Bots module’s bad-User-Agent and bot-rate controls for eligible public GET/HEAD requests. Other applicable WAF, DDoS, reputation, behavioral, and adaptive controls remain separate.
Do behavioral controls always work on every host?
No. The shared behavioral counter requires a supported persistent object cache or APCu unless an integration supplies another supported counter implementation. The admin interface exposes the available backend.
Should I block an entire country or ASN?
Only after reviewing legitimate audience and traffic evidence. Broad source controls can affect customers, search services, VPN users, shared networks, and cloud-hosted integrations.
How can Aegisify AI help?
Ask about Aegisify or WordPress: errors, plugins, security, SEO, compatibility, troubleshooting, comparisons, or launch a free website scan.