429 Too Many Requests

What an HTTP 429 status means, how Google treats rate limiting and backs off from crawling, how it affects crawl budget, and how to configure your server to send 429s without causing deindexing.

First published: Jun 27, 2026 · Last updated: Jul 17, 2026 · Advanced
demand #6 in HTTP Errors#6 in HTTP Status Codes#21 in Technical SEO#30 on the site
AIAuthored byAI v2
2 evidence signals on this page

429 Too Many Requests is the one 4xx code Google doesn't treat like a client error. Once it sees enough of them, it reads that as a server-overload signal — the same bucket as 5xx — and throttles Googlebot's crawl rate across your whole hostname instead of dropping your content. That makes it the correct, Google-endorsed way to slow a crawler down (never 403 or 404). But it's a short-term tool: keep it to a couple of hours or 1–2 days, send a Retry-After header as best practice, and scope it to the right traffic. Sustained 429s on the same URLs for days can still get them dropped from the index.

TL;DR — 429 is the single 4xx code Google treats like a 5xx: once it encounters a significant number of 500/503503 Service Unavailable is the HTTP status code a server returns when it's temporarily unable to handle a request — usually because of overload or planned maintenance. It tells crawlers 'come back later' instead of 'this page is gone,' which is why Google recommends it (paired with a Retry-After header) for short, planned downtime./429 responses, it reads that as a server-overload signal and throttles GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.’s crawl rateCrawl rate is how fast a search engine crawler fetches pages from your site — the number of simultaneous requests it makes and the delay between them. Google sets it automatically based on your server's health; it's the supply side of crawl budget, not a ranking factor. hostname-wide instead of removing content. It’s the one code Google endorses for slowing a crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. down — never 403 or 404. Google’s docs give emergency-use guidance of “a couple of hours, or 1–2 days” — not a guaranteed safe window; sustained 429s on the same URLs risk those URLs eventually being dropped from the indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed., and the throttle starts increasing again (not necessarily instantly or fully) once error volume falls. RFC 6585 says a 429 SHOULD explain the condition and MAY include Retry-After — sending it is recommended practice, not a compliance requirement. Scope the limit to the right traffic and verify crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. identity before writing exceptions.

What 429 is at the protocol level

Straight from the spec, as MDN puts it: “The HTTP 429 Too Many Requests429 Too Many Requests is an HTTP client-error status code that means a client sent too many requests in a given time window — a mechanism called rate limiting. Unlike other 4xx codes, Google treats 429 as a server-overload signal and slows crawling instead of removing content. client error response status code indicates the client has sent too many requests in a given amount of time. This mechanism of asking the client to slow down the rate of requests is commonly called ‘rate limiting.’” Evidence for this claim A 429 response means the user sent too many requests in a given time, and the response may include Retry-After. Scope: RFC 9110 defines the status and optional Retry-After field; it does not define a universal rate threshold. Confidence: high · Verified: IETF: RFC 9110 §15.5.20 — 429 Too Many Requests

RFC 6585 §4 is more precise than most summaries of it get. A 429 representation SHOULD explain the condition and MAY include a Retry-After header giving the client a concrete number of seconds (RFC 9110 also allows an HTTP date) to wait before retrying — Retry-After is a recommended practice, not a compliance requirement. The spec also doesn’t define how a client is identified or how requests are counted; that’s left entirely to whatever issued the response (per IP, per session, per API key, per resource — implementation policy, not protocol). One more rule that’s easy to miss: RFC 6585 says a 429 response must not be stored by a cache. If you see a 429 that looks cached or replayed on a healthy origin, that’s an intermediary (CDN, proxy) misbehaving, not the origin re-deciding to limit you.

I’ve always framed it plainly in my HTTP Status Codes & Their SEO Impact guide: 429 is “a form of rate-limiting to protect the server because the client sent too many requests to the server too fast.” Nominally it’s a client error — the client did something wrong by asking too much. But that framing is exactly where the SEO story diverges from the spec.

The one exception among 4xx codes

The single most important fact on this page: Google does not treat 429 like the rest of the 4xx family. Gary Illyes wrote a whole Google Search Central blog post about this in February 2023, because enough sites and CDNs were misusing 404s to throttle GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. that Google had to tell them to stop.

His rule: “The one exception is 429, which stands for ‘too many requests’. This error is a clear signal to any well-behaved robot, including our beloved Googlebot, that it needs to slow down because it’s overloading the server.” And the flip side, in Google’s status-code reference: “Don’t use 401 and 403 status codes for limiting the crawl rateCrawl rate is how fast a search engine crawler fetches pages from your site — the number of simultaneous requests it makes and the delay between them. Google sets it automatically based on your server's health; it's the supply side of crawl budget, not a ranking factor.. The 4xx status codes, except 429, have no effect on crawl rate.”

So in the same breath where 403 and 404 will get your content removed from Search, 429 gets you a temporary slowdown. Google literally buckets it with server errors: “Google’s crawlers treat the 429 status code as a signal that the server is overloaded, and it’s considered a server error.” Evidence for this claim Google treats 429 as a server-overload signal that reduces crawl rate and recommends 429, 500, or 503 for temporary crawl reduction instead of other 4xx codes. Scope: Google's guidance covers Google crawler behavior and short-term overload; it does not promise indexing preservation during prolonged unavailability. Confidence: high · Verified: Google: Reduce Google crawl rate

This is what makes 429 the useful sibling of 503 Service Unavailable503 Service Unavailable is the HTTP status code a server returns when it's temporarily unable to handle a request — usually because of overload or planned maintenance. It tells crawlers 'come back later' instead of 'this page is gone,' which is why Google recommends it (paired with a Retry-After header) for short, planned downtime. (the traditional maintenance/temporary-unavailable signal) — and the exact opposite of 403 ForbiddenAn HTTP 403 client-error status code meaning the server understood the request but refuses to fulfill it — access is denied, whether or not credentials are involved. For SEO, a 403 served to Googlebot on a page meant to be public and indexable usually points to a misconfigured rule; a persistent 403 keeps a page out of the index either way., which is the wrong tool for rate limiting despite how many firewalls default to it.

Crawl-rate impact is hostname-wide — with a threshold

Two different scopes get conflated here, and it’s worth separating them. How you count and key a rate limit — per IP, per session, per API key, per resource, per server — is your own policy; the HTTP spec doesn’t define it. What Google does with the errors it observes is a separate, documented behavior, and it’s conditioned on volume, not a single response: “Google’s crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. infrastructure reduces your site’s crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. rate when it encounters a significant number of URLs with 500, 503, or 429 HTTP response status codes.” Once that threshold is met, “the reduced crawl rate affects the whole hostname of your site (for example, subdomain.example.com), both the crawling of the URLs that return errors, as well as the URLs that return content.”

In other words, if you 429 a subset of pages (say, a heavy API path) at real volume, Googlebot slows its crawling of the entire hostname — including the pages still returning 200. That’s usually the intended effect when your goal is to reduce total load. But one isolated 429 on one path, on its own, doesn’t establish that hostname-wide effect — Google’s own wording is scoped to “a significant number” of error responses, not any single one.

The 1–2 day guidance — when 429 turns risky

429 is a short-term signal, and Google gives concrete emergency-use guidance for it — not a guaranteed safe window or a hard cliff. From the “reduce crawl rate” docs: “If you need to urgently reduce the crawl rate for short period of time (for example, a couple of hours, or 1-2 days), then return 500, 503, or 429 HTTP response status code instead of 200 to the crawl requests.”

Push past that and you’re in riskier territory, though Google frames it as a possibility, not a promise: “We don’t recommend that you do this for a long period of time (meaning, longer than 1-2 days) as it may have a negative effect on how your site appears in Google products… if Googlebot observes these status codes on the same URL for multiple days, the URL may be dropped from Google’s index.” The status-code reference says the same thing for 5xx and 429 together: “already indexed URLs are preserved in the index, but eventually dropped.”

The risk model, stated honestly: short-term 429 fits the window Google recommends for emergency use; sustained 429 on the same URLs over multiple days is where Google’s own language turns to “may” and “eventually dropped” — a documented risk, not a guaranteed outcome either way. It’s the same dynamic as a prolonged 503.

Crawl rate recovers automatically

The reassuring flip side: there’s no penalty flag that follows your site around. Once the errors subside, Google says “the crawl rate will automatically start increasing again.” You don’t file anything, you don’t re-request anything. Note the exact wording, though — Google says “starts increasing,” not “instantly returns to your prior rate.” Treat recovery as a documented direction with no fixed timeline or guaranteed endpoint, not an SLA.

(Contrast that with the opposite problem — wanting Google to permanently crawl you less. If serving errors isn’t feasible, Google says to “file a special request to report a problem with unusually high crawl rate” — a manual path that can take days and isn’t guaranteed. There’s no such friction for recovery.)

How Bing handles 429

BingbotBingbot is Microsoft Bing's primary web crawler — the bot that discovers, fetches, and renders pages to build the Bing index. That index also powers Yahoo, DuckDuckGo, Ecosia, and Microsoft Copilot, so Bingbot's reach is far wider than Bing's own search-market share. is widely reported to behave similarly — 429/500/503 signaling overload and BingbotBingbot is Microsoft Bing's primary web crawler — the bot that discovers, fetches, and renders pages to build the Bing index. That index also powers Yahoo, DuckDuckGo, Ecosia, and Microsoft Copilot, so Bingbot's reach is far wider than Bing's own search-market share. backing off — though I couldn’t independently confirm current wording to that effect on Bing’s own help pages in this research pass (they’re JS-rendered SPAs that didn’t yield fetchable static text). Treat the parity claim as industry-reported, not something I’ve verified against current Bing documentation. What Bing does confirm, in its own historical guidance, are two proactive controls Google doesn’t offer in the same form:

  • Crawl Control in Bing Webmaster ToolsMicrosoft's free portal for monitoring and improving how a site appears in Bing search — the peer to Google Search Console, plus IndexNow instant indexing, richer backlink data, and keyword volumes. Because Bing's index also feeds Microsoft Copilot, it doubles as a window into AI-search visibility., a requests-per-second grid where you set Bingbot’s speed by hour of day.
  • The crawl-delay robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. directive. Current Bing Webmaster guidance documents values from 1–20 seconds. This is Bing-specific; it does not throttle Googlebot.

So on Bing you can throttle proactively with crawl-delay or Crawl Control instead of reactively with status codes. (Google retired its own manual crawl-rate slider in 2024 and now leans entirely on your server’s responses.)

Note: Bing’s current Crawl Control and crawl-error help pages are JavaScript-rendered; the crawl-delay wording above is from Bing’s own 2009 blog post, still-honored guidance rather than a current UI screenshot. The 429-parity claim above and the current state of crawl-delay/Crawl Control are both needs-review against current primary Bing documentation — confirm exact present-day wording in Bing Webmaster Tools before quoting any of this as current.

When you’d deliberately send a 429

Legitimate reasons to return 429 on purpose:

  • Emergency server load — a traffic spike, a botched migration, or an outage where you need Googlebot to ease off right now for a few hours.
  • Protecting APIs and non-HTML endpoints from crawler/bot abuse — search-engine crawlers, third-party SEO crawlers (Ahrefs, Screaming Frog), and scrapers all hit rate limits meant to stop abuse.

What 429 is not for: permanently blocking bots you don’t want at all. If you never want something crawled, that’s a robots.txt disallow job, not a 429. And if you want to keep a page but out of the index, that’s noindex. 429 only means “later,” not “never.”

Unintentional 429s — the usual culprits

When 429s show up in GSC’s Page IndexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. or Crawl Stats reportA Google Search Console report (under Settings) that shows how Google has crawled your site over the last 90 days — total requests, download size, and average response time, broken down by response code, file type, Googlebot type, and purpose. It's only available for root-level properties (a Domain property or a URL-prefix property verified at the site's root). and you didn’t put them there, the source is typically one of these — I’m not aware of good evidence for a universal ranking of which is most common, so treat this as a list of candidates to rule in or out, not a diagnosis:

  • WAF / firewall rules misfiring on legitimate crawler IP ranges.
  • Shared hosting or CDN default rate limits that are too tight for a real crawl.
  • Bot-management tools misclassifying Googlebot or Bingbot as abusive traffic.
  • Aggressive rate-limiting middleware meant for API abuse catching your own crawlers.

Before you touch a threshold or write a rule that exempts real search bots, establish provenance first — don’t guess which layer owns the response. Pull the raw response headers, the exact request log lines (not a dashboard summary), the rule or rate-limit-zone identifier that fired, the client key it counted against (IP, session, API key), the route, the CDN POP or edge location, and the time window. That combination tells you which layer actually issued the 429 and what it was counting — only then does it make sense to loosen a limit or add an exception. Verify crawler identity with reverse-plus-forward DNS (Google’s official method), not the user-agent string alone — spoofed “Googlebot” user-agents are common. The Scripts tab has the exact commands.

The short version of the playbook

  1. Use 429 or 503 with Retry-After to slow a crawler — never 403 or 404.
  2. Keep it to hours, or 1–2 days — beyond that, URLs can be dropped.
  3. Remember the throttle is hostname-wide, and auto-recovers when errors stop.
  4. Scope the limit to the right traffic and verify crawler identity before exempting bots.

Try it live

This is a real endpoint on this site — not a simulation. Hit it from the button, open it in a new tab, or curl -i it from your terminal, and the server answers with the actual status code this article is about.

Open in new tab ↗

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.