Is 429 a client error or a server error for Google?

By number it is a client error, but Google's documentation says its crawlers treat 429 as a signal that the server is overloaded and handle it like a server error, together with 5xx.

Does a 429 remove my page from Google?

Not right away. Indexed URLs are preserved for a while when they return 5xx or 429, but Google's documentation says they are eventually dropped if the errors persist on the same URL for multiple days.

Why does my CDN return 429 to Googlebot?

Because a rate-limiting or bot-protection rule counts Googlebot's requests like any other client. Verify Googlebot by IP range and exempt it, or raise the limit for verified crawlers.

Can I use 429 to slow Google down on purpose?

Yes, for a short emergency. Google's reduce-crawl-rate documentation lists 429 next to 500 and 503 as codes that lower the crawl rate, and recommends not doing it for longer than 1-2 days.

What does Retry-After do with a 429?

It tells the client when to try again, as seconds or as an absolute UTC date. Google's documentation says its crawlers read it on 429 and 503 responses.

Where do 429 errors show up in Search Console?

In the Pages report under "URL blocked due to other 4xx issue", and in the Crawl Stats report as a response type and a drop in crawl requests.

429 status code (Too Many Requests)

A 429 status code means the client sent too many requests in a given time and the server is refusing to answer for now. Google does not treat it like the other 4xx codes: a 429 is read as a server overload signal, the same as a 503. Crawling slows down for the whole hostname, and URLs that keep returning 429 can fall out of the index.

A 429 means the server is refusing requests because the client sent too many. Google treats it as an overload signal like 503: crawl rate drops for the whole host and persistent 429s remove URLs from the index.

How it looks

A 429 is sent by whatever layer enforces the limit: the application, a reverse proxy, a WAF or a CDN. The body is usually a short error page; the headers may say when to retry.

HTTP/1.1 429 Too Many Requests

Retry-After: 120

Retry-After: Wed, 21 Oct 2026 07:28:00 GMT

Some rate limiters add headers such as X-RateLimit-Remaining. They help you debug, but only Retry-After is documented as read by Google's crawlers.

How Google handles it

Google's page on HTTP status codes is explicit: Google's crawlers treat the 429 status code as a signal that the server is overloaded, and it is considered a server error. All other 4xx codes are handled as "content does not exist" and have no effect on crawl rate; 429 is the single exception.

Being grouped with 5xx has three consequences listed in the same document. First, 5xx and 429 responses prompt Google's crawlers to slow down temporarily. Second, already indexed URLs are preserved in the index but eventually dropped. Third, any content received with the response is ignored, so the error page itself is never indexed. When the server returns 2xx again, Google gradually increases the crawl rate.

The reduce crawl rate documentation describes the scope. When Google's crawling infrastructure sees a significant number of URLs returning 500, 503 or 429, it reduces the crawl rate across the whole hostname, including URLs that still return content, and raises it again once the errors decrease. Google warns against doing this for more than 1-2 days: if Googlebot observes these codes on the same URL for multiple days, the URL may be dropped from the index. The same page documents the Retry-After header for 503 and 429 responses, as a delay in seconds or an absolute UTC date and time.

The crawl budget guide says that rate-limiting signals such as HTTP 429 lower the crawl capacity limit, so Google crawls less; the mechanism is described in the entry on crawl budget.

There is a second place where 429 bites: the robots.txt file. According to the robots.txt specification, a 429 on the robots.txt file is not treated like other 4xx responses; it falls under the 5xx handling, so Google stops crawling the site for the first 12 hours and then uses the last cached copy for up to 30 days.

Where 429s come from

CDN rate limiting rules with a per-IP threshold that Googlebot exceeds on a large site.
WAF or bot-management products that classify crawler traffic as abusive.
Application-level throttling on search, filter or API endpoints that also serve HTML.
Shared hosting limits on requests per minute.

Googlebot can be a legitimate source of bursts. Google's reduce crawl rate page names faceted navigation, calendars with many date URLs and Dynamic Search Ad targets as the usual causes of a sharp increase in crawling. Fixing the URL inventory is the durable fix; a 429 is a stopgap.

When a 429 is the right answer

Use 429 deliberately only when the alternative is the server falling over, and only briefly. Google's documentation on reducing the crawl rate says to return 500, 503 or 429 to urgently reduce crawling for a couple of hours or 1-2 days, and to file a special request if serving errors is not feasible. For anything longer, remove the cause instead.

Never use 401 or 403 for throttling. The HTTP status codes page says these codes do not affect crawl rate and that Google treats them as missing content, which means the URLs leave the index instead of being retried later.

Common mistakes

Mistake	Effect
Rate limit applied to all user agents, including verified Googlebot	Crawl rate drops site-wide; pages stop being refreshed
429 left on for weeks "to protect the server"	URLs that keep returning 429 are dropped from the index
429 on robots.txt	Google halts crawling, then crawls on a cached copy
403 used instead of 429 for throttling	Treated as missing content: no slowdown, URLs removed from the index
No Retry-After header	Google picks its own retry schedule; you lose the chance to say "in 2 minutes"

How to check it

Reproduce it with curl in a quick loop and look at the status codes:

for i in $(seq 1 30); do curl -s -o /dev/null -w "%{http_code}\n" https://example.com/; done

If codes switch from 200 to 429 after a few requests, the limit is per IP and will hit Googlebot too. Run curl -I https://example.com/ while the limit is active to see Retry-After. In browser devtools, a 429 shows in the Network tab, typically on calls to search or filter endpoints first.

In Search Console, open the Pages report. A 429 lands under URL blocked due to other 4xx issue, because the report has no dedicated 429 status; the one for server errors is Server error (5xx), which does not cover 429 either. The Crawl Stats report is more useful here: look for a drop in total crawl requests and for "Other client error (4XX)" in the responses table around the time the limit went live.

The redirect checker requests up to 10 URLs and shows the status and headers of each hop, including Retry-After, which is a quick way to confirm what an outside client receives.

How IndexRise monitors it

IndexRise fetches every monitored URL once a night and records the status code. A 429 is treated as the site refusing our check, not as a page error: the URL keeps its last known state and is shown as "couldn't be checked", and the project shows that the site's security is not letting monitoring in. We slow down instead of retrying harder. Because the crawler sends a modest number of requests, 429s in the nightly report usually mean the limit is low enough to hit Googlebot as well. When the site answers normally again, the block notice closes itself.

Google reads 429 as "your server is overloaded", not as "this page is missing". That is good for a few hours and bad for a few weeks, and the difference is only visible if someone checks every day.