6 Ways to Fix the 429 "Too Many Requests" Error in WordPress

A 429 "Too Many Requests" error in WordPress means your server — or a security layer in front of it — has received more requests from your IP address than it is willing to handle within a given time window. It is not a broken plugin or a corrupted database; it is a rate-limit response, the same mechanism that stops bots from hammering an API. This error is frequently mistaken for a true server outage or a hosting resource limit, but the fix is almost never about buying more RAM or CPU. The fastest fix, in most cases, is to wait 60 seconds and refresh, then investigate which component is enforcing the cap.

When a 429 error appears on your WordPress admin dashboard or front end, the underlying problem is almost always a rate limit set by a security plugin (Wordfence, Sucuri, iThemes Security), a CDN or web application firewall (Cloudflare, Sucuri), or your hosting provider's own traffic-shaping rules. Less common causes include a misconfigured REST API endpoint, a caching plugin that has locked up, or an XML-RPC attack that has triggered a temporary block. Each of these causes requires a slightly different fix, and this guide covers every one of them in the order you should try them.

Before You Start: Back Up Your Site and Database

Before making any change to your WordPress site, create a complete backup of both your files and your database. A single misstep inside wp-config.php or a security plugin setting can take your site offline. Use your hosting control panel's backup tool, or a plugin like UpdraftPlus or BlogVault, to export a full snapshot. If you are editing files via FTP or the file manager inside cPanel, download a copy of the file you are about to change first. This precaution turns a potentially stressful troubleshooting session into a reversible experiment.

Common Causes of the 429 Error in WordPress

1. Wait and Refresh (The Obvious First Step)

The simplest fix is also the one most people skip: wait 60 to 120 seconds, then hit refresh. Rate limits are almost always time-windowed — once the window closes, the counter resets. If the error clears after a brief pause, you know a rate limit exists but you have not yet identified the source. Use this moment to check your security plugin's logs and your hosting dashboard for any "blocked IP" or "rate limit exceeded" entries. The logs will tell you which service enforced the cap, which narrows the next steps considerably.

2. Check and Adjust Your Security Plugin

Security plugins are the most common culprit. They protect your site by throttling login attempts, API calls, and page requests from a single IP. When the threshold is too low for legitimate activity — especially during a bulk content update or a migration — the plugin returns a 429.

Wordfence

Navigate to Wordfence > All Options > Rate Limiting. Look for the setting labeled "If anyone's requests exceed" and check the current values. A common fix is to increase the "maximum requests per minute" value from the default (often 200) to 400 or 600, then save. Also ensure "Immediately block IPs that exceed" is not set too aggressively. After changing the value, clear the Wordfence cache under Wordfence > Tools > Live Traffic and test your site.

iThemes Security

Go to Security > Settings > Banned Users. If your IP is listed there, remove it. Then navigate to Security > Settings > Local Brute Force and increase the "Max Login Attempts" threshold if you suspect the error occurs during login. For API-related 429 errors, check Security > Settings > REST API and ensure the access policy is not set to "Restrict Access" — switch it to "Default" or "Allow" temporarily to test.

Sucuri

Log into your Sucuri dashboard (not the WordPress plugin) and go to Settings > Firewall (WAF). Look for "Rate Limit" settings. Increase the allowed requests per visitor per minute. If you cannot find the setting, contact Sucuri support — some rate limits on their enterprise tier are locked and require a ticket to adjust.

3. Disable or Bypass Cloudflare Rate Limiting

If your site uses Cloudflare, the 429 error may come from Cloudflare's own rate-limiting rules, not from WordPress itself. Log into your Cloudflare dashboard and navigate to Security > Rate Limiting > Rules. Review each rule. If a rule matches your current traffic pattern (e.g., more than 100 requests in 60 seconds from one IP), it will trigger a 429. You can either increase the threshold or temporarily disable the rule while troubleshooting. For a quick test, pause Cloudflare entirely (toggle the orange cloud to grey in the DNS settings) and see if the error stops. If it does, re-enable Cloudflare and refine the rate-limiting rules rather than leaving the proxy disabled.

4. Review REST API Limits and Disable Problematic Endpoints

Modern WordPress relies heavily on the REST API for block editor features, AJAX calls, and plugin communication. A plugin that polls the REST API too frequently — especially during bulk operations or content syndication — can trip a rate limit. Install a plugin like WP REST API Controller or Disable REST API and review which endpoints are active. If you find an endpoint being called hundreds of times per minute, consider disabling it or adding a cache layer in front of it. Alternatively, you can add a custom rate limit to the REST API by placing the following code in your theme's functions.php file or a site-specific plugin:

addfilter( 'restauthenticationerrors', function( $result ) {
    if ( ! isuserloggedin() ) {
        return new WPError( 'restnotloggedin', 'You are not currently logged in.', array( 'status' => 401 ) );
    }
    return $result;
});

This snippet forces authentication on all REST API requests, which often reduces the volume of anonymous polling. Test your site immediately after applying it to confirm the 429 error is gone.

5. Check Hosting-Level Traffic Limits

Shared hosting providers — including popular names like Bluehost, HostGator, and SiteGround — enforce per-account traffic limits to protect server resources. If a single visitor (or a small group of visitors) generates a high number of concurrent requests, the server may respond with a 429 or a 503 error. Log into your hosting control panel and look for sections labeled "Resource Usage", "Traffic Shaping", or "Rate Limiting". If your account has exceeded its allowed connections per second, you may need to upgrade to a VPS or dedicated plan. Before upgrading, run a resource usage report to confirm that the traffic is legitimate — a sudden spike could indicate an attack, not organic growth.

6. Disable XML-RPC (If You Do Not Need It)

XML-RPC is a legacy WordPress feature used by some mobile apps and remote publishing tools. It is also a common vector for brute-force attacks that generate a flood of requests and trigger rate limits. If you do not use an external app to publish to your site, disable XML-RPC entirely. You can do this via a plugin like Disable XML-RPC Pingbacks or by adding the following filter to your functions.php file:

addfilter( 'xmlrpcenabled', '__returnfalse' );

After disabling it, monitor your error logs for the next 24 hours. Many users find that a single XML-RPC attack was causing the 429 error every few hours, and disabling the feature resolves it permanently.

7. Increase PHP Memory and Execution Limits

While a 429 is not directly caused by low PHP memory, certain plugins — especially caching and security plugins — consume memory while processing rate-limit checks. If your PHP memory limit is very low (e.g., 32MB), the rate-limiting module may fail and return a 429 because the plugin cannot complete its check within the time limit. Edit your wp-config.php file and add or update the following lines:

define('WPMEMORYLIMIT', '256M');
define('WPMAXMEMORYLIMIT', '512M');

Also ensure PHP's maxexecutiontime is set to at least 300 seconds. You can adjust this in your php.ini file or via your hosting control panel's PHP settings page. After making these changes, restart the PHP process if your hosting panel allows it, then check whether the error recurs.

8. Flush All Caches and Reset Transients

A corrupted cache — especially a page cache from WP Rocket, W3 Total Cache, or WP Super Cache — can cause a feedback loop where the caching layer requests the same page repeatedly, each request counting toward the rate limit. This is rare but real. Clear all caches in your caching plugin's settings. Then clear server-level cache (if your host offers Varnish or Redis). Finally, clean the WordPress transients table using a plugin like Transient Cleaner or via phpMyAdmin. Run the following SQL query (after backing up the database):

DELETE FROM wpoptions WHERE optionname LIKE '%transient%';

Replace wp with your actual table prefix. After clearing transients, visit your site and verify that the error is gone.

9. Examine Your .htaccess File for Custom Rewrite Rules

Custom rewrite rules in .htaccess — especially rules added by caching or security plugins — can inadvertently trigger rate limits by creating redirect loops or by matching a rate-limit pattern. Download your .htaccess file via FTP and review it line by line. Look for any RewriteRule that contains R=429 or references a rate-limit module. If you find suspicious rules, comment them out by adding a # at the start of each line, save the file, and test. If the error disappears, you have identified the culprit. Regenerate a fresh .htaccess by going to Settings > Permalinks and clicking Save Changes — this writes a clean WordPress core .htaccess.

10. Contact Your Hosting Provider's Support

If all the above steps fail, the rate limit may be enforced at the network level by your hosting provider, beyond what you can see in the control panel. Contact support and provide them with the exact error message, the timestamp, and the steps you have already taken. Ask specifically: "Is there a rate limit on my account, and can it be raised or temporarily lifted?" Many hosts will raise the limit for a few hours to let you complete your work, or they will confirm that a DDoS protection service (like modevasive) is causing the block and help you whitelist your IP.

How to Prevent the 429 Error in the Future

Prevention is largely about monitoring and configuration hygiene. Keep your security plugin's rate-limit settings logged and review them after every major update. Use a CDN like Cloudflare with sensible rate-limiting rules — thresholds of 200–300 requests per minute per IP for a normal blog, and 600+ for a site that runs bulk operations. Schedule heavy tasks — like content migrations or mass post generation — during low-traffic hours. If you publish a high volume of posts via an API or automation tool, choose a platform that respects WordPress's rate limits by adding delays between requests.

For example, nativeWP is an AI content automation platform that publishes to WordPress with configurable delays, which helps you stay well under most rate-limit thresholds while still generating posts at scale.

Finally, set up uptime monitoring with a service like UptimeRobot or Better Uptime that alerts you the moment a 429 appears. Early detection turns a multi-hour outage into a five-minute fix.

Frequently Asked Questions

Is a 429 error the same as being blocked by the hosting provider?

No. A 429 is a temporary rate-limit response, not a permanent block. Your IP is still allowed, just throttled for a short window. A true hosting block usually returns a 403 (forbidden) or a 503 (service unavailable) with no reset timer.

Can a caching plugin cause a 429 error?

Yes, though it is uncommon. A corrupted page cache or a misconfigured preload setting can create a feedback loop where the caching plugin requests the same URL hundreds of times per minute, each request counting toward the security plugin's rate limit. Clearing all caches usually resolves this.

How long does a 429 error last in WordPress?

The duration depends on which system enforces the limit. Security plugins like Wordfence often use a 60-second or 120-second window. Cloudflare rate limits can last 10 to 60 minutes. Hosting-level limits may persist until the next hour. Check the error headers — some 429 responses include a Retry-After header with the exact number of seconds.

Should I use a plugin to fix the 429 error?

Only if the plugin addresses the root cause. A "Fix 429" plugin does not exist in any reliable repository. Instead, use a security plugin's built-in logs, a REST API controller, or a transient cleaner to address the specific source. Installing more plugins without diagnosis often makes the problem worse.

Can too many WordPress REST API requests trigger a 429 on a local site?

On a local development environment (XAMPP, Local, Docker), a 429 is extremely unlikely because no external rate-limiting service is present. If you see a 429 on localhost, it is usually a misconfigured caching plugin or a rewrite rule, not a true rate limit.

Key Takeaways