Skip to content
Webmaster Tools
Inspect & debugHTTP Status Codes429 Too Many Requests

429 Too Many Requests

What HTTP 429 Too Many Requests means, why servers send it, how to handle it in clients with Retry-After and backoff, and how it affects Googlebot.

All status codes

What 429 means

The client sent more requests than the server allows in a period of time: it hit a rate limit. 429 is defined in RFC 6585 §4. The server may say when to try again with a Retry-After header, either a number of seconds or an HTTP date:

HTTP/1.1 429 Too Many Requests
Retry-After: 30
Content-Type: application/json

{"error": "rate limit exceeded, try again in 30 seconds"}

Many APIs also send headers that show the budget before you run out, such as RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset (or the older X-RateLimit-* names).

Common causes

  • An API's rate limit: too many calls per second, minute or day for your key, account or IP address.
  • Abuse protection in a CDN or firewall (Cloudflare, AWS WAF, nginx limit_req) that counts requests per IP.
  • Retries that make it worse: a client retries immediately after every failure, so one burst turns into a storm.
  • Shared IP addresses: many users behind one office NAT, VPN or cloud egress IP share one per-IP budget.
  • Crawlers and scripts fetching pages in parallel without a delay.

How to fix it as a client

  1. Honour Retry-After. Wait at least that long before the next request to that server.
  2. Back off exponentially when there's no Retry-After: wait 1 s, then 2 s, 4 s, 8 s…, with some random jitter, and give up after a few tries.
  3. Spread requests out: queue them and send at a steady rate under the limit instead of in bursts.
  4. Cache responses you fetch repeatedly, and use bulk endpoints where the API has them.
  5. Check which budget you hit. A per-key limit needs fewer calls or a higher plan; a per-IP limit may need the traffic spread over time.

How to send it as a server

Return 429 with a Retry-After header rather than 403 or 503, so clients and crawlers know it's temporary and when to come back. In nginx:

limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    location /api/ {
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
    }
}

429 and SEO

Googlebot treats 429 like a server error: it slows down crawling of the whole site, and URLs that keep answering 429 for a long time can drop out of the index. Don't rate-limit search engine crawlers you want to keep. If a CDN or firewall rule is catching them, allow verified Googlebot and Bingbot, and let them slow down by themselves.

To see what a URL answers right now, run it through the Redirect Checker, which shows the status of every hop, or send a custom request with the HTTP Request Builder.