⏱️ What is Rate Limiting?
Rate Limiting controls how many requests an IP can make within a given time window. If an IP exceeds the configured limit, an action is triggered (monitor, challenge, or block). It is the primary defense against brute force attacks (mass login attempts), scraping (automated content extraction), and resource abuse (excessive requests to APIs or forms).
🎯 What it protects
- Login / wp-admin: Stops brute force attacks against wp-login.php, wp-admin, and registration pages.
- XML-RPC: Protects the xmlrpc.php endpoint against amplification attacks and user enumeration.
- REST API: Limits requests to /wp-json/ to prevent saturation from scraping or abuse.
- General site: Covers the entire site (front-end) against aggressive crawlers and bots.
⚙️ How RPM + Burst work
RPM (Requests Per Minute) is the sustained limit of requests per minute: how many times an IP can load content in a minute (a human browsing normally generates about 5-15 requests/min; an aggressive bot, 100+). Burst is how many of those requests can arrive practically instantly — loading a single page already fires off several at once (HTML, CSS, JS, images). If the Burst is exceeded, the server responds asking to wait a few seconds before the next request; this doesn't block the IP by itself as long as it stays under the RPM limit. This tells apart real human traffic (short occasional bursts from loading a page) from automated attacks (continuous, sustained spikes).
Action: Monitor / Challenge / Block
The action defines what happens when an IP exceeds the configured limit. Each mode offers a different level of severity:
📋 Monitor (Log Only)
Logs every time an IP exceeds the limit but takes no action. Ideal for the initial observation phase. Use it for the first 24-48h to establish a baseline of legitimate traffic.
⚠️ Challenge (HTTP 429)
Responds with HTTP 429 Too Many Requests and includes a Retry-After header. The browser or client must wait before retrying. It is the recommended option for production: stops abuse without a permanent block.
🚫 Block (HTTP 403)
Responds with HTTP 403 Forbidden and blocks the IP immediately. The IP is added to the blocked list and all subsequent requests are rejected. Only use it when you are sure the limits do not affect legitimate traffic.
Presets & Custom Limits
SeenSecure includes preconfigured presets for the most common scenarios. You can select a preset or configure custom limits manually. Presets adjust both RPM and Burst automatically:
Custom
You define RPM (1-3600) and Burst (1-1000). Ideal for sites with specific needs or after analyzing logs in Monitor mode.
🧪 Testing (50/10)
50 RPM + Burst 10. Designed for testing and development. Very permissive limit to avoid interference while you adjust settings.
🔑 Login (50/10)
50 RPM + Burst 10. Optimized to protect wp-login.php and wp-admin. 50 login attempts per minute is enough for legitimate users but stops brute force attacks.
🔌 XML-RPC (30/5)
30 RPM + Burst 5. More restrictive limit because xmlrpc.php is a common vector for amplification attacks. If you don't use XML-RPC, consider disabling it entirely.
🌐 REST API (1000/100)
1000 RPM + Burst 100. High limit to avoid interfering with legitimate integrations (plugins, themes, external apps). Adjust if your API has heavy traffic.
🌍 Site (1000/100)
1000 RPM + Burst 100. General coverage for the site front-end. Suitable for most sites with moderate traffic. Monitor the logs and reduce if you see abuse.
🔧 Custom limits
When selecting "Custom" you can define:
- RPM: Range 1-3600. Sustained requests per minute.
- Burst: Range 1-1000. Maximum consecutive requests in a spike.
Protected Contexts
Rate Limiting applies independently across four distinct contexts. Each context has its own RPM/Burst counter, allowing specific limits without affecting other areas of the site:
🔐 Login / wp-admin
Protects wp-login.php, wp-admin/, registration and password reset pages. The most critical context: a successful attack here can compromise the entire site. Use the Login preset (50 RPM) or a more restrictive custom limit.
🔌 XML-RPC
Protects xmlrpc.php. This endpoint is infamous for DDoS amplification attacks and user enumeration. The XML-RPC preset (30 RPM + Burst 5) is very restrictive because ideally this endpoint should have minimal to no traffic.
🌐 REST API
Protects /wp-json/. Many plugins and themes make frequent requests to the REST API. The preset (1000 RPM + Burst 100) is high to avoid breaking integrations. Monitor the logs to identify if an external plugin needs more or less limit.
🌍 General Site
Covers the entire site front-end: pages, posts, archives, searches, and any URL not covered by the other contexts. The preset (1000 RPM + Burst 100) is suitable for most. Reduce if you see aggressive content scraping.
Progressive Escalation
The progressive escalation system automatically increases the severity of penalties for repeat-offending IPs. Instead of always applying the same punishment, sanctions get tougher the more the abuse persists:
Level 1 (Mild)
Initial short-duration penalty. The IP receives a brief timeout (a few minutes) before being able to retry. If the abuse stops, the IP returns to normal automatically.
Level 2 (Moderate)
If the IP re-offends within the escalation window, the penalty lengthens significantly (minutes to hours). The system records the repeat offense and applies a longer block time.
🚫 Permanent Block
If the IP exceeds the repeat-offense threshold within the configured escalation window, it is automatically added to the permanent block list. Only an administrator can unblock it manually from the blocked IPs list.
⚙️ Configurable parameters
- Level 1 Duration: Initial penalty time (15 minutes by default, configurable between 1 and 60).
- Level 2 Duration: Penalty for repeat offenders (120 minutes / 2 hours by default, configurable between 30 and 1440).
- Permanent Threshold: Number of repeat offenses before permanent block (5 by default, configurable between 2 and 10).
- Escalation Window: Time period during which repeat offenses are counted (24 hours by default, configurable between 1 and 168). If the IP behaves during this period, the counter resets.
❓ FAQ — Frequently Asked Questions
🔹 What if an external service (API, webhook) gets blocked?
If an external service your site needs (payment gateway, CRM, third-party webhook) gets blocked by Rate Limiting:
- Check the logs — Go to the Rate Limiting log and identify the blocked service's IP or IP range.
- Add the IP to the whitelist — In the firewall Whitelist section, add the IP or CIDR range (e.g., 203.0.113.0/24) so that traffic from that service bypasses Rate Limiting.
- Verify connectivity — Run a test to confirm the service works correctly.
🔹 How long should I use Monitor mode before switching to Challenge?
We recommend 24-48 hours in Monitor mode as a minimum. This allows you to:
- Identify legitimate traffic spikes (launches, promotions, email campaigns).
- Establish the baseline RPM for each context.
- Detect abusive IPs before enabling blocks.
- Adjust presets or create informed custom limits.
After that period, switch to Challenge (HTTP 429). Monitor for another 7 days before considering Block.
🔹 Does logging affect performance?
The logging toggle enables or disables detailed recording of Rate Limiting events. With logging on, each time an IP exceeds a limit an entry is written to the log. With logging off, actions (Challenge/Block) still execute but are not recorded. We recommend keeping logging on during Monitor and Challenge phases for visibility, and it can be turned off in production if the log volume is very high.
🔹 ¿Puedo tener límites distintos para cada contexto?
Yes. Each context (Login, XML-RPC, REST API, Site) has its own RPM and Burst configuration. You can have, for example, 50 RPM on Login, 30 RPM on XML-RPC, 1000 RPM on REST API, and 1000 RPM on Site, all at the same time.
🔹 Does Rate Limiting affect search engines (Googlebot)?
Legitimate search engine bots (Googlebot, Bingbot, etc.) are identified by their User-Agent and generally do not exceed standard preset limits (1000 RPM). If unsure, review the logs in Monitor mode to see if any crawler is being limited. If so, you can add its IP to the whitelist or increase the limit for the General Site context.
🔹 What is the "First Line" shown on this tab?
It's an additional protection layer (not bot-specific) that acts before WordPress even loads, built for traffic spikes and very intense attacks that could overwhelm the rest of the site. It's enabled and configured right here, in the "🚀 First Line" section. As part of that protection, it also avoids hurting your search rankings: before applying any limit, it checks whether the visit genuinely belongs to a legitimate search engine or AI assistant (by cross-checking its IP, not just the text it sends) so it can pass through without friction.
🔹 A legitimate visitor got permanently blocked from repeat offenses — how do I unblock them?
A permanent block from progressive escalation can only be reversed by an administrator, by hand, from the firewall's blocked-IPs list (or by adding the IP to the whitelist, which takes priority over any block). It doesn't revert on its own even if the IP stops generating traffic.
🔹 What exactly does an HTTP 429 response mean?
It's the standard "too many requests" response when the active mode is Challenge: the visitor can retry after some time. It's not a permanent block and doesn't indicate confirmed malicious activity, just that they exceeded the RPM limit configured for that context.