WordPress rate limiting works best right where the requests arrive. FLAVOR Traffic Guard runs as an MU-plugin inside your installation: no service in front of the domain, no nameserver move, no detour through someone else's network.
That saves you more than a monthly invoice, because local WordPress rate limiting comes without a second base fee. Logs, IP addresses and ban lists stay on your server. Your privacy documentation gets shorter instead of longer, and as the shop grows nothing moves into an edge network whose price list you have not seen.
Backups and updates are not replaced by a WordPress rate limiter. What WordPress rate limiting takes off your hands is the daily load: scrapers harvesting prices, login attempts by the minute, filter pages requested by bots in thousands of combinations.
Security plugins inspect requests after WordPress has started. By then the PHP process and the database query are already paid for, even for a request that gets discarded a moment later. Our WordPress rate limit plugin decides earlier, before the first PHP process runs.
What counts is not the raw number of requests but the effort behind them: a product page counts as 1, while a three-value filter combination counts 60. Those sums sit per IP in an SQLite database in WAL mode, measured rather than estimated.
Requests that WordPress rate limiting turns away never reach PHP at all. Apache answers them with a 403 or 429, which is why a flood costs almost nothing in resources. Genuine customers keep their session throughout and are never asked to prove anything.
| Visitor type | Treatment | Budget |
|---|---|---|
| Browser with a verified cookie (24 hours) | full access, no limit | 2,000 |
| Browser without a cookie | normal browsing possible | 1,000 |
| Googlebot and Bingbot, DNS-verified | free run on clean URLs | unlimited |
| AI crawlers | throttled instead of banned | 60 requests/minute |
| Unknown bot over budget | ban by accumulated cost | 100 |
The effect is measurable: server load drops by as much as 72%, TTFB falls from 1,450 to 320 milliseconds, and 38% more real buyers reach the shop under pressure. That difference comes from WordPress rate limiting that judges effort rather than IP addresses, on the same hardware as before.
Blocking everything costs visibility, letting everything through costs processing time. Between those two sits WordPress bot protection that decides per bot type. Thirteen AI crawlers are recognised individually, among them GPTBot, ClaudeBot and PerplexityBot, and each one you set to allow, throttle or block.
So that your range stays quotable in AI answers, filter combinations return a clean 410 to bots. Not one filter URL turns into a crawl trap.
Search engines get checked more strictly than any blocklist can manage: reverse and forward DNS across A and AAAA records settle whether a Googlebot really is one. Anything claiming to be a search engine and failing that test is gone immediately. On top of that, 16 honeypot traps catch requests for backups and configuration files that no visitor ever opens. Every hit there feeds straight into the WordPress rate limiting budget of that IP.
What happens if a rule turns out too strict? That worry is handled up front: every WordPress rate limiting plugin we ship starts in observation mode. For seven days it records what would have happened, and blocks nothing.
After that week you see in real numbers which rules would fire. Then you switch WordPress rate limiting on for good. Should anything run out of hand afterwards, auto safe mode steps in as soon as more than 50 bans pile up within 10 minutes. As a last resort, an empty file uploaded by FTP disables everything, no backend access required.
While all of that runs, logging happens in three places at once: in the .htaccess blocks, in the preload before WordPress and in the plugin itself. One view merges all three, filtered by source.
Before you start, you need WordPress 5.8 or newer, PHP 8.3 and the SQLite extension. We recommend Apache, and the plugin runs under Nginx as well. Caching stays untouched, whether you use WP Rocket, NitroPack or FlyingPress, and multilingual shops on WPML or Polylang leave the rules unaffected.
Login attempts fall under the same ruleset, so a separate WordPress brute force protection is not needed beside it. Adding a WordPress firewall plugin stays optional rather than necessary.
WordPress rate limiting is licensed per site, as with all our premium WordPress plugins, and we set the whole thing up on request.
We have been building shops and websites since 2010, by now past 1,000 projects. The rules in this plugin come out of exactly those installations. What clients say about working with us is public on ProvenExpert. Once the load is under control and visibility should follow, our WordPress SEO plugin takes the next step.