Imunify Lets cPanel Customers Set Bot Limits, but They Won’t Work on Nginx or LiteSpeed

Server security vendor Imunify now lets hosting customers set their own bot rules without a support ticket. Their host has to switch the controls on first. The company announced a Rate Limiting tab for WHM and cPanel on November 4, and a site-owner allowlist for AI Bot Management in version 4.1.4 of its WordPress plugin on November 5. Rate Limiting does not work on cPanel servers with Nginx or LiteSpeed.

According to the company, both kinds of change used to end in a ticket. Only root could write a rate-limiting rule, and the only way to exempt traffic from AI Bot Management was the server-wide whitelist in the hosting panel. An uptime monitor and a payment webhook both look like bots to that feature, and Imunify’s argument is that only the site owner knows the site depends on them.

CloudLinux, which makes Imunify, and WebPros surveyed 446 providers in late 2025 for the Web Hosting Trends Report 2026. Bot traffic consuming scarce server resources was among the security challenges creating the most overhead or risk for 36% of respondents.

Host Rules Apply First in cPanel, WordPress Gets Site-Level Exceptions

Both controls stay off until the server administrator acts, and Imunify lists neither at an extra cost. Once on, they divide control differently.

Rate Limiting Does Not Work on cPanel Servers With Nginx or LiteSpeed

Rate Limiting needs WebShield to run as a module inside the web server, the default on cPanel with Apache. The cPanel tab depends only on the WHM switch that shows it to customers, so those on an Nginx or LiteSpeed server could still add rules that never apply. The company’s advice there is to leave that switch off.

Imunify also advises checking server headroom before switching Rate Limiting on, because a flood from many different addresses can grow the imunify360-wafd service to 1 to 2 GB of RAM and its counters file to about 2 GB.

In the cPanel Tab, the First Matching Rule Applies

Once switched on, Rate Limiting covers every request no rule matches with a server-wide default that ships at 300 requests per minute per visitor, or five requests a second, and a JavaScript challenge above that. According to Imunify, real browsers solve the challenge in the background. Administrators can change the default, while customers can only see it.

Above its limit, a rule can use the same challenge, reject the request with an HTTP 403, let it through, or only log it. An Allow rule also skips the remaining WebShield checks, including the WAF rules WebShield runs, though ModSecurity still inspects the request. Imunify lists it for trusted integrations scoped to their IP addresses, and a limit of 0 lets every matching request through.

Administrator rules are checked before customer rules. Within each group, rules follow their creation order, the first match applies, and they cannot be reordered. Cron jobs, integrations and monitoring that call a site over HTTP count like any other visitor, so Imunify advises giving the busy ones an Allow rule ahead of the broader rules.

Imunify names crawler awareness as the next step for Rate Limiting. It would let verified search engines and other legitimate services through while slowing everything else.

The WordPress Allowlist Applies Before Bot Classification

The allowlist is checked before AI Bot Management classifies a request. Entries apply per site and never reach the server-wide whitelist. Imunify warns that any client can send any user-agent name, so an entry for a monitoring service also lets in anyone claiming to be that service. The company advises allowlisting fixed IP addresses where a service publishes them.

AI Bot Management, launched in July, sorts requests into six categories and limits bots by category. According to the launch post, it checks a crawler’s claimed identity against the IP ranges its operator publishes instead of trusting the user-agent name. Imunify’s case against an outright block is that site owners want to appear in AI search and answers, though the effect depends on the crawler. OpenAI, for one, uses OAI-SearchBot for ChatGPT search and GPTBot to crawl content that may be used in model training.

The post adds that site owners can switch between the Balanced, Strict and Monitor presets or turn the feature off for their own site. For ImunifyAV and ImunifyAV+, it describes monitor mode only, without rate-limiting. There, an allowlist match simply skips classification.

Version 4.1.4 also stops rate-limiting requests to Elementor’s MCP endpoint, a route AI assistants use to work on Elementor sites. It recognizes Claude-User requests as verified AI traffic after checking them against the IP range Anthropic publishes.

Kinsta Offers Similar Controls in Its Own Dashboard

Kinsta, a managed WordPress host, released a beta of Bot Protection to all customers in May and announced the feature on June 9. Its custom exceptions work by IP address, user agent or request path, close to the entry types in Imunify’s allowlist, and the company describes the feature as requiring no support ticket. To show the scale of bot traffic, Kinsta cites its own infrastructure data, including bots hitting add-to-cart URLs 7.67 million times in a single 24-hour period.

The models differ. Kinsta offers the controls on its own platform, while Imunify’s reach customers only through hosts running its software, and each host decides whether to turn them on. For those hosts, the change moves some routine requests to customers, which Imunify presents as a way to reduce “my integration is blocked” tickets. Administrators keep the switches and, in cPanel, the first say on rate limits.