429 Too Many Requests (RFC 6585) means the user has sent too many requests in a given amount of time. The response should explain the condition and may include a Retry-After header with the number of seconds, or a date, after which the client can try again. Caches must not store 429 responses.
Rate limits can apply per IP address, user, API key or endpoint. Many APIs also send headers such as X-RateLimit-Limit and X-RateLimit-Remaining, or the RateLimit header fields that the IETF is standardising, to show the remaining budget.
Well-behaved clients wait as long as Retry-After says, or back off exponentially, instead of retrying immediately. TrueURL's own API also answers with 429 and Retry-After if you run a very large number of checks in a short time.
Example response
HTTP/1.1 429 Too Many Requests
Date: Fri, 06 Nov 2026 10:15:32 GMT
Retry-After: 120
Content-Type: application/json
Content-Length: 81
{"error":"rate_limited","message":"Too many requests. Try again in 120 seconds."}SEO and redirect checking
Google treats 429 as a sign that the server is overloaded, similar to a 5xx error. Googlebot slows down crawling, and URLs that keep returning 429 can eventually be dropped from the index. Returning 429 or 503 for a short time is the recommended way to reduce crawling in an emergency; returning it for more than a day or two is not.
Make sure rate limits and bot protection do not hit legitimate crawlers during normal operation. A redirect check that returns 429 means the target is rate-limiting the checker; wait a while before checking again.
Common causes and use cases
- An API client exceeded its quota or burst limit.
- A login form blocks repeated attempts from the same IP address.
- A CDN or WAF rate-limiting rule is triggered by a crawler, monitor or bulk checker.
- Many users share one IP address (company network, mobile carrier) and hit a per-IP limit together.