HTTP 429 'Too Many Requests': What It Means & How to Fix

HTTP 429 “Too Many Requests” means you sent too many requests in too short a time and a server’s rate limiter told you to slow down — and the single worst thing you can do is retry immediately. It’s a client-side (4xx) status, but it’s not really an “error” in the broken sense: it’s a server deliberately throttling you. Here’s what triggers it and exactly how to fix it.

What does HTTP 429 mean?

429 is the standard status a server returns when a client exceeds a rate limit — the maximum number of requests it allows in a given window. The mechanism is called rate limiting, and it exists to protect servers and APIs from overload and abuse. When you cross the threshold, further requests get a 429 instead of being processed, usually until the window resets.

You’ll see it most when:

• Hitting an API too fast — the most common cause. APIs cap requests per second/minute/hour.
• A script or bot loops without pausing and hammers an endpoint.
• Too many requests from one IP — shared hosting, an office network, or a scraper.
• Aggressive crawling — including SEO crawlers set to crawl too fast.

The first thing to check: the Retry-After header

Before anything else, look at the response for a Retry-After header. A well-behaved server includes it with a 429, and it tells you exactly how long to wait — either a number of seconds or an HTTP date. Obey it. Waiting the stated time is the surest way to get unblocked, and ignoring it usually just extends the block.

If there’s no Retry-After, you’ll need to back off using your own logic (below).

How to fix HTTP 429 errors

The cure is always the same idea: send fewer requests. Concretely:

1. Stop retrying immediately. Retrying harder makes 429s worse and can lengthen the penalty. This is the #1 mistake — pause first.
2. Respect Retry-After. If it’s present, wait exactly that long before the next attempt.
3. Add exponential backoff. For repeated failures, increase the wait between retries progressively — e.g. 1s, 2s, 4s, 8s — ideally with a little random “jitter” so many clients don’t retry in sync.
4. Throttle proactively. Don’t wait to be blocked — cap your own request rate below the documented limit. Space out calls, batch where the API allows, and cache responses you’ll reuse.
5. Check the API’s documented limits and align to them. Many APIs publish rate-limit headers (like X-RateLimit-Remaining) so you can slow down before hitting zero.
6. Spread the load if it’s legitimately high volume — multiple keys/IPs where allowed, or queue the work.

Is a 429 a problem for my website’s SEO?

Usually only if you’re serving them to Googlebot. If your server returns 429 to Google’s crawler because it’s crawling faster than your site can handle, Google will back off crawling — occasional 429s are handled gracefully, but persistent ones can slow how quickly your pages get crawled and indexed. If you see Googlebot getting 429s in your logs, your server likely can’t keep up; that’s a performance/capacity issue worth fixing, and it sits alongside the other technical basics in technical SEO in the AI era. If you’re seeing crawl-related warnings in Search Console generally, the indexing guides here may help.

The bottom line

429 isn’t a bug to route around — it’s a server asking you to slow down, and the fix is to actually slow down. Read the Retry-After header, stop hammering, add exponential backoff with jitter, and throttle yourself below the limit so you don’t hit it again. Do that and 429s disappear without any drama.

If plain-English answers like this help, I send occasional notes on the technical side of running a site — subscribe below for those and the free GEO Starter Checklist.

Frequently asked questions

What does HTTP 429 Too Many Requests mean?

It means a client sent too many requests in a given period and the server's rate limiter is throttling further requests. It is a client-side (4xx) status used to ask you to slow down, not a sign the server is broken.

How do I fix a 429 error?

Stop retrying immediately, check the response for a Retry-After header and wait exactly that long, then add exponential backoff with jitter for repeated failures. Longer term, throttle your own request rate below the documented limit and cache responses so you send fewer requests.

What is the Retry-After header?

Retry-After is a header a server may include with a 429 (or 503) telling you how long to wait before trying again — as a number of seconds or an HTTP date. Obeying it is the fastest way to get unblocked.

Does a 429 error hurt SEO?

Only if your server returns 429s to Googlebot. Occasional ones are handled fine, but persistent 429s tell Google to slow its crawl, which can delay indexing. That usually signals your server cannot keep up with crawl demand — a capacity issue worth fixing.