# 429 too many requests: what it means and how to fix it

> A 429 too many requests error means a rate limit fired: some client asked faster than the server allows, and that client can be you, your office, your crawler or your own site. Visitor fixes first, then both owner sides.

Updated 2026-10-19 · Technical SEO · HTML version: https://getreport.app/guides/429-too-many-requests

A 429 too many requests error means a rate limit fired: the server is up, saw the request, and refused it because this client has asked too often in a short time. Nothing is broken on either side; a counter ran over a line someone drew. The catch is the word "client": it can be you, everyone in your office behind one shared address, an SEO crawler you pointed at the site, or your own website calling an API too eagerly. This guide gives visitors the one-minute version, then takes site owners through both directions; your site sending 429s, and your site receiving them. For where 429 sits among all the others, see the [guide to HTTP status codes](https://getreport.app/guides/http-status-codes).

## Quick answer

- **Visitor:** stop refreshing and wait. If the error page names a time or a `Retry-After` value, wait that long; otherwise give it a minute, then longer. Retrying fast is the one thing that makes it worse.
- **On a VPN, office or campus network,** the limit probably counted everyone behind your shared address, not you. Wait, or switch networks.
- **Site owner, sending 429s:** find which layer's limit fired (a CDN or WAF rate rule, a login-protection plugin, your host, or nginx `limit_req`) and check it is not catching Googlebot or whole offices.
- **Rate limiting should answer 429 (or 503), never 403**: Google treats 429 as "slow down" and 403 as "drop this content", per Google Search Central.
- **Site owner, receiving 429s** from an API your site calls: honor `Retry-After`, add backoff, and cache the answers so most page views never call the API at all.
- **429 or [503](https://getreport.app/guides/503-service-unavailable)?** 429 blames one client's rate; 503 says the whole server is unavailable. Both mean "come back later".

## What does 429 too many requests mean?

The code has its own little standard: RFC 6585 defines 429 as "the user has sent too many requests in a given amount of time" and puts the word *rate limiting* right in the definition. Two details in that RFC do real work:

- **The server decides what a "user" is and what it counts.** The RFC leaves identification and counting entirely to the server: per IP address, per account, per API key, per resource or across a whole set of servers. That is why you can be rate limited "without doing anything"; the counter may belong to your network, not to you.
- **The response may carry a `Retry-After` header** saying how long to wait, as seconds or a date. It is optional, but a well-run limiter sends it, and clients that honor it recover fastest.

The RFC also says a 429 must never be stored by a cache: each retry genuinely re-asks the server, so when the window resets, the next request goes through.

In practice the client that tripped the limit is one of four suspects: a person refreshing or clicking fast; a shared address (office NAT, VPN, campus or mobile-carrier network) whose combined traffic looks like one heavy user; a bot or crawler, yours or someone else's; or a server-side integration; a plugin or script polling an API on every page view.

![A request counter at the server door: requests within the allowance pass through, the burst over the line is turned away with 429 and a Retry-After note](https://getreport.app/guides/img/429-too-many-requests/diagram.svg "A 429 is a counter, not a crash: requests under the limit pass, the excess waits out the Retry-After.")

## If you're a visitor: wait, don't hammer

A 429 punishes speed, so every fix is a form of slowing down:

1. **Stop refreshing.** Each retry inside the window counts against the same limit; rapid retries keep you locked out longer.
2. **Honor the timer if there is one.** Some error pages show a wait time or the `Retry-After` value. No timer? Wait a minute, and if it fails again, wait a few minutes more before the next try.
3. **On a VPN or shared network, the limit is probably collective.** Cloudflare's rate-limit page, "Error 1015: You are being rate limited", is a common sight on VPN exits for exactly this reason. Switching networks (or turning the VPN off for that site) gives you a fresh address.
4. **Close duplicate tabs and anything auto-refreshing**: a dashboard tab reloading every few seconds can spend your whole allowance by itself.
5. **If it persists for hours**, tell the site owner which page and when. A limit that locks out normal readers is set too tight, and only they can retune it.

## If your site returns 429s: find the limiter

Somewhere in your stack a rule is doing what it was told. The usual suspects, outermost first: a CDN or WAF rate rule (Cloudflare's rate limiting rules, for example), a security or login-protection plugin, your host's own throttling, an API gateway, or the web server itself. The error page usually carries the vendor's branding, and that names the layer. One wrinkle on nginx: `limit_req` answers **503 by default**, so an nginx rate limit often doesn't look like one; the [503 guide](https://getreport.app/guides/503-service-unavailable) covers it and the `limit_req_status 429;` line that fixes the label.

Once you know which rule fired, ask who it is catching:

- **Real visitors behind one address.** Offices, campuses and VPNs funnel many people through one IP. If support tickets say "it works from my phone but not from work", your per-IP window is too small. Raise the burst, or scope the limit to expensive paths (login, search, API) instead of the whole site. The [rate limiting guide](https://getreport.app/guides/rate-limiting-and-bot-protection-on-a-small-site) is the full recipe for setting limits that stop abuse without these casualties.
- **Googlebot.** Google Search Central's documentation on HTTP status codes says its crawlers treat 429 as a server-overload signal: crawling slows while the errors last, and URLs that persistently answer 429 are eventually dropped from the index. Check Search Console → Settings → Crawl stats for a drop in crawl requests and a rise in error responses starting the day the rule shipped, and grep your logs for 429s served to Googlebot's user agent. The same documentation is explicit that 401 and 403 are the wrong tools for crawl control (every 4xx except 429 has no effect on crawl rate and just gets content dropped) so a limiter should answer 429 or 503, never 403.
- **Your own robots.txt.** Never let a rate limit cover `/robots.txt`: Google treats a robots.txt that answers 429 like a 5xx, and that can stall crawling of the whole site, as the [robots.txt guide](https://getreport.app/guides/robots-txt) explains.
- **Actual abuse.** If the logs show one address or user agent hammering a path, the limit is doing its job. Send `Retry-After` so well-behaved clients back off cleanly, and let it stand.

## If your site receives 429s: back off and cache

The other direction is easy to miss because visitors never see the code. Your site calls someone else's API (currency rates, maps, a social feed, shipping quotes, an AI service) and that API starts answering 429 because your plan's quota or rate is spent. The symptom is a feature quietly breaking: empty widgets, stale prices, a checkout step failing, and 429s from the remote host in your error log.

Three fixes, in order of value:

1. **Cache the answers.** Most API data does not change per page view. One server-side cached copy, refreshed every few minutes, turns thousands of API calls a day into dozens. If each visitor's page load triggers its own API call, this is the whole problem.
2. **Honor `Retry-After` and back off.** When a call gets a 429, wait at least the header's value before retrying; without a header, double the wait after each failure (1s, 2s, 4s…) instead of retrying in a tight loop. A loop of instant retries is how a small overage becomes an hours-long outage, and some providers suspend keys that ignore 429s.
3. **Spread and batch the work.** Cron jobs that sync "everything, every minute" are the classic cause. Sync less often, request in batches where the API allows it, and stagger jobs so they don't all fire at the top of the hour. If you are still over, that is what the provider's bigger plan is priced for.

## Does a 429 hurt SEO?

Briefly, no: Google's documentation even lists 429 and 503 as the codes to answer when you need Googlebot to slow down in an emergency. Persistently, yes: Google Search Central's page on HTTP status codes says crawling slows while 429s last, indexed URLs are kept at first, and URLs that keep answering 429 are removed from the index. Crawling ramps back up once the site answers 2xx again.

So the damage profile matches the other "come back later" codes: a burst during a traffic spike costs nothing, while a rate rule that serves Googlebot 429s on ordinary pages for weeks quietly bleeds the index. The rule of thumb: limits belong on login pages, search endpoints and APIs, not on the content Googlebot needs to crawl.

## How to check your pages for 429s

A too-tight limit rarely shows while you browse your own site alone. Test the way crawlers hit it: many URLs, close together.

> **Free tool:** [Bulk redirect checker: status of 1,000 URLs](https://getreport.app/tools/bulk-url-checker): Free bulk redirect checker. Paste up to 1,000 URLs and get each status code, final URL, redirect hops, noindex and canonical in one table, with CSV export.

Paste your sitemap URLs or top pages into the bulk URL checker: it requests up to 1,000 addresses and labels each row with its status code and response time. It is deliberately gentle (at most four parallel requests per host) so it checks pages without hammering them; if even that gets 429s or server-error rows on normal content pages, your limiter is far too tight for real crawlers.

For a single page, a getReport report answers it too: the indexability finding reports the HTTP status the page returned, and the server response time finding shows how close the server runs to needing limits at all.

> **Check: The page can be indexed.** To appear in search, a page must return HTTP 200, carry no noindex directive and be allowed in robots.txt. If any of the three fails, the page is invisible to searchers.
>
> 1. Open the technical detail to see which condition fails, then fix that one; the individual findings above have the steps.
> 2. After the fix, request indexing in Google Search Console to speed things up.

> **Check: Server response time.** Lighthouse flags a first byte slower than 600 ms. Caching and hosting fix this for most CMS sites.
>
> 1. Enable full-page caching (WordPress: WP Rocket, LiteSpeed Cache, WP Super Cache; or your host's server cache).
> 2. Use a CDN and keep database queries out of the request path.

## Common mistakes

- **Refreshing through a 429.** Every retry inside the window extends your lockout. Wait out the `Retry-After`.
- **Rate limiting with 403.** Google drops content behind 4xx codes and its documentation says only 429 affects crawl rate. Answer 429 or 503.
- **One tight limit on the whole site.** It catches offices, VPNs and Googlebot before it inconveniences an attacker. Scope limits to expensive paths.
- **No `Retry-After` header.** One line tells every well-behaved client exactly when to come back.
- **Letting the limit cover robots.txt.** A robots.txt answering 429 can stall crawling of the whole site.
- **Retrying an API in a tight loop.** Instant retries turn a spent quota into an outage. Back off, then cache so the calls stop happening.

## Questions people ask

### What does 429 too many requests mean?

It means a rate limit fired: RFC 6585 defines 429 as the user having sent too many requests in a given amount of time. The server is healthy and refusing on purpose, and it decides what counts as one "user"; an IP address, an account or an API key. Well-configured limiters add a Retry-After header saying how long to wait before the next request will pass.

### How long should I wait after a 429 error?

As long as the Retry-After header or the error page says, when there is one: that value comes from the limiter itself. Without one, wait a minute before the first retry, then double the wait after each failure: one minute, two, four. Most windows are measured in seconds or minutes, so patience nearly always clears it; retrying rapidly restarts the clock instead.

### Why am I getting 429 errors without doing anything?

Because the limit probably counted your network, not you. Offices, campuses, VPNs and mobile carriers put many people behind one shared IP address, and most rate limits count per address, so the combined traffic of everyone around you looks like one very heavy user. Cloudflare's "Error 1015" page on VPN exits is the classic case. Wait it out, or switch to another network for that site.

### Can 429 errors hurt SEO?

Short bursts, no: Google itself suggests answering 429 or 503 to slow Googlebot in an emergency. Sustained 429s, yes: Google Search Central's documentation says crawlers treat 429 as server overload, slow their crawling while it lasts, and eventually drop URLs that persistently return it. Keep rate limits off ordinary content pages and off robots.txt, and watch Search Console's crawl stats after tightening any rule.

### How do I fix 429 errors on my WordPress login page?

Loosen the login limit just enough for humans. A 429 on wp-login.php means your protection (a security plugin, a CDN rule or an nginx limit) is working but set too tight, and a shared office address hits it fastest. Allow a burst of a few attempts before blocking, lengthen the window rather than the ban, and keep the limit scoped to the login path. The [WordPress login security guide](https://getreport.app/guides/wordpress-login-security) has settings that balance both.

### Why is my website getting 429 errors from an API?

Because your site calls that API faster than your plan allows: usually a plugin or cron job polling on every page view or every minute. The fix is rarely a bigger plan: cache the API's answers server-side so most page views reuse one recent copy, honor the Retry-After header when a call is refused, and back off between retries instead of looping. Check the provider's dashboard for which key and endpoint is over.