429 Too Many Requests: Complete Troubleshooting Guide

Your browser, script, or app hit a request limit. The server saw too many requests from your address in too short a window and shut the door. That's 429 Too Many Requests — not a crash, not a misconfiguration, just a hard throttle.

The fix depends on which side of the problem you're on. Visitors get three options. Site owners get four more. And if this keeps happening, there are three prevention measures worth implementing now.

What Does 429 Too Many Requests Mean?

HTTP 429 is a rate limiting response. The server tracks how many requests a given client makes per unit of time — per second, per minute, per hour — and when that count exceeds the configured limit, it returns 429 instead of the requested content.

It's a deliberate mechanism, not a malfunction. Servers use it to protect against overload, DDoS attempts, brute-force login attacks, and scrapers. APIs use it to enforce fair usage across clients. Shared hosting platforms use it to stop one site from consuming resources that affect others on the same server.

When 429 hits, the response may include a Retry-After header that tells you exactly how long to wait:

HTTP/1.1 429 Too Many Requests Retry-After: 3600

That 3600 means 3600 seconds — one hour. Check the response headers before doing anything else. If there's a Retry-After value, that's your answer.

How to Fix 429 Too Many Requests as a Visitor

User Fix 1: Wait and Retry

If you hit a rate limit, the simplest fix is also the correct one: stop sending requests and wait. Server-side rate limits reset after a fixed period, typically anywhere from 30 seconds to an hour depending on the service.

Check the Retry-After header in the error response if the site or API surfaces it. That header contains the exact number of seconds before the limit resets. Retrying before that window closes will just restart the counter.

If there's no Retry-After header, wait a few minutes before trying again. Don't hit refresh repeatedly — that's exactly what got you rate-limited in the first place.

User Fix 2: Clear Browser Cache and Cookies

Corrupted or stale browser data can cause your browser to send malformed or repeated requests that a server's rate limiter flags as suspicious traffic. Clearing the cache and cookies gives you a clean slate.

In Google Chrome:

Click the three-dot menu (top right) and go to Settings.
Select Delete browsing data from the left sidebar.
Choose Cached images and files and Cookies and other site data.
Set the time range to All time.
Click Delete data, then restart Chrome.

Firefox, Safari, and Edge follow the same general pattern. After clearing, retry the page. If that clears the 429, stale browser data was the trigger.

User Fix 3: Flush the DNS Cache

Your local DNS cache maps domain names to IP addresses. If a cached entry is stale or pointing to a wrong address, your browser may end up firing repeated requests at the wrong endpoint — which some rate limiters count toward your limit even if the requests never reach valid content.

Flushing the DNS cache forces a fresh lookup.

Windows: Open Command Prompt as Administrator and run: ipconfig /flushdns

macOS: Run in Terminal: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux: Run: sudo systemd-resolve --flush-caches

After flushing, retry the site. If the 429 disappears, the stale DNS record was causing your requests to hit a misconfigured endpoint.

How to Fix 429 Too Many Requests as a Site Owner

Owner Fix 1: Upgrade Your Hosting Plan

If your site is triggering 429 responses for legitimate visitors, the most likely cause on shared hosting is resource exhaustion. Shared plans cap CPU usage, simultaneous connections, and requests per minute. When traffic spikes, you hit those caps fast.

Moving to a VPS or cloud hosting plan removes those hard ceilings. You get dedicated CPU and RAM, and the request limits scale with the resources you pay for rather than being shared across dozens of other sites on the same machine.

Signs that a hosting upgrade is the right fix: the 429 errors correlate with traffic spikes, peak hours, or viral content. If the server is calm and you're still getting 429s, the problem is more likely a plugin or theme.

Owner Fix 2: Disable WordPress Plugins

Some WordPress plugins make frequent outbound or inbound HTTP requests as part of their normal operation — social sharing buttons polling APIs, email automation tools syncing lists, analytics scripts firing on every page load. On a server with tight rate limits, these background requests can push the site past its quota.

To isolate the culprit:

Go to Plugins > Installed Plugins in wp-admin.
Select all plugins and choose Deactivate from the Bulk actions menu.
Check whether the 429 errors stop.
If they do, reactivate plugins one at a time, checking after each one, until the error returns.
The last plugin you activated is the source.

If you can't access wp-admin, rename the wp-content/plugins folder to plugins_disabled via FTP or your hosting file manager. WordPress deactivates all plugins automatically.

Owner Fix 3: Switch to a Default WordPress Theme

Custom themes that load multiple external fonts, scripts, CDN resources, and tracking pixels can generate a surprisingly high number of HTTP requests on every page load. If the 429 errors started after a theme change, this is worth testing.

In wp-admin, go to Appearance > Themes and switch to a default theme like Twenty Twenty-Four. If the 429 errors drop, your previous theme was generating too many requests. Contact the theme developer or look for a lighter alternative.

Before switching themes, back up your site. Switching themes doesn't delete content, but it removes all customisations tied to the previous theme.

Owner Fix 4: Contact Your Hosting Provider

If none of the above resolves the issue, the rate limit may be set at the server configuration level, not the application level. Hosting providers sometimes set conservative request-per-minute limits that don't scale with legitimate traffic growth.

Contact support with:

The specific error code and the time(s) it occurred.
Whether the 429 affects all visitors or specific IPs.
Your current hosting tier and recent traffic data.

They may be able to raise the rate limit threshold, assign a dedicated IP, or configure a CDN to absorb traffic spikes before they hit your origin server.

What Causes the 429 Error?

API rate limits. Most APIs enforce strict request quotas per API key per minute. Exceed them and 429 fires immediately. This is the expected behaviour, not a bug.
Server resource caps. Shared hosting plans have hard limits on CPU, RAM, and concurrent connections. Heavy traffic or inefficient code pushes you past them.
Brute-force attacks. Bots hammering your WordPress login page with credential stuffing attempts generate massive request volumes that trigger server-level rate limiters.
Misbehaving plugins or themes. Background tasks, polling loops, and poorly optimised asset loading can generate enough internal requests to hit rate limits even with zero external traffic.

How to Prevent 429 Errors

The /wp-admin and /wp-login.php URLs are the same on every WordPress site on the internet. Bots know this. They hit those endpoints constantly with credential lists, generating thousands of login attempts per hour from a single botnet.

Changing the login URL to something non-standard cuts off the predictable attack surface. Install WPS Hide Login from the WordPress plugin directory, activate it, and go to Settings > WPS Hide Login. Set a custom URL path. Save changes.

The old /wp-admin URL stops working immediately. The bots keep trying it and get 404s instead of 429s. Your server stops wasting rate limit budget on failed login attempts.

Prevention 2: Implement WordPress Rate Limiting

Rate limiting on your own site means you control who gets throttled, at what threshold, and for how long. Wordfence Security includes a built-in rate limiting engine that lets you set separate rules for crawlers, humans, and bots.

After installing Wordfence, go to Wordfence > All Options > Firewall Options > Rate Limiting. Reasonable starting settings:

Throttle if anyone's requests exceed 240 per minute.
Throttle if a crawler's page views exceed 120 per minute.
Throttle if a crawler's 404s exceed 60 per minute.
Block IPs that break rules for 30 minutes.

Adjust these based on your actual traffic patterns. High-traffic editorial sites need looser thresholds. Low-traffic B2B sites can run tighter limits safely.

Even with the login URL changed, adding a login attempt limit is worth doing. Wordfence's Brute Force Protection locks out IPs after a configurable number of failed logins.

Practical settings:

Lock out after 3-5 login failures.
Lock out after 3-5 failed password reset attempts.
Count failures over a 4-hour window.
Lock out duration: 30 minutes minimum.

Add reCAPTCHA v3 on top of this. Go to Wordfence > Login Security > Settings and enter your reCAPTCHA v3 site key and secret. This blocks automated login tools that can solve simple CAPTCHAs but struggle with v3's risk-scoring approach.

Impact of 429 Errors on SEO and User Experience

Search engine crawlers treat 429 the same way they treat any server error: if they can't fetch a page, they can't index it. A crawl that repeatedly hits 429 responses will back off and crawl less frequently. Pages that go unindexed stop ranking.

For users, a 429 is a dead end. There's no helpful error message, no redirect, no suggestion. They see a broken page and leave. Bounce rate climbs, session depth drops, and returning visitors start associating your domain with unreliability.

The brand damage is slower but compounds. A site that goes down during a traffic spike — exactly when it should be getting its largest audience — trains visitors not to depend on it.

Rate limiting, a properly scaled hosting plan, and clean plugin management prevent all of this. The 429 is almost always a preventable error.