What Is a 429 Too Many Requests Error and How Do You Fix It?

What Does 429 Too Many Requests Mean?

The response can indicate that:

• A request limit exists: The service controls how frequently a client may perform an operation.
• A threshold was exceeded: The request count, concurrency or resource quota crossed the configured boundary.
• The limit has a scope: It may apply to an IP address, account, API key, user, endpoint, hostname or another identifier.
• The restriction may be temporary: Access can resume after a window resets, capacity becomes available or the client reduces its request rate.
• The client should slow down: Immediate repeated requests can extend or repeatedly trigger the restriction.

The status does not reveal the exact quota, counting algorithm or identity used by the server. Those details must come from response headers, documentation, logs or the service provider.

How Does an HTTP 429 Response Work?

1. A browser, crawler, app or API client sends a request.
2. The service identifies the rate-limit key.
3. The service checks the current count, quota or concurrency level.
4. The request exceeds the permitted threshold.
5. The server rejects or postpones the operation.
6. The response returns 429 Too Many Requests.
7. The client waits, slows down or follows the published recovery policy.

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

{
  "error": "rate_limit_exceeded",
  "message": "Try again later."
}

The server may count fixed-window requests, rolling-window requests, tokens, concurrent operations or another resource unit.

What Is Rate Limiting?

Rate limiting protects service availability, controls costs, enforces product plans and reduces abuse. It should still provide enough information for legitimate clients to recover safely.

What Causes a 429 Too Many Requests Error?

The public response alone cannot prove whether the client is misbehaving or the limit is too restrictive. Compare request behavior with the intended policy and available capacity.

Who Is Being Rate Limited?

A limit may apply to:

• IP address: All clients sharing the address contribute to the same counter.
• User account: Requests from one authenticated user are grouped together.
• API key: Multiple applications using one credential share the same limit.
• Access token: Usage is counted against one authorization token.
• Application: The provider limits an entire registered integration.
• Endpoint: One expensive route has a stricter threshold.
• Hostname or origin: A CDN limits total traffic reaching one service.
• Organization or subscription: Several users share one plan-level quota.

This explains why one person can receive 429 despite making only a few visible requests: background jobs or other clients may share the same identity.

429 Error vs 403 Forbidden

Using 403 to represent rate limiting hides the temporary request-pressure condition and can cause search crawlers to interpret the response as an access restriction.

429 Error vs 503 Service Unavailable

An overloaded service may return either code depending on whether the system applies a client-specific limit or reports broad temporary unavailability.

429 Error vs 502 Bad Gateway

429 Error vs 504 Gateway Timeout

What Does the Retry-After Header Mean?

A delay in seconds:

HTTP/1.1 429 Too Many Requests
Retry-After: 120

The client is asked to wait 120 seconds.

A specific HTTP date:

HTTP/1.1 429 Too Many Requests
Retry-After: Wed, 05 Aug 2026 18:30:00 GMT

The client is asked to wait until the stated GMT time.

Review the syntax in MDN’s Retry-After reference.

What Are RateLimit Response Headers?

RateLimit-Limit: 100
RateLimit-Remaining: 0
RateLimit-Reset: 60
Retry-After: 60

Header names and semantics can vary between providers and standards versions. Follow the service’s current documentation rather than assuming every API uses the same format.

How Long Does a 429 Error Last?

The duration can depend on:

• The fixed or sliding request window
• The token refill rate
• The number of excess requests
• Whether retries continue adding pressure
• The client identity being counted
• The API plan or account quota
• Whether the restriction escalates after repeated violations
• Whether an administrator must manually restore access

Use Retry-After and provider documentation when available. Without those signals, stop aggressive retries and increase the delay between controlled attempts.

Can an API Cause a 429 Error?

API clients frequently trigger 429 by:

• Launching too many parallel requests
• Sharing one API key across many workers
• Polling instead of using webhooks
• Requesting unchanged data repeatedly
• Ignoring rate-limit headers
• Retrying immediately after failure
• Failing to batch supported operations
• Exceeding a purchased quota
• Running several integrations against the same account

The correct response is to comply with the published quota, reduce unnecessary calls, cache reusable data, batch operations where supported or request a legitimate quota increase.

Can WordPress Cause 429 Too Many Requests?

Common WordPress sources include:

• A plugin repeatedly calls an external API.
• WP-Cron launches overlapping jobs.
• A broken AJAX request loops in the browser.
• A security plugin rate-limits login attempts.
• A backup or import plugin sends large request bursts.
• An SEO crawler and cache preloader run simultaneously.
• XML-RPC or REST endpoints receive automated traffic.
• A plugin retries a failed request without backoff.

Inspect the exact URL, initiating plugin, cron schedule, browser network log and security-rule event. Deactivating every plugin at once may restore access but does not identify the responsible request pattern.

Can Cloudflare or a CDN Return 429?

Review:

• The CDN response headers and event identifier
• The exact firewall or rate-limit rule matched
• The client IP, user agent and request path
• Whether verified search crawlers were recognized correctly
• Whether several users share one public IP
• Whether the origin or the CDN generated the response
• The request rate before and after caching
• Regional differences between edge locations

A CDN can protect the origin from abusive traffic, but a poorly scoped rule can also block legitimate users, APIs or search crawlers.

Can a Firewall or Security Plugin Cause 429?

False positives can occur when:

• Many legitimate users share one IP address.
• A reverse proxy does not forward the real client IP correctly.
• A health checker requests the same endpoint frequently.
• A search crawler is not verified correctly.
• A mobile app creates background request bursts.
• An administrator performs repeated login or save actions.
• The threshold was copied from a lower-traffic environment.
• Several security layers count the same traffic separately.

Confirm the matching rule, rate-limit key and normal request baseline before raising the threshold.

Can Cron Jobs and Automation Trigger 429?

Common patterns include:

• Every job starts exactly at the top of the hour.
• Several servers run the same cron schedule.
• A missed schedule launches several delayed jobs together.
• Workers share one API token.
• The queue has no global concurrency limit.
• Failed requests are retried immediately.
• The job downloads unchanged data repeatedly.
• Large data sets are split into too many small requests.

Distribute job start times, centralize request quotas, queue work, cache results and use bounded retries with jitter.

Can AI Agents and Crawlers Trigger Rate Limits?

Common causes include:

• Parallel agents use the same API key.
• The agent repeats equivalent tool calls.
• Each page triggers additional API enrichment.
• The crawler ignores Retry-After.
• Several crawl sessions target the same host.
• The system lacks per-host concurrency limits.
• Failed requests create recursive retry loops.
• The agent does not cache previous results.

Use explicit budgets, per-host queues, deduplication, caching, maximum retries and traceable user-agent identification where appropriate.

Can Shared Hosting or a Shared IP Cause 429?

This can happen in:

• Corporate networks using one NAT gateway
• Schools, hotels and public Wi-Fi networks
• VPN or proxy services
• Shared hosting environments
• Serverless functions using shared outbound addresses
• Multiple applications sharing one API key
• Agencies managing several sites through one platform account

Confirm whether the limit uses an IP or another shared identity. Changing infrastructure may help only when it is a legitimate architectural correction, not an attempt to bypass provider controls.

Can Googlebot Receive a 429 Response?

A 429 may be intentional when:

• The server is under temporary crawl pressure.
• A large crawl competes with user traffic.
• A CDN applies a verified-bot rate limit.
• A particular URL group is unusually expensive.

It may be accidental when:

• Googlebot is grouped with unverified bots.
• All crawler traffic shares one overly strict rule.
• The CDN fails to verify Googlebot correctly.
• The origin sees only the proxy IP and counts all traffic together.

Review how access controls affect discovery in What Is Crawlability in SEO?.

Are 429 Errors Bad for SEO?

SEO risk increases when:

• Googlebot receives 429 across many URLs.
• The homepage or robots.txt is rate limited.
• XML sitemaps repeatedly return 429.
• New pages cannot be crawled after publication.
• Important changes remain unavailable to crawlers.
• JavaScript, CSS or rendering endpoints are restricted.
• The CDN rate-limits verified search crawlers accidentally.
• Normal responses do not return after the temporary event.

The status can be the correct short-term signal during overload, but it cannot make long-term inaccessibility harmless.

How Does Google Handle 429 Responses?

1. Googlebot requests a URL.
2. The server or CDN returns 429.
3. Google cannot retrieve the intended content from that request.
4. The response contributes to crawl-rate adjustment.
5. Googlebot may retry the URL later.
6. Persistent unavailability can cause crawling to slow substantially.
7. Long-term inability to retrieve pages can eventually affect indexing.

Google does not provide a guaranteed period during which rankings or indexing remain unchanged.

See Google’s crawling-error guidance.

Can 429 Errors Reduce Googlebot Crawling?

Crawl reduction becomes more likely when:

• Many URLs return 429 during the same period.
• The same directories remain restricted across retries.
• Robots.txt and sitemap files also return 429.
• The CDN blocks Googlebot across regions.
• The site continues rate limiting after capacity recovers.
• Successful requests are rare between rejected requests.
• Rate limiting combines with server timeouts or 5xx errors.

Crawl activity may recover after stable successful responses return, but recovery timing is not guaranteed.

Review the wider resource-allocation model in What Is Crawl Budget?.

Can Long-Term 429 Responses Affect Indexing?

Risk depends on:

• How long the rate limit remains active
• How many crawlable URLs are affected
• Whether the page was already indexed
• How often Googlebot normally revisits it
• Whether successful responses return between failures
• Whether canonical, rendering and sitemap resources are accessible
• Whether the entire hostname is restricted

A correct 429 is preferable to a misleading 200, 403 or 404, but it does not preserve inaccessible content indefinitely.

Should You Return 429 or 503 to Googlebot?

Use the status that accurately describes the condition. Both should be temporary and removed when normal service resumes.

Should a 429 Error Page Return 200?

A helpful branded page can explain the waiting period, but the response status must remain accurate.

Should You Block Googlebot in Robots.txt Instead?

Blocking in robots.txt can:

• Prevent Googlebot from retrieving the actual 429 response
• Block content crawling after capacity has recovered
• Remain active longer than the incident
• Apply too broadly to important URL groups
• Create a crawlability problem separate from server capacity

Use an accurate temporary HTTP response and restore successful access when the incident ends.

Validate current directives with the Robots.txt Checker.

How Do You Find 429 Errors?

Group responses by client identity, endpoint, time window, rule, region and credential. This reveals whether the issue is user-specific, crawler-specific or service-wide.

Inspect one URL with the HTTP Status & Redirect Chain Tracer.

How Do You Diagnose a 429 Error?

1. Capture the exact request and response.
2. Record Retry-After and rate-limit headers.
3. Identify whether the CDN, application or API returned 429.
4. Determine the counted identity.
5. Document the threshold and reset policy.
6. Measure request rate and concurrency before failure.
7. Find every process sharing the identity.
8. Check for retry loops, polling and duplicate work.
9. Compare the rule with legitimate traffic baselines.
10. Test a controlled lower request rate.
11. Verify recovery after the window resets.
12. Monitor the next comparable traffic period.

“Too many requests” is an observation. A root cause identifies which client generated the traffic, why it generated that pattern and why the applied policy rejected it.

How Do Clients Fix 429 Too Many Requests?

1. Stop immediate retries.
2. Read Retry-After and provider-specific quota headers.
3. Wait for the requested period.
4. Reduce parallel workers.
5. Cache reusable responses.
6. Batch operations where the API supports batching.
7. Replace polling with webhooks where available.
8. Deduplicate equivalent requests.
9. Add exponential backoff and random jitter.
10. Set a maximum retry count.
11. Queue excess work instead of discarding control.
12. Request a legitimate quota increase when justified.

How Do Website Owners Fix Repeated 429 Errors?

After the correction, test representative users, search crawlers, API clients and regions. Confirm that the rule does not merely move the failure to another layer.

How Do You Implement Exponential Backoff?

JavaScript example

async function requestWithBackoff(url, options = {}, maxRetries = 5) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const response = await fetch(url, options);

    if (response.status !== 429) {
      if (!response.ok) {
        throw new Error(`HTTP ${response.status}`);
      }
      return response;
    }

    if (attempt === maxRetries) {
      throw new Error("Rate limit persisted after maximum retries");
    }

    const retryAfter = response.headers.get("Retry-After");
    const retrySeconds = retryAfter && /^\d+$/.test(retryAfter)
      ? Number(retryAfter)
      : null;

    const exponentialDelay = Math.min(1000 * 2 ** attempt, 30000);
    const jitter = Math.floor(Math.random() * 1000);
    const waitMs = retrySeconds !== null
      ? retrySeconds * 1000 + jitter
      : exponentialDelay + jitter;

    await new Promise(resolve => setTimeout(resolve, waitMs));
  }

  throw new Error("Unexpected retry state");
}

Python example

import random
import time
from email.utils import parsedate_to_datetime
from datetime import datetime, timezone

import requests


def retry_after_seconds(value: str | None) -> float | None:
    if not value:
        return None

    if value.isdigit():
        return float(value)

    try:
        target = parsedate_to_datetime(value)
        now = datetime.now(timezone.utc)
        return max(0.0, (target - now).total_seconds())
    except (TypeError, ValueError):
        return None


def get_with_backoff(url: str, max_retries: int = 5) -> requests.Response:
    for attempt in range(max_retries + 1):
        response = requests.get(url, timeout=30)

        if response.status_code != 429:
            response.raise_for_status()
            return response

        if attempt == max_retries:
            raise RuntimeError("Rate limit persisted after maximum retries")

        retry_after = retry_after_seconds(response.headers.get("Retry-After"))
        exponential = min(2 ** attempt, 30)
        jitter = random.uniform(0, 1)
        delay = retry_after if retry_after is not None else exponential
        time.sleep(delay + jitter)

    raise RuntimeError("Unexpected retry state")

How Do You Prevent a Retry Storm?

Use:

• Random jitter: Prevents clients from retrying simultaneously.
• Maximum attempts: Stops infinite retry loops.
• Maximum total time: Ends work after an operational deadline.
• Global concurrency control: Coordinates all workers sharing one limit.
• Circuit breakers: Pause calls when failures cross a threshold.
• Queues: Smooth bursts into a controlled processing rate.
• Request deduplication: Prevents identical work from being repeated.
• Idempotency keys: Protect supported write operations from duplication.

A retry should be a controlled recovery attempt, not an automatic multiplication of demand.

Common 429 Error Mistakes

429 Too Many Requests Checklist

Frequently Asked Questions About 429 Errors

Find the Rate Limit Before Raising It

Start with the exact request and capture the 429 status, Retry-After value, response source and counted identity. Then connect the rejection to its threshold, time window, request pattern and business purpose before modifying the rule.

Use the free HTTP checker for one URL, review crawlability when search bots are affected and move to a broader audit when rate limiting appears across many URLs.

Novaverb connects HTTP responses, crawl evidence and URL-level diagnostics so teams can distinguish a legitimate protection rule from an accidental traffic bottleneck.

Use the Decision Ladder to determine whether the next action should be client backoff, queue control, rule correction, capacity expansion or security escalation.