WordPress 429 too many requests: how to fix it

A 429 Too Many Requests response means you have sent more requests than the server is willing to handle in a given time window. Unlike a 403 which is a permanent block, or a 503 which means the server is overloaded, a 429 is a rate limit – slow down and try again later.

In a WordPress context, 429 errors appear in several scenarios: you get locked out of wp-admin after too many login attempts, the block editor intermittently fails to save, a WooCommerce checkout process fails during high traffic, or automated tools (cron, API scripts, import processes) are throttled. The source of the rate limit determines the fix.

What generates a 429#

Rate limits exist at multiple layers, and the same request can be subject to limits at each one:

Server-level rate limiting. The web server (Nginx, Apache) can enforce request rate limits per IP address. This is the most common source of 429 errors and is configured independently of WordPress. When Nginx returns a 429, the request never reaches PHP.

WordPress application-level rate limiting. WordPress itself does not have built-in rate limiting, but security plugins add it. Wordfence, Sucuri, and similar plugins track request rates per IP and return 429 (or 403) when thresholds are exceeded.

Third-party API rate limits. WordPress plugins that communicate with external services (Stripe, Google Maps, Mailchimp, OpenAI, social media APIs) are subject to those services’ rate limits. When the API returns 429 to the plugin, the plugin may pass that error through to the user or fail silently.

CDN or proxy rate limits. Cloudflare, Sucuri CDN, and other proxy services have their own rate limiting that applies before the request reaches your server.

Hosting infrastructure rate limits. The hosting platform may enforce per-IP or per-endpoint rate limits to protect server resources, especially on login pages and POST endpoints.

Identifying which layer produced the 429 is the first diagnostic step.

Diagnosing the source#

Check the response headers

Rate limit responses typically include headers that tell you about the limit:

Retry-After: 60
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1679500000

Retry-After tells you how many seconds to wait. X-RateLimit-* headers (when present) show the limit, how many requests remain, and when the window resets.

Check who responded

Open developer tools (F12), go to the Network tab, and examine the 429 response:

• Plain text or generic page = web server or hosting infrastructure
• WordPress-themed page = a WordPress plugin generated the 429
• JSON response with API-specific error = a third-party API limit
• Cloudflare or CDN branded page = CDN-level rate limit

Check the error log

Nginx logs 429 responses in its access log with the 429 status code:

grep " 429 " /var/log/nginx/access.log | tail -20

This shows which IPs are hitting the rate limit and which URLs they are requesting.

Cause 1: Too many login attempts#

The most common cause of 429 errors in WordPress. Login pages are the primary target of brute force attacks, so hosting platforms and security plugins enforce strict rate limits on wp-login.php.

How to confirm

The 429 occurs when accessing /wp-login.php or /wp-admin/ (which redirects to wp-login.php). It may happen after several failed login attempts, or it may affect you even with correct credentials if someone else (or a bot) was attempting to log in from the same IP range before you.

How to fix

Wait. The rate limit is temporary. Most login rate limits reset within 1-15 minutes. If you wait and try again with the correct credentials, you will get through.

Use a different IP. If you are on a shared IP (office network, VPN) and someone else triggered the limit, switch to a different network temporarily.

Check your security plugin. Wordfence, Sucuri, and similar plugins have configurable login rate limits. If the default is too aggressive for your usage pattern (multiple editors logging in from the same office IP), adjust the threshold. But be cautious – loosening login rate limits makes brute force attacks more effective.

Use strong credentials and 2FA. The real fix for login rate limit problems is not weakening the rate limit but eliminating failed login attempts. Use a strong, unique password and enable two-factor authentication. You will never trigger the rate limit with correct credentials on the first attempt. See Brute force attacks on WordPress: how they work and how to stop them for the complete picture.

Cause 2: Server-level Nginx rate limiting#

Nginx can enforce rate limits per IP using the limit_req module. This is commonly applied to POST endpoints, login pages, and XML-RPC to prevent abuse. When the limit is exceeded, Nginx returns a 429 before the request reaches PHP.

How to confirm

The 429 response is a plain page (not WordPress themed). It appears on specific endpoints (login, admin-ajax.php, REST API) rather than all pages. The Nginx error log shows limiting requests entries:

grep "limiting requests" /var/log/nginx/error.log | tail -10

How to fix

If you are hitting the limit with legitimate traffic, the rate limit may be too low for your use case. Common scenarios where legitimate traffic hits server-level limits:

• WooCommerce AJAX. WooCommerce uses admin-ajax.php heavily for cart updates, checkout validation, and product filtering. A busy store can generate many POST requests per second from a single user’s session.
• Page builders. Elementor, Divi, and other page builders make frequent AJAX requests while editing. Autosave and preview requests can accumulate quickly.
• Import processes. Plugins that import products, posts, or media in bulk may send rapid requests to the REST API.

On managed hosting, contact support to adjust rate limits for specific endpoints. On self-managed servers, adjust the limit_req zone in the Nginx configuration.

On Hostney, the server-level rate limits are tuned for WordPress and WooCommerce compatibility. Logged-in WordPress users bypass rate limits on most endpoints, which prevents the editing/checkout experience from being throttled while still protecting against anonymous abuse.

Cause 3: Third-party API rate limits#

WordPress plugins that integrate with external APIs are subject to those APIs’ rate limits. When the external API returns 429, the behavior depends on the plugin – some retry automatically, some fail silently, and some pass the error through to the user.

Common APIs and their limits

How to fix

Identify the failing API call. Enable WP_DEBUG_LOG and check wp-content/debug.log for error messages mentioning rate limits or 429 responses. The error usually includes the API hostname.

Cache API responses. If a plugin makes the same API call on every page load (checking social media counts, loading maps, verifying licenses), install an object caching layer so the response is cached and the API is called less frequently. On Hostney, enable Memcached from the control panel for this purpose.

Reduce API call frequency. Some plugins have settings to control how often they sync or poll. A social media feed that updates every 5 minutes instead of on every page load dramatically reduces API usage.

Upgrade API tier. If you legitimately need more API calls, many services offer higher-tier plans with relaxed limits. This is common with mapping APIs and AI services.

Use a transient for expensive operations. If you are building custom functionality that calls an API, use WordPress transients to cache the result:

$data = get_transient('my_api_data');
if ($data === false) {
    $response = wp_remote_get('https://api.example.com/data');
    $data = wp_remote_retrieve_body($response);
    set_transient('my_api_data', $data, HOUR_IN_SECONDS);
}

This caches the API response for one hour, reducing API calls from every-page-load to once-per-hour.

Cause 4: WordPress cron overloading#

WordPress cron ( wp-cron.php ) is triggered on every page load by default. Each page load checks if any scheduled tasks are due and executes them. On a high-traffic site, this means multiple cron processes can run simultaneously, generating rapid requests to the same endpoints.

If cron tasks call external APIs or trigger internal AJAX requests, the combined request volume can trigger rate limits.

How to confirm

The 429 errors correlate with traffic spikes. The Nginx access log shows many requests to wp-cron.php from different source IPs in short timeframes.

How to fix

Disable the default cron trigger and use a real system cron:

In wp-config.php :

define('DISABLE_WP_CRON', true);

Then set up a system cron to run WordPress cron at a controlled interval:

*/5 * * * * wp --path=/path/to/wordpress cron event run --due-now

This ensures cron runs exactly once every 5 minutes rather than on every page load. For a complete walkthrough, see How to run a WP-CLI command with cron.

Cause 5: Automated tools or scripts#

If you are running automated tools against your site – load testers, crawlers, import scripts, deployment tools, or monitoring probes – they may generate enough requests to trigger rate limits.

How to fix

Crawlers and scanners. Tools like Screaming Frog, Ahrefs, or Semrush crawlers can send hundreds of requests per minute. Reduce the crawl rate in the tool’s settings. Most SEO crawlers have a “requests per second” setting – start with 1-2 requests per second.

Import and sync scripts. Batch your operations and add delays between requests. A script that processes 1000 items should not send 1000 requests in 10 seconds.

Monitoring tools. If you have an uptime monitor checking your site every 30 seconds, ensure it is not also checking wp-admin, the REST API, and several other endpoints simultaneously.

Load testing. Always notify your hosting provider before running load tests. The request patterns of load tests are indistinguishable from a DDoS attack at the infrastructure level.

Cause 6: CDN or proxy rate limits#

If your site uses Cloudflare, Sucuri CDN, or another proxy, the proxy has its own rate limiting rules that apply before the request reaches your server.

How to confirm

The 429 response page is branded by the CDN (Cloudflare error page, Sucuri block page). The response headers include CDN-specific identifiers.

How to fix

Check the CDN’s dashboard for rate limiting rules. On Cloudflare:

• Rate Limiting rules in the Security section define custom limits per URL pattern
• Bot Fight Mode can aggressively challenge requests that appear automated
• Under Attack Mode adds a JavaScript challenge to all requests (not a 429 but can feel similar)

If the CDN is blocking legitimate traffic, adjust the rules to be less aggressive or add exceptions for specific paths (wp-admin, wp-json, wc-ajax).

Handling 429 errors in custom code#

If you are developing a WordPress plugin or theme that makes HTTP requests (to your own API or a third-party), handle 429 responses correctly:

$response = wp_remote_get('https://api.example.com/data');
$status = wp_remote_retrieve_response_code($response);

if ($status === 429) {
    $retry_after = wp_remote_retrieve_header($response, 'retry-after');
    $wait = $retry_after ? intval($retry_after) : 60;

    // Log the rate limit
    error_log("API rate limited. Retry after {$wait} seconds.");

    // Do not retry immediately - schedule a retry
    wp_schedule_single_event(time() + $wait, 'my_plugin_retry_api_call');
    return;
}

The key principles:

• Respect the Retry-After header. Do not retry before the specified time.
• Do not retry in a loop. Each failed retry counts against the rate limit and pushes you further from recovery.
• Use exponential backoff. If Retry-After is not provided, wait 1 second on first retry, 2 on second, 4 on third, and so on.
• Log rate limit events. Track when and where rate limits are hit to identify patterns.

How Hostney handles rate limiting#

Layered rate limiting. Hostney uses multiple rate limiting layers that work together rather than competing. Nginx enforces per-endpoint limits (login, POST requests), while edge-level detection monitors per-IP request rates in real-time across a broader time window. The layers are coordinated so that a request blocked at one layer is not counted again at another.

Logged-in user bypass. WordPress users with valid session cookies bypass most rate limits on non-login endpoints. This means that store managers editing products, editors saving posts, and customers checking out are not throttled by the same limits that protect against anonymous abuse.

Challenge instead of block. For traffic that is suspicious but might be human (moderate rate spikes, unusual patterns), the system serves a proof-of-work challenge instead of an immediate 429 or 403. Real users solve the challenge in seconds and continue browsing. Bots cannot solve it and are effectively blocked. This approach avoids false positives that hard rate limits create.

Per-domain customization. Rate limits can be configured per subdomain, so a high-traffic WooCommerce store can have different limits than a low-traffic blog on the same account.

Summary#

A 429 error means a rate limit was exceeded. Identify which layer produced it (server, security plugin, third-party API, CDN, or hosting infrastructure) by checking the response body and headers. The most common causes on WordPress sites are too many failed login attempts, server-level Nginx rate limits on POST endpoints, and third-party API limits from plugins that call external services.

For login rate limits, wait and retry with correct credentials. For server-level limits on legitimate traffic, contact your host to adjust thresholds. For API limits, cache responses and reduce call frequency. For automated tools, reduce request rates. For a complete reference of WordPress errors and their quick fixes, see How to fix the most common WordPress errors.